Operating Standards
What We’ve Learned From HL7
The CIO needs to understand the benefits of HL7 implementation, not how it works internally
By Timothy C. Bailey and Joseph E. Lenahan
In attempting to arrive at the truth, I have applied everywhere for information, but in scarcely an instance have I been able to obtain hospital records fit for any purpose of comparison. If they could be obtained, they would enable us to decide many other questions. They would show subscribers how their money was being spent [and] what amount of good was really being done with it.
Florence Nightingale (“Notes on a Hospital,” 1873) actually uttered this contemporary-sounding statement with an all-too-familiar ring more than a century ago.
The organization and delivery of health care services is and always will be an information-intensive effort. Yet, despite the significant technological advancements of the 20th century, the health care industry still struggles to achieve effective information management.
During the last 20 years, hospitals and other health care institutions have made significant progress in automating their information management functions. Currently, the primary information management goal of most health care institutions is to interface and integrate all information related to the delivery of health care over a patient’s lifetime, and communicate it electronically wherever it is needed. This goal initially focused the industry on the need for standards in health care data integration. Enter Health Level 7 (HL7).
Originally, HL7 was proposed as a voluntary, ad hoc standard to facilitate data transmission and communications in the health care environment. The main objective of HL7 was to provide a uniform medium for exchanging data among health care software applications, while eliminating or substantially reducing custom interface programming and program maintenance. “HL7’s intent is to prepare a complete standard for these interfaces, built on a generic framework that is sufficiently robust to support many other interfaces” (HL7 Version 2.3, April 1997).
Today, HL7 has created a new vocabulary — for example, open systems and hub technology — as well as questions about the ultimate acceptance of a final, common standard by the industry. This article places HL7 in its historical perspective, focuses on the importance of HL7 in contemporary and future health care environments, addresses the question of one eventual standard, and offers health care IT managers and CIOs practical advice in the development of systems and applications within the open systems philosophy.
Historical overview
Prior to establishing standards, institutions were burdened with many homegrown, point-to-point applications existing on large mainframes. By the late 1980s, institutions were faced with adapting to new, network-based, client/server health care applications and had considerable difficulty linking their old point-to-point interfaces with systems outside the mainframe. Interfaces required a tremendous amount of time to build, test and install, and typically required a separate interface for each application, creating a maintenance nightmare.
In the spring of 1987, a conference was sponsored by the Hospital of the University of Pennsylvania. A 12-member group conceptualized and formed the HL7 Working Group. Out of that group came the organizational name and title for:
* an application interfacing standard;
* a coding methodology;
* data structure; and
* procedures designed to ensure that accurate, consistent data could be communicated among disparate computer systems.
HL7 is named for the seventh, or highest layer of the Open Systems Interconnection (OSI) model of the International Standards Organization (ISO). The six lower levels of OSI, the network, hardware and software are used to transmit the data through the network. The HL7 standard assumes that levels one through six of OSI have successfully transported the data from its origin to its destination.
At the data presentation layer, level seven, the software allows for processing of the exchanged data within various applications — medical, financial and others. HL7 has placed an emphasis on the format and definition of the data to be exchanged, the reasons for the data exchange, the timing of the exchange and the communication of certain application-specific errors among applications.
Since 1987, membership within the HL7 Working Group has grown to thousands worldwide and encompasses Austria, Australia, Germany, Holland, Israel, Japan, New Zealand and the United Kingdom. In June 1994, HL7 became an American National Standards Institute (ANSI) accredited standards developing organization. Version 2.2 of HL7 was accepted by ANSI as an accredited standard in 1996.
Anyone interested in the development and promotion of HL7 as the recognized standard can join the HL7 Working Group. Today, many health care professionals volunteer their time to enhance, clarify and promote HL7 standards around the world.
The HL7 committee also works with other standards developers, including the American Society for Testing and Materials (ASTM), Accredited Standards Committee X12N (ASC X12N), American College of Radiology (ACR), National Council for Prescription Drug Programs (NCPDP), International Standards Organization (ISO), Medical Data Interchange Committee (MEDIX), and Institute of Electronics and Electrical Engineers (IEEE). Professionals in these organizations work in committees to further expand and separate data into core fields and sub-fields within these standards, paying particular attention to categorizing data components to their finite definition within the standards.
The coding structure of HL7 was conceived as a simple structure — one that would identify trigger events, messages, segments, fields and sub-fields. All data is displayed as ASCII characters. A set of encoding characters separates messages into segments, segments into fields and fields into sub-fields. These are suggested values only, as stated in the standards manual. Exact encoding characters may be negotiated between communications partners, except that the segment separator, which separates message segments, is the ASCII Carriage Return character.
One uniform standard?
With the diverse business processes that exist in health care delivery networks, the development of one uniform standard cannot be achieved. The HL7 standard makes no assumptions about the architecture of any health care system, nor does it attempt to resolve any architectural differences between them. HL7, as with any computerized language, presents the implementer with negotiable options to facilitate vendor differences within their systems. The difference in the manner in which the HL7 standard is negotiated and implemented at each site prevents HL7 from being a truly plug-and-play interface standard.
Even though HL7 is not a language, it has taken on language-like characteristics. Analysts, programmers, health care personnel and academicians use HL7 terminology in ways that can confuse the technical novice. Regardless of a user’s technical background, if that person understands the standard’s basic concepts, the information that is needed can be easily retrieved.
The most prevalent user of the standard is the interface developer. During early application development, vendors labeled their data fields independently of each other. Under the HL7 standard, vendors and interface developers have embraced the cost and time savings of implementing HL7 interfaces by using a common message format.
The HL7 standards are constantly being modified by the Working Group to fit the ever-changing ways health care does business, and to address changes mandated by regulatory agencies. It would be impossible to develop a standard for health care today that will fit the needs of health care five years from now. For this reason it is safe to say that a final, comprehensive standard cannot be adopted.
Open systems
The concept of open systems plays an important role in today’s business world: banking, manufacturing, health care and government. In an open systems environment, data is shared among users and systems. As new applications or department-specific systems are developed, there is a need to share data. An institution using HL7 standard interfaces is no longer encumbered with a need to select a system that fits the installed hardware.
The institution can shop the market to find the best-of-breed system that fits its needs. The system only needs to be able to send and receive an HL7 set of interface transactions. The system is not immediately compatible with any HL7 interfaces currently installed and minor, negotiated modifications to the interfaces are required. However, the time to complete the interface for the new application is short.
HL7 operation
The HL7 standards manual contains instructions that provide the developer with a blueprint for formatting messages sent to a communications partner. This blueprint is used by the recipient to decipher a message received from a communications partner.
Multiple types of messages and data can be sent and received within the hospital environment. Therefore, a generic vocabulary is needed to describe the types of messages and their data contents. Messages are comprised of segments, and segments are made up of one or more fields. Each segment has a three-character name and represents a certain type of data. Control characters are used to format the message by dividing them into data segments, fields and sub-fields. The triggering event and type, along with the encoding rules are identified in a Message Header. With keys, the receiving system has all the information necessary to interpret the message.
If a situation is not defined by the standard, the provisions within HL7 allow the installer to tailor the interface. Tailoring the standard is done through negotiation with the communication partner to create user-defined segments. The HL7 standard states that if a user modifies the standard and stays within its guidelines, then the user is still abiding by the standard at the application level.
There is incompatibility today between the 2.x versions, because data contained in Version 2.3 is not “truly backward compatible” with preceding versions. This prevents an easy transition from an interface that is 2.3 compatible to an interface that uses Version 2.1. This incompatibility is more pronounced within an interface engine, due to the varying data structures and levels built into the interface engine translation software.
Toward HL7 Version 3.0
An enhanced Version 2.3, to be called Version 2.3.1, is tentatively scheduled for release in the first quarter of 1999. And, at the present time, the much anticipated HL7 version 3.0 is tentatively slated to be put to the ballot in November 1999. (It will be released sometime in the first quarter of 2000.)
It is expected that Version 3.0 will not be directly interoperable with previous versions. Only its developers know the exact reasons for its incompatibility with prior releases. The HL7 Quarterly Newsletters and internal technical notes do not shed any light on the details of the incompatibility. However, this much is known about Version 3.0 differences and enhancements:
* Version 3.0 is perceived by HL7 leadership to be a somewhat radical improvement over the version 2.x series.
* Version 3.0 is based on the IEEE Medix Standard Model.
* Version 3.0 may not be fully backward-compatible with version 2.x implementations. The committees are looking for ways to make it backward-compatible but it appears to be a difficult task.
* Version 3.0 will take the object definition model and run it through a tool that creates a set of message definitions encoded in an XML standard format (with ASM-1). The results will run through another tool that creates the messages. The first tool will probably be a manual process; the second could be an automated process. The ASCII XML format may result in the equivalent of the current HL7 coding. HL7 anticipates that software tools will be developed so automatic messages will be written.
* Version 3.0 is based on a set of prospective scenarios, as opposed to perspective scenarios.
* It is expected that the Implement-ation Guide for Version 3.0 may be something other than a Word document so it will be easier to find answers to implementation questions. The implementer may need to feed the guide a set of parameters; the guide will create a document containing the desired information. The guide might also be published as a database, with tools for queries.
This information was gleaned from “Technical Notes on Implementing HL7,” which was produced after a recent special interest group meeting, and from discussions with HL7 representatives. It is subject to change.
The future
The future of interfacing in an open systems architecture is hub technology, also known as an interface engine. There are numerous name brands to choose from, all providing the same service but with different tool sets. The interface engine enables multiple types of message data to pass through the engine and provides for the message to be separated and reformatted into a different structure for the recipient. Similarly, an interface engine can route the message to one or more receiving systems.
One inbound interface message can be systematically dismantled and sent to multiple systems in other formats. Regardless of HL7 compliance or the fixed message layout, the interface engine addresses end user functionality, whether it is HL7 or a fixed record. This functionality must be considered when reviewing HL7 versions and contemplating HL7’s most pressing question: to upgrade or not to upgrade.
Health care IT managers must start training their employees and developing systems and applications around the open systems architecture — avoiding proprietary system solutions and approaches whenever possible. They must know the systems they have and must also know what data needs to be shared with other systems. Not only must they know what works now, but must also project what will work in the next three to five years (and into the future), as product and application releases continue to enter the market.
As the need for a robust, comprehensive standard grows, vendors and developers still have a consistent health care standard to follow, as they await the future of the HL7 standard.
Mr. Bailey is a systems consultant with Superior Consultant Company, Inc. of Southfield, Mich.
Mr. Lenahan is executive director with Superior Consultant Company.
Both specialize in implementing HL7 standards using a variety of interface engines.
HL7 Discusses Version 3
According to a timeless proverb, “A picture is worth a thousand words.”
HL7 is taking that wisdom to heart with its Version 3 object-oriented message development process. The process is outlined in HL7’s Message Development Framework (MDF), a methodology for linking events, data elements and messages.
Within the MDF, determining the message requirements, analyzing the data and implementing the messages are accomplished by generating four distinct yet integrated models, which are pictorial representations of data and their interaction. The models are the means by which HL7 is building a new and enhanced standard that is definite and testable.
Central to Version 3 is the Reference Information Model (RIM). The RIM is a large pictorial representation object model of the clinical data and the state transitions. This model captures the data that a message or group of related messages will carry. It is a shared model between all domains, and is the model from which all domains must create their messages. Its commonality decreases the domain-specific eccentricities found in the current 2.x series of HL7 messages.
The MDF also calls for the creation of the Interaction Model, which captures information and identifies which application roles need to support the messages. Application roles define how an application interacts with others.
The Interaction Model includes specific trigger events, message formats and data elements that are needed for each application role. This provides a way to test a vendor’s conformity with a particular application role. HL7 plans to certify systems that “pass the test.”
Another benefit of HL7 Version 3 will be an expanded suite of data interchange formats. Until now, HL7 messages supported a single format using ASCII encoding. Version 3 messages will support XML, a restricted form of SGML, and component definitions in ActiveX and CORBA. For users and vendors that focus on electronic health records, the XML interchange model and its ability to represent both clinical documents and data elements will be appealing. Others will favor the transportability of data inherent in the component-based models.
HL7 V3 is slated for initial ballot in the fall of 1999 with the first approved chapters scheduled for release in 2000. A demonstration of Version 3 is planned for the 1999 HIMSS conference and exhibition in February 1999.
— Karen Van Hentenryck, HL7
