Where did that data come from?

This post grew out of a question from one of the Analysts at Orion Health. We’re in the process of embedding FHIR pretty deeply into our product stack – and part of that involves creating FHIR interfaces to our existing data repositories.

This particular repository takes data feeds from a number of sources – mostly in the form of v2 messages, but also including CCDA documents – and from them extracts clinical data of interest such as encounters, procedures, problems and so forth. Because of the varied source of the data, one of the data items in the existing output that is displayed to the user is where it come from – ie which facility and possibly which application. (As much as we’d like to get the clinician, this data is not generally available in v2 messages).

So they question they asked me was – ‘where does this stuff go in FHIR’?

At first, this looked like quite a simple question – the provenance resource is “a record-keeping assertion that gathers information about the context in which the information in a resource was obtained”

But as we dug into the details, the situation for us became a bit murky.

The connection between provenance and the resource it refers to is from Provenance to Resource. This is in keeping with the general pattern we have in FHIR that resource references tend to be from the ones created later to the ones created earlier – otherwise resources need to be updated, which adds significant complexity to the server (and the client). For example a Procedure refers to the Patient – not the other way around. You can imagine all the issues if you needed to update the Patient resource every time you created some data.

The provenance resource would need to be a separate resource in the bundle and in order for the UI to be able to display the source alongside the resource details, then the UI code would need – for each resource – to locate the appropriate Provenance and extract the source details from there. Do-able, but not attractive.

It would be made a bit easier if we ‘contained’ the Provenance resource inside the one to which it refers – but then the reference direction becomes an issue. A ‘container’ resource is meant to have a reference to the ‘contained’ resource, and so the direction is wrong.

And then the actual Provenance itself doesn’t really seem to fit our particular use case. The Provenance.agent node seemed the logical place to store that information, but that is a reference to another FHIR resource, which we are not specifically identifying (in theory we could – it is an HD datatype, but we aren’t). We could of course just put the text there in the display element… (And, as we will see, it isn’t really the correct place anyway!)

And there’s significant capability in Provenance that we don’t need.

I asked the question on the FHIR list – and got a great response and a comment from John Moehrke made the penny drop.

What we’re actually doing is to build a model from information in the v2 message. In the case of a Procedure for example, we’d get most of the data from the PR1 segment. All we want to do is to be able to say that ‘we were told this by the GoodHealth Clinic’ – and we get that from the MSH segment. We aren’t wanting to track back to the original v2 message.

Now, if we DID want to be able to do so, then a better approach would be:

• Save the v2 message somewhere, and establish a URI that can refer to it.
• Create the various derived resources – like the procedure above, which might also involve identifying the other resources that it references (like Patient, Organization whatever)
• Create a Provenance resource that:
  • refers to those derived resources (and there can be more than one of course) using Provenance.target.
  • refers to the original v2 message using Provenance.entity.reference.
  • indicate the facility from where the message came (which is what we want here) using Provenance.entity.agent (modeled as a FHIR resource of course)

For our specific requirements – and the timeframes we have – this isn’t really an option for us, so for the moment we’ll create an extension that we’ll use for all resources derived from v2 messages. But – now that we have a better understanding of how this should work – we can consider adding this functionality in future versions.

As mentioned above I’m deeply grateful for the input of those in the FHIR community – I hope that I got it all right!

Oh, and this is a reference that came up in the conversation to a blog post from Rene Spronk about v2 -> FHIR mapping in general.