Janury 22, 2007
HL7 101: A Beginner’s Guide
Is HL7 Greek to you? Then get to know the messaging standard whose goal is to connect healthcare organizations that speak different “languages.”
In more than 100 nations, written language is based on the same 26-letter alphabet we are familiar with in North America. The words in many of these Indo-European languages are drawn from a set of core ancient languages (Latin, Greek, etc). The sentence construction rules, word spellings, and related details are related yet different. For example, mother in English has a straightforward translation into Spanish (madre), German (mutter), French (mère), and Dutch (moeder). All are close, but none are the same.
Accordingly, without some type of translation between languages, a person who speaks only English would not be able to communicate with a person who speaks only German, Spanish, or French. Two hundred years ago, when travel and commerce between countries were limited, communication between users of different languages was not as important as it is today.
The same is true for healthcare applications. Fifteen years ago, there was typically little need for clinical applications to exchange data; today, the need for applications to share clinical data is critical. The explosion in the number of clinical applications and the national push for a centralized electronic health record are only two factors driving the requirement for a common language between applications.
Health Level 7 (HL7) is a large part of the solution. Applications used by healthcare organizations that have adopted the HL7 messaging standard can communicate with one another—even when they speak different languages.
The evolution of HL7 is improving workflow throughout the healthcare industry, and as technology continues to improve, so too will the quality, accuracy, and efficiency of healthcare providers.
Healthcare Is Unique
Multiply the uniqueness of each healthcare setting by the number of countries or political settings where care will be delivered. The result is almost an infinite number of unique requirements that—like English, Spanish, and German—are close in terms of their needs but not exactly the same.
It is in this hazardous arena where “all care settings and users of clinical systems are different” that HL7 attempts to establish a single, flexible, worldwide standard for the representation/movement of clinical data.
What Is HL7?
Patients may believe a radiology information system (RIS), lab information system (LIS), hospital information system (HIS), and electronic medical record (EMR) inherently communicate with one another seamlessly. Furthermore, they may expect information to be sent freely between a hospital and external magnetic resonance imaging center or external testing laboratory. However, in many cases, each of these systems speaks its own language.
In 1987, in an attempt to begin solving this problem, an international community of healthcare subject matter experts and information scientists collaborated to create the HL7 standard for the exchange, management, and integration of electronic healthcare information.1
Today, HL7 is a standards developing organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a broad view from healthcare system stakeholders. From a practical standpoint, the HL7 committee has compiled a collection of message formats and related clinical standards that loosely define an ideal presentation of clinical information. Together, the standards provide a framework in which data may be exchanged.
After years of work, the HL7 messaging standard is used worldwide and is still being modified to meet the changing data needs of the healthcare world. This standard does not dictate to hospitals, medical clinics, imaging centers, labs, and software vendors how to build applications or present data. Rather, HL7 was created as a framework for negotiation where an agreed-upon ANSI standard would be used to enable independent systems to communicate with one another. That is, the standard is the basis of data exchange.
The HL7 standard is often called the nonstandard standard. While not entirely fair, it does reflect that almost every hospital, clinic, imaging center, lab, and care facility is “special” and, therefore, there is no such thing as a standard business or clinical model for interacting with patients, clinical data, or related personnel.
Just as programmers utilize the broad capabilities of Java, Visual Basic, C++, and XML to solve their specific needs, HL7 offers a broad messaging standard that can accommodate both large-scale hospital networks and stand-alone diagnostic imaging centers and clinics.
To clear up a common misconception, HL7 is not a software application. The title HL7 conjures images of a packet of compact discs, manuals, and clever icons. This could not be further from the truth. In reality, the HL7 standard is a “book of rules” with thousands of pages of detailed interfacing information that sets forth a framework for negotiation in interfacing, giving programmers and analysts a starting point from which to begin their technical discussions.
What’s in a Name?
1. Physical: Connects the entity to the transmission media
2. Data Link: Provides error control between adjacent nodes
3. Network: Routes the information in the network
4. Transport: Provides end-to-end communication control
5. Session: Handles problems that are not communication issues
6. Presentation: Converts the information
7. Application: Provides different services to the applications
Why Was HL7 Created?
Before HL7, data exchanges between healthcare systems were performed via customized interfacing systems that required a great deal of programming on the part of both the sending and receiving applications. These interfaces were expensive because there was no standard collection of patient attributes or standard set of “interesting events.” As a result, in the 1980s, the number of clinical interfaces in a typical hospital was small and the cost per interface was high.
The primary challenge of interfacing is that as internal hospital teams and software vendors create new clinical applications, each application is developed without input or collaboration with other application development teams. Commercial development teams rarely share proprietary data on how their applications are built, so it is difficult for other teams to build compatible applications.
Who Uses HL7?
1. Clinical interface specialists who are tasked with moving clinical data, creating tools to move such data, or creating clinical applications that need to share or exchange data with other systems. These users are responsible for moving clinical data between applications or healthcare providers.
2. Government or other politically homogeneous entities that are looking to share data across multiple entities or in future data movement. Generally, few legacy systems are present. These users are often looking to move clinical data in a new area not covered by current interfaces and have the ability to adopt or mandate a messaging standard.
3. Medical informatists who work within the field of health informatics, which is the study of the logic of healthcare and how clinical knowledge is created. These users seek to create or adopt a clinical ontology—a sort of hierarchical structure of healthcare knowledge (a data model), terminology (a vocabulary), and workflow (how things get done).
How Was HL7 Created?
Clinical interface specialists in the healthcare industry decided there had to be a better method to interface applications besides large amounts of costly customized coding. A small number of mostly acute care hospitals and software vendors formed a volunteer group to create a more standard way of building interfaces. In retrospect, the group’s goal was to substantially reduce the cost of building interfaces.
Without a standards history to rely on but a drive to eliminate custom interfaces, the group initially defined a loose and largely implied data model of messaging “touch points” between applications. The primary challenges faced by the group were the small number of volunteers and a lack of interest on the part of major application vendors.
The volunteers found that the magnitude of their vision to eliminate custom interfaces and radically reduce the cost of interfacing required predefining only 80% of the interface framework up front. This allows a given facility to address special business, clinical, and workflow rules in the final 20% of the interface.
This 80/20 approach provided a way to define and facilitate the clinical specialization and uniqueness that brings so many benefits to patient care and challenges to IT teams. This practical approach was also critical for the standard’s widespread acceptance.
What Is HL7’s Value?
Consider any of the popular de facto standards in use today: TCP, IP, HTTP, HTML, POP, telnet, Windows, or even the American Standard Code for Information Interchange character set. They are all valuable because the user base has grown to be large, and the standards work in the real world. Similarly, the network effect for HL7 would come if many healthcare applications started using it.
Ultimately, HL7 balanced the points that drove its creation: solve 80% of the clinical interfacing problem in a flexible way using a consensus, volunteer-driven process. The focus was on making the standard easy to adopt so the network effect would occur and create a significant cost savings as quickly as possible.
Complicating matters, each updated version of HL7 introduces new features and options. So not only is each version an “80% standard,” but multiple versions also serve to further enhance and complicate the standard. This, of course, does not mean that there are not solutions to this problem.
Numerous organizations build HL7 interface engines, which serve as a “hub” that both routes and translates data between linked applications. Imagine watching the United Nations general assembly on CSPAN, and you get the idea. Different languages are being spoken, yet understood by each individual because of the translators (interface engines) they are wearing.
The very best interface engines allow for multiple connections to both internal and external applications allowing for an optimal information exchange environment. Although other options, such as point-to-point interfaces, are available, they may be difficult to manage as requirements continue to evolve.
HL7 and the Future
Perhaps soon, a patient’s visit to a clinic or a doctor’s office may go like this: A nurse measures a patient’s weight, which is electronically populated into his or her medical record. The nurse then takes the patient’s blood pressure, and the result is also electronically populated into the medical record. Next, the doctor selects criteria for a lab order, and the lab receives it electronically almost instantly. The lab performs the order and electronically populates the patient’s medical record with the results.
HL7 certainly doesn’t make these types of technological advancements happen, but the adoption and implementation of the HL7 message standard certainly helps make them possible more quickly.
With the emergence of new HIPAA guidelines and legislation, and as more hospitals and clinics consider the regional health information organization model, EMRs improve, and laboratories and diagnostic imaging centers continue to utilize new technologies into their workflow, HL7 will continue to be a critical component in the evolution of healthcare.
— Dave Shaver, chief technology officer and founder of Corepoint Health, has more than 20 years of experience in training, consulting, and software development. A recognized Health Level 7 (HL7) expert, he serves on several HL7 special interest groups and regularly speaks on the subject.