Stream: implementers
Topic: Provenance Location and Agent clarity
Craig Newman (Mar 18 2019 at 19:09):
Moving this discussion from gForge to Zulip for broader discussion (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=20531&start=0)
As we are mapping V2-to-FHIR, we noticed ambiguity on when to use/update a single Provenance instance or create a new one. When mapping ORC-10, Entered By, for certain OCR-1 Order Action Codes, a Provenance instance would be created. When the ServiceRequest is then verified, e.g., 2 hours later, is one expected to update that first Provenance instance with another Provenance.agent? Or create a new Provenance instance? If the first, Provenance.location seems to be required within Provenance.agent. If the latter, that is not clear. Either way therefore clarification and/or update is required to understand the intended use of Provenance.
Note that in the v2 world, not every Provenance event generates a v2 message. For example, a new order v2 message might have both been entered and verified by different folks at different times. Does this warrant two Provenance records or just a single one with multiple agents?
Craig Newman (Mar 18 2019 at 19:10):
some input from John Moehrke from the gForge ticket:
I don't think the core specification should define this. The two alternatives are reasonable, so they should be defined in implementation guides.
I think, but need to confirm, that the expectation would be that you never 'update' a Provenance record, you create a new Provenance record for the validation activity.
Craig Newman (Mar 18 2019 at 19:10):
And a response from Hans:
If the expectation is that certain actions always yield a new Provenance instance, that the description be updated to reflect that, and that then the reason for Provenance.agent to be 1..* is that that reflects the person and/or organization and/or etc. that are involved at the same time to change the target resource, thus reasonably expected to be in the same location based on the "primary" agent (e.g., the person rather than perhaps a remotely controlled device that is also involved). If that cannot be reasonable assumed, the location should be within agent. It does not seem that these variances would be appropriate for an implementation guide, i.e., subject to varying approaches for essentially the same purpose.
John Moehrke (Mar 18 2019 at 19:25):
I am unclear on what is being asked as a question here, and what is background.
The reason for .agent to be 1..* is to support someone needing to record multiple participants in one act that resulted in one change. An example might be a adhoc team of people working together on a patient problem, producing one update of a set of resources. Another example would be a single individual, using a specified device, using a specified service, to carry out an act that results in a change to a set of resources.
John Moehrke (Mar 18 2019 at 19:28):
If the question is around the use of the .location, vs moving the .location into .agent.location.... I don't think much discussion has gone into the current location of the .location element. It might be very helpful to have a use-case that can be used to drive the right placement of the location
Lloyd McKenzie (Mar 18 2019 at 19:57):
Each 'action' performed at a distinct time should generally drive a separate Provenance. If authoring and verification happen simultaneously, one Provenance is fine. If they're done at different times, then that should be two separate provenance events
Craig Newman (Mar 19 2019 at 16:35):
I think Lloyd's clarification is what we were after. Every action is a provenance record even if multiple actions contribute to a single output (in this case a v2 message that is only triggered after the second action, but with a data relating to the first action)
Lloyd McKenzie (Mar 19 2019 at 17:07):
Essentially all actions in some way contribute to an output. Every change since the original creation 'contributes' to what gets shared "now".
Last updated: Apr 12 2022 at 19:14 UTC
