ePA · FdV · Aktendienste

ePA-Aktenzugriff: Sitzung, Gerätebindung, Berechtigungen und Dokumentdienste

Der ePA-Zugriff verbindet einen geschützten VAU-Kanal und eine authentisierte userSession mit dem HealthRecordContext einer konkreten Akte. Gerätebestätigung, Befugnis, Widerspruch und Dokumentensichtbarkeit haben eigene Wirkungen. Das Entfernen eines Geräts beendet eine bereits aktive Sitzung nicht; logoutFdV ist eine separate Operation. XDS, MHD, Basic und Medication behalten ihre eigenen Dienstverträge. Die geprüften Produkt- und Anbietersteckbriefe bestimmen die Verantwortlichkeiten; HCSA veranschaulicht ausgewählte Abläufe mit synthetischen lokalen Daten.

Themen: ePAVAUHealthRecordContextDevice bindingMHDFHIR
Der Zusammenhang im Überblick

Sitzung und Aktenzugriff unterscheiden

  1. FdV · VAU · userSession

    Geschützter Kanal und authentisierte Sitzung

    für die konkrete Akte prüfen
  2. HealthRecordContext

    Aktenbezogene Befugnisse, Widersprüche und Sichtbarkeit

    je Dienstvertrag
  3. Dokumente und FHIR-Dienste

    XDS / MHD · Basic · Medication

Ausgewählte Zugriffsgrenzen. Gerätebestätigung, Sitzungsende und fachliche Freigabe haben eigene Regeln; dies ist kein universeller ZETA-Zugriffspfad.

ePA-FdV, Aktensystem und Betreiber

Der FdV-Produkttypsteckbrief 3.1.3-3, Dokument 1.0.0, bindet die hier betrachtete Dokumenten- und Zugriffsarchitektur an gemSpec_ePA_FdV 2.8.0, Aktensystem 1.8.2 und IDP Frontend 2.0.0. Dazu gehören Basic IG 1.3.2, MHD IG 1.1.3 und Medication IG 1.3.5. Das FdV ist das Versicherten-Frontend; das Aktensystem setzt Aktenhaltung und serverseitige Zugriffsprüfung um. Produktanforderungen an das Aktensystem und Anforderungen an dessen Anbieter stehen in eigenen PTV-/ATV-Steckbriefen 3.1.3-3. Ein mobiles UI-Konzept erfüllt diese drei Nachweisscopes nicht allein. Die Schnittstellenreferenzen ePA-Basic und ePA-XDS-Document sind auf ePA-3.1.3 und die dazu ermittelten unveränderlichen Commits festgelegt.

VAU-Kanal, userSession und konkrete Akte

Das FdV baut einen VAU-Kanal zum Aktensystem auf und prüft dabei dessen VAU-Zertifikat. sendAuthorizationRequestFdV leitet die Authentifizierung über GesundheitsID, sektoralen IDP und Authenticator ein; sendAuthCodeFdV übergibt den erhaltenen Autorisierungscode an das Aktensystem. Die authentifizierte userSession ist vom HealthRecordContext einer konkreten Akte zu unterscheiden. Eine Aktenanfrage benennt die Akte über x-insurantid und setzt die passende Befugnis sowie die weiteren Zugriffsprüfungen voraus. So können Inhaber und berechtigte Vertretung auf unterschiedliche Akten zugreifen. Ein generisches ZETA-Allow oder ein TI-M Client ePA Login ersetzt diesen ePA-FdV-Vertrag nicht.

Sitzung beenden und Gerät entfernen

logoutFdV beendet die userSession, löscht die zugehörigen temporären Sitzungsdaten und schließt ihre HealthRecordContexts. Für weiteren Zugriff sind eine neue Anmeldung und ein neu ausgehandelter VAU-Kanal erforderlich. Das FdV beendet die Sitzung spätestens 20 Minuten nach der letzten Nutzer-Aktivität; auch das Aktensystem besitzt eine Inaktivitätsregel. deleteDevice entfernt dagegen eine Gerätefreigabe. Laut Geräte-API bleibt eine bereits aktive userSession davon unberührt. Ein Produkt muss deshalb Abmelden und Geräteverwaltung als unterschiedliche Aktionen behandeln. Die lokale HCSA-Demo hält keine echte ePA-Sitzung und führt keine dieser Operationen aus.

Gerätebestätigung vor dem Aktenzugriff

Am Heimat-Aktensystem weist das FdV ein registriertes und bestätigtes Gerät mit x-device-identifier und x-device-token nach. Bei einem anderen Aktensystem dient eine Geräteattestierung des Heimat-Aktensystems als Nachweis. Fehlt die bestätigte Registrierung, bleibt die authentifizierte Sitzung auf die Geräteverwaltung beschränkt. registerDevice und confirmPendingDevice bilden Registrierung und Bestätigung ab; getDeviceAttestation setzt ein bestätigtes Gerät voraus. Der besondere Modus x-authorize-representative dient der Einrichtung einer Vertretung und beschränkt den Zugriff auf die Befugnisverwaltung. Er öffnet keine allgemeine Dokumentensitzung. GesundheitsID-Anmeldung, Gerätebestätigung und Aktenbefugnis haben somit jeweils einen eigenen Zweck.

Befugnis, Widerspruch und Sichtbarkeit

Entitlement Management verwaltet die Befugnis eines Akteurs auf eine bestimmte Akte. Der Inhaber hat eine statische Befugnis; eine Vertretung benötigt eine ausdrückliche Befugnis. setEntitlement verarbeitet einen signierten Befugnisnachweis, deleteEntitlement entzieht eine widerrufbare Befugnis. Consent Decision Management setzt dagegen den Widerspruch gegen definierte Funktionen um: permit bedeutet kein Widerspruch, deny einen Widerspruch mit funktionsabhängigen Folgen. Der allgemeine Widerspruch gegen die ePA selbst liegt außerhalb dieses Dienstes. Constraint Management steuert das Verbergen zulässiger Dokumente, Ordner oder Kategorien über GeneralDenyPolicies; emp und technical können hier nicht verborgen werden. Die serverseitige LegalPolicy und Rollenprüfung gelten zusätzlich. Favoriten in der HCSA-Demo sind lediglich lokale Lesezeichen und ändern keine dieser Berechtigungen.

Dokumente finden: XDS, MHD und Basic

XDS verwendet SOAP/WSDL, etwa DocumentRegistry_RegistryStoredQuery für Metadatensuche und DocumentRepository_RetrieveDocumentSet für den Abruf. Der zusätzliche MHD-Consumer des FdV nutzt DocumentReference-Suche und -read: Find Document References (ITI-67) verbindet Metadaten mit der Volltextsuche über _content. Jede MHD-Suche belegt mindestens patient.identifier und status; der Pfad lautet /epa/mhd/api/v1/fhir/DocumentReference. Retrieve Document (ITI-68) ruft den Inhalt über DocumentReference.content.attachment.url ab. Ein nicht vorhandenes und ein vor dem Anfragenden verborgenes Dokument liefern dabei beide 404. Basic IG 1.3.2 beschreibt unter anderem Patient und AuditEvent; Medication IG 1.3.5 beschreibt eML/eMP. Diese Verträge sind getrennt. Der HCSA-Filter durchsucht lokal Namen und Datum synthetischer Dokumente und implementiert keine MHD-Volltextsuche.

TI Common: PTV-Pin und Paketabhängigkeit

Der FdV-PTV 3.1.3-3 nennt TI Common 1.3.0. Die tatsächlich geprüften Pakete de.gematik.epa 1.3.2 und de.gematik.epa.mhd 1.1.3 deklarieren dagegen de.gematik.ti 1.3.1 als Abhängigkeit. Die beiden Common-Versionen sind deshalb getrennt dokumentiert. Ein konkreter Unterschied liegt im Profil TI Organization: 1.3.1 setzt mustSupport=true auf Organization.extension; in 1.3.0 fehlt diese Kennzeichnung an diesem Element. Das ist relevant für die Auswertung von Profilanforderungen und zugehörige Tests, beweist für sich allein aber keine Inkompatibilität im Datenaustausch. Eine offizielle Auflösung des Versionsunterschieds ist im geprüften Material nicht enthalten. Weder eine automatische Ersetzung des PTV-Pins noch eine pauschale Konformitätsaussage wird daraus abgeleitet.

Versionierte Primärquellen

Was hier ausdrücklich nicht behauptet wird: Dies ist eine quellenbasierte Erklärung ausgewählter ePA-Pflichten, kein Testergebnis für ein produktives FdV oder Aktensystem. Der PTV-Verweis auf Common 1.3.0 und die Paketabhängigkeit 1.3.1 bleiben getrennt dokumentiert; eine offizielle Auflösung enthält das geprüfte Material nicht.