Rapport sur les résultats

Element afin de rendre l’historisation plus facile à suivre pour le patient. HIN constate que le GLN au ch. 1.4.4.1.1 est défini comme « MUST » (impératif). Or, le texte de l’ordonnance (art. 24 ODEP) dit « peut transmettre », ce qui en ferait un élément optionnel. Cela paraît contradictoire. Il y a des cas où le GLN n’est pas encore défini. HIN propose de faire du GLN un « MUST » partout. Cela signifie qu’avant de pouvoir entrer dans une communauté, un cabinet médical doit d’abord obtenir un numéro GLN. La Poste et IG eHealth font l’observation suivante à propos du ch. 1.4.4.1 : Why should the implementer be forced to persist an audit event in any particular format? A canonical format is only relevant for audit message exchange across communities. As long as the implementer can generate and populate the exchange format he should be free to store the data in whatever format deemed most practical. Demande : Remove MUST requirement to store audit event data in a pre-defined format. Ils ajoutent cette réflexion à propos du ch. 1.4.4.1.1 : Which time zone is used in a timestamps string representation is completely irrelevant as long as the time zone is included in the string representation so downstream processes interpret it correctly. Demande : remove the Swiss national extension.

1.5 Requirements on PIXv3 for Patient Identity Feed

La Poste et IG eHealth déclarent à propos de OtherIDs : From the documents of EPDV storing the electronic patient dossier-PID in the MPI is a MUST requirement. Why is it a MAY requirement here? Correct the requirement.

1.7 Requirements on PDQv3 Profile for Patient Demographics Query

La Poste et IG eHealth ont une incertitude à propos du ch. 1.7.2.1.1 : If there are more than 5 matches zero matches a special handling like in the XCPD transaction (see IHE ITI TF-2b, chapter 3.55.4.2.2.6) is necessary. Clarify this statement

1.8 Requirements on XCPD Profile for Cross-Community Patient Discovery

Dans leur prise de position, La Poste et IG eHealth prennent l’exemple d’un cas et demandent comment le résoudre. Ils formulent aussi la revendication suivante : An example for patient matching across communities should be provided. Ils ajoutent à propos du ch. 1.8.2 : As the header is a suggestion by the initiating gateway to the responding gateway, i.e. the responding gateway may do whatever, why is there a hard limit of the value that can be recommended? To restrict a non-binding value seems pointless. Remove “This values MUST NOT exceed 3 days”.

1.9 Requirements on HPD Profile for Replication

HIN réitère pour les ch. 1.9.5.1.1 et 1.9.5.1.2 sa prise de position sur le ch. 1.4.4.1.1.

Annexe 5c

1 Introduction

KSSG demande à propos de la mise en œuvre de XDS-I si le service DICOM WADO fait également partie de la certification. Celui-ci serait un élément des systèmes primaires si seul le KOF était enregistré au Repository XDS. Une autre question qui l’intéresse est si les portails d’accès patient doivent supporter un afficheur DICOM compatible avec WADO (acteur Imaging Document Consumer) et si c’est pertinent ou non pour la certification. Le domaine XDS-I pour l’échange d’images a été entièrement ignoré dans les CTO, d’où la nécessité de revoir l’ODEP et les CTO à l’aune des exigences d’IHE XDS-I. À propos de la phrase « It has been specified for the Document Registries to act as Policy Enforcing Service Providers in terms of a XACML PEP », La Poste et IG eHealth déclarent : Where has this been specified? How do we deal with the situation that someone, who knows all the identifiers relevant to a document can retrieve this document with the REG PEP intercepting this transaction? Example: A primary system that was authorized in the past, stored this information. It can access the