Normative Verträge, Rollen und Architekturgrenzen.

Der TI-Flow-Fachdienst-Hersteller ist HCC-Workload-Hersteller: Er entwickelt, testet, dokumentiert und registriert das Workload-Release. Der Fachdienst-Anbieter ist HCC-Dienstanbieter: Er integriert den Dienst in seinen Mandantenkontext und verantwortet Betrieb, Monitoring und Support. Der HCC-Provider stellt Plattform und HSM-Cluster sowie den providerspezifischen Trust-Domain Build Service (TDBS) und den Trust-Domain Configuration & Attestation Service (TDCAS) bereit. Der übergreifende TI Verification & Build Service liegt in der Verantwortung der gematik; die providerspezifischen Build Services sind darin eingebunden. Die Rollen können organisatorisch verbunden sein; ihre Pflichten bleiben getrennt.

• gemSpec_FD_TI-Flow 1.0.0 · §5.2 ↗
• gemSpec_HCC 1.0.0 · §§ 7.5.8–7.5.9, 8.1, 14.8 · A_28996 ↗

OCI-konforme Workload-Images werden für den Trust-Domain Build Service bereitgestellt. HSM-Zugriffs-Credentials bezieht der Dienst vom Trust-Domain Attestation Service. Die Workload lädt ihre Konfiguration beim Start und muss für Änderungen neu instanziiert und attestiert werden können. Beliebige privilegierte Laufzeitadministration ist ausgeschlossen; vordefinierte Eingriffe auf Anwendungsebene und Policy-Administration bleiben im spezifizierten Rahmen möglich.

• gemSpec_HCC 1.0.0 · A_29661–A_29663 ↗

Der TI-Flow-Fachdienst verarbeitet alle fachlichen Operationen innerhalb der VAU. Schützenswerte Daten werden vor einer Speicherung außerhalb der VAU verschlüsselt; die Persistenzschlüssel bezieht der Dienst aus einem HSM der HCC-Plattform. Der ZETA Guard ist der einzige Eingang für Clientanfragen. Client bis Guard verwendet TLS und ASL; bei getrennten VMs sichert mTLS die Verbindung zwischen Guard und Resource Server ohne zusätzliche ASL. Die Fachautorisierung gilt weiterhin je Operation. Die E2EE-Grenze eines Headless Clients und die serverseitige VAU sind eigenständige Schutzkontexte.

• gemSpec_FD_TI-Flow 1.0.0 · S. 15 / p. 15; A_29709, A_29713, A_29715, A_29717–A_29719 ↗

A_29714 verlangt für persistierte Vorgangsdaten entweder einen eigenen Schlüssel je Vorgang oder mindestens einen Schlüsselwechsel pro Sekunde, sodass nur die in dieser Sekunde neu angelegten Vorgänge denselben Schlüssel nutzen. A_29715 bindet den Bezug an das HSM der HCC-Plattform. Die Spezifikation kennzeichnet eine mögliche spätere Ablösung von A_29714 als offenen Punkt; daraus folgt noch keine geänderte Vorgabe. Nach A_29732 werden aktiv verwendete Zertifikate auf Integrität und Authentizität geprüft. Ohne gültiges Ergebnis müssen die davon abhängigen Arbeitsabläufe abgelehnt werden; jeder verwendete öffentliche Schlüssel muss auf eine erfolgreiche Zertifikatsprüfung zurückführbar sein.

• gemSpec_FD_TI-Flow 1.0.0 · A_29714, A_29715, A_29732 · §5.1.4, §5.4 ↗

Sensible Informationen werden vor dem Speichern eines Systemprotokolleintrags entfernt. Zulässige Zwecke sind anlassbezogene Fehleranalyse und -behebung sowie Security Monitoring. Fehleranalyse-Protokolle sind nach Fehlerbehebung unverzüglich, Security-Monitoring-Protokolle nach drei Monaten zu löschen. Für gematik-Logdaten wird key_pn_log im Klartext ausschließlich in der VAU verarbeitet und im Vier-Augen-Prinzip eingebracht; für diesen besonderen Schlüssel ist eine Speicherung im VAU-HSM nicht zwingend.

• gemSpec_FD_TI-Flow 1.0.0 · A_29724–A_29726, A_29729, A_29731, A_30134–A_30135 ↗

HCC-Dienste unterstützen mehrere Instanzen auf verschiedenen Hosts, sodass Hostwechsel oder Neustarts den Service nicht unterbrechen. Der HCC-Dienst protokolliert Fehler- und Performancedaten genutzter Cloud-Services; der HCC-Dienstanbieter überwacht und steuert Kapazitäten und testet Änderungen des HCC-Stacks vor dem produktiven Einsatz. Der TI-Flow-Anbieter erfüllt zusätzlich seinen ATV und die dienstbezogenen Performance-Vorgaben. gemSpec_Perf 2.88.0 konkretisiert die Anbieterpflichten: A_29788 verlangt 99,99 % Verfügbarkeit zur Hauptzeit und 99,97 % zur Nebenzeit in den festgelegten Servicezeiten. A_29790 verlangt die betreffenden Medication-Übermittlungen innerhalb von zwölf Stunden, sofern technische Fehler im ePA-Aktensystem dies nicht verhindern; A_29791 verlangt Versand an das Push-Gateway innerhalb von 60 Minuten nach Ereignisgenerierung, sofern das Gateway erreichbar ist. Diese normativen Zielwerte müssen im konkreten Dienstbetrieb nachgewiesen werden. Ein lokales Readiness-Signal beschreibt nur einen Teil dieses Betriebsbilds.

• gemSpec_HCC 1.0.0 · A_29664–A_29666, A_29678 ↗
• TI-Flow FD ATV 1.0.0-0 · Dokument 1.0.0 ↗
• gemSpec_Perf 2.88.0 · §3.29 · A_29788 / A_29790 / A_29791 ↗

Für den TI-Flow-PTV ist gemSpec_Krypt 2.51.0 gebunden; der G-App-PTV-Entwurf nennt 2.49.1. Diese Referenzen werden pro Produkttyp geführt. Eine neuere allgemeine Kryptografie-Ausgabe ersetzt eine im Produktprofil gebundene Fassung nicht automatisch. Algorithmen, Zertifikatsprüfung, Schlüsselverwendung und Transport müssen im jeweiligen Rollen- und Versionskontext bewertet werden.

• TI-Flow FD PTV 1.0.0-0 / 1.0.0 · S. 6 / p. 6 ↗
• G-App PTV 1.0.0-0 / 1.0.0_CC · S. 6 / p. 6 · Draft_App ZIP ↗
• gemSpec_Krypt 2.51.0 · TI-Flow PTV baseline ↗
• gemSpec_Krypt 2.49.1 · G-App PTV draft baseline ↗

Der TI-M Pro Headless Client muss der alleinige kryptografische Endpunkt der Ende-zu-Ende-verschlüsselten Kommunikation sein. Schlüsselmaterial, interne E2EE-Zustände und rekonstruierbare Sicherheitsinformationen bleiben innerhalb seines geschützten Kontexts; Diagnose-Dumps dürfen sie nicht offenlegen. Für die Nachrichtenverschlüsselung verlangen TI-M Clients eine auditierte, als ausreichend sicher bewertete Olm/Megolm-Implementierung. Die Basis nennt Vodozemac und libolm; andere Implementierungen benötigen einen gleichwertigen Sicherheitsnachweis durch geeignete unabhängige Prüfer. Cross-Signing und Secure Secret Storage and Sharing (SSSS) zur Geräteverifikation sind ebenfalls zu unterstützen. Rust oder ein lokales ABI allein erfüllen diese Anforderungen nicht.

• gemSpec_TI-M_Pro 1.2.0 · A_28710 / A_28715 ↗
• gemSpec_TI-M_Basis 1.3.0 · A_25557 / A_25559 / A_25598 / A_25599 ↗

A_25299 verlangt TLS zwischen TI-M-Komponenten über virtuelle/physische Maschinengrenzen; A_25573 bindet gemSpec_Krypt ein. Eine ausdrückliche VoIP-Ausnahme wurde in den geprüften Quellen nicht gefunden. Deshalb beschränkt ITL den Entwurf auf zwei TURN-Allocations über TLS/TCP an derselben kontrollierten Instanz/VM und ausschließlich lokale Relay-Weiterleitung. turns-URL und relay-Candidate allein belegen den Pfad nicht; bei fehlender beidseitiger Zusicherung bleibt Calling nicht verfügbar. Das ist eine enge technische Herleitung, keine offizielle Auslegung. Allgemeine TLS-1.2-Unterstützung bleibt erhalten; TLS 1.3 ist die Wahl dieses Medienprofils.

• gemSpec_TI-M_Basis 1.3.0 · A_25299 / A_25573 ↗
• gemSpec_Krypt 2.50.0 · GS-A_4385 / A_18467 / A_18986 ↗
• RFC 8656 · §§ 3.1 / 12.6 / 21.1.6 ↗

party_id identifiziert eine Call-Partei, muss aber nicht der Matrix-Geräte-ID entsprechen. Matrix 1.17 verbietet, äußere Megolm-Felder sender_key/device_id als Ursprungsnachweis oder Session-Index zu verwenden. Der Entwurf bindet den geprüften Benutzer und Geräte-Vertrauensnachweis über die validierte Session an Raum, call_id, party_id und SDP-Fingerprint. Erst ein passender DTLS-Handshake und der zulässige Relay-Pfad geben Medien frei. Explizit bestätigtes Gerätevertrauen vor Calling ist eine strengere ITL-Policy; TLS zum Homeserver allein authentisiert den Medienpartner nicht.

• Matrix 1.17 · Voice over IP / Party Identifiers ↗
• Matrix 1.17 · m.megolm.v1.aes-sha2 ↗
• Matrix 1.17 · Verification of the sending user ↗
• RFC 8827 · § 4.3 / § 6.5 ↗

ZETA 1.3.2 ist die freigegebene Quelle für die hier erläuterte allgemeine Client-/Guard-Architektur. Der G-App-Entwurfssteckbrief nennt dagegen gemSpec_ZETA 2.0.1_CC und gemSpec_Krypt 2.49.1 als Abhängigkeiten. Der exakte ZETA-Quelltext 2.0.1_CC und eine Berichtigung dieses Pins konnten im geprüften öffentlichen Quellenbestand nicht verifiziert werden; dieser Teil des G-App-Abgleichs bleibt offen. Der öffentlich vorliegende Entwurf 2.0.0_CC vom 09.07.2026 ergänzt den mobilen Architekturkontext. Er wird ebenso wie 1.3.2 mit seinem eigenen Geltungsbereich erläutert und ersetzt die G-App-Abhängigkeit 2.0.1_CC nicht.

• G-App PTV 1.0.0-0, V1.0.0_CC · Tabelle / Table 1, S. / p. 6 · im / in ZIP ↗
• gemSpec_ZETA 1.3.2 · 26.06.2026 ↗
• Draft_ZETA_26_2 · veröffentlicht / published: 2.0.0_CC ↗
• ZETA Guard Verzeichnis 1.3.0-0 / 1.0.2 · Tabelle / Table 1: ZETA 1.3.2 ↗

Rechnungsmetadaten für RE-PS und KTR-PS dürfen keine Rückschlüsse auf die vom Versicherten verwalteten Status oder Markierungen erlauben. Das Berechtigungsmanagement ist eine separate HTTP-REST-Schnittstelle mit KVNR-Claim sowie permission.r zum Lesen und permission.u zum Bearbeiten. Im MVP verwaltet der FD ausschließlich Rechnungsversandberechtigungen: Sie entstehen bei der ersten Rechnung des Rechnungserstellers; Versicherte können bestehende Berechtigungen auflisten, entziehen und wieder erteilen. Daraus folgt keine allgemeine Freigabe persönlicher Rechnungsmetadaten oder beliebiger medizinischer Daten.

• gemSpec_DiPag_FD 1.1.3_CC · A_29954 / A_29955 / A_25967-01 / A_26043-01 ↗

Der DiPag-Fachdienst protokolliert unter anderem Änderungen an Markierungen mit Dokumentbezug und verantwortlichem Akteur. Ein Nutzerprotokolleintrag ist nach drei Jahren ab Zugriffszeitpunkt innerhalb eines Monats zu löschen. Das FdV stellt Einsicht und Export bereit. Die lokale Aktivitätsliste dieser Demo bleibt flüchtige Bedienhistorie; sie ersetzt weder das Fachdienst-Nutzerprotokoll noch dessen Aufbewahrungs- und Löschregeln.

• gemSpec_DiPag_FD 1.1.3_CC · A_25987 / A_29995 ↗
• gemSpec_App 1.0.0_CC · A_30080 / A_30081 ↗

Service Discovery bestimmt den Guard und seine Endpunkte. Registrierungsdaten einschließlich client-id werden pro Guard geführt; der mobile Registrierungsablauf bindet lokal erzeugte geschützte Schlüssel, OIDC-Nutzerauthentifizierung, Attestierung und eine Offband-Bestätigung ein. Für Sitzungen sind OAuth mit PKCE, sichere Access-/Refresh-Token- und DPoP-Schlüsselverwaltung sowie Refresh-Token-Rotation beschrieben. Nutzer können registrierte Clients einsehen und deregistrieren. Dienstspezifische Berechtigungen bleiben separat. Der Zwölf-Screen-Flow illustriert Entscheidungen an einer fiktiven Ressource demo.document; er implementiert diesen Protokollablauf nicht. Die offenen mobilen Details in 1.3.2 bleiben vom G-App-Versionsabgleich getrennt.

• gemSpec_ZETA 1.3.2 · §§ 5.8.2–5.8.5 · A_28465 / A_28524 / A_25432-01 / A_25769 / A_25733 / A_25781 / A_25782 ↗

Der öffentlich vorliegende Entwurf beschreibt die mobile Registrierung mit lokal erzeugtem Schlüssel, Attestierungsnachweis und beim Erstkontakt E-Mail-OTP-Bestätigung. Der schnelle Registrierungsweg setzt einen bereits gültigen ZETA-Attestierungstoken und weitere Schlüsselprüfungen voraus. Android-Hardwareattestierung und Apple App Attest werden plattformspezifisch behandelt; der Software-Fallback besitzt keine Hardware-Vertrauensbindung und erhält eine niedrigere Vertrauensbewertung. Für OIDC beschreibt der Entwurf Authorization Code, PAR und PKCE sowie DPoP-gebundene Access-Token. Der Fach-Client bestimmt den fachlichen Aufruf und den IDP-Kontext; der ZETA Client verwaltet Registrierung, Schlüssel und Authentifizierungsablauf. Diese Aussagen beziehen sich ausschließlich auf 2.0.0_CC. Der illustrative Zwölf-Screen-Flow bleibt ein ITL-Beispiel ohne Implementierungsnachweis.

• gemSpec_ZETA 2.0.0_CC · § 5.3.2 · A_29658 / A_29809 / A_29810 / A_29659 · Kontext, kein Ersatz für / context, not a substitute for 2.0.1_CC ↗

Der G-App-PTV enthält 57 unterschiedliche ZETA-Anforderungs-IDs mit 66 Prüfzuordnungen. Er nennt ausdrücklich 2.0.1_CC. Im geprüften Kontextentwurf 2.0.0_CC stehen A_25783-01 und A_27379-02, während der PTV A_25783-02 und A_27379-03 auswählt. Die 55 dort gefundenen identischen IDs belegen keine Textgleichheit zur fehlenden Ausgabe. Die SDK-Ausnahme in § 3.2.1 betrifft nur bereits durch Zeta-SDK-Funktionalität abgedeckte Anforderungen der Tabelle 7; übrige Prüfungen und Herstellerpflichten bleiben eigenständig. A_25735-01 steht sowohl in der allgemeinen UX-Tabelle 5 als auch in Tabelle 10 der Option PushNotification. Beide Zuordnungen bleiben erhalten. Der Katalog macht den PTV-Bezug prüfbar; der volle Inhalt von 2.0.1_CC bleibt offen.

• G-App PTV 1.0.0-0 / 1.0.0_CC · Tabellen / Tables 1, 4–5, 7–10 ↗
• ZETA 2.0.0_CC · ausschließlich ID-Vergleich / ID comparison only ↗

Der freigegebene Verzeichnissteckbrief ZETA Guard 1.3.0-0, Dokument 1.0.2 vom 30.06.2026, bindet in Tabelle 1 gemSpec_ZETA 1.3.2 und gemSpec_Krypt 2.47.0. Seine Prüftabellen wählen konkrete Anforderungs-IDs aus; ein Verweis auf die Spezifikation macht nicht automatisch jeden Absatz zur ausgewählten Guard-Pflicht. Die öffentliche Zuordnung nennt deshalb ID, Quellenversion, verantwortliche Komponente und die vorhandenen Prüfzuordnungen. Die G-App-Basis besitzt eine eigene Entwurfsreferenz auf ZETA 2.0.1_CC und Krypt 2.49.1; diese Referenzkette bleibt getrennt.

• gemSpec_ZETA 1.3.2 · § 1.3 · Anwendbarkeit / applicability ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

Der Client prüft aktiv verwendete Zertifikate einschließlich Hostname, Gültigkeit, Vertrauenskette und Widerruf nach A_25340-01; von einer ungültigen Prüfung abhängige Abläufe werden abgelehnt. Well-known-Abfragen verwenden ETag und If-None-Match. Ohne Cache-Control werden Well-known und JWKS alle 24 Stunden neu geladen; ein 404 beim Aufbau der Ressourcenkommunikation löst erneute Discovery aus. Der Guard veröffentlicht genau einen logischen Authorization Server. Die Registrierung erfolgt pro Guard; client-id sowie Registrierungs- und Konfigurationsdaten bleiben diesem Guard zugeordnet. Eine fachliche App-Kachel ist keine eigene Registrierungsinstanz.

• gemSpec_ZETA 1.3.2 · A_25340-01 / A_28425-01 / A_28426 / A_28464 / A_28465 / A_28524 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

Der PEP HTTP Proxy prüft Signatur, zeitliche Gültigkeit, Audience und Scope des Access Tokens sowie die DPoP-Bindung; die DPoP-Prüfung folgt RFC 9449. Ein ungültiges Access Token führt gemäß A_25668 zu HTTP 401. A_28525-01 verlangt ein Step-up-Signal mit HTTP 401, wenn bei einer existierenden, unterstützten URL der benötigte Scope fehlt oder die Audience nicht passt. Daraus folgt keine Regel, nach jedem beliebigen 401 pauschal eine neue MFA-Abfrage zu starten. Die fachliche Anwendung wertet den konkreten Autorisierungskontext aus und erhält keinen Zugriff allein durch ein sichtbares Login-Signal.

• gemSpec_ZETA 1.3.2 · A_25667 / A_25668 / A_28963 / A_28525-01 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

A_26681-01 bindet die Verwendung des ZETA/ASL-Kanals an zeta_asl_use: required oder required_passthrough. Der innere Request enthält Access Token und DPoP Token für den Resource-Server-Endpunkt. Bei required_passthrough enthält zusätzlich der äußere Request ein passendes Token-Paar für den ASL-Endpunkt. Terminiert ASL am HTTP Proxy, prüft dieser das innere Token-Paar. Bei Passthrough prüft er das äußere Paar und leitet an den terminierenden Resource Server weiter. Die Wahl des Dienstes und seiner Produktspezifikation bestimmt diese Grenze; die allgemein optionale Guard-Konfiguration hebt eine dienstspezifische ASL-Pflicht nicht auf.

• gemSpec_ZETA 1.3.2 · A_26681-01 / A_26480 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

Vor einem neuen Token-Set fragt der Authorization Server die Policy Engine. Eine verweigerte Policy-Entscheidung wird mit HTTP 403 umgesetzt; Token-Claims müssen zur Entscheidung passen. Access und Refresh Token sind über DPoP an die registrierte Client-Instanz gebunden. Refresh Token werden nur einmal eingetauscht und rotiert; der Client bewahrt Sitzungstoken und DPoP-Schlüssel geschützt auf. Ein anwendungsspezifisches Authorization Backend kann über die definierte Plug-in-Schnittstelle einbezogen werden. Clientverwaltung, manuelle De-Registrierung und Einsicht in das Registrierungs-Zugriffsprotokoll bleiben eigene Funktionen. Diese ZETA-Funktionen ersetzen weder ePA-Befugnisse noch die Fachregeln einer DiPag- oder TI-Flow-Operation.

• gemSpec_ZETA 1.3.2 · A_28837 / A_25661 / A_25662 / A_25663 / A_25665 / A_25782 / A_25733 / A_25734 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

A_28827 und A_28803 betreffen ausdrücklich Stufe 1: Die anfragende IP-Adresse wird im Access Token hinterlegt und bei Client-Requests verglichen. Ein negatives Ergebnis sperrt Access und Refresh Token und bricht die fachliche Operation ab. Die Spezifikation ordnet diese vereinfachte Impossible-Travel-Prüfung der LEI-Rolle mit stationärem Endgerät zu. Die mobile HCSA-Illustration übernimmt daraus keine universelle IP-Bindung. Mobile Aussagen aus 2.0.0_CC behalten ihren Entwurfsstatus; die im G-App-PTV referenzierte Fassung 2.0.1_CC bleibt bis zum Vorliegen der exakten Quelle ungeprüft.

• gemSpec_ZETA 1.3.2 · A_28827 / A_28803 ↗
• ZETA Guard 1.3.0-0 / 1.0.2 · ausgewählte Prüfzuordnungen / selected assessment categories ↗

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.

• ePA FdV PTV 3.1.3-3, V1.0.0 · Tabellen / Tables 1–2, S. / pp. 7–8 ↗
• ePA Aktensystem PTV 3.1.3-3, V1.0.0 ↗
• ePA Aktensystem ATV 3.1.3-3, V1.0.0 ↗

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.

• gemSpec_ePA_FdV 2.8.0 · §§ 6.1.2, 6.2.3.1 · A_24557 / A_24830 / A_24831 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · § 3.7 ↗
• I_Authorization_Service 1.9.1 · sendAuthorizationRequestFdV / sendAuthCodeFdV · commit 3186ad27 ↗

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.

• gemSpec_ePA_FdV 2.8.0 · A_15295-02 / A_15296-02 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · A_25006 ↗
• I_Authorization_Service 1.9.1 · GET /epa/authz/v1/logoutFdV · operationId logoutFdV ↗
• I_Device_Management_Insurant 1.10.1 · operationId deleteDevice · aktive Sitzung / active session ↗

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.

• I_Authorization_Service 1.9.1 · sendAuthCodeFdV · Geräteprüfung / device verification ↗
• I_Device_Management_Insurant 1.10.1 · registerDevice / confirmPendingDevice / getDeviceAttestation ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · A_25291 / A_26157 ↗

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.

• gemSpec_ePA_FdV 2.8.0 · §§ 6.2.5–6.2.7 · A_24399-01 / A_26280 ↗
• I_Entitlement_Management 1.8.0 · setEntitlement / deleteEntitlement ↗
• I_Consent_Decision_Management 1.7.1 · updateConsentDecision ↗
• I_Constraint_Management_Insurant 1.6.1 · setDenyPolicyAssignment · commit c88635c4 ↗
• gemSpec_Aktensystem_ePAfueralle 1.8.2 · §§ 3.8–3.11 · A_24548 ↗