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

Lors de la mise à jour des statuts en unité, il est nécessaire de partager à ViaTrajectoire, en plus de l’identifiant unité ROR, les statuts et motifs, les données suivantes : (i) nom de l’unité, (ii) catégorie organisation, (iii) temporalité d’accueil, (iv) accueil séquentiel, (v) le mode de prise en charge. Ces données doivent être renseignées selon les jeux de valeurs suivant : 

• Catégorie d’organisation : JDV_J34_CategorieOrganisation-ROR / TRE_R244-CategorieOrganisation
• Temporalité d’accueil : JDV_J30_TemporaliteAccueil_ROR (à transmettre dans les cas précisés par la spécification fonctionnelle des échanges)
• Accueil séquentiel : booléen (true/false)
• Mode prise en charge : JDV_J264_ModeEtCentreDePriseEnCharge-MDPH

Le caractère obligatoire de ces éléments est décrit dans les spécifications des échanges.

Afin de réaliser une mise à jour, révision, clôture ou renouvellement, il est nécessaire de procéder en deux temps :

1. Import d’un premier jeu de décisions initiales,
2. Import d’un second jeu de décisions venant mettre à jour, réviser, clôturer ou renouveler les décisions précédemment importées.

Dans le fichier CSV, une décision d’orientation est identifiée par le triplet de données suivant :

• idMDPH colonne 1
• idIndividu colonne 2
• idDecision colonne 62.

Si le second import utilise le même triplet, toutes les autres données de la décision d’orientation sont remplacées par les nouvelles données importées.

Si le second import utilise le même couple idMDPH, idIndividu avec un idDecision différent, une nouvelle décision est créée. Si l’on souhaite indiquer qu’il s’agit d’une révision, clôture ou renouvellement il faut utiliser des colonnes complémentaires :

• colonne 62 : mettre un nouvel identifiant local
• colonne 72 : mettre l’identifiant local de la décision révisée, renouvelée ou clôturée
• pour une cloture :
  • colonne 106 : mettre le code 5 (cloture)
• pour un renouvellement :
  • colonne 71 : mettre le code 2 (renouvellement)
  • colonne 106 : mettre le code 1 (attribution)
• pour une révision :
  • colonne 71 : mettre le code 3 (révision)
  • colonne 106 : mettre le code 1 (attribution)

Pour plus de détail se référer aux spécifications de l’import CSV qui sont communiquées en réponse à la demande d’accès au bac à sable. 

Les mise à jour / révisions / renouvellements / clôtures sont par ailleurs des événements fréquents en ESMS. Il est particulièrement important d’éprouver ces fonctionnalités en phase de tests sur le bac à sable.

Les spécifications de l’import CSV sont communiquées en réponse à la demande d’accès au bac à sable. Ce document précise pour chaque colonne du fichier, la donnée importée et le format attendu. 

Ce mécanisme d’import est celui actuellement utilisé par les MDPH, il ne respecte pas toutes les exigences et nomenclatures de l’interopérabilité. En particulier, il n’est pas possible d’utiliser l’import CSV pour :

• Charger dans ViaTrajectoire les données suivantes :
  • INS
  • dateDemenagement
  • statutDeces
  • motifFinPAG
  • precisionReponseRevisionTiers
• Récupérer dans les fichiers CDA Décision d’Orientation / Evaluation les données suivantes :
  • modePriseCharge (colonnes 77, 79, 81 du CSV)
  • quantification (colonnes 76, 78, 80 du CSV)
  • motivation (colonne 64 du CSV)

Pour le mode de prise en charge, la nomenclature d’import se base sur 4 codes tandis que les spécifications d’interopérabilité qui anticipent une interopérabilité MDPH-CNSA-ViaTrajectoire se basent sur une nomenclature d’exposition issue des NOS (JDV_J264_ModeEtCentreDePriseEnCharge_MDPH).

Pour les données de quantification, l’import se fait à l’aide d’un champ texte non structuré tandis que les spécifications d’interopérabilité anticipent une interopérabilité MDPH-CNSA-ViaTrajectoire et décrivent une donnée structurée en trois éléments (nombre, unité et périodicité.

Pour les motivations, la colonne 64 permet d’alimenter le champ « motivationLocale » du CDA qui est une donnée textuelle. Si le champ « motivationLocale » du CSV est rempli, alors ViaTrajectoire renvoie « 9999 – Autre » dans le champ « motivation » du CDA. Cela correspond, à ce jour, à la seule manière de remplir ce champ CDA

L’ensemble des informations relatives à l’interopérabilité entre le module Handicap de ViaTrajectoire et les SI ESMS (DUI) est mise à jour fréquemment et disponible sur une page dédiée du Portail de la e-santé pour les Entreprises du Numérique en Santé : https://esante.gouv.fr/ens/offre/interoperabilite-viatrajectoire-module-handicap.

Il y a deux « volets » derrière la clôture du dossier :

• D’une part la notification passe à « admission impossible entérinée » / « notification annulée »et donc la notification doit être masquée (à réception du flux 5 et en informant les agents en ESMS)
• D’autre part, l’éventuel dossier usager dans le DUI associé peut être archivé (cad considéré inactif dont l’usager est sorti).
   

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…).