Rapport sur les résultats

transactions XDS.b sont « hors champ d’application » (out of scope). Les champs d’application de la LDEP, de l’ODEP et des CTO doivent être mieux définis. Integic signale à propos du ch. 2.9.11.2 que la désignation correcte est « Registry Stored Query », à corriger. Il dit également avoir relevé des incohérences dans les transactions mentionnées. En effet, une partie des transactions indiquées sont de celles que les acteurs doivent pouvoir exécuter ou réceptionner/traiter eux-mêmes. Il y a des lacunes dans les transactions qui doivent être prises en charge par les acteurs IHE respectifs (réception et envoi). Par exemple, 2.9.12. doit prendre en charge ITI-42, car cette transaction s’effectue du Document Repository au Document Registry, alors qu’elle n’est indiquée que pour Document Registry (2.9.11). Il convient donc de corriger ces incohérences.

2.9.12 Acteurs et transactions des profils d’intégration – Lieux de stockage des documents : Integic réitère d’une part la prise de position émise au sujet du ch. 2.9.11, et critique d’autre part l’absence totale de la transaction ITI-64, essentielle aux processus de clearing et à l’amélioration de la qualité des données dans les registres de référence, ainsi que du profil IHE XAD-PID Change Management qui lui est associé. La transaction ITI-64 doit donc être complétée. KSSG réitère à propos du ch. 2.9.12.1 sa position déjà prise à l’égard du ch. 2.9.9.

2.9.15 Acteurs et transactions des profils d’intégration – Gestion de l’index des patients : BINT réitère son commentaire du ch. 2.9.4 pour le ch. 2.9.15.3 et propose, comme Integic et ahdis, de supprimer ce dernier chiffre. Il n’est pas nécessaire de prévoir un message de mise à jour pour les ID du patient. Le cas d’application n’est pas reconnaissable.

2.9.16 - 2.9.18 Acteurs et transactions des profils d’intégration – Authentification des systèmes et historisation des transactions IHE : Integic et ahdis demandent la suppression de l’élément de texte « grouped with Any IHE Actor » aux ch. 2.9.16 et 2.9.17. D’après medshare, Secure Applications et Secure Nodes doivent être traités à égalité. Les sous-points des ch. 2.9.17 et 2.9.18 doivent figurer dans les deux chiffres. IG eHealth, Integic et ahdis demandent l’ajout d’un ch. 2.9.18.2 « Maintain Time [ITI-1] », conformément à l’annexe 5 ODEP-DFI, point 1.4.2.4 ATNA Secure Application.

2.9.22 – 2.9.24 Authentification avec des certificats valables : À propos des certificats électroniques délivrés par les services de certification en vertu de la loi sur la signature électronique (SCSE), OFAC déclare que la SCSE règle les conditions de reconnaissance des prestataires de services de certification dans le domaine de la signature électronique, ainsi que leurs droits et devoirs. La SCSE définit le cadre qui permet aux personnes physiques de signer électroniquement des documents, mais elle est limitée au domaine de la signature électronique et ne couvre en aucun cas les modalités d’identification et d’authentification des personnes morales et leurs différents points d’accès techniques. L’exigence d’acquérir les certificats auprès de fournisseurs de signatures électroniques n’est pas fondée et n’apporte du reste au dossier électronique du patient aucune garantie supplémentaire sur le marché vis-à-vis de l’organisme de certification. La Poste demande à propos du ch. 2.9.22 si les certificats logiciels sont autorisés. medshare fait valoir que la CdC ne devrait pas être traitée différemment des services centraux de recherche. Elle propose de fusionner ce chiffre avec le ch. 2.9.22.3 et de faire de même dans l’art. 38, al. 1, ODEP. Au ch. 2.9.23, medshare signale que la référence aux documents fait défaut. Par ailleurs, medshare réitère pour le ch. 2.9.24 le commentaire déjà émis à l’égard du ch. 2.9. CT (consistent time) est une condition sine qua non pour l’ATNA. L’ATNA est une condition dictée par les autres profils IHE. Il serait plus judicieux selon medshare que CT prenne comme source l’heure suisse.

2.9.25 Cohérence de l’heure en Suisse : SQS veut savoir qui décide quels sont les systèmes pertinents de traitement de l’information et comment. Un smartphone ou une tablette, par exemple, sont-ils des systèmes pertinents ? Des déclarations de ce type peuvent être interprétées et évaluées différemment dans des audits. SQS demande concrètement une description explicite de la notion de « système pertinent de traitement de l’information ». IG eHealth et La Poste demandent de leur côté pourquoi l’on ne référence pas ici le profil CT.