What's the main difference between EHR launch and standalone launch?

EHR launch begins from inside the EHR's own clinical workflow with patient context already established, while standalone launch begins from your own application, requiring it to handle patient selection and initial authentication independently.

Does SMART on FHIR use standard OAuth 2.0, or something different?

It builds on standard OAuth 2.0 with healthcare-specific additions, like the launch context parameter and specific scope conventions, rather than being an entirely separate authorization protocol from the broader, widely used OAuth 2.0 standard.

What are scopes used for in a SMART on FHIR authorization request?

Scopes define exactly what data and level of access your application is requesting, such as read access to a specific patient's observations, letting the authorization server and user understand precisely what's being granted.

When should an application use backend services instead of an interactive launch?

Backend services suit automated, system-to-system integration scenarios without a human actively present, such as scheduled bulk data exports, while interactive launches suit applications a human user directly opens and uses in real time.

Can the same application support both EHR launch and standalone launch?

Yes, many applications are built to support both launch types, detecting which context they're running in and adjusting their initial flow accordingly, though this does require handling both code paths correctly.

What happens if an access token expires during a user's session?

Depending on the specific implementation, your application typically needs to either request a new token through a refresh token flow or prompt the user to reauthorize, rather than assuming the original token remains valid indefinitely.

SMART on FHIR Explained: How the Launch Flow Works

TL;DR

SMART on FHIR layers a standardized OAuth 2.0 authorization pattern on top of FHIR. An EHR launch starts inside the clinician's EHR workflow and passes a launch parameter that your app exchanges for patient and encounter context; a standalone launch starts from your own app, which then handles patient selection itself. The flow is: discover the server's authorization and token endpoints, redirect the user to authorize the requested scopes, exchange the returned authorization code for an access token, then send that token in the Authorization header on every FHIR call. Backend services skip the human entirely, using a signed JWT assertion in a client-credentials-style flow for unattended system-to-system work like Bulk FHIR export — still constrained by scopes.

Quick answer

SMART on FHIR combines FHIR's data model with a standardized OAuth 2.0 authorization pattern specifically designed for healthcare applications, letting an app launch either embedded inside an EHR's own clinical workflow or as a standalone application, while still authenticating through a consistent, predictable flow either way. The distinction between EHR launch and standalone launch, along with understanding how scopes control exactly what data an authorized app can access, is foundational to building any SMART on FHIR application correctly.

Below is how the two launch types actually differ, how the OAuth 2.0 authorization flow works step by step, and how backend services differ from user-facing app launches. If you're building a SMART on FHIR application, our free Mirth Health Check can review your specific implementation approach directly — part of the Mirth Connect support work we do for US healthcare teams.

EHR Launch vs Standalone Launch

SMART on FHIR supports two distinct launch patterns, and choosing the right one depends entirely on whether your application is meant to run embedded inside an EHR's own interface or independently outside it.

EHR Launch Starts From Inside the Clinical Workflow

In an EHR launch, a clinician clicks a link or button inside the EHR itself, which launches your application with patient and encounter context already established, without the user needing to separately select a patient again.

Standalone Launch Starts From Your Own Application

A standalone launch begins from your own application rather than from inside the EHR, requiring your app to handle patient selection itself, typically after the user authenticates directly through your application's own entry point.

The Launch Parameter Carries Context in EHR Launch

During an EHR launch, a launch parameter is passed to your application, which your app then exchanges during the OAuth flow to retrieve the actual patient and encounter context the EHR launch established.

Choosing the Right Launch Type for Your Use Case

Applications meant to support clinicians during an active patient encounter typically use EHR launch for that embedded context, while patient-facing applications accessed independently usually use standalone launch instead.

How the OAuth 2.0 Authorization Flow Works

SMART on FHIR builds on standard OAuth 2.0 with specific healthcare-relevant additions, and understanding the flow sequence matters for building both server-side and client-side handling correctly.

Discovering the Authorization Server Endpoints

Your application first discovers the FHIR server's specific authorization and token endpoints, typically through the server's published capability statement or a well-known configuration endpoint the SMART specification defines.

Redirecting the User to Authorize Access

Your application redirects the user to the discovered authorization endpoint, requesting specific scopes defining what data access you need, and the user, or the EHR context, then either grants or denies that access.

Exchanging the Authorization Code for an Access Token

After successful authorization, your application receives an authorization code, which it then exchanges directly with the token endpoint for an actual access token used to make authenticated FHIR API calls.

Using the Access Token for Subsequent API Calls

With a valid access token in hand, your application includes it in the Authorization header for every subsequent FHIR API request, until that token expires and needs to be refreshed or reacquired.

How Backend Services Differ From User-Facing Launches

Beyond the interactive, user-facing launch flows, SMART on FHIR also defines a backend services pattern for system-to-system integration that doesn't involve a human user actively authorizing each request.

No Human User Interaction Required

Backend services authentication uses a client credentials-style flow rather than requiring a human to actively log in and grant permission, making it suitable for automated, unattended system-to-system data exchange.

JWT Assertions Replace Interactive User Consent

Instead of an interactive authorization step, backend services use a signed JWT assertion proving the client's identity, which the authorization server validates before issuing an access token for that automated client.

Suited for Bulk Data Export and System Integration

Backend services authentication is commonly used alongside Bulk FHIR data export and other system-level integration scenarios where an automated process needs ongoing, unattended access rather than a single user session.

Scopes Still Control What Backend Services Can Access

Even without interactive user consent, backend services authentication still uses scopes to define exactly what data the automated client can access, maintaining the same principle of least-privilege access control.

When to call for help

If your app authorizes in one EHR sandbox but fails in another, the cause is usually endpoint discovery, a scope the server doesn't grant, or launch context that isn't being exchanged correctly. Our free Mirth Connect health check reviews your SMART on FHIR implementation approach as part of the standard diagnostic.

Book a Free Health Check →

Troubleshooting something specific? Send us the exact error, or check pricing for our support plans.

SMART on FHIR Explained: How the Launch and Authorization Flow Actually Works