Stream: patient empowerment
Topic: What are my apps doing?
John Moehrke (Jun 12 2019 at 12:47):
With patients using Apps, there is an even stronger need for audit logging of API access. The patient can't be expected to know what their Apps are doing, they might have read the privacy policy but likely just trust.. However the AuditEvent resource offers us a way to see ALL the accesses to that patients data. Should be all authorized requests, but the audit log will also show those requests that were properly rejected, etc. Best if the AuditEvent log contains ALL accesses, not just the patient them-selves, including those accesses for Treatment, Payment, and directly accessed under operations. Yes, I think it is time to declare useless and dead the "Accounting of Disclosures", long live the "Access Log". https://healthcaresecprivacy.blogspot.com/2019/06/patient-engagement-access-log.html
John Moehrke (Jun 12 2019 at 14:55):
Provided a FHIR Server did record basic API access (CRUD.E), it would be very interesting to me to see an app that is dedicated to the AuditEvent log. It could be limited to Read on AuditEvent for that Patient (an interesting permission model), and it would be a challanging system function to determine acceptable patterns so that unusual patterns can become the focus (alarm, reporting, analysis).
Ryan Howells (Jun 12 2019 at 21:11):
In the CARIN Alliance, @John Moehrke we listed audit logs as a best practice in our Code of Conduct that we are having apps attest to. We agree.
Abbie Watson (Jun 12 2019 at 22:10):
Ooof. I don't entirely disagree; but... capacity planning? Do we store those records indefinitely? Or is there a best practice for caping the collection/table? 30d? 90d? 1yr? i.e. Servers MUST retain API audit logs for 90 days, but SHOULD retain for 1 year?
John Moehrke (Jun 13 2019 at 12:32):
Yes @Abigail Watson , one of the struggles with audit logs is indeed one must have a retention policy as otherwise the audit log will overwhelm the real data. This retention policy is usually something carefully crafted around that organization risk management policy. There are some security audit logs that will show up alot (For example positive authentication events) but their appearance is an indication that everything is working well. There might be an exceptional time (for example triggered by a privacy inspection), where the retention purging is forbidden. Of course a purge event is it-self an auditable event, so there would be a record of the trigger for the purge etc. This retention policy is not something that can be standardized.
Grahame Grieve (Jun 13 2019 at 21:44):
should be a commercial service storing app based audit trail
John Moehrke (Jun 14 2019 at 12:29):
yes that is one option I have outlined. This service could be feed using a subscription in the background.
John Moehrke (Jun 14 2019 at 12:32):
Hence why ATNA has this feed and subscription...
Last updated: Apr 12 2022 at 19:14 UTC
