HL7, FHIR & Healthcare Interoperability
What HL7 and FHIR are, how they differ, and how lab and EHR systems actually exchange orders and results. A plain-English guide for lab and health-IT teams.
A lab result is only useful where a clinician can see it. Getting it there means one system has to hand structured data to another, correctly, every time, across software written by different vendors in different decades. That handoff is healthcare interoperability, and HL7 and FHIR are the standards that make it possible.
What is HL7?
HL7 (Health Level Seven) is a set of international standards for exchanging clinical and administrative health data between software systems, published by the standards body of the same name. When a physician's EHR sends a lab an order, or the lab sends a result back, that message almost always moves in an HL7 format.
HL7 International calls its Version 2 standard “the workhorse of electronic data exchange in the clinical domain, and arguably the most widely implemented standard for healthcare in the world.” First released in 1987, HL7 v2 defines pipe-delimited messages for specific events: an ORM for an order, an ORU for a result, an ADT for a patient admission or demographic update. It is not elegant, and implementations vary enough that “HL7 compliant” rarely means two systems connect without work. It is, however, everywhere, which is why supporting it is non-negotiable for any lab integration.
What is FHIR?
FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”) is HL7's newer standard, built on the same web technologies that run the rest of the internet: REST APIs, JSON, and modular data objects called resources. Instead of parsing a delimited message, a system requests a resource, a Patient, an Observation, a DiagnosticReport, from an API endpoint, the way a web app requests any other data.
HL7 describes FHIR as combining the best features of its older v2, v3, and CDA standards while leaning on modern web standards and a tight focus on implementability. FHIR Release 4 (2019) introduced the first normative, formally stable content, and Release 5 followed in 2023. For labs, FHIR is the natural choice for new and patient-facing integrations, while HL7 v2 remains the reality for most existing hospital and EHR connections.
HL7 v2 vs FHIR
Both are HL7 standards solving the same problem in different eras.
| HL7 v2 | FHIR | |
|---|---|---|
| Format | Pipe-delimited text messages | REST API with JSON or XML resources |
| Model | Event messages (ORM, ORU, ADT) | Modular resources (Patient, Observation, DiagnosticReport) |
| Style | Push a message when an event happens | Request or subscribe to data over an API |
| Best for | Existing hospital and EHR interfaces | New integrations, apps, patient-facing access |
| Reality | Carries most clinical data today | Where regulation and new builds are heading |
The practical answer for a lab is rarely one or the other. It is both: FHIR where you can, HL7 v2 where you must, and a translation layer between systems that speak different versions of “standard.”
SMART on FHIR, published by HL7 as the SMART App Launch Implementation Guide, sits on top of FHIR: it lets a third-party app launch inside an EHR and read or write data through FHIR APIs using OAuth 2.0 authorization, without a custom integration for every EHR vendor.
Interoperability is not one thing
HIMSS defines four levels. Most integration problems are really a failure at one specific level.
Foundational
One system can securely send data to another, and the second can receive it. Connectivity, with no requirement that the receiver interpret the data.
Structural
The data arrives in a defined format, syntax, and organization, down to the field level, so the receiving system can parse it without guessing.
Semantic
Both systems attach the same meaning to the data through common models and standardized codes and vocabularies, such as LOINC for lab tests.
Organizational
Governance, policy, and legal and workflow considerations let the exchange actually happen across organizations, with consent and trust in place.
Most “we have an interface but the data is useless” complaints are semantic failures: the message arrived and parsed, but a test coded one way on the sending side maps to nothing on the receiving side. Coding results in LOINC is what closes that gap.
Interoperability stopped being optional
Under the ONC Cures Act Final Rule, certified health IT must support a standardized FHIR-based API, built on FHIR Release 4 and the US Core Implementation Guide, and must make available the data in the United States Core Data for Interoperability (USCDI). The rule also prohibits information blocking, practices that interfere with the access, exchange, or use of electronic health information.
The upshot is concrete: results need to reach the ordering clinician's EHR in a standard format, coded so they are interpretable, without manual re-keying. That is an HL7 and FHIR problem, and building or maintaining those interfaces is specialized work.
DS2 builds the interfaces, in the standard that fits
DS2 does not sell an interoperability platform; it builds and runs the interfaces that connect a lab to the systems around it. The integration team supports the full range: HL7 v2 for existing hospital and EHR and EMR connections (ORM, ORU, ADT, SIU, with custom Z-segment mapping for the non-standard implementations that are the norm), FHIR R4 for modern and patient-facing integrations, and custom REST APIs with OAuth 2.0 where a system needs something bespoke.
With more than 1,000 laboratory integrations built, the team has usually connected the platforms a given lab depends on before. The interface is one layer; DS2 also builds the collection kits and moves specimens by temperature-controlled courier, so the data connection and the physical sample are handled by one accountable partner.
HL7 and FHIR questions
What is HL7?
HL7 (Health Level Seven) is a set of international standards for exchanging clinical and administrative data between healthcare software systems, published by the HL7 standards organization. Lab orders and results between an EHR and a laboratory almost always move in an HL7 format.
What is the difference between HL7 and FHIR?
Both are HL7 standards. HL7 v2 is the older pipe-delimited messaging standard (ORM orders, ORU results, ADT admissions) that still carries most clinical data exchange. FHIR is the modern standard built on REST APIs, JSON, and modular resources, designed to be easier to implement and used for new and patient-facing integrations. Most labs need both.
What is FHIR used for?
FHIR is used to exchange healthcare data over web APIs, so a system can request a specific resource (a patient, an observation, a diagnostic report) rather than parse a message. It underpins patient-facing apps, modern EHR integrations, and the standardized API that US certified health IT must now offer.
What is SMART on FHIR?
SMART on FHIR, published by HL7 as the SMART App Launch Implementation Guide, is an open specification that lets third-party apps launch inside an EHR and access data through FHIR APIs using OAuth 2.0 authorization, without a custom integration per EHR vendor. It is the standard way to add an app to a clinician's EHR workflow.
What are the levels of interoperability in healthcare?
HIMSS defines four: foundational (one system can send, another can receive), structural (the data has a defined format the receiver can parse), semantic (both systems share meaning through vocabularies like LOINC), and organizational (governance and policy let exchange happen across organizations). Most real-world integration failures are semantic.
Does a lab have to support HL7 or FHIR?
In practice, yes. Exchanging orders and results with EHRs relies on HL7 v2 and, increasingly, FHIR. The ONC Cures Act Final Rule now requires certified health IT to support a standardized FHIR-based API (FHIR Release 4 with the US Core Implementation Guide) and prohibits information blocking, so a lab that cannot exchange data cleanly falls out of step with its referring providers and the rules.
References
- 1.HL7 International, HL7 Version 2 Product Suite: "the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world."
- 2.HL7 FHIR (Fast Healthcare Interoperability Resources), overview and current release (R5 / v5.0.0, 2023; R4 introduced the first normative content in 2019).
- 3.HL7 SMART App Launch Implementation Guide (SMART on FHIR): OAuth 2.0-based app authorization for FHIR data systems.
- 4.HIMSS, Interoperability in Healthcare: the four levels (foundational, structural, semantic, organizational).
- 5.ONC/ASTP (HealthIT.gov), §170.315(g)(10) Standardized API for Patient and Population Services: FHIR Release 4 + US Core Implementation Guide + USCDI.
- 6.Regenstrief Institute / NLM, LOINC: universal standard for identifying laboratory observations.
Ready to Simplify Your Diagnostic Workflow? Let's Talk.
No commitment required. Our team responds within 24 hours.