What Is HL7, Anyway?
What Is HL7, Anyway?
(Editor’s note: A version of this article was originally presented in Perspectives on the Medical Transcription Profession, Summer 1996, published by Health Professions Institute in Modesto, CA.)
Special to ADVANCE
The January 1996 issue of Healthcare Informatics contains 26 references to it. The majority of requests for proposals (RFPs) require it. Marketing materials for transcription software usually imply that their messaging format complies to it.
So what is it, anyway?
It’s HL7, or “Health Level Seven.”
But what is this three-character, alphanumeric acronym, and why is it so important that medical transcription (MT) companies, in particular, learn about it in a proactive, rather than reactive manner?
I can recall feeling a great sense of accomplishment when I found out that HL7 was short for Health Level Seven. Even more impressive, or so I thought at that time, was that I could also enlighten listeners a little further by regurgitating a canned response to the question, “What is HL7?”
My response was that “Health Level Seven refers to the highest level of the communication model of the International Standards Organizations (ISO) for Open Systems Interconnections (OSI), this being the application level.”
In mid-1995, the Medical Transcription Industry Alliance (MTIA) office was contacted by Wayne Tracy of SpaceLabs Medical Inc., Overland Park, KS. Tracy is the co-chair of the HL7 working group on medical records/information management. He strongly recommended that MTIA send a representative to the next HL7 plenary and working group meetings to assist with the development of the first section of the chapter on health information, starting with transcription.
The transcription section was nearing its first balloting, although it had been prepared to that point without input from any organization or individual representing the MT industry. This was a scary thought—that a ballot version of an application protocol for MT would be prepared without the input of the very industry it would most impact.
With the assistance of Tracy and his co-chair, Mary Brandt, MBA, RRA, the American Health Information Management Association’s (AHIMA) director of policy and research, I prepared for my first HL7 working group meeting. On the first full day of meetings, I picked up my registration packet and tried to blend in with the “techies” that packed the lobby. At the end of the registration table, there was a fish bowl filled with small, round, rather plain lapel buttons inscribed with the phrase, “Ask me about HL7.”
At that point in my HL7 education, I was afraid that wearing it might prompt an inquiring mind to actually ask me, “So what is HL7?” I was no longer impressed with my canned response that seemed so complete and totally awesome just a few years before.
After three intensive days of working group meetings, I returned to the MTIA office with a much clearer understanding of the importance of HL7 and, more importantly, why MT companies and the vendors that serve them must arm themselves with knowledge of this health information communications protocol. I felt confident enough to unearth the HL7 button, and I wore it proudly at the MTIA exhibit booth at the 1995 AHIMA Convention in Philadelphia.
By the close of the exhibit, I had spoken to hundreds of people…registered record administrators (RRAs), accredited records technicians (ARTs), chief information officers (CIOs), chief executive officers (CEOs), students and vendors. It was obvious that most seasoned professionals had heard of HL7 or seen it referred to in the literature, but most only recognized the term and were not certain of its meaning or implications.
***
So, let me tell you about HL7.
It all started in March 1987 at a meeting held at the University of Pennsylvania. A group of interested users, vendors and consultants met to discuss how they could work together to develop a cost-effective approach to system connectivity within a particular hospital setting. At that point in time, nearly a decade ago, few departmental systems interfaced with components of a hospital information system. The concept of a single integrated system was just that–a concept.
An ad hoc standards organization seemed the best approach, and it was christened “Health Level Seven” to conform to the seven levels of the OSI reference model. By the fall of 1987, HL7 had prepared its first standard, which defined the format and syntax for messaging between computers within the same health care facility. This was not an operational standard but simply a guide to prepare Version 2.0, which was unveiled in September 1988 and published in 1989. Version 2.0 was a springboard to Version 2.1 published in 1990, which was the first version to actually be implemented widely.
In 1991, HL7 became a member of ANSI and in 1992 became a charter member of ANSI’s Healthcare Informatics Standards Planning Panel (HISPP). By June 1994, HL7 became an ANSI Accredited Standards Developing Organization (SDO), and on Feb. 8, 1996, ANSI approved HL7 Version 2.2 as the official American National Standard. Currently, Version 2.3 has been balloted.
When I did the initial interviews for preparation of this article, I asked Gary Higbie, vice president of technology for Atlanta-based TransQuick Inc., to describe in his words, “What is HL7?”
He explained: “Technically speaking, HL7 is simply a protocol for the exchange of health care information. What does that mean? The history of health care information systems has been that in order to build an interface between different applications (and typically vendors), custom interfaces had to be written with the specifics of the communication protocol and information to be exchanged meticulously designed and agreed upon by the parties involved. HL7 removes the issue of the communication protocol or messaging by creating a standard methodology. This allows the interface designers to focus on the information to be exchanged, theoretically reducing implementation time dramatically and making maintenance and enhancement a much simpler issue.”
Higbie believes there are four pearls of wisdom regarding HL7:
- HL7 is becoming as much a given as the rising sun, so don’t try to hide from it.
- Start educating yourself immediately, and you will be prepared; otherwise, prepare yourself to suffer the business consequences.
- There is a wealth of knowledge and materials available (for free) on the subject; utilize them.
- Although it looks intimidating at first, it really isn’t all that bad, and in the long run it is actually simpler than maintaining multitudes of “one-of-a-kind” interfaces.
Higbie feels, as do most industry watchers, that the trend in health care is toward alliances. He stated, “Hospitals and clinics are merging daily to ensure their own survival financially. This consolidation creates an information systems nightmare, as centralization of information becomes paramount. CIOs faced with “merging” all of these different systems have nearly universally adopted HL7 as their interfacing strategy.”
He also added, “I have not received a single RFP in the last 18 months from a health care alliance that hasn’t required HL7 compliance.”
The “Seventh level” or the “application level” of the ISO-OSI layered protocol model (see accompanying table) supports such functions as:
- Identifying the participants (the MT server is going to send data to the hospital’s data repository);
- Creating availability checks (can the MT server gain access to the hospital’s server for the exchange of information to take place at this time?); and
- Negotiating exchange mechanisms and structuring data exchanges (how and what packets of information will be transmitted and where will they be located in the message?)
To better understand what seems to be a rather complicated process, start with what you already know. Let’s use a common example of a history and physical that has been dictated.
A message goes out to the chart tracking system that the report has been dictated and is awaiting transcription. The dictation is then transcribed, and the chart tracking system is notified that the document exists and requires authentication. In both scenarios an original document notification or T01 event has occurred.
Now, think of the next step in the process. At this point, the content of the document is transmitted along with the notification that these events have taken place. The original document notification has been sent along with the content. This is referred to as a T02 event.
But what if you had to issue a document status change to alter the completion status, the confidentiality status, the availability status or the storage status of that report? This would be a T03 event and would send out the message header, event type, patient ID information, patient visit information and document notification. The message would be acknowledged along with any error information.
A familiar scenario might be that a document has been authenticated. Notification has been sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated. The document content also is transmitted along with the change notification; this would be a T04 event.
For each type of notification or combined notification and content transmission, there is an event denoted by TX, where “X” is a 2-digit number. The message segments contain information specific to a transcribed document but do not include the text of the document. The TXA segments or transcription document header segments specify the sequence (SEQ), the length of the segment (LEN), the data type (DT), whether it is required or option data (R/O), and if it is repeatable (RP/#). The TXA attributes are assigned for each element starting with the document ID, type, content presentation, activity date/time, primary activity provider code/name, origination date/time, etc.
Basically, all the information transcriptionists have placed in the headers of the reports and/or in the document creation screen for the various transcription software packages is neatly ordered and arranged according to the HL7 messaging protocol. When this information is transmitted from one computer system to another using a standard HL7 interface, all the information arrives in a readable format with each segment or packet of information going to the proper location for other systems to record, query and utilize that data appropriately.
The current version of the HL7 standard provides for a variety of document types, content presentation styles (e.g., image data, formatted text, audio data, etc.), completion status, confidentiality status, availability status, storage status, authentication time/date stamp and authenticator ID information, and distributed copies of that document. These are all phrases that the MT industry uses on a daily basis in one way or another. By applying HL7 interfaces, MT companies should be able to reduce the cost of maintaining multiple interfaces and recreating the wheel with each new application.
* About the author: Catherine S. Baxter is the executive director of the Medical Transcription Industry Alliance (MTIA), which is headquartered in Houston. MTIA can be reached via the World Wide Web at http://www.wwma.com/a2/mtia/
