What is Health Level 7?

In general, Health Level 7 is a standard for information exchange between medical applications. It defines the format and the content of messages that applications use when exchanging data with one another under various clinical or administrative circumstances. It provides for “loosely-coupled” communication between independent and disparate applications, rather than a client/server relationship, for example, that is referred to as “closely-coupled.”

HL7 does not describe how the data get from one place to another on a network—that's up to other protocols at the lower levels (see below). HL7 is a message-oriented structure designed to ensure that the meaning of the data gets across.

HL7 is also an event-driven protocol. This means that a specific event causes messages to be sent. For example, a patient being admitted to the hospital is an event that causes data to flow into the system to all areas that need to know about it. This is different from a client/server relationship, where data mainly flow when a client requests it.

The most extensively employed portion of the standard concerns messaging that facilitates dissimilar healthcare applications to exchange important sets of clinical and administrative data. We'll talk more about the messaging portion of the standard later.

The main thing to know or remember about HL7 is that it is a specification. Its development and management is controlled by a Standards Development Organization (SDO). The HL7 SDO is accredited by the American National Standards Institute (ANSI). Most SDOs produce standards. I've found that many times terms like standards, specifications, and protocols are commonly used interchangeably—don't let that throw you. There are specific definitions of these terms, but you'll find that they are used loosely in the literature.

The Health Level 7 organization is headquartered in Ann Arbor, MI. Like most other SDOs, it is a not-for-profit volunteer organization. Its membership consists of providers, vendors, payers, consultants, government groups, and those that have an interest in the development and advancement of clinical and administrative standards for healthcare. All ANSI-accredited SDOs must abide by a strict and detailed set of operating procedures that attempt to guarantee consensus, openness, and balance of all the interests. Members of SDOs are known as Working Groups. Working Groups are then arranged into technical committees and SIGs (Special Interest Groups).

The “7” in Health Level 7 refers to the 7th layer of the ISO OSI model. The International Organization for Standardization Open System Interconnection defines network communication in terms of a framework consisting of seven layers. Table 1 provides a brief overview of the OSI reference model (see also IT World from Sep/Oct 2000). Normally software application packages manage the upper 2 or 3 layers counting on the NOS (Network Operating System) to manage the rest of the layers and actual communication connection. In most descriptions of upper layer protocols, you'll find that there is little distinction made between layers 6 and 7. In other words, layers 6 and 7 are typically glommed together (to use a technical term). Again, the name HL7 refers to the fact that the specification operates at layer 7 of the OSI model.

HL7 is not a software package, but a set of specifications that define how an HL7 compliant software package is implemented and used. In this respect, it is very much like TCP/IP. TCP/IP is an open standard NOS that has many components that define all the aspects of network communication. There are many providers of TCP/IP compliant network operating systems or software, but TCP/IP really refers to the standard itself. Transport Control Protocol (TCP) is a spec within the standard for how communicating partners break up a long message into pieces, transmit them, and how they are reassembled by the receiver. There many parts to the TCP/IP standard that defines protocols that work at the different layers on the OSI model (Table 1). At layer 7 you'll find application services for file transfers, e-mail, and other network software services. Telnet and FTP are applications that exist entirely in the application level. Telnet is a terminal emulator that, for example, allows you to use your PC and network to connect to a main frame. File Transfer Protocol (FTP) defines in great detail how to transfer files across a network. FTP works similar to HTTP (Hyper Text Transfer Protocol) for sending Web pages from a server to a user's browser and SMTP (Simple Mail Transfer Protocol) for sending electronic mail across the Internet. All of these application specific specifications uses the TCP/IP protocols to enable data transfer. HL7 is very much like this, in that it defines or specifies how the protocol and all detailed application parts work. (By the way, I found a nice TCP/IP pocket reference guide while researching this month's topic. You techogeeks out there can check it out at www.sans.org/resources/tcpip.pdf.)

Rather than attempting to create your own messaging system between two network domains, use a standard method of communication. HL7 works to define all the areas of healthcare data communications. Compare this idea with the TCP/IP set of protocols; there are several NOSs that do not follow the TCP/IP standard. Novell Netware, Banyan VINES, and IBM's LAN Server are NOS examples that follow their own set of communication protocols. Also like these other NOSs, other private or protected protocols in the healthcare environment are not as popular or used as widely as those that follow HL7.

HL7 focuses on the interface requirements of the entire healthcare organization, while most other efforts focus on the requirements of a particular department. In addition, HL7 develops a set of protocols on the fastest possible track that is both responsive and responsible to its members on an ongoing basis. The group addresses the unique requirements of previously installed hospital and departmental systems, some with quite mature technologies.

There are many domains or common data groups in healthcare, including pharmacies, medical devices themselves, imaging networks, and insurance or claims processing transactions, to name a few. HL7, focused on clinical and administrative data, covers many aspects of these domains. The sidebar on page 378 shows what's covered in an earlier version of the HL7 spec. Also see the sidebar that addresses the differences between updates and upgrades (right).

Currently HL7 is in version 3. The main aspect of this upgraded version is the Reference Information Model (RIM). The purpose of the RIM is not just to find a way to share clinical data relative to the healthcare industry, but to ensure the meaning of the data gets shared as well. As there is a wide scope of interest in healthcare, it becomes very important to set down a list of assumptions about any specific topic. Different interest groups may have different ideas on what bits of data are important in any one event. RIM provides a comprehensive basis or source for all information categories used in the HL7 specification. Remember that the HL7 domains cover just the clinical and administrative data groupings.

Like the OSI reference model, the HL7 RIM defines a way for differing systems to communicate. I like the language used in the spec for the RIM where it says, “As HL7 specifications are used to connect information systems operated in different circumstances, across many types of healthcare delivery organizations and potentially across political jurisdictions, the HL7 RIM needs to be flexible enough to express a diverse range of information content while maintaining a unified framework.” In other words, the RIM contains precise definitions for any information being shared—including the data or message characteristics and the relationships between them. The attempt is to define the life-cycle of events that the message will carry. The entire spec is very detailed indeed to enable all of this. Think of it as an interconnected arrangement of data classes where each class is defined by their attributes (characteristics) and connected by their associations. Dig deeper into each class and you'll find more information about its specific definitions, connections, and constraints.

But it's not a database and is not based on any one vendor's system and any particular healthcare organization's system. It is a detailed description of data classes that includes its attributes, what other classes it connects with, and also lists any limitations. Think about it—what if you had to define every kind of data that runs across your organization's network in this way. After you've assembled your mega-list, then you'd have to build consensus among all interested parties that use that data, a huge undertaking, and that is what the working groups in the HL7 community are doing with the RIM. There is always a trade-off when building a spec like this—you want it to be able to cover as much as possible to make it flexible to cover any occurrence, but you also don't want it to get too large to be unmanageable. I give a lot of credit to the people that work to organize, define, and generally put into order specifications that we can all benefit from!

The main portion of the HL7 standard revolves around the message. The message is a group of information or data that defines a specific event. The message is made up of several observation/result packages called OBX segments. An OBX segment represents the smallest indivisible unit of a report or message. It is used to transmit a single observation or observation fragment. OBX segments contain a header that qualifies the subsequent data fields. In data structure terms, each line in a message is a segment. Each segment contains data of a certain type. There are over 100 segment types, for example:

• A line that begins with EVN means that is contains data about the type of message; for example, A04 would mean “Register a patient.”

• A line that begins with MSH means it's a segment that contains data about the Sender and Receiver of the message that would include the type of the message and a time stamp, among other data pieces.

• PID contains patient demographic data (name, id codes, address…)

• PV1 contains data about the patient's hospital stay (assigned location, referring doctor…)

Each of the fields in the segment line is called composite. A composite is a certain attribute of that segment. A segment may be made up of several composites. In other words Messages are made up of Segments which are made up of Composites. A message may have many segments and a segment may have many composites. See, now you know way more about HL7 than the average man on the street!

Enough about all the grim details of what the messages look like. A couple of minutes spent googling HL7 and you'll find enough information to keep any techno-geek busy for weeks! For example, the PID segment alone can contain 30 composites!

An HL7 template is a data structure that is based on the HL7 Reference Information Model (defined above). It identifies the data content needed in a specific clinical or administrative domain.

A template is a set blueprint for messages by which multiple OBX segments may be put together to express chosen observations. Some observations are fairly simple in nature like blood pressure. The template would have segments to list the expected observations like systolic, diastolic, mean, alarm limits, method, etc. More complicated diagnostic procedures may involve hundreds of related OBX segments. Templates provide a way of combining OBX segments needed to send the total observation set of information.

In addition to templates, part of the HL7 mandate is to also define a vocabulary for the data within templates, messages, and segments. Like any glossary or dictionary it attempts to create consensus on the definition or meaning of the different data being shared. I remember as an adolescent I had a 1966 Chevy Caprice. It had hood locks and cherry bomb mufflers. It sounded and looked pretty cool. We went to a part of town where we didn't normally hang out and met a cousin of a friend of mine that lived in that neighborhood. He said I had a bad car. I thought, what do you mean, it's a nice car, I take care of it. My friend knew his cousin's vocabulary and explained that “bad” meant “good” in this part of town. He said, he means that it's a b-a-d car. So in this way HL7's Vocabulary Technical Committee organizes and maintains definitions of the terms used in messages to share proper meaning. By the way, I hope that my friend's cousin isn't an MD now, I can just hear him saying, “You've got a b-a-d looking x-ray there buddy!”

HL7 is a huge undertaking and continues to grow. We talked about certain main themes of the spec that I've found interesting and thought you might too. You can always find additional information—especially from the HL7 website itself at www.hl7.org or www.altisinc.com/IE/hl7.html.

The main thing to remember is that HL7 is a specification for describing, formatting, encoding, and sharing of clinical and administrative data in healthcare. An easy way to remember that is that the 7 in HL7 refers to the Application layer in the OSI model. The next time someone talks about their HL7 software or application, you'll know that they really mean their HL7 compliant software or application. Then be sure to ask them how many composites are in their OBX segments!