MDM messages move clinical documents between systems in HL7 v2: progress notes, discharge summaries, operative reports, consult notes and transcribed or AI-generated documentation. MDM^T02, the original document notification with content, is the version most integrations use because it carries both the document’s metadata and its text in one message. This guide explains MDM event types, message structure, the TXA segment, a full example and the practices that keep documents filing correctly. For the wider picture of message types, see our HL7 message types and event types guide. Sending notes back to an EHR? Request a free HL7 interface review.
What MDM Messages Are Used For
MDM stands for Medical Document Management. These messages notify receiving systems about new documents, status changes, addenda, edits, replacements and cancellations. They are central to transcription, dictation, ambient documentation and any workflow where documents are created outside the EHR.
Transcription and dictation
Transcription and dictation systems traditionally use MDM to send completed documents into EHRs. Each message identifies the patient, author, document type and status, then carries the document text so clinicians can review and sign notes inside their usual workflow without switching applications.
Ambient and AI documentation
Ambient documentation tools increasingly use MDM to send AI-drafted notes into EHRs for clinician review and signature. Our ambient clinical documentation services team builds these integrations with careful attention to document status and authentication workflows. Clinicians always review AI drafts before signing them.
Reports from departmental systems
Cardiology, pathology, radiology and other departmental systems may send narrative reports through MDM, especially when reports are documents rather than discrete results. Using MDM keeps document metadata, authentication and versioning consistent across sources in a health system. Each source needs its own mapping review.
Document lifecycle updates
Documents change after creation: they are signed, amended, edited, replaced or cancelled. MDM event types communicate each change. Receivers must apply updates to the correct original document, which depends on stable unique document numbers in every related message. Test every update type carefully.
MDM Event Types
MDM uses paired trigger events: odd numbers notify without content, while even numbers include document content. Knowing which events each system sends helps teams design receivers that handle the full document lifecycle rather than only new documents.
T01 and T02: original documents
T01 notifies that an original document exists, without content. T02 notifies and includes the document content in OBX segments. Most integrations use T02, because receivers can display the document immediately without fetching content through a separate mechanism. Confirm which events each source sends.
T03 and T04: status changes
T03 notifies that a document’s status changed, such as moving from dictated to authenticated, without content. T04 includes content. Receivers update status fields so clinicians and downstream systems know whether a document is preliminary or final. Test every status transition with each receiver.
T05 to T10: addenda, edits and replacements
T05 and T06 cover addenda, T07 and T08 edits, and T09 and T10 replacements, with even-numbered events including content. Receivers must link these to the parent document correctly, preserving history while showing clinicians the current version. Test each event type with the EHR.
T11: cancellations
T11 notifies that a document was cancelled, often because it was created in error or for the wrong patient. Receivers must remove or hide the document appropriately, following organizational policies for retaining cancelled documents in audit history. Notify affected clinicians where appropriate.
MDM^T02 Message Structure
An MDM^T02 message combines patient and visit context, optional order information, the TXA document header and OBX segments carrying content. Understanding this structure helps teams handle documents with or without related orders and with different content formats.
| Segment | Name | Usage | Purpose |
| MSH | Message Header | Required | Sender, receiver, message type, version |
| EVN | Event Type | Required | Event and timing |
| PID | Patient Identification | Required | Patient identifiers and demographics |
| PV1 | Patient Visit | Required | Visit context for the document |
| ORC | Common Order | Optional, repeating | Related order, if any |
| OBR | Observation Request | Optional | Related order details |
| NTE | Notes and Comments | Optional, repeating | Order comments |
| TXA | Transcription Document Header | Required | Document metadata |
| OBX | Observation/Result | Required for T02, repeating | Document content |
| NTE | Notes and Comments | Optional, repeating | Content comments |
TXA Segment: Key Fields
TXA holds the document’s identity, type, authors, timing and status. Receivers rely on it to file documents correctly, route them for signature and manage versions. The fields below are those integrations use most often in HL7 v2.5.1.
| Seq | Field name | Opt | Notes |
| TXA-1 | Set ID – TXA | R | Usually 1 |
| TXA-2 | Document Type | R | e.g. PR progress note, DS discharge summary |
| TXA-3 | Document Content Presentation | C | e.g. TX text, FT formatted text |
| TXA-4 | Activity Date/Time | O | Date of the clinical activity |
| TXA-5 | Primary Activity Provider | C | Provider associated with the activity |
| TXA-6 | Origination Date/Time | O | When the document was created |
| TXA-9 | Originator Code/Name | O | Author of the document |
| TXA-10 | Assigned Document Authenticator | O | Who must sign |
| TXA-11 | Transcriptionist Code/Name | C | Person who transcribed |
| TXA-12 | Unique Document Number | R | Stable ID for the document |
| TXA-13 | Parent Document Number | C | Links addenda and replacements |
| TXA-14 | Placer Order Number | C | Related order, if any |
| TXA-17 | Document Completion Status | R | e.g. DO, IP, AU, LA |
| TXA-18 | Document Confidentiality Status | O | Confidentiality level |
| TXA-19 | Document Availability Status | O | e.g. AV available, CA canceled |
| TXA-22 | Authentication Person, Time Stamp | C | Who signed and when |
Example MDM^T02 Message
The example below shows an authenticated progress note sent from a documentation system to an EHR, with content in a text OBX segment. Data is fictional. Use examples like this to validate parsing, document filing and status handling before connecting live systems.
MSH|^~\&|DOCSYS|HOSP|EHR|HOSP|20261016140500||MDM^T02^MDM_T02|MSG00006|P|2.5.1
EVN|T02|20261016140500
PID|1||MRN123456^^^HOSP^MR||Doe^Jane^Marie||19850214|F
PV1|1|O|CLINIC1^^^HOSP
TXA|1|PR|TX|20261016140000|1234567890^Smith^John|||||||DOC556677^HOSP_EHR|||||AU
OBX|1|TX|11506-3^Progress note^LN||Patient seen for follow-up of type 2 diabetes. Glucose well controlled.||||||F
Reading the header and context
MSH shows the documentation system sending to the EHR with message type MDM^T02 and version 2.5.1. EVN records the event. PID identifies the patient by MRN, and PV1 places the document in an outpatient visit at CLINIC1. Each value sits in its expected position.
Reading the TXA segment
TXA-2 identifies a progress note and TXA-3 text content. TXA-4 records the activity time, TXA-5 the provider and TXA-12 the unique document number DOC556677. TXA-17 shows status AU, meaning the document is authenticated. The EHR then routes the note to the correct chart and signer.
Reading the content
OBX carries the note text with value type TX and LOINC code 11506-3 for a progress note. Longer documents often span several OBX segments, one per line or paragraph, which receivers must reassemble in the correct order. Test reassembly with long documents.
Implementation Best Practices
Reliable document interfaces depend on stable identifiers, correct status handling and careful content formatting. These practices reflect lessons from building documentation integrations for transcription vendors, ambient AI companies and hospital departments.
Keep document numbers stable
TXA-12 must uniquely and permanently identify each document. Addenda, edits and replacements reference it through TXA-13. Regenerating or reformatting document numbers breaks version links, leaving clinicians with duplicate or orphaned notes that are difficult to clean up. Validate them on every message.
Respect authentication workflows
Many EHRs require clinicians to sign documents created externally. Send drafts with appropriate completion status, such as in progress or documented, and let the EHR manage signature. Sending documents as authenticated without proper sign-off creates compliance and safety risks. Document the agreed rules.
Preserve formatting
Narrative documents lose readability when line breaks, headings and lists disappear. Agree on formatting conventions, such as formatted text or multiple OBX lines, with each receiver. Test how documents display in the EHR, not only whether they file successfully. Readability affects patient safety.
Handle encapsulated documents
Some workflows send PDFs or images using the ED data type in OBX, with base64 content. Confirm size limits and supported formats with receivers, and test performance. Large encapsulated documents can slow interfaces if engines are not configured appropriately. Monitor message sizes continuously.
How Taction Helps With Document Interfaces
Taction has delivered 200+ healthcare projects, including documentation, transcription and ambient AI integrations with EHRs. We help organizations build MDM interfaces that file documents correctly, respect signature workflows and preserve readability for clinicians.
Free HL7 interface review
Share sample MDM messages and EHR specifications. We review TXA usage, status handling, versioning and formatting, then flag risks and fixes. You get clear, prioritized recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce unfiled or duplicate documents.
Document interface development
We build MDM interfaces through engines such as Mirth Connect, handling text and encapsulated content, versioning, acknowledgments and monitoring. Every interface is documented and tested against real EHR display requirements. Each interface is monitored after go-live so failed or unfiled documents are caught before clinicians notice.
HL7 and FHIR document exchange
Many organizations exchange documents through both MDM and FHIR DocumentReference. Our HL7 integration services cover both, helping teams choose the right approach for each EHR and workflow. We also help organizations migrate document workflows from MDM to FHIR gradually, without disrupting clinicians or existing EHR integrations.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand documentation workflows, MDM events and engine development. They join your team quickly and document every interface thoroughly. Engagements scale with your roadmap, from a single document interface to support across many EHRs, departments and documentation vendors.
Frequently Asked Questions
These answers cover common questions about HL7 MDM messages. Because EHRs and partners add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What is an MDM^T02 message?
MDM^T02 is the HL7 v2 original document notification and content message. It notifies a receiving system that a new clinical document exists and includes the document content in OBX segments, along with metadata in the TXA segment. Most document interfaces use it.
What is the difference between MDM T01 and T02?
T01 notifies that a document exists without including content, while T02 includes the document content. Most integrations use T02 because receivers can display documents immediately without retrieving content through a separate process. Confirm which events each EHR expects before building interfaces.
What is the TXA segment?
TXA, the Transcription Document Header, carries document metadata such as type, authors, timing, unique document number and completion status. Receivers use it to file documents correctly, route them for signature and manage document versions. Validate it on every message. Accuracy matters.
How are document addenda sent?
Addenda use MDM T05 or T06 events, with T06 including content. The addendum references the original document through TXA-13 Parent Document Number, allowing receivers to link it correctly and display it with the original document. Test addenda display in the EHR.
Can MDM carry PDF documents?
Yes. MDM can carry PDFs and other files using the ED encapsulated data type in OBX, usually with base64 encoding. Confirm supported formats and size limits with each receiver, and test display and performance carefully. Monitor message sizes in production.