Systemspezifisches Konzept ePA

Urheber: gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
Version: 1.0.0
Veröffentlichungsdatum: 30.01.2019
Schlagworte: Festlegung der gematik  // Telematikinfrastruktur  // ePA
Stellungnahmen: 2
Bewertungen der gematik: 1
Kommentare: 2

Beschreibung

Dieses Konzept beschreibt die Umsetzung der Anwendung ePA auf Systemebene.
Es legt das Zusammenspiel der Produkttypen der Fachanwendung und den Verantwortungsbereich der einzelnen Produkttypen fest.
Das Dokument ist ein Bestandteil des Dokumentenpakets der gematik und enthält technische und semantische Anforderungen zur Nutzung in Anwendungen nach den §§ 291 und 291f Absatz 1 SGB V. Die enthaltenen Anforderungen werden entsprechend der über die Dokumentenlandkarte und Produkttypsteckbriefe auf der Webseite der gematik (www.gematik.de) geregelten Verbindlichkeit in Zulassungs- und Bestätigungsverfahren der gematik geprüft.

Zusätzliche URLs

https://fachportal.gematik.de/spezifikationen/online-produktivbetrieb/

Bewertungen der gematik

  • Die gematik beabsichtigt diese Festlegung in vesta aufzunehmen.
    Im Releaseprozess der gematik wurde die vorliegende Festlegung auf Interoperabilität zu gematik Dokumenten sowie zu weiteren, zum Stand 13.12.2018, bereits in vesta enthaltenen Interoperabilitätsfestlegungen geprüft. Aus Sicht der gematik ist die vorliegende Festlegung mit den bereits in vesta eingetragenen Interoperabilitätsfestlegungen interoperabel.

Stellungnahmen

  • Systemspezifisches Konzept ePA

    Referenzierung: gemSysL_ePA

    Bewertung:

    Die Inhalte der Spezifikation sind nicht kompatibel mit internationalen Standards. Die gematik hat ein hochproprietäres Format – basierend auf einem proprietären gematik-Datenmodell –  ohne die Berücksichtigung internationaler Standards entwickelt. Die gematik hat für die Entwicklung zwar IHE-Profile miteingebunden, diese allerdings so verändert, dass keine IHE-konforme Verwendung mehr möglich ist.

    Die Spezifikation ausschließlich von Dateitypen greift zu kurz. Interoperabilität bedarf semantischer Festlegungen und einer zugehörigen Infrastruktur, wie z.B. Terminologie-Servern. Zudem sind eine Versionsverwaltung für alle Dokumentenformate sowie versionierte Verzeichnisse von Value Sets von Nöten.

    Der angebliche Einsatz von IHE-Profilen genügt nicht, um die Umsetzbarkeit durch die Anbieter von ePA-Aktensystemen angemessen zu berücksichtigen. Um dem im Konzept aufgebrachten Gebot der Angemessenheit zu entsprechen, müsste die hier vorgestellte Architektur auch den IHE-Vorgaben entsprechen. Diese sehen eine weitere, landesspezifische Profilierung vor, um weitergehende Anforderungen und lokale Besonderheiten einzubeziehen. Stattdessen wurde der Ansatz gewählt, nominell IHE XDS-basiert zu arbeiten, aber in Wirklichkeit durch Ausschlüsse (z.B. A_14668, A_13809), Inkompatibilitäten (z.B. A_15034) und überzogene Betriebsforderungen (Isolation pro Versichertenakte in einer dedizierten VAU, Versichertenspezifische Data-at-rest Verschlüsselung) praktisch jeglichen Einsatz von Standardprodukten zu verhindern. Dies erfordert somit eine dedizierte Neuentwicklung der angeblich standardbasierten Komponenten.

    Zudem wird auf die Verwendung des ATNA-Profils verzichtet. Dies stößt auf besonderes Unverständnis, da IHE XDS zwingend die Protokollierung über das IHE ATNA-Profil voraussetzt. Die von allen Anbietern verlangten zusätzlichen Aufwände für eine zweite, parallele Protokollierung auf allen IHE XDS-Schnittstellen werden inhaltlich nicht begründet.

    Die Spezifikation verbietet eine Entschlüsselung der Metadaten in der Registry, d.h. außerhalb der vertrauenswürdigen Ausführungsumgebung (VAU). Die VAU ist eine proprietäre deutsche Lösung. Der gewählte Verschlüsselungsansatz schränkt die Nutzung der Akte und die Usability für die Anwender extrem ein. So wird die Umsetzung einer für den Patienten praktischen Webanwendung mit Hilfe gebräuchlicher Webtechnologien verhindert, da das Frontend des Versicherten ausschließlich auf dem Endgerät des Versicherten benutzt werden kann.

    Weiterhin ist der Verzicht auf die Nutzung von aktuellen, FHIR-basierten Profilen, wie IHE MHD, ist insofern erstaunlich, als dass diese explizit für den Mobilzugriff vorgesehen sind. Die Nutzung von IHE XDS hingegen wird für Mobilanwendungen nicht empfohlen, u.a. da die für XDS notwendigen Technologien in den Libraries und SDKs für Mobilanwendungen kaum unterstützt werden.

    Der aktuellen Spezifikation zufolge ist die Akte lediglich ein Austauschmedium ohne weiteren Mehrwert. Abgesehen von den Kategorien in den Metadaten sind keine Mechanismen zur Strukturierung der Dokumente vorgesehen: Es gibt weder Ordner, noch Fälle oder ähnliche Gruppierungselemente – obwohl IHE XDS diese bereitstellt. Zudem bietet das System keine dedizierten Funktionen für Benachrichtigungen. Das Primärsystem kann dies nicht ausgleichen, da es durch die „Ende-zu-Ende“-Verschlüsselung ohne Anmeldung des Benutzers keinen Zugriff auf die Dokumente hat und somit den Benutzer nicht über neu verfügbare Dokumente in der Akte informieren kann. Dies führt zu geringer Benutzerakzeptanz. Die in dieser Spezifikation postulierte „Benachrichtigung“ beschränkt sich somit auf die Kennzeichnung neuer Dokumente (ähnlich der Verwaltung des Lesestatus in vielen Email-Clients).

    Insgesamt werden die Gesamtkosten für die Akte, basierend auf obengenannten Schwächen, als sehr hoch bewertet. Zudem liegt die Vermutung nahe, dass die Akte bei den Versicherten wenig Anklang finden wird.

    Anmerkung zur Nutzung der ePA und zur Vertreterregelung:

    Nach den derzeitigen Prozessabbildungen ist es für nicht-geschäftsfähige Versicherte, wie z.B. Kinder, nicht möglich die elektronische Patientenakte zu nutzen. Durch die konkrete Forderung beim Login des Versicherten im FdV (Kapitel 6.2.4.1) den LifeCycleStatus das DF.HCA zu prüfen, werden alle anderen Möglichkeiten, Personen ohne eGK zur Vertretung zu ernennen, verhindert. Hiermit kommen alle Privatversicherten nicht als Vertreter in Frage. Das Login kann lokal nicht vom DF.HCA abhängig gemacht werden, weil das Ende des Versicherungsvertrages nicht zwangsläufig das Ende des Zugriffs zum FdV bedeuten muss. Hier werden Methoden gemischt, die nicht miteinander verbunden sein sollen. DF.HCA ist das Verzeichnis für Versicherungsstatus und Gesundheitsdaten. Für die Authentisierung sollte ein X.509 Zertifikat im DF.ESIGN verwendet werden. Die Abbildung der Prüfung des DF.HCA verursacht gewaltige Probleme auf alternativen Plattformen, wie z.B. virtuellen eGKs (siehe Ausschreibung BMG), weil das DF.HCA ein rein gematik-proprietäreres Objekt ist und nicht auf SecureElements oder UICCs abgebildet wird. GSMA unterstützt lediglich PKI.

    Anmerkungen zur Rollenvergabe:

    Aktuell wird in der Spezifikation keine saubere Rollenvergabe modelliert. Der Patient vergibt eine Berechtigung an eine Leistungserbringerinstitution, die dann auf die Akte zugreifen darf. Dies stellt gerade in großen Institutionen, wie z.B. Krankenhäusern oder Unikliniken, ein Problem dar, weil in Krankenhäusern somit sehr viele Personen Einsicht in die Akte haben. Dies ist aus datenschutzrechtlichen Gründen äußerst kritisch zu bewerten und widerspricht der OH-KIS. In der OH-KIS wird eine rollen- und stationsbasierte Trennung der Zugriffsrechte gefordert.

    Detaillierte Kommentare finden Sie in den beigefügten Tabellen gemSysL_ePA und IHE-Konformität.

  • Die Inhalte sind nicht kompatibel mit internationalen Standards.

    Es sind nur Dateitypen vorgesehen. Semantischer Interoperabilität bedarf festgelegter Value-Sets, Wertebereiche, Bezüge und Technologien wie Terminologie-Servern etc.

Kommentare

  • Name: Thomas Liebscher
    Organisation: Philips GmbH
    25.02.2019

    Die Inhalte der Spezifikation definieren ein proprietäres Format und Datenmodell und sind nicht kompatibel mit internationalen Standards, insbesondere IHE Profilen. Die Spezifikation erwähnt zwar das IHE XDS Profil, hat dieses in den Anforderungen allerdings so stark verändert, dass IHE-konforme Produkte dieser Spezifikation nicht entsprechen können bzw. neu-entwickelte Produkte nicht IHE-konform werden können und dies auf einem Connectathon nachweisen können. Siehe Ausschlüsse (z.B. A_14668, A_13809), Inkompatibilitäten (z.B. A_15034) und insbesondere das Untersagen der Verwendung des ATNA-Profils für die Protokollierung. Dies stößt auf absolutes Unverständnis, da IHE XDS zwingend die Protokollierung über das IHE ATNA-Profil voraussetzt. 

    Die Spezifikation verbietet eine Entschlüsselung der Metadaten in der Registry und außerhalb der VAU. Der gewählte Verschlüsselungsansatz schränkt die Nutzung der Akte und die Usability für die Anwender extrem ein. So wird die Umsetzung einer für den Patienten praktischen Webanwendung mit Hilfe gebräuchlicher Webtechnologien verhindert, da das Frontend des Versicherten ausschließlich auf dem Endgerät des Versicherten benutzt werden kann.

    Ebenfalls nicht verständlich ist der Verzicht auf die Nutzung von aktuellen, FHIR-basierten Profilen, wie IHE MHD, da diese explizit für den Mobilzugriff vorgesehen sind. Die Ableitung der Spezifikation von IHE XDS kann nicht nachvollzogen werden, da die Nutzung von IHE XDS für Mobilanwendungen nicht empfohlen wird.

    Der Spezifikation zufolge sind keine Mechanismen zur Strukturierung der Dokumente über Metadaten vorgesehen: Es gibt weder Ordner, noch Fälle oder andere Gruppierungselemente – obwohl IHE XDS/MHD diese bereitstellt.

    Der Spezifikation zufolge sind keine dedizierten Funktionen für Benachrichtigungen (siehe IHE DSUB) über neue/veränderte Dokumente vorgesehen. Das Primärsystem kann dies nicht ausgleichen, da es durch die „Ende-zu-Ende“-Verschlüsselung ohne Anmeldung des Benutzers keinen Zugriff auf die Dokumente hat und somit den Benutzer nicht über neu verfügbare Dokumente in der Akte informieren kann. Dies wird zu geringer Benutzerakzeptanz bei allen Nutzern führen. Eine reine Kennzeichnung des Lesestatus neuer Dokumente im Primärsystem nachdem die Dokumente abgeholt wurden, reicht da nicht.

    Aktuell ist es nicht vorgesehen, Personen ohne eGK zu Vertretern zu ernennen. Hiermit kommen alle Privatversicherten / Beamte nicht als Vertreter in Frage. Dies wird zu geringer Benutzerakzeptanz bei Patienten führen. Da ein Großteil der niedergelassenen Ärzte- und Apothekerschaft zudem privatversichert sein dürfte, fehlen hier auch Key-User des Systems, die motivierend mit Hilfe eigener Erfahrungen auf die Akzeptanz bei Patienten einwirken können.

    Der Spezifikation folgend ist keine saubere Rollenvergabe vorgesehen. Der Patient vergibt eine Berechtigung an eine Leistungserbringerinstitution, die dann auf die Akte zugreifen darf. Dies stellt in großen Institutionen (Krankenhäuser) ein Problem dar, weil somit sehr viele Personen Einsicht in die Akte haben. Dies ist aus datenschutzrechtlichen Gründen äußerst kritisch zu bewerten und widerspricht der OH-KIS. In der OH-KIS wird eine rollen- und stationsbasierte Trennung der Zugriffsrechte gefordert. Eine Verwendung des IHE APPC Profils würde dies ermöglichen.

  • Name: Dr. Frank Oemig
    Organisation: bvitg e.V.
    15.03.2019

    Die gematik-Spezifikation wurde im Prinzip aus der IHE ITI XDS Spezifikation herauskopiert, so dass sich relativ viele scheinbare Überlappungen ergeben, die funktional aber nicht identisch sind. Ein Beispiel: Es werden zwar die Webservice-Spezifikationen (WSDL) übernommen, aber mit einer veränderten Backendfunktionalität. Oder es werden MUSS-Anforderungen wie ATNA oder CT verboten und durch TI-eigene ersetzt. Damit stehen die Vorgaben im Widerspruch zu internationalen Standards und Profilen und sind also NICHT IHE-konform, auch wenn Aussagen wie "benutzt IHE-Profile" das nahelegen.

    Die Aussage „basiert auf internationalen Standards“ stimmt zwar, weil hier der genutzte Standard ebXML von OASIS ist, nur hilft das nicht für die Etablierung von Interoperabilität. Durch die gematik-eigene Profilierung entsteht also eine zu internationalen Ausarbeitungen wie XDS inkompatible Version, die halt nur „ähnlich“ aussieht. So gesehen entsteht eine gematik-proprietäre Aktenspezifikation, die so nur in Deutschland einsatzfähig ist.

    Was hätte hier gegen eine Koexistenz oder eine Zusatzspezifikation "on top of IHE" gesprochen? Das hätte sogar eine offizielle National Extension werden können. Mit derartigen Veränderungen ist eine internationale Verankerungen so gut wie ausgeschlossen, weil das über die einzuhaltenden Veränderungsprozesse (Change Proposal) so nicht dursetzbar ist. Damit ist und bleibt das eine spezifisch deutsche Vorgabe, die so nirgendwo auf der Welt Anwendung finden wird. (Weitere Anmerkungen sind in den Kommentaren des bvitg zu finden.)

Entscheidung der gematik

25.04.2019

Aufgrund der eingegangenen Stellungnahmen wurde eine erneute Prüfung der Interoperabilitätsbewertung durch die gematik vorgenommen.

In der nächsten Version der Spezifikation (Dokumentenrelease 3.1.0) wird das Verbot des Vorhandenseins von ATNA-Funktionalität aufgehoben. Es werden lediglich Einschränkungen bzgl. des Einsatzes veralteter TLS-Standards und nicht Datenschutzkonformer Protokollierungsinhalte gemacht.
Zu CT: IHE CT verwendet NTP 3. Der gematik-Zeitdienst läuft auf Basis von NTP Version 4, welche auch von den Clients gefordert wird. Version 4 hat gegenüber Version 3 u. a. eine höhere Genauigkeit und weitere Verbesserungen. Eine gleichzeitige Verwendung erscheint wenig sinnvoll, da die IHE-Implementierung die Systemzeit einerseits ein zweites mal stellen würde und andererseits aufgrund der geringeren Genauigkeit die Uhr sogar genau genommen verstellen würde.Die Prüfung auf ein gesperrtes DF.HCA bildet die Anforderung ab, dass nur gesetzlich Versicherte die ePA nutzen sollen, das betrifft auch Vertreter.
Die Prüfung auf ein gesperrtes DF.HCA erfolgt ausschließlich beim Zugriff des Versicherten mittels seiner eGK und findet bei Nutzung der alternativen Authentisierung keine Anwendung.Die im neuen Terminservice- und Versorgungsgesetzes geforderte alternative Authentisierung an der ePA wird durch die gematik bis Mitte Mai 2019 spezifiziert.
Weitere ungeklärte Fragen und Anmerkungen in Bezug auf einzelne Spezifikationen und der IHE-Konfirmität im Gesamten befinden sich derzeit noch in Abstimmung.

Der vorliegende Bewertungsentwurf bleibt unverändert und die beantragte Festlegung wird mit dem Attribut „interoperabel mit den gematik-Spezifikationen/ Interoperabilitätsfestlegungen“ in vesta aufgenommen.