Understanding SMART on FHIR

You can use the Smart App Launch Framework with Redox to facilitate both single sign-on (SSO), making requests via the Redox FHIR® API, or making requests via the 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 patient or provider is prompted 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 subsequent 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 subsequent FHIR® requests to Redox.

The SSO data model should contain the following fields:

Field
Description
Meta.SessionID
Redox provides a unique SessionID that you must include in the _redox_session field to make subsequent FHIR® requests.
Meta.SessionBaseURL
This is a FHIR®-base URL that can be used in the _redox_session field to make subsequent FHIR® requests.
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:

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

Read more about the SSO data model: