Epic EHR/EMR Integration Guide: FHIR, APIs, Cost, and Challenges

Updated October 2026

You’ve got a health app that needs data out of Epic: Epic EHR integration, often called Epic EMR integration, is how it gets there, and the 21st Century Cures Act final rule made Epic’s USCDI FHIR APIs free for developers to read patient data.

What is Epic integration?

Epic integration connects a third-party app to a health system’s Epic EHR so the two can exchange patient data through Epic’s FHIR R4 APIs, SMART on FHIR, Bulk FHIR or HL7 v2 feeds. The how in one line: register free on Epic on FHIR, build in Epic’s sandbox, and each Epic customer approves your app before go-live.

Key takeaways:

• Epic’s USCDI on FHIR APIs give developers free, read-only access to standard patient data. Use them for apps that display clinical records or run analytics.
• Write-back is limited and depends on what each health system enables. Confirm the required writes before you scope the build.
• Build OAuth 2.0 with PKCE and least-privilege scopes into your app. Plan for each target health system’s security review and deployment requirements.

Epic integration at a glance

Facts checked September 2026. Cost and timeline are Topflight’s planning ranges; other facts come from Epic’s documentation and ONC.

Table of contents:

1. What Epic integration actually means
2. Benefits of Epic EMR/EHR integration
3. Common use cases for Epic integration
4. Challenges and limitations of Epic API integration
5. How to integrate with Epic EHR
6. 2026 considerations when integrating your mobile app with Epic EHR
7. Epic integration timeline and cost
8. Topflight’s Epic EHR integration services
9. Let’s build a health app that connects to Epic EHR
10. Glossary of Epic integration terms
11. Frequently asked questions

What Epic integration actually means

Epic integration (often called Epic EMR integration or Epic EHR integration) connects a third-party app to a health system’s Epic EHR so the two can exchange patient data, usually through Epic’s FHIR R4 APIs, SMART on FHIR launches, Bulk FHIR exports or HL7 v2 feeds. Developers register free on Epic on FHIR, and each health system approves the app. A production integration typically takes 6 to 12 months and $50K to $200K+ (Topflight planning range).

What is the Epic USCDI API?

USCDI stands for United States Core Data for Interoperability. It’s the federal standard that says which classes of health data a certified EHR has to be able to share through its APIs so other apps can read them. ONC maintains it, and it’s the baseline for nationwide health data sharing.

The Epic USCDI API is that standard turned into endpoints: the rules for pulling USCDI-formatted health records out of Epic.

FHIR (Fast Healthcare Interoperability Resources) is the format those records travel in: HL7’s standard for exchanging health data as defined units called resources, most often through a RESTful API. As of September 2026, certified EHR APIs in the US must support FHIR R4 with the US Core 6.1.0 profiles (45 CFR 170.215), which makes data from different EHRs more consistent. Codes, optional fields and extensions still differ between vendors and between sites, which is why Epic interoperability work still needs per-site checks.

Open.epic lists over 750 no-cost APIs and interfaces, including its USCDI v3 FHIR APIs, and FHIR APIs for the newer USCDI v5 data set are under development.

USCDI v3 replaced v1 on January 1, 2026 as the version ONC’s certification rules require (45 CFR 170.213; see ONC’s USCDI page). Epic’s certified API has used v3 since its August 2024 version, so a site still on an older Epic version may expose only the v1 set.

Since March 2025, ONC has used enforcement discretion to let certified products leave out v3’s sexual orientation and gender identity elements (ONC’s SVAP page), and its pending HTI-5 proposal would make USCDI v3.1 the required version.

And the reason any of this is worth your time: KLAS Research’s US Acute Care EHR Market Share 2026 report (May 2026) found Epic was one of only two acute care EHR vendors to gain net market share in 2025, and both health systems with more than 10 hospitals that made enterprise-wide EHR decisions that year chose Epic. KLAS had reported in May 2024 that Epic covered more than half of US acute care multispecialty hospital beds, so if your customers are hospitals, a lot of them run Epic.

Epic integration is really four different builds

What you build when you integrate with Epic depends on the data you need and which direction it moves. Four distinct paths sit under the same “Epic integration” umbrella:

• Read clinical data via USCDI on FHIR. Pull labs, meds, problems, vitals, and demographics into your app. Free and read-only, the usual starting point.
• Launch from inside Epic via SMART on FHIR. Your app opens in the clinician’s chart with patient context already passed in, so it feels like part of Hyperspace.
• Export populations via Bulk FHIR (Flat FHIR). For cohort reporting or payer programs, start one asynchronous export for a patient group and download the files, so one export job replaces thousands of single-patient calls.
• Take event feeds via HL7 v2. For ADT events and order or result messages as they happen, Epic recommends event-driven interfaces, most commonly HL7 v2, sometimes routed through an engine like Mirth.

A read-only telehealth view and a population-analytics pipeline are different builds with different approval paths, even though both count as integrating with Epic EHR. Scope the path before you scope the timeline.

For a narrow administrative task with no usable interface, robotic process automation in healthcare can operate an approved screen under the health system’s access policy.

Pick the path before you set a budget, because it decides what you will be waiting on from each health system.

Every Epic site is configured a little differently

Each Epic customer configures its own site, so the same app can behave differently from one hospital to the next.

In a September 2026 spot check of 11 Epic customer endpoints, versions ran from May 2024 to May 2026, while Epic’s sandbox ran August 2026.

FHIR versions are mixed. A single Epic server serves DSTU2, STU3 and FHIR R4 APIs side by side, and Epic’s catalog still lists older versions of some APIs, so check the version of each API you call and build against R4 where it exists. USCDI support lags too: Epic’s certified USCDI v3 APIs start with its August 2024 version, and each customer upgrades on its own schedule, often 3 to 12 months (sometimes more) after Epic’s release.

Then there’s approval. Each Epic customer decides which apps connect to its own instance, on its own timeline, regardless of any certification you already hold. And the sandbox you tested in won’t match production exactly, since identifier systems, flowsheet rows, security setup and patient-facing data filters can all differ by organization.

All of this is workable, as long as you count each Epic site as a separate integration: the next hospital is a fresh configuration cycle. That site-by-site reality turns Epic systems integration into an ongoing program, so plan for the multiplier from day one.

Epic vs. Oracle Health (Cerner) vs. athenahealth: how integration differs

Epic, Oracle Health (formerly Cerner) and athenahealth all certify FHIR R4 APIs to the same federal criterion, and they split on who pays for API access and how much you can write back.

Sources: each vendor’s developer documentation and ONC’s Certified Health IT Product List. Fees and certification details checked September 2026. Certification covers a product version, so confirm what each customer site runs.

On TEFCA, Epic customers connect through Epic Nexus, and Oracle runs its own QHIN, Oracle Health Information Network, designated in November 2025. For the Oracle side in depth, see our Oracle Health vs Epic comparison; for athenahealth, our athenahealth integration guide.

Benefits of Epic EMR/EHR integration

Epic integration gives your app current clinical records and lets clinicians use them across departments, reducing duplicate entry and gaps in care.

1. Reduce data silos across healthcare departments

When radiology, lab, and pharmacy all read from the same Epic record, your app stops being one more login. Pull from Epic as the source of truth and a clinician sees current data in your tool without bouncing between systems. Better care coordination falls out of that: everyone works from the same chart.

2. Improve clinical outcomes with better data continuity

Structured, current records are what make downstream clinical decision-making any good. Feed an app fresh labs and problem lists and your risk scoring or treatment-plan logic has something real to work with. That data continuity lets a model nudge patient outcomes; on stale snapshots, it’s guessing.

3. Minimize manual entry and improve data exchange

Every field a clinician re-keys is a chance to introduce an error and a reason to dislike your app. Reading structured data straight from Epic over FHIR removes whole categories of manual entry: chart updates populate automatically from Epic, and medication and allergy lists arrive structured.

4. Enable interoperability and workflow automation

Build on Epic’s FHIR APIs and you’re building on the same standards every other modern EHR is adopting, so the work travels. Shared standards turn a one-off connector into something you can extend to Cerner or athenahealth later, and CDS Hooks let you surface alerts and recommendations right where clinicians already work. That’s the core of Epic automation, and it’s where clinicians actually feel the integration.

5. Improve patient engagement via Epic MyChart

MyChart is Epic’s patient portal, and it’s also the easiest on-ramp for patient-facing features: patients sign in with their MyChart credentials to authorize your app, then view test results, request prescription renewals, schedule appointments and message their care team in one place. Where an organization sets up a launch from inside MyChart, your app sits right next to those tasks, so patients stay engaged with their care between visits. If you build a doctor appointment app that writes bookings into Epic, verify which operations the health system enables before you commit to the patient flow.

Common use cases for Epic integration

The free USCDI on FHIR read path covers a specific shape of product: provider-facing apps that need to read standard patient data and never write anything back. An integration with Epic built just to read is the cheapest, fastest way in.

A read-only integration with Epic EHR is the right call when:

• you’re building a provider-facing app that pulls fairly standard data from the Epic electronic medical records: medications, allergies, conditions, demographics, test results
• you want that data cheaply and want it to grow across sites without per-call fees
• you don’t need to launch your app from inside Epic
• you don’t need to push data back into Epic

Two builds where it lands cleanly. One is a telehealth app that pulls a patient’s record in mid-visit, so a remote provider sees current meds, problems, and recent labs without the patient reciting their history. Read our telehealth EHR integration guide for the deeper version.

The other is a patient management app with a simple interface that tracks treatment plans over time. It pulls the initial clinical picture (medication status, test results) when a record is first reviewed, then keeps watching for changes.

Here’s a screenshot from an MVP we built to show how little it takes to stand up a simple Epic-connected app on USCDI on FHIR.

You search for a patient, then view her record: previous diagnoses, prescribed medications, care plans, plus demographics pulled in through the integration. Use it in a remote encounter, or feed it into any downstream processing.

Start with the read-only workflow your product needs; add SMART launch or bulk export when the use case calls for it. If you want yours scoped against your actual product, see our EHR integration services.

Challenges and limitations of Epic API integration

Epic API integration’s friction is predictable: write-back limits, per-customer governance and authentication, and no two Epic sites behaving the same. Know the boundaries up front and you design around them; find them in production and you eat the rework.

Site-specific approvals and governance

Epic uses a federated model: every customer runs its own Epic instance and decides which apps connect to it. For clinician-facing, backend and write-capable apps, each customer requests your client ID and signs off on its own timeline, no matter how many sites you’ve already cleared or what certifications you hold. Governance lives with the customer, so the same app can clear fast at one site and stall at another.

Larger health systems route it through their own IT governance, and approvals vary across institutions even inside one network. Plan for a per-customer approval cycle.

Patient-facing apps add a wrinkle. Patients sign in with their MyChart credentials at each organization, and a patient without a MyChart account there can’t authorize your app this way. Even when they have one, you’re asking patients to remember and use those credentials, which is its own adoption tax. And patient-facing responses are filtered, so confirm what’s actually available before you promise a feature.

Read-only patient-facing apps that use only qualifying USCDI APIs skip the per-site request: Epic distributes them automatically to customers that license those APIs and haven’t turned auto-download off. Patient-facing apps that write data or call other APIs go through each Community Member’s own review, and those timelines swing widely with app type. Don’t put a fixed turnaround on the roadmap.

“Your implementation timeline is going to be 90% waiting for the health system to approve your integration and 10% doing, and that 10% can take two weeks to 90 days.”

Scott Rossignol, who led EHR integration at Topflight

Authentication, scopes, and app registration

Epic’s troubleshooting guide traces 403 errors on API calls to an API that isn’t on your client record or hasn’t synced yet, a scope error flagged as insufficient_scope, one person’s access token used on another person’s behalf, or the organization’s own user security checks. API list changes take up to an hour to reach Epic’s sandbox and up to 12 hours to reach a customer’s Epic instance.

When sign-in fails at the authorize step, the guide’s checks cover redirect URIs that don’t match exactly (they’re case sensitive), a client ID mismatch, a response_type other than code, and a missing aud parameter. For backend apps, Epic says the error developers hit most often is a 400 invalid_client response.

Decide up front whether you need user-level or system-level scopes, since they’re approved and behave differently, and keep your consent screens and audit trails documented from day one. Reviewers ask for them.

Direct database access takes two approvals: Epic’s open.epic terms say developers don’t need direct access to Epic software, and it can be granted only with approval from both the health system and Epic. If you want your own SQL against a customer’s Epic reporting databases, Epic licenses its Kit and Clarity data models through Vendor Services, and each customer still has setup work to do.

Data availability and workflow limits

Epic’s USCDI APIs are read-only. Through FHIR you can pull demographics, problems, lab results, medications, clinical notes, and vital signs, then build whatever sits on top, like population health dashboards and risk scoring. That’s the most common case, and it’s well supported.

Outside USCDI, Epic’s public FHIR APIs let apps file vital signs and plain-text clinical notes and add allergies or problems, which wait in a holding area until a clinician reconciles them. None of those write APIs sits in Epic’s USCDI group, so each health system decides whether to license and enable them for your app.

A deeper integration with Epic EMR that needs to place real orders or keep two systems in live sync usually adds an HL7 v2 interface the health system configures on top of these APIs. Here’s what the public APIs won’t do:

• place signed orders (labs, meds); outside specialty cases such as radiation oncology, Epic’s catalog creates orders only as unsigned CDS Hooks suggestions a clinician reviews and signs, with order details filled from the health system’s defaults
• continuous, real-time bidirectional sync; you get near-real-time or periodic, so architect for async and event-driven updates
• override Epic’s native workflows like medication reconciliation or problem-list management
• deeply customize Epic’s UI; the chrome stays Epic’s, and your app can launch via SMART

Every write your app needs depends on a yes from each target health system, so ask for it early in onboarding.

For analytics, pull large volumes through Bulk FHIR (Flat FHIR), which Epic supports from its August 2021 version and only for patient groups that each health system defines and authorizes for your app. By default you can request the same group once every 24 hours, and Epic lists incremental loads and data warehouse sync as poor fits for Bulk FHIR.

Patient matching is the other quiet trap. Epic says MRNs and FHIR IDs are unique only when you store them with their identifier system, such as the site’s FHIR base URL, so keep each health system’s patient records apart.

When your app searches for a patient, Epic strongly recommends requiring first and last name, legal sex, date of birth and at least one more identifier, and for patient-facing and backend apps it says to fail the match when more than one record comes back; Patient.$match returns at most one. Across health systems, we’d run EMPI patient matching that blends deterministic and probabilistic rules, and keep an eye on the false-match rate.

And across infrastructure that old, billing and specialized coordination sometimes still need their own interfaces alongside the FHIR read.

Rate limits, testing, and production readiness

Before go-live, test every API at realistic volumes in each customer’s non-production environment and account for these production limits:

• Load limits and pagination. Epic’s App Developer Guidelines ask apps to use no more than 1% of a customer’s Epic database resources during peak hours, typically 7 a.m. to 7 p.m. local time, and no more than 5% off-peak, and none of the Epic docs we checked lists a per-request rate limit or an HTTP 429 response. Cap and stagger your calls, and follow each next link, since Epic pages any search over 1,000 results.
• Incremental updates. Epic’s FHIR APIs don’t support _lastUpdated and its Bulk FHIR export doesn’t support _since, so build incremental updates on event-driven HL7 v2 feeds or on the date filters individual APIs support.
• Sandbox testing only gets you partway. Epic’s docs say identifier systems, flowsheet row IDs, backend-app security setup and patient-facing data filters can all differ by organization, and Epic upgrades its sandbox each quarter while customers upgrade on their own schedule. Keep per-site configs behind feature flags, and test each API in every community member’s own non-production environment, usually its TST environment, at realistic call volumes before go-live.
• Data hygiene at ingest. FHIR requires a time zone offset on any dateTime that includes a time, so store timestamps in UTC alongside their original offset and leave date-only values as dates. US Core expects numeric vital signs and lab results in UCUM units, so check units at ingest and convert any non-UCUM value before you store it.
• Per-site go-live. Each customer is its own production cutover, so a “done” integration is really done once, then repeated per site.

This is the work that separates a demo from something a hospital will run in production, where every interaction with the live system has to be predictable and logged. Bring in an experienced team early. It costs less than discovering these in a go-live week.

Best practices for working within Epic limitations

Every limit above is workable if you build with it in mind. Five habits that keep an Epic integration out of trouble:

1. Complement Epic’s native functionality

Build your app to sit alongside the core EHR and let Epic keep the jobs it already does. Providers want a clean handoff between your tool and Epic. Make them bounce between conflicting screens and they’ll quietly stop using you.

2. Plan for asynchronous data flows

Epic’s public FHIR catalog has no general subscription or webhook API, so design for async from the start. Lean on event-driven HL7 v2 interfaces, which Epic calls one of the best tools for keeping systems in sync in real time, so your app refreshes when something actually changes.

3. Stick to open standards

Stay on FHIR and HL7 wherever you can. Standard data exchange keeps you compatible across sites and makes the jump to another EHR far less painful later.

4. Engage Epic and your IT team early

Sort out permissions and constraints before anyone writes code. The teams that loop in the customer’s IT and clinical owners early, plus Epic’s own staff if they pay for Vendor Services, hit far fewer surprises mid-build.

5. Focus on data presentation over direct write-back

Most of the value you can deliver comes from reading Epic data and presenting it well. Surface the clinical summaries and risk scores that sharpen decision-making, and let Epic stay the system of record. That single choice sidesteps a huge share of the approval and compliance friction.

Stick to these and you get less clinician friction and a build that stays inside Epic’s compliance lines.

How to integrate with Epic EHR

How to integrate with Epic EHR: register your app for free on Epic on FHIR, build and test against Epic’s FHIR R4 APIs in the public sandbox, then bring each Epic customer to its own go-live. Epic’s step-by-step Developer Guide on open.epic covers the same ground, and every Epic EMR integration follows the same 7 steps below.

1. Scope the build: pick your path (USCDI read, SMART on FHIR launch, Bulk FHIR export or HL7 v2 feeds) and list the FHIR resources and APIs your product needs.
2. Check each site’s Epic version: a site’s public FHIR metadata endpoint usually reports the version it runs.
3. Register your app: create a free Epic on FHIR account at fhir.epic.com and register the app, which gives you one non-production and one production client ID to use with every Epic customer. The open.epic.com login, used for documentation access and updates, is a separate sign-in.
4. Build and test in the sandbox: Epic’s public sandbox refreshes every Sunday evening and erases the prior week’s test data, so script your test-data setup.
5. Get each customer to install it: the health system (Epic calls it a community member) signs the open.epic API Subscription Agreement once and downloads your client ID; apps that use client secrets supply one per customer and environment.
6. Test in each customer’s environment: Epic advises testing every API in the customer’s non-production environment, usually its TST environment, at realistic call volumes before go-live.
7. Go live site by site: each customer is its own production cutover, and an optional Connection Hub listing opens up once your first customer is live.

What data can you access through Epic APIs

USCDI sets the minimum data certified EHR APIs must support. ONC has published a new USCDI version every July since 2021, most recently v7 on July 23, 2026, and the required baseline changes only through rulemaking: as of September 2026, ONC’s certification rules (45 CFR 170.213) require USCDI v3. The Epic EHR API surface starts with that set, and Epic’s USCDI APIs on FHIR cover:

• Observation (Vitals): vital signs
• Observation (Labs): lab results
• DiagnosticReport: result reports for lab, imaging, cardiology and endoscopy orders, with the report text and discrete result values (scans filed into Epic aren’t returned); Epic’s Media and Binary (Study) APIs return key cardiology and endoscopy images linked from a report
• DocumentReference and Binary: clinical notes from clinical staff
• MedicationRequest: prescribed medications
• AllergyIntolerance: a patient’s allergies and intolerances
• Condition: problem-list entries
• Procedure: surgeries, endoscopies, biopsies, physiotherapy, and similar
• Patient: demographics and other administrative info
• Immunization: vaccines and administration details
• Device: implantable device info, the foundation for medical device EHR integration

Epic API integration on the USCDI tier is read-only: the APIs cost developers nothing, and each health system that turns them on licenses them from Epic. Write APIs sit outside the USCDI group, so a customer may license them separately. What’s enabled varies by API and by community member.

Confirm what your target site actually exposes early in onboarding. When the read-only tier stops short of the workflow you need, the next question is what it takes to build an EHR system you control.

What you need to integrate a health app with Epic

Three pieces, at minimum:

• a server running your app, whether that’s an AI app analyzing patient data to surface a preliminary read, or a simple tool that displays readings and links to resources
• the FHIR integration itself: a REST API that uses OAuth 2.0 to authorize your app, plus OpenID Connect when you need to know who signed in
• your app registered on Epic on FHIR (fhir.epic.com)

The real work is the middle one: the data exchange layer between your app and Epic’s backend. If you’re adapting Epic itself to your workflows rather than the other way around, see our guide to Epic customization.

You register the app, and get its client IDs, through a free Epic on FHIR account at fhir.epic.com. Showroom, Epic’s website for products that work with Epic, is a separate thing: its Epic Connection Hub section lists apps already live with at least one Epic customer. Once registered, your app can run on its own against Epic over the API, or launch inside Hyperspace, Epic’s clinician-facing application.

Epic FHIR API implementation guide

Epic FHIR API integration starts with an endpoint-and-scope matrix for each target site. Scope the USCDI resources your product needs, then check which FHIR versions each API offers and what each site has enabled. Build against R4 where you can, and gate the older DSTU2 and STU3 paths behind capability checks.

Define an endpoint-and-scope matrix per site so you’re not guessing what’s enabled where. Implement paging and real error handling for every interaction with Epic’s endpoints: plan around the 400 and 403 errors in Epic’s troubleshooting guide plus the 410 and 422 responses FHIR R4 defines, and cap and stagger your own calls.

Then test in each community member’s non-production environment, usually its TST environment, and keep a per-site conformance checklist so a new site is just another checklist run. That matrixing is the single biggest thing that keeps rework down as you add sites.

OAuth 2.0 authentication for Epic integration

Default to OAuth 2.0 PKCE: the Authorization Code flow with Proof Key for Code Exchange and the S256 method. HL7’s SMART App Launch v2 requires every SMART app to support PKCE. Epic’s OAuth 2.0 implementation has supported it since the August 2019 version of Epic, and Epic recommends it for native mobile apps (its OAuth tutorial recommends it for all apps).

Scope to least privilege. You register once and use the same client IDs with every Epic customer. Epic’s request-process guide asks for a different key or client secret for each customer and environment, though its OAuth tutorial lets a cloud-hosted app using private_key_jwt share one signing key across customers.

Epic’s App Developer Guidelines ask apps to keep persisted tokens in the operating system’s secure storage and enforce inactivity timeouts. Epic’s guidelines also call for regular token rotation.

For provider sign-in outside Epic, use the standalone launch defined in HL7’s SMART App Launch guide, which Epic describes in its OAuth 2.0 Specification. It runs on standard OAuth 2.0, so you avoid building and maintaining your own credential infrastructure. Where a site’s Epic version can’t use PKCE, Epic recommends Universal Links on iOS and App Links on Android for your redirect URI.

To keep a native or browser-based app signed in between sessions, Epic supports DCR (OAuth 2.0 client registration, RFC 7591). After the user signs in, the app creates a key pair on the device and registers the public key with that organization’s Epic server. The app then gets new access tokens with signed JWTs or refresh tokens for as long as the user approved. From the November 2021 version of Epic, an app that’s allowed to use DCR can find the registration endpoint in a site’s STU3 or R4 metadata by sending its client ID in an Epic-Client-ID header.

Epic Connection Hub and how the Epic Showroom listing process works

Showroom is Epic’s marketplace website. Epic’s Vendor Services FAQ lists four Showroom product tiers: Cornerstone Partners, Toolbox, Toolbox Under Construction and Connection Hub, and most listed apps sit in Connection Hub.

An Epic Showroom listing in Connection Hub costs $500 per product per year, according to Epic’s listing documentation, and it’s open only to products already in production use with at least one Epic customer. Toolbox is a designation Epic grants at its discretion, and it requires Vendor Services enrollment.

The order matters. Register your app on Epic on FHIR first; it’s free and gives you the client IDs every customer downloads. Match your privacy and consent copy to what users see at install, then build and test in each community member’s own environment until at least one customer is live.

Only then can you request a listing. The request is the attestation: you confirm your listing details and your live connection to an Epic system, and you agree to the $500 annual fee. Epic says you should hear back about payment within 15 days (Epic’s listing documentation, as of September 2026).

The listing is optional, since other Epic customers can connect without it. Epic’s listing terms say it isn’t an endorsement or certification, and its marketing guidelines suggest “listed in Epic Connection Hub” and ask vendors to avoid “Certified by Epic” and “Epic partner.”

What happened to Epic App Orchard?

Epic renamed App Orchard as App Market in 2022. In January 2023 it opened Connection Hub for app listings and moved App Market vendors into a new Vendor Services program, and Showroom launched in January 2024. The old App Orchard and App Market addresses redirect to Vendor Services, so if a hospital’s IT team tells you to “get listed in App Orchard,” that program no longer exists.

2026 considerations when integrating your mobile app with Epic EHR

Epic already ships mobile apps, including MyChart for patients, Haiku (iPhone and Android) and Canto (iPad) for physicians, and Rover for nurses. So before you build, ask whether you should. For a lot of teams the answer is yes, because the stock apps don’t cover the specific workflow they need, and the provider apps’ store ratings make the gap visible.

Store ratings as of September 18, 2026 (Apple App Store and Google Play). Canto and Rover each have fewer than 125 ratings per store.

Why build a custom mobile app on top of Epic

MyChart, Haiku, and Canto are built for the general case. They handle standard patient and provider workflows, and for plenty of organizations they’re enough. The reason to build your own is a use case they don’t serve: a condition-specific patient experience or a specialty provider workflow.

The provider-app ratings above are part of why teams consider it. When the default experience frustrates users, a focused custom app pulling the same Epic data can be a real upgrade for the people using it every day. Most of what you’ll need is documented in Epic’s developer FHIR toolbox and its step-by-step Developer Guide.

Define your mobile app’s data, workflows, and exchange direction

Three decisions up front save you from expensive rework later.

First, the data. Which resources does your app actually touch, and at what level of detail? Demographics and a medication list are a light lift. Full clinical history with attachments is a much bigger one.

Second, the direction. Will your app write back to Epic, or only read? On mobile that mostly means reading, given the write-back limits we covered. Answer it honestly now, because the answer shapes everything downstream.

Third, the workflows. Pin down exactly when the data exchange happens, say at scheduling or during an encounter. The workflow is what decides which APIs you call and when.

One mobile-specific note while you’re here: treat the phone as the edge of your PHI boundary. Store on-device data in the OS keystore or secure storage, and enforce inactivity time-outs.

Choose the right data exchange method for mobile use cases

For a mobile build, the use case usually picks the exchange method for you:

• reading clinical data into the app: USCDI on FHIR (R4) over REST, authorized with OAuth 2.0 and PKCE, the default for almost every mobile use case
• launching from inside Epic on a provider’s device: a SMART on FHIR Epic launch, so your screen opens with patient context already in hand
• population or cohort work: a Bulk FHIR job that runs on your backend
• event feeds (ADT, orders, results): HL7 v2 on the backend, surfaced to the app after your server processes it

The phone talks FHIR. Anything heavier, like bulk exports or v2 message processing, belongs on your server, with the mobile client reading clean, already-reconciled data. Keep that split clear and the app stays responsive and easier to secure.

How patient-facing FHIR responses can differ across Epic environments

If you’re building anything patient-facing, expect the same FHIR call to return different data at different sites, and sometimes for different patients. Epic filters some patient-facing responses, and customers can configure some of that filtering, so plan for variation.

What drives the differences:

• Responses are scoped to the authenticated patient, so what comes back depends on who’s logged in.
• Patient-entered data may not appear until a clinician reviews and reconciles it.
• Some responses use patient-friendly medication names, such as pseudoephedrine where a clinician sees the full order name.
• Certain lab results can be withheld under state and local rules.
• A site can turn that filtering off, in which case responses look more like the provider-facing version.

Because each customer configures this differently, Epic’s own advice is to test every API at each Community Member site before you go live. Budget for that testing per site, the same way you budget for per-site approval.

Supporting SMART Health Cards in mobile apps

If your app touches COVID-19 vaccine or lab result credentials, you’ll run into SMART Health Cards. They’re an open, interoperable standard built on HL7 FHIR and modeled on the JWT encoding in version 1.x of the W3C Verifiable Credentials data model. Epic generates them in a couple of ways.

Epic describes its SMART Health Card support as evolving. What your mobile app needs to handle:

• QR codes a patient pulls from MyChart, on screen or downloaded
• QR codes health system staff print from Hyperspace, typically for patients who don’t use MyChart
• QR codes shared from another device or printed on paper, so read both screen and paper reliably
• the .smart-health-card file itself, by associating your app with that extension so a download opens in your app

Get those input paths right and a patient can present a credential however they happen to have it, which is the whole point of the standard.

Cross-network exchange and TEFCA considerations

TEFCA gives patient-facing apps another route to Epic data through Individual Access Services (IAS). The first QHINs (Qualified Health Information Networks) were designated in December 2023, and health data began flowing among them within days, according to ONC.

The Sequoia Project, TEFCA’s Recognized Coordinating Entity, lists 11 designated QHINs. Epic customers connect through Epic’s own QHIN, Epic Nexus, which Epic says is currently open only to Epic community members (open.epic).

For patient-facing apps, TEFCA opens a second route to Epic data. An app that joins TEFCA through another QHIN and completes Epic Nexus’s client registration can use Individual Access Services (IAS) to request a patient’s records from Epic organizations that answer FHIR requests on TEFCA, after the patient verifies their identity and approves access through MyChart. IAS is the only TEFCA purpose Epic Nexus supports for outside FHIR apps, and for those patient apps it can stand in for integrating with Epic EHR site by site.

Adoption is real: Epic’s TEFCA tracker lists 2,165 hospitals and about 58,000 clinics using Epic as live on TEFCA for all purposes. ONC reported about 10 million documents exchanged through TEFCA before 2025 and 464 million by the end of 2025.

So track TEFCA in parallel with your direct Epic plan. For a patient-facing app built on IAS, it can be an alternative on-ramp to the per-site integration grind; plan any other kind of app on direct, site-by-site connections. If you want that decision checked against your actual Epic setup, send us the details.

Epic integration timeline and cost

A production Epic connection typically takes 6 to 12 months and $50,000 to $200,000+ in our planning estimates; scope and the number of sites drive the total.

Time and cost by phase

These are Topflight’s planning estimates by phase; program fees were checked against Epic’s pages in September 2026. Times and costs scale with complexity and with the number of sites.

What usually increases time and budget

Write scope and repeated site validation push projects toward the high end of the planning ranges.

Validation scales with what you’re building. A read-only FHIR app can clear in weeks. A bidirectional integration that touches clinical workflows takes months of back-and-forth with each health system’s governance and security review.

For apps on Epic’s standards-based APIs, Epic says you can register, connect and go live without Epic’s own involvement, and it recommends customers request a licensing estimate based on the APIs on your client ID.

Production multiplies. Each customer site needs its own setup, and for most apps its own approval, regardless of the certifications you hold, so each new system repeats part of the validation cycle. A “done” integration is done per site.

Budget the first site as a project and, for most apps, every later site as its own approval wait plus a short go-live.

Middleware is the main lever in the other direction. Redox’s implementation guide (last updated April 2026) says its average implementation runs about 6 to 10 weeks from kickoff to go-live, depending on scope and how quickly both teams move. Plan your own product build ahead of that kickoff.

As of September 2026, Redox’s pricing page lists a non-production Sandbox tier from $15,000 a year (companies under 500 employees) and production Core from $35,000 a year, with usage-based and managed-service fees on top. That’s a real line item, so model it against the engineering time it saves.

For a deeper look at cost drivers, see our EHR Implementation Cost Breakdown and epic ehr cost guides.

Topflight’s Epic EHR integration services

Our Epic integration services cover FHIR and HL7 development, security testing, and each customer’s go-live. As a healthcare app development company, we’ve shipped Epic integrations for the products below.

Products we’ve built have helped our partners raise over $200 million. A tight EHR integration is often what makes a health-tech product adoptable in the first place.

We’ve built GaleAI’s plug-in module for the athenahealth Marketplace and prepare apps for Epic Showroom and athenahealth Marketplace listing requirements, so we know the sandbox quirks and the checkboxes standing between you and clinical adoption.

Marketplace and listing experience

Once the build works, getting an app into a clinician’s hands is a listing and onboarding problem. We manage the whole path from Epic on FHIR registration to each customer’s go-live, and we prepare the Connection Hub and athenahealth Marketplace listing materials once an app has a live customer. When a listing or attestation needs to move, we’ve walked it before.

Deep Epic, FHIR, and HL7 delivery expertise

Real Epic work spans modern and legacy in the same project. Our engineers handle SMART on FHIR and R4 resources alongside the dusty HL7 v2 messages a lot of sites still run on, and they keep the data flowing without tripping an auditor.

Compliance and security built into delivery

The compliance work ships with the build. HIPAA, OAuth 2 with PKCE, SOC 2, audit artifacts: we handle the boring, necessary parts while you focus on the product. Retrofitting compliance is where healthcare budgets quietly blow up.

Faster time to market without reinventing the process

We’ve already built most of the integration playbook. Pre-built components and a process we’ve run many times mean you demo to clinicians while competitors are still stuck in vendor paperwork. Speed here buys time in front of clinical users early, while there’s still budget to act on what you learn.

Results from products we’ve connected to Epic and other EHRs

Two products we built and connected to EHRs, Epic included, and what came of them.

Roundr

Roundr is a React Native rounding app for hospitalists that we built and connected to Epic EHR using FHIR APIs, an HL7 v2 ADT interface and Mirth Connect. It’s designed for quick EHR access and clean charting on the move. The case study logs 700 hours over 9 months from prototype through EHR integration, and in testing early physician users said the app simplified their daily rounds.

GaleAI

GaleAI is an AI medical coding platform we built with SMART on FHIR support, and we worked with the GaleAI team on connecting it to EHRs such as Epic and athenahealth. It cut coding time by 97% and delivered up to 15% higher revenue from better coding accuracy. In a one-month audit, it found 7.9% more codes than human coders had, and that undercoding came to an estimated $1.14 million a year in lost revenue. GaleAI is listed as generally available in the athenahealth Marketplace.

Roundr used FHIR APIs and an HL7 v2 feed in the same build, so plan for both standards if your app needs ADT events as they happen.

What clients say

“Topflight Apps built my mobile app for iOS and Android and provided marketing services, transforming my initial concept into a functional, impactful tool.”

Josh Dégallier, MD, PhD, Founder and CEO of Roundr

“Topflight has been a complete end-to-end solution for helping us launch our software and get it into the hands of users as well as performing and integrating automated testing.”

Grant Muller, M.D., Co-founder & CTO, GaleAI

DIY vs. Topflight professional integration

If you’re weighing an in-house build against bringing us in, here’s the side-by-side.

When a Showroom listing is in scope, we prepare the Epic Connection Hub listing request once your first customer is live, while keeping your build moving.

Let’s build a health app that connects to Epic EHR

Epic’s free open.epic path gives you documentation, sandbox testing tools, a troubleshooting guide, a Technology Guidance form and an email contact for account and process questions. Hands-on technical and implementation help from Epic requires Epic Vendor Services (fees in the glance table), and you pay Epic representatives by the hour on top. Epic also suggests asking your customer’s IT team.

Hands-on help is our job. We get teams past the roadblocks the documentation doesn’t cover, including the data questions and medical device integration edge cases.

If you’re scoping an Epic connection, the details are where things go sideways: the parameters in your patient search API calls and the quirks in whatever API documentation you’re working from.

Tell us about your Epic setup and what you’re trying to build, and we’ll map the path.

Glossary of Epic integration terms

Twelve terms you’ll meet on an Epic project:

• Bulk FHIR, formally HL7’s FHIR Bulk Data Access (Flat FHIR) guide, lets an authorized backend client start one asynchronous export for a whole patient group and download the results as NDJSON files.
• CDS Hooks is an HL7 standard that lets an EHR call an outside decision-support service at set points in the clinician’s workflow, such as opening a chart or signing an order, and show the returned cards with information, suggested changes or a link to a SMART app.
• Connection Hub is the part of Epic’s Showroom where a developer can list a product that’s live with at least one Epic customer, for a per-product annual fee (see the glance table), and the listing is optional.
• An EMPI (enterprise master patient index) is a database that holds identity and demographic information for every patient across an organization’s separate systems, or across a group of organizations, and gives each patient one enterprise-wide identifier.
• FHIR (Fast Healthcare Interoperability Resources) is HL7’s standard for exchanging health data as modular building blocks called resources, usually over REST APIs in JSON or XML.
• Hyperspace is Epic’s clinician-facing application, which users now reach through Epic’s Hyperdrive desktop client, and it’s where SMART on FHIR apps can launch inside a patient’s chart.
• MyChart is Epic’s patient portal; a patient-facing app sends the patient to their provider’s MyChart login page, where they sign in and approve the data the app can pull.
• A QHIN (Qualified Health Information Network) is a TEFCA-designated network that has signed the Common Agreement and that hospitals and other participants connect to for nationwide exchange.
• Showroom is Epic’s website, launched in January 2024, for finding products and services that work with Epic, including third-party apps listed in Connection Hub and services from Epic itself.
• SMART on FHIR, defined in HL7’s SMART App Launch implementation guide, is a set of OAuth 2.0-based rules that let an app get scoped permission to EHR data and open with context such as the current patient, whether it launches inside the EHR or on its own.
• TEFCA (Trusted Exchange Framework and Common Agreement) is the nationwide health information sharing framework created by ONC, in which networks that sign its Common Agreement, called QHINs, connect hospitals and other participants to exchange records for purposes such as treatment, public health, government benefits determination and individual access services.
• USCDI (United States Core Data for Interoperability) is ONC’s standard list of health data classes and elements, such as medications, allergies, lab results and vital signs, that certified EHRs must be able to exchange.