Epic Integration for Mobile Health Apps,
From Sandbox to Go-Live
An Epic EHR integration app connects your mobile health product to Epic, the most widely used EHR in US hospitals, so patient data, results and appointments flow securely between your app and the health systems that use Epic. Integration involves more than code: you need the right Epic programme, SMART on FHIR authorisation, a sponsoring customer and that customer's security and clinical approvals. We guide you through every step, from sandbox to production. Review the connection paths below, then book an Epic integration review with our team.
Book an Epic Integration ReviewHow It Works
How Epic Integration Works for Third-Party Apps
Epic offers several routes for third-party apps, each granting different access and requiring different commitments. Public FHIR APIs support many patient-facing and standards-based use cases. Epic's developer programmes, including Epic Showroom, which replaced the former App Orchard, cover broader access, listings and partnership options. Every production connection ultimately runs inside a health system's own Epic environment, so that organisation's approval is always part of the path. Understanding these layers prevents unrealistic launch dates.
Public FHIR APIs
Epic exposes standards-based FHIR R4 APIs, documented on its open.epic developer site, supporting US Core data and SMART on FHIR. Many patient-facing and read-focused apps start here. Documentation and sandboxes are freely available.
Developer Programmes
Epic's programmes, including Epic Showroom, offer listings, additional resources and, for some participants, access beyond public APIs. Terms, tiers and costs change, so confirm current details with Epic directly. Requirements differ by tier.
Customer-Specific Activation
Each Epic customer runs its own environment. Even approved apps typically need the health system to activate access, configure settings and complete internal security and clinical reviews. Plan time for each customer.
Former App Orchard
Many buyers still search for App Orchard. Epic replaced it with Epic Showroom, so older guidance referring to App Orchard pricing or processes should be treated as outdated. Check current Epic resources.
Connection Paths
Epic Connection Path Table
This table summarises the main routes for an Epic EHR integration app, what each grants, typical time to production and what the health system must sponsor or approve. Exact requirements depend on your use case, data scope and Epic's current programme terms, which change periodically. Treat timelines as indicative ranges based on typical projects. We confirm the current path with Epic and your target health systems during discovery before committing to dates.
| Path | What it grants | Typical time to production | Health system role |
|---|---|---|---|
| Patient-facing FHIR APIs (standalone launch) | Patient-authorised read access to US Core data | 1–3 months | Often light; may still require organisation approval |
| Provider-facing SMART on FHIR (EHR launch) | App launched inside Epic with user and patient context | 3–6 months | Sponsorship, security review, build and configuration |
| Backend / system integration | Server-to-server access for automated workflows | 3–9 months | Sponsorship, security review, scope approval |
| Write-back (observations, documents, questionnaires) | Create or update data in the record | 4–9 months | Clinical informatics review and explicit approval |
| Expanded access via Epic programmes | Additional APIs, resources or listing | Varies by programme | Usually a sponsoring customer |
Patient-Facing Apps
Patients sign in with their health system credentials and authorise your app. Read access to core data is the fastest path, though organisations may still review apps before allowing connections.
Provider-Facing Apps
Apps launched from within Epic receive user and patient context, so clinicians avoid separate logins. These require customer build work, security review and clinical approval before go-live. Build work varies by customer.
Backend Integrations
Server-to-server integrations support automated workflows such as syncing readings or appointments. They use system-level authorisation and typically require careful scope approval from each health system. Each site approves scopes separately.
Write-Back Scope
Writing observations, questionnaire responses or documents into Epic adds clinical value but needs explicit approval, validation and governance, because it changes the official medical record. Validation rules protect data quality throughout.
Approvals
Epic Approval Sequence
The approval sequence is where most Epic projects lose time. Buyers who have been through it know that coding is rarely the bottleneck; sponsorship, registration, security review and customer build are. The sequence below reflects a typical provider-facing integration. Patient-facing apps using public FHIR APIs may skip some steps. We map this sequence for each target health system early, so stakeholders know exactly who must act and when. Each step has an owner.
Step 1: Define Use Case and Scope
Document the workflow, users, FHIR resources, read or write needs and launch context. Precise scope speeds every later approval and prevents requests for access you do not need. Write it down clearly.
Step 2: Build in the Sandbox
Register your app on Epic's developer site and build against sandbox environments with test patients, validating authorisation, resource mapping and error handling before involving customers. Synthetic patients cover realistic edge cases.
Step 3: Secure a Sponsoring Customer
Identify the health system that will use your app. Its IT, security and clinical leaders become sponsors who champion approvals, configure their environment and support testing. Strong sponsors accelerate every later step.
Step 4: Register and Request Access
Complete Epic registration for production client IDs and any programme requirements. The sponsoring organisation then reviews and approves the requested scopes for its own environment. Scope requests should match Step 1 exactly.
Step 5: Security and Clinical Review
The health system reviews security controls, BAAs, data flows and clinical safety. Our HIPAA-compliant app development evidence pack helps answer these reviews quickly. Prepared answers often save several weeks of review.
Step 6: Customer Build, Test and Go-Live
The customer configures access in its Epic environment, then both teams test with real configuration. After sign-off, production access is enabled and monitored closely during early use. Hypercare support follows launch.
Technical Details
Technical Details for Epic Integration
Epic follows modern interoperability standards, but practical details still determine success. Authorisation, environment differences, rate limits and data variation between customers all affect design. Epic FHIR API work goes faster when these details are planned upfront rather than discovered during customer testing. These are the technical areas we address in every Epic integration, alongside the wider integration practices described on our EHR integration page. Each is planned during discovery. Nothing is left to chance.
SMART on FHIR Authorisation
Apps use OAuth 2.0 with SMART launch contexts and scopes. Mobile apps use PKCE, store tokens securely and request only the minimum scopes their features require. Token handling is tested carefully.
Environment Differences
Sandbox data is cleaner than production. Each customer configures Epic differently, so mapping, codes and available data must be validated in every customer's test environment before go-live. Budget time for this.
Combining FHIR and HL7
Some workflows still rely on HL7 v2 feeds alongside FHIR APIs. Our EHR integration app development team designs layers that combine both cleanly. Each source is mapped into one consistent model.
Multi-Site Scaling
Once one customer is live, later Epic sites move faster because patterns, documentation and evidence already exist. Our health apps for hospitals work plans for this scale. Reuse saves months.
FAQ
Frequently Asked Questions About Epic Integration
These answers cover what founders, product leaders and health system IT teams ask most about Epic EHR integration for mobile apps, including programmes, approvals, timelines and write access. Epic updates its programmes and terms regularly, so confirm current requirements directly with Epic and your target health systems. If you want help planning your path, contact our team for a practical integration roadmap. We will outline a realistic, sequenced plan. No obligation applies.
How do I integrate my app with Epic?
Start by defining your use case and scope, then build against Epic's public FHIR APIs in the sandbox using SMART on FHIR. For production, register your app, secure a sponsoring health system and complete its security and clinical reviews before it enables access in its environment.
What happened to Epic App Orchard?
Epic replaced App Orchard with Epic Showroom, which organises listings and partnership options differently. Guidance referring to App Orchard fees or processes is likely outdated. Check Epic's current developer resources for the latest programme structure, requirements and any associated costs.
Does Epic integration require a sponsoring health system?
Most provider-facing and backend integrations require a sponsoring Epic customer to approve and configure access. Some patient-facing apps using public FHIR APIs face lighter requirements, but organisations may still review apps. Plan for sponsorship early in your commercial strategy. Sponsors also help testing.
How long does Epic integration take?
Patient-facing read-only integrations can take one to three months. Provider-facing apps and backend integrations usually take three to six months or longer, and write-back can take up to nine months. Sponsorship, security review and customer build typically drive timelines. Code is rarely the bottleneck.
Can my app write data back to Epic?
Yes, for supported resources such as observations, questionnaire responses or documents, when the health system approves. Write access requires clinical informatics review, validation and governance because it changes the medical record. Expect additional approval steps compared with read-only access. Plan extra time.
Get Started
Book your strategy session
Free architecture review. Expert HIPAA compliance advice. No hard sell — just an honest conversation about your project.