FAQ de l'offre : Ségur du numérique en santé

Des règles de masquage des notifications ont été spécifiées dans le guide d’implémentation fonctionnelles. Elles figurent au chapitre 2.9 Masquage des notifications. Sans indiquer de recommandation sur la méthode d’implémentation, ces règles suggèrent de calculer un méta-statut pour que les notifications soient masquées ou démasquées selon :

• Le statut de la notification
• La date d’échéance ou de clôture.

Ces règles visent à ne garder en liste de travail que les notifications dont le traitement est en cours.
 

La règle 5 du guide d’implémentation fonctionnelle reprise dans l’exigence MS.CDM/VT.04 du Référentiel d’Exigences Minimales du Référencement Ségur vague 2 liste plusieurs critères de recherche au sein de la liste de travail DUI. Le tableau ci-dessous explicite la correspondance avec chacune des données véhiculées dans les flux.

(*) À noter : en lien avec la gestion du jeu de donnée, il n’est pas possible actuellement de renseigner dans le CDA Décision d’Orientation le mode de prise en charge selon la nomenclature NOS.

Deux règles concernent la récupération périodique de données :

• Règle 1 : « Le système DOIT permettre aux utilisateurs de lancer une requête à ViaTrajectoire pour récupérer les nouvelles notifications d’orientation le concernant ainsi que les mises à jour de notifications existantes (flux 1). Le système DOIT aussi proposer de paramétrer la fréquence d’exécution des requêtes automatiques selon les pratiques des professionnels. ».
  Cette interrogation doit s’effectuer via une requête automatique dont la fréquence doit être adaptée aux pratiques des professionnels.
• Règle 32 : « Le système DOIT permettre aux utilisateurs de lancer une requête à ViaTrajectoire pour récupérer les le statut « Usager entré » des notifications des autres structures ayant un dossier en cours d’instruction ainsi que les autres mises à jour de statuts (flux 5). Le système DOIT aussi proposer de paramétrer la fréquence d’exécution des requêtes automatiques selon les pratiques des professionnels. »
   

Les flux 1 à 3 permettent de véhiculer les informations relatives aux notifications et de tracer le consentement de l’usager à l’évaluation de la décision :

• Le flux 1 permet de récupérer les décisions d’orientation émises par ViaTrajectoire dans le SI ESMS (DUI),
• Le flux 2 permet de récupérer les informations relatives à la décision d’acceptation du dossier par le SI ESMS (DUI) dans ViaTrajectoire,
• Le flux 3 permet de récupérer les informations relatives à l’évaluation du dossier par ViaTrajectoire dans le SI ESMS (DUI). 

Les flux 4 et 5 assurent la communication des changements de statuts opérés sur les notifications en cours de traitement :

• Le flux 4 permet de transmettre les informations de suivi du parcours des personnes orientées au sein de l’ESMS dans ViaTrajectoire,
• Le flux 5 permet de transmettre les informations relatives aux statuts des usagers de ViaTrajectoire dans le SI ESMS (DUI).
   

Deux exemples de fichiers CDA sont disponibles dans le guide d’implémentation technique :

• https://interop.esante.gouv.fr/ig/fhir/sdo/CDA_SI-ESMS_Decision.xml
• https://interop.esante.gouv.fr/ig/fhir/sdo/CDA_SI-ESMS_Evaluation.xml

Le bac à sable permet par ailleurs de conduire des tests complémentaires et de générer des fichiers de test à la volée permettant d’éprouver les différents cas métier (ex. révision, renouvellement, clôture, mise à jour…).
 

Les nomenclatures préfixées NO_* sont des nomenclatures CNSA. Le fichier Excel les détaillant est téléchargeable depuis la page https://interop.esante.gouv.fr/ig/fhir/sdo/annexes_Nomenclature.html, en cliquant sur le lien Nomenclature CNSA. Afin de pouvoir naviguer à l’intérieur du fichier, il est nécessaire de le télécharger et d’activer les macros.

Les types de décision sont « Attribution » ; « Rejet », « Sursis », « Non attribution supplémentaire » et « Clôture de droit ».
Les décisions « Rejet », « Sursis » et « Non attribution supplémentaire » associés aux codes 2, 3, 4 ne relèvent pas du périmètre du SI SDO. Seules les codes 1 et 5, associés respectivement aux décisions « Attribution » et « Clôture de droit », doivent être utilisées par les SI ESMS (DUI).
 

Il n’est pas nécessaire de revoir le paramétrage des unités organisationnelles du DUI. Cependant, il est attendu que chaque unité décrite dans le DUI soit rattachée à au moins une unité ROR et que cette unité (ROR) soit cohérente avec l'unité DUI en question (ex. mode de prise en charge, professionnels mobilisés...).

Plusieurs unités organisationnelles décrites dans le DUI peuvent être rattachées à une seule et même unité ROR. Et inversement, une unité DUI peut être rattachée à plusieurs unités ROR. Autrement dit, les ESMS n'ont pas besoin de changer leur organisation interne
À titre d'illustration, si un ESMS a 8 unités dans son DUI qui correspondent à 4 unités ROR, l'ESMS n'a pas besoin de modifier ses unités DUI. Il suffit que l’ESMS raccroche les 8 unités DUI à une ou plusieurs des 4 unités ROR.

Dans le cas où les unités organisationnelles DUI sont rattachées à plusieurs unités ROR, il sera nécessaire que les agents en ESMS, lors du traitement des notifications ViaTrajectoire, indiquent l'unité ROR de prise en charge retenue. Cette unité ROR servira à la mise à jour des statuts de traitement dans ViaTrajectoire.
 

La spécification fonctionnelle décrit plusieurs identifiants :

• idDecision : identifiant de la décision d’orientation attribué par la MDPH qui en est à l’origine
• idMDPHDecision : identifiant de la MDPH (OID de la MDPH) à l’origine de la décision
• idNat_Decision : identifiant de la décision d’orientation attribué par ViaTrajectoire
• idIndividu : identifiant de l’individu attribué par la MDPH qui est à l’origine de la décision.

Les données idIndividu et idDecision ont une portée locale. Le couple idDecision idMDPHDecision forme un identifiant de décision à portée nationale sur le plan métier tandis que la donnée idNat_Decision a une portée nationale et doit être utilisé comme identifiant technique de référence d’une décision.

Dans le CDA d’une décision :

• l’idNat_Decision est présent dans l’entête, au sein de la balise setId
• le couple idDecision idMDPHDecision est présent dans le corps, au sein de la balise identifiantDecision via les attributs extension et root
• le couple idIndividu idMDPHDecision est présent dans l’entête du CDA, dans la section recordTarget, dans la balise id via les attributs extension et root

Dans l’import CSV pour charger les données dans ViaTrajectoire :

• idDecision est présent à la colonne 62 du CSV
• idMDPHDecision n’est pas présent, c’est l’identifiant de la MDPH avec laquelle l’import est réalisé, la donnée est donc déduite du contexte d’import
• idNat_Decision n’est pas présent, c’est l’identifiant de la décision d’orientation attribué par ViaTrajectoire lors de l’import
• idIndividu est présent en colonne 2 du CSV

L’objectif principal est d’améliorer la qualité des données et la fluidité des échanges entre les SI MDPH (Dossier Usager Informatisé, DUI) et ViaTrajectoire, avec un impact attendu sur la réduction des erreurs et une meilleure traçabilité.