Nurses working in the hospital setting increasingly have become overburdened by managing alarms that, in many cases, provide low information value regarding patient health. The current trend, aided by disposable, wearable technologies, is to promote patient monitoring that does not require entering a patient's room. The development of telemetry alarms and middleware escalation devices adds to the continued growth of auditory, visual, and haptic alarms to the hospital environment but can fail to provide a more complete understanding of patient health. As we begin to innovate to both address alarm overload and improve patient management, perhaps using fundamentally different integration architectures, lessons from the aviation flight deck are worth considering. Commercial jet transport systems and their alarms have evolved slowly over many decades and have developed integration methods that account for operational context, provide multiple response protocol levels, and present a more integrated view of the airplane system state. We articulate three alarm system objectives: (1) supporting hazard management, (2) establishing context, and (3) supporting alarm prioritization. More generally, we present the case that alarm design in aviation can spur directions for innovation for telemetry monitoring systems in hospitals.
Healthcare, and the hospital setting in particular, has experienced rapid growth of auditory, visual, and haptic alarms. These alarms can be notoriously unreliable or can focus on narrowly defined changes to the patient's state.1 Further, this alarm proliferation has led nursing staff to become increasingly overburdened and distressed by managing alarms.2 Current alarm system architectures do not effectively integrate meaningful data that support increased patient status awareness and management.3 In contrast, commercial jet transports, over many decades, have developed integration methods that account for operational context, provide multiple response protocol levels, and present a more integrated view of airplane state to support operational decision making. Similar methods for advanced control rooms in nuclear power generation have been reviewed by Wu and Li.4
In healthcare, The Joint Commission (TJC) and hospital quality departments have generated guidance that further elevates the need to address the industry's “alarm problem.” In 2014, TJC issued an accreditation requirement (National Patient Safety Goal 06.01.01) titled, “Reduce patient harm associated with clinical alarm systems.”5 This requirement continues to be included in the 2020 requirements for accreditation.
From the authors' perspective, this requirement is leading to solutions that will not effectively support performance of essential tasks and is moving away from the types of innovations that are being sought in aviation and other settings. For example, healthcare administrators advocate categorizing alarms into high-priority (“run”), medium-priority (“walk”), and low-priority (“shuffle”) alarms independent of unit context, hospital context, situational context, and historical patient context.6 In addition, each alarm category is assigned a minimum response time. When nurses do not meet response time targets, administrators may add staff (“telemetry monitor watchers”), increase the volume of alarms, escalate alarms to other staff to respond, increase the “startling” nature of alarms to better direct attention, and benchmark average response times by individual nurse identifiers. Although well intentioned, these approaches can sometimes add to the alarm overload problem by creating more alarms and involving more people in alarm response.
The authors, who have investigated human performance in several operational settings, believe that a need exists to reflect more broadly on the role of alarms in understanding and managing a system (be it an aircraft or a set of patients in a hospital department). Most alarms in hospitals signal when a variable is outside a prespecified range that is determined from the patient population (e.g., high heart rate), when a change in cardiac rhythm occurs (e.g., ventricular fibrillation [V-fib]), or when a problem occurs with the alarm system (e.g., change battery). These alarms support shifts in attention when the event being alarmed requires an action by a nurse and when the relative priority of the response is clear in relation to competing demands.
Certain alarms are useful for other purposes, such as aiding situation awareness about planned, routine tasks (e.g., an expected event of high heart rate has occurred, which indicates that a staff member is helping a patient to the bathroom). Increasingly, secondary alarm notification systems (SANSs), otherwise known as middleware escalation systems, are incorporating communications through alarms, such as patient call systems, staff emergency broadcasts, and demands for “code blue” teams to immediately go to a patient's bedside.
Thus, alarms are used to attract attention (i.e., to orient staff to an important change). However, from a cognitive engineering perspective, we believe alarms can also be used to support awareness, prioritization, and decision making. That is, the current siloed approach to alarm presentation in healthcare, which is driven by technology, impedes the ability to properly understand and appreciate the implications of alarms. Understanding the meaning and implications of alarms can best be achieved when they are integrated via a system interface that places the alarm in the broader context of system state. We hope that sharing our insights can spur both design and alarm management innovations for bedside telemetry monitoring devices and related middleware escalation systems and dashboards.
In this article, we provide insights from human factors research, and from the integrated glass cockpit in particular, to prompt innovation with clinical alarm systems. To draw lessons from aviation and other domains, we conducted a series of meetings among three human factors engineers with expertise in alarm design in healthcare, aviation, nuclear power generation, and military command and control domains. In the process, we identified differences in the design, use, and philosophies for managing alarms in different domains; defined alarm systems; clarified common elements in the “alarm problem” across these domains; articulated objectives for an alarm system that supports a human operator in controlling a complex process (i.e., supervisory control); and identified levels of alarm system maturity. Based on these activities, we assert that:
Clinical alarm systems fail to reduce unnecessary complexity compared with the integrated glass cockpit.
Aviation and clinical alarm systems share core objectives.
The challenges with aviation and clinical alarm systems are similar, including where alarm systems fall short of their objectives.
We can demarcate levels in the process of alarm system evolution, largely based on alarm reliability, system integration, and how system state is described. The higher levels point the way for innovation in clinical alarm systems.
Aviation and Healthcare: Relative Complexity of Operating Environments
Compared with healthcare, the operating environment in aviation arguably is less complex and the expectation for alarms is different. In aviation, the airplane is assumed to be “healthy” and alarms are unusual events; in healthcare, patients arrive in a compromised state and their basic physiological functions may be unstable, making alarms more commonplace. The alarm schemes for commercial jet transports have evolved slowly (compared with hospitals); the evolution timescale is spread across decades, with fewer and less frequent incorporation of new alarm systems, types of alarms, or new types of devices and communication systems.
In healthcare, more variability exists in the variables being monitored by the alarm system because patients are not an engineered system, meaning that each patient has a different range of normal values. Pilots monitor a single system, whereas healthcare involves multiple patients in different rooms on a care unit. In aviation, the sensors and associated alarm systems typically are more reliable, with fewer “no signal” alarms from when a sensor becomes disconnected from the monitored system. The location of both auditory and visual alarms is more variable for healthcare, while the flight deck design places the two pilots in front of a fairly compact alarm display. In addition, there are only two crew members, both of whom benefit from hearing all alarms, whereas healthcare targets alarms to an individual working a particular role in a particular shift who sometimes is not in the physical space where auditory alarms occur. The actions to be executed are taken by the flight crew who receive the alarm through the same interface in the same location. Finally, in aviation, an integrated alarm management system prioritizes alarms using increased salience for higher priority alarms, presents a list of alarms in the sequence in which they occurred, and suppresses alarms that are of lower significance in some situations.
In hospitals, differences can occur in some operating environments, which adds further complexity. All hospitals in the United States currently use bedside telemetry monitoring devices approved by the Food and Drug Administration (FDA). In some hospitals, additional SANSs are used. SANSs provide auditory and visual alarms directly to registered nurses on smartphones, cellphones, or pagers. Some of these devices have haptic interfaces, and they allow changing the normal range for a patient without having to go to the patient's bedside. Additional alarm systems are being implemented in some hospitals that use sensors in wearable technologies (e.g., Fitbit; Fitbit, Inc. San Francisco, CA) to monitor a patient's physical activity and heart rate. Some alarm systems are being introduced to enable nurses to reduce the number of times they enter the hospital room for patients who have an infectious disease (e.g., COVID-19). Some middleware escalation systems are incorporating call system interactions initiated by hospital staff and patients, as well as providing options for escalation pathways to redirect alarms to other staff if response does not occur within set time periods. In some cases, these escalations incorporate location data for nurses from radio-frequency identification sensors on their identification badges or sensors in the ceilings of patient rooms. Some alarm systems support capturing information on nurse identifiers, patient identifiers, time-stamps, and actions taken through the interface, such as turning off an alarm or escalating an alarm to another provider by refusing to accept an alarm.
Alarm System Objectives
How should alarms support operators? The simplest objective for an alarm is to get a human operator's attention to a meaningful change; that is, the nurse or the pilot needs to orient to an important system change. However, from a systems-management perspective, this simple characterization fails to tell the whole story. In the following, we propose three alarm system objectives. With these objectives, we lay out directions for how to move beyond an approach tied to responding to single alarms and instead focus on supporting an operator (e.g., nurse, pilot) having a better understanding of the monitored system (e.g., patient, airplane).
Support Hazard Management
One important objective for alarms in any safety-critical system is to initiate the appropriate operator response to a failure or other hazard: in aviation, a stall warning; in healthcare, a warning that a patient has no pulse (possibly a code blue). An alarm, along with related elements of the system interface and operational procedures, needs to help the operator do the following:
Orient to an important change. Some salient interface element, such as a loud sound, a bright light, or both, needs to attract the operator's attention to an important change. In general, having more than one sensory channel (e.g., visual, auditory, tactile) makes capturing attention more reliable, especially when one channel (e.g., auditory for nurses in hospitals, visual in aviation cockpits) already is saturated with information.
In healthcare, for those who use SANSs, when the primary caregiver is otherwise engaged in a critical activity or physically distant, providing a mechanism for redirecting the alarm to someone who can respond is important. Potential mechanisms are a nurse pushing a button to indicate that he or she is not available or automatically escalating an alarm to another nurse after a period of time (e.g., 60 seconds).
Understand the nature of that change. Some interface element needs to describe this important change. Information about the nature of the change needs to be presented clearly and simply.7 In hospitals, because a nurse is responsible for multiple patients, understanding must also include identifying the patient's room. In some cases, the aural alarm itself conveys meaning, as in the “terrain, terrain” alarm that occurs when the airplane flies too close to the terrain. This approach is an alternative to a standard warning tone that requires the pilot to look to the central alerting system display to read an alarm message. A voice alarm can communicate the most urgent hazards directly to the flight crew and remove the need for locating and reading an alarm message.
Urgency or severity are other aspects of the change that could be communicated. For example, in the hospital, bedside telemetry monitoring devices that are required to be FDA approved use the ANSI/AAMI/IEC 60601-1-8 standard8 to distinguish high-priority events (repeated sequence of five sound pulses) from medium-priority events (nonrepeating sequence of three pulses9 ). These bedside telemetry monitoring devices use nonverbal sounds to distinguish between types of alarms that are primarily clinical in nature but also include signals such as “dead battery” or “leads fail,” where the alarm system itself requires maintenance. Alarms forwarded to nurses' phones and pagers via middleware escalation systems typically include alarms from the bedside, as well as alarms from other sources. One source includes alarms from the call system; therefore, code blue and staff emergency alarms are included. Another source can be bed exit alarms from the hospital bed itself, where a patient is at risk of falling.
Identify appropriate actions to take. Although some alarms are intended to update situation awareness, the primary role of an alarm in hazard management is to cue an operator to take appropriate action to recover from or mitigate the consequences of a failure or other hazard. When operator actions to manage the failure or hazard are recommended, the operator needs to have ready access to what those appropriate actions are. For the most critical cases (e.g., low peripheral oxygen saturation [SpO2]), an action or small set of actions is memorized by the operator. For many other alarms, the operator may need access to procedures that specify the required response steps. The alarm needs to create support for a user to identify those actions, either by showing a recommended action visually along with an auditory alarm sound or by directing the operator to a set of actions to ensure that the correct procedure is executed. For example, a system could recommend lowering a threshold for a “low heart rate” alarm to 55 bpm for a particular patient directly from a nurse's phone by pushing a button while also displaying the recent history of low heart rate alarms all being just below 60 bpm.10 In recently developed jet transports, the interface automatically identifies and presents the most appropriate non-normal procedure when it detects and alarms a failure.
Sort recommended actions from multiple alarms by priority. In healthcare, on some units, six simultaneous alarms might be tied to events across four patients. Rather than allowing them to go off simultaneously, in which case some alarms are either dropped or indistinguishable, the alarms and their associated actions could be sorted by urgency of the recommended actions, such as by putting code blue alarms first. In aviation, in some non-normal situations, the operator may be able to take a number of actions, especially when there are multiple alarms. The system interface aids the operator in assessing which actions have the highest priority by ordering the presentation of the alarm conditions: warnings at the top, followed by cautions and advisory alarms.
Execute the actions efficiently, accurately, and completely, including a safe recovery. The system interface and the operational documents need to support the operator in executing the prescribed actions in a timely manner. Ideally, the interface allows the operator to evaluate how well the situation is managed as actions are taken. For example, airplane systems reveal their configuration and the flight crew can see that their actions have altered the configuration to replace a failed power source. Of note, in the hospital setting, the recovery process can extend beyond the immediate response, especially if the initial recovery is not full. For example, if respiratory distress occurs, a therapist will need to administer oxygen over time, and other providers will become involved. The initial recovery actions need to be linked to these extended actions.
These five steps, which have been referred to as the “integrated alerting-to-recovery sequence,”11 broaden the usual scope of alarm schemes to emphasize the point that an integrated approach is needed among the initial alarm, the system interface, and operational procedures to ensure that critical events are managed.
Communicate a New System State/Establish Context
The overall objectives are to establish context for interpreting changes and for the alarm system to communicate new states to operators. In many cases, an alarm signals a change to system state for which no immediate operator action is required, though it may have implications for later actions or decisions. When these changes occur, a change in some enduring system representation should capture the new state and provide context for future system changes. Of note, these representations typically are not elements of the alarm system but are captured in a separate system representation that is integrated with the alarms. The following two types of system changes should be considered.
Compromised or degraded system. In aviation, examples of a compromised or degraded system include loss of automatic throttle, engine icing, or a loss of system redundancy. In healthcare, examples are a high heart rate, low blood oxygen level, or presence of an anomalous cardiac rhythm (e.g., V-fib). Ideally, the system representation reflects system history to offer a complete picture of system state, especially for those who were not present when changes occurred. The ultimate objective is to help the operator identify how to manage the system in its new state and how system capabilities have been degraded (e.g., airplane will require manual speed control, patient will need supplemental oxygen before getting out of hospital bed). Communicating a new system state and establishing context helps the operator to understand if the alarm is important.
Change in operating regime. The system can sometimes enter a new regime in which the operating objectives change, and alarms need to be interpreted for that operating regime or mode. For example, a nuclear power plant can be operated to produce power or in a shut-down state to perform refueling. Each regime has different operational objectives. In aviation, ground operations and flying are different types of operation with different objectives. For example, an airplane can sense when it is in the air (versus on the ground) and alarm if sensor probe heating is not armed; the airplane does not care about heating sensor probes on the ground. In healthcare, a particularly important state change is when a patient no longer wants to receive interventions because s/he is solely being treated for comfort care (do-not-resuscitate comfort care). In these situations, quickly responding to cardiac anomalies is less important because the heart is expected to fail in the next 24 hours. Another type of regime change can be a shift in alarm trigger values. An example is a patient who is recovering from a cardiac operation to address atrial fibrillation (i.e., a cardioversion) and therefore is expected to have abnormal rhythm for a few hours in the postoperative unit before transitioning to a regular rhythm. In aviation, terrain warnings depend on the airplane's status regarding approach; if the airplane has engaged the approach and will intentionally fly toward the ground, terrain warnings are suppressed.
Thus, new situations define a context for setting or responding to system alarms. A system representation needs to convey clearly how that new context will shape operator decision making and actions. For example, innovation for this step could automatically tailor respiratory threshold expectations for patients in a postoperative unit immediately following surgery, several hours later, and after transitioning to an acute care unit. This type of tailoring could be expanded to fit data from an individual patient, such as changing the low heart rate alarm setting for a patient who has had a low resting heart rate (e.g., 40 bpm) for a number of hours.
Support the Operator in Managing the Set of Alarms in Time
Another objective for an alarm system is to manage multiple alarms, which brings two methods. When multiple alarms occur, they need to be prioritized, which typically requires an understanding of the larger system context. That is, the identification of the most urgent or important alarm may depend on the other alarms that are occurring and the operating regime. Ideally, the alarm system aids in this prioritization. In the healthcare setting, prioritization occurs across patients; context for each patient may be relevant for assessing the overall most urgent or important alarm. Displays that provide a quick overview of the status of all the patients that a given nurse is managing, including the most critical alarms for each patient, can also be useful in helping a nurse triage responses for multiple patients.
One approach to prioritization in engineered systems is tied to dependency between alarms; specifically, some alarms are tied to events that occur “downstream” from an initial failure or event. A newer feature in airplane alarm systems is logic to identify the initial failure and move it to the top of the alarm stack, knowing that if the primary failure is addressed, the downstream problems will be resolved.
A complementary approach to prioritization is alarm suppression. In an example from aviation, Airbus airplanes have a “dual-input” alarm, with an aural component and visual message, to indicate that both pilots are making inputs on their sidestick controllers, which can lead to unexpected effects on the airplane. However, when a stall alarm occurs at the same time, the aural component of the dual-input alarm is suppressed to prevent interference with the stall alarm.
These forms of alarm management are possible when alarms are integrated into a single system that has awareness of the context and the full set of alarms. Prioritization and suppression are tools to aid the human operator in determining alarms that get immediate attention and those that should be deferred.
Alarm System Challenges in Aviation and Healthcare
Despite the differences in the operating environments, alarm systems have shared challenges in both the aviation and healthcare domains, as well as in nuclear power generation. These include when:
False alarms are difficult to remove completely from the system.
An actionable signal, buried in numerous nonactionable signals, is difficult to detect.
Masking occurs: Multiple simultaneous alarms reduce the ability to discern the encoded auditory information or view the visually displayed information at once (i.e., “alarm floods”).
Repetitive, redundant alarms lead to unnecessary tasks and communications.
Frequent communication of required actions to multiple parties decreases clarity on responsibility and accountability for responding to alarms.
Challenge 1: False Alarms
For the first challenge of false alarms, in healthcare settings, sensor technologies and sensor connections to the patient have led to reliability issues. For example, electrocardiographic electrodes can become dried out over time and fail (though daily changes can reduce false alarms for cardiac events12 ). Other hospital alarm reliability issues have been addressed (e.g., alarms for capnography, such as for end-tidal carbon dioxide). With this higher reliability, these alarms are better and occur earlier than alarms for oxygen desaturation using pulse oximetry (e.g., SpO2) for patients using patient-controlled analgesia after a surgical procedure.13 Alarm reliability improvements are essential before any alarm system can support hazard management effectively.
For dynamic systems that can operate near alarm boundaries frequently, designing a highly reliable alarm can sometimes be difficult. Aviation, over the decades, generally has developed reliable alarm schemes that are embedded in engineered systems, though a few difficult cases remain. One area of alarming that continues to be open to second guessing, though sometimes at great peril, is alarming for terrain proximity (Ground Proximity Warning System). Pilots believe it is too sensitive; however, because of limitations in this older technology, the warning system also has a history of failing to identify impending terrain collisions (e.g., Cali accident,14 more recent First Air accident15 ). An improved system (Enhanced Ground Proximity Warning System) has applied a completely different technology to achieve greatly improved terrain avoidance.
Challenge 2: Buried Alarms
For the second challenge of buried alarms, nurses routinely have experiences with particular alarms that are not actionable, meaning that the alarm does not require an immediate action from the nurse. Combined with the unreliable alarms, nurses become calibrated to the low information content for alarms, resulting in delays in responding to some alarms or even failing to respond at all. For example, if a series of low pulse oxygenation (i.e., low SpO2) alarms was erroneously triggered when a sensor is no longer attached to a patient's finger, the next alarm on that patient or the same type of alarm on a different patient can reasonably be interpreted as invalid and, therefore, not a higher priority than other ongoing high-priority activities.
In aviation, some system failures, such as unreliable airspeed, generate a number of consequential alarms that can distract from the primary cause of the problem. In older airplane models, this was worse because there was no explicit alarm message for unreliable airspeed.16 The pilot had to infer the real problem from several cues, and the consequential alarms produced a distraction from that desired path.
Challenge 3: Masking
For the third challenge, masking, it is not uncommon on hospital units for multiple auditory alarms to go off simultaneously on a unit, making it difficult to distinguish the sounds. This issue is exacerbated when there is background noise from intravenous pump alarms, alarms and breathing sounds from ventilators, sounds from ice machines and refrigeration units, conversations, and broadcast announcements on overhead paging systems.
In aviation, cases have occurred in which the alarm messages overwhelm the central alarm display space, which has roughly 20 lines. Indeed, in an accident in which an engine exploded, sending engine parts into other systems and disabling them, the alarm display generated 86 messages over a relatively short period of time. It took the flight crew several hours to sort through the long alarm list.17 Airplane manufacturers fight an uphill battle to contain the number of aural alarms (tone and voice) and to sort alarm messages for urgency (via prioritization and suppression, as mentioned above). The general approach is to use a small number of aural alerts to attract attention and then use sorted alarm messages on a central display to present a coherent picture.
Challenge 4: Redundant Alarms
For the fourth challenge, redundant alarms, new alarm systems commonly are layered onto the existing alarm system infrastructure. The original infrastructure with bedside telemetry monitoring can lead to alarms in the patient's room and simultaneous alarms at a central monitoring station, where nurses on the unit typically go when not providing bedside care. New alarms systems, such as SANSs, will often convey many of these alarms, along with alarms from other systems (e.g., hospital beds, ventilators, patient call systems) directly to nurses on hand-held devices. In other industries that use central alarm displays, there is no need for these distribution schemes.
Challenge 5: Diffuse Responsibility for Alarm Response
For the fifth challenge, diffuse responsibility for responding to alarms, the SANS sends an alarm signal to a nurse assigned to care for a hospital bed with an associated patient during a particular work shift. This assignment typically is done by a unit clerk, who needs to be informed of all updates to patient assignments to nursing staff as new patients are admitted and patients are discharged to other units. With many SANSs, the initial alarm goes first to the assigned nurse, then to a nurse with secondary responsibility (typically defined by taking care of patients next to the first nurse), and then to a charge nurse or to all nurses on the unit during that work shift. If alarms are sent to “all,” then nurses can get confused about how the alarm system works and whether the assignment was correctly entered for the patients cared for during that shift because the alarm signal is not modified when it is an escalated alarm.
In aviation, the pilot flying the airplane does not receive all alarms. Certainly, alarms that directly reflect airplane operation, such as an inability to pressurize the cabin, are presented to the pilots. However, engine health maintenance alarms are sent to system technicians responsible for aircraft maintenance and not the pilots flying the airplane. In contrast, nurses often are sent alarm system maintenance alarms (e.g., dead battery) in a telemetry monitoring device. Maintaining the clinical alarm system power source probably is not an appropriate role for nurses who have been assigned patient care during a work shift.
Levels of Alarm System Evolution
Clearly, differences exist in the maturation of alarm system technology between healthcare and aviation. Although aviation alarm systems are more mature than healthcare in general, there is still room for improvement. The following section defines four levels of maturation in an effort to capture how well alarm system technology supports the three alarm system objectives. For each level, we identify design goals for improving alarm management that can be implemented within that level of alarm technology maturation. Clinical alarm systems currently are at the first and second level of maturation. In contrast, aviation is currently at level 3, with opportunities to move to level 4. The hope is that as more software and network infrastructure become available in hospitals, clinical alarm systems will evolve toward levels 3 and 4.
Level 1: Low-Reliability, Unintegrated Alarms
At the lowest level are systems that include “single-sensor, single-alarm” technologies, for which individual alarms are based on single indicators using a simple criterion (e.g., a parameter exceeding some threshold). The alarm logic does not consider the broader context or other alarms that might have been triggered recently. Further, at the lowest level, the alarms tend to be unreliable and are subject to high false-alarm rates.
Healthcare, generally speaking, operates with poorly integrated technology. It is supported by different patient-monitoring and treatment technologies from different developers. This lack of integration significantly limits the ability to consider context to establish alarm priorities and suppress alarms that are not meaningful in the moment. In contrast, an airplane or a nuclear power plant, especially those of more recent vintage, is tied to a central networked system that manages all system indications and control inputs.
Furthermore, the sensors used by healthcare generally are less reliable than those used in aviation, and implementation is more vulnerable to patient and personnel factors. Specifically, a sensor may be attached to a patient with the intention to remove it after a short period of time, which can make it less reliable than sensors that are integrated into engineered airplane systems. An example is a pulse oxygenation sensor placed using removable tape on the end of a patient's finger; this sensor can fall off and trigger a low-oxygenation alarm.
Design goals for alarm systems at this level are:
Increase the reliability of individual alarms to the extent possible through changes to procedures and technology
Remove ineffective alarms and alarms that do not have strong ties to operational policy or practices (i.e., alarms that do not support decisions or actions)
Remove or combine similar and redundant alarms (e.g., use a high heart rate alarm but eliminate the tachycardia alarm)
Strive for some type of integration across sensors to cross-check each sensor and produce more reliable alarms
Use adjustable trigger points to tailor each alarm to a patient's specific case, supporting visibility of the trigger point shifts
Revise SANS alarm escalation schemes and visual displays to clarify primary and secondary responsibility for responding to alarms
Level 2: High-Reliability, Unintegrated Alarms
At the second level of maturity, alarm reliability issues mostly have been overcome but the alarms remain unintegrated. After issues in alarm reliability are addressed, the next step is to use sensor integration to provide more context to support better interpretation and prioritization of the alarms. Opportunities to better align alarms with operational needs may be available even before the larger system becomes better integrated. For example, aviation recently added alarm schemes for better awareness about airport runways and traffic during landing; however, this new set of alarms is not well integrated into the existing alarm scheme.
Design goals for alarm systems at this level are:
Add alarm context for single alarms via graphs or digital strip charts that present a history of the variable over time
Develop minimal integration through a separate representational scheme that pulls in the various alarm outputs and:
Presents a more coherent picture of each patient
Presents an integrated (i.e., across patients) set of priorities that allow healthcare practitioners to allocate resources to the most urgent or highest-priority patients
Better manages the timing of auditory alarms to prevent alarm masking (i.e., having multiple patient alarms occurring simultaneously through the same system)
Level 3: Strong Alarm Integration with Component Level of System Description
At this level of maturation, highly reliable alarms are processed through an integrated alarm system that supports alarm suppression and prioritization schemes to remove or de-emphasize less meaningful alarms. This characterizes the current state of commercial jet transports. In some cases, downstream alarms are removed or made subordinate to the initial upstream failure. The operational procedures that accompany the alarm scheme aid the human operator in establishing context and, in some cases, identifying changes to system capabilities.
However, in the case of jet transports, the alarms primarily are describing failures of system components: failed pumps and valves at the lowest level up to loss of an airplane system (e.g., hydraulic or electrical system). The implications regarding what system capabilities have been compromised and what options remain available are not presented to the operator; indeed, the bulk of this important cognitive work is left to the operator. They must fall back on their own knowledge to infer how the system's operational capabilities have changed and what options remain for safely managing the situation. There are a few examples in aviation where the alarm system does communicate implications of the system failure. For example, in the case of a loss of the Autoland function, the alarm system reports out a change to airplane capability directly instead of requiring the human operators to determine it on their own. Then, the flight crew, now aware of the loss of that capability, can operate using less automated procedures.
Design goals for alarm systems at this level are:
Make it easier for human operators to go from alarms on failures of system components to the changes in the system's operational capabilities (e.g., develop approaches for operational decision making based on the system's remaining capabilities, such as selecting an alternative airport and arrival based on remaining navigational capabilities).
In healthcare, move from alarming on individual variables to a higher level of patient description; for example:
Detect “signatures” in real-time vitals data (e.g., increasing or decreasing respiratory rates)
Detect recovery signatures after disrupting events (e.g., back to normal after antibiotics given for sepsis)
Detect “system failures” such as infections (e.g., sepsis)
Use higher levels of data access and integration to alarm on unexpected events outside of the sensor technologies around the patient; for example:
Trigger an alarm for lab results outside of threshold ranges (i.e., non-normal labs)
Detect undesired medication actions (e.g., giving two medications together that should never be given together)
Level 4: Strong Alarm Integration with Functional Level of System Description
At the highest level of maturation, the alarm system would not only flag abnormal system states (e.g., malfunctioning equipment, abnormal patient temperature) but also flag implications at a higher system level (e.g., loss of Autoland function, evidence of sepsis, respiratory system compromised). This conceptual approach relies on a functional analysis18 of the system. What are the highest-level objectives and how well are they being met?
This form of advanced alarm scheme has been proposed; it reports out airplane system failures not in terms of physical system components but in terms of changes to the airplane's operational capabilities,19 including landing distance, range, ability to maintain a livable environment, and capability to fly certain approaches. Thus, the alarm system would indicate that the airplane cannot reach the planned destination or use a specified approach and runway. The objective of this approach is to remove the need for pilots to reason from broken system components to the effects on operational decisions and flexibly and resiliently respond to a loss or degradation in a system function. This approach will become increasingly important as airplane systems become more complex and interconnected.
This preceding exercise—demarcating alarm system maturation levels—artificially proposes periods of stability. In reality, each system will more opportunistically tack on improvements in alarm reliability, alarm integration and context, and meaningful representations of system state (patient health). A system is unlikely to advance all three in lockstep. The objective in describing these artificial levels is to highlight appropriate goals for system upgrades; that is, upgrades should not just provide faster, more reliable technology but also strive to improve cognitive engineering (support healthcare actions and decision making). This focus may lead to different upgrade decisions in alarm system development.
We described the differences between the state of alarm technology for commercial jet transports and that for hospital patients. Aviation, which has been around longer and has better-integrated systems, offers lessons about how hospital alarm strategies could be improved with respect to making complex cognitive work easier for nursing personnel. We offered three high-level objectives for alarming in any complex, safety-critical system; these strongly emphasize using alarms not only to indicate a meaningful change but also to provide the context for that change and future changes.
To spur innovation in both healthcare and aviation, we propose a four-level framework for characterizing maturity levels for alarm systems. Overall, we advocate for reconceptualizing alarms to be integrated systems for supporting the cognitive work of nurses on a unit, collaborations with code blue response teams and respiratory therapists, and communications with patients and other clinical staff.
This research was supported in part by the Institute for the Design of Environments Aligned for Patient Safety at The Ohio State University, which is sponsored by the Agency for Healthcare Research & Quality (AHRQ; grant no. P30HS024379). The authors' views do not necessarily represent the views of AHRQ.
Randall J. Mumaw, PhD, is a senior research associate at San Jose State University in San Jose, CA. Email: firstname.lastname@example.org
Emilie M. Roth, PhD, is owner and principal scientist at Roth Cognitive Engineering in Palo Alto, CA. Email: email@example.com
Emily S. Patterson, PhD, is an associate professor in the School of Health and Rehabilitation Sciences at The Ohio State University in Columbus, OH. Email: firstname.lastname@example.org