PlanDefinition — Orchestration d'actions cliniques

Le squelette d'un protocole, d'un parcours de soin ou d'un order set. Combine ActivityDefinition, règles ECA (Event-Condition-Action) et bibliothèques CQL pour générer dynamiquement un CarePlan ou un RequestOrchestration.

Objet de la ressource

PlanDefinition représente un modèle d'actions ordonnées — protocole, order set, parcours, règle ECA. Le scope est plus large qu'ActivityDefinition : un PlanDefinition peut déclencher d'autres PlanDefinition imbriquées, instancier plusieurs ActivityDefinition en parallèle, et porter des règles conditionnelles.

Les cas d'usage typiques :

• Order set — paquet d'ordres médicaux pour une situation donnée (admission ICU, suspicion AVC).
• Protocole clinique — séquence d'évaluations et de traitements à appliquer.
• Règle CDS — déclencheur (Observation, MedicationRequest) + condition (CQL) + actions.
• Parcours de soin — itinéraire structuré pour une pathologie (diabète, insuffisance cardiaque).

Champs clés

Modèle d'action

Le champ action est récursif et porte la logique d'orchestration :

• trigger — quand déclencher (TriggerDefinition : événement nommé, condition de données, scheduling).
• condition — précondition CQL/FHIRPath (applicability, start, stop).
• input / output — données requises et produites.
• relatedAction — dépendance avec une autre action (before, after, concurrent).
• selectionBehavior — any | all | all-or-none | exactly-one | at-most-one | one-or-more.
• requiredBehavior — must | could | must-unless-documented.
• cardinalityBehavior — single | multiple.
• definitionCanonical — pointe vers ActivityDefinition, Questionnaire, autre PlanDefinition.
• action imbriquée — pour les sous-protocoles.

Exemple JSON

{
  "resourceType": "PlanDefinition",
  "id": "low-suicide-risk-order-set",
  "url": "http://example.org/PlanDefinition/low-suicide-risk-order-set",
  "version": "5.0.0",
  "name": "LowSuicideRiskOrderSet",
  "title": "Low Suicide Risk Order Set",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/plan-definition-type",
      "code": "order-set",
      "display": "Order Set"
    }]
  },
  "status": "active",
  "experimental": true,
  "date": "2026-05-15",
  "publisher": "HL7 International (Clinical Decision Support WG)",
  "action": [{
    "title": "Suicide Risk Assessment",
    "definitionCanonical": "http://example.org/ActivityDefinition/suicide-risk-assessment"
  }]
}

Opération $apply

L'opération $apply matérialise un PlanDefinition pour un sujet et un contexte :

• POST /PlanDefinition/{id}/$apply avec subject, encounter, practitioner, organization.
• Le serveur évalue les trigger, condition et dynamicValue.
• Il retourne un CarePlan ou un RequestOrchestration agrégeant les ressources concrètes (MedicationRequest, ServiceRequest, Task…).

Pièges courants

• Actions sans title — l'utilisateur clinique ne sait pas quoi cocher dans l'order set.
• CQL non versionnée — la library doit pointer une version précise pour la reproductibilité.
• RelatedAction circulaire — l'évaluation du plan boucle.
• SelectionBehavior absent sur un groupe — comportement par défaut any, rarement ce que l'on souhaite.

Ressources liées

• ActivityDefinition — actions atomiques composées.
• Library — logique CQL référencée.
• RequestOrchestration — résultat de $apply.
• CarePlan — plan de soin instancié.
• Hub FHIR R5.