Stream: implementers
Topic: Patient-related Provenance
Jose Costa Teixeira (Mar 04 2022 at 08:00):
A project needs to track who changed clinical data about a patient (not the Patient resource). Like updating an ObservationX for a Patient1.
From the Provenance resource, I see the Patient could be mentioned as a Target, but the definition of the Target seems to contradict this, since the Patient has not changed, it was the Observation that changed.
Jose Costa Teixeira (Mar 04 2022 at 08:01):
has this been considered?
Jose Costa Teixeira (Mar 04 2022 at 08:02):
From the structure of the resource, I would put the Patient as an entity in the Provenance resource, but this would not be aligned with the search parameter that exists for patient.
John Moehrke (Mar 04 2022 at 13:28):
Provenance is about the data that was created/changed. It is not about the patient.
John Moehrke (Mar 04 2022 at 13:29):
When the Patient is the one changing the data, then the Patient is the Provenance.agent
John Moehrke (Mar 04 2022 at 13:30):
When the Patient is not involved in the changing of the data, then the Patient is not mentioned anywhere in the Provenance resource
John Moehrke (Mar 04 2022 at 13:31):
Ah, so you are mentioning that in Provenance, the patient search parameter is defined as
patient reference Target Reference(s) (usually version specific) Provenance.target.where(resolve() is Patient)
(Any)
That is very odd indeed. I would not have expected at patient search parameter at all.
John Moehrke (Mar 04 2022 at 13:32):
Or would have expected it to be more like AuditEvent patient search parameter that looks broader.
John Moehrke (Mar 04 2022 at 13:33):
This noted... We approved a CR this week to add a Provenance.patient (and AuditEvent.patient) that are to be filled when there is a patient known to be an agent, entity, or subject of the data in the activity (entity->patient). So this search parameter will change to that element.
Lloyd McKenzie (Mar 04 2022 at 14:53):
Provenance should always have an explicit reference to the Patient if the Provenance.target is part of the Patient compartment. That's essential to access control. I thought we'd agreed to do that in R5 @John Moehrke?
John Moehrke (Mar 04 2022 at 14:57):
no. we did not agree to that
John Moehrke (Mar 04 2022 at 14:57):
but we did this week agree to add a .patient
Sukanta Barai (Mar 04 2022 at 15:00):
Sure.. Thank you for your update.
Lloyd McKenzie (Mar 04 2022 at 15:01):
Isn't that what .patient would do?
Lloyd McKenzie (Mar 04 2022 at 15:02):
Certainly I would expect there to be a rule mandating it for Provenance that points to records that are tied to a single Patient.
John Moehrke (Mar 04 2022 at 15:03):
the .patient would enable compartment.. yes. but it would be distinct from Provenance.target (which is ONLY the changed resources), and Provenance.agent (which is all the agents involved), and Provenance.entity (which is the entities directly used in the activity).
John Moehrke (Mar 04 2022 at 15:03):
yes, that is the idea
John Moehrke (Mar 04 2022 at 15:04):
Ill try to get that into the current build today. we just approved the CR on monday
Daniel Venton (Mar 04 2022 at 15:10):
And if the provenance targets many resources and those resources cross multiple patients, how does the ,patient reference reference THE patient? Are we now saying that provenance cannot span resources that span multiple patients?
Daniel Venton (Mar 04 2022 at 15:12):
What if the provenance spanned patient compartment and non-patient compartment resources?
John Moehrke (Mar 04 2022 at 15:18):
the CR recommends that when an activity involved more than one Patient, then multiple Provenance instances would be created so as to prevent leakage between patient compartments.
John Moehrke (Mar 04 2022 at 15:19):
only patient compartment was persuasive. other compartments can be handled by extensions.
Last updated: Apr 12 2022 at 19:14 UTC
