Changelog SGRDV — release 1.2.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.2.1 → 1.2.2

Cette release correspond à un bump PATCH. Elle intègre :

• L'ensemble des changements de la version 1.1.2 de l'incrément 2 — voir §2.
• L'unification de la Provenance de requête et du Device source, communs à toutes les opérations (§3). 🟠
• Le passage de la Provenance $book / $cancel à un modèle à agent unique (§4). 🟠

Tous les changements portent sur des artefacts experimental = true.

1.2 Version explicite sur tous les artefacts

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

2. Intégration de la version 1.1.2

La version 1.2.2 intègre l'ensemble des changements publiés dans la version 1.1.2 de l'incrément 2 (ajustements des contraintes d'audit, exemples associés). Le détail est disponible à l'adresse suivante :

• Version 1.1.2 : https://simplifier.net/packages/ca.qc.sq.sgrdv/1.1.2

3. Unification de la Provenance de requête et du Device source 🟠

Toutes les opérations partagent désormais une seule Provenance de requête et un seul Device source. Auparavant, deux modèles coexistaient : un pour $find / $lock / $aggregate / $process-message (Device identifié par référence logique, non matérialisé) et un distinct pour $book / $cancel (Device matérialisé en ressource contenue).

3.1 Provenance de requête unique 🟠

SGRDVBaseRequestProvenance devient la Provenance commune à $find, $lock, $aggregate, $book, $cancel et $process-message. Le Device source est désormais matérialisé en ressource contenue (contained[portail]) et référencé via le fragment #portail. Les opérations qui identifiaient le système source par une référence logique (agent.who.identifier.system, Device non matérialisé) transmettent maintenant le Device dans contained.

Les éléments spécifiques à la réservation restent disponibles en optionnel sur la Provenance unifiée : nom du professionnel REO (extension nomProfessionnelREO), organisation d'origine d'une réorientation (agent[portail].onBehalfOf) et région administrative (location).

3.2 Device source unique 🟠

SGRDVBaseSourceSystemDevice devient le Device source unique. Il porte l'identifiant du système source et, en optionnel, la tuile du portail REO (property[tuilePortail]) et le lieu Clinique d'origine (owner).

L'acteur d'audit (SGRDVAuditAgent) demeure un profil distinct : il hérite du Device source unifié, restreint son identifiant à exactement un, et ne porte jamais le lieu Clinique d'origine.

3.3 Identifiant requis sur le Device source 🟠

Le Device source doit porter au moins un identifiant dont le système émetteur (identifier.system) est renseigné, sans que la liste des systèmes soit figée. La valeur de l'identifiant reste facultative.

3.4 Artefacts mis à jour

4. $book / $cancel — Provenance à agent unique 🟠

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

5. Recommandations de migration pour les partenaires

Provenance et Device (toutes opérations)

1. Produire la Provenance de la demande avec le Device source matérialisé dans contained[portail] et référencé par agent[portail].who.reference = "#portail". Les opérations $find, $lock, $aggregate et $process-message qui identifiaient le système source par une référence logique doivent migrer vers cette structure.
2. Référencer la Provenance de requête par son profil unique SGRDVBaseRequestProvenance (le profil SGRDVBaseBookRequestProvenance n'existe plus).
3. Référencer le Device source par son profil unique SGRDVBaseSourceSystemDevice (le profil SGRDVBaseBookSourceDevice n'existe plus).
4. Renseigner sur le Device source au moins un identifiant dont le system pointe vers un NamingSystem reconnu.

Si vous intégrez $book ou $cancel

1. Migrer la Provenance vers un agent unique portail. Retirer l'agent de réorientation et le RelatedPerson contenu.
2. Le cas échéant, renseigner le nom du professionnel réorienteur dans l'extension nomProfessionnelREO.
3. L'organisation d'origine d'une réorientation reste portée par agent[portail].onBehalfOf (Clinique, Installation ou Établissement), en référence logique.

Toutes intégrations confondues

1. Mettez à jour vos références au paquet SUSHI (version: 1.2.2).
2. Intégrez les changements de la version 1.1.2 si ce n'est pas encore fait (voir §2).
3. Revalidez vos payloads contre la version 1.2.2 du paquet IG.