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

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute la procédure les phases de la procédure de conformité.

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

Cette phase a pour finalité d'échanger sur le rapport du test d'intrusion, notamment si des manquements aux règles de sécurité sont détectées. L'auditeur devra communiquer les résultats du test d'intrusion à l'éditeur en clarifiant les points suivants :

• Les détails techniques des vulnérabilités identifiées ;
• L'impact potentiel des non-conformités aux règles de sécurité et le niveau de risque associé ;
• Les solutions concrètes permettant de corriger les potentielles failles ;
• La définition des prochaines étapes (définition d’une date permettant d’évaluer de nouveau les vulnérabilités recensées).

Le contenu des traces fonctionnelles attendues est défini par l’exigence SC.MSS/CONF.18.
L’objectif est de permettre un suivi des actions significatives réalisées sur les boîtes aux lettres MSSanté, sans conserver l’intégralité des échanges IMAP/SMTP ni le contenu des messages.

Ainsi, pour chaque boîte aux lettres, il est attendu a minima que les traces permettent de connaître :

• l’identifiant de l’auteur de l’action, dûment authentifié ;
• l’horodatage local du poste au moment de l’action ;
• le type d’action réalisée (consultation, envoi, suppression, etc.) ;
• la demande effectuée sur le serveur de messagerie MSSanté ;
• la réponse fournie par le serveur (y compris en cas d’échec).

Le contenu des messages ne doit en aucun cas être tracé. Le choix du niveau de détail des traces et des traitements suivis est laissé à l’appréciation de l’éditeur, dans la mesure où ces traces visent avant tout à le protéger, notamment en cas de requête judiciaire ou d’incident de sécurité. Il est toutefois attendu a minima que les actions d’envoi et de suppression de messages soient tracées.

Concernant la durée de conservation :

• Comme indiqué au §5 du référentiel #2 MSSanté, une durée de conservation de 6 mois est recommandée pour ces traces fonctionnelles.
• Le responsable de traitement (LPS) reste libre de définir la durée exacte de conservation, en fonction de son analyse de risques et de son cadre réglementaire.
• Les traces doivent être soumises aux mêmes mesures de sécurité et de confidentialité que les données MSSanté auxquelles elles se rattachent (mesures organisationnelles, techniques, etc.).

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.

La phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.  

Les modalités de traitement des modifications de structures sont décrites dans les AF.

Pour un utilisateur, l'administration 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
Par défaut, l'envoi d'un document au DMP est automatique 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" (cf onglet « Liste des documents Ségur » du REM vers la MSS professionnelle est également automatique par défaut. 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.

Les durées de conservation sont une responsabilité du responsable de traitement.

En tant qu'éditeur, vos logiciels doivent être capables de gérer deux durées de conservation distinctes :

• Les traces techniques (ex. logs d'erreurs, événements système) pour le support et la maintenance du logiciel, conservées sur une courte période de 6 mois à 1 an (recommandations CNIL).
• Les traces applicatives (ex. journaux d'accès aux dossiers patients) pour des raisons légales et de traçabilité, conservées sur une longue période de 20 ans, conformément à la durée de conservation des dossiers médicaux (article R.1112-7 du code de la santé publique).

Ces traces constituent des données à caractère personnel et il faut donc prévoir des mesures de sécurité adaptées à cette longue durée de conservation, ainsi qu’une information adaptée (par exemple, via les conditions générales d'utilisation (CGU) ou la politique de confidentialité) du responsable de traitement, voire une capacité d’adaptation des durées par ce dernier.