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

You’ve got a health app that needs data out of Epic. Maybe it’s a clinician-facing tool pulling labs and medications, maybe it’s a patient app wiring into MyChart. Before you scope it, know one thing: the work behind “integrate with Epic” shifts with the data you need and which direction it flows. And it shifts again depending on which Epic site you’re connecting to.

Epic is the dominant acute-care EHR in US hospitals, so for a lot of health-tech teams, Epic EHR integration decides whether those hospitals can adopt the product at all. Get it right and you’re inside the clinician’s workflow. Get it wrong and you’ve built a demo no one can deploy.

If you’re about to develop a healthcare app on top of Epic, you need four answers up front: what Epic’s USCDI on FHIR APIs hand you for free, where the write-back wall sits, what site-by-site approval costs in time and budget, and what changes once the app lives on a phone. That free read-only access exists because federal interoperability regulations, the 21st Century Cures Act Final Rule, made a standardized FHIR API a requirement for EHRs certified under ONC’s program, and they limit what certified API developers can charge app developers for it.

How do I integrate my health app with Epic EHR?

Register your app for free on Epic on FHIR, build against Epic’s FHIR R4 APIs in its public sandbox, then have each Epic customer download your client ID and test in its own environment before go-live. As of September 2026, Epic’s USCDI APIs are read-only and cost developers nothing, and each health system licenses them from Epic. Our planning range for a production integration is 6 to 12 months to the first go-live.

Key takeaways:

• Epic’s USCDI on FHIR APIs give you free, read-only access to a standard set of patient data (labs, medications, problems, vitals, demographics), enough to power a clinician-facing app, a patient app, a telehealth view, or analytics. Epic charges developers nothing for them, per call or otherwise; each health system licenses them from Epic.
• Write-back is narrow: Epic’s USCDI APIs are read-only, and other public APIs allow a limited set of writes, such as filing notes and vital signs or adding allergies and problems, where a health system turns them on. Outside specialty cases such as radiation oncology, the public APIs create orders only as unsigned suggestions a clinician signs, and real orders come in through an HL7 v2 interface the health system sets up. Build for reading and displaying, and keep clinical decisions inside Epic where they belong.
• Security is what gets apps rejected. OAuth 2.0 with PKCE and least-privilege scopes are table stakes, and each Epic customer decides when your app goes live on its own instance. Unless yours is one of the read-only patient apps Epic distributes automatically, build the per-site approval window into your schedule from the start.

Epic integration at a glance

The short version, as of September 2026. Cost and timeline are Topflight’s planning ranges; the rest comes from Epic’s own 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. Why health tech teams choose Topflight for Epic integration
9. Let’s build a health app that connects to Epic EHR

What Epic integration actually means

Epic integration means connecting your app to one health system’s own Epic instance, and each Epic customer configures its instance a little differently. “Integration” also covers several jobs: reading a patient’s labs, launching your app inside a clinician’s chart, exporting a whole cohort for analytics, or taking HL7 v2 message feeds. The work and the cost change with each.

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.

As of September 2025, Epic said open.epic offers specifications for over 800 free APIs, including its USCDI v3 FHIR APIs, and that 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, and ONC’s SVAP page still described that discretion as in effect in August 2026. A pending ONC proposal (HTI-5, December 2025) 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.

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

Here’s the part that catches teams treating Epic as one endpoint. Each Epic customer configures its own site, so the same app can behave differently from one hospital to the next.

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. But a few kinds of read-only patient-facing apps, including those on qualifying USCDI APIs, arrive automatically at customers that license those APIs. 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. As of September 2026:

Sources: each vendor’s developer documentation and ONC’s Certified Health IT Product List, 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 Cerner vs. Epic comparison; for athenahealth, our athenahealth integration guide.

Benefits of Epic EMR/EHR integration

Connecting your app to Epic does two things at once: it gets you the patient data you need, and it makes your product deployable in the hospitals that run Epic. The benefits of Epic integration mostly trace back to those two.

Start with the economics. Epic’s USCDI on FHIR APIs cost you nothing as a developer: each health system licenses them from Epic, and your app reads patient data without a per-call fee, then runs AI on it or does whatever your product does with clinical data. That makes it the lowest-cost entry point into Epic EMR integration for you, and for a lot of products it’s enough on its own.

FHIR reads fit on-demand pulls. When your app has to stay in sync as data changes, Epic recommends event-driven HL7 v2 interfaces; Epic publishes no price for those, so ask each health system what one will cost. Epic also tells apps to prefer discrete FHIR APIs to CDA documents such as CCDs, because they perform better for both systems.

Also Read: Why FHIR is no longer optional

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, so patient care coordination doesn’t hinge on someone manually reconciling three screens.

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, along with the one-off middleware that usually comes with it. Standard endpoints also mean less to maintain when a site upgrades.

Done right, this is where you optimize workflows that used to eat clinician time:

• chart updates that populate automatically from Epic
• medication and allergy lists that arrive structured
• demographics that don’t get typed twice

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 scalable solutions you can extend to Cerner or athenahealth later. They’re also why Epic integration with other information systems tends to get easier after the first one, and why you should design your Epic integration solutions for reuse from the start, since the patterns repeat.

Beyond Epic interoperability, integration is what makes EHR process automation possible. With CDS Hooks you can surface alerts and recommendations at the point of care, right where clinicians are already working. And once Epic is the source of truth, the repetitive clinic management work automates:

• appointment scheduling
• medication reconciliation
• chart updates
• intake and check-in

That’s the core of Epic automation, and it’s where clinicians actually feel the integration.

One caveat: Epic’s FHIR APIs don’t keep two systems in continuous, live two-way sync. You architect around scheduled pulls or event-driven HL7 v2 feeds, which Epic calls one of the best tools for keeping systems in sync in real time. Most use cases run fine on that setup, as long as you plan for it up front.

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 authorize your app by signing in with their MyChart credentials at each organization, and an organization can also set up a launch of your app from inside MyChart. In MyChart itself, patients:

• view test results
• request prescription renewals
• schedule appointments
• message their care team

Where an organization sets up a launch from inside MyChart, your app sits right next to those tasks, and patients stay engaged with their care between visits. More and more healthcare delivery happens in that gap. You also skip standing up your own portal login.

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

Done well, that kind of Epic software integration quietly improves practice management: patient care coordination that used to live in someone’s head now flows between systems, and the same pattern carries from a single clinic to a multi-site group. For smaller operations, that’s often what clinic management runs on.

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.

These read-only patterns are the Epic integration solutions most teams ship first. The more involved Epic integrations (SMART launch, write-back, bulk export) come later. If you want yours scoped against your actual product, see our EHR integration services.

Challenges and limitations of Epic API integration

Epic’s open APIs are generous for reading and stingy for almost everything else. Most of the friction of integrating with Epic is predictable. It clusters around write-back limits, per-customer governance and auth, and the reality that no two Epic sites behave 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: as of September 2026, 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

Related: Building a doctor on demand application

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. As of September 2026, 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.

Two pieces of Epic guidance shape how you handle credentials. Epic’s App Developer Guidelines, which Epic strongly encourages developers to follow, say the credentials you use with a health system’s Epic software should be unique to that Community Member and used only with Epic APIs. Its request-process guide asks for a different key or client secret for each customer and environment, though its OAuth 2.0 tutorial lets a cloud-hosted app using private_key_jwt share one signing key across customers.

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, workflow limits, and version drift

The Epic EMR integration API is built for reading. 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.

The ceiling is write-back. Epic API write back covers a limited set of resources: as of September 2026, Epic’s public FHIR APIs let apps, among other writes, 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.

When integrating with Epic, treat version drift as a given. A single Epic server can serve DSTU2, STU3 and R4 APIs side by side (Epic’s catalog still lists older versions of some APIs), and each customer upgrades on its own schedule, often 3 to 12 months (sometimes more) after Epic’s release. Ship an adapter layer that normalizes resources across versions and gate features by what each site actually supports. A per-site conformance checklist with contract tests catches the rest.

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

The gap between “works in the sandbox” and “works at the customer’s site” is where timelines slip. A few things to engineer for before you call it done:

• 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. As of September 2026, 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.

Also Read: Developing a Senior Care Application

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

As of September 2026, 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

Integrating with Epic EHR starts with a free app registration on Epic on FHIR and ends with a go-live at each Epic customer, which downloads your client ID and tests your app in its own environment. Epic’s step-by-step Developer Guide on open.epic covers the same ground. Here’s how to integrate with Epic EHR, in the order the work happens:

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. In a September 2026 spot check of 11 customer endpoints, versions ran from May 2024 to May 2026, while Epic’s sandbox ran August 2026.
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. A few kinds of read-only patient-facing apps, including those on qualifying USCDI APIs, download automatically to customers that license those APIs and haven’t turned auto-download off.
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. Epic data integration starts with that set, and as of September 2026, 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

These USCDI APIs are read-only. They 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.

Also Read: Mastering PointClickCare EHR Integration

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, and pulls records into your app
• 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.

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.

Also Read: EHR Implementation Guide

Also Read: E-Prescription App Development Guide

Epic FHIR API implementation guide

Once you know which sites you’re targeting, Epic FHIR API integration follows a repeatable shape. 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.

As of September 2026, Epic’s App Developer Guidelines ask apps to keep persisted tokens in the operating system’s secure storage, rotate tokens and enforce inactivity timeouts.

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. As of September 2026, 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.”

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.

Screenshot from 2023. Current ratings are in the table below.

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.

Also Read: Patient Intake Management Automation Guide

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.

As of September 2026, 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.

Related Article: SMART on FHIR Guide to Healthcare App Development

Cross-network exchange and TEFCA considerations

One shift worth planning around: TEFCA is live and growing. The first QHINs (Qualified Health Information Networks) were designated in December 2023, and health data began flowing among them within days, according to ONC.

As of September 2026, 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. As of September 2026, 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: as of September 2026, Epic’s TEFCA tracker lists 2,165 hospitals and about 58,000 clinics using Epic as live on TEFCA for all purposes. Epic’s consumer app playbook said over 200 Epic provider organizations were answering IAS requests as of September 2025. ONC reported about 10 million documents exchanged through TEFCA before 2025 and 464 million by the end of 2025, and as of August 2026 the RCE reports more than 1.5 billion since go-live.

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

Our planning range for Epic integration cost is $50,000 to $200,000+ over 6 to 12 months for a production integration, depending on read versus write scope and how many sites you connect. For the app build itself, smart use of AI in our development process brought focused healthcare builds in at $25,000 to $97,000, with a median of $49,000 (see our healthcare app development cost guide). Here’s where the time and money go.

Time and cost by phase

These are Topflight’s planning estimates by phase, as of September 2026; the Epic program fees in the table come from Epic’s own pages. Times and costs scale with complexity and with the number of sites.

What usually increases time and budget

A few things reliably push toward the high end of those ranges.

The sandbox eats the most budget. Epic refreshes its free FHIR sandbox at fhir.epic.com every Sunday evening, erasing the prior week’s writes, and upgrades it each quarter (as of September 2026), so script your test-data setup. Epic’s private APIs, Kit and Clarity need Vendor Services on top, starting at $1,900 a year.

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 pricing guides.

Why health tech teams choose Topflight for Epic integration

When timelines are tight and PHI is on the line, you want a healthcare app development company that’s already shipped real Epic integrations. We have.

Products we’ve built have helped our partners raise over $200 million (as of September 2026). 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. That’s the short version of our Epic EHR integration services.

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. That range, FHIR and HL7 under one roof, is what a lot of Epic integration services are missing.

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. As of September 2026, 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

As of September 2026, 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 Vendor Services, from $1,900 a year, with time from Epic representatives billed hourly 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.

Developers also post Epic sandbox and OAuth questions in the public SMART on FHIR Google Group, a community forum Epic doesn’t run. The three Epic questions posted there in May and June 2026 had no replies when we checked in September.

If you’re scoping an Epic EMR integration or Epic EHR integration project, 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. Working with people who’ve shipped Epic integrations before means your app supports Epic systems integration cleanly and keeps patient care coordination intact across institutions.

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 any Epic project, defined as of September 2026:

• 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 $500 per product per year according to Epic’s listing documentation, 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 the patient signs in and approves 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; as of September 2026 the RCE lists 11, including Epic Nexus.
• 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.

Other blogs about healthcare app development:

• How to build a healthcare chatbot
• Guide to creating a Hospital Management Software
• Blockchain in Healthcare: The Good, Better, Best
• A Guide to Integrating AI in EHR

Related articles:

1. Healthcare App Development: Everything you need to know
2. Healthcare Mobile App Design Guide
3. How to Start a Healthcare Startup
4. A Guide to Medical Website Development
5. HIPAA Compliant App Development Guide
6. Cerner vs EPIC: The Better Choice?
7. EHR Data Migration Guide
8. Cost of EHR Implementation

[Reviewed September 2026]