What is SMART and why should you care.

This was actually a summary of SMART that was intended to wrap up a series I wrote a few months back, but I forgot to post it! So, better late than never…

Introduction

Most people who are active in the healthcare interoperability space will have heard of FHIR – the ‘next generation’ interoperability standard from HL7 that is implementer focused – reusing many of the concepts already familiar to developers from other domains such as Resources to represent common healthcare concepts such as Allergies, Medications and Problems and a simple REST based API made popular by some of the major internet players such as Google, Twitter and Facebook.

FHIR has the support of many of the larger vendors – Epic, Cerner, Allscripts and Orion Health as well as national bodies such as ONC in the US, the NHI in the UK, HINZin New Zealand and NEHTA in Australia.

But there’s a new acronym making the rounds at the moment – SMART (standing for Substitutable Medical Applications and Reusable Technologies) that is also generating a lot of interest. It isn’t yet as wide spread as FHIR, but the same organizations are taking a close look at it.

Put simply, SMART adds a layer of security in front of FHIR interfaces by leveraging OAuth2 for Authentication and Authorization, OpenID Connect for user Identity and standardizing the process of negotiating access to information and operations between client and server. It also describes a process by which an EHR application can launch an external application preserving context, and providing safe access to the data within the EHR.

Details

SMART was originally proposed as a standard to enable specialist external applications (applets) to interact securely with the data in an EMR system. The vision was that by standardizing the communication between the two it would be possible to create an ‘ecosystem’ of apps and data sources in much the same way as mobile applications can interact with on-device resources such as contacts lists and camera.

When first developed it used its own definitions for content and API, but once FHIR gained traction in the market place it switched to use FHIR for both of those.

The problem that it was trying to solve is that there is a great deal of clinical information that is collected within EMR systems that is only available to the EMR vendor. Any application development that used that data could only be done by the application vendor, reducing the possibility of developing specialized and innovative applications. By splitting the roles of data consumer and data supplier, it becomes possible for vendors to develop specialist applications that can be run against different data sources – something called ‘sidecar’ applications by Gartner analyst Wes Richell.

However, since originally described, it has become a more general standard for securing access to FHIR resources.

SMART focuses on 3 key areas – leveraging other standards to do so.

• Providing a way for a client to identify themselves and to negotiate access to the data in the EHR. This leverages the OAuth2 standard.
• Representing the information that is being exchanged, and the manner in which it can be accessed. This uses FHIR Resources (specifically utilizing FHIR profiles for the details) for the content, and the FHIR REST API as the query mechanism.
• Providing a mechanism by which an external app can be ‘launched’ from an EHR – preserving the context (current patient and user).

Identifying the client & negotiating access

There are a number of ‘roles’ that are important in understanding SMART (these come from the underlying OAuth2).

• The Resource provider is the supplier of the data – the system that wishes to make the data available via FHIR interfaces to a client
• The Authorization Server is the component that identifies and authorizes both the client and the user wishing to access the data. It can be part of the same application as the Resource Provider – but it doesn’t have to be.
• The App is the actual application that is requesting the information (eg a smartphone app)
• The User is the person who is using the app

While the implementation details are complex (and can vary from site to site even within the SMART standard) from a high level it’s quite straightforward.

A pre-requisite is that the app must be registered with the Authorization Server, which supplies it with an identification key.

When the user uses the app to request some data:

1. The Authorization Server checks that it knows the app (the app has to supply the key that identifies it). This allows the Authorization Server to customize its behavior based on the capabilities of the app.
2. The Authorization Server then identifies the user of the app. This can be by requesting a Username/Password, or some other mechanism that the Authorization Server trusts.
3. Next the Authorization Server determines what data, and what functions on that data (read, insert, update, delete) the user is allowed. Again, the actual details of how that is done varies according to the implementation. This is expressed as the ‘scope’ of the access, and SMART describes how the content of the scope is expressed. One of the possible scopes is for the app to read the user details (name, date of birth, address etc.). Somewhat confusingly, this is also referred to as the user ‘Identity’
4. Having identified the user (but only that they are a valid user – not the ‘Identity’ details) and determined what data they can access, the Authorization Server then issues the app with a token (called the Access Token) that the app can then use when requesting the data.
5. Finally the app makes a FHIR request against the Resource Server, including the Access Token in the request. The Resource Server checks that the token is valid and that the user is allowed to make the request (implementation dependent) and if so, returns the requested data (or processes any updates).

Here’s a diagram of this process:

You’ll note that a lot of the details of the process can vary according to the implementation. For example, the Authorization Server could place the agreed scope in the Access Token and encrypt and sign it, or Access Token could simply be some random key, and the Resource Server uses it to check each request with the Authorization Server.

The client doesn’t care – SMART will work regardless of the servers implementation details, which is the whole purpose of the standard.

The API and the Data content

The other big thing that SMART provides is related to the data content – the FHIR resources. While FHIR provides descriptions of each resource (for example what information is inside an Allergy), it does so in a very general way. Specific implementations then ‘adapt’ that resource to meet their specific requirements – a process called ‘profiling’ FHIR. Although not necessary for interoperability, it is helpful that both client and server recognize the same profile and so SMART defines a standard profile.

In fact, this aspect of SMART is undergoing development at the moment – currently there is a ‘SMART profile’, but in the US this is moving towards being Data Access Framework (DAF). There is also work on adapting DAF for other countries – specifically Canada at the moment – so it is likely that SMART will allow a client to specify the profiles it supports as part of the negotiation process.

Launching an app

SMART describes a couple of ways of launching an app – from within an app (the EHR launch) and an externally launched app (Standalone launch). The standalone launch is really just an external app requesting access via the external API as described above.

The ‘EHR launch’ describes how the EHR can start a SMART aware app, preserving the current EHR context – the current user and patient (if selected). In brief:

1. The user invokes a function to launch a previously registered app (eg clicks on a link in the User Interface).
2. The EHR stores the context information somewhere, creating a token (the launch token) that refers to it. Alternatively the EHR could include the context within the token encrypting and signing it.
3. The app then authenticates in the same way as described above.
4. After authentication, the app includes the launch token with each call to the Resource Server. The Resource Server uses the token to retrieve the context of the call – either by using the token as a key to some internal store or by decrypting it – depending on how it was initially created.

Note that like the other aspects of SMART, most of the server side implementation details can vary between implementations. As long as the interface between client and server is preserved it doesn’t matter to the client.

Future growth of SMART

SMART (like FHIR) is an evolving standard, and so is likely to change and extend as it is implemented internationally. The areas where we are likely to see evolution are:

• Becoming the ‘de facto’ security standard for FHIR interfaces. FHIR itself doesn’t prescribe a security mechanism, leaving that to the implementer. Given SMARTs use of widely accepted standards, it is likely that it will become the ‘normal’ security mechanism
• Supporting different profiles. As described in this paper, SMART is already moving in the direction of allowing the client to describe the profiles it supports.
• CDS Hooks – an exciting new development that seeks to standardize how an EHR can invoke Decision Support capability in the course of its usual operation. This standard – if it becomes widely adopted – could make it easier for a provider of Decision Support services to be utilized by different EMR/EHR systems – another important aspect of exposing advice generated as part of the Precision Medicine initiative.