The Audit Log Patterns defined rely on the ATNA Profile for transport of the AuditEvent and query/retrieval of AuditEvents previously recorded. The patterns defined may be used as they are, or further refined to specific use-cases. Where a more specific audit event is defined, it should be derived off of these basic patterns. Thus, a more specific AuditEvent would be compliant with one or more of the AuditEvent patterns defined here.
This Implementation Guide is intended to be fully compliant with the HL7 FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with ATNA and other IHE Profiles.
RESTful ATNA Supplement. Where ANY Secure Client and ANY Secure Server are involved in some communication that is an auditable event described in this Implementation Guide and for which some AuditEvent pattern is defined. The AuditEvent patterns defined here will be created and recorded [ITI-20] by the Secure Node or Secure Application that is grouped within the diagramed ANY Secure Client and the ANY Secure Server.
The double recording enables forensic analysis to detect failures better. Both audit events recorded will be different as the AuditEvent.source would identify the actor recording the event. Some actors will be able to populate the AuditEvent pattern given more fully, the lack of an element being populated is not a defect, but rather indicates that the actor did not have access to that data.
The following AuditEvent patterns are defined:
- RESTful activities (Create, Read, Update, Delete, Search)
- SAML Security Token
- OAuth Security Token
- Consent Authorized Decision Audit Message
- Privacy Disclosure Audit Message
Implemented in FHIR Servers
- HAPI FHIR Server - https://hapifhir.io/hapi-fhir/docs/security/balp_interceptor.html
- Firely FHIR Server - https://docs.fire.ly/projects/Firely-Server/en/latest/security/auditing.html
- Aidbox FHIR Repository - https://docs.aidbox.app/modules-1/logging-and-audit/audit-logging