Skip to main content

Single-Sign-On and SMART-on-FHIR

· 5 min read
Eric Morgan
  • SSO with SMART-on-FHIR can prevent your users from logging in twice: Once for the EHR, and once for your application
  • This article discusses strategies for implementing this into your application
  • Plasma provides a mechanism to make this process quick and easy

Multiple Logins

Many people building SMART-on-FHIR applications have an existing app with an existing user management system. In these applications, users (typically clinicians) must first login in order to use the app.

When converting an app like this to SMART-on-FHIR, the user will also be required to login to the EHR in order to have access to the EHR's clinical data. Requiring users to login twice to use your app can be a source of frustration and increase the number of clicks it takes for your users to accomplish their goals.

The ideal solution is to have your users login a single time, through the EHR, in order to both use your application and interact with the EHR.

SMART-on-FHIR Standards

SMART-on-FHIR provides a way to receive an id_token which can be used to gather identity data about the currently logged in user. This data can then be incorporated into your own user management system to link existing accounts, or to initialize new user accounts.

This will work for both a Clinician-facing and a Patient-facing application. The user information will come back in the form of a FHIR resource, whichever is appropriate to the situation (a Patient resource or a Practitioner resource).

You can read more about the SMART-on-FHIR standards at the following URL: https://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context.html

Case Study 1: Brand New App

In this case study, you are still building an application and you do not have any existing users. This is the simplest case because you will not have any legacy data to contend with.

One option you have in this case is to use the existing user management system of the EHR and just copy and customize the data necessary for your application.

We recommend placing a login button for whichever EHRs your application needs to support and direct the user to the authentication page for that specific EHR. The image below shows a sample implementation for an app that can support multiple EHRs. You may choose to provide individual buttons for quick access to the relevant EHR, or provide a drop-down list for the user to choose from.

SSO Demo

Once the user has logged in to their EHR, you can retrieve the identity information and populate your user management system accordingly. The user is now authenticated and can be granted access to your application's features.

Case Study 2: Existing App

In this case study, suppose you have an existing clinician-facing application with many users who are accustomed to logging into your app using their email and password.

We want to link each user's account to their EHR account and have them login via the EHR rather than with their email and password.

We recommend having the user keep their existing login and then "linking" their account to the EHR account. You can provide a "Link Acocunt" button that will direct the user to the EHR's login page. Once the user has logged in, you can retrieve identity information and store that linked information into your user management system.

Depending on your implementation, you may want to save refresh tokens so that you can refresh the user's access periodically and avoid frequent logins.

Case Study 3: Multiple EHR Accounts

In this case study, suppose you have a patient-facing app and suppose that some of your users (patients) have accounts registered with multiple EHRs. This can be quite common if the patient receives care from two different health systems in their community. Another example may be that the patient has changed insurance providers and was required to change health providers.

In this situation, we recommend maintaining a one-to-many relationship between your users and their health system connections. You can still retrieve identity information for each health system connection and you can decide in what capacity you should use it. We recommend using the patient's current health system data when pulling any kind of demongraphic identity data.

SSO with Plasma

With Plasma, we provide a seamless integration to an EHR's SMART-on-FHIR authentication service. Our platform can get your application and users connected to an EHR with the push of a button.

We provide an endpoint for you for every EHR system that you need to support. You can direct your users to this endpoint to have them login and connect to the EHR.

Once your users have connected to the EHR, we provide a convenient endpoint that will automatically retrieve the logged-in user's information. This can be done in a single step by calling the .../plamsa/sof/whoami?readFhirUser=1 endpoint.

A sample response from this API can be seen below.

SSO Data

Demonstration

To demonstrate this functionality, we have built a very basic app using the Plasma Platform. This app connects to both the Epic and the SMART Health IT sandbox environments. Feel free to try it out here: https://sso.smart-on-fhir.com/

Get Started

Check out https://medblocks.org/plasma to get started today!