Questions fréquentes

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

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 » ; « Reje », « 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).
 

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) catégorie organisation, (ii) temporalité d’accueil, (iii) accueil séquentiel, (iv) 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.

C'est un scénario nominal possible si les fichiers d'attente ne sont pas synchronisés au sein du logiciel. Si cette situation se produit :

• Côté DMP : La V2 sera stockée (comme version initiale ou de remplacement selon le choix fait à la Question 1).
• Côté MSSanté : Le destinataire ayant reçu la V1, l'émetteur DOIT obligatoirement renvoyer la V2 par MSSanté (selon le principe du "Annule et remplace" exigé en vague 1) afin de garantir que le correspondant dispose de la même information médicale que celle présente sur le DMP du patient.
   

Note : Les éditeurs sont encouragés, dans la mesure du possible, à synchroniser leurs files d'attente DMP et MSSanté pour éviter ces écarts.

Si le DMP n'a jamais reçu la version initiale (V1), toute tentative d'envoi d'une V2 contenant une métadonnée de remplacement (RPLC ou lien vers l'identifiant de la V1) sera refusée par le DMP, car le document à remplacer est inconnu de ses services. Dans ce scénario, le logiciel a deux options, la première étant fortement recommandée :

1. Option privilégiée : Envoyer directement la version finale (V2) au DMP en tant que document initial (V1 pour le DMP). Les modifications intermédiaires restent purement locales au logiciel métier.
2. Option secondaire : Envoyer de manière séquentielle la V1, puis la V2 avec sa requête de remplacement (génère un trafic technique peu utile).

L’idUnité est invariante dans le temps, elle est structurée comme suit : « code INSEE régional / code interne ROR » avec code INSEE régional qui respecte la nomenclature TRE_R30_ReionOM https://mos.esante.gouv.fr/NOS/TRE_R30-RegionOM/FHIR/TRE-R30-RegionOM (par exemple, « 84/123abc »).

Le code INSEE régional est un code numérique (allant de 2 à 5 caractères).

Le code interne ROR peut être quant à lui un alphanumérique de longueur variable et non définie.

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.
 

Les unités ROR sont un prérequis à l’interopérabilité. Elles permettent d’associer une proposition d’admission (en réponse à une décision d’orientation) à une unité de prise en charge renseignée dans le ROR.
Il est nécessaire que les ESMS puissent paramétrer les unités ROR qui décrivent leur offre de prise en charge au sein du SI ESMS (DUI), en miroir de ce qui est paramétré dans ViaTrajectoire.

En effet, pour mettre à jour les statuts des notifications via le flux 4, il est nécessaire que le SI ESMS (DUI) indique, à partir de la mise en liste d’attente, l’unité ROR au sein de laquelle la prise en charge est à l’étude (cf. paragraphe « 2.6 Gestion des statuts » du guide d’implémentation fonctionnelle https://esante.gouv.fr/sites/default/files/media/document/VTPH_Guide-implementation.pdf).
 

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)

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.