Reducing Interruption Fatigue with Advanced Alarm-Safety Middleware
Reducing Interruption Fatigue with Advanced Alarm-Safety Middleware
By Mary Jahrsdoerfer, PhD, RN; and Brian McAlpine
PHOTO CREDIT: www.123RF.com
In a report by the National Academy of Sciences, caution is drawn to system-related issues surrounding the nurse-work environment, stating that interruptions of nurse-work processes may compromise patient safety (Page, 2004). Despite this concern, studies demonstrate that interruptions to clinical workflow are quite common (Beyea, 2007; Alvarez & Coiera, 2005; Tucker & Spear, 2006; Hall, Pedersen, & Fairly, 2010). Exemplary technologies exist to facilitate the delivery of patient safety. However, many value-demonstrated technologies related to alarms and communication, though available to nurses, are underutilized (Henneman, 2012). The purpose of this article is to demonstrate how alarm middleware addresses the issue of “interruption fatigue” in hospitals today.
The Joint Commission’s National Patient Safety Goal 06.01.01 specifically addresses medical device alarms, however there are more sources of interruptions than alarms. Interruption fatigue expands on the concept of alarm fatigue by focusing on noise in the patient room and on the floors as well as frequent non-alarm based nursing interruptions.
Background: Looking Back at 2007, a Pivotal Year
The concept of a comprehensive, vendor-neutral approach to alarm middleware is now approaching the 10-year mark since industry pioneers originally proved the efficacy of such a solution. Many advances have occurred in that time period, and in fact, some of those advanced concepts were discussed in this publication more than eight years ago (Gee, 2007):
- Meaningful improvements in patient safety at the point of care require that alarms become more clinically significant and are presented to caregivers more effectively.
- A patient-centric approach is required to deliver patient safety improvements.
- Alarms must be truly actionable to improve care coordination and patient safety. The integration required for improved coordination goes beyond a single parameter and its normal values. It must evaluate parameters within the context of other parameters derived from other devices and data from information systems.
As the article suggests, these concepts were not available in any commercial solution back in 2007. Largely based on these forward-thinking theories, however, the foundations for the next generation of alarm safety middleware were already being developed.
Alarm Middleware |
|
Middleware is software that enables communication and data management between two different systems. In the case of managing alerts and alarms, alarm middleware enables communication and management of alarms and provides ancillary notification of alarm signals directly to caregivers, often via mobile communication devices. Alarm middleware performs critical functions, such as:
|
Also in 2007, Apple was preparing to release the modern smartphone (“History of the iPhone,” 2015). While smartphones became a universal means of communication in most settings, only recently have they begun to change the face of clinical communications and alarm management. Smart applications provide a more collaborative team response for clinicians responding to the alarms and events. This unified clinical workflow translates to prospective patient-safety processes.
A study published recently but conducted in 2007 describes the incidence and types of nursing interruptions that occur in a level-one trauma center (Sorensen & Brahe, 2014). Considering the findings from this study and potential impact to patient safety, it may seem surprising that not a lot has been done in hospitals to address many of the problems uncovered in this study. One reason is because the technology had simply not advanced enough to enable new approaches and solutions. Another reason is because the alarm fatigue problem was never really solved by early alarm middleware systems. Evidence of this comes from the hundreds of early deployments of alarm management systems and their lack of progress in solving alarm fatigue.
These early systems were mainly designed to address the original Joint Commission National Patient Safety Goal for audible alarms. The problem identified in 2003 was that the alarm was not audible in all areas of patient care (Phillips, 2006). This is clearly a different problem than alarm fatigue. In many instances, hospitals addressed problems related to audible alarms, which over time resulted in an unintended side effect: alarm fatigue became a more serious problem. As a result, the industry has made this a national priority due to the criticality and lack of progress in addressing alarms.
Looking back, 2007 proved to be an important year in the evolution of alarm management. In order to develop an advanced alarm middleware system, all of these concepts, information, and even workflow-enabling technology such as smartphones have to be taken into account.
Alarm Middleware—An Evolving Definition
The generally accepted industry definition of basic alarm middleware includes software that directs notifications of actionable alerts or alarms from multiple sources to caregivers via end-user communication devices. The goal is to get relevant alerts to the appropriate caregiver in a timely fashion to enable clinical decisions (AAMI, 2014). In support of the Joint Commission’s National Patient Safety Goal NPSG.06.01.01, the main issue addressed is the well-known problem of alarm fatigue (“The Joint Commission announces,” 2013). The focus is placed on notification to the caregiver to ensure awareness that a critical event has occurred. Often an alternate name for this middleware is “secondary alarm notification systems,” with the understanding that medical devices are the “primary” sources of alarms (i.e. the audible alarms) and the communication of the occurrence of the alarm to a caregiver is considered a second level of notification.
The distinction between primary and secondary alarms is largely related to FDA 510k regulations and how vendors achieve regulatory clearance for their medical devices and alarm notification systems. However, looking beyond medical device alarms and considering alerts such as nurse call and critical lab results—which are not regulated by the FDA—the notification is often sent as a primary means of notifying the caregiver or even a care team.
Because of advances in technology and new approaches in recent years, the definition for alarm management is now being expanded to include event response. Event response is important to consider because the alarm or critical patient event lifecycle is not complete until a qualified caregiver has arrived in the room, responded to the patient, and acknowledged the alarm or alert. Early alarm systems often sent all alarms to the nurse regardless of the type or severity of alarm. This human recognition, as a required response to the technology system that generated the event, is what in fact has added to clinical interruption fatigue. Also recognize that someone other than the primary nurse may be the recipient of a communicated event (even if verbal). Responding to this event, they must now communicate their actions to the patient’s primary nurse.
More important is enabling an easy way for clinicians to communicate and collaborate among other care team members in response to the alarms. This is all considered part of event response, and clearly the trend is to enable caregivers to collaborate using smartphones they each carry.
Interruption Fatigue—More Than Just Alarms
The Joint Commission’s definition of alarm fatigue is limited to medical device alarms and does not include nurse call events, alerts generated by the EHR, labs systems, or general IT systems (“Alarm system safety,” 2013). To date, hospitals have conducted numerous studies focused on collecting and analyzing baseline alarm data as part of efforts to determine where to begin addressing the alarm fatigue problem. Results from additional studies continue to be released periodically. However, when you examine the results closely, the studies basically say the same thing: alarms are a big problem.
Additional baseline studies at this point are not expected to yield different results except for minor variations in alarm counts derived from different types of care environments. Hospitals are still interested in collecting their own baseline alarm data because it gives them a starting point for process improvement. There is a bigger problem, however, that needs to be addressed related to clinical interruptions.
By definition, medical device alarms are considered an interruption. But so are many of the alerts that are generated by the other systems, such as nurse call. On top of all of the medical device alarms and system-generated events causing interruptions, there is also the problem of noise and distractions caused by overhead paging systems and environmental noise generated by phones ringing and other equipment commonly found in proximity to the patient (Figure 1).
 |
|
| Figure 1: Interruption fatigue includes alarms, distractions, and nursing interruptions. |
A study published in the Journal of Clinical Nursing (Sorensen & Brahe, 2014) describes interruptions to clinical nursing practice as being much more frequent than those caused by medical device alarms. The study states that a nurse’s colleagues are responsible for more than one out of three interruptions and cause nearly twice as many interruptions as the next highest source of interruption, which comes from other staff members, including peripheral and administrative staff. The study also examined the cause of interruption, including “questions,” “need information,” and “need help,” all of which occur at a higher incidence than alarms and calls.
Many of these interruptions would be eliminated if nurses were enabled to unobtrusively collaborate among the care team using secure messaging on smartphones. With secure messaging, a nurse’s colleagues and other caregivers would still be able to get responses to questions; because text messaging is asynchronous it does not have to cause an immediate interruption. If you add in the “other persons,” students, and doctors, a fairly significant number of interruptions can be eliminated. The reality is that because alarms are only a subset of the overall problem, it is very possible to solve alarm fatigue and still be left with a significant interruption fatigue problem.
 |
|
| Figure 2: An example of an alarm displayed on legacy phone device. | |
 |
|
| Figure 3: An example of an integrated alarm and messaging app running on a smartphone device. Note that alarms, alerts, and messages are always listed in priority on one screen order to ensure safety. |
User Experience Is Key
The clinical user experience may not seem all that important during the early stages of evaluating solutions. However, the traditional user experience for enabling an efficient and collaborative event response has been less than optimal. This is partly due to the limitations of the user interface on legacy phone devices. Secure texting is not all that practical where 10-key typing is the norm (Figure 2). Also, some hospital-issued phones require the user to press up to five buttons simply to acknowledge an alarm or event.
Because there were no viable alternatives prior to smartphones, clinicians had to live with these legacy devices or go without. It is fair to state that when used solely for receipt and acknowledgement of alarms, legacy devices have proven to be adequate for many use cases. But with smartphones, this is all changing. Increasingly, hospitals are looking beyond “receipt and acknowledgement” features and are also focusing on enabling care team collaboration as one of the key capabilities.
In order to avoid recreating these same legacy-device issues on smartphones, hospitals should map out a plan for the clinical end user’s full experience. Once a hospital gets deeply into an implementation of smartphone-based point-of-care applications, the user experience is the only thing that will matter. No matter how good the device, without a well-designed and integrated application that combines alarm management with patient-centric secure messaging, and the ability to seamlessly link to other apps running on the device (Figure 3), the hospital will risk having little or no widespread adoption of new smartphone-based technologies.
Designing Advanced Alarm Middleware – A Paradigm Shift
Designing a next-generation system for managing alarm and event response involves a few key principles:
- The approach needs to focus on the ability to aggregate and store data from multiple sources and provide access to all data to hospitals for alarm-safety improvement.
- The system’s design has to be patient-centric and intuitive for nurses to use.
- The system design must promote clinical collaboration and easy access to the right care team members without searching through large directories.
- The system needs to be able to take advantage of all types of contextual data in order to present intelligent alarms to clinicians and ensure efficient event response.
- The system must be able to simultaneously process alarms and alerts from multiple data sources and automatically apply advanced rules “on the fly” to those alarms.
- The system needs to integrate patient-centric secure messaging capabilities to ensure interruptions from alarms, alerts, and messaging can be linked to the patient, prioritized, and managed well from a clinician’s perspective. Given that text messaging on smartphones is easy and pervasive, support for smartphones needs to be a core feature.
- And finally, the system needs to have FDA 510k clearance to enable medical device alarms to be integrated along with all of the other interruptions.
Conclusion
The current state of patient care and clinical workflow is extremely demanding in today’s hospital environment. The consequences of technology advancements in clinical decision support often burden clinicians with additional response times or interruptions, in part because nurses must physically go to the technology itself to acknowledge the event triggered. The question should be posed: if the clinicians are mobile, shouldn’t the technology be as well? Middleware accomplishes this task, bringing technology to the clinician on the run, allowing team communication and collaboration. It is a new era of patient care.
An Example: Putting It All Together |
| A nurse has received several events or messages on his or her smartphone (Figure 4). Alarms are always highest priority and will appear automatically at the top of the main screen. With a swipe of the screen the user can access a care team list that is generated “on the fly” that is specific for each patient and event. Once selecting one or more care team members to collaborate and with another swipe of the screen, any event can become context for a text-based conversation with those care team members. Care-team members receiving the message will instantly know the situation and relevant background information about the patient.
From a usability perspective, the user does not have to type key context in order to establish effective communications. For example, for the smart bed alarm listed the nurse receiving the alarm simply has to type or select from a list of preconfigured messages – “need assistance.” The message recipient automatically knows the patient name, room number, admit diagnosis, fall risk score, and any other information that could be included to assist with event response. There is no need for the busy nurse to type the patient’s room number or name into the message and this saves valuable time during a critical event response. |
 |
| Figure 4: an example of a simxperience for managing critical alarms and events with the ability to collaborate with the patient’s care team. |
Both authors work at Extension Healthcare. Mary Jahrsdoerfer is chief nursing officer, and Brian McAlpine is vice president of product management and marketing. McAlpine may be contacted at BMcAlpine@ExtensionHealthcare.com, and Jahrsdoerfer can be contacted at MJahrsdoerder@extensionhealthcare.com.
References
Alarm system safety. (2013, December 11). R3 Report, 5, 1–3. Retrieved from http://www.jointcommission.org/assets/1/18/R3_Report_Issue_5_12_2_13_Final.pdf
Alvarez, G., & Coiera, E. (2005). Interruptive communication patterns in the intensive care unit ward round. International Journal of Medical informatics, 74, 791-796.
Association for the Advancement of Medical Instrumentation (AAMI). (2014, January 28). Use of middleware in alarm management: Ancillary notification and obtaining alarm data. Retrieved February 11, 2015, from http://www.aami.org/meetings/webinars/HTSI/resources/01282014_slides.pdf
Beyea, S. (2007). Distractions, interruptions and patient safety. AORN Journal, (86), 109-112
Fourth alarms webinar examines use of middleware. (2014, March). AAMI News, 49(3). Retrieved from http://www.aami.org/publications/AAMINews/Mar2014/Alarms_Webinar_Middleware.html
Gee, T. (2007). Trends in point-of-care alarm notification. Patient Safety & Quality Healthcare, 4(1). Retrieved from http://psqh.com/janfeb07/pointofcare.html
Hall, L. Pedersen, C. & Fairly, L. (2010). Losing the moment: Understanding interruptions to nurses’ work. Journal of Nursing Administration, 40(4), 169-176.
Henneman, E. (2012). Patient safety and technology. AACN Advanced Critical Care, 20(2), 128-132.
History of the iPhone. (2015, March 16). In Wikipedia, The Free Encyclopedia. Retrieved March 17, 2015, from http://en.wikipedia.org/w/index.php?title=History_of_the_iPhone&oldid=651578424
Page, A. (2004). Keeping patients safe: Transforming the work environment for nurses. Washington, DC: National Academy of Sciences.
Phillips, J. (2006). Clinical alarms: Complexity and common sense. Critical Care Nursing Clinics of North America, 18(2), 145-156.