Rapport sur les résultats

termes « âgés ou ayant un handicap » de cette disposition. Six cantons¹⁴⁸ renvoient pour le ch. 9.3 à leurs prises de position sur le sujet au ch. 3. SBV réitère pour le ch. 9.3.1.2 sa prise de position sur le ch. 3.3.1.2. VGIch fait valoir qu’il faut régler les grandes lignes de l’exigence dès le stade de l’ordonnance, sans attendre l’ODEP-DFI. On contrevient ici au principe de légalité.

9.4 Formats de fichiers : mise à disposition

Six cantons¹⁴⁹ renvoient pour le ch. 9.4 à leurs prises de position sur le sujet au ch. 4. ZH, K3, VZK ZAD font valoir que les dispositions du ch. 9.4 découlent déjà de celles de la LDEP et de l’ODEP ou qu’elles vont de soi et qu’on peut dès lors les supprimer. K3, VZK, ZH et ZG réitèrent pour le ch. 9.4 leur prise de position sur le ch. 3.4, tandis que K3 et VZK renvoient, pour le ch. 9.4.1.2, à leur commentaire relatif au ch. 3.4.1.2. La Poste observe que l’ODEP-DFI définit l’annexe 4 comme sa source pour les formats des fichiers tandis que les CTO se réfèrent à l’annexe 3 (métadonnées), ce qui nécessite une mise au point. Il n’est d’ailleurs pas question que l’ordonnance rabaisse le dossier électronique du patient au rang d’un convertisseur de documents. Convertir des documents au format PDF ne pose plus de problème aujourd’hui à l’utilisateur ni aux systèmes primaires. La Poste est d’avis qu’aucune conversion de documents ne devrait être requise et demande de supprimer cette exigence.

9.5 Formats de fichiers : requête

ZH, K3, VZK et ZAD réitèrent ici la position déjà prise au sujet du ch. 9.4. Six cantons¹⁵⁰ renvoient pour le ch. 9.5 à leurs prises de position sur le sujet au ch. 5. BFH demande pourquoi le portail d’accès doit offrir la fonction de téléchargement vers un système primaire, puisque les professionnels de la santé disposent de leur propre accès. Il faut envisager de supprimer le ch. 9.5.1.2. SCH rappelle à propos de ce chiffre que le patient ne dispose pas d’un système primaire. Medgate se demande également ce qu’un « système primaire » vient faire ici et suppose qu’il s’agit là d’une erreur à corriger. La Poste ne voit pas la raison d’être de la disposition au ch. 9.5.1.3. La manière dont fonctionnent les interfaces au sein des communautés est hors de propos de la LDEP et les solutions utilisées entre communautés sont de type XCA (ou XCF). Une telle exigence n’aurait de sens que si l’on entreprenait aussi de normaliser la façon d’effectuer un « bulk download ». La Poste demande que cette disposition soit supprimée. Elle rappelle par ailleurs que les « rate limits » et « use cases » doivent être définis en détail pour éviter des discussions interminables. On souhaite là aussi la suppression de cette exigence.

9.6 Données historisées (let. c)

ZH, K3, VZK et ZAD réitèrent ici les positions déjà prises au sujet des ch. 9.4. et 9.5. BFH demande ce que l’on entend par « forme lisible » et propose un autre terme comme variante : « […] consulter, sous forme d’un contenu clair qu’ils puissent aisément suivre et comprendre, les données historisées de toutes les communautés […] ». Chez privatim, on regrette que cette formulation ne dise pas dans quelle mesure un patient peut établir un aperçu global de toutes les données historisées des communautés et des communautés de référence. Ce serait pourtant important pour assurer un contrôle efficace. Il faudra examiner s’il est possible de préciser l’énoncé en ce sens.

10. Disponibilité des données enregistrées par les patients (art. 18 ODEP)

10.1 Stockage des documents de patients

10.1.1/10.1.2 : HIN part de l’hypothèse qu’au ch. 10.1.1, le mot « spéciaux » utilisé pour désigner les lieux de stockage internes ne veut pas dire « physiquement séparés ». Une séparation logique suffit amplement. On propose de compléter l’énoncé comme suit : « […] lieux de stockage internes spé-