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

Les tests relatifs au PCA sont spécifiques et visent à mettre en pratique les processus opérationnelles de continuité et de reprise d'activité au niveau des services. L’obligation de réalisation d’un exercice de crise cyber ne peut donc pas être remplie par la réalisation d’un exercice de terrain du PCA. 
La seule réalisation d'un exercice de crise cyber ne permet donc pas la validation de l'objectif D2.O1.D : le candidat doit simuler un risque d'indisponibilité au sein des services, et activer les processus de continuité d'activité. Le candidat peut en revanche mutualiser l’exercice de crise cyber et le test PCRA, dès lors que l’exercice couvre explicitement les attendus propres à chacun de ces dispositifs. 
Par ailleurs, la validation de l'objectif D2.O1.D repose sur (i) la formalisation d'un retour d'expérience suite à l'exercice incluant un plan d'amélioration du PCA, et (ii) la soumission d'un planning de réalisation des tests sur l'ensemble des activités critiques. 
Des kits d’exercices de crise cyber prêts à l’emploi sont disponibles sur le site de l’ANS au lien suivant :
https://esante.gouv.fr/strategie-nationale/cybersecurite/axe-1
Il est en revanche possible de réaliser simultanément un exercice de cybercrise (dans le format connu, et notamment exigé au titre du Domaine 1) et un exercice de continuité d'activité au sein des services. 

Le candidat doit réaliser un BIA et un PCRA (en réponse à l’objectif D2.O1.C) sur chacun des périmètres a minima (i.e. un service de soin, un plateau technique, le processus administratif le plus critique) couvrant au moins 66% de son activité combinée (analysée à la maille des structures juridiques pour les candidats GHT, et de la maille des structures géographiques pour les autres candidats). 
Il est à noter que les entités considérées par le candidat pour la réalisation du BIA / PCRA peuvent différer selon les périmètres. Les activités considérées pour chacun des périmètres peuvent être différentes d’un établissement à l’autre (par exemple, il est possible au titre du BIA/PCRA sur un service de soin de considérer (i) le service d’oncologie sur une entité, et (ii) le service de cardiologie pour une autre entité). 

L’ensemble des dépenses réalisées pendant la phase opérationnelle pour contribuer à l’atteinte des objectifs du Domaine 2 sont éligibles à un subventionnement – y compris les coûts de formation À titre d’exemple, le recours à la prestation externe, l’acquisition d’un SMCA ou encore la mise en œuvre d’un nouveau système de sauvegarde sécurisée sont éligibles – étant entendu que cette liste n’est pas exhaustive. Il est à noter que l’ensemble des dépenses réalisées durant la phase opérationnelle concourants à l'élaboration du PCRA seront éligibles, y compris si le périmètre dépasse le périmètre minimal défini dans les objectifs qui ne constitue pas une limite. 
En ce qui concerne les objectifs visant à « s’inscrire dans une démarche », les investissements opérationnels réalisés pour définir cette démarche ou la mettre en œuvre sont bien valorisables au titre de l’AAF domaine 2. 

Les coûts associés à la mobilisation des ressources humaines du candidat sont également éligibles. Néanmoins, il est à souligner que ces coûts doivent être explicitement justifiés au regard des activités du programme. Aussi, nous recommandons aux établissements de favoriser les dépenses associées à des travaux de prestation intellectuelle, d’acquisition de solutions informatiques, ou des coûts RH associés à la mobilisation de personnels disposant d’une lettre de mission dans le cadre du Domaine 2.  

Pour plus de précisions, les candidats sont invités à consulter le guide des dépenses éligibles mis à disposition par l’Agence du Numérique en Santé : 
https://esante.gouv.fr/sites/default/files/media/document/Guide des de%CC%81penses e%CC%81ligibles domaine 2_v1.0_0.pdf

En complément, il est rappelé que les candidats devront renseigner, signer et soumettre la trame des éléments financiers également mise à disposition sur le site de l’ANS : 
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fesante.gouv.fr%2Fsites%2Fdefault%2Ffiles%2Fmedia_entity%2Fdocuments%2F20260128---trame-financiere-v1.0.xlsx&wdOrigin=BROWSELINK

Le BIA est réalisé a minima sur le périmètre suivant : (i) un service de soins ayant un impact majeur sur la prise en charge du patient, (ii) un plateau technique en lien avec le parcours de soins, et (iii) le processus administratif / support le plus critique pour l’établissement. Les candidats ne disposant pas d’un plateau technique sont invités à réaliser un BIA / PCRA sur un 2nd service de soins ou le cas échéant, sur un 2nd service administratif / support s’il ne dispose que d’un service de soins (voir réponse à la question 4.15). 
Le candidat est invité à réaliser un document descriptif des activités décrites du périmètre à minima, et pourra le cas échéant y intégrer des contenus qu’il aurait déjà décrits dans les BIA. 

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.