ediverse

Type to search across standards, messages, tools and glossary.

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.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

AuditEvent — detail: FHIR audit log

Standard FHIR audit log to trace accesses, reads, exports, and exceptions on clinical resources. Compatible with RFC 3881 (IHE ATNA), DICOM Audit Trail. Cornerstone of HIPAA Security Rule, GDPR article 30, French HDS certification.

R4 → R5 changes

R5 introduces significant changes:

  • code instead of type + subtype (simplification).
  • occurredDateTime and recorded separated (before recorded covered both).
  • category is now a list (multi-classification).
  • basedOn new: link to trigger (Request, Notification).
  • outcome structured: code + detail (before free string).

Key fields

FieldCardinalityRole
category0..*High classification (rest, application-activity, security-alert, user-access).
code1..1Specific action (read, create, update, delete, login, logout).
action0..1C (Create), R (Read), U (Update), D (Delete), E (Execute).
severity0..1informational / warning / error / critical (syslog RFC 5424 alignment).
occurredDateTime0..1When the action happened.
recorded1..1When the audit was created.
outcome0..1Success (0) / Minor failure (4) / Serious failure (8) / Major failure (12).
agent1..*Who did the action (humanuser, device, application).
source1..1Which system logged the audit (collector).
entity0..*What (accessed resources) + security classification.

IHE ATNA and RFC 3881 alignment

FHIR AuditEvent is the FHIR expression of the IHE ATNA profile (Audit Trail and Node Authentication), itself based on RFC 3881 (Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications). Mapping:

  • FHIR code + action = ATNA EventID + EventActionCode.
  • FHIR agent = ATNA ActiveParticipant.
  • FHIR source = ATNA AuditSourceIdentification.
  • FHIR entity = ATNA ParticipantObjectIdentification.

HDS-certified French HIS must emit AuditEvent to an ATNA collector over mutual TLS on port 6514 (RFC 5425).

Example: patient record read by physician

json auditevent-read-patient.json 
{
  "resourceType": "AuditEvent",
  "id": "audit-read-patient-marie-887",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/audit-event-type",
      "code": "rest"
    }]
  }],
  "code": {
    "coding": [{
      "system": "http://hl7.org/fhir/restful-interaction",
      "code": "read",
      "display": "read"
    }]
  },
  "action": "R",
  "severity": "informational",
  "occurredDateTime": "2026-05-19T16:42:33+02:00",
  "recorded": "2026-05-19T16:42:33.812+02:00",
  "outcome": {
    "code": {
      "coding": [{
        "system": "http://hl7.org/fhir/audit-event-outcome",
        "code": "0",
        "display": "Success"
      }]
    }
  },
  "purposeOfEvent": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "TREAT"
    }]
  }],
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/extra-security-role-type",
        "code": "humanuser"
      }]
    },
    "who": {
      "reference": "Practitioner/dr-bernard-claude",
      "display": "Dr Claude BERNARD"
    },
    "requestor": true,
    "role": [{
      "coding": [{
        "system": "http://snomed.info/sct",
        "code": "112247003",
        "display": "Medical doctor"
      }]
    }],
    "networkString": "192.168.10.245"
  }, {
    "type": {
      "coding": [{
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "110153",
        "display": "Source Role ID"
      }]
    },
    "who": { "reference": "Device/ehr-pro-portal-v8.2" },
    "requestor": false
  }],
  "source": {
    "site": { "display": "Central Hospital Paris" },
    "observer": { "reference": "Device/audit-aggregator-001" },
    "type": [{
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/security-source-type",
        "code": "4",
        "display": "Application Server"
      }]
    }]
  },
  "entity": [{
    "what": { "reference": "Patient/marie-durand-887" },
    "role": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/object-role",
        "code": "1",
        "display": "Patient"
      }]
    },
    "securityLabel": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
      "code": "R",
      "display": "Restricted"
    }]
  }]
}

Common pitfalls

  • Overwhelming volume — AuditEvent can represent 100x the volume of other resources. Separate storage mandatory (cold storage, date partitioning).
  • No agent with requestor=true — at least one agent must be marked as initiator. Otherwise impossible to impute the action.
  • networkString sensitive — IP/MAC may be PII depending on context. GDPR requires analysis of the log's legal basis.
  • Confusion with Provenance — Provenance = who modified what (business metadata). AuditEvent = who accessed / did what (technical log). See Provenance detail.