Stream: implementers
Topic: Use of Provenance
Vanitha (Aug 30 2018 at 05:15):
Hi All, For which resources, we can use provenance? What is the best way to implement provenance either in front end application or in server side? Can any one suggest me.
Lloyd McKenzie (Aug 30 2018 at 05:19):
Provenance can (and generally should) be used for all resources. Typically the Provenance will be stored on the same system as the record it's associated with, but there's not a firm requirement that be the case. In principle, it can be stored on multiple systems.
Vanitha (Aug 30 2018 at 05:53):
Thank you @Lloyd McKenzie .
We can't create a provenance for every resource?
For example, If we have 10 medications --> 10 provenances
5 Allergies --> 5 provenances
20 Conditions --> 20 provenances
Like that for each & every resource, we need to create provenance.
If it continues, there will be many provenances.
For which resources we have to create provenance, Is there any way to implement provenance resource?
Lloyd McKenzie (Aug 30 2018 at 06:08):
Actually, you'll have a Provenance for the creation of the record, plus each time it is updated or transformed or deleted or otherwise changed. So there will indeed be a LOT of Provenances :) I is possible for one Provenance to refer to multiple resource instance versions - e.g. if multiple resources were created or updated as a single action, but most typically there will be one Provenance for each version of each resource.
There's no "have to" with respect to Provenance (or any other resource) in the core spec. We indicate that it's generally a good idea to have Provenance, but it's not mandatory. Provenance provides several things - it exposes details about what happened to a resource when, why, caused by whom, etc. This information often has clinical relevance. If your users are going to want to see resource history, they're probably going to want to see the associated Provenance records too. Also, the Provenance resources can be extremely relevant when integrating data from multiple sources. Knowing where data came from originally can help when determining how best to combine data and can also help users better understand the context of the information. As data gets shared more easily, having that context becomes more important.
As for "any way to implement", I'm not sure what you mean. Provenance is a resource like any other. In some ways it's simpler, as there's almost never a need to update it and it's pretty uncommon to need to delete it. So in most cases all you have to worry about is "create" and "search".
Vanitha (Aug 31 2018 at 05:18):
Thank you @Lloyd McKenzie .
Should we create provenance to each resource?
We will create a Provenance for a patient (like how we load conformance for server),
it will have all the resources(references for Patient resource).
Can any one suggest me.
Lloyd McKenzie (Aug 31 2018 at 05:28):
As I stated, every single version of every single resource should have it's own provenance instance. The purpose of Provenance is to capture how each version of each resource came into being - who created it, when, why, from where, under whose supervision, etc. It doesn't make sense to have a single Provenance for all resources unless they were all created by the same person at the same time.
Richard Townley-O'Neill (Aug 31 2018 at 05:34):
I think of Provenance resources as like entries in a log of changes. If it is important to know about additions, modifications and deletions, use provenance resources to hold the information.
John Moehrke (Aug 31 2018 at 12:46):
I will only add that you do have a choice on how many Provenance resources you create. For example, in IHE we have a the mXDE implementation guide that describes a use-case of decomposing CDA documents into FHIR Resources. Given that these FHIR Resources came from CDA documents, this is useful Provenance. IHE defines that for every CDA document that is decomposed, ONE Provenance resource would exist. That Provenance resource would have Provenance.entity reference back to the CDA document, and that Provenance.target would point at EVERY FHIR Resource that was found within that CDA document. In this way when one finds in 10 CDA documents an allergy to peanuts, one would have one FHIR AllergyIntolerance indication for peanuts, that one AllergyIntolerance would be pointed to by 10 different Provenance resources, each Provenance resource points at their own CDA document. Thus one can also look at the Provenance that is pointing at a CDA document as an entity (source of data), and see all the information derived from that CDA document. (Same can be done with other document types, I am using CDA only for illustrative clarity).
Lloyd McKenzie (Aug 31 2018 at 15:54):
Right. It's one Provenance instance per "record action". If a single action affects multiple records, you only need one Provenance.
Last updated: Apr 12 2022 at 19:14 UTC
