Stream: implementers
Topic: AuditEvent Implementation
Mona O (Sep 12 2019 at 03:29):
We have the need to capture a correlation id, who (individual user GUID) and when any operation is performed for auditing purposes. We are only performing read operations and not creating or updating any information. It appears AuditEvent is a good fit over Provenance, but I'm not entirely clear how a consumer would provide the AuditEvent information. Can it be used as a custom header like Provenance? If it can't be provided as custom header how would an AuditEvent be submitted along with a specific resource (ex. Coverage)? We have traditionally requested this information in our headers (x-correlation-id, x-source-system, x-user).
Lloyd McKenzie (Sep 12 2019 at 11:07):
To make sure I understand, the client system provides a unique id for every query they do that the server stores as part of their AuditEvent to allow linking the server's audit record with the client's audit record?
Grahame Grieve (Sep 12 2019 at 11:12):
see X-Request-Id in http://hl7.org/fhir/http.html#custom
Mona O (Sep 13 2019 at 22:08):
@Lloyd McKenzie Yes, the client system provides a unique id for every query and we also need to capture an unique id of the user who initiated the action. Looking at http://build.fhir.org/http.html I see that "X-Request-Id" would work for the client system id, but I don't see anything that could be used for the unique id of the user who initiated the request. AuditEvent resource has the attributes that would allow us to solve that use case, but I didn't see any reference that it could be submitted as a http header like Provenance has noted. Can AuditEvent be submitted as a custom header? As I read the documentation Provenance is only to be used for PUT or POST or is it acceptable to use Provenance for my use case?
Lloyd McKenzie (Sep 13 2019 at 22:58):
The user who intitiated is typically conveyed as part of the OAuth token
John Moehrke (Sep 14 2019 at 18:23):
as LLoyd says, the user is identified using security layers... But the client can record an AuditEvent. Best to record it in an independent POST so it can represent the success/failure of the other request.
Mona O (Sep 18 2019 at 13:26):
Thank you. Unfortunately, this is a B2B integration, so the user initiating the action where the application/process that would call the API is not available in the OAuth token. Any additional thoughts?
John Moehrke (Sep 19 2019 at 21:05):
client records AuditEvent that has the user identity... server should still record the auditEvent without it.
Last updated: Apr 12 2022 at 19:14 UTC
