Changelog SGRDV — release 1.0.2

Date de publication : 4 mai 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 Bump 1.0.0 → 1.0.2 🟢

Cette release applique un bump PATCH cumulant les changements de §2 et §3 depuis la version 1.0.0 publiée précédemment. Tous les artefacts versionnés (config IG, OperationDefinition, CapabilityStatement) sont alignés sur la version 1.0.2 ; les nouvelles opérations $extend-lock et $release-lock (voir §3.1) sont publiées au statut #draft alors que les autres artefacts demeurent au statut #active introduit en 1.0.0. L'attribut experimental = true est conservé sur tous les artefacts tant que la phase de validation se poursuit.

Le bump est conforme à la politique de versionnement (voir §1.2) : ruptures sur des artefacts experimental = true → bump PATCH.

1.2 Politique de versionnement formalisée 🟢

Une politique explicite de versionnement et de stabilité est désormais publiée. Elle précise :

• la sémantique des bumps MAJOR / MINOR / PATCH selon le type de changement ET le statut experimental de l'artefact concerné ;
• les engagements de stabilité de SGRDV pour les artefacts experimental = false (production) vs experimental = true (validation) ;
• la légende des changelogs partenaires (🔴 / 🟠 / 🟢).

À retenir : tant qu'un artefact est experimental = true, ses ruptures n'entraînent qu'un bump PATCH du paquet. Les partenaires en intégration anticipée doivent suivre activement les changelogs.

2. Opérations $find et $aggregate

S'applique aux deux surfaces (api-sgrdv et api-source), via le profil parent commun SGRDVBaseFindPayloadParameters.

2.1 Paramètres practitioner / clinic / gmf — logical references contraintes 🟠

Les paramètres de filtrage practitioner, clinic et gmf étaient typés Reference(...) mais aucune contrainte ne précisait la modalité d'identification — le payload Parameters n'embarque pas la ressource cible, donc une référence littérale ("PractitionerRole/abc") pointait dans le vide.

Le contrat est désormais explicite : ces trois paramètres sont des logical references (identifier-only).

⚠️ Action requise : remplacer toute Reference littérale (reference = "...") par une logical reference (identifier.system + identifier.value + identifier.type.coding) dans parameter[practitioner | clinic | gmf]. Le DMÉ résoudra le filtre par identifiant local (CodeProfessionnel / CodeEtablissement / GMF).

2.2 Patient.generalPractitioner — embarquement par contained 🟢

Le profil partagé SGRDVBaseFindPatient reçoit un slicing explicite de Patient.contained[], permettant d'embarquer le médecin de famille (PractitionerRole, Practitioner) et l'organisation/GMF du patient directement dans le payload Patient. Patient.generalPractitioner les référence alors via fragment #id.

Ce pattern résout la situation où Patient.generalPractitioner.reference pointait vers une instance externe absente du payload : le DMÉ peut désormais matérialiser le nom du médecin (name.family / name.given) sans appel externe.

Le PractitionerRole contained porte à la fois practitioner.identifier (sémantique métier — CodeProfessionnel) et practitioner.reference = "#<id>" (exigence FHIR dom-3 sur les ressources contained, pour qu'une ressource embarquée soit considérée référencée).

Slicing #open : les références externes restent permises pour les implémentations qui ne souhaitent pas embarquer. Aucune action requise pour les partenaires existants — pattern additif.

3. Opérations de verrou ($lock, $extend-lock, $release-lock)

S'applique aux deux surfaces (api-sgrdv et api-source).

3.1 Nouvelles opérations $extend-lock et $release-lock 🟢

Le cycle de vie du verrou est désormais complet : prolongation et retrait s'ajoutent à la pose initiale.

Les deux opérations sont publiées au statut #draft dans cette release ; leur structure de paramètres est stabilisée mais le contrat reste susceptible d'évoluer pendant la phase de validation. Les CapabilityStatement des deux surfaces sont enrichis en conséquence.

3.2 lockIdentifier — secret du portail appelant 🟢

Un nouveau slice parameter[lockIdentifier] (string 1..1) est introduit sur le profil parent commun SGRDVBaseLockPayloadParameters. Sa sémantique :

Règle de sécurité fondamentale : le lockIdentifier est un secret connu uniquement du portail appelant initial. SGRDV ne le propage jamais vers les systèmes source. Les notifications SGRDV → DMÉ portent uniquement l'appointment, le lockEndTime (le cas échéant) et la provenance.

3.3 Appointment.slot — logical reference contrainte 🟠

Sur le profil parent commun SGRDVBaseLockCandidateAppointment (utilisé en entrée par $lock, $extend-lock et $release-lock sur les deux surfaces), le champ slot était typé Reference(SGRDVBaseDmeSlot) mais le Slot n'est pas embarqué dans le payload de verrou — une référence littérale ("Slot/abc") pointait dans le vide.

Le contrat est désormais explicite : Appointment.slot est une logical reference (identifier-only).

⚠️ Action requise : remplacer toute référence littérale slot[i].reference = "Slot/..." par une logical reference (slot[i].identifier.system + slot[i].identifier.value + slot[i].identifier.type.coding = $sgrdv-ident-type#IdSlotDME).

Note : sur les réponses de $find (entrée entry[slot] du Bundle searchset), la ressource Slot reste matérialisée comme entry du Bundle ; la référence littérale slot[i].reference y demeure valide. Cette règle de logical reference s'applique uniquement aux opérations de verrou.

4. Recommandations de migration pour les partenaires

Si vous émettez parameter[practitioner | clinic | gmf] dans $find ou $aggregate

1. Remplacer valueReference.reference = "..." par un logical reference :
   • valueReference.identifier.system (NamingSystem applicable, p. ex. $ns-ramq)
   • valueReference.identifier.value (valeur métier — code professionnel, code établissement ou code GMF)
   • valueReference.identifier.type.coding = $sgrdv-ident-type#CodeProfessionnel · #CodeEtablissement · #GMF selon le paramètre concerné.

Si vous renseignez Patient.generalPractitioner dans $find ou $aggregate

1. Optionnel — matérialiser les ressources cibles dans Patient.contained[] avec un id local et faire pointer generalPractitioner.reference vers "#<id>". Recommandé si le destinataire (DMÉ/SIP-C) a besoin du nom du médecin (name.family / name.given) et n'a pas la connaissance interne du PractitionerRole / Practitioner référencé. Si la matérialisation est utilisée, le PractitionerRole doit renseigner à la fois practitioner.identifier et practitioner.reference = "#<id>" (contrainte FHIR dom-3).

Si vous appelez $lock, $extend-lock ou $release-lock

1. Sur Appointment.slot[i], remplacer toute reference = "Slot/..." par une logical reference (identifier.system + identifier.value + identifier.type.coding = $sgrdv-ident-type#IdSlotDME).
2. Pour $extend-lock / $release-lock (portail) : rejouer le lockIdentifier reçu en réponse du $lock initial dans parameter[lockIdentifier].valueString. Ce secret n'est pas transmis aux systèmes source.
3. Côté systèmes source (DMÉ/SIP-C) : ne jamais s'attendre à recevoir le lockIdentifier ; les notifications SGRDV portent uniquement l'appointment, le lockEndTime (le cas échéant) et la provenance.

Toutes intégrations confondues

1. Mettre à jour les références internes (validation, documentation, dépendances de paquet) à la version 1.0.2 des artefacts (les opérations $extend-lock et $release-lock sont publiées au statut #draft ; les autres artefacts demeurent au statut #active introduit en 1.0.0).
2. Prendre connaissance de la politique de versionnement et de stabilité publiée avec cette release : elle précise les règles de bump (MAJOR / MINOR / PATCH) selon le type de changement et le statut experimental de chaque artefact, ainsi que les engagements de stabilité de SGRDV.