Free access
Research Article
1 Sep 2006

What is Health Level 7?

In this issue, IT World looks into HL7 (Health Level 7). We'll discuss what HL7 is and what it is not. We'll also talk about some of the major aspects of HL7 during our attempt to define it. There's a lot to talk about so let's get right to it.

What is HL7?

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.
Check Points
Health Level 7 is a standard for information exchange between medical applications.
✓ It is designed to ensure that the meaning of the data gets across.
✓ HL7 specifies the describing, formatting, encoding, and sharing of clinical and administrative data in healthcare.
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).

HL7 and the OSI Model

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.
Table 1. The ISO OSI Reference Model
Rather than attempting to create your own messaging system between two network domains, use a standard method of communication.
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

Why use HL7?

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.
Upgrades and Updates
There is a difference between upgrades and updates. An upgrade to a software package or application usually means that there are added features. While each company that creates software applications may have their own revision tracking system, generally an upgrade would be reflected in a change in the version level. For example, moving from version 1.0 to 2.0 would indicate an upgrade.
On the other hand, an update usually means that there are patches, fixes, or new pieces of software programming that resolve a fundamental problem that surfaced in the current revision level. While we hope that each manufacturer would have some kind of rigorous means for testing their software, it is difficult to predict actual use and sequence of key strokes (for example) that might be made. In other words, glitches are common. Updates to a particular revision might look like this: moving from 1.0 to 1.1. Another update would bump it up to 1.2 and so on.
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!

Message > Segments > Composites

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…)
HL7 Version 2.4
Each version of the HL7 spec has a structure like that listed below. This list represented HL7 version 2.4. Each upgrade adds sections, for example sections 13, 14, and 15 were not part of version 2.3, they were added in 2.4.
Introduction: Overview of HL7.
Control: Message Definitions, Interchange Protocols.
Patient Administration: Admit, Discharge, Transfer, and Demographics.
Order Entry: Orders for Clinical Services and Observations, Pharmacy, Dietary, and Supplies.
Query: Rules applying to queries and to their responses.
Financial Management: Patient Accounting and Charges.
Observation Reporting: Observation Report Messages.
Master Files: Health Care Application Master Files.
Medical Records/Information Management: Document Management Services and Resources.
Scheduling: Appointment Scheduling and Resources.
Patient Referral: Primary Care Referral Messages.
Patient Care: Problem-Oriented Records.
Laboratory Automation: Equipment status, specimen status, equipment inventory, equipment comment, equipment response, equipment notification, equipment test code settings, equipment logs/service.
Application Management: Application control-level requests, transmission of application management information.
Personnel Management: Professional affiliations, educational details, language detail, practitioner organization unit, practitioner detail, staff identification.
Appendix A—Data Definition Tables: All HL7 and User-defined tables and their values.
Appendix B—Lower Layer Protocols: Protocols for lower layer of OSI model.
Appendix C—BNF Message Descriptions: BNF representations of abstract message definitions at the segment level.
Appendix D—Glossary: Glossary of terms.
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 or
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!

Information & Authors


Published In

cover image Biomedical Instrumentation & Technology
Volume 40Number 5
Pages: 375 - 379
PubMed: 17078369




Jeff Kabachinski, MCNE, MS-T, is manager of workplace learning and performance for GE Healthcare located in Waukesha, WI. He holds MCNE certification, an MSc in training and development from Leicester University, and a BS in engineering technology from the Milwaukee School of Engineering. E-mail: [email protected].

Metrics & Citations


Article Usage

Total views and downloads: 141


Export citation

Select the citation format you wish to export for this article or chapter.

Citing Literature

  • An ETL-process design for incremental loading German real-world data based on FHIR and OMOP CDM: Algorithm Development and Validation (Preprint), JMIR Medical Informatics, 10.2196/47310, (2023).
  • An ETL-process design for data harmonization to participate in international research with German real-world data based on FHIR and OMOP CDM, International Journal of Medical Informatics, 10.1016/j.ijmedinf.2022.104925, 169, (104925), (2023).
  • Clinical decision support in the neonatal ICU, Seminars in Fetal and Neonatal Medicine, 10.1016/j.siny.2022.101332, 27, 5, (101332), (2022).
  • Linking clinotypes to phenotypes and genotypes from laboratory test results in comprehensive physical exams, BMC Medical Informatics and Decision Making, 10.1186/s12911-021-01387-z, 21, S3, (2021).
  • Logic-Based Formalization of System Requirements for Integrated Clinical Environments, Automated Reasoning for Systems Biology and Medicine, 10.1007/978-3-030-17297-8_8, (215-242), (2019).
  • Applying time-constraint access control of personal health record in cloud computing, Enterprise Information Systems, 10.1080/17517575.2018.1522452, 14, 2, (266-281), (2018).
  • Perspectives on Big Data applications of health information, Current Opinion in Systems Biology, 10.1016/j.coisb.2017.04.012, 3, (36-42), (2017).
  • Modeling communication network requirements for an integrated clinical environment in the Prototype Verification System, 2016 IEEE Symposium on Computers and Communication (ISCC), 10.1109/ISCC.2016.7543728, (135-140), (2016).
  • A healthcare management system for Turkey based on a service-oriented architecture, Informatics for Health and Social Care, 10.3109/17538157.2012.710689, 38, 3, (246-264), (2012).
  • Data Support for Electronic Medicines Management, Principles of Electronic Prescribing, 10.1007/978-1-4471-4045-0_5, (97-115), (2012).

View Options

View options


View PDF

Buy or Subscribe

Any member discount will be applied at checkout.

View our Individual and Enterprise packages and learn more about the advantages of the AAMI eSubscription.







Copy the content Link

Share with email

Email a colleague

Share on social media

This site uses cookies. By continuing to use our website, you are agreeing to our privacy policy.