You integrate a patient application with Epic mainly through Epic's FHIR APIs and the SMART on FHIR standard, registering your app in Epic's developer program and connecting to the data you are authorised to access. Epic supports standards-based integration, so you do not need a proprietary interface for most modern use cases. The core path is: register your app, authenticate with SMART on FHIR, request the FHIR resources you need, and test in Epic's sandbox before going live with a healthcare organisation that uses Epic.
This matters because Epic holds records for a very large share of US patients, so for many patient apps, Epic integration is the difference between a product that fits real clinical life and one that sits outside it. The path is well defined but has real steps, requirements and approvals. This guide walks through how it works, what you need, and where teams commonly get stuck.
How do you integrate a patient app with Epic?
You integrate by using Epic's FHIR APIs through the SMART on FHIR standard, after registering your application in Epic's developer program and getting the necessary access. Epic exposes patient and clinical data as FHIR resources, and your app requests them with the patient's or provider's authorisation.
There is no single magic switch, but there is a clear, standards-based route. The main decisions are which data (FHIR resources) you need, how your app is launched and authorised, and which Epic organisation you are connecting with, since access ultimately depends on the healthcare organisation that runs Epic, not only on Epic itself.
What is the standard way to connect to Epic?
The standard way is FHIR, the modern healthcare data API standard, accessed through Epic's developer program. Epic publishes FHIR APIs that expose patient and clinical data as resources such as Patient, Observation, Medication and Appointment, which your app reads (and in some cases writes) with proper authorisation.
Using the standard path matters. Building to FHIR and SMART on FHIR means your integration follows a supported, documented route rather than a fragile custom one, and it aligns with the same standards US regulations increasingly require. Epic provides sandbox environments and documentation through its developer program so you can build and test before connecting to a live organisation.
What is SMART on FHIR and how does Epic use it?
SMART on FHIR is a standard that lets an app authenticate and launch securely with an EHR, obtaining permission to access specific data. Epic supports SMART on FHIR, so your app can either be launched by a provider inside Epic or authorised directly by a patient, depending on the use case.
In practice, SMART on FHIR handles the "who are you and what are you allowed to see" part of integration. It uses standard authorisation (OAuth 2.0 and OpenID Connect) so that access is scoped and consented, the patient or provider grants permission, and your app receives a token to call the FHIR APIs. This is how a patient app gets safe, authorised access to Epic data without a bespoke security scheme.
Step-by-step: integrating your patient app with Epic
Here is the path we follow for a standards-based Epic integration. Steps and program specifics can change, so confirm against Epic's current documentation.
- Define your data needs. List the FHIR resources your app requires (for example Patient, Observation, Appointment).
- Register in Epic's developer program. Create your app record and configure it for the access mode you need.
- Choose the launch and access model. Patient-authorised access, or provider-facing SMART on FHIR launch inside Epic.
- Implement SMART on FHIR auth. Set up OAuth 2.0 and OpenID Connect to obtain scoped, consented access.
- Build against the FHIR APIs. Request the resources you need and handle the data in your app.
- Test in the sandbox. Validate behaviour and data handling in Epic's test environment.
- Coordinate with the Epic organisation. Work with the healthcare organisation to enable and approve production access.
- Go live and monitor. Move to production with the organisation's sign-off, then monitor and maintain.
The key thing to internalise: the code is only part of it. Access, the organisation's approval, and testing shape the timeline as much as development.
What do you need before you start?
You need a clear data scope, an Epic developer account, a security and consent model, and a connection to an organisation that runs Epic. Missing any of these is the usual reason integrations stall.
| Requirement | Why it matters |
|---|
| Defined FHIR resource scope | Determines access and effort |
| Epic developer program registration | The supported route to APIs and sandbox |
| SMART on FHIR auth (OAuth 2.0 / OIDC) | Secure, consented access |
| HIPAA-aligned architecture | Protects PHI the app receives |
| An Epic-using organisation to connect with | Production access depends on them |
| Testing plan | Sandbox validation before go-live |
Line these up early. The technical build is often quicker than getting access and organisational approval in place.
With Epic, the code is only part of the job. The data scope, the access model, and the Epic-using organisation's approval shape the timeline as much as development does.
Patient-authorised access vs provider-facing launch
There are two main ways your app connects, and choosing the right one shapes the whole integration. Patient-authorised access lets a patient grant your app access to their own Epic data, which suits consumer and patient-facing apps. Provider-facing launch uses SMART on FHIR to open your app inside Epic for a clinician, which suits tools used during care.
Pick based on who uses the app and where. A patient wellness or engagement app usually uses patient-authorised access, while a clinician decision-support or documentation tool usually launches inside Epic. Some products use both. The access model affects your auth setup, your approvals and your testing, so decide it early rather than late.
Common Epic integration mistakes
Most Epic integration pain comes from a few avoidable errors. Watch for these.
- Starting to build before defining the data scope. The FHIR resources you need drive everything.
- Underestimating organisational approval. Production access depends on the Epic-using organisation, not only on Epic.
- Skipping the sandbox. Testing in Epic's sandbox first prevents costly surprises.
- Weak security. PHI from Epic must sit on HIPAA-aligned architecture with proper auth.
- Choosing the wrong access model. Patient-authorised and provider-launch are different builds.
- Assuming it is all coding. Access and approvals shape the timeline as much as development.
The pattern: succeed by defining scope, using the standard FHIR and SMART path, and planning access and approvals early.
How do you get started?
Start by defining exactly which Epic data your app needs and how it will be launched, then register in Epic's developer program and build against the sandbox. Do not wait for a live organisation to begin; you can design and test the integration first.
A practical first step is scoping the FHIR resources, the access model and the security design into a clear integration plan, then coordinating production access with the Epic-using organisation. This is how we approach EHR and FHIR integration: use the standard, secure path, test early, and manage the access and approvals that shape go-live.
Conclusion
Integrating a patient app with Epic is a standards-based process built on FHIR and SMART on FHIR: define your data, register in Epic's developer program, implement secure authorisation, build against the FHIR APIs, test in the sandbox, and go live with an Epic-using organisation. The path is well documented, but access, approvals and testing shape the timeline as much as the code.
Get the data scope and access model right early, build on HIPAA-aligned architecture, and use Epic's supported standards route, and your integration will be far smoother. If you want help integrating your app with Epic, talk to our team and we will map it with you.
Key takeaways
- Epic integration for patient apps runs through Epic's FHIR APIs and the SMART on FHIR standard, via Epic's developer program.
- SMART on FHIR handles secure, consented access using OAuth 2.0 and OpenID Connect.
- There are two main access models: patient-authorised access and provider-facing launch inside Epic. Choose early.
- Production access depends on the healthcare organisation that runs Epic, not only on Epic.
- Test in Epic's sandbox before going live, and build on HIPAA-aligned architecture.
- A focused Epic integration typically takes 6 to 12 weeks, with access and approvals a big factor.
- Define your FHIR resource scope first; it drives access, effort and timeline.
