Epic integration services
SMART on FHIR apps, backend integrations and HL7 v2 interfaces for Epic customers.
Free checklist
Epic integration planning checklist
Use this Epic integration checklist before you write code. It covers the use case and sponsor, the access path, FHIR scopes, the work on the health system's side, testing and go-live, so your plan matches how Epic customers review and switch on integrations.
For digital health founders and product teams whose first health system customer runs Epic.
Epic integration plan
Phase 5 of 6Your team
Register appMap FHIR R4 resourcesSandbox tests
Health system
Sponsor confirmedSecurity reviewEnable in production
What does the Epic integration checklist help you decide?
The Epic integration checklist helps a product team decide how their app should connect to a health system running Epic: which access path to use, which FHIR resources and scopes to request, what the customer's Epic team must do and what has to be tested before go-live. It turns Epic integration requirements into an ordered plan.
Last reviewed by the Agnotic Technologies engineering team
What needs to be in place at each phase?
Six phases in the order they usually happen. Phases 1 and 2 decide whether the project can start; phases 3 to 6 are the build. Your ticks stay in this browser tab and are not sent anywhere.
0 of 23 tasks ready
Use case and sponsor
0/4Access path and registration
0/4Data and scopes
0/4Build
0/4Testing
0/4Go-live and support
0/3
Access paths
Which Epic access path fits your use case?
Five common ways an app connects to a health system on Epic. Which ones a health system will enable is its decision, so confirm early with its Epic team.
| Access path | Who starts it | Typical use | Standard |
|---|---|---|---|
| SMART on FHIR, EHR launch | A clinician, from inside Epic | An app inside the clinician's workflow that opens on the current patient | SMART App Launch, FHIR R4 |
| SMART on FHIR, standalone launch | A patient or clinician, outside Epic | A patient app that connects to the patient's record after they sign in | SMART App Launch, FHIR R4 |
| Backend services | Your server, with no user present | Scheduled sync, population data or bulk export | SMART Backend Services, FHIR Bulk Data |
| HL7 v2 interface | The health system's interface engine | Real-time feeds such as admissions, orders and results | HL7 v2 messages such as ADT, ORM and ORU |
| CDS Hooks service | The EHR, at a workflow point such as opening a chart | Recommendations shown as cards inside the workflow | CDS Hooks |
Where do Epic integration projects stall?
The points where we see plans slip, and the checklist item that prevents each one.
Failure point 1
No sponsor on the health system's side
Without an owner who wants it live, the request waits behind internal projects.
Prevented in Phase 1
Failure point 2
Scopes added late
Asking for a new resource or for write access after the security review can reopen parts of that review.
Prevented in Phase 3
Failure point 3
Testing only in the sandbox
Example data does not match a customer's configuration, so mappings break in their test environment.
Prevented in Phase 5
Failure point 4
PHI in logs and analytics
Debug logs and analytics events are an easy place for PHI to leak while an integration is being built.
Prevented in Phase 4
Failure point 5
Nobody owns it after launch
Upgrades on Epic's side or yours need regression tests and a named owner.
Prevented in Phase 6
What should you do with the result?
Step 1
Unticked items in phases 1 and 2 are blockers
Resolve them with the customer before you estimate the build.
Step 2
Unticked items in phases 3 and 4 are scope
They drive Epic integration cost: the number of resources, write access, launch types and how many customer environments you support.
Step 3
Phases 5 and 6 belong in the project plan
Give each item an owner on your side and on the health system's side.
What can the checklist not tell you?
- Whether a specific health system will approve your app, or which APIs it has enabled.
- Epic's current program terms, fees or listing requirements. Check open.epic.com and Showroom directly.
- A price or a timeline. Both depend on the customer's configuration and team, and we work them out on a scoping call.
Facts and sources
What do Epic and the standards bodies say?
Short facts behind the checklist, each linked to its source.
Open@Epic describes itself as a resource for anyone looking to connect a healthcare app or service to providers using Epic software.
Source: Open@EpicEpic's FHIR developer site offers a testing sandbox for trying its APIs against example data, along with app registration and client ID management.
Source: Epic on FHIRThe HL7 SMART App Launch guide defines how apps launch from inside an EHR or standalone, and its Backend Services profile authorizes automated clients with no user present.
Source: HL7 SMART App LaunchThe ONC (ASTP) certification criterion for standardized APIs, 45 CFR 170.315(g)(10), references FHIR R4, the US Core implementation guide and the SMART App Launch guide.
Source: ONC (ASTP), HealthIT.govCDS Hooks is an HL7 specification for invoking decision support from within a clinician's workflow at points called hooks, such as patient-view and order-select.
Source: HL7 CDS Hooks
Related services
Which Agnotic services pick up from here?
Agnotic Technologies builds Epic and EHR integrations for digital health teams. These pages cover the build behind each phase.
EHR integration services
Integrations across Epic, Oracle Health (Cerner) and other EHRs.
SMART on FHIR app development
Apps that launch inside the EHR with the right scopes and patient context.
FHIR and SMART on FHIR development
FHIR APIs, data mapping and authorization built as part of your product.
HIPAA app engineering checklist
The security controls a health system's review will ask about.
Healthcare software scope builder
Put the integration into a full product scope.
Frequently Asked Questions
In practice, yes. A health system's Epic team decides what is enabled in its environment, and a clinical or operational sponsor who wants the integration is what moves it through their review and build queue. Find the sponsor before you invest in the build.
Yes. You can register an app and test against Epic's public sandbox with example data. Expect changes once you test in a customer's environment, because each health system's configuration and enabled APIs differ.
Use FHIR when your app reads or writes data on demand for a user or a patient. Use HL7 v2 when you need a real-time feed of events, such as admissions or results, through the health system's interface engine. Many products use both.
The number of FHIR resources and workflows, whether you need write access, how many launch types you support, the security review and how many customer environments you run in. We estimate after a scoping call, not from a checklist.
Not to work with one customer: the health system decides what it enables for its own use. A Showroom listing matters when you want other Epic customers to find your product. Check Epic's current requirements on its developer sites before you plan for one.