Questions fréquentes

La base des établissements éligibles mis à disposition sur le site (accessible au lien suivant) de l’Agence du Numérique en Santé précise l’activité de chacune des entités géographiques associés à une entité juridique éligible au domaine. Les candidats sont invités à utiliser ces données pour vérifier que le périmètre d’entité considéré pour la réalisation des BIA / PCRA est conforme à l’objectif de 66% d’activité combinée définie pour les objectifs D2.O1.C et D2.O1.D. 

Non. Les audits ne font pas partie des objectifs du programme et ne sont donc pas éligibles à un financement. Elles constituent une réponse à un besoin global de continuité et de reprise d'activité mais n'agissent pas directement sur les capacités opérationnelles du candidat et l’atteinte des objectifs du domaine 2.  

La règle 3-2-1 n'est pas garantie si les copies sont réalisées sur une même technologie altérable, en ce qu’elle repose sur la diversité effective des mécanismes de sauvegarde. Le candidat doit démontrer l'existence d'au moins 2 supports réellement différents, d'une copie immuable et d'au moins une copie hors site / hors ligne.  Ainsi la présence d'un site de secours ou d'un cloud ne suffit pas si les 3 copies reposent sur des solutions modifiables ou exposées aux mêmes risques. Les candidats doivent démontrer la complémentarité des supports et la robustesse de son schéma face aux cyberattaques. 

Une réplication n'est pas une sauvegarde dans la mesure où elle reproduit immédiatement toute modification ou corruption. Elle ne permet donc de revenir à un état antérieur. 
Le 3-2-1, exige des copies indépendantes du système de production, la possibilité de restaurer un état antérieur, d’être stockée sur un support distinct, d’être immuable et ne pas être automatiquement modifié par les opérations de production.  Aussi, la mise en place d’un système de réplication ne permet pas de répondre aux objectifs du domaine et ne constitue pas une dépense éligible. 

Pour rappel, les candidats doivent définir une trajectoire de mise en œuvre du 3-2-1 mais son opérationnalisation n’est pas attendue dans le cadre de l’objectif D2.O3.C. Ainsi, les candidats ne sont pas tenus de soumettre des preuves relatives à l’immuabilité des copies. 

Il est rappelé que l’immuabilité est obtenue par la concomitance de plusieurs dispositifs. A titre d’exemple, les situations suivantes ne permettent pas de garantir une immuabilité des copies : une procédure organisationnelle sans justification technique, un support en coffre-fort sans verrouillage logiciel ou matériel, une sauvegarde externalisée mais modifiable (pas de WORM / Object Lock). 
L'établissement doit donc s’engager dans une trajectoire associant une contrainte technique en complément de contrainte organisationnelle afin d’empêcher toute altération prématurée. 

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