Register an app, launch it the way an EHR would, and get a token scoped to a patient whose chart is worth looking at. SMART App Launch 2.0, on a sandbox you can set up in about a minute.
Discovery. Every SMART client starts at the discovery document. Ours advertises the authorization and token endpoints, supported scopes, PKCE methods and the capabilities array — if your client library reads it, it works here without special-casing.
Standalone launch. Your app starts the flow: response_type=code, client_id, redirect_uri, scope, state, aud and a PKCE code_challenge. The user picks a patient, consents, and you exchange the code for an access token plus a patient context claim.
EHR launch. The EHR opens your launch_uri with iss and a single-use launch token, and patient context arrives already resolved. This is how apps run inside Epic and Oracle Health in production, and it's the flow most sandboxes make hardest to rehearse.
Scopes that are enforced. SMART v2 granular scopes — patient/Observation.rs, patient/*.r, user/Patient.r, system/*.r — plus launch, launch/patient, openid, fhirUser and offline_access. A token is checked against the scopes it was granted, so an over-broad request fails the way it will in production.
curl "https://api.mock.health/fhir/.well-known/smart-configuration"Register your app with a launch URL, open Sandbox → SMART Launcher, pick the app and a patient, choose EHR Launch, and click Launch. The launcher appends iss and a single-use launch token to your launch URL and opens it — exactly what an EHR does from a patient's chart. Standalone launch works from the same app registration.
The SMART on FHIR tutorial builds a complete app — standalone and EHR launch — in a single HTML file and runs it against this launcher.
A launch flow that ends at a patient with one condition and no labs tests your OAuth code and nothing else. Behind a mock.health token is a chart generated by a Markov progression module trained on millions of real patient journeys: correlated conditions, medications that follow diagnoses, labs that trend, clinical notes and imaging reports, all US Core 6.1 profiled. The patients keep living, so an app that polls after launch sees new encounters land.
Production SMART isn't uniform. Endpoint paths differ by vendor, and Oracle Health uses its own .r/.rs/.rsu/.rsuc scope forms. Vendor-specific SMART behavior is reproduced per deployment on the map, so you can rehearse against Epic and Oracle Health (Cerner) shapes before you're in their app galleries.
Working toward certification? The Inferno (g)(10) guide covers running the ONC test suite. For patient-facing apps that launch from a payer or provider portal, see portals.
A FHIR server with a SMART App Launch authorization server and test patients, so you can register an app, run the OAuth 2.0 launch flow, and read FHIR data with a scoped token — without access to a real EHR.
Both. The SMART Launcher in the sandbox plays the EHR: it opens your launch URL with iss and a single-use launch token, and patient context comes back already resolved.
SMART App Launch 2.0 with PKCE and SMART v2 granular scopes such as patient/Observation.rs, plus launch, launch/patient, openid, fhirUser and offline_access.
SMART on FHIR authorization is included in the Free tier, against 25 curated synthetic patients. Pro ($199/month) adds thousands of patients, write access and your own isolated sandbox.
You can test against their observed shape — endpoint layout, scope syntax and related wire behavior are reproduced per deployment on the map. Listing in a vendor's app gallery still goes through the vendor.
Create a free account, register your app, and launch it against a patient with a real chart — read the SMART on FHIR docs for the endpoint details. Start free · Pricing · Quickstart