Introduction

This is an introductory tutorial on the HL7 2.x standard (often to referred to as "V2"). I just cover just enough basics to get you started. In the subsequent tutorials, we will dive into the details more when we look at it from a software development or configuration perspective.

Need for the V2 Standard

The abbreviation “HL7” stands for “Health Level Seven, Inc.”. It is a standards developing organization (SDO) that is accredited by the American National Standards Institute (ANSI). The organization was founded in 1987 to produce a standard for the exchange/integration/sharing/retrieval of electronic health information. Before the HL7 standard arrived, hospitals and other healthcare organizations would typically have many different software applications running on a variety of operating systems and hardware platforms and running in isolation. Even when these applications supported some network connectivity, they would exchange information using proprietary protocols. This made integration of applications, particularly from different vendors, very difficult. For example, a patient registration system would be unable to communicate with a billing system, or a laboratory system, and therefore, these systems would be unable to provide a consolidated view of a patient’s profile for use by healthcare professionals. As a result, most organizations were often locked into proprietary technologies/solutions, and the costs and risks associated with implementing, integrating and maintaining healthcare systems was extremely high.

Inception, Growth and Organizational Structure

All this has changed since 1987 when the HL7 organization was created, and its membership has grown from a modest 14 members in 1987 to over 2200 members worldwide, including 500 corporate members today and International Affiliates in 33 countries. The V2 standard published by this organization provided rules on how messages for various events occurring within the healthcare domain should be structured, formatted, transmitted and received (note: there was no official release of a 'V1 standard' and was a proof of concept only**). The “transmit/acknowledge” communication model forms the core principle of information delivery in systems following the HL7 standard. Acceptance grew rapidly as healthcare organizations as well as vendors realized the benefits it offered. Since the standard did not impose any specific network protocol for information delivery, software systems could communicate using a variety of transport protocols such as LLP, FTP and SMTP (more on all of this later). Besides developing standards to increase the effectiveness, efficiency and quality of their healthcare information delivery, the group also collaborates with other standards development organizations and national and international sanctioning bodies in the development of supportive and compatible standards (e.g., DICOM, IHE). Any one can become a member and can get access to published standards and other information at a highly discounted rate. The group has also begun offering a certification exam testing the standard’s core concepts. The certification might be useful to have if you want to make yourself more marketable as a systems integrator, software developer or a consultant. Please visit the organization’s website for more information on the certification.

Nothing diminishes anxiety faster than action. ~ Walter Anderson

Before you continue reading my article any further, you may also want to take a pause and [watch this excellent video by Marc Kohli explaining the typical workflow in radiology including how the HL7 standard (along with other standards such as DICOM) fits within it. I feel that this video really explains the big picture of how HL7 integrates into the larger healthcare workflow within any hospital network.

On V2 Message Encoding and Structural Components

V2 messages sent and received can be any one of the hundreds of message types that are defined in the HL7 message vocabulary. These HL7 messages are often created and sent by an information system in response to an occurrence of an event such as a patient admission, a patient discharge or a it may be a query to another system. And each message contains information about that event. And further, each of these HL7 messages are themselves made up of segments. These segments are considered the real building blocks of HL7 messages although the segments themselves are in turn comprised of fields. A segment has a three-character name and a pre-defined format of specific fields. The fields are separated by the “|” (pipe) character and may be further divided into sub-components with the “^” character. A “PID” segment for example contains information patient information such as ID numbers, name, address and date of birth. Different HL7 events trigger different message types - each message type has a defined set of segments that are joined together to provide all the required information regarding that event. Some segments are mandatory, and must be included in the message, and other segments are optional.

For example, an “ADT^A01” message (“ADT” stands for “Admission, Discharge, Transfer”) is sent because of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient’s stay in a healthcare facility. This event can trigger a notification to other auxiliary systems, say, a pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the laboratory, pathology and the radiology systems that a patient has been admitted and is entitled to receive services. This message is comprised of the MSH, EVN, PID, PV1 segments and sometimes more. The MSH segment contains details about the message such as sending and receiving systems, dates and message type. the EVN segment contains details about the triggered event such as event type, event date/time, the person that triggered the event. The PID segment contains details about the relevant patient. PV1 segment contains details of the patient’s visit to hospital, such as visit number, ward/bed, attending doctor, financial classification. So, all relevant information about the patient admission event is communicated to the receiving systems using this message. In the same manner, other information pertaining to patient, observation, finance and billing-related information can also be communicated between various software systems. The HL7 standards manual available from HL7 Inc. provides extensive details on trigger events, message types, and segments. interoperability between local vendors. Please refer to the standards body relevant to your country for more details.

V2 Message Acknowledgement Mechanisms

When the incoming message (see screen capture of sample ADT A01 message above) reaches the receiving system, a message acknowledgment (called “ACK” in HL7) is transmitted back to the sending system (shown in my screen capture below). This acknowledgment can take many different forms based on how well the receiving system was able to process the incoming message. If the message was successfully processed, a positive ACK message is sent to the sending system and the communication is concluded for that message. In HL7, a positive ACK is communicated by using an AA (Application Acknowledgment) value in the first field of the MSA segment of the transmitted the 3rd field in the MSA segment of the acknowledgment contains the same message control ID that was in the message created by the sending system. This permits the sending system to match the acknowledgment to the original message that it transmitted earlier. If there were errors during the processing of the incoming message, then negative acknowledgments (called “NACK” in HL7) are transmitted back to the sending system. The transmitting system can then diagnose, fix, and later resend the failed message back to the receiving system. A negative ACK is indicated by using an AE (Application Error) value in the first field of the MSA segment. This code indicates that were either a problem with the message structure, or the message itself.

Minimal Lower Layer Protocol (MLLP)

The V2 standard proposed a transport protocol built on top of the TCP/IP protocol called Minimal Lower Layer Protocol (MLLP). It is essentially a wrapping protocol where the core HL7 message is enveloped in special characters to signal the start and end of transmission of message information to the receiving application. HL7 messages transmitted using the MLLP protocol are prefixed with a start block character, message segments are terminated with a segment separator, and the messages themselves are then terminated with two characters namely an end block and a carriage return character. Most often, the character typically used to signify start block is a VT (vertical tab), which is ASCII 11. The FS (file separator), ASCII 28, is used to signify end block, and CR (ASCII 13), is used for carriage return. However, implementing sites are free to customize these to use different characters as and when necessary.

Conclusion

This forms the foundation on which the protocol is built. In my next article in this series, I will illustrate, using examples both in Java and C#, how to transmit, receive, parse and acknowledge HL7 messages using the MLLP protocol, which is the most popular form of transmitting and receiving HL7 messages today.

*You should read René Spronk's excellent article here if you are interested in digging a little deeper into the beginnings of the HL7 standard, .