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

Accessing lab data via FHIR – part 3

In this post we’re going to take a look at more aspects of coding data. We spent a bit of time in the last post describing why we want to have data coded, how FHIR supports coded data – especially the external terminologies where the concepts are defined – and described some of the RESTful API calls that we could make to retrieve specific Observations and DiagnosticReports from the repository.

But in doing so, we make one key assumption – that all the data in the repository was properly coded with consistent codes – and this is actually not that common in the real world, especially for repositories that are collecting data from different sources. (It’s a bit easier when it is a single lab exposing their data and have complete control over the coding used)

So let’s think about how to manage the situation where there may be different codes that mean the same thing, a good example of which is where labs are using their own coding system rather than an external one such as LOINC.

Ideally what we want to be able to do is ‘map’ all of the codes that mean the same thing to a single concept – preferably a concept from a known codesystem which as LOINC or SNOMED.

We’ll focus on setting up the ‘definitional’ part of the mapping here – in the next post we’ll talk about implementing it.

Read more of this post

Accessing lab data via FHIR – part 2

In the previous post we took a look at the overall organization of the resources involved in representing Laboratory tests and what an API to retrieve them might look like.

But the queries that we discussed were rather ‘blunt’ – just retrieving results for a person with minimal filtering. While that’s often needed, being able to make more targeted queries can be a whole lot more useful (especially when we want to chart it or include data into Decision Support routines), and that brings us onto the topic of coding the data – the subject of this post.

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

When an Implementation Guide is built by the IG Publisher (and presumably other build applications like simplifier), one of the outputs is a zipped package (actually a tarball)  that contains all the FHIR resources defined by the Implementation guide – profiles, extension definitions, terminology and conformance resources and such like. It’s based on the NPM package scheme as described on the HL7 Confluence page.

This package can then be saved in the International FHIR registry so that it can be discovered and downloaded by implementers. There’s a description of the registry on the HL7 confluence site, as well as from the registry itself.

While the package doesn’t contain the textual part of the IG, it does have all the computable artefacts that an implementer might need, as well as a manifest file (package.json) which contains a number of goodies about the IG – such as the canonical url, which can be used to view the full IG.

This post is to introduce a new clinFHIR module that can display the contents of a package. It works by downloading a copy of the package from the FHIR registry and saving it on the clinFHIR server.  Subsequently, the contents can be displayed to the user. The download only needs to happen once, as a particular version of a package is immutable – it is guaranteed not to change.

Read more of this post