Epic mobile app and MyChart integration
We connect native and cross-platform mobile apps to Epic: patients sign in with MyChart and connect their record, clinicians pull the chart into a mobile workflow, and your backend keeps data in sync. SMART on FHIR with PKCE, secure token storage, refresh and reconnection are built in, and each health system's rollout is planned from the first sprint.
Scope your Epic mobile app integrationFor digital health, remote monitoring, care management and clinical mobile products whose customers run Epic. Updated September 26, 2026.
Pick the organization from Epic's R4 endpoint directory
System browser, PKCE and the scopes on your registration
US Core data for the features your app offers
Refresh tokens, reconnection and clean logout
Illustrative workflow · scope tailored to your environment
The short answer
Epic mobile app integration connects an iOS or Android app to a health system's Epic instance so patients or clinicians can use Epic data in the app. Patient apps use a standalone SMART on FHIR launch where the patient signs in with MyChart; clinician apps sign in with Epic credentials; a backend service keeps server-side data in sync. Nirmitee builds the OAuth 2.0 flow with PKCE in the system browser, stores tokens in the iOS Keychain or Android Keystore, maps Epic's FHIR data into your app and plans each health system's approval. Read-only patient apps that use Epic's USCDI APIs reach Epic customers automatically; apps that write data or serve clinicians go through each customer's review.
Read how to integrate with EpicStart with the real problem
Real users switch phones, lose signal, background the app for a week and return expecting their data. Tokens expire, a health system upgrades its Epic version, a patient connects a second organization. A usable Epic mobile integration handles all of it: refresh before expiry, reconnect without losing history, show when data is missing rather than empty, and never leak PHI into logs, crash reports or push notifications.
What we build
Each app type has its own sign-in, data and approval path. We scope it before the first estimate.
Apps where patients connect their Epic record to see results, medications, conditions and visits alongside your own features.
Epic SMART on FHIR app developmentApps that collect weight, blood pressure, glucose or SpO2 at home and send readings to the care team in Epic.
Remote patient monitoring softwareRounding, care coordination and specialty tools where clinicians see the chart on a phone or tablet.
Epic FHIR API integration servicesExperiences that patients open from MyChart itself rather than from your app.
Epic integration servicesApps that connect patients across Epic, Oracle Health and other EHRs in one record view.
Oracle Health and Cerner integration servicesServer-side services that keep your app's data current without the phone being online.
Epic Integration Cost PlanningYour starting point
Let patients connect their Epic record from your app, with the right organization, consent and reconnection behavior.
Give clinicians Epic data in a mobile workflow without carrying stale patient context between sessions.
Turn a sandbox connection into production access at your first Epic customer, then repeat it for the next.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Identify the Epic customers, app type, APIs, scopes and whether the app qualifies for automatic distribution or needs each customer's review.
Implement OAuth 2.0 for native apps with PKCE in the system browser (ASWebAuthenticationSession or Custom Tabs), app-claimed redirect URIs and OpenID Connect identity.
Store tokens in the iOS Keychain or Android Keystore, refresh before expiry, reconnect after revocation and log out cleanly on shared devices.
Map Epic's US Core resources to your screens, preserve source identifiers and dates, cache only what the policy allows and show missing data as missing.
File readings and patient-entered data through the Epic APIs that support it, with duplicate checks and clear status for the patient.
Prepare registration, security review answers, test evidence and support ownership for each customer environment.
Compare your options
The right option depends on who uses the app, where they start and whether the app writes data back.
| Option | How the user connects | How it reaches Epic customers | Best for |
|---|---|---|---|
| Standalone patient app with MyChart sign-in | Patient opens your app, picks the health system and signs in with MyChart | Automatic for read-only USCDI apps; customer approval otherwise | Consumer, companion and remote monitoring apps |
| Launch from inside MyChart | Patient opens the experience from MyChart | Health-system configuration and Epic's embedded testing | Health systems adding a third-party experience to their portal |
| Standalone clinician app | Clinician signs in with Epic credentials on a phone or tablet | Customer approval of the client and its APIs | Rounding, care coordination and specialty tools |
| Backend sync behind the app | No user sign-in; your server connects | Customer approval and key provisioning per site | Data that must stay current when the phone is offline |
| Network access through TEFCA | Patient authorizes through Individual Access Services | Registered with a QHIN such as Epic Nexus; MyChart Central links organizations | Apps that need records from many organizations at once |
Most patient apps start with a standalone MyChart sign-in and add backend sync; clinician tools follow Epic SMART on FHIR app development patterns.
Expertise is in the decisions
Read-only patient apps that use only Epic's USCDI APIs are distributed to Epic customers automatically. Writing data, serving clinicians or calling other APIs puts the app through each customer's review. The feature list decides the rollout plan.
Mobile apps cannot keep a secret, so they use PKCE, which Epic has supported since its August 2019 version. When the app needs long-lived server access, the backend holds the credentials and the phone talks only to your API.
Validate each intended write. Epic's vital-sign write needs an Encounter reference and one reading per call, and patient-entered readings need an order from the health system that creates patient-entered flowsheet rows.
Choose what may be cached, for how long and how it is protected. Keep tokens and patient payloads out of analytics, crash reports and push notification text.
Each Epic customer approves the apps that connect beyond automatic distribution. We name those approvals as dependencies in the delivery plan and drive them from the first week.
Each Epic customer has its own endpoint, Epic version and enabled APIs. We keep that context in configuration and confirm it site by site before release.
Timeline
Engineering milestones are ours to hit. Customer review and app store release run in parallel and are tracked as named dependencies.
Weeks 1 to 2: users, data, write needs, distribution route and a registered app on fhir.epic.com.
Weeks 2 to 8: PKCE sign-in, token lifecycle, data mapping and screens, tested against the Epic sandbox.
Weeks 6 to 14, paced by the health system: security review, production client activation and acceptance testing.
After the first go-live: app store release, monitoring and the next health systems.
Delivered work
Client names are withheld; each is a real engagement or a public repository you can inspect.
A live patient app that unifies records from multiple providers with wearable data. We took it over from previous vendors, closed inherited credential exposure first, and kept releasing to the app stores without disrupting existing users.
Our multi-EHR SMART app runs discovery, PKCE and token exchange against both vendors from one code path, reads the chart and files a vital sign that returns 201 and reads back. Epic granted the registration's scopes; Oracle Health granted only the intersection and issued tokens lasting about 570 seconds.
A FHIR R4 server with SMART App Launch that passed 47 of 47 ONC (g)(10) SMART standalone patient tests in Inferno.
Scheduling, charts, care plans and billing on a FHIR R4 server, with clinicians signing in through PKCE OAuth 2.0 and a token exchange bridging the organization's single sign-on.
From discussion to delivery
Agree the user, sign-in path, required data and the first Epic customer.
Test the MyChart or Epic sign-in and representative data against the Epic sandbox.
Handle refresh, reconnection, offline behavior and permitted writes.
Complete the customer's review, activate production access and release to the app stores.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗Before you commit
It connects an iOS or Android app to a health system's Epic instance so patients or clinicians can use Epic data in the app. Patients sign in with MyChart through a SMART on FHIR standalone launch, clinicians sign in with Epic credentials, and a backend service can keep data in sync.
Register a patient-facing app on fhir.epic.com, open Epic's authorization page in the system browser with PKCE, let the patient pick their health system and sign in with MyChart, then exchange the code for tokens. The access token and patient ID let the app read the record within the registered scopes.
Launching from inside MyChart is configured by each health system and tested through Epic's embedded testing in Vendor Services. A standalone app with MyChart sign-in needs no listing. A Showroom listing is optional and markets the product to Epic customers.
Not always. Epic distributes read-only patient apps that use only its USCDI APIs to customers automatically, unless a customer has turned that off. Apps that write data, serve clinicians or call other APIs need each health system's approval.
Yes. The framework does not change the Epic side: OAuth 2.0 with PKCE in the system browser, an app-claimed redirect URI, secure token storage and the same FHIR APIs. We use the platform's secure storage from React Native, Flutter, Swift or Kotlin.
The same app works across Epic customers, and Epic's public directory listed 479 R4 endpoints on 25 September 2026. Each site can differ in Epic version, enabled APIs and approval, so we test against the site's configuration before launch there.
Yes, where Epic supports the write. Patient-entered vital signs file through Observation.Create with an Encounter reference and an order from the health system that creates patient-entered flowsheets; questionnaires file as QuestionnaireResponse. Writes need the customer's review.
Epic's documentation shows access tokens of about an hour. Patient apps that request offline_access receive refresh tokens so the patient stays connected; Epic also supports dynamic client registration for device-bound keys. We refresh ahead of expiry and handle revocation cleanly.
Cost follows the number of app types, the data and writes, offline and caching needs, and how many health systems you launch with. We fix the scope after a short discovery and list any Epic or health-system fees separately.
Sign-in and core data for one app type are usually built and tested against the Epic sandbox in 6 to 8 weeks. Apps that need customer review add that health system's timetable, and app store review runs alongside.
No. MyChart remains the health system's patient portal. Your app uses MyChart sign-in to connect the patient's record and adds the experience your product is built for.
Yes. We sign Business Associate Agreements and are ISO 27001:2022 certified. Mobile builds keep PHI out of logs, analytics and push notifications, encrypt local data and wipe it on logout.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
