Understanding SMART on FHIR

Last updated: Aug 28, 2023

The SMART App Launch Framework with Redox enables single sign-on (SSO) and API requests via the Redox FHIR® API or Redox Data Model API all in one session. Learn more about SMART App Launch.

We make developing SMART applications easier by providing the following features:

  • OAuth normalization: Redox handles minor differences in OAuth implementations.
  • Access token storage: Redox stores access tokens for you, and automatically refreshes them as needed.
  • Decoupling of SSO and FHIR® API: Use SSO with SAML, SMART, or any number of other SSO schemes.

Using SMART applications with Redox allows you to quickly and efficiently integrate with new healthcare organizations and their EHR systems with minimal code changes.

Flow for SMART app launch

Follow the outline below to get a better understanding of how SMART App Launch works with Redox:

  1. Either the patient or a provider at a healthcare organization initiates a SMART App Launch.
  2. The launch URL is a Redox URL, which Redox uses to look up your dashboard configuration, then redirects the request to the authorization server.
  3. The authorization server prompts the patient or provider to authorize your application—not Redox—to access the relevant data.
  4. The patient or provider is redirected back to Redox.
  5. Redox requests an access token and stores it securely.
  6. Redox sends an SSO message to your endpoint.
  7. Your endpoint records the SessionID and redirects to either a static page or does SSO.
  8. Redox redirects the client as appropriate.
  9. When additional FHIR® API or Data Model API requests are made, they should use the SessionID to use the access token from step #5.

App registration and redirect URIs

To use SMART applications with Redox, you must first register your application with a provider that supports SMART. Redox is compatible with any OAuth or OpenID Connect provider.

Then, check out these sandbox environments that work with Redox:

Each vendor requires different information, but one required element to include is this callback/redirect uri: https://launch.redoxengine.com/redirect. Essentially, this tells the authorization service that it's okay for Redox to handle the SMART app launch.

SSO destination

When Redox handles authorization and access tokens on your behalf, an SSO destination is required even if you don't have an app component. Redox generates and sends a unique SessionID that you can use to make FHIR® requests to Redox.

The SSO data model should contain the following fields:

Field
Description
Meta.SessionID
A unique SessionID that you must include in the _redox_session field to make additional FHIR® requests.
Meta.SessionBaseURL
A FHIR®-based URL that you can use in the _redox_session field to make additional FHIR® requests.
Example: SSO data model
json
1
{
2
"Meta": {
3
"DataModel": "SSO",
4
"EventType": "Sign-on",
5
"Source": {
6
"ID": "7ce6f387-c33c-417d-8682-81e83628cbd9",
7
"Name": "Redox Dev Tools"
8
},
9
"SessionID": "abcdefghijklmnop",
10
"SessionBaseURL": "https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development",
11
...
12
}
13
}

Here's an example of running a patient search to the Redox FHIR® sandbox URL using SSO:

Example: Patient search with SSO
bash
1
POST https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Patient/_search?_redox_session=abcdefghijklmnop

Read more about the SSO data model: