Stream: implementers
Topic: US Core + Provenance Interactions
Weiyu Zhang (Jul 14 2020 at 23:49):
Hi all,
Quick question for the group about US Core Provenance profile - are search + read support required? The provenance specific page only lists _revInclude from other resources as mandatory search parameters, but the US core capability statement has Provenance interactions as:
Profile Interaction Summary:
SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.
Robert Scanlon (Jul 20 2020 at 20:18):
I don't think search-type should be listed there. But you do need to support the read interaction. @Eric Haas @Brett Marquard
Eric Haas (Jul 20 2020 at 20:24):
yep that is a good catch - copy/paste error - not supposed to be there. will add to the errata.
Weiyu Zhang (Jul 22 2020 at 17:05):
thanks for the clarification! Regarding the read - we're working on adding provenance support on our FHIR server, and we're not sure how to make sure that callers are getting the "correct" version of provenance - e.g.
1) client discovers provenance ID via _revInclude on a documentReference.search
2) documentReference resource changes, provenance is updated as well
3) client calls provenance read, only to get an updated provenance rather than the provenance version for the documentReference that they have
Do you have any recommendations on how to enforce a "sync" in the reads? Or would you expect folks to mainly use _revInclude?
Lloyd McKenzie (Jul 22 2020 at 17:37):
The Provenance resource wouldn't be changed when there's an update to the DocumentReference. Instead, a new Provenance instance would be created - associated with that specific update.
Lloyd McKenzie (Jul 22 2020 at 17:37):
There'll be a separate Provenance instance for the creation and every update, delete, patch or other manipulation of the DocumentReference.
Michele Mottini (Jul 22 2020 at 18:53):
The Provenance resource wouldn't be changed when there's an update to the DocumentReference
Maybe yes, maybe no - depends on server internals. Servers generate some audit trail of changes that are then mapped to provenance, but how this happens can vary a lot I'd imagine
Weiyu Zhang (Jul 28 2020 at 23:55):
Thanks @Lloyd McKenzie and @Michele Mottini! That's the exact issue that I'm dealing with - our current implementation is a many-to-one map of internal audit entries to a single provenance resource. Do you foresee a use case where someone might want to get "older" provenance entries only/"older" provenance entries without the corresponding resource (or an older version of the resource)?
Lloyd McKenzie (Jul 29 2020 at 02:59):
It would be odd to have multiple AuditEvents for a single Provenance. You can certainly search for Provenance and filter by dateTime. @Grahame Grieve, what's the proper search to get back all Provenances for a resource, irrespective of version, when all of the references are version-specific?
John Moehrke (Jul 29 2020 at 13:33):
It is understood that with a versioning server there could be equal versions of a target resource and that target resources Provenance; but given that this is not generalizable, it is not the intended use of Provenance. The intention is that a new Provenance record is created each time a change to a resource happens. Thus Provenance would never be Updated. Thus a client can always understand Provenance without having to first determine if the server is a versioning server or not.
John Moehrke (Jul 29 2020 at 13:34):
also relying on versioning would limit the use of Provenance to support marking many updates with one Provenance instance.
Michele Mottini (Jul 29 2020 at 13:40):
The intention is that a new Provenance record is created each time a change to a resource happens.
This is not going to be the case most of the times. Resources changes because people enter data into forms, V2 messages are received, CDA are processed, CSV files are imported etc etc etc. All interactions that know nothing of provenance or FHIR - they will record _some_ kind of audit log and _maybe_ those can be converted to provenance in some way
John Moehrke (Jul 29 2020 at 13:45):
That is inverted. There should be a Provenance on all of those reasons to update a record. Provenance is not just for direct human, it is for ALL changes.
Lloyd McKenzie (Jul 29 2020 at 14:19):
I don't think @Michele Mottini was arguing about what "should be", he was arguing about "what is" and can reasonably be expected...
John Moehrke (Jul 29 2020 at 14:23):
misuse of any standard can't be prevented. I am just trying to set an intended use. and I thought that the us-core provenance was explicit. So we have done all we can to guide implementers. no question some won't follow.
Also, noted that inside a non-FHIR system there will be many proprietary ways that provenance will be stored or rooted-out. This is systems-design, not anything that FHIR model can affect.
Michele Mottini (Jul 29 2020 at 16:46):
It is not misuse. If you are getting data via an HL7v2 interface that was written 10 years ago you have no control over which kind of logging that generates.
John Moehrke (Jul 29 2020 at 16:54):
yes, that is recognized by my note about non-FHIR systems.
Michele Mottini (Jul 29 2020 at 17:24):
All existing production systems are 'non-FHIR' systems
Lloyd McKenzie (Jul 29 2020 at 19:52):
I don't know about "all" - but certainly that's true of 'most major healthcare systems'
Last updated: Apr 12 2022 at 19:14 UTC
