SMART on FHIR

The industry-standard authorization protocol that underpins SMART on FHIR's security layer. It enables a third-party application to obtain limited access to a FHIR API on behalf of a clinician or patient without exposing user credentials. The framework defines a series of authorization grants—specifically the authorization code grant for confidential apps—to issue scoped access tokens. This decouples authentication from authorization, allowing an EHR to verify identity while the app requests specific clinical data scopes.

A simple identity layer on top of OAuth 2.0 that standardizes how a SMART app verifies the identity of the end-user and obtains basic profile information. It introduces an ID Token, a JSON Web Token (JWT) that contains claims about the authenticated user, such as their fhirUser identifier. This allows the app to match the clinical context—like the currently selected patient—to the authorized user session, enabling single sign-on across disparate applications within the EHR environment.

The foundational data standard that SMART apps consume. FHIR structures healthcare data into discrete, web-friendly resources—such as Patient, Observation, and MedicationRequest—each with a defined URL endpoint and JSON/XML representation. SMART extends this by defining contextual scopes (e.g., patient/Observation.read) that map OAuth permissions directly to specific FHIR resource types and CRUD operations. This granularity ensures an app can only access the exact clinical data it needs.

A companion specification that defines a trigger-based, real-time integration pattern for SMART apps. Instead of a user launching an app, CDS Hooks allows the EHR to invoke a remote SMART service at specific points in the clinician's workflow—such as when opening a patient chart or signing an order. The EHR sends a hook containing the current clinical context, and the service returns decision support cards with actionable recommendations, enabling seamless, passive clinical decision support.

The core architectural goal of the SMART platform: enabling an ecosystem where a third-party application can run unmodified across different EHR systems. This is achieved through a standardized launch protocol where the EHR passes a launch context (patient, encounter, user) to the app. Because the app interacts only with the FHIR API and OAuth endpoints, it remains completely decoupled from any proprietary EHR database, allowing a growth hormone calculator or a cardiac risk app to be written once and deployed everywhere.

The specific sequence of interactions that governs how a SMART app is initiated from within an EHR session. It defines two primary launch flows: EHR Launch, where the app is invoked from a clinician's workspace and receives a launch context, and Standalone Launch, where the app is opened independently and must request authorization to access a FHIR endpoint. The protocol specifies the handshake of OAuth parameters—iss, launch, aud—that securely bind the app instance to the specific EHR tenant and user session.