Patient-authorized EHR integration

Epic and MyChart FHIR integration for patient-facing applications.

The production work around an Epic connection extends beyond the authorize URL: application registration, organization routing, exact callbacks, patient context, scopes, and source-specific validation all matter.

Updated: 2026-08-25 · 10 min read

The bottom line

Use a standalone patient-facing OAuth flow when the patient begins in your application. Register the exact redirect URI, route to the selected organization’s FHIR environment, use PKCE, validate state, and test with the application’s non-production registration before pursuing production use.

Key takeaways

“Epic integration” is an organization-routing problem as well as an OAuth problem.
Epic recommends PKCE, and current SMART guidance requires applications to support it.
Open sandbox success does not prove an individual customer environment or complete production workflow.

Evidence boundary: Combines FinchNode implementation experience with Epic’s public OAuth and testing documentation. It does not claim that every Epic organization exposes identical data.

Author: FinchNode Engineering

Choose the correct launch pattern

For a patient-facing product that starts outside MyChart, use the standalone launch pattern. The application initiates authorization, Epic authenticates the patient, and the token response supplies the authorized context. An EHR or MyChart launch is a different workflow because Epic initiates the launch and supplies a launch value.

Build the authorization request from registered values

GET {authorizeEndpoint}?response_type=code
  &client_id={nonProductionClientId}
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fepic%2Fcallback
  &aud={encodedOrganizationFhirBase}
  &scope=openid%20fhirUser%20launch%2Fpatient%20patient%2F*.rs
  &state={oneTimeState}
  &code_challenge={s256Challenge}
  &code_challenge_method=S256

What the sandbox cannot prove

That the selected healthcare organization is live for your registered production application.
That the organization returns every configured resource or historical record.
That portal enrollment, proxy access, or patient matching will succeed for every user.
That refresh, logout, revocation, and reauthorization behave identically in every environment.
That an EHR-launched workflow works when only standalone authorization was tested.

What FinchNode puts behind one connection contract

FinchNode separates provider selection from application code, maintains source routing, performs the hosted authorization handoff, tracks connection state, and exposes approved normalized categories through its server API. It still reports source, availability, and sync status so the abstraction does not imply universal data.

Primary sources

More FinchNode interoperability guides

Frequently asked questions

Can a patient-facing app connect to Epic through MyChart?

Yes, when the application is registered for the appropriate patient-facing workflow and the selected organization supports the required endpoint and scopes. The patient authenticates with the source, not with FinchNode.

Does one Epic sandbox cover every hospital?

No. A sandbox validates important protocol behavior but does not reproduce every organization’s endpoint configuration, version, data, or patient workflow.

Should an Epic app use PKCE?

Yes. Epic recommends PKCE, and SMART App Launch 2.2 requires applications to support it. Use S256 rather than a plain challenge.

Does FinchNode receive MyChart passwords?

No. The simulated FinchNode Visualizer demonstrates the handoff, but real patient credentials belong only on the healthcare organization’s authorization experience.