HL7 MDM Document Messages:
The Complete T01-T10 Reference

Most of the clinical narrative in a hospital — H&P notes, operative reports, discharge summaries, radiology reads, pathology reports, consult notes, progress notes — never lives in structured HL7 fields. It lives in dictated or typed documents. And those documents reach the EHR (and the HIE, and the billing system, and the data warehouse) over HL7 v2 MDM messages.

This reference covers every MDM trigger from T01 through T10, breaks down the unique document segments (TXA and the document-bearing OBX), explains how CDA and other binary formats ride inside MDM, walks through real sample messages, and details the Mirth Connect channel patterns we use for production document pipelines. For broader HL7 context, start with our HL7 integration guide and HL7 v2 message structure explained.

If you are integrating a transcription vendor, a pathology reporting system, or a radiology voice-recognition platform into your EHR, our Mirth Connect helpdesk and services team have built these document pipelines for US hospitals, radiology groups, and reference pathology labs.

1. What MDM Is

MDM stands for Medical Document Management. MDM messages communicate the creation, modification, and status changes of clinical documents between systems.

Typical MDM scenarios:

• Transcription system emits a dictated note to the EHR as a T02.
• Radiology voice recognition system emits a preliminary read as T02, then a final as T08 when signed.
• Pathology LIS emits a cytology/surgical report as T02.
• Cardiology reporting system emits an echo/cath report as T02.
• A provider amends a note — the system emits T06 or T08.
• A document is retracted (wrong patient) — the system emits T04 with a cancelled status or T10 replacement.

MDM volume is lower than ADT or lab, but the clinical impact is high. A missed or misrouted radiology read can delay surgery; a lost pathology report can delay cancer treatment. MDM pipelines deserve robust monitoring.

2. T01-T10 Trigger Events

MDM triggers come in pairs — an odd-numbered "notification only" trigger and its even-numbered "notification with content" counterpart.

Most production integrations prefer the content-bearing variants (T02, T04, T06, T08, T10) to avoid a separate retrieval step. The notification-only variants (T01, T03, T05, T07, T09) are used when the document is too large to inline or when a store-and-forward model separates notification from retrieval.

3. TXA - Transcription Document Header

TXA is the document's metadata header. It identifies the document, who authored it, when it was dictated/transcribed/authenticated, and its status.

TXA|1|RAD^Radiology Report^L|TX^Text data^HL70191|20260421143000|1234567890^CHEN^VIVIAN^^^^MD^^^^^^NPI|20260421140000|20260421143000|||1234567890^CHEN^VIVIAN^^^^MD|DOC00012345^RAD_VR|RPT00067890^RAD_PACS||AUTH001^EPIC|||AU|AV|R|||1234567890^CHEN^VIVIAN^^^^MD

Key TXA fields

• TXA-1 Set ID.
• TXA-2 Document type (RAD, CN consult note, DS discharge summary, HP H&P, OP operative report, PN progress note, PC procedure note, SP surgical pathology, AP autopsy report).
• TXA-3 Document content presentation (TX text, FT formatted text, SD scanned document, NS non-scanned digital image).
• TXA-4 Activity date/time.
• TXA-5 Primary activity provider.
• TXA-6 Origination date/time (when dictated).
• TXA-7 Transcription date/time.
• TXA-8 Edit date/time.
• TXA-9 Originator code/name.
• TXA-10 Assigned document authenticator.
• TXA-11 Transcriptionist code/name.
• TXA-12 Unique document number — THE key identifier.
• TXA-13 Parent document number (for addenda/edits).
• TXA-14 Placer order number.
• TXA-15 Filler order number.
• TXA-16 Unique document file name.
• TXA-17 Document completion status.
• TXA-18 Document confidentiality status.
• TXA-19 Document availability status.
• TXA-20 Document storage status.
• TXA-22 Authentication person/time/stamp (repeating).

TXA-17 Document Completion Status

TXA-19 Document Availability Status

4. OBX for Document Content

Document content lives in OBX segments. Two OBX types dominate MDM:

Plain text (TX)

Each line of narrative becomes one OBX with value type TX. The set ID increments per line. Preserves line breaks via repetition.

OBX|1|TX|RAD^Report Body^L||CLINICAL HISTORY: 45-year-old female with low back pain for 6 weeks, radiating down the left leg.||||||F
OBX|2|TX|RAD^Report Body^L|||||||||F
OBX|3|TX|RAD^Report Body^L||TECHNIQUE: Multiplanar, multisequence MRI of the lumbar spine performed without contrast.||||||F
OBX|4|TX|RAD^Report Body^L|||||||||F
OBX|5|TX|RAD^Report Body^L||FINDINGS: The vertebral body heights are maintained. At L4-L5, there is a left paracentral disc protrusion measuring 6 mm, with mass effect on the left L5 nerve root. No acute fracture. Conus medullaris ends normally at L1.||||||F
OBX|6|TX|RAD^Report Body^L|||||||||F
OBX|7|TX|RAD^Report Body^L||IMPRESSION: L4-L5 left paracentral disc protrusion with mass effect on the left L5 nerve root, correlating with the patient's left leg radicular symptoms.||||||F

Encapsulated data (ED)

A single OBX with value type ED carries a complete binary document — PDF, TIFF, JPG, XML, CDA — base64-encoded inside OBX-5. The ED construct has 5 components: source application, type of data, subtype, encoding, data.

OBX|1|ED|CDA^CDA Document^L||RAD^TEXT^CDAR2^Base64^PHN1bW1hcnk+PHRpdGxlPlJhZGlvbG9neSBSZXBvcnQ8L3RpdGxlPjwvc3VtbWFyeT4=||||||F

Where the 5 components are:

• Component 1 - Source application (RAD)
• Component 2 - Type of data (TEXT, IMAGE, AUDIO, MULTIPART, APPLICATION)
• Component 3 - Subtype (PDF, TIFF, CDAR2, HTML, RTF, XML)
• Component 4 - Encoding (Base64, Hex, A no encoding)
• Component 5 - Data

5. T02 - Original Document Notification & Content

T02 is the workhorse MDM trigger — the most common message in a transcription-to-EHR pipeline.

Segment structure

• MSH — required
• EVN — required
• PID — required
• PV1 — optional
• TXA — required
• OBX — optional, repeating (document content)

Full T02 sample - Radiology report as plain text

MSH|^~\&|RAD_VR|GENERAL_HOSP|EPIC|GENERAL_HOSP|20260421143000||MDM^T02^MDM_T02|MSG0041234567|P|2.5
EVN|T02|20260421143000
PID|1||MRN45678^^^GENERAL_HOSP^MR||PATEL^RAJESH^K^^MR^^L||19740703|M||2028-9|456 PINE ST^^BELLEVUE^WA^98005
PV1|1|O|RAD^MRI1^^GENERAL_HOSP|||9999^CHEN^VIVIAN^^^^MD|||RAD||||||||||||||||||||||||||||||||||VN00078901
TXA|1|RAD^Radiology Report^L|TX|20260421143000|1234567890^CHEN^VIVIAN^^^^MD|20260421140000|20260421143000|||1234567890^CHEN^VIVIAN^^^^MD|DOC00012345^RAD_VR|RPT00067890^RAD_PACS||ORD009876^EPIC|||AU|AV|R|||1234567890^CHEN^VIVIAN^^^^MD
OBX|1|TX|RAD^Report Body^L||EXAM: MRI Lumbar Spine without contrast||||||F
OBX|2|TX|RAD^Report Body^L||DATE: 04/21/2026||||||F
OBX|3|TX|RAD^Report Body^L||CLINICAL HISTORY: 52-year-old male with low back pain for 6 weeks, radiating down the left leg. Failed conservative management.||||||F
OBX|4|TX|RAD^Report Body^L|||||||||F
OBX|5|TX|RAD^Report Body^L||TECHNIQUE: Multiplanar, multisequence MRI of the lumbar spine performed without IV contrast.||||||F
OBX|6|TX|RAD^Report Body^L|||||||||F
OBX|7|TX|RAD^Report Body^L||FINDINGS:||||||F
OBX|8|TX|RAD^Report Body^L||The vertebral body heights and alignment are maintained. Normal bone marrow signal.||||||F
OBX|9|TX|RAD^Report Body^L||L1-L2: Unremarkable.||||||F
OBX|10|TX|RAD^Report Body^L||L2-L3: Mild facet arthropathy, no significant stenosis.||||||F
OBX|11|TX|RAD^Report Body^L||L3-L4: Mild disc bulge without significant stenosis.||||||F
OBX|12|TX|RAD^Report Body^L||L4-L5: Left paracentral disc protrusion measuring 6 mm AP, with mass effect on the left L5 nerve root. Moderate left lateral recess stenosis.||||||F
OBX|13|TX|RAD^Report Body^L||L5-S1: Mild disc desiccation without focal protrusion or stenosis.||||||F
OBX|14|TX|RAD^Report Body^L|||||||||F
OBX|15|TX|RAD^Report Body^L||IMPRESSION:||||||F
OBX|16|TX|RAD^Report Body^L||1. L4-L5 left paracentral disc protrusion with mass effect on the left L5 nerve root, correlating with the patient's left leg radicular symptoms.||||||F
OBX|17|TX|RAD^Report Body^L||2. Mild multilevel degenerative changes as described.||||||F

Full T02 sample - Operative report with PDF attachment

MSH|^~\&|TRANSC|GENERAL_HOSP|EPIC|GENERAL_HOSP|20260421195500||MDM^T02^MDM_T02|MSG0041345678|P|2.5
EVN|T02|20260421195500
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD|||MED||||||||||||VN00045678
TXA|1|OP^Operative Report^L|AP^Scanned document^HL70191|20260421193000|1234567890^SMITH^JOHN^A^^^MD|20260421191500|20260421195500|||1234567890^SMITH^JOHN^A^^^MD|DOC00012346^TRANSC|RPT00067891^EPIC||ORD009877^EPIC|||AU|AV|R|||1234567890^SMITH^JOHN^A^^^MD
OBX|1|ED|OP^Operative Report^L||TRANSC^APPLICATION^PDF^Base64^JVBERi0xLjQKJeLjz9MKMTQgMCBvYmoKPDwvUHJvZHVjZXIoU2FtcGxlIFBERiBFbmNvZGVkIGRhdGEpPj4KZW5kb2JqCg==||||||F

6. T04 - Document Status Change

T04 updates the status of an existing document — typically moving from preliminary/unauthenticated (UN) to authenticated (AU) or legally authenticated (LA). The document body may or may not have changed.

MSH|^~\&|RAD_VR|GENERAL_HOSP|EPIC|GENERAL_HOSP|20260421145500||MDM^T04^MDM_T02|MSG0042456789|P|2.5
EVN|T04|20260421145500
PID|1||MRN45678^^^GENERAL_HOSP^MR||PATEL^RAJESH^K^^MR^^L||19740703|M
PV1|1|O|RAD^MRI1^^GENERAL_HOSP|||9999^CHEN^VIVIAN^^^^MD
TXA|1|RAD^Radiology Report^L|TX|20260421145500|1234567890^CHEN^VIVIAN^^^^MD|20260421140000|20260421145500|||1234567890^CHEN^VIVIAN^^^^MD|DOC00012345^RAD_VR|RPT00067890^RAD_PACS||ORD009876^EPIC|||LA|AV|R|||1234567890^CHEN^VIVIAN^^^^MD^^^^^^NPI&20260421145500
OBX|1|TX|RAD^Report Body^L||[Full report body as in T02 - unchanged, now legally authenticated]||||||F

Receiver pattern: locate the document by TXA-12 unique ID, update TXA-17 status, log the status transition in an audit trail, and re-present the document to end users with the updated status badge.

7. T06 - Document Addendum

T06 appends an addendum to an existing document. The addendum has its own unique ID in TXA-12; the parent document ID is carried in TXA-13.

MSH|^~\&|RAD_VR|GENERAL_HOSP|EPIC|GENERAL_HOSP|20260422101500||MDM^T06^MDM_T02|MSG0043567890|P|2.5
EVN|T06|20260422101500
PID|1||MRN45678^^^GENERAL_HOSP^MR||PATEL^RAJESH^K^^MR^^L||19740703|M
PV1|1|O|RAD^MRI1^^GENERAL_HOSP|||9999^CHEN^VIVIAN^^^^MD
TXA|1|RAD^Radiology Report Addendum^L|TX|20260422101500|1234567890^CHEN^VIVIAN^^^^MD|20260422100000|20260422101500|||1234567890^CHEN^VIVIAN^^^^MD|DOC00012347^RAD_VR|RPT00067892^RAD_PACS|DOC00012345^RAD_VR|ORD009876^EPIC|||AU|AV|R
OBX|1|TX|RAD^Addendum Body^L||ADDENDUM 04/22/2026 10:15 AM:||||||F
OBX|2|TX|RAD^Addendum Body^L||On re-review of the imaging, also noted is a 4 mm left L3-L4 foraminal disc protrusion with mild left L3 nerve root compression.||||||F
OBX|3|TX|RAD^Addendum Body^L||Recommend correlation with L3 radicular symptoms.||||||F
OBX|4|TX|RAD^Addendum Body^L|||||||||F
OBX|5|TX|RAD^Addendum Body^L||Electronically signed by Vivian Chen, MD at 04/22/2026 10:15 AM||||||F

8. T08 - Document Edit

T08 communicates an edit to an existing document — typically a typo correction, clarification, or minor revision. The edited document reuses the same TXA-12 unique ID (or increments to a new version, depending on the vendor).

MSH|^~\&|RAD_VR|GENERAL_HOSP|EPIC|GENERAL_HOSP|20260421150000||MDM^T08^MDM_T02|MSG0044678901|P|2.5
EVN|T08|20260421150000
PID|1||MRN45678^^^GENERAL_HOSP^MR||PATEL^RAJESH^K^^MR^^L||19740703|M
PV1|1|O|RAD^MRI1^^GENERAL_HOSP|||9999^CHEN^VIVIAN^^^^MD
TXA|1|RAD^Radiology Report^L|TX|20260421150000|1234567890^CHEN^VIVIAN^^^^MD|20260421140000|20260421150000|||1234567890^CHEN^VIVIAN^^^^MD|DOC00012345^RAD_VR|RPT00067890^RAD_PACS||ORD009876^EPIC|||AU|AV|R
OBX|1|TX|RAD^Report Body^L||EXAM: MRI Lumbar Spine without contrast||||||F
OBX|2|TX|RAD^Report Body^L||DATE: 04/21/2026||||||F
OBX|3|TX|RAD^Report Body^L||CLINICAL HISTORY: 52-year-old male with low back pain for 6 weeks, radiating down the LEFT leg. Failed conservative management. (EDIT: originally said right - corrected)||||||F
OBX|4|TX|RAD^Report Body^L||[remainder of report unchanged]||||||F

9. CDA in Base64 and Other Payloads

Carrying a CDA document inside an MDM message is a common interoperability pattern, especially for HIE and C-CDA exchanges.

T02 with C-CDA payload

MSH|^~\&|TRANSC|GENERAL_HOSP|HIE|REGION|20260421200000||MDM^T02^MDM_T02|MSG0045789012|P|2.5
EVN|T02|20260421200000
PID|1||MRN12345^^^GENERAL_HOSP^MR||DOE^JANE^MARIE^^MS^^L||19850412|F
PV1|1|I|7N^701^A^GENERAL_HOSP|E|||1234567890^SMITH^JOHN^A^^^MD
TXA|1|DS^Discharge Summary^L|SD^Structured document^HL70191|20260421195500|1234567890^SMITH^JOHN^A^^^MD|20260421190000|20260421195500|||1234567890^SMITH^JOHN^A^^^MD|DOC00012400^EPIC|||||AU|AV|R
OBX|1|ED|CDA^CDA Document^L||EPIC^TEXT^CDAR2^Base64^PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPENsaW5pY2FsRG9jdW1lbnQgeG1sbnM9InVybjpobDctb3JnOnYzIj4KICAgIDx0eXBlSWQgcm9vdD0iMi4xNi44NDAuMS4xMTM4ODMuMS4zIiBleHRlbnNpb249IlBPQ0RfSEQwMDAwNDAiLz4KICAgIDx0ZW1wbGF0ZUlkIHJvb3Q9IjIuMTYuODQwLjEuMTEzODgzLjEwLjIwLjIyLjEuMSIvPgogICAgPGlkIGV4dGVuc2lvbj0iRGlzY2hhcmdlU3VtbWFyeS1EMSIgcm9vdD0iMi4xNi44NDAuMS4xMTM4ODMuMTkuMS45OTkiLz4KICAgIDxjb2RlIGNvZGU9IjE4ODQyLTUiIGNvZGVTeXN0ZW09IjIuMTYuODQwLjEuMTEzODgzLjYuMSIvPgogICAgPHRpdGxlPkRpc2NoYXJnZSBTdW1tYXJ5PC90aXRsZT4KPC9DbGluaWNhbERvY3VtZW50Pg==||||||F

Decoding the CDA payload (receiver side)

// Mirth JavaScript - extract and decode CDA from OBX-5
var m = new XML(message);
var ed = m..OBX[0]['OBX.5'];
var subtype = ed['OBX.5.3'].toString();      // CDAR2
var encoding = ed['OBX.5.4'].toString();     // Base64
var data = ed['OBX.5.5'].toString();

if (encoding === 'Base64' && subtype.indexOf('CDA') !== -1) {
  var decoded = java.lang.String(
    java.util.Base64.getDecoder().decode(data), 'UTF-8'
  );
  channelMap.put('cdaXml', decoded);
  // Now XSLT or direct XPath on decoded to extract sections
}

Other common payload types

• PDF — APPLICATION^PDF^Base64 — common for scanned or fully-formatted reports.
• RTF — APPLICATION^RTF^Base64 — Microsoft-native transcription output.
• HTML — TEXT^HTML^Base64 — occasionally seen for formatted narrative.
• TIFF — IMAGE^TIFF^Base64 — for scanned paper documents.
• JPG/PNG — IMAGE^JPEG^Base64 — occasional embedded images.

10. Mirth Connect MDM Channel Patterns

10.1 Inbound document listener

• Source: MLLP listener on a dedicated MDM port.
• Inbound data type: HL7 v2.x. Set "encoding" to UTF-8.
• Message size: Bump the max message size — MDM with embedded binary can be 5-50MB per message.
• Preprocessor: Extract key metadata (document ID, type, patient MRN, trigger).
• Filter: Accept only MDM message types.

10.2 Document body extraction

// Concatenate all TX-type OBX values into a single narrative
var m = new XML(message);
var obxSegments = m..OBX;
var narrative = '';
for (var i = 0; i < obxSegments.length(); i++) {
  if (obxSegments[i]['OBX.2'].toString() === 'TX') {
    narrative += obxSegments[i]['OBX.5'].toString() + '\n';
  }
}
channelMap.put('documentNarrative', narrative);

// Detect binary attachment
var hasBinary = false;
for (var j = 0; j < obxSegments.length(); j++) {
  if (obxSegments[j]['OBX.2'].toString() === 'ED') {
    hasBinary = true;
    var ed = obxSegments[j]['OBX.5'];
    channelMap.put('binarySubtype', ed['OBX.5.3'].toString());
    channelMap.put('binaryEncoding', ed['OBX.5.4'].toString());
    channelMap.put('binaryData', ed['OBX.5.5'].toString());
  }
}
channelMap.put('hasBinaryAttachment', hasBinary);

10.3 Store to S3 / Azure Blob

// Destination: JavaScript writer to store large payloads externally
var docId = $('documentId');
var s3Key = 'mdm/' + docId + '.bin';
var decoded = java.util.Base64.getDecoder().decode($('binaryData').toString());

// Write to local filesystem (Mirth file writer), then sync to S3 out-of-band,
// or use AWS SDK directly via Mirth's code template library.
var fos = new java.io.FileOutputStream('/var/mdm-storage/' + docId + '.bin');
fos.write(decoded);
fos.close();

channelMap.put('storagePath', '/var/mdm-storage/' + docId + '.bin');

10.4 Mapping MDM to FHIR DocumentReference

// Transformer - MDM to FHIR DocumentReference
var fhir = {
  resourceType: 'DocumentReference',
  status: 'current',
  docStatus: mapTxaStatus($('txaStatus')),
  type: {
    coding: [{
      system: 'http://loinc.org',
      code: mapDocTypeToLoinc($('docType')),
      display: $('docTypeDisplay')
    }]
  },
  subject: { reference: 'Patient/' + $('patientMrn') },
  date: $('activityDateTime'),
  author: [{ reference: 'Practitioner/' + $('authorNpi') }],
  content: [{
    attachment: {
      contentType: mapMimeFromSubtype($('binarySubtype')),
      data: $('binaryData'),
      title: $('docTypeDisplay'),
      creation: $('activityDateTime')
    }
  }],
  context: { encounter: [{ reference: 'Encounter/' + $('visitNumber') }] }
};

10.5 Addendum linking

// On T06 addendum, link to the parent via TXA-13
var parentDocId = msg['TXA']['TXA.13']['TXA.13.1'].toString();
var newDocId    = msg['TXA']['TXA.12']['TXA.12.1'].toString();
channelMap.put('parentDocId', parentDocId);
channelMap.put('newDocId', newDocId);
// Downstream: INSERT addendum row + UPDATE parent row to flag "has addenda"

11. Common MDM Pitfalls

11.1 Message size limits

Default MLLP and Mirth settings assume small messages. A 20MB PDF-in-base64 hits those limits hard. Raise the MLLP max message size and JVM heap — see our post on the Java heap space error.

11.2 Losing line breaks in narrative

Transcribed narrative has meaningful structure — blank lines between sections, bullet indentation. Receivers that concatenate OBX-5 values without preserving line breaks destroy readability.

11.3 Duplicate documents on resends

MDM senders may resend messages on retry. Key your persistence by TXA-12 (unique document number), not by MSH-10, and UPSERT — never INSERT. Otherwise you end up with three copies of the same radiology read.

11.4 Mishandling addenda

An addendum is not a replacement. Preserve the original; append the addendum. Display chronologically. Do not overwrite.

11.5 Ignoring authentication status

Preliminary radiology reads get displayed in the EHR alongside final reads. If your system does not surface TXA-17 (completion status), providers may act on unverified reads.

11.6 Character set issues with dictated narrative

Dictated text often contains special characters — degree signs, mu (micro), greek letters, em-dashes. Encoding mismatch destroys these. Use UTF-8 end-to-end and test with real dictated content.

12. Frequently Asked Questions

Related Reading

• HL7 Integration: The Complete Guide
• FHIR Integration Guide
• EHR Integration Guide
• Healthcare Interoperability Guide
• Mirth Connect: The Complete Guide
• HL7 v2 Message Structure Explained
• HL7 v2 vs v3 vs FHIR
• HL7 ACK/NAK Explained
• MLLP Protocol Explained
• HL7 Testing Tools & Sample Messages
• Common HL7 Integration Errors
• HL7 ADT Messages Complete Reference
• HL7 ORM/ORU Lab Workflow
• HL7 SIU Scheduling Messages
• Mirth Connect MLLP Connection Refused
• Mirth Connect Java Heap Space Error
• Mirth Helpdesk
• Services
• Contact Us