Reducing Alarm Hazards: Selection and Implementation of Alarm Notification Systems
March / April 2011
Reducing Alarm Hazards: Selection and Implementation of Alarm Notification Systems
Few threats to patient safety have existed for as long or been as thoroughly studied as alarm fatigue (Healthcare Technology Foundation). In December 2010, ECRI Institute listed “Alarm Hazards” as the second highest technology hazard of 2011. Alarm hazards include inappropriate alarm modification, alarm desensitization or alarm fatigue, non-restoration of alarm settings to the normal or standard value after being modified for a specific situation, and improper relaying of alarm signals to appropriate personnel (ECRI Institute, 2010).
Additionally, with the evolution of stand-alone devices to proprietary end-to-end systems, there is a proliferation of overlapping and duplicate systems. This ends up in clinicians sometimes carrying a “bandolier” of communication devices. Most alarms and other messaging are simply broadcast throughout the unit via distributed speakers and message panels.
Noisy overhead paging systems can cause nurses to miss calls – particularly when working within patients’ rooms. In addition, most point-of-care staff members have multiple devices – a nurse often carries a pager, PDA and a mobile phone, with each device providing specific functionality and generating its own alarms (Rawson, 2010).
Healthcare providers must investigate and report sentinel events. Risk management departments of healthcare providers routinely suffer from a lack of information regarding incidents, and disparate systems can complicate the investigation and reporting processes. This lack of information or conflicting information from disparate systems can become a medical-legal risk (Iyer, 2011).
Alarm notification problems can be divided into two categories: 1) problems of being aware of alarms and 2) alarm fatigue or desensitization. Hospitals have used remote speakers and message panels for many years to reduce the problem of hard-to-hear alarms. Some hospitals have put considerable effort into testing the loudness of local alarms on medical devices located in patient rooms to ensure that alarms are always heard. Alarm fatigue is a desensitization to alarms that results from over stimulation. Factors contributing to alarm fatigue include loudly broadcasting all alarms throughout the entire unit, false positive alarms, overhead paging, nurse call systems, and other noise generators. To reduce some of this over abundance of noise, many hospitals have replaced overhead paging with nurse-carried wireless phones.
Alarm notification systems reduce alarm fatigue and improve patient safety by:
- sending alarms and messages directly to the responsible caregiver, rather than everyone on the unit;
- sending alarms to a mobile device like a phone or PDA that alerts the user but does not disturb patients or other staff;
- providing appropriate alarm context, like waveforms, so users can quickly and reliably identify false positive alarms;
- providing closed-loop communications to ensure that alarms are received and acknowledged; and
- automatically escalate alarms to appropriate staff to ensure timely alarm responses.
Properly implemented, an alarm notification system can eliminate alarm fatigue and reduce failure-to-rescue type sentinel events to near zero.
Needs Assessment and Purchase Requirements
Every clinical environment is unique, based on patient population, staff backgrounds and training, policies and procedures, and the environment—especially information systems, equipment, and medical devices used at the point of care. Consequently, there is no boilerplate request for proposal or list of requirements that are best for all situations. Buyers must identify their own requirements. A risk analysis is a great tool to define requirements for an alarm notification system. All of the risks associated with generating and responding to alarms are identified in this process. Each risk identified, and how they may be mitigated, become specifications that can be compared between vendors. The risk management process described in ISO 14971 provides a good template for a hospital risk analysis of alarms.
The risk analysis should encompass information and communications technology, medical devices, clinical practice, policy, and procedures.
A survey of each target care-delivery unit should document existing alarm sources, configuration policy and procedures. The medical devices that are sources of potential alarms must be cataloged (manufacturer, model, and firmware release) to ensure that prospective alarm notification systems have interfaces to capture alarms and relevant associated data. Due to the proprietary nature of medical device data communications protocols and medical device system architectures, alarm notification systems may integrate directly with medical devices, through a gateway device from the medical device manufacturer or third party, or not at all. The configuration of these interfaces can be complex, and sufficient focus is required to determine how different alarm notification systems achieve integration.
Besides using this data to define medical device integration requirements, it is important to normalize policies and procedures across units to facilitate implementation of the alarm notification system. This data also defines important alarm notification requirements to be met by a prospective system. The workflow for basic activities must be documented, including nurse-to-patient assignments, taking report at shift change, and coordination with any rapid response teams. Special attention to both the various roles of staff, any information systems used, and the actual sequence of events are important. Alarm escalation policy across units is another key metric to be captured for use as purchase requirements. Any of the above items that do not already exist in current operations should be developed prior to or along with the selection of an alarm notification system.
Life-critical applications, such as alarm notification, require sufficient monitoring and response requirements for the alarm notification system itself, related IT infrastructure, related medical device systems, and end-point computing devices (e.g., phones, PDAs, portable computers). System monitoring and response requirements should fall out of a thorough risk analysis and review of existing policy. Many alarm notification vendors have experience and can offer advice that should be considered. But, relying too heavily on a system vendor can result in policies, procedures, and workflow that are a great fit with their solution, but perhaps a less than ideal fit for the actual operation of clinical areas.
Implementation Considerations
Alarm notification systems are typically deployed across multiple patient care units, and often enterprise wide. These wide deployments transform alarm notification systems from departmental to enterprise applications. A key implementation issue with enterprise applications is system configuration. When policies and procedures are consistent and normalized across the enterprise, the easier—and quicker—it is to implement enterprise applications. Before the advent of alarm notification systems, there was no real reason to look at variations in alarm policy and procedures across the different care delivery areas in a hospital. A common implementation phase for alarm notification systems is to evaluate, harmonize, and document alarming issues across units. Specifically, alarm configuration for all the medical devices used on units should be reviewed to ensure that alarm classification, default alarm limits, and standing orders for alarms are consistent where possible. Refinements resulting from such a review can themselves result in reduced alarm fatigue (Graham & Cvach, 2010).
Likewise, the policies and procedures for adverse and sentinel event investigation and documentation must be normalized so that the alarm notification system can consistently support these investigations across the enterprise.
Post-installation, the ease and flexibility of day-to-day alarm notification system configuration can be an important differentiator between alarm notification systems. As noted above, getting alarms to the appropriate caregiver and ensuring appropriate alarm responses are key benefits of alarm notification systems. Nurse-to-patient assignments are a key task that must occur on each individual care delivery unit, at each shift change. The frequency of this task and the patient safety necessity of completing it correctly (so each patient’s alarms are properly routed to the most appropriate caregiver) make this process another potential differentiator between alarm notification solutions. The alarm notification system’s workflow for nurse-to-caregiver assignments must be consistent with the actual shift change processes that are used in each unit. Alarm escalation capabilities must also align with the alarm escalation policy for each unit.
The actual data that is conveyed to caregivers in alarm notifications must be reviewed and configured as necessary. Alarm notification systems vary in their ability to tailor alarm messages. Some messages may be fixed, while some alarm messages will be configurable. Configurable alarm messages may be provided with system defaults. These alarm message defaults should be reviewed and revised when it is determined that a change will improve the effectiveness of the alarm notification system’s use in the hospital. Message data can include text captured from the medical device, text generated by the alarm notification system, and graphical data. Graphical data can represent a patient’s basic clinical status, like a traffic light does, with green, yellow, and red lights. Graphical data can also include waveforms captured from the medical device that can be critical to determining if an alarm message represents a false positive or a true positive alarm.
Most alarm notification systems include a rules engine-like functionality where a situation is analyzed by the system using logical statements or conditions configured into the system. A common example of this is the messaging engine that determines the proper routing of a message or alarm, to ensure that the correct recipient receives the message. Alarm or message escalation is another common rules engine type of configuration. Alarm notification systems can vary considerably in how rules are defined in the system, both in the ease of configuration and the power and flexibility of the resulting rules. System defaults provided with the system and the ability to load rules or configuration files from the manufacturer or other sites also differentiate vendors’ systems.
Besides per-shift configuration of nurse-to-patient assignments, the alarm notification system requires basic messaging engine configuration that includes both user and messaging device associations. The system must be loaded with all the potential recipients of messages or alarms, in addition to knowing how to address each potential messaging device that may be assigned to a user. Messaging devices, such as pagers, wireless VoIP handsets, PDAs, smart phones, desktop or portable computers, must interact with and be available to the alarm notification system. Some systems provide interfaces to enterprise directories like LDAP or RADIUS (Wikipedia), that provide access to user information such as name, title, department, and IT logins and passwords. As important as knowing who may receive alarms is being able to reach each specific user through their assigned messaging device. Thus, the messaging engine must also associate a user with the correct device through which each potential message recipient would receive, display, and respond to an alarm. Another differentiator for alarm notification systems is how well the system supports the association between users and messaging devices and the ability to manage the way messages are displayed and the user’s ability to respond to messages across different messaging devices. Another important variable is how messaging device systems, such as wireless VoIP phone systems make this user-to-device association data available to alarm notification systems.
Advanced Features
Some alarm notification systems offer advanced features. A common advanced feature is the ability to acquire and use positioning data from real-time location systems (RTLS). This data can include the location of the patient or medical device that is alarming, and the location of potential messaging recipients (to enable alerting the closest appropriate user). Location data can also contribute to adverse or sentinel event reviews, provided that data from the alarm notification system and RTLS can be synchronized by time, allowing the review of alarms and messaging with the locations and actions of patients, devices and users. Sentinel event capture and reporting is another advanced feature available with some alarm notification systems. This data can be available as cryptic log files, or more user-friendly descriptions of events and messages over time.
Nurse-to-patient assignments is an association that is important to an increasing number of systems at the point of care. A careful evaluation of different systems needing this information, how it is captured in each system, and the ability to share this association data across systems from different manufacturers is an emerging advanced feature. At the present time, providers should expect to enter these associations repeatedly into multiple systems. But manufacturers should be pressured to work together to make this data interoperable across systems.
The most advanced alarm notification feature is the decision support system (DSS). The DSS feature can provide alarm normalization across different manufacturer’s devices; this can be particularly useful with ventilators. Another form of DSS-generated alarm normalization captures alarms produced from different medical devices attached to the same patient that result from the same physiological change. These seemingly separate alarms are actually duplicates resulting from the same physiological change in the patient, and the duplication of these alarms can contribute to alarm fatigue. Another emerging DSS feature is support for automated therapy protocols. In this example, the DSS can initiate messages to caregivers or clinicians based on messages received from external diagnostic systems or patient-connected diagnostic devices. Tight glycemic control is a therapy protocol getting a lot of attention from manufacturers and clinicians. At some point in the future, this type of DSS application will include medical device interoperability.
Potential Pitfalls
With any complex system of systems application, there are many potential pitfalls. An alarm notification system exists within a broader technology infrastructure that includes networking, end-point computing devices (computers, phones, PDAs, etc.), and other systems – especially nurse call, medical devices, and various HIT applications. Integration points, codependences, and synergistic features must be taken into account for every aspect of this fabric of systems and devices. Alarm notification systems create a new set of requirements for these other systems that must be met if the full potential of alarm notification is to be achieved and maintained over time. This broader system-of-systems technology management is an extension of the kind of life cycle management currently practiced at most hospitals.
Alarm notification systems are functional extensions of the medical devices that generate the alarms, and as such are themselves medical devices regulated by the FDA. With the publication of the final MDDS rule (Gee, 2011), FDA signaled a shift to enforcement discretion regarding alarm notification systems. Those manufacturers that are not currently regulated appear to be moving into compliance. A manufacturer’s compliance strategy is an important purchase criterion for alarm notification systems. Similarly, as regulated medical devices comingle on the hospitals enterprise IT infrastructure, that infrastructure becomes part of a regulated medical device and must be managed accordingly. Consequently, buyers need their own compliance strategy that takes into account standards like IEC 80001 (Gee, 2008) and a review of IT governance to ensure that policies and procedures are appropriately revised to ensure patient safety with life critical systems.
As with any system-of-systems, there will be unexpected behaviors or failures, and it will be important to have back-up clinical procedures. Usually this will involve an increase in personnel to ensure sufficient nursing vigilance is maintained. When technical and infrastructure requirements are developed for the system, it is important to identify the impacts of failure in operational and financial terms. This may ensure that a proper availability and reliability for the system design is attained. Of course, back-up procedures need to documented and practiced.
Some clinical staff may have a negative reaction regarding being “tracked” by this technology. It will be imperative for management to work with the staff regarding expectations of both the staff and the technology. Having clear policies regarding staff-to-patient assignments, policies for alarm setting, triage, and response expectations should foster an appreciation for the technology and its contribution to improved patient safety. Anecdotally, there have been benefits noted for a logging feature of an integrated system showing a patient’s family that their loved ones have been attended to.
Tim Gee is principal and founder of Medical Connectivity Consulting (MCC) (www.medicalconnectivity.com). Gee’s practice revolves around workflow automation through the integration of medical devices with information systems, and enabling technologies. MCC advises healthcare providers and manufacturers on needs assessment, requirements, workflow and patient flow analysis, regulatory issues, product development, sales, and marketing. Markets covered include both acute and ambulatory care. Gee is currently the program chair and principal organizer for the Medical Device Connectivity conference and serves on the editorial advisory boards of a number of publications including Patient Safety & Quality Healthcare. He may be contacted at tim@medicalconnectivity.com.
Bridget Moorman is president of BMoorman Consulting, LLC (www.bmoorman.com). She has 21 years experience in the clinical engineering field doing strategic technology management and medical device interfacing to EMRs. She has consulted for medical device companies, third party device integration companies, information technology companies, standards promulgation organizations, and healthcare providers. In addition to her clinical engineering experience, she has done bio-mechanical research, power-line relay/metering design, and space system acquisition/launch/ground systems/telecommunications work. Moorman may be contacted at bridget@bmoorman.com.
References