Epic FHIR for HealthTech startups: patient access, provider SMART, backend JWT
A decision page for HealthTech teams integrating with Epic — patient-access SMART versus provider launch versus backend-services JWT, App Market versus a single health system, and KLAS share as cited market context.
Ala Ben Aicha
Direct answer
This page is for HealthTech teams choosing Epic FHIR access: patient SMART, provider SMART, or backend-services JWT. Marketplace listing is not a single-system go-live. KLAS share is market context, not a delivery claim.
Decision table: which API
Build the handshake from SMART App Launch 2.2.0 and SMART Backend Services. Epic’s implementation notes live on fhir.epic.com. Launch mechanics (iss, aud, PKCE, sandbox versus production client IDs) are the SMART on FHIR app launch playbook. Platform flavour versus Oracle Health is Epic vs Cerner.
| Need | Flow | Scopes / credential | When not to use it |
|---|---|---|---|
| Patient-facing app (PHR, intake, home monitoring) | SMART standalone or patient-portal EHR launch | launch/patient or portal launch; patient/*.rs (or tighter) |
Chart-embedded clinician UX; bulk export without the patient present |
| Provider app in Hyperspace / Hyperdrive | SMART EHR launch | launch + user/ or patient/ scopes; openid fhirUser if you need the practitioner |
Headless jobs, nightly CCD ingest, payer bulk |
| System-to-system (no user) | Backend services — JWT (client_credentials + private_key_jwt) |
Backend client, JWK Set URL; Epic maps the client to an audit user in production | Anything that needs interactive consent or in-chart context |
| Discoverability in Epic’s catalogue | Connection Hub / Showroom (App Orchard is retired) | Listing is a go-to-market artefact | A private app for one health system that already wants you |
| One health system only | Register on fhir.epic.com; member build; their FHIR base | Two client IDs (non-prod / prod) | Waiting on a marketplace badge before writing the first Patient read |
Epic issues a non-production and a production client ID per app. Sandbox (https://fhir.epic.com/interconnect-fhir-oauth/) auto-maps backend clients to a user. A live community member does not: an ECSA must map the client ID to an Epic user for audit before a backend token is issued. That discrepancy belongs on the test matrix in the launch playbook. It is not a calendar commitment.
App Orchard (the old paid directory) is retired. Do not plan an “8-week App Orchard review”. Showroom is where customers browse; Connection Hub is where connections are recorded. A hospital can still go live with a private app that is not in Showroom. Conversely, a Showroom tile does not replace member-by-member FHIR base URLs, JWKS, and ECSA build.
KLAS as market context, not a sales metric
KLAS’s US Acute Care EHR Market Share 2026 (contracts January–December 2025) is the current public benchmark for “how much of US acute care sits on Epic”. Independent write-ups of that report (for example healthsystemCIO, 14 May 2026 and HIT Consultant, 14 May 2026) state that Epic holds 43.7% of acute care hospitals and 56.9% of beds, and added 77 hospitals in 2025. Those figures explain why US HealthTech roadmaps mention Epic first. They are not a count of Epic implementations I have shipped, not a win rate, and not a reason to skip Oracle Health or MEDITECH when the buyer runs those EHRs.
Illustrative 4–8 week spike
Phases below are a spike outline for scoping, not a quote, not Vendor Services lead time, and not an Epic assurance calendar.
| Week (illustrative) | Phase | Exit |
|---|---|---|
| 1 | Choose the cell in the table — patient vs provider vs backend; one health system vs catalogue. Register the app; store both client IDs | Written decision; sandbox SMART or JWT hello-world |
| 2 | CapabilityStatement + scopes — read the member (or sandbox) metadata; cut scopes to the minimum; list resources that exist in sandbox but not in the target version | Scope file in git; list of gaps |
| 3–4 | Happy-path fixture — one de-identified Patient read / one EHR launch / one backend search. PKCE, aud, iss. Backend: JWKS hosted, not a pasted key |
Automated test against sandbox |
| 5–6 | Member non-prod — second FHIR base, production-shaped auth, ECSA mapping if backend, patient-selection differences | Same tests green on the member non-prod ISS |
| 7–8 | Failure matrix — wrong aud, expired launch token, 403 on a sandbox-only resource, refresh vs no refresh. Rollback: disable the app at the EHR, rotate keys |
Written rollback; no PHI in logs |
If week 6 is still “waiting for a marketplace ticket”, you picked the wrong cell — go live with the member who wants the app, then discuss Showroom as a separate GTM track.
What you will not get from this page (or from me as a stamp)
- A legal opinion that your app is HIPAA-permitted, a BAA, or a subprocessor analysis.
- An Epic certificate, Showroom listing, or Vendor Services membership in my name.
- A count of Epic hospitals I have connected inferred from KLAS share.
- A fixed App Orchard / Showroom SLA.
- Clinical advice, treatment logic, or a CDS Hooks card that tells a clinician what to prescribe — that is a different product and possibly a medical device.
I implement the mapping, the launch, the JWT, and the test matrix. The health system’s ECSA, compliance, and Epic’s own programmes remain theirs.
If that spike is what you need, use Epic integration or contact with project intent.