Explore
Need help with your project?
Oops! Something went wrong while submitting the form.
EHR integration connects your product to a health record system through FHIR R4, HL7v2, or a middleware layer. This guide covers the methods in use, Epic and Oracle Health specifics, 2026 compliance, build-vs-buy, and what actually drives cost.
EHR integration is the process of connecting an electronic health record system to another application — a patient portal, a scheduling tool, a lab system, a wearable-data pipeline — so patient data flows between them without manual re-entry. Most integrations today run on FHIR R4 APIs, with HL7v2 messaging still carrying the bulk of hospital-to-hospital traffic behind the scenes.
Quick answer: EHR integration connects your product to a health record system using one of four methods — a vendor’s FHIR R4/SMART on FHIR API, legacy HL7v2 messaging, a direct point-to-point interface, or a middleware/integration-engine layer. As of January 1, 2026, USCDI v3 is the adopted certification baseline in the ONC Health IT Certification Program, and certified EHRs must expose it through FHIR-based APIs. That’s why FHIR is now the default starting point for new integration work, not one option among several.
Product teams usually hit this problem in one of two ways: a hospital or clinic customer asks “does this talk to Epic?”, or a compliance review flags that patient data is moving through a system that was never built for healthcare software development in the first place. Both paths lead to the same questions: which method fits, what Epic and Oracle Health actually require from a developer, and what it costs to build.
This guide covers current integration methods, Epic and Oracle Health (formerly Cerner) specifics, the 2026 compliance picture, and how to decide between a platform and a custom build. If you're weighing a full system rather than an integration layer, our guide to building a custom EHR system covers the modules, compliance, and cost.
Ask a developer what EHR integration involves and they’ll describe an API call. Ask someone who has shipped one and they’ll describe a negotiation with a hospital’s IT department, its compliance officer, and a data model that doesn’t map cleanly onto anyone else’s.
EHR integration is the exchange of clinical data between an external system and an EHR platform — as opposed to a single-practice EMR, a distinction the EMR vs EHR comparison unpacks — typically through a defined API (FHIR R4) or message format (HL7v2), governed by interoperability rules from ONC and the Health Information Exchange (HIE) infrastructure a facility connects to. That covers the technical shape of the problem. It says nothing about why projects stall.
Grahame Grieve, the founder of FHIR and an interoperability consultant who has spent over a decade watching implementations succeed and fail, put it plainly:
"The primary challenge we face is a people problem — getting individuals skilled up and enthusiastic while ensuring they have the right connections to solve their problems."
— Grahame Grieve, FHIR founder (January 2025)
That tracks with what a build actually runs into. The FHIR spec is public and well documented. What isn’t documented is which fields a specific hospital’s EHR instance actually populates, who has authority to approve a sandbox request, and how long the security review takes once code is ready. Fewer than 1 in 3 US care-delivery facilities were connected to a regional HIE as of 2024, so even the exchange layer an integration sits on top of varies from site to site.
The technical spec is the easy 20%. The remaining 80% is data mapping, access approval, and coordinating with people who own systems you don’t control. That’s also where two systems that both claim FHIR compliance can still diverge in how they populate optional fields — the theme that resurfaces throughout this guide.
Four approaches cover nearly every real-world EHR integration project: a standards-based API (FHIR, usually paired with SMART on FHIR for app authorization), legacy HL7v2 messaging, a direct point-to-point interface built against one specific EHR instance, and a middleware layer that sits between multiple systems. The right one depends on what the EHR vendor exposes, what the receiving system needs, and how many endpoints are involved. A related workflow is clinical speech recognition integration, which adds audio capture, medical-language processing, and human approval before write-back.
Four ways product teams connect to an EHR, and when each one fits
FHIR R4 is the current production baseline for US health IT certification, and the standard EHR vendors must support for Cures Act API compliance through at least 2027. FHIR R5 is published, but adoption among certified products is still limited. As of January 1, 2026, USCDI v3 is the data-class baseline certified EHRs must expose through FHIR-based APIs, per the ONC Health IT Certification Program.
SMART on FHIR is the authorization layer on top of the FHIR API: an OAuth2-based framework that lets a third-party app request a patient’s data with consent. The SMART App Launch Implementation Guide v2.0.0 became the ONC-required minimum for HTI-1 certification as of December 31, 2025, up from v1.0.0 under the original Cures Act rule. Version 2 requires granular OAuth2 scopes (limiting access by encounter or diagnosis, for example) and revocation of a patient’s authorization within one hour. An integration built against SMART v1 assumptions needs a scope-handling rework to stay compliant.
HL7v2 is the messaging standard that still carries most real-time clinical data inside hospital networks (admit/discharge/transfer events, lab results, order feeds), independent of whether the front-end system also exposes FHIR. It’s widely cited as covering roughly 95% of US healthcare institutions and 35+ countries, though that figure traces to repeated vendor citations rather than a single dated HL7.org statement. Treat it as directional, not a precise stat to quote.
Point-to-point interfaces and middleware are less about a data standard and more about topology. A direct interface connects your system to one EHR instance with a purpose-built connector: fast for a single relationship, expensive to repeat across many. A middleware layer normalizes FHIR and HL7v2 traffic from multiple sources into one internal format, which pays off past two or three distinct EHR instances.
Epic EHR integration today runs through two current developer programs, not the “App Orchard” name still floating around in older blog posts and forum threads. App Orchard, Epic’s original developer marketplace launched around 2017 and renamed App Market in 2021, was shut down in December 2022. It was replaced by Epic Vendor Services, the paid developer program at vendorservices.epic.com, and Epic Showroom, the public-facing marketplace with an entry tier called Connection Hub.
Epic Vendor Services membership costs approximately $1,900 per year and unlocks sandbox environments, FHIR and SMART on FHIR documentation, CDS Hooks specs, and client-ID registration: the credentials needed to call Epic’s production APIs. Listing in Connection Hub, the public marketplace tier, starts at $500 per year on top of that.
The friction point teams underestimate is approval time, not API complexity. Getting a client ID provisioned and an app through Epic’s review process is a gated, asynchronous workflow that runs on Epic’s own review queue, not on how quickly an engineering team writes the integration. Any project plan for Epic EHR integration should budget vendor approval lead time as a separate line item from development time, and start that registration process in parallel with, not after, the technical build.
Cerner is now Oracle Health, following Oracle’s acquisition, and the branding shift extends to the developer tooling. The current developer portal and app-certification path is the Oracle Health code Console, at code-console.cerner.com. The older “code.cerner.com” URL still resolves and is referenced in Oracle’s own documentation, but the active console carries the Oracle Health name.
Through the code Console, developers register SMART on FHIR apps, configure redirect URIs, set launch context, and provision sandbox environments to test against before requesting production access. The workflow mirrors Epic’s in structure: sandbox first, then a registration and review step before production credentials. The specific fields, scopes, and app-listing requirements are Oracle Health’s own, so a connector built and tested for Epic’s sandbox won’t drop in against Oracle Health’s console without adjustment. Oracle Health is also listed among the organizations holding QHIN designation under TEFCA as of early 2026, which matters if an integration needs to reach beyond a single Oracle Health customer’s data.
HIPAA sets the floor for any EHR integration: business associate agreements, encryption in transit and at rest, audit logging. Meeting it is table stakes, not the hard part. The hard part comes after the security review, when one system’s data model has to map onto another’s without silently corrupting a patient record.
Two 2026 regulatory threads matter here. ASTP/ONC’s HTI-5 proposed rule, published December 22, 2025, would relax some certification and information-blocking requirements, with comments open through February 27, 2026. In the same action, ONC withdrew the non-finalized HTI-2 provisions floated in August 2024. Teams scoping a 2026 build should treat both as live, not settled.
The 2026 regulatory milestones an EHR integration has to clear
TEFCA adds a second track. As of early 2026, 11 organizations hold QHIN designation under the framework, more than double the count at TEFCA’s December 2023 go-live, and the network has moved over 1.2 billion documents since launch. Not every participant moves at the same speed.
"Where TEFCA looks to be a rising tide that lifts all boats, networks that have pledged to be a CMS-Aligned Network are more like speedboats shooting out ahead to achieve specific milestones."
— Steven Posnack, Principal Deputy National Coordinator for Health IT, ONC (December 2025)
That distinction matters for planning. A vendor that’s merely TEFCA-participating moves on a slower, baseline timeline. A CMS-Aligned Network partner commits to specific milestones on a faster clock, and a roadmap should track which category each connected system falls into. Two systems can both claim FHIR compliance and still diverge in how they populate optional fields, code allergies, or timestamp encounters. Reconciling those differences, field by field, is the work that turns a certified API into a working integration.
Build vs buy is the first real decision in any EHR integration project: pay a platform vendor (Redox, Mirth Connect-based middleware) for a pre-built connector layer, or build directly against FHIR/HL7v2 endpoints. Neither is automatically right, and each has a disqualifying condition vendor-sales content skips.
A platform earns its fee when a team needs to connect to many EHR systems with limited headcount, and the vendor already has a live connection to the target system (Epic, Oracle Health). It absorbs the mapping-table churn described above. The disqualifier: platforms charge per connection and per transaction volume, and cost compounds fast past a handful of endpoints. Its release cadence becomes yours too — if it hasn’t updated for SMART App Launch v2.0.0, neither has the product built on it.
Custom development earns out when the integration is core to the product, when fine-grained OAuth2 scope control is needed for HTI-1 compliance, or when endpoint count is small and known upfront. The disqualifier: the team owns every mapping table, certification renewal, and vendor API change going forward, and teams without in-house HL7/FHIR experience routinely underestimate this by months.
| Factor | Buy a platform | Build custom |
| Best fit | Many EHR vendors, small team | Few endpoints, integration is core product |
| Ongoing cost driver | Per-connection / per-transaction fees | Engineering maintenance hours |
| Compliance control | Bounded by platform’s own certification pace | Full control, full responsibility |
| Time to first connection | Faster (existing connector) | Slower (build from spec) |
| Long-term lock-in | Platform vendor dependency | None, but internal knowledge dependency |
A hybrid pattern shows up often: a thin custom API gateway in front of Epic/Oracle Health native APIs, handling auth in-house, while routing lower-priority feeds through a platform. UI/UX considerations for surfacing that integration inside a clinical workflow are covered in EMR/EHR interface design.
A fixed quote for “an EHR integration” before scoping means nothing. The real cost drivers live in five variables, none of them visible from the outside.
The five dials that move an EHR integration cost and timeline
Endpoint count is the first multiplier. One FHIR R4 connection to a single EHR is a contained project. Three EHRs, each with its own quirks, roughly triples the mapping and testing work, and it doesn’t stay linear once vendor-specific edge cases pile up.
FHIR-vs-HL7 mix changes the shape of the work, not just the size. A pure FHIR R4 build is comparatively predictable. Add HL7v2 parsing for a legacy ADT feed and the team maintains two integration paradigms instead of one, on top of the HL7v2-heavy legacy work already covered above.
Certification and SMART on FHIR compliance add fixed overhead regardless of endpoint count. HTI-1 required SMART App Launch Implementation Guide v2.0.0 by December 31, 2025: granular OAuth2 scopes and revocation within one hour. Proving that in testing is its own line item.
Data mapping blows up estimates most often. It’s manual, field-by-field work that scales with schema divergence, not endpoint count.
Vendor approval lead time sits outside engineering hours but still eats calendar time. Epic’s developer program review runs on Epic’s own schedule, and teams that budget zero slack for it consistently blow their launch date, even with the code done early.
Stack these five drivers and the spread between projects is wide by design. A single-EHR, FHIR-only connection for a startup-stage product sits at the low end of typical custom software budgets in the low five figures, while a multi-EHR build mixing HL7v2 legacy feeds with full SMART on FHIR certification testing moves well past it. Anyone quoting a fixed number before seeing the target EHRs and data model is guessing.
Purrweb treats EHR integration as a compliance-first engineering problem, not a feature bolted on later. Discovery comes first: which EHR systems the product needs to talk to, what data classes are required, and which standard (FHIR R4, HL7v2, or a mix) each endpoint exposes.
Data mapping is built and tested against real sample messages from the target systems, not the spec alone, since spec-compliant fields and real-world facility data rarely match. HIPAA requirements are designed into the architecture from this stage, not retrofitted after a security review flags gaps.
The build phase implements SMART on FHIR authorization with the granular OAuth2 scopes HTI-1 requires, so the integration is ready for certification review rather than needing rework. Certification and vendor approval run in parallel with the build wherever the vendor’s process allows.
For teams weighing platform vs custom (see above), Purrweb scopes both paths against actual endpoint count and compliance requirements before recommending one. Full-service delivery is covered under EHR/EMR development services.
EHR integration in 2026 is a compliance-and-architecture decision before it’s a coding task. USCDI v3 and SMART App Launch v2.0.0 set the certification floor, TEFCA’s QHIN network keeps expanding past 11 designated networks, and HL7v2 mapping friction hasn’t gone away just because FHIR exists.
Buy a platform when broad EHR coverage matters more than headcount. Build custom when the integration is core to the product and direct control over compliance and scope logic is non-negotiable. Cost and timeline hinge on endpoint count, standard mix, certification lead time, and how messy the data mapping turns out to be, not a flat quote.
➡️ If you’re scoping an EHR integration and want a realistic architecture and cost estimate before committing engineering time, get a free project estimation from Purrweb’s team.
EHR integration links an electronic health record system to another application, most often through a FHIR R4 API or HL7v2 messaging, so a scheduling tool, patient portal, or lab system can exchange patient data automatically instead of relying on staff to re-key it between systems.
Yes. Epic exposes FHIR R4 and SMART on FHIR APIs. The original App Orchard marketplace was retired in December 2022 and replaced by two paths: Epic Vendor Services, a paid developer program with sandbox access, and Epic Showroom, a public marketplace with an entry-level Connection Hub tier.
Integration-platform vendors sit between a product and the underlying EHR APIs, offering pre-built connectors instead of direct FHIR/HL7v2 development. Common examples include Redox and Mirth Connect-based middleware. Coverage differs by vendor. Verify a live connection to the specific target EHR before committing.
Yes, through a shared standard rather than a direct link. They exchange data via FHIR APIs, HL7v2 messaging, or a national network like TEFCA, which connects Qualified Health Information Networks (QHINs) so participating systems can query records regardless of vendor.
HL7v2 is an older, message-based standard still used for most hospital messaging. FHIR R4 is the newer API-based standard, and the one ONC requires certified EHRs to expose through USCDI v3 data classes as of January 2026. Most real projects need to handle both.
.svg)
