SMART on FHIR

SMART mandates OAuth 2.0 for delegated authorization, allowing patients and clinicians to grant third-party applications scoped access to FHIR resources without sharing their primary EHR credentials. This framework supports authorization code and client credentials grant types, ensuring that apps receive short-lived access tokens with precisely defined permissions. The use of PKCE (Proof Key for Code Exchange) is required for public clients to prevent authorization code interception attacks, establishing a robust trust boundary between the data holder and the application.

SMART extends OAuth 2.0 with OpenID Connect to provide a federated identity layer. This enables a clinician to authenticate once within their EHR session and seamlessly launch multiple distinct SMART applications without re-entering credentials. The identity token (ID Token) conveys verified user attributes, such as a fhirUser claim linking the authenticated identity to a specific FHIR Practitioner or Patient resource. This unified identity model simplifies user management and creates a cohesive clinical workflow across disparate tools.

When a clinician launches a SMART app from within the EHR, the platform passes a structured launch context as part of the authorization handshake. This context includes critical clinical parameters such as the current patient ID, encounter ID, and user role. The app uses these parameters to immediately orient itself to the correct patient record and clinical workflow, eliminating manual search. This tight integration ensures the application presents relevant, contextualized information at the moment of launch, reducing cognitive load and preventing patient mismatches.

SMART defines a granular permission model using OAuth scopes that align directly with FHIR resource types and interaction verbs. An app requesting patient/Observation.read is authorized to read only a specific patient's vital signs, not their entire record. Scopes can be further constrained to patient-level, user-level, or system-level access, enabling distinct authorization profiles for patient-facing apps, clinician dashboards, and backend analytics services. This fine-grained control is essential for enforcing the principle of least privilege in clinical data sharing.

A core design goal of SMART is application substitutability: a single SMART-compliant application can run, without modification, on any EHR system that implements the SMART on FHIR specification. This is achieved by standardizing the launch protocol, authorization flow, and data API. The app developer writes to the FHIR interface, not to a proprietary vendor API. This decoupling fosters a competitive marketplace of clinical tools, allowing healthcare organizations to select best-of-breed applications independently of their underlying EHR infrastructure.

For server-to-server communication where no direct user interaction occurs, SMART defines the Backend Services profile. This specification uses the OAuth 2.0 client credentials grant, augmented with a signed JSON Web Token (JWT) for client authentication. This allows trusted analytical pipelines, population health tools, and machine learning systems to obtain system-level access to FHIR Bulk Data APIs. The JWT assertion includes claims about the requesting system's identity and the requested scope, enabling automated, secure data access for non-interactive workloads.

The foundational HL7 standard for healthcare data exchange that SMART apps use as their data layer. FHIR defines Resources—granular clinical and administrative concepts like Patient, Observation, and MedicationRequest—exposed via a RESTful API. SMART on FHIR relies on FHIR's modern web technologies (JSON, OAuth 2.0) to enable apps to read and write EHR data without custom integrations.

• Uses RESTful API with JSON/XML payloads
• Defines 150+ base Resources for clinical concepts
• Enables plug-and-play app interoperability across EHRs

The industry-standard authorization protocol that SMART on FHIR uses for secure, delegated access to patient data. SMART defines specific OAuth 2.0 profiles for healthcare, including authorization code flow for user-facing apps and client credentials flow for backend services. This ensures apps can only access the specific FHIR resources a user or system has explicitly authorized.

• Supports scoped access tokens tied to specific FHIR resources
• Enables single sign-on across healthcare applications
• Prevents unauthorized data access through token-based authentication

An identity layer built on top of OAuth 2.0 that SMART on FHIR uses for user authentication. OIDC provides an ID token (a signed JSON Web Token) containing claims about the authenticated user, such as their identity and clinical role. This allows SMART apps to verify who is using the application and tailor the experience based on the user's role (physician, nurse, patient).

• Provides signed ID tokens with user identity claims
• Supports fhirUser claim linking identity to a FHIR Practitioner resource
• Enables role-based access control within apps

An HL7 specification for invoking clinical decision support services directly from a clinician's EHR workflow. CDS Hooks uses a hook-based pattern—the EHR fires a trigger (e.g., patient-view, order-select) and sends a FHIR payload to a CDS service, which returns actionable guidance cards. SMART on FHIR apps can integrate with CDS Hooks to deliver real-time, context-aware recommendations.

• Triggers on workflow events like patient-view or order-sign
• Returns guidance cards with suggestions, links, or SMART app launches
• Uses FHIR as the data payload format for context

A FHIR specification defining an asynchronous API for exporting large, flat datasets of patient-level data. Unlike real-time FHIR queries, Bulk Data Access initiates an export job, compresses the results as NDJSON files, and provides a download link. SMART Backend Services authorization is commonly used to secure these population-level exports for analytics and machine learning.

• Designed for population-level analytics and ML training
• Uses asynchronous export with NDJSON format
• Secured via SMART Backend Services authorization

A FHIR specification defining the minimum conformance requirements for accessing patient data in the United States, based on the U.S. Core Data for Interoperability (USCDI) standard. SMART apps targeting the U.S. market must align with US Core profiles, which constrain FHIR resources like Patient, AllergyIntolerance, and Observation to ensure consistent data representation across EHR systems.

• Mandates specific FHIR profiles for U.S. interoperability
• Based on USCDI v3 data classes and elements
• Required for ONC Health IT Certification compliance