Every certified electronic health record sold in the United States has to expose a FHIR R4 API. That's not a vendor's choice.
It's a baseline set by federal certification rules, and it's the reason FHIR integration shows up in almost every healthcare app that needs to read a chart, write back a result, or sit between a patient and their insurer.
Get the integration wrong and your app sits in an EHR's sandbox for months waiting on approval.
Nail it, though, and the same connection that talks to Epic can usually talk to Oracle Health and Athenahealth with only a thin mapping layer in between.
On top of that baseline, a new set of CMS rules lands between 2026 and 2027, changing what counts as finished for a lot of these builds.
How FHIR Integration Actually Works in a Healthcare App
FHIR breaks a patient's record into resources: a Patient resource, an Observation, a MedicationRequest, a Condition.
Each one has a standard shape, so a lab result from one system and a lab result from another show up in the same structure.
That's the whole trick behind interoperability, according to HL7's own FHIR specification: resources are built from reusable data types with common metadata. It's a deliberate break from older standards like HL7 v2 and CDA, which modeled data by constraint instead.
Your app doesn't usually touch those resources directly. It goes through SMART on FHIR, the launch framework that wraps the API in OAuth 2.0.
Registration happens with the EHR itself: your app requests specific scopes, such as read access to observations or write access to one resource type, and gets back a token tied to one patient, one provider, and one session.
Ask for broader access than the feature needs, and the review process slows down. Every EHR vets scopes against what the app actually does.
Connecting to Epic, Oracle Health, and Whatever Else You'll Meet
Epic is usually the first wall a team hits, and it's also the best documented.
Its developer program publishes FHIR APIs across DSTU2, STU3, and R4, with read, search, create, and update operations across hundreds of resource types, plus CDS Hooks support for plugging decision tools straight into a clinician's workflow.
According to Epic's own developer documentation, every app goes through client registration, a sandbox with test data, and an app review before it touches a live chart.
Oracle Health, the company formerly known as Cerner, runs the same pattern on its own developer portal: FHIR R4 resources, OAuth 2.0, and a SMART app launch flow.
Small differences between the two mean a team building for both still needs a mapping layer that normalizes them, rather than running two completely separate integrations.
| EHR | FHIR versions | Auth model | What it buys you |
|---|---|---|---|
| Epic | DSTU2, STU3, R4 | OAuth 2.0, SMART launch | Largest install base, deepest resource coverage, app marketplace listing |
| Oracle Health (Cerner) | R4 | OAuth 2.0, SMART launch | Second major EHR to support for most multi-system products |
A single FHIR mapping layer, built once against the standard rather than against either vendor's quirks, is what lets a team add a third or fourth EHR later without rebuilding the integration from scratch.
What the 2026-2027 Federal Rules Actually Require
Two separate federal requirements sit underneath most FHIR integration work right now, and they apply to different parts of the healthcare system.
The first is ONC's certification criterion for certified health IT, which requires API-enabled read access for patients and populations.
Under ONC's API Condition of Certification, developers have to publish their technical documentation publicly, on non-discriminatory terms, and without charging for the access itself.
The second is CMS-0057-F, which targets payers rather than EHR vendors.
Medicare Advantage organizations, state Medicaid and CHIP programs, and qualified health plan issuers on the federal exchanges have to build and maintain four FHIR-based APIs. The CMS fact sheet on the rule lays them out plainly:
- A Patient Access API, now expanded to include prior authorization data
- A Provider Access API for sharing claims and encounter data with in-network providers
- A Payer-to-Payer API so a patient's history follows them when they switch coverage
- A Prior Authorization API for electronic requests, decisions, and denial reasons
Some operational pieces of the rule already kicked in at the start of 2026, but the APIs themselves aren't due until January 1, 2027.
If your app talks to a payer rather than a provider, that deadline is the one to plan around. It's close enough now that a build started from scratch has little room left to slip.
Where These Projects Actually Go Wrong
The API itself is rarely the hard part. Scopes are what actually trip teams up.
Teams ask for more access than a feature needs because it's easier to request everything up front, and that's exactly what slows down an EHR's app review.
Request only what the feature uses, and the review moves faster, because there's less for the reviewer to question.
Mapping is the other recurring problem.
A FHIR resource is a standard shape, but your product still has its own internal data model, and the two rarely line up field for field.
Take a Condition resource: it might carry a diagnosis code your app needs to display differently depending on which clinic submitted it. Get that mapping wrong once, early, and it has to be unwound across every record already synced.
Sandbox data causes its own trouble. Epic's test sandbox and Oracle Health's equivalent both use synthetic patients, and synthetic data is clean in ways real records never are.
Missing fields, inconsistent coding, and duplicate resources all show up for the first time once an app goes live. A realistic testing plan has to go beyond what the sandbox hands you.
Security and access control sit on top of all of it. If your app is handling protected health information, the FHIR layer is only one half of the compliance picture, and our guide to HIPAA compliant app development covers the half FHIR doesn't.
Should You Build Your Own FHIR Layer or Buy a Connectivity Platform?
Some teams build their own mapping layer against the raw FHIR APIs. Others buy a connectivity platform that's already done the Epic-versus-Oracle-Health normalization and hands your app a single consistent interface.
Neither is automatically the right call.
A platform gets you to a working integration faster, but you're trusting someone else's scope requests and someone else's uptime. Building your own gives you control over exactly what data moves and when, at the cost of maintaining it as EHRs update their APIs.
What decides it, more than anything else, is how many EHRs your product actually needs to reach, and how much that number is likely to grow.
A single-EHR pilot rarely justifies a platform subscription. Aiming at three or four major systems in year one usually does.
Our guide to choosing a healthcare app development partner walks through the same build-versus-buy tradeoff from the vendor-selection side.
When we built OptimalMD's platform, we designed and built the member-facing product end to end: the website, the members portal, and the mobile app.
Questions about how a member's record is structured, and who's allowed to see which piece of it, come up at every layer of a build like that, long before an EHR connection enters the picture.
It's part of why interoperability planning belongs in the architecture conversation from day one, rather than being bolted on once the app already works.
For teams weighing the full scope of a build like this, our complete guide to healthcare software development covers the pieces around the integration itself, and our apps and SaaS team can help scope where FHIR work fits into the rest of the product.
Frequently asked questions
Does FHIR replace older HL7 v2 integrations?
Not everywhere yet. Plenty of hospital systems still run HL7 v2 feeds for lab and ADT messages alongside FHIR APIs for newer, patient-facing use cases. A new build should target FHIR, but don't assume every data source you need has already made the switch.
Do I need ONC certification to build a FHIR-connected app?
No. ONC certification applies to the EHR or health IT module exposing the API, not to the third-party apps that connect to it. Your app registers as a SMART on FHIR client against an already-certified system; it doesn't need its own certification to do that.
Can a FHIR integration feed an AI tool or an automation workflow?
Yes. Epic's FHIR platform includes CDS Hooks specifically so external tools, AI-assisted ones included, can plug into a clinician's workflow at the point a decision gets made, rather than pulling data out after the fact.
Is R4 still the version to build against, now that R5 exists?
For now, yes. HL7 R5 is the current published release, but ONC's certification criteria and CMS-0057-F both specify FHIR R4 as the required standard, which makes it the version every major U.S. EHR actually exposes in production.
Sources
- FHIR Overview — HL7
- Epic on FHIR — Epic
