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

Bundle Visualizer for Trans-Tasman Connectathon

So in the previous post about the upcoming Trans-Tasman connectathon I mentioned that I was going to work on a couple of applications in the IPS track – a way of visualizing IPS documents (actually any kind of FHIR document), and a ‘façade’ application that could produce an IPS document on demand from a back-end data source.

This post is an update of where I’ve got to.

Read more of this post

FHIR Documents (and other stuff)

I had an email from a company which had a number of really good questions about exposing data through FHIR, so I thought I’d write a post about it rather than just replying directly as it may be of interest to others (and also gives others the opportunity to disagree with me 🙂 )

Read more of this post

GraphBuilder and R5

Just a short post to follow up on using GraphBuilder for building examples.

To help support people building R5 examples for connectathon, I’ve added the ability to select the version of FHIR to use for the graph. Currently the R4 and R5 draft release are supported (as these are the versions that sushi supports).

Read more of this post

Accessing Lab data via FHIR – part 3a

So there have been a few comments on the series thus far (a good thing!) through a number of channels, so I thought I’d quickly address them before moving on to the implementation discussion.

Read more of this post

FHIR enabling an immunization registry

In New Zealand (and other places as well I expect) we’ve had a national registry for immunizations for a number of years – the National Immunization Register or NIR

It’s currently fed by HL7 version 2 messages and there’s a User Interface for authorized users, but there was always a plan to introduce a FHIR interface to some point – something that has been accelerated by the current COVID pandemic of course.

Read more of this post

clinFHIR stock take

I’ve been asked to give a short talk about clinFHIR to a course at Johns Hopkins this month – what it is and what you’d use it for, so to organize my thoughts I decided to write a ‘stock take’ of clinFHIR modules. This is actually part of a project I’ve been working on for a little while – learning FHIR with clinFHIR – so it’s a perfect time to be doing it.

The idea for clinFHIR started shortly after FHIR started to gain prominence within HL7 – coming up to 10 years ago now. The technical folk understood what the developers were trying to do – utilize internet standards to share healthcare data – but it was harder for the clinical folk to gain that understanding and appreciate the significance.

clinFHIR (Clinical FHIR) was envisaged as a way to visualize FHIR – particularly resources and the references between them – so that the committees within HL7 responsible for authoring resources could advance their development. We worked closely with the members of the ‘Patient Care’ committee in particular – they had sessions at most Working Group Meetings called ‘Clinicians on FHIR’, and we developed clinFHIR as one of the main tools for them.

(And I’d like to recognize all the work they put into this – it was an on-going balance between evolving the application to meet identified needs, and dealing with the bugs that a rapid development cycle brings!)

Read more of this post

FHIR Forms: Theory and background

In this set of posts we’re going to dig into how FHIR supports the use of forms in collecting information. 

We’ll start with the theory – how the Questionnaire and QuestionnaireResponse resources work together to define a form and record the information entered into the form (whether directly by the user or pre populated from existing data)  and then describe an example implementation that we’ve built in clinFHIR. 

Read more of this post

Updating a resource using patch

We’ve received a bit of pushback from the community regarding our proposal to use custom operations for updating the Patient in NHI upgrade project. But the development team really isn’t keen on using PUT updates of the complete resource – the main reason being that of ‘accidental’ data changes when the updater doesn’t return the parts of the resource that should remain unaltered. (Apparently, this is not uncommon with messaging based updates that are kind of similar).

I mentioned in that post that we didn’t really take a close look at PATCH updates – but a couple of days ago I saw this trail in the FHIR chat which is about a similar project (slightly different requirements) and thought I really should take a closer look at PATCH.

Read more of this post

Accessing lab data via FHIR – part 1

This will be the first post in a short series that considers a very useful interaction – accessing Laboratory data such as blood tests from a repository of data via (of course) a FHIR API. The actual repository we use doesn’t really matter – it could be a part of an EHR, or an interface that the lab exposes or it could be a standalone data repository such as a regional or National store – it’s the API that counts.

There are a number of different perspectives that we can take, of which two are:

  • Accessing data about a particular person – whether by the person themselves or an authorized clinician.
  • Accessing data from the perspective of the ordering clinician – e.g. all the tests they have ordered, but not yet reviewed. This would return the results belonging to multiple people.

In this post we’ll take a look at the first perspective – accessing a single person’s data. We’ll consider the clinicians perspective in a subsequent post.

Read more of this post