FHIR vs HL7 v2: Which to Use
Use FHIR for new, API-first products — patient apps, SMART on FHIR launches, and any system that reads or writes discrete data over REST. Keep HL7 v2 where it already runs: real-time clinical messaging inside hospitals (ADT, orders, results) that existing interface engines handle reliably. Most production systems run both — FHIR at the edges for apps and partners, HL7 v2 in the core for high-volume event flows — with a facade translating between them.
Quick answer
New app or external integration → FHIR. Existing in-hospital messaging → HL7 v2. Real systems run both behind a translation layer.
Decision table at a glance
| 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 they are
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.
Key differences
Interaction model
FHIR is request/response over HTTP — you GET a Patient or POST an Observation, with search parameters and paging built in. HL7 v2 is fire-and-forget event messaging: a source system emits an ADT^A01 when a patient is admitted and downstream systems react. Pulling data on demand is natural in FHIR and clumsy in HL7 v2.
Cost & time to market
For new work, FHIR is usually cheaper: JSON, REST, and OAuth are skills web teams already have, and vendor sandboxes let you build without a hospital in the loop. HL7 v2 work carries interface-engine licensing (or Mirth ops), specialist contractors, and per-interface build/test cycles that add up quickly across a large estate.
Coverage & maturity
HL7 v2 wins on incumbency — nearly every hospital system speaks it, and message types are battle-tested. FHIR coverage is excellent for common resources and patient-access scenarios but can be thin or vendor-specific at the edges (write operations, niche data). Check the specific EHR's FHIR capability statement before assuming parity.
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 to use each
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.
Migration: running FHIR and HL7 v2 together
The pragmatic path is rarely "rip out HL7 v2." Instead, stand up a FHIR facade in front of existing feeds: an interface engine or integration layer consumes HL7 v2 messages, maps them to FHIR resources, and exposes a clean REST API to apps and partners — while the hospital core keeps humming on v2.
Prioritize by consumer. New apps and external integrations get FHIR from day one. Internal, high-volume clinical messaging stays on v2 until there's a concrete reason to move it. Map v2 segments to FHIR profiles incrementally, resource by resource, and validate against US Core so the output is portable rather than another bespoke interface.
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.