Given the sensitive nature of healthcare data, logging, monitoring system events, and tracking user actions are critical to ensuring compliance with privacy regulations and security requirements. There are multiple ways of implementing comprehensive logging in healthcare systems, from third-party tools to cloud-native solutions. However, FHIR-based servers can also implement the support for the FHIR AuditEvent resource.
It was specifically created for recording detailed information about actions on stored health data. This includes read (get a resource by ID, search with some criteria, read for a specific version), write (or create a new one), modify (apply PUT or PATCH instruction), and delete actions, as well as user authentication attempts.
Our team has implemented the IHE logic according to the Basic Audit Log Profile (BALP) for audit events in our Kodjin FHIR server. This implementation aligns with the guidelines in the IHE Implementation Guide. Read our article about IHE Profiles and FHIR for more in-depth information.
Key Takeaways:
- The FHIR AuditEvent resource ensures comprehensive logging of healthcare data actions, supporting compliance with privacy regulations and security requirements.
- The FHIR AuditEvent resource aligns with IHE Basic Audit Log Profile (BALP) guidelines and provides standardized action recording to meet ONC Certification criteria.
- The FHIR AuditEvent resource, when integrated with tools like Elasticsearch, Prometheus, and Grafana, facilitates efficient log storage, advanced monitoring, and real-time alerts for robust security and quick audit event analysis.
What is FHIR’s AuditEvent resource?
The FHIR AuditEvent resource records detailed information about actions within healthcare systems, especially those related to healthcare data viewing, creation, modification, and deletion. It’s based on standards and definitions from several bodies, including IHE-ATNA, DICOM, ASTM, and ISO, ensuring broad acceptance and applicability in healthcare IT.
This resource is instrumental in supporting the requirements for auditing activities in healthcare applications, facilitating the detection of unauthorized access, and enabling monitoring events for security analysis and compliance auditing.
Below is a FHIR AuditEvent general example in JSON format:
{
"resourceType" : "AuditEvent",
"id" : "example",
"text" : {
"status" : "generated",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">Application Start for under service login "Grahame" (id: Grahame's Test HL7Connect)</div>"
},
"type" : {
"coding" : [{
"system" : "http://dicom.nema.org/resources/ontology/DCM",
"code" : "110100",
"display" : "Application Activity"
}]
},
"subtype" : [{
"coding" : [{
"system" : "http://dicom.nema.org/resources/ontology/DCM",
"code" : "110120",
"display" : "Application Start"
}]
}],
"action" : "E",
"recorded" : "2012-10-25T22:04:27+11:00",
"outcome" : {
"code" : {
"system" : "http://terminology.hl7.org/CodeSystem/audit-event-outcome",
"code" : "0",
"display" : "Success"
}
},
"agent" : [{
"role" : [{
"text" : "Service User (Logon)"
}],
"who" : {
"identifier" : {
"value" : "Grahame"
}
},
"requestor" : false
},
{
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/auditevent-AlternativeUserID",
"valueIdentifier" : {
"type" : {
"text" : "process ID"
},
"value" : "6580"
}
}],
"who" : {
"identifier" : {
"system" : "urn:oid:2.16.840.1.113883.4.2",
"value" : "2.16.840.1.113883.4.2"
}
},
"requestor" : false,
"networkString" : "Workstation1.ehr.familyclinic.com"
}],
"source" : {
"observer" : {
"display" : "Grahame's Laptop"
},
"type" : [{
"coding" : [{
"system" : "http://dicom.nema.org/resources/ontology/DCM",
"code" : "110122",
"display" : "Login"
}]
}]
},
"entity" : [{
"what" : {
"identifier" : {
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "SNO"
}],
"text" : "Dell Serial Number"
},
"value" : "ABCDEF"
}
},
"role" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/object-role",
"code" : "4",
"display" : "Domain Resource"
}]
}
}]
}
The AuditEvent resource aligns with the requirements of the Office of the National Coordinator for Health Information Technology (ONC) Certification. A key area of focus in the ONC Certification criteria is the ability of health IT to record and audit health information-related actions to ensure patient data security and privacy.
Thus, creating the AuditEvent by an FHIR client ensures all relevant actions are recorded in a standardized manner, supporting compliance with ONC Certification criteria.
This includes the implementation of features that support the audit log content, format, and functionality as outlined in the certification criteria. While the certification does not mandate using the FHIR AuditEvent resource specifically, the functionality is directly relevant to meeting these certification requirements.
AuditEvent Capabilities
| Feature | Description |
| Comprehensive Event Logging | It can record various events, from system start-ups and shutdowns, user logins and logouts, to data access and changes, ensuring a wide coverage of security and operational activities. |
| Multi-Actor Recording | AuditEvent supports logging from multiple actors (applications, processes, services) within a workflow. This may result in duplicate logs; however, this multiplicity can help identify discrepancies or security issues from different angles. |
| Rich Event Details | AuditEvent captures detailed information about an event, including who initiated it, what exactly happened, where it occurred, when it took place, and why. This detail aids in thorough analysis and auditing. |
| Security and Privacy | Events related to security and privacy, such as access control decisions and policy rule changes, are explicitly recorded. This is crucial for compliance with privacy laws and regulations. |
| Categorization | Utilizes an extensive set of codes for event categorization, action types, outcomes, etc., making it easier to classify and analyze events for specific scenarios. |
| Patient Control of Data Access | Primarily intended for security administrators and IT personnel, it helps manage and analyze audit logs. However, it can also inform patients about how their data is being used, respecting privacy concerns. |
Provenance vs. AuditEvent FHIR resources: What’s the difference?
The Provenance and AuditEvent resources capture information about actions taken on data within a healthcare system, but they serve different purposes and contain various types of information.
Provenance Resource
The Provenance resource records and manages metadata about the history of a resource. It provides detailed information on the origin, activity, and changes to a FHIR resource. This includes who made changes, when the changes were made, and what changes were made. The Provenance resource is crucial for ensuring data integrity and security and for supporting the necessary activity audits for compliance with regulations.
In the Kodjin FHIR Server, Provenance resources are generated by the client application, initiating actions such as resource creation or updates. Meanwhile, AuditEvent resources, which contain information that may overlap with Provenance resources, are generated in real-time to track and audit activities. Typically, AuditEvent resources are created by the application in response to various events like reads, queries, creations, updates, etc. In this scenario, the Kodjin FHIR Server creates AuditEvent resources.
Key aspects of Provenance include:
- Who performed the action (e.g., a practitioner, an organization).
- When the action occurred.
- What the action was (e.g., create, update, delete).
- The source of the information.
- The target of the action (the specific resource or resources affected).
AuditEvent Resource
The AuditEvent resource, on the other hand, is focused on recording system-level security events and interactions as they occur. It logs entries for security monitoring, compliance, and operational transparency. AuditEvent captures details about successful and failed access or actions performed within the system. Audit event actions for restful operations include read, update, delete, or create.
Key aspects of AuditEvent include:
- Who accessed the system or data (this can include system users, software, or other entities).
- What type of action was performed (e.g., read, write, delete).
- When the action took place.
- Outcome of the action (success, failure, etc.).
- The object that was accessed or changed.
Key Differences
- Purpose: Provenance is more focused on the history and changes of the FHIR resources themselves, providing a detailed record of who did what and when to a resource. AuditEvent, however, affects security and access logging, tracking successful and unsuccessful access attempts and actions within the system.
- Scope: Provenance is more granular, tracking the lineage and modifications to individual resources. AuditEvent captures broader system interactions and security-relevant events.
- Usage: Provenance is often used in clinical scenarios to maintain the integrity and trustworthiness of health information. AuditEvent is used for security audits, compliance, and operational monitoring.
AuditEvent often works alongside the Provenance resource, which tracks the history and origin of data, offering a comprehensive audit mechanism for healthcare data management.
Ensure regulation compliance and keep your data secure with Kodjin
The AuditEvent FHIR resource can be a useful tool for healthcare IT systems, ensuring data integrity, security, and compliance with privacy regulations. Kodjin FHIR Server‘s support for AuditEvent offers healthcare organizations a reliable and efficient way to manage audit logs and comply with regulatory standards.
We take our security and data privacy seriously. For logging and monitoring, Kodjin also utilizes Elasticsearch for efficient log storage and search capabilities, facilitating quick retrieval of audit events and analysis of system behavior. Advanced monitoring with Prometheus and Grafana provides deep insights into system performance and security metrics, enabling real-time alerts and detailed reporting to identify and mitigate potential security threats.
The integration of these technologies into Kodjin’s ecosystem highlights our commitment to robust security mechanisms, ensuring healthcare organizations can trust their compliance and data protection capabilities.
