Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Fachmodul ePA

    

     

      
Version
      
1.53.0
     
     

      
Revision
      
988102
     
     

      
Stand
      
03.04.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_ePA
     
    

Dokumentinformationen

Ä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

Das Fachmodul ePA ist Teil der Fachanwendung ePA, die im Systemkonzept [gemSysL_ePA] beschrieben wird. Als Teil des Konnektors kommt das Fachmodul ePA in der Leistungserbringerumgebung zum Einsatz und ist damit Bestandteil der dezentralen TI. Es bietet Primärsystemen Schnittstellen an, um medizinische Dokumente für Versicherte in einem ePA-Aktensystem zu verwalten.

Die vom Fachmodul ePA bereitzustellenden Schnittstellen basieren zu großen Teilen auf den Spezifikationen der IHE-Initiative. Insbesondere kommen IHE-Integrationsprofile aus der Familie XDS.b (Cross-Enterprise Document Sharing) zum Einsatz. Neben den Primärsystemen kommuniziert das Fachmodul ePA auch mit ePA-Aktensystemen, welche die Dokumente der Versicherten verwalteten. ePA-Aktensysteme können von mehreren Anbietern zur Verfügung gestellt werden, wobei die Dokumente eines einzelnen Versicherten immer genau bei einem Anbieter ePA-Aktensystem hinterlegt werden.

Diese Spezifikation beschreibt Anforderungen an die Schnittstellen, die vom Fachmodul ePA selbst angeboten werden müssen und an die daraus resultierende Funktionalität. Dazu nutzt das Fachmodul ePA die Schnittstellen des ePA-Aktensystems und weiterer zentraler TI-Komponenten.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller des Produkttyps Konnektor sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

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

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

Die vollständige Anforderungslage für den Konnektor ergibt sich aus weiteren Spezifikationsdokumenten, die im Produkttypsteckbrief verzeichnet sind.

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.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

Referenz auf eine Anforderung:

<AFO-ID> - *

Das Zeichen '*' steht hierbei für den Suffix der Anforderung. Es gilt der im Dokumentenpaket gültige Suffix.

2 Systemüberblick

Die Fachanwendung ePA setzt im Rahmen der TI-Plattform eine elektronische Patientenakte (ePA), ein Aktenkonto des Versicherten um, in die Berechtigte wie der Versicherte oder autorisierte Leistungserbringer patientenbezogene Dokumentation aus verschiedenen Einrichtungen einstellen und verwalten können. Die Fachanwendung erlaubt das Einstellen, Suchen, Abrufen und Löschen von Dokumenten sowie die Aktualisierung von Metadaten bestehender Dokumente.

Die Fachanwendung ePA besteht aus Sicht dieser Spezifikation aus zwei Teilen: Einerseits dem dezentralen Fachmodul, das Teil des Konnektors ist und nach außen eine Schnittstelle für die Verwaltung der Dokumente bietet und anderseits dem zentralen Fachdienst ePA-Aktensystem, der die Dokumente innerhalb der TI-Plattform speichert, Berechtigungen verwaltet und durchsetzt usw. und den beiden Schlüsselgenerierungsdiensten (SGD). Das außerdem zur Fachanwendung gehörende „ePA-Modul Frontend des Versicherten“ ist für dieses Dokument nicht relevant und wird deshalb nicht weiter behandelt.

Diese Spezifikation beschreibt das Fachmodul ePA und dessen Außenschnittstelle, die von Primärsystemen (z. B. KIS und PVS) genutzt wird, um Dokumente zu verwalten. Um beim Leistungserbringer „ad hoc“ Zugriffsberechtigungen zu Dokumenten vom Patienten einzuholen, findet zudem bei Bedarf eine Kommunikation mit dem Kartenterminal statt. Zusätzlich beschreibt diese Spezifikation die Nutzung der Schnittstelle des ePA-Aktensystems, welches die eigentliche Dokumentenverwaltung, Autorisierung und weitere Details umsetzt.

Ein ePA-Aktensystem kann durch mehr als einen Anbieter angeboten werden. Die Akte des Versicherten wird zu einem Zeitpunkt jedoch immer nur exklusiv von einem einzigen Anbieter ePA-Aktensystem geführt, der alle Dokumente des Versicherten verwaltet und über das ePA-Aktensystem bereitstellt.

Über das ePA-Aktensystem hinaus interagiert das Fachmodul ePA unter Verwendung der Basisdienste des Konnektors mit dem Verzeichnisdienst der TI-Plattform, um Details zu Leistungserbringern und -institutionen abzurufen sowie anderen zentralen TI-Diensten (Zeitdienst, Namensdienst).

ePA-Aktensysteme speichern aus Datenschutzgründen alle Dokumente in verschlüsselter Form. Die Verschlüsselung beim Einstellen und die Entschlüsselung beim Herunterladen erfolgt immer im Fachmodul (nicht in den Primärsystemen). Um eine im ePA-Aktensystem eingehende Suchanfrage nach Dokumenten im ePA-Aktensystem trotz verschlüsselter Daten durchführen zu können, wird für jedes Dokument zusätzlich ein Satz an unverschlüsselten Metadaten gespeichert. Dazu gehören das Dokumentenformat (z. B. PDF), der Dokumententyp (z. B. Notfalldatensatz), Erstellungsdatum und -uhrzeit und der Autor des Dokuments.

Für den Zugriff auf Metadaten und Dokumente muss ein Nutzer (in diesem Dokument Leistungserbringerinstitutionen) sich über das Fachmodul ePA authentisieren und vom ePA-Aktensystem autorisiert werden. Um den Zugriff des Anbieters ePA-Aktensystem auf die im Klartext vorliegenden Metadaten zu verhindern, werden diese zusätzlich über eine vertrauenswürdige Ausführungsumgebung (VAU) geschützt.

3 Systemkontext

Das Fachmodul ePA ist eingebettet in den Produkttyp Konnektor. Die Beschreibung aller direkt mit dem Fachmodul kommunizierenden Akteure ist im vorgehenden Kapitel beschrieben. Eine weitere Beschreibung des Systemkontexts ist nicht erforderlich.

4 Zerlegung des Produkttyps

Eine weitere Untergliederung des Fachmoduls ePA in Komponenten ist nicht erforderlich.

5 Technologien und Standards

Die Schnittstellen und die Verarbeitungslogik der Fachmoduls basiert auf Transaktionen des IHE ITI Technical Frameworks [IHE-ITI-TF]. Es werden soweit wie möglich Cross-Community Access-Profile angewendet.

Der Profilierung von IHE ITI-Transaktionen als Umsetzungsvorgabe für die Außenschnittstellen der Dokumentenverwaltung des ePA-Aktensystems liegt die folgende Herangehensweise zugrunde:

1. Auswahl relevanter IHE ITI-Integrationsprofile
2. Logische Gruppierung zwischen IHE ITI-Akteuren mit Auswahl relevanter IHE ITI-Transaktionen.
3. Übergreifende Einschränkung von IHE ITI-Transaktionen
4. Festlegung spezieller Umsetzungsvorgaben bzgl. einzelner Transaktionen

5.1 Webservices

5.2 Integrating the Healthcare Enterprise (IHE)

5.2.1 Relevante IHE-Integrationsprofile

Für die Umsetzung des Fachmoduls sind die folgenden Integrationsprofile relevant:

• Cross-Enterprise Document Sharing (XDS.b) Profile
• Cross-Community Access (XCA) Profile
• Cross-Community Document Reliable Interchange  (XCDR) Profile
• Cross-Enterprise Document Reliable Interchange (XDR) Profile
• Remove Metadata and Documents (RMD) Profile
• Cross-Enterprise User Assertion (XUA) Profile
• Advanced Patient Privacy Consents (APPC) Profile

Ihre Verwendung im Fachmodul wird im Folgenden kurz erläutert:

XDS.b (Cross-Enterprise Document Sharing) Profile

XDS.b [IHE-ITI-TF], im Weiteren nur als XDS bezeichnet, stellt die Grundlage für die Umsetzung von IHE-Patientenakten dar. Die mit dem Fachmodul verbundenen Primärsysteme bei den Leistungserbringern operieren als Akteure Document Source und Document Consumer, während das ePA-Aktensystem die Akteure Document Repository und Document Registry bereitstellt.

Das Fachmodul ePA selbst muss zwischen Primärsystem und ePA-Aktensystem vermitteln, also die XDS-basierten Primärsystemnachrichten entgegennehmen, verarbeiten und an das ePA-Aktensystem weiterleiten; das Fachmodul ePA übernimmt also eine Art Proxyfunktionalität, nimmt die Anfragen von Primärsystemen (Document Source/Consumer) entgegen und leitet sie an den Anbieter ePA-Aktensystem mit der Akte des Patienten bzw. dessen Document Repository und Registry weiter. Aus diesem Grund wird auch eine Spezialisierung des XDS-Profils verwendet: XCA (siehe unten).

XCA (Cross-Community Access) Profile

XCA [IHE-ITI-TF] wird im engeren Sinne bei IHE dafür verwendet, um verschiedene „Home Communities“ miteinander zu vernetzen. Das Profil nimmt dazu geringe Änderungen an den bei XDS.b vorgesehenen Nachrichten und Akteuren zum Suchen und Herunterladen von Dokumenten vor.

Im Fachmodul ePA kommt es zum Einsatz, da XCA (zusammen mit dem XCDR-Profil, siehe unten) am besten die Proxy-artige Funktionalität des Fachmoduls darstellt, das zwischen Primärsystem und ePA-Aktensystem vermittelt und es ermöglicht, die unterschiedlichen Anbieter ePA-Aktensystem jeweils als eigene Home Community zu modellieren. Das Fachmodul ePA tritt dabei als IHE-Akteur „Initiating Gateway“ auf.

XCDR (Cross-Community Document Reliable Interchange) Profile

XCDR [IHE-ITI-XCDR] wird für das Einstellen von Dokumenten verwendet, wenn der XCA-Ansatz (siehe oben) Anwendung findet und spezialisiert vor diesem Hintergrund die in XDS dafür vorgesehene Akteure und Transaktionen. Das Fachmodul ePA arbeitet auch hier als IHE-Akteur „Initiating Gateway“, der Anbieter ePA-Aktensystem als „Responding Gateway".

XDR (Cross-Enterprise Document Reliable Interchange) Profile

Die Verwendung des Profils XCDR erzwingt auch den gleichzeitigen Gebrauch des Profils XDR, welches leicht veränderte Anforderungen beim Einstellen von Dokumenten (bezüglich Metadaten) mit sich bringt.

RMD (Remove Metadata and Documents) Profile

Gemäß [gemSysL_ePA] muss die Akte auch das Löschen von Dokumenten ermöglichen. Da dies über die Möglichkeiten der oben genannten Integrationsprofile hinausgeht, greift die Fachanwendung zusätzlich auf das Profil RMD [IHE-ITI-RMD] zurück. Das Fachmodul ePA (als IHE-Akteur „Document Repository“ bzw. als IHE-Akteur „Document Administrator“) empfängt und verarbeitet dazu die entsprechenden Nachrichten des Primärsystems und leitet diese (als IHE-Akteur Document Administrator) an das ePA-Aktensystem weiter.

XUA (Cross-Enterprise User Assertion) Profile

Das XUA-Profil [IHE-ITI-TF] wird vom Fachmodul verwendet, um sich einerseits bei der Komponente Autorisierung des Anbieters ePA-Aktensystem und andererseits beim Zugriff auf die Akte eines Versicherten bei der Dokumentenverwaltung mit Authentifizierungsinformationen des anfragenden Nutzers auszuweisen.

APPC (Advanced Patient Privacy Consents)

Das APPC-Profil [IHE-ITI-APPC] dient der Durchsetzung von Zugriffsregeln (Autorisierung) in der Fachanwendung. Das Fachmodul ePA erzeugt bei Bedarf das technische Dokument (gemäß APPC) und hinterlegt es in der Akte des Versicherten. Das ePA-Aktensystem verwendet die hinterlegten Zugriffsregeln dann, um zu entscheiden, ob der anfragende Nutzer (gemäß mitgelieferter XUA-Zusicherung) die entsprechende Operation (z. B. Herunterladen eines bestimmten Dokuments) unter Berücksichtigung der Dokumentenmetadaten durchführen darf oder die Anfrage abgelehnt werden muss.

5.2.2 Überblick über IHE-Akteure und assoziierte Transaktionen

Die Abbildung in Abschnitt [gemSpec_DM_ePA#2.1.3] zeigt, welche IHE ITI-Akteure insgesamt in der Fachanwendung ePA wie gruppiert sind und welche zugehörigen Transaktionen angewendet werden.

Die folgenden Schilderungen beschreiben beispielhaft die drei häufigsten Anwendungsfälle, das Einstellen, Suchen und Herunterladen von Dokumenten aus Sicht des Fachmoduls ePA.

Gemäß der Nutzung von Cross-Community-Profilen, ist die IHE-basierte Nachrichtenübermittlung durch Transaktionen gekennzeichnet, um ein Dokument durch den Mitarbeiter einer Leistungserbringerinstitution in die elektronische Patientenakte eines Versicherten zu speichern. Ein Primärsystem in der Consumer Zone erzeugt ein Dokument, das vom System als XDR-Akteur „Document Source" in die Akte eines Versicherten gespeichert werden soll. Beim Einstellen kommen anschließend die folgenden IHE ITI-Transaktionen zum Tragen:

1. Provide & Register Document Set-b [ITI-41]: Das Primärsystem bzw. der XDR-Akteur „Document Source" sendet eine Nachricht zum Speichern ein oder mehrerer Dokumente an den XDR-Akteur „Document Recipient" bzw. den gruppierten XCDR-Akteur „Initiating Gateway", welcher durch das Fachmodul ePA umgesetzt wird.
2. Cross-Gateway Document Provide [ITI-80]: das Fachmodul ePA nimmt einige Transformationen an der Nachricht vor (z. B. Verschlüsselung des Dokuments) und leitet sie als XCDR „Initiating Gateway" an das XCDR „Responding Gateway" des Anbieters ePA-Aktensystem weiter.
3. Es erfolgt das akteninterne Registrieren und Speichern der Dokumente. Die Umsetzungsdetails werden zu großen Teilen den Anbietern ePA-Aktensystem überlassen.

Für das Suchen von Dokumenten werden die folgenden IHE-Transaktionen eingesetzt:

1. Registry Stored Query [ITI-18]: Das Primärsystem bzw. der XDS-Akteur „Document Consumer" sucht Dokumente anhand gewünschter Suchkriterien, in dem es eine entsprechende Nachricht an den XCA-Akteur „Initiating Gateway" sendet, der vom Fachmodul repräsentiert wird.
2. Cross-Gateway Query [ITI-38]: das Fachmodul ePA bzw. der XCA-Akteur „Initiating Gateway" leitet die Suchanfrage an den Anbieter ePA-Aktensystem weiter, der den XCA-Akteur „Responding Gateway" umsetzt.
3. Die Suche innerhalb der Akte wird vom Anbieter ePA-Aktensystem durchgeführt und Suchergebnisse über „Responding Gateway" und „Initiating Gateway" an das Primärsystem zurückgeliefert.

Das Herunterladen von Dokumenten wird über die folgenden Transaktionen umgesetzt:

1. Retrieve Document Set [ITI-43]: Das Primärsystem stößt als XDS-Akteur „Document Consumer" den Download eines oder mehrerer Dokumente an.
2. Cross-Gateway Retrieve [ITI-39]: das Fachmodul ePA als XCA-Akteur „Initiating Gateway" nimmt die Anfrage entgegen und leitet sie an den Anbieter ePA-Aktensystem (XCA-Akteur „Responding Gateway") weiter.
3. Die angefragten Dokumente werden vom Anbieter ePA-Aktensystem über XCA „Responding Gateway" und „Initiating Gateway" an das Primärsystem zurückgeliefert.

Das Fachmodul ePA muss alle Anfragen an denjenigen Anbieter ePA-Aktensystem weiterleiten, der die Akte für den jeweiligen Versicherten führt. Dazu nutzt es die vom Primärsystem bei jeder Anfrage mit bereitgestellte HomeCommunityID, die den Anbieter ePA-Aktensystem eindeutig identifiziert. Um die HomeCommunityID verlässlich verwenden zu können, geht die Fachmodulspezifikation an einigen Stellen über die Anforderungen von IHE hinaus (z.B. Ermittlung der HomeCommunityID über den Namensdienst der TI).

6 Übergreifende Festlegungen

6.1 Allgemein

Die folgenden Anforderungen gelten für das gesamte Fachmodul. Im Gegensatz dazu gibt es auf der Ebene der Webservices Festlegungen, die dann jeweils nur für dessen Operationen greifen.

Übergreifende Festlegung für die Kommunikation mit ePA-Aktensystemen

Eine Operation, die nur mit einem ePA-Aktensystem kommunizieren muss, bricht demnach ab, falls eine der genannten Komponenten zwingend benötigt wird und nicht zur Verfügung steht. Eine Operation, die mit mehreren ePA-Aktensystemen kommunizieren muss, bricht erst ab wenn eine der Komponenten zwingend benötigt wird und in allen ePA-Aktensystemen nicht zur Verfügung steht. Sonderfälle, falls z.B. ein ePA-Aktensystem komplett ausfällt, werden in den Operationen unterschiedlich behandelt (vgl. auch Kapitel 6.11).

Für Operationen, die mit genau einem Aktensystem kommunizieren, wird die Operation mit dem Fehler abgebrochen, wenn die Fehlersituation beim Zugangsgateway des Versicherten oder bei der Komponente Autorisierung oder bei der Komponente Dokumentenverwaltung auftritt.
Für Operationen, die mit mehr als einem Aktensystem kommunizieren, wird die Operation nur dann mit dem Fehler abgebrochen, wenn die Fehlersituation zu allen Zugangsgateways des Versicherten oder bei allen Komponenten Autorisierung oder bei allen Komponenten Dokumentenverwaltung auftritt. Treten Fehler an verschiedenen Komponenten auf, so wird im Kontext der Operation entschieden, ob mit einem Fehler (und mit welchem Code) abgebrochen wird (vgl. auch Kapitel 6.11).

Status des Aktenkontos

Hinweise:

• Eine Auflistung und Erläuterung aller Status befindet sich in [gemSpec_Aktensystem].
• Ein Aktenkonto kann nur aktiviert werden, falls es sich im Status REGISTERED befindet.
• Berechtigungen für LEI können auch bei einem Aktenkonto hinzugefügt werden, das sich im Status DISMISSED befindet.
• Falls RequestFacilityAuthorization mit einem Aktenkonto aufgerufen wird, das sich im Status REGISTERED befindet, führt das Fachmodul vorher implizit die Operation ActivateAccount durch, um das Aktenkonto zu aktivieren.

Da die Operationen GetHomeCommunityID und GetAuthorizationList mit mehreren ePA-Aktensystemen kommunizieren müssen, findet die Behandlung der Status in den jeweiligen Unterkapiteln statt.

Der Status und die Existenz eines Aktenkontos kann mit Hilfe der Operation I_Authorization_Management::checkRecordExists der Komponente Autorisierung eines ePA-Aktensystems ermittelt werden. Für manche Operationen müssen alle bekannten ePA-Aktensysteme angefragt werden, die jeweils mit verschiedenen Fehlern antworten können. Das Fachmodul zeigt mit dem Fehlercode 7215 eindeutig ein Problem auf Seite der Aktensysteme an, Fehlercode 7400 hingegen deutet auf ein Problem im Konnektor hin, bedarf aber einer genaueren Analyse der Log-Dateien.

Übergreifende Festlegungen für beteiligte Smartcards

Übergreifende Festlegungen zur Verwendung von kryptographischen Verfahren

Die Authentisierungsbestätigungen mittels einer eGK der Generation 2 wird z.B. mit C.CH.AUT.R2048 erstellt, vgl [gemSpec_Kon#TAB_KON_858].

Die Authentisierungsbestätigungen mittels einer eGK ab Generation 2.1 wird z.B. mit C.CH.AUT.E256 erstellt, vgl [gemSpec_Kon#TAB_KON_858].

Übergreifende Festlegungen zur Verwendung von Schlüsseln

Übergreifende Festlegungen zur Performanz

Die für das Fachmodul ePA relevanten Vorgaben zur Performanz befinden sich in dem Dokument [gemSpec_Perf#4.1.2.1].

Übergreifende Festlegung zur Nutzung der Basisfunktionalität des Konnektors

Zur Erzeugung von Schlüsseln kann TUC_KON_072 „Daten symmetrisch verschlüsseln“ verwendet werden, welcher als Rückgabewert einen symmetrischen Schlüssel liefert.

Die fachlichen Schnittstellen zur Nutzung des Verschlüsselungsdienstes im Konnektor sind in [gemSpec_Kon#4.1.7] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Zertifikatsdienstes im Konnektor sind in [gemSpec_Kon#4.1.9] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Signaturdienstes im Konnektor sind in [gemSpec_Kon#4.1.8] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Namensdienstes im Konnektor sind in [gemSpec_Kon#4.2.6] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Zugriffsberechtigungsdienstes im Konnektor sind in [gemSpec_Kon#4.1.1] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Protokollierungsdienstes im Konnektor sind in [gemSpec_Kon#4.1.10] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Kartendienstes im Konnektor sind in [gemSpec_Kon#4.1.5] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des TLS-Dienstes sind in [gemSpec_Kon#4.1.11] beschrieben.

Die fachlichen Schnittstellen zur Nutzung des Zeitdienstes sind in [gemSpec_Kon#4.2.5] beschrieben.

6.2 IHE

Das Aktensystem, mit dem die Operationen des Fachmoduls kommunizieren, wird durch die HomeCommunityID festgelegt. Diese wird als Teil des RecordIdentifier entweder über Aufrufparameter oder SOAP-Header übertragen. Kapitel 6.2  beschreibt alle IHE-Akteure der Fachanwendung ePA.

Hinweis: Alle spezifizierten Anforderungen der IHE ITI-Akteure in Abschnitt 6.2. definieren das zu implementierende Verhalten an den Außenschnittstellen PHRService sowie PHRManagementService. Dies schließt keine zusätzlichen implementierten IHE-Funktionalitäten innerhalb des ePA-Fachmoduls aus. Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen auch bei der Verwendung weiterer IHE-Funktionalitäten weder medizinische noch personenbezogene Daten geloggt werden, d.h. es gilt A_14155

Hinweis: Sofern zusätzliche Funktionalität im Fachmodul ePA implementiert ist, muss diese vollständig dokumentiert werden (inkl. Begründung, warum sie nicht ausführbar ist), um eine Prüfung nach der Technischen Richtlinie zu ermöglichen.

Eine Schemaprüfung der Metadaten als übergebenen Parameter findet nur im Rahmen der Schemaprüfung der Nachricht durch den zugehörigen Webservice PHRService statt. Die darüberhinausgehende, Prüfung der Metadaten gemäß der IHE-Profilierung in [gemSpec_DM_ePA#2.1.4] erfolgt im ePA-Aktensystem.

6.3 Lokalisierung von ePA-Aktensystemen

Die Versicherten haben das Recht, sich ihr Aktensystem frei unter den am Markt bestehenden Anbietern ePA-Aktensystem auszuwählen und zu wechseln. Dies bedeutet, dass vor dem Zugriff auf eine Akte immer der passende Anbieter inklusive der URL des Aktendienstes und der Endpunkte über den Namensdienst der zentralen TI abgefragt werden muss.

Das ePA-Aktensystem wird durch die HomeCommunityID adressiert, welche Bestandteil des RecordIdentifier (siehe [gemSpec_DM_ePA#2.2]) ist.

Das Fachmodul ePA kann die Lokalisierungsinformationen unabhängig von der Nutzung seiner Schnittstellen abrufen, zwischenspeichern und wiederverwenden. Es ist z.B. denkbar, dass das Fachmodul ePA die Lokalisierungsinformationen in der Bootup-Phase des Konnektors abruft.

6.4 Aufrufkontext und Auswahl eines SM-B

Die Operationen des Fachmoduls ePA werden von Mandanten mit unterschiedlichen Berechtigungen aufgerufen und benötigen Zugriff auf vom Konnektor verwaltete Ressourcen, wie z.B. Kartenterminals und SM-Bs. Daher muss bei jedem Aufruf vom Clientsystem ein Aufrufkontext übergeben werden, anhand dessen der Konnektor die Zugriffsberechtigung gegen das vom Administrator konfigurierte Informationsmodell prüfen kann. Falls die Operation einen Login im ePA-Aktensystem mittels SM-B erfordert, wird diese durch den Mandanten, den der Aufrufkontext bestimmt, ebenfalls über das Informationsmodell ermittelt.

Der Aufrufkontext wird üblicherweise im Request als Parameter übertragen (vgl. [PHRManagementService.wsdl]). Um die Verwendung bereits vorhandener IHE-Funktionalität in Primärsystemen zu erleichtern bzw. sogar ohne Anpassungen zu unterstützen, bietet das Fachmodul folgende Möglichkeiten:

• In weniger komplexen Einsatzumgebungen kann bei der Nutzung des Webservices PHRService auf die Übertragung des Aufrufkontexts verzichtet und stattdessen ein Default-Aufrufkontext verwendet werden. Dieser wird vorab auf dem Konnektor eingerichtet und bezieht sich immer genau auf einen Mandanten, ein Clientsystem und einen Arbeitsplatz.
• In Einsatzumgebungen, welche verschiedene Aufrufkontexte benötigen, wird der zu verwendende Aufrufkontext im SOAP-Header übertragen.

Default-Aufrufkontext

Für die IHE-Schnittstelle (PHRService) wird die Komfortfunktion eines Default-Aufrufkontexts angeboten, um die Verwendung bereits vorhandener IHE-Funktionalität in Primärsystemen zu erleichtern bzw. sogar ohne Anpassungen zu unterstützen. Der Webservice PHRManagement hingegen folgt der in den anderen Fachmodulen des Konnektors üblichen Vorgehensweise zur Übertragung des Aufrufkontexts durch die Primärsysteme via Aufrufparameter.

Prüfung der Zugriffsberechtigung auf vom Konnektor verwaltete Ressourcen

Auswahl eines SM-B

Alle Operationen, außer GetHomeCommunityID, benötigen in ihrem Ablauf ein oder auch mehrere SM-Bs für die folgende Funktionalität:

Tabelle 4: Tab_FM_ePA_034 Übersicht der Funktionen, die ein SM-B benötigen, mit Zuordnung zu den aufrufenden Operationen und ob die SM-B eine Berechtigung zum Zugriff haben muss

Die folgenden Anforderungen beziehen sich auf die Auswahl eines SM-B zur Authentisierung, zur Berechtigungsvergabe und zur Durchführung eines C2C mit einer eGK. Die Auswahl eines SM-B zur Autorisierung wird im Kapitel 6.5.4 behandelt.

Ein SM-B wird als freigeschaltet betrachtet, wenn sich das Objekt PIN.SMC im erhöhten Sicherheitszustand befindet.

Prüfung, ob Mandant ePA-fähig ist
Notwendige Voraussetzung für das Funktionieren der Anwendung ePA besteht darin, dass alle SMC-B eines Mandanten die gleiche Telematik-ID enthalten.

6.5 Login

Der Login nach [gemSysL_ePA#3.4.2] in ein ePA-Aktensystem erfolgt bei Bedarf durch das Fachmodul ePA und beinhaltet die Vorbereitungen zur Durchführung von Fachoperationen. Dazu gehören das Abrufen der Authentifizierungs- und Autorisierungsbestätigungen sowie das Initialisieren und Öffnen des Aktenkontextes. Für den aufrufenden Akteur ist die Login-Funktionalität nicht explizit nutzbar, sondern wird implizit innerhalb anderer Operationsaufrufe ausgeführt. Dies bedeutet, dass eventuelle Fehlersituationen beim Login in den Rückgabewerten der jeweiligen Fachoperationen sichtbar werden.

Das Ergebnis eines vollständigen Logins ist

1. das Anlegen einer neuen oder die Nutzung einer vorhandenen Aktensession,
2. die Authentisierung des Nutzers (LEI oder Versicherter/Vertreter) gegenüber dem ePA-Aktensystem,
3. die Autorisierung des Nutzers gegenüber dem ePA-Aktensystem und
4. das Starten und die Initialisierung einer vertrauenswürdigen Ausführungsumgebung (VAU) im ePA-Aktensystem.

Punkt 4 ist insofern optional, als dass die Verbindung zur Dokumentenverwaltung nicht zur Durchführung aller Operationen erforderlich ist.

6.5.1 Aktensession

Eine Aktensession umfasst die zur Kommunikation mit dem ePA-Aktensystem notwendigen Daten eines Operationsaufrufes (Abläufe, Parameter, Rückgabewerte, interne Variablen und Zustände, Referenzen auf Smartcards, Schlüsselmaterialien, Token, etc.). Je nach Komponenten und Art der Authentisierung des Nutzers (via SM-B oder eGK) werden die folgenden Daten benötigt:

Tabelle 5: Tab_FM_ePA_001 Daten zur Kommunikation mit den Komponenten des ePA-Aktensystems (abhängig vom Nutzer)

Sowohl der Aufruf der Operation EjectCard als auch das Ziehen der Karte aus dem Kartenterminal führt zum Entfernen der eGK aus dem Kartenterminal.

6.5.2 Authentisierung mittels SM-B

Die Authentisierung mittels SM-B findet für die folgenden Operationen statt:

• PHRService
• • putDocuments
  • find
  • getDocuments
  • removeDocuments bzw. removeMetadata
  • PHRManagementService
  • GetAuthorizationList
  • GetAuthorizationState

Die Authentisierung LEI mit dem ausgewählten SM-B erfolgt durch das Fachmodul ePA. Hierzu erzeugt das Fachmodul ePA ein SAML-Token, welches dem IHE-Profil "XUA" [IHE-ITI-TF] genügt und als AuthenticationAssertion bezeichnet wird. Das Token wird mit dem für LEI ausgewählten SM-B signiert.

Die Authentisierung LEI im Fachmodul ePA muss nur einmalig erfolgen, auch wenn die LEI auf verschiedene Akten zugreifen möchte. Aus diesem Grunde kann die AuthenticationAssertion außerhalb einer Aktensession gespeichert und wiederverwendet werden.

Ermittlung der Karte für die Authentisierung

Die Ermittlung der SM-B für die Authentisierung wird in Kapitel 6.4 beschrieben.

Erstellung der AuthenticationAssertion

Die SAML2-Assertion gemäß A_14927 wird auch zur Kommunikation mit der Komponente Dokumentenverwaltung verwendet.

6.5.3 Authentisierung mittels eGK

Die Authentisierung mittels eGK findet für die folgenden Operationen statt:

• PHRManagementService
• • ActivateAccount
  • RequestFacilityAuthorization

Für die Anmeldung des Versicherten oder seines berechtigten Vertreters mit seiner eGK wird eine 2-Faktor-Authentisierung (eGK + PIN) verwendet. Das Fachmodul ePA baut anschließend eine TLS-Verbindung zur Komponente Zugangsgateway für Versicherte auf. Durch Nutzung des Interfaces I_Authentication_Insurant::login an der Komponente wird eine Authentifizierungsbestätigung (AuthenticationAssertion) angefordert. Bei dieser Form der Authentisierung wird kryptographisches Material der eGK verwendet. Hierfür ist eine Freischaltung der eGK durch PIN-Eingabe erforderlich.

Freischaltung der eGK

Aufbau der TLS-Verbindung zur Komponente Zugangsgateway für Versicherte

Authentifizierungsbestätigung erstellen

Das Fachmodul erstellt eine Authentifizierungsbestätigung für einen Versicherten auf der Basis des Zertifikats C.CH.AUT der eGK. Das Vorgehen und die Schnittstelle hierzu ist in [gemSpec_Authentisierung_Vers] beschrieben.

Das Interface I_Authentication_Insurant::login ist in [gemSpec_Authentisierung_Vers#6.1 beschrieben].

Weitere Fehlerrückgaben der Operationen AuthInsurantService::LoginCreateChallenge und AuthInsurantService::LoginCreateToken werden in [gemSpec_Authentisierung_Vers] spezifiziert.

6.5.4 Autorisierung

Die Komponente Autorisierung des lokalisierten ePA-Aktensystems prüft, ob der Zugriff auf die mit dem RecordIdentifier referenzierte Akte erlaubt ist. Dazu schickt das Fachmodul ePA die im Rahmen der Authentisierung (s.o.) ausgestellte AuthenticationAssertion an die Komponente Autorisierung und erhält nach erfolgreicher Prüfung ein Chiffrat mit Akten- und Kontextschlüssel sowie eine Autorisierungsbestätigung (AuthorizationAssertion) zur Kommunikation mit der Dokumentenverwaltung ausgehändigt. Das Chiffrat wird mit zwei gemäß [gemSpec_SGD_ePA] abgeleiteten Schlüsseln der SGDs entschlüsselt. Der Ablauf gliedert sich in die folgenden Schritte:

1. TLS-Verbindung zur Komponente Autorisierung aufbauen
2. Aufruf der Operation I_Authorization::getAuthorizationKey der Komponente Autorisierung, Übergabe der AuthenticationAssertion und entsprechender Signatur im SOAP-Header gemäß [WSS-SAML]
3. Verbindungsaufbau zu zwei SGDs und Abruf jeweils eines AES-Schlüssels
4. Entschlüsselung von Akten- und Kontextschlüssel zur Nutzung in der Aktensession

Verbindungsaufbau zur Komponente Autorisierung

Im Konnektor baut das Fachmodul ePA mit Hilfe von TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen" gemäß [gemSpec_Kon#4.1.11.4.1] die TLS-Verbindung ohne Clientauthentisierung und mit Rollenprüfung auf.

Abruf des Chiffrats für den authentisierten Nutzer (LEI oder Versicherter / Vertreter)

Legende:

• Inhalte in eckigen Klammern ([...]) sind ihrer Beschreibung nach zu ersetzen.
• Die Parameter sind der Spezifikation [gemSpec_Autorisierung] entnommen.

Weitere Fehlerrückgaben der Operation I_Authorization::getAuthorizationKey werden in [gemSpec_Autorisierung] spezifiziert.

Schlüsselableitung und Entschlüsselung von Akten- und Kontextschlüssel

Die Schlüsselableitung und Entschlüsselung von Akten- und Kontextschlüssel ist in Kap. 6.5.6- Schlüsselableitung beschrieben.

Benachrichtigung des Primärsystem über bestehende Berechtigungen zum Zugriff auf ein Aktenkonto

Das Element validTo macht eine Aussage über die zeitliche Gültigkeit der übertragenen Schlüssel. Somit kann das Event bei einer Abonnierung durch ein Primärsystem verwendet werden, um Informationen über die zeitliche Gültigkeit der Berechtigung der LEI durch den Versicherten zu erhalten.

6.5.5 Verbindung zur Dokumentenverwaltung

Alle Operationen des Webservices PHRService sowie die Operation RequestFacilityAuthorization benötigen einen initialisierten Aktenkontext in der Dokumentenverwaltung, d.h. eine Verbindung zum Verarbeitungskontext der Vertrauenswürdigen Ausführungsumgebung (VAU) des Versicherten wie in [gemSpec_Dokumentenverwaltung#4.4] beschrieben. Das Fachmodul ePA muss dafür eine TLS-Verbindung zur Komponente Dokumentenverwaltung des Aktensystems, in welchem das Aktenkonto des Versicherten liegt, aufbauen. Die Dokumente des Aktenkontos werden zwischen dem Fachmodul ePA und dem Verarbeitungskontext der VAU in einem sicheren Kanal auf HTTP-Anwendungsschicht gemäß [gemSpec_Krypt#6] übertragen.

Die Schnittstelle der Dokumentenverwaltung wird in [gemSpec_Dokumentenverwaltung#5.4] spezifiziert.

Aufbau der TLS-Verbindung

Im Sinne der Optimierung soll der Konnektor in der Lage sein mehrere VAU-Session über eine TLS-Session zu transportieren.

Aufbau eines sicheren Kanals auf HTTP-Anwendungsschicht zum Verarbeitungskontext der VAU

Wie der Aufbau der sicheren Verbindung zum Verarbeitungskontext der VAU erfolgt, ist in [gemSpec_Krypt#3.15] beschrieben.

Nach dem erfolgreichen Aufruf der Operation OpenContext für ein Aktenkonto, kann das Fachmodul mittels IHE-Transaktionen auf Dokumente im ePA-Aktensystem zugreifen. Im Falle einer Aktivierung des Aktenkontos (Aufruf der Operation ActivateAccount) sind Akten- und Kontextschlüssel noch nicht vorhanden und müssen vor der Initialisierung erzeugt werden (vgl. Operation ActivateAccount im Webservice PHRManagementService).

Weitere Fehlerrückgaben der Operation I_Document_Management_Connect::OpenContext werden in [gemSpec_Autorisierung] spezifiziert.

Dies trifft auch zu, falls kein Schlüsselmaterial vorhanden ist.

6.5.6 Schlüsselableitung

Akten- und Kontextschlüssel werden doppelt symmetrisch verschlüsselt in der Komponente Autorisierung des Aktensystems hinterlegt. Die symmetrischen Schlüssel zur Ver- und Entschlüsselung von Akten- und Kontextschlüssel werden über die Schlüsselableitungsfunktion der SGDs 1 und 2 ermittelt. Die Funktionsweise der Schlüsselgenerierung, die die Basis für die Ver- und Entschlüsselung von Akten- und Kontextschlüssel ist, wird in [gemSpec_SGD_ePA] beschrieben.

Das Element phrs:AuthorizationKey/phrs:EncryptedKeyContainer enthält das Chiffrat mit dem doppelt verschlüsselten Akten- und Kontextschlüssel sowie AssociatedData.
Die Datenstruktur für EncryptedKeyContainer und die Klartextpräsentation für Akten- und Kontextschlüssel ist in [gemSpec_SGD_ePA#8 - Interoperables Austauschformat] beschrieben.

Aufbau der TLS-Verbindung

In den Schritten 12 und 18 des Basisablaufs erfolgt der Aufruf für KeyDerivation abhängig vom Anwendungsfall.

Als Ergebnis bei einer erfolgreichen Schlüsselableitung zum Verschlüsseln erhält das Fachmodul ePA von jedem der beiden SGD eine Antwortnachricht für KeyDerivation im Format: "OK-KeyDerivation "+Key+" "+a.
Key ist der für die Verschlüsselung zu verwendende symmetrische Schlüssel und a entspricht AssociatedData für den entsprechenden SGD.

Festlegungen zur Verschlüsselung von Akten- und Kontextschlüssel

Zur Erteilung einer Berechtigung unter Verwendung der Operation ActivateAccount wird der Anwendungsfall gemSpec_SGD_ePA#2.4 betrachtet.
Zur Erteilung einer Berechtigung unter Verwendung der Operation RequestFacilityAuthorization werden die Anwendungsfälle gemSpec_SGD_ePA#2.6 und gemSpec_SGD_ePA#2.8 betrachtet.

Die konkrete Verwendung der Schlüsselableitung zur Verschlüsselung von Akten- und Kontextschlüssel ist in den Kapiteln zur Umsetzung der Operationen ActivateAccount und RequestFacilityAuthorization beschrieben.

Festlegungen zur Entschlüsselung von Akten- und Kontextschlüssel

I_Authorization::getAuthorizationKey liefert abhängig von der Telematik-ID bzw. KVNR der übertragenen AuthenticationAssertion das Chiffrat für einen berechtigten Nutzer mit Akten- und Kontextschlüssel, die Information durch wen die Berechtigung erfolgte und eine dazu passende AuthorizationAssertion. Das Fachmodul ePA kann im nächsten Schritt das Chiffrat entschlüsseln und Akten- und Kontextschlüssel liegen im Klartext vor und können verwendet werden.

Die Ermittlung der Ableitungsinformation für SGD1 und SGD2 ist in [gemSpec_SGD_ePA#8 ] beschrieben.

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

6.6 Logout

Das Fachmodul ePA stellt einen impliziten Logout für die Aktensession bereit, welcher nach einem Timeout bei Inaktivität bzgl. der Nutzung einer Aktensession ausgeführt wird. Es veranlasst die Löschung der zur Aktensession gehörenden Verbindungsdaten in der VAU und löscht anschließend die Aktensession. Falls noch weitere Verbindungen anderer Aktensessions in die VAU bestehen, bleiben diese aktiv (vgl. I_Document_Management_Connect::CloseContext gemäß [gemSpec_Dokumentenverwaltung]).

Das Fachmodul hat die Option, eine vom Zugangsgateway abgerufene AuthenticationAssertion zu erneuern und muss daher, falls ein Logout erfolgt, als zusätzliche Sicherheitsmaßnahme die Möglichkeit zur Erneuerung der aktuellen AuthenticationAssertion mittels der Operation AuthInsurantService::LogoutToken verhindern.

Da die Löschung der Aktensession nicht innerhalb einer vom Clientsystem aufgerufenen Operation ausgeführt wird, kann ein aufgetretener Fehler auch nicht an das Clientsystem zurückgegeben werden. Der Fehler muss dennoch protokolliert werden.

6.7 Datenschutz und Sicherheitsaspekte

Regelungen aus [gemSpec_Krypt]

Für die Erzeugung von Schlüsselmaterial gilt übergreifend [gemSpec_Krypt#GS-A_4368].

Regelungen für TLS-Verbindungen

Für TLS-Verbindungen gelten die Regelungen aus [gemSpec_Krypt#3.3.2].

6.8 Verwendung des Dienstverzeichnisdienstes

6.9 Protokollierung und Logging

Während die Protokollierung der Zugriffe nach §291a im ePA-Aktensystem erfolgt, legt das Fachmodul ePA Log-Informationen im Konnektor ab, die eine Analyse technischer Vorgänge erlauben. Diese Dateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen weder medizinische noch personenbezogene Daten geloggt werden.

Die Log-Dateien folgen einem einheitlichen Format, das vom Hersteller festgelegt und dokumentiert wird. Es muss geeignet sein, um automatische Auswertungen mit wenig Aufwand durch Dritte zu ermöglichen. Ein Vorbild ist das Weblog des Apache Webservers. Um mehrere Protokolleinträge korrelieren zu können, soll beim Aufruf einer Operation an den Schnittstellen eine Vorgangsnummer gebildet werden. Diese Vorgangsnummer wird in allen Protokolleinträgen dieses Operationsaufrufs genutzt. Die Vorgangsnummer wird vom Konnektor pseudozufällig gebildet.

Der Zugriff auf Log-Dateien muss auf autorisierte Personen durch angemessene technische oder organisatorische Maßnahmen eingeschränkt werden. Zur besseren Auswertung können die Log-Dateien auf ein separates Speichermedium kopiert werden (siehe [gemSpec_Kon#TIP1-A_4716]).

Hinweis: Der Parameter „Schwere“ wird für einen Eintrag im Performanceprotokoll nicht verwendet.

6.10 Konfiguration

Die Einsicht von Protokolldateien und Administration der Konfigurationsparameter erfolgen über die Managementschnittstelle des Konnektors (vgl. [gemSpec_Kon#4.3.4]).

6.11 Fehlerbehandlung und Fehlermeldungen

Fehlerkonzept

Einige Operationen des Fachmoduls müssen möglicherweise mehrere oder sogar alle ePA-Aktensysteme anfragen, um ihre Funktionalität durchführen zu können. GetHomeCommunityID iteriert beispielsweise über alle bekannten ePA-Aktensysteme, bis ein ePA-Aktensystem gefunden wird, dass die Akte zur angefragten KVNR führt. Dabei könnten die ePA-Aktensysteme verschiedene Fehler zurückgeben oder aufgrund eines technischen Problems nicht erreichbar sein. Die einzelnen Operationen reagieren fachlich nicht einheitlich auf diese Situation. Während ein nicht erreichbares ePA-Aktensystem für GetHomeCommunity nicht zwingend ein Problem darstellt, falls etwa ein anderes ePA-Aktensystem die Akte führt, gibt GetAuthorizationList in diesem Falle eine Warnung aus, da möglicherweise nicht alle Berechtigungen der LEI abgerufen werden konnten.

Die Methodik in diesem Dokument sieht in diesem Kapitel eine übergreifende Behandlung der Fehler vor, falls alle Anfragen an das ePA-Aktensystem oder seine Komponenten, die zwingend zur Durchführung einer Operation oder Funktionalität benötigt werden, fehlschlagen. Diese Anforderungen greifen also auch, falls nur die Kommunikation mit einem einzigen ePA-Aktensystem notwendig ist. Alle weiteren Situationen werden jeweils in den Unterkapiteln der Operationen behandelt. Falls unterschiedliche Probleme innerhalb einer Operation auftreten, liefert diese Operation dann ggfs. einen allgemeinen Fehler an das aufrufende System zurück, da eine Differenzierung der Fehlersituationen schnell unübersichtlich und für den Nutzer nicht hilfreich ist. Jeder Fehlercode wird dann aber im Fachmodulprotokoll abgelegt und erlaubt so eine genaue Analyse.

Übergreifende Festlegungen zu Fehlermeldungen

Treten bei der Ausführung einer Operation Fehler auf, die zum Abbruch der Operation führen, so werden diese an das aufrufende System über eine SOAP-Fault-Nachricht gemeldet. Im Erfolgsfalle oder bei Fehlern, die nicht zum Abbruch der Operation führen, wird ein Status-Element gemäß [gemSpec_Kon#3.5.2] zurückgegeben.

Für das Fehlermanagement gelten neben den hier aufgeführten spezifischen Anforderungen die Anforderungen aus Kapitel 3 der übergreifenden Spezifikation [gemSpec_OM#3].

Details zu gematik-SOAP-Faults finden sich in [gemSpec_OM#3.2.3]. Der Code 7400 wird für Fehlerfälle verwendet, die technisch bedingt sind und durch den Nutzer nicht behoben werden können. Diese Fehlerfälle erfordern eine Analyse und Behebung durch den Anbieter.

Hinweis: Die Syntaxprüfung der Operationsaufrufe von PHRService* und PHRManagementService* ist durch die normative Beschreibung mittels WSDL-Dateien bedingt (Kapitel 7.1 PHRService und 7.2 PHRManagementService).

Übergreifende Fehlercodes

Die nachfolgenden Tabellen enthalten

• Fehlermeldungen der übergreifenden Festlegungen des Fachmoduls ePA,
• Fehlermeldungen zu Situationen, die in mehreren Operationen auftreten (und in den entsprechenden Unterkapiteln behandelt  werden),
• Fehlermeldungen, die aus anderen Spezifikationen nachgenutzt werden.

Tabelle 15: Tab_FM_ePA_011 Übergreifende Fehlermeldungen des Fachmoduls ePA

Tabelle 16: Tab_FM_ePA_050 Wiederverwendete Fehlermeldungen aus der Konnektorspezifikation

Tabelle 17: Tab_FM_ePA_051 Wiederverwendete Fehlermeldungen aus der Übergreifenden Spezifikation Operations und Maintenance

7 Funktionsmerkmale

ePA 2.0 führt ein neues Berechtigungskonzept ein. Es wird in die dokumentenkategoriebasierte und dokumentenspezifische Berechtigung unterschieden. In der LEI wird bei der Ad-hoc-Berechtigung die kategoriebasierte Berechtigung unterstützt. Um die Interoperabilität mit bisherigen Primärsystemen sicherzustellen, werden in der Migrationsphase sowohl die in früheren Versionen bereits unterstützte Ad-hoc-Berechtigung auf Basis der drei Kategorien Versicherter, Arzt und Kasse als auch die neue dokumentenkategoriebasierte Berechtigung unterstützt. Die Webservices PHRService und PHRManagementService unterstützen unterschiedliche Versionen für ePA 2. 

Das Fachmodul ePA wird in zwei Funktionsmerkmale unterteilt, die je über eine Schnittstelle realisiert werden:

Tabelle 18: Tab_FM_ePA_004 Schnittstellenübersicht des Fachmoduls ePA

Die Operationen von PHRService erlauben das Einstellen, Suchen, Herunterladen und Löschen von Dokumenten sowie die Aktualisierung von Metadaten. Die zum Aufruf benötigte HomeCommunity als Teil des RecordIdentifiers können Primärsysteme über die Operation GetHomeCommunityID des Webservices PHRManagementService beziehen. Dieser Webservice erlaubt es außerdem einem Versicherten, in der LE-Umgebung sein Aktenkonto zu aktivieren und eine Leistungserbringerinstitution ad-hoc zu berechtigen (Operation RequestFacilityAuthorization). Eine LEI kann ihre Berechtigungen für Aktenkonten abrufen und aktualisieren.

Die Webservices werden vom Fachmodul ePA im Dienstverzeichnis des Konnektors registriert und damit für Primärsysteme auffindbar gemacht (siehe Kapitel 6.8 Verwendung des Dienstverzeichnisdienstes).

7.1 PHRService

In ePA 2 werden mehrere Versionen des WebService PHRService unterstützt.

Der Webservice PHRService V2.x unterstützt die Operationen putDocuments, find, getDocuments, removeMetadata für ePA 2. 

Der Webservice PHRService setzt die logische Schnittstelle I_PHR_Management gemäß [gemSysL_ePA] um.

PHRService Version 2.0.2 wird eingeführt mit der Prüfung, ob der im Operationsaufruf (IHE) übergebene Mandant "ePA-fähig" ist. Andernfalls wird die Operation abgebrochen und ein Fehler an das Primärsystem zurückgegeben, der auf den Konfigurationsfehler hinweist.

Auch wenn das Schema PHR_Common.xsd das Element HomeCommunityId als optional kennzeichnet ist es für alle Operationen von PHRService verpflichtend.

Der SOAP-Header ermöglicht es dem Webservice, die Zugriffsberechtigungsprüfung durchzuführen (Kapitel 6.4 Aufrufkontext) und einen SM-B für den Zugriff auf die Akte des Versicherten auszuwählen (Kapitel 6.5 Login).

7.1.1 Definition/Signatur

Dieses Unterkapitel beschreibt die in [PHRService*.wsdl] definierten Methoden, d.h. Aufruf- und Rückgabeparameter sowie alle möglichen Fehlermeldungen.

7.1.1.1 putDocuments

Tabelle 22: Tab_FM_ePA_006 Beschreibung und Parameter der Operation putDocuments

Fehlermeldungen

Die Operation putDocuments kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7208, 7209, 7211, 7212, 7214, 7215, 7220, 7221, 7233, 7400, 7401, 7403, 7404 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-41] definierte Fehlermeldungen

7.1.1.2 find

Die Operation find ermöglicht einem Primärsystem das Suchen von Inhalten (Dokumenten und SubmissionSets) im ePA-Aktensystem.

Tabelle 23: Tab_FM_ePA_013 Beschreibung und Parameter der Operation find (Semantik)

Fehlermeldungen

Die Operation find kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7208, 7209, 7214, 7215, 7220, 7221, 7233, 7400, 7401, 7403, 7404 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-18] und [ITI-38] definierte Fehlermeldungen

7.1.1.3 getDocuments

Die Operation getDocuments ermöglicht Primärsystemen das Herunterladen von Dokumenten aus dem ePA-Aktensystem.

Tabelle 24: Tab_FM_ePA_027 Beschreibung und Parameter der Operation getDocuments (Semantik)

Fehlermeldungen

Die Operation getDocuments kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7208, 7209, 7211, 7212, 7214, 7215, 7220, 7221, 7233, 7400, 7401, 7403, 7404 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-43] und [ITI-80] definierte Fehlermeldungen

7.1.1.4 removeDocuments (abgekündigt)

Die Operation removeDocuments ermöglicht Primärsystemen das Löschen von Dokumenten aus dem ePA-Aktensystem.

Tabelle 25: Tab_FM_ePA_029 Beschreibung und Parameter der Operation removeDocuments (Semantik)

Die Unterstützung von [ITI-62] "Remove Metadata" ist nicht notwendig. Die Dokumentenverwaltung stellt sicher, dass sowohl Dokument als auch Metadaten gelöscht werden.

Fehlermeldungen

Die Operation removeDocuments kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7209, 7214, 7215, 7220, 7221, 7400, 7401, 7403, 7404 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-86] definierte Fehlermeldungen

7.1.1.5 removeMetadata

Die Operation removeMetadata ermöglicht Primärsystemen das Löschen von Dokumenten (auch in Ordnern) aus dem ePA-Aktensystem.

Tabelle 26: Tab_FM_ePA_029 Beschreibung und Parameter der Operation removeMetadata (Semantik)

Fehlermeldungen

Die Operation removeMetadata kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7208, 7209, 7214, 7215, 7220, 7221, 7233, 7400, 7401, 7403, 7404 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-62] definierte Fehlermeldungen

7.1.1.6 updateDocumentSet (abgekündigt)

Die Operation updateDocumentSet wird mit einem Fehler abgebrochen.

Tabelle 27: Tab_FM_ePA_031 Beschreibung und Parameter der Operation updateDocumentSet (Semantik)

Fehlermeldungen

Die Operation updateDocumentSet kann folgende Fehlermeldungen zurückliefern:

• 7400, 7401

7.1.2 Umsetzung

Die Operationen des Webservices PHRService sind IHE-basierte Anfragen. Die Verarbeitung durch das Fachmodul ePA läuft im Wesentlichen für alle Operation gleich ab:

1. Operationsaufruf vom Primärsystem entgegennehmen und Parameter prüfen
2. Login wie in Kapitel 6.5 beschrieben (optional, falls noch nicht geschehen)
3. Fachliche Transformation der Parameter (Verschlüsselung der Dokumente, Aktualisierung bestimmter Metadaten, etc.)
4. SOAP Security Header setzen
5. Weiterleitung der IHE-Transaktion an das ePA-Aktensystem
6. Antwort oder Fehlermeldung des ePA-Aktensystems entgegennehmen
7. Antwort oder Fehlermeldung erstellen und an das aufrufende Primärsystem zurückgeben

Übergreifende Anforderungen bei der Umsetzung des Webservices PHRService

Die Authentisierung mittels SM-B und der weitere Login-Prozess sind in Kapitel 6.5 Login beschrieben. Der Aufrufkontext wird mithilfe der SOAP-Header bestimmt.

Der Begriff „Dokument“ bezeichnet im Folgenden das Originaldokument, welches in unverschlüsselter Form vom Primärsystem in einer IHE-Nachricht zur Ablage im Aktensystem übertragen wird.

7.1.2.1 putDocuments

Die Weiterleitung der Anfragen an die Komponente Dokumentenverwaltung und der Antworten der Dokumentenverwaltung zurück an das Primärsystem erreicht das Fachmodul ePA durch die Gruppierung von IHE-Akteuren. Dazu nimmt das Fachmodul ePA die Anfrage als XDR „Document Recipient" vom Primärsystem entgegen und leitet sie anschließend an die Komponente Dokumentenverwaltung via [ITI-80] "Cross-Gateway Document Provide" in der Rolle eines XCDR Initiating Gateway an das ePA-Aktensystem weiter (vgl. hierzu[gemSpec_DM_ePA#Abbildung 2]).  Das ePA-Aktensystem setzt dementsprechend ein XCDR Responding Gateway um. Die Antworten nehmen den umgekehrten Weg.

Die Gruppierung von XCDR- und XDR-Akteur wird durch das XCDR-Profil erzwungen.

Die Antwort der Dokumentenverwaltung auf eine Fachmodulanfrage gemäß [ITI-80] „Cross-Gateway Document Provide" enthält keinerlei Metadatenfelder, die vor der Weiterleitung an das anfragende Primärsystem einer Transformation bedürfen.

Dokumentenverschlüsselung

7.1.2.2 find

Das Fachmodul ePA muss eine find-Anfrage, sofern sie den Anforderungen aus Kapitel 7.1.1.2 genügt, anschließend an das ePA-Aktensystem weiterleiten. Das Fachmodul ePA agiert dabei als XCA "Initiating Gateway", während das ePA-Aktensystem ein XCA-„Responding Gateway“ umsetzt (siehe Operation I_Document_Management::CrossGatewayQuery gemäß [gemSpec_Dokumentenverwaltung]). Die Antworten nehmen den umgekehrten Weg.

7.1.2.3 getDocuments

Das Fachmodul ePA muss eine eingehende Primärsystemanfrage, sofern sie den Anforderungen aus Kapitel 7.1.1.3 genügt, anschließend an das ePA-Aktensystem weiterleiten. Das Fachmodul ePA agiert dabei als XCA "Initiating Gateway", während das ePA-Aktensystem ein XCA-„Responding Gateway“ umsetzt (siehe Operation I_Document_Management::CrossGatewayRetrieve in [gemSpec_Dokumentenverwaltung]).

Dokumentenentschlüsselung

7.1.2.4 removeDocuments (abgekündigt)

Die Weiterleitung der removeDocument-Anfragen an die Komponente Dokumentenverwaltung und der Antworten der Dokumentenverwaltung zurück an das Primärsystem erreicht das Fachmodul ePA durch die Kombination zweier IHE-Akteure. Dazu nimmt das Fachmodul ePA die Anfrage als IHE-Akteur RMD "Document Repository" vom Primärsystem entgegen und leitet sie anschließend in der Rolle eines RMD "Document Administrator" an das ePA-Aktensystem weiter. Das ePA-Aktensystem setzt dementsprechend ein RMD Document Repository über die Schnittstelle removeDocuments um. Die Antworten nehmen den umgekehrten Weg.

Diese Kombination beider Akteure ist deshalb notwendig, da IHE bislang keine explizite "Cross-Community"-Variante für das RMD-Profil spezifiziert hat.

Es müssen keine Metadaten in Anfragen oder Antworten der Operation removeDocuments transformiert werden.

7.1.2.5 removeMetadata

Die Weiterleitung der removeMetadata-Anfragen an die Komponente Dokumentenverwaltung und der Antworten der Dokumentenverwaltung zurück an das Primärsystem erreicht das Fachmodul ePA durch die Kombination zweier IHE-Akteure. Dazu nimmt das Fachmodul ePA die Anfrage als IHE-Akteur RMD "Document Registry" vom Primärsystem entgegen und leitet sie anschließend in der Rolle eines RMD "Document Administrator" an das ePA-Aktensystem weiter. Das ePA-Aktensystem setzt dementsprechend ein RMD Document Registry über die Schnittstelle removeMetadata um. Die Antworten nehmen den umgekehrten Weg.

Diese Kombination beider Akteure ist deshalb notwendig, da IHE bislang keine explizite "Cross-Community"-Variante für das RMD-Profil spezifiziert hat.

Es müssen keine Metadaten in Anfragen oder Antworten der Operation removeDocuments transformiert werden.

7.2 PHRManagementService

In ePA 2 werden mehrere Versionen des WebService PHRManagementService unterstützt.
Der Webservice PHRManagementService V2.x unterstützt mit der Operation RequestFacilityAuthorization Version 2.x die kategoriebasierte Berechtigung.

Der Webservice PHRManagementService V2.5 unterstützt mit der Operation RequestFacilityAuthorization Version 2.5 die kategoriebasierte Berechtigung mit der Erweiterung für Digitale Gesundheitsanwendungen (DiGA).

Wenn sich die Anforderungen für die Versionen der Operation RequestFacilityAuthorization unterscheiden, so wird die neue Anforderung den Bezug zu V2.5 herstellen. Die parallel hierzu bereits existierende Anforderung gilt für RequestFacilityAuthorization 2.x. Alle sonstigen Anforderungen gelten für V2.x und V2.5.

Der Webservice PHRManagementService setzt die logischen Schnittstellen I_Account_Administration und I_Authorization_Administration gemäß [gemSysL_ePA] um.

Wenn der im Operationsaufruf (IHE) übergebene Mandant nicht "ePA-fähig" ist, wird die Operation abgebrochen und ein Fehler an das Primärsystem zurückgegeben, der auf den Konfigurationsfehler hinweist.

PHRManagementService Version 2.5.3 wird eingeführt mit der Prüfung für die Operationen RequestFacilityAuthorization, GetAuthorizationList, GetAuthorizationState:
Wenn der im Operationsaufruf übergebene Mandant nicht "ePA-fähig" ist, dann existiert potentiell das Risiko, dass wegen der Fehlkonfiguration eine Berechtigung für eine falsche Institution erteilt wird bzw. Berechtigungen für die falsch konfigurierte Telematik-ID ermittelt werden. In diesem Fall wird die Operation abgebrochen und ein Fehler an das Primärsystem zurückgegeben.

7.2.1 Definition/Signatur

Dieses Unterkapitel beschreibt die in [PHRManagementService*.wsdl] definierten Methoden, d.h. Aufruf- und Rückgabeparameter sowie alle möglichen Fehlermeldungen.

7.2.1.1 ActivateAccount

Tabelle 32: Tab_FM_ePA_016 Beschreibung und Parameter der Operation ActivateAccount (Semantik)

Die Operation ActivateAccount kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7203, 7207, 7213, 7215, 7220, 7400, 7401, 7402, 7404 gemäß Tab_FM_ePA_011
• Fehlermeldungen gemäß Tab_FM_ePA_050
• Fehlermeldungen gemäß Tab_FM_ePA_051

7.2.1.2 RequestFacilityAuthorization

Tabelle 33: Tab_FM_ePA_020 Beschreibung und Parameter der Operation RequestFacilityAuthorization (Semantik)

Die Operation RequestFacilityAuthorization kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7203, 7207, 7208, 7209, 7213, 7214, 7215, 7217, 7220, 7232, 7233, 7400, 7401, 7404 gemäß Tab_FM_ePA_011
• Fehlermeldungen gemäß Tab_FM_ePA_050
• Fehlermeldungen gemäß Tab_FM_ePA_051

7.2.1.3 GetHomeCommunityID

Tabelle 34: Tab_FM_ePA_039 Beschreibung und Parameter der Operation GetHomeCommunityID (Semantik)

Die Operation GetHomeCommunityID kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7220, 7400 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• Fehlermeldungen gemäß Tab_FM_ePA_032

Tabelle 35: Tab_FM_ePA_032 Fehlermeldungen der Operation GetHomeCommunityID

7.2.1.4 GetAuthorizationList

Tabelle 36: Tab_FM_ePA_040 Beschreibung und Parameter der Operation GetAuthorizationList (Semantik)

Die Operation GetAuthorizationList kann folgende Fehlermeldungen zurückliefern:

• 4000, 4010, 4011, 4012, 4014, 4021, 4204 gemäß Tab_FM_ePA_050
• 7200, 7202, 7205, 7208, 7220, 7221, 7233, 7400  gemäß Tab_FM_ePA_011
• Fehlermeldungen gemäß Tab_FM_ePA_041

Tabelle 37: Tab_FM_ePA_041 Fehlermeldungen der Operation GetAuthorizationList

7.2.1.5 GetAuthorizationState

Tabelle 38: Tab_FM_ePA_056 Beschreibung und Parameter der Operation GetAuthorizationState (Semantik)

Die Operation GetAuthorizationState kann folgende Fehlermeldungen zurückliefern:

• 4000, 4010, 4011, 4012, 4014, 4021, 4204 gemäß Tab_FM_ePA_050
• 7200, 7202, 7205, 7208, 7220, 7221, 7233, 7400, 7401, 7403, 7404  gemäß Tab_FM_ePA_011
• Fehlermeldungen gemäß Tab_FM_ePA_057

Tabelle 39: Tab_FM_ePA_057 Fehlermeldungen der Operation GetAuthorizationState

7.2.2 Umsetzung

Authentisierung gegenüber dem Aktensystem

Die Authentisierung mittels SM-B bzw. eGK und der weitere Login-Prozess sind in Kapitel 6.5 Login beschrieben. Der Aufrufkontext wird in den Parametern der Operationen übergeben.

Der Aufruf der Operation GetHomeCommunityID erfordert keine Authentisierung gegenüber dem ePA-Aktensystem.

Übergreifende Regelungen für PHRManagementService

Fehlerrückgaben der Operation I_Authorization_Management::putAuthorizationKey werden in [gemSpec_Autorisierung] spezifiziert.

7.2.2.1 ActivateAccount

Der Ablauf der Operation ActivateAccount ist in [gemSysL_ePA#3.5.1] beschrieben und gliedert sich in die folgenden Schritte:

1. Prüfung der Parameter und des Sperrstatus der eGK
2. Login des Versicherten mit der eGK
3. Schlüsselmaterial erzeugen und verschlüsseln
4. Hinterlegen des verschlüsselten Schlüsselmaterials für den Versicherten in der Komponente Autorisierung

Authentisierung des Versicherten gegenüber dem Aktensystem

Die Authentisierung gegenüber einem Aktensystem erfolgt gemäß A_15192 mit der eGK. Der vollständige Login-Prozess ist in Kapitel 6.5 Login beschrieben.

Erzeugung des Schlüsselmaterials für den Zugriff durch die eGK

Übergreifende Festlegungen zur Datensicherheit befinden sich in Kapitel 6.7 Datenschutz und Sicherheitsaspekte. Für die Verschlüsselung von Akten- und Kontextschlüssel gelten die Vorgaben aus [gemSpec_SGD_ePA#8].

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

Schlüsselableitung und Verschlüsselung von Akten- und Kontextschlüssel

Das Chiffrat von Akten- und Kontextschlüssel im Schlüsselkasten wird bei der Aktivierung des Aktenkontos in der Komponente Autorisierung hinterlegt. Hierzu werden Akten- und Kontextschlüssel mit zwei AES-256-Schlüsseln verschlüsselt. Die für die Verschlüsselung des Chiffrats benötigten zwei AES-256-Schlüssel ruft das Fachmodul ePA von den SGDs 1 und 2 ab (siehe Kap. 6.5.6- Schlüsselableitung).

Hinterlegen des Schlüsselmaterials für den Versicherten in der Komponente Autorisierung

Zur Hinterlegung des Schlüsselmaterials wird eine TLS-Verbindung zur Komponente Autorisierung aufgebaut. Die normativen Festlegungen hierzu befinden sich in Kapitel 6.5.4.

7.2.2.2 RequestFacilityAuthorization

In ePA 2 werden mehrere Versionen der Operation RequestFacilityAuthorization unterstützt. Der Webservice PHRManagementService V2.x unterstützt mit der Operation RequestFacilityAuthorization die kategoriebasierte Berechtigung gemäß gemSpec_Dokumentenverwaltung#5.4.

PHRManagementService V2.5 unterstützt mit der Operation RequestFacilityAuthorization V2.5 die kategoriebasierte Berechtigung mit der Erweiterung für DiGA.

Wenn sich die Anforderungen für die beiden Versionen der Operation RequestFacilityAuthorization unterscheiden, so wird die neue Anforderung den Bezug zu V2.5 herstellen.

Auswahl eines SM-B

Das Fachmodul ePA sucht ein SM-B aus dem fest konfigurierten Informationsmodell des Konnektors, das dem übertragenen Context zugeordnet ist und zuvor durch PIN-Eingabe freigeschaltet wurde (siehe A_15614-*). Die Berechtigungsvergabe zum Zugriff auf ein Aktenkonto erfolgt für eine LEI, identifiziert durch die Telematik-ID.

Bestätigung der Berechtigung per PIN-Eingabe

Die folgenden Beispiele sollen veranschaulichen, wie die Anzeige am Kartenterminal und die Eingabe des Versicherten bei der Operation RequestFacilityAuthorization Version 2 erfolgt.

Tabelle 46 : Tab_FM_ePA_043 - Beispiel Anzeige am Kartenterminal der Operation RequestFacilityAuthorization Version 2 ohne Dokumentkategorien

Im Beispiel erteilt Max Mustermann der Praxis Dr. Müller bis 01.08.2021 die Berechtigung, auf normale und vertrauliche deklarierten Dokumente der Akte des Versicherten Max Mustermann zuzugreifen. Im Dialog am Kartenterminal entscheidet sich Max Mustermann dafür, die 5 Dokumentenkategorien, die nach Rücksprache in der Praxis vereinbart wurden, nicht am Kartenterminal anzeigen zu lassen.
Die Optimierung gemäß A_16219-* wurde im Beispiel nicht berücksichtigt.

Tabelle 47 : Tab_FM_ePA_044 - Beispiel Anzeige am Kartenterminal der Operation RequestFacilityAuthorization Version 2 mit Dokumentenkategorien

Im Beispiel erteilt Max Mustermann der Praxis Dr. Müller (Allgemeinmedizin) bis 01.08.2021 die Berechtigung, auf normale deklarierte Dokumente der Akte des Versicherten Max Mustermann zuzugreifen. Im Dialog am Kartenterminal entscheidet sich Max Mustermann dafür, die 5 Dokumentenkategorien, die nach Rücksprache in der Praxis vereinbart wurden, am Kartenterminal anzeigen zu lassen. Auf Wunsch des Versicherten wurden die Dokumentenkategorien eingeschränkt. Am Kartenterminal werden nur die Dokumentenkategorien angezeigt, die in AuthorizationConfiguration.DocumentCategoryList vom Primärsystem übergeben wurden.
Die Optimierung gemäß A_16219-* wurde im Beispiel nicht berücksichtigt.

Im einfachsten Fall ist das vom Primärsystem übergebene Zeichen am Kartenterminal anzeigbar, z.B. das Zeichen 'a'. Für nicht abbildbare Zeichen gibt es verschiedene Möglichkeiten. Das Zeichen kann beispielsweise weggelassen werden oder durch ein festes Zeichen als Platzhalter ersetzt werden oder es gibt eine geeignete Abbildung auf ein lesbares Zeichen. Eine geeignete Abbildung für Buchstaben mit diakritischen Zeichen (z.B. 'ñ') ist die Darstellung des Buchstabens ohne das diakritische Zeichen ('n') auf dem Display des Kartenterminals.

Über TUC_KON_058 „Displaygröße ermitteln“ gemäß [gemSpec_Kon] kann das Fachmodul ePA die Größe des durch das Kartenterminal verwendeten Displays abfragen und die Darstellung der Berechtigungen optimieren.

Tab_FM_ePA_045 zeigt ein Beispiel der Optimierung für den Fall, dass das Kartenterminal im sichtbaren Bereich 40 Zeichen und 5 Zeilen unterstützt:

• Die Anzeige für wen die Berechtigung erfolgt kann dabei auf eine Seite optimiert werden.
• Die Anzeige der Dokumentenkategorien kann dabei auf zwei Seiten optimiert werden.

Tabelle 48 : Tab_FM_ePA_045 - Beispiel  Optimierung der Anzeige am Kartenterminal der Operation RequestFacilityAuthorization Version 2 mit Dokumentenkategorien

Login am ePA-Aktensystem (Authentisierung und Autorisierung)

Die Authentisierung gegenüber einem Aktensystem erfolgt gemäß A_15192 mit der eGK. Der vollständige Login-Prozess ist in Kapitel 6.5 Login beschrieben. Dabei ist es unerheblich, ob es sich um den Versicherten als Eigentümer der Akte handelt oder ob der Versicherte in der Rolle des Vertreters agiert. In beiden Fällen wird für den Versicherten die Authentisierung und Autorisierung mit seiner eGK durchgeführt.

Verbindung zur Dokumentenverwaltung

Die Operation RequestFacilityAuthorization kommuniziert mit der Komponente Dokumentenverwaltung und baut hierzu eine sichere Verbindung gemäß den Festlegungen in Kapitel 6.5.5 auf.

Kontoaktivierung falls erforderlich

Bevor die Berechtigung für die Telematik-ID in der Komponente Autorisierung hinterlegt wird, wird für den Fall, dass das Aktenkonto noch nicht aktiviert wurde, die Operation ActivateAccount implizit aufgerufen und vollständig abgearbeitet.

Bei der Kontoaktivierung wird die Zustimmung des Versicherten durch PIN-Eingabe verlangt. Es werden Events definiert und zu Beginn und Ende der impliziten Kontoaktivierung erzeugt. Das Primärsystem erhält dadurch die Möglichkeit, den Versicherten auf die zusätzliche Kontoaktivierung hinzuweisen.

Berechtigung in Komponente Autorisierung für Telematik-ID erstellen

Durch den Login (Authentisierung und Autorisierung) liegt in der Session zur Operation RequestFacilityAuthorization der Aktenschlüssel und der Kontextschlüssel im Klartext vor. Beide Schlüssel werden mit AES-Schlüsseln, die von SGD 1 und 2 abgerufen werden, verschlüsselt und mittels I_Authorization_Management::putAuthorizationKey in die Komponente Autorisierung eingebracht.

Der RecordIdentifier wird aus den Aufrufparametern von RequestFacilityAuthorization übernommen, die AuthenticationAssertion wurde beim Login über die Komponente Zugangsgateway für Versicherte erzeugt.

Berechtigung der LEI in die Dokumentenverwaltung einbringen

Das Fachmodul erstellt im Kontext der Operation RequestFacilityAuthorization ein Policy Document, sendet dieses an die Komponente Dokumentenverwaltung wodurch die Berechtigung für die LEI in der Dokumentenverwaltung hinterlegt wird.

Die Nutzungsvorgaben für XDS-Metadaten bei Policy Documents sind in [gemSpec_DM_ePA#2.1.4.2] beschrieben.

Die Nutzungsvorgaben zum Inhalt eines Policy Documents zur Berechtigung einer Leistungserbringerinstitution werden durch die Anforderung A_15442-* in [gemSpec_Dokumentenverwaltung] geregelt.

Bei erfolgreicher Durchführung der Operation RequestFacilityAuthorization wurde die Berechtigung für die LEI im Aktensystem hinterlegt. Ein Akteur der LEI kann jetzt durch Operationen von PHRService auf Dokumente des Versicherten im Aktensystem zugreifen das Login mit SM-B erfolgen.

7.2.2.3 GetHomeCommunityID

Der Namensdienst der TI enthält für jedes ePA-Aktensystem die IP-Adressen der einzelnen Komponenten und die HomeCommunityID als fachlichen Identifier. GetHomeCommunityID iteriert über alle Einträge und liefert dann die HomeCommunityID des ePA-Aktensystems zurück, welches die Akte zu der übergebenen Versicherten-ID führt. Als Fehler der Operation werden die Fälle abgefangen, dass kein oder mehr als ein passendes ePA-Aktensystem gefunden wird. Liefert der Aufruf von I_Authorization_Management::checkRecordExists den Statuswert UNKNOWN zurück, geht die Operation GetHomeCommunityID davon aus, dass das ePA-Aktensystem keine Patientenakte zu der übertragenen Versicherten-ID führt. Der Fehlerfall, dass die Lokalisierungsinformationen zum Zeitpunkt des Aufrufs von GetHomeCommunityID nicht zur Verfügung stehen, wird in Kapitel 6.3 behandelt.

Aufbau einer TLS-Verbindung zur Komponente Autorisierung eines ePA-Aktensystems

Gemäß A_14105 muss zur Kommunikation mit der Komponente Autorisierung eines ePA-Aktensystems eine TLS-Verbindung mit serverseitiger Authentisierung aufgebaut werden.

Abfrage der ePA-Aktensysteme

Da ein Versicherter höchstens ein Aktenkonto bei genau einem ePA-Aktensystem hat, kann Fachmodul ePA die Operation GetHomeCommunityID erfolgreich beenden, sobald das entsprechende ePA-Aktensystem gefunden wurde.

Falls mindestens ein ePA-Aktensystem erreichbar ist und einen Statuswert zurückliefert, wird bei fehlgeschlagenen Aufrufen anderer ePA-Aktensysteme angenommen, dass diese kein passendes Aktenkonto zur der Versicherten-ID führen.

Fehlerbehandlung

7.2.2.4 GetAuthorizationList

Auswahl eines SM-B

Das Fachmodul ePA sucht ein SM-B aus dem fest konfigurierten Informationsmodell des Konnektors, das dem übertragenen Context zugeordnet ist und zuvor durch PIN-Eingabe freigeschaltet wurde. Die Berechtigungen werden für die Telematik-ID des ausgewählten SM-B ermittelt.

Aufbau einer TLS-Verbindung zur Komponente Autorisierung eines ePA-Aktensystems

Gemäß A_14105 muss zur Kommunikation mit der Komponente Autorisierung eines ePA-Aktensystems eine TLS-Verbindung mit serverseitiger Authentisierung aufgebaut werden.

Abfrage der ePA-Aktensysteme

Login an den ePA-Aktensystemen (nur Authentisierung)

Der Abruf der Berechtigungen erfordert die Authentisierung gegenüber den ePA-Aktensystemen (A_15193). Der Ablauf verläuft jeweils analog zum Login bei Aufruf einer Operation des Webservices PHRService. Eine Autorisierung und Verbindung zur Komponente Dokumentenverwaltung ist nicht notwendig.

Abfrage der Berechtigungen an den ePA-Aktensystemen

Zur Ermittlung der Berechtigungen wird an allen im Namensdienst der TI gelisteten ePA-Aktensystemen die Operation I_Authorization_Management::getAuthorizationList der jeweiligen Komponente Autorisierung aufgerufen. Die Operation I_Authorization_Management::getAuthorizationList liefert eine Liste von KVNRs, für die im Schlüsselkasten ein AuthorizationKey hinterlegt ist, der die zur übergebenen AuthenticationAssertion gehörende LEI zum Zugriff berechtigt sowie das Enddatum der Zugriffsberechtigung. Die KVNRs werden in vollständige RecordIdentifier transformiert und als Liste, zusammen mit dem jeweiligen Enddatum der Berechtigung, an das aufrufende Clientsystem übergeben. Ein Fehler der Operation I_Authorization_Management::getAuthorizationList führt nicht zum Abbruch der Operation GetAuthorizationList, sondern lediglich zu einer Warnung. Falls alle Aufrufe von I_Authorization_Management::getAuthorizationList zu einem Fehler führen, wird die Operation GetAuthorizationList mit einem Fehler abgebrochen.

Fehlerbehandlung

Die Operation GetAuthorizationList muss alle bekannten ePA-Aktensysteme anfragen, die jeweils mit verschiedenen Fehlern antworten können. Das Fachmodul zeigt mit dem Fehlercode 7215 eindeutig ein Problem auf Seite der Aktensysteme an, Fehlercode 7400 hingegeben deutet auf ein Problem im Konnektor hin, bedarf aber einer genaueren Analyse der Log-Dateien.

Sind für eine LEI keine Berechtigungen vorhanden, gibt die Operation GetAuthorizationList eine leere Liste in dem Rückgabeparameter AuthorizationList zurück.

Die Persistierung der Information über einen bereits erfolgten Aufruf von GetAuthorizationList gemäß A_22462 ist nicht über einen Neustart des Konnektors hinaus erforderlich.

Transformation KVNR nach RecordIdentifier

7.2.2.5 GetAuthorizationState

Auswahl eines SM-B

Das Fachmodul ePA sucht ein SM-B aus dem fest konfigurierten Informationsmodell des Konnektors, das dem übertragenen Context zugeordnet ist und zuvor durch PIN-Eingabe freigeschaltet wurde. Die Berechtigung wird für die Telematik-ID des ausgewählten SM-B ermittelt.

Aufbau einer TLS-Verbindung zur Komponente Autorisierung eines ePA-Aktensystems

Gemäß A_14105 muss zur Kommunikation mit der Komponente Autorisierung eines ePA-Aktensystems eine TLS-Verbindung mit serverseitiger Authentisierung aufgebaut werden.

Login am ePA-Aktensystemen (nur Authentisierung)

Der Abruf der Berechtigungen erfordert die Authentisierung gegenüber dem ePA-Aktensystem (A_15193). Der Ablauf verläuft analog zum Login bei Aufruf einer Operation des Webservices PHRService. Eine Autorisierung und Verbindung zur Komponente Dokumentenverwaltung ist nicht notwendig.

Abfrage der Dauer der Berechtigung am ePA-Aktensystem

Zur Ermittlung der Berechtigungen wird am durch RecordIdentifier (HCID) adressierten ePA-Aktensystem die Operation I_Authorization_Management::GetAuthorizationState der Komponente Autorisierung aufgerufen. Falls Berechtigungen für die LEI vorliegen, liefert die Operation I_Authorization_Management::GetAuthorizationState die Liste der berechtigten Anwendungen. Der Konnektor übergibt die Liste der berechtigten Anwendungen an das aufrufende Clientsystem. Liegt keine Berechtigung vor entfällt die Liste in der Response.

Die Bildungsvorschrift für UserAgent wird in A_22470 definiert.

Fehlerbehandlung

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

Weitere Begriffserklärungen befinden sich in [gemGlossar].

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. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

8.5.2 Weitere Dokumente