Schedule — Le calendrier d'un acteur de soin

Le conteneur de disponibilité. Un Schedule décrit l'horizon de réservation d'un praticien, d'une salle ou d'un équipement, sans porter directement la donnée des Appointment : il agit comme l'enveloppe des Slot.

Objet de la ressource

La ressource Schedule est un conteneur d'intervalles de temps pouvant être réservés pour des Appointment. Elle établit la fenêtre dans laquelle un acteur (praticien, lieu, device, équipe) accepte d'être réservé, tout en restant cleanement séparée des Appointment eux-mêmes — c'est ce qui permet d'exposer les disponibilités d'un médecin sans révéler l'identité des patients déjà inscrits.

Schedule n'est jamais autonome dans un workflow de prise de rendez-vous : il fonctionne en triptyque avec Slot (les créneaux unitaires qu'il contient) et Appointment (les réservations qui les consomment). C'est sur Schedule que portent les politiques de visibilité — l'app patient ne voit que les Schedule publics, le secrétariat voit tous les Schedule de la structure.

Champs clés

La StructureDefinition R5 énumère neuf éléments de premier niveau. Le résumé des champs structurants :

Exemple JSON

Calendrier du Dr Adam Careful pour la salle de consultation « South Wing, second floor », ouvert du 14 mai au 30 juin 2026, avec un commentaire éditorial pour le front office.

{
  "resourceType": "Schedule",
  "id": "example",
  "identifier": [{
    "use": "usual",
    "system": "http://example.org/scheduleid",
    "value": "45"
  }],
  "active": true,
  "serviceCategory": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/service-category",
      "code": "17",
      "display": "General Practice"
    }]
  }],
  "serviceType": [{
    "concept": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/service-type",
        "code": "57",
        "display": "Immunization"
      }]
    }
  }],
  "specialty": [{
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "408443003",
      "display": "General medical practice"
    }]
  }],
  "name": "Burgers UMC, South Wing, Second floor",
  "actor": [
    { "reference": "Practitioner/example" },
    { "reference": "Location/1", "display": "South Wing, second floor" }
  ],
  "planningHorizon": {
    "start": "2026-05-14T09:00:00+02:00",
    "end": "2026-06-30T17:00:00+02:00"
  },
  "comment": "Les blocs de matinée sont réservés aux nouveaux patients ; après-midi consacrés au suivi."
}

À noter dans cet exemple :

• actor liste deux références : le praticien et la location physique. Un même Schedule peut couvrir une combinaison ressource-humain + ressource-lieu.
• serviceCategory et serviceType permettent à l'app patient de filtrer : « disponibilités pour vaccination ».
• planningHorizon est borné. Au-delà du 30 juin, le secrétariat doit prolonger le Schedule ou créer un suivant.
• comment est en markdown — pratique pour les apps qui rendent le texte avec mise en forme.

Recherche des Slot associés

L'app cliente n'interroge typiquement pas /Schedule directement — elle parcourt les Schedule de l'organisation par actor ou serviceType, puis demande au serveur les Slot qui les peuplent :

• GET /Schedule?actor=Practitioner/example&active=true — récupère les Schedule actifs du praticien donné.
• GET /Slot?schedule=Schedule/example&status=free&start=ge2026-05-22 — récupère les créneaux libres rattachés.
• GET /Schedule?actor:Practitioner.specialty=394814009 — chaînage de recherche FHIR sur la spécialité du praticien acteur du calendrier.
• GET /Schedule?_include=Schedule:actor — inclusion directe des références actor.

Les profils US Core et Argonaut Scheduling exposent en complément l'opération $find sur la racine /Schedule/$find pour automatiser la découverte d'un créneau à partir de critères (spécialité, géographie, plage horaire).

Pièges courants

• Schedule sans actor — la cardinalité est 1..*. Un Schedule sans acteur est invalide et rejeté par le validateur.
• Slot hors planningHorizon — créer un Slot dont start sort de la fenêtre du Schedule parent est techniquement permis (pas d'invariant FHIR strict) mais sémantiquement faux — les apps de prise de rendez-vous l'ignoreront.
• Confusion Schedule / Appointment — Schedule n'est jamais le bon support pour porter des informations patient. Il décrit uniquement la disponibilité d'un acteur de soin. Les détails du rendez-vous sont dans l'Appointment.
• Schedule actif mais aucun Slot rattaché — du point de vue de l'app patient, le résultat est identique à un Schedule inactif. Veiller à publier au moins une plage de Slot dès qu'un Schedule passe en active=true.
• Plusieurs Schedule pour le même actor + même planningHorizon — autorisé techniquement, mais source de confusion. Préférer un Schedule unique qui couvre tout l'horizon et différencier les sous-plannings via serviceCategory.
• Identifier mutables — l'identifier métier ne doit pas changer entre deux versions du Schedule, sous peine de casser le rapprochement côté SIRH.

Ressources liées

• Slot — les créneaux unitaires que le Schedule contient et qui portent le statut free / busy.
• Appointment — la réservation qui consomme un ou plusieurs Slot du Schedule.
• Practitioner, PractitionerRole, Location, Device — les acteurs typiques dont le Schedule décrit la disponibilité.
• HealthcareService — le service de soin abstrait que les Schedule peuvent référencer comme acteur.

Voir aussi : l'index FHIR R5.