Rapport sur les résultats

doute trouver une autre solution compatible avec la LPD. Six cantons¹⁰¹ critiquent la traduction française du ch. 2.10.4.1.3 et proposent l’énoncé suivant : « configuration des autorisations ou gestion des autorisations ».

Au sujet du ch. 2.10.4.2, La Poste et IG eHealth demandent s’il est bien utile que le patient voie aussi dans l’historique les tentatives d’accès qui ont été refusées. On doute en effet qu’il soit vraiment nécessaire d’afficher toutes les recherches avec leurs critères dans l’historique parce qu’elles pourraient créer une certaine confusion, surtout lorsqu’elles n’ont rien trouvé ou apporté à leur auteur. Ces intervenants demandent donc des précisions. À propos du ch. 2.10.4.2.1, ils rappellent qu’il figure dans la liste des « saisies de l’historique consultables par le patient ». Ils demandent s’il est approprié qu’un patient puisse vérifier pour n’importe quel professionnel de la santé quand celui-ci s’est connecté et déconnecté, à moins qu’il soit question ici des (dé-)connexions du patient, à préciser le cas échéant. Le terme allemand de « Fokus » doit être repensé, l’historisation en elle-même est acceptable en la forme. Ils proposent de préciser : « authentification du patient dans le système […] ». La Poste objecte à propos du ch. 2.10.4.2.3 « que les entrées dans l’historique risquent d’être très nombreuses, notamment parce que les médecins font souvent des recherches non spécifiques. La limitation du nombre de résultats dans les profils IHE est facultative et il manque une disposition légale qui en ferait une exigence contraignante. Un déluge d’informations ne contribue pas à la sécurité des données. Le texte de ce chiffre doit être revu et rendu plus cohérent ». Pour medshare, le texte de ce chiffre est incompréhensible. En effet, il permet la recherche de documents, mais pas du dossier électronique du patient. Il s’agit de préciser où on veut en venir. En outre, medshare demande des précisions et une justification pour le ch. 2.10.4.2.5. KSSG fait remarquer que les saisies dans l’historique consultables par le patient sont générées par le profil IHE ATNA et à leur avis, le profil IHE ATNA ne prend pas en charge cette exigence. Ils demandent donc la suppression du ch. 2.10.4.2.7. L’historisation d’un nouveau MID peut être demandée dans Systemlogs, mais pas dans ATNA. Il en résulte que les saisies de son historique ne sont pas consultables par le patient. SCH explique à propos du ch. 2.10.4.2.7 que l’enregistrement d’un nouveau MID est un processus isolé dans Identity Provider, mais que l’Identity Provider n’est pas forcément une composante TI de la communauté ; il peut être sous-traité à des tiers. Le protocole SAML prescrit pour la communication des portails avec les Identity Providers ne prévoit aucun échange de données historisées entre l’Identity Provider et les portails. Par conséquent, les informations sur l’enregistrement de nouveaux MID ne sont en général pas disponibles dans la communauté et ne peuvent dès lors pas être historisées.

2.10.5 : Six cantons¹⁰² font remarquer qu’une recherche n’a pas besoin d’être historisée si son résultat ne concerne pas qu’un seul patient. De plus, il est techniquement impossible de tracer une impression ou d’empêcher une capture d’écran. Il convient donc de supprimer les ch. 2.10.5.1 à 2.10.5.3. Integic réitère sa prise de position au sujet du ch. 2.10.4. SUVA rappelle que ses remarques concernant le ch. 2.10.4 restent valables tant qu’il s’agit de recherches effectuées par le patient dans ses propres données. Comme le déplore privatim, le texte n’indique pas si le patient trouvera dans l’historique les noms de ceux qui ont eu accès à ses données. C’est en tout cas une information importante qui devrait figurer dans l’historique. En règle générale, la personne qui accède aux données est connue du système, sinon l’historique doit faire état d’un accès par inconnu. La disposition doit être précisée, évent. complétée des éléments manquants. La SSIM et la FMH considèrent que l’historisation de la fonction de recherche et de ses paramètres va trop loin et qu’il faut la supprimer. Même les accès par create, read, update et delete sont historisés. BFH critique le fait que le ch. 2.10.5 évoque ce que l’historique « doit contenir au moins », mais fait suivre les exemples donnés aux ch. 2.10.5.1 à 2.10.5.3 de la mention « etc. ». Il demande que l’on dresse une liste exacte des attributs minimum à historiser. La Poste demande la suppression du ch. 2.10.5.3 au motif qu’il est impossible à appliquer.

2.10.6 : Tessaris propose de compléter comme suit le ch. 2.10.6 : « Les données historisées doivent être conservées pendant toute la durée de conservation prescrite des données dans le dossier électronique du patient jusqu’à leur suppression du dossier, mais au moins pendant 10 ans ». Par souci