AppointmentResponse — Réponse à un RDV

Un acteur — patient, praticien, salle — répond à une proposition de rendez-vous. Acceptation, refus, contre-proposition : AppointmentResponse trace chaque RSVP.

Objet de la ressource

AppointmentResponse représente la réponse d'un participant à un Appointment proposé. Quand le système crée un rendez-vous avec plusieurs participants (médecin, patient, salle, dispositif), chacun peut répondre individuellement — une AppointmentResponse par acteur. Le statut global de l'Appointment dépend des réponses agrégées : booked seulement si tous les requis ont accepted.

Champs clés

Champ	Type	Cardinalité	Rôle
`identifier`	Identifier[]	0..*	Identifiants externes.
`appointment`	Reference(Appointment)	1..1	Obligatoire. RDV cible.
`proposedNewTime`	boolean	0..1	`true` = contre-proposition d'un autre créneau.
`start`	instant	0..1	Début proposé/accepté.
`end`	instant	0..1	Fin proposée/acceptée.
`participantType`	CodeableConcept[]	0..*	Rôle du participant.
`actor`	Reference(Patient \| Group \| Practitioner \| PractitionerRole \| RelatedPerson \| Device \| HealthcareService \| Location)	0..1	Participant répondant.
`participantStatus`	code	1..1	Obligatoire. `accepted`, `declined`, `tentative`, `needs-action`.
`comment`	string	0..1	Commentaire libre.
`recurring`	boolean	0..1	S'applique à toute la série.
`occurrenceDate`	date	0..1	Occurrence ciblée (si récurrent).
`recurrenceId`	positiveInt	0..1	ID d'occurrence dans la série.

Cycle de vie

Un Appointment est créé en proposed ou pending : le serveur génère une AppointmentResponse needs-action par participant requis. Chaque réponse modifie le statut du participant correspondant dans l'Appointment.participant[]. Quand tous les participants requis ont accepted, l'Appointment passe à booked.

Exemple JSON

Un patient confirme son RDV du 20 mai 2026 :

json appointmentresponse-patient.json

{
  "resourceType": "AppointmentResponse",
  "id": "ar-001",
  "identifier": [{ "system": "urn:oid:1.2.34", "value": "AR-2026-05-15-001" }],
  "appointment": { "reference": "Appointment/apt-2026-05-20-001" },
  "proposedNewTime": false,
  "start": "2026-05-20T10:00:00+02:00",
  "end": "2026-05-20T10:30:00+02:00",
  "participantType": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
      "code": "ATND",
      "display": "attender"
    }]
  }],
  "actor": { "reference": "Patient/doe-john" },
  "participantStatus": "accepted",
  "comment": "Confirmé, j'arriverai 10 minutes en avance",
  "recurring": false,
  "occurrenceDate": "2026-05-20"
}

Pièges courants

Pas de synchronisation Appointment.participant.status — créer une AppointmentResponse sans mettre à jour le statut côté Appointment laisse l'EHR confus.
Contre-proposition sans start/end — proposedNewTime=true doit s'accompagner d'un nouveau créneau, sinon il n'y a pas de proposition exploitable.
Réponse pour un acteur non listé — l'actor doit faire partie de l'Appointment.participant[].
Récurrence ambiguë — recurring=true sans occurrenceDate applique à toutes les occurrences : souvent involontaire.
Confondre avec Appointment.participant.status — la réponse formelle est une ressource ; le statut est dénormalisé pour la lecture rapide.

Ressources liées

Appointment — proposition cible.
Schedule / Slot — disponibilités sous-jacentes.
Patient, Practitioner — typiquement actor.

Fondamentaux

Standards

Messages phares

Outils