Alarm fatigue is defined as sensory overload when clinicians are exposed to an excessive number of alarms, which can result in desensitization to alarms, missed alarms, and even patient deaths.1 One strategy to reduce the alarm fatigue in hospitals is implementing a secondary device notification system. This strategy involves transmitting the alarms from a primary device to a middleware system (Figure 1). The system uses predefined rules to suppress, translate, escalate and/or communicate these alarms to a secondary device, such as a care team member's pager or cellphone. Development of these rules dramatically affects what and how alarms are sent.
The belief that adding another device into an already crowded alarm environment would reduce alarm fatigue seems counterintuitive. However, the successful implementation of secondary devices allows other alarms to be turned off (e.g., certain alarms in patient rooms and at central stations). A middleware system also reduces the scope of the alarm by directly transmitting to the person responsible for it, rather than broadcasting the alarm to all staff members near the patient.
When developing middleware rules, several fundamental questions must be answered by the alarm management team:
What alarms do I want going to my secondary device?
Do I want to add a delay to the notification?
How or in what context will the alarm be received?
How will the alarm be acknowledged?
How will the alarm be escalated?
To whom will the alarm be escalated?
This article will identify several factors that affect secondary device notification, including the type of device to utilize for secondary notifications, determining which alarms should be sent to the secondary device, who should be notified, and how to address delays and escalations.
The type of device (e.g., a pager, phone, or tablet) selected to receive messages from the middleware affects the type of data that can be sent (e.g., text versus waveforms), the context of the alarms (e.g., single or multiple vitals), and how messages are received (e.g., the size of the text or waveform), acknowledged, and escalated.
For example, a pager device is capable of transmitting text but not waveforms, and the number of characters that can be delivered in one message may be limited. Clinicians experience a different workflow when acknowledging alarms using a pager compared with other devices. A hospital may procure a specific phone make or model capable of sending waveform snapshots, but the workflow to access that snapshot may differ dramatically.
Finally, it is necessary to understand the workflow on how to accept or escalate alarms on various devices. Some pager systems lack the ability to confirm the receipt of a sent message. A pager system may include limitations in escalating or transferring alarms to other team members. Most phone- or tablet-based systems require multiple user actions in a defined time frame to accept an alarm before the alarm is automatically escalated. Understanding the workflow for transferring alarms to different team members will also aid in optimizing workflow for the end users.
This workflow analysis is particularly important when considering staff that may be in the middle of sterile procedure, preparing a medication, or wearing personal protective equipment. An understanding of these workflows and their impact on infection prevention also needs to be investigated. Other workflows that need review include, but are not limited to, patient and device handoffs during breaks, meals, and/or while traveling off of the unit with other patients.
Thoughtful selection of the end device aids in development of an efficient workflow, which is critical to a successful implementation of a secondary alarm notification system.
Evaluating Which Alarms Need to Go to Secondary Devices
For each device integrated into a middleware system, a thoughtful analysis should be completed to determine which alarms to pass through to the end user via the secondary device. Just because the device alarms does not mean the end user needs to receive that alarm on their secondary device. Implementing a secondary device notification system will not reduce alarm fatigue unless proactive decisions limit the number and type of alarms sent through the middleware.
For example, a physiological monitor may contain several types of alarms:
Physiological alarms that occur when limit breaches occur (e.g., high or low heart rate, respiratory rate, oxygen saturation [SpO2], end-tidal CO2 [ETCO2])
Arrhythmia alarms (e.g., ventricular tachycardia, asystole)
Technical alarms (e.g., leads off, battery issues)
An on-call nurse may receive other types of alarms, such as patient assist, staff emergencies or staff assistance, code blue, and bed exit.
In determining which of the above alarms are passed through to the secondary device, the team must evaluate which alarms need immediate attention and how the interruption will affect the day-to-day workflow of the clinician. A hospital may decide, for example, that arrhythmia alarms and code blue events are critical and must be transmitted, but all technical alarms will not be transmitted.
The above analysis applies to all devices that are being integrated into the middleware. After completing the individual device analysis, the hospital should conduct a review of all its devices that studies the priority of each message from each device. This helps to resolve issues that occur when faced with multiple, simultaneous alarms.
The way information is conveyed can affect how clinicians will respond to an alarm. For example, if a patient experiences a heart rate of 224 bpm while the alarm threshold on their physiological monitor is set to 200 bpm—the alarm message may say “HR > 200” or “HR = 224,” depending on the settings and equipment. The information contained in those two messages is very different. In addition, the alarm may or may not concatenate other vital signs occurring the same time, such as “HR = 224, Resp = 12, SpO2 = 99.” This concatenation can provide additional context to the end user, who is looking at that alarm to determine the criticality of the patient.
Who Is Notified?
The previous section focused on what data should be sent to the secondary device, but that decision needs to be made at the same time as who the data should be sent to. It may seem reasonable to send all alarms to the secondary device of the nurse assigned to a given patient, but that decision may not make sense for the workflow of that nurse. Consider if she or he will be able to respond to all of the alarms in a timely matter. Will the number of alarms interrupt the nurses' workflow so much that it affects the other aspects of care?
It may make more sense for the assigned nurse to receive alarms related to limit breaches, while sending technical alarms such as “leads off” to the patient care assistant, who can reattach the leads. Should arrhythmia alerts be transmitted directly to the charge nurse as well as the nurse assigned to that patient, or should they go directly to the code team? The answers to these situations greatly vary based on the workflow of the individual institution. The closer the notification aligns to the workflow of the unit, the less disruptive the secondary notification.
Technology complexity can arise related to the multiple ways staff members are assigned to patients. Hospitals may encompass several locations, systems, and software programs. The alignment and/or integrations of different technologies can be complicated. Ideally, the operational logistics of this patient-to-staff assignment needs to be assessed and understood to ensure a successful implementation of secondary device notification systems.
Will the number of alarms interrupt the nurses' workflow so much that it affects the other aspects of care?
While discussing which team members should receive what alarms, the hospital should also discuss the steps that should occur if the alarm is not acknowledged or handled. Should there be an automatic escalation within the system? There are two schools of thought for implementing escalations. The path that the hospital takes should align to the culture and workflow of the organization.
Option 1. If the alarm is not accepted or acknowledged, the system may allow rebroadcasting of alarms to others. If this option is selected, decisions need to be made about who the escalation is routed to. This decision will dramatically affect workflow, so working though the details is required. For example, if a hospital decides to escalate all nonaccepted or unacknowledged alarms to the floor's charge nurse, can that single charge nurse handle all those escalations? How will she prioritize multiple alarms from several different patients in different rooms? What is his or her workflow to handle those alarms? Should the hospital add a delay to the escalation alarm? What happens when the person receiving the escalated alarm is unavailable to handle it?
Option 2. No escalations are implemented. This option requires workflows that allow the staff assigned to that bed to respond to all alarms. Workflows must be developed to deal with operational issues such as break times, traveling off the floor, and isolation patients. Hospitals that choose this option develop workflows that allow transferring alarms to another staff member if the primary staff is occupied at the time of the alarm.
Hospitals choosing either of these options should understand their current workflows and cultures. If not aligned to current workflows, this option can exacerbate alarm fatigue.
Implementing a delay at the secondary device may help resolve certain types of false alarms.2 This delay manifests as follows: An alarm sounds at the primary device in the room. If a 30-second delay is implemented between the primary alarm and secondary device notification, then the alarm would not arrive to the secondary device until 30 seconds after the primary device generates the alarm. If the primary alarm resolves itself during that during that 30-second to 1-minute delay, then secondary alarm would never reach the end user. This type of delay is useful for alarms subject to motion artifact, such as SpO2. However, some types of alarm signals should never be delayed, such as life-threatening arrhythmias.
Hospitals can also implement a delay between the secondary device notification to the end user and the escalation notification.
Below are some example scenarios demonstrating the above decisions.
Patient A in room 1023 is on a physiological monitor with a high heart rate limit set to 200. The patient's heart rate has spiked to 224. Hospital A has designed the system so that the nurse assigned to bed 1023 is alerted to the HR = 224 on her phone immediately. She is currently in a different patient's room in an isolation gown, so she declines the alarm on her phone. The alarm auto-escalates to the change nurse.
Patient B is in room 1024 is on a physiological monitor with a low SpO2 limit set to 90. The patient's SpO2 decreases to 88. Hospital A has designed a system to incorporate a delay on SpO2 alarms because they determined that the majority of the SpO2 alarms resolve within 30 seconds. Patient B's SpO2 rises above 90 during the 30-second interval. No alarm is sent to the nurse assigned to bed 1024.
Patient C in room 1025 has rolled over, causing his leads to come off. Hospital A has designed their system so that the patient care assistant assigned to room 1025 is alerted to the leads off after a 30-second delay. She does not address the alert. After a 1-minute delay, the alert is transmitted to the nurse assigned to bed 1025.
Patient D in room 1026 has an asystole alarm on their physiological monitor. Hospital A has designed the system so that the alarm is immediately transmitted to both the nurse assigned to bed 1026 and the charge nurse.
When implementing or optimizing secondary device notification systems, several factors need to be taken into consideration, including:
What end device is selected.
What alarms are sent.
Who receives those alarms
Which alarms are escalated.
What delays should be implemented.
Hospitals should be thoughtful in their development of secondary alarm notifications systems by tailoring solutions to each unit within the hospital. Solutions should be workflow-driven and take into consideration the unit, the staff, and the alarms occurring in that situation. Hospitals should utilize process improvement cycles to optimize the system, rather than expecting to optimize all aspects of the design in the initial implementation.
About the Author
Samantha Jacques, PhD, FACHE, is director of clinical engineering at Penn State Health Milton S. Hershey Medical Center in Hershey, PA. Email: firstname.lastname@example.org