EHR Integration: HL7 v2 vs FHIR R4, Cost, and Timeline
The Question Behind the Question
EHR integration means connecting your product to a hospital’s or clinic’s electronic health record system so patient data, appointments, orders, and results move between them without someone re-typing. For a digital health product, it is usually the single piece of the build that most decides the timeline and the budget, and it works differently depending on whether the data source speaks HL7 v2, FHIR R4, or, as is common, both.
Most guides on this topic are written by providers of electronic health record (EHR) systems and developers of AI tools for managing medical records, and they explain how these systems integrate with one another. We decided to look at it from a different angle. This one is written for the team that has to do the integrating: what HL7 v2 and FHIR actually are, when each one is the answer, what one interface realistically costs to build and to keep running, and the mistakes that turn a six-week integration into a six-month one. It pairs with our guides to telemedicine software development and telemedicine app costs, where EHR integration is one budget line among several. Here it is the whole subject.
What EHR Integration Actually Involves
“Integrate with the EHR” hides four different kinds of work, and scoping starts with knowing which ones you need.
Read-only access pulls data out: a patient’s demographics, medications, allergies, problem list, recent labs. This is the cheapest and most common first integration, and it is what most patient-facing apps and analytics tools need.
Bidirectional sync writes back: a note, an order, a scheduled appointment, a result. Every write needs validation, error handling, and a plan for what happens when the EHR rejects or disagrees with what you sent. This is where cost and risk climb.
Event feeds push data to you as things happen, typically ADT (admit, discharge, transfer) messages over HL7 v2. If your product needs to know the moment a patient is admitted, this is the path, and it usually means an interface engine.
Bulk export moves whole populations at once, over FHIR Bulk Data. Analytics, population health, and payer use cases live here.
A single product frequently needs two or three of these, against two or three different EHR vendors, each with its own quirks. That multiplication is the real shape of the project.
HL7 v2 vs FHIR R4: The Actual Differences
These are not competing standards you choose between. Most real integrations use both, and the useful question is which one each data source speaks.
The mapping between them is the hard part in practice: HL7’s own v2-to-FHIR comparison is explicit that there is no clean one-to-one correspondence between v2 segments and FHIR resources, which is why translation layers carry so much of the effort in mixed environments.
What US Rules Actually Require, Precisely
A lot of content says “FHIR is mandated.” The precise version matters for scoping, so here it is.
The ONC Cures Act Final Rule (May 2020) adopted a certification criterion, 45 CFR 170.315(g)(10), requiring certified health IT to expose a standardized API for patient and population services using HL7 FHIR Release 4, and required certified developers to have those APIs available to customers by December 31, 2022. The mandate falls on the certified EHR developer, which is why Epic, Oracle Health, athenahealth, and the rest expose FHIR R4 endpoints today. It does not require your product to use FHIR; it guarantees that a FHIR R4 read path exists on the EHR side for you to use.
The HTI-1 final rule (December 2023) then moved the baseline data set to USCDI v3, effective January 1, 2026, which changes what data elements those certified APIs have to support. If you are building against a certified EHR in 2026, USCDI v3 is the floor for what you can expect to read.
The practical consequence: read access over FHIR R4 is now the path of least resistance to any certified EHR. Write access, event feeds, and anything outside the certified scope are still negotiated per vendor, and often still travel over HL7 v2.
What EHR Integration Costs to Build and to Run
Published 2026 agency estimates cluster around the same numbers, and it is worth saying plainly that they are a market consensus rather than independent measurements: several vendor guides cite each other for the same ranges. With that caveat, the ranges are consistent enough to plan against.
A single read-only FHIR connection to one EHR runs roughly $15,000 to $30,000. Bidirectional integration with one platform, covering patient data, documentation, orders, results, and scheduling, runs $50,000 to $80,000 over 10 to 18 weeks and usually combines FHIR APIs with HL7 v2 interfaces through an engine like Mirth Connect. Multi-platform, bidirectional suites run $150,000 and up. Epic is consistently the most expensive to integrate with, typically $18,000 to $80,000, because of its App Orchard and Showroom certification process and proprietary extensions; athenahealth is consistently the cheapest because of its API-first architecture.
The number most proposals leave off is the run cost. Every interface needs monitoring, error resolution, and updates when the vendor versions its API or retires an endpoint, and the market range for that is $3,000 to $15,000 per interface per year. HL7 v2 interfaces sit at the high end because they carry more transformation logic; FHIR interfaces are cheaper to keep alive. Both ends of the pipe move on their own schedules, and none of that is on your roadmap.
For an estimate scoped to your integrations rather than a range, our project calculator is a two-minute start.
Where the Timeline Actually Slips
What This Looks Like on a Real Integration
On one digital health engagement, the product needed both directions: read patient context in from the EHR at the point of care, and write documentation back. The read side went the way FHIR R4 is supposed to go, against the vendor’s certified API, and was the shorter half of the work. The write side was where the assumptions broke: what the vendor accepted, how it validated, and what it did with a rejected write were all specific to that implementation, not to the standard, and the error-handling and reconciliation logic ended up being the larger share of the engineering.
The other lesson was sequencing. Getting a real sandbox and real sample data before design, rather than after, moved several surprises from production back into week two, where they cost hours instead of weeks. Our healthcare development practice builds this into how integration work is scoped.
Integrating With Epic, Oracle Health, and athenahealth
The largest installed base and the most demanding process: App Orchard and Showroom registration, sandbox approval, and proprietary FHIR extensions to navigate. Budget the certification timeline as a workstream, not a formality. Its FHIR APIs are comprehensive once you are through the gate.
Broad FHIR R4 coverage with its own developer program and sandbox. Common in the same hospital systems that also run HL7 v2 feeds internally, so mixed-standard integrations are typical.
Cloud-native and API-first, which is why it is consistently the least expensive of the three to integrate with. A good first EHR to prove an integration pattern against before tackling Epic.
Common Mistakes in EHR Integration
HL7 v2 permits enormous local variation. Get real sample messages from the actual source system before design, not after the first failed test.
HL7 v2 confirms receipt with ACK messages. Interfaces that do not implement ACK handling correctly lose messages silently, which in clinical data is the worst possible failure mode.
$3,000 to $15,000 per interface per year in monitoring and vendor-driven updates is the line most quotes omit, and the one that surprises budgets in year two.
FHIR is far more consistent than v2, but vendor profiles and extensions still differ. Design the integration layer to be version- and vendor-aware.
Reads are where FHIR shines. Writes need validation, error handling, and reconciliation logic specific to each vendor, and they are where most of the engineering actually goes.
Frequently Asked Questions
Connecting a software product to an electronic health record system so patient data, appointments, orders, and results move between them automatically. It ranges from read-only data access to full bidirectional sync and event feeds.
HL7 v2 is a message-based standard from 1987 that still runs most internal hospital interfaces. FHIR R4 is a REST API standard using JSON resources, designed for web and mobile, and required for certified EHR patient-access APIs under US rules. Most real integrations use both.
Market ranges in 2026: roughly $15,000 to $30,000 for a single read-only FHIR connection, $50,000 to $80,000 for bidirectional integration with one platform, $150,000 and up for multi-platform suites, plus $3,000 to $15,000 per interface per year to run.
A read-only FHIR connection can ship in weeks. Bidirectional integration with one platform typically runs 10 to 18 weeks. Epic adds certification time on top. Multi-vendor programs run longer and are usually phased.
Not for your product. The ONC Cures Act rule requires certified EHR developers to expose FHIR R4 APIs for patient and population access, which guarantees a FHIR read path exists on the EHR side. What your product uses is your decision.
Usually yes if you are consuming HL7 v2 feeds such as ADT, and usually no for pure FHIR integrations. Mixed environments, which are the norm, tend to need one.
athenahealth is consistently the least expensive and fastest because of its API-first design. Epic is the most demanding because of its certification process and proprietary extensions, though its APIs are comprehensive once approved.
The read side over FHIR is approachable for a strong team. The write side, HL7 v2 feeds, and multi-vendor programs are where healthcare-specific integration experience saves the most time, because the surprises are implementation-specific rather than documented in the standard.
Scoping an EHR Integration?
The difference between a six-week integration and a six-month one is usually decided before code is written: which standard each source actually speaks, whether you need write access, and whether anyone has looked at real sample data yet.
See our healthcare software development practice, or talk to our team about the integrations on your roadmap.