gemSpec_ePA_FdV_V2.0.0_Aend

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

Spezifikation ePA-Frontend des Versicherten

 

   

Version	12.520.0
Revision	618101830590
Stand	12.04.2023Wert nicht konfiguriert
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_ePA_FdV

Dokumenteninformation

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

Dokumenteninformation

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemüberblick

3 Systemkontext

3.1 Akteure und Rollen

3.2 Nachbarsysteme

3.2.1 Identität des Nutzers

4 Zerlegung des Produkttyps

5 Übergreifende Festlegungen

5.1 Datenschutz und Sicherheit

5.1.1 Anforderungen bei CC-Zertifizierung

5.1.2 Unterstützung von Audits2 Verwendete Standards

5.2 Verwendete Standards3 Integrating the Healthcare Enterprise IHE

5.3 Integrating the Healthcare Enterprise IHE4 Benutzeroberfläche

5.34.1 Policy DocumentsVisuelle Darstellung

5.4 Benutzeroberfläche.2 Benutzerführung

5.4.1 Visuelle Darstellung2.1 Technische Normen und Verordnungen zur Beachtung

5.4.2 Benutzerführung3 Anzeige von Dokumenten

5.4.2.1 Technische Normen und Verordnungen zur Beachtung4 Drucken und Speichern von Verwaltungs- und Inhaltsdaten

5.4.3 Anzeige von Dokumenten5 Sammlungen

5.4.4 Sammlungen6 Nutzungsvorgaben für IHE ITI XDS-Metadaten

5.4.56.1 Metadaten für einzustellende Dokumente

5.4.6 Konfiguration des ePA-Frontend des Versicherten.2 Metadaten für existierende Dokumente

6 Funktionsmerkmale5.4.7 Konfiguration des ePA-Frontend des Versicherten

65.1 Allgemein5 Bereitstellung für UX-Messdaten

6.1.1 Aktensession-Verwaltung Funktionsmerkmale

6.1.2 Kommunikation mit dem ePA-Aktensystem Allgemein

6.1.3 Sicherer Kanal zur Dokumentenverwaltung1 Kommunikation mit dem ePA-Aktensystem

6.1.4 Geräteautorisierung2 Sicherer Kanal zur Aktenkontoverwaltung

6.1.5 Zertifikatsprüfung3 Authentisierung

6.1.5.1 Vertrauensanker des TI-Vertrauensraum4 Geräteregistrierung

6.1.5.2 TSL-Behandlung Zertifikatsprüfung

6.1.5.3 Zertifikatsprüfung von Zertifikaten der TI6 Dokumente

6.1.5.4 Zertifikatsprüfung von Internet-Zertifikaten7 ePA-FdV für Desktop-Plattformen

6.1.6 Dokumente8 Anbindung an das Nationale Gesundheitsportal

6.1.7 Umschlüsselung der Dokumente9 Anbindung VZD-FHIR-Directory

6.1.7.1 Kryptographische Architektur der Dokumentenverschlüsselung10 Dokumente für den statischen Ordner "technical"

6.1.8 ePA-FdV für Desktop-Plattformen2 Implementation ePA-Anwendungsfälle im FdV

6.12.9 Freigabe von Dokumenten für Forschungszwecke1 Übergreifende Festlegungen

6.12.9.1 Einwilligung in die Datenfreigabe2 Fehlerbehandlung

6.1.9.2 Freigabe der Dokumente und Pseudonymisierung.3 Aktivitäten

6.12.9.3 Übermittlung der Daten an das Forschungsdatenzentrum.1 Authentisieren des Nutzers

6.12.93.4 Umfang und Aufzeichnung der Freigabe2 Leistungserbringerinstitution im Verzeichnisdienst der TI finden

6.12.93.5 Aktenumzug3 DiGA im Verzeichnisdienst der TI finden

6.12.10 Anbindung an das Nationale Gesundheitsportal4 Nutzerzugang ePA

6.12.11 Dokumente für den statischen Ordner "technical"4.1 Login User

6.2 Implementation ePA-Anwendungsfälle im FdV.4.2 Logout User

6.2.1 Übergreifende Festlegungen5 Aktenkontoverwaltung

6.2.2 Fehlerbehandlung5.1 Widersprüche für Funktionen der ePA verwalten

6.2.3 Aktivitäten5.2 Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI

6.2.3.1 Authentisieren des Nutzers6 Befugnisverwaltung

6.2.36.2 Authentisierungstoken erneuern1 Befugnisverwaltung für LEI

6.2.36.3 Dokumentenset in Dokumentenverwaltung hochladen2 Befugnisverwaltung für DiGA

6.2.36.4 Dokumentenset aus Dokumentenverwaltung herunterladen3 Vertretung einrichten

6.2.36.5 Dokumentenset in Dokumentenverwaltung löschen4 Vergebene Befugnisse anzeigen

6.2.3.6 Suche nach Dokumenten in Dokumentenverwaltung.5 Eingerichtete Vertretungen anzeigen

6.2.3.7 Vergebene Berechtigungen bestimmen7 Verbergen und Sichtbarmachen von Dokumenten

6.2.37.8 AuthorizationKey1 Kategorienbasiertes Verbergen von Dokumenten

6.2.37.8.1 Struktur AuthorizationKeyType2 Dokumentenspezifisches Verbergen von Dokumenten

6.2.3.8.2 Schlüsselableitung für Ver- und Entschlüsselung Medical Services

6.2.3.8.3 AuthorizationKey erstellen1 XDS Document Service

6.2.3.8.4 AuthorizationKey entschlüsseln1.1 Dokumente einstellen

6.2.38.9 Schlüsselmaterial aus ePA-Aktensystem laden1.2 Dokumente suchen

6.2.38.10 Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden1.3 Dokument herunterladen

6.2.38.11 Schlüsselmaterial im ePA-Aktensystem speichern1.4 Dokumente im Aktenkonto löschen

6.2.38.12 Schlüsselmaterial im ePA-Aktensystem ersetzen1.5 Metadaten von Dokumenten ändern

6.2.38.13 Schlüsselmaterial im ePA-Aktensystem löschen2 Medication Service

6.2.3.14 Leistungserbringerinstitution im Verzeichnisdienst der TI finden9 Protokollverwaltung

6.2.3.15 DiGA im Verzeichnisdienst der TI finden10 Geräteverwaltung

6.2.3.16 Suchanfrage Verzeichnisdienst der TI11 Migration der Akte von ePA 2.6 nach ePA 3.0

6.2.3.17 PIN-Eingabe für eGK durch Nutzer Testtreiber-Modul für ePA-Frontend des Versicherten

6.2.4 Nutzerzugang ePA7 Verteilungssicht

6.2.4.1 Login Aktensession8 Anhang A – Verzeichnisse

6.2.4.2 Logout Aktensession8.1 Abkürzungen

68.2.5 Aktenkontoverwaltung Glossar

6.2.5.1 Aktenkonto aktivieren8.3 Abbildungsverzeichnis

6.2.5.2 Anbieter wechseln8.4 Tabellenverzeichnis

68.2.5.3 Schließen einer Akte Referenzierte Dokumente

68.25.6 Umschlüsselung1 Dokumente der gematik

68.25.7 Berechtigungsverwaltung2 Weitere Dokumente

6.2.7.1 Spezifische Zugriffsregeln9 Anhang B - Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets

6.2.7.1.1 kategorienbasierte Berechtigung

6.2.7.1.2 Dokumentenspezifische Berechtigung

6.2.7.2 Vertretung einrichten

6.2.7.3 Berechtigung für Kostenträger vergeben

6.2.7.4 Vergebene Berechtigungen anzeigen

6.2.7.5 Eingerichtete Vertretungen anzeigen

6.2.7.6 Bestehende Berechtigungen verwalten

6.2.7.6.1 Berechtigung für LEI ändern

6.2.7.6.2 Berechtigung für LEI löschen

6.2.7.6.3 Berechtigung für Vertreter löschen

6.2.7.6.4 Berechtigung für Kostenträger löschen

6.2.7.7 Berechtigung für DiGA löschen

6.2.7.8 Berechtigungen für DiGA vergeben

6.2.8 Dokumentenverwaltung

6.2.8.1 Dokumente einstellen

6.2.8.2 Dokumente suchen

6.2.8.3 Dokument herunterladen

6.2.8.4 Dokumente im Aktenkonto löschen

6.2.9 Protokollverwaltung

6.2.9.1 Zugriffsprotokoll einsehen

6.2.10 Verwaltung eGK

6.2.10.1 PIN der eGK ändern

6.2.10.2 PIN der eGK entsperren

6.2.11 Geräteverwaltung

6.2.11.1 Benachrichtigungsadresse für Geräteautorisierung aktualisieren

6.2.11.2 Benachrichtigungsadressen abfragen

6.3 Realisierung der Leistungen der TI-Plattform

6.3.1 Transportschnittstelle für Kartenkommandos

6.3.1.1 Kartenterminals der Sicherheitsklasse 1

6.3.1.2 Kartenterminals der Sicherheitsklasse 2

6.3.1.3 Kartenterminals der Sicherheitsklasse 3

6.3.2 Schnittstelle für PIN-Operationen und Anbindung der eGK

6.4 Test-App FdV

7 Informationsmodell

8 Verteilungssicht

9 Anhang A – Verzeichnisse

9.1 Abkürzungenq

9.2 Glossar

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

9.5.2 Weitere Dokumente

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps ePA-Frontend des Versicherten.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Produkten des Frontend des Versicherten sowie an Hersteller und Anbieter von weiteren Produkttypen der Fachanwendung ePA.

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) festgelegt 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

Im Dokument wird spezifiziert, wie Schnittstellen benutzt werden, um fachliche Anwendungsfälle umzusetzen. Die Schnittstellen selbst werden in der Spezifikation desjenigen Produkttypen beschrieben, der die Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 9.5).

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

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID 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.

Die Spezifikation der durch den Produkttyp genutzten Interfaces erfolgt in der Spezifikation des Produkttypen, welcher das Interface anbietet. Eine Übersicht befindet sich in Kapitel "3.2 Nachbarsysteme".

2 Systemüberblick

Das ePA-Frontend des Versicherten (FdV) ist eine Anwendung, welche die für die Nutzung der ePA notwendigen Funktionalitäten bündelt und dezentrale Fachlogik der Fachanwendung ePA ausführt. Das FdV ermöglicht es Versicherten, ePA-Anwendungsfälle auszuführen.

Ausführungsumgebung des FdV ist ein Gerät des Versicherten (GdV), bspw. ein stationäres Gerät oder ein mobiles Endgerät. Es steht unter alleiniger Kontrolle des Versicherten. Dem Versicherten obliegt es, durch geeignete Maßnahmen die Sicherheit der Daten zu stärken.

Das FdV kann zusätzliche Funktionalitäten anbieten, die nicht der Fachanwendung ePA zugeordnet werden und somit nicht der Regelungshoheit der gematik unterliegen.

3 Systemkontext

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.

3.1 Akteure und Rollen

Im Systemkontext des FdV interagieren verschiedene Akteure (aktive Komponenten) in unterschiedlichen Rollen mit dem FdV.

Tabelle 1: TAB_FdV_101 – Akteure und Rollen

3.2 Nachbarsysteme

Die vom FdV direkt erreichbaren Produkttypen der TI sind

•   ePA-Aktensystem,

•   Signaturdienst und

•   eGK (G2 und höher).

•  Abbildung 1: Systemüberblick FdVVerzeichnisdienst FHIR-Directory

Der Signaturdienst bietet die Schnittstelle I_Remote_Sign_Operations für Signaturen mittels der alternativen kryptographischen Versichertenidentität an. Siehe [gemSpec_SigD].

In TAB_FdV_102der folgenden Tabelle sind die Schnittstellen des ePA-Aktensystems gelistet, welche durch das ePA-Frontend des Versicherten genutzt werden.

Tabelle 2: TAB_FdV_102 – Schnittstellen des ePA-Aktensystems

Für die Authentisierung mittels eGK und kryptographischer Operationen greift das ePA-Frontend des Versicherten über ein Kartenlesegerät oder über die kontaktlose Schnittstelle auf die eGK zu.

3.2.1 Identität des Nutzers

Ein Versicherter kann als Nutzer des FdV das auf der eGK verfügbare Schlüsselmaterial und Zertifikatein seiner Rolle als Versicherter oder Vertreter verwendet die GesundheitsID für die Authentisierung gegenüber dem ePA-Aktensystem und dem Schlüsselgenerierungsdienst verwenden. Mit dieser digitalen Identität meldet sich der Versicherte an den Diensten der ePA sowie weiteren Diensten der TI entweder über nPA+PIN oder eGK+PIN an.

Voraussetzung ist die Nutzung einer eGK G2 oder höher, wobei eine eGK G2 nur den RSA-2048-Algorithmenkatalog unterstützt. Eine eGK G2.1 unterstützt den RSA-2048 und ECC-256-Algorithmenkatalog. Die normierenden Organisationen haben das Ende der Zulässigkeit für den RSA-2048 festgelegt. Aus diesem Grund wird bei Nutzung einer eGK G2 der RSA-Algorithmenkatalog und bei eGK einer höheren Generation (d.h. ab eGK G2.1) der ECC-Algorithmenkatalog verwendet.

Zusätzlich zur eGK sieht das FdV die Möglichkeit der Nutzung einer alternativen Authentisierung vor. Sie muss bei der Krankenkasse des Nutzers beantragt werden. Die Authentisierung beim ePA-Aktensystem erfolgt unter Einbeziehung eines Signaturdienstes.

Für die Zertifikate der alternativen Authentisierung wird der ECC-Algorithmenkatalog verwendetDas ePA Aktensystem etabliert hierzu einen Authorization Server welcher als OpenID Relying-Party (Client) Mitglied der TI-Föderation ist.

Nach initialem Login-Request des FdV (unter Signalisierung des zu verwendenden Identity Provider (IDP) authentisiert sich der Authorization Server gegenüber dem für den Versicherten zuständigen sektoralen IDP. Anschließend leitet er einen Authentication Request über das ePA Frontend an die Authenticator-Modul Komponente des IDP innerhalb des FdV.

Das Authenticator-Modul realisiert die Authentisierung des Versicherten mittels eGK, online Ausweisfunktion oder weiteren zulässigen Verfahren des IDP. Anschließend wird über das FdV der sogenannte Authorization_Code an den Authorization Server des Aktensystems gesendet.

Dieser authentisiert sich nun erneut gegenüber dem sektoralen IDP und tauscht den Authorization_Code gegen ein verschlüsseltes ID_TOKEN mit den personenbezogenen Daten des Versicherten ein.

Diese Daten können anschließend der etablierten VAU/User Session zugeordnet werden und signalisieren dem Aktensystem die Identität des Nutzers.

4 Zerlegung des Produkttyps

Im Folgenden wird die Zerlegung des Produkttyps ePA-Frontend des Versicherten dargestellt, welche für die Übersicht der funktionalen Leistungsmerkmale in der vorliegenden Spezifikation nötig ist.

Abbildung 21: Komponenten ePA-Frontend des Versicherten

Tabelle 3: TAB_FdV_167 – Komponenten des FdV

Das für die Nutzung des ePA-Frontend des Versicherten notwendige GUI ist Teil des FdV und wird nicht normativ durch die Spezifikation des FdV vorgegeben.

Das FdV kann zusätzliche Funktionen beinhalten, hierzu zählen Module/Funktionen (z.B. Authenticator-Modul, weitere fachliche Anwendungen der gematik) und bspw. kassenspezifische Funktionen, welche Schnittstellen zu kassenspezifischen Diensten außerhalb der TI nutzen.

Das ePA-Frontend des Versicherten besitzt eine produktspezifische anwendungsinterne Schnittstelle, welche durch das GUI oder die zusätzlichen Funktionalitäten der integrierenden Anwendung genutzt werden kann, um ePA-Anwendungsfälle auszuführen.

5 Übergreifende Festlegungen

Das ehemalige ePA-Modul FdV wurde als eigenständiges Objekt der Produktzulassung vollständig abgelöst vom ePA-Frontend des Versicherten (also der Gesamt-App). Das sollte durch die Verfahrensbeschreibung und den Aufbau sowie die Bezeichnung des Produkttypsteckbriefsder Produkttypsteckbriefe eindeutig und normativ dargestellt sein. Das heißt, prinzipiell richten sich alle Anforderungen des Produkttypsteckbriefs an die gesamte ePA-App bzw. an deren Entwicklungsprozess. Der Nachweis zur Erfüllung der Anforderungen erfolgt dabei im Einzelnen folgendermaßen:

•  Die Menge der Anforderungen zur funktionalen Eignung, deren Erfüllung im Produkttest bzw. Produktübergreifenden Test nachzuweisen ist, entspricht weitgehend der, die ursprünglich dem ehemaligen ePA-Modul zugeordnet war. Es handelt sich um die Vorgaben an die Funktionalität für den Zugriff auf die ePA (die Komponenten der TI). Der Test erfolgt, unverändert zum bisher geplanten Vorgehen, unter Einsatz des AKTORs und der Testtreiberschnittstelle.
• Die Menge der Anforderungen zur funktionalen Eignung, deren Erfüllung durch Herstellererklärung zu belegen ist, umfasst nunmehr auch Anforderungen, die bisher nur mittelbar durch das Verfahren der Bestätigung der Entwicklungsprozesse an die gesamte App gestellt wurden. Dabei handelt es sich beispielsweise um elementare Anforderungen an die Nutzerinteraktion (Anzeige etc.), die nicht unter Nutzung des AKTORs geprüft werden können/sollen.
• Die Anforderungen der sicherheitstechnischen Eignung, deren Erfüllung im Produktgutachten bzw. in der CC-Evaluierung nachzuweisen ist, richten sich an die gesamte App – der Betrachtungsgegenstand der Prüfung ist die gesamte App einschließlich der von der gematik nicht spezifizierten Funktionalität.
• Die Herstellererklärung zur sicherheitstechnischen Eignung bezieht sich auf die Erfüllung von Anforderungen an die gesamte App.
• Die Anforderungen zur Sicherheitsbegutachtung entsprechen denen, die nach dem bisherigen Verfahren in der Bestätigung der sicheren Entwicklungsprozesse des Herstellers nachgewiesen wurden. 

Die Gesamtmenge der Anforderungen, die sich aus der Zusammenführung der Produktzulassung und der Bestätigung der Entwicklungsprozesse des Herstellers ergibt, ist im Wesentlichen unverändert geblieben. 

Die Darstellung in der Systemlösung hat keinen normativen Charakter, was den Schnitt der Zulassungsobjekte und deren inneren Aufbau betrifftLeistungserbringerinstitutionen

Der Begriff Leistungserbringerinstitutionen (LEI) umfasst in diesem Dokument alle Nutzergruppen der TI, welche durch eine TelematikID eindeutig adressiert werden und eine professionOID gemäß A_24463* (außer oid_diga) besitzen.

Digitale Gesundheitsanwendung

Eine Digitale Gesundheitsanwendung (DiGA) wird durch eine TelematikID eindeutig adressiert und ist mit der professionOID mit dem Wert oid_diga gekennzeichnet.

5.1 Datenschutz und Sicherheit

In diesem Kapitel werden übergreifende Anforderungen beschrieben, die sich aus den Themenfeldern Datenschutz und Sicherheit ergeben.

Für das ePA-FdV ist die Prüfvorschrift für den Produktgutachter des „ePA-Frontend des Versicherten“ des BSI [BSI PVePAeRp] einzuhalten.“

A_24960 - ePA-Frontend des Versicherten: Konvertieren von PDF in PDF/A

Das ePA-Frontend des Versicherten MUSS Dokumente im PDF-Format, die in das Aktenkonto eingestellt werden sollen,  automatisch im ePA-FdV in ein PDF/A-Format konvertieren und ausschließlich das Dokument im PDF/A-Format in das Aktenkonto übermitteln. [<=]

A_16973-01 - ePA-Frontend des Versicherten: lokale Ausführung

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass alle ePA-fachanwendungsspezifischen Anteile lokal auf dem Gerät des Versicherten ausgeführt werden. [<=]

Hinweis: Der auszuführende Code für die ePA-Funktionen des ePA-FdV muss lokal vorliegen und ausgeführt werden, so dass insbesondere alle ePA-Daten (medizinische Daten, sicherheitskritische Daten wie Schlüssel) ausschließlich lokal verarbeitet werden. Zudem erschwert es Administratoren von Servern, auf denen der Code liegen könnte, den Code zu manipulieren.

Dies bedeutet insbesondere, dass eine Auslagerung von ePA-Funktionen auf Webserver nicht erlaubt ist. Dies verhindert jedoch nicht, das ePA-FdV mithilfe von Webtechnologien umzusetzen, um eine Plattformunabhängigkeit zu erreichen. Mithilfe des Frameworks Electron können beispielsweise in HTML, CSS und JavaScript entwickelte Anwendungen lokal unabhängig vom verwendeten Betriebssystem (Windows, MacOS, Linux) ausgeführt werden. Electron bietet auch die Möglichkeit der Nutzung von WebAssembly.

A_15251-01 - ePA-Frontend des Versicherten: Anforderungen an Ausführungsumgebung

Der Hersteller des ePA-FrontendsFrontend des Versicherten MUSS  den Nutzer über die Annahmen und Anforderungen seines Produktes an die Ausführungsumgebung seines Produktesdas Gerät, auf dem das ePA-FdV läuft, sowie über den Bezug des Produkts aus vertrauenswürdigen App Stores informieren. [<=]

Die Annahmen und Anforderungen sollen insbesondere Hinweise enthalten, mit welchen Maßnahmen der Nutzer seine Ausführungsumgebung sicher gestalten kann.

A_21235 - ePA-Frontend des Versicherten: Versicherten über Konsequenzen der Datenfreigabe informieren

Der Hersteller des ePA-FrontendsFrontend des Versicherten MUSS den Nutzer darüber informieren, dass das Erteilen einer Zugriffsberechtigung auf Daten für Leistungserbringer mit einem Speichern dieser Daten in der Umgebung des Leistungserbringers verbunden sein kann. [<=]

Die medizinischen Dokumente im ePA-Aktensystem sind Ende-zu-Ende verschlüsselt. Dadurch können die Dokumente nicht an zentraler Stelle auf mögliche Schadsoftware geprüft werden. Eine Absicherung gegen mögliche Schadsoftware muss auf dem GdV erfolgen.

A_17723 - ePA-Frontend des Versicherten: Über mögliche Schadsoftware informieren

Der Hersteller des ePA-FrontendsFrontend des Versicherten MUSS den Nutzer darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der Nutzer zum Selbstschutz vornehmen kann. [<=]

A_15252-02 - ePA-Frontend des Versicherten: Schlüsselmaterial nicht persistent speichern

Das ePA-Frontend des Versicherten DARF alle verwendeten symmetrischen und privaten asymmetrischen Schlüssel NICHT persistent speichern, sofern es sich nicht um Authentisierungsmerkmale handelt. [<=]

Hinweis: Die Anforderung A_20211-* und A_21354 legenfür die Bedingungen für die persistente Speicherung von Authentisierungsmerkmalen legt das Authenticator-Modul fest.

A_15253-01 - ePA-Frontend des Versicherten: Schutz Session-Daten

Das ePA-Frontend des Versicherten DARF Session-Daten NICHT an Dritte, außer im Rahmen der in den Anwendungsfällen spezifizierten Kommunikation, weitergeben. [<=]

Der Umfang der Session-Daten ist im Kapitel "" beschrieben. Die für den Versicherten im Aktenkonto bereitgestellten Dokumente gehören nicht zu den Session-Daten.

A_15254-01 - ePA-Frontend des Versicherten: Session-Daten nicht persistent speichern

Das ePA-Frontend des Versicherten DARF Session-Daten NICHT persistent speichern. [<=]

A_17625-01 - ePA-Frontend des Versicherten: Keine Speicherung der PIN der eGK

Das ePA-Frontend des Versicherten DARF die PIN der eGK NICHT speichern. [<=]

A_20211-02 - ePA-Frontend des Versicherten für mobile Plattformen: Schutz von gespeicherten Authentisierungsmerkmalen

Das ePA-Frontend des Versicherten DARF Authentisierungsmerkmale NICHT speichern, außer wenn

•   der Versicherte sich hierfür bewusst entscheidet (Opt-in),

•   die Speicherung des Authentisierungsmerkmals auf dem Endgerät gemäß den Anforderungen O.Data_2 und O.Data_3  der BSI TR-03161 erfolgt,

•   auf das gespeicherte Authentisierungsmerkmal ausschließlich durch das ePA-Frontend des Versicherten nach erfolgreicher Authentifizierung des Versicherten über die Biometrie des Endgeräts oder die PIN bzw. das Passwort des Endgerätes zugegriffen werden kann,

•   die biometrischen Sensoren des Endgerätes die Anforderungen O.Biom_x der BSI TR-03161 mit Ausnahme der O.Biom_2 erfüllen,

•   die Forderung O.Biom_3 der BSI TR-03161 mit einer Allowlist umgesetzt wird (d.h. eine Denylist ist nicht möglich) und

•   die Qualität und Eigenschaften des biometrischen Sensors die spezifischen Anforderungen zur Biometrie des BSI-Dokumentes „Bewertung von Authentisierungslösungen gemäß TR-03107“ für das Vertrauensniveau von mindestens „substanziell“ erfüllen.

Die oben beschriebene Ausnahme vom Verbot der Speicherung von Authentisierungsmerkmalen gilt nicht für die PIN der eGK, die niemals gespeichert werden darf. [<=]

A_21354 - ePA-FdV für Desktop-Plattformen: Schutz von gespeicherten Authentisierungsmerkmalen

Das ePA-FdV für Desktop-Plattformen MUSS sicherstellen, dass Authentisierungsmerkmale ausschließlich unter folgenden Bedingungen gespeichert werden:

•   der Versicherte entscheidet sich hierfür bewusst (Opt-in),

•   die Speicherung des Authentisierungsmerkmals auf dem Endgerät des Versicherten erfolgt ausschließlich verschlüsselt,

•   auf das verschlüsselte gespeicherte Authentisierungsmerkmal kann ausschließlich nach erfolgreicher Authentifizierung des Versicherten über ein Passwort bzw. eine Passphrase zugegriffen werden.

[<=]

Hinweis: Dies ist die analoge Anforderung zu A_20211-* bei mobilen Endgeräten.

Hinweis: Eine explizite Authentifizierung des Versicherten durch das ePA-FdV wird empfohlen.

A_20746 - ePA-Frontend des Versicherten: Authentifizierung des Nutzers am ePA-FdV

Das ePA Frontend des Versicherten MUSS den Nutzer beim Starten des ePA Frontends des Versicherten am ePA Frontend des Versicherten authentisieren.  [<=]

Hinweis: Für die Authentifizierung des Nutzers am ePA-FdV können die Authentifizierungsfunktionen des Betriebssystems des Endgerätes (z.B. Logscreen-Credentials, Biometrie) genutzt werden. Bei der Authentifizierung der oberen Anforderung ist nicht die Anmeldung an Backendsystemen (z.B. ePA-Aktensystem) gemeint, sondern die Authentifizierung am ePA-Frontend des Versicherten.

A_20747 - ePA-Frontend des Versicherten: Hinweis auf Verwendung eines sicheren PINs/Passworts bei Erstnutzung

Das ePA Frontend des Versicherten MUSS den Versicherten bei Erstverwendung des ePA-Frontend des Versicherten darauf hinweisen, dass dieser bei Wahl einer PIN oder eines Passworts zur Freischaltung seines Endgerätes, die bzw. das auch zur Authentisierung am ePA-Frontend des Versicherten genutzt wird, eine sichere PIN bzw. ein sicheres Passwort nutzen sollte inkl. Hinweisen, wie eine sichere PIN bzw. ein sicheres Passwort zu wählen sind. [<=]

A_15255-01 - ePA-Frontend des Versicherten: Schutzmaßnahmen gegen die OWASP-Mobile-Top-10-Risiken

Das ePA-Frontend des Versicherten MUSS Maßnahmen zum Schutz vor den in der aktuellen Version genannten OWASP-Top-10-Mobile-Risiken [OWASPMobileTop10] umsetzen. [<=]

Dies betrifft bspw. die folgenden Aspekte:

• Schutz von Reverse Engineering
• Verwendung von Plattform Sicherheit Best Practice
• Secure Data Storage
• Schutz gegen code tampering
• Extraneous functionality

Für mobile Anwendungen sind OWASP Top Ten Mobile Controls [OWASP TTMC] und OWASP MASVS – L2 + R [OWASP MASVS] zu beachten. Anforderung A_15255-01  ist sowohl für Lösungen auf mobilen als auch Desktop-Plattformen umzusetzen.

Die im Aktenkonto eingestellten Dokumente werden verschlüsselt an das Aktensystem übermittelt und verarbeitet. Sie liegen im Aktensystem nie im Klartext vor. Daher kann das ePA-Aktensystem den Inhalt der Dokumente nicht auf Schadsoftware überprüfen.

A_17660 - ePA-Frontend des Versicherten: Schutzmaßnahmen gegen Schadsoftware aus Dokumenten

Das ePA-Frontend des Versicherten MUSS, wenn es Dokumentinhalte direkt anzeigt, Maßnahmen zum Schutz vor Schadsoftware in den Dokumenten umsetzen. [<=]

Folgende Maßnahmen sind sinnvoll:

• Prüfen, ob Dokumenten-Format und Inhalt mit dem angegebenen Dokumententyp in den Metadaten übereinstimmt
• Prüfen, ob Dokumenten-Format und Inhalt zu den erlaubten ePA-Dokumentenformaten passt
• Vor der Anzeige eines Dokumentes sind Sonder- und Meta-Zeichen im Dokument für die jeweilige Anzeigesoftware mit der richtigen Escape-Syntax zu entschärfen.
• Die Anzeigesoftware ist in einer Art Sandbox zu betreiben.

A_15256-02 - ePA-Frontend des Versicherten: Verbot von Werbe-Tracking

Das ePA-Frontend des Versicherten DARF ein Werbe-Tracking NICHT verwenden. [<=]

Im Folgenden wird unter Tracking Usability-Tracking sowie Crash-Reporting verstanden.

A_18767 - Tracking-Funktionen – Keine Weitergabe von Sicherheitsmerkmalen

Das ePA-Frontend des Versicherten MUSS sicherstellen, falls es Tracking-Funktionen implementiert, dass in den übermittelten Tracking-Informationen keine Sicherheitsmerkmale enthalten sind. [<=]

Hinweis: Sicherheitsmerkmale sind die Gerätekennung (DeviceID) und Session-Daten wie z. B. geheime oder private Schlüssel, Authentifizierungs- oder Autorisierungsbestätigungen.

A_18768 - Tracking-Funktionen – Verarbeitung und Auswertung der Tracking-Daten

Der Hersteller des ePA-Frontend des Versicherten MUSS die Verarbeitung und Auswertung der gesammelten Tracking-Daten des ePA-Frontends des Versicherten selbst durchführen und nicht von einem Drittanbieter durchführen lassen. [<=]

A_18769 - Tracking-Funktionen – Keine direkt identifizierenden personenbezogenen Daten

Das ePA-Frontend des Versicherten MUSS sicherstellen, falls es Tracking-Funktionen nutzt, dass die Tracking-Daten keine Daten enthalten, die natürliche Personen direkt identifizieren. [<=]

Hinweis: Personenbezogene Daten mit direktem Personenbezug sind bspw. Namen von natürlichen Personen, Geräte-IDsGeräteidentifikatoren, Nutzerkennungen oder ein „Fingerabdruck“ auf Basis von Geräteeigenschaften und Einstellungen.

Tracking Anforderungen für Trackingdaten ohne Einwilligung

A_18770 - Tracking-Funktionen – Ohne Einwilligung des Nutzers

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen ohne Einwilligung des Versicherten nutzt, sicherstellen, dass die Tracking-Daten

• sich nur auf eine Nutzersession (von der ersten Interaktion des Nutzers mit dem FdV bis zum Schließen des FdVs bzw. bis zum Inaktivitätstimeout) beziehen und nicht mit anderen Sessions des Nutzers verknüpft werden,
• weder personenbezogene noch pseudonymisierte personenbezogene Daten enthalten,
• keine nutzerbezogenen IDs oder gerätespezifischen IDs der Nutzergeräte enthalten,
• keinen Rückschluss auf Versicherte, deren Vertreter, Leistungserbringer oder Kostenträger ermöglichen, insbesondere Rückschlüsse anhand des Nutzerverhaltens über die Zeit oder über Nutzersessions hinweg,
• nicht durch die Verknüpfung mit personenbezogenen Daten aus anderen Quellen de-anonymisiert werden können.

[<=]

Hinweis: Andere Quellen sind z.B. Webtracker, Tracker von anderen Apps oder Trackingmerkmale des Betriebssystems (z.B. Hardware IDs, Network IDs oder Advertising IDs).  

A_19061 - Tracking-Funktionen – Nutzer Informieren

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen ohne Einwilligung des Versicherten nutzt, den Nutzer über das Tracking im ePA-FdV in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache informieren, bevor die Trackingdaten erhoben werden.
[<=]

Hinweis: Diese Anforderung ist nicht durch einen alleinigen Verweis auf die AGB oder Nutzungsbedingungen des FdVs erfüllbar. Verständliche Form bedeutet eine kurze nicht juristische Erklärung zum Zweck des Trackings. Leicht zugängliche Form bedeutet direkt im FdV.

A_18771 - Tracking-Funktionen – Generierung von Nutzersession basierte Trackingmerkmale

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen ohne Einwilligung des Versicherten nutzt, beim Start einer Nutzersession die Nutzersession-ID zufällig neu generieren. [<=]

Anforderungen zur Einwilligung zum Session-übergreifenden Tracking

A_18772 - Tracking-Funktionen - Opt-in

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, technisch sicherstellen, dass diese Tracking-Funktionen bei der Installation des FdV standardmäßig deaktiviert sind und nur nach expliziter Einwilligung durch den Versicherten als Nutzer des FdV aktiviert werden (Opt-in). [<=]

A_18773 - Tracking-Funktionen – Kopplungsverbot

Das ePA-Frontend des Versicherten DARF, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpft, die Nutzung des FdVs NICHT an die Aktivierung dieser Trackingfunktion koppeln.  [<=]

Hinweis: Das FdV muss voll-funktional ohne aktiviertes Tracking nutzbar sein.

A_18774 - Tracking-Funktionen - Einwilligungsinformation des Nutzers

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, den Versicherten vor der Einwilligung in die Aktivierung dieser Tracking-Funktionen in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen anzeigen:

• welche Daten durch die Tracking-Funktionen erhoben werden,
• zu welchen Zwecken die Daten erhoben werden,
• welche Informationen durch die Auswertung der erhobenen Daten gewonnen werden und ob Rückschlüsse auf den Gesundheitszustand des Nutzers möglich wären,
• wer die Empfänger der Daten sind,
• wie lange die Daten gespeichert werden.

[<=]

Hinweis: Diese Anforderung ist nicht durch einen alleinigen Verweis auf die AGB oder Nutzungsbedingungen des FdVs erfüllbar. Verständliche Form bedeutet eine kurze nicht juristische Erklärung zum Zweck des Trackings. Leicht zugängliche Form bedeutet direkt im FdV.

A_18775 - Tracking-Funktionen – Aktivierung erst nach Lesebestätigung der Einwilligungsinformationen

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, sicherstellen, dass die Einwilligung des Nutzers in die Aktivierung der Tracking-Funktionen erst erfolgt, wenn der Nutzer bestätigt, die angezeigten Einwilligungsinformationen gelesen zu haben. [<=]

A_18776 - Tracking-Funktionen – Deaktivierung ist jederzeit möglich

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, technisch sicherstellen, dass aktivierte Tracking-Funktionen jederzeit durch den Nutzer des FdVs deaktiviert werden können. [<=]

A_18777 - Tracking-Funktionen – Neue Generierung der Pseudonyme ist jederzeit möglich

Das ePA-Frontend des Versicherten SOLL, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, technisch sicherstellen, dass eine neue Generierung der pseudonymen Identifier jederzeit durch den Nutzer des FdVs veranlasst werden kann. [<=]

A_18778 - Tracking-Funktionen – Verbot von mehrmaligen Einwilligungsabfragen

Das ePA-Frontend des Versicherten MUSS, falls es Tracking-Funktionen implementiert, die Tracking-Daten mehrerer Nutzersessions verknüpfen, technisch sicherstellen, dass der Benutzer der App maximal einmal eine Abfrage zur Einwilligung des Trackings angezeigt bekommt. [<=]

Hinweis: Wenn der Benutzer seine Einwilligung zum Tracking nicht erteilt, darf das FdV den Nutzer nicht solange nach seiner Einwilligung fragen, bis der Nutzer diese erteilt.

A_15257-01 - ePA-Frontend des Versicherten: Qualität verwendeter Schlüssel

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass die von ihm erzeugten Schlüssel die Qualität nach [gemSpec_Krypt#GS-A_4368] besitzen. [<=]

Wenn die eGK zur Verfügung steht, dann kann diese für das Erzeugen von Schlüsseln in der geforderten Qualität (Kartenkommando GET RANDOM) genutzt werden. Ist das optionale Kartenkommando GET RANDOM für die eGK nicht verfügbar (Fehlermeldung der Karte), dann kann das Kartenkommando GET CHALLENGE (PL_TUC_GET_CHALLENGE) der eGK genutzt werden. GET RANDOM und GET CHALLENGE liefern einen ausreichend guten Zufall, der die Forderungen aus [gemSpec_Krypt#GS-A_4368] erfüllt.

Wenn die eGK nicht zur Verfügung steht, dann können Informationen von zusätzliche Quellen (Internet, Sensoren des GdV) zusammengeführt werden, um die geforderte Entropie zu erreichen.

A_15258-01 - ePA-Frontend des Versicherten: Dynamische Inhalte von Drittanbieter

Das ePA-Frontend des Versicherten DARF dynamische Inhalte von Drittanbietern NICHT herunterladen oder verwenden. [<=]

A_15259-01 - ePA-Frontend des Versicherten: Privacy bei default

Das ePA-Frontend des Versicherten MUSS bei Konfigurationsmöglichkeiten die sichere, datenschutzfreundlichere Option vorauswählen. [<=]

Bspw. ist ein Opt-In anstelle eines Opt-Out-Verfahrens anzuwenden.

A_15261-01 - ePA-Frontend des Versicherten: Sicherheitsrisiken von Software Bibliotheken minimieren

Das ePA-Frontend des Versicherten MUSS Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren. [<=]

Hinweis:  Beispielmaßnahmen sind in [OWASP Proactive Control#C2] zu finden. Das gewählte Verfahren muss die gleiche Wirksamkeit aufweisen, wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4].

Das ePA-Frontend des Versicherten bietet nur Funktionalitäten an, welche sich aus den Anwendungsfällen der Fachanwendung ePA bietet nur Funktionalitäten an, welche sich aus den Anwendungsfällen der Fachanwendung ePA und weiteren Fachanwendungen der TI (z.B. E-Rezept, TI-Messenger) ergeben. 

Zusätzliche Funktionalitäten können durch das FdV angeboten werden. Folgende Anforderungen gelten für die Abgrenzung der zusätzlichen Funktionalitäten zu denen der Fachanwendung ePAFachanwendungen der TI.

A_16438 - ePA-Frontend des Versicherten: Unterscheidbarkeit zusätzlicher Funktionalitäten

Das ePA-Frontend des Versicherten MUSS sicherstellen, falls es zusätzliche Funktionalitäten enthält, dass der Nutzer diese zusätzlichen Funktionalitäten von den Funktionalitäten für die ePA unterscheiden kann. [<=]

Die Information, welche Funktionalitäten zusätzlich zu den Funktionen für die ePA enthalten und damit nicht Gegenstand der Zulassung durch die gematik sind, kann im Handbuch oder den Informationen zur Zustimmung gemäß A_16439 beschrieben werden.

A_18401 - ePA-Frontend des Versicherten: Verarbeiten von ePA-Daten in zusätzlichen Funktionalitäten - Zustimmung

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass der Nutzer dem Verarbeiten der ePA-Daten in zusätzlichen Funktionalitäten des ePA-Frontends des Versicherten bezüglich Umfang, Art und Dauer der Verarbeitung vor dem Zugriff der Zusatzfunktionen auf die ePA-Daten zustimmen muss. [<=]

A_18402 - ePA-Frontend des Versicherten: Verarbeiten von ePA-Daten in zusätzlichen Funktionalitäten - Opt-In

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass die Zustimmung zur Verarbeitung der ePA-Daten in zusätzlichen Funktionalitäten des ePA-Frontends des Versicherten optional (Opt-In) und jederzeit widerrufbar ist. [<=]

A_16439 - ePA-Frontend des Versicherten: Weiterleiten von Daten - Zustimmung

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass Daten, die aus der ePA ins FdV geladen werden, nur mit Zustimmung des Versicherten unter Nutzung von expliziten Opt-in-Lösungen weitergeleitet werden können, wobei sich das Opt-In nur genau auf die Weiterleitung beziehen und nicht mit anderen Zustimmungen kombiniert werden darf. [<=]

Die in A_16439 geforderte Zustimmung kann einmalig durch den Versicherten erteilt werden und bis auf Widerruf des Versicherten für alle Datenweiterleitungen, die von dem Versicherten veranlasst werden, gelten. Das FdV kann dabei die Möglichkeit einer expliziten Opt-in-Lösung mit Widerrufsrecht oder ein anlassbezogenes Zustimmungsverfahren oder eine Wahlmöglichkeit beider Verfahren vorsehen.

A_20721 - Weiterleiten von Daten an Krankenkassen erst nach Einwilligung

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass Daten, die aus der ePA ins FdV geladen werden, nur an von Krankenkassen angebotene Anwendungen weitergeleitet werden, falls der Versicherte zuvor gegenüber der Krankenkasse in die Verarbeitung dieser Daten eingewilligt hat. [<=]

Hinweis: Die A_20721 setzt die Forderung des § 345 Abs. 1 SGB V um. Die Einwilligung gegenüber der Krankenkasse kann elektronisch erfolgen. Dies betrifft insbesondere auch die Übermittlung des Nachweises, mit dem die Krankenkasse die Einwilligung des Versicherten in die Verarbeitung der Daten nachweisen kann (vgl. Art. 7 Abs. 1 DSGVO).

A_16440 - ePA-Frontend des Versicherten: Weiterleiten von Daten - Information

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass der Versicherte vor der Zustimmung zur Nutzung von aus der ePA ins FdV geladenen Daten durch Anwendungen oder Apps im oder außerhalb des Frontends in verständlicher Weise darüber informiert wird, welche Daten, wann und an wen weitergeleitet werden und zu welchem Zwecke die Anwendungen die Daten verarbeiten. [<=]

A_16441 - ePA-Frontend des Versicherten: Weiterleiten von Daten - Nachvollziehbarkeit

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass der Versicherte eine Weiterleitung der Daten im Nachhinein nachvollziehen kann (z.B. durch Protokollierung). [<=]

A_19110 - ePA-Frontend des Versicherten: – Unterbindung bei einer erheblichen Störung

Der Hersteller des ePA-Frontend des Versicherten MUSS bei Bekanntwerden einer erheblichen Störung (gemäß §291b Abs.6 S.3 SGB V) in einer Version des ePA-Frontend des Versicherten die Nutzung dieser Version unverzüglich unterbinden.
[<=]

A_21342 - ePA-FdV für Desktop-Plattformen: Anzeige eines Hinweistextes zum Betrieb auf Hardware, die nicht unter der Kontrolle des Versicherten steht

Das ePA-FdV MUSS den Versicherten in einem Hinweistext auf die Gefahren hinweisen, die bei einem Betrieb des ePA-FdV auf Hardware, die nicht unter der Kontrolle des Versicherten steht, gegeben sind. [<=]

Hinweis: Im Gegensatz zu Betriebssystem für Smartphones und Tablets wie etwa Android und iOS sind Betriebssysteme für stationäre Geräte wie etwa PCs durchaus im öffentlichen Raum verfügbar. So läuft etwa auf den meisten Geräten in Internet-Cafes Windows. Würde hier das ePA-FdV ausgeführt werden und der Versicherte sich Dokumente aus seiner Akte herunterladen, dann müsste der Versicherte dafür sorgen, dass keine Daten von ihm auf der Hardware verbleiben, wenn er den Zugriff auf die Hardware beendet. Es wird empfohlen, die Nutzung des ePA-FdV auf öffentlich zugänglicher Hardware zu unterlassen.

Hinweis: Die einmalige Anzeige des Hinweises mit Bestätigung pro Versicherten ist ausreichend. Es muss dabei sichergestellt sein, dass jedem Nutzer (Mehrbenutzerbetrieb) dieser Hinweis zur Bestätigung angezeigt wird. Dieses könnte etwa durch Anzeige vor der Authentisierung gegenüber dem ePA-FdV erfolgen.

A_21343-01 - ePA-FdV für Desktop-PlattformenFrontend des Versicherten: Ausführen von begutachtetem Code

Der Hersteller des ePA-FdV MUSS technisch sicherstellen, dass nur im Rahmen eines Produktgutachtens begutachteterePA-FdV nur Code ausgeführt wird, welcher im Scope des Produktgutachtens liegt oder Code-Änderungen nach Vorgaben der gematik durch den Hersteller des ePA-FdV als nicht zulassungsrelevant bewertet wurden. [<=]

Hinweis: Die Anforderung soll das Einschleusen von Schadcode verhindern. Dies kann beispielsweise durch Signieren des ePA-FdV durch den Hersteller erfolgen, um Manipulationen am ePA-FdV vor der Ausführung erkennen zu können. Das Verbot des dynamischen Nachladens von ungeprüftem Code soll insbesondere auch sicherstellen, dass zum Zeitpunkt der Prüfung des ePA-FdV durch den Produktgutachter der gesamte Anwendungscode vorliegt und dieser nicht später durch ungeprüften Code ersetzt bzw. ergänzt werden kann. Die Anforderung verhindert zum Beispiel nicht, das Kartendaten eines externen Kartendienstes oder Bilder aus externen Quellen ins ePA-FdV geladen werden können. Es ist aber z.B. nicht möglich, ausführbaren Code wie z.B. Java Script nachzuladen.

Im Zulassungsverfahren für das ePA-FdV ist festgelegt, wann Änderungen durch die gematik als zulassungsrelevant betrachtet werden. Zulassungsrelevante Änderungen sind z.B. Änderungen von Sicherheitsfunktionen oder deren Implementierung (z.B. Wechsel der TLS-Implementierung). Nicht-zulassungsrelevante Änderungen sind z.B. Sicherheitsupdates für von anderen Herstellern bezogenen Software-Komponenten der Plattform (z.B. Bibliotheken), die aus einer vertrauenswürdigen Quelle bezogen werden.

A_21344-01 - ePA-FdV für Desktop-PlattformenFrontend des Versicherten: Code von Drittanbietern aus vertrauenswürdigen Quellen

Der Hersteller des ePA-FdV MUSS die Software-Komponenten des ePA-FdV, die nicht vom Hersteller des ePA-FdV selbst entwickelt oder zur Entwicklung beauftragt werden (z.B. TLS-Bibliotheken), aus bekannten und vertrauenswürdigen Quellen beziehen.  [<=]

A_21355 - ePA-FdV für Desktop-PlattformenFrontend des Versicherten: Zugriff auf den Geräteidentifikator durch Zusatzfunktionen

Das ePA-FdV DARF Zusatzfunktionen des FdV (d.h. kassenspezifische Dienste) NICHT auf den Geräteidentifikator (die von der Autorisierung übermittelte Zufallszahl bei der Gerätebindung) zugreifen lassen. [<=]

A_21356 - ePA-FdV für Desktop-PlattformenFrontend des Versicherten: Speicherung des Geräteidentifikators

Das ePA-FdV MUSS sicherstellen, dass die Speicherung des Geräteidentifikators (die von der Autorisierung übermittelte Zufallszahl bei der Gerätebindung) ausschließlich verschlüsselt erfolgt. [<=]

A_21357 - ePA-FdV für Desktop-PlattformenFrontend des Versicherten: Zugriff auf den Geräteidentifikator

Das ePA-FdV MUSS sicherstellen, dass auf den verschlüsselten gespeicherten Geräteidentifikator ausschließlich nach erfolgreicher Authentifizierung des Versicherten beim Start des ePA-FdV zugegriffen werden kann. [<=]

Hinweis: Nach A_20746 muss sich der Nutzer beim Starten des ePA-FdV am ePA-FdV authentisieren.

A_21350 - ePA-FdV für Desktop-Plattformen: Informieren des Versicherten über sichere Bezugsquellen für die Verteilung des FdV

Der Hersteller des ePA-FdV MUSS Versicherte über die vertrauenswürdigen Quellen informieren, von denen Versicherte das ePA-FdV beziehen können und wie sie die Vertrauenswürdigkeit der Quelle erkennen können. [<=]

Hinweis: Krankenkassen (als Anbieter eines ePA-Aktensystems) können zur Umsetzung dieser Anforderung z.B. den Versicherten hierzu entsprechendes Informationsmaterial zur Verfügung stellen, wo die Download-Punkte aufgelistet sind.

A_21351 - ePA-FdV für Desktop-Plattformen: Sicherstellung der Authentifizierung der Bezugsquelle bei Erstbezug

Der Hersteller des ePA-FdV MUSS sicherstellen, dass der Versicherte bei Erstbezug eines ePA-FdV die Authentizität der vertrauenswürdigen Bezugsquelle verifizieren kann. [<=]

Hinweis: Beim Erstbezug des ePA-FdV kann die Prüfung der Authentizität der Quelle noch nicht durch das ePA-FdV selbst erfolgen. Dies kann z.B. über eine TLS-Server-Authentifizierung der Bezugsquelle erreicht werden. Bei ePA-FdVs in den Stores der mobilen Plattformen kann der Versicherte die Vertrauenswürdigkeit daran erkennen, dass er den offiziellen Store nutzt. Auch unter Windows und Mac OS und Linux/Debian gibt es einen offiziellen Store.

A_21352 - ePA-FdV für Desktop-Plattformen: Technische Authentifizierung der Update-Bezugsquellen für die sichere Verteilung der ePA-FdV-Anwendung

Das ePA-FdV MUSS sicherstellen, dass Updates nur von bekannten und vertrauenswürdigen Quellen bezogen werden, nach dem die Authentizität der Quelle technisch erfolgreich verifiziert wurde. [<=]

A_21475 - Zugriff auf das Nationale Gesundheitsportal nur nach Zustimmung des Versicherten (Opt-in)

Das ePA-FdV MUSS sicherstellen, dass Zugriffe mit dem ePA-FdV auf das Nationale Gesundheitsportal erst erfolgen können, nachdem der Versicherte dem zugestimmt hat, und nicht mehr erfolgen können, nachdem der Versicherte eine zuvor gegebene Zustimmung zurückgenommen hat. [<=]

Hinweis: Die Zustimmung kann einmal eingeholt werden und muss nicht bei jedem Zugriff wiederholt erfolgen.

A_21476 - Informationen zum Datenschutz bei Nutzung des Nationalen Gesundheitsportals

Das ePA-FdV MUSS den Versicherten vor Nutzung des Nationalen Gesundheitsportals mindestens informieren über

• den Zweck, Umfang und Art der Verarbeitung der Daten des Versicherten im Nationalen Gesundheitsportal,
• die Maßnahmen im Nationalen Gesundheitsportal zur Verhinderung einer Profilbildung,
• den nach DSGVO Verantwortlichen des Nationalen Gesundheitsportals und
• die zuständige datenschutzrechtliche Aufsichtsbehörde für das Nationale Gesundheitsportal.

[<=]

A_21477 - Sichere Verbindung zum Nationalen Gesundheitsportal

Das ePA-FdV MUSS sicherstellen, dass auf das Nationale Gesundheitsportal ausschließlich zugegriffen wird, nachdem die Authentizität des Nationalen Gesundheitsportals vom ePA-FdV erfolgreich geprüft wurde und eine vertrauliche und integritätsgeschützte Verbindung zwischen ePA-FdV und Nationalem Gesundheitsportal aufgebaut wurde. [<=]

A_21700 - Verbot der Übermittelung persönlicher Daten an das Nationale Gesundheitsportal

Das ePA-FdV MUSS sicherstellen, dass bei Zugriffen auf das Nationale Gesundheitsportal keine personenbezogenen Daten oder Einstellungen an das Nationale Gesundheitsportal übermittelt oder dem Nationalen Gesundheitsportal Zugriffe auf diese Daten gewährt werden, außer sie sind für die technische Verbindung vom ePA-FdV zum Nationalen Gesundheitsportal zwingend notwendig. [<=]

A_21795 - ePA-FdV: Ausschluss der Übermittlung nicht freigegebener Dokumente für Forschungszwecke

Das ePA-FdV DARF Dokumente des Versicherten, die nicht durch den Versicherten für die Verwendung zu Forschungszwecken freigegeben sind, NICHT an das Forschungsdatenzentrum übermitteln. [<=]

A_21802 - ePA-FdV: Ausschluss der Übermittlung nicht pseudonymisierter Dokumente für Forschungszwecke

Das ePA-FdV DARF Originaldokumente (nicht pseudonymisierte Dokumente) NICHT an das Forschungsdatenzentrum oder die Vertrauensstelle übermitteln. [<=]

A_21857 - ePA-FdV: Integrität und Authentizität Pseudonymisierungsschema

Das ePA-FdV des Versicherten MUSS sicherstellen, dass ausschließlich integre und authentische Pseudonymisierungsschemata genutzt werden. [<=]

A_22822 - ePA-FdV: Keine Übertragung von Metadaten an das Forschungsdatenzentrum

Das ePA-FdV MUSS sicherstellen, dass keine Metadaten zu Dokumenten des Versicherten an das Forschungsdatenzentrum übertragen werden.  [<=]

5.1.1 Anforderungen bei CC-Zertifizierung

A_19143 - ePA-Frontend des Versicherten: Mitwirkungspflicht bei der CC-Zertifizierung

Falls der Hersteller des ePA-Frontend des Versicherten entscheidet, eine CC-Zertifizierung statt eines Produktgutachtens durchzuführen, MUSS der Hersteller des ePA-Frontend des Versicherten bei der Einreichung eines CC-Zertifizierungsantrags sein Security Target Dokument der gematik zur Verfügung stellen. [<=]

A_19144 - ePA-Frontend des Versicherten: Dokumentationspflicht bei der CC-Zertifizierung

Falls der Hersteller des ePA-Frontend des Versicherten entscheidet, eine CC-Zertifizierung statt eines Produktgutachtens durchzuführen, MUSS der Hersteller des ePA-Frontend des Versicherten

• die zusätzlichen Funktionen des ePA-Frontend des Versicherten, 
• die in den zusätzlichen Funktionen verarbeiteten Daten,
• die Schnittstellen zwischen dem ePA-Frontend des Versicherten und den ggf. genutzten Backend-Diensten der zusätzlichen Funktionen inklusive ihrer Sicherheitsmaßnahmen und 
• die Sicherheitsannahmen an das ePA-Frontend des Versicherten und die Ausführungsumgebung

im Security Target beschreiben.
[<=]

5.1.2 Unterstützung von Audits

Die gematik kann für die Überprüfung der Umsetzung der Anforderungen zur sicherheitstechnischen Eignung Audits beim ePA- FdV durchführen. Für die Hersteller gelten Mitwirkungspflichten.

A_18254-01 - ePA-Frontend des Versicherten: Rechte der gematik zur sicherheitstechnischen Prüfung des Produktes

Der Hersteller des ePA-Frontends des Versicherten MUSS zusichern, dass die gematik oder ein von ihr zur Geheimhaltung verpflichteter Bevollmächtigter berechtigt sind,

•   Sicherheitsprüfungen (z.B. Whitebox oder Blackbox Pentest) seines Produktes durchzuführen (Hiervon unbenommen ist das Recht der gematik, anlasslose Sicherheitsprüfung durchzuführen.),

•   im Rahmen einer Sicherheitsprüfung die konkrete Umsetzung der an das Produkt gestellten Anforderungen zu überprüfen.

Der Hersteller muss dies im gleichen Maße für Unterauftragnehmer zusichern. Die Kosten, die dem Hersteller durch diese Mitwirkungspflichten entstehen, trägt der Hersteller selbst.
[<=]

A_18211-01 - ePA-Frontend des Versicherten: Mitwirkungspflicht bei Sicherheitsprüfung

Der Hersteller des ePA-Frontends des Versicherten MUSS Sicherheitsprüfungen (z.B. Pentest) der gematik unterstützen. [<=]

Hinweis: Unterstützen bedeutet beispielsweise das Bereitstellen einer Release oder Beta-Version des Produkts, das Bereitstellen eines Testsystems inkl. Test Accounts, kleine Anpassungen des Produktes, die eine Beschleunigung des Tests ermöglichen (z.B. Entfernung von Certificate Pinning, Code Obfuscation) und Unterstützung bei Rückfragen.

A_18246-01 - ePA-Frontend des Versicherten: Auditrechte der gematik zur Prüfung des Sicherheitsgutachtens

Der Hersteller des ePA-Frontends des Versicherten MUSS zusichern, dass die gematik oder ein von ihr zur Geheimhaltung verpflichteter Bevollmächtigter berechtigt sind,

•   Audits durchzuführen (Hiervon unbenommen ist das Recht der gematik, anlasslose Audits durchzuführen.),

•   im Rahmen eines Audits beim Hersteller die konkrete Umsetzung der an den Hersteller gestellten Anforderungen zu überprüfen,

•   im Rahmen eines Audits während der üblichen Geschäftszeiten die Geschäftsräume des Herstellers zu betreten,

•   im Rahmen eines Audits alle für das Audit benötigten Informationen zur Verfügung gestellt zu bekommen und insbesondere die erforderlichen Zugangs-, Auskunfts- und Einsichtsrechte zu erhalten.

Der Hersteller muss dies im gleichen Maße für Unterauftragnehmer zusichern. Die Kosten, die dem Hersteller durch diese Mitwirkungspflichten entstehen, trägt der Hersteller selbst. [<=]

5.2 Verwendete Standards

Für die Nutzung der Schnittstellen werden u.a. die folgenden Standards verwendet.

A_15268-01 - ePA-Frontend des Versicherten: Konformität zu WS-I Basic Profil 2.0

Das ePA-Frontend des Versicherten MUSS SOAP-Nachrichten gemäß den Vorgaben aus WS-I Basic Profile V2.0 [WSIBP] unterstützen. [<=]

A_15269-02 - ePA-Frontend des Versicherten: Verwendung von WS-Trust 1.3

Das ePA-Frontend des Versicherten MUSS für die Authentisierung den Standard [WS-Trust1.3] unterstützen.
[<=]

A_15270-01 - ePA-Frontend des Versicherten: Verwendung von DMSLv2

Das ePA-Frontend des Versicherten MUSS für die Abfrage des Verzeichnisdienstes die Standard Directory Services Markup Language v2.0 (DSMLv2) unterstützen. [<=]

Informationen zu DMSLv2 sind unter https://www.oasis-open.org/standards#dsmlv2 verfügbar.

5.3 Integrating the Healthcare Enterprise IHE

Die dokumentenbezogenen Schnittstellen des ePA-Aktensystems und die Verarbeitungslogik des ePA-FrontendFrontends des Versicherten basieren auf Transaktionen des IHE ITI Technical Frameworks (IHE ITI TF). Die IHE ITI-Implementierungsstrategie ist in [gemSpec_DM_ePA] beschrieben.

Das ePA-Frontend des Versicherten nutzt die folgenden Integrationsprofile des IHE ITI TF:

• Cross-Enterprise Document Media Interchange (XDM) Profile

• Cross-Enterprise Document Sharing (XDS.b) Profile
• Remove Metadata and Documents (RMD) Profile

•   Cross-Enterprise User Assertion (XUA) Profile

• Advanced Patient Privacy Consents (APPCRestricted Metadata Update (RMU) Profile

Die folgende Tabelle bietet einen Überblick über die durch das ePA-Frontend des Versicherten umzusetzenden IHE ITI-Akteure und assoziierte Transaktionen. Siehe auch [gemSpec_DM_ePA#Abbildung Überblick über IHE ITI-Akteure und assoziierte Transaktionen].

Tabelle 4: TAB_FdV_103 – IHE Akteure und Transaktionen

XDS-Option „Document Replacement“ - Ersetzen eines existierenden Dokuments

Ein eingestelltes Dokument kann auch ein existierendes Dokument ersetzen. Dies erfolgt durch Verwendung der „Document Replacement“-Option (XDS.b Document Source). Dazu wird das gleiche Dokument (mit geändertem Inhalt und nebst ggf. geänderten DocumentEntry-Metadaten) erneut hochgeladen. Das neue Dokument erhält den Status „Approved“. Das alte Dokument geht in den Status „Deprecated“.  Beide Dokumente werden über eine „Replace“-Association miteinander verbunden, sodass nach dem Einstellen erkennbar ist, dass das neue Dokument das alte ersetzt. Lädt man erneut eine neue Fassung hoch, erhält man zwei Dokumente im Status "Deprecated" und das neueste im Status "Approved".
Alle alten Dokumente (Status "Deprecated") können nach wie vor gefunden und heruntergeladen werden. Einige Suchen erlauben das Filtern nach Status bzw. zeigen per Default auch nur Dokumente im Status „Approved“ an.

Eingestellt (im "Submission Set") wird zum einen das neue Dokument inkl. Metadaten und zum anderen eine Association vom Typ urn:ihe:iti:2007:AssociationType:RPLC, die auf das neue Dokument und das zu ersetzende, bestehende Dokument verweist und so die "Replace"-Beziehung herstellt.

XDS-Option "Folder Management" - Verwendung von Ordnern

Ordner können durch die Option "Folder Management" (XDS.b Document Source) verwendet werden. Bei der kategorienbasierten Berechtigungsverwaltung werden vom Aktensystem definierte Ordner genutzt. Nur für dynamische Dokumentensammlungen (z. B. Kinderuntersuchungsheft und Mutterpass) werden Ordner durch Primärsysteme erstellt und vom FrontendDie Zuordnung von Dokumenten zu Ordnern im Aktensystem erfolgt durch die Metadaten des Dokuments. Dynamische Ordner werden durch Primärsysteme (Mutterpass) oder Aktensystem (DiGA) erstellt und vom FdV ggf. ausgewertet. Durch die Assoziation eines Dokumentes zu einem dieser Ordner wird das Dokument dem Ordner der entsprechenden Dokumentenkategorie bzw. DokumentensammlungDatenkategorie bzw. Sammlung zugeordnet.

Die XDS-Option "Folder Management" ist nur für den geschilderten Verwendungszweck zugelassen; ein selbständiges Anlegen oder Bearbeiten von Ordnern und ihrer Metadaten ist durch das FdV nicht möglich. Das Entfernen von Dokumenten aus einem Ordner durch Löschen der entsprechenden Assoziation ist nicht vorgesehen, da dies die direkte Zuordnung gemäß einer Zugriffsunterbindungsregel verletzten könnte.

Weitere Festlegungen

Weitere übergreifenden Einschränkungen von IHE ITI-Transaktionen sowie Festlegungen spezieller Umsetzungsvorgaben bzgl. einzelner Transaktionen sind in [gemSpec_DM_ePA] und [gemSpec_Dokumentenverwaltung] ]beschrieben.

Wenn im Rahmen der IHE InterfaceSchnittstellen-Beschreibung der Begriff "Patient" verwendet wird, ist im Rahmen der vorliegenden Spezifikation darunter der Aktenkontoinhaber zu verstehen.

Im ePA-Frontend des Versicherten werden fachliche Dokumente (Versichertendokumente) und technische Dokumente (Policy Documents) unterschieden.

5.3.1 Policy Documents

Die Fachanwendung ePA verwendet das APPC-Profil für die Durchsetzung von Zugriffsregeln (Autorisierung) auf Dokumente. Die Zugriffsregeln werden gemäß APPC in Policy Documents beschrieben und als technische Dokumente im Aktenkonto des Versicherten hinterlegt.

Für jeden Vertreter, jede berechtigte Leistungserbringerinstitution (LEI), den berechtigten Kostenträger (KTR) und jede berechtigte Digitale Gesundheitsanwendung (DiGA) wird je ein Policy Document im Aktenkonto verwaltet.

Bei der Neuvergabe einer Berechtigung für Vertreter, LEI, DiGA oder KTR erstellt das ePA-Frontend des Versicherten ein neues Policy Document und lädt es in das Aktenkonto hoch. Bei der Änderung einer Berechtigung (bspw. Verlängerung der Berechtigungsdauer) lädt das ePA-Frontend des Versicherten das Policy Document aus der ePA-Dokumentenverwaltung herunter (IHE-Akteur Content Consumer), bearbeitet es und lädt die veränderte Fassung als neu zu registrierendes Policy Document in die ePA-Dokumentenverwaltung hoch (IHE APPC-Akteur Content Creator). Beim Hochladen einer veränderten Version eines Policy Document wird die vorherige Version infolge des Hochladens des neuen Policy Document automatisch durch die ePA-Dokumentenverwaltung gelöscht. Beim Entzug einer Berechtigung löscht das ePA-Frontend des Versicherten das entsprechende Policy Document aus der ePA-Dokumentenverwaltung. 

Die ePA-Dokumentenverwaltung wertet die in den Policy Documents hinterlegten Zugriffsregeln aus. Es entscheidet unter Berücksichtigung der Dokumentenmetadaten, ob der anfragende Nutzer den Dokumentenzugriff (bspw. Einstellen von Dokumenten) durchführen darf oder ob der Dokumentenzugriff ablehnt wird. Das ePA-Frontend des Versicherten verarbeitet Policy Documents nur intern.

A_15271-02 - ePA-Frontend des Versicherten: Keine Anzeige von Policy Documents

Das ePA-Frontend des Versicherten DARF Policy Documents an der Schnittstelle zum FdV NICHT herausgeben. [<=]

Für die XDS-Metadaten eines Policy Documents gelten die Nutzungsvorgaben aus [gemSpec_DM_ePA#A_14961-*].

A_15673-03 - ePA-Frontend des Versicherten: Policy Document für LEI erstellen

 Das ePA-Frontend des Versicherten MUSS für eine zu berechtigende LEI ein Policy Document unter Berücksichtigung der Anforderungen an deren Inhalt in A_15442-* erstellen.  [<=]

A_15674-03 - ePA-Frontend des Versicherten: Policy Document für Vertreter erstellen

Das ePA-Frontend des Versicherten MUSS für einen zu berechtigenden Vertreter ein Policy Document unter Berücksichtigung der Anforderungen an deren Inhalt in  A_15440-* erstellen. [<=]

A_17232-03 - ePA-Frontend des Versicherten: Policy Document für Kostenträger erstellen

 Das ePA-Frontend des Versicherten MUSS für einen zu berechtigenden Kostenträger ein Policy Document unter Berücksichtigung der Anforderungen an deren Inhalt in A_17460-* erstellen. [<=]

A_22995 - ePA-Frontend des Versicherten: Policy Document für DiGA erstellen

Das ePA-Frontend des Versicherten MUSS für eine zu berechtigende DiGA ein Policy Document unter Berücksichtigung der Anforderungen an deren Inhalt in A_22705-* erstellen. [<=]

5.4 Benutzeroberfläche

Die Benutzeroberfläche, welche durch den Versicherten genutzt wird, um ePA-Anwendungsfälle auszuführen, ist Teil des FdV.

Die folgenden Ausführungen zu Anforderungen an die visuelle Darstellung und Benutzerführung sind informativ und nicht normativ.

5.4.1 Visuelle Darstellung

Für die visuelle Darstellung der Inhalte ist eine grafische Benutzeroberfläche erforderlich, welche die Daten des Versicherten strukturiert und übersichtlich darstellt.

Das FdV soll eine einheitlich gestaltete Oberfläche zur Benutzerführung besitzen, um die Übersichtlichkeit in allen Anwendungsfällen für den Nutzer zu gewährleisten. Es soll Menüfunktionen, Texte und andere Anzeigen eindeutig, verständlich und widerspruchsfrei benennen bzw. darstellen.

Das FdV soll es dem Nutzer ermöglichen, zu jeder Zeit zu erkennen, in welchem ePA-Anwendungsfall sich die Applikation gerade befindet.

A_20968-02 - Unterstützung der ePA-Anwendungsfälle im Hintergrundmodus bei der Umschlüsselung

Das ePA-Frontend des Versicherten MUSS den Hintergrundmodus bei der Umschlüsselung, soweit es das Betriebssystem zulässt, unterstützen. [<=]

Hinweis:
Ist durch das Betriebssystem keine sichere und ausreichende Unterstützung des Hintergrundmodus möglich, kann die Ausführung im Vordergrund erfolgen.

A_20969 - Notwendige Permissions für den Hintergrundmodus

Das ePA-Frontend des Versicherten MUSS die notwendigen Permissions besitzen, die für eine fehlerfreie Funktion im Hintergrundmodus notwendig sind. [<=]

Sofern der Benutzer diese Permissions nicht schon bei der Installation freigegeben hat, ist die Freigabe beim Beginn längerer Aktionen einzuholen und zu aktivieren. Insbesondere ist dies bei der Umschlüsselung zu beachten, da sie länger dauern kann.

A_20970 - Hinweis zur Arbeitsweise im Hintergrundmodus

Das ePA-Frontend des Versicherten MUSS den Nutzer vor dem Beginn längerer Aktionen darauf hinweisen, dass die Aktion im Hintergrund weiter läuft und die Anwendung während dieser Zeit nicht beendet oder deinstalliert und dass das Gerät während dieser Zeit nicht ausgeschaltet oder rebootet werden darf. [<=]

5.4.2 Benutzerführung

Die Bedienung des FdV soll für den Nutzer intuitiv gestaltet werden. Das FdV soll dem Nutzer alle anzeigbaren Texte mindestens in der Sprache Deutsch bereitstellen. 

DIN Normen und Verordnungen zur Beachtung:

Eine hohe Akzeptanz der Benutzerfreundlichkeit oder Usability wird durch eine einfache, selbsterklärende Bedienung der Oberfläche erreicht, die sich an gängigen Mustern des App-Designs orientiert.

Hierfür ist es auch erforderlich, die Erwartungshaltung der Zielgruppe zu kennen und zu berücksichtigen (z.B. auch Menschen mit körperlichen oder geistigen Einschränkungen).

Die Akzeptanz des Frontends für den Versicherten hängt in großem Maße von folgenden Faktoren ab:

1.                      Anwendbarkeit auf verschiedenen Bildschirmgrößen und Auflösungen
2.                      Intuitive und unkomplizierte Handhabung
3.                      Anwendbarkeit auch im Offline-Modus
4.                      Zielgruppenorientierung
5.                      Leichte und verständliche Bereitstellung von Informationen
6.                      Einhaltung ergonomischer Aspekte (z.B. kurze Touchwege)
7.                      Konsistente Gestaltung der Links, Buttons, etc.

5.4.2.1 Technische 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.

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

Insbesondere sollen die nachfolgend aufgeführten Teile der ISO 9241 berücksichtigt werden:

• 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

Für die Entwicklung eines barrierefreien Frontend des Versicherten ist insbesondere die Verordnung zur barrierefreien Gestaltung von Informationstechnik zu beachten.

BITV 2.0 - Barrierefreie Informationstechnik-Verordnung

Hinweis: Die Versionsnummern der aufgeführten Normen und Richtlinien spiegeln den Stand zum Zeitpunkt der Erstellung dieses Dokumentes wider.

Die seit 2018 bestehende umfassende Forderung nach Umsetzung von Barrierefreiheit in der Informationstechnik erwächst aus der EU Richtlinie 2016/2102 zur „Barrierefreiheit von Webseiten und mobiler Anwendungen öffentlicher Stellen“. Diese Richtlinie musste im Jahr 2018 in Bundes- und Landesrecht übertragen werden. – Diese Gesetze verweisen jeweils auf die Barrierefreie Informationstechnik-Verordnung mit Ausgabe vom 21. Mai 2019 (BITV 2.0).

Zur Erfüllung der BITV 2.0 § 3 Abs. 2 ist die durch die Veröffentlichung im europäischen Amtsblatt harmonisierte EN 301549 „Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen“ (V 2.1.2 von 2018-08) anzuwenden. Diese liegt in der Fassung von 2020-02 als DIN EN 301549 als deutsche Übersetzung vor. Die DIN EN 301549 ist eine Beschaffungsnorm. Die darin aufgeführten und für den Anwendungsfall des FdV des E-Rezepts anzuwendenden Erfolgskriterien sind in Kapitel 9 (Web mit 50 Erfolgskriterien), Kapitel 10 (Dokumente mit 46 Erfolgskriterien) und Kapitel 11 (Nicht webbasierte Software mit 44 Erfolgskriterien) aufgeführt. Sie entsprechen den Erfolgskriterien von Level AA der 2.1. WCAG 2.1 (Web Content Accessibility Guidelines).

Der sachliche Geltungsbereich der BITV 2.0 umfasst folgende relevanten Anwendungsbereiche für diese Spezifikation:

• Webseiten,
• nicht webbasierte Software mit mobilen Anwendungen.

Folgende Gestaltungsmerkmale der Anwendungen stellen die Barrierefreiheit sicher: 

• wahrnehmbar,
• bedienbar,
• verständlich und
• robust.    

In den genannten Normen und Standards werden nebeneinander die Belange von in der Handmotorik eingeschränkter, blinder, sehbehinderter, gehörloser, schwerhöriger, geistig und lernbehinderter Menschen berücksichtigt.

Nach BITV 2.0 müssen Dokumente, die über dem FdV angezeigt werden, die gleichen Anforderungen an die Barrierefreiheit erfüllen, wie sie an die Anwendung gestellt werden. Sämtliche bereitgestellten Dokumente müssen als barrierefreie Formate angeboten werden, die mit dem Screenreader lesbar und navigierbar sind. Hierbei müssen die behinderungsspezifischen Standardsoftwares zur Herstellung von Zugänglichkeit berücksichtigt werden.

Allgemeine Anforderungen an die Benutzerfreundlichkeit

A_20092 - ePA-Frontend des Versicherten: Intuitive Bedienung

Die Bedienung des ePA-Frontend des Versicherten SOLL für den Nutzer intuitiv gestaltet werden. [<=]

A_20094 - ePA Frontend des Versicherten: Bereitstellung Sprachen

Das ePA-Frontend des Versicherten SOLL dem Nutzer alle anzeigbaren Texte in der Sprache Deutsch bereitstellen. [<=]

Zusätzliche Sprachen können unterstützt werden.

A_20095-02 - ePA-Frontend des Versicherten: Abbruch Anwendungsfälle

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Anwendungsfälle auch vor dem Ende der Verarbeitung jederzeit abzubrechen. [<=]

A_20096 - ePA-Frontend des Versicherten: Arten der Verwaltung

Das ePA-Frontend des Versicherten SOLL dem Nutzer anzeigen, welche Arten von Dokumentenzugriffen und Verwaltungsfunktionen ausgeführt werden können. [<=]

A_20097 - ePA-Frontend des Versicherten: Bezeichnung der Anwendungsfälle

Das ePA-Frontend des Versicherten MUSS für die Inhalte und Anwendungsfälle eindeutige und verständliche Bezeichnungen verwenden. [<=]

Bezeichnungen sollen nach Möglichkeit vollständig ausgeschrieben sein, Abkürzungen sind zu vermeiden.

A_20098 - ePA-Frontend des Versicherten: Navigierbarkeit bereitgestellter Inhalte

Das ePA-Frontend des Versicherten SOLL sicherstellen, dass bereitgestellte Inhalte maschinenlesbar und navigierbar sind, um dem Nutzer eine barrierefreie Bedienung zu ermöglichen. [<=]

A_20099 - ePA-Frontend des Versicherten: Nutzung Gerätefunktionalitäten

Das ePA-Frontend des Versicherten SOLL gerätespezifische Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) sinnvoll nutzen und unterstützen. [<=]

A_20100 - ePA-Frontend des Versicherten: Nutzung Schnittstellen Bedienungsmöglichkeiten des Betriebssystems

Das ePA-Frontend des Versicherten SOLL die Schnittstellen für die Unterstützung der barrierefreien Bedienungsmöglichkeit, welche vom Betriebssystem zur Verfügung gestellt werden, nutzen. [<=]

A_20101 - ePA-Frontend des Versicherten: Nutzung Bedienhilfen des Betriebssystems

Das ePA-Frontend des Versicherten SOLL die Bedienhilfen der verwendeten Betriebssysteme zur barrierefreien Nutzung verwenden. [<=]

A_20102 - ePA-Frontend des Versicherten: Kontrastverhältnis

Das ePA-Frontend des Versicherten SOLL für das GUI ein Kontrastverhältnis verwenden, welches unter verschiedenen Bedingungen eine optimale Ablesbarkeit gewährleistet. [<=]

A_20103 - ePA-Frontend des Versicherten: Hinweise

Das ePA-Frontend des Versicherten SOLL dem Nutzer Hinweise anzeigen, die den Zweck sowie den inhaltlichen Ablauf eines Anwendungsfalls betreffen, um dem Nutzer die Bedienung zu vereinfachen. [<=]

Um dem Nutzer die Bedienung zu vereinfachen, sollen ihm Hinweise angezeigt werden, die den Zweck sowie den inhaltlichen Ablauf eines Anwendungsfalls betreffen.

Ist ein Anwendungsfall durchgeführt worden, muss das FdV das Ergebnis für den Versicherten klar verständlich anzeigen, z. B. "Die Vertretung wurde erfolgreich eingerichtet.".

Ist ein Anwendungsfall durch den Nutzer abgebrochen worden oder technisch nicht durchführbar, muss der Nutzer ebenfalls einen für ihn verständlichen Hinweis erhalten. In jedem Fall muss das Ergebnis für den Nutzer klar erkennbar sein.

Ist ein Anwendungsfall durch den Versicherten abgebrochen worden oder technisch nicht durchführbar, muss der Versicherte ebenfalls einen für ihn verständlichen Hinweis erhalten. In jedem Fall muss das Ergebnis für den Versicherten klar erkennbar sein.

Für die Anzeige in Fehlerfällen siehe Kapitel "6.2.2 Fehlerbehandlung".

Zur Sicherstellung, dass keine Daten versehentlich gelöscht werden, soll der Nutzer nach der Auswahl der Löschen-Funktion für Dokumente darauf hingewiesen werden, dass es sich hierbei um eine unwiderrufliche Aktion handelt.

5.4.3 Anzeige von Dokumenten

Der Nutzer kann nach Dokumenten in der ePA suchen und diese herunterladen oder sich anzeigen lassen.

A_18257 - ePA-Frontend des Versicherten: Dokumentengrösse an Aussenschnittstellen

Das ePA-Frontend des Versicherten MUSS für alle Außenschnittstellen, welche für Dokumente in ePA-Anwendungsfälle genutzt werden, Dokumente mit einer Größe von mindestens 25 MB unterstützen. [<=]

A_17226 - ePA-Frontend des Versicherten: Anzeige Metadaten von Dokumenten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die zu einem Dokument zugehörigen Metadaten mit fachlichen Informationen einzusehen. [<=]

Technische Metadaten zu einem Dokument müssen nicht angezeigt werden.

A_15284 - ePA-Frontend des Versicherten: Anzeige von Dokumenten

Das ePA-Frontend des Versicherten SOLL Standardprogramme zur Anzeige von aus der ePA heruntergeladenen Dokumenten verwenden. [<=]

Für die Anzeige der Dokumente werden die auf dem Gerät des Versicherten (GdV) verfügbaren Standardprogramme verwendet. Unter einem Standardprogramm wird das im GdV mit einem Dokumenttypen verknüpfte Programm verstanden (z.B. Dateityp PDF mittels eines auf dem GdV verfügbaren PDF Reader). Das FdV braucht keine Funktionalität zur Anzeige von Dokumenten in beliebigem Format bereitstellen.

Ist kein Programm zur Anzeige des Dokumentenformates auf dem GdV verfügbar, dann kann der Nutzer das Dokument nur lokal speichern.

A_15285 - ePA-Frontend des Versicherten: Anzeige strukturierter Dokumente

Das ePA-Frontend des Versicherten MUSS für strukturierte Dokumente eine für den Nutzer lesbare Darstellung mit dem vollständigen Inhalt des Dokumentes generieren und dem Nutzer anzeigen können. [<=]

Für Informationen zu strukturierten Dokumenten siehe [A_14761-*].

Wenn ein Arztbrief Dokument mit xml- und pdf-Anteil vorliegt, muss nur das PDF angezeigt werden.

Der Nutzer kann Dokumente in die ePA einstellen. Dafür müssen diese im FdV ausgewählt werden.

A_22974 - ePA-Frontend des Versicherten: Keine Anzeige von Dokumenten des Ordners "technical"

Das ePA-Frontend des Versicherten DARF einem Nutzer die Dokumente und Metadaten der Dokumente des Ordners "technical" NICHT zur Anzeige anbieten oder anzeigen.  [<=]

5.4.4 SammlungenDrucken und Speichern von Verwaltungs- und Inhaltsdaten

Als Sammlung gemäß [] wird eine Zusammenstellung von Dokumenten verstanden, die in ihrer Gesamtheit betrachtet, berechtigt oder anderweitig besonders behandelt werden müssen. Zum Beispiel werden einzelne Einträge im Impfpass als separate Dokumente in ePA abgelegt. Als Sammlung "Impfpass" unterliegen sie jedoch bestimmten Verarbeitungsregeln. Beispiele für andere Sammlungen sind der Mutterpass oder das Kinderuntersuchungsheft. Je nach Verarbeitungsvorgaben für einzelne Sammlungen werden drei Sammlungstypen ("mixed", "uniform" und "atomic") eingeführt. Bestehende strukturierte Dokumente werden einem dieser Typen zugeordnet, weitere strukturierte Dokumente und ihre Sammlungstypen können konfiguriert werden. Weitere Details finden sich in []. 

Für das Erteilen einer Berechtigung für eine LEI auf einen Pass gilt das analog, d.h., das ePA-Frontend des Versicherten muss die Erteilung einer Berechtigung zum Zugriff auf einen Pass in seiner Gesamtheit durch eine LEI unterstützen. Dies wird in Anforderung A_19686-* geregelt.In der ePA für alle wird grundsätzlich unterschieden zwischen Daten, die für den Versicherten inhaltlich relevant sind, und Daten, die der Verwaltung dieser Inhaltsdaten dienen.
Inhaltsdaten sind beispielsweise medizinische Dokumente, wie Arztbrief, Daten des Medikationsprozesses oder des Kostenträgers. Verwaltungsdaten sind beispielsweise Informationen zu Widersprüchen oder zur Zugriffssteuerung (Verbergen und Sichtbar machen), aber auch eine Liste der aktuell hinterlegten Befugnisse oder ein Ergebnis der Suche nach Dokumenten.

A_24426 - ePA-Frontend des Versicherten: Drucken und Speichern von Verwaltungs- und Inhaltsdaten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Verwaltungs- und Inhaltsdaten auszudrucken oder lokal zu speichern. [<=]

5.4.5 Sammlungen

Strukturierte Dokumente sind Dokumente, die Inhalte nach einem festgelegten Format dokumentieren. Diese werden durch Implementation Guides für strukturierte Dokumente [gemSpec_IG_ePA] eindeutig identifiziert. Eine besondere Form von strukturierten Dokumenten sind Sammlungen. 
Als Sammlung gemäß [ ] wird eine Zusammenstellung von strukturierten Dokumenten verstanden, die in ihrer Gesamtheit betrachtet, verborgen oder anderweitig besonders behandelt werden müssen. Das betrifft alle Sammlungen vom Typ "uniform" und "mixed". Zum Beispiel werden einzelne Einträge im Impfpass als separate Dokumente in der ePA abgelegt. Als Sammlung "Impfpass" unterliegen sie jedoch bestimmten Verarbeitungsregeln. Beispiele für andere Sammlungen sind der Mutterpass oder das Kinderuntersuchungsheft.  

A_19897-01 - ePA-Frontend des Versicherten: Anzeige von Sammlungsinstanzen vom Typ "mixed" und "uniform"

Das ePA-Frontend des Versicherten MUSS für eine für den Nutzer lesbare Darstellung mit dem vollständigen Inhalt aller zur Sammlungsinstanz gehörenden Dokumente generieren und dem Nutzer anzeigen können. [<=]

A_19898-01 - ePA-Frontend des Versicherten: Sammlungsinstanzen drucken oder speichern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine Sammlungsinstanz lokal zu drucken oder zu speichern. [<=]

Das lokale Speichern kann im PDF-Format angeboten werden.

A_19961-01 - ePA-Frontend des Versicherten: Löschen einer Sammlungsinstanz

Das ePA-Frontend des Versicherten MUSS einen Nutzer beim Löschen einer Sammlungsinstanz, insbesondere dem gesamtheitlichen Löschen bei Instanzen des Typs "mixed" und "uniform", unterstützen. [<=]

Das Löschen einer Sammlungsinstanz umfasst das Löschen aller zur Instanz gehörenden Dokumente.

5.4.5Das Löschen einer Sammlungsinstanz umfasst das Löschen aller zur Instanz gehörenden Dokumente.

A_19961-02 - ePA-Frontend des Versicherten: Löschen einer Sammlungsinstanz

Das ePA-Frontend des Versicherten MUSS einen Nutzer beim Löschen einer Sammlungsinstanz, dem gesamtheitlichen Löschen bei Instanzen des Typs "mixed" und "uniform", unterstützen. [<=]

Für das Verbergen der Sichtbarkeit auf eine Sammlung vom Typ "uniform" und "mixed" muss das ePA-Frontend des Versicherten die Sammlung in ihrer Gesamtheit unterstützen.

A_24458 - ePA-Frontend des Versicherten: Verbergen einer Sammlung vom Typ "mixed" oder "uniform"

Das ePA-Frontend des Versicherten MUSS einen Nutzer unterstützen, eine Sammlung vom Typ "mixed" oder "uniform" zu verbergen bzw. sichtbar zu machen. [<=]

Hat eine Sammlung vom Typ "uniform" die "folderCardinality.max"=1 gemäß [gemSpec_IG_ePA], dann gibt es nur eine Instanz dieser Sammlung, welche gleichbedeutend mit dem statischen Ordner, also der Datenkategorie ist. Ein Impfpass wird demzufolge verborgen, indem der Ordner mit code="prescription" verborgen wird.

Hat eine Sammlung vom Typ "uniform" die "folderCardinality.max" >1 gemäß [gemSpec_IG_ePA], dann kann es mehrere Instanzen dieser Sammlung geben. Jede Instanz wird durch einen dynamischen Ordner abgebildet, welcher sich innerhalb der Datenkategorie befindet. Ein Mutterpass wird demzufolge verborgen, indem der dynamische Ordner des Mutterpasses verborgen wird. Wird die Datenkategorie "mothersrecord" verborgen, dann werden alle in dieser Kategorie enthaltenen Mutterpässe verborgen.

5.4.6 Nutzungsvorgaben für IHE ITI XDS-Metadaten

5.4.6.1 Metadaten für einzustellende Dokumente

Für Dokumente, welche durch den Nutzer in die ePA eingestellt werden, sind Metadaten anzugeben, auf deren Basis Dokumente nachfolgend gesucht und heruntergeladen werden können.

Die XDS-Metadaten und ihre Nutzungsvorgaben sind in [gemSpec_DM_ePA ] beschrieben.
Es kann auf die Anzeige einzelner nutzbarer Metadatenattribute verzichtet werden, um eine übersichtliche Darstellung beim Einstellen der Dokumente zu erreichen.

Das FdV soll für die Eingabe von Metadaten required-Attribute als Pflichtfelder kennzeichnen. Dabei soll unterschieden werden zwischen einer einer einfachen Ansicht für das Einstellen von Dokumenten des Versicherten und einer erweiterten Ansicht für das Einstellen von LE-Dokumenten durch den Versicherten. Vorgaben dazu werden in [gemSpec_DM_ePA] getroffen.

Defaultmäßig wird der Nutzer als Submission Set author (Einstellender) gesetzt. Die Werte für den author werden mindestens mit den Informationen givenname, surname und title aus den subject des C.CH.AUT bzw. C.CH.AUT_ALT Zertifikates vorbelegt. Das Zertifikat wird im Anwendungsfall "Login Aktensession" in die Session-Daten übernommen vorbelegt.

Entsprechend den Nutzungsvorgaben für die Verwendung von XDS-Metadaten sind für einzelne Attribute Value Sets zu verwenden. Für eine bessere Bedienbarkeit bei der Eingabe der Metadaten werden die in der GUI auswählbaren Werte defaultmäßig auf einen Teil des Value Sets gemäß [Anhang B - Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets]  eingeschränkt. Über die Konfiguration des FdV hat der Nutzer die Möglichkeit, die anzuzeigenden Werte zu ändern, d.h. nicht angezeigte Werte aus dem Value Set hinzuzunehmen oder angezeigte Werte zu verbergen.

Das FdV soll dem Nutzer in der GUI für Attribute von Metadaten, welche entsprechend einem Value Set belegt werden, eine konfigurierbare Auswahl anbieten. Wenn das Attribut optional ist, dann muss die Auswahl einen leeren Eintrag beinhalten.

Dokumente, die vom Versicherten am FdV eingestellt werden, werden vom Aktensystem entsprechend der verwendeten Metadaten in die Kategorien bzw. die FolderDatenkategorien "patientdoc", oder "childsrecord"  oder "eGA" eingeordnet, da sie mit  (submissionset.authorRole = 102 eingestellt werden). Zusätzliche Metadaten können Dokumente als medizinisch relevante Dokumente auszeichnen, etwa als Arztbrief, ohne dass sie deswegen in Ordner einsortiert werden, die für DokumentenkategorienDatenkategorien der Leistungserbringer stehen. 

Das Frontend kann den Nutzer auch durch eine sinnvolle Vorauswahl bei der Klassifizierung und Typisierung unterstützen, insbesondere falls Versicherte Dokumente in ihre Akte einstellen wollen, die ursprünglich von anderen Leistungserbringern erstellt wurden, etwa Arztbriefe, die der Versicherte in Kopie erhalten hat.

A_15291 - ePA-Frontend des Versicherten: Schlüsselwerte aus Value Sets decodieren

Das ePA-Frontend des Versicherten MUSS Schlüsselwerte aus Value Sets decodieren und in einem für den Nutzer verständlichen Text anzeigen. [<=]

Ggf. kann dazu bei unbekannten Codes der Anzeigename eines Codes (sofern mit übertragen bzw. verfügbar) angezeigt werden.

5.4.6.2 Metadaten für existierende Dokumente

Für bereits in die ePA eingestellte Dokumente können Metadaten geändert werden.

Eine Änderung von Metadaten führt zu einer erneuten Prüfung der bestehenden Zuordnung des Dokuments und kann somit eine andere Zuordnung zur Folge haben.

5.4.7 Konfiguration des ePA-Frontend des Versicherten

Im Folgenden sind Konfigurationsparameter beschrieben, deren Werte für die Nutzung der Schnittstellen benötigt werden. Darüber hinaus kann der Hersteller des ePA-Frontend des Versicherten zusätzliche Konfigurationsparameter definieren.

A_15292-0506 - ePA-Frontend des Versicherten: Parameter speichern und laden

Das ePA-Frontend des Versicherten MUSS die folgenden Parameter aus TAB_FdV_104 persistent speichern und bei der Initialisierung laden.

Tabelle 5: TAB_FdV_104 – Parameter FdV 

[<=]

Entsprechend dem für die Akten-ID spezifizierten Format, besitzt die Akten-ID einen variablen und einen konstanten Anteil. Der variable Anteil entspricht der Versicherten-ID, welche bspw. auf der eGK des Versicherten aufgedruckt ist. Das Erfassen der Akten-ID kann auf die Versicherten-ID beschränkt werden und automatisch um die konstanten Anteile ergänzt werden.

A_15293 - ePA-Frontend des Versicherten: Konfigurationsparameter verwalten

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, die nicht automatisch bestimmbaren Parameter aus TAB_FdV_104A_15292* zu verwalten (anzeigen, ändern, löschen). [<=]

A_17088-0124588 - ePA-Frontend des Versicherten: Kopplung an spezifisches ePA-AktensystemLokalisierung eines Aktenkontos

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, die Lokalisierungsinformation für ein gewünschtes Aktenkonto (Vertreterszenario) durch Abruf der herstellerspezifischen Schnittstelle gemäß A_24801* am ePA-Aktensystem zu ermitteln. [<=]

Der Hersteller des ePA-Frontend des Versicherten KANN den Wertebereich für die Parameter zur Identifikation des zu nutzenden ePA-Aktensystems fest vorgeben und eine Konfiguration durch den Nutzer einschränken. [<=]

Das entspricht den folgenden Parametern aus TAB_FdV_104 für Aktenkontoinhaber:

•   FQDN Anbieter ePA-Aktensystem, 

•   Anbieter-ID.

Ein FdV kann an ein oder mehrere ePA-Aktensysteme gekoppelt werdenDie Operation zur Ermittlung der Liste aller Kostenträger und der FQDN, unter der deren ePA-Aktensystem im Internet erreichbar ist wird nicht normativ vorgegeben, sondern ist herstellerspezifisch.

A_23209 - Konfiguration SSO durch den Nutzer

Das ePA-FdV MUSS sicherstellen, dass der Nutzer konfigurieren kann, für welche Fachdienste er seine Zustimmung für ein SSO erteilt, diese Konfiguration persistent speichern und bei der Initialisierung laden. [<=]

A_25047 - ePA-Frontend des Versicherten: Default-Einstellung kein SSO

Das ePA-FdV MUSS sicherstellen, dass in der Default-Einstellung kein SSO konfiguriert ist und somit für jeden Fachdienst eine explizite Authentisierung des Nutzers erforderlich ist. [<=]

A_25048 - ePA-Frontend des Versicherten: Information des Nutzers über SSO

Das ePA-FdV MUSS den Nutzer im ePA-FdV mindestens vor der ersten Nutzung eines SSO über die Sicherheitskonsequenzen bei der Nutzung eines SSO informieren. [<=]

5.5 Bereitstellung für UX-Messdaten

Zur Verbesserung der User Experience werden Messdaten erfasst und an das Aktensystem übertragen. Dabei werden folgende Anwendungsfälle betrachtet:

A_24669 - ePA-Frontend des Versicherten: UX-Messdaten erfassen

Das ePA-Frontend des Versicherten MUSS bei Durchführung der Anwendungsfälle aus Tab_UX_KPI_Messung_ePA die in der Spalte "Beschreibung" beschriebene Messung durchführen und das Ergebnis in Millisekunden speichern.

Tabelle 6 : Tab_UX_KPI_Messung_ePA

UX-Anwendungsfälle	Beschreibung
UX_Login_V	Es wird der Zeitraum gemessen, den ein Nutzer nach der Auswahl einer ePA warten muss, bis die angeforderte Akte geöffnet ist. Dabei beginnt die Messung mit der letzten Versicherteninteraktion (z. B. Antippen eines Feldes "ePA mit KVNR A12345680") bevor die Akte geöffnet wird und endet mit der Anzeige von Inhalten der Akte (z. B. der Information über Aktivitäten seit dem letzten Login, Dokumentenübersicht, allgemeine Informationen zur Akte wie Anzahl Befugnisse, Anzahl Dokumente).
UX_Doc_Upload_V	Es wird der Zeitraum gemessen, den ein Nutzer nach dem Befehl zum Hochladen eines Dokumentes warten muss, bis dieses Dokument in der ePA sichtbar ist oder die Information über den Erfolg/Misserfolg der Operation angezeigt wird.
UX_Doc_Download_V	Es wird der Zeitraum gemessen, den ein Nutzer nach dem Befehl zum Herunterladen eines Dokumentes warten muss, bis dieses Dokument vollständig heruntergeladen wurde.
UX_LEI_search	Es wird der Zeitraum gemessen, den ein Nutzer nach der Eingabe von Suchparametern warten muss, bis die ersten Suchergebnisse angezeigt werden.

Es sind ausschließlich Anwendungsfälle von Nutzern zu berücksichtigen, bei denen sie das zu ihrem FdV zugehörige Aktensystem nutzen. Vertreter-Szenarios, in denen ein Nutzer über sein FdV mit einem anderen Aktensystem kommuniziert, sind nicht zu berücksichtigen.
[<=]

A_24670 - ePA-Frontend des Versicherten: UX-Messdaten übertragen

Das ePA-Frontend des Versicherten MUSS unmittelbar nach erfolgreicher Durchführung der UX-Anwendungsfälle das Messergebnis im Hintergrund an das gleiche Aktensystem übermitteln und den gespeicherten Wert löschen, sofern die Übermittlung erfolgreich war.  [<=]

Hinweis:  Die Schnittstelle zur Übermittlung der Messwerte zwischen FdV und Aktensystem ist nicht normiert, da die Entwicklung von FdVs und Aktensystem je Kasse abgestimmt erfolgt.
"Im Hintergrund" bedeutet, dass die Übermittlung einerseits automatisch (ohne Nutzerinteraktion) geschieht und andererseits für den Nutzer auch keine "Wartezeit" entsteht.

6 Funktionsmerkmale

6.1 Allgemein

6.1.1 Aktensession-VerwaltungKommunikation mit dem ePA-Aktensystem

Eine Aktensession in einemDas ePA-Frontend des Versicherten  bezeichnet die Sitzung eines Nutzers, in der dieser fachliche Anwendungsfälle im Aktenkonto eines Versicherten ausführt. Hierbei kann es sich um das Aktenkonto des Nutzers selber (Nutzer ist Aktenkontoinhaber) oder um das Aktenkonto eines zu vertretenden Versicherten handeln, wenn dieser eine entsprechende Vertretung für den Nutzer eingerichtet hat.

Ein Aktenkonto wird eindeutig durch eine Akten-ID (RecordIdentifier, siehe ) referenziert. Der RecordIdentifier für sein eigenes Aktenkonto wird dem Versicherten als Ergebnis der Eröffnung des Aktenkontos mitgeteilt. Wenn der Nutzer die Vertretung eines anderen Versicherten wahrnimmt, dann erhält der Nutzer den RecordIdentifier von dem zu Vertretenden.

Eine Aktensession im ePA-Frontend des Versicherten beginnt mit dem Login und endet mit dem Logout des Nutzers aus dem Aktenkonto. Das Logout erfolgt auf Wunsch des Nutzers, mittels eines Time-outs oder nach einem Fehler beim Login.

A_15294-01 - ePA-Frontend des Versicherten: Login nach Notwendigkeit

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Login Aktensession" vor der Ausführung einer fachlichen Operation, welche eine Kommunikation mit dem ePA-Aktensystem beinhaltet, starten, wenn im Rahmen der internen Session-Verwaltung keine gültigen Session-Daten vorhanden sind. [<=]

Das Login kann explizit nach Auswahl eines Aktenkontos im FdV durch den Nutzer ausgeführt werdennutzt TLS-Verbindungen für die Kommunikation zum ePA-Aktensystem. Es verbindet sich mit der Komponente Access Gateway des ePA-Aktensystems. Das ePA-Frontend des Versicherten führt eine Authentisierung des Servers durch, wobei sich das Access Gateway mittels eines öffentlich prüfbaren Zertifikats authentisiert. Für die TLS-Verbindung gelten die Vorgaben aus [gemSpec_Krypt].

Im Falle einer Vertretung wird dem Vertreter durch das ePA-Aktensystem der Name des Anbieters für den Zugriff auf das ePA-Aktensystem mitgeteilt, damit der Vertreter beim Login den relevanten Anbieter aus der Anbieterliste auswählen kann.

A_1750515302-02 - ePA-Frontend des Versicherten für mobile Plattformen: Auswahl kryptographische Versichertenidentität: Lokalisierung Access Gateway

Das ePA-Frontend des Versicherten MUSS dem Nutzer die Möglichkeit geben, für eine Aktensession anstelle der eGK eine von einem Signaturdienst erzeugte alternative kryptografische Identität des Versicherten zu verwenden, falls der Nutzer diese alternative kryptographische Versichertenidentität zuvor im ePA-Frontend des Versicherten bekannt gemacht hat. [<=]

A_21830 - ePA-FdV für Desktop-Plattformen: optionale Auswahl kryptographische Versichertenidentität

Das ePA-Frontend des Versicherten für Desktop-Plattformen KANN dem Nutzer die Möglichkeit geben, für eine Aktensession anstelle der eGK eine von einem Signaturdienst erzeugte alternative kryptografische Identität des Versicherten zu verwenden, falls der Nutzer diese alternative kryptographische Versichertenidentität zuvor im ePA-Frontend des Versicherten für Desktop-Plattformen bekannt gemacht hatden Endpunkt für die Kommunikation mit dem Access Gateway mittels des Mechanismus gemäß [A_22688-*] ermitteln. [<=]

Falls eine Auswahl zwischen eGK und alternativer kryptographische Versichertenidentität durch den Nutzer getroffen wurde, kann diese in der Konfiguration gespeichert werden.

A_15295-01 - ePA-Frontend des Versicherten: Beenden der Session

Das ePA-Frontend des Versicherten MUSS zum Beenden der Aktensession den Anwendungsfall "Logout Aktensession" ausführen. [<=]

A_15296-01 - ePA-Frontend des Versicherten: Abmeldung des Nutzers nach Inaktivität

Das ePA-Frontend des Versicherten MUSS den Nutzer nach spätestens 20 Minuten Inaktivität (Zeitspanne nach der letzten Nutzer-Aktivität) automatisch abmelden und die Aktensession beenden. [<=]

Das FdV kann dem Nutzer vor der Abmeldung wegen Inaktivität einen Hinweis einblenden, der es dem Nutzer ermöglicht, die Aktensession fortzuführen.

Für die Dauer der Aktensession benötigt das ePA-Frontend des Versicherten einen gültigen Authentisierungstoken. Dieser wird in der Aktivität "Authentisieren des Nutzers" im Anwendungsfall "Login Aktensession" erstmalig ausgestellt. Der Authentisierungstoken hat eine Gültigkeitsdauer von 5 min und kann über einen Zeitraum von 120 min erneuert werden. Nach diesem Zeitraum muss sich der Nutzer neu authentisieren.

A_17543-01 - ePA-Frontend des Versicherten: periodisch Authentisierungstoken erneuern

Das ePA-Frontend des Versicherten MUSS vor Ablauf der Gültigkeit des Authentisierungstoken versuchen, mit der Aktivität "Authentisierungstoken erneuern" einen neuen Authentisierungstoken zu erhalten. [<=]

Der Zeitpunkt zum Erneuern soll so gewählt werden, dass bei einem Fehlschlagen der Operation je nach Fehlermeldung die Aktivität noch einmal ausgeführt werden kann, bzw. eine erneute Authentisierung gestartet werden kann.
Zu einer Aktensession im FdV gehören Session-Daten, welche für die Dauer der Aktensession vorzuhalten sind. Die Session-Daten beinhalten u.a. die in TAB_FdV_105 gelisteten Informationen. Eine vollständige Auflistung ist in "" beschrieben.für den FQDN mehrere IP-Adressen hinterlegt sind, wählt das ePA-Frontend des Versicherten zufällig eine der IP-Adressen als Endpunkt für den Verbindungsaufbau aus. Die Komponente Access Gateway weist bei Vollauslastung der Systemressourcen im ePA-Aktensystem die Verbindunganfrage ab. In diesem Fall kann das ePA-Frontend des Versicherten zufällig eine der weiteren IP-Adressen für einen neuen Verbindungsaufbau auswählen.
Jeder Anbieter eines ePA-Aktensystem verwaltet gemäß [A_22688-*] die Schnittstellen-Konfiguration des ePA-Aktensystems. Die einzelnen Module werden mit Key-/Value-Paaren mit den Kürzeln der folgenden Tabelle identifiziert:

Tabelle 6: TAB_FdV_105 – Session-Daten7: ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration

Die Informationen zu diesen Session-Daten ergeben sich aus dem Anwendungsfall "Login Aktensession".

Nach dem Ende der Aktensession (Anwendungsfall "Logout") werden die Session-Daten verworfen.

6.1.2 Kommunikation mit dem ePA-Aktensystem

Das ePA-Frontend des Versicherten nutzt TLS-Verbindungen für die Kommunikation zum ePA-Aktensystem. Es verbindet sich mit der Komponente Zugangsgateway des Versicherten. Das ePA-Frontend des Versicherten führt eine Authentisierung des Servers durch, wobei sich das Zugangsgateway mittels eines öffentlich prüfbaren Zertifikats authentisiert. Für die TLS-Verbindung gelten die Vorgaben aus [gemSpec_Krypt].

Im Falle einer Vertretung, muss der zu Vertretende dem Vertreter den Namen des Anbieters für den Zugriff auf das ePA-Aktensystem mitteilen, damit der Vertreter beim Login den relevanten Anbieter aus der Anbieterliste auswählen kann.

A_15302-02 - ePA-Frontend des Versicherten: Lokalisierung Zugangsgateway für Versicherte

Das ePA-Frontend des Versicherten MUSS den Endpunkt für die Kommunikation mit dem Zugangsgateway für Versicherte mittels des Mechanismus gemäß [gemSpec_Aktensystem#A_22688-*] ermitteln. [<=]

Falls für den FQDN mehrere IP-Adressen hinterlegt sind, wählt das ePA-Frontend des Versicherten zufällig eine der IP-Adressen als Endpunkt für den Verbindungsaufbau aus. Die Komponente Zugangsgateway des Versicherten weist bei Vollauslastung der Systemressourcen im ePA-Aktensystem die Verbindunganfrage ab. In diesem Fall kann das ePA-Frontend des Versicherten zufällig eine der weiteren IP-Adressen für einen neuen Verbindungsaufbau auswählen.
Jeder Anbieter eines ePA-Aktensystem verwaltet gemäß [gemSpec_Aktensystem#A_22688-*] die Schnittstellen-Konfiguration des ePA-Aktensystems. Die einzelnen Module werden mit Key-/Value-Paaren mit den Kürzeln in TAB_FdV_106 identifiziert.

Tabelle 7: TAB_FdV_106 – ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration

Die URL wird entsprechend den Vorgaben in URL wird entsprechend den Vorgaben in [  ] gebildet.

A_15297-01 - ePA-Frontend des Versicherten: Kommunikation über TLS-Verbindung

Das ePA-Frontend des Versicherten MUSS mit dem Zugangsgateway des VersichertenAccess Gateway ausschließlich über TLS kommunizieren. [<=]

A_15298-01 - ePA-Frontend des Versicherten: Unzulässige TLS-Verbindungen ablehnen

Das ePA-Frontend des Versicherten MUSS bei jedem Verbindungsaufbau das Zugangsgateway des VersichertenAccess Gateway anhand seines TLS-Zertifikats authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]

Das Zugangsgateway für VersicherteAccess Gateway authentisiert sich mit einem extended-validation-X.509-Zertifikat. Für Kriterien zur Prüfung des Zertifikates siehe "6.1.5 Zertifikatsprüfung".

Es gelten die Bedingungen für das TLS-Handshake gemäß [gemSpec_PKI#GS-A_4662].

A_15299-03 - ePA-Frontend des Versicherten: eine TLS-Session pro Aktensession

Das ePA-Frontend des Versicherten MUSS für jede Aktensession genau eine TLS-Session nutzen. [<=]

Für jede Aktensession kann eine separate TLS-Verbindung genutzt werden.

Für die Schlüsselgenerierung müssen der Schlüsselgenerierungsdienst (SGD) 1 und SGD 2 parallel angesprochen werden (siehe A_17994-01 ). Dafür baut das ePA-Frontend des Versicherten eine zweite TLS-Verbindung auf (siehe ), welche nach Abschluss der Schlüsselgenerierung wieder geschlossen wird.

A_15300-0115300-02 - ePA-Frontend des Versicherten: TLS-Verbindungsaufbau nach Notwendigkeit

Das ePA-Frontend des Versicherten MUSS eine TLS-Verbindung zum Zugangsgateway des VersichertenAccess Gateway aufbauen, wenn die ausgeführte Operation eine Kommunikation zum ePA-Aktensystem oder den zentralen Diensten der TI beinhaltet und keine TLS-Verbindung zum Zugangsgateway des VersichertenAccess Gateway für die AktensessionUser Session besteht. [<=]

A_15301-0102 - ePA-Frontend des Versicherten: TLS-Verbindung beenden

Das ePA-Frontend des Versicherten MUSS die für eine AktensessionUser Session aufgebaute TLS-Verbindung zum Zugangsgateway des VersichertenAccess Gateway schließen, wenn die AktensessionUser Session beendet wird. [<=]

A_15303-01 - ePA-Frontend des Versicherten: SOAP-Responses valide

Das ePA-Frontend des Versicherten MUSS bei allen SOAP-Responses eine Schemaprüfung durchführen und mit einer qualifizierten Fehlermeldung abbrechen, wenn die Nachricht nicht valide ist. [<=]

6.1.3 Sicherer Kanal zur Dokumentenverwaltung

Die Kommunikation zur Dokumentenverwaltung wird zusätzlich zu TLS über einen sicheren Kanal zwischen FdV und der Vertrauenswürdigen Ausführungsumgebung (VAU) in der Dokumentenverwaltung gesichert. Die Dokumentenverwaltung bietet dem FdV die folgenden Operationen ausschließlich über einen sicheren Kanal an:

•   I_Document_Management_Insurant::ProvideAndRegisterDocumentSet-b

•   I_Document_Management_Insurant::RegistryStoredQuery

•   I_Document_Management_Insurant::RemoveMetadata

•   I_Document_Management_Insurant::RetrieveDocumentSet

•   I_Document_Management_Insurant::RestrictedUpdateDocumentSet

•   I_Account_Management_Insurant::GetAuditEvents

•   I_Account_Management_Insurant::SuspendAccount

•   I_Account_Management_Insurant::ResumeAccount

•   I_Key_Management_Insurant::StartKeyChange

•   I_Key_Management_Insurant::GetAllDocumentKeys

•   I_Key_Management_Insurant::PutAllDocumentKeys

•   I_Key_Management_Insurant::FinishKeyChange

•   I_Document_Management_Connect::OpenContext

I_Document_Management_Connect::CloseContextA_24678 - ePA-Frontend des Versicherten:

Das ePA-Frontend des Versicherten MUSS  das HTTP Header Element mit dem Namen "x-useragent" bei jedem Request sowohl im HTTP-Header der VAU-Nachricht, als auch im HTTP-Header der Nachricht an den Service gemäß A_22470* senden. [<=]

6.1.2 Sicherer Kanal zur Aktenkontoverwaltung

Das ePA-Frontend des Versicherten kommuniziert als ePA-Client mit der Aktenkontoverwaltung in einer Vertrauenswürdigen Ausführungsumgebung (VAU). Diese stellt sicher, dass sensible Klartext-Daten wie z. B die medizinischen Daten des Versicherten sicher vor Angriffen verarbeitet werden können. Die Daten werden ausschließlich in einem VAU-Kanal zwischen ePA-Frontend des Versicherten und ePA-Aktensystem übertragen.

Das ePA-Frontend des Versicherten initiiert den Aufbau eines VAU-Kanals zum Aktensystem. Dabei authentisiert sich die VAU mit ihrem Zertifikat als authentische VAU des Aktensystems.

A_24557 - Frontend des Versicherten: Kommunikation mit der Vertrauenwürdigen Ausführungsumgebung (VAU)

Das Frontend des Versicherten MUSS als ePA-Client für die Kommunikation mit der Vertrauenswürdigen Ausführungsumgebung (VAU) die Vorgaben aus [gemSpec_Krypt#8 und #3.15] umsetzen. [<=]

Für Informationen zum Kommunikationsprotokoll zwischen dem ePA-Frontend des Versicherten  und einer VAU siehe und [].

Anschließend wird für den Nutzer, repräsentiert durch die GesundheitsID, mit Hilfe des sektoralen IDPs eine User Session angelegt. Diese User Session ermöglicht den Zugriff auf alle Aktenkonten des Aktensystems, sofern der Nutzer für diese befugt ist. Durch eine Anfrage an eine bestimmte Akte wird diese in der User Session als Health Record Context geladen und der Nutzer kann mit der Akte arbeiten.

Eine User Session in einem ePA-Frontend des Versicherten bezeichnet die Sitzung eines Nutzers, in der dieser fachliche Anwendungsfälle im Aktenkonto eines Versicherten ausführt. Hierbei kann es sich um das Aktenkonto des Nutzers selber (Nutzer ist Aktenkontoinhaber=Versicherter) oder um das Aktenkonto eines zu vertretenden Versicherten handeln, wenn dieser eine entsprechende Vertretung für den Nutzer eingerichtet hat. Die im Rahmen der User Session ausgehandelten Daten werden als Session-Daten bezeichnet.

Ein Aktenkonto wird eindeutig durch eine Akten-ID (unveränderbare Teil der KVNR; 10 Stellen) referenziert.

Eine User Session im ePA-Frontend des Versicherten beginnt mit dem Login und endet mit dem Logout des Nutzers oder einem impliziten Logout. Das Logout erfolgt auf Wunsch des Nutzers, mittels eines Time-outs oder nach einem Fehler beim Login.

A_15294-02 - ePA-Frontend des Versicherten: Login nach Notwendigkeit

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Login User" vor der Ausführung einer fachlichen Operation, welche eine Kommunikation mit dem ePA-Aktensystem beinhaltet, starten, wenn keine gültigen Session-Daten vorhanden sind. [<=]

A_15295-02 - ePA-Frontend des Versicherten: Beenden der User Session

Das ePA-Frontend des Versicherten MUSS zum Beenden der User Session den Anwendungsfall "Logout User" ausführen. [<=]

A_15296-02 - ePA-Frontend des Versicherten: Abmeldung des Nutzers nach Inaktivität

Das ePA-Frontend des Versicherten MUSS den Nutzer nach spätestens 20 Minuten Inaktivität (Zeitspanne nach der letzten Nutzer-Aktivität) automatisch abmelden und die User Session beenden. [<=]

Das FdV kann dem Nutzer vor der Abmeldung wegen Inaktivität einen Hinweis einblenden, der es dem Nutzer ermöglicht, die User Session fortzuführen.

Zu einer User Session im FdV gehören Session-Daten, welche für die Dauer der User Session vorzuhalten sind. Die Session-Daten beinhalten die ausgehandelten VAU-Schlüssel gemäß [].

Die Session-Daten ergeben sich aus dem Anwendungsfall "Login User".

Nach dem Ende der User Session (Anwendungsfall "Logout User") werden die Session-Daten verworfen.

A_15304-0102 - ePA-Frontend des Versicherten: Umsetzung sicherer Kanal zur DokumentenverwaltungAktenkontoverwaltung

Das ePA-Frontend des Versicherten MUSS dendie im Rahmen des sicheren Verbindungsaufbaus mit der Dokumentenverwaltungzur Aktenkontoverwaltung ausgehandelten Sitzungsschlüssel verwenden, um den HTTP Body aller über den sicheren Kanal zu sendenden Requests an die DokumentenverwaltungAktenkontoverwaltung zu verschlüsseln und alle über den sicheren Kanal gesendeten Responses von der DokumentenverwaltungAktenkontoverwaltung zu entschlüsseln. [<=]

Für Informationen zum Kommunikationsprotokoll zwischen dem ePA-Frontend des Versicherten  und einer VAU siehe und .

6.1.4 Geräteautorisierung

Um einen möglichen Missbrauch und Identitätsdiebstahl erkennen zu können, wird eine Berechtigungsprüfung auf Geräteebene auf Seiten der Versicherten umgesetzt. Der Zugriff auf ein Aktenkonto ist zulässig, wenn das Gerät, auf dem das FdV genutzt wird, durch den Nutzer über einen separaten Benachrichtigungskanal (E-Mail mit Freischalt-Link) zur Benutzung eines Aktenkontos autorisiert wurde. Siehe auch .6.1.3 Authentisierung

Zur Authentisierung des Nutzers wird ein Request an den Authorization Service im ePA-Aktensystem gesendet. Es folgt folgender Ablauf:

Abbildung 2 : Authentisieren des Nutzers

Das ePA FdV agiert generell analog zu anderen Anwendungsfrontends, welche gegenüber dem Authorization Server ihres Fachdienstes die Anmeldung des Nutzers über einen sektoralen Identity Provider der Föderation unterstützen. Dazu werden die generellen Anforderungen aus [gemSpec_IDP_Frontend#Kapitel ] konkretisiert bzw. sind für die Anwendung der elektronischen Patentenakte nicht relevant.

Das Authenticator-Modul übernimmt die Authentisierung des Nutzers gegenüber dem für den Versicherten zuständigen sektoralen IDP.

A_24829 - ePA-Frontend des Versicherten: Kenntnis über issuer ID des zugehörigen sektoralen IDP

Das Gerät wird durch die Gerätekennung (DeviceID) identifiziert. Die Gerätekennung beinhaltet die Geräteidentität und den Gerätenamen. Die Geräteidentität ist eine Zufallszahl, welche dem ePA-Frontend des Versicherten von der Autorisierung übermittelt wird. Der Gerätename ist ein bis zur 64 Zeichen langer String, welcher durch den Nutzer in der Konfiguration des ePA-Frontend des Versicherten hinterlegt wird (siehe A_15292-*)ePA-Frontend des Versicherten MUSS die Adresse des für die Authentisierung seiner Nutzer verantwortlichen sektoralen IDP kennen und bei Autorisierungsanfragen gegenüber allen Aktensystemen verwenden.  Dabei handelt es sich um die Identität (iss URL) des IDP innerhalb der Open-ID Connect Föderation der Telematikinfrastruktur. [<=]

Bevor im ePA-Aktensystem eine User Session für diesen Nutzer etabliert wird, erfolgt die Prüfung, ob das vom Nutzer verwendete Gerät registriert ist. Wenn nicht, dann wird die Geräteregistrierung gestartet.

Beim erstmaligen Login eines Nutzers von einem GdV wird die Gerätekennung mit leerem Geräteidentifikator (phr:DeviceID::Device) im Aufruf gesandt. Da noch kein bekannter Geräteidentifikator für dieses GdV in der Autorisierung registriert ist, antwortet die Autorisierung mit dem Fehler DEVICE_UNKNOWN und einer Zufallszahl im Fehlertext. Das ePA-Frontend des Versicherten speichert die Zufallszahl als Geräteidentifikator lokal und verwendet sie in allen Aufrufen gegenüber der Komponente Autorisierung6.1.4 Geräteregistrierung

Um einen möglichen Missbrauch und Identitätsdiebstahl erkennen zu können, wird eine Berechtigungsprüfung für das Gerät des Nutzers umgesetzt.  Hierzu wird bei erstmaliger Nutzung des Gerätes eine Geräteregistrierung am ePA-Aktensystem im Rahmen der Nutzerauthentisierung gestartet. Als Ergebnis wird an das FdV der deviceIdentifier als Gerätekennung und das deviceToken als Sicherheitsmerkmal zurückgegeben. Dieses deviceToken wird für den Nutzer im FdV persistent gespeichert und muss beim Login am ePA-Aktensystem mitgegeben werden.
Der Zugriff auf ein Aktenkonto ist zulässig, wenn das Gerät, auf dem das FdV genutzt wird, durch den Nutzer über einen separaten Benachrichtigungskanal (E-Mail mit Freischalt-Link) zur Benutzung eines Aktenkontos autorisiert wurde.

Ein Nutzer kann die Rolle Versicherter oder die Rolle Vertreter einnehmen. Hinsichtlich der Geräteregistrierung wird am selben Aktensystem nicht unterschieden, d. h. ein für den Versicherten registriertes Gerät ist für diesen in der Rolle Vertreter ebenfalls registriert und umgekehrt.

A_15305-0203 - ePA-Frontend des Versicherten: Geräteidentifikator abspeichernGeräteinformationen speichern

Das ePA-Frontend des Versicherten MUSS einen von der Komponente Autorisierung übermittelten Geräteidentifikator nutzer- und aktensystemspezifisch abspeichernFalls eine Geräteregistrierung als implizite Operation bei der Authentisierung des Nutzers erfolgt, MUSS das ePA-Frontend des Versicherten die Geräteinformationen persistent und sicher speichern. [<=]

A_15306-0224924 - ePA-Frontend des Versicherten: DeviceID bildenGeräteinformationen anzeigen

Das ePA-Frontend des Versicherten MUSS beim Start der Applikation nutzerspezifisch die DeviceID aus der Geräteidentität und dem Gerätenamen aus der Konfiguration bilden und für Aufrufe an der Schnittstelle zur Komponente Autorisierung verwenden. [<=]

Für die Struktur von DeviceID siehe [PHR_Common.xsd].Falls eine Geräteregistrierung als implizite Operation bei der Authentisierung des Nutzers erfolgt, MUSS das ePA-Frontend des Versicherten den Nutzer darüber informieren, dass der Nutzer die Geräteregistrierung bestätigen muss und ein Zugang zum ePA-Aktensystem erst nach erfolgter Verifikation durch den Nutzer möglich ist. [<=]

6.1.5 Zertifikatsprüfung

Das ePA-Frontend des Versicherten  verwendet bei den in TAB_FdV_110 dargestellten Aktivitäten Zertifikate.

Tabelle 8: TAB_FdV_110 – Zertifikatsnutzung

Es gelten folgende übergreifende Festlegungen für die Prüfung aktiv durch das ePA-Frontend des Versicherten genutzter ZertifikateEs gelten die Vorgaben für die Prüfung von Zertifikaten gemäß A_24624* und A_24958* aus [gemSpec_Krypt].

A_15872-01 - ePA-Frontend des Versicherten: verpflichtende Zertifikatsprüfung

Das ePA-Frontend des Versicherten MUSS alle Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau) auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das ePA-Frontend des Versicherten MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]

"Ein Zertifikat aktiv verwenden" bedeutet im Sinne von A_15872, dass ein ePA-FdV einen dort aufgeführten öffentlichen Schlüssel innerhalb einer kryptografischen Operation (Signaturprüfung, Verschlüsselung, Signaturprüfung von öffentlichen (EC)DH-Schlüsseln etc.) nutzt. Erhält ein ePA-Frontend des Versicherten bspw. einen Access-Token, in dem Signaturen und Zertifikate enthalten sind und behandelt es diesen Token als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet das ePA-Frontend des Versicherten diese Zertifikate im Sinne von A_15872 passiv.

6.1.5.1 Vertrauensanker des TI-Vertrauensraum

Der Vertrauensraum der TI ist in [gemSpec_PKI#8.1] beschrieben. Für das ePA-Frontend des Versicherten gelten abweichende Vorgaben, da das ePA-FdV nicht innerhalb der TI betrieben wird. Diese Abweichungen werden im Folgenden beschrieben.

Die Initialisierung des TI-Vertrauensraums und der Wechsel des TI-Vertrauensankers wird beim ePA-Frontend des Versicherten

durch die Bereitstellung der FdV Applikation durchgeführt.

A_17667-01 - ePA-Frontend des Versicherten: Behandlung des Vertrauensankers

Das ePA-Frontend des Versicherten MUSS den aktuellen TI-Vertrauensanker (TSL-Signer-CA-Zertifikat) im Auslieferungszustand der Applikation integer und authentisch mit sich führen. 
Dabei MUSS der TI-Vertrauensanker fest mit dem Code des ePA-Frontend des Versicherten verbunden sein, d.h. eine Manipulation des TI-Vertrauensankers MUSS durch das ePA-Frontend des Versicherten erkannt werden.
Das ePA-Frontend des Versicherten MUSS bei einem angekündigten Wechsel des TI-Vertrauensankers den neuen TI-Vertrauensanker zusätzlich zum aktuell gültigen Vertrauensanker mit sich führen.
Das ePA-Frontend des Versicherten MUSS eindeutig identifizierte und während der Erstellung der Applikation mittels Fingerprint validierte TSL-Signer-CA-Zertifikate mit sich führen und ausschließlich diese als Vertrauensanker verwenden.
[<=]

6.1.5.2 TSL-Behandlung

Folgende Vorgaben gelten für den Bezug und die Verarbeitung der TSL.

A_15874-02 - ePA-Frontend des Versicherten: Periodische Aktualisierung TI-Vertrauensraum

Das ePA-Frontend des Versicherten MUSS zur periodischen Aktualisierung des TI-Vertrauensraums den TUC_PKI_001 mit folgenden Anpassungen umsetzen:

•   Der Offline-Modus ist nicht zu berücksichtigen

•   Auslöser: keine TSL lokal gespeichert oder die gespeicherte TSL ist zu alt (die in der TSL selbst kodierte Gültigkeitsdauer NextUpdate ist abgelaufen).

•   Sofern nur eine abgelaufene TSL vorliegt, soll abweichend von TUC_PKI_006 in Schritt 5 die Prüfung des OCSP-Signer-Zertifikats des TSL-Signer OCSP-Responders nicht mittels der TSL, sondern gegen die TSL-Signer-CA erfolgen.

•   Wenn innerhalb der letzten 24 Stunden keine Prüfung erfolgte, dann muss das ePA-Frontend des Versicherten prüfen, ob eine neuere TSL zur Verfügung steht. Falls eine neuere TSL am Downloadpunkt bereit steht, so muss das ePA-Frontend des Versicherten die neuere TSL herunterladen.

Das ePA-Frontend des Versicherten MUSS zum Prüfen der Aktualität und dem Herunterladen der TSL(ECC-RSA) die vom Zugangsgateway des Versicherten angebotene Schnittstelle verwenden. [<=]

Für die Spezifikation der Schnittstelle siehe .

Der Aufbau und der Inhalt der TSL sind durch [ETSI_TS_102_231_V3.1.2] gegeben und in  beschrieben.

A_16489-01 - ePA-Frontend des Versicherten: TSL - Prüfung Integrität und Authentizität

Das ePA-Frontend des Versicherten MUSS die Integrität und Authentizität der heruntergeladenen TSL prüfen. Falls die Prüfung kein positives Ergebnis liefert, so MUSS die gerade heruntergeladene TSL verworfen werden. [<=]

Die Bedingungen an den Vertrauensstatus der TSL sind in [gemSpec_TSL#8.2.2] beschrieben. Für das ePA-FdV gilt eine "TSL-Graceperiod" von 0 Tagen, d.h., die TSL-Informationen sind nicht mehr vertrauenswürdig, wenn das aktuelle Datum nach dem Datum nextUpdate der TSL liegt.

A_17732-01 - ePA-Frontend des Versicherten: TSL - Truststore für Zertifikatsprüfung

Das ePA-Frontend des Versicherten MUSS die TSL auswerten, um aus den Inhalten einen Truststore für die durchzuführenden Zertifikatsprüfungen zu bilden. [<=]

Hinweis: Eine Möglichkeit zur Umsetzung ist, im Rahmen der Aktualisierung der TSL (vgl. A_15874) nach positiver Prüfung der TSL-Signatur die CA-Zertifikate aus der TSL in verschiedene zugriffsgeschützte Verzeichnisse zu legen: bspw. einmal für HBA/SMC-B/eGK-CAs, einmal für SGD-Zertifikate und einmal für CAs der Komponenten-PKI der TI. Die Verzeichnisse dienen dann als Truststore für die Zertifikatsprüfung, womit sich die Umsetzungskomplexität der Vorgabe aus A_15873 Punkt 2 reduziert.

A_16490-01 - ePA-Frontend des Versicherten: TSL nicht verfügbar

Das ePA-Frontend des Versicherten MUSS, falls keine nach A_16489 erfolgreich geprüfte TSL zur Verfügung steht oder das aktuelle Datum nach dem Datum nextUpdate der TSL liegt, den Vertrauensraum als ungültig betrachten und sicherstellen, dass alle Zertifikatsprüfungen für TI-Zertifikate mit "ungültig" bewertet werden. [<=]

Hinweis: Es ist in Bezug auf die CC-Evaluierung hilfreich, wenn die TSL-Signaturprüfung mit einer speziell dafür geschriebenen (und gehärteten) Programmkomponente durchgeführt wird. Bei einer anschließenden XML-Auswertung der TSL mit einer Standard-XML-Bibliothek können die verarbeiteten XML-Daten dann als vertrauenswürdig angesehen werden.

6.1.5.3 Zertifikatsprüfung von Zertifikaten der TI

In der folgenden Anforderung sind die Schritte zum Prüfen eines Zertifikates der TI beschrieben. In den Schritten werden TUC_PKI_* referenziert. Sie dienen als Rahmen für den Ablauf der Prüfschritte. Die TUC_PKI_* sind in dieser Afo nicht normativ umzusetzen.

A_15873-01 - ePA-Frontend des Versicherten: Prüfung TI-Zertifikate (ausser SGD-Zertifikate)

Das ePA-Frontend des Versicherten MUSS bei der Prüfung von X.509-Zertifikaten der TI (ausser X.509-Zertifikaten eines Schlüsselgenerierungsdienstes) folgende Prüfschritte durchlaufen.

•      Prüfung der zeitlichen Gültigkeit des Zertifikats auf Basis der aktuellen Systemzeit (orientiert an gemSpec_PKI#TUC_PKI_002)

•      Ist das Zertifikat kryptographisch (Signaturprüfung) rückführbar auf ein CA-Zertifikat aus einer authentischen und integeren und zeitlich gültigen TSL (vgl. A_15874)? (orientiert an [gemSpec_PKI#TUC_PKI_003 und TUC_PKI_004])

•      Prüfung auf den für den Anwendungsfall korrekten Zertifikatstyp gemäß TAB_FdV_110. Die OID des Zertifikatstyps gemäß [gemSpec_OID] muss in der Extension CertificatePolicies enthalten sein.

•      Falls das Zertifikat für den Aufbau des sicheren Kanals zur VAU verwendet wird (VAU-Zertifikat innerhalb des VAU-Protokolls, vgl. [gemSpec_Krypt#Kommunikationsprotokoll zwischen VAU und ePA-Clients]), so MUSS die Rolle "oid_epa_vau" gemäß [gemSpec_OID#GS-A_4446-*] im EE-Zertifikat aufgeführt sein (analog gemSpec_PKI#TUC_PKI_009). Falls nein, MUSS das Zertifikat für den Aufbau des sicheren Kanals zur VAU abgelehnt werden.

•      Falls das Zertifikat ein EE-Zertifikat ist: Ermittlung der OCSP-Statusinformation. Ist das Zertifikat nicht gesperrt (Status "good" [RFC-6960#2.2 Response]) (vgl. A_15869)? Eine OCSP-Antwort KANN lokal maximal 4 Stunden gecacht und als Prüfgrundlage verwendet werden.
Die Prüfung ist analog gemSpec_PKI#TUC_PKI_006 mit den Parametern Referenzzeitpunkt=Systemzeit, OCSP-Graceperiod=4 Stunden.

•      Prüfung der Extensions KeyUsage und ExtendedKeyUsage auf die richtige Belegung gemäß dem Anwendungsfall (orientiert an gemSpec_PKI#TUC_PKI_018 Schritt 2).

Führt einer der Prüfschritte nicht zu einen positiven Prüfergebnis, so MUSS das Zertifikat abgelehnt werden und die weitere Verarbeitung des Zertifikats oder der Attribute darin abgelehnt werden.
Das ePA-Frontend des Versicherten muss die referenzierten gemSpec_PKI#TUC_PKI_* im Rahmen dieser Anforderung nicht normativ umsetzen. [<=]

Für die Prüfung des Online-Status von Zertifikaten der TI wird die Schnittstelle I_OCSP_Status_Information genutzt. Siehe [gemSpec_PKI#9]. Die Schnittstelle wird durch den Status-Proxy der Komponente Zugangsgateway des Versicherten angeboten. Siehe auch .

A_18177-01 - ePA-Frontend des Versicherten: Prüfung TI-Zertifikate (SGD-Zertifikate)

Das ePA-Frontend des Versicherten MUSS X.509-Zertifikate eines Schlüsselgenerierungsdienstes der TI gemäß PL_TUC_PKI_VERIFY_CERTIFICATE prüfen. 

[<=]

6.1.5.4 Zertifikatsprüfung von Internet-Zertifikaten

Folgende Vorgaben gelten für die Prüfung von Internet-Zertifikaten.

A_15887-03 - ePA-Frontend des Versicherten: Prüfung Internet-Zertifikate

Das ePA-Frontend des Versicherten MUSS für die Prüfung des internetseitigen Zertifikats des Zugangsgateways des Versicherten das Zertifikat auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (https://cabforum.org/baseline-requirements-documents/) erfüllt, kryptographisch (Signaturprüfung) zurückführen können. Ansonsten MUSS es das Zertifikat als "ungültig" bewerten.
Es MUSS die zeitliche Gültigkeit des Zertifikats prüfen. Falls diese Prüfung negativ ausfällt, muss es das Zertifikat als "ungültig" bewerten. 
Bei der Prüfung auf eine gültige CA SOLL die Prüfung auf ausgewählte Zertifikate aus der Liste https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport beschränkt werden (bez. Auswahl vgl. Hinweis 2 zu A_15887-*).
[<=]

Hinweis 1: Der erste Teil von A_15887-* ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers ist.

Hinweis 2: gemäß Absprache mit den ePA-Industriekonsortien soll bei der Prüfung nach A_15887-* die Menge der zulässigen CA:

1. initial auf die CA-Zertifikate von GlobalSign, DigiCert und Entrust aus der Liste von https://wiki.mozilla.org/CA/Included_Certificates -> "Included CA Certificates" beschränkt werden.
2. weiterhin muss die Liste die CA-Zertifikate von ISRG (Let's encrypt) enthalten (fachlicher Hintergrund: das Gesundheitspotral https://gesund.bund.de/ verwendet diesen TSP).
3. und zukünftig auf eine Menge von CA-Zertifikaten beschränkt werden, die in Abhängigkeit zu [gemSpec_Aktensystem#A_22409] steht und bei Änderung von der gematik an die ePA-FdV-Hersteller gesendet wird.

6.1.6 Dokumente

Das ePA-Aktensystem unterstützt die einzelne Dokumente bis zu einer Größe von 25 MB.

A_15283-01 - ePA-Frontend des Versicherten: Dokumentgrößen von 25 MB

Das ePA-Frontend des Versicherten MUSS für alle Außenschnittstellen, in denen ein Dokument verarbeitet wird, Dokumente mit einer Größe von mindestens 25 MB unterstützen. [<=]

A_21301 - ePA-FdV für Desktop-Plattformen: Kein Ausführen von aktiven Inhalten bei der Anzeige

Das ePA-FdV DARF bei der Anzeige von Dokumenten aktive Elemente NICHT ausführen.  [<=]

Hinweis: Aktive Elemente sind alle code-ausführenden Anteile eines Dokuments, also etwa Makros oder Skripte. Diese dürfen im Kontext des FdV nicht ausgeführt werden, etwa indem auch bei zugelieferten Bibliotheken diese Funktionalität deaktiviert wird.
Die Verwendung explizit externer Applikationen wird dabei nicht betrachtet, da hier aus Sicht des ePA-FdV der Vorgang mit dem Herunterladen des Dokuments als abgeschlossen angesehen wird.

6.1.7 Umschlüsselung der Dokumente

Die Dokumente der elektronischen Patientenakte sind mit ePA-spezifischen kryptographischen Schlüsseln gesichert. Ab der ePA Version 2.0 ist es möglich, dass der Versicherte zu jedem Zeitpunkt eine Umschlüsselung starten kann. Dadurch kann bei Verdacht oder bei tatsächlicher Kompromittierung eine missbräuchliche Nutzung der Dokumente verhindert werden.

Die Umschlüsselung kann über das FdV vom Versicherten gestartet werden.

6.1.7.1 Kryptographische Architektur der Dokumentenverschlüsselung

Die Dokumente der elektronischen Patientenakte werden verschlüsselt im Aktensystem abgelegt. Der Betreiber hat keinen Zugriff auf die Klartext-Daten der Dokumente. Die Versicherten können jederzeit alle Dokumente entschlüsseln und die Leistungserbringer dürfen im Rahmen ihrer von den Versicherten festgelegten Berechtigungen für sie freigegebene Dokumente über ihr Primärsystem entschlüsseln. Um diese Funktionalität umzusetzen sind verschiedene Verschlüsselungen mit unterschiedlichen Schlüsseln notwendig. Diese müssen bei der Umschlüsselung ausgetauscht werden. In der folgenden Abbildung sind die verschiedenen Schlüssel aufgeführt.

Abbildung 3: Kryptographische Schlüssel der ePA

Für die Verschlüsselung eines Dokumentes wird ein dokumentenindividueller symmetrischer Dokumentenschlüssel verwendet. Dieser wird mit einem versichertenindividuellen Aktenschlüssel verschlüsselt. Der Aktenschlüssel wird mit nutzerindividuellen Schlüsseln des SGD1 und SGD2 verschlüsselt und anschließend in der Komponente Autorisierung abgelegt. Nutzer sind berechtigte LEI, Kassen und Vertreter des Versicherten.

Die mit dem Dokumentenschlüssel gesicherten Dokumente und die mit dem Aktenschlüssel verschlüsselten Dokumentenschlüssel werden mit einem aus einem betreiberspezifischen Schlüssel abgeleiteten aktenspezifischen Schlüssel nochmals verschlüsselt und anschließend im Aktensystem abgelegt.

Die Metadaten werden mit dem versichertenindividuellen Kontextschlüssel verschlüsselt. Die verschlüsselten Metadaten werden nochmals mit dem aus dem betreiberspezifischen Schlüssel abgeleiteten aktenspezifischen Schlüssel verschlüsselt und im Aktensystem abgelegt. Die Kontextschlüssel werden mit den nutzerindividuellen Schlüsseln des Schlüsselgenerierungsdienstes 1 und 2 (SGD1 und SGD2) symmetrisch verschlüsselt und anschließend in der Komponente Autorisierung abgelegt.

Ab Release 4.0.1 ist die explizite, vom Versicherten angestoßene, Erneuerung der Akten-, Kontext- und SGD1- und SGD2 Schlüssel umgesetzt. Der Betreiber kann unabhängig davon regelmäßig den betreiberspezifischen Schlüssel erneuern.

Einzelne Rückgabewerte bei der Kommunikation zwischen dem FdV und der Autorisierungskomponente und der Dokumentenverwaltung sind vom jeweiligen Absender signiert, damit beim Weiterleiten von Argumenten (z.B. bei der Übermittlung der von der Autorisierung ausgestellten rollbackTime) der Empfänger diese über eine Signaturprüfung validieren kann. Es werden sowohl die Herkunft als auch der Signaturerstellungszeitpunkt vom Empfänger geprüft. Das Frontend des Versicherten prüft die Signaturen der Rückgabewerte nicht.

A_20477 - ePA-Frontend des Versicherten: Unterstützung der Umschlüsselungsfunktion

Das ePA-Frontend des Versicherten MUSS dem Nutzer eine Umschlüsselungsfunktion anbieten, die auf Wunsch des Versicherten einen Wechsel der Akten- und Kontextschlüssel sowie der SGD1- und SGD2-Schlüssel durch die Komponenten, die diese Schlüssel verwalten, einleitet. 
[<=]

6.1.8 ePA-FdV für Desktop-Plattformen

Wird das FdV nicht auf einem mobilen Gerät betrieben, muss die Verwendung des FdV durch mehrere Versicherte für den Zugriff auf die individuellen ePA möglich sein.

A_21358 - ePA-FdV für Desktop-Plattformen: Mehrbenutzerfähigkeit des Desktop-Clients

Das ePA-FdV MUSS die Ausführung der Aktensteuerung über verschiedene, lokale Benutzerkonten des Betriebssystems oder alternativ eine FdV-interne Benutzer-Kontensteuerung ermöglichen. [<=]

6.1.9 Freigabe von Dokumenten für Forschungszwecke

Einem Versicherten oder einem Vertreter muss die Freigabe von Dokumenten der Akte des Versicherten in pseudonymisierter Form für Zwecke der Forschung gemäß §363 Abs. 1-7 SGB V nach erteilter Einwilligung gemäß § 363 Absatz 2 SGB V ermöglicht werden. Darüber hinaus muss es einem Versicherten oder einem Vertreter möglich sein, die Verwendung zuvor freigegebener Daten für Forschungszwecke zu widerrufen.

Die Freigabe von Dokumenten aus der Akte eines Versicherten ist auf die Freigabe von Daten in strukturierten Dokumenten (MIOs) beschränkt. Die freizugebenden Dokumente werden durch das ePA-FdV unter Verwendung von Pseudonymisierungsvorgaben ("Pseudonymisierungsschema") in pseudonymisierte Dokumente übertragen. Ausschließlich pseudonymisierte Dokumente dürfen für Forschungszwecke an das Forschungsdatenzentrum übermittelt werden. Der Versicherte oder ein Vertreter muss dabei für jeden Freigabevorgang auswählen können, welche Dokumente freigegeben werden sollen. Ein Freigabevorgang kann dabei auch die Freigabe zu einer automatisch zu wiederholenden Übermittelung eines Dokuments an das Forschungsdatenzentrum beinhalten, beispielsweise nach Aktualisierungen eines Dokuments.

Neben der Pseudonymisierung der Daten des Versicherten (pD) wird eine Arbeitsnummer (AN) und ein Lieferpseudonym (LP) auf Basis der KVNR des Versicherten verwendet. Zum Nachweis der Authentizität des Absenders fordert das ePA-FdV die Erstellung von nicht personengebundenen Transporttoken von der Autorisierung des Aktensystems an, jeweils ein Token für die Vertrauensstelle mit der Arbeitsnummer und dem Lieferpseudonym und ein Token für das Forschungsdatenzentrum mit der Arbeitsnummer. Die Einbettung der Arbeitsnummer und des Lieferpseudonyms in diese signierten Token stellt darüber hinaus sicher, dass alle Dokumentenfreigaben des ePA-FdV ausschließlich für dieses Lieferpseudonym erfolgen können. 

Das Transporttoken für die Vertrauensstelle mit dem Lieferpseudonym und der Arbeitsnummer werden an die Vertrauensstelle (VST, gemäß § 303c SGB V) übertragen.

Das Transporttoken für das Forschungsdatenzentrum mit der Arbeitsnummer und die Ende-zu-Ende verschlüsselten pseudonymisierten Dokumente werden an das Forschungsdatenzentrum (FDZ, gemäß § 303d SGB V ) übertragen.

Eine Übersicht der freigegebenen Dokumente und etwaiger Widerrufe der Freigabe wird zentral in einem Dokument des Versicherten in seiner Akte verwaltet (Aufzeichnungsliste).

Die Referenzierung der freigegebenen Dokumente gegenüber dem Forschungsdatenzentrum erfolgt nicht durch Metadaten der Akte (z.B. document.UniqueId). Das ePA-FdV generiert daher pro Dokument (MIO) einen eigenen Identifier. Dieser wird in der Aufzeichnungsliste abgelegt und sowohl für folgende Freigaben, als auch den Widerruf der Dokumente verwendet.

Abbildung 4 Übersicht des Ablaufs der Freigabe von Daten für Forschungszwecke

6.1.9.1 Einwilligung in die Datenfreigabe

A_21843-01 - ePA-FdV: Einwilligung nach § 363 Absatz 2 SGB V in die Datenfreigabe für Forschungszwecke

Das ePA-FdV MUSS dem Versicherten eine Einwilligung nach § 363 Absatz 2 SGB V in die Datenfreigabe für die Forschung in einem informierten Dialog zur Anzeige bringen. Dabei MUSS der von der Krankenkasse des Versicherten vorgegebene Einwilligungstext verwendet werden. Der Text der Einwilligung muss auch im Nachhinein für den Versicherten zugänglich sein.
[<=]

A_21844-01 - ePA-FdV: Datenfreigabe nur nach Einwilligung

Das ePA-FdV MUSS sicherstellen, dass eine Freigabe von Dokumenten zu Forschungszwecken am ePA-FdV erst erfolgen kann, nachdem der Versicherte die Einwilligung nach § 363 Absatz 2 SGB V gegenüber der Krankenkasse erteilt hat.  
[<=]

A_21845-01 - ePA-FdV: Widerruf der Einwilligung nach § 363 Absatz 2 SGB V

Das ePA-FdV MUSS es dem Versicherten ermöglichen, die Einwilligung nach § 363 Absatz 2 SGB V gegenüber der Krankenkasse jederzeit zu widerrufen. Nach einem Widerruf MUSS das ePA-FdV die weitere Freigabe von Dokumenten für Forschungszwecke verhindern.
[<=]

Hinweis: das ePA-FdV vermerkt den Status einer erteilten, bzw. widerrufenen Einwilligung nach § 363 Absatz 2 SGB V in der Akte des Versicherten im Dokument der aufgezeichneten Freigaben/Widerrufe (Aufzeichnungsliste).

A_21895 - ePA-FdV: Widerruf freigegebener Dokumente nach einem Widerruf der Einwilligung

Das ePA-FdV MUSS bei einem Widerruf der Einwilligung nach § 363 Absatz 2 SGB V automatisch gegenüber dem Forschungsdatenzentrum alle zu diesem Zeitpunkt noch freigegebenen  Dokumente widerrufen. Für diesen Widerruf MÜSSEN die Schnittstellen [I_VST] und  [I_FDZ] unter Angabe der zu widerrufenden Dokumente genutzt werden. [<=]

Hinweis: Es müssen alle Dokumente widerrufen werden, die in der Aufzeichnung der freigegebenen und widerrufenen Dokumente als freigegeben aber noch nicht widerrufen vermerkt sind.

6.1.9.2 Freigabe der Dokumente und Pseudonymisierung

A_21794 - ePA-FdV: Auswahl der freizugebenden Dokumente für Forschungszwecke

Das ePA-FdV MUSS dem Versicherten oder einem Vertreter die Auswahl der freizugebenden Dokumente für Forschungszwecke ermöglichen. Die Auswahl MUSS durch den Versicherten oder einen Vertreter bei folgenden Freigaben änderbar sein. [<=]

A_22682 - ePA-FdV: Keine wiederholte Freigabe unveränderter Dokumente

Das ePA-FdV MUSS sicherstellen, dass Dokumente nicht erneut freigegebenen werden, welche schon für Forschungszwecke freigegeben und übermittelt und seitdem in der Akte des Versicherten nicht verändert wurden [<=]

Hinweis: Es muss also mindestens ein XDS-Dokument vor einer erneuten Freigabe hinzugekommen, gelöscht oder verändert worden sein. 

A_21877 - ePA-FdV: Bestätigung der Freigabe oder des Widerrufs von Dokumenten für Forschungszwecke

Das ePA-FdV MUSS vor der Übermittelung von ausgewählten Dokumenten und vor der Übermittelung des Widerrufs von einem oder mehreren zuvor freigegebenen Dokumenten für Forschungszwecke die Bestätigung des Versicherten oder eines Vertreters einholen. [<=]

A_21847 - ePA-FdV: Widerruf von freigegebenen Dokumenten

Das ePA-FdV MUSS es dem Versicherten oder einem Vertreter ermöglichen, zuvor freigegebene Dokumente jederzeit zu widerrufen. Zum Zwecke des Widerrufs MÜSSEN die Schnittstellen [I_VST] und [I_FDZ] unter Angabe der zu widerrufenden, in der Vergangenheit freigegebenen Dokumente genutzt werden. [<=]

A_21792 - ePA-FdV: Pseudonymisierung von Dokumenten für Forschungszwecke

Das ePA-FdV MUSS die Daten eines für Forschungszwecke freizugebenden Dokuments unter Verwendung von Pseudonymisierungsvorgaben in ein pseudonymisiertes Dokument überführen. [<=]

A_22997-02 - ePA-FdV: Format der pseudonymisierten Dokumente für Forschungszwecke

Das ePA-FdV MUSS für ein pseudonymisiertes Dokument die Regeln des FHIR-Standards (Compliance) berücksichtigen und im Format xml an das Forschungsdatenzentrum übermitteln.
[<=]

A_21793 - ePA-FdV: Verwendung geeigneter Pseudonymisierungsvorgaben

Das ePA-FdV MUSS für die Konvertierung der Daten eines Dokuments des Versicherten in ein pseudonymisiertes Dokument die Pseudonymisierungsvorgaben verwenden, welche für die Pseudonymisierung dieser spezifischen Ausprägungen (Versionen) der Datenstruktur geeignet sind [<=]

Hinweis: Die Pseudonymisierungsvorgaben für die strukturierten Dokumente werden zusammen mit den Implementierungsvorgaben ("Implementation-Guidelines") zu den strukturierten Dokumenten auf GitHub veröffentlicht und enthalten Listen von FHIR-Path-Ausdrücken, welche eindeutig und vollständig die für ein pseudonymisiertes Dokument zulässigen Elemente eines MIOs angeben.

6.1.9.3 Übermittlung der Daten an das Forschungsdatenzentrum

Die Übermittlung der freigegebenen und pseudonymisierten Dokumente an das Forschungsdatenzentrum erfolgt verschlüsselt und unter Verwendung einer Arbeitsnummer. Die gleiche Arbeitsnummer und ein Lieferpseudonym werden an die Vertrauensstelle übermittelt.

Ein Übermittlungsvorgang beinhaltet die Übermittlung der pseuonymisierten Dokumente gemäß Auswahl durch den Versicherten oder einen Vertreter. Ein solcher Vorgang kann dabei mehr als einen Aufruf der Schnittstelle des Forschungsdatenzentrums erfordern.

Ein zur Freigabe ausgewähltes Dokument kann in der Akte des Versicherten durch mehr als ein XDS-Dokument repräsentiert sein (Sammlungstypen mixed und uniform). Für jeden Übermittlungsvorgang eines Dokuments dieses Sammlungstyps müssen alle aktuellen (Status 'approved') XDS-Dokumente des assoziierten Ordners (XDS Folder) berücksichtigt werden.

Ein Übermittlungsvorgang zum Zweck des Widerrufs erfolgt analog zu einer Datenfreigabe. Anstelle der pseudonymisierten Dokumente wird jedoch lediglich deren ID an das Forschungsdatenzentrum übertragen.

A_21797 - ePA-FdV: Erstellung der Transporttoken

Das ePA-FdV MUSS für den Übermittlungsvorgang an die Vertrauensstelle und an das Forschungsdatenzentrum von der Autorisierung erstellte Transporttoken verwenden. Beide Transporttoken MÜSSEN aus dem gleichen Aufruf der Schnittstelle [I_Authorization_Token_Service] stammen. [<=]

A_22699-01 - ePA-FdV: Bezug und Prüfung des Verschlüsselungszertifikats des Forschungsdatenzentrums

Das ePA-FdV MUSS das Verschlüsselungszertifikat des Forschungsdatenzentrums über die in [I_FDZ] definierte URL herunterladen und dieses Zertifikat mittels TI-Zertifikatsprüfung (Policy-List enthält oid_epa_fdz [gemSpec_OID], OCSP-Graceperiod=4h, vgl. auch A_15873-*) prüfen.
Das ePA-FdV MUSS sicherstellen, dass ausschließlich gültige Zertifakte nach Prüfung für die Verschlüsselung der pseudonymisierten Dokumente für das Forschungsdatenzentrum verwendet werden. 

[<=]

A_21800 - ePA-FdV: Verschlüsselung der Daten für Forschungszwecke

Das ePA-FdV MUSS sicherstellen, dass die pseudonymisierten Dokumente ausschließlich gemäß [I_FDZ] für das Forschungsdatenzentrum verschlüsselt werden. D. h., insbesondere das ePA-FdV MUSS das Verschlüsselungszertifikat des FDZ prüfen bevor es den öffentlichen Schlüssel darin für Verschlüsselungsoperationen verwendet. [<=]

A_21850 - ePA-FdV: Verwendung der Arbeitsnummer

Das ePA-FdV MUSS für jeden Übermittlungsvorgang (ein oder mehrere Dokumente, siehe Erläuterung) an die Vertrauensstelle und an das Forschungsdatenzentrum eine neu erzeugte Arbeitsnummer, bzw. neu erzeugte Transporttoken, verwenden.  [<=]

A_21796-01 - ePA-FdV: Verwendungsdauer der Transporttoken

Das ePA-FdV MUSS bei jedem Übermittlungsvorgang an die Vertrauensstelle und an das Forschungsdatenzentrum zeitlich gültige Transporttoken verwenden. Dieser Verwendungszeitraum beginnt mit dem Bezug der Transporttoken von der Komponente Autorisierung und endet 30 Minuten vor dem Verfallszeitpunkt der Transporttoken ("exp" - 30 Minuten). 
[<=]

A_21803 - ePA-FdV: Verwendung der Schnittstelle der Vertrauensstelle

Das ePA-FdV MUSS das Transporttoken mit der Arbeitsnummer und dem Lieferpseudonym unter Verwendung der Schnittstelle der Vertrauensstelle [I_VST] über den Transport-Proxy an die Vertrauensstelle übermitteln. [<=]

A_21804 - ePA-FdV: Verwendung der Schnittstelle des Forschungsdatenzentrums

Das ePA-FdV MUSS die pseudonymisierten und verschlüsselten Dokumente mit der Arbeitsnummer gemäß [I_FDZ], oder - im Falle eines Widerrufs - die Identifier der zu widerrufenen Dokumente, und die Arbeitsnummer unter Verwendung der Schnittstelle des Forschungsdatenzentrums [I_FDZ] über den Transport-Proxy an das Forschungsdatenzentrum übermitteln [<=]

Erläuterung zum Begriff "Übermittlungsvorgang": Ein Übermittlungsvorgang beinhaltet einen Aufruf der Schnittstelle der Vertrauensstelle und -- je nach Umfang der freigegebenen Dokumente -- einen oder mehrere Aufruf der Schnittstelle des Forschungsdatenzentrums.

A_22821-01 - ePA-FdV: Erstellung der Identifier für die Übermittelung an das Forschungsdatenzentrum

Das ePA-FdV MUSS für jedes freigegebene Dokument eine eigens generierte ID (256 Bit Zufallswert) als Identifier verwenden. Dieser Identifier MUSS auch für Folgefreigaben des Dokuments verwendet werden. Für Freigaben nach einem Widerruf MUSS ein neuer Identifier erzeugt werden. 
Dieser Zufallswert muss den Anforderungen aus GS-A_4367 [gemSpec_Krypt] zur Qualität der Zufallszahlenerzeugung entsprechen.
[<=]

A_22670 - ePA-FdV: Verwendung der Schnittstelle des Forschungsdatenzentrums zur Übermittlung von Dokumenten

Das ePA-Fdv MUSS alle freizugebenden und pseudonymisierten XDS-Dokumente eines MIOs mit einem einzigen Aufruf der Schnittstelle des Forschungsdatenzentrums gemäß [I_FDZ] übermitteln. [<=]

A_22683 - ePA-FdV: Bestandteile der freigegebenen Dokumente

Das ePA-FdV MUSS bei der Pseudonymisierung und Übermittlung von Dokumenten an das Forschungsdatenzentrum jeweils alle Teildokumente (XDS Dokumente mit Status 'approved') berücksichtigen. [<=]

A_21894 - ePA-FdV: Aufruf der Schnittstellen der Vertrauensstelle und des Forschungsdatenzentrums

Das ePA-FdV MUSS für einen Übermittlungsvorgang die Schnittstelle der Vertrauensstelle [I_VST] und die Schnittstelle des Forschungsdatenzentrums [I_FDZ] verwenden. [<=]

Hinweis: Für das ePA-FdV gilt der Vorgang der Übermittelung an das FDZ als erfolgreich abgeschlossen, wenn sowohl der Aufruf der Schnittstelle der Vertrauensstelle [I_VST], als auch der anschließende Aufruf der Schnittstelle des Forschungsdatenzentrums [I_FDZ] erfolgreich war

6.1.9.4 Umfang und Aufzeichnung der Freigabe

Jede Freigabe und jeder Widerruf eines strukturierten Dokuments muss erfasst werden und für den Versicherten oder einen Vertreter einsehbar sein. Für diese Aufzeichnungen wird ein vorgegebenes Dokument (Aufzeichnungsliste) in der Akte des Versicherten verwendet. Anhand dieser Aufzeichnungen ist nachvollziehbar, welche Dokumente zu welchem Zeitpunkt freigegeben und an das Forschungsdatenzentrum übermittelt und welche widerrufen wurden und wer den jeweiligen Vorgang initiiert hat. Die aufgezeichnete Dokumenteninformation zu einer Freigabe kann auch für einen eindeutigen Widerruf der Freigabe verwendet werden.

Bei der Aufzeichnung der freigegebenen Dokumente, bzw. der zu übermittelnden Artefakte, muss sichergestellt sein, dass keine Situation eintreten kann welche dazu führt, dass im Forschungsdatenzentrum Dokumente vorliegen, deren Freigabe für einen Versicherten nicht mehr einsehbar und dahingehend auch nicht widerrufbar ist. In die Aufzeichnungsliste werden freizugebende Daten daher vor einer Übermittlung eingetragen und ein Widerruf erst nach Erhalt der Bestätigung durch das Forschungsdatenzentrum. Das ePA-FdV selbst muss daneben Maßnahmen vorsehen, die sicherstellen, dass der genannte eindeutige Zustand auch nach einer unvorhergesehenen Unterbrechung der Kommunikation erreicht werden kann. 

A_21878-01 - ePA-FdV: Aufzeichnung der erteilten oder widerrufenen Einwilligung des Versicherten in die Freigabe von Dokumenten für Forschungszwecke

Das ePA-FdV MUSS einen Nachweis der erteilten Einwilligung des Versicherten oder den Widerruf dieser Einwilligung zur Freigabe von Dokumenten für Forschungszwecke im Dokument [FD_Aufzeichnung] unter Beachtung von [FD_Aufzeichnung_Schema] in der Akte des Versicherten ablegen. Ist das Dokument [FD_Aufzeichnung] zum Zeitpunkt der Aufzeichnung der erteilten Einwilligung nicht vorhanden, MUSS das ePA-FdV dieses Dokument gemäß [FD_Aufzeichnung] in der Akte des Versicherten anlegen.
[<=]

Hinweis: A_21878-* bezieht sich auf die Einwilligung gemäß § 363 Absatz 2 SGB V (A_21843-*). Als Nachweis genügt der Einwilligungsstatus, welcher gemäß den Vorgaben in [FD_Aufzeichnung] angegeben wird. 

A_21805 - ePA-FdV: Aufzeichnung von Freigabe und Widerruf von Dokumenten für Forschungszwecke

Das ePA-FdV MUSS die Freigabe von Dokumenten für Forschungszwecke und den erfolgten Widerruf von Dokumenten aufzeichnen und in der Akte des Versicherten gemäß [FD_Aufzeichnung] und [FD_Aufzeichnung_Schema] ablegen.  [<=]

A_22858-01 - ePA-FdV: Metadaten zur Aufzeichnungsliste der Freigaben und Widerrufe von Dokumenten für Forschungszwecke

Das ePA-FdV MUSS bei der Erstellung und bei Modifikationen des Dokuments der Aufzeichnungsliste in der Akte die Vorgaben in [FD_Aufzeichnung] beachten. [<=]

A_22680 - ePA-FdV: Sicherstellen der Aufzeichnung von Freigaben

Das ePA-FdV MUSS sicherstellen, dass alle dem Forschungsdatenzentrum freigegebenen Dokumente in der Aufzeichnungsliste gespeichert sind und für einen Widerruf verwendet werden können. [<=]

A_22674 - ePA-FdV: Aufzeichnung von Freigabe oder Widerruf im Störungsfall

Das ePA-FdV MUSS durch geeignete Maßnahmen sicherstellen, dass ein durch technische Störung unterbrochener Übermittlungsvorgangs nach erneuter Anmeldung des ePA-FdV am Aktensystem beendet werden kann, ohne dass im Forschungsdatenzentrum Dokumente vorliegen, die in der Aufzeichnungsliste nicht vermerkt sind. [<=]

Hinweis: Bei einem Abbruch der Übermittlung, beispielsweise durch einen schwachen Akku des Geräts des ePA-FdV, ist nicht bekannt, ob und welche Dokumente schon an das Forschungsdatenzentrum übertragen wurden. Ein ePA-FdV soll daher den Vorgang regulär beenden können, beispielsweise durch erneute Übermittlung der betroffenen Dokumente.

A_21896 - ePA-FdV: Anzeige der freigegebenen Dokumente für Forschungszwecke

Das ePA-FdV MUSS es dem Versicherten oder einem Vertreter jederzeit ermöglichen, einzusehen, welche Dokumente aus seiner Akte für Forschungszwecke freigegeben sind, welche widerrufen wurden, sowie zu welchem Zeitpunkt dieses erfolgte und wer (Versicherter/Vertreter) diesen Vorgang ausgelöst hat.
[<=]

A_22693 - ePA-FdV: Verbergen der Aufzeichnungsliste als Dokument des Versicherten

Das ePA-FdV MUSS die Aufzeichnungsliste gemäß [FD_Aufzeichnung] aus der regulären Handhabung von Dokumenten des Versicherten ausnehmen und gegenüber einem Versicherten verbergen. [<=]

6.1.9.5 Aktenumzug

Bei einem Wechsel des Kostenträgers (Aktenumzug) ist eine eigenständige Erteilung der Einwilligung gemäß § 363 Absatz 2 SGB V gegenüber dem neuen Kostenträger erforderlich.

Diese erneute Einwilligung muss vor einem Umzug der Akte erteilt werden, wenn aktuell noch freigegebene Dokumente im Forschungsdatenzentrum vorliegen und diese Freigabe nach dem Umzug erhalten bleiben soll. Wird diese Einwilligung nicht erteilt, müssen vor dem Umzug der Akte alle freigegebenen Dokumente widerrufen werden.

A_22666 - ePA-FdV: Erteilung der Einwilligung gemäß § 363 Absatz 2 SGB V bei Aktenumzug

Das ePA-FdV MUSS einem Versicherten die Erteilung der Einwilligung gemäß § 363 Absatz 2 SGB V gegenüber dem neuen Kostenträger ermöglichen, wenn zum Zeitpunkt des Aktenumzugs freigegebene Dokumente des Versicherten beim Forschungsdatenzentrum vorliegen. [<=]

A_22667 - ePA-FdV: Widerruf aller freigegebenen Dokumente für Forschungszwecke bei Verzicht auf Einwilligung gemäß § 363 Absatz 2 SGB V bei Aktenumzug

Das ePA-FdV MUSS alle für Forschungszwecke aktuell freigegebenen Dokumente beim Forschungsdatenzentrum widerrufen, wenn ein Versicherter die Einwilligung gemäß § 363 Absatz 2 SGB V gegenüber dem neuen Kostenträger nicht erteilt. Dieser Widerruf MUSS vor Aufruf der Operation Suspend_Account des AccountManagement-Dienstes des Aktensystems abgeschlossen sein. [<=]

6.1.108 Anbindung an das Nationale Gesundheitsportal

Durch die Kopplung der ePA mit dem Nationalen Gesundheitsportal ([NGP]) soll dem Versicherten über das ePA-FdV, unabhängig von Gesundheitskompetenzniveau, eine Hilfestellung angeboten werden, durch die sich der Versicherte einen Zugang zu einfach verständlichen und von Experten bereitgestellten Gesundheitsinformationen verschaffen kann.

Der Versicherte hat über das ePA-FdV zwei Möglichkeiten auf die Inhalte des Nationalen Gesundheitsportal zu zugreifen. Einerseits kann der Versicherte über eine selektive schlagwortbasierte Suche aus dem ePA-FdV heraus auf die Inhalte des Nationalen Gesundheitsportal zugreifen. In dem Fall, dass im ePA-Aktensystem bereits strukturierte Daten vorliegen (eingestellt durch den Versicherten und/oder berechtigte Leistungserbringerbefugte Leistungserbringerinstitutionen bzw. Dritte), kann der Versicherte über das ePA-FdV gezielt auf im Nationalen Gesundheitsportal liegende Informationen zu Symptomen, Diagnosen oder medizinische Fachbegriffe zugreifen.

A_21473 - Zugriff auf das Nationale Gesundheitsportal aus dem ePA-FdV

Das ePA-FdV MUSS es dem Versicherten ermöglichen, auf Informationen des Nationalen Gesundheitsportals barrierefrei zuzugreifen. [<=]

A_21474 - Verknüpfen von Daten aus der ePA mit Informationen des Nationalen Gesundheitsportals

Das ePA-FdV MUSS es dem Versicherten ermöglichen, Informationen des Nationalen Gesundheitsportals mit Daten, die in der elektronischen Patientenakte des Versicherten gespeichert sind, zu verknüpfen. [<=]

6.1.119 Anbindung VZD-FHIR-Directory

Zur Authentisierung am VZD-FHIR-Directory nutzt das ePA-FdV ein search-access_token, welches das ePA-FdV am ePA-Aktensystem anfragt.

A_25177 - ePA-Frontend des Versicherten: Authentisierung am FHIR VZD

Das ePA-Frontend des Versicherten MUSS einmalig für die Suche des Versicherten nach Einträgen im VZD-FHIR-Directory den Anwendungsfall "AF_10219* - Versicherter sucht Einträge im FHIR-Directory" gemäß [gemSpec_VZD_FHIR_Directory] als Client unterstützen und dabei für die Client Anfrage von search-access_token die Operation getFHIRVZDtoken gemäß [I_Authorization_Service.yaml] verwenden.
[<=]

6.1.10 Dokumente für den statischen Ordner "technical"

Ein ePA-FdV kann technische Dokumente (Dokumente, die nicht Dokumente des Versicherten sind) bei Bedarf im Ordner "technical" ablegen, beispielsweise für eine Synchronisation von Zuständen zwischen verschiedenen ePA-FdVs des Versicherten.

A_23145 - ePA-Frontend des Versicherten: formatCode für Dokumente des Ordners "technical"

Das ePA-Frontend des Versicherten MUSS für herstellerspezifische Dokumente, die im Ordner "technical" abgelegt werden, einen formatCode mit der codeSystem OID "2.25.154081344090540725127779452347992051720" und einem code der Form "urn:<Hersteller>:ig:<Bezeichner>:<Version>" verwenden. [<=]

Hinweis: Der Teil <Hersteller> in code muss dabei so gewählt werden, dass eine Verwechselung mit einem anderen Hersteller ausgeschlossen ist.

Ein ePA-Frontend des Versicherten soll alle Dokumente des Ordners "technical" ignorieren, wenn diese nicht für den Verarbeitungskontext des ePA-FdV notwendig oder unbekannt sind.

Der Ordner "technical" im ePA-Aktensystem hat einen unveränderlichen Wert von Folder.entryUUID, siehe A_24491.

6.2 Implementation ePA-Anwendungsfälle im FdV

In diesem Kapitel wird die Umsetzung der im systemspezifischen Konzept [gemSysL_ePA] spezifizierten AnwendungsfälleAnwendungsfälle für ePA für alle im FdV beschrieben.

6.2.1 Übergreifende Festlegungen

Voraussetzung für die Nutzung des FdV ist das Vorhandensein eines Aktenkontos:

1.                      Der Versicherte verfügt über ein aktiviertes Aktenkonto (Anderenfallsoder ist ausschließlich der Anwendungsfall für die Aktivierung des Aktenkontos ausführbar.).als Vertreter für ein Aktenkonto befugt worden.
2.                      Die Akten-ID (der RecordIdentifierKVNR) des Aktenkontos, welche sich mittels der Versicherten-ID des Aktenkontoinhabers bestimmen lässt, ist im ePA-Frontend des Versicherten  bekannt.
3.                      Der FQDN für den Zugriff auf das ePA-Aktensystem ist im ePA-Frontend des Versicherten bekannt.

A_15567-06 - ePA-Frontend des Versicherten: Zulässigkeit der Anwendungsfälle

Das ePA-Frontend des Versicherten MUSS die Zulässigkeit des Anwendungsfalls in Abhängigkeit von folgenden Kriterien sicherstellen:
VerificationResult

•   K1: Rolle des Nutzers (Aktenkontoinhaber, Vertreter)

•   K2: Status Aktenkonto

•   K3: falls eGK zur Authentisierung genutzt wird: Status PIN (MRPIN.home) der eGK: [OK (PasswordEnabledVerified) / BLOCKED (PasswordBlocked) / VERIFYABLE (PasswordEnabledNotVerified.X)]

Tabelle 9: TAB_FdV_161 – Zulässigkeit von Anwendungsfällen

[<=]

Die Rolle des Nutzers kann durch den Vergleich der Versicherten-ID aus dem Authentisierungszertifikat der eGK (C.CH.AUT) bzw. der alternativen kryptographische Versichertenidentität (C.CH.AUT_ALT) des Nutzers mit der Versicherten-ID aus der Akten-ID bestimmt werden.

6.2.2 Fehlerbehandlung

Tritt ein Fehler bei der Verarbeitung von Operationsaufrufen des ePA-Aktensystems auf, dann antworten die Komponenten des ePA-Aktensystemsantwortet das ePA-Aktensystem mit einer Fehlermeldung. Das Format und die verwendeten Fehlercodes sind in den Spezifikationen der InterfacesSchnittstellen der jeweiligen Produkttypen beschrieben. Weiterhin können Fehler in der lokalen Verarbeitung auftreten.

A_15307-01 - ePA-Frontend des Versicherten: Abbruch bei Fehler im Anwendungsfall

Das ePA-Frontend des Versicherten MUSS, wenn bei der Abarbeitung der Aktivitäten eines Anwendungsfalls ein Fehler auftritt und keine Fehlerbehandlung beschrieben ist, den Anwendungsfall abbrechen. [<=]

Das FdV soll dem Nutzer nach einem Abbruch eine verständliche Fehlermeldung anzeigen.

A_24402 - ePA-Frontend des Versicherten: verständliche Fehlermeldung

Falls das ePA-Frontend des Versicherten wegen eines Fehlers einen Anwendungsfall abbricht, dann MUSS der Nutzer mit einer verständlichen Fehlermeldung über den Fehler informiert werden. [<=]

Wenn die Möglichkeit besteht, dass der Nutzer das fehlerverursachende Problem selbst beheben kann, kann das FdV den Nutzer auf die Lösung hinweisen. Bspw. kann dem Nutzer bei einer gesperrten PIN der Anwendungsfall "PIN der eGK entsperren" angeboten werden.

A_15308 - ePA-Frontend des Versicherten: Anzeige von Handlungsmöglichkeiten im Fehlerfall

Das ePA-Frontend des Versicherten SOLL dem Nutzer im Fehlerfall einen Hinweis geben, wenn es für den Nutzer Handlungsmöglichkeiten dazu gibt. [<=]

A_15309-02 - ePA-Frontend des Versicherten: Anzeige im Fehlerfall

Das ePA-Frontend des Versicherten MUSS bei Auftreten der Fehlercodes aus TAB_FdV_107 und TAB_FdV_108 dem Nutzer den entsprechenden Fehlertext anzeigen und die spezifische Aktion durchführen.
 

Tabelle 10: TAB_FdV_107 – Behandlung von Fehlercodes von Plattformbausteinen

Tabelle 11: TAB_FdV_108 – Behandlung von Fehlern des ePA-Aktensystems

[<=]

A_15310-01 - ePA-Frontend des Versicherten: Fehlerbehandlung ungültiger Token

Das ePA-Frontend des Versicherten MUSS, wenn eine Operation mit einer Fehlermeldung antwortet, welche auf einen ungültigen Authentisierungstoken oder ungültigen Autorisierungstoken verweist, den referenzierten Token aus den Session-Daten löschen. [<=]

A_15311-01 - ePA-Frontend des Versicherten: Aufrufparameter ungültig

Das ePA-Frontend des Versicherten MUSS bei allen Operationen mit einer qualifizierten Fehlermeldung abbrechen, wenn notwendige Aufrufparameter unvollständig, ungültig oder inkonsistent sind. [<=]

6.2.3 Aktivitäten

Dieser Abschnitt beschreibt Aktivitäten, welche durch verschiedene Anwendungsfälle genutzt werden.

6.2.3.1 Authentisieren des Nutzers

Mit dieser Operation authentisiert sich der Nutzer am ePA-Aktensystem. Das ePA-FdV erhält bei erfolgreicher Authentisierung einen Authentisierungstoken.

A_15312-02 - ePA-Frontend des Versicherten: Authentisieren des NutzersAuslösung der Benutzerauthentifizierung

A_24830 - ePA-Frontend des Versicherten: Senden von Authorization Request gegenüber Aktensystemen

Das ePA-Frontend des Versicherten MUSS, um die Nutzerauthentifizierung zu starten, die Operation send_Authorization_Request nutzen gemäß [I_Authorization_Service]. [<=]

Der Authorization Server kontaktiert nach dem Authorization Request des FdV auf einem direkten Kanal den sektoralen IDP mittels eines sogenannten Pushed Authorization Request, authentisiert sich diesem gegenüber und überträgt die für die Authentisierung des Nutzers gewünschten Parameter. Anschließend antwortet er dem FdV mit einem Satz an Parametern, welche an das Authenticator-Modul des sektoralen IDP übermittelt werden. Diese Response enthält ClientID (des Aktensystems) und request_uri (Identifikation des Request beim zugehörigen IDP).

Das Authenticator-Modul kann entweder in das FdV in das FdV integriert sein oder in einer separaten Authenticator-App implementiert sein.

Aufruf des Authenticator-Moduls
 

Das ePA-Frontend gibt die Antwort der send_Authorization_Request Operation an das Authenticator-Modul weiter.

Ist das Authenticator-Modul in das ePA-Fontend integriert, so kann gemäß A_24756 [gemSpec_IDP_Sek] ein Single-Sign-On (SSO) für den Zugriff auf die im ePA-Frontend integrierten TI-Fachdienste (z.B. E-Rezept) erfolgen. In diesem Fall erfolgt der Aufruf des Authenticator-Moduls über FdV interne Schnittstellen.

Ist das Authenticator-Modul in einer separaten Authenticator-App implementiert, so erfolgt der Aufruf als App-App-Kommunikation über Plattformmechanismen (deeplink, universal-link).

Das Authenticator-Modul realisiert die Authentisierung des Versicherten mittels eGK, online Ausweisfunktion oder weiteren zulässigen Verfahren des IDP.

Anwendungsinterner Aufruf durch Authenticator-Modul

Nach Abschluss der Nutzerauthentisierung durch den sektoralen IDP liefert dieser einen sogenannten Authorization_Code (Auth_Code) an das Authenticator-Modul des sektoralen IDP. Dieses leitet den Auth_Code zum FdV.

Ist das Authenticator-Modul in das FdV integriert, so erfolgt die Weiterleitung des Auth_Code über anwendungsinterne Schnittstellen.

Ist das Authenticator-Modul in einer separaten Authenticator-App implementiert, so erfolgt die Weiterleitung des Auth_Code als App-App-Kommunikation über Plattformmechanismen (deeplink, universal-link).

Anschließend wird über das FdV der Auth_Code an den Authorization Server des Aktensystems weitergeleitet.

A_24831 - ePA-Frontend des Versicherten: Weiterleitung des Auth_Code vom Authenticator-Modul zum Authorization Server

Das ePA-Frontend des Versicherten MUSS die Aktivität "Authentisieren des Nutzers" gemäß TAB_FdV_109 umsetzenden Auth_Code vom Authenticator-Modul annehmen und an den Authorization-Server unter Verwendung der Operation send_AuthCode gemäß [I_Authorization_Service] weiterleiten. [<=]

Der Authorization Server des Aktensystems authentisiert sich nun erneut gegenüber dem sektoralen IDP und tauscht den Auth_Code gegen ein ID_TOKEN mit den personenbezogenen Daten des Versicherten ein.

Diese Daten werden anschließend der etablierten VAU Sitzung im ePA-Aktensystem zugeordnet und signalisieren damit dem Aktensystem die Identität des Nutzers.

Mit der send_AuthCode-Response erhält das FdV die Zugriffserlaubnis auf das Aktensystem. Die User-Session ist etabliert und fachliche Operationen sind möglich.

6.2.3.2 Leistungserbringerinstitution im Verzeichnisdienst der TI finden

Informationen zu Leistungserbringerinstitutionen sind im Verzeichnisdienst FHIR-Directory (VZD-FHIR-Directory) der TI-Plattform hinterlegt. Der Nutzer des FdV kann (bspw. für die Erstellung einer Befugnis für eine LEI) mit verschiedenen Kriterien nach Leistungserbringerinstitutionen im VZD-FHIR-Directory suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD_FHIR_Directory#4.1.1 Datenmodell] beschrieben.

Tabelle 12: TAB_FdV_109 – Authentisieren des Nutzers Die Suche nach LEIs erfolgt primär über den Namen oder Institutionsnamen, aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.

A_24387 - ePA-Frontend des Versicherten: LEI - Search Operation am VZD-FHIR-Directory

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Leistungserbringerinstitutionen über die folgenden Suchkriterien im VZD-FHIR-Directory gemäß [gemSpec_VZD_FHIR_Directory#5.5] zu suchen. 

Tabelle 8: FHIR Suche LEI

[<=]

Die Dauer der Gültigkeit des Authentisierungstoken ist in [gemSpec_Authentisierung_Vers] beschrieben.Da nur Leistungserbringerinstitutionen und keine einzelnen Leistungserbringer für den Zugriff auf ein Aktenkonto befugt werden können, müssen die durch den Nutzer eingegebenen Suchparameter ggf. für die Abfrage am VZD-FHIR-Directory so ergänzt werden, dass nur Informationen zu Leistungserbringerinstitutionen abgefragt werden.

A_25134 - ePA-Frontend des Versicherten: LEI - Volltextsuche am VZD-FHIR-Directory

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, LEIs über die Volltextsuche im VZD-FHIR-Directory gemäß https://github.com/gematik/api-vzd/blob/main/docs/FHIR_VZD_HOWTO_Search.adoc#full-text-search  zu suchen.  [<=]

6.2.3.2 Authentisierungstoken erneuern3 DiGA im Verzeichnisdienst der TI finden

Mit dieser Operation kann das ePA-Frontend des Versicherten den Authentisierungstoken am ePA-Aktensystem verlängern.

A_17541-01 - ePA-Frontend des Versicherten: Authentisierungstoken erneuernInformationen zu DiGAs sind im Verzeichnisdienst FHIR-Directory (VZD-FHIR-Directory) der TI-Plattform hinterlegt. 

Der Nutzer des FdV kann (bspw. für die Erstellung einer Befugnis für eine DiGA) mit verschiedenen Kriterien nach DiGAs im VZD-FHIR-Directory suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD_FHIR_Directory#4.1.1 Datenmodell] beschrieben.

Die Suche nach DiGAs erfolgt primär über den Namen der DiGA.

A_25131 - ePA-Frontend des Versicherten: DiGA - Search Operation am VZD-FHIR-Directory

Das ePA-Frontend des Versicherten MUSS die Aktivität "Authentisierungstoken erneuern" gemäß TAB_FdV_173 umsetzen.es dem Nutzer ermöglichen, DiGAs über die folgenden Suchkriterien im VZD-FHIR-Directory gemäß [gemSpec_VZD_FHIR_Directory#5.5] zu suchen. 

Tabelle 13: TAB_FdV_173 – Logout - Authentisierungstoken abmelden 9: FHIR Suche DiGA

[<=]

Der vorher genutzte Authentisierungstoken wird gelöscht.

Im Fehlerfall kann die Operation wiederholt oder eine neue Authentisierung des Nutzers gestartet werden.

6.2.3.3 Dokumentenset in Dokumentenverwaltung hochladen

Mit dieser Operation werden ein oder mehrere Dokumente in die Dokumentenverwaltung hochgeladen. Hierbei kann es sich entweder um durch den Nutzer ausgewählte (fachliche) Versichertendokumente oder um technische Dokumente (z.B. ein Policy Document) handeln. Eine Mischung beider Arten von Dokumenten innerhalb eines Dokumentensets ist nicht erlaubt.

A_15314-01 - ePA-Frontend des Versicherten: Dokumentenset in Dokumentenverwaltung hochladen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" gemäß TAB_FdV_111 umsetzen.

Tabelle 14: TAB_FdV_111 – Dokumentenset in Dokumentenverwaltung hochladen

[<=]

A_15315-01 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-41]

Das ePA-Frontend des Versicherten MUSS für die Nutzung der Operation I_Document_Management_Insurant::ProvideAndRegisterDocumentSet-b gemäß der in [IHE-ITI-TF] definierten IHE XDS-Transaktion [ITI-41] "Provide & Register Document Set-b" als Akteur "Document Source" umsetzen. [<=]

Für die XDS-Metadaten von Dokumenten des Versicherten gelten die Nutzungsvorgaben aus [gemSpec_DM_ePA#A_14760-*]. Für die XDS-Metadaten eines Policy Documents gelten die Nutzungsvorgaben aus [gemSpec_DM_ePA#A_14961-*].

A_15316-01 - ePA-Frontend des Versicherten: Upload verschlüsselter Versichertendokumente

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass Dokumente des Versicherten, welche in das ePA-Aktensystem eingestellt werden, verschlüsselt sind. [<=]

Technische Dokumente (Policy Documents) werden nach der Übertragung in das Aktenkonto durch die Dokumentenverwaltung ausgewertet.

A_17772-01 - ePA-Frontend des Versicherten: Upload unverschlüsselter technischer Dokumente

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass technische Dokumente (Policy Documents) unverschlüsselt, d.h. nicht mit dem Aktenschlüssel verschlüsselt, in das ePA-Aktensystem eingestellt werden.  [<=]

A_15972-01 - ePA-Frontend des Versicherten: Trennung fachlicher und technischer Dokumente beim Upload

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass eine Provide And Register Document Set-b Message entweder ein oder mehrere Versichertendokumente oder genau ein technisches Dokument enthält. [<=]

A_16221-01 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-41] - Unterstützung MTOM/XOP

Das ePA-Frontend des Versicherten MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-41] zur Übertragung von Dokumenten eine Kodierung mittels MTOM/XOP [MTOM] gemäß [IHE-ITI-TF2x#V.3.6.] verwenden. [<=]

Das ePA-Aktensystem lehnt beim Einstellen von Dokumenten Requests ab, wenn die Summe der Größe der Dokumente in einem Submission Set 250 MB überschreitet. Das ePA-Frontend des Versicherten kann Einstellversuche von Dokumentensets unterbinden, wenn diese von der Dokumentenverwaltung aufgrund der Größenbeschränkung abgelehnt würden.

6.2.3.4 Dokumentenset aus Dokumentenverwaltung herunterladen

Mit dieser Operation werden ein oder mehrere Dokumente anhand der Document Unique IDs aus den XDS-Metadaten aus dem Aktenkonto heruntergeladen.

A_15317-02 - ePA-Frontend des Versicherten: Dokumentenset aus Dokumentenverwaltung herunterladen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Dokumentenset aus Dokumentenverwaltung herunterladen" gemäß TAB_FdV_112 umsetzen.

Tabelle 15: TAB_FdV_112 – Dokumentenset aus Dokumentenverwaltung herunterladen

[<=]

A_15318-01 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-43]

Das ePA-Frontend des Versicherten MUSS für die Nutzung der Operation I_Document_Management_Insurant::RetrieveDocumentSet gemäß der in [IHE-ITI-TF] definierten IHE XDS-Transaktion [ITI-43] "Retrieve Document Set" als Akteur "Document Consumer" umsetzen. [<=]

A_16222-02 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-43] - MTOM unterstützen

Das ePA-Frontend des Versicherten MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-43] die Übertragung von Dokumenten mit MTOM/XOP [MTOM] unterstützen. [<=]

6.2.3.5 Dokumentenset in Dokumentenverwaltung löschen

Mit dieser Operation werden ein oder mehrere Dokumente anhand ihrer entryUUIDs aus der Dokumentenverwaltung gelöscht. Die XDS-Metadaten wurden vorab mit einer Suche nach Dokumenten im ePA-Aktensystem ermittelt.

A_15319-02 - ePA-Frontend des Versicherten: Dokumentenset in Dokumentenverwaltung löschen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Dokumentenset in Dokumentenverwaltung löschen" gemäß TAB_FdV_113 umsetzen.

Tabelle 16: TAB_FdV_113 – Dokumentenset in Dokumentenverwaltung löschen

[<=]

A_15320-02 - ePA-Frontend des Versicherten: IHE RMD-Transaktion [ITI-62]

Das ePA-Frontend des Versicherten MUSS die Nutzung der Operation I_Document_Management_Insurant::RemoveMetadata gemäß der in [IHE-ITI-RMD] definierten IHE RMD-Transaktion [ITI-62] "Remove Metadata" als Akteur "Document Administrator" umsetzen. [<=]

6.2.3.6 Suche nach Dokumenten in Dokumentenverwaltung

Mit dieser Operation wird eine Suchanfrage über die XDS-Metadaten der Dokumente im Aktenkonto an die Dokumentenverwaltung gesendet.

A_15321-01 - ePA-Frontend des Versicherten: Suche nach Dokumenten in Dokumentenverwaltung

Das ePA-Frontend des Versicherten MUSS die Aktivität "Suche nach Dokumenten in Dokumentenverwaltung" gemäß TAB_FdV_114 umsetzen.

Tabelle 17: TAB_FdV_114 – Suche nach Dokumenten in Dokumentenverwaltung

[<=]

A_15322-01 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-18]

Das ePA-Frontend des Versicherten MUSS für die Nutzung der Operation I_Document_Management_Insurant::RegistryStoredQuery gemäß der in [IHE-ITI-TF] definierten IHE XDS-Transaktion [ITI-18] "Registry Stored Query" als Akteur "Document Consumer" umsetzen. [<=]

A_17854-01 - ePA-Frontend des Versicherten: Nutzung des Anfragetyps "FindDocumentsByTitle"

Das ePA-Frontend des Versicherten MUSS den in [ITI-18] nicht enthaltenen zusätzlichen Anfragetyp "FindDocumentsByTitle" mit der Query-ID "urn:uuid:ab474085-82b5-402d-8115-3f37cb1e2405" und denselben Parameternutzungsvorgaben der Registry Stored Query "FindDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.1] in Verbindung mit dem zusätzlich zu [ITI-18] eingeführten Suchparameter $XDSDocumentEntryTitle sowie dem optionalen Parameter $XDSDocumentEntryAuthorInstitution nutzen können. [<=]

Der zusätzliche Parameter "$XDSDocumentEntryTitle" filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.title. Dabei ist die Angabe von Platzhaltern (wie für Suchanfragen über den Parameter $XDSDocumentEntryAuthorPerson) möglich, die sich verhält wie das SQL Schlüsselwort "LIKE" in Kombination mit den anzugeben Wildcard-Zeichen "%", um jedes beliebige Zeichen und "_", um ein einzelnes beliebiges Zeichen zu finden.

Der optionale Parameter "$XDSDocumentEntryAuthorInstitution" filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.authorInstitution.

6.2.3.7 Vergebene Berechtigungen bestimmen

Mit dieser Operation werden die für das Aktenkonto vergebenen Berechtigungen ermittelt. Für jeden Berechtigten ist in der Komponente Autorisierung ein AuthorizationKey und in der Komponente Dokumentenverwaltung ein technisches Dokument (Policy Document) hinterlegt. Letzteres beinhaltet die Parameter der Berechtigung.

A_15323-02 - ePA-Frontend des Versicherten: Vergebene Berechtigungen bestimmen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Vergebene Berechtigungen bestimmen" gemäß TAB_FdV_115 umsetzen.
 

Tabelle 18: TAB_FdV_115 – Vergebene Berechtigungen bestimmen

[<=]

A_17129-01 - ePA-Frontend des Versicherten: Berechtigung bestimmen - Schlüsselmaterial aller Berechtigten laden

Das ePA-Frontend des Versicherten MUSS für die Aktivität "Vergebene Berechtigungen bestimmen" die übergreifende Aktivität "Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden" ausführen. [<=]

Dokumente im Aktenkonto werden mittels ihrer XDS-Metadaten identifiziert. Die Nutzungsvorgaben für XDS-Metadaten zur Kennzeichnung von Policy Documents sind in [gemSpec_DM_ePA#A_14961-*] beschrieben.

A_15324-01 - ePA-Frontend des Versicherten: Berechtigung bestimmen - Policy Documents suchen

Das ePA-Frontend des Versicherten MUSS für die Aktivität "Vergebene Berechtigungen bestimmen" zur Suche der Policy Documents die übergreifende Aktivität "Suche nach Dokumenten in Dokumentenverwaltung" mit einer query:AdhocQueryRequest_Message für Policy Documents ausführen. [<=]

Das Ergebnis der Suchanfrage query:AdhocQueryResponse_Message liefert, falls Berechtigungen erteilt wurden, die XDS-Metadaten von einem oder mehreren Policy Documents (je ein Policy Document pro LEI, KTR, DiGA bzw. Vertreter). Die XDS-Metadaten beinhalten die eindeutigen Kennungen (DocumentEntry.uniqueId) der Policy Documents. Mittels dieser werden die Policy Documents im nächsten Schritt aus der Dokumentenverwaltung heruntergeladen.

A_15325-01 - ePA-Frontend des Versicherten: Berechtigung auflisten - Policy Dokuments herunterladen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vergebene Berechtigungen anzeigen" zum Herunterladen der Policy Documents die übergreifende Aktivität "Dokumentenset aus Dokumentenverwaltung herunterladen" mit einer RetrieveDocumentSet_Message für alle über die XDS-Metadaten ermittelten Kennungen (DocumentEntry.uniqueId) von Policy Documents ausführen. [<=]

Als Ergebnis liegen, falls Berechtigungen erteilt wurden, ein oder mehrere AuthorizationKeys sowie Policy Documents für berechtigte LEI, KTR, DiGA und für Vertreter vor.

Gemäß der Beschreibung in "" können folgende Informationen zu den Berechtigungen aus den Policy Documents bzw. den XDS-Metadaten ermittelt werden.

Berechtigung für LEI: Telematik-ID, Name der LEI, Berechtigung "erteilt am", Berechtigung "gültig bis", Zugriffsrecht der LEI berechtigte Dokumentenkategorien, einzeln freigeschaltete oder geblockte Dokumente (Allowlist, Denylist)

Gemäß der Beschreibung in "" können folgende Informationen zu den Berechtigungen aus den AuthorizationKeys ermittelt werden.

Berechtigung für Vertreter: Versicherten-ID, Name des Vertreters

Berechtigung für KTR: Telematik-ID, Name des KTR

Berechtigung für DiGA: Telematik-ID, Name der DiGA

Die Policy Documents lassen sich auf Basis der Versicherten-ID des Vertreters bzw. der Telematik-ID der LEI, DiGA oder KTR den AuthorizationKeys zuordnen.

6.2.3.8 AuthorizationKey

Der AuthorizationKey enthält Parameter zur Berechtigung sowie die für den Berechtigten verschlüsselten Akten- und Kontextschlüssel.

6.2.3.8.1 Struktur AuthorizationKeyType

Die Struktur AuthorizationKeyType ist in [AuthorizationService.xsd] beschrieben.

Das Attribut validTo beinhaltet die Gültigkeit des AuthorizationKey, d.h. den Zeitpunkt bis zu dem die Berechtigung erteilt wird. Für eine Berechtigung ohne zeitliche Begrenzung wird ein technisches Datum (31.12.9999) verwendet.

Das Attribut actorID beinhaltet die ID des Berechtigenden, d.h. die Versicherten-ID für Aktenkontoinhaber und Vertreter bzw. die Telematik-ID für LEIs, DiGA und KTR.

Das Element DisplayName beinhaltet den Klartextnamen des Berechtigten oder den Namen der berechtigten DiGA.

Das Element AuthorizationType beinhaltet den Berechtigungstyp. Siehe auch .

Das Element phrs:AuthorizationKey/phrs:EncryptedKeyContainer enthält das Chiffrat mit dem verschlüsselten Akten- und Kontextschlüssel sowie AssociatedData.

Die Datenstruktur für EncryptedKeyContainer und die Klartextpräsentation für Akten- und Kontextschlüssel ist in  beschrieben.

6.2.3.8.2 Schlüsselableitung für Ver- und Entschlüsselung

Die Klartextpräsentation von Akten- und Kontextschlüssel im AuthoritationKey ist doppelt symmetrisch verschlüsselt. Die symmetrischen Schlüssel zur Ver- und Entschlüsselung von Akten- und Kontextschlüssel werden über die Schlüsselableitungsfunktion der Schlüsselgenerierungsdienste Typ 1 und 2 ermittelt. Die Funktionsweise der Schlüsselgenerierung wird in [gemSpec_SGD_ePA] beschrieben.

A_17842-01 - ePA-Frontend des Versicherten: Symmetrische Schlüssel für Akten- und Kontextschlüssel ermitteln

Das ePA-Frontend des Versicherten MUSS zur Schlüsselableitung den in  festgelegten Ablauf in der Rolle Client durchführen. [<=]

Im Schritt 7 des Basisablaufs erfolgt der Aufruf für KeyDerivation abhängig vom Anwendungsfall:

Als Ergebnis bei einer erfolgreichen Schlüsselableitung zum Verschlüsseln erhält das ePA-FdV von jedem der beiden SGD eine Antwortnachricht für KeyDerivation im Format: "OK-KeyDerivation "+Key+" "+a

Key ist der für die Verschlüsselung zu verwendende symmetrische Schlüssel und a entspricht AssociatedData für den entsprechenden SGD.

Zur Optimierung der Performance muss das ePA-FdV die Schlüsselableitung für SGD 1 (Basisablauf Schritt 1) und SGD 2 (Basisablauf Schritt 3) und das Erzeugen eines ephemeren ECDH-Schlüsselpaares (Basisablauf Schritt 5) parallel ausführen. Der Request an SGD 1 und SGD 2 in Basisablauf Schritt 7 können ebenfalls parallelisiert werden. Die bei einer Schlüsselableitung für eine Entschlüsselung im Request für KeyDerivation zu übermittelnden Informationen werden sowohl für SGD 1 als auch SGD 2 dem Element phrs:AuthorizationKey/phrs:EncryptedKeyContainer/phrs:AssiciatedData entnommen.

A_17994-01 - ePA-Frontend des Versicherten: Aufrufe zur Schlüsselableitung parallelisieren

Das ePA-Frontend des Versicherten MUSS die Schlüsselableitung mit SGD 1 und SGD 2 sowie das Erzeugen des ephemeren ECDH-Schlüsselpaares parallelisieren. [<=]

Siehe auch .

6.2.3.8.3 AuthorizationKey erstellen

Für den Aktenkontoinhaber, Vertreter, DiGA und KTR wird die Berechtigung ohne zeitliche Begrenzung vergeben. Für LEI ist das Enddatum entsprechend der vom Nutzer gewählten Berechtigungsdauer zu setzen. Der für DisplayName zu verwendende Name einer LEI, einer DiGA oder eines KTR und die Telematik-ID werden aus dem Eintrag der zu berechtigenden Institution im VZD bestimmt (siehe "").

A_18248-01 - ePA-Frontend des Versicherten: AuthorizationKey erstellen - Verschlüsselungszertifikate für Telematik-ID verwenden

Das ePA-Frontend des Versicherten MUSS beim Erstellen eines AuthorizationKeys für das Ermitteln der Telematik-ID einer Leistungserbringerinstitution oder eines Kostenträger ein Verschlüsselungszertifikat der Institution verwenden. [<=]

A_16204-01 - ePA-Frontend des Versicherten: AuthorizationKey erstellen - Verschlüsselungszertifikate Gültigkeit online prüfen

Das ePA-Frontend des Versicherten MUSS beim Erstellen eines AuthorizationKey alle verwendeten Verschlüsselungszertifikate prüfen und den Anwendungsfall abbrechen, wenn das Zertifikat in der Prüfung abgelehnt wurde oder der Sperrstatus nicht ermittelt werden konnte. [<=]

Es werden bei der Autorisierung verschiedene Berechtigungstypen unterschieden. Siehe . Für Aktenkontoinhaber, Vertreter, LEIs, DiGA und KTR wird immer ein Berechtigung mit Zugriff auf die Dokumente vergeben.

A_15328-01 - ePA-Frontend des Versicherten: AuthorizationKey erstellen - Berechtigungstyp DOCUMENT_AUTHORIZATION

Das ePA-Frontend des Versicherten MUSS beim Erstellen eines AuthorizationKey den AuthorizationType = DOCUMENT_AUTHORIZATION setzen, wenn dem zu Berechtigenden Zugriff auf Dokumente in der Dokumentenverwaltung gewährt werden soll. [<=]

Akten- und Kontextschlüssel werden mit den in der Schlüsselableitung erhaltenen Schlüssel symmetrisch verschlüsselt. Es gelten die Vorgaben aus  sowie .

A_17995-02 - ePA-Frontend des Versicherten: AuthorizationKey erstellen - Akten- und Kontextschlüssel verschlüsseln

Das ePA-Frontend des Versicherten MUSS beim Erstellen eines AuthorizationKeys den Akten- und Kontextschlüssel mit den von der Schlüsselableitung mit SGD 1 und SGD 2 erhaltenen symmetrischen Schlüssel gemäß [gemSpec_SGD_ePA] und [gemSpec_Krypt] verschlüsseln.

Tabelle 19: TAB_FdV_179 – Akten- und Kontextschlüssel verschlüsseln

[<=]

6.2.3.8.4 AuthorizationKey entschlüsseln

Der AuthorizationKey für einen Versicherten (Aktenkontoinhaber oder Vertreter) enthält ein verschlüsseltes Schlüsselpaar (Akten- und Kontextschlüssel).

Der Aktenschlüssel wird benötigt, um die Dokumente aus dem ePA-Aktensystem zu ver- und entschlüsseln. Der Kontextschlüssel wird benötigt, um den Verarbeitungskontext der Dokumentenverwaltung zu öffnen.

Das Chiffrat phrs:AuthorizationKey/phrs:EncryptedKeyContainer/phrs:CipherText ist doppelt symmetrisch verschlüsselt. Die für die Entschlüsselung des Chiffrats benötigten zwei AES-256-Schlüssel ruft das FdV von den Schlüsselgenerierungsdiensten Typ 1 und Typ 2 gemäß [gemSpec_SGD_ePA] ab. Siehe " ". 

Es gelten für das Entschlüsseln die Vorgaben aus  sowie .

A_17843 - ePA-Frontend des Versicherten: Akten- und Kontextschlüssel entschlüsseln

Das ePA-Frontend des Versicherten MUSS beim Entschlüsseln des Akten- und Kontextschlüssel die bei der Schlüsselableitung mit SGD 1 und SGD 2 erhaltenen symmetrischen Schlüssel gemäß [gemSpec_SGD_ePA] und [gemSpec_Krypt] nutzen.

Tabelle 20: TAB_FdV_180 – Akten- und Kontextschlüssel entschlüsseln

[<=]

6.2.3.9 Schlüsselmaterial aus ePA-Aktensystem laden

Mit dieser Operation wird die Autorisierung eines Nutzers des FdV für ein Aktenkonto geprüft und die Schlüssel eines berechtigten Nutzers (bspw. Aktenkontoinhaber, berechtigter Vertreter, LEI) für den Zugriff auf die Dokumentenverwaltung heruntergeladen.

A_15330-02 - ePA-Frontend des Versicherten: Schlüsselmaterial aus ePA-Aktensystem laden

Das ePA-Frontend des Versicherten MUSS die Aktivität "Schlüsselmaterial aus ePA-Aktensystem laden" gemäß TAB_FdV_116 umsetzen.

Tabelle 21: TAB_FdV_116 – Schlüsselmaterial aus ePA-Aktensystem laden

[<=]

Besitzt der Nutzer, für den das Schlüsselmaterial angefragt wird, keine Autorisierung für den Zugriff auf das Aktenkonto, dann beinhaltet die Response den Fehler KEY_ERROR.

Wird versucht das Schlüsselmaterial für den Aktenkontoinhaber herunterzuladen und beinhaltet der Response eine AuthorizationAssertion aber kein AuthorizationKey, dann ist das Aktenkonto des Versicherten noch nicht aktiviert. Das Aktivieren kann über die Anwendungsfälle "Aktenkonto aktivieren" oder "Anbieter wechseln" erfolgen.

6.2.3.10 Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden

Mit dieser Operation wird das Schlüsselmaterial für alle Berechtigten des Aktenkontos heruntergeladen. Im Response werden keine AuthorizationAssertion übertragen.

A_17130-01 - ePA-Frontend des Versicherten: Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden

Das ePA-Frontend des Versicherten MUSS die Aktivität "Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden" gemäß TAB_FdV_163 umsetzen.

Tabelle 22: TAB_FdV_163 – Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden

[<=]

6.2.3.11 Schlüsselmaterial im ePA-Aktensystem speichern

Mit dieser Operation wird Schlüsselmaterial (AuthorizationKey) für den Aktenkontoinhaber, einen Vertreter oder eine LEI in der Komponente Autorisierung des ePA-Aktensystems gespeichert. Beim Operationsaufruf für einen Vertreter wird eine Benachrichtigungsadresse (E-Mail) für die Geräteautorisierung hinterlegt (Parameter NotificationInfoRepresentative).

A_15331-02 - ePA-Frontend des Versicherten: Schlüsselmaterial im ePA-Aktensystem speichern

Das ePA-Frontend des Versicherten MUSS die Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" gemäß TAB_FdV_117 umsetzen.

Tabelle 23: TAB_FdV_117 – Schlüsselmaterial im ePA-Aktensystem speichern

[<=]

Wenn die Operation den Fehler KEY_ERROR meldet, dann ist bereits ein Schlüssel in der Autorisierung hinterlegt. Dies kann bspw. bei einer Berechtigung der Fall sein, wenn die Berechtigung bereits zuvor erfolgreich erteilt wurde, oder wenn bei einem vorherigen Versuch die Berechtigung einzurichten ein Fehler auftrat, nachdem Schlüsselmaterial erfolgreich hinterlegt wurde (bspw. das zugehörige Policy Document nicht erfolgreich in der Dokumentenverwaltung hinterlegt werden konnte).

A_15332-01 - ePA-Frontend des Versicherten: Schlüsselmaterial im ePA-Aktensystem speichern KEY_ERROR

Das ePA-Frontend des Versicherten MUSS, wenn die Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" den Fehler KEY_ERROR liefert, einmalig den Anwendungsfall nicht abbrechen, das bereits hinterlegte Schlüsselmaterial mit der Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" löschen und die Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" wiederholen. [<=]

6.2.3.12 Schlüsselmaterial im ePA-Aktensystem ersetzen

Mit dieser Operation wird vorhandenes Schlüsselmaterial (AuthorizationKey) für den Aktenkontoinhaber, einen Vertreter oder eine LEI in der Komponente Autorisierung des ePA-Aktensystems ersetzt.

A_15333-01 - ePA-Frontend des Versicherten: Schlüsselmaterial im ePA-Aktensystem ersetzen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Schlüsselmaterial im ePA-Aktensystem ersetzen" gemäß TAB_FdV_118 umsetzen.

Tabelle 24: TAB_FdV_118 – Schlüsselmaterial im ePA-Aktensystem ersetzen

[<=]

6.2.3.13 Schlüsselmaterial im ePA-Aktensystem löschen

Mit dieser Operation wird vorhandenes Schlüsselmaterial (AuthorizationKey) für einen Vertreter oder eine LEI in der Komponente Autorisierung des ePA-Aktensystems gelöscht.

A_15334-01 - ePA-Frontend des Versicherten: Schlüsselmaterial im ePA-Aktensystem löschen

Das ePA-Frontend des Versicherten MUSS die Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" gemäß TAB_FdV_119 umsetzen.

Tabelle 25: TAB_FdV_119 – Schlüsselmaterial im ePA-Aktensystem löschen

[<=]

6.2.3.14 Leistungserbringerinstitution im Verzeichnisdienst der TI finden

Informationen zu Leistungserbringern und Leistungserbringerinstitutionen sind im Verzeichnisdienst (VZD) der TI-Plattform hinterlegt. Der Nutzer der FdV kann (bspw. für die Vergabe von Berechtigungen an LEI) mit verschiedenen Kriterien nach LE und LEI im VZD suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD#5] beschrieben.

Die Suche nach LE oder LEIs erfolgt primär über den Namen oder Institutionennamen aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.

A_15335-01 - ePA-Frontend des Versicherten: Search Operation mittels LDAP-Directory Basisdatensatz AttributA_25133 - ePA-Frontend des Versicherten: DiGA - Volltextsuche am VZD-FHIR-Directory

Das ePA-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, Leistungserbringerinstitutionen über Suchkriterien gemäß TAB_FdV_120 zu suchen.

Tabelle 26: TAB_FdV_120 – Suchkriterien LDAP Search

[<=]

Da nur Leistungserbringerinstitutionen und keine einzelnen Leistungserbringer für den Zugriff auf ein Aktenkonto berechtigt werden können, müssen die durch den Nutzer eingegebenen Suchparameter ggf. für die VZD-Abfrage so ergänzt werden, dass nur Informationen zu Leistungserbringerinstitutionen abgefragt werden. Dies kann anhand des Parameters entryType=3 oder, wenn spezifischere Informationen zur Art der Leistungserbringerinstitution vorliegen, über den Parameter professionOID im Wertebereich gemäß [gemSpec_VZD#Tab_VZD_Mapping_Eintragstyp Eingangstyp 3] erfolgen.

Die VZD-Abfrage wird gemäß der übergreifenden Aktivität "Suchanfrage Verzeichnisdienst der TI" durchgeführt.

6.2.3.15 DiGA im Verzeichnisdienst der TI finden

Informationen zu DiGAs sind im Verzeichnisdienst (VZD) der TI-Plattform hinterlegt. Der Nutzer der FdV kann (bspw. für die Vergabe von Berechtigungen an eine DiGA) mit verschiedenen Kriterien nach DiGAs im VZD suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD#5] beschrieben.

A_22668 - ePA-Frontend des Versicherten: Search Operation mittels LDAP-Directory Basisdatensatz Attribut

Das ePA-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, DiGAs über Suchkriterien gemäß TAB_FdV_190 zu suchen.

Tabelle 27: TAB_FdV_190 – Suchkriterien LDAP Search für DiGA

[<=]

Das Ergebnis kann eine Liste von Apps unterschiedlicher Hersteller sein, aus welcher der Versicherte diejenige DiGA auswählt, die er berechtigen möchte. Eine genauere Eingrenzung der Suchergebnisse kann am FdV über organizationName (Name des DiGA-Herstellers) und commonName (Name der DiGA) erfolgen.

Das Verschlüsselungszertifikat im Ergebnis der Abfrage beinhaltet die Telematik-ID des zu berechtigenden DiGA-Herstellers und den Namen der DiGA.

6.2.3.16 Suchanfrage Verzeichnisdienst der TI

Der VZD der TI ist für Suchoperationen des ePA-Frontend des Versicherten  über das Zugangsgateway des Versicherten erreichbar, welches als LDAP-Proxy agiert. Das ePA- FdV nutzt zur Abfrage des VZD den Standard Directory Services Makeup Language v2.0 [DSML2.0].

A_18256-01 - ePA-Frontend des Versicherten: Search Operation mittels LDAP-Directory Basisdatensatz Attribut

Das ePA-Frontend des Versicherten MUSS für eine Suchanfrage im VZD der TI eine LDAP search Operation basierend auf dem VZD Datenmodell umsetzen. [<=]

Für das Datenmodell des LDAP-Verzeichnis siehe [gemSpec_VZD].

A_15336-01 - ePA-Frontend des Versicherten: Suchanfrage Verzeichnisdienst der TI

Das ePA-Frontend des Versicherten MUSS die Aktivität "Suchanfrage Verzeichnisdienst der TI" gemäß TAB_FdV_121 umsetzen.

Tabelle 28: TAB_FdV_121 – Abfrage Verzeichnisdienst

[<=]

Für ein Beispiel für eine Suchanfrage und ein Ergebnis siehe .

Die Anzahl der Einträge im Ergebnis der Suchabfrage wird durch den VZD beschränkt. (siehe ) 

Die Anzahl der möglichen Anfragen an den Verzeichnisdienst ist begrenzt (default: 10 Anfragen pro Minute). Wird die Anzahl überschritten, beinhaltet der HTTP-Response des Zugangsgateway des Versicherten den HTTP-Statuscode 429 entsprechend RFC6585 Kapitel 4 "429 Too Many Requests". Der Response mit dem HTTP-Statuscode 429 stellt keinen Fehler dar. Der Anwendungsfall wird nicht abgebrochen. Das FdV muss den Nutzer informieren, dass der nächste Request erst nach einer Verzögerung möglich ist.

Die im dsmlEnvelopeResponse gelieferten Informationen beinhalten die Informationen zum Name der Institution und Verschlüsslungszertifikate, welche für die Vergabe von Berechtigungen weiterverarbeitet werden.

Der Name einer Institution oder einer DiGA wird aus dem Basisdatensatz Attribut displayName bestimmt. Die Telematik-ID einer Institution oder einer DiGA wird aus einem Verschlüsselungszertifikat des Datensatzes bestimmt (siehe [gemSpec_PKI]).

6.2.3.17 PIN-Eingabe für eGK durch Nutzer

Mit dieser Operation wird der Nutzer zur fachlich motivierten PIN-Eingabe für seine eGK aufgefordert.

Zusätzlich kann bei Nutzung einer eGK eine PIN-Eingabe für die Berechtigung zum Zugriff auf Daten auf der eGK notwendig sein. In dem Fall wird die Aufforderung zur PIN-Eingabe durch den CardProxy ausgelöst.

A_15338-01 - ePA-Frontend des Versicherten: PIN-Eingabe für eGK durch Nutzer

Das ePA-Frontend des Versicherten MUSS die Aktivität "PIN-Eingabe durch Nutzer" gemäß TAB_FdV_122 umsetzen.

Tabelle 29: TAB_FdV_122 – PIN-Eingabe durch Nutzer

[<=]

A_15339-01 - ePA-Frontend des Versicherten: Abbruch Anwendungsfall nach fehlgeschlagener Nutzerverifikation

Das ePA-Frontend des Versicherten MUSS, wenn die Nutzerverifikation in der Operation "PIN-Eingabe durch Nutzer" fehlschlägt, den Anwendungsfall abbrechen, in dem die Operation aufgerufen wurde. Nutzer ermöglichen, DiGAs über die Volltextsuche im VZD-FHIR-Directory gemäß https://github.com/gematik/api-vzd/blob/main/docs/FHIR_VZD_HOWTO_Search.adoc#full-text-search  zu suchen.  [<=]

6.2.4 Nutzerzugang ePA

6.2.4.1 Login AktensessionUser

Mit diesem Anwendungsfall wird die Aktensession eines Nutzers im FdV gestartet. Der Sessionstart erfolgt implizit, falls die Verbindung zum ePA-Aktensystem bei Ausführung eines fachlichen Anwendungsfalls der ePA erforderlich ist und nicht besteht oder explizit beim Start des FdV durch den Nutzereine sichere Verbindung in das ePA-Aktensystem für den Nutzer gestartet.

Für die Anmeldung des Nutzers mit seiner eGK wird eine 2-Faktor-Authentisierung (eGK + PIN)die GesundheitsID verwendet. Als weitere Möglichkeit kann die alternative kryptographische Versichertenidentität genutzt werden. Nach erfolgreicher Authentisierung inklusive Gültigkeitsprüfung der eGK und Autorisierung wird das empfängerverschlüsselte Schlüsselmaterial heruntergeladen und das Öffnen des Aktenkontextes in der Komponente "Dokumentenverwaltung" für das referenzierte Aktenkonto durchgeführt.

Bei der Anmeldung eines Nutzers als Vertreter oder bei der Anmeldung des Versicherten bei seinem alten Aktensystem während des Anbieterwechsels erfolgt das Login immer explizit. Dabei unterstützt das ePA-Frontend des Versicherten den Benutzer bei der Auswahl des Aktensystems des zu VertretenenDas ePA-Frontend des Versicherten unterstützt den Vertreter bei der Auswahl des Aktensystems.

A_13695-0324746 - ePA-Frontend des Versicherten: Login Aktensession

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 1.1 - Login durch einen Versicherten" aus [gemSysL_ePA] gemäß TAB_FdV_123 umsetzen.

Tabelle 30: TAB_FdV_123 – Login Aktensession

[<=]

Abbildung 5: Aktivitätsdiagramm "Login Aktensession"

A_15340-01 - ePA-Frontend des Versicherten: Login - Session-Daten für RecordIdentifier prüfenUser - Auswahl Aktensystem für Vertreter

Das ePA-Frontend des Versicherten MUSS denim Anwendungsfall "Login Aktensession" ohne Fehler abbrechen, wenn gültige Session-Daten zu dem RecordIdentifier vorliegen. [<=]

Gültige Session-Daten liegen vor, wenn die Session-Daten einen Authentisierungstoken und einen Autorisierungstoken beinhalten. Auf eine Prüfung der zeitlichen Gültigkeit der Token wird verzichtet, da eine Synchronität der Systemzeit in der Ablaufumgebung des ePA-FdV mit der den Token ausstellenden Komponente nicht sichergestellt werden kann. Antwortet das ePA-Aktensystem auf einen Operationsaufruf mit dem Fehler, dass ein Token ungültig ist, dann löscht das ePA-FdV die Token aus den Session-Daten (siehe A_15310-01). 

A_15341-01 - ePA-Frontend des Versicherten: Login - Einlesen der Karte

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession", wenn die Authentisierung mittels eGK erfolgt, die Aktivität "Einlesen der Karte" gemäß TAB_FdV_124 umsetzen.

Tabelle 31: TAB_FdV_124 – Login - Einlesen der Karte

* für eGK G2 das RSA-Zertifikat (R2048) und für eGK einer höheren Generation (bspw. G2.1) das ECC-Zertifikat (E256) [<=]

A_15342 - ePA-Frontend des Versicherten: Login - Abbruch bei Karte lesen

Das ePA-Frontend des Versicherten MUSS, wenn der Anwendungsfall "Login Aktensession" aufgrund der Prüfungen beim Einlesen der Karte abbricht, den Nutzer darauf hinweisen, seine aktuell gültige eGK zu stecken.  [<=]

Authentisieren und Autorisieren

A_15343-01 - ePA-Frontend des Versicherten: Login - Authentisieren des Nutzers

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" die übergreifende Aktivität "Authentisieren des Nutzers" ausführen. [<=]

Während der Entschlüsselung des Akten-und Kontextschlüssels werden Zertifikate der TI geprüft. Zuvor ist die Aktualität des Vertrauensraumes der TI sicher zu stellen. Siehe "".

A_15344-01 - ePA-Frontend des Versicherten: Login - Autorisieren des Nutzers - Schlüsselmaterial aus ePA-Aktensystem laden

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" zum Autorisieren des Nutzers die übergreifende Aktivität "Schlüsselmaterial aus ePA-Aktensystem laden" ausführen. Wenn die Aktivität die Informationen AuthenticationAssertion, AuthorizationAssertion, RecordKey (Aktenschlüssel) oder ContextKey (Kontextschlüssel) liefert, dann werden diese in die Session-Daten übernommen. [<=]

Aktivieren und Migration

Wenn die Autorisierung eine AuthorizationAssertion aber kein AuthorizationKey liefert, dann ist das Aktenkonto des Versicherten noch nicht aktiviert. Das Aktivieren kann über die Anwendungsfälle "Aktenkonto aktivieren" oder "Anbieter wechseln" erfolgen.

Der Status des Aktenkontos (RecordState) lässt sich aus dem Autorisierungstoken Attribut Assertion/AttributeStatement/Attribute mit dem Namen "Zustand des Kontos" ermitteln. Die Information wird in die Session-Daten übernommen.

A_15346-01 - ePA-Frontend des Versicherten: Login - Autorisieren des Nutzers - Aktenkontostatus REGISTERED

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" den Aktenzustand aus dem Autorisierungstoken ermitteln und bei RecordState = REGISTERED den Anwendungsfall ohne Fehler abbrechen und den Anwendungsfall "Aktenkonto aktivieren" startenUser" einen Vertreter dabei unterstützen, das Aktensystem unter Verwendung der vom Aktensystem bereitgestellten Operation gemäß A_24801* auszuwählen.
[<=]

A_15340-02 - ePA-Frontend des Versicherten: Login - Session-Daten für Nutzer prüfen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Login User" ohne Fehler abbrechen, wenn bereits gültige Session-Daten zu dem Nutzer vorliegen. [<=]

A_1568115343-02 - ePA-Frontend des Versicherten: Login - AutorisierenAuthentisieren des Nutzers - Aktenkontostatus REGISTERED_FOR_MIGRATION

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" den Aktenzustand aus dem Autorisierungstoken prüfen und bei RecordState = REGISTERED_FOR_MIGRATION nur die Operation I_Account_Management_Insurant::ResumeAccount zum Import des Pakets mit den Daten aus der Akte des Versicherten beim alten Anbieter ermöglichen, alle anderen Anwendungsfällen sind mit einem Fehler abzubrechen. [<=]

Dem Nutzer soll im Falle dieses Abbruchs ein Hinweis gegeben werden, dass vor der Nutzung des Aktenkontos beim neuen Anbieter eine Migration der Daten aus dem Aktenkonto des alten Anbieters durchgeführt werden muss.

Verbindung zur Dokumentenverwaltung

Für die Aktivität "Aktenkonto öffnen" wird zuerst ein sicherer Kanal auf Inhaltsebene zwischen dem ePA-FdV und der VAU der Dokumentenverwaltung aufgebaut. Dafür wird die Schnittstelle I_Document_Management_Connect der Komponente Dokumentenverwaltung genutzt (siehe auch ).

A_15347-01 - ePA-Frontend des Versicherten: Login - Aktenkontext öffnen - Aufbau sicherer Kanal zu Dokumentenverwaltung

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" in der Aktivität "Aktenkontext öffnen" für die Schnittstellen zur Komponente Dokumentenverwaltung das Kommunikationsprotokoll gemäß den Vorgaben aus  und  umsetzen.

[<=]

A_15600-01 - ePA-Frontend des Versicherten: Login - Aktenkontext öffnen - Erweiterung des sicheren Verbindungsprotokolls

Das ePA-Frontend des Versicherten MUSS beim Aufbau des sicheren Kanals zur Dokumentenverwaltung die AuthorizationAssertion aus den Session-Daten der vom ePA-Frontend des Versicherten aufgerufenen Operation als Parameter gemäß [gemSpec_Dokumentenverwaltung#A_15592-*] übergeben. [<=]

Das ePA-FdV nutzt den abgeleiteten Sitzungsschlüssel, um alle fachlichen Eingangs- und Ausgangsnachrichten zur Dokumentenverwaltung zu ver- bzw. entschlüsseln. Siehe A_15304-01.

A_15348-01 - ePA-Frontend des Versicherten: Login - Aktenkontext öffnen - Operation OpenContext

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login Aktensession" in der Aktivität "Aktenkontext öffnen" das Übersenden des Kontextschlüssels gemäß TAB_FdV_126 umsetzen.

Tabelle 32: TAB_FdV_126 – Login - Aktenkontext öffnen - Operation OpenContext

User" die übergreifende Aktivität "Authentisieren des Nutzers" ausführen. [<=]

Benachrichtigungen

Die Anzeige von Benachrichtigungen im Anwendungsfall "Login AktensessionUser" ist optional gemäß den Konfigurationsdaten. Wird das Login nicht explizit mit dem Start des FdV ausgeführt, sondern erst bei Ausführung eines Anwendungsfalls mit Zugriff auf das ePA-Aktensystem, dann muss der Nutzer zuerst bestätigen, ob die Benachrichtigungen innerhalb des aufgerufenen Anwendungsfalls angezeigt werden sollen.

A_15350 - ePA-Frontend des Versicherten: Login - Benachrichtigungen anzeigen optional

Das ePA-Frontend des Versicherten MUSS, wenn die Konfiguration Benachrichtigungen aktivieren = nein gesetzt ist, die Aktivitäten zum Anzeigen von Benachrichtigungen ignorieren. [<=]

A_15351 - ePA-Frontend des Versicherten: Login - Benachrichtigungen anzeigen unterdrücken

Das ePA-Frontend des Versicherten MUSS, wenn die Konfiguration Benachrichtigungen aktivieren = ja gesetzt ist und der Anwendungsfall "Login Aktensession" nicht zum Start des FdV durchgeführt wird, sondern implizit durch einen anderen Anwendungsfall getriggert wird, beim Nutzer abfragen, ob die Benachrichtigungen angezeigt werden sollen. [<=]

A_15352-02 - ePA-Frontend des Versicherten: Login - Protokolldaten Dokumentenverwaltung15352-03 - ePA-Frontend des Versicherten: Login - Protokolldaten abfragen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login AktensessionUser", wenn die Konfiguration Benachrichtigungen aktivieren = ja gesetzt ist, die Protokolldaten der Komponente Dokumentenverwaltung gemäß A_15485-*des ePA-Aktensystems abfragen und das Ergebnis gemäß der Konfiguration Benachrichtigungszeitraum filtern. Falls gemäß A_15354-* noch kein Wert "Letzte Anmeldung zum Aktenkonto" vorliegt, ist es ausreichend, wenn die Protokolldaten für den Zeitraum der letzten 30 Tage abgefragt werden. Der Versicherte MUSS dann über eine Einschränkung der Protokolldaten informiert werden.
 [<=]

A_15353-01 - ePA-Frontend des Versicherten: Login - Benachrichtigungen-Anzeige

Das ePA-Frontend des Versicherten MUSS eine Anzeige für Benachrichtigungen umsetztenumsetzen, in der die Protokolleinträge für folgende Zugriffe übersichtlich dargestellt werden:

•   Folgende Anwendungsfälle aus dem § 291a-konformen Zugriffsprotokoll der Dokumentenverwaltung

• Dokumente einstellen aus der ärztlichen LEI-Umgebung
• Dokumente löschen aus der ärztlichen LEI-Umgebung
• Dokumente einstellen aus der privaten Umgebung
• Dokumente löschen aus der privaten Umgebung

[<=]

Es gilt die folgende Anforderung aus dem Anwendungsfall "Protokolldaten einsehen" für die Darstellung der Benachrichtigung: "".

A_15354-01 - ePA-Frontend des Versicherten: Konfiguration letzte Anmeldung

Das ePA-Frontend des Versicherten MUSS nach erfolgreichem Login den Wert "Letzte Anmeldung zum Aktenkonto" für das Aktenkonto in den Konfigurationsdaten aktualisieren. [<=]

6.2.4.2 Logout AktensessionUser

Dieser Anwendungsfall beendet eine Aktensession.

A_15355-01 - ePA-Frontend des Versicherten: Logout Aktensession

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 1.3 - Logout durch einen Nutzer" aus [gemSysL_ePA] gemäß TAB_FdV_127 umsetzen.

Tabelle 33: TAB_FdV_127 – Logout Aktensession

[<=]

A_15356-01 - ePA-Frontend des Versicherten: Logout - Aktenkontext schließen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Logout Aktensession", wenn ein sicherer Kanal zur Dokumentenverwaltung aufgebaut und der Aktenkontext erfolgreich geöffnet wurde, die Aktivität "Aktenkontext schließen" gemäß TAB_FdV_128 umsetzen.

Tabelle 34: TAB_FdV_128 – Logout - Aktenkontext schließen

[<=]

A_17542-01 - ePA-Frontend des Versicherten: Logout - Authentisierungstoken abmeldenUser Session und verwirft die für den sicheren Kanal zur Aktenkontoverwaltung ausgehandelten VAU-Schlüssel.

A_24759 - ePA-Frontend des Versicherten: Logout User

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Logout Aktensession", wenn ein Authentisierungstoken in den Session-Daten gespeichert ist, die Aktivität "Authentisierungstoken abmelden" gemäß TAB_FdV_172 umsetzen.

Tabelle 35: TAB_FdV_172 – Logout - Authentisierungstoken abmelden

[<=]

A_17766-01 - ePA-Frontend des Versicherten: Logout - Freischaltung des Signaturdienstes beenden

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Logout Aktensession", wenn für die Authentisierung eine alternative kryptographische Versichertenidentität genutzt wurde und die Schnittstelle I_Remote_Sign_Operations::sign_Data freigeschaltet wurde, den Signaturdienst aufrufen, um eine Freischaltung des Signaturdienstes für den Nutzer zu beenden. [<=]

Eine Beschreibung der signaturdienstspezifischen Schnittstelle für diese Operation ist in [vesta].

A_15358-01User" die Operation Logout gemäß [I_Authorization_Service] aufrufen.
[<=]

A_15358-02 - ePA-Frontend des Versicherten: Logout - Session-Daten löschen

Das ePA-Frontend des Versicherten MUSS zum Abschluss des Anwendungsfall "Logout AktensessionUser" alle Session-Daten aus dem lokalen Speicher löschen. [<=]

DieHinweis: Zu den Session-Daten sind in "" beschriebengehören z. B. die geheimen Schlüssel für ein SSO oder für den VAU-Kanal.

6.2.5 Aktenkontoverwaltung

6.2.5.1 Aktenkonto aktivieren

Der Anwendungsfall "Aktenkonto aktivieren" wird automatisch gestartet, wenn sich beim Login nach der Autorisierung ergibt, dass das Aktenkonto den Status "REGISTERED" hat.

Der Anwendungsfall kann in der GUI auswählbar sein. Dann ist vorab der Anwendungsfall "Login Aktensession" auszuführen.

A_15359 - ePA-Frontend des Versicherten: Aktenkonto aktivieren über GUI

Das ePA-Frontend des Versicherten MUSS, wenn der Versicherte den Anwendungsfall "Aktenkonto aktivieren" über die GUI auswählt, den Anwendungsfall "Login Aktensession" starten. [<=]

Im Rahmen des Login wird eine Authentisierung und Autorisierung des Nutzers durchgeführt.

A_15360-01 - ePA-Frontend des Versicherten: Aktenkonto aktivieren

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 2.1 - Aktenkonto einrichten" aus [gemSysL_ePA] gemäß TAB_FdV_130 umsetzen.

Tabelle 36: TAB_FdV_130 – Aktenkonto aktivieren

[<=]

A_15362-01 - ePA-Frontend des Versicherten: Aktenkonto aktivieren - Aktenschlüssel erzeugen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Aktenkonto aktivieren" den Aktenschlüssel erzeugen. [<=]

A_15363-01 - ePA-Frontend des Versicherten: Aktenkonto aktivieren - Kontextschlüssel erzeugen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Aktenkonto aktivieren" den Kontextschlüssel erzeugen. [<=]

Für das Erzeugen von Schlüsseln ist  und zu beachten.

A_15364-01 - ePA-Frontend des Versicherten: Aktenkonto aktivieren - AuthorizationKey erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Aktenkonto aktivieren" einen AuthorizationKey mit

•   den erzeugten Aktenschlüssel und Kontextschlüssel,

•   dem Namen und der Versicherten-ID aus dem Authentisierungszertifikat

•   sowie AuthorizationType = DOCUMENT_AUTHORIZATION

für den Versicherten erstellen. [<=]

A_15365-01 - ePA-Frontend des Versicherten: Aktenkonto aktivieren - Schlüsselmaterial im ePA-Aktensystem speichern

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Aktenkonto aktivieren" für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem Eingangsparameter AuthorizationKey = erstellter AuthorizationKey ausführen. Der optionale Parameter NotificationInfoRepresentative wird nicht belegt. [<=]

Nach erfolgreichem Aufruf dieser Operation hat das Aktenkonto den Status aktiviert. Die folgenden Aktivitäten ermöglichen, dass der Nutzer ohne erneutes Login fachliche Anwendungsfälle (bspw. Berechtigung vergeben, Dokument einstellen) mit dem Aktenkonto ausführen kann.

Das Laden des Schlüsselmaterial aus ePA-Aktensystem laden erfolgt gemäß A_15344-01.

Das Öffnen des Aktenkontext erfolgt gemäß A_15347-01 und A_15348-01.

6.2.5.2 Anbieter wechseln

Ein Versicherter kann mit diesem Anwendungsfall den Anbieter seines Aktenkontos wechseln und alle Inhalte zu einem neuen Anbieter übertragen. Hierfür sind mehrere Aktionen durch den Versicherten durchzuführen.

•   Kündigung des bestehenden Aktenkontos beim alten Anbieter

•   Registrierung eines neuen Aktenkontos bei einem neuen Anbieter

•   Bestätigung vom neuen Anbieter erhalten, dass das neue Aktenkonto zur Datenübernahme vorbereitet ist

•   Übernahme der Daten vom Aktenkonto des alten Anbieters zum neuen Anbieter im FdV

A_21545 - ePA-Frontend des Versicherten: Anbieter wechseln - Steuerung des Wechsels über das FdV des neuen Anbieters

Die Steuerung des Anbieterwechsels MUSS über das FdV des neuen Anbieters erfolgen. [<=]

A_15369-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Hinweis Verwaltungsprotokoll

Das ePA-Frontend des Versicherten MUSS vor Start des Anwendungsfalls "Anbieter wechseln" den Versicherten darauf hinweisen, dass das Verwaltungsprotokoll nicht zum neuen Anbieter übertragen wird, der Versicherte sich das Verwaltungsprotokoll lokal speichern muss, falls es weiterhin verfügbar sein soll. Der Versicherte MUSS auf die Möglichkeit des signierten Exports der Protokolle hingewiesen werden.
[<=]

A_15371-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Informationen zum anderen am Wechsel beteiligten Anbieter

Das ePA-Frontend des Versicherten MUSS dem Versicherten ermöglichen, die folgenden Registrierungsinformationen des anderen am Wechsel beteiligten Anbieters zu erfassen bzw. auszuwählen:

•   Akten-ID

•   FQDN des Anbieter

Das FdV kann die Operation I_Authorization_Management_Insurant::getRecordProviderList nutzen, um dem Versicherten die Auswahl des abgebenden Aktensystems zu ermöglichen. Alternativ kann das FdV auch eine optionale Schnittstelle des ePA-Aktensystems zur Ermittlung des FQDN des abgebenden Aktensystems entsprechendgemSpec_Aktensystem#A_21740-* nutzen.
[<=]

A_15372-02 - PA-Frontend des Versicherten: Anbieter wechseln - Zugriffsberechtigungen anzeigen und Umzug bestätigen

Das ePA-Frontend des Versicherten MUSS dem Versicherten die zugriffsberechtigten Leistungserbringerinstitutionen und Vertreter aus dem ePA-Aktensystem des alten Anbieters anzeigen und dem Versicherten die Möglichkeit geben, zu entscheiden, welche der bestehenden Berechtigungen in das ePA-Aktensystem des neuen Anbieters übernommen werden sollen. [<=]

Die Anzeige der zugriffsberechtigten LEIs und, Vertreter erfolgt mittels Anwendungsfall "Vergebene Berechtigungen anzeigen". Das Ergebnis der Operation I_Authorization_Management_Insurant::getAuthorizationList wird im weiteren Verlauf für die Einrichtung der Berechtigungen im neuen Aktenkonto genutzt.

A_15370-02 - ePA-Frontend des Versicherten: Anbieter wechseln

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 2.5 - Anbieter wechseln" aus [gemSysL_ePA] gemäß TAB_FdV_131 umsetzen.
 

Tabelle 37: TAB_FdV_131 – Anbieter wechseln

[<=]

Abbildung 6: Aktivitätsdiagramm "Anbieter wechseln"

A_15377-02 - ePA-Frontend des Versicherten: Anbieter wechseln - Aktenkonto in Exportzustand versetzen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln" die Aktivität "Aktenkonto in Exportzustand versetzen" gemäß TAB_FdV_132 umsetzen.

Tabelle 38: TAB_FdV_132 – Anbieter wechseln - Aktenkonto in Exportzustand versetzen

[<=]

Nachdem das Aktenkonto den Zustand SUSPENDED ("bereit für Anbieterwechsel") erhalten hat, kann der Versicherte oder ein berechtigter Nutzer nicht mehr auf das Aktenkonto zugreifen.

A_15378-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Login neues Aktenkonto

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln" die folgenden Aktivitäten aus dem Anwendungsfall "Login Aktensession" mit den Daten des Aktenkontos beim neuen Anbieter ausführen, um sich beim neuen Aktenkonto einzuloggen:

•   Authentisieren des Nutzers

•   Autorisieren des Nutzers

•   Sicheren Kanal zur Dokumentenverwaltung aufbauen

•   Aktenkontext öffnen

[<=]

Das Authentisieren des Nutzers erfolgt mittels der übergreifenden Aktivität "Authentisieren des Nutzers".

Die Autorisierung des Nutzers erfolgt gemäß A_15344-01. Die Operation getAuthorizationKeys liefert ein Autorisierungstoken mit RecordState = REGISTERED_FOR_MIGRATION und kein Schlüsselmaterial.

Der Aufbau des sicheren Kanals zur Dokumentenverwaltung erfolgt gemäß A_15347-*.

Das Öffnen des Aktenkontextes erfolgt gemäß A_15348-01  unter Nutzung des Autorisierungstoken mit RecordState = REGISTERED_FOR_MIGRATION und dem Kontextschlüssel des Aktenkontos des alten Anbieters.

A_21839 - ePA-Frontend des Versicherten: ENC-VAU-Zertifikat des Betreibers für Anbieterwechsel

Das ePA-Frontend des Versicherten MUSS das ENC-VAU-Zertifikat des Betreibers im UseCase Anbieterwechsel verfügbar machen. [<=]

Hinweis: Das ENC-VAU-Zertifikat des Betreibers darf im ePA-FdV persistent gespeichert werden.

A_15374-01 - ePA-Frontend des Versicherten: Anbieter wechseln - AuthorizationKey für Aktenkontoinhaber erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln" einen AuthorizationKey mit dem für den Versicherten gesicherten Aktenschlüssel und Kontextschlüssel sowie AuthorizationType = DOCUMENT_AUTHORIZATION für den Versicherten erstellen. [<=]

A_15375-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Schlüsselmaterial für Aktenkontoinhaber im ePA-Aktensystem speichern

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln" für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem des neuen Anbieters die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem Eingangsparameter AuthorizationKey = erstellter AuthorizationKey ausführen. Der optionale Parameter NotificationInfoRepresentative wird nicht belegt. [<=]

Die bestehenden Berechtigungen werden in das ePA-Aktensystem des neuen Anbieters übernommen.

A_15598-02 - ePA-Frontend des Versicherten: Anbieter wechseln - Berechtigung LEI erteilen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln", wenn die Berechtigungen in das Aktenkonto des neuen Anbieters übernommen werden sollen, für jede aus dem Aktenkonto des alten Anbieters ermittelte Berechtigung einer LEI einen AuthorizationKey erstellen und das Schlüsselmaterial in das ePA-Aktensystem des neuen Anbieters laden.  [<=]

A_22669 - ePA-Frontend des Versicherten: Anbieter wechseln - Berechtigung DiGA erteilen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln", wenn die Berechtigungen in das Aktenkonto des neuen Anbieters übernommen werden sollen, für jede aus dem Aktenkonto des alten Anbieters ermittelte Berechtigung einer DiGA einen AuthorizationKey erstellen und das Schlüsselmaterial in das ePA-Aktensystem des neuen Anbieters laden. [<=]

Die Berechtigung für einen Vertreter kann nur übernommen werden, wenn dem Versicherten die E-Mailadresse des Vertreters für die Geräteautorisierung bekannt ist. Hierbei wird davon ausgegangen, dass es sich bei dem Vertreter um eine Vertrauensperson handelt und der Versicherte die Daten kennen könnte. Anderenfalls kann die Berechtigung für den Vertreter nicht übernommen werden und muss mittels dem Anwendungsfall "Vertretung einrichten" zusammen mit dem Vertreter neu eingerichtet werden.

A_15635-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Benachrichtigungsadresse Vertreter erfassen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer im Anwendungsfall "Anbieter wechseln" ermöglichen, bei der Übernahme der Berechtigungen in das Aktenkonto des neuen Anbieters für jeden Vertreter die Benachrichtigungsadresse für die Geräteautorisierung zu erfassen. Dabei MUSS die bestehende Benachrichtigungsadresse jedes Verteters mittels GetNotificationInfo ermittelt werden, um sie dem Versicherten zur Übernahme anzubieten. [<=]

A_15636-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Berechtigung Vertreter erteilen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall „Anbieter wechseln“, wenn die Berechtigungen in das Aktenkonto des neuen Anbieters übernommen werden sollen und die Benachrichtigungsadresse des Vertreters für die Geräteautorisierung bekannt ist, für jede aus dem Aktenkonto des alten Anbieters heruntergeladene Berechtigung eines Vertreters das Schlüsselmaterial in das ePA-Aktensystem laden. [<=]

Das Hochladen des Schlüsselmaterials in das ePA-Aktensystem erfolgt mit der übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem EingangsparameterAuthorizationKey = erstellter AuthorizationKey. Der optionale Parameter NotificationInfoRepresentative wird für LEI, DiGA und KTR nicht belegt.

Die Information, welche Geräte durch Nutzer autorisiert sind, wird nicht übertragen. D.h. der Nutzer muss bei der nächsten Anmeldung am Aktenkonto des neuen Anbieters sein GdV autorisieren.

A_15379-01 - ePA-Frontend des Versicherten: Anbieter wechseln - Aktenkonto fortführen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Anbieter wechseln" die Aktivität "Aktenkonto fortführen" gemäß TAB_FdV_133 beim Aktenkonto des neuen Anbieters umsetzen.

Tabelle 39: TAB_FdV_133 – Anbieter wechseln - Aktenkonto fortführen

[<=]

Der Vorgang des Anbieterwechsels erfolgt aktensystemseitig asynchron, d. h. die Operation ist aus Sicht des FdV nach kurzer Zeit abgeschlossen, läuft im Backend jedoch weiter. Der Nutzer ist darauf hinzuweisen, dass er Zugriff auf sein Aktenkonto erst nach Abschluss der Datenmigration erhalten kann und dass diese länger dauern kann.

6.2.5.3 Schließen einer AkteDer Widerspruch bzw. die Rücknahme des Widerspruchs in die grundsätzliche Nutzung der ePA und die Übertragung von Abrechnungsdokumenten in die ePA durch den Kostenträger werden durch den Kostenträger verwaltet und werden nicht über das hier dargestellte Widerspruchsmanagement der ePA verwaltet.

Der Versicherte hat jederzeit das Recht, seine ePA endgültig zu schließen.

A_21128 - Hinweis im FdV zur selbstständigen Sicherung der Protokolle bei Schließen der Akte

Falls das ePA-FdV dem Nutzer eine Funktion zum Schließen seiner Akte anbietet, MUSS das eA-FdV beim Schließen einer Akte über das ePA-FdV den Versicherten darauf hinweisen, seine Protokolldaten aus der Akte für eine weitere Verwendung selbstständig zu exportieren, da diese nach Schließen der Akte im Aktensystem nur noch eingeschränkt und nicht mehr vollständig für datenschutzrechtliche Auskünfte zur Verfügung stehen. Der Versicherte MUSS auf die Möglichkeit des signierten Exports der Protokolle hingewiesen werden. [<=]

A_21129-01 - Revisionssicherer Export der Protokolle

Das ePA-FdV MUSS dem Nutzer eine Funktion zum Export signierter Protokolldaten aus der Akte unter Nutzung der Operationen I_Authentication_Insurant::getSignedAuditEvents (nur wenn der Nutzer der Kontoinhaber ist), I_Authorization_Management_Insurant:: getSignedAuditEvents und I_Account_Management_Insurant::getSignedAuditEventsOperation get gemäß [I_Audit_Event_Render_Insurant] bereitstellen. [<=]

6.2.6 Umschlüsselung5.1 Widersprüche für Funktionen der ePA verwalten

Dieses Kapitel beschreibt den Anwendungsfall Umschlüsselung. In den folgenden Abbildungen ist in einem Sequenzdiagramm der Ablauf der Umschlüsselung mit den einzelnen Akteuren ePA-FdV, Autorisierung, Dokumentenverwaltung und SGD1/2 dargestellt. Grün eingefärbte Pfeile bezeichnen signierte Rückgabewerte. Die Signaturen werden bei der Weiterleitung der Rückgabewerte mit an den Empfänger geleitet. Dieser validiert nach Empfang des Wertes und der Signatur diese auf Gültigkeit und darauf, dass der Signaturerstellungszeitpunkt nicht zu weit in der Vergangenheit liegt.

Abbildung 7: Umschlüsselung I

 

Abbildung 8: Umschlüsselung II

 

Abbildung 9: Umschlüsselung III

Abbildung 10: Umschlüsselung IV

A_20507-01 - ePA-Frontend des Versicherten: Funktions-Timeout für Aufrufe an die Dokumentenverwaltung, die Autorisierungskomponente und die Schlüsselgenerierungsdienste SGD1 und SGD2

Das ePA-Frontend des Versicherten MUSS während der Umschlüsselung bei allen Funktionsaufrufen an die Dokumentenverwaltung, die Autorisierungskomponente und die Schlüsselgenerierungsdienste nach Ablaufen der Timeout-Zeit von mindestens 60 Minuten die Umschlüsselung abbrechen und die Methode finishKeyChange(FALSE) bei der Komponente Dokumentenverwaltung aufrufen.  [<=]

Wenn das Frontend des Versicherten auf einem Smartphone läuft, dann kann es durchaus die Verbindung in einem Funkloch verlieren und nach kurzer Zeit wieder herstellen. Weiterhin kann es sein, dass das Smartphone sich wegen erschöpften Akkumulators abschaltet und der Nutzer es innerhalb kurzer Zeit an das Ladegerät anschließt und die Umschlüsselung fortsetzen möchte. Diese Verbindungsabbrüche sollen nicht zum Abbrechen des Umschlüsselungsprozesses  führenDas Consent Management des ePA-Aktensystems verwaltet den Zustand der erteilten oder nicht erteilten Widersprüche des Versicherten oder eines Vertreters gegen oder für die Nutzung widerspruchsfähiger Funktionen der ePA.

Die Liste der widerspruchsfähigen Funktionen ist in A_23874* [gemSpec_Aktensystem_ePAfuerAlle] definiert.

Über das Frontend des Versicherten kann der aktuelle Zustand der Widersprüche eingesehen oder geändert werden. Der initiale Zustand nach Aktivierung eines Aktenkontos ist "kein Widerspruch erteilt" für alle Funktionen.

Eine Änderung eines Zustands führt dazu, dass die betroffene Funktion entweder nicht mehr durch Akteure der ePA ausgeführt wird ("Widerspruch erteilt") oder aber ausgeführt wird ("kein Widerspruch erteilt"). Ein Zustand kann dabei jederzeit durch einen Versicherten oder einen Vertreter geändert werden.

Ein erteilter Widerspruch kann, abhängig von der betroffenen Funktion, dazu führen, dass beispielsweise bereits hinterlegte Dokumente gelöscht bzw. keine Dokumente mit Bezug zu dieser Funktion neu in das Aktenkonto eingestellt werden.

Für eine fundierte Entscheidung des Versicherten oder eines Vertreters für oder gegen die Nutzung einer widerspruchsfähigen Funktion der ePA ist die Bereitstellung geeigneter Informationen erforderlich. Diese Information muss durch den Versicherten oder einen Vertreter auch nach der Änderung eines Widerspruchs einsehbar sein.

A_20725-0124056 - ePA-Frontend des Versicherten: Abbruch der Umschlüsselung durch den VersichertenFdV: Information des Nutzers über Möglichkeit des Widerspruchs in Funktionen der ePA

Das ePA-Frontend des Versicherten MUSS während der Umschlüsselung dem Nutzer anbieten, die Umschlüsselung abzubrechen. Wenn der Nutzer die Umschlüsselung abbricht, dann sendet das FdV die Nachricht finishKeyChange(FALSE) an die Dokumentenverwaltung. Die Dokumentenverwaltung ihrerseits sendet dann die Nachricht finishKeyChange(FALSE) an die Komponente Autorisierung. einen Versicherten bei der ersten Nutzung eines neu angelegten Aktenkontos oder bei der ersten Nutzung eines migrierten ePA-2.x Aktenkontos über den aktuellen Zustand der Widersprüche in die widerspruchsfähigen Funktionen der ePA und seine Möglichkeit einer Änderung dieser umfassend informieren. [<=]

Die Komponenten Autorisierung und Dokumentenverwaltung führen nach Erhalt der Nachricht finishKeyChange(FALSE) die Methode Rollback() durch und stellen den Zustand von vor der Umschlüsselung wieder her.

A_20723 - ePA-Frontend des Versicherten: Anzeige des Aktenzustandes KEY_CHANGE

Das ePA-Frontend des Versicherten MUSS während der Umschlüsselung an der Oberfläche dem Nutzer anzeigen, dass die Akte im Zustand "KEY_CHANGE" ist. [<=]

A_20724 - ePA-Frontend des Versicherten: Verhindern aller sonstigen Aktivitäten während der Umschlüsselung

Das ePA-Frontend des Versicherten SOLL während der Umschlüsselung alle Aktivitäten verhindern, die nicht zum Umschlüsselungsprozess gehören. [<=]

Das Aktensystem lehnt im Zustand KEY_CHANGE alle sonstigen Aktivitäten vom FdV ab, daher sollte das FdV dem Benutzer auch keine weiteren Aktivitäten anbieten.

A_20479-06 - ePA-Frontend des Versicherten: Umschlüsselung durchführen

Das Frontend des Versicherten muss den Anwendungsfall "Umschlüsselung" für den Versicherten umsetzen.
 

[<=]

6.2.7 Berechtigungsverwaltung

Dieses Kapitel beschreibt Anwendungsfälle zur Vergabe und Administration von Berechtigungen zum Zugriff auf das Aktenkonto.

Im FdV können nur Berechtigungen an LEI und DiGA vergeben werden, die im Verzeichnisdienst (VZD) der TI registriert sind.

Die zulässigen Berechtigungsvergaben für die verschiedenen Leistungserbringerinstitutionen, Kostenträger, DiGA und Vertreter werden vom Aktensystem durchgesetzt. Das ePA-Frontend des Versicherten kann die grundsätzlich gesetzlich möglichen Berechtigungsvergaben nicht erweitern, sondern nur weiter einschränkenA_23870 - ePA-FdV: Information des Nutzers über die Auswirkungen bei Änderungen von Widersprüchen

Das ePA-Frontend des Versicherten MUSS einen Nutzer über die Auswirkungen eines Widerspruchs gegen oder einer Einwilligung in die Nutzung einzelner widerspruchsfähiger Funktionen der ePA umfassend informieren, so dass auch ein nicht technisch vorgebildeter Nutzer eine fundierte Entscheidung über die Teilnahme oder Nicht-Teilnahme an einer Funktionen treffen kann. [<=]

Einige Funktionen haben weitergehende Auswirkungen, die vor einem Widerspruch gegen die Nutzung der Funktionen berücksichtigt werden müssen (siehe dazu die Kapitel "Auswirkungen bei Widerspruch gegen Funktionen der ePA auf die Dokumente des Aktenkontos" in den Kapiteln "XDS Document Service" und "Medication Service"[gemSpec_Aktensystem_ePAfuerAlle]).

Der Nutzer hat die Möglichkeit, die Daten vor Erteilung eines Widerspruchs aus seiner Akte lokal zu speichern (siehe Dokument herunterladen).

Die Anzeige der widerspruchsfähigen Funktionen und deren aktueller Zustand (Widerspruch erklärt/nicht erklärt) erfolgt durch das FdV. Ein Nutzer des FdV kann die aktuelle Einstellung bei Bedarf ändern, also Widersprüche erklären oder zurücknehmen.
Dabei ist die umfassende Information eines Nutzers vor einer Änderungsausführung gemäß A_23870-* zu beachten.

A_1538223875 - ePA-Frontend des Versicherten: Bestätigung BerechtigungskonfigurationAnzeige der Widersprüche

Das ePA-Frontend des Versicherten MUSS, bevor es eine Berechtigung an eine LEI vergibt oder ändert, eine Bestätigung der gewählten Berechtigungskonfiguration vom Nutzer einholen dem Nutzer alle im Aktensystem hinterlegten Widersprüche unter Verwendung der Operation getConsentDecisions gemäß [I_Consent_Decision_Management] anzeigen. [<=]

Die Anzeige kann z.B. als Hilfetext vom Nutzer bei der Berechtigungsvergabe erreichbar sein.

A_15380A_23880 - ePA-Frontend des Versicherten: Suche Leistungserbringerinstitution in VerzeichnisdienstAnwendungsfall "Widerspruch für Funktionen der ePA ändern"

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine oder mehrere LEI im Verzeichnisdienst zu suchen und für die Vergabe von Berechtigungen auszuwählenWiderspruche für Funktionen der ePA gemäß A_23874 unabhängig voneinander zu erteilen bzw. zurückzunehmen unter Verwendung der Operation updateConsentDecision gemäß [I_Consent_Decision_Management]. [<=]

Für die Umsetzung der Suche siehe " ". 

A_20196-01 - ePA-Frontend des Versicherten: Anzeige der Berufsgruppe der Leistungserbringerinstitution bei der Berechtigungsvergabe

Das ePA-Frontend des Versicherten MUSS dem Nutzer die aus dem Zertifikat C.HCI.ENC aus  über die professionOID aus GS-A_4443-* ermittelte Berufsgruppe der Leistungserbringerinstitution bei der Berechtigungsvergabe anzeigen. [<=]6.2.5.2 Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI

Der Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI erfolgt über die Ombudsstelle des zuständigen Kostenträgers oder das ePA-Frontend des Versicherten. Dabei wird im Entitlement Management vermerkt, dass für die spezifische LEI keine Befugnisse registriert werden können.

A_20254-0125136 - ePA-Frontend des Versicherten: Anzeige der Dokumente, auf die in Abhängigkeit eines Policy Document eine Berechtigung wirktLEI - Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, sich die Dokumente (anhand der zurückgegeben UniqueIDs) anzeigen zu lassen, auf die eine konkrete Leistungserbringerinstitution des vorliegenden Policy Document berechtigt werden kann. Dazu MUSS ein Policy Document für eine aktensystemseitige Simulation hochgeladen werden können (vgl. A_21705)eine LEI im VZD-FHIR-Directory zu suchen und für die Erteilung eines Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI auszuwählen. [<=]

A_15383-0224410 - ePA-Frontend des Versicherten: Berechtigung an LEI für Aktenkonto vergebenErteilung eines Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.1 - Berechtigung durch einen Versicherten vergeben" aus [gemSysL_ePA] für jede LEI, für die eine Berechtigung vergeben werden soll, gemäß TAB_FdV_134 umsetzen.

Tabelle 40: TAB_FdV_134 – Berechtigung an LEI für Aktenkonto vergeben

es dem Nutzer ermöglichen, einen Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI zu erteilen unter Verwendung der Operation setBlockedUserPolicyAssignment gemäß [I_Entitlement_Management]. [<=]

A_20198-0224460 - ePA-Frontend des Versicherten: Anzeige der auf ein Dokument berechtigtenLöschen eines Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Anzeige der auf ein Dokument berechtigten LEI" gemäß TAB_FdV_178 umsetzen.

Tabelle 41: TAB_FdV_178 Anzeige der auf ein Dokument berechtigten LEI

es dem Nutzer ermöglichen, einen Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI zurückzunehmen unter Verwendung der Operation deleteBlockedUserPolicyAssignment gemäß [I_Entitlement_Management]. [<=]

A_20199-0124411 - ePA-Frontend des Versicherten: Ändern der Vertraulichkeitsstufe eines DokumentesAnzeigen von Widersprüchen gegen die Nutzung der ePA durch spezifische LEIs

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Ändern der Vertraulichkeitsstufe eines Dokumentes" gemäß TAB_FdV_179 umsetzen.

Tabelle 42: TAB_FdV_179: Ändern der Vertraulichkeitsstufe eines Dokumentes

[<=]

A_20201-01 - ePA-Frontend des Versicherten: Ändern der Zugriffsberechtigung einer LEI auf Dokumentenkategorien

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "Ändern der Zugriffsberechtigung einer LEI auf Dokumentenkategorien" gemäß TAB_FdV_180 umsetzen.

[<=]

A_19306 - ePA-Frontend des Versicherten: Berechtigung konform mit Zugriffsunterbindungsregeln

Das ePA-Frontend des Versicherten MUSS verhindern, dass Nutzer Berechtigungen erteilen, die der Tabelle [gemSpec_Dokumentenverwaltung#Tab_Dokv_030 - Zugriffsunterbindungsregeln] widersprechen. [<=]

A_15384-01 - ePA-Frontend des Versicherten: Berechtigung an LEI vergeben - AuthorizationKey erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an LEI für Aktenkonto vergeben" einen AuthorizationKey mit AuthorizationType = DOCUMENT_AUTHORIZATION und validTo entsprechend der vom Nutzer festgelegten Berechtigungsdauer für die zu berechtigende LEI erstellen. [<=]es dem Nutzer ermöglichen, die Liste der erteilten Widersprüche gegen die Nutzung der ePA durch spezifische LEIs unter Verwendung der Operation getBlockedUserPolicyAssignment gemäß [I_Entitlement_Management] anzuzeigen. [<=]

6.2.6 Befugnisverwaltung

Dieses Kapitel beschreibt Anwendungsfälle zur Vergabe und Administration von Befugnissen (Entitlements) zum Zugriff auf das Aktenkonto. Im ePA-Aktensystem wird die Verwaltung der Befugnisse im Entitlement Management realisiert.
Mit einer Befugnis befähigt der Versicherte einen Nutzer oder eine DiGA zur Verarbeitung seiner Daten. Es können nur Befugnisse für die in A_23941 aufgeführten Nutzer bzw. Nutzergruppen erteilt werden.

Ein Versicherter ist immer zum Zugriff auf sein Aktenkonto befugt.
Ein Vertreter ist nur befugt, wenn dies explizit durch den Versicherten für sein Aktenkonto vergeben wurde. 
Eine LEI ist nur befugt, wenn:

• dies explizit durch den Versicherten oder Vertreter für das Aktenkonto des Versicherten vergeben wurde, oder
• eine Behandlungssituation in der LEI vorlag und somit automatisch eine Befugnis für die Telematik-ID dieser LEI des zugehörigen Aktenkontos erstellt wurde.

Eine DiGA ist nur befugt, wenn:

• dies explizit durch den Versicherten oder Vertreter für sein Aktenkonto vergeben wurde

Im ePA-Frontend des Versicherten können nur Befugnisse an LEI oder DiGA vergeben werden, die im VZD-FHIR-Directory der TI registriert sind.

Die Prüfung des Zugriffs durch den Nutzer auf die Daten bzw. Dokumente des Aktenkontos erfolgt durch das ePA-Aktensystem.

A_15385-0123968 - ePA-Frontend des Versicherten: Berechtigung an LEI vergeben - Schlüsselmaterial im ePA-Aktensystem speichernBefugnisverwaltung am Aktensystem - Nutzung Schnittstelle

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an LEI für Aktenkonto vergeben" für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem Eingangsparameter AuthorizationKey = erstellter AuthorizationKey ausführen. Der optionale Parameter NotificationInfoRepresentative wird nicht belegtbeim Erstellen, Anzeigen, Ändern und Löschen von Befugnissen am ePA-Aktensystem die Operationen getEntitlement, getEntitlements, setEntitlement, deleteEntitlements der Schnittstelle I_Entitlement_Management gemäß [I_Entitlement_Management] verwenden. [<=]

A_15386-0124399 - ePA-Frontend des Versicherten: Berechtigung an LEI vergeben - Policy Document erstellenBefugnis signieren

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an LEI für Aktenkonto vergeben" ein Policy Document für den zu Berechtigenden entsprechend den für die Berechtigung ausgewählten Parametern erstellenbeim Erstellen und Ändern einer Befugnis diese Befugnis mit der Datenstruktur EntitlementRequestType für Vertreter und EntitlementRequestType für alle anderen Befugnisse gemäß [I_Entitlement_Management] erstellen und diese durch Aufruf der Schnittstelle I_Remote_Sign_Operations::sign_Data am Signaturdienst mit der Identität des Nutzers gemäß [gemSpec_SigD] signieren. [<=]

Für Informationen zu Policy Documents und deren Nutzungsvorgaben siehe "".

A_15387-01 - ePA-Frontend des Versicherten: Berechtigung an LEI vergeben - Policy Document hochladen6.2.6.1 Befugnisverwaltung für LEI

In diesem Kapitel werden die folgenden Anwendungsfälle umgesetzt:

•   "Befugnis für eine LEI erstellen"

•   "Befugnis für eine LEI ändern"

•   "Befugnis für eine LEI löschen"

A_23960 - ePA-Frontend des Versicherten: LEI - Befugnis verwalten

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung an LEI für Aktenkonto vergeben" zum Hochladen des Policy Documents in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für Policy Documents ausführenes dem Nutzer ermöglichen, eine Befugnis für eine LEI zu erstellen, zu ändern bzw. zu löschen. [<=]

A_23965 - ePA-Frontend des Versicherten: LEI - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine oder mehrere LEI im VZD-FHIR-Directory zu suchen und für die Vergabe der Befugnisse auszuwählen. [<=]

A_20066Für die Umsetzung der Suche siehe Aktivität 6.2.3.2 Leistungserbringerinstitution im Verzeichnisdienst der TI finden.

A_24549 - ePA-Frontend des Versicherten: Vom Aktensystem durchgesetzte Zugriffsrechte der LEI auf ein einzelnes Dokument anzeigenLEI - Berücksichtigung der Legal Policy bei Erstellen einer Befugnis

Das ePA-Frontend des Versicherten MUSS dem Nutzer anzeigen, in welcher Weise (z.B. nur Lesen, nur Schreiben, Lesen und Schreiben und Löschen) das Aktensystem für eine berechtigte LEI für ein konkretes Dokument den Zugriff ermöglicht. beim Erstellen einer Befugnis die Legal Policy aus [ ] beachten. Daraus folgt, dass dem Nutzer nur Leistungserbringerinstitutionen zur Auswahl angezeigt werden, die den erlaubten Berufsgruppen gemäß der Legal Policy entsprechen.
[<=]

Damit kann der Versicherte vor dem Besuch einer Leistungserbringerinstitution kontrollieren, auf welche Dokumente die Leistungserbringerinstitution lesenden bzw. löschenden Zugriff während der Behandlung hat.

A_20109-04A_20109-05 - ePA-Frontend des Versicherten: Konfiguration der zeitlichen Begrenzung der BerechtigungsdauerLEI - Konfiguration der Befugnisdauer

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die zeitliche Begrenzung für eine Leistungserbringerinstitution für die erteilte ZugriffsberechtigungBefugnis zu konfigurieren. Folgende Optionen MUSS das ePA-Frontend anbieten:

•   flexibles Enddatum

•   1 Tag (heutiges Datum)

•   7unbefristet

•   90 Tage [default] (heutiges Datum + 689 Kalendertage)

•   18 Monate
bzw. 3 Tage [default] (heutiges Datum + 18 Monate)

•   Unbefristet (31.12.99992 Kalendertage) bei Nutzergruppen gemäß § 342 Abs. 2 Nr. 1 lit. l SGB V.(siehe A_23941*)

[<=]

6.2.7.1 Spezifische Zugriffsregeln

Das Aktensystem setzt folgende Regeln um: Die kategorienbasierte Berechtigung in Form eines Policy Document berechtigt eine LEI abhängig von den Zugriffsunterbindungsregeln auch zum Einstellen eines Dokuments. Diese Autorisierung kann über Vertraulichkeitsstufen weiter eingeschränkt werden. Der lesende Zugriff auf Dokumente und Ordner kann weiterhin feingranular gewährt oder entzogen werden ("Allowlisting" und "Denylisting).

6.2.7.1.1 kategorienbasierte Berechtigung

Bei der kategorienbasierten Berechtigung wird der Zugriff auf die vorhandenen Dokumente der elektronischen Patientenakte in Dokumentenkategorien organisiert. Diese sind in der Spezifikation gemSpec_DM_ePA aufgeführt. Die Zuordnung eines einzelnen Dokumentes zu einer einzelnen Dokumentenart legt (mit Ausnahme der Dokumentenarten Dokumente des Versicherten, Dokumente einer DiGA und der Kostenträgerdokumente) die ePA-Dokumentenverwaltung fest. Alle Dokumente, die der Versicherte selbst einstellt, sind immer der Kategorie Dokumente des Versicherten zugeordnet.  Eine DiGA kann ausschließlich DiGA-Dokumente einstellen. Ein Kostenträger kann ausschließlich Kostenträgerdokumente einstellen.
Der Versicherte kann über das ePA-Frontend des Versicherten einer einzelnen Leistungserbringerinstitution den Zugriff auf einzelne Dokumentenkategorien erteilen oder entziehen.

A_19685-01 - ePA-Frontend des Versicherten: Anzeige der zugehörigen Dokumentenkategorie

Das ePA-Frontend des Versicherten MUSS dem Nutzer die dem Dokument zugeordnete Dokumentenkategorie, die in der gemSpec_DM_ePA in den Anforderungen A_14761-* und A_19388-* aufgeführt sind, anzeigen können.  [<=]

A_19686-02 - ePA-Frontend des Versicherten: Auswahl der Leistungserbringerinstitutionen in der kategorienbasierten Berechtigung

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, eine oder mehrere LEI, die über die Anforderung A_15380 gefunden wurden, den Zugriff auf eine oder mehrere Dokumentenkategorien zu ermöglichen. [<=]

A_19989-01 - ePA-Frontend des Versicherten: Ermittlung der ProfessionOID in der kategorienbasierten Berechtigung

Das ePA-Frontend des Versicherten MUSS bei der kategorienbasierten Berechtigung die ProfessionOID der Leistungserbringerinstitution aus dem Zertifikat C.HCI.ENC (Extension Admission) der Leistungserbringerinstitution ermitteln.
[<=]

A_19687-01 - ePA-Frontend des Versicherten: Berücksichtigung der Zugriffsunterbindungsregeln bei der Anzeige der Dokumentenkategorien

Das ePA-Frontend des Versicherten MUSS bei der kategorienbasierten Berechtigung die Zugriffsunterbindungsregeln aus [gemSpec_Dokumentenverwaltung#Tab_Dokv_030 - Zugriffsunterbindungsregeln] beachten. Daraus folgt, dass dem Nutzer für eine ausgewählte Leistungserbringerinstitution nur diejenigen Dokumentenkategorien angezeigt werden, für die diese tatsächlich berechtigt werden kann. [<=]

Wenn die Nutzerin des ePA-Frontend des Versicherten als Leistungserbringerinstitution eine Hebamme auswählt, dann hat diese weniger mögliche Zugriffsrechte als zum Beispiel ein Hausarzt. Das  ePA-Frontend des Versicherten darf dann für die Hebamme nur die nach [gemSpec_Dokumentenverwaltung#Tab_Dokv_030 - Zugriffsunterbindungsregeln] möglichen Berechtigungen anzeigen.

A_19690 - ePA-Frontend des Versicherten: Optische Kennzeichnung der Dokumentenkategorien

Das ePA-Frontend des Versicherten KANN dem Nutzer die zugeordnete Dokumentenkategorie eines Dokumentes durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe,Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen. [<=]

A_19691 - ePA-Frontend des Versicherten: Anzeige der für den LEI sichtbaren Dokumentenkategorien

Das ePA-Frontend des Versicherten MUSS dem Nutzer anzeigen, auf welche Dokumentenkategorien eine einzelne Leistungserbringerinstitution zugreifen darf.  [<=]

Damit kann der Nutzer vor dem Besuch einer Leistungserbringerinstitution sehen, welche Dokumentenkategorien der ePA bei der LEI sichtbar sind.

Ein Dokument kann sich in einer Dokumentenkategorie befinden, für die eine Leistungserbringerinstitution zugriffsberechtigt ist, über die dokumentenspezifische Berechtigung könnte der Leistungserbringerinstitution hingegen der Zugriff auf dieses Dokument entzogen worden sein. Im Resultat wird von der ePA-Dokumentenverwaltung durchgesetzt, dass diese Leistungserbringerinstitution keinen Zugriff auf das Dokument hat. 

A_19692 - ePA-Frontend des Versicherten: Anzeige der für den LEI geltenden Zugriffsregeln für die sichtbaren Dokumentenkategorien

Das ePA-Frontend des Versicherten MUSS dem Nutzer anzeigen, welche der vom  Aktensystem durchgesetzten Zugriffsregeln bezüglich Lesen, Schreiben und Löschen für eine einzelne Dokumentenkategorie für eine einzelne Leistungserbringerinstitution gelten.  [<=]

A_19693 - ePA-Frontend des Versicherten: Änderung der Dokumentenkategorie-Zugriffsberechtigung

Das ePA-Frontend des Versicherten MUSS dem Nutzer jederzeit ermöglichen, einmal getroffene Entscheidungen bezüglich der Zugriffsberechtigung für einzelne Dokumentenkategorien zurückzunehmen und neu zu vergeben. [<=]

A_19698-01 - ePA-Frontend des Versicherten: Erstellen eines Policy Document für die kategorienbasierte Berechtigung

Das ePA-Frontend des Versicherten MUSS bei der Erteilung einer Berechtigung für den Zugriff auf eine Dokumentenkategorie ein Policy Document für diese Leistungserbringerinstitution erzeugen und in der ePA-Dokumentenverwaltung speichern. Dieses muss in ihren Regeln die Freigabe der einzelnen Dokumentenkategorien enthalten. Wenn es für die LEI noch kein Policy Document gibt, dann muss das ePA-Frontend des Versicherten diese erstellen. [<=]

Bei der kategorienbasierten Berechtigung kann der Zugriff auf die vorhandenen Dokumente einer Dokumentenkategorie weiterhin in drei Vertraulichkeitsstufen näher festgelegt werden. Dabei werden die Vertraulichkeitsstufen normal, vertraulich und streng vertraulich verwendet. Eine einzelne Leistungserbringerinstitution kann entweder Zugriff auf alle Dokumente der Vertraulichkeitsstufe normal oder auf die Vertraulichkeitsstufen normal und vertraulich erhalten. Es ist auch möglich, einen generellen Zugriff auf diese beiden oder einer der beiden Vertraulichkeitsstufen zu vergeben. Dazu müssen in einer Autorisierung zusammen mit einer Vertraulichkeitsstufe alle Dokumentenkategorien für einen Zugriff ausgewählt werden.

Der Zugriff auf Dokumente der Vertraulichkeitsstufe streng vertraulich ist der Leistungserbringerinstitution nur dann möglich, wenn eine gesonderte Freigabe über eine Allowlist vorgenommen wird.

Eine einmal getroffene Entscheidung bezüglich der Zuordnung eines Dokumentes zu einer Vertraulichkeitsstufe und bezüglich des Zugriffs einer Leistungserbringerinstitution kann vom Versicherten durch das ePA-Frontend des Versicherten jederzeit revidiert werden. 

A_19566-02 - ePA-Frontend des Versicherten: Vertraulichkeitsstufen in der kategorienbasierten Berechtigung

Das ePA-Frontend des Versicherten MUSS dem Nutzer die Möglichkeit geben, bei der kategorienbasierten Berechtigungsvergabe pro Kategorie ein normales oder ein erweitertes Zugriffsrecht auszuwählen. [<=]

A_20177-01 - ePA-Frontend des Versicherten: Verwendung der Operation RestrictedUpdateDocumentSet

Das ePA-Frontend des Versicherten MUSS die Operation I_Document_Management_Insurant::RestrictedUpdateDocumentSet ausschließlich dafür verwenden, um die Zugriffsberechtigungen für LEI auf Dokumente in der grobgranularen Berechtigungsverwaltung aufgrund einer Interaktion mit dem Versicherten zu verändern. Es darf ausschließlich der DocumentEntry.confidentialityCode am FdV durch ein Metadaten-Update geändert werden.
[<=]

Beim Aufruf von I_Document_Management_Insurant::RestrictedUpdateDocumentSet muss immer für "previousVersion" in der Nachricht der Wert "1" angegeben werden, da der Aufruf seitens der ePA-Dokumentenverwaltung nicht für eine echte Versionierung des alten Dokuments genutzt wird. Serverseitig wird DocumentEntry.version entsprechend nicht verwaltet und besitzt standardmäßig deshalb immer den impliziten Wert 1.

A_21232 - ePA-Frontend des Versicherten: Konfiguration der Vertraulichkeitsstufe

Das ePA-Frontend des Versicherten MUSS dem Nutzer die Konfiguration des Defaultwertes der Vertraulichkeitsstufe beim Einstellen von Dokumenten jederzeit ermöglichen. [<=]

Das Abspeichern des Defaultwertes erfolgt lokal im ePA-FdV, d.h. bei Nutzung eines weiteren Gerätes ist dieser Defaultwert nicht bekannt.

A_20178-01 - ePA-Frontend des Versicherten: Vorauswahl der Vertraulichkeitsstufe

Das ePA-Frontend des Versicherten MUSS beim Einstellen von Dokumenten den vom Nutzer konfigurierten Defaultwert der Vertrauensstufe vorschlagen. [<=]

A_19567-02 - ePA-Frontend des Versicherten: Vertraulichkeits-Kennzeichnung hochgeladener Dokumente

Das ePA-Frontend des Versicherten MUSS bei allen Dokumenten die vom Nutzer ausgewählte Vertraulichkeitsstufe in den Metadaten jedes Dokuments setzen. [<=]

A_19578-02 - ePA-Frontend des Versicherten: Abbildung der Vertraulichkeitsstufen auf confidentialityCodes

Das ePA-Frontend des Versicherten MUSS, wenn der Nutzer seine Dokumente mittels der kategorienbasierten Berechtigung freigeben möchte, bei diesen Dokumenten die vom Nutzer ausgewählte Vertraulichkeitsstufe über folgende confidentialityCodes abbilden:

•   normal -> confidentialityCode normal

•   vertraulich ->confidentialityCode restricted

Im Detail ist dies auch schon in Kapitel 6.2.6 in den Anforderungen A_15386-* und A_15387-* übergreifend beschrieben. [<=]

A_19568-01 - ePA-Frontend des Versicherten: Auswahl der Leistungserbringerinstitution für die kategorienbasierte Berechtigung

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, einer oder mehreren Leistungserbringerinstitutionen, die über die Anforderungen A_15380 gefunden wurden, eines der folgenden Zugriffsrechte zu erteilen:

•   einfaches Zugriffsrecht (Vertraulichkeitsstufe "normal")

•   erweitertes Zugriffsrecht (Vertraulichkeitsstufen "normal" und "vertraulich")

[<=]

Eine Leistungserbringerinstitution, welche das einfache Zugriffsrecht erteilt wurde, hat nur Zugriff auf Dokumente in der ePA mit der Vertraulichkeitsstufe normal. Eine Leistungserbringerinstitution, welcher das erweitere Zugriffsrecht erteilt wurde, hat nur Zugriff auf Dokumente in der ePA mit den Vertraulichkeitsstufen normal und vertraulich.  

A_19577 - ePA-Frontend des Versicherten: Optische Anzeige der Vertraulichkeitsstufen

Das ePA-Frontend des Versicherten KANN dem Nutzer die Vertraulichkeitsstufe eines Dokumentes durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe,Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen.  [<=]

Mögliche Anzeigen wäre z. B: "LEI hat erweitertes Zugriffsrecht mit Freigabe der Kategorie Arztbrief und wurde nicht explizit einzeln ausgeschlossen.", "LEI hat explizite Einzelfreigabe für dieses Dokument.", "LEI hat kein Zugriffsrecht für dieses Dokument6.2 Befugnisverwaltung für DiGA

Eine Befugnis für eine DiGA gilt unbegrenzt, d.h. die Befugnis gilt solange bis der Nutzer diese Befugnis löscht.

In diesem Kapitel werden die folgenden Anwendungsfälle umgesetzt:

•   "Befugnis für eine DiGA erstellen"

•  "Befugnis für eine DiGA löschen"

A_1958025129 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von normal nach vertraulich

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von normal in vertraulich zu ändern. [<=]

A_19581 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von normal nach streng vertraulichDiGA - Befugnis verwalten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von normal in streng vertraulich zu ändern. [<=]

A_19582 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von vertraulich nach normal

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von vertraulich in normal zu ändern. [<=]

A_19583 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von vertraulich nach streng vertraulich

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von vertraulich in streng vertraulich zu änderneine Befugnis für eine DiGA zu erstellen bzw. zu löschen. [<=]

A_1958425130 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von streng vertraulich nach normal

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von streng vertraulich in normal zu ändern. [<=]

A_19585 - ePA-Frontend des Versicherten: Wechsel der Vertraulichkeitsstufe von streng vertraulich nach vertraulich

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Vertraulichkeitsstufe eines Dokumentes von streng vertraulich in vertraulich zu ändern. [<=]

A_19588 - ePA-Frontend des Versicherten: Erstellen einer Leistungserbringer-Policy für das einfache Zugriffsrecht

Das ePA-Frontend des Versicherten MUSS beim Erteilen einer einfachen Zugriffsberechtigung für die Leistungserbringerinstitution in der APPC-Policy das einfache Zugriffsrecht über den confidentialityCode normal abbilden. [<=]

A_19589 - ePA-Frontend des Versicherten: Erstellen einer Leistungserbringer-Policy für das erweiterte Zugriffsrecht

Das ePA-Frontend des Versicherten MUSS beim Erteilen einer erweiterten Zugriffsberechtigung für die Leistungserbringerinstitution in der APPC-Policy das erweiterte Zugriffsrecht über die confidentialityCodes normal und restricted abbilden. [<=]

6.2.7.1.2 Dokumentenspezifische Berechtigung

Bei der dokumentenspezifischen oder feingranularen Berechtigung wird der Zugriff einer Leistungserbringerinstitution auf die vorhandenen Dokumente der elektronischen Patientenakte auf der Ebene einzelner Dokumente organisiert. Dazu erzeugt das ePA Frontend des Versicherten für jedes freizugebende Dokument (d.h. intern pro documentEntry.entryUUID) einen Eintrag auf einer sogenannten Allowlist, um einen Zugriff zu gewähren. Ein explizites Verbot kann der Versicherte über eine sogenannte Denylist aussprechen. Auf einer Allow- oder Denylist kann auch ein Ordner (d.h. intern pro Folder.entryUUID) der Sammlungstypen uniform und mixed stehen, um z.B. bei potentiell mehreren Pässen spezifische Zugriffe zu untersagen (welche u.U. durch eine Freigabe über die Dokumentenkategorien möglich wären).  Beim Aktualisieren der Allowlist- oder Denylist-Einträge muss das ePA-Frontend des Versicherten sicherstellen, dass diese Policies keine widersprüchlichen Einträge enthalten.

A_19768 - ePA-Frontend des Versicherten: Zugriff auf ein einzelnes Dokument für eine Leistungserbringerinstitution erteilen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, einer vorher ausgewählten LEI den Zugriff auf ein einzelnes Dokument ermöglichen. [<=]

A_19770 - ePA-Frontend des Versicherten: Zugriff auf ein einzelnes Dokument für eine Leistungserbringerinstitution entziehen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, einer vorher ausgewählten LEI den Zugriff auf ein einzelnes Dokument zu entziehen. [<=]

A_19771 - ePA-Frontend des Versicherten: Anzeige der freigegebenen Dokumente für eine einzelne Leistungserbringerinstitution

Das ePA-Frontend des Versicherten MUSS dem Nutzer in einer Liste anzeigen, welche Dokumente für eine einzelne LEI über die feingranulare Berechtigung freigegeben sind. Die Ansicht MUSS Angaben zu den vom Aktensystem durchgesetzten möglichen Zugriffsarten (Lesen, Schreiben und Löschen) der LEI enthalten. [<=]

A_19772 - ePA-Frontend des Versicherten: Anzeige der nicht freigegebenen Dokumente für eine einzelne Leistungserbringerinstitution

Das ePA-Frontend des Versicherten MUSS dem Nutzer in einer Liste anzeigen, welche Dokumente für eine einzelne LEI über die feingranulare Berechtigungsverwaltung der Zugriff entzogen wurde. [<=]

A_19773 - ePA-Frontend des Versicherten: Optische Kennzeichnung für eine LEI freigegebene Dokumente

Das ePA-Frontend des Versicherten KANN dem Nutzer die für eine LEI freigegebenen Dokumente durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe, Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen. [<=]

A_19774 - ePA-Frontend des Versicherten: Optische Kennzeichnung der für eine LEI gesperrten Dokumente

Das ePA-Frontend des Versicherten KANN dem Nutzer die für eine LEI nicht freigegebene Dokumente durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe,Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen. [<=]

A_19778-02 - ePA_Frontend des Versicherten: Abbilden eines erteilten Zugriffs in dem Policy Document

Das ePA-Frontend des Versicherten MUSS einen Allowlist-Eintrag mit der DocumentEntry.entryUUID oder Folder.entryUUID (eines Folders der Sammlungstypen uniform und mixed) in der Allowlist-Policy des Policy Document der LEI erstellen, wenn der Nutzer dieser LEI den Zugriff auf ein konkretes Dokument bzw. einen konkreten Folder der Sammlungstypen uniform und mixed erteilen möchte. 
[<=]

A_19866 - ePA_Frontend des Versicherten: Erzeugen einer neuen APPC Policy

Das ePA-Frontend des Versicherten MUSS für eine LEI eine neue APPC Policy anlegen, wenn der Versicherte eine Berechtigung auf ein Dokument für eine bestimmte LEI erteilt oder entzogen hat und es noch keine APPC Policy gibt. [<=]

A_19867 - ePA_Frontend des Versicherten: Kein Dokument gleichzeitig auf Allowlist und Denylist

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass in einer APPC Policy kein Dokument gleichzeitig auf Deny- und Allowlist gelistet ist. [<=]

A_19781-02 - ePA_Frontend des Versicherten: Abbilden eines entzogenen Zugriffs in dem Policy Document

Das ePA-Frontend des Versicherten MUSS einen Denylist-Eintrag mit der DocumentEntry.entryUUID oder Folder.entryUUID (eines Folders der Sammlungstypen uniform und mixed) in der Denylist-Policy des Policy Document der LEI erstellen, wenn der Nutzer dieser LEI den Zugriff auf ein konkretes Dokument bzw. einen konkreten Folder der Sammlungstypen uniform und mixed entziehen möchte. 
[<=]

6.2.7.2 Vertretung einrichten

Mit diesem Anwendungsfall richtet ein Versicherter (Aktenkontoinhaber) eine Zugriffsberechtigung für einen Vertreter ein. Dieser Vertreter muss über eine eigene gültige eGK verfügen und den PIN seiner eGK kennen oder eine alternative Authentisierung für ein geeignetes FdV auf seinem GdV eingerichtet haben. Der Anwendungsfall steht einem berechtigten Vertreter nicht zur Verfügung.

Zur Verbesserung des Datenschutzes muss die Vertretung zusätzlich über eine E-Mail durch den Versicherten bestätigt werden.

DiGA - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine DiGA im VZD-FHIR-Directory zu suchen und für die Vergabe der Befugnis auszuwählen. [<=]

Für die Umsetzung der Suche siehe Aktivität 6.2.3.3 DiGA im Verzeichnisdienst der TI finden .

6.2.6.3 Vertretung einrichten

Ein Versicherter (Aktenkontoinhaber) kann eine Befugnis für einen Vertreter einrichten oder auch entziehen. Dieser Vertreter muss über eine GesundheitsID verfügen. Der Anwendungsfall "Vertretung einrichten" steht einem befugten Vertreter nicht zur Verfügung.
Vor der Berechtigung müssen der Name, die Versicherten-ID sowie die E-Mailadresse des Vertreters für die Geräteautorisierung erfasst werden.

A_15389 - ePA-Frontend des Versicherten: Daten des Vertreters

Das ePA-Frontend des Versicherten MUSS es dem Nutzer im Anwendungsfall "Vertretung einrichten" ermöglichen, den Namen, die Versicherten-ID und eine Benachrichtigungsadresse (E-Mail) für die Geräteautorisierung des Vertreters zu erfassen. [<=]

Die BerechtigungsdauerBefugnisdauer für Vertreter kann nicht zeitlich oder inhaltlich begrenzt werden. Wenn ein Vertreter berechtigtbefugt ist, auf die Dokumente zuzugreifen, dann kann der Vertreter dauerhaft auf alle Dokumente im Aktenkonto zugreifen, bis ihm die BerechtigungBefugnis generell wieder entzogen wird.

A_15391-0123971 - ePA-Frontend des Versicherten: VertretungVertreter einrichten

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.2 - Vertretung durch einen Versicherten einrichten" aus [gemSysL_ePA] gemäß TAB_FdV_135 umsetzen.

Tabelle 43: TAB_FdV_135 – Vertretung einrichten

[<=]

A_15396-01 - ePA-Frontend des Versicherten: Vertretung einrichten - AuthorizationKey erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung einrichten" einen AuthorizationKey für den Vertreter mit AuthorizationType = DOCUMENT_AUTHORIZATION erstellen. [<=]

Falls der Vertreter die Vertretung nicht ausschließlich in einer LEI sondern auch an einem FdV wahrnehmen möchte, muss in der folgende Aktivität die Benachrichtigungsadresse des Vertreters für die Geräteautorisierung an das Aktensystem übergeben werden, da der Vertreter sich ansonsten von seinem FdV nicht autorisieren kann. 

A_15397-01 - ePA-Frontend des Versicherten: Vertretung einrichten - Schlüsselmaterial im ePA-Aktensystem speichern

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung einrichten" für das Hochladen des Schlüsselmaterials des Vertreters in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit den Eingangsparametern AuthorizationKey = erstellter AuthorizationKey und NotificationInfoRepresentative = Benachrichtigungsadresse für die Geräteautorisierung ausführen. [<=]

A_15398-01 - ePA-Frontend des Versicherten: Vertretung einrichten - Policy Document erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung einrichten", ein Policy Document für den zu berechtigenden Vertreter erstellen. [<=]

Für Informationen zu Policy Documents und deren Nutzungsvorgaben siehe " ".

A_15399-01 - ePA-Frontend des Versicherten: Vertretung einrichten - Policy Document hochladen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung einrichten" zum Hochladen des Policy Documents in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für Policy Documents ausführen. [<=]

Dem Versicherten kann ein Hinweis angezeigt werden, dass zum Abschluss eine Autorisierung der Vertretung über eine E-Mail erfolgen muss, welche dem Versicherten vom Aktensystem zugesandt wird. 

Nach der Einrichtung der Vertretung teilt der Versicherte dem Vertreter die Informationen mit, welche der Vertreter in seinem FdV konfigurieren muss, um auf das Aktenkonto zugreifen zu können. Diese Informationen können der Konfiguration des ePA-FdV entnommen werden.es dem Versicherten ermöglichen, eine Befugnis für einen Vertreter zu erstellen oder zu löschen.
[<=]

A_15400-01 - ePA-Frontend des Versicherten: PDF mit Information für Vertretung

Das ePA-Frontend des Versicherten MUSS dem Versicherten die Möglichkeit geben, ein druckbares Format (z. B. PDF) mit den Informationen für die Vertretung zu erzeugen. Das Dokument mussMUSS die folgenden Informationen des Versicherten, welcher vertreten wird, beinhalten:

• Versicherten-ID
• FQDN des AnbieterAnbieters.

[<=]

Zur Unterstützung kann das FdV bspw. zusätzlich eine E-Mail (an die Benachrichtigungsadresse zur Geräteautorisierung) bereitstellen, um die Informationen zu übermitteln.

A_21534 - Einwilligung des Vertreters bestätigen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung einrichten" vom Versicherten bestätigen lassen, dass der Vertreter der Vertretung und der Verarbeitung der dafür erforderlichen personenbezogenen Daten im ePA-Aktensystem zugestimmt hat und den Anwendungsfall abbrechen, falls die Bestätigung durch den Versicherten nicht erfolgt. [<=]

A_21535 - Information zu verarbeiteten personenbezogenen Daten des Vertreters im ePA-Aktensystem

Der Hersteller des ePA-Frontends des Versicherten MUSS sicherstellen, dass dem Versicherten die notwendigen Informationen zur Verfügung gestellt werden, die für die Einholung der Zustimmung des Vertreters benötigt werden, insbesondere welche personenbezogenen Daten vom Vertreter im Rahmen der Vertreterberechtigung im ePA-Aktensystem verarbeitet werden, wie der Vertreter eine Vertreterberechtigung widerrufen kann, gegenüber wem er seine datenschutzrechtlichen Betroffenenrechte wahrnehmen kann und wo die Datenschutzerklärungen der entsprechenden Krankenkassen zu finden sind. [<=]

A_23555Anwendungsfall "Vertretung am fremden FdV verwalten" als Sonderfall - gleicher Kostenträger von Vertretenden und Vertreter

Für den Fall, dass der zu Vertretende und der zukünftige Vertreter beim gleichen Kostenträger versichert sind, ist die Umsetzung des Anwendungsfalls "Vertretung am fremden FdV verwalten" wie folgt möglich.

A_23555-01 - ePA-Frontend des Versicherten: Vertretung am fremden FdV des Vertreters verwaltenverwalten - Ablauf

Das ePA-Frontend des Versicherten KANN den Anwendungsfall "Vertretung am fremden FdV des Vertreters verwalten" gemäß TAB_FdV_136 umsetzen. 

Tabelle 44: TAB_FdV_136 –10: Vertretung am fremden FdV des Vertreters verwalten 

[<=]

A_2377024405 - ePA-Frontend des Versicherten: Vertretung am FdV des Vertreters einrichten und löschen ausschließlich mit eGK (nicht alvi)

Das ePA-FdV MUSS sicherstellen, dass der Anwendungsfall "Vertretung am FdV des Vertreters verwalten"

•   ausschließlich mittels eGK des zu Vertretenden, aber nicht mit einer al.vi des zu Vertretenden möglich ist und

•   in den Operationen getAuthorizationKey, putAuthorizationKey und deleteAuthorizationKey der Komponente Autorisierung für den Parameter DeviceID der Wert AUTHORIZE_REPRESENTATIVE verwendet wird.

[<=]

6.2.7.3 Berechtigung für Kostenträger vergeben

Mit diesem Anwendungsfall richtet ein Versicherter oder ein berechtigter Vertreter Zugriffsberechtigungen auf das Aktenkonto für einen Kostenträger ein. Der Zugriff eines KTR ist auf das Einstellen und Aktualisieren von Dokumenten beschränkt.

A_21547 - ePA-Frontend des Versicherten: Telematik-ID des Kostenträgers ermittelnfremden FdV verwalten - Authentisierung

Das ePA-Frontend des Versicherten MUSS die Telematik-ID des zu berechtigen Kostenträgers mittels der Operation I_Authorization_Management_Insurant::getKtrTelematikID ermitteln. [<=]

A_17188 - ePA-Frontend des Versicherten: Bestätigung Berechtigung für Kostenträger

Das ePA-Frontend des Versicherten MUSS, bevor es eine Berechtigung an einen Kostenträger vergibt, eine Bestätigung vom Nutzer einholen. Hierbei ist der Name des zu berechtigenden Kostenträgers kenntlich zu machen. [<=]

A_17189-01 - ePA-Frontend des Versicherten: Berechtigung an Kostenträger für Aktenkonto vergeben

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 3.1 - Berechtigung durch einen Versicherten vergeben" aus [gemSysL_ePA] für den Kostenträger, für den eine Berechtigung vergeben werden soll, gemäß TAB_FdV_171 umsetzen.

Tabelle 45: TAB_FdV_171 – Berechtigung an Kostenträger für Aktenkonto vergeben

[<=]

A_17190-01 - ePA-Frontend des Versicherten: Berechtigung Kostenträger vergeben - AuthorizationKey erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an Kostenträger für Aktenkonto vergeben" einen AuthorizationKey mit AuthorizationType = DOCUMENT_AUTHORIZATION für den zu berechtigenden Kostenträger erstellen. [<=]

A_17191-01 - ePA-Frontend des Versicherten: Berechtigung Kostenträger vergeben - Schlüsselmaterial im ePA-Aktensystem speichern

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an Kostenträger für Aktenkonto vergeben" für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem Eingangsparameter AuthorizationKey = erstellter AuthorizationKey ausführen. Der optionale Parameter NotificationInfoRepresentative wird nicht belegt. [<=]

A_17192-01 - ePA-Frontend des Versicherten: Berechtigung Kostenträger vergeben - Policy Document erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an Kostenträger für Aktenkonto vergeben" ein Policy Document für den zu Berechtigenden erstellen. [<=]

Für Informationen zu Policy Documents und deren Nutzungsvorgaben siehe "".

A_17193-01 - ePA-Frontend des Versicherten: Berechtigung Kostenträger vergeben - Policy Document hochladen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung an Kostenträger für Aktenkonto vergeben" zum Hochladen des Policy Documents in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für Policy Documents ausführen.
[<=]

6.2.7.4 Vergebene Berechtigungenim Anwendungsfall "Vertretung am fremden FdV verwalten" auf dem Gerät des zukünftigen Vertreters die Authentisierung des zu Vertretenden am IdP mit GesundheitsID durch Angabe von AUTHORIZE_REPRESENTATIVE verlangen. [<=]

6.2.6.4 Vergebene Befugnisse anzeigen

Mit diesem Anwendungsfall kann ein Nutzer eine Liste der für das Aktenkonto vergebenen BerechtigungenBefugnisse anzeigen lassen. Diese Liste beinhaltet die zugriffsberechtigten Leistungserbringer, die berechtigten Vertreter und zugriffsberechtigte Kostenträgerbefugten Leistungserbringerinstitutionen, DiGAs und Vertreter sowie die Details zu Berechtigungen (für LEI: Berechtigungsdauer, Zugriff auf durch den Versicherten eingestellte Dokumente).

A_15401-0123963 - ePA-Frontend des Versicherten: Vergebene BerechtigungenBefugnisse anzeigen

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.5 - Berechtigungen durch einen Versicherten auflisten" aus [gemSysL_ePA] gemäß TAB_FdV_137 umsetzen.

Tabelle 46: TAB_FdV_137 – Vergebene Berechtigungen anzeigen

[<=]

A_15402-01 - ePA-Frontend des Versicherten: Berechtigungen anzeigen - Berechtigungen bestimmen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vergebene Berechtigungen anzeigen" die übergreifende Aktivität "Vergebene Berechtigungen bestimmen" ausführendem Nutzer alle im Aktensystem hinterlegten Befugnisse einschließlich Gültigkeitszeitraum anzeigen und dem Nutzer nach Nutzergruppen (LEI, DiGA, Vertreter) geordnet anzeigen. [<=]

A_15403-0923972 - ePA-Frontend des Versicherten: Ergebnisliste BerechtigungenBefugnisse Felder

Das ePA-Frontend des Versicherten MUSS im Ergebnis der Suche nach BerechtigungenBefugnissen mindestens

•   für LEI: Name der Leistungserbringerinstitution, des Kostenträgers bzw. des Vertreters (Nur für den Fall, dass der Aufrufende der Versicherte ist. Bei Aufruf durch einen Vertreter erfolgt die Ausgabe der Namen der Vertreter nicht.) im Klartext,

•   für LEI: Berechtigte Kategorien samt Vertraulichkeitsstufe (nicht im Kontext des Anwendungsfalls "Anbieter wechseln")

•   für LEI: Explizit erlaubte oder geblockte Dokumente gemäß dokumentenspezifischer Berechtigung (nicht im Kontext des Anwendungsfalls "Anbieter wechseln")

•   für LEI: verbleibende Berechtigungsdauer (nicht im Kontext des Anwendungsfalls "Anbieter wechseln")

•   für Vertreter: Anzeige der E-Mail-Adresse der berechtigten Vertreter (Nur für den Fall, dass der Aufrufende der Versicherte ist. Bei Aufruf durch einen Vertreter erfolgt die Ausgabe der E-Mail-Adresse der Vertreter nicht.)

•   für DiGA: Name des DiGA-Herstellers und Name der DiGAEnde der Befugnis (nicht im Kontext des Anwendungsfalls "Anbieter wechseln")

•   für DiGA: Name des DiGA-Herstellers und Name der DiGA

•   für Vertreter: Name des Vertreters und Anzeige der E-Mail-Adresse des befugten Vertreters (Nur für den Fall, dass der Aufrufende der Versicherte ist. Bei Aufruf durch einen Vertreter erfolgt die Ausgabe der E-Mail-Adresse der Vertreter nicht.)

anzeigen. [<=]

Das Ergebnis der Suche soll für den Nutzer sortierbar und filterbar dargestellt werden.

A_15405-01 - ePA-Frontend des Versicherten: Ergebnisliste Berechtigungen drucken und speichern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, das Ergebnis der Suche nach Berechtigungen auszudrucken oder lokal zu speichern. [<=]

Das lokale Speichern kann im PDF-Format angeboten werden.

Das Das ePA-FdV ermöglicht es dem Nutzer, über Einträge in der Ergebnisliste Berechtigungen Befugnisse zu bearbeiten oder zu löschen.

6.2.76.5 Eingerichtete Vertretungen anzeigen

Mit diesem Anwendungsfall kann ein Nutzer eine Liste der Versicherten anzeigen lassen, für die im ePA-Frontend des Versicherten die Wahrnehmung der Vertretung durch ihn konfiguriert ist ("ich bin Vertreter für"). Es wird dabei nicht geprüft, ob im Aktenkonto des zu Vertretenden auch tatsächlich eine BerechtigungBefugnis für den Nutzer vorliegt.

A_15406 - ePA-Frontend des Versicherten: Liste "ich bin Vertreter für" anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine Liste mit den im ePA-Frontend des Versicherten  für ihn konfigurierten Vertretungen anderer Versicherter anzuzeigen. [<=]

6.2.7.6 Bestehende Berechtigungen verwalten Verbergen und Sichtbarmachen von Dokumenten

6.2.7.6.1 Berechtigung für LEI ändern

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter die Parameter für eine berechtigte LEI ändern.

A_15407-04 - ePA-Frontend des Versicherten: Bestehende Berechtigungen einer Leistungserbringerinstitution ändern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, für bereits berechtigte Leistungserbringerinstitutionen kategorienbasierte als auch dokumentenspezifische Berechtigungsvorgaben sowie die Berechtigungsdauer anzupassen. [<=]

Die zum Zugriff auf das Aktenkonto berechtigten LEIs werden mit der übergreifenden Aktivität "Vergebene Berechtigungen bestimmen" ermittelt.

Wenn die Berechtigungsdauer geändert wird, dann muss ein neuer AuthorizationKey auf Basis eines Verschlüsselungszertifikates der LEI erzeugt werden. Ein Verschlüsselungszertifikat kann mit der Aktivität "Suchanfrage Verzeichnisdienst der TI" mit dem Suchkriterium Telematik-ID ermittelt werden. Die Telematik-ID der LEI lässt sich aus dem Policy Document bestimmen.

A_15408-01 - ePA-Frontend des Versicherten: Berechtigung für LEI ändern

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 3.6 - Bestehende Berechtigungen durch einen Versicherten verwalten" aus [gemSysL_ePA] für jede LEI, für die Konfiguration seiner Berechtigung geändert werden soll, gemäß TAB_FdV_138 umsetzen.

Tabelle 47: TAB_FdV_138 – Berechtigung für LEI ändern

[<=]

Das Policy Document der LEI steht aus der Aktivität "Vergebene Berechtigungen bestimmen" zur Verfügung.

A_15409-01 - ePA-Frontend des Versicherten: Berechtigung für LEI ändern - Policy Document anpassen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für LEI ändern" das Policy Document entsprechend der gewählten Einstellungen für Berechtigungsdauer und/oder Aktenanteil anpassen. [<=]

Die Anpassung des AuthorizationKey muss nur erfolgen, wenn die Berechtigungsdauer für die LEI geändert wurde.

A_15412-01 - ePA-Frontend des Versicherten: Berechtigung für LEI ändern - AuthorizationKey für LEI erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für LEI ändern", wenn die Einstellung für Berechtigungsdauer geändert wurde, einen AuthorizationKey mit AuthorizationType = DOCUMENT_AUTHORIZATION und validTo entsprechend der vom Nutzer festgelegten Berechtigungsdauer für die zu berechtigende LEI erstellen. [<=]

A_15413-01 - ePA-Frontend des Versicherten: Berechtigung für LEI ändern - Schlüsselmaterial im ePA-Aktensystem ersetzenDokumente sind für eine befugte LEI prinzipiell sichtbar. Allerdings besteht die Möglichkeit die Sichtbarkeit bei Zugriffen von Leistungserbringerinstitutionen einzuschränken. Es gibt folgende Möglichkeiten zum Verbergen von Dokumenten:

4. Kategorienbasiertes Verbergen von Dokumenten ggü. allen Leistungserbringerinstitutionen:
   Der Nutzer wählt im ePA-Frontend des Versicherten die zu verbergenden Datenkategorien aus. Das ePA-Frontend des Versicherten übermittelt diese Datenkategorien über eine spezifische Schnittstelle an den Constraint Management Service, welcher sie in die General Deny Policy aufnimmt.
   Alle Dokumente dieser Datenkategorie sind für alle Leistungserbringerinstitutionen zum Zugriff nicht sichtbar.
5. Kategorienbasiertes Verbergen von Dokumenten ggü. einer Leistungserbringerinstitution
   Der Nutzer wählt im ePA-Frontend des Versicherten für eine gewählte Leistungserbringerinstitution die zu verbergenden Datenkategorien aus. Das ePA-Frontend des Versicherten übermittelt diese Datenkategorien über eine spezifische Schnittstelle an den Constraint Management Service, welcher sie in die User-specific Deny Policy für die gewählte Leistungserbringerinstitution aufnimmt.
   Alle Dokumente dieser Datenkategorie sind für die gewählte Leistungserbringerinstitution zum Zugriff nicht sichtbar.
6. Dokumentenspezifisches Verbergen von Dokumenten ggü. allen Leistungserbringerinstitution
   Der Nutzer wählt im ePA-Frontend des Versicherten die zu verbergenden Dokumente aus. Das ePA-Frontend des Versicherten übermittelt diese Dokumenten-IDs über eine spezifische Schnittstelle an den Constraint Management Service, welcher sie in die General Deny Policy aufnimmt.
   Alle verborgenen Dokumente sind für alle Leistungserbringerinstitutionen zum Zugriff nicht sichtbar.
7. Dokumentenspezifisches Verbergen von Dokumenten ggü. einer Leistungserbringerinstitution
   Der Nutzer wählt im ePA-Frontend des Versicherten für eine gewählte Leistungserbringerinstitution die zu verbergenden Dokumente aus. Das ePA-Frontend des Versicherten übermittelt diese Dokumenten-IDs über eine spezifische Schnittstelle an an den Constraint Management Service, welcher sie in die User-specific Deny Policy für die gewählte Leistungserbringerinstitution aufnimmt. 
   Alle verborgenen Dokumente sind für die gewählte Leistungserbringerinstitution zum Zugriff nicht sichtbar.

Die Datenkategorien sind in der [ ] aufgeführt.

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für LEI ändern", wenn die Einstellung für Berechtigungsdauer geändert wurde, für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem ersetzen" mit den Eingangsparametern NewAuthorizationKey = geänderter AuthorizationKey ausführen. [<=]

A_15414-01 - ePA-Frontend des Versicherten: Berechtigung für LEI ändern - Policy Document in Dokumentenverwaltung laden

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für LEI ändern" für das Hochladen des Policy Documents in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für das angepasste Policy Documents ausführen. [<=]

Die Dokumentenverwaltung verarbeitet das Policy Document und überschreibt die vorher geltenden Regeln.

6.2.7.6.2 Berechtigung für LEI löschen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter einer berechtigten LEI die Berechtigung entziehen.

A_15415 - ePA-Frontend des Versicherten: LEI zum Entzug der Berechtigung markieren

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, berechtigte LEI für den Entzug der Berechtigung auszuwählen. [<=]Sichtbar machen von bisher verborgenen Dokumenten oder einer bisher verborgenen Datenkategorie erfolgt in gleicher Art und Weise. Der Nutzer wählt im ePA-Frontend des Versicherten für alle oder eine gewählte Leistungserbringerinstitution die verborgen Dokumente oder Datenkategorien aus, welche er sichtbar machen möchte. Das ePA-Frontend des Versicherten übermittelt diese Auswahl an den Constraint Management Service, welcher sie in der General Deny Policy und/oder User-specific Deny Policy für die gewählte Leistungserbringerinstitution aktualisiert. 

Verbergen und Sichtbarmachen von MIOs

Eine Besonderheit stellt das Verbergen von MIOs dar. Einzelne Dokumente eines MIOs dürfen nicht verborgen werden, damit die Aussage des MIOs in seiner Gesamtheit nicht verfälscht wird.
Das Verbergen eines konkreten MIOs erfolgt entweder über das Verbergen der Datenkategorie (MIOs die durch einen statischen Ordner repräsentiert werden, z. B. Impfpass, Zahnbonusheft, Kinderuntersuchungsheft) oder über das Verbergen eines dynamischen Ordners (Mutterpass, DiGA).

Die zum Zugriff auf das Aktenkonto berechtigten LEIs werden mit der übergreifende Aktivität "Vergebene Berechtigungen bestimmen" ermitteltKonfiguration der General Deny Policy und der User-specific Deny Policy erfolgt im Constraint Management des ePA-Aktensystems.

A_15416-0124357 - ePA-Frontend des Versicherten: Berechtigung für LEI löschenVerbergen von Dokumenten - Schnittstelle

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.6 - Bestehende Berechtigungen durch einen Versicherten verwalten" aus [gemSysL_ePA] für jeden berechtigten LEI, dessen Berechtigung entzogen werden soll, gemäß TAB_FdV_139 umsetzen.

Tabelle 48: TAB_FdV_139 – Berechtigung löschen

zum Verbergen und sichtbar Machen von Dokumenten und Datenkategorien das Interface I_Constraint_Management_Insurant gemäß [I_Constraint_Management_Insurant] am ePA-Aktensystem aufrufen. [<=]

A_15417-0224452 - ePA-Frontend des Versicherten: Berechtigung für LEI löschen - Policy Document in Dokumentenverwaltung löschenVerbergen von Dokumenten - Nutzung FHIR-VZD

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung für LEI löschen" für das Löschen des Policy Document in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung löschen" mit einer RemoveMetadata_Message für den über die XDS-Metadaten ermittelten Dokument Identifier des Policy Documents der LEI ausführenzum Verbergen und sichtbar Machen von Dokumenten und Datenkategorien bei der Auswahl einzelner LEIs die Vorgaben gemäß   nutzen und für die Konfiguration der User-specific Deny Policy die am FHIR-VZD ermittelten Parameter verwenden. [<=]

Die Telematik-ID der LEI kann aus dem Policy Document bestimmt werden.

A_15418-01A_25144 - ePA-Frontend des Versicherten: Berechtigung für LEI löschen - Schlüsselmaterial in ePA-Aktensystem löschenVerbergen von Dokumenten – Hinweis auf mögliche versorgungsrelevante Folgen

Das ePA-Frontend des Versicherten MUSS dem Nutzer im Anwendungsfall "Berechtigung für LEI löschen" für das Löschen des Schlüsselmaterials die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" mit dem Eingangsparameter ActorID = Telematik-ID der LEI ausführenVerbergen von Dokumenten" vor dem Verbergen der Dokumente in der elektronischen Patientenakte einen Hinweis darauf geben, dass das Verbergen von Dokumenten Auswirkungen auf die Versorgung und die Patientensicherheit haben kann. [<=]

6.2.7.6.3 Berechtigung für Vertreter löschen1 Kategorienbasiertes Verbergen von Dokumenten

Mit diesem Anwendungsfall kann ein Versicherter einem berechtigten Vertreter die Berechtigung entziehen. Ferner soll es einem Vertreter auch möglich sein, sich seine eigene Berechtigung zu entziehenDas Verbergen einer Datenkategorie führt dazu, dass alle Dokumente und, falls vorhanden, alle in dieser Datenkategorie enthaltenen dynamischen Ordner (z. B. Mutterpass, DiGA) einschließlich der darin enthaltenen Dokumente für eine/alle befugte Leistungserbringerinstitutionen nicht sichtbar sind.

A_16044-0124449 - ePA-Frontend des Versicherten: Vertreter zum Entzug der Berechtigung markierenVerbergen einer Datenkategorie für eine Leistungserbringerinstitution

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, berechtigte Vertreter  für den Entzug der Berechtigung auszuwählen. Sofern der Nutzer ein Vertreter ist, darf er nur seine eigene Berechtigung auswähleneine vorher ausgewählten LEI eine bzw. mehrere Datenkategorien zum Zugriff durch diese LEI zu verbergen. [<=]

Die zum Zugriff auf das Aktenkonto berechtigten Vertreter werden mit der übergreifende Aktivität "Vergebene Berechtigungen bestimmen" ermittelt.

A_16045-02A_24450 - ePA-Frontend des Versicherten: Berechtigung für Vertreter löschenSichtbar Machen einer Datenkategorie für eine Leistungserbringerinstitution

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.6 - Bestehende Berechtigungen durch einen Versicherten verwalten" aus [gemSysL_ePA] für jeden berechtigten Vertreter, dessen Berechtigung entzogen werden soll, gemäß TAB_FdV_168 umsetzen.

Tabelle 49: TAB_FdV_168 – Berechtigung für Vertreter löschen

dem Nutzer ermöglichen, eine bzw. mehrere zum Zugriff durch eine konkrete LEI verborgenen Datenkategorien für diese LEI sichtbar zu machen. [<=]

A_16046-0219685-01 - ePA-Frontend des Versicherten: Berechtigung für Vertreter löschen - Policy Document in Dokumentenverwaltung löschenAnzeige der zugehörigen Datenkategorie

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für Vertreter löschen" für das Löschen des Policy Document in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung löschen" mit einer RemoveMetadata_Message für den über die XDS-Metadaten ermittelten Dokument Identifier des Policy Documents des Vertreters ausführen.dem Nutzer die dem Dokument zugeordnete Datenkategorie, die in den Anforderungen A_14761-* und A_19388-* aufgeführt sind, anzeigen können.  [<=]

Die Versicherten-ID für den Vertreter kann aus dem AuthorizationKey bestimmt werden.

A_16047-01A_24453 - ePA-Frontend des Versicherten: Berechtigung für Vertreter löschen - Schlüsselmaterial in ePA-Aktensystem löschenBerücksichtigung der Legal Policy bei der Anzeige der Datenkategorien

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für Vertreter löschen" für das Löschen des Schlüsselmaterials die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" mit dem Eingangsparameter ActorID = Versicherten-ID für Vertreter ausführen. [<=]

6.2.7.6.4 Berechtigung für Kostenträger löschen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter dem Kostenträger die Berechtigung entziehen.

A_17194 - ePA-Frontend des Versicherten: Kostenträger zum Entzug der Berechtigung markieren

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, berechtigte Kostenträger für den Entzug der Berechtigung auszuwählen. [<=]

Die zum Zugriff auf das Aktenkonto berechtigten KTR werden mit der übergreifende Aktivität "Vergebene Berechtigungen bestimmen" ermittelt.

A_17195-01 - ePA-Frontend des Versicherten: Berechtigung für Kostenträger löschen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 3.6 - Bestehende Berechtigungen durch einen Versicherten verwalten" aus [gemSysL_ePA] für den Kostenträger, deren Berechtigung entzogen werden soll, gemäß TAB_FdV_166 umsetzen.

Tabelle 50: TAB_FdV_166 – Berechtigung für Kostenträger löschen

[<=]

A_17196-02 - ePA-Frontend des Versicherten: Berechtigung für Kostenträger löschen - Policy Document in Dokumentenverwaltung löschenbeim Verbergen und Sichtbarmachen einer Datenkategorie die Legal Policy aus [ ] beachten. Daraus folgt, dass dem Nutzer für eine ausgewählte Leistungserbringerinstitution nur diejenigen Datenkategorien angezeigt werden, für die diese grundsätzlich zum Zugriff befugt werden kann. [<=]

Wenn beispielsweise der Nutzer des ePA-Frontends des Versicherten eine Leistungserbringerinstitution mit der Berufsgruppe Geburtshilfe auswählt, dann hat diese weniger mögliche Zugriffsrechte als zum Beispiel ein Hausarzt. Das ePA-Frontend des Versicherten darf dann für die LEI Geburtshilfe nur die nach [ ] möglichen Berechtigungen anzeigen.

A_19690 - ePA-Frontend des Versicherten: Optische Kennzeichnung der Datenkategorien

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für Kostenträger löschen" für das Löschen des Policy Document in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung löschen" mit einer RemoveMetadata_Message für den über die XDS-Metadaten ermittelten Dokument Identifier des Policy Documents des Kostenträgers ausführenKANN dem Nutzer die zugeordnete Datenkategorie eines Dokumentes durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe, Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen. [<=]

Die Telematik-ID des Kostenträgers kann aus dem Policy Document bestimmt werden.

A_17197-01A_24454 - ePA-Frontend des Versicherten: Berechtigung für Kostenträger löschen - Schlüsselmaterial in ePA-Aktensystem löschenAnzeige der für den LEI verborgenen Datenkategorien

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für Kostenträger löschen" für das Löschen des Schlüsselmaterials die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" mit dem Eingangsparameter ActorID = Telematik-ID des Kostenträgers ausführendem Nutzer anzeigen können, welche Datenkategorien für eine einzelne Leistungserbringerinstitution verborgen sind. [<=]

6.2.7.7 Berechtigung für DiGA löschen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter der DiGA die Berechtigung auf die elektronische Patientenakte entziehen.

A_21499 - ePA-Frontend des Versicherten: DiGA zum Entzug der Berechtigung markieren

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, berechtigte DiGAs für den Entzug der Berechtigung auszuwählen. [<=]

Hinweis: Die zum Zugriff auf das Aktenkonto berechtigten DIGA werden mit der übergreifende Aktivität "Vergebene Berechtigungen bestimmen" ermitteltDamit kann der Nutzer vor dem Besuch einer Leistungserbringerinstitution sehen, welche Datenkategorien der ePA bei der LEI verborgen sind.

Das ePA-Akensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung von Berufsgruppen durch, siehe  . Das ePA-Frontend des Versicherten unterstützt den Nutzer dabei, sich ein Bild zu verschaffen, auf welche Datenkategorien eine einzelne befugte Leistungserbringerinstitution prinzipiell zugriffsberechtigt ist.

A_2150024455 - ePA-Frontend des Versicherten: Berechtigung für DiGA löschenAnzeige der für eine befugte LEI prinzipiell geltenden Zugriffsregeln

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 3.6 - Bestehende Berechtigungen durch einen Versicherten verwalten" aus [gemSysL_ePA] für die DiGA, deren Berechtigung entzogen werden soll, gemäß TAB_FdV_190 umsetzen.

Tabelle 51: TAB_FdV_190 – Berechtigung für DiGA löschen

[<=]

A_21501 - ePA-Frontend des Versicherten: Berechtigung für DiGA löschen - Policy Document in Dokumentenverwaltung löschendem Nutzer anzeigen können, welche der vom ePA-Aktensystem durchgesetzten Zugriffsregeln (Legal Policy) hinsichtlich Lesen, Schreiben, Aktualisieren und Löschen für eine einzelne Datenkategorie für eine einzelne Leistungserbringerinstitution gelten. [<=]

6.2.7.2 Dokumentenspezifisches Verbergen von Dokumenten

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für DiGA löschen" für das Löschen des Policy Document in der Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung löschen" mit einer RemoveMetadata_Message für den über die XDS-Metadaten ermittelten Dokument Identifier des Policy Documents der DiGA ausführen. [<=]Verbergen von Dokumenten kann für einzelne Leistungserbringerinstitutionen aber auch für alle Leistungserbringerinstitutionen erfolgen.

Hinweis: Die Telematik-ID der DiGA kann aus dem Policy Document bestimmt werden.

A_21502 - ePA-Frontend des Versicherten: Berechtigung für DiGA löschen - Schlüsselmaterial in ePA-Aktensystem löschen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Berechtigung für DiGA löschen" für das Löschen des Schlüsselmaterials die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem löschen" mit dem Eingangsparameter ActorID = Telematik-ID der DiGA ausführen. [<=]

6.2.7.8 Berechtigungen für DiGA vergeben

Mit diesem Anwendungsfall richtet ein Versicherter oder ein berechtigter Vertreter Zugriffsberechtigungen auf das Aktenkonto für jede einzelne DiGA ein. Die Zugriffrechte einer DiGA sind auf das Einstellen und Aktualisieren von Dokumenten beschränkt.Eine Auswahl einzelner Dokumente, die verborgen werden sollen, kann der Nutzer über 6.2.8.1.2 Dokumente suchen ermitteln. 

Bei der Konfiguration der Policies wird das Metadatum referenceIdList mit "urn:gematik: iti:xds:2023:rootDocumentUniqueId" eines Dokuments verwendet, welches eine Referenz auf ein Dokument unabhängig von der Version des Dokuments darstellt. Dadurch wird sichergestellt, dass das Verbergen eines Dokuments für alle Versionen, also auch für zukünftige Versionen wirksam wird.

A_2149224431 - ePA-Frontend des Versicherten: Bestätigung der Berechtigung für eine DiGAVerbergen von Dokumenten für eine Leistungserbringerinstitution

Das ePA-Frontend des Versicherten MUSS, bevor es eine Berechtigung an eine DiGA vergibt, eine Bestätigung vom Nutzer einholen. Hierbei ist der Name der zu berechtigenden DiGA kenntlich zu machen dem Nutzer ermöglichen, einer ausgewählten LEI ein oder mehrere Dokumente zum Zugriff durch diese LEI zu verbergen. [<=]

Hinweis: Der Name der DiGA entspricht dem displayName aus [gemSpec_VZD#Tabelle 29].

A_21493A_24432 - ePA-Frontend des Versicherten: Berechtigung für eine DiGA für ein Aktensystemkonto vergebenSichtbar machen von Dokumenten für eine Leistungserbringerinstitution

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "UC 3.1 - Berechtigung durch einen Versicherten vergeben" aus [gemSysL_ePA] für die DiGA, für die eine Berechtigung vergeben werden soll, gemäß TAB_FdV_181 umsetzen.

Tabelle 52: TAB_FdV_181 – Berechtigung an DiGA für Aktenkonto vergeben

dem Nutzer ermöglichen, ein oder mehrere zum Zugriff durch eine konkrete LEI verborgenen Dokumente für diese LEI sichtbar zu machen. [<=]

A_2149424360 - ePA-Frontend des Versicherten: Berechtigung DiGA vergeben - AuthorizationKey erstellenAnzeige von verborgenen Dokumenten für eine Leistungserbringerinstitution

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung an DiGA für Aktenkonto vergeben" einen AuthorizationKey mit AuthorizationType = DOCUMENT_AUTHORIZATION für die zu berechtigende DiGA erstellendem Nutzer die im ePA-Aktensystem für einzelne Leistungserbringerinstitutionen verborgenen Dokumente auflisten können. [<=]

A_2149524363 - ePA-Frontend des Versicherten: Berechtigung DiGA vergeben - Schlüsselmaterial im ePA-Aktensystem speichernVerbergen von Dokumenten für alle Leistungserbringerinstitutionen

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung an DiGA für Aktenkonto vergeben" für das Hochladen des Schlüsselmaterials in das ePA-Aktensystem die übergreifende Aktivität "Schlüsselmaterial im ePA-Aktensystem speichern" mit dem Eingangsparameter AuthorizationKey = erstellter AuthorizationKey ausführen. Der optionale Parameter NotificationInfoRepresentative wird nicht belegtdem Nutzer ermöglichen, ein oder mehrere ausgewählte Dokumente für alle Leistungserbringerinstitutionen im ePA-Aktensystem zu verbergen. [<=]

A_2149624364 - ePA-Frontend des Versicherten: Berechtigung DiGA vergeben - Policy Document erstellenSichtbar machen von Dokumenten für alle Leistungserbringerinstitution

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung an DiGA für Aktenkonto vergeben" ein Policy Document für die zu berechtigende DiGA  erstellendem Nutzer ermöglichen, ein oder mehrere ausgewählte für alle Leistungserbringerinstitutionen im ePA-Aktensystem verborgenen Dokumente sichtbar zu machen. [<=]

A_2149724362 - ePA-Frontend des Versicherten: Berechtigung DiGA vergeben - Policy Document hochladenAnzeige von verborgenen Dokumenten für alle Leistungserbringerinstitutionen

Das ePA-Frontend des Versicherten  MUSS im Anwendungsfall "Berechtigung an DiGA für Aktenkonto vergeben" zum Hochladen des Policy Documents in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für Policy Documents ausführendem Nutzer die im ePA-Aktensystem für alle Leistungserbringerinstitutionen verborgenen Dokumente auflisten können. [<=]

6.2.8 DokumentenverwaltungMedical Services

6.2.8.1 Dokumente einstellen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter Dokumente in die ePA hochladen.

A_15464 - ePA-Frontend des Versicherten: Dokumente einstellen - Zugriffsberechtigungen anzeigen und bestätigen

Das ePA-Frontend des Versicherten MUSS, wenn die Option "Dokumente einstellen: Berechtigte anzeigen" aktiv ist, dem Nutzer vor dem Anwendungsfall "Dokumente einstellen" alle für die Dokumente potentiell zugriffsberechtigten Leistungserbringerinstitutionen anzeigen und eine Bestätigung vom Nutzer einholen. [<=]

Die für die Dokumente potentiell zugriffsberechtigten LEI werden mittels der übergreifenden Aktivität "Vergebene Berechtigung bestimmen" ermittelt.

Optional können zusätzlich auch die zugriffsberechtigten Vertreter angezeigt werden. Die Abfrage dient der Kontrolle der vergebenen Zugriffsberechtigungen durch den Nutzer.

Zugriffsberechtigt sind alle Vertreter und alle LEI mit der Berechtigung für vom Versicherten eingestellte Dokumente.

A_15465 - ePA-Frontend des Versicherten: Dokumente einstellen - Hinweis Änderung Zugriffsberechtigungen

Das ePA-Frontend des Versicherten MUSS es ermöglichen, die Anwendungsfälle zum Verwalten von Berechtigungen auszuführen, wenn der Nutzer vor dem Anwendungsfall "Dokumente einstellen" die Zugriffsberechtigungen nicht bestätigt. [<=]XDS Document Service

Es können Dokumente am XDS Document Service eingestellt, gesucht, heruntergeladen und gelöscht werden.

6.2.8.1.1 Dokumente einstellen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein Vertreter Dokumente in die ePA hochladen.

A_15286 - ePA-Frontend des Versicherten: Auswahl von Dokumenten

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, ein oder mehrere Dokumente aus lokal eingebundenem Speicher auszuwählen, um sie in die ePA einzustellen. [<=]

A_15462 - ePA-Frontend des Versicherten: Dokumente einstellen - Eingabe der Metadaten zu Dokumenten

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, zu jedem einzustellenden Dokument Metadaten einzugeben. [<=]

Für Festlegungen zur Eingabe von Metadaten siehe " ".

Das ePA-Frontend des Versicherten kann eine Prüfung der Metadaten auf Vollständigkeit und Korrektheit durchführen und den Nutzer bei fehlenden oder falschen Werten zur Korrektur auffordern.

A_20223-03 - ePA-Frontend des Versicherten: Zusätzliche Auswahl der Kategorie "Dokumente der eGA"

Falls dem ePA-Frontend des Versicherten im kassenspezifischen Teil des FdV eGA-Daten bereitgestellt werden, MUSS das ePA-Frontend des Versicherten dem Nutzer ermöglichen, diese eGA-Dokumente anhand der Vorgaben aus A_19388-* in die ePA hochzuladen. [<=]

A_15458-01 - ePA-Frontend des Versicherten: Dokumente einstellen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 4.2 - Dokumente durch einen Versicherten einstellen" aus [gemSysL_ePA] gemäß TAB_FdV_146 umsetzen.

Tabelle 53: TAB_FdV_146 – Dokumente einstellen

[<=]

Das ePA-Aktensystem unterstützt nur Dokumente mit bestimmten MIME Types. Die initial zulässigen Typen sind in [gemSpec_DM_ePA#A_] beschrieben. Die Dokumentenverwaltung prüft jedes Dokument anhand der Metadaten beim Hochladen der Dokumente und antwortet mit einem Fehler, wenn der Dokumenttyp nicht unterstützt wird.

A_15461-02 - ePA-Frontend des Versicherten: Dokumente einstellen - Prüfung Dateigröße

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente einstellen" die Größe jedes durch den Nutzer ausgewählten Dokuments prüfen und ablehnen, wenn das Dokument die Größe von 25 MB überschreitet. [<=]

Das bedeutet, dass Dokumente bis zu einer Größe von 25 MB = 25 * (1024)^2 Byte in die ePA hochgeladen werden. Grundlage für die Berechnung der Dokumentengröße ist das Dokument ohne Verschlüsselung durch den Dokumentenschlüssel und ohne Transportcodierung. Größere Dokumente können nicht hochgeladen werden.

A_15462 - ePA-Frontend des Versicherten: Dokumente einstellen - Eingabe der Metadaten zu Dokumenten

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, zu jedem einzustellenden Dokument Metadaten einzugeben. [<=]

Für Festlegungen zur Eingabe von Metadaten siehe 5.4.6 Nutzungsvorgaben für IHE ITI XDS-Metadaten .

Das ePA-Frontend des Versicherten kann eine Prüfung der Metadaten auf Vollständigkeit und Korrektheit durchführen und den Nutzer bei fehlenden oder falschen Werten zur Korrektur auffordern.

Das ePA-Aktensystem unterstützt nur Dokumente mit bestimmten MIME Types. Die initial zulässigen Typen sind in A_14760* beschrieben. Der XDS Document Service prüft jedes Dokument anhand der Metadaten beim Hochladen der Dokumente und antwortet mit einem Fehler, wenn der Dokumenttyp nicht unterstützt wird.

A_15463-01 - ePA-Frontend des Versicherten: Dokumente einstellen - Prüfung XDS-Metadaten

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente einstellen" die XDS-Metadaten auf Vollständigkeit prüfen und bei fehlenden oder fehlerhaften Werten den Anwendungsfall abbrechen. [<=]

Zum Verschlüsseln des Dokuments wird dieses mit einem Dokumentenschlüssel symmetrisch verschlüsselt. Der Dokumentenschlüssel wird dann symmetrisch mit dem Aktenschlüssel verschlüsselt. Für Vorgaben zum Verschlüsseln eines Dokuments für das ePA-Aktensystem siehe .A_24707 - ePA-Frontend des Versicherten: Dokumente einstellen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen Dokumente in die Akte einzustellen unter Verwendung der Operation I_Document_Management_Insurant::ProvideAndRegisterDocumentSet-b des XDS Document Service. [<=]

A_21483 - ePA-Frontend des Versicherten: Dokumente einstellen - Kein Einstellen von Ordnern

Das ePA-Frontend des Versicherten DARF im Anwendungsfall "Dokumente einstellen" KEINE neuen Ordner in die Dokumentenverwaltungden XDS Document Service einstellen.
[<=]

A_1546615972-01 - ePA-Frontend des Versicherten: Trennung fachlicher und technischer Dokumente einstellen - Dokument verschlüsselnbeim Upload

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass eine Provide And Register Document Set-b Message entweder ein oder mehrere Versichertendokumente oder genau ein technisches Dokument enthält. [<=]

DasA_16221-01 - ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente einstellen" für jedes zu übermittelnde Dokument die Aktivität "Dokument verschlüsseln" gemäß TAB_FdV_147 umsetzen.: IHE XDS-Transaktion [ITI-41] - Unterstützung MTOM/XOP

Das ePA-Frontend des Versicherten MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-41] zur Übertragung von Dokumenten eine Kodierung mittels MTOM/XOP [MTOM] gemäß [IHE-ITI-TF2x#V.3.6.] verwenden. [<=]

Tabelle 54: TAB_FdV_147 – Dokumente einstellen - Dokument verschlüsseln

[<=]

Die Dokumentenschlüssel dürfen nicht persistent gespeichert werden und müssen nach ihrer Verwendung gelöscht werdenDas ePA-Aktensystem lehnt beim Einstellen von Dokumenten Requests ab, wenn die Summe der Größe der Dokumente in einem Submission Set 250 MB überschreitet. Das ePA-Frontend des Versicherten kann Einstellversuche von Dokumentensets unterbinden, wenn diese von der Dokumentenverwaltung aufgrund der Größenbeschränkung abgelehnt würden.

6.2.8.1.2 Dokumente suchen

Mit diesem Anwendungsfall kann ein Versicherter oder ein Vertreter nach Dokumenten oder Dokumentensets im ePA-Aktensystem auf Basis der XDS-Metadaten der Dokumente suchen. Als Ergebnis der Suchanfrage liefert das ePA-Aktensystem eine Liste von XDS-Metadaten zu Dokumenten.

A_15467-0124706 - ePA-Frontend des Versicherten: Dokumente einstellen - Dokumentenschlüssel löschensuchen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "dem Nutzer ermöglichen Dokumente einstellen" in der Aktivität "Dokument verschlüsseln" erstellte Dokumentenschlüssel nach dem Ende der Aktivität löschenAkte zu suchen unter Verwendung der Operation I_Document_Management_Insurant::RegistryStoredQuery des XDS Document Service. [<=]

Auf Basis der verschlüsselten Dokumente und den durch den Nutzer für jedes Dokument eingegebenen Metadaten wird eine Provide And Register Document Set-b Message für die einzustellenden Versichertendokumente erstellt.

Für Nutzungsvorgaben siehe Kapitel

"Versichertendokumente"

.

A_15468-01 - ePA-Frontend des Versicherten: Dokumente einstellen - Dokumentenset in Dokumentenverwaltung hochladenA_17854-01 - ePA-Frontend des Versicherten: Nutzung des Anfragetyps "FindDocumentsByTitle"

Das ePA-Frontend des Versicherten MUSS den in [ITI-18] nicht enthaltenen zusätzlichen Anfragetyp "FindDocumentsByTitle" mit der Query-ID "urn:uuid:ab474085-82b5-402d-8115-3f37cb1e2405" und denselben Parameternutzungsvorgaben der Registry Stored Query "FindDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.1] in Verbindung mit dem zusätzlich zu [ITI-18] eingeführten Suchparameter $XDSDocumentEntryTitle sowie dem optionalen Parameter $XDSDocumentEntryAuthorInstitution nutzen können. [<=]

A_25190 - ePA-Frontend des Versicherten: Nutzung des Anfragetyps "FindDocumentsByComment"

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente einstellen" zum Hochladen des Dokumentenset in die Dokumentenverwaltung die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung hochladen" mit einer Provide And Register Document Set-b Message für Versichertendokumente ausführenden in [ITI-18] nicht enthaltenen zusätzlichen Anfragetyp "FindDocumentsByComment" mit der Query-ID "urn:uuid:2609dda5-2b97-44d5-a795-3e999c24ca99" und denselben Parameternutzungsvorgaben der Registry Stored Query "FindDocuments" gemäß [IHE-ITI-TF2a#3.18.4.1.2.3.7.1] in Verbindung mit dem zusätzlich zu [ITI-18] eingeführten Suchparameter $XDSDocumentEntryComment nutzen können. [<=]

6.2.8.2 Dokumente suchen

Mit diesem Anwendungsfall kann ein Versicherter oder ein berechtigter Vertreter nach Dokumenten oder Dokumentensets im ePA-Aktensystem auf Basis der XDS-Metadaten der Dokumente suchen. Als Ergebnis der Suchanfrage liefert das ePA-Aktensystem eine Liste von XDS-Metadaten zu DokumentenDer zusätzliche Parameter "$XDSDocumentEntryTitle" filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.title. Dabei ist die Angabe von Platzhaltern (wie für Suchanfragen über den Parameter $XDSDocumentEntryAuthorPerson) möglich, die sich verhält wie das SQL Schlüsselwort "LIKE" in Kombination mit den anzugeben Wildcard-Zeichen "%", um jedes beliebige Zeichen und "_", um ein einzelnes beliebiges Zeichen zu finden.

Der optionale Parameter "$XDSDocumentEntryAuthorInstitution" filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.authorInstitution.

A_15469 - ePA-Frontend des Versicherten: Suchparameter für Dokumente

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Suchparameter auf Basis der XDS-Metadaten für eine Suchanfrage einzugeben. Für Suchparameter mit fest vorgegebenem Wertebereich muss der Nutzer eine Auswahlliste nutzen können. [<=]

Folgende Suchanfragen sollen mindestens möglich sein (ggf. mit zusätzlichem Nachfiltern auf dem FdV):

•   Suche nach allen medizinischen Dokumenten im Aktenkonto

•   Suche nach Ersteller bzw. Einstellendem ($XDSSubmissionSetAuthorPerson, $XDSDocumentEntryAuthorPerson, $XDSDocumentEntryAuthorInstitution siehe   und A_17854-*)

•   Suche nach in einem Zeitraum erstellten bzw. eingestellten Dokumenten ($XDSDocumentEntryCeationTimeFrom/To / $XDSSubmissionSetSubmissionTimeFrom/To)

•   Suche nach Dokumententitel (siehe [gemSpec_Dokumentenverwaltung#A_17185] und A_17854-*)

•   Suche nach durch LEIs bereitgestellte Dokumente

•   Suche nach Dokumenten mit Kennzeichnung "Versicherteninformation"(siehe [gemSpec_DM_ePA#A_14986])

•   Suche nach durch Krankenkassen bereitgestellte Informationen

•   Suche nach Dokumenten im DocumentEntry.availabilityStatus "Deprecated" oder "Approved"

•   Suche nach durch DiGA bereitgestellten Dokumenten

A_15470-01 - ePA-Frontend des Versicherten: Dokumente suchen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 4.4 - Dokumente durch einen Versicherten suchen" aus [gemSysL_ePA] gemäß TAB_FdV_148 umsetzen.

Tabelle 55: TAB_FdV_148 – Dokumente suchen

[<=]

A_15471-01 - ePA-Frontend des Versicherten: Dokumente suchen - Suchanfrage ausführen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente suchen" zum Ausführen der Suchanfrage die übergreifende Aktivität "Suche nach Dokumenten in Dokumentenverwaltung" mit einer query:AdhocQueryRequest_Message entsprechend der von Nutzer vorgegebenen Suchkriterien ausführen. [<=]

Das Ergebnis der Suche soll für den Nutzer sortierbar und filterbar dargestellt werden.

A_15472 - ePA-Frontend des Versicherten: Ergebnisliste Dokumente anzeigen

Das ePA-Frontend des Versicherten MUSS dem Nutzer das Ergebnis der Suche nach Dokumenten anzeigen. [<=]

A_21134-01 - ePA-Frontend des Versicherten: Unscharfe Ergebnisse in Ergebnisliste kennzeichnen

Das ePA-Frontend des Versicherten SOLL etwaige unscharfe Suchergebnisse (siehe gemSpec_Dokumentenverwaltung#A_21132Aktensystem_ePAfuerAlle#A_24764*) in der Ergebnismenge als solche kennzeichnen können.
[<=]

A_15473-01 - ePA-Frontend des Versicherten: Ergebnisliste Dokumente drucken oder speichern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, das Ergebnis der Suche nach Dokumenten auszudrucken oder lokal zu speichern. [<=]

Das lokale Speichern kann im PDF Format angeboten werden.

A_15474 - ePA-Frontend des Versicherten: Suche verfeinern

Das ePA-Frontend des Versicherten MUSS die Ergebnisse einer Suchanfrage zusammen mit den zur Suche verwendeten Parameter anzeigen und es dem Nutzer ermöglichen, die Suchparameter anzupassen und die Suchanfrage erneut auszuführen. [<=]

6.2.8.1.3 Dokument herunterladen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter Dokumente aus dem Aktenkonto zum Anzeigen oder lokalen Speichern herunterladen.

A_15475-01 - ePA-Frontend des Versicherten: Dokumente zum Herunterladen markiereneiner Suchanfrage verarbeiten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Dokumente aus dem Ergebnis einer Suchanfrage zum Herunterladenherunterzuladen (bspw. für die Anzeige oder lokales Speichern) zu markieren. [<=]

A_15476-0124708 - ePA-Frontend des Versicherten: Dokumente herunterladen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 4.10 -dem Nutzer ermöglichen Dokumente durch einen Versicherten anzeigen" aus [gemSysL_ePA] gemäß TAB_FdV_149 umsetzen.

Tabelle 56: TAB_FdV_149 – Dokumente aus Aktenkonto herunterladen

[<=]

A_15477-01 - ePA-Frontend des Versicherten: Dokumente herunterladen - Herunterladen und Entschlüsseln

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente herunterladen" zum Herunterladen und Entschlüsseln der Dokumente die übergreifende Aktivität "Dokumentenset aus Dokumentenverwaltung herunterladen" mit einer RetrieveDocumentSet_Message für alle über die XDS-Metadaten ermittelten Dokument Identifier der ausgewählten Dokumente ausführenaus der Akte herunterzuladen unter Verwendung der Operation I_Document_Management_Insurant::RetrieveDocumentSet des XDS Document Service. [<=]

A_23620-01 - ePA-Frontend des Versicherten: Information des Versicherten bei fehlerhaften medizinischen Dokumenten

Das ePA-Frontend des Versicherten MUSS den Nutzer mit einer Fehlermeldung informieren, wenn nach dem Download aus dem Aktensystem technisch fehlerhafte medizinische Dokumente bzw. Teildokumente einer Sammlung erkannt werden. Sofern es sich um eine fehlerhaftes Teildokument einer Sammlung handelt, MÜSSEN die korrekten Teildokumente der Sammlung trotzdem angezeigt werden. [<=]

A_15478 - ePA-Frontend des Versicherten: Dokument lokal speichern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, ein aus dem Aktenkonto heruntergeladenes Dokument im lokalen Speicher persistent abzulegen. [<=]

A_15479 - ePA-Frontend des Versicherten: Dokument mit Standardprogramm anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, wenn für einen gegebenen Dateitypen ein Standardprogramm verfügbar ist, ein aus dem Aktenkonto heruntergeladenes Dokument mit dem Standardprogramm anzuzeigen. [<=]

6.2.8A_16222-02 - ePA-Frontend des Versicherten: IHE XDS-Transaktion [ITI-43] - MTOM unterstützen

Das ePA-Frontend des Versicherten MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-43] die Übertragung von Dokumenten mit MTOM/XOP [MTOM] unterstützen. [<=]

6.2.8.1.4 Dokumente im Aktenkonto löschen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter Dokumente im Aktenkonto löschen. Die Dokumente sind damit unwiederbringlich aus dem ePA-Aktensystem entfernt.

A_15480 - ePA-Frontend des Versicherten: Dokumente zum Löschen markieren

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Dokumente aus dem Ergebnis einer Suchanfrage zum Löschen zu markieren. [<=]

A_15482 - ePA-Frontend des Versicherten: Dokumente löschen - Bestätigung

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Dokumente löschen" vom Nutzer eine Bestätigung einholen, dass die markierten Dokumente gelöscht werden sollen und die Möglichkeit geben, das Löschen abzubrechen. [<=]

A_15481-0124709 - ePA-Frontend des Versicherten: Dokumente löschen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 4.8 -dem Nutzer ermöglichen Dokumente durch einen Versichertenin der Akte zu löschen" aus [gemSysL_ePA] gemäß TAB_FdV_150 umsetzen. unter Verwendung der Operation I_Document_Management_Insurant::RemoveMetadata des XDS Document Service. [<=]

Tabelle 57: TAB_FdV_150 –A_20722-01 - ePA-Frontend des Versicherten: Dokumente löschen – Hinweis auf mögliche versorgungsrelevante Folgen

Das ePA-Frontend des Versicherten MUSS dem Nutzer im Anwendungsfall "Dokumente löschen" vor dem Löschen von Dokumenten in der elektronischen Patientenakte einen Hinweis darauf geben, dass das Löschen von Dokumenten Auswirkungen auf die Versorgung und die Patientensicherheit haben kann. [<=]

A_15483-0324353 - ePA-Frontend des Versicherten: Dokumente löschen - Löschnachricht Dokumentenverwaltung– Hinweis auf löschen

Das ePA-Frontend des Versicherten MUSS dem Nutzer im Anwendungsfall "Dokumente löschen" zumvor dem Löschen der Dokumente die übergreifende Aktivität "Dokumentenset in Dokumentenverwaltung löschen" mit einer RemoveMetadata_Message für alle über die XDS-Metadaten ermittelten Dokument Identifier (entryUUIDs) der ausgewählten Dokumente ausführenvon Dokumenten in der elektronischen Patientenakte auf die Möglichkeit des Verbergens von Dokumenten und Datenkategorien hinweisen. [<=]

Hinweis: Es reicht aus, dass der Hinweis auf verbergen nur ein Mal während einer laufenden User-Session angezeigt wird.

6.2.8.1.5 Metadaten von Dokumenten ändern

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein befugter Vertreter die Metadaten von Dokumenten in der ePA ändern. Es dürfen ausschließlich Metadaten gemäß A_15083* am ePA-FdV durch ein Metadaten-Update geändert werden.

A_24198 - ePA-Frontend des Versicherten: Aktualisierung von Metadaten

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen Metadaten von Dokumenten zu ändern unter Verwendung der Operation I_Document_Management_Insurant::RestrictedUpdateDocumentSet des XDS Document Service.
[<=]

Beim Aufruf von I_Document_Management_Insurant::RestrictedUpdateDocumentSet muss immer für "previousVersion" in der Nachricht der Wert "1" angegeben werden, da der Aufruf seitens des XDS Document Service nicht für eine echte Versionierung der alten Dokumentenmetadaten genutzt wird. Serverseitig wird DocumentEntry.version entsprechend nicht verwaltet und besitzt standardmäßig deshalb immer den impliziten Wert 1.

Das ePA-Akensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung für Versicherte und Vertreter durch, siehe  . Das ePA-Frontend des Versicherten unterstützt den Nutzer dabei,

A_25132 - ePA-Frontend des Versicherten: Berücksichtigung der Legal Policy bei der Aktualisierung von Metadaten

Das ePA-Frontend des Versicherten MUSS bei der Aktualisierung von Metadaten die Legal Policy aus [ ] beachten. Daraus folgt, dass dem Nutzer nur Dokumente zur Aktualisierung von Metadaten angezeigt werden, die gemäß der Legal Policy durch den Nutzer geändert werden dürfen. [<=]

A_20722 - ePA-Frontend des Versicherten: Dokumente löschen – Hinweis auf mögliche versorgungsrelevante FolgenEine Änderung von Metadaten führt zu einer erneuten Prüfung der bestehenden Zuordnung des Dokuments im Aktensystem und kann somit eine andere Zuordnung zu einer Datenkategorie zur Folge haben.

6.2.8.2 Medication Service

Die elektronische Medikationsliste (eML) wird im ePA-Aktensystem durch den Medication Service umgesetzt.

Ein Nutzer des FdV kann die in seinem Aktenkonto gespeicherte Medikationsliste einsehen. Es gibt verschiedene Formen in welcher die Medikationsliste abgerufen werden kann entweder über das  FHIR API, die Liste im Format pdf oder als xhtml zur Anzeige im Browser.

A_24947 - ePA-Frontend des Versicherten: Medikationsliste (FHIR-Schnittstelle) anzeigen

Das ePA-Frontend des Versicherten KANN es dem Nutzer ermöglichen für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung von [I_Medication_Service_FHIR] die Medikationsliste oder deren Details anzuzeigen bzw. nach Details zu suchen. [<=]

Das Rendering der FHIR-Daten für die Anzeige erfolgt bei Abfrage der FHIR-Schnittstelle durch das FdV.

A_24949 - ePA-Frontend des Versicherten MUSS dem Nutzer im Anwendungsfall "Dokumente löschen" vor dem Löschen von Dokumenten in der elektronischen Patientenakte auf die möglichen versorgungsrelevanten Folgen hinweisen: Medikationsliste (durch das Aktensystem gerendert) anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Medikationsliste für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung von [I_Medication_Service_eML_Render] anzuzeigen.  [<=]

A_25174 - ePA-Frontend des Versicherten: Medikationsliste anzeigen bei Widerspruch

Falls der Versicherte der Teilnahme am digital gestützten Medikationsprozess widersprochen („medication = deny“) und dem Einstellen von Verordnungsdaten und Dispensierinformation durch den E-Rezept-Fachdienst nicht widersprochen hat („erp-submission = permit“), MUSS das ePA-FdV dem Versicherten beim Aufruf der elektronischen Medikationsliste (eML) erkenntlich machen, dass die eML aufgrund des derzeitigen Widerspruchs durch Leistungserbringer nicht eingesehen und zur Behandlung des Versicherten genutzt werden kann. [<=]

6.2.9 Protokollverwaltung

6.2.9.1 Zugriffsprotokoll einsehen

Bei der Nutzung eines Aktenkontos durch LEI, durch berechtigte Vertreter oder den Aktenkontoinhaberverschiedene Akteure werden Aktivitäten protokolliert, damit der Aktenkontoinhaber oder ein berechtigter Vertreter diese Aktivitäten nachvollziehen kann. Dazu zählen Zugriffe auf die Dokumente und seine Metadaten (§ 291a-konformes Zugriffsprotokoll) sowie auch Aktivitäten mit administrativem Charakter (Verwaltungsprotokoll).

Die verschiedenen Aktivitäten sind in [gemSpec_DM_ePA#A_14505-*] gelistet. 

. Die Protokolldaten des § 291a-konformen Zugriffsprotokolls werden im Aktenkonto (Komponente Dokumentenverwaltung) abgelegt. Die Protokolldaten des Verwaltungsprotokolls werden in verschiedenen Komponenten des ePA-Aktensystems vorgehalten. Die Daten müssen für eine Anzeige separat abgefragt werden.

und müssen für eine Anzeige unter Nutzung des Audit Event Service abgefragt werden.
Mit diesem Anwendungsfall kann ein Versicherter bzw. ein berechtigter Vertreter die Protokolldaten über die Zugriffe auf das Aktenkonto des Versicherten einsehen.

Die Protokolleinträge werden im Aktensystem nach Ablauf der in [gemSpec_ePA_FdV#A_19051] beschriebenen Frist gelöscht.

A_15485-01A_24698 - ePA-Frontend des Versicherten: Protokolldaten einsehen

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "UC 6.1 -es dem Nutzer ermöglichen die Protokolldaten durch einen Versicherten einsehen" aus [gemSysL_ePA] gemäß TAB_FdV_151 umsetzen.

Tabelle 58: TAB_FdV_151 – Protokolldaten einsehen

[<=]

A_15486-01 - ePA-Frontend des Versicherten: Protokoll einsehen - Dokumentenverwaltung abfragen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Protokolldaten einsehen" die Aktivität "Protokolldaten Dokumentenverwaltung abfragen" gemäß TAB_FdV_152 umsetzen.

Tabelle 59: TAB_FdV_152 – Protokolldaten einsehen - Dokumentenverwaltung abfragen

[<=]

A_22331 - ePA-Frontend des Versicherten: Protokoll einsehen - mehrere ParticipantObjectIdentification-Tags innerhalb einer AuditMessage

Das ePA-Frontend des Versicherten MUSS zusammengefasste Protokolleinträge mit mehreren ParticipantObjectIdentification-Elementen innerhalb einer AuditMessage verarbeiten und zur Anzeige bringen könnenfür sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung von [I_Audit_Event] einzusehen. [<=]

A_15487-0124699 - ePA-Frontend des Versicherten: Protokoll einsehen - Autorisierung abfragen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Protokolldaten einsehen" die Aktivität "Protokolldaten Autorisierung abfragen" gemäß TAB_FdV_153 umsetzen.

Tabelle 60: TAB_FdV_153 – Protokolldaten einsehen - Autorisierung abfragen

[<=]

A_15488-01 - ePA-Frontend des Versicherten: Protokoll einsehen - Authentisierung abfragen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Protokolldaten einsehen" die Aktivität "Protokolldaten Authentisierung abfragen" gemäß TAB_FdV_154 umsetzen.

Tabelle 61: TAB_FdV_154 – Protokolldaten einsehen - Zugangsgateway des Versicherten abfragen

[<=]

Die Ergebnisse der Abfragen an die Komponenten des ePA-Aktensystems werden vereint.

A_21312 - ePA-Frontend des Versicherten: Suchparameter beim Protokollabruf

Das ePA-Frontend des Versicherten SOLL beim Abruf von Protokolldaten von den Komponenten ePA-Dokumentenverwaltung, Authentisierung und Autorisierung Parameter für den seitenweisen Abruf gemäß [gemSpec_Aktensystem#A_21303-*] verwenden.
Protokolldaten filtern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen die Protokolldaten für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden zu filtern unter Verwendung von [I_Audit_Event]. [<=]

A_1549023547-01 - ePA-Frontend des Versicherten: Erweiterte-Anzeige fürder Protokolldaten

Das ePA-Frontend des Versicherten MUSS einem Nutzer alle Protokolleinträge der vom ePA-Aktensystem für die Akte des Versicherten erstellten Protokolle (§ 291a-konformes Zugriffsprotokoll und Verwaltungsprotokolle der Komponenten) übersichtlich anzeigen können. [<=]

A_23547 - ePA-Frontend des Versicherten: eigene displayNames für die Anzeige der Protokolldaten

Das ePA-Frontend des Versicherten KANN für die Anzeige der Protokolleinträge eigene, auch für Nutzer ohne technisches Vorwissen oder spezifisches ePA-Wissen verständliche Beschreibungen (displayNames) anstelle der Inhalte des Prokollfeldes "Aufgerufene Operation/@displayName"Protokolleintrages verwenden. [<=]

A_15491-02 - ePA-Frontend des Versicherten: Felder Protokolldaten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, alle Felder (der Protokollattribute) der Protokolleinträge gemäß [gemSpec_DM_ePA#A_14471-*] darzustellen. Die gewählten Bezeichnungen der Felder der Protokolleinträge in der Anzeige MÜSSEN auch für Nutzer ohne technisches Vorwissen oder spezifisches ePA-Wissen verständlich sein.
[<=]

Das FdV kann es dem Nutzer über einen Link in der Anzeige ermöglichen, das referenzierte Dokument direkt herunterzuladen.

Die Protokolldaten sollen für den Nutzer sortierbar und filterbar dargestellt werden. Der Nutzer soll die Protokolldaten durchsuchen können.

Das ePA-Frontend des Versicherten kann Protokolleinträge für einen Nutzer übersichtlich anordnen oder einzelne Felder in der Anzeige ausblenden. Es muss einem Nutzer jedoch ermöglicht werden, alle Protokolleinträge und alle Protokollfelder einzusehen. 

A_15495-01 - ePA-Frontend des Versicherten: Protokolldaten lokal speichern

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Protokolldaten lokal im Format AuditEventList aus der getAuditEvents Response abzuspeichernvom Audit Event Service abgerufenen Protokolldaten lokal zu speichern. [<=]

A_15496-01 - ePA-Frontend des Versicherten: lokal gespeicherte Protokolldaten anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die lokal abgespeicherten Protokolldaten einzulesen und anzuzeigen. 
[<=]

6.2.10 Verwaltung eGKGeräteverwaltung

6.2.10.1 PIN der eGK ändern

Mit diesem Anwendungsfall kann der Nutzer das Geheimnis der PIN einer eGK ändern.Die Geräteverwaltung erfolgt im ePA-Aktensystem durch den Device Management Service.

A_24792 - ePA-Frontend des Versicherten: registrierte Geräte anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die für den Nutzer registrierten Geräte unter Verwendung der Operation getAllDevices gemäß [I_Device_Management_Insurant] zu ermitteln und einschließlich des aktuellen Status anzuzeigen. [<=]

A_15497-0124802 - ePA-Frontend des Versicherten: PIN der eGKAnzeigename für registriertes Gerät ändern

Das ePA-Frontend des Versicherten  MUSS den Anwendungsfall "PIN der eGK ändern" gemäß TAB_FdV_156 umsetzen.es dem Nutzer ermöglichen, den Anzeigenamen eines für den Nutzer registrierten Gerätes unter Verwendung der Operation updateDevice gemäß [I_Device_Management_Insurant] zu ändern. [<=]

Tabelle 62: TAB_FdV_156 – PIN der eGK ändern

Tabelle 63: TAB_FdV_157 – Ablaufaktivitäten – PIN der eGK ändern

[<=]

Abbildung 11: Aktivitätsdiagramm "PIN der eGK ändern"

6.2.10.2 PIN der eGK entsperren

Mit diesem Anwendungsfall kann der Nutzer den gesperrten PIN einer eGK mit der PUK entsperren.

A_15498-01 - ePA-Frontend des Versicherten: PIN der eGK entsperren

Das ePA-Frontend des Versicherten MUSS den Anwendungsfall "PIN der eGK entsperren"  gemäß TAB_FdV_158 umsetzen.

Tabelle 64: TAB_FdV_158 – PIN der eGK entsperren

Tabelle 65: TAB_FdV_159 – Ablaufaktivitäten – PIN der eGK entsperren

[<=]

Abbildung 12: Aktivitätsdiagramm "PIN der eGK entsperren"

6.2.11 Geräteverwaltung

6.2.11.1 Benachrichtigungsadresse für Geräteautorisierung aktualisieren

Um ein Gerät mit dem FdV für den Zugriff auf ein Aktenkonto zu autorisieren, muss der Nutzer dieses über einen separaten Benachrichtigungskanal (E-Mail mit Freischalt-Link) bestätigen. Die E-Mail wird an die im Aktenkonto hinterlegte Benachrichtigungsadresse des Nutzers gesendet.

Für den Aktenkontoinhaber wird die Benachrichtigungsadresse initial im Rahmen der Kontoeröffnung hinterlegt. Für Vertreter erfolgt die initiale Hinterlegung der Benachrichtigungsadresse während der Vergabe der Zugriffsberechtigung.

Der Anwendungsfall "Benachrichtigungsadresse für Geräteautorisierung aktualisieren" gibt dem Nutzer die Möglichkeit eine neue Benachrichtigungsadresse im Aktenkonto zu hinterlegen.

A_15499 - ePA-Frontend des Versicherten: Benachrichtigungsadresse erfassen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine Benachrichtigungsadresse für die Geräteautorisierung einzugeben. [<=]

A_15500-01 - ePA-Frontend des Versicherten: Benachrichtigungsadresse aktualisieren

Das ePA-Frontend des Versicherten MUSS das Hinterlegen der Benachrichtigungsadresse im ePA-Aktensystem gemäß TAB_FdV_160 umsetzen.

Tabelle 66: TAB_FdV_160 – Benachrichtigungsadresse aktualisieren

[<=]

6.2.11.2 Benachrichtigungsadressen abfragen

Bei der Einrichtung eines Vertreters wird dessen Benachrichtigungsadresse im AS hinterlegt. Die Schnittstelle GetNotificationInfo wird durch den Versicherten dafür genutzt, diese Benachrichtigungsadresse vom AS abfragen zu können, insbesondere im Rahmen des Aktenwechsels oder zur Prüfung, ob eine Korrektur der Benachrichtigungsadresse des Vertreters erforderlich ist.

A_21254-02 - ePA-Frontend des Versicherten: Benachrichtigungsadresse abfragen

Das ePA-Frontend des Versicherten MUSS das Abfragen einer Benachrichtigungsadresse im ePA-Aktensystem gemäß TAB_FdV_161 Benachrichtigungsadresse abfragen umsetzen 

I_Authorization_Management_Insurant:: getNotificationInfo Request erstellen	Eingangsparameter:  •   AuthenticationAssertion aus Session-Daten •   RecordIdentifier aus Session-Daten •   DeviceID aus Gerät-Daten •   ActorID des Nutzers, dessen Benachrichtigungskanal zu ermitteln ist. Bei fehlender ActorID wird eine Liste aller Benachrichtigungskanäle zurück gegeben.
I_Authorization_Management_Insurant:: getNotificationInfo Response verarbeiten	NotificationInfoList =  Liste der abgefragten Benachrichtigungskanäle (ActorID, Benachrichtigungsadresse) oder gematik Fehlermeldung

[<=]

6.3 Realisierung der Leistungen der TI-Plattform

Der Produkttyp ePA-Frontend des Versicherten realisiert die von den Fachanwendungen benötigten Leistungen der TI-Plattform, die in den fachlichen Anwendungsfällen der ePA genutzt werden. Die durch die TI-Plattform bereitgestellten Leistungen umfassen einen für die Fachanwendungen einheitlichen Zugriff auf die eGK des Versicherten, Leistungen der PKI der Telematikinfrastruktur, kryptographische Operationen, etc. die in übergreifenden Spezifikationen der gematik festgelegt sind. Die Definition der Leistungen der TI-Plattform im ePA-Frontend des Versicherten finden sich in [gemSpec_Systemprozesse_dezTI].

Das ePA-Frontend des Versicherten verwendet u.a. die in der Tabelle TAB_FdV_177 dargestellten Plattformleistungen.

Tabelle 67: TAB_FdV_177 – Verwendete Plattformleistungen

In den folgenden Abschnitten wird festgelegt, wie umgebungsspezifische Operationen an der Schnittstelle zu den Leistungen der TI-Plattform umgesetzt werden sollen.

6.3.1 Transportschnittstelle für Kartenkommandos

Der hier beschriebene Produkttyp ePA-Frontend des Versicherten ist als reines Softwareprodukt konzipiert. Als solches muss das ePA-Frontend des Versicherten eine Schnittstelle zur eGK über ein Kartenterminal herstellen. Diese Schnittstelle muss die von den Plattformprozessen erzeugten, kartenverständlichen APDUs an die Karte übertragen und wird im Folgenden als ENV_TUC_CARD_APDU_TRANSPORT bezeichnet. Neben proprietären Schnittstellentreibern von Kartenterminalherstellern existieren eine Reihe standardisierter Schnittstellen, die auch von verschiedenen Betriebssystemen zur Anbindung handelsüblicher Kartenterminals unterstützt werden.

A_15501-01 - ePA-Frontend des Versicherten: Transportschnittstelle für Kartenkommandos

Das ePA-Frontend des Versicherten SOLL eine Transportschnittstelle für die Übertragung von SmartCard-APDUs gegen die Standards CT-API und PCSC implementieren. [<=]

Von der Anforderung A_15501-* darf abgewichen werden, wenn die Umsetzung technisch nicht möglich ist (bspw. durch die fehlende Unterstützung der NFC-Schnittstelle bei Herstellern mobiler Endgeräte).

Das ePA-Frontend des Versicherten kann ergänzend eine Transportschnittstelle für die Übertragung von SmartCard-APDUs auf Basis des SICCT-Protokolls, gegen den Standard CCID oder gegen proprietäre Hardwaretreiber eines Kartenterminalherstellers implementieren.

A_15502 - ePA-Frontend des Versicherten: Handbuch: Liste unterstützter Kartenterminals

Der Hersteller des ePA-Frontend des Versicherten MUSS im Handbuch ausweisen, welche Standards und Schnittstellen zu Kartenterminals sein Produkt unterstützt und MUSS eine Liste mit handelsüblichen Kartenterminals angeben, die mit seinem Produkt funktionieren. [<=]

Es können Kartenterminalvarianten der Sicherheitsklassen 1 (reine Kontaktiereinheit) zum Einsatz kommen. Es sollen bevorzugt Kartenterminalvarianten der Sicherheitsklassen 2 (Kartenterminal mit eigenem PIN-Pad) oder 3 (PIN-Pad plus Display) verwendet werden. Zusätzlich ist die Ausstattung des eingesetzten Kartenterminals (Klasse 1, 2 oder 3) mit einer NFC-Schnittstelle möglich. Das ePA-Frontend des Versicherten muss die von den Varianten gebotenen Features geeignet nutzen.

A_21828 - ePA-FdV für Desktop-Plattformen: Unterstützung von Kartenlesern ab Sicherheitsklasse 2

Das ePA-Frontend des Versicherten für Desktop-Plattformen MUSS es dem Nutzer ermöglichen, das ePA-Frontend des Versicherten mit einem Kartenleser einer höheren Sicherheitsklasse als Sicherheitsklasse 1 (Sicherheitsklasse 2 oder höher) zu nutzen [<=]

A_15503 - ePA-Frontend des Versicherten: PIN-Eingabe nicht speichern

Das ePA-Frontend des Versicherten DARF ein eingegebenes PIN-Geheimnis NICHT temporär und NICHT persistent speichern. [<=]

A_15504-01 - ePA-Frontend des Versicherten: PIN-Geheimnis ausschließlich an Karte übermitteln

Das ePA-Frontend des Versicherten und das ePA-Frontend des Versicherten MÜSSEN sicherstellen, dass das eingegebene PIN-Geheimnis ausschließlich an die Karte und nicht an andere Adressaten übermittelt wird. [<=]

Das temporäre Speichern bezieht sich bei der Verwendung eines Kartenterminals der Sicherheitsklasse 1 auf das Verwenden der PIN über den Anwendungsfall hinaus, für den die PIN-Eingabe erfolgt ist, z.B. Caching während einer Sitzung. Gelangt das ePA-Frontend des Versicherten bei der Verwendung eines Kartenterminals der Sicherheitsklassen 2 und 3 ggfs. durch Fehlkonfiguration in Kenntnis der PIN, darf es diese ebenfalls weder temporär noch persistent speichern.

6.3.1.1 Kartenterminals der Sicherheitsklasse 1

Kartenterminals der Sicherheitsklasse 1 verfügen über keine Sicherheitsmerkmale, sie sind eine reine Kontaktiereinheit einer SmartCard. Sämtliche Geheimnis-Eingaben und Hinweistext-Ausgaben müssen über das FdV mittels Bildschirm und Tastatur/Maus erfolgen.

A_21829 - ePA-FdV für Desktop-Plattformen: Hinweis bei Kartenlesern der Sicherheitsklasse 1

Falls das ePA-Frontend des Versicherten für Desktop-Plattformen mit einem Kartenleser der Sicherheitsklasse 1 genutzt wird, MUSS das ePA-Frontend des Versicherten für Desktop-Plattformen den Nutzer in einer für den Nutzer verständlichen Form darauf hinzuweisen,

•   dass Kartenleser der Sicherheitsklasse 1 geringere Sicherheitsleistungen als Kartenleser der Sicherheitsklassen 2 oder 3 erbringen und welche handelsüblichen Kartenleser der Sicherheitsklassen 2 und 3 vom Nutzer am ePA-Frontend des Versicherten für Desktop-Plattformen genutzt werden könnten,

•   welche Risiken bei einer Nutzung von Kartenlesern der Sicherheitsklasse 1 für den Nutzer bestehen und welche Maßnahmen der Versicherte auf seinem Gerät treffen sollte, um diese Risiken zu verringern.

Das ePA-Frontend des Versicherten für Desktop-Plattformen MUSS es dem Nutzer ermöglichen, auf die Anzeige des Hinweises bei einer zukünftigen Nutzung des Kartenlesers der Sicherheitsklasse 1 zu verzichten, sofern der Nutzer dies explizit bestätigt und die Bestätigung so gestaltet ist, das eine versehentliche Bestätigung vermieden wird.
[<=]

A_15505-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe

Das ePA-Frontend des Versicherten MUSS, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, die PIN-/PUK-Eingabe über ein angeschlossenes Eingabegerät entgegennehmen und in ein an die Karte adressiertes Kommando einbetten. [<=]

A_15506 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Geheimnis

Das ePA-Frontend des Versicherten DARF, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, die eingegebene PIN/PUK Ziffernfolge NICHT im Klartext auf dem Bildschirm darstellen. [<=]

A_15507 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Eingabefeedback

Das ePA-Frontend des Versicherten MUSS, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, ein eingegebenes Zeichen einer Geheimniseingabe mit dem Zeichen "*" (Wildcard) quittieren. [<=]

A_15508-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Validierung

Das ePA-Frontend des Versicherten MUSS, wenn das Geheimnis durch einen Anwendungsfall geändert werden soll und wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, ein eingegebenes, neues PIN-Geheimnis durch eine erneute Abfrage des neuen PIN-Geheimnisses verifizieren. [<=]

6.3.1.2 Kartenterminals der Sicherheitsklasse 2

Kartenterminals der Sicherheitsklasse 2 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses. Typischerweise werden Kartenterminals der Sicherheitsklasse 2 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

A_15509-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 2: PIN-Eingabe

Das ePA-Frontend des Versicherten MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 2 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

A_15510-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 2: PIN-Eingabe Fehlkonfiguration

Das ePA-Frontend des Versicherten MUSS alle Operationen mit einer eindeutigen Fehlermeldung abbrechen, in denen es die Kenntnis eines PIN/PUK-Geheimnisses erlangt, nachdem dieses an einem PIN-Pad eines Kartenterminals der Sicherheitsklasse 2 eingegeben wurde. [<=]

A_15511 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 2: PIN-Eingabe Eingabefeedback

Das ePA-Frontend des Versicherten MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 2 einen Benutzerhinweis zur PIN-Eingabe am Kartenterminal an der Bildschirmausgabe ausgeben. [<=]

6.3.1.3 Kartenterminals der Sicherheitsklasse 3

Kartenterminals der Sicherheitsklasse 3 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses und Ausgabeschnittstelle zur Anzeige kurzer Textmeldungen. Typischerweise werden Kartenterminals der Sicherheitsklasse 3 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

Während des Wartens auf eine Benutzereingabe kann ein an das Kartenterminal übergebener Text angezeigt werden. Einzelne Eingaben durch einen Benutzer werden in der Regel durch das Zeichen "*" quittiert. Ebenso besitzen Kartenterminals der Sicherheitsklasse 3 meist zusätzliche Logik, z.B. Eingaben zu verifizieren (siehe Anforderungen zum Ändern einer PIN mittels Klasse 1-Kartenterminal). Auf diese Logik soll hier nicht weiter eingegangen werden.

A_15512-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 3: PIN-Eingabe

Das ePA-Frontend des Versicherten MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 3 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

A_15513-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 3: PIN-Eingabe Fehlkonfiguration

Das ePA-Frontend des Versicherten MUSS alle Operationen mit einer eindeutigen Fehlermeldung abbrechen, in denen es die Kenntnis eines PIN/PUK-Geheimnisses erlangt, nachdem dieses an einem PIN-Pad eines Kartenterminals der Sicherheitsklasse 3 eingegeben wurde. [<=]

A_15514-01 - ePA-Frontend des Versicherten: Kartenterminal der Sicherheitsklasse 3: PIN-Eingabe Eingabefeedback

Das ePA-Frontend des Versicherten MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 3 einen Benutzerhinweis zur PIN-Eingabe am Display des Kartenterminals ausgeben. [<=]

Die Anzeige eines Benutzerhinweises soll den Nutzer informieren zu welchem Zweck eine Eingabe getätigt (z.B. alte PIN, neue PIN im Anwendungsfall PIN ändern) und welches konkrete Geheimnis abgefragt werden soll (PIN, PUK).

6.3.2 Schnittstelle für PIN-Operationen und Anbindung der eGK

Anwendungsfälle zur PIN-Verwaltung, das Login sowie weitere Anwendungsfälle können die Eingabe eines PIN- oder PUK-Geheimnisses durch den Versicherten erfordern. Der Zugriff auf die eGK erfolgt über die Systemprozesse PL_TUC_CARD_*. Das FdV als Realisierungsumgebung der Systemprozesse muss ihrerseits die von der Plattform geforderten Schnittstellen ENV_TUC_CARD_SECRET_INPUT implementieren, um die Kommunikation der Plattform mit dem Nutzer über die Außenschnittstelle des FdV zu ermöglichen. Die Außenschnittstelle ist in Kapitel "6.3.1 Transportschnittstelle für Kartenkommandos" beschrieben und umfasst das Kartenterminal, Eingabemedium und Hinweistexte an den Nutzer. Diese kann je nach Konfiguration an einem Gerät als Kartenterminal der Sicherheitsklasse 3 oder auch eine Kombination aus Bildschirmausgabe, Kartenterminal-PIN-Pad und/oder Tastatureingabe erfolgen.

A_15515-01 - ePA-Frontend des Versicherten: Übergabeschnittstelle PIN/PUK-Geheimnis

Das ePA-Frontend des Versicherten MUSS eine Operation ENV_TUC_SECRET_INPUT zur Eingabe eines PIN/PUK-Geheimnisses und Weiterleitung an eine SmartCard mit den Parametern

•   Eingangsparameter:

o   Identifikator

o   Aktion

o   minLength

o   maxLength

o   commandApduPart

•   Rückgabewerte:

o   responseApdu

implementieren. [<=]

A_15516-01 - ePA-Frontend des Versicherten: Umsetzung der Operation ENV_TUC_SECRET_INPUT

Das ePA-Frontend des Versicherten MUSS die Abbildung der Eingangsparameter auf die Rückgabewerte der Operation ENV_TUC_SECRET_INPUT derart umsetzen, dass

•   die Eingangsparameter Identifikator und Aktion für einen Hinweistext an den Nutzer verwendet werden, welche Aktion auf welchem konkreten Kartenobjekt (z.B. Name einer PIN) durchgeführt wird

•   wenn der Eingangsparameter Aktion die Eingabe eines Nutzerhinweises erfordert, der commandApduPart an der Eingabeschnittstelle um das Geheimnis des Nutzers ergänzt wird

•   der commandApduPart über die Transportschnittstelle für Kartenkommandos an die Karte gesendet wird

und die Antwortnachricht der Karte als responseApdu an den Aufrufer zur Auswertung zurückgegeben wird. [<=]

A_15517-01 - ePA-Frontend des Versicherten: Minimalprinzip Karteninteraktion

Das ePA-Frontend des Versicherten DARF ein Kartenkommando NICHT an eine angebundene Karte weiterleiten, dass nicht explizit im Kontext eines Anwendungsfalls (intendierte Kartenoperationen und Erhöhen des Sicherheitszustands der Karte falls erforderlich) erforderlich ist. [<=]

6.4 Test-App FdV

Für das Zulassungsverfahren des ePA-Frontend des Versicherten muss eine Anwendung (Test-App) mit integriertem ePA-Frontend des Versicherten bereitgestellt werden. Um einen automatisierten Test für das ePA-Frontend des Versicherten zu ermöglichen, muss die Test-App zusätzlich ein Testtreiber-Modul beinhalten, welcher die Funktionalitäten der produktspezifischen Schnittstelle des ePA-Frontend des Versicherten über eine standardisierte Schnittstelle von außen zugänglich macht und einen Fernzugriff ermöglicht.

Abbildung 13: Test-App mit ePA-Frontend des Versicherten und Testtreiber

A_18044-01 - ePA-Frontend des Versicherten: Test-App mit ePA-Frontend des Versicherten und Testtreiber-Modul

Die Test-App des ePA-Frontend des Versicherten MUSS ein Testtreiber-Modul beinhalten, welches die Schnittstellen  I_FdV und I_FdV_Management anbietetA_24803 - ePA-Frontend des Versicherten: registriertes Gerät löschen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, ein aus der Liste der registrierten Geräte ausgewähltes Gerät unter Verwendung der Operation removeOneDevice gemäß [I_Device_Management_Insurant] zu löschern. [<=]

6.2.11 Migration der Akte von ePA 2.6 nach ePA 3.0

Für die Migration der Daten von ePA 2.6 nach ePA 3.0 ist es erforderlich, dass die Chiffrate von Akten- und Kontextschlüssel aus ePA 2.6 mittels SGD entschlüsselt und dem ePA-Aktensystem bereitgestellt werden. Der Hersteller des ePA-Aktensystems definiert das Verfahren und die Schnittstelle für die Migration. Die Migration der Daten kann nur durch den Versicherten, nicht durch einen Vertreter durchgeführt werden.

A_24969 - ePA-Frontend des Versicherten: Akten- und Kontextschlüssel an ePA-Aktensystem übertragen

Das ePA-Frontend des Versicherten muss dem Versicherten die Migration der Daten von ePA 2.6 nach ePA für alle ermöglichen und dabei folgende Schritte umsetzen:

4. Akten- und Kontextschlüssel werden dem Aktensystem ePA für alle bereitgestellt. 
5. Die in ePA 2.6 berechtigten Vertreter werden gemäß A_23968* und A_24399* in ePA für alle befugt.

[<=]

6.3 Testtreiber-Modul für ePA-Frontend des Versicherten

Für die automatisierten Tests des gematik im Kontext von Zulassungsverfahren des ePA-Frontend des Versicherten muss der Hersteller ein Testtreiber-Modul implementieren.  Dieses ist entweder in ein Test-FdV zu integrieren oder es steuert die GUI des ePA-Frontends an. Vom Hersteller ist der gematik der Zugriff auf das Test-FdV bzw. zu testende ePa-Frontend über das Interface des Testtreibermoduls entsprechend [gemKPT_Test# ] zu ermöglichen.

Das Außeninterface des TesttreiberModuls [I_Test_Driver_FdV] wird im Fachportal der gematik und in GitHub als normativer Bestandteil der Spezifikation veröffentlicht.

A_18044-02 - ePA-Frontend des Versicherten: Testtreiber-Modul

Der Hersteller des ePa-Frontend des Versicherten MUSS ein Testtreiber-Modul mit dem Außeninterface laut [I_Test_Driver_FdV] implementieren. Das Testtreiber-Modul MUSS die durch das ePA-Frontend des Versicherten – dem Zulassungsgegenstand – über eine produktspezifische Schnittstelle angebotene Funktionalität nutzen, um die Operationen der Schnittstellen umzusetzen. [<=]

Das Testtreiber-Modul darf die Ausgaben des ePA-Frontend des Versicherten gemäß der technischen Schnittstelle aufarbeiten, aber darf die Inhalte nicht verfälschen.

A_18171 - ePA-Frontend des Versicherten: Keine Fachlogik in Testtreiber-Modul

Das Testtreiber-Modul DARF NICHT die fachliche Logik des ePA-Frontend des Versicherten umsetzen. [<=]

Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren in Test-Apps beschränkt und darf nicht in Wirkbetriebs-Apps genutzt werden.

A_18071 - ePA-Frontend des Versicherten: Beschränkung Einsatz Testtreiber-Modul

Das Frontend des Versicherten DARF ein Testtreiber-Modul NICHT enthalten. [<=]

Die Test-App kann eine GUI anbieten. Diese kann bspw. für die Eingabe der PIN/PUK für die eGK oder die Authentifizierung gegenüber dem Signaturdienst genutzt werden.

Die Test-App muss Fehler, welche von aufgerufenen Systemen gemeldet werden oder bei der internen Verarbeitung auftreten, auf produktspezifische Fehler mappen. Der Hersteller muss die Fehler in der Betriebsdokumentation beschreiben und in einem strukturierten, maschinell verarbeitbarem Dokument übermitteln.

Wenn der Testtreiber einen Eingangsparameter an der Schnittstelle zum ePA-Frontend des Versicherten nicht benötigt, dann kann der Parameter ignoriert werden.

Alle Operationen beinhalten Parameter mit den notwendigen Informationen für ein Login. Diese sollen für ein implizites Login genutzt werden, wenn zu der insurantId noch keine Aktensession besteht.

Die Test-App muss bei Implementierung eines an ein ePA-Aktensystem gekoppeltes FdV sicherstellen, dass im Rahmen von gematik-Tests die Parameter für die Identifikation des zu nutzenden ePA-Aktensystems konfiguriert werden können.

Um Zugriffe aus einer Webanwendung, wie sie durch das AKTOR-Testfrontend zur Verfügung gestellt wird, auf die Testtreiberschnittstelle zu ermöglichen, werden folgende Schnittstelleneigenschaften benötigt:

Die Test-App kann die Testtreiberschnittstelle so über TLS zur Verfügung stellen, dass ein Zugriff aus Webanwendungen ermöglicht wird, die selbst über TLS geladen wurden.

Die Test-App kann den Zugriff auf die Testtreiberschnittstelle durch das Setzen von CORS-Headern für den Zugriff aus Webanwendungen öffnen, die aus einer anderen Origin geladen wurden.

Die konkrete Ausgestaltung der Schnittstellen [gemTestTreiberFdV] ist im Fachportal der gematik und in GitHub vefügbar.

7 Informationsmodell

Aktenkonto:

Geräte-Daten:

Session-Daten:

Nutzer:

Berechtigungen:

87 Verteilungssicht

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

98 Anhang A – Verzeichnisse

9.1 Abkürzungenq8.1 Abkürzungen

98.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

98.3 Abbildungsverzeichnis

Abbildung 1: Systemüberblick FdVKomponenten ePA-Frontend des Versicherten

Abbildung 2: Komponenten ePA-Frontend des Versicherten : Authentisieren des Nutzers

8.4 Tabellenverzeichnis

Abbildung 3: Kryptographische Schlüssel der ePATabelle 1: Akteure und Rollen

Abbildung 4 Übersicht des Ablaufs der Freigabe von Daten für ForschungszweckeTabelle 2: Schnittstellen des ePA-Aktensystems

Abbildung 5: Aktivitätsdiagramm "Login Aktensession"Tabelle 3: Komponenten des FdV

Abbildung 6: Aktivitätsdiagramm "Anbieter wechseln"Tabelle 4: IHE Akteure und Transaktionen

Abbildung 7: Umschlüsselung ITabelle 5: Parameter FdV

Abbildung 8: Umschlüsselung IITabelle 6 : Tab_UX_KPI_Messung_ePA

Abbildung 9: Umschlüsselung IIITabelle 7: ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration

Abbildung 10: Umschlüsselung IVTabelle 8: FHIR Suche LEI

Abbildung 11: Aktivitätsdiagramm "PIN der eGK ändern"Tabelle 9: FHIR Suche DiGA

Abbildung 12: Aktivitätsdiagramm "PIN der eGK entsperren"Tabelle 10: Vertretung am fremden FdV verwalten

Abbildung 13: Test-App mit ePA-Frontend des Versicherten und TesttreiberTabelle 11: Value Set - Empfehlungen für die Anzeige

9.4 Tabellenverzeichnis

Tabelle 1: TAB_FdV_101 – Akteure und Rollen12: Value Set authorSpecialty

Tabelle 2: TAB_FdV_102 – Schnittstellen des ePA-Aktensystems13: Value Set classCode

Tabelle 3: TAB_FdV_167 – Komponenten des FdV14: Value Set confidentialityCode

Tabelle 4: TAB_FdV_103 – IHE Akteure und Transaktionen15: Value Set eventCodeList

Tabelle 5: TAB_FdV_104 – Parameter FdV16: Value Set healthcareFacilityTypeCode

Tabelle 6: TAB_FdV_105 – Session-Daten17: Value Set practiceSettingCode

Tabelle 7: TAB_FdV_106 – ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration18: Value Set typeCode

Tabelle 8: TAB_FdV_110 – Zertifikatsnutzung

Tabelle 9: TAB_FdV_161 – Zulässigkeit von Anwendungsfällen

Tabelle 10: TAB_FdV_107 – Behandlung von Fehlercodes von Plattformbausteinen

Tabelle 11: TAB_FdV_108 – Behandlung von Fehlern des ePA-Aktensystems

Tabelle 12: TAB_FdV_109 – Authentisieren des Nutzers

Tabelle 13: TAB_FdV_173 – Logout - Authentisierungstoken abmelden

Tabelle 14: TAB_FdV_111 – Dokumentenset in Dokumentenverwaltung hochladen

Tabelle 15: TAB_FdV_112 – Dokumentenset aus Dokumentenverwaltung herunterladen

Tabelle 16: TAB_FdV_113 – Dokumentenset in Dokumentenverwaltung löschen

Tabelle 17: TAB_FdV_114 – Suche nach Dokumenten in Dokumentenverwaltung

Tabelle 18: TAB_FdV_115 – Vergebene Berechtigungen bestimmen

Tabelle 19: TAB_FdV_179 – Akten- und Kontextschlüssel verschlüsseln

Tabelle 20: TAB_FdV_180 – Akten- und Kontextschlüssel entschlüsseln

Tabelle 21: TAB_FdV_116 – Schlüsselmaterial aus ePA-Aktensystem laden

Tabelle 22: TAB_FdV_163 – Schlüsselmaterial aller Berechtigten aus ePA-Aktensystem laden

Tabelle 23: TAB_FdV_117 – Schlüsselmaterial im ePA-Aktensystem speichern

Tabelle 24: TAB_FdV_118 – Schlüsselmaterial im ePA-Aktensystem ersetzen

Tabelle 25: TAB_FdV_119 – Schlüsselmaterial im ePA-Aktensystem löschen

Tabelle 26: TAB_FdV_120 – Suchkriterien LDAP Search

Tabelle 27: TAB_FdV_190 – Suchkriterien LDAP Search für DiGA

Tabelle 28: TAB_FdV_121 – Abfrage Verzeichnisdienst

Tabelle 29: TAB_FdV_122 – PIN-Eingabe durch Nutzer

Tabelle 30: TAB_FdV_123 – Login Aktensession

Tabelle 31: TAB_FdV_124 – Login - Einlesen der Karte

Tabelle 32: TAB_FdV_126 – Login - Aktenkontext öffnen - Operation OpenContext

Tabelle 33: TAB_FdV_127 – Logout Aktensession

Tabelle 34: TAB_FdV_128 – Logout - Aktenkontext schließen

Tabelle 35: TAB_FdV_172 – Logout - Authentisierungstoken abmelden

Tabelle 36: TAB_FdV_130 – Aktenkonto aktivieren

Tabelle 37: TAB_FdV_131 – Anbieter wechseln

Tabelle 38: TAB_FdV_132 – Anbieter wechseln - Aktenkonto in Exportzustand versetzen

Tabelle 39: TAB_FdV_133 – Anbieter wechseln - Aktenkonto fortführen

Tabelle 40: TAB_FdV_134 – Berechtigung an LEI für Aktenkonto vergeben

Tabelle 41: TAB_FdV_178 Anzeige der auf ein Dokument berechtigten LEI

Tabelle 42: TAB_FdV_179: Ändern der Vertraulichkeitsstufe eines Dokumentes

Tabelle 43: TAB_FdV_135 – Vertretung einrichten

Tabelle 44: TAB_FdV_136 – Vertretung am FdV des Vertreters verwalten

Tabelle 45: TAB_FdV_171 – Berechtigung an Kostenträger für Aktenkonto vergeben

Tabelle 46: TAB_FdV_137 – Vergebene Berechtigungen anzeigen

Tabelle 47: TAB_FdV_138 – Berechtigung für LEI ändern

Tabelle 48: TAB_FdV_139 – Berechtigung löschen

Tabelle 49: TAB_FdV_168 – Berechtigung für Vertreter löschen

Tabelle 50: TAB_FdV_166 – Berechtigung für Kostenträger löschen

Tabelle 51: TAB_FdV_190 – Berechtigung für DiGA löschen

Tabelle 52: TAB_FdV_181 – Berechtigung an DiGA für Aktenkonto vergeben

Tabelle 53: TAB_FdV_146 – Dokumente einstellen

Tabelle 54: TAB_FdV_147 – Dokumente einstellen - Dokument verschlüsseln

Tabelle 55: TAB_FdV_148 – Dokumente suchen

Tabelle 56: TAB_FdV_149 – Dokumente aus Aktenkonto herunterladen

Tabelle 57: TAB_FdV_150 – Dokumente löschen

Tabelle 58: TAB_FdV_151 – Protokolldaten einsehen

Tabelle 59: TAB_FdV_152 – Protokolldaten einsehen - Dokumentenverwaltung abfragen

Tabelle 60: TAB_FdV_153 – Protokolldaten einsehen - Autorisierung abfragen

Tabelle 61: TAB_FdV_154 – Protokolldaten einsehen - Zugangsgateway des Versicherten abfragen

Tabelle 62: TAB_FdV_156 – PIN der eGK ändern

Tabelle 63: TAB_FdV_157 – Ablaufaktivitäten – PIN der eGK ändern

Tabelle 64: TAB_FdV_158 – PIN der eGK entsperren

Tabelle 65: TAB_FdV_159 – Ablaufaktivitäten – PIN der eGK entsperren

Tabelle 66: TAB_FdV_160 – Benachrichtigungsadresse aktualisieren

Tabelle 67: TAB_FdV_177 – Verwendete Plattformleistungen

98.5 Referenzierte Dokumente

98.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

9.5.2 Weitere Dokumente8.5.2 Weitere Dokumente

9 Anhang B - Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets

Die in [gemSpec_Voc_ePA] vorgegebenen Value Sets beinhalten in der Regel eine hohe Anzahl von Werten, die nicht für jeden Sektor oder jede Berufsgruppe gleichermaßen relevant sind. Um dem Anwender die Nutzung zu erleichtern, wird für die Auswahl der Werte die Anzeige einer gefilterten Ansicht der Tabellen empfohlen.

Tabelle 11: Value Set - Empfehlungen für die Anzeige

Tabelle 12: Value Set authorSpecialty

Hinweis: Im Zuge der Value Set-Pflege wurde das Code-System "S_BAR2_WBO" (OID 1.2.276.0.76.5.114) für Fachgruppen-Codes nach der Weiterbildungsordnung Bundesarztregister in das neue Code-System "Facharzttitel der Ärztekammern" (OID: 1.2.276.0.76.5.514) konsolidiert, welches zukünftig das alte System ersetzt. Aufgrund der notwendigen Abwärtskompatibilität muss im Value Set "DocumentEntry.authorSpecialty" (OID: 1.2.276.0.76.11.31) für Spezialisierungen eines Dokumentenautors weiterhin das Code-System "S_BAR2_WBO" durch ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, lesend unterstützt werden. Für das Value Set "SubmissionSet.authorSpecialty" gilt dies analog. Neue Dokumente oder SubmissionSets dürfen nicht mehr mit Codes aus "S_BAR2_WBO" gekennzeichnet werden. 

Tabelle 13: Value Set classCode

Tabelle 14: Value Set confidentialityCode

Tabelle 15: Value Set eventCodeList

Tabelle 16: Value Set healthcareFacilityTypeCode

Tabelle 17: Value Set practiceSettingCode

Tabelle 18: Value Set typeCode