A surprising amount of wasted effort in healthcare integration comes from a single framing error: treating FHIR and HL7v2 as old-versus-new, with a migration in between. They're not generations of the same thing. They were designed for different jobs, and in most real environments you'll run both for the foreseeable future.
They solve different problems
HL7v2 is a messaging standard: event-driven notifications flowing between systems inside (and between) hospitals. A patient is admitted → an ADT message fires. A lab result is ready → an ORU message. It's been the backbone of hospital integration since the 1990s, and it is everywhere.
FHIR is a resource-based API standard: RESTful, web-native, built for querying and exchanging discrete data (a Patient, an Observation, a MedicationRequest) on demand. It's how modern apps, patient access, and cross-organization exchange increasingly work.
What HL7v2 is still better at
- Real-time, event-driven workflows inside a hospital (ADT, orders, results, scheduling)
- Talking to the installed base — most hospital systems speak v2 fluently and may not expose FHIR for what you need
- High-volume, fire-and-forget messaging with mature tooling (interface engines like Mirth)
What FHIR is better at
- On-demand queries: "give me this patient's active medications"
- Patient- and consumer-facing apps (SMART on FHIR, patient access APIs)
- Cross-organization and regulatory exchange (USCDI, CMS rules, TEFCA-era flows)
- Discrete, structured data you can reason about — versus parsing pipe-delimited segments
When to use HL7v2
Reach for v2 when the integration is an event happening inside the hospital and the systems on both ends already speak it: admissions feeds, order entry, results routing, scheduling. Rebuilding these on FHIR just because it's newer adds risk for no benefit when the v2 interface already works and is battle-tested.
When to use FHIR
Reach for FHIR when you're building something new that queries data, faces a patient or external app, or has to satisfy a modern regulatory requirement. Anything consumer-facing, anything crossing an organizational boundary, anything where you want structured resources rather than messages — that's FHIR's lane.
The both-at-once reality
The architecture we ship most often: HL7v2 interfaces feeding an internal pipeline (often through an interface engine), normalized into FHIR resources that the rest of the system — apps, analytics, external APIs — consumes. v2 at the edges where the installed base lives; FHIR in the core and at the modern surfaces. The two coexist by design, not as a half-finished migration.
A mapping gotcha
Translating v2 to FHIR is not field-for-field. v2's loose, locally-customized segments (every site uses Z-segments differently) don't map cleanly to FHIR's stricter resources. The hard part isn't the transport — it's reconciling local v2 conventions, vocabularies, and missing data into conformant FHIR. Budget for that reconciliation; it's where v2-to-FHIR projects actually spend their time.
If you're choosing a standard for a specific interface and want a sanity check, send us the data flow — we run the conformance suites (Touchstone, Inferno) and have shipped both standards across 60+ integrations.