Jongler avec les Jeux De Valeurs et Schematrons de l'ANS
Générer des documents HL7 - CDA (Clinical Document Architecture) conforme pour les différents schematrons des différents outils proposés par l’ANS ce n’est pas une mince affaire.
En effet, pour générer un document CDA conforme, il faut :
- une syntaxe correcte
- une sémantique correcte
- un vocabulaire correct.
C’est simple, si vous remplissez ces trois critères vos documents sont bons.
Une syntaxe correcte
Ici, on commence tranquillement, le document généré doit être conforme au schéma cda.xsd fournit par HL7. Il y a une seule version de ce schéma et il est partagé par tous.
Quelques tests de non régression sur ce schéma, et vous êtes tranquille dans tous vos développements.
Une sémantique correcte
Là, ça se corse un peu. En effet, pour vérifier la conformité il faut que le CDA soit conforme à un ou plusieurs schematrons. Et il faut en fonction du contexte que ce CDA soit validé par un outil différent.
- Pour l’homologation DMP (ou pour tout envoi via un EAI dans le DMP), les schematrons qui font foi sont ceux disponibles sur : https://github.com/ansforge/TestContenuCDA-3-0
- Pour une homologation SEGUR (du moins c’était comme cela pour la vague 1), les schematrons qui font foi sont ceux disponbles sur l’espace de tests de l’ANS: https://interop.esante.gouv.fr/evs/home.seam
Si ces outils s’appuyaient sur les même schematrons et sur les mêmes versions, il n’y aurait pas de soucis. Mais c’est loin d’être le cas :
Pour le premier outil, il suffit de voir le nombre de modifications du projet (https://github.com/ansforge/TestContenuCDA-3-0/commits) pour s’apercevoir que le numéro de version 3.0 n’est que très théorique.
Pour le deuxième outil, même topo à la lecture de le release note (https://interop.esante.gouv.fr/releasenote/ ) on s’aperçoit que c’est la dernière modification dans l’outil qui fait foi.
Par conséquent, il est facile de comprendre qu’il est difficile d’être en mesure de générer des documents CDA conformes à ces deux outils et à tous moments.
Un vocabulaire correcte
Par vocabulaire correcte, j’entends les codes et libellés des jeux de valeurs (JDV) utilisés dans le CDA. Mais, ici l’affaire se corse encore un peu car ces mêmes jeux de valeurs sont également utilisés dans les transactions XDS (standard de l’IHE) du DMP.
Il faut donc que les documents CDA générés contiennent des codes/libellés conformes à des Jeux de Valeurs et que les transactions XDS (valides pour le DMP) aussi utilisent ces mêmes jeux de valeurs.
Ces Jeux de Valeurs ont deux sources différentes :
- Les jeux de valeurs officiels pour le GIE sesam-vitale disponibles dans l’espace industriel, au jour d’écriture de cet article, ceux du 23 février : https://industriels.sesam-vitale.fr/documents/823064/2268106/20240223-JDV_DMP_API_V2_XML.zip
- Les jeux de valeurs à jour et maintenus au fil de l’eau par l’ANS disponibles sur le site du NOS : https://mos.esante.gouv.fr/NOS/
Et ont deux cibles déployées différentes :
- Les jeux de valeurs utilisés par les outils schematrons : https://github.com/ansforge/TestContenuCDA-3-0/tree/main/jeuxDeValeurs
- Les jeux de valeurs déployées sur les différents environnements du DMP pour vérification des transactions XDS
Par conséquent, il est également facile de comprendre que si nous prenons un code / libellé d’une source, il n’est potentiellement pas disponible sur une des cibles et donc générer une erreur.
Conclusion
Nul doute qu’il faut faire évoluer les outils de vérifications et d’affiner ces derniers pour être le plus à jour possible. Mais, serait-il possible de définir des versions, ou même si ce n’est pas possible de figer ces outils/JDV à une date donnée (tous les x mois par exemple), le temps que tous les acteurs se synchronisent sur ces jeux de valeurs et versions de schematron. Définir une temporalité, des itérations.