Uncelebrated Case #3:
Drug misadministrations via computerized infusion devices in the operating room

Cook and colleagues studied how the characteristics of a particular infusion device used in cardiac anesthesia contributed to a series of operating room near misses. In this uncelebrated case, the story of how the incidents were investigated and how different stakeholders reacted is as revealing as the specific results.

The research began after an institution experienced an inadvertent delivery of a vasoactive drug via a computerized infusion device during cardiac anesthesia. Due to prompt physician intervention, the misadministration had no lasting consequences for the patient.

The researchers, who were already engaged in a study of human performance in anesthesia, began to investigate the incident in particular and to study broader questions about physician-device interaction. In the midst of these studies three more misadministrations occurred (again with no lasting consequences).

These studies of device use in context and the incident investigations showed that the device possessed classic deficiencies in human-computer interface (HCI) design. These HCI deficiencies contributed to misoperation and misassembly of the device. These HCI deficiencies made it difficult for users to detect and recover from these and other problems. These HCI deficiencies were one contributor to incidents of misadministrations of vasoactive drugs. The results also led the research team to design an alternative device interface and displays to illustrate how to correct these kinds of HCI deficiencies in this class of infusion devices. The study has implications for incident reporting, for device design, and for the analysis of human performance in technical environments.

Background
Infusion devices are ubiquitous in medicine, as are problems related to their use. The incidents with this infusion device occurred during anesthesia for cardiac surgery. Drugs with rapid onset and short duration of action have the advantage of permitting quick adjustment (titration) to achieve desired effects. In cardiac surgery there are predictable periods where patients may require the infusion of these fast-acting/short-lasting drugs to increase cardiac contractility, change blood pressure, or alter heart rate. Various mechanical devices are used to administer these infusions. The advent of microprocessor-based, battery-powered infusion devices opened the way to more precise control of these infusions than was possible with older, purely mechanical devices. But this increased precision has been achieved at the cost of increasing the complexity of the drug delivery process and the creation of new forms of failure.

The Research
Table 2 presents the sequence of events that followed the first case of inadvertent drug delivery.

The researchers were engaged in a study of human performance in anesthesia. The first incident was reported informally to one of the investigators shortly after it occurred. The initial descriptions were vague, but the event involved free flow of a vasoactive drug through an infusion device. Free flow is a runaway condition where the fluid containing the drug is delivered to the patient as a continuous, unlimited flow rather than as a controlled incremental delivery over time. In this instance, the fluid contained a drug that lowered blood pressure. Other drugs were given to counteract the effect, but the free-flow event was not discovered until later.

At the time, the failure was attributed to human operator error. This was the view of the manufacturer and also of the senior practitioners. For some, the event was regarded as an example of human fraility, or at least the limited ability of humans to operate modern equipment (e.g., "you can't make devices completely idiotproof"). Many practitioners thought that the device had some quirks in operation and that it was potentially troublesome. Some had developed local adaptations to help them forestall problems with the device in use. In general, other practitioners felt that this kind of thing could not happen to them because of their skill, attention to detail, and vigilance. In addition, the event was regarded as an anomaly with only local implications, unrelated to other events.

To the researchers, however, the incident had the flavor of a human-computer interaction breakdown. They were familiar with problems in human-computer cooperation and also with investigating human performance in incidents and were already active in this setting in a related study. As a result, they decided to investigate the incident and the device more closely.

The researchers used multiple methods to reconstruct the sequence of events and to explore what factors contributed to the incident. They explored how the device behaved under different circumstances, e.g., how the alarms and displays behaved when flow was obstructed or excessive. They began observing how people used the devices in the context of cardiac surgery. They linked aspects of cardiac anesthesia to device characteristics and the user interface-for example, the need to use multiple devices in parallel in this setting. The data were used to construct a protocol of the incident that consisted of what cues the anesthesia team noticed about the patient's physiology, their interpretation of the situation, and their interventions. In particular, the protocol traced the interaction with the set of infusion devices during the case.

The basic sequence of events was as follows. The anesthetist observed increasing blood pressure and attempted to counteract the change by starting one of the infusion devices that had been set up earlier to be ready to deliver medication to lower the blood pressure. The device emitted an audible alarm and posted a message on its screen indicating that no flow had occurred. An anesthesiologist scanned the assembly and noted that all of the stop cocks were closed downstream of the infusion devices, blocking flow to the patient. The anesthesiologist then opened all of these valves. By this point in time blood pressure had fallen. Because the infusion was no longer needed, the anesthesiologist did not restart the device (in the anesthesiologist's mind the infusion had never started).

The blood pressure began to fall and reached an unacceptably low level. The anesthesiologist responded appropriately by injecting other drugs to counteract the drop. However, the disturbance to blood pressure continued, and the anesthesiologist continued to act to keep blood pressure under control. When the anesthesia team scanned the array of infusion devices, the displays indicated that the one they originally attempted to use was not running. Even so, they pressed the OFF button on the device to turn off the power. Only later, as they began to prepare another drug infusion to counter the low blood pressure, did they notice that the previously full bag of drug for lowering blood pressure was now empty.

Although they did not realize it at the time, the anesthesiologists had misassembled the device in a way that allowed free flow. The closed stop-cock in series prevented the immediate free-flow condition in the infusion device. When the anesthesiologist opened these valves, free flow began, drug reached the patient, and the blood pressure began to fall. Once the unintended drug delivery began, the device provided no feedback to indicate flow of any kind to the users. The display and alarms indicated there was no flow and that there had been no flow. The device's sensor obscured the user's view of the drip chamber. The bag of fluid that contained the drug was inside a veil of aluminum foil to prevent it from reacting with light, thus obscuring the user's view. Furthermore, the off button only powered down the device; it did not block flow. Figure 5 contains the final version of the protocol describing the incident.

The studies of user-device interaction in context showed how multiple factors could come together to produce this incident. Some of the factors were traps created by the device interface and displays. For example, because several of these devices were used together in a device array and the setup for each individual device was complex, there were several steps that might be omitted or incorrectly performed which could produce a path toward failure. Misassemblies were observed to occur during normal use, but they did not produce inadvertent drug deliveries because other necessary conditions were not present. The observations showed that users were sensitive to the possibilities for misassembly and misoperation and devised strategies they thought would help to avoid these or to prevent inadvertent drug flow the patient. In the context of cardiac anesthesia, a misassembly (i.e., a flaw in setting up the device) could occur much earlier than the effects of the failure (i.e., the moment that drug began to flow freely).

If an unintended drug delivery began, there were other characteristics of the device that made it difficult for operators to detect that something had gone wrong with one device in the array and to correct the failure. Basically, the device provides weak feedback about its activities. Under the right circumstances the device's alarms and displays can give the impression that there is no flow when in fact there is flow or the impression that flow is precisely as desired when in fact it is different.

Up to this point the failure was regarded as a operator error, or perhaps a training problem, but only of passing significance. One week later, however, another near miss occurred involving this kind of infusion device, with one of the senior practitioners using the device. The anesthesiologists recognized that the surprising cardiovascular behavior resulted from the behavior of the device. The device was in a state that all thought was impossible-the device was delivering drug even though it appeared to be "off" as evidenced by a completely blank screen. The research team was called, and they removed the device to a place where it could be studied, thus capturing the device in its failed mode.

With a video recorder running and the manufacturer's representative present, the investigators determined the specific contributors that created the impossible state. This was done by varying the setup and operation of another of these infusion devices until its behavior matched the "impossible" behavior of the operating room (OR) device. The results from the previous investigations of device use in context and device behavior were important contributors to this process.

At this stage, the research project began in earnest with detailed, formal field studies observing the user setting up, testing, and using the devices. To verify how the device actually behaved and how it appeared to behave under different normal and abnormal conditions, the researchers tested the device in an engineering laboratory under a variety of conditions. The user interaction sequence was worked out for various tasks to reveal various HCI problems (e.g., ambiguous alarms and multiple hidden modes of operation). These results made the problems with the device in clinical settings comprehensible. They also made it possible to see which aspects of the user-device interface created opportunities for problems in the context of cardiac anesthesia.

In the research the investigators were unable to get any useful data about other incidents involving this device or similar devices from incident reporting systems. The device manufacturer provided a brief, cryptic incident report to the FDA device incident reporting system which referred to a "custom" setup, stated that the device worked as designed, and implied erratic human behavior was responsible. But practitioners now saw the device itself as the source of difficulties or surprises they experienced, and they began to report more incidents involving the device.

During the research projects, two more incidents related to the device occurred and were investigated. Several new reports of difficulty with the device were also received during this period. Some of these helped to confirm findings about difficulties with the device-user interface.

The research team also began a follow-up project to redesign the device interface (Yue, Woods and Cook, 1992). The goal of the redesign was to show how to correct deficiencies in practitioner-computer cooperation (a) with this device, (b) with this class of devices and, (c) in general. The design project used the results on the HCI problems to create a redesign based on user-centered automation principles. Particular attention was paid to:

• making the device display its actual and intended functions in a way that allowed users to see whether the actual performance of the device matched the intended one;
• supporting the user's need to attend to other tasks and interact with the device only at intervals by making the device show its behavior over time;
• making it possible to switch smoothly between automated and manual methods of control, so that situations where using the automated system would lead to instability (like transporting patients connected to the device from one location to the other) could be handled by taking manual control;
• providing a direct, positive, visible control that stopped flow through the device; and
• incorporating specific features to reduce the difficulties associated with using multiple devices simultaneously, including a support tree that made it possible to align infusion devices and their source bags of fluids and a slender package that permitted side-by-side arrangement of devices.

Broadly speaking, these features were all directed towards making the operations of the device apparent to the operator or, in the jargon of HCI, more "visible."

The results of the studies led to predictions of other problems one might expect. For example, the results alert us to the potential for certain kinds of problems and incidents in total intravenous anesthesia, which requires the use of arrays of automated infusion devices. These potential problems could be avoided largely through improved interface design. In another example, the studies showed that during transport from the OR to the ICU actual device performance was irregular in a way that was unpredictable and invisible to the user. Later, the investigators were present for discussion of a case in a morbidity and mortality conference involving a patient whom became unstable while being transported from the operating room to the intensive care unit. One of these infusion devices was being used to support the patient's cardiovascular system. While it was impossible to reconstruct the device's behavior during this period and to determine its contribution to the incident, the researchers were able to alert the physicians that the device could behave erratically and unpredictably under these sorts of circumstances.

The investigators reported the incidents and results of their investigations in a specialty journal and through presentations to research-oriented and technology-oriented anesthesiologist groups. A report was prepared that describes the results of all of the investigations, documents the problems in practitioner-computer cooperation, and traces how they contributed to incidents (Moll van Charante et al., Cook, Woods, Yue and Howie, 1993). Overall, the research on the device lasted nearly nine months. It was not funded; the participants donated the time for the project. The work also led to other studies of different classes of infusion devices used in other contexts (e.g., Obradovich and Woods, 1996).

Implications of the Research
One interesting feature of the research is that the deficiencies of the device design are subtle and became apparent only under the conditions of use. Problems occur when aspects of the context of use combine with features of the device and device interface to create problems for the user. The testing that uncovered specific problems with the device-user interface was directed by the field studies that in turn were prompted by close examination of incidents. The device did not possess a hidden "Achilles' heel" defect but rather possessed a group of properties that influenced human performance. These factors were significant with respect to outcome only under specific circumstances.

It is important to note that the incidents were regarded as operator error until the investigation was well underway. A variety of factors tended to make it unlikely people would discover the specific problems with the device in this context of use: a) the complexity of the larger system in which the device was used; b) the hidden complexity of the device itself; and c) the general experience of practitioners that computerized devices are quirky, difficult, or unpredictable.

These factors made human performance rather than device characteristics the center of attention after the fact. Indeed, the reports regarding incidents with this device that were filed with the government incident tracking system emphasized simple "operator error" and implied each was unique (e.g., "user reports problem; cannot duplicate problem"). None of the reports provided a narrative of the incident with enough detail for researchers to go back and look for similarities or contrasts with new cases. None of the reports indicated any in-depth investigation of the factors that led to the incident.

Only when these actual incidents were carefully explored, applying specialized knowledge and techniques related to the factors that affect human performance, were investigators able to reveal a second story hidden behind the label of "operator error."

Another important feature of the research is the use of multiple methods to understand the different factors at work. Each new finding based on a particular method raised questions that required a shift to a different method. This is natural, considering the complexity of the underlying features of the domain. The ability to make progress depended on being able to bring together disparate methods to create a web of information that was mutually reinforcing. The incidents themselves pointed to features of the device. The HCI analysis of the device suggested particular problems with the interface. The studies of the behavior of the interface showed how the device would appear opaque under conditions like those occurring in the incidents. The redesign showed how this opacity was a function of cognitive tasks and how it might be avoided without changing the underlying mechanical functions of the device. The contrasts and connections between these various approaches provided the insight.

Finally, the research is significant because it was so fortuitous and unplanned. It points out the value of long term associations between researchers and practitioners. In particular, the ability to recognize fruitful areas for investigation depends on being intimately involved with practitioners. The research perspective allows one to see beyond the practitioners' own characterizations of the difficulties they face and to follow deeper, more subtle, but ultimately more rewarding lines of inquiry.

Contrasting Uncelebrated and Celebrated Cases

Taken together, the laparoscopic cholecystectomy, blood antibody identification, and infusion device cases demonstrate the kinds of insights that come from exploring the second story that lies behind the incidents that provoke attention. In each case, the work is painstaking and detailed, going far beyond the sorts of investigations that followed the celebrated cases. In each case the story is complex, difficult for outsiders to understand, and not easily reduced to a simple summary. Significantly, the research methods used are unfamiliar to many. Finally, the motivation for the work was less the desire to directly generate safety improvements than to understand the nature of the real processes that underlie success and failure in the real world. The potential for such work to produce sustained increases in safety is substantial. In particular, in each case the research offers the possibility of further progress by identifying areas ripe for additional work.

Day One Footnotes

 See Cook, Woods and Howie (1992), Moll van Charante et al. (1993), Yue, Woods, and Cook (1992).

Return to document

 These deficiencies in human-computer cooperation are called classic because they have been identified as contributors to erroneous actions and assessments in many different settings. Because they are common design errors in computerized devices, they are used as cautionary tales when teaching HCI.

Return to document

 In one case, a practitioner was observed setting up the devices. Setup was completed at the beginning of the day, well before bringing the patient into the room. After assembling the devices and drugs the practitioner started all the devices at a high flow rate setting, allowing the fluid they controlled to flow into a garbage pail. Once the devices had been running for several minutes without generating any alarms, the practitioner changed the settings to low rates and shut the devices off. This pretest of the assembled system of devices is a good example of local adaptation.

Return to document

 The device monitored its own function by counting fluid drops forming in a drip chamber, but lateral acceleration could move these drops out of the detector's path; this could lead to a variety of responses (e.g., automatically blocking flow and then trying to resume flow at the target setpoint) depending on precisely how and when the detection failed along with other factors.

Return to document

 Moll van Charante was a visiting medical student from The Netherlands, Yue was a graduate student in the Industrial Design program focusing on human-computer interaction at The Ohio State University.

Return to document