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 68Fedlex · Rapport sur les résultats
ter à la communauté l’architecture du système de stockage. Ces architectures évoluent très rapidement et vouloir les fixer dans les prescriptions d’une ordonnance n’a guère de sens. Neuf participants92 au total se prononcent pour la suppression du ch. 2.2.1.1. La CDS et 10 cantons93 demandent au minimum que ces règles soient simplifiées et que l’on autorise également le recours au système de stockage des documents utilisé pour le KIS (ZAD utilise dans sa prise de position le terme de « système primaire »), moyennant le cas échéant l’observation de certaines consignes techniques de sécurité. ZH souligne que les éventuelles consignes techniques de sécurité ne doivent pas être trop restrictives sous peine d’entraîner une flambée des coûts chez les prestataires. HIN relève qu’une séparation logique devrait suffire et propose l’énoncé suivant pour le ch. 2.2.1.1 : « les documents du dossier électronique du patient peuvent être séparés en tout temps d’autres documents mémorisés dans le lieu de stockage par un procédé qui assure une séparation logique contrôlée ». IG eHealth et La Poste trouvent ambigu le terme « uniquement », car on pourrait l’interpréter comme une nécessité de stocker en duplicata. Une telle pratique serait contraire au bon sens, car elle doublerait les coûts et rendrait la manutention irréalisable et fortement sujette à des erreurs. Ils proposent donc de biffer le terme « uniquement » du ch. 2.2.1.1.
IG eHealth constate que dans le texte du ch. 2.2.1.2, il est question de l’« annexe 3 » alors qu’il faudrait sans nul doute parler de l’annexe 4, une erreur à rectifier. La Poste demande s’il est permis d’introduire des documents « on demand » (à la demande) dans le dossier électronique du patient. La norme CDA-CH-MTPS est basée sur les documents « on demand ». La Poste fait aussi valoir que les dispositions en la matière sont extrêmement restrictives et empêchent toute adaptation à de nouvelles technologies, ce qu’il s’agit d’éviter. Si par « formats de fichier autorisés », on entend la liste énoncée au ch. 1.9 (MIME Type du document) de l’annexe 3, ZH fait valoir qu’il est problématique de restreindre le nombre de formats de fichier autorisés. D’abord, la conversion en un format autorisé n’est pas toujours réalisable techniquement, et ensuite, elle ne devrait pas toujours être nécessaire. Les formats tels que PNG ou SVG notamment, mais aussi des documents texte, devraient pouvoir être pris en charge. Par ailleurs, l’indication de formats tels que TIFF ou XML est trop vague. ZH recommande donc le remaniement ou la suppression pure et simple du ch. 2.2.1.2.
GE, VD, VS, JU et FR jugent les dispositions du ch. 2.2.1.3 trop restrictives. Il existe aujourd’hui la norme PDF/A-3, introduite par la révision selon ISO 19005. D’autre part, on pourrait aussi utiliser la norme PDF/X (ISO 15930). Ces normes évoluent régulièrement. Des détails techniques n’ont pas leur place dans un texte législatif contraignant et il convient dès lors de supprimer ce chiffre. IG eHealth observe qu’une restriction du choix des formats à la norme PDF/A-1 ou PDF/A-2 pourrait bien se traduire par une conversion obligatoire des données. Cette transformation implique le risque d’une perte d’information ou d’intégrité. Le système ne doit pas procéder à des conversions de format. Par conséquent, le système doit accepter des données du format PDF/A-1 ou PDF/A-2. Tous les autres formats sont rejetés, ce qui pourrait créer un grand problème d’acceptation chez les utilisateurs. Ces cantons demandent donc la suppression du ch. 2.2.1.3. Integic reproche aux indications concernant les normes PDF/A-1 et PDF/A-2 d’être trop imprécises, étant donné que les exigences et surtout la lisibilité divergent fortement entre ces deux sous-versions. Le format PDF/A-1a, par exemple, se prête à un archivage de longue durée et à des applications accessibles à tous, tandis que le format PDF/A-1b ne s’y prête pas du tout. Les normes PDF/A-1 et PDF/A-2 sont plutôt le fruit de technologies évolutives qui se chevauchent, tandis que leurs sous-versions régissent la sémantique de manière plus concrète94. Integic demande que l’on fournisse des précisions sur les sous-versions autorisées de PDF/A-1 et PDF/A-2. ZH rappelle que les formats PDF/A-1 et PDF/A-2 ont été développés précisément pour l’archivage. Si l’ordonnance prescrit que seuls ces formats peuvent être utilisés, cela se traduira par l’obligation de convertir de nombreux documents sans qu’il y en ait un besoin manifeste. Les besoins du dossier électronique du patient n’imposent pas de prescrire ces formats et il convient donc de supprimer cette disposition. La FMH demande à propos du ch. 2.2.1.3 si l’on n’en est pas déjà à la version PDF/A-3. Le législateur n’a pas à introduire des spécifications si précises dans un texte de loi,
92 BINT, Integic, VAKA, SSIM, FMH, KSSG, K3, VZK, SUVA
93 CDS, ZAD, BL, GL, LU, OW, UR, FR, NW, ZG, ZH, SZ
94 http://www.pdfa.org/wp-content/uploads/2011/10/Flyer-PDFA2-Uebersicht-DE.pdf