Epic integration: what a real build involves
Epic's FHIR R4 endpoints are documented and public. Getting your app approved to call them, at a specific hospital, is the part nobody puts in the pitch deck.
Answered in short
5 things that decide this
- 01An Epic integration runs on FHIR R4 endpoints that any certified EHR exposes, but calling them for a specific hospital means going through Epic's own developer programme and app review first.
- 02Sandbox access is usually quick. Production access is a separate, slower approval that sits with Epic and with the hospital's own IT team, who decide what your app is allowed to touch.
- 03A practice does not own an Epic instance on its own in most cases. It sits on a health system's Epic, so the health system's rules, review queue and interface team govern the integration, not the practice.
- 04Where no FHIR endpoint exists for what you need, the fallback is an HL7 v2 interface built by the host organisation's own interface team, queued behind their other work.
- 05We build to the access model as Epic documents it: registration, sandbox, app review, then production. We confirm what your specific account exposes during the audit before quoting any timeline.
The API is the easy half
Ask a vendor if they can integrate with Epic, and most say yes without asking a single follow-up question. That's the wrong answer to give, because Epic isn't one system you connect to once. It's thousands of separate hospital and health-system instances, each configured differently, each with its own review process for a third-party app.
The FHIR R4 standard means a resource is named the same way everywhere. It doesn't mean every site has approved your app to read it. There's a separate developer programme and app review for exactly this reason. Certified access to the standard doesn't grant you access to any one hospital's data. That's a separate yes, from a separate party, on a separate timeline.
So the real first question isn't whether your code can call a FHIR endpoint. It's whose instance you're trying to reach, and who administers it. Then: has that organisation's own IT and compliance team said yes to your specific app? We confirm all three during the audit, before scoping anything.
It's rarely the practice's own decision
Most independent practices don't run their own Epic. It's priced and built for hospitals and health systems. A practice using it is usually on a host organisation's instance instead. That host is a hospital, an IDN or a health system that bought and configured Epic, then gave the practice a login inside it. The distinction changes who you're actually negotiating with.
If a practice sits on a health system's Epic, the health system decides what a third-party build can do. Its interface team, its IT governance and its app-review process all sit above the practice. Your practice can want an integration badly and still wait on someone else's queue, because the account isn't fully theirs to grant access to.
Where no standard FHIR resource covers what you need, the fallback is an HL7 v2 interface. That's older, message-based and built by hand, and it goes through the same host organisation's interface team rather than through Epic's app review. It's real work, and it sits behind whatever else that team already has queued.
- 01Epic's published developer documentation and your host organisation's interface team decide what's possible and how long it takes. We confirm this during the audit, against your own account, not against general documentation.
- 02A practice-level login inside a hospital's Epic is not the same thing as owning the integration decision for that Epic instance.
- 03Ask early who administers your Epic access. The answer decides who you actually need to convince.
- Developer programmeApp registered with Epic, credentials issued
- SandboxTest data, usually quick to reach
- App reviewEpic reviews the app against its own criteria
- Host organisation sign-offThe hospital or health system approves it for their instance
- ProductionReal patient data, live account, its own clock
- HL7 v2 fallbackWhere no FHIR endpoint exists, the interface team builds one
Sandbox access rarely blocks a project. Production access, and whatever the host organisation's interface backlog looks like, usually does.
Same question, different answer
Every EHR or PMS runs its own version of this gate, and none of them run the same one. athenahealth's Marketplace has its own developer application and review. eClinicalWorks exposes an API surface, but access usually runs through a partner programme rather than open self-service. Open Dental publishes a far more open API. That's one reason it shows up so often in smaller dental practices with no health-system layer in the way.
The pattern is worth remembering: the FHIR or HL7 standard tells you what a field is called. It never tells you who has to say yes before your app can read it. We check that per platform, per account, before we write a line of integration code.
Some of the systems we have shipped
Related questions
01Can a small practice integrate with Epic at all?+
Rarely on its own. A small practice on a health system's Epic instance goes through that system's own interface team and app-review process, not a self-service path. Administering your own Epic outside a host is possible, but the developer programme and app review are still Epic's. We confirm what your specific instance exposes before scoping anything.
02How long does an Epic integration take?+
Epic's published developer documentation and your host organisation's interface team decide this, not a general estimate. Sandbox access tends to move fast. Production access and any HL7 v2 interface work depend on the host organisation's own queue, which we confirm during the audit rather than guessing at.
03What's the difference between FHIR and HL7 v2 here?+
FHIR R4 is the modern, resource-based standard that Epic's developer programme exposes for app review and API access. HL7 v2 is older and message-based. It's still used where no FHIR resource covers what you need, built by the host organisation's own interface team rather than through Epic's app review.
04Do you need to be listed in Epic's App Orchard to integrate?+
Listing matters for a packaged product other health systems will install later. A one-off integration built for a single practice doesn't necessarily need that listing. It still goes through the same developer programme and app review for that one instance.
05Is athenahealth or Open Dental easier to integrate with than Epic?+
Usually, yes, but each has its own gate. Open Dental publishes a comparatively open API, which is part of why smaller dental practices choose it. athenahealth and eClinicalWorks both run their own developer or partner programmes, separate from Epic's, with their own review steps. Same question, different answer each time — we check the one that applies to your account.
Related
- EHR integration →What we build around FHIR and HL7 access, once the approvals are in place.
- Healthcare hub →AI, automation and custom software across every stage of a practice.
- Protected health information →What PHI covers and what a build owes it.
- HIPAA →The rules a healthcare integration is built against.
