Epic FHIR Integration: What It Actually Takes to Connect a Third-Party App
An Epic FHIR integration, connecting a healthcare application to Epic, can look simple from the outside. For the practical steps, see how to connect your app to Epic EHR using FHIR APIs.
Epic provides FHIR APIs. SMART on FHIR supports authorization. There is also a developer sandbox where teams can test their application.
So it is easy to assume that an engineering team only needs to build the API connection and move the application into production.
That is where many Epic FHIR integration projects become more complicated than expected. Before committing resources, it's worth understanding the true cost of FHIR integration, build versus buy, up front.
A successful sandbox connection is not the same as a production integration. Health systems may have their own configuration requirements, workflows, security expectations, testing processes, and deployment requirements.
For health-tech companies, understanding these requirements before development starts can help reduce rework and integration delays.
This guide explains what an Epic FHIR integration actually involves, where teams commonly underestimate the work, and what the path from sandbox development to production can look like.
Why "Epic Has an API" Is Only the Beginning
Epic provides a broad collection of APIs based on healthcare interoperability standards such as FHIR.
But access to an API does not automatically mean an application is ready to work inside an Epic customer's environment.
There are several stages that teams often combine into one.
The first is development. Your team needs to determine which FHIR resources the application requires, what scopes are needed, and how authentication will work.
The second is testing. Epic provides developer resources and a sandbox that can help teams build and test applications. However, sandbox testing does not necessarily reproduce every detail of a customer's production configuration.
The third is customer-specific integration. A health system may need to configure the application, determine how it will launch, establish the authorization model, and test the workflow with its own Epic environment.
The fourth is production readiness.
This is why Epic FHIR integration should be treated as an integration project, not simply an API connection.
For development teams starting their research, Epic on FHIR provides Epic's official developer resources, documentation, and sandbox information.
What the Epic FHIR Integration Timeline Looks Like
There is no single timeline that applies to every Epic integration.
The duration depends on the application's workflow, FHIR resources, authentication requirements, customer configuration, testing requirements, and whether additional interfaces are required.
A project can generally be divided into these phases:
Sandbox testing is an important milestone, but it cannot replace customer-specific testing.
What SMART on FHIR Actually Requires
SMART on FHIR provides a standardized framework for applications to obtain authorization and access FHIR data in a controlled way. It builds on OAuth 2.0 and supports different application launch patterns.
The official HL7 SMART App Launch documentation explains the authorization and launch framework used by SMART-enabled applications.
An application may need to know:
- Which patient is being viewed
- Which encounter is active
- Which user launched the application
- Which FHIR resources the application can access
- Whether the application is launched from the EHR or independently
EHR Launch vs Standalone Launch
With an EHR launch, the application is launched from within the clinical workflow. The EHR provides launch information that helps establish the session context.
For example, a clinician may open an application while viewing a specific patient.
A standalone launch works differently. The application starts independently and initiates the authorization process. Depending on the workflow, the user may authenticate and select the appropriate patient or context.
These approaches can result in different implementation requirements.
Patient Context and FHIR Resources
Healthcare applications usually need more than a simple Patient resource.
Depending on the product, an application may need:
- Patient
- Observation
- Condition
- MedicationRequest
- AllergyIntolerance
- DiagnosticReport
- Encounter
- Procedure
The exact resources depend on the application's workflow.
Retrieving a Patient resource is different from determining which patient a clinician is currently working with. That is why SMART launch context matters.
FHIR provides the underlying interoperability framework and resource definitions. The official HL7 FHIR specification provides the technical reference for these resources.
OAuth 2.0 and Scopes
SMART on FHIR uses OAuth 2.0 based authorization patterns.
Scopes define what access the application is requesting. These should be designed around the application's actual requirements.
An application that only needs demographic information should not automatically request broad clinical access.
Authentication and authorization should therefore be considered part of the architecture from the beginning.
For teams reviewing the underlying authorization model, OAuth 2.0 at IETF provides the formal OAuth 2.0 specification.
Common Epic Integration Problems
Epic integration projects do not usually become difficult because an engineering team cannot send an HTTP request.
The harder problems often involve workflow, authorization, configuration, and assumptions.
Treating the Sandbox as Production
A sandbox is useful for development, but it should not be treated as a complete representation of every customer's Epic environment.
Production environments may have customer-specific configuration, security requirements, workflows, endpoints, and testing expectations.
Requesting Excessive Scopes
The application should request the permissions required for its actual workflow.
Overly broad scopes can create unnecessary authorization and security concerns.
Designing Authentication Too Late
Authentication affects application launch, session management, token handling, patient context, user identity, and API requests.
SMART on FHIR should therefore be part of the architecture from the beginning.
Hard-Coding Configuration
Endpoints, client identifiers, scopes, environments, and customer-specific settings should not be scattered throughout application code.
A configurable architecture makes it easier to support different healthcare organizations and environments.
Ignoring the Clinical Workflow
A technically correct API integration can still create a poor user experience.
An application launched from an EHR should account for the context available at launch and avoid unnecessary authentication or patient-selection steps when the workflow already provides that information.
Involving the Health-System Team Too Late
The health system may need to participate in configuration, testing, workflow validation, security review, and deployment planning.
Waiting until the application is finished before involving the customer can create avoidable rework.
What a Realistic Epic Integration Project Looks Like
A realistic project usually starts with discovery rather than coding.
The first question should not be:
"Which Epic API should we call?"
It should be:
"What exactly does the application need to do inside the Epic workflow?"
Phase 1: Discovery
The team defines the application's workflow, users, launch method, required patient information, FHIR resources, read or write access, SMART launch model, and customer-specific configuration.
Phase 2: Sandbox Development
The engineering team can then build SMART authentication, OAuth 2.0 flows, FHIR API requests, resource parsing, patient and encounter context, token management, error handling, and environment configuration.
The objective is to establish a repeatable integration architecture rather than simply prove that one API request works.
Phase 3: Customer Pilot
Once the application is technically ready, the health-system environment becomes important.
The customer may need to configure the application and validate the intended workflow. Differences between the testing environment and the customer's actual configuration can become visible at this stage.
Phase 4: Production Preparation
Before deployment, the team should review security controls, authentication, authorization, scopes, FHIR resources, logging, data retention, customer configuration, monitoring, documentation, and support procedures.
Production readiness is not just a technical checkbox. The application needs to be operationally ready for the environment in which it will be used.
What About Epic App Orchard?
Epic's App Market and developer ecosystem can be an important part of bringing third-party applications into the Epic environment.
However, "App Orchard integration" should not be treated as one universal certification step that replaces all other integration work.
The exact process depends on the application, integration type, Epic customer, and deployment model.
Customer-specific configuration and testing may still be required.
For health-tech companies, the better approach is to identify the exact Epic integration and production path during discovery instead of assuming that every application follows the same process.
Teams should confirm the applicable requirements through Epic's official developer documentation rather than assuming that one process applies to every application.
Frequently Asked Questions
How much does Epic FHIR integration cost?
There is no single price.
Cost depends on the application's scope, number of FHIR resources, read and write requirements, SMART implementation, authentication model, customer configuration, testing, and any additional interfaces.
A simple read-only application and a complex clinical platform should not be expected to require the same effort.
How long does Epic FHIR integration take?
There is no universal timeline.
A proof of concept can be developed much faster than a production-ready integration requiring customer-specific testing, workflow validation, security review, and deployment preparation.
Teams should separate the sandbox development timeline from the production deployment timeline.
Do we need an Epic expert on our team?
Not necessarily.
A health-tech company can work with an experienced healthcare integration partner for the Epic-specific interoperability work.
However, the product and engineering team still needs to clearly define what the application does, which data it requires, who uses it, and how it should fit into the healthcare workflow.
Can we build against the Epic sandbox and immediately go live?
Not necessarily.
Sandbox development is an important milestone, but production deployment may require customer-specific configuration, testing, workflow validation, and production-readiness steps.
Does every Epic integration require App Orchard certification?
Not every Epic integration should be described as having one universal certification requirement.
The applicable process depends on the application, integration type, Epic customer, and deployment model.
Teams should confirm the exact requirements for their intended integration instead of assuming that one certification process applies to every project.
Conclusion
Connecting a third-party application to Epic involves much more than connecting to an API.
FHIR resources, SMART on FHIR, OAuth 2.0, patient and encounter context, authorization scopes, customer-specific configuration, testing, and production readiness can all become important parts of the integration.
For organizations building applications that need to work with Epic, understanding these requirements early can help reduce integration delays and avoid rework during customer testing.
A successful sandbox connection is an important milestone, but production readiness requires the application to work securely within the intended healthcare workflow and the customer's Epic environment.
For organizations planning an Epic integration, Aishco Solutions brings expertise in healthcare interoperability, FHIR integrations, SMART on FHIR, healthcare APIs, and enterprise integration projects.
