Difficulty Using Smart Pump Logs to Recreate a Patient Safety Event: Case Study and Considerations for Pump Enhancements.

The authors present a case in which a physical anomaly with an infusion pump resulted in an unforeseen fault that the nurse's attempts to resolve unknowingly exacerbated. This case study presents the first report in the literature to detail the difficulty in recreating a patient safety event using smart pump logs, support server continuous quality improvement (CQI) data, and the drug order entry system to elucidate the clinical scenario. A 75-year-old male patient presented to a major teaching hospital and was admitted to the intensive care unit (ICU) with a massive gastrointestinal bleed and myocardial infarction, then stabilized. One of the patient's pumps alarmed "communication error" on the display. The display gave no explicit instructions about how to resolve the issue, and resolution was not intuitive. Attempts to clear the alarm failed, so the module was disconnected to reprogram the infusion, causing an interruption in the dopamine. Over the course of approximately 2 min of troubleshooting, the patient's blood pressure decreased from 109/50 to 60/30, with a rapid pulse change from a consistent 95 up to 115 and subsequently 135 beats per minute. A cardiac arrest ensued and a code blue was called. All cardiac drugs, including the dopamine, were suspended during the code. Cardiopulmonary resuscitation was performed and the patient survived the code. Post-code, the dopamine and epinephrine were restarted, and the norepinephrine was discontinued. The patient's condition remained very unstable. Pump logs and the server database were queried to locate relevant equipment. It was concluded that dirty contacts on the inter-unit interface (IUI) connectors between the PC unit (PCU) and the modules caused the alarm message "communication error" to appear on the PCU display. Learning yielded a nursing practice alert to clarify how a nurse should resolve a "communication error", and appropriate cleaning protocols were promptly implemented. The investigation found smart pump event logs and proprietary software are not designed with any forethought as to retrospective reconstruction of incident investigations, leaving facilities to cobble together pieces of information from multiple sources to determine what occurred. The authors also suggest further pump enhancements, challenging pump manufacturers to go to the next level of integration and enable greater patient safety with smart infusion pumps.

Key Points

Introduction

Serious errors programming infusion pumps have been documented in the literature [1-3]. Healthcare institutions have used rigorous human factor assessments to acquire smart pumps with drug error reduction software (DERS) to mitigate programming errors at the bedside [4]. These evaluations focus primarily on routine task workflow with the pump rather than how the pump helps the user respond during emergent fault conditions or the utility of the system in reconstructing safety events. Retrospective analysis of smart pump data is often conducted for professional practice improvements, to determine whether DERS safety parameters are accurate, to identify chronic offending drugs, or to determine the time of day when most errors occur [5-8]. Infusion pump physical anomalies resulting in adverse events have been described but remain relatively rare [9]. A previous study has described the inconvenience of using infusion pump logs to glean meaningful information from common alarms such as air-in-line, door-open, and battery use [10]. Infusion pump logs have also been compared to “black boxes” in commercial aviation, and the authors concluded that infusion logs are poorly suited to accident investigations [11]. The authors present a case in which a physical anomaly with the infusion pump resulted in an unforeseen fault condition that was unknowingly exacerbated by the nurse’s response and attempts to resolve the issue. The pump discussed in this case study is a modular Alaris System smart infusion pump, firmware version 9.5.32.2 (CareFusion Corporation, San Diego, CA, USA) with one central PC unit (PCU) and up to four large-volume pump modules to accommodate each drug infusion.

Case Report

A 75-year-old male patient presented to a major teaching hospital on 8 July 2013 with a massive gastrointestinal bleed (hemoglobin 50 g/l) and a myocardial infarction (MI). The patient was known and had been diagnosed previously with coronary artery disease and a non-ST segment elevation MI (non-STEMI) in February 2013. The patient was admitted to the intensive care unit (ICU), and his condition was stabilized with a series of drugs (see Table 1). On 12 July 2013 at approximately 1335 h, the infusion pump module providing dopamine alarmed with a “communication error” message. The nurse was unfamiliar with this error message and attempted to clear the alarm but was unsuccessful. She turned the pump off and on again, and received the same error message. Unsure of how to respond, she disconnected the pump module, causing an interruption in the dopamine infusion only, and promptly reconnected and reprogrammed it. Over the course of approximately 2 min of troubleshooting, the patient’s blood pressure decreased from 109/50 to 60/30, with a rapid pulse change from a consistent 95 up to 115 and subsequently 135 beats per minute. A cardiac arrest ensued and a code blue was called at 1340 h. All cardiac drugs, including the dopamine, were suspended during the code. Cardiopulmonary resuscitation was performed and the patient survived the code. At 1343 h, the dopamine, and epinephrine were restarted and the norepinephrine was discontinued. The patient’s condition remained very unstable.

Table 1

List of patient medications from nursing notes

Drug	Lumen	Drug	Rate
1	Proximal	Morphine	1 mg/h
2	Proximal	Midazolam	8 mg/h
3	Proximal	Dopamine	20 μg/kg/min
4	Proximal	Norepinephrine	1 μg/min
5	Medial	Insulin	2.5 units/h
6	Medial	Normal saline flush	10 ml/h (paired with insulin)
7	Distal	Normal saline flush	15 ml/h (for medications, e.g. antibiotics)

Following the event, the pump was quarantined and sent to Biomedical Engineering (BME) for analysis.

Data Extraction and Investigation

Infusion pump events are stored in on-board memory called logs. Some event information is also sent wirelessly to the support server as continuous quality improvement (CQI) data. The onboard Error Log contains a record of any abnormal device conditions due to hardware or software errors [12]. The onboard Event Log contains a complete record of operating events, such as keystrokes, alarms, external communications, and infusion start and stops on the PCU and any connected modules. This log can contain information in coded form about changes that occurred on the display screen and other internal software events [12]. The Continuous Quality Improvement Log captures only the exceptions to the drug library during programming (e.g., exceeding a hard limit) and is stored on the support server. An exception is defined as a drug library selection by the pump user that contravenes a predefined safety parameter, such as attempting to exceed a predetermined flow rate for a given concentration of drug [13].

Data log files are manually extracted from the PCU using a serial to universal serial bus (USB) connection cable between the RJ45 jack on the back of the pump and a USB port on a computer running the proprietary software. The support server is accessed via a web browser and the pertinent information extracted into spreadsheets.

The investigation began with only the PCU and module that were involved with the “communication error”. It was subsequently discovered that additional pumps and modules were involved with this patient’s care that had not been quarantined for investigation and remained in the hospital circulation. To find the equipment, the CQI server database was queried using the patient’s medical record number (MRN) and the date to determine the serial numbers of the additional PCUs and their adjunct modules. Although the MRN is not required to operate the pump, it was fortuitous that the clinician had entered the MRN before commencing the infusion, as the MRN was the key that unlocked the total number of PCUs and modules providing therapy to the patient at the time of the adverse event. It was discovered that a total combination of three PCUs and nine modules were connected to the patient. They were located in the hospital for analysis.

Additional information was gathered to reconstruct the scenario, including the patient chart documentation, clinician interviews, and the drug order entry system to cross-reference ordered drugs for the patient.

Data Analysis and Inspection

Equipment Check Out

All identified equipment was located, and BME completed a manufacturer’s check out and performance verification on the PCUs and modules in question using the company’s proprietary software. Functionally, all equipment passed and was found to operate within the manufacturer’s specifications. The PCU and two modules that were involved with the “communication error” were subjected to additional investigation.

Inspection of the Pump and Module Inter-Unit Interface

There are connectors on either side of the PCU and modules called the inter-unit interface (IUI). When a module is mated with a PCU, the IUI pins mesh and facilitate power and the transfer of data between the components. An inspection of the dopamine module and its associated PCU revealed small pieces of “fluff” and green corrosion on the contact surfaces (Fig. 1).

Fig. 1

Connections 1 and 2 surface contamination with corrosion and “fluff”

Data Analysis and Swimlane Diagram

Raw data were obtained from the PCU event logs and CQI data from the support server. CQI data provided partial drug and infusion device serial number information. The drug order entry system provided a list of ordered drugs for the MRN. This information was cross-referenced with CQI data to help understand the drugs being infused. Iteratively, each interrogated PCU provided information that the investigation team then manually plotted in a swimlane diagram, with PCU and module details on the y-axis and time on the x-axis (Fig. 2), to provide a visual representation of the minutes surrounding the communication error. While the swimlane diagram has not been fully detailed, the authors believe this concept is a useful tool in the analysis of events.

Fig. 2

Excerpt from swimlane diagram illustrating the patient’s PC units, modules, and associated drugs and fluids

Discussion

This patient safety issue manifested because a communication error occurred on a module infusing inotropes, yielding an unconventional nursing response, ultimately resulting in a decrease in the patient’s blood pressure. The issue may not have been reported had it occurred on a module infusing a non-critical drug.

Green corrosion on the IUI connectors is believed to be a latent condition. Although a compliant 70 % isopropyl alcohol (IPA) disposable wipe was used routinely to clean the pump exterior, these wipes are not indicated to clean the IUI contacts [14]. The “fluff” from the disposable wipe snagged on the contacts and the corrosion is because the contacts were not cleaned with the IPA solution and brush [14]. Upon being advised of the event, the manufacturer reiterated the IUI cleaning protocol, which the facility promptly implemented.

The dirty contacts on the IUI connectors between the PCU and the modules caused the alarm message “communication error” to appear on the PCU display. Resolution of the error was not intuitive, and the pump gave no explicit instructions, thus it was unclear to the nurse how to resolve the issue. After the event, the manufacturer clarified that “communication error” means that the module has lost communication with the PCU device and that the pump’s fail-safe mechanism is designed to continue to infuse the drug at the prescribed rate. As this was the first time this error had been encountered at the facility, a practice alert to clarify “communication error” protocol was drafted and circulated.

The authors agree with Bitan and Nunnally [11] that infusion pump logs are not designed with forethought as to how they will be used to support an incident investigation. Methods to view pump logs are cumbersome, and often the extracted data are heavily coded and not easily interpreted in plain English (Table 2). Vendor software lacks meaningful tools to easily manipulate the data for analysis, such as a swimlane diagram, leaving the investigator to compile and interpret data from multiple sources, such as event logs and server CQI data, to reconstruct what happened during a clinical scenario (Fig. 3).

Table 2

Example of coded log file from pump

	Description	Details	Company explanation in plain language
1	AVA_EVENT_PCU	SourceType = NETWORK_MANAGEMENT; SourceContext = 0; EventType = NET_UNIT_DISCONNECTED	A “Channel Disconnect” error event has occurred
2	FORM_REQUEST	Form = CHANNELS_DISCONNECTED; FormRequest = FORM_REQUEST	The form display for such an event is displayed “Channel Disconnected Channel(s) have either been disconnected while in operation or have a non-recoverable error Press Confirm” with a displayed CONFIRM over soft key 14
3	FORM_REQUEST	Form = CHANNELS_DISCONNECTED; FormRequest = CANCEL_FORM	User selected the confirm key on the PCU
4	RDS_CONNECTION_LOST		PCU lost communication with the server
5	RDS_CONNECTION_ESTABLISHED		PCU re-established communication with the server
6	EXTERNAL_CONTROL_EVENT	EventID = RPT_LOG_REQUEST_HIST_START	PCU uploading information to server
7	EXTERNAL_CONTROL_EVENT	EventID = RPT_LOG_REQUEST_HIST_COMPLETED	Uploaded information to server completed
8	EXTERNAL_CONTROL_EVENT	EventID = CQI_LOG_DOWNLOAD_REQUEST	CQI information uploaded to server
9	EXTERNAL_CONTROL_EVENT	EventID = CQI_LOG_DOWNLOAD_COMPLETED	CQI uploaded information completed

Fig. 3

Reconstruction of the relational position of the modules and their connections prior to the “communication error”

For this pump manufacturer, the server only captures exceptions in the drug library at the bedside; all the remaining drug information from the pump is stored in the onboard memory. Cauchi et al. [15] suggest expanding the capability of pump logs to hold at least 6 months of data. The authors believe that all event log data should be sent from the PCU to the CQI database. This would enable a comprehensive understanding of how the pump is being used without needing to access the pump directly; it would also ensure that pump log information is centralized for incident investigations. This convenience would eliminate the challenge of locating pumps in a facility following an incident as well as the need for manual log downloads from the pumps themselves, which would outweigh the cost of virtual hard-drive space and the additional traffic required on the wireless infrastructure to transfer more data.

Additional Considerations for Pump Enhancements

Modern smart pump technology does not operate as a patient-focused system. Instead, each pump operates independently, lacking the ability to allow soft warning or hard stops for a combination of contraindicated drugs in the drug library that are infusing on separate channels of a PCU. Similarly, if two or more PCUs are concurrently infusing drugs to the same patient, the PCUs do not cross-reference what is being infused on the other PCU channels. In a critical care environment, it is not uncommon for a patient to be receiving a combination of 8–12 drugs or fluids at one time, requiring multiple PCUs to be connected to one patient. This situation does not allow a pharmacist to provide hard stops in the drug library for additive (1 + 1 = 2), potentiation (1 + 1 = 4), and antagonistic (1 + 1 = 0.5) drugs, or a combination of contraindicated drugs that are infusing on separate channels of a PCU. Pumps should be able to be daisy chained together so they can communicate and record information as a cohesive system per patient.

An ICU in Salt Lake City, Utah, USA self-developed and implemented “smart system” software that interfaces a non-smart infusion pump with patient data in the electronic medical record. This system provided the ability to check for concurrent drugs such as insulin and total parenteral nutrition (TPN) infusing on different pumps. If TPN is turned off and insulin continues infusing, an alert notifies clinicians of the inconsistency [16]. To the authors’ knowledge, no pump manufacturers currently provide this functionality on a per-patient basis.

Conclusions

A previously known patient was admitted to the ICU with gastrointestinal bleeding and an MI and was stabilized. One of the patient’s pumps, infusing dopamine, displayed “communication error” on the PCU display. Resolution was not intuitive, and the pump lacked clear instructions as to how to resolve the issue in the moment. The nurse disconnected the module to reprogram the pump, causing an interruption in the inotrope infusion, and subsequently the patient’s blood pressure decreased. It was concluded that the dirty contacts on the IUI connectors between the PCU and the modules caused the “communication error”. It was discovered that an oversight in cleaning technique caused this precipitous event. Learning yielded a nursing practice alert to clarify how a nurse should resolve a “communication error”, and appropriate cleaning protocols were promptly implemented. The investigation found that smart pump event logs and proprietary software are not designed with any forethought as to retrospective reconstruction of incident investigations, leaving facilities to cobble together pieces of information to elucidate the patient safety event. The authors suggest further pump enhancements, challenging pump manufacturers to go to the next level of integration and enable greater patient safety with smart infusion pumps.

“Communication error” resulting in the removal of the dopamine infusion module caused cessation in therapy, resulting in a decrease in the patient’s blood pressure.

Smart pump event logs and vendor software are not designed with any forethought as to retrospective reconstruction of patient safety events.

Infusion pump channels or multiple infusion pumps providing therapy to the same patient do not communicate as a patient-focused system.