gemILF_PS_ePA_V2.52.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme -

Elektronische Patientenakte (ePA)

    

     

      
Version
      
2.52.0
     
     

      
Revision
      
784617
     
     

      
Stand
      
31.03.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
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ärsystems, die zur Nutzung der elektronischen Patientenakte 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 aus der Sicht der PS-Hersteller erläutert. Dabei werden nicht nur Anwendungsfälle der ePA erläutert, sondern auch praktische Umsetzungshinweise sowie Beispiele gegeben.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Hersteller von Primärsystemen, welche die Fachmodul-ePA-Schnittstelle des Konnektors 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 Gegenstandsbereiche.

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. Dokumentenlandkarte, 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_DM_ePA] 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

Einem Leistungserbringer als Nutzer seines Primärsystems bietet ein ePA-fähiger Konnektor den Zugang zur elektronischen Patientenakte des gesetzlich Versicherten an. Leistungserbringer und Primärsystem greifen in der ConsumerZone der TI primär auf die lokalen bzw. dezentralen TI-Komponenten der LE-Institution zu. Zugriffe auf elektronische Patientenakten erfolgen ausschließlich gekapselt über den Konnektor.

Zu diesem Zweck nutzt das Primärsystem IHE-Schnittstellen, die das Fachmodul ePA des Konnektors bereitstellt.  
Eine Übersicht über die Fachanwendung ePA im Ganzen liefert [gemSysL_ePA]. Einen Überblick über die ePA-Profilierung des Frameworks von IHE (Integrating the Healthcare Enterprise) liefert [gemSpec_Dokumentenverwaltung].

Wenn von der "Akte" 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.

2.1 Relevante Integrationsprofile

Für das aktennutzende PS sind mehrere IHE-Integrationsprofile für das Primärsystem relevant:

Tabelle 1: Tab_ILF_ePA_IHE-TransaktionenProfile

3 Systemkontext

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 Berechtigungsvergabe 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 mit dem Fachmodul ePA, welches die Kommunikation mit dem ePA-Aktensystem ermöglicht.  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], [gemILF_PS_NFDM] und [gemILF_PS_AMTS] beschrieben sind.

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

3.2 Nachbarsysteme

Leistungserbringer erhalten über ihr ePA-fähiges Primärsystem Zugriff auf die ePA des Versicherten ausschließlich über den Konnektor. Der Konnektor macht zusätzlich die zentralen und dezentralen Komponenten der TI für das PS zugänglich, für Details siehe die Übersicht in [gemKPT_Arch_TIP]. Weitere Nachbarsysteme oder an das PS angebundene Softwaremodule werden in diesem Dokument nicht betrachtet.

Das vorliegende Dokument bezieht sich mit den referenzierten Konnektorschnittstellen auf den Leistungsumfang der ePA-Komponenten, die in der dazugehörigen Dokumentenlandkarte aufgelistet sind. Die hier beschriebene Funktionalität wird als ePA Stufe 2 (und höher) beschrieben, um zu kennzeichnen, dass die vorliegenden Primärsystemschnittstellen der ePA einige nur beschränkt abwärtskompatible Änderungen zur ePA-Stufe 1 enthält. Das betrifft insbesondere die Erteilung von Berechtigungen. In ePA 1 erstellte Berechtigungen werden vom Aktensystem in Berechtigungen für ePA 2.x transformiert. ePA 2.x - Berechtigungen können jedoch nicht in ePA 1 - Berechtigungen zurück transformiert werden. Das Upgrade von ePA 1 auf ePA 2.x kann nicht rückgängig gemacht werden. In einer früheren Version des vorliegenden Dokumentes ist die Nutzung der ePA Stufe 1 beschrieben, zuletzt für das Release 3.1.3.

Das Upgrade des Primärsystems auf Stufe 2.x ist abhängig von der Verfügbarkeit des ePA 2.x - Konnektorfachmoduls im Konnektor des Leistungserbringers. Falls der PS-Hersteller die Verfügbarkeit des Konnektor PTV5 (mit der ePA 2 - Funktionalität) bei den Leistungserbringern nicht durchgängig sicher stellen kann, kann es für das Ausrollen des ePA 2 - Primärsystems erforderlich sein, die Schnittstellenversion des Konnektors über den Dienstverzeichnisdienst zu ermitteln und die Inbetriebnahme des ePA 2 - Upgrades vom Vorliegen der passenden Schnittstellenversion im Dienstverzeichnisdienst abhängig zu machen (PHRService V2.x und PHRServiceManagement V2.x sind erreichbar). Dieses Feature ("Dualmode" des Primärsystems) unterstützt die Migration von ePA 1 nach ePA 2.x und darf nicht dazu verwendet werden zwischen den Interfaces von ePA 1 und ePA 2.x beliebig zu wechseln. Dies würde dazu führen, dass bei manchen PS-Installation ePA 1 genutzt wird, bei anderen ePA 2.x, je nach Version des Konnektors in der konkreten LE-Institution. Dieser "Dualmode" erlaubt PS-Herstellern ein einheitliches Release-Management für unterschiedliche Praxiskonstellationen im Migrationszeitraum der ePA Stufe 1 auf die ePA Stufe 2.x. 

4 Übergreifende Festlegungen

Das Primärsystem verarbeitet die primäre Behandlungsdokumentation der Versicherten. Die ePA ist ein potentiell lebenslanger Speicherort für eine sekundäre Behandlungsdokumentation der Versicherten.

Die Anbindung und Nutzung dezentraler TI-Komponenten, die in [gemILF_PS] beschrieben wird, ermöglicht unter anderem den Aufbau von Kartensitzungen, die an verschiedenen Stellen vorausgesetzt werden, insbesondere zur Nutzung der eGK des Versicherten.

Das Fachmodul ePA wird vom Konnektor ab Produkttyp Version 4 (PTV4) zur Verfügung gestellt.

Die Inbetriebnahme des Konnektors in die LE-Umgebung [gemILF_PS#4.1] und die Unterstützung des VSDM durch das PS für eine Gültigkeitsprüfung der eGK [gemILF_PS#4.3] MUSS erfolgt sein, um die ePA nutzen zu können.

Für die Anwendungsfälle der ePA MUSS eine SM-B in PS und Konnektor verwaltet werden und freigeschaltet sein [gemILF_PS#4.2.3]. Das PIN-Handling von eGK und SM-B wird in [gemILF_PS#4.1.5] beschrieben. 

Das PS muss eine Arbeitsplatz-Konfiguration in der LE-Institution ermöglichen, in der Versicherte auf ein Kartenterminal zugreifen können, in dem sie ihre eGK freischalten können. Dazu gehört ein KT, dessen PIN-Pad dem Versicherten zur Eingabe seiner PIN.CH zugänglich ist. Die Konfiguration eines Arbeitsplatzes, an dem ein Kartenterminal für den Versicherten zur PIN-Eingabe zugänglich ist, insbesondere am Empfangstresen, wird in [gemILF_PS#9.1] beschrieben. 

4.1 Webservice-Kommunikation

Die Webservice-Konnektorschnittstellen werden nachrichtenbasiert angesprochen über

• SOAP1.1 mit [BasicProfile1.2] für Webservices der Konnektor-Basisdienste und anderer Fachmodule und 
• SOAP1.2 mit [BasicProfile2.0] für Webservices des Fachmoduls ePA.

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 Aufruf- und Aktenkontext zu erhalten (s. Kap. 4.4).

4.2 Dienstverzeichnisdienst

Das PS soll auch mit Konnektoren kompatibel sein, die eine Produkttypversion kleiner als PTV4 nutzen. Der PS-Hersteller kann es erreichen, dass sein Primärsystem mit Konnektoren unterschiedlicher Produkttypversion zusammenarbeitet, um darauf vorbereitet zu sein, dass seine Kunden Konnektoren älterer Produkttypversionen (kleiner PTV4) nutzen, indem er die Versionsinformationen des Dienstverzeichnisdienstes beachtet:

• Der Dienstverzeichnisdienst stellt dem PS die Information zur Verfügung, ob der Konnektor ePA-Dienste anbietet. Wenn kein ePA-Webservice angeboten wird, SOLL das PS die ePA-Funktionsmerkmale an der Nutzeroberfläche nicht zur Verfügung stellen. 
• Der Dienstverzeichnisdienst stellt ihm die Information, in welcher Version der Konnektor seine Webservices anbietet, als eine dreistellige Versionsnummer mit Hauptversionsnummer (1. Stelle), Nebenversionsnummer (2. Stelle) und einer Revisionsnummer (3. Stelle) zur Verfügung. 

Es kann vorkommen, dass PS und Konnektor vom selben Webservice unterschiedliche Dienstversionsnummern unterstützen. Der Umgang mit Abweichungen zwischen produktiven PS und Konnektor in Bezug auf unterstützte Dienstversionen wird in [gemILF_PS#4.1.2] beschrieben. 

4.3 Ereignisdienst/Systeminformationsdienst

Falls das PS den Eventservice des Konnektors abonniert, kann es Komfortfunktionen der Kartenverwaltung wie Benachrichtigungen über gesteckte und gezogene Karten und Informationen über den Betriebszustand des Konnektors nutzen.

4.4 Zugriffssteuerung

Der ePA-Client übergibt je nach Signatur der Operation eines ePA-Webservices Informationen über

1. sich selbst (bzw. den Arbeitsplatz, von dem aus der Clientaufruf erfolgt) in den Context-Parametern (im SOAP-Header oder im SOAP-Request) sowie
2. Identifikatoren zur Akte des Versicherten.

Viele Funktionsmerkmale erfordern die Kenntnis des Status der Zugriffsberechtigung auf die ePA eines Versicherten, um

• nicht auf unnötige Fehler zu laufen (insbesondere bei Operationen des Dokumentenmanagements) und
• Aufrufe vollständig umsetzen zu können.

4.4.1 Aufrufkontext

Das Bilden des Aufrufkontextes erfolgt wie schon im PTV1-Konnektor. Die nur für den HBA verwendete User-ID muss im Rahmen der ePA nicht gesetzt werden, da der Zugriff auf die ePA mittels HBA in den Stufen 1 und 1.1 nicht möglich ist. 

Abbildung 1: ILF_ePA_Element_Context

Der Konnektor ermittelt unter Verwendung von Konfigurationsdaten am Konnektor und der Context-Informationen die zur Laufzeit verfügbaren SM-Bs, die für den Aktenzugriff vom Konnektor herangezogen werden können. Voraussetzung für die Nutzung vieler Funktionsmerkmale ist daher das Vorliegen mindestens einer freigeschalteten SM-B.

Beispiel #: Bsp_ILF_ePA_Context 

Die konsequente Nutzung der ePA-fähigen Aufrufkontexte kann auch konfigurativ in der konkreten LEI sichergestellt werden. 

Die Liste der gesteckten SM-Bs liefert der Systeminformationsdienst (siehe [gemILF_PS#4.1.4]). Der erhöhte Sicherheitszustand bzw. die Freischaltung einer SM-B ist mittels GetPinStatus am Rückgabewert verified erkennbar (siehe [gemILF_PS#4.1.5.4]).

4.4.1.1 Aufrufkontext in großen Institutionen

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. Besonders sorgfältig sollte dabei das Verhältnis von MandantID und Telematik-ID beachtet werden, falls eine große Institution über mehrere SMC-Bs mit unterschiedlichen Telematik-IDs verfügt.

Der Aufrufkontext referenziert implizit (über die Konfiguration von SMC-B und MandantID) eine Telematik-ID. Die Telematik-ID, die implizit im Aufrufkontext der Berechtigungsvergabe verwendet wird, muss mit der Telematik-ID übereinstimmen, die implizit im Aufrufkontext der Berechtigungsvergabe verwendet wird. Andernfalls kann es unerwünschterweise passieren, dass der Zugriff auf die Dokumentenverwaltung scheitert, weil keine Zugriffsberechtigung vorliegt.

Mandantenverwaltung

Eine Voraussetzung für eine funktionierende ePA besteht darin, dass die Leistungserbringerinstitution so konfiguriert ist, dass die Beziehung zwischen MandantID und Telematik-ID eindeutig ist, d.h. jedem ePA-Mandanten muss immer genau eine Telematik-ID zugeordnet sein. Die Beziehung zwischen MandantID und Telematik-ID muss eine n:1 Beziehung sein. Andernfalls bestünde die Gefahr, dass genutzte Mandanten zufällig Telematik-IDs zugeordnet werden.

Das PS kann die n:1-Beziehung zwischen MandantID und Telematik-ID technisch verifizieren, indem es (Schritt 1) alle SMC-B-Cardhandles der für die ePA im Kontext verwendeten MandantID ermittelt, (Schritt 2) für jede dieser CardHandle per ReadCardCertificate aus der SMC-B das C.HCI.AUT-Zertifikat ausliest, die Telematik-ID extrahiert und (Schritt 3) eine Fehlermeldung anzeigt, falls die ermittelten Telematik-IDs pro MandantID nicht identisch sind.

Wenn es SMC-Bs mit mehr als einer Telematik-ID gibt, muss in der Konfiguration von Konnektor und Primärsystem die fachliche Bedeutung des Aufrufkontextes besondere Beachtung finden:

• Die MandantID der Berechtigungsvergabe muss immer auf dieselbe Telematik-ID in den SMC-Bs verweisen wie die MandantID (bzw. die ihr zugehörige Telematik-ID), die in der Dokumentenverwaltung z.B. beim Zugriff auf eine Akte verwendet wird.
• ClientsystemID und WorkplaceID können im Aufrufkontext des Zugriffs auf die Dokumentenverwaltung abweichen vom Aufrufkontext der Berechtigungsvergabe.

Lastprobleme vermeiden

Die Operationen getHomecommunityID, getAuthorizationList und getAuthorizationState liefern Informationen, die für alle Clientsysteme und Arbeitsplätze des gleichen Mandanten nutzbar sind. Gleichlautende Anfragen können somit überflüssige Last für beteiligte Komponenten verursachen.  

Um diese unnötige Last zu minimieren, die in großen Institutionen für die ePA-Aktensysteme entstehen könnte, soll in großen Institutionen beachtet werden:

• Arbeitsplätze mit unterschiedlichen WorkplaceIDs sollen nicht separat voneinander jeweils getHomecommunityID, getAuthorizationList und getAuthorizationState aufrufen. Vielmehr sollen diese Aufrufe in den für sie vorgesehenen Zeiträumen einmalig für den Mandanten erfolgen, der über den Aufrufkontext referenziert wird. 
• Von einander getrennte Clientsysteme in einer Leistungserbringerumgebung (z.B. die Clients eines Krankenhauslabors und einer Krankenhausapotheke) dürfen nur dann separat voneinander getHomecommunityID, getAuthorizationList und getAuthorizationState aufrufen oder Ad-hoc-Berechtigungen erstellen, wenn sie nicht auf die Berechtigungsinformationen zugreifen können, die in anderen Clientsystemen gegebenenfalls bereits vorliegen.

Weitere Hinweise zur Nutzung der ePA in Krankenhäusern finden sich auf dem Fachportal der gematik unter

• TI-FAQ für Krankenhäuser  und
• Anschluss von Krankenhäusern an die TI - Eine Übersicht über die Te-lematikinfrastruktur im stationären Sektor 

4.4.2 RecordIdentifier

Für die ePA eines Versicherten werden identifizierende Merkmale in unterschiedlicher Form verwendet:

Tabelle 2: Tab_ILF_ePA_Identifier_für_Versicherte_und_Akten

An den Konnektor-Schnittstellen werden jeweils entweder der RecordIdentifier oder seine Bestandteile verwendet.

Abbildung 2: Abb_ILF_ePA_RecordIdentifier

4.4.3 Status Aktenzugriff

Die LEI wird vom Primärsystem darin unterstützt, die Metadaten für die Aktenzugriffe mit möglichst wenig Pflegeaufwand zu befüllen, und zwar insbesondere durch die

• Persistierung von Statusinformationen der Zugriffsberechtigung einer LEI auf Akten;
• Verwendung von Default-Einstellungen
• Selbstauskunftsangaben und reduzierte Wertebereichsvorschlagslisten aus [gemSpec_DM_ePA] gemäß Kap. 6.2

Der lokal hinterlegbare Status des Aktenzugriffs umfasst für einzelne Versicherte in Tab_ILF_ePA_Zugriffsberechtigungsstatus pro RecordIdentifier aufgeführte Informationen. Kap. 5.4.1 (Benachrichtigungen verwalten) beschreibt, wie sich diese Informationen akkumulieren und aktualisieren lassen.

Tabelle 3: Tab_ILF_ePA_Zugriffsberechtigungsstatus pro RecordIdentifier

Die LEI erhält Zugriff auf ePA-Dokumente je nach erteilter Kombination von Zugriffsberechtigungen. Folgende einander ergänzende Zugriffsberechtigungen sind in der ePA möglich:

Tabelle 4: Tab_ILF_ePA_Zugriffsberechtigungen  

5 Funktionsmerkmale

Das Aktenkonto eines Versicherten kann sowohl beim LE, als auch am ePA-Frontend des Versicherten aktiviert werden (Kap. 5.2.1).

Das PS nutzt die Berechtigungsverwaltung des ePA-Aktensystems über seine Schnittstellen zum Fachmodul ePA.

Leistungserbringerinstitutionen haben zwei Möglichkeiten, vom Versicherten eine Berechtigung zum Aktenzugriff zu erhalten:

1. Der Versicherte erteilt eine Berechtigung für die LE-Institution am ePA-Frontend des Versicherten 
2. In der LE-Institution erteilt der Versicherte eine Ad-hoc-Berechtigung (Kap. 5.1.4)

Die Berechtigung 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, s. [gemSpec_PKI#Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung] und [gemKPT_Arch_TIP#Tabelle Zugriffsberechtigter Personenkreis (PK) nach §291a SGB V].

Die Laufzeit von Zugriffsberechtigungen ist begrenzt. Falls eine Zugriffsberechtigung aufgrund in der Vergangenheit liegendem expirationDate oder Berechtigungsentzug am ePA-Frontend des Versicherten nicht mehr existiert, ist eine erneute Berechtigungsvergabe erforderlich, s. [gemSysL_ePA#2.5.2]. 

Im Falle vorliegender Berechtigung kann das PS den RecordIdentifier des Versicherten ermitteln (Kap. 5.1.5).

Für ein bereits aktiviertes Aktenkonto kann sich eine Kombination der Anwendungsfälle bis hin zu einem lesenden Aktenzugriff beispielhaft folgendermaßen darstellen:

Abbildung 3: Abb_ILF_ePA_Kombinierte_Anwendungsfälle_für_bereits_aktiviertes_Aktenkonto

In technische Abläufe wird der Versicherte oder sein Vertreter über die PIN-Eingabe integriert.

Tabelle 5: Tab_ILF_ePA_Funktionsmerkmale_Beteiligung_Versicherter

Der Vertreter hat seine Vertretungsberechtigung am ePA-Frontend des Versicherten erhalten, wo auch die eGK des Vertreters der ePA des Vertretenen bekannt gemacht wurde. Im Gegensatz dazu benutzt der gesetzlich bevollmächtigte Vertreter die eGK desjenigen, den er vertritt.

Falls ein Vertreter das Aktenkonto aktivieren möchte, kann er dies nur dann tun, falls er ein gesetzlich bevollmächtigter Vertreter ist, der über eGK und PIN des Versicherten verfügt, den er vertritt. Für das Aktivieren des Aktenkontos kann der Vertreter seine eigene eGK nicht verwenden, anders als beim Erteilen der Ad-hoc-Berechtigung.

Für die Durchführung der Aktenkonto-Aktivierung oder der Erteilung der Ad-hoc-Berechtigung durch einen gesetzlich bevollmächtigten Vertreter ist keine darüber hinaus gehende zusätzliche Implementierung am PS erforderlich.

Das komplette Berechtigungskonzept inklusive der Berechtigungsverwaltung am ePA-Frontend des Versicherten liefert [gemSysL_ePA#3.6].

5.1 ePA-Administration

Das Aktenmanagement der Leistungserbringer (PHRManagementService) erfolgt weitgehend über das Fachmodul ePA und dort gekapselte Funktionalitäten.

In ActivateAccount und RequestFacilityAuthorization werden eGK und SM-B im freigeschaltetem Zustand verwendet, in GetHomeCommunityID nur die SM-B. 

5.1.1 Aktenanbieter ermitteln

Frau Gundlach ist Patientin bei Herrn Dr. Weber und teilt ihm bei einem vergangenen Arzttermin mit, dass sie seit kurzem ein Aktenkonto bei einem ePA-Provider eingerichtet hat. Dr. Weber ermittelt daraufhin dessen Identifier über eine Funktion seines Primärsystems, und speichert den Identifier des Aktenanbieters von Frau Gundlach daraufhin persistent in der Primärdokumentation des Primärsystems ab. 

Für die Nutzung der ePA durch das Primärsystem ist das Vorliegen eines Identifikators für das Aktenkonto des Versicherten (RecordIdentifier) erforderlich, der neben der KVNR auch dessen HomeCommunityID umfasst.

Zur Ermittlung der HomeCommunityID für ein nutzbares Aktenkonto des Versicherten wird die Operation GetHomeCommunityID des PHRManagementService genutzt. Falls eine Akte sich in keinem nutzbaren Zustand befindet, enthält die GetHomeCommunityIDResponse keine HomeCommunityID.

Fachliche Grundlage der Aktenzuordnung ist die Versicherten-ID (KVNR) des Versicherten. Jeder Versicherte hat zur selben Zeit nur ein einzelnes Aktenkonto, falls er über ein Aktenkonto verfügt. Unterschiedliche Versicherte können bei jeweils unterschiedlichen Aktenanbietern ihre Patientenakte hosten lassen. Die Abfrage der verschiedenen möglichen Aktenanbieter übernimmt das Fachmodul für das PS. Jeder Versicherte verfügt über genau eine aktive Akte, auch während er ggf. den Aktenanbieter wechselt.

Das Resultat von Aktenanbieter ermitteln, die HomeCommunityId, wird als Teil des RecordIdentifiers verwendet, sowie separat als Wert bestimmter Metadatenfelder.

Eine persistente Speicherung der HomeCommunityId (kurz: HCID) beim Datensatz des Versicherten macht eine wiederholte zeitaufwändige Ermittlung der HCID überflüssig. Der einmal ermittelte Status der Akte als aktiviert bei einem bestimmten Aktenanbieter ändert sich höchst selten. 

In der Response von GetAuthorizationList() sind HomeCommunityIds enthalten, die versichertenbezogen persistiert werden können, falls noch nicht geschehen.

Der Tabelle Tab_ILF_ePA_Handlungsanweisung_im_Fehlerfall ist zu entnehmen, in welchen Fehlerszenarien es sinnvoll ist, getHomeCommunityID aufzurufen (siehe 7404, wobei auch die Hinweise 7401, 7403, 4705, 4706 zu beachten sind).  

Solange die ePA-Nutzung gering ist, werden viele GetHomeCommunityID-Anfragen negativ beantwortet werden. Da sich der Aktenstatus höchst selten ändert, ist es jedoch nicht sinnvoll, die Anfragen oft zu wiederholen.

5.1.1.1 Schnittstelle

Tabelle 6: Tab_ILF_ePA_Operation_getHomeCommunityID

Abbildung 4: Abb_ILF_ePA_getHomeCommunityRequest

Abbildung 5: Abb_ILF_PS_ePA_getHomeCommunityIDResponse

5.1.1.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Aktenanbieter ermitteln sind:

Vorbedingung:

• Dem Versicherten ist aktuell nach Auslesen der eGK oder bei einem vorangegangenen Arztbesuch eine Versicherten-ID im Primärsystem zugeordnet worden. 
• Der Aufruf erfolgt aus der Primärdokumentation des Versicherten heraus

Auslöser:

• Die für einen Zugriff auf die Akte des Versicherten oder Verwaltung der Zugriffsberechtigung erforderliche HomeCommunityId liegt nicht vor.
• Bisher im PS bekannte HomeCommunityId hat sich als falsch herausgestellt, insbesondere aufgrund eines Anbieterwechsels des Versicherten. 

Aktivitäten:

• Ermitteln der Versicherten-ID aus der Primärdokumentation des Versicherten

Resultat:

• Im Erfolgsfalle der Operation erhält der Nutzer eine HomeCommunityId, als Voraussetzung der Nutzung der ePA eines Versicherten.
• Die HomeCommunityId wird in der Primärdokumentation des Versicherten abgespeichert gemäß 

  A_14660

  .

5.1.1.3 Nutzung

Das erfolgreiche Ermitteln einer HomeCommunityId ist kein Beleg für das Vorliegen einer Zugriffsberechtigung auf die Akte des Versicherten. Daher ist die Nutzung der Operation GetHomeCommunityID vor allem im Kontext der Ad-hoc-Berechtigung sinnvoll, oder nach einer Kenntnisnahme davon, dass Leistungserbringer eine Berechtigung über das ePA-Frontend des Versicherten erhalten haben. 

Beispiel #: Bsp_ILF_ePA_Request_gethomecommunityid.xml 

Wenn das Primärsystem durch eine VSDM-Prüfung von einem Wechsel der Haupt-IK-Nummer an den Daten des Versicherten informiert wird, soll im Falle einer bestehenden Zugriffsberechtigung auf eine Akte der Operation GetHomeCommunityID aufgerufen werden, da ein Wechsel des Aktenanbieters nicht unwahrscheinlich ist.

5.1.2 Aktenkonto aktivieren

Frau Gundlach hat bei einem Aktenanbieter einen Vertrag über die Nutzung einer elektronischen Patientenakte abgeschlossen. Sie bittet Dr. Weber darum, für sie das Aktenkonto zu aktivieren. Dr. Weber ermittelt den Aktenanbieter von Frau Gundlach durch Aufruf einer entsprechenden Funktion im PVS  und aktiviert dort für Sie ihre Akte. Dabei gibt Frau Weber die PIN ihrer eGK ein.

Zur Umsetzung des "Schritt 2 - Aktivierung in der Umgebung des Leistungserbringers" im Anwendungsfall Aktenkonto einrichten aus [gemSysL_ePA#3.5.1, UC 2.1 - Aktenkonto einrichten, Schritt 2 - Aktivierung in der Umgebung des Leistungserbringers] wird die Operation ActivateAccount des PHRManagementService genutzt.

Das Aktivieren des Aktenkontos wird entweder vom PS-Nutzer über das Userinterface aktiv gestartet oder es wird implizit aus anderen Anwendungsfällen heraus gestartet, in denen das Fachmodul am Status der Akte erkennt, dass die Akte eines Versicherten noch zu aktivieren ist. Das implizite Starten des Anwendungsfalles führt ebenso wie das vom PS angestoßene Starten des Aktenkonto-Aktivierens zu einer Interaktion des Versicherten mit dem Kartenterminal, worüber das PS durch das Event FM_EPA/ ACTIVATE_ACCOUNT/START informiert wird.

5.1.2.1 Schnittstelle

Durch seine PIN bestätigt der Versicherte seine Einwilligung dazu, das Aktenkonto in der in den Vertragsunterlagen ausgewählten Konfiguration zu aktivieren.

Tabelle 7: Tab_ILF_ePA_Operation_ActivateAccount

Abbildung 6: Abb_ILF_ePA_Eingabeparameter_ActivateAccount

5.1.2.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Aktenkonto aktivieren sind:

Vorbedingung:

• Der Versicherte hat in einem ersten vorgelagerten Initialisierungsschritt ein Aktenkonto bei einem Aktenanbieter eingerichtet.
• Durch ein vorgelagertes GetHomeCommunityID wurde die HomeCommunityId ermittelt.

Auslöser:

• Der Versicherte informiert den LE über eine noch zu aktivierende Akte oder, alternativ, wird der Anwendungsfall durch das Event FM_EPA/ ACTIVATE_ACCOUNT/START gestartet.
• In einem der Anwendungsfälle des PHRService ist der Fehler 7403 ist aufgetreten, der auf ein nicht aktiviertes Aktenkonto hinweist

Aktivitäten:

• Ermitteln des CardHandles zur eGK des Versicherten
• Abfrage getPinStatus, ob PIN.CH gesperrt ist
• Aufruf der Konnektorschnittstelle activateAccount
• Der Versicherte soll darüber informiert werden, dass er am Kartenterminal seine PIN eingeben muss;
• Der Versicherte autorisiert den LE zur Aktivierung der Akte mit seiner PIN-Eingabe
• Auswertung des Ergebnisses

Resultat:

• Das Aktenkonto des Versicherten ist aktiviert

5.1.2.3 Nutzung

Der Versicherte kann so vom Nutzer des PS darauf aufmerksam gemacht werden, dass der Versicherte am Kartenterminal dazu aufgefordert wird, seine PIN einzugeben.

Der Anwendungsfall startet mit der Information des Versicherten, die Aktenaktivierung bereits vorbereitet zu haben, mit einem expliziten Auslösen über das Userinterface des Primärsystems.

Das implizite Aktivieren startet die Aktenkontoaktivierung beispielsweise beim Erteilen einer Ad-hoc-Berechtigung, sofern das Aktenkonto sich in dem Zustand befindet, die ausstehende Aktivierung durchführen zu können. Dabei wird das Event FM_EPA/ ACTIVATE_ACCOUNT/START ausgelöst.

Wenn die Aktivierung des Aktenkontos erfolgreich beendet wurde und sich das Aktenkonto des Versicherten im aktivierten Zustand befindet, löst das ePA-Fachmodul das Event FM_EPA/ ACTIVATE_ACCOUNT/FINISHED aus, das für eine Erfolgsmeldung am Primärsystem genutzt werden kann, um den Versicherten über den Erfolg des Anwendungsfalles zu unterrichten.

5.1.3 Ad-hoc-Berechtigung erteilen

Frau Gundlach möchte Herrn Dr. Weber und seiner Hausarztpraxis Zugriff auf ihre ePA erteilen. Im Gespräch mit der Medizinischen Fachangestellte (MFA) von Dr. Weber am Empfangstresen, Frau Kunze, wird besprochen, dass der Zugriff auf alle normalen von Leistungserbringern eingestellte Dokumente erfolgen soll, nicht aber auf die vertraulichen Dokumente von Frau Gundlach. Sie überreicht ihre eGK Frau Kunze. Frau Kunze wählt die besprochene Option am PS. Frau Kunze fordert die Ad-hoc-Berechtigung am PS an und dreht das Kartenterminal mit dem Eingabefeld für die PIN-Eingabe zu Frau Weber. Auf dem Display des Kartenterminals sieht Frau Weber die Aufforderung zur PIN-Eingabe für die Ad-hoc-Berechtigung mit den abgesprochenen Optionen, sowie Dauer der Gültigkeit der Zugriffsberechtigung für die Arztpraxis Dr. Weber. Das PS am Empfangstresen fügt der lokalen Primärdokumentation von Frau Gundlach ein ePA-Kennzeichen als Markierung einer bestehenden Zugriffsberechtigung hinzu. 

Zur Umsetzung des Anwendungsfalles Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern aus [gemSysL_ePA#3.6.7, UC 3.7 - Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern] wird die Operation RequestFacilityAuthorization des PHRManagementService verwendet.

Die Vertraulichkeitsstufe vertraulich (restricted) betrifft Dokumente, die der Versicherte an seinem FdV als vertraulich gekennzeichnet hat, sowie Dokumente, die von Leistungserbringern auf Wunsch des Versicherten als vertraulich eingestellt wurden. Falls eine Freigabe auf Dokumente der Vertraulichkeitsstufe restricted erfolgt, ist damit eine Freigabe auf Dokumente der Vertraulichkeitsstufe normal verbunden.

Es ist nicht möglich, in der Leistungserbringer-Umgebung eine Freigabe auf Dokumente der Vertraulichkeitsstufe very restricted zu erteilen. Auch in anderen Aspekten verfügt die Berechtigungsvergabe am FdV über mehr Optionen als die Berechtigungsvergabe am PS, insbesondere was das Setzen von Dokumenten auf eine Deny- oder Permit-List betrifft. Versicherte, die solche Optionen wählen wollen, verwenden dazu ausschließlich ihr FdV.  

Durch die Erteilung einer Ad-hoc-Berechtigung wird eine Konfiguration der Zugriffsrechte erzeugt, die eine bereits bestehende Konfiguration überschreibt. Das betrifft auch ggf. bestehende Konfigurationen, die der Versicherte an seinem FdV vorgenommen hat.

Am Aktensystem werden Zugriffe auf Dokumente unterbunden, die nicht den gesetzlich festgelegten berufsgruppenspezifischen Regeln entsprechen. Manche Berufsgruppen verfügen nur über eingeschränkte Zugriffsrechte auf bestimmte Typen von Dokumenten. Die Auswahl von Dokumentenkategorien durch den Versicherten kann diese Zugriffsmöglichkeiten weiter einschränken, nicht jedoch über die gesetzlich festgelegten Rahmenbedingungen hinaus erweitern.

Über die Operation ReadCardCertificate kann das PS die Berufsgruppe derjenigen SMC-B ermitteln, die für die ePA-Zugriffe benutzt wird. Im Authentisierungszertifikat C.AUT befindet sich die  Berufsgruppe ProfessionOID in der ZertifikatsExtension Admission, s. [gemSpec_PKI#Anhang A]. 

Die Rolle des Versicherten kann teilweise auch vom Vertreter übernommen werden. In diesem Fall übergibt der Vertreter seine eigene eGK, um eine Ad-hoc-Berechtigung für den Versicherten zu erstellen, für den die Vertretung wahrgenommen wird (identifiziert durch dessen RecordIdentifier, aufgerufen aus der PS-Dokumentation des Vertretenen). 

Durch das Starten des Anwendungsfalles aus dem Aktenkonto desjenigen heraus, der vertreten wird, wird dessen RecordIdentifier verwendet. Die Ermittlung desjenigen, der vertreten wird, kann nicht über die eGK des Vertreters erfolgen und muss vielmehr im Dialog mit dem Vertreter durchgeführt werden.  Falls für den Vertreter die Vertretungsrechte nicht (mehr) vorliegen sollten, scheitert der Anwendungsfall Ad-hoc-Berechtigung durch den Vertreter erteilen. Dabei wird der Fehler 7209 (Keine Berechtigung für das Aktenkonto vorhanden) geworfen. 

5.1.3.1 Schnittstelle

Tabelle 8: Tab_ILF_ePA_Operation_RequestFacilityAuthorization

Abbildung 7: Abb_ILF_ePA_RequestFacilityAuthorization

Der Eingabeparameter AuthorizationConfiguration beschreibt 

• Art des Zugriffs: die in Tab_ILF_ePA_Zugriffsberechtigungen erläuterten Werte
• Zugriffsberechtigungs-Endedatum. ExpirationDate berechnet aus der Dauer des Zugriffs (1 Tag, 7 Tage, 18 Monate, flexibel, unbefristet) (Default: 7 Tage).

Der Versicherte oder ein von ihm berechtigter Vertreter stimmt der Berechtigung auf Aktenzugriff durch PIN-Eingabe am Kartenterminal, in dem die eGK (des Versicherten bzw. des Vertreters) steckt, zu.

5.1.3.2 Umsetzung

Das Primärsystem nutzt beim Erteilen einer Ad-hoc-Berechtigung die Festlegungen zur Vertraulichkeitsstufe (AuthorizationConfidentiality) und die kategoriebasierte Berechtigung (DocumentCategoryList). Dokumentenspezifische Berechtigungen, d.h. Zugriffsberechtigungen, die sich auf einzelne ausgewählte Dokumente beziehen, können am PS nicht gesetzt werden. Dokumentenspezifische Berechtigungen erteilen kann nur der Versicherte an seinem Frontend.

Falls schon eine Berechtigung vorliegt, wird diese durch die Operation überschrieben.

Die Aktivitäten des Anwendungsfalles Ad-hoc-Berechtigung erteilen sind:

Vorbedingung:

• Ermittelter RecordIdentifier

Auslöser:

• Ein ePA-Anwendungsfall soll ausgeführt werden,
• Leistungserbringer fragen beim Versicherten eine Autorisierung für einen Aktenzugriff an, 
• Ein Versuch, einen ePA-Anwendungsfall auszuführen scheiterte mit Fehler 7209 (Keine Berechtigung für das Aktenkonto vorhanden). Vor einem erneuten Versuch, einen ePA-Anwendungsfall auszuführen wird nun erst noch eine Ad-hoc-Berechtigung eingeholt.

Aktivitäten:

• Ermitteln des CardHandles zur eGK des Versicherten
• Abfrage getPinStatus, ob PIN.CH gesperrt ist
• Auswahl am PS
• • der vom Versicherten intendierten (mündlich mitgeteilten) Art der Zugriffberechtigung im Element authorizationConfiguration
  • des Zeitraumes, für die er dem LE Zugriff auf seine Akte gewährt (1 Tag, 7 Tage [default], 18 Monate, flexibel oder unbefristet);
• Aufruf der Konnektorschnittstelle unter Übergabe der Auswahl-Parameter
• Der Versicherte soll darüber informiert werden, dass er am Kartenterminal seine PIN zur Bestätigung der Auswahl eingeben muss;
• Die Erfolgsmeldung wird vom PS verarbeitet, indem der Zeitraum vermerkt wird, für den die Autorisierung vorliegt, sowie die RecordIdentifier

Resultat:

• Mit der vorliegenden Berechtigung ist die Voraussetzung für sämtliche Aktenzugriffe und Aktenadministrations-Anwendungsfälle gegeben
• Es liegt die RecordIdentifier vor, für die eine Zugriffsautorisierung besteht.

Abbildung 8: Abb_ILF_ePA_Ad-hoc-Berechtigung_erteilen

5.1.3.3 Nutzung

Die Ad-hoc-Berechtigung ermöglicht eine Abfrage der Metadaten der ePA-Dokumente und das Anlegen eines lokalen Metadaten-Index für die Dokumente, auf die prinzipiell Zugriffsrechte bestehen, als Vorbereitung von Dokumentenmanagement-Zugriffen. 

5.1.3.4 Nutzung durch einen Vertreter

Die Ad-hoc-Berechtigung kann ein Vertreter für denjenigen durchführen, den er vertritt, falls die Vertreterberechtigung vom Vertretenen am FdV ausgestellt wurde. Ein Versicherter kann einen anderen Versicherten am PS nicht als Vertreter einrichten. Wohl aber kann der Vertreter die am Aktensystem vorliegende Vertreterberechtigung dafür nutzen, einer LEI im Rahmen der Ad-hoc-Berechtigung eine Zugriffsberechtigung auf das Konto des Vertretenen auszustellen.

Dazu muss der Vertretene in der LEI als Patient bekannt sein, jedoch nicht mit seiner eGK physisch anwesend sein. Der Vertreter teilt der LEI mit, für welchen Versicherten er sein Vertreterrecht wahrnehmen möchte, damit für den Vertretenen InsurantId und HomeCommunityID ermittelt werden können.

5.1.4 Sämtliche Berechtigungen der LEI ermitteln

Die Praxis von Herrn Dr. Weber hat von verschiedenen Versicherten eine Zugriffsberechtigung auf ihre ePA erhalten. Einmal am Tag, jeweils am frühen Morgen vor Öffnung der Praxis aktualisiert die Praxis die Informationen über die vorliegenden Zugriffsberechtigungen. Dadurch kann den Mitarbeitern der Praxis angezeigt werden, ob auch diejenigen Patienten, die an diesem Tag einen Behandlungstermin haben, eine Zugriffsberechtigung erteilt haben. Eine vorliegende Zugriffsberechtigung wird durch ein Icon am PVS angezeigt, so dass bei Bedarf mit den Patienten darüber geredet werden kann, ob das Erteilen einer Zugriffsberechtigung angeraten ist, und wie die dafür zu erteilende Zugriffsberechtigung gewählt werden sollte. 

Durch Aufruf der Operation PHRManagementService::GetAuthorizationList erhält das PS eine Liste sämtlicher zum Zeitpunkt der Abfrage vorliegenden RecordIdentifier, auf die die LEI zugriffsberechtigt ist, sowie das jeweilige Ablaufdatum der Zugriffsberechtigung. 

Der LE erhält über die Schnittstelle nicht nur Kenntnis über Zugriffsberechtigungen, die in der Ad-hoc-Autorisierung in seiner LEI erteilt wurden, sondern auch über Zugriffsberechtigungen, die vom ePA-Frontend des Versicherten aus erteilt oder geändert wurden.

Diese Daten stehen jedoch generell unter dem Vorbehalt, dass der Versicherte oder sein Vertreter diese Berechtigung am FdV jederzeit wieder entziehen kann.

5.1.4.1 Schnittstelle

Tabelle 10: Tab_ILF_ePA_Operation_GetAuthorizationList

Abbildung 9: Abb_ILF_ePA_Eingabeparameter_GetAuthorizationList

Die AuthorizationList als Liste von Tupeln aus RecordIdentifier und Ablaufdatum der Zugriffsberechtigung erlaubt die Aktualisierung von Info_Neu_Zugriff (über den RecordIdentifier) und Info_Ende_Zugriff (über das validTo-Element), indem die Liste der AuthorizationEntry-Elemente mit der Liste der bisher schon bekannten Berechtigungen auf Aktenzugriff verglichen wird.

Abbildung 10: Abb_ILF_ePA_GetAuthorizationListResponse

5.1.4.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Sämtliche Berechtigungen der LEI ermitteln sind:

Vorbedingung:

• Eine dem Aufrufkontext zugeordnete SM-B ist freigeschaltet.

Auslöser:

• Der tägliche Job wird in den Nebenzeiten angestoßen

Aktivitäten:

• Der Job läuft im Hintergrund und aktualisiert Informationen über erhaltene Berechtigungen.

Resultat:

• Informationen über erhaltene Berechtigungen wurden aktualisiert.

5.1.4.3 Nutzung

Die Liste der Autorisierungen, die für eine LEI vorliegen, wird mittels GetAuthorizationList tagesaktuell gehalten. Sie gibt Auskunft auch über Berechtigungen, die der Versicherte für die LEI am FdV vergeben hat. Die Information über die am FdV (und nicht ad-hoc) erteilten Berechtigungen können vom PS dazu genutzt werden, der LEI darüber Auskunft zu geben, dass die Akten bestimmter Versicherten aktuell nutzbar sind, ohne dass mittels RequestFacilityAuthorization oder GetAuthorizationState gezielte Maßnahmen bzw. Prüfungen vorgenommen werden, um diese Aktenkonten nutzbar zu machen.

Falls in der Vergangenheit eine Ad-hoc-Berechtigung erteilt wurde, zu der Details gemäß A_14517-* am PS gespeichert wurden, so können diese Informationen veralten, weil der Versicherte am FdV jederzeit Veränderungen vornehmen kann. Durch die tagesaktuelle Abfrage GetAuthorizationList können Änderungen erkannt werden, die Versicherte im Nachgang zu einer Ad-hoc-Berechtigung vorgenommen haben. In dieser Hinsicht kann die Autorisierungsliste aktueller sein als die aufgrund von A_14517-* am PS gespeicherten Informationen, wobei die bei der Ad-hoc-Berechtigung gespeicherten Daten detaillierter sind, denn sie umfassen zusätzlich die am Kartenterminal vergebenen Berechtigungskategorien.

Der Konnektor wirft im Falle einer zu häufigen Anfrage von getAuthorizationList den Fehler 7231. Falls es eine Response mit der Warning 7230 gibt, konnten nicht alle Aktensysteme erfolgreich angefragt werden. Sowohl beim Fehler 7231, als auch bei der Warning 7230 darf nicht sofort ein Retry von getAuthorizationList durchgeführt werden.

Informationen über die erhaltenen Berechtigungen helfen dabei, die ePA-Nutzung im Vorfeld der Öffnung einer Praxis für den Besucherverkehr vorzubereiten. Sie sollten, um Spitzenlasten zu vermeiden, außerhalb der Hauptverkehrszeiten erfolgen. Keinesfalls darf ein getAuthorizationList vor jedem einzelnen Aktenzugriff erfolgen. 

Das PS erhält Kenntnis vom Aktenanbieterwechsel eines Versicherten über die GetAuthorizationListResponse, in der die aktualisierte HomeCommunityId des neuen Aktenanbieters enthalten ist 

Sobald ein Versicherter den Aktenanbieter gewechselt hat, wird der alte RecordIdentifier (zum alten Aktenanbieter) aus der AuthorizationEntry-Liste entfernt. Beim Aktenanbieterwechsel wird die Berechtigung der LEI in die neue Akte transferiert, so dass ein neuer RecordIdentifier in der AuthorizationEntry-Liste erscheint. Anhand der bekannten InsurantId kann das PS feststellen, dass der bekannte Versicherte die Akte gewechselt hat, so dass der in der Primärakte für den Versicherten dokumentierte RecordIdentifier im PS aktualisiert werden kann. 

5.1.4.4 Nutzung in größeren Institutionen

Das Ergebnis von GetAuthorizationList wird anhand der Telematik-ID der SMC-B gebildet, die aufgrund der Angaben im Context verwendet wird. Für größere Institutionen, etwa Krankenhäuser, die über eine Vielzahl von SMC-Bs verfügen, gilt:

1. Es sollen nur der ePA-fähige Contexte (s. A_22398) für GetAuthorizationList verwendet werden. Damit ist sichergestellt, dass die Abfrageergebnisse Aussagen über Telematik-IDs beinhalten, die effektiv für die Anwendung ePA verwendet werden.  
2. Anfragen, die über ihre Contexte unterschiedliche SMC-Bs verwenden, aber dieselbe Telematik-ID enthalten, ergeben ein identisches Ergebnis und sind somit überflüssig. 

5.1.5 Einzelne Berechtigungen der LEI ermitteln

Frau Gundlach tritt an den Tresen der Arztpraxis Dr. Weber, um sich für ihre erste Schwangerschaftskontrolluntersuchung zu melden. Aufgrund der täglich ermittelten Zugriffsberechtigungsliste sieht die Arzthelferin in der GUI ihres PVS, dass Frau Gundlach der Arztpraxis noch keine ePA-Zugriffsberechtigung erteilt hat, so dass die Ergebnisse der Untersuchung noch nicht in den elektronischen Mutterpass eingetragen werden können. Weil das Kartenterminal gerade durch andere Patienten belegt ist, kann eine Ad-hoc-Berechtigung aktuell nicht durchgeführt werden. Frau Gundlach verspricht, die Berechtigung an ihrem Mobiltelefon, bzw. ihrem FdV zu erteilen, während sie im Wartezimmer auf den Termin mit Dr. Weber wartet. Sie vergibt die Zugriffsberechtigung für 12 Monate. Die Arzthelferin möchte einige Zeit später erste Daten in den elektronischen Mutterpass von Frau Gundlach eintragen. Um unnötigen Fehlern vorzubeugen erfragt sie gezielt, ob Frau Gundlach diese Berechtigung inzwischen erteilt hat. Frau Gundlach hat die Berechtigung im Wartezimmer erteilt. Die Arzthelferin trägt erste Daten in den Mutterpass von Frau Gundlach ein.

Leistungserbringer können mittels der Operation GetAuthorizationState gezielt abfragen, ob ein bestimmter Versicherter der eigenen LEI eine ePA-Zugriffsberechtigung erteilt hat, und welches das Ablaufdatum ist.

Die KVNR des Versicherten wird im RecordIdentifier an der Schnittstelle übergeben, zusammen mit dem Parameter UserAgent, der vom Primärsystem automatisiert befüllt wird.

Die Rückgabe beinhaltet eine Liste von Ablaufdaten für Berechtigungen, die jeweils auf eine Anwendung bezogen sind. Für die Anwendung Elektronische Patientenakte wird der Wert "ePA" mit dem Ablaufdatum der ePA-Berechtigung als Listenelement mitgeliefert. 

5.1.5.1 Schnittstelle

Tabelle 11: Tab_ILF_ePA_Operation_GetAuthorizationState

Die Angabe des UserAgents dient der Performance-Rohdatenerfassung und wird ohne kundenspezifische Angaben ausschließlich durch firmwarespezifische Angaben des PS-Herstellers gemäß [gemSpec_DM_ePA#A_22470-*] gebildet.

5.1.5.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Einzelne Berechtigungen der LEI ermitteln sind:

Vorbedingung:

• Eine dem Aufrufkontext zugeordnete SM-B ist freigeschaltet.

Auslöser:

• Anlass, die Berechtigungsvergabe eines bestimmten Versicherten für die LEI zu prüfen 

Aktivitäten:

• Aktualisierung der Informationen über erhaltene Berechtigungen.

Resultat:

• Informationen über erhaltene Berechtigungen wurden aktualisiert.

5.1.5.3 Nutzung

GetAuthorizationState ist geeignet, um in konkreten Nutzungsszenarien gezielte Abfragen für einzelne Versicherte zu tätigen. Falls Informationen für eine Vielzahl von Versicherten eingeholt werden sollen, sollte abgewogen werden, ob die Nutzung von GetAuthorizationList nicht effektiver ist, auch wenn sie nur einmal täglich durchgeführt werden darf.

Die durch GetAuthorizationList gebildete Autorisierungsliste, die für eine LEI vorliegen, umfasst auch Berechtigungen, die der Versicherte am FdV vergeben hat, und sind tagesaktuell. Die Operation GetAuthorizationState bildet in zwei Fällen eine Ergänzung bzw. eine Alternative:

• Die Information über den Berechtigungsstatus soll noch aktueller sein, etwa weil eine gerade eben am FdV vergebene Berechtigung geprüft werden soll;
• Das PS soll ausschließlich in dedizierten Nutzungsszenarien Informationen über den Berechtigungsstatus eines konkreten Versicherten erhalten. Andere Informationen sind nicht erwünscht, GetAuthorizationList wird daher nicht verwendet.

Sowohl GetAuthorizationList als auch GetAuthorizationState erfassen Berechtigungen, die der Versicherte ad-hoc oder am FdV vergeben hat.

5.2 Dokumentenmanagement

Der Konnektor bietet dem PS mit dem Dienst PHRService eine Dokumentenverwaltung auf  Basis einer Profilierung der IHE-Spezifikationen rund um das Kernprofil XDS.b (Cross-Enterprise Document Sharing) an.

Tabelle 12: Tab_ILF_ePA_PHRService

Name	PHRService [gemSpec_FM_ePA#7.1]
Version	2.0.1
SOAP-Header
Namensraum	urn:ihe:iti:xds-b:2007
Abkürzung Namensraum	ihe
Operationen	Name	Implementierungshinweise
	DocumentRepository_ProvideAndRegisterDocumentSet-b	Profilierung von [ITI-41], s. Kap. 5.2.1
	DocumentRegistry_RegistryStoredQuery	Profilierung von [ITI-18], s. Kap. 5.2.2
	DocumentRepository_RetrieveDocumentSet	Profilierung von [ITI-43], s. Kap. 5.2.3
	DocumentRegistry_RemoveMetadata	Profilierung von [ITI-62], s. Kap. 5.2.5
WSDL	gemäß: PHRService_V2_0_1.wsdl  IHE XCA-Profil [IHE-ITI-TF1] IHE XDR-Profil [IHE-ITI-TF1] IHE RMD-Profil [IHE-ITI-RMD]
XML-Schema	PHRService.xsd

Tabelle 13: Tab_ILF_ePA_DM_Profilierung

Tabelle 14: Tab_ILF_ePA_Einschränkungen_auf_XDS.b

Die Anwendungsfälle des Dokumentenmanagements der Akte erfordern, dass der Nutzer die Berechtigung hat, auf mindestens eine SM-B zuzugreifen, die für die LE-Institution vorliegt und dass eine durch eine Telematik-ID identifizierte Institution oder ein durch eine Telematik-ID identifizierter Teil einer Institution eine Berechtigung erhalten hat. Um diese Berechtigung durchzusetzen ist eine Konfiguration am Konnektor administrativ zu pflegen und vom PS zu nutzen.

Drei Elemente des Aufrufkontextes eines SOAP-Clients geben bei einem Zugriff des Dokumentenmanagements im SOAP-Header darüber Auskunft, von welchem Clientsystem-Arbeitsplatz ein Aufruf auf welche Akte erfolgt: 

Tabelle 15: Tab_ILF_ePA_ClientInformationen

Die interne Mandantenverwaltung des PS SOLL auf die WS-Kommunikation der ePA über die Nutzung der MandantID abgebildet werden. Die MandantID steht für die Kennung der PS-Mandanten. Die Konfiguration von PS-Mandanten, SM-Bs und Arbeitsplätzen wird in [gemILF_PS] geschildert, die Konfiguration für größere LE-Institutionen mit mehreren SM-Bs oder Mandanten in Kapitel 3.3.3.

Der Nutzer ist durch die lokale Mandantenverwaltung seines Primärsystems berechtigt auf die Primärdokumentation des Versicherten zuzugreifen und wird durch die Konfiguration der Mandantenverwaltung im Konnektor derjenigen SM-B zugeordnet, die er für den Zugriff auf die Akte benötigt. 

In der Administrationsoberfläche des Konnektors wird gemäß [gemSpec_Kon#10.3.1.1] im Informationsmodell der LE-Institution die Default-SM-B der Arbeitsplätze, Clientsysteme und Kartenterminals für den Zugriff auf die ePA konfiguriert. Für die Administration des Default-Aufrufkontextes s. [gemSpec_FM_ePA#6.4]. 

Ad-hoc-Berechtigung erteilen ist nicht davon abhängig, ob für eine LEI eine oder mehrere SM-Bs im Verzeichnisdienst eingepflegt sind. Falls mehrere  SM-Bs in einer LEI verwendet werden, sind die unterschiedlichen Primärsystem-Arbeitsplätze erst dann zugriffsberechtigt, wenn der Aufrufkontext oder der Default-Aufrufkontext SMC-Bs mit derjenigen Telematik-ID zugeordnet sind, für die eine Berechtigung erteilt wurde.

Wenn der Parameter nicht gesetzt wird, verwendet das Fachmodul ePA den in der Konnektorkonfiguration hinterlegten Default-Wert.

Das Ersetzen eines Dokumentes ist als Kombination mehrerer Anwendungsfälle umzusetzen: Nach dem Ermitteln (Suchen, Kap. 5.2.2) und Löschen des zu ersetzenden Dokumentes (Kap. 5.2.5) nach Rücksprache mit dem Versicherten wird das ersetzende Dokument (als "Original"-Dokument, s. A_14250) in die ePA eingestellt (Kap. 5.2.1).

5.2.1 Dokumente einstellen

Herr Dr. Weber hatte für Frau Gundlach vor einigen Monaten einen Notfalldatensatz auf ihre eGK geschrieben. Dr. Weber bespricht mit Frau Gundlach, ihren Notfalldatensatz auch in ihre ePA einzustellen. Frau Gundlach erteilt eine Ad-hoc-Berechtigung für diesen Zugriff. Bei Auswahl der entsprechenden Funktion nutzt Dr. Weber die Möglichkeit, die Metadaten zu kontrollieren, mit denen der Notfalldatensatz automatisch für die Akte von Frau Gundlach konnotiert werden. Dr. Weber nimmt kurz Notiz von der Bestätigungsmeldung über den Erfolg des Einstellens.

Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer Einstellen aus  [gemSysL_ePA#3.7.1, UC 4.1 - Dokumente durch einen Leistungserbringer einstellen]  wird Provide & Register Document Set-b [ITI-41] gemäß Cross-Enterprise Document Reliable Interchange (XDR) Profile profiliert. 

Tabelle 17: Tab_ILF_ePA_IHE-Profilierung_ITI41

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

5.2.1.1 Schnittstelle

Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRepository) die Operation DocumentRepository_ProvideAndRegisterDocumentSet-b an, und übernimmt gemäß [ITI-41] die Rolle eines IHE DocumentRepository gegenüber dem PS.

Tabelle 18: Tab_ILF_ePA_Operation_Dokument_einstellen

Generell besteht ein Schreibrecht im Rahmen der Zugriffsunterbindungsregeln, sobald eine LEI über irgendeine Art von Zugriffsberechtigung verfügt.  Vor dem Einstellen von MIOs des Typs Mixed oder Uniform (MIOs in statischen Ordnern, d.h. alle MIOs bis auf Mutterpass und U-Heft) sollen jedoch bereits bestehende fachliche MIO-Inhalte geprüft werden, so dass sichergestellt werden kann, dass die neu einzustellenden MIO-Daten konsistent sind zu den bereits bestehenden. 

Dynamische Ordner sind bei fehlenden Zugriffsrechten für das PS nicht zu ermitteln, so dass sich nicht feststellen lässt, ob dynamische Ordner bereits angelegt wurden. Auch ist nicht ohne schreibenden Zugriff und Auswertung der Fehlermeldung zu ermitteln, dass hier ein Zugriffsrecht fehlt. Der IHE-Fehlercode DocumentAccessNotAuthorized informiert darüber, dass eine Vergabe von Zugriffsrechten für Sammlungstypen mixed und uniform erforderlich ist, um Dokumente erfolgreich einstellen zu können. Dabei muss die Vertraulichkeitsstufe der Kategorienberechtigung vom Versicherten passend gewählt werden.   

Dokumente, die auf einer Denylist stehen oder für die aufgrund der Vertraulichkeitsstufe keine Leseberechtigung besteht, sind für das PS nicht zu ermitteln.

Durch das Auslesen von (MIO)-Foldern und die fachliche Sichtung der bereits bestehenden Daten im Vorfeld des Schreibens können folgende Probleme im Vorfeld verhindert werden:

• MIO-Eintrags-Verdoppelung: MIO-Datenelemente, die einmalig vorliegen sollen, dürfen nicht doppelt/parallel angelegt werden. Es soll z.B. verhindert werden, dass eine Anamnese im Mutterpass doppelt eingestellt wird oder identische Impfeinträge doppelt angelegt werden.
• Dokumentenverdoppelung: Leistungserbringer oder Primärsysteme sollen prüfen, dass sie MIO-Einträge (in statischen Ordnern) oder Dokumente nicht bereits eingestellt haben. 
• Ordnerverdoppelung: Dynamische Ordner sollen nicht doppelt angelegt werden, nur weil Leistungserbringer ohne es überprüft zu haben davon ausgehen, dass für Kinder oder Schwangerschaften dynamische Ordner noch fehlen.

Hinweis: In seltenen Fällen werden im vorliegenden Dokument Anforderungen formuliert, die Felder zu Pflichtfeldern erklären, auch wenn sie im Datenmodell [gemSpec_DM_ePA#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] noch als optional [0..1] gekennzeichnet sind. In diesen Fällen wird eine Verschärfung der Prüfpflichten des Aktensystems erst noch eingeführt. Sobald die Kardinalität [1..1] festgeschrieben ist, muss das Aktensystem abweichende Requests abweisen. 

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

Eine entsprechende Absprache zwischen LEI und Versichertem muss nicht zwangsläufig explizit für jedes einzelne Dokument getroffen werden, sondern kann auch im Vorfeld stattfinden, z. B. über eine Vereinbarung über die Vertraulichkeitsstufe von bestimmten Dokumententypen oder ähnliche Mechanismen. 

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

Ob das U-Heft in die Akte des Kindes oder der gesetzlichen Vertreter eingestellt werden soll, regeln fachlichen Vorgaben in [KBV-UHeft]. Die technische Lösung der ePA2 ist für das U-Heft hinsichtlich der zu wählenden Akte flexibel.

Der errechnete Entbindungstermin im mothersrecord 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.

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

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_DM_ePA#A_14762* wird die Softwarekomponente eines Geräts als Nachname und ggf. als Vorname(n) eingetragen.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY

5.2.1.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente einstellen sind:

Vorbedingung:

• Ermittelter RecordIdentifier
• Das einzustellende Dokument sollte mit dem Versicherten besprochen sein
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Auswahl der RecordIdentifier
• 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.

Beispiel #: Bsp_ILF_ePA_ProvideAndRegisterDocumentSetRequest 

XDS-Option „Document Replacement“ - Ersetzen eines existierenden Dokuments

Ein eingestelltes Dokument kann auch ein existierendes Dokument ersetzen. Dies erfolgt durch Verwendung der „Document Replacement“-Option. 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“-Assoziation miteinander verbunden, so dass nach dem Einstellen erkennbar ist, dass das neue Dokument das alte ersetzt. Lädt man erneut eine neue Fassung hoch, erhält man analog 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. Dies gilt insbesondere für Dokumente, bei denen es zu jedem Zeitpunkt nur eine einzige gültige Dokumentenversion gibt, etwa für den Notfalldatensatz, den elektronischen Medikationsplan und den Datensatz persönliche Erklärungen.

Durch Setzen von Metadaten Dokumente werden gemäß gemSpec_DM_ePA#A_19388-* je unterschiedlichen Foldern zugeordnet. Beim Hochladen eines Dokumentes mittels DocumentRepository_ProvideAndRegisterDocumentSet-b bei Nutzung der RPLC-Option gilt es zu verhindern, dass ein Dokument beim nachfolgenden Hochladen eine andere Folderzuordnung erhält als beim initialen Hochladen. Eine Änderung der Folderzuordnung hätte Einfluss auf die Freigabeentscheidung des Versicherten. Die vollständige Liste der Dokumenten-Kategorien, wie sie dem Versicherten am Kartenterminal bei der Ad-Hoc-Berechtigung angezeigt werden, findet sich in [gemSpec_FM_ePA#Tab_FM_ePA_042 - Mapping von DocumentCategoryEnum auf Anzeigetext am Kartenterminal].

Korrekturen an den genannten Metadaten müssen durch Löschen und Neueinstellung des Dokumentes realisiert werden.

5.2.1.3 Nutzung

Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (Kennzeichnung über entsprechende Auswahl aus SubmissionSet.AuthorRole, siehe [gemSpec_DM_ePA#2.1.4.1], 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.

Beispiel #: Bsp_ILF_ePA_ProvideAndRegisterDocumentSetResponse 

In [gemSpec_DM_ePA#A_14760] ist beschrieben, bei Einhaltung welcher Vorgaben konsistente Metadaten für das Einstellen des Dokumentes erzeugt werden können. 

Tabelle 19: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_einstellen

5.2.2 Dokumente suchen

Frau Gundlach berichtet Dr. Weber über den Arztbrief, den ihr Radiologe vor wenigen Tagen in ihre Patientenakte geschrieben hat. Dr. Weber sieht in seiner lokalen Akte, dass die 7 Tage lang gültige Berechtigung auf die elektronische Akte zuzugreifen, noch nicht abgelaufen ist. Er sucht nach dem Arztbrief des Radiologen über dessen Namen in der ePA-Suchmaske des PVS. Sein PVS zeigt ihm Metadaten zum Arztbrief des Kollegen an.

Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer suchen aus [gemSysL_ePA#3.7.3, UC 4.3 - Dokumente durch einen Leistungserbringer suchen] wird Registry Stored Query [ITI-18] profiliert.

Tabelle 20: Tab_ILF_ePA_IHE-Profilierung_ITI18

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

Um Dokumente suchen zu können, brauchen Leistungserbringer nicht zu wissen, welche Art Berechtigung sie erhalten haben (Zugriffsberechtigung auf LE-Dokumente, Versicherten-Dokumente oder mehrere dieser Dokumententypen). Die Suche erfolgt immer ausschließlich auf den berechtigungsgemäß tatsächlich zugänglichen Dokumenten, nie auf Dokumenten, für die keine Zugriffsberechtigung besteht. 

Zur Suche nach Dokumenten zu einem RecordIdentifier 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

Weitere für Suchstrategien geeignete Metadaten von Dokumenten (Metadaten) können [gemSpec_DM_ePA] entnommen werden. Sie beziehen sich vor allem auf Informationen der Dokumentenverwaltung, weniger auf den (medizinischen) Inhalt der Dokumente.

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

5.2.2.1 Schnittstelle

Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRegistry)die Operation DocumentRegistry_RegistryStoredQuery an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-18] folgt und die Rolle eines IHE DocumentRegistry gegenüber dem PS übernimmt.

Tabelle 21: Tab_ILF_ePA_Operation_Dokument_suchen

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.

5.2.2.2 Umsetzung

Die Umsetzung der Suchen 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.

Tabelle 22: Tab_ILF_ePA_FindDocuments_Pflichtfelder

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

Die Aktivitäten des Anwendungsfalles Dokumente suchen sind:

Vorbedingung:

• Ermittelter RecordIdentifier
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen

Auslöser:

• Nutzerinteraktion
• anlassbezogene Suche

Aktivitäten:

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

Resultat:

• Ergebnismeldung
• Dokumenten-UUID-Liste (XDSDocumentEntry_uniqueId)

5.2.2.3 Nutzung

Beispiel #:Bsp_ILF_ePA_Request_AdhocQuery 

Das PS soll Stored Query IDs der Tab_ILF_ePA_StoredQueries gemäß [ITI-18#3.18.4.1.2.4] verwenden.

Tabelle 23: Tab_ILF_ePA_StoredQueries

Tabelle 24: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen

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

Filtern

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

5.2.3 Dokumente laden

Dr. Weber erkennt anhand der Metadaten aus seiner Dokumentensuche, dass in der Akte von Frau Gundlach ein Arztbrief im eArztbrief-Format enthalten ist. Das PVS zeigt Dr. Weber an, dass dieses Dokumentenformat strukturiert in die lokale Patientenakte übernommen und dort verarbeitet werden kann. Dr. Weber wählt dieses Dokument aus den Suchergebnissen aus, lässt es sich anzeigen und speichert es in seine lokale Patientenakte.

Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer anzeigen aus [gemSysL_ePA#3.7.9, UC 4.9 - Dokumente durch einen Leistungserbringer anzeigen] wird Retrieve Document Set [ITI-43] profiliert.

Tabelle 25: Tab_ILF_ePA_IHE-Profilierung_ITI43

Das Fachmodul stellt kein Integrated Document Source/Repository und keine On-Demand Document Source dar.

Das Anzeigen von Dokumenten beinhaltet auch das Anzeigen der Metadaten des Dokumentes.

Das Anzeigen ist nicht zwingend mit dem persistenten Abspeichern des Dokumentes verbunden.

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.

Es lassen sich nur solche Dokumente laden, für welche die LEI über eine Berechtigung verfügt.

5.2.3.1 Schnittstelle

Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRepository)die Operation RetrieveDocumentSet an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-43] folgt und die Rolle eines IHE ITI DocumentRepository gegenüber dem PS übernimmt.

Tabelle 26: Tab_ILF_ePA_Operation_Dokumente_anzeigen

5.2.3.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Dokumente anzeigen sind:

Vorbedingung:

• Ermittelter RecordIdentifier
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen
• XDSDocumentEntry_uniqueId (DocumentEntry.uniqueId) bekannt

Auslöser:

• Fachliches Erfordernis
• Nutzerinteraktion

Aktivitäten:

• Auswahl RecordIdentifier, ggf. anhand von Dokument-Metadaten 
• 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

Beispiel #: Bsp_ILF_ePA_RetrieveDocumentSetRequest

Für den Beispiel-Request 6 ist ein passender Anhang mit zu versenden. 

Beispiel #: Bsp_ILF_ePA_RetrieveDocumentSetResponse 

5.2.3.3 Nutzung

Die Retrieve Document Set Request Message muss mindestens eine DocumentUniqueID enthalten.

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

Dokumente werden in das ePA-Aktensystem Ende-zu-Ende verschlüsselt eingestellt. Dadurch können die Dokumente nicht an zentraler Stelle auf mögliche Schadsoftware geprüft werden. Eine Absicherung gegen mögliche Schadsoftware in heruntergeladenen Dokumenten muss im Primärsystem 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. 

Ein Client darf das Dokument nur dann als Datei behandeln, wenn es mit scheme = file ausgezeichnet ist, z.B. file:///c:/path/to/file.txt.

5.2.4 Dokumente löschen

Dr. Weber stellt fest, dass Frau Gundlach keine Medikamente mehr benötigt, setzt diese ab und löscht in Absprache mit ihr den elektronischen Medikationsplan aus ihrer Akte. Frau Gundlach hat kein Interesse daran, überholte Versionen des eMP in der ePA zu archivieren. 

Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer löschen aus [gemSysL_ePA#3.7.7, UC 4.7 - Dokumente durch einen Leistungserbringer löschen] wird Remove Metadata [ITI-62] profiliert.

Das Löschen eines Dokumentes aus einer ePA wird als ein strukturierter Anwendungsfall realisiert, dem unmittelbar ein Suchen des Dokumentes vorhergeht, so dass vom Fachmodul eine Aktensession eröffnet wurde, die vom Löschen nachgenutzt wird. 

Tabelle 27: Tab_ILF_ePA_IHE-Profilierung_ITI86

Ein LE kann alle Dokumente in Rücksprache mit dem Versicherten löschen, für die er Zugriffsrechte gemäß Tab_ILF_ePA_Zugriffsberechtigungen erhalten hat.

Der Aktenanbieter löscht mit den Dokumenten auch die Metadaten des Dokumentes.

Für das nach der Löschung des Dokumentes in der ePA gegebenenfalls in der Primärdokumentation des Leistungserbringers verbleibende Dokument sind die in Kap. 7.1 aufgeführten Empfehlungen zur Archivierung zu beachten.

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

5.2.4.1 Schnittstelle

Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRegistry)die Operation RemoveMetadata an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-62] folgt und die Rolle einer IHE DocumentAdministrator gegenüber dem PS übernimmt.

Tabelle 28: Tab_ILF_ePA_Operation_Dokumente_löschen

5.2.4.2 Umsetzung

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

Vorbedingung:

• Ermittelter RecordIdentifier
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen
• 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.

5.2.4.3 Nutzung

Der RMD-Request MUSS enthalten:

• Einen Content-Type HTTP header mit action Parameterwert "urn:ihe:iti:2010:DeleteDocumentSet" 
• Ein SOAP element <wsa:Action/> mit dem Wert "urn:ihe:iti:2010:DeleteDocumentSet"
• Ein SOAP element <soap12:Body/> mit dem Wert "<lcm:RemoveObjectsRequest>", der wiederum das Element <rim:ObjectRefList> enthält.
• <rim:ObjectRefList> MUSS für jedes zu löschende Objekt das Element <rim:ObjectRef> enthalten, in dessen Attribut "id" die DocumentEntry.entryUUID des zu löschende Objekt anzugeben ist 

5.2.5 Artefakte

5.2.5.1 Namensräume

Tabelle 29: Tab_ILF_ePA_Namensräume

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

5.2.6 Testunterstützung

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

5.3 Protokolle und Benachrichtigungen

5.3.1 Benachrichtigungen erhalten

Frau Gundlach hat Herrn Dr. Weber angekündigt, sie werde ihm in Kürze eine Zugriffsberechtigung von ihrem ePA-Frontend des Versicherten aus erteilen (ihre eGK führte sie für die Ad-hoc-Berechtigung nicht mit sich). Am folgenden Tag findet sie am Frontend des Versicherten ihren Hausarzt Dr. Weber über den Verzeichnisdienst und erteilt ihm eine Berechtigung für einen 7-Tage-Zugriff (Default-Zeitraum) auf ihre ePA. Ein Mitarbeiter von Dr. Weber öffnet die Primärakte von Frau Gundlach und erhält dabei die Benachrichtigung, dass Dr. Weber eine Zugriffsberechtigung erhalten hat und dass der Facharzt, zu dem er Frau Gundlach überwiesen hatte, einen eArztbrief in die Patientenakte eingestellt hat.

Zur Umsetzung des UseCases "Benachrichtigungen durch einen LE verwalten" aus [gemSysL_ePA#3.8.1] gibt es keine dedizierte Konnektorschnittstelle, auch nicht zur dedizierten Abfrage der Zugriffsrechte, über die ein LE verfügt. Stattdessen setzt sich das Funktionsmerkmal aus einer Reihe von Informationsquellen zusammen, die gesamthaft eine zuverlässige Informationsgrundlage bieten können, die jedoch keine Vollständigkeit beanspruchen kann. 

Die Benachrichtigungsverwaltung kann aus dem Vergleich der Werte des Zugriffsberechtigungsstatus und der Info-Quellen einen Vergleich über Änderungen ziehen und über diese Änderungen den LE geeignet informieren.

Benachrichtigungen über Änderungen an der ePA von Versicherten können aus folgenden Quellen stammen:

Tabelle 30: Tab_ILF_ePA_Benachrichtigungsquellen

Die Dokumentation durchgeführter Ad-hoc-Berechtigungen ergibt kein vollständiges Bild der erteilten Zugriffsberechtigungen, da Zugriffsberechtigungen für die LEI auch vom ePA-Frontend des Versicherten heraus erteilt werden können.

Handlungsanweisungen auf Basis der Informationen von Tab_ILF_ePA_Benachrichtigungs_InfoModell:

• Bei Nutzung der Benachrichtigungsfunktion werden ePA-Daten des Versicherten aktualisiert. Diese Aktualisierung SOLL ausschließlich aus der geöffneten Primärakte eines einzelnen Versicherten heraus erfolgen und nicht als Sammelverarbeitung über mehrere Akten gleichzeitig.
• An der Primärdokumentation eines Versicherten lokal gespeicherte Informationen zum Zugriffberechtigungsstatus MUSS das PS durch die Benachrichtigungsinformationen aktualisieren.
• Nach Ablauf der Zugriffsberechtigung MUSS die nicht mehr vorliegende Zugriffsberechtigung dem Anwender kenntlich gemacht werden, etwa anhand des ExpirationDate. 
• Falls die Benachrichtigungsverwaltung im PS Performance-Probleme verursacht, MUSS die Frequenz der Abfrage der  Benachrichtigungsquellen verringert werden oder es müssen Abfragen temporär ganz ausgeschaltet werden. 

Das Erhalten von Berechtigung ist die Nachbedingung der Anwendungsfälle "Berechtigung durch einen Versicherten vergeben" aus [gemSysL_ePA#3.6.1] und "Bestehende Berechtigungen durch einen Versicherten verwalten" [gemSysL_ePA#3.6.6].

5.3.1.1 Info-Quelle ePA-Administration

Im Rahmen der Ad-hoc-Berechtigung wird der RecordIdentifier bekannt, für den eine Zugriffsberechtigung erteilt wird, und das ExpirationDate der Zugriffsberechtigung (Quelle_Ad-hoc). Als alleinige Quelle dieser Informationen ist die Ad-hoc-Berechtigung u.a. deswegen nicht geeignet, weil der Versicherte vom ePA- Frontend des Versicherten ebenfalls Zugriffsberechtigungen erteilen kann.

5.3.1.2 Info-Quelle Berechtigungs-Abfrage

[Das Kapitel wurde ersetzt bzw. verschoben in Kapitel 5.1.4]

5.3.1.3 Info-Quelle Dokumentensuche

Die Dokumentensuche mit GetAll (Quelle_getAll) liefert die umfangreichsten Informationen für die Benachrichtigungsverwaltung, sollte aber aus Performancegründen nicht zu oft für Änderungsabfragen verwendet werden.

Das PS erhält nur Kenntnis von solchen Dokumenten, für die es berechtigt ist. Bei einer Änderung des Berechtigungstyps aus Tab_ILF_ePA_Zugriffsberechtigungen kann sich auch die Ergebnismenge des Querys ändern.

5.3.1.4 Info-Quelle Systeminformationsdienst

Wenn das Fachmodul ePA den Leistungserbringer gegenüber der Akte eines Versicherten erfolgreich autorisiert, erzeugt das Fachmodul ePA unter Verwendung des Systeminformationsdienstes des Konnektors ein Event mit dem in [gemSpec_FM_ePA#6.5.4] aufgeführten Inhalt ("Zugriffspolicy-Event"). Das Zugriffspolicy-Event gibt Auskunft über den RecordIdentifier, für den eine Zugriffsberechtigung erteilt wird, sowie über das ExpirationDate(Quelle_Event). 

Das Zugriffspolicy-Event liefert zum aktuellen Zeitpunkt korrekte Informationen und informiert somit über Aktualisierungen über Zugriffsberechtigungen, auch solche, die der Versicherte am ePA-Frontend des Versicherten vorgenommen hat. 

Das Zugriffspolicy-Event wird implizit bei jedem Aktenzugriff am Fachmodul ePA geworfen, der einen Zugriff auf den Berechtigungsschlüssel des LE erfordert und dabei mit einem Abruf des Schlüssels vom Aktensystem verbunden ist. 

5.3.1.5 Info-Quelle Fehlermeldung

5.3.1.6 Umsetzung

Die auch kombinierbaren Aktivitäten des Anwendungsfalles Benachrichtigungen erhalten sind:

Vorbedingung:

• Der Versicherte ist der Primärdokumentation im PS mit seiner Versicherten-ID und seinem RecordIdentifier bekannt

Auslöser:

• Die Primärdokumentation im PS zu dieser Versicherten-ID ist geöffnet
• anlassbezogene Abfrage oder Nutzerinteraktion

Aktivitäten:

• Auswerten der Auswahloptionen der Benachrichtigungsverwaltung
• Aufruf der für die Benachrichtigungsverwaltung hinterlegten StoredQueries auf die Akte des Versicherten
• Auswertung des Ergebnisses und ggf. Aktualisieren geänderter Werte in der Primärdokumentation

Resultat:

• Die aktualisierten Benachrichtigungsinformationen liegen zur Anzeige vor

Abbildung 11: Abb_ILF_ePA_Benachrichtigungen_GetAll_mit_Zugriffspolicy-Event

5.3.1.7 Nutzung

Der StoredQuery GetDocuments liefert aktuelle Metadaten für Dokumente, auf die ein LE zugriffsberechtigt ist. Durch Nutzung von GetALL [ITI-18#3.18.4.1.2.3.7.4] werden die Metadaten aller XDSSubmissionSets und XDSDocumentEntries eines Versicherten in einer Akte erfragt.

Suchstrategien aus der Schnittstelle Registry Stored Query können Info_Neu_Zugriff und Info_Ende_Zugriff aktualisieren helfen, beispielsweise:

• Benachrichtigungen über durch andere Akteure hinzugefügte Dokumente in einer Akte ab einem Stichtag
• Ermitteln von Änderungen durch andere Akteure an Dokumenten, die ein LE selbst eingestellt hat

Die Suche erfolgt auf den Metadaten von Dokumenten, nicht auf den Dokumenteninhalten.

5.3.2 Übertragungsprotokolle speichern

Das Primärsystem von Dr. Weber speichert die Übertragungsprotokolle zwischen dem Primärsystem und dem Konnektor, die darüber Auskunft geben, welche Aktenzugriffe er auf Frau Gundlachs ePA vollzogen hat.

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, nicht jedoch des Fachmoduls ePA oder anderer Komponenten der TI. 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 zur Speicherung 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.4 Status- und Fehlermeldungen

5.4.1 Statusinformationen

Tabelle 33: Tab_ILF_ePA_ErrorSeverity

[IHE-ITT-TF3] definiert, insbes. Table 4.2.4.2-3 und Table 4.2.4.2-4.

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

Tabelle 34: Tab_ILF_ePA_IHE_Success_and_Error_Reporting

5.4.2 Fehlerbehandlung

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 35: Tab_ILF_ePA_DifferenzFehlerhandling

Der Stacktrace der Fehler wird nicht an das PS weitergegeben.

5.4.2.1 TelematikError

Im Falle von Nicht-IHE-Fehlern erhält das PS vom Fachmodul ePA 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].

Die vom FM geworfenen Fehler sind gelistet in Tab_ILF_ePA_Fehlermeldungen des Fachmoduls ePA.

Daneben kann es Fehler des Basiskonnektors geben gemäß [gemSpec_Kon], s. Übersicht in [gemILF_PS#6.6]

5.4.2.2 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 eine 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, die nützlich sind, um den Nutzer über die Ursache des Fehlers hinzuweisen und daraus Handlungen abzuleiten, mit denen die Ursache des Fehlers behoben wird.

5.4.3 Handlungsempfehlungen in Fehlerfällen

Tabelle 36: Tab_ILF_ePA_Handlungsanweisung_im_Fehlerfall

5.4.4 Übersicht möglicher Fehlermeldungen

5.4.4.1 Fehlermeldungen aus dem Fachmodul ePA

Das Primärsystem können neben Fehlermeldungen des Basiskonnektors auch solche des Fachmoduls ePA erreichen. Hier eine Auswahl solcher Fehlermeldungen unter Hinweis auf Dokumente und Textstellen, in denen detaillierte Informationen zu finden sind. 

Eine Liste von Fehermeldungen, das Primärsystem über das ePA-Fachmodul erreichen, findet sich im gemSpec_FM_ePA in den Tabellen

• Tab_FM_ePA_011 Übergreifende Fehlermeldungen des Fachmoduls ePA
• Tab_FM_ePA_050 Wiederverwendete Fehlermeldungen aus der Konnektorspezifikation
• Tab_FM_ePA_051 Wiederverwendete Fehlermeldungen aus der Übergreifenden Spezifikation Operations und Maintenance

Darüber hinaus werden Fehlermeldungen, die spezifisch sind für Schnittstellenaufrufe am Fachmodul bei der Beschreibung der Schnittstellensignaturen von gemSpec_FM_ePA aufgelistet

• Tab_FM_ePA_032 Fehlermeldungen der Operation GetHomeCommunityID
• Tab_FM_ePA_041 Fehlermeldungen der Operation GetAuthorizationList
• Tab_FM_ePA_057 Fehlermeldungen der Operation GetAuthorizationState

Fehlermeldungen, die in der aktuelle Fachmodul-Spezifikation abgekündigt sind, ab in älteren Konnektoren noch auftreten können, sind in Tab_ILF_ePA_abgekündigte_Fehlermeldungen_des_Fachmoduls_ePA aufgelistet. 

Tabelle 37: Tab_ILF_ePA_abgekündigte_Fehlermeldungen_des_Fachmoduls_ePA

5.4.4.2 Fehlermeldungen aus dem Aktensystem ePA

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

Tabelle 38: Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem

6 Informationsmodell

6.1 Metadaten

Beim Einstellen von Dokumenten in die ePA werden die dazu genutzten SubmissionSets und die Dokumente selbst, durch Metadaten angereichert die für Such- und Filterfunktionen nachgenutzt werden können. Metadaten liegen sowohl am SubmissionSet, als auch am ePA-Dokument selbst vor. 

Das PS MUSS Metadaten unter Beachtung von [gemSpec_DM_ePA] möglichst automatisiert aus den Primärdaten der Versicherten übernehmen und erzeugen, ohne dass eine händische Eingabe von Metadaten zwingend erforderlich ist. Die manuelle Auszeichnung der Werte von Metadaten sollte auf ein Minimum begrenzt werden. 

Als Codierung wird UTF-8 verwendet.

Wenn Leistungserbringer Dokumente einstellen, bei denen sie nicht selbst der Autor sind, kann es passieren, dass die TelematikID 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 TelematikID nicht erfolgreich sein sollte.

6.2 Selbstauskunft

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

6.3 Wertebereiche

Erforderliche Wertebereiche (Value Sets) für ePA-Dokumente werden je nach Festlegung von [gemSpec_Voc_ePA] angegeben. 

Bei der Migration von Akten werden Dateinamen überschrieben. Beim Einstellen und Auslesen von Dokumenten sollen daher bevorzugt die Attribute title und mimetype genutzt werden. 

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.

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. 

6.4 Dokumentenformate der ePA

Falls Word- oder Openoffice-Dokumente in die ePA eingestellt werden sollen, müssen diese Dokumente vor ihrem Upload in ein PDF umgewandelt werden.

Das DPE-XML der eGK ist ein Beispiel eines XML-Dokumentes, dessen Metadaten gemäß [gemSpec_Voc_ePA] angereichert werden. 

Ein ContentProfile zu einem einzelnen Dokumentenformat bzw. Inhaltstypen eines Dokumentenformates beschreibt die Befüllung der Metadaten im Sinne einer Best Practice zur Vermeidung von Interoperabilitätsproblemen. 

Der DocumentEntry. formatCode von Dokumenten, bei denen es kein Contentprofile gibt, kann mit dem Wert  "urn:ihe:iti:xds:2017:mimeTypeSufficient" automatisch vorbelegt werden. Eine manuelle Auswahl des formatCodes soll vermieden werden. Dasselbe gilt für typeCode und classCode.  

6.4.1 ContentProfile Notfalldatensatz und Datensatz Persönliche Erklärungen

Der Notfalldatensatz, der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_NFDM#5.1.2] von der eGK gelesen oder er wird gemäß den im XML-Schema des Infomodells NFDM festgelegten Regeln und den darüber hinaus gehenden in [gemSpec_InfoNFDM] definierten Integritätsregeln erstellt, so dass der NFD gemäß [gemRL_QES_NFDM] signiert werden kann. 

Ein Datensatz persönliche Erklärungen (DPE), der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_NFDM#5.2.2] von der eGK gelesen oder er wird  gemäß  den  im XML-Schema  des  Infomodells  NFDM  festgelegten Regeln  und  den darüber hinaus gehenden in [gemSpec_InfoNFDM] definierten Integritätsregeln erstellt. 

Im <lcm:SubmitObjectsRequest> des <ProvideAndRegisterDocumentSetRequest> referenziert das <rim:ExtrinsicObject> die <rim:RegistryObjectList> die ID des angehängten NFD-Objektes bzw. DPE-Objektes.

Der Notfalldatensatz wird im Base64-Format, wie er aus der eGK ausgelesen wird, in das Element <xds:Document> eingefügt, das ein Attribut @id enthält, das dem rim:ExtrinsicObject/@id übereinstimmt.

6.4.2 ContentProfile elektronischer Medikationsplan

Der elektronische Medikationsplan, der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_AMTS] von der eGK gelesen oder er wird gemäß den im XML-Schema des Infomodells eMP/AMTS festgelegten Regeln und den darüber hinaus gehenden in [gemSpec_Info_AMTS] definierten Integritätsregeln erstellt, so dass der eMP durch das PS gemäß [gemILF_PS_AMTS] zum Einstellen des eMP in die ePA vorbereitet ist. Die Einwilligung in die Nutzung des eMP wird nicht in der ePA gespeichert.

Tabelle 40: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMP

6.4.3 ContentProfile Arztbrief nach § 291f

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 § 291f 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 12: Abb_ILF_ePA_eAB-XML-Containerformat

6.4.4 Daten digitaler Gesundheitsanwendungen

Daten digitaler Gesundheitsanwendungen (DiGA) liegen in interoperablen Formaten vor, die den Festlegungen in [gemSpec_DM_ePA] und falls vorhanden, Vorgaben aus [KBV Portal] folgen. 

Nur digitale Gesundheitsanwendungen in der Rolle von Primärsystemen (DiGA-PS) können berechtigt werden, DiGA-Daten in für jeden Versicherten eindeutige Folder einzustellen. Andere Rechte auf Daten der Kategorie 9 bzw. DiGA können ihnen nicht eingeräumt werden.

Primärsysteme der Leistungserbringer können berechtigt werden, DiGA-Daten, d.h. Daten der Kategorie 9 bzw. "diga" zu lesen. Andere Rechte auf Daten der Kategorie 9 bzw. "diga" können ihnen nicht eingeräumt werden.

Das DiGA-PS hat zwei IHE-konforme Optionen zur Bereitstellung von Daten in die ePA: Einstellen neuer Dokumente oder Replacement bestehender Dokumente.

Der Inhalt eines DiGA-Ordners wird durch Folder.title beschrieben. Dieses Feld wird vom Aktensystem belegt. Das PS kann unter den freigegebenen DiGA-Ordnern einen bestimmten Ordner über Folder.title suchen, aber auch über Folder.uniqueID. Einzelne DiGA-Dokumente, die durch ein Update fortgeschrieben werden, bleiben unter der einmal verwendeten DocumentEntry.entryUUID dauerhaft auffindbar.

6.4.5 Strukturierte Dokumente

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

Zum Laden, Suchen und Einstellen von strukturierten Dokumenten gelten die Anwendungsfälle zum Laden, Suchen, Einstellen und Löschen von Dokumenten. Es kommen gemäß [gemSpec_DM] weitere Kriterien zur Aufbereitung einer Sammlung hinzu. Besteht der Bedarf nach mehreren Sammlungen des gleichen Typs (Beispiel Mutterpass) 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. Es wird empfohlen für den Titel des Ordners einen sprechenden Namen zu finden. Dadurch kann bei der Suche nach Sammlungen bereits durch den Titel auf deren Inhalt geschlossen werden. Da das Aktensystem dynamisch angelegte  Ordner löscht, wenn diese keine Dokumente mehr enthalten, ist das Löschen der Ordner durch das Primärsystem nicht erforderlich.

Die Erteilung der Berechtigung für eine Sammlung kann im Primärsystem im Rahmen der Berechtigung für eine Dokumentenkategorie (soweit für Pass definiert) erfolgen.

Die Liste der strukturierten Dokumente wird sich im Laufe der Zeit erweitern. Die KBV liefert zu neu entwickelten MIOs Informationen über die interne Datenstruktur und fachliche Hintergründe, die gematik veröffentlicht Informationen darüber, um welchen Sammlungstyp es sich bei dem neuen strukturierten Dokument handelt, und welche Metadaten dieses strukturierte Dokument identifizieren.

Die Berechtigung zukünftiger strukturierter Dokumente wird über das Freigeben gemäß Vertraulichkeitsstufe geregelt, d.h. wenn ein neues, bisher noch nicht bekanntes strukturiertes Dokument vom Versicherten mit der Vertraulichkeitsstufe "normal" eingestellt wird, kann es über die genannte Vertraulichkeitsstufe für einen LE freigegeben werden.

6.4.5.1 Signatur für strukturierte Dokumentenformate der ePA

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

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

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, z.B. Dokument elektronische Verordnungen/Verordnungsdatensatz, Impfpassdokument.
2. Primärsystem serialisiert die Daten zu einer Data to be Signed Representation (DTBSR).
3. Primärsystem übermittelt DTBSR an den Konnektor zur Signaturerstellung (Aufruf der Operation SignDocument gemäß [gemILF_PS]).
4. Konnektor erzeugt eine CADES Enveloping Signatur.
5. Signiertes Objekt enthält sowohl die Signatur als auch die ursprünglichen DTBSR bitgenau und in einem binären ASN.1 Format (PKCS#7).
6. Konnektor übermittelt signiertes Objekt an das Primärsystem.
7. Primärsystem stellt über das Funktionsmerkmal "Dokumente einstellen" (siehe Kap.5.2.1) 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. Primärsystem lädt Dokument aus dem ePA-Aktensystem.
2. Primärsystem erkennt, dass es sich dabei um ein medizinisches Objekt im Format im PKCS#7 handelt (DocumentEntry.mimetype = application/pkcs7-mime).
3. Primärsystem übermittelt das signierte Objekt an den Konnektor zur Signaturprüfung (Aufruf der Operation VerifyDocument [gemILF_PS]).
4. Konnektor prüft die Signatur.
5. 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.

Ein vom Arzt mit QES-signiertes E-Rezept darf nicht in den Besitz des Versicherten gelangen und wird ausschließlich im E-Rezept-Server gespeichert. Deshalb wird begrifflich unterschieden zwischen E-Rezept und Elektronische Verordnungen/Verordnungsdatensatz. Elektronische Verordnungen/Verordnungsdatensatz ist nicht QES signiert und kann in die Akte des Versicherten eingestellt werden.

7 Ergänzende Funktionalitäten

7.1 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_DM_ePA#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] aufgelistet sind, soweit sie für den Verarbeitungskontext relevant sind.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. 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