SMART on FHIR: How EHR Apps Launch Without Breaking Workflow

Doctors are spending more time on screens, even when they see fewer patients. A study published in Health Affairs in February 2026, covered by Healthcare Dive, found that primary care physicians saw 32.6% fewer patients, but their EHR time dropped by only 21.2%. As a result, EHR time per visit increased by more than 21%.

That points to a problem beyond the patient visit itself. Doctors also have to deal with logins, separate applications, patient searches, and switching between systems to get the information they need.

These tasks may seem small, but they add friction to the clinical workflow. When an app can open with the right patient and user context already available, doctors have fewer steps to repeat.

This is one of the problems it is designed to address. It gives healthcare apps a standard way to connect with EHRs, authenticate users, get the right permissions, and open within the clinician’s workflow.

In this guide, you’ll learn what SMART on FHIR actually is, how an EHR launch works step by step, what changed with SMART v2 in 2026, and why some apps still slow doctors down even when they technically follow the rules.

SMART on FHIR is an open standard that helps third-party apps securely connect with EHR systems. It uses OAuth 2.0 and OpenID Connect to authenticate the user, authorize access, and launch the app with the right context. In an EHR launch, the user can often use the existing EHR session instead of signing in again.

FHIR handles the health data itself. It gives apps a standard way to read and write information using resources such as Patient, Observation, and Condition.

The name explains what it does. SMART stands for Substitutable Medical Applications and Reusable Technologies. The goal is to make it easier to build an app that can work with different EHRs without creating a new integration for each one.

It was created at Boston Children’s Hospital and Harvard Medical School, and is now maintained by HL7 International as part of FHIR. The idea was first explained in a 2016 paper in JAMIA, which described a shared, standard way for EHR apps to work together. That same idea still applies today.

At this point, FHIR and SMART on FHIR can sound like the same thing. They aren’t. FHIR handles the data, while SMART on FHIR handles how an app securely connects to it.

FHIR and SMART on FHIR work together, but they have different jobs.

Now that you know what it is, let’s look at why it matters for healthcare teams in 2026.

Doctors often need more than the information shown in the EHR. They may need to open another app, log in again, or search for the same patient.

SMART on FHIR can reduce these extra steps. An app can open from the EHR with the right patient and user context already available, so the doctor doesn’t have to start over.

This makes it easier to use third-party apps without taking the doctor away from the workflow.

There is also an important change for healthcare organizations in 2026. Since January 1, 2026, SMART App Launch v1.0.0 is no longer an option for ONC certification. SMART App Launch v2.0.0 is the required baseline, with v2.2.0 also available as an approved version.

Version 2.2.0 is the current published release. It also adds stronger access controls. Certified systems must be able to revoke an authorized app’s access at a patient’s request within one hour.

What this means for buyers: When evaluating a SMART on FHIR app, check which SMART App Launch version it supports. An app still built around version 1 may need updates to meet current requirements.

So, what does that connection actually look like when a clinician launches a SMART on FHIR app? Let’s find out:

Most clinicians never think about what happens after they click an app. That’s because the process should happen in the background. But for developers and buyers, those few seconds matter. They determine whether the app opens with the right patient and context.

The process starts inside the patient’s chart. A button or tab lets the clinician open the app without leaving the EHR or searching for it somewhere else.

When the clinician clicks the app, the EHR sends its launch URL with two important values: iss, which points to the FHIR server, and launch, a one-time token linked to the current patient and session.

The app checks the FHIR server’s /well-known/smart-configuration file. This tells it where to send authorization and token requests. This is better than hardcoding these addresses because the EHR may change its server setup.

The app requests the scopes it needs. Depending on the EHR and existing session, the user may be able to continue without another login, although an authorization or consent step may still appear.

After authorization, the app receives an access token and the context it needs. This can include the patient, the current encounter, and fhirUser, which identifies the logged-in user.

The app uses the access token to request data from the FHIR API. It then opens with the correct patient already selected. The clinician doesn’t need to search for the patient or enter the same information again.

That’s how the app gets launched and connected to the right patient. But there’s more happening in the background: the app also needs the right context and permissions to work safely.

A SMART on FHIR launch gives the app more than an access token. It also gives the app useful information about the patient, visit, and person using it. This helps the app open in the right place without asking the clinician to enter the same details again.

• Patient and encounter: These tell the app which patient the clinician is viewing and which visit or encounter they are working on. This gives the app the right patient context as soon as it opens.
• fhirUser: This identifies the person using the app, such as a doctor, nurse, or other clinical staff member. It tells the app who is signed in, not just which patient is being viewed.
• need_patient_banner: This tells the app whether it needs to show its own patient banner. If the EHR already shows the patient’s name and other details, the app can avoid displaying a second banner and making the screen confusing.
• smart_style_url: This lets the app get styling information from the EHR, including fonts, colors, and spacing. This helps the app look more consistent with the EHR instead of feeling like a separate tool.
• fhirContext: This can give the app additional launch information beyond the patient and encounter, such as references to other FHIR resources. The exact context depends on what the EHR supports.

Together, this context helps the app open where the clinician needs it, without adding more steps to the workflow.

Once the app knows who and what it is working with, it also needs permission to access health data. That’s where SMART scopes come in.

Scopes tell the app what data it can access. In SMART v1, some scopes were broad. For example, patient/*.read could give the app read access to many types of data for a patient, even if it only needed a small part of that data.

SMART App Launch v2 supports more specific scopes. Instead of asking for broad access, an app can request only the data it needs, such as patient/Observation.rs for observations or patient/Condition.rs for conditions. The letters at the end show which operations the app can perform, such as r for read and s for search.

HTI-1 takes this further for Condition and Observation data. Certified systems must support finer-grained scopes that can restrict access using the category search parameter, allowing access to specific types of Condition and Observation data.

For security teams, this makes access requests easier to review. An app that asks only for the data it needs is easier to understand and approve than one asking for broad access without a clear reason.

SMART on FHIR covers more than the launch-from-the-chart pattern described earlier. There are four distinct ways an app can connect, and each one fits a different job.

EHR launch: This is the pattern most clinical tools use. The clinician is already inside the EHR, so the app opens with the current patient already available. This is useful for tools doctors need while working on a patient’s chart.

Standalone launch: Here, the app opens first, outside the EHR. The user then signs in and selects a patient. This works well for patient-facing apps or other tools that don’t start inside an EHR.

Backend services: These services work without a person using the app. A server connects to the FHIR system on its own, often to move or sync data or support analytics. Nothing needs to be opened on a clinician’s screen.

CDS Hooks: This starts with an event in the EHR, such as opening a patient’s chart or signing an order. The EHR can then show a suggestion or card, which may give the clinician the option to open a SMART app.

Tip: These approaches can also work together. For example, a SMART app can be launched from the EHR while backend services run in the background to sync data or support analytics.

The connection method is only one part of the picture. Next, let’s look at the types of apps that use SMART on FHIR and what they actually do.

There are different types of SMART on FHIR apps, depending on what they are built to do. Some help doctors make decisions, while others help with patient care, documentation, or communication between care teams.

1. Clinical decision support apps
These help doctors make decisions using information already in the patient’s chart. For example, a risk calculator can open from the EHR, use the patient’s data, and show the result without the doctor entering the information again.

2. Specialty apps
These are built for a specific clinical task or medical area. For example, SMART Growth Chart and SMART BP Centiles are open-source examples from SMART Health IT. They help clinicians check a child’s growth or compare blood pressure readings with expected ranges, right from the EHR.

3. Patient-facing Apps
These are built for patients instead of doctors. A patient can open the app, sign in, and access their own health information. These apps can be used to view medical records, track a condition, or manage appointments.

4. AI Documentation Apps
These apps help clinicians create notes and other documentation. An AI scribe can use SMART on FHIR to get the patient and encounter details it needs, so the clinician does not have to enter the same information again.

5. Care Coordination Apps
These help different healthcare teams work together. For example, a referral app can pull patient information from the EHR and use it to create or manage a referral without making the clinician copy the details into another system.

These are some of the main types of SMART on FHIR apps. But having the right connection and a useful purpose does not automatically mean an app will be easy to use. An app can follow the SMART standard and still create problems for clinicians.

A SMART on FHIR app can meet the technical requirements and still make a clinician’s work harder. The problems are usually simple things such as the wrong patient opening, an extra login, slow loading, or too much data access.

Fixing these issues can make the app easier and less frustrating for clinicians to use.

Epic, Oracle Health, and athenahealth each have their own process for registering and testing SMART on FHIR apps. Knowing where to start can save time, especially when moving from a sandbox to a live hospital environment.

Epic’s old App Orchard program is no longer used. It closed in December 2022 and was replaced by Epic Vendor Services and Showroom. Epic Vendor Services is the paid program for vendors that need technical support and design review. Showroom is Epic’s directory where customers can discover and evaluate available apps.

Vendors start through Epic’s developer portal, where they can register the app, get a client ID, and test it in the sandbox.

Getting listed on Showroom does not automatically make the app available at every hospital. Each Epic customer still needs to review and activate the app based on its own security and technical requirements.

Timeline: Epic integration timelines vary based on the app, FHIR resources, write access requirements, testing, and the hospital’s review process. Complex integrations can take several months.

Oracle Health uses Code Console for app registration and testing. Developers can use code Console and the sandbox to test authentication, scopes, and API access before working with a customer on production provisioning.

For endpoint, scope, and SMART on FHIR requirements, Oracle’s Millennium SMART on FHIR documentation is the main reference.

athenahealth has its own developer portal and Marketplace for registering and publishing apps. Developers can use these resources to build and test integrations before making an app available to customers.

The review process can vary based on what the app does, which data it needs, and whether it only reads data or also writes data back to the EHR.

For organizations deciding whether to build these integrations in-house or get help from an experienced team, see our guide on how to customize Epic hospital software.

SMART on FHIR is also becoming useful for AI tools that need access to EHR data. Ambient AI scribes are one example. They can use SMART on FHIR to pull the patient and visit information they need while working inside the clinical workflow.

Ambient AI scribes are already using this approach. AI documentation tools can use SMART on FHIR and other EHR integration methods to access the patient and encounter information they need within the clinical workflow.

Common integration methods for third-party AI tools include FHIR APIs, SMART on FHIR apps, and direct EHR vendor APIs.

Scopes as guardrails are especially important for AI apps. An AI feature can only access the healthcare data allowed by its scopes. If the scopes are too broad, the AI tool may get access to patient data it does not actually need.

AI during development can help teams map FHIR data, create test cases, and find integration issues earlier. But it does not replace human review, real-world testing, or audit logs. These are still needed before an AI app is used with patient data.

With the connection and AI use cases covered, the next question is how to keep these apps secure and compliant when they handle sensitive health data.

At Bacancy, we help healthcare teams build SMART on FHIR apps that work with their EHR systems. Our healthcare IT services and solutions cover integration, data access, security, and testing, while keeping the clinician’s workflow in mind.

• Connect with major EHRs: We work with EHRs such as Epic and Oracle Health, helping teams handle SMART on FHIR connections, registration, authentication, and API testing.
• Get the right patient context: When the app opens, it needs the right patient, visit, and user information. Our team makes sure this context is passed correctly so clinicians don’t have to enter the same details again.
• Work with FHIR data: FHIR resources and APIs let the app access the healthcare data it needs. We handle the data flow based on the EHR, use case, and whether the app needs to read or write information.
• Keep data access focused: Instead of asking for broad access, the app requests only the scopes it needs. We plan these permissions early to keep access clear and make security reviews easier.
• Test beyond the sandbox: A sandbox cannot show every issue that may appear in real use. Our testing covers app launches, patient context, authentication, and how the app behaves inside the EHR.
• Build security into the app: Security is considered throughout development, not added at the end. Our healthcare projects follow HIPAA-aligned practices and include the access controls needed to protect patient data.
• Add AI where it makes sense: AI can support tasks such as clinical documentation and data review. When we add AI to a healthcare app, access to patient data stays controlled, with testing and human review built into the process.