gemILF_PS_ePA_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme -

Elektronische Patientenakte (ePA)

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
18.12.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_ePA
     
    

Dokumentinformationen

Änderungen zur Vorversion

Bei dem Dokument handelt es sich um ein neu-erstelltes Dokument.

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_Fachanwendung_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-Profile

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 (Berechtigungen aktualisieren).

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, etwa die Ad-hoc-Berechtigung auf LE-Dokumente (CareProviderWithoutInsurantDocuments)
• 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

Tabelle 4: Tab_ILF_ePA_DokumentenZugriffsTypen 

5 Funktionsmerkmale

Das Aktenkonto eines Versicherten kann sowohl beim LE, als auch am 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 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 Frontend des Versicherten nicht mehr existiert, ist eine erneute Berechtigungsvergabe erforderlich, s. [gemSysL_Fachanwendung_ePA#2.5.2]. 

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

Das PS kann Berechtigungen aktualisieren, wenn Leistungserbringerinstitutionen neue SM-Bs verwenden wollen, oder SM-Bs außer Verkehr nehmen wollen.

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 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 Frontend des Versicherten liefert [gemSysL_Fachanwendung_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 und RegisterSMB 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. 

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 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 Patientenakteabgeschlossen. 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_Fachanwendung_ePA#3.5.1, UC 2.1 - Aktenkonto einrichten, Schritt 2 - Aktivierung in der Umgebung des Leistungserbringers] wird die Operation ActivateAccount des PHRManagementService genutzt.

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
• In einem der Anwendungsfälle des PHRService ist der Fehler 7208 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

Es ist nicht möglich automatisiert im Vorfeld zu prüfen, ob eine Aktenaktivierung noch aussteht. Der Anwendungsfall startet mit der Information des Versicherten, die Aktenaktivierung bereits vorbereitet zu haben, oder mit einem spezifisch auf die Notwendigkeit einer Aktenkontoaktivierung hinweisenden Fehler 7208.

5.1.3 Ad-hoc-Berechtigung erteilen

Frau Gundlach erteilt Herrn Dr. Weber und seiner Hausarztpraxis Zugriff auf ihre ePA. Sie überreicht ihre eGK der Medizinischen Fachangestellte (MFA) von Dr. Weber am Empfangstresen. Die Medizinischen Fachangestellte (MFA) 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, 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_Fachanwendung_ePA#3.6.7, UC 3.7 - Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern] wird die Operation RequestFacilityAuthorization des PHRManagementService verwendet.

Die Rolle des Versicherten kann 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). 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

authorizationConfiguration

Dieser Eingabeparameter beschreibt 

• Art des Zugriffs: AuthorizationConfiguration gemäß Tab_ILF_ePA_DokumentenZugriffsTypen
• Zugriffsberechtigungs-Endedatum. ExpirationDate: Das aus der Dauer des Zugriffs (1 Tag, 28 Tage, 18 Monate oder flexibel 1 bis 540 Tage). Default: 28 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

Der Default-Wert KANN durch den LE übersteuert werden. 

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
  
• • Typen von Dokumenten, auf die der Versicherte Zugriff gewährt (LE-Dokumente und Versicherten-Dokumente || Nur LE-Dokumente [default])
  • des Zeitraumes, für die er dem LE Zugriff auf seine Akte gewährt (1 Tag, 28 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 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.4 Berechtigungen aktualisieren

Zur Umsetzung des Anwendungsfalles Berechtigungen für SMC-B durch einen Leistungserbringer aktualisieren aus  [gemSysL_Fachanwendung_ePA#3.4.4, UC 1.4 - Berechtigungen für SMC-Bs durch einen Leistungserbringer aktualisieren] wird die Operation RegisterSMB des PHRManagementService genutzt.

Dabei wird ein Berechtigungserhalt umgesetzt [gemSysL_Fachanwendung_ePA#2.2.2]. Beim Aktualisieren von Berechtigungen werden Aktensystemen neue SM-Bs bekannt gemacht und alte abgekündigt.

Nutzungsszenarien für den Anwendungsfall sind:

• Die LEI möchte neben einer bereits verwendeten SM-B eine zusätzliche SM-B für die Aktenzugriffe einsetzen, z.B. für eine Ersatz-SM-B
• Verlust einer SM-B in der LEI, in der mehrere SM-Bs berechtigt sind
• SM-B wird außer Betrieb genommen und ersetzt.

Für den Anwendungsfall der Auflösung einer BAG und Weiterarbeit in getrennten Einzelpraxen als jeweils "neue Institution" gilt, dass die SMC-B des ursprünglichen Antragstellers weitergenutzt werden kann, vgl. [gemKPT_PKI_TIP#2.8.2]. Hier ist die Nutzung von RegisterSMB nicht erforderlich: Der ursprüngliche Antragsteller der SM-B benutzt diese weiterhin, vorausgesetzt, er darf die Telematik-ID weiter verwenden. 

Falls in einer Gemeinschaftspraxis zu einer bestehenden Telematik-ID eine neue SM-B eingesetzt werden soll (z.B. Ersatz-SMC-B), kann mit RegisterSMB durch Umschlüsselung die bestehende Berechtigung auf die neue SM-B übertragen werden. 

LE-Institutionen können im Falle größerer Institutionen über mehrere Telematik-IDs verfügen. Ein Wechsel der Berechtigung von einer Telematik-ID auf die nächste ist über RegisterSMB nicht möglich, auch wenn die Telematik-IDs zur selben Institution gehören oder zugehörige SM-Bs von derselben Person beantragt wurden. Auch in diesem Fall wird jeder Telematik-ID eine separate Berechtigung zugeordnet.

RegisterSMB ist eine Schnittstelle, in der für SM-Bs technische Zugriffsberechtigungen verwaltet werden. Die Mandantenverwaltung in der LEI ist nur insoweit betroffen, als dass neue SM-Bs wiederum auch Mandanten zugeordnet werden müssen.

5.1.4.1 Schnittstelle

Nutzungsvoraussetzungen:

• Für die Telematik-ID sind im VZD alle zugeordneten SM-Bs eingetragen, für welche eine Aktualisierung der Berechtigung erfolgen soll;
• Eine Liste der RecordIdentifier liegt im PS vor, zu denen Zugriffsberechtigungen vorliegen, ermittelbar am noch nicht abgelaufenen ExpirationDate.

Tabelle 11: Tab_ILF_ePA_Operation_RegisterSMB

Abbildung 9: Abb_ILF_ePA_Request_RegisterSMB

Abbildung 10: Abb_ILF_ePA_Response_RegisterSMB

5.1.4.2 Umsetzung

Die Operation RegisterSMB führt eine Umverschlüsselung für die Akten durch, die mit knownRecords angegeben werden. RegisterSMB bezieht sich auf die über den VZD einzelnen Telematik-IDs zugeordneten Berechtigungen bzw. Verschlüsselungsschlüsseln, und hilft dabei, für jede SM-B einer bestimmten Telematik-ID genau diese vergebenen Berechtigungen von alten SM-Bs auf neue SM-Bs zu aktualisieren. Die neuen SM-Bs werden vom Fachmodul über den VZD ermittelt. 

Die Liste KnownRecords bildet das PS anhand der Feststellung der aktuell vorliegenden Zugriffsberechtigungen durch Auflistung der so ermittelten RecordIdentifier. Wenn diese Liste länger als 50 Einträge ist, wird sie in mehrere kleinere Listen aufgeteilt und RegisterSMB entsprechend öfter aufgerufen.

Die Aktivitäten des Anwendungsfalles Berechtigung aktualisieren sind:

Vorbedingung:

• zu einer Telematik-ID gibt es neben der einen, bereits verwendeten SM-B weitere SM-Bs, für die im VZD zur Telematik-ID die ENC-Zertifikate der aktuellen SM-B eingetragen sind
• Ermittelte RecordIdentifier liegen vor;
• Zusammenstellung einer Liste von RecordIdentifier, für die Berechtigung noch nicht abgelaufen ist;
• Eine neue SM-B zur Telematik-ID ist in den VZD eingetragen worden, z.B. eine Ersatz-SMC-B;
• Die alte, bisher verwendete SM-B ist noch vorhanden;

Auslöser:

• Nutzerinteraktion

Aktivitäten:

• Zusammenstellung der Liste knownRecords, für die Zugriffsberechtigung vorliegt. Die Liste der RecordIdentifier wird im PS anhand der Primärdokumentation der Versicherten ermittelt. 
  
• Generierung und Versand der Nachricht;
• Auswertung des Ergebnisses

Resultat:

• Das bisherige verschlüsselte Schlüsselmaterial für berechtigte Aktensysteme ist durch ein „altes“ SM-B entschlüsselt worden und für alle aktuell gültigen, im VZD hinterlegten ENC-Zertifikate des SM-B der LEI neu verschlüsselt und im jeweiligen Aktensystem ersetzt worden .
• Das Fachmodul ist bei nachfolgend ausgeführten Anwendungsfällen des Aktenzugriffs in der Lage, Entschlüsselungen durchzuführen, weil der aktuell im Einsatz befindlichen SM-B zur Entschlüsselung eingesetzt werden kann.
• Für den Fall, dass einige Records aktualisiert wurden, andere jedoch nicht, soll für das Delta ein erneuter Aktualisierungsversuch durchgeführt werden. Wenn dieser ebenfalls scheitert, kann dies als Hinweis darauf genommen werden, dass die Berechtigung auf den Aktenzugriff vom Versicherten am Frontend des Versicherten entzogen wurde oder die Liste knownRecords aus anderen Gründen fehlerhaft erstellt wurde.

5.1.4.3 Nutzung

Die Nutzung von RegisterSMB ist für Szenarien vorgesehen, in denen für eine LEI mehrere SM-Bs im Verzeichnisdienst eingetragen sind. Daher kann es sinnvoll sein, zu überprüfen, wie viele SM-Bs im VZD eingetragen sind.

Umsetzungsmöglichkeiten:

• Das PS vergleicht die Ergebnisse der getCards-Abfrage [gemILF_PS#4.2.1.1] zu den verwendeten SM-Bs mit den Ergebnissen der LDAPv3-Suchanfrage am VZD (beschrieben in [gemILF_PS#4.5.3.2]).

Das Konfigurieren des Dienstverzeichnisdienstes liegt nicht im Aufgabenbereich des Primärsystems.

Bei Fehlermeldungen, denen zufolge Dokumente nicht entschlüsselt werden können, und die VZD-Einträge zur Telematik-ID der LE-Organisation aktualisiert wurden, kann ein Aufruf von RegisterSMB unter Angabe des RecordIdentifiers, bei dem der Fehler aufgetreten ist, verwendet werden, um die Berechtigungen zu aktualisieren und einen erneuten Leseversuch durchzuführen. 

Eine regelmäßige Nutzung der Benachrichtigungsverwaltung führt dazu, dass die Liste der RecordIdentifier, für die eine Zugriffsberechtigung besteht, weitgehend aktuell und korrekt gehalten werden kann.

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

Name	PHRService [gemSpec_FM_ePA#7.1]
Version	1.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.3.1
	DocumentRegistry_RegistryStoredQuery	Profilierung von [ITI-18], s. Kap. 5.3.2
	DocumentRepository_RetrieveDocumentSet	Profilierung von [ITI-43], s. Kap. 5.3.3
	UpdateResponder_RestrictedUpdateDocumentSet	Profilierung von [ITI-92], s. Kap. 5.3.4
	DocumentRepository_RemoveDocuments	Profilierung von [ITI-86], s. Kap. 5.3.5
WSDL	gemäß: PHRService.wsdl  IHE XCA-Profil [IHE-ITI-TF1] IHE XDR-Profil [IHE-ITI-TF1] IHE "Restricted Metadata Update"-Profil [ITI-92] 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 diejenige SM-B identifiziert, für die eine Autorisierung erstellt wurde, und diese SM-B durch PIN-Eingabe freigeschaltet wurde, s. [gemILF_PS#3.3].

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

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

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

Das PS soll die DocumentEntry.UniqueID als OID 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

5.2.1.3 Nutzung

Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (ConfidentialityCode="PN", AuthorRole="8") kategorisiert, um sie von Versicherten-Dokumenten (ConfidentialityCode="PR", AuthorRole="102") zu unterscheiden, s. [gemSpec_DM_ePA#2.1.4.2]. 

Beispiel #: Bsp_ILF_ePA_Request_FindDocuments_urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d

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 28 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_Fachanwendung_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 der 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
• Dokumententyp (z.B. LE-Dokument: DocumentEntry.ConfidentialityCode=PN)
• 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 21: Tab_ILF_ePA_Operation_Dokument_suchen

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_SOAPHeader

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

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

Beispiel getDocuments

Beispiel #: Bsp_ILF_ePA_Request_getDocuments_urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4

Beispiel #: Bsp_ILF_ePA_Response_getDocuments

Tabelle 24: 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_Fachanwendung_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.

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

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.

5.2.4 Umklassifizieren "äquivalent zu LE-Dokument"

Frau Gundlach hat einen Arztbrief eingescannt, den sie von einem Facharzt per Post erhalten hat. Beim Einstellen in die ePA am Frontend des Versicherten von Frau Weber ist das Dokument als Versichertendokument klassifiziert worden. Dr. Weber möchte kenntlich machen, dass dieser von Frau Gundlach eingestellte Arztbrief äquivalent ist zum selben Dokument, den der Facharzt selber in die Akte eingestellt hätte oder als Dokument, das ein LE hätte einstellen können. Dafür wählt er in seinem PVS am Dokument die Option aus "als LE-äquivalent kennzeichnen". Nun können auch andere berechtigte Leistungserbringer auf dieses Dokument zugreifen, die berechtigt sind, auf LE-Dokumente zuzugreifen. Beim Filtern auf LE-Dokumente erscheint dieses Dokument in den Suchergebnissen.

Zur Umsetzung des Anwendungsfalles Ändern einer Dokumentenklassifizierung durch einen Leistungserbringer aus [gemSysL_Fachanwendung_ePA#3.7.5, UC 4.5 - Ändern einer Dokumentenklassifizierung durch einen Leistungserbringer] wird Restricted Update Document Set [ITI-92] profiliert. 

Mit der Änderung der ePA-Klassifizierung eines Dokumentes ändern sich die Zugriffsregeln für ein Dokument nicht. Allerdings ändert sich die Menge der Dokumente, die im Metadatenfeld DocumentEntry.ConfidentialityCode gemäß [gemSpec_DM_ePA#2.1.4.2] mit Werten aus dem Codesystem gematik_ePA als LE(-äquivalente) Dokumente gefunden werden und daher 

• aufgrund der Zugriffsregel "darf auf LE-Dokumente zugreifen" zugreifbar sind;
• in Queries auf LE-Dokumente als LE-Dokument gefunden werden.

Tabelle 27: Tab_ILF_ePA_IHE-Profilierung_ITI92

5.2.4.1 Schnittstelle

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

Tabelle 28: Tab_ILF_ePA_Operation_Umklassifizieren

5.2.4.2 Umsetzung

Die Aktivitäten des Anwendungsfalles Umklassifizieren "äquivalent zu LE-Dokument" sind:

Vorbedingung:

• Ermittelter RecordIdentifier
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen

Auslöser:

• Nutzerinteraktion
  

Aktivitäten:

• Auswahl des Dokumentes, zu der die Dokumenten-ID bekannt ist.
• Generierung und Versand der Nachricht UpdateDocumentSet
• Auswertung des Ergebnisses 

Resultat:

• Metadaten der Dokumente haben sich geändert und sind als "Äquivalent zu LE-Dokument" gekennzeichnet, oder diese Klassifikation ist einem Dokument wieder entzogen worden.

5.2.4.3 Nutzung

Wurden durch Versicherte eingestellte Dokumente fälschlich als LE-äquivalentes Dokument klassifiziert (confidentialityCode="PN"), so kann RestrictedUpdateDocumentSet verwendet werden, um die Klassifikation des Versicherten-Dokumentes wieder rückgängig zu machen. Das Metadatenfeld DocumentEntry.ConfidentialityCode der Dokumente wird dabei  auf den Wert "PR" angepasst.

5.2.5 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_Fachanwendung_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 29: Tab_ILF_ePA_IHE-Profilierung_ITI86

Ein LE kann auch solche Dokumente löschen, die ein anderer LE eingestellt 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.5.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 30: Tab_ILF_ePA_Operation_Dokumente_löschen

5.2.5.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.5.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.6 Artefakte

5.2.6.1 Namensräume

Tabelle 31: Tab_ILF_ePA_Namensräume

5.2.6.2 WSDLs und Schemata

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

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

5.2.7 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 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 28-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_Fachanwendung_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 32: 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 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. 

Das Erhalten von Berechtigung ist die Nachbedingung der Anwendungsfälle "Berechtigung durch einen Versicherten vergeben" aus [gemSysL_Fachanwendung_ePA#3.6.1] und "Bestehende Berechtigungen durch einen Versicherten verwalten" [gemSysL_Fachanwendung_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 Frontend des Versicherten ebenfalls Zugriffsberechtigungen erteilen kann.

Für den Fall, dass einige Records bei RegisterSMB aktualisiert wurden, andere jedoch nicht, soll für das Delta ein erneuter Aktualisierungsversuch durchgeführt werden. Wenn bei wiederholter Aufnahme einer Akte in den KnownRecords beim RegisterSMB-Request wie in der Ergebnisliste UpdatedRecords erkennbar ist, keine Berechtigung aktualisiert wurde, sollte in der Benachrichtigungsfunktion geschlussfolgert werden, dass die Berechtigung auf den Aktenzugriff vom Versicherten am Frontend des Versicherten entzogen wurde.

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

5.3.1.3 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 Frontend des Versicherten vorgenommen hat. 

5.3.1.4 Info-Quelle Fehlermeldung

5.3.1.5 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.6 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 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, um IHE-konform Übertragungsprotokolle zu verwalten.

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 35: 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 36: 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 37: 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 39: 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 40: 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 42: Tab_ILF_ePA_Dokumentenformate

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

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. 

Im <lcm:SubmitObjectsRequest> des <ProvideAndRegisterDocumentSetRequest> referenziert das <rim:ExtrinsicObject> die <rim:RegistryObjectList> die ID des angehängten NFD-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.

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

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. 

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