At the FHIR Connectathon last week I participated in the Questionnaire track and spent most of my time there using – and integration with – the fhirpath lab questionnaire tester tool  maintained by Brian Postlethwaite – one of the foundation members of the FHIR community. The tester is part of a suite of tools that started with a focus on providing an app that helps people build FHIRPath expressions – then branched out from there (as these things tend to do). Here’s a screenshot of the front page: In this post we’ll be focussing on the Form Tester – we can look at some of the other modul ..read more

A post on custom search parameters from my good friend Brian Postlethwaite Well worth a read – and try out his FHIRPath Lab tool too ..read more

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 ..read more

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). To set the FHIR version for your project, create a new project and select the FHIR version at the bottom of the form. This has a number of consequences: The resource types available for selection are those in the selected release The links to the spec and details of the resource types ..read more

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. We’ll start by looking at the viewing application – the clinFHIR Bundle Visualizer. This module has actually been around for quite a while – I started it when we were looking at v2 to FHIR messages a number of years ago but in t ..read more

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 ..read more

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 mak ..read more

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 ..read more

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 ..read more

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. One reader noted that it would be good if there was a resource to represent the specimen. Well, actually there is! I had shown only some of the possible references from DiagnosticReport in the previous post. Here’s a more complete graph (leaving out only some reference to images): Additional resources include: A reference to Practitioner to represent the interpreter of the result The specimen reference ..read more