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.
HL7 CDA
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 FHIR
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.
