A Sound Approach to Device Alarms

Originally Published MDDI October 2003

Alarms

Although most complex medical devices have alarms, problems still frequently occur. Proper alarm system requirement specifications may offer solutions.

Laurence Harris

When defining a new medical device, many people have very specific ideas about what alarms their device should generate. For example, they are aware that fault and abnormal condition detection, alarm annunciation, and logging are important functions in control and monitoring systems. But this knowledge by itself is incomplete.

Problems with alarms occur in many systems; however, medical equipment using embedded controllers is especially affected. Although embedded controllers usually have alarms, these systems are often troubled by ineffective fault-reporting subsystems. In addition, manufacturers designing equipment using embedded controllers may not have prior experience with specifying an alarm system, often resulting in a less than optimally effective product.

For medical product developers who use embedded computers, the definition of fault detection and reporting behavior should be an important part of a product requirements specification (PRS) document.

Comprehensively designed alarm systems perform three important functions: event annunciation, status reporting, and event logging. Annunciation of a fault condition can be done in a variety of ways, using various types of hardware, but usually combines a visual presentation with an appropriate sound or sequence of sounds. Most people understand this, even if they've never before worked with alarm system design. That, however, is the root of one big problem with the PRS development process: most people don't understand that the topic of alarm system specification is quite complicated and has already been studied thoroughly. Not realizing this, many people defining product requirements fail to specify critically important alarm system features.

Learning from History

There are published standards and related technical articles that address those factors that must be considered when defining alarm system requirements. One comprehensive standard is ANSI/ISA-18.1-1979-(R1992) Annunciator Sequences and Specifications.¹ Such standards have resulted from industrial insurance–driven requirements for plant and process safety, and from the users and manufacturers of industrial process control room equipment. The standards are the product of cooperation among many talented and experienced engineers participating periodically in working meetings held by organizations such as ANSI, ASTM, ISA, and others. The development of the standards has provided tremendous benefits to companies that are operating industrial processes such as oil refining, papermaking, and chemical processing. The standards enable them to easily engineer control systems, using commercial, off-the-shelf modular hardware for their control rooms.

The benefits can also flow to those defining and designing medical equipment since the standardized methods can be utilized. These defined methods can simplify product definition and lead to thorough PRSs, because referral to standardized methods highlights important product behavior considerations. Every alarm system for a medical device will have unique features; using the standards helps make sure that no important aspects are forgotten.

Additional factors uniquely important to medical products developers are addressed in other standards for some specific applications, such as equipment for anesthesiology. A joint effort by ISO and IEC subcommittees has been working to produce a collateral standard to IEC 60601-1, for the application of alarms in medical equipment. If enacted, it will be an important and useful resource.

Alarm Priorities

Creating different alarm priorities helps product designers ensure that users will see and understand the most critical alarms easily, without having to wade through less important information.

Grouping alarms of similar importance allows a designer to define different system behaviors that enhance a user's ability to quickly understand any given situation and to more easily choose an appropriate response to the situation. For example, an alarm indicating the failure of a heart-assist pump deserves more attention than alarms about small deviations from expected system performance. The highest priority alarms might use a louder sound and be presented in a livelier or brighter display than those of low or medium priority.

It may also be important to define a class of less important alerts that, like alarms, are intended to convey useful information, but not to signal a life- or safety-related situation. These might also include presentations about expected events occurring within the control system about which the user should be aware. Treating some reporting as less-than-alarm importance can reduce requirements for redundancy, with significant cost savings in engineering, testing, and manufacturing.

Sounds

Sounds for alarm subsystems should be tailored to work in their intended environments: loud sounds for noisy backgrounds, and softer sounds for quiet environments, or for situations in which a patient might be inappropriately startled. Alarm sounds can start out at a low volume, to be silenced when acknowledged, and increase in volume until then. Low-priority alarms might not have any sound associated with them, while medium-priority alarms might use a soft chime tone. Some alarm systems even use prerecorded speech to get attention, as in an airplane's notification on final approach, for example, “Your wheels are not down.” 

Multiple-Sensor Alarms

Most alarm systems function with a collection of individual sensors that monitor one variable and compare the value with a fixed limit. When the measured value exceeds the limit, an alarm sounds and a light flashes, or perhaps a message appears. The sound can usually be turned off by a button push. When the measured value drops back below the limit, the message disappears or the light goes out. A user needing to report on measurements from 50 different sensors might use 50 backlighted messages or a computer-controlled display with 50 possible messages. There are many options.

But such a system does not explain the sequence of the alarm conditions. It is often important to know which condition arose first. So, a user looking at a field of 50 indicators, in which 12 are blinking, would get no sequence information. One possible solution would be to use a faster blink rate for the first alarm to occur. But many possibilities and hardware configurations could address these important issues.

There are three events shown in Figure 1 that might be logged to a printer or to an event record. 

• The fact and time of occurrence of the high-limit violation fault.
• The fact and time of acknowledgement of the alarm.
• The fact and time of clearing of the fault condition.

Note also that the hysteresis line represents a value that is used to decide when to leave the fault state and return to normal. The alarm state does not return to normal when the measured value drops below the alarm limit; the value must go a little bit lower. This lower return-to-normal limit prevents nuisance reports of new alarms when a noisy measured value alternates from just above to just below the fault level.

Deviation Alarms

Systems that use automatic feedback control of measurements such as flow, pressure, temperature, or position sometimes employ alarms to report the controller's failure to maintain the desired set point value. The set point defines the alarm limits, usually as a fixed value added to the set point for the upper limit and a fixed value subtracted from the set point for the lower alarm limit. Other possibilities include limits that are proportionally wider as the set point gets larger.

Variable and Computed Alarm Limits

Sometimes, changes in external conditions affect the latitude that should be given for a measured value. Thus, there may be a need to perform computations using several measured values to arrive at reasonable limits for fault detection. One example might be the amount of pump power needed to maintain a flow of a fluid where the viscosity of the fluid changed with temperature. The alarm subsystem might measure flow, temperature, and motor supply voltage, and then compute a reasonable upper and lower alarm limit for motor current.

Some of the options for fault detectors include differing degrees of contact debounce, analog and digital filtering of continuous measurements, and measurement of peak-to-peak amplitude. Hysteresis, or deadband, is important for reducing the unwanted repetitive triggering of an alarm from a jittery signal. Sometimes alarms are based on the difference between two measured variables, or a comparison of a measured variable with a computed limit. Other possible strategies include limiting the number of times a measured variable exceeds a limit in a sliding time window, or the length of time a variable is outside of a limit. Strategies that minimize false alarms sometimes slow down the initiation of the alarm at the same time. In general, a very reliable alarm system is desired, since equipment users quickly learn to ignore false alarms and then often end up missing important alarms.

Fault Event Logging

Some devices are just not complex enough to warrant logging of event information. Others may benefit from a simple Flash memory record of a few events, such as an identifiable failure of some subsystem. Still others will need time- and date-stamped records of alarms and events such as start-up, shutdown, and commands to change operations. These can be maintained in memory in the device, sent to a local printer, or transmitted to another computer. Whatever the complexity of the logging requirements, it is always best to separate logging of alarms and events from the visual presentation of alarm status.

Alarm Displays

While some systems may depend on a single blinking light to signal an alarm condition, others may need very sophisticated graphic displays, and any of them might use complex strategies for some of the fault detectors.

Various types of displays can enhance the presentation and comprehension of meaningful information about faults. One traditional industrial alarm display method, shown in Figure 2, employs text engraved into backlit rectangular plastic panels that light up. These effectively show the exact present state of many measured variables in parallel, and enhance rapid comprehension when the operator learns the meanings of the positions through frequent use. First-out alarm indication can be done with a different rate of flashing, or with different colors using a color graphic display.
A multiline text display can be used to present a list of alarms that are active, as shown in Figure 3. The first one to occur would be on the first line of the display, while the subsequent alarms would be displayed in order of occurrence. One option would be to have unacknowledged alarms blinking, where pressing the acknowledge button would change the line from blinking to steady. One can also include the alarm limit value on the line along with a current measured value. When the screen fills, it could be scrolled automatically so that the most recently added alarm would be on the next to the bottom line of the display. Scrolling up and down through the list would enable viewing of a list too large for the display, and a means to remove items from the display could account for problems with sensors or other changes in conditions. More-sophisticated computer-controlled displays can mimic backlighted panels and add touch screen–driven means to jump to a graphic strip-chart-style display of real-time data.

Alarm messages that are clearly worded in the user's terminology, rather than in engineering jargon, can increase user comprehension. Consideration should be given to the possible need for multiple languages, and how this will be supported with the embedded computer. Settling these issues early makes alarms less costly to develop. Symbols used should be chosen from prevailing standards, such as IEC 60878:1988—Graphical symbols for electrical equipment in medical practice, ANSI/AAMI/ISO 15223:2000—Medical devices—Symbols to be used with medical device labels, labeling and information to be supplied, and ISO 15223:2000—Medical devices—Symbols to be used with medical device labels, labeling and information to be supplied.

Beyond the Simple

Combining alarm event recording with the recording of other significant events can yield a rich source of diagnostic help. Other, more-sophisticated analytical tools can be employed to reduce the welter of alarm events into more-meaningful communication with a human operator. Analysis of sequences of alarms can yield root causes.

For example, if 12 alarms are generated nearly simultaneously, all having to do with a reduced flow condition and side effects, it may be possible for the computer to recognize a pattern and report that the real problem is a nearly discharged power-supply battery that should be replaced. Without the machine-assisted analysis of the pattern, it could take an operator a considerable amount of time to try to absorb all the information and perform the same analysis. 

Complexity reduction, described by Riley in an article about pilot interfaces, can provide a tremendous aid to users' rapid alarm comprehension.² If an alarm is easy to recognize quickly and without effort, it might be noticed and handled appropriately. Unfortunately, the most likely response to alarms in an anesthesia and surgical context has been to ignore them.³ Creating better alarm systems may bring tremendous opportunities and newly perceived responsibilities to medical device designers.

Product developers defining alarm subsystem requirements need to be aware of and consider all of the options that are available, so that the end product serves users well. Considering the experiences of users of existing products is useful in avoiding repetition of mistakes. Using previously developed methodologies that have been embodied in published standards as a starting point is a good way to ensure that all the bases are covered in a new medical product specification.

References

1. Annunciator Sequences and Specifications, ANSI/ISA-18.1-1979-(R1992) (Arlington, VA: Association for the Advancement of Medical Instrumentation, 1979).
2. Victor Riley, “A New Language for Pilot Interfaces,” Ergonomics in Design 9, no. 2 (2001): 21–26.
3. Jacob F Seagull and Penelope M Sanderson, “Anesthesia Alarms in Context: An Observational Study,” Human Factors 43, no. 1 (2001): 66–78.

Bibliography

Association for the Advancement of Medical Instrumentation Web site: www.aami.org/index.htm. 

Maddox, Michael E. “Designing Medical Devices to Minimize Human Error.” Medical Device & Diagnostic Industry 19, no.5 (1997):166.

Szakonyi, Robert, ed. Technology Management. Boca Raton, FL: Auerbach, 1998.

Wiklund, Michael E and Eric A Smith. “Answering the Call for Harmonization of Medical Device Alarms.” Medical Device & Diagnostic Industry 23, no.10 (2001):118–125. 

Copyright ©2003 Medical Device & Diagnostic Industry