Questions fréquentes

Comme indiqué dans le DSR, l'habilitation EDC PSC Editeur (Editeur de logiciel utilisateur et Editeur de Proxy e-santé) est obligatoire et constitue un pré requis à votre référencement Ségur.

Dans le cas où vous n’avez pas obtenu l’habilitation Editeur de logiciel utilisateur et/ou l’habilitation Editeur de Proxy e-santé de l’EDC PSC Editeur à l’échéance de la Date 3 du guichet Ségur (date limite de fin des échanges de l’Editeur avec l’ANS), vous devez transmettre une capture d’écran de l’étape "Dépôt de preuves" du guichet EDC PSC Editeur devant obligatoirement afficher :

• Le numéro unique de référencement (NRU),
• Le nom de la solution,
• Et l'ensemble des chapitres EDC PSC validés.

Exemple d’une copie écran attendue :

Image

Comme indiqué dans le DSR, l'habilitation EDC PSC Editeur (Editeur de logiciel utilisateur et Editeur de Proxy e-santé) est obligatoire et constitue un pré requis à votre référencement Ségur.

Dans le cas où vous n’avez pas obtenu l’habilitation Editeur de logiciel utilisateur et/ou l’habilitation Editeur de Proxy e-santé de l’EDC PSC à l’échéance de la Date 2 du guichet Ségur (date limite de dépôt d'un dossier complet), vous devez transmettre une capture d’écran de l’étape "Dépôt de preuves" du guichet EDC PSC Editeur devant obligatoirement afficher :

• Le numéro unique de référencement (NRU),
• Le nom de la solution,
• L'ensemble des chapitres soumis au moins une fois,
• La validation du chapitre « Prérequis maturité technique » et l’obtention de l’Autorisation d’accès aux environnements de test des acteurs de l’Espace de confiance.
  • A noter : l’atteinte de la Date 2 implique que ce chapitre « Prérequis maturité technique » ait été validé et que vous ayez obtenu cette Autorisation d’accès aux environnements de test des acteurs de l’Espace de confiance (utilisateurs et Proxy e-santé) afin que vous puissiez contractualiser avec le CNDA. Ce prérequis EDC PSC est ainsi nécessaire afin que vous soyez en mesure de déposer l’attestation d’homologation du CNDA attendue à la Date 2, ou à défaut le dépôt au CNDA de l'ensemble des éléments attendus du dossier de l'homologation concernée, tel qu'attesté par le CNDA (via une copie d’écran de son espace personnel CNDA mettant en visibilité la date de retour prévisionnelle) .

Exemple d’une copie d'écran attendue :

Image

La nouvelle version du scénario complète les informations à renseigner lors de la création de l'unité.

Ces ajouts ont été réalisés afin d'aligner le scénario de conformité avec les données attendues dans le cadre des spécifications d'interopérabilité

En complément de l'ID ROR, de la catégorie d'organisation et du mode de prise en charge, il est désormais demandé de renseigner :

• Le nom de l'unité
• L'accueil séquentiel ;
• La temporalité d'accueil.

Le scénario fournit également les valeurs attendues pour la démonstration :

• Identifiant ROR : 41/50616
• Nom de l'unité : Hébergement Complet Internat
• Catégorie d'organisation : 01 – Appartement thérapeutique en psychiatrie
• Mode de prise en charge : 46 – Hébergement (accueil jour et nuit)
• Accueil séquentiel : True
• Temporalité d'accueil : 02 – Permanent.

Les preuves attendues pour les exigences ANN/va1.02.01.02 et ANN/va1.03.01.02 dépendent du mode d'alimentation des correspondants mis en œuvre par votre solution.

Cas n°1 : alimentation par téléchargement de fichier

 Lorsque l'alimentation repose sur le téléchargement de fichier il est attendu de déposer un fichier de log permettant de visualiser a minima :

• le chargement des données ;
• le traitement réalisé ;
• le nombre total d'enregistrements traités ;
• une synthèse des résultats du traitement.

Ce fichier doit permettre de vérifier le bon déroulement du traitement d'import des correspondants.

Cas n°2 : alimentation via l'API FHIR

Lorsque l'alimentation repose sur l'API FHIR, les preuves attendues sont adaptées au mode de fonctionnement de cette interface.

Dans ce cas, il est attendu de fournir :

• un exemple de recherche unitaire d'un correspondant ;
• le retour de l'appel aux ressources FHIR issu de l'environnement de production.

Dans cette configuration, le dépôt d'un fichier de log n'est pas attendu, la preuve de conformité reposant sur les échanges FHIR réalisés avec le service.

Oui. Dans le cas d'un logiciel SaaS dont le numéro de version évolue entre le début du référencement et la fin du déploiement, il est possible de candidater sur une version N, d'obtenir le référencement sur une version N+1, puis de déployer une version N+2, à condition que cette dernière respecte les exigences de la version pour laquelle le référencement a été obtenu.

Toutefois, il est demandé à l'éditeur de déclarer tout changement de version auprès de l'équipe de référencement.

En règle générale, la compatibilité ascendante peut être considérée comme respectée en cas de changement de version mineure. En revanche, un changement de version majeure nécessite une analyse spécifique, notamment en raison des impacts potentiels sur certains contrôles, tels que les tests d'intrusion réalisés dans le cadre de l'Espace de Confiance Pro Santé Connect (EDC PSC).

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