Rapport sur les résultats

conversion automatique et des erreurs de traitement qui en résulteraient. K3 et VZK plaident pour l’inadmissibilité des conversions durant la procédure d’envoi. En effet, une conversion risque de falsifier le contenu et de porter atteinte à l’intégrité des données. Le résultat est hors du contrôle de l’auteur et le document pourrait acquérir une tout autre signification. La disposition doit être modifiée de manière à interdire toute conversion de fichier téléchargé en amont. Aucun document ne doit pouvoir être converti, cette prescription doit donc être supprimée. Integic pose deux autres questions en rapport avec le ch. 3.4.1.2 : quelles sont les voies prévues pour la conversion et comment pratiquer le téléchargement en amont de fichiers de Fitness Tracker ou d’autres applis ? Pour HIN, les fabricants de systèmes primaires devraient avoir tout intérêt à proposer des conversions appropriées. La voie à privilégier devrait être que le portail n’autorise que certains types de fichiers. HIN demande que le ch. 3.4.1.2 soit reformulé : « accepter les fichiers des formats définis à l’annexe 3. Les fichiers soumis dans d’autres formats doivent être convertis automatiquement ou refusés ». Medshare demande que l’on apporte la précision suivante à l’art. 3.4.1.2 : « […] dans un format autorisé en vertu du ch. 3.4.1.1 ».

3.5 Formats de fichiers : requête

Pour K3, VZK, ZAD, ZH et ZG, les dispositions du ch. 3.5 n’ont aucune utilité et doivent dès lors être supprimées. La Poste demande pourquoi les types de documents courants, tels que Word, ne sont pas pris en charge.

3.5.1 : Pour le ch. 3.5.1.2, privatim renvoie à ses déclarations dans les remarques générales sur l’ODEP. SBC signale que le « bulk download » ouvre une faille sécuritaire, raison pour laquelle le ch. 3.5.1.3 doit être supprimé. Integic demande si dans un « bulk download », l’utilisateur doit confirmer la vérification de chaque document ou si le regroupement se fait en une fois. Ce point doit être clarifié et complété. BINT, Integic et IG eHealth font remarquer à propos du ch. 3.5.1.5 que la lisibilité « par l’être humain » n’est pas un problème de téléchargement, mais de présentation. Ils se posent la question si l’on parle ici d’un rendu côté serveur. Dans l’affirmative, il convient de le dire clairement. SUVA souhaite quant à elle des précisions sur ce que l’on entend par « lisible par l’être humain ». KSSG considère que l’on ne peut espérer que le portail d’accès pourra gérer n’importe quel type de données structurées, mais qu’il faut partir du principe qu’il ne travaillera qu’avec les formats d’échange mentionnés à l’annexe 4 de l’ODEP-DFI. Il convient donc de préciser au ch. 3.5.1.5 qu’il vaut uniquement pour les formats d’échange mentionnés à l’annexe 4 de l’ODEP-DFI. Six cantons¹¹⁰ demandent que le ch. 3.5.1.1 soit supprimé et que les ch. 3.5.1.2, 3.5.1.3 et 3.5.1.5 soient reformulés comme suit : « 3.5.1.2 permettre d’enregistrer des fichiers présents dans le système primaire ("upload") ; 3.5.1.3 prévoir la publication, non seulement un par un, mais aussi en masse ("bulk upload") des documents sélectionnés ; 3.5.1.5 […] données structurées brutes ou d’exporter la forme affichée de ces données ». OFAC fait remarquer à propos du « bulk download » au ch. 3.5.1.3 qu’un lot important de données concernant le patient échapperait ainsi au contrôle de la communauté. De plus, cette disposition est en contradiction totale avec le concept du « Patient Empowerment » (responsabilisation du patient).

3.5.2 : medshare signale une faute de frappe dans la version allemande (il manque le t dans « erlaubte »). K3 et VZK critiquent la formulation qu’ils jugent imprécise. SQS demande à ce propos que l’on précise qui est responsable de définir les limites supérieures admises. Integic, BINT et IG eHealth sont d’avis que le principe d’une limite absolue est inadmissible. Il faut pouvoir reconnaître et consulter en toute simplicité d’autres documents disponibles. Pour La Poste, l’argumentation des « rate limits » est indéfendable. Si le patient a décidé de donner le droit d’accès à son dossier électronique au professionnel de la santé qui le demande, il semble inapproprié d’y mettre arbitrairement un verrou. D’après Bleuer, il y a un risque que les documents soient lus incomplètement par le système. Il demande donc la suppression du ch. 3.5.2. SUVA se prononce également pour la suppression de cette disposition et fait remarquer qu’elle se traduirait par la production de données incomplètes sur le patient. Pour les données que le patient a ajoutées lui-même, cela pourrait conduire à une intrusion dans