ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

AuditEvent — Regulatory traceability

Who read what, when, from where, with what outcome? AuditEvent answers, aligned with DICOM ATNA and IHE BPPC. The cornerstone of HIPAA and GDPR traceability on a FHIR server.

Purpose

AuditEvent logs security-relevant events of the FHIR system: read access, write, delete, authentication failure, bulk export. The structure is derived from DICOM ATNA audit, aligned with NIST 800-92 and IHE BPPC.

Three typical actors:

  • agent: the user or system that acts.
  • source: the system that records the event.
  • entity: the object (resource) on which the action operated.

Key fields

FieldTypeCardinalityRole
categoryCodeableConcept[]0..*Event category (REST, login, network...).
codeCodeableConcept1..1Mandatory. Precise event type.
actioncode0..1C, R, U, D, E (Create, Read, Update, Delete, Execute).
severitycode0..1emergency to debug (RFC 5424).
occurred[x]Period | dateTime0..1When the event happened.
recordedinstant1..1Mandatory. When the audit was recorded.
outcomeBackboneElement0..1Outcome (success, failure, partial).
outcome.codeCoding1..10=Success, 4=Minor failure, 8=Serious failure, 12=Major failure.
authorizationCodeableConcept[]0..*Legal basis (GDPR Article 6).
patientReference(Patient)0..1Patient concerned — frequent in healthcare.
encounterReference(Encounter)0..1Encounter during which the event occurred.
agentBackboneElement[]1..*Mandatory. Actor(s).
agent.whoReference1..1Actor identity.
agent.requestorboolean0..1Did this agent initiate the action?
agent.networkBackboneElement0..1IP, hostname, URI.
sourceBackboneElement1..1Mandatory. Audit source.
entityBackboneElement[]0..*Action target.
entity.whatReference0..1Concerned resource.
entity.roleCodeableConcept0..1Role (Patient, Job, Master file...).

JSON example

Successful read of a Patient by Dr Jones from IP 10.0.1.42:

json auditevent-read-patient.json
{
  "resourceType": "AuditEvent",
  "id": "example",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
      "code": "rest",
      "display": "RESTful Operation"
    }]
  }],
  "code": {
    "coding": [{
      "system": "http://hl7.org/fhir/restful-interaction",
      "code": "read",
      "display": "read"
    }]
  },
  "action": "R",
  "severity": "informational",
  "occurredDateTime": "2026-05-14T10:25:30+02:00",
  "recorded": "2026-05-14T10:25:30.123Z",
  "outcome": {
    "code": {
      "system": "http://terminology.hl7.org/CodeSystem/audit-event-outcome",
      "code": "0",
      "display": "Success"
    }
  },
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "humanuser",
        "display": "human user"
      }]
    },
    "who": { "reference": "Practitioner/dr-jones" },
    "requestor": true,
    "network": { "address": "10.0.1.42", "type": "2" }
  }, {
    "type": {
      "coding": [{
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "110150",
        "display": "Application"
      }]
    },
    "who": { "display": "Acme FHIR Server 4.5" },
    "requestor": false
  }],
  "source": {
    "site": { "display": "Hospital 1" },
    "observer": { "reference": "Device/fhir-server" }
  },
  "entity": [{
    "what": { "reference": "Patient/example" },
    "role": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/object-role",
        "code": "1",
        "display": "Patient"
      }]
    }
  }]
}

Common pitfalls

  • No agent.requestor — an event MUST have at least one agent with requestor=true (otherwise origin is ambiguous).
  • Auditing the audit — avoid logging AuditEvents about reading AuditEvents themselves: exponential loop.
  • PHI in entity.detail — don't inline patient data in cleartext in the audit: the audit would become an informal copy of the record.
  • No network info — without IP, forensic investigation is crippled.
  • Outcome success for a 403 — access denied is a success of the security control but a functional failure. Mark outcome.code=4.
  • Provenance — who created/modified a resource (vs AuditEvent = who accessed).
  • Consent — legal basis, may be referenced by authorization.
  • CapabilityStatement — declares server audit capabilities.