Jherrod ThomasThe Lion of Functional Safety™

May 20, 2026 · 14 min read

ISO 14971IEC 62304ISO 14708-2

When the Safe State Wasn't Safe: The ACCOLADE Pacemaker Class I Recall

A pacemaker has exactly one job, and a pacemaker for a pacemaker-dependent patient has exactly one job with no second chances. So when a device decides — on its own — to drop into a fixed-rate fallback mode and stay there, the interesting question is never "why did the battery do that." It's "who decided that fallback was safe, and against which operating context did they check?"

The Boston Scientific ACCOLADE recall is being reported as a battery story. It isn't. The battery defect is real, but the battery is not what put four patients in the adverse-event count. What did that was a risk control measure — a designed safe state — that was specified once, against one scenario, and never re-evaluated against the patient who would actually be wearing it when it fired.

This is a medical-device story, so the automotive vocabulary stays in its box. No ASILs here. The lenses that matter are ISO 14971 (risk management), IEC 62304 (medical device software life cycle), and ISO 14708-2 (the particular standard for implantable cardiac pacemakers).

1. The public record

On May 7, 2026, the FDA published its correction notice for the ACCOLADE family of pacemakers and cardiac resynchronization therapy pacemakers (CRT-Ps), and identified it as the most serious recall class — a Class I recall, the FDA tier reserved for situations with a reasonable probability of serious injury or death. The action is recall event 98615, a follow-up to recalls 97467 (August 2025) and 95969 (December 2024). It covers more than 1.4 million devices across the ACCOLADE, PROPONENT, ESSENTIO, and ALTRUA 2 pacemaker lines plus the VISIONIST and VALITUDE CRT-Ps. As of March 18, 2026, Boston Scientific had reported four deaths and 2,557 serious injuries associated with the issue (FDA, Pacemaker Correction: Boston Scientific Issues Correction for ACCOLADE Pacemakers and CRT-Ps, May 7, 2026).

The failure chain is worth stating precisely, because every link is an engineering decision. A battery cathode processing technique left a subpopulation of devices with a higher concentration of lithium salts, which is associated with high battery impedance later in device life. High impedance produces a voltage sag during high-power operations — chiefly telemetry interrogation. A deep enough sag triggers a power-on reset. And here is the latch: three power-on resets within a 48-hour window cause the device to enter Safety Mode (Heart Rhythm Society, Revised Notice — Boston Scientific ACCOLADE Family Pacemakers, May 8, 2026).

Safety Mode is not a graceful degradation. The device shifts to VVI pacing at 72.5 bpm, 5.0 V at 1.0 ms, with pacing and sensing in unipolar mode — fixed, non-programmable, and effectively irreversible without explanting the device. HRS spelled out the clinical consequence in plain language: Safety Mode "could lead to pacing inhibition and pauses (e.g. due to myopotential inhibition), muscle stimulation (e.g. skeletal muscle or phrenic nerve stimulation), heart failure decompensation, or rapid battery depletion." Of the deaths in the Q1 2026 product performance data, three patients whose devices activated Safety Mode experienced syncope requiring hospitalization and later died; one died after the replacement procedure (HRS, May 8, 2026).

Then there is the software saga, which is its own lesson. The December 2024 recall (95969) was information only. In August 2025, Boston Scientific shipped Brady SMR5, a firmware update designed to detect elevated battery impedance via a telemetry-activated battery test, raise fault code FC1003 ("Voltage Too Low for Remaining Battery Capacity"), and disable ZIP wandless telemetry before impedance could progress far enough to provoke Safety Mode. Within weeks, SMR5 had defects of its own: it disabled active telemetry but not RF wake-ups, and it produced a magnet-induced false-positive impedance result that disabled telemetry and threw a bogus explant alert. A third issue — a prolonged voltage-recovery state that could leave battery diagnostics stuck — was caught internally before any field report. Brady SMR6, released March 19, 2026, resolves those behaviors and expands the advisory to every CRT-P and DR-EL device, citing a 7.6% probability of early device replacement from impedance-induced telemetry disablement (FDA, May 7, 2026).

So: a battery defect, a fallback mode, a software fix, and a software fix for the software fix. Four recall events in fifteen months. The standards have something to say about every one of those.

2. The standards lens

First, a precision note, because the word "class" is doing two jobs in this story and people conflate them. FDA "Class I recall" is an enforcement classification — the most serious of three. It is not a software safety class. A pacemaker's firmware is IEC 62304 software safety Class C — the class assigned where death or serious injury is possible. Two different scales, two different documents. If someone uses them interchangeably, they have read neither.

Safety Mode is a risk control measure. That is the whole case. It exists to keep a patient paced when the device's normal logic can no longer be trusted. ISO 14971 §7.4 and §10.1 are explicit that risk control measures must themselves be analyzed — you evaluate whether the control introduces new hazards or new hazardous situations. Safety Mode introduces several. Fixed-rate VVI at 72.5 bpm gives a pacemaker-dependent patient no rate response when they stand up or climb stairs. Unipolar sensing is materially more susceptible to myopotential oversensing than the bipolar configuration most patients are actually programmed to — and oversensing inhibits pacing output. There is no AV synchrony. That configuration is "safe" relative to the failure it was designed for: a device that has lost its programmed parameters and needs some backup output on a bench. It is not safe relative to the operating context it actually lands in — an ambulatory, pacemaker-dependent human being.

That is the missing artifact. Not a clever algorithm — a row in a table. A hazard analysis entry for the risk control measure itself, evaluated against the defined patient operating states: at-rest, ambulatory, exercising, pacemaker-dependent versus non-dependent. If that row exists, Safety Mode either gets a context-aware design or, at minimum, an alarm that announces "I am in a degraded mode" loudly and immediately. Today it does neither.

Second, the trigger logic. "Three power-on resets within 48 hours" is an availability heuristic. It answers a reasonable question — "how do I know this device is unhealthy?" — but it never answers the question ISO 14971 actually requires: is the resulting mode worse than the condition I am protecting against, given who is wearing it? A threshold derived from device-health telemetry is not the same thing as a threshold derived from a harm comparison. The standard wants the second one.

Third, IEC 62304 and the SMR5 regression. SMR5 was a §6 software maintenance change, and it was itself deployed as a risk control. It then introduced two field-confirmed defects. IEC 62304 §6.2.1.1 and §6.3 require that a maintenance change get a change-impact analysis and re-verification proportionate to its safety class — and for Class C software that envelope must be wide. The SMR5 envelope plainly did not include RF wake-up paths or magnet-present states. Neither is exotic. A pacemaker encounters a magnet routinely; clinicians use one to run threshold tests. ISO 14971 closes the loop: SMR5 was a risk control measure that created new risks, and the change analysis should have surfaced them before release rather than the field doing it afterward.

Fourth, the alarm regression. SMR6 changed the notification behavior so that a device with ZIP disabled by high impedance posts to a remote-monitoring "Patient Not Monitored" page after 14 days, instead of generating an active "Remote Monitoring Disabled" alert. Read that slowly: a pacemaker-dependent patient can be effectively unmonitored for up to two weeks with no active notification to anyone. That is an alarm-system design decision. Measured against the alarm-prioritization philosophy that IEC 60601-1-8 codifies for medical electrical systems — match alarm priority to the urgency of the underlying condition — a 14-day silent latency on a state that precedes a potentially life-threatening mode is a low-priority response to a high-priority condition.

3. A worked snippet

ISO 14971 risk analysis — the rows that should already exist

Risk is the combination of severity and probability of harm. Probability is decomposed here into P1 (probability of the hazardous situation) and P2 (probability the hazardous situation leads to harm). Severity scale: Negligible / Minor / Serious / Critical / Catastrophic.

| ID | Hazard | Foreseeable sequence of events | Hazardous situation | Harm | Severity | P1 × P2 | Risk | |---|---|---|---|---|---|---|---| | RM-SM-01 | Inappropriate fixed-rate / inhibited pacing | High battery impedance late in life → voltage sag on telemetry → 3 or more power-on resets in 48 h → device latches Safety Mode (unipolar VVI 72.5) | Pacemaker-dependent patient is ambulatory in fixed-rate unipolar VVI; myopotential oversensing inhibits output | Syncope, fall injury, death | Catastrophic | Occasional × Probable | Unacceptable | | RM-SM-02 | Delayed detection of degraded operating mode | ZIP disabled by impedance; remote status posts to "Patient Not Monitored" after 14 days with no active alert | Clinician unaware patient is unmonitored / in degraded mode for up to 14 days | Delayed intervention; harm from undetected Safety Mode | Catastrophic | Occasional × Occasional | Undesirable | | RM-SM-03 | False end-of-service indication | Battery impedance test runs with magnet present → false-positive result | Unnecessary telemetry disablement and erroneous explant prompt | Premature device explant; surgical risk | Critical | Probable × Remote | Undesirable |

The point of RM-SM-01 is that the risk control measure (Safety Mode) is the source of the hazardous situation. That is exactly the case ISO 14971 §7.4 tells you to evaluate, and it is the case that, on the evidence of the design, was not evaluated against the ambulatory patient state.

Fault tree — top event: loss of effective demand pacing in an ambulatory pacemaker-dependent patient

Top: Loss of effective demand pacing — ambulatory pacemaker-dependent patient
        OR
        ├── A. Device latches Safety Mode in an ambulatory context
        │       AND
        │       ├── A1. High battery impedance late in device life
        │       │        (cathode lithium-salt concentration)
        │       ├── A2. Voltage sag during high-power telemetry triggers
        │       │        3 or more power-on resets within 48 h
        │       └── A3. Safety Mode entry condition not gated on patient
        │                context (pacing-dependency / activity state)
        ├── B. Unipolar VVI configuration inhibits pacing output
        │       OR
        │       ├── B1. Myopotential oversensing on the unipolar sense channel
        │       └── B2. No rate response and no AV synchrony for an active patient
        └── C. Degraded mode not detected in time to intervene
                OR
                ├── C1. No immediate, high-priority alert on Safety Mode entry
                └── C2. ZIP disabled; remote status posts only after a 14-day lag

Gate A is an AND gate, and A3 is the leaf nobody expanded. Defects A1 and A2 are genuinely hard — a cathode process change is a real metallurgy problem. But A3 is free. It costs one requirement and one design review. With A3 removed as a contributor, gate A cannot complete, and the entire top event is starved on its dominant path.

Software-change FMEA — the SMR5 release (S/O/D, 1–5 scale)

| SMR5 change item | Failure mode | Effect | S | O | D | Risk | |---|---|---|---|---|---|---| | Disable ZIP telemetry on high impedance | Disablement omits the RF wake-up path | Device still reachable by telemetry that can provoke Safety Mode | 5 | 4 | 4 | High | | Telemetry-activated battery impedance test | Magnet present produces a false-positive impedance result | Telemetry disabled unnecessarily; false explant alert raised | 4 | 3 | 3 | Medium | | Battery test state machine | Prolonged voltage-recovery state | Battery status / diagnostics stuck | 4 | 2 | 5 | Medium |

Every one of these three rows is a regression that a change-impact analysis scoped to "all telemetry paths and all magnet states" would have flagged before SMR5 shipped — which is the entire point of IEC 62304 §6.

4. Derived requirements (excerpt)

Every ID above traces to a row in §3: SR-SM-001 and SR-SM-003 to leaf A3 and to RM-SM-01; SR-SM-002 to leaf C2 and RM-SM-02; SR-SM-004 and SR-SM-005 to the SMR5 FMEA and RM-SM-03. That traceability is the deliverable. The requirements are not the hard part — connecting them back to a hazard nobody had written down is.

5. What the headline really tells us

The headline is "1.4 million pacemakers recalled, four deaths." The engineering story is smaller and more uncomfortable than that.

The battery defect is real, and a cathode process change is a legitimate, difficult problem. But the battery is not what hurt these patients. What hurt them is that the device's designed response to a battery problem — Safety Mode — was specified against a single scenario and never re-evaluated against the patient inside the operating context it would actually fire in. A fallback mode is a risk control measure. ISO 14971 is unambiguous that a risk control measure is itself a thing you analyze for new hazards. The missing artifact here is one hazard-analysis row — Safety Mode, evaluated per patient operating state — and the immediate, high-priority alarm requirement that row would have forced.

Everything downstream of that gap, including a software release (SMR5) that had to be recalled and replaced by a second software release (SMR6), is the compounding cost of not writing the row. A safe state that has not been validated against its operating context is not a safe state. It is just a state — and the standard already told you to check.

If you build implantable or life-supporting devices and your fallback modes do not each have their own hazard-analysis row and their own derived alarm requirement, that gap is the actionable item — not the recall notice. The contact link on the main site is the fastest way to reach me if you want to walk through how that row gets built.

— Jherrod Thomas, The Lion of Functional Safety™

Sources