Le plan d'assurance sécurité du système (PAS) est un document qui définit les mesures de sécurité et les engagements entre l'hébergeur et la structure utilisatrice pour l'environnement de mise en œuvre du système. Il vise à garantir la sécurité des données et des composants du système lorsqu'ils sont hébergés par un tiers ou fournis sous forme de services (SaaS).

La négligence dans la désignation des responsables de la sécurité peut entraîner un certain nombre de risques, notamment :

• Des failles de sécurité non détectées ;
• Des retards dans la réponse aux incidents de sécurité ;
• Un manque de coordination dans la gestion des risques ;
• Une faible sensibilisation à la sécurité au sein de l'équipe.

La désignation d'acteurs responsables de la sécurité apporte plusieurs avantages, notamment :

• Une meilleure gestion des risques de sécurité ;
• Une responsabilité claire pour les problèmes de sécurité ;
• Une amélioration de la coordination des activités de sécurité ;
• Une sensibilisation accrue à la sécurité au sein de l'équipe de développement ;
• Une conformité aux normes de sécurité.

La désignation des personnes responsables de la sécurité des produits nécessite les étapes suivantes :
- Identifier les exigences spécifiques de votre produit en matière de sécurité ;
- Évaluer les compétences et l'expérience des membres de votre équipe ;
- Désigner les responsabilités en matière de sécurité en fonction des compétences des membres de l'équipe ;
- Formaliser ces responsabilités dans un document dédié et les communiquer aux équipes.

Le choix du responsable de la sécurité dépend de la structure de l'éditeur. Cela implique d'identifier les personnes qui ont les compétences et l'expertise pour prendre en charge la sécurité de la solution. Il peut s'agir de responsables sécurité, de développeurs sécurité expérimentés, d'architectes sécurité, etc.

Oui. À compter de la délivrance de la conformité des prérequis CNDA, les tests doivent être engagés dans un délai de 3 mois, a minima sur le volet authentification.

En revanche, ce délai ne conditionne pas la finalisation de l’homologation, pour laquelle des délais supplémentaires peuvent être nécessaires.

Pour toutes questions relatives aux informations à renseigner dans la démarche contactez votre ARS.

Pour savoir comment compléter vous pouvez consulter les guides.
Pour toutes autres questions contactez-nous.

Des vidéos, interviews, témoignages et replays des webinaires de l’Agence du Numérique en Santé et de ses partenaires sont disponibles en suivant ce lien: https://esante.gouv.fr/webinaires.

Vous trouverez en suivant le lien suivant l'ensemble des webinaires passés et à venir (où vous pourrez vous inscrire).

Les éditeurs sont embarqués sur les travaux Ségur depuis fin 2020 et beaucoup des fonctionnalités exigées sont déjà embarquées dans les versions actuelles.

Beaucoup d'éditeurs, au vu des perspectives de financement, ont anticipé et monté des équipes de déploiement pour paralléliser les opérations de déploiement, de paramétrage et de formation.

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

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

Oui, l’ensemble des collaborateurs disposant d’un accès à la candidature ainsi qu’au produit rattaché à celle-ci peuvent consulter les échanges et les retours des référents de référencement.

Aucune action spécifique n’est nécessaire pour leur donner accès, en dehors du rattachement préalable au produit concerné. Des précisions sur cette configuration sont disponibles dans le guide utilisateur Convergence, notamment dans la dernière section dédiée à ce sujet : https://convergence.esante.gouv.fr/pictures/publish/22.

La réception des notifications par email dépend toutefois des préférences définies par chaque utilisateur, qui peut choisir d’activer ou non ce type d’alertes.

En cas de difficulté ou d’anomalie, les utilisateurs sont invités à contacter directement le support via la plateforme Convergence.