Implementing SMART on FHIR in an EHR

We’ve talked about SMART and OAuth2 before, but it was a little while ago and it was in the context of what SMART is about and how it worked (with the odd bit of sample code thrown in). This post takes a slightly different perspective by looking at SMART from the perspective of an EHR (Electronic Health Record) developer tasked with implementing a SMART interface to an EHR– what are they things that they need to consider adding SMART Interfaces ?

We’ll take a slightly roundabout way of doing that by starting with a brief overview and some key points about SMART, then diving into the details of the steps involved in a sample implementation. That’ll be enough for this post, then in a follow up we’ll take a closer look at the issues that our EHR developer will need to resolve. And later on, we’ll switch to the clients perspective.

So what is SMART?

Basically, SMART fulfills the use cases around supporting small, independent applications that want to provide specialized functionality in the context of an EHR (Electronic Health Record). The example often given is that of an application that displays pediatric growth charts. Launched from within the context of an EHR, it can pull data from the EHR to display charts of a childs development progress and potentially interact with other services to provide customized services such as decision support to the end user. In effect, it adds this functionality to that of the EHR to give a richer experience to the clinician – something that Wes Richell has called ‘sidecar’ applications.

To do so, it takes a number of well accepted existing standards – both within healthcare and more generally in the Internet community, and creates a profile of those standards – a pattern of use – to meet that need.

These standards are:

• FHIR. Describes the content of data being exchanged, and the query API to be used. FHIR is Health specific.
• OAuth2. An Authorization framework widely used outside of health – particularly allowing users to permit client applications (like mobile and web) to access their data. It permits the authentication (are you who say you are) and the authorization (what are you allowed to to) processes to be delegated to separate  ‘Authorization Servers’ so that the application supplying the data (the ‘Resource Server’) doesn’t have to do this – it can delegate that to the Authorization server.
• OpenID Built on top of OAuth2, this supports user identity – personal information about the user to be given to the client application.

The huge value of this  standards based approach is that the specialized application can then work against any EHR that supports the SMART interface, in effect helping to establish the ecosystem of health care applications that will support innovation across the healthcare sector by creating a market place for application developers to exploit specific niches.

To understand how SMART works, we need to describe the main components – the building blocks – that we will use.

The Client application is the SMART enabled application that wishes to access data from the EHR – or to update it – in order to perform its specialized function (displaying growth charts in this example). While it uses (and potentially updates) EHR based data – there is nothing that prohibits it getting data from other sources, or calling on other sources (like immunization protocols) as it performs its functions.

The EHR, or Electronic Health Record is the system which holds the information that the client application wishes to access, and Is responsible for managing access to it as well as it’s overall integrity. It can be considered as the Custodian of the data. In many (but not all) of the Use Cases, the client application will be invoked from within the EHR. Part of the work in developing a SMART EHR interface is creating a way to actually invoke the client application – a process that we’ll talk about a bit later on

In SMART speak, the EHR has a number of sub-components that are separately defined in the underlying OAuth2 spec, but are managed by (and are really a part of) the EHR application. These are:

• The Resource Server. This is the component that holds the desired data and is responsible for delivering / updating it. In SMART, this is an implementation of a FHIR server. The more fine-grained privacy will likely be implemented by this component (Again, we’ll talk about this a bit later on).
• The Authorization Server is the component responsible for confirming that the user of the client application is who they say they are (a process called Authentication for the geeks out there), and for determining the precise access that a given user can have to a given patients records (Authorization).
• The Conformance Endpoint is part of FHIR, and allows a client to discover the capabilities of the FHIR Server.

Here’s a picture of how these components interact.

Note that making these components part of the EHR simplifies the security model in this version of SMART. Note that the terms ‘Authorization Server’ and ‘Resource Server’ are logical terms – physically they may be the same application.

It is also entirely possible that future versions will support a more distributed model, where – for example – the Authorization Server sits outside of the EHR, and manages the access rights to multiple EHRs. This is something that the base OAuth2 specification supports, but it is complex (and therefore expensive) to implement.

Small steps!

So, as promised, let’s jump right into the detail of how all this works in a specific Use Case. The example that we’ll use is where there is a vendor who has created the worlds best paediatric growth chart application. Their application is web based, and so can be started simply by calling a specific Url from within our EHR.

Our user (a clinician) is using the EHR. They will select a patient, and then click a button labeled ‘Growth Chart’. After a short (hopefully) delay, a window will open with the Growth Chart application User Interface populated with data from the EHR system. (Of course, the application could also open inside of the EHR so the user has no idea that the functionality is being provided by an external application, which would be even cooler…)

They interact with the application – viewing data, entering new information, making orders – and when finished close the window. All of the changes they have made are reflected in their EHR.

So what happened under to hood to make this happen? Well…

Detailed steps

We’ll now look at the sequence of events that made this happen. If you’re come here to find out what SMART can do, then you probably want to stop reading now. If you like the details, them read on…

There are a few prerequisites for all this to work properly. Essentially the client app needs to be initially registered with the EHR, providing:

• A client_id that uniquely identifies the client application to the EHR.
• The launch_url for the client application has been supplied- so the EHR knows where to call the app.
• The redirect_url for the application has been registered – so that the EHR can redirect after authentication has successfully completed.

(We’ll think about how all this might happen in a later post).

Also – for those looking at this who are already aware of some of the SMART concepts, the app is assumed to be a ‘public’ application – ie it is not capable of keeping a ‘secret’ token. This has implications on the workflow, which is why we need to be aware of this. We’ll talk about this a bit more in the next post, so you can safely ignore that for now.

Architecturally, this will be a Single Page Application – running in the browser, perhaps using a framework like Angular.

Now for the details. First a sequence diagram:

And the description of the steps – with the numbers corresponding to those in the diagram.

s

So that’s the detailed flow for a single Use Case – an EHR user invoking a SMART application which can securely access data from the underlying EHR (the Resource Server). Note that this is just one implementation – there are many others that could be used. SMART really focuses on the interface between EHR and Client – not the internals of how the EHR (or client) do their work.

Which brings us nicely to the question of libraries. As we’ve seen, Outh2 is a complicated specification – and it’s very easy to have bugs when writing code to support it, which is not a good thing – especially in the security implementation! There are many libraries available that will perform these steps that have been thoroughly tested, and you are strongly advised to use one of them rather than trying to do it yourself.

And for clients, there’s also a javascript library provided by the SMART project team – plus others for python and iOS.

In the next post, we’ll take a step upward and consider some of the higher-level aspects of SMART – different Launch schemes, more about Scopes, Confidential vs Public applications and so forth. We’ll also think about the FHIR profiles that are used, and touch on User Details – the openID part of the specification.

And lastly, here are the official SMART specifications. The page on Authorization is well worth a read (most of the contents of this post came from reading that page – plagiarism at its best! – or the most sincere form of flattery…).