HL7 vs FHIR: What's the Difference, and Which Do You Need?

HL7 (Health Level Seven) is the standards organization, and it publishes several standards — HL7 v2 messaging (from the late 1980s, still the backbone of most hospital interfaces) and FHIR (Fast Healthcare Interoperability Resources, HL7's newest standard) among them. So "HL7 vs FHIR" really means HL7 v2 vs. FHIR: an older message-based integration engine pattern versus a modern REST/JSON API pattern.

Neither has fully replaced the other. HL7 v2 still runs the vast majority of real-time clinical event feeds inside hospitals — ADT (admit/discharge/transfer), ORU (lab results), ORM (orders) — while FHIR has become the standard for app-based access to that same data: patient portals, third-party apps, payer data exchange, and anything that needs SMART on FHIR authentication.

HL7 v2 is a message-based protocol: systems push discrete messages (a new lab result, a patient admission) over a persistent connection, typically via an integration engine (Mirth, Rhapsody, Cloverleaf) that routes and transforms messages between systems. It's mature, extremely well-supported by every legacy hospital system, and well-suited to real-time event feeds where you want to be notified the moment something happens.

If you're building an integration to receive live ADT feeds from a hospital, or push lab results into an EHR from a reference lab, HL7 v2 is very likely still the interface the other side expects — even in 2026. Most hospital integration teams have deep HL7 v2 tooling and are not going to stand up a FHIR endpoint just for your project.

FHIR is a REST API standard: resources (Patient, Observation, MedicationRequest, Coverage, and dozens more) are fetched and posted over standard HTTP, authenticated via OAuth 2.0 (SMART on FHIR), and returned as structured JSON. It's the standard EHR vendors expose for app-based integration — patient-facing apps, provider-facing SMART apps embedded in the EHR, and backend system-to-system integrations that need scoped, auditable access to specific resources.

If you're building a patient-facing app, a provider-facing app that needs to launch from inside Epic or Oracle Health, or a backend service that needs read access to specific clinical data without standing up a full HL7 interface engine, FHIR is almost always the better fit — and increasingly the only option, since US federal interoperability rules (ONC's 21st Century Cures Act API requirements) mandate FHIR-based patient access APIs from certified EHRs.

It's rare to find a healthcare organization of any size running only HL7 v2 or only FHIR. Hospital systems typically keep HL7 v2 interfaces for internal, real-time clinical event routing (that infrastructure works and replacing it has no clear ROI), while adding FHIR endpoints for anything that needs to be exposed to external apps, patients, or payers. The two standards solve different problems and are frequently bridged by integration engines that speak both.

We design integration layers around what the source or target system actually exposes, not around a standard we'd prefer to use. In practice that means building HL7 v2 listeners/senders where a hospital's interface engine expects them, and FHIR clients where an EHR vendor's API is the only supported access path — sometimes both, in the same project, feeding a common internal data model so the rest of the application doesn't need to know which wire format the data arrived in.