gemILF_PS_ePA_V3.0.0
Elektronische Gesundheitskarte und Telematikinfrastruktur
Implementierungsleitfaden Primärsysteme ePA für alle
Version | 3.0.0 |
Revision | 831785 |
Stand | Wert nicht konfiguriert |
Status | freigegeben |
Klassifizierung | öffentlich |
Referenzierung | gemILF_PS_ePA |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version | Stand | Kap./ Seite | Grund der Änderung, besondere Hinweise | Bearbeitung |
---|---|---|---|---|
3.0.0 | Einbau der "ePA für alle" | gematik | ||
zur Abstimmung freigegeben | ||||
30.01.24 | zur Freigabe empfohlen | gematik | ||
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Die vorliegende Spezifikation definiert Anforderungen zu Erstellung, Test und Betrieb derjenigen Anteile eines Primär- oder Clientsystems, die zur Nutzung der ePA für alle erforderlich sind.
Technische Standards werden in der ePA verwendet, um Interoperabilität zu steigern und die technischen Voraussetzungen zur Nutzung der Anwendung zu legen. Auf Seiten der Primärsystemhersteller eröffnet die Verwendung von Standards die Chance, wiederverwendbare Schnittstellen zu entwickeln bzw. zu nutzen und einzelne Module austauschbar zu gestalten.
Zum Zweck der Implementierungshilfe werden grundlegende Konzepte und Anwendungsfälle der ePA für alle aus der Sicht der PS-Hersteller erläutert. Dabei werden nicht nur Anwendungsfälle der ePA erläutert, sondern auch praktische Umsetzungshinweise gegeben sowie auf Beispiele verwiesen.
1.2 Zielgruppe
Das Dokument ist maßgeblich für Hersteller von Primärsystemen, welche die Schnittstellen der ePA für alle nutzen.
Falls ein Primärsystem bisher das technische Framework von IHE noch nicht verwendet, wird es durch diesen Implementierungsleitfaden in die Lage versetzt, die ePA-Schnittstellen IHE-konform zu verwenden.
Falls ein Primärsystem das technische Framework von IHE bereits verwendet, schildert der Implementierungsleitfaden ihm die relevanten Einschränkungen des IHE-Frameworks, die für die ePA der Telematikinfrastruktur von Relevanz sind. Die IHE-Konformität dieser Schnittstellen ermöglicht ihm die Anbindung weiterer Anwendungen.
Mit der ePA für alle werden viele Schnittstellen als REST-Schnittstellen angeboten. Der Implementierungsleitfaden beschreibt die Umsetzung dieser Schnittstellen und der genutzten FHIR-Ressourcen.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Bestätigungs- Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. [gemPTV_ATV_Festlegung], AFO-Steckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 Abgrenzungen
Benutzte Schnittstellen werden in der Spezifikation desjenigen Produkttypen normativ beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 8.5).
Nicht Bestandteil des vorliegenden Dokumentes sind:
- Festlegungen zum Themenbereich Semantik von Metadaten, insoweit sie im Dokument [gemSpec_Aktensystem_ePAfuerAlle] beschrieben sind;
- Rendering-Vorschriften zur Form, in der ePA-Dokumente zur Anzeige gebracht werden (ggf. wird auf externe Festlegungen referenziert).
Die ePA fungiert als Sekundärdokumentation von Daten der Versicherten. Die Primärdokumentation der Versichertendaten im PS wird nur insoweit thematisiert, wie es für die Anbindung der ePA an das PS erforderlich ist.
1.5 Methodik
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.
2 Systemüberblick
Abbildung 1: Überblick ePA für alle
Die zentralen Funktionen der ePA für alle sind das integre Management von wohl definierten Metadaten und den medizinischen Dokumenten als auch die Unterstützung von digitalen Versorgungsprozessen. Initial bedient das Aktensystem den digital gestützten Medikationsprozess durch die Bereitstellung einer elektronischen Medikationsliste (eML) an Leistungserbringer.
Das Primärsystems bietet einem Leistungserbringer als Nutzer den Zugang zur elektronischen Patientenakte des gesetzlich Versicherten an. Dabei greifen Leistungserbringer und Primärsystem über eine vertrauenswürdige Ausführungsumgebung (VAU) geschützt auf die elektronische Patientenakte zu und nicht mehr gekapselt über ein Konnektor-Fachmodul. Das in der ePA 2.x genutzte ePA-Fachmodul im Konnektor entfällt in der ePA für alle. Ein Zugang zur TI (mittels Konnektor oder TI-Gateway) ist zum Erreichen der Aktensysteme allerdings weiterhin erforderlich.
Wenn von dem "Aktenkonto" im Folgenden gesprochen wird, ist die ePA als Sekundärakte des Versicherten gemeint, nicht die "Primärakte" für den Versicherten im Primärsystem. Mit "Aktenanbieter" ist im Folgenden immer der Anbieter des ePA-Aktensystems gemeint. ePA-Aktensysteme können von mehreren Anbietern zur Verfügung gestellt werden, wobei die Dokumente eines einzelnen Versicherten immer genau bei einem Anbieter ePA-Aktensystem hinterlegt werden.
Die Nutzer der Primärsysteme der Leistungserbringer teilen sich die technische Infrastruktur der ePA in der Telematikinfrastruktur, folgen dabei den hier geschilderten Regeln der TI und bilden in diesem Sinne eine IHE-Affinity Domain, um ePA-Daten gesteuert durch die Befugnisvergabe des Versicherten auszutauschen. Dieser Datenaustausch erfolgt in vielerlei Hinsicht gemäß Festlegungen von IHE.
Die technische Infrastruktur der ePA besteht beim Leistungserbringer vor allem aus dem Konnektor, den Kartenlesegeräten und den Smartcards. Mit dem Konnektor stehen auch die Komponenten der Basis-TI, die zentrale TI und der Fach- und Basisdienste der TI zur Verfügung, etwa die Signaturfunktionalität, deren Nutzung durch das PS in [gemILF_PS] beschrieben sind.
Die Authentifizierung für die Zugriffe auf die ePA erfolgt durch den Identity Provider (IDP). Der Identity Provider (IDP) ist ein Nutzerdienst der TI-Plattform, welcher die Authentifizierung von Nutzern, die sich über eine Institutionskarte (SMC-B) ausweisen können, und die Bereitstellung bestätigter Identitätsmerkmale der Nutzer als Plattformleistungen ermöglicht. Der IDP authentifiziert den Nutzer anhand der kartenbasierten Identität und einer Signatur durch das Schlüsselmaterial auf der Karte (SMC-B) und stellt bei Erfolg einen IDP-Token für den Zugriff auf den Fachdienst aus.
Für einen Leistungserbringer liegt die Befugnis zur Nutzung der ePA des Versicherten vor, wenn ein Behandlungskontext besteht oder eine Befugnis über das ePA-FdV erteilt wurde.
Der Behandlungskontext wird im Rahmen von VSDM festgestellt, d. h. mit dem Stecken der eGK im Rahmen von VSDM.
Das Dokument [gemKPT_ePAfuerAlle] bietet einen Überblick zur ePA für alle.
2.1 Akteure und Rollen
Das vorliegende Dokument richtet sich vorrangig an Hersteller von Systemen, die von Leistungserbringern genutzt werden und formuliert Anforderung, die für die Nutzung der ePA implementiert werden müssen. Darüber hinaus werden in Kap 4 weitere Arten ePA-nutzender Systeme aufgeführt, deren Nutzer keine Leistungserbringer sind. Die großen Überschneigungen in den Anforderungshaushalten dieser Systeme mit denen der Leistungserbringer sind in den AFO-Steckbriefen dieser Nutzer abgebildet, s. TabILF_Kurzübersicht_PS-CS-Typen.
Leistungserbringer agieren in zwei ePA-Szenarien:
- als Einsteller und Konsument im bilateralen Dokumentenaustausch zwischen LE und Versichertem
- als Einsteller und Konsument in der Interaktion zwischen Leistungserbringern über die ePA
Das PS tritt somit in der Consumer Zone der TI sowohl als Document Consumer als auch als Document Source auf, beim Löschen auch als Document Administrator.
Gemäß [gemILF_PS#3.1.3] können Heilberufler ihren SM-B selbst nutzen oder ihre Gehilfen im Allgemeinen dafür autorisieren, auf die Anwendungen der eGK mit ebendiesen Rechten zuzugreifen. Dies gilt für das SM-B der TI-Rollenprofile 2, 3, 4 (SM-B Leistungserbringer). Eine Ausnahme hierzu bilden ausschließlich die Gehilfen der nichtärztlichen Psychotherapeuten. Das PS darf die berufsmäßigen Gehilfen der nichtärztlichen Psychotherapeuten nicht mit denjenigen Zugriffsberechtigungen auf die ePA ausstatten, über die der nichtärztliche Psychotherapeut verfügt.
Die Versicherten agieren in der Rolle des Akteninhabers und in der Rolle des Vertreters des Akteninhabers.
Auch innerhalb größerer Leistungserbringer-Institutionen ist ein Akteur gegenüber der ePA mittels seiner Telematik-ID als eigenständiger Nutzer identifiziert, nicht als Mandant einer übergreifenden Institution. Die Mandantenverwaltung innerhalb einer größeren Institution, etwa einem Krankenhaus, muss ggf. dafür genutzt werden, um den Prüfungsnachweis des Mandanten nutzen zu können, der aktuell in der ePA aktiv ist.
Unterschiedliche Arten von Primärsystemen (PS) und Clientsystemen (CS) haben je nach ihren fachlichen Nutzungsprofilen unterschiedliche Anforderungshaushalte.
- PS = Client gegenüber dem Aktensystem mit Userinteraktion
- CS = Client gegenüber dem Aktensystem potentiell ohne Userinteraktion
Normative Anforderungshaushalte unterschiedlicher Systeme sind jeweils in speziellen AFO-Steckbriefen aufgeführt. Der AFO-Steckbrief hat im Zweifelsfall Priorität gegenüber der Unterscheidung zwischen Primärsystem und Clientsystem im Fließ- und Anforderungstext.
Tabelle 1: TabILF_Kurzübersicht_PS-CS-Typen
Nutzer | Kurzbeschreibung der Nutzungsszenarien | Typ | AFO-Steckbrief |
---|---|---|---|
Leistungs- erbringer | Leistungserbringer benutzen das Aktensystem, um Daten für Behandlungsprozesse bereitzustellen und zu nutzen. | PS (alle PS-AFOs, keine CS-AFOs) | gemSST_PS_ePA |
Kostenträger | Einstellen von Abrechnungsdaten, eAUs und eingescannten Papierdokumenten. Im Rahmen eines betreiberübergreifenden Aktenumzugs:
|
CS (Untermenge PS-AFOs, Untermenge CS-AFOs) | gemSST_CS_ePA_KTR |
Ombudstelle | Auf Wunsch eines Versicherten für sein Aktenkonto:
|
CS (Untermenge PS-AFOs, Untermenge CS-AFOs) | gemSST_CS_ePA_Ombudstelle |
DiGA | Einstellen von DiGA-Daten | CS (Untermenge PS-AFOs, Untermenge CS-AFOs) | gemSST_CS_ePA_DiGA |
3 Übergreifende Festlegungen
In diesem Kapitel werden die übergreifenden Festlegungen zum erfolgreichen Kommunikationsaufbau zwischen Primärsystem und einem Aktenkonto beschrieben.
A_24680 - User Agent im Nachrichtenheader
Das PS MUSS die HTTP Header Elemente "ClientID" und "Versionsnummer" bei jedem Request sowohl im HTTP-Header der VAU-Nachricht, als auch im HTTP-Header der Nachricht an den Service einfügen gemäß [gemSpec_Aktensystem_ePAfuerAlle#2]. [<=]
3.1 TLS
Das Primärsystem benutzt für die Kommunikation im Rahmen der Anwendungsfälle der ePA für alle ausschließlich TLS.
Es gelten die Vorgaben aus [gemSpec_Krypt] für TLS.
A_24500 - Kommunikation über TLS-Verbindung
Das PS MUSS für die Anwendungsfälle der ePA für alle mit den Diensten der TI ausschließlich über TLS mit serverseitiger Authentisierung kommunizieren. [<=]
A_24502 - Vorgaben für TLS-Verbindungen
Das PS MUSS als ePA-Client für die TLS-Kommunikation die Vorgaben aus [gemSpec_Krypt#3.15.3] umsetzen. [<=]
3.2 Lokalisierung der Service-Endpunkte der ePA
Das Primärsystem erfährt die Endpunkte der verschiedenen Aktensysteme über die DNS-Service Discovery (DNS-SD) für eine übergreifende Domäne entweder über den DNS-Resolver des Konnektors oder den konfigurierten DNS-Resolver für das Internet. Hinterlegt sind dort alle Service-Endpunkte in der Telematikinfrastruktur für die verschiedenen Aktensysteme. Die DNS-SD wird durch den entsprechenden ePA-Client einmal täglich abgefragt.
Die übergreifende Domäne lautet epa4all.de. Darunter sind die Sub-Domänen für die unterschiedlichen Umgebungen:
- prod.epa4all.de
- ref.epa4all.de
- dev.epa4all.de
- test.epa4all.de.
Die nach außen angebotenen und für die Primärsysteme relevanten Dienste der ePA-Aktensysteme stehen unter folgenden URLs zur Verfügung:
- https://<FQDN aus DNS Lookup>:443/info/I_Information_Service
- https://<FQDN aus DNS Lookup>:443/epa/<Schnittstellen der verschiedenen Services in der VAU>.
A_24447 - Domänen als konfigurierbarer Wert
Das PS MUSS die Domänen für die DNS-Service Discovery als einen konfigurierbaren Wert umsetzen, damit ein Wechsel der Umgebungen einfach möglich ist. [<=]
A_24448 - DNS-Service Discovery täglich für Service-Endpunkte der ePA
Das PS MUSS die DNS-Service Discovery für die Service-Endpunkte der ePA beim Start und einmal täglich ausführen, die Ergebnisse lokal speichern und diese Informationen nutzen. [<=]
A_24380 - Endpunkt Schnittstelle ePA-Aktensysteme
Das Primärsystem MUSS die URL für die Kommunikation mit den ePA-Aktensystemen gemäß https://<FQDN aus DNS Lookup>:443/ bilden. [<=]
Das Primärsystem erreicht die ePA-Aktensysteme und den IDP über den Konnektor geroutet. Es ist sinnvoll den Konnektor als Default-Gateway zu nutzen.
Die Informationen zu den Endpunkten des Identity Providers ermittelt das Primärsystem aus dem Discovery Document, siehe auch [gemSpec_IDP_Dienst#Registrierung von Endgerät und Anwendungsfrontend]. Das Discovery Document ist vom IDP-Dienst unter der URL /.well-known/openid-configuration abrufbar.
3.3 Lokalisierung der Akte eines Versicherten
Wenn dem Primärsystem nicht bekannt ist, bei welchem Aktensystembetreiber ein Aktenkonto liegt, muss es den zuständigen Service-Endpunkt ermitteln. Dazu wendet sich das PS an den Information Service außerhalb der VAU eines Aktensystems, um dort nach der Akte zu fragen.
Konnte das Aktenkonto ermittelt werden, wird der zuständige Service-Endpunkt gespeichert. Gibt der Informationsdienst den Aktenkonto-Status "Unknown" zurück, wiederholt das Primärsystem den Aufruf beim nächsten Aktensystem.
Kennt kein Aktensystem die Akte, hat der Versicherte der ePA widersprochen und es existiert keine Akte.
Dazu wird folgende Operation genutzt:
Tabelle 2: I_Information_Service::getRecordStatus
REST-Schnittstelle des Aktensystems (Nutzung ohne VAU-Kanal) |
|
---|---|
I_Information_Service | |
getRecordStatus | Diese Operation ermittelt, ob für die übergebene KVNR ein Aktenkonto existiert und in welchem Status es ist. |
A_24499 - Nutzung der Schnittstelle I_Information_Service
Das PS MUSS die Operation getRecordStatus nutzen gemäß [I_Information_Service]. [<=]
A_24435 - Ermitteln des zuständigen Service-Endpunkts zu einem Aktenkonto
Das PS MUSS die Abfrage der Existenz eines Aktenkontos zu einer KVNR gegen die bekannten Aktensysteme wiederholen, bis diese erfolgreich ist oder alle Aktensysteme angefragt wurden. [<=]
A_25146 - Aktenlokalisierung als Hintergrundprozess
Das PS MUSS die Lokalisierung der Akte ohne Nutzeraktion im Rahmen eines ePA-Zugriffs durchführen, wenn noch kein Service-Endpunkt zur Akte vorliegt. Dieses soll im Hintergrund ablaufen und darf nicht die Weiterarbeit behindern. [<=]
A_24439 - Speichern und Nutzen des zuständigen Service-Endpunkts zu einem Aktenkonto
Das PS MUSS den zuständigen Service-Endpunkt zu einem Aktenkonto speichern und verwenden. Nur wenn der Status "Unknown" vom Aktensystem zurückgegeben wurde, darf es den Service-Endpunkt neu ermitteln. [<=]
A_24445 - Fehlermeldung Akte existiert nicht
Das PS MUSS dem Nutzer eine verständliche Fehlermeldung oder eine eindeutige Statusinformation anzeigen, wenn alle verfügbaren Aktensysteme angefragt wurden und alle den Status "Unknown" zurückgeben. [<=]
3.4 User Session und Login in ein Aktenkonto
Das Primärsystem kommuniziert als ePA-Client mit dem ePA-Aktensystem in einer Vertrauenswürdige Ausführungsumgebung (VAU). Diese stellt sicher, dass sensible Klartext-Daten wie z. B. die medizinischen Daten des Versicherten sicher vor Angriffen verarbeitet werden können. Die Daten werden ausschließlich über sichere VAU-Kanäle vom PS in die VAU transportiert bzw. aus der VAU abgerufen.
Das Primärsystem initiiert den Aufbau eines VAU-Kanals in die VAU des Aktensystems. Dabei authentisiert sich die VAU mit ihrem Zertifikat als authentische VAU des Aktensystems. Anschließend wird für den Nutzer, repräsentiert durch die SMC-B, mit Hilfe des IDP-Dienstes eine User Session angelegt. Diese User Session ermöglicht den Zugriff auf alle Aktenkonten des Aktensystems, in denen eine Befugnis für die LEI hinterlegt ist. Durch eine Anfrage an eine bestimmte Akte wird diese in der User Session als Health Record Context geladen und man kann darauf arbeiten.
Abbildung 2: Überblick über Aufbau VAU, User Session und Aktensession
3.4.1 VAU
Für Informationen zum Kommunikationsprotokoll zwischen dem Primärsystem und einer VAU siehe und [gemSpec_Krypt#7].
A_24494 - Kommunikation mit der Vertrauenswürdigen Ausführungsumgebung (VAU)
Das PS MUSS als ePA-Client für die Kommunikation mit der Vertrauenswürdigen Ausführungsumgebung (VAU) die Vorgaben aus [gemSpec_Krypt#7,3.15] umsetzen. [<=]
A_24926 - Umsetzung sicherer Kanal zur Aktenkontoverwaltung
Das PS MUSS die im Rahmen des sicheren Verbindungsaufbaus zur Aktenkontoverwaltung ausgehandelten Sitzungsschlüssel verwenden, um den HTTP Body aller über den sicheren Kanal zu sendenden Requests an die Aktenkontoverwaltung zu verschlüsseln und alle über den sicheren Kanal gesendeten Responses von der Aktenkontoverwaltung zu entschlüsseln. [<=]
Die gematik wird Beispielimplementierungen des VAU-Protokolls der ePA für alle auf GitHub veröffentlichen.
3.4.2 Nutzerauthentifizierung per IDP-Dienst mittels OIDC-Flow
Die Authentifizierung der LEI erfolgt mittels zentralem IDP-Dienst. Dieser steht bereits u.a. für das e-Rezept zur Verfügung:
Abbildung 3: Überblick über Nutzerauthentifizierung
1. Die Nutzerauthentifizierung wird durch einen Zugriff des Primärsystems auf das ePA-Aktensystem getriggert.
2. Da der Nutzer noch nicht angemeldet ist, leitet der Authorization Server des ePA-Aktensystem an den IDP-Dienst weiter. Am IDP-Dienst authentisiert sich der Nutzer mittels SMC-B und PIN. Bei erfolgreicher Authentisierung erhält das Primärsystem einen Authorization Code.
3. Das Primärsystem übermittelt den Authorization Code an das ePA-Aktensystem.
Der Authorization Server im ePA-Aktensystem ruft mittels des Authorization Codes das ID-Token für den Nutzer vom IDP-Dienst ab. Das ID-Token ist vom IDP-Dienst signiert. Als Ergebnis ist ein ID-Token des Nutzers in der VAU vorhanden. Liegt ein ID-Token des Nutzers in der VAU vor, wird durch den User Session Manager eine User Session für den Nutzer gestartet und die LEI kann auf die Aktenkonten (sofern eine Befugnis vorhanden ist) zugreifen.
Die folgende Abbildung zeigt den Nachrichten-Flow im Detail:
Abbildung 4: Detaillierter Nachrichten-Flow für die Nutzerauthentifizierung mit dem IDP-Dienst
Vorbereitend zum OIDC-Flow fragt das PS eine Nonce ab (0), die es mit der SMC-B signiert als "Attestation der Umgebung".
Dazu nutzt es folgende Operation:
Tabelle 3: I_Authorization_Service::getNonce
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Authorization_Service | |
getNonce | Diese Operation liefert eine Nonce für die Erstellung der Attestation. |
A_24881 - Nonce anfordern für Erstellung "Attestation der Umgebung"
Das PS MUSS, um die Nutzerauthentifizierung zu starten, die Operation getNonce nutzen gemäß [I_Authorization_Service]. [<=]
A_24882 - Signatur der Nonce
Das PS MUSS zum Signieren der Nonce mit der SMC-B des ePA-Mandanten die Konnektorschnittstelle AuthSignatureService::ExternalAuthenticate nutzen gemäß [gemSpec_Kon]. [<=]
A_24883 - Nonce signieren als ECDSA-Signatur
Das PS MUSS beim Signieren der Nonce mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden. Nur wenn der Signaturversuch scheitert, weil noch eine SMC-B G2 vorliegt, darf das PS auf eine PKCS#1-Signatur ausweichen. [<=]
A_24884 - Nonce signieren als PKCS#1-Signatur
Das PS MUSS beim Signieren der Nonce nach einem gescheiterten Versuch eine ECDSA-Signatur zu erzeugen, eine PKCS#1-Signatur erzeugen. Dazu MUSS im Element dss:SignatureType die URI urn:ietf:rfc:3447 übergeben werden. Als Signatur-Schema MUSS der Default-Wert für SIG:SignatureSchemes RSASSA-PSS genutzt werden. [<=]
A_24886 - Signierte Nonce als ClientAttest
Das PS MUSS die signierte Nonce als Parameter ClientAttest im send_AuthCode setzen. [<=]
Der eigentlich IDP-Flow startet mit der Anfrage des PS an den Authorization Service (1). Dazu nutzt es folgende Operation:
Tabelle 4: I_Authorization_Service::send_Authorization_Request_SC
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Authorization_Service | |
send_Authorization_Request_SC | Mit dieser Operation wird die Authentifizierung eines Leistungserbringers durch einen IDP initiiert. |
A_24760 - Start der Nutzerauthentifizierung
Das PS MUSS, um die Nutzerauthentifizierung zu starten, die Operation send_Authorization_Request_SC nutzen gemäß [I_Authorization_Service]. [<=]
Die Response enthält "clientID" (des Aktensystems),"response_type", "redirect_uri", "state", "code_challenge", "code_challenge_method", "scope" und "nonce" (3 und 4).
Das Authenticator Modul des PS stellt nun einen GET: AUTHORIZATION REQUEST an den zentralen IDP mit den vom Authorization Service erhaltenen Parametern (5).
A_24944 - Anfrage des "AUTHORIZATION_CODE" für ein "ID_TOKEN"
Das Primärsystem MUSS den Antrag zum "AUTHORIZATION_CODE" für ein "ID_TOKEN" beim Authorization-Endpunkt (URI_AUTH) in Form eines HTTP/1.1 GET Request stellen und dabei die folgenden Attribute aus der send_Authorization_Request Antwort des Authorization Server übermitteln:
• "response_type"
• "scope"
• "nonce"
• "client_id"
• "redirect_uri"
• "code_challenge" (Hashwert des "code_verifier") [RFC7636 # section-4.2]
• "code_challenge_method" HASH-Algorithmus (S256) [RFC7636 # section-4.3]
[<=]
Der Authorization-Endpunkt legt nun eine "session_id" an, stellt alle nötigen Informationen zusammen und erzeugt das "CHALLENGE_TOKEN".
Darüber hinaus stellt der Authorization-Endpunkt den im Claim des entsprechenden Fachdienstes vereinbarten "Consent" zusammen, welcher die für dessen Funktion notwendigen Attribute beinhaltet.
Der IDP-Dienst antwortet dem PS dann mit dem Challenge-Token und dem User Consent (6a).
A_20662 - Annahme des "user_consent" und des "CHALLENGE_TOKEN"
Das Primärsystem MUSS den "user_consent" und den "CHALLENGE_TOKEN" vom Authorization-Endpunkt des IDP-Dienstes annehmen. Der Authorization-Endpunkt liefert diese als Antwort auf den Authorization-Request des Primärsystems. [<=]
A_20663-01 - Prüfung der Signatur des CHALLENGE_TOKEN
Das Primärsystem MUSS die Signatur des "CHALLENGE_TOKEN" gegen den aktuellen öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_SIG" prüfen. Liegt dem Primärsystem der öffentliche Schlüssel des Authorization-Endpunktes noch nicht vor, MUSS es diesen gemäß dem "kid"-Parameter "puk_idp_sig" aus dem Discovery Document abrufen. [<=]
Das Primärsystem verwendet nun die AUT-Identität der SM-B der LEI und deren Konnektor, um das gehashte "CHALLENGE_TOKEN" des IDP-Dienstes zu signieren. Wenn es sich um eine erstmalige Anmeldung des Benutzers bei diesem Fachdienst handelt, werden diesem darüber hinaus die für den Zugriff übermittelten Daten der LEI angezeigt.
A_20664 - Bestätigung des Consent
Das Primärsystem MUSS dem Nutzer einmalig vor der Signatur der "challenge" anzeigen, dass ein tokenbasierter Zugriff auf den im "scope" genannten Dienst initiiert wird. [<=]
Hinweis: Die erfolgte Zustimmung des Nutzers darf gespeichert werden und weitere Abfragen können entfallen.
A_20665-01 - Signatur der Challenge des IdP-Dienstes
Das Primärsystem MUSS für das Signieren des CHALLENGE_TOKEN des IdP-Dienstes mit der Identität ID.HCI.AUT der SM-B die Operation ExternalAuthenticate des Konnektors gemäß [gemSpec_Kon#4.1.13.4] bzw. [gemILF_PS#4.4.6.1] verwenden und als zu signierende Daten BinaryString den SHA-256-Hashwert des CHALLENGE_TOKEN in Base64-Codierung übergeben.
[<=]
A_24751 - Challenge signieren als ECDSA-Signatur
Das PS MUSS beim Signieren der Challenge mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden. Nur wenn der Signaturversuch scheitert, weil noch eine SMC-B G2 vorliegt, darf das PS auf eine PKCS#1-Signatur ausweichen. [<=]
A_24752 - Challenge signieren als PKCS#1-Signatur
Das PS muss beim Signieren der Challenge nach einem gescheiterten Versuch eine ECDSA-Signatur zu erzeugen, eine PKCS#1-Signatur erzeugen. Dazu MUSS im Element dss:SignatureType die URI urn:ietf:rfc:3447 übergeben werden. Als Signatur-Schema MUSS der Default-Wert für SIG:SignatureSchemes RSASSA-PSS genutzt werden. [<=]
A_20666-01 - Auslesen des Authentisierungszertifikates
Das Primärsystem MUSS das Zertifikat ID.HCI.AUT der SM-B über die Operation ReadCardCertificate des Konnektors gemäß [gemSpec_Kon#4.1.9.5.2] bzw. [gemILF_PS#4.4.4.2] auslesen. [<=]
Hinweis: Damit das bei der Signatur bevorzugt zu verwendene ECC-Zertifikat gelesen wird, muss bei der Operation ReadCardCertificate der Parameter Crypt auf ECC gesetzt werden. Nur bei einer Karte der Generation G2 kann der Default (RSA) genutzt werden.
Anschließend werden die signierte "challenge" und das verwendete Authentisierungszertifikat der Smartcard an den IDP-Dienst übermittelt (6b).
A_20667-01 - Response auf die Challenge des Authorization-Endpunktes
Das Primärsystem MUSS das eingereichte "CHALLENGE_TOKEN" zusammen mit der von der Smartcard signierten Challenge-Signatur "signed_challenge" (siehe A_20665) und dem Authentifizierungszertifikat der Smartcard (siehe A_20666), mit dem öffentlichen Schlüssel des Authorization-Endpunktes "PUK_IDP_ENC" verschlüsselt, an diesen in Form eines HTTP-POST-Requests senden. [<=]
Hinweis: Der Aufbau der Anfrage und der einzureichenden Objekte entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request].
Hinweis: Das Signieren und Verschlüsseln des "CHALLENGE_TOKEN" ist durch die Verwendung eines Nested JWT [angelehnt an den folgenden Draft: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03, zu realisieren. Im cty-Header ist "NJWT" zu setzen, um anzuzeigen, dass es sich um einen Nested JWT handelt. Das Signieren wird dabei durch die Verwendung einer JSON Web Signature (JWS) [RFC7515 # section-3 - Compact Serialization] gewährleistet. Die Verschlüsselung des signierten Token wird durch die Nutzung der JSON Web Encryption (JWE) [RFC7516 # section-3] sichergestellt. Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.
Der Authorization-Endpunkt validiert nun die "session" sowie die "signed_challenge" und prüft das Zertifikat der LEI. Anschließend verknüpft er die "session" mit der Identität aus dem Authentisierungszertifikat und erstellt einen "AUTHORIZATION_CODE", welchen er als Antwort zurücksendet.
Das Primärsystem empfängt nun diesen "AUTHORIZATION_CODE" vom IDP-Dienst (7).
A_20668 - Annahme des "AUTHORIZATION_CODE"
Das Primärsystem MUSS den vom Authorization-Endpunkt als Antwort auf die signierte Challenge gesendeten "AUTHORIZATION_CODE" verarbeiten. Das Primärsystem MUSS das "AUTHORIZATION_CODE" ablehnen, wenn dieser außerhalb der mit dem Authorization-Endpunkt etablierten TLS-Verbindung übertragen wird. [<=]
Das PS sendet diesen Authorization Code an den Authorization Service des Aktensystems (1). Dazu nutzt es die Operation send_AuthCode:
Tabelle 5: I_Authorization_Service::send_AuthCode
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Authorization_Service | |
send_AuthCode | Diese Operation sendet den vom IDP-Dienst erhaltenen Auth-Code an den Authorization Service. |
A_24766 - Abschluss der Nutzerauthentifizierung
Das PS MUSS, um die Nutzerauthentifizierung abzuschließen, die Operation send_AuthCode nutzen gemäß [I_Authorization_Service].
[<=]
Mit der send_AuthCode-Response erhält das Primärsystem die Zugriffserlaubnis auf das Aktensystem. Die User-Session ist etabliert und fachliche Operationen sind möglich.
3.4.2.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes
Zur Nutzung des IDP-Dienstes gelten einige grundlegende Voraussetzungen, welche das PS erfüllen muss:
A_20655 - Regelmäßiges Einlesen des Discovery Document
Das Primärsystem MUSS das Discovery Document (DD) [RFC8414] regelmäßig alle 24 Stunden einlesen und auswerten, und danach die darin aufgeführten URI zu den benötigten öffentlichen Schlüsseln (PUKs) und Diensten verwenden.
Der Downloadpunkt wird als Teil der organisatorischen Registrierung des Primärsystems beim IDP-Dienst übergeben.
Das Primärsystem MUSS den Downloadpunkt des Discovery Document als konfigurierbaren Parameter speichern. [<=]
A_20656-01 - Prüfung der Signatur des Discovery Document
Das Primärsystem MUSS die JWS (JSON Web Signature) [RFC7515 # section-3 - Compact Serialization] Signatur des Discovery Document auf mathematische Korrektheit sowie über die Funktion "VerifyCertificate" des Konnektors gemäß [gemSpec_Kon#4.1.9.5.3] bzw. [gemILF_PS#4.4.4.3] auf Gültigkeit des ausstellenden Zertifikates innerhalb der TI prüfen.
[<=]
Hinweis: Der genaue Aufbau entspricht [gemSpec_IDP_Dienst#7.7 Aufbau des Discovery Document].
Bei Aufruf der Funktion "VerifyDocument" an der Außenschnittstelle des Konnektors ist es nicht möglich, direkt auch eine Prüfung des Zertifikatstyps und der Rollen-OID durchzuführen.
A_20657 - Prüfung der Signatur des Discovery Document
Das Primärsystem MUSS die Signatur des Discovery Document auf ein zeitlich gültiges C.FD.SIG-Zertifikat mit der Rollen-OID "oid_idpd" zurückführen können. [<=]
Hinweis: Zur Durchführung der Prüfungen gemäß A_20657 und ähnlicher Anforderungen ist zu verifizieren, ob im Feld certificatePolicies (2.5.29.32) des Zertifikates der richtige Zertifikatstyp FD.SIG (1.2.276.0.76.4.203) gemäß [gemSpec_OID#Tabelle Tab_PKI_405] eingetragen ist und sich in der Admission (1.3.36.8.3.3) des Zertifikats die richtige "oid_idpd" (1.2.276.0.76.4.260) findet.
3.4.3 Logout
Das Primärsystem muss sich nicht explizit aus dem ePA-Aktensystem ausloggen. Ein implizites Logout findet statt,
- wenn die User Session endet,
- wenn der VAU-Kanal geschlossen wird.
Eine VAU schließt nach 20 Minuten Inaktivität automatisch die "UserSession" (gemSpec_Aktensystem#A_25006). Die VAU-Schlüssel (und damit auch die Nutzer-Authentisierung) muss davon unabhängig mindestens alle 24 Stunden erneuert werden (neuer Verbindungsaufbau VAU-Protokoll + anschließende Nutzerauthentisierung). Eine VAU-Verbindung kann bspw. über alle 15 Minuten Abfrage von /VAU-Status (gemSpec_Krypt#A_25143) "ohne anliegende fachliche Operation offen gehalten werden. Das ID-Token besitzt eine maximale Gültigkeitsdauer von 24 Stunden.
3.4.4 Aktenkontokennung
Das PS adressiert das gewünschte Aktenkonto über die KVNR des Versicherten. Bei Aufrufen innerhalb der VAU muss es ein HTTP-Header-Element mit dem Namen "x-insurantId" senden.
Werden Services außerhalb der VAU angesprochen, erfolgt die Adressierung über den Pfad, z. B. bei der Operation getConsentDecisionInformation "/information/{insurantid}/consentdecisions".
A_24998 - InsurantID im Nachrichtenheader
Das PS MUSS bei Aufrufen innerhalb der VAU ein HTTP Header Element mit dem Namen "x-insurantId" senden, um das Aktenkonto zu adressieren. [<=]
3.4.5 Zertifikate
Die kryptographischen Vorgaben im TLS-Bereich sind für das E-Rezept und ePA für alle ähnlich. Das VAU-Protokoll der ePA für alle unterscheidet sich vom E-Rezept-VAU-Protokoll, weil ein andere Authentisierungsvariante von OIDC/OAuth2/PCKE verwendet wird. Diese wird in einer späteren Ausbaustufe vom E-Rezept ebenfalls verwendet. Ab dann verwenden beide Anwendungen das VAU-Protokoll von ePA-für-alle.
A_24578 - Kryptografische Vorgaben für TLS- und VAU-Clients
Das PS MUSS alle Anforderungen zur Benutzung von Zertifikaten bei den Kommunikationsprotokollen TLS und VAU-Protokoll für die Kommunikation mit dem ePA-Aktensystem umsetzen, die in [gemSpec_Krypt#3.15.3] (ePA-spezifische TLS-Vorgaben) und in [gemSpec_Krypt#7] (VAU-Protokoll für ePA-für-alle) für einen ePA-Client definiert sind.
[<=]
A_24556 - Verpflichtende Zertifikatsprüfung
Das PS MUSS als ePA-Client alle Zertifikate der Tabelle TAB_ILF_Zertifikate, die es aktiv verwendet (bspw. TLS-Verbindungsaufbau), auf Integrität und Authentizität prüfen. Falls die Prüfung kein positives Ergebnis ("gültig") liefert, so MUSS es die von dem Zertifikat und den darin enthaltenen Attributen (bspw. öffentliche Schlüssel) abhängenden Arbeitsabläufe ablehnen.
Das Primärsystem MUSS alle öffentlichen Schlüssel, die es verwenden will, auf eine positiv verlaufene Zertifikatsprüfung zurückführen können. [<=]
Tabelle 6: TAB_ILF_Zertifikate
Aktivität | Zertifikat der TI | Zertifikatstyp | Rollen-OID | Nutzung |
---|---|---|---|---|
TLS-Verbindungsaufbau zum ePA-Aktensystem | ja | C.FD.TLS-S | oid_epa_dvw | aktiv |
TLS-Verbindungsaufbau zum Verzeichnisdienst der TI | nein | TLS Internet Zertifikat | n/a | aktiv |
TLS-Verbindungsaufbau zum IDP | nein | TLS Internet Zertifikat | n/a | aktiv |
Aufbau sicherer Kanal zur VAU des ePA-Aktensystems | ja | C.FD.AUT | oid_epa_vau | aktiv |
A_24900 - Prüfung TI-Zertifikate
Das Primärsystem MUSS X.509-Zertifikate der TI auf eine der beiden folgenden beiden Arten prüfen:
- Verwenden des CertificateService des Konnektors mit der Operation VerifyCertificate gemäß [gemSpec_Kon#4.1.9.5.3], wobei das zu prüfende Zertifikat als Parameter X509Certificate und die aktuelle Systemzeit als Parameter VerificationTime verwendet werden. Das Primärsystem MUSS bei Prüfung von TI-Zertifikaten der TAB_ILF_Zertifikate den Rückgabewert in RoleList gegen die erwartete Rollen-OID prüfen.
- Das Primärsystem prüft die TI-Zertifikate selbst ohne Nutzung des Konnektors nach [gemSpec_PKI#TUC_PKI_018] mit folgenden Parametern:
Parameter | Wert |
---|---|
Zertifikat | C.FD.TLS-S (für TLS) bzw. C.FD.AUT (für VAU-Kanal) |
PolicyList | oid_epa_dvw bzw. oid_epa_vau |
intendedKeyUsage | digitalSignature |
intendedExtendedKeyUsage | id-kp-serverAuth bzw. leer |
OCSP-Graceperiod | 60 Minuten |
Offline-Modus | nein |
Prüfmodus | OCSP |
A_24906 - lokales Caching von Sperrinformationen und Toleranzzeiten
Das Primärsystem, welches im Rahmen von Zertifikatsprüfungen Sperrinformation für nonQES-Zertifikate einholt, MUSS folgende Vorgaben umsetzen:
- Die Sperrinformationen (bspw. OCSP-Responses) müssen lokal gespeichert werden (caching), solange sie noch zeitlich gültig sind.
- Definition zeitliche Gültigkeit: Sei p die Zeit zu der die Sperrinformation vom TSP erzeugt wurde. Im Fall von OCSP-Responses ist diese Zeit die productedAt-Angabe [RFC-6960]. Sei s die lokale Systemzeit des prüfenden Systems. Eine Sperrinformation ist zeitlich gültig, wenn gilt s - D <= p <= s + 5 Minuten, wobei D im default-Fall eine Stunde beträgt.
(Es gibt anwendungsspezifische Verlängerungen der Gültigkeitsdauer D, die dann explizit in den entsprechenden Spezifikationen definiert werden.
D. h. die Sperrinformation können im default-Fall maximal eine Stunde alt sein und maximal für fünf Minuten "aus der Zukunft kommen". (Da nicht alle Produkttypen ihre Systemzeit in der TI synchronisieren, erlauben wir hier eine fünfminutige fehlerhafte Abweichung der lokalen Zeit.) - Das prüfende System muss, bevor es Sperrinformationen (bspw. für ein Zertifikat) einholt, prüfen, ob im Cache (vgl. Punkt 1) zeitlich gültige Sperrinformationen schon vorliegen. Falls ja, muss es diese Informationen verwenden und darf diese nicht neu beziehen.
- Bei einer evtl. Abarbeitung von TUC_PKI_006 muss der optionale Eingabeparameter "OCSP-Graceperiod" ignoriert werden und für die zeitliche Gültigkeit ist Punkt 2 maßgeblich. Bei OCSP-Antworten ist in diesem Kontext die Konsistenzprüfung, wie in TUC_PKI_006 in Schritt 6 aufgeführt, fachlich unnötig und deshalb nicht durchzuführen.
- Zeitlich ungültige Sperrinformation im Cache dürfen nicht für Zertifikatsprüfvorgänge verwendet werden und müssen mindestens alle 24h aus dem Cache aktiv entfernt werden.
Kontext OCSP: Die aufgrund der historischen Entwicklung von OCSP als Abfragemechanismus einer CRL-Abfrage bei einem TSP stammenden Werte thisUpdate und nextUpdate sind für A_24906-* irrelevant. Was zählt ist, dass der bestmögliche Informationsstand eines TSP zum Zeitpunkt producedAt in der Antwort dokumentiert ist. Dieser Informationsstand wird im Cache für die in A_24906-* aufgeführte Zeit als maßgeblich betrachtet und im prüfenden System verwendet.
Falls Sperrinformationen grundsätzlich vom zu authentifizierenden System mit gesendet werden (bspw. TLS-OCSP-stapling, OCSP-Anwort der VAU innerhalb des VAU-Protokolls), so holt der Client diese nicht aktiv ein, d. h., A_24906-* greift in Bezug auf das Caching nicht als MUSS-Bestimmung.
3.5 SOAP
In der ePA für alle nutzt das Primärsystem SOAP für den Zugriff auf die IHE-Schnittstellen des XDS Document Service.
Die SOAP-Schnittstellen werden nachrichtenbasiert über SOAP1.2 mit [BasicProfile2.0] angesprochen.
Die Bildung der SOAP-Nachrichten durch das Primärsystem wird in diesem Dokument technologie-neutral geschildert. Dabei werden die Voraussetzungen für unterschiedliche Strategien zur Nachrichtenerzeugung geliefert, darunter:
- Nutzung von Template Engines
- Codegenerierung mittels WSDL und XSD.
Die ePA nutzt bei bestimmten Operationen den SOAP-Header, um Informationen über den Aktenkontext und die Telematik-ID zu erhalten.
A_14510 - Setzen erforderlicher Parameter im SOAP-Header
Das PS MUSS Parameter im SOAP-Header setzen, wenn diese in der jeweiligen Signatur der Operation gefordert sind. [<=]
A_15569 - Verwendung von Byte Order Mark in SOAP-Nachrichten
Das PS KANN einen UTF-8 Unicode Byte Order Mark (BOM) gemäß [BasicProfile1.2#3.1.2] setzen. [<=]
A_15570-02 - Content-Type und Charset im http-Header
Das PS MUSS abweichend von R1012 in [BasicProfile1.2] und [BasicProfile2.0] ausschließlich das Character Encoding UTF-8 in der Nachricht benutzen und das charset im http-Header auf UTF-8 setzen. [<=]
3.6 REST
In der ePA für alle werden die vom Primärsystem angesprochenen Dienste wie der Information Service, Entitlement Management und den Medication Service über OpenAPI- sowie FHIR-Profildefinitionen festgelegt. Die Schnittstellen und Operationen sind funktional in den Beschreibungen der jeweiligen Schnittstelle beschrieben.
3.7 Mandantenverwaltung
Sowohl Befugnisse, VAU als auch ID-Token verwenden dedizierte anwendungsfallübergreifend identische Telematik-IDs. In größeren Einrichtungen muss dabei unter Datenschutz-Gesichtspunkten die Einrichtung einer Mandantenverwaltung für die Nutzung der ePA sowie ein ausreichendes Logging von Aktenzugriffen beachtet werden.
Die Nutzung ePA-fähiger Aufrufkontexte ist in kleineren Einrichtungen mit nur einer einzigen verwendeten SMC-B einfacher umzusetzen als in großen Einrichtungen, in denen es viele verwendete SMC-Bs zu konfigurieren gilt. Eine Voraussetzung für eine funktionierende ePA besteht darin, dass die Leistungserbringerinstitution so konfiguriert ist, dass die Beziehung zwischen der Telematik-ID der signierten Befugnis immer genau der Telematik-ID aus der VAU-Instanz, wie aus dem IDP-Token entspricht.
A_24401 - Mandantenweite Verwendung der korrekten SMC-B
Das PS MUSS sicherstellen, dass bei Vorhandensein mehrerer Mandanten in einer LEI jeder Mandant nur seine eigene SMC-B für den Aufbau der VAU, die Erstellung der Befugnis-Signatur und das IDP-Token verwendet. [<=]
Die Verwendung der korrekten SMC-B wird über den Aufrufkontext gesteuert.
Abbildung 5: ILF_ePA_Element_Context
Beispiel #: Bsp_ILF_ePA_Context
<m0:Context> <m1:MandantId>m0001</m1:MandantId> <m1:ClientSystemId>csid0001</m1:ClientSystemId> <m1:WorkplaceId>wpid007</m1:WorkplaceId> </m0:Context> |
---|
3.8 Funktionsmerkmale
Leistungserbringerinstitutionen haben zwei Möglichkeiten, vom Versicherten eine Befugnis zum Zugriff auf das Aktenkonto zu erhalten:
- Der Versicherte erteilt eine Befugnis für die LE-Institution am ePA-Frontend des Versicherten.
- Im Behandlungskontext wird vom PS im Zusammenhang mit dem Einlesen der eGK eine Befugnis einstellt.
Die Befugnis kann sowohl vom Versicherten selbst stammen, als auch vom Vertreter des Versicherten. Sie ist auf Leistungserbringerinstitutionen (inkl. deren berufsmäßigen Gehilfen oder zur Vorbereitung auf den Beruf Tätige, jedoch nicht die Gehilfen der nichtärztlichen Psychotherapeuten) eingeschränkt.
Die Laufzeit von Befugnissen ist begrenzt. Falls eine Befugnis aufgrund in der Vergangenheit liegendem validTO oder Befugnisentzug am ePA-Frontend des Versicherten nicht mehr existiert, ist eine erneute Berfugnisvergabe erforderlich.
A_15090 - Protokollierung Dokumententransfer im Übertragungsprotokoll
Jeder Dokumententransfer (Dokumente einstellen, laden, löschen) MUSS im Übertragungsprotokoll vermerkt werden. [<=]
3.9 Erstellen einer Befugnis
Die Leistungserbringerorganisation benötigt eine Befugnis (Entitlement), um auf die ePA eines Versicherten zugreifen zu können.
Abbildung 6: Ablauf Erstellung einer Befugnis
Der Auslöser zur Erstellung einer Befugnis ist das etablierte Lesen der eGK mit Onlineprüfung (1) beim ersten Praxisbesuch im Quartal oder bei der Aufnahme im Krankenhaus. Dabei wird vom Konnektor-Fachmodul VSDM ein Prüfungsnachweis erzeugt und in der ReadVSD-Response an das PS geliefert. Der Prüfungsnachweis enthält im Falle einer erfolgreichen Online-Prüfung (Ergebnis 1 oder 2) im Element Receipt die Prüfziffer des Fachdienstes als eine Base64Binary-kodierte Folge von bis zu 65 Bytes.
Damit die Prüfziffer in Verbindung zur Umgebung gesetzt werden kann, erfolgt die Erstellung eines signierten JSON-Web-Token (JWS). Dazu wird das JWS mit der AUT-Identität der SMC-B signiert (2), bevor es im Entitlement Management des Aktensystems als Befugnis registriert (3) wird.
Die Befugnisdauer wird vom Aktensystem festgelegt. Die in der LEI erzeugte Befugnis muss innerhalb dieses Zeitraumes nicht erneuert werden. Im Falle eines späteren Hochladens eines neueren Entitlements im vorliegenden Quartal gilt der aktuellere bzw. aktualisierte Befugniszeitraum.
Die Befugnisdauer beträgt
- 3 Tage für Apotheken, ÖGD und Institutionen der Arbeits- und Betriebsmedizin und
- 90 Tage für alle anderen Arten von Leistungserbringer-Institutionen.
Das Einstellen einer Befugnis aus der LEI-Umgebung erfolgt über folgende Operation des Entitlement Management des Aktensystems:
Tabelle 7: I_Entitlement_Management::setEntitlementPs
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Entitlement_Management | |
setEntitlementPs | Diese Operation registriert eine Befugnis im Entitlemanagent. |
A_24388 - Einstellen der LEI-Befugnis in die ePA für alle
Das PS MUSS für das Einstellen einer Befugnis die Operation setEntitlementPs nutzen gemäß [I_Entitlement_Management]. [<=]
3.9.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Erstellen einer Befugnis sind:
Vorbedingung:
- Ermittelter Service-Endpunkt zum Aktenkonto
- erfolgreiches ReadVSD mit Online-Prüfung
Auslöser:
- Erhalt einer Prüfziffer durch Lesen der eGK mit erfolgreicher Online-Prüfung (Prüfnachweis 1 oder 2)
- manuelle Auslösung
- Nachfrage bei uploadpflichtigen PVS-Aktionen und fehlender Berechtigung
Aktivitäten:
- Auswahl KVNR
- Auswahl des Service-Endpunkts zum Aktenkonto
- Auswahl der Prüfziffer des Versicherten
- Bildung eines JWS mit Prüfziffer und Zertifikat
- JWS signieren mit SMC-B
- JWS als Entitlement einstellen
- Auswertung des Ergebnisses
Resultat:
- Die Antwort gibt Auskunft darüber, ob eine Befugnis im Aktensystem erzeugt werden konnte oder nicht.
- Das Einstellen scheitert z. B., wenn die SMC-B nicht zur Gruppe der erlaubten Berufsrollen (professionOID) gehört oder wenn die LEI selbst oder die ganze Nutzergruppe vom Versicherten geblockt wurde.
- Die Antwort enthält im Erfolgsfall mit dem validTo das Enddatum der Befugnisdauer. Das PS kann die Befugnisdauer persistieren.
3.9.2 Nutzung
A_24398 - Prüfung auf Durchführbarkeit der Befugnis-Erstellung
Das PS MUSS den Prüfungsnachweis daraufhin prüfen, ob ein Prüfergebnis 1 oder 2 vorliegt und anderenfalls den UseCase Erstellen einer Befugnis abbrechen. [<=]
A_24391 - Das Entitlement in zeitnahem Kontext der VSDM-Prüfung in die ePA hochladen
Nach Erzeugen eines VSDM-Prüfungsnachweises für einen bestimmten Versicherten MUSS das PS die signierte Prüfziffer innerhalb von 20 Minuten als Entitlement für einen Zugriff auf seine Akte über die Schnittstelle I_Entitlement_Management in die ePA einstellen. [<=]
A_24528 - Einstellen einer Befugnis ohne Nutzeraktion
Das PS MUSS das Einstellen der Befugnis so implementieren, dass dazu keine eigene Nutzeraktion notwendig ist. [<=]
A_24400 - Prüfziffer als JWS signieren mit ExternalAuthenticate
Das PS MUSS zum Signieren der Prüfziffer mit der SMC-B des ePA-Mandanten die Konnektorschnittstelle AuthSignatureService::ExternalAuthenticate nutzen gemäß [gemSpec_Kon]. [<=]
A_24540 - Prüfziffer als JWS signieren als ECDSA-Signatur
Das PS MUSS beim Signieren des JWS mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden. Nur wenn der Signaturversuch scheitert, weil noch eine SMC-B G2 vorliegt, darf das PS auf eine PKCS#1-Signatur ausweichen. [<=]
A_24542 - Prüfziffer als JWS signieren als PKCS#1-Signatur
Das PS MUSS beim Signieren des JWS nach einem gescheiterten Versuch eine ECDSA-Signatur zu erzeugen, eine PKCS#1-Signatur erzeugen. Dazu MUSS im Element dss:SignatureType die URI urn:ietf:rfc:3447 übergeben werden. Als Signatur-Schema MUSS der Default-Wert für SIG:SignatureSchemes RSASSA-PSS genutzt werden. [<=]
Getrennte Mandanten im Primärsystem verfügen über SMC-Bs mit je verschiedenen Telematik-IDs. Wenn es SMC-Bs mit mehr als einer Telematik-ID gibt, muss dies in der Konfiguration von Konnektor und Primärsystem und im Aufrufkontextes der SMC-B berücksichtigt werden.
3.10 Versorgungsspezifische Services
Die ePA für alle unterstützt verschiedene Versorgungsprozesse mittels dedizierter Services. Initial unterstützt sie den digital gestützten Medikationsprozess (dgMP) durch die Bereitstellung einer Elektronischen Medikationsliste (eML) über einen FHIR Data Service.
3.10.1 Widersprüche zu Versorgungsprozessen abrufen
Versicherte können der Teilnahme an durch die ePA unterstützen Versorgungprozessen widersprechen. Das PS kann die Entscheidung zu Teilnahme (ConsentDecision) zur Behandlungsvorbereitung abfragen. Sie kann dabei den Zustand "kein Widerspruch erklärt" ("permit") oder "Widerspruch erklärt" ("deny") haben. Die Versorgungsprozesse werden über eine ID referenziert ( z. B. die Teilnahme am Medikationsprozess "id":"medication").
Über diese Operation des Information Service kann das PS die Entscheidung zu den Versorgungsprozessen abfragen:
Tabelle 8: I_Information_Service::getConsentDecisionInformation
REST-Schnittstelle des Aktensystems (Nutzung ohne VAU-Kanal) |
|
---|---|
I_Information_Service | |
getConsentDecisionInformation | Diese Operation liest den aktuellen Zustand der Widersprüche gegen die Nutzung von widerspruchsfähigen Funktionen der Funktionsklasse "Versorgungsprozess" aus. |
A_24493 - Nutzung der Schnittstelle I_Information_Service
Das PS MUSS es dem Nutzer ermöglichen, die Entscheidung zur Teilnahme an Versorgungsprozessen abzufragen unter der Verwendung der Operation getConsentDecisionInformation gemäß [I_Information_Service]. [<=]
A_24368 - Persistieren der Information zur Teilnahme an Versorgungsprozessen
Das PS MUSS die erhaltenen Informationen zur Teilnahme an Versorgungsprozessen persistieren. [<=]
Wenn es bei Aufrufen im Rahmen des Versorgungsprozesses zu einem Fehler kommt, ist eine Wiederholung der Abfrage der Widersprüche sinnvoll.
3.10.2 Medikationsprozess
Der digital gestützte Medikationsprozess (dgMP) wird über eine elektronische Medikationsliste (eML) durch den Medication Service umgesetzt. In der initialen Ausbaustufe der ePA für alle ist diese Liste durch Leistungserbringer und Versicherte nur lesend verarbeitbar. In der eML finden sich die vom E-Rezept-Fachdienst übergebenen und aufbereiteten Verordnungen und Dispensierinformationen.
Die eML soll vom Leistungserbringer über das Primärsystem abgerufen und angezeigt werden können. Dies kann beispielsweise im Rahmen des Verschreibungsprozesses geschehen oder bei der Abgabe in der Apotheke.
Dazu bietet der Medication Service mehrere Möglichkeiten:
Das Primärsystem kann über die folgenden URL-Aufrufe diese Formate anfordern:
Tabelle 9: I_Medication_Service_eML_Render
HTTP-Schnittstelle des Aktensystems für Rendering (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Medication_Service_eML_Render | |
|
Diese Operationen liefern gerenderte Versionen der eML. |
Für Primärsysteme, die bereits FHIR-basiert arbeiten, gibt es auch die Möglichkeit, über die standardisierte FHIR-Schnittstelle sämtliche Medikationen vollständig (und historisiert) abzufragen.
Tabelle 10: I_Medication_Service_FHIR
FHIR-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
---|---|
I_Medication_Service_FHIR | |
Unterstützte FHIR-Ressourcen:
|
Diese API liefert die FHIR-Instanzen einer eML über eine FHIR-basierte Abfrage unter Nutzung der entsprechenden Suchparameter. |
A_24559 - Abruf und Darstellung der elektronischen Medikationsliste im Medikationsprozess
Das PS MUSS mindestens eine Möglichkeit des Abrufs der eML umsetzen gemäß [I_Medication_Service_FHIR] oder [I_Medication_Service_eML_Render]. [<=]
3.11 Dokumentenmanagement
Für das Dokumentenmanagement in der ePA für alle nutzt das PS eine Profilierung der IHE-Spezifikationen rund um das Kernprofil XDS.b (Cross-Enterprise Document Sharing).
Tabelle 11: Tab_ILF_ePA_Profilierung
Profilierungen des Kernprofiles XDS.b |
|
---|---|
Anwendungsfall |
IHE-Schnittstelle |
Dokumente einstellen |
DocumentRepository_ProvideAndRegisterDocumentSet-b [ITI-41] |
Dokumente suchen |
Registry Stored Query [ITI-18] |
Dokumente laden |
Retrieve Document Set [ITI-43] |
Dokument löschen |
Remove Metadata [ITI-62] |
Aktualisieren von Metadaten | Restricted Update Document Set [ITI-92] |
A_24661 - Nutzung der Dokumentenmanagement-Schnittstelle I_Document_Management
Das PS MUSS die Aktensystemschnittstelle Schnittstelle I_Document_Management am Aktensystem der ePA für alle [gemSpec_Aktensystem_ePAfuerAll#5.11.6.1] implementieren. [<=]
A_14418-01 - MTOM-Pflicht bei Verwendung von [ITI-41] und [ITI-43]
Das PS MUSS bei der Umsetzung der IHE XDS-Transaktionen [ITI-41] und [ITI-43] zur Übertragung von Dokumenten eine Kodierung mittels MTOM/XOP [MTOM] gemäß [IHE-ITI-TF-2b#3.39.5] mit Verweis auf [IHE-ITI-TF-2b#3.43.5] verwenden. [<=]
A_15084 - SOAP-Header nach [SOAP]
Das PS MUSS in der Kommunikation mit dem Aktensystem der ePA für alle die SOAP-Nachricht konform zu [SOAP] bilden. [<=]
Das Aktensystem setzt in DocumentEntry.hash eine Prüfsumme eines Dokumentes. Mithilfe dieser Prüfsumme kann ein PS eine Dublettenprüfung durchführen, um nicht unnötig Duplikate von Dokumenten in die ePA einzustellen oder Dokumente mehrfach herunterzuladen.
Das Aktensystem wirft einen Fehler mit dem Fehlercode XDSDuplicateDocument, wenn versucht wird, ein Dokument in die Akte eines Versicherten hochzuladen, das es dort schon gibt. Das Aktensystem führt die Dublettenprüfung mithilfe der Prüfsumme durch.
Ordner können durch die Option "Folder Management" (XDS.b Document Source) verwendet werden. Durch die Assoziation eines Dokumentes zu einem dieser Ordner wird das Dokument dem Ordner der entsprechenden Dokumentenkategorie bzw. Dokumentensammlung zugeordnet. Nur für dynamische Dokumentensammlungen (pregnancy_childbirth) werden Ordner durch Primärsysteme erstellt, ansonsten werden Dokumente und Daten den Ordnern vom Aktensystem zugewiesen.
Die XDS-Option "Folder Management" ist nur für den geschilderten Verwendungszweck zugelassen; ein selbständiges Anlegen oder Bearbeiten von Ordnern und ihrer Metadaten ist nicht möglich. Das Entfernen von Dokumenten aus einem Ordner durch Löschen der entsprechenden Assoziation ist nicht vorgesehen, da dies die direkte Zuordnung gemäß einer Zugriffsunterbindungsregel verletzten könnte.
Weitere übergreifenden Einschränkungen von IHE ITI-Transaktionen sowie Festlegungen spezieller Umsetzungsvorgaben bzgl. einzelner Transaktionen sind in [gemSpec_Aktensystem_ePAfuerAlle] beschrieben.
Wenn im Rahmen der IHE Interface-Beschreibung der Begriff "Patient" verwendet wird, ist im Rahmen der vorliegenden Spezifikation darunter der Aktenkontoinhaber zu verstehen.
3.11.1 Dokumente einstellen [ITI-41]
Ein eingestelltes Dokument kann auch ein existierendes Dokument ersetzen. Dies erfolgt durch Verwendung der „Document Replacement“-Option (XDS.b Document Source). Dazu wird das gleiche Dokument (mit geändertem Inhalt und nebst ggf. geänderten DocumentEntry-Metadaten) erneut hochgeladen. Das neue Dokument erhält den Status „Approved“. Das alte Dokument geht in den Status „Deprecated“. Beide Dokumente werden über eine „Replace“-Association miteinander verbunden, sodass nach dem Einstellen erkennbar ist, dass das neue Dokument das alte ersetzt. Lädt man erneut eine neue Fassung hoch, erhält man zwei Dokumente im Status "Deprecated" und das neueste im Status "Approved".
Alle alten Dokumente (Status "Deprecated") können nach wie vor gefunden und heruntergeladen werden. Einige Suchen erlauben das Filtern nach Status bzw. zeigen per Default auch nur Dokumente im Status „Approved“ an.
Eingestellt (im „Submission Set“) wird das neue Dokument inkl. DocumentEntry-Metadaten, ein Verweis auf das alte Dokument und die verbindende „Replace“-Association (urn:ihe:iti:2007:AssociationType:RPLC).
Das Ersetzen eines existierenden Dokuments mit der XDS-Option „Document Replacement“ eignet sich dafür, eine Änderung an einem bereits bestehenden Dokument abzubilden. Metadaten werden jedoch über Restricted Update Document Set geändert.
3.11.1.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente einstellen sind:
Vorbedingungen:
- Dokumente sind einer KVNR zugeordnet
- Das einzustellende Dokument sollte mit dem Versicherten besprochen sein
- gültige Befugnis
Auslöser:
- Nutzerinteraktion
- Automatische Trigger
Aktivitäten:
- Auswahl der Dokumente
- Ermittlung der Metadaten zu den Dokumenten
- Generierung inklusive Metadaten
- Validierung der Nachricht
- Versand der Nachricht
- Auswertung des Ergebnisses
Resultat:
- Die Antwort gibt Auskunft darüber, ob die Dokumente eingestellt werden konnten oder nicht.
3.11.1.2 Nutzung
A_14253-01 - Metadaten-Pflicht für Dokumente
Das PS MUSS Metadaten ausschließlich aus der in [gemSpec_Aktensystem_ePAfuerAlle] aufgeführten Menge von Metadaten entnehmen. Das Primärsystem MUSS Dokumente, denen es keine passenden Metadaten zuweisen kann, von der Auswahl der einzustellenden Dokumente ausschließen. Das PS MUSS das Metadatenobjekt XDSDocumentEntry entsprechend den Vorgaben aus dem Datenmodell [gemSpec_Aktensystem_ePAfuerAlle#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] befüllen. Das PS MUSS alle mit der Kardinalität [1..1] markierten Metadatenfelder setzen. [<=]
Die Auswahl der Metadaten soll möglichst weitgehend automatisiert werden.
A_16194 - Änderbarkeit der Metadaten - Auswahllisten
Bei der Auswahl der Metadaten zum Zwecke des Einstellens von Dokumenten SOLL das PS insbesondere im Falle erforderlicher Auswahldialoge beachten:
- die Bildung von Auswahllisten erfolgt gemäß Anhang B,
- Auswahllisten sind konfigurativ änderbar,
- Metadaten werden weitestgehend automatisch vorbefüllt,
- Nutzer können Metadaten editieren.
A_20517-02 - Exklusivität der Dokumentenkategorien
Das PS MUSS beim Einstellen von Dokumenten die Kategorien beachten, zu denen Dokumente gehören. Dabei werden Kategorien durch zwei Arten von Foldern umgesetzt:
- Statische Folder. Die Zuordnung zu den Kategorien/Foldern erfolgt am Aktensystem aufgrund der vom PS gesetzten Metadaten. Die Angabe einer FolderUUID beim Hochladen von Dokumenten DARF NICHT erfolgen.
- Dynamische Folder. Dynamische Folder werden gemäß A_21610-* (pregnancy_childbirth) vom PS angelegt und die entsprechenden Dokumente dort eingestellt. Beim Hochladen von Dokumenten MUSS die FolderUUID angegeben werden.
A_22515-02 - Pflicht zum Setzen von Dokumenten-Titeln
Das PS MUSS beim Einstellen von Dokumenten documentEntry.title belegen. Der Titel des Dokumentes MUSS eine fachliche Beschreibung des Dokumentes enthalten. [<=]
Dokumente werden statischen Ordnern automatisch am Aktensystem aufgrund der vergebenen Metadaten zugeordnet. Dokumente werden dynamischer Ordnern (pregnancy_childbirth) hingegen durch das PS zugeordnet.
Das Kinderuntersuchungsheft wird in die ePA des Kindes eingestellt.
A_22514-03 - Titel dynamischer Ordner für Schwangerschaften
Der Leistungserbringer legt bei Bedarf dynamische Ordner für pregnancy_childbirth an. Bei der Anlage dynamischer Ordner MUSS das PS das Metadatum Folder.title folgendermaßen setzen:
- Der dynamische Ordner der Kategorie pregnancy_childbirth identifiziert eine Schwangerschaft. Folder.title MUSS mit dem (ggf. prognostizierten) Entbindungstermin belegt werden.
- Bildungsregel: "Errechneter EBT: " + Datum im Format TT.MM.YYYY Beispiel: "Errechneter EBT: 03.03.2017"
Der errechnete Entbindungstermin im dynamischen Ordner pregnancy_childbirth wird mit dem initial errechneten Wert befüllt. Eine spätere Änderung des Ordnernamens ist zur Identifizierung der Schwangerschaft nicht erforderlich, auch wenn zu einem späteren Zeitpunkt ein anderer Entbindungstermin errechnet werden sollte.
A_20180-04 - Für pregnancy_childbirth dynamischen Ordner auswählen
Falls das hochzuladende Dokument zur Kategorie pregnancy_childbirth gehört, MUSS das PS das hochzuladende Dokument genau einem der dynamischen Ordner pregnancy_childbirth zuweisen, indem es das Dokument in den entsprechenden Ordner hochlädt. Dazu MUSS das PS beim Einstellen im SubmissionSet mit dem DocumentEntry eine zusätzliche Association (FD-DE-HasMember) hinterlegen, die den DocumentEntry mit dem für die gewünschte Unterkategorie bereits existierenden Ordner über ihre jeweilige entryUUID verbindet, vgl. u.a. [IHE-ITI-TF3#4.2.1.3]. [<=]
Die entryUUID des Ordners kann z. B. über die Suche FindFolders mit entsprechendem Filter auf Folder.codeList ermittelt werden.
A_25127 - Keine Verdoppelung dynamischer Ordner
Dynamische Ordner zu einem Anwendungsfall (z.B. zu einer Schwangerschaft) DÜRFEN NICHT doppelt angelegt werden. [<=]
A_14932 - Bildung und Verwendung einer UUID für Dokumente
Das PS MUSS eine DocumentEntry.UniqueID gemäß [ITI-TF-3#4.2.3.2.26] erstellen. Für den XDS Document Service im ePA-Aktensystem wird die DocumentEntry.UniqueID in die Metadaten der IHE-Nachrichten eingestellt:
- DocumentEntry.@id
- ExternalIdentifier.@id
Wenn für das Feld SubmissonSet.AuthorPerson keine Person als Einsteller angegeben werden kann, ist das Feld mit Werten zu befüllen, mit denen die einstellende Softwarekomponente beschrieben wird. Laut [gemSpec_Aktensystem_ePAfuerAlle#A_14762*] wird die Softwarekomponente eines Geräts als Nachname und ggf. als Vorname(n) eingetragen.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY
Ein Dokument kann verborgen eingestellt werden, wenn ein entsprechender Wunsch des Versicherten bekannt ist.
A_24672 - Verbergendes Einstellen von Dokumenten
Auf Wunsch des Versicherten MUSS das PS den confidentialityCode eines Dokumentes auf "CON" im Code System "ePA-Vertraulichkeit" mit der OID "1.2.276.0.76.5.491" setzen, um ein Dokument zu verbergen. [<=]
Der Wert "CON" wird vom Aktensystem nicht persistiert und ausschließlich für das Verbergen von Dokumenten mittels der General Deny Policy verwendet. Ein verborgen eingestelltes Dokument ist auch für den Einstellenden nicht ohne weiteres zu lesen und nicht durch Suchoperationen auffindbar.
A_25142 - Ändern und Löschen verborgener Dokumente
Das PS KANN ein Dokument, das es verborgen eingestellt hat, löschen oder ändern, obwohl es auch für sich selbst verborgen ist. Dazu muss das PS die DocumentEntry.entryUUID des vom PS verborgen in die ePA eingestellen Dokumentes persistieren. Da es die DocumentEntryUUID nicht mehr mittels Find ermitteln kann. muss es gemäß [IHE-ITI-TF-2b#3.42.4.1.3.7] beim Einstellen des Dokumentes die DocumentEntry.entryUUID als valide UUID selber setzen, anstatt eine symbolische ID zu verwenden. Beim nachfolgenden Löschen, Ändern der Metadaten oder Ersetzen des Dokumentes mit der Option RPLC (replace) wird diese persistierte DocumentEntry.entryUUID verwendet. [<=]
Das PS soll den Nutzer in einem Warnhinweis darauf aufmerksam machen, dass es nicht ohne weiteres (bzw. nicht ohne zusätzlichen Aufwand, wie in A_25142-* beschrieben) möglich ist, das verborgen eingestellte Dokument anzuzeigen, zu ändern oder zu löschen.
A_23329-01 - Einschränkung der Änderbarkeit von Metadaten beim Hochladen eines Dokumentes unter Verwendung der RPLC-Option
Das Primärsystem DARF beim Hochladen eines Dokumentes mittels DocumentRepository_ProvideAndRegisterDocumentSet-b bei Nutzung der RPLC-Option an Metadaten des Dokumentes KEINE Veränderung vornehmen. [<=]
Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (Kennzeichnung über entsprechende Auswahl aus SubmissionSet.AuthorRole, und dem konfigurierten XDSDocumentEntry.healthcareFacilityTypeCode) kategorisiert, um sie von Dokumenten zu unterscheiden, die vom Versicherten selbst (SubmissionSet. AuthorRole="102") oder von Kostenträgern (SubmissionSet.AuthorRole="105") eingestellt wurden. Das heißt u. a., dass die Codes für Versicherte und Kostenträger ("102" und "105") dabei explizit nicht verwendet werden dürfen.
A_15621-02 - Kategorisierung der vom LE eingestellten Dokumente
Das PS MUSS die von der LEI eingestellten Dokumente kategorisieren:
- documentEntry.author oder submissionset.author sind gemäß den Vorgaben von [gemSpec_Aktensystem_ePAfuerAlle]#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] zu befüllen;
- XDSDocumentEntry.author.authorSpecialty wird mit einem die Fachrichtung der LEI beschreibenden Wert der Selbstauskunft der LEI befüllt, es sei denn, der Autor des Dokumentes entstammt nicht der das Dokument einstellenden Institution;
- XDSDocumentEntry.healthcareFacilityTypeCode wird mit einem den Typ der LEI beschreibenden Wert der Selbstauskunft der LEI (A_15086-*) befüllt, es sei denn, der Autor des Dokumentes entstammt nicht der das Dokument einstellenden Institution;
- Das PS MUSS sicherstellen, dass der XDSDocumentEntry.healthcareFacilityTypeCode nicht mit den Werten "KTR" oder "EGA" belegt wird.
A_24967 - Konvertieren von PDF in PDF/A
Das PS MUSS Dokumente im PDF-Format, die in das Aktenkonto eingestellt werden sollen, automatisch in das Format PDF/A-1 und PDF/A-2 konvertieren und ausschließlich das Dokument im PDF/A-Format in das Aktenkonto übermitteln. [<=]
Die Unterstützung für RPLC (replace) durch das Aktensystem ermöglicht, dass Dokumente durch eine neue Version des gleichen Dokuments ersetzt werden können. Das alte Dokument wechselt in den Status (DocumentEntry.availabilityStatus) "Deprecated" und wird mit dem neuen Dokument (Status "Approved") über eine "RPLC"-Association verbunden. Der AvailabilityStatus wird beim Dokumente einstellen ausschließlich vom Aktensystem automatisiert gesetzt bzw. geändert.
3.11.2 Dokumente suchen [ITI-18]
Das Suchen nach Dokumenten erfolgt auf den Metadaten des Dokumentes, nicht auf den Inhalten des Dokumentes selbst. Die Suche kann zur Anzeige der Metadaten eines Dokumentes verwendet werden.
Die Suche erfolgt ausschließlich auf Dokumenten, die für den Leistungserbringer sichtbar sind.
Zur Suche nach Dokumenten sind u. a. folgende Filterfunktionen möglich:
- kein Filter
- Zeitintervall
- Dokumentenkategorie, darunter auch Dokumentenkategorie 1a (Suche über Ordner)
- Dokumentenquelle (z. B. eine bestimmte Facharztgruppe)
- SubmissionSet-Identifier
- Submission-Zeit.
Für die Suche über Parameter:
- $XDSDocumentEntryTitle und
- $XDSDocumentEntryAuthorInstitution
- XDSDocumentEntry.comment
ist eine Ähnlichkeitssuche möglich, wie auch beim Parameter $XDSDocumentEntryAuthorPerson. Diese Ähnlichkeitssuche beruht auf dem SQL-Suchmuster LIKE, in dem mit einer Kombination aus dem SQL-Wildcard-Zeichen "%" und dem SQL-Platzhalterzeichen "_" Suchanfragen zusammengestellt werden, in denen nach einer Kombination aus bestimmten und beliebigen Zeichen gesucht wird.
Zudem können bei Verwendung der folgenden Suchparameter auch auf diese Suchparameter bezogen unscharfe, d. h. leicht abweichende, Suchergebnisse zurückgegeben werden:
- $XDSDocumentEntryTitle
- $XDSDocumentEntryAuthorInstitution
- $XDSDocumentEntryAuthorPerson
- $XDSSubmissionSetAuthorPerson
- XDSDocumentEntry.comment.
Die Umsetzung der Suche von Dokumenten über Metadaten ist in vielfältiger Form möglich, insbesondere als
- Suchen mittels einer Suchmaske;
- anlassbezogene Suche ohne Suchmaske, z. B. aus dem UseCase "Benachrichtigung verwalten" heraus.
Je nachdem, ob returnType auf LeafClass oder ObjectRef gesetzt wird, enthält die Response der Suche eine Objektliste im Result (LeafClass) oder eine Liste von Objektidentifiern (ObjectRef), s. [ITI-18#3.18.4.1.2.6].
3.11.2.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente suchen sind:
Vorbedingungen:
- Ausgewählte KVNR
- gültige Befugnis
Auslöser:
- Nutzerinteraktion
- anlassbezogene Suche
Aktivitäten:
- Auswahl der Suchkriterien
- Generierung und Versand der Nachricht
- (optional) Filterung der Ergebnisse
- (optional) Sortierung des Ergebnisses
Resultat:
- Ergebnismeldung
- Dokumenten-UUID-Liste (XDSDocumentEntry_uniqueId)
3.11.2.2 Nutzung
A_16336-01 - Eingrenzung von Suchergebnissen
Das PS SOLL verschiedene Strategien nutzen können, um die Menge der ePA-Dokumente einer Akte auf die für den LE relevanten Dokumente zu reduzieren:
- Die Auswahl der Metadaten-Suchstrategie (Wahl eines geeigneten StoredQuery)
- Je nach Wahl des Suchtyps und der Ergebnistypen LeafClass oder ObjectRef werden die Dokumente direkt oder nach einem zusätzlichen Auswahlschritt angezeigt:
-
- Leafclass: Auswahl anhand der Metadaten-Suchergebnisse
- ObjectRef: Direkte Auswahl der anzuzeigenden Dokumente ohne zusätzlich verfügbare Metadaten
- Die Suche kann in einigen StoredQueries bezüglich des Dokumentenstatus (DocumentEntry.availabilityStatus) eingeschränkt werden auf "Deprecated" oder "Approved".
Das Ergebnis der Suche in der Dokumenten-Registry sind Mengen eindeutiger Dokumenten-Identifier als UUID.
A_17198-02 - Nutzung des um XDSDocumentEntryTitle erweiterten Registry Stored Query FindDocuments
Das PS MUSS den in [ITI-18] nicht enthaltenen zusätzlichen Anfragetyp FindDocumentsByTitle mit der Query-ID "urn:uuid:ab474085-82b5-402d-8115-3f37cb1e2405" und denselben Parameternutzungsvorgaben der Registry Stored Query FindDocuments gemäß [IHE-ITI-TF-2b#3.38] in Verbindung mit dem zusätzlich zu [ITI-38] eingeführten Suchparameter $XDSDocumentEntryTitle nutzen können. Der zusätzliche Parameter $XDSDocumentEntryTitle ist verpflichtend und filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.title . [<=]
A_25187 - Nutzung des um XDSDocumentEntryComment erweiterten Registry Stored Query FindDocuments
Das PS MUSS den in [ITI-18] nicht enthaltenen zusätzlichen Anfragetyp FindDocumentsByComment mit der Query-ID "urn:uuid:2609dda5-2b97-44d5-a795-3e999c24ca99" und denselben Parameternutzungsvorgaben der Registry Stored Query FindDocuments gemäß [IHE-ITI-TF-2b#3.38] in Verbindung mit dem zusätzlich zu [ITI-38] eingeführten Suchparameter $XDSDocumentEntryComment nutzen können. Der zusätzliche Parameter $XDSDocumentEntryComment ist verpflichtend und filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.comment [<=]
Tabelle 12: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen
Fehlercode |
Beschreibung |
Handlungsanweisung |
---|---|---|
XDSTooManyResults |
Die Ergebnismenge der Suche ist zu groß. |
Die Suche verfeinern und neu durchführen bis das Aktensystem den Fehler nicht mehr wirft. Die Reduktion von Metadaten-Suchergebnissen erfolgt gemäß A_16336. |
Durch die Einführung der Folder für jede Kategorie, also auch für solche der Kategorie patient, kann eine Suche mittels FindFolders auf Dokumentenkategorie erfolgen, die in Folder.Codelist angegeben sind.
A_24457 - Unveränderbarkeit des eindeutigen DokumentenIdentifiers in der referenceIdList
Das Aktensystem hinterlegt beim initialen Einstellen eines Dokumentes in der referenceIdList die DocumentEntry.uniqueId des initial eingestellten Dokumentes als rootDocumentUniqueId im Format:
<DocumentEntry.uniqueId>^^^^urn.gematik.iti.xds.2023.rootDocumentUniqueId.
Über alle Versionen des Dokumentes bleibt diese rootDocumentUniqueId erhalten. Das PS DARF die rootDocumentUniqueId NICHT durch ein RestrictedUpdateDocumentSetRequest ändern, damit mittels einem Find auf der referenceIdList ein Dokument in allen Versionen gefunden werden kann. [<=]
Die Metadaten der StoredQuery-Response sind geeignet, dem Nutzer weitere Filtermöglichkeiten zu geben, um die Ergebnismenge der Dokumenten-Anzeige einzuschränken.
A_15030 - Filteroptionen für den Nutzer
Das PS MUSS mittels der Metadaten aus der StoredQuery-Response Filteroptionen anbieten, mit denen Leistungserbringer die Ergebnismenge für die Anzeige von Dokumenten einschränken können. [<=]
3.11.3 Dokumente laden [ITI-43]
Falls das anzuzeigende Dokument nicht schon mit seiner Dokumenten-ID bekannt ist, und eine Liste vorliegt, SOLL das PS die Auswahl des anzuzeigenden Dokumentes unter Auswertung von Metadaten ermöglichen.
3.11.3.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente laden sind:
Vorbedingungen:
- Auswahl KVNR
- gültige Befugnis
- XDSDocumentEntry_uniqueId (DocumentEntry.uniqueId) bekannt
Auslöser:
- Fachliches Erfordernis
- Nutzerinteraktion
Aktivitäten:
- Auswahl XDSDocumentEntry_uniqueId
- Generierung und Versand der Nachricht
- Dekodierung des empfangenen Dokumentes (Base64 oder XOP)
- Anzeige des angefragten Dokumentes oder der Dokumentenmenge
- Auswertung des Ergebnisses
Resultat:
- Das angefragte Dokument oder die Dokumentenmenge liegt vor und kann in das PS übernommen werden
3.11.3.2 Nutzung
Die RetrieveDocumentSet Request Message muss mindestens eine DocumentUniqueID enthalten.
Das PS soll die DocumentEntry.UniqueID gemäß [ITI-TF-3#4.2.3.2.26] nicht nur für das Laden von Dokumenten, sondern auch in der Primärakte verwenden. Eine aktenweit eindeutige DocumentEntry.UniqueID ermöglicht dem PS eine zuverlässige Benachrichtigungsverwaltung (s. Kap. 5.3.1 und Kap. 5.2.3).
Ein http-Request im MTOM/XOP - Format (type="application/xop+xml") führt zu einer MTOM-Response.
Im Primärsystem sollte eine Absicherung gegen mögliche Schadsoftware in heruntergeladenen Dokumenten erfolgen.
A_17769 - Schutzmaßnahmen nach Plausibilitätsprüfungen an heruntergeladenen Dokumenten
Das PS SOLL Maßnahmen zur Absicherung gegen mögliche Schadsoftware in heruntergeladenen Dokumenten ergreifen, falls:
- das Format oder der Inhalt des heruntergeladenen Dokumentes nicht mit dem angegebenen Dokumententyp in den Metadaten übereinstimmen;
- das Format oder der Inhalt des heruntergeladenen Dokumentes nicht den zulässigen Dokumententypen im Metadatum mimeType gemäß [gemSpec_Aktensystem_ePAfuerAlle#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] entspricht.
A_17770 - Maßnahmen zum Schutz vor heruntergeladenen Dokumenten
Das PS MUSS bei Anzeige oder persistenter Speicherung eines heruntergeladenen Dokumentes sicherstellen, dass geeignete Maßnahmen zum Schutz von PS und LE-Umgebung durchgeführt werden. [<=]
Geeignet wären insbesondere folgende Maßnahmen:
- Anzeigesoftware in einer Sandbox oder einem Modus betreiben, das die Umgebung der LEI vor einer potentiellen Gefährdung durch das Dokument schützt;
- vor der Anzeige eines Dokumentes Sonder-und Meta-Zeichen im Dokument für die jeweilige Anzeigesoftware mit einer geeigneten Escape-Syntax entschärfen (als Schutz z. B. gegen Injection-Angriffe aus [OWASP Top 10#A1]).
- den Nutzer darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der Nutzer zum Selbstschutz vornehmen kann.
Eine Beispielimplementierung eines Antiviren-Gateways findet sich im Fachportal der gematik.
A_23621-02 - Den LE informieren über fehlerhafte medizinische Dokumente
Das PS MUSS den Nutzer mit einer Fehlermeldung informieren, wenn nach dem Download aus dem Aktensystem fehlerhafte medizinische Dokumente bzw. Teildokumente einer Sammlung erkannt werden. Sofern es sich um eine fehlerhaftes Teildokument einer Sammlung handelt, MÜSSEN die korrekten Teildokumente der Sammlung trotzdem angezeigt werden, soweit dies möglich ist.
[<=]
A_15089 - Protokollierung einer Dokumentenanzeige im Übertragungsprotokoll
Das Anzeigen von Dokumenten MUSS als Übertragung eines Dokumentes aus der ePA in das PS im Übertragungsprotokoll vermerkt werden. [<=]
A_16198 - Prüfung der Zuordnung von Dokument zu Akte
Die PatientId enthält die Versicherten-ID und SOLL vom PS zur Überprüfung verwendet werden, ob das angezeigte Dokument vor einem möglichen Abspeichern dem richtigen Versicherten bzw. der richtigen lokalen Patientenakte zugeordnet ist. [<=]
A_16196 - Verarbeitung strukturierter Inhalte
Das PS SOLL in der Lage sein, aus ePA-Dokumenten, deren Inhalte strukturiert vorliegen, die strukturierten Inhalte in die Primärdokumentation des Versicherten zu übernehmen. [<=]
A_21503-01 - Daten digitaler Gesundheitsanwendungen auslesen
Das Primärsystem MUSS DiGA-Daten, deren Formatvorgabe als Medizinisches Informationsobjekt gemäß [gemSpec_DM_ePA] definiert sind, bei vorliegender Berechtigung aus dem ePA-Aktensystem des Versicherten auslesen können. [<=]
Wenn DiGA-Daten als PDF bereit gestellt werden, ist eine Anzeige der DiGA-Daten mittels eines PDF-Viewers möglich.
3.11.4 Dokumente löschen [ITI-62]
Der Leistungserbringer löscht Dokumente und dynamische Ordner in Absprache mit dem Versicherten.
3.11.4.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente löschen sind:
Vorbedingung:
- Auswahl KVNR
- gültige Befugnis
- Absprache zwischen LE und Versicherten zur Löschung liegt vor
- Die zu löschenden Dokumente innerhalb einer Document-Request-Liste anhand ihrer XDSDocumentEntry.entryUUID
Auslöser:
- Nutzerinteraktion
Aktivitäten:
- Auswahl des Dokumentes bzw. der Dokumente unter Verwendung der XDSDocumentEntry.entryUUID
- Sicherheitsabfrage
- Generierung und Versand der Nachricht
- Auswertung des Ergebnisses
Resultat:
- Im Erfolgsfall sollte im PS die UUID gelöscht werden, falls sie zuvor persistent gespeichert wurde.
3.11.4.2 Nutzung
Das Löschen von Ordnern ist nur in einem eingeschränkten Umfang möglich. Das Aktensystem akzeptiert den Lösch-Request nur dann, wenn er auf einen dynamischen Folder abzielt, und wenn dieser Request nicht die im Folder enthaltenen Dokumente, SubmissionSets und Assoziationen enthält. Diese werden vielmehr vom Aktensystem selbst zusammen mit dem Folder Object gelöscht. Falls im dynamischen Ordner, der gelöscht werden soll, Dokumente vorliegen, muss daher zuvor eine Absprache mit dem Versicherten stattgefunden haben, da eine Löschung von Dokumenten immer in Absprache mit dem Versicherten stattfinden soll.
3.11.5 Aktualisieren von Metadaten [ITI-92]
Bei Dokumenten, bei denen Metadaten fehlen oder falsch sind, sollte das Primärsystem die korrekten Metadaten ändern bzw. korrigieren können. Dazu dient die Schnittstelle updateDocumentSet. In der Operation können sowohl eigene, als auch durch Dritte eingestellte Dokument-Metadaten bearbeitet werden, soweit es die Berechtigung des Nutzers erlaubt. Ein Herunterladen des Dokumentes, auf die sich die Metadaten beziehen, ist zum Editieren der Metadaten nicht erforderlich.
3.11.5.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Aktualisieren von Metadaten sind:
Vorbedingungen:
- Auswahl KVNR
- gültige Befugnis
- Notwendigkeit, die Metadaten zu aktualisieren, liegt vor
- Die zu aktualisierenden Dokumente innerhalb einer Document-Request-Liste liegen vor anhand ihrer XDSDocumentEntry.entryUUID
Auslöser:
- Nutzerinteraktion
Aktivitäten:
- Auswahl des Dokumentes bzw. der Dokumente unter Verwendung der XDSDocumentEntry.entryUUID
- Generierung und Versand der Nachricht
Resultat:
- Im Erfolgsfall sollten auch im PS die Metadaten in der aktuellen Form gespeichert sein, falls sie zuvor persistent gespeichert wurden.
3.11.5.2 Nutzung
A_24386 - Aktualisierbare Metadaten
Das PS MUSS sich beim Anwendungsfall Aktualisieren von Metadaten des DocumentEntry mittels RestrictedUpdateDocumentSet beschränken auf das Ändern der Dokumentmetadaten
- author
- classCode
- comments
- confidentialityCode (Der UseCase "Metadaten Aktualisieren" kann jedoch nicht für das Verbergen von Dokumenten verwendet werden, sondern nur für Nutzung des Codes außerhalb der ePA)
- eventCodeList
- formatCode
- healthcareFacilityTypeCode
- languageCode
- legalAuthenticator
- practiceSettingCode
- referenceIdList
- serviceStartTime
- serviceStopTime
- title
- typeCode
- URI
A_25166 - Keine Änderung von Metadaten von Dokumenten einer mixed- oder uniform-Sammlung
Das PS MUSS unterbinden, dass Metadaten von Dokumenten einer mixed- oder uniform-Sammlung geändert werden. [<=]
Das Ändern von Metadaten von Dokumenten, die ein PS selbst eingestellt hat, jedoch verborgen, ist in A_25142 beschrieben.
3.11.6 Artefakte
3.11.6.1 Namensräume
Tabelle 13: Tab_ILF_ePA_Namensräume
Präfix | Namensraum |
---|---|
ds | http://www.w3.org/2000/09/xmldsig |
ec | http://www.w3.org/2001/10/xml-exc-c14n# |
wst | http://docs.oasis-open.org/ws-sx/ws-trust/200512 |
wsu | http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd |
xsi | http://www.w3.org/2001/XMLSchema-instance |
fed | http://docs.oasis-open.org/wsfed/federation/200706 |
wsp | http://schemas.xmlsoap.org/ws/2004/09/policy |
wsa | http://www.w3.org/2005/08/addressing |
xds | urn:ihe:iti:xds-b:2007 |
rmd | urn:ihe:iti:rmd:2017 |
rim | urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 |
lcm | urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0 |
query | urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 |
soap12 | http://www.w3.org/2003/05/soap-envelope |
3.11.6.2 WSDLs und Schemata
Die normativen WSDLs und Schemata der ePA werden von der gematik zur Verfügung gestellt.
Für den Fall, dass es sich dabei um IHE-Artefakte handelt, gilt, dass diese Artefakte denjenigen entsprechen, die von IHE im entsprechenden Zeitraum bereitstellt.
3.11.7 Testunterstützung
Zur Unterstützung von Tests im Zusammenhang mit den oben geschilderten Funktionsmerkmalen dürfen keine Echtdaten verwendet werden.
3.12 Informationsmodell
A_21651-02 - Verarbeitung von Dokumenten der gesetzlich vorgegebenen Kategorien
Das Primärsystem MUSS Dokumente der in [gemSpec_Aktensystem_ePAfuerAlle#A_19303-*] aufgeführten Kategorien im Rahmen der dort aufgeführten berufsgruppenspezifischen Zugriffsregeln verarbeiten können. [<=]
A_14246 - Verarbeitbarkeit ausgelesener Dokumente und Formate
Das Primärsystem MUSS anhand der Metadaten eines durch Dokumente Suchen aufgefundenen Dokumentes erkennen, ob es in der Lage ist, diese zu verarbeiten, insbesondere anhand von mimeType, formatCode, classCode und typeCode des DocumentEntry in [gemSpec_IG_ePA]. [<=]
3.12.1 Metadaten
A_24505 - Automatisiertes Setzen von Metadaten
Das PS SOLL Metadaten automatisiert aus den Primärdaten der Versicherten übernehmen und erzeugen, ohne dass eine händische Eingabe von Metadaten zwingend erforderlich ist. Die manuelle Belegung der Werte von Metadaten soll auf ein Minimum begrenzt werden. Wertebereiche (Value Sets) für ePA-Dokumente sind je nach Festlegung von [gemSpec_Voc_ePA] zu benutzen. [<=]
A_23556-01 - Einheitliche Metadaten-Vorgaben für unstrukturierte Dokumente ohne ImplementationGuide
Das PS SOLL die Klinische Dokumentenklassen-Liste (KDL) nutzen, um Dokumente zu kennzeichnen. Beispiele für ein Mapping zwischen KDL und IHE auf Basis von [IHE-ITI-VS] und [KDL-ILF] liefert Tab_ILF_ePA_KDL-Mapping. Weitere Dokumententypen sollen entsprechend belegt werden.
Tabelle 14: Tab_ILF_ePA_KDL-Mapping
Dokumententyp | classCode | typeCode | eventCodeList (KDL) | OID Code System | Anzeigename |
---|---|---|---|---|---|
Arztbrief (nicht IG eArztbrief) | BRI | BERI | - | - | Arztbericht /Arztbrief |
Krankenhausentlassungsbericht | BRI | BERI | AD010104 | 1.2.276.0.76.5.533 | Krankenhausentlassungsbericht |
Befund/Vorbefund/Altbefund | BEF | BEFU | - | - | Ergebnisse Diagnostik |
Röntgenbefund | BEF | BILD | DG020110 | 1.2.276.0.76.5.533 | Ergebnisse bildgebender Diagnostik (Radiologie) |
Sonographiebefund | BEF | BILD | DG020111 | 1.2.276.0.76.5.533 | Ergebnisse bildgebender Diagnostik (Sonographie) |
EKG-Auswertung | BEF | FUNK | DG060111 | 1.2.276.0.76.5.533 | Ergebnisse Funktionsdiagnostik (EKG) |
Histologiebefund | BEF | PATH | PT080102 | 1.2.276.0.76.5.533 | Pathologiebefundberichte |
Lungenfunktionstest | BEF | FUNK | DG060108 | 1.2.276.0.76.5.533 | Ergebnisse Funktionsdiagnostik (Lunge) |
Bild | BIL | BILD | - | - | Ergebnisse bildgebender Diagnostik |
Foto | BIL | FOTO | - | - | Fotodokumentation |
OP-Bericht | DUR | OPDK | OP150103 | 1.2.276.0.76.5.533 | OP-Dokumente (OP-Bericht) |
OP-Plan/OP-Vorbereitung | DUR | OPDK | - | - | OP-Dokumente (OP-Vorbereitung) |
Dialyseprotokoll | DUR | FPRO | VL040202 | 1.2.276.0.76.5.533 | Therapiedokumentation (Dialyse) |
Überweisung | VER | AUFN | AU050102 | 1.2.276.0.76.5.533 | Überweisung (Überweisunsgschein) |
Krankenhauseinweisung | VER | AUFN | AU050101 | 1.2.276.0.76.5.533 | Verordnung von Krankenhausbehandlung |
Anamnese | DUR | AUFN | - | - | Anamnese |
Anamnesebogen | DUR | AUFN | AU010101 | 1.2.276.0.76.5.533 | Anamnesebogen |
Therapievorschlag/Therapiebedarf | ANF | FPRO | - | - | Therapiedokumentation |
Histologieanforderung | ANF | PATH | PT080101 | 1.2.276.0.76.5.533 | Histologieanforderung |
Kontaktdaten Angehörige | ADM | PATD | - | - | Kontaktdaten Angehörige |
Neugeborenensceening | BEF | GEBU | SD070104 | 1.2.276.0.76.5.533 | Neugeborenenscreening |
Einstellen von Dokumenten
Auf die Auszeichnung von in die ePA einzustellenden Dokumenten durch Metadaten kann das PS spezifische Einschränkungen und Vorbelegungen umsetzen:
- abhängig vom Nutzungskontext bzw. Anwendungsfall;
- gemäß sektorspezifischen Besonderheiten;
- je nach LE-spezifischen Besonderheiten und Konfigurationen, etwa in Zusammenhang mit der Selbstauskunft der Leistungserbringer.
Wenn Leistungserbringer Dokumente einstellen, bei denen sie nicht selbst der Autor sind, kann es passieren, dass die Telematik-ID des ursprünglichen Dokumenten-Autors nicht in DocumentEntry.author.authorInstitution angegeben wurde. Ein Herunterladen und eine Weiterverarbeitung solcher Dokumente soll möglich sein, auch wenn eine strenge Validierung des Metadatums aufgrund der fehlenden Telematik-ID nicht erfolgreich sein sollte.
A_15748-03 - Metadaten-Vorbelegungen bei Dokumenten, die nicht aus der eigenen LEI stammen
Für den Fall, dass LE der eigenen LE-Institution nicht die Autoren der einzustellenden Dokumente sind, KANN das PS in seinen Dialogen zur Beschreibung des Dokumenten-Autors und seiner Institution Auswahllisten von Wertebereiche der Metadaten author, authorSpecialty, healthcareFacilityTypeCode und practiceSettingCode in einer verkürzten Form zur Auswahl bringen. [<=]
A_16206-02 - Empfehlungen zur sektorspezifischen Reduktion von Auswahllisten
Beim Einstellen von Dokumenten SOLLEN die in Anhang B aufgeführten sektorspezifische Empfehlungen zur Reduktion von Auswahllisten mögliche Werte für die Metadaten authorRole und typeCode beim Einstellen von Dokumenten beachtet werden. [<=]
Auslesen von Dokumenten
Insoweit Metadaten zur Anzeige gebracht werden, muss das PS die Anzeigenamen der Metadaten in eine lesbare Form bringen. Die Anzeige von Metadaten ist insbesondere zu dem Zwecke des Filterns großer Ergebnismengen erforderlich sowie zur Auswahl der gegebenenfalls herunterzuladenden Dokumente. Zum Filtern über Dokumentenmengen kann es nützlich sein, nicht nur Metadaten der DocumentEntries, sondern auch Metadaten der SubmissionSets anzuzeigen, um ein Ausblenden bestimmter Suchergebnisse zu ermöglichen.
3.12.2 Strukturierte Dokumente
In der ePA können strukturierte Dokumente verarbeitet werden. Strukturierte Dokumente und deren Zuordnung zu Sammlung und Sammlungstypen sind in [gemSpec_IG_ePA] und in [gemSpec_Aktensystem_ePAfuerAlle] beschrieben.
3.12.2.1 Medizinische Informationsobjekte
Für strukturierte Dokumente gelten die Anwendungsfälle zum Laden, Suchen, Einstellen und Löschen von Dokumenten. Besteht der Bedarf nach mehreren Sammlungen des gleichen Typs in den dynamischen Ordnern pregnancy_childbirth, so wird jeweils ein dynamischer Ordner (je Schwangerschaft) angelegt. Beim erstmaligen Erstellen einer dynamischen Sammlung muss vom Primärsystem für diese Sammlung ein Ordner angelegt werden.
Mit ePA 3.0 gibt es keine dynamischen Ordner für Kinder in der Akte eines Elternteils mehr. Die Nutzung von dynamischen Ordnern für Kinder, wie sie in ePA 2.6 noch möglich war, wird ab ePA 3.0 mit einem Fehler abgewiesen. Daten von Kindern MÜSSEN mit ePA 3.0 in den Akten der Kinder verarbeitet werden.
A_25008 - Nutzung des childrecord in der Akte des Kindes
Das PS MUSS für die Nutzung von Dokumenten der Kategorie child die Akte des Kindes verwenden. Ebenso müssen Zugriffe auf andere Dokumente mit medizinischen Daten von Kindern in deren ePAs durchgeführt werden. [<=]
3.12.2.2 NFD, DPE und eMP
Ein Notfalldatensatz (NFD) oder ein Datensatz persönliche Erklärungen (DPE), der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_NFDM] von der eGK gelesen, vgl. auch [gemSpec_InfoNFDM], oder er liegt bereits im PS vor. Analog wird der elektronischen Medikationsplan (eMP) gemäß [gemILF_PS_AMTS] und [gemSpec_Info_AMTS] von der eGK gelesen, falls er nicht schon im PS vorliegt, und in der ePA verarbeitet. Die Einwilligung in die Nutzung des eMP wird nicht in der ePA gespeichert.
NFD, DPE und eMP werden im Base64-Format gespeichert. Die Datensätze werden so, wie sie aus der eGK ausgelesen werden, in das Element <xds:Document> eingefügt, das ein Attribut @id enthält, das mit dem rim:ExtrinsicObject/@id übereinstimmt.
3.12.2.3 Elektronischer Arztbrief im DischargeLetterContainer-Format
Falls ein eArztbrief im Format als HL7 CDA R2-Dokument vorliegt, ohne dass der eArztbrief eine PDF-Darstellung hat, soll er direkt im Format mimeType = application/xml im XDS Document Service der ePA verwaltet werden. Ein eArztbrief, der als reines PDF-Dokument in die ePA eingestellt werden soll, soll direkt im Format mimeType = application/pdf in den XDS Document Service der ePA verwaltet werden.
Der eArztbrief DischargeLetterContainer-Format hat gemäß [Richtlinie eArztbrief] die verpflichtenden Teile PDF-Dokument und CDA-XML (nur der CDA-Header ist verpflichtend). Um diesen eArztbrief in die ePA einzustellen und wieder auszulesen, wird auf das XML-Containerformat DischargeLetterContainer (s. Abb_ILF_ePA_eAB-XML-Containerformat) nach [PHR_Common.xsd] zurückgegriffen.
Abbildung 7: Abb_ILF_ePA_eAB-XML-Containerformat
A_14244-02 - Verarbeitungsvorschrift für eAB im DischargeLetterContainer-Format
Falls der eArztbrief im DischargeLetterContainer-Format gemäß [Richtlinie eArztbrief]] in zwei Anteilen vorliegt (einem CDA-Anteil und einem PDF-Anteil), MUSS das PS beide Teile gemeinsam in eine XML-Container-Struktur nach [PHR_Common.xsd] einstellen und diese gemeinsam in einem SubmissionSet in den XDS Document Service der ePA einstellen. In diesem SubmissionSet MÜSSEN die Metadaten konform zu den Vorgaben des Implementation Guides des eArztbriefes ig-eab* in [gemSpec_IG_ePA] gesetzt werden. [<=]
Die folgende XML-Struktur für einen Container mit eArztbrief im DischargeLetterContainer-Format wird festgelegt:
Tabelle 15: XML-Struktur für Arztbrief im DischargeLetterContainer-Format
Element-, Attribut- oder Textknoten |
Opt.
|
Nutzungsvorgabe |
||
---|---|---|---|---|
DischargeLetterContainer |
R
|
|||
PDF |
R
|
Base64-kodierter Arztbrief in PDF-Repräsentation gemäß [Richtlinie eArztbrief] |
||
CDA |
R
|
|||
@level |
O
|
Der Wert "1", "2" oder "3" MUSS gesetzt werden, um den CDA-Level des Dokuments zu kennzeichnen. Der CDA-Level DARF weiterhin NICHT gesetzt werden, sofern der CDA Body gemäß [Richtlinie eArztbrief] leer ist. |
||
text() |
R
|
Base64-kodierter Arztbrief in CDA-Repräsentation gemäß [VHITG_AB] |
A_16246-02 - Auslesen des eArztbriefes im DischargeLetterContainer-Format
Beim Auslesen eines eArztbriefes mit formatCode="Code=urn:gematik:ig:Arztbrief:r3.1" MUSS das PS die zwei Anteile (den CDA-Anteil und den PDF-Anteil) aus der XML-Container-Struktur DischargeLetterContainer nach [PHR_Common.xsd] aus dem XDS Document Service herauslesen und als eArztbrief im DischargeLetterContainer-Format gemäß [Richtlinie eArztbrief] weiterverarbeiten und den PDF-Anteil zur Anzeige bringen können. [<=]
3.12.3 Selbstauskunft
A_15086-08 - Selbstauskunft der LE-Institution mit Belegung von Default-Werten
Das PS MUSS dem LE die Möglichkeit zur Hinterlegung einer Default-Konfiguration von Metadaten geben. Die Selbstauskunft der LE-Institution MUSS zur Befüllung der Metadaten in Tab_ILF_ePA_Datenfelder_Selbstauskunft automatisiert herangezogen werden können.
Tabelle 16: Tab_ILF_ePA_Datenfelder_Selbstauskunft
Vorkonfigurierbare Werte für DocumentEntry und SubmissionSet | Default-Konfiguration unter Beachtung von [gemSpec_Aktensystem_ePAfuerAlle] und [IHE-ITI-VS] |
---|---|
authorPerson | Person, die im Default-Fall als Autor von Dokumenten innerhalb der LEI fungiert |
authorInstitution | Im Normalfall die Institution, welche die SMC-B beantragt hat |
authorRole | Übliche Prozessrolle des Autors der LEI, in der das PS installiert ist |
authorSpecialty | Fachrichtung des Default-Autors |
authorTelecommunication | Telekommunikationsdaten der LEI, in der das PS installiert ist |
healthcareFacilityTypeCode | Art der Einrichtung, in der das PS installiert ist |
practiceSettingCode | Fachrichtung der Einrichtung, in der das PS installiert ist |
languageCode | Sprache, in welcher üblicherweise der menschenlesbare Teil des Dokuments abgefasst ist |
Die Telematik-ID der Leistungserbringerinstitution muss in vielen Nachrichten angegeben werden. Sie sollte aus der SMC-B ausgelesen werden und im PS persistent gespeichert werden.
Die Telematik-ID ist von den Kartenherausgebern der SM-B festgelegt und immer im Attribut "registrationNumber" im Admission-Element der Extension der SMC-B-Zertifikate (C.HCI.AUT, C.HCI.ENC,C.HCI.OSIG) eingetragen. Wenn nicht explizit vom Antragsteller eine neue Telematik-ID angefordert wird, wird bei Ausgabe von Folge- und Ersatzkarten die bisherige Telematik-ID wiederverwendet. Eine generelle Vorgehensweise kann die gematik hierfür nicht geben, da die Personalisierung der SMC-B sektoral unterschiedlich ist (siehe [gemSpec_PKI#Anhang A]). Zum Auslesen der Zertifikate kann die Operation ReadCardCertificate gemäß [gemSpec_Kon#4.1.9.5.2] verwendet werden. Die Telematik-ID ist in allen Zertifikaten in der Admissionstruktur als "registrationNumber" im ASN.1-Format gespeichert.
3.12.4 Signieren von Dokumenten
Ob eine Signatur und welche Art der Signatur (QES oder nonQES) erforderlich ist, wird durch den Anwendungsfall für das jeweilige Dokumentenformat festgelegt und außerhalb dieser Spezifikation veröffentlicht.
Im Folgenden wird das Vorgehen für den Fall, dass ein Medizinisches Informationsobjekt signiert wird, beschrieben.
Im Primärsystem liegt ein strukturiertes Dokumentenformat der ePA als FHIR-XML-Darstellung oder FHIR-JSON-Darstellung vor. Im Sinne der Signaturerstellung wird dies als Data to be Signed (DTBS) bezeichnet.
Vor dem Einstellen des Dokuments wird dieses elektronisch signiert (QES oder nonQES). Das Primärsystem nutzt dafür die Schnittstelle des Konnektors und dieser den HBA für QES bzw. SM-B für nonQES des einstellenden LE.
Bei der Signaturerstellung ist folgender Ablauf im Primärsystem erforderlich:
- Das Primärsystem stellt fachliche DTBS zusammen.
- Das Primärsystem serialisiert die Daten zu einer Data to be Signed Representation (DTBSR).
- Das Primärsystem übermittelt DTBSR an den Konnektor zur Signaturerstellung (Aufruf der Operation SignDocument gemäß [gemILF_PS]).
- Der Konnektor erzeugt eine CADES Enveloping Signatur.
- Das signierte Objekt enthält sowohl die Signatur als auch die ursprünglichen DTBSR bitgenau und in einem binären ASN.1 Format (PKCS#7).
- Der Konnektor übermittelt das signierte Objekt an das Primärsystem.
- Das Primärsystem stellt über das Funktionsmerkmal "Dokumente einstellen" das signierte Objekt als DocumentEntry im ePA-Aktensystem im PKCS#7-Format ein.
A_19742 - strukturiertes Dokument - QES signieren
Falls eine QES-Signatur für ein strukturiertes Dokument gefordert wird, MUSS das PS vor dem Einstellen eines strukturierten Dokumentes in die Akte des Versicherten eine QES-Signatur als CADES Enveloping Signatur für das strukturierte Dokument durch Aufruf der Operation SignDocument erstellen. [<=]
A_19957 - strukturiertes Dokument - nonQES signieren
Falls eine nonQES-Signatur für ein strukturiertes Dokument gefordert wird, MUSS das PS vor dem Einstellen eines strukturierten Dokumentes in die Akte des Versicherten eine nonQES Signatur als CADES Enveloping Signatur für das strukturierte Dokument durch Aufruf der Operation SignDocument erstellen. [<=]
Bei der Signaturprüfung ist folgender Ablauf im Primärsystem erforderlich:
- Das Primärsystem lädt Dokument aus dem ePA-Aktensystem.
- Das Primärsystem erkennt, dass es sich dabei um ein medizinisches Objekt im Format im PKCS#7 handelt (DocumentEntry.mimetype = application/pkcs7-mime).
- Das Primärsystem übermittelt das signierte Objekt an den Konnektor zur Signaturprüfung (Aufruf der Operation VerifyDocument [gemILF_PS]).
- Der Konnektor prüft die Signatur.
- Der Konnektor übermittelt das Prüfergebnis an das Primärsystem.
- Bei erfolgreicher Signaturprüfung verarbeitet das Primärsystem die fachlichen Daten entsprechend dem formatCode weiter. Hierzu parst das Primärsystem die binäre ASN.1-Struktur der Daten im PKCS#7-Format und trennt die Fachdaten von den restlichen Daten ab.
A_19743 - strukturiertes Dokument - QES-Signatur prüfen
Falls eine QES-Signatur für ein strukturiertes Dokument gefordert wird MUSS das PS nach dem Laden eines strukturierten Dokumentes aus der Akte des Versicherten die QES des Dokumentes durch Aufruf der Operation VerifyDocument prüfen und das Prüfergebnis zur Anzeige bringen. [<=]
A_19958 - strukturiertes Dokument - nonQES Signatur prüfen
Falls eine nonQES-Signatur für ein strukturiertes Dokument gefordert wird, MUSS das PS nach dem Laden eines strukturierten Dokumentes aus der Akte des Versicherten die nonQES des Dokumentes durch Aufruf der Operation VerifyDocument prüfen und das Prüfergebnis zur Anzeige bringen. [<=]
4 Spezielle Nutzungsumgebungen
Nutzerumgebungen werden grundlegend durch [gemSpec_Aktensystem_ePAfuerAlle#A_19303-*] in ihren Zugriffsrechten auf Dokumente des Versicherten in der ePA für alle eingeschränkt.
4.1 Funktionsumfang Clientsystem des Kostenträgers
Der Kostenträger stellt für Versicherte Dokumente in ihr Aktenkonto. Das sind:
- Abrechnungsdaten,
- digitalisierte Papierdokumente von Versicherten ohne FdV,
- elektronische Arbeitsunfähigkeitsbescheinigungen.
Somit muss das Clientsystem des Kostenträgers das Einstellen von Dokumente des XDS Document Service umsetzen.
Des Weiteren übernimmt das Clientsystem des Kostenträgers Aufgaben im Rahmen eines betreiberübergreifenden Aktenumzugs. Damit unterscheidet sich der Funktionsumfang des Clientsystems des Kostenträgers wesentlich vom Funktionsumfang des Primärsystems einer Leistungserbringerinstitution. Der Kostenträger wird dabei durch die SMC-B des Kostenträgers repräsentiert. Der Kostenträger ist grundsätzlich befugt, schreibend auf die Akten der Versicherten zuzugreifen, das individuelle Befugen durch Lesen der Versichertenkarte entfällt. Ein lesender Zugriff ist nicht möglich.
Im Folgenden wird der spezifische Funktionsumfang beschrieben und die Anforderungen genannt, die sich nur auf das Primärsystem des Kostenträgers beziehen.
4.1.1 Einstellen von Daten durch Kostenträger
A_19394-03 - Kennzeichnung eines Dokumentes als Kostenträgerinformation
Das Clientsystem des Kostenträgers MUSS zur Kennzeichnung der Dokumente, die für die ePA des Versicherten eingestellt werden, die in Tab_ILF_ePA_KTR_Metadatenkennzeichnungen für den Dokumententyp aufgeführten Metadaten für DocumentEntry setzen.
Tabelle 17: Tab_ILF_ePA_KTR_Metadatenkennzeichnungen
Dokumententyp | Metadaten |
---|---|
Dokumente der bei den Krankenkassen gespeicherten Daten über die in Anspruch genommenen Leistungen der Versicherten | healthcareFacilityTypeCode=VER und typeCode=ABRE |
Elektronische Arbeitsunfähigkeitsbescheinigungen | gemäß Implementationguide eAU [gemSpec_IG_ePA] |
Eingescannte Dokumente | classCode=DOK |