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

• Est considérée comme donnée sensible toute donnée à caractère personnel, qu'elle soit ou non de santé ou bien toute information participant à la sécurité du système d'information constitué par le système ou auquel il participe.
• Est considérée comme opération sensible tout déclenchement d'action susceptible d'induire directement ou indirectement l'enregistrement, l'affichage, la transmission, la modification ou l'effacement d'information sensible, sauf à ce que l'analyse de risque du système ait spécifié que l'action considérée sur les informations considérées n'était pas porteuse d'enjeu particulier, tout déclenchement d'action susceptible d'induire des effets négatifs sur la santé de patients et tout autre déclenchement d'action identifiée par l'analyse de risque du système comme devant faire l'objet de mesures de protection et/ou de contrôle renforcées. 

Une application client-serveur fait référence à une architecture désignant la séparation des tâches d’une application entre deux entités distinctes et cloisonnées. Le côté client désigne l’ensemble des composants logiciels manipulés par les utilisateurs. Le côté serveur désigne l’ensemble des composants logiciels responsables des traitements, c’est-à-dire l’implémentation de la logique métier, et de l’accès aux données.

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.

Oui, le bon de commande, et ses éventuelles annexes, doit avoir fait l’objet d’un accord explicite du Client final, par la signature du responsable, celle-ci pouvant être manuscrite ou électronique : signature avec certificats CPx, signature avec identification électronique par Pro Santé Connect, signature par certificat logiciel RGS, signature électronique de niveau minimum eIDAS simple

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement.

 En effet, les prescripteurs peuvent parfois disposer d'une BAL nominative (adresse MSS personnelle) ainsi que d'une BAL organisationnelle (boite de service, pouvant être utilisée par plusieurs professionnels
d’un même service). Dans ce cas, il convient d'enregistrer les deux correspondants : le prescripteur et le service ou établissement.

Le SGL doit faire 1 et 2, pour faire face à toutes les situations :

1. capable de fournir ‘directement’ au client une alimentation DMP
   • soit le SGL alimente directement le DMP, il faut que le SGL apporte sa propre homologation CNDA ;
   • soit le SGL a une PFI (‘module’) sous-traitant qui s’en charge (PFI invisible pour le client), il faut alors qu’il apporte l’homologation CNDA du sous-traitant (et nous donne quelques éléments sur son interconnexion en sortie avec son ‘module’) lors du référencement de l’ensemble [SGL + module] (1 seul référencement) ;
     
     et
      
2. capable de laisser l’hôpital gérer les envois au DMP avec la PFI de l'hôpital (non choisie par le SGL, mais préalablement choisie par l’hôpital). Il n'appartient pas au SGL de s'assurer que la PFI est référencée Ségur. Le SGL n’a aucune homologation CNDA à apporter dans ce cas. Le SGL doit en revanche prouver qu’il sait envoyer les CR par des messages ORU (qui seront routés par la DSI vers la PFI hospitalière)