Stream: Security and Privacy
Topic: AuditEvent for consent decision
John Moehrke (May 19 2021 at 12:33):
@Mohammad Jafari @Duane Decouteau I am looking at the AuditEvents from your server this week. And am noticing that the way you fill out the AuditEvent, it is very hard to do audit log analysis to uncover where a permit was denied. I might want to do this so that I could then follow up on why was it denied, was it a legitiamte successful security policy enforcement, or was it a case where policy is not currently aligned with desire (e.g. the patient should be asked if they would like to allow the interaction, such as is done with point-of-care-consent like workflows).
John Moehrke (May 19 2021 at 12:34):
The only distinction I can see is in the .outcomeDesc
"outcomeDesc": "CONSENT_DENY",
John Moehrke (May 19 2021 at 12:34):
unfortunately outcomeDesc is not a query parameter, and I don't think it is a good query parameter. i am not against adding it, but I don't think adding it is the right solution.
John Moehrke (May 19 2021 at 12:35):
I am wondering if there should be an added .entity in your AuditEvent that indicates permit vs deny. This entity could also carry any refrain or obligations that are residual on this decision.
Last updated: Apr 12 2022 at 19:14 UTC
