Regulation Drove FHIR, Not Operations
Cures Act certification requires FHIR R4 APIs for patient and third-party access. It does not require replacing clinical messaging, so v2 interfaces stayed exactly where they were.
Custom Software
Why HL7 v2 and FHIR Coexist Rather Than One Replacing the Other
Vendors have been announcing the end of HL7 v2 for a decade. It has not happened, and the reason is structural rather than cultural. FHIR is request-response and resource-oriented, built for applications that ask for data. HL7 v2 is event-driven messaging, built for systems that must be told the instant something happens. A lab result posting, an admission, a bed transfer: these are events, and pushing them as messages is a better fit than expecting every downstream system to poll an API. Most healthcare organizations will run both indefinitely, and the integration problem is coexistence rather than replacement.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted Partners
Trusted by Industry Leaders Worldwide
Recognition
Awards & Recognitions
Events Push, APIs Pull
An ADT feed notifies twelve downstream systems within seconds of a registration. Replicating that with FHIR requires subscriptions and infrastructure that most estates have not built or validated.
Installed Base Reality
A mid-size hospital commonly runs dozens to hundreds of v2 interfaces accumulated over years. Each has downstream consumers, error handling, and institutional knowledge attached to it.
Where FHIR Wins Outright
Patient-facing apps, third-party developer access, bulk population export, and cross-organizational query are all far cleaner in FHIR. Forcing those through v2 messaging produces worse systems.
The Real Decision
The question is not which standard to use. It is which workflows belong on each, and where the translation boundary between them sits. That boundary is the architecture.
What Each Standard Is Actually Good At
Choosing correctly requires knowing what each standard was designed to solve. HL7 v2 is a pipe-delimited message format carried over TCP with MLLP framing, with trigger events such as ADT for patient movement, ORM and OML for orders, ORU for results, SIU for scheduling, and DFT for charges. FHIR is a REST API exposing resources as JSON or XML, authorized through OAuth 2.0 and profiled for United States use through US Core. Neither is a superset of the other, and treating FHIR as simply a newer v2 leads directly to bad mappings.
01
HL7 v2 Message Types in Practice
ADT drives patient context, ORU carries results, SIU handles scheduling, DFT posts charges, and MDM manages documents. Segment-level customization between sites is the norm rather than the exception.
02
The Z-Segment Problem
Sites extend v2 with custom Z-segments carrying local data. These have no standard meaning, which is why v2 interfaces are rarely portable between organizations without rework.
03
FHIR Resources and Profiles
FHIR data is modeled as resources such as Patient, Encounter, Observation, and MedicationRequest, constrained by profiles. US Core defines the minimum profiles and interactions expected in United States implementations.
04
Authorization Differs Fundamentally
V2 interfaces trust the network connection. FHIR requires token-based authorization with scoped access, which means every FHIR integration carries an identity and consent design that v2 never needed.
05
Interface Engines Bridge Both
Mirth Connect and comparable engines handle v2 routing and transformation and can also broker REST calls. Our HL7 integration services page covers engine implementation and channel design.
06
Deeper Standards Background
If your team is new to either standard, start with fundamentals rather than architecture. Our healthcare integration guide covers both standards and Mirth Connect from the ground up.
Architecture Patterns for Running v2 and FHIR Together
There are four patterns that actually work in production, and the choice among them is driven by where your source of truth sits and how much latency your consumers tolerate. The failure mode common to all four is unmanaged bidirectional translation, where v2 becomes FHIR becomes v2 again through separate mapping layers that drift apart over time. Pick one direction of authority per data domain and enforce it. Systems that allow both representations to be authoritative eventually disagree, and reconciling that disagreement is far more expensive than designing around it.
Pattern One: FHIR Facade Over v2 Feeds
Ingest v2 messages, persist a normalized store, and expose FHIR APIs over it. Suits organizations needing FHIR access without touching source systems that cannot provide it.
Pattern Two: Event Bridge From v2 to FHIR Subscriptions
Translate incoming v2 events into FHIR resource updates and notify subscribers. Gives modern applications event-driven behavior while source systems continue emitting messages unchanged.
Pattern Three: FHIR-First With v2 Egress
Capture in FHIR, then generate v2 messages for legacy consumers that cannot accept APIs. Common when a new platform must feed established downstream systems.
Pattern Four: Parallel Operation With Defined Boundaries
Clinical messaging stays on v2, patient and third-party access runs on FHIR, and the two meet only at documented touchpoints. Least elegant, frequently the most stable.
Choosing Between Them
Decide by consumer latency tolerance, whether source systems can change, and which domain owns identity. Architecture chosen for standards fashion rather than these constraints tends to be rebuilt.
Mapping HL7 v2 to FHIR Resources Without Losing Meaning
Mapping is where these projects consume their budget. A v2 message and a FHIR resource are different shapes, and the translation involves genuine semantic decisions rather than field copying. HL7 publishes a v2-to-FHIR implementation guide providing segment and field level mapping guidance, which is the right starting point and not a complete answer, because local Z-segments and site conventions are by definition outside it. Budget mapping as analysis work with clinical input, not as development work, because the hard questions are about meaning rather than code.
Segment to Resource Is Not One to One
A single ORU message may produce a DiagnosticReport, several Observation resources, a Specimen, and Provenance. One inbound message routinely becomes a resource bundle.
Identifier Reconciliation Comes First
MRNs, account numbers, visit numbers, and placer order numbers must map to FHIR identifier systems with declared namespaces. Getting this wrong creates duplicate patients that are painful to unwind.
Terminology Is the Long Pole
Local codes must map to LOINC, SNOMED CT, and RxNorm. This work is ongoing rather than one-time, and it belongs in configuration and terminology services, never hardcoded in transformation logic.
Z-Segments Need Explicit Decisions
Each custom segment either maps to an extension, maps to a standard element, or is deliberately dropped. Undocumented handling here is the most common source of silent data loss.
Preserve Provenance and Original Messages
Retain raw v2 alongside derived resources. Audits, mapping corrections, and reprocessing all require the original, and regenerating from FHIR back to v2 is not lossless.
Analytics Consumers Have Different Needs
Warehouse and reporting layers often want flattened extracts rather than resources. Our healthcare data lake architecture post covers serving both from one ingestion pipeline.
FHIR Version Strategy: R4 Now, R6 on the Horizon
Version selection is a compliance question before it is a technical one. FHIR R4 remains the normative baseline referenced by Cures Act certification requirements and CMS mandates, and it is what certified EHRs expose. R5 was published in March 2023 and saw limited vendor adoption. R6 entered ballot in January 2026, with the fourth ballot draft circulating by May 2026 and final publication expected late 2026 or into 2027. No major EHR vendor supports R6 yet, and US Core alignment for R6 is targeted around May 2027 contingent on publication.
Build Against R4 Today
R4 is what regulation requires and what your integration partners expose. Building against anything else for EHR integration means building against endpoints that do not exist.
Skipping R5 Is Usually Correct
R5 makes sense only where you need its subscription framework, a trading partner requires it, or an implementation guide mandates it. Otherwise it adds migration cost without regulatory benefit.
Plan for R6 Structurally, Not Yet Operationally
R6 elevates many resources to normative status, which improves long-term stability. Isolate version-specific serialization behind an internal model so the eventual move is contained.
Version Negotiation Between Partners
Estates connecting to multiple organizations will encounter mixed versions. Handle translation at the boundary rather than allowing multiple versions to propagate into your core model.
API Development Specifics
Server implementation, resource modeling, and SMART on FHIR authorization are covered separately. See our FHIR API development service page for that scope.
Hands-On Developer Reference
Engineers wanting code-level detail on resources, REST operations, and authorization flows should start with our HL7 FHIR integration tutorial, which includes working examples.
How We Scope and Deliver HL7 and FHIR Integration Work
We work only in healthcare, and integration is the majority of what we do. Since 2013 we have completed over 250 healthcare and EHR integrations across more than 200 organizations, including HL7 v2 and Mirth Connect interface work for Coronis Health. That volume matters mainly because it tells us where the schedule risk sits. Vendor onboarding, test environment provisioning, and terminology mapping consistently take longer than interface development itself, and sequencing around them is the difference between a project that lands and one that slips two quarters.
Discovery and Interface Inventory
We catalogue existing interfaces, message types, consumers, and failure handling before proposing architecture. Estates almost always have more live interfaces than documentation reflects.
Focused Integration Build: $40,000 to $80,000
A defined scope covering a small set of interfaces or a single FHIR facade, with mapping, validation, and monitoring. Appropriate for a first project or a contained migration.
Platform Integration: $80,000 to $200,000
Multiple interface families, a normalized data layer, FHIR API exposure, and terminology services. This tier covers most provider organization and digital health platform integration programs.
Enterprise Interoperability: $200,000 and Above
Multi-facility estates, network participation, high availability requirements, and phased v2 to FHIR migration across many systems, with governance and documentation to match.
Ongoing Interface Operations
Interfaces need monitoring, reconciliation, and terminology maintenance after go-live. Silent interface failure is a patient safety concern, so support scope includes alerting and periodic reconciliation reporting.
EHR-Specific Onboarding
Each vendor has its own program, timelines, and scope approval process. Our Epic EHR integration guide covers what to expect on that path specifically.
FAQs
Frequently Asked Questions About HL7 and FHIR Integration
These questions come up in nearly every integration scoping conversation, usually because a stakeholder has been told FHIR makes existing interfaces unnecessary. Answers reflect the standards position as of September 2026, and FHIR versioning in particular is moving, so confirm current ballot and publication status before committing to a version in a contract. If your estate spans multiple EHRs or participates in a national network, the analysis shifts and warrants specific review.
No. FHIR handles API access, patient-facing applications, and bulk export. HL7 v2 remains better suited to real-time clinical event messaging, and most organizations will operate both for the foreseeable future.
R4. It is the normative baseline referenced by Cures Act certification and CMS requirements, and it is what certified EHR vendors actually expose. R6 is still in ballot with no vendor support.
Partially. HL7’s v2-to-FHIR guidance covers standard segments, but local Z-segments, identifier namespaces, and terminology mapping require analysis specific to your site.
Usually yes. Engines handle v2 routing, transformation, retries, and alerting that FHIR APIs do not provide, and most estates still carry substantial v2 traffic requiring exactly that.
A contained facade over existing feeds typically runs three to six months. Multi-system estate migrations run considerably longer, with vendor onboarding and terminology mapping as the main constraints.
Certified health IT must expose FHIR R4 APIs under Cures Act requirements, and network participation frameworks expect FHIR support. Clinical messaging itself carries no equivalent FHIR mandate.
Undocumented Z-segment handling and unmapped local codes, both of which cause silent data loss that surfaces months later during reconciliation rather than at go-live.