Enhanced Notification of Critical Ventilator Events

Abstract

Mechanical ventilators are designed to generate alarms when patients become disconnected or experience other critical ventilator events. However, these alarms can blend in with other accustomed sounds of the intensive care unit. Ventilator alarms that go unnoticed for extended periods of time often result in permanent patient harm or death. We developed a system to monitor critical ventilator events through our existing hospital network. Whenever an event is identified, the new system takes control of every computer in the patient's intensive care unit and generates an enhanced audio and visual alert indicating that there is a critical ventilator event and identifies the room number. Once the alert is acknowledged or the event is corrected, all the computers are restored back to the pre-alert status and/or application. This paper describes the development and implementation of this system and reports the initial results, user acceptance, and the increase in valuable information and patient safety.

While little literature exists on the specific hazards and duration of ventilator events, medical personnel know the potential morbidity and mortality that can result when ventilator-dependent patients experience critical ventilator events for an extended period of time. All ventilators are now designed to detect critical events and are equipped with alarms. However, these alarms are only audible peeps that often are difficult to hear outside of the patient's room. Moreover, the large number of false-positive alarms generated by bedside monitoring devices exacerbates this problem because ventilator alarms can blend in with other accustomed sounds of the intensive care unit (ICU).¹ As a result, some critical ventilator alarms go unrecognized for periods of time that result in permanent patient harm or death. In 2002, the Joint Commission on Accreditation of Healthcare Organizations published a new Sentinel Event guideline aimed at preventing ventilator-related deaths and injuries.²

Background

Early studies on ventilator events during the 1960s and 1970s stressed the need for alarms, and a few third-party alarms were developed that could be attached to most types of ventilators as “add-on” devices.^3,4,5,6,7,8 Subsequently, ventilators were developed with disconnection and other types of alarms built in. However, a 1980 study evaluated the use of 13 commercial ventilators with alarms, and only two could be recommended for general ventilator use and three others as disconnection alarms.^{9,10,11,12,13} A later study highlighted five new ventilators that used microcomputers to improve the alarm capabilities.¹⁴ This led the National Aeronautics and Space Administration to develop a computer algorithm to be used on ventilators on the space station that would enable untrained users to manage the mechanical ventilation of critically injured crew members.¹⁵ Still, reports of ventilator alarm failures continued, and in 1989, Spacelabs developed a computer program to monitor patients on Puritan-Bennett 7200 ventilators that not only performed initial status checks, but periodically polled the status of the ventilator.^16,17,18,19 Knowledge-based alarm systems have now been developed using mathematical modeling that have been shown to correctly classify 99% of clinical events.²⁰

The literature on ventilator alarms is divided by ventilator use in the ICU and ventilator use in the surgical suite during anesthesia. A number of studies and advancements in the safety of ventilators were targeted at their use during anesthesia.^21,22,23 The only study to measure response times to alarms was conducted to see whether anesthetists responded more quickly to visual or auditory alarms.²⁴ As expected, the response times to auditory alarms was significantly shorter than visual alarms since visual alarms required the anesthetists to be looking at the monitor in order to see the alarm. However, a study of 64 anesthetists assessed ten common operating room alarms for perceived urgency and only 33% were correctly identified.²⁵ The extension of monitoring with these results to a large and busy ICU setting would not lead to an increase in the correct identification of alarms. In a study that focused on the complications of mechanical ventilation in the ICU, the repeated sounding of ventilator alarms (false-positive alarms) was a major reason why clinicians are called to the bedside.²⁶ An Australian study of 2,000 incident reports identified 317 incidents that involved problems with ventilators and the majority (47%) were caused by disconnections.²⁷ A study to determine the predictive value of alarms from pulse oximeters, end-tidal Pco₂ monitors, ventilators, and electrocardiographs in a pediatric ICU found that 68% were false and the positive predictive value for ventilator alarms was only 3%.²⁸ Likewise, another study found that of 1,455 alarm soundings in the ICU, only eight (0.5%) indicated potentially life-threatening problems.²⁹

While the alarm systems built into all ventilators today have become very accurate at identifying critical events,^30,31 too often the resulting alarms go unnoticed for excessive periods of time. This results from a systematic problem that is outside the control of the ventilator. This may be due to the physical layout of the ICU, staffing limitations, staff complacency due to numerous false alarms, or environmental acoustics and noise. Another serious problem is when patients who are in isolation for infection experience a critical ventilator event. The closed doors can prevent hospital personnel outside the room from hearing or seeing standard ventilator alarms.^32,33 In some situations, the ventilator alarm is heard, but valuable time can be lost while the clinician tries to determine which patient or room in the unit activated the alarm.

Design Objectives

LDS Hospital in Salt Lake City, UT, is owned by Intermountain Health Care (IHC). LDS has created and evolved an electronic medical record (EMR) known as the HELP System over the past 30 years.³⁴ This EMR contains most patient clinical information including bedside charting by respiratory therapists.³⁵ While respiratory care charting has been part of the HELP System for 20 years, information pertaining to critical ventilator events was not included. If a patient was unintentionally disconnected from a ventilator or experienced another critical event, respiratory therapists were supposed to fill out a paper incident report describing the event.

However, these reports were usually not filled out and submitted. In fact, nurses or other medical personnel often were the first to respond to the ventilator events and sometimes the respiratory therapists were not informed of the event. Thus, important information on the number of and causes for ventilator events was incomplete. Moreover, the duration times of the events were usually unknown and not documented. Without this information, patient care improvement plans were difficult to create and evaluate. Respiratory therapy management was concerned with this situation and was constantly investigating a number of options to improve patient care.

In 2002, respiratory care management at LDS Hospital tested a new physiologic monitor interface to the ventilators in the shock/trauma ICU. The interface detected the ventilator alarms and sent them to the physiologic monitors at the central station. This approach was discontinued after a short time due to the fact that all types of ventilator alarms, no matter the type or severity, were sent to the central station. The volume of false-positive alarms was found to be overwhelming for the ICU staff. Others have tried this same approach and report similar results.^36,37 Based on our previous experience, we needed to find a method to notify medical personnel of critical ventilator events that was accurate, reliable, and instantly recognizable and did not report low-level ventilator alarms.

System Description

At the time of the study, LDS Hospital used the Puritan-Bennett 840 and 7200 mechanical ventilators. This ventilator manufacturer defines critical ventilator events as when less than 25% of the gas delivered by the ventilator is returned to the ventilator and classifies them as “ventilator disconnections.” Thus, the ventilator circuit may or may not be physically disconnected when a disconnection alarm is generated. ▶ lists common causes for a reduction in the amount of gas returning to the ventilator. We developed a new application on an external microcomputer, the Device Communications Controller (DCC), which is connected to the ventilators through an RS232 connection (▶). The DCC polls the ventilator every five seconds, and the ventilator sends current alarm and ventilator settings. The DCC then sends ventilator data, including whether the alarm silence button on the ventilator had been activated, to the bedside computer using the IEEE MIB 1073 standard.³⁸ A program written in C on the bedside computer accesses the HELP System to determine which room the computer is in along with other pertinent patient information. The bedside computer program parses the data string from the ventilator and attaches the patient room number. If the ventilator sends three consecutive disconnection alarms to the DCC and the alarm silence status of the ventilator is “off,” the bedside computer sends an alert to a central server through an Ethernet connection using TCP/IP. Because the DCC polls the ventilator every five seconds, the disconnection alarm on the ventilator must be active for at least ten seconds before the enhanced alert is generated. If the silence button on the ventilator is pressed by medical personnel (alarm silence) or the ventilator-disconnect alarm is no longer active, then a message is sent to the server to turn the alert off. Thus, three different messages are sent from the bedside computer to the server: (1) activate alert, (2) ventilator alarm was silenced, and (3) ventilator event was corrected. If the silence button is pushed on the ventilator and the disconnection alarm is still active for two or more minutes, an activate alert message will be resent to the server.

Table 1.

Common Events^* That Can Cause Less Than 25% of Delivered Gas to Return to the Ventilator and Generate “Disconnect” Alarms

1.Disconnection of the ventilator circuit

a.Circuit becomes detached from the patient's artificial airway

b.Pieces of the circuit become disconnected from each other

2.During a medical procedure, the ventilator is disconnected intentionally. However, the staff forget to ventilate the patient or forget to turn off the ventilator as alternative ventilation is being provided

3.Obstruction of the tubing connecting the patient to the ventilator

a.Condensed water filling the tubing

b.Kink or blockage in the tubing

c.Leak in the tubing

4.The patient's artificial airway comes out accidentally (extubation)

5.Leak around the artificial airway (cuff leak)

6.Obstruction of the patient's artificial airway

7.Leakage through the outside surface of the lung (bronchopleural fistula)

8.The patient takes multiple breaths from the ventilator in a row without exhaling between breaths; This generally occurs when the ventilator is delivering only small-sized breaths to the patient, but the patient is trying to get much larger breaths (breath-stacking or patient-ventilator dyssynchrony)

^*All these events are classified by the ventilator manufacturer as “ventilator disconnections.”

Figure 1.

Diagram of the enhanced ventilator event alerting system. DCC = Device Communications Controller.

The program on the server was written in Java and constantly listens on a TCP/IP port for messages sent from the bedside computers. The bedside and nursing station computers also “check in” with the server every ten minutes. A program on the server contains a table with the nursing units, rooms, and IP addresses of each of the computers. If a computer has not checked in during the previous hour, that computer is marked as “out of service” and removed from the table. When a computer is replaced or brought back online, a start-up message is sent to the server and the current data are loaded into the table. Another program on the server collects and analyzes the data sent from the bedside and nursing station computers. If that computer does not check in with the server every 30 minutes, a message is sent to the pagers of the on-call staff to determine the status of the computer. This process ensures that the table on the server will contain the correct IP addresses and other information for the computers in each of the units. Thus, when one of the three messages is sent by a bedside computer, the server program determines which unit the computer is in and searches the table for other computers that are in the same unit. As it finds computers in the same unit, it then sends the same message over the TCP/IP connection to the computers. For activate alert messages, an alert record is created that includes the patient's encounter number, time of the event, and room number and is stored in a key-sequenced file on the HELP hospital information system.

A program loaded on the bedside and nursing station computers in the units was written in Java and runs as a Microsoft Windows service. When this program receives an activate-alert message from the server, it sends a Java frame to the terminal that fills the whole screen. The background of the frame alternates between red and black every three seconds (▶). The room number is displayed large enough to be seen from 20 to 25 feet away. An audio message containing the “submarine dive horn” is also sent to the nonbedside computers in the same unit. The alerts are then sent by e-mail or to pagers so that respiratory care management is informed of each critical event. There are three ways to turn off the enhanced visual and audio alerts sent to the computers in the unit: (1) correct the problem at the bedside, (2) press the alarm silence button on the ventilator, or (3) close the alert window on the computer. If the clinician closes the alert window on the computer, he or she has to acknowledge and terminate the alert. The program then logs how the alert was turned off and from which computer. This project was a hospital quality improvement effort and IHC Institutional Review Board approval was obtained.

Figure 2.

Display found on every computer terminal in the same unit as the patient who generated the critical ventilator alarm. Screen color alternates from red and black every three seconds.

Respiratory Therapy Charting and Reporting

The respiratory therapy charting program on the HELP System also was updated to notify the therapists whenever an enhanced ventilator alert had been generated for a patient for whom they were providing care. The therapist is requested to enter information concerning the cause of the event (▶) and describe the patient and the environment during the time of the event such as prior status of the patient, how the endotracheal tube was secured, the staffing level of the unit, who was in the room, post status of the patient, who was notified of the event, and the ventilator serial number. On some occasions, this notification is the first time the therapists find out about the event and they may need to contact other medical personnel to collect the requested information. The information is then sent to the enterprise data warehouse. A ventilator event report was created and is reviewed by respiratory care management (▶). The report is available on the IHC enterprise intranet and can be accessed by authorized personnel from any clinical computer in the hospital. The report is saved as a .pdf file and sent out through group e-mail to the ventilator Task Force Team and the critical care managers in the four ICUs for review.

Figure 3.

Example of ventilator event report used by respiratory care management to investigate ventilator events and identify possible process changes (patient identifiers are blanked out).

Status Report

Device Information Acquisition

The enhanced ventilator event system was initially tested in the shock/trauma ICU at LDS Hospital from January through June 2004. The new video/audio ventilator alerts were very distinct from any other alarms in the ICU and were virtually impossible to ignore. This served the design purpose to prevent prolonged duration of critical ventilator events. Although the audio was not sent to the bedside computers, the audio from the nursing stations could be heard in the patient rooms even if the door was closed. The clinician approval of the enhanced system in the shock/trauma ICU was so high that it was requested to be installed in three other ICUs (medical/surgical, coronary care, thoracic) in the hospital as soon as possible.

Pilot Study

During a six-month study (October 2004 through March 2005), 237 (average of 1.3 per day) enhanced ventilator alerts were generated from the four ICUs at LDS Hospital (60 beds). Some of the alerts were generated because the therapist or nurse forgot to inactivate the ventilator alarm during a patient procedure. Many resulted from unintended ventilator disconnections or ventilator tube occlusions due to water accumulation, all potential life-threatening events. ▶ lists information on the different types of enhanced ventilator alerts from the study period for each of the four different ICUs. The shock/trauma and thoracic ICUs had the highest number of ventilator events (75 and 89, respectively) compared to coronary care and medical/surgical ICUs (25 and 47, respectively). This was expected since shock/trauma (875 ventilator days) and thoracic (954 ventilator days) patients were more likely to be on ventilators and for longer periods of time compared to coronary care (298 ventilator days) and medical/surgical patients (383 ventilator days). Thus, the shock/trauma unit had 8.6 event alerts per 100 ventilator days compared to 9.3 for thoracic, 12.3 for medical/surgical, and 8.4 for coronary care. The shock/trauma ICU had the highest number of unintended disconnections (21 vs. 5, 8, and 17, respectively). Six of the unintended disconnection alerts from all four ICUs resulted from the patient becoming extubated. The other event alerts were caused by patient procedures, circuit obstruction by condensed water, other causes listed in ▶, or undetermined factors.

Table 2.

Number of Enhanced Ventilator Events by ICU (10/1/2004 to 3/31/2005)

ICU	Unintended Disconnection	Water in Tubing	During Procedure	Other	Undetermined	Total
CCICU	5	3	4	7	6	25
MSICU	8	1	15	14	9	47
STICU	21	10	21	14	9	75
TICU	17	5	25	26	17	90
Total	51	19	65	61	41	237

ICU = Intensive Care Unit; CCICU = Coronary Care; MSICU = Medical/Surgical; STICU = Shock/Trauma; TICU = Thoracic.

Before the enhanced ventilator event system was developed, respiratory care management had no information on the duration of the critical events, especially with regard to ventilator disconnections. This system now collects this information for all types of ventilator events (▶). On average, the ventilator alarms were activated for 20.5 seconds during the six-month study period. Thus, due to the ten-second delay between the ventilator alarm and the start of the enhanced alerts, duration of the enhanced alerts was an average of 10.5 seconds. Alarm times for unintentional disconnections averaged 23.3 seconds (range 10–55) and those classified as water in the tubing averaged 14.3 seconds (range 9–60). While the shock/trauma and thoracic ICUs had more critical ventilator events than the other two ICUs, the average duration of those events was slightly less (20.4 and 20.0 vs. 21.0 and 22.0, respectively). As shown in ▶, most ventilator alarms were corrected between 11 to 15 seconds while the range varied by the type of alarm and ICU. Moreover, the data from the study shows that none of the ventilator disconnections and other critical event times reached a level where patient harm occurred. Only eight of the 237 (3%) ventilator events were not resolved within 40 seconds. During the data analysis for this project, we discovered that 42 enhanced alerts were activated when the ventilator alarm was generated for ten seconds or less. We found that the program on the bedside computer may have activated the enhanced alert before ten seconds if that patient had previous ventilator alarms within a certain time period. This resulted in the “count” variable in the program to not always get reset and to use a previous alarm state instead of waiting for two or more new consecutive alarm states. This has been changed in the bedside computer program to conform to the initial purpose and design as an enhanced backup system.

Table 3.

Average Critical Ventilator Alarm Duration Times^* (in Seconds) by ICU and Event Type (10/1/2004 to 3/31/2005)

	CCICU	MSICU	STICU	TICU	Type Average	Range
Unintended disconnection	25.0	22.5	22.4	25.1	23.3	10–55
Water in tubing	18.3	60.0	13.4	13.8	14.3	9–60
During procedure	16.7	22.9	18.6	18.7	19.6	9–45
Other	21.4	15.6	24.4	19.5	20.4	10–50
Undetermined	20.8	25.8	21.7	18.8	20.6	9–67
ICU average	21.0	22.0	20.4	20.0	20.5
Range	15–40	10–67	9–55	9–50

ICU = Intensive Care Unit; CCICU = Coronary Care; MSICU = Medical/Surgical; STICU = Shock/Trauma; TICU = Thoracic.

^*Due to ten-second delay, the duration of enhanced alerts would average about ten seconds less than the reported time.

Figure 4.

Critical ventilator alarm duration times for all events during the study period. Ventilator alarms started at time 0. Due to a ten-second delay, duration of enhanced alerts should have averaged about ten seconds less than the reported time.

The analyses of ventilator event information not only increased our knowledge of the number and duration of the events, but also allowed respiratory care management to identify ventilator problems such as the need for further education and training from the ventilator manufacturer on optimal use and management, identification of the location of room fans and ventilator heaters to be associated with the buildup of condensed water in the ventilator tubing, lack of communication between staff during shift changes, and obstruction of the exhalation filter. Ventilator alarms generated during patient procedures also may have represented patient discomfort. The exact cause for 41 alerts could not be determined by the respiratory therapist or other clinical personnel and remained in the undetermined category. The number of enhanced ventilator alerts and type of alerts varied for each ICU over the six-month study period. The variation of alerts over time and by ICU along with the knowledge that the cause of some events remained in the “undetermined” category will provide an opportunity for respiratory care management to focus on certain problem areas for further investigation.

Discussion

The enhanced alerts improve patient safety by alerting all medical staff in the ICU of all critical ventilator events in a timely manner. If a critical event alarm sent by the ventilator continues for ten seconds or longer, the enhanced audio and video alert is automatically activated and is nearly impossible to ignore. The duration of the ventilator events since the enhanced system was installed has been reduced to a level where patient harm does not occur. To date, we have not received any verified reports of false-positive enhanced alerts. This is due to the fact that the program on the DCC was developed to distinguish the difference between the severity and different types of alarms generated by the ventilator. The lack of false-positive enhanced alerts has definitely been a key factor leading to the high clinician acceptance. We have received almost no reaction from patients or family members concerning the enhanced alerts. Medical staff attribute this to the obvious explanation on the computer screens and the acceptance as routine medical care.

In addition, the system identifies and logs each ventilator event whenever the ventilator alarms and enhanced alerts are activated. In a previous study, we found that, except for infections caused by arterial, central, peripherally inserted central and urinary catheters, routine identification and analyses of adverse medical device events are rare.³⁹ This was mainly due to sparse or nonexistent event documentation, lack of electronic flags, and the absence of routine or organized surveillance for these events, including ventilator events. Also, in that study, medical staff reported frustration due to high numbers of false-positive alarms from medical devices.

Now, with the enhanced alerting system, therapists are notified of all critical events and respiratory care management staff are provided the information that they need to perform root-cause analyses. The information provided by the new report allows the health care team to see trends as to whether patients are restrained properly, patient breathing tubes are secured, circuits are being drained of water, staffing is sufficient, and alarms are answered in a timely manner. There is also a check to see whether the right members of the health care team are notified of the critical events.

Some ventilator events including those that occur during procedures are generally not as life threatening or emergent as unintended disconnections, water in the tubing, and extubations. However, the incidence of these ventilator events can alert management of the need for more education regarding adjusting the ventilator for patient comfort and understanding ventilator waveforms. Events during procedures reminds the health care team that patients still need to be ventilated during other important procedures being done at the bedside. We can only manage what we can measure.

The new audio and video alerts are so distinct and annoying that all medical personnel quickly respond to get the alerts turned off. One item of potential concern is that while respiratory therapists may now be more attentive with ventilator management to avoid disturbing the other staff with the enhanced alerts, they and other medical staff may also be tempted to silence ventilator alarms more often during patient procedures. Since there is a ten-second delay between the ventilator alarm and the enhanced alert being triggered, respiratory therapists and other medical staff know that if they forget to silence the alarm before the procedure, they can avoid the enhanced alert if they silence the ventilator alarm quickly enough. Respiratory care management is monitoring this process to make sure that the ventilator silence button is not overused as patient harm can occur during procedures. In addition, if a ventilator alarm is silenced for two or more minutes, the enhanced alert will activate.

Although the clinical impression in the four ICUs at LDS Hospital is that the enhanced alerts have improved patient care, that fact has not been scientifically proven. If so, does the improvement in patient care justify the cost of implementing the system in other ICUs? While sentinel events involving ventilators are devastating, fortunately, they do not occur often. Because we do not have any previous information on the duration of ventilator events before implementing the enhanced system, an extended time period will be needed to statistically compare the number of previous ventilator-related sentinel events and incidence reports to evaluate the true impact on patient outcomes. In addition, future studies will need to evaluate the duration of ventilator events in ICUs that do not have the enhanced alerts. This will enable us to evaluate the impact that this system actually has on the duration of ventilator events. Nevertheless, the data from the pilot study show that the present critical ventilator alarm times are below durations that are likely to be dangerous.