# 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. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/epic-fhir-for-healthtech-startups Updated: 2026-09-17 ## 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](https://hl7.org/fhir/smart-app-launch/app-launch.html) and [SMART Backend Services](https://hl7.org/fhir/smart-app-launch/backend-services.html). Epic’s implementation notes live on [fhir.epic.com](https://fhir.epic.com/Documentation). Launch mechanics (iss, aud, PKCE, sandbox versus production client IDs) are the [SMART on FHIR app launch](https://alabenaicha.me/insights/smart-on-fhir-app-launch) playbook. Platform flavour versus Oracle Health is [Epic vs Cerner](https://alabenaicha.me/insights/epic-vs-cerner-comparison). | 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](https://healthsystemcio.com/2026/05/14/acute-care-ehr-market-share-2026/) and [HIT Consultant, 14 May 2026](https://hitconsultant.net/2026/05/14/klas-2026-ehr-market-share-report/)) 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](https://alabenaicha.me/services/epic-integration) or [contact with project intent](https://alabenaicha.me/contact?intent=project).