HL7 MDM_T02 Original Document 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_T02 is a medical document management message for a newly created document with its content included. It is common around transcription, radiology reports, scanned or generated clinical documents, consult notes, operative reports, and other workflows where the receiver needs the document header and the document body.

It overlaps with ORU_R01 in the real world because both can carry report-like content. The useful distinction is that MDM is explicitly about a document: document identity, activity, status, authoring, authentication, and content. ORU is more naturally an observation result workflow.

A small MDM document example

MSH|^~\&|DOCSYS|CITYHOSP|EHR|CITYHOSP|20260715164000||MDM^T02^MDM_T02|MDM00002|P|2.5.1 EVN|T02|20260715163800 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|RAD^XRAY^^CITYHOSP||||55555^Reader^Riley TXA|1|RADRPT^Radiology Report^L|TX|20260715153000|55555^Reader^Riley|20260715161000|20260715163800|55555^Reader^Riley||||DOC20260715001|ORD448900^EHR|LAB998900^RAD|AU OBX|1|TX|REPORT^Report text^L||Chest x-ray shows no acute cardiopulmonary abnormality.||||||F

What systems do with it

The sender is usually a document system, transcription platform, radiology system, specialty system, or integration engine. The receiver stores the document, attaches it to the patient and visit, updates document status, and may notify clinicians that the report is available.

TXA is the document header. It identifies the document type, activity dates, author, originator, document number, parent document if any, order links, availability, and completion/authentication state. OBX carries the document content, often as TX, FT, ED, or another value type depending on the profile.

How to read the structure

The v2.5.1 structure starts with MSH, EVN, PID, and PV1. Optional common order groups can link the document back to an order through ORC and OBR. TXA is required, and at least one OBX/NTE support group carries the content or related notes.

Document identifiers need to be stable. If a corrected document arrives later, the receiver must know whether it replaces the previous document, appends to it, or creates a new version. That answer usually depends on TXA fields and local document status rules.

Implementation traps

Large documents can stress interface tooling. ED-encoded PDFs, images, or long text in OBX-5 need careful size limits, logging rules, and retry behavior. It is easy to make a test message that works and a production report that quietly exceeds a string, database, or UI limit.

Also avoid treating every OBX in MDM like a lab result. In MDM_T02, OBX is often the document body or document payload. It may not belong in a flowsheet, trend graph, or result table.

Reference notes

HL7 Chapter 9 describes document notification messages as updates created when documents are completed, transcribed, authenticated, or otherwise changed. Vendor references such as iNTERFACEWARE's MDM overview and the Caristix MDM_T02 definition describe T02 as an original document notification that includes content.