gemSpec_ePA_FdV_V2.1.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation ePA-Frontend des Versicherten

    

     

      
Version
      
2.1.0
     
     

      
Revision
      
875646
     
     

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

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.

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

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

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

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.

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

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

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.

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.

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.

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

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

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.

Tracking Anforderungen für Trackingdaten ohne Einwilligung

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

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.

Anforderungen zur Einwilligung zum Session-übergreifenden Tracking

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

5.1.1 Anforderungen bei CC-Zertifizierung

5.2 Verwendete Standards

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

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

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

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

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.

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

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.

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.

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.

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.  

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

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.

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

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.

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.

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.

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:

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.

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.

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

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.

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.

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.

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.

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 ePA-Aktensystem aufgerufen. Als Ergebnis wird an das FdV die DeviceID mit deviceIdentifier als Gerätekennung und das deviceToken als Sicherheitsmerkmal zurückgegeben. Diese DeviceID wird für den Nutzer im FdV persistent gespeichert und kann beim Login am ePA-Aktensystem für die Überprüfung der Registrierung des verwendeten Geräts mitgegeben werden.Der Zugriff auf ein Aktenkonto ist erst nach erfolgreicher Prüfung der DeviceID 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.

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

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

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

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

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

1. initial auf die CA-Zertifikate von GlobalSign, DigiCert und Entrust aus der Liste von https://wiki.mozilla.org/CA/Included_Certificates -> "Included CA Certificates" beschränkt werden.
2. weiterhin muss die Liste die CA-Zertifikate von ISRG (Let's encrypt) enthalten (fachlicher Hintergrund: das Gesundheitspotral https://gesund.bund.de/ verwendet diesen TSP).
3. und zukünftig auf eine Menge von CA-Zertifikaten beschränkt werden, die in Abhängigkeit zu [gemSpec_Aktensystem_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.

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.

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.

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.

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.

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.

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

Wenn die Möglichkeit besteht, dass der Nutzer das fehlerverursachende Problem selbst beheben kann, kann das FdV den Nutzer auf die Lösung hinweisen.

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

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.

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.

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.

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.

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.

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.

Benachrichtigungen

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

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.

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.

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.

Einige Funktionen haben weitergehende Auswirkungen, die vor einem Widerspruch gegen die Nutzung der Funktionen berücksichtigt werden müssen (siehe dazu die Kapitel "Auswirkungen bei Widerspruch gegen Funktionen der ePA auf die Dokumente des Aktenkontos" in den Kapiteln "XDS Document Service" und "Medication Service"[gemSpec_Aktensystem_ePAfueralle]).

Der Nutzer hat die Möglichkeit, die Daten vor Erteilung eines Widerspruchs aus seiner Akte lokal zu speichern (siehe Dokument herunterladen).

Die Anzeige der widerspruchsfähigen Funktionen und deren aktueller Zustand (Widerspruch erklärt/nicht erklärt) erfolgt durch das FdV. Ein Nutzer des FdV kann die aktuelle Einstellung bei Bedarf ändern, also Widersprüche erklären oder zurücknehmen.
Dabei ist die umfassende Information eines Nutzers vor einer Änderungsausführung gemäß A_23870-* zu beachten.

6.2.5.2 Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI

Der Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI erfolgt über die Ombudsstelle des zuständigen Kostenträgers oder das ePA-Frontend des Versicherten. Dabei wird im Entitlement Management vermerkt, dass für die spezifische LEI keine Befugnisse registriert werden können.

6.2.6 Befugnisverwaltung

Dieses Kapitel beschreibt Anwendungsfälle zur Vergabe und Administration von Befugnissen (Entitlements) zum Zugriff auf das Aktenkonto. Im ePA-Aktensystem wird die Verwaltung der Befugnisse im Entitlement Management realisiert.
Mit einer Befugnis befähigt der Versicherte einen Nutzer oder eine DiGA zur Verarbeitung seiner Daten. Es können nur Befugnisse für die in A_23941 aufgeführten Nutzer bzw. Nutzergruppen erteilt werden.

Ein Versicherter ist immer zum Zugriff auf sein Aktenkonto befugt.
Ein Vertreter ist nur befugt, wenn dies explizit durch den Versicherten für sein Aktenkonto vergeben wurde. 
Eine LEI ist nur befugt, wenn:

• dies explizit durch den Versicherten oder Vertreter für das Aktenkonto des Versicherten vergeben wurde, oder
• eine Behandlungssituation in der LEI vorlag und somit automatisch eine Befugnis für die Telematik-ID dieser LEI des zugehörigen Aktenkontos erstellt wurde.

Eine DiGA ist nur befugt, wenn:

• dies explizit durch den Versicherten oder Vertreter für sein Aktenkonto vergeben wurde

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

Die Prüfung des Zugriffs durch den Nutzer auf die Daten bzw. Dokumente des Aktenkontos erfolgt durch das ePA-Aktensystem.

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. 

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"

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

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"

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.

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.

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.

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

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

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.

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:

1. 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.
2. 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 verborgen Dokumente oder Datenkategorien aus, welche er sichtbar machen möchte. Das ePA-Frontend des Versicherten übermittelt diese Auswahl an den Constraint Management Service, welcher sie in der General Deny Policy 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.

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.

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

Das ePA-Akensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung von Berufsgruppen durch, siehe 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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Hinweis: Es reicht aus, dass der Hinweis auf verbergen nur ein Mal während einer laufenden User-Session angezeigt wird.

6.2.8.1.5 Metadaten von Dokumenten ändern

Mit diesem Anwendungsfall kann ein Versicherter bzw. ein befugter Vertreter die Metadaten von Dokumenten in der ePA ändern. Es dürfen ausschließlich Metadaten gemäß A_15083* am ePA-FdV durch ein Metadaten-Update geändert werden.

Beim Aufruf von I_Document_Management_Insurant::RestrictedUpdateDocumentSet muss immer für "previousVersion" in der Nachricht der Wert "1" angegeben werden, da der Aufruf seitens des XDS Document Service nicht für eine echte Versionierung der alten Dokumentenmetadaten genutzt wird. Serverseitig wird DocumentEntry.version entsprechend nicht verwaltet und besitzt standardmäßig deshalb immer den impliziten Wert 1.

Das ePA-Akensystem setzt die gesetzlichen Vorgaben zur Zugriffsbeschränkung für Versicherte und Vertreter durch, siehe Legal Policy. Das ePA-Frontend des Versicherten unterstützt den Nutzer dabei,

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.

Der confidentialityCode ist für den Nutzer nicht relevant. Um Fehlkonfigurationen zu vermeiden darf der confidentialityCode bei der Aktualisierung von Metadaten durch das FdV nicht zur Anzeige gebracht werden.

6.2.8.2 Medication Service

Die elektronische Medikationsliste (eML) wird im ePA-Aktensystem durch den Medication Service umgesetzt.

Ein Nutzer des FdV kann die in seinem Aktenkonto gespeicherte Medikationsliste einsehen. Es gibt verschiedene Formen in welcher die Medikationsliste abgerufen werden kann entweder über das  FHIR API, die Liste im Format pdf oder als xhtml zur Anzeige im Browser.

Das Rendering der FHIR-Daten für die Anzeige erfolgt bei Abfrage der FHIR-Schnittstelle durch das FdV.

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

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. 

6.2.10 Geräteverwaltung

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

6.2.11 Verwaltung von E-Mail-Adressen

Dieses Kapitel beschreibt Anwendungsfälle zur Administration von email-Adressen eines Nutzers. Im ePA-Aktensystem wird die Verwaltung der E-Mail-Adressen im Email Management Service realisiert. Ein Nutzer kann nur seine eigenen email-Adressen verwalten. Ist nur eine email-Adresse für den Nutzer hinterlegt kann diese nicht gelöscht werden. Das Ändern einer email-Adresse wird realisiert durch das Einstellen einer neuen und löschen der alten email-Adresse.

In diesem Kapitel werden die folgenden Anwendungsfälle umgesetzt:

• alle für den Nutzer hinterlegten email-Adressen abrufen
• neue email-Adresse für den Nutzer hinterlegen
• email-Adresse für den Nutzer löschen

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.

6.3 Testtreiber-Modul für ePA-Frontend des Versicherten

Für die automatisierten Tests des gematik im Kontext von Zulassungsverfahren des ePA-Frontend des Versicherten muss der Hersteller ein Testtreiber-Modul implementieren.  Dieses ist entweder in ein Test-FdV zu integrieren oder es steuert die GUI des ePA-Frontends an. Vom Hersteller ist der gematik der Zugriff auf das Test-FdV bzw. zu testende ePa-Frontend über das Interface des Testtreibermoduls entsprechend [gemKPT_Test# ] zu ermöglichen.

Das Außeninterface des TesttreiberModuls [I_Test_Driver_FdV] wird im Fachportal der gematik und in GitHub als normativer Bestandteil der Spezifikation veröffentlicht.

Das Testtreiber-Modul darf die Ausgaben des ePA-Frontend des Versicherten gemäß der technischen Schnittstelle aufarbeiten, aber darf die Inhalte nicht verfälschen.

Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren beschränkt und darf nicht in Wirkbetriebs-Apps genutzt werden.

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

8.4 Tabellenverzeichnis

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

Tabelle 12: Value Set authorSpecialty

Hinweis: Im Zuge der Value Set-Pflege wurde das Code-System "S_BAR2_WBO" (OID 1.2.276.0.76.5.114) für Fachgruppen-Codes nach der Weiterbildungsordnung Bundesarztregister in das neue Code-System "Facharzttitel der Ärztekammern" (OID: 1.2.276.0.76.5.514) konsolidiert, welches zukünftig das alte System ersetzt. Aufgrund der notwendigen Abwärtskompatibilität muss im Value Set "DocumentEntry.authorSpecialty" (OID: 1.2.276.0.76.11.31) für Spezialisierungen eines Dokumentenautors weiterhin das Code-System "S_BAR2_WBO" durch ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, lesend unterstützt werden. Für das Value Set "SubmissionSet.authorSpecialty" gilt dies analog. Neue Dokumente oder SubmissionSets dürfen nicht mehr mit Codes aus "S_BAR2_WBO" gekennzeichnet werden. 

Tabelle 13: Value Set classCode

Tabelle 14: Value Set eventCodeList

Tabelle 15: Value Set healthcareFacilityTypeCode

Tabelle 16: Value Set practiceSettingCode