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
Die Kommentierung endet in 6 Tagen, 17 Stunden und 4 Minuten.

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.

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

  • Name: Kim Becker

    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.

  • Name: Mathias Aschhoff

    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