Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme ePA für alle

    

     

      
Version
      
3.0.0_CC
     
     

      
Revision
      
796818
     
     

      
Stand
      
15.12.2023
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemILF_PS_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

Die vorliegende Spezifikation definiert Anforderungen zu Erstellung, Test und Betrieb derjenigen Anteile eines Primär- oder Clientsystems, die zur Nutzung der ePA für alle erforderlich sind.

Technische Standards werden in der ePA verwendet, um Interoperabilität zu steigern und die technischen Voraussetzungen zur Nutzung der Anwendung zu legen. Auf Seiten der Primärsystemhersteller eröffnet die Verwendung von Standards die Chance, wiederverwendbare Schnittstellen zu entwickeln bzw. zu nutzen und einzelne Module austauschbar zu gestalten.

Zum Zweck der Implementierungshilfe werden grundlegende Konzepte und Anwendungsfälle der ePA für alle aus der Sicht der PS-Hersteller erläutert. Dabei werden nicht nur Anwendungsfälle der ePA erläutert, sondern auch praktische Umsetzungshinweise gegeben sowie auf Beispiele verwiesen.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Hersteller von Primärsystemen, welche die Schnittstellen der ePA für alle nutzen.

Falls ein Primärsystem bisher das technische Framework von IHE noch nicht verwendet, wird es durch diesen Implementierungsleitfaden in die Lage versetzt, die ePA-Schnittstellen IHE-konform zu verwenden.

Falls ein Primärsystem das technische Framework von IHE bereits verwendet, schildert der Implementierungsleitfaden ihm die relevanten Einschränkungen des IHE-Frameworks, die für die ePA der Telematikinfrastruktur von Relevanz sind. Die IHE-Konformität dieser Schnittstellen ermöglicht ihm die Anbindung weiterer Anwendungen.

Mit der ePA für alle werden viele Schnittstellen als REST-Schnittstellen angeboten. Der Implementierungsleitfaden beschreibt die Umsetzung dieser Schnittstellen und der genutzten FHIR-Ressourcen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Bestätigungs- Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. [gemPTV_ATV_Festlegung], Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt 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

Benutzte Schnittstellen werden in der Spezifikation desjenigen Produkttypen normativ beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 8.5).

Nicht Bestandteil des vorliegenden Dokumentes sind:

• Festlegungen zum Themenbereich Semantik von Metadaten, insoweit sie im Dokument [gemSpec_Aktensystem_ePAfuerAlle] beschrieben sind;
• Rendering-Vorschriften zur Form, in der ePA-Dokumente zur Anzeige gebracht werden (ggf. wird auf externe Festlegungen referenziert).

Die ePA fungiert als Sekundärdokumentation von Daten der Versicherten. Die Primärdokumentation der Versichertendaten im PS wird nur insoweit thematisiert, wie es für die Anbindung der ePA an das PS erforderlich ist.

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.

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

Abbildung 1: Überblick ePA für alle

Die zentralen Funktionen der ePA für alle sind das integre Management von wohl definierten Metadaten und den medizinischen Dokumenten als auch die Unterstützung von digitalen Versorgungsprozessen. Initial bedient das Aktensystem den digital gestützten Medikationsprozess durch die Bereitstellung einer elektronischen Medikationsliste (eML) an Leistungserbringer.

Das Primärsystems bietet einem Leistungserbringer als Nutzer den Zugang zur elektronischen Patientenakte des gesetzlich Versicherten an. Dabei greifen Leistungserbringer und Primärsystem über eine vertrauenswürdige Ausführungsumgebung (VAU) geschützt auf die elektronische Patientenakte zu und nicht mehr gekapselt über den Konnektor. Das in der ePA 2.x genutzte ePA-Fachmodul im Konnektor entfällt in der ePA für alle.

Wenn von dem "Aktenkonto" im Folgenden gesprochen wird, ist die ePA als Sekundärakte des Versicherten gemeint, nicht die "Primärakte" für den Versicherten im Primärsystem. Mit "Aktenanbieter" ist im Folgenden immer der Anbieter des ePA-Aktensystems gemeint. 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.

Die Nutzer der Primärsysteme der Leistungserbringer teilen sich die technische Infrastruktur der ePA in der Telematikinfrastruktur, folgen dabei den hier geschilderten Regeln der TI und bilden in diesem Sinne eine IHE-Affinity Domain, um ePA-Daten gesteuert durch die Befugnisvergabe des Versicherten auszutauschen. Dieser Datenaustausch erfolgt in vielerlei Hinsicht gemäß Festlegungen von IHE.

Die technische Infrastruktur der ePA besteht beim Leistungserbringer vor allem aus dem Konnektor, den Kartenlesegeräten und den Smartcards. Mit dem Konnektor stehen auch die Komponenten der Basis-TI, die zentrale TI und der Fach- und Basisdienste der TI zur Verfügung, deren Nutzung durch das PS in [gemILF_PS] beschrieben sind.

Die Authentifizierung für die Zugriffe auf die ePA erfolgt durch den Identity Provider (IDP). Der Identity Provider (IDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern, die sich über eine Institutionskarte (SMC-B) ausweisen können, und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen ermöglicht. Der IDP authentifiziert den Nutzer anhand der kartenbasierten Identität und einer Signatur durch das Schlüsselmaterial auf der Karte (SMC-B) und stellt bei Erfolg einen IDP-Token für den Zugriff auf den Fachdienst aus.

Für einen Leistungserbringer liegt die Befugnis zur Nutzung der ePA des Versicherten vor, wenn ein Behandlungskontext besteht. Der Behandlungskontext wird im Rahmen von VSDM festgestellt, d. h. mit dem Stecken der eGK im Rahmen von VSDM.

Das Dokument [gemKPT_ePAfuerAlle] bietet einen Überblick zur ePA für alle.

2.1 Akteure und Rollen

Leistungserbringer agieren in zwei ePA-Szenarien: 

• als Einsteller und Konsument im bilateralen Dokumentenaustausch zwischen LE und Versichertem 
• als Einsteller und Konsument in der Interaktion zwischen Leistungserbringern über die ePA

Das PS tritt somit in der Consumer Zone der TI sowohl als Document Consumer als auch als Document Source auf, beim Löschen auch als Document Administrator.

Gemäß [gemILF_PS#3.1.3] können Heilberufler ihren SM-B selbst nutzen oder ihre Gehilfen im Allgemeinen dafür autorisieren, auf die Anwendungen der eGK mit ebendiesen Rechten zuzugreifen. Dies gilt für das SM-B der TI-Rollenprofile 2, 3, 4 (SM-B Leistungserbringer). Eine Ausnahme hierzu bilden ausschließlich die Gehilfen der nichtärztlichen Psychotherapeuten. Das PS darf die berufsmäßigen Gehilfen der nichtärztlichen Psychotherapeuten nicht mit denjenigen Zugriffsberechtigungen auf die ePA ausstatten, über die der nichtärztliche Psychotherapeut verfügt. 

Die Versicherten agieren in der Rolle des Akteninhabers und in der Rolle des Vertreters des Akteninhabers. 

Auch innerhalb größerer Leistungserbringer-Institutionen ist ein Akteur gegenüber der ePA mittels seiner Telematik-ID als eigenständiger Nutzer identifiziert, nicht als Mandant einer übergreifenden Institution. Die Mandantenverwaltung innerhalb einer größeren Institution, etwa einem Krankenhaus, muss ggf. dafür genutzt werden, um den Prüfungsnachweis des Mandanten nutzen zu können, der aktuell in der ePA aktiv ist.

Unterschiedliche Arten von Primärsystemen (PS) und Clientsystemen (CS) haben je nach ihren fachlichen Nutzungsprofilen unterschiedliche Anforderungshaushalte.

• PS = Client gegenüber dem Aktensystem mit Userinteraktion
• CS = Client gegenüber dem Aktensystem potentiell ohne Userinteraktion 

Normative Anforderungshaushalte unterschiedlicher Systeme sind jeweils in speziellen Produkttypsteckbriefen (PTSB) aufgeführt. Der PTSB hat im Zweifelsfall Priorität gegenüber der Unterscheidung zwischen Primärsystem und Clientsystem im Fließ- und Anforderungstext.

Tabelle 1: TabILF_Kurzübersicht_PS-Typen

3 Übergreifende Festlegungen

In diesem Kapitel werden die übergreifenden Festlegungen zum erfolgreichen Kommunikationsaufbau zwischen Primärsystem und einem Aktenkonto beschrieben.

3.1 TLS

Das Primärsystem benutzt für die Kommunikation im Rahmen der Anwendungsfälle der ePA für alle ausschließlich TLS.

Es gelten die Vorgaben aus [gemSpec_Krypt] für TLS.

3.2 Lokalisierung der Service-Endpunkte der ePA

Das Primärsystem erfährt die Endpunkte der verschiedenen Aktensysteme über die DNS-Service Discovery (DNS-SD) für eine übergreifende Domäne entweder über den DNS-Resolver des Konnektors oder den konfigurierten DNS-Resolver für das Internet. Hinterlegt sind dort alle Service-Endpunkte in der Telematikinfrastruktur für die verschiedenen Aktensysteme. Die DNS-SD wird durch den entsprechenden ePA-Client einmal täglich abgefragt.

Die übergreifende Domäne lautet epa4all.de. Darunter sind die Sub-Domänen für die unterschiedlichen Umgebungen:

• prod.epa4all.de
• ref.epa4all.de
• dev.epa4all.de
• test.epa4all.de.

Die nach außen angebotenen und für die Primärsysteme relevanten Dienste der ePA-Aktensysteme stehen unter folgenden URLs zur Verfügung:

• https://<FQDN aus DNS Lookup>:443/info/I_Information_Service
• https://<FQDN aus DNS Lookup>:443/epa/<Schnittstellen der verschiedenen Services in der VAU>.

Das Primärsystem erreicht die ePA-Aktensysteme und den IDP über den Konnektor geroutet. Je nach Installationsumgebung des Primärsystems ist der Konnektor evtl. nicht das Default-Gateway. Um diese Fachdienste zu erreichen, müssen ggfs. feste Routen und eine DNS-Konfiguration pro Arbeitsplatz-Computer im Rahmen der Installation festgelegt werden.

Die Informationen zu den Endpunkten des Identity Providers ermittelt das Primärsystem aus dem Discovery Document, siehe auch [gemSpec_IDP_Dienst#Registrierung von Endgerät und Anwendungsfrontend]. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar.

3.3 Lokalisierung der Akte eines Versicherten

Wenn dem Primärsystem nicht bekannt ist, bei welchem Aktensystembetreiber ein Aktenkonto liegt, muss es den zuständigen Service-Endpunkt ermitteln. Dazu wendet sich das PS an den Information Service außerhalb der VAU eines Aktensystems, um dort nach der Akte zu fragen.

Konnte das Aktenkonto ermittelt werden, wird der zuständige Service-Endpunkt gespeichert. Gibt der Informationsdienst den Aktenkonto-Status "Unknown" zurück, wiederholt das Primärsystem den Aufruf beim nächsten Aktensystem.

Kennt kein Aktensystem die Akte, hat der Versicherte der ePA widersprochen und es existiert keine Akte.

Dazu wird folgende Operation genutzt:

Tabelle 2: I_Information_Service::getRecordStatus

3.4 User Session und Login in ein Aktenkonto

Das Primärsystem kommuniziert als ePA-Client mit dem ePA-Aktensystem in einer Vertrauenswürdige Ausführungsumgebung (VAU). Diese stellt sicher, dass sensible Klartext-Daten wie z. B. die medizinischen Daten des Versicherten sicher vor Angriffen verarbeitet werden können. Die Daten werden ausschließlich über sichere VAU-Kanäle vom PS in die VAU transportiert bzw. aus der VAU abgerufen.

Das Primärsystem initiiert den Aufbau eines VAU-Kanals in die VAU des Aktensystems. Dabei authentisiert sich die VAU mit ihrem Zertifikat als authentische VAU des Aktensystems. Anschließend wird für den Nutzer, repräsentiert durch die SMC-B, mit Hilfe des IDP-Dienstes eine User Session angelegt. Diese User Session ermöglicht den Zugriff auf alle Aktenkonten des Aktensystems, sofern der Nutzer für diese befugt ist. Durch eine Anfrage an eine bestimmte Akte wird diese in der User Session als Health Record Context geladen und man kann darauf arbeiten.

Abbildung 2: Überblick über Aufbau VAU, User Session und Aktensession

3.4.1 VAU

Für Informationen zum Kommunikationsprotokoll zwischen dem Primärsystem und einer VAU siehe und [gemSpec_Krypt#7].

Die gematik stellt Beispielimplementierungen des VAU-Protokolls der ePA für alle in verschiedenen Programmiersprachen zur Verfügung.

3.4.2 Nutzerauthentifizierung per IDP-Dienst mittels OIDC-Flow

Die Authentifizierung der LEI erfolgt mittels IDP-Dienst:

Abbildung 3: Überblick über Nutzerauthentifizierung

1. Die Nutzerauthentifizierung wird durch einen Zugriff des Primärsystems auf das ePA-Aktensystem getriggert.

2. Da der Nutzer noch nicht angemeldet ist, leitet der Authorization Server des ePA-Aktensystem an den IDP-Dienst weiter. Am IDP-Dienst authentisiert sich der Nutzer mittels SMC-B und PIN. Bei erfolgreicher Authentisierung erhält das Primärsystem einen Authorization Code.

3. Das Primärsystem übermittelt den Authorization Code an das ePA-Aktensystem.

Der Authorization Server im ePA-Aktensystem ruft mittels des Authorization Codes das ID-Token für den Nutzer vom IDP-Dienst ab. Das ID-Token ist vom IDP-Dienst signiert. Als Ergebnis ist ein ID-Token des Nutzers in der VAU vorhanden. Liegt ein ID-Token des Nutzers in der VAU vor, wird durch den User Session Manager eine User Session für den Nutzer gestartet und die LEI kann auf die Aktenkonten (sofern eine Befugnis vorhanden ist) zugreifen.

Die folgende Abbildung zeigt den Nachrichten-Flow im Detail:

Abbildung 4: Detaillierter Nachrichten-Flow für die Nutzerauthentifizierung mit dem IDP-Dienst

Vorbereitend zum OIDC-Flow fragt das PS eine Nonce ab (0), die es mit der SMC-B signiert als "Attestation der Umgebung".

Dazu nutzt es folgende Operation:

Tabelle 3 : I_Authorization_Service::getNonce

Der eigentlich IDP-Flow startet mit der Anfrage des PS an den Authorization Service (1). Dazu nutzt es folgende Operation:

Tabelle 4 : I_Authorization_Service::send_Authorization_Request_SC

Die Response enthält "clientID" (des Aktensystems),"response_type",  "redirect_uri", "state", "code_challenge",  "code_challenge_method",  "scope" und  "nonce" (3 und 4).

Das Authenticator Modul des PS stellt nun einen GET: AUTHORIZATION REQUEST an den zentralen IDP mit den vom Authorization Service erhaltenen Parametern (5).

Der Authorization-Endpunkt legt nun eine "session_id" an, stellt alle nötigen Informationen zusammen und erzeugt das "CHALLENGE_TOKEN".
Darüber hinaus stellt der Authorization-Endpunkt den im Claim des entsprechenden Fachdienstes vereinbarten "Consent" zusammen, welcher die für dessen Funktion notwendigen Attribute beinhaltet.

Der IDP-Dienst antwortet dem PS dann mit dem Challenge-Token und dem User Consent (6a).

Das Primärsystem verwendet nun die AUT-Identität der SM-B der LEI und deren Konnektor, um das gehashte "CHALLENGE_TOKEN" des IDP-Dienstes zu signieren. Wenn es sich um eine erstmalige Anmeldung des Benutzers bei diesem Fachdienst handelt, werden diesem darüber hinaus die für den Zugriff übermittelten Daten der LEI angezeigt.

Hinweis: Die erfolgte Zustimmung des Nutzers darf gespeichert werden und weitere Abfragen können entfallen.

Hinweis: Damit das bei der Signatur bevorzugt zu verwendene ECC-Zertifikat gelesen wird, muss bei der Operation ReadCardCertificate der Parameter Crypt auf ECC gesetzt werden. Nur bei einer Karte der Generation G2 kann der Default (RSA) genutzt werden.

Anschließend werden die signierte "challenge" und das verwendete Authentisierungszertifikat der Smartcard an den IDP-Dienst übermittelt (6b).

Hinweis: Der Aufbau der Anfrage und der einzureichenden Objekte entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].

Hinweis: Das Signieren und Verschlüsseln des "CHALLENGE_TOKEN" ist durch die Verwendung eines Nested JWT [angelehnt an den folgenden Draft: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03, zu realisieren. Im cty-Header ist "NJWT" zu setzen, um anzuzeigen, dass es sich um einen Nested JWT handelt. Das Signieren wird dabei durch die Verwendung einer JSON Web Signature (JWS) [RFC7515 # section-3 - Compact Serialization] gewährleistet. Die Verschlüsselung des signierten Token wird durch die Nutzung der JSON Web Encryption (JWE) [RFC7516 # section-3] sichergestellt. Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Der Authorization-Endpunkt validiert nun die "session" sowie die "signed_challenge" und prüft das Zertifikat der LEI. Anschließend verknüpft er die "session" mit der Identität aus dem Authentisierungszertifikat und erstellt einen "AUTHORIZATION_CODE", welchen er als Antwort zurücksendet.

Das Primärsystem empfängt nun diesen "AUTHORIZATION_CODE" vom IDP-Dienst (7).

Das PS sendet diesen Authorization Code an den Authorization Service des Aktensystems (1). Dazu nutzt es die Operation send_AuthCode:

Tabelle 5: I_Authorization_Service::send_AuthCode

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

3.4.2.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes

Zur Nutzung des IDP-Dienstes gelten einige grundlegende Voraussetzungen, welche das PS erfüllen muss:

Hinweis: Der genaue Aufbau entspricht [gemSpec_IDP_Dienst#7.7 Aufbau des Discovery Document].

Bei Aufruf der Funktion "VerifyDocument" an der Außenschnittstelle des Konnektors ist es nicht möglich, direkt auch eine Prüfung des Zertifikatstyps und der Rollen-OID durchzuführen.

Hinweis: Zur Durchführung der Prüfungen gemäß A_20657 und ähnlicher Anforderungen ist zu verifizieren, ob im Feld certificatePolicies (2.5.29.32) des Zertifikates der richtige Zertifikatstyp FD.SIG (1.2.276.0.76.4.203) gemäß [gemSpec_OID#Tabelle Tab_PKI_405] eingetragen ist und sich in der Admission (1.3.36.8.3.3) des Zertifikats die richtige "oid_idpd" (1.2.276.0.76.4.260) findet.

3.4.3 Logout

Das Primärsystem muss sich nicht explizit aus dem EPA-Aktensystem ausloggen. Ein implizites Logout findet statt,

• wenn die User Session endet (durch Renew-Anzahl des IDP-Token begrenzt),
• wenn der VAU-Kanal nach längerer Inaktivität abgebaut wird.

3.4.4 Aktenkontokennung

Das PS addressiert das gewünschte Aktenkonto über die KVNR des Versicherten. Bei Aufrufen innerhalb der VAU muss es ein HTTP-Header-Element mit dem Namen "x-insurantId" senden.

Werden Services außerhalb der VAU angesprochen, erfolgt die Adressierung über den Pfad, z. B. bei der Operation getConsentDecisionInformation  "/information/{insurantid}/consentdecisions".

3.4.5 Zertifikate

Die kryptographischen Vorgaben im TLS-Bereich sind für das E-Rezept und ePA für alle ähnlich. Das VAU-Protokoll der ePA für alle unterscheidet sich vom E-Rezept-VAU-Protokoll, weil ein andere Authentisierungsvariante von OIDC/OAuth2/PCKE verwendet wird. Diese wird in einer späteren Ausbaustufe vom E-Rezept ebenfalls verwendet. Ab dann verwenden beide Anwendungen das VAU-Protokoll von ePA-für-alle.

Tabelle 6 : TAB_ILF_Zertifikate

Kontext OCSP: Die aufgrund der historischen Entwicklung von OCSP als Abfragemechanismus einer CRL-Abfrage bei einem TSP stammenden Werte thisUpdate und nextUpdate sind für A_24906-* irrelevant. Was zählt ist, dass der bestmögliche Informationsstand eines TSP zum Zeitpunkt producedAt in der Antwort dokumentiert ist. Dieser Informationsstand wird im Cache für die in A_24906-* aufgeführte Zeit als maßgeblich betrachtet und im prüfenden System verwendet.

Falls Sperrinformationen grundsätzlich vom zu authentifizierenden System mit gesendet werden (bspw. TLS-OCSP-stapling, VAUServerHello), so holt der Client diese nicht aktiv ein, d. h., A_24906-* greift in Bezug auf das Caching nicht als MUSS-Bestimmung.

3.5 SOAP

In der ePA für alle nutzt das Primärsystem SOAP für den Zugriff auf die IHE-Schnittstellen des XDS Document Service.

Die SOAP-Schnittstellen werden nachrichtenbasiert über SOAP1.2 mit [BasicProfile2.0] angesprochen.

Die Bildung der SOAP-Nachrichten durch das Primärsystem wird in diesem Dokument technologie-neutral geschildert. Dabei werden die Voraussetzungen für unterschiedliche Strategien zur Nachrichtenerzeugung geliefert, darunter:

• Nutzung von Template Engines
• Codegenerierung mittels WSDL und XSD.

Die ePA nutzt bei bestimmten Operationen den SOAP-Header, um Informationen über den Aktenkontext und die Telematik-ID zu erhalten.

3.6 REST

In der ePA für werden die vom Primärsystem angesprochenen Dienste wie der Information Service, Entitlement Management und den Medication Service über OpenAPI- sowie FHIR-Profildefinitionen festgelegt. Die Schnittstellen und Operationen sind funktional in den Beschreibungen der jeweiligen Schnittstelle beschrieben.

3.7 Mandantenverwaltung

Sowohl Befugnisse als auch ID-Token verwenden dedizierte anwendungsfallübergreifend identische Telematik-IDs. In größeren Einrichtungen kann daher eine Mandantenverwaltung für die Nutzung der ePA erforderlich sein.

Die Nutzung ePA-fähiger Aufrufkontexte ist in kleineren Einrichtungen mit nur einer einzigen verwendeten SMC-B einfacher umzusetzen als in großen Einrichtungen, in denen es viele verwendete SMC-Bs zu konfigurieren gilt. Eine Voraussetzung für eine funktionierende ePA besteht darin, dass die Leistungserbringerinstitution so konfiguriert ist, dass die Beziehung zwischen der Telematik-ID der signierten Befugnis immer genau der Telematik-ID aus dem IDP-Token entspricht. 

Die Verwendung der korrekten SMC-B wird über den Aufrufkontext gesteuert.

Abbildung 5: ILF_ePA_Element_Context

Beispiel #: Bsp_ILF_ePA_Context 

3.8 Funktionsmerkmale

Leistungserbringerinstitutionen haben zwei Möglichkeiten, vom Versicherten eine Befugnis zum Zugriff auf das Aktenkonto zu erhalten:

1. Der Versicherte erteilt eine Befugnis für die LE-Institution am ePA-Frontend des Versicherten.
2. Im Behandlungskontext wird vom PS im Zusammenhang mit dem Einlesen der eGK eine Befugnis einstellt.
   

Die Befugnis kann sowohl vom Versicherten selbst stammen, als auch vom Vertreter des Versicherten. Sie ist auf Leistungserbringer (inkl. deren berufsmäßigen Gehilfen oder zur Vorbereitung auf den Beruf Tätige, jedoch nicht die Gehilfen der nichtärztlichen Psychotherapeuten) eingeschränkt.

Die Laufzeit von Befugnissen ist begrenzt. Falls eine Befugnis aufgrund in der Vergangenheit liegendem validTO oder Befugnisentzug am ePA-Frontend des Versicherten nicht mehr existiert, ist eine erneute Berfugnisvergabe erforderlich.

3.9 Erstellen einer Befugnis

Die Leistungserbringerorganisation benötigt eine Befugnis (Entitlement), um auf die ePA eines Versicherten zugreifen zu können.

Abbildung 6: Ablauf Erstellung einer Befugnis

Der Auslöser zur Erstellung einer Befugnis ist das etablierte quartalsweise Lesen der eGK mit Onlineprüfung (1). Dabei wird vom Konnektor-Fachmodul VSDM ein Prüfungsnachweis erzeugt und in der ReadVSD-Response an das PS geliefert. Der Prüfungsnachweis enthält im Falle einer erfolgreichen Online-Prüfung (Ergebnis 1 oder 2) im Element Receipt die Prüfziffer des Fachdienstes als eine Base64Binary-kodierte Folge von bis zu 65 Bytes.

Damit die Prüfziffer in Verbindung zur Umgebung gesetzt werden kann, erfolgt die Erstellung eines signierten JSON-Web-Token (JWS). Dazu wird das JWS mit der AUT-Identität der SMC-B signiert (2), bevor es im Entitlement Management des Aktensystems als Befugnis registriert (3) wird.

Die Befugnisdauer wird vom Aktensystem festgelegt. Die in der LEI erzeugte Befugnis muss innerhalb dieses Zeitraumes nicht erneuert werden. Im Falle eines späteren Hochladens eines neueren Entitlements im vorliegenden Quartal gilt der aktuellere bzw. aktualisierte Befugniszeitraum. 

Die Befugnisdauer beträgt

• 3 Tage für Apotheken, ÖGD und Institutionen der Arbeits- und Betriebsmedizin und
• 90 Tage für alle anderen Arten von Leistungserbringer-Institutionen.

Das Einstellen einer Befugnis aus der LEI-Umgebung erfolgt über folgende Operation des Entitlement Management des Aktensystems:

Tabelle 7: I_Entitlement_Management::setEntitlementPs

3.9.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Erstellen einer Befugnis sind:

Vorbedingung:

• Ermittelter Service-Endpunkt zum Aktenkonto
• erfolgreiches ReadVSD mit Online-Prüfung

Auslöser:

• Erhalt einer Prüfziffer durch Lesen der eGK mit erfolgreicher Online-Prüfung (Prüfnachweis 1 oder 2)
  

Aktivitäten:

• Auswahl KVNR
• Auswahl des Service-Endpunkts zum Aktenkonto
• Auswahl der Prüfziffer des Versicherten
• Bildung eines JWS mit Prüfziffer und Zertifikat
• JWS signieren mit SMC-B
• JWS als Entitlement einstellen
• Auswertung des Ergebnisses

Resultat:

• Die Antwort gibt Auskunft darüber, ob eine Befugnis im Aktensystem erzeugt werden konnte oder nicht.
• Das Einstellen scheitert z. B., wenn die SMC-B nicht zur Gruppe der erlaubten Berufsrollen (professionOID) gehört oder wenn die LEI selbst oder die ganze Nutzergruppe vom Versicherten geblockt wurde.
• Die Antwort enthält im Erfolgsfall mit dem validTo das Enddatum der Befugnisdauer. Das PS kann die Befugnisdauer persistieren.
  

3.9.2 Nutzung

Getrennte Mandanten im Primärsystem verfügen über SMC-Bs mit je verschiedenen Telematik-IDs. Wenn es SMC-Bs mit mehr als einer Telematik-ID gibt, muss dies in der Konfiguration von Konnektor und Primärsystem und im Aufrufkontextes der SMC-B berücksichtigt werden.

3.10 Versorgungsspezifische Services

Die ePA für alle unterstützt verschiedene Versorgungsprozesse mittels dedizierter Services. Initial unterstützt sie den digital gestützten Medikationsprozess (dgMP) durch die Bereitstellung einer Elektronischen Medikationsliste (eML) über einen FHIR Data Service.

3.10.1 Widersprüche zu Versorgungsprozessen abrufen

Versicherte können der Teilnahme an durch die ePA unterstützen Versorgungprozessen widersprechen. Das PS kann die Entscheidung zu Teilnahme (ConsentDecision) abfragen. Sie kann dabei den Zustand "kein Widerspruch erklärt" ("permit") oder "Widerspruch erklärt" ("deny") haben. Die Versorgungsprozesse werden über eine ID referenziert ( z. B. die Teilnahme am Medikationsprozess "id":"medication").

Über diese Operation des Information Service kann das PS die Entscheidung zu den Versorgungsprozessen abfragen:

Tabelle 8: I_Information_Service::getConsentDecisionInformation

Wenn es bei Aufrufen im Rahmen des Versorgungsprozesses zu einem Fehler kommt, ist eine Wiederholung der Abfrage der Widersprüche sinnvoll.

3.10.2 Medikationsprozess

Der digital gestützte Medikationsprozess (dgMP) wird über eine kuratierbare, elektronische Medikationsliste (eML) durch den Medication Service umgesetzt. In der initialen Ausbaustufe der ePA für alle ist diese Liste durch Leistungserbringer und Versicherte nur lesend verarbeitbar. In der eML finden sich die vom E-Rezept-Fachdienst übergebenen und aufbereiteten Verordnungen und Dispensierinformationen.

Die eML soll von den Primärsystemen im Rahmen der Verschreibung eines Medikaments und bei der Ausgabe des Medikaments in der Apotheke abgerufen und dargestellt werden.

Dazu bietet der Medication Service mehrere Möglichkeiten:

Das Primärsystem kann über die folgenden URL-Aufrufe diese Formate anfordern:

Tabelle 9: I_Medication_Service_eML_Render

Für Primärsysteme, die bereits FHIR-basiert arbeiten, gibt es auch die Möglichkeit, über die standardisierte FHIR-Schnittstelle sämtliche Medikationen vollständig (und historisiert) abzufragen.

Tabelle 10: I_Medication_Service_FHIR

3.11 Dokumentenmanagement

Für das Dokumentenmanagement in der ePA für alle nutzt das PS eine Profilierung der IHE-Spezifikationen rund um das Kernprofil XDS.b (Cross-Enterprise Document Sharing).

Tabelle 11: Tab_ILF_ePA_DM_Profilierung

Das Aktensystem setzt in DocumentEntry.hash eine Prüfsumme eines Dokumentes. Mithilfe dieser Prüfsumme kann ein PS eine Dublettenprüfung durchführen, um nicht unnötig Duplikate von Dokumenten in die ePA einzustellen oder Dokumente mehrfach herunterzuladen. 

Ordner können durch die Option "Folder Management" (XDS.b Document Source) verwendet werden. Durch die Assoziation eines Dokumentes zu einem dieser Ordner wird das Dokument dem Ordner der entsprechenden Dokumentenkategorie bzw. Dokumentensammlung zugeordnet. Nur für dynamische Dokumentensammlungen (pregnancy_childbirth) werden Ordner durch Primärsysteme erstellt, ansonsten werden Dokumente und Daten den Ordnern vom Aktensystem zugewiesen.

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

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

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

3.11.1 Dokumente einstellen [ITI-41]

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

Alle alten Dokumente (Status "Deprecated") können nach wie vor gefunden und heruntergeladen werden. Einige Suchen erlauben das Filtern nach Status bzw. zeigen per Default auch nur Dokumente im Status „Approved“ an.
Eingestellt (im „Submission Set“) wird das neue Dokument inkl. DocumentEntry-Metadaten, ein Verweis auf das alte Dokument und die verbindende „Replace“-Association (urn:ihe:iti:2007:AssociationType:RPLC).

Das Ersetzen eines existierenden Dokuments mit der XDS-Option „Document Replacement“ eignet sich dafür, eine Änderung an einem bereits bestehenden Dokument abzubilden. Metadaten werden jedoch über Restricted Update Document Set geändert.

3.11.1.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente einstellen sind:

Vorbedingungen:

• Dokumente sind einer KVNR zugeordnet
• Das einzustellende Dokument sollte mit dem Versicherten besprochen sein
• gültige Befugnis

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Auswahl der Dokumente
• Ermittlung der Metadaten zu den Dokumenten
• Generierung inklusive Metadaten
• Validierung der Nachricht
• Versand der Nachricht
• Auswertung des Ergebnisses

Resultat:

• Die Antwort gibt Auskunft darüber, ob die Dokumente eingestellt werden konnten oder nicht.

3.11.1.2 Nutzung

Die Auswahl der Metadaten soll möglichst weitgehend automatisiert werden.

Dokumente werden statischen Ordnern automatisch am Aktensystem aufgrund der vergebenen Metadaten zugeordnet. Dokumente werden dynamischer Ordnern (pregnancy_childbirth) hingegen durch das PS zugeordnet. 

Das Kinderuntersuchungsheft wird in die ePA des Kindes eingestellt.

Der errechnete Entbindungstermin im dynamischen Ordner pregnancy_childbirth wird mit dem initial errechneten Wert befüllt. Eine spätere Änderung des Ordnernamens ist zur Identifizierung der Schwangerschaft nicht erforderlich, auch wenn zu einem späteren Zeitpunkt ein anderer Entbindungstermin errechnet werden sollte.

Die entryUUID des Ordners kann z. B. über die Suche FindFolders mit entsprechendem Filter auf Folder.codeList ermittelt werden.

Wenn für das Feld SubmissonSet.AuthorPerson keine Person als Einsteller angegeben werden kann, ist das Feld mit Werten zu befüllen, mit denen die einstellende Softwarekomponente beschrieben wird. Laut [gemSpec_Aktensystem_ePAfuerAlle#A_14762*] wird die Softwarekomponente eines Geräts als Nachname und ggf. als Vorname(n) eingetragen.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY

Der Wert "CON" wird vom Aktensystem nicht persistiert und ausschließlich für das Verbergen von Dokumenten mittels der General Deny Policy verwendet.

Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (Kennzeichnung über entsprechende Auswahl aus SubmissionSet.AuthorRole, und dem konfigurierten XDSDocumentEntry.healthcareFacilityTypeCode) kategorisiert, um sie von Dokumenten zu unterscheiden, die vom Versicherten selbst (SubmissionSet. AuthorRole="102") oder von Kostenträgern (SubmissionSet.AuthorRole="105") eingestellt wurden. Das heißt u. a., dass die Codes für Versicherte und Kostenträger ("102" und "105") dabei explizit nicht verwendet werden dürfen.

Die Unterstützung für RPLC (replace) durch das Aktensystem ermöglicht, dass Dokumente durch eine neue Version des gleichen Dokuments ersetzt werden können. Das alte Dokument wechselt in den Status (DocumentEntry.availabilityStatus) "Deprecated" und wird mit dem neuen Dokument (Status "Approved") über eine "RPLC"-Association verbunden. Der AvailabilityStatus wird beim Dokumente einstellen ausschließlich vom Aktensystem automatisiert gesetzt bzw. geändert. 

Das Aktensystem wirft einen Fehler mit dem Fehlercode XDSDuplicateDocument, wenn versucht wird, ein Dokument in die Akte eines Versicherten hochzuladen, das es dort schon gibt. 

• Ordnerverdoppelung: Dynamische Ordner sollen nicht doppelt angelegt werden, nur weil Leistungserbringer, ohne es überprüft zu haben, davon ausgehen, dass für Schwangerschaften dynamische Ordner noch fehlen.

3.11.2 Dokumente suchen [ITI-18]

Das Suchen nach Dokumenten erfolgt auf den Metadaten des Dokumentes, nicht auf den Inhalten des Dokumentes selbst. Die Suche kann zur Anzeige der Metadaten eines Dokumentes verwendet werden. 

Die Suche erfolgt ausschließlich auf Dokumenten, die für den Leistungserbringer sichtbar sind. 

Zur Suche nach Dokumenten sind u. a. folgende Filterfunktionen möglich:

• kein Filter
• Zeitintervall
• Dokumentenkategorie, darunter auch Dokumentenkategorie 1a (Suche über Ordner)
• Dokumentenquelle (z. B. eine bestimmte Facharztgruppe)
• SubmissionSet-Identifier
• Submission-Zeit.

Für die Suche über beiden Parameter

• $XDSDocumentEntryTitle und
• $XDSDocumentEntryAuthorInstitution

ist eine Ähnlichkeitssuche möglich, wie auch beim Parameter $XDSDocumentEntryAuthorPerson. Diese Ähnlichkeitssuche beruht auf dem SQL-Suchmuster LIKE, in dem mit einer Kombination aus dem SQL-Wildcard-Zeichen "%" und dem SQL-Platzhalterzeichen "_" Suchanfragen zusammengestellt werden, in denen nach einer Kombination aus bestimmten und beliebigen Zeichen gesucht wird.

Zudem können bei Verwendung der folgenden Suchparameter auch auf diese Suchparameter bezogen unscharfe, d. h. leicht abweichende, Suchergebnisse zurückgegeben werden:

• $XDSDocumentEntryTitle
• $XDSDocumentEntryAuthorInstitution
• $XDSDocumentEntryAuthorPerson
• $XDSSubmissionSetAuthorPerson.

Ob und inwieweit unscharfe Ergebnisse für diese Parameter zurückgegeben werden, kann das PS nicht steuern.

Die Umsetzung der Suche von Dokumenten über Metadaten ist in vielfältiger Form möglich, insbesondere als

1. Suchen mittels einer Suchmaske;
2. anlassbezogene Suche ohne Suchmaske, z. B. aus dem UseCase "Benachrichtigung verwalten" heraus.

Je nachdem, ob returnType auf LeafClass oder ObjectRef gesetzt wird, enthält die Response der Suche eine Objektliste im Result (LeafClass) oder eine Liste von Objektidentifiern (ObjectRef), s. [ITI-18#3.18.4.1.2.6].

3.11.2.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente suchen sind:

Vorbedingungen:

• Ausgewählte KVNR
• gültige Befugnis

Auslöser:

• Nutzerinteraktion
• anlassbezogene Suche

Aktivitäten:

• Auswahl der Suchkriterien
• Generierung und Versand der Nachricht
• (optional) Filterung der Ergebnisse
• (optional) Sortierung des Ergebnisses

Resultat:

• Ergebnismeldung
• Dokumenten-UUID-Liste (XDSDocumentEntry_uniqueId)

3.11.2.2 Nutzung

Das Ergebnis der Suche in der Dokumenten-Registry sind Mengen eindeutiger Dokumenten-Identifier als UUID.

Tabelle 12: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen

Durch die Einführung der Folder für jede Kategorie, also auch für solche der Kategorie patient, kann eine Suche mittels FindFolders auf Dokumentenkategorie erfolgen, die in Folder.Codelist angegeben sind. 

Die Metadaten der StoredQuery-Response sind geeignet, dem Nutzer weitere Filtermöglichkeiten zu geben, um die Ergebnismenge der Dokumenten-Anzeige einzuschränken. 

3.11.3 Dokumente laden [ITI-43]

Falls das anzuzeigende Dokument nicht schon mit seiner Dokumenten-ID bekannt ist, und eine Liste vorliegt, SOLL das PS die Auswahl des anzuzeigenden Dokumentes unter Auswertung von Metadaten ermöglichen.

3.11.3.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente laden sind:

Vorbedingungen:

• Auswahl KVNR
• gültige Befugnis
• XDSDocumentEntry_uniqueId (DocumentEntry.uniqueId) bekannt

Auslöser:

• Fachliches Erfordernis
• Nutzerinteraktion

Aktivitäten:

• Auswahl XDSDocumentEntry_uniqueId
• Generierung und Versand der Nachricht
• Dekodierung des empfangenen Dokumentes (Base64 oder XOP)
• Anzeige des angefragten Dokumentes oder der Dokumentenmenge
• Auswertung des Ergebnisses

Resultat:

• Das angefragte Dokument oder die Dokumentenmenge liegt vor und kann in das PS übernommen werden

3.11.3.2 Nutzung

Die RetrieveDocumentSet Request Message muss mindestens eine DocumentUniqueID enthalten.

Das PS soll die DocumentEntry.UniqueID  gemäß [ITI-TF-3#4.2.3.2.26] nicht nur für das Laden von Dokumenten, sondern auch in der Primärakte verwenden. Eine aktenweit eindeutige DocumentEntry.UniqueID ermöglicht dem PS eine zuverlässige Benachrichtigungsverwaltung (s. Kap. 5.3.1 und Kap. 5.2.3).

Ein http-Request im MTOM/XOP - Format (type="application/xop+xml") führt zu einer MTOM-Response.

Im Primärsystem sollte eine Absicherung gegen mögliche Schadsoftware in heruntergeladenen Dokumenten erfolgen.

Geeignet wären insbesondere folgende Maßnahmen:

• Anzeigesoftware in einer Sandbox oder einem Modus betreiben, das die Umgebung der LEI vor einer potentiellen Gefährdung durch das Dokument schützt;
• vor der Anzeige eines Dokumentes Sonder-und Meta-Zeichen im Dokument für die jeweilige Anzeigesoftware mit einer geeigneten Escape-Syntax entschärfen (als Schutz z. B. gegen Injection-Angriffe aus [OWASP Top 10#A1]).
• den Nutzer darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der Nutzer zum Selbstschutz vornehmen kann.

Eine Beispielimplementierung eines Antiviren-Gateways findet sich im Fachportal der gematik. 

3.11.4 Dokumente löschen [ITI-62]

Der Leistungserbringer löscht Dokumente und dynamische Ordner in Absprache mit dem Versicherten.

3.11.4.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente löschen sind:

Vorbedingung:

• Auswahl KVNR
• gültige Befugnis
• Absprache zwischen LE und Versicherten zur Löschung liegt vor
• Die zu löschenden Dokumente innerhalb einer Document-Request-Liste anhand ihrer XDSDocumentEntry.entryUUID

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Auswahl des Dokumentes bzw. der Dokumente unter Verwendung der XDSDocumentEntry.entryUUID
• Sicherheitsabfrage
• Generierung und Versand der Nachricht
• Auswertung des Ergebnisses

Resultat:

• Im Erfolgsfall sollte im PS die UUID gelöscht werden, falls sie zuvor persistent gespeichert wurde.

3.11.4.2 Nutzung

Das Löschen von Ordnern ist nur in einem eingeschränkten Umfang möglich. Das Aktensystem akzeptiert den Lösch-Request nur dann, wenn er auf einen dynamischen Folder abzielt, und wenn dieser Request nicht die im Folder enthaltenen Dokumente, SubmissionSets und Assoziationen enthält. Diese werden vielmehr vom Aktensystem selbst zusammen mit dem Folder Object gelöscht. Falls im dynamischen Ordner, der gelöscht werden soll, Dokumente vorliegen, muss daher zuvor eine Absprache mit dem Versicherten stattgefunden haben, da eine Löschung von Dokumenten immer in Absprache mit dem Versicherten stattfinden soll.

3.11.5 Aktualisieren von Metadaten [ITI-92]

Bei Dokumenten, bei denen Metadaten fehlen oder falsch sind, sollte das Primärsystem die korrekten Metadaten hinzuzufügen oder korrigieren können. Dazu dient die Schnittstelle updateDocumentSet. In der Operation können sowohl eigene, als auch durch Dritte eingestellte Dokument-Metadaten bearbeitet werden, soweit es die Berechtigung des Nutzers erlaubt. Ein Herunterladen des Dokumentes, auf die sich die Metadaten beziehen, ist zum Editieren der Metadaten nicht erforderlich.

3.11.5.1 Umsetzung

Die Aktivitäten des Anwendungsfalles Aktualisieren von Metadaten sind:

Vorbedingungen:

• Auswahl KVNR
• gültige Befugnis
• Notwendigkeit, die Metadaten zu aktualisieren, liegt vor
• Die zu aktualisierenden Dokumente innerhalb einer Document-Request-Liste liegen vor anhand ihrer XDSDocumentEntry.entryUUID

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Auswahl des Dokumentes bzw. der Dokumente unter Verwendung der XDSDocumentEntry.entryUUID
• Generierung und Versand der Nachricht

Resultat:

• Im Erfolgsfall sollten auch im PS die Metadaten in der aktuellen Form gespeichert sein, falls sie zuvor persistent gespeichert wurden.

3.11.5.2 Nutzung

3.11.6 Artefakte

3.11.6.1 Namensräume

Tabelle 13: Tab_ILF_ePA_Namensräume

3.11.6.2 WSDLs und Schemata

Die normativen WSDLs und Schemata der ePA werden von der gematik zur Verfügung gestellt.

Für den Fall, dass es sich dabei um IHE-Artefakte handelt, gilt, dass diese Artefakte denjenigen entsprechen, die von IHE im entsprechenden Zeitraum bereitstellt. 

3.11.7 Testunterstützung

Zur Unterstützung von Tests im Zusammenhang mit den oben geschilderten Funktionsmerkmalen dürfen keine Echtdaten verwendet werden.

3.12 Informationsmodell

3.12.1 Metadaten

Einstellen von Dokumenten

Auf die Auszeichnung von in die ePA einzustellenden Dokumenten durch Metadaten kann das PS spezifische Einschränkungen und Vorbelegungen umsetzen:

• abhängig vom Nutzungskontext bzw. Anwendungsfall;
• gemäß sektorspezifischen Besonderheiten;
• je nach LE-spezifischen Besonderheiten und Konfigurationen, etwa in Zusammenhang mit der Selbstauskunft der Leistungserbringer.

Wenn Leistungserbringer Dokumente einstellen, bei denen sie nicht selbst der Autor sind, kann es passieren, dass die Telematik-ID des ursprünglichen Dokumenten-Autors nicht in DocumentEntry.author.authorInstitution angegeben wurde. Ein Herunterladen und eine Weiterverarbeitung solcher Dokumente soll möglich sein, auch wenn eine strenge Validierung des Metadatums aufgrund der fehlenden Telematik-ID nicht erfolgreich sein sollte.

Auslesen von Dokumenten

Insoweit Metadaten zur Anzeige gebracht werden, muss das PS die Anzeigenamen der Metadaten in eine lesbare Form bringen. Die Anzeige von Metadaten ist insbesondere zu dem Zwecke des Filterns großer Ergebnismengen erforderlich sowie zur Auswahl der gegebenenfalls herunterzuladenden Dokumente. Zum Filtern über Dokumentenmengen kann es nützlich sein, nicht nur Metadaten der DocumentEntries, sondern auch Metadaten der SubmissionSets anzuzeigen, um ein Ausblenden bestimmter Suchergebnisse zu ermöglichen.

3.12.2 Strukturierte Dokumente

In der ePA können strukturierte Dokumente verarbeitet werden. Strukturierte Dokumente und deren Zuordnung zu Sammlung und Sammlungstypen sind in [gemSpec_IG_ePA] und in [gemSpec_Aktensystem_ePAfuerAlle] beschrieben.

3.12.2.1 Medizinische Informationsobjekte

Zum Laden, Suchen und Einstellen von strukturierten Dokumenten gelten die Anwendungsfälle zum Laden, Suchen, Einstellen und Löschen von Dokumenten. Besteht der Bedarf nach mehreren Sammlungen des gleichen Typs in den dynamischen Ordnern pregnancy_childbirth, so wird jeweils ein dynamischer Ordner (je Schwangerschaft) angelegt. Beim erstmaligen Erstellen einer dynamischen Sammlung muss vom Primärsystem für diese Sammlung ein Ordner angelegt werden.

Mit ePA 3 gibt es keine dynamischen Ordner für Kinder in der Akte eines Elternteils mehr. Die Nutzung von dynamischen Ordnern für Kinder, wie sie in 2.6 noch möglich war, wird ab ePA 3.0 mit einem Fehler abgewiesen. Daten von Kindern sollen mit ePA 3 in den Akten der Kinder verarbeitet werden.

3.12.2.2 NFD, DPE und eMP

Ein Notfalldatensatz (NFD) oder ein Datensatz persönliche Erklärungen (DPE), der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_NFDM] von der eGK gelesen, vgl. auch [gemSpec_InfoNFDM]. Analog wird der elektronischen Medikationsplan (eMP) gemäß [gemILF_PS_AMTS] und [gemSpec_Info_AMTS] von der eGK gelesen und in der ePA verarbeitet. Die Einwilligung in die Nutzung des eMP wird nicht in der ePA gespeichert.

NFD, DPE und eMP werden im Base64-Format gespeichert. Die Datensätze werden so, wie sie aus der eGK ausgelesen werden, in das Element <xds:Document> eingefügt, das ein Attribut @id enthält, das mit dem rim:ExtrinsicObject/@id übereinstimmt.

3.12.2.3 Arztbrief nach § 383 SGB V

Falls ein Arztbrief im Format als HL7 CDA R2-Dokument vorliegt, ohne dass der Arztbrief eine PDF-Darstellung hat, soll er direkt im Format  mimeType = application/xml in der Dokumentenverwaltung der ePA verwaltet werden. Ein Arztbrief, der als reines PDF-Dokument in die ePA eingestellt werden soll, soll direkt im Format  mimeType = application/pdf  in der Dokumentenverwaltung der ePA verwaltet werden.

Der Arztbrief nach § 383 SGB V hat gemäß [Richtlinie eArztbrief] die verpflichtenden Teile PDF-Dokument und CDA-XML (nur der CDA-Header ist verpflichtend).  Um diesen Arztbrief in die ePA einzustellen und wieder auszulesen, wird auf das XML-Containerformat DischargeLetterContainer (s. Abb_ILF_ePA_eAB-XML-Containerformat) zurückgegriffen. 

Abbildung 7: Abb_ILF_ePA_eAB-XML-Containerformat

Die folgende XML-Struktur für einen Container mit Arztbrief nach § 383 SGB V wird festgelegt:

Tabelle 15: XML-Struktur für Arztbrief nach § 291f SGB V

3.12.3 Selbstauskunft

Die Telematik-ID der Leistungserbringerinstitution muss in vielen Nachrichten angegeben werden. Sie sollte aus der SMC-B ausgelesen werden und im PS persistent gespeichert werden.

Die Telematik-ID ist von den Kartenherausgebern der SM-B festgelegt und immer im Attribut "registrationNumber" im Admission-Element der Extension der SMC-B-Zertifikate (C.HCI.AUT, C.HCI.ENC,C.HCI.OSIG) eingetragen. Wenn nicht explizit vom Antragsteller eine neue Telematik-ID angefordert wird, wird bei Ausgabe von Folge- und Ersatzkarten die bisherige Telematik-ID wiederverwendet. Eine generelle Vorgehensweise kann die gematik hierfür nicht geben, da die Personalisierung der SMC-B sektoral unterschiedlich ist (siehe [gemSpec_PKI#Anhang A]). Zum Auslesen der Zertifikate kann die Operation ReadCardCertificate gemäß [gemSpec_Kon#4.1.9.5.2] verwendet werden. Die Telematik-ID ist in allen Zertifikaten in der Admissionstruktur als "registrationNumber" im ASN.1-Format gespeichert. 

3.12.4 Signieren von Dokumenten

Ob eine Signatur und welche Art der Signatur (QES oder nonQES) erforderlich ist, wird durch den Anwendungsfall für das jeweilige Dokumentenformat festgelegt und außerhalb dieser Spezifikation veröffentlicht.

Im Folgenden wird das Vorgehen für den Fall, dass ein Medizinisches Informationsobjekt signiert wird, beschrieben.

Im Primärsystem liegt ein strukturiertes Dokumentenformat der ePA als FHIR-XML-Darstellung oder FHIR-JSON-Darstellung vor. Im Sinne der Signaturerstellung wird dies als Data to be Signed (DTBS) bezeichnet.

Vor dem Einstellen des Dokuments wird dieses elektronisch signiert (QES oder nonQES). Das Primärsystem nutzt dafür die Schnittstelle des Konnektors und dieser den HBA für QES bzw. SM-B für nonQES des einstellenden LE. 

Bei der Signaturerstellung ist folgender Ablauf im Primärsystem erforderlich:

1. Das Primärsystem stellt fachliche DTBS zusammen.
2. Das Primärsystem serialisiert die Daten zu einer Data to be Signed Representation (DTBSR).
3. Das Primärsystem übermittelt DTBSR an den Konnektor zur Signaturerstellung (Aufruf der Operation SignDocument gemäß [gemILF_PS]).
4. Der Konnektor erzeugt eine CADES Enveloping Signatur.
5. Das signierte Objekt enthält sowohl die Signatur als auch die ursprünglichen DTBSR bitgenau und in einem binären ASN.1 Format (PKCS#7).
6. Der Konnektor übermittelt das signierte Objekt an das Primärsystem.
7. Das Primärsystem stellt über das Funktionsmerkmal "Dokumente einstellen" das signierte Objekt als DocumentEntry im ePA-Aktensystem im PKCS#7-Format ein.

Bei der Signaturprüfung ist folgender Ablauf im Primärsystem erforderlich:

1. Das Primärsystem lädt Dokument aus dem ePA-Aktensystem.
2. Das Primärsystem erkennt, dass es sich dabei um ein medizinisches Objekt im Format im PKCS#7 handelt (DocumentEntry.mimetype = application/pkcs7-mime).
3. Das Primärsystem übermittelt das signierte Objekt an den Konnektor zur Signaturprüfung (Aufruf der Operation VerifyDocument [gemILF_PS]).
4. Der Konnektor prüft die Signatur.
5. Der Konnektor übermittelt das Prüfergebnis an das Primärsystem.
6. Bei erfolgreicher Signaturprüfung verarbeitet das Primärsystem die fachlichen Daten entsprechend dem formatCode weiter. Hierzu parst das Primärsystem die binäre ASN.1-Struktur der Daten im PKCS#7-Format und trennt die Fachdaten von den restlichen Daten ab.

4 Spezielle Nutzungsumgebungen

Nutzerumgebungen werden grundlegend durch [gemSpec_Aktensystem_ePAfuerAlle#A_19303-*] in ihren Zugriffsrechten auf Dokumente des Versicherten in der ePA für alle eingeschränkt.

4.1 Funktionsumfang Clientsystem des Kostenträgers

Der Kostenträger stellt für Versicherte Dokumente in ihr Aktenkonto. Das sind:

• Abrechnungsdaten,
  
• Bis zu zehn digitalisierte Papierdokumente, die der Versicherte ohne FdV seiner Krankenkasse übergeben hat,
• elektronische Arbeitsunfähigkeitsbescheinigungen.

Somit muss das Clientsystem des Kostenträgers das Einstellen von Dokumente des XDS Document Service umsetzen.

Des Weiteren übernimmt das Clientsystem des Kostenträgers Aufgaben im Rahmen eines betreiberübergreifenden Aktenumzugs. Damit unterscheidet sich der Funktionsumfang des Clientsystems des Kostenträgers wesentlich vom Funktionsumfang des Primärsystems einer Leistungserbringerinstitution. Der Kostenträger wird dabei durch die SMC-B des Kostenträgers repräsentiert. Der Kostenträger ist grundsätzlich befugt, schreibend auf die Akten der Versicherten zuzugreifen, das individuelle Befugen durch Lesen der Versichertenkarte entfällt. Ein lesender Zugriff ist nicht möglich.

Im Folgenden wird der spezifische Funktionsumfang beschrieben und die Anforderungen genannt, die sich nur auf das Primärsystem des Kostenträgers beziehen.

4.1.1 Einstellen von Daten durch Kostenträger

4.1.2 Ablauf eines betreiberübergreifenden Aktenumzugs (informativ)

Abbildung 8 : Ablauf eines betreiberübergreifenden Aktenumzugs

Anstoßen eines Aktentransfers
Der Kostenträger (neu) lässt im Aktensystem eine neue Akte anlegen (1). Das Aktensystem fragt am Information Service der anderen Aktensysteme ab, ob für diese KVNR schon eine Akte existiert (2). Sollte dies der Fall sein, wird der Anbieterwechsel angestossen. In dieser Kommunikation wird auch das Verschlüsselungszertifikat des neuen Betreibers ausgetauscht.

Dafür informiert der Information Service des alten Aktensystems den Kostenträger (alt) über den Wechsel (3). Der Kostenträger (alt) meldet sich an der ePA an, startet die Erstellung eines Export-Pakets im Health Record Relocation Service und übergibt dabei das Verschlüsselungszertifikat (4). Der Service ändert den Status der Akte auf SUSPENDED und baut das Export-Paket. Das Export-Paket wird mit dem Verschlüsselungszertifikat für die VAU des neuen Betreibers verschlüsselt (5).

Das verschlüsselte Export-Paket wird nun auf dem Download-Punkt des alten Aktensystems abgelegt und die entsprechende Download-URL dem Kostenträger (alt) bekannt gemacht. Dieser übermittelt die Download-URL an den Information Service seines Aktensystems, welches diese an den Information Service des neuen Aktensystems übergibt, welches die URL mit der Information, dass ein Anbieterwechsel ansteht, an den Kostenträger (neu) weiterleitet (6).

Import einer Akte
Der Kostenträger (neu) meldet sich an der ePA an und startet am Health Record Relocation Service den Import der Akte (7). Nachdem der Health Record Relocation Service das Export-Paket abgerufen (8) und entschlüsselt hat, werden die Daten in die entsprechenden Services importiert und die Akte ist beim neuen Anbieter nutzbar und deren Status wechselt auf ACTIVATED (9).

4.1.3 Erstellung des Exportpakets auf Seiten des alten Kostenträgers

Der Information Service des Aktensystems informiert das Clientsystem des Kostenträgers über den anstehenden Aktenumzug und gibt dabei die die KVNR des umzuziehenden Aktenkontos, das Verschlüsselungs-Zertifikat des Ziel-Aktensystems und eine RequestID mit. Das Format dieser Information wird nicht von der gematik vorgegeben und ist betreiberspezifisch. Die RequestID stammt vom Information Service des neuen Kostenträgers und identifiziert die Abfolge der Aufrufe und Antworten im Rahmen eines Aktenumzugs als zusammengehörig.

Getriggert durch diese Information loggt sich das Clientsystem des Kostenträges in das Aktenkonto ein und startet die Herstellung des Exportspakets unter Verwendung des erhaltenen Verschlüsselungszertifikats.

Dazu nutzt es diese Operation des Health Record Relocation Service des Aktensystems:

Tabelle 18: I_Health_Record_Relocation_Service::startPackageCreation

Die startPackageCreation-Response enthält die Download-URL des Export-Pakets. Diese Download-URL muss das Clientsystem an den Information Service des Aktensystems senden. Das Format dieser Nachricht wird nicht von der gematik vorgegeben und ist betreiberspezifisch.

4.1.4 Einspielen des Exportpakets auf Seiten des neuen Kostenträgers

Der Information Service des neuen Aktensystems informiert das Clientystem des neuen Kostenträgers, dass der Import des Exportpakets beginnen kann und gibt dabei die Download-URL mit. Das Format dieser Information wird nicht von der gematik vorgegeben und ist betreiberspezifisch.

Getriggert durch diese Information loggt sich das Clientsystem des Kostenträges in das Aktenkonto ein und startet den Import des Exportpakets.

Dazu nutzt es diese Operation des Health Record Relocation Service des Aktensystems:

Tabelle 19: I_Health_Record_Relocation_Service::startPackageImport

4.1.5 Verhalten bei Scheitern des Imports

Falls der Import des Exportpakets im neuen Aktensystem scheitert, erhält das Clientsystem des alten Kostenträgers diese Information vom Information Service des alten Aktensystems.

Das Clientsystem muss daraufhin den Health Record Relocation Service auffordern, den Status des Aktenkontos von SUSPENDED zurück auf ACTIVATED zu setzen.

Das Format dieser Aktionen wird nicht von der gematik vorgegeben und ist betreiberspezifisch.

4.2 Funktionsumfang Clientsystem der Ombudsstelle

Die vom Kostenträger eingerichtete Ombudsstelle ermöglicht es Versicherten, die über kein FdV verfügen, sonst nur über das FdV nutzbare Funktionalitäten ihres Aktenkontos zu nutzen. Das sind:

• für spezifische LEI das Erstellen einer Befugnis ausschließen und dieses wieder rückgängig machen,
• Widerspruch gegen den Medikationsprozess aussprechen und diesen zu widerrufen,
• Protokolldaten aus dem Aktenkonto herunterladen.

Diese Funktionen werden aus dem Clientsystem der Ombudsstelle heraus getriggert, dessen Funktionsumfang sich damit wesentlich vom Funktionsumfang des Primärsystems einer Leistungserbringerinstitution unterscheidet. Die Ombudsstelle wird dabei duch die SMC-B der Ombudsstelle repräsentiert. Die Ombudsstelle ist grundsätzlich befugt, auf die Akten der Versicherten zuzugreifen, das individuelle Befugen durch Lesen der Versichertenkarte entfällt.

Im Folgenden wird der spezifische Funktionsumfang beschrieben und die Anforderungen genannt, die sich nur auf das Clientsystem der Ombudsstelle beziehen.

Zum Funktionsumfang des Clientsystems der Ombudsstelle gehört nicht die Verarbeitung von Dokumenten. Somit muss der XDS Document Service nicht umgesetzt werden.

4.2.1 Spezifische LEI für die Nutzung eines Aktenkontos sperren

Um für einen Versicherten eine bestimmte LEI für den Zugriff auf das Aktenkonto zu sperren, muss das Clientsystem der Ombudsstelle zunächst die Telematik-ID und ProfessionID der zu sperrenden LEI ermitteln. Dazu sind die Suchmöglichkeiten des VZD-FHIR-Directory der TI zu nutzen.

Informationen zu Leistungserbringerinstitutionen sind im Verzeichnisdienst FHIR-Directory (VZD-FHIR-Directory) der TI-Plattform hinterlegt. Der Nutzer kann mit verschiedenen Kriterien nach Leistungserbringerinstitutionen im VZD-FHIR-Directory suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD_FHIR_Directory#4.1.1 Datenmodell] beschrieben.

Die Suche nach LEI erfolgt primär über den Namen oder Institutionsnamen, aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.

Für die Umsetzung der Suche siehe [gemSpec_ePA_FdV#6.3.3.6].

Für die Sperrung nutzt das Clientsystem der Ombudsstelle folgende Operation:

Tabelle 20: I_Entitlement_Management::setBlockedUserPolicyAssignment

Um eine Sperrung aufzuheben, benutzt das Clientsystem der Ombudsstelle folgende Operation:

Tabelle 21: I_Entitlement_Management::deleteBlockedUserPolicyAssignment

Um alle gesperrten LEI zu ermitteln, nutzt das Clientsystem folgende Operation:

Tabelle 22: I_Entitlement_Management::getBlockedUserPolicyAssignment

4.2.2 Widerspruch gegen den Medikationsprozess einstellen oder widerrufen

Das Clientsystem der Ombudsstelle nutzt das Consent Decision Management des Aktensystems, um für einen Versicherten einen Einspruch gegen die Teilnahme am Medikationsprozess einzustellen oder diesem wieder zuzustimmen. Dazu wird folgende Operation genutzt:

Tabelle 23: I_Consent_Decision_Management::updateConsentDecision

Um den Zustand eines Widerspruchs festzustellen, benutzt das Clientsystem folgende Operation:

Tabelle 24: I_Consent_Decision_Management::getConsentDecision

4.2.3 Protokolldaten dem Versicherten zur Verfügung stellen

Versicherte ohne ePA-FdV können bei ihrer zuständigen Ombudsstelle beantragen, die Protokolldaten zur Verfügung gestellt zu bekommen. Für den Abruf der Protokolldaten aus dem Aktenkonto des Versicherten nutzt das Clientsystem der Ombudsstelle die Schnittstelle Audit Event Service des Aktensystems. Bei den Audit Events handelt es sich um eine FHIR-Ressource gemäß der FHIR-Profilierung [gemSpec_EPAAuditEvent].

Die Anfrage des Client-Systems enthält eine FHIR-Suche, bei der über verschiedene Suchparameter das Suchergebnis eingeschränkt wird. Die Response enthält ein Bundle mit den Suchergebnissen der passenden Audit Events.

Es wird folgende Operation genutzt:

Tabelle 25: I_Audit_Event_Service

5 Ergänzende Funktionalitäten

5.1 Betriebs- und Performancedaten

Das PS versendet Messdaten zur Userexperience (UX-Messdaten) der in Tab_UX_KPI_Messung_ePA_PS aufgeführten erfolgreich abgeschlossenen Anwendungsfälle an das Aktensystem, bei dem ein Aktenzugriff erfolgte.

Tabelle 26: I_Information_Service::setUserExperienceResult

Hinweis: "Im Hintergrund" bedeutet, dass die Übermittlung einerseits automatisch (ohne Nutzerinteraktion) geschieht und andererseits für den Nutzer auch keine "Wartezeit" entsteht.

5.2 Übertragungsprotokolle speichern

Das PS benutzt "Übertragungsprotokolle", um insbesondere die vorgeschriebenen Nachweispflichten von Leistungserbringern bei der Übertragung von Dokumenten zwischen PS und Aktensystem zu erfüllen, bei denen Patientendaten betroffen sind. Das Erstellen, Speichern, durchsuchbar Machen und Anzeigen der Übertragungsprotokolle zwischen PS und Aktensystem ist eine Aufgabe des PS, die nicht durch Komponenten der TI abgedeckt wird. Die Übertragungsprotokolle geben Auskunft über die Aktivität des PS bei der Nutzung der Akte, nicht aber über die Datenverarbeitung im Aktensystem des Versicherten.

Das Format der Speicherung und die Schnittstellen zu den Übertragungsprotokollen können herstellerspezifisch sein. Das PS kann zum Speichern Record Audit Event [ITI-20] verwenden, und darauf aufbauende Filtermechanismen zur Anzeige der Übertragungsprotokolle verwenden.

Durch das Loggen der SOAP-Parameter aus Tab_ILF_ePA_ClientInformationen bei Dokumentenmanagementzugriffen werden für das Einsehen von Übertragungsprotokollen erforderliche Zugriffsinformationen bereit gestellt.

Details zur Nutzung der Übertragungsprotokolle obliegen dem PS.

5.3 Empfehlung zur Archivierung

Auf der Grundlage gesetzlicher Regelungen besteht eine Archivierungspflicht für die medizinischen Dokumente und für die Übertragungsprotokolle des Versicherten. Die Archivierung ist korrekt, verständlich, vollständig, nachvollziehbar und zeitnah durchzuführen. Je nach gesetzlicher Regelung sind damit dokumentierte Inhalte mit Aufbewahrungszeiträumen verbunden. 

Zur Aufbewahrungsfrist wird auf die jeweils aktuelle Fassung der „Empfehlungen zur ärztlichen Schweigepflicht, Datenschutz und Datenverarbeitung in der Arztpraxis“ der BÄK und KBV, siehe [BÄK_KBV], und auf die einschlägigen gesetzlichen Normen 
verwiesen.  
Im Umfang der Archivierung sollen zusätzlich zu den aus der ePA heruntergeladenen und persistent im PS gespeicherten ePA-Dokumenten des Versicherten auch die zu diesen Dokumenten gehörigen Metadaten enthalten sein, die in [gemSpec_Aktensystem_ePAfuerAlle#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] aufgelistet sind, soweit sie für den Verarbeitungskontext relevant sind.

6 Fehlerbehandlung

6.1 Fehlermeldungen der REST-Schnittstellen

Für jede REST-Schnittstelle sind in der OpenAPI die möglichen Fehlersituationen beschrieben. In dieser Tabelle sind alle Fehlermeldungen zusammen gefasst:

Tabelle 28: Tab_ILF_ePA- Übersicht der REST-Fehlermeldungen

Bei den FHIR-Schnittstellen werden die Fehlermeldungen mit einem Operation Outcome gemäß https://hl7.org/fhir/R4/operationoutcome.html  gebildet.

6.1.1 Fehlerbehandlung im XDS Document Service

Auftretende Fehlertypen unterscheiden sich je nach Architekturebene:

• gematik-SOAP-Faults bei Fehlern auf Transportebene mit TelematikError auf Anwendungsebene außerhalb des Dokumentenmanagements:
• Fehler bei Abbruch der Verarbeitung
• Error-Elemente als Teil der Status-Elemente bei abgeschlossener Verarbeitung
• Fehler auf Ebene des Dokumentenmanagements und der Aktenermittlung.

Tabelle 29: Tab_ILF_ePA_DifferenzFehlerhandling

Der Stacktrace der Fehler wird nicht an das PS weitergegeben.

6.1.2 TelematikError

Im Falle von Nicht-IHE-Fehlern erhält das PS einen Fehler gemäß [gemSpec_OM#3.2.3], das ein einzelnes GERROR:Trace-Element enthält, das in der GERROR-Struktur im Element GERROR:Trace einen von der gematik spezifizierten Fehler enthält. 

Es gibt keinen Fehlertrace bei SOAP-Fehlern. Die Fehlerbehandlung durch das PS muss auf Basis der Fehlerstruktur erfolgen. Herstellerspezifische ePA-SOAP-Fehler sind nicht zulässig. Anforderungen an das PS zum Fehlerhandling bei SOAP-Fehlern finden sich in [gemILF_PS#6].

Daneben kann es Fehler des Basiskonnektors geben gemäß [gemSpec_Kon].

6.1.3 IHE-Error

In der Response der IHE-Schnittstellen-Aufrufe können [ITI-TF-3#Table 4.2.4.1-2]: Error Codes auftreten, die drei ResponseStatusType aufweisen können.

Das Vorhandensein einer Error-List ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Falls die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), kann die Verarbeitung als erfolgreich angesehen werden.

Fehler aus Aufrufen des Dokumentenmanagements haben das in [ITI TF Vol 3#4.2.4] "Success and Error Reporting" beschriebene Format. Es wird im Fehlerfall ggf. eine Fehlerliste (RegistryErrorList) und darin Fehler (RegistryError) mit den Attributen errorCode, errorContext, codeContext und severity zurückgegeben. 

Für die Analyse der Fehlerquelle enthält insbesondere auch der codeContext hilfreiche Informationen, um den Nutzer über die Ursache des Fehlers hinzuweisen und daraus Handlungen abzuleiten, mit denen die Ursache des Fehlers behoben wird.

Bei IHE-Operationen stellt der in Im rs:RegistryResponse/@status Attribut den Verarbeitungsstatus der Anfrage dar:

Tabelle 30: Tab_ILF_ePA_IHE_Success_and_Error_Reporting

6.1.4 Fehlermeldungen aus dem XDS Document Service

Das Aktensystem kann mindestens die Fehler der Tabelle Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem werfen, die an das PS durchgereicht werden.

Tabelle 31: Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

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

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

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

7.5.2 Weitere Dokumente

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

Die in [gemSpec_Voc_ePA] vorgegebenen Value Sets beinhalten in der Regel eine hohe Anzahl von Werten, die nicht für jeden Sektor oder jede Berufsgruppe gleichermaßen relevant sind. Um dem Anwender die Nutzung zu erleichtern, wird für die Auswahl der Werte die Anzeige einer gefilterten Ansicht der Tabellen empfohlen.

Hinweis: Neue Nutzergruppen, die im Folgenden noch nicht berücksichtigt sind, sollten sich nach Vorbild der vorliegenden Vorschläge eine verkürzte Ansicht bilden. Neue Nutzergruppen werden schrittweise auch explizit Berücksichtigung finden.

Tabelle 32: Value Set authorRole

Tabelle 33: Value Set authorSpecialty