Changelog SGRDV — release 1.2.0

Date de publication : 17 juin 2026

Légende : 🔴 = rupture sur contrat de production (experimental = false) · 🟠 = rupture sur contrat en validation (experimental = true) · 🟢 = ajout rétrocompatible

1. Versionnement et statut

1.1 Publication de la version 1.2.0 🟠

Cette release applique un bump MINEUR portant deux changements :

• §2 — $find : nouveau paramètre obligatoire appointment-status permettant de distinguer une recherche de disponibilités (proposed) d'une consultation de rendez-vous existants (booked). Rupture sur les clients qui ne fournissent pas ce paramètre. 🟠
• §3 — $cancel : nouvel endpoint d'annulation de rendez-vous sur les deux surfaces (api-sgrdv et api-source). Ajout rétrocompatible. 🟢

Le bump MINEUR est déclenché par §3 (nouvel endpoint) conformément à la politique de versionnement SGRDV. La rupture §2 est sur des artefacts experimental = true.

Tous les artefacts versionnés sont alignés sur la version 1.2.0 via la configuration du paquet IG.

2. $find — Mode liste de rendez-vous : appointment-status obligatoire 🟠

S'applique au profil partagé SGRDVBaseFindPayloadParameters (et donc aux deux profils surface-spécifiques SGRDVFindRequestParameters et SGRDVSourceFindRequestParameters qui en héritent).

2.1 Nouveau paramètre obligatoire appointment-status 🟠

Le paramètre appointment-status pilote le mode de la recherche :

• proposed — comportement inchangé : recherche de créneaux disponibles dans une fenêtre start/end.
• booked — nouveau mode : liste de rendez-vous réservés associés au patient. end et appointmentType sont optionnels dans ce mode (règles métier documentaires, non contraintes par invariant FHIR).

2.2 Paramètres rendus optionnels 🟢

Ces assouplissements sont rétrocompatibles : les payloads précédents fournissant end et appointmentType restent conformes en 1.2.0.

2.3 SGRDVBaseFindPatient — admisGap rendu optionnel 🟢

L'extension admisGap n'est pas pertinente dans le mode booked. Le portail peut l'omettre lorsque appointment-status = booked.

2.4 Nouveau ValueSet SGRDVFindAppointmentStatusVS 🟢

Binding required sur parameter[appointmentStatus].valueCode.

2.5 Nouvelle extension SGRDVAppointmentCancellableExtension sur Appointment 🟢

2.6 Nouveaux codes d'erreur 🟢

2.7 Nouvelles instances d'exemple — mode booked 🟢

2.8 Artefacts mis à jour

3. $cancel — Nouvel endpoint d'annulation de rendez-vous 🟢

Nouvel endpoint POST [base]/Appointment/$cancel disponible sur les deux surfaces.

3.1 Comportement fonctionnel

Le portail transmet la disponibilité à annuler en logical reference (IdDispoDME), une raison d'annulation optionnelle (texte libre) et la Provenance multi-agents (identique à $book). SGRDV identifie le DMÉ responsable et relaie la demande via la surface source. La réponse indique si l'annulation a été effectuée (cancellationCompleted = true) ou refusée (cancellationCompleted = false) avec des OperationOutcome explicatifs.

3.2 Profils de requête / réponse

3.3 Opérations

3.4 Nouveaux codes d'erreur 🟢

3.5 Nouvelles instances d'exemple 🟢

4. Recommandations de migration pour les partenaires

Si vous intégrez $find (api-sgrdv ou api-source)

1. Ajoutez appointment-status à toutes vos requêtes $find — ce paramètre est désormais obligatoire. Utilisez proposed pour conserver le comportement précédent (recherche de disponibilités).
2. Si vous utilisez le mode booked : end et appointmentType sont optionnels. Exploitez extension[cancellable] sur l'Appointment retourné pour déterminer si le RV peut être annulé avant d'offrir l'option d'annulation.
3. Traitez les nouveaux codes d'erreur MSG_PATIENT_NOT_FOUND et MSG_AUCUN_RV dans votre gestion des OperationOutcome.

Si vous intégrez $cancel (api-sgrdv)

1. Implémentez POST [base]/Appointment/$cancel avec le profil SGRDVCancelRequestParameters : appointment (logical ref IdDispoDME) en 1..1, provenance en 1..1, cancellationReason optionnel.
2. Gérez les trois codes de refus : MSG_RV_INEXISTANT, MSG_RV_NOTBOOKED, MSG_DELAI_INSUFFISANT — présentez un message explicite à l'utilisateur dans chaque cas.
3. Vérifiez la présence de extension[cancellable] sur les Appointment retournés par $find (mode booked) avant d'offrir l'option d'annulation.

Si vous intégrez $cancel (api-source — DMÉ/SIP-C)

1. Exposez POST [base]/Appointment/$cancel conforme au profil SGRDVSourceCancelNotificationParameters.
2. Retournez SGRDVSourceCancelResponseParameters avec cancellationCompleted = true en cas de succès, ou cancellationCompleted = false + au moins un OperationOutcome en cas de refus.
3. Gérez les règles métier de délai minimum avant annulation et retournez MSG_DELAI_INSUFFISANT si applicable.

Toutes intégrations confondues

1. Mettez à jour vos références au paquet SUSHI (version: 1.2.0).
2. Revalidez vos jeux de tests $find : les requêtes sans appointment-status ne sont plus conformes.
3. Intégrez les nouveaux codes d'erreur SGRDV dans votre mapping de messages utilisateur.