HL7 Overview

HL7, which is an abbreviation of Health Level Seven, is a standard for exchanging information between medical applications. This standard defines a format for the transmission of health-related information. Information sent using the HL7 standard is sent as a collection of one or more messages, each of which transmits one record or item of health-related information. Examples of HL7 messages include patient records, laboratory records and billing information. The following sections provide an overview of the HL7 standard. The following topics are covered:

What an HL7 message looks like, and what its components are; What versions of the HL7 standard are in use or are under development; The acknowledgment (ACK) protocol that indicates that an HL7 message has been successfully received.

Additional sections discuss the advantages and disadvantages of using the HL7 standard and provide technical details of the HL7 standard and its common transport methods. You will not need to read these sections to understand the HL7 standard, but they may be useful to you if you need additional background information to implement your application or interface.

Understanding HL7 Messages

This section describes the contents of an HL7 message and how an HL7 message is organized. The following topics are covered:

The components of an HL7 message; The delimiter characters that are used to separate these components; How to determine the type of an HL7 message; How message segments are organized.

Components of an HL7 Message

An HL7 message consists of one or more segments. Each segment consists of one or more composites, also known as fields.

The following sections provide an example of a typical HL7 message, and describe segments and composites in more detail.

Example HL7 Message

Here is an example of a typical HL7 message:

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457| D|2.5| PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B| 254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359|||M|NON| 400003403~1129086| NK1||CONROY^MARI^^^^|SPO||(216)731-4359||EC||||||||||||||||||||||||||| PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684||||||||||||||||||||||||| 199912271408||||||002376853

HL7 messages are in human-readable (ASCII) format, though they may require some effort to interpret. Each message consists of one or more segments. A carriage return character (\r, which is 0D in hexadecimal) separates one segment from another. Each segment is displayed on a different line of text.

Segments
In an HL7 message, each segment of the message contains one specific category of information, such as patient information or patient visit data. For example, consider the sample HL7 message that you saw in the previous section:

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457| D|2.5| PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B| 254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359|||M|NON| 400003403~1129086| NK1||CONROY^MARI^^^^|SPO||(216)731-4359||EC||||||||||||||||||||||||||| PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684||||||||||||||||||||||||| 199912271408||||||002376853

In an HL7 message, the name of each segment in the message is specified by the first field of the segment, which is always three characters long. This example message contains four

segments: MSH, PID, NK1 and PV1. Different types of HL7 messages contain different segments. (For more information on the type of an HL7 message, see Determining the Message Type.) The segments in this example contain the following information:

The MSH (Message Header) segment contains information about the message itself. This information includes the sender and receiver of the message, the type of message this is, and the date and time it was sent. Every HL7 message specifies MSH as its first segment.

The PID (Patient Information) segment contains demographic information about the patient, such as name, patient ID and address. The NK1 (Next of Kin) segment contains contact information for the patient's next of kin. The PV1 (Patient Visit) segment contains information about the patient's hospital stay, such as the assigned location and the referring doctor.

Over 120 different segments are available for use in HL7 messages.

Composites
Each segment of an HL7 message consists of one or more composites (also known as fields). By default, the | (pipe) character is used to separate one composite from another. A composite can be a primitive data type (such as a character string or a number), or can contain other composites. If a composite contains other composites, these sub-composites (or sub-fields) are normally separated by ^ characters. If a sub-composite also contains composites, these sub-subcomposites are normally separated by & characters. Sub-sub-composites must be primitive data types. For an example of a typical composite, consider the PID segment of the sample message that you have seen in the previous sections:

PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^| 19480203|M||B|254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359||| M|NON|400003403~1129086|

In this segment, the fifth composite is the patient name, which is DOE^JOHN^^^^. (The four ^^^^ characters at the end of this composite indicates that it has a total of six sub-

composites, and that only the first two of the sub-composites are defined.) In this composite, DOE represents the family name of the patient, and JOHN is the patient's given name.

HL7 Delimiter Characters

As you have seen in the previous sections, certain special characters separate one composite in a segment from another, or separate one sub-composite from another. These special characters are known as delimiter characters. This section describes delimiter characters in more detail, how to use escape characters to include a delimiter character as part of a composite, and how to define new delimiter characters.

Delimiter Characters
The following table lists the default delimiter characters used in HL7:

Character 0x0D | ^ & ~ \

Purpose
Marks the end of each segment. Composite delimiter. Sub-composite delimiter. Sub-sub-composite delimiter. Separates repeating fields. Escape character

Delimiter Escape Sequences

If an HL7 message contains one of the special delimiter characters as part of its message content, you can use a special escape sequence to specify the delimiter character. This ensures that any application that processes HL7 messages can always distinguish between a delimiter character and a character that is part of the message text.

Each delimiter character has its own escape sequence. This escape sequence consists of the \ character followed by a unique capital letter, followed by \. The following table lists the delimiter characters and their equivalent escape sequences:

Character & ^ | ~ \ Hexadecimal character xx

Escape Sequence
\T\ \S\ \F\ \R\ \E\ \Xxx..\

In the \Xxx\ escape sequence, xx is a two-digit hexadecimal number representing the ASCII value of a character. Note that the \ escape character has its own escape sequence. In addition to the above escape sequences, some additional special escape sequences are defined. These escape sequences are left unchanged.

Sequence/Type

Format

Highlighting Sequences

\H\ \N\ \.br\ \.fi\ \.nf\ \.sp\ \.in\ \.ti\ \.sk\ \.ce\

Formatting Sequences (starting with a period)


Character Set Codes

\Cxxyy\ (single-byte) \Mxxyy\, \Mxxyyzz\ (multi-byte)

These escape sequences enable you to include formatting information as part of a segment composite.

Delimiter Redefinitions
The Delimiter Characters section lists the default delimiter characters that are normally used in HL7 messages. An HL7 message can choose to use different delimiter characters if the standard characters are not convenient to use. In any HL7 message, the delimiter characters that the message is using are specified as the first field of the MSH segment. (Recall that every HL7 message must include an MSH segment, and that the MSH segment must be the first segment of the message.) If the message is using the default delimiter characters, the MSH segment of the message starts with the following:

MSH|^~\&

The characters immediately following MSH indicate the delimiter characters in use in this message. They are, in order:

The delimiter character that separates one composite from another (the default is |); The delimiter character that separates one sub-composite from another (default ^); The delimiter character that separates repeating fields (default ~); The delimiter character that specifies the start or end of an escape sequence (default \); The delimiter character that separates one sub-sub-composite from another (default &).

If an incoming HL7 message uses different delimiter characters, these first five characters of the MSH segment define the delimiter characters that are used. For example:

MSH#^~\&

Here, #, not |, is the delimiter character that separates one composite from another.

Determining the Message Type

Each HL7 message is of a particular message type. This message type indicates what healthrelated information is being provided in this message. The message type also determines what segments can be included as part of the message. To determine the message type of a message, examine its MSH segment. The message type is normally the ninth field of this segment. For example, consider this MSH segment, which you have seen before:

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457| D|2.5|

Here, the message type is ADT^A04, which is "Register a Patient".

HL7 Segments
The following sections provide more information about segments in HL7 messages and how they are organized and used. The topics that are covered are:

Repeating and optional segments; Custom segments, also known as Z-segments; Present but null fields in segments; Segment groups; The standard segment grammar notation.

Repeating and Optional Segments

Some HL7 message types allow a segment to be repeated one or more times, or allow a segment to be optionally present. For example, repeating segments are useful for messages that contain contact information, as they make it possible to provide more than one contact. For instance, multiple NK1 (Next of Kin) segments may be provided if a patient has more than one person that can be contacted in case of emergency:

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457| D|2.5| PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B| 254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359|||M|NON|

400003403~1129086|999-| NK1||CONROY^MARI^^^^|SPO||(216)731-4359||EC||||||||||||||||||||||||||| NK1||DOE^JOHN ^^^^|SPO||(216)731-4222||EC||||||||||||||||||||||||||| NK1||DOE^ROBERT ^^^^|SPO||(216)731-4222||EC||||||||||||||||||||||||||| PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684||||||||||||||||||||||||| 199912271408||||||002376853

Optional segments are useful for providing information that is not provided in all messages. For instance, an AL1 (Patient Allergy Information) segment may be included if a patient has allergies

Custom Segments
If an HL7 message contains customized data that cannot be included in any segment that is defined for its message type, you can create a custom segment to transmit this data. By convention, all custom segments begin with the letter Z. For example, a ZPD segment could be created to contain customized patient demographics information. These custom segments are known as Z-segments. Applications that process HL7 messages are usually configured to ignore Z-segments that they do not know how to handle.

Present but Null Fields

In segments, it is important to note that there is a difference between fields that have no value defined for them and fields that have a null value defined for them. If a field is not defined, there is nothing between the two | characters that delimit the field:

OBR|||||||||

A null value is indicated by two double-quote characters:

OBR|||||""||||

A field for which a null value has been defined is often referred to as present but null. Present but null fields are used in many applications.

Segment Groups
Some message types support segment groups. A segment group is a collection of segments that always appear together. Some segment groups can be optional or repeating. For example, messages of type ORU^R01 (Lab Result) can have one or more Result Group segment groups defined. Each Result Group consists of one OBR (Observation Request) segment and one or more OBX (Observation/Result) segments. For instance, the following message includes two Result Group segment groups:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01| MESA3b781ae8|P|2.5|||||||| PID|||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct|||||||||||| OBR||||4550|||20010501141500.0000||||||||||||||||||F|||||||||||||||||| OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F|||||| OBX|2|TX|SR Text||Lungs expanded and clear. Conclusions Normal PA chest x-ray.||||||F|||||| OBR||||4551|||20010501141500||||||||||||||||||F|||||||||||||||||| OBX|1|HD|SR Instance UID||1.113654.1.2001.10.2.1.603||||||F|||||| OBX|2|HD|Study Instance UID|1|1.113654.1.2001.10||||||F|||||| OBX|3|HD|Series Instance UID|1|1.113654.1.2001.10.1||||||F||||||

Segment Grammar Notation

By convention, a standard segment grammar notation is defined to provide a convenient way to indicate the segments that can be included in a particular type of HL7 message. Many vendors use this segment grammar notation to specify what segments may be included with each type of HL7 message that they send. In the standard segment grammar notation, segments are listed from left to right, starting with the first segment in the message (which is always MSH). For example, consider this HL7 message, which you have seen before:

MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457| D|2.5| PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B| 254 E238ST^^EUCLID^OH^44123^USA||(216)731-4359|||M|NON| 400003403~1129086| NK1||CONROY^MARI^^^^|SPO||(216)731-4359||EC|||||||||||||||||||||||||||

PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN FADZL^BONNIE^^^^|||||||||| ||2688684||||||||||||||||||||||||| 199912271408||||||002376853

The segment grammar notation for this message would be:

MSH PID NK1 PV1

In the segment grammar notation, optional segments are enclosed in square brackets []. For example, if a PV2 (Patient Visit - Additional Information) segment can be optionally included with messages such as the one shown above, the segment grammar looks like this:

MSH PID NK1 PV1 [PV2]

Repeating segments are enclosed in curly brackets {}. For example, if multiple NK1 segments can be included, the segment grammar looks like this:

MSH PID {NK1} PV1 [PV2]

A segment that is both optional and can be repeated is enclosed in both square brackets and curly brackets. For example, if the NK1 segment is optional but can be repeated, the segment grammar looks like this:

MSH PID [{NK1}] PV1 [PV2]

Optional or repeating segment groups are indicated by specifying multiple segment names inside square brackets or curly brackets. For example, consider the sample Lab Result message that you have seen earlier:

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|REPOSITORY|XYZ|||ORU^R01| MESA3b781ae8|P|2.5|||||||| PID|||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct|||||||||||| OBR||||4550|||20010501141500.0000||||||||||||||||||F|||||||||||||||||| OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F|||||| OBX|2|TX|SR Text||Lungs expanded and clear. Conclusions Normal PA chest x-ray.||||||F|||||| OBR||||4551|||20010501141500||||||||||||||||||F|||||||||||||||||| OBX|1|HD|SR Instance UID||1.113654.1.2001.10.2.1.603||||||F||||||

OBX|2|HD|Study Instance UID|1|1.113654.1.2001.10||||||F|||||| OBX|3|HD|Series Instance UID|1|1.113654.1.2001.10.1||||||F||||||

This message can optionally contain one or more Result Groups, with each Result Group consisting of one OBR message and one or more OBX messages. The segment grammar notation for this message is:

MSH PID [{OBR {OBX}}]

Here, OBR {OBX} is the segment grammar notation for a Result Group. The Result Group is enclosed in both square and curly brackets, as it is optional and can be repeated.

Versions of the HL7 Standard

To make it easier to send and receive health-care information, the HL7 organization has defined a standard that specifies what types of HL7 messages can be sent, what segments can be included in these messages, and what fields can be included in their segments. The HL7 standard is constantly evolving. To date, the HL7 committee has released eight versions of the HL7 standard:

2.1 2.2 2.3 2.3.1 2.4 2.5 2.5.1 2.6

A revised version of the HL7 standard, version 3.0, has been in ongoing development since 1997, but is not yet in common use. The following sections provide more information about these versions of the HL7 standard. HL7 Version 2.X HL7 Version 3.0

HL7 Version 2.X

Version 2 of the HL7 standard is the version that is currently in common use. It has been designed to always be backward compatible. For example, version 2.6 of the standard is compatible with version 2.5. This ensures that existing applications that use the standard do not have to be constantly updated to match the evolving standard. Because these versions of the standard are backward compatible, they are often referred to as version 2.X of the HL7 standard.

Because version 2.X is backward compatible, the exact version number of the HL7 message is usually not important. What is often more important is how the vendor that is sending HL7 messages to you is populating the fields and segments defined in the standard.

For an example of backward compatibility in version 2.X of the HL7 standard, consider the Patient ID field in the PID segment. Early versions of HL7 declared the Patient ID to be just a simple, one-field identifier:

|PatientID|

In more recent versions, the Patient ID field has been modified to include more sub-fields. Examples of sub-fields that have been added include an identifier check digit, an assigning authority, and an identifier type code. To ensure backward compatibility, the sub-fields that have been added to the Patient ID field are optional.

When a field can contain several sub-fields that are optional, the message does not need to include delimiters if all of the fields are empty. For example,

For example,

|234324^^^|
is equivalent to:

|234324|

You only need to supply delimiters for empty fields if a later field contains a value:

|234324^^^X|
This helps to ensure backward compability: if new subfields are defined, they are assumed to be empty.

Backward compatibility issues with HL7 XML formats are less straightforward. For more information, see Backward Compatibility Issues in the XML <-> HL7 Translation chapter.

HL7 Version 3.0

Since 1997, the HL7 organization has been developing version 3.0 of the protocol. Unlike 2.X versions, HL7 3.0 is based largely on a single formal model called the Reference Information Model, or RIM. The goal of RIM is to reduce the implementation costs of HL7enabled solutions and further standardize the HL7 communication specifications between healthcare systems. HL7 3.0 is a complete redefinition of the HL7 standard that is attempting to overcome some of the issues with the current standard. Version 3 will change not only the content of the messages and fields, but also the encoding rules, LLP (low level communication protocols), base data types and even the roles of the applications participating in HL7 communications. XML is the planned medium for HL7 interchange instead of the simple ASCII text that is currently in use. The difficulties with HL7 3.0 are:

Despite the length of time it has been under development, the 3.0 standard has not yet been clearly defined. Very few health-care facilities have migrated to version 3.0, since this version is not compatible with version 2.X. Applications that support version 3.0 would also need to support version 2.X. Creating an interface between version 2.X and version 3.0 would be difficult and expensive.

Because of these difficulties, version 2.X remains the standard that is used by both healthcare facilities and vendors.

The ACKnowledgment Protocol

An important part of the HL7 standard is the ACKnowledgment protocol. Every time an application accepts a message and consumes the message data, it is expected to send an ACKnowledgment message back to the sending application. The sending application is expected to keep on sending a message until it has received an ACK message.

If you do not follow this rule, data may be lost in transmission.

An acknowledgment message consists of two segments:

An MSH segment, which contains information about the sending and receiving applications and contains the Message Control ID of the message; An MSA segment, which indicates whether the message was accepted or rejected.

The diagram below shows a typical ACK message with the important fields labelled:

ACK Message An acknowledgment message is not sent until the data in the HL7 message has been read and consumed.

The Message Control ID, which is specified in field 10 of the MSH segment, is a unique identifier that is associated with a particular HL7 message. When a message is processed and acknowledged, field 10 of the MSH segment of the acknowledgment message contains the same identifier as the message that it is acknowledging. This is how applications can keep track of what messages have been successfully acknowledged. The MSA segment indicates whether the message that is being acknowledged was processed successfully. The first field of the MSA segment contains the acknowledge status, which is one of the following:

Acknowledge Status
AA

Meaning
Positive acknowledgment: the message was successfully processed. Application error: there is a problem processing the message. The sending

AE

application must correct the problem before attempting to resend the message. Application reject: there is a problem with field 9, field 11 or field 12 of the

AR

MSH segment of the incoming message, or there is a problem with the receiving application that is not related to the message or its structure.

Advantages and Disadva ntages of HL7

This section will discuss the advantages and disadvantages of HL7 by taking a closer look at open systems (HL7) vs. closed systems (proprietary interface model) and the pros and cons of each model. You will also learn about the advantages of using cost-effective HL7 tools and why HL7 is not simply plug-and-play. Open Systems vs. Closed Systems Using Cost-Effective HL7 Tools Why is HL7 Not Plug-and-Play? HL7 Interfaces and Mobile Devices

Open Systems vs. Closed Systems

Following a standard protocol provides you with an advantage of connecting to any system that supports this particular part of the standard, both now and in the future. For example,

Internet Explorer or Netscape can connect to any existing and future web server using HTTP and HTML standard protocols. Adhering to a standard protocol is called "open system architecture". Anybody can interface with an open system using appropriate protocols, independent of its vendor. When using HL7, the interface allows for numerous systems to be added to a single HL7 feed. New systems can be added without having to modify the original source system as demonstrated in the following diagram:

HL7 Interface Model Now consider the proprietary system model:

Proprietary Interface Model "Closed" and "Proprietary" are used interchangeably throughout this section to mean that characteristics of the system are hidden by the vendor from the public domain. Although the closed-system model is easier to design and initially costs less to implement, closed systems have greater reliability on single vendors and more reliance on specific applications and technologies. Although the worldwide trend is to follow an open-system architecture, there are still tradeoffs in following a standard protocol when developing interfaces. For instance, a greater initial investment is required. Time and money must be spent to understand the standard and create the infrastructure required to support the standard, such as a parsing framework and networking code. However, the benefits are abundant. For example, it will be easier to answer user requirements because HL7 is considered the standard for exchanging data between healthcare systems. In addition, because HL7 is the standard, it will be easier to create a system that can interface with an open system now and in the future.

Using Cost-Effective HL7 Tools

Fortunately, the clear advantage of standards is that you do not have to develop the infrastructure for it from scratch. Standards create markets for tools, which means that you can buy generic tools to make your implementation easier.

When developing for a standard protocol such as HL7 and XML, there are many cost-effective, easy-to-use tools and programming components. These help to avoid low level creation, parsing and network communication of HL7 and XML messages over the network. Using standard tools can save you up to 90 percent of the low level work that would otherwise be required.

Why is HL7 Not Plug-and-Play?

Unlike many other standard protocols, HL7 is not really plug-and-play. For historical reasons, each vendor implements HL7 messages in slightly different ways. As a result, if you design your HL7 interface yourself, you will have to modify the HL7 parser and the application for each new installation. The following table explains why HL7 is not plug-and-play:

Reason

Description
Some vendors tend to omit fields in the message instead of leaving them

Missing Fields

empty. This will change the number of every subsequent field from the start of the message.

Same Data in Different Fields

The same information may be located in other fields - and even in different segments - in various HL7 implementations. The same data may be provided in different formats. For example, timestamp

Same Data in

information should appear as 19991231100000.000, but some vendors divide

Different Formats the date and time into different sub-fields: 19991231^100000.000. This is
only one example of the possible mis-formats.

Different Versions Missing Values (including

The existence of a number of different versions allows data exchange only between applications that support the same version of HL7. Although the standard requires only a limited set of values to be present (95 percent of the fields are optional), some vendors omit even those with required

mandatory fields) values.

There is a lack of adherence to the segment grammar that is required by the standard. Some expected segments may be missing, while other unexpected segments may appear.

Invalid Segment Grammar

In this environment, it is important to be equipped with tools that deal with the diversity of HL7 implementations, standards and versions

HL7 Interfaces and Mobile Devices

If you have a medical application that interacts with mobile devices, and you want to modify this application to add an interface that reads or generates HL7 messages, you should note that an HL7 interface should not be contained on a mobile device. There are many reasons for this:

HL7 interfaces need to be persistent: HL7 interfaces are normally point-to-point interfaces that process persistent streams of data, such as Admit Discharge Transfer (ADT) events or lab results. An HL7 interface is a back-end datacenter server-toserver protocol that normally consists of interface engines that are monitored by hospital IT staff. When an interface goes down, alerts are raised until the interface is brought back up.

Configuration and change management: HL7 interfaces are usually interactions between applications created by multiple vendors, not interactions that are contained within a single vendor's application. When a vendor's system is upgraded, the HL7 interface often needs to be modified to preserve the integrity of the medical data that is being processed. If the HL7 configuration is centralized, this modification is easy to perform. If the configuration is spread across a large number of user devices, modification becomes a nightmare.

Licensing concerns: Many prominent HIS vendors charge substantial fees for each HL7 connection - in many cases, a minimum of $10,000 per interface. This means that server-to-server HL7 interfaces are more cost-effective.

Database and storage issues: Many HL7 interfaces, such as ADT feeds, consist of broadcast streams of data. These streams of data need to be stored in persistent databases so that patient demographic information can be obtained. These databases cannot be stored on mobile devices: such devices are not always activated, and their storage capacity is too limited to contain large persistent databases.

The typical solution implemented by most vendors that use hand-held devices for medical applications is shown in the diagram below:

A Typical Hand-Held Device Solution In this solution:

A server containing an SQL database is deployed on a server. An HL7 interface, such as Iguana, sends HL7 messages to the database and receives messages from it. The HL7 messages are sent to mobile devices using the appropriate proprietary synchronization protocol.

HL7 Technical Details

The following sections provide more detailed technical information related to the HL7 standard. These sections cover the following topics:

The protocol characteristics of the HL7 standard; The most common transport methods for HL7 messages.

HL7 Protocol Characteristics Common HL7 Transports

HL7 Protocol Characteristics

HL7 is a structured protocol that is used as a means of communicating between healthcare applications. The following descriptions provide an outline that define the characteristics of the HL7 protocol: Event-Driven Application-to-Application Point-to-Point OSI Level 7

Data Exchange Standard

Event-Driven
Real-world events, such as the admission of a patient, cause messages to flow between applications. In other words, an application that encounters a real-world event sends a message to other applications that need to be aware of this event.

Application-to-Application
HL7 defines a communication between two independent applications, rather than between closely coupled, client/server applications. The scope of interest for HL7 is the message exchange between the applications, rather than the specific role of each application in the healthcare delivery process.

Point-to-Point
HL7 is a messaging format that is independent of its transport method. However, it is typically used in a client/server environment for employing some form of a point-to-point protocol. For instance, HL7 can use the LLP Transport method to transfer messages between a client and a server. However, since a client must establish a connection to a server before a message can be sent, the client must have prior knowledge about the server. It is not normal for HL7 messages to use a non point-to-point protocol, where the client listens for 'broadcasts' from a particular server.

OSI Level 7
OSI Level 7 indicates that HL7's scope is the format and content of the data exchanged between the applications rather than how the messages are transmitted between computers or networks. In other words, HL7 does not specify how messages will be delivered between the applications. Usually a TCP/IP connection or FTP file transfer is used to deliver a message. However, within local area networks, the de facto standard is the Lower Layer Transport Protocol.

Data Exchange

HL7 specifies the way data exchange between applications will be accomplished. It does not specify how applications store or process this data. It would be advantageous for an application developer if their application's database structure coincided with HL7 message definitions, but this is not mandatory.

Standard
When you create a proprietary, non-standard link between two systems, you can create a message exchange system that better suits your personal needs and better fits the data structure of your application. However, the efforts invested in this link are useless when considering a connection to other third-party systems. Using HL7 means that your initial development effort can be reused again and again.

Common HL7 Transports

This section describes the most common transport method used to send HL7 messages, called the Lower Layer Protocol (LLP). A less common transport called the Hybrid Lower Layer Protocol (HLLP) is also briefly discussed. Although HL7 messages are sent via a variety of TCP/IP transports, including FTP, SOAP and SMTP, LLP is the most common method. LLP - Lower Layer Protocol TCP/IP Basics Hybrid Lower Layer Protocol (HLLP)

LLP - Lower Layer Protocol

The Lower Layer Protocol (LLP), sometimes referred to as the Minimal Lower Layer Protocol (MLLP), is the absolute standard for transmitting HL7 messages via TCP/IP. Since TCP/IP is a continuous stream of bytes, a wrapping protocol is required for communications code to be able to recognize the start and the end of each message. The Lower Layer Protocol is the most common mechanism for sending unencrypted HL7 via TCP/IP over a local area network, such as those found in a hospital. When using LLP, an HL7 message must be wrapped using a header and trailer (also called a footer) to signify the beginning and end of a message. These headers and footers are usually non-printable characters that would not be shown in the actual content of an HL7 message. The typical structure of an HL7 message being sent via LLP is described in the table below. It contains four parts:

Heade r

HL7 Message

Trailer

Carriage Return

The HL7 message is wrapped using a header and trailer (immediately Vertical followed by a carriage return): tab charact er (0x0B) Field separator Carriage return (0x0D)

MSH|^~\&||.|||199908180016||ADT^A04| ADT.1.1698593|P|2.5 PID|1||000395122||LEVERKUHN^ADRIAN^C^^^|| 19880517180606|M|

character (0x1C)

Moreover, you must also ensure that each segment is terminated by an 0x0D (carriage return) character. This is mandated by the standard, but often HL7 log data can be received via FTP or email where the segment separators have been transformed into 0x0A characters.

TCP/IP Basics
In this section, you will learn about the basics of TCP/IP based communication. This section will also discuss the roles of the client and server when implementing an HL7 interface, as well as the limits of TCP/IP. Client or Server Testing TCP/IP LLP Connections

Client or Server
When implementing an HL7 interface, your interface will either be acting as a Client or a Server. TCP/IP Server

A TCP/IP server is a program that listens on a TCP/IP port number receiving connections from clients. For instance, a web server is a special type of TCP/IP server that listens on port number 80. A TCP/IP server can have many different TCP/IP clients connected to it.

TCP/IP Client

A TCP/IP client is a program that connects to a TCP/IP server. For instance, Netscape and Internet Explorer are TCP/IP client programs that connect to web servers. A

TCP/IP client must specify both the host address or IP address, as well as the port number that it wants to connect to. TCP/IP Server Usage Example

A typical example of where you might want to implement an HL7 server is when you want to receive an ADT (Admit/Discharge/Transfer) feed to extract, for instance, patient demographics. Typically, you would write your interface as a TCP/IP server. You would then listen on a port number that you could negotiate with your counterparty, and the device sending you the ADT messages will connect to your server. This means you need to give the host and port number that you are listening on to the administrator of the ADT feed so they know how to connect to you.

TCP/IP Client Usage Example

A typical example of where you might want to implement an HL7 client is when you want to send lab results to a HIS (Health Information System). The administrator of the HIS system would need to give you the host or IP address of their HL7 server and the port number that it is listening on.

ACKnowledgment Messages

One final point that confuses many people is how HL7 ACKnowledgment messages should be sent. It is important to understand that when a TCP/IP connection is established, it is a two-way channel of communication. When a client establishes a connection to a server there is one channel on which the client can send data to the server, and another on which the server can send data back to the client. This latter channel should be used to send ACK messages.

Sometimes it is necessary to implement both a client and a server component for your product's HL7 interface. Avoid the temptation to follow some creative members of the computer community who use the client component to send back all the ACK messages. Your creativity will be someone else's problem. This certainly happens in the real world, but if you have the choice, make use of the fact that you can use the second channel of communication to send back ACK messages, as this is a much cleaner design

Testing TCP/IP LLP Connections

It can often be useful to test LLP implementations using a low-level tool to view the raw data being transmitted by an interface. An example of such a tool is MSOCS (shown below).

MSOCS Test Program MSOCS is a very simple tool to use and is useful for testing TCP/IP LLP Connections. To use the MSOCS application:

Check either the Client or Server radio button. In the Server TCP Port field, type the port you are sending data to.

The Receive field will be populated with output when a message is sent.

Cut and paste that message into a text editor, such as Notepad, and save the file as a text (.txt) file. Open this file in Visual C++, or in any hex editor that you prefer to use, making sure to do so in binary mode.

By examining the exact hexadecimal codes of the message, you can see exactly what is being sent. This is an excellent diagnostic tool for solving low-level problems.

Hybrid Lower Layer Protocol (HLLP)

The Hybrid Lower Layer Protocol (HLLP) is a variation of the more widely used Lower Layer Protocol. Like LLP, HLLP uses TCP/IP as its transport but incorporates error detection and verification via the use of checksums at the end of messages. The checksums are used to

verify that no data was corrupted. Checksums are typically computed for each block of data that is sent for the sending application and then verified for accuracy at the receiving application.

The checksums used in HLLP are non-standard, meaning they may vary from implementation to implementation.

A common type of checksum used in HLLP is called BCC (Block Character Check), which is the sum of all characters in a block. The BCC checksum is considered a weak checksum since it may be easy to find different blocks that generate the same block checksum. Although the BCC checksum is relatively easy to implement, it may not meet the commuication standards of most companies.

In practice, most vendors choose to use TCP/IP over LLP, rather than HLLP. LLP is a very simple protocol to incorporate and can be used instead of HLLP since the TCP/IP channel provides all of the services necessary for the error-free delivery of HL7 messages. This includes: 1. Connection Handshaking

The process by which two systems initiate communication. Start and end control characters are used to start/stop the transmission of data.

2. Full Duplex Data Transfer

The process by which a system transmits and bi-directionally receives data simultaneously.

3. Error Detection and Retransmission

The process by which the transport layer detects segments that fail transmission and retransmits them, if necessary.

4. Flow Control

The process by which the flow of messages between systems is managed by TCP through the use of ACKs and NACKs. Through the use of ACKs/NACKs and other builtin mechanisms in an HL7 application, you can manage the flow of data to ensure that messages are transferred efficiently and reliably.

5. Connection Termination

The process by which a connection is ended independently by each system via a handshake.

In most cases, HLLP is an unnecessary requirement as long as the two communicating health systems are using a reliable OSI transport layer since the transmission of messages, as well as the integrity of messages, is already verified by the underlying OSI protocols.