Validateur FHIR - Qualification Pprod / Prod

[jguihot]

Actions à prévoir

Pprod

• [x] Déployer le package sur matchbox en Pprod
• [x] Création du validateur sur FhirValidator en Pprod
• [x] Qualification en Pprod

Prod

• [ ] Déployer le package sur matchbox en Prod
• [ ] Création du validateur sur FhirValidator en Prod
• [ ] Qualification en Prod

[TristanKEREVAL]

@nriss @3abdel3ali @mbrulliard @SEBELIN Bonjour, voici les problèmes que nous avons rencontré en pprod ans pour la qualification TDDUI. Pour la validation de la ressource DUIDocumentReference, en utilisant le SMT comme serveur de terminologie, on obtient : https://interop-pprod.esante.gouv.fr/evs/report.seam?oid=2.16.840.1.113883.2.7.4.6099 Lorsqu'on utilise le serveur de graham : https://interop-pprod.esante.gouv.fr/evs/report.seam?oid=2.16.840.1.113883.2.7.4.6097

Pour la validation de la ressource TDDUIBundle, en utilisant le SMT comme serveur de terminologie, on obtient : https://interop-pprod.esante.gouv.fr/evs/report.seam?oid=2.16.840.1.113883.2.7.4.6098 Lorsqu'on utilise le serveur de graham : https://interop-pprod.esante.gouv.fr/evs/report.seam?oid=2.16.840.1.113883.2.7.4.6096

Il semblerait que le SMT ait des difficultés à valider des codes issus de ValueSet basés sur des BCP, ici on retrouve un fonctionnement similaire pour DocumentReference.content.attachement.language et DocumentReference.content.attachement.contentType.

Ce manque de validation terminologique pose problème pour la validation des 2 ressources.

[nriss]

Toujours le même problème avec ce CodeSystem urn:ietf:bcp:13 définit les codes selon une grammaire, que le serveur de Grahame est capable de parser, mais pas ontoserver..

On en avait déjà parlé ici : https://github.com/ahdis/matchbox/issues/224

[jguihot]

@nriss , @SEBELIN , est-on d'accord que ces anomalies sont indépendantes du volet ? Pouvons-nous livrer les validateurs en Pprod, avec grosse réserve sur le fonctionnement SMT ?

[nriss]

Oui, indépendant du volet je confirme!

[mbrulliard]

Oui @nriss , et donc lié à une issue ESMS https://github.com/ansforge/IG-fhir-medicosocial-suivi-decisions-orientation/issues/205 (issue référencée dans l'issue matchbox que tu pointes) D'accord avec @jguihot : il faut prendre une décision rapidement pour livrer TDDUI mais les faux-FAILED (cas passants qui seront FAILED) ne sont vraiment pas propres. Une solution serait de passer par le serveur de Grahame en pré-prod et en prod (et quand le SMT sera entièrement fonctionnel, le serveur de Grahame pourra pointer sur le SMT pour les IG qui n'auront pas le package NOS dans les dépendances) ; est-ce envisageable @nriss ?

[nriss]

Comme le SMT fait partie du réseau fédéré de serveurs de terminologie, à priori, il suffirait d'indiquer le serveur de Grahame effectivement ! Normalement, le serveur de Grahame redirigera vers le SMT pour les terminologies dont il est maître

Cf. https://tx.fhir.org/tx-reg/

Il faudra juste vérifier sur les JDV ANS que le serveur de Grahame redirige bien vers le SMT et que les JDV du NOS notamment soient bien validés

[jguihot]

@nriss , c'est toute la problématique, pour l'instant la communication ne s'effectue pas correctement entre tx-serveur et smt. Nous contournons ce problème en maintenant les dépendances NOS dans l'IG pour l'instant. Mais au moins les anomalies BCP disparaissent. Nous en rediscuterons cet après-midi, mais j'entends que sur le principe tu serais OK pour cette modification de configuration

[nriss]

C'est effectivement la cible, de mettre le serveur de Grahame qui pointe le SMT pour les JDV et TRE dont il est maître, donc ça me paraît bien :)

[mbrulliard]

@M-Priour , es-tu d'accord sur le principe ?

[M-Priour]

Oui, c'est bien cela, on met en cible le serveur de Graham.