gemSpec_FM_ePA_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Fachmodul ePA

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
18.12.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_ePA
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das Fachmodul ePA ist Teil der Fachanwendung ePA, die im Systemkonzept [gemSysL_Fachanwendung_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.

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. Das außerdem zur Fachanwendung gehörende „ePA-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
• Restricted Metadata Update (RMU) 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 (sowie Patient Identity Source) 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_Fachanwendung_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“) empfängt und verarbeitet dazu die entsprechenden Nachrichten des Primärsystems und leitet diese (als IHE-Akteur Document Administrator) an das ePA-Aktensystem weiter.

Restricted Metadata Update (RMU) Profile

ePA unterstützt keine Versionierung von Dokumenten. Müssen ein Dokument oder seine Metadaten geändert werden, muss es gelöscht (RMD-Profil) und neu eingestellt werden (XCDR-Profil). Die einzige Ausnahme dieser Regel wird genutzt, um den Status eines Dokuments von einem reinen „Versichertendokument" auf ein „leistungserbringeräquivalentes Dokument" zu ändern, ohne das Dokument neu einstellen zu müssen.

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]

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 XCA-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 einem ePA-Aktensystem

Übergreifende Festlegungen für beteiligte Smartcards

Ü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 LDAP-Proxy im Konnektor sind in [gemSpec_Kon#4.1.12] 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 5.2 stellt alle IHE-Akteure der Fachanwendung ePA.

Die nicht unterstützten Optionen sind damit nach aktuellem Stand von [IHE-ITI-TF], [IHE-ITI-XCDR], [IHE-ITI-APPC], [IHE-ITI-XDS] und [IHE-ITI-RMU]: Document Replacement, Document Addendum, Document Transformation, Folder Management, Basic Patient Privacy Enforcement, Basic Patient Privacy Proof, Persistence of Retrieved Documents, Asynchronous Webservice, Remote Repository, Subject-Role, Authz-Consent, PurposeOfUse, View, Secured NTP, Radiology Audit Trail, XCA Persistence, XDS Persistence, XDS Version Persistence.

Auch die Profile CT und ATNA (beide [IHE-ITI-TF]), die von IHE eigentlich bei der Verwendung von XDS-basierten Akteuren vorgesehen sind, dürfen explizit nicht unterstützt werden. Die entsprechenden Funktionalitäten werden anderweitig umgesetzt.

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 als SAML-Token im SOAP-Header unter Nutzung des IHE-Profils "XUA" als SAML-Token übertragen.

Tritt bei der Ermittlung des Aufrufkontexts ein Fehler auf wird die aufgerufene Operation mit dem Fehler 4000 beendet (

A_15675

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 ActivateAccount und GetHomeCommunityID, benötigen in ihrem Ablauf ein oder auch mehrere SM-Bs für die folgende Funktionalität:

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

6.5 Login

Der Login nach [gemSysL_Fachanwendung_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 4: Tab_FM_ePA_001 Daten zur Kommunikation mit den Komponenten des ePA-Aktensystems (abhängig vom Nutzer)

6.5.2 Authentisierung mittels SM-B

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

• PHRService
• • putDocuments
  • find
  • getDocuments
  • removeDocuments
  • updateDocumentSet
• PHRManagementService
• • RegisterSMB

Die Authentisierung LEI mit dem ausgewählten SM-B erfolgt durch das Fachmodul ePA. Hierzu erzeugt das Fachmodul ePA ein SAML-Token gemäß [WSS-SAML], 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.1 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].

6.5.4 Autorisierung

Autorisierung gegenüber dem ePA-Aktensystem

Die Komponente Autorisierung des lokalisierten ePA-Aktensystems prüft, ob im Rahmen der Aktensession 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 Akten- und Kontextschlüssel sowie eine Autorisierungsbestätigung (AuthorizationAssertion) zur Kommunikation mit der Dokumentenverwaltung ausgehändigt. 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. Entschlüsselung von Akten- und Kontextschlüssel zur Nutzung in der Aktensession

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.

Auswahl SM-Bs zur Autorisierung

I_Authorization::getAuthorizationKey liefert eine Liste von verschlüsselten Schlüsselpaaren (Kontext- und Aktenschlüssel) für alle zum Zugriff berechtigten SM-Bs, sowie eine AuthorizationAssertion passend zur Telematik-ID. Das Fachmodul ePA muss genau eines der Schlüsselpaare entschlüsseln, um an die Schlüsselmaterialien im Klartext zu gelangen. Die Komponente Autorisierung trägt bei Einbringung des Schlüsselmaterials mittels I_Authorization_Management::putAuthorizationKey die serialNumber gemäß [RFC5280#4.1.2.2.] des jeweiligen Zertifikats in das XML-Element <ds:KeyName>...</ds:KeyName> ein. Anhand der serialNumber kann das Fachmodul dann beim Abruf der Schlüsselpaare ein entsprechendes SM-B aus den vom Konnektor verwalteten SM-Bs aussuchen.

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 Operationen ActivateAccount und 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.1]  übertragen.

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

Aufbau der TLS-Verbindung

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

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

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

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

6.10 Fehlerbehandlung und 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).

Die nachfolgenden Tabellen enthalten alle Fehlermeldungen der übergreifenden Festlegungen des Fachmoduls ePA. Dazu gehören auch Fehlermeldungen, die aus anderen Spezifikationen nachgenutzt werden.

Tabelle 9: Tab_FM_ePA_011 - Übergreifende Fehlermeldungen des Fachmoduls ePA

Tabelle 10: Tab_FM_ePA_050 - Wiederverwendete Fehlermeldungen aus der Konnektorspezifikation

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

7 Funktionsmerkmale

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

Tabelle 12: 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 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

Der Webservice PHRService setzt die logischen Schnittstelle I_PHR_Management gemäß [gemSysL_Fachanwendung_ePA] um.

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 15: Tab_FM_ePA_006 Beschreibung und Parameter der Operation putDocuments

Fehlermeldungen

Die Operation putDocuments kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7206, 7208, 7209, 7220, 7400 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 16: Tab_FM_ePA_013 Beschreibung und Parameter der Operation find (Semantik)

Fehlermeldungen

Die Operation find kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7206, 7208, 7209, 7220, 7400 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 17: Tab_FM_ePA_027 Beschreibung und Parameter der Operation getDocuments (Semantik)

Fehlermeldungen

Die Operation getDocuments kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7206, 7208, 7209, 7220, 7400 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

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

Tabelle 18: 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, 7206, 7208, 7209, 7220, 7400 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 updateDocumentSet

Die Operation updateDocumentSet ermöglicht Primärsystemen, Metadaten bestehender Dokumente zu ändern.

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

Fehlermeldungen

Die Operation updateDocumentSet kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7206, 7208, 7209, 7220, 7400 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• reguläre bei IHE für [ITI-92] definierte Fehlermeldungen

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.

Die Dokumentenverwaltung lehnt Dokumente ab, deren Größe größer ist als 25 MB.

Die Dokumentenverwaltung lehnt Dokumente ab, wenn die Summe der Dokumente größer ist als 250 MB.

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 Abbildung Abb_FM_ePA_001 IHE-Akteure und Transaktionen der Fachanwendung ePA). 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

Unabhängig von der Art des Transports (MTOM/XOP versus Base64), die das Primärsystem gewählt hat, muss das Fachmodul ePA immer das Dokument selbst verschlüsseln, d.h., eine etwaige Base64-Kodierung vor der Verschlüsselung dekodieren.

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

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 (vgl. hierzu Abbildung Abb_FM_ePA_001 IHE-Akteure und Transaktionen der Fachanwendung ePA). 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 updateDocumentSet

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 der IHE-Akteure RMU Update Responder und RMU Update Initiator. Dazu nimmt das Fachmodul ePA die Anfrage als Update Responder vom Primärsystem entgegen und leitet sie anschließend an die Komponente Dokumentenverwaltung via [ITI-92] "Restricted Update Document Set" in der Rolle eines RMU Update Initiator an das ePA-Aktensystem weiter (vgl. hierzu Abbildung Abb_FM_ePA_001 IHE-Akteure und Transaktionen der Fachanwendung ePA). Das ePA-Aktensystem setzt dementsprechend ein RMU Update Responder um. Die Antworten nehmen den umgekehrten Weg.

Die Gruppierung von RMU Update Responder und RMU Update Initiator wird auch durch die "Forward Update" Option des RMU Update Responders gemäß RMU-Profil erzwungen.

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

7.2 PHRManagementService

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

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

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 21: Tab_FM_ePA_016 Beschreibung und Parameter der Operation ActivateAccount (Semantik)

Die Operation ActivateAccount kann folgende Fehlermeldungen zurückliefern:

• 7200, 7201, 7202, 7203, 7205, 7206, 7207, 7220, 7400 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• Fehlermeldungen gemäß Tab_FM_ePA_017

Tabelle 22 Tab_FM_ePA_017 - Fehlermeldungen der Operation ActivateAccount

7.2.1.2 RequestFacilityAuthorization

Tabelle 23 Tab_FM_ePA_020 Beschreibung und Parameter der Operation RequestFacilityAuthorization (Semantik)

Die Operation RequestFacilityAuthorization kann folgende Fehlermeldungen zurückliefern:

• 7200, 7201, 7202, 7203, 7205, 7206, 7207, 7208, 7220, 7400 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050
• 7210 gemäß Tab_FM_ePA_035

Tabelle 24: Tab_FM_ePA_035 - Fehlermeldungen der Operation RequestFacilityAuthorization

7.2.1.3 RegisterSMB

Tabelle 25: Tab_FM_ePA_018 Beschreibung und Parameter der Operation RegisterSMB (Semantik)

Die Operation RegisterSMB kann folgende Fehlermeldungen zurückliefern:

• 7200, 7202, 7205, 7206, 7209, 7220, 7400 gemäß Tab_FM_ePA_011
• 4000 gemäß Tab_FM_ePA_050

7.2.1.4 GetHomeCommunityID

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

Die Operation GetHomeCommunityID kann folgende Fehlermeldungen zurückliefern:

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

Tabelle 27: Tab_FM_ePA_032 - Fehlermeldungen der Operation GetHomeCommunityID

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

7.2.2.1 ActivateAccount

Der Ablauf der Operation ActivateAccount ist in [gemSysL_Fachanwendung_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

Der Abbruch erfolgt mit einer Warnung. Ein bereits aktiviertes Aktenkonto kann auch schon über den Versicherten hinaus Berechtigungen enthalten. Die Operation wird in diesem Fall abgebrochen, da bestehende Berechtigungen nicht verändert werden dürfen. 

Hinweis:
Ob ein Aktenkonto bereits aktiviert ist, kann durch Aufruf der Operation I_Authorization_Management::checkRecordExists ermittelt werden. Die Operation liefert den Status eines Aktenkontos.

Authentisierung gegenüber dem Aktensystem

Die Authentisierung gegenüber einem Aktensystem erfolgt gemäß 

A_15192

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_DM_ePA#2.5].

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

7.2.2.2 RequestFacilityAuthorization

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_15218

Bestätigung der Berechtigung per PIN-Eingabe

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.

Login am ePA-Aktensystem (Authentisierung und Autorisierung)

Die Authentisierung gegenüber einem Aktensystem erfolgt gemäß 

A_15192

Verbindung zur Dokumentenverwaltung

Die Verbindung zur Komponente Dokumentenverwaltung verläuft analog zum Login durch eine LEI mit dem Aufruf von Operationen des Webservices PHRService. Die Operation RequestFacilityAuthorization möchte mit der Komponente Dokumentenverwaltung kommunizieren und baut hierzu eine sichere Verbindung gemäß den Festlegungen in Kapitel 6.5.5 auf.

Ermittlung aller zugehörigen SM-Bs im Verzeichnisdienst

Die Berechtigungsvergabe zum Zugriff auf ein Aktenkonto erfolgt für eine LEI, identifiziert durch eine Telematik-ID.

Berechtigung in Komponente Autorisierung für alle SM-Bs 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 allen im Verzeichnisdienst gefundenen Zertifikaten der LEI verschlüsselt und mittels I_Authorization_Management::putAuthorizationKey in die Komponente Autorisierung eingebracht.

Für die Verschlüsselung von Akten- und Kontextschlüssel gelten die Vorgaben aus [gemSpec_DM_ePA#Kapitel 2.5].

Die Erteilung der Berechtigung auf die Patientenakte ist nur bestimmten Institutionstypen gestattet. Der Institutionstyp der jeweiligen Institution ist im X.509-Zertifikat des SM-B als OID („ProfessionOID“) hinterlegt. Die Komponente Autorisierung prüft die OID beim Aufruf von I_Authorization_Management::putAuthorizationKey und lehnt alle nicht zulässigen Werte mit dem Fehler AUTHORIZATION_ERROR ab.

Hinweis:
Das aktuelle Datum validTo wird bei der Aktualisierung der Berechtigungen des jeweiligen Aktenkontos in der Komponente Autorisierung auf das maximale Datum geändert.

Falls für ein Zertifikat eines SM-B bereits ein Schlüsselpaar in der Komponente Autorisierung vorhanden ist, wird der Aufruf von I_Authorization_Management::putAuthorizationKey erfolgreich beendet, ohne das Schlüsselmaterial zu verändern. Der RecordIdentifier wird hierbei 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

7.2.2.3 RegisterSMB

Mit der Operation RegisterSMB berechtigt eine LEI neue, ihr zugehörige, SM-Bs aus dem Verzeichnisdienst der TI für jedes Aktenkonto aus dem Parameter KnownRecords.

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_15218

Der Zugriff auf alle Patientenakten eines ePA-Aktensystem kann zwar mit der gleichen AuthenticationAssertion erfolgen, erfordert aber für jede Akte eine neue AuthorizationAssertion. Zudem könnte es sein, dass die Berechtigungen des ausgewählten SM-B nicht für alle in KnownRecords übermittelten Patientenakten gelten. Ein Grund hierfür könnten etwa unterschiedliche Zertifikate im Verzeichnisdienst zum Zeitpunkt der Berechtigungsvergabe sein. In diesem Fall muss das Fachmodul zur Entschlüsselung des mit I_Authorization_Management::replaceAuthorizationKey abgerufenen Schlüsselmaterials einfach ein anderes SM-B auswählen.

Ermittlung aller zugehörigen SM-Bs im Verzeichnisdienst

Die Fehlerbehandlung erfolgt analog zu der Operation RequestFacilityAuthorization (siehe A_14820).

Login an den ePA-Aktensystemen der übergebenen Aktenkonten (Authentisierung und Autorisierung)

Der Aufruf zur Aktualisierung der Berechtigungen (I_Authorization_Management::replaceAuthorizationKey der Komponenten Autorisierung) erfordert die Authentisierung und die Autorisierung gegenüber den ePA-Aktensystemen aller im Parameter KnownRecord übertragenen Aktenkonten. Der Ablauf verläuft jeweils analog zum Login bei Aufruf einer Operation des Webservices PHRService. Eine Verbindung zur Komponente Dokumentenverwaltung ist nicht notwendig.

Aktualisierung der Berechtigungen

Für die Verschlüsselung von Akten- und Kontextschlüssel gelten die Vorgaben aus [gemSpec_DM_ePA#2.5].

7.2.2.4 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 Komponenten Autorisierung eines ePA-Aktensystems

Gemäß 

A_14105

Abfrage der ePA-Aktensysteme

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 passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

8.5.2 Weitere Dokumente