The four routes into Epic, what Epic charges and who pays, and why a sponsoring health system sets your timeline more than code does.
Originally published on Nirmitee.io: How to Integrate with Epic EHR (2026): Steps, APIs, Cost & Timeline
"Does it work with Epic?" is one of the first questions a health system asks a healthtech vendor. Getting to "yes" is less about code than most teams expect. To integrate with Epic, you pick the route that matches who is present when your code runs, register your app on Epic on FHIR, build against the free sandbox, then go live through a health system that signs Epic's API agreement and switches your app on.
Here is the short version, for founders and product leaders planning an Epic integration.
Four routes into Epic
The four core routes into Epic. Source: Nirmitee.io
There is no single "Epic integration". Epic publishes several hundred APIs, most of them FHIR R4, plus HL7 v2 interface specifications and Epic-specific web services. There are four core routes, and most products that sell to health systems use two of them:
- FHIR R4 API: read a patient's record, such as problems, medications, labs, vitals and notes.
- SMART app inside the chart: your web app opens inside Epic with the patient already selected, so to the clinician it looks like part of Epic.
- HL7 v2 interface: real-time admissions, results, orders, schedules and charges, built by the health system's interface team.
- Backend Services and Bulk Data: server-to-server syncs and population exports, with no user present.
CDS Hooks (alerts while a clinician orders) and TEFCA (patient-directed record retrieval) are two more for specific jobs.
What Epic charges, and who pays
Developers pay Epic nothing for its public and standards-based APIs. Registration and the sandbox are free and self-service. The health system pays an annual API subscription per production instance: $4,500 to $47,000 for the full USCDI FHIR set, in five tiers by size, or from $300 a year for a single API.
Two programs are optional. Vendor Services (support, testing tools and guidance) starts at $1,900 a year. A Connection Hub listing on Epic's Showroom marketplace costs $500 per product per year, and you need one live Epic customer first. App Orchard no longer exists.
The original post reproduces Epic's full fee table, tier by tier.
Six steps from sandbox to a live customer
From the Epic sandbox to a live customer. Source: Nirmitee.io
- Register the app on fhir.epic.com and choose only the APIs you will use in production.
- Build and test in the sandbox. Test data is synthetic and well behaved. Production data is not.
- Mark the app ready for production. After this, only redirect URIs and key URLs can change. Any other technical change means a new app, so finish your API list first.
- The customer signs and downloads your client ID.
- Security review, customer build and testing in the customer's non-production environment.
- Go live, then repeat steps 4 to 6 for each new health system.
You control the first three steps. The last three run on the customer's calendar.
The gate nobody warns you about
Your production client ID does nothing until a customer's Epic team downloads it and finishes their setup. That creates a chicken-and-egg problem: you need a sponsoring health system to go live, and health systems are reluctant to be first.
Only three kinds of app reach Epic customers without a per-site approval, and all three are patient-facing and read-only. Every clinician app, every backend app and every app that writes is approved by each health system.
Writes are narrower than reads. In Epic's public catalog, none of the 255 USCDI-flagged APIs is a create or update, so every write is a governed, per-customer feature. A problem or allergy your app writes, for example, waits until a clinician reconciles it.
What changed in 2026
- From the May 2026 Epic version, backend apps must publish their keys at a JWK Set URL instead of uploading a static public key.
- SMART App Launch 2.0 and USCDI v3 are now the certified baseline.
- Epic published its full API fee table.
- Payer APIs for the CMS-0057-F rule became a build priority.
How long it takes
Plan for 6 to 18 months from start to a first live customer. Most of that time goes to landing a sponsor and waiting in the customer's queue, not to writing code. In the source post's phase table, registration takes 1 to 2 weeks, sandbox build 2 to 8 weeks, and the customer's security review 4 to 12 weeks. Each additional customer then takes weeks, not months, if you built for repeatability.
Every health system configures its own Epic build, so an integration that passes in the sandbox still needs testing in each customer's non-production environment. The full guide covers authentication, write-back and common errors in detail.
Before you start
Have four things ready: a sponsoring customer or a plan to get one, a defined data contract (which data, read or write, for which users, at what volume), the security evidence a health system will ask for, and HIPAA controls that actually run.
Nirmitee.io builds and runs Epic integrations for healthtech companies, from route selection to a live customer. For the fee table, the auth code, the write-back matrix and the cost model, read the full guide: How to Integrate with Epic EHR (2026) on Nirmitee.io.
Dinesh Thorat is Healthtech Growth Partner at Nirmitee.io.
Originally published at nirmitee.io.
Top comments (1)
Really useful breakdown, especially the point that the sponsoring health system sets the timeline more than the code does. That's the part founders tend to underestimate.
One question on the patient-facing route: my understanding is that apps using only the patient-access FHIR APIs (the Cures Act right-of-access path, standalone SMART launch) don't need a sponsoring health system in the same way, although each organization's endpoint behaviour still varies. Does that match what you've seen in practice, and has anything changed there in 2026?