Continue reading for answers to commonly asked questions about HL7 and its impact on interoperability in healthcare. Use the table of contents below to jump ahead to any question.
Topics covered in this article:
What is HL7?
As an organization that develops international healthcare standards, HL7 creates rules and guidelines for the exchange of patient data between health IT systems. Established in 1987 and based in Ann Arbor, Michigan, HL7 is accredited by the American National Standards Institute. Its members include providers, payers, and other industry stakeholders from more than 50 countries.
Why “Level Seven”?
In 1984, the International Organization for Standardization (ISO) — the world’s largest developer of technical, industrial, and commercial standards — created a conceptual model for Open Systems Interconnection (OSI) to describe the communication functions of any computer system. Intended to provide a framework for interoperability between devices, the OSI model defines seven “layers” of computer network architecture. The “Level Seven” in HL7 refers to OSI’s application layer, which includes the computer interface responsible for communicating directly with end-user applications like web browsers and software programs.
How does HL7 support interoperability in healthcare?
The standards developed by HL7 spell out the language, structure, and data types needed for communication to occur between health IT systems. ISO suggests thinking of a standard as a “formula that describes the best way of doing something”. When a clinician at one organization shares patient data from their electronic health record (EHR) with a clinician at another facility using a different EHR, this exchange is possible only because the data is formatted and organized using commonly understood semantic standards.
There are currently about a dozen HL7 standards, but the most widely implemented is Version 2 (V2), an inter-system messaging standard supported by every major medical IT vendor in the United States and used by 95 percent of US healthcare organizations.
Another HL7 standard, Fast Healthcare Interoperability Resources (FHIR), has also become a critical part of interoperability since it was introduced in 2014. In July 2021, the Centers for Medicare & Medicaid Services (CMS) made FHIR-based Patient Access APIs — or application program interfaces — mandatory for organizations that participate in its programs. These APIs function as the layer between an application like an EHR and the web server that manages the foundational level of information exchange between providers.
To learn more about FHIR, check out this companion 101-style article that answers some common FAQs and covers how FHIR is helping solve healthcare’s interoperability problem.
What are HL7 messages?
When multiple systems supporting V2 “talk” to one another, they do so automatically via HL7 messages. These messages are created using ASCII (American Standard Code for Information Interchange), a code where the numbers 0-127 represent 128 different English language characters. Another popular HL7 standard, Consolidated-Clinical Document Architecture (C-CDA), relies on XML (Extensible Markup Language) for encoding. C-CDA allows clinicians to create and send digital documents containing patient information to other providers who may need that information.
What are some use cases for HL7?
Using systems that conform to HL7 standards, healthcare organizations can easily share patient histories, lab results, and other information across EHRs and between other systems from a wide range of vendors. If a provider orders a lab test, for example, they can simply enter that information in their EHR, and it will go to the appropriate laboratory information system for processing. When a patient comes to a hospital for X-rays, data about that patient can be transmitted between its picture archiving and communication system in radiology and the billing system used at the front desk.
What’s next for HL7?
Described by HL7 as a “next generation standards framework,” FHIR is seen by most in the industry as easier to implement than V2 because it relies on web-based technologies and APIs that are familiar to almost any developer. With the CMS regulations taking effect, many believe that it won’t be long before FHIR-based APIs become healthcare’s IT standard of choice.
