Retransmitted Device Results: Is This a Duplicate or a Correction?

The decision behind a resent result

Treat a retransmitted device result as a duplicate only when the receiver can establish that it represents the same already-processed observation and unchanged clinical payload. Apply a correction when the message explicitly supersedes an identified prior result under the agreed interface profile. If identity or action is ambiguous, hold the update for resolution rather than silently adding or overwriting a clinical record.

For a laboratory analyzer or data manager sending to a laboratory information system (LIS), this requires two separate checks: which message was processed, and which observation is being updated. HL7 v2.5 provides message-control identifiers, acknowledgment codes, and observation-status semantics that help specify those checks. It does not supply a complete deduplication algorithm, determine every receiving-system workflow, or require every medical device to use HL7.

A useful starting point is FDA MAUDE report 2432235-2022-00213. The manufacturer reported that a receiving LIS mishandled Atellica Data Manager result aspect codes, leading to one falsely elevated prostate-specific antigen (PSA) result reaching a physician. After reconfiguration, the correct result was retransmitted and reported to the physician. The report describes a configuration mismatch, not a demonstrated failure of HL7 correction codes. It shows why verifying delivery alone cannot establish that the receiving system interpreted the result correctly.

• Transport recovery concerns the communications connection. A restored connection does not tell the application whether an earlier result was already processed.

• Application resend concerns a message sent again after an absent acknowledgment or another recovery action. The receiver needs enough evidence to identify a replay.

• Result correction concerns an intentional change to an identified prior observation. A repeat measurement is not automatically a correction; the sender and receiver must agree whether it is a new observation, a preliminary progression, or a replacement.

The worked ledger below is a design and verification proposal for this specific decision. For broader protocol selection, see the medical device interoperability guide. Here the focus is the narrower contract between a sender, any middleware, and the system that stores or presents the clinical result.

Message identity: what the acknowledgment proves

In HL7 v2.5 Chapter 2, MSH-10 identifies the message. The responding message has its own MSH-10; MSA-2 carries the initiating message control ID so the sender can associate the response with the correct request. An acknowledgment should therefore be interpreted using both its correlation field and its acknowledgment mode, rather than merely checking that some response arrived.

• AA reports successful application processing. It does not, by itself, certify a particular database transaction, correct clinician-facing display, or subsequent downstream delivery. Those meanings need an explicit interface contract and verification.

• AE is an application error response. AR may arise from unacceptable header values during initial validation or from an application unable to process the message for reasons unrelated to content or format. Implementers decide whether automatic retry is appropriate; repeating an unchanged message cannot be assumed to resolve its error.

• Enhanced acknowledgment distinguishes acceptance from application processing. CA, CE, and CR are commit-level accept, error, and reject codes. The requested responses depend on MSH-15/MSH-16 and the exchange rules; two acknowledgments are not universally required. Acceptance into safe storage is distinct from completion of the clinical application action.

Consider a synthetic lost-acknowledgment case. A receiver successfully processes message M1 and generates an AA with MSA-2=M1, but the response never reaches the sender. The sender cannot infer from the missing response whether processing happened. Its documented recovery policy might retry, reconcile status, or escalate. A timeout is evidence of uncertainty, not proof that the receiving database is empty.

For this proposed contract, journal message identity together with the sending application and facility, processing context, payload fingerprint, and processing outcome. If M1 reappears with an identical payload and a recorded successful outcome, avoid applying its clinical action again and return the corresponding response according to the profile. If the same identifier carries different data, treat that as an identifier collision. If the earlier attempt failed or remains in progress, do not convert it into a successful duplicate merely because its identifier is familiar.

A resend with a new identifier M2 needs a separate observation-level check. The new envelope identifies a new transmission, but does not establish that the clinical observation is new. Chapter 2 distinguishes its simple acknowledgment scheme from the sequence-number protocol used to prevent duplicate transactions on a transaction stream. Neither acknowledgment correlation nor a bare MSH-10 comparison should be presented as an end-to-end guarantee. Specify journal persistence, retention, restart behavior, and recovery after a lost response for the actual interface.

Result identity and supersession: OBX-11 and OBR-25

In HL7 v2.5 Chapter 7, section 7.4.2.11, the correction and deletion rules refer to the observation identifier and observation sub-ID, represented by OBX-3 and OBX-4. That pair identifies the relevant observation group within its report context. It is not a globally unique key across patients, orders, specimens, or repeated measurements. The proposed receiver contract also resolves sender identity, patient identifier and assigning authority, order/specimen context, and the particular observation instance before changing a record.

Pin the following meanings to HL7 v2.5 Table 0085 and the cited section. Other editions and implementation guides can differ, so document the exact version and local constraints used on both sides of the interface.

Chapter 7 also treats multiple OBX segments sharing both the observation ID and sub-ID as one replacement or deletion unit. In the proposed implementation, resolve and process that group together so the resulting observation does not combine incompatible revisions. This rule is about the group sharing both identifiers, not every segment with the same sub-ID throughout the message. The standard does not prescribe a particular database transaction mechanism or an immutable audit-table design.

OBR-25 expresses status at the report/order-detail level. The archived HL7 Australia v2.4 localization, section 4.4.1.25 recommends that an Australian corrected report contain all its OBX segments and carry OBR-25=C, with individual updated observations flagged through OBX-11. This is a versioned Australian implementation convention, not a universal regulatory requirement or evidence that all observations in such a report changed.

A report marked C can therefore contain unchanged final observations alongside corrected ones. Do not use OBR-25=C as a blanket instruction to replace every value. Agree how report completeness, unchanged segments, and individual observation statuses are handled. The ledger uses that complete-report convention where relevant, while keeping the actual observation action explicit.

A synthetic ledger for five receiver decisions

All identifiers below are fictitious. LAB-A is the sender; PAT-A includes its assigning authority; ORD-A and ORD-B identify distinct order/specimen contexts. TEST-X/1 denotes OBX-3/OBX-4 within that context. Values A and B are symbolic alternatives, not clinical measurements. Each row states its prerequisites; the status-only row starts from a separate stored preliminary observation, rather than following the corrected-final row.

Apply the following proposed receiver rule before deciding to store, supersede, or suppress. The sequence deliberately checks action semantics and prior state before any payload-equality shortcut:

1. Validate the envelope and processing state. Scope MSH-10 to its sender and processing context. An identical, already-successful transaction can be handled as a replay. Identifier reuse with changed content is a conflict; a previous failure or incomplete attempt needs its documented recovery path.

2. Resolve the observation target. Use patient authority, order/specimen identity, and the observation instance together with OBX-3/OBX-4. Check for incompatible patient or order associations. Hold unresolved identity before applying any action. A genuinely new F can be inserted only after these checks.

3. Apply explicit transitions to known prior state. C replaces the matching final group; D deletes the specified active result data; W marks the original wrong; U finalizes an existing preliminary observation without a new value. Keep these actions distinct. An unknown prior target must not become a new observation merely because a matching database row was absent.

4. For a new envelope carrying F, establish whether it is a replay or a distinct observation. Compare the complete agreed clinical payload, including units, flags, interpretation and relevant timing/context, along with observation provenance. The same number can occur in different specimens or measurements. Unexplained changes to a stored final result require resolution rather than silent overwrite.

5. Control ordering and recovery. Specify what happens when an older final arrives after a correction, a correction arrives before its original, or a restart loses an in-memory journal. Preserve the intended clinical state and recoverable processing outcome together. The five rows are a starting set, not exhaustive coverage.

6. Return the response for the actual completed outcome. In this proposed profile, an unresolved application conflict produces AE with error detail and the incoming control ID in MSA-2. A duplicate that was successfully handled can receive AA. Do not issue success merely because an exception was logged; define safe acceptance separately when using enhanced mode.

Verification should observe both message exchange and receiving-system state. For each case, record the message, precondition, stored observation count and status, revision relationship, clinician-facing result state where relevant, and acknowledgment correlation. Interrupt processing around the update and response to test the agreed recovery behavior. These are proposed assertions derived from the contract; they are not claims that an HL7 field alone enforces clinical visibility or that FDA names this particular test set.

Where the evidence goes in your documentation

FDA’s Content of Premarket Submissions for Device Software Functions was issued June 14, 2023 and superseded the May 2005 software guidance. It gives nonbinding documentation recommendations; it does not mandate this ledger, an HL7 protocol, a particular alert banner, or a deduplication algorithm. Use the mapping below to connect the interface decision to the recommended evidence, while determining the applicable regulatory requirements for the actual device.

• Software description: explain the result outputs, their recipients, and the communication methods, standards and specifications. For this example, identify which receiver performs deduplication and correction, which middleware transforms the message, and which version and implementation profile each boundary supports.

• Software requirements specification: the guidance covers inputs/outputs, interfaces, error handling, accepted ranges and limits, among other elements. Translate the ledger into testable requirements for identity resolution, acknowledgment meaning, timeouts, retention and exception behavior. These concrete choices are the team’s engineering specifications, not universal thresholds supplied by FDA.

• System and software architecture diagram: show the components and data flows. Make queues, persistent processing state, transformation boundaries and acknowledgment routes visible when needed to explain this design. Keep the SRS focused on required behavior and the software design specification focused on how the implementation achieves it.

• Risk management and verification traceability: link the identified hazardous situation to the interface requirement, implemented control and verification evidence. Traceability should let a reviewer find the test that demonstrates the required receiver outcome, rather than only a network-delivery screenshot.

Both Basic and Enhanced documentation recommendations include system-level protocols with expected and observed results, pass/fail determinations, and a system-level report. Enhanced adds unit- and integration-level protocols and reports to the Basic testing documentation. Enhanced is recommended when a software failure could create a hazardous situation with a probable risk of death or serious injury, assessed before risk controls and in the intended-use context. A connection to an acute-care LIS does not, by itself, determine the documentation level. Document the device-specific rationale.

FDA’s September 6, 2017 interoperable-device guidance recommends evaluating interface risks including delay, corrupted or wrongly formatted data, and unsynchronized information. It also addresses interface timeliness, information integrity, and identification of the standards and versions used. The proposed lost-response, stale-message, and conflicting-identity cases apply those broad considerations to this result interface; they are editorial examples, not verbatim FDA test requirements.

The 2023 software guidance now carries a QMSR transition notice: the amended quality-system regulation took effect February 2, 2026 and incorporates ISO 13485:2016 by reference. The notice explains that the QMSR does not use terms such as Design Controls and that their elements are described in clause 7.3 and its subclauses. Read the guidance’s older QS-regulation references with that notice. An HL7 implementation or an IEC 62304 process does not, by itself, establish compliance across jurisdictions. For the broader testing distinction, see the software verification and validation guide.

Two reported events and their verification lessons

The two retained MAUDE records are malfunction reports containing reporter and manufacturer narratives. They are useful failure scenarios, not validated incidence estimates or independent findings that a particular product is defective. Neither record supplies HL7 message traces, so neither verifies the ledger’s field-level implementation.

Atellica Data Manager, report 2432235-2022-00213, event date July 12, 2022: the manufacturer narrative says the LIS substituted a result aspect code for the actual PSA result. Validation used a test channel with aspect codes disabled; the go-live channel enabled them. The configuration was changed and the correct result retransmitted. Siemens attributed the event to an ADM setting unsupported by the LIS and stated that the analyzer was performing within specifications. No patient intervention or adverse health consequence was known in the report.

The practical inference is to preserve the production-relevant channel configuration in verification evidence. Record which optional fields are enabled, how the receiver maps them, and whether the retransmitted correction changes the intended clinical record. A successful test on a differently configured channel is weak evidence for the deployed configuration. This inference concerns interface verification; the record does not establish whether OBX-11 or OBR-25 was used incorrectly.

DL2000 Data Manager, report 2050012-2010-00479, event date June 23, 2010: the event narrative describes reuse of a sample ID for a different patient while an older urine-creatinine order remained pending. Staff ignored a warning about a tube sent twice for different patients; the new program was rejected and the unit attempted a urine-creatinine test on a serum sample. The narrative says the result was suppressed and patient treatment was not impacted. It also contains a statement that a result was reported outside the laboratory, so it should not be simplified into a claim that nothing was ever released.

The manufacturer’s follow-up also describes an ignored archive-request alert and attributes the event to customer error and the data manager. The supported lesson is that identifier reuse, retained pending state and response to warnings belong in verification and operational follow-up. The record does not establish alert fatigue, a buried warning, or a universal requirement for a positive acknowledgment button. Choose blocking, escalation and reconciliation behavior through the device-specific risk assessment and agreed receiving workflow.

For go-live and later changes, reconcile unresolved resends and corrections, review identifier collisions, and check that exception messages reach the responsible operator. Preserve the configuration and software version associated with each investigation. These proposed practices connect the two reported failure scenarios to observable evidence: one result processed once, a correction applied to the right prior record, and ambiguous patient associations held for resolution. They do not turn two historical reports into a frequency estimate or a claim of guaranteed patient safety.