Rapport sur les résultats

« 4.7.5 Pour soutenir la gestion des failles de sécurité, les communautés doivent faire effectuer un test de pénétration du système par un prestataire indépendant au moins une fois par année ». VAKA approuve le principe des mesures proposées au ch. 4.7, mais considère que guetter en permanence toutes les failles de sécurité de l’ensemble des logiciels constitue une charge relativement lourde. De plus, il s’agit souvent de logiciels « closed source », de sorte qu’en règle générale, une faille de sécurité restera de toute manière inconnue.

4.8 Gestion des données et des systèmes sensibles (al. 1, let. c et d)

K3, VZK, ZAD ainsi que NW et ZH trouvent cette réglementation trop détaillée pour une utilité pratique somme toute faible, et souhaitent une simplification du ch. 4.8.

4.8.1 : Six cantons¹¹⁶ font remarquer que cela fait partie de l’obligation de diligence à laquelle les professionnels de la santé sont tenus, comme d’ores et déjà dans la pratique actuelle. Bleuer fait valoir que la pertinence pour le traitement du patient ne peut pas être définie a priori. VAKA considère que la décision visée au ch. 4.8.1 doit être prise par les professionnels de la santé sur la base d’une évaluation de cas en cas. KSSG demande comment répondre à ces exigences si aucune directive ne dit quelles sont les données pertinentes pour le traitement. Dans le même ordre d’idées, BINT et Integic demandent comment comprendre la notion de « pertinence pour le traitement » dans ce contexte et suggèrent que la manière dont elle est perçue doit varier considérablement. La SSIM trouve elle aussi que la notion de « pertinent pour le traitement » est trop vague et demande une définition plus concrète, comme elle l’avait fait dans son avis sur le projet de loi de 2011. VGIch critique également le fait que l’on ignore quelles données et quels documents il faut considérer comme pertinents. Pas moins de neuf participants¹¹⁷ demandent la suppression pure et simple du ch. 4.8.1, tandis qu’Integic et KSSG accepteraient qu’on lui apporte les précisions nécessaires. VGIch propose que l’OFSP fournisse un modèle non contraignant de « Best Practice » pour la mise à disposition de fichiers par les hôpitaux. OFAC demande comment les communautés pourraient garantir quoi que ce soit concernant les institutions affiliées. Qui assurerait le contrôle dans le temps, comment et de quel droit ? Les tâches des communautés sont décrites de manière exhaustive à l’art. 10 LDEP. Les institutions affiliées sont, indépendamment de leur affiliation, soumises au droit suisse de la protection des données. Il faut, de plus, noter que le droit auquel les institutions sont soumises dépend de leur nature juridique.

4.8.2 – 4.8.4 : La Poste réitère pour le ch. 4.8.2. sa prise de position à propos du ch. 4.5. Six cantons¹¹⁸ signalent que dans la version française, le terme « sensible » utilisé au ch. 4.8.2 n’a pas le même sens qu’aux art. 1 et 2 ODEP ou dans la LDEP et qu’il faut dès lors clarifier ce terme. La CCM, BüAeV, GAeSO et KAeG SG observent que là encore, le texte allemand parle de « schützenswerte Daten » (traduit en français par « données sensibles ») sans que cette notion ait été définie. Il en résulte un flou juridique. Ces intervenants suggèrent de fournir ici une définition légale. Integic voit dans le ch. 4.8.3.8.1 l’obligation pour chaque acteur IHE d’utiliser son propre certificat client et demande dès lors que cette règle soit précisée. KSSG relève à ce sujet que la mémorisation du certificat client TLS dans l’inventaire est un processus incertain. Les certificats clients doivent être conservés dans un endroit sécurisé. KSSG souhaite donc que ce chiffre soit supprimé ou reformulé. L’inventaire ne doit contenir que le nom du certificat client, mais non le certificat lui-même. Six cantons¹¹⁹ estiment que la communauté ne peut tenir un inventaire de milliers de systèmes primaires utilisés, pas plus qu’elle n’est en mesure de fournir des indications sur le certificat TLS installé sur ces systèmes. Ils demandent la suppression du ch. 4.8.3.8. SQS n’arrive pas à comprendre le sens du ch. 4.8.4.3. On ignore à la lecture de quelle confirmation il s’agit, il faut que cela soit précisé dans le texte ou alors qu’il soit reformulé. ahdis demande que le ch. 4.8.3.8.1 utilise les désignations plus précises de « Serial ID, HASH du certificat client TLS » en lieu et place de « certificat client TLS » afin de limiter le risque d’abus. OFAC observe qu’il manque dans la liste les interfaces entre la communauté et le reste du