Overview
SMART on FHIR (Substitutable Medical Applications and Reusable Technologies) is the open standard that layers OAuth 2.0 authorization and OpenID Connect identity on top of FHIR APIs to create a secure, standardized launch framework for third-party healthcare applications. SMART is what makes it possible for a patient-facing app to connect to any certified EHR, for a clinician-launched app to gain context about the current patient in the EHR, and for an app to request specific data scopes rather than unrestricted access.
The SMART App Launch specification defines two flows. The SMART Standalone Launch flow is used by patient-facing apps: the patient logs in through the EHR's patient portal OAuth, authorizes the app's requested scopes, and the app receives an access token usable against the FHIR API. The SMART EHR Launch flow is used by clinician-launched apps: the clinician launches the app from within the EHR, the EHR provides launch context (current patient, encounter), and the app receives an access token scoped to that context.
Scope-based authorization is a core SMART feature. Apps request specific scopes (patient/Observation.read to read the patient's observations, user/Patient.read to read patient records as the logged-in user, etc.), and the EHR authorization server grants only the requested scopes. This prevents apps from getting unrestricted data access and enables fine-grained control over what third-party apps can see and do.
The ONC Cures Act requires certified EHRs to support SMART App Launch for both patient and provider flows. This is what enables the patient-access ecosystem that regulations envisioned: any certified EHR supports any SMART-compliant patient app without the app requiring bespoke integration per EHR vendor. Similarly, clinician-facing apps that register with an EHR's SMART endpoint can be launched by clinicians and gain context without separate vendor agreements.
SMART Backend Services adds system-level authentication for server-to-server FHIR access without patient or clinician presence. Backend services use JWT assertion flows rather than interactive OAuth consent; they are used for bulk-data extract operations, payer-to-payer transfers, and other programmatic integrations.
For RCM vendors and healthtech apps, SMART on FHIR support has become a baseline capability. An integration that requires custom OAuth per EHR vendor is dramatically more expensive to build and maintain than one leveraging the standardized SMART flow. Competitive positioning in the healthtech market increasingly depends on SMART conformance.
From a board-reporting standpoint, SMART on FHIR belongs in the compliance committee's quarterly dashboard. The reporting line should include volume, exception rate, and any open remediation action; reviewers tie SMART on FHIR metrics to the broader compliance program KPIs so an emerging SMART on FHIR risk surfaces before it becomes a formal finding. Pairing the SMART on FHIR trend with fhir api gives the committee a single view of whether the control environment is strengthening or drifting.
Industry benchmark
ONC certification requires SMART App Launch support for both patient and provider flows as of 2023. Major EHR vendors (Epic, Cerner/Oracle, Allscripts, Meditech, athenahealth, eClinicalWorks, NextGen) all support SMART.
Worked example
A diabetes-management patient app supports SMART standalone launch. A patient at a hospital using Epic opens the app, selects their hospital, logs into MyChart through the SMART flow, and grants the app patient/Observation.read and patient/MedicationRequest.read scopes. The app pulls the patient's A1c results and medication list via FHIR R4 APIs and renders a personalized care plan.
Frequently asked questions — SMART on FHIR
What does SMART stand for?
Substitutable Medical Applications and Reusable Technologies. The standard emphasizes interchangeability: any SMART-conformant app should work with any SMART-conformant EHR.
Is SMART required for all FHIR apps?
Required for apps that need authorized access to protected patient data via certified EHR FHIR endpoints. Open-data use cases (public formulary data, public provider directories) may not need SMART.
What is SMART Backend Services?
A variant of SMART using JWT assertion flows for server-to-server integration without user consent. Used for bulk-data export, payer-to-payer data transfer, and other programmatic integrations.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.