Delving into SMART

While FHIR is not a security standard ‘per se’, there are numerous references in the spec to security related matters – including a specific module in the specification. One of the recommendations made is about SMART – a defined way to use the OAuth2 Authorization framework in FHIR. I recently gave a webinar on SMART, and part of the feedback was that it wasn’t enough detail for a developer to implement a solution – while this wasn’t really the focus of the presentation, it did make me realize that there will be a lot of interest in this from developers, so thought it might be useful to develop a SMART application – and call out the significant parts as we go.

Read more of this post

An update to the SMART client

Just a quick note the say that I’ve made a couple of changes to the SMART client we discussed in a previous post.

There’s now an option to start the login process in a separate tab. This is needed because a number of sites I’ve been testing won’t let the login page open in an iFrame (it’s a security thing). When you configure the server, select the ‘separate tab’ option under ‘Where to open Browser’ at the bottom of the first page. Read more of this post

Provider Directories – part 2

In the previous post, we set up the environment for our provider registry and imported some test data (Practitioner only at this stage) from an existing reference server. Now let’s think about how we can go about exposing that information through an API. We’ll work with 2 use cases – which can then act as a pattern for future APIs.

Read more of this post

Securing a FHIR endpoint in Node-RED

So in a comment to the previous post on using Node-RED to create Tasks from Assessments, Michael suggested that I talk about some of the  security considerations that you might have. There are a few ways you could make this more secure that I can think of.

  • The simplest way would be to put the whole thing behind as API manager (such as APIgee or WSO2) and delegate security to that application. In effect you are trusting the API manager.
  • Another way is to follow the SMART / OAuth process – check that a valid access token issued by an Authorization Server (Authz) has been provided in the call, rejecting the call if not.
  • And yet another option is to perform the whole OAuth2 dance – look for a valid access token, taking on the role of the Authorization server if not – validating the user and issuing tokens.

(And there will be plenty of others I’m sure). Naturally all calls will use SSL.

Let’s look a bit further into the second option – checking for a valid access token, and simply rejecting the call if there is not one present.

Read more of this post

Trans Tasman Connectathon

So the first trans-tasman connectathon (at least in a little while) is going to be held in a few weeks. There are 3 main streams – 2 of them associated with SMART – that Grahame has written about  and the third one is the IPS – International Patient Summary Implementation Guide, which I’m going to attend.

For those unfamiliar with IPS, it defines a base summary (as a FHIR document) of key clinical data about a patient that was originally intended for patients travelling in different countries to be able to provide medical information to healthcare providers data if needed – but has grown a bit larger than that, and is being widely adopted globally.

Read more of this post

FHIR enabling an Immunization registry – part 3

So we’ve made a few proposals in the last couple of posts:

The next thing to think about is how to generate the ImmunizationRecommendation (IR) from the PlanDefinition.

This could be really complicated, depending on the circumstances around the generation. For example, if we just wanted the recommendation for a new born then it’s quite easy. If we wanted more ‘smarts’ – e.g. the recommendation for someone of a given age considering their immunization and clinical history, then it becomes rather more complicated. In this post we’ll keep it simple and not look at the patient’s history, focusing on the ‘mechanics’ of the generation.

As a background to the discussion, let’s think about how a client might use the registry API.

Read more of this post

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…

Read more of this post

SMART Webinar

And quite by coincidence, this webinar from HL7 that Josh is presenting…

SMART – Security

So in the last post we went into some details concerning a specific SMART scenario – where a web based application is launched from the EHR (technically an EHR launch as described below). Let’s take a step back and take an overview of SMART as a whole, including some the other ways it can be used.

Read more of this post

SMART – Scopes and Profiles

In a previous post we looked at some of the ‘security related’ aspects of SMART. In this one we’re going to take a closer look at what the ‘scope’ is, and make a couple of comments on the use of Profiles.

Scope is an AOuth2 term that represents the range of functionality requested by (and potentially granted to) a client application by the Authorization Server. For example an app that displays a person’s vitals might want to be able to read and create Observations.

Read more of this post