FAQ des industriels

L’article L.1111-8 du code de la santé en public distingue trois grandes catégories de services d’hébergement de données de santé :

• l’hébergement de données de santé sur support papier dans le cadre d'un service d'archivage, qui doit être réalisé par un hébergeur agréé par le ministre de la culture ;
• l’hébergement de données de santé sur support numérique (hors cas d’un service d’archivage électronique) qui doit être réalisé par un hébergeur certifié HDS ;
• l’hébergement de données de santé sur support numérique dans le cadre d’un service d’archivage électronique, qui doit être réalisé par un hébergeur certifié HDS et agréé par le ministre de la culture dans des conditions qui seront définies par décret en Conseil d’Etat pris après avis de la Commission nationale de l’informatique et des libertés et des conseils des ordres des professions de santé.

Exemple de cas d'usage : les coffres forts numériques où l'utilisateur peut stocker des données de santé à caractère personnel.

Il s'agit des activités de suivi réalisées par les établissements et services sociaux et médico-sociaux. Ces établissements et services sont listés de façon exhaustive à l’article L.312-1 du code de l’action sociale et des familles.

Les activités de prévention mentionnées dans le CSP sont les actions menées afin éviter l’apparition ou l’aggravation de maladies. Les principales catégories d'activités de prévention incluent :

1. la prévention primaire : ces activités visent à éviter l'apparition de maladies ou d'incidents de santé en réduisant les facteurs de risque. Cela peut inclure : 

• les vaccinations,
• les campagnes de sensibilisation (i.e. tabagisme, alimentation, prévention des maladies cardiovasculaires),
• d'éducation à la santé (promotion des comportements favorables à la santé comme l’activité physique, lutte contre la sédentarité, éducation sur la santé mentale, etc.) ;

2. la prévention secondaire : elles concernent le dépistage précoce de maladies ou de conditions afin de les traiter rapidement. Par exemple, le dépistage prénatal, le dépistage néo-natal, dépistages des troubles du développement, le dépistage pour certains cancers ou maladies chroniques, etc ;

3. la prévention tertiaire : ces actions visent à diminuer les complications ou les séquelles d'une maladie déjà installée, souvent en rapport avec des soins ou du suivi de rééducation après un incident de santé ou une intervention médicale (réadaptation), sont concernés les programmes d’éducation thérapeutique du patient (diabète, hypertension, etc.).

Toutes ces activités peuvent nécessiter, par différents moyens, la collecte et l'hébergement de données personnelles de santé.

L’hébergeur doit être certifié sur toutes les activités qui constituent son offre (y compris sur les activités de son offre sous-traitées).

La responsabilité conjointe de traitement déclarée entre deux organismes ne fait pas disparaître l'obligation de certification HDS si les autres conditions sont remplies. En effet, dans la mesure où la détermination de la responsabilité conjointe de traitement relève de leur appréciation, on ne peut pas considérer qu'ils pourraient décider de se soustraire à l'obligation de certification, par cette seule décision.

L’article L.1111-8 du code de la santé publique dispose que : « Toute personne physique ou morale qui héberge des données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social ou médico-social pour le compte de personnes physiques ou morales à l'origine de la production ou du recueil de ces données ou pour le compte du patient lui-même, doit être agréée ou certifiée à cet effet ».

Certaines activités d'hébergement ne rentrent pas dans le périmètre établit à l'article L.1111-18 du Code de la santé publique. Il s'agit de (liste non exhaustive) :

• des organismes d’assurance maladie obligatoire et complémentaire dans le cadre de leur activité de prise en charge des frais de santé ; ces organismes manipulent des données de santé mais ils n’en sont pas à l’origine ;
• des organismes de recherche dans le domaine de la santé lorsque leurs bases de données ne sont pas initialement constituées à des fins de prévention, de diagnostic, de soins ou de suivi social et médico-social ;
• des associations qui proposent des activités sportives à des personnes en situation de handicap. Ces associations manipulent des données de santé mais elles n’en sont pas à l’origine.

L’obligation de disposer d’un certificat de conformité mentionnée à l’article L.1111-8 du code de la santé publique s’applique à toute entité qui propose un service d’hébergement : 

1. portant sur des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social ; 
2. pour le compte du patient ou pour le compte des professionnels de santé, des établissements et services de santé et tout autre organisme réalisant des missions de prévention, de soins, de suivi médico-social et social à l’origine de ces données.

Ces conditions sont cumulatives et l'obligation s'applique à toute personne (physique ou morale), qu’elle relève du droit public ou du droit privé.

Tout professionnel de santé, tout établissement et service de santé et tout autre organisme réalisant des missions de prévention, de soins, de suivi médico-social et social (personnes physiques ou morales) doit apprécier au cas par cas si ces données de santé dont il entend confier l’hébergement à un tiers proviennent de  son activité de prévention, de diagnostic, de soins ou de suivi social et médico-social.

En outre, tout projet de système d’information (SI) portant sur l’exploitation des données susmentionnées nécessite de s’interroger au cas par cas sur l’application de la législation relative à l’hébergement des données de santé. Il incombe donc au responsable du système d’information de veiller au respect de cette législation dès que l’une des fonctionnalités du SI concerne des données de santé répondant aux critères ci-dessus.

Par exemple, un établissement de santé exploitant un DPI est tenu de recourir à un hébergeur certifié HDS en cas d’externalisation de l’hébergement de ce DPI. 

Le règlement européen sur la protection des données personnelles donne une définition depuis avril 2016. Ce sont les données relatives à la santé physique ou mentale d'une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l'état de santé de cette personne.

Des précisions sont apportées par la CNIL.

Le test doit être daté de moins d'un an.

Le mode d'hébergement est pris en compte au niveau des exigences SSI ainsi que des points de contrôle du test d'intrusion dans le cas où un industriel ou un tiers sous sa responsabilité assure l'hébergement de tout ou partie des composants du système, ou fournit tout ou partie du système sous forme de service (SaaS).
En revanche, les OS ne sont pas pris en compte dans les exigences SSI.

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.

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 les rôles et responsabilités de l'équipe.

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

L'exigence a 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 responsabilité de la rédaction du plan d'assurance sécurité du système peut être partagée entre l'éditeur et l'hébergeur ou le fournisseur de services SaaS, en fonction des accords contractuels. Cependant, il est essentiel que ce plan soit clairement et doit contenir : 

• Le cadre juridique : les références légales, les réglementations et les obligations contractuelles liées à l'hébergement du système, en précisant les responsabilités et les droits des parties impliquées, etc. ;
• Les mesures de sécurité : les dispositions et les procédures de sécurité mises en place pour protéger le système hébergé (ex: contrôles d'accès, protection des données, etc.) ;
• Les engagements entre l'hébergeur et la structure utilisatrice comme par exemple des garanties de disponibilité, des délais de réponse en cas de problème, des mesures de résilience en cas de panne, etc. ;
• L'environnement de mise en œuvre du système : il s'agit de décrire l'environnement technique et opérationnel dans lequel le système doit être déployé (ex: configuration réseau, connectivité, etc.). 

Un "standard de développement sécurisé" est un ensemble de lignes directrices, de bonnes pratiques que les développeurs devraient suivre pour garantir la sécurité d'un système. Il peut provenir de différentes sources (ex : guide de l'ANSSI, documentation interne, OWASP, PGSSI-S, etc.). Il comprend des recommandations sur la vérification de la qualité du code, la gestion de l'obsolescence des bibliothèques, la sécurisation de la plateforme système, et bien d'autres aspects liés à la sécurité. Il est essentiel car il permet de réduire les vulnérabilités potentielles, les failles de sécurité et les risques de cyberattaques, assurant ainsi la sécurité du système.