Accessing Lab data via FHIR – part 4

May 30, 2021 1 Comment

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

Filed under Uncategorized

Accessing Lab data via FHIR – part 3a

May 27, 2021 1 Comment

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

Filed under Lab Data, sushi

Accessing lab data via FHIR – part 3

May 26, 2021 5 Comments

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

Filed under Lab Data

Accessing lab data via FHIR – part 2

May 25, 2021 4 Comments

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

Filed under Lab Data, terminology

Accessing lab data via FHIR – part 1

May 23, 2021 4 Comments

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

Filed under clinFHIR, Lab Data, Uncategorized

clinFHIR Package Viewer

May 11, 2021 1 Comment

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

Filed under package