Stream: implementers
Topic: Modelling provenance
Andrew Berry (Jun 23 2021 at 04:13):
We’re trying to use FHIR Provenance to record activities against patient-related resources. The target of the Provenance resource is not a patient resource, but we want to search by patient identifier. The obvious modelling is to reference the related Patient resource in a Provenance.entity reference, which is searchable. The entity reference has a mandatory role parameter coded using the ProvenanceEntityRole valueset, which is not extensible (https://www.hl7.org/fhir/valueset-provenance-entity-role.html). None of the role definitions seem to fit. Perhaps ‘source’ but it has a rather convoluted definition that isn’t very deterministic.
My question: can we use ‘source’ in this case? If not, how else could we capture a searchable patient identity in the Provenance resource?
Would appreciate any suggestions. Thanks.
David Pyke (Jun 23 2021 at 13:08):
@John Moehrke
John Moehrke (Jun 23 2021 at 13:11):
Provenance is intended to be used to determine the provenance of a resource. It does not have use-cases for discovering all the Provenance for a given subject. The Provenance resource design is intended to cover specifically provenance use-cases, and not more.
John Moehrke (Jun 23 2021 at 13:12):
It sounds like you are looking for a function that the AuditEvent does cover. And it covers it much like you have expressed. And AuditEvent covers more than just Create/Update events, it covers queries and reads and more.
John Moehrke (Jun 23 2021 at 13:13):
We have added clarifications of this in the R5 build - http://build.fhir.org/auditevent.html#patient
Andrew Berry (Jun 23 2021 at 22:33):
Thanks John.
John Moehrke said:
It sounds like you are looking for a function that the AuditEvent does cover. And it covers it much like you have expressed. And AuditEvent covers more than just Create/Update events, it covers queries and reads and more.
They’re not AuditEvents because they are intended for clinical review (noting from AuditEvent “This content is not intended to be accessible or used directly by other healthcare users”). That said, re-reading the Provenance definition in light of your comments I can see we are stretching the definition. We could perhaps take a slightly different approach and say that the Patient resource is the target since we are tracking changes to the patient clinical record, but I suspect this is still stretching the definition.
Other thoughts or suggestions?
Lloyd McKenzie (Jun 25 2021 at 16:42):
You might need to define a custom SearchParameter
John Moehrke (Jun 25 2021 at 17:04):
The note on AuditEvent is more to distinguish Provenance from AuditEvent.
John Moehrke (Jun 25 2021 at 17:08):
Possibilities:
a. add an extension in Provenance for .patient and search parameter
b. make this extension core in FHIR.. by proving it useful beyond a specific project
c. proving it useful it is recognized as a core element in Provenance.
d. define an operation that works on magic (use of $everything with reverse include on Provenance)
I could be convinced this is core. The Provenance layout is generic, and thus not considering the Healthcare needs.
But we would need more than one person interested.
John Moehrke (Jun 25 2021 at 17:10):
Drawbacks of adding a patient element (extension or core) is that this adds overhead to everywhere Provenance is recorded that there is an evaluation of if a Patient is relevant (not all FHIR resources are patient relevant). and then extraction of the Patient id relevant (which sometimes it is a step away).
Daniel Venton (Jun 25 2021 at 18:52):
What if the Provenance targets resources from multiple patients? A bulk update, insert process.
John Moehrke (Jun 25 2021 at 19:10):
yup, more issues with this.
Andrew Berry (Jun 27 2021 at 07:44):
Thanks, interesting discussion. Our use case is patient clinical review, patient history and (potentially) clinical audit, so a singular patient resource is reasonable for this use case.
I don’t think it would be adequately covered by history on the Patient resource as other resources are necessarily involved and the specific agent and activity is important (i.e. knowledge of data changed is not necessarily sufficient). It isn’t really resource provenance because it’s about the patient rather than the resources themselves, but it is about activity involving a patient, the agent responsible, and and other entities involved in the activity. You can perhaps interpret the English language meaning of “provenance” to include this.
Would a clinical “PatientProvenance” or perhaps “ClinicalAuditEvent” resource be appropriate or warranted?
Lloyd McKenzie (Jun 27 2021 at 15:30):
I have trouble imagining those being added. Those sound more like profiles and IGs built on the existing resources.
John Moehrke (Jun 27 2021 at 15:55):
if added they would be huge overhead and thus very unlikely to be filled out. Provenance itself is unlikely to be filled out without some community policy requiring it.
John Moehrke (Jun 27 2021 at 15:56):
I am unclear on why a review of the Patient compartment is not sufficient?
Andrew Berry (Jun 27 2021 at 23:10):
Regarding Patient, there are a few reasons it doesn’t work for us:
- activity and agent are important and this is not captured or coded in our case
- at present we don’t have access to adequate history for the resources in question
In an ideal world we could perhaps access them via Patient history and linked resource history. Our world probably won’t be ideal for a while yet. The limited compliance on resource history and the request pattern captured in history are also likely to make it troublesome to reliably capture activity and agent, especially if multiple repositories are involved.
Andrew Berry (Jun 27 2021 at 23:12):
Note that based on this discussion, we will most likely model around existing resources.
John Moehrke (Jun 28 2021 at 12:11):
So for activity and agent consistency it does seem like you need a policy requiring Provenance. I think what I was pushing back on is the modification of Provenance to include a Patient. I was more pointing that there is already the $everything (aka Patient compartment) that is defined to find everything; from which you can get the Provenance for all of that. Wrap this algorithm into an operation -- $provenanceOfEverything
Andrew Berry (Jun 29 2021 at 05:01):
That makes sense John. I wasn’t particularly wanting to change the current resource definition. We will likely use Patient as our target resource and explicitly identify relevant subordinate resources in entity references.
John Moehrke (Jul 06 2021 at 14:26):
so you are planning on adding to all Provenance records a Provenance.target of the Patient impacted? Yet the activity that caused the Provenance did not revise the Patient resource... this would be against the definition of the .target element. Far better to add a Provenance.entity of the Patient as a resource that was read (source). This is not directly the intent, but surely it is true that anything created/updated (Provenance.target) was created/updated with knowledge of the subject. (This is what I recommend in AuditEvent for similar purpose). -- I don't think this is the proper solution, prefer the use of AuditEvent as it already does this (and includes read and query).
Last updated: Apr 12 2022 at 19:14 UTC
