latest




Elektronische Gesundheitskarte und Telematikinfrastruktur




Spezifikation
Aktensystem ePA für alle 




    
Version 1.3.0
Revision 985851
Stand 14.08.2024
Status freigegeben
Klassifizierung öffentlich
Referenzierung gemSpec_Aktensystem_ePAfueralle


Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung
1.0.0 30.01.2024 ePA für alle gematik
1.1.0 28.03.2024 ePA für alle - Release 3.0.1 gematik
1.2.0 12.07.2024 ePA für alle - Release 3.0.2, Zuordnungen für Release E-Rezept 1.6.5  gematik
1.3.0 14.08.2024 ePA für alle - Release 3.1.0 gematik

Inhaltsverzeichnis

1 Einführung

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zur Herstellung, Test und Betrieb des Produkttyps ePA-Aktensystem.

1.2 Zielgruppe

Das Dokument richtet sich an Anbieter und Hersteller des Produkttyps ePA-Aktensystem sowie an Anbieter und Hersteller von Produkten, die die Schnittstellen des Produkttyps ePA-Aktensystem nutzen. 

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps ePA-Aktensystem verzeichnet.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet. Sie werden im Dokument wie folgt dargestellt:


<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

2 Übergreifende Festlegungen

Das Grobkonzept der "ePA für alle", siehe [gemKPT_ePAfuerAlle], beschreibt wesentliche Kernmechanismen, Basisfunktionalitäten sowie technische Konzepte zu den Diensten des ePA-Aktensystems und den beteiligten Client-Systemen der Fachanwendung ePA.

A_24986 - ePA-Aktensystem - Rollentrennung ePA-Aktensystem und IDP-Dienst

Falls der Betreiber des ePA-Aktensystems auch den IDP-Dienst betreibt, MUSS der Betreiber sicherstellen, dass die Erstellung oder Änderungen von IDToken beim IDP-Dienst und die Verarbeitung und Prüfung der Client-Attestation im ePA-Aktensystem durch geeignete technische und organisatorische Maßnahmen so wirkungsvoll voneinander getrennt werden, dass ein einzelner Mitarbeiter des Betreibers nicht beide Aktivitäten durchführen kann. [<=]

A_25149-01 - ePA-Aktensystem - Rollentrennung ePA-Aktensystem und sektoraler IDP

Falls der Betreiber des ePA-Aktensystems auch einen sektoralen IDP betreibt, MUSS der Betreiber sicherstellen, dass die Erstellung oder Änderungen von ID-Token beim sektoralen IDP und die Erstellung oder Änderungen der Mailadresse für die Geräteverwaltung im ePA-Aktensystem durch geeignete technische und organisatorische Maßnahmen so wirkungsvoll voneinander getrennt werden, dass ein einzelner Mitarbeiter des Betreibers nicht die Aktivitäten in beiden Diensten durchführen kann. [<=]

A_24673 - Zeitsynchronisation über Zeitdienst in der TI

Das ePA-Aktensystem MUSS die Systemzeit über den Zeitdienst in der TI gemäß [gemSpec_Net#6.2] synchronisieren
[<=]

A_25612 - ePA-Aktensystem - Authentisierung gegenüber einem Client innerhalb der TI

Das ePA Aktensystem MUSS sich beim Aufruf durch einen Client innerhalb der TI mit der TLS-Identität oid_epa_dvw und Zertifikatsprofil C.FD.TLS-S authentisieren. [<=]

A_24676 - Useragent Information in HTTP Header außerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass  in der Kommunikation mit den ePA-Clients außerhalb des VAU-Kanals ein HTTP Header Element mit dem Namen "x-useragent" gesendet wird und andernfalls den Request mit HTTP-Fehler 400 ablehnen. [<=]

A_24677 - Useragent Information in HTTP Header innerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass in der Kommunikation mit den ePA-Clients innerhalb des VAU-Kanals ein HTTP Header Element mit dem Namen "x-useragent" gesendet wird und andernfalls den Request mit HTTP-Fehler 400 ablehnen. [<=]

Die Formatvorgaben zu User Agent sind in A_22470* definiert.

2.1 Aktensystem- und Service-Lokalisierung

Die Lokalisierung der Services der ePA für alle für ePA-Clients, die über das zentrale Netz der TI auf die Anwendung zugreifen, erfolgt mittels der übergreifenden Domäne epa4all.de. Da nicht gesteuert werden kann, welchen DNS ein ePA-Client verwendet, kann diese Domäne sowohl im Internet als auch im DNS der TI aufgelöst werden und verweist immer auf IP-Adressen der TI. Für die verschiedenen Umgebungen der TI werden third-level Domänen eingerichtet: .ref (RU1), .dev (RU2), .test (TU) und .prod (PU).

Ein ePA-Client aus der TI kennt die FQDNs der ePA-Aktensysteme (diese werden hier fest definiert, vgl. A_24592-*). Das Vorgehen der festvorgegebenen FQDNs ist analog zum E-Rezept-Vorgehen.

Ein ePA-FdV kennt den FQDN seines ePA-Aktensystems und erhält die Information über die dort verwendeten Service-Endpunkte über den Abruf einer Konfigurationsdatei unter /.well-known. In dieser Datei sind die verschiedenen Pfade zu den Endpunkten hinterlegt.

Jedes ePA-FdV ruft an seinem ePA-Aktensystem auch eine Liste aus allen Namen der verschiedenen Kostenträger und den zuständigen FQDN ab, damit diese im Falle einer Vertretung genutzt werden können, um das entsprechende Aktensystem zu finden.

A_24592-02 - Anbieter ePA-Aktensystem -Registrierung an übergreifender ePA-Domäne

Der Anbieter des ePA-Aktensystems MUSS seine Hosts und IP-Adressen für Services, die über das zentrale Netz der TI angeboten werden, in der übergreifenden ePA-Domäne epa4all.de für die Sub-Domänen ref (RU1), dev (RU2), test (TU) und prod (PU) unter folgend aufgeführten DNS-Namen (FQDN) registrieren. Diese sind

  1. Host und IP-Adressen für den Endpunkt I_Information_Service und der Services in der VAU:
    epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de.
  2. Host und IP-Adressen für den Endpunkt I_Information_Service_Accounts:
    epa-asisa-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de.
Die "ePA-Anbieter-Zahl" wird durch die gematik festgelegt.
[<=]

Folgende Zuordnungen der "ePA-Anbieter-Zahl" wurden vorgenommen:

ePA-Anbieter-Zahl Anbieter / Betreiber
1 IBM
2 Bitmarck Technik

Sobald ein neuer Anbieter/Betreiber hinzukommt, wird diesem die kleinste, nicht belegte Ziffer (>0) durch die gematik zugewiesen.

Beispiele der Dienstlokalisierung

PU :
Aktensystem A

epa-as-1.prod.epa4all.de A 100.102.x1.x2
ggf. ... weitere IP-Adressen für epa-as-1.prod.epa4all.de (DNS-Round-Robin) ...
epa-asisa-1.prod.epa4all.de A 100.102.x3.x4

 
Aktensystem B

epa-as-2.prod.epa4all.de A 100.102.x5.x6
epa-asisa-2.prod.epa4all.de A 100.102.x7.x8

TU :
Aktensystem 1
epa-as-1.test.epa4all.de A 172.30.x9.x10

...

D. h. ein ePA-Client aus der TI (Primärsystem) kennt die für ihn zwei relevanten FQDNs (PU: epa-as-1.prod.epa4all.de und epa-as-2.prod.epa4all.de) und verwendet diese um die beiden Aktensystem zu kontaktieren. Eine dynamisch konfigurierbare Anzahl der Anbieter in einem Primärsystem wird aktuell nicht in der Spezifikation gefordert.

A_14128-04 - Anbieter ePA-Aktensystem - Resource Records FQDN ePA

Der Anbieter des ePA-Aktensystems MUSS in seinen Nameservern im Internet den FQDN des Aktensystems für das ePA-FdV auflösen.
[<=]

A_22688-03 - Anbieter ePA-Aktensystem, Konfiguration Schnittstellen über /.well-known/

Der Anbieter des ePA-Aktensystems MUSS an seinen Access Gateway des Versicherten über den URL-Pfadnamen (bzw. die Datei) /.well-known/epa-configuration.json eine JSON-Repräsentation aller Pfade zu seinen Komponenten verfügbar machen.
D. h. der Aufrufende (ePA-FdV) MUSS wenn er diesen Pfad per HTTP-GET abfragt ein JSON-Objekt (also Content-Type "application/json") vom Access Gateway des Versicherten erhalten der Art

{
    "version" : "<Produkttypversion des Aktensystems im Format[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}>",
    "sgd1"  : "<pfad_Schlüsselgenerierungsdienst_typ1>",
    "sgd2"  : "<pfad_Schlüsselgenerierungsdienst_typ2>",
    ....
}
[<=]

A_22687 - Aktensystem, Konfiguration Schnittstellen über /.well-known/

Das ePA-Aktensystem MUSS sicherstellen, dass dem Anbieter des ePA-Aktensystems die technische Möglichkeit bereitgestellt wird A_22688-* umzusetzen. [<=]

A_17969-06 - Anbieter ePA-Aktensystem - Schnittstellenadressierung

Der Anbieter des ePA-Aktensystems MUSS alle nach außen angebotenen Dienste gemäß der ePA-OpenAPI-Spezifikationen ([I_Information_Service] etc.) an seinen ePA-spezifischen HTTPS-Schnittstellen anbieten (insbesondere mit den in den ePA-OpenAPI-Spezifikationen aufgeführten Pfadnamen). Falls die Operationen innerhalb einer ePA-VAU liegt, so gilt der Pfadname der ePA-OpenAPI-Spezifikation für den inneren HTTP-Request (übertragen innerhalb eines VAU-Kanals).

Ein ePA-Client verwendet, falls die Operation innerhalb einer VAU liegt gemäß [gemSpec_Krypt#A_24428-*] den Pfadnamen /VAU für die Initiierung eines VAU-Kanals. Beim Aufbau des VAU-Kanals gibt das Aktensystem den für den VAU-Kanal weiter zu verwendenden Pfadnamen vor [gemSpec_Krypt#A_24608]. Innerhalb des VAU-Kanals, d. h. für innere HTTP-Request, MÜSSEN die Pfadnamen der ePA-OpenAPI-Spezifikationen umgesetzt werden. Für Schnittstellen, die außerhalb einer VAU liegen, gelten ebenfalls die jeweilige ePA-OpenAPI-Spezifikation mit den dort aufgeführten Pfadnamen. [<=]

A_24801 - Aktensystem, Liste von FQDN im Internet

Das ePA-Aktensystem MUSS dem ePA-FdV eine Liste aller Kostenträger und der FQDN, unter der deren ePA-Aktensystem im Internet erreichbar ist, bereitstellen. Die Liste setzt sich zusammen aus den selbst verwalteten Kostenträgern und den über I_Information_Service_Accounts bezogenen Teillisten der anderen ePA-Aktensysteme. [<=]

2.2 Redundanz

Die Anforderungen zur Verfügbarkeit ergeben sich aus [gemSpec_Perf]. Die Verfügbarkeit wird hergestellt durch Anzahl, Verteilung und Konfiguration der Komponenten des ePA-Aktensystems. In diesem Dokument werden zusätzliche Redundanzanforderungen spezifiziert, wenn die Anforderungen in [gemSpec_Perf] zur Verfügbarkeit nicht ausreichen.

Die Auswahl und der Zugriff auf Services des ePA-Aktensystems wird durch die Primärsysteme anhand definierter FQDNs vorgenommen [siehe Kapitel 2.1]. Auf die Auswahl der Services des ePA-Aktensystems kann der Anbieter des ePA-Aktensystems durch die Konfiguration und Anpassung der DNS-Einträge Einfluss nehmen. Die Verfügbarkeit ist hergestellt, wenn jedes Primärsystem oder andere Fachdienste (z.B. E-Rezept-Fachdienst, ein anderes ePA-Aktensystem, ...) die Möglichkeit haben, die Services des ePA-Aktensystems zu erreichen. Von der Versichertenseite aus erfolgt der Zugriff auf die Komponenten des ePA-Aktensystems durch das ePA-Frontend des Versicherten.

Eine hardwaretechnische Hochverfügbarkeit der einzelnen Komponenten des ePA-Aktensystems ist über grundlegende Maßnahmen wie redundante Netzteile hinaus nicht erforderlich. Es steht dem Anbieter jedoch frei, zur Sicherstellung der Verfügbarkeitsanforderungen technische Lösungen, wie z. B. Load-Balancer und Stateful Failover innerhalb von Clustern einzusetzen, so dass jede einzelne Komponente des ePA-Aktensystems im Ergebnis eine höhere Verfügbarkeit oder Leistungsfähigkeit besitzt.

A_14921 - Anbieter ePA-Aktensystem - lokale Redundanz im Standort des ePA-Aktensystems

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass bei Ausfall einer oder mehrerer Komponenten des ePA-Aktensystems die verbleibenden Komponenten des ePA-Aktensystems in demselben Standort den Datenverkehr aller Clients der ausgefallenen Komponente zusätzlich übernehmen, die Konsistenz der persistenten Daten erhalten bleibt und die Verfügbarkeit der Komponenten gemäß den geforderten SLAs in [gemSpec_Perf] weiterhin gegeben ist. [<=]

A_15245 - Anbieter ePA-Aktensystem - standortübergreifende Redundanz und Verfügbarkeit

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass bei Ausfall eines Standorts (Rechenzentrum) die Konsistenz der persistenten Daten erhalten bleibt und die Verfügbarkeit der Komponenten gemäß der geforderten SLAs in [gemSpec_Perf] gegeben ist. [<=]

A_24862-03 - Anbieter ePA-Aktensystem – Georedundanz: Verfügbarkeit der Akten innerhalb von fünf Arbeitstagen

Der Betreiber des ePA-Aktensystems MUSS Maßnahmen zur Verfügbarkeit der Akten ergreifen, die sicherstellen, dass bei einem Großereignis, bei dem alle Aktensysteminstanzen ausfallen, die betroffenen Akten innerhalb von fünf Arbeitstagen wieder vollumfänglich für die Versorgung genutzt werden können. Die Maßnahmen zur Erhaltung der Verfügbarkeit des Aktensystems müssen die Sicherheitsanforderungen für das ePA-Aktensystem erfüllen. [<=]

2.3 Datenschutz und Sicherheit

A_15128 - Anbieter ePA-Aktensystem - Schutz der transportierten Daten im ePA-Aktensystem

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die Vertraulichkeit und Integrität der innerhalb des ePA-Aktensystems transportierten Daten gewährleistet ist. [<=]

Die folgenden Anforderungen verhindern Profilbildungen über Versicherte und Leistungserbringer(-institutionen) durch den Anbieter bzw. dessen Mitarbeiter.

A_15103 - Anbieter ePA-Aktensystem - Konzept zur Verhinderung von Profilbildung

Der Anbieter des ePA-Aktensystems MUSS ein Konzept erstellen und umsetzen, dass sicherstellt, dass Mitarbeiter des Anbieters die im ePA-Aktensystem verarbeiteten Daten nicht für Profilbildungen über Versicherte oder Leistungserbringer(-institutionen) nutzen können. [<=]

Hinweis: Das Konzept kann Teil des Sicherheits- oder Datenschutzkonzeptes des Anbieters sein. Es ist nicht notwendigerweise ein eigenes Dokument erforderlich.

A_25722 - ePA-Aktensystem - Löschen von personenbezogenen Daten von Vertretern nach Wegfall der Notwendigkeit

Das ePA-Aktensystem MUSS die personenbezogenen Daten eines Vertreters löschen, sofern der Vertreter kein Aktenkonto im ePA-Aktensystem besitzt und der Vertreter keine Versicherten im ePA-Aktensystem mehr vertritt. [<=]

A_15104 - Anbieter ePA-Aktensystem - Ordnungsgemäße IT-Administration

Der Anbieter des ePA-Aktensystems MUSS die Maßnahmen für erhöhten Schutzbedarf des BSI-Bausteins „OPS.1.1.2 Ordnungsgemäße IT-Administration“ [BSI-Grundschutz] während des gesamten Betriebs des ePA-Aktensystems umsetzen.    [<=]

Hinweis: Die Anforderungen des BSI-Bausteins sind entsprechend des dort genannten Schlüsselwortes („MUSS, DARF NICHT/ DARF KEIN, SOLLTE; SOLLTE NICHT/SOLLTE KEIN, KANN/DARF“) umzusetzen.

A_15824 - Anbieter ePA-Aktensystem - Sichere Speicherung von Daten

Unabhängig davon, ob die Daten schon verschlüsselt vorliegen, MUSS der Anbieter des ePA-Aktensystems  die Daten des ePA-Aktensystems bei der Speicherung verschlüsseln.   [<=]

Hinweis: Dies kann z. B. durch eine transparente Datenbankverschlüsselung oder eine Festplattenverschlüsselung erfolgen.

A_24774 - Anbieter ePA-Aktensystem - Zwei-Faktor-Authentisierung von Administratoren

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass sich Administratoren mindestens mit einer Zwei-Faktor-Authentisierung anmelden. [<=]

A_15107-02 - Anbieter ePA-Aktensystem - Keine unzulässige Weitergabe von Daten

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die in seinem Aktensystem verarbeiteten Daten nicht weitergegeben werden, auch nicht in pseudonymisierter oder anonymisierter Form. Davon ausgenommen sind Weitergaben an berechtigte Nutzer der Aktenkonten, an einen durch den Versicherten gewählten Anbieter beim Anbieterwechsel sowie Übermittlungen an das Forschungsdatenzentrum Gesundheit soweit dagegen kein Widerspruch durch den Versicherten oder einen Vertreter vorliegt. [<=]

A_15119 - Anbieter ePA-Aktensystem - Löschkonzept

Der Anbieter des ePA-Aktensystems MUSS in einem Löschkonzept für die im ePA-Aktensystem verarbeiteten personenbezogenen Daten mindestens folgende Aspekte beschreiben:

  • die umgesetzten organisatorischen und technischen Löschmaßnahmen (dies beinhaltet insbesondere auch die Löschung von Backups, Protokollen etc.),
  • die Löschregeln und Löschfristen zusammen mit einer nachvollziehbaren Begründung für die getroffenen Fristfestlegungen,
  • wie sichergestellt wird, dass alle Auftragnehmer die Löschpflichten ihrerseits umsetzen.
[<=]

Hinweis: Das Löschkonzept kann Teil des Sicherheits- oder Datenschutzkonzeptes des Anbieters sein. Es ist nicht notwendigerweise ein eigenes Dokument erforderlich.

A_15169 - ePA-Aktensystem - Verbot von Werbe- und Usability-Tracking

Die Komponenten des ePA-Aktensystems DÜRFEN im Produktivbetrieb ein Werbe- und Usability-Tracking NICHT verwenden.
Davon ausgenommen ist das Erfassen des standardmäßigen quantitativen Nutzerverhaltens zur Ermittlung der Standard-Aktennutzung entsprechend der Anforderung A_15154. [<=]

A_15154 - Anbieter ePA-Aktensystem - Ermittlung von Standard-Aktennutzung

Der Anbieter des ePA-Aktensystems MUSS mindestens einmal im Jahr Werte zu einer Standard-Aktennutzung von LE und Versicherten durch die Profilierung anonymer Zugriffsstatistiken auf das ePA-Aktensystem zum Zweck der Erkennung von Zugriffen gemäß A_15155 ermitteln. [<=]

A_15155 - Anbieter ePA-Aktensystem - Abweichung von Standard-Aktennutzung

Der Anbieter des ePA-Aktensystems MUSS Zugriffe und Zugriffsmuster, die nicht einer Standard-Aktennutzung entsprechen, erkennen und Maßnahmen zur Schadensreduzierung umsetzen.  [<=]

Hinweis: Diese Erkennung darf keine zusätzliche Persistierung von personenbezogenen Daten auslösen. Ausnahme sind hier nur die notwendigen Daten, falls ein Missbrauch erkannt wird.

A_24778 - Anbieter ePA-Aktensystem - Einsatz zertifizierter HSM

Der Anbieter des ePA-Aktensystems MUSS beim Einsatz eines HSM sicherstellen, dass dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage.    
Die Prüftiefe MUSS mindestens 

  1. FIPS 140-2 Level 3 oder
  2. FIPS 140-3 Level 3 oder  
  3. Common Criteria EAL 4+ (mit AVA_VAN.5)
entsprechen. [<=]

A_15157 - Anbieter ePA-Aktensystem - Sicherer Betrieb und Nutzung eines HSMs

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass die auf dem HSM verarbeiteten privaten Schlüssel, Konfigurationen und eingesetzte Software nicht unautorisiert ausgelesen, unautorisiert verändert, unautorisiert ersetzt oder in anderer Weise unautorisiert benutzt werden können. [<=]

A_15159 - Anbieter ePA-Aktensystem - Schutzmaßnahmen gegen die OWASP Top 10 Risiken

Der Anbieter des ePA-Aktensystems MUSS in allen Komponenten des ePA-Aktensystems technische Maßnahmen zum Schutz vor den in der aktuellen Version genannten OWASP-Top-10-Risiken umsetzen. [<=]

A_24780 - Anbieter ePA-Aktensystem – Versicherte über sensible Änderungen informieren

Der Anbieter des ePA-Aktensystems MUSS sicherstellen, dass der Versicherte über Änderungen in den folgenden Anwendungsfällen informiert wird,  

  • E-Mail-Adresse ändern,
  • Aktenkonto schließen
und wenn der Anbieter des Aktensystems eine manuelle Änderung bezüglich einer Akte (Aktenverwaltung) im Auftrag eines Versicherten durchführt. [<=]

Hinweis: Dies kann z. B. durch eine Notifikations-E-Mail an den Versicherten erfolgen. Solche E-Mails dürfen keine Details über die Änderungen beschreiben, sondern nur einen Hinweis geben, dass eine Änderung gemacht wurde und dass der Versicherte die Änderungen in seinem Aktenkonto prüfen sollte.

A_15163 - Anbieter ePA-Aktensystem - Angriffen entgegenwirken

Der Anbieter des ePA-Aktensystems MUSS Maßnahmen zur Erkennung von Angriffen und zur Reduzierung bzw. Verhinderung von Schäden aufgrund von Angriffen in allen Komponenten des ePA-Aktensystems umsetzen. [<=]

A_15167 - Anbieter ePA-Aktensystem - Social Engineering Angriffen entgegenwirken

Der Anbieter des ePA-Aktensystems MUSS Maßnahmen zur Erkennung und Verhinderung von Social Engineering Angriffen umsetzen. [<=]

A_24989 - Anbieter ePA-Aktensystem - Schutz vor Angriffen über die TI

Die Anbieter des ePA-Aktensystems MUSS für alle über die TI erreichbaren Schnittstellen des ePA-Aktensystems Maßnahmen zum Schutz vor DoS-Angriffen auf Anwendungsebene treffen. Weitere Angriffe auf Anwendungsebene MÜSSEN mindestens durch Einsatz geeigneter IDS/IPS Lösungen verhindert werden. [<=]

A_15168 - ePA-Aktensystem - Verbot vom dynamischen Inhalt

Die Komponenten des ePA-Aktensystems DÜRFEN dynamischen Inhalt von Drittanbietern NICHT herunterladen und verwenden. 
[<=]

A_17080 - Verhindern von Session Hijacking

Die Komponenten des ePA-Aktensystems MÜSSEN geeignete Schutzmaßnahmen gegen Session-Hijacking implementieren.
[<=]

A_16323-01 - ePA-Aktensystem - Verbot von medizinisch irrelevantem Inhalt

Der Anbieter des ePA-Aktensystems MUSS der Ablage von Dokumenten, die für die medizinische Versorgung oder für die Eigenorganisation medizinischer Belange des Versicherten oder zur Erstattung der Behandlungskosten irrelevant sind, mittels AGB auf Anbieterseite entgegenwirken.
[<=]

A_24781 - Sicherer Betrieb des Produkts nach Handbuch

Der Anbieter eines ePA-Aktensystems MUSS die im Handbuch des eingesetzten ePA-Aktensystems beschriebenen Voraussetzungen für den sicheren Betrieb des Produktes gewährleisten. [<=]

A_18953 - Darstellen der Voraussetzungen für sicheren Betrieb des Produkts im Handbuch

Der Hersteller des ePA-Aktensystems MUSS für sein Produkt im dazugehörigen Handbuch leicht ersichtlich darstellen, welche Voraussetzungen vom Betreiber und der Betriebsumgebung erfüllt werden müssen, damit ein sicherer Betrieb des Produktes gewährleistet werden kann. [<=]

A_19122-01 - Anbieter ePA-Aktensystem – Trennung zu anderen Mandanten

Ein Betreiber eines ePA-Aktensystems MUSS sicherstellen, dass die Daten von unterschiedlichen Mandanten organisatorisch und technisch getrennt sind.  [<=]

A_21106 - Anbieter ePA-Aktensystem – Signaturschlüssel für Protokolle

Das ePA-Aktensystem MUSS für die Signatur von Listen von Protokollen des Versicherten Schlüsselmaterial der Ausstelleridentität ID.FD.SIG mit einem zugehörigen Zertifikat C.FD.SIG mit der Rolle oid_epa_logging gemäß [gemSpec_OID] besitzen. [<=]

A_21107 - Anbieter ePA-Aktensystem – Speicherung Signaturschlüssel für Protokolle im HSM

Das ePA-Aktensystem MUSS das private Schlüsselmaterial der Ausstelleridentität ID.FD.SIG für die Signatur von Listen von Protokollen des Versicherten in einem HSM speichern.
[<=]

A_22409 - Anbieter ePA-Aktensystem - CA-Anbieterwechsel

Der Anbieter des ePA-Aktensystems MUSS mindestens drei Monate vor dem Wechsel des CA-Anbieters für die Ausstellung der TLS_Zertifikate des Access Gateways die gematik darüber informieren, wer der alte Anbieter war und wer der neue Anbieter wird. [<=]

A_19118-01 - Komponenten des Aktensystems, Schutz vor XSW-Angriffen

Die Komponenten des ePA-Aktensystems, die XML-Signaturen prüfen, MÜSSEN geeignete Maßnahmen gegen XSW-Angriffe umsetzen. Mindestens MÜSSEN sie die FastXPath-Auswertung der XML-Daten und XML-Signaturen gemäß [GJLS-2009] (vgl. auch [BSI-XSpRES]) umsetzen. [<=]

A_24783 - ePA-Aktensystem - Eingabevalidierung von Operationen

Das ePA-Aktensystem MUSS alle Operationsaufrufe seiner Schnittstellen (Requests) sowie die Antwortmeldung auf seine Anfragen (Responses) auf Wohlgeformtheit und Zulässigkeit prüfen und bei Encoding-, Schema-, Semantik- oder Protokollverletzungen die Operation abbrechen. [<=]

Hinweis: Eine Orientierung für die Validierung ist in [OWASP ASVS] Kapitel 5, Validation, Sanitization and Encoding beschrieben.

A_24992 - ePA-Aktensystem - Zugriffe durch Versicherte übers Access Gateway

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session für einen Versicherten (NutzerID ist KVNR) ausschließlich über das Access Gateway erreichbar ist. [<=]

A_24993 - ePA-Aktensystem - Zugriffe übers Access Gateway ausschließlich für Versicherte

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session für einen Nutzer, dessen NutzerID keine KVNR ist (z.B. Leistungserbringerinstitutionen) nicht über das Access Gateway erreichbar ist. [<=]

A_25006 - ePA-Aktensystem - User Session bei Inaktivität Beenden

Das ePA-Aktensystem MUSS sicherstellen, dass eine User Session nach 20 Minuten Inaktivität beendet wird. [<=]

A_25022 - ePA-Aktensystem - Debug-Protokoll für Testbetrieb

Das ePA-Aktensystem KANN im Testbetrieb ein Debug-Protokoll schreiben, welches eine erweiterte Protokollierung für Testzwecke ermöglicht. [<=]

Hinweis: Die Anforderung beschränkt den Debug-Modus auf Testzwecke. Im Produktivbetrieb ist der Debug-Modus nicht zulässig.

A_25023 - ePA-Aktensystem - Keine Echtdaten im Testbetrieb

Das ePA-Aktensystem MUSS sicherstellen, dass im Testbetrieb keine Echtdaten verarbeitet werden. [<=]

A_25042 - ePA-Aktensystem - Prüfung von Signaturen

Das ePA-Aktensystem MUSS bei der Prüfung von Signaturen

  • das Signaturzertifikat gemäß A_25040-* prüfen,
  • die Signatur prüfen (i. S. v. Verify()-Funktion des kryptographischen Signaturverfahrens ergibt "valid")
[<=]

A_25040-01 - ePA-Aktensystem - Prüfung Signaturzertifikate

Das ePA-Aktensystem MUSS Signaturzertifikate gemäß [gemSpec_PKI#TUC_PKI_018] mit folgenden Parametern auf Gültigkeit prüfen:

Tabelle 1: Tab_Prüfung_Signaturzertifikate Parameter Prüfung Signaturzertifikat 

Parameter C.FD.SIG
C.CH.SIG C.HCI.OSIG C.HCI.AUT
PolicyList oid_fd_sig oid_egk_sig
oid_smc_b_osig oid_smc_b_aut
intendedKeyUsage digitalSignature  nonRepudiation nonRepudiation digitalSignature
intendedExtendedKeyUsage (leer) (leer) (leer) id-kp-clientAuth
OCSP-Graceperiod 24 Stunden 24 Stunden 24 Stunden 24 Stunden
Offline-Modus nein nein nein nein
Prüfmodus OCSP OCSP OCSP OCSP
Das ePA-Aktensystem MUSS sicherstellen, dass die Prüfung des Signaturzertifikats nur erfolgreich ist, falls das Signaturzertifikat anhand der Zertifikatsprüfung für [Zertifikatsignatur "valid" UND zeitlich gültig UND online gültig ] befunden wird.
[<=]

2.4 Validierungsaktenkonto

Die Architektur des ePA-Aktensystems verhindert eine Einsichtnahme des Betreibers in Daten von Versicherten. Ebenso ist ein Monitoring der Verfügbarkeit einzelner Schnittstellen und Operationen erschwert. Mit der Anlage eines Validierungsaktenkontos (auf Basis einer Validierungsidentität gem. gemSysL_PK_eGK) im ePA-Aktensystem kann die korrekte Funktionsweise in der Produktivumgebung validiert und überwacht werden. Ein Validierungsaktenkonto verhält sich dabei wie ein Konto eines echten Versicherten. Eine Validierungsidentität ist eine Identität mit Versichertenrolle, deren KVNR sich aufgrund ihrer festgelegten Bildungsvorschrift technisch von der eines echten Versicherten unterscheiden lässt. Die Bildungsvorschrift zur Erzeugung von KVNRn für Validierungskonten weicht dahingehend vom Standard ab, dass hier 4 (oder mehr) aufeinanderfolgende, gleiche Ziffern verwendet werden. Dadurch ist eine Überschneidung mit der Menge der "Echt"-KVNRn ausgeschlossen. Die Zuteilung von KVNR-Nummernkreisen, bzw. die Ausgabe einer KVNR in Form einer Prüfkarte, erfolgt durch die gematik.

Validierungsaktenkonten stehen der gematik, den Aktensystembetreibern selbst und Dritten (z. B. DVOs, Primärsystemhersteller  ...) zur Verfügung. Für Dritte übernimmt die gematik die Anforderung der Validierungsaktenkonten bei den Aktensystembetreibern und vertreibt diese zusammen mit den dazugehörigen Prüfkarten. Für Validierungsaktenkonten von Dritten kann der Aktensystembetreiber nur eingeschränkten Support in Form von "Akte anlegen", "Akte zurücksetzen" und "Akte löschen" leisten. Über die Einschränkung sind die Nutzer durch die gematik zu informieren.

Folgende Anwendungsfälle sollen mit den Validierungsaktenkonten adressiert werden:

  • Monitoring der Aktensystemfunktionalität
  • Troubleshooting bei Störungsmeldungen (über FdV oder Primärsystem)
  • Validierung der Konfiguration in der LEU
  • Store-Review seitens der App-Store-Betreiber (über FdV)
  • Validierung der EU-Anbindung

Die mittels der Validierungskonten in der Produktivumgebung realisierten Anwendungsfälle müssen sich möglichst auf die genannten, unbedingt jedoch auf spezifizierte Anwendungsfälle beschränken.

A_18168-01 - Anbieter des ePA-Aktensystem - Validierungsaktenkonto für gematik

Nach Aufforderung durch die gematik MUSS der Anbieter des ePA-Aktensystems

  • für die gematik ein Validierungsaktenkonto im ePA-Aktensystem für die von der gematik übergebene KVNR anlegen, wobei die KVNR die Festlegungen für die Versichertennummer [gem. gemSysL_PK_eGK] erfüllen muss.
  • das durch die gematik angegebene Validierungsaktenkonto löschen, sofern die gematik dessen Anlage beantragt hatte.
[<=]

A_18169-02 - Anbieter des ePA-Aktensystem - Validierungsaktenkonto für eigene Zwecke

Falls sich der Anbieter des ePA-Aktensystems ein Validierungsaktenkonto für eigene Zwecke anlegen möchte, MUSS er sicherstellen, dass nur eine Versichertennummer aus dem von der gematik für diesen Anbieter freigegebenen Nummernkreis [gem. gemSysL_PK_eGK] verwendet wird.
[<=]

A_22522-01 - Anbieter des ePA-Aktensystems - Validierungskonto für Dritte

Der Anbieter des ePA-Aktensystems MUSS auf Antrag der gematik

  • Validierungsaktenkonten für Dritte (z.B. DVO, PS-Hersteller) für eine vom Antragsteller übermittelte KVNR anlegen, sofern die KVNR die Festlegungen für die Versichertennummer [gem. gemSysL_PK_eGK] erfüllt ist.
  • das durch einen Antragsteller angegebene Validierungsaktenkonto löschen, sofern der Antragsteller dessen Anlage beantragt hatte.
[<=]

Hinweis zu A_22522-*: Die Einrichtung der Validierungsaktenkonten für Dritte kann gegen Bezahlung erfolgen. Die Entscheidung dafür obliegt dem Anbieter des ePA-Aktensystems.

Im Design der ePA für alle wird die Initialisierung und Aktivierung durch den Kostenträger vorgenommen. Da es diese Rolle bei Validierungsaktenkonten nicht gibt, sind für diese speziellen Aktenkonten die folgenden Besonderheiten zu berücksichtigen:

A_26187 - Anlage von Validierungsaktenkonten

Das Aktensystem MUSS die Anlage von Validierungsaktenkonten auch ohne KTR- und Ombudsstellen-Befugnisse zulassen. [<=]

A_26188 - Anbieter des ePA-Aktensystems -Aktivierung von Validierungsaktenkonten

Der Anbieter des ePA-Aktensystems MUSS den Status von Validierungsaktenkonten, welche für die gematik (gem. A_18168-*) oder für Dritte (gem. A_22522-*) angelegt wurden, nach der Anlage auf ACTIVATED setzen. [<=]

Falls ein Antragsteller keine Löschung eines Validierungsaktenkontos beim Anbieter des ePA-Aktensystems beantragt, wird das Validierungsaktenkonto nach einer Lebensdauer von maximal 5 Jahren automatisch durch den Anbieter des ePA-Aktensystems gelöscht (ggf. früher aber nicht vor Ablauf der Gültigkeit der Prüf-eGK). Dies verhindert das Auftreten ungenutzter Validierungsaktenkonten im Aktensystem. Die maximale Lebensdauer eines Validierungsaktenkontos ist dabei an die maximale Gültigkeit der Zertifikate der Validierungsidentität gekoppelt, die maximal fünf Jahre betragen kann.

A_22524-01 - Anbieter des ePA-Aktensystems - Löschen von Validierungsaktenkonten nach 5 Jahren

Der Anbieter des ePA-Aktensystems MUSS ein Validierungsaktenkonto spätestens fünf Jahre nach Anlage des Validierungsaktenkontos, frühestens jedoch nach Ablauf der Gültigkeit der dazugehörigen Prüf-eGK, löschen. [<=]

A_22684-01 - Validierungsaktenkonten im Store-Review der FdVs

Der Anbieter/Hersteller des ePA-Aktensystems bzw. Hersteller des ePA-FdVs KANN - ausschließlich für dedizierte KVNRn von Validierungsaktenkonten zum Zwecke der Verwendung im Store-Review der FdVs – Vorkehrungen treffen, die es ermöglichen auf Gerätebindung, E-Mail-Validierung oder andere Aktivitäten des Registrierungs-/Anmeldeprozesses zu verzichten, um eine Prüfung der FdVs durch die App-Store-Betreiber zu ermöglichen.  [<=]

A_22942 - Besonderheiten bei Validierungaktenkonten für StoreReviews

Bei Validierungsaktenkonten, für die die Regelung gem. A_22684-* gilt [Validierungsaktenkonten im StoreReview der FdVs], MÜSSEN folgende Besonderheiten berücksichtigt werden:

  • die entsprechenden Validierungsaktenkonten dürfen nur für den Zeitpunkt des Reviews aktiviert und erreichbar sein,
  • die entsprechenden Validierungsaktenkonten sind unmittelbar nach dem Review zu leeren,
  • es sind Zeitraum der Erreichbarkeit und eine eindeutige Referenz auf den Review (z.B. Vorgangsnummer) zu dokumentieren und auf Anforderung an die gematik zu übertragen
[<=]

A_24539 - Nutzung von Validierungsaktenkonten via FdV

Der Anbieter des ePA-Aktensystems bzw. Hersteller des ePA-FdVs MUSS ein FdV bereitstellen, mit dem der Zugriff auf Validierungsaktenkonten möglich ist. [<=]

Die Bereitstellung dieser FdVs muss nicht unentgeltlich erfolgen, wenngleich eine Integration dieser Eigenschaft (Kompatibilität mit Validierungsaktenkonten) in das Standard-FdV anzustreben ist.

A_26209 - Prüfung auf Vertretungsberechtigung für Prüfidentität

Das Aktensystem MUSS sicherstellen, dass bei der Vertreterbefugnis ausschließlich "echte" Vertreter für "echte" Konten befugt, bzw. auf Validierungsaktenkonten ausschließlich "Validierungs-Vertreter" eingerichtet werden können. [<=]

2.5 Tracing in Nichtproduktivumgebungen

Ein gewonnener Erfahrungswert ist, dass es für die Fehlersuche in Nichtproduktivumgebungen -- insbesondere bei IOP-Problemen zwischen Produkten verschiedener Hersteller in einer fortgeschrittenen Entwicklungsphase -- leistungsfähigere Mechanismen als zuvor geben muss. Gab es zunächst nur die Testschnittstelle ([gemKPT_Test#A_21193-*]) in den ePA-Clients, so wurde mit ePA 2.0 ein Tracing im Aktensystem für Nichtproduktivumgebungen eingeführt und wird mit ePA für alle wie folgt umgesetzt:

  1. Innerhalb des AS werden an die für die Fehlersuche in Nichtproduktivumgebungen wichtigen Stellen Sensoren platziert. Diese Sensoren streamen die aktuell transportierten Daten an bestimmte TCP-Ports am Access Gateway. Die Sensorpunkte liegen im AS immer hinter der TLS-Entschlüsselung. Fehlersuchende können sich zu diesen TCP-Ports  am Access Gateway verbinden und lesen dann im Read-Only-Modus den aktuellen Datenverkehr, der an den Sensorpunkten vorbeifließt, mit.
  2. ePA-Clients müssen in Nichtproduktivumgebungen beim VAU-Protokoll die symmetrischen Verbindungsschlüssel offenlegen [gemSpec_Krypt#A_24477-*].

Damit wird es möglich, für die Fehlersuche in Nichtproduktivumgebungen den Datenverkehr zwischen einem ePA-Client und der VAU-Instanz im Aktensystem mitzulesen. Für ePA für alle konzentriert sich das Tracing auf genau diese Verbindungsstrecke, andere Sensorpunkte vor Services außerhalb der VAU sind optional.

Ein Aktensystem besitzt mehrere HTTPS-Schnittstellen, über die ein ePA-Client auf das Aktensystem zugreift. Die TLS-Sicherung endet vor den VAU-Instanzen. In den VAU-Instanzen möchte man die Trusted Computing Base (TCB) minimieren und setzt dort das VAU-Protokoll als extrem reduziertes TLS-Analogon ein. Der geforderte Sensorpunkt muss hinter der TLS Terminierung und vor der VAU Instanz liegen.

A_21887-01 - Tracing, Sensorpunkt nahe vor den VAU-Instanzen (Nichtproduktivumgebungen)

Ein Aktensystem MUSS sicherstellen, dass genau in Nichtproduktivumgebungen der Datenverkehr zur und von den VAU-Instanzen auf TCP-Ebene mitgeschnitten wird (Sensorpunkt). Der aktuell mitgeschnittene Datenverkehr MUSS auf einen TCP-Port im Access Gateway gestreamt werden (siehe A_21890-*). D. h. wenn ein Client sich zu diesem TCP-Port verbindet, MUSS er die aktuell auf dem Interface durchlaufenden Daten gestreamt lesen können.
[<=]

A_21891-01 - Tracing, Tiger-Standalone-Proxy

Ein Aktensystem MUSS zum Mitschneiden und Streamen der Testdaten in Nichtproduktivumgebungen nach A_21887-* den von der gematik bereitgestellten aggregierenden Tiger-Standalone-Proxy (mindestens der Version 0.20) verwenden. [<=]

A_22581 - Tracing, Abschaltbarkeit

Ein Aktensystem MUSS den Tiger-Standalone-Proxy (und die damit verbunden Sensorpunkte) gemäß A_21891-* im Rahmen der Zulassungstests auf Wunsch der gematik aktivieren und insbesondere deaktivieren können. [<=]

Hinweis: Die Aktivier- bzw. Deaktivierbarkeit nach A_22581-* kann dabei auch teilweise mit organisatorische Maßnahmen umgesetzt werden, d. h. es ist hier kein vollautomatisierter Mechanismus notwendig, der im Millisekunden-Bereich umschalten kann.

2.6 Benutzerführung

Bietet der Anbieter des ePA-Aktensystems dem Versicherten die Aktenkontoeröffnung, die Änderung von Vertragsdaten und die Aktenkontoschließung auf einem elektronischen Weg an, dann muss die Bedienung für den Nutzer intuitiv gestaltet werden.

A_15842 - Anbieter ePA-Aktensystem - Ergonomie der Benutzerführung

Der Anbieter des ePA-Aktensystems MUSS eine ergonomisch gestaltete Benutzerführung nach den Vorgaben zur Ergonomie in [DIN EN ISO 9241-171] anbieten. [<=]

DIN-Normen und Verordnungen zur Beachtung:

Zusätzlich zu den in diesem Kapitel aufgeführten Anforderungen zur Benutzerführung sollen auch die in der ISO 9241 aufgeführten Qualitätsrichtlinien zur Sicherstellung der Ergonomie interaktiver Systeme und Anforderungen aus der Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung – BITV 2.0) beachtet werden.

Insbesondere soll der Fokus auf die nachfolgend aufgeführten Teile der ISO 9241 gerichtet sein:

DIN EN ISO 9241 – Teile mit Bezug zur Software-Ergonomie

  • Teil 8:       Anforderungen an Farbdarstellungen
  • Teil 9:       Anforderungen an Eingabegeräte – außer Tastaturen
  • Teil 110:   Grundsätze der Dialoggestaltung (ersetzt den bisherigen Teil 10)
  • Teil 11:     Anforderungen an die Gebrauchstauglichkeit – Leitsätze
  • Teil 12:     Informationsdarstellung
  • Teil 13:     Benutzerführung
  • Teil 14:     Dialogführung mittels Menüs
  • Teil 15:     Dialogführung mittels Kommandosprachen
  • Teil 16:     Dialogführung mittels direkter Manipulation
  • Teil 17:     Dialogführung mittels Bildschirmformularen
  • Teil 171:   Leitlinien für die Zugänglichkeit von Software BITV 2.0

BITV 2.0 - Barrierefreie Informationstechnik-Verordnung

Die Umsetzung der Verordnung dient zur behindertengerechten Umsetzung von  Webseiten und anderen grafischen Oberflächen.

Insbesondere sollen deshalb neben der Übernahme der international anerkannten Standards für barrierefreie Webinhalte, die Web Content Accessibility Guidelines (WCAG) 2.1, auch die Belange gehörloser, hör-, lern- und geistig behinderter Menschen berücksichtigt werden.

Die BITV 2.0 regelt unter anderem den sachlichen Geltungsbereich, die einzubeziehenden Gruppen behinderter Menschen und die anzuwendenden Standards.

Weitere Richtlinien und Empfehlungen zur digitalen Barrierefreiheit sind die EU-Richtlinie 2016/2102 für öffentliche Stellen und die europäische Norm EN 301 549 V2.1.2 mit dem Titel "Accessibility requirements for ICT products and services".

A_15846 - Anbieter ePA-Aktensystem - Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit

Der Anbieter des ePA-Aktensystems SOLL die Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit, welche vom Betriebssystem zur Verfügung gestellt werden, unterstützen. [<=]

2.7 Useragent

A_22470-05 - Definition Useragent

Das Produkt MUSS für das UserAgent-Element in Eingangs- oder Ausgangsparametern einer Operation folgende Formatvorgaben berücksichtigen:

  • der Useragent umfasst 2 Informationen, welche als 1 String - getrennt durch "/" (Slash) - im Header übertragen werden
    • erster Teil: ClientID = ein bis zu 20 Zeichen langer String (a-z A-Z 0-9, "-"), welcher im Rahmen der Produktregistrierung bei der gematik erzeugt wird,
    • zweiter Teil: Versionsnummer = bis zu 15 Zeichen langer String (a-z A-Z 0-9, "-", ".") welcher die aktuelle Produktversion des Clients repräsentiert.
Beispiel: "CLIENTID1234567890AB/2.1.12-45"
[<=]

Hinweis zum Erhalt der ClientID: die ClientID wird durch die gematik vergeben und übermittelt, sobald sich ein (Client-)Produkthersteller (z.B. FdV oder Primärsystem) unter idp-registrierung@gematik.de registriert hat. Dazu ist im Rahmen dieser Registrierung der Name des Herstellers und der Name des zu registrierenden Produktes zu übermitteln. Sollte im Rahmen einer anderen TI-Anwendung bereits eine Registrierung vorgenommen worden sein, kann die ClientID auch im ePA-Kontext genutzt werden (sofern es sich um das gleiche Softwareprodukt handelt).

Hinweis für FdV-Hersteller: Bei Entwicklung eines White-Label-Clients ist der Useragent Teil des kundenspezifischen Customizings, sodass über die ClientID im Useragent das spezifische Kostenträger-ePA-FdV erkennbar sein muss. 

2.8 Datenmigration

Jeder Versicherter (vorbehaltlich eines Widerspruchs durch den Versicherten) erhält in ePA 3.0 ein neues, leeres Aktenkonto. Bei der Migration werden Daten und Vertreterberechtigungen aus ePA 2.6 in dieses Aktenkonto übertragen.

Für die Migration eines existierenden Aktenkontos der Version ePA-2.x wird vorausgesetzt, dass ein migriertes Aktenkonto sowohl die Schnittstellen der ePA für alle, als auch die Schnittstellen der bisherigen ePA-Version 2.x bereitstellt und simultan verarbeiten kann.

Die Migration eines existierenden Aktenkontos der ePA-Version 2.x erfordert die Entschlüsselung der existierenden Inhalte durch die Anwendung des aktenkontospezifischen Akten- und Kontextschlüssels und deren Überführung in die Verwaltungs- und Diensteeinheiten der im vorliegenden Dokument beschriebenen ePA-Version 3.x.

Aus einem existierenden Aktenkonto werden die folgenden Artefakte übernommen:

  • Kategorien und Ordner, insoweit die Kategorien nicht abgekündigt sind. Ordner erhalten eine feste UUID.
  • Dokumente, sowie deren Metadaten
  • Protokolle

Die Vertraulichkeitsstufen für die Sichtbarkeit von Dokumenten werden nicht mehr unterstützt. Dokumente mit bisheriger Vertraulichkeitsstufe confidential werden bei der Migration der GeneralDenyPolicy  des Constraint Managements zugeordnet.

Alle weiteren Nutzergruppen (LEI, Apotheken, usw) erhalten eine Befugnis zur Nutzung dediziert in einer Behandlungssituation oder durch direkte Befugnisvergabe durch den Versicherten oder einen Vertreter mittels ePA-FdV.

Für Versicherte, die keine ePA-FdV nutzen möchten oder können, ist eine Migration der Daten einer existierenden Akte nicht möglich, da die dafür notwendige Übertragung des bisherigen individuellen Akten- und Kontextschlüssels nicht erfolgen kann. Versicherte ohne ePA-FdV erhalten (vorbehaltlich eines Widerspruchs durch den Versicherten) ein neues, leeres Aktenkonto ohne Inhalten, die womöglich in ePA 2.6 existierten. Eine Befugnisvergabe für Leistungserbringerorganisationen ist in diesem Fall ausschließlich durch die Befugnisvergabe im Behandlungskontext möglich. Dieses erfordert eine LEI mit einem Client gemäß ePA-Version 3.x.

Es resultiert ein Aktenkonto, welches direkt durch den Versicherten, befugte Vertreter, den Kostenträger, die Ombudsstelle und den E-Rezept-Fachdienst genutzt werden kann.

2.8.1 Herstellerspezifische Umsetzung der Datenmigration

Die technische Umsetzung der Datenmigration obliegt grundsätzlich dem Hersteller des ePA-Aktensystems. Es muss jedoch sichergestellt werden, dass der Schutz der zu migrierenden Daten durchgehend gewährleistet wird.

A_24995 - Migration: Sicherheitskonzept für Datenmigration

Der Hersteller des ePA-Aktensystems MUSS ein Sicherheitskonzept zur Datenmigration erstellen, in welchem er beschreibt, mit welchen Maßnahmen die zu migrierenden Daten im gesamten Datenmigrationsprozess geschützt werden. [<=]

A_25000 - Migration: Stärke der Sicherheitsmaßnahmen für Datenmigration

Das ePA-Aktensystem MUSS sicherstellen, dass die zu migrierenden Daten im gesamten Datenmigrationsprozess mit technischen Maßnahmen geschützt werden, die auch gegen einzelne Innentäter beim Betreiber des ePA-Aktensystems wirken. [<=]

A_25049 - Migration: Migrationskonzept

Der Anbieter des ePA-Aktensystems MUSS ein Migrationskonzept erstellen, welches sowohl die Aktensystemmigration, als auch die Datenmigration, mitsamt der Bereitstellungs- und ggf. Außerbetriebnahme-Zeitpunkte der benötigten Komponenten berücksichtigt. Das Migrationskonzept MUSS dabei auch aufzeigen, welche Abhängigkeiten zu anderen TI-Diensten bestehen, wann und in welchem Umfang die Migration getestet wird und wie eventuelle Roll-Back-Szenarios aussehen.
[<=]

2.8.2 Durchführung der Migration

Das Aktenkonto muss durch den Anbieter für die Migration der Daten vorbereitet werden. Dabei müssen alle Maßnahmen umgesetzt werden, die im Zustand INITIALIZED eines neuen Aktenkontos vor der Aktivierung erforderlich sind (siehe 3.1.3 Anlage eines neuen Aktenkontos ). Abweichend von den Maßnahmen für die Erstellung eines neuen Aktenkontos kann auf den Status INITIALIZED verzichtet werden und das Aktenkonto im Status ACTIVATED verbleiben.

Für ein zu migrierendes Aktenkonto sind alle Schritte anzuwenden, die auch für die Erstellung eines neuen Aktenkontos vor der Aktivierung erforderlich sind, insbesondere die Anlage der initialen Befugnisse für den Versicherten, den Kostenträger und die Ombudsstelle, sowie den E-Rezept-Fachdienst. 

Im Anschluss an die Initialisierung erfolgt einmalig die Bereitstellung der Akten- und Kontextschlüssel durch ein ePA-FdV. Existierende Daten werden übertragen.

A_25148 - Migration: Information des Versicherten

Der Anbieter des ePA-Aktensystems MUSS den Versicherten über die Notwendigkeit und die Folgen einer Migration vor der eigentlichen Migration informieren, insbesondere darüber, welche Dokumentenformate und welche Berechtigungen übernommen und welche nicht übernommen werden, über die Freiwilligkeit einer Migration. [<=]

Die Entschlüsselung des Datenbestands für die Überführung in das vorbereitete Aktenkonto und die Migration der Berechtigungen der Vertreter wird durch die Nutzung eines ePA-FdV gemäß ePA-Version 3.x abgeschlossen. Bei der ersten Nutzung eines ePA-FdV durch den Versicherten mit dem zur Migration vorbereiteten Aktenkonto erfolgt die Migration über die vom ePA Aktensystem bereitgestellten Schnittstellen.

A_24922 - Migration: Schnittstellen zur Durchführung der Migration

Das ePA-Aktensystem MUSS für jedes Aktenkonto eine Migration von ePA 2.6 auf ePA 3.0 durchführen und geeignete Schnittstellen zum FdV anbieten, mit denen der Versicherte vom FdV das Entschlüsseln der verschlüsselten ePA 2.6-Akteninhalte anstoßen kann.  [<=]

In der ePA für alle ist der Zugriff über einen Client der ePA-Version 2.x nicht mehr möglich, da sich die grundsätzliche Architektur und die Schnittstellen und Protokolle geändert haben.

2.8.3 Bereinigung von Registry und Repository im Zuge der Migration

A_24964 - XDS Document Service - Migration: Isolation der Migration

Der XDS Document Service MUSS die Verarbeitung von entschlüsselten Dokumenten, die im Rahmen der Migration durchgeführt werden, so technisch isolieren, dass kein Schaden für Aktenkonten oder das ePA-Aktensystem selbst entsteht. [<=]

A_25730 - XDS Document Service - Konvertierung von PDF in PDF/A bei der Datenmigration

Der XDS Document Service MUSS die Konvertierung von entschlüsselten PDF-Dokumenten in PDF/A-Dokumente, die im Rahmen der Migration durchgeführt wird, in einer Aktenkontoverwaltungs-VAU oder in einer getrennten VAU-Instanz durchführen, wobei

  • die Konvertierung innerhalb der Aktenkontoverwaltungs-VAU ausschließlich für die Datenmigration von ePA2.6 auf die ePA3.0 verwendet werden darf und
  • es bei einer getrennten VAU-Instanz eine 1:1-Beziehung zur Aktenkontoverwaltungs-VAU geben muss (d.h. die getrennte VAU-Instanz zur Konvertierung ist nur mit einer (1) Aktenkontoverwaltungs-VAU verbunden und eine Aktenkontoverwaltungs-VAU nur mit einer (1) VAU-Instanz für die Konvertierung) und die getrennte VAU-Instanz für die Konvertierung ausschließlich für die Datenmigration von ePA2.6 auf die ePA3.0 verwendet werden darf.
[<=]

A_25002 - XDS Document Service - Migration: Umbenennung von Ordnern

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 in den Werten von Folder.codeList die mit ePA 3.0 gegebenenfalls geänderten Kategoriennamen als Werte verwenden.  [<=]

A_24562 - XDS Document Service - Migration: Auflösung abgekündigter Ordner

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 die abgekündigten Kategorien auflösen. Dabei MÜSSEN sämtliche Dokumente gemäß der Einordnungsregeln in A_19388-* neu Ordnern zugeordnet werden und die Ordner der abgekündigten Kategorien gelöscht werden. [<=]

Die in ePA 2 angelegten dynamischen Ordner der Kategorie childsrecord können Kinder identifizieren, deren Daten nicht in ihren eigenen Akten gehalten wurden. Diese dynamischen Ordner sind nach folgender Regel in ePA 2 vom Primärsystem angelegt worden: Folder.title wurde mit dem Namen und Geburtsdatum des Kindes belegt. Bildungsregel: Nachname + ", " + 1. Vorname + " "Datum im Format TT.MM.YYYY. Beispiel: "Musterkind, Max 03.03.2017".

Die Kinderuntersuchungshefte werden nicht migriert und verbleiben im Ordner childsrecord.

A_24963 - XDS Document Service - Migration: Keine Übernahme von Dokumenten mit unzulässigem Format

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 sämtliche Dokumente der ePA2.6 gemäß A_24864-* auf die zulässigen Dokumentenformate prüfen und Dokumente in einem nicht erlaubten Format nicht in die "ePA für alle" migrieren. [<=]

A_24966 - XDS Document Service - Migration: Konvertieren von PDF- in PDF/A-Dokumente

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 Dokumente im PDF-Format in ein PDF/A-Format konvertieren und ausschließlich das Dokument im PDF/A-Format in das Aktenkonto übernehmen. [<=]

A_25032 - XDS Document Service - Migration: Information des Versicherten zur Nichtübernahme von Dokumenten in bestimmten Formaten

Der Anbieter des ePA-Aktensystems MUSS den Versicherten darüber informieren, das Dokumente in der ePA2.6, die ein bestimmtes Format besitzen, nicht in die "ePA für alle" übernommen werden und informieren, um welche Formate es sich handelt. [<=]

A_24520 - XDS Document Service - Migration: Prüfsumme Dokument erzeugen

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 für jedes Dokument, das im Klartext vorliegt, die kryptographische Prüfsumme des Dokumentes berechnen und in DocumentEntry.hash hinterlegen. Dabei MUSS SHA-256 verwendet werden. Außerdem MUSS die Dokumentengröße für das Feld DocumentEntry.size berechnet und gesetzt werden.  [<=]

A_24847 - XDS Document Service - Migration: Identifizieren und Auflösen von Dokumenten-Dubletten

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 zum Zeitpunkt der Entschlüsselung eine Dublettenerkennung durchführen. Dabei werden entschlüsselte Dokumente innerhalb und außerhalb von Sammlungen verglichen mit Dokumenten, die durch eine zwischenzeitliche Nutzung von ePA für alle in die Akte eingestellt worden sind. Dubletten werden anhand der Gleichheit des Hash-Wertes im Feld documentEntry.hash identifiziert. Das Dokument mit dem älteren Einstelldatum wird verworfen. [<=]

A_24851 - XDS Document Service - Migration: Dokumente und Ordner mergen

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 zum Zeitpunkt der Entschlüsselung des Datenbestands die Ordnerinhalte einer Kategorie vergleichen, falls es neben den migrierten ePA 2.6-Akteninhalten durch eine ePA3-Aktennutzung ebenfalls Ordnerinhalte gibt. Unter Berücksichtigung der Dublettenprüfung werden alle Dokumente von zwei Ordnern derselben Kategorie (in ePA 2.6 bzw. 3.0 entstanden) in einen Ordner zusammengeführt. Dokumente und RPLC-Ketten, die durch die documentEntry.uniqueId erkennbar zusammen gehören, werden unter Wahrung der Abfolge der Einstelldaten zusammengeführt und das jüngste Dokument als aktives Dokument der Kette behandelt. Dokumente erhalten eine rootDocumentUniqueId gemäß A_24451-*, falls noch nicht vorhanden.  [<=]

A_24848 - XDS Document Service - Migration: Auflösung von duplizierten dynamischen Ordnern

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 anhand des Titels dynamischer Ordner erkennen, ob zwei dynamische Ordner zur selben Kategorie vorliegen, z.B. zur selben Schwangerschaft. In diesem Falle werden alle vorhandenen Einträge in einen der Ordner hinein gemergt und der andere Ordner gelöscht.
[<=]

A_24522 - XDS Document Service - Migration: Erzeugen von Titeln für Dokumente

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf die ePA 3.0 sicherstellen, dass bei jedem Dokument das Metadatum DocumentEntry.title belegt ist. documentEntry.title=" " oder "" ist gleichbedeutend mit einem nicht vorhandenen Titel. Wenn title nicht belegt ist, MUSS title gemäß folgender Tabelle belegt werden. 

Typ  Titel
Dokumente, die einem Implementation Guide zugeordnet sind IG.displayName
andere Dokumententypen Die gemäß A_24524-* bereinigte DocumentEntry.URI ohneExtension 
[<=]

A_24523 - XDS Document Service - Migration: Löschen von ConfidentialityCodes

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 Dokumente und Ordner mit dem confidentialityCode "very restricted" auf die GeneralDenyPolicy setzen. Danach werden die confidentialityCodes gelöscht.   [<=]

A_24817 - XDS Document Service - Migration: Normalisieren und Validieren der URI

Der XDS Document Service MUSS im Zuge der Migration von ePA 2.6 die ePA 3.0 für sämtliche Dokumente die documentEntry.URI gemäß A_24524-* und A_23447-* normalisieren und validieren. [<=]

A_24866 - Audit Event Service - Migration: Übernahme von Protokolldaten

Der Audit Event Service MUSS im Zuge der Migration von ePA 2.6 auf ePA 3.0 sämtliche Protokolldaten des Versicherten in die migrierte Akte übernehmen. Für die Migration werden alte Protokolldaten in ein PDF/A überführt und in die Kategorie "patient" eingestellt. [<=]

2.8.4 Protokollierung der Migration

A_25029 - XDS Document Service - Protokollierung der Migration der medizinischen Daten

Der XDS Document Service MUSS den Vorgang der Migration der medizinischen Daten (Dokumente, Folder, Metadaten) gemäß A_24704* protokollieren. Dabei ist die Migration als atomares Ereignis zu betrachten und mit einem Protokolleintrag zu dokumentieren. Für den Protokolleintrag ist folgende Wertebelegung zu berücksichtigen:

Tabelle 2: Protokollierung der Migration der medizinischen Daten

Strukturelement Wert Erläuterung
AuditEvent.type "object"
AuditEvent.outcome 0
Migration war erfolgreich und ist abgeschlossen. Dieser Wert wird auch gesetzt, wenn einzelne Dokumente (z.b. Dokumente bestimmter Formate) nicht übernommen werden konnten.
12 Migration wurde abgebrochen und wird ggf wiederholt, keine Datenübernahme ist erfolgt.
In der AuditEvent.entity.detail Struktur werden keine Informationen hinterlegt.
AuditEvent.action E
AuditEvent.entity.name "Migration"
AuditEvent.entity.description <Hinweistext>
AuditEvent.entity.detail

type value[x] dieses Strukturelement ist zu versorgen, wenn einzelne Dokumente nicht übernommen werden konnten
"DocumentTitle" <DocumentEntry.title> Name des Dokumentes, welches nicht übernommen werden konnte
"DocumentUniqueId" <Document.uniqueId> ID des Dokumentes, welches nicht übernommen werden konnte
"DocumentFormatCode" <DocumentEntry.formatCode> kodiert als Datentyp „Coded String“ gemäß [IHE-ITI- TF3].
"DocumentMimeType" <DocumentEntry.mimeType>
[<=]

A_25031 - Audit Event Service - Protokollierung der Migration der Protokolldaten des Versicherten

Der Audit Event Service MUSS den Vorgang der Migration der Protokolldaten des Versicherten gemäß A_24704* protokollieren.
Dabei ist die Migration als atomares Ereignis zu betrachten und mit einem Protokolleintrag zu dokumentieren.
Für den Protokolleintrag ist folgende Wertebelegung zu berücksichtigen:


Tabelle 3: Protokollierung der Migration der Protokolldaten des Versicherten

Strukturelement Wert Erläuterung
AuditEvent.type "object"
AuditEvent.action E
AuditEvent.entity.name "MigrationProtocol"
AuditEvent.entity.description <Hinweistext>
dieses Strukturelement ist nur zu versorgen, wenn bei der Migration Fehler aufgetreten sind
[<=]

2.9 Performance aus Anwendersicht

Im Gegensatz zu den Performancevorgaben, welche in [gemSpec_Perf] gemacht werden und welche lediglich die Aktivitäten im Aktensystem berücksichtigen, stellt sich die Leistungsfähigkeit und Nutzbarkeit in der Wahrnehmung der Clients oftmals anders dar. Aus diesem Grund werden die Endgeräte (Primärsystem und FdV) für definierte Anwendungsfälle (sogenannte UX-Usecases) dazu verpflichtet, eigene Messungen durchzuführen und diese Messwerte an eine definierte Schnittstelle im Aktensystem zu übermitteln. Das Aktensystem verarbeitet diese Informationen und leitet das konsolidierte Ergebnis im Rahmen der Rohdatenlieferung weiter an die gematik. Auf diese Weise erhalten sowohl die gematik (im Rahmen der Gesamt-Produktverantwortung) als auch die Anbieter der Aktensysteme Informationen darüber, wie die Anwendung ePA bei den Nutzern (insb. in der LEU und bei Versicherten) hinsichtlich bestimmter Kernfunktionalitäten wahrgenommen wird.

Die Anwendungsfälle umfassen dabei unter anderem das Login und das Hoch- bzw. Herunterladen von Dokumenten / Daten. Eine spezifische Beschreibung ist in der Spezifikation des FdVs bzw. im Implementierungsleitfaden für Primärsysteme zu finden.

Die Übermittlung der Messdaten erfolgt im Anschluss an den erfolgreichen Abschluss des Anwendungsfalles an das gleiche  Aktensystem (unter Verwendung der Schnittstelle InformationService.setUserExperienceResult), bei dem auch der Anwendungsfall stattgefunden hat. Hierbei ist die Schnittstelle zur Lieferung der Messdaten an der Komponente "Information Service" nur für Primärsysteme normiert. Es steht dem Hersteller des Aktensystems frei, die Lieferschnittstelle für Messdaten von FdVs selbst oder nach dem Vorbild der PS-Schnittstelle zu implementieren.

Die eingegangenen Messergebnisse werden vom Aktensystem verarbeitet und anschließend gemäß der Vorgaben aus [gemSpec_Perf] an die Betriebsdatenerfassung der gematik im Rahmen der Rohdatenlieferung übermittelt.

A_24570-01 - Verarbeitung von UX-Messdaten

Das Aktensystem MUSS für die im zu betrachtenden Zeitintervall der Rohdatenlieferung (gemäß [gemSpec_Perf]) eingegangenen Messdaten je UX-Usecase, je ClientID und je Client-Version folgende Werte ermitteln und gemäß [gemSpec_Perf] übermitteln:
- Durchschnittswert der Messergebnisse
- Anzahl der berücksichtigten Messergebnisse
- Maximalwert
- Minimalwert [<=]

Die Versionsnummer des Useragents wird bei der Konsolidierung nicht weiter verarbeitet und dient dem Anbieter des ePA-Aktensystems zur Identifikation von möglichen Fehlerquellen im Rahmen des Eigenmonitorings und Troubleshootings.

3 Funktionsmerkmale

3.1 Aktenkonto eines Versicherten (Health Record)

Ein ePA-Aktenkonto wird durch den Kostenträger eines Versicherten als Anbieter der ePA für jeden Versicherten angelegt und für die Nutzung im Rahmen der gesetzlichen Vorgaben zur Verfügung gestellt. Die Anlage eines Aktenkontos erfordert keine Beantragung durch den Versicherten, dieser kann einer Anlage seines Aktenkontos jedoch widersprechen.

3.1.1 Widerspruch des Versicherten gegen die Nutzung der elektronischen Patientenakte

Der Widerspruch des Versicherten gegen die grundsätzliche Nutzung der ePA kann jederzeit erfolgen. Wird dieser im Vorfeld der Anlage eines Aktenkontos erklärt, wird kein Aktenkonto für diesen Versicherten erzeugt. Existiert zum Zeitpunkt des Widerspruchs schon ein Aktenkonto (in einem beliebigen Zustand), so wird dieses gelöscht und alle enthaltenen Daten werden gelöscht.

Die Regelungen zum Widerspruch oder die Rücknahme des Widerspruchs gegen die grundsätzliche Nutzung der ePA sind durch den Anbieter der ePA eigenständig im Rahmen der gesetzlichen Vorgaben umzusetzen und sind nicht Bestandteil dieser Spezifikation.

Für die vereinfachte Prüfung auf einen bereits erteilten Widerspruch des Versicherten bei einem Wechsel des Kostenträgers muss die Information zu einem Widerspruch jedoch vermerkt und über die Schnittstelle I_Information_Service_Account [I_Information_Service_Account] abrufbar sein.

A_23886 - Anbieter ePA-Aktensystem - Keine Aktenkontoanlage bei Widerspruch des Versicherten

Der Anbieter des ePA-Aktensystems DARF ein Aktenkonto für den Versicherten NICHT anlegen, wenn ein Widerspruch des Versicherten gegen die Nutzung der elektronischen Patientenakte vorliegt. [<=]

Der Widerspruch gegen die grundsätzliche Nutzung der ePA kann durch den Versicherten jederzeit zurückgenommen werden. In diesem Fall wird wie bei der Anlage eines neuen Aktenkontos für den Versicherten verfahren.

A_25181 - Anbieter ePA-Aktensystem - Aktenkontoanlage bei Zurücknahme des Widerspruchs des Versicherten

Falls ein Versicherter den Widerspruch gegen die grundsätzliche Nutzung der ePA zurücknimmt MUSS der Anbieter des ePA-Aktensystems ein Aktenkonto für den Versicherten unverzüglich anlegen. [<=]

3.1.1.1 Widerspruch gegen das Einstellen von Abrechnungsdaten durch den Kostenträger

Die Regelungen zum Widerspruch oder die Rücknahme des Widerspruchs gegen das Einstellen von Abrechnungsdaten des Kostenträgers in die ePA sind durch den Anbieter der ePA eigenständig im Rahmen der gesetzlichen Vorgaben umzusetzen und sind nicht Bestandteil dieser Spezifikation.

3.1.2 Lebenszyklus und Zustände eines Aktenkontos

Ein Aktenkonto durchläuft in seinem Lebenszyklus diverse Zustände. Einige dieser Zustände sind für rein administrative Vorgänge vorgesehen (Initialisierung, Umzug des Aktenkontos zu einem anderen Anbieter), andere für die Nutzung der Akte im Versorgungsprozess. Diese Nutzung für Versorgungsprozesse ist dabei auf den Zustand "Activated" eingeschränkt.

Eine Übersicht der unterschiedlichen Status und der Bedingungen für den Statusübergang sind in der folgenden Tabelle dargestellt.

Tabelle 4: Zustandswechsel im Lebenszyklus eines Aktenkontos

Zustand
Erläuterung
zulässige Transitionen
Folgezustand
UNKNOWN
Für einen Versicherten existiert kein Aktenkonto.
Konto initialisieren

Initialized
INITIALIZED
Ein neues Aktenkonto ist konfiguriert und für eine Aktivierung vorbereitet. Die initialen Befugnisse sind erstellt. Eine Nutzung des Aktenkontos im Versorgungsprozess und die Nutzung medizinischer Dokumente ist jedoch erst nach der Aktivierung möglich.
Die Daten eines existierenden Aktenkontos werden importiert.
Widerspruch gegen die Nutzung der ePA
Unknown
Explizite Aktivierung des Kontos durch den Anbieter. Bei existierendem Aktenkonto bei einem anderen Anbieter erfolgt die Aktivierung erst nach einem Import der Daten des Aktenkontos.


Activated
ACTIVATED
Das Aktenkonto ist aktiv und kann von befugten Nutzern und Nutzergruppen im Versorgungsprozess verwendet werden.
Vorbereitung des Umzugs des Aktenkontos zu einem anderen Anbieter (Erstellung des Exportpakets)
Suspended
Widerspruch gegen die Nutzung der ePA 
Unknown
SUSPENDED Die Daten des Aktenkontos des Versicherten werden zu einem neuen Anbieter übertragen.
Die Nutzung des Aktenkontos ist in diesem Zustand nicht möglich.
Erfolgreicher Abschluss des Umzugs
Widerspruch gegen die Nutzung der ePA
Unknown
Der Bereitstellungszeitraum des Exportpakets ist abgelaufen. Activated

Die Anforderungen in den folgenden Kapiteln legen die zulässigen Zustandswechsel eines Kontos fest.

A_24980 - Aktenkontoverwaltung – Protokollierung des Aktenkontostatus

Die Aktenkontoverwaltung MUSS bei Änderungen des Status eines Aktenkontos jeweils einen Protokolleintrag gemäß A_24704* erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 5: Protokollierung von Änderungen des Aktenkontostatus

Strukturelement
Wert
Erläuterung
AuditEvent.type "object"
AuditEvent.action
E
Erste Aktivierung des Aktenkontos,
Statuswechsel des Aktenkontos nach der ersten Aktivierung
AuditEvent.entity.name
"HealthRecordStatus"
Änderung des Aktenkontostatus
AuditEvent.entity.detail
type
value[x]
 
"previousRecordState" <bisheriger Status des Aktenkontos> Status des Aktenkontos vor der Änderung, beispielsweise "INITIALIZED"
 
"RecordState"
<Status des Aktenkontos>
Zielstatus der Aktenkontos, beispielsweise "ACTIVATED"

[<=]

Hinweis: Der Statuswechsel von UNKNOWN auf INITIALIZED bei der Erstellung eines neuen Aktenkontos wird nicht protokolliert.

3.1.3 Anlage eines neuen Aktenkontos

Ein neues Aktenkonto wird für einen Versicherten bei seinem Anbieter automatisch angelegt, wenn der Versicherte der grundsätzlichen Nutzung der ePA nicht widerspricht oder einen zuvor gegebenen Widerspruch zurücknimmt und bei einem anderen Anbieter kein Aktenkonto für den Versicherten existiert.

Die Anlage eines neuen Aktenkontos erfolgt in zwei Stufen: der Initialisierung und der darauffolgenden Aktivierung.

Bei der Initialisierung wird ein neues Aktenkonto bei einem Betreiber eines ePA-Aktensystems für den Versicherten angelegt und die Dienste des Aktenkontos für die Nutzung vorbereitet. Die Identifikation eines Aktenkontos erfolgt dabei über die KVNR des Versicherten (unveränderlicher Anteil der Versichertennummer) im Aktensystem und gegenüber Clients bei Nutzung der ePA.

A_24336 - Anbieter ePA-Aktensystem - Identifizerung eines Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS bei der Anlage eines neuen Aktenkontos die KVNR des Versicherten zur Identifikation des Aktenkontos im Aktensystem verwenden und sicherstellen, dass diese Identifikation eines Aktenkontos nicht verändert werden kann. [<=]

A_24302 - Anbieter ePA-Aktensystem - verpflichtende Nutzung von startRelocation

Der Anbieter des ePA-Aktensystems MUSS bei der Anlage eines neuen Aktenkontos durch Verwendung der Operation startRelocation gemäß [I_Information_Service_Accounts] auf Existenz eines Aktenkontos des Versicherten bei allen anderen Anbietern prüfen. [<=]

A_24790 - Anbieter ePA-Aktensystem - keine unbegründete Nutzung von startRelocation

Der Anbieter des ePA-Aktensystems DARF die Operation startRelocation gemäß [I_Information_Service_Accounts] für Zwecke abweichend der Vorgaben in A_24302* NICHT nutzen. [<=]

A_24789 - Anbieter ePA-Aktensystem - verpflichtender Import eines existierenden Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS die Inhalte eines existierenden Aktenkontos in ein neues, initialisiertes Aktenkonto vor dessen Aktivierung übernehmen. [<=]

Der Import eines existierenden Aktenkontos vor dessen Aktivierung erfolgt unter Verwendung des Health Record Relocation Service (3.2 Health Record Relocation Service ).

A_15870-01 - Anbieter ePA-Aktensystem - Abbruch bei Nichtverfügbarkeit anderer Anbieter

Der Anbieter des ePA-Aktensystems MUSS die Erstellung eines Aktenkontos abbrechen, wenn die Operation startRelocation gemäß [I_Information_Service_Accounts] mindestens bei einem anderen Anbieters eines ePA-Aktensystems eine technische Fehlermeldung liefert oder dieser nicht erreichbar ist. [<=]

A_23775 - Anbieter ePA-Aktensystem - Neues Aktenkonto anlegen

Der Anbieter des ePA-Aktensystems MUSS für Versicherte jeweils ein Aktenkonto anlegen, wenn kein Widerspruch des Versicherten gegen die Nutzung der ePA vorliegt, und dabei die KVNR des Versicherten zur Identifikation eines Aktenkontos im Aktenkonto registrieren. Das initialisierte Aktenkonto MUSS den Status INITIALIZED erhalten. [<=]

Für die Geräteregistrierung bei Nutzung eines ePA-FdV durch den Versicherten ist eine E-Mail-Adresse des Versicherten für Bestätigung der Geräteregistrierung erforderlich. Falls vorhanden, kann diese E-Mail-Adresse bei der Anlage eines Aktenkontos im Device Management hinterlegt werden. Ansonsten muss eine E-Mail-Adresse bei der ersten Einrichtung eines ePA-FdV zur Nutzung des Aktenkontos hinterlegt werden. Eine E-Mail-Adresse muss vor der Übernahme in das Aktensystem validiert sein, beispielsweise durch Versand eines Bestätigungslink an diese E-Mail-Adresse.

A_14996-01 - Anbieter ePA-Aktensystem - Manuelle Ergänzung E-Mail-Adresse

Der Anbieter des ePA-Aktensystems MUSS es dem Versicherten auf geeignetem Weg ermöglichen, die Registrierung einer E-Mail-Adresse für die Geräteverwaltung auch nachträglich vorzunehmen. [<=]

A_14993-02 - Anbieter ePA-Aktensystem - Mailadresse validieren

Der Anbieter des ePA-Aktensystems MUSS eine Mailadresse

  • bei der ersten Hinterlegung im Aktensystem,
  • bei einer Änderung der Mailadresse
auf Gültigkeit hin validieren. [<=]

A_24369 - Anbieter ePA-Aktensystem - Initialisierung des Aktenkontos

Der Anbieter des ePA-Aktensystems MUSS die Initialisierung der Bestandteile

  • Consent Decision Management (initiale Entscheidungen)
  • Constraint Management (Policies)
  • Entitlement Management (initiale Befugnisse und Befugnisausschlüsse)
  • Information Service (initiale Entscheidungen "Versorgungsprozess")
  • XDS Document Service (statische Aktenkontoinhalte)
  • Device Management 
  • Authorization Service
  • Audit Event Service
  • Medication Service
vor der Aktivierung eines Aktenkontos durchführen. Die genannten Bestandteile MÜSSEN nach der Aktivierung des Aktenkontos sofort nutzbar sein. [<=]

Im Zustand INITIALIZED obliegt es dem Anbieter, ein Aktenkonto mittels administrativer Eingriffe in die verschiedenen Bestandteile des Aktensystems und -kontos auf die Aktivierung vorzubereiten bzw. zu konfigurieren.

A_26005 - ePA-Aktensystem – Optionale Schnittstelle zum Einbringen von initialen Befugnissen

Das ePA-Aktensystem KANN eine Schnittstelle für Kostenträger anbieten, über die Kostenträger die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle ins ePA-Aktensystem einbringen können. [<=]

A_26006 - ePA-Aktensystem – Nutzen der optionalen Schnittstelle zum Einbringen von initialen Befugnissen ausschließlich im Status INITIALIZED

Falls das ePA-Aktensystem eine Schnittstelle für Kostenträger anbietet, über die Kostenträger die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle für ein Aktenkonto einbringen können, MUSS das ePA-Aktensystem sicherstellen, dass diese Schnittstelle ausschließlich genutzt werden kann, wenn sich das Aktenkonto im Status INITIALIZED befindet.
[<=]

Das Aktenkonto wird nach Abschluss der Initialisierung durch den Anbieter aktiviert und kann dann durch befugte Nutzer und  Nutzergruppen verwendet werden. Eine Aktivierung erfolgt für den Rollout der ePA Version 3 im Kontext des ePA Go-Live-Termins und zu späteren, individuellen Zeitpunkten, wenn Versicherte als ePA-Nutzer neu dazu gekommen (bspw. Widerspruch wird zurückgenommen und ePA wird später angelegt oder Versicherte Person kommt erstmalig ins Gesundheitssystem im Falle eines Zuzugs oder eines Neugeborenen).

A_24335 - Anbieter ePA-Aktensystem - Neues Aktenkonto aktivieren

Der Anbieter des ePA-Aktensystems MUSS ein neues Aktenkonto nach Abschluss der Initialisierung aktivieren (Status ACTIVATED), wenn die gesetzliche Widerspruchsfrist abgelaufen ist. [<=]

3.1.4 Löschen eines Aktenkontos

Die Löschung eines Aktenkontos bei einem Anbieter und aller darin enthaltenen Daten kann in folgenden Situationen erforderlich sein:

  • Widerspruch des Versicherten gegen die Nutzung der ePA,
  • nach erfolgreichem Wechsel des Anbieters durch den Versicherten und abgeschlossener Datenübernahme aus dem bisherigen Aktenkonto,
  • nach Beendigung des Versicherungsverhältnisses des Versicherten bei seinem Kostenträger.

Ein Versicherter kann nach der Anlage eines Aktenkontos der grundsätzlichen Nutzung der ePA widersprechen. Liegt dieser erklärte Widerspruch vor, werden das Aktenkonto des Versicherten und sämtliche Inhalte durch den Anbieter des Aktenkontos gelöscht.

Bei einem Anbieterwechsel erfolgt die Übernahme der Daten des bisherigen Aktenkontos zu dem neuen Anbieter. Nach erfolgreichem Abschluss der Datenübernahme in das Aktenkonto des neuen Anbieters löscht der bisherige Anbieter das Aktenkonto des Versicherten und alle darin enthaltenen Daten.

Kündigt ein Versicherter das Vertragsverhältnis ohne Übernahme der Daten zu einem neuen Anbieter, löscht der Anbieter des Aktenkontos des Versicherten nach einer angemessenen Wartezeit, bzw. nach Ablauf von vorgeschriebenen Bereitstellungs- und Aufbewahrungszeiträumen, das Aktenkonto und alle darin enthaltenen Daten.

Vor der Ausführung der endgültigen Löschung des Aktenkontos muss es dem Versicherten ermöglicht werden, die Protokolldaten (auch unter Einbindung der Ombudsstelle) für seinen eigenen Gebrauch außerhalb des Aktenkontos zu sichern. Dieses ist nicht erforderlich, wenn das Aktenkonto in Folge eines erfolgreichen Umzugs zu einem anderen Anbieter geschlossen wird.

A_25289 - Anbieter ePA-Aktensystem - Löschen des Aktenkontos durch den Kostenträger

Der Anbieter des ePA-Aktensystems MUSS das Aktenkonto eines Versicherten inklusive aller enthaltenen Daten löschen (sämtliche Dokumente, Schlüsselmaterial, Protokolle, Widerspruchsinformation, Befugnisse und Beschränkungen), wenn dies durch den zuständigen Kostenträger beauftragt wird. [<=]

3.2 Health Record Relocation Service

Transfer eines Aktenkontos zu einem neuen Anbieter (Aktenkontoumzug).

Wechselt der Versicherte den Kostenträger bzw. den Anbieter seines Aktenkontos, so erfolgt der Umzug der Inhalte seines bestehenden Aktenkontos vom bisherigen Anbieter zu einem neuen Anbieter weitestgehend automatisiert.

Seitens der Aktensysteme werden für einen Aktenkontoumzug zwei Schnittstellen angeboten: I_Health_Record_Relocation_Service zur Nutzung durch die Anbieter (alt und neu) für den Zugriff auf das Aktenkonto des Versicherten und I_Information_Service_Accounts für die Interaktion der Aktensysteme (alt und neu) untereinander. Die notwendige Kommunikation der Kassen-Backends mit ihren Aktensystemen außerhalb der VAU erfolgt dabei in Absprache der Beteiligten und ist nicht Bestandteil der genannten Schnittstellen.

A_24786 - Health Record Relocation Service - Realisierung der Schnittstelle I_Health_Record_Relocation_Service

Der Health Record Relocation Service MUSS die Operationen der Schnittstelle I_Health_Record_Relocation_Service gemäß [I_Health_Record_Relocation_Service] umsetzen. [<=]

Hinweis: Zur Schnittstelle I_Information_Service_Accounts siehe 3.15.2 Information Service - Account ).

A_24821 - Health Record Relocation Service - Suspendierung des Aktenkontos

Der Health Record Relocation Service MUSS sicherstellen, dass das Aktenkontos für die Erstellung eines Exportpakets auf den Status SUSPENDED gesetzt wird. [<=]

A_24827 - Health Record Relocation Service - Reaktivierung des Aktenkontos

Der Health Record Relocation Service MUSS sicherstellen, dass ein Aktenkonto im Status SUSPENDED nach einem Abbruch eines Transfers von einem Anbieter zu einem anderen Anbieter aufgrund eines Fehlers (Datenübertrag ist nicht erfolgt) in den Status ACTIVATED gesetzt wird. [<=]

A_25005-01 - Health Record Relocation Service - Daten des Exportpakets

Der Health Record Relocation Service MUSS sicherstellen, dass alle Daten des Aktenkontos in das Exportpaket übernommen werden aus:

  • XDS Document Service
  • Medication Service
  • Consent Management
  • Constraint Management
  • Audit Event Service
  • Entitlement Management (außer Befugnisse für Versicherter, E-Rezept-Fachdienst, Kostenträger und Ombudsstelle).
  • E-Mail Management (die E-Mail-Adresse des Aktenkontoinhabers (falls vorhanden) sowie für alle Vertreter die E-Mail-Adressen, sofern sie die dem exportierenden Aktensystem bekannt sind).
[<=]

Hinweis: Die Geräteregistrierungen des Versicherten oder der Vertreter werden nicht exportiert. Bei einem neuen Anbieter ist für den Versicherten eine erneute Geräteregistrierung erforderlich.

A_25605 - Health_Record_Relocation_Service - Erstellung des Exportpakets

Der Health Record Relocation Service MUSS sicherstellen, dass das Exportpaket gemäß der Vorgaben in [HealthRecordMigration] bezüglich der Struktur, der Formate für die enthaltenen Daten und die Verschlüsselung erfolgt.  [<=]

A_25012 - Health Record Relocation Service - Signatur der Befugnisse

Der Health Record Relocation Service MUSS sicherstellen, dass die gemäß A_23734-* signierten Anteile einer Befugnis mit der Signaturidentität ID.FD.SIG (Rolle oid_epa_vau) signiert werden. [<=]

Hinweis: Der CMAC einer Befugnis wird nicht ins Export-Paket übernommen.

A_25719 - Health Record Relocation Service - JWT der Befugnis im Exportpaket

Der Health Record Relocation Service MUSS sicherstellen, dass die Befugnisse im Exportpaket als gültig signierte JWT mit den dargestellten Inhalten abgelegt sind:

Befugnis Claim Name Claim Beispiel
Protected Header
"typ" "JWT"
"alg" "ES256"
"x5c" Signaturzertifikat C.FD.SIG
Payload
"iat" Zeitstempel Ausgabezeitpunkt
"exp" Verfalldatum, = "iat" + 8Tage" Mindestens für den gesamten Bereitstellungszeitraum des Exportpakets
"insurantId" KVNR des Aktenkontos A123456789
"actorId" Identifier (Telematik-id oder KVNR) 3-883110000092471
"validTo" Ende der Gültigkeit,
gemäß [RFC3339], z.B. 2025-06-30T21:59:59Z oder 2025-06-30T23:59:59+02:00
[<=]

Der Wert "ES256" (JWS-Parameters "alg") gilt auch für die Kurve "brainpoolP256r1" (also nicht nur für P-256). Die Signatur und Kodierung des JWT ist gemäß [RFC7515] zu erstellen."

A_24787-01 - Health Record Relocation Service - Verschlüsselung des Exportpaktes

Der Health Record Relocation Service MUSS sicherstellen, dass Exportpakete ausschließlich verschlüsselt für den Download zu einem anderen Betreiber zur Verfügung stehen. Für die Verschlüsselung MUSS das kryptographische Material des ENC-Zertifikats verwendet werden, welches mittels der Regel hsm-r7 vom VAU-HSM abgerufen wurde. [<=]

A_24942 - Health Record Relocation Service – Prüfung Provider ENC Zertifikat

Der Health Record Relocation Service MUSS das übergebene Provider ENC-Zertifikat mittels TUC_PKI_018 (OCSP-Graceperiod=12h, PolicyList= oid_fd_enc, professionOID = oid_epa_vau ) prüfen und ungültige Zertifikate mit der Fehlermeldung " CERTICATE_INVALID " ablehnen. [<=]

A_21750 - Health Record Relocation Service – Integritätsschutz Exportpaket

Der Health Record Relocation Service MUSS das erstellte Exportpaket mit einem "Digest" HTTP Response Header (https://tools.ietf.org/html/rfc5843) als Integritätsschutz  versehen und dabei als Digest Algorithmus SHA-256 verwenden.
Beispiel Digest-Header:
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
[<=]

A_15051 - Health Record Relocation Service - Authentisierung gegenüber einem neuen Aktenanbieter

Der Health Record Relocation Service, welcher das Exportpaket zur Verfügung stellt, MUSS sich beim Abruf des Exportpakets durch ein anderes ePA-Aktensystem mit der TLS-Identität oid_epa_mgmt und Zertifikatsprofil C.FD.TLS-S authentisieren.
[<=]

A_15048 - Health Record Relocation Service - Authentifizierung des neuen Aktenanbieters

Der Health Record Relocation Service MUSS den Abruf des Exportpakets durch ein anderes ePA-Aktensystem ablehnen, wenn sich der abrufende Client nicht als ePA-Aktensystem in der Rolle oid_epa_mgmt in einem TLS-Zertifikat C.FD.TLS-C authentisiert. [<=]

A_17236 - Health Record Relocation Service - Prüfung der TLS-Zertifikate

Der Health Record Relocation Service MUSS bei der Authentifizierung eines anderen Aktensystems beim Abruf des Exportpakets die Prüfung der verwendeten TLS-Zertifikate entsprechend TUC_PKI_018 durchführen. Zur Prüfung des TLS-Zertifikats C.FD-TLS-S sind dabei die Parameter PolicyList=oid_fd_tls_s, IntendedKeyUsage=digitalSignature, intendedExtendedKeyUsage=id-kp-serverAuth, OCSP-Graceperiod=60 Minuten, Offline-Modus=nein zu verwenden. Zur Prüfung des TLS-Zertifikats C.FD-TLS-C sind dabei die Parameter PolicyList=oid_fd_tls_c, IntendedKeyUsage=digitalSignature, intendedExtendedKeyUsage=id-kp-clientAuth, OCSP-Graceperiod=60 Minuten, Offline-Modus=nein  zu verwenden.
[<=]

A_15703 - Health Record Relocation Service - Verfügbarkeit Export-Paket

Der Health Record Relocation Service MUSS ein erstelltes Export-Paket für maximal sieben Kalendertage zum Abruf durch einen anderen Anbieter eines ePA-Aktensystems bereithalten. [<=]

A_21239 - Health Record Relocation Service – Verhalten bei Nichtabholen des Exportpakets

Der Health Record Relocation Service MUSS nach Ablauf des Bereithaltungszeitraums entsprechend A_15703* ein erstelltes Export-Paket löschen und den Status des Aktensystems von  SUSPENDED auf ACTIVATED zurücksetzen. [<=]

Hinweis: siehe dazu auch 3.2.1.7.3 Nicht erfolgter Download oder fehlende Rückmeldung durch den neuen Anbieter 

A_14905-04 - Health Record Relocation Service – Import des Exportpakets des vorhergehenden Aktenkontos

Der Health Record Relocation Service MUSS das vom vorhergehenden Anbieter ePA-Aktensystem des Versicherten bezogene Exportpaket, in das neue Aktenkonto importieren und dazu:

  • das Exportpaket mittels des privaten ENC-VAU-Schlüssels des neuen Betreibers entschlüsseln,
  • den Digest gemäß A_21750-* prüfen,
  • die Befugnisse mit Regel "rr5" (siehe Tab_AS_Entitlement_Registration_Rules im Aktensystem) registrieren und
  • falls DocumentEntry.originalURI im Exportpaket vorhanden ist, wird für jedes Dokument eines SubmissionSet der Inhalt von DocumentEntry.URI durch den Inhalt von DocumentEntry.originalURI ersetzt. (Hinweis: DocumentEntry.originalURI darf nicht als eigenständiges Metadatum in die Registry übernommen werden, da es lediglich dem Transport des Originalwertes von DocumentEntry.URI aus dem alten Aktensystem dient.
[<=]

A_21548-01 - Health Record Relocation Service - Information der Vertreter über neuen FQDN nach Abschluss des Anbieterwechsels

Der Health Record Relocation Service MUSS sicherstellen, dass alle Vertreter nach erfolgreichem Import des Exportpakets und somit Abschluss des Anbieterwechsels über Anbieterwechsel und den FQDN des neuen Aktensystems des Versicherten informiert werden, so dass sie in der Lage sind, die erforderliche initiale Anmeldung und Geräteregistrierung durchzuführen und informiert sind, welche Art von personenbezogenen Daten vom Vertreter im Rahmen der Vertreterberechtigung im ePA-Aktensystem verarbeitet werden, wie der Vertreter eine Vertreterberechtigung widerrufen kann und gegenüber wem er seine datenschutzrechtlichen Betroffenenrechte wahrnehmen kann. [<=]

Hinweis zu A_21548-01: Für die Benachrichtigung derjenigen Vertreter, die dem importierenden Aktensystem nicht bekannt sind, werden die E-Mail-Adressen aus dem Exportpaket genommen. Für die Benachrichtigung der Vertreter, die dem importierenden Aktensystem bekannt sind, wird die im importierenden Aktensystem hinterlegte E-Mail-Adresse des Vertreters verwendet.

A_26257 - Health Record Relocation Service - Löschen der im Exportpaket enthaltenen E-Mail-Adressen der Vertreter

Der Health Record Relocation Service MUSS sicherstellen, dass die im Exportpaket enthaltenen E-Mail-Adressen von Vertretern ausschließlich zur Information der Vertreter gemäß A_21548-* genutzt werden und nach Abschluss des Anbieterwechsels im importierenden Aktensystem gelöscht werden, d.h. nicht im importierenden Aktensystem gespeichert werden. [<=]

A_24788 - Health Record Relocation Service - Löschen des Exportpakets nach Umzug des Aktenkontos

Das Aktensystem MUSS sicherstellen, dass ein vorhandenes Exportpaket nach einem erfolgreichen Transfer eines Aktenkontos eines Versicherten von einem Anbieter zu einem anderen Anbieter gelöscht wird. [<=]

A_24982 - Health Record Relocation Service – Protokollierung des Anbieterwechsels eines Aktenkontos

Der Health Record Relocation Service des neuen (importierenden) Aktensystems MUSS nach der erfolgreichen oder einer abgebrochenen Übertragung der Inhalte eines Aktenkontos vom bisherigen Anbieter einen Protokolleintrag gemäß A_24704* erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 6 : Health Record Relocation Service Protokollierung

 Strukturelement
Wert
Erläuterung
AuditEvent.type "object"
AuditEvent.action
E
Übertrag von Daten eines Aktenkontos von einem anderen Anbieter
AuditEvent.entity.name
"HealthRecordRelocation"

AuditEvent.entity.detail
type
value[x]
 
 
"OriginName"
<Name des Kostenträgers>
Name des Kostenträgers, von welchem ein bestehendes Aktenkonto übernommen wird
[<=]

Hinweis: Statuswechsel des Aktenkontos im Kontext eines Wechsels des Anbieters erzeugen Protokolleinträge gemäß A_24980*.

Hinweis: Das Aktensystem des bisherigen Anbieters muss keinen Protokolleintrag gemäß A_24982* erzeugen.

3.2.1 Ablauf eines Aktenkontoumzugs

3.2.1.1 Initialisierung des Aktenkontos bei einem neuen Anbieter

Der Anbieter (neu) lässt im Aktensystem (neu) ein neues Aktenkonto anlegen. Dieses erhält den Status INITIALIZED. Hierfür gelten die Anforderungen gemäß 3.1.3 Anlage eines neuen Aktenkontos.

Falls der Versicherte schon einen Widerspruch gegen die Nutzung der ePA bei seinem bisherigen Kostenträger erklärt hat, kann die Initialisierung eines neuen Aktenkontos ggf. entfallen, Ein Transfer, bzw. die Erstellung eines Exportpakets, ist in diesem Fall mangels eines existierenden Aktenkontos beim bisherigen Anbieter nicht erforderlich.

Die Abfrage eines existierenden Widerspruchs des Versicherten bei einem anderen Anbieter ePA-Aktensystem erfolgt über dessen Information Service.

Abfrage eines existierenden Widerspruchs gegen die Nutzung der ePA
I_Information_Service_Accounts (bisheriges Aktensystem)
getGeneralConsentDecision Abfrage des ggf. schon erteilten Widerspruchs gegen die Nutzung der ePA durch den Versicherten
3.2.1.2 Abfrage existierendes Aktenkonto und Anfrage zum Transfer

Das Aktensystem (neu) fragt im Rahmen der Initialisierung des neuen Aktenkontos alle Aktensysteme der weiteren Betreiber an, ob bei diesen ein Aktenkonto für den Versicherten (KVNR) existiert. Das Aktensystem (alt), bei welchem das Aktenkonto existiert, bestätigt diese Anfrage zum Transfer mit einer Vorgangs-ID.

Starten des Transfers
I_Information_Service_Accounts (bisheriges Aktensystem)
startRelocation initiieren der Exportpaketerstellung

Existiert bei keinem Anbieter (alt) ein Aktenkonto des Versicherten, ist eine Datenübernahme nicht erforderlich und das Aktenkonto (neu) kann in den Status ACTIVATED überführt und der Transferprozess abgeschlossen werden.

3.2.1.3 Erzeugung Exportpaket für Transfer durch den bisherigen Anbieter

Das Aktensystem (alt) informiert den Anbieter (alt) über die Anfrage zum Transfer und die Vorgangsnummer. Der Anbieter (alt) öffnet das existierende Aktenkonto des Versicherten und stößt in der VAU die Erzeugung des Exportpakets an. Der Health Record Relocation Service beantwortet diese Anfrage durch Rückgabe einer URL für den späteren Download des Exportpakets durch den neuen Anbieter und startet die Erzeugung des Exportpakets. Das Aktenkonto wird vor der Paketerstellung auf den Status SUSPENDED gesetzt, um weitere Aktivitäten seitens der Nutzer zu verhindern.

Erzeugen des Exportpakets
I_Health_Record_Relocation_Service_ (bisheriger Anbieter)
startPackageCreation Starten der Erzeugung des Exportpakets in der VAU

In dieses Exportpaket werden alle Daten des Aktenkontos gemäß A_25005*übernommen. Das fertige Exportpaket wird mittels ENC-Zertifikat, welches im VAU-HSM eingebracht und gespeichert wurde, verschlüsselt und am vorbereiteten Downloadpunkt bereitgestellt.

3.2.1.4 Übermittlung Download-URL Exportpaket für Transfer an den neuen Anbieter

Der Anbieter (alt) veranlasst nach Erhalt der Download-URL über das Aktensystem (alt) den Versand der Url an das Aktensystem (neu).

Das Aktensystem (alt) prüft vor der Übermittlung der Download-URL an das Aktensystem (neu), ob das Exportpaket für den Download bereitsteht, ggf. wird auf den Abschluss der Paketerstellung gewartet. Ist dieses der Fall, erfolgt die Benachrichtigung des Information_Service des Aktensystem (neu) mit der Übergabe der URL

Übergabe der Download-URL für das Exportpaket
I_Information_Service_Accounts (neues Aktensystem)
putDownloadUrlForExportPackage Übergabe der geprüften Download-URL
3.2.1.5 Import des Exportpakets durch den neuen Anbieter

Der Information Service des Aktensystems (neu) nimmt die Download-URL entgegen und übermittelt diese an den Kostenträger (neu). Dieser öffnet den Zugang zum Aktenkonto (neu) des Versicherten und veranlasst in der VAU den Import des Exportpakets.

Import und Integration des Exportpakets
I_Health_Record_Relocation_Service (neuer Anbieter)
startPackageImport Starten des Imports der vorhandenen Daten
3.2.1.6 Abschluss des Transfers durch beide Anbieter

Das Aktensystem (neu) startet den Download des Exportpakets, entschlüsselt dieses und übernimmt die Daten in das initialisierte Aktenkonto des Versicherten. Nach erfolgreichem Abschluss wird (kann) das Aktenkonto (neu) in den Status ACTIVATED überführt werden.

Unter Verwendung des Information Service wird das Aktensystem (alt) über den erfolgreichen Import und den Abschluss des Transfers informiert. Das Aktenkonto (alt) kann daraufhin, ggf. unter Einhaltung weiterer Bedingungen des Kostenträgers bzw. gesetzlicher Vorgaben, gelöscht werden (Status = UNKNOWN).

Abschluss des Transfers
I_Information_Service_Accounts (bisheriges Aktensystem)
deleteExportPackage Beenden des Vorgangs (Löschen Exportpaket und ggf. bisheriges Aktenkonto)
3.2.1.7 Fehlersituationen und Handhabung

Der gesamte Austausch von Informationen zwischen Aktensystemen und Anbietern kann durch die in  erzeugte Vorgangs-ID genau einem konkreten Relocation Vorgang zugeordnet werden. Diese Vorgangsnummer wird auch verwendet, wenn das jeweils andere Aktensystem über Fehler im Ablauf benachrichtigt werden muss (Incidents).

3.2.1.7.1 Abruf des Exportpakets durch neuen Anbieter nicht mehr erforderlich oder derzeit nicht möglich

Kann ein Anbieter (neu) nach dem Start der Exportpaketerzeugung durch den Anbieter (alt) das Exportpaket voraussehbar nicht importieren oder widerspricht der Versicherte nach der Initialisierung des Aktenkontos beim neuen Kostenträger der Nutzung der ePA, so kann durch Übertragung eines Incidents an das Aktensystem (alt) dieser Sachverhalt mitgeteilt werden, so dass der Transfervorgang abgebrochen und das Exportpaket nicht erzeugt oder wieder gelöscht wird.

Incident Abbruch des Transfers
I_Information_Service_Accounts (bisheriger Anbieter)
postExportPackageIncident Benachrichtigung zum Abbruch des Transfers
Incident
relocationAborted
Abbruch aus Gründen bei Anbieter (neu). Transfer wird zu gegebener Zeit erneut gestartet

Das Aktenkonto wird bei Anbieter (alt) wieder in den Status ACTIVATED gesetzt, um eine weitere Nutzung zu ermöglichen.

Für einen Transfer zu einem späteren Zeitpunkt muss der Anbieter (neu) den Vorgang durch Anfrage bei den weiteren Anbietern (alt) und Übermittlung eines ENC-Zertifikats erneut starten.

3.2.1.7.2 Fehler beim Download oder Import durch den neuen Anbieter

Kann ein Anbieter (neu) nach dem Start der Exportpaketerzeugung durch den Anbieter (alt) das Exportpaket unter Verwendung der übertragenen Download-URL nicht oder nicht vollständig laden oder die Inhalte des Exportpaketes aufgrund fehlerhafter Verschlüsselung oder fehlerhafter Struktur oder Inhalte nicht erfolgreich integrieren oder der Anbieter (neu) hat keine Download-URL vom Anbieter (alt) bezogen, so kann durch Übertragung eines Incidents an den Anbieter (alt) dieser Sachverhalt mitgeteilt werden.

Incident Fehler bei Import
I_Information_Service_Accounts (bisheriges Aktensystem)
postExportPackageIncident Benachrichtigung zu Problemen beim Import des Exportpakets
Incident
importFailed

Exportpaket kann nicht vom Downloadpunkt geladen werden, ist unvollständig oder falsch verschlüsselt
packageCorrupt

Exportpaket kann nicht verarbeitet werden (strukturelle Fehler oder inhaltliche Fehler)
urlNotReceived
Download-URL nicht erhalten

 Das Aktenkonto verbleibt beim neuen Anbieter in Status INITIALIZED. Die Incidentmeldung an den Anbieter (alt) kann durch Kommunikation der Anbieter und/oder Betreiber untereinander zum Zweck der Problemlösung ergänzt werden.

Der Anbieter (alt) meldet die Korrektur durch erneuten Versand einer Download-URL an den Anbieter (neu) für den unterbrochenen Vorgang.

Es obliegt dem Anbieter (alt), bei zeitlich aufwendigen Korrekturen das Aktenkonto zunächst für eine weitere Nutzung wieder zu aktivieren (Status ACTIVATED) und nach Abschluss der Korrektur wieder in den Status SUSPENDED zu überführen. 

Es obliegt dem Anbieter (alt) auch, bei zeitlich aufwendigen Korrekturen den Transfer durch Senden des Incidents "relocationAborted" an den Anbieter (neu) abzubrechen und das Aktenkonto zur weiteren Nutzung wieder zu aktivieren (Status ACTIVATED). Der Transfer muss dann durch den Anbieter (neu) erneut gestartet werden.

3.2.1.7.3 Nicht erfolgter Download oder fehlende Rückmeldung durch den neuen Anbieter

Ruft ein neuer Anbieter ein bereitgestelltes Exportpaket nicht ab oder erfolgt durch den neuen Anbieter keine Benachrichtigung über einen erfolgreichen Abschluss des Transfers oder einen Fehler beim Import des Exportpakets,  dann kann eine Benachrichtigung an den neuen Anbieter erfolgen.

Incident Abbruch des Transfers durch bisherigen Anbieter
I_Information_Service_Accounts (neuer Anbieter)
postPackageDeliveryIncident  Benachrichtigung zum Abbruch des Transfers
Incident
noRelocationConfirmation

Nach Ablauf der Bereitstellungszeit gemäß A-15703-* wird der Transfer durch den Anbieter (alt) abgebrochen, da keine Bestätigung eines erfolgreichen Imports erfolgte.

Der Transfer wird durch den Anbieter (alt) abgebrochen. Das Aktenkonto wird bei Anbieter (alt) auf den Status ACTIVATED gesetzt, um eine weitere Nutzung zu ermöglichen. Exportpaket und Downloadlink können gelöscht werden. Der Transfer muss durch den Anbieter (neu) erneut gestartet werden.

3.2.1.7.4 Abbruch des Transfers durch den bisherigen Anbieter

Ein Anbieter (alt) kann den Abbruch eines angeforderten Transfers an den Anbieter (neu) signalisieren.

Incident Abbruch des Transfers durch bisherigen Anbieter
I_Information_Service_Accounts (neuer Anbieter)
postPackageDeliveryIncident  Benachrichtigung zum Abbruch des Transfers
Incident
relocationAborted

Das Exportpaket kann aufgrund von Ursachen seitens Anbieter (alt) nicht (länger) bereitgestellt werden. Der Transfer wird vorzeitig abgebrochen und muss erneut gestartet werden. 

Der Transfer wird durch den Anbieter (alt) abgebrochen. Das Aktenkonto wird bei Anbieter (alt) auf den Status ACTIVATED zurückgesetzt, wenn dieses schon den Status SUSPENDED hat, um eine weitere Nutzung zu ermöglichen. Exportpaket und Downloadlink können gelöscht werden. Der Transfer muss durch den Anbieter (neu) erneut gestartet werden.

3.3 Sichere Speicherung sensibler Schlüssel und Informationen im VAU-HSM

Im Folgenden wird beschrieben, welche Informationen in einem HSM (als VAU-HSM bezeichnet) zu speichern sind.

Verständnishinweis: Die HMAC-Schlüssel (symmetrische Schlüssel) für die Prüfung der VSDM+-Prüfnachweise [gemSpec_SST_FD_VSDM], [C_11321] werden von den VSDM-Betreibern erzeugt und für die ePA-VAUs der ePA-Betreiber verschlüsselt exportiert. Die Schlüssel und auch die Export/Import-Vorgänge (Mehr-Augen-Prinzip) sind die gleichen wie sie auch für/bei der E-Rezept-VAU verwendet werden.

A_24611-02 - ePA-Aktensystem - Im VAU-HSM gespeicherte Schlüssel und Informationen für VAU-Betrieb

Das ePA-Aktensystem MUSS sicherstellen, dass folgende, für den Betrieb der VAU notwendigen Schlüssel und Informationen in einem HSM (als VAU-HSM bezeichnet) gespeichert werden:

  • privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU (u.a. genutzt für die Authentisierung der VAU beim Aufbau des VAU-Kanals)
  • ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
  • ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
  • privater Schlüssel der Verschlüsselungsidentität der VAU
  • privater Schlüssel der Signaturidentität der VAU
  • Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
  • Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel
  • Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel
  • Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung")
  • symmetrische Schlüssel für die HMAC-Prüfung der VSDM-Prüfziffern (jeweils einen pro VSD-Dienst-Betreiber)
  • symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
  • Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  • Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).
[<=]

A_26109 - ePA-Aktensystem - Unterschiedliche private Authentisierungsschlüssel für AK-, Befugnisverifikations- und Service-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass für die Authentisierungsidentitäten für Aktenkontoverwaltungs-VAUs, Befugnisverifikations-VAUs und Service-VAUs unterschiedliche private Schlüssel verwendet werden. [<=]

A_26110 - ePA-Aktensystem - Unterschiedliche private Authentisierungsschlüssel für unterschiedliche Service-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass für unterschiedliche Typen von Service-VAUs unterschiedliche private Schlüssel für die Authentisierung genutzt werden. [<=]

Hinweis zu A_26110: Ein Typ einer Service-VAU könnte beispielsweise eine PDF-Konvertierungs-Service-VAU oder eine Pseudonymisierungs-Service-VAU für Daten zur Sekundärnutzung sein. Alle Instanzen einer PDF-Konvertierungs-Service-VAU nutzen denselben privaten Authentisierungsschlüssel. Die Instanzen der Pseudonymisierungs-Service-VAU dürfen den  Authentisierungsschlüssel der PDF-Konvertierungs-Service-VAU jedoch nicht verwenden.

A_24612-03 - ePA-Aktensystem - Erzwingen von 4-Augen-Prinzip für Einbringen und Verwalten von Informationen ins VAU-HSM

Das ePA-Aktensystem MUSS technisch erzwingen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip in das VAU-HSM eingebracht und verwaltet werden können:

  • privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
  • ggf. privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
  • ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
  • privater Schlüssel der Verschlüsselungsidentität der VAU
  • privater Schlüssel der Signaturidentität der VAU
  • Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
  • symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
  • symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
  • Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  • Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).
[<=]

A_24614-02 - ePA-Aktensystem - Einbringung von Informationen ins VAU-HSM im 4-Augen-Prinzip mit der gematik

Der Betreiber des ePA-Aktensystems MUSS sicherstellen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip ins VAU-HSM eingebracht und im VAU-HSM verwaltet werden, bei dem eine von der gematik benannte Person beteiligt ist:

  • privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
  • ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
  • ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
  • privater Schlüssel der Verschlüsselungsidentität der VAU
  • privater Schlüssel der Signaturidentität der VAU
  • Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
  • symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
  • symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
  • Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  • Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).
[<=]

Beim Einbringen der Hashwertrepräsentation der erlaubten VAU-Software ins VAU-HSM prüft die von der gematik benannte Person, dass die Hashwertrepräsentation des VAU-Images zuvor vom Hersteller des ePA-Aktensystems an die gematik übermittelt wurde und zulässig für den Produktivbetrieb ist.

A_24618-02 - ePA-Aktensystem - Zugriff auf Schlüssel und Informationen im VAU-HSM

Das ePA-Aktensystem MUSS sicherstellen, dass auf die folgenden, für den Betrieb der VAU notwendigen und im VAU-HSM gespeicherten Schlüssel und Informationen ausschließlich über attestierte VAU-Instanzen zugegriffen werden kann:

  • privater Schlüssel der Authentisierungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU ausschließlich durch eine Befugnisverifikations-VAU-Instanz
  • privater Schlüssel der Authentisierungsidentität eines Service-VAU-Typs ausschließlich durch eine Service-VAU-Instanz dieses Service-VAU-Typs
  • privater Schlüssel der Verschlüsselungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • privater Schlüssel der Signaturidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentiät des anderen ePA-Aktensystembetreibers ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  • Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung") ausschließlich durch die Aktenkontoverwaltungs-VAU-Instanz oder durch eine dedizierte Überschlüsselungs-VAU
  • symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz
  • symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz.
[<=]

3.4 Befugnisverifikations-Modul

Das Befugnisverifikations-Modul enthält die Regeln zur Befugnisregistrierung (entitlement registration rules) und die Regeln zum Abruf der versichertenindividuellen Persistierungsschlüssel (key rules).

Die folgende Abbildung zeigt die zwei möglichen Architekturvarianten für die Ausführung des Befugnisverifikations-Moduls. In Variante 1 wird es direkt im VAU-HSM ausgeführt. In Variante 2 wird es in einer Befugnisverifikations-VAU ausgeführt, die zwischen einer Aktenkontoverwaltungs-VAU und einem VAU-HSM vermittelt und Prüfungen für das VAU-HSM übernimmt (z. B. prüfen der ID-Token oder registrieren neuer Befugnisse).

In beiden Varianten ist ein Zugriff auf die Schlüssel im VAU-HSM nur durch integre und attestierte VAUs möglich. Die Prüfung der VAU-Attestierungstoken verbleibt in beiden Varianten im VAU-HSM (VAU-Token-Modul). Das VAU-HSM speichert in Variante 2 neben den Hashwertrepräsentationen der erlaubten VAU-Software und erlaubten VAU-Hardware für die VAU der Aktenkontoverwaltung zusätzlich auch die Hashwertrepräsentationen der erlaubten VAU-Software und erlaubten VAU-Hardware für die VAU der Befugnisverifikations-VAU. Ein Zugriff auf das HSM ist dann nur mit einem validen Attestierungstoken für die Aktenkontoverwaltung-VAU und die Befugnisverifikations-VAU möglich.

Abbildung 1: Alternativen zur Ausführung des Befugnisverifikations-Moduls

A_25281 - ePA-Aktensystem - VAU-Token-Modul ausschließlich im HSM

Das ePA-Aktensystem MUSS sicherstellen, dass ein VAU-Token-Modul ausschließlich in einem VAU-HSM ausgeführt wird. [<=]

A_24574 - ePA-Aktensystem - Befugnisverifikations-Modul im HSM oder Befugnisverifikations-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass ein Befugnisverifikations-Modul ausschließlich in einem VAU-HSM oder in einer Befugnisverifikations-VAU ausgeführt wird. [<=]

A_25050 - ePA-Aktensystem - 1:1-Beziehung zwischen Befugnisverifikations-VAU und Aktenkontoverwaltungs-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass eine 1:1-Beziehung zwischen einer Instanz einer Befugnisverifikations-VAU und einer Instanz einer Aktenkontoverwaltungs-VAU gibt. [<=]

3.4.1 VAU-Token-Modul

Dieser Abschnitt enthält die Regeln zum Zugriff auf die Schlüssel im VAU-HSM. Diese werden von einem Befugnisverifikations-Modul genutzt.

A_24712-01 - ePA-Aktensystem - VAU-Token-Modul nur durch Befugnisverifikations-Modul oder Aktenkontoverwaltungs-VAU aufrufbar

Das ePA-Aktensystem MUSS sicherstellen, dass die Regeln hsm-r1 bis hsm-r3 des VAU-Token-Moduls ausschließlich von einem Befugnisverifikations-Modul und die Regeln hsm-r4 bis hsm-r7 ausschließlich von einer Aktenkontoverwaltungs-VAU aufgerufen werden. [<=]

A_25282-01 - ePA-Aktensystem - Regeln des VAU-Token-Moduls

Das VAU-Token-Modul MUSS die in Tabelle Tab_AS_VAU_Token_Modul_Rules definierten Regeln umsetzen. [<=]

Tabelle 7: Tab_AS_VAU_Token_Modul_Rules -Prüfregeln VAU Token

Regel Beschreibung
hsm-r1 Diese Regel dient zur Sicherung von Befugnissen und HSM-ID-Token mittels CMAC.
Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • VAU-Attestierungstoken einer Befugnisverifikations-VAU (optional)
  • Daten
Ausgangsdaten:
  • Daten gesichert mittels CMAC
Prüfschritte:
  1. prüfen der Signatur(en) des(r) VAU-Attestierungstoken (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
  3. ggf. prüfen, ob die im VAU-Attestierungstoken für die Befugnisverifikations-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
Falls die Prüfungen 1) - 3) erfolgreich waren, werden die übergebenen Daten mittels CMAC gesichert.
hsm-r2 Diese Regel dient zur Ableitung der versichertenindividuellen Persistierungsschlüssel

Eingangsdaten
:
  • KVNR
  • gewünschte Persistierungsschlüssel [Label für Datenpersistierungs-Masterkey und/oder Label für Befugnispersistierungs-Masterkey]
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • VAU-Attestierungstoken einer Befugnisverifikations-VAU (opt.)
Ausgangsdaten:
  • falls in Eingangsdaten angefordert: versichertenindividueller Befugnispersistierungsschlüssel
  • falls in Eingangsdaten angefordert: versichertenindividueller Datenpersistierungsschlüssel
Prüfschritte:
  1. prüfen der Signatur(en) des(r) VAU-Attestierungstoken (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
  3. ggf. prüfen, ob die im VAU-Attestierungstoken für die Befugnisverifikations-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
Falls die Prüfungen 1) - 3) erfolgreich waren, wird der angeforderte versichertenindividuelle Befugnispersistierungsschlüssel und/oder versichertenindividuelle Datenpersistierungsschlüssel für die übergebene KVNR von den durch die Label identifizierten Masterkeys abgeleitet.
hsm-r3 Diese Regel dient zur Nutzung des HMAC bzgl. VSDM-Prüfziffern
Eingangsdaten
:
  • Daten
  • Bezeichner des HMAC-Schlüssels
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • VAU-Attestierungstoken einer Befugnisverifikations-VAU (opt.)
Ausgangsdaten:
  • HMAC der Daten mit dem symmetrischen Schlüssel, der zum übergebenen Bezeichner des HMAC-Schlüssels gehört
Prüfschritte:
  1. prüfen der Signatur(en) des(r) VAU-Attestierungstoken (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
  3. (opt.) prüfen, ob die im VAU-Attestierungstoken für die Befugnisverifikations-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
Falls die Prüfungen 1) - 3) erfolgreich waren, wird der HMAC mit dem gewünschten HMAC-Schlüssel über die Daten gebildet.
hsm-r4 Diese Regel dient zur Nutzung der privaten Schlüssel der AUT-Identitäten der VAU
Eingangsdaten
:
  • Challenge
  • [VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU|
    VAU-Attestierungstoken einer Befugnisverifikations-VAU|
    VAU-Attestierungstoken eines Service-VAU-Typs]
Ausgangsdaten:
  • Challenge signiert mit privatem Schlüssel der AUT-Identität
    • der Aktenkontoverwaltungs-VAU, falls in den Eingangsdaten ein VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU übergeben wurde,
    • der Befugnisverifikations-VAU, falls in den Eingangsdaten ein VAU-Attestierungstoken einer Befugnisverifikations-VAU übergeben wurde,
    • des Service-VAU-Typs, falls in den Eingangsdaten ein VAU-Attestierungstoken des Service-VAU-Typs übergeben wurde.
Prüfschritte
  1. prüfen der Signatur des VAU-Attestierungstokens (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind und zum VAU-Typ passt.
Falls die Prüfungen in 1) bis 2) erfolgreich waren, wird die übergebene Challenge mit dem privatem Schlüssel der zum VAU-Attestierungstoken gehörenden AUT-Identität signiert.
hsm-r5 Diese Regel dient zur Nutzung des privaten Schlüssels der ENC-Identität der VAU
Eingangsdaten
:
  • verschlüsselte Daten
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
Ausgangsdaten:
  • entschlüsselte Daten
Prüfschritte
  1. prüfen der Signatur des VAU-Attestierungstokens (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind.
Falls die Prüfungen in 1) bis 2) erfolgreich waren, werden die übergebenen verschlüsselten Daten mit dem privatem Schlüssel der ENC-Identität der VAU entschlüsselt.
hsm-r6 Diese Regel dient zur Nutzung des privaten Schlüssels der Signaturidentität der VAU
Eingangsdaten
:
  • zu signierende Daten
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
Ausgangsdaten:
  • signierte Daten
Prüfschritte
  1. prüfen der Signatur des VAU-Attestierungstokens (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
Falls die Prüfungen in 1) bis 2) erfolgreich waren, werden die übergebenen Daten mit dem privatem Schlüssel der Signaturidentität der VAU signiert.
hsm-r7 Diese Regel dient zum Auslesen des ENC-Zertifikats des anderen Aktensystembetreibers.
Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
Ausgangsdaten:
  • Verschlüsselungszertifikat C.FD.ENC des anderen Aktensystembetreibers
Prüfschritte:
  1. prüfen der Signatur des VAU-Attestierungstokens (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken für die Aktenkontoverwaltungs-VAU attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind
Falls die Prüfungen 1) - 2) erfolgreich waren, wird das ENC-Zertifikat des anderen Aktensystembetreibers zurückgeliefert.
hsm-r8 Diese Regel dient zum Ableiten von symmetrischen Schlüsseln für die Ver- bzw. Entschlüsselung von Daten

Sie dient bspw. dazu, sogenannte Submissions für die  Datenausleitung an das Forschungsdatenzentrum Gesundheit (FDZ) nach § 363 Absatz 1 SGB V außerhalb der VAU im Aktensystem zwischenzuspeichern, bis das Forschungsdatenzentrum diese Submissions abholt. Die Submissions sind dann über die über diese Regel abgeleiteten symmetrischen Schlüssel außerhalb der VAU kryptographisch gesichert.

Eingangsdaten:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU oder einer Service-VAU
  • Ableitungsvektor dv
  • Label für Masterkey (opt.)
Ausgangsdaten:
  • symmetrischer Schlüssel symKey
  • Label für Befugnis-Masterkey
Prüfschritte:
  1. prüfen der Signatur des VAU-Attestierungstokens (herstellerspezifisch)
  2. prüfen, ob die im VAU-Attestierungstoken attestierte VAU-Software und VAU-Hardware dem HSM bekannt sind und es sich um die Attestierung einer Aktenkontoverwaltungs-VAU oder Service-VAU handelt
  3. falls ein Label für einen Masterkey In den Eingangsdaten enthalten ist, prüfen, ob das Label zu einem Befugnis-Masterkey gehört
Falls alle Prüfungen erfolgreich waren, wird symKey wie folgt abgeleitet:

Fall: Eingangsdaten enthalten ein Label mkey_label für einen Befugnis-Masterkey:
Ableitung eines AES-Schlüssels [FIPS-197] symKey mit 256 Bit Schlüssellänge nach einem in [gemSpec_Krypt#2.4] zulässigen Verfahren auf Basis des Befugnis-Masterkeys mit Label mkey_label und dem Ableitungsvektor "eds: "+ dv. Ausgangsdaten sind der abgeleitete Schlüssel symKey und das Label mkey_label.

(Verständnishinweis: eds steht für "External Data Storage". Das HSM erzwingt bei dieser Regeln, dass das Präfix "eds: " (also 5 Byte) dem vom Aufrufer übergebenen Ableitungsvektor (dv) vorangestellt wird.)

Fall: Eingangsdaten enthalten kein Label für einen Befugnis-Masterkey:
Abbleitung eines AES-Schlüssels [FIPS-197] symKey mit 256 Bit Schlüssellänge nach einem in [gemSpec_Krypt#Abschnitt 2.4] zulässigen Verfahren auf Basis des aktuellen Befugnis-Masterkeys und dem Ableitungsvektor "eds: " + dv. Ausgangsdaten sind der abgeleitete Schlüssel symKey und das Label des aktuellen Befugnis-Masterkeys. 

A_24667 - ePA-Aktensystem -VAU-HSM - Prüfen des VAU-Attestierungstokens

Das VAU-HSM MUSS bei der Prüfung eines VAU-Attestierungstokens sicherstellen, dass dieses zeitlich gültig ist und Replay-Attacken abwehren. [<=]

A_26303 - ePA-Aktensystem - Abgeleitete Verschlüsslungsschlüssel sind ausschließlich einer VAU zugänglich

Das ePA-Aktensystem MUSS sicherstellen, dass ein mit Regel hsm-r8 abgeleiteter Schlüssel ausschließlich einer VAU zugänglich ist und ausschließlich mittels AES/GCM analog [gemSpec_Krypt#GS-A_4389] verwendet wird. [<=]

3.4.2 Regeln des Befugnisverifikations-Moduls

Die folgende Tabelle zeigt die Regeln des Befugnisverifikations-Moduls im Überblick.

Tabelle 8: Überblick über die Regeln des Befugnisverifikations-Moduls

Regel Kurzbeschreibung
Vollständige Regelspezifikation in
rr0 Mit dieser Regel werden ID-Token im Aktensystem registriert und zu einem HSM-ID-Token konvertiert. Tab_AS_Entitlement_Registration_Rules
rr1 Mit dieser Regel werden vom Aktenkontoinhaber am ePA-FdV erstellte Befugnisse im Aktensystem registriert. Die im ePA-FdV erstellten Befugnisse sind vom Versicherten mittels Signaturdienst signiert. Tab_AS_Entitlement_Registration_Rules
rr2 Mit dieser Regel werden vom Vertreter am ePA-FdV erstellte Befugnisse für das Aktenkonto des Versicherten im Aktensystem registriert. Die im ePA-FdV erstellen Befugnisse sind vom Vertreter mittels Signaturdienst signiert. Tab_AS_Entitlement_Registration_Rules
rr3 Mit dieser Regel werden Befugnisse im Aktensystem registriert, die sich durch das Stecken der eGK in einer Leistungserbringerumgebung ergeben. Tab_AS_Entitlement_Registration_Rules
rr4 Mit dieser Regel werden die Befugnisse für den Kostenträger und die zuständige Ombudsstelle bei der Anlage eines Aktenkontos im Aktensystem registriert. Tab_AS_Entitlement_Registration_Rules
rr5 Mit dieser Regel werden die Befugnisse bei einem betreiberübergreifenden Anbieterwechsel im Aktensystem registriert. Tab_AS_Entitlement_Registration_Rules
kr1 Diese Regel wird für die Anmeldung des Aktenkontoinhabers genutzt. Tab_AS_SDS-Key_Rules
kr2 Diese Regel wird für den Abruf des versichertenindividuellen Befugnispersistierungsschlüssels genutzt. Sie wird für die Anmeldung von Nutzern verwendet, für die eine Befugnis im Aktensystem registriert wurde. Tab_AS_SDS-Key_Rules
kr3 Diese Regel wird für den Abruf des versichertenindividuellen Datenpersistierungsschlüssels genutzt. Sie wird für die Anmeldung von Nutzern verwendet, für die eine Befugnis im Aktensystem registriert wurde. Tab_AS_SDS-Key_Rules
kr4 Diese Regel wird für die Anmeldung des E-Rezept-Fachdienstes verwendet. Tab_AS_SDS-Key_Rules
kr5 Diese Regel wird für die Überschlüsselung (ggf. mit Umschlüsselung einer Überschlüsselung) verwendet. Tab_AS_SDS-Key_Rules

A_24573-02 - ePA-Aktensystem - Regeln des Befugnisverifikations-Moduls

Das Befugnisverifikations-Modul  MUSS die in den Tabellen Tab_AS_Entitlement_Registration_Rules und Tab_AS_SDS-Key_Rules definierten Regeln umsetzen. [<=]

Tabelle 9: Tab_AS_Entitlement_Registration_Rules - Regeln zur Registrierung von Befugnissen

Regel Beschreibung
rr0 Mit dieser Regel werden ID-Token im Aktensystem registriert und zu einem HSM-ID-Token konvertiert.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token mit NutzerID=x signiert durch einen sektoralen Identity Provider, den IDP-Dienst oder den E-Rezept-Fachdienst
Ausgangsdaten:
  • HSM-ID-Token mit NutzerID=x gesichert mittels CMAC
Prüfschritte:
  1. prüfen des ID-Tokens gemäß A_24690-* (C.FD.SIG) bei Token eines IDPs bzw. gemäß A_24658-* bei Token des E-Rezept-Fachdiensts (C.FD.AUT).
  2. Falls die Prüfung in 1) erfolgreich war,
    1. erstellt das Befugnisverifikations-Modul ein HSM-ID-Token mit der NutzerID=x, einer Gültigkeitsdauer von 24 Stunden und der professionOID aus dem Signaturzertifikat (oid_idpd_sek,  oid_idpd oder oid_erp-vau).
    2. ruft das Befugnisverifikations-Modul die VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und dem HSM-ID-Token auf.
      1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  3. Das Befugnisverifikations-Modul liefert das mittels CMAC gesicherte HSM-ID-Token als Ergebnis des Regelaufrufs zurück.
rr1 Mit dieser Regel werden vom Aktenkontoinhaber am ePA-FdV erstellte Befugnisse im Aktensystem registriert. Die im ePA-FdV erstellten Befugnisse sind vom Versicherten mittels Signaturdienst signiert.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token oder HSM-ID-Token gesichert mit CMAC
  • Befugnis1 = (KVNR Aktenkonto, Telematik-ID oder KVNR, Gültigkeitszeitraum) signiert vom Versicherten
Ausgangsdaten:
  • Befugnis2 = (KVNR Aktenkonto, Telematik-ID oder KVNR, Gültigkeitszeitraum) gesichert mittels CMAC
Prüfschritte:
  1. prüfen des ID-Tokens gemäß A_24690-* (Zertifikatsprofil C.FD.SIG)
    1. prüfen, ob die professionOID im Signaturzertifikat oid_idpd_sek ist
    2. prüfen, ob die KVNR im ID-Token mit der KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 übereinstimmt
oder prüfen des HSM-ID-Tokens
  1. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und HSM-ID-Token und Vergleich des Rückgabewerts mit dem CMAC des übergebenen HSM-ID-Tokens
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. prüfen, ob die professionOID im HSM-ID-Token oid_idpd_sek ist
  3. prüfen, ob die KVNR im HSM-ID-Token mit der KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 übereinstimmt.
  1. prüfen der Befugnis1
    1. prüfen der Signatur gemäß A_25042-* (Zertifikatsprofil C.CH.SIG)
    2. prüfen, ob die professionOID im Signaturzertifikat oid_versicherter ist
    3. prüfen, ob die KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 mit der "KVNR Aktenkonto" in der Befugnis1 übereinstimmt.
    4. prüfen, dass das JWT gemäß A_24587-* nicht abgelaufen ist (Feld: exp)
  2. Falls die Prüfungen in 1) bis 2) erfolgreich waren, erstellt das Befugnisverifikations-Modul die Befugnis2. Die Inhalte werden aus Befugnis1 übernommen mit folgender Ausnahme:
    Für eine Befugnis1 mit oid = oid_ncpeh wird die Gültigkeit validTo in Befugnis2 auf aktuelle Zeit + 1 Stunde gesetzt.
  3. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und Befugnis2
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  4. Das Befugnisverifikations-Modul liefert die mittels CMAC gesicherte Befugnis2 als Ergebnis des Regelaufrufs zurück.
rr2 Mit dieser Regel werden vom Vertreter am ePA-FdV erstellte Befugnisse für das Aktenkonto des Versicherten im Aktensystem registriert. Die im ePA-FdV erstellten Befugnisse sind vom Vertreter mittels Signaturdienst signiert.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token oder HSM-ID-Token gesichert mit CMAC
  • Befugnis1 = (KVNR Aktenkonto, Telematik-ID, Gültigkeitszeitraum) signiert vom Vertreter
  • Befugnis2 = (KVNR Aktenkonto, KVNR Vertreter) gesichert mittels CMAC
Ausgangsdaten:
  • Befugnis3 = (KVNR Aktenkonto, Telematik-ID, Gültigkeitszeitraum) gesichert mittels CMAC
Prüfschritte:
  1. prüfen des ID-Tokens gemäß A_24690-* (Zertifikatsprofil C.FD.SIG)
    1. prüfen, ob die professionOID im Signaturzertifikat oid_idpd_sek ist
    2. prüfen, ob die KVNR im ID-Token mit der KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 übereinstimmt
oder prüfen des HSM-ID-Tokens
    1. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und HSM-ID-Token und Vergleich des Rückgabewerts mit dem CMAC des übergebenen HSM-ID-Tokens
      1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
    2. prüfen, ob die professionOID im HSM-ID-Token oid_idpd_sek ist
    3. prüfen, ob die KVNR im HSM-ID-Token mit der KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 übereinstimmt.
  1. prüfen der Befugnis1 und Befugnis2
    1. prüfen der Signatur von Befugnis1 gemäß A_25042-* (Zertifikatsprofil C.CH.SIG)
    2. prüfen, ob die professionOID im Signaturzertifikat oid_idpd_sek ist
    3. prüfen des CMAC von Befugnis2
    4. prüfen, dass die Telematik-ID in Befugnis 1 keine KVNR ist (Vertreter dürfen keine weiteren Vertreter befugen)
    5. prüfen, ob die KVNR im Signaturzertifikat C.CH.SIG der Signatur von Befugnis1 mit der „KVNR Vertreter“ in der Befugnis2 übereinstimmt
    6. prüfen, ob die „KVNR Aktenkonto“ in Befugnis 1 mit der „KVNR Aktenkonto“ in Befugnis2 übereinstimmt
    7. prüfen, dass das JWT gemäß A_24587-* nicht abgelaufen ist (Feld: exp)
  2. Falls die Prüfungen in 1) erfolgreich waren, wird die Befungnis3 vom Befugnisverifikations-Modul erstellt. Die Inhalte werden aus Befugnis1 übernommen.
  3. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und Befugnis3
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  4. Das Befugnisverifikations-Modul liefert die mittels CMAC gesicherte Befugnis3 als Ergebnis des Regelaufrufs zurück.
rr3 Mit dieser Regel werden Befugnisse im Aktensystem registriert, die sich durch das Stecken der eGK in einer Leistungserbringerumgebung ergeben.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • Prüfziffer des VSDM-Prüfungsnachweises signiert mit AUT-Identität der SMC-B
Ausgangsdaten:
  • Befugnis = (KVNR Aktenkonto, Telematik-ID, Gültigkeitszeitraum) gesichert mittels CMAC
Prüfschritte:
  1. prüfen der SMC-B-Signatur der signierten VSDM-Prüfziffer gemäß A_25042-* (C.HCI.AUT)
  2. prüfen, dass das JWT gemäß A_24590-* nicht abgelaufen ist (Feld: exp)
  3. prüfen, dass der Ausstellungszeitpunkt der VSDM-Prüfziffer nicht länger als 20 Minuten zurückliegt
  4. prüfen des HMAC der VSDM-Prüfziffer mittels VAU-HSM Regel hsm-r3
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  5. Falls die Prüfungen in 1) bis 4) erfolgreich waren, wird vom Befugnisverifikations-Modul die Befugnis mit folgenden Inhalten erstellt:
    • Aktenkonto: die KVNR aus dem VSDM-Prüfziffer
    • Telematik-ID: die Telematik-ID aus der SMC-B-Signatur
    • Gültigkeitszeitraum: ergibt sich aus der fachlichen Rollen-OID der SMC-B-Signatur.
  6. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und der erstellten Befugnis
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  7. Das Befugnisverifikations-Modul liefert die mittels CMAC gesicherte Befugnis als Ergebnis des Regelaufrufs zurück.
rr4 Mit dieser Regel werden die Befugnisse für den Kostenträger und die zuständige Ombudsstelle bei der Anlage eines Aktenkontos im Aktensystem registriert.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • Befugnis1 = (KVNR Aktenkonto, Telematik-ID des Kostenträgers/der Ombudsstelle) signiert mit SMC-B des Kostenträgers bzw. der Ombudsstelle
Ausgangsdaten:
  • Befugnis2 = (KVNR Aktenkonto, Telematik-ID des Kostenträgers/der Ombudsstelle) gesichert mittels CMAC
Prüfschritte:
  1. Prüfen der Befugnis1
    1. prüfen der SMC-B-Signatur des Kostenträgers bzw. der Ombudsstelle gemäß A_25042-* (C.HCI.OSIG)
    2. prüfen, ob die professionOID im Signaturzertifikat oid_kostentraeger bzw. oid_ombudsstelle ist
    3. prüfen, ob die Telematik-ID im Signaturzertifikat C.HCI.OSIG der SMC-B-Signatur des Kostenträgers bzw. der Ombudsstelle mit der Telematik-ID in der Befugnis1 übereinstimmt
  2. Falls die Prüfungen in 1) erfolgreich waren, wird die Befugnis2 erstellt. Die Inhalte der Befugnis2 sind:
    • Aktenkonto: die KVNR des Aktenkontos aus Befugnis1
    • Telematik-ID: die Telematik-ID aus Befugnis1
  3. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und der erstellten Befugnis2
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  4. Das Befugnisverifikations-Modul liefert die mittels CMAC gesicherte Befugnis2 als Ergebnis des Regelaufrufs zurück.
rr5 Mit dieser Regel werden die Befugnisse bei einem betreiberübergreifenden Anbieterwechsel im Aktensystem registriert.

Eingangsdaten:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • Befugnis1 = (KVNR Aktenkonto, NutzerID, Gültigkeitszeitraum) signiert vom alten Aktensystembetreiber
Ausgangsdaten:
  • Befugnis2 = (KVNR Aktenkonto, NutzerID, Gültigkeitszeitraum) gesichert mittels CMAC
Prüfschritte:
  1. Prüfen der Befugnis1
    1. prüfen der Signatur gemäß A_25042-* (C.FD.SIG)
    2. prüfen, ob im Signaturzertifikat C.FD.SIG der policyIdentifier oid_epa_vau ist
    3. prüfen,  dass das Signaturzertifikat C.FD.SIG nicht auf das importierende Aktensystem ausgestellt ist.
  2. Falls die Prüfungen in 1) erfolgreich waren, wird die Befugnis2 mit den Inhalten aus Befugnis1 erstellt.
  3. Aufruf der VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung und der erstellten Befugnis2
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  4. Das Befugnisverifikations-Modul liefert die mittels CMAC gesicherte Befugnis2 als Ergebnis des Regelaufrufs zurück.

A_24690-01 - ePA-Aktensystem - Befugnisverifikations-Modul: Prüfen des ID-Tokens

Das Befugnisverifikations-Modul MUSS folgende Prüfungen bei der Prüfung eines ID-Tokens durchführen: 

  • das ID-Token muss gemäß A_25042-* valide signiert sein durch einen sektoralen Identity Provider oder den IDP-Dienst (professionOID ist oid_idpd_sek oder oid_idpd),
  • das ID-Token muss zeitlich gültig sein (Felder: iat, exp),
  • das ID-Token muss im Feld aud das ePA-Aktensystem eingetragen haben.
[<=]

A_24691 - ePA-Aktensystem - Befugnisverifikations-Modul: Prüfen von übers ePA-FdV erstellten Befugnissen

Das Befugnisverifikations-Modul MUSS folgende Prüfungen bei der Prüfung einer von einem Versicherten bzw. Vertreter über das ePA-FdV eingestellten signierten Befugnis durchführen:

  • die Befugnis muss gemäß A_25042-* valide signiert sein durch einen Versicherten bzw. Vertreter (C.CH.SIG, professionOID ist oid_versicherter),
  • das JWT für die Befugnis gemäß A_24587-* darf nicht abgelaufen sein (Feld: exp),
  • das Feld insurantID des JWT muss eine KVNR sein,
  • das Feld actorID des JWT muss eine KVNR oder eine Telematik-ID sein,
  • das Feld validTO des JWT muss ein zeitliches Datum sein.
[<=]

Die folgenden Regeln dienen zum Abruf der versichertenindividuellen Daten- und Befugnispersistierungsschlüssel. Die kryptographischen Vorgaben für diese Schlüssel und die Ableitungsvorschriften sind in [gemSpec_Krypt] in Abschnitt 3.15.2 festgelegt.

Tabelle 10: Tab_AS_SDS-Key_Rules Key Rules - Regeln zur Ableitung der versichertenindividuellen Persistierungsschlüssel

Regel Beschreibung
kr1 Diese Regel wird für die Anmeldung des Aktenkontoinhabers genutzt.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token oder HSM-ID-Token gesichert mit CMAC
  • Label Datenpersistierungs-Masterkey der die Grundlage der Schlüsselableitung sein soll (ggf. besonderes Symbol "<current>" für jüngsten im VAU-HSM verfügbaren).
  • Label Befugnispersistierungs-Masterkey der die Grundlage der Schlüsselableitung sein soll (ggf. besonderes Symbol "<current>" für jüngsten im VAU-HSM verfügbaren).
  • ggf. Label Überschlüsselungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
Ausgangsdaten:
  • versichertenindividueller Datenpersistierungsschlüssel (Secure Data Storage Key) + Label des verwendeten Masterkeys
  • versichertenindividueller Befugnispersistierungsschlüssel (SecureAdminStorageKey) + Label des verwendeten Masterkeys
Regelverhalten:
  1. prüfen des ID-Tokens gemäß A_24690-* (Zertifikatsprofil C.FD.SIG)
    1. prüfen, ob die professionOID im Signaturzertifikat oid_idpd_sek ist
oder prüfen des HSM-ID-Tokens
  1. prüfen des CMAC des HSM-ID-Tokens mit VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. prüfen, ob die professionOID im HSM-ID-Token oid_idpd_sek ist
  1. Falls die Prüfungen in 1) erfolgreich waren, wird die VAU-HSM Zugriffsregel hsm-r2 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung, der KVNR aus dem ID-Token und den Labeln der zu verwendenden Befugnispersistierungs- und Datenpersistierungs-Masterkeys zur Ableitung von Befugnis- und Datenpersistierungsschlüssel aufgerufen.
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. Das Befugnisverifikations-Modul liefert die abgeleiteten Schlüssel als Ergebnis des Regelaufrufs zurück.
kr2 Diese Regel wird für den Abruf des versichertenindividuellen Befugnispersistierungsschlüssel genutzt. Sie wird für die Anmeldung von Nutzern verwendet, für die eine Befugnis im Aktensystem registriert wurde.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • KVNR (Aktenkonten-ID)
  • Label Befugnispersistierungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
  • ggf. Label Überschlüsselungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
Ausgangsdaten:
  • versichertenindividueller Befugnispersistierungsschlüssel (SecureAdminStorageKey) + Label des verwendeten Masterkeys
  • ggf. versichertenindividueller Überschlüsselungsschlüssel + Label des verwendeten Masterkeys
Prüfschritte:
  1. Aufruf der VAU-HSM Zugriffsregel hsm-r2 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung, der KVNR und dem Label des Befugnispersistierungs-Masterkeys zur Ableitung des Befugnispersistierungsschlüssels
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. Das Befugnisverifikations-Modul liefert den abgeleiteten Befugnispersistierungschlüssel als Ergebnis des Regelaufrufs zurück.
kr3 Diese Regel wird für den Abruf des versichertenindividuellen Datenpersistierungsschlüssels genutzt. Sie wird für die Anmeldung von Nutzern verwendet, für die eine Befugnis im Aktensystem registriert wurde.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token oder HSM-ID-Token gesichert mit CMAC
  • Befugnis = (KVNR Aktenkonto, BefugtenID (TID|KVNR), Gültigkeitszeitraum (opt.)) mit CMAC gesichert
  • Label Datenpersistierungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
  • ggf. Label Überschlüsselungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
Ausgangsdaten:
  • versichertenindividueller Datenpersistierungsschlüssel (Secure Data Storage Key) + Label des verwendeten Masterkeys
  • ggf. versichertenindividueller Überschlüsselungsschlüssel + Label des verwendeten Masterkeys
Prüfschritte:
  1. prüfen des ID-Tokens
    1. gemäß A_24690-* (Zertifikatsprofil C.FD.SIG)
oder prüfen des HSM-ID-Tokens
    1. prüfen des CMAC des HSM-ID-Tokens mit VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung
      1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  1. Prüfen der Befugnis
    1. prüfen des CMAC der Befugnis mittels VAU-HSM Regel hsm-r1
      1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
    2. prüfen, ob die Nutzer-ID im ID-Token bzw. im HSM-ID-Token (KVNR oder Telematik-ID) mit der Befugten-ID in der Befugnis übereinstimmt.
    3. prüfen, ob die Befugnis noch gültig ist, falls die Befugnis zeitlich begrenzt ist (d. h. ein Gültigkeitszeitraum in der Befugnis enthalten ist).
  2. Falls alle Prüfungen in 1) bis 2) erfolgreich waren, wird die VAU-HSM Zugriffsregel hsm-r2 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung, der KVNR aus dem ID-Token bzw. im HSM-ID-Token und dem Label für den Datenpersistierungs-Masterkey zur Ableitung des Datenpersistierungsschlüssels aufgerufen.
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  3. Das Befugnisverifikations-Modul liefert den abgeleiteten Datenpersistierungsschlüssel als Ergebnis des Regelaufrufs zurück.
kr4 Diese Regel wird für die Anmeldung des E-Rezept-Fachdienstes verwendet.

Eingangsdaten
:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU
  • ID-Token oder HSM-ID-Token gesichert mit CMAC
  • KVNR (Aktenkonten-ID)
  • Label Datenpersistierungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
  • ggf. Label Überschlüsselungs-Masterkey der die Grundlage der Schlüsselableitung sein soll
Ausgangsdaten:
  • versichertenindividueller Datenpersistierungsschlüssel (Secure Data Storage Key) + Label des verwendeten Masterkeys
  • ggf. versichertenindividueller Überschlüsselungsschlüssel + Label des verwendeten Masterkeys
Prüfschritte:
  1. Prüfen des ID-Tokens
    1. prüfen der Signatur gemäß A_25042-* (C.FD.AUT)
    2. prüfen, ob die professionOID im Zertifikat C.FD.AUT gleich oid_erp-vau ist
    3. prüfen des ID-Tokens gemäß A_24658-*
oder prüfen des HSM-ID-Tokens
  1. prüfen des CMAC des HSM-ID-Tokens mit VAU-HSM Zugriffsregel hsm-r1 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. prüfen, ob die professionOID im HSM-ID-Token oid_erp-vau ist
  1. Falls die Prüfungen in 1) erfolgreich waren, wird die VAU-HSM Zugriffsregel hsm-r2 mit dem VAU-Attestierungstoken der Aktenkontoverwaltung, der KVNR aus dem ID-Token bzw. dem HSM-ID-Token und dem Label für den Datenpersistierungs-Masterkey zur Ableitung des Datenpersistierungsschlüssels aufgerufen.
    1. Falls das Befugnisverifikations-Modul in einer Befugnisverifikations-VAU ausgeführt wird, wird zusätzlich ein VAU-Attestierungstoken für die Befugnisverifikations-VAU mit übergeben.
  2. Das Befugnisverifikations-Modul liefert den abgeleiteten Schlüssel als Ergebnis des Regelaufrufs zurück.
kr5 Diese Regel wird für die Überschlüsselung verwendet (ggf. mit Umschlüsselung einer Überschlüsselung).

Diese Regel kann von einer VAU (AK-VAU oder dedizierte Überschlüsselungs-VAU) verwendet werden um verschlüsselte Akten zu überschlüsseln (vgl. Abschnitt 3.6 Umschlüsselung und Überschlüsselung). Dabei kann es auch zu einer Umschlüsselung einer älteren Überschlüsselung kommen.

Sei <current> ein spezielles Symbol was im VAU-HSM durch das Label des jüngsten Überschlüsselungsschlüssel ersetzt wird. Ein Aufruf braucht so das tatsächliche Label nicht zu kennen. (Der Hersteller ist frei "<current>" durch ein selbstgewählten Symbolnamen zu ersetzen.)

Eingangsdaten:
  • VAU-Attestierungstoken einer Aktenkontoverwaltungs-VAU oder ggf. einer dedizierten Überschlüsselungs-VAU
  • KVNR (Aktenkonten-ID)
  • Labelliste: nicht leere Liste von Label-n von Überschlüsselungs-Masterkeys
    (im Regelfall enthält die Liste mindestens "<current>" als Element)
Ausgangsdaten:
  • Liste von Paaren:
    versichertenindividueller Überschlüsselungsschlüssel (Secure Data Storage Key), 
    Label für verwendeten Überschlüsselungs-Masterkey

    (Hinweis: Die Liste enthält mindestens ein Element -- im Fall der ersten Überschlüsselung in Intervall 2 (vgl. Abschnitt 3.6 Umschlüsselung und Überschlüsselung ))
Ablauf:
Das VAU-HSM muss des VAU-Attestierungstoken prüfen, ob es sich um eine AK-VAU oder dedizierte Überschlüsselungs-VAU handelt. Falls nein, Abbruch.

Das VAU-HSM durchläuft die Label-Liste und führt mit dem entsprechenden Label verbundenen Überschlüsselungs-Masterkey und der KVNR eine Schlüsselableitung durch. Dabei wird im VAU-HSM das spezielle Symbol "<current>" durch das Label des jüngsten Überschlüsselungs-Masterkeys vor Abarbeitung ersetzt. 
In der Ergebnisse (siehe Ausgangsdaten) ist "<current>" ebenfalls so ersetzt.
Die Reihenfolge in der Eingangsliste muss in der Ausgabeliste gleich bleiben.

3.5 Vertrauenswürdige Ausführungsumgebung (VAU)

Eine Vertrauenswürdige Ausführungsumgebung (VAU) gewährleistet mit technischen Maßnahmen, dass Daten serverseitig im ePA-Aktensystem im Klartext verarbeitet werden können, ohne dass einzelne Mitarbeiter des Betreibers auf diese Daten zugreifen können.

Die Datenverarbeitungen der Aktenkontoverwaltung müssen in einer VAU ausgeführt werden. Diese VAU wird im folgenden als Aktenkontoverwaltungs-VAU bezeichnet. Des weiteren kann das Befugnisverifikations-Modul in einer VAU ausgeführt werden. Diese VAU wird im folgenden als Befugnisverifikations-VAU bezeichnet.

A_25716-01 - ePA-Aktensystem - Services ausschließlich in der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass die folgenden Services ausschließlich innerhalb einer VAU ausgeführt werden können und ein Zugriff auf die Schnittstellen ausschließlich über einen VAU-Kanal erfolgen kann:

  • Consent Decision Management Service
  • Entitlement Management
  • Constraint Management
  • Device Management
  • E-Mail Management
  • Audit Event Service
  • Authorization Service
  • Health Record Relocation Service
  • alle Medical Services
  • Data Submission Service.
[<=]

In den folgenden Abschnitten werden zunächst die Anforderungen an eine VAU beschrieben, die sowohl von einer Aktenkontoverwaltungs-VAU als auch einer Befugnisverifikations-VAU zu erfüllen sind. Die speziellen Anforderungen an eine Aktenkontoverwaltungs-VAU bzw. an eine Befugnisverifikations-VAU folgen darauf in separaten Abschnitten.

3.5.1 Übergreifende VAU-Anforderungen

3.5.1.1 Schutz der Integrität der VAU

Die folgenden Anforderungen stellen die Integrität der VAU sicher.

A_24613 - ePA-Aktensystem - Bildung Hashwertrepräsentation des VAU-Images

Der Hersteller des VAU-Images MUSS für seine zugelassenen VAU-Images Hashwertrepräsentationen bilden. Diese MÜSSEN signiert und die signierten Hashwertrepräsentationen an die gematik übermitteln. Dabei SOLLEN bezüglich der kryptographischen Vorgaben zur Signatur die Vorgaben aus [gemSpec_Krypt] eingehalten werden. [<=]

Erläuterung zu A_24613-*:

Bei Intel-SGX sind die durch die Intel-Hardware erzeugten Signaturen RSA-3072-Bit-Signaturen, bei denen der öffentliche Exponent 3 ist. Dies entspricht nicht den Vorgaben in [gemSpec_Krypt] für allgemeine RSA-Signaturen (also nicht im SGX-Kontext). Deshalb steht in A_24613-* diesbezüglich nur eine SOLL-Formulierung. Im Kontext SGX ist der öffentliche RSA-Exponent 3 zulässig.

A_24642 - ePA-Aktensystem - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU MUSS die Integrität der eingesetzten Hardware schützen und damit insbesondere Manipulationen an der Hardware durch den Betreiber des ePA-Aktensystems ausschließen. [<=]

A_24616 - ePA-Aktensystem - Attestierung des VAU-Images und der VAU-Hardware beim Start

Das ePA-Aktensystem MUSS beim Start einer VAU das genutzte VAU-Image sowie die VAU-Hardware, auf der die VAU ausgeführt werden soll, kryptographisch attestieren und ein signiertes VAU-Attestierungstoken erzeugen, welches vom VAU-HSM geprüft werden kann. [<=]

A_24684 - ePA-Aktensystem - Hardwarebasierter Vertrauensanker für Attestierung der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass der kryptographische Vertrauensanker für die Attestierung des VAU-Images und der VAU-Hardware in einem hardwarebasierten sicheren Schlüsselspeicher gesichert ist. [<=]

A_24617 - ePA-Aktensystem - Betreiberunabhängiger Vertrauensanker für Attestierung der VAU

Das ePA-Aktensystem MUSS sicherstellen, dass der kryptographische Vertrauensanker für die Attestierung des VAU-Images und der VAU-Hardware nicht in der Hoheit des Betreibers des Aktensystems liegt.  [<=]

Hinweis zu A_24617: Mit der Anforderung soll die Bedrohung abgewehrt werden, dass sich einzelne Innentäter beim Betreiber des ePA-Aktensystems eigene VAU-Software oder VAU-Hardware mit Schwachstellen erstellen und sich für diese einen falschen Hashwert attestieren, der dem VAU-HSM bekannt ist.

A_24620 - ePA-Aktensystem - Attestierung durch Systeme außerhalb der VAU zur Laufzeit

Das ePA-Aktensystem MUSS technisch ermöglichen, dass Änderungen an der VAU-Software und der VAU-Hardware während der Laufzeit durch Systeme außerhalb der VAU automatisiert geprüft werden können.  [<=]

Hinweis: Die gematik soll regelmäßig die Integrität der Aktensysteme prüfen können.

3.5.1.2 Schutz der Daten bei Verarbeitung in der VAU

Die folgenden Anforderungen der VAU stellen sicher, dass die innerhalb der VAU verarbeiteten Daten technisch geschützt werden.

A_24621 - ePA-Aktensystem - Äußere Isolation der VAU von Datenverarbeitungsprozessen des Betreibers

Die VAU MUSS die in ihr ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Betreibers technisch trennen und damit gewährleisten, dass der einzelne Mitarbeiter des Betreibers vom Zugriff auf die in der VAU verarbeiteten Daten technisch ausgeschlossen ist.  [<=]

A_24638 - ePA-Aktensystem - Schutz der Daten vor physischem Zugang zu Systemen der VAU

Die VAU MUSS mit technischen Mitteln sicherstellen, dass bei einem physischen Zugang zu Hardware-Komponenten der VAU keine Daten aus der VAU extrahiert oder manipuliert werden können.  [<=]

A_24651 - ePA-Aktensystem - Betreiber ergreift Maßnahmen gegen physische Angriffe auf die VAU

Der Betreiber des ePA-Aktensystems MUSS mit technischen und/oder organisatorischen Maßnahmen ausschließen, dass ein einzelner Innentäter beim Betreiber des ePA-Aktensystems physische Angriffe auf eine VAU ausführen kann.   [<=]

A_24641 - ePA-Aktensystem - Löschen aller Daten beim Beenden einer VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass beim Beenden einer VAU-Instanz sämtliche Daten dieser VAU-Instanz aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist. [<=]

A_25244 - ePA-Aktensystem - x-insurantId nicht außerhalb des VAU-Kanals

Das ePA-Aktensystem MUSS sicherstellen, dass das HTTP Header-Element mit dem Namen "x-insurantId" nicht außerhalb des VAU-Kanals gesendet wird. [<=]

3.5.1.3 Schutz der Daten bei Speicherung außerhalb der VAU

A_26314 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Daten

Das ePA-Aktensystem MUSS sicherstellen, dass eine VAU Daten, die im System des Aktensystembetreibers gespeichert werden sollen und für die keine spezifischen Anforderungen zum Schutz der gespeicherten Daten existieren, ausschließlich verschlüsselt gespeichert werden und der verwendete Verschlüsselungsschlüssel mittels der Regel hsm-r8 vom VAU-HSM abgeleitet wird. [<=]

Hinweise zu A_26314:

  • Spezifische Anforderungen zum Schutz der gespeicherten Daten gibt es z.B. für die Aktenkontoverwaltungs-VAU in Abschnitt 3.5.2.2 und die durch die VAU für den Betrieb erstellten Protokolle in Abschnitt 3.5.1.5.
  • Außerhalb der VAU verschlüsselt gespeicherte Daten der ePA3.0, die bisher nicht mit Regel hsm-r8 verschlüsselt sein konnten,  sind beim Öffnen der Akte umzuschlüsseln und mit einem Schlüssel zu sichern, der mit Regel hsm-r8 abgeleitet wird. Eine Umschlüsselung ohne Öffnen der Akte ist nicht erforderlich.

A_26322 - ePA-Aktensystem - Unterschiedliche Schlüssel für die Verschlüsselung von außerhalb der VAU gespeicherten Daten bei unterschiedlichen Verarbeitungszwecken

Falls Daten außerhalb der VAU im System des Aktensystembetreibers gespeichert werden, MUSS das ePA-Aktensystem sicherstellen, dass für die Verschlüsselung von Daten, die zu unterschiedlichen Zwecken verarbeitet werden, unterschiedliche Verschlüsselungsschlüssel genutzt werden. [<=]

Hinweis zu A_26322: Verarbeitungszwecke für Daten sind beispielsweise die Verarbeitung von Daten zum Zwecke  der Sekundärnutzung ( siehe Data Submission Service) oder die Verarbeitung von Daten für die Nutzerverwaltung im Aktensystem (insbesondere Geräteinformationen und E-Mail-Adressen).

3.5.1.4 Schutz der Verbindung zwischen VAU und VAU-HSM

A_24653 - ePA-Aktensystem - Sichere Verbindung zwischen VAU und VAU-HSM

Das ePA-Aktensystem MUSS technisch sicherstellen, dass zwischen einer VAU und einem VAU-HSM eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

3.5.1.5 Logging und Monitoring

Hinweis: Die Anforderungen dieses Abschnitts könnten sich noch ändern, falls sich bei der Umsetzung des ePA-Aktensystems herausstellt, dass weitere Protokollierungen auf Seiten des Betreibers notwendig werden.

Die Anforderungen zu den Betreiberprotokollen können im weiteren Verlauf der Umsetzung des ePA-Aktensystems

A_24910 - ePA-Aktensystem - Erlaubte Zwecke der Betreiberprotokolle

Der Betreiber des Aktensystems MUSS sicherstellen, dass die durch die VAU für den Betrieb erstellten Protokolle des Betreibers ausschließlich zum Zwecke der Fehleranalyse und -behebung anlassbezogen sowie zum Zwecke des Security Monitorings verwendet werden. [<=]

A_24649 - ePA-Aktensystem - Datenschutzkonformes Logging und Monitoring der VAU

Die VAU MUSS die für den Betrieb des ePA-Aktensystems erforderlichen Logging- und Monitoring-Informationen in solcher Art und Weise erheben und verarbeiten, dass mit technischen Mitteln ausgeschlossen ist, dass dem Betreiber des ePA-Aktensystems vertrauliche oder zur unautorisierten Profilbildung geeignete Daten zur Kenntnis gelangen.  [<=]

A_24695 - ePA-Aktensystem - Keine medizinische Informationen in VAU-Protokollen des Betreibers

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers keine personenbezogenen medizinischen Informationen enthalten sind (u. a. medizinische Daten von Versicherten oder Informationen, aus denen sich ableiten lässt, bei welchen Leistungserbringerinstitutionen ein Versicherter in Behandlung ist).
[<=]

A_24909 - ePA-Aktensystem - Nicht KVNR und Telematik-ID gemeinsam protokollieren

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers höchstens die KVNR oder höchstens die Telematik-ID enthalten ist, aber nicht eine Kombination aus KVNR und Telematik-ID und keine solche Verbindung über mehrere Protokolle hergestellt werden kann. [<=]

A_24719 - ePA-Aktensystem - Kein kryptographisches Schlüsselmaterial in VAU-Protokollen des Betreibers

Die VAU MUSS sicherstellen, dass in den durch die VAU für den Betrieb erstellten Protokollen des Betreibers kein kryptographisches Schlüsselmaterial enthalten ist. [<=]

A_24911 - Löschfristen Protokolle

Das ePA-Aktensystem MUSS sicherstellen, dass die

  • zum Zwecke der Fehleranalyse erhobenen Protokolle nach Behebung des Fehlers unverzüglich gelöscht werden,
  • zum Zwecke des Security Monitorings erhobenen Protokolle nach 3 Monaten gelöscht werden.
[<=]

A_26316 - Anbieter ePA-Aktensystem - Schutz der Protokolle des Betreibers

Der Betreiber des ePA-Aktensystems MUSS sicherstellen, dass die durch die VAU für den Betrieb erstellten Protokolle des Betreibers durch technische und organistorische Maßnahmen vor einer missbräuchlichen Nutzung geschützt werden. [<=]

3.5.2 Zusätzliche Anforderungen an eine Aktenkontoverwaltungs-VAU

3.5.2.1 Schutz der Daten bei Verarbeitung in der Aktenkontoverwaltungs-VAU

A_24636 - ePA-Aktensystem - Innere Isolation zwischen Datenverarbeitungsprozessen innerhalb einer VAU-Instanz

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus ausschließen, dass sich innerhalb einer VAU-Instanz die Verarbeitungen eines Health Record Context oder einer User Session schadhaft auf die Verarbeitungen eines anderen Health Record Context oder einer anderen User Session auswirken können.
[<=]

Hinweis zu A_24636-*: Die Anforderung schließt eine Umsetzung mit Server-Threads, Worker und Ähnlichem nicht grundsätzlich aus, sofern die Sicherheitsleistung der Separation erbracht werden kann.

A_24885 - ePA-Aktensystem - Innere Isolation zwischen Datenverarbeitungsprozessen unterschiedlicher VAU-Instanzen

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus, der unabhängig vom Separationsmechanismus in A_24636-* ist, ausschließen, dass sich Verarbeitungen in einer VAU-Instanz schadhaft auf die Verarbeitungen einer anderen VAU-Instanz auswirken können.
[<=]

A_24637 - ePA-Aktensystem - Maximale Health Record Context in einer VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass maximal 80 Health Record Context gleichzeitig in einer VAU-Instanz laufen können.
[<=]

A_25028 - ePA-Aktensystem - Keine Kommunikation zwischen Aktenkontoverwaltungs-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass es keine direkte Kommunikation zwischen VAU-Instanzen von Aktenkontoverwaltungs-VAUs gibt. [<=]

A_26111 - ePA-Aktensystem - Keine Kommunikation zwischen Health Record Contexts

Das ePA-Aktensystem MUSS sicherstellen, dass es innerhalb einer Aktenkontoverwaltungs-VAU-Instanz keine Kommunikation zwischen Health Record Contexts gibt. [<=]

A_24639 - ePA-Aktensystem - Löschen aller Daten beim Beenden eines Health Record Context

Die VAU MUSS sicherstellen, dass beim Beenden eines Health Record Context sämtliche Daten dieses Health Record Context aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist.  [<=]

A_24640 - ePA-Aktensystem - Löschen aller Daten beim Beenden einer User Session

Die VAU MUSS sicherstellen, dass beim Beenden einer User Session sämtliche Daten dieser User Session aus flüchtigen Speichern sicher gelöscht werden oder ein Zugriff auf diese Daten technisch ausgeschlossen ist. [<=]

Hinweis zu A_24639-*, A_24640-* und A_24648-*: Eine zeitliche Verzögerung des Löschens ist tolerabel, sofern ein sofortiges Löschen aufgrund der Architektur des Aktensystemherstellers aus Performanzgründen nicht sinnvoll ist. In diesem Fall ist ein geeigneter Kompromiss zwischen dem Löschzeitpunkt und der Performanz zu wählen.

A_25231 - ePA-Aktensystem - Schließen des Health Record Context beim Beenden einer User Session

Die VAU MUSS sicherstellen, dass beim Beenden einer User Session alle mit dieser User Session verknüpften Health Record Context beendet werden, wenn der jeweilige Health Record Context nicht mit mindestens einer weiteren User Session verknüpft ist. [<=]

A_25051 - ePA-Aktensystem - VAU-Kanal endet immer in einer Aktenkontoverwaltungs-VAU

Die VAU MUSS sicherstellen, dass ein VAU-Kanal von einem Client der ePA (ePA-Client oder ePA-FdV) ausschließlich in einer Aktenkontoverwaltungs-VAU endet. [<=]

Hinweis: Der VAU-Kanal darf z.B. nicht in einer Befugnisverifikations-VAU enden.

3.5.2.2 Schutz der Daten bei Speicherung außerhalb der Aktenkontoverwaltungs-VAU

Die folgenden Anforderungen gewährleisten den Schutz der beim Betreiber des ePA-Aktensystems persistierten Daten von Aktenkonten. Die Verschlüsselung der Daten eines Versicherten erfolgt mit seinem versichertenindividuellen Daten- und Befugnispersistierungsschlüssel. Die kryptographischen Vorgaben für diese Schlüssel sind in [gemSpec_Krypt#3.15.2] festgelegt.

A_24643 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Daten mit dem Datenpersistierungsschlüssel

Die VAU MUSS sicherstellen, dass die in einem Health Record Context verarbeiteten

  1. Daten des FHIR-Data Service
  2. Daten des XDS Document Service
  3. Daten des Audit Event Service (Protokolle für den Versicherten zum Zwecke der Datenschutzkontrolle)
  4. Daten des Constraint Managements (Policies zu verborgenen Daten)
  5. Daten des Consent Managements (Widersprüche des Versicherten)
vor der Speicherung in den Systemen des Betreibers des ePA-Aktensystems innerhalb des Health Record Context mit dem zum Health Record gehörenden versichertenindividuellen Datenpersistierungsschlüssel verschlüsselt werden.
[<=]

A_24644 - ePA-Aktensystem - Verschlüsselung von außerhalb der VAU gespeicherten Befugnissen mit dem Befugnispersistierungsschlüssel

Die VAU MUSS sicherstellen, dass die in einem Health Record Context verarbeiteten Daten des Entitlement Managements, d. h. Befugnisse und Befugnisverbote, vor der Speicherung in den Systemen des Betreibers des ePA-Aktensystems innerhalb des Health Record Context mit dem zum Health Record gehörenden versichertenindividuellen Befugnispersistierungsschlüssel verschlüsselt werden. [<=]

3.5.2.3 Konsistenz des Systemzustands

A_24650 - ePA-Aktensystem - Konsistenter Systemzustand eines Health Record Context

Die VAU MUSS sicherstellen, dass ein konsistenter Zustand eines Health Record Context auch bei Bedienfehlern oder technischen Problemen immer erhalten bleibt bzw. wiederhergestellt werden kann. [<=]

A_24696 - ePA-Aktensystem - Konsistenz bei parallelen Zugriffen

Die VAU MUSS auch bei parallelen Zugriffen auf dasselbe Aktenkonto durch mehrere Nutzer immer einen konsistenten Zustand des Aktenkontos gewährleisten. [<=]

3.5.3 Zusätzliche Anforderungen an eine Befugnisverifikations-VAU

Eine Befugnisverifikations-VAU ist eine spezielle VAU, in der ausschließlich das Befugnisverifikations-Modul ausgeführt wird.

A_24646 - ePA-Aktensystem - Befugnisverifikations-VAU verarbeitet ausschließlich ein Befugnisverifikations-Modul

Das ePA-Aktensystem MUSS sicherstellen, dass in einer Befugnisverifikations-VAU ausschließlich ein Befugnisverifikations-Modul ausgeführt wird. [<=]

A_24647 - ePA-Aktensystem - Befugnisverifikations-VAU speichert keine Daten

Eine Befugnisverifikations-VAU DARF die Daten, die sie im Rahmen der Regeln des Befugnisverifikations-Moduls verarbeitet, NICHT außerhalb der Befugnisverifikations-VAU speichern. [<=]

Eine Befugnisverifikations-VAU darf insbesondere die vom VAU-HSM abgeleiteten versichertenindividuellen Persistierungsschlüssel nicht speichern.

A_24648 - ePA-Aktensystem - Befugnisverifikations-VAU löscht Daten nach Regelbearbeitung

Eine Befugnisverifikations-VAU MUSS sämtliche Daten, die sie im Rahmen eines Regelaufrufs des Befugnisverifikations-Moduls verarbeitet, sofort nach Abarbeitung der Regel sicher aus der Befugnisverifikations-VAU löschen bzw. einen Zugriff auf diese Daten technisch ausschließen. [<=]

A_24671 - ePA-Aktensystem - Sichere Verbindung zwischen VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass zwischen einer VAU-Instanz einer Befugnisverifikations-VAU und einer VAU-Instanz einer Aktenkontoverwaltungs-VAU eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

A_24856 - ePA-Aktensystem - Private Authentisierungsschlüssel für sichere Verbindung zwischen VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass sich die VAU-Instanzen bei einer Verbindung zwischen einer VAU-Instanz einer Befugnisverifikations-VAU und einer VAU-Instanz einer Aktenkontoverwaltungs-VAU mit privaten Schlüsseln authentisieren, die ausschließlich über die jeweilige VAU-Instanz nutzbar sind. [<=]

3.5.4 Zusätzliche Anforderungen an eine Service-VAU

Spezielle Funktionen der “ePA für alle“ können in eigenen, von den Aktenkontoverwaltungs-VAUs (AK-VAU) getrennten, VAUs ausgelagert und ausgeführt werden. Diese VAUs werden als Service-VAUs bezeichnet. Es kann Service-VAUs für unterschiedliche Funktionen geben, so dass es dementsprechend unterschiedliche Typen von Service-VAUs geben kann.

Service-VAU-Instanzen können durch den Betreiber des Aktensystems gestartet und in einem Pool verwaltet werden. AK-VAU-Instanzen können bei Bedarf auf Service-VAU-Instanzen zugreifen, wenn sie den Service nutzen möchten (in Abbildung 2 mit Service A dargestellt), Ein Kommunikationsaufbau von Service-VAU-Instanzen zu AK-VAU-Instanzen ist nicht möglich.

Eine Service-VAU-Instanz kann von mehreren AK-VAU-Instanzen gleichzeitig genutzt werden (die Service-VAU-Instanz zu AK-VAU-Instanz-Beziehung ist eine n:m-Beziehung).

Abbildung 2 - Überblick Service-VAUs

Innerhalb einer Service-VAU-Instanz erfolgt die Verarbeitung unterschiedlicher Service-Requests in voneinander getrennten Isolated Workspaces. Isolated Workspaces in Service-VAUs werden analog zu den Health Record Contexts in Aktenkontoverwaltungs-VAUs geschützt.

A_26112 - ePA-Aktensystem - Maximale Isolated Workspaces in einer Service-VAU-Instanz

Das ePA-Aktensystem MUSS sicherstellen, dass maximal 80 Isolated Workspaces gleichzeitig in einer Service-VAU-Instanz laufen können. [<=]

A_26113 - ePA-Aktensystem - Isolation zwischen Isolated Workspaces innerhalb einer Service-VAU-Instanz

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus ausschließen, dass sich innerhalb einer Service-VAU-Instanz die Verarbeitungen eines Isolated Workspaces schadhaft auf die Verarbeitungen eines anderen Isolated Workspaces auswirken können. [<=]

A_26114 - ePA-Aktensystem - Isolation zwischen unterschiedlichen Service-VAU-Instanzen

Das ePA-Aktensystem MUSS durch einen technischen Separationsmechanismus, der unabhängig vom Separationsmechanismus in A_26113-* ist, ausschließen, dass sich Verarbeitungen in einer Service-VAU-Instanz schadhaft auf die Verarbeitungen einer anderen Service-VAU-Instanz auswirken können. [<=]

A_26115 - ePA-Aktensystem - Isolated Workspace verarbeitet maximal einen Request einer AK-VAU

Nachdem ein Isolated-Workspace einen (1) Service-Request einer Aktenkontoverwaltungs-VAU-Instanz verarbeitet hat, MUSS das ePA-Aktensystem sicherstellen, dass alle Daten des Isolated-Workspaces sicher gelöscht werden, um den Isolated-Workspace für nachfolgende Service-Requests wieder neu zu initialisieren.  [<=]

A_26116 - ePA-Aktensystem - In einem Isolated Workspace sind zu einem Zeitpunkt nur Daten eines Versicherten

Das ePA-Aktensystem MUSS sicherstellen, dass in einem Isolated Workspace zu einem Zeitpunkt ausschließlich Daten eines Versicherten verarbeitet werden können, sofern die Auswahl der zu verarbeitenden Daten durch die Logik im ePA-Aktensystem bestimmt wird. [<=]

Hinweis zu A_26116-*: Falls Nutzer die Daten für die Service-VAU auswählen, ohne dass das ePA-Aktensystem auf diese Daten Einfluss hat (z.B. Nutzer wählt zu konvertierende PDF-Dokumente im ePA-FdV aus) kann es dazu kommen, dass zu einem Zeitpunkt auch Daten mehrerer Versicherter in einem Isolated Workspace verarbeitet werden.

A_26117 - ePA-Aktensystem - Keine Kommunikation zwischen Isolated Workspaces

Das ePA-Aktensystem MUSS sicherstellen, dass es innerhalb einer Service-VAU-Instanz keine Kommunikation zwischen Isolated Workspaces gibt. [<=]

A_26118 - ePA-Aktensystem - Keine Kommunikation zwischen Service-VAU

Das ePA-Aktensystem MUSS sicherstellen, dass es keine Kommunikation zwischen Instanzen von Service-VAUs gibt. [<=]

A_26119 - ePA-Aktensystem - Service-VAUs speichern keine Daten in Aktenkonten

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen keine Daten in einem Aktenkonto eines Versicherten persistieren. [<=]

A_26120 - ePA-Aktensystem - Service-VAUs verarbeiten keine Identitätstoken

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen keine Identitätstoken von Nutzern verarbeiten. [<=]

A_26123 - ePA-Aktensystem - Service-VAU-Instanzen haben maximale Lebensdauer

Das ePA-Aktensystem MUSS sicherstellen, dass Service-VAU-Instanzen nach einer definierten Lebensdauer (abhängig von der Funktionalität der Services) keine neuen Service-Requests mehr annehmen können und, nachdem die laufenden Requests abgearbeitet wurden, beendet und neu gestartet werden. [<=]

A_26124 - ePA-Aktensystem - Information über neuen Service-VAU-Typ

Der Hersteller des ePA-Aktensystems MUSS die gematik über die Absicht der Einführung eines neuen Service-VAU-Typs informieren und ggf. für diesen neuen Service-VAU-Typ zu erfüllende Rahmenbedingungen abstimmen. [<=]

Hinweis zu A_26124-*: Hierzu gehört z.B. auch die Festlegung der maximalen Lebensdauer für den neuen Service-VAU-Typ (siehe A_26123-*).

A_26125 - ePA-Aktensystem - Starten ausschließlich attestierter Service-VAUs

Das ePA-Aktensystem MUSS sicherstellen, dass ausschließlich attestierte Service-VAU-Instanzen gestartet werden können. [<=]

3.5.4.1 Kommunikation zwischen AK-VAU und Service-VAU

A_26126 - ePA-Aktensystem - Gesicherte und authentisierte Verbindung zwischen AK-VAU- und Service-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass zwischen einer Aktenkontoverwaltungs-VAU-Instanz und einer Service-VAU-Instanz eine beidseitig authentisierte und vertrauliche Verbindung besteht. Die vertrauliche Verbindung muss auch gegen Zugriffe durch einzelne Mitarbeiter des Betreibers des Aktensystems schützen. [<=]

A_26127 - ePA-Aktensystem - Kein Kommunikationsaufbau von Service-VAU-Instanzen zu AK-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass eine Service-VAU-Instanz keine Kommunikation zu einer AK-VAU-Instanz aufbauen kann. [<=]

A_26128 - ePA-Aktensystem - Kein Aufruf von Schnittstellen von AK-VAU-Instanzen durch Service-VAU-Instanzen

Das ePA-Aktensystem MUSS sicherstellen, dass eine Service-VAU-Instanz keine Schnittstellen/Services aufrufen kann, die in einer AK-VAU-Instanz ausgeführt werden. [<=]

3.6 Umschlüsselung und Überschlüsselung

Das Kerckhoffs'sche Prinzip von 1883 ist ein Grundpfeiler der Kryptographie. Es besagt u. a. dass die Sicherheit von kryptographischen Verfahren alleinig von der Geheimhaltung der Schüssel abhängen darf, und dass Schlüssel leicht auswechselbar sein müssen. Damit kryptographische Schlüssel in der Praxis ihre Sicherheitseigenschaft behalten können müssen sie einen Lebenszyklus besitzen (vgl. bspw. [NIST-SP-800-57P1]), der den regelmäßigen Austausch (Wechsel) der Schlüssel vorsieht und umsetzt. Jährlich werden aus diesem Grunde die Masterkey für Aktendaten und die Masterkey für Befugnisse erneuert (vgl. A_15745-* und A_20519-* (beide aus [gemSpec_Krypt])). Bei dieser Erneuerung muss eine Umschlüsselung durchgeführt werden:

  • Schlüssel_alt_KVNR = Ableitung (MK_alt, KVNR),
  • Schlüssel_neu_KVNR = Ableitung (MK_neu, KVNR),
  • Umschlüsselung pro Akte: Schlüssel_alt_KVNR -> Schlüssel_neu_KVNR.

Falls eine AK-VAU Zugriff auf eine Akte besitzt und zu diesem Zeitpunkt feststellt neue Masterkeys (vgl. betreiberspezifische Schlüssel A_15745-*) existieren, muss sie eine Umschlüsselung durchführen (A_20519-*). Falls eine Akte länger nicht verwendet wird, kann eine AK-VAU keinen Zugang zu den Klartexten der Akte erhalten, da sie nur nach erfolgreicher Nutzerauthentisierung vom VAU-HSM die aktenspezifischen Ableitungsschlüssel erhält. Dann kann eine AK-VAU zunächst auch keine Umschlüsselung vornehmen. Aus diesem Grunde muss eine VAU (entweder eine AK-VAU oder eine dedizierte Überschlüsselungs-VAU) eine Überschlüsselung der Chiffrate der Akte vornehmen. Dafür werden Überschlüsselungsschlüssel benötigt. Es gibt analog zu den anderen betreiberspezifischen Schlüssel (A_15745-*) Masterkeys für eine Schlüsselableitung für die Überschlüsselung der Chiffrate einer Akte.

A_26197 - ePA-Aktensystem - betreiberspezifische Schlüssel: Überschlüsselungs-Masterkeys

Ein ePA-Aktensystem MUSS sicherstellen, dass die Menge der betreiberspezifischen Schlüssel aus [gemSpec_Krypt#A_15745-*] um die Kategorie Überschlüsselungs-Masterkeys erweitert wird. Für die Überschlüsselungsschlüssel MÜSSEN die gleichen Vorgaben wie für alle bestreiberspezifischen Schlüssel gemäß A_15745-* gelten.
Die betreiberspezifischen Schlüssel werden mindestens jährlich aktualisiert (A_20519-*), die alten Schlüssel MÜSSEN solange im VAU-HSM verfügbar sein, solange Chiffrate im Aktensystem existieren (bspw. Daten einer Akte), die mit diesen Schlüsseln kryptographisch gesichert sind. [<=]

D. h. wie in Abschnitt 3.3 Sichere Speicherung sensibler Schlüssel und Informationen im VAU-HSM (bspw. A_24611-*) definiert, gibt es bei den Masterkeys drei Kategorien: (1) Aktenpersistierung, (2) Befugnispersisitierung und (3) Überschlüsselung. Initial startet der Betrieb eines Aktensystems mit je einem Schlüssel in den ersten zwei Kategorien. Nach maximal einem Jahr (A_20519-*), oder anders formuliert im nächsten Intervall, werden diese beiden ersten Schlüssel zufällig neu erzeugt. Dabei muss nun ein neuer Überschlüsselungsmasterkey erzeugt werden. Die Anzahl der Schlüssel nach o. g. Kategorie ist anschließend (1) 2, (2) 2, (3) 1.

A_26198 - ePA-Aktensystem - neuer Überschlüsselungsschlüssel bei Erneuerung betreiberspezifischen Schlüssel

Ein ePA-Aktensystem MUSS sicherstellen, dass bei jeder Erneuerung der Masterkeys zur Aktenpersistierung ein weiterer neuer Überschlüsselungsmasterkey zufällig im VAU-HSM erzeugt wird.
[<=]

Bei einer Erneuerung der betreiberspezifischen Schlüssel gibt es verschiedene Zeitabschnitte:

Abbildung 3: Zeitabschnitte Umschlüsselung und Überschlüsselung

A_26204 - ePA-Aktensystem - zeitliche Vorgaben zur Durchführung der Umschlüsselung und Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass es ein konfigurierbares Zeitintervall alpha gibt, so dass nach einer Schlüsselerneuerung der betreiberspezifischen Schlüssel innerhalb von alpha bei einer Aktennutzung eine Umschlüsselung in einer AK-VAU vorgenommen wird, falls die Verschlüsselung der Akte auf einem älteren Masterkey basiert. Das Zeitintervall alpha startet jeweils direkt mit jedem neuen Intervall (Schlüsselerneuerung der betreiberspezifischen Schlüssel).
Weiter MUSS es sicherstellen, dass es ein konfigurierbares Zeitintervall beta gibt beginnend direkt nach alpha, so dass nach ablaufen von alpha eine Überschlüsselung von Chiffraten von Akten, bei denen keine Umschlüsselung (wegen Nichtaktennutzung innerhalb von alpha) durchgeführt werden konnte, vorgenommen wird.

Der Default-Wert für die Länge von alpha MUSS 100 Tage und für die Länge von beta 60 Tage betragen. ("Default-Wert" bedeutet, Wert wenn der AS-Betreiber dort keinen anderen Wert konfigurieren möchte.)
[<=]

Die folgenden zwei Anforderung geben weitere Details zu A_26204-*.

A_26205 - ePA-Aktensystem - Umschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass wenn die AK-VAU eine Akte verwendet und feststellt, dass diese Akte nicht überschlüsselt ist und die versichertenindividuelle Aktenverschlüsselung auf einem älteren Masterkey (i. S. v. eben nicht aus dem aktuellen Intervall kommend) basiert, die AK-VAU eine Umschlüsselung vornimmt. Die alten Chiffrate der Akten (also die Chiffrate die auf Basis eines älteren Masterkeys verschlüsselt sind), MÜSSEN im Aktensystem nach erfolgreicher Umschlüsselung gelöscht werden.

Wenn die AK-VAU eine Akte verwendet und feststellt, dass diese überschlüsselt ist, so MUSS die AK-VAU die Überschlüsselung entschlüsseln und die nun verfügbaren Chiffrate der Akten auf Grundlage des aktuellen Masterkeys umschlüsseln. (Hinweis: nach Konstruktion muss die innere Aktenverschlüsselung auf einem älteren Masterkey basieren, ansonsten hätte keine Überschlüsselung stattgefunden.) Nach erfolgreicher Umschlüsselung MÜSSEN die alten Chiffrate (das Überschlüsselungschiffrat und das alte "innere" Chiffrat der Akte) im Aktensystem gelöscht werden. [<=]

Hinweis zu A_26205-*: Die notwendigen aktenspezifischen Schlüssel liegen nun in der AK-VAU vor. Die Umschlüsselung muss nicht direkt sofort vor Nutzung der Akte erfolgen, sondern kann auch einige Minuten später erfolgen. Die konkrete Ausgestaltung liegt beim Hersteller.

A_26206 - ePA-Aktensystem - Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass jeweils im aktuellen Intervall nach Ablauf des Zeitintervalls alpha Akten, die nicht überschlüsselt sind und deren Verschlüsselung auf einem älteren Masterkey (i. S. v. nicht aus dem aktuellen Zeitintervall) basiert, überschlüsselt werden auf Basis des aktuellen Überschlüsselungs-Masterkeys. Diese Umschlüsselung MUSS jeweils innerhalb des Zeitintervalls beta für alle solche Akten abgeschlossen werden. Die "alten" Chiffrate (Chiffrate von solchen Akten vor der Überschlüsselung) MÜSSEN im Aktensystem gelöscht werden. [<=]

Umschlüsselung einer Überschlüsselung: Bei einer Akten, die länger nicht verwendet wird, kann es dazu kommen, dass überschlüsselte Akten wieder überschlüsselt werden müssen, weil alpha im nächsten Intervall abgelaufen ist. In diesem Fall wird eine Umschlüsselung mittels der Überschlüssel vorgenommen, d. h. die Verschlüsselungstiefe / -kette wird 2 nicht überschreiten -- es gibt maximal eine Überschlüsselungsschicht.

Abbildung 4: Zeitabschnitte Umschlüsselung lange nicht verwendeter Akten bei einer Überschlüsselung

A_26208 - ePA Aktensystem - Umschlüsselung einer Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass jeweils in einem Intervall innerhalb von beta überprüft wird, ob überschlüsselte Akten existieren, deren Überschlüsselung auf Basis eines alten Überschlüsselungs-Masterkeys (also aus einem früheren Intervall stammend) durchgeführt wurde. Die AK-VAU (oder eine dedizierte Überschlüsselungs-VAU) MUSS die überschlüsselten Akten umschlüsseln, d. h. die Überschlüsselung auf Grundlage eines älteren Überschlüsselungs-Masterkeys wird aufgehoben (äußeren Verschlüsselungsschicht innerhalb der VAU entschlüsselt) und das Ergebnis (= Chiffrat einer Akte) neu verschlüsselt auf Basis des aktuellen Überschlüsselungs-Masterkeys. Die alten Chiffrate (also vor der Umschlüsselung der Überschlüsselung) MÜSSEN gelöscht werden. Das ePA-Aktensystem MUSS sicherstellen, dass nach Ablauf von beta keine überschlüsselten Akten existieren, deren Überschlüsselung auf Basis eines Überschlüsselungsschlüssel, der nicht aus dem aktuellen Intervall stammt, durchgeführt wurde.
[<=]

Sollte durch irgendeinen Umstand die Sicherheitseigenschaft der Betreiberschlüssel (A_15745-*) in Frage stehen, so muss ein Aktensystembetreiber die Umschlüsselung bzw. die Überschlüsselung aktivieren/starten können.

A_26199 - ePA-Aktensystem - Notfall-Aktivierung Umschlüsselung/Überschlüsselung

Ein ePA-Aktensystem MUSS sicherstellen, dass das ePA-Aktensystem es einem ePA-Betreiber ermöglicht eine Erneuung der betreiberspezifischen Schlüssel zu starten/aktivieren. Es MUSS also dem ePA-Betreiber möglich sein neben der regelmäßigen Erneuerung der betreiberspezifischen Schlüssel (A_205019-*) eine Erneuerung zu initiieren.
[<=]

Nach A_20519-* muss es mindestens jährlich eine Schlüsselerneuerung geben. Mit 26199-* kann ein ePA-Betreiber im Notfall sozusagen den Zyklus "beschleunigen" -- ein neues Intervall sofort einleiten/erzeugen.

Da die Chiffrate in einem ePA-Aktensystem mit Verschlüsselungsschlüsseln, die aus unterschiedlichen Masterkeys (aus unterschiedlichen Intervallen) abgeleitet werden, erzeugt werden können, muss an den äußeren Meta-Daten eines Chiffrats ersichtlich sein auf welchem Masterkeys sie basieren (vom welchem Masterkey sind sie abgeleitet sind).

A_26223 - ePA-Aktensystem - Metadaten von ePA-spezifischen Chiffraten

Ein ePA-Aktensystem MUSS sicherstellen, dass bei ePA-spezifischen Daten (Datenpersistierung von Akten, überschlüsselte Aktenchiffrate, verschlüsselte Befugnisse etc.) an den äußeren (also unverschlüsselten) Meta-Daten des Chiffrat erkennbar ist mithilfe welches (oder welcher) Masterkeys die Chiffrate entschlüsselbar sind. [<=]

3.7 User Session und Health Record Context

Die Verarbeitungen innerhalb einer VAU werden über User Sessions und Health Record Contexts voneinander getrennt.

Wenn ein ePA-Client einen VAU-Kanal zum Aktensystem aufbaut, wird dieser einer bestimmten VAU-Instanz zugeordnet, in welcher dann eine User Session für den Nutzer des ePA-Clients erzeugt wird. Nach erfolgreicher Authentifizierung des Nutzers unter Verwendung des sektoralen IDPs (Versicherte) oder des IDP-Dienstes (LEI) ist die User Session etabliert und kann durch den ePA-Client genutzt werden. Alle Verbindungen für diesen VAU-Kanal werden immer an dieselbe VAU-Instanz geleitet, die die User Session verwaltet. Eine VAU-Instanz kann mehrere User Sessions verwalten.

Wird durch den ePA-Client eine Operation für eine bestimmte Akte aufgerufen (Parameter x-insurantid) der Operation, wird in der User Session geprüft, ob diese Akte schon verwendet wird (ein anderer Nutzer gerade mit der Akte arbeitet) oder nicht. Sollte die Akte noch nicht verwendet werden, wird die Akte in einem Health Record Context geöffnet und kann durch den ePA-Client in dessen User Session verwendet werden. Existiert für die Akte schon ein geöffneter Health Record Context, darf es durch den parallelen Zugriff zu keinen Inkonsistenzen in der Akte kommen.

Innerhalb einer VAU-Instanz dürfen nur eine maximale Anzahl von Health Record Contexts gleichzeitig aufgebaut sein. Sollte diese Anzahl überschritten werden, wird der am längsten nicht genutzte Health Record Context geschlossen, um einen neuen Health Record Context öffnen zu können.

3.8 Consent Decision Management

Das Consent Decision Management des Aktensystems verwaltet die Entscheidungen eines Versicherten oder eines Vertreters für oder gegen die Nutzung von definiert widerspruchsfähigen Funktionen gemäß gesetzlicher Vorgaben.

Außerdem werden im Consent Decision Management die Einschränkungen der Verwendung von Daten auf bestimmte Sekundärnutzungszwecke durch das Forschungsdatenzentrum Gesundheit verwaltet (siehe 3.8.2 Einschränkung der Verwendung von Daten auf bestimmte Sekundärnutzungszwecke ).

Der Widerspruch gegen die grundsätzliche Nutzung der ePA wird nicht im Consent Decision Management berücksichtigt. Die Existenz eines Aktenkontos für einen Versicherten impliziert, dass kein Widerspruch gegen die Nutzung der ePA erteilt wurde. Der Widerspruch gegen das Einstellen von Abrechnungsdaten durch den Kostenträger wird ebenfalls nicht hier verwaltet (siehe zu beiden Widersprüchen auch 3.1.1 Widerspruch des Versicherten gegen die Nutzung der elektronischen Patientenakte ).

3.8.1 Widersprüche für Funktionen der ePA

Die vorgehaltenen Entscheidungen zu einer Funktion umfassen dabei den Zustand "kein Widerspruch erklärt" ("permit") oder "Widerspruch erklärt" ("deny") und den Kontext einer Funktion. Der Kontext ordnet dabei die einzelnen widerspruchsfähigen Funktionen einem für die Umsetzung des Widerspruchs betroffenen Nutzerkreis zu und wird bei den zugreifenden Schnittstellen zur Filterung der Ausgabe verwendet.

Initial, also bei der Erstellung eines neuen Aktenkontos oder bei Übernahme eines existierenden ePA 2.x Aktenkontos, ist für keine widerspruchsfähige Funktion ein Widerspruch gegen die Nutzung erklärt. Ein Versicherter oder ein Vertreter kann im Verlauf der Nutzung des Aktenkontos aktiv der Verwendung von widerspruchsfähigen Funktionen widersprechen oder einen erteilten Widerspruch zurücknehmen.

Die aktuell erteilten Widersprüche können durch einen Versicherten oder einen Vertreter jederzeit über ein ePA-FdV eingesehen und geändert werden. Versicherte und Vertreter, die ein ePA-FdV nicht nutzen möchten, können eine Auskunft über die aktuell erteilten Widersprüche über die Ombudsstelle erhalten und dort auch Änderungen an den Entscheidungen im Aktenkonto veranlassen. Die Ansicht oder Änderung der Widersprüche erfolgt im Aktenkonto stets gesichert innerhalb der VAU, die aktuellen Entscheidungen zu den widerspruchsfähigen Funktionen der ePA sind versichertenindividuell mit dem SecureDataStorageKey verschlüsselt abgelegt.

Die Information über relevante erteilte oder nicht erteilte Widersprüche können Clients auf einfache Weise (ohne Authentisierung oder Etablierung eines VAU-Kanals) im Vorfeld einer Operation über den Information Service abfragen (siehe auch  3.15 Information Service ).

Das Consent Decision Management des Aktenkontos spiegelt ("cached") die Entscheidungen zu den Widersprüchen für die schnelle Abfrage über den Information Service in einen Bereich, der ohne den Aufbau eines VAU-Kanals und Verwendung des versichertenindividuellen SecureDataStorageKey nutzbar ist.

Das Aktenkonto unterstützt die Durchsetzung eines erteilten Widerspruchs überall dort, wo Aktivitäten dediziert als Teil einer widerspruchsfähigen Funktion zugeordnet werden können. Beispielsweise wird das Einstellen neuer Verordnungs- und Dispensierdaten in die Ordner der Kategorie "medication" immer verhindert, wenn der Teilnahme am digital gestützten Medikationsprozess widersprochen wurde. Die konkreten Auswirkungen eines Widerspruchs sind in den jeweiligen Kapiteln zur Handhabung von Dokumenten und Daten des Aktenkontos dargestellt (siehe 3.13.1 XDS Document Service  und 3.13.2 FHIR Data Services ) . 

Die jeweils berücksichtigten widerspruchsfähigen Funktionen sind wie folgt definiert. Diese Liste kann in folgenden Versionen der ePA ergänzt oder verändert werden.

A_23874-01 - Consent Decision Management - Definition der widerspruchsfähigen Funktionen der ePA

Das Consent Decision Management MUSS die Attribute zu widerspruchsfähigen Funktionen der ePA gemäß der folgenden Tabelle verwenden.

Tabelle 11: Widerspruchsfähige Funktionen der elektronischen Patientenakte

Funktion
(name)
Funktionsklasse
(consent class)
Id der Funktion
(id)
Entscheidung
(consent decision)
Teilnahme am digital gestützten Medikationsprozess Versorgungsprozess
("healthcareProcess") 
"medication" "deny"/"permit" 
Einstellen von Verordnungsdaten und Dispensierinformation durch den E-Rezept-Fachdienst Versorgungsprozess
("healthcareProcess") 
"erp-submission" "deny"/"permit" 
Sekundärdatennutzung durch das Forschungsdatenzentrum Gesundheit Sekundärdatennutzung
("secundaryDataUsage")
"data-submission" "deny"/"permit" 
[<=]

Hinweis: Die Bezeichnungen in () sind die Bezeichnungen in den Schnittstellen für den Abruf und die Verwaltung der Widersprüche. Eine widerspruchsfähige Funktion wird durch die ID der Funktion eindeutig identifiziert.

Hinweis: Die Verwaltung der Widersprüche gegen die Nutzung des Aktenkontos durch eine spezifische Leistungserbringerinstitution erfolgt über die Befugnisverwaltung (siehe 3.9.4 Befugnisausschluss (Blocked User Policy) ).

Die Entscheidungen zu den widerspruchsfähigen Funktionen  "medication' und "erp-submission" sind durch das Aktensystem dabei abhängig assoziiert:

A_25300 - Consent Decision Management - Untereinander abhängige Entscheidungen zu Widersprüchen

Das Consent Decision Management MUSS durch interne Maßnahmen sicherstellen, dass bei Erteilung eines Widerspruchs gegen die Nutzung der Funktion der elektronischen Patientenakte 'erp-submission' ('deny') auch der Widerspruch gegen die Nutzung der Funktion 'medication' gesetzt wird ('deny') und dass bei der Rücknahme ('permit') des Widerspruchs gegen die Nutzung der Funktion 'medication' auch der Widerspruch gegen die Nutzung der Funktion 'erp-submission' zurückgenommen wird. [<=]

Hinweis zu A_25300*: Die Änderung der Entscheidung zur Nutzung der "führenden" Funktion hat automatisch eine Entscheidung zur Nutzung der "abhängigen" Funktion zur Folge. Dieses gilt nur für die aufgeführten Entscheidungsänderungen. Alle weiteren, nicht aufgeführten, Änderungen zu Entscheidungen haben keine "abhängige" Auswirkung auf weitere Entscheidungen zu Funktionen. Beispiel: Wird die Entscheidung für 'medication'' von 'permit' auf 'deny' gesetzt, so hat dieses keine weiteren Änderungen an Entscheidungen zur Folge. 

A_23766 - Consent Decision Management - Initialisierung der Widerspruchsinformation zur Nutzung von Funktionen der ePA

Das Consent Decision Management MUSS die Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte bei Erstellung eines neuen Aktenkontos oder bei Übernahme eines existierenden Aktenkontos einer älteren ePA-Version für alle Funktionen, gegen die der Versicherte nicht widersprochen hat mit der Entscheidung "kein Widerspruch erklärt" ("permit") initialisieren sowie alle Funktionen, gegen die der Versicherte widersprochen hat, mit "deny" initialisieren.
[<=]

A_24343 - Consent Decision Management - Speichern der Inhalte

Das Consent Decision Management MUSS die Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_23712 - Consent Decision Management - Übertrag der Widerspruchsinformation zur Nutzung von Funktionen der ePA für den Informationsdienst

Das Consent Decision Management MUSS die aktuellen Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte der Funktionsklassen

  • Versorgungsprozess ("healthCareProcess")
sofort im Anschluss an eine Änderung der Entscheidung im Consent Decision Management für die Abfrage durch den Information Service des Aktensystems ohne Nutzung der VAU und des SecureAdminStorageKeys verfügbar machen.
[<=]

A_24040 - Consent Decision Management - Periodischer Übertrag der Widerspruchsinformation zur Nutzung von Funktionen der ePA für den Informationsdienst

Das Consent Decision Management MUSS die aktuellen Entscheidungen zu Widersprüchen bezüglich der Nutzung von Funktionen der elektronischen Patientenakte der Funktionsklassen

  • Versorgungsprozess ("healthCareProcess")
bei jedem Start der VAU (des VAU-Kanals) für die Abfrage durch den Information Service des Aktensystems ohne Nutzung der VAU und des SecureAdminStorageKeys verfügbar machen, unabhängig von einer Änderung der Entscheidungen zu den Widersprüchen. [<=]

Clients der Ombudsstelle und aus der Umgebung des Versicherten nutzen das Consent Decision Management über die Operationen der Schnittstelle I_Consent_Decision_Management. Clients aus der Umgebung der LEI und der E-Rezept-Fachdienst nutzen für die schnelle Abfrage die Operation der Schnittstelle I_Information_Service.

A_23824 - Aktensystem - Realisierung der Schnittstelle I_Consent_Decision_Management

Das Aktensystem MUSS die Operationen der Schnittstelle I_Consent_Decision_Management gemäß [I_Consent_Decision_Management] umsetzen. [<=]

A_23919 - Consent Decision Management - unveränderte Übernahme der Widerspruchsentscheidung

Das Consent Decision Management MUSS die über Operationen der Schnittstellen des Consent Managements übermittelten Entscheidungen (consent decisions) zu widerspruchsfähigen Funktionen der ePA in das Aktenkonto übernehmen. Die Entscheidungen zu den in den Operationen nicht adressierten widerspruchsfähigen Funktionen MÜSSEN im Aktenkonto unverändert bleiben. [<=]

A_24844 - Consent Decision Management - Information über Änderungen der Widerspruchsinformation

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung einer Widerspruchsinformation, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass Widerspruchsinformationen geändert wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_24055 - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Widersprüchen

Das Consent Decision Management MUSS Bei Änderungen von Entscheidungen zu den widerspruchsfähigen Funktionen der ePA jeweils einen Protokolleintrag gemäß A_24704* erzeugen. Für die Wertebelegung ist A_23874* zu berücksichtigen und die Protokollstruktur entsprechend zu belegen:

Tabelle 12: Consent Decision Management Protokollierung - Widersprüche für Funktionen der ePA

 Strukturelement Wert Erläuterung
AuditEvent.action U Update
AuditEvent.entity.name
 
"ConsentDecision"
Eintrag protokolliert eine Widerspruchsentscheidung
AuditEvent.entity.detail




type value[x]
"ConsentClass"
<consent class"
z.b. "healthcareProcess"
"ConsentClassId" <consent class Id> z.b. "medication"
"ConsentDecision" <consent decision> "deny" oder "permit"
[<=]

Hinweis: Die initiale Entscheidung zu den Widersprüchen bei Anlage eines Aktenkontos wird nicht protokolliert, dieses ist implizit mit der Protokollierung der Aktivierung bzw. Migration abgedeckt. Die spezifische Protokollierung erfolgt für Folgeänderungen.

A_26293 - Consent Decision Management – Weiterleitung von Widersprüchen gegen die Sekundärdatennutzung durch das FDZ

Das Consent Decision Management MUSS die Information über einen erklärten Widerspruch die Sekundärdatennutzung durch das FDZ über den Data Submission Service an das FDZ weiterleiten. [<=]

3.8.2 Einschränkung der Verwendung von Daten auf bestimmte Sekundärnutzungszwecke

Wenn kein Widerspruch gegen die Sekundärdatennutzung durch das FDZ für das Aktenkonto erteilt wurde, kann durch den Versicherten oder einen Vertreter über das ePA FdV, bzw. durch die Ombudsstelle, die Verwendung der Daten auf die in § 303e Absatz 2 SGB V aufgeführten Sekundärnutzungszwecke im FDZ eingeschränkt werden.

Der initiale Zustand nach Aktivierung eines Aktenkontos ist für jeden Sekundärnutzungszweck "kein Widerspruch erteilt".

Eine Änderung der Widersprüche zu Verwendungszwecken führt dazu, dass diese Informationen an das Forschungsdatenzentrum Gesundheit übermittelt werden. Die Widersprüche des Versicherten in die Sekundärnutzungszwecke sind dort bindend für die Verarbeitung der übermittelten pseudonymisierten medizinischen Daten, siehe auch 3.20 Data Submission Service .

A_26286 - Consent Decision Management - Initialisierung der Sekundärnutzungszwecke

Das Consent Decision Management MUSS jeden in § 303e Absatz 2 SGB V aufgeführten Sekundärnutzungszweck der elektronischen Patientenakte bei Erstellung eines neuen Aktenkontos oder bei Übernahme eines existierenden Aktenkontos einer älteren ePA-Version mit der Entscheidung "kein Widerspruch erklärt" ("permit") initialisieren. [<=]

A_26287 - Consent Decision Management - Speichern der Entscheidungen zu Sekundärnutzungszwecken

Das Consent Decision Management MUSS die Entscheidungen zu Sekundärnutzungszwecken der elektronischen Patientenakte unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_26288 - Consent Decision Management - Übertragen der Entscheidungen zu Sekundärnutzungszwecken an das FDZ

Das Consent Decision Management MUSS die Entscheidungen zu Sekundärnutzungszwecken sofort im Anschluss an eine Änderung der Entscheidung im Consent Decision Management in das Paket zur Übermittlung von pseudonymisierten medizinischen Daten zu Sekundärnutzungszwecken an das FDZ aufnehmen. [<=]

A_26291 - Consent Decision Management - unveränderte Übernahme der Widerspruchsentscheidung

Das Consent Decision Management MUSS die über Operationen der Schnittstellen des Consent Managements [I_Consent_Decision_Management] übermittelten Entscheidungen zu Sekundärnutzungszwecken in das Aktenkonto übernehmen. [<=]

A_26292 - Consent Decision Management - Information über Änderungen der Entscheidungen zu Sekundärnutzungszwecken

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung der Entscheidungen zu Sekundärnutzungszwecken, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass Entscheidungen zu Sekundärnutzungszwecken geändert wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_26294 - Consent Decision Management – Weiterleitung von Widersprüchen gegen Sekundärnutzungszwecken an das FDZ

Das Consent Decision Management MUSS die Information über einen erklärten Widerspruch gegen Sekundärnutzungszwecke  über den Data Submission Service an das FDZ weiterleiten. [<=]

A_26310 - Consent Decision Management – Rücknahme des Widerspruchs gegen die Sekundärdatennutzung durch das FDZ

Falls ein Widerspruch gegen die Sekundärdatennutzung durch das FDZ zurückgenommen wird MUSS das Consent Decision Management die Entscheidungen zu Sekundärnutzungszwecken über den Data Submission Service an das FDZ weiterleiten. [<=]

A_26308 - Consent Decision Management – Protokollierung geänderter Entscheidungen zu Sekundärnutzungszwecken

Das Consent Decision Management MUSS bei jeder Änderung einer Widerspruchsentscheidung zur Verwendung der an das Forschungsdatenzentrum übermittelten Daten für bestimmte Sekundärnutzungszwecke einen Protokolleintrag gemäß A_24704* erzeugen.

Tabelle 13: Consent Decision Management Protokollierung - Widersprüche zu Sekundärnutzungszwecken

 Strukturelement Wert Erläuterung
AuditEvent.action U Update
AuditEvent.entity.name
 
"DataUsagePurpose"
Eintrag protokolliert eine Widerspruchsentscheidung zu Sekundärnutzungszwecken
AuditEvent.entity.detail




type value[x] Liste aller geänderten Widersprüche zu Sekundärnutzungszwecken
"Purpose"
<purpose Id>
Auswahl aus <purpose Id> mit den Werten: [Purpose1, Purpose2, Purpose3, Purpose4, Purpose5, Purpose6, Purpose7, Purpose8, Purpose9, Purpose10]
"ConsentDecision" <consent decision> "deny" oder "permit"
[<=]

3.8.3 Einschränkung des Medication Service für bestimmte LEI (User Specific Deny Policy Medication)

Ein Versicherter bzw. Vertreter kann den Zugriff auf den Medication Service für bestimmte LEI innerhalb seines Aktenkontos einschränken und diese Einschränkung auch wieder zurücknehmen. Durch das Setzen einer LEI auf eine User Specific Deny Policy Medication wird jeder Zugriff dieser LEI auf den Medication Service für das Aktenkonto mit einem Fehler abgebrochen. Durch das Entfernen einer LEI von der User Specific Deny Policy Medication kann diese LEI Operationen des Medication Service (falls kein Widerspruch gegen "medication" vorliegt) wieder nutzen. 
Die User Specific Deny Policy Medication wird durch das Aktensystem für die in A_26406-* aufgeführten Nutzergruppen angewendet und durchgesetzt.

Der initiale Zustand nach Aktivierung eines Aktenkontos ist eine leere Liste.

A_26400 - Consent Decision Management - Initialisierung der User Specific Deny Policy Medication

Das Consent Decision Management MUSS für ein Aktenkonto eine User Specific Deny Policy Medication ohne initiale Einträge, bereitstellen und die Konfiguration der Einträge der Policy über die Schnittstelle I_Constraint_Management_Insurant gemäß [I_Constraint_Management_Insurant] ermöglichen. [<=]

A_26401 - Consent Decision Management - Speichern der Inhalte der User Specific Deny Policy Medication

Das Consent Decision Management MUSS Einträge aus der User Specific Deny Policy Medication unter Verwendung des SecureDataStorageKeys gesichert im Aktenkonto ablegen. [<=]

A_26403 - Consent Decision Management - Information über Änderungen der User Specific Deny Policy Medication

Das Consent Decision Management MUSS den Aktenkontoinhaber bei einer Änderung der Entscheidungen zu der User Specific Deny Policy Medication , sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, welche Änderungen der User Specific Deny Policy Medication vorgenommen wurden, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

A_26406 - Consent Decision Management - Policy für berechtigte Nutzergruppen und Nutzer

Das Consent Decision Management MUSS die Konfiguration der User Specific Deny Policy Medication auf die folgenden Nutzergruppen einschränken:

Nutzergruppe [professionOID] der User Specific Deny Policy Medication
oid_praxis_arzt
oid_krankenhaus
oid_institution-vorsorge-reha
oid_zahnarztpraxis
oid_öffentliche_apotheke
oid_praxis_psychotherapeut
oid_institution-pflege
oid_institution-geburtshilfe
oid_praxis-physiotherapeut
oid_institution-oegd
oid_institution-arbeitsmedizin
oid_diga
oid_praxis-ergotherapeut
oid_praxis-logopaede
oid_praxis-podologe
oid_praxis-ernaehrungstherapeut


[<=]

A_26405 - Consent Decision Management – Protokollierung geänderter Entscheidungen der User Specific Deny Policy Medication

Das Consent Decision Management MUSS für jede Änderung der User Specific Deny Policy Medication einen Protokolleintrag gemäß A_24704* erzeugen:

Tabelle 14: Consent Decision Management Protokollierung - User Specific Deny Policy Medication

 Strukturelement Wert Erläuterung
AuditEvent.action C, D Update
AuditEvent.entity.name
 
"UdpMedication"
Eintrag protokolliert eine Änderung der User Specific Deny Policy für Medication Service
AuditEvent.entity.detail




type value[x]
"UserId"
<Telematik-ID der LEI>
Telematik-ID der LEI, welche zur User Specific Deny Policy Medication hinzugefügt oder gelöscht wurde
"UserName" <displayName> Name der LEI, welche zur User Specific Deny Policy Medication hinzugefügt oder gelöscht wurde
[<=]

3.9 Entitlement Management

Befugnisse (Entitlements) werden individuell für jeden Nutzer des Aktenkontos erstellt (Versicherter, Vertreter, Leistungserbringerinstitutionen, Kostenträger, Ombudsstelle und Fachdienste). Eine erteilte Befugnis ist notwendige Voraussetzung für die Nutzung des Aktenkontos und zum internen Bezug des Datenpersistierungsschlüssels (SecureDataStorageKey) für den Zugriff auf die Dokumenten- und Datenverwaltung.

Eine Befugnis enthält folgende Informationen:

A_23734-01 - Entitlement Management - Definition einer Befugnis

Das Entitlement Management MUSS für eine individuelle Befugnis die folgenden Daten nutzen und verwalten: 

Tabelle 15: Inhalt einer Befugnis

Element Inhalt Anmerkung signiertes
Element (*)
Identifier des Aktenkontos
(insurantId)
KVNR des Aktenkontos, für welches die Befugnis ausgestellt ist ja
Identifier des befugten Nutzers
(actorId)
Telematik-ID oder KVNR ja
Name des befugten Nutzers
(displayName)
Name der Institution, des Nutzers nein
Rolle des Nutzers
(oid)
OID der Nutzerrolle (professionOID) nein
Ende der Gültigkeit
(validTo)
Datum und Zeitpunkt
(letzter Tag der Gültigkeit, d.h. eine heutige Befugnisvergabe für 3 Tage setzt für validTo das Datum von übermorgen (aktueller Tag + 2 Tage). aktueller Tag ist inklusiv zu bewerten).
Wird gemäß [RFC3339] mit Zeitzone UTC (z.B.: 2024-04-12T22:59:59Z) bzw. Zeitzonen-Offset (z.B.: 2024-04-12T23:59:59+01:00) gespeichert. 
Eine unbegrenzt gültige Befugnis erhält das Datum 9999-12-31T00:00:00Z. .
Die Befugnisdauer der Befugnisse (Karte stecken), die durch das Aktensystem erstellt werden, werden auf das Ende des resultierenden Tages der aktuell gültigen Zeitzone in Deutschland gesetzt, z.B.: 2024-04-12T23:59:59+01:00.
Wird durch den Versicherten oder einen Vertreter oder das Entitlement Management gesetzt.
ja
Beginn der Gültigkeit, Ausstellungszeitpunkt
(issued-at)
Datum und Zeitpunkt Wird durch das Entitlement Management gesetzt. nein
Identifier des Erstellers
(issued-actorId)
Telematik-ID oder
KVNR
Wird durch das Entitlement Management gesetzt. nein
Name des Erstellers
(issued-displayName)
Name der Institution, des Nutzers Wird durch das Entitlement Management gesetzt. nein
[<=]

Hinweis: Ein Nutzer ist der Adressat, für den die Befugnis ausgestellt wird. Der Ersteller ist der Nutzer, welcher die Befugnisausstellung veranlasst hat. Die Bezeichner in () sind die Bezeichner in den Schnittstellenbeschreibungen.

Hinweis (*): A_23734 definiert eine "vollständige" Befugnis, welche auch Daten enthält, die für eine Prüfung einer gültigen Befugnis im Kontext einer Schnittstellenoperation nicht notwendig sind. Für diesen Zweck wird nur der (HSM-) signierte Anteil als Ergebnis einer Befugnisverifikation verwendet (signiertes Element = ja). Eine gespeicherte Befugnis enthält jedoch alle Elemente für eine qualifizierte Verwaltung der Befugnisse durch einen Versicherten oder Vertreter. 

Hinweis: Befugnisse können durch das Aktensystem selbst (initiale Befugnisse), durch den Versicherten oder einen befugten Vertreter unter Verwendung eines ePA-FdV oder durch eine Leistungserbringerinstitution in einer Behandlungssituation erstellt werden.

Eine Befugnis kann nur für Nutzer und Nutzergruppen mit bestimmter Rolle erteilt werden. Nutzergruppen mit abweichenden Rollen können nicht befugt werden und erhalten keinen Zugriff auf das Aktenkonto.

Erfolgt die Befugniserteilung durch eine Leistungserbringerinstitution in einer Behandlungssituation, wird eine vorgegebene Gültigkeitsdauer der Rolle des Befugten entsprechend durch das Entitlement Management vergeben. Ein Versicherter oder ein befugter Vertreter kann den Gültigkeitszeitraum frei wählen (ausgenommen Vertreterbefugnisse).

A_23941-01 - Entitlement Management - Erteilung von Befugnissen für berechtigte Nutzergruppen und Nutzer

Das Entitlement Management MUSS die Erteilung von Befugnissen in der jeweiligen Umgebung auf die folgenden Nutzergruppen und Nutzer einschränken:

Tabelle 16: Befugnisse für berechtigte Nutzergruppen und Nutzer

professionOID / Nutzergruppe und Nutzer Umgebung Standard-Befugnisdauer [Tage] Befugnisdauer FdV [Tage]
LEI FdV AS durch das Entitlement Management bei Erteilung der Befugnis aus der Umgebung LEI
bei Erteilung der Befugnis aus der Umgebung FdV
oid_praxis_arzt x x - 90 var
oid_krankenhaus x x - 90 var
oid_institution-vorsorge-reha x x - 90 var
oid_zahnarztpraxis x x - 90 var
oid_öffentliche_apotheke x x - 3 var
oid_praxis_psychotherapeut x x - 90 var
oid_institution-pflege x x - 90 var
oid_institution-geburtshilfe x x - 90 var
oid_praxis-physiotherapeut x x - 90 var
oid_praxis-ergotherapeut x x - 90 var
oid_praxis-logopaede x x - 90 var
oid_praxis-podologe x x - 90 var
oid_praxis-ernaehrungstherapeut x x - 90 var
oid_institution-oegd x x - 3 var
oid_institution-arbeitsmedizin x x - 3 var
oid_kostentraeger - - x (statisch) - -
oid_ombudsstelle - - x (statisch) - -
oid_erp-vau (E-Rezept vertrauenswürdige Ausführungsumgebung) - - x (statisch) - -
oid_versicherter (Versicherter) - - x (statisch) - -
oid_versicherter (Vertreter) - x - - dauerhaft
oid_diga - x - - dauerhaft

Hinweis:
'x' bedeutet: diese Nutzer/Nutzergruppe kann aus der angegebenen Umgebung befugt werden 
'-' bedeutet: diese Nutzer/Nutzergruppe  kann aus der angegebenen Umgebung nicht befugt werden

LEI = Leistungserbringerorganisation mit Nachweis der Behandlungssituation über VSDM-Prüfungsnachweis (Prüfziffer),
FdV = Versicherter oder Vertreter,
KTR = Kostenträger
AS = Aktensystem (systemseitig erteilte Befugnisse)
Tage = Gültigkeit in Tagen: angegebener Wert ist einschließlich aktuellem Datum, z. B. 90 Tage bedeutet aktuelles Datum + 89 Tage.
dauerhaft = Befugnis unbegrenzt gültig (Enddatum = 9999-12-31)
statisch = Gültigkeit analog 'dauerhaft', Befugnis ist implizit vorhanden.
var = Gültigkeitsdauer von 1 Tag bis dauerhaft in jeweils ganzen Tagen [<=]

Befugnisse werden durch das Entitlement Management mit dem SecureAdminStorageKey verschlüsselt und im Aktenkonto gesichert abgelegt.

Einzelne Nutzer können durch den Versicherten, einen befugten Vertreter oder die Ombudsstelle explizit von der Befugnisvergabe ausgeschlossen sein (siehe 3.9.4 Befugnisausschluss (Blocked User Policy) ). Eine Befugniserstellung ist dann weder für Leistungserbringerinstitutionen in einer Behandlungssituation, noch durch den Versicherten oder einen Vertreter möglich.

Die Befugnisse für den Versicherten und den E-Rezept-Fachdienst werden dabei nicht persistiert. Diese Befugnisse werden als implizit vorhanden und gültig angenommen.

Eine Besonderheit stellt hierbei eine Befugnis EU-Zugriff dar. Es gibt zu einem Zeitpunkt für ein Aktenkonto maximal eine Befugnis EU-Zugriff. Die Dauer dieser Befugnis wird durch das Aktensystem festgelegt und beträgt 1 Stunde. Das Ende der Gültigkeit (validTo) wird ermittelt vom Ausstellungszeitpunkt + 1 Stunde.

A_26167 - Entitlement Management (EU) - Erteilung der Befugnis EU-Zugriff

Das Entitlement Management MUSS die Erteilung einer Befugnis EU-Zugriff in der jeweiligen Umgebung zusätzlich zu A_23941-* auf die folgenden Nutzergruppen und Nutzer einschränken:

Tabelle 17: Befugnisse EU-Zugriff für berechtigte Nutzergruppen und Nutzer

professionOID / Nutzergruppe und Nutzer Umgebung Standard-Befugnisdauer Befugnisdauer FdV
LEI FdV AS durch das Entitlement Management bei Erteilung der Befugnis aus der Umgebung LEI
bei Erteilung der Befugnis aus der Umgebung FdV
oid_ncpeh - x - - 1 Stunde;
wird durchgesetzt durch das Aktensystem
Hinweis:
'x' bedeutet: diese Nutzer/Nutzergruppe kann aus der angegebenen Umgebung befugt werden 
'-' bedeutet: diese Nutzer/Nutzergruppe  kann aus der angegebenen Umgebung nicht befugt werden

LEI = Leistungserbringerorganisation mit Nachweis der Behandlungssituation über VSDM-Prüfungsnachweis (Prüfziffer),
FdV = Versicherter oder Vertreter,
AS = Aktensystem (systemseitig erteilte Befugnisse) [<=]

A_24371 - Entitlement Management - Verschlüsselung der Befugnisse

Das Entitlement Management MUSS Befugnisse mit dem versichertenindividuellen SecureAdminStorageKey verschlüsseln und im Aktenkonto persistieren. [<=]

A_24372 - Entitlement Management - Keine persistente Ablage unverschlüsselter Befugnisse

Das Entitlement Management  MUSS sicherstellen, dass Befugnisse ausschließlich verschlüsselt unter Verwendung des versichertenindividuellen SecureAdminStorageKey im Aktenkonto gespeichert werden. [<=]

A_24687 - Entitlement Management - Keine Speicherung oder Verwendung nicht verifizierter Befugnisse

Das Entitlement Management  MUSS sicherstellen, dass ausschließlich Befugnisse persistiert oder für eine Befugnisprüfung verwendet werden, die erfolgreich durch das HSM unter Verwendung der adäquaten Regeln 'rr1 - rr4' gemäß A_24573* befugnisverifiziert sind. [<=]

A_23842 - Entitlement Management - Eindeutigkeit der Befugnisse im Befugniskontext

Das Entitlement Management MUSS sicherstellen, dass im Befugniskontext keine zwei oder mehr Befugnisse existieren, die als Identifier des befugten Nutzers die gleiche Identifikation (actorId) aufweisen. [<=]

A_24785 - Entitlement Management - VSDM-Prüfungsnachweis kann höchstens einmal genutzt werden

Das Entitlement Management MUSS sicherstellen, dass ein VSDM-Prüfungsnachweis (Prüfziffer) höchstens einmal zur Registrierung einer Befugnis genutzt werden kann. [<=]

ePA-Clients nutzen zur Befugnisvergabe die Operationen der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management].
Die initialen Befugnisse des Aktenkontos werden auf organisatorischem Weg direkt im Aktenkonto erstellt.

A_24506 - Entitlement Management- Realisierung der Schnittstelle I_Entitlement_Management

Das Entitlement Management MUSS die Operationen der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] umsetzen. [<=]

A_26168 - Entitlement Management (EU)- Realisierung der Schnittstelle I_Entitlement_Management_EU

Das Entitlement Management MUSS die Operationen der Schnittstelle I_Entitlement_Management_EU gemäß [I_Entitlement_Management_EU] umsetzen. [<=]

A_24987-01 - Entitlement Management - Protokolleinträge für Zugriffe auf das Entitlement Management

Das Entitlement Management MUSS für das Erteilen und Entziehen von Befugnissen und das Setzen und Löschen von Befugnisausschlüssen jeweils einen Protokolleintrag gemäß A_24704 erzeugen. Dabei ist folgende Wertebelegung zu berücksichtigen:

Tabelle 18: Entitlement Management Protokollierung

 Strukturelement Wert Erläuterung
AuditEvent.type "rest"
AuditEvent.action C, D, U ein Code aus den genannten, je nach Operation
AuditEvent.entity.name "UserBlocking" Setzen und Löschen von Befugnisausschlüssen
"EntitlementManagement" Erteilen oder Entziehen von Befugnissen
AuditEvent.entity.detail type value[x]
"blockedUserName" <Name der LEI> Name der LEI, für die der Befugnisausschluss gesetzt bzw. der Ausschluss zurückgenommen wurde
"blockedUserId" <Telematik-ID der LEI> Telematik-ID der LEI, für die der Befugnisausschluss gesetzt bzw. der Ausschluss zurückgenommen wurde
"UserName" <Name der Institution oder des Vertreters>
Name der Institution oder des Nutzers für die eine Befugnis erteilt oder gelöscht wurden
"UserId" <Identifier der Institution oder des Vertreters> ID der Institution oder des Nutzers für die eine Befugnis erteilt oder gelöscht wurden
"entitledValidTo" <Endzeitpunkt der Gültigkeit der Befugnis>
Angabe des Endes einer erteilten Befugnis, Format gemäß [RFC3339] YYYY-MM-DDThh:mm:ssZ oder YYYY-MM-DDThh:mm:ss+/-time zone

[<=]

Hinweis: Ein Update ("U") eines Entitlements liegt vor, wenn ein existierendes Entitlement aufgrund des längeren Gültigkeitszeitraums eines neuen Entitlements überschrieben wird.

3.9.1 Initiale Befugnisse (static Entitlements)

Einige grundsätzlich notwendige Befugnisse sind zum Zeitpunkt der Aktivierung eines Aktenkontos verfügbar.

Zu diesen initialen Befugnissen gehören die Befugnisse für den Versicherten, den E-Rezept-Fachdienst, den Kostenträger und die Ombudsstelle. Diese Befugnisse müssen in der Phase der Initialisierung eines Aktenkontos durch das Aktensystem erstellt werden.

Diese Befugnisse sind dauerhaft gültig und unveränderbar und können nicht gelöscht werden.

A_24145 - Entitlement Management – Implizite initiale (statische) Befugnisse

Das Entitlement Management MUSS sicherstellen, dass der Versicherte (KVNR des Akteninhabers, oid_versicherter), und der E-Rezept-Fachdienst (registrierte Telematik-ID, oid_erp-vau) dauerhaft den versichertenindividuellen SecureDataStorageKey beziehen können und Zugriff auf die Dokumenten- und Datenverwaltung erhalten. Die Befugnisse MÜSSEN den Vorgaben der folgenden Tabelle entsprechen:

Element Versicherter E-Rezept-Fachdienst
Identifier des befugten Nutzers
(actorId)
KVNR des Versicherten (Aktenkontoinhaber) Telematik-ID der E-Rezept vertrauenswürdigen Ausführungsumgebung
Name des befugten Nutzers
(displayName)
Name des Versicherten Name/ Bezeichnung des E-Rezept-Fachdienstes oder "Fachdienst E-Rezept"
Rolle des Nutzers
(oid)
oid_versicherter oid_erp-vau 
Ende der Gültigkeit
(validTo)
9999-12-31 9999-12-31
[<=]

A_24374 - Entitlement Management – Signierte initiale (statische) Befugnisse

Das Entitlement Management MUSS sicherstellen, dass für den Kostenträger und die Ombudsstelle gültige Befugnisse mit unbegrenzter Gültigkeitsdauer zum Zeitpunkt der Aktivierung des Aktenkontos gemäß der Vorgaben der folgenden Tabelle vorliegen:

Element Kostenträger Ombudsstelle
Identifier des Aktenkontos
(insurantid) 
KVNR des Versicherten KVNR des Versicherten
Identifier des befugten Nutzers
(actorId)
Telematik-ID des Kostenträgers  Telematik-ID der Ombudsstelle
Name des befugten Nutzers
(displayName)
Name des Kostenträgers Name/ Bezeichnung der Ombudsstelle
Rolle des Nutzers
(oid)
oid_kostentraeger oid_ombudsstelle
Ende der Gültigkeit
(validTo)
9999-12-31 9999-12-31
[<=]

A_24688-01 - Entitlement Management – Befugnisverifikation signierter initialer Befugnisse

Das Entitlement Management MUSS sicherstellen, dass die initialen, signierten Befugnisse des Kostenträgers und der Ombudsstelle spätestens beim ersten Zugriff auf das Aktenkonto durch das HSM unter Verwendung der Regel 'rr4' gemäß A_24573* befugnisverifiziert sind. [<=]

A_24533 - Entitlement Management - Keine Änderung statischer Befugnisse

Das Entitlement Management MUSS sicherstellen, dass die dauerhaften Befugnisse des Versicherten, des E-Rezept-Fachdiensts, des Kostenträgers und der Ombudsstelle nicht verändert oder gelöscht werden können. [<=]

A_24784 - Entitlement Management - Höchstens eine Befugnis für KTR und Ombudsstelle pro Aktenkonto

Das Entitlement Management MUSS sicherstellen, dass in einem Aktenkonto höchstens eine Befugnis für einen Kostenträger und höchstens eine Befugnis für eine Ombudsstelle hinterlegt ist. [<=]

A_24955 - Entitlement Management - Befugnis für KTR und Ombudsstelle nur bei Anlage und betreiberinterner Anbieterwechsel

Das Entitlement Management MUSS sicherstellen, dass eine signierte Befugnis des Kostenträgers und eine signierte Befugnis der Ombudsstelle ausschließlich bei einer Anlage eines Aktenkontos (Initialisierung) oder bei einem betreiberinternen Anbieterwechsel in die Befugnisse des Aktenkontos aufgenommen werden.
[<=]

3.9.2 Erstellen einer Befugnis durch Clients

Die Anforderung zur Vergabe einer neuen Befugnis erfolgt durch die Clients der ePA. Bei einer Befugnisvergabe aus der Umgebung der Leistungserbringer ist dieses das Primärsystem (PS), aus der Umgebung des Versicherten ist es das ePA-FdV.

Clients verwenden zur Befugnisvergabe signierte JSON Web Token (JWS). Das Token wird zur Verifikation an das HSM übergeben. Als Ergebnis der HSM Verarbeitung liegt eine bestätigte, CMAC gesicherte Befugnis mit den Elementen actorId (Identifier des zu befugenden Nutzers), kvnr (AktenkontoId) und validTo (Gültigkeitszeitraum) für die spätere Befugnisprüfung vor. Das HSM Ergebnis wird mit den weiteren Daten gemäß A_23734* (oid, displayName, issued-*) ergänzt und gemäß A_24371* mit dem SecureAdminStorageKey gesichert im Aktenkonto abgelegt. 

3.9.2.1 Befugnisvergabe durch ein ePA-FdV

Ein ePA-FdV muss für die Befugnisvergabe ein JWS gemäß folgender Vorgabe erstellen.

A_24587-01 - Entitlement Management - Befugnis durch ein ePA-FdV

Das Entitlement Management MUSS sicherstellen, dass die Befugnisvergabe durch ePA-FdV über die Schnittstelle I_Entitlement_Management durch Verwendung eines gültig signierten JWT mit den dargestellten Mindest-Inhalten erfolgt:

Befugnis Claim Name Claim Beispiel
Protected Header
"typ" "JWT"
"alg" "ES256"
"x5c" Signaturzertifikat C.CH.SIG
Payload
"iat" Zeitstempel Ausgabezeitpunkt
"exp" Verfalldatum, = "iat" + 20 min
"insurantId" KVNR des Aktenkontos A123456789
"actorId" Identifier (Telematik-id oder KVNR) 3-883110000092471
"oid" professionOid  1.2.276.0.76.4.54
"displayName" Name des Befugten Test-Apotheke
"validTo" Ende der Gültigkeit,
(Bei unbegrenzter Gültigkeit ist 9999-12-31T00:00:00Z zu verwenden.)
gemäß [RFC3339], z.B. 2025-06-30T21:59:59Z oder 2025-06-30T23:59:59+02:00
[<=]

Sollte der öffentliche Schlüssel im Signaturzertifikat zu "x5c" auf der ECC-Kurve "brainpoolP256r1 basieren, so soll der Wert "ES256" (JWS-Parameters "alg") im Kontext der Befugnisvergabe auch für diese Kurve gelten (also nicht nur für P-256). Die Signatur und Kodierung des JWT ist gemäß [RFC7515] zu erstellen.

Hinweis zu A_24587*: Im Falle der Befugnisvergabe für einen NCPeH (EU-Zugriff, "oid" == "oid_ncpeh") wird durch das Aktensystem sichergestellt, dass die vorgeschriebene Gültigkeitsdauer für derartige Befugnisse angewendet wird. Dieses erfolgt durch die Befugnisverifikation gemäß Regel "rr1" im HSM. Die Angabe eines Gültigkeitsendes im "validTo"-Element des JWT wird daher für diesen Fall ignoriert, das Element selbst muss jedoch vorhanden sein.

A_24689 - Entitlement Management - Befugnisverifikation einer Befugnis durch ein ePA-FdV

Das Entitlement Management MUSS für ein signiertes JWT zur Befugnisvergabe durch ein ePA-FdV unter Verwendung der Regeln 'rr1' (Befugnisvergabe durch den Versicherten) bzw. 'rr2' (Befugnisvergabe durch einen Vertreter) des HSM eine Befugnisverifikation durchführen. [<=]

A_24535 - Entitlement Management - Befugnisse für Vertreter

Das Entitlement Management MUSS sicherstellen, dass Befugnisse für Vertreter (actorId = KVNR) ausschließlich durch den Versicherten erstellt oder gelöscht werden können. [<=]

A_24536 - Entitlement Management - Gültigkeitsdauer der Befugnisse für Vertreter

Das Entitlement Management MUSS sicherstellen, dass Befugnisse für Vertreter (actorId = KVNR) ausschließlich mit einer unbegrenzten Gültigkeit erstellt werden. [<=]

A_24754 - Entitlement Management - E-Mail-Adresse des Vertreters

Das Entitlement Management MUSS sicherstellen, dass bei Befugnissen für Vertreter (actorId = KVNR) eine E-Mail-Adresse des Vertreters für dessen Benachrichtigung angegeben wird. [<=]

Die in A_24754 angegebene E-Mail-Adresse wird ausschließlich zur Benachrichtigung des Vertreters über die eingestellte Befugnis verwendet (vgl. A_24755-*), jedoch nicht für die Geräteregistrierung. Um eine Vertretung wahrnehmen zu können und hierfür Geräte zu registrieren, muss der Vertreter in seinem Home-AS eine E-Mail-Adresse hinterlegt haben.

A_24755-01 - Entitlement Management - Benachrichtigung des Vertreters bei Befugnisserstellung

Das Entitlement Management MUSS im Anschluss an die erfolgreiche, neue Befugniserstellung für einen Vertreter eine E-Mail an die E-Mail-Adresse des Vertreters senden, die diesen über die Befugniserstellung für das Aktenkonto des Versicherten geeignet informiert. In der Nachricht MUSS der Name des Versicherten enthalten sein und welche Art von personenbezogenen Daten vom Vertreter im Rahmen der Vertreterberechtigung im ePA-Aktensystem verarbeitet werden, wie der Vertreter eine Vertreterberechtigung widerrufen kann und gegenüber wem er seine datenschutzrechtlichen Betroffenenrechte wahrnehmen kann. [<=]

Hinweis: Unter Art der personenbezogenen Daten ist z.B. „Krankenversichertennummer, Name und E-Mail-Adresse“ gemeint, aber nicht die tatsächliche KVNR des Vertreters, der tatsächliche Name oder die tatsächliche E-Mail-Adresse.

3.9.2.2 Befugnisvergabe durch ein Primärsystem

Ein Primärsystem muss für die Befugnisvergabe ein JWS gemäß folgender Vorgabe erstellen.

A_24590 - Entitlement Management - Befugnis durch ein Primärsystem

Das Entitlement Management MUSS sicherstellen, dass die Befugnisvergabe durch ein Primärsystem über die Schnittstelle I_Entitlement_Management durch Verwendung eines gültig signierten JWT mit den dargestellten Mindest-Inhalten erfolgt:

Befugnis Claim Name Claim
Protected Header
"typ" "JWT"
"alg" "ES256" oder "PS256"
"x5c" Signaturzertifikat C.HCI.AUT
Payload
"iat" Zeitstempel Ausgabezeitpunkt
"exp" Verfalldatum, = "iat" + 20 min
"auditEvidence" VSDM-Prüfziffer aus dem VSDM-Prüfungsnachweis
[<=]

Sollte der öffentliche Schlüssel im Signaturzertifikat zu "x5c" auf der ECC-Kurve "brainpoolP256r1 basieren, so soll der Wert "ES256" (JWS-Parameters "alg") im Kontext der Befugnisvergabe auch für diese Kurve gelten (also nicht nur für P-256). Die Signatur und Kodierung des JWT ist gemäß [RFC7515] zu erstellen.

A_25249 - Entitlement Management - Befugnisverifikation einer Befugnis durch ein Primärsystem

Das Entitlement Management MUSS für ein signiertes JWT zur Befugnisvergabe durch ein Primärsystem unter Verwendung der Regeln 'rr3' (Stecken der eGK in einer Leistungserbringerumgebung) des HSM eine Befugnisverifikation durchführen. [<=]

A_24537 - Entitlement Management - Standardgültigkeitsdauer für Befugnisse

Das Entitlement Management MUSS sicherstellen, dass neue Befugnisse, die unter Verwendung der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] erstellt werden, eine vorgegebene, rollenspezifische Befugnisdauer gemäß A_23941-* erhalten. [<=]

3.9.3 Löschen von Befugnissen

Erteilte Befugnisse werden grundsätzlich nach Erreichen des Endzeitpunkts ihrer Gültigkeit durch das Aktensystem gelöscht.

A_24504 - Entitlement Management - Löschen ungültiger Befugnisse

Das Entitlement Management MUSS vorhandene Befugnisse, deren Enddatum der Gültigkeit überschritten ist, unverzüglich aus dem Befugniskontext des Aktenkontos vollständig löschen. [<=]

Das explizite Löschen von Befugnissen innerhalb ihres Gültigkeitszeitraums kann ausschließlich durch den Versicherten oder einen Vertreter mittels eines ePA-FdV erfolgen. Es können alle erteilten Befugnisse gelöscht werden, ausgenommen die initialen Befugnisse gemäß 3.9.1 Initiale Befugnisse (static Entitlements) .

Für das Löschen von Befugnissen durch einen Vertreter gilt darüber hinaus folgende Einschränkung:

A_25246 - Entitlement Management - Löschen von Befugnissen durch einen Vertreter

Das Entitlement Management MUSS sicherstellen, dass eine erteilte Befugnis für einen Vertreter (actorId der Befugnis == KVNR) durch einen Vertreter nur dann gelöscht werden kann, wenn die KVNR des löschenden Vertreters der KVNR der actorId der zu löschenden Befugnis entspricht. [<=]

Hinweis: Ein Vertreter darf nur seine eigene Befugnis löschen, nicht aber die Befugnis weiterer Vertreter.

A_25269 - Entitlement Management - Benachrichtigung des Versicherten bei Löschen einer Vertreterbefugnis durch Vertreter

Falls ein Vertreter seine eigene Vertreterbefugnis löscht MUSS das Entitlement Management für den Fall, dass für den Versicherten mindestens eine E-Mail-Adresse hinterlegt ist, den Versicherten über das Löschen der Vertreterbefugnis an alle seine hinterlegten E-Mail-Adressen informieren. [<=]

3.9.4 Befugnisausschluss (Blocked User Policy)

Das Entitlement Management erlaubt die Verwaltung von Widersprüchen des Versicherten oder eines Vertreters gegen die Nutzung des Aktenkontos durch spezifische Leistungserbringerinstitutionen.

Ist ein Widerspruch gegen einen bestimmten Nutzer hinterlegt, so kann für diesen keine Befugnis erstellt werden, bis dieser Widerspruch zurückgenommen wird.

Die Umsetzung dieser Widerspruchsverwaltung bzw. des Befugnisausschlusses erfolgt durch eine Policy (Blocked User Policy). Die Konfiguration dieser Policy obliegt dem Versicherten oder einem befugten Vertreter mittels ePA-FdV oder der Ombudsstelle. Einträge können der Policy hinzugefügt oder entfernt werden. Zum Zeitpunkt der Erstellung des Aktenkontos enthält die Blocked User Policy keine Einträge.

Ein Eintrag in der Policy referenziert einen bestimmten Nutzer über seinen Identifier (Telematik-Id). Die Menge der Einträge ist nicht limitiert.

Jeder Eintrag der Blocked User Policy verhindert grundsätzlich die Erstellung einer Befugnis für den referenzierten Nutzer. Erfolgt der Widerspruch (Anlegen eines neuen Eintrags) bei bestehender Befugnis für den auszuschließenden Nutzer, wird die bestehende Befugnis gelöscht.

Bei Rücknahme eines Widerspruchs gegen die Nutzung des Aktenkontos für eine bestimmte Leistungserbringerinstitution wird der entsprechende Eintrag der Policy gelöscht. Anschließend kann dieser Nutzer befugt werden.

Ein Widerspruch gegen die Nutzung des Aktenkontos kann nur für Nutzer der folgenden Nutzergruppen erfolgen.

A_24463-01 - Entitlement Management - zulässige Rollen für den Widerspruch gegen die Nutzung durch eine Leistungserbringerinstitution

Das Entitlement Management  MUSS den Widerspruch gegen die Nutzung durch eine Leistungserbringerinstitution ausschließlich für Nutzer der folgenden Nutzergruppen zulassen:

professionOID / Nutzergruppe
oid_praxis_arzt
oid_krankenhaus
oid_institution-vorsorge-reha
oid_zahnarztpraxis
oid_öffentliche_apotheke
oid_praxis_psychotherapeut
oid_institution-pflege
oid_institution-geburtshilfe
oid_praxis-physiotherapeut
oid_praxis-ergotherapeut
oid_praxis-logopaede
oid_praxis-podologe
oid_praxis-ernaehrungstherapeut
oid_institution-oegd
oid_institution-arbeitsmedizin
[<=]

Ein Eintrag der Blocked User Policy enthält Angaben gemäß der folgenden Tabelle: (Beispiel)

Tabelle 19: Inhalt eines Blocked User Policy Eintrags

Element Inhalt Beispiel
actorId Telematik-Id 2-883110000099999
oid professionOID 1.2.276.0.76.4.5
displayName Name der Leistungserbringerinstitution Zahnarztpraxis Dr. Beispiel
at Zeitpunkt des Widerspruchs (wird durch das Entitlement Management gesetzt) 2025-01-01T12:00:00Z

A_25135 - Entitlement Management - Initialisierung der Blocked User Policy

Das Entitlement Management MUSS für ein Aktenkonto eine Blocked User Policy ohne initiale Einträge, bereitstellen und die Konfiguration der Einträge der Policies über die Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] ermöglichen. [<=]

A_24514 - Entitlement Management - Keine Befugnis für von einer Befugnis ausgeschlossene Nutzer

Das Entitlement Management  MUSS sicherstellen, dass für keinen durch einen Eintrag der Blocked User Policy referenzierten Nutzer eine Befugnis existiert oder erstellt werden kann. [<=]

A_24515 - Entitlement Management- Verschlüsselung der Einträge der Blocked User Policy

Das Entitlement Management MUSS Einträge der Blocked User Policy mit dem Befugnispersistierungsschlüssel (SecureAdminStorageKey) verschlüsseln und im Aktenkonto persistieren. [<=]

Die Konfiguration der Blocked User Policy erfolgt über die Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] durch ein ePA-FdV bzw. durch die Ombudsstelle.

A_24965 - Entitlement Management - Information über Änderungen der Blocked User Policy

Das Entitlement Management MUSS den Aktenkontoinhaber bei einer Änderung der Blocked User Policy, sofern eine E-Mail-Adresse vorliegt, mit einer E-Mail darüber informieren, dass ein Befugnisausschluss geändert wurde, wann die Änderung erfolgte und darauf hinweisen, dass nähere Informationen zur Änderung im Protokoll zu finden sind. [<=]

3.10 Legal Policy

Die Legal Policy enthält die gesetzlich verbindlichen Regelungen der Zugriffsrechte bzgl. der Berufsgruppen und Datenkategorien gemäß § 341 Absatz 2 SGB V.

Für die Datenkategorien sind die grundsätzlichen Zugriffsrechte der Zugriffsoperationen (CRUD - create, read, update, delete) vorgegeben. Diese Zugriffsrechte wirken ausnahmslos für jeden befugten Nutzer.

Beispiele sind:

  • Apotheker haben keinen Zugriff auf das Zahnbonusheft der Datenkategorie "dental").
  • Kostenträger können Dokumente lediglich einstellen, also Dokumente weder lesen noch löschen.

Die Legal Policy wird durch das Aktensystem durchgesetzt und ist jederzeit vorhanden. Die Konfiguration kann durch Clients oder Bestandteile des Aktensystems nicht verändert werden.

A_19303-20 - Legal Policy – gesetzlich vorgegebene Zugriffsrechte

Das Aktensystem MUSS alle in der folgenden Tabelle aufgeführten Regeln der Legal Policy bei jedem Zugriff auf Daten und Dienste des Aktenkontos durchsetzen.

Tabelle 20: Legal Policy

Kategorie Nutzergruppe
Technischer Identifier Med
Apo Pflege GH HME AM KTR OM DiGA eRP Ver
Medical Services (XDS Document Service)
Zugriffsrecht gemäß § 352 SGB V
reports CRUD R R R R R - - - - RD
emp  CRUD CRUD R R R R - - - - RD
emergency CRUD R R R R R - - - - RD
eab  CRUD R R R R R - - - - RD
dental
CRUD - R - - R - - - - RD
childsrecord RD R R RD R R - - - - RD
child
CRUD R R CRUD R R - - - - RD (CU (*))
pregnancy_childbirth
CRUD R R CRUD R R - - - - RD
vaccination
CRUD CRUD R R - CRUD - - - - RD
patient RD  R R R R R C - - - CRUD
receipt RD RD - R R R CU - - - RD
diga R R R R R R - - CU - RD
care CRUD R CRUD R R R - - - - RD
eau CRUD - - - - R - - - - RD
rehab CRUD - - - - - - - - - RD
transcripts CRUD - - - - - - - - - RD
other CRUD - - - - R - - - - RD
Medical Services (FHIR Data Service)
Zugriffsrecht
medication CRUD CRUD R R R R - - - CU R
Basic Services Zugriffsrecht
Consent Decisions - - - -