September 3, 2026 · 12 min read

IEC 62304 §6.2 / §7.4 / §5.2IEC 60601-1-8 §6.5 / IEC 80001-1ISO 14971 §10 / FDA Early Alert

When the Update Discharged the Patients: The GE HealthCare Portrait Mobile Early Alert Through an IEC 62304 and IEC 60601-1-8 Lens

A wearable monitoring system has one job that matters more than the others: keep knowing which patient it is watching. On August 21, 2026 the FDA published an Early Alert because, for a stretch of time during a routine software update, GE HealthCare's Portrait Mobile system stopped knowing. Nobody was hurt. The engineering lesson is worth more than the injury count suggests.

I have written before about recalls where the failure was a component. This one is different. The hardware worked. The sensors worked. The radio worked. What failed was the assumption, buried somewhere in a software maintenance plan, that an update is a maintenance activity rather than an operating state of a device with patients attached to it.

1. The public record

On July 20, 2026, GE HealthCare sent affected customers a letter with updated use instructions for all Portrait Mobile Monitoring Solution installations running Portrait Core Services software V1.0.5, V1.1 or V1.2. The FDA's Center for Devices and Radiological Health published an Early Alert on August 21, 2026, and the American Hospital Association pushed it to member hospitals on August 24. (FDA Early Alert; AHA News)

The affected articles are software, not hardware:

| Product | Ref Number | UDI-DI | | --- | --- | --- | | Portrait Core Services Software V1.1 | 5700209 | 00195278679284 | | Portrait Core Services Software V1.0.5 | 5697353 | 00195278364838 | | Portrait Compute and Core Services V1.2 | 5700592 | 00198953056752 | | FRU, Portrait Core Services SW Reload V1.1 | 5700225 | 00195278679307 |

The FDA's summary of the reason is short enough to quote in full: "during an update of Portrait Core Services software at a facility, some patients who were monitored on Portrait Mobile devices were discharged (removed) from the Portrait monitoring system. In addition, all alarm settings may be reset to factory defaults following the updates." The consequence, in the agency's words, "can result in a loss of patient monitoring or the intended alarms at the Hub and Central Viewer." (FDA Early Alert)

The correction is procedural. Facilities may continue using the system. Before starting any update they must "ensure appropriate alternative monitoring is established for patients," using a User Manual addendum GE HealthCare supplied for that purpose. As of July 29, 2026, no serious injuries or deaths had been reported. (24x7 Magazine; Respiratory Therapy)

Some context on the device. Portrait Mobile received 510(k) clearance on August 14, 2023. It is a smartphone-sized patient-worn monitor with wireless sensors for continuous respiration rate, SpO2 and pulse rate, aimed at post-surgical and step-down patients who would otherwise be spot-checked every four to six hours. The entire clinical argument for it is continuous surveillance of patients who are mobile and therefore not at a bedside where a nurse would notice them deteriorating. (GE HealthCare)

The architecture, as far as the public record describes it, has three tiers: the patient-worn monitor, a Hub at the care-area level, and a Central Viewer at the station. Portrait Core Services is the server-side layer that holds the patient census, the admission state of each monitor, and the alarm configuration per patient and per care area. Update that layer, and everything downstream depends on what it remembers when it comes back.

One more note on process. The Early Alert program began as a pilot in November 2024 and was extended to all device types on September 29, 2025. It exists to shorten the gap between FDA becoming aware of a potentially high-risk correction and the public hearing about it, before a formal recall classification is assigned. So the record here is a July 20 customer letter, a July 29 injury status, and an August 21 public notice - about a month between the vendor's action and the public's knowledge of it. (FDA - What is an Early Alert?)

2. The standards lens

Two failure modes are described, and they map to two different clauses.

Failure mode A: patients discharged during the update

IEC 62304 §6.2 (software maintenance process) requires that each modification go through a change request, a problem-resolution process, and, per §7.4 (risk management of software changes), an analysis of whether the change introduces new hazardous situations or affects existing risk control measures. That analysis has an obvious blind spot if the maintenance plan models the update as "server offline, then server online with new code." It does not model the interval, and it does not model the state transfer across the interval.

The relevant question at §7.4 is not "does version 1.2 behave correctly." It is "what does the system do to the admitted-patient list while version 1.1 stops and version 1.2 starts, and what does the Hub do if the census it receives afterwards is empty." Whatever the mechanism turned out to be - a database schema migration that dropped rows, a service that rebuilt its state from scratch and treated absent records as discharges, a Hub that interpreted a lost heartbeat as an end of session - the failure sits inside the transition, and the transition was not a modelled operating state.

IEC 62304 §5.2 (software requirements analysis), at §5.2.2, lists the categories that requirements must cover, including data definition and database requirements, and requirements related to installation and acceptance. A software system whose primary safety function is maintaining an association between a patient and a monitor should have an explicit requirement that this association persists across a restart of the service that owns it. If that requirement existed, the update was a verification failure. If it did not, it was a requirements failure. The public record does not say which, and from a patient's point of view it does not matter.

Failure mode B: alarm settings reset to factory defaults

This one has a dedicated clause. IEC 60601-1-8, the collateral standard for alarm systems in medical electrical equipment, addresses alarm presets at §6.5 and, specifically, what happens to alarm settings when power is interrupted at §6.5.5. The intent of that clause is well known to anyone who has designed a bedside monitor: a short interruption must not silently destroy the operator's configured limits, and a long interruption must either restore the previous settings or fall back to a defined preset in a way the operator is made aware of.

Portrait Core Services is not a bedside monitor and the update was not a power interruption. But the hazard is the same hazard the clause exists to control, and the Early Alert describes the exact outcome the clause was written to prevent: "the device will not follow the alarm settings previously configured for each patient or care area." A distributed monitoring system inherits the obligations of the monitor it replaces. If the alarm limit for a particular post-operative patient's SpO2 lives on a server, then the server's restart is that patient's power interruption, and §6.5.5 applies in spirit to the server even if the letter of the standard was written for a box on a pole.

There is a worse version of this failure than losing a tightened limit. Factory defaults are, by definition, tuned for a generic adult. Portrait Mobile is cleared for pediatric patients. A care area configured with pediatric respiration and pulse-rate limits that silently reverts to adult defaults will not alarm on values that are abnormal for a child. Nothing in the record says this happened. Everything in the record says the system was capable of it.

The hospital's side of the boundary

IEC 80001-1 exists because a device that lives on a hospital network is only half designed by its manufacturer. The responsible organization - the hospital - owns the risk management of the network and of changes to it, and a Core Services update is a change to a medical IT network in that standard's sense. What the July 20 letter does, in effect, is move a risk control measure from the manufacturer's side of that boundary to the hospital's: "establish alternative monitoring before starting an update." That is a legitimate interim control. It is also an admission that, for now, the system cannot be trusted to protect the patient through its own maintenance.

ISO 14971 §10 (production and post-production activities) is the clause that turns a single-site event into a fleet action. One facility's update surfaced the fault. The Early Alert covers every installation on three software versions. That widening is the process working as designed, and it is worth noting that the first public trigger was a field observation and not a verification result.

3. A worked snippet

Here is the fault tree I would expect a §7.4 change-risk analysis to have produced for the top event that actually occurred. It is not complicated. That is the point.

TOP: Patient on Portrait Mobile is unmonitored, or monitored with wrong
     alarm limits, following a Core Services update  [Hazardous situation]
|
+-- OR
    |
    +-- [A] Patient-monitor association lost across update
    |   |
    |   +-- OR
    |       +-- A1  Admission state held only in volatile memory of
    |       |       Core Services; not restored on restart
    |       +-- A2  Schema migration V1.x -> V1.y drops or invalidates
    |       |       admission records
    |       +-- A3  Hub treats loss of Core Services heartbeat longer
    |       |       than T_hb as end-of-session and auto-discharges
    |       +-- A4  Post-update census reconciliation absent; empty
    |               census accepted as valid
    |
    +-- [B] Alarm configuration replaced by factory preset
    |   |
    |   +-- OR
    |       +-- B1  Alarm settings stored in a versioned config store
    |       |       that the installer re-initialises
    |       +-- B2  Migration cannot parse prior config format and
    |       |       falls back to default without raising a
    |       |       technical alarm
    |       +-- B3  Per-care-area presets not persisted separately
    |               from per-patient settings; one reset clears both
    |
    +-- [C] No independent alarming during the outage
        |
        +-- AND
            +-- C1  Patient-worn monitor depends on Core Services for
            |       limit values (no local copy)
            +-- C2  Hub has no degraded-mode local alarming

Two things stand out once it is drawn. Branch C is an AND gate, which means either a local copy of the limits on the wearable or a degraded-mode Hub would have kept the patient covered through the entire update regardless of what happened in branches A and B. And branch A4 is a detection failure, not a fault: a five-line reconciliation check comparing the pre-update and post-update admitted count would have converted a silent discharge into a technical alarm at the Central Viewer.

The same analysis as an FMEA row set, using the software-FMEA convention with Action Priority rather than RPN:

| ID | Function | Failure mode | Effect | S | O | D | AP | Recommended action | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | SW-F-01 | Persist patient admission state | State not restored after Core Services restart | Patient silently discharged; no alarms at Hub or Central Viewer | 9 | 4 | 7 | High | Non-volatile admission store; restore-on-start; census reconciliation with technical alarm | | SW-F-02 | Persist alarm settings per patient and care area | Settings replaced by factory preset after update | Alarms fire at wrong limits; pediatric limits revert to adult | 9 | 4 | 8 | High | Versioned config with migration test; refuse to start with unparseable config; technical alarm on any preset fallback | | SW-F-03 | Continue alarming during server unavailability | Hub and wearable have no local limits | No alarms for duration of update | 9 | 5 | 3 | High | Cache limits on Hub and wearable; degraded-mode local alarming with Hub-level technical alarm | | SW-F-04 | Gate update start on patient census | Installer proceeds with patients admitted | Update occurs during active monitoring | 7 | 6 | 2 | High | Pre-flight check displays admitted count; require explicit acknowledgement; log operator identity |

Severity 9 is justified because the intended use of the device is early detection of deterioration in patients nobody is otherwise watching continuously; loss of monitoring defeats the reason the patient is wearing it. Detection 7 and 8 reflect a failure that produces no alarm and looks, from the Central Viewer, like a legitimately discharged patient.

4. Derived requirements (excerpt)

These are written as software requirements at the IEC 62304 §5.2 level, traceable to the FMEA rows above. Numeric values are my engineering proposals, not GE HealthCare's.

| ID | Requirement | Trace | | --- | --- | --- | | SW-REQ-PCS-101 | Core Services shall persist the admission state of every monitor (patient identifier, monitor identifier, care area, admission timestamp) in non-volatile storage, and shall restore all admissions within 60 s of service start without operator action. | SW-F-01 | | SW-REQ-PCS-102 | Core Services shall persist per-patient and per-care-area alarm settings in a schema-versioned store. Any software update shall include a tested migration for every supported prior schema version. If migration fails for any record, the service shall not start in normal mode and shall raise a technical alarm at the Central Viewer identifying the affected patients. | SW-F-02 | | SW-REQ-PCS-103 | The update installer shall, before stopping any service, query the current admitted-patient count and display it to the operator. If the count is greater than zero, the installer shall require an explicit acknowledgement that alternative monitoring is in place, and shall log the operator identity and timestamp. | SW-F-04 | | SW-REQ-PCS-104 | Within 120 s of completing an update, Core Services shall compare the post-update admitted-patient set and alarm-configuration hash against values captured before the update. Any difference shall raise a high-priority technical alarm at the Central Viewer and the affected Hub. | SW-F-01, SW-F-02 | | SW-REQ-PCS-105 | The patient-worn monitor and the Hub shall each hold a local copy of the active alarm limits for every admitted patient, and shall continue to generate physiological alarms locally for not less than 30 min after loss of communication with Core Services, while indicating a technical alarm for the communication loss. | SW-F-03 |

SW-REQ-PCS-105 is the one I would fight for hardest in a design review. It does not depend on the update going well. It does not depend on anyone reading the addendum. It makes the server's availability irrelevant to whether a patient whose SpO2 is falling gets an alarm, which is where the safety argument for a distributed monitoring system needs to rest.

5. What the headline really tells us

The Early Alert reads like an IT incident: an update went wrong, the vendor issued a workaround, patch to follow. That is the wrong frame. A software update on a monitoring platform is a planned, foreseeable, repeated operating condition of a medical device with patients attached to it, and a change risk analysis under IEC 62304 §7.4 that does not model the update interval as its own state, with its own hazards, has not analysed the change. The alarm-preset reset is the same lesson from a different direction: IEC 60601-1-8 §6.5 has told monitor designers for two decades that alarm settings must survive interruptions, and moving the settings to a server does not repeal the clause. The missing artifact is not a bug fix. It is the fault tree in section 3, written before the installer shipped, with branch C closed by design.

6. Sources

— Jherrod Thomas, The Lion of Functional Safety™