SMART on FHIR

SMART on FHIR is what turns a FHIR server from a raw data endpoint into something an app — or an agent — can be authorized against. It is a health-specialized profile of OAuth 2.0 and OpenID Connect that answers the questions base FHIR leaves open: how an app launches, how a user consents, and exactly what slice of a record a token may touch.

• Two launch modes - EHR-launch (an app opened from inside the clinician’s chart, inheriting patient context) and standalone launch (a patient-facing app the user connects on their own).
• Health-scoped permissions - Scopes like patient/Observation.read, user/*.read, and system/*.rw express access at the resource level — the closest thing healthcare has to a machine-legible permission grant.
• Backend Services for machines - A client-credentials profile with signed-JWT client authentication for bulk and system-to-system access, the pattern most population-scale FHIR runs on.
• A discovery document - /.well-known/smart-configuration advertises the auth endpoints and capabilities, the SMART equivalent of an OpenAPI security scheme.

When I score healthcare APIs, SMART is the dividing line between a provider that publishes real, agent-legible authorization and one that hands out an opaque bearer token. It is also where the sector’s biggest gap shows up: scopes tell an agent what it may technically call, but almost no provider serves the smart-configuration that makes those scopes discoverable, and none exposes consent state as a first-class surface — the layer the agentic era in a HIPAA world will make load-bearing.