Changelog SGRDV — release 1.1.0

Date de publication : 30 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 Bump 1.0.6 → 1.1.0 🟠

Cette release correspond à la livraison de l'incrément 2 du guide d'implémentation SGRDV. Le bump MINOR est appliqué par décision éditoriale pour signaler l'amplitude des changements structurels cumulés sur plusieurs opérations : retrait d'un paramètre opérationnel ($book), resserrement d'un binding ($find), nouvelles cardinalités obligatoires ($lock / $extend-lock) et relâchement de cardinalité ($list-clinics).

Conformément à la politique de versionnement, tous les artefacts affectés portent experimental = true — les ruptures individuelles auraient justifié un bump PATCH. Le bump MINOR est une décision délibérée signalant un incrément de livraison majeur.

Résumé des changements :

• §2 — $lock / $extend-lock : valueDuration.system et valueDuration.code rendus obligatoires (1..1 MS). 🟠
• §3 — $find : binding encounterClass durci de extensible à required. 🟠
• §4 — $book : retrait de la slice parameter[organisationREO] du payload. 🟠
• §5 — $list-clinics : cardinalité entry[organization] relâchée de 1..* à 0..*. 🟢
• §6 — OperationOutcome : MUST SUPPORT ajouté sur issue.diagnostics ; instances corrigées pour utiliser SGRDVBaseOperationOutcome. 🟢
• §7 — Correctifs FSH : slicing simplifié sur identifier[ni] ($find) et property[tuilePortail] ($book).

Tous les artefacts versionnés (config IG, OperationDefinition, CapabilityStatement) sont alignés sur la version 1.1.0.

2. $lock / $extend-lock — Paramètre lock-requestedDuration 🟠

S'applique aux profils partagés SGRDVBaseLockPayloadParameters (opération $lock) et SGRDVBaseLockReferenceParameters (opérations $extend-lock et $release-lock).

2.1 Nouvelles cardinalités et flags MUST SUPPORT 🟠

Les sous-éléments system et code de la durée demandée sont désormais explicitement obligatoires et must-support. Les valeurs fixées restent inchangées (UCUM secondes).

2.2 Impact partenaires 🟠

• Portails (surface api-sgrdv) : doivent renseigner explicitement valueDuration.system et valueDuration.code dans toute demande $lock et $extend-lock. Un payload omettant ces sous-éléments n'est plus conforme au profil.
• SGRDV (propagation $process-message vers api-source) : le payload propagé doit inclure les trois sous-éléments de la durée.

⚠️ Action requise : Vérifier que les implémentations transmettent valueDuration.system = "http://unitsofmeasure.org" et valueDuration.code = #s en plus de valueDuration.value dans toutes les demandes de verrou.

2.3 Artefacts mis à jour

3. $find — Binding encounterClass durci 🟠

S'applique au profil partagé SGRDVBaseFindPayloadParameters (et donc aux deux surfaces qui en héritent).

3.1 Changement de binding 🟠

Avec un binding extensible, un système pouvait transmettre des codes hors ValueSet si aucun code applicable n'existait. Avec required, seuls les codes de SGRDVEncounterClassVS sont acceptés.

3.2 Impact partenaires 🟠

• Portails (surface api-sgrdv) : doivent utiliser exclusivement des codes appartenant à SGRDVEncounterClassVS pour le paramètre encounter-class. Tout code hors ValueSet est désormais invalide.

⚠️ Action requise : Vérifier la liste des codes encounterClass utilisés et confirmer leur appartenance à SGRDVEncounterClassVS.

3.3 Artefacts mis à jour

4. $book — Retrait de la slice organisationREO du payload 🟠

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

4.1 Contexte

La version 1.0.5 avait introduit le slice parameter[organisationREO] permettant de matérialiser l'organisation d'origine de la réorientation REO directement dans le payload $book. Cette approche est abandonnée : l'organisation REO est désormais uniquement portée en référence logique via Provenance.agent[professionnelREO].onBehalfOf — elle n'est jamais matérialisée dans le payload.

4.2 Changement de structure 🟠

4.3 Impact partenaires 🟠

• Portails (surface api-sgrdv) : ne doivent plus inclure parameter[organisationREO] dans le payload $book. L'organisation d'origine de la réorientation est identifiée uniquement par l'Identifier dans Provenance.agent[professionnelREO].onBehalfOf.
• SGRDV (propagation vers api-source) : le payload propagé ne contiendra plus parameter[organisationREO].

⚠️ Action requise : Retirer toute logique de construction ou de traitement de parameter[organisationREO] dans les implémentations $book. L'organisation REO est identifiée uniquement via Provenance.agent[professionnelREO].onBehalfOf.identifier.

4.4 Artefacts mis à jour

5. $list-clinics — Cardinalité entry[organization] relâchée 🟢

S'applique au profil SGRDVSourceListClinicsResponseBundle (surface api-source).

5.1 Changement de cardinalité 🟢

Un Bundle de réponse $list-clinics peut désormais ne contenir aucune entrée Organization. Ce cas correspond à une réponse valide lorsqu'aucune clinique ne correspond aux critères de filtrage du DMÉ.

5.2 Impact partenaires 🟢

• SGRDV (récepteur, surface api-source) : doit désormais gérer le cas d'un Bundle de réponse sans entrée Organization — une liste vide est une réponse valide.
• DMÉ / SIP-C (émetteur, surface api-source) : peut retourner un Bundle vide sans violer le profil.

5.3 Artefacts mis à jour

6. OperationOutcome — MUST SUPPORT sur issue.diagnostics 🟢

S'applique au profil partagé SGRDVBaseOperationOutcome (utilisé par toutes les opérations sur les deux surfaces).

6.1 Nouvel élément MUST SUPPORT 🟢

issue.diagnostics est destiné aux messages techniques (identifiants internes, contexte de débogage) à distinguer de issue.details.text qui porte le message lisible par un humain.

6.2 Correction des instances d'exemple

Trois instances d'exemple étaient typées InstanceOf: OperationOutcome (ressource FHIR de base) au lieu de InstanceOf: SGRDVBaseOperationOutcome (profil SGRDV). Cette erreur est corrigée.

6.3 Impact partenaires 🟢

Aucune rupture. Les émetteurs sont encouragés à renseigner issue.diagnostics pour améliorer la traçabilité technique des erreurs dans les logs de débogage.

6.4 Artefacts mis à jour

7. Correctifs FSH — Slicing simplifié (refactoring interne)

Correction de définitions FSH incorrectes sur deux profils. Le slicing via type.coding introduisait un comportement de validation non désiré ; la notation shorthand FSH = system#code est sémantiquement équivalente et correcte. Aucun impact sur les payloads valides.

7.1 SGRDVBaseFindPatient — Slice identifier[ni]

7.2 SGRDVBaseBookSourceDevice — Slice property[tuilePortail]

7.3 Artefacts mis à jour

8. Recommandations de migration pour les partenaires

Si vous intégrez $lock ou $extend-lock (les deux surfaces)

1. Vérifiez que les payloads transmettent valueDuration.system = "http://unitsofmeasure.org" et valueDuration.code = #s explicitement en plus de valueDuration.value.
2. Revalidez vos exemples et jeux de tests $lock / $extend-lock avec le profil 1.1.0.

Si vous intégrez $find (les deux surfaces)

1. Vérifiez que tous les codes encounterClass utilisés sont présents dans SGRDVEncounterClassVS.
2. Retirez toute logique d'envoi de codes hors ValueSet pour ce paramètre.

Si vous intégrez $book (les deux surfaces)

1. Retirez toute logique de construction ou de traitement de parameter[organisationREO].
2. L'organisation REO reste identifiable uniquement via Provenance.agent[professionnelREO].onBehalfOf.identifier.
3. Revalidez vos scénarios de réorientation REO avec un payload 1.1.0.

Si vous intégrez $list-clinics (surface api-source)

1. Assurez-vous que votre implémentation gère un Bundle de réponse sans entrée Organization (liste vide = réponse valide).

Toutes intégrations confondues

1. Revalidez vos payloads contre la version 1.1.0 du paquet IG.
2. Traitez les §2, §3 et §4 comme des ruptures sur contrats expérimentaux — des mises à jour sont requises avant la prochaine validation partenaire.