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.

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 from DiagnosticReport. The specimen also has a reference to the Patient where it was taken from.
• A reference to the encounter when the test was ordered (the ServiceRequest also has a reference)

Note that not all these resources are needed in all cases – it depends on what you are wanting to do. And, of course, you could document this in an Implementation Guide with the appropriate profiles.

And note also that the graph can extend almost indefinitely from here. You might, for example, want to reference the ServiceRequest from the Specimen – and indicate who actually took the specimen.

I had also made an error in asserting that NZPOC only had LOINC codes – apparently there are some custom/bespoke ones in there as well. Bother. To accommodate that, we would need to:

• Create a CodeSystem to define the additional concepts
• Add those additional concepts to the ValueSet. This is actually a good example how a single ValueSet can refer to concepts from multiple CodeSystems.

Here’s the updated NZPOC ValueSet (assuming that there was a CodeSystem defining the bespoke codes with the url http://clinfhir.com/ns/bespokePOCSCodes)

It also complicates the ConceptMap resource a bit. In particular we need to add a second group to represent the mappings from clinFHIRLab to the NZPOC bespoke codes, in addition to the original group that mapped from clinFHIRLab to LOINC.

Here’s the updated ConceptMap:

In case you were wondering, the first group could also be represented as “group[0]”. If it’s omitted, then “0” is assumed…

And finally it was also pointed out that the ConceptMap resource is undergoing significant revision in the next FHIR release (version 5) that will introduce breaking changes. Of course, this is the case with any of the non-normative resource types, but it is something that we should bear in mind, and we’ll discuss it a bit more when we consider an implementation.

Thanks to everyone who took the time to make these comments, the effort is much appreciated.