Healthcare IT Glossary

What is SMART on FHIR?
SMART on FHIR Apps

For years, building an app that worked inside an EHR meant navigating proprietary interfaces, vendor-specific SDKs, and custom authentication schemes — a different integration for every EHR platform. SMART on FHIR changed that by defining a universal framework: build your app once, connect it to any EHR that supports the standard. It’s the app store model applied to healthcare.

Certifications

Tell Us Your Requirements

Our experts are ready to understand your business goals.

What is 1 + 1 ?

100% confidential & no spam

Definition of SMART on FHIR

SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources) is a standards-based framework that enables third-party applications to integrate with EHR systems using FHIR APIs and OAuth 2.0 authorization. It defines how apps launch within an EHR context, how they authenticate users and obtain authorization, and how they access patient data through FHIR endpoints.

SMART on FHIR was developed by Boston Children’s Hospital Computational Health Informatics Program (CHIP) and Harvard Medical School, with funding from ONC. It has since become a core component of the ONC Health IT Certification Program — certified EHR systems must support SMART on FHIR app launch and authorization as part of their 21st Century Cures Act compliance.

The framework solves three problems simultaneously: authentication (who is the user?), authorization (what data can this app access?), and context (which patient is selected, which encounter is active?). By standardizing all three, SMART on FHIR makes apps portable across EHR platforms — the same clinical decision support tool, patient engagement app, or analytics dashboard can work in Epic, Oracle Health, MEDITECH, or any other SMART-enabled system.

In simple terms: SMART on FHIR is the universal plug for healthcare apps — the standard that lets a single app connect to any EHR without custom integration for each vendor.

How SMART on FHIR Works in Healthcare

SMART on FHIR operates through a well-defined launch and authorization flow that connects the app, the EHR, and the authorization server.

App registration
Before an app can connect to an EHR, it must be registered with the EHR’s SMART authorization server. Registration provides the app with a client ID and defines the app’s redirect URI, scopes (what data it can request), and launch context (whether it launches from within the EHR or standalone). EHR vendors maintain app galleries or registration portals for this purpose — Epic’s App Orchard, Oracle Health’s app marketplace, and similar platforms.
EHR launch flow
The most common pattern is the EHR launch — the clinician is working in the EHR, selects a patient, and launches the SMART app from within the EHR interface. The EHR sends the app a launch token along with the FHIR server endpoint URL. The app uses this token to request an authorization code from the EHR’s authorization server, exchanges it for an access token, and uses that token to call the FHIR API for the patient in context.
Standalone launch flow
In the standalone launch, the app initiates the connection — the user opens the app outside the EHR (e.g., a mobile app or web portal), authenticates against the EHR’s authorization server, selects a patient, and receives an access token. This flow is used for patient-facing apps, care management tools, and applications that operate independently of the EHR workflow.
Scopes and permissions
SMART on FHIR uses OAuth 2.0 scopes to control data access granularity. Scopes follow the pattern /. — for example, patient/Observation.read grants read access to the current patient’s observations, while user/MedicationRequest.read grants the logged-in user access to medication data for any patient they’re authorized to view. Scopes are requested by the app and approved by the authorization server based on the app’s registration and the user’s permissions.
Clinical context
When an app launches from within the EHR, it receives context parameters — the current patient ID, the current encounter ID (if applicable), and the FHIR server endpoint. This context allows the app to immediately display relevant information without asking the clinician to re-select the patient.
Token refresh and session management
SMART access tokens are short-lived (typically 5–60 minutes). Apps use refresh tokens to obtain new access tokens without requiring the user to re-authenticate. Proper token lifecycle management — refresh before expiry, handle revocation gracefully, clear tokens on logout — is essential for production reliability.

Key SMART on FHIR Standards and Specifications

Modern
SMART App Launch Framework (IG)
The SMART App Launch Implementation Guide (currently v2.0) is the definitive specification. It defines the EHR launch sequence, standalone launch sequence, authorization/authentication flows, scope syntax, token handling, and capability discovery. All certified EHR systems must implement this IG as part of ONC certification.
Legacy
OAuth 2.0 and OpenID Connect
SMART on FHIR builds on OAuth 2.0 for authorization and optionally OpenID Connect for authentication. The authorization code grant flow is the required flow for confidential clients (server-side apps). Public clients (single-page apps, mobile apps) use PKCE (Proof Key for Code Exchange) to secure the authorization flow without a client secret.
Legacy
FHIR Capability Statement
Every SMART-enabled FHIR server publishes a Capability Statement (formerly Conformance resource) that advertises its SMART capabilities — supported launch modes, authorization endpoints, token endpoints, supported scopes, and FHIR resource profiles. Apps use the Capability Statement to discover how to connect to a specific EHR’s FHIR endpoint.
Modern
Backend Services (System-to-System)
The SMART Backend Services specification extends the framework for system-level access without a user in the loop — used for Bulk FHIR data export, population health analytics, and automated data pipelines. Backend services use asymmetric key authentication (JSON Web Tokens signed with a private key) instead of user-facing OAuth flows.
Legacy
CDS Hooks Integration
CDS Hooks is a companion standard that enables clinical decision support within the EHR workflow. When a clinician performs an action (opening a patient chart, ordering a medication, signing a note), the EHR fires a CDS Hook event to a registered service, which returns decision support cards — recommendations, alerts, or suggested actions. CDS Hooks services often launch SMART apps for detailed interaction when the clinician wants to act on a recommendation.
Building an SMART on FHIR integration? Let’s talk.
Book a free call

Implementation Considerations

Building SMART on FHIR apps requires attention to authorization mechanics, EHR-specific behaviors, security, and user experience.

HIPAA compliance applies to SMART apps. Any app that receives patient data through SMART on FHIR is handling protected health information. The app developer must comply with HIPAA Security Rule requirements — encryption, access controls, audit logging, and breach notification. If the app is provided to a covered entity, a Business Associate Agreement is required.

EHR vendor differences are real
While SMART on FHIR is a standard, every EHR implements it with vendor-specific nuances — different scope naming conventions, different token lifetimes, different capability statement structures, and different app review and approval processes. An app built against Epic’s SMART implementation may need adjustments for Oracle Health or MEDITECH. Test against every target EHR platform during development.
App review and approval processes vary
Each EHR vendor has its own process for reviewing, approving, and listing SMART apps. Epic’s App Orchard review can take weeks to months. Some vendors require security assessments, penetration testing, or SOC 2 certification. Plan for vendor approval timelines in your go-to-market strategy.
Scope management requires precision
Request only the scopes your app actually needs — over-requesting scopes triggers review scrutiny and may cause authorization servers to reject the request. Under-requesting means your app can’t access data it needs. Map your app’s data requirements to specific FHIR resources and SMART scopes before implementation.
Patient-facing apps face additional scrutiny
Under the 21st Century Cures Act, EHR vendors cannot unreasonably restrict patient-authorized apps from connecting through SMART APIs. However, app developers must still meet reasonable security requirements, and patients must provide informed consent for data access.
Performance and reliability matter
SMART apps that are slow to launch, fail to load patient data, or crash during clinical workflows will be abandoned by clinicians. Optimize app launch time, implement graceful error handling for API failures, and build offline-capable modes for unreliable network environments.

How Taction Helps with SMART on FHIR

At Taction, our team builds SMART on FHIR applications, implements SMART authorization infrastructure, and helps health IT vendors navigate EHR platform integration.

What we do:

Whether you’re building your first SMART app, deploying across multiple EHR platforms, or implementing SMART authorization infrastructure, our healthcare engineering team delivers the FHIR expertise and EHR platform knowledge these integrations demand.

SMART app development
We build clinical and patient-facing SMART on FHIR applications — from clinical decision support tools and care management dashboards to patient engagement apps and specialty workflow extensions.
SMART authorization server implementation
For EHR vendors and health IT platforms, we implement SMART App Launch authorization servers — handling OAuth 2.0 flows, scope management, token lifecycle, and FHIR Capability Statement publication.
Multi-EHR app deployment
We adapt SMART apps for deployment across multiple EHR platforms — handling vendor-specific differences in scope naming, capability discovery, and app review processes for Epic, Oracle Health, MEDITECH, and others.
Backend services integration
We build system-to-system integrations using SMART Backend Services for Bulk FHIR export, automated data pipelines, and population-level analytics without user-in-the-loop authentication.
CDS Hooks services
We build CDS Hooks services that integrate with EHR workflows and launch SMART apps for detailed clinical decision support interactions.

Explore Related Terms

Ready to discuss your SMART on FHIR project?

Schedule a free call

Ready to Discuss Your Project With Us?

Your email address will not be published. Required fields are marked *

What is 1 + 1 ?

What's Next?

Our expert reaches out shortly after receiving your request and analyzing your requirements.

If needed, we sign an NDA to protect your privacy.

We request additional information to better understand and analyze your project.

We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.

If you're satisfied, we finalize the agreement and start your project.