When the Battery Lies and the UI Freezes

An infusion pump that lies about its remaining battery and freezes its own interface when a clinician fat-fingers a leading zero is not a bug story. It is a Class C medical device software story — and a Class I FDA recall — and the artifacts that should have caught both anomalies are not exotic. They are the ones the standard already names: an ISO 14971 risk row, a software unit test with boundary coverage, and an IEC 60601-1-8 alarm conformance entry.

The public story is short and uncomfortable. On November 14, 2025, Fresenius Kabi sent customers an Urgent Medical Device Correction letter for the Ivenix Large Volume Pump (LVP). On February 25, 2026, the FDA classified the action as Class I — the most serious recall designation, reserved for situations where there is a reasonable probability that use of the product will cause serious adverse health consequences or death. (FDA recall page, FDA early-alert correction page.)

Two software anomalies, both in Ivenix LVP Software version 5.10.1 and earlier (product code LVP-SW-0005). Two reported serious injuries. Zero deaths so far. The fix is a software upgrade to 5.10.2 paired with an Infusion Management System update to 5.2.2.

The framing that the trade press chose was "infusion pump software has bugs again," which is true and useless. The interesting question is which clauses of which standards should have caught these anomalies before a patient was harmed. So let me put the rows in the table.

1. The public record

What the regulator said, what the manufacturer said, what the press did with it.

The two anomalies, verbatim from the FDA correction notice. The first is a battery state-of-charge defect: "Ivenix LVPs operating for extended periods on battery power may inaccurately report remaining battery capacity, resulting in unexpected shutdown without the standard low-battery alarm sequence (30, 15, 5, and 1 minute remaining). Pumps with greater accumulated battery usage are more susceptible to this issue." The second is a UI state-machine defect: "If a rate with two leading zeros (e.g., 0010) is entered on the LVP that exceeds drug library limits, pressing 'Back' or 'OK' on the Set Rate screen causes the pump to enter a fail-stop alarm state, freezing the LVP interface." (FDA correction notice.)

The harm. Both modes interrupt or delay infusion therapy. On a Large Volume Pump, the drugs that flow through it are not aspirin — they're vasopressors, sedatives, paralytics, chemotherapeutics, parenteral nutrition. An unannounced shutdown of a norepinephrine infusion in an ICU is a matter of minutes between "patient stable" and "patient coding." Two serious injuries had been reported as of November 18, 2025. (MedTech Dive coverage, AABB regulatory update.)

Mitigations the manufacturer asked for, until the patch arrives. Keep pumps on AC power. Don't program rates with two leading zeros. (Manufacturing Chemist.) Both are correct workarounds. Neither is acceptable as a substitute for engineering — "please instruct your nurses not to type 0010" is a paper mitigation, not a control.

Context this is the second one. This is not Fresenius Kabi's first Class I action on Ivenix in recent memory. There was a separate Class I recall earlier covering mechanical interference between the LVP cassette and infusion sets, and another covering reverse flow on certain administration sets. (Fierce Biotech on the second pump recall.) The pattern matters for the standards lens; one Class I in a quarter is bad luck, three is a process signal.

2. The standards lens

Three standards govern an LVP at this layer. Each one has a clause that maps directly onto one of these anomalies.

IEC 62304 — Medical device software life cycle. An LVP is unambiguously Software Safety Class C under §4.3: the software can contribute to a hazardous situation that could result in death or serious injury, and there is no external risk control (a hardware mechanical limiter, a separate watchdog circuit, or a clinician-in-the-loop check) that reduces the resulting risk to acceptable. Class C demands the full V-model: software architecture documented to the unit level (§5.3), unit verification with a defined coverage criterion (§5.5), integration testing (§5.6), system testing (§5.7), and a documented anomaly resolution process (§9). Both Ivenix anomalies are §5.5 / §5.6 misses — one in a numeric estimator, one in a UI state machine.

ISO 14971 — Application of risk management to medical devices. §5 (risk analysis) and §7 (risk control) require that every reasonably foreseeable hazard linked to a hazardous situation be enumerated and a control allocated. Both failure modes are foreseeable. "Battery indicator becomes inaccurate as the cell ages" is a routine risk row on every battery-powered safety-critical device built since the early 2000s. "User enters a value with leading zeros" is in every published list of input-validation hazards going back to the 1980s. If those rows weren't in the Ivenix risk file at the right severity, the gap is in the risk file — not in the code.

IEC 60601-1-8 — General requirements for alarm systems in medical electrical equipment. §6.3.3.4 requires that an alarm system signal degraded states (including imminent loss of power) at the appropriate priority. The 30/15/5/1-minute low-battery escalation in the Ivenix UI is a specific implementation of this requirement. When the SoC estimator is wrong, the alarm system's trigger never fires — and the pump quietly dies under a clinician who believed the screen.

21 CFR Part 820 — FDA Quality System Regulation. §820.30 (design controls) — specifically design verification (§820.30(f)) and design validation (§820.30(g)) — is the regulatory hammer. A Class I recall typically forces a CAPA root-cause investigation that lands on the V&V plan and the verification evidence for the changed software unit. Why didn't the verification protocol cover the leading-zero pattern? and why didn't the SoC verification span the full battery-aging envelope? are the two questions an FDA inspector will ask first.

3. Worked snippet — ISO 14971 risk rows that should have existed

These are the two rows I would expect to see in the risk management file for any infusion pump in 2025, regardless of vendor. Severity is per ISO 14971 Annex C; harm semantics here use the AAMI TIR57-style five-level scale (Negligible / Minor / Serious / Critical / Catastrophic).

| Risk ID | Hazard | Foreseeable sequence of events | Hazardous situation | Harm | Severity | Probability of occurrence (P1·P2) | Risk before control | Risk control(s) | Risk after control | |---|---|---|---|---|---|---|---|---|---| | RM-PWR-014 | Inaccurate battery state-of-charge under aged-cell conditions | (1) Battery cell capacity degrades with cycle count and calendar age. (2) SoC estimator uses a static nominal capacity in its coulomb-counting model. (3) On a unit with high accumulated cycles, the estimator over-reports remaining time. (4) Pump shuts down without firing the 30/15/5/1-minute alarm sequence required by IEC 60601-1-8. | Active infusion of a continuous critical drug (e.g., vasopressor) terminates without warning, in a context where the clinician relied on the displayed remaining time. | Hemodynamic collapse; death | Catastrophic | High (any unit with > N battery cycles is exposed) | Unacceptable | (a) SoC estimator shall use a state-of-health-corrected capacity model; (b) SoC accuracy shall be verified across the full warranted battery-life envelope, not nominal-only; (c) On any SoC-confidence drop below threshold, the pump shall escalate to High-priority alarm regardless of the calculated remaining time. | Acceptable | | RM-UI-027 | Operator-input pattern places UI in unrecoverable state | (1) Clinician enters infusion rate with leading-zero pattern (e.g., 0010 µg/kg/min). (2) Value exceeds drug library hard limit. (3) Set Rate screen state machine has no guarded transition for the (over-limit + leading-zero + Back/OK) tuple. (4) UI enters fail-stop alarm; clinician cannot recover or reprogram on the pump face. | Active or pending infusion is delayed while the unit is unrecoverable; staff must take the pump out of service mid-therapy. | Delay or interruption of critical-drug therapy; serious injury | Critical | Medium (depends on drug library configuration and clinician keypad habits) | Unacceptable | (a) Input validation shall reject the pattern at the keypress layer with a clear soft-error message — not a fail-stop alarm; (b) Set Rate state machine shall have an explicit "input rejected, return to ready" transition for every error class; (c) Unit tests shall enumerate boundary inputs including leading zeros, trailing zeros, and decimal-position permutations against every drug-library limit. | Acceptable |

If those rows had been in the file at those severities, the controls listed would have been V&V deliverables. The recall is the consequence of a control that wasn't allocated, or was allocated and not verified at the right rigor.

4. Worked snippet — IEC 62304 software unit verification gap

Both anomalies trace back to a missing verification artifact at the unit level. Class C software requires §5.5.5 unit-level testing with a documented pass/fail acceptance criterion. The architecture sketch below shows where each anomaly lives and the unit test that should have failed first.

LVP application software (Class C)
├── ui_layer/
│   ├── set_rate_screen.c         <- Anomaly #2 lives here
│   │     state machine: IDLE -> ENTRY -> VALIDATE -> {ACCEPT|REJECT} -> IDLE
│   │     missing guarded transition: VALIDATE -> REJECT
│   │       on (rate.leading_zeros >= 2 AND rate > drug_library.upper_limit)
│   └── alarm_priority_router.c
├── infusion_control/
│   ├── flow_setpoint.c
│   └── drug_library.c
├── power_management/
│   ├── soc_estimator.c            <- Anomaly #1 lives here
│   │     model: SoC(t) = SoC(0) - integral(I(t)/C_nominal)
│   │     defect: C_nominal is not adjusted for SoH(cycle_count, calendar_age)
│   │     on aged units the estimator overshoots actual remaining capacity
│   ├── soh_tracker.c              <- exists, but its output is not consumed
│   └── battery_alarm_escalator.c  <- driven by SoC, inherits the error
└── platform/
    ├── osal/
    └── log/

Unit tests that should have failed:

• test_set_rate_screen_rejects_leading_zero_overlimit_input() — exercise every (leading-zero count × value × drug-library limit) tuple; assert UI returns to IDLE with a RATE_REJECTED event, not a FAIL_STOP_ALARM event. Coverage requirement: boundary value analysis per IEC 62304 §5.5 with branch coverage on the validate state.
• test_soc_estimator_accuracy_across_battery_aging_envelope() — feed simulated current profiles at 0/250/500/750/1000 charge cycles against measured cell capacity, assert SoC error stays within ±X% of true remaining minutes through the full warranted life, not only at "fresh battery" calibration. Coverage requirement: equivalence-class testing across the SoH envelope, traced to risk control RM-PWR-014(b).

If the unit-test plan didn't include those two cases, the V&V plan didn't satisfy IEC 62304 §5.5.5 for those units. That is the audit-finding form of this recall.

5. Worked snippet — IEC 60601-1-8 alarm conformance row

The low-battery escalation sequence (30/15/5/1 minutes) is itself a conformance claim against IEC 60601-1-8. When the upstream SoC estimator is wrong, every claim downstream of it inherits that error. The conformance row should have included a negative test for that case.

| Conformance ID | Clause | Requirement | Test method | Pass criterion | Result | |---|---|---|---|---|---| | CC-ALM-014 | IEC 60601-1-8 §6.3.3.4 | Alarm system shall annunciate impending loss of essential operating power | Run pump on battery to depletion, on units representing the full warranted battery-life envelope (fresh, mid-life, end-of-life) | High-priority alarm asserted no later than the documented escalation thresholds (≥ 30 min, ≥ 15 min, ≥ 5 min, ≥ 1 min remaining), with audio + visual signaling, on every unit population in the envelope | Failed on aged units — alarm sequence skipped; pump shut down without High-priority annunciation |

That one row, run on aged batteries instead of only on fresh ones, would have surfaced the defect before customer release.

6. Derived requirements (excerpt, traceable IDs)

These are the requirements I would expect to see added to the next baseline, with traceability to the standards clauses that demand them.

• REQ-IVX-PWR-101 — The State-of-Charge estimator shall consume the State-of-Health output of the battery health tracker and apply it as an SoH-corrected capacity term in the coulomb-counting model. (Trace: ISO 14971 RM-PWR-014; IEC 62304 §5.3 architecture.)
• REQ-IVX-PWR-102 — The pump shall verify SoC accuracy across cycle counts of {0, 250, 500, 750, 1000} and calendar ages of {0, 1, 2, 3} years against measured cell capacity, with an end-of-life threshold of ±10 % of true remaining minutes; failure of any envelope point is a Class C V&V failure. (Trace: IEC 62304 §5.5.5; IEC 60601-2-24 §201.12.)
• REQ-IVX-PWR-103 — On any SoC confidence interval > X % (i.e., the estimator itself is uncertain), the pump shall declare a High-priority alarm independent of the calculated remaining time, per IEC 60601-1-8 §6.3.3.4.
• REQ-IVX-UI-201 — The Set Rate state machine shall include a guarded transition VALIDATE → REJECT for every error class, including over-limit values entered with N ≥ 1 leading zeros, with a soft-error annunciation that returns the UI to a programmable state without entering Fail-Stop. (Trace: ISO 14971 RM-UI-027; IEC 62366-1 usability.)
• REQ-IVX-UI-202 — Unit tests for the rate-entry path shall enumerate boundary inputs spanning {leading-zero count, trailing-zero count, decimal-position} × {below limit, at limit, above limit} for each drug in the library; pass criterion is no Fail-Stop transitions on any input that the keypad can produce. (Trace: IEC 62304 §5.5.5 boundary value analysis.)

A traceability matrix that maps these five requirements back to the two ISO 14971 risk rows and forward to the IEC 62304 unit tests is the actual deliverable. The Markdown table is just a teaser for it.

7. What the headline really tells us

The press version of this story is "infusion pump software has another bug." The engineering version is more specific and more useful. Two anomalies in the Ivenix LVP correspond to two missing artifacts:

• A risk row for "battery indicator drifts on aged cells" with a Catastrophic severity and a control that mandates SoH-corrected capacity in the SoC model — and a verification protocol that exercises the SoH envelope, not a fresh-battery sample.
• A risk row for "input pattern places UI in unrecoverable state" with a Critical severity and a control that requires every rate-entry error class to have an explicit, soft-error transition — and a unit test that enumerates boundary inputs against every drug-library limit.

Neither of those is invention. Both are routine Class C deliverables under IEC 62304 and ISO 14971. The recall is what happens when those deliverables are partial. The fix that ships with software 5.10.2 will close the two findings. The systemic fix is to ask, on the next program review, which other rows in the risk file have controls that were allocated but not verified across the full envelope? That is the question that prevents the next Class I.

If you're a medical-device program lead or a software-of-medical-device manager reading this and you don't have the equivalent rows in your live ISO 14971 file with the IEC 62304 unit tests pinned to them — or if you have them but the verification stops at "fresh battery / nominal input" — the gap is the actionable thing, not the headline.

— Jherrod Thomas, The Lion of Functional Safety™