Ergebnisbericht

Teil umfangreiche Krankengeschichten für die Bereiche Probleme, Anamnese, Behandlungen und Verlauf durch sämtliche an der Behandlungskette beteiligten Gesundheitsfachpersonen geführt werden. Dies sei weder zielführend noch realistisch. Der Blick aufs Wesentliche gehe verloren und es würden riesige Datenfriedhöfe entstehen, die dann vom BAG trotz gesetzlichem Auftrag nicht ausgewertet werden können, weil zu wenige Patientinnen / Patienten ein elektronisches Patientendossier wollten.

3.2.5 Art. 5 Integrationsprofil (Anhang 5)

Art. 5 Integrationsprofile

Anhang 5 legt in Anwendung von Artikel 9 Absatz 3 Buchstabe d und e EPDV fest:

a. die Integrationsprofile;

b. die nationalen Anpassungen der Integrationsprofile;

c. die nationalen Integrationsprofile.

Artikel 5: Der Kanton NE schliesst sich dem Kommentar vom Kanton FR zum Artikel 1 EPDV-EDI an dieser Stelle an. Die H+ begrüsst, dass das EDI auf international anerkannte, auch in der Schweiz etablierte technische Standards zurückgreife. Wichtig sei, dass den Gemeinschaften und Stammgemeinschaften aufgrund ihrer juristischen Ausgestaltung nicht verwehrt bleibe, auf vorhandenen Datenaustausch-Plattformen des eGovernment mitzuwirken.

Anhang 5a

Die Kantone GE, VS, VD, JU und FR schreiben, dass sie nicht die Kompetenz hätten, um diesen Anhang zu kommentieren und dieser von IHE Suisse validiert werden müsse. Die OFAC vertraut IHE Suisse bezüglich Standardisierung und Dokumentation der Integrationsprofile. Ähnlich verlässt sich das KSSG auf die Stellungnahme von IHE Suisse und HL7. Der Kanton SG verweist auf die Prüfung durch IHE Suisse und HL7 und fügt an, dass Integrationsprofile fehlen würden, welche das Löschen über die Gemeinschaften hinweg definieren. Gemäss dem LUKS sei wichtig, dass das Ausführungsrecht des EPDG mit der technischen Entwicklung Schritt halte. Insbesondere seien die kommenden Entwicklungen des HL7 Standard FIHR zu berücksichtigen und zuzulassen. Für die weitere Beurteilung und Überarbeitung sei IHE Suisse und HL7 einzubeziehen. Die IG eHealth und die POST sind der Meinung, dass diese Vorschrift so keinen Sinn mache. Die definierten IHE-Profile seien teilweise für den Einsatz innerhalb einer Affinity Domain und teilweise für den Einsatz "Cross Community" vorgesehen. Der Gesetzgeber habe festgelegt, dass das Gesetz den Bereich zwischen den Gemeinschaften regelt. Darum mache es keinen Sinn Profile zu definieren, welche ausschliesslich für den Einsatz innerhalb von Affinity Domains gemacht wurden. Zudem sei auch nicht klar, wie diese Liste von Profilen zu interpretieren sei. Muss jedes System, das in der Gemeinschaft teilnehmen will, diese Profile unterstützen? Ist es also verboten eine Lösung zu integrieren, welche HL7 Nachrichten über File Transfer übermittelt? Diese Vorschriften können von Auditoren geprüft werden und verursachen damit Kosten. Diese sollten vermieden werden. Die IG eHealth und die Post schlagen vor, dass die Formulierung zwischen MUSS (MUST) und SOLL (SHOULD) Profilen unterscheiden sollte. Die Integic schreibt bezüglich folgendes: „1.4 Requirements on ATNA, XDS.b and XCA Profiles for Audit Trail Consumption“: RESTful- ATNA sei ein neues Supplement for Trial Implementation und solle aufgenommen werden (Add RESTful Query to ATNA - Published 2015-08-07)¹⁶⁵. Neben der vorgeschlagenen Lösung über National Extention sei auch eine Lösung mit IHE RESTful-ATNA verfügbar. Die SGMI und SBC weisen darauf hin, dass Lieferanten von IT-Komponenten diese registrieren lassen sollten (Homologation). Weiter sollte die Registrierung von IT-Systemen komplett von der Gemeinschaftszertifizierung getrennt werden. Dies würde ermöglichen, dass signifikante Einsparungen bei der Zertifizierung der einzelnen Gemeinschaften erzielt würden, da die technischen Komponenten schon registriert werden, es gäbe eine klare Verantwortungsverteilung zwischen den Lieferanten von IT-Komponenten und der Gemeinschaft, es entstünde ein offener Markt für die technischen Komponenten, es würde eine Vereinfachung des Beschaffungsprozesses für die Gemeinschaft erfolgen und es gäbe eine Unterstützung für „best of breed“-Infrastruktur, die