SMART on FHIR is an HL7 standard that layers OAuth 2.0 and OpenID Connect onto FHIR so third-party, provider, and patient-facing apps can be authorized against an EHR with scoped, revocable permissions. It defines the SMART App Launch flow (EHR-launch and standalone launch), SMART Backend Services (system-to-system client-credentials with signed JWT), health-specific scopes (patient/*.read, user/*.read, system/*.rw), and a discoverable .well-known/smart-configuration document. It is the de-facto authorization contract for modern healthcare APIs.
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, andsystem/*.rwexpress 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-configurationadvertises 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.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The State of Canadian Insurance APIs
The only published insurance-domain scopes in Canada are SMART scopes, and they exist because of United States regulation rather than Canadian.
The State of US Healthcare APIs
SMART scopes are the one place the US healthcare mandate delivered a real, agent-legible security contract — yet the smart-configuration that publishes them is served almost nowhere.
Governed by these regulations
A standard is the machine-readable contract; a regulation is the law that requires it. These are the regulations that mandate or drive this standard, catalogued at regulations.apievangelist.com.
21st Century Cures Act
The information-blocking rule makes standardized FHIR + SMART access a legal obligation for certified EHRs.
ONC Health IT Certification Program
The (g)(10) 'Standardized API' criterion requires SMART App Launch + SMART Backend Services.
