Stream: implementers
Topic: Element level provenance
Rik Smithies (Mar 05 2021 at 15:15):
Other than PATCH, has anyone considered annotating a resource to say what data has changed from a previous version?
I would like to able to show the difference between two versions of a document, so this is not necessarily a RESTful update.
Are there extensions that can annotate an element to say if it has changed?
Could Provenance point from the outside at an element of a resource (via element.id)? e.g. /Composition/1234#section1
Possibly it could if an extension was added to Provenance to say what element(s) of the target were altered?
David Pyke (Mar 05 2021 at 15:16):
IF you have a versioning server, that's done automatically. Otherwise you can do it through audit
Rik Smithies (Mar 05 2021 at 15:18):
it shows you field by field what has changed?
David Pyke (Mar 05 2021 at 15:18):
Audit could, it depends on how you audit. But a versioning server has all versions of a resource and you can deduce the changes from there
David Pyke (Mar 05 2021 at 15:19):
Provenance tells you it did change but not what the changes necessarily are
Rik Smithies (Mar 05 2021 at 15:19):
yes but the idea is not to deduce, but to declare. And also, there is no RESTful server in this scenario
David Pyke (Mar 05 2021 at 15:21):
Then I'd rely on AuditEvent for that.
John Moehrke (Mar 05 2021 at 15:21):
if you have a versioning server, you can pull the previous version and compare it to the current version. Versioning servers are the right way to know details on what changed.
John Moehrke (Mar 05 2021 at 15:21):
AuditEvent does not tell you what changed. It only indicates who, why, when, and which versions
John Moehrke (Mar 05 2021 at 15:22):
thus if you need to know what elements changed from what values; then you need to require that the server be a versioning server.
Rik Smithies (Mar 05 2021 at 15:22):
as mentioned, I don't have a versioning server - or any server. And I don't want to deduce, I want someone to be able to declare changes, at an attribute level
David Pyke (Mar 05 2021 at 15:22):
You could use entity.detail to have the changes but it's not the best way but without a versioning server, not much can be don
Rik Smithies (Mar 05 2021 at 15:24):
I don't have a server. Let's say I am emailing you a FHIR document, and I want to annotate it with changes.
John Moehrke (Mar 05 2021 at 15:24):
the method that is available in FHIR core is to use a versioning server
David Pyke (Mar 05 2021 at 15:25):
Rik, then I'd include an AuditEvent with the changes listed in .entity.detail
John Moehrke (Mar 05 2021 at 15:25):
specifically versioned Resources
David Pyke (Mar 05 2021 at 15:25):
Again, it's a hack but it would work.
David Pyke (Mar 05 2021 at 15:26):
John, he doesn't have a versioning server. THink of a second way
Rik Smithies (Mar 05 2021 at 15:28):
so entity.detail.type could be "resource-element" and entity.detail.valueString could be the element name itself
John Moehrke (Mar 05 2021 at 15:29):
then why not use a PDF file... I thought we were a standards org, forcused on use of FHIR
John Moehrke (Mar 05 2021 at 15:30):
the appropriate use in FHIR is versioned Resources. Versioned resources can be sent in a message. or persisted into a document.
Rik Smithies (Mar 05 2021 at 15:30):
John - the FHIR standard includes documents
Rik Smithies (Mar 05 2021 at 15:31):
documents don't need to use REST
Rik Smithies (Mar 05 2021 at 15:31):
and it seems that only the RESTful server can do the processing. And in fact, they don't do this sort of processing for a client anyway.
Rik Smithies (Mar 05 2021 at 15:32):
how do I ask a server for a list of changes between two resources?
John Moehrke (Mar 05 2021 at 15:39):
https://www.hl7.org/fhir/versioning.html
John Moehrke (Mar 05 2021 at 15:39):
which does work in a Document too
John Moehrke (Mar 05 2021 at 15:40):
sorry, wrong paste
John Moehrke (Mar 05 2021 at 15:41):
https://www.hl7.org/fhir/resource.html#versions
Rik Smithies (Mar 05 2021 at 15:43):
thanks John, but where is the part that generates and exposes the list of changes for me? That is the issue at hand. I don't think this addresses that. I can understand "no, you have the wrong use case, you should use a versioning server" :-) but this doesn't seem to work even if I was using a versioning server. I don't need old versions, I am looking for deltas. Like tracked changes in Word, but for resources. Word doesn't just show me the old version and let me figure it out.
John Moehrke (Mar 05 2021 at 15:45):
the historic versions are what you have. Working out what the difference between 3 and 4 is an exercise left to the client.
John Moehrke (Mar 05 2021 at 15:45):
possibly a good toolkit could provide some functionality that you are looking for
Rik Smithies (Mar 05 2021 at 15:48):
I already have the new and old versions. What I want is a way, once I know the changes, to record those changes for others to see. AuditEvent and entity.detail seems to be the way.
John Moehrke (Mar 05 2021 at 15:52):
The recommendation is to NOT put that kind of detail into Provenance or AuditEvent. The recommendation is to rely on versioning of resource instances. If you put this level of detail into AuditEvent, you will make the AuditEvent a duplicate database from the core FHIR endpoint.
John Moehrke (Mar 05 2021 at 15:52):
there is no one that will stop you from doing this. It is simply against recommendation.
Rik Smithies (Mar 05 2021 at 15:55):
in this scenario there is no core FHIR endpoint
John Moehrke (Mar 05 2021 at 16:09):
@Lloyd McKenzie
John Moehrke (Mar 05 2021 at 16:29):
Note that there is a long standing approved FHIR-I CP FHIR-21284 that would be a core method available in Provenance and AuditEvent to indicate specifically a Provenance record to a specific element level change in a target resource. This CP has not yet been applied to R5, and is unclear what it will look like, and thus how Provenance.target would change to leverage it.
John Moehrke (Mar 05 2021 at 16:31):
This method does NOT replicate the change in Provenance, but rather would allow one to express a subset of element changes as being the Provenance. This is, I think, different from what you are asking for
Lloyd McKenzie (Mar 05 2021 at 16:48):
If you have a document, there are a few 'typical' ways of communicating change:
- send both versions (you can have multiple versions of a resource in a document) which allows the receiver to see exactly what's changed
- use List which allows you to flag what's added, deleted and modified for things like drug lists, problem lists, etc.
- provide a text summary of changes in a clinical note
There's no "standard computable" way of sharing a list of changes, though embedding details in AuditEvent is a kludge that is potentially workable.
Rik Smithies (Mar 05 2021 at 17:20):
@John thanks. Actually those look like exactly what I was originally looking for.
I am wanting to say "these exact elements have changed". I was thinking that was provenance rather than audit but I am a little blurry on the difference.
If this was approved is there a reason they were never applied? I see comments asking the same. It appears that they apply to all references. Powerful. I would be happy to apply this change to R5 build.
Last updated: Apr 12 2022 at 19:14 UTC
