Hay on FHIR

Custom Search Parameters

A post on custom search parameters from my good friend Brian Postlethwaite

Well worth a read – and try out his FHIRPath Lab tool too!

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.

Representing Recalls

Recently I was asked by a local vendor what was the best way to record a recall in a Practice Management System (PMS).

As background, in New Zealand (and likely elsewhere) it is common for a Primary Care Practitioner (what we call a General Practitioner) to create a ‘recall’ for a patient. These are essentially reminders that a patient needs a follow up for some purpose within some time frame. 

Examples of recalls include:

• The patient has a mildly abnormal blood test – not worth acting on immediately, but should be checked again in a month or so to see if it is changing
• A mildly elevated blood pressure was taken during a routine visit. Again, not high enough to consider treating immediately, but should be checked in a month or so.
• The patient is eligible for a screening program – such as a cervical smear – and needs to have one performed in 2 years time
• A child due for their scheduled immunization
• An elderly person is not coping at home – have the nurse contact them in a week to see how they are going

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).

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.

Creating sample data with GraphBuilder

One of the things I find myself doing quite often is helping people design FHIR API interfaces. Of course, the actual API itself is defined by the FHIR standard – but the parts that are implemented by any given system will vary tremendously – particularly with regard to API features like chaining, reverse chaining and the _include search parameter.

What I find very useful is to create a small set of sample data and save to a generic FHIR server (I use the HAPI server generally, though there are others available these days). Then, I can test out the API calls against that sample data set to make sure I have the syntax right – and they are returning the results I expect.

HL7 New Zealand

Well written article on the early days of HL7 in New Zealand written by the current chair, Peter Jordan.

I think he understates his own role in health IT in our part of the world, maintaining both GP2GP and the prescription service.

Accessing Lab data via FHIR – part 4

In this final post for the lab series, we’ll take the terminology resources that we created in the previous post and use them to map codes from the laboratory bespoke coding system to the (mostly) LOINC based NZPOC set.

A quick reminder of what those resources were:

• A CodeSystem and ValueSet that held the descriptions of the bespoke lab codes
• A ValueSet for NZPOC, plus the CodeSystem for the non-LOINC codes.
• A ConceptMap that defined the mappings from lab code to NZPOC (and we’re assuming that all the bespoke codes could be mapped – in practice you’d need a strategy for codes that couldn’t be mapped.)

Read more of this post