Logging Events with FHIR AuditEvent Resource

Explore the capabilities of the FHIR AuditEvent resource and its role in ensuring security, patient data privacy, and compliance with ONC regulations.

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. For a comprehensive understanding of integrating genomic data within the FHIR framework, refer to our FHIR genomics complete guide, which provides in-depth insights into this specialized area.

FHIR AuditEvent Structure

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 &quot;Grahame&quot; (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

FeatureDescription
Comprehensive Event LoggingIt 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 RecordingAuditEvent 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 DetailsAuditEvent 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 PrivacyEvents 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.
CategorizationUtilizes 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 AccessPrimarily 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.

Provenance Structure

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.

Post author

Andrii Krylov

Product Owner at Edenlab

More article about Blog about FHIR

Let`s chat

We would be glad to share more details about our enterprise-level FHIR software solutions and other cases based on the HL7 FHIR standard.

    Your form has been submitted successfully

    We will contact your shortly

    Kodjin White Paper

    Please leave your email to get Kodjin White Paper

      By downloading files from this site you agree to the Policy

      The Kodjin White Paper has been successfully sent to your email

      We have sent a copy to your email

      Back to website content