SMART on FHIR

The authorization backbone of SMART on FHIR. It uses OAuth 2.0 for secure API access delegation and OpenID Connect for single sign-on identity verification.

• Authorization Code Grant: The primary flow for server-side apps, ensuring the client secret is never exposed to the browser.
• Scopes: Define granular access (e.g., patient/Observation.read) to specific FHIR resources.
• Token Introspection: Allows resource servers to validate the active status and scope of an access token in real-time.

A JSON document published by the app at a public URL that declares its capabilities and requirements to the EHR.

• Scopes Declaration: Lists the specific FHIR scopes the app requires to function.
• Launch Modes: Specifies whether the app supports EHR launch, standalone launch, or both.
• Redirect URIs: Defines the valid callback URLs for the authorization flow, preventing open redirect attacks.

A companion specification that enables clinical decision support services to be invoked at specific points in the clinician's workflow.

• Trigger Cards: The EHR displays a card to the clinician based on a hook (e.g., patient-view, order-select).
• Prefetch Data: The EHR sends relevant FHIR data with the hook request, reducing the number of API calls the CDS service must make.
• Decision Link: A CDS card can deep-link to a full SMART app for complex interactions, bridging simple alerts to rich applications.

The foundational data standard that SMART extends. FHIR defines a RESTful API and modular data models called resources (e.g., Patient, Observation) for exchanging healthcare data. SMART on FHIR applications rely on FHIR's API to read and write clinical data, making it the data layer beneath SMART's authorization and UI framework. Without FHIR's standardized resources, SMART apps would lack a consistent data interface across different EHR systems.

The industry-standard protocol that SMART on FHIR uses for secure delegated access. Key mechanisms include:

• Authorization Code Grant: The primary flow for server-side apps to obtain access tokens
• Client Credentials Grant: Used for backend service-to-service communication
• Scopes: Define granular permissions (e.g., patient/Observation.read) that limit what data an app can access
• Token Introspection: Allows resource servers to validate the active state of access tokens

This ensures apps only access data explicitly authorized by the user or system.

An identity layer built on top of OAuth 2.0 that SMART on FHIR uses for user authentication. OIDC provides:

• ID Tokens: JSON Web Tokens (JWTs) containing claims about the authenticated user
• fhirUser Claim: A SMART-specific extension that links the digital identity to a FHIR Practitioner or Patient resource
• Single Sign-On (SSO): Enables clinicians to launch multiple apps without re-entering credentials

This separates authentication (who you are) from authorization (what you can access).

A complementary specification that enables real-time, event-driven clinical decision support within a SMART on FHIR ecosystem. Key concepts:

• Hooks: Predefined triggers (e.g., patient-view, order-select) that fire when clinicians perform specific actions
• Cards: Structured responses (information, suggestions, links) displayed natively in the EHR UI
• Prefetch: Data sent with the hook request to reduce latency

CDS Hooks works alongside SMART to launch apps proactively at the point of care rather than requiring manual invocation.

An extension to the FHIR API designed for population-level analytics rather than individual patient access. SMART on FHIR apps targeting population health use this specification to:

• Export large datasets asynchronously in NDJSON format
• Request data for groups of patients (e.g., all diabetics in a practice)
• Receive completion notifications when exports finish processing

This enables SMART apps to perform cohort analysis and quality reporting across entire patient populations.