Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme -

Elektronische Patientenakte (ePA)

    

     

      
Version
      
1.5.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
30.06.2020
     
     

      
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. Die gematik erstellt auch in Hinsicht auf die ePA eine Bestätigung über die Konformität des Primärsystems zur Konnektorschnittstelle aus. Bei Umsetzung der Anforderungen dieses Dokumentes erfüllt der PS-Hersteller die Anforderungen des Bestätigungsverfahrens.

Die Anforderungen des Dokumentes sind für Primärsystemhersteller, die keine Bestätigung auf Konformität der Konnektorschnittstelle durch die gematik benötigen informativ.

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.

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 des Produkttyps 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 zusammen arbeitet, 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

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

Tabelle 6: Tab_ILF_ePA_PHRManagementService

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. 

Zur Ermittlung der HomeCommunityID des Versicherten wird die Operation GetHomeCommunityID des PHRManagementService genutzt.

Für die Nutzung der ePA durch das Primärsystem ist das Vorliegen eines Identifikators für das Aktenkonto des Versicherten (RecordIdentifier) erforderlich. 

Fachliche Grundlage der Aktenzuordnung ist die Versicherten-ID des Versicherten. Jeder Versicherte hat zur selben Zeit nur ein einzelnes Aktenkonto. Unterschiedliche Versicherte können bei jeweils unterschiedlichen Aktenanbietern ihre Patientenakte hosten lassen. Die Abfrage der verschiedenen möglichen Anbieter übernimmt das Fachmodul für das PS. Die HomeCommunityId kann pro Versicherten über das Fachmodul ePA ermittelt werden. 

Jeder Versicherte verfügt über genau eine aktive Akte, auch während er ggf. den Aktenanbieter wechselt.

Wenn die Aktenzuordnung für einen Vertreter durchgeführt wird, muss der Vertreter der LEI hinreichend genau mitteilen, für welchen Versicherten er vertretungsberechtigt ist, damit für den Vertretenen der Aktenanbieter ermittelt werden kann. Aufgrund der vom Vertreter mitgeteilten Patientenidentifikationsmerkmale ermittelt die LEI die betroffene Primärakte und ermittelt den Aktenanbieter aus dieser Primärakte heraus. Durch das Starten des Anwendungsfalles aus dem Aktenkonto desjenigen heraus, der vertreten wird, wird dessen KVNR als InsurantID 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.

Das Resultat von Aktenanbieter ermitteln, die HomeCommunityId, wird als Teil des RecordIdentifiers verwendet, sowie separat als Wert bestimmter Metadatenfelder. Aufgrund der vielfachen Verwendung ist eine persistente Speicherung in der Primärdokumentation des Versicherten erforderlich. 

5.1.1.1 Schnittstelle

Tabelle 7: Tab_ILF_ePA_Operation_getHomeCommunityID

Abbildung 4: Abb_ILF_ePA_getHomeCommunityRequest

Abbildung 5: Abb_ILF_PS_ePA_getHomeCommunityResponse

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

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

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 9: 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 oder flexibel 1 bis 540 Tage) (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 grobgranulare Festlegungen (AuthorizationConfidentiality) oder mittelgranulare Festlegungen (DocumentCategoryList). Feingranulare Berechtigungen, d.h. Zugriffsberechtigungen, die sich auf einzelne ausgewählte Dokumente beziehen, können am PS nicht gesetzt werden. Feingranulare 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 einen 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 oder flexibel 1 bis 540 Tage);
• 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.2 Dokumentenmanagement

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

Tabelle 11: Tab_ILF_ePA_PHRService

Name	PHRService [gemSpec_FM_ePA#7.1]
Version	2.0.0
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
	DocumentRepository_RemoveDocuments	Profilierung von [ITI-86], s. Kap. 5.2.5
WSDL	gemäß: PHRService.wsdl  IHE XCA-Profil [IHE-ITI-TF1] IHE XDR-Profil [IHE-ITI-TF1] IHE RMD-Profil [IHE-ITI-RMD]
XML-Schema	PHRService.xsd

Tabelle 12: Tab_ILF_ePA_DM_Profilierung

Tabelle 13: 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 14: 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 16: 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.

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 17: Tab_ILF_ePA_Operation_Dokument_einstellen

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

Die uniqueId des Folders kann z. B. über die Suche "FindFolders" mit entsprechendem Filter auf Folder.codeList ermittelt werden.

Ein einzelnes Dokument kann auf Wunsch mehreren Unterkategorien zugeordnet 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).

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:

• Im Erfolgsfall gibt die Response die UUID des eingestellten Dokumentes zurück

Beispiel #: Bsp_ILF_ePA_SOAP-Body_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).

XDS-Option „Document Addendum“ - Verlinken von Dokumenten

Wenn Pässe aus mehreren Passdokumenten unterschiedlicher Dokumentenformate bestehen, wie es z. B. für den Mutterpass vorgesehen ist, ist es sinnvoll, die einzelnen Passdokumente als sich ergänzende Teile eines Ganzen zu kennzeichnen. Genau dies ist möglich über die XDS-Option „Document Addendum“. Sie ermöglicht es, ein Dokument durch ein neues Dokument zu ergänzen. Der Vorgang ist ähnlich wie beim Document Replacement. Abweichend davon sind am Ende beide Dokumente im Status Approved und werden über eine „Append“-Assoziation (urn:ihe:iti:2007:AssociationType:APND) miteinander verbunden.

In ePA 2.0 ist die „Append“-Association ausschließlich für den Mutterpass und für das Untersuchungsheft für Kinder erlaubt.

5.2.1.3 Nutzung

Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (ConfidentialityCode="LEI",SubmissionSet.AuthorRole="8" und dem konfigurierten XDSDocumentEntry.healthcareFacilityTypeCode) kategorisiert, um sie von Versicherten-Dokumenten (ConfidentialityCode="PAT",SubmissionSet. AuthorRole="102" und XDSDocumentEntry.healthcareFacilityTypeCode="KTR") zu unterscheiden, s. [gemSpec_DM_ePA#2.1.4.2]. 

Beispiel #: Bsp_ILF_ePA_ProvideAndRegisterDocumentSetRequest

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 #: 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 18: 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 einer RecordIdentifier sind u.a. folgende Filterfunktionen möglich:

• kein Filter
• Zeitintervall
• Dokumentenkategorie, darunter auch Dokumentenkategorie 1a (Suche über Folder)
• 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.

Ein Filtern über Ordner ist nicht möglich, s. Tab_ILF_ePA_Einschränkungen_auf_XDS.b.

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

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 20: 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_SOAPHeader

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

Tabelle 21: Tab_ILF_ePA_StoredQueries

Als Ergebnis der Suche mit confidentialityCode="LEÄ" wird das als LE-äquivalent gekennzeichnete Dokument zusätzlich sichtbar für LE, die nur eine Berechtigung auf von LEI eingestellte Dokumente haben und es bleibt sichtbar für LE, die eine Berechtigung auf vom Versicherten oder von der Krankenkasse eingestellte Dokumente haben.

Das PS kann mittels RegistryStoredQuery mit XDSDocumentEntry.confidentialityCode= "PAT" gezielt nach den von Versicherten eingestellten Dokumente suchen, falls es dazu berechtigt ist. 

Beispiel getDocuments

Beispiel #: Bsp_ILF_ePA_Request_getDocuments

Beispiel #: Bsp_ILF_ePA_Response_getDocuments

Tabelle 22: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen

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 23: 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 24: 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

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.

5.2.4 Dokumente löschen

Dr. Weber erstellt einen neuen Notfalldatensatz für Frau Gundlach und löscht in Absprache mit ihr den alten NFD aus ihrer Akte, um den aktualisierten Notfalldatensatz in die Akte einzustellen. Frau Gundlach hat kein Interesse daran, überholte Versionen ihrer Notfalldaten 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 and Documents [ITI-86] 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 25: 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.

5.2.4.1 Schnittstelle

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

Tabelle 26: 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_uniqueId

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Auswahl des Dokumentes bzw. der Dokumente unter Verwendung der XDSDocumentEntry_uniqueId
• 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:2017:RemoveDocuments" 
• Ein SOAP element <wsa:Action/> mit dem Wert "urn:ihe:iti:2017:RemoveDocuments"
• Ein SOAP element <soap12:Body/> mit dem Wert "<rmd:RemoveDocumentsRequest/> "  

Der RemoveDocumentsRequest MUSS als Liste der Löschaufträge pro <rmd:RemoveDocumentsRequest/> enthalten:

• DocumentRequest.RepositoryUniqueID (s. Tab_ILF_ePA_Zugriffsinformation_Werte)
• DocumentUniqueID aus einem vorangegangenen Ergebnis von [ITI-41], [ITI-18]

Beispiel #: Bsp_ILF_ePA_RemoveDocumentsRequest

Beispiel #: Bsp_ILF_ePA_RemoveDocumentsResponse

5.2.5 Artefakte

5.2.5.1 Namensräume

Tabelle 27: 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 eines Versicherten können aus folgenden Quellen stammen:

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

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.

Nutzungsvoraussetzungen:

• Eine dem Aufrufkontext zugeordnete SM-B.

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

Falls die AuthorizationList Versicherten-IDs enthält, die dem Primärsystem nicht bekannt sind, so dass sie keiner Primärdokumentation und keinem bestehenden oder vergangenen Behandlungskontext entsprechen, so soll dieser RecordIdentifier verworfen werden. Falls dieser noch unbekannte Versicherte zu einem späteren Zeitpunkt eine neue Primärakte im PS erhält, kann sein RecordIdentifier mit getHomeCommunityID ermittelt werden. Die Informationen der Tab_ILF_ePA_Benachrichtigungs_InfoModell werden dann wie bei Quelle_getAll beschrieben ermittelt, wo implizit auch Quelle_Event ausgewertet werden kann, um die Benachrichtigungsinformationen zu vervollständigen. 

Das PS erhält Kenntnis vom Aktenanbieterwechsel eines Versicherten über GetAuthorizationList. 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.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, z.B. wie bei Quelle_getAll beschrieben. 

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

Beispiel #: Bsp_ILF_ePA_Request_GetAll_urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3

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 32: 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 33: 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 34: 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 und severity zurückgegeben.

5.4.3 Handlungs-Empfehlungen in Fehlerfällen

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:

Tabelle 36: Tab_ILF_ePA_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 37: 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.

6.2 Wertebereiche

Erforderliche Wertebereiche (Value Sets) für ePA-Dokumente werden je nach Festlegung von [gemSpec_DM_ePA] in [IHE-ITI-VS] angegeben. 

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.3 Dokumentenformate der ePA

Tabelle 39: Tab_ILF_ePA_Dokumentenformate (beispielhaft)

Das DPE-XML der eGK ist ein Beispiel eines XML-Dokumentes, dessen Metadaten gemäß [gemSpec_DM_ePA] in [IHE-ITI-VS] 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.  

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

eMP-spezifische Metadatenbefüllung
Das PS MUSS die Werte der SubmissionSet-Metadaten für den elektronischen Medikationsplan gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen und dabei die eMP-spezifischen Implementierungshinweise aus Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMP sowie die ValueSetDefinition aus  [IHE-ITI-VS] beachten. Datenquellen sind Daten des Einstellers oder eMP-Daten der eGK. 

Tabelle 41: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMP

6.3.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 aus  PHRManagementService.xsd) zurückgegriffen. 

Abbildung 11: Abb_ILF_ePA_eAB-XML-Containerformat

6.3.4 Weitere strukturierte Dokumentenformate der ePA

Weitere strukturierte Dokumentenformate der ePA sind Pässe, elektronische Verordnungen/den Verordnungsdatensatz und Arbeitsunfähigkeitsbescheinigung gemäß [gemSpec_DM_ePA#2.1.4.1.1].

Ein Medizinisches Informationsobjekt (MIO) besteht aus Einzeleinträgen, die gesamthaft das MIO bilden. Für die Einzeleinträge gilt, was für das gesamte MIO gilt:

• es gibt jeweils identifizierende Metadaten (z.B. formatCode);
• Einzeleinträge können in die ePA geladen werden;
• Einzeleinträge können (optional) beim Laden in die ePA signiert werden;
• beim Herunterladen aus der ePA kann eine Signaturprüfung durchgeführt werden;
• Einzeleinträge können in der ePA gesucht werden;
• Einzeleinträge können in der ePA gelöscht werden.

Die Berechtigung für ein MIO kann immer nur gesamthaft verwaltet werden, d.h. die Erteilung und Löschung einer Berechtigung gilt gesamthaft für das ganze MIO und damit implizit auch für die Einzeleinträge. Die Berechtigung für Einzeleinträge können jedoch nicht separiert vom Gesamt-MIO verwaltet werden.

6.3.4.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 für Passdokumente, elektronische Verordnungen/Verordnungsdatensatz und Arbeitsunfähigkeitsbescheinigung 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. elektronische Verordnungen/Verordnungsdatensatz oder Daten von Medizinischen Informationsobjekten (MIO).
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