Auditing of Special Events

[ndegwamartin]

We need to implement an Audit trail for special actions performed by the practitioners (and other users) on the android client

• Move to catchment
• Editing of resources/tasks/action
• Any changes by Supervisor for data synced to their device via P2P

Resources

• https://www.hl7.org/fhir/auditevent.html
• http://hl7.org/fhir/R4B/provenance.html

[pld]

Good call, this feels like something to control with a feature flag as we work on it. I wonder if we could implement this with the decorator pattern, maybe using annotations

[ekigamba]

If we assumed that the user interacting with the FHIR server API automatically made the change on the frontend device, would we be able to handle this audit logging under this issue https://github.com/onaio/opensrp-tasks/issues/107 ?

Maybe review the issue and the scope to make sure it serves this purpose also

[pld]

One exception to that assumption is when we use p2p sync to transfer data from healthcare devices to a manager device and only the manager device syncs w/the remote server

[ekigamba]

Nice catch 🤔

[ekigamba]

p2p sync generally introduces a number of edge cases. Currently, we add the practitioner-id in the meta for new resources. This could help resolve this at the API level but the fact that this resource can be edited again on the manager device without the practitioner-id being added means we might have to handle this audit at the front-end device

[ndegwamartin]

We can implement the normal interactions using the BALP interceptors @ekigamba mentioned on the conversation here as they follow a logging FHIR IG as documented here.

Then for any special events we can create custom Audit Events on the device using the AuditEvent resource.

[ndegwamartin]

However for the P2P case above it appears the most appropriate FHIR resource to use would be the Provenance one @roywanyaga mentioned.

There seems to be a clear distinction in its application vs the AuditEvent resource where the former is generated by the creating entity of the data (device) while the latter by the responding entity which is the server in this case.

[dubdabasoduba]

@aurangzaibumer raised an interesting item we could log.

• The number of resources affected by the fhircore migration scripts. e.g. Migration version 1.0.0 ran and affected 20 Tasks.

[pld]

Cool, even logging the UUIDs seems reasonable