Changelog SGRDV — release 1.0.5

Date de publication : 25 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 Bump 1.0.4 → 1.0.5 🟠

Cette release applique un bump PATCH portant plusieurs modifications :

• §2 — Sur les deux surfaces (api-sgrdv et api-source), le Bundle de réponse de l'opération $book doit désormais toujours contenir un OperationOutcome (succès comme refus). Auparavant, l'OperationOutcome n'était attendu qu'en cas de refus. 🟠
• §3 — $find Practitioner : nouvelle extension statutGMFProfessionnel (GMF / Hors GMF). 🟢
• §4 — $book : agent[professionnelREO].onBehalfOf élargi à trois profils Organization (Clinique / Institution / CIUSS) et nouveau slice parameter[organisationREO] matérialisant l'organisation d'origine de la réorientation au niveau du payload. 🟢
• §5 — $book : interdiction explicite de matérialisation de l'Appointment via parameter[bookedAppointment].resource. 🟢 (neutre en pratique — déjà couvert par l'invariant FHIR inv-1)
• §6 — $lock / $process-message : précision documentaire (SGRDV est l'autorité du verrou).
• §7 — list-clinics : reformulation terminologique (services couverts par la RAMQ plutôt que « cliniques publiques »).
• §8 — Pipeline CI / build : mises à jour mineures Azure Pipelines (hors contrat partenaire).

Le bump PATCH est déclenché par §2 (rupture sur un contrat experimental = true). Les autres sections sont rétrocompatibles ou documentaires et ne justifieraient pas un bump à elles seules.

Tous les artefacts versionnés (config IG, OperationDefinition, CapabilityStatement) sont alignés sur la version 1.0.5. L'attribut experimental = true est conservé sur tous les artefacts.

Le bump est conforme à la politique de versionnement publiée en 1.0.2 : ruptures sur des artefacts experimental = true → bump PATCH.

2. Bundle de réponse de $book — OperationOutcome toujours présent 🟠

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

2.1 Changement de cardinalité 🟠

L'OperationOutcome n'est donc plus conditionnel à un refus : il accompagne aussi les réponses de succès.

2.2 Sémantique attendue de l'OperationOutcome

L'Appointment réservée n'est jamais rematérialisée dans le Bundle de réponse — le portail dispose déjà de l'information matérialisée via $find. Cette règle reste inchangée par rapport à 1.0.4.

2.3 Impact partenaires

• Émetteurs (SGRDV vers portails sur api-sgrdv ; DMÉ/SIP-C vers SGRDV sur api-source) : doivent désormais émettre un OperationOutcome informational dans le Bundle de succès, en plus du Parameters de résultat. Un Bundle de succès sans OperationOutcome n'est plus conforme.
• Récepteurs : peuvent désormais s'attendre à recevoir un OperationOutcome dans tous les cas et l'utiliser pour journaliser/afficher un message d'accusé de réception sur les réponses de succès.

2.4 Artefacts mis à jour

2.5 Nouvelles instances d'exemple 🟢

Les exemples de succès (SGRDVBookExampleResponseSuccess et SGRDVSourceBookExampleResponseSuccess) embarquent désormais à la fois le Parameters de résultat et le nouvel OperationOutcome informational, conformément à la nouvelle cardinalité.

3. $find Practitioner — extension statutGMFProfessionnel 🟢

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

3.1 Nouvelle extension

3.2 Nouveaux artefacts terminologiques 🟢

3.3 Impact partenaires

• DMÉ/SIP-C (surface api-source) : peuvent désormais qualifier l'inscription d'un Practitioner retourné dans la réponse $find par son statut GMF lorsque l'information est disponible. L'extension reste optionnelle (0..1) — aucune action requise si l'information n'est pas portée par le système source.
• Portails (surface api-sgrdv) : peuvent exploiter ce qualificatif pour distinguer une inscription en GMF d'une inscription hors GMF dans l'expérience utilisateur (priorisation des plages, libellés, etc.).

4. $book — agent[professionnelREO].onBehalfOf élargi à trois profils Organization + matérialisation au niveau payload 🟢

S'applique aux profils partagés SGRDVBaseBookRequestProvenance (élargissement du typage onBehalfOf) et SGRDVBaseBookPayloadParameters (nouveau slice parameter[organisationREO]).

4.1 Contexte

Dans la version 1.0.4, Provenance.agent[professionnelREO].onBehalfOf était typé Reference(SGRDVBaseFindOrganization), c'est-à-dire une clinique identifiée par un CodeEtablissement RAMQ. La sémantique métier de la réorientation REO peut cependant nécessiter de référencer une institution hospitalière ou un CIUSS, identifiés par leur code MSSS — ce que le typage 1.0.4 ne permettait pas.

4.2 Changement de typage 🟢

Tout payload 1.0.4 conforme reste valide en 1.0.5 (la clinique RAMQ demeure un type cible accepté).

4.3 Nouveaux profils Organization 🟢

4.4 Nouveaux codes terminologiques 🟢

4.5 Matérialisation de l'organisation au niveau du payload 🟢

Nouveau slice ajouté sur SGRDVBaseBookPayloadParameters :

L'organisation d'origine de la réorientation est matérialisée comme ressource au niveau du Parameters payload (pattern aligné avec parameter[patient].resource et parameter[provenance].resource). Provenance.agent[professionnelREO].onBehalfOf la référence en logical reference ; l'appariement entre les deux se fait par Identifier.

4.6 Impact partenaires

• Portails (surface api-sgrdv) : peuvent désormais fournir une organisation d'origine de réorientation au niveau du payload $book, identifiée par RAMQ (clinique), MSSS+CodeInstitutionMSSS (institution hospitalière) ou MSSS+CodeCIUSSMSSS (CIUSS).
• Surface source (SGRDV → DMÉ) : propage le nouveau paramètre comme tout autre paramètre $book reçu du portail. Le typage élargi de onBehalfOf traverse la surface sans transformation supplémentaire.

4.7 Artefacts mis à jour

5. $book — interdiction explicite de matérialisation de l'Appointment via parameter.resource 🟢

S'applique au profil partagé SGRDVBaseBookResultParameters.

5.1 Contrainte ajoutée

La disponibilité réservée transite uniquement en logical reference (valueReference.identifier) ; toute matérialisation via parameter[bookedAppointment].resource est désormais formellement interdite par le profil. L'invariant FHIR inv-1 (mutuelle exclusion value[x] / resource) le couvrait déjà implicitement — le profil rend la contrainte explicite et auditable côté validation.

5.2 Impact partenaires

Aucun en pratique : tout payload 1.0.4 conforme reste valide en 1.0.5. Le pattern logical reference seul était déjà la voie unique recommandée et explicitée dans la description du profil.

6. $lock / $process-message — précision : SGRDV est l'autorité du verrou (mise à jour documentaire)

En réponse au commentaire de conformité du $lock Source, la note suivante a été inscrite dans la description des artefacts concernés :

SGRDV agit comme autorité du verrou. Les ajouts, prolongations et retraits de verrous sont propagés aux DMÉ via $process-message. Le DMÉ n'expose pas d'opération $lock transactionnelle.

6.1 Artefacts mis à jour

Aucune modification de cardinalité ni de typage — purement documentaire.

7. list-clinics — terminologie : précision sur la couverture RAMQ (mise à jour documentaire)

Les descriptions et commentaires liés à GET [base]/Organization (surface api-source) ont été reformulés pour clarifier le critère de filtrage côté DMÉ.

7.1 Reformulations

7.2 Artefacts mis à jour

Aucune modification de cardinalité, de typage ni de règle de filtrage côté serveur — purement terminologique. Le critère métier est identique à 1.0.4 : seules les cliniques de 1ère ligne présentement desservies par le DMÉ et offrant des services couverts par la RAMQ sont retournées.

8. Pipeline CI / build — mises à jour mineures (hors contrat partenaire)

Mises à jour internes du pipeline Azure Pipelines, sans impact sur les artefacts FHIR ni sur les partenaires :

Aucune action requise côté partenaire.