Working with MDM Messages

An HL7 Medical Document Management (MDM) message provides information about new or updated notes or documents. MDM messages are typically used by Radiology departments to communicate provider transcriptions, order information and document contents. This message type is covered in Chapter 9 of the HL7 standard.

Application Guidelines

Network

Applications shall use the Minimal Lower Layer Protocol (MLLP) defined in Appendix C of the HL7 Implementation Guide.

An application that wants to send a message (initiate a transaction) will initiate a network connection to start the transaction.

The receiver application will respond with an acknowledgment or response to query but will not initiate new transactions on this network connection.

Acknowledgment Mode

Applications that receive HL7 messages shall send acknowledgments using the HL7 Original Mode (versus Enhanced Acknowledgment Mode) unless otherwise specified.

Empty Field

According to the HL7 standard, if the value of a field is not present, the receiver shall not change corresponding data in its database.

However, if the sender includes explicit NULL value (i.e., two double-quotes ""), it shall cause removal of any values for that field in the receiver's database.

HL7 Version

Since the transactions are self-contained communications, the implementation of each HL7 transaction may possibly use a different version of HL7.

An application implementing an HL7 messages must comply with the message structure and contents defined by the specified version(s) of the HL7 standard.

HL7 v2.5

Acknowledgment Message

• Each HL7 message to be acknowledged by the HL7 ACK message sent by the receiver of an HL7 message to its sender. The segments of the ACK message listed below are required, and their detailed descriptions are provided in the following subsections.
• The ERR segment is optional and may be included if the MSA-1 Acknowledgment Code field identifies an error condition.

Common ACK Message static definition

Message Header Segment (MSH)

• MSH-1 Field Separator value recommended by HL7 is | (ASCII 124).
• MSH-2 Encoding Characters a required field. This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. The values recommended by HL7 are ^~\& (ASCII 94, 126, 92, and 38, respectively).

• MSH-9 Message Type (MSG), required.
  Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
  This field contains the message type, trigger event, and the message structure ID for the message. All three components are required.

• MSH-10 Message Control Id (ST), required. This field contains a number or other identifier that uniquely identifies the message in the context of exchange between trading partners. Each message should be given a unique identifier by the sending system. The receiving system will echo this ID back to the sending system in the Message Acknowledgment segment (MSA). The combination of this identifier and the name of the sending application (MSH-3) should be unique across the message exchange environment.

• MSH-12 Version ID (VID), required.
  Components: <Version ID (ID)> ^ <Internationalization Code (CE)> ^ <International Version ID (CE)>
  This field is matched by the receiving system to its supported version(s) to be sure that the message will be interpreted correctly. The first component should be populated with the value "2.5.1" or higher, representing HL7 Version 2.5.1 or higher.

• MSH-17 Country Code (ID), required if available. This field contains the country of origin for the message. The values to be used are those of ISO 3166, using the 3-character alphabetic form. Refer to HL7 Table 0399 - Country code.

• MSH-18 Character Set (ID), conditional. This field contains the character set for the entire message. Refer to HL7 Table 0211 - Alternate character sets for valid values.
  Condition predicate: This field shall only be valued if the message uses a character set other than the 7-bit ASCII character set. IHE authorizes only one occurrence (i.e., one character set).
  Examples of valid values:

  • ASCII: The printable 7-bit ASCII character set.
  • UNICODE UTF-8: UCS Transformation Format, 8-bit form.

• MSH-19 Principal Language of Message (CE), required if available. Coded from ISO 639. Examples:
  DE = German, EN = English, ES = Spanish, JA = Japanese, FR = French, NL = Dutch, IT = Italian

• MSH-20 Alternate Character Set Handling Scheme (ID), not supported: Character set switching is not allowed.

• MSH-21 Message Profile Identifier (EI), required if available. This field shall be valued in the messages for which a Message Profile has been officially registered with HL7. When multiple message profiles are listed in this field, they should be vendor specific and/or country specific message profiles constraining the official one.

Message Acknowledgment (MSA)

• MSA-1 Acknowledgment Code (ID), required. This field shall contain the value AA, AE or AR when using Original Acknowledgment Mode, or CA, CE or CR when using Enhanced Acknowledgment Mode. See HL7 v2.5.1 Chapter 2 Section 2.9.2 and 2.9.3 for details.
• MSA-2 Message Control ID (ST), required. This field contains the message control ID from Field MSH-10-Message Control ID of the incoming message for which the acknowledgment is sent.
• MSA-3 Text Message (ST), not supported.
• MSA-6 Error Condition (CE), not supported.

Error segment (ERR)

• ERR-1 is deprecated since HL7 Version 2.5 (retained for backward compatibility only)

• ERR-2 is populated except when the error is not within an HL7 field, component or subcomponent. For example, if the receiver returns an acknowledgment containing MSA-1-acknowledgment code value AR or CR to indicate that the receiving application was unavailable, ERR-2 is not populated.
  In case that the receiving application does not recognize either the message type (MSH-9.1) or the trigger event (MSH-9.2) in a message, the components of Field ERR-2 of the acknowledgment shall be populated as follows:

  • ERR-2.1: MSH 1660
  • ERR-2.2: 1
  • ERR-2.3: 9
  • ERR-2.4: 1
  • ERR-2.5: 1 if an unrecognized message type, 2 if an unrecognized trigger event

• ERR-3 HL7 Error Code (CWE) is required. It identifies the HL7 (communication) error code. Valid values are given by HL7 Table 0357.
  The components of Field ERR-3 of the acknowledgment shall be populated as follows:

  • ERR-3.1: 200 if an unrecognized message type. 201 if an unrecognized trigger event.
  • ERR-3.2: Unsupported message type or Unsupported trigger event as appropriate
  • ERR-3.3: HL70357
• ERR-4 Severity (ID) is required. It identifies the severity of an application error. Valid values are given by HL7 Table 0516

HL7 v2.3.1

Requirements

• Each HL7 message is to be acknowledged by the HL7 ACK message sent by the receiver of an HL7 message to its sender.
• The segments of the ACK 1515 message listed below are required, and their detailed descriptions are provided in the following subsections.
• The ERR segment is optional and may be included if the MSA-1 Acknowledgment Code field identifies an error condition.
• Use HL7-recommended values for the fields MSH-1-Field Separator and MSH-2-Encoding Characters.
• Field MSH-18-Character Set shall only be valued if the message utilizes character sets other than ISO IR-6, also known as ASCII.

Common ACK Message static definition

Message Header Segment(MSH)

Implementations supporting sequence number protocol (and using the field MSH-13-Sequence Number) shall be configurable to allow them to perform transactions without such protocol.

Message Acknowledgment (MSA)

• Field MSA-1 Acknowledgment Code shall contain the value AA, AE or AR when using Original Acknowledgment Mode, or CA, CE or CR when using Enhanced Acknowledgment Mode. See HL7 v2.3.1 Chapter 2 Section 2.2.2, 2.2.3 and 2.24.2.1 for details.
• Field MSA-2 Message Control ID shall contain the Message ID from the MSH-10 Message Control ID of the incoming message for which this acknowledgment is sent.

Error Segment

The MDM Transaction Set

The transaction set supports the transmission of new or updated documents or information about their status(es).

Documents are created in two distinct contexts, one of which is related to an order and describes the procedures or activities associated with that order. The other context in which an MDM message is created occurs independent of the order process.

The Common Order (ORC), Observation Request (OBR) and associated Notes and comments (NTE) segments in order provide full ordering context.

The content of a document can be represented with one or more Observation segments (OBX). Each medical concept is represented in its own OBX segment. The document notification is transmitted in the form of an unsolicited update or in response to a record-oriented query.

Assumptions

• All documents are unique, and document numbers and file names are not reused.
• Documents may be associated with one or more orders.

Message Trigger Events

The trigger events and messages may be divided into two broad categories. One which describes the status of a document only and the other that describes the status and contains the document content itself.

• T07 and T08 are only valid for documents with availability status "Unavailable" (i.e., the document has not been made available for patient care). Scenario: Errors, which need to be corrected, are discovered in a document. The original document is edited, and an edit notification is sent.
• T09 is generally used when the original document availability status is "Available"
• T10 Scenario: Errors discovered in a document are corrected. The original document is replaced with the revised document. The replacement document has its own new unique document ID that is linked to the original document via the parent ID. The availability status of the original document is changed to "Obsolete" but the original document should be retained in the system for historical reference.
• T11 is only used for an original document with an availability status of "Unavailable". When a document has been made available for patient care, the process should be to replace the original document, which then becomes obsolete. The replacement document describes why the erroneous information exists. Scenario: When the author dictated a document, the wrong patient identification was given, and the document was transcribed and sent to the wrong patient's record. When the error is discovered, a cancellation notice is sent to remove the document from general access in the wrong patient's record. In these cases, a reason should be supplied in the cancellation message. To protect patient privacy, the correct patient's identifying information should not be placed on the erroneous document that is retained in the wrong patient's record for historical reference. A new document notification and content will be created using a T02 (original document notification and content) event and sent for association with the correct patient's record.

Observation Result Status in the OBX segment

This field in the OBX segment contains the observation result status. It reflects the current completion status of the results for one Observation Identifier.

This is a required field. Previous versions of HL7 stated this implicitly by defining a default value of F.

When changing or deleting a result, multiple OBX segments with the same observation ID and observation sub-ID are replaced or deleted as a unit. Normal progression of results through intermediate (e.g., "gram positive cocci") to final (e.g., "staphylococcus aureus") should not be transmitted as C (correction); they should be transmitted as P or S (depending upon the specific case) until they are final.

Refer to HL7 table 0085 - Observation result status codes interpretation for valid values.

Transcription Document Header (TXA) Segment

The TXA segment contains information specific to a transcribed document but does not include the text of the document. The message is created as a result of a document status change. This information updates other healthcare systems and allows them to identify reports that are available in the transcription system.

Refer to Chapter 9 for massage field details.

MDM versus ORU

Chapter 7 of the HL7 Standard covers transactions related to Observation reporting and HL7 Observation Result (ORU) messages.

A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) acting as the filler, to the ordering system (e.g., HIS order entry, physician's office system) which acts as the placer.

These transaction sets allow the transmission of clinical observations including, but not limited to:

• Clinical laboratory results
• Measures of patient status and condition
• Vital signs
• Intake and output
• Severity and/or frequency of symptoms.

If the observation being reported meets one or more of the following criteria, then the content would qualify as an MDM message rather than an ORU message:

• Documents/reports that require succession management to reflect the evolution of both document addenda and replacement documents
• Documents/reports where the sender wants to indicate the availability of the report for use in patient care using the Transcription Document Header (TXA) segment, as described in Chapter 9
• Documents/reports where the content as a whole requires a signature as part of the message
• If a Clinical Document Architecture (CDA) document requires succession management or report availability
• Documents/reports where the content as a whole requires special confidentiality protection using the TXA segment
• Documents/reports where document storage status is useful for archival and purging purposes using the TXA segment

Examples of documents/reports would typically qualify as MDM messages:

• History and Physical
• Consultation reports
• Discharge summaries
• Surgical/anatomic pathology reports
• Diagnostic imaging reports
• Cardio-diagnostic reports
• Operative reports

Insertion of a CDA document within an OBX Segment

CDA documents are to be exchanged in the OBX segment. The value of OBX-2-Value Type should be set to ED.

OBX-5-Observation Value contains the MIME package encoded as an encapsulated data type. The components values should be set as follows:

Every entity within the MIME package must be Base64-encoded.

As stated in Chapter 2 of the standard,

The data component must be scanned before transmission for HL7 delimiter characters (and other non-printing ASCII or non-ASCII characters such as LineFeed), and any found must be escaped by using the HL7 escape sequences defined in Section 2.7 'Use of escape sequences in text fields'. On the receiving application, the data field must be de-escaped after being parsed.

As a result, CR/LF sequences required in the MIME package need to be escaped (i.e., converted to \X0D0A\) prior to transmission. The content type of the first MIME entity is set to application/x-hl7-cda-level-one+xml, and should contain the CDA document itself.

Multimedia objects referenced by the CDA document that need to be transmitted within the CDA document are to be placed in successive entities of the MIME package.

Note that a MIME package is not itself Base64-encoded. Rather entities within the MIME package are Base64-encoded. A MIME package is sent as ASCII text. Therefore, the correct value is A not Base64.

DICOM Structured Report (SR) to HL7

The export of DICOM SR is described in volume 2 of the IHE Radiology (RAD) Technical Framework in section 4.28: Structured Report Export [RAD-28]. This is done using an ORU^R01 message.