FHIR at the New Zealand HINZ conference.

As part of the HINZ conference, we (HL7 New Zealand) held a 1 day seminar on FHIR with a focus on clinicians rather than our more usual technical audience. We decided to do this because FHIR is now at a stage where wider clinical input is feasible – it’s at DSTU-2 and there is visualization tooling (clinFHIR) available. Technical folk are already on board with FHIR – it  just makes sense to them – so time to pull in our clinical colleagues that have not yet been involved.

There were 2 parts to the day.

The morning was an overview of FHIR – we talked about the ‘value proposition’ of FHIR to a number of user types (clinicians, patients, administrators), before describing some of the fundamental aspects of FHIR that a clinician should be familiar with – resources, exchange patterns, terminology binding and profiling. As part of this we used a real clinical Use Case showing how you could represent the components of a consultation with FHIR resources – how they refer to each other, and how you could package the resources up as either a message or a document. If you’re interested, the presentation is here.

In the afternoon we split into 2 streams.

The clinical stream (which I facilitated) looked at a specific resource – the AllergyIntolerance resource and how we would profile it for representing Adverse Drug Reactions in New Zealand.

The second stream (facilitated by Peter Jordan) was a (very) mini technical hackathon, with developers accessing data in various FHIR servers (including one developed by my colleague David Fallas).

At the end of the day we got back together – shared notes and thought about what next steps in New Zealand might be.

From my perspective, this was a very successful event. For a start we had around 55 people there – about a half being clinicians or people with a clinical (rather than technical) interest in FHIR. This is good for New Zealand! We had good engagement from the group during the design exercise, and I have a new appreciation of how hard it is to facilitate these events – by the end of the day I was exhausted!

We also had a number of people thanking us for the event – and a couple of them even mentioned FHIR in their presentations at the conference the next day! In fact, one of them – Dr Bev Nichols – drew the following picture depicting FHIR as a ‘bus’ with the contents of data and extensions – quite a neat analogy I thought.

(some of my colleagues thought that a fire engine might have been more appropriate – but I think the bus represents more of a ‘business as usual’ approach than a fire engine would!)

The technical stream was also well received – the time allowed didn’t really support any real application development, but the feedback is that further events will be welcomed.

So from a learning’s perspective, there were a number of takeaways for me.

I didn’t use clinFHIR during the design session in the afternoon (I did use it a lot in the morning as it’s great for showing the internals of a resource, and then creating a simple profile and building a conformant resource). Instead we went directly from the spec. With a few alterations, I think clinFHIR will be the better approach as we’ll be able to generate the profile – and a sample resource – in real-time as we discuss the profile.

Choosing the AllergyIntolerance as the resource to profile was a 2 edged sword. On the one hand it’s very topical, and we had some experts in the room which was excellent. On the other hand allergies are one of the more complex clinical domains, so the job was harder than it might otherwise have been and we did come across a few areas that we weren’t sure about. The fact that there a number of properties where the ValueSet binding strength is required (ie we can’t change the contents of the ValueSet) also made it rather harder than it might otherwise have been (we understood why, but the contents of the ValueSet seemed a bit arbitrary in places). On balance though, it was a good choice.

Wrapping up, we agreed that it was necessary for clinicians to be involved in this design work and some enthusiasm (or perhaps resignation?) from the group that time needed to be found to do this – and possibly at the level of the professional organization rather than the individual. We also thought that doing this ‘virtually’ rather than requiring face to face meetings might make the process faster.

There are some tasks for me to do:

• I need to create a profile that represents the outcome of our initial discussions (that should be reasonably straightforward)
• We had some feedback to the HL7 Patient Care workgroup – especially around the contents of the required ValueSets (criticality, type, code)
• There are some changes I’d like to make to clinFHIR to make it easier to capture clinician comments, and to support a more ‘distributed’ or ‘virtual’ design process. You could imagine a situation where the discussion takes place over a period of weeks, with people (anyone) commenting on-line as the profile is developed – almost a ‘social’ or consensus process. This is something the openEHR folk do quite well.

So, a good result.