Ask an engineer how long it takes to integrate with Epic and you might hear "a couple of weeks." Ask someone who has actually shipped one and you will hear "we are eight months in." Both are looking at the same project. The difference is that the engineer is counting the code, and the code is the small part.
The honest answer: plan for 6 to 18 months end to end. Here is exactly where that time goes, phase by phase, what each phase costs, and a readiness checklist you can run before you commit to a single date.
The short answer
An Epic integration is nine phases. A few are fast and entirely in your control. The slow ones are not about code at all, they are about a customer's queue, a security review, and the months it takes to land a hospital willing to sponsor you.
Notice the shape: the build is measured in weeks, but landing a sponsoring customer is measured in months, and it gates everything after it. That single bar is why "two weeks" becomes "two quarters."
The nine phases, one by one
For each phase below: what happens, the realistic duration, and what to have ready so it does not stall. Durations are the ranges reported consistently across integrators, not Epic-published figures.
1. Register your app (1 to 2 weeks)
Create an account on Epic on FHIR, register the app, and Epic generates a production and a non-production client ID. You declare your FHIR scopes and pick a "primary user type" here, and that choice quietly decides which APIs and auth flows you can even use. One trap: once you mark an app "ready for production," the record is frozen. Other than adding redirect URIs and updating your key URL, any change means registering a brand-new app.
2. Build and test in the sandbox (2 to 8 weeks)
This is where your engineering time actually concentrates. You build against synthetic data on the public sandbox. The catch every team learns: you never get a real Epic instance to test in. As one developer who builds for both Epic and Cerner put it on Reddit, "Epic have a policy of not providing them... we still can't get an Epic env to test in." The sandbox is clean and well-behaved in a way production never is.
3. Marketplace listing, if you pursue it (2 to 4 months)
Epic's old "App Orchard" is gone. The marketplace is now Showroom, with a self-attested Connection Hub listing (about $500/year, and you need at least one live Epic customer to qualify) and a paid Vendor Services membership (reported around $1,900/year; Epic does not publish the figure) for proprietary APIs and support. A listing helps discoverability. It does not get you into production. We cover the full program maze in our companion guide, how to get your app into Epic.
4. Land a sponsoring customer (6 to 18+ months) — the longest pole
This is the phase nobody puts on the engineering plan, and it is usually the critical path. You cannot reach production without a health system that signs the agreement and switches your app on. And the chicken-and-egg is brutal, in the words of a former Epic employee:
"Most successful apps start with the customer attached... the majority won't talk to you until you're already live somewhere else."
- former Epic employee, r/healthcareIT
Treat this as job one. Start it before you write production code, because everything downstream waits on it.
5. The customer's security review (4 to 12 weeks)
Before a hospital enables you, its security, privacy, and vendor-management teams run a vendor risk assessment. This is the most under-scoped phase and a frequent stall. A solo founder described it bluntly: "their sandbox worked fine but production requires 16 different certificates and a 3 month review process." We break the full evidence list down in the checklist below.
6. Customer-side provisioning (4 to 12 weeks)
Someone at the customer with the right Epic security role downloads your client into their environment, and their team builds and configures it, promotes it through test, and sets up connectivity. This phase is dominated by one thing: the customer's own Epic IT team is frequently backlogged 3 to 6 months. You wait in their queue, and no amount of clean code shortens it.
7. Validation in their environment (3 to 8 weeks)
Every site is, as the saying in the field goes, "a beautiful and unique snowflake." Site-specific code sets and content break assumptions that passed in the sandbox, so real integrated testing against their data always surfaces rework.
8. Go-live and hypercare (3 to 8 weeks)
Production cutover goes through the customer's change-control board, then a heightened-support window (hypercare) of typically two to six weeks while real users hit it.
9. Every additional customer (2 to 6 weeks each) — the repeat tax
Here is the part that surprises founders most: it does not get much easier. Each new hospital re-runs the security review, the provisioning, and the validation. One builder noted "security reviews that reset every time a health system's IT team changes."
An HL7 v2 interface can run $50,000 to $60,000 per hospital; a standardized EHR integration over FHIR lowers the per-customer cost, but it never reaches zero. Certification does not exempt you from any of it.
What it costs
Membership fees are rounding errors next to the build. The standardized USCDI read APIs are actually free under the Cures Act; what costs money is the build labor, the security evidence, and the per-site work.
- FHIR read-only: roughly $40,000 to $80,000, 2 to 4 months of build.
- FHIR read and write: roughly $80,000 to $180,000.
- Full bidirectional: $150,000 to $350,000 and up, 6 to 14 months.
- Each additional site: $10,000 to $40,000.
- Security evidence (SOC 2 / HITRUST): often $30,000 to $100,000+ on its own.
Where the calendar actually goes
If the code is weeks and the project is 6 to 18 months, where does the time go? The most-quoted line in the field, from interoperability veteran Brendan Keeler, sums it up:
"Integration is 20% development, 80% negotiation and coordination."
- Brendan Keeler, Health API Guy
The 80% is the customer's IT queue, the security and legal review, the sales cycle to land a sponsor, and the per-site repeat tax. None of it is something you can engineer away, which is exactly why estimates that count only the code are always wrong.
The readiness checklist
Run this before you commit to a date. Every box you cannot tick is a place the project will stall.
- A sponsoring Epic customer lined up, or a concrete plan to get one.
- Decided whether this is read-only, read-write, or embedded (each is a different project).
- The right SMART on FHIR auth flow chosen for how your app runs.
- Sandbox tested against real-shaped, messy data, not just the happy path.
- Client IDs and keys provisioned per customer and per environment.
- SOC 2 Type II report, current and correctly scoped.
- HITRUST i1 or r2 (most hospital and health-plan buyers expect it).
- A signed BAA ready, with a reconciled subprocessor list.
- PHI audit logging actually in place and complete.
- Access controls: mandatory MFA, RBAC, documented offboarding.
Pass the vendor security review
The security review is where promising integrations quietly die. It is not mysterious, though. It is a finite list of evidence a hospital's HIPAA and security teams expect you to produce. Have these ready and the review takes weeks instead of quarters.
- SOC 2 Type II — current, scoped to the actual product, with a bridge letter if the period ended more than three months ago.
- HITRUST i1 or r2 — a large majority of hospitals and health plans require it of their vendors, unlike most SaaS deals.
- Penetration test — within the last 12 months, from a qualified third party.
- Signed BAA — with audit rights, breach notice, and subcontractor flow-down.
- Subprocessor list, reconciled to the BAA — this is the single most common stall. Procurement will compare your full list of PHI-touching vendors against your BAA coverage, and anything missing gets flagged.
- Complete PHI access audit logs — the second most common gap.
- Cyber-insurance certificate, a data-flow diagram, and your incident-response plan.
One important clarification: helping you genuinely meet this bar is the point. None of the above is about looking secure for an audit; it is the work that makes the patient data actually safe.
How to compress the timeline
You cannot make Epic faster, but you can stop adding self-inflicted delay.
- Line up a sponsoring customer before you build. It is the longest pole, so start it first.
- Run the security review in parallel with the build, not after it.
- Have your SOC 2 and BAA ready before the customer asks, so you can answer questionnaires same-day.
- Treat access as the critical path and schedule into the customer's IT queue as early as possible.
Do you need to be ONC certified?
A common worry, and the honest answer is usually no. Passing the ONC g(10) / Inferno test suite shows your software conforms to the standardized API criterion, but it is not the same as being a certified Health IT Module on the CHPL, which requires a formal certification body. More importantly, the g(10) certification obligation sits on the EHR (Epic) as the API provider, not on the third-party app consuming the API. A typical SMART on FHIR app integrating with Epic does not need to be ONC certified. It only matters if your product is itself the certified technology a provider attests with for federal programs.
The honest bottom line
Epic integration is not slow because the engineering is hard. It is slow because access, trust, and a customer's queue cannot be rushed, and because the same gauntlet repeats for every hospital. The teams that get through cleanly do three things: they land a sponsor before they build, they prepare their security evidence up front, and they treat access as the critical path rather than an afterthought.
That is the work our team does every day. We build the FHIR, HL7, and X12 connection layer so your engineers stay on your product, and our proof is public: our open-source headless FHIR server passes the ONC g(10) / Inferno SMART App Launch suite, 47 of 47 tests, on GitHub.
If you are scoping an Epic project and want a realistic timeline before you commit one to your board, our healthcare interoperability solutions team connects digital-health products to Epic and the major EHRs every day, and our custom healthcare software development team can build the product around it. Talk to our team to pressure-test your scope.
