Key points are not available for this paper at this time.
Medical devices are pervasive throughout modern healthcare, but each device works on its own and in isolation. Interoperable medical devices would lead to clear benefits for the care provider and the patient, such as more accurate assessment of the patient's health and safety interlocks that would enable error-resilient systems. The Center for Integration of Medicine others only require low precision such as sending a stop signal to the PCA pump in case of an overdose. Nevertheless, the underlying infrastructure must provide means to execute such time-critical tasks right from the beginning. Otherwise, the infrastructure will become obsolete once it starts to proliferate. The support infrastructure of the medical network must therefore provide means for computing end-to-end guarantees for delays in the system. For example, it must provide all the data necessary to compute how long it will take from the pulse oximeter reporting an alarm condition until the PCA pump stops pumping fluid.Some treatment devices perform safety-critical operations since a patient could die as a result of an incorrect treatment due to a malfunctioning treatment device. This was clearly demonstrated by the example of the Therac-25 linear accelerator system.6 Treatment devices must therefore be subjected to rigorous verification and validation (V&V) to ensure safety and must be approved by regulatory agencies, such as the U.S. Food and Drug Administration (FDA), before being put on the market. V&V and approval of interconnected devices pose new challenges since there is no longer a single manufacturer of the system and the final configuration can not always be predicted before the individual devices are sold. This situation is different if the manufacturer of the treatment device designed it with the intention of a defined control interface in mind.Interconnected devices enable more complex alarms than standalone devices. To show this, we chose scenarios which would cause false positive and negative alarms in standalone devices and showed how we would detect and correct the false alarms in an interconnected system.A false positive alarm is one where the system sounds an alarm when no real fault is present. This causes the caregiver to waste resources responding to situations that do not require intervention and, in extreme cases, may cause caregivers to ignore alarms. False negative alarms are conditions where the patient has a problem but the monitor does not detect it and no alarm is sounded. A monitor may also sound the alarm too late.A false positive may occur if, for example, a patient is resting and his or her heart rate goes below the threshold set on the monitor. We can try to mask this kind of false alarm by requiring that the signal stay low for a period of time before sounding an alarm, but this delays caregiver response for all real alarms as well. Instead, we need to correlate the heart rate and SpO2 from the patient monitor with data from other monitors (such as respiratory rate and other data from a capnograph) to get a better picture of the patient's overall status. Rather than triggering an alarm based only on heart rate measured by the pulse oximeter, we can also look at the other data that is available and only alarm if they also show abnormal conditions.The prototype system consisted of the PCA pump, two pulse oximeters, and the supervisor node (see Figure 2). The nurse alarm and the respiratory rate monitor were directly connected to the supervisor. A time-division multiple-access (TDMA) driven Ethernet forms the communication backbone of the medical network.We selected all system components so they satisfy the requirement for remote controllability. The patient monitors already had a serial output port that they used to publish their status and patient information. The PCA infusion pump was more difficult since there are currently no PCA infusion pumps that allow external control of their settings. We used an experimental pump system based on the Generic Infusion Pump.2 We hope in the future to modify an existing pump to enable external control and are discussing this possibility with pump manufacturers.The system uses time-triggered computation and time-triggered communication. This means that devices execute actions and communicate at predefined points in time. To ensure this, each device connects to a dongle that shields the network from the device and the device from the network.4 The dongle acts as the gateway to the medical network, implements the plug-and-play functionality, and handles the communication layer interface. During operation, the medical network layer is completely transparent for the medical devices because they only interact with the dongle. The dongle synchronizes all information across the system at predefined rates and maintains a consistent state.The following scenario outlines how the system works in operation. The pulse oximeter is a monitoring device and it reports new values every second. The oximeter dongle transmits the latest measurements with a frequency of 1Hz to the supervisor. The supervisor collects information from all monitors and decides the treatment dose. The supervisor dongle communicates the treatment dose to all treatment devices at a frequency of 1Hz. The PCA pump is a treatment device and it keeps on delivering treatment only as long as it periodically receives a go signal from the supervisor.We preallocate communication bandwidth for the individual dongles and use temporal isolation to eliminate collisions on the shared communication medium. Thus, we can precisely calculate the end-to-end delay from the oximeter reporting a hazardous condition until the pump stops delivering medication.The dongles, together with the supervisor, support workflows, and the ability to implement precisely timed actions allows us to implement time-sensitive workflows as well. Consider a general workflow with the following three steps: (1) enable monitoring devices, (2) wait for the first reading, (3) if ok, start delivering medication. The nurse need not follow this workflow precisely because it is embedded in the dongles. Instead, the nurse simply connects all the devices, selects the right workflow at the supervisor node, and then presses start. The pump dongle will keep the pump turned off until it receives a go signal from the supervisor. The supervisor will not send this go signal before it has received the first reading from the monitor devices and before all readings are fine. And finally, the monitoring devices will not report readings before the nurse presses the start button on the supervisor.The final step in the system is to understand whether it works as specified. For this, we used software and communication abstractions that facilitate formal verification and thereby create evidence for a potential certification. Formal verification of our system allows us to statically check properties of the systems such as: will the pump dongle ever turn on the pump before it has received a go signal? An in-depth discussion of the formal verification part is beyond the scope of this column and we point the interested reader to other works.52The closed-loop integration of monitoring devices with treatment devices allows us to lower the work burden of the clinical staff by reducing the number of false alarms produced by the monitoring devices. In the following we present a concrete case, showing how our prototype prevents a false alarm and can take safety precautions in the presence of a real alarm.Consider a patient experiencing a drop in the SpO2 reading. This drop can be the result of a variety of reasons including the common occurences of the measuring clip falling off or the patient fiddling with the sensor. At this point an isolated system will sound an alarm and notify the clinical staff to check on the patient. If the drop is transient, then this will be a false alarm and the notification will have been unnecessary.Our prototype system will not sound an alarm resulting from transient drops because it can integrate readings from multiple monitoring devices and has more data available to make the decision. The pulse oximeter transmits the SpO2 reading to the supervisor. At the same time, the respiratory rate monitor reports its readings. The supervisor can now fuse the data of these two monitoring devices and use a smart algorithm that, for example, will sound an alarm only if the SpO2 value remains low for a predefined period of time and the respiratory monitor also reports abnormal readings. This will reduce the number of false alarms, assuming that the patient continues breathing while fiddling with the sensor or after the sensor falls off. The algorithm might report a warning to the nurse to check the patient if time permits.Furthermore, our prototype system can take safety precautions in case an alarm appears. If we assume that the SpO2 drop is permanent and that the respiratory rate monitor also reports abnormal readings, then the workflow can specify to terminate the treatment and the supervisor will command the pump to stop delivering medication. This simple safety interlock between the monitoring and the treatment devices can safeguard a significant number of patients from a lethal overdose.839One major element of the case study is the medical network. Its key property is to provide bounded communication delays for the participating devices. While the theory on bounding communication delays is rich, the practical solutions do not provide acceptable latencies and flexibility when basing communication decisions on the application state. This is required to ensure future tight integration of safety checks into the dongle to protect the patient from transient and permanent hardware and software failures. We built our own communication chip with Ethernet technology that provides the required latencies and flexibility for the medical network. The current version of this chip works with a predefined set of devices and we are working on extending it to support any device that is plug-and-play compatible. Adding complexity to the medical network introduces new hazards, so our design must include mechanisms to mitigate those hazards.We are also working to support smarter treatment algorithms. In the current implementation, the supervisor shuts off the pump in the presence of a permanent respiratory depression based on a preset threshold. We envision using smart algorithms that integrate data from multiple sensors together with the patient history and statistical data from other patients to calculate the threshold for each individual. The next generation of our case study is aimed at use in a hospital setting where it collects data from real patients. This data will be used to develop better algorithms for detecting when a patient is receiving an overdose.The case study implementation presented here has served several roles. It is a research platform for developing infrastructure for prototype interoperable systems, a tool for presenting the ideas of medical device plug-and-play, and a means of exploring the clinical patient safety applications enabled by interoperable systems. We have presented results in each of these areas and we expect that our future work will continue to advance infrastructure for medical device interoperability and applications for improving patient safety.
Arney et al. (Wed,) studied this question.