Using SMART to talk between systems  

A question I was asked was ‘Can SMART help the scenario where an EMR users wants to access data from another system for the patient they have in context’?

Take the situation where there is, say, an HIE that contains information about a patient that is useful to share in care delivery. It might have the definitive list of the patients medications, all known prescriptions, or their allergies, or encounters – information of value to the clinician and exposed by FHIR interfaces. In New Zealand, it could be the proposed national EHR.

There’s also a Primary Care (Ambulatory Care in the US) system (EMR) that wants to be able to access that information in the context of their EMR. Now, you might say that the EMR should just consume those services – and it should. But that does require development on behalf of the EMR vendor, and does mean that all of the functionality needs to be provided by the vendor – we lose the flexibility and potential innovation that SMART ‘sidecar’ applications provide.

For example some apps may be able to update the EMR data from the HIE data (if the EMR allows). There might be specialist apps – like chronic care apps – that are tailored to that condition and maybe calling on external decision support services that read data from both systems, and update the patients care plan based on that data.

Can we use SMART to bridge the gap?

Well,  you can – and here’s how.

First some assumptions and caveats.

• This is really about clinicians accessing patient data.
• The clinician user needs to have an account in both systems. We’ll assume that it’s a standard username/password, though other variants are certainly possible. Life would be simpler if both EHR and EMR shared a common user identity source – but that’s not common at the moment.
• There’s some form of common patient identifier. Or – the HIE knows the identity used by the EMR. This isn’t an absolute requirement, but does make the Use Case more user friendly.
• The EMR supports ‘EHR launch’ – ie can launch a SMART app supplying the user and patient context.
• The HIE supports ‘standalone’ launch – ie a SMART app that is not launched from the HIE User Interface.
• There is a SMART app registered in both systems

Heres a picture:

And here’s how it would work.

1. The EMR user invokes the app, which authenticates the user in the usual way for an EHR launch.
2. Because there was a patient selected, the Access Token from the EMR will have the patients id in the EMR. The app therefore calls the EMR FHIR Patient endpoint to retrieve the Patient resource. This has the patient identifier as a property.
3. The app then calls the authorize end point of the HIE (a standalone launch). The HIE responds by displaying a logon screen for the user.
4. The user logs in, and is presented with another Access Token from the HIE. (They now have 2 Access Tokens – one from each system).
5. And now the app has access to both systems. It has the patient identifier, and so can locate the patient in the HIE and the relevant clinical information.

At this point the skys the limit! – depending on the access rights that each system grants (which is one of the nice things about this approach – each system still controls the access rights of the user according to their own policies). The app can combine data from both systems, compare data from both systems, prepare summaries – whatever. It could reconcile the data between the two or perform a ‘sync’ – update the data in both systems.

And neither system had to do anything special – they just needed to implement SMART.

Of course, nothing’s perfect, and the need for the user to authenticate to the HIE each time is a bit tedious. However there is a solution to that as well.

Provided that the app is ‘private’ (i.e. can store a secret) then it could maintain a secure cache of Access Tokens – one for each EMR user. When the EMR user invokes the app, then the app could by-pass the HIE authentication step, and just present the Access Token for that user when querying the HIE. In this way, once the user has authenticated, they don’t need to re-authenticated (at least for the life of the Access Token -and there’s always the Refresh Token to make it last even longer).

Of course the solution above does require a significant amount of trust between HIE & EMR (at quite a number of levels 🙂 ). Saving and replaying the access credentials always makes security people twitch. Still, there’s no technical impediment that I can see.

In the next post, we’ll take a closer look at scopes.