FHIR vs HL7 v2
Use FHIR for new, API-first products such as patient apps, SMART on FHIR launches and REST integrations. Keep HL7 v2 for real-time clinical messaging inside hospitals (ADT, orders, results). Most production systems run both, with a FHIR facade translating between them.
What is the difference between FHIR and HL7 v2?
Quick answer
FHIR and HL7 v2 are both HL7 International standards, but they move data differently. HL7 v2 sends event messages, such as admissions and lab results, between systems inside a hospital. FHIR exposes discrete resources over RESTful APIs for apps, partners and patients. Most organizations run both: HL7 v2 in the core and FHIR at the edges.
| Criterion | FHIR | HL7 v2 |
|---|---|---|
| Architecture | RESTful API, discrete resources | Event messages over TCP/MLLP |
| Data format | JSON / XML | Pipe-delimited segments (ER7) |
| Best for | Apps, external partners, patient access | In-hospital real-time clinical feeds |
| Tooling maturity | Growing, modern, vendor dev programs | Mature, ubiquitous interface engines |
| Learning curve | Familiar to web/API developers | Requires HL7 v2 / interface-engine expertise |
| Regulatory fit (US) | Required for patient access / USCDI | Legacy, not the compliance target |
| Query support | Rich search & filtering built in | Query/response is limited and awkward |
What are FHIR and HL7 v2?
What is FHIR
FHIR (Fast Healthcare Interoperability Resources) is HL7's modern standard built on RESTful APIs, JSON/XML, and discrete, individually-addressable "resources" (Patient, Observation, MedicationRequest). It's what powers patient-access APIs, SMART on FHIR apps, and vendor developer programs like Epic and Oracle Health.
What is HL7 v2
HL7 v2 is the decades-old pipe-and-hat messaging standard that still carries most real-time clinical traffic inside hospitals: admissions/transfers (ADT), orders (ORM), and results (ORU). It runs over interface engines (Mirth, Rhapsody, Cloverleaf) and is deeply embedded in existing hospital infrastructure.
FHIR vs HL7 v2 pros and cons
Interaction model
FHIR is request and response over HTTP: you GET a Patient or POST an Observation, with search and paging built in. HL7 v2 is event messaging: a source system emits an ADT^A01 on admission and downstream systems react. On-demand pulls suit FHIR far better.
Cost & time to market
FHIR is usually cheaper for new work, because JSON, REST and OAuth are skills web teams already have, and vendor sandboxes let you build without a hospital. HL7 v2 work adds interface-engine licensing or Mirth operations, specialist contractors and per-interface test cycles.
Coverage & maturity
HL7 v2 wins on incumbency: nearly every hospital system speaks it, and its message types are proven. FHIR coverage is strong for common resources and patient access but can be thin at the edges, such as write operations. Check each EHR's FHIR capability statement first.
Control vs standardization
FHIR profiles (US Core, IPS) push you toward standardized, portable data. HL7 v2's flexibility, Z-segments and site-specific customizations, gives control but means every interface is a little different, which is exactly what makes large HL7 v2 estates expensive to maintain.
When should you choose FHIR or HL7 v2?
When to use FHIR
- You're building a new patient- or clinician-facing app that reads/writes discrete data.
- You need to integrate with 3+ EHRs and want vendor-supported, documented APIs.
- You're launching a SMART on FHIR app inside an EHR (OAuth scopes, standardized launch).
- You're meeting US regulatory drivers: patient access, USCDI, CMS interoperability rules.
When to use HL7 v2
- You're interfacing with existing hospital systems that already speak HL7 v2.
- You need high-throughput, real-time event messaging (lab results, ADT feeds).
- The receiving system has no FHIR endpoint and adding one isn't feasible.
- You're extending an established interface-engine estate rather than greenfield building.
When do you need both HL7 v2 and FHIR?
You need both HL7 v2 and FHIR once one workflow stays inside the hospital and another faces apps, patients or payers. ADT feeds, lab orders and results, and scheduling messages usually stay on HL7 v2. Claims and remittance use a third standard, X12.
FHIR is named by rule for outside access: 45 CFR 170.215 adopts FHIR R4.0.1 and US Core for certified health IT, and CMS-0057-F adds Provider Access and Prior Authorization APIs from January 1, 2027. The practical path is a FHIR facade over HL7 v2 feeds.
Which sources does this comparison rely on?
- HL7 FHIR is a standard published by HL7 International for exchanging health data through RESTful APIs built on defined resources such as Patient and Observation (HL7 FHIR, hl7.org)
- ONC certification criterion 45 CFR 170.315(g)(10) requires certified health IT to offer a standardized API for patient and population services (eCFR)
- 45 CFR 170.215 adopts HL7 FHIR Release 4.0.1 as the API base standard for certified health IT, with US Core and SMART App Launch as implementation specifications (eCFR)
- Beginning January 1, 2027, Medicare Advantage organizations must implement a Provider Access API and a Payer-to-Payer API built on those FHIR standards (42 CFR 422.121, eCFR)
- Beginning January 1, 2027, Medicare Advantage organizations must also implement a Prior Authorization API (42 CFR 422.122, eCFR)
Frequently Asked Questions
Not sure which fits your build?
Tell us about your product, integration targets, and timeline. We'll map the trade-offs to your context and recommend the path that gets you to a compliant launch fastest.