Mit der ePA für alle sind DiGA-Hersteller in der Pflicht, strukturierte Nutzungsdaten sowie begleitende Berichte sicher, interoperabel und gemäß gesetzlicher Vorgaben in die ePA zu übertragen. Die technischen Anforderungen dafür sind eindeutig – aber in der Umsetzung zeigen sich viele Details erst in der Praxis.

In den letzten Monaten haben mehrere Hersteller unsere Open-Source-Lösung, den _fbeta-ePA-Client, integriert. In diesem Artikel geben wir einen Einblick in typische Herausforderungen, die dabei aufgetreten sind – und wie sie gelöst wurden. Die Fälle sind anonymisiert, beruhen aber auf konkreten Erfahrungen.

Die technische Grundlage zu unserem Open-Source-Client gibt’s hier:  fbeta ePA-Client – Eine Open-Source-Lösung für die sichere und einfache Anbindung von DiGA an die ePA für alle

Was sind typische Probleme bei der ePA-Anbindung?

Referenzumgebung ≠ Produktivumgebung

Die Aktensystemanbieter stellen Referenzumgebungen (RU und RU2) für die ePA bereit. DiGA-Hersteller können dann auf diesen Referenzumgebungen ihren Zugriff auf die ePA testen. Die Produktivumgebung (PU) darf nicht zu Testzwecken genutzt werden. Erst nach einem erfolgreichen Testen in der Referenzumgebung sollte man das Schreiben in das Aktensystem der Produktivumgebung in Aussicht stellen. In diesen Umgebungen gibt es standardisierte Aktenanbieter, Authentifizierungsdienste und VAU-Komponenten. Im realen Produktivbetrieb kommen jedoch echte Aktenanbieter mit leicht variierendem Verhalten zum Einsatz.

Ein technischer Unterschied zwischen der Referenz- und der Produktivumgebung besteht in der Kommunikation über den externen HTTP-Request mit dem VAU-Kanal. VAU steht für „Vertrauenswürdige Ausführungsumgebung“ (englisch: Trusted Execution Environment) und ermöglicht durch einen initialen Schlüsselaustausch eine symmetrische Verschlüsselung der Nachrichtenkommunikation über dedizierte Endpunkte.
In der Referenzumgebung müssen nach erfolgreicher Schlüsselaushandlung mit den VAU-Komponenten die ausgehandelten symmetrischen Schlüssel K2_c2s_app_data und K2_s2c_app_data base64-kodiert im HTTP-Request-Header unter dem Feldnamen „VAU-nonPU-Tracing“ bei jedem externen HTTP-Request übermittelt werden. Dieser Header ist in der Produktivumgebung nicht erforderlich und kann dort weggelassen werden.

DiGA-Hersteller sollten vor dem Übergang in das Produktivsystem umfassend ihren Zugriff auf die ePA in der Referenzumgebung testen. Ebenso ist es entscheidend, in der Produktivumgebung die korrekten Endpunkte anzusteuern. Der Open-Source-_fbeta-ePA-Client ermöglicht durch das Setzen einer Umgebungsvariable einen einfachen Wechsel zwischen Referenz- und Produktivumgebung. Dadurch können Konfigurationen, die erfolgreich in der Referenzumgebung getestet wurden, unkompliziert in die Produktivumgebung übernommen werden.

Valide MIO-Daten konfigurieren

Eine DiGA muss gültige MIO-Dokumente gemäß der Spezifikation der KBV (Kassenärztliche Bundesvereinigung) erstellen, bevor sie diese in die elektronische Patientenakte (ePA) übertragen kann. MIOs (Medizinische Informationsobjekte) sind standardisierte Datenmodelle, die medizinische Informationen strukturieren und codieren. Durch diese Standardisierung wird eine Interoperabilität zwischen verschiedenen digitalen Gesundheitssystemen sichergestellt.

Für DiGAs ist es entscheidend, Gesundheitsdaten im MIO-Format zu exportieren, um eine einheitliche und interoperable Kommunikation mit der ePA zu ermöglichen. Nur so können die von der DiGA erzeugten Daten korrekt in der ePA gespeichert, von anderen medizinischen Systemen verarbeitet und von Behandelnden zuverlässig genutzt werden.

Die ePA 3.0 kontrolliert die XML-Syntax der SOAP-Nachrichten. Die Syntax der angehängten MIO-Dokumenten wird beim Schreiben in das Aktensystem nicht kontrolliert. Eine inhaltlich nicht valide oder syntaktisch unkorrekte MIO wird also dennoch in die ePA übertragen werden – was die Bedeutung inhaltlicher Validierung zusätzlich unterstreicht.  Um die Interoperabilität und den korrekten Nutzen der MIO zu garantieren, ist es demnach wichtig zugelassene und valide MIOs zu generieren, um diese dann in die ePA schreiben zu können. Sie hierzu auch in unserem _hub Anwendung des DIGA-MIO-Baukastens

Der _fbeta-ePA-Client (Open-Source-Lösung) übernimmt mit einer automatischen SOAP-Generierung einen Großteil der korrekten XML-Syntax-Formatierung, um in die ePA schreiben zu können. Um auch valide MIOs zu generieren, bietet _fbeta die Möglichkeit, über Workshops, Data Reviews und kollaboratives Arbeiten eine MIO-Datenstruktur zu erstellen, die die medizinisch relevanten Aspekte Ihrer DiGA abdeckt, um diese dann nutzbringend in die ePA schreiben zu können.

Notwendiges Grundverständnis der Akteure, Daten und Prozesse

Damit eine DiGA Daten in die ePA schreiben kann, müssen drei Workflows durchlaufen werden, um eine vertrauliche Ausführungsumgebung (den VAU-Kanal) aufzubauen, den Autor und die Ziel-KVNR zu authentifizieren, das Schreiben in die ePA zu autorisieren und eine SOAP-Nachricht zu konstruieren, um schließlich in die ePA schreiben zu können.

An diesen Prozessen sind mehrere Akteure beteiligt, wie das Kartenterminal, der TI-Konnektor, das VAU-Modul des Aktensystems, der Autorisierungsserver des Aktensystems, das Aktensystem selbst und der zentrale IDP-Server. Diese Akteure erfüllen unterschiedliche Aufgaben und werden von unterschiedlichen Organisationen verwaltet.

Daher ist es wichtig, zumindest ein grobes Verständnis davon zu haben, welche Akteure es gibt, was ihre Aufgaben sind und von wem sie administriert werden, um Fehlerquellen schnell zu verstehen und im Zweifelsfall sogar selbst beheben zu können. Wenn z. B. der eigene Server keine Verbindung zum Konnektor aufbauen kann, könnte dies an einem Fehler in der VPN-Verbindung oder auch am Konnektor liegen. Um dem auf den Grund zu gehen, könnte man die VPN-Verbindung auf dem eigenen Server überprüfen oder den Konnektor-Host kontaktieren.

Mit einem Verständnis der relevanten Daten, die während des Verbindungsaufbaus generiert werden, kann auch ein effizientes Caching von Verbindungs- und Authentisierungstoken genutzt werden, um u. a. den gesamten Aufbauprozess zu überspringen und direkt in die ePA zu schreiben.

Empfohlene Lösung: _fbeta liefert hier ein getestetes Docker-Image, das entsprechende Caching der relevanten Verbindungsdaten sowie genaue Hinweise und Fehlercodes, so dass Hersteller ggf. mit automatisierten Prozessen reagieren können. Darüber hinaus stellt _fbeta eine Dokumentation zur Verfügung, die genannten Akteure, Verbindungsdaten und ihre relevanten Aspekte leicht verständlich erklärt.

Unsere Lessons Learned aus den bisherigen Projekten mit dem _fbeta-ePA-Client

Die Einführung der ePA für alle bringt standardisierte Anforderungen – aber jeder Hersteller hat individuelle Rahmenbedingungen, Infrastrukturen und MIO-Strategien. Die Anbindung an die ePA für alle ist also kein Plug-and-Play – aber lösbar.
Der _fbeta ePA-Client hilft, viele Hürden zu abstrahieren – die tatsächliche Implementierung bleibt dennoch ein Prozess, in dem gute Vorbereitung und gemeinsames Debugging den Unterschied machen.

Wir hoffen, diese Einblicke geben anderen DiGA-Herstellern eine realistische Einschätzung, worauf es bei der ePA-Anbindung ankommt.

Falls ihr euch ebenfalls auf den Weg macht oder überlegt, wie ihr eure TI-Integration zukunftssicher aufstellen wollt: Wir stehen gern mit Rat und Code zur Seite.

📩 Kontakt: epa@fbeta.de