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.

Before we go any further we have to recognize that mapping concepts is hard – really hard.

Different codesystems look at things differently, and it can be very tricky to decide if two codes represent the same thing. The context of use can also play a part – we might map things differently if we’re collecting codes for billing purposes than if we are intending to support care delivery. And just exactly what does ‘equivalent’ actually mean? Is a random blood glucose the same as a measurement taken 1 hour into a Glucose Tolerance Test?

Naturally we’re going to simplify all of that for this discussion, but if you are doing this for real, it would really pay to seek the advice of people and organizations that know how all this stuff works.

The example we’re going to use is where we have a repository of lab data that receives results from multiple labs, each of which has its’ own custom codes but we want to be able query this data using the New Zealand  Pathology Observation Code sets (NZPOC).

But first, we need a bit more background.

Take another look at the diagram of terminology resources from the spec:

Last time we focused on the CodeSystem and ValueSet – this time we’ll take a look at the ConceptMap (the purple box at the top). As its name suggests, the purpose of this resource is to define mappings for concepts in one codesystem (the source) to another (the target). Mappings are always one way – if you need to map in the reverse direction then another mapping is needed.

The example we’ll be discussing is where we have a laboratory with their own codes, and we want to map those codes to the LOINC codes defined in NZPOC. We’ll be able to define all the mappings for a lab in a single ConceptMap resource. So – we’d need another ConceptMap for a different lab – or if we wanted to map back from LOINC to the labs bespoke codes. (Actually, a single ConceptMap can have bi-directional maps – and could even map codes from different systems – so it’s a preference more than a limitation of the resource).

Here’s how we’ll set it up.

• There will be a CodeSystem that describes the bespoke Lab codes (we’ll create a url for it that will be the system). It will contain all of the lab codes (in the CodeSystem.concept element), with a description of each one.
•  We’ll also create a ValueSet (with url) that includes all of the lab codes. This is quite easy – we just include all the concepts from the CodeSystem in the ValueSet

Here’s what it could look like. We’ll use FSH to represent this as it’s straightforward to visualize – and to write. It’s not the way that the resources are represented ‘on the wire’ (Json & XML are generally used for this), it’s an authoring tool and uses the sushi tool to generate the FHIR resources from the FSH. For more details on FSH, check out the FSH School, or search for FSH in this blog.

This CodeSystem has only the code and the display of the code – there are other properties we could add if needed.

NZPOC will also need a ValueSet – but as all the codes in it are LOINC codes, no additional CodeSystem is needed – rather there is a list of the codes from LOINC in it as shown below. This is called an extensional list, as opposed to intensional where there are some kind of rule rather than a list (the clinFHIRLab ValueSet was intensional).

As an aside, note that we used an Alias for LOINC to avoid having to repeat the LOINC url all the time. And we need to specify the url as a ValueSet can have codes from multiple codesystems, though that’s not the case here.

So now that we have the CodeSystems and ValueSets for both Lab (source) and NZPOC (target) we can create the ConceptMap for mapping from lab bespoke code to NZPOC LOINC.

This isn’t quite as tidy as the other resources (FSH doesn’t yet have specific handling for ConceptMap) but it should be pretty straightforward to follow. There’s a single group with a source (line 50) and a target (line 51) code system.

Then, each mapping has a separate element with a number of attributes of the mapping (there are others you can use).

The concept of equivalence gives more detail to the mapping – here we are saying that the concepts from the 2 CodeSystems are the same.

So now that we’ve created all our resources we can finally use them!

We’ll pick that up in the next post.