Changelog SGRDV — release 1.2.8

Date de publication : 23 septembre 2026

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

1. Identification des professionnels — Numéro de licence d'un ordre professionnel 🟢

Pour référer, dans $find/$aggregate, à un professionnel autre qu'un médecin de famille, un résident ou un IPSPL, l'identifiant peut désormais se construire à partir du numéro de licence de son ordre professionnel plutôt que du code professionnel RAMQ.

1.1 Nouveaux NamingSystem des ordres professionnels 🟢

11 nouvelles ressources NamingSystem (kind #identifier) et leurs alias associés :

1.2 Nouveau code NoLicenceProfessionnel 🟢

1.3 Slicing de l'identifiant du Practitioner ($find / $aggregate) 🟢

SGRDVBaseFindPractitioner.identifier figeait jusqu'ici un unique identifiant de type #CodeProfessionnel (RAMQ). Il est désormais slicé par type.coding.code, ce qui ajoute une option sans retirer l'existante :

Un Practitioner continue de ne porter qu'un seul de ces deux identifiants. Les payloads existants (identifiant unique #CodeProfessionnel) demeurent valides sans modification.

2. OperationOutcome — ValueSets et profils dédiés par opération (surface SGRDV) 🟢

2.1 Nouveaux codes CodeSystem 🟢

32 nouveaux codes MSG_* ajoutés à SGRDVOperationOutcomeCodesExtensionCS (displays à compléter depuis le catalogue de messages applicatif).

2.2 ValueSets et profils OperationOutcome par opération 🟢

Chaque opération de la surface SGRDV dispose désormais de son propre jeu de valeurs d'outcome (façade, cf. ADR-020) et de son propre profil, dérivé de SGRDVBaseOperationOutcome, avec rebinding informatif (extensible) de issue.details :

Le profil de base SGRDVBaseOperationOutcome et la surface Systèmes source ne sont pas affectés.

2.3 Conteneurs de réponse spécialisés 🟢

Sur $find, $aggregate, $book et $cancel, l'entrée entry[outcome].resource du Bundle de réponse pointe désormais vers le profil spécifique de l'opération plutôt que vers le profil de base :

Le rebinding étant extensible, tout OperationOutcome valide contre SGRDVBaseOperationOutcome reste valide contre le profil spécialisé — aucune action requise.

2.4 Codes d'exemple corrigés 🟢

Les instances d'exemple $lock, $extend-lock et $release-lock sont rebranchées sur des codes sémantiquement plus justes : MSG_AUCUNE_DISPO → MSG_VERROU_IMPOSSIBLE (lock), → MSG_LOCK_EXPIRED (extend-lock), → MSG_RELEASE_BOOKED (release-lock, avec issue.code #not-found → #conflict). Changement d'exemples uniquement, sans impact sur le contrat.

3. Filtres d'exclusion sur $find / $aggregate 🟢

Trois nouveaux paramètres, symétriques aux paramètres d'inclusion existants, permettent d'exclure des résultats des professionnels, cliniques ou GMF ciblés :

Règle métier : un même identifiant ne peut pas apparaître à la fois dans un paramètre positif et son équivalent d'exclusion (practitioner/excludePractitioner, clinic/excludeClinic, gmf/excludeGMF). excludeGMF n'est accepté que sur la surface SGRDV — SGRDV résout les cliniques membres du GMF exclu et les relaie au système source sous forme d'occurrences répétées de excludeClinic.

4. $aggregate — timeslot-category rendu obligatoire 🟠

$find n'est pas affecté : timeslot-category y demeure optionnel, pour continuer à permettre une recherche de rendez-vous sans catégorie.

⚠️ Action requise : tout appel à $aggregate (portail ou DMÉ/SIP-C) doit désormais toujours fournir timeslot-category ; un appel sans ce paramètre est rejeté.

5. Audit — AuditEvent auto-portant (contained), remplace le Bundle d'audit 🟠

Le pipeline d'ingestion du Lac (Fabric HDS) ne décompose pas les Bundle type=collection : le modèle d'audit en Bundle (ADR-016) n'y est pas ingérable. L'audit passe à un AuditEvent auto-portant qui embarque ses ressources compagnes en contained (ADR-024, qui remplace ADR-016).

5.1 SGRDVAuditEvent 🟠

5.2 SGRDVAuditAgent 🟠

5.3 Retrait de SGRDVAuditBundle et ingestion 🟠

Le CapabilityStatement de la surface Audit est refondu en conséquence (ressource AuditEvent avec interaction create directe ; Device documenté comme ressource contenue, sans interaction REST propre).

⚠️ Action requise : les systèmes qui produisent des journaux d'audit SGRDV doivent migrer de la publication d'un Bundle type=collection à 4 entrées vers la publication d'un AuditEvent auto-portant unique, avec ses ressources compagnes en contained et meta.versionId/meta.lastUpdated renseignés sur chacune.

Ces profils (SGRDVAuditEvent, SGRDVAuditAgent, ex-SGRDVAuditBundle) portent status = #draft mais font l'objet d'un suivi changelog continu depuis la 1.1.1 ; le symbole 🟠 reflète leur statut experimental = true.

6. Recommandations de migration pour les partenaires

Si vous intégrez le portail ($find / $aggregate)

1. $aggregate : fournissez systématiquement timeslot-category — ce paramètre est désormais obligatoire (il reste optionnel sur $find).
2. Pour référer un professionnel autre qu'un médecin de famille/résident/IPSPL (via practitioner ou excludePractitioner), utilisez un identifiant de type NoLicenceProfessionnel (system = NamingSystem de l'ordre professionnel concerné, value = numéro de licence) plutôt que CodeProfessionnel.
3. De nouveaux paramètres optionnels excludePractitioner, excludeClinic et excludeGMF permettent d'exclure des professionnels, cliniques ou GMF des résultats.
4. Les OperationOutcome retournés peuvent désormais porter des codes documentés dans un jeu de valeurs propre à l'opération — binding informatif, aucune action requise si issue.details est déjà traité de façon générique.

Si vous intégrez le DMÉ/SIP-C ($find / $aggregate)

1. $aggregate : timeslot-category est désormais obligatoire dans les demandes reçues de SGRDV.
2. excludePractitioner et excludeClinic peuvent désormais être reçus dans les demandes ; excludeGMF n'est jamais relayé tel quel (SGRDV le résout en occurrences répétées de excludeClinic).
3. Un identifiant Practitioner de type NoLicenceProfessionnel peut désormais être reçu en plus de CodeProfessionnel.

Si vous produisez ou consommez l'audit affaire SGRDV (Lac / Fabric HDS)

1. Migrez la publication des journaux d'audit d'un Bundle type=collection (4 entrées, POST [base]/Bundle) vers un AuditEvent auto-portant (POST [base]/AuditEvent) embarquant ses ressources compagnes en contained.
2. Fixez les références locales agent[source].who.reference = "#source", agent[destination].who.reference = "#destination" et, lorsque présent, entity[payload].what.reference = "#payload".
3. Renseignez meta.versionId et meta.lastUpdated sur chaque ressource Device contenue (SGRDVAuditAgent).
4. Une transaction sans corps de réponse (ex. 204) peut désormais produire un audit sans entity[payload] — ne traitez plus ce cas comme une erreur de modélisation.
5. Le regroupement par fil repose désormais uniquement sur l'extension sgrdv-audit-discussion-id — Bundle.identifier n'existe plus.

Toutes intégrations confondues

1. Alignez vos consommations sur la version 1.2.8 du paquet IG.