In addition to general maintenance, this release includes changes which in the main will support: the Choose Pharmacy service, error workflows for care documents and complexities around organisation and location data (e.g. type classification, regions and clusters).

0.3.1-alpha

- `documentation` References to the [Prostate Cancer Spec IG](https://bih-cei.github.io/ProstateCancerSpec/index.html) added as a reference example - `documentation` References to originalText/narrativeLink removed from the section grouper description - `documentation` Text "one grouper per preparation" removed from all grouper profile pages (#249) - `documentation` Relationship between examination request, specimen and case added (#250) - `documentation` Search parameters adjusted for finding/grouper (#248) - `feature` DiagnosticReport.code: new ValueSet MII_VS_Patho_Report_Code_LOINC, extensible binding (#166) - `documentation` Examination request: requisition as order group/case (#253) - `documentation` Specimen: referencing logic of the specimens added (#255) - `documentation` Grouper: derivedFrom note added (#257) - `changed` Composition.event corrected (#258) - `documentation` Scenarios: SDC passage made more precise (#256) - `documentation` Module description extended: design decisions, synoptic structured reports (#261) - `documentation` Life-cycle tables brought in line with the updated report-form matrix (#247) - `feature` Specimen.collection.bodySite: R5 BodyStructure extension (mCode dropped) including prostatectomy and breast example (#259) - `feature` EU Lab alignment: DiagnosticReport↔Composition extensions and optional Composition section slices (#262, #263) - `fix` Corrections: CapabilityStatement URL, missing substances in the specimen examples

Cleaned up some validataion errors

KDS Modul Consent Release 2027.0.0-ballot.rc1 - Policies SNID korrigiert #121 - Policy Labels ACRIBIS korrigiert #129 - MIIConsentVersionModuleCodeSystem: BC Varianten für Vertretende hinzugefügt #127 - Validierungs- und Abhängigkeits-Probleme (`consent.category` Slices) behoben #124, #119 - CodeSystem in Beispielen korrigiert #113 - sprachliche Verbesserung zur Beschreibung der Level #112 **Full Changelog**: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/compare/2026.0.0...2027.0.0-ballot.rc1

### Version: 2027.0.0-ballot.rc3 Ballot candidate for 2027.0.0, superseding `2027.0.0-ballot.rc2`. ### FHIR / Content Changes: #### MII_PR_Labor_Laborbefund and MII_PR_Labor_Laboruntersuchung - category: One open slice on `category` carrying the mandatory HL7 coding, instead of a slice whose codings were sliced again — two slices at that level are not disjoint, since a CodeableConcept holding both codes matches both patterns. LOINC `26436-6` stays permitted as a further coding but is no longer required. Measured against the category shapes of every release since 2025.0.2, including the microbiology module's: all validate.

# Changelog SGRDV — release `1.2.5` **Date de publication :** 2 septembre 2026 > Légende : 🔴 = rupture sur contrat de production (`experimental = false`) · 🟠 = rupture sur contrat en validation (`experimental = true`) · 🟢 = ajout ou assouplissement rétrocompatible --- ## 1. Terminologie — spécialités de professionnels ### 1.1 Retrait de codes SNOMED CT du ValueSet `SGRDVSpecialtyVS` 🟠 Le jeu de valeurs `SGRDVSpecialtyVS` (binding `required` sur `PractitionerRole.specialty`, utilisé par `$find`, `$aggregate` et `$book` sur les deux surfaces) est aligné sur les types de professionnels réellement en usage : retrait de trois codes obsolètes et ajout d'un code. | Code SNOMED CT | Changement | |---|---| | `59058001` (General practitioner / Omnipraticien) | Retiré | | `62247001` (Family doctor / Médecin de famille) | Ajouté | | `224571005` (Nurse practitioner / Infirmière praticienne spécialisée) | Retiré | | `45081000087108` (Dietetic technician / Technicien en diététique) | Retiré | L'exemple de référence `SGRDVExamplePractitionerRoleRequester` est mis à jour de `59058001` vers `62247001`. ⚠️ **Action requise** : tout partenaire envoyant ou recevant `PractitionerRole.specialty` avec l'un des trois codes retirés doit migrer immédiatement. --- ## 2. Réservation de rendez-vous (`$book`) ### 2.1 Langue de communication du patient obligatoire 🟠 Le profil `SGRDVBaseBookPatient` déclare désormais `Patient.communication` avec une cardinalité `1..*` (au moins une langue), restreinte au français et à l'anglais via le nouveau ValueSet `SGRDVLanguageVS` (BCP 47). | Élément | Avant | Après | |---|---|---| | `SGRDVBaseBookPatient.communication` | Non contraint par le profil (cardinalité de base FHIR `Patient`) | `1..* MS` — `communication.language` `1..1 MS` lié à `SGRDVLanguageVS` (`required`, `fr` \| `en`) | | ValueSet `SGRDVLanguageVS` | Inexistant | Nouveau — `fr` (French/Français), `en` (English/Anglais) | ⚠️ **Action requise** : si vous intégrez `$book` (api-sgrdv ou api-source) en validation anticipée, incluez désormais au moins une langue de communication (`fr` ou `en`) dans `Patient.communication` pour chaque requête et réponse `$book`. --- ## 3. Profils Patient communs ### 3.1 Canal SMS disponible dès `$find` et `$aggregate` 🟢 Le slice `telecom[sms]` (optionnel), auparavant déclaré uniquement sur `SGRDVBaseBookPatient`, est remonté sur le profil parent `SGRDVBaseFindPatient`. Il est donc désormais disponible sur `$find` et `$aggregate`, en plus de `$book`, sur les deux surfaces API. Le rang de préférence (`telecom.rank`) demeure une contrainte propre à `$book`. | Élément | Avant | Après | |---|---|---| | `telecom[sms]` | Déclaré uniquement sur `SGRDVBaseBookPatient` (`$book`) | Déclaré sur `SGRDVBaseFindPatient`, hérité par `$find`, `$aggregate` et `$book` | Aucune action requise — ajout rétrocompatible et purement optionnel. --- ## 4. Exemples ### 4.1 Alignement de conformité des instances de réponse 🟢 Corrections des instances d'exemple (`Usage: #example`) pour `$lock`, `$extend-lock`, `$book`, `$find` et `$aggregate` : - Ajout de `Bundle.entry.fullUrl` sur les Bundles collection (contrainte `bdl-15`). - Alignement des `OperationOutcome` d'exemple sur `SGRDVBaseOperationOutcome`. - Utilisation de `SGRDVBaseFindPractitioner` pour l'exemple `Practitioner` de `$find`. - Correction de la cible `Provenance` du rendez-vous réservé — `Appointment/{id}/_history/{versionId}` plutôt qu'un `urn:uuid`. - Ajout du code `MSG_BOOK_REUSSI` au `CodeSystem` `SGRDVOperationOutcomeCodesExtensionCS` (message de succès pour `$book`). Aucune action requise — corrections d'exemples et ajout de code optionnel, sans impact sur les profils ou contrats existants. --- ## 5. Recommandations de migration pour les partenaires ### Si vous intégrez la recherche de professionnels (`specialty`) — `$find` / `$aggregate` / `$book` 1. Retirez toute dépendance aux codes SNOMED CT `59058001`, `224571005` et `45081000087108`. ### Si vous intégrez `$book` 1. Fournissez au moins une langue de communication (`Patient.communication`, `fr` ou `en`) dans chaque requête et réponse `$book`. 2. Le canal SMS (`telecom[sms]`) est maintenant disponible dès `$find`/`$aggregate` si vous souhaitez le collecter plus tôt dans le parcours. ### Toutes intégrations confondues 1. Alignez vos consommations sur la version `1.2.5` du paquet IG. 2. Revalidez vos payloads utilisant `PractitionerRole.specialty` contre le `SGRDVSpecialtyVS` mis à jour.