Stream: implementers
Topic: pointers to provenance
Josh Mandel (Feb 17 2017 at 17:31):
http://build.fhir.org/medicationrequest-definitions.html#MedicationRequest.eventHistory includes a link to Provenance. But doesn't Provenance link back to the resource it describes? Does this violate our principle of having links go only in a defined direction (not back-and-forth)?
John Moehrke (Feb 17 2017 at 17:36):
It would be a violation if it was pointing at its own Provenance. But the definition seems to indicate that it is pointing at historic Provenance. This should not be needed, as they are just as discoverable...
John Moehrke (Feb 17 2017 at 17:40):
Note that DeviceRequest was a big more clear http://build.fhir.org/devicerequest-definitions.html#DeviceRequest.relevantHistory
John Moehrke (Feb 17 2017 at 17:44):
also ProcedureRequest seems to be using similar good words. Should ask this pattern be brought to all the others. http://build.fhir.org/procedurerequest-definitions.html#ProcedureRequest.relevantHistory
John Moehrke (Feb 17 2017 at 17:45):
is this something QA can fix? @Lloyd McKenzie @Grahame Grieve
Lloyd McKenzie (Feb 17 2017 at 18:38):
Not sure about doing it QA, but certainly a non-substantive change that pharmacy can make any time before a week Sunday. @Melva Peters ?
Eric Haas (Feb 17 2017 at 18:41):
Ah.. good this got your attention. What is a good example use case for this. I put a signature in my examples. Is that appropriate.?
Melva Peters (Feb 17 2017 at 18:43):
Pharmacy has been waiting for some guidance on how to use Provenance for the EventHistory. I'll look at procedurerequest and update
Eric Haas (Feb 17 2017 at 18:45):
@Melva Peters I guessed on this and would like someone to confirm is appropriate. (Questions like these make me wonder if the element should be delegated to extension island.)
Melva Peters (Feb 17 2017 at 19:18):
It isn't an extension for the pharmacy resources. We originally had eventHistory in to include the changes that occur over the lifecycle of a record such as a medicationRequest. The guidance we were given was to include Provenance which now aligns with the workflow pattern. Just need some additional guidance on how to use this.
Josh Mandel (Feb 17 2017 at 21:21):
It's pretty unclear how you'd capture the relevant events, though — just saying "here's a list of Provenances" doesn't really give developers a good idea of what to expect
John Moehrke (Feb 17 2017 at 21:41):
It is however a fantastic opportunity for STU3 experimentation with feedback.
Josh Mandel (Feb 17 2017 at 21:45):
Yes, but the back/forth references seem like a problem to me.
John Moehrke (Feb 17 2017 at 21:49):
I agree. especially since a Provenance will point at many targets. Some of those targets would be useless as historic evidence. I was expecting that historic evidence would be more direct, not by-way-of a Provenance.
John Moehrke (Feb 17 2017 at 21:50):
for example when a CDA document in imported into a FHIR Server, it will have one Provenance record that will point at all the various FHIR resources (CDA-on-FHIR). Huge number of very different Resources.
Lloyd McKenzie (Feb 18 2017 at 07:04):
History only points to provenances associated with prior versions, not the current version.
Last updated: Apr 12 2022 at 19:14 UTC
