Changelog SGRDV — release 1.1.2

Date de publication : 19 juillet 2026

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

1. Versionnement et statut

1.1 Bump 1.1.1 → 1.1.2

Cette release correspond à un bump PATCH. Tous les artefacts modifiés portent experimental = true. Les ruptures individuelles justifient le symbole 🟠 mais n'imposent qu'un bump PATCH conformément à la politique de versionnement.

Résumé des changements :

• §2 — $book commun : refonte de la représentation de la réorientation REO. La Provenance de la demande passe d'une structure multi-agents (portail + professionnel réorienteur en RelatedPerson) à un agent unique (le portail, un Device). Le nom du professionnel réorienteur est désormais porté par une extension dédiée. 🟠
• §3 — $book commun : le slicing d'identifiant et l'invariant de portail sur le Device source (introduits en 1.1.1) sont remplacés par une contrainte souple — au moins un identifiant dont le système émetteur est renseigné, sans figer la liste des portails. 🟢
• §4 — Device source commun : deviceName rendu optionnel sur le Device source de base. 🟢
• §5 — Audit : SGRDVAuditEvent.outcome rendu optionnel ; type.system rendu obligatoire ; alignement du Device acteur d'audit sur le Device source des autres surfaces (identifiant par system seul, prise en charge de la tuile de portail). 🟠 / 🟢
• §6 — $book surface source : correction d'une référence supportedProfile du CapabilityStatement laissée sur l'ancien canonical lors du renommage effectué en 1.1.1. 🟢

1.2 Version explicite sur tous les artefacts

Tous les artefacts définitionnels du guide portent désormais explicitement la version de la release : profils, extensions, ValueSet, CodeSystem, OperationDefinition et CapabilityStatement sont alignés sur 1.1.2. Les ressources NamingSystem ne portent pas de version — l'élément version n'existe pas sur cette ressource en FHIR R4.

2. $book — Refonte de la réorientation REO sur la Provenance 🟠

2.1 Provenance à agent unique 🟠

La Provenance de la demande $book modélisait la réorientation REO au moyen d'un second agent (professionnelREO) référençant un RelatedPerson contenu représentant la personne ayant effectué la réorientation. Cette modélisation est remplacée : la Provenance ne porte plus qu'un seul agent, le portail source (un Device). Le nom du professionnel réorienteur, lorsqu'il s'applique, est porté par une extension dédiée sur la Provenance (voir §2.3).

L'organisation d'origine de la réorientation (Clinique, Institution hospitalière ou CIUSS) reste portée par agent[portail].onBehalfOf en référence logique (identifiant seul, référence littérale interdite).

2.2 Suppression du profil RelatedPerson réorienteur 🟠

Le profil SGRDVBaseBookOrienteurRelatedPerson (Id sgrdv-base-book-orienteur-related-person) est supprimé. La personne réorientatrice n'est plus modélisée comme un RelatedPerson distinct.

2.3 Nouvelle extension Nom du professionnel REO 🟢

Une extension porte le nom du professionnel de santé ayant effectué la réorientation REO, directement sur la Provenance de la demande $book.

2.4 Cardinalité location.identifier.system 🟠

2.5 Artefacts mis à jour

⚠️ Action requise : Les implémentations qui produisaient une Provenance $book avec un agent professionnelREO (RelatedPerson contenu #orienteur) doivent migrer vers un agent unique portail et, le cas échéant, renseigner le nom du professionnel réorienteur dans l'extension sgrdv-provenance-nom-professionnel-reo.

3. $book — Identifiant de portail : passage à une contrainte souple 🟢

Le slicing d'identifiant (reo / votresante) et l'invariant sgrdv-book-device-portail-identifier ajoutés en 1.1.1 sur le Device source d'une demande $book — qui figeaient la liste des portails émetteurs et imposaient l'un des deux systèmes reconnus — sont remplacés par une contrainte souple. Le Device source doit porter au moins un identifiant dont le système émetteur (identifier.system) est renseigné, sans énumérer ni figer les portails : un nouveau portail s'identifie via son propre système sans modification de l'IG.

3.1 Artefacts mis à jour

Les instances d'exemple $book portent désormais l'identifiant de portail (système émetteur seul).

4. Device source commun — deviceName optionnel 🟢

Le Device source de base rendait deviceName obligatoire. Il devient optionnel : le système source est identifié par son identifier.system (URL de NamingSystem reconnue), le nom lisible n'étant plus exigé.

4.1 Artefacts mis à jour

5. Audit — Ajustements de contraintes 🟠 / 🟢

5.1 SGRDVAuditEvent 🟠 / 🟢

outcome devient optionnel : l'issue de la transaction n'est renseignée que lorsqu'elle est connue au moment de la journalisation.

5.2 Device acteur d'audit aligné sur les autres surfaces 🟢

Le Device acteur d'audit (SGRDVAuditAgent) reprend le contrat du Device source des autres surfaces : l'acteur est identifié par identifier.system seul, identifier.value restant facultative. La tuile de portail REO est prise en charge (via property[tuilePortail]) et n'est renseignée que lorsque la transaction auditée s'y prête ($book).

5.3 Artefacts mis à jour

Les instances d'exemple d'audit sont alignées (identifiant par system seul).

6. $book surface source — Correction du supportedProfile du CapabilityStatement 🟢

Le profil des paramètres d'entrée de l'opération $book sur la surface source a été renommé en 1.1.1 (SGRDVSourceBookNotificationParameters → SGRDVSourceBookRequestParameters, canonical …/sgrdv-source-book-notification-parameters → …/sgrdv-source-book-request-parameters). Le CapabilityStatement de la surface source continuait toutefois de référencer, dans sa liste supportedProfile, l'ancien canonical — qui n'est plus produit et ne résout donc plus. La référence est corrigée vers le canonical courant.

6.1 Artefacts mis à jour

⚠️ Action requise : Les implémentations qui résolvaient les profils listés dans le supportedProfile du CapabilityStatement source obtiennent désormais un canonical valide pour les paramètres d'entrée $book. Aucune action si vous référenciez déjà le profil par son canonical courant.

7. Recommandations de migration pour les partenaires

Si vous intégrez $book

1. Migrer la Provenance de la demande vers un agent unique portail (Device). Retirer l'agent professionnelREO et le RelatedPerson réorienteur contenu (#orienteur).
2. Le cas échéant, renseigner le nom du professionnel réorienteur dans l'extension sgrdv-provenance-nom-professionnel-reo (valeur HumanName).
3. Le Device source d'une demande $book doit porter au moins un identifiant dont le système émetteur (identifier.system) est renseigné ; la liste des portails n'est plus figée par le profil. Continuez de renseigner l'identifiant de portail attendu par le service.

Si vous produisez ou consommez des Bundles d'audit

1. outcome sur AuditEvent est désormais optionnel — aucune action requise si vous le renseigniez déjà.
2. Le Device acteur d'audit est identifié par identifier.system seul ; identifier.value reste acceptée mais n'est plus exigée.
3. Pour une transaction $book, la tuile de portail peut être portée par Device.property[tuilePortail].

Toutes intégrations confondues

1. Revalidez vos payloads contre la version 1.1.2 du paquet IG.
2. Traitez la §2 comme une rupture sur contrat expérimental — une mise à jour est requise avant la prochaine validation partenaire.