Rapport sur les résultats

pour indiquer le degré d’obligation correspondant aux différents formats d’échange.

Cinq participants¹¹ constatent qu’au titre du « Type de document » indiqué au ch. 2, il est fait référence aux métadonnées figurant au ch. 2.11 de l’annexe 3, alors que l’annexe 3 ne contient pas le type de document « Décision thérapeutique » figurant au ch. 3.2.2., let. d, du projet. Ils recommandent donc de passer en revue toutes les informations mentionnées dans le projet actuel afin de vérifier si elles coïncident avec les métadonnées visées à l’annexe 3. Si nécessaire, l’annexe 3 doit être modifiée en conséquence.

S’agissant du ch. 2.2.3, Ofac est d’avis que les données relatives à l’auteur telles qu’elles sont proposées ne suffisent pas pour couvrir tous les cas d’application. L’organe préconise de modifier le ch. 2.2.3 de manière à pouvoir saisir deux informations ; d’abord le thérapeute qui a rédigé l’ordonnance papier, puis le thérapeute qui a enregistré l’ordonnance papier sous forme électronique dans le DEP.

Selon FMH, il faut définir clairement les consignes relatives à l’identifiant des professionnels de la santé, au ch. 2.2.3. Autrement dit, le Global Location Number (GLN) doit être désigné comme identifiant.

Medshare relève qu’au ch. 2.1, la référence au CDA-CH doit être adaptée à la version 2 du document disponible à l’adresse http://e-health-wiki.ch/index. php/Ehscda:CDA-CH 2017 (spécification). Idéalement, la référence doit renvoyer à l’OID de la spécification concernée. Il est en outre proposé de supprimer la référence au ch. 2.1.b et dans les données relatives au destinataire, ces indications devant être saisies uniquement pour le résultat électronique de laboratoire. Medshare demande également l’ajout des moyens de communication (par ex. numéros de téléphone, courriels) en tant qu’unité d’information autorisée plusieurs fois.

GSASA souhaite que la traduction en anglais (shall, should) soit définie et reprise de manière systématique dans les suppléments 1, 2 et 3. Elle suggère également que les traductions de « Doit » et « Peut » soient établies dans l’ordonnance et reprises de manière systématique dans les suppléments. Le degré d’obligation « Peut » devrait également être indiqué au ch. 3.2.

BEKAG souligne qu’il faut suivre en permanence l’évolution parallèle des normes déjà existantes et qu’il est indispensable que ces différents standards et formats d’échange soient et restent interopérables dans les systèmes d’information des cliniques et des cabinets médicaux. Elle indique que, dans la pratique, la réalité consistera en une juxtaposition de divers standards et formats.

Swisscom écrit que le niveau de confidentialité indiqué au ch. 2.4. de l’annexe 3 ODEP-DFI est déjà donné lors de l’enregistrement d’un document conformément à la transaction IHE (par ex. ITI-41). Il ne semble donc pas opportun de faire figurer ces données dans le document lui-même, d’autant moins que le niveau de confidentialité peut changer. En outre, Swisscom souhaite que le champ « auteur » soit spécifié, au motif qu’il convient d’établir une distinction entre le collaborateur spécialisé et la personne chargée du contenu. Dans tous les cas, il faudrait au moins préciser ce que l’on entend exactement par « auteur ».

Cistec déplore qu’à l’annexe 4 les formats d’échange à utiliser soient limités au CDA-CH-II et propose de compléter l’annexe 4 par le standard Fast Healthcare Interoperability Resources (FHIR) de HL7. Cette norme offre en effet des temps de développement nettement plus courts et permet beaucoup mieux de répondre aux exigences de synchronicité et de performance. HL7 s’étant inspiré des expériences réalisées avec son CDA pour développer FHIR, elle a pu exploiter les meilleures caractéristiques de CDA tout en améliorant de manière significative l’échange de données. Cistec souhaite en outre que d’autres profils IHE (PML, MTP, PADV, DIS et PRE) soient basés sur FHIR et que des profils IHE supplémentaires, tels PIXm, PDQm et ATNA RESTFul, soient repris dans l’ODEP-DFI.