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

Les statuts attendus par ViaTrajectoire dans le flux 4 sont ceux détaillés dans le paragraphe « 2.6 Gestion des statuts » du guide d’implémentation disponible à cette adresse https://esante.gouv.fr/sites/default/files/media/document/VTPH_Guide-implementation.pdf. Un seul statut suffit à la mise à jour de ViaTrajectoire ; il suffit de préciser soit le statut ESMS soit le statut Unité.

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

L’INS n’est pas une donnée transmise dans les flux. Elle ne peut pas être importée via le fichier d’import CSV. Seul le NIR peut être véhiculé par cette méthode. Cette donnée alimente d’ailleurs les documents CDA des flux 1 et 3.
La gestion de l’INS doit être réalisée lors de l’admission selon les règles du RNIV et du référentiel INS. Aucun comportement spécifique pour la qualification des INS n’est attendu dans le cadre d’une admission après orientation MDPH. Il est nécessaire de revenir au comportement nominal attendu dans le cadre d’une prise en charge en ESMS (qualification de l’INS lors de l’admission).
 

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.