A Brief History of HL7 | Intely

Daniel Pluard

November 30, 2022
IntelyConnect illustration website 5

What is HL7?

HL7 (Health Level Seven) are international standards that define the transfer and communication of clinical, financial, and administrative data between software applications used in healthcare. Health Level Seven International is the international standards organization that produces, maintains, and improves HL7. The standards focus on “layer 7” in the OSI model framework, which is the application layer (for those curious about what ‘Seven’ refers to).

Healthcare providers, payor organizations, and patients use a variety of software and technology applications across the care continuum. The systems are generally isolated and do not form a cohesive technology stack through native integrations. The data collected and produced in one system is not usually available in external systems. Despite the disparate nature of this technology landscape, the solutions provide value to specialties and various healthcare workflows and therefore need an effective way to interface and share data.

Before HL7 was developed, making disparate healthcare systems “talk to each other” was inefficient. Standards for sending, storing, and receiving data must be agreed on and built for each interface. The digitalization of patient medical records made having an integrated EMR system important. Electronic Medical Record systems require communication with external vendor systems for scheduling, billing, reimbursement, and more. With the recent growth of digital health solutions, interoperability standards could not be more critical.

HL7 v2

Healthcare application development requires developers and engineers to create innovative architectures and solutions that solve a business, or in this case, a healthcare problem. The programming behind these systems is unique, but without a common standard for communication, linking these systems is a monstrous task requiring custom work and serious collaboration.

In 1989, a group of technology and healthcare leaders created HL7 with the goal of better supporting hospital workflows. The theory behind the formation was that a standard set of patient attributes and clinical events that healthcare systems can use for their applications would make the systems more generally compatible.

Structure of HL7 v2

HL7 messaging version 2 is a non-XML encoded syntax with segments and delimiters. Segments are identified and begin with a 3-character identifier. Every segment contains a standard set of fields (composites) that are separated by the delimiter and can have sub-fields (sub-composites) with sub-delimiters. A carriage return divides each segment, and a ‘|’ delimiter separates each field. A ‘^’ separates sub-components.

Every message contains an ‘MSH’ segment to start the message, which identifies essential message data such as sending and receiving systems, sending date and time, message type, and version. HL7 v2 has multiple release versions ranging from 2.1 to 2.8 and is backward compatible.

HL7 version 2 messaging is supported by all EMR (Electronic Medical Record) systems in the United States and many systems in use internationally. The general acceptance and support for the standard make it a suitable protocol to connect many systems, especially within a specific organization. HL7 interfaces are in use today. When you hear reference to “HL7”, most likely they are referring to HL7 v2.

Unfortunately, the syntax HL7 v2 uses is challenging in application development. Each message contains many data elements that may not be pertinent to a specific workflow. Since the standard is event-driven, messages are generated frequently and can create unwanted traffic on a particular interface.

HL7 messaging uses Minimum Lower Layer Protocol (MLLP), which relies on Transport Layer Security (TLS) or IPsec when communicating outside a secure network. The HL7 v2 protocol is proficient for connecting applications within a healthcare or hospital system since they are generally on the same network. However, the standard becomes more cumbersome when connecting applications and systems on different networks.

HL7 v3

In the 1990s, the HL7 community released HL7 messaging version 3, intending to support all healthcare workflows. The previous version 2 provides a standard for implementation, but significant localization occurs in messages, making it difficult to support at scale between many systems.

HL7 messaging version 3 attempts to provide a more rigid structure to messages and support interactions, similar to events in HL7 v2. The messages use XML encoding syntax and follow object-oriented principles.

Despite the good intention, HL7 version 3 is a complex standard that the healthcare software and provider community found challenging to implement. There was no backward compatibility with HL7 version 3, which required a complete migration to the new standard. With HL7 version 2 being an integral component of existing healthcare interfaces, the healthcare industry did not adopt HL7 version 3 as the community had hoped.


Clinical Document Architecture (HL7 CDA) is a component of HL7 v3 and defines the standard and format for exchanging clinical documents. Although the broader HL7 v3 standard did not stick due to complexity, CDA was included in Meaningful Use – a federal incentive to promote the adoption of EMR systems in hospitals and healthcare systems.

CDA uses an XML-based markup standard that defines the document exchange’s encoding, structure, and semantics. CDA is supported and in use today and has proven successful for specific use cases where document exchange between systems is required.

The standard does come with challenges. Similarly to the HL7 messaging version 3, the standard, syntax, and implementation are complex. Since CDA supports document exchange, it is only suitable for some interoperability workflows and remains limited in the broader scope of healthcare data communication. CDA secure messaging generally need to be supported by one or more healthcare interfaces.


HL7 International released Fast Healthcare Interoperability Resources (FHIR) as a draft standard in 2014. Over several decades, technology advanced significantly, and the HL7 community wanted a standard to exchange healthcare information that supports modern application design. As technology expands in healthcare, defining a standard that allows interfacing with legacy healthcare systems and supports easy connections to new applications is essential.

The new HL7 FHIR standard draws on previous standards such as HL7 v2 and HL7 v3 and uses HTTP-based RESTful services. FHIR does not rely on document-based standards. Rather FHIR Resources represent data elements in efficient transactional units. Specific resources are accessible through a discrete URL, making it manageable to retrieve, send, or manipulate them through an API request.

Resources are sometimes comparable to HL7 segments from the messaging version 2. However, there is no standard conversion or relationship. Converting healthcare data between HL7 standards is tricky, and FHIR has an entirely different structure than other message types.

FHIR is easier to learn and implement, especially for newer application developers with more web services experience. The standard uses more efficient data structures that are flexible and extensible. FHIR scales well, is cost-effective, and is poised to be the next generation of healthcare interoperability.

In 2019, HL7 International released FHIR Normative Version 4, which will be backward compatible with all future versions of FHIR. New healthcare and digital health applications are cloud-based and employ architectures that support web-service protocols like FHIR well.

Regulatory initiatives from the Center for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health IT (ONC) have released new rules requiring using APIs to allow access to patient information. Standards such as the United States Core Data for Interoperability (USCDI) define data classes and elements that EMR systems must implement for nationwide, interoperable health information exchange.

What’s Next For HL7 FHIR?

Without a doubt, new regulatory initiatives and the momentum of the software community are pushing HL7 FHIR as the next standard. But for FHIR to become the de facto healthcare integration and interoperability standard, two things should occur.

Capabilities need to expand, primarily in event-driven architecture like HL7 v2. HL7 FHIR is excellent for querying or requesting data in an external system and supports better security of PHI. However, real-time data exchange must support subscriptions to certain care events or interactions.

EMR systems will need to implement the FHIR R4 normative standard fully. Interoperability and interfaces are difficult when you connect to multiple systems that may or may not support a given resource and may have different formats. The healthcare industry is taking steps in the right direction to improve interoperability and data exchange. As this trend continues, FHIR R4 will certainly become a more prevalent HL7 interface method.

What is HL7?

HL7 (Health Level Seven) refers to a set of international standards for the transfer and communication of clinical, financial, and administrative data between healthcare software applications. Developed by Health Level Seven International, these standards focus on the application layer (layer 7) of the OSI model, facilitating interoperability among disparate healthcare systems.

Why was HL7 developed?

HL7 was developed to address the inefficiencies in making disparate healthcare systems communicate with each other. Before HL7, custom interfaces had to be built for each system, making integration time-consuming and costly. HL7 standards provide a common framework that simplifies the exchange of data among various healthcare applications.

What is HL7 v2?

HL7 version 2 (v2) is a widely adopted standard for healthcare messaging that uses a non-XML encoded syntax with segments and delimiters to structure data. It supports hospital workflows by defining standard patient attributes and clinical events. Despite its widespread use, HL7 v2 can be challenging for application development due to its complexity and frequent generation of data-heavy messages.

How does HL7 v2 structure its messages?

HL7 v2 messages consist of segments identified by a 3-character identifier, with each segment containing fields (composites) separated by delimiters. Sub-fields (sub-composites) are further divided by sub-delimiters. Each message starts with an ‘MSH’ segment that includes essential information like sending and receiving systems, date and time, message type, and version.

What are the limitations of HL7 v2?

HL7 v2’s limitations include its complex syntax, the inclusion of many non-essential data elements in each message, and the potential for creating unwanted traffic due to its event-driven nature. Additionally, while it works well within secure, localized networks, it can be cumbersome when connecting applications across different networks.

What is HL7 v3?

HL7 version 3 (v3) is an attempt to provide a more rigid structure and support for all healthcare workflows using XML encoding and object-oriented principles. However, due to its complexity and lack of backward compatibility with v2, HL7 v3 has not been widely adopted in the healthcare industry.

What is HL7 CDA?

Clinical Document Architecture (CDA) is a component of HL7 v3 that defines the standard for exchanging clinical documents using an XML-based markup. Despite the broader HL7 v3 standard’s lack of adoption, CDA has been successful in specific use cases, such as document exchange in compliance with federal initiatives like Meaningful Use.

What is HL7 FHIR?

Fast Healthcare Interoperability Resources (FHIR) is a modern standard released by HL7 International in 2014, designed to support the exchange of healthcare information using HTTP-based RESTful services. FHIR uses discrete data elements called resources, making it easier to implement and more efficient than previous HL7 versions. FHIR is gaining traction as the next-generation standard for healthcare interoperability.

What are the benefits of HL7 FHIR?

HL7 FHIR offers several benefits, including ease of learning and implementation, efficient data structures, flexibility, scalability, and cost-effectiveness. FHIR’s use of web-service protocols aligns well with modern cloud-based healthcare applications, making it suitable for both legacy system integration and new application development.

What are the regulatory impacts on HL7 FHIR adoption?

Regulatory initiatives by CMS and ONC are driving the adoption of HL7 FHIR, requiring the use of APIs for patient information access. Standards like the United States Core Data for Interoperability (USCDI) are defining the necessary data elements for nationwide health information exchange, further promoting FHIR as a key standard.

What is the future of HL7 FHIR?

For HL7 FHIR to become the dominant standard, it needs to expand its capabilities, especially in event-driven architecture, and gain full implementation by EMR systems of the FHIR R4 normative standard. As the healthcare industry continues to move toward improved interoperability and data exchange, HL7 FHIR is expected to play a crucial role in this evolution.

Download Your Interoperability Strategy Guide

Not Sure where to start? This 9-page guide helps you build an actionable strategy in 4 proven steps. 

4 Steps to Interoperability Hero

Share This Post

Subscribe to our blog and updates via email

Recent Articles

Resource Guides

White paper

The Realities of Interoperability & Technology Infrastructure in the Healthcare Market

Now more than ever, it is impossible to overstate how critical it is to grasp the impact of interoperability.


White paper

How to Not Fall Victim to the Healthcare Scheduling Trap

You can solve the patient scheduling problems in healthcare with the right toolkit.

Want to learn more?
One of our team members can help.