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:

Untitled

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.

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

10 Responses to What is SMART and why should you care.

  1. jkiddster says:

    SMART is definitely getting somewhere – but what I miss in terms of launching an app/application from the EHR system is the context state maintenance. Once you have launched the 3.party app/application it gains the context from start – but once you’ve changed the state in the 3.party app/application the context is no longer in sync across apps/applications. This is where the old CCOW tried to solve the problem. As long as the ‘working context’ is not maintained across apps/applications it is merely a standardized way of deeplinking, IHMO.

    • David Hay says:

      Apologies – I forgot to reply. I suspect that Josh would give a better answer than I, but I guess you could use some sort of eventing mechanism whereby the EHR can notify the 3rd party app that the patient has changed and it could then query the EHR for the ‘current patient’ and update itself. There’s some support for that in FHIR – see http://hl7.org/fhir/subscription.html – where the 3rd party app would subscribe to events from the EHR but it’s certainly an area that could use some attention. There’s a new standard CDS Hooks (https://github.com/cds-hooks/cds-hooks/wiki) that might also be interesting here as well…

  2. Pingback: SMART on FHIR and the Personal Health Record | The Fhirplace

  3. Graeme Hibbert says:

    Hi David, great article. This would make a good topic for a seminar FYI.

    • David Hay says:

      Thanks Graeme- yes, we have done one seminar December 2014 (Josh came across) but an in-depth (and perhaps practical) might be worth thinking about…

  4. Ravi Ada says:

    David, this is a great blog, it seems like you have been living in this world for a while. Thanks for sharing your experiences and ideas.

    Couple of questions:
    1) How to enable an EHR implementation to support FHIR? Is it through EHR vendor as an upgrade with supported FHIR server or develop mappings from CCDA or HL7 to FHIR if an organization wants to support MU3 patient engagement?

    2) I like the description of sidecar applications, I can see a whole new market of these apps springing up. It may be trivial for these vendors to consume FHIR messages and develop meaningful apps but they may be bound by the timelines of EHR vendor support for FHIR, and often it may cost for upgrades. What incentives and motivations for customer to upgrade their EHR implementations to support FHIR?

    We belong to sidecar application arena, providing patient engagement platform in the form of digital check-in exchanging aggregated clinical and patient generated data. We built the solution supporting FHIR but the challenge is the dependency of EMR support for FHIR.

    • David Hay says:

      Thanks Ravi – appreciate the comments! Yes, FHIR can become all consuming 🙂

      Let me think on your questions a bit. There are a lot of different ways that an EHR can support FHIR – indeed the Argonaut project in the US is an example of this, and there are others around the world doing the same. I’ll try to give a more complete opinion (maybe another post 🙂 ) later…

      cheers

  5. Ravi Ada says:

    Thanks David! I look forward to hear more about the question above.

    In the meanwhile, I am wondering if there is any work underway to generate FHIR resources for patient generated data. For example data from wearables and patient annotations on clinical data, I did not find any suitable resources to handle this data.

  6. Imran Hafeez says:

    One of the best articles I have found on the Internet on this subject. Excellent explanation in a very simple way. Thanks for putting this together David!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: