SMART on FHIR

fhir technical technical fhirinteroperabilityhealthcare
Source: HL7 System: http://hl7.org/fhir/smart-app-launch Code: SMART on FHIR Reviewed: 07/02/2026 License: CC-BY-4.0

SMART on FHIR

One-sentence definition: SMART on FHIR is the HL7 standard authorization framework that enables third-party apps to securely launch from within an EHR and request scoped access to FHIR data on behalf of a patient or clinician — built on OAuth 2.0 and OpenID Connect.

Full Definition

Before SMART on FHIR, every EHR vendor had its own proprietary approach to app authentication. A clinical decision support app that ran in Epic used a different launch and authorization mechanism than the same app running in Cerner. There was no standard way for an app to say “I need read access to this patient’s medications” and have that request be interpretable by any FHIR server.

SMART (Substitutable Medical Applications and Reusable Technologies) on FHIR solves this by layering a healthcare-specific profile on top of standard OAuth 2.0 and OpenID Connect. It defines two launch contexts: EHR launch, where the EHR initiates the app and passes patient context, and standalone launch, where the app launches independently and selects context itself. It also defines a standard set of scopes — such as patient/Observation.read or user/Patient.write — that apps use to declare exactly what FHIR data they need.

SMART on FHIR is published as an HL7 Implementation Guide (the SMART App Launch IG). ONC certification criteria require EHRs to support SMART App Launch as a prerequisite for the standardized patient access API mandate under the 21st Century Cures Act.

Context and Usage

Where This Term Appears

  • Patient access apps: Consumer-facing apps (like Apple Health) use SMART standalone launch to retrieve patient data from payer and provider FHIR APIs
  • EHR-integrated clinical tools: CDS tools, formulary apps, and prior auth tools use EHR launch to receive patient context from the EHR
  • ONC certification requirements: 2015 Edition certification criteria require SMART App Launch support
  • Backend services: The SMART Backend Services profile handles machine-to-machine FHIR access without a user context (used in bulk data pipelines)

Common Usage Examples

In conversation: “The app uses SMART standalone launch — it redirects to the payer’s auth server, the user logs in, and then it gets a token scoped to patient/Everything.read.”

In documentation: “Clients must authenticate via SMART on FHIR before calling any endpoint on the RESTful API.”

Relationship to Other Terms

  • FHIR — the data API that SMART on FHIR secures and provides scoped access to
  • HL7 — the standards body that maintains the SMART App Launch IG
  • Implementation Guide — SMART App Launch is published as a FHIR IG

Common Misconceptions

Misconception: SMART on FHIR Is Only for Patient-Facing Apps

  • Incorrect belief: SMART on FHIR is a consumer technology for patient-facing apps like Apple Health.
  • Reality: SMART on FHIR covers EHR-embedded clinical tools, backend machine-to-machine services (SMART Backend Services), and provider-facing apps as well as patient-facing ones.
  • Why it matters: Teams building provider-facing CDS tools or payer data pipelines also need to implement SMART — not just teams building consumer apps.

Misconception: SMART on FHIR Is Part of the Core FHIR Specification

  • Incorrect belief: SMART on FHIR is defined within the FHIR specification itself.
  • Reality: SMART on FHIR is a separate HL7 IG that defines a profile on OAuth 2.0 and OpenID Connect. The FHIR core specification references security considerations but does not prescribe an authorization mechanism.
  • Why it matters: Implementing FHIR does not automatically mean implementing SMART — they are separate specifications that must both be explicitly adopted.

Why SMART on FHIR Matters

Without a standard authorization layer, interoperability stops at the data format. Two systems that both speak FHIR still cannot exchange data securely if they use incompatible auth mechanisms. SMART on FHIR is the security envelope that makes the FHIR RESTful API interoperable for apps.

ONC’s patient access API requirements, CMS payer-to-payer exchange, and the Da Vinci prior authorization workflows all assume SMART on FHIR as the authorization mechanism. Any team building a FHIR-connected app or API needs to understand where SMART App Launch applies.

Cross-References

  • FHIR — the data API that SMART on FHIR secures and extends
  • HL7 — the standards body that maintains the SMART App Launch IG
  • Implementation Guide — SMART App Launch is packaged and versioned as a FHIR IG

Last reviewed: February 7, 2026 Definition authority: HL7 International Content status: Canonical reference