Complete Guide to HL7 Standards

HL7 provides a framework that helps govern how electronic health information is retrieved, shared, exchanged and integrated. The standards define how patient information is structured, packaged and communicated between disparate parties and also sets the data types, structure, and language needed for seamless integration between electronic health systems. We’ve put together this guide to provide an in-depth overview of HL7 standards, from the history of HL7 through implementation challenges and more. Specifically, we’ll discuss:

• The History of HL7
• HL7 Aims and Objectives
• HL7 Implementation Challenges
• Fast Healthcare Interoperability Resources (FHIR)
• Solving HL7 Integration Challenges
• Additional Resources on HL7 Standards

The History of HL7

Many patients believe that electronic medical record (EMR), hospital information system (HIS), lab information system (LIS), radiology information system (RIS), and other healthcare solutions inherently communicate with each other. They expect that their medical information and history can be sent easily from one healthcare provider to the next. However, the reality is quite different.

A little over two decades ago, there was little need for clinical apps and solutions to exchange data. However, the national push for a centralized electronic health record and the explosion in the number of clinical applications drove the need for a common language to streamline the exchange of information between electronic health applications. With the rise in the number of digital solutions in the healthcare industry, the ability to seamlessly share clinical data across systems was not only desirable, but it also became essential.

In response to this need, an international community of information scientists and healthcare subject matter experts came together to form HL7 International and solve the challenges of integrating, managing and exchanging electronic healthcareinformation.

Founded in 1987 and accredited by the American National Standards Institute (ANSI) in 1994, HL7 International is a non-profit organization with members in over 50 countries. It develops Health Level 7 standards that define and provide formats for data exchange, rules syntax, decision support, and common definitions for health data in personal health record (PHR) claims attachments, electronic health records, clinical genomics, product labels for prescription medications, and quality reporting.

The HL7 committee created a framework through which health information could be exchanged by compiling a collection of messaging formats and related clinical standards, thus loosely defining the ideal representation of health/clinical information. In theory, healthcare organizations that use applications leveraging the HL7 messaging standard can communicate and exchange patient data with each other — even if the applications speak quite different languages.

Since 1987, there has been widespread use of the HL7 standard on a global scale — a standard that is constantly reviewed and modified to meet the ever-evolving data needs of the healthcare industry. The evolution of HL7 standards continues to improve workflows throughout the healthcare industry, thus facilitating increased efficiency and accuracy of healthcare providers and enabling the delivery of quality care and better outcomes to consumers.

HL7 Aims and Objectives

Each healthcare setting is unique, with differences in clinical processes, software systems in use, database structures, how data is collected, stored and used, payment structures, among others. This means that healthcare organizations (hospitals, acupuncture centers, podiatrist offices, outpatient surgery centers, imaging centers, clinical labs, etc.) have unique requirements and processes for interacting with patients and data.

Created and maintained by Health Level Seven International, the prime objective of HL7 is to simplify the implementation of interfaces between various vendors and healthcare software applications, in a bid to reduce the cost and time involved in custom interface programming.

Before the creation of HL7, healthcare IT systems performed data exchanges via customized interfacing systems that were built through a great deal of programming effort by vendors of both receiving and sending applications. Since there were no standard data formats for collecting and storing patient data, the cost of building such interfaces was prohibitive, and most hospitals (in the 1980s) had only a few such interfaces.

The major challenge of interfacing arose from the fact that software vendors and hospital IT teams collaborated to build new clinical applications that were designed to enable in-house clinical processes, workflows, and data formats used in the provider’s setting. As such, applications were custom-built for a particular healthcare setting with zero input from other application development teams and no conformance with healthcare solutions built by other vendors.

The task of HL7 within this healthcare ecosystem (where users, clinical processes, and settings differ) is to establish a single global standard for the representation and movement of clinical data. The standards do not dictate to software vendors, providers, and other stakeholders in the healthcare industry how to present data or build applications. They are intended to serve as a guide and framework where independent health IT systems can communicate with each other via an agreed-upon ANSI standard.

In essence, the HL7 standard is the preeminent basis of data exchange in healthcare settings. It is a broad messaging standard (with more than 80 message types) designed to solve the data exchange challenges in the healthcare industry by accommodating the needs of both stand-alone healthcare providers and clinics as well as large-scale hospital networks.

HL7 is supported by over 4,000 members, and over 90 percent of the largest health information system vendors in the U.S. are HL7 members. HL7 standards are primarily used by:

• Clinical interface specialists tasked with migrating clinical data between healthcare providers or applications. They are experts who build tools to migrate clinical data or design applications that would need to exchange or share data with other systems.
• Medical informaticists working in the health informatics field. This field concerns itself with how clinical knowledge is created and the logic of healthcare workflows. Typically, these specialists attempt to create clinical ontology — designing workflows and crafting terminology that forms a hierarchical framework of healthcare knowledge.
• Healthcare application vendors who must implement integration for their products to be viable in the healthcare marketplace. Clinicians simply don’t have the time necessary for duplicating data across multiple systems, logging in and out of several applications to access or document data, and other time-consuming tasks. Applications must fit into clinicians’ workflows, and that means integration is a must.

HL7 Implementation Challenges

One of the major challenges facing increased HL7 adoption is its flexibility. While the HL7 community designed the standard to be flexible and easy to adopt, thus enabling the “network effect” and driving immediate, significant benefits and cost savings for adopters, this very flexibility can make interfacing a distinctly challenging task.

HL7 is sometimes referred to as the “non-standard standard” because nearly every healthcare organization implements the framework in a unique way. This is due to the absence of a standard clinical or business process for interacting with clinical data, patients, or relevant personnel.

Aside from the fact that HL7 allows healthcare environments to utilize different aspects and versions of the standard, each new version of HL7 comes with new options and features. Let’s take a look at some of the major HL7 standards.

HL7 Version 2

HL7’s Version 2.x (V2) is the most widely used messaging standard for exchanging clinical and patient care information.  Basically, it’s a database query language that healthcare providers can use to send messages containing or requesting health data.

HL7 version 3

HL7 v3 is more powerful than its predecessor and based on model-driven methodology built to better support conformance testing and streamline implementation planning. While HL7 v2 was meant to facilitate clinical communications (like patient registration, medical orders, etc.), HL7 v3 comes with additional capabilities for informaticists and support for government reporting requirements.

However, it’s still evolving and not backward-compatible with previous versions of HL7. Also, healthcare organizations may find it difficult to move to the new standard since such migrations will be expensive and they are just beginning to enjoy the benefits of implementing HL7 v2. It’s likely that most organizations and vendors will continue to use the more familiar v2 protocol.

EHR-PHR System Functional Models

EHR-PHR System Functional Models provide common language parameters for developing electronic health record system and their underlying components. PHR System Functional Models are draft standards for functions to be used in a Personal Health Record (PHR), helping to facilitate data exchange between EHRs and PHRs.

Clinical Document Architecture (CDA)

This is an ISO-approved standard that establishes an exchange model for clinical documents such as progress notes and discharge summaries. Along with the CDA is the Consolidated CDA (C-CDA) — used in ONC meaningful use-certified EHR systems to consolidate former CDA templates into one document and the CCD (Continuity of Care Document) — a record of patient admission and discharge among separate facilities.

Fast Healthcare Interoperability Resources (FHIR)

FHIR is an interoperability specification developed by HL7 that makes it easier and faster to develop interoperable healthcare applications. It is a draft standard that describes elements, data formats, and a modern, web-based application programming interface that developers can use to build tools for sending, receiving, and accessing electronic health records. 

While FHIR is built around previous data format standards like HL7 version 3.x and HL7 version 2.x, it’s far easier to implement because it uses a modern suite of web-based API technology, including Atom for results, a choice of RDF, XML, or JSON for data representation, HTML and CSS for user interface integration, and a HTTP-based RESTful protocol.

This allows healthcare systems to make web/REST requests that poll data rather than the traditional HL7 push data model. In the traditional push model, a source system sends information to the destination system as new information becomes available or as data is deemed potentially useful for the destination. The destination system receives the data, and then must maintain and index that data, meaning the source system places trust in the destination to maintain security and appropriate access controls. The push data method requires multiple workflows for a single HL7 transaction.

FHIR supports both pushing and polling data:

• REST APIs can be used in both a push and poll fashion.
• Message events are defined for both push and poll.
• Services can be designed to support either push or poll.

In a polling data model, the source system is responsible for maintaining and indexing data and also maintains security and access controls. The destination system, which may have its own security and access controls, retrieves data from the source system as needed. In essence, FHIR is a web-based, next-gen, scalable standards framework that is supported by current exchange infrastructure.

Objectives of FHIR

One of the major goals of FHIR is to enable easier interoperation between healthcare systems, enabling third-party application developers to build medical apps that can easily integrate with existing systems. Easier interoperation also enables health care providers and clinicians to access healthcare information from their device of choice — cell phones, tablets, or computers.

Since FHIR is implemented on top of the HTTPS (HTTP Secure) protocol and HL7, messages can be parsed by wire data analytics platforms — making real-time data gathering possible. As messages pass over the network, healthcare organizations can collect data from specific segments in FHIR messages. Some use cases for this capability include adverse drug interaction warnings, prescription drug fraud, epidemic tracking, etc.

Backward Compatibility

Earlier this year, HL7 International released a new version of the FHIR standard. Like previous versions, Release 4 allows health data to travel in discrete pieces while facilitating additional stability for several elements in the standard. Furthermore, it promises to be backward-compatible so that products being developed with the standard will be compatible with future updates.

As a result, developers are becoming more confident in leveraging FHIR since they are sure that the tools and solutions they build will still work when the next FHIR version is released. Also, more and more vendors of health IT systems are also considering including FHIR data repositories in their Enterprise Data Warehouse strategy (EDW).

Solving HL7 Integration Challenges

Since HL7 allows for extensive customization, there are many adaptations and significant variance in the way HL7 interface standards are implemented. Applications and healthcare solutions often use different HL7 formats, and there is no set standard for how the data is handled or how these systems are implemented.

The substantial variations in HL7 implementation slows down development cycles and makes integration both costly and time-consuming. Significant resources must be dedicated to integration development, leaving fewer resources to handle improvements to functionality and features.

Also, different code base and integration points must be maintained for each EHR and adding or replacing interfaces can potentially impact the entire system — requiring extensive modifications to endpoints.

Fortunately, healthcare organizations and software vendors can solve HL7 integration challenges by implementing a robust API solution.

While interface engines are the typical solution to HL7 integration problems, they introduce unnecessary security risks, slow down implementation, do not provide real-time data access and are not EHR-agnostic. API solutions like Integrate facilitate the seamless exchange of health information across disparate EHR platforms and clinical and administrative applications. Integrate comes with a robust set of REST APIs that write and read to EHRs through vendor-supported software modules, thus standardizing EHR integration through a unified data model and universal, real-time APIs. Real-time access to patients’ medical records and other clinical data without compromising PHI security enables healthcare organizations to reduce time-consuming manual tasks such as copying and faxing patient records, obtaining necessary patient data, and entering duplicate data across multiple applications. And, with API solutions like Integrate, you only need to code the application once to connect to any EHR, significantly reducing lengthy, costly integration projects.

For decades now, HL7’s interoperability standards have been the de-facto international protocol for exchanging clinical and administrative and clinical healthcare data, and traditional HL7 isn’t going anywhere anytime soon. It has helped to improve healthcare delivery by optimizing workflows, reducing ambiguity, and enhancing knowledge transfer between vendors, patients, standards organizations, government agencies, and healthcare providers as well as reducing ambiguity and optimizing workflows.

Continued adoption of HL7 will pave the way for vendors to create better tools for transferring electronic health information. This will serve to increase efficiency, improve clinical workflows, increase quality of care, and ultimately ensure better outcomes for all. With the emergence of new legislation and HIPAA guidelines, more interest in the regional health information organization model, and a greater number of healthcare providers leveraging innovative technologies to facilitate clinical workflows, standardizing — or making progress towards standardization — will be of great value in the healthcare community, facilitating increasingly open clinical data exchange.

Additional Resources on HL7 Standards

For more information on HL7 standards, FHIR, and the evolution of healthcare data exchange, visit the following resources:

• The evolution of HL7 Standards: V2 to FHIR
• How SMART on FHIR Grew Vendor Support for Interoperable HIT Apps
• Evolution of Health Level-7: A Survey
• Fundamental Principles of FHIR
• Business Archetypes and Archetype Patterns from the HL7 RIM and openEHR RM Perspectives: Towards Interoperability and Evolution of Healthcare Models and Software Systems
• Considering a CRM? It Might Be Time to Catch Up on HL7 Standards
• HL7 Standards Could Open Health IT Infrastructure to Cyberattacks
• Unmasking the HL7 Data Standard
• Interoperability: The FHIR standard is not a panacea
• FHIR Standards Continue to Shape Health IT’s Interoperability Progression
• HL7 releases new FHIR standard, but don’t expect true interoperability
• FHIR May Not Help Healthcare Orgs Achieve Semantic Interoperability