Best Practices Guide for SMART on FHIR

Introduction

The SMART on FHIR Framework unites healthcare workers and their patients by harnessing the latest technology standards in order to connect clinical documentation, patient-clinician communication, billing, and the Electronic Health Record (EHR).

The Fast Healthcare Interoperability Resources (FHIR) Standards Framework expands the interoperability of healthcare technology. Information sharing between third-party applications and the EHR is now possible even between different platforms through RESTful practices.

The SMART Application Launch Framework is a reliable authorization protocol that supports any FHIR system. The FHIR scope covers many architectural scenarios to support integrated healthcare, from clinical trials to patient billing. It is easy to implement, built on the latest standards, and leverages Clinical Documentation Architecture (CDA).

FHIR is a collection of healthcare instances called "resources" that can be accessed based on an institution's policies. FHIR is a comprehensive foundation for different healthcare contexts, from clinical decision making to financial reimbursement for services. The FHIR API is the definitive patient access API and provides developers readability from data to endpoints. Particularly, the Da Vinci Payer Data Exchange (PDex) showcases powerful interoperability of FHIR resources and payer data alongside financial and clinical requirements.

However, complex use case implementation can quickly become an infrastructural nightmare, and security protocols are left to the developer to manage.

Auth0 provides a secure authorization and authentication platform compatible with SMART applications, enabling customers to make access requests to FHIR resources via OAuth 2.0-compliant authorization through Auth0 Tenant Servers and authentication through the OpenID Connect standard. Auth0 offers HIPAA Business Associate Agreements to customers handling PHI data. Using Auth0 as an identity and authentication service helps companies be HIPAA-compliant.

SMART vs OAuth2

FHIR is a standards framework for exchanging healthcare data, and the SMART Launch Framework secures the FHIR API so that only authorized users/services can access that data. SMART may share similarities with OAuth2, but there are key differences:

1. The SMART authorization service is more flexible when determining an active patient record or providing user consent for viewing multiple patients.
2. SMART provides session context next to an Access Token response. OAuth2 relies on the OIDC protocol to communicate application session-level information.
3. SMART has additional authorization server metadata endpoints not part of OAuth2.
4. SMART supports public application authentication via a single shared key for all public SMART clients.

This guide covers addressing these differences with a PDex scenario involving a clinical portal (Clinico), a patient (Joe Smith), and a third-party insurance website (Med0), to share visit history and carrier coverage options.

Stateless

SMART apps should be stateless, meaning request transactions are independent of session context. Session-based and browser-based data should be stored in separate cookies to reduce memory usage and eliminate sticky server-side sessions, supporting scalability.

In stateless applications, never include bearer tokens in cookies.

Clinico is working on incorporating DynamoDB and TTL to maintain previously selected data, with one Access Token associated per patient.

Authorization & Authentication Parameters

While not required in V1 of SMART on FHIR standards, PKCE authorization with Auth0 supports secure interaction with the FHIR API. Otherwise, the application will need an additional endpoint to authorize with Auth0.

For SMART apps, state and aud (audience) parameters must be included with the authorization request. state is a unique and opaque parameter to prevent phishing and CSRF attacks. The audience parameter should be the URL of the FHIR resource server from which the app wishes to retrieve FHIR data to prevent leaking a bearer token to a counterfeit resource server.

OIDC specifications suggest treating the user claim/representing the user as the URL of an FHIR resource, in addition to a pair of OIDC scopes, as a more-secure authentication method.

SMART apps should always use a restrictive scope when requesting access to a given FHIR resource.

{
  "access_token": "XXXX.",
  "aud": "https://yourfhirresource.io/r/12345",
  "scope": "openid fhirUser launch patient:read",
  "state": "xyzABC123",
  "fhirUser": "https://yourfhirresource.io/r/12345"
}
  

In the B2C use case, Clinico, built on the SMART Patient Standalone Launch SDK, allows Joe to link Med0 as his insurance carrier.

Consent

Consent is integral to SMART applications. Different types of consent authorizations vary based on context, from sharing personal information to permitting authorized representatives to access patient records. After a user is navigated to the login page by the Auth0 Authorization Server, SMART applications must request consent to access FHIR resources on the user's behalf.

Clients created in the Auth0 dashboard are assumed to be first-party applications. Since consent legislation varies per region, first-party application consent is optional. However, it is recommended to set Allow Skipping User Consent to disabled. For third-party applications, set is_first_party: false in the management API. It is imperative that SMART apps include a consent flow to accommodate IIHI scenarios according to HIPAA regulations.

Clinico, the FHIR resource owner, uses an Auth0 Redirect Rule to connect Joe to Med0, a third-party application. The Rule redirects Joe to a custom consent screen that prepends Joe's patient identifier and the appropriate scopes. If Joe does not accept the consent screen, Clinico does not connect Joe's insurance payer (Med0) information.

Claims

SMART launch specs require session information or launch context parameters such as patient ID (patient_id) to be returned with the Access Token. Auth0 offers the option to create a Rule to modify the Access Token and add custom claims like patient_id so these claims are included alongside the Access Token in the response.

Your SMART app can use this Access Token to interact with the FHIR API. Rules run during every authentication, meaning the Access Token can include any type of claim, not just a patient parameter but also encounters or observations. Use a unique name and take advantage of URL namespacing.

SMART apps should use a minimal number of claims for authorized users. Do not include sensitive patient information in the payload, and stick to SMART requirements, minimizing Access Token scope manipulation.

Clinico sends custom claims limited to Joe's patient ID, his permissions via scope, and Med0 as the audience.

Proxies

Use case requirements sometimes go beyond custom claims in the Access Token. Since Auth0 doesn't support custom claims in an HTTP response out of the box, Auth0 customers with complex application requirements can leverage services like AWS CloudFront and Auth0 Private Cloud on AWS. Lambda functions can act as proxies and send requests to Auth0's /authorize and oauth/token endpoints so that custom namespaced claims are in the issued response.

Clinico uses a proxy to connect Joe's Clinico visit history with his Med0 payer information. Clinico's developers followed a security-forward design pattern to avoid a single point of failure.

Authorization Policies

Access for a given patient, study, or clinical instance has many granular security implications. Role-based authorization of SMART clients can be achieved through Auth0's Core Authorization, which includes policy evaluation based on roles and permissions assigned to users.

Clinico uses role-based access control (RBAC) for basic application navigation and access control lists for more fine-grained authorization administration and management. Once RBAC is enabled, authorization policy can be further customized using Rules.

Clinico's patient portal connects patients' third-party insurer information and grants access to pharmacy prescriptions, upcoming appointments, and lab results. Clinico also has clinician-dedicated SMART applications for risk assessment tracking, such as blood pressure and cardiac health. These apps leverage data from one another, from demographics to lab results, illustrating the potential of interoperability with SMART on FHIR. With great interoperability comes great responsibility. Because the FHIR API handles population health, individual SMART apps must have their own authorization policy, as well as an authorization policy for the organization.

Public Registration

PKCE authorization with Auth0 offers the security benefit of automatically exposing a JSON Web Key (JWK) endpoint for each Tenant, making possible a single shared key for all public SMART clients, as per the SMART backend service registration specification.

Clinico's JWK is used to sign all incoming JWTs.

Confidential Registration

Auth0 supports confidential client registration using client secrets, securing both web and mobile applications.

Refresh Tokens

Refresh token rotation for Single Page Applications (SPAs) is a powerful Auth0 differentiator.

Developers at Clinico are working on leveraging refresh tokens for their SMART Application, testing their new feature set with FHIR Public Test Servers.

Unsupported Use Cases

While the future looks bright, session timeouts, updates, and SPA refresh are not currently covered in the SMART application profile context.

Conclusion

Despite Clinico being a fictional developer scenario, BioReference Laboratories handled a 25x volume spike during the onset of the COVID-19 pandemic with Auth0, supporting their patient portal experience which integrates FHIR, enabling patients to link their data between platforms.

"I don't ever have to worry about security or user access. I have Auth0," said Vinny Pacione, Vice President of Consumer Technology and Digital Solutions.

For those working on bridging their application to other SMART on FHIR applications and seeking the best in authorization and authentication, reach out to Auth0 experts to get started.

Auth0's modern approach to identity enables organizations to provide secure access to any application, for any user. The Auth0 Identity Platform is a highly customizable identity operating system that is as simple as development teams want, and as flexible as they need. Safeguarding billions of login transactions each month, Auth0 delivers convenience, privacy, and security so customers can focus on innovation.

For more information, visit https://auth0.com.