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

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

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

Creating your own FHIR Server: revised

So I’ve written an earlier post describing how you can use the excellent HAPI FHIR engine to host your own FHIR server. This used the CLI (Command Line Interface) tool, and has worked well for me in the past – for example most of the clinFHIR modules have used this as the back end storage.

However, this is definitely only useful for development and testing, and recently there have been some issues running the more recent versions of the CLI so I decided to take a closer look at other options – in particular using Docker to host the server.

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

FHIR Prototyping with Node-RED – part 2

In part one of this series, we looked at using node-RED to manage notifications using the FHIR Subscription resource for a Use Case where relatives (or other care givers) could be notified when a person is admitted to hospital. We looked at the overall flow – now let’s look a bit deeper into some of the details.

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…