Questions and Answers > Understanding the Redox SSO Data Model
Questions and Answers

Understanding the Redox SSO Data Model

When do I use the SSO Data Model?

​​​​​​​ The SSO Data Model allows organizations to securely share the login context for a user. The most common use case is a provider in an EHR launching an integrated application, and being automatically logged in, as well as passing context such as which patient and visit are open.

Current support of this data model requires that the EHR is capable of making an outbound SAML request. As with all Redox Data Models, we provide abstraction, standardization, and normalization services to deliver a consistent experience for developers.

What is an example SSO workflow?

The goal is to launch an application from within an EHR without requiring the user to sign in repeatedly.

  • User (physician, nurse, scheduler, etc) is logged into an EHR
  • User clicks a button to launch a Redox network app in their EHR
    • SAML (or another base message) is sent to Redox and transformed into the Redox SSO Data Model
  • Application receives message, processes contents, and returns a URL to the EHR to show the user inside of the EHR window.

What contextual information is included in the SSO request?

Basic information about the user who launches the application as well as the particular patient is included in the SSO Data Model. In the event that this basic information does not meet your needs, some EHRs may have support for extending this information to include additional data.

Does our SSO model work for patient context, such as launching apps from an EHR’s patient portal?

The SSO support we’ve currently implemented has only been via SAML, which is launched from an EHR context for providers or other organizational users. However, patient SSO could be set up with a URL based launch or SMART on FHIR. If you are interested in pursuing such functionality, please reach out to us.

How does the SSO Data Model differ from the ClinicalDecisions Data Model?

Both the ClinicalDecisions and SSO Data Models involved workflow embedded bi-directional exchange. However, they differ in several capacities:

  1. Trigger Point
    1. ClinicalDecisions is typically triggered from the EHR via a normal workflow step such as ordering or adding of a problem.
    2. SSO is typically triggered from the EHR via a specially configured button made available within the right EHR module.
  2. Returned Content
    1. ClinicalDecisions returns discrete data that the EHR can utilize as part of an alert to advise on the user’s behavior.
    2. SSO returns a URL that the EHR can launch for the user.