Stream: implementers
Topic: Provenance period vs recorded
Jay Lyle (Mar 18 2019 at 22:57):
Is there a difference between Provenance.period (activity = enter) and Provenance.recorded? Might .recorded be deprecated?
David Pyke (Mar 18 2019 at 22:59):
Quite a difference. Provenance.recorded is when the activity was recorded into the resource. Provenance.period is when the change to the provenanced resource happenened
John Moehrke (Mar 19 2019 at 12:01):
often these are at the same time.. but one might detect a change, but not able to record a Provenance until later. A good question would be if the recorded element really needs to be a core element, or could be a core extension to help simplify the Provenance resource.
Jay Lyle (Mar 19 2019 at 14:28):
That's kind of the conceptual distinction I see, but I'm not seeing an application.
The VA has a lot of actions that are captured without distinction - entered, signed, verified, e.g. It's assumed that the verification time and the verification entry time are the same - the knowledge work is being done on the EHR.
There a few case where there might be some daylight between the two times, e.g., "dictated." But we don't capture "entry of 'dictated' time." If it were important, there could be another activity.
As it is, having two fields seems to blur the lines between model and meta.
Craig Newman (Mar 21 2019 at 13:22):
I've been struggling with this too. My use case is converting a v2 VXU (immunization event message) into FHIR resources. A number of things happen (1) the vaccine is given, (2) the immunization event is recorded in the EHR, (3) a v2 message is created and (4) that v2 message is transformed into FHIR resources. Would Provenance.period be (1) or (2)? Does it matter that the v2 message, doesn't actually contain a value for step (2)? Would Provenance.recorded be (2), (3) or (4)? And which of these steps is the actual "activity" that the Provenance resource is tracking?
John Moehrke (Mar 21 2019 at 22:25):
I think the only way to answer that is to define an Implementation Guide that covers your specific use-case. The core FHIR specification is not going to decide one way or the other. Core specifications are open to all reasonable needs. An Implementation guide would get specific.
Jay Lyle (Mar 27 2019 at 13:53):
In Craig's example, Immunization already has 1 (Immunization.occurrence) and 2 (Immunization.recorded), so neither would be in Provenance.
For properties that are not in the resource, my assumption is that you'd put whatever record activity(ies) that you want to track in Provenance.
Which is why it looks to me like Provenance.recorded is a redundant and partial representation of Provenance.occurred where Provenance.activity = "record".
(And I'd be uncomfortable putting administration time in there. It is part of the process by which the information was generated, and if you squint hard you could consider it "meta," but as an atoms-not-bits activity I think it's disqualified. It's a business object, not an annotation.)
Lloyd McKenzie (Mar 27 2019 at 15:33):
Just because immunization has them doesn't mean they wouldn't also appear in Provenance. Resources often contain a subset of Provenance information. The Provenance record will duplicate that information - otherwise it'd be pretty useless to search on.
John Moehrke (Mar 27 2019 at 15:49):
For reference there is a complete walk through of the intended overlap between Provenance elements and the various Resources. See http://build.fhir.org/fivews.html#mappings
Last updated: Apr 12 2022 at 19:14 UTC
