After a Network Reconnect: Can Medical Devices Show Old Data as Current?

The Direct Answer: Define What Counts as Current

Consider an illustrative scenario: the link between a bedside monitor and a central station disappears for 90 seconds, then returns. The central display still holds the last received heart rate and waveform. May it resume presenting those samples as live? A successful reconnect alone is insufficient. The product needs evidence that the samples satisfy its specified freshness criteria before the display represents them as current.

Stored values can remain useful for historical review, but their presentation should make that role clear to the intended user. If age or availability cannot be established reliably, the interface needs a defined response that avoids implying current monitoring. These are risk-based design conclusions for this scenario, rather than a quotation of a universal FDA prohibition on displaying old data. A timestamp alone does not establish that a particular presentation is safe.

First determine the function’s intended use. FDA’s Digital Health Policy Navigator, Step 5 distinguishes software solely transferring, storing, converting formats or displaying device data from functions that analyze or interpret it. It identifies alarms, prioritization on multi-patient displays and active monitoring for immediate clinical action as device-function considerations. Assess the actual function and applicable requirements; neither the presence of a screen nor a connection icon establishes its regulatory pathway.

For manufacturers subject to the applicable quality-system requirements, FDA’s QMSR overview confirms that the revised 21 CFR Part 820 took effect on February 2, 2026 and incorporates ISO 13485:2016. The current software-guidance cover note locates the elements formerly called Design Controls and Design Validation in clause 7.3 and its subclauses. Keep reconnect requirements, risk decisions and verification within that design-and-development framework, rather than treating the display as a cosmetic feature.

What FDA Guidance Supports

FDA’s final September 6, 2017 interoperability guidance recommends addressing information timing, synchronization and interface failures in the device description, risk analysis, testing and labeling. Its recommendations support the following questions. The guidance is nonbinding except where it cites applicable statutory or regulatory requirements; it does not mandate the particular interface or architecture proposed here.

• What timing and integrity requirements apply to information exchanged through the interface? Specify the relevant sampling, transmission and update characteristics, and the synchronization method.

• How can delayed, corrupted or time-mismatched information create a hazardous situation? Consider boundary conditions, fault tolerance and the safe behavior of critical functions.

• Which verification results and interface limitations support the intended interoperability claims? Explain the supported configuration and what users need to understand about failures.

Translate those questions into product requirements. A team might define a maximum acceptable sample age for a specific parameter, when a missing update changes its presentation, and what conditions allow the display to return to current status. Derive the actual limits from intended use and risk analysis. Do not borrow a timeout from another monitor, a vendor blog or this article. Sampling frequency, display refresh frequency and acceptable end-to-end age describe different parts of the data path.

Why Connected and Current Are Different States

A connection event describes part of the communication path. It does not by itself show when a measurement was acquired, whether it was queued during the outage, whether the receiver has processed it, or whether it belongs to the correct patient session. Reconnecting can therefore coexist with historical backfill, missing intervals or an unresolved clock relationship. Testing only the return of a network-status icon misses those conditions.

For the proposed matrix, use three separate presentation concepts. Current means the value meets the product’s specified validity and freshness conditions. Historical means its earlier acquisition context is known and clearly conveyed. Unavailable means there is no usable value for the current task, including cases where freshness cannot be established. A channel can have historical data while current monitoring remains unavailable; the software should not force both into one green connected state.

The CitrusBits BLE reconnection article also recommends separating link and synchronization status and identifying information that is stale or incomplete. That is useful practitioner framing from a software-services vendor, rather than regulatory authority. The additional task for an RA/QA team is to connect each chosen behavior to a requirement, risk control and observed test result.

Define the timing reference explicitly. Reception time may be recent even when the underlying measurement was acquired before the outage. If acquisition timestamps are used, document their clock relationship and uncertainty. If reliable acquisition timing is unavailable, specify how the system detects that limitation and changes its display claims. Different channels may need different freshness decisions; the recovery of one parameter should not automatically clear another parameter’s unavailable indication.

What the Recall and Adverse Event Reports Show

The FDA Class 2 recall record Z-2243-2026 lists a firm initiation date of April 24, 2026 and a software-design cause. Its reason describes potential ECG and SpO2 monitoring loss involving ApexPro CARESCAPE Telemetry Server versions 5.0 and 6.0 after persistent NO COMM or OFF NETWORK conditions at the central station. The specific product entry concerns v5.0; the reason covers both versions.

The recorded correction directs affected users to alternative bedside monitoring, notification of the relevant facility department and GE HealthCare, and verification that monitoring is restored. These are product-specific instructions. The record supports taking network-loss recovery seriously; it does not establish a stale-display defect, reported injury, or a universal fallback architecture for other devices.

On October 23, 2026, the exact openFDA device-event query for “stale data” returned a metadata total of 19 matching records and five returned results; its dataset update date was October 13, 2026. The total is a phrase-query result, not 19 verified network-reconnection incidents. It can change with database updates. Selected returned narratives illustrate why attribution matters:

• IntelliVue X3, report 9610816-2025-000418, received May 23, 2025: intermittent pressure-waveform hanging was reported. The manufacturer requested clarification about static or prior data, could not reproduce the issue and reported an unknown cause; no patient or user harm was reported.

• Medtronic ICD, report 9614453-2026-00461, event January 28, 2026: the record is coded Injury and describes therapy and hardware problems. Its narrative separately attributes incorrect displayed measurements to stale data from software processing. It does not establish that the display issue caused injury or arose during network reconnection.

• Avalon FM20, report 9610816-2022-00295: the narrative describes freezing and a return to a patient screen with stale data. Repair identified a faulty main board; no adverse event to the patient or user was reported.

These are reporter and manufacturer narratives, not FDA causation findings. Phrase selection, incomplete reporting and possible duplicate reports limit interpretation; the query supplies no denominator for estimating incidence. Use these cases to challenge design assumptions, rather than counting them as evidence of one shared mechanism.

The Disconnect/Reconnect State Matrix: Editorial Proposal

The following matrix translates the retained evidence into a proposed engineering review aid. It is not an FDA-named test set or a declaration of compliance. “Proposed indication” and “alarm review” identify decisions the manufacturer must resolve for its device; they do not prescribe wording, color, priority or timing. Substitute approved, measurable requirements before using any row as a test protocol.

Review the transitions between rows as well as the steady states. In the 90-second scenario, a central station might receive an old packet immediately after reconnecting. A useful test asks whether that packet is identified correctly, whether the current-data indication remains conditional, and what observation permits the display to resume current status. The duration is an illustrative scenario stimulus, not a regulatory threshold or acceptance criterion.

For each transition, record the triggering observation, the affected channels, the user-visible state, the risk-control reference and the recovery condition. Include repeated loss during backfill and recovery of only some channels. This makes it possible to review whether the proposed state machine has an undefined path without assuming that every product implements the same network protocol or storage design.

Reconnect Edge Cases to Include in the Evidence Review

Silent Loss and Detection Limits

A cable-disconnect test and a stalled-data test answer different questions. Plan a test where the communication association remains present but the application stops delivering usable samples. Observe whether freshness is assessed from the samples themselves, what happens when the detection interval expires, and whether the intended user can recognize the resulting limitation. Choose a heartbeat, timeout or another detection mechanism through the architecture and risk process; none is universally mandated by the cited guidance.

Backfill and Delayed Clinical Events

Define whether the receiver processes current and historical data separately and how it prevents backfill from being mistaken for live monitoring. If live and historical traffic share resources, test the worst supported backlog and concurrent load against the approved performance limits. A separate physical channel is one possible implementation, not a universal requirement. The evidence should establish the promised behavior, whichever architecture implements it.

Delayed alarm information needs its own risk decision. Blanket suppression of all historical alerts may conceal clinically important events, while presenting an old event as happening now may also mislead users. Specify the intended delayed-event notification, its timing context and any interaction with current alarms, then test both. For result-message identity after reconnection, use the separate duplicate-versus-correction guide; that decision does not establish whether a waveform is current.

Clock Relationships, Capacity and Patient Context

A clock correction can change the apparent age or ordering of buffered samples. Define how acquisition time, receipt time and sequence information relate, including what happens when clocks disagree or synchronization is unavailable. Monotonic timing can be a design option for elapsed intervals, but it does not by itself reconcile clocks on different devices. Verify the chosen approach. The timestamp and repeated-hour guide addresses the separate calendar-time problem.

Outage duration can exceed buffer capacity, and a reconnect can occur after a patient-session change. Define which records remain, how missing intervals are identified and how data is associated with the intended patient and endpoint before presentation resumes. Do not assume an IP address alone establishes identity. Avoid prescribing a particular authentication technology without the product’s security and interoperability analysis.

Test a full buffer, a restarted gateway and a changed patient association as separate scenarios when they are relevant to the design. Their freshness consequences differ. The storage-full guide covers recording and export continuity, while the power-recovery guide covers retained state after restart. Here, the question remains what the receiver can truthfully show after communication recovers.

Writing the Test Protocol: Expected and Actual Results

The final June 14, 2023 device-software submission guidance uses a risk-based documentation level. Evaluate foreseeable software hazards before controls. A hospital-network patient monitor is an Enhanced example, but connectivity alone does not assign the level. Section VI.H recommends system-level protocols and reports for Basic documentation too; Enhanced additionally includes all unit and integration protocols and reports. Expected results, recorded actual results and objective pass/fail determinations are central to both.

The protocol template below is an editorial extension of the state matrix. It contains no executed tests or product performance claims. Replace each reference to a specified limit or response with the approved requirement identifier and its measurable criterion. Record the software and firmware builds, network configuration, receiver version, enabled channels, test equipment and timing method so another reviewer can interpret the observations.

An observed return of a green icon cannot alone close a freshness requirement. Use a known source sequence or simulator with an independent observation method to establish what the display actually represented. Reconcile the source data, receiver processing and visible output; explain timestamp uncertainty and instrument limitations. Screenshots may document wording, but a single screenshot does not establish a transition time or show that an entire recovered sequence was handled correctly.

Maintain traceability from each hazard and requirement to the selected cases, their results and unresolved anomalies. Rerun affected cases when a relevant change alters recovery behavior. FDA’s January 2002 General Principles of Software Validation supplies the general validation context. The public IEC 62304:2006 catalogue entry describes medical-device software lifecycle scope; it does not establish clause-level conformity. This proposed matrix cannot certify compliance with the complete standard or validate a finished device.

Label the Limits Users Need During Recovery

The interoperability guidance’s labeling recommendations support communicating the interface purpose, supported configurations, relevant performance characteristics, synchronization method, failure behavior and limitations. Match the documentation to what was specified and tested. A monitor’s sampling rate does not tell a user how old a centrally displayed measurement can become, and restoring the network does not necessarily mean every channel or alarm function has recovered.

• Explain what current, historical and unavailable mean for the intended workflow, including how any age indicator is calculated and when its accuracy is limited.

• State the supported network and endpoint conditions relevant to the interface claims, without importing unverified Wi-Fi, bandwidth or time-server specifications.

• Describe which monitoring and alarm functions remain available during interruption, which depend on the connection, and how restoration is recognized.

• Provide the product-specific response to persistent interruption or incomplete recovery, consistent with verified capabilities and the intended users’ responsibilities.

Review the interface and instructions together with representative intended users where appropriate. A warning buried in an operator manual does not demonstrate that a user will recognize an old value on the screen. Conversely, a prominent status badge is not evidence that every underlying risk has been controlled. The release evidence should support the actual presentation and recovery claims: which data is current, which remains historical, which is unavailable and what the user can rely on during each transition.