» Fünf Sekunden halte ich für machbar «

Im Überblick: Was ist aus technischer Sicht das „Neue“ an der neuen ePA?
Es gibt zwei wichtige Punkte. Zum einen wird die Sicherheitsarchitektur verändert: Auf eine Ende-zu-Ende-Verschlüsselung wird verzichtet. Das wird es nicht zuletzt Ärztinnen und Ärzten ermöglichen, mit den ePA-Inhalten viel besser zu arbeiten als bisher. Zum Zweiten, und das hängt mit der neuen Architektur zusammen, gibt es Veränderungen, die sich sehr positiv auf Performance und Stabilität auswirken werden. Die ePA wird – zumindest mittelfristig, vielleicht nicht gleich zum 15. Januar 2025 – schneller und weniger störanfällig.

Beginnen wir mit der Sicherheitsarchitektur: Was ändert sich da konkret?
Die bisherige ePA sieht vor, dass ein Dokument, das in der Arztpraxis hochgeladen wird, vom Konnektor verschlüsselt und dann verschlüsselt auf dem Server abgelegt wird. Entsprechend werden Dokumente beim Herunterladen vom Konnektor entschlüsselt, analog beim Versicherten. Damit sind die Dokumente auf dem Server selbst tot: Dort kann damit nichts gemacht werden. Das wird jetzt geändert. Auch künftig werden die Daten verschlüsselt übertragen und natürlich auch verschlüsselt gespeichert. Aber es gibt ein Zeitfenster, in dem die Daten bzw. Dokumente im Server in einer sogenannten vertrauenswürdigen Ausführungsumgebung (VAU) im Klartext vorliegen. Für die VAU wird die gleiche Technik genutzt, die auch beim E-Rezept-Server schon genutzt wird.

Warum macht das Sinn?
Es geht bei der ePA ja nicht um eine Datenübertragung von Punkt A nach Punkt B, sondern um eine potenziell lebenslange Akte, die Daten und Dokumente enthält, mit denen ich nach Jahren oder sogar Jahrzehnten noch arbeiten will. Auch der Server selbst sollte in meinem Auftrag mit meinen Daten arbeiten können. Das wird jetzt möglich. Ärztinnen und Ärzte könnten Dokumente serverseitig durchsuchen lassen, das Handling von Medikationsplan bzw. Medikationsliste wird unkomplizierter. Und auch Performance und Stabilität der ePA werden sich verbessern.

Wie hängen Sicherheitsarchitektur und Performance bzw. Stabilität zusammen? Das sind ja wesentliche Kritikpunkte der Ärzteschaft an der bisherigen ePA.
Wenn man darauf verzichtet, Daten und Dokumente vor Ort in der Arztpraxis zu verschlüsseln und später wieder zu entschlüsseln, dann kann man sich auch den Konnektor-Fachmodul-Anteil sparen. Das wiederum heißt: Bei der neuen ePA greifen die Primärsysteme, also Praxisverwaltungssystem (PVS), Krankenhausinformationssystem (KIS) und Apothekeninformationssysteme (AIS), direkt auf das ePA-Aktensystem zu. Beides, der Verzicht auf die Verschlüsselung im Konnektor beim Upload und Download und der Verzicht auf die Konnektor-Fachmodule, macht das System schneller. Zusätzlich bekommen wir eine Verringerung der Komplexität, weil nur noch die PVS mit den Aktensystemen interagieren, und nicht noch Konnektoren von drei verschiedenen Herstellern dazwischengeschaltet sind. Weniger Komplexität macht weniger Fehleranfälligkeit macht mehr Stabilität.

Nun wurde die Ende-zu-Ende-Verschlüsselung ja seit Ulla Schmidt als das sicherheitstechnische Nonplusultra propagiert. Generationen von Datenschützern haben immer wieder aufgeschrien, wenn es jemand wagte, sie infrage zu stellen. Werden die Daten in der ePA jetzt sehr viel weniger sicher?
Aus meiner Sicht nicht. Wir haben in der ePA einen patientenindividuellen Schlüssel. Allerdings wird dafür heute schon nicht der Schlüssel der eGK verwendet, sondern ein Schlüssel eines zentralen sogenannten schlüsselhaltenden Dienstes, gegenüber dem sich der Patient oder die Patientin mit seinem oder ihrem eGK-Schlüssel authentifiziert. Das wird deswegen so gemacht, damit bei Verlust und Neuausstellung einer eGK nicht die gesamte ePA verloren ist. Bei der zukünftigen ePA wird im Prinzip der gleiche Mechanismus genutzt, die Daten werden weiterhin patientenindividuell verschlüsselt gespeichert. Sie werden auch verschlüsselt transportiert. Der Unterschied ist das temporäre Aufbrechen der Ende-zu-Ende-Verschlüsselung für die serverseitige Verarbeitung der Daten in der VAU – unter Ausschluss des Betreibers. Das ist der Preis für mehrwertstiftende Services.

Lassen Sie uns auf ein paar Punkte etwas genauer eingehen. Was kann aus Ihrer Sicht von der neuen ePA in Sachen Performance erwartet werden?
Heute dauert ein Zugriff eines Arztes auf das Aktensystem zwischen 10 und 40 Sekunden, bevor er die Akte überhaupt sieht. Datei-Upload- und -Download-Vorgänge dauern dann auch gern noch mal 10 bis 15 Sekunden. Das ist der Status quo. Wenn man jetzt in das Fachkonzept der neuen ePA schaut, steht dort, dass der Arzt binnen 3 Sekunden die Akte über sein Primärsystem öffnen und ein 5 MB großes Dokument hochladen können muss. Das ist die Zielvorgabe. Damit lässt sich in jedem Fall arbeiten. Der Pferdefuß ist, dass diese Zeit in den Spezifikationen so nicht auftaucht. Die Zeitvorgaben in der Spezifikation kann man aufaddieren, und da landen wird dann eher bei 10 bis 30 Sekunden. Da ist also schon noch ein bisschen Spielraum. Ich persönlich halte die 3 Sekunden für schwer erreichbar, aber wenn die ePA binnen 5 Sekunden offen ist, dann wäre das auch schon ein Riesenfortschritt. Und das halte ich durchaus für machbar.

Stichwort Stabilität: Sie hatten schon den Wegfall des Konnektor-Fachmoduls genannt, der Komplexität reduziert. Wo wird in Sachen Komplexität noch Hand angelegt?
Auch aufseiten der Aktensysteme wird deutlich verschlankt. Vorher war es so, dass pro Kasse eine eigene
Aktensystem-Instanz laufen musste. Das ist jetzt anders: Die Aktensysteme dürfen als ein System betrieben werden und sind intern mandantenfähig. Das heißt: Die Akten-Provider müssen nur noch ein Aktensystem betreiben, auf dem dann die unterschiedlichen Krankenkassen laufen, sauber getrennt natürlich. Auch das reduziert Komplexität und erhöht damit die Stabilität. Dann kommt noch dazu, dass das Session-Handling geändert wurde. Die VAU gab es bei der alten ePA im Prinzip auch schon. Da musste aber noch für jede ePA eine eigene VAU-Instanz hochgefahren werden.  Das kostete auch immens Zeit. Jetzt soll es eine VAU-Instanz pro Nutzer, also zum Beispiel pro Apotheke oder pro Arztpraxis, geben, innerhalb derer dann bis zu 80 ePAs geöffnet werden können. Das macht vieles einfacher, sowohl aufseiten der Aktensysteme als auch aufseiten der Primärsysteme.

Welche Vorteile ganz konkret bringt die Möglichkeit der serverseitigen Verarbeitung von ePA-Daten für die medizinischen Anwenderinnen und Anwender? Bei Dokumenten, aber auch zum Beispiel beim Medikationsplan?
Bei der Medikation ist die Sache insofern etwas komplexer, als die Medikation zur allseitigen Überraschung (und Begeisterung) jetzt doch in einer Datenbank laufen soll. Neben der Dokumentenverwaltung, also der Verwaltung von PDF, XML-Dokumenten und medizinischen Informationsobjekten (MIO), gibt es beim ePA-Server jetzt auch einen Datenbankanteil, einen FHIR-Server. Der wird von Beginn an zur Verwaltung der Medikationslisten verwendet und soll danach auch beim Medikationsplan genutzt werden. Auch das funktioniert übrigens nur, weil man auf eine Ende-zu-Ende-Verschlüsselung verzichtet hat. Ein entscheidender Punkt sind aus meiner Sicht die Suchanfragen. In meinen Gesprächen mit Ärztinnen und Ärzten ist die Aussage immer: „Ich will nicht nach Metadaten suchen, sondern ich will konkrete Anfragen an das Aktensystem stellen.“ Also zum Beispiel: Wie waren die HbA1c-Werte in der Vergangenheit? Gab es schon mal eine Diagnose „chronische Bronchitis“ oder gab es schon mal eine Diagnose mit dem ICD-Code xy? Das ginge künftig mit der neuen ePA, und das wäre ein Riesenmehrwert. Konjunktiv deswegen, weil es zunächst mal noch nicht gehen wird: Die gematik sieht eine Volltextsuche in der aktuellen Spezifikation nicht vor. Das tut weh, und ich finde es unverständlich. Das sollte mit Blick auf die Akzeptanz der ePA bei den medizinischen Einrichtungen dringend geändert werden.

Wie sieht es bei der Medikation aus?
Durch den angesprochenen FHIR-Server muss bei Änderungen des Medikationsplans künftig nicht mehr die gesamte Datei jeweils runter- und wieder hochgeladen werden. Das ist, siehe oben, nicht zuletzt ein Performance- und Stabilitätsvorteil. Ein Medikationsplan in einer Datenbank ist schneller, flexibler und weniger fehleranfällig. Wir hatten daher bei unserer Initiative #better_eMP auf genau eine solche Lösung gedrängt. Zusätzlich werden auch bei der Medikation die besagten Abfragen möglich: Welche Antibiotika wurden in der Vergangenheit verordnet? Welche Dosis hatte Medikament xy bei der letzten Verordnung? Auch hier gilt: Das wird so nicht am 15. Januar 2025 funktionieren, schon deswegen nicht, weil die derzeitige Spezifikation für die ePA 3.0 nur die Medikationsliste kennt, also die verordneten Medikamente, aber noch nicht den kuratierten Medikationsplan, der dann auch Dosierungen und andere Informationen enthält. Der Medikationsplan kommt dann erst im nächsten Schritt. Auch bei der Medikationsliste gibt es übrigens eine Einschränkung: Der Gesetzgeber sieht vor, dass alle in der Apotheke dispensierten Medikamente in der ePA auftauchen, unabhängig davon, ob sie über ein E-Rezept, über Muster 16 oder als Betäubungsmittel verordnet oder auch selbst erworben wurden. Das gibt die derzeitige gematik-Spezifikation noch nicht her: Sie sieht bisher nur Dispensierinformationen vor, die zu E-Rezept-Verordnungen gehören. Auch das halte ich eigentlich für problemlos änderbar, die Dispensierinformationen liegen in der Apotheke ohnehin digital vor. Das müsste das Bundesgesundheitsministerium meines Erachtens im Rahmen seiner Rechtsaufsicht beanstanden.

Auch die Forschung mit ePA-Daten soll durch die neue ePA-Architektur einfacher werden, richtig?
Ja. Allerdings ist auch die Übermittlung von Daten an das Forschungsdatenzentrum erst für die nächste Ausbaustufe der ePA zu Juli 2025 vorgesehen. Durch die neue Architektur kann prinzipiell jeder ePA-Nutzer Daten spenden. Mit der bisherigen Architektur wäre das nur möglich gewesen, wenn die ePA-App installiert ist und das Frontend geöffnet wird. Mit anderen Worten: Der Forschungsdatensatz aus der ePA dürfte perspektivisch durch die neue Architektur deutlich breiter werden. Allerdings sind natürlich primär strukturierte Daten für die Forschung interessant, also die MIOs. Die gibt es in der ePA aber noch gar nicht, insofern stellt sich die Forschungsfrage nicht akut. Allenfalls die Medikation könnten ein Kandidat sein, aber diese Daten sind auf anderen Wegen auch schon zugänglich, und da dann vollständiger.

Welche anderen, nicht primär medizinischen Arten der serverseitigen Datenverarbeitung wären mit der neuen Architektur noch denkbar bzw. sinnvoll?
Was mir da als Erstes einfällt, sind Virenscanner. Man könnte beim zentralen Aktenprovider zusätzlich zu den ohnehin nötigen Virenscannern auf Ebene der medizinischen Einrichtungen einen weiteren Virenscanner laufen lassen, der alle eingestellten Dokumente nochmals prüft und verdächtige Dokumente in Quarantäne stellt. Ich hielte das für sehr sinnvoll, und es ist bei zentraler Datenhaltung eigentlich auch üblich. Aber es ist derzeit noch nicht von der gematik vorgesehen. Warum das so ist, erschließt sich mir nicht, insbesondere wenn man bedenkt, dass ja auch die Versicherten von ihren ePA-Apps aus Dokumente hoch- und runterladen sollen und dass auf Mobilgeräten typischerweise keine Virenscanner installiert sind. Das ist umso fataler, als die gematik eine Verschärfung bezüglich der zugelassenen Dokumentenformate plant.

Worum geht es da genau?
Die gematik will künftig bei PDF-Dokumenten nur noch PDF/A zulassen, kein konventionelles PDF mehr, und zwar unter Verweis auf Sicherheitsrisiken. Man kann das sicherheitstechnisch begründen, weil in normalen PDFs auch zum Beispiel ausführbarer Java-Code enthalten sein kann. Aber es wäre für die Versorgung eine Katastrophe: Die meisten Dokumente, die im deutschen Gesundheitswesen bewegt werden, liegen nicht in PDF/A vor, der eArztbrief ist da die Ausnahme, und auch da wird es meines Wissens nicht überprüft. Hätte man einen Virenscanner, bräuchte man die Einschränkung auf PDF/A nicht, denn der würde enthaltenen Schadcode erkennen und Alarm schlagen. Nun kann man PDF in PDF/A konvertieren, das stimmt. Aber dabei erzeuge ich eine neue Datei, die Konvertierungsfehler haben kann und die der Arzt deswegen überprüfen müsste, was aber niemand tun wird. Unabhängig davon entstehen auf diese Weise auch massenhaft Dubletten. Besonders absurd ist, dass die E-Rezept-App im Rahmen der Abrechnungsinformationen derzeit auch normale PDF-, und nicht PDF/A-Dokumente
generiert. Da wird also ein Anspruch formuliert, den derzeit nicht mal die gematik selbst erfüllt. Hinzu kommt, dass die Abrechnungsinformationen im generierten PDF auch XML-Daten für die Versicherung enthalten. Würde ein solches PDF nach PDF/A konvertiert, gingen diese XML-Daten verloren und die Versicherung würde die Einreichung möglicherweise ablehnen. Ich kann daher als Versicherter noch nicht einmal meine Rezept-Abrechnungsinformationen in meiner künftigen ePA speichern. Auch die EKG-Dokumente aus Apple Watches sind nicht im PDF/A-Format und müssten zuerst konvertiert werden (mit erkennbaren Veränderungen). All das kann man keinem erklären – und es ist völlig unnötig.

Ein abschließendes Wort zu den Fristen. Ist der 15. Januar 2025 als Einführungstermin realistisch?
Der Umbau der Aktensysteme ist ein signifikanter Aufwand. Auch bei den Primärsystemherstellern ist einiges zu tun, schon weil das Konnektor-Fachmodul wegfällt. Die heutigen Primärsysteme werden nicht auf die künftige ePA zugreifen können. Das heißt: Wenn die beiden existierenden Aktensysteme zum 15. Januar für die Versicherten umgeschaltet werden, was sehr sportlich, aber nicht völlig unrealistisch ist, dann können nur solche Primärsysteme zugreifen, die ebenfalls bereits umgestellt wurden. Das wiederum halte ich für kaum zu schaffen, weil die Primärsystemhersteller immer das letzte Glied in der Kette sind. Sie brauchen ein funktionierendes Aktensystem, um testen zu können. Ich denke, dass die medizinischen Einrichtungen Mitte Januar noch nicht in großer Zahl auf die neue ePA zugreifen werden können. Dass das Testen eine Weile dauert, haben wir beim E-Rezept gesehen.


Das Interview führte Philipp Grätzel von Grätz, Chefredakteur E-HEALTH-COM.