For transferring electronic data between disparate healthcare systems, we use HL7 Messages. Each HL7 message sends information about a particular medical or administrative event, for example, patient admission.
There are many types of HL7 messages, but mostly used HL7 message types are ACK, ADT, BAR, RGV, SIU, and many more. We will learn all in detail. Though, to learn about these message types, we must know in brief about HL7 and HL7 Messages as well.
So, let’s begin with an overview of HL7 for better understanding.
What is HL7?
A standard for exchanging information between medical applications is what we call HL7 (Health Level Seven). It defines a format for the transmission of health-related information.
Moreover, the information sent using the HL7 standard is transmitted as a collection of one or more messages, where each transmits one record or item of health-related information. These messages could contain anything, like patient records, laboratory records, billing information, etc.
Even when HL7 and its messages are widely used, many systems don’t know to speak the language and require a translator. Though, interface engines of HL7 work alongside existing applications as an interpreter, speaking the language of HL7.
The HL7 Message
As we mentioned earlier as well, to transmit data between disparate systems, we use HL7 Messages. It contains a group of segments in a defined sequence, with these segments or groups of segments being required, optional, and/or repeatable.
Besides, the type of the HL7 message explains the purpose of the message being sent and is present in every HL7 message. By a three-character code, we can identify these message types.
Also, the message types are used in conjunction with a trigger event. Well, an HL7 trigger event is a real-world event which starts communication and sending of a message and is shown as part of the message type.
Both the trigger event and message type are found in the MSH-9 field of the message. For instance, the MSH-9 field might contain the value ADT-A01. ADT is the HL7 message type, and A01 is the trigger event. Moreover, an ADT-A01 message is known as a “patient admit” message in the HL7 Standard.
There is a defined format of each message type and trigger event within a specific HL7 version. Though, some message types and triggers are available that have the same format, including ADT-A01, ADT-A04, ADT-A05, and ADT-A08. But the formats vary widely in many cases.
Types of HL7 Messages
Some of the most commonly used HL7 Message types are:
1. ACK: General Acknowledgment
Whenever a message is received by the destination system, this is the ack sent. Generally, ACKs are automated responses. However, it is possible to use ACKs as a way to modulate the speed at which messages come through. Well, until the ACK is received, the sending system will not send the next message.
In healthcare data exchange communications, only two types of Acknowledgement messages (ACKs) are used:
HL7 ACKs: It includes both original mode and enhanced mode acknowledgments.
Non-HL7 ACKs: It is also known as static string acknowledgments.
2. ADT: Admission, Discharge, and Transfer
Whenever a patient goes through any of those states, Admission, Discharge, and Transfer messages are created. These messages carry patient demographic information for HL7 communications. Also, it provides important information about trigger events like patient admit, registration, etc.
In this message, some most important segments are the PID, PV1, IN1. This message is extremely common in HL7 processing. Also, it is the most widely used of all message types.
There are 51 different types of ADT messages, but the most commonly used ADT messages are:
ADT-A01 – patient admit
ADT-A02 – patient transfer
ADT-A03 – patient discharge
ADT-A04 – patient registration
ADT-A05 – patient pre-admission
ADT-A08 – patient information update
ADT-A11 – cancel the patient admit
ADT-A12 – cancel the patient’s transfer
ADT-A13 – cancel the patient discharge
3. ORM: Pharmacy/Treatment Order Message
It functions as a general order message which we use to transmit information about an order. ORM message is only of 1 type, that is, the ORM-O01 message. It is also the most widely used type, in the HL7 standard.
4. ORU: Observation Message (Unsolicited)
This message transmits observations and results from the producing system/filler. The term 'unsolicited' indicates that the destination systems are not asking for it, it is fired off and the source systems will take it in and if needed, process it or if not, discard it.
Also, we sometimes use this message to register or link to clinical trials or for medical reporting purposes for drugs and devices.
Some types of observations reported in the ORU-R01 message are:
- Clinical lab results
- Imaging study reports
- EKG pulmonary function study results
- The patient condition or other data (such as symptoms, vital signs, allergies, notes, etc.)
5. BAR: Add/Change Billing Account
This adds or changes the billing account.
6. SIU: Schedule Information (Unsolicited), usually patient specific
To create, modify, and delete patient appointments and other schedules, we use this message type. It notifies an auxiliary application of changes to some facet of the filler application’s appointment schedule. Especially for the SIU message, there are 14 different trigger events. But still, they all use a common message format.
The 14 SIU messages are:
SIU-S12 – Notification of new appointment booking
SIU-S13 – Notification of appointment rescheduling
SIU-S14 – Notification of appointment modification
SIU-S15 – Notification of appointment cancellation
SIU-S16 – Notification of appointment discontinuation
SIU-S17 – Notification of appointment deletion
SIU-S18 – Notification of addition of service/resource on the appointment
SIU-S19 – Notification of modification of service/resource on the appointment
SIU-S20 – Notification of cancellation of service/resource on the appointment
SIU-S21 – Notification of discontinuation of service/resource on the appointment
SIU-S22 – Notification of deletion of service/resource on the appointment
SIU-S23 – Notification of blocked schedule time slot(s)
SIU-S24 – Notification of un-blocked schedule time slot(s)
SIU-S26 – Notification that the patient did not show up for the scheduled appointment
7. MDM: Medical Document Management
In simple words, this type helps manage medical records by transmitting new or updated documents, or also by transmitting important status information and/or updates for the record.
An important part of MDM messages is the OBX segment that contains document contents. Except for the OBX segment, all MDM messages have the same message structure.
8. DFT: Detailed Financial Transactions
To capture the details of procedures so that claims can be generated. It determines a financial transaction which is sent to a billing system and is used for patient accounting purposes.
9. MFN: Master Files Notification
This message type sends changes to core data elements.
10. QRY: Query
To query source systems for data on things like patient demographics, etc., we use this message type.
11. RAS: Pharmacy/Treatment Administration Message
12. RDE: Pharmacy/treatment Encoded Order Message
For sending an order to the pharmacy and/or dispensing systems, this message is used by clinical applications. We can send it in several types, like either an order containing a single pharmacy/treatment or as a message in which order for a patient or also as a message as an order containing multiple pharmacy/treatment orders for a patient.
13. RGV: Pharmacy/Treatment Give Message
HL7 Message Components
Generally, HL7 messages are in human-readable (ASCII) format. Therefore, it may require some effort to interpret. There are one or more segments in an HL7 message. There is a carriage return character \r (0D in hexadecimal) that separates one segment from another. Each segment is displayed on a different line of text.
However, each segment contains one or more composites, which we also call fields. And, to separate one composite from another, a pipe (|) character is used. Though, if a composite contains other composites, these sub-composites are separated by ^ characters.
Sample HL7 Message
Past Encounters – Incoming Patient
Administration Interface
Outpatient Encounters (ADT^A04)
Message Structure
EVN|||||||
PID|||
|||||||||||||||Visit ID>||
PV1||
||||||Provider>||||||||||
||||||||||||||||||||||||||Date/Time>||
DG1|||||||
Data Element Details
Must have-
PID-3: Patient Identifiers
PID-18 or PV1-19: Patient Visit ID
PV1-3: Patient Location - Primarily looking for department
PV1-44: Admit Date/Time - Required to date the visit correctly
Highly recommended-
EVN-6: Event Occurred Date/Time
PID-5: Patient Name
PID-7: Date of Birth
PID-8: Sex
PID-19: SSN
PV1-2: Patient Class
PV1-7: Attending Provider
PV1-45: Discharge Date/Time
Good to have-
PV1-8: Referring Provider
PV1-18: Patient Type
DG1-3: Diagnosis Code
DG1-6: Diagnosis Type
HL7 Delimiter Characters
There are certain special characters, which separate one composite in a segment from another or separate one sub-composite from another. So, these special characters are what we call delimiter characters.
Here is the list of the default delimiter characters:
“0x0D” marks the end of each segment.
“|” is the Composite delimiter.
“^” is the Sub-composite delimiter.
“&” is the Sub-sub-composite delimiter.
“~” separates repeating fields.
\ is the Escape character.
HL7 Segments
A group of fields that contain varying types of data is what we call a segment. Anyway, each segment exists independently. And, we can utilize it in multiple messages in varying sequences throughout the HL7 standard. We may require segments for a particular message, or it may be optional.
There is a unique three-character code known as the “Segment ID." This identifies each segment. There are some Segment ID codes which begin with the letter Z. They are reserved for locally defined Z-segments and that are not part of the HL7 standard.
Some most commonly utilized segments are:
DG1: Diagnosis
EVN: Event type
GT1: Guarantor
IN1: Insurance
MSH: Message header
NK1: Next of kin/associated parties
NTE: Notes and comments
OBR: Observation request
OBX: Observation result
ORC: Common order
PID: Patient identification
FT1 (for DFT messages): Financial transaction
PV1: Patient Visit
TXA: Transcription Document Header
For example:
MSH|^~\&|||||||MDM^T02^MDM_T02|8001|P|2.3|||||||||
PID|||18178819Y||Patient’s Name||||||||||||||||||||||||||||||||||
TXA||OATELE||01/25/18 12:00:00 AM|17621|||||||OATELE8001|||||||||||
OBX||FT|||{Value}||||||||||||||||||||
So, in this example, segments are:
MSH: Message header
TXA: Transcription Document Header
PID: Patient identification
OBX: Observation result
The HL7 MSH (Message Header)
In every HL7 message type, the HL7 MSH (Message Header) segment is present. Here, this segment determines the message’s purpose, destination, source, and certain syntax specifics like delimiters (separator characters) & character sets. Along with the only exception being HL7 batch messages, this is always the first segment in the HL7 message.
Generally, there are 19 fields in the MSH segment, six of which are required for all messages processed using the HL7 standard. Those six are:
- Field separator
- Encoding characters
- Message type
- Message control ID
- Processing ID
- Version ID
The most important of the MSH fields in the entire message is the MSH-9 (Message Type) field. And, it specifies the type of message is being transmitted ( ORM, ADT, ACK, ORU, etc.) and also what the trigger event is. The time when the message is loaded, often the first field examined to determine processing is the value in this field.
SEQ-1
LEN-1
DT-ST
OPT- R
RP/#-
ELEMENT NAME-Field Separator
SEQ- 2
LEN-4
DT-ST
OPT-R
RP/#-
ELEMENT NAME-Encoding Characters
SEQ- 3
LEN-180
DT-HD
OPT-O
RP/#-
ELEMENT NAME-Sending Application
SEQ-4
LEN-180
DT-HD
OPT-O
RP/#-
ELEMENT NAME-Sending Facility
SEQ-5
LEN-180
DT-HD
OPT-O
RP/#-
ELEMENT NAME-Receiving Application
SEQ-6
LEN-180
DT-HD
OPT-O
RP/#-
ELEMENT NAME-Receiving Facility
SEQ-7
LEN-26
DT-TS
OPT-O
RP/#-
ELEMENT NAME-Date/Time of Message
SEQ-8
LEN-40
DT-ST
OPT-O
RP/#-
ELEMENT NAME- Security
SEQ-9
LEN-7
DT- CM_MSG
OPT-R
RP/#-
ELEMENT NAME-Message Type
SEQ-10
LEN-20
DT-ST
OPT-R
RP/#-
ELEMENT NAME-Message Control Id
SEQ-11
LEN-3
DT-PT
OPT-R
RP/#-
ELEMENT NAME-Processing Id
SEQ-12
LEN-8
DT-ID
OPT-R
RP/#-
ELEMENT NAME-Version Id
SEQ-13
LEN-15
DT-NM
OPT-O
RP/#-
ELEMENT NAME-Sequence Number
SEQ-14
LEN-180
DT-ST
OPT-O
RP/#-
ELEMENT NAME-Continuation Pointer
SEQ-15
LEN-2
DT-ID
OPT-O
RP/#-
ELEMENT NAME-Accept Acknowledgement Type
SEQ-16
LEN-2
DT-ID
OPT-O
RP/#-
ELEMENT NAME-Application Acknowledgement Type
SEQ-17
LEN-2
DT-ID
OPT-O
RP/#-
ELEMENT NAME-Country Code
SEQ-18
LEN-6
DT-ID
OPT-O
RP/#-
ELEMENT NAME-Character Set
SEQ-19
LEN-3
DT-CE
OPT-O
RP/#-
ELEMENT NAME-Principal Language of Message
Here, the first two fields define the separator characters, which we use throughout the message.
The MSH-1 field shows the field separator.
The MSH-2 field shows the other separator characters for the message in this sequence:
- Component
- Field repeat
- Escape character
- Subcomponent
MSH-9 (Message Type) – It shows the type of message and trigger event
MSH-10 (Message Control ID) – This shows the number or other unique identifiers for the message.
MSH-11 (Processing ID) – It shows the HL7 processing ID or processing mode;
MSH-12 (Version ID) – It tells about the HL7 version used in the message (i.e., 2.1, 2.3, 3.0, etc.)
Determining the HL7 Message Type
There is a particular type of each HL7 message. And, its type determines what health-related information is being provided in this message. Also, the message type indicates what segments can be included as part of the message.
To determine the message type of an HL7 message, do examine its MSH segment. However, the message type is normally the ninth field of this segment.
For example:
MSH|^~\&|||||||MDM^T02^MDM_T02|8001|P|2.3|||||||||
PID|||18178819Y||Patient’s Name||||||||||||||||||||||||||||||||||
TXA||OATELE||01/25/18 12:00:00 AM|17621|||||||OATELE8001|||||||||||
OBX||FT|||{Value}||||||||||||||||||||
So here the type of message is MDM^T02, that is, “Medical Document Management.”
Conclusion
So, we have learned how we can use HL7 Messages for transferring electronic data between diverse healthcare systems in detail. We hope this blog gives you an idea regarding the same.
Happy learning!
