HL7 MDM Messages Explained: T01, T02, T10 and T11 with a T02 Example

Mirth Connect MDM channels handle something the other HL7 message types can't: the narrative clinical record. HL7 ADT tells you where a patient went. ORU tells you what their labs showed. MDM — Medical Document Management — tells you what the clinician actually wrote.

New to Mirth? Start with our Mirth Connect guide: what it is, how it works, and when it fits.

Sample MDM^T02 message

An MDM^T02 is the HL7 v2 message that announces a new clinical document and carries its content. T01 announces a document without content, T10 replaces an earlier document with new content, and T11 cancels one. A sample T02 with synthetic data:

MSH|^~\&|TRANSCR|GENHOSP|IFENGINE|PRODAPP|20260914140500||MDM^T02^MDM_T02|MSG00355|P|2.5.1
EVN|T02|20260914160000
PID|1||MRN12345^^^GENHOSP^MR||DOE^JANE^A||19800101|F
PV1|1|I|4W^401^A^GENHOSP
TXA|1|DS^Discharge Summary|TX|20260914153000|1234^SMITH^JOHN^^^^MD|||||||DOC7781|||||AU
OBX|1|TX|DS^Discharge Summary||Patient admitted for observation and discharged in stable condition.||||||F

TXA-2 is the document type (DS, discharge summary), TXA-12 the unique document number that later T10 and T11 messages point back to, and TXA-17 the completion status (AU, authenticated). The document text sits in OBX-5. MDM messages reach your system through an HL7 interface, and the rest of this guide covers routing them in Mirth Connect.

In practice, MDM channels are where a lot of Mirth Connect implementations go sideways. The TXA segment is unlike anything else in HL7 v2. Document replacement and cancellation require precise ID tracking that most basic channel setups skip. And with the 21st Century Cures Act's information-blocking rules in play, which documents route to patient portals — and when — is no longer a configuration detail you can defer.

This guide covers building a production-ready Mirth Connect MDM channel: event type selection, TXA segment parsing, OBX content extraction, T10 replacement handling, T11 cancellation, and FHIR DocumentReference output for downstream systems that need it.

What Are HL7 MDM Messages? (And Why They're Different)

MDM messages carry transcribed clinical notes, operative reports, discharge summaries, radiology transcriptions, and scanned referral letters between systems. They're defined in Chapter 9 of the HL7 v2 standard.

ADT and ORU are the high-volume transactional workhorses. MDM is quieter but carries a different category of content: the narrative that gives clinical context to everything else. A lab result only makes sense alongside the note that ordered it. A discharge summary is what the next care team reads first.

Because of that, MDM documents frequently become part of the legal medical record. Errors in routing, replacement handling, or cancellation aren't just technical bugs — they're potential compliance failures under Joint Commission and CMS documentation standards.

MDM Event Types: T01, T02, T04, T10, T11 Explained

HL7 defines 11 MDM trigger events. Most production Mirth Connect MDM channels handle four or five of them.

T01 — Original Document Notification (No Body)

Signals that a document exists. Content is not included in the message. The receiving system fetches it separately via XDS.b query or a FHIR DocumentReference lookup.

Use T01 when:

• Documents are large (multi-page PDFs)
• Multiple receivers have different access rights to the content
• The receiving system is built to make outbound document-fetch calls

T02 — Original Document Notification with Content

The most common MDM event in production. Full document body is embedded in OBX segments as plain text (TX), formatted text (FT), or Base64-encoded binary (ED — typically PDF).

Use T02 for point-to-point integrations where the receiver cannot make outbound calls, for time-sensitive documents, and anywhere you want self-contained delivery. If you're connecting a transcription system to an EHR and you're unsure which event type to use, it's almost always T02.

T04 — Document Addendum with Content

Appends content to an existing document. Common for amended lab reports and progress note addenda added after initial sign-off. The addendum gets its own document ID but links back to the original via TXA-12.

T10 — Document Replacement

Fully replaces a previously transmitted document. TXA-12 identifies the original; TXA-13 identifies the replacement. The original is typically retained with status "Obsolete" — available for audit but not shown as the active version.

T10 is where most naive channel implementations fail silently. If Mirth treats T10 the same as T02 and just creates a new document record, you end up with two active versions in the downstream system and no link between them.

T11 — Document Cancellation

Revokes a previously transmitted document. Most common scenario: wrong patient ID was used during transcription. The cancellation removes the document from general clinical access but the document itself must be retained for historical reference — with a cancellation reason recorded.

Key distinction: T10 and T11 look structurally similar to T02, but the semantics are completely different. A channel that treats all inbound MDM messages identically will fail silently on replacements and cancellations.

TXA Segment in Mirth Connect: What to Extract and Why

TXA is the segment that makes MDM distinctive. Every other HL7 message relies on OBR or OBX for key metadata. MDM has a dedicated header segment — Transcription Document Header — that carries all document-level information.

Here's a production extraction block in Mirth's JavaScript transformer:

// TXA segment extraction — Mirth Connect MDM channel
var docType     = msg['TXA']['TXA.2'].toString();          // DS, OP, PN, RAD, CN
var docFormat   = msg['TXA']['TXA.3'].toString();          // TX, AP, FT
var activityDT  = msg['TXA']['TXA.4'].toString();          // Dictation/transcription timestamp
var authorLN    = msg['TXA']['TXA.9']['XCN.3'].toString(); // Author last name
var uniqueDocID = msg['TXA']['TXA.12']['EI.1'].toString(); // KEY — links all lifecycle events
var docStatus   = msg['TXA']['TXA.17'].toString();         // DI, AU, IN, LA
var docTitle    = msg['TXA']['TXA.21'].toString();

channelMap.put('doc_id', uniqueDocID);
channelMap.put('doc_type', docType);
channelMap.put('doc_status', docStatus);

TXA-12: The Field That Links the Entire Document Lifecycle

TXA-12 (Unique Document Number) is the persistent identifier that connects every MDM event for the same document. A single clinical note can generate a T01 (notify), T02 (full send), T04 (addendum), T10 (replacement), and T11 (cancellation) over its lifetime — all referencing the same TXA-12.

Without extracting and indexing TXA-12, downstream ECMs and EHRs cannot correlate those events. T10 replacements silently become orphaned new documents. T11 cancellations are ignored.

TXA-17: Document Completion Status (Critical for Portal Routing)

TXA-17 controls authentication status and drives patient portal visibility decisions:

Under the 21st Century Cures Act, most clinical notes must reach patients without delay. But best practice is to gate portal routing on AU or LA status only. A transcribed but unsigned discharge summary should not be visible to a patient before the attending physician has reviewed it.

TXA-2: Document Type Codes

Document type drives routing decisions — operative notes and discharge summaries often go to different downstream destinations, and may have different authentication thresholds before portal release.

Extracting Document Body from OBX Segments (T02, T04, T10)

For events that carry a document body, the content lives in OBX segments. OBX-2 (Value Type) tells you the format:

// OBX content extraction — MDM T02, T04, T10
var docBody     = '';
var contentType = 'text/plain';

for each (var obx in msg['OBX']) {
    var valType = obx['OBX.2'].toString();
    var content = obx['OBX.5'].toString();

    if (valType === 'TX' || valType === 'FT') {
        // Plain text or formatted text — concatenate all OBX segments
        docBody += content + '
';
    } else if (valType === 'ED') {
        // Encapsulated Data — Base64 PDF
        // Format: source^subtype^encoding^dataType^Base64Data
        var parts = content.split('^');
        if (parts.length >= 5) {
            docBody     = parts[4];
            contentType = 'application/pdf';
        }
    }
}

channelMap.put('doc_body', docBody);
channelMap.put('content_type', contentType);

Performance note for large PDFs: For ED-type documents over 1MB, extract and detach binary content early in the pipeline. Holding a large Base64 string in channel memory through multiple transformer steps creates JVM heap pressure that compounds under concurrent load. Extract once, write the binary to a temp file reference, and route that reference downstream.

T10 Document Replacement: Getting the Linking Right in Mirth

T10 is where most basic MDM channel implementations break. The naive approach — treating T10 like T02 and creating a new document record — leaves orphaned versions with no link between them.

The correct Mirth implementation:

// T10 replacement handling — Mirth Connect MDM channel
if (channelMap.get('event_type') === 'T10') {
    var originalDocId    = msg['TXA']['TXA.12']['EI.1'].toString();
    var replacementDocId = msg['TXA']['TXA.13']['EI.1'].toString();

    channelMap.put('original_doc_id', originalDocId);
    channelMap.put('replacement_doc_id', replacementDocId);
    channelMap.put('is_replacement', 'true');

    logger.info('Doc replacement: ' + originalDocId + ' -> ' + replacementDocId);
}

In the destination transformer, use original_doc_id to locate the existing document in the ECM or EHR, flip its status to "Obsolete," then create the new version using replacement_doc_id. The HL7 standard is explicit: the original must be retained for historical reference — not deleted.

For T11 cancellations, the logic is simpler: locate by TXA-12, update status to cancelled, surface the cancellation reason in the clinical record. No new document is created.

Mapping MDM to FHIR DocumentReference (R4)

When downstream systems consume FHIR rather than HL7 v2, the MDM document maps to a DocumentReference resource in FHIR R4.

For T10 replacements, the new DocumentReference gets a relatesTo element with code = "replaces" pointing to the prior version's ID. This preserves the version chain for HIPAA audit trail requirements and Joint Commission documentation standards.

For a complete HL7 v2 to FHIR R4 transformation pattern in Mirth Connect, see our HL7 v2 to FHIR APIs guide.

Pre-Go-Live Testing Checklist for MDM Channels

MDM channels fail in predictable ways. Validate these scenarios in a non-production environment before deploying:

1. Document chain integrity
Send T01 → T02 → T10 for the same document. In the downstream system, you should see one active document and one with status "Obsolete," both linked by TXA-12. Two active documents means your destination transformer isn't handling the replacement logic.

2. T11 cancellation visibility
After sending T11, confirm the document is no longer surfacing as active — but also confirm it still exists in the record. Retrievable for audit. Not presented as current.

3. ED type (Base64 PDF) under load
Send ten concurrent T02 messages with Base64-encoded PDF bodies. Watch Mirth's JVM heap in the admin console. If heap climbs without recovering between messages, rework when and where you decode the binary.

4. Portal routing gate
Send T02 with TXA-17 = DO (unsigned). The document should not reach the portal destination. Then send the same document with TXA-17 = AU. It should route through. If both route, the authentication gate is broken.

Further Reading

• C-CDA Processing in Mirth Connect: Parse, Validate, Route
• Mirth Connect Patient Portal Integration
• Turning HL7 v2 into Modern FHIR APIs Using Mirth Connect
• Mirth Connect Channel Design Patterns
• ORU Lab Results Routing with Mirth Connect