Corrections d'erreurs et d'avertissements remontés par la validation QA du build IG Publish

[Haoura]

Description des changements

Erreurs de validation QA

• sushi-config.yaml : remplacement de valueUrl par valueCanonical pour l'extension implementationguide-resource-logical (type FHIR incorrect).
• Plusieurs profils (FRCDAAssociatedEntity, FRCDAEncounterParticipant, FRCDADICOMObservationSubordonnee, FRCDADICOMQuantiteSubordonnee, FRCDADemandeDExamenOuDeSuivi, FRCDARencontre, FRCDAResultat, FRCDAResultatExamensDeBiologieElementCliniquePertinent, FRCDASigneVitalObserve, FRCDASimpleObservation, FRCDAStatut) : remplacement des bindings required sur classCode/code par un binding additionnel (^binding.additional[+]) pour ne pas entrer en conflit avec le binding required déjà hérité de CDA.

Slicing templateId sur frParticipantValideurResultats

• FRCDAResultatsExamensDeBiologieMedicale : correction du slicing de templateId sous participant[frParticipantValideurResultats] (ajout du discriminant et de la slice templateId-other) au lieu de fixer directement .root.
• FRCDAParticipantCorps : cardinalité 1..1 MS explicite sur templateId[templateId-other].root.

Avertissements "Illegal HTML"

Correction de descriptions FSH contenant des balises XML littérales (<text>, <telecom .../>, <consumable>, etc.) que le moteur Markdown→HTML interprétait comme du HTML brut invalide. Les occurrences sont désormais entourées de backticks pour être rendues comme du code (échappées) :

• CISISTelecom.fsh
• FRCDASectionCRBIOChapitre.fsh
• FRCDAQuantiteDeProduit.fsh

Warnings / erreurs restants (non corrigeables)

• Duplicate anchor Ids sur cisis-addr.html (en/fr) : bug de rendu de l'IG Publisher sur le type CDA AD, pas lié à notre FSH.
• Fragments HTML non inclus (globals-table.xhtml, expansion-params.xhtml) : fichiers du template HL7 par défaut, warning standard sur tout IG SUSHI.
• Incompatibilité de version FHIR : ans.fr.terminologies et hl7.fhir.uv.ips sont en FHIR 4.0.1, alors que cet IG est en FHIR 5.0.0. Incompatibilité entre packages.

Type de changement

• Nouveau contenu (profil, extension, page, exemple)
• Correction (erreur dans un profil, une page, une dépendance)
• Refactoring (pas de changement fonctionnel)
• Release

Checklist

• sushi-config.yaml : releaseLabel est bien ci-build pour une version en développement
• change-log.md mis à jour
• La branche est à jour avec main

Preview

https://ansforge.github.io/interop-IG-cda-document-core/qa-validation-errors/ig

[nriss]

Ok pour moi, juste la partie additional binding à creuser/discuter !

Il faut s'assurer que nos JDVs soient bien conformes au standard std CDA

[nriss]

Je ne comprends pas trop ici - on a déjà un binding required en CDA, mais on met un autre ValueSet

Est-ce que c'est les mêmes codes avec traductions ? Normalement le cas échéant il ne devrait pas y avoir d'erreurs.

Pourriez-vous m'indiquer l'erreur qui était affichée ?

J'ai l'impression qu'il y a qqc à creuser

Ma question se pose pour l'ensemble des bindings passés en additional.

[Haoura]

Le binding required hérité du std CDA (CDAObservationInterpretation pour interpretationCode) restreint à une liste fermée de codes HL7, alors que le jdv-hl7-v3-ObservationInterpretation-cisis utilise le même système de codes (mêmes codes + libellés traduits en FR) mais avec une liste plus large. Comme FHIR interdit à un profil de remplacer un binding required hérité par un value set qui n'en est pas un sous-ensemble, l'ancien from ... (required) faisait planter le build, erreur exacte :

https://ansforge.github.io/interop-IG-cda-document-core/main/ig/qa.min.html#___w_interop-IG-cda-document-core_interop-IG-cda-document-core_igSource_fsh-generated_resources_StructureDefinition-fr-cda-statut

Élément	ValueSet JDV (CI-SIS)	ValueSet std CDA hérité	Codes JDV absents du std CDA
interpretationCode (Statut, SimpleObservation, SigneVitalObserve, Resultat, …)	jdv-hl7-v3-ObservationInterpretation-cisis	CDAObservationInterpretation	RR, NR, E, NS, LU, LX, HU, UNE, HX, NEG, DET, SDD, EX, CAR, POS, SYN-S, NCL, ND, SYN-R, WR, EXP, IE, IND

binding.additional[+].purpose = #required est le mécanisme FHIR R5 prévu pour ce cas : il ajoute le binding JDV en plus du binding std CDA, sans le remplacer, le binding hérité reste actif, donc la conformité au std CDA n'est absolument pas affaiblie.

• https://hl7.org/fhir/R5/elementdefinition-definitions.html#ElementDefinition.binding.additional

Cette même modification se retrouve sur les 4 bindings convertis en additional dans chaque cas, le binding required hérité du std CDA porte sur une liste de codes plus restreinte que celle du JDV CI-SIS correspondant, ce qui empêchait de remplacer directement l'un par l'autre :

• interpretationCode (Statut, SimpleObservation, SigneVitalObserve, Resultat, DemandeDExamenOuDeSuivi, DICOM…) :
  • JDV jdv-hl7-v3-ObservationInterpretation-cisis vs std CDA CDAObservationInterpretation
• EncounterParticipant.typeCode :
  • JDV JDV_J140-EncounterParticipationType-CISIS vs std CDA v3-xEncounterParticipant
• Rencontre.moodCode :
  • JDV jdv-hl7-v3-ActMood-cisis vs std CDA v3-xDocumentEncounterMood
• AssociatedEntity.classCode :
  • JDV JDV_J141-RoleClass-CISIS vs CDARoleClassAssociative

Cette même modification a corrigé les quatre éléments en utilisant binding.additional, tout en conservant le binding.required hérité du standard CDA.

[nriss]

Je suis un peu étonné

• Le standard CDA impose une liste restreinte de code avec un binding required interdisant d'en rajouter
• On choisit en France de ne pas prendre cette contrainte imposée par le standard et de rajouter des codes non permis pas CDA ?

Je ne suis pas sûr que lorsqu'on crée des instances de documents CDA, malgré les additional bindings, les codes ajoutés soient acceptés.

Je n'ai pas de solution mais je vois plusieurs pistes :

• Etudier le comportement du validateur sur un code qui n'est pas permis par le standard mais rajouté dans l'additional binding
• Challenger d'un point de vue métier l'ajout de ces codes non standards
• Trouver une autre méthode de renseignement des codes ? Peut être via les translations ou qqc comme ça ?

[Haoura]

@nriss Je testerai le comportement du validateur avec un code absent du ValueSet du std CDA, mais ajouté dans le binding.additional, afin de trancher ce point techniquement. Je regarderais aussi s’il existe une autre méthode pour gérer ces codes, tout en évitant les erreurs de validation.

J'ai également comparé les codes des ValueSets du std CDA avec ceux des JDV-CI-SIS.
@nmahraz et @aperie07 Voici l'écart réel, confirmé par les erreurs du validateur, et vérifié côté HL7 :

• interpretationCode — utilisé dans les entrées suivantes : FR-Statut, FR-Simple-Observation, FR-Signe-vital-observé, FR-Resultat, FR-Resultat-examens-de-biologie-element-clinique-pertinent, FR-DICOM-Quantite-subordonnee, FR-DICOM-Observation-subordonnee, FR-Demande-d-examen-ou-de-suivi.

  • jdv-hl7-v3-ObservationInterpretation-cisis (39 codes) vs std CDA CDAObservationInterpretation (18 codes), même CodeSystem v3-ObservationInterpretation.
    → Codes absents du std CDA : CAR, DET, E, EX, EXP, HU, HX, IE, IND, LU, LX, NCL, ND, NEG, NR, NS, POS, RR, SDD, SYN-R, SYN-S, UNE, WR.
    → Existent bien côté HL7, simplement non repris dans le sous-ensemble std CDA.

• Rencontre.moodCode — utilisé dans l'entrée : FR-Rencontre.

  • jdv-hl7-v3-ActMood-cisis (16 codes) vs std CDA v3-xDocumentEncounterMood (8 codes), même CodeSystem v3-ActMood.
    → Codes absents, confirmé par l'erreur du validateur : OPT, PERM, GOL, SLOT, RMD, PERMRQ, RSK, EXPEC.
    → Tous définis dans v3-ActMood côté HL7 (ex. RMD="recommendation", OPT="option").

• EncounterParticipant.typeCode — utilisé dans : encounterParticipant (en-tête).

  • JDV_J140 (6 codes) vs std CDA v3-xEncounterParticipant (5 codes).
    → Le validateur rapporte 6 codes en erreur (REF, CON, RESP, ATND, ADM, DIS), mais c'est parce que l'URL du CodeSystem ANS (TRE_A13) diffère de celle du std CDA (v3-ParticipationType) — même OID HL7 2.16.840.1.113883.5.90.
    → Un seul code absent : RESP ("responsible party"), bien défini dans v3-ParticipationType côté HL7.

• Sur interpretationCode, j’ai regardé les templates IHE :

  • IHE PaLM – Laboratory Observation : interpretationCode utilise le ValueSet HL7 v3 ObservationInterpretation.
  • IHE PCC – Vital Signs / Simple Observation : aucun ValueSet spécifique n’est imposé.

[Haoura]

@nriss J'ai testé avec le code CAR (qui n'existe pas dans le value set std CDA) sur l'exemple patient-summary, et je n'ai pas eu d'erreur de validation. Cela confirme que le mécanisme binding.additional de FHIR R5 fonctionne bien : il prend en compte les codes présents dans ce binding additionnel.

Après discussion avec Nidal @nmahraz ce matin, la bonne solution serait plutôt d'ouvrir un ticket JIRA côté CDA std, pour leur demander pourquoi ils ont restreint certains codes dans leur value set et s'il est possible d'y ajouter les codes existants dans les JDV HL7.

[nriss]

Super, merci bcp pour ton analyse détaillée @Haoura !

Je suis d'accord avec Nidal! Il me semble donc pertinent de laisser les additional binding et de faire des tickets jira en parallèle dans ce cas