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 75Fedlex · Rapport sur les résultats

2.10 Données historisées (al. 3, let. e) – Exigences concernant le système d’historisation

FMH renvoie à ses remarques faites à propos des articles pertinents de l’ordonnance, mais tient surtout à rappeler que l’historisation des accès engage également la responsabilité civile des personnes traitantes. Elle doit impérativement servir à établir quelles données ont été consultées par un professionnel de la santé au moment de son accès.

2.10.2 : Sept participants100 demandent ce qu’on entend par « ce qui est nécessaire » ou comment on le définit. K3, VZK, ZAD et ZH demandent la suppression de cette dénomination. ZH demande en plus que l’historique – contrairement à ce qui est dit au ch. 2.10.2 – montre quelles données ont été consultées, sinon le patient n’est pas en mesure d’apprécier si l’accès était ou non licite. Il faut aussi veiller à ce que l’historisation soit complète en toutes circonstances. Ce n’est qu’ainsi que l’on peut créer la confiance en ce système. IG eHealth souhaite que la notion « erforderliches Mass » (version allemande de « ce qui est nécessaire ») soit incluse dans les définitions terminologiques, faute de quoi la mesure de ce qui est nécessaire devra être régie par un règlement d’exploitation au niveau national. ZG propose que l’on précise cette notion. D’après medshare, la notion de « donnée médicale » est floue et il convient de la préciser.

2.10.3 : IG eHealth et La Poste demandent s’il est approprié qu’il suffise de pouvoir établir qu’une modification a eu lieu ultérieurement. Ils proposent de modifier comme suit l’énoncé du ch. 2.10.3.2 : « […] des données historisées doit être impossible. » À propos des modifications ultérieures de données historisées, Tessaris observe qu’il pourrait fort bien s’agir de données dont la pratique a révélé qu’elles étaient erronées ou incomplètes. Dans ce cas, il devrait être possible de corriger ou de compléter des données historisées, mais non de les modifier rétroactivement. Les compléments, correctifs ou modifications d’inscriptions historisées doivent être marqués comme tels, complétés d’informations sur l’auteur et horodatés.

Bleuer fait valoir à propos du ch. 2.10.3.3 que l’historisation d’une consultation par le patient de ses propres données constitue une ingérence dans la sphère privée des citoyens et doit par conséquent être expressément autorisée par le patient. Selon ZH, le dossier électronique du patient doit être paramétré de telle manière qu’un administrateur système n’a aucun accès aux données médicales du patient. Les données doivent être cryptées et les clés de cryptage administrées de manière à empêcher toute lecture de ces données par les administrateurs OS et les administrateurs DB. Le cryptage doit être effectué sur toutes les données. Au sujet des ch. 2.10.3.3 et 2.10.3.4, privatim fait remarquer que le patient doit pouvoir se rendre compte que des administrateurs système ont eu accès à son dossier électronique. Il demande que la réglementation soit adaptée en conséquence.

SQS relève à propos du ch. 2.10.3.4 qu’il sera toujours possible de contourner des restrictions techniques moyennant des droits d’accès appropriés. Le problème devra par conséquent être résolu par la voie administrative. La restriction des droits d’administrateur doit faire l’objet d’une directive. KSSG adhère à ce point de vue et considère que des données historisées sont toujours manipulables jusqu’à leur archivage, ce qui pose des limites à la portée effective de cette règle. Il convient par conséquent de biffer le ch. 2.10.3.4 ou de l’adapter. SCH met également en doute la faisabilité technique du ch. 2.10.3.4 et propose la variante suivante : « Les logs système doivent pouvoir être sauvegardés de manière conforme aux critères de révision ». BFH est d’avis que les administrateurs système ne doivent pas non plus pouvoir effacer ni désactiver l’historisation d’autres activités, et demande d’adapter comme suit le ch. 2.10.3.4 : « […] effacer ou désactiver l’historisation des activités ».

2.10.4 : Integic fait valoir que les saisies dans l’historique visées au ch. 2.10.4 constituent une atteinte à la vie privée du citoyen dans la mesure où elles impliquent la consultation de ses propres données. Le patient doit pouvoir décider s’il autorise ou non ce processus. SUVA déclare également que cette disposition viole la sphère privée du patient. Le patient doit rester libre de décider quand et comment consulter ses propres données sans qu’un professionnel de la santé ne le sache. Il faudra sans nul

100 IG eHealth, Integic, K3, VZK, ZG, ZH, ZAD