When a clinic decides to connect a lab or pharmacy data feed into a health information exchange, the vendor conversation almost always turns into an acronym fight: HL7 v2 versus FHIR. Both are legitimate, both are in active use, and picking the wrong assumption about which one a partner actually supports is the single most common reason a "simple" interface project runs long. Understanding what each standard actually does — and what federal certification rules require of your vendors — turns that conversation from a guessing game into a short checklist.
Two standards, one goal: getting data into the exchange
HL7 v2 and FHIR both move clinical data between systems, but they were built a generation apart and they behave differently in practice. HL7 v2 is a text-based, message-driven standard that has been the workhorse of healthcare data exchange since the late 1980s; it is still in use across the large majority of U.S. healthcare organizations, particularly for internal, system-to-system messaging like lab orders, lab results, pharmacy orders, and patient admissions. FHIR (Fast Healthcare Interoperability Resources), developed by HL7 International, is the newer, web-based alternative — a RESTful API standard that organizes data into modular resources such as Patient, Observation, and Medication, exchanged as JSON or XML. For a practice connecting a lab or pharmacy feed, the practical question is not "which standard is better" but "which standard does this specific interface actually run on, and does my side support it."
HL7 v2: still carrying most lab and pharmacy traffic
HL7 v2 uses a message-based architecture: structured, pipe-delimited segments organized around a specific clinical event. A lab result, for example, typically arrives as an ORU (Observation Result) message with segments for the message header, patient identification, and the actual test values. This structure is mature, compact, and fast to parse, which is why it remains deeply entrenched for high-volume, point-to-point connections between a lab, a pharmacy system, and an EHR. Its weakness is exactly the flip side of its strength: because HL7 v2 implementations are flexible by design, no two vendors build them quite the same way, and connecting a new lab or pharmacy partner usually means custom mapping work done by an integration engine or middleware layer rather than a simple plug-and-play API call.
FHIR: the API-first standard federal rules are pushing toward
FHIR takes a different approach. Instead of discrete point-to-point messages, it exposes data through a REST API that authorized applications can query directly — a one-to-many pattern well suited to patient portals, mobile apps, and modern app-to-app integrations. For e-prescribing specifically, FHIR APIs are increasingly used to move prescription data and medication or allergy history between prescribers and dispensers, though FHIR does not yet cover every e-prescribing function on its own; many e-prescribing workflows still rely on the NCPDP SCRIPT standard to fill the gaps. On the regulatory side, the ONC Health IT Certification Program — now administered under the Assistant Secretary for Technology Policy (ASTP) — requires certified health IT to expose patient data through APIs using the HL7 FHIR standard and the FHIR US Core Implementation Guide, a requirement that traces back to the 21st Century Cures Act’s information-blocking and interoperability provisions. ASTP/ONC’s 2024 Federal FHIR Action Plan reinforced that direction. In practice, this means most certified EHR vendors are already wired to expose FHIR endpoints, even if their internal lab and pharmacy messaging still runs on HL7 v2 behind the scenes. The transition is real, but it is a "reasonable glidepath," not an overnight cutover — HL7 v2 is not going away soon.
HL7 v2 vs. FHIR at a glance
| Dimension | HL7 v2 | FHIR |
|---|---|---|
| Format | Pipe-delimited text messages | JSON or XML resources over REST APIs |
| Typical use today | Internal lab/pharmacy/ADT messaging, point-to-point | Patient access, app integration, newer e-prescribing workflows |
| Lab result example | ORU (Observation Result) message | Observation resource queried via API |
| Setup pattern | Custom interface build, often via middleware | Standardized endpoint, still needs authorization/scope setup |
| Federal certification tie-in | Not the certified API requirement | Required for ONC/ASTP certified health IT patient-access APIs |
| Known gap | Inconsistent implementations across vendors | E-prescribing sometimes still needs NCPDP SCRIPT alongside it |
Questions to ask before you sign the interface agreement
Most onboarding delays trace back to one of these questions never getting asked up front:
- Which HL7 v2 message types do you support for lab results and pharmacy orders, and which FHIR versions (R4, R5) do you support for the same data?
- If both standards are involved, do you use an interface engine to translate between HL7 v2 and FHIR, and who owns that mapping when something breaks?
- Are your FHIR APIs certified under the ONC Health IT Certification Program, including the US Core Implementation Guide?
- For e-prescribing, do you support NCPDP SCRIPT in addition to FHIR, or only one of the two?
- Is there a separate fee for FHIR API access, and is it billed differently from the HL7 v2 interface?
- Do you already have a built interface with this specific lab, pharmacy, or exchange, or will this be a custom build?
- What is the realistic timeline for testing and go-live, and what does your support model look like once the feed is live?
None of these questions require the practice to become an interoperability expert. They require the vendor to be specific instead of reassuring. A vendor who cannot answer which message types or FHIR versions they support is telling a practice something important about how the rest of the project will go.
Why this distinction matters for onboarding
Onboarding a lab or pharmacy feed into an exchange is fundamentally a matching problem: a clinic’s system has to speak the same language, on the same standard version, as the lab, pharmacy, or exchange endpoint on the other side. Getting that match right the first time — rather than discovering mid-build that one side assumed FHIR and the other assumed HL7 v2 — is what separates a routine interface project from one that stalls for months. A neutral connector that understands both standards, and asks these questions before a contract is signed, is doing the practical work of interoperability, not just the paperwork of it.