Rapport sur les résultats

4.4 Détection des incidents de sécurité (SIEM) (al. 1, let. b)

KSSG attire l’attention sur le fait que la mise en place d’un SIEM prend beaucoup de temps et qu’un délai de transition de trois ans ne sera guère suffisant pour l’implémenter. Il convient dès lors soit d’assouplir les dispositions du ch. 4.4, soit de prolonger les délais prévus pour sa mise en œuvre. VGIch considère que le SIEM doit se restreindre aux parties techniques et organisationnelles de l’infrastructure communautaire qui servent à la mise à disposition du dossier électronique du patient, mais ne doit s’appliquer ni aux extensions (logiquement séparées) requises pour la mise en place de la communication dirigée, ni à l’infrastructure et à l’organisation des institutions affiliées. Six cantons¹¹⁵ déclarent qu’à leur avis, un SIEM ne doit pas pouvoir s’appliquer aux systèmes primaires des professionnels de la santé et demandent par conséquent d’introduire le complément suivant au ch. 4.4.1.1 : « […] de la communauté à l’exclusion des systèmes primaires, qui détecte […] ». ISSS est d’avis que les personnes chargées de la mise en œuvre pratique de ces dispositions doivent être dûment formées, suivre un cours ou obtenir une attestation. Il convient donc de compléter le ch. 4.4.1.3 comme suit : « […] technique, conformément au ch. 4.5. En particulier, il convient d’apporter aux personnes chargées de ces tâches un soutien adéquat et récurrent au sein de la communauté par des mesures de sensibilisation, des formations ou des échanges d’expériences avec d’autres responsables. »

La Poste critique le flou des dispositions du ch. 4.4.2.2. Juger de ce qui est inhabituel, définir comment le reconnaître est une tâche difficile, tant pour la communauté que pour l’auditeur. De plus, on ne sait pas ce qu’est une « mutation critique » au sens du ch. 4.4.2.3. Le texte de ces deux chiffres doit être reformulé en termes concrets.

4.5 Gestion des incidents de sécurité (SIEM) (al. 1, let. b)

VAKA, K3 et VZK demandent ce qui distingue une procédure « formelle » d’une procédure normale. medshare est d’avis que le texte du ch. 4.5.1.1 doit être complété d’un renvoi au document de l’ODEP, car aucun n’y figure. La FMH et la SSIM demandent que l’on précise l’énoncé du ch. 4.5.1.1. Il ne rime à rien de tout signaler. La Poste aurait aimé trouver ici une description claire de l’étendue des problèmes à corriger. ISSS demande que le ch. 4.5.1.1 soit reformulé comme suit pour être conforme au Règlement général sur la protection des données de l’UE (RGPD-UE) : « avoir défini une procédure formelle selon le ch. 4.13 pour l’annonce d’événements pertinents pour la protection et la sécurité des données aux patients concernés ». SQS fait valoir que ce n’est ni la fonction ni la tâche d’un organisme de certification que de recevoir des annonces d’événements relatifs à la protection et à la sécurité de données ou d’en contrôler la suppression de la cause. L’organisme de certification en tant que site d’escalade doit être biffé du ch. 4.5.1.1. Medshare souhaite que l’on précise comme suit l’énoncé du ch. 4.5.2.2.1 : « […] pour isoler la communauté, par blocage de son point d’accès et de son portail d’accès, du traitement des données […] ».

4.6 Protection contre les logiciels malveillants (al. 1, let. b)

ZAD ainsi que NW, TI et ZH trouvent que la réglementation au ch. 4.6 est trop détaillée. Il faut la supprimer et il serait plus adéquat de le remplacer par des principes généraux à inscrire dans l’ODEP. La Poste réitère pour le ch. 4.6.1.1 la demande qu’elle a faite au sujet du ch. 4.5.1.1.

4.7 Gestion des failles de sécurité (al. 1, let. b)

NW, ZH et ZAD réitèrent leur prise de position faite à propos du ch. 4.6, mais contrairement à son commentaire relatif au ch. 4.6, ZAD propose de simplifier le ch. 4.6 au lieu de le supprimer. À l’instar de NW et de ZH, K3 et VZK demandent la suppression du ch. 4.7. Ils précisent que la réglementation est juste dans son principe, mais beaucoup trop détaillée. ISSS demande d’ajouter des chiffres supplémentaires à l’énoncé suivant : « 4.7.4 Pour soutenir la gestion des failles de sécurité, les communautés doivent effectuer des analyses automatisées de vulnérabilité au moins tous les trois mois » et