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

Slicing with Forge

This is a ‘so I can remember how I did it later’ post.

Slicing in FHIR is where you take an element that can repeat and create ‘sub-lists’ which have specific values. The example in the spec involves slicing the Observation.component element to represent a Blood Pressure measurement where you want to record the systolic and diastolic values in a single observation.

In my example I wanted to create a slice on Patient.identifier as part of the work we’re doing for the NHI (National Health Identifier) interface. Because patients are frequently duplicated in the NHI registry, it’s common for a single person to have a number of different identifiers – the current ‘active’ one, and any number of ‘old’ ones – numbers that were assigned to duplicate entries than have been merged or linked (we call them dormant ones).

Read more of this post

Thoughts about updating Registries

In New Zealand we are lucky enough to have had a national patient registry for some years which serves as a unique identifier of patients in New Zealand – the National Health Index or NHI. The Registry is an instance of an EMPI (Enterprise Master Patient Index) and currently  exposes a SOAP interface that can be accessed by clients across a protected network.

In order to make it available for more users we are working in a project to expose a FHIR API that will offer similar functionality to the existing SOAP one, be simpler to use, available across the public Internet and so accessible to a wider range of clients in support of the healthcare ecosystem. We’re also looking at similar work for Provider registries.

Read more of this post

FHIR Bundle Visualizer

So a little while back I wrote about an app I developed during the WGM Connectathon to send an HL7 v2 message to a converter app, and display the response (a FHIR Bundle) in a number of visualizations after validating it using the community supplied validation tool (actually, exposed by the reference servers via the $validate operation). It occurred to me that this visualization might be of use to implementers who are developing query applications – such as the CSIRO Primary Care project for example, so I pulled it out into a separate application.

Read more of this post

Is it a bird? Is it a plane? No, it’s a beer box!

At the last HL7 Working Group Meeting my good friend Brian Postlethwaite shared with us a video on how he made a plane out of a beer carton! This is so quintessentially Australian (and New Zealand), that I just had to share…

(Can’t wait to see what he does for an encore!)

Updated: here is the encore. This is why New Zealand always beats Australia at Rugby –  we know that the idea is to go BETWEEN the poles…  (The best bit us at 24 seconds)…

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

Converting v2 to FHIR

At the recent Working Group Meeting in Montreal, I participated in the ‘v2 to FHIR’ stream – focused on how can the HL7 community give advice to implementers about converting v2 messages into FHIR bundles.

Broadly there are 2 approaches to this conversion:

  • The creation of a FHIR message bundle that mirrors the contents of the v2 message, and is intended to be an equivalent representation, behaving in the same way as v2 messages
  • Using the contents of the v2 message to update a FHIR server – perhaps extracting Encounter resources or creating a Bundle that is intended to act as a ‘transaction’ bundle against a FHIR server. I think this will be a much more common use case.

In either case, it’s desirable that HL7 should provide the mappings (insofar as that is possible in v2) from v2 to FHIR.

Read more of this post