Last Updated | September 13, 2021
HL7 messages are used whenever healthcare data needs to be transferred between disparate systems or different healthcare providers. These messages are sent in response to trigger events associated with patients, such as when a patient is being admitted into a clinic or when they are being discharged. Each HL7 message comprises of various segments in a specific sequence and take some practice to decipher.
Each HL7 message consists of one or more segments, which make up different lines of text. A carriage return character (\r)) separates each segment from the next. Each segment further contains fields, which are separated by the pipe ‘|’ character. Each field may contain further sub-fields, each of which are separated by the ‘^’ character.
Each HL7 message includes a message type, dictated by a three character code, which indicates why the message is being sent and which triggers an event. The MSH-9 field of the message contains both the message type as well as the trigger event. For instance, in an HL7 message such as ADT-A01, the field ADT is the HL7 message type, and A01 is the trigger event. This type of message reads as “patient admit” message.
Here is what a typical HL7 message looks like:
SMITH^WILLIAM^A^III||19610615|M||C|1200 N ELM STREET^^JERUSALEM^TN^99999?
NK1|1|SMITH^OREGANO^K|WI^WIFE||||NK^NEXT OF KIN
Before you attempt to read this complicated HL7 message, you should understand its various components. Each HL7 message contains various segments, fields, components, and subcomponents. Every line in a message is called a segment and contains information of a specific type. Each segment has a three-character label, such as ‘MSH’, ‘PV1’, ‘NK1’ or ‘PID’, and a hierarchy of fields and sub-fields grouping related data. Various fields within each segment are separated by the ‘|’ character. If a segment or field is being repeated, it is indicated by the presence of the ‘~’ character. Within each field, components are separated by the ‘^’ character, while sub-components are separated by the ‘&’ character.
Now that you can sort out each part of the message, it is time to decipher each segment separately. Remember that each segment of the message contains one specific category of information, which is evident from the three character code. In our example message, we see four different HL7 segments. The MSH segments holds information about the sender and receiver of the message, as well as the time stamp. Since the MSH segment contains information about the message itself, each HL7 message has MSH as the first segment, and EVN (event type) as the second segment. The PID segment incorporates patient demographics, such as name, medical ID, location, and such. The Next of Kin (NK1) segment delineates information about the patient’s next of kin, while the PV1 segment includes every piece of data related to patient’s hospital stay, such as the doctor and assigned room. “0x0D” marks the end of each segment.
Now, let’s dig deeper within each segment. Each segment consists of several fields, separated by ‘|’. Each field can be a primitive data type or contain more fields (sub-fields), denoted by the character ‘^’. Sub-fields may further contain sub-sub-fields, which are separated by the ‘&’ character.
Remember that segments are either mandatory or optional. For instance, the MSH segment and the PID (Patient identification) segment are necessary to understand messages such as ADT^A04 (Register Patient). Some segments, such as those containing patient allergen information, are optional since patients may or may not have allergies.
There are many types of HL7 messages, each with its own unique purpose and message contents. Each message format in HL7 has a specific code of three characters and each serves to trigger an event. While there are numerous messaging formats in HL7, the most common include ACK (General Acknowledgment), ADT: Admission, Discharge, and Transfer, which carry patient demographic information, and ORM: Pharmacy/Treatment Order Message which carries information about an order. The ORU: Observation message type transmits observations and results, such as clinical lab results and imaging reports, from the producing system. SIU: Schedule Information message type is used to create, modify, and delete patient appointments and has 14 different trigger events.
Similarly, the RDE: Pharmacy/treatment Encoded Order Message is used by clinics to send orders to the pharmacies. Other important messaging types in HL7 include BAR – Add/change billing account, QRY – Query, original mode, MFN – Master files notification, and DFT – Detailed financial transaction.
HL7 messages are generally transmitted using the TCP/IP protocol over a local network, such as within an hospital. TCP/IP data is sent as a stream of bytes, which means that numerous message may be sent as a continuous stream. But this creates a confusion, since we would need to define a starting and ending point for each HL7 message. This is where you can use Minimal Lower-Layer Protocol to add a header and footer to each message to know where it begins and ends. These headers and footers are not actually shown in the transmitted message.
HL7 message transmission needs an adequately designed protocol in the hospital. For this reason, a well-designed UX design healthcare will help ensure proper protocol implementation, hence proper HL7 message transmission. Also, you can depend on Folio3’s integration service to design a good UX design.
Folio3 hl7 integration solutions work accurately alongside some of the most challenging healthcare apps.
The Health Level 7 Version 3 is quite different from version 2, since it supports the exchange of clinical information and electronic documents in the XML syntax. The V3 specification was released to eliminate variances and improve interoperability between all users of the standard. Another difference is that v3 includes both messages and documents, which are also called clinical document architecture.
The HL7 Order Entry (ORM) message is a general order message that is used to transmit information about a patient-specific order against a trigger event, such as a new order placement, a cancellation of an existing order, updates to an order, discontinuation, etc. While most HL7 messages have several types, the ORM message only has one; ORM^001. Each ORM message consists of several segments and groups of repeating and non-repeating segments, such as the MSH, PID (in case of a new order), a notes and comments segment (NTE2), observation (OBX), information about Patient visit (PV1 and PV2), diagnosis (DG1), insurance details, Clinical trial information (CTI) and billing details (BLG).
A typical HL7 V2 message has a 3 character string identifier, such as ACK (Acknowledgement), ADT (Send Demographic Update), or RSP (Return Immunization History). The trigger of a V2 message is a real-life event that necessitated communication, such as patient admission into a clinical facility. Unlike flat file structures, version 2 messages can be expanded or shortened to carry only the necessary data. For instance, some segments and fields are optional or repeat. If no information is available for a patient’s next of kin (NK1), this segment can be removed, or if there are multiple Next of Kin, each would have a separate NK1 repeat segment. Each V2 message is composed of several segments, each with its own identifier and a separate line. Each segment is composed of composites, which carry the data. Each field within a segment is separated by the ‘|’ character. Each sub-composite within a field is separated by a ‘^’ character. Repeating fields are preceded by the ‘~’ character.
This is how a simple V2 ACK message looks like!
MSA|AA|9B38584D|Everything was okay dokay!|
Here, the MSH segment contains information about the message itself, such as the time stamp, and the sender and the receiver of the message. MSH-10 field contains the message ID. When a message is acknowledged, this field of the acknowledgment message contains the same identifier as the message that it is acknowledging. The second segment, MSA, denotes the status of the message, here the status is AA, which translates to Positive acknowledgment. The id of the original message is returned in the MSA.
Admission, discharge, transfer (ADT) notifications are most commonly used to exchange the patient status within a healthcare facility. ADT messages are used to synchronize patient demographic, such as contact information, address, medical Record number, insurance, next of kin, and visit information, such as length of stay and attending physician, across myriad healthcare systems. Initiated by the EMR or a registration application, ADT messages also include reasons for admission or discharge. ADT messages are highly important in value-based care since they contain a repository of valuable information that can affect point-of-care decisions.
You need a software such as Health Level 7 to open and read an HL7 file. Without proper software, Windows won’t be open to open this type of file and you will receive an error. If you cannot open your HL7 file correctly, click on “Open with” and choose the pertinent application.
What is MSH hl7?
The MSH segment contains important information about the message itself, such as intent, source, destination, as well as some specifics of the syntax of a message. MSH segment includes both the message type and trigger event.
ADT-A08 (update patient information) messages are used to notify the receiving systems of a change in the address or a name of a patient.
ADT-A04 message relates to “register a patient” event. This notification is sent to notify that a patient has arrived or checked in as a one-time, or recurring outpatient, and hasn’t yet been assigned a bed. This message is sent for both emergency room patients and outpatients.
Think of HL7 segments as logical grouping of data field. Each HL7 message consists of several segments, each characterized by a unique 3-character code identifier. Each segment of the message contains one specific category of information, such as patient visit data or insurance data. There are about 120 segment codes available for HL7, including MSH, PID, NK1, and PV1.
Yes, HL7 is an actively used programming language which denotes a set international standards for transfer, integration, sharing and retrieval of clinical and administrative data between the medical applications of various healthcare providers. Folio3 Medical app development solutions helps develop application that parse and decode HL7 messages.
In its most basic form, each HL7 message consists of segments, fields, components and sub-components. Components and subcomponents further contain the data within data fields.
There are 51 types of ADT message, but a few common ADT messages include:
A Z-segment is a message segment that contains clinical or patient data but isn’t actually part of the HL7 standard. The option to add z segments is what makes HL7 such a flexible standard. All Z segments start with “Z”.
In HL7, the ORM is a general order message that is used to transmit information about an order. The ORM message has only one type; ORM-O01 message.
The OBX segment is used to transmit key clinical observation/results back to the requesting system, to another physician system, or or to an archival medical record system.
The HL7 RDE message is often used to place orders to medication dispensing systems and may contain a full list of the medication a patient has been prescribed with.
The easiest way to convert raw HL7 messages to XML is to use a HL7 to XML Transformer.
The patient visit segment (PV1) contains basic inpatient or outpatient encounter information. This type of message is most commonly used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis.
The Laboratory Test Compendium Framework within HL7 delineates the laboratory order codes for systems that support the electronic laboratory ordering functionality. Folio3’s team of HL7 integration experts offer exceptional Folio3 EHR/EMR integration services to help organizations gain seamless HL7 integration solutions.
An Overview: How Can The Internet Of Things (IoT) Benefit Healthcare Institutions? What we are…
Overview: How to Build an Electronic Health Record System There are numerous electronic health record…
Overview: How to Build a Telemedicine Platform to Start a Telemedicine Business? We explain why telemedicine…
Overview: Create EMR Software by Folio3 with 8 Easy Steps About fifteen years ago, you…