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

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

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

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

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.

Read more of this post

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

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

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