Keywords

1 Motivation

The entire cardiac surgical team (8–12 individuals) collectively takes responsibility for the patient’s overall safety during cardiac surgery; it is a “team of teams”, whereby four sub-teams (surgery, anesthesia, perfusion and nursing) must collaborate and coordinate their actions throughout the procedure. A mission-critical part of this responsibility is ensuring that the patient’s gas exchange (oxygen and carbon dioxide) needs are met during cardiac surgery. The anesthesia team controls the function of the lung ventilator to deliver air and supplemental oxygen to the patient’s lungs during inspiration and permit excretion of carbon dioxide during expiration. While the patient is being maintained on cardiopulmonary bypass (CPB), the responsibility for ensuring adequate ventilation shifts from the anesthesiologist to the perfusionist: instead of exchanging gases using the ventilator machine, the perfusionist uses the oxygenator present in-line with the CPB circuit. During the CPB “run”, the ventilator machine and its monitors and alarms is turned off for the duration of the run to allow unobstructed vision of the surgical field for the surgical team. After the CPB is discontinued the responsibility of ventilation is transferred back to the anesthesia team that must restart the ventilator. These two mission-critical transitions of responsibilities back and forth from the anesthesia and perfusion team require complex human-human communication to coordinate actions involving machines that otherwise don’t communicate between each other and introduce the rare but potentially lethal possibility of missing the handoff, resulting in the patient not being ventilated and suffering from anoxic brain injury (a “never event”). Communication breakdown is considered the most frequent cause of errors causing preventable adverse events in surgery. We propose an interoperable, context-aware system for cardiac surgery that specifically allows machine-machine communication and makes it hard for the surgical team to make errors and cause patient harm by detecting and alarming in case of missed handoff.

2 Methodology

In developing clinical alarms, it is important to build systems that support the existing surgical workflows and communication patterns in the care teams. In failing to do so, the new alarms are likely to cause surgical flow disruptions than of being useful. Our goal is to develop an alarm system for an extremely rare but potentially lethal situation, and therefore we need to create a system with a very low false positive rate. False positives distract the surgical team, increasing risk to the patient, and reduce confidence in the alarm system. False positives refer to situations where the alarm indicates a condition that is not actually present.

We observed and discussed the process and cardiac surgical environment with a number of subject matter experts at a cardiac surgery program of a teaching hospital of Harvard Medical School. The proposed specific alarm is most relevant to the anesthesia and perfusion teams, so we focused on interviewing domain experts of these two teams. We determined that monitoring the anesthesia machine ventilator’s respiratory rate and the flow rate of the CPB machine would allow us to trigger a simple alarm for a “failure to ventilate”. We read the ventilator rate and CPB pump speed and when the respiratory rate is zero and the CPB pump flow rate is also zero, we know that the patient is not being ventilated.

We prototyped this system in the Massachusetts General Hospital MD PnP lab using a combination of physical medical devices, simulated medical devices, and electronic and physical patient simulators as shown in Fig. 1. The setup includes an operating room patient monitor, an anesthesia machine, an electronic patient simulator and a physical lung simulator. The simulators allow us to see how the medical devices and our system respond to a wide variety of normal and abnormal patient conditions.

Fig. 1.
figure 1

Medical devices and patient simulators for algorithm development and testing

Full size image

The devices were integrated using the OpenICE platform [3], which translates each device’s proprietary communications protocol and data representation to a standardized format and communications middleware. This platform allows us to write applications around the device settings and vital signs of interest without having to concern ourselves with the peculiarities of specific devices. Figure 1 shows a Drager Apollo anesthesia machine, but the same respiratory rate value could be obtained from other brands and models without making any changes to the alarm application. This platform allows us to reuse device interfaces developed previously and build on safety interlock applications including PCA safety [6], x-ray and ventilator synchronization [1, 2], and detection of pulseless electrical activity. OpenICE is an implementation of the ASTM 2761-09 ICE standard [4], which includes clinical scenarios around ventilator to pump handoffs as annexes B.2.4.1 and B.2.4.2.

As an initial prototype, the purpose was to test connectivity to the required data sources and prove the feasibility of the approach. Once initial feasibility is demonstrated, we can plug in more complex algorithms to increase the specificity and sensitivity of the alarm.

We want to detect failure to ventilate with high reliability, but we only want to trigger an alarm when it is clinically relevant. Doing so perfectly would require our algorithm to know whether the clinicians already know that both the CPB machine and the ventilator are turned off. Our software can’t detect what the surgical team is thinking, but we can take some steps to make the alarm more relevant and filter out real (not false positive) alarms that are irrelevant. One way to filter is to delay the alarm. If both devices remain off for more than a few seconds then there is a higher likelihood that it is not deliberate; simply delaying the alarm by a few seconds is likely to substantially reduce the number of clinically irrelevant alarms without significantly increasing the risk to the patient.

Fig. 2.
figure 2

The OpenICE supervisor and simulated cardiopulmonary bypass pump

Full size image

We developed and tested the alarm algorithm with a mix of real and simulated medical devices. Figure 2 shows the OpenICE supervisor and the simulated cardiopulmonary bypass pump. The supervisor shows the devices that are connected (Apollo anesthesia machine and simulated pump) on the right and the available applications on the left. Our alarm application is assessed through the “Rule-Based Safety” application. The simulated bypass pump outputs pump speed in RPM, flow rate in liters/minute, blood temperature, and a pressure measurement. A full bypass machine includes several pumps and many other components. For this version of the alarm, we only use the CPB flow rate and so we have only simulated the pump.

Fig. 3.
figure 3

The alarm system in monitoring mode

Full size image

We implemented the alarm using the OpenICE Rule-based-safety application. This allows us to write the alarm as a script that runs under OpenICE and accesses devices connected through the platform. The alarm has two states: monitoring and triggered, shown in Figs. 3 and 4.

Fig. 4.
figure 4

The alarm system when triggered

Full size image

In the monitoring mode, the alarm application shows a short description of itself, a display of the relevant device information (CPB flow rate and ventilator machine respiratory rate), and a list of messages. The device information is updated as new data is available from the devices and typically refreshes in well under one second.

When the CPB machine reports a flow rate of zero and the ventilator machine reports a respiratory rate of zero simultaneously, the alarm condition is reached and the application switches to its triggered mode. In this mode, it shows an alarm symbol, changes its border to red, sounds an audible alert tone, and displays a message indicating what has happened. It also continues to show the live data from the devices and is currently configured to stop alarming without manual intervention when the alarm condition is no longer true. This allows the surgical team to stop the alarm by increasing either the CPB flow rate or ventilator respiratory rate without having to touch the OpenICE computer.

3 Results and Future Work

Having established an interoperable framework for building better alert systems for the cardiac operating room, we can build on this work by developing more advanced algorithms and by integrating the alert system with more sources of relevant information. We expect that we could improve the sensitivity of the alarm using information from hospital IT systems such as the medical records system and pharmacy systems, and that we could improve the clinical relevance using additional contextual information that would allow the algorithm to be more reactive to the unfolding situation in the operating room. Measuring and reacting to the cognitive load of the various team members would allow the alert system to be responsive without interrupting critical tasks [5]. Ideally, this system, operating through algorithms, should be viewed as an additional member of the surgical team, offering relevant information to the right people at the right time in a way that doesn’t interfere with the other team members’ work.

The Rule-based-safety application allowed for rapid prototyping and concept validation, but it does not support the more advanced rules that we would like to implement in the future. We plan to implement future iterations of the alarm system as full applications on the OpenICE platform, which will allow us to implement delays, thresholds based on rate of change, and other more complex rules.

Validating alarms for rare events but potentially catastrophic events is a challenge. There is no data set of patients injured due to failure to ventilate in cardiac surgery and it is not practical to conduct a clinical study to collect data on events that happen so infrequently. However, we have identified a critical system vulnerability that makes this never event possible; if making such an error is possible, it will happen eventually. We plan to continue testing our implementations using a simulation environment where we can create a wide range of clinical situations.