HL7 MDM_T10 Document Replacement Notification and Content

HL7 message structure MDM_T02 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
Message Header Yes No
Software Segment No Yes
Event Type Yes No
Patient Identification Yes No
Patient Visit Yes No
MDM_T02.COMMON_ORDER
Common Order group No Yes
Common Order Yes No
MDM_T02.TIMING
Timing group No Yes
Timing/Quantity Yes No
Timing/Quantity Relationship No Yes
Observation Request Yes No
Notes and Comments No Yes
Transcription Document Header UAC User Authentication Credential Segment Yes No
MDM_T02.OBXNTE_SUPPGRP
Obxnte Suppgrp group Yes Yes
Observation/Result Yes No
Notes and Comments No Yes

MDM_T10 is the document replacement notification with content. It is used when a document that has been made available needs to be replaced by a new corrected document. The original document should not simply vanish; it normally becomes obsolete while the replacement document becomes the current version.

On the wire this is MDM^T10^MDM_T02. T10 is the replacement event, and MDM_T02 is the content-bearing document structure with TXA plus OBX content.

A small MDM_T10 example

MSH|^~\&|DOCSYS|CITYHOSP|EHR|CITYHOSP|20260716153000||MDM^T10^MDM_T02|MDM100001|P|2.5.1 EVN|T10|20260716152800 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|RAD^CT^^CITYHOSP||||55555^Reader^Riley TXA|1|RADRPT^Radiology Report^L|TX|20260716140000|55555^Reader^Riley|20260716150000|20260716152800|55555^Reader^Riley||||DOC20260716010|DOC20260716004^DOCSYS|ORD449200^EHR|AV OBX|1|TX|REPORT^Replacement report text^L||Corrected report: CT abdomen shows uncomplicated diverticulitis. This replaces document DOC20260716004.||||||F

What systems do with it

The sender is usually a reporting, transcription, radiology, cardiology, or document repository system. The receiver files the new document, marks the old document as replaced or obsolete, links the two, and displays the replacement in a way that preserves audit history.

TXA carries the document header and the relationship to the prior document. OBX carries the replacement content. The receiver should not treat this as an addendum, because the replacement is meant to supersede the prior document rather than sit beside it as additional commentary.

How to read the structure

T10 uses the MDM_T02 structure: MSH, EVN, PID, PV1, optional common-order context, required TXA, and required OBX/NTE content group. The important implementation detail is not just that the new content arrives, but that the new document is connected to the document it replaces.

Some systems use TXA parent document fields, status fields, or local profile fields to represent that relationship. Whatever the convention, document repositories and EHR viewers need enough information to avoid showing both reports as equally current.

Implementation traps

The biggest trap is losing the old document. Replacement should preserve history. A receiver may hide the obsolete document from normal clinical views, but it should still be available for audit and medico-legal reasons according to local policy.

The second trap is using T10 for a tiny post-final clarification that should have been an addendum. If the old document remains clinically meaningful and the new content is additional rather than superseding, T06 is usually the better pattern.

Reference notes

HL7 Chapter 9 describes T10 as document replacement notification and content, where the replacement has a new unique document ID linked to the original and the original becomes obsolete. Caristix summarizes T10 as replacement content sent after errors are corrected. Rhapsody groups T10 with the MDM events that contain document body content in OBX.