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

Les exigences ont pour objectif de vérifier si une sensibilisation générale aux enjeux et aux risques à la SSI est menée auprès des équipes du système (équipes de conception, de développement, d'installation, d'exploitation, d'administration, de maintenance, de support, etc.). Il est préconisé d'effectuer cette sensibilisation à minima annuellement pour l'ensemble des équipes et pour chaque nouvel arrivant. Cette sensibilisation peut être effectuée par des équipes de l'éditeur ou des prestataires qu'il choisit librement.
Dans le cas où le système est destiné à traiter des données à caractère personnel, alors la sensibilisation doit intégrer des obligations légales (en particulier le règlement général sur la protection des données) ainsi que des réglementations applicables.

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

Des recommandations sur la désignation des responsabilités en matière de sécurité sont fournies dans diverses ressources, notamment le guide d'hygiène de l'ANSSI, la PGSSI-S de l'ANS et la norme ISO 27002. 

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.

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.

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Toutefois, si votre solution est éligible au mécanisme d’équivalence des preuves, vous pourrez être exempté du dépôt de certaines preuves communes au dispositif candidat (par exemple : Médico-social DUI, Sage-femme / Paramédical), dès lors que vous avez déjà obtenu un référencement Vague 2 sur un autre dispositif comportant ces mêmes exigences. Pour cela, vous pouvez consulter la matrice d'équivalence correspondant à votre couloir candidat sur le site de l'ANS. 

Pour un utilisateur, la gestion de l'envoi de documents vers le Dossier Médical Partagé (DMP) et la Messagerie Sécurisée de Santé (MSS) depuis un logiciel s'effectue par une interface conçue pour être à la fois automatisée et personnalisable. L'objectif est de simplifier au maximum le processus tout en respectant les obligations légales et les situations spécifiques des patients.

Envoi de documents au DMP
L'envoi automatisé d'un document au DMP est défini dans l'onglet "Liste des documents Ségur" du Référentiel d'Exigences (REM) de votre dispositif et le document est visible par le patient.
Cette configuration par défaut est non modifiable de façon globale par l'utilisateur, ce qui garantit le respect de l'obligation légale d'alimentation du DMP (Article L. 1111-15 du Code de la santé publique précisé par l’arrêté du 23 mai 2024).

Toutefois, le professionnel de santé dispose de deux options pour gérer l'envoi et la visibilité d'un document au cas par cas :

• Ne pas envoyer un document : L'utilisateur a la possibilité de ne pas envoyer un document au DMP si le patient s'y oppose pour un motif légitime (motif légitime ne nécessitant pas de traçabilité et laissé à l’appréciation du professionnel)
• Modifier la visibilité : Le professionnel peut rendre un document invisible au patient (dans l'attente d'une consultation d'annonce pour un diagnostic grave) ou à ses représentants légaux (Le respect du secret médical pour un mineur ne souhaitant pas que ses parents soient informés de certains soins.)
• Cas particulier « Modèles de documents »
  • Pour optimiser le processus de production documentaire, le professionnel pourrait pré-paramétrer des modèles de documents et leurs conditions de visibilité. Par exemple, un professionnel peut créer un modèle de « compte-rendu d'expertise judiciaire » et le configurer pour que son envoi au DMP soit désactivé par défaut.

Envoi de documents par MSS professionnelle
l'envoi des "documents Ségur" vers la MSS professionnelle est également défini dans l'onglet "Liste des documents Ségur" du REM. Ces documents sont systématiquement transmis, à minima, au Médecin Traitant (MT) et au professionnel adresseur.
Le professionnel de santé peut modifier ou amender la liste des destinataires ou les paramètres d'envoi si besoin.

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

Effectivement cette étape du scénario ne sera pas prise en compte dans l’étude des preuves.

Le critère voie/rue n’est pas inclus dans les points de contrôle du référencement pour cette exigence.

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).