Ergebnisbericht

1.4.3.2 folgendes: Instead of UUID this should read documentUniqueId. Zu Ziffer 1.4.3.1.2 schreiben sie zudem folgendes: „Cache all audit messages“, this paragraph implies several drawbacks:

- Caching implies that an updated version of the document is not available for another 8 hours. If a user notices that after a log view, subsequent actions (even his own) are no longer presented, he may think that logging is flawed.

- To force a particular implementation makes no sense. It is preferable to specify what the response must contain and maybe allow the option to cache this information for up to 8 hours. The implementation details should be left to the platform.

The method chosen (On demand document) to implement this feature can be discussed. Alternatives would be: - XCF, - Delayed Document Assembly. Improve the requirement for a more sustainable solution. Avoid to limit the freedom of the implementation and standardize the relevant aspect of the interfaces.

1.4.4: Die Integic empfiehlt betreffend AuditMessage/ActiveParticipant, nicht nur die UserID, sondern einen lesbaren Namen der durchführenden Person als 1.1 mandatory Element einzuführen, um die Protokollierung für die Patientin / den Patienten nachvollziehbarer zu gestalten. HIN stellt fest, dass GLN bei Ziffer 1.4.4.1.1 als „MUSS“ definiert sei. In der Verordnung (Artikel 24 EPDV) sei aber erwähnt, dass sie übermittelt werden "kann", also optional ist. Dies scheine widersprüchlich zu sein. Es gebe Fälle, bei denen die GLN noch undefiniert sei. Es wird vorgeschlagen, die GLN überall als „MUSS“ zu haben. Dies bewirke, dass Praxen erst eine GLN lösen müssen, bevor sie einer Gemeinschaft beitreten können. Die Post und die IG eHealth schreiben folgendes zu Ziffer 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. Antrag: Remove MUST requirement to store audit event data in a pre-defined format. Zu Ziffer 1.4.4.1.1 geben sie zudem folgendes zu bedenken: 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. Antrag: remove the Swiss national extension.

1.5 Requirements on PIXv3 for Patient Identity Feed

Die Post und die IG eHealth schreiben betreffend OtherIDs folgendes: 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

Betreffend Ziffer 1.7.2.1.1 ist folgendes für die Post und die IG eHealth unklar: 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

Die Post und die IG eHealth zeigen in ihrer Stellungnahme ein Case auf und fragen, wie dieser zu lösen sei. Zudem fordern sie folgendes: An example for patient matching across communities should be provided. Bezüglich Ziffer 1.8.2 schreiben sie zudem folgendes: 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 wiederholt ihre Stellungnahme von Ziffer 1.4.4.1.1 bezüglich den Ziffern 1.9.5.1.1 und 1.9.5.1.2.