Rapport sur les résultats
Consultation 2015/88: Droit d'exécution concernant la loi fédérale sur le dossier électronique du patient (LDEP) · 127 pages
Fedlex · Rapport sur les résultats · Page 89Fedlex · Rapport sur les résultats
besoin de définir de procédure de déclaration par les communautés. SQS propose dès lors que l’on supprime l’élément de texte « l’organisme de certification et » du ch. 4.13.1. ISSS observe que selon les dispositions en vigueur dans d’autres contextes, p. ex. dans le RGPD-UE, les informations sur des incidents affectant la sécurité des données doivent être aussi communiquées aux patients s’il s’avère qu’il existe probablement un risque élevé. Le ch. 4.13.1 doit dès lors être complété de la phrase suivante : « […] Par ailleurs, les communautés doivent définir une procédure formelle pour déclarer immédiatement des événements de sécurité aux patients concernés qui se retrouvent probablement exposés, par suite d’une violation de la protection de leurs données personnelles, à un risque élevé pour leurs droits et leurs libertés. »
4.14 Sécurité d’exploitation (al. 3)
4.14.1 : HIN relève à propos du ch. 4.14.1.1.1 qu’il s’agit d’une forte authentification à deux facteurs, fait qu’il convient de saluer. SQS veut savoir à ce propos à partir de quel point une authentification à deux facteurs peut être qualifiée de forte, et demande des précisions à ce sujet. Au sujet du ch. 4.14.1.1, KSSG fait savoir que la mise en place d’une authentification à deux facteurs pour un système d’exploitation, mais surtout pour une base de données et d’autres composants techniques, est considérée comme disproportionnée et difficilement réalisable. Cela signifierait que tous les utilisateurs dans l’Active Directory devraient se soumettre pour chaque objet (même hors contexte du dossier électronique du patient) à une authentification à deux facteurs, ce qui serait à la fois extrêmement coûteux et surtout plus du tout praticable pour l’exploitation. Suivant la banque de données, une authentification à deux facteurs est même impossible à mettre en place. Le ch. 4.14.1.1 doit par conséquent être supprimé. STSAG craint également que les dispositions des ch. 4.14.1.1 et 4.14.1.3 à 4.14.1.10 occasionnent des coûts inadéquats et demande que l’on supprime purement et simplement ces dispositions. Dix participants129 signalent que dans le texte allemand du ch. 4.14.1.1.2, une phrase est incomplète et qu’il y manque au moins un mot. Ce texte doit être complété. HIN propose concrètement d’introduire ici le mot « système ». Six cantons130 voient difficilement comment on peut garantir qu’un système ne permettra pas d’exporter des données de patients alors qu’un accès privilégié permet de consulter ces mêmes données. Cet accès privilégié repose sur le secret professionnel. Ces cantons demandent la suppression du chiffre 4.14.1.1.3. ISSS considère que le ch. 4.14.1.2.3 est éloigné des réalités pratiques. Dès lors que le fournisseur doit garantir l’infrastructure et donc son fonctionnement permanent, on ne peut pas attendre un « cas de besoin » pour activer un accès. Cela empêcherait d’honorer des SLA (cf. 4.23.1.2). Ils demandent donc la suppression de ce chiffre. ISSS propose également de préciser au ch. 4.14.1.4 : « […] et qu’elles sont cryptées et conservées en un lieu sûr et physiquement séparé. ». À propos du ch. 4.14.1.5, ISSS reproche à cette disposition son manque de clarté et demande ce que l’on entend ici par « principe du double contrôle ». Il suppose probablement que le mot de passe est connu de plus d’une personne, mais les modalités d’implémentation technique doivent absolument être expliquées, sinon il vaut mieux renoncer à cette disposition. Pour ce qui est des ch. 4.14.1.4 et 4.14.1.5, KSSG considère qu’il n’y a pas de proportionnalité entre le cryptage des back-up et l’accès au matériel de cryptage en application du principe du double contrôle. Il faudrait édifier une infrastructure de back-up séparée pour le dossier électronique du patient, ce qui occasionnerait des coûts énormes. Il convient donc de reformuler ces chiffres pour obliger les exploitants informatiques à conserver les back-up en lieu sûr, à charge pour eux de trouver des solutions pratiques concrètes. HIN rappelle que les tâches exigées au ch. 4.14.1.7 seront automatisées si un fournisseur reprend l’exploitation de l’infrastructure informatique et y effectue régulièrement des sauvegardes. Une séparation physique du lieu de stockage est donc irréaliste vu qu’elle impliquerait des opérations manuelles. On peut donc biffer ce chiffre. VAKA souhaite également la suppression de ce chiffre, étant donné que l’exigence (déconnexion du réseau pendant le back-up) est sans doute excessive. La Poste trouve aussi que la déconnexion du réseau est une mesure exagérée. Les back-up sont déjà cryptés et les clés de cryptage protégées selon le principe du double contrôle. SCH relève à ce propos qu’en règle générale, on ne prévoit plus de systèmes de stockage de back-up à déconnecter du réseau après la copie, parce que le stockage de données selon les cri-
129 CCM, BüAeV, GAeSO, KAeG SG, HIN, La Poste, privatim, medshare, Medgate, SQS
130 FR, NE, GE, VS, VD, JU