Consent — Volontés et autorisations

Recherche, partage, traitement, opt-in/opt-out : tout ce que le patient autorise ou refuse, sous quelle juridiction, avec quelle granularité — codifié pour exécution machine.

Objet de la ressource

Consent encode les volontés du patient : à qui il donne accès à ses données, pour quel usage, pendant quelle période, sur quel sous-ensemble de données. R5 a réécrit Consent autour de decision (permit/deny) et d'une seule provision hiérarchique. Le Consent peut être : opt-in (autorise par défaut + provisions deny), opt-out (refuse par défaut + provisions permit), ou formulaire spécifique (research, advance-directive).

Champs clés

Provisions et logique deny/permit

R5 a simplifié : une seule decision globale (permit ou deny) et des provision[] qui restreignent ou élargissent. Chaque provision liste actor, action, securityLabel, purpose, class, code, dataPeriod, data — toute donnée matchant TOUS ces critères tombe sous la provision.

Exemple JSON

Consentement à la recherche, 5 ans, données 2020-2026, accès Org recherche X :

{
  "resourceType": "Consent",
  "id": "share-research-001",
  "status": "active",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentcategorycodes",
      "code": "research",
      "display": "Research Information Access"
    }]
  }],
  "subject": { "reference": "Patient/doe-john" },
  "date": "2026-05-15",
  "grantor": [{ "reference": "Patient/doe-john" }],
  "decision": "permit",
  "controller": [{ "reference": "Organization/hospital-1" }],
  "sourceAttachment": [{
    "url": "https://docs.hospital-1.example.org/consent/2026-05-15-001.pdf",
    "contentType": "application/pdf",
    "title": "Formulaire de consentement signé"
  }],
  "regulatoryBasis": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/consentpolicycodes",
      "code": "cric"
    }]
  }],
  "provision": {
    "period": {
      "start": "2026-05-15",
      "end": "2031-05-15"
    },
    "actor": [{
      "role": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
          "code": "PROV",
          "display": "healthcare provider"
        }]
      },
      "reference": { "reference": "Organization/research-center-x" }
    }],
    "action": [{
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/consentaction",
        "code": "access"
      }]
    }],
    "purpose": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "HRESCH",
      "display": "healthcare research"
    }],
    "dataPeriod": {
      "start": "2020-01-01",
      "end": "2026-05-15"
    }
  }
}

Pièges courants

• Confondre active et permit — status est le cycle de vie de la ressource, decision le sens (permit/deny).
• Pas de regulatoryBasis — sans base réglementaire (RGPD art. 9, HIPAA), le consentement est faible juridiquement.
• Provisions trop larges — un permit + provision action=access sans restriction de purpose est un open bar.
• Pas de sourceAttachment — sans le PDF signé, le Consent est juste une déclaration sans preuve.
• Migration depuis R4 — le modèle R4 (scope + provision.type) a été remplacé par decision + provision unifiée. Refactor non trivial.

Ressources liées

• Patient — sujet typique.
• Contract — usage juridique étendu.
• Provenance — traçabilité.
• AuditEvent — audit des accès.
• DocumentReference — formulaire signé.