FAQ des industriels

Un TSP est un fournisseur de services de confiance qui fournit des certificats numériques utilisés pour authentifier et sécuriser les signatures électroniques.

Une application standalone est un logiciel embarquant l’ensemble des composantes nécessaires à son fonctionnement, et en particulier le traitement et l'implémentation de « l’intelligence » du logiciel, responsable de toute la logique métier et garant du fonctionnement de l’application et la gestion du stockage des données.

Le client effectue des contrôles sur la taille des entrées de l'utilisateur afin de prévenir les attaques par débordement de mémoire tampon. De plus, toutes les entrées de l'utilisateur dans le client lourd doivent être nettoyées pour éviter les injections de commandes (commandes arbitraires visant le système d'exploitation par l'intermédiaire de l'application). Par ailleurs, l'utilisation d'un serveur d'application est nécessaire pour éviter l'accès à la base de données directement à partir du client lourd.

Le test d'intrusion concerne toutes les solutions, incluant les applications web et mobiles, les clients lourds de trois tiers ou plus et les clients lourds inférieurs à trois tiers. Le guide d'utilisation propose une classification explicite à travers un logigramme : une application est considérée comme web si elle fonctionne sur un serveur web ou est accessible via un navigateur. En revanche, si elle est spécifiquement conçue pour les appareils mobiles, elle est classée comme une application mobile. Si aucune de ces catégories ne s'applique et qu'une installation locale est nécessaire, elle est alors répertoriée comme un client lourd. 

Deux types de clients lourds sont à distinguer : un client lourd est qualifié de trois tiers ou plus s'il intègre un serveur d'application par lequel transitent tous les flux, sinon il est considéré comme moins de trois tiers.

Non, l'exigence PGSSI-S IEU 2 n'est pas applicable lorsque la solution est esclave de l'identité.

Il doit être possible de voir la création ou le résultat de la création d’un patient dans la solution avec son identifiant privé et ses 5 attributs. Il doit être possible aussi de visualiser que ce patient est associé à son INS, même si peut être les étapes du scénario de conformité sont faites en même temps.

Il faudrait donc, s’il n’est pas possible de visualiser la création d’un patient via la GAP, avoir le flux de création permettant de créer le patient et celui pour associer l’INS dans la solution (si différent), puis d’avoir une copie écran d’un compte usager associé à son matricule INS.

NB : Attention à ne pas confondre  la création de l'identité (au niveau de la GAP) et la création du compte dans le DMN. Si la solution ne permet pas l'accès à la GAP, cela signifie qu'il ne peut récupérer l'identité.

Comme noté à la page 14 du référentiel 1.2.2 : « Le Référentiel d’Interopérabilité et de Sécurité des Dispositifs Médicaux Numériques (DMN) exige une méthode d’authentification des usagers à 2 facteurs. Le Système doit donc implémenter cette méthode d’authentification (exigence IEU 9.1). » Le développement de la double authentification est donc obligatoire pour un DMN s'il y a un accès patient, et c’est une exigence qui sera vérifiée par l’ANS.

Par contre, il est également indiqué : « Pour tenir compte du cas où l’activation de l’authentification des usagers à 2 facteurs diminue l’usage de la solution et entraîne une perte de chance pour l’usager, le fabricant du DMN peut sous sa responsabilité ne pas activer systématiquement l’authentification à deux facteurs. ». Cela signifie que l’activation du double facteur peut ne pas être systématique pour l’ensemble des patients. Ce point est de la responsabilité de l'entreprise du numérique en santé développant le DMN.

Enfin, il est précisé dans le scénario IEU 9.1 : « L'accès du patient à une interface de déclaration simple dans le cadre d'un parcours de télésurveillance n'est pas soumis à ce scenario de conformité et ne nécessite pas d'authentification à deux facteurs systématique. » . Cela signifie que dans le cadre d’une déclaration simple, c’est-à-dire dans le cas où un patient accède à un simple formulaire de saisie de données (hors du DMN),  il n’est pas soumis au développement du double facteur.

Le référentiel d’identification électronique se borne à faire en sorte que les identifiants utilisés pour les usagers soient des identifiants uniques et sectoriels de préférence. Il n'existe aujourd'hui aucune exigence qui encadre ce cas de figure, même si la qualité de l’identification d’un usager est l’un des principes fondamentaux de la qualité et de la sécurité de sa prise en charge.