SMART on FHIR is an open technology standard that lets third-party apps plug into electronic health record (EHR) systems securely, much like apps on a smartphone connect to the phone’s operating system. It combines two pieces: SMART (Substitutable Medical Applications, Reusable Technologies), which handles app launch and security, and FHIR (Fast Healthcare Interoperability Resources), which provides a standardized way to read and write clinical data. Together, they give developers a single set of rules for building health apps that work across different EHR platforms instead of being locked to one vendor.
Where SMART on FHIR Came From
The project started in 2010 at Boston Children’s Hospital’s Computational Health Informatics Program (CHIP), led by Kenneth Mandl, with federal funding to create a standard API for digital health data exchange. The original SMART platform was updated in late 2013 to adopt FHIR, a then-emerging draft standard from Health Level Seven International (HL7), the nonprofit that publishes most healthcare data standards. That combination became SMART on FHIR.
Mandl’s team later worked with U.S. legislators to embed standardized API requirements into the 21st Century Cures Act. The Office of the National Coordinator for Health IT (ONC) turned those requirements into regulation, effectively mandating that certified EHR systems support standardized APIs so patients and providers can access health information through apps of their choosing.
How the Two Layers Work Together
FHIR organizes clinical data into “resources,” each representing a distinct concept: a patient, an observation (like a blood pressure reading), a medication, an allergy, a lab result. Every resource has a defined structure with specific fields and data types, which means an app can request a patient’s medication list from any FHIR-compliant system and get data back in a predictable format.
Raw FHIR resources alone don’t guarantee that two hospitals use the same terminology for the same concept. That consistency comes from “profiles,” which are additional rules layered on top of resources. A profile might require that blood pressure readings always use a specific coding system or that medication names follow a particular vocabulary. From SMART’s perspective, profiles are what make an app truly portable: they lock down exactly how data should look so an app built for one health system doesn’t break when connected to another.
SMART provides the launch and security layer on top of FHIR’s data model. It defines how an app registers with an EHR, how a user grants permission, and how the app receives an access token that lets it call the FHIR API. Without SMART, every EHR vendor would implement its own login and authorization flow, and developers would need custom code for each one.
Security and Authorization
SMART on FHIR uses OAuth 2.0 for authorization, the same protocol behind “Sign in with Google” buttons across the web. When you launch a SMART app, the EHR’s authorization server asks you (or an administrator) to approve specific permissions before the app can access any data. The app never sees your EHR password.
For verifying who the user actually is, SMART layers on OpenID Connect, a standard identity protocol. Apps that need to know the logged-in user’s identity request two specific permissions: “openid” and “fhirUser.” All SMART apps are also required to support PKCE (Proof Key for Code Exchange), a technique that prevents attackers from intercepting or injecting authorization codes during the login flow. Confidential apps (those running on a server rather than entirely in a browser) can use cryptographic keys for additional authentication.
Two Ways to Launch an App
SMART defines two launch sequences. In an EHR launch, a clinician clicks on an app from within their EHR. The EHR passes along context automatically: which patient’s chart is open, which encounter is active, who the logged-in user is. The app doesn’t need to ask for any of that information because it arrives as part of the launch.
In a standalone launch, the app starts outside the EHR, perhaps from a browser bookmark or a patient’s phone. Because there’s no EHR session providing context, the app has to request it. For example, a standalone app might ask the user to select a patient at launch time by including a “launch/patient” permission in its request. Both launch types end at the same place: the app holds a secure access token and knows which FHIR server to call.
Scopes Control What Apps Can Access
SMART uses a granular permission system called scopes. Each scope maps directly to a FHIR resource type and specifies what the app can do with it. The permission letters are straightforward: c for create, r for read, u for update, d for delete, and s for search. An app that only needs to view lab results might request “patient/Observation.rs,” granting read and search access to observations for the current patient and nothing else.
There are three levels of access:
- Patient-level scopes (patient/*.rs) restrict data to a single patient. This is typical for patient-facing apps.
- User-level scopes (user/*.cruds) grant access to whatever the logged-in user is already allowed to see in the EHR. A physician would see more than a billing clerk.
- System-level scopes (system/*.cruds) are used by backend services running without a user present, like overnight data analytics jobs. Access is governed by pre-configured policies on the server.
Scopes can be narrowed even further with query parameters. For instance, an app could request only laboratory observations by appending a category filter to the scope string, ensuring it never receives other types of observations like vital signs.
CDS Hooks: Triggering Apps Automatically
A related standard called CDS Hooks extends SMART on FHIR by letting the EHR automatically suggest apps at the right moment. Instead of a clinician remembering to open an app, a “hook” fires when a specific event occurs, like opening a patient’s chart or signing an order. A CDS Hooks service then checks the patient’s data through the FHIR server and returns a “card” to the EHR with guidance: a text recommendation, a suggested action, or a direct link to launch a SMART app.
The workflow looks like this in practice: a clinician opens a chart, the EHR fires the hook, the CDS service retrieves relevant patient data via FHIR, runs its logic, and if the patient meets certain criteria, a prompt appears inside the EHR. Clicking that prompt can launch a SMART app with a single click, landing the user on exactly the right page. A trial published in the Journal of the American Medical Informatics Association tested this approach with the MDCalc clinical calculator app, using CDS Hooks to recommend specific calculators based on patient context.
Because CDS Hooks also uses FHIR as its data model, developers can share logic between the CDS service and the app itself, reducing the work of building both.
Which EHR Systems Support It
The major EHR vendors supporting SMART app launches include Epic, Cerner (now Oracle Health), Allscripts, athenahealth, Intersystems, and Meditech. Each provides sandbox environments where developers can test their apps against simulated patient data before deploying in production. The SMART App Gallery, maintained by the SMART Health IT project, lists apps that have been built on the standard, ranging from cardiovascular risk calculators and newborn bilirubin charts to AI-powered clinical documentation tools and patient-controlled data management platforms.
U.S. Regulatory Requirements
The 21st Century Cures Act and ONC’s Cures Act Final Rule require certified health IT systems to support standardized APIs for patient and provider access to electronic health information. While the rule doesn’t name SMART on FHIR by letter, the technical standards it references (FHIR R4, OAuth 2.0-based authorization) align directly with the SMART on FHIR specification. The regulation also includes information blocking provisions that prevent healthcare organizations from unreasonably restricting access to electronic health data. These rules have been the primary driver behind widespread EHR vendor adoption of FHIR-based APIs in the United States.
Why It Matters for Patients and Clinicians
Before SMART on FHIR, health apps were typically custom-built integrations tied to a single EHR vendor. If a hospital switched EHR systems, those apps broke. If a developer wanted to reach clinicians across multiple health systems, they had to build and maintain separate integrations for each one. SMART on FHIR changes that equation by making apps substitutable: a cardiovascular risk calculator that works in Epic should also work in Cerner, because both systems speak the same API and security language.
For patients, this standard underpins the growing number of apps that can pull your health records directly from your provider’s system onto your phone. For clinicians, it means access to specialized tools (growth charts, risk scores, clinical decision support) that launch inside the EHR they already use, populated with the patient’s actual data, without manual data entry. The design philosophy, as Mandl put it, is simple: “Information is more powerful when it’s shared.”