How FHIR apps work

Try it

Each button opens a real tool through the same SMART on FHIR launch Epic uses. The data comes from the SMART Health IT sandbox, a public test system with synthetic patients. No real patient data is involved.

You'll see a simulated login screen; click Login. The tool opens with a banner showing what it read from the chart. Sandbox patients are sparse: expect age and sex, often without labs or problems. Then come back here, or use the banner's “How this launch worked” link, to see each step.

What just happened

The steps of your last launch in this tab, as the tool recorded them. Codes and tokens are shortened.

FHIR: a common format for chart data

FHIR (Fast Healthcare Interoperability Resources) is the standard that EHRs like Epic use to share data with apps. The chart is split into resources, each with a fixed shape:

An app asks for them with plain web requests, and they come back as JSON. A troponin result looks like this:

GET Observation?patient=123&code=http://loinc.org|67151-1

{ "resourceType": "Observation",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "67151-1",
            "display": "Troponin T.cardiac, high sensitivity" }] },
  "effectiveDateTime": "2026-10-18T08:42:00Z",
  "valueQuantity": { "value": 11, "unit": "ng/L" } }

The code (LOINC for labs, ICD-10 or SNOMED for problems) is what lets the same app work at any hospital: it asks for “LOINC 67151-1” rather than for one lab's internal test name.

SMART: how the app gets in safely

SMART on FHIR is the sign-in layer on top. It lets the EHR hand an app a short-lived, limited key to one patient's chart. This is the sequence every launch above runs through:

1. EHR→Tool

   The clinician clicks the tool's button in the chart. The EHR opens /launch/?iss=…&launch=…: iss is the EHR's FHIR address, launch a one-time ticket naming this patient and user.

2. Tool→EHR

   The tool looks up the EHR's sign-in addresses at iss/.well-known/smart-configuration.

3. Tool→EHR sign-in

   It redirects to the EHR's sign-in with its client ID (registered in advance), the scopes it wants (e.g. read labs), and a PKCE challenge: a one-way hash of a secret only this browser tab knows.

4. EHR sign-in

   The EHR checks the user is signed in and the app is approved, then sends the browser back to the tool with a one-time code.

5. Tool→EHR

   The tool trades the code plus its PKCE secret for an access token, about an hour long, and learns which patient is open.

6. Tool→FHIR API

   It reads Patient, Observation, Condition and MedicationRequest with that token, fills in the form, and shows what it used.

Why it's safe

• Nothing leaves the browser. These tools have no server: chart data goes from the EHR straight to the page and disappears when the tab closes.
• Limited, short-lived access. The token covers one patient, read-only, for about an hour, and only the data types the app was approved for.
• Can't be hijacked. PKCE and a random state value mean a stolen code is useless to anyone but the tab that started the launch.
• The clinician stays in charge. Every prefilled field can be changed, and judgment items (history, ECG, “PE most likely”) are never filled automatically.

Sandbox vs. Epic

The code is the same. What changes at a real hospital:

• Registration: the app is registered with Epic, which issues the client ID, and the hospital's Epic team approves it and adds a button in the chart.
• Data: real labs, vitals and problem lists, so troponins, D-dimers and risk factors fill in.
• Local codes: if a lab isn't mapped to LOINC, the app needs the hospital's own code for it.

Next step beyond launching: CDS Hooks, where the EHR calls the tool by itself at a key moment (e.g. when a CT angiogram is ordered) and shows its result as a card.