ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

AuditEvent — détail : log d'audit FHIR

Log d'audit standard FHIR pour tracer les accès, lectures, exports et exceptions sur les ressources cliniques. Compatible RFC 3881 (IHE ATNA), DICOM Audit Trail. Pierre angulaire des conformités HIPAA Security Rule, RGPD article 30, certification HDS française.

Changements R4 → R5

R5 introduit des changements significatifs :

  • code au lieu de type + subtype (simplification).
  • occurredDateTime et recorded séparés (avant recorded couvrait les deux).
  • category est désormais une liste (multi-classification).
  • basedOn nouveau : lien vers le déclencheur (Request, Notification).
  • outcome structuré : code + detail (avant string libre).

Champs clés

ChampCardinalitéRôle
category0..*Classification haute (rest, application-activity, security-alert, user-access).
code1..1Action spécifique (read, create, update, delete, login, logout).
action0..1C (Create), R (Read), U (Update), D (Delete), E (Execute).
severity0..1informational / warning / error / critical (alignement syslog RFC 5424).
occurredDateTime0..1Quand l'action s'est passée.
recorded1..1Quand l'audit a été créé.
outcome0..1Success (0) / Minor failure (4) / Serious failure (8) / Major failure (12).
agent1..*Qui a fait l'action (humanuser, device, application).
source1..1Quel système a enregistré l'audit (collecteur).
entity0..*Quoi (ressources accédées) + leur classification de sécurité.

IHE ATNA et alignement RFC 3881

FHIR AuditEvent est l'expression FHIR du profil IHE ATNA (Audit Trail and Node Authentication), lui-même basé sur 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.

Les SIH français certifiés HDS doivent émettre des AuditEvent vers un collecteur ATNA en TLS mutuel sur port 6514 (RFC 5425).

Exemple : lecture dossier patient par médecin

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/maincare-portail-pro-v8.2" },
    "requestor": false
  }],
  "source": {
    "site": { "display": "Hopital Central 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"
    }]
  }]
}

Pièges courants

  • Volume écrasant — AuditEvent peut représenter 100x le volume des autres ressources. Stockage séparé obligatoire (cold storage, partitioning par date).
  • Pas d'agent requestor=true — au moins un agent doit être marqué comme initiateur. Sinon impossible d'imputer l'action.
  • networkString sensible — IP/MAC peuvent être PII selon le contexte. RGPD impose une analyse de la base légale du log.
  • Confusion avec Provenance — Provenance = qui a modifié quoi (métadonnée business). AuditEvent = qui a accédé / fait quoi (log technique). Voir page Provenance détail.

Ressources liées