Hospital Infusion-Pump Software Recalls: Why Dose Delivery Became a Software-Safety Problem

Modern infusion pumps are programmable medication-delivery computers

Infusion pumps regulate fluids and drugs that may have narrow therapeutic margins. Modern systems combine embedded software, drug libraries, alarms, networking, electronic-medication interfaces, and centralized management. That sophistication can reduce manual errors, but it also creates software failure modes. FDA recall records for the BD Alaris platform show how defects in programming, alarms, communications, and system integration can affect whether a patient receives the intended dose.^[1]

Automation moves risk rather than eliminating it

A smart pump can prevent some arithmetic mistakes while creating new dependencies on configuration, software state, interfaces, and network behavior.

The 2020 Alaris recall bundled several distinct software hazards

A major 2020 recall covered software versions associated with multiple problems: system errors that could prevent setting changes, delay-option behavior, low-battery alarm failures, alarm-priority issues, and custom-concentration entry problems.^[1] The diversity matters. A medical device does not have one “software risk.” Different components can fail independently, and each failure may produce a different clinical consequence such as interrupted therapy, missed completion, or incorrect concentration.

Remediation itself required a controlled software-release process

In 2021, BD announced a software remediation programme intended to address issues from the earlier recall, including operational and cybersecurity updates.^[2] Updating a fleet of infusion pumps is not like updating a consumer application. Hospitals must validate versions, schedule devices out of service, preserve drug-library compatibility, train users, and ensure that the update does not introduce new workflow problems. Patch management becomes part of clinical operations.

Medical software updates carry their own deployment risk

A fix can improve safety only if hospitals can identify every affected device, install the correct version, and verify the resulting configuration.

Network integration created new ways for stale or delayed data to affect dosing

In 2025, FDA highlighted a serious software correction involving Alaris Systems Manager and a care-coordination infusion adapter. Delayed system response could backlog automated programming requests, after which an outdated request might appear on a pump with rate, dose, or volume parameters no longer current.^[3] This is a distributed-systems failure in a clinical setting: data can be valid when created but unsafe when delivered too late.

Connectivity failures can force a safe-looking system back into manual operation

An earlier recall involving Alaris PC Units described network failures that could prevent pumps from receiving new datasets or exchanging data with electronic medication and admission systems.^[4] Clinicians could continue by programming pumps manually, but that fallback removes some automated cross-checks. Systems therefore need explicit degraded modes whose risks are understood and communicated.

Graceful degradation must include human workload

A fallback is not truly safe if it technically preserves function while shifting a large, error-prone burden onto clinicians without warning or support.

Recurring recalls reveal the difficulty of maintaining a long-lived device platform

Infusion systems remain deployed for years while networking environments, cybersecurity expectations, hospital interfaces, and drug libraries evolve. FDA’s recall database continued to list new Alaris-related actions into 2026.^[5] Long service life means medical-device manufacturers must support software under conditions that did not exist when the hardware was first designed. Architecture decisions about updateability, logging, isolation, and interface contracts therefore have long-term safety consequences.

Alarm behavior is software behavior

In medication delivery, alarms define when humans are expected to intervene. Priority errors, missing low-battery warnings, or ambiguous end-of-infusion behavior can turn a recoverable condition into delayed care. Alarm logic deserves the same requirements discipline as dose calculation because it shapes operator attention under workload. The 2020 recall makes clear that safety can depend on when software decides to interrupt, notify, or remain silent.^[1]

Human attention is a scarce resource

Too many alarms cause fatigue, but missing or incorrectly prioritized alarms create invisible hazards. Alarm engineering is therefore a balancing problem, not a binary on/off feature.

Why infusion-pump recalls belong in software-failure history

Infusion pumps demonstrate how embedded software becomes part of treatment itself. The system decides what parameters are displayed, when a request is accepted, how alarms are prioritized, and whether networked data is current. Recalls show that failures can arise from local code, distributed timing, interface assumptions, or operational update processes.^[2][3]

The broad lesson is that medical-device software needs lifecycle safety engineering. Manufacturers and hospitals must monitor field behavior, preserve auditability, validate updates, test degraded modes, and treat interoperability latency as a clinical concern. The pump may be physically small, but the software system around it now extends across the hospital network.

The recurring Alaris actions also show why hospitals need their own software inventory rather than relying solely on vendor notices. A recall may apply only to particular hardware, network cards, interface modules, or software versions. Biomedical engineering and clinical IT teams therefore need asset records precise enough to identify affected devices quickly, quarantine risky configurations, schedule remediation, and verify completion. Without that operational data, even a well-written safety notice may not reach the exact pumps that require action.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES

1. 01
   FDA — Class I Recall: CareFusion Alaris Pump Module, 2020 ↗accessdata.fda.gov
2. 02
   FDA — BD to Begin Remediation for BD Alaris System Software ↗fda.gov
3. 03
   FDA — Alaris Software Correction for Outdated Automated Programming Requests ↗fda.gov
4. 04
   FDA — Recall: Alaris PC Unit Network Connection Failure ↗accessdata.fda.gov
5. 05
   FDA — Alaris Pump Recall Database Results ↗accessdata.fda.gov

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.