Changelog SGRDV — semaine du 4 mai 2026

Période couverte : 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 Promotion 0.1.0 → 1.0.1 et statut #active 🟢

Tous les artefacts publiés (Profile, Extension, ValueSet, CodeSystem, OperationDefinition, CapabilityStatement) passent désormais au statut #active (au lieu de #draft) et sont alignés sur la version 1.0.1 (au lieu de 0.1.0). L'attribut experimental = true est conservé sur tous les artefacts tant que la phase de validation se poursuit.

Le passage par 1.0.1 (plutôt que 1.0.0) reflète l'application immédiate de la nouvelle politique de versionnement (voir §1.2) au cumul des changements du jour : 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. 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).

Toutes intégrations confondues

1. Mettre à jour les références internes (validation, documentation, dépendances de paquet) à la version 1.0.1 et au statut #active des artefacts.
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.