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.