If you run or support a laboratory, you have almost certainly heard the terms HL7 and FHIR — often used interchangeably, sometimes as if one replaces the other. They are related but not the same, and understanding the difference matters because it shapes how your lab exchanges orders and results with electronic health records, public health agencies, and partner systems. This guide explains both standards in plain English and why most modern labs end up supporting both.
The short version
- HL7 v2 is the long-established messaging standard behind most lab order and result exchange (ORM, ORU, ELR).
- FHIR is a newer, web-API-based standard from HL7 that uses structured “resources” and modern REST patterns.
- Neither fully replaces the other today — HL7 v2 dominates installed integrations, while FHIR is growing fast, partly driven by regulation.
- An interface engine lets a lab speak both, translating between formats as needed.
First, clear up the naming
“HL7” can mean two things. Health Level Seven International (HL7) is the standards organization. It is also shorthand for HL7 version 2(HL7 v2), the messaging standard most people mean when they say “we send HL7.” FHIR — Fast Healthcare Interoperability Resources — is a newer standard alsocreated by HL7. So FHIR is not a competitor to HL7 the organization; it is HL7's modern approach to interoperability.
What is HL7 v2?
HL7 v2 is a messaging standard that has been in production use for decades. It defines structured text messages with segments and fields, delimited by pipes and other characters. For laboratories, three message types come up constantly:
- ORM (Order Message) — communicates a laboratory order to the lab. (In newer HL7 v2 releases this role is often handled by OML messages, but many integrations still use ORM.)
- ORU (Observation Result) — carries results back to the ordering system or EHR.
- ELR (Electronic Laboratory Reporting) — reporting of reportable conditions to public health agencies.
HL7 v2's strength is ubiquity — almost every EHR, LIS, and instrument middleware speaks it. Its weakness is that it is comparatively rigid and message-oriented, and it was not designed for modern web and mobile application patterns.
What is FHIR?
FHIR models healthcare information as resources — discrete, structured objects like Patient, Observation, DiagnosticReport, ServiceRequest, and Specimen — exchanged using modern web technology: RESTful APIs, standard HTTP methods, and formats like JSON and XML. That design makes FHIR well-suited to on-demand access and app-style integration. For lab data, ServiceRequest often represents the order, Specimen the sample, Observation the individual results, and DiagnosticReport the assembled report. A modern patient and provider portal typically leans on FHIR-style access patterns.
| Aspect | HL7 v2 | FHIR |
|---|---|---|
| Format | Delimited text messages | Resources in JSON or XML |
| Exchange style | Message-based (push) | Web API (REST), on-demand |
| Typical lab use | ORM/OML orders, ORU results, ELR | App & portal access, modern APIs |
| Maturity in the field | Extremely widespread | Growing rapidly |
| Best at | Established system-to-system flow | App ecosystems, on-demand access |
When is each used?
In practice, the two coexist. HL7 v2 remains the backbone of routine order and result exchange between labs, EHRs, and instruments, and for public health ELR. FHIR is increasingly used where modern APIs make sense: patient-facing portals, third-party apps, and newer integrations. U.S. interoperability rules stemming from the 21st Century Cures Act, and related certification requirements, have promoted standardized API access to health data and named FHIR as a foundation for that access. The direction of travel is toward more FHIR — but this has not eliminated the vast installed base of HL7 v2 integrations, which continue to do essential work.
Why labs usually need both
Because your trading partners are at different stages. A large reference partner might expect HL7 v2 ORU results, while a newer digital-health client wants FHIR API access, and a public health agency requires ELR. This is where an interface engine earns its keep: it sits between systems and translates — receiving an order in one format, mapping it to your LIS, and returning results in whatever format each partner needs. Labrynix approaches this with a dedicated connectivity layer — see Labrynix Connect — designed to support both message-based and API-based interoperability. A few practical considerations:
- Map to real-world partner behavior, not just the spec. Implementations vary; conformance testing with each partner matters.
- Plan for both push and pull. Result delivery and on-demand API access are different patterns.
- Keep security central. Whatever the format, exchanged data must be protected — review your platform's security posture.
- Avoid lock-in to a single standard. Your connectivity should evolve as FHIR adoption grows without discarding working HL7 v2 interfaces.
HL7 v2 and FHIR are not rivals so much as two generations of the same mission. Most laboratories will support both for years to come, and the right integration layer — part of a broader interoperability platform — is what makes speaking both languages practical rather than painful.
Frequently asked questions
Is FHIR replacing HL7 v2?
Not in the near term. FHIR adoption is growing quickly, especially for patient access and app integrations driven by interoperability regulation, but HL7 v2 still carries the majority of established order and result exchange. Most labs operate both for the foreseeable future.
What is the difference between ORM and ORU messages?
ORM (Order Message) communicates a lab order to the laboratory, while ORU (Observation Result) returns the results. In newer HL7 v2 releases, ordering is often handled by OML messages, but the order-then-result pattern is the same.
Do I need an interface engine?
If you connect to more than a couple of partners or need to support both HL7 v2 and FHIR, an interface engine or integration layer greatly simplifies translation, routing, and per-partner configuration so your core lab system stays stable.