Programming infusion pumps has been recognized as a high-risk activity and a source of adverse events. Infusion pumps can look similar but function differently for reasons such as inconsistent software versions, leading to use errors and potential for patient harm. This case highlights the benefits of multi-disciplinary team investigation and collaborative learning following an infusion safety event.

A previously healthy patient presented in Emergency (ED) and was diagnosed with community-acquired pneumonia and respiratory failure. Four hours later, the patient’s oxygen levels could not be maintained via facemask and he required intubation and ventilation. A standard infusion of NORepinephrine ­– a high-alert medication – was started to maintain his declining blood pressure. The patient was stabilized and moved to the intensive care unit (ICU) where approximately nine hours later the nurse discovered that the pump had ”overinfused” and delivered too much medication. The patient went into cardiac arrest. A Code Blue was called, and the patient was successfully resuscitated and recovered. The pump was sent to Biomedical Engineering (BME) for analysis.

Investigation

A multi-disciplinary team at St. Paul’s Hospital carried out an extensive review of the incident. They conducted a retrospective analysis of the pump’s logs, interviewed the healthcare staff involved, and completed a thorough investigation of all similar pumps in use at the hospital.

Collaborative learning and positive communication was important throughout the investigation. Nurses from both the ED and ICU took part, along with staff from BME, and hospital leaders were kept well-informed throughout the process. The team focused on the pump involved in this case but they also wanted to ensure other pumps currently in use were safe and functioning as expected.

Outcome

The team determined that the pump had been working as intended. Investigation of the pump’s event log revealed that the clinician incorrectly programmed the pump as a loading dose instead of a primary rate. The pump was also found to have an older software version, which did not clear historical values. So, the historical volume-to-be-infused (VTBI) for the loading dose was never cleared, and when the pump completed the VTBI it correctly reverted back to the primary rate, which was set at 80 times the prescribed rate for the patient, resulting in the overinfusion. 

Software Version 2.79

Software Version 4.54

Clinician Prompt “New Patient?” (Version 4.54)

If the pump had been upgraded to the latest software – from v2.79 to v4.54 – it would have asked the Yes/No question, “New Patient?” If the clinician had answered “Yes”, the historical values would have been cleared and the clinician would have been prompted to manually key in the correct dose for the new patient, which might have helped prevent this event from happening.

The hospital has since identified outdated version 2.79 pumps and either upgraded them or decommissioned their use. 

Andrew Ibey, Manager, BME, says, “This case was really eye-opening. We came together as a group to focus on one event but we’re continuing to examine how we operate as a system to improve patient care.”

Key takeaways:

1. Standardize all pump software versions in the hospital.
2. Re-educate clinical staff on proper use of loading dose function.
3. Report patient safety events in BC PSLS, to the pump manufacturer, and to the appropriate regulatory body.
4. Consider for the future: Dose error reduction software (DERS) pumps.
5. A collaborative approach to learning from patient safety events fosters a culture of safety and positive relationships among healthcare teams, and ultimately improves patient experience and safety.

Learn more about:

• Inadvertent overinfusion of norepinephrine using infusion pump loading dose
• Accreditation Canada Required Organization Practices 2016 – Infusion Pump Safety
• Canadian Incident Analysis Framework – Canadian Patient Safety Institute (2012)
• High-Alert Medications – Institute for Safe Medication Practices (2014)