Stream: implementers
Topic: Deleted data in AuditEvents
James Jahns (Feb 02 2021 at 15:52):
Hello,
I am having trouble with how to represent a deleted element in an AuditEvent.
Currently, I am populating
entity.detail.type = {name of element modified}
entity.detail.value = {value it was modified to}
However, both entity.detail.type and entity.detail.value are cardinality 1..1 ,
so I can't leave entity.detail.value blank to communicate a delete.
Is there a better way to structure this so that deletes can be communicated?
I would like to keep this info in the entity BackboneElement so that I can point to the relevant Resource, and since I'd like to specify which element was deleted, just populating action="Delete" on the AuditEvent seems incorrect.
Lloyd McKenzie (Feb 02 2021 at 16:56):
@John Moehrke
John Moehrke (Feb 02 2021 at 17:05):
I happen to be writing an IG on basic auditEvent profiles for REST.. i am not yet to Delete... but will get there.
John Moehrke (Feb 02 2021 at 17:05):
The notional concept is that you just put the former resource id into the .entity.what
James Jahns (Feb 02 2021 at 18:17):
My problem is that it's not an entire resource that's deleted, but rather just some element/field of it. So there is still a valid Resource ID but some of its data has been removed; I'm not sure where I can best put the name of this element. (at any rate, an IG for this sounds helpful!)
Lloyd McKenzie (Feb 02 2021 at 19:26):
Removing some information from a resource is just an update.
James Jahns (Feb 02 2021 at 19:50):
Right; does that mean I can't provide the details of this update however? Ideally I'd like to specify the element that was changed. For example, "User X has deleted the value of Observation.note" or similar. Using AuditEvent.entity.detail works for most updates, but not for updates that don't have a value.
John Moehrke (Feb 02 2021 at 20:35):
As lloyd mentions. that is an Update. The AuditEvent (and Provenance) is there to indicate that an update happened. Where it is important for the before and after to be known, the solution recommended in FHIR core is to use a versioning FHIR service implementation. In that case the version specific id is recorded for the old resource. Thus you can always compare that version with the version that followed it. Replicating these differences within the AuditEvent or Provenance is not the intent of the model.
James Jahns (Feb 02 2021 at 21:08):
Okay, that makes sense; thanks for the explanation!
John Moehrke (Feb 02 2021 at 21:31):
@James Jahns I have taken a first crack at an IG for AuditEvents for REST. I only have Create, Read, Update, and Delete done. I will now work no Query. I welcome comments. I do have some open questions to myself, so adding others questions would be good.
http://build.fhir.org/ig/JohnMoehrke/BasicAudit/branches/main/index.html
This is not a formal project, I wanted to exercise the concept before proposing it as formal. It is based on the intention noted on the AuditEvent core page, but it does deviate a bit.
Last updated: Apr 12 2022 at 19:14 UTC
