Ergebnisbericht

Sie fügen dazu an, dass solche Vorgaben zwingend im Rahmen der vorliegenden Verordnungen zu formulieren und nicht zu verschieben seien.

2.9.3 Integrationsprofile, nat. Anpassungen der Integrationsprofile und nat. Integrationsprofile: Die BINT und die Integic machen geltend, dass der entsprechende Nachweis für diese Konformität zu den genannten IHE-Profilen erforderlich sein müsse. Ohne Conformance Statements und Nachweis durch erfolgreich abgelegte IHE Connect-A-Thon-Tests sei dieses Kriterium nicht seriös zertifizierbar, womit diese für die relevanten IHE-Profile einzufordern seien. Die Post kritisiert, dass der Anwendungsbereich von Ziffer 2.9.3 nicht klar sei. Es sollte nur den Austausch zwischen Gemeinschaften und nicht innerhalb einer Gemeinschaft angewendet werden. Die Ziffer sei mit folgendem Zusatz zu ergänzen: „[…] Informationsübertragung zwischen Gemeinschaften die Integrationsprofile […]“.

2.9.4 Akteure und Transaktionen der Integrationsprofile - Gemeinschaftsübergreifende Kommunikation: Die BINT und HIN sind der Meinung, dass die gemeinschaftsübergreifenden Zugriffe kostenlos ausgeführt werden müssen. Falls Gemeinschaften Roaming-Gebühren erheben dürfen, könne so die Ausbreitung und der föderative Ansatz des EPDG nicht umgesetzt werden. Es bestehe zudem die Gefahr von Monopolen, denn bereits das Patientenportal sei hinsichtlich des Betreibers eingeschränkt. Sie beantragen dementsprechend, dass Ziffer 2.9.4 folgendermassen ergänzt wird: „nach Anhang 5 der EPDV- EDI kostenlos unterstützen“. Die IG eHealth und die Post geben zu bedenken, dass die Anforderung gemäss Ziffer 2.9.4.2 nicht nötig sein sollte. Ziffer 2.9.1 definiere die Schnittstelle zur ZAS. Die ZAS biete auch WebService an. Zudem weisen sie darauf hin, dass SEDEX nicht kostenlos sei und fragen, wer diese Kosten tragen solle. Sie schlagen die Löschung der Anforderung vor. Die BINT, die Integic, die IG eHealth und die ahdis sprechen sich für die Streichung von Ziffer 2.9.4.4 aus. Die Patient Location Query werde in Anhang 5 der EPDV-EDI explizit ausgeschlossen. Die BINT, die Integic und die ahdis plädieren zudem für die Aufnahme einer Ziffer 2.9.4.5; Update Document Set Cross Community [ITI-xxx]. Sie schreiben, dass es eine Cross Community Transaktion brauche, um die Dokument-Metadaten Vertraulichkeitsstufen in einer anderen Gemeinschaft zu ändern. Des Weiteren wünschen sie auch die Aufnahme einer Ziffer 2.9.4.6; On-Demand Documents Option (siehe ITI TF-2a, 3.18.4.1.2.5).

Die SQS gibt zu bedenken, dass im Rahmen von Audits eines Managementsystems technische Überprüfungen in dieser Tiefe nicht möglich seien und dem Verständnis von Audits (Stichprobe) widersprechen würden. Die hier beschriebenen Anforderungen seien zwingend zu erfüllende Abnahmekriterien, welche im Rahmen der Inbetriebnahmen von Systemen / Schnittstellen validiert und protokolliert werden müssen. Diese Abnahmen seien ausserhalb der eigentlichen Zertifizierung zu regeln, z.B. im Rahmen einer technischen Prüfung. Im Rahmen der Zertifizierung selber werde mittels Controls ausschliesslich überprüft, ob diese Prüfungen durchgeführt wurden und mögliche Befunde bearbeitet werden. Die Zertifizierungsnorm definiere hingegen nicht, wie schwerwiegend ein Befund ist. Konkret fordert die SQS die Ergänzung der Ziffern 2.9.4 – 2.9.21 mit einer Regelung bezüglich des Nachweises technischer Überprüfung der technischen Voraussetzungen. Diese Forderung wiederholt sie jeweils in sämtlichen relevanten Ziffern.

2.9.5/2.9.6 Akteure und Transaktionen der Integrationsprofile - Kommunikation beglaubigter Identitäten: Das KSSG schreibt bezüglich Ziffer 2.9.5, dass aus ihrer Sicht XUA dafür nicht ausreiche und XUA++ eingesetzt werden müsse. Die ahdis weist darauf hin, dass unter Ziffer 2.9.6 eine Ausführung fehle, wie der X-Service User die Assertion vom X-Assertion Provider bekommt und wie die Relation zum User Authentification Provider sein muss.

2.9.9 Akteure und Transaktionen der Integrationsprofile - Dokumente bereitstellen: Das KSSG fragt, ob es zwingend sei, dass die Dokumente mittels Provide and Register Document Set-b im Repository abgelegt werden. Es sei auch denkbar, dass die Dokumente über HL7 MDM im Repository abgelegt werden und dann mit der Transaktion Register Document Set in der Registry registriert werden. In St. Gallen sei dies so umgesetzt, da die Dokumenten-Quellen zum Teil kein Provide and Register Document Setb unterstützen würden. Bei Medizinprodukten sei es eher unwahrscheinlich, dass diese Anforderung für