FHIR and HL7 v2 solve different problems. HL7 v2 remains the workhorse for event-driven clinical messaging inside an enterprise, such as admissions, orders, and results, while FHIR is the right choice for request-response access by applications, patients, payers, and partners. Most production environments run both, and the real decision is which workflow each standard owns and who operates it.
Two different shapes of problem
HL7 v2 is a messaging standard built around clinical events. When a patient is admitted, an order is placed, or a result is finalized, a message is pushed to subscribing systems through an interface engine. FHIR is a resource-based API standard built around requests: an application asks for a patient's medications, a payer requests a member's clinical data, a research system queries for candidates matching criteria.
Choosing between them is rarely an either-or. Ask which side initiates, whether the consumer needs a push or a pull, how much latency the workflow tolerates, and what your trading partners can actually support today.
Decision criteria that matter in practice
Five criteria settle most of these debates without a standards argument.
- Initiation: event-driven notification favors HL7 v2; consumer-driven access favors FHIR.
- Partner capability: an interface engine and ADT feed may be available in weeks; a partner FHIR endpoint may not exist at all.
- Data scope: narrow, well-defined message content favors v2; broad, evolving data needs favor FHIR resources and profiles.
- Regulatory pull: CMS API obligations and patient-facing access are FHIR-based, so those roadmaps should not be built on v2.
- Operations: who monitors, alerts, and fixes it at 2 a.m. matters more than which standard is more modern.
Legacy is not a temporary condition
Any plan that assumes v2 and document exchange disappear will miss its dates. National survey data shows that in 2025, 40% of hospitals still often sent summary-of-care records by mail or fax, even as network-based methods grew steadily from 2018 onward, with 55% often sending and 59% often receiving through EHR vendor-based networks. Modernization succeeds when new FHIR services are added alongside a well-run v2 estate, with a clear map of which workflow each path serves.
A coexistence pattern
A common target state keeps v2 for intra-enterprise clinical events, adds FHIR for external and application-facing access, and places a normalization layer between them so that mappings, terminology, and identity resolution are defined once. That pattern lets you retire individual interfaces on their own schedule instead of demanding a single cutover.
How BlockInterop supports this work
- FHIR and API Implementation consulting and implementation — Design and implement FHIR-based APIs, SMART on FHIR applications, US Core-aligned workflows, and scalable integration services.
- HL7 Interface Development consulting and implementation — Build, optimize, test, and support HL7 v2 interfaces across complex clinical and enterprise environments.
Sources
Every figure cited in this article links to its public source. BlockInterop publishes no client names, outcomes, or internal performance statistics.