SMART on FHIR is a set of open standards that lets third-party health applications connect securely to electronic health record (EHR) systems. Think of it like an app store model for healthcare: just as your phone lets you install apps that access your camera or contacts with your permission, SMART on FHIR lets clinical apps plug into hospital systems and access specific patient data with controlled authorization. The name combines two technologies: SMART (Substitutable Medical Applications, Reusable Technologies) and FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”), which is the modern data format for exchanging health information.
Where SMART on FHIR Came From
The SMART project launched in 2010 with a four-year, $15 million grant from the Office of the National Coordinator for Health Information Technology (ONC). It was originally a health systems engineering project at Boston Children’s Hospital designed to build the fundamental building blocks of a health information economy. The core problem it addressed was that health apps were locked into whichever EHR system they were built for. An app written for Epic couldn’t work in Cerner, and vice versa. SMART on FHIR created a universal layer so that a single app could run on any compliant EHR, much like a website works in any browser.
Federal regulation accelerated adoption. The 21st Century Cures Act directed the healthcare industry to adopt standardized APIs that allow individuals to securely access their structured health information using smartphone applications. The ONC Certification Program now enforces these requirements, meaning EHR vendors must support standardized API access to maintain their certification. In practice, this pushed major vendors to build SMART on FHIR support into their platforms.
How the Two Pieces Fit Together
FHIR is the data language. It defines how health information (lab results, medications, allergies, encounters) is structured and exchanged between systems. SMART is the security and launch framework built on top of it. SMART uses OAuth 2.0, the same authorization standard that powers “Sign in with Google” buttons across the web, to control which apps can access which data and for how long.
Together, they solve two problems at once: FHIR ensures that apps can read and write health data in a consistent format regardless of the underlying EHR, and SMART ensures that this access is authenticated, authorized, and limited to exactly the data the app needs.
How Apps Launch and Connect
There are two ways a SMART app can start up, and the difference matters for how data flows.
In an EHR launch, the app opens from inside the EHR itself. A clinician might click a button in their patient chart, and the EHR opens the app in a new window or embedded frame. The EHR passes along context automatically: which patient is open, which encounter is active, who the logged-in user is. The app receives an opaque identifier that it sends back to the EHR’s authorization server, which then grants access based on that specific clinical context. The clinician never has to re-enter patient information or log in again.
In a standalone launch, the app starts outside the EHR, perhaps from a patient’s phone or a separate website. Since there’s no EHR session to pull context from, the app requests the context it needs during the authorization process. It might declare that it needs a patient ID or an encounter ID, and the authorization server handles acquiring that information, often by prompting the user to select a patient or log in.
How Permissions Work
SMART on FHIR controls data access through a precise scope system that specifies exactly what an app can see and do. Scopes follow a pattern: who the access is for, what type of data, and what operations are allowed (create, read, update, delete, search).
- Patient-level scopes limit access to a single patient’s data. An app might request permission to read a patient’s lab observations, or to add new blood pressure readings, or to read demographic information only.
- User-level scopes allow access to whatever data the logged-in user is authorized to see. A clinician’s scheduling app could manage all appointments that clinician has access to, potentially spanning multiple patients.
- System-level scopes describe access for automated processes rather than individual users. An alerting engine might monitor all lab observations across a health system in read-only mode, or a bulk data export might pull information across an entire FHIR server.
These scopes can get very specific. Version 2.0 of the SMART specification introduced finer-grained constraints using search parameters. For example, an app could request access to only laboratory observations for a patient, excluding other observation types like vital signs or social history. This granularity means a blood glucose tracking app doesn’t need to see your mental health notes.
Beyond clinical data scopes, there are also scopes for identity verification and session management. An app can request to authenticate the end user, obtain a representation of the current user as a FHIR resource, or request tokens that keep working as long as the user stays online (or even after they log out, for background processes that need continued access).
What This Means for Clinicians
The practical payoff is reduced friction. When an app launches from within an EHR, SMART on FHIR automatically passes along details about the user, the patient, and the clinical encounter. This eliminates manual lookups and duplicate data entry. A cardiologist using a SMART-enabled app can instantly view a patient’s complete history, including labs, medications, and encounters from multiple hospitals, without re-entering the patient’s name or switching between systems. That unified view can reduce redundant tests and cut administrative time.
For patients, SMART on FHIR is the reason you can download a health app on your phone and pull in your medical records from your hospital’s patient portal. The app connects to the hospital’s FHIR server, you authorize access through a familiar login screen, and the data flows in a standardized format.
Clinical Decision Support With CDS Hooks
SMART on FHIR also integrates with a companion standard called CDS Hooks, which triggers real-time clinical decision support at key moments in a provider’s workflow. When a clinician starts ordering a medication or first opens a patient’s chart, the EHR can automatically send clinical context to an external decision support server. That server evaluates the information and returns alerts, suggestions, or a link to launch a SMART app with more detail.
A concrete example: prescription drug monitoring. When a provider begins ordering a controlled substance, a CDS Hook fires at the start of the ordering process. The decision support server checks the state’s prescription drug monitoring database and, rather than returning sensitive patient history directly in the alert, sends back a link to a SMART app where the provider can securely review the full details. This keeps sensitive data within the app’s controlled environment while still surfacing timely warnings at the point of care.
EHR Vendor Support
Major EHR platforms support SMART on FHIR and provide developer tools for building and testing apps. Oracle Health (formerly Cerner) maintains a self-registration developer console and a sandbox environment where any developer can run a SMART app against test data. The SMART Health IT project itself hosts a public launcher at launch.smarthealthit.org that developers use to test their apps against simulated EHR environments. Epic, Oracle Health, and other certified EHR vendors all provide FHIR API endpoints as part of their certification requirements under the Cures Act.
This vendor-neutral design is the core promise of SMART on FHIR: build an app once, and it runs on any compliant system. For health systems, it means access to a broader ecosystem of specialized tools without being locked into a single vendor’s app marketplace.