Medical Documents with MDM

What MDM is for

A great deal of clinical information lives not in discrete coded values but in narrative documents: transcribed history-and-physical reports, operative notes, discharge summaries, radiology dictations, consult letters. The Medical Document Management (MDM) message family exists to move these documents — and, just as importantly, their status — between systems such as a transcription service, a dictation platform, and the receiving EHR or document repository ¹.

The reason MDM is its own family rather than a variation on results reporting is that a document has a life of its own. The same report may be dictated, then transcribed, then read as preliminary, then signed and authenticated — possibly followed later by an addendum or a correction. MDM gives each of those events a trigger so receivers can keep their copy of the document, and its state, in step with the source ².

Trigger events: notification versus content

MDM trigger events come in a deliberate pattern. Some announce that something happened to a document (a notification), while others carry the document content as well. Recall that the trigger event is named in MSH-9 alongside the message type. The most useful events are:

• T01 — Original document, notification. A new document exists; this message only announces it.
• T02 — Original document, notification and content. Same event, but the document body travels with it.
• T03 — Document status change. The document moved to a new status (for example, from preliminary to authenticated).
• T04 — Document status change, notification and content.
• T05 / T06 — Document addendum (notification / with content). New material is appended to an existing document without altering the original.
• T07 / T08 — Document edit (notification / with content). A correction or replacement of existing content.
• T11 — Document cancel. The document is withdrawn.

The recurring “notification only” versus “with content” pairing lets an architecture choose how documents flow: a lightweight notification can tell a repository that something is ready to pull, while the content-bearing variant ships the text directly ¹.

The TXA segment

The segment that defines an MDM message is TXA (Transcription Document Header). It describes the document as an object, independent of its body:

• Document type — what kind of document it is (e.g., discharge summary, operative note).
• Unique document number — a stable identifier for this document across systems. This is the anchor for versioning: an addendum (T06) or edit (T08) refers back to it.
• Activity, availability, and completion status — where the document sits in its lifecycle.
• Dates — when the activity occurred, when transcription happened, and when the document was authenticated.
• Authoring, transcribing, and authenticating persons — who dictated, who typed, and who signed.

The document’s actual narrative does not live in TXA. The body is carried in one or more OBX segments beneath the TXA, which can hold either plain text or encoded content ¹.

An MDM^T02 skeleton

MSH|^~\&|TRANSCRIPTION|HOSP|EHR|HOSP|20260601101500||MDM^T02|MSG0001|P|2.5.1
EVN|T02|20260601101500
PID|1||100711^^^HOSP^MR||DOE^JANE||19800101|F
TXA|1|DS|TX|20260601100000|9988^SMITH^ANN^^^DR|||||DOC12345^HOSP|||AU
OBX|1|TX|||Discharge summary: Patient admitted for...||||||F

Reading the key parts: MSH-9 declares MDM^T02, so the receiver expects a document with content. EVN echoes the trigger. PID ties the document to the patient. In TXA, DS is the document type, DOC12345^HOSP is the unique document id, and AU (authenticated) is the completion status. The OBX carries the narrative, with its own status flag (F, final) ².

Why status and identity matter

Two TXA values do the heavy lifting. The status lifecycle — dictated, transcribed, preliminary, authenticated — lets every downstream system know whether a document is safe to act on; a preliminary radiology read and a signed one carry very different clinical weight. The unique document id is what makes versioning coherent: when a T06 addendum or a T08 edit arrives, the receiver uses that id to attach the change to the right document rather than creating a duplicate ². Get those two right and a document’s whole history stays consistent across the enterprise.