Adding support for AuditEvents

FHIR Info Gateway
,
1

Hi everyone,

We’re excited to share an update on the development of the FHIR Info Gateway.

We are currently working on integrating auditing as an out of the box feature. This will allow users to collect AuditEvent resources when health data resources are accessed or modified via the Gateway, whether its searching/reading, creation, deletion, updates and even access denied type events.

Our target is to implement minimal audit events inline with the Basic Audit Log Patterns (BALP) IG content profile which defines some basic and reusable AuditEvent patterns.

The goal is to make audit creation a built-in part of the system, ensuring that compliance and security requirements are addressed natively.

If you’re interested in contributing or giving feedback early, feel free to check out our GitHub repo here - https://github.com/google/fhir-gateway. We are particularly interested in receiving your suggestions regarding the specific details and default configurations we should include.

Thank you for joining this journey. Let’s collaborate to build something great!

Stay healthy,

Martin

Software Engineer, OHS FHIR Info Gateway

4 Likes
2

Today on the OHS Developers Call we discussed the ongoing work on the Audit feature Add support for AuditEvents · Issue #276 · google/fhir-gateway · GitHub and some of the design decisions.

Here’s a brief overview:

  1. The only configurable item coming from the plugin is the AuditEvent.agent.who part that refers to executor of the audit event action

  2. We need to address the Bundle processing concern of code duplication by refactoring and reusing parsing code in both PatientFinder and AuditEvent creator.

  3. For search type queries, we only capture the search query itself rather than the returned results as documented in the minimal AuditEvent BALP IG pattern here - 1:52 Basic Audit Log Patterns - Basic Audit Log Patterns (BALP) v1.1.3

  4. AuditEvent resources will be created during the post-processing part of core. That way we have access to both the request and the response which helps in capturing the complete information for all operation types that we need to create the AuditEvent e.g. POST request doesn’t have a server id assigned yet

For those who joined and those who have provided feedback so far, thank you! Your insights are already shaping the direction of this feature.

If you you’d like to provide feedback and/or collaborate on ideas feel free to leave a comment here Audit Event support on Gateway or leave a chat message on Discourse.

Looking forward to building more, together.

2 Likes