Changelog SGRDV — release 1.0.6

Date de publication : 12 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.5 → 1.0.6 🟠

Cette release applique un bump PATCH portant une modification structurante sur le profil partagé SGRDVBaseFindPatient, utilisé par les deux surfaces pour les demandes de disponibilités.

• Patient.identifier.type devient obligatoire pour chaque identifiant du patient (1..1 MS).
• Un nouveau slice identifier[ni] normalise le NAM RAMQ lorsqu'il est porté par le patient : type = #NI, system = $ns-ramq, value = 1..1.
• Le changement reste documenté en 🟠 car l'artefact concerné est publié avec experimental = true.

Tous les artefacts versionnés sont alignés sur la version 1.0.6 via la configuration du paquet IG.

2. $find Patient — identifiant typé obligatoire et slice NAM RAMQ 🟠

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

2.1 Changement de cardinalité et de structure 🟠

Le profil impose désormais que chaque identifiant de patient soit typé. Quand le patient porte un NAM RAMQ, celui-ci doit être exprimé via le slice identifier[ni] plutôt que comme identifiant générique non typé.

2.2 Impact partenaires 🟠

• Portails (api-sgrdv) : doivent renseigner Patient.identifier.type pour tout identifiant transmis dans les demandes de disponibilités.
• DMÉ / SIP-C (api-source) : doivent également émettre des identifiants typés pour les réponses ou les charges utiles de disponibilité concernées.
• Cas RAMQ NAM : lorsqu'un patient est identifié par son NAM, le slice identifier[ni] doit être utilisé avec le système RAMQ et le code NI.

2.3 Artefacts mis à jour 🟠

3. Recommandations de migration pour les partenaires

Si vous intégrez api-sgrdv

1. Vérifiez que tous les Patient.identifier sortants sont typés.
2. Utilisez identifier[ni] pour le NAM RAMQ lorsque l'identifiant du patient est connu.

Si vous intégrez api-source

1. Appliquez la même contrainte sur les identifiants patient émis ou relayés par le DMÉ.
2. Validez vos scénarios de recherche de disponibilités avec un patient porteur d'un NAM RAMQ pour confirmer le bon usage du slice ni.

Toutes intégrations confondues

1. Revalidez les exemples et jeux de tests qui laissaient Patient.identifier.type absent.
2. Traitez cette release comme une rupture sur contrat expérimental : un payload encore non typé doit être corrigé avant publication.