EHR APIs Compared: Epic, Oracle Health, athena and eCW

Nirmitee.io — Tue, 03 Nov 2026 10:57:08 +0000

All four pass the same certification floor. Where they differ (write-back, backend access and the path to a live customer) decides your roadmap.

If your product has to work with more than one EHR, every health system you sell to asks the same question: "Does it work with our EHR?"

In the US in 2026, the answer starts with a certified FHIR R4 API secured with SMART on FHIR. Epic, Oracle Health, athenahealth and eClinicalWorks all offer one. But the parts a product roadmap depends on are not the same across the four.

Here is the short version, built from each vendor's public developer documents, checked on 12 September 2026.

What every certified EHR API must do

US rules (ONC criterion 170.315(g)(10)) set a floor. Every certified EHR API must:

Return one patient's data to an app that a clinician or patient has authorized.
Export data for a group of patients through FHIR Bulk Data.

That is the floor, and all four vendors meet it. Anything above it is a vendor choice. One example: using a backend (system) token for everyday single-patient calls, such as a scheduling agent looking up one patient's appointments with no user present. Epic, Oracle Health and eClinicalWorks document this, and athenahealth documents system scopes on its certified FHIR resources. How far it reaches still varies by vendor and by resource.

The biggest gap: writing data back

Reading data is broadly available. Writing it back is where the vendors split. From the public sandbox documents pulled in September 2026:

FHIR write-back by vendor, from public R4 CapabilityStatements, September 2026. Source: Nirmitee.io

Oracle Health lists writes on 21 resource types, including Appointment, Encounter, MedicationRequest and Coverage. It has the widest FHIR write surface of the four.
Epic lists writes on 13 resource types, focused on documentation, observations and orders.
athenahealth lists one standard FHIR write (QuestionnaireResponse create). Writes such as booking and clinical documents go through its proprietary athenaOne APIs, which athenahealth advertises as 700 to 800+ endpoints.
eClinicalWorks documents create, update and delete APIs, but contracts them separately, and they do not appear in its public metadata.

A listed write is a capability, not a promise. The original post gives three rules: check the write in the customer's own production metadata, make sure your app registration asks for that write, and plan a fallback (a proprietary API, an interface message or a clinician task).

How it plays out for common products

The full comparison on Nirmitee.io maps product types to vendor reality. A few examples:

AI scribe or ambient notes. Epic and Oracle Health list note (DocumentReference) create and update. eClinicalWorks has a contracted note create. athenahealth's FHIR API does not, so plan a non-FHIR note path there.
Scheduling or voice agent. Oracle Health lists Appointment create. Epic books through its own scheduling operations once the health system sets up its scheduling rules. eClinicalWorks has no FHIR Appointment API and points scheduling to healow.
Analytics and population health. All four support Bulk Data export, but Epic needs a patient roster built by the health system, and Oracle Health's Patient export needs a list of patient IDs.

Production access sets the schedule, not code

Every vendor puts the customer between your finished build and live data:

Epic: each customer downloads your client ID.
Oracle Health: Oracle validates provider-facing apps, then each client enables them domain by domain.
athenahealth: each practice enables your app. Its proprietary APIs also need a Platform Services contract and Solution Validation.
eClinicalWorks: the practice enters your App Activation Code, you approve the practice, and the practice activates the app.

Limits matter too. eClinicalWorks allows 250 calls per minute per practice base URL. athenahealth publishes 150 calls per second and 500,000 per day in production. Epic publishes no fixed rate limit. Oracle Health rejects Patient searches that match more than 1,000 records.

The vendor-by-vendor sections in the original post cover where teams get stuck, such as no sponsoring customer, per-site setup, locked app registrations and upgrade drift.

Roll out in five phases

A multi-EHR rollout in five phases. Source: Nirmitee.io

The post recommends one shared integration layer, with each EHR added as an adapter behind it:

Map. Write each feature as a resource, an action and an auth pattern. Check every sandbox's published capabilities.
Build. Pick the first EHR by customer demand and build against its sandbox, with tests for each feature.
Go live. Clear the vendor's gate with one sponsoring site, then rerun the tests in production.
Extend. Add the next vendor as a new adapter behind the same interface and run the same tests.
Operate. Recheck each site's capabilities on a schedule, alert per site and review each EHR release before it reaches your sites.

What drives cost and timeline

Cost depends less on how many FHIR resources you use and more on:

Vendors times sites. Each EHR is an adapter. Each site is setup, a security review and a production check.
How much you write. Every write path outside certified FHIR adds mapping, testing and ownership.
Customer queues. Client ID downloads, enablement, activation and security questionnaires run on the customer's calendar, so start them alongside the build.

The cheapest decision, in the post's words, is the one you make before the first adapter ships: keep vendor logic out of product code.

Nirmitee.io builds and runs EHR integrations across Epic, Oracle Health, athenahealth and eClinicalWorks for product teams. For the full comparison table, auth flows, and vendor-by-vendor detail, read the complete guide: EHR Integration APIs Compared (2026) on Nirmitee.io.

Dinesh Thorat is Healthtech Growth Partner at Nirmitee.io.

Originally published at nirmitee.io.