MDM — Medical Document Management

HL7 MDM messages carry medical document management events — the notifications that a clinical document has been dictated, transcribed, edited, authenticated, or otherwise changed status, together with the document content when it is sent. Where an ADT feed keeps every system aligned on who the patient is, the MDM feed keeps them aligned on what has been documented about that patient. This page explains what an MDM message represents, when each trigger event fires, every segment the message can carry and what each one holds, and how an MDM message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.

What an MDM message represents

An MDM message communicates a change in the state of a clinical document. When a discharge summary is dictated, a transcription is completed, or a clinician authenticates a report, the document management system emits an MDM message describing the event, and downstream subscribers file, index, or update their own copy of the document. The message is unsolicited: the source pushes it as documents move through their lifecycle rather than waiting to be queried, which is what distinguishes MDM from the DOC response that answers a document query.

The core of the message is the TXA segment — the transcription document header — which carries the document's type, its activity and origination timestamps, its completion and availability status, and the unique document number that every system indexes on. When the event carries content as well as notification, the document text follows in one or more OBX observation segments. The sender is typically a transcription platform, document management system, or EHR acting as a document repository; the receivers are the EHR, the clinical workstation, the document archive, and any health information exchange that needs the document.

Every MDM message shares the same skeleton — an MSH header, an EVN event segment, a PID patient segment, a PV1 visit segment, and the TXA document header — and the trigger-event code in MSH-9 tells the receiver which document event occurred.

When MDM messages are sent

MDM messages are sent the instant a document changes state, which makes the MDM feed a continuous real-time stream that tracks each document through its lifecycle. A single document can produce a sequence of related events as it moves from dictation to transcription to authentication, and status-only notifications are distinguished from notifications that also carry content.

Common MDM messages

The MDM message type defines a set of trigger events for document status changes. The T02 event — document status change notification and content — is the workhorse and the one with a published FHIR Bundle map. The events an integration team handles most often:

• MDM^T01 – Original document notification — status change only, no content.
• MDM^T02 – Original document notification and content — the new document plus its content.
• MDM^T03 – Document status change notification — status only.
• MDM^T04 – Document status change notification and content.
• MDM^T05 – Document addendum notification — status only.
• MDM^T06 – Document addendum notification and content.
• MDM^T07 – Document edit notification — status only.
• MDM^T08 – Document edit notification and content.
• MDM^T09 – Document replacement notification — status only.
• MDM^T10 – Document replacement notification and content.
• MDM^T11 – Document cancel notification.

The event in MSH-9 drives the handling, and the v2-to-FHIR Implementation Guide publishes a Bundle map for MDM_T02. The odd-numbered events are notification-only; the even-numbered events pair the same notification with the document content in OBX.

Integration topology

The diagram shows the document management system broadcasting document events through the integration engine to every downstream subscriber.

{{diagram: transcription / document management system → MDM message → integration engine → EHR / clinical workstation / document archive / HIE}}

Typical senders: transcription platform, document management system, EHR acting as a document repository, dictation system.

Typical receivers: EHR clinical workstation, document archive, health information exchange, care coordination application.

Direction: unidirectional broadcast from the document source of truth to many subscribers.

Segments in an MDM message

The MDM_T02 message opens with a fixed header block — MSH, optional software, EVN, PID, and PV1 — followed by an optional repeating COMMON ORDER group, the required TXA document header, and a required repeating OBSERVATION group carrying the document content. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The COMMON ORDER group from ORC through NTE is optional and repeats; the OBSERVATION group of OBX and NTE is required and repeats once per content segment, so a single MDM message can carry a complete multi-page document. The canonical segment pages carry the full field-by-field detail.

Sample MDM message

Note. Constructed for illustration. Patient identifiers, document numbers, dates, and names are fictional.

MSH|^~&|TRANSCRIPTION|MERCYGEN|EHR|MERCYGEN|202006151030||MDM^T02^MDM_T02|MSG00051|P|2.5.1
EVN|T02|202006151030||01|JSMITH
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^A||19651022|F|||123 OAK ST^^SPRINGFIELD^IL^62701
PV1|1|I|3WEST^301^A||||1234^JONES^RICHARD^^^MD|||MED||||||||V0001
TXA|1|DS^Discharge Summary^HL70270|FT|202006141800|1234^JONES^RICHARD^^^MD|202006141800|202006150900|||DOC-2026-98765-001||DOC-2026-98765-001|AU||||AV|LA
OBX|1|FT|18842-5^Discharge Summarization Note^LN||Patient Jane Smith was admitted on 14-Jun-2026 for management of acute exacerbation of COPD. She was treated with bronchodilators and systemic corticosteroids and discharged in stable condition on 15-Jun-2026 with outpatient follow-up arranged.||||||F

What this sample shows

The MDM^T02 in MSH-9 marks an original document notification with content, and the matching T02 in EVN repeats the trigger with its timestamp. PID identifies the patient as Jane Smith with medical record number MR98765, and PV1 places the document against an inpatient visit. The TXA is the heart of the message: it records a discharge summary (DS in TXA-2), the activity datetime 202006141800 in TXA-4, the originating provider in TXA-5, and the unique document number DOC-2026-98765-001 in TXA-12. The OBX carries the formatted text of the discharge summary keyed to LOINC code 18842-5.

Working with MDM messages

Read document metadata from TXA, not from OBX

The document type, status, authentication state, and unique identifier all live in TXA, not in the observation content. Index and route on TXA-2 (document type) and TXA-12 (unique document number), and read completion and availability status from TXA-17 and TXA-19 before deciding whether a document is ready for a clinical record. Do not infer status from the content text in OBX.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key for the message, and treat the unique document number in TXA-12 as the natural business key for the document. MDM feeds are replayed after outages; a repeated TXA-12 should update the existing document record rather than create a duplicate.

Status progression and content vs. notification

The odd-numbered events (T01, T03, T05, T07, T09) carry a status change with no content; the even-numbered events (T02, T04, T06, T08, T10) pair the same notification with the content in OBX. Model the document lifecycle rather than treating each event as an independent document — an addendum (T05/T06), edit (T07/T08), or replacement (T09/T10) updates a document you already hold, and a T11 cancels it.

Multi-segment document content

Long documents span multiple OBX segments, each with a unique sequence number in OBX-1. Reassemble the content in sequence-number order rather than message-arrival order before storing or displaying it, and do not assume a maximum OBX count.

Vendor variance. Not all document systems populate TXA-17, TXA-19, and TXA-22 consistently, and some send the content in a single OBX using encapsulated data (ED) while others split formatted text across many FT-typed OBX segments. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An MDM message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Patient, Encounter, and DocumentReference the event concerns. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH, the Patient from PID, the Encounter from PV1, and the DocumentReference from TXA and OBX, with an optional ServiceRequest produced from the ORC common order and Coverage, Basic, and Device resources produced when the corresponding data is present.

The Implementation Guide publishes an official Bundle map for MDM_T02; other MDM trigger events are composed from the per-segment maps.

Common pitfalls

Pitfall. Treating every incoming MDM as a new document. A replay or a status-update event carries the same TXA-12 unique document number as a previously received document. Use TXA-12 as the upsert key and update status and content when a higher-status version arrives rather than storing a duplicate.

Pitfall. Displaying unauthenticated documents as final. A document whose completion status in TXA-17 indicates it is dictated or transcribed but not yet authenticated has not been approved by a clinician; surface the status on every document display rather than presenting it as final.

Pitfall. Reassembling OBX content in arrival order rather than sequence order. Multi-segment documents can arrive with OBX segments out of order; sort by OBX-1 before reassembly to render the document correctly.

How Vorro handles MDM messages

Vorro ingests the MDM feed over MLLP or another transport, deduplicates on MSH-10, routes by the trigger event in MSH-9, and fans each document event out to every subscribed destination in the format that system expects — the EHR document record, the clinical workstation, and the document archive. Vorro reads document type, status, and authentication state from TXA, uses TXA-12 as the upsert key to handle status progressions without creating duplicates, and reassembles multi-segment content from the OBX chain in sequence order. Where the v2-to-FHIR Implementation Guide provides a published map, Vorro emits the corresponding FHIR Bundle with its DocumentReference; for other events it composes the Bundle from the per-segment maps.

Related messages

• DOC — the solicited document response that returns documents in reply to a query, using the same TXA structure.
• ORU — the unsolicited observation result message, which carries observation-based clinical results in a related but distinct pattern from document notifications.
• ADT — the patient administration feed that establishes the patient and visit context an MDM document is filed against.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms the MDM_T02 message map
• HL7 v2-to-FHIR IG — MDM_T02 to Bundle ConceptMap
• HL7 Messaging Standard Version 2.5.1 product brief