An Epic integration build moves through five phases: discovery and workflow mapping, gaining Epic system access (through Interconnect or Epic’s developer program, which requires certification before anything touches a live environment), the technical build itself, testing in Epic’s sandbox, and go-live validation. The phase almost every team underestimates is certification — Epic requires interfaces to pass its own review before they get near a production chart, and that queue, not the code, is usually what sets the real timeline. A narrow, read-only FHIR pull can ship in a matter of weeks. A bidirectional interface touching orders, results, or scheduling runs months. Teams that have shipped Epic interfaces before know which certification steps to start in parallel with development. Teams doing it for the first time find the bottleneck the hard way — after they’ve already hit it.

Epic controlled 43.7% of the U.S. acute care hospital EHR market in 2025, per KLAS Research — its fifth straight year of gains, and the only vendor large health systems (10+ hospitals) picked at all that year. If you’re building software that needs to talk to a hospital or health system’s records, there’s better than even odds it needs to talk to Epic. That’s the demand side. The supply side — teams who’ve actually sat in Epic’s certification queue and know where a build stalls — is a lot thinner, and most of what ranks for “Epic integration” online reads like a generalist agency learning Epic’s documentation in real time. This is what the build calendar actually looks like, phase by phase, including the parts Epic’s own marketing leaves out.

What “Epic Integration” Actually Means

There are two real pathways into Epic. Interconnect is Epic’s web-services API layer — the plumbing that exposes HL7v2 and FHIR endpoints so an outside system can read or write data. Epic’s developer program (what used to be called App Orchard, now split into Connection Hub for developers and Showroom for the customer-facing marketplace — the old name still shows up constantly in hospital IT conversations, so expect to hear it even though the program itself has been restructured) is the path for an app meant to be listed and reused across multiple Epic customers, not just built for one client’s instance.

Those are very different projects wearing the same name. A read-only FHIR pull for a patient-facing app is not the same build as a bidirectional interface writing orders or results back into a live chart. Anyone quoting you a single number for “Epic integration” without asking which one you’re building hasn’t scoped it yet. The rest of this post follows one representative build end-to-end, the kind our team has actually shipped for Epic integration clients.

Phase 1 — Discovery and Workflow Mapping

Before a line of code gets written, someone has to define which Epic modules the integration actually touches — Orders, Results, Scheduling, MyChart, whatever’s in scope — and which direction the data flows. This is also where you find out who owns the relationship on Epic’s side, and it’s not the vendor. It’s the client’s own IT or informatics team. Epic doesn’t grant access to an outside developer on request; the client’s Epic administrator has to sponsor it. Skip this step or rush it, and you’ll be renegotiating scope mid-build, which is exactly the kind of thing that resets a certification clock.

The deliverable out of this phase is a data-flow map and integration spec the client’s Epic team actually signs off on — not a vendor’s internal notes, a document the people who control Epic access have reviewed and approved before build work starts.

Phase 2 — Getting Epic Access: Interconnect, Certification, and the Real Bottleneck

This is the phase that actually paces the project, and it’s the one most competitor content glosses over. “Getting access” means the client’s Epic administrator provisioning Interconnect endpoints on their instance, and — if the integration is going to be distributed as a reusable app rather than a one-off client build — the vendor going through Epic’s developer program review and certification.

Realistic numbers here: marketplace review generally runs two to four months, and site-specific activation adds another one to three months per site on top of that. A simple, read-only FHIR integration can be live in two to four months total. A comprehensive bidirectional build combining FHIR and HL7v2 — development, testing, marketplace listing, and per-site go-live — more realistically runs six to fourteen months. None of that is coding time. It’s review time.

What a team that’s done this before does differently: they start the certification paperwork in parallel with early development instead of treating it as a step that happens after the build is “done.” A team doing it for the first time treats certification like a formality at the end of the project. It isn’t. It’s usually the longest single phase on the calendar.

Phase 3 — The Build: Mapping Data to Epic’s Model

HL7v2 vs. FHIR R4 vs. Interconnect Web Services

Here’s the part that surprises people who assume FHIR has already replaced everything: over 95% of hospitals still run HL7v2 for core system integrations, according to ONC data. HL7v2 isn’t legacy cruft waiting to be retired — it’s the workhorse still moving the bulk of order and result traffic in a live Epic environment. FHIR R4 is Epic’s modern standard for newer, app-based integrations, and it’s growing fast — Epic’s own FHIR APIs process over a billion transactions a month — but in 2026 a real integration project usually needs to speak both, not pick one.

The actual engineering work here is field-level mapping between your application’s data model and Epic’s, and it’s rarely a clean 1-to-1. Epic represents encounters, flowsheets, and orders with its own quirks that a generic FHIR server wouldn’t prepare you for. Add error handling and retry logic for HL7 message queues — because messages get dropped, malformed, or duplicated in the real world, not just in test data — and this is the section where a technical buyer, a CTO or informatics director evaluating a partner, can tell in about thirty seconds whether they’re talking to a team that’s actually built one of these or a team reading Epic’s docs for the first time.

Phase 4 — Testing in Epic’s Sandbox

Epic’s non-production sandbox environment catches a lot, but not everything — it won’t surface the load patterns of a real clinical day. Testing scope should cover end-to-end message flow, edge cases (duplicate patients, malformed HL7 segments, partial or missing data), and, if the interface will carry real clinical volume, load testing under something close to actual throughput. Sign-off here is a joint call — your QA team and the client’s Epic analyst or informatics lead both need to agree it’s ready, because only one of you can see the client’s live environment.

Phase 5 — Go-Live and Epic Validation

Moving from sandbox to production means working through Epic’s own go-live checklist, a cutover window — usually scheduled during low-traffic clinical hours, for obvious reasons — and an active monitoring period immediately after go-live. A rollback plan isn’t optional paperwork here. This is a clinical system. If something breaks during cutover, the team needs a tested way back to the last known-good state before it affects a single patient chart.

Common Pitfalls That Delay Epic Integration Builds

A 2025 healthcare IT survey found interoperability issues were the leading cause of delayed implementations, cited by 56% of teams — and industry estimates from KLAS and HIMSS put 30 to 50% of EHR projects overall into significant scope, timeline, or budget overruns. The specific ways Epic builds blow their timelines are consistent enough to name:

  • Underestimating certification lead time — worth restating as the number one delay cause, because it’s the one every first-time team gets wrong.
  • Treating Epic like “just another FHIR server” and skipping the platform-specific data-model quirks until they show up as bugs in testing.
  • Not looping in the client’s Epic analyst early enough — access and sign-off both run through them, not the vendor, and a build that ignores that reality stalls waiting on approvals it should have started weeks earlier.
  • Scope creep — starting with a narrow read-only integration and expanding to bidirectional mid-build without re-scoping the certification work that decision now requires.

How Long Does an Epic Integration Actually Take?

There’s no single honest number, but there are honest ranges: two to four months for a narrow, read-only FHIR integration; six to fourteen months for a bidirectional HL7v2/FHIR build that needs marketplace certification and per-site activation. Anyone quoting a flat number without asking which kind of integration you need is guessing, not scoping.

Why the Team You Hire Matters as Much as the Process

A generalist dev agency encountering Epic’s documentation for the first time is going to make the same mistakes this post just walked through — not because they’re careless, but because there’s no substitute for having already sat in the certification queue once. A team that’s shipped Epic, Cerner, and athenahealth integrations before knows where the real friction is, because they’ve felt it — we compare what each of the three actually demands of an integration partner in Epic vs. Cerner vs. athenahealth. That’s the whole differentiation, and it’s the same reason we build to a practice’s actual workflow with custom EHR development rather than handing over a generic template and calling it done. A cardiology group running Epic and pulling device data into a structured chart needs a genuinely different build than a single-location urgent care clinic doing a read-only patient lookup — see how that plays out in practice on our cardiology EHR work.

If you’re earlier in the process and still scoping what an integration project actually requires before you’re ready to talk build phases, our EHR integration guide for founders is the better starting point — it covers the decision-making before you get to a calendar like the one above.

Next Steps

If Epic is somewhere on your roadmap, the conversation worth having now is about scope — which pathway, which modules, which direction the data actually needs to move — not just a timeline estimate. Learn more about our Epic integration services, browse the broader EHR integration work we do beyond Epic specifically, or talk to our team about where your build actually sits on this calendar.