gemSpec_ePA_FdV_V2.3.0_Aend

24399

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

Spezifikation ePA-Frontend des Versicherten

 

   

Version	2.23.0
Revision	953382967543
Stand	12.0714.08.2024
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.2 Verwendete Standards

5.3 Integrating the Healthcare Enterprise IHE

5.4 Benutzeroberfläche

5.4.1 Visuelle Darstellung

5.4.2 Benutzerführung

5.4.2.1 Technische Normen und Verordnungen zur Beachtung

5.4.3 Anzeige von Dokumenten

5.4.4 Drucken und Speichern von Verwaltungs- und Inhaltsdaten

5.4.5 Sammlungen

5.4.6 Nutzungsvorgaben für IHE ITI XDS-Metadaten

5.4.6.1 Metadaten für einzustellende Dokumente

5.4.6.2 Metadaten für existierende Dokumente

5.4.7 Konfiguration des ePA-Frontend des Versicherten

5.5 Bereitstellung für UX-Messdaten

6 Funktionsmerkmale

6.1 Allgemein

6.1.1 Kommunikation mit dem ePA-Aktensystem

6.1.2 Sicherer Kanal zur Aktenkontoverwaltung

6.1.3 Authentisierung

6.1.4 Geräteregistrierung

6.1.5 Zertifikatsprüfung

6.1.6 Dokumente

6.1.7 ePA-FdV für Desktop-Plattformen

6.1.8 Anbindung an das Nationale Gesundheitsportal

6.1.9 Anbindung VZD-FHIR-Directory

6.1.10 Dokumente für den statischen Ordner "technical"

6.2 Implementation ePA-Anwendungsfälle im FdV

6.2.1 Übergreifende Festlegungen

6.2.2 Fehlerbehandlung

6.2.3 Aktivitäten

6.2.3.1 Authentisieren des Nutzers

6.2.3.2 Leistungserbringerinstitution im Verzeichnisdienst der TI finden

6.2.3.3 DiGA im Verzeichnisdienst der TI finden

6.2.4 Nutzerzugang ePA3.4 Land (EU-Zugriff) im Verzeichnisdienst der TI finden

6.2.4.1 Login User Nutzerzugang ePA

6.2.4.2 Logout1 Login User

6.2.5 Aktenkontoverwaltung4.2 Logout User

6.2.5.1 Widersprüche für Funktionen der ePA verwalten Aktenkontoverwaltung

6.2.5.2 Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI1 Widersprüche für Funktionen der ePA verwalten

6.2.6 Befugnisverwaltung5.2 Einschränkung der Verwendung von Daten auf bestimmte Sekundärnutzungszwecke

6.2.65.1 Befugnisverwaltung für3 Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI

6.2.65.2 Befugnisverwaltung für DiGA4 Widerspruch gegen die Nutzung des Medication Service durch eine spezifische LEI

6.2.6.3 Vertretung verwalten Befugnisverwaltung

6.2.6.4 Vergebene Befugnisse anzeigen1 Befugnisverwaltung für LEI

6.2.6.5 Eingerichtete Vertretungen anzeigen2 Befugnisverwaltung für DiGA

6.2.7 Verbergen und Sichtbarmachen von Dokumenten6.3 Vertretung verwalten

6.2.76.1 Kategorienbasiertes Verbergen von Dokumenten4 Vergebene Befugnisse anzeigen

6.2.76.2 Dokumentenspezifisches Verbergen von Dokumenten5 Eingerichtete Vertretungen anzeigen

6.2.8 Medical Services6.6 Befugnisverwaltung EU-Zugriff

6.2.8.1 XDS Document Service7 Verbergen und Sichtbarmachen von Dokumenten

6.2.87.1.1 Dokumente einstellen Kategorienbasiertes Verbergen von Dokumenten

6.2.87.1.2 Dokumente suchen2 Dokumentenspezifisches Verbergen von Dokumenten

6.2.8.1.3 Dokument herunterladen Medical Services

6.2.8.1.4 Dokumente im Aktenkonto löschen XDS Document Service

6.2.8.1.5 Metadaten von Dokumenten ändern1 Dokumente einstellen

6.2.8.2 Medication Service1.2 Dokumente suchen

6.2.9 Protokollverwaltung8.1.3 Dokument herunterladen

6.2.10 Geräteverwaltung8.1.4 Dokumente im Aktenkonto löschen

6.2.11 Verwaltung von E-Mail-Adressen8.1.5 Metadaten von Dokumenten ändern

6.2.12 Migration der Akte von ePA 2.6 nach ePA 3.08.2 Medication Service

6.3 Testtreiber-Modul für ePA-Frontend des Versicherten2.9 Protokollverwaltung

7 Verteilungssicht6.2.10 Geräteverwaltung

8 Anhang A – Verzeichnisse6.2.11 Verwaltung von E-Mail-Adressen

86.1 Abkürzungen2.12 Migration der Akte von ePA 2.6 nach ePA 3.0

86.2 Glossar3 Testtreiber-Modul für ePA-Frontend des Versicherten

8.3 Abbildungsverzeichnis7 Verteilungssicht

8.4 Tabellenverzeichnis Anhang A – Verzeichnisse

8.5 Referenzierte Dokumente1 Abkürzungen

8.5.1 Dokumente der gematik2 Glossar

8.5.2 Weitere Dokumente3 Abbildungsverzeichnis

9 Anhang B - Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

8.5.2 Weitere Dokumente

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

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: Akteure und Rollen

3.2 Nachbarsysteme

Die vom FdV direkt erreichbaren Produkttypen der TI sind

• ePA-Aktensystem,
• Signaturdienst
• Verzeichnisdienst FHIR-Directory

Der Signaturdienst bietet die Schnittstelle I_Remote_Sign_Operations für Signaturen an. Siehe [gemSpec_SigD].

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

Tabelle 2: Schnittstellen des ePA-Aktensystems

3.2.1 Identität des Nutzers

Ein Nutzer des FdV in seiner Rolle als Versicherter oder Vertreter verwendet die GesundheitsID für die Authentisierung gegenüber dem ePA-Aktensystem. Mit dieser digitalen Identität meldet sich der Versicherte an den Diensten der ePA sowie weiteren Diensten der TI an.

Das 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 1: Komponenten ePA-Frontend des Versicherten

Tabelle 3: 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 der 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).
• 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 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. 

Leistungserbringerinstitutionen

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.

Land (EU-Zugriff)

Land (EU-Zugriff) bezeichnet ein Land, welches zu den beteiligten EU-Mitgliedsstaaten gehört, die die Bereitstellung der Gesundheitsdaten (z.B. ePKA - elektronische Patientenkurzakte) für autorisierte Leistungserbringer im EU-Ausland (LE-EU) unterstützen.

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-01 - 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 in ein erlaubtes PDF/A-Format konvertieren bzw. durch das Aktensystem konvertieren lassen und ausschließlich das Dokument im PDF/A-Format in das Aktenkonto übermitteln. [<=]

Die im ePA-Aktensystem erlaubten Formate sind durch A_25233 definiert.

A_25457 - ePA-Frontend des Versicherten: Konvertieren von PDF im Aktensystem

Das ePA-Frontend des Versicherten KANN für die Konvertierung von Dokumenten im PDF-Format in das PDF/A-Format die Operation convertPDF gemäß [I_Tool_Convert_PDF_Insurant] verwenden. [<=]

A_25693 - ePA-Frontend des Versicherten: Anzeige von konvertierten PDF-Dokumenten

Das ePA-Frontend des Versicherten MUSS das Ergebnis eines konvertierten PDF-Dokuments vor dem Einstellen in das Aktenkonto dem Nutzer anzeigen. [<=]

Hinweis: Die Anzeige eines konvertierten PDF-Dokuments für den Nutzer ist erforderlich, da sich durch die Konvertierung Unterschiede im Layout ergeben können. 

Zur Verbesserung der UX im ePA FdV ist die Umsetzung von A_25693 eine akzeptable Lösung, wenn dem Versicherten eine Möglichkeit zur Konfiguration am FdV angeboten wird.  Der Versicherte kann somit nach ausreichender Belehrung worin die Risiken der Konvertierung liegen auf die zukünftige Anzeige des Ergebnisses der PDF/A-Konvertierung verzichten.
Eine andere Möglichkeit der Umsetzung von A_25693 ist beispielsweise eine Übersichtsseite, über die im nächsten Schritt einzustellenden bereits konvertierten Dokumente, mit den notwendigen Informationen/Risiken für den Versicherten und der Möglichkeit diese konvertierten Dokumente vor dem Upload einzusehen.

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-Frontend des Versicherten MUSS den Nutzer über die Annahmen und Anforderungen seines Produktes an das 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-Frontend 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. [<=]

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

Der Hersteller des ePA-Frontend 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 fü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. [<=]

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

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

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_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.

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äteidentifikatoren, Nutzerkennungen oder ein „Fingerabdruck“ auf Basis von Geräteeigenschaften und Einstellungen.

A_25267 - ePA-Frontend des Versicherten: Verbot der Profilbildung

Falls der Hersteller des ePA-Frontend des Versicherten Tracking Informationen verarbeitet, DARF er diese Informationen NICHT für eine Profilbildung verwenden. [<=]

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-01 - Tracking-Funktionen - Einwilligungsinformation des Nutzers

Das ePA-Frontend des Versicherten MUSS den Versicherten vor der Einwilligung in die Aktivierung von 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,
• wie die Tracking-Funktionen deaktiviert werden können.

[<=]

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-01 - Tracking-Funktionen – Neue Generierung der Pseudonyme ist jederzeit möglich

Das ePA-Frontend des Versicherten SOLL, falls es Tracking-Funktionen implementiert, 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.

Das ePA-Frontend des Versicherten 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 Fachanwendungen 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-Frontend des Versicherten: Ausführen von begutachtetem Code

Der Hersteller des ePA-FdV MUSS technisch sicherstellen, dass im ePA-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: Das Verbot des dynamischen Nachladens von ungeprüftem Code soll insbesondere 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-Frontend 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-Frontend 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 zugreifen lassen. [<=]

A_21356 - ePA-Frontend des Versicherten: Speicherung des Geräteidentifikators

Das ePA-FdV MUSS sicherstellen, dass die Speicherung des Geräteidentifikators ausschließlich verschlüsselt erfolgt. [<=]

A_21357 - ePA-Frontend 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. [<=]

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. [<=]

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.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.
[<=]

5.3 Integrating the Healthcare Enterprise IHE

Die dokumentenbezogenen Schnittstellen des ePA-Aktensystems und die Verarbeitungslogik des ePA-Frontends des Versicherten basieren auf Transaktionen des IHE ITI Technical Frameworks (IHE ITI TF). Die IHE ITI-Implementierungsstrategie ist in [] 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
• Restricted 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.

Tabelle 4: 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. Die 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 Datenkategorie 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 []beschrieben.

Wenn im Rahmen der IHE Schnittstellen-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 unterschieden.

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.

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:

• Anwendbarkeit auf verschiedenen Bildschirmgrößen und Auflösungen
• Intuitive und unkomplizierte Handhabung
• Anwendbarkeit auch im Offline-Modus
• Zielgruppenorientierung
• Leichte und verständliche Bereitstellung von Informationen
• Einhaltung ergonomischer Aspekte (z.B. kurze Touchwege)
• 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-01 - ePA-Frontend des Versicherten: Nutzung Gerätefunktionalitäten

Zur Umsetzung der Barrierefreiheit SOLL das ePA-Frontend des Versicherten gerätespezifische Funktionalitäten (z.B. Lagebestimmung, Kamerafunktion, Multi-Touch-Gesten) 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 Drucken und Speichern von Verwaltungs- und Inhaltsdaten

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. [<=]

Das 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 [ ] 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.

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  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 Datenkategorien "patientdoc" oder "childsrecordchild"  eingeordnet (submissionset.authorRole = 102). 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 Datenkategorien 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-06 - ePA-Frontend des Versicherten: Parameter speichern und laden

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

Tabelle 5: 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 A_15292* zu verwalten (anzeigen, ändern, löschen). [<=]

A_24588 - ePA-Frontend des Versicherten: Lokalisierung 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. [<=]

Die 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 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 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_15302-02 - ePA-Frontend des Versicherten: Lokalisierung Access Gateway

Das ePA-Frontend des Versicherten MUSS den Endpunkt für die Kommunikation mit dem Access Gateway mittels des Mechanismus gemäß [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 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 7: ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration

Die 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 Access 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 Access Gateway anhand seines TLS-Zertifikats authentifizieren und MUSS die Verbindungen ablehnen, falls die Authentifizierung fehlschlägt. [<=]

Das Access 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_15300-02 - ePA-Frontend des Versicherten: TLS-Verbindungsaufbau nach Notwendigkeit

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

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

Das ePA-Frontend des Versicherten MUSS die für eine User Session aufgebaute TLS-Verbindung zum Access Gateway schließen, wenn die User 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. [<=]

A_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ürdigenVertrauenswü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-02 - ePA-Frontend des Versicherten: Umsetzung sicherer Kanal zur Aktenkontoverwaltung

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

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

6.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 Home-AS aufgerufen. Als Home-AS wird das ePA-Aktensystem desjenigen Betreibers bezeichnet, der vom Kostenträger des Versicherten beauftragt wurde. Als Ergebnis wird an das ePA-FdV die DeviceID mit deviceIdentifier als Gerätekennung und das deviceToken als Sicherheitsmerkmal zurückgegeben. Diese DeviceID wird für den Nutzer im ePA-FdV persistent gespeichert. Ist für den Nutzer eine Geräteregistrierung für das verwendete Gerät bereits erfolgt kann diese für folgende Logins erneut genutzt werden. Der Zugriff auf ein Aktenkonto ist nur mit einem registrierten Gerät möglich.

Die DeviceID einer neuen Geräteregistrierung muss vor der Verwendung durch den Nutzer in der Geräteverwaltung des Aktensystems einmalig bestätigt werden. Dafür erhält der Nutzer über einen separaten Benachrichtigungskanal (E-Mail) den Geräteregistrierungscode (Confirmation Code) für dieses Gerät.

Falls der Nutzer als Vertreter auf ein anderes als sein Home-AS zugreifen möchte, muss das ePA-FdV eine Bestätigung der Geräteregistrierung (deviceAttestation) am Home-AS abfragen und diese beim Login an einem anderen als dem Home-AS als Nachweis der Geräteregistrierung in der Operation sendAuthCodeFdV mitgeben.

A_15305-03 - ePA-Frontend des Versicherten: Geräteinformationen speichern

Falls eine Geräteregistrierung beim Login des Nutzers erfolgt, MUSS das ePA-Frontend des Versicherten die Geräteinformationen persistent und sicher speichern. [<=]

A_24924 - ePA-Frontend des Versicherten: Geräteinformationen anzeigen

Falls eine Geräteregistrierung beim Login 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. [<=]

A_26073-01 - ePA-Frontend des Versicherten: email-Adresse für BestätigungslinkGeräteregistrierungscode anzeigen

Das ePA-Frontend des Versicherten MUSS dem Nutzer die email-Adresse, an welche der BestätigungslinkGeräteregistrierungscode versendet wurde, anzeigen. [<=]

6.1.5 Zertifikatsprüfung

Es 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. [<=]

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 GesundheitspotralGesundheitsportal 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_ePAfueralle#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 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.8 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 befugte 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.9 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 Anwendungsfä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:

• Der Versicherte verfügt über ein Aktenkonto oder ist als Vertreter für ein Aktenkonto befugt worden.
• Die Akten-ID (KVNR) des Aktenkontos, welche sich mittels der Versicherten-ID des Aktenkontoinhabers bestimmen lässt, ist im ePA-Frontend des Versicherten bekannt.
• Der FQDN für den Zugriff auf das ePA-Aktensystem ist im ePA-Frontend des Versicherten bekannt.

6.2.2 Fehlerbehandlung

Tritt ein Fehler bei der Verarbeitung von Operationsaufrufen des ePA-Aktensystems auf, dann antwortet das ePA-Aktensystem mit einer Fehlermeldung. Das Format und die verwendeten Fehlercodes sind in den Spezifikationen der Schnittstellen 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.

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. [<=]

6.2.3 Aktivitäten

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

6.2.3.1 Authentisieren des Nutzers

Auslö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 sendAuthorizationRequestFdV 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 integriert sein oder in einer separaten Authenticator-App implementiert sein.

Aufruf des Authenticator-Moduls
 

Das ePA-Frontend gibt die Antwort der sendAuthorizationRequestFdV 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 den Auth_Code vom Authenticator-Modul annehmen und an den Authorization-Server unter Verwendung der Operation sendAuthCodeFdV 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 sendAuthCodeFdV-Response erhält das FdV die Zugriffserlaubnis auf das Aktensystem. Die User-Session ist etabliert und fachliche Operationen sind möglich.

A_26270 - ePA-Frontend des Versicherten: Nutzung von Prüfkarten und Prüfnutzeridentitäten

Für die Nutzung von Prüfkarten und Prüfnutzeridentitäten MUSS das ePA-Frontend des Versicherten die Operation send_authorization_request_fdv mit dem Parameter x-authorize_validation aufrufen [I_Authorization_Service]. [<=]

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.

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-01 - 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 Suche nach LEIs erfolgt primär über den Namen oder Institutionsnamen, aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.

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.3 DiGA im Verzeichnisdienst der TI finden

Informationen 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 es dem Nutzer ermöglichen, DiGAs über die folgenden Suchkriterien im VZD-FHIR-Directory gemäß [gemSpec_VZD_FHIR_Directory#5.5] zu suchen. 

Tabelle 9: FHIR Suche DiGA

[<=]

A_25133 - ePA-Frontend des Versicherten: DiGA - Volltextsuche am VZD-FHIR-Directory

Das ePA-Frontend des Versicherten MUSS es dem 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.3.4 Land (EU-Zugriff) im Verzeichnisdienst der TI finden

Informationen zu Ländern (EU-Zugriff) sind im Verzeichnisdienst FHIR-Directory (VZD-FHIR-Directory) der TI-Plattform hinterlegt. 

Der Versicherte kann über das ePA-FdV (bspw. für die Erstellung einer Befugnis EU-Zugriff) mit verschiedenen Kriterien nach dem entsprechenden Land 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 dem Land erfolgt primär über den Namen des Landes.

A_25828 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Search Operation am VZD-FHIR-Directory

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

Tabelle 10: FHIR Suche EU-Land

[<=]

Voraussetzung für die Suche nach einem EU-Land ist professionOID = oid_ncpeh.

6.2.4 Nutzerzugang ePA

6.2.4.1 Login User

Mit diesem Anwendungsfall wird eine sichere Verbindung in das ePA-Aktensystem für den Nutzer gestartet.

Für die Anmeldung des Nutzers wird die GesundheitsID verwendet. Das ePA-Frontend des Versicherten unterstützt den Vertreter bei der Auswahl des Aktensystems.

A_24746 - ePA-Frontend des Versicherten: Login User - Auswahl Aktensystem für Vertreter

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login User" 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_15343-02 - ePA-Frontend des Versicherten: Login - Authentisieren des Nutzers

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Login User" die übergreifende Aktivität "Authentisieren des Nutzers" ausführen. [<=]

A_25227 - ePA-Frontend des Versicherten: Login - registriertes Gerät

Falls das verwendete Gerät des Nutzers bereits registriert ist, MUSS das ePA-Frontend des Versicherten im Anwendungsfall "Login User" diese Registrierungsdaten bei der Kommunikation mit dem Authorization Service verwenden gemäß [I_Authorization_Service]. [<=]

Da die Registrierung eines Gerätes immer im Home-AS erfolgt werden 2 Fälle beim Login und bereits erfolgter Registrierung unterschieden:

1. Login in Home-AS
Die Registrierungsdaten sind mit der DeviceID im ePA-FdV persistiert. Es wird die DeviceID beim Login übergeben.

2. Login in anderem ePA-Aktensystem, nicht Home-AS (Vertreter)

Das ePA FdV ruft am Device Management Service des Home-AS die Operation getDeviceAttestation  auf. Diese Operation liefert ein vom Home-AS signiertes Token deviceAttestation, welches die Geräteregistrierung bestätigt. Das Token deviceAttestation wird beim Login übergeben. Dadurch entfällt eine erneute Registrierung an einem weiteren ePA-Aktensystem. Der Nachweis der Geräteregistrierung wird am Aktensystem nicht persistiert und muss bei einem nächsten Login erneut abgefragt werden.

A_26149 - ePA-Frontend des Versicherten: Login - Device Attestation

Falls ein Login an einem NICHT Home-As erfolgt MUSS das ePA-Frontend des Versicherten sich bestätigen lassen, dass das verwendete Gerät des Nutzers bereits im Home-AS registriert ist. Dies erfolgt durch Aufruf der Operation getDeviceAttestation gemäß [I_Authorization_Service]. [<=]

A_25293 - ePA-Frontend des Versicherten: Login - neues Gerät registrieren

Falls das verwendete Gerät des Nutzers noch nicht registriert ist, MUSS das ePA-Frontend des Versicherten im Anwendungsfall "Login User" die Geräteregistrierung unter Verwendung der Operation registerDevice gemäß [I_Device_Management_Insurant.yaml] aufrufen. [<=]

Benachrichtigungen

Die Anzeige von Benachrichtigungen im Anwendungsfall "Login User" ist optional gemäß den Konfigurationsdaten.

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_15352-04 - ePA-Frontend des Versicherten: Login - Protokolldaten abfragen

Das ePA-Frontend des Versicherten MUSS in einer User Session beim erstmaligen Zugriff auf ein Aktenkonto, wenn die Konfiguration Benachrichtigungen aktivieren = ja gesetzt ist, die Protokolldaten des ePA-Aktensystems abfragen und das Ergebnis gemäß der Konfiguration Benachrichtigungszeitraum filtern. Falls gemäß A_15354-* noch kein Wert "Zugriff auf das 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 umsetzen, in der die Protokolleinträge für folgende Zugriffe übersichtlich dargestellt werden:

• Dokumente einstellen aus der LEI-Umgebung
• Dokumente löschen aus der LEI-Umgebung
• Dokumente einstellen aus der privaten Umgebung
• Dokumente löschen aus der privaten Umgebung

[<=]

A_15354-02 - ePA-Frontend des Versicherten: Konfiguration letzte Anmeldung

Das ePA-Frontend des Versicherten MUSS in einer User Session beim erstmaligen Zugriff auf ein Aktenkonto den Wert "Zugriff auf das Aktenkonto" für das Aktenkonto in den Konfigurationsdaten aktualisieren. [<=]

6.2.4.2 Logout User

Dieser Anwendungsfall beendet eine User 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 User" die Operation logoutFdV 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 User" alle Session-Daten aus dem lokalen Speicher löschen. [<=]

Hinweis: Zu den Session-Daten gehören z. B. die geheimen Schlüssel für ein SSO oder für den VAU-Kanal.

6.2.5 Aktenkontoverwaltung

Der 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 eAePA-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-0203 - Revisionssicherer Export der Protokolle

Das ePA-FdV MUSS dem Nutzer eine Funktion zum Export signierter Protokolldaten aus der Akte unter Nutzung der Operation get gemäß [I_Audit_Event_Render"Render API: PDF Audit" des FHIR Implementation Guide für den Audit Event Service [IG_Audit_Event_Service] bereitstellen. [<=]

6.2.5.1 Widersprüche für Funktionen der ePA verwalten

Das 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_24056-01 - ePA-FdV: Information des Nutzers über Möglichkeit des Widerspruchs in Funktionen der ePA

Das ePA-Frontend des Versicherten MUSS einen Versicherten bei der ersten Nutzung eines ePA FdV über die widerspruchsfähigen Funktionen der ePA und seine Möglichkeit einer Änderung dieser umfassend informieren. [<=]

Hinweis zu A_24056-*:
Um zu vermeiden, dass dem Versicherten die Informationen bei Gerätewechseln und Neuinstallationen eines ePA-FdV immer wieder erneut angezeigt werden, kann im Backend-System der Krankenkasse nachgehalten werden, dass der Versicherte die Informationen bereits einmal erhalten hat und die Information nicht nochmals am ePA-FdV angezeigt werden muss.

A_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 und die Auswirkungen bei Rücknahme des Widerspruchs umfassend informieren, so dass auch ein nicht technisch vorgebildeter Nutzer eine fundierte Entscheidung über die Teilnahme oder Nicht-Teilnahme an einer FunktionenFunktion treffen kann. [<=]

Die geforderten Informationen des Nutzers betrifft auch die Widersprüche zu Sekundärnutzungszwecken, siehe 6.2.5.2 Einschränkung der Verwendung von Daten auf bestimmte Sekundärnutzungszwecke .

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 ePA FdV. Ein Nutzer des ePA 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_26311 - ePA-Frontend des Versicherten: Anzeige Widersprüche zu Sekundärnutzungszwecken bei Rücknahme Widerspruch gegen die Sekundärdatennutzung durch das FDZ

Falls ein Widerspruch gegen die Sekundärdatennutzung durch das FDZ zurückgenommen wird MUSS das ePA-Frontend des Versicherten dem Versicherten die im Aktensystem hinterlegten Widersprüche zu Sekundärnutzungszwecken anzeigen. [<=]

A_23875 - ePA-Frontend des Versicherten: Anzeige der Widersprüche

Das ePA-Frontend des Versicherten MUSS dem Nutzer alle im Aktensystem hinterlegten Widersprüche unter Verwendung der Operation getConsentDecisions gemäß [I_Consent_Decision_Management] anzeigen. [<=]

A_23880-01 - ePA-Frontend des Versicherten: Anwendungsfall "Widerspruch für Funktionen der ePA ändern"

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Widerspruche für Funktionen der ePA gemäß A_23874 unter Verwendung der Operation updateConsentDecision gemäß [I_Consent_Decision_Management] zu erteilen bzw. zurückzunehmen . [<=]

A_25234-01 - ePA-Frontend des Versicherten: Anzeige der Widersprüche - Information für Nutzer

Das ePA-Frontend des Versicherten MUSS den Nutzer darüber informieren, dass ein erteilter Widerspruch "Teilnahme am digital gestützten Medikationsprozess" dazu führt, dass ausschließlich der E-Rezept-Fachdienst und der Versicherte/Vertreter auf eML-Daten zugreifen darf. [<=]

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

Wenn kein Widerspruch gegen die Sekundärdatennutzung durch das FDZ für das Aktenkonto erteilt wurde kann der Versicherte (bzw. ein Vertreter) die Verwendung seiner Daten auf die in § 303e Absatz 2 SGB V aufgeführten Sekundärnutzungszwecke einschränken.

Über das Frontend des Versicherten kann die Liste der Sekundärnutzungszwecke und deren Zustand hinsichtlich Widerspruch eingesehen oder geändert werden. Der initiale Zustand nach Aktivierung eines Aktenkontos ist für jeden Sekundärnutzungszweck "kein Widerspruch erteilt".

Eine Änderung der Liste der Sekundärnutzungszwecke durch den Versicherten oder einen Vertreter führt dazu, dass diese Information an das Forschungsdatenzentrum Gesundheit übermittelt wird. Die Widersprüche des Versicherten in die Sekundärnutzungszwecke ist dort bindend für die Verarbeitung der übermittelten pseudonymisierten medizinischen Daten.

A_26283 - ePA-Frontend des Versicherten: Anzeige der Sekundärnutzungszwecke

Falls kein Widerspruch gegen die Sekundärdatennutzung erteilt wurde MUSS das ePA-Frontend des Versicherten dem Nutzer die Widersprüche zu den einzelnen Sekundärnutzungszwecken unter Verwendung der Operation getDataUsagePurposes gemäß [I_Consent_Decision_Management] anzeigen. [<=]

A_26439 - ePA-Frontend des Versicherten: Art der Anzeige der Sekundärnutzungszwecke

Das ePA-Frontend des Versicherten MUSS dem Nutzer die Widersprüche zu den einzelnen Sekundärnutzungszwecken immer im exakten Wortlaut des Gesetzes sowie in einer für Laien verständlichen Beschreibung anzeigen. [<=]

Weiterführende Informationen zu Sekundärnutzungszwecken und laienverständliche Darstellungen können unter https://www.forschungsdatenzentrum-gesundheit.de/gesundheitsdaten gefunden werden.

A_26284 - ePA-Frontend des Versicherten: Anwendungsfall "Widersprüche in Sekundärnutzungszwecke ändern"

Falls kein Widerspruch gegen die Sekundärdatennutzung erteilt wurde MUSS das ePA-Frontend des Versicherten dem Nutzer ermöglichen, die Widersprüche zu den einzelnen Sekundärnutzungszwecken unter Verwendung der Operation updateDataUsagePurposes gemäß [I_Consent_Decision_Management] zu erteilen bzw. zurückzunehmen. [<=]

6.2.5.3 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_25136 - ePA-Frontend des Versicherten: LEI - Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, 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_24410 - ePA-Frontend des Versicherten: Erteilung eines Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI

Das ePA-Frontend des Versicherten MUSS 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_24460 - ePA-Frontend des Versicherten: Löschen eines Widerspruchs gegen die Nutzung der ePA durch eine spezifische LEI

Das ePA-Frontend des Versicherten MUSS 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_24411 - ePA-Frontend des Versicherten: Anzeigen von Widersprüchen gegen die Nutzung der ePA durch spezifische LEIs

Das ePA-Frontend des Versicherten MUSS 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.5.4 Widerspruch gegen die Nutzung des Medication Service durch eine spezifische LEI

Ein Versicherter bzw. Vertreter hat die Möglichkeit der Nutzung des Medication Service durch eine oder mehrere spezifische LEI zu widersprechen. Die Verwaltung dieser Widersprüche durch das ePA FdV erfolgt im Consent Management. Ein Nutzer kann einen Widerspruch wieder zurücknehmen.

A_26425 - ePA-Frontend des Versicherten: Widerspruchs gegen die Nutzung des Medication Service durch eine spezifische LEI - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine LEI im VZD-FHIR-Directory zu suchen und für die Erteilung eines Widerspruchs gegen die Nutzung des Medication Service durch eine spezifische LEI auszuwählen. [<=]

A_26426 - ePA-Frontend des Versicherten: Erteilung eines Widerspruchs gegen die Nutzung des Medication Service durch eine spezifische LEI

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, einen Widerspruch gegen die Nutzung des Medication Service durch eine spezifische LEI zu erteilen unter Verwendung der Operation setUserSpecificMedicationDeny gemäß [I_Consent_Decision_Management]. [<=]

A_26427 - ePA-Frontend des Versicherten: Löschen eines Widerspruchs gegen die Nutzung des Medication Service durch eine spezifische LEI

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, einen Widerspruch gegen des Medication Service durch eine spezifische LEI zurückzunehmen unter Verwendung der Operation deleteUserSpecificMedicationDeny gemäß [I_Consent_Decision_Management]. [<=]

A_26428 - ePA-Frontend des Versicherten: Anzeigen von Widersprüchen gegen die Nutzung des Medication Service durch spezifische LEIs

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, die Liste der erteilten Widersprüche gegen die Nutzung des Medication Service durch spezifische LEIs unter Verwendung der Operation getUserSpecificMedicationDenyList gemäß [I_Consent_Decision_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_2394123941* 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.

Im ePA-Frontend des Versicherten können nur Befugnisse an LEI oder DiGA vergeben werden, die im VZD-FHIR-Directory der TI registriert sind.

Eine Besonderheit bildet der Zugriff auf Gesundheitsdaten im grenzüberschreitenden Austausch zwischen den Mitgliedsstaaten der Europäischen Union (EU-Zugriff), siehe Kapitel 6.2.6.6 Befugnisverwaltung EU-Zugriff .

A_23968 - ePA-Frontend des Versicherten: Befugnisverwaltung am Aktensystem - Nutzung Schnittstelle

Das ePA-Frontend des Versicherten MUSS beim 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_24399-01 - ePA-Frontend des Versicherten: Befugnis signieren

Das ePA-Frontend des Versicherten MUSS beim 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 unter Verwendung von privacy_mode=true am Signaturdienst mit der Identität des Nutzers gemäß [gemSpec_SigD] signieren. [<=]

Vor dem Signieren der Befugnis wird das Zertifikat des Nutzers vom SigD unter Verwendung der Operation I_Remote_Get_Certificate::get_Certificate für die Erstellung des JWT abgerufen. Es wird der Hashwert des jwt vom ePA-Frontend des Versicherten gebildet und signiert. 

A_26280 - ePA-Frontend des Versicherten: Keine Übermittlung von Informationen des Befugten an den Signaturdienst

Das ePA-Frontend des Versicherten MUSS sicherstellen, dass beim Aufruf der Schnittstellen des Signaturdienstes zum Zwecke des Signierens einer Befugnis keine Informationen über den zu befugenden Nutzer an den Signaturdienst übermittelt werden. [<=]

Hinweis zu A_26280: Um dies zu ermöglichen, bietet der Signaturdienst die Möglichkeit des privacy mode, so dass nur der zu signierende Hashwert der Befugnis an den Signaturdienst übermittelt werden muss.

6.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 es 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. [<=]

Für die Umsetzung der Suche siehe Aktivität 6.2.3.2 Leistungserbringerinstitution im Verzeichnisdienst der TI finden.

A_24549 - ePA-Frontend des Versicherten: LEI - Berücksichtigung der Legal Policy bei Erstellen einer Befugnis

Das ePA-Frontend des Versicherten MUSS beim Erstellen einer Befugnis die Legal Policy beachten. Daraus folgt, dass dem Nutzer nur Leistungserbringerinstitutionen zur Auswahl angezeigt werden, die den erlaubten Berufsgruppen gemäß der Legal Policy entsprechen.
[<=]

A_20109-05 - ePA-Frontend des Versicherten: LEI - 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 Befugnis zu konfigurieren. Folgende Optionen MUSS das ePA-Frontend anbieten:

• flexibles Enddatum
• unbefristet
• 90 Tage [default] (heutiges Datum + 89 Kalendertage)
  bzw. 3 Tage [default] (heutiges Datum + 2 Kalendertage) bei Nutzergruppen gemäß § 342 Abs. 2 Nr. 1 lit. l SGB V.(siehe A_23941-*)

[<=]

A_25482 - ePA-Frontend des Versicherten: LEI - Endzeitpunkt der Befugnisdauer

Das ePA-Frontend des Versicherten MUSS zu dem vom Nutzer gewählten Endedatum den Endezeitpunkt auf das Ende des Tages der aktuellen Zeitzone in Deutschland, d.h. MEZ (UTC+1) bzw. MESZ (UTC+2)  setzen. [<=]

Hinweis: Befugniserstellungszeitpunkt ist 2024-04-12T10:05:30+01:00. Der daraus resultierende Befugniszeitpunkt ist 2024-04-12T23:59:59+01:00

6.2.6.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_25129 - ePA-Frontend des Versicherten: DiGA - Befugnis verwalten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, eine Befugnis für eine DiGA zu erstellen bzw. zu löschen. [<=]

A_25130 - ePA-Frontend des Versicherten: 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 verwalten

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 Befugnisdauer für Vertreter kann nicht zeitlich oder inhaltlich begrenzt werden. Wenn ein Vertreter befugt ist, auf die Dokumente zuzugreifen, dann kann der Vertreter dauerhaft auf alle Dokumente im Aktenkonto zugreifen, bis ihm die Befugnis generell wieder entzogen wird.

A_23971 - ePA-Frontend des Versicherten: Vertreter verwalten

Das ePA-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, eine Befugnis für einen Vertreter zu erstellen oder zu löschen. [<=]

A_25245 - ePA-Frontend des Versicherten: eigene Befugnis als Vertreter löschen

Das ePA-Frontend des Versicherten MUSS es dem Vertreter ermöglichen, die eigene Befugnis als Vertreter 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 MUSS die folgenden Informationen des Versicherten, welcher vertreten wird, beinhalten:

• Versicherten-ID
• FQDN des Anbieters.

[<=]

Anwendungsfall "Vertretung am fremden FdV verwalten" als Sonderfall

Für den Fall, dass der zu Vertretende kein eigenes ePA FdV nutzt, aber eine Vertretung einrichten oder löschen möchte, ist die Umsetzung des Anwendungsfalls "Vertretung am fremden FdV verwalten" wie folgt möglich.

A_23555-02 - ePA-Frontend des Versicherten: Vertretung am fremden FdV verwalten - Ablauf

Das ePA-Frontend des Versicherten KANN den Anwendungsfall "Vertretung am fremden FdV verwalten" umsetzen

Tabelle 1011: Vertretung am fremden FdV verwalten

[<=]

Hinweis:
Im Anwendungsfall "Vertretung am fremden FdV verwalten" ist die Authentisierung des zu Vertretenden ausschließlich mittels eGK und PIN möglich.

A_24405-01 - ePA-Frontend des Versicherten: Vertretung am fremden FdV verwalten - Authentisierung

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Vertretung am fremden FdV verwalten" die Authentisierung des zu Vertretenden am IdP mittels eGK und PIN ohne Prüfung Gerätebindung verlangen gemäß [I_Authorization_Service]. [<=]

Die Anmeldung des zu Vertretenden in diesem Szenario erfolgt ohne Geräteregistrierung.

6.2.6.4 Vergebene Befugnisse anzeigen

Mit diesem Anwendungsfall kann ein Nutzer eine Liste der für das Aktenkonto vergebenen Befugnisse anzeigen lassen. Diese Liste beinhaltet die befugten Leistungserbringerinstitutionen, DiGAs und Vertreter sowie die Details zu Berechtigungen (für LEI: Berechtigungsdauer).

A_23963 - ePA-Frontend des Versicherten: Befugnisse anzeigen

Das ePA-Frontend des Versicherten MUSS dem Nutzer alle im Aktensystem hinterlegten Befugnisse einschließlich Gültigkeitszeitraum anzeigen und dem Nutzer nach Nutzergruppen (LEI, DiGA, Vertreter) geordnet anzeigen. [<=]

A_23972-01 - ePA-Frontend des Versicherten: Ergebnisliste Befugnisse Felder

Das ePA-Frontend des Versicherten MUSS im Ergebnis der Suche nach Befugnissen mindestens

• für LEI: Name der Leistungserbringerinstitution, Ende 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

anzeigen. [<=]

Das Ergebnis der Suche soll für den Nutzer sortierbar und filterbar dargestellt werden.

Das ePA-FdV ermöglicht es dem Nutzer, über Einträge in der Ergebnisliste Befugnisse zu bearbeiten oder zu löschen.

6.2.6.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 Befugnis 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.6.6 Befugnisverwaltung EU-Zugriff

Auf Gesundheitsdaten (z.B. ePKA) kann auch im grenzüberschreitenden Austausch zwischen den Mitgliedsstaaten der Europäischen Union zugegriffen werden. Voraussetzung hierfür ist eine durch den Versicherten erstellte Befugnis für das entsprechende Land. Der Versicherte wählt hierzu im FHIR-VZD das Land aus. Für die ermittelte Telematik-ID dieses Landes wird eine Befugnis erstellt und mit der Identität des Versicherten signiert. Die Befugnis EU-Zugriff ist 1 Stunde gültig und kann verlängert werden. Die Verlängerung einer Befugnis EU-Zugriff wird technisch als Erstellen einer neuen Befugnis umgesetzt, welche eine noch existierende Befugnis ersetzt. Es gibt zu einem Zeitpunkt maximal eine Befugnis EU-Zugriff.

Das ePA-FdV erzeugt zusätzlich zur Befugnis einen 6-stelligen Zugriffscode. Der Zugriffscode wird zur Befugnis im Entitlement Management hinterlegt und dient als Geheimnis, welches der Versicherte dem LE im EU-Ausland übergibt und erteilt diesem dadurch die Erlaubnis zum Zugriff auf die Daten.

In diesem Kapitel werden die folgenden Anwendungsfälle umgesetzt:

• "Befugnis für einen EU-Zugriff erstellen"
• "Befugnis für einen EU-Zugriff verlängern"
• "Befugnis für einen EU-Zugriff löschen"
• "Befugnis für einen EU-Zugriff anzeigen"

A_26108 - ePA-Frontend des Versicherten (EU): EU Zugriff - Erstellung Befugnis am Aktensystem - Nutzung Schnittstelle

Das ePA-Frontend des Versicherten MUSS beim Erstellen einer Befugnissen für EU-Zugriff am ePA-Aktensystem die Operation setEntitlementEU der Schnittstelle I_Entitlement_Management_EU gemäß [I_Entitlement_Management_EU] verwenden. [<=]

A_26122 - ePA-Frontend des Versicherten (EU): EU Zugriff - Abruf Zugriffscode für EU Zugriff am Aktensystem - Nutzung Schnittstelle

Das ePA-Frontend des Versicherten MUSS beim Abruf des für die Befugnis hinterlegten Zugriffscode am ePA-Aktensystem die Operation getAccessCode der Schnittstelle I_Entitlement_Management_EU gemäß [I_Entitlement_Management_EU] verwenden. [<=]

Löschen und Lesen einer Befugnis für EU-Zugriff unterscheidet sich nicht von den anderen Befugnissen, d.h. diese werden mit den Operationen von [I_Entitlement_Management] umgesetzt. 

Die Operation getEntitlements liefert alle im Aktensystem hinterlegten Entitlements einschließlich eines evt. hinterlegten Entitlements für EU-Zugriff. 

A_25825 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Befugnis verwalten

Das ePA-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, eine Befugnis EU-Zugriff zu erstellen, zu verlängern, zu löschen bzw. anzuzeigen. [<=]

A_25826 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Suche in Verzeichnisdienst

Das ePA-Frontend des Versicherten MUSS es dem Versicherten ermöglichen, ein Land für eine Befugnis EU-Zugriff im VZD-FHIR-Directory zu suchen. Länder für EU-Zugriff besitzen die Rolle = oid_ncpeh. [<=]

Für die Umsetzung der Suche siehe 6.2.3.4 Land (EU-Zugriff) im Verzeichnisdienst der TI finden  .

A_25839 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Zugriffscode erstellen

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Befugnis für einen EU-Zugriff erstellen" einen Zugriffscode (AccessCode) als Zufallswert erstellen (vgl. A_26301) und diesen Zugriffcode gemeinsam mit der Befugnis EU-Zugriff im Entitlement Management hinterlegen. Für jede Befugnis EU-Zugriff MUSS ein neuer AccessCode erzeugt werden. [<=]

 Die zufällige Erzeugung des Zugriffscodes wird in [gemSpec_Krypt#Zugriffscode-Erzeugung] detaillierter betrachtet.

A_25841 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Anzeige Zugriffscode

Das ePA-Frontend des Versicherten MUSS, den bei einer Befugnis EU-Zugriff erzeugten Zugriffscode dem Versicherten anzeigen und auf Wunsch wiederholt anzeigen. [<=]

A_25842 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Information für Versicherten allgemein

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Befugnis für EU-Zugriff erstellen" vor Erteilung der Befugnis den Versicherten über seine Rechte in Bezug auf den Schutz seiner persönlichen und Gesundheitsdaten und der Verarbeitung seiner Daten innerhalb der grenzüberschreitenden Dienste (Aufklärungstext zur Einwilligung in den Datenaustausch) informieren. [<=]

Hinweis:

Eine Befugnis EU-Zugriff ist eine Stunde gültig. Das Gültigkeitsendedatum validTo wird bei Erstellung der Befugnis durch das Aktensystem gesetzt, d.h. der Wert im JWT der Befugnis wird vom Aktensystem nicht ausgewertet.

Eine nicht abgelaufene Befugnis EU-Zugriff kann um eine Stunde auch wiederholt verlängert werden. Hierzu erzeugt das ePA-FdV einen neuen Zugriffscode und erstellt eine neue Befugnis EU-Zugriff mit diesem Zugriffscode.

A_25843 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Befugnis verlängern

Das ePA-Frontend des Versicherten MUSS im Anwendungsfall "Befugnis für EU-Zugriff verlängern" für die aktuell gültige Befugnis EU-Zugriff erneut eine Befugnis EU-Zugriff für dieses Land erzeugen, d.h. einen Zugriffscode (AccessCode) als Zufallswert erstellen und diesen Zugriffcode gemeinsam mit der Befugnis EU-Zugriff im Entitlement Management hinterlegen. [<=]

A_25866 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Befugnis anzeigen

Das ePA-Frontend des Versicherten MUSS dem Versicherten die im Aktensystem hinterlegte Befugnis EU-Zugriff anzeigen und dabei die folgenden Inhalte anzeigen:

• Name des Landes
• Gültigkeitsende
• Zugriffscode
• KVNR des Versicherte

[<=]

Damit kann der Versicherte dem LE-EU die Informationen auf seinem Endgerät zeigen und so die Nutzung der Zugriffsdaten verständlich machen.

A_25868 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Anzeige vor Ablauf

Falls die Restdauer der Befugnis EU-Zugriff < 10 Minuten MUSS das ePA-Frontend des Versicherten den Zeitwert für den Versicherten deutlich hervorgehoben anzeigen. (z.B. farblich) [<=]

Die Anzeige vor Ablauf der Befugnis EU-Zugriff kann z.B. farblich hervorgehoben werden.

A_25871 - ePA-Frontend des Versicherten (EU): EU-Zugriff - Anzeige bei Ablauf

Falls die Befugnis EU-Zugriff zeitlich abgelaufen ist MUSS das ePA-Frontend des Versicherten eine Information für den Versicherten über den Ablauf der Befugnis EU-Zugriff anzeigen. [<=]

Hinweis: Es reicht aus, dass die Information über den Ablauf der Befugnis EU-Zugriff nur angezeigt wird, während der Nutzer auf dem Gerät aktiv ist.

Der zeitliche Ablauf der Befugnis EU-Zugriff wird nicht durch das ePA-Aktensystem signalisiert.

6.2.7 Verbergen und Sichtbarmachen von Dokumenten

Dokumente 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:

• 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.
• 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.

Die Datenkategorien sind in der Legal Policy (A_19303) aufgeführt.

Das 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 die verborgenverborgenen 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 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 Konfiguration der General Deny Policy erfolgt im Constraint Management des ePA-Aktensystems.

A_24357 - ePA-Frontend des Versicherten: Verbergen von Dokumenten - Schnittstelle

Das ePA-Frontend des Versicherten MUSS 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_26380 - ePA-Frontend des Versicherten: Verbergen von Dokumenten durch ConfidentialityCode "CON"

Das ePA-Frontend des Versicherten KANN es dem Nutzer ermöglichen, Dokumente direkt als verborgene Dokumente einzustellen (Verwendung des confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491)). [<=]

A_25144 - ePA-Frontend des Versicherten: Verbergen von Dokumenten – Hinweis auf mögliche versorgungsrelevante Folgen

Das ePA-Frontend des Versicherten MUSS dem Nutzer im Anwendungsfall "Verbergen 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.1 Kategorienbasiertes Verbergen von Dokumenten

Das 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 befugte Leistungserbringerinstitutionen nicht sichtbar sind. Die möglichen Datenkategorien zum Verbergen ergeben sich aus den Kategorien des XDS Document Service (siehe A_19303*) außer eMP.

A_19685-01 - ePA-Frontend des Versicherten: Anzeige der zugehörigen Datenkategorie

Das ePA-Frontend des Versicherten MUSS dem Nutzer die dem Dokument zugeordnete Datenkategorie, die in den Anforderungen A_14761-* und A_19388-* aufgeführt sind, anzeigen können.  [<=]

A_19690 - ePA-Frontend des Versicherten: Optische Kennzeichnung der Datenkategorien

Das ePA-Frontend des Versicherten KANN dem Nutzer die zugeordnete Datenkategorie eines Dokumentes durch typografische Auszeichnung wie etwa Schriftfarbe, Hintergrundfarbe, Schriftart oder auch die Anordnung in Gruppen optisch kennzeichnen. [<=]

A_24454-01 - ePA-Frontend des Versicherten: Anzeige der für den LEI verborgenen Datenkategorien

Das ePA-Frontend des Versicherten MUSS dem Nutzer anzeigen können, welche Datenkategorien für alle Leistungserbringerinstitutionen verborgen sind. [<=]

Damit kann der Nutzer vor dem Besuch einer Leistungserbringerinstitution sehen, welche Datenkategorien der ePA bei der LEI verborgen sind.

Das ePA-AkensystemAktensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung von Berufsgruppen durch, siehe Legal Policy. 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_24455 - ePA-Frontend des Versicherten: Anzeige der für eine befugte LEI prinzipiell geltenden Zugriffsregeln

Das ePA-Frontend des Versicherten MUSS dem 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 Verbergen von Dokumenten erfolgt für alle Leistungserbringerinstitutionen gemeinsam.

Eine Auswahl einzelner Dokumente, die verborgen werden sollen, kann der Nutzer über 6.2.8.1.2 Dokumente suchen ermitteln. 

Bei der Konfiguration der Policy 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_24363-01 - ePA-Frontend des Versicherten: Verbergen von Dokumenten für alle Leistungserbringerinstitutionen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, ein oder mehrere ausgewählte Dokumente für alle Leistungserbringerinstitutionen im ePA-Aktensystem zu verbergen. Falls Dokumente untereinander assoziiert sind, MUSS dem Nutzer angezeigt werden, dass alle miteinander assoziierten Dokumente zusammen verborgen werden. [<=]

A_24364 - ePA-Frontend des Versicherten: Sichtbar machen von Dokumenten für alle Leistungserbringerinstitution

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen, ein oder mehrere ausgewählte für alle Leistungserbringerinstitutionen im ePA-Aktensystem verborgenen Dokumente sichtbar zu machen. [<=]

A_24362 - ePA-Frontend des Versicherten: Anzeige von verborgenen Dokumenten für alle Leistungserbringerinstitutionen

Das ePA-Frontend des Versicherten MUSS dem Nutzer die im ePA-Aktensystem für alle Leistungserbringerinstitutionen verborgenen Dokumente auflisten können. [<=]

6.2.8 Medical Services

6.2.8.1 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_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. [<=]

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 gemäß [XDSDocumentService]. [<=]

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 den XDS Document Service einstellen.
[<=]

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.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_24706 - ePA-Frontend des Versicherten: Dokumente suchen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen Dokumente in der Akte zu suchen unter Verwendung der Operation I_Document_Management_Insurant::RegistryStoredQuery des XDS Document Service gemäß [XDSDocumentService]. [<=]

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. [<=]

A_25190 - ePA-Frontend des Versicherten: Nutzung des Anfragetyps "FindDocumentsByComment"

Das ePA-Frontend des Versicherten MUSS den 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. [<=]

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.

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. [<=]

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_Aktensystem_ePAfuerAlle#A_24764*) in der Ergebnismenge als solche kennzeichnen können.
[<=]

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 Vertreter Dokumente aus dem Aktenkonto zum Anzeigen oder lokalen Speichern herunterladen.

A_15475-01 - ePA-Frontend des Versicherten: Dokumente einer Suchanfrage verarbeiten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, Dokumente aus dem Ergebnis einer Suchanfrage zum herunterzuladen (bspw. für die Anzeige oder lokales Speichern). [<=]

A_24708 - ePA-Frontend des Versicherten: Dokumente herunterladen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen Dokumente aus der Akte herunterzuladen unter Verwendung der Operation I_Document_Management_Insurant::RetrieveDocumentSet des XDS Document Service gemäß [XDSDocumentService]. [<=]

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 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. [<=]

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.8.1.4 Dokumente im Aktenkonto löschen

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein Vertreter Dokumente im Aktenkonto löschen. Die Dokumente sind damit unwiederbringlich aus dem ePA-Aktensystem entfernt.

A_15480-01 - 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. Falls Dokumente untereinander assoziiert sind, MUSS dem Nutzer angezeigt werden, dass alle miteinander assoziierten Dokumente zusammen gelöscht werden.  [<=]

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_24709 - ePA-Frontend des Versicherten: Dokumente löschen

Das ePA-Frontend des Versicherten MUSS dem Nutzer ermöglichen Dokumente in der Akte zu löschen unter Verwendung der Operation I_Document_Management_Insurant::RemoveMetadata des XDS Document Service gemäß [XDSDocumentService]. [<=]

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_24353 - ePA-Frontend des Versicherten: Dokumente löschen – Hinweis auf löschen

Das 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öglichkeit des Verbergens von Dokumenten und Datenkategorien hinweisen. [<=]

Hinweis: Es reicht aus, dass der Hinweis auf verbergenVerbergen 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 gemäß [XDSDocumentService].
[<=]

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-AkensystemAktensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung für Versicherte und Vertreter durch, siehe Legal Policy. 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 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. [<=]

Eine Ä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.

A_25241-01 - ePA-Frontend des Versicherten: keine Anzeige von confidentialityCode = "CON"

Das ePA-Frontend des Versicherten DARF bei der Aktualisierung von Metadaten NICHT den confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491 ) zur Anzeige bringen. [<=]

Der confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) ist für den Nutzer nicht relevant.

6.2.8.2 Medication Service

Die elektronische Medikationsliste (eML) wird, die arzneimitteltherapiesicherheitsrelevanten Zusatzinformationen (AMTS-rZI) sowie der elektronische Medikationsplan (eMP) )werden im ePA-Aktensystem durch den Medication Service umgesetzt.

 Ein Nutzer des FdV kann die in seinem Aktenkonto gespeicherte Medikationslistegespeicherten Medikationsdaten 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-02 - ePA-Frontend des Versicherten: Medikationsliste anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung der "Operation API: Medikationsliste abrufen" des FHIR Implementation Guide für den Medication Service [IG_Medication_Service] die Medikationsliste anzuzeigen. [<=]

A_2494724949-01 - ePA-Frontend des Versicherten: Medikationsliste (FHIR-Schnittstelledurch das Aktensystem gerendert) 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 [Ider "Render API: Medikationsliste abrufen" des FHIR Implementation Guide für den Medication Service [IG_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_26342 - ePA-Frontend des Versicherten: Medikationsplan anzeigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung der "Operation API: Medikationsplan abrufen" des FHIR Implementation Guide für den Medication Service [IG_Medication_Service] den aktuellen Medikationsplan anzuzeigen. [<=]

A_2494926343 - ePA-Frontend des Versicherten: MedikationslisteMedikationsplan (durch das Aktensystem gerendert) anzeigen

Das ePA-Frontend des Versicherten MUSS KANN es dem Nutzer ermöglichen, die Medikationsliste für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden  unter Verwendung von [Ider "Render API: Medikationsplan abrufen" des FHIR Implementation Guide für den Medication Service [IG_Medication_Service_eML_Render]] den aktuellen Medikationsplan anzuzeigen.  [<=]

A_25174-01 - ePA-Frontend des Versicherten: MedikationslisteMedikationsdaten 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)Zugriff auf Daten des Medication Service erkenntlich machen, dass die eMLdiese aufgrund des derzeitigen Widerspruchs durch Leistungserbringer nicht eingesehen und zur Behandlung des Versicherten genutzt werden kannkönnen. [<=]

6.2.9 Protokollverwaltung

Bei der Nutzung eines Aktenkontos durch verschiedene Akteure werden Aktivitäten protokolliert, damit der Aktenkontoinhaber oder ein Vertreter diese Aktivitäten nachvollziehen kann. Dazu zählen beispielsweise Zugriffe auf die Dokumente und seine Metadaten sowie auch Aktivitäten mit administrativem Charakter. Die Protokolldaten werden im Aktenkonto abgelegt und müssen für eine Anzeige unter Nutzung des Audit Event Service abgefragt werden.
Mit diesem Anwendungsfall kann ein Versicherter bzw. ein Vertreter die Protokolldaten über die Zugriffe auf das Aktenkonto des Versicherten einsehen.

A_24698-01 - ePA-Frontend des Versicherten: Protokolldaten einsehen

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 unter Verwendung von [I_Audit_Eventder "Query API: AuditEvent" des FHIR Implementation Guide für den Audit Event Service [IG_Audit_Event_Service] einzusehen. [<=]

A_24699-01 - ePA-Frontend des Versicherten: 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_Eventder "Query API: AuditEvent" des FHIR Implementation Guide für den Audit Event Service [IG_Audit_Event_Service]. [<=]

A_23547-01 - ePA-Frontend des Versicherten: Anzeige der Protokolldaten

Das ePA-Frontend des Versicherten MUSS für die Anzeige der Protokolleinträge eigene, auch für Nutzer ohne technisches Vorwissen oder spezifisches ePA-Wissen verständliche Beschreibungen anstelle der Inhalte des Protokolleintrages verwenden. [<=]

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 vom 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 Geräteverwaltung

Die Geräteverwaltung erfolgt im ePA-Aktensystem durch das Device Management.

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_24802 - ePA-Frontend des Versicherten: Anzeigename für registriertes Gerät ändern

Das ePA-Frontend des Versicherten MUSS 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. [<=]

A_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öschernlöschen. [<=]

A_25237 - ePA-Frontend des Versicherten: registriertes Gerät bestätigen

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, den Geräteregistrierungscode (Confirmation Code) zur Bestätigung einer neuen Geräteregistrierung einzugeben und diesen mit der Operation confirmDevice gemäß [I_Device_Management_Insurant.yaml] an das Aktensystem senden [<=]

A_25292 - ePA-Frontend des Versicherten - Eingabe eines falschen Geräteregistrierungscodes

Falls das Device Management dem ePA-FdV für den vom Versicherten am ePA-FdV eingegebenen Geräteregistrierungscode (Confirmation Code) in einer Fehlermeldung einen Fehlerzähler zurückmeldet, weil der Geräteregistrierungscode nicht zum deviceIdentifier passt, MUSS das ePA Frontend des Versicherten dem Versicherten ermöglichen, erneut einen Geräteregistrierungscode einzugeben und den Versicherten darauf hinweisen, dass sich die Anzahl der erlaubten Versuche zur Eingabe des Geräteregistrierungscodes reduziert hat.
[<=]

6.2.11 Verwaltung von E-Mail-Adressen

Dieses Kapitel beschreibt Anwendungsfälle zur Administration der E-Mail-Adresse eines Nutzers. 

Die E-Mail-Adresse eines Nutzers wird am Home-AS verwaltet. Als Home-AS wird das ePA-Aktensystem desjenigen Betreibers bezeichnet, der vom Kostenträger des Versicherten beauftragt wurde.

Im ePA-Aktensystem wird die Verwaltung der E-Mail-Adresse im Email Management Service realisiert. Ein Nutzer kann nur seine eigene E-Mail-Adresse verwalten. Die emailE-Mail-Adresse ist Voraussetzung für die Geräteregistrierung, d.h. um ein ePA FdV nutzen zu können muss bei der ersten Nutzung durch das ePA FdV bereits eine E-Mail-Adresse für den Nutzer hinterlegt sein. Die aktuelle E-Mail-Adresse kann zur Anzeige abgerufen oder geändert werden.

In diesem Kapitel werden die folgenden Anwendungsfälle umgesetzt:

• die für den Nutzer hinterlegten E-Mail-Adressen anzeigen
• E-Mail-Adresse für den Nutzer ändern

A_25442-01 - ePA-Frontend des Versicherten: E-Mail-Verwaltung am Aktensystem - Nutzung Schnittstelle

Das ePA-Frontend des Versicherten MUSS beim ErstellenÄndern und Anzeigen der E-Mail-Adresse am ePA-Aktensystem die Operationen der Schnittstelle I_Email_Management gemäß [I_Email_Management] verwenden. [<=]

A_25443-01 - ePA-Frontend des Versicherten: E-Mail-Adressen verwalten

Das ePA-Frontend des Versicherten MUSS es dem Nutzer ermöglichen, seine im Aktensystem hinterlegte E-Mail-Adresse einzusehen und die E-Mail-Adresse zu ändern. [<=]

A_25721 - ePA-Frontend des Versicherten: Hinweis auf Benachrichtigungsmail

Das ePA-Frontend des Versicherten MUSS den Nutzer beim Hinterlegen einer neuen E-Mail-Adresse am ePA-Frontend des Versicherten darauf hinweisen, dass ihm eine E-Mail an die neu hinterlegte E-Mail-Adresse gesendet wird und dass der Nutzer die im Aktensystem hinterlegte E-Mail-Adresse nochmals prüfen sollte, falls er die E-Mail nicht erhält.
[<=]

6.2.12 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 mussMUSS dem Versicherten die Migration der Daten von ePA 2.6 nach ePA für alle ermöglichen und dabei folgende Schritte umsetzen:

1. Akten- und Kontextschlüssel werden dem Aktensystem ePA für alle bereitgestellt. 
2. 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 ePaePA-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 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. [<=]

7 Verteilungssicht

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

8.3 Abbildungsverzeichnis

Abbildung 1: Komponenten ePA-Frontend des Versicherten

Abbildung 2 : Authentisieren des Nutzers

8.4 Tabellenverzeichnis

Tabelle 1: Akteure und Rollen

Tabelle 2: Schnittstellen des ePA-Aktensystems

Tabelle 3: Komponenten des FdV

Tabelle 4: IHE Akteure und Transaktionen

Tabelle 5: Parameter FdV

Tabelle 6 : Tab_UX_KPI_Messung_ePA

Tabelle 7: ePA-Aktensystem Komponenten, Schnittstellen-Konfiguration

Tabelle 8: FHIR Suche LEI

Tabelle 9: FHIR Suche DiGA

Tabelle 10: Vertretung am fremden FdV verwaltenFHIR Suche EU-Land

Tabelle 11: Value Set - Empfehlungen für die AnzeigeVertretung am fremden FdV verwalten

Tabelle 12: Value Set authorSpecialty- Empfehlungen für die Anzeige

Tabelle 13: Value Set classCodeauthorSpecialty

Tabelle 14: Value Set eventCodeListclassCode

Tabelle 15: Value Set healthcareFacilityTypeCodeeventCodeList

Tabelle 16: Value Set practiceSettingCodehealthcareFacilityTypeCode

Tabelle 17: Value Set typeCodepracticeSettingCode

Tabelle 18: Value Set typeCode

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

8.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 1112: Value Set - Empfehlungen für die Anzeige

Tabelle 1213: 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 1314: Value Set classCode

Tabelle 1415: Value Set eventCodeList

Tabelle 1516: Value Set healthcareFacilityTypeCode

Tabelle 1617: Value Set practiceSettingCode

Tabelle 1718: Value Set typeCode