HL7

What is HL7?

Why is HL7 used in healthcare?

Historically, communication between different types of software that is used by different organizations has always been challenging. The same goes for healthcare.

Interoperability

Different kinds of healthcare systems use different applications that were programmed in different languages and that provide different functionality. For example, hospitals use complex, customized systems while general practitioners usually use out-of-the-box practice management software. Medical research institutes may use software that is part of a larger network like a university. Often, these types of institutions need to exchange data about patients.  

The goal of HL7 is to enable healthcare organizations to create uniform data that anyone with authorization can retrieve and use in their own systems. Interoperability between healthcare organizations necessitates that interfaces between different systems use a common protocol like HL7.

Automated workflows

Implementing an electronic health records (EHR) system is costly. HL7 helps to optimize the way data is exchanged between applications and devices and it suggests ways to automate standard workflows, which reduces operational and labor costs.

Global standard

HL7 is an internationally accepted industry standard for data exchange in healthcare. It is also platform independent and technology independent.

Customizable

HL7 has been called a nonstandard standard because the framework allows some customization, for example the use of optional fields and the ability to add message segments.

Healthcare organizations build and use disparate applications according to their unique requirements. HL7 allows developers to create interfaces for data exchange between different healthcare organizations instead of making changes to their software.

Public health collaboration

HL7 enables the sharing of public health information. HL7 has the potential to be used in times of national health crises, like the COVID-19 pandemic, to foster collaboration between government institutions and private healthcare companies and to share medical research data globally.

What do the HL7 standards cover?

Categories

HL7 standards are grouped into reference categories called sections.

Section 1 defines the primary specifications for compliance, integration, and interoperability. Section 1 also describes HL7-supplemental standards like Clinical Document Architecture (CDA), Electronic Health Records (EHR), Fast Health Interop Resources (FHIR), Arden Syntax, and Clinical Context Management Specification (CCOW).

Section 2 describes document standards and messaging protocols for clinical specialties.

Section 3 provides implementation guides and use cases for existing standards.

Section 4 includes guidelines for software and standards development, technical specifications, and programming structures.

A specification for a procedure or an event may include material drawn from different HL7 sections. For example, a common procedure in healthcare is the continuity of care. The specification for the continuity of care standard consists of a clinical document architecture standard (section 1), a clinical and administrative domains document (section 2), and a standards implementation guide (section 3).

Versions

There are several versions of HL7. 2.x versions are the most commonly used versions. The latest HL7 version is HL7 FHIR.

HL7 version 2.x

HL7 version 2.x supports data variations by allowing optional fields and additional message segments. All HL7 2.x versions are backwards compatible.

HL7 version 3

HL7 version 3 was developed as a complete redefinition of the original HL7 standard and aimed to be more consistent and formally structured. HL7 version 3 added more functionality to HL7 version 2.x, including tools for conformance testing and implementation planning. HL7 version 3 has not been widely adopted because it is not backwards compatible with HL7 version 2.x.

HL7 FHIR

HL7 FHIR implements functionality from versions 2.x and 3 and leverages the use of web services. The original HL7 standards are not configured to work well with nonclinical applications like mobile devices. FHIR-based APIs allow HL7 messages to be exchanged with nonclinical applications.

FHIR allows medical personnel to use mobile devices to communicate with key medical services remotely from virtually anywhere. FHIR allows patients to use personal devices to access their personal health records (PHRs) and to interface directly with some medical systems, for example to view their laboratory test results or to book a consultation.   

Products, technologies, and concepts

The main versions of the HL7 framework are supplemented by several other standards that are usually differentiated from the base standard as supplemental products and technologies. These supplemental products and technologies are provided in the form of implementation guidelines for common processes and procedures, supported syntaxes, reference documents, and guidelines for creating standards for specific use cases.

In the future, products and technologies are likely to be identified more uniformly as profiles for specific HL7 use cases.

Examples of supplemental products and technologies include the Continuity of Care Document (CCD), Structured Product Labeling (SPL), Clinical Document Architecture (CDA), Clinical Context Management (CCOW), and Arden Syntax. 

The CCD is an electronic document that summarizes patient information and helps care providers share clinical information. The SPL specification defines the markup syntax to specify the semantics of the information included with medicines. CDA is an XML-based standard for transferring clinical data. CCOW is the standard that allows collaboration between visual applications on clinical workstations. Arden Syntax is a markup language that is used to represent and share medical information.

An electronic health record (EHR) contains all of a patient's health information including status, medications, procedures, and diagnoses. An EHR is generated and controlled by a physician. A PHR is similar to an EHR but is designed to be controlled and managed by a patient.

HL7 messages

Examples

Messages that are exchanged in healthcare systems include information about patient admissions, discharge, and transfer; patient visit and examination scheduling; ordering of procedures; laboratory test results; physician consultations; billing and material inventory; patient referrals; and electronic health record archiving.

Message library

The HL7 framework provides an object type definition (OTD) library, which is a collection of prebuilt message structures. The HL7 message library allows healthcare providers to create interfaces with messaging systems that conform to HL7 standards. HL7 also allows healthcare providers to customize messages by using optional fields and by adding segments to messages.

Message segments

An HL7 message is made up of segments in a defined sequence. Each segment has a three-character identifier called a segment ID. A segment ID describes what information the segment holds, for example message header segment (MSH), patient information (PID), an event type (EVN), or details about a patient’s visit (PV1).

A segment may have multiple parts such as the accident (ACC) segment, which includes fields to describe the accident itself, who was involved, whether the patient died, and when and where the accident took place.

Message types

Every HL7 message must include a message type in the message header. The message type describes what kind of message is being transmitted An example of a message type is DFT, or detailed financial transaction.

Message types are grouped into information categories, for example the DFT message type is in the charges information category.

Each information category contains several trigger codes that describe specific events in that category like A01, which is the trigger code to admit a patient. 

Trigger events

A trigger event is a message that describes an event that took place. Message types are used together with trigger codes to initiate the transmission of a message about an event such as when a patient is admitted to a medical facility. The message header would then include the trigger event ADT-A01.

Transaction sets

HL7 messages are grouped by transaction sets that describe the purpose or type of message in the group.

The core HL7 transaction set is the control transaction set. The control transaction set defines general rules that are applicable to all messages. These rules include data encoding rules, how messages should be described, and how acknowledgement messages should be used.  

The patient administration transaction set manages, among other things, ADT messages.

Other HL7 transaction sets include ones for financial management, queries, procedure orders, observation reporting, visit scheduling, patient referrals, medical records management, patient care, laboratory automation, application management, and personnel management.

The master file transaction set is a collection of reference files that provide information about patient statuses, patient types, lab test definitions, exam codes, locations, doctors, etc. 

Sending messages

HL7 messages are transmitted using HL7 files. An HL7 file has the .hl7 extension and can only be opened with software that supports HL7 files, for example 7Edit, QuickViewHL7, or Chameleon browser.

HL7 does not specify how systems actually store data within an application. However, the standard does specify a data type for message fields. When transmitted, message fields are encoded and transmitted as character strings.

Who uses HL7?

HL7 is used by healthcare organizations such as hospitals, medical imaging centers, doctors, government clinics, laboratories, care homes, pharmacies, medical research institutions, and medical software and hardware vendors.

HL7 is also used at medical facilitates where messages are exchanged between different internal departments like X-ray, pharmacy, physiotherapy, patient administration, human resources, and finance.

HL7 users include IT systems developers, specialist clinical interface developers, medical researchers, and medical organizations that need to share data with other healthcare institutions and users.

What is the HL7 interface?

An HL7 interface consists of an endpoint for the sending application, an endpoint for the receiving application, and a method of transmitting data between the endpoints. TCP/IP is the most commonly used transport protocol for moving HL7 messages between endpoints.

An HL7 interface is sometimes referred to as an interface engine or integration engine but these terms describe slightly different functionality. Point-to-point interfaces allow two endpoints to communicate independently of other endpoints in a system. Interface or integration engines act as intermediaries for all interfaces that are connected to endpoints in a system. 

While HL7 does not provide a plug-and-play interface engine standard, there are commercial and open-source interface engines that support HL7 and that can make the customization and implementation of HL7 interfaces for different endpoints easier.

What is layer 7 in the OSI model?

The HL7 standards focus on layer 7, the application layer, in the Open Systems Interconnection (OSI) model. The OSI model standardizes communication functions in telecommunication and computing systems.

The importance of layer 7 in HL7 is that the application layer is where users interact with an application, namely at the interface. Layer 7 is concerned with how data is exchanged, data security, data availability, access control, and error notifications. APIs are also accessed via layer 7.

What are the downsides of HL7?

HL7 can be difficult to implement between systems that use different versions, for example HL7 version 3 is not backwards compatible with HL7 version 2.x.

HL7 is not a plug-and-play solution and may need some adaptation for different application data models, for example where there is no matching HL7 terminology for vendor-specific technology.

Significant resources may be needed to create and test HL7-compatible interfaces for every endpoint in a healthcare system. Maintaining system interoperability may require frequent test cycles when new endpoints are added.

While the HL7 standard delineates the best way to do things and is touted as a set of rules, there is no legal backlash for not following the rules. This could result in organizations bending the rules to save time and money in the short term to the detriment of other components in the healthcare system in the long term.

Conclusion

HL7 standards do not regulate healthcare system architecture but provide a guide for how clinical information should be structured and shared.

Both the original file-based HL7 standards and the newer XML-based FHIR protocols are designed to automate data exchange, improve workflows for medical transactions and events, and give patients access to their records from their own devices.

Integrating the Healthcare Enterprise (IHE) is an initiative to promote the use of standards like HL7 to help healthcare organizations provide better healthcare more efficiently. IHE is currently working to extend the use of profiles in HL7. An HL7 profile is an out-of-the-box standard designed for a specific use case such as the continuity of care.

It is important for healthcare organizations to monitor the status of clinical interfaces in their environments, for example message errors, network connection status, backlogged message queues, acknowledgement (ACK) statuses, and machine malfunctions. PTRG has a proactive, self-monitoring solution that is designed to keep tabs specifically on HL7-related issues in healthcare environments.