Elektronische Gesundheitskarte und Telematikinfrastruktur
Implementierungsleitfaden Primärsysteme -
Elektronische Patientenakte (ePA) ePA für alle
Version |
|
Revision |
|
Stand |
|
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 |
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
gematik |
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
|
|
|
|
gematik |
||||
|
|
|
|
|
||||
|
|
|
|
|
||||
Inhaltsverzeichnis
DokumentinformationenDokumentinformationen
InhaltsverzeichnisInhaltsverzeichnis
2.1 Relevante IntegrationsprofileAkteure und Rollen
3 SystemkontextÜbergreifende Festlegungen
3.2 NachbarsystemeLokalisierung der Service-Endpunkte der ePA
4 Übergreifende Festlegungen3.3 Lokalisierung der Akte eines Versicherten
4.1 Webservice-Kommunikation3.4 User Session und Login in ein Aktenkonto
4.2 Dienstverzeichnisdienst3.4.1 VAU
4.3 Ereignisdienst/Systeminformationsdienst3.4.2 Nutzerauthentifizierung per IDP-Dienst mittels OIDC-Flow
4.4 Zugriffssteuerung3.4.2.1 Übergreifende Festlegungen zur Nutzung des IDP-Dienstes
4.4.1 Aufrufkontext3.4.3 Logout
4.4.1.1 Aufrufkontext in großen Institutionen3.4.4 Aktenkontokennung
4.4.2 RecordIdentifier3.4.5 Zertifikate
4.4.3 Status Aktenzugriff3.5 SOAP
5 Funktionsmerkmale3.6 REST
5.1 ePA-Administration3.7 Mandantenverwaltung
5.1.1 Aktenanbieter ermitteln3.8 Funktionsmerkmale
5.1.1.1 Schnittstelle3.9 Erstellen einer Befugnis
5.1.1.2 Umsetzung3.9.1 Umsetzung
5.1.1.3 Nutzung3.9.2 Nutzung
5.1.2 Aktenkonto aktivieren3.10 Versorgungsspezifische Services
5.1.2.1 Schnittstelle3.10.1 Widersprüche zu Versorgungsprozessen abrufen
5.1.2.2 Umsetzung3.10.2 Medikationsprozess
5.1.2.3 Nutzung3.11 Dokumentenmanagement
5.1.3 Ad-hoc-Berechtigung erteilen3.11.1 Dokumente einstellen [ITI-41]
5.1.3.1 Schnittstelle3.11.1.1 Umsetzung
5.1.3.2 Umsetzung3.11.1.2 Nutzung
5.1.3.3 Nutzung3.11.2 Dokumente suchen [ITI-18]
5.1.3.4 Nutzung durch einen Vertreter3.11.2.1 Umsetzung
5.1.4 Sämtliche Berechtigungen der LEI ermitteln3.11.2.2 Nutzung
5.1.4.1 Schnittstelle3.11.3 Dokumente laden [ITI-43]
5.1.4.2 Umsetzung3.11.3.1 Umsetzung
5.1.4.3 Nutzung3.11.3.2 Nutzung
5.1.4.4 Nutzung in größeren Institutionen3.11.4 Dokumente löschen [ITI-62]
5.1.5 Einzelne Berechtigungen der LEI ermitteln3.11.4.1 Umsetzung
5.1.5.1 Schnittstelle3.11.4.2 Nutzung
5.1.5.2 Umsetzung3.11.5 Aktualisieren von Metadaten [ITI-92]
5.1.5.3 Nutzung3.11.5.1 Umsetzung
5.2 Dokumentenmanagement3.11.5.2 Nutzung
5.2.1 Dokumente einstellen3.11.6 Artefakte
5.2.1.1 Schnittstelle3.11.6.1 Namensräume
5.2.1.2 Umsetzung3.11.6.2 WSDLs und Schemata
5.2.1.3 Nutzung3.11.7 Testunterstützung
5.2.2 Dokumente suchen3.12 Informationsmodell
5.2.2.1 Schnittstelle3.12.1 Metadaten
5.2.2.2 Umsetzung3.12.2 Strukturierte Dokumente
5.2.2.3 Nutzung3.12.2.1 Medizinische Informationsobjekte
5.2.3 Dokumente laden3.12.2.2 NFD, DPE und eMP
5.2.3.1 Schnittstelle3.12.2.3 Elektronischer Arztbrief im DischargeLetterContainer-Format
5.2.3.2 Umsetzung3.12.3 Selbstauskunft
5.2.3.3 Nutzung3.12.4 Signieren von Dokumenten
5.2.4 Dokumente löschen4 Spezielle Nutzungsumgebungen
5.2.4.1 Schnittstelle4.1 Funktionsumfang Clientsystem des Kostenträgers
5.2.4.2 Umsetzung4.1.1 Einstellen von Daten durch Kostenträger
5.2.4.3 Nutzung4.1.2 Ablauf eines betreiberübergreifenden Aktenumzugs (informativ)
5.2.5 Artefakte4.1.3 Erstellung des Exportpakets auf Seiten des alten Kostenträgers
5.2.5.1 Namensräume4.1.4 Einspielen des Exportpakets auf Seiten des neuen Kostenträgers
5.2.5.2 WSDLs und Schemata4.1.5 Verhalten bei Scheitern des Imports
5.2.6 Testunterstützung4.2 Funktionsumfang Clientsystem der Ombudsstelle
5.3 Protokolle und Benachrichtigungen4.2.1 Spezifische LEI für die Nutzung eines Aktenkontos sperren
5.3.1 Benachrichtigungen erhalten4.2.2 Widersprüche zum Medikationsprozess einstellen oder widerrufen
5.3.1.1 Info-Quelle ePA-Administration4.2.3 Protokolldaten dem Versicherten zur Verfügung stellen
5.3.1.2 Info-Quelle Berechtigungs-Abfrage4.3 Funktionsumfang Clientsystem DiGA
5.3.1.3 Info-Quelle Dokumentensuche4.3.1 Einstellen von DiGA-Daten
5.3.1.4 Info-Quelle Systeminformationsdienst5 Ergänzende Funktionalitäten
5.3.1.5 Info-Quelle Fehlermeldung5.1 Betriebs- und Performancedaten
5.3.1.6 Umsetzung5.2 Übertragungsprotokolle speichern
5.3.1.7 Nutzung5.3 Empfehlung zur Archivierung
5.3.2 Übertragungsprotokolle speichern6 Best practice UX Primärsysteme
5.4 Status- und Fehlermeldungen6.1 Allgemeine Hinweise
5.4.1 Statusinformationen6.1.1 ePA im Dokumentenmanagementkontext immer ansteuerbar
5.4.2 Fehlerbehandlung6.1.2 Ladevorgänge im Hintergrund
5.4.2.1 TelematikError6.1.3 Pflichtdokumente und optionale Dokumente
5.4.2.2 IHE-Error6.2 Konfigurationsmöglichkeiten des Systems
5.4.3 Handlungsempfehlungen in Fehlerfällen6.2.1 Hochladen in die ePA als Default beim Archivieren für bestimmte Dokumententypen
5.4.4 Übersicht möglicher Fehlermeldungen6.2.2 Hochladen in die ePA als Default für ausgewählte Dokumententypen in der Benutzung von KIM
5.4.4.1 Fehlermeldungen aus dem Fachmodul ePA6.2.3 Hochladen in die ePA als Default nach dem Erstellen für bestimmte Dokumententypen
5.4.4.2 Fehlermeldungen aus dem Aktensystem ePA6.2.4 Default Vorbelegung beim Hochladen eines Dokuments
6 Informationsmodell6.3 Dokumentenverwaltung in der elektronischen Patientenakte
6.1 Metadaten6.3.1 ePA öffnen
6.2 Selbstauskunft6.3.2 Dokumente suchen, filtern und sortieren
6.3 Wertebereiche6.3.3 Dokument verwalten
6.4 Dokumentenformate der ePA6.3.4 Dokument hochladen aus Karteikarte
6.4.1 ContentProfile Notfalldatensatz und Datensatz Persönliche Erklärungen6.3.5 Dokument hochladen aus KIM-Workflow
6.4.2 ContentProfile elektronischer Medikationsplan6.4 Digital gestützter Medikationsprozess in der elektronischen Patientenakte
6.4.3 ContentProfile Arztbrief nach § 291f6.4.1 Medikationsliste öffnen
6.4.4 Daten digitaler Gesundheitsanwendungen6.4.2 Medikationsliste als Übersicht anzeigen
6.4.5 Strukturierte Dokumente6.4.3 Medikationslisteneintrag im Detail anzeigen
6.4.5.1 Signatur für strukturierte Dokumentenformate der ePA6.4.4 Medikationsliste herunterladen
7 Ergänzende Funktionalitäten6.5 Nachbereitung
7.1 Empfehlung zur Archivierung6.5.1 Benachrichtigung der Patient:in über Hochladen eines Dokuments
8 Anhang A – Verzeichnisse6.6 Fehlermanagement
8.1 Abkürzungen6.6.1 Verständliche Fehlermeldungen
8.2 Glossar7 Fehlerbehandlung
8.3 Abbildungsverzeichnis7.1 Fehlermeldungen der REST-Schnittstellen
8.4 Tabellenverzeichnis7.1.1 Fehlerbehandlung im XDS Document Service
8.5 Referenzierte Dokumente7.1.2 IHE-Error
8.5.1 Dokumente der gematik7.1.3 Fehlermeldungen aus dem XDS Document Service
8.5.2 Weitere Dokumente8 Anhang A – Verzeichnisse
9 Anhang A- Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets
1 Einordnung des Dokumentes
1.1 Zielsetzung
Die vorliegende Spezifikation definiert Anforderungen zu Erstellung, Test und Betrieb derjenigen Anteile eines PrimärsystemsPrimär- oder Clientsystems, die zur Nutzung der elektronischen PatientenakteePA 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 gegebenverwiesen.
1.2 Zielgruppe
Das Dokument ist maßgeblich für Hersteller von Primärsystemen, welche die Fachmodul-ePA-Schnittstelle des KonnektorsSchnittstellen 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 GegenstandsbereicheAnwendungen.
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. Dokumentenlandkarte, Produkttypsteckbrief 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_
DM_ePAAktensystem_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
Einem Leistungserbringer als Nutzer seines Primärsystems bietet ein ePA-fähiger Konnektor den Zugang zur elektronischen Patientenakte des gesetzlich Versicherten an. Leistungserbringer und Primärsystem greifen in der ConsumerZone der TI primär auf die lokalen bzw. dezentralen TI-Komponenten der LE-Institution zu. Zugriffe auf elektronische Patientenakten erfolgen ausschließlich gekapselt über den Konnektor.
Zu diesem Zweck nutzt das Primärsystem IHE-Schnittstellen, die das Fachmodul ePA des Konnektors bereitstellt. Eine Übersicht über die Fachanwendung ePA im Ganzen liefert [gemSysL_ePA]. Einen Überblick über die ePA-Profilierung des Frameworks von IHE (Integrating the Healthcare Enterprise) liefert [gemSpec_Dokumentenverwaltung]
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 der "Aktedem "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.
2.1 Relevante Integrationsprofile
Für das aktennutzende PS sind mehrere IHE-Integrationsprofile für das Primärsystem relevant:
Tabelle 1: Tab_ILF_ePA_IHE-TransaktionenProfile
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 Systemkontext 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 BerechtigungsvergabeBefugnisvergabe des Versicherten auszutauschen. Dieser Datenaustausch erfolgt in vielerlei Hinsicht gemäß Festlegungen von IHE.
Die technische Infrastruktur der ePA besteht beim Leistungserbringer vor allem aus dem Konnektor mit dem Fachmodul ePA, welches die Kommunikation mit dem ePA-Aktensystem ermöglicht. , 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], [gemILF_PS_NFDM] und [gemILF_PS_AMTS] beschrieben sind 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.
3.1 Akteure und Rollen2.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.
3.2 Nachbarsysteme
Leistungserbringer erhalten über ihr ePA-fähiges Primärsystem Zugriff auf die ePA des Versicherten ausschließlich über den Konnektor. Der Konnektor macht zusätzlich die zentralen und dezentralen Komponenten der TI für das PS zugänglich, für Details siehe die Übersicht in [gemKPT_Arch_TIP]. Weitere Nachbarsysteme oder an das PS angebundene Softwaremodule werden in diesem Dokument nicht betrachtet.
Das vorliegende Dokument bezieht sich mit den referenzierten Konnektorschnittstellen auf den Leistungsumfang der ePA-Komponenten, die in der dazugehörigen Dokumentenlandkarte aufgelistet sind. Die hier beschriebene Funktionalität wird als ePA Stufe 2 (und höher) beschrieben, um zu kennzeichnen, dass die vorliegenden Primärsystemschnittstellen der ePA einige nur beschränkt abwärtskompatible Änderungen zur ePA-Stufe 1 enthält. Das betrifft insbesondere die Erteilung von Berechtigungen. In ePA 1 erstellte Berechtigungen werden vom Aktensystem in Berechtigungen für ePA 2.x transformiert. ePA 2.x - Berechtigungen können jedoch nicht in ePA 1 - Berechtigungen zurück transformiert werden. Das Upgrade von ePA 1 auf ePA 2.x kann nicht rückgängig gemacht werden. In einer früheren Version des vorliegenden Dokumentes ist die Nutzung der ePA Stufe 1 beschrieben, zuletzt für das Release 3.1.3.
Das Upgrade des Primärsystems auf Stufe 2.x ist abhängig von der Verfügbarkeit des ePA 2.x - Konnektorfachmoduls im Konnektor des Leistungserbringers. Falls der PS-Hersteller die Verfügbarkeit des Konnektor PTV5 (mit der ePA 2 - Funktionalität) bei den Leistungserbringern nicht durchgängig sicher stellen kann, kann es für das Ausrollen des ePA 2 - Primärsystems erforderlich sein, die Schnittstellenversion des Konnektors über den Dienstverzeichnisdienst zu ermitteln und die Inbetriebnahme des ePA 2 - Upgrades vom Vorliegen der passenden Schnittstellenversion im Dienstverzeichnisdienst abhängig zu machen (PHRService V2.x und PHRServiceManagement V2.x sind erreichbar). Dieses Feature ("Dualmode" des Primärsystems) unterstützt die Migration von ePA 1 nach ePA 2.x und darf nicht dazu verwendet werden zwischen den Interfaces von ePA 1 und ePA 2.x beliebig zu wechseln. Dies würde dazu führen, dass bei manchen PS-Installation ePA 1 genutzt wird, bei anderen ePA 2.x, je nach Version des Konnektors in der konkreten LE-Institution. Dieser "Dualmode" erlaubt PS-Herstellern ein einheitliches Release-Management für unterschiedliche Praxiskonstellationen im Migrationszeitraum der ePA Stufe 1 auf die ePA Stufe 2.x.
4 Übergreifende FestlegungenAuch 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.
|
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 verarbeitet die primäre Behandlungsdokumentation der Versicherten. Die ePA ist ein potentiell lebenslanger Speicherort für eine sekundäre Behandlungsdokumentation der VersichertenMUSS 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).
Die Anbindung und Nutzung dezentraler TI-Komponenten, die in [gemILF_PS] beschrieben wird, ermöglicht unter anderem den Aufbau von Kartensitzungen, die an verschiedenen Stellen vorausgesetzt werden, insbesondere zur Nutzung der eGK des Versicherten.
Das Fachmodul ePA wird vom Konnektor ab Produkttyp Version 4 (PTV4) zur Verfügung gestellt.
Die Inbetriebnahme des Konnektors in die LE-Umgebung [gemILF_PS#4.1] und die Unterstützung des VSDM durch das PS für eine Gültigkeitsprüfung der eGK [gemILF_PS#4.3] MUSS erfolgt sein, um die ePA nutzen zu können.
Für die Anwendungsfälle der ePA MUSS eine SM-B in PS und Konnektor verwaltet werden und freigeschaltet sein [gemILF_PS#4.2.3]. Das PIN-Handling von eGK und SM-B wird in [gemILF_PS#4.1.5] beschrieben.
Das PS muss eine Arbeitsplatz-Konfiguration in der LE-Institution ermöglichen, in der Versicherte auf ein Kartenterminal zugreifen können, in dem sie ihre eGK freischalten können. Dazu gehört ein KT, dessen PIN-Pad dem Versicherten zur Eingabe seiner PIN.CH zugänglich ist. Die Konfiguration eines Arbeitsplatzes, an dem ein Kartenterminal für den Versicherten zur PIN-Eingabe zugänglich ist, insbesondere am Empfangstresen, wird in [gemILF_PS#9.1] beschrieben.
4.1 Webservice-Kommunikation
Die Webservice-Konnektorschnittstellen werden nachrichtenbasiert angesprochen über
• SOAP1.1 mit [BasicProfile1.2] für Webservices der Konnektor-Basisdienste und anderer Fachmodule und
SOAP1.2 mit [BasicProfile2.0] für Webservices des Fachmoduls ePAA_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 |
Ist die Zertifikatsprüfung nicht erfolgreich, ist der Verbindungsaufbau abzulehnen. [<=]
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 Aufruf- und Aktenkontextden Aktenkontext und die Telematik-ID zu erhalten (s. Kap. 4.4).
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_14511 - Leere oder fehlende SOAP-Header im Falle fehlender Parametern
Das PS KANN einen leeren SOAP-Header an den Konnektor senden oder eine Nachricht ohne SOAP-Header versenden, wenn keine SOAP-Header-Parameter 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. [<=]
43.2 Dienstverzeichnisdienst6 REST
A_15573 - Nutzung DVD zur Ermittlung der Webservice-Endpunkte der ePA am Konnektor
Das PS MUSS ausschließlich den Dienstverzeichnisdienst des Konnektors nutzen, um die Webservice-Endpunkte für die ePA-Dienste des Fachmoduls zu ermitteln. Die URL des Webservice-Endpunktes, die aus WSDL-Abfragen wie GET /ws/CertificateService?wsdl ermittelt werden kann, ist nicht zu verwenden. [<=]
Das PS soll auch mit Konnektoren kompatibel sein, die eine Produkttypversion kleiner als PTV4 nutzen. Der PS-Hersteller kann es erreichen, dass sein Primärsystem mit Konnektoren unterschiedlicher Produkttypversion zusammenarbeitet, um darauf vorbereitet zu sein, dass seine Kunden Konnektoren älterer Produkttypversionen (kleiner PTV4) nutzen, indem er die Versionsinformationen des Dienstverzeichnisdienstes beachtet:
• Der Dienstverzeichnisdienst stellt dem PS die Information zur Verfügung, ob der Konnektor ePA-Dienste anbietet. Wenn kein ePA-Webservice angeboten wird, SOLL das PS die ePA-Funktionsmerkmale an der Nutzeroberfläche nicht zur Verfügung stellen.
• Der Dienstverzeichnisdienst stellt ihm die Information, in welcher Version der Konnektor seine Webservices anbietet, als eine dreistellige Versionsnummer mit Hauptversionsnummer (1. Stelle), Nebenversionsnummer (2. Stelle) und einer Revisionsnummer (3. Stelle) zur Verfügung.
Es kann vorkommen, dass PS und Konnektor vom selben Webservice unterschiedliche Dienstversionsnummern unterstützen. Der Umgang mit Abweichungen zwischen produktiven PS und Konnektor in Bezug auf unterstützte Dienstversionen wird in [gemILF_PS#4.1.2] beschrieben.
4.3 Ereignisdienst/Systeminformationsdienst
Falls das PS den Eventservice des Konnektors abonniert, kann es Komfortfunktionen der Kartenverwaltung wie Benachrichtigungen über gesteckte und gezogene Karten und Informationen über den Betriebszustand des Konnektors nutzen.
A_15577 - Abonnierung von Ereignissen
Das PS SOLL Benachrichtigung über Konnektor-Ereignisse gemäß [gemILF_PS#4.1.4] Eventservice abonnieren, insbesondere FM_EPA/POLICY_LEI (Kap. 5.4.1) und FM_EPA/ ACTIVATE_ACCOUNT/START (Kap. 5.1.2). [<=]
4.4 Zugriffssteuerung
Der ePA-Client übergibt je nach Signatur der Operation eines ePA-Webservices Informationen über
• sich selbst (bzw. den Arbeitsplatz, von dem aus der Clientaufruf erfolgt) in den Context-Parametern (im SOAP-Header oder im SOAP-Request) sowie
• Identifikatoren zur Akte des Versicherten.
Viele Funktionsmerkmale erfordern die Kenntnis des Status der Zugriffsberechtigung auf die ePA eines Versicherten, um
• nicht auf unnötige Fehler zu laufen (insbesondere bei Operationen des Dokumentenmanagements) und
Aufrufe vollständig umsetzen zu können.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_14413 - Primärdokumentation als Voraussetzung der ePA als Sekundärdokumentation24401 - Mandantenweite Verwendung der korrekten SMC-B
Das PS MUSS für einen Versicherten Daten in seiner Primärdokumentation verwalten, falls er für ihn Funktionsmerkmale des ePA-Dokumentenmanagements zur Sekundärdokumentation nutzen will, und dort folgende Informationen hinterlegen können: RecordIdentifier inklusive Versicherten-ID (Die Versicherten-ID ist der 10-stellige unveränderliche Teil der 30-stelligen Krankenversicherungsnummer), Status Zugriffsberechtigungsicherstellen, 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. [<=]
4.4.1 Aufrufkontext
Das Bilden des Aufrufkontextes erfolgt wie schon im PTV1-Konnektor. Die nur für den HBA verwendete User-ID muss im Rahmen der ePA nicht gesetzt werden, da der Zugriff auf die ePA mittels HBA in den Stufen 1 und 1.1 nicht möglich ist. Die Verwendung der korrekten SMC-B wird über den Aufrufkontext gesteuert.
Abbildung 15: ILF_ePA_Element_Context
Der Konnektor ermittelt unter Verwendung von Konfigurationsdaten am Konnektor und der Context-Informationen die zur Laufzeit verfügbaren SM-Bs, die für den Aktenzugriff vom Konnektor herangezogen werden können. Voraussetzung für die Nutzung vieler Funktionsmerkmale ist daher das Vorliegen mindestens einer freigeschalteten SM-B.
Beispiel #: Bsp_ILF_ePA_Context
<m0:Context> |
A_22398 - ePA-Nutzung nur durch ePA-fähige Aufrufkontexte
Das PS SOLL sicherstellen, dass immer nur ePA-fähige Aufrufkontexte für die Anwendung ePA genutzt werden. ePA-fähig ist ein Aufrufkontext (Context) dann, wenn eine SMC-B verwendet wird, die für die Nutzung der ePA vorgesehen ist. [<=]
Die konsequente Nutzung der ePA-fähigen Aufrufkontexte kann auch konfigurativ in der konkreten LEI sichergestellt werden.
A_14442 - Freischaltung von SM-Bs garantieren
Das PS MUSS mindestens einmal täglich den Sicherheitszustand aller SM-Bs prüfen, die in der LE-Institution verfügbar sind. Im Falle nicht freigeschalteter SM-Bs MUSS das PS den Nutzer auffordern, die Freischaltung der SM-Bs durchzuführen. [<=]
Die Liste der gesteckten SM-Bs liefert der Systeminformationsdienst (siehe [gemILF_PS#4.1.4]). Der erhöhte Sicherheitszustand bzw. die Freischaltung einer SM-B ist mittels GetPinStatus am Rückgabewert verified erkennbar (siehe [gemILF_PS#4.1.5.4]).
4.4.1.1 Aufrufkontext in großen Institutionen
Die Nutzung ePA-fähiger Aufrufkontexte ist in kleineren Einrichtungen mit nur einer einzigen verwendeten SMC-B einfacher umzusetzen als in großen Einrichtungen, in denen es viele verwendete SMC-Bs zu konfigurieren gilt. Besonders sorgfältig sollte dabei das Verhältnis von MandantID und Telematik-ID beachtet werden, falls eine große Institution über mehrere SMC-Bs mit unterschiedlichen Telematik-IDs verfügt.
Der Aufrufkontext referenziert implizit (über die Konfiguration von SMC-B und MandantID) eine Telematik-ID. Die Telematik-ID, die implizit im Aufrufkontext der Berechtigungsvergabe verwendet wird, muss mit der Telematik-ID übereinstimmen, die implizit im Aufrufkontext der Berechtigungsvergabe verwendet wird. Andernfalls kann es unerwünschterweise passieren, dass der Zugriff auf die Dokumentenverwaltung scheitert, weil keine Zugriffsberechtigung vorliegt.
Mandantenverwaltung
Eine Voraussetzung für eine funktionierende ePA besteht darin, dass die Leistungserbringerinstitution so konfiguriert ist, dass die Beziehung zwischen MandantID und Telematik-ID eindeutig ist, d.h. jedem ePA-Mandanten muss immer genau eine Telematik-ID zugeordnet sein. Die Beziehung zwischen MandantID und Telematik-ID muss eine n:1 Beziehung sein. Andernfalls bestünde die Gefahr, dass genutzte Mandanten zufällig Telematik-IDs zugeordnet werden.
Das PS kann die n:1-Beziehung zwischen MandantID und Telematik-ID technisch verifizieren, indem es (Schritt 1) alle SMC-B-Cardhandles der für die ePA im Kontext verwendeten MandantID ermittelt, (Schritt 2) für jede dieser CardHandle per ReadCardCertificate aus der SMC-B das C.HCI.AUT-Zertifikat ausliest, die Telematik-ID extrahiert und (Schritt 3) eine Fehlermeldung anzeigt, falls die ermittelten Telematik-IDs pro MandantID nicht identisch sind.
Wenn es SMC-Bs mit mehr als einer Telematik-ID gibt, muss in der Konfiguration von Konnektor und Primärsystem die fachliche Bedeutung des Aufrufkontextes besondere Beachtung finden:
• Die MandantID der Berechtigungsvergabe muss immer auf dieselbe Telematik-ID in den SMC-Bs verweisen wie die MandantID (bzw. die ihr zugehörige Telematik-ID), die in der Dokumentenverwaltung z.B. beim Zugriff auf eine Akte verwendet wird.
• ClientsystemID und WorkplaceID können im Aufrufkontext des Zugriffs auf die Dokumentenverwaltung abweichen vom Aufrufkontext der Berechtigungsvergabe.
Lastprobleme vermeiden
Die Operationen getHomecommunityID, getAuthorizationList und getAuthorizationState liefern Informationen, die für alle Clientsysteme und Arbeitsplätze des gleichen Mandanten nutzbar sind. Gleichlautende Anfragen können somit überflüssige Last für beteiligte Komponenten verursachen.
Um diese unnötige Last zu minimieren, die in großen Institutionen für die ePA-Aktensysteme entstehen könnte, soll in großen Institutionen beachtet werden:
1. Arbeitsplätze mit unterschiedlichen WorkplaceIDs sollen nicht separat voneinander jeweils getHomecommunityID, getAuthorizationList und getAuthorizationState aufrufen. Vielmehr sollen diese Aufrufe in den für sie vorgesehenen Zeiträumen einmalig für den Mandanten erfolgen, der über den Aufrufkontext referenziert wird.
2. Von einander getrennte Clientsysteme in einer Leistungserbringerumgebung (z.B. die Clients eines Krankenhauslabors und einer Krankenhausapotheke) dürfen nur dann separat voneinander getHomecommunityID, getAuthorizationList und getAuthorizationState aufrufen oder Ad-hoc-Berechtigungen erstellen, wenn sie nicht auf die Berechtigungsinformationen zugreifen können, die in anderen Clientsystemen gegebenenfalls bereits vorliegen.
Weitere Hinweise zur Nutzung der ePA in Krankenhäusern finden sich auf dem Fachportal der gematik unter
1. TI-FAQ für Krankenhäuser und
2. Anschluss von Krankenhäusern an die TI - Eine Übersicht über die Te-lematikinfrastruktur im stationären Sektor
4.4.2 RecordIdentifier
Für die ePA eines Versicherten werden identifizierende Merkmale in unterschiedlicher Form verwendet:
Tabelle 2: Tab_ILF_ePA_Identifier_für_Versicherte_und_Akten
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An den Konnektor-Schnittstellen werden jeweils entweder der RecordIdentifier oder seine Bestandteile verwendet.
Abbildung 2: Abb_ILF_ePA_RecordIdentifier
A_15640 - Transformationen InsurantId und patientId
Das PS MUSS in der Lage sein, aus der Versicherten-ID gemäß [gemSpec_DM_ePA#2.1.4.5] eine InsurantId und eine patientId zu erzeugen, sowie die inhaltsgleichen InsurantId und patientId wechselseitig ineinander zu transformieren. [<=]
4.4.3 Status Aktenzugriff
Die LEI wird vom Primärsystem darin unterstützt, die Metadaten für die Aktenzugriffe mit möglichst wenig Pflegeaufwand zu befüllen, und zwar insbesondere durch die
• Persistierung von Statusinformationen der Zugriffsberechtigung einer LEI auf Akten;
• Verwendung von Default-Einstellungen
• Selbstauskunftsangaben und reduzierte Wertebereichsvorschlagslisten aus [gemSpec_DM_ePA] gemäß Kap. 6.2
Der lokal hinterlegbare Status des Aktenzugriffs umfasst für einzelne Versicherte in Tab_ILF_ePA_Zugriffsberechtigungsstatus pro RecordIdentifier aufgeführte Informationen. Kap. 5.4.1 (Benachrichtigungen verwalten) beschreibt, wie sich diese Informationen akkumulieren und aktualisieren lassen.
Tabelle 3: Tab_ILF_ePA_Zugriffsberechtigungsstatus pro RecordIdentifier
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die LEI erhält Zugriff auf ePA-Dokumente je nach erteilter Kombination von Zugriffsberechtigungen. Folgende einander ergänzende Zugriffsberechtigungen sind in der ePA möglich:
Tabelle 4: Tab_ILF_ePA_Zugriffsberechtigungen
|
|
|
|
|
|
|
|
5 Funktionsmerkmale
Das Aktenkonto eines Versicherten kann sowohl beim LE, als auch am ePA-Frontend des Versicherten aktiviert werden (Kap. 5.2.1).
Das PS nutzt die Berechtigungsverwaltung des ePA-Aktensystems über seine Schnittstellen zum Fachmodul ePA.
Leistungserbringerinstitutionen haben zwei Möglichkeiten, vom Versicherten eine Berechtigung zum Aktenzugriff zu erhalten:
• Der Versicherte erteilt eine Berechtigung für die LE-Institution am ePA-Frontend des Versicherten
In der LE-Institution erteilt der Versicherte eine Ad-hoc-Berechtigung (Kap. 5.1.4)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 BerechtigungBefugnis kann sowohl vom Versicherten selbst stammen, als auch vom Vertreter des Versicherten. Sie ist auf LeistungserbringerLeistungserbringerinstitutionen (inkl. deren berufsmäßigen Gehilfen oder zur Vorbereitung auf den Beruf Tätige, jedoch nicht die Gehilfen der nichtärztlichen Psychotherapeuten) eingeschränkt, s. [gemSpec_PKI#Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung] und [gemKPT_Arch_TIP#Tabelle Zugriffsberechtigter Personenkreis (PK) nach §291a SGB V].
Die Laufzeit von ZugriffsberechtigungenBefugnissen ist begrenzt. Falls eine ZugriffsberechtigungBefugnis aufgrund in der Vergangenheit liegendem expirationDate oder BerechtigungsentzugvalidTO oder Befugnisentzug am ePA-Frontend des Versicherten nicht mehr existiert, ist eine erneute BerechtigungsvergabeBerfugnisvergabe erforderlich, s. [gemSysL_ePA#2.5.2]. .
Im Falle vorliegender Berechtigung kann das PS den RecordIdentifier des Versicherten ermitteln (Kap. 5.1.5).
Für ein bereits aktiviertes Aktenkonto kann sich eine Kombination der Anwendungsfälle bis hin zu einem lesenden Aktenzugriff beispielhaft folgendermaßen darstellen:
Abbildung 3: Abb_ILF_ePA_Kombinierte_Anwendungsfälle_für_bereits_aktiviertes_Aktenkonto
In technische Abläufe wird der Versicherte oder sein Vertreter über die PIN-Eingabe integriert.
Tabelle 5: Tab_ILF_ePA_Funktionsmerkmale_Beteiligung_Versicherter
|
|
|
|
|
|
|
|
Der Vertreter hat seine Vertretungsberechtigung am ePA-Frontend des Versicherten erhalten, wo auch die eGK des Vertreters der ePA des Vertretenen bekannt gemacht wurde. Im Gegensatz dazu benutzt der gesetzlich bevollmächtigte Vertreter die eGK desjenigen, den er vertritt.
Falls ein Vertreter das Aktenkonto aktivieren möchte, kann er dies nur dann tun, falls er ein gesetzlich bevollmächtigter Vertreter ist, der über eGK und PIN des Versicherten verfügt, den er vertritt. Für das Aktivieren des Aktenkontos kann der Vertreter seine eigene eGK nicht verwenden, anders als beim Erteilen der Ad-hoc-Berechtigung.
Für die Durchführung der Aktenkonto-Aktivierung oder der Erteilung der Ad-hoc-Berechtigung durch einen gesetzlich bevollmächtigten Vertreter ist keine darüber hinaus gehende zusätzliche Implementierung am PS erforderlich.
Das komplette Berechtigungskonzept inklusive der Berechtigungsverwaltung am ePA-Frontend des Versicherten liefert [gemSysL_ePA#3.6].
A_15090 - Protokollierung Dokumententransfer im Übertragungsprotokoll
Jeder Dokumententransfer (Dokumente einstellen, laden, löschen) MUSS im Übertragungsprotokoll vermerkt werden. [<=]
53.1 ePA-Administration
Das Aktenmanagement der Leistungserbringer (PHRManagementService) erfolgt weitgehend über das Fachmodul ePA und dort gekapselte Funktionalitäten.
In ActivateAccount und RequestFacilityAuthorization werden eGK und SM-B im freigeschaltetem Zustand verwendet, in GetHomeCommunityID nur die SM-B.
5.1.1 Aktenanbieter ermitteln
Frau Gundlach ist Patientin bei Herrn Dr. Weber und teilt ihm bei einem vergangenen Arzttermin mit, dass sie seit kurzem ein Aktenkonto bei einem ePA-Provider eingerichtet hat. Dr. Weber ermittelt daraufhin dessen Identifier über eine Funktion seines Primärsystems, und speichert den Identifier des Aktenanbieters von Frau Gundlach daraufhin persistent in der Primärdokumentation des Primärsystems ab.
Für die Nutzung der ePA durch das Primärsystem ist das Vorliegen eines Identifikators für das Aktenkonto des Versicherten (RecordIdentifier) erforderlich, der neben der KVNR auch dessen HomeCommunityID umfasst.
Zur Ermittlung der HomeCommunityID für ein nutzbares Aktenkonto des Versicherten wird die Operation GetHomeCommunityID des PHRManagementService genutzt. Falls eine Akte sich in keinem nutzbaren Zustand befindet, enthält die GetHomeCommunityIDResponse keine HomeCommunityID.
Fachliche Grundlage der Aktenzuordnung ist die Versicherten-ID (KVNR) des Versicherten. Jeder Versicherte hat zur selben Zeit nur ein einzelnes Aktenkonto, falls er über ein Aktenkonto verfügt. Unterschiedliche Versicherte können bei jeweils unterschiedlichen Aktenanbietern ihre Patientenakte hosten lassen. Die Abfrage der verschiedenen möglichen Aktenanbieter übernimmt das Fachmodul für das PS. Jeder Versicherte verfügt über genau eine aktive Akte, auch während er ggf. den Aktenanbieter wechselt.
A_15581 - Anwendungsfall Aktenanbieter ermitteln
Das PS MUSS es dem Leistungserbringer ermöglichen, für einen Versicherten, über dessen Versicherten-ID er in der Primärdokumentation seines PS verfügt, mittels GetHomeCommunityID die HomeCommunityId des Aktenanbieters zu ermitteln. [<=]
Das Resultat von Aktenanbieter ermitteln, die HomeCommunityId, wird als Teil des RecordIdentifiers verwendet, sowie separat als Wert bestimmter Metadatenfelder.
A_14660-01 - Persistente Speicherung der HomeCommunityId
Das PS MUSS eine über GetHomeCommunityID ermittelte HomeCommunityID in der Primärdokumentation des Versicherten speichern. [<=]
Eine persistente Speicherung der HomeCommunityId (kurz: HCID) beim Datensatz des Versicherten macht eine wiederholte zeitaufwändige Ermittlung der HCID überflüssig. Der einmal ermittelte Status der Akte als aktiviert bei einem bestimmten Aktenanbieter ändert sich höchst selten.
In der Response von GetAuthorizationList() sind HomeCommunityIds enthalten, die versichertenbezogen persistiert werden können, falls noch nicht geschehen.
A_22395 - Erneutes GetHomeCommunityID ausschließlich in Fehlerszenarien
Das PS DARF die HomeCommunityID eines Versicherten nicht erneut abfragen, falls sie bereits in seinen Patientendaten vorliegt. Ausnahme: Ein Fehlerszenario, das darauf hinweist, dass ein Aktenanbieterwechsel erfolgte (nicht Fehler 7290) und somit die Nutzung der ePA mit der alten HomeCommunityID nicht mehr möglich ist. [<=]
Der Tabelle Tab_ILF_ePA_Handlungsanweisung_im_Fehlerfall ist zu entnehmen, in welchen Fehlerszenarien es sinnvoll ist, getHomeCommunityID aufzurufen (siehe 7404, wobei auch die Hinweise 7401, 7403, 4705, 4706 zu beachten sind).
A_22394 - Verwendung der persistent gespeicherten HomeCommunityId
Die Verwendung der HomeCommunityId zur Befüllung des RecordIdentifiers oder im Rahmen der Dokumentenverwaltung MUSS mittels der persistent gespeicherten HomeCommunityId erfolgen. [<=]
Solange die ePA-Nutzung gering ist, werden viele GetHomeCommunityID-Anfragen negativ beantwortet werden. Da sich der Aktenstatus höchst selten ändert, ist es jedoch nicht sinnvoll, die Anfragen oft zu wiederholen.
A_22397 - Erneutes GetHomeCommunityID erst am Folgetag
Falls GetHomeCommunityID keine nutzbare Akte finden konnte (Fehlercode 7290), SOLL die nächste Anfrage erst am nächsten Tag erfolgen. [<=]
5.1.1.1 Schnittstelle
A_15582 - Identifikation des Versicherten mittels Versicherten-ID
Das PS MUSS die Versicherten-ID benutzen, um den Versicherten in seiner Primärdokumentation seiner ePA durch Bildung eines RecordIdentifiers zuzuordnen. [<=]
Tabelle 6: Tab_ILF_ePA_Operation_getHomeCommunityID
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9 Erstellen einer Befugnis
Die Leistungserbringerorganisation benötigt eine Befugnis (Entitlement), um auf die ePA eines Versicherten zugreifen zu können.
Abbildung 4: Abb_ILF_ePA_getHomeCommunityRequest
Abbildung 5: Abb_ILF_PS_ePA_getHomeCommunityIDResponse
5.1.1.2 Umsetzung
Die Aktivitäten des Anwendungsfalles Aktenanbieter ermitteln sind:
Vorbedingung:
• Dem Versicherten ist aktuell nach Auslesen der eGK oder bei einem vorangegangenen Arztbesuch eine Versicherten-ID im Primärsystem zugeordnet worden.
• Der Aufruf erfolgt aus der Primärdokumentation des Versicherten heraus
Auslöser:
• Die für einen Zugriff auf die Akte des Versicherten oder Verwaltung der Zugriffsberechtigung erforderliche HomeCommunityId liegt nicht vor.
• Bisher im PS bekannte HomeCommunityId hat sich als falsch herausgestellt, insbesondere aufgrund eines Anbieterwechsels des Versicherten.
Aktivitäten:
• Ermitteln der Versicherten-ID aus der Primärdokumentation des Versicherten
Resultat:
• Im Erfolgsfalle der Operation erhält der Nutzer eine HomeCommunityId, als Voraussetzung der Nutzung der ePA eines Versicherten.
• Die HomeCommunityId wird in der Primärdokumentation des Versicherten abgespeichert gemäß
A_14660
.
5.1.1.3 Nutzung
Das erfolgreiche Ermitteln einer HomeCommunityId ist kein Beleg für das Vorliegen einer Zugriffsberechtigung auf die Akte des Versicherten. Daher ist die Nutzung der Operation GetHomeCommunityID vor allem im Kontext der Ad-hoc-Berechtigung sinnvoll, oder nach einer Kenntnisnahme davon, dass Leistungserbringer eine Berechtigung über das ePA-Frontend des Versicherten erhalten haben.
Beispiel #: Bsp_ILF_ePA_Request_gethomecommunityid.xml
Wenn das Primärsystem durch eine VSDM-Prüfung von einem Wechsel der Haupt-IK-Nummer an den Daten des Versicherten informiert wird, soll im Falle einer bestehenden Zugriffsberechtigung auf eine Akte der Operation GetHomeCommunityID aufgerufen werden, da ein Wechsel des Aktenanbieters nicht unwahrscheinlich ist.
5.1.2 Aktenkonto aktivieren
Frau Gundlach hat bei einem Aktenanbieter einen Vertrag über die Nutzung einer elektronischen Patientenakte abgeschlossen. Sie bittet Dr. Weber darum, für sie das Aktenkonto zu aktivieren. Dr. Weber ermittelt den Aktenanbieter von Frau Gundlach durch Aufruf einer entsprechenden Funktion im PVS und aktiviert dort für Sie ihre Akte. Dabei gibt Frau Weber die PIN ihrer eGK ein.
Zur Umsetzung des "Schritt 2 - Aktivierung in der Umgebung des Leistungserbringers" im Anwendungsfall Aktenkonto einrichten aus [gemSysL_ePA#3.5.1, UC 2.1 - Aktenkonto einrichten, Schritt 2 - Aktivierung in der Umgebung des Leistungserbringers] wird die Operation ActivateAccount des PHRManagementService genutzt.
A_14191 - Anwendungsfall Aktivierung Aktenkonto des Versicherten
Das PS MUSS es dem Leistungserbringer ermöglichen, mittels ActivateAccount das Aktenkonto des Versicherten zu aktivieren. [<=]
Das Aktivieren des Aktenkontos wird entweder vom PS-Nutzer über das Userinterface aktiv gestartet oder es wird implizit aus anderen Anwendungsfällen heraus gestartet, in denen das Fachmodul am Status der Akte erkennt, dass die Akte eines Versicherten noch zu aktivieren ist. Das implizite Starten des Anwendungsfalles führt ebenso wie das vom PS angestoßene Starten des Aktenkonto-Aktivierens zu einer Interaktion des Versicherten mit dem Kartenterminal, worüber das PS durch das Event FM_EPA/ ACTIVATE_ACCOUNT/START informiert wird.
5.1.2.1 Schnittstelle
Durch seine PIN bestätigt der Versicherte seine Einwilligung dazu, das Aktenkonto in der in den Vertragsunterlagen ausgewählten Konfiguration zu aktivieren.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: Tab_ILF_ePA_Operation_ActivateAccountI_Entitlement_Management::setEntitlementPs
|
|
|||||||
|
|
|||||||
setEntitlementPs |
|
|
||||||
|
|
|
||||||
|
|
|||||||
|
|
|
||||||
|
|
|||||||
Abbildung 6: Abb_ILF_ePA_Eingabeparameter_ActivateAccount
5.1.2.2A_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 Aktenkonto aktivierenErstellen einer Befugnis sind:
Vorbedingung:
• Der Versicherte hat in einem ersten vorgelagerten Initialisierungsschritt ein Aktenkonto bei einem Aktenanbieter eingerichtet.
Durch ein vorgelagertesGetHomeCommunityIDwurde dieHomeCommunityIdermittelt.Ermittelter Service-Endpunkt zum Aktenkonto
- erfolgreiches ReadVSD mit Online-Prüfung
Auslöser:
• Der Versicherte informiert den LE über eine noch zu aktivierende Akte oder, alternativ, wird der Anwendungsfall durch das Event FM_EPA/ ACTIVATE_ACCOUNT/START gestartet.
In einem der Anwendungsfälle des PHRService ist der Fehler 7403 ist aufgetreten, der auf ein nicht aktiviertes Aktenkonto hinweistErhalt 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:
• Ermitteln des CardHandles zur eGK des Versicherten
• Abfrage getPinStatus, ob PIN.CH gesperrt ist
• Aufruf der Konnektorschnittstelle activateAccount
• Der Versicherte soll darüber informiert werden, dass er am Kartenterminal seine PIN eingeben muss;
Der Versicherte autorisiert den LE zur Aktivierung der Akte mit seiner PIN-EingabeAuswahl 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:
• Das Aktenkonto des Versicherten ist aktiviert
5.1.2.3 Nutzung
A_17204 - Informieren aufgrund Event FM_EPA/ ACTIVATE_ACCOUNT/START
Das PS MUSS bei Erhalt der Events FM_EPA/ ACTIVATE_ACCOUNT/START eine Information an den Nutzer des PS weiterleiten, dass der Versicherte aktuell mit dem Anwendungsfall beschäftigt ist, das Aktenkonto zu aktivieren. [<=]
Der Versicherte kann so vom Nutzer des PS darauf aufmerksam gemacht werden, dass der Versicherte am Kartenterminal dazu aufgefordert wird, seine PIN einzugeben.
Der Anwendungsfall startet mit der Information des Versicherten, die Aktenaktivierung bereits vorbereitet zu haben, mit einem expliziten Auslösen über das Userinterface des Primärsystems.
Das implizite Aktivieren startet die Aktenkontoaktivierung beispielsweise beim Erteilen einer Ad-hoc-Berechtigung, sofern das Aktenkonto sich in dem Zustand befindet, die ausstehende Aktivierung durchführen zu können. Dabei wird das Event FM_EPA/ ACTIVATE_ACCOUNT/START ausgelöst.
Wenn die Aktivierung des Aktenkontos erfolgreich beendet wurde und sich das Aktenkonto des Versicherten im aktivierten Zustand befindet, löst das ePA-Fachmodul das Event FM_EPA/ ACTIVATE_ACCOUNT/FINISHED aus, das für eine Erfolgsmeldung am Primärsystem genutzt werden kann, um den Versicherten über den Erfolg des Anwendungsfalles zu unterrichten.
5.1.3 Ad-hoc-Berechtigung erteilen
Frau Gundlach möchte Herrn Dr. Weber und seiner Hausarztpraxis Zugriff auf ihre ePA erteilen. Im Gespräch mit der Medizinischen Fachangestellte (MFA) von Dr. Weber am Empfangstresen, Frau Kunze, wird besprochen, dass der Zugriff auf alle normalen von Leistungserbringern eingestellte Dokumente erfolgen soll, nicht aber auf die vertraulichen Dokumente von Frau Gundlach. Sie überreicht ihre eGK Frau Kunze. Frau Kunze wählt die besprochene Option am PS. Frau Kunze fordert die Ad-hoc-Berechtigung am PS an und dreht das Kartenterminal mit dem Eingabefeld für die PIN-Eingabe zu Frau Weber. Auf dem Display des Kartenterminals sieht Frau Weber die Aufforderung zur PIN-Eingabe für die Ad-hoc-Berechtigung mit den abgesprochenen Optionen, sowie Dauer der Gültigkeit der Zugriffsberechtigung für die Arztpraxis Dr. Weber. Das PS am Empfangstresen fügt der lokalen Primärdokumentation von Frau Gundlach ein ePA-Kennzeichen als Markierung einer bestehenden Zugriffsberechtigung hinzu.
Zur Umsetzung des Anwendungsfalles Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern aus [gemSysL_ePA#3.6.7, UC 3.7 - Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern] wird die Operation RequestFacilityAuthorization des PHRManagementService verwendet.
A_14200-06 - Anwendungsfall Ad-hoc-Berechtigung erteilen
Das PS MUSS es Leistungserbringern ermöglichen, mittels RequestFacilityAuthorization vom Versicherten oder seinem Vertreter eine Ad-hoc-Zugriffsberechtigung auf seine Akte erteilen zu lassen. Dabei wird die Art des gewährten Zugriffs in der AuthorizationConfiguration angegeben, sowie die Dauer der Zugriffsberechtigung im ExpirationDate (heute+6 Tage als Defaultwert). Die AuthorizationConfiguration enthält die vom Versicherten getroffene Festlegung zu folgenden Auswahlmöglichkeiten:
• Vertraulichkeitsstufe (AuthorizationConfidentiality)
o einfacher Zugriff: Zugriff auf Dokumente, die mit der Vertraulichkeitsstufe normal gekennzeichnet sind; AuthorizationConfidentiality=normal
o erweiterter Zugriff: Zugriff auf Dokumente, die mit der Vertraulichkeitsstufe normal oder vertraulich gekennzeichnet sind; AuthorizationConfidentiality=extended
• die Auflistung der Dokumentenkategorien DocumentCategory gemäß [gemSpec_DM#Tab_DM_Dokumentenkategorien], auf die eine Berechtigung erteilt wird.
[<=]
Die Vertraulichkeitsstufe vertraulich (restricted) betrifft Dokumente, die der Versicherte an seinem FdV als vertraulich gekennzeichnet hat, sowie Dokumente, die von Leistungserbringern auf Wunsch des Versicherten als vertraulich eingestellt wurden. Falls eine Freigabe auf Dokumente der Vertraulichkeitsstufe restricted erfolgt, ist damit eine Freigabe auf Dokumente der Vertraulichkeitsstufe normal verbunden.
Es ist nicht möglich, in der Leistungserbringer-Umgebung eine Freigabe auf Dokumente der Vertraulichkeitsstufevery restrictedzu erteilen. Auch in anderen Aspekten verfügt die Berechtigungsvergabe am FdV über mehr Optionen als die Berechtigungsvergabe am PS, insbesondere was das Setzen von Dokumenten auf eine Deny- oder Permit-List betrifft. Versicherte, die solche Optionen wählen wollen, verwenden dazu ausschließlich ihr FdV.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_19408 - Auswahlmöglichkeit AuthorizationConfiguration.DocumentCategory24400 - Prüfziffer als JWS signieren mit ExternalAuthenticate
Das PS MUSS ihren Nutzern geeignete Auswahlmöglichkeiten bieten, um die Optionen der AuthorizationConfiguration.DocumentCategory auszuwählen, insbesondere die Kombination der mit dem Versicherten besprochenen Dokumentenkategorien gemäß [gemSpec_DM#Tab_DM_Dokumentenkategorien], für die eine Freigabe erfolgt. Das Primärsystem MUSS dem Leistungserbringer je nach dem Sektor, in dem er arbeitet, einen konfigurierbaren Defaultwert anbieten, der die Summe aller Kategorien umfasst, die ihm die Zugriffsunterbindungsregeln erlauben. Die Summe der für den Sektor des Primärsystems möglichen Zugriffsrechte ist aus der Tabelle [gemSpec_Dokumentenverwaltung#Tab_Dokv_030 - Zugriffsunterbindungsregeln] abzuleiten.
A_19497 - Auswahlmöglichkeit AuthorizationConfiguration.AuthorizationConfidentiality24540 - Prüfziffer als JWS signieren als ECDSA-Signatur
Das PS MUSS dem LE eine Auswahl an Optionen anzubieten, die dem Wunsch des Versicherten entsprechen, eine Zugriffsberechtigung AuthorizationConfiguration aus der Tabelle Tab_ILF_ePA_Zugriffsberechtigungen zu erteilen. Eine leere Auswahl ist nicht zulässig. Erfolgt keine anders lautende Auswahl, MUSS das PS für AuthorizationConfiguration.AuthorizationConfidentiality den Default-Wert normal setzen. Das PS MUSS die ausgewählte Kombination aus Zugriffsberechtigungen im Element AuthorizationConfiguration setzen.
[<=]
Durch die Erteilung einer Ad-hoc-Berechtigung wird eine Konfiguration der Zugriffsrechte erzeugt, die eine bereits bestehende Konfiguration überschreibt. Das betrifft auch ggf. bestehende Konfigurationen, die der Versicherte an seinem FdV vorgenommen hat.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_19498 - Speicherung RecordIdentifier in der lokalen Primärdokumentation des PS24542 - Prüfziffer als JWS signieren als PKCS#1-Signatur
Das PS MUSS den RecordIdentifier an der lokalen Patientenakte (Primärdokumentation) persistent speichern, falls die Ad-hoc-Autorisierung erfolgreich verlaufen ist. Zusätzlich MUSS die RequestFacilityAuthorization.AuthorizationConfiguration gespeichert werden, um für denselben Versicherten bei der nächsten Adhoc-Autorisierung dem Versicherten die Option anbieten zu können, dieselben Optionen wie beim letzten Mal zu setzen. 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. [<=]
Am Aktensystem werden Zugriffe auf Dokumente unterbunden, die nicht den gesetzlich festgelegten berufsgruppenspezifischen Regeln entsprechen. Manche Berufsgruppen verfügen nur über eingeschränkte Zugriffsrechte auf bestimmte Typen von Dokumenten. Die Auswahl von Dokumentenkategorien durch den Versicherten kann diese Zugriffsmöglichkeiten weiter einschränken, nicht jedoch über die gesetzlich festgelegten Rahmenbedingungen hinaus erweitern.
A_19386 - Respektieren der berufsgruppenspezifischen Zugriffsunterbindungsregeln
Das PS MUSS die in [gemSpec_Dokumentenverwaltung#Tab_Dokv - Zugriffsunterbindungsregeln] aufgeführten Zugriffsunterbindungsregeln beachten, um nicht unnötige Fehlermeldungen zu provozieren. Das PS darf nur solche Dokumentenkategorien zur Auswahl bringen, die der Berufsgruppe der SMC-B entsprechen, die für die Ad-hoc-Berechtigung verwendet wird. [<=]
Über die Operation ReadCardCertificate kann das PS die Berufsgruppe derjenigen SMC-B ermitteln, die für die ePA-Zugriffe benutzt wird. Im Authentisierungszertifikat C.AUT befindet sich die Berufsgruppe ProfessionOID in der ZertifikatsExtension Admission, s. [gemSpec_PKI#Anhang A].
Die Rolle des Versicherten kann teilweise auch vom Vertreter übernommen werden. In diesem Fall übergibt der Vertreter seine eigene eGK, um eine Ad-hoc-Berechtigung für den Versicherten zu erstellen, für den die Vertretung wahrgenommen wird (identifiziert durch dessen RecordIdentifier, aufgerufen aus der PS-Dokumentation des Vertretenen).
Durch das Starten des Anwendungsfalles aus dem Aktenkonto desjenigen heraus, der vertreten wird, wird dessen RecordIdentifier verwendet. Die Ermittlung desjenigen, der vertreten wird, kann nicht über die eGK des Vertreters erfolgen und muss vielmehr im Dialog mit dem Vertreter durchgeführt werden. Falls für den Vertreter die Vertretungsrechte nicht (mehr) vorliegen sollten, scheitert der Anwendungsfall Ad-hoc-Berechtigung durch den Vertreter erteilen. Dabei wird der Fehler 7209 (Keine Berechtigung für das Aktenkonto vorhanden) geworfen.
5.1.3.1 Schnittstelle
Tabelle 8: Tab_ILF_ePA_Operation_RequestFacilityAuthorizationGetrennte 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
|
|
||||||
|
|
|
|||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
|
|
||||||
getConsentDecisionInformation |
|
|
|||||
Abbildung 7: Abb_ILF_ePA_RequestFacilityAuthorization
Der Eingabeparameter AuthorizationConfiguration beschreibt
• Art des Zugriffs: die in Tab_ILF_ePA_Zugriffsberechtigungen erläuterten Werte
• Zugriffsberechtigungs-Endedatum. ExpirationDate berechnet aus der Dauer des Zugriffs (1 Tag, 7 Tage, 18 Monate, flexibel, unbefristet) (Default: 7 Tage).
A_15633-06 - Setzen des Elementes ExpirationDate
Das PS MUSS dem LE eine Konfigurationsauswahl gemäß Tabelle Tab_ILF_ePA_Zugriffsberechtigungs-Endedatum anbieten, in der ein Versicherter bestimmt, wie lange er dem LE eine Zugriffsberechtigung erteilt. Außerdem MUSS zusätzlich eine flexible Festlegung möglich sein. Erfolgt keine Festlegung, gilt der Default-Wert. Für die erteilte Berechtigung setzt das PS ein Zugriffsberechtigungs-Endedatum im Element ExpirationDate aufgrund der Berechnung des Datums des letzten Datums ab heute, zu dem die Zugriffsberechtigung noch besteht. 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: Tab_ILF_ePA_Zugriffsberechtigungs-Endedatum I_Medication_Service_eML_Render
|
|
||||
|
|
||||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
[<=]
Der Versicherte oder ein von ihm berechtigter Vertreter stimmt der Berechtigung auf Aktenzugriff durch PIN-Eingabe am Kartenterminal, in dem die eGK (des Versicherten bzw. des Vertreters) steckt, zu.
5.1.3.2 Umsetzung
Das Primärsystem nutzt beim Erteilen einer Ad-hoc-Berechtigung die Festlegungen zur Vertraulichkeitsstufe (AuthorizationConfidentiality) und die kategoriebasierte Berechtigung (DocumentCategoryList). Dokumentenspezifische Berechtigungen, d.h. Zugriffsberechtigungen, die sich auf einzelne ausgewählte Dokumente beziehen, können am PS nicht gesetzt werden. Dokumentenspezifische Berechtigungen erteilen kann nur der Versicherte an seinem Frontend.
Falls schon eine Berechtigung vorliegt, wird diese durch die Operation überschrieben.
Die Aktivitäten des Anwendungsfalles Ad-hoc-Berechtigung erteilen sind:
Vorbedingung:
• Ermittelter RecordIdentifier
Auslöser:
• Ein ePA-Anwendungsfall soll ausgeführt werden,
• Leistungserbringer fragen beim Versicherten eine Autorisierung für einen Aktenzugriff an,
• Ein Versuch, einen ePA-Anwendungsfall auszuführen scheiterte mit Fehler 7209 (Keine Berechtigung für das Aktenkonto vorhanden). Vor einem erneuten Versuch, einen ePA-Anwendungsfall auszuführen wird nun erst noch eine Ad-hoc-Berechtigung eingeholt.
Aktivitäten:
• Ermitteln des CardHandles zur eGK des Versicherten
• Abfrage getPinStatus, ob PIN.CH gesperrt ist
• Auswahl am PS
o der vom Versicherten intendierten (mündlich mitgeteilten) Art der Zugriffberechtigung im Element authorizationConfiguration
o des Zeitraumes, für die er dem LE Zugriff auf seine Akte gewährt (1 Tag, 7 Tage [default], 18 Monate, flexibel oder unbefristet);
• Aufruf der Konnektorschnittstelle unter Übergabe der Auswahl-Parameter
• Der Versicherte soll darüber informiert werden, dass er am Kartenterminal seine PIN zur Bestätigung der Auswahl eingeben muss;
• Die Erfolgsmeldung wird vom PS verarbeitet, indem der Zeitraum vermerkt wird, für den die Autorisierung vorliegt, sowie die RecordIdentifier
Resultat:
• Mit der vorliegenden Berechtigung ist die Voraussetzung für sämtliche Aktenzugriffe und Aktenadministrations-Anwendungsfälle gegeben
• Es liegt die RecordIdentifier vor, für die eine Zugriffsautorisierung besteht.
Abbildung 8: Abb_ILF_ePA_Ad-hoc-Berechtigung_erteilen
5.1.3.3 Nutzung
A_14517 - Speicherung RecordIdentifier in der lokalen Primärdokumentation des PS
Das PS MUSS den RecordIdentifier an der lokalen Patientenakte (Primärdokumentation) persistent speichern, falls die Ad-hoc-Autorisierung erfolgreich verlaufen ist. Zusätzlich MUSS das Zugriffsberechtigungs-Endedatum ExpirationDate aus RequestFacilityAuthorization.AuthorizationConfiguration.ExpirationDate als Ablaufdatum der Zugriffsberechtigung in der Primärakte des Versicherten gespeichert werden. [<=]
Die Ad-hoc-Berechtigung ermöglicht eine Abfrage der Metadaten der ePA-Dokumente und das Anlegen eines lokalen Metadaten-Index für die Dokumente, auf die prinzipiell Zugriffsrechte bestehen, als Vorbereitung von Dokumentenmanagement-Zugriffen.
5.1.3.4 Nutzung durch einen Vertreter
Die Ad-hoc-Berechtigung kann ein Vertreter für denjenigen durchführen, den er vertritt, falls die Vertreterberechtigung vom Vertretenen am FdV ausgestellt wurde. Ein Versicherter kann einen anderen Versicherten am PS nicht als Vertreter einrichten. Wohl aber kann der Vertreter die am Aktensystem vorliegende Vertreterberechtigung dafür nutzen, einer LEI im Rahmen der Ad-hoc-Berechtigung eine Zugriffsberechtigung auf das Konto des Vertretenen auszustellen.
Dazu muss der Vertretene in der LEI als Patient bekannt sein, jedoch nicht mit seiner eGK physisch anwesend sein. Der Vertreter teilt der LEI mit, für welchen Versicherten er sein Vertreterrecht wahrnehmen möchte, damit für den Vertretenen InsurantId und HomeCommunityID ermittelt werden können.
A_22396 - Veranlassung der Adhoc-Autorisierung durch einen Vertreter
Das PS MUSS anhand der Angaben eines Vertreters denjenigen Patienten in den Patientendaten ermitteln, für den dieser eine Vertretung wahrnehmen möchte, so dass ein RecordIdentifier gebildet werden kann, der die Akte des Vertretenen adressiert. [<=]
A_22399 - Nutzung von RequestFacilityAuthorization im Vertreterkontext
Das PS MUSS für die Ad-hoc-Autorisierung der LEI auf das Aktenkonto des Vertretenen (identifiziert durch dessen RecordIdentifier) ermöglichen, dass die eGK des Vertreters im Kartenterminal genutzt wird. Der Vertreter erstellt die Zugriffsfreigabe für die LEI mittels seiner eigenen PIN. [<=]
5.1.4 Sämtliche Berechtigungen der LEI ermitteln
Die Praxis von Herrn Dr. Weber hat von verschiedenen Versicherten eine Zugriffsberechtigung auf ihre ePA erhalten. Einmal am Tag, jeweils am frühen Morgen vor Öffnung der Praxis aktualisiert die Praxis die Informationen über die vorliegenden Zugriffsberechtigungen. Dadurch kann den Mitarbeitern der Praxis angezeigt werden, ob auch diejenigen Patienten, die an diesem Tag einen Behandlungstermin haben, eine Zugriffsberechtigung erteilt haben. Eine vorliegende Zugriffsberechtigung wird durch ein Icon am PVS angezeigt, so dass bei Bedarf mit den Patienten darüber geredet werden kann, ob das Erteilen einer Zugriffsberechtigung angeraten ist, und wie die dafür zu erteilende Zugriffsberechtigung gewählt werden sollte.
Durch Aufruf der Operation PHRManagementService::GetAuthorizationList erhält das PS eine Liste sämtlicher zum Zeitpunkt der Abfrage vorliegenden RecordIdentifier, auf die die LEI zugriffsberechtigt ist, sowie das jeweilige Ablaufdatum der Zugriffsberechtigung.
Der LE erhält über die Schnittstelle nicht nur Kenntnis über Zugriffsberechtigungen, die in der Ad-hoc-Autorisierung in seiner LEI erteilt wurden, sondern auch über Zugriffsberechtigungen, die vom ePA-Frontend des Versicherten aus erteilt oder geändert wurden.
Diese Daten stehen jedoch generell unter dem Vorbehalt, dass der Versicherte oder sein Vertreter diese Berechtigung am FdV jederzeit wieder entziehen kann.
5.1.4.1 Schnittstelle
Tabelle 10: Tab_ILF_ePA_Operation_GetAuthorizationListFü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
|
|
||||||
|
|
|
|||||
|
|
||||||
|
|
||||||
I_Medication_Service_FHIR |
|
||||||
Unterstützte FHIR-Ressourcen: GET <<FQDN des Aktensystems>>/medication/v1/fhir/MedicationRequest GET <<FQDN des Aktensystems>>/medication/v1/fhir/MedicationDispense GET <<FQDN des Aktensystems>>/medication/v1/fhir/Medication GET <<FQDN des Aktensystems>>/medication/v1/fhir/Practitioner GET <<FQDN des Aktensystems>>/medication/v1/fhir/PractitionerRole GET <<FQDN des Aktensystems>>/medication/v1/fhir/Organization |
|
|
|||||
Abbildung 9: Abb_ILF_ePA_Eingabeparameter_GetAuthorizationList
Die AuthorizationList als Liste von Tupeln aus RecordIdentifier und Ablaufdatum der Zugriffsberechtigung erlaubt die Aktualisierung von Info_Neu_Zugriff (über den RecordIdentifier) und Info_Ende_Zugriff (über das validTo-Element), indem die Liste der AuthorizationEntry-Elemente mit der Liste der bisher schon bekannten Berechtigungen auf Aktenzugriff verglichen wird.
Abbildung 10: Abb_ILF_ePA_GetAuthorizationListResponse
5.1.4.2 Umsetzung
Die Aktivitäten des Anwendungsfalles Sämtliche Berechtigungen der LEI ermitteln sind:
Vorbedingung:
1. Eine dem Aufrufkontext zugeordnete SM-B ist freigeschaltet.
Auslöser:
• Der tägliche Job wird in den Nebenzeiten angestoßen
Aktivitäten:
• Der Job läuft im Hintergrund und aktualisiert Informationen über erhaltene Berechtigungen.
Resultat:
• Informationen über erhaltene Berechtigungen wurden aktualisiert.
5.1.4.3 Nutzung
Die Liste der Autorisierungen, die für eine LEI vorliegen, wird mittels GetAuthorizationList tagesaktuell gehalten. Sie gibt Auskunft auch über Berechtigungen, die der Versicherte für die LEI am FdV vergeben hat. Die Information über die am FdV (und nicht ad-hoc) erteilten Berechtigungen können vom PS dazu genutzt werden, der LEI darüber Auskunft zu geben, dass die Akten bestimmter Versicherten aktuell nutzbar sind, ohne dass mittels RequestFacilityAuthorization oder GetAuthorizationState gezielte Maßnahmen bzw. Prüfungen vorgenommen werden, um diese Aktenkonten nutzbar zu machen.
Falls in der Vergangenheit eine Ad-hoc-Berechtigung erteilt wurde, zu der Details gemäß A_14517-* am PS gespeichert wurden, so können diese Informationen veralten, weil der Versicherte am FdV jederzeit Veränderungen vornehmen kann. Durch die tagesaktuelle Abfrage GetAuthorizationList können Änderungen erkannt werden, die Versicherte im Nachgang zu einer Ad-hoc-Berechtigung vorgenommen haben. In dieser Hinsicht kann die Autorisierungsliste aktueller sein als die aufgrund von A_14517-* am PS gespeicherten Informationen, wobei die bei der Ad-hoc-Berechtigung gespeicherten Daten detaillierter sind, denn sie umfassen zusätzlich die am Kartenterminal vergebenen Berechtigungskategorien.
A_19008-02 - Einschränkung der Häufigkeit der Abfrage getAuthorizationList
Das PS DARF den Request getAuthorizationList NICHT öfter als einmal pro Tag stellen. Abfragen, die zu häufig ausgeführt werden, führen zu Fehlerszenarien. [<=]
Der Konnektor wirft im Falle einer zu häufigen Anfrage von getAuthorizationList den Fehler 7231. Falls es eine Response mit der Warning 7230 gibt, konnten nicht alle Aktensysteme erfolgreich angefragt werden. Sowohl beim Fehler 7231, als auch bei der Warning 7230 darf nicht sofort ein Retry von getAuthorizationList durchgeführt werden.
Informationen über die erhaltenen Berechtigungen helfen dabei, die ePA-Nutzung im Vorfeld der Öffnung einer Praxis für den Besucherverkehr vorzubereiten. Sie sollten, um Spitzenlasten zu vermeiden, außerhalb der Hauptverkehrszeiten erfolgen. Keinesfalls darf ein getAuthorizationList vor jedem einzelnen Aktenzugriff erfolgen.
A_22388-05 - Aufruf von getAuthorizationList statistisch verteilt in den Nebenzeiten
Das PS SOLL GetAuthorizationList in den Nebenzeiten nutzen, bevorzugt nachts. Dabei MÜSSEN die Anfragen über die Clients eines Primärsystems hinweg betrachtet statistisch verteilt werden. [<=]
A_17143-01 - Nutzung von GetAuthorizationList für die Benachrichtigungsverwaltung
Das PS MUSS das Ergebnis der Operation GetAuthorizationList (Liste von Tupeln aus RecordIdentifier und ExpirationDate)bis zum Ablauf der Berechtigungen persistieren. Falls die AuthorizationList Versicherten-IDs enthält, die dem Primärsystem nicht bekannt sind, so dass sie keiner Primärdokumentation und keinem bestehenden oder vergangenen Behandlungskontext entsprechen, kann dieser RecordIdentifier verworfen werden. [<=]
Das PS erhält Kenntnis vom Aktenanbieterwechsel eines Versicherten über die GetAuthorizationListResponse, in der die aktualisierte HomeCommunityId des neuen Aktenanbieters enthalten ist
Sobald ein Versicherter den Aktenanbieter gewechselt hat, wird der alte RecordIdentifier (zum alten Aktenanbieter) aus der AuthorizationEntry-Liste entfernt. Beim Aktenanbieterwechsel wird die Berechtigung der LEI in die neue Akte transferiert, so dass ein neuer RecordIdentifier in der AuthorizationEntry-Liste erscheint. Anhand der bekannten InsurantId kann das PS feststellen, dass der bekannte Versicherte die Akte gewechselt hat, so dass der in der Primärakte für den Versicherten dokumentierte RecordIdentifier im PS aktualisiert werden kann.
5.1.4.4 Nutzung in größeren Institutionen
Das Ergebnis von GetAuthorizationList wird anhand der Telematik-ID der SMC-B gebildet, die aufgrund der Angaben im Context verwendet wird. Für größere Institutionen, etwa Krankenhäuser, die über eine Vielzahl von SMC-Bs verfügen, gilt:
• Es sollen nur der ePA-fähige Contexte (s. A_22398) für GetAuthorizationList verwendet werden. Damit ist sichergestellt, dass die Abfrageergebnisse Aussagen über Telematik-IDs beinhalten, die effektiv für die Anwendung ePA verwendet werden.
• Anfragen, die über ihre Contexte unterschiedliche SMC-Bs verwenden, aber dieselbe Telematik-ID enthalten, ergeben ein identisches Ergebnis und sind somit überflüssig.
5.1.5 Einzelne Berechtigungen der LEI ermitteln
Frau Gundlach tritt an den Tresen der Arztpraxis Dr. Weber, um sich für ihre erste Schwangerschaftskontrolluntersuchung zu melden. Aufgrund der täglich ermittelten Zugriffsberechtigungsliste sieht die Arzthelferin in der GUI ihres PVS, dass Frau Gundlach der Arztpraxis noch keine ePA-Zugriffsberechtigung erteilt hat, so dass die Ergebnisse der Untersuchung noch nicht in den elektronischen Mutterpass eingetragen werden können. Weil das Kartenterminal gerade durch andere Patienten belegt ist, kann eine Ad-hoc-Berechtigung aktuell nicht durchgeführt werden. Frau Gundlach verspricht, die Berechtigung an ihrem Mobiltelefon, bzw. ihrem FdV zu erteilen, während sie im Wartezimmer auf den Termin mit Dr. Weber wartet. Sie vergibt die Zugriffsberechtigung für 12 Monate. Die Arzthelferin möchte einige Zeit später erste Daten in den elektronischen Mutterpass von Frau Gundlach eintragen. Um unnötigen Fehlern vorzubeugen erfragt sie gezielt, ob Frau Gundlach diese Berechtigung inzwischen erteilt hat. Frau Gundlach hat die Berechtigung im Wartezimmer erteilt. Die Arzthelferin trägt erste Daten in den Mutterpass von Frau Gundlach ein.
Leistungserbringer können mittels der Operation GetAuthorizationState gezielt abfragen, ob ein bestimmter Versicherter der eigenen LEI eine ePA-Zugriffsberechtigung erteilt hat, und welches das Ablaufdatum ist.
Die KVNR des Versicherten wird im RecordIdentifier an der Schnittstelle übergeben, zusammen mit dem Parameter UserAgent, der vom Primärsystem automatisiert befüllt wird.
Die Rückgabe beinhaltet eine Liste von Ablaufdaten für Berechtigungen, die jeweils auf eine Anwendung bezogen sind. Für die Anwendung Elektronische Patientenakte wird der Wert "ePA" mit dem Ablaufdatum der ePA-Berechtigung als Listenelement mitgeliefert.
5.1.5.1 Schnittstelle
Tabelle 11: Tab_ILF_ePA_Operation_GetAuthorizationStateA_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
|
|
|||||
|
|
|||||
Anwendungsfall |
|
|
||||
Dokumente einstellen |
|
|
||||
Dokumente suchen |
|
|
||||
|
|
|
||||
Dokument löschen |
|
|
||||
Aktualisieren von Metadaten |
|
|
||||
Die Angabe des UserAgents dient der Performance-Rohdatenerfassung und wird ohne kundenspezifische Angaben ausschließlich durch firmwarespezifische Angaben des PS-Herstellers gemäß [gemSpec_DM_ePA#A_22470-*] gebildet.
5.1.5.2A_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 Einzelne Berechtigungen der LEI ermittelnDokumente einstellen sind:
Vorbedingung:
• Eine dem Aufrufkontext zugeordnete SM-B ist freigeschaltet.
Auslöser:
Anlass, die Berechtigungsvergabe eines bestimmten Versicherten für die LEI zu prüfen 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:
• Aktualisierung der Informationen über erhaltene Berechtigungen.
Resultat:
• Informationen über erhaltene Berechtigungen wurden aktualisiert.
5.1.5.3 Nutzung
GetAuthorizationState ist geeignet, um in konkreten Nutzungsszenarien gezielte Abfragen für einzelne Versicherte zu tätigen. Falls Informationen für eine Vielzahl von Versicherten eingeholt werden sollen, sollte abgewogen werden, ob die Nutzung von GetAuthorizationList nicht effektiver ist, auch wenn sie nur einmal täglich durchgeführt werden darf.
Die durch GetAuthorizationList gebildete Autorisierungsliste, die für eine LEI vorliegen, umfasst auch Berechtigungen, die der Versicherte am FdV vergeben hat, und sind tagesaktuell. Die Operation GetAuthorizationState bildet in zwei Fällen eine Ergänzung bzw. eine Alternative:
• Die Information über den Berechtigungsstatus soll noch aktueller sein, etwa weil eine gerade eben am FdV vergebene Berechtigung geprüft werden soll;
• Das PS soll ausschließlich in dedizierten Nutzungsszenarien Informationen über den Berechtigungsstatus eines konkreten Versicherten erhalten. Andere Informationen sind nicht erwünscht, GetAuthorizationList wird daher nicht verwendet.
Sowohl GetAuthorizationList als auch GetAuthorizationState erfassen Berechtigungen, die der Versicherte ad-hoc oder am FdV vergeben hat.
A_22480 - Einschränkung der Häufigkeit der Abfrage getAuthorizationState
Das PS MUSS zwischen zwei getAuthorizationState Requests für den gleichen Versicherten einen zeitlichen Abstand von 10 Minuten einhalten. Abfragen, die für einen Versicherten zu häufig ausgeführt werden, werden vom Konnektor abgewiesen. [<=]
5.2 Dokumentenmanagement
Der Konnektor bietet dem PS mit dem Dienst PHRService eine Dokumentenverwaltung auf Basis einer Profilierung der IHE-Spezifikationen rund um das Kernprofil XDS.b (Cross-Enterprise Document Sharing) an.
Tabelle 12: Tab_ILF_ePA_PHRService
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tabelle 13: Tab_ILF_ePA_DM_Profilierung
|
|
|
|
|
|
|
|
|
|
|
|
Tabelle 14: Tab_ILF_ePA_Einschränkungen_auf_XDS.b
|
|
|
|
|
|
|
|
A_14418 - MTOM-Pflicht bei [ITI-41]
Das PS MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-41] zur Übertragung von Dokumenten eine Kodierung mittels MTOM/XOP [MTOM] gemäß [IHE-ITI-TF2x#V.3.6.] verwenden. [<=]
A_15084 - SOAP-Header nach [SOAP 1.2]
Das PS MUSS in der Dokumentenverwaltung die SOAP-Nachricht konform zu [SOAP 1.2] bilden. [<=]
Die Anwendungsfälle des Dokumentenmanagements der Akte erfordern, dass der Nutzer die Berechtigung hat, auf mindestens eine SM-B zuzugreifen, die für die LE-Institution vorliegt und dass eine durch eine Telematik-ID identifizierte Institution oder ein durch eine Telematik-ID identifizierter Teil einer Institution eine Berechtigung erhalten hat. Um diese Berechtigung durchzusetzen ist eine Konfiguration am Konnektor administrativ zu pflegen und vom PS zu nutzen.
Drei Elemente des Aufrufkontextes eines SOAP-Clients geben bei einem Zugriff des Dokumentenmanagements im SOAP-Header darüber Auskunft, von welchem Clientsystem-Arbeitsplatz ein Aufruf auf welche Akte erfolgt:
Tabelle 15: Tab_ILF_ePA_ClientInformationen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die interne Mandantenverwaltung des PS SOLL auf die WS-Kommunikation der ePA über die Nutzung der MandantID abgebildet werden. Die MandantID steht für die Kennung der PS-Mandanten. Die Konfiguration von PS-Mandanten, SM-Bs und Arbeitsplätzen wird in [gemILF_PS] geschildert, die Konfiguration für größere LE-Institutionen mit mehreren SM-Bs oder Mandanten in Kapitel 3.3.3.
Der Nutzer ist durch die lokale Mandantenverwaltung seines Primärsystems berechtigt auf die Primärdokumentation des Versicherten zuzugreifen und wird durch die Konfiguration der Mandantenverwaltung im Konnektor derjenigen SM-B zugeordnet, die er für den Zugriff auf die Akte benötigt.
In der Administrationsoberfläche des Konnektors wird gemäß [gemSpec_Kon#10.3.1.1] im Informationsmodell der LE-Institution die Default-SM-B der Arbeitsplätze, Clientsysteme und Kartenterminals für den Zugriff auf die ePA konfiguriert. Für die Administration des Default-Aufrufkontextes s. [gemSpec_FM_ePA#6.4].
Ad-hoc-Berechtigung erteilen ist nicht davon abhängig, ob für eine LEI eine oder mehrere SM-Bs im Verzeichnisdienst eingepflegt sind. Falls mehrere SM-Bs in einer LEI verwendet werden, sind die unterschiedlichen Primärsystem-Arbeitsplätze erst dann zugriffsberechtigt, wenn der Aufrufkontext oder der Default-Aufrufkontext SMC-Bs mit derjenigen Telematik-ID zugeordnet sind, für die eine Berechtigung erteilt wurde.
A_14475 - SOAP-Header-Clientparameter bei gesamthaft berechtigten LE-Institutionen
Falls der LE-Institution nur eine einzelne Telematik-ID zugeordnet ist, KANN das PS die in Tab_ILF_ePA_ClientInformationen aufgeführten Parameter des SOAP-Headers in jedem Zugriff des Dokumentenmanagements verwenden. [<=]
Wenn der Parameter nicht gesetzt wird, verwendet das Fachmodul ePA den in der Konnektorkonfiguration hinterlegten Default-Wert.
A_14476 - SOAP-Header-Clientparameter bei unterschiedlich berechtigten Teilen von LE-Institutionen
Falls der LE-Institution mehrere Telematik-ID zugeordnet sind, MUSS das PS die in Tab_ILF_ePA_ClientInformationen aufgeführten Parameter des SOAP-Headers in jedem Zugriff des Dokumentenmanagements verwenden. [<=]
A_14698 - Einstellen von Zugriffsinformationen in Metadaten
Für die Weiterverarbeitung auf Dokumentenebene MÜSSEN Zugriffsinformationen gemäß Tab_ILF_ePA_Zugriffsinformation_Werte zusätzlich in die Metadaten der Dokumentenmanagement-Zugriffe eingestellt werden:
Tabelle 16: Tab_ILF_ePA_Zugriffsinformation_Werte
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
Das Ersetzen eines Dokumentes ist als Kombination mehrerer Anwendungsfälle umzusetzen: Nach dem Ermitteln (Suchen, Kap. 5.2.2) und Löschen des zu ersetzenden Dokumentes (Kap. 5.2.5) nach Rücksprache mit dem Versicherten wird das ersetzende Dokument (als "Original"-Dokument, s. A_14250) in die ePA eingestellt (Kap. 5.2.1).
5.2.1 Dokumente einstellen
Herr Dr. Weber hatte für Frau Gundlach vor einigen Monaten einen Notfalldatensatz auf ihre eGK geschrieben. Dr. Weber bespricht mit Frau Gundlach, ihren Notfalldatensatz auch in ihre ePA einzustellen. Frau Gundlach erteilt eine Ad-hoc-Berechtigung für diesen Zugriff. Bei Auswahl der entsprechenden Funktion nutzt Dr. Weber die Möglichkeit, die Metadaten zu kontrollieren, mit denen der Notfalldatensatz automatisch für die Akte von Frau Gundlach konnotiert werden. Dr. Weber nimmt kurz Notiz von der Bestätigungsmeldung über den Erfolg des Einstellens.
A_15653 - Funktionsmerkmal Dokumente Einstellen
Das PS MUSS es dem Leistungserbringer ermöglichen, ePA-Dokumente in die Akte eines Versicherten einstellen zu können. Dafür MUSS das PS die Konnektorschnittstellenoperation ProvideAndRegisterDocumentSet-b verwenden. [<=]
Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer Einstellen aus [gemSysL_ePA#3.7.1, UC 4.1 - Dokumente durch einen Leistungserbringer einstellen] wird Provide & Register Document Set-b [ITI-41] gemäß Cross-Enterprise Document Reliable Interchange (XDR) Profile profiliert.
Tabelle 17: Tab_ILF_ePA_IHE-Profilierung_ITI41
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Unterstützung für RPLC (replace) hat zur Folge, dass Dokumente ersetzt werden können durch eine neue Version des gleichen Dokuments. Das hat zur Folge, dass das alte Dokument in den Status (DocumentEntry.availabilityStatus) "Deprecated" wechselt und mit dem neuen Dokument (Status "Approved") über eine "RPLC"-Association verbunden wird. Der AvailabilityStatus wird beim Dokumente einstellen ausschließlich vom Aktensystem automatisiert gesetzt bzw. geändert.
5.2.1.1 Schnittstelle
Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRepository) die Operation DocumentRepository_ProvideAndRegisterDocumentSet-b an, und übernimmt gemäß [ITI-41] die Rolle eines IHE DocumentRepository gegenüber dem PS.
Tabelle 18: Tab_ILF_ePA_Operation_Dokument_einstellen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A_14201 - Anwendungsfall Dokumente einstellen
Das PS MUSS bei vorliegender Berechtigung Dokumente in die Akte eines Versicherten einstellen können. Das Primärsystem MUSS im Dienst PHRService des Konnektor-Fachmoduls die Operation DocumentRepository_ProvideAndRegisterDocumentSet-b nutzen [gemSpec_FM_ePA#7.1.1.1] und dazu schemakonforme SOAP-Nachrichten erstellen können. [<=]
Generell besteht ein Schreibrecht im Rahmen der Zugriffsunterbindungsregeln, sobald eine LEI über irgendeine Art von Zugriffsberechtigung verfügt. Vor dem Einstellen von MIOs des Typs Mixed oder Uniform (MIOs in statischen Ordnern, d.h. alle MIOs bis auf Mutterpass und U-Heft) sollen jedoch bereits bestehende fachliche MIO-Inhalte geprüft werden, so dass sichergestellt werden kann, dass die neu einzustellenden MIO-Daten konsistent sind zu den bereits bestehenden.
A_22523-03 - Kein Einstellen von Dokumenten bei fehlender Leseberechtigung auf statische Ordner
Das PS MUSS beim Einstellen von MIOs die entsprechenden statischen Ordner gelesen haben, damit bereits bestehende Daten fachlich gewürdigt werden können. Dafür ist ein FindFolders für die gewünschten MIO-Kategorien erforderlich. Falls ein FindFolders auf eine Kategorie mit statischen Ordnern keine Ordnerreferenz liefert, besteht keine Leseberechtigung für diese Kategorie. [<=]
Dynamische Ordner sind bei fehlenden Zugriffsrechten für das PS nicht zu ermitteln, so dass sich nicht feststellen lässt, ob dynamische Ordner bereits angelegt wurden. Auch ist nicht ohne schreibenden Zugriff und Auswertung der Fehlermeldung zu ermitteln, dass hier ein Zugriffsrecht fehlt. Der IHE-Fehlercode DocumentAccessNotAuthorized informiert darüber, dass eine Vergabe von Zugriffsrechten für Sammlungstypen mixed und uniform erforderlich ist, um Dokumente erfolgreich einstellen zu können. Dabei muss die Vertraulichkeitsstufe der Kategorienberechtigung vom Versicherten passend gewählt werden.
Dokumente, die auf einer Denylist stehen oder für die aufgrund der Vertraulichkeitsstufe keine Leseberechtigung besteht, sind für das PS nicht zu ermitteln.
Durch das Auslesen von (MIO)-Foldern und die fachliche Sichtung der bereits bestehenden Daten im Vorfeld des Schreibens können folgende Probleme im Vorfeld verhindert werden:
• MIO-Eintrags-Verdoppelung: MIO-Datenelemente, die einmalig vorliegen sollen, dürfen nicht doppelt/parallel angelegt werden. Es soll z.B. verhindert werden, dass eine Anamnese im Mutterpass doppelt eingestellt wird oder identische Impfeinträge doppelt angelegt werden.
• Dokumentenverdoppelung: Leistungserbringer oder Primärsysteme sollen prüfen, dass sie MIO-Einträge (in statischen Ordnern) oder Dokumente nicht bereits eingestellt haben.
Ordnerverdoppelung: Dynamische Ordner sollen nicht doppelt angelegt werden, nur weil Leistungserbringer ohne es überprüft zu haben davon ausgehen, dass für Kinder oder Schwangerschaften dynamische Ordner noch fehlen.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 imin [gemSpec_DM_ePAAktensystem_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_DM_ePA#TabelleAktensystem_ePAfuerAlle#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] befüllen. Das PS MUSS alle mit der Kardinalität [1..1] markierten Metadatenfelder setzen. [<=]
Hinweis: In seltenen Fällen werden im vorliegenden Dokument Anforderungen formuliert, die Felder zu Pflichtfeldern erklären, auch wenn sie im Datenmodell [gemSpec_DM_ePA#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] noch als optional [0..1] gekennzeichnet sind. In diesen Fällen wird eine Verschärfung der Prüfpflichten des Aktensystems erst noch eingeführt. Sobald die Kardinalität [1..1] festgeschrieben ist, muss das Aktensystem abweichende Requests abweisen.
Die Auswahl der Metadaten soll möglichst weitgehend automatisiert werden.
A_16194 - Änderbarkeit der Metadaten - Auswahllisten
Bei der Auswahl der Metadaten zum Zwecke des Einstellens von Dokumenten MUSSSOLL das PS insbesondere im Falle erforderlicher Auswahldialoge beachten:
Diedie Bildung von Auswahllisten erfolgt gemäß[gemSpec_DM_ePA] und Kap. 6;Anhang B,- Auswahllisten sind konfigurativ änderbar
;, Das PS kannMetadatendem Benutzerwerden weitestgehend automatischgefüllte Metadaten zur händischen Nacheditierung anbietenvorbefüllt,- Nutzer können Metadaten editieren.
[<=]
A_20179-01 - Setzen der Vertraulichkeitsstufe
Beim Einstellen von Dokumenten MUSS das PS für jedes Dokument eine Vertraulichkeitsstufe wählen, die dem Wunsch des Versicherten entspricht, d.h. entweder "streng vertraulich" (very restricted), "vertraulich" (restricted) oder "normal" (normal). [<=]
Eine entsprechende Absprache zwischen LEI und Versichertem muss nicht zwangsläufig explizit für jedes einzelne Dokument getroffen werden, sondern kann auch im Vorfeld stattfinden, z. B. über eine Vereinbarung über die Vertraulichkeitsstufe von bestimmten Dokumententypen oder ähnliche Mechanismen.
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
gemäß der Regeln in [gemSpec_DM_ePA#Tab_DM_Dokumentenkategorien]. 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
istMUSS dieAngabe derFolderUUIDerforderlich.angegeben werden.
[<=]
Dokumente werden statischen Ordnern automatisch am Aktensystem aufgrund der vergebenen Metadaten zugeordnet. Dokumente werden dynamischer Ordnern (mothersrecord und childsrecord) hingegen durch das PS zugeordnet.
Ob das U-Heft in die Akte des Kindes oder der gesetzlichen Vertreter eingestellt werden soll, regeln fachlichen Vorgaben in [KBV-UHeft]. Die technische Lösung der ePA2 ist für das U-Heft hinsichtlich der zu wählenden Akte flexibel.
A_22515 - Pflicht zum Setzen von Dokumenten-Titeln
Das PS MUSS beim Einstellen von Dokumenten documentEntry.title belegen. Falls möglich soll der Titel des Dokumentes eine fachliche Beschreibung des Dokumentes enthalten. [<=]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-0103 - Titel dynamischer Ordner für Schwangerschaften
Der Leistungserbringer legt bei Bedarf dynamische Ordner an (childsrecord, mothersrecord)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 childsrecord identifiziert ein Kind. Folder.title MUSS mit dem Namen und Geburtsdatum des Kindes belegt werden. Bildungsregel: Nachname + ", " + 1. Vorname + " "Datum im Format TT.MM.YYYY. Beispiel: "Musterkind, Max 03.03.2017"
Der dynamische Ordner der Kategorie mothersrecordpregnancy_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 mothersrecorddynamischen 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-0304 - Für Mutterpass und U-Heft dynamischepregnancy_childbirth dynamischen Ordner auswählen
Falls das hochzuladende Dokument in die Kategorien mit dynamischen Ordnern fällt (mothersrecord und childsrecord, siehe [gemSpec_DM_ePA#Tab_DM_Dokumentenkategorien])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 die Dokumentenverwaltungden XDS Document Service im ePA-Aktensystem wird die DocumentEntry.UniqueID in die Metadaten der IHE-Nachrichten eingestellt:
- DocumentEntry.@id
- ExternalIdentifier.@id
[<=]
Das PS soll die DocumentEntry.UniqueID gemäß [ITI-TF-3#4.2.3.2.26] nicht nur für das Laden von Dokumenten, sondern auch in der Primärakte verwenden. Eine aktenweit eindeutige DocumentEntry.UniqueID ermöglicht dem PS eine zuverlässige Benachrichtigungsverwaltung (s. Kap. 5.3.1 und Kap. 5.2.3).
Wenn für das Feld SubmissonSet.AuthorPerson keine Person als Einsteller angegeben werden kann, ist das Feld mit Werten zu befüllen, mit denen die einstellende Softwarekomponente beschrieben wird. Laut [gemSpec_DM_ePA#AAktensystem_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
5.2.1.2 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente einstellen sind:
Vorbedingung:
• Ermittelter RecordIdentifier
• Das einzustellende Dokument sollte mit dem Versicherten besprochen sein
• ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufen
Auslöser:
• Nutzerinteraktion
Aktivitäten:
• Auswahl der RecordIdentifier
• Auswahl der Dokumente
• Ermittlung der Metadaten zu den Dokumenten
• Generierung inklusive Metadaten
• Validierung der Nachricht
• Versand der Nachricht
• Auswertung des Ergebnisses
Resultat:
• Die Antwort gibt Auskunft darüber, ob die Dokumente eingestellt werden konnten oder nicht.
Beispiel #: Bsp_ILF_ePA_ProvideAndRegisterDocumentSetRequest
XDS-Option „Document Replacement“ - Ersetzen eines existierenden Dokuments
Ein eingestelltes Dokument kann auch ein existierendes Dokument ersetzen. Dies erfolgt durch Verwendung der „Document Replacement“-Option. Dazu wird das gleiche Dokument (mit geändertem Inhalt und nebst ggf. geänderten DocumentEntry-Metadaten) erneut hochgeladen. Das neue Dokument erhält den Status „Approved“. Das alte Dokument geht in den Status „Deprecated“. Beide Dokumente werden über eine „Replace“-Assoziation miteinander verbunden, so dass nach dem Einstellen erkennbar ist, dass das neue Dokument das alte ersetzt. Lädt man erneut eine neue Fassung hoch, erhält man analog zwei Dokumente im Status "Deprecated" und das neueste im Status "Approved".Alle alten Dokumente (Status "Deprecated") können nach wie vor gefunden und heruntergeladen werden. Einige Suchen erlauben das Filtern nach Status bzw. zeigen per Default auch nur Dokumente im Status „Approved“ an.Eingestellt (im „Submission Set“) wird das neue Dokument inkl. DocumentEntry-Metadaten, ein Verweis auf das alte Dokument und die verbindende „Replace“-Association (urn:ihe:iti:2007:AssociationType:RPLC).
Das Ersetzen eines existierenden Dokuments mit der XDS-Option „Document Replacement“ eignet sich dafür, eine Änderung an einem bereits bestehenden Dokument abzubilden. Dies gilt insbesondere für Dokumente, bei denen es zu jedem Zeitpunkt nur eine einzige gültige Dokumentenversion gibt, etwa für den Notfalldatensatz, den elektronischen Medikationsplan und den Datensatz persönliche Erklärungen.
Durch Setzen von Metadaten Dokumente werden gemäß gemSpec_DM_ePA#A_19388-* je unterschiedlichen Foldern zugeordnet. Beim Hochladen eines Dokumentes mittels DocumentRepository_ProvideAndRegisterDocumentSet-b bei Nutzung der RPLC-Option gilt es zu verhindern, dass ein Dokument beim nachfolgenden Hochladen eine andere Folderzuordnung erhält als beim initialen Hochladen. Eine Änderung der Folderzuordnung hätte Einfluss auf die Freigabeentscheidung des Versicherten. Die vollständige Liste der Dokumenten-Kategorien, wie sie dem Versicherten am Kartenterminal bei der Ad-Hoc-Berechtigung angezeigt werden, findet sich in [gemSpec_FM_ePA#Tab_FM_ePA_042 - Mapping von DocumentCategoryEnum auf Anzeigetext am Kartenterminal]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 MUSS sichDARF beim Hochladen eines Dokumentes mittels DocumentRepository_ProvideAndRegisterDocumentSet-b bei Nutzung der RPLC-Option an Metadaten die Werte des bestehenden Dokumentes unverändert lassen, da diese Einfluss auf die Zuordnung des Dokumentes zu Foldern haben. Dies betrifft insbesondere die Metadaten:
• documentEntry.healthcareFacilityTypeCode
• documentEntry.practiceSettingCode
• documentEntry.classCode
• documentEntry.formatCode
• documentEntry.typeCode
• documentEntry.mimeType
[<=]
Korrekturen an den genannten Metadaten müssen durch Löschen und Neueinstellung des Dokumentes realisiert werden.
5.2.1.3 NutzungKEINE Veränderung vornehmen. [<=]
Dokumente, die Leistungserbringer einstellen, werden unabhängig vom Inhalt des Dokumentes als LE-Dokumente (Kennzeichnung über entsprechende Auswahl aus SubmissionSet.AuthorRole, siehe [gemSpec_DM_ePA#2.1.4.1], und dem konfigurierten XDSDocumentEntry.healthcareFacilityTypeCode) kategorisiert, um sie von Dokumenten zu unterscheiden, die vom Versicherten selbst (SubmissionSet. AuthorRole="102") oder von Kostenträgern (SubmissionSet.AuthorRole="105") eingestellt wurden. Das heißt u. a., dass die Codes für Versicherte und Kostenträger ("102" und "105") dabei explizit nicht verwendet werden dürfen.
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_
DM_ePAAktensystem_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
(Kap. 6.2, A_15086-*)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 (
Kap. 6.2,A_15086-*) - Das PS MUSS sicherstellen, dass der XDSDocumentEntry.healthcareFacilityTypeCode nicht mit den Werten "KTR" oder "EGA" belegt wird.
DocumentEntry und SubmissionSet enthalten übereinstimmende Werte, wenn der Autor des Dokumentes aus der das Dokument einstellenden Institution stammt. Falls eine LEI ein Dokument hochlädt, das einer Quelle außerhalb der hochladenden LEI entstammt, können diese Wert voneinander abweichen.
A_14251 - Vom LE in die Akten einstellbare Dokumententypen24967 - Konvertieren von PDF in PDF/A
Das PrimärsystemPS MUSS die in die ePA einstellbaren Dokumententypen aus [gemSpec_DM_ePA#A_14760] in die ePA einstellen können.
[<=]
Beispiel #: Bsp_ILF_ePA_ProvideAndRegisterDocumentSetResponse
In [gemSpec_DM_ePA#A_14760] ist beschrieben, bei Einhaltung welcher Vorgaben konsistente Metadaten für das Einstellen des Dokumentes erzeugt werden können.
A_16187 - Maximalgröße des Dokumentes
Das PS MUSS sicherstellen, dass jedes einzelne einzustellende Dokument nicht größer als 25 MB ist, und dass ein Satz der in einem einzelnen Request einzustellenden Dokumente insgesamt nicht größer als 250 MB ist. [<=]
A_16188 - MTOM-Pflicht bei [ITI-43]
Das PS MUSS bei der Umsetzung der IHE XDS-Transaktion [ITI-43] die Übertragung von Dokumenten mit MTOM/XOP [MTOM] umsetzen.[<=]
Tabelle 19: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_einstellen
|
|
|
|
|
|
|
|
|
5.2.2 Dokumente suchen
Frau Gundlach berichtet Dr. Weber über den Arztbrief, den ihr Radiologe vor wenigen Tagen in ihre Patientenakte geschrieben hat. Dr. Weber sieht in seiner lokalen Akte, dass die 7 Tage lang gültige Berechtigung auf die elektronische Akte zuzugreifen, noch nicht abgelaufen ist. Er sucht nach dem Arztbrief des Radiologen über dessen Namen in der ePA-Suchmaske des PVS. Sein PVS zeigt ihm Metadaten zum Arztbrief des Kollegen an.
Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer suchen aus [gemSysL_ePA#3.7.3, UC 4.3 - Dokumente durch einen Leistungserbringer suchen] wird Registry Stored Query [ITI-18] profiliert.
A_15652 - Funktionsmerkmal Dokumente Suchen
Das PS MUSS es dem Leistungserbringer ermöglichen, ePA-Dokumente in der Akte eines Versicherten suchen zu können. Dafür MUSS das PS die Konnektorschnittstellenoperation RegistryStoredQuery verwenden.
[<=]
Tabelle 20: Tab_ILF_ePA_IHE-Profilierung_ITI18
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Suchen nach Dokumenten erfolgt auf den Metadaten des Dokumentes, nicht auf den Inhalten des Dokumentes selbst. Die Suche kann zur Anzeigen der Metadaten eines Dokumentes verwendet werden.
Um Dokumente suchen zu können, brauchen Leistungserbringer nicht zu wissen, welche Art Berechtigung sie erhalten haben (Zugriffsberechtigung auf LE-Dokumente, Versicherten-Dokumente oder mehrere dieser Dokumententypen). Die Suche erfolgt immer ausschließlich auf den berechtigungsgemäß tatsächlich zugänglichen Dokumenten, nie auf Dokumenten, für die keine Zugriffsberechtigung bestehtDokumente 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 zu einem RecordIdentifier sind u. a. folgende Filterfunktionen möglich:
- kein Filter
- Zeitintervall
- Dokumentenkategorie, darunter auch Dokumentenkategorie 1a (Suche über Ordner)
- Dokumentenquelle (z. B. eine bestimmte Facharztgruppe)
- SubmissionSet-Identifier
6. Submission-Zeit
Weitere für Suchstrategien geeignete Metadaten von Dokumenten (Metadaten) können [gemSpec_DM_ePA] entnommen werden. Sie beziehen sich vor allem auf Informationen der Dokumentenverwaltung, weniger auf den (medizinischen) Inhalt der Dokumente.
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:
1. Die Auswahl der Metadaten-Suchstrategie (Wahl eines geeigneten StoredQuery)
2. Je nach Wahl des Suchtyps und der Ergebnistypen LeafClass oder ObjectRef werden die Dokumente direkt oder nach einem zusätzlichen Auswahlschritt angezeigt:
a. Leafclass: Auswahl anhand der Metadaten-Suchergebnisse
b. ObjectRef: Direkte Auswahl der anzuzeigenden Dokumente ohne zusätzlich verfügbare Metadaten
3. 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_21133 - Identifizierung unscharfer Ergebnisse
Das PS SOLL etwaige unscharfe Suchergebnisse (siehe gemSpec_Dokumentenverwaltung#A_21131) in der Ergebnismenge als solche kennzeichnen können.[<=]
5.2.2.1 Schnittstelle
Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRegistry)die Operation DocumentRegistry_RegistryStoredQuery an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-18] folgt und die Rolle eines IHE DocumentRegistry gegenüber dem PS übernimmt.
Tabelle 21: Tab_ILF_ePA_Operation_Dokument_suchen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A_17198-01 - 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-TF2a#3.18.4.1.2.3.7.1] in Verbindung mit dem zusätzlich zu [ITI-18] eingeführten Suchparameter $XDSDocumentEntryTitle nutzen können. Der zusätzliche Parameter $XDSDocumentEntryTitle ist verpflichtend und filtert die Suchergebnismenge über das Attribut XDSDocumentEntry.title, siehe auch [gemSpec_Dokumentenverwaltung#A_17184]. [<=]
A_18197 - Suche nach Institutionen im Anfragetyp "FindDocumentsByTitle"
Das PS KANN im Anfragetyp FindDocumentsByTitle den optionalen Parameter $XDSDocumentEntryAuthorInstitution setzen, um eine Suchanfrage nach Institutionen durchzuführen, bei denen die Ergebnismenge auf Einträge eingeschränkt wird, die im XDSDocumentEntry.author-Slot über ein zutreffendes authorInstitution-Sub-Attribut verfügen. [<=]
-
Für die Suche über beiden Parameter.
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
Ob und inwieweit unscharfe Ergebnisse für diese Parameter zurückgegeben werden, kann das PS nicht steuern.
5.2.2.2 UmsetzungXDSDocumentEntry.comment.
Die Umsetzung der SuchenSuche 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.
Tabelle 22: Tab_ILF_ePA_FindDocuments_Pflichtfelder
|
|
|
|
|
|
|
|
|
Je nachdem, ob returnType auf LeafClass oder ObjectRef gesetzt wird, enthält die Response der Suche eine Objektliste im Result (LeafClass) oder eine Liste von Objektidentifiern (ObjectRef), s. [ITI-18#3.18.4.1.2.6].
3.11.2.1 Umsetzung
Die Aktivitäten des Anwendungsfalles Dokumente suchen sind:
Vorbedingung:
• Ermittelter RecordIdentifier
ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufenVorbedingungen:
- Ausgewählte KVNR
- gültige Befugnis
Auslöser:
- Nutzerinteraktion
- anlassbezogene Suche
Aktivitäten:
1. Auswahl der RecordIdentifier
- Auswahl der Suchkriterien
- Generierung und Versand der Nachricht
- (optional) Filterung der Ergebnisse
- (optional) Sortierung des Ergebnisses
Resultat:
- Ergebnismeldung
- Dokumenten-UUID-Liste (XDSDocumentEntry_uniqueId)
53.211.2.32 Nutzung
A_14907 - Setzen des Message-Identifiers im Dokumentensuche-Request16336-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
WS-Requests der Dokumentensuche werden alsAdhocQuerymit der Stored Query ID aus [ITI-18#3.18.4.1.2.4] an die ePA-Aktensysteme versendet. Dabei MUSS das PS diewsa:MessageIDalsUUIDgemäß PHR_Common.xsd im SOAP-Header des Requests setzen.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".
[<=]
Beispiel #:Bsp_ILF_ePA_Request_AdhocQuery Das Ergebnis der Suche in der Dokumenten-Registry sind Mengen eindeutiger Dokumenten-Identifier als UUID.
Das PS soll Stored Query IDs der Tab_ILF_ePA_StoredQueries gemäß [ITI-18#3.18.4.1.2.4] verwenden.
Tabelle 23: Tab_ILF_ePA_StoredQueries
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A_15088-01 - LE-Dokumente suchenA_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 SOLL mittels RegistryStoredQuery über SubmissionSet.authorPerson Dokumente herausfiltern können, die von Leistungserbringern eingestellt wurden.
Tabelle 2412: 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 patientdocpatient, kann eine Suche mittels FindFolders auf Dokumentenkategorie erfolgen, die in Folder.Codelist angegeben sind.
FilternA_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. [<=]
A_15087 - Identifizierung von LE-Dokumente in Ergebnismengen
Eine metadatengestützte Sortierfunktion unterstützt das Filtern von Dokumenten. Das PS SOLL eine Ergebnismenge unter Identifizierung der LE-Dokumente einschränken können. [<=]
5.2.3 Dokumente laden
Dr. Weber erkennt anhand der Metadaten aus seiner Dokumentensuche, dass in der Akte von Frau Gundlach ein Arztbrief im eArztbrief-Format enthalten ist. Das PVS zeigt Dr. Weber an, dass dieses Dokumentenformat strukturiert in die lokale Patientenakte übernommen und dort verarbeitet werden kann. Dr. Weber wählt dieses Dokument aus den Suchergebnissen aus, lässt es sich anzeigen und speichert es in seine lokale Patientenakte.
Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer anzeigen aus [gemSysL_ePA#3.7.9, UC 4.9 - Dokumente durch einen Leistungserbringer anzeigen] wird Retrieve Document Set [ITI-43] profiliert.
A_15651 - Funktionsmerkmal Dokumente laden
Das PS MUSS es dem Leistungserbringer ermöglichen, ePA-Dokumente aus der Akte in das PS laden zu können. Dafür MUSS das PS die Konnektorschnittstellenoperation RetrieveDocumentSet verwenden. [<=]
Tabelle 25: Tab_ILF_ePA_IHE-Profilierung_ITI43
|
|
|
|
|
|
|
|
|
Das Fachmodul stellt kein Integrated Document Source/Repository und keine On-Demand Document Source dar.
Das Anzeigen von Dokumenten beinhaltet auch das Anzeigen der Metadaten des Dokumentes.
Das Anzeigen ist nicht zwingend mit dem persistenten Abspeichern des Dokumentes verbunden.
Falls das anzuzeigende Dokument nicht schon mit seiner Dokumenten-ID bekannt ist, und eine Liste vorliegt, soll das PS die Auswahl des anzuzeigenden Dokumentes unter Auswertung von Metadaten ermöglichen.
Es lassen sich nur solche Dokumente laden, für welche die LEI über eine Berechtigung verfügt.
5.2.3.1 Schnittstelle
Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRepository)die Operation RetrieveDocumentSet an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-43] folgt und die Rolle eines IHE ITI DocumentRepository gegenüber dem PS übernimmt.
Tabelle 26: Tab_ILF_ePA_Operation_Dokumente_anzeigen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.3.23.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 anzeigenladen sind:
Vorbedingung:
• Ermittelter RecordIdentifier
ExpirationDate der Aktenzugriffsberechtigung noch nicht abgelaufenVorbedingungen:
- Auswahl KVNR
- gültige Befugnis
- XDSDocumentEntry_uniqueId (DocumentEntry.uniqueId) bekannt
Auslöser:
- Fachliches Erfordernis
- Nutzerinteraktion
Aktivitäten:
• Auswahl RecordIdentifier, ggf. anhand von Dokument-Metadaten
- Auswahl XDSDocumentEntry_uniqueId
- Generierung und Versand der Nachricht
- Dekodierung des empfangenen Dokumentes (Base64 oder XOP)
- Anzeige des angefragten Dokumentes oder der Dokumentenmenge
- Auswertung des Ergebnisses
Resultat:
- Das angefragte Dokument oder die Dokumentenmenge liegt vor und kann in das PS übernommen werden
Beispiel #: Bsp_ILF_ePA_RetrieveDocumentSetRequest3.11.3.2 Nutzung
Für den Beispiel-Die RetrieveDocumentSet Request 6 ist ein passender Anhang mit zu versenden. Message muss mindestens eine DocumentUniqueID enthalten.
Beispiel #: Bsp_ILF_ePA_RetrieveDocumentSetResponse
5.2.3.3 Nutzung
Die Retrieve Document Set Request Message muss mindestens eine DocumentUniqueID enthaltenDas 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.
A_16519 - Größenbeschränkung beim Laden von Dokumentensätzen
Das Dokumente Laden unterliegt der Beschränkung der Gesamtgröße einer Dokumentenmenge, die mit einem einzelnen Aufruf geladen werden können. Das PS MUSS beachten, dass die in den Dokument-Metadaten size aufgeführte Größe der Dokumente, die in der Response der Nachricht zu erwarten sind, in Summe 250 MB nicht überschreiten darf, um eine Fehlermeldung des Fachmodules oder des Aktensystems zuverlässig zu vermeiden. [<=]
Dokumente werden in das ePA-Aktensystem Ende-zu-Ende verschlüsselt eingestellt. Dadurch können die Dokumente nicht an zentraler Stelle auf mögliche Schadsoftware geprüft werden. Eine Absicherung gegen mögliche Schadsoftware in heruntergeladenen Dokumenten muss im PrimärsystemIm 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
derden Metadatenüberein stimmenübereinstimmen; - das Format oder der Inhalt des heruntergeladenen Dokumentes nicht den zulässigen Dokumententypen im Metadatum mimeType gemäß [gemSpec_
DM_ePA#TabelleAktensystem_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.
Ein Client darf das Dokument nur dann als Datei behandeln, wenn es mit scheme = file ausgezeichnet ist, z.B. file:///c:/path/to/file.txt.
A_23621 - Information des Versicherten bei fehlerhaften medizinischen DokumentenA_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 nach Möglichkeit in der Lage sein, aus ePA-Dokumenten, deren Inhalte strukturiert vorliegen, die strukturierten Inhalte in die Primärdokumentation des Versicherten zu übernehmen. [<=]
5.2.4 Dokumente löschen
Dr. Weber stellt fest, dass Frau Gundlach keine Medikamente mehr benötigt, setzt diese ab und löscht in Absprache mit ihr den elektronischen Medikationsplan aus ihrer Akte. Frau Gundlach hat kein Interesse daran, überholte Versionen des eMP in der ePA zu archivieren.
Zur Umsetzung des Anwendungsfalles Dokumente durch einen Leistungserbringer löschen aus [gemSysL_ePA#3.7.7, UC 4.7 - Dokumente durch einen Leistungserbringer löschen] wird Remove Metadata [ITI-62] profiliert.
A_14247-04 - Funktionsmerkmal Dokumente LöschenA_21503-01 - Daten digitaler Gesundheitsanwendungen auslesen
Das PSPrimärsystem MUSS es dem LE ermöglichen, dem Wunsch des Versicherten nach Löschung von Dokumenten entsprechen zu können. Dafür MUSS das PS die Konnektorschnittstellenoperation RemoveMetadata verwenden. Technische Dokumente der ePA (Policy-Dateien) können nicht vom LE gelöscht werden. 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. [<=]
Das Löschen eines Dokumentes aus einer ePA wird als ein strukturierter Anwendungsfall realisiert, dem unmittelbar ein Suchen des Dokumentes vorhergeht, so dass vom Fachmodul eine Aktensession eröffnet wurde, die vom Löschen nachgenutzt wird.
Tabelle 27: Tab_ILF_ePA_IHE-Profilierung_ITI86
|
|
|
|
|
|
Ein LE kann alle Dokumente in Rücksprache mit dem Versicherten löschen, für die er Zugriffsrechte gemäß Tab_ILF_ePA_Zugriffsberechtigungen erhalten hat.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 Aktenanbieter löscht mit den Dokumenten auch die Metadaten des Dokumentes.
Für das nach der Löschung des Dokumentes in der ePA gegebenenfalls in der Primärdokumentation des Leistungserbringers verbleibende Dokument sind die in Kap. 7.1 aufgeführten Empfehlungen zur Archivierung zu beachten.
Das Löschen von Ordnern ist nur in einem eingeschränkten Umfang möglich. Das Aktensystem akzeptiert den Lösch-Request nur dann, wenn er auf einen dynamischen Folder abzielt, und wenn dieser Request nicht die im Folder enthaltenen Dokumente, SubmissionSets und Assoziationen enthält. Diese werden vielmehr vom Aktensystem selbst zusammen mit dem Folder Object gelöscht. Falls im dynamischen Ordner der gelöscht werden soll, Dokumente bzw. MIOs vorliegen, muss daher zuvor eine Absprache mit dem Versicherten stattgefunden haben, da eine Löschung von Dokumenten immer in Absprache mit dem Versicherten stattfinden soll.
5.2.4.1 Schnittstelle
Das Fachmodul ePA bietet zur logischen Schnittstelle I_PHR_Management am Webservice PHR_Service (analog IHE-Dienst DocumentRegistry)die Operation RemoveMetadata an, die in ihrem Außenverhalten der Schnittstellendefinition des [ITI-62] folgt und die Rolle einer IHE DocumentAdministrator gegenüber dem PS übernimmt.
Tabelle 28: Tab_ILF_ePA_Operation_Dokumente_löschen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.4.2Leistungserbringer 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:
• Ermittelter RecordIdentifier
ExpirationDateder Aktenzugriffsberechtigung noch nicht abgelaufenAuswahl 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.
53.211.4.32 Nutzung
Der RMD-Request MUSS enthalten:
• Einen Content-Type HTTP header mit action Parameterwert "urn:ihe:iti:2010:DeleteDocumentSet"
• Ein SOAP element <wsa:Action/> mit dem Wert "urn:ihe:iti:2010:DeleteDocumentSet"
• Ein SOAP element <soap12:Body/> mit dem Wert "<lcm:RemoveObjectsRequest>", der wiederum das Element <rim:ObjectRefList> enthält.
• <rim:ObjectRefList> MUSS für jedes zu löschende Objekt das Element <rim:ObjectRef> enthalten, in dessen Attribut "id" die DocumentEntry.entryUUID des zu löschende Objekt anzugeben ist
5.2.5 Artefakte
5.2.5Das 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 2913: 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 |
|
wsp |
|
wsa |
|
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 |
53.211.56.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.
53.211.67 Testunterstützung
Zur Unterstützung von Tests im Zusammenhang mit den oben geschilderten Funktionsmerkmalen dürfen keine Echtdaten verwendet werden.
5.3 Protokolle und Benachrichtigungen
5.3.1 Benachrichtigungen erhalten
Frau Gundlach hat Herrn Dr. Weber angekündigt, sie werde ihm in Kürze eine Zugriffsberechtigung von ihrem ePA-Frontend des Versicherten aus erteilen (ihre eGK führte sie für die Ad-hoc-Berechtigung nicht mit sich). Am folgenden Tag findet sie am Frontend des Versicherten ihren Hausarzt Dr. Weber über den Verzeichnisdienst und erteilt ihm eine Berechtigung für einen 7-Tage-Zugriff (Default-Zeitraum) auf ihre ePA. Ein Mitarbeiter von Dr. Weber öffnet die Primärakte von Frau Gundlach und erhält dabei die Benachrichtigung, dass Dr. Weber eine Zugriffsberechtigung erhalten hat und dass der Facharzt, zu dem er Frau Gundlach überwiesen hatte, einen eArztbrief in die Patientenakte eingestellt hat.
Zur Umsetzung des UseCases "Benachrichtigungen durch einen LE verwalten" aus [gemSysL_ePA#3.8.1] gibt es keine dedizierte Konnektorschnittstelle, auch nicht zur dedizierten Abfrage der Zugriffsrechte, über die ein LE verfügt. Stattdessen setzt sich das Funktionsmerkmal aus einer Reihe von Informationsquellen zusammen, die gesamthaft eine zuverlässige Informationsgrundlage bieten können, die jedoch keine Vollständigkeit beanspruchen kann.
Die Benachrichtigungsverwaltung kann aus dem Vergleich der Werte des Zugriffsberechtigungsstatus und der Info-Quellen einen Vergleich über Änderungen ziehen und über diese Änderungen den LE geeignet informieren.
Benachrichtigungen über Änderungen an der ePA von Versicherten können aus folgenden Quellen stammen: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 3014: Tab_ILF_ePA_BenachrichtigungsquellenKDL-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 |
|||||||
|
|
|
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) |
|||||||
|
|
FUNK |
DG060111 |
|
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 |
|||||||
|
|
AUFN |
AU010101 |
|
Anamnesebogen |
|||||||
|
|
|
- |
- |
Therapiedokumentation |
|||||||
|
|
PATH |
PT080101 |
|
Histologieanforderung |
|||||||
|
ADM |
PATD |
- |
- |
|
|
||||||
|
|
GEBU |
SD070104 |
|
Neugeborenenscreening |
|||||||
Die Dokumentation durchgeführter Ad-hoc-Berechtigungen ergibt kein vollständiges Bild der erteilten Zugriffsberechtigungen, da Zugriffsberechtigungen für die LEI auch vom ePA-Frontend des Versicherten heraus erteilt werden können.
A_14351-01 - Benachrichtigung über ePA-Änderungen bei Auswahl des Versicherten
Falls die Benachrichtigungsfunktion aktiviert ist, MUSS das PS Leistungserbringer (sowie ihre Gehilfen) bei Auswahl einer Ansicht mit Versichertenbezug in Bezug auf diesen Versicherten in folgenden Konstellationen (ein- und abschaltbar, mit Einstellbarkeit der Frequenz der Benachrichtigung) informieren können:
1. bei bestehender Zugriffsberechtigung auf die Akte informieren über:
1. neu eingestellte Dokumente (oder aufgrund einer Umklassifizierung neu zugänglich gemachte Dokumente);
2. gelöschte Dokumente;
2. bei veränderten Zugriffsrechten informieren über:
1. das Endedatum einer Zugriffsberechtigung (sofern bekannt);
2. eine neue Berechtigung, die bisher nicht bestand.
Tabelle 31: Tab_ILF_ePA_Benachrichtigungs_InfoModell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
Handlungsanweisungen auf Basis der Informationen von Tab_ILF_ePA_Benachrichtigungs_InfoModell:
• Bei Nutzung der Benachrichtigungsfunktion werden ePA-Daten des Versicherten aktualisiert. Diese Aktualisierung SOLL ausschließlich aus der geöffneten Primärakte eines einzelnen Versicherten heraus erfolgen und nicht als Sammelverarbeitung über mehrere Akten gleichzeitig.
• An der Primärdokumentation eines Versicherten lokal gespeicherte Informationen zum Zugriffberechtigungsstatus MUSS das PS durch die Benachrichtigungsinformationen aktualisieren.
• Nach Ablauf der Zugriffsberechtigung MUSS die nicht mehr vorliegende Zugriffsberechtigung dem Anwender kenntlich gemacht werden, etwa anhand des ExpirationDate.
• Falls die Benachrichtigungsverwaltung im PS Performance-Probleme verursacht, MUSS die Frequenz der Abfrage der Benachrichtigungsquellen verringert werden oder es müssen Abfragen temporär ganz ausgeschaltet werden.
Das Erhalten von Berechtigung ist die Nachbedingung der Anwendungsfälle "Berechtigung durch einen Versicherten vergeben" aus [gemSysL_ePA#3.6.1] und "Bestehende Berechtigungen durch einen Versicherten verwalten" [gemSysL_ePA#3.6.6].
5.3.1.1 Info-Quelle ePA-Administration
Im Rahmen der Ad-hoc-Berechtigung wird der RecordIdentifier bekannt, für den eine Zugriffsberechtigung erteilt wird, und das ExpirationDate der Zugriffsberechtigung (Quelle_Ad-hoc). Als alleinige Quelle dieser Informationen ist die Ad-hoc-Berechtigung u.a. deswegen nicht geeignet, weil der Versicherte vom ePA- Frontend des Versicherten ebenfalls Zugriffsberechtigungen erteilen kann.
A_15656 - Nutzung Ad-hoc-Berechtigung Erteilen für die Benachrichtigungsverwaltung
Das PS MUSS das Funktionsmerkmal Aktenkonto Aktivieren nutzen, um für die im Erfolgsfalle zu einem RecordIdentifier das ExpirationDate für die Benachrichtigungsfunktion zu erhalten. [<=]
5.3.1.2 Info-Quelle Berechtigungs-Abfrage
[Das Kapitel wurde ersetzt bzw. verschoben in Kapitel 5.1.4]
5.3.1.3 Info-Quelle Dokumentensuche
Die Dokumentensuche mit GetAll (Quelle_getAll) liefert die umfangreichsten Informationen für die Benachrichtigungsverwaltung, sollte aber aus Performancegründen nicht zu oft für Änderungsabfragen verwendet werden.
Das PS erhält nur Kenntnis von solchen Dokumenten, für die es berechtigt ist. Bei einer Änderung des Berechtigungstyps aus Tab_ILF_ePA_Zugriffsberechtigungen kann sich auch die Ergebnismenge des Querys ändern.
A_14708 - Nutzung StoredQuery [ITI-18] für die Benachrichtigungsverwaltung
Das PS MUSS dem Leistungserbringer die Möglichkeit geben, zur Verwaltung von Benachrichtigungen gemäß dem in Kapitel 5.3.2 profilierten [ITI-18] die StoredQueries GetALL oder GetDocuments zu verwenden, um regelmäßige Änderungsabfragen zu initiieren.[<=]
A_15654 - Keine regelmäßige Änderungsabfrage über sämtliche Versicherten eines LE
Das PS MUSS seine regelmäßigen Änderungsabfragen beschränken auf Akten zu Primärdokumentationen, in denen Leistungserbringer aktiv arbeiten. Eine regelmäßige Änderungsabfrage mittels StoredQuery über sämtliche Versicherte einer LE-Umgebung DARF NICHT erfolgen. [<=]
5.3.1.4 Info-Quelle Systeminformationsdienst
Wenn das Fachmodul ePA den Leistungserbringer gegenüber der Akte eines Versicherten erfolgreich autorisiert, erzeugt das Fachmodul ePA unter Verwendung des Systeminformationsdienstes des Konnektors ein Event mit dem in [gemSpec_FM_ePA#6.5.4] aufgeführten Inhalt ("Zugriffspolicy-Event"). Das Zugriffspolicy-Event gibt Auskunft über den RecordIdentifier, für den eine Zugriffsberechtigung erteilt wird, sowie über das ExpirationDate(Quelle_Event).
Das Zugriffspolicy-Event liefert zum aktuellen Zeitpunkt korrekte Informationen und informiert somit über Aktualisierungen über Zugriffsberechtigungen, auch solche, die der Versicherte am ePA-Frontend des Versicherten vorgenommen hat.
Das Zugriffspolicy-Event wird implizit bei jedem Aktenzugriff am Fachmodul ePA geworfen, der einen Zugriff auf den Berechtigungsschlüssel des LE erfordert und dabei mit einem Abruf des Schlüssels vom Aktensystem verbunden ist.
A_15655 - Nutzung Systeminformationsdienst für die Benachrichtigungsverwaltung
Das PS MUSS den Systeminformationsdienst des Konnektors nutzen, um zum Topic FM_EPA/POLICY_LEI und der TelematikID der Leistungserbringerinstitution das Ablaufdatum der Zugriffsberechtigung für einen RecordIdentifier im Element validTo für die Benachrichtigungsfunktion zu erhalten. [<=]
5.3.1.5 Info-Quelle Fehlermeldung
A_15657 - Nutzung von Fehlermeldungen für die Benachrichtigungsverwaltung
Bei Auftreten der in Tab_ILF_ePA_Infoquelle_Fehlermeldung aufgelisteten Fehlercodes MUSS das PS die geschilderten Handlungsweisen umsetzen.
Tabelle 32: Tab_ILF_ePA_Infoquelle_Fehlermeldung
|
|
|
|
|
|
|
|
|
|
|
[<=]
5.3.1.6 Umsetzung
Die auch kombinierbaren Aktivitäten des Anwendungsfalles Benachrichtigungen erhalten sind:
Vorbedingung:
• Der Versicherte ist der Primärdokumentation im PS mit seiner Versicherten-ID und seinem RecordIdentifier bekannt
Auslöser:
• Die Primärdokumentation im PS zu dieser Versicherten-ID ist geöffnet
• anlassbezogene Abfrage oder Nutzerinteraktion
Aktivitäten:
• Auswerten der Auswahloptionen der Benachrichtigungsverwaltung
• Aufruf der für die Benachrichtigungsverwaltung hinterlegten StoredQueries auf die Akte des Versicherten
• Auswertung des Ergebnisses und ggf. Aktualisieren geänderter Werte in der Primärdokumentation
Resultat:
• Die aktualisierten Benachrichtigungsinformationen liegen zur Anzeige vor
Abbildung 11: Abb_ILF_ePA_Benachrichtigungen_GetAll_mit_Zugriffspolicy-Event
5.3.1.7 Nutzung
A_14659 - Speicherung RecordIdentifier in der lokalen Primärdokumentation des PS
Das PS MUSS den RecordIdentifier an der lokalen Patientenakte (Primärdokumentation) persistent speichern, falls eine neu vergebene Berechtigung für den LE ermittelt wurde. [<=]
A_15100 - Auswahloptionen der Benachrichtigungsverwaltung
Das PS SOLL dem LE Auswahloptionen für die Benachrichtigungsverwaltung anbieten. [<=]
Der StoredQuery GetDocuments liefert aktuelle Metadaten für Dokumente, auf die ein LE zugriffsberechtigt ist. Durch Nutzung von GetALL [ITI-18#3.18.4.1.2.3.7.4] werden die Metadaten aller XDSSubmissionSets und XDSDocumentEntries eines Versicherten in einer Akte erfragt.
Suchstrategien aus der Schnittstelle Registry Stored Query können Info_Neu_Zugriff und Info_Ende_Zugriff aktualisieren helfen, beispielsweise:
• Benachrichtigungen über durch andere Akteure hinzugefügte Dokumente in einer Akte ab einem Stichtag
• Ermitteln von Änderungen durch andere Akteure an Dokumenten, die ein LE selbst eingestellt hat
Die Suche erfolgt auf den Metadaten von Dokumenten, nicht auf den Dokumenteninhalten.
5.3.2 Übertragungsprotokolle speichern
Das Primärsystem von Dr. Weber speichert die Übertragungsprotokolle zwischen dem Primärsystem und dem Konnektor, die darüber Auskunft geben, welche Aktenzugriffe er auf Frau Gundlachs ePA vollzogen hat.
Das PS benutzt "Übertragungsprotokolle", um insbesondere die vorgeschriebenen Nachweispflichten von Leistungserbringern bei der Übertragung von Dokumenten zwischen PS und Aktensystem zu erfüllen, bei denen Patientendaten betroffen sind. Das Erstellen, Speichern, Durchsuchbar machen und Anzeigen der Übertragungsprotokolle zwischen PS und Aktensystem ist eine Aufgabe des PS, nicht jedoch des Fachmoduls ePA oder anderer Komponenten der TI. Die Übertragungsprotokolle geben Auskunft über die Aktivität des PS bei der Nutzung der Akte, nicht aber über die Datenverarbeitung im Aktensystem des Versicherten.
A_16434 - Übertragungsprotokolle durchsuchbar und einsehbar speichern
Das PS MUSS Übertragungsprotokolle der Kommunikation mit dem Fachmodul ePA des Konnektors speichern, durchsuchbar und einsehbar machen. [<=]
Das Format der Speicherung und die Schnittstellen zu den Übertragungsprotokollen können herstellerspezifisch sein. Das PS kann zur Speicherung zum Speichern Record Audit Event [ITI-20] verwenden, und darauf aufbauende Filtermechanismen zur Anzeige der Übertragungsprotokolle verwenden.
Durch das Loggen der SOAP-Parameter aus Tab_ILF_ePA_ClientInformationen bei Dokumentenmanagementzugriffen werden für das Einsehen von Übertragungsprotokollen erforderliche Zugriffsinformationen bereit gestellt.
Details zur Nutzung der Übertragungsprotokolle obliegen dem PS.
5.4 Status- und Fehlermeldungen
5.4.1 Statusinformationen
A_14691 - Meldung über partielle Erfolgsmeldungen
Das PS MUSS im Falle einer partiellen Erfolgsmeldung (oder eines vorliegenden Warning-Elementes) eine Warnung bereitstellen, die es den Mitarbeitern der Leistungserbringerinstitution ermöglichen, die Ursache des (partiellen) Fehlers zu identifizieren und mögliche Gegenmaßnahmen zu ergreifen und die partiellen Fehler vom partiellen Erfolg unterscheiden helfen. [<=]
Tabelle 33: Tab_ILF_ePA_ErrorSeverity
|
|
|
|
|
|
|
|
|
|
|
|
[IHE-ITT-TF3] definiert, insbes. Table 4.2.4.2-3 und Table 4.2.4.2-4.
Bei IHE-Operationen stellt der in Im rs:RegistryResponse/@status Attribut den Verarbeitungsstatus der Anfrage dar:
Tabelle 34: Tab_ILF_ePA_IHE_Success_and_Error_Reporting
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.4.2 Fehlerbehandlung
Auftretende Fehlertypen unterscheiden sich je nach Architekturebene:
• gematik-SOAP-Faults bei Fehlern auf Transportebene mit TelematikError auf Anwendungsebene außerhalb des Dokumentenmanagements:
o Fehler bei Abbruch der Verarbeitung
o Error-Elemente als Teil der Status-Elemente bei abgeschlossener Verarbeitung
• Fehler auf Ebene des Dokumentenmanagements und der Aktenermittlung
Tabelle 35: Tab_ILF_ePA_DifferenzFehlerhandling
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A_14179 - Verständliche Fehlermeldung
Das PS MUSS im Falle von Fehlern Fehlermeldungen bereitstellen, die es den Mitarbeitern der Leistungserbringerinstitution ermöglichen, die Ursache des Fehlers zu identifizieren und mögliche Gegenmaßnahmen zu ergreifen. [<=]
Der Stacktrace der Fehler wird nicht an das PS weitergegeben.
5.4.2.1 TelematikError
Im Falle von Nicht-IHE-Fehlern erhält das PS vom Fachmodul ePA einen Fehler gemäß [gemSpec_OM#3.2.3], das ein einzelnes GERROR:Trace-Element enthält, das in der GERROR-Struktur im Element GERROR:Trace einen von der gematik spezifizierten Fehler enthält.
Es gibt keinen Fehlertrace bei SOAP-Fehlern. Die Fehlerbehandlung durch das PS MUSS auf Basis der Fehlerstruktur erfolgen. Herstellerspezifische ePA-SOAP-Fehler sind nicht zulässig. Anforderungen an das PS zum Fehlerhandling bei SOAP-Fehlern finden sich in [gemILF_PS#6].
Die vom FM geworfenen Fehler sind gelistet in Tab_ILF_ePA_Fehlermeldungen des Fachmoduls ePA.
Daneben kann es Fehler des Basiskonnektors geben gemäß [gemSpec_Kon], s. Übersicht in [gemILF_PS#6.6]
A_16205 - Fehlertexte aus dem TelematikError zur Anzeige von Fehlertexten
Das PS SOLL bei Auftreten eines TelematikErrors den Code und den ErrorText zur Anzeige der Fehlermeldungen verwenden.
[<=]
5.4.2.2 IHE-Error
In der Response der IHE-Schnittstellen-Aufrufe können [ITI-TF-3#Table 4.2.4.1-2]: Error Codes auftreten, die drei ResponseStatusType aufweisen können.
Das Vorhandensein eine Error-List ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Falls die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), kann die Verarbeitung als erfolgreich angesehen werden.
Fehler aus Aufrufen des Dokumentenmanagements haben das in [ITI TF Vol 3#4.2.4] "Success and Error Reporting" beschriebene Format. Es wird im Fehlerfall ggf. eine Fehlerliste (RegistryErrorList) und darin Fehler (RegistryError) mit den Attributen errorCode, errorContext, codeContext und severity zurückgegeben.
Für die Analyse der Fehlerquelle enthält insbesondere auch der codeContext hilfreiche Informationen, die nützlich sind, um den Nutzer über die Ursache des Fehlers hinzuweisen und daraus Handlungen abzuleiten, mit denen die Ursache des Fehlers behoben wird.
A_14920 - Fehlertexte aus der RegistryErrorList zur Anzeige von Fehlertexten
Das PS SOLL für Fehler aus der RegistryErrorList eine deutschsprachige Fehlermeldung erstellen.[<=]
A_15092 - Eigene Übersetzungen von Fehlertexten
Das PS KANN die IHE-Error-Fehlertexte mit eigenen Übersetzungen zur Anzeige bringen. Andernfalls KANN der Fehlertext für Fehler, bei denen keine Handlungsanweisung besteht, mit dem generischen Fehlertext "Der ePA-Anwendungsfall konnte nicht erfolgreich beendet werden." zur Anzeige gebracht werden. [<=]
5.4.3 Handlungsempfehlungen in Fehlerfällen
A_15632-10 - Empfehlungen zur Fehlerbehandlung
Bei Auftreten der in Tab_ILF_ePA_Handlungsanweisung_im_Fehlerfall aufgelisteten Fehlercodes SOLL das PS die geschilderten Handlungsweisen unterstützen.[<=]
Tabelle 36: Tab_ILF_ePA_Handlungsanweisung_im_Fehlerfall
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.4.4 Übersicht möglicher Fehlermeldungen
5.4.4.1 Fehlermeldungen aus dem Fachmodul ePA
Das Primärsystem können neben Fehlermeldungen des Basiskonnektors auch solche des Fachmoduls ePA erreichen. Hier eine Auswahl solcher Fehlermeldungen unter Hinweis auf Dokumente und Textstellen, in denen detaillierte Informationen zu finden sind.
Eine Liste von Fehermeldungen, das Primärsystem über das ePA-Fachmodul erreichen, findet sich im gemSpec_FM_ePA in den Tabellen
• Tab_FM_ePA_011 Übergreifende Fehlermeldungen des Fachmoduls ePA
• Tab_FM_ePA_050 Wiederverwendete Fehlermeldungen aus der Konnektorspezifikation
• Tab_FM_ePA_051 Wiederverwendete Fehlermeldungen aus der Übergreifenden Spezifikation Operations und Maintenance
Darüber hinaus werden Fehlermeldungen, die spezifisch sind für Schnittstellenaufrufe am Fachmodul bei der Beschreibung der Schnittstellensignaturen von gemSpec_FM_ePA aufgelistet
• Tab_FM_ePA_032 Fehlermeldungen der Operation GetHomeCommunityID
• Tab_FM_ePA_041 Fehlermeldungen der Operation GetAuthorizationList
• Tab_FM_ePA_057 Fehlermeldungen der Operation GetAuthorizationState
Fehlermeldungen, die in der aktuelle Fachmodul-Spezifikation abgekündigt sind, ab in älteren Konnektoren noch auftreten können, sind in Tab_ILF_ePA_abgekündigte_Fehlermeldungen_des_Fachmoduls_ePA aufgelistet.
Tabelle 37: Tab_ILF_ePA_abgekündigte_Fehlermeldungen_des_Fachmoduls_ePA
|
|
|
|
|
|
|
|
|
|
|
|
5.4.4.2 Fehlermeldungen aus dem Aktensystem ePA
Das Aktensystem kann mindestens die Fehler der Tabelle Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem werfen, die an das PS durchgereicht werden.
Tabelle 38: Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6 Informationsmodell
6.1 Metadaten
Beim Einstellen von Dokumenten in die ePA werden die dazu genutzten SubmissionSets und die Dokumente selbst, durch Metadaten angereichert die für Such- und Filterfunktionen nachgenutzt werden können. Metadaten liegen sowohl am SubmissionSet, als auch am ePA-Dokument selbst vor.
Das PS MUSS Metadaten unter Beachtung von [gemSpec_DM_ePA] möglichst automatisiert aus den Primärdaten der Versicherten übernehmen und erzeugen, ohne dass eine händische Eingabe von Metadaten zwingend erforderlich ist. Die manuelle Auszeichnung der Werte von Metadaten sollte auf ein Minimum begrenzt werden.
Als Codierung wird UTF-8 verwendet.
A_14940 - Festlegungen zu Metadaten im Datenmodells der ePA-Dokumente
Das PS MUSS die Dokumententypen aus [gemSpec_DM_ePA#A_14760] betreffenden Festlegungen zur Verwendung von Metadaten gemäß [gemSpec_DM_ePA#3.3] beachten. [<=]
A_23556 - Einheitliche Metadaten-Vorgaben für unstrukturierte Dokumente
Das PS MUSS beim Hochladen von Dokumente, für die kein ImplementationGuide vorliegt, die Metadaten gemäß Tab_ILF_ePA_Metadatenvorgaben belegen. Die Codes der eventCodeList sind im KDL Implementierungsleitfaden definiert.Tab_ILF_ePA_Metadatenvorgaben
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
A_23609 - Suche nach unstrukturierten ePA-Dokumenten
Das PS SOLL die Suche nach Dokumenten, für die kein ImplementationGuide vorliegt, die Metadaten gemäß Tab_ILF_ePA_Metadatenvorgaben verwenden. Eine Suche nach classCode und typeCode ergibt ein unspezifischeres Suchergebnis als eine gezielte Suche nach eventCodes aus dem KDL Implementierungsleitfaden. [<=]
Wenn Leistungserbringer Dokumente einstellen, bei denen sie nicht selbst der Autor sind, kann es passieren, dass die TelematikID des ursprünglichen Dokumenten-Autors nicht in DocumentEntry.author.authorInstitution angegeben wurde. Ein Herunterladen und eine Weiterverarbeitung solcher Dokumente soll möglich sein, auch wenn eine strenge Validierung des Metadatums aufgrund der fehlenden TelematikID nicht erfolgreich sein sollte.
6.2 Selbstauskunft
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 automatisiert herangezogen werden können.
[<=]
Tab_ILF_ePA_Datenfelder_Selbstauskunft
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Telematik-ID der Leistungserbringerinstitution muss in vielen Nachrichten angegeben werden. Sie sollte aus der SMC-B ausgelesen werden und im PS persistent gespeichert werden.
Die Telematik-ID ist von den Kartenherausgebern der SM-B festgelegt und immer im Attribut "registrationNumber" im Admission-Element der Extension der SMC-B-Zertifikate (C.HCI.AUT, C.HCI.ENC,C.HCI.OSIG) eingetragen. Wenn nicht explizit vom Antragsteller eine neue Telematik-ID angefordert wird, wird bei Ausgabe von Folge- und Ersatzkarten die bisherige Telematik-ID wiederverwendet. Eine generelle Vorgehensweise kann die gematik hierfür nicht geben, da die Personalisierung der SMC-B sektoral unterschiedlich ist (siehe gemSpec_PKI, Anhang A). Zum Auslesen der Zertifikate kann die Operation ReadCardCertificate gemäß [gemSpec_Kon#4.1.9.5.2] verwendet werden. Die Telematik-ID ist in allen Zertifikaten in der Admissionstruktur als "registrationNumber" im ASN.1-Format gespeichert.
6.3 Wertebereiche
Erforderliche Wertebereiche (Value Sets) für ePA-Dokumente werden je nach Festlegung von [gemSpec_Voc_ePA] angegeben.
Bei der Migration von Akten werden Dateinamen überschrieben. Beim Einstellen und Auslesen von Dokumenten sollen daher bevorzugt die Attribute title und mimetype genutzt werden. [<=]
Einstellen von Dokumenten
Auf die Auszeichnung von in die ePA einzustellenden Dokumenten durch Metadaten kann das PS spezifische Einschränkungen und Vorbelegungen umsetzen:
- abhängig vom Nutzungskontext bzw. Anwendungsfall;
- gemäß sektorspezifischen Besonderheiten;
- je nach LE-spezifischen Besonderheiten und Konfigurationen, etwa in Zusammenhang mit der Selbstauskunft der Leistungserbringer.
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 gemäß [gemSpec_DM#4.1] 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 gemäß [gemSpec_DM_ePA#5.2.3] 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.
63.4 Dokumentenformate der ePA12.2 Strukturierte Dokumente
A_14245-01 - Unterstützung der Verarbeitung von Dokumentenformaten der ePA durch das PS
Das PS KANN über die Liste der in ePA definierten strukturierten Dokumente gemäß [gemSpec_DM_ePA#A_14761] hinaus zusätzliche Dokumentenformate gemäß [gemSpec_DM_ePA#A_14760] unterstützen, um sie zu verwalten. [<=]
Falls Word- oder Openoffice-Dokumente in die ePA eingestellt werden sollen, müssen diese Dokumente vor ihrem Upload in ein PDF umgewandelt werden.
Das DPE-XML der eGK ist ein Beispiel eines XML-Dokumentes, dessen Metadaten gemäß [gemSpec_Voc_ePA] angereichert werden.
Ein ContentProfile zu einem einzelnen Dokumentenformat bzw. Inhaltstypen eines Dokumentenformates beschreibt die Befüllung der Metadaten im Sinne einer Best Practice zur Vermeidung von Interoperabilitätsproblemen.
Der DocumentEntry. formatCode von Dokumenten, bei denen es kein Contentprofile gibt, kann mit dem Wert "urn:ihe:iti:xds:2017:mimeTypeSufficient" automatisch vorbelegt werden. Eine manuelle Auswahl des formatCodes soll vermieden werden. Dasselbe gilt für typeCode und classCode.
A_21651 - Verarbeitung strukturierter Dokumente der gesetzlich vorgegebenen Kategorien
Das Primärsystem MUSS strukturierte Dokumente der Kategorien aus Tab_DM_Dokumentenkategorien in gemSpec_DM_ePA#A_19388-* nicht nur anzeigen, sondern auch verarbeiten können, d.h. anlegen und bearbeiten können. Strukturierte Dokumente sind Dokumente, für die in gemSpec_DM Strukturdefinitionen aufgeführt werden oder aber Definitionen als Medizinische Informationsobjekte vorliegen. [<=]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_14246 - Verarbeitbarkeit ausgelesener Dokumente und Formate25008 - Nutzung des childrecord in der Akte des Kindes
Das PrimärsystemPS 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. 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. [<=]
63.412.1 ContentProfile Notfalldatensatz und Datensatz Persönliche Erklärungen2.2 NFD, DPE und eMP
DerEin Notfalldatensatz, der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_NFDM#5.1.2] von der eGK gelesen oder er wird gemäß den im XML-Schema des Infomodells NFDM festgelegten Regeln und den darüber hinaus gehenden in [gemSpec_InfoNFDM] definierten Integritätsregeln erstellt, so dass der NFD gemäß [gemRL_QES_NFDM] signiert werden kann.
Ein (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#5.2.2NFDM] von der eGK gelesen oder er wird gemäß den im XML-Schema des Infomodells NFDM festgelegten Regeln und den darüber hinaus gehenden in, vgl. auch [gemSpec_InfoNFDM] definierten Integritätsregeln erstellt.
Im <lcm:SubmitObjectsRequest> des <ProvideAndRegisterDocumentSetRequest> referenziert das <rim:ExtrinsicObject> die <rim:RegistryObjectList> die ID des angehängten NFD-Objektes bzw. DPE-Objektes.
A_18690 - DPE-spezifische Metadatenbefüllung
Das PS KANN die Werte der SubmissionSet-Metadaten für den Datensatz persönliche Erklärungen gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen und dabei die DPE-spezifischen Implementierungshinweise aus Tab_ILF_ePA_Nutzungsvorgaben für Metadaten NFD/DPE beachten. Datenquellen sind Daten des Einstellers und der DPE der eGK. [<=]
A_14504-06 - NFD-spezifische Metadatenbefüllung
Das PS MUSS die Werte der SubmissionSet-Metadaten für den Notfalldatensatz gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen und dabei die NFD-spezifischen Implementierungshinweise aus Tab_ILF_ePA_Nutzungsvorgaben für Metadaten NFD/DPE beachten. Datenquellen sind Daten des Einstellers und die NFD der eGK.
Tabelle 39: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten NFD/DPE
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
[<=]
Der Notfalldatensatz wird im Base64-Format, wie er aus der eGK ausgelesen wird, in das Element <xds:Document> eingefügt, das ein Attribut @id enthält, das dem rim:ExtrinsicObject/@id übereinstimmt.
A_15058 - Anzeige (Rendering) ContentProfile NFD/DPE
Das PS MUSS ePA-Daten im ContentProfile NFD/DPE in geeigneter Form zur Anzeige bringen können. Für die Anzeige der Inhaltsdaten SOLL die Anzeigefunktion der Notfalldaten bzw. des DPE nachgenutzt werden, die beim Auslesen der NFD/DPE von der eGK gemäß [gemILF_PS_NFDM] verwendet wird, sofern die Anzeigefunktion über die Anwendung NFDM verfügbar ist. [<=]
6.4.2 ContentProfile elektronischer Medikationsplan
Der elektronische Medikationsplan, der in die ePA eingestellt werden soll, wird vom PS entweder zuvor gemäß [gemILF_PS_AMTS] von der eGK gelesen oder er wird gemäß den im XML-Schema des Infomodells eMP/AMTS festgelegten Regeln und den darüber hinaus gehenden in [gemSpec_Info_AMTS] definierten Integritätsregeln erstellt, so dass der eMP durch das PS gemäß [gemILF_PS_AMTS] zum Einstellen des eMP in die ePA vorbereitet ist. Die Einwilligung in die Nutzung des eMP wird nicht in der ePA gespeichert.
A_21103-03 - Einstellen von eMP-Daten
Das PS MUSS dafür Sorge tragen, dass für den elektronischen Medikationsplan der eGK das XML-Artefakt der eMP/AMTS-Daten gemäß [gemSpec_Info_AMTS#2.1] in einer aktuellen Fassung in die ePA hochgeladen wird, falls die genannten Artefakte dort fehlen oder nicht in einer aktuellen Version vorliegen. Ein bereits in der ePA des Versicherten vorliegender eMP MUSS mittels der Replace-Option ersetzt werden. [<=]
A_21102-03 - eMP-spezifische Metadatenbefüllung
Das PS MUSS die Werte der Metadaten für den elektronischen Medikationsplan gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen und dabei die eMP-spezifischen Implementierungshinweise aus Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMP sowie die ValueSetDefinition aus [gemSpec_Voc_ePA] beachten. Datenquellen sind Daten des Einstellers oder eMP-Daten der eGK. [<=]
Tabelle 40: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMP
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
A_15059-03 - Anzeige (Rendering) ContentProfile eMP
Das PS MUSS ePA-Daten im ContentProfile elektronischer Medikationsplan in geeigneter Form zur Anzeige bringen können. Für die Anzeige der Inhaltsdaten SOLL die Anzeigefunktion des Medikationsplans nachgenutzt werden, die beim Auslesen des eMP von der eGK gemäß [gemILF_PS_AMTS] verwendet wird, sofern die Anzeigefunktion über die Anwendung eMP/AMTS verfügbar ist.[<=]
6.4.3 ContentProfile Arztbrief nach § 291f, 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 ArztbriefeArztbrief im Format als HL7 CDA R2-Dokument vorliegt, ohne dass der ArztbriefeArztbrief eine PDF-Darstellung hat, soll er direkt im Format mimeType = application/xml in der Dokumentenverwaltungim XDS Document Service der ePA verwaltet werden.
Ein ArztbriefeArztbrief, der als reines PDF-Dokument in die ePA eingestellt werden soll, soll direkt im Format mimeType = application/pdf in der Dokumentenverwaltung den XDS Document Service der ePA verwaltet werden.
Der Arztbrief nach § 291f SGB V eArztbrief DischargeLetterContainer-Format hat gemäß [Richtlinie eArztbrief] die verpflichtenden Teile PDF-Dokument und CDA-XML (nur der CDA-Header ist verpflichtend). Um diesen ArztbriefeArztbrief 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 127: Abb_ILF_ePA_eAB-XML-Containerformat
A_14244-0102 - ePA-Einstellung Verarbeitungsvorschrift für Arztbrief nach § 291f mit XML- und PDF-AnteileAB im DischargeLetterContainer-Format
Falls der Arztbrief nach § 291feArztbrief 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 gemäß [gemSpec_DM_ePA#4.2nach [PHR_Common.xsd] einstellen und diesen in eine gemeinsamendiese gemeinsam in einem SubmissionSet in dieden XDS Document Service der ePA einstellen. In diesem SubmissionSet MÜSSEN die Metadaten konform zu den Vorgaben des ImplementationGuidesImplementation Guides des eArztbriefes ig-eab* in [gemSpec_IG_ePA] gesetzt werden. [<=]
A_14556-02 - eAB-spezifische Metadatenbefüllung
Das PS MUSS die Werte der SubmissionSet-Metadaten für den elektronischen Arztbrief gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen und dabei die eAB-spezifischen Implementierungshinweise aus Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eAB beachten. Die folgende XML-Struktur für einen Container mit eArztbrief im DischargeLetterContainer-Format wird festgelegt:
Tabelle 41: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eAB 15: XML-Struktur für Arztbrief im DischargeLetterContainer-Format
|
|
|
||||||||||
|
||||||||||||
|
Opt. |
Nutzungsvorgabe |
|
|
||||||||
|
|
|
|
|||||||||
|
|
|
||||||||||
|
R |
|
||||||||||
|
|
|
||||||||||
|
|
|
||||||||||
|
|
|
||||||||||
|
|
|
||||||||||
|
R |
|
||||||||||
CDA |
R |
|
||||||||||
|
@level |
O |
Der Wert "1", "2" oder "3" MUSS gesetzt werden, um den CDA-Level des Dokuments zu kennzeichnen. |
|||||||||
text() |
R |
|
||||||||||
[<=]
A_16246-02 - Auslesen des eArztbriefes nach § 291f SGB V
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 gemäß [gemSpec_DM_ePA#4 Anhang B] aus der ePA herauslesen und als eArztbrief nach § 291f SGB V gemäß [Richtlinie eArztbrief] weiterverarbeiten und den PDF-Anteil zur Anzeige bringen können. [<=]
6.4.4 Daten digitaler Gesundheitsanwendungen
Daten digitaler Gesundheitsanwendungen (DiGA) liegen in interoperablen Formaten vor, die den Festlegungen in [gemSpec_DM_ePA] und falls vorhanden, Vorgaben aus [KBV Portal] folgen.
Nur digitale Gesundheitsanwendungen in der Rolle von Primärsystemen (DiGA-PS) können berechtigt werden, DiGA-Daten in für jeden Versicherten eindeutige Folder einzustellen. Andere Rechte auf Daten der Kategorie 9 bzw. DiGA können ihnen nicht eingeräumt werden.
Primärsysteme der Leistungserbringer können berechtigt werden, DiGA-Daten, d.h. Daten der Kategorie 9 bzw. "diga" zu lesen. Andere Rechte auf Daten der Kategorie 9 bzw. "diga" können ihnen nicht eingeräumt werden.
Das DiGA-PS hat zwei IHE-konforme Optionen zur Bereitstellung von Daten in die ePA: Einstellen neuer Dokumente oder Replacement bestehender Dokumente.
A_23131 - DiGA-PS: Persistierung der DocumentEntry.entryUUID
Das DiGA-PS MUSS die DocumentEntry.entryUUID des von ihm in die ePA eingestellen Dokumentes persistieren, falls er die Möglichkeit nutzen möchte, für dieses Dokument Updates durchzuführen. Hierzu ist es gemäß [IHE-ITI-TF2b#3.42.4.1.3.7] erforderlich, dass ein DiGA-Client beim Einstellen des Dokumentes die DocumentEntry.entryUUID als valide UUID setzt und keine symbolische ID verwendet. Beim nachfolgenden Einstellen von Dokumenten mit der Option RPLC (replace) MUSS die persistierte DocumentEntry.entryUUID verwendet werden. [<=]
A_21503 - PS: 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 und anzeigen können. [<=]
Der Inhalt eines DiGA-Ordners wird durch Folder.title beschrieben. Dieses Feld wird vom Aktensystem belegt. Das PS kann unter den freigegebenen DiGA-Ordnern einen bestimmten Ordner über Folder.title suchen, aber auch über Folder.uniqueID. Einzelne DiGA-Dokumente, die durch ein Update fortgeschrieben werden, bleiben unter der einmal verwendeten DocumentEntry.entryUUID dauerhaft auffindbar.
6.4.5 Strukturierte Dokumente
In der ePA können strukturierte Dokumente verarbeitet werden. Strukturierte Dokumente und deren Zuordnung zu Sammlung und Sammlungstypen sind in [gemSpec_DM_ePA# ] beschrieben.
Zum Laden, Suchen und Einstellen von strukturierten Dokumenten gelten die Anwendungsfälle zum Laden, Suchen, Einstellen und Löschen von Dokumenten. Es kommen gemäß [gemSpec_DM] weitere Kriterien zur Aufbereitung einer Sammlung hinzu. Besteht der Bedarf nach mehreren Sammlungen des gleichen Typs (Beispiel Mutterpass) so wird jeweils ein dynamischer Ordner (je Schwangerschaft) angelegt. Beim erstmaligen Erstellen einer dynamischen Sammlung muss vom Primärsystem für diese Sammlung ein Ordner angelegt werden. Es wird empfohlen für den Titel des Ordners einen sprechenden Namen zu finden. Dadurch kann bei der Suche nach Sammlungen bereits durch den Titel auf deren Inhalt geschlossen werden. Da das Aktensystem dynamisch angelegte Ordner löscht, wenn diese keine Dokumente mehr enthalten, ist das Löschen der Ordner durch das Primärsystem nicht erforderlich.
Die Erteilung der Berechtigung für eine Sammlung kann im Primärsystem im Rahmen der Berechtigung für eine Dokumentenkategorie (soweit für Pass definiert) erfolgen.
Die Liste der strukturierten Dokumente wird sich im Laufe der Zeit erweitern. Die KBV liefert zu neu entwickelten MIOs Informationen über die interne Datenstruktur und fachliche Hintergründe, die gematik veröffentlicht Informationen darüber, um welchen Sammlungstyp es sich bei dem neuen strukturierten Dokument handelt, und welche Metadaten dieses strukturierte Dokument identifizieren.
Die Berechtigung zukünftiger strukturierter Dokumente wird über das Freigeben gemäß Vertraulichkeitsstufe geregelt, d.h. wenn ein neues, bisher noch nicht bekanntes strukturiertes Dokument vom Versicherten mit der Vertraulichkeitsstufe "normal" eingestellt wird, kann es über die genannte Vertraulichkeitsstufe für einen LE freigegeben werden.
A_19548 - Elektronischer Impfpass
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für den elektronischen Impfpass gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
A_19549 - Elektronischer Mutterpass
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für den elektronischen Mutterpass gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
A_19550 - Elektronisches Untersuchungsheft für Kinder
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für das elektronische Untersuchungsheft für Kinder gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
A_19551 - Elektronisches Zahnbonusheft
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für das elektronische Zahnbonusheft gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
A_19552 - Elektronische Verordnungen/Verordnungsdatensatz
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für elektronische Verordnungen/den Verordnungsdatensatz gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
A_20197-01 - Arbeitsunfähigkeitsbescheinigung
Das PS MUSS die Werte der DocumentEntry- und SubmissionSet-Metadaten für elektronische Arbeitsunfähigkeitsbescheinigungen gemäß [gemSpec_DM_ePA] für das Dokumentenmanagement der ePA automatisiert befüllen. [<=]
6.4.5.1 Signatur für strukturierte Dokumentenformate der ePAA_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 strukturierte Dokumentenformat festgelegt und außerhalb dieser Spezifikation veröffentlicht.
Im Folgenden wird das Vorgehen beschrieben, für den Fall, dass ein strukturiertes Dokumentenformat 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
, z.B. Dokument elektronische Verordnungen/Verordnungsdatensatz, Impfpassdokument. - 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.
SigniertesDas 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
signiertesdas signierte Objekt an das Primärsystem. - Das Primärsystem stellt über das Funktionsmerkmal "Dokumente einstellen"
(siehe Kap.5.2.1)das signierte Objekt als DocumentEntry im ePA-Aktensystem im PKCS#7-Format ein.
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. [<=]
Ein vom Arzt mit QES-signiertes E-Rezept darf nicht in den Besitz des Versicherten gelangen und wird ausschließlich im E-Rezept-Server gespeichert. Deshalb wird begrifflich unterschieden zwischen E-Rezept und Elektronische Verordnungen/Verordnungsdatensatz. Elektronische Verordnungen/Verordnungsdatensatz ist nicht QES signiert und kann in die Akte des Versicherten eingestellt werden.
A_19974 - Elektronische Verordnungen/Verordnungsdatensatz ohne QES
Ein Primärsystem DARF NICHT Elektronische Verordnungen/Verordnungsdatensatz mit QES in die Akte des Versicherten einstellen. [<=]
7 Ergänzende Funktionalitäten
7.14 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 |
Elektronische Arbeitsunfähigkeitsbescheinigungen |
gemäß Implementationguide eAU [gemSpec_IG_ePA] |
Eingescannte Dokumente |
classCode=DOK |
[<=]
4.1.2 Ablauf eines betreiberübergreifenden Aktenumzugs (informativ)
Abbildung 8: Ablauf eines betreiberübergreifenden Aktenumzugs
Anstoßen eines Aktentransfers
Der Kostenträger (neu) lässt im Aktensystem eine neue Akte anlegen (1). Das Aktensystem fragt am Information Service der anderen Aktensysteme ab, ob für diese KVNR schon eine Akte existiert (2). Sollte dies der Fall sein, wird der Anbieterwechsel angestossen. In dieser Kommunikation wird auch das Verschlüsselungszertifikat des neuen Betreibers ausgetauscht.
Dafür informiert der Information Service des alten Aktensystems den Kostenträger (alt) über den Wechsel (3). Der Kostenträger (alt) meldet sich an der ePA an, startet die Erstellung eines Export-Pakets im Health Record Relocation Service und übergibt dabei das Verschlüsselungszertifikat (4). Der Service ändert den Status der Akte auf SUSPENDED und baut das Export-Paket. Das Export-Paket wird mit dem Verschlüsselungszertifikat für die VAU des neuen Betreibers verschlüsselt (5).
Das verschlüsselte Export-Paket wird nun auf dem Download-Punkt des alten Aktensystems abgelegt und die entsprechende Download-URL dem Kostenträger (alt) bekannt gemacht. Dieser übermittelt die Download-URL an den Information Service seines Aktensystems, welches diese an den Information Service des neuen Aktensystems übergibt, welches die URL mit der Information, dass ein Anbieterwechsel ansteht, an den Kostenträger (neu) weiterleitet (6).
Import einer Akte
Der Kostenträger (neu) meldet sich an der ePA an und startet am Health Record Relocation Service den Import der Akte (7). Nachdem der Health Record Relocation Service das Export-Paket abgerufen (8) und entschlüsselt hat, werden die Daten in die entsprechenden Services importiert und die Akte ist beim neuen Anbieter nutzbar und deren Status wechselt auf ACTIVATED (9).
4.1.3 Erstellung des Exportpakets auf Seiten des alten Kostenträgers
Der Information Service des Aktensystems informiert das Clientsystem des Kostenträgers über den anstehenden Aktenumzug und gibt dabei die die KVNR des umzuziehenden Aktenkontos, das Verschlüsselungs-Zertifikat des Ziel-Aktensystems und eine RequestID mit. Das Format dieser Information wird nicht von der gematik vorgegeben und ist betreiberspezifisch. Die RequestID stammt vom Information Service des neuen Kostenträgers und identifiziert die Abfolge der Aufrufe und Antworten im Rahmen eines Aktenumzugs als zusammengehörig.
Getriggert durch diese Information loggt sich das Clientsystem des Kostenträges in das Aktenkonto ein und startet die Herstellung des Exportspakets unter Verwendung des erhaltenen Verschlüsselungszertifikats.
Dazu nutzt es diese Operation des Health Record Relocation Service des Aktensystems:
Tabelle 18: I_Health_Record_Relocation_Service::startPackageCreation
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Health_Record_Relocation_Service |
|
startPackageCreation |
Diese Operation startet die Anlage eines Exportpakets der Inhalte eines Aktenkontos zum Download. |
A_24683 - Anlage eines Exportspakets
Das Clientsystem des Kostenträgers MUSS die Anlage eines Exportpakets der Inhalte eines Aktenkontos zum Download starten unter Verwendung der Operation startPackageCreation gemäß [I_Health_Record_Relocation_Service]. [<=]
Die startPackageCreation-Response enthält die Download-URL des Export-Pakets. Diese Download-URL muss das Clientsystem an den Information Service des Aktensystems senden. Das Format dieser Nachricht wird nicht von der gematik vorgegeben und ist betreiberspezifisch.
4.1.4 Einspielen des Exportpakets auf Seiten des neuen Kostenträgers
Der Information Service des neuen Aktensystems informiert das Clientystem des neuen Kostenträgers, dass der Import des Exportpakets beginnen kann und gibt dabei die Download-URL mit. Das Format dieser Information wird nicht von der gematik vorgegeben und ist betreiberspezifisch.
Getriggert durch diese Information loggt sich das Clientsystem des Kostenträges in das Aktenkonto ein und startet den Import des Exportpakets.
Dazu nutzt es diese Operation des Health Record Relocation Service des Aktensystems:
Tabelle 19: I_Health_Record_Relocation_Service::startPackageImport
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Health_Record_Relocation_Service |
|
startPackageImport |
Diese Operation startet den Import des Exportpakets der Inhalte in das neue Aktensystem. |
A_24692 - Import des Exportpakets
Das Clientsystem des Kostenträgers MUSS den Import eines Exportpakets starten unter Verwendung der Operation startPackageImport gemäß [I_Health_Record_Relocation_Service]. [<=]
4.1.5 Verhalten bei Scheitern des Imports
Falls der Import des Exportpakets im neuen Aktensystem scheitert, erhält das Clientsystem des alten Kostenträgers diese Information vom Information Service des alten Aktensystems.
Das Clientsystem muss daraufhin den Health Record Relocation Service auffordern, den Status des Aktenkontos von SUSPENDED zurück auf ACTIVATED zu setzen.
Das Format dieser Aktionen wird nicht von der gematik vorgegeben und ist betreiberspezifisch.
4.2 Funktionsumfang Clientsystem der Ombudsstelle
Die vom Kostenträger eingerichtete Ombudsstelle ermöglicht es Versicherten, die über kein FdV verfügen, sonst nur über das FdV nutzbare Funktionalitäten ihres Aktenkontos zu nutzen. Das sind:
- für spezifische LEI das Erstellen einer Befugnis ausschließen und dieses wieder rückgängig machen,
- im Rahmen des Medikationsprozesses:
- Widerspruch einlegen gegen die Teilnahme am digitalen Medikationsprozess (medication) und die Rücknahme dieses Widerspruchs:
- Widerspruch einlegen gegen das Einstellen der Medikationsdaten durch den E-Rezept-Fachdienst und die Rücknahme dieses Widerspruchs,
- Protokolldaten aus dem Aktenkonto herunterladen.
Diese Funktionen werden aus dem Clientsystem der Ombudsstelle heraus getriggert, dessen Funktionsumfang sich damit wesentlich vom Funktionsumfang des Primärsystems einer Leistungserbringerinstitution unterscheidet. Die Ombudsstelle wird dabei duch die SMC-B der Ombudsstelle repräsentiert. Die Ombudsstelle ist grundsätzlich befugt, auf die Akten der Versicherten zuzugreifen, das individuelle Befugen durch Lesen der Versichertenkarte entfällt.
Im Folgenden wird der spezifische Funktionsumfang beschrieben und die Anforderungen genannt, die sich nur auf das Clientsystem der Ombudsstelle beziehen.
Zum Funktionsumfang des Clientsystems der Ombudsstelle gehört nicht die Verarbeitung von Dokumenten. Somit muss der XDS Document Service nicht umgesetzt werden.
4.2.1 Spezifische LEI für die Nutzung eines Aktenkontos sperren
Um für einen Versicherten eine bestimmte LEI für den Zugriff auf das Aktenkonto zu sperren, muss das Clientsystem der Ombudsstelle zunächst die Telematik-ID, den Displaynamen und die ProfessionID der zu sperrenden LEI ermitteln. Dazu sind die Suchmöglichkeiten des VZD-FHIR-Directory der TI zu nutzen.
Informationen zu Leistungserbringerinstitutionen sind im Verzeichnisdienst FHIR-Directory (VZD-FHIR-Directory) der TI-Plattform hinterlegt. Der Nutzer kann mit verschiedenen Kriterien nach Leistungserbringerinstitutionen im VZD-FHIR-Directory suchen und Informationen abrufen. Das Informationsmodell des Verzeichnisdienstes ist in [gemSpec_VZD_FHIR_Directory#4.1.1 Datenmodell] beschrieben.
Die Suche nach LEI erfolgt primär über den Namen oder Institutionsnamen, aber auch über zusätzliche Informationen wie Adressen, Fachgebiet oder Institutionstyp.
Für die Umsetzung der Suche siehe [gemSpec_ePA_FdV#6.3.3.6].
A_24668 - Suche nach LEI im Verzeichnisdienst durch Ombudsstelle
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, eine oder mehrere LEI im VZD-FHIR-Directory zu suchen und für die weitere Verarbeitung auszuwählen. [<=]
Für die Sperrung nutzt das Clientsystem der Ombudsstelle folgende Operation:
Tabelle 20: I_Entitlement_Management::setBlockedUserPolicyAssignment
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Entitlement_Management |
|
setBlockedUserPolicyAssignment |
Diese Operation erstellt den Befugnisausschluss für eine LEI (Telematik-ID). |
A_24657 - Sperren einer spezifischen LEI durch Ombudsstelle
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, einen Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI zu erteilen unter Verwendung der Operation setBlockedUserPolicyAssignment gemäß [I_Entitlement_Management]. [<=]
Um eine Sperrung aufzuheben, benutzt das Clientsystem der Ombudsstelle folgende Operation:
Tabelle 21: I_Entitlement_Management::deleteBlockedUserPolicyAssignment
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Entitlement_Management |
|
deleteBlockedUserPolicyAssignment |
Diese Operation hebt einen Befugnisausschluß einer LEI (Telematik-ID) auf. |
A_24666 - Löschen einer Sperrung einer spezifische LEI durch Ombudsstelle
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, einen Widerspruch gegen die Nutzung der ePA durch eine spezifische LEI zurückzunehmen unter Verwendung der Operation deleteBlockedUserPolicyAssignment gemäß [I_Entitlement_Management]. [<=]
Um alle gesperrten LEI zu ermitteln, nutzt das Clientsystem folgende Operation:
Tabelle 22: I_Entitlement_Management::getBlockedUserPolicyAssignment
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Entitlement_Management |
|
getBlockedUserPolicyAssignment |
Diese Operation ruft die aktuell vorhandenen Befugnisausschlüsse ab. |
A_24931 - Einsehbarkeit von Befugnisausschlüssen
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, alle aktuell vorhandenen Befugnisausschlüsse abzurufen unter Verwendung der Operation getBlockedUserPolicyAssignment gemäß [I_Entitlement_Management]. [<=]
4.2.2 Widersprüche zum Medikationsprozess einstellen oder widerrufen
Das Clientsystem der Ombudsstelle nutzt das Consent Decision Management des Aktensystems, um für einen Versicherten Einsprüche gegen im Rahmen des Medikationsprozesses einzustellen oder diese zu wiederufen.
Es gibt zwei verschiedene Widersprüche:
Tabelle 23: Widersprüche im Rahmen des Medikationsprozesses
Art des Widerspruchs |
Folgen des Widerspruchs |
Rücknahme des Widerspruchs |
Medication |
Das Lesen und Schreiben in Medical Services "emp" (XDS) und Medical Services "medication" (fhir) wird für alle LEI und FdV unterbunden. Daten der ePA werden nicht gelöscht. |
Kann nur zusammen mit dem Erp-submission-Widerspruch zurückgenommen werden. |
Erp-submission |
Die Daten in Medical Services "emp" (XDS) und Medical Services "medication" (fhir) werden gelöscht. Das Einstellen von Verordnungen und Dispensierdaten durch den Fachdienst wird abgelehnt. |
Rücknahme muss explizit erfolgen. Der Medication-Widerspruch bleibt erhalten. |
Es wird folgende Operation genutzt:
Tabelle 24: I_Consent_Decision_Management::updateConsentDecision
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Consent_Decision_Management |
|
updateConsentDecision |
Diese Operation setzt für den digitalen Medikationsprozess (functionid "medication") und für die Einstellung von Medikationsdaten durch den Fachdienst (functionid "erp-submission") eine Zustimmung ("permit") oder eine Ablehnung ("deny"). |
A_24659 - Entscheidung zum Medikationsprozess setzen durch Ombudsstelle
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, Widersprüche im Rahmen des Medikationsprozesses zu erteilen bzw. zurückzunehmen unter Verwendung der Operation updateConsentDecision gemäß [I_Consent_Decision_Management]. [<=]
Um den Zustand eines Widerspruchs festzustellen, benutzt das Clientsystem folgende Operation:
Tabelle 25: I_Consent_Decision_Management::getConsentDecision
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Consent_Decision_Management |
|
getConsentDecision |
Diese Operation liest den aktuellen Zustand des Widerspruchs gegen die Nutzung von widerspruchsfähigen Funktionen aus. |
A_24927 - Entscheidungen zu widerspruchsfähigen Funktionen abfragen
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, den aktuellen Zustand des Widerspruchs gegen die Nutzung von widerspruchsfähigen Funktionen abzufragen unter Verwendung der Operation getConsentDecision gemäß [I_Consent_Decision_Management]. [<=]
4.2.3 Protokolldaten dem Versicherten zur Verfügung stellen
Versicherte ohne ePA-FdV können bei ihrer zuständigen Ombudsstelle beantragen, die Protokolldaten zur Verfügung gestellt zu bekommen. Für den Abruf der Protokolldaten aus dem Aktenkonto des Versicherten nutzt das Clientsystem der Ombudsstelle die Schnittstelle Audit Event Service des Aktensystems. Bei den Audit Events handelt es sich um eine FHIR-Ressource gemäß der FHIR-Profilierung [gemSpec_EPAAuditEvent].
Die Anfrage des Client-Systems enthält eine FHIR-Suche, bei der über verschiedene Suchparameter das Suchergebnis eingeschränkt wird. Die Response enthält ein Bundle mit den Suchergebnissen der passenden Audit Events.
Es wird folgende Operation genutzt:
Tabelle 26: I_Audit_Event_Service
REST-Schnittstelle des Aktensystems (Nutzung nur bei etabliertem VAU-Kanal) |
|
I_Audit_Event |
|
GET/audit/v1/fhir/AuditEvent |
Mit dieser Operation kann die Ombudsstelle über eine FHIR-basierte Abfrage unter Nutzung der entsprechenden Suchparameter die Protokolldaten eines Aktenkontos abrufen. |
A_24660 - Abruf der Protokolldaten durch Ombudsstelle
Das Clientsystem der Ombudsstelle MUSS es dem Nutzer ermöglichen, Protokolldaten aus einem Aktenkonto herunterzuladen gemäß [I_Audit_Event]. [<=]
A_24711 - Aufbereitung der Protokolldaten für den Versicherten
Das Clientsystem der Ombudsstelle MUSS die Protokolldaten für den Versicherten lesbar aufbereiten. [<=]
4.3 Funktionsumfang Clientsystem DiGA
Das Clientsystem eines DiGA-Herstellers kann DiGA-Daten in die ePA einstellen und aktualisieren. Jede mit einer individuellen Telematik-ID ausgestatteten DiGA legt dazu einen DiGA-indivituellen dynamischen Ordner an. Die Telematik-ID im Folder-Title kann identifiziert die DiGA, deren Daten in einem MIO im Folder des Versicherten abgelegt sind.
4.3.1 Einstellen von DiGA-Daten
A_23131-01 - DiGA-CS: Persistierung der DocumentEntry.entryUUID
Das DiGA-CS MUSS die DocumentEntry.entryUUID des von ihm in die ePA eingestellen Dokumentes persistieren, falls er die Möglichkeit nutzen möchte, für dieses Dokument Updates durchzuführen. Hierzu ist es gemäß [IHE-ITI-TF-2b#3.42.4.1.3.7] erforderlich, dass ein DiGA-Client beim Einstellen des Dokumentes die DocumentEntry.entryUUID als valide UUID setzt und keine symbolische ID verwendet. Beim nachfolgenden Einstellen von Dokumenten mit der Option RPLC (replace) MUSS die persistierte DocumentEntry.entryUUID verwendet werden. [<=]
5 Ergänzende Funktionalitäten
5.1 Betriebs- und Performancedaten
Das PS versendet Messdaten zur Userexperience (UX-Messdaten) der in Tab_UX_KPI_Messung_ePA_PS aufgeführten erfolgreich abgeschlossenen Anwendungsfälle an das Aktensystem, bei dem ein Aktenzugriff erfolgte.
Tabelle 27: I_Information_Service::setUserExperienceResult
REST-Schnittstelle des Aktensystems (Nutzung ohne VAU-Kanal) |
|
I_Information_Service |
|
setUserExperienceResult |
Diese Operation versendet Messdaten von Verarbeitungszeiten. |
A_24685 - Messung von Verarbeitungszeiten
Das PS MUSS bei Durchführung der Anwendungsfälle aus Tab_UX_KPI_Messung_ePA_PS die in der Spalte "Beschreibung" beschriebene Messung von Verarbeitungszeiten durchführen und das Ergebnis in Millisekunden speichern.
Tabelle 28: Tab_UX_KPI_Messung_ePA_PS
UX-Anwendungsfälle |
Beschreibung |
UX_Login_PS |
Es wird der Zeitraum gemessen, den ein Nutzer eines Primärsystems nach der Auswahl einer ePA warten muss, bis die angeforderte Akte geöffnet ist. Dabei beginnt die Messung mit der letzten Nutzer-Interaktion (z. B. Anklicken eines Feldes "Patient A12345680") bevor die Akte geöffnet wird und endet mit der Anzeige von Inhalten der Akte (z. B. Dokumentenübersicht oder einer Fehlermeldung bei fehlender Befugnis). |
UX_Doc_Upload_PS |
Es wird der Zeitraum gemessen, den ein Nutzer eines Primärsystems nach dem Befehl zum Hochladen eines Dokumentes warten muss, bis dieses Dokument im PS angezeigt wird oder die Information über den Erfolg der Operation erfolgt. |
UX_Doc_Download_PS |
Es wird der Zeitraum gemessen, den ein Nutzer eines Primärsystems nach dem Befehl zum Herunterladen eines Dokumentes warten muss, bis dieses Dokument vollständig heruntergeladen wurde. |
[<=]
A_24686 - Übertragung von Verarbeitungszeiten
Das PS MUSS unmittelbar nach erfolgreicher Durchführung der Messung von Verarbeitungszeiten der Anwendungsfälle aus [gemILF_PS_ePA::Tab_UX_KPI_Messung_ePA_PS] das Messergebnis ohne Nutzerinteraktion im Hintergrund an das gleiche Aktensystem (unter Verwendung der Schnittstelle InformationService.setUserExperienceResult) übermitteln, bei dem der Aktenzugriff erfolgte. Im Anschluss MÜSSEN die gespeicherten Werte gelöscht werden, sofern die Übermittlung erfolgreich war. [<=]
Hinweis: "Im Hintergrund" bedeutet, dass die Übermittlung einerseits automatisch (ohne Nutzerinteraktion) geschieht und andererseits für den Nutzer auch keine "Wartezeit" entsteht.
5.2 Übertragungsprotokolle speichern
Das PS benutzt "Übertragungsprotokolle", um insbesondere die vorgeschriebenen Nachweispflichten von Leistungserbringern bei der Übertragung von Dokumenten zwischen PS und Aktensystem zu erfüllen, bei denen Patientendaten betroffen sind. Das Erstellen, Speichern, durchsuchbar Machen und Anzeigen der Übertragungsprotokolle zwischen PS und Aktensystem ist eine Aufgabe des PS, die nicht durch Komponenten der TI abgedeckt wird. Die Übertragungsprotokolle geben Auskunft über die Aktivität des PS bei der Nutzung der Akte, nicht aber über die Datenverarbeitung im Aktensystem des Versicherten.
A_16434 - Übertragungsprotokolle durchsuchbar und einsehbar speichern
Das PS MUSS Übertragungsprotokolle der Kommunikation mit dem ePA-Aktensystem speichern, durchsuchbar und einsehbar machen. [<=]
Das Format der Speicherung und die Schnittstellen zu den Übertragungsprotokollen können herstellerspezifisch sein. Das PS kann zum Speichern Record Audit Event [ITI-20] verwenden, und darauf aufbauende Filtermechanismen zur Anzeige der Übertragungsprotokolle verwenden.
Durch das Loggen der SOAP-Parameter aus Tab_ILF_ePA_ClientInformationen bei Dokumentenmanagementzugriffen werden für das Einsehen von Übertragungsprotokollen erforderliche Zugriffsinformationen bereit gestellt.
Details zur Nutzung der Übertragungsprotokolle obliegen dem PS.
5.3 Empfehlung zur Archivierung
Auf der Grundlage gesetzlicher Regelungen besteht eine Archivierungspflicht für die medizinischen Dokumente und für die Übertragungsprotokolle des Versicherten. Die Archivierung ist korrekt, verständlich, vollständig, nachvollziehbar und zeitnah durchzuführen. Je nach gesetzlicher Regelung sind damit dokumentierte Inhalte mit Aufbewahrungszeiträumen verbunden.
Zur Aufbewahrungsfrist wird auf die jeweils aktuelle Fassung der „Empfehlungen zur ärztlichen Schweigepflicht, Datenschutz und Datenverarbeitung in der Arztpraxis“ der BÄK und KBV, siehe [BÄK_KBV], und auf die einschlägigen gesetzlichen Normen
verwiesen.
Im Umfang der Archivierung sollen zusätzlich zu den aus der ePA heruntergeladenen und persistent im PS gespeicherten ePA-Dokumenten des Versicherten auch die zu diesen Dokumenten gehörigen Metadaten enthalten sein, die in [gemSpec_DM_ePA#TabelleAktensystem_ePAfuerAlle#Tabelle Nutzungsvorgaben für Metadatenattribute XDS.b] aufgelistet sind, soweit sie für den Verarbeitungskontext relevant sind.
6 Best practice UX Primärsysteme
Die Best Practices UX Primärsysteme geben einen Einblick in die Möglichkeit, die Einbindung der ePA-Prozesse in Versorgungsprozess nutzerfreundlich und möglichst aufwandsarm zu gestalten. Ein Anspruch auf Vollständigkeit bei der Abdeckung möglicher Versorgungsprozesse, in welche die ePA integriert werden sollte, besteht nicht.
6.1 Allgemeine Hinweise
6.1.1 ePA im Dokumentenmanagementkontext immer ansteuerbar
Der Nutzer des Systems soll in jedem Vorgang, in dem ein Dokument archiviert wird, dieses auch in die ePA der Patient;in hochladen können. Dazu ist die ePA in den entsprechenden Eingabemasken ansteuerbar.
6.1.2 Ladevorgänge im Hintergrund
Das Primärsystem soll bei Ladevorgängen zum Herunterladen und Hochladen eines oder mehrerer Dokumente in die ePA dem Nutzer das Weiterarbeiten im System erlauben. Dem Nutzer werden nur bei Fehlermeldungen auffällige und für den Nutzer verständliche Hinweise angezeigt. Erfolgsmeldungen können so in die Benutzeroberfläche integriert werden, dass sie keine Interaktion des Nutzers verlangen und den Nutzer nicht im weiteren Arbeitsprozess stören.
6.1.3 Pflichtdokumente und optionale Dokumente
Der Nutzer soll vom PS dabei unterstützt werden zu entscheiden, welche Dokumente hochgeladen werden müssen und welche Dokumente optional hochgeladen werden dürfen. In der Benutzerführung soll der Nutzer daher bei der Erstellung dieser Dokumentenarten dahin geführt werden, dass diese Dokumente automatisch ohne zusätzliche Klicks standardmäßig eingestellt werden.
Aufgrund gesetzlicher Vorgaben gibt es bestimmte Daten und Dokumentenkategorien, die verpflichtend von einem Leistungserbringer in die ePA des Versicherten hochgeladen werden müssen. Die Grundlage dafür findet sich je nach Leistungserbringergruppe u.a. in §§ 347 und 348 SGB V.
Mit Verabschiedung des Digital-Gesetzes sind Leistungserbringer künftig zum Hochladen folgender Dokumente verpflichtet:
- Verordnungs- und Dispensierdaten (übernimmt der E-Rezept Fachdienst)
- Medikationsplan
- Krankenhaus-Entlassbrief
- Laborbefund
- Bildbefund
- Befundberichte aus invasiven oder chirurgischen sowie aus nicht-invasiven oder konservativen Maßnahmen
- eArztbrief (Empfehlung: aus dem KIM-Workflow heraus)
Der Nutzer soll nicht die aktuelle Gesetzeslage auswendig kennen und überlegen müssen, welche Dokumente (bis auf Widerspruch durch den Versicherten) hochgeladen werden müssen und welche Dokumente optional hochgeladen werden dürfen.In der Benutzerführung soll der Nutzer daher bei der Erstellung dieser Dokumentenarten dahin geführt werden, dass diese Dokumente automatisch ohne zusätzliche Klicks standardmäßig eingestellt werden. Eine Funktionalität, um das Einstellen zu verhindern, muss ebenfalls bereitgestellt werden, da eine Patient:in der Einstellung eines Dokuments widersprechen kann. Eine entsprechende Funktionalität wird im Folgekapitel beschrieben.
Diese Auflistung wird mit den neueren Versionen dieses Implementierungsleitfadens stets aktualisiert.
6.2 Konfigurationsmöglichkeiten des Systems
6.2.1 Hochladen in die ePA als Default beim Archivieren für bestimmte Dokumententypen
In den Einstellungen des Primärsystems kann eingestellt werden, dass beim Archivieren bestimmter Dokumente diese automatisch in die dazugehörige ePA der Patient:in hochgeladen werden soll. Zu diesen Dokumenten gehören:
- Krankenhaus-Entlassbrief (PDF/A)
- Laborbefund (PDF/A)
- Bildbefund (PDF/A)
- Befundberichte aus invasiven oder chirurgischen sowie aus nicht-invasiven oder konservativen Maßnahmen (PDF/A)
Die Option zum Hochladen des ausgewählten Dokuments in die ePA ist dann in diesen Fällen voreingestellt. Der Nutzer klickt nur dann in der Eingabemaske oder bedient eine Tastenkombination, um das voreingestellte Hochladen in die ePA abzuwählen.
Für den Fall, dass das Hochladen für einen Krankenhaus-Entlassbrief, für einen Laborbefund oder einen Bildbefund abgewählt wurde, erzeugt das Primärsystem automatisch eine Hinweisnotiz in der Karteikarte der Patient:in, dass diese:r dem Hochladen des Dokuments widersprochen hat.
6.2.2 Hochladen in die ePA als Default für ausgewählte Dokumententypen in der Benutzung von KIM
In den Einstellungen des Primärsystems kann eingestellt werden, dass beim Versenden eines eArztbriefs oder einer elektronischen Arbeitsunfähigkeitsbescheinigung (eAU) über KIM das Dokument automatisch in die dazugehörige ePA der Patient:in hochgeladen werden soll.
Die Option zum Hochladen des ausgewählten Dokuments in die ePA ist dann in diesen Fällen voreingestellt. Der Nutzer klickt nur dann in der Eingabemaske oder bedient eine Tastenkombination, um das voreingestellte Hochladen in die ePA abzuwählen.
Für den Fall, dass das Hochladen im Kontext eArztbrief abgewählt wurde, erzeugt das Primärsystem automatisch eine Notiz in der Karteikarte der Patient:in, dass diese:r dem Hochladen des eArztbriefs widersprochen hat.
Für den Fall, dass das Hochladen im Kontext eAU abgewählt wurde, erzeugt das Primärsystem keine Notiz in der Karteikarte der Patient:in.
6.2.3 Hochladen in die ePA als Default nach dem Erstellen für bestimmte Dokumententypen
Die Einstellungen des Primärsystems können so konfiguriert werden, dass nach dem Erstellen bestimmter Dokumente diese automatisch in die dazugehörige ePA der Patient:in hochgeladen werden sollen. Zu diesen Dokumenten gehören:
- NFD
- eMP
Die Option zum Hochladen des ausgewählten Dokuments in die ePA ist dann in diesen Fällen voreingestellt. Der Nutzer klickt nur dann in der Eingabemaske oder bedient eine Tastenkombination, um das voreingestellte Hochladen in die ePA abzuwählen.
Für den Fall, dass das Hochladen im Kontext NFD abgewählt wurde, erzeugt das Primärsystem keine Notiz in der Karteikarte der Patient:in.
Für den Fall, dass das Hochladen im Kontext eMP abgewählt wurde, erzeugt das Primärsystem keine Notiz in der Karteikarte der Patient:in und es wird der eMP als Ausdruck in Form des BMP angeboten.
6.2.4 Default Vorbelegung beim Hochladen eines Dokuments
Um Dokumente aufwandsarm hochladen zu können, soll es möglich sein, in den Einstellungen des Primärsystems bestimmte Parameter zu setzen und die für den behandelnden Arzt und für die Einrichtung hinterlegten Stammdaten automatisch beim Hochladen eines Dokuments zu übernehmen.
6.3 Dokumentenverwaltung in der elektronischen Patientenakte
Das Primärsystem soll zum XDS Document Service in der elektronischen Patientenakte folgende funktionale Anwendungsfälle und die dazugehörigen Klickpfade umsetzen:
- ePA öffnen
- Dokumente suchen, filtern und sortieren
- Dokumente verwalten
- Herunterladen
- Metadaten ändern
- Löschen
- Dokument hochladen aus Karteikarte
- Dokument hochladen aus KIM-Workflow
- eArztbrief
- eAU
6.3.1 ePA öffnen
Um Dokumente mit der ePA der Patient:in verwalten zu können, soll die ePA für einen Nutzer sichtbar gemacht und geöffnet werden. Eine Darstellung, wie die ePA aus der Karteikarte der Patient:in angesteuert werden kann, kann Abbildung 9 entnommen werden.
Tabelle 29 Dokumente suchen, filtern und sortieren - UX Optimaler Klickpfad
Titel |
ePA_DMS_1 - ePA öffnen |
Zielstellung |
Der Nutzer öffnet die ePA der Patient:in, kann die Dokumente in der ePA sehen und Folgeschritte innerhalb der ePA unternehmen. |
Vorbedingung |
• Der Nutzer befindet sich in der Karteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
• Der Nutzer sieht die ihm sichtbaren Dokumente in der ePA der Patient:in |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur ePA an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 9 Ansteuern der elektronischen Patientenakte aus der Karteikarte, um die ePA zu öffnen (am oberen Bildrand ist der Menüpunkt zu finden)
6.3.2 Dokumente suchen, filtern und sortieren
Um Dokumente mit der ePA der Patient:in finden zu können, soll die ePA für einen Nutzer die Möglichkeit bieten auf Metadatenebene zu suchen, filtern und sortieren. Eine Darstellung, wie eine Anzeige der Dokumentenübersicht gestaltet sein kann, aus der heraus eine Suche, ein Filtern oder eine Sortierung der Dokumente vorgenommen werden kann, kann Abbildung 10 entnommen werden.
Tabelle 30 Dokumente suchen, filtern und sortieren - UX Optimaler Klickpfad
Titel |
ePA_DMS_2 - Dokumente suchen, filtern und sortieren |
Zielstellung |
Der Nutzer öffnet die ePA der Patient:in, kann die Dokumente in der ePA sehen und kann mithilfe der Metadaten nach einem oder mehreren Dokumenten suchen, filtern und sortieren. |
Vorbedingung |
• Der Nutzer befindet sich in der Karteikarte einer konkreten Patient:in des Primärsystems. |
Nachbedingung |
Die angezeigte Menge an Dokumente der ePA wird entsprechend der ausgewählten Kriterien auf die Treffermenge reduziert angezeigt. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur ePA an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 10 Anzeige der Dokumentenübersicht einer ePA, um nach Dokumenten in der ePA zu suchen, sie zu filtern und zu sortieren (am oberen Bildrand sind die Steuerungselemente zu finden)
6.3.3 Dokument verwalten
Um Dokumente aus der ePA der Patient:in herunterzuladen, dessen Metadaten bearbeiten oder es in der ePA löschen zu können, soll dem Nutzer für ein ausgewähltes Dokument ein Kontextmenü angezeigt werden. Eine Darstellung, wie die Dokumentenbearbeitung eines Dokuments aus der ePA der Patient:in angesteuert werden kann, kann Abbildung 11 entnommen werden.
Hinweis:
1. Das Löschen von Dokumenten kann zu ungewollten Lücken in der medizinischen Dokumentation der Patientenakte führen. Bevor ein Dokument in der ePA gelöscht wird, soll ein Hinweis erscheinen, dass das Dokument auch verborgen werden kann und damit nur für die Patient:in und von ihr ausgewählte Leistungserbringer einsehbar ist.
2. Beim Ändern von Metadaten ist darauf zu achten, dass das Dokument nicht erneut abgelegt wird und der Nutzer somit eine Fehlermeldung erhält, dass eine Dublette abgelegt werden soll.
Tabelle 31 Dokument bearbeiten - UX Optimaler Klickpfad
Titel |
ePA_DMS_3 – Dokument bearbeiten |
Zielstellung |
Der Nutzer öffnet die ePA der Patient:in, kann die Dokumente in der ePA sehen und auswählen, um diese · herunterzuladen · dessen Metadaten zu ändern · zu löschen. |
Vorbedingung |
|
Nachbedingung |
Der Nutzer hat das Dokument · in das Primärsystem heruntergeladen · dessen Metadaten in der ePA geändert · es in der ePA gelöscht. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur ePA an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 11 Anzeige eines Kontextmenüs für ein ausgewähltes Dokument, um dieses zu bearbeiten (am rechten Bildrand ist der Menüpunkt zu finden)
6.3.4 Dokument hochladen aus Karteikarte
Um ein Dokumente in die ePA der Patient:in aufwandsarm hochzuladen, soll die Funktion zum Hochladen aus der Karteikarte der Pateint:in angeboten werden und an jeder Stelle, an dem ein Dokument zur Patient:in archiviert wird. In der Eingabemaske zur Archivierung des Dokuments im Primärsystems soll die Option für das Hochladen eines Dokuments der oben genannten Anwendungsfälle in die ePA standardmäßig ausgewählt sein. Die Metadaten des Dokuments sollen mit den im Primärsystem hinterlegten Stammdaten für den behandelnden Arzt und für die Einrichtung vorbefüllt sein. Eine Darstellung, wie die Option zum Hochladen eines Dokuments in die ePA standardmäßig als ausgewählt angezeigt werden kann, kann Abbildung 12 entnommen werden.
Hinweise:
1. Das Hochladen mehrerer Dokumente kann in einem einzelnen SubmissionSet erfolgen.
2. Es ist erlaubt, dass Dokumente von berufsmäßigen Gehilfen in die ePA hochgeladen werden können. Da die Zugriffsbefugnis für die Leistungserbringerinstitution gilt und sich diese mittels SMC-B dem Aktensysten gegenüber kenntlich macht, kann die Aufgabe zum Hochladen von Inhalten einrichtungsintern geregelt werden.
3. Es ist vorgesehen, dass das Aktensystem und das Primärsystem Dokumente auf Dubletten prüfen. Hierzu werden Hash-Werte gebildet, die miteinander verglichen werden. Das Primärsystem soll dem Nutzer eine verständliche Fehlermeldung anzeigen, wenn das Ergebnis des Versuchs ein Dokument hochzuladen abgewiesen wird aufgrund der Tatsache, dass es bereits in der ePA vorhanden ist.
Tabelle 32 Dokument hochladen aus Karteikarte - UX Optimaler Klickpfad
Titel |
ePA_DMS_4 – Dokument hochladen aus Karteikarte |
Zielstellung |
Der Nutzer öffnet Karteikarte der Patient:in im Primärsystem, digitalisiert bzw. archiviert ein Dokument und lässt dieses im gleichen Prozessschritt in die ePA hochladen. |
Vorbedingung |
• Der Nutzer befindet sich in derKarteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
Für den Nutzer ist erkenntlich, dass das Dokument erfolgreich in die ePA hochgeladen wurde. |
Klickpfad |
1. Die Ärzt:in oder MFA fügt ein Dokument in die Patientenakte der Patient:in innerhalb des Primärsystem zu. |
Alternative |
Die Nutzerführung zum Hochladen eines Dokuments in die ePA einer Patient:in kann zusätzlich auch aus einem anderen Kontextmenü heraus gestartet werden (bspw. aus der Dokumentenübersicht einer geöffneten ePA). |
Abbildung 12 Eingabemaske mit der vorausgefüllten Einstellung, dass ein Dokument (am unteren Bildrand ist der Menüpunkt zu finden)
6.3.5 Dokument hochladen aus KIM-Workflow
Um ein Dokumente in die ePA der Patient:in aufwandsarm hochzuladen, soll die Funktion zum Hochladen für bestimmte Dokumente aus dem KIM-Workflow angeboten werden. In der Eingabemaske zum Versand eines eArztbriefs und einer eAU mithilfe von KIM soll die Option für das Hochladen des Dokuments in die ePA standardmäßig ausgewählt sein. Die Metadaten des Dokuments sollen mit den im Primärsystem hinterlegten Stammdaten für den behandelnden Arzt und für die Einrichtung vorbefüllt sein. Eine Darstellung, wie die Option zum Hochladen eines Dokuments in die ePA im KIM-Workflow standardmäßig als ausgewählt angezeigt werden kann, kann Abbildung 13 entnommen werden.
Hinweis: Es ist darauf zu achten, dass für der eArztbrief als XML in die ePA hochgeladen wird, während er per KIM unter Umständen als PDF verschickt wird.
Tabelle 33 Dokument hochladen aus KIM-Workflow - UX Optimaler Klickpfad
Titel |
ePA_DMS_5 - Dokument hochladen aus KIM-Workflow |
Zielstellung |
Der Nutzer verschickt einen eArztbrief oder eine eAU per KIM und gleichzeitig in die ePA der Patient:in, insofern dem nicht widersprochen wurde. |
Vorbedingung |
• Der Nutzer hat einen eArztbrief oder eine eAU erstellt. |
Nachbedingung |
• Für den Nutzer ist erkenntlich, dass das Dokument erfolgreich in die ePA hochgeladen wurde. |
Klickpfad |
1. Die Ärzt:in oder MFA erstellt einen eArtzbrief oder eine eAU. |
Alternative |
Die Nutzerführung zum Hochladen eines Dokuments in die ePA einer Patient:in kann zusätzlich auch aus einem anderen Kontextmenü heraus gestartet werden. |
Abbildung 13 Standardmäßige Auswahl der Option zum Hochladen eines Dokuments im Falle des Versands eines eArztbriefs oder einer eAU im Rahmen des KIM-Workflows (am unteren Bildrand ist der Menüpunkt zu finden)
6.4 Digital gestützter Medikationsprozess in der elektronischen Patientenakte
Das Primärsystem soll für den digital gestützten Medikationsprozess in der elektronischen Patientenakte folgende funktionale Anwendungsfälle und die dazugehörigen Klickpfade umsetzen:
1. Medikationsliste öffnen
2. Medikationsliste als Übersicht anzeigen
3. Medikationslisteneintrag im Detail anzeigen
4. Medikationsliste herunterladen
Hinweis:
Der digital gestützte Medikationsprozess (dgMP) umfasst perspektivisch in Summe:
• eine elektronische Medikationsliste (eML), welche die Verordnungsdaten und Dispensierinformationen eines zeitlich abgeschlossenen Zeitraums standardmäßig anzeigt und langfristig im Aktenkonto speichert,
• relevante Zusatzinformationen zur Arzneimitteltherapiesicherheit (AMTS), wie bspw. Körpergröße, Gewicht, Kreatininwert, Allergien und Unverträglichkeiten,
• sowie den elektronischen Medikationsplan (eMP), der für anspruchsberechtigte Versicherte, die über einen Zeitraum von mindestens 4 Wochen mindestens 3 verordnete, systemisch wirkende Arzneimittel anwenden, anzulegen ist (siehe auch § 31a SGB V, § 29 Bundesmantelvertrag Ärzte und Rahmenvertrag über ein Entlassmanagement beim Übergang in die Versorgung nach Krankenhausaufenthalt nach § 39 Absatz 1a SGB V).
6.4.1 Medikationsliste öffnen
Um die elektronische Medikationsliste der ePA zu nutzen, soll diese Funktion für einen Nutzer im Primärsystem ansteuerbar sein. Eine Darstellung, wie die elektronische Medikationsliste aus der Karteikarte der Patient:in angesteuert werden kann, kann Abbildung 14 entnommen werden.
Tabelle 34 Medikationsliste öffnen - UX Optimaler Klickpfad
Titel |
ePA_dgMP_1 – Medikationsliste öffnen |
Zielstellung |
Der Nutzer öffnet die eML der Patient:in, kann erkennen, ob die Patient:in dem dgMP widersprochen hat und bei Teilnahme am dgMP die Liste zur Anzeige bringen. |
Vorbedingung |
• Der Nutzer befindet sich in der Karteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
• Der Nutzer sieht, falls die Patient:in dem dgMP widersprochen hat, trotzdem eine ePA vorhanden ist. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur eML an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 14 Ansteuern der elektronischen Medikationsliste aus der Karteikarte der Patient:in (am rechten Bildrand ist der Menüpunkt zu finden)
6.4.2 Medikationsliste als Übersicht anzeigen
Damit die Leistungserbringerinstitution mit der eML arbeiten kann, muss sie angezeigt werden können. Einerseits kann die eML als PDF oder xHTML aus dem Aktensystem abgerufen werden. Andererseits können alle FHIR Daten aus dem Medication Service abgerufen und lokal vom Primärsystem zusammengestellt werden. Eine Darstellung, wie die elektronische Medikationsliste im Primärsystem aussehen kann, kann Abbildung 15 entnommen werden.
Hinweise:
Für die Erzeugung eines PDF/A-Exports, siehe auch A_24869.
Für die Erzeugung eines xHTML-Exports, siehe auch A_24868.
Tabelle 35 Medikationsliste als Übersicht anzeigen - UX Optimaler Klickpfad
Titel |
ePA_dgMP_2 – Medikationsliste als Übersicht anzeigen |
Zielstellung |
Der Nutzer öffnet die eML der Patient:in und erhält die eML in der Übersicht. |
Vorbedingung |
• Der Nutzer befindet sich in der Karteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
• Der Nutzer sieht die eML in einer Übersicht als PDF oder in einer xHTML Ansicht. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur eML an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 15 Anzeige der elektronischen Medikationsliste im Primärsystem
6.4.3 Medikationslisteneintrag im Detail anzeigen
Wenn eine Leistungserbringerinstitution mit der eML arbeitet, kann es sein, dass sie auf Detailinformationen zu bestimmten Verordnungen und Dispensierungen zugreifen möchte (bspw. welche Praxis die Verordnung für das Medikament ausgestellt hat). Eine Darstellung, wie eine Detailansicht zu einem Medikationslisteneintrag aussehen kann, kann Abbildung 16 entnommen werden.
Hinweise:
Diese Detailanzeige ist nicht umsetzbar, wenn das PDF oder xHTML abgerufen und gerendert wird. Hierfür braucht es den Export der FHIR Daten und eine lokale Zusammenstellung der abgerufenen Daten.
Tabelle 36 Medikationslisteneintrag im Detail anzeigen - UX Optimaler Klickpfad
Titel |
ePA_dgMP_3 – Medikationslisteneintrag im Detail anzeigen |
Zielstellung |
Der Nutzer öffnet die eML der Patient:in, möchte weitere Informationen zu einem Zeilentrag in der eML und erhält die entsprechende Anzeige. |
Vorbedingung |
• Der Nutzer befindet sich in derKarteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
• Der Nutzer sieht die Informationen zum Zeileneintrag der eML. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur eML an oder bedient eine Tastenkombination. |
Alternative |
N/A |
Abbildung 16 Detailanzeige eines Zeileneintrags der eML auf Basis der abgerufenen FHIR Daten aus dem Medication Service der ePA (am unteren Bildrand ist der Menüpunkt zu finden)
6.4.4 Medikationsliste herunterladen
Wenn ein Leistungserbringer unter Kenntnisnahme der eML als PDF oder xHTML eine Entscheidung getroffen hat, dann soll die eML in der Karteikarte der Patient:in gespeichert werden. Eine Darstellung, wie die elektronische Medikationsliste aus der Übersichtsanzeige heraus gespeichert werden kann, kann Abbildung 17 entnommen werden.
Hinweis:
Damit Nutzer des Primärsystems mehr Möglichkeiten haben mit den Daten der eML zu arbeiten, empfehlen wir den Abruf der einzelnen FHIR Daten anstelle der reinen Anzeige des PDF oder der xHTML.
Tabelle 37: Medikationsliste herunterladen - UX Optimaler Klickpfad
Titel |
ePA_dgMP_4 – Medikationsliste öffnen |
Zielstellung |
Der Nutzer öffnet die eML der Patient:in und kann die Anzeige der eML in der Übersicht als PDF oder xHTML mit einem Klick herunterladen und in der lokalen Dokumentation speichern. |
Vorbedingung |
• Der Nutzer befindet sich in der Karteikarte einer konkreten Patient:in innerhalb des Primärsystems. |
Nachbedingung |
• Für den Nutzer ist erkenntlich, dass das Dokument erfolgreich heruntergeladen und in die lokale Dokumentation übernommen wurde. |
Klickpfad |
1. Die Ärzt:in oder MFA klickt den Menüpunkt zur eML an oder bedient eine Tastenkombination. |
Alternative |
Die eML wird erzeugt, indem die FHIR Daten vom Medication Service direkt abgerufen und gespeichert werden. |
Abbildung 17: Anzeige der elektronischen Medikationsliste im Primärsystem (am oberen Bildrand rechts ist der Menüpunkt zu finden)
6.5 Nachbereitung
6.5.1 Benachrichtigung der Patient:in über Hochladen eines Dokuments
Es gibt Fallkonstellationen, in denen die Patient:in nicht in der Leistungserbringerinstitution anwesend ist, wenn ein Dokument in die ePA hochgeladen wird (z.B. am Folgetag eingegangener Laborbefund). Das Primärsystem soll es dem Nutzer ermöglichen, nach dem erfolgreichen Hochladen eines Dokuments in die ePA eine Benachrichtigung (bspw. per SMS oder E-Mail) an den Patienten zu versenden.
Das Primärsystem darf in der Nachricht nicht medizinische oder personenbezogene Informationen einfügen.
6.6 Fehlermanagement
6.6.1 Verständliche Fehlermeldungen
Im Arbeitsablauf des Nutzers können Fehler in der Dokumentenverwaltung in der ePA auftreten. Da vom Nutzer kein technisches Vorwissen erwartet werden darf, sind Fehlermeldungen so anzugeben, dass dieser nach Möglichkeit darauf reagieren kann. Hierbei sollen Fehlermeldungen so aufbereitet werden, dass der Nutzer versteht, welches System im Prozess den Fehler verursacht hat. Außerdem sollen bei technischen Fehlern diese sprachlich aufbereitet werden, so dass der Nutzer den Inhalt des Fehlers verstehen kann.
Das Primärsystem soll beim Auftreten eines Fehlers dem Nutzer eine verständliche Fehlermeldung ausgeben und nicht die von der Quelle erzeugte technische Fehlermeldung darstellen.
Das Primärsystem soll beim Auftreten eines Fehlers, falls möglich, dem Nutzer Handlungsempfehlungen ausgeben, die dazu beitragen können, den Fehler zu beseitigen.
Die Bereitstellung der Fehlerdetails per Email o.Ä. steht mit diesen Anforderungen nicht im Widerspruch. Es soll weiterhin möglich sein, technische Details an den technischen Support zu übermitteln.
7 Fehlerbehandlung
7.1 Fehlermeldungen der REST-Schnittstellen
Für jede REST-Schnittstelle sind in der OpenAPI die möglichen Fehlersituationen beschrieben. In dieser Tabelle sind alle Fehlermeldungen zusammen gefasst:
Tabelle 38: Tab_ILF_ePA- Übersicht der REST-Fehlermeldungen
Error mapping |
Status |
Desription |
ErrorCode |
errorDetails |
Vorschlag für Hinweis an den Nutzer |
invalid parameters |
400 |
Bad Request |
malformedRequest |
|
Meldung an den technischen Service |
User Session not available |
403 |
Forbidden |
noUserSession |
|
Meldung an den technischen Service |
blocked user entitlement |
403 |
Forbidden |
blockedUser |
|
Versicherte hat die Praxis für den Zugriff auf das Aktenkonto geblockt |
no valid entitlement |
403 |
Forbidden |
notEntitled |
|
Die Praxis ist nicht befugt auf das Aktenkonto zuzugreifen. Versichertenkarte einlesen oder Versicherten bitten, die Praxis für den Zugriff zu befugen. |
no valid role |
403 |
Forbidden |
invalidOid |
used professionOID in errorDetail |
Der gewünschte Aktenzugriff ist für diese Berufsgruppe nicht erlaubt |
HSM verification failed |
403 |
Forbidden |
invalidToken |
|
Meldung an den technischen Service |
Resource for functionid does not exist |
404 |
Not Found |
noResource |
rootDocumentId of document or uuid folder in errorDetail |
Das gesuchte Dokument oder die gesuchten Daten existieren (nicht) mehr |
Health record does not exist |
404 |
Not Found |
noHealthRecord |
|
Das Aktenkonto existiert nicht (mehr). |
Health record is not in state ACTIVATED |
409 |
Conflict |
statusMismatch |
current status in errorDetail |
Das Aktenkonto befindet sich im Umzug, ca. 24 warten |
request not applicable |
409 |
Conflict |
requestMismatch |
mismatching item (oid, document, folder) in errorDetail |
Meldung an den technischen Service |
the insurant objects to the medication process |
423 |
Locked |
Locked |
|
Versicherter nimmt nicht am Medikationsprozess teil |
any other error |
500 |
Internal Server Error |
internalError |
further information in errorDetail if appliclable |
Aktion wiederholen nach ca. 10 Minuten, sonst |
Bei den FHIR-Schnittstellen werden die Fehlermeldungen mit einem Operation Outcome gemäß https://hl7.org/fhir/R4/operationoutcome.html gebildet.
7.1.1 Fehlerbehandlung im XDS Document Service
Auftretende Fehlertypen unterscheiden sich je nach Architekturebene:
- http-Fehler auf Transportebene
- Fehler auf Ebene des Dokumentenmanagements und der Aktenermittlung.
Tabelle 39: Tab_ILF_ePA_DifferenzFehlerhandling
Aspekt |
IHE-Error |
Fehlercodes |
als String mit Kurzbeschreibung |
Fehlerlisten |
RegistryErrorList |
Kritikalität Warning |
RegistryErrorList.highestSeverity="Warning" |
Kritikalität Error |
RegistryErrorList.highestSeverity="Error" |
SOAP-Fehlertyp |
SOAP 1.2 |
A_14179 - Verständliche Fehlermeldung
Das PS MUSS im Falle von Fehlern Fehlermeldungen bereitstellen, die es den Mitarbeitern der Leistungserbringerinstitution ermöglichen, die Ursache des Fehlers zu identifizieren und mögliche Gegenmaßnahmen zu ergreifen. [<=]
7.1.2 IHE-Error
In der Response der IHE-Schnittstellen-Aufrufe können [ITI-TF-3#Table 4.2.4.1-2]: Error Codes auftreten, die drei ResponseStatusType aufweisen können.
Das Vorhandensein einer Error-List ist prinzipiell vereinbar mit einer teilweise erfolgreichen Verarbeitung. Falls die ErrorList nur Warnings enthält (RegistryError elements mit warning severity, aber ohne error severity), kann die Verarbeitung als erfolgreich angesehen werden.
Fehler aus Aufrufen des Dokumentenmanagements haben das in [ITI TF Vol 3#4.2.4] "Success and Error Reporting" beschriebene Format. Es wird im Fehlerfall ggf. eine Fehlerliste (RegistryErrorList) und darin Fehler (RegistryError) mit den Attributen errorCode, errorContext, codeContext und severity zurückgegeben.
Für die Analyse der Fehlerquelle enthält insbesondere auch der codeContext hilfreiche Informationen, um den Nutzer über die Ursache des Fehlers hinzuweisen und daraus Handlungen abzuleiten, mit denen die Ursache des Fehlers behoben wird.
A_14691 - Meldung über partielle Erfolgsmeldungen
Das PS MUSS im Falle einer partiellen Erfolgsmeldung (oder eines vorliegenden Warning-Elementes) eine Warnung bereitstellen, die es den Mitarbeitern der Leistungserbringerinstitution ermöglichen, die Ursache des (partiellen) Fehlers zu identifizieren und mögliche Gegenmaßnahmen zu ergreifen und die partiellen Fehler vom partiellen Erfolg unterscheiden helfen. [<=]
Bei IHE-Operationen stellt der in Im rs:RegistryResponse/@status Attribut den Verarbeitungsstatus der Anfrage dar:
Tabelle 40: Tab_ILF_ePA_IHE_Success_and_Error_Reporting
Wert |
Beschreibung |
Erläuterung |
Beispiel Anzeigetext |
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess |
[IHE-ITT-TF3]#Table 4.2.4.2-3, 4.2.4.2-4. |
In der Response einer Transaktion sind Error-Elemente enthalten, mindestens eines davon hat die Error Severity. Andere Teile der Transaktion sind erfolgreich verlaufen. |
Transaktion in Teilen erfolgreich |
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure |
[IHE-ITT-TF3#Table 4.2.4.2-1, 4.2.4.2-3,4.2.4.2-4] |
Transaktion gescheitert |
Der ePA-Anwendungsfall konnte nicht erfolgreich beendet werden. |
A_14920 - Fehlertexte aus der RegistryErrorList zur Anzeige von Fehlertexten
Das PS SOLL für Fehler aus der RegistryErrorList eine deutschsprachige Fehlermeldung erstellen. [<=]
A_15092 - Eigene Übersetzungen von Fehlertexten
Das PS KANN die IHE-Error-Fehlertexte mit eigenen Übersetzungen zur Anzeige bringen. Andernfalls KANN der Fehlertext für Fehler, bei denen keine Handlungsanweisung besteht, mit dem generischen Fehlertext "Der ePA-Anwendungsfall konnte nicht erfolgreich beendet werden." zur Anzeige gebracht werden. [<=]
7.1.3 Fehlermeldungen aus dem XDS Document Service
Das Aktensystem kann mindestens die Fehler der Tabelle Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem werfen, die an das PS durchgereicht werden.
Tabelle 41: Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem
Code |
Hinweis |
Referenz |
InvalidDocumentContent |
Dokument passt nicht zu Metadaten |
[gemSpec_Aktensystem_ePAfuerAlle#A_24512*] |
PolicyViolation |
Zugriffsunterbindungsregeln wurden verletzt |
[gemSpec_Aktensystem_ePAfuerAlle#A_24509*] |
UnresolvedReferenceException |
entryUUID kann nicht aufgelöst werden |
[IHE-ITI-TF3#4.2.4] |
XDSDocumentUniqueIdError |
uniqueId kann nicht aufgelöst werden, weil Dokument verborgen |
[gemSpec_Aktensystem_ePAfuerAlle#A_24510*] |
XDSDuplicateUniqueIdInRegistry |
uniqueId ist nicht eindeutig |
[IHE-ITI-TF3#4.2.4] |
XDSMissingDocument |
Dokument zu den Metadaten fehlt |
[IHE-ITI-TF3#4.2.4] |
XDSMissingDocumentMetadata |
Metadaten zum Dokument fehlen |
[IHE-ITI-TF3#4.2.4] |
XDSPatientIdDoesNotMatch |
PatientID fehlt |
[IHE-ITI-TF3#4.2.4] |
XDSRegistryBusy |
Zu viele Aktivitäten in der Registry |
[IHE-ITI-TF3#4.2.4] |
XDSRepositoryBusy |
Zu viele Aktivitäten |
[IHE-ITI-TF3#4.2.4] |
XDSRegistryError |
interner Fehler |
[IHE-ITI-TF3#4.2.4] |
XDSRepositoryError |
interner Fehler |
[IHE-ITI-TF3#4.2.4] |
XDSRegistryMetadataError |
Fehlerhafte Metadaten |
[IHE-ITI-TF3#4.2.4] Der codeContext kann je nach Anwendungsfall zusätzliche Informationen liefern: |
XDSRepositoryMetadataError |
Fehlerhafte Metadaten |
[IHE-ITI-TF3#4.2.4] |
XDSRegistryNotAvailable |
Fehler Zugriff Registry |
[IHE-ITI-TF3#4.2.4] |
XDSRegistryOutOfResources |
Resourcenengpass |
[IHE-ITI-TF3#4.2.4] |
XDSRepositoryOutOfResources |
Resourcenengpass |
[IHE-ITI-TF3#4.2.4] |
XDSStoredQueryMissingParam |
Parameterfehler Stored Query |
[IHE-ITI-TF3#4.2.4] |
XDSStoredQueryParamNumber |
Parameterfehler Stored Query |
[IHE-ITI-TF3#4.2.4] |
XDSTooManyResults |
|
Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen |
XDSUnknownStoredQuery |
Fehlerhafte Stored Query |
[IHE-ITI-TF3#4.2.] |
XDSUnreferencedObjectException |
Fehler beim Löschen von Dokumenten |
[gemSpec_Aktensystem_ePAfuerAlle#A_24511*] |
8 Anhang A – Verzeichnisse
8.1 Abkürzungen
Kürzel |
Erläuterung |
|
|
BAG |
Berufsausübungsgemeinschaft |
CS |
Clientsystem |
DTBS |
Data To Be Signed - zu signierende Daten |
DTBSR |
Data to be Signed Representation - maschinenlesbare Repräsentation der zu signierenden Daten |
eML |
elektronische Medikationsliste |
KT |
Kartenterminal |
PS |
Primärsystem |
PTSB |
Produkttypsteckbrief |
TLS |
Transport Layer security |
Versicherten-ID |
10-stelliger unveränderlicher Teil der 30-stelligen Krankenversicherungsnummer |
VAU |
Vertrauenswürdige Ausführungsumgebung |
8.2 Glossar
Begriff |
Erläuterung |
Behandlungskontext |
Ein Behandlungskontext beginnt, wenn sich der Patient bzw. die Patientin gegenüber der Leistungserbringerinstitution mittels elektronischer Gesundheitskarte oder digitaler Identität identifiziert hat. Er ist die Voraussetzung für den Zugriff einer LEI auf die ePA für alle, Der Behandlungskontext dauert je nach Rolle standardmäßig 3 oder 90 Tage und kann vom Versicherten über die ePA App jederzeit beendet werden oder auf einen beliebigen Zeitraum ausgeweitet werden. |
ePA-Frontend des Versicherten |
Softwareprogramm in der Verfügung des Versicherten, ausgestattet mit einer grafischen Benutzeroberfläche zum Starten fachlicher Anwendungsfälle der ePA und Darstellung des Ergebnisses der Anwendungsfälle. |
Funktionsmerkmal |
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems. |
|
|
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
8.3 Abbildungsverzeichnis
Abbildung 1: ILF_ePA_Element_ContextAbbildung 1: Überblick ePA für alle
Abbildung 2: Abb_ILF_ePA_RecordIdentifierAbbildung 2: Überblick über Aufbau VAU, User Session und Aktensession
Abbildung 3: Abb_ILF_ePA_Kombinierte_Anwendungsfälle_für_bereits_aktiviertes_AktenkontoAbbildung 3: Überblick über Nutzerauthentifizierung
Abbildung 4: Abb_ILF_ePA_getHomeCommunityRequestAbbildung 4: Detaillierter Nachrichten-Flow für die Nutzerauthentifizierung mit dem IDP-Dienst
Abbildung 5: Abb_ILF_PS_ePA_getHomeCommunityIDResponseAbbildung 5: ILF_ePA_Element_Context
Abbildung 6: Abb_ILF_ePA_Eingabeparameter_ActivateAccountAbbildung 6: Ablauf Erstellung einer Befugnis
Abbildung 7: Abb_ILF_ePA_RequestFacilityAuthorizationAbbildung 7: Abb_ILF_ePA_eAB-XML-Containerformat
Abbildung 8: Abb_ILF_ePA_Ad-hoc-Berechtigung_erteilenAbbildung 8: Ablauf eines betreiberübergreifenden Aktenumzugs
Abbildung 9: Abb_ILF_ePA_Eingabeparameter_GetAuthorizationListAbbildung 9 Ansteuern der elektronischen Patientenakte aus der Karteikarte, um die ePA zu öffnen (am oberen Bildrand ist der Menüpunkt zu finden)
Abbildung 10: Abb_ILF_ePA_GetAuthorizationListResponseAbbildung 10 Anzeige der Dokumentenübersicht einer ePA, um nach Dokumenten in der ePA zu suchen, sie zu filtern und zu sortieren (am oberen Bildrand sind die Steuerungselemente zu finden)
Abbildung 11: Abb_ILF_ePA_Benachrichtigungen_GetAll_mit_Zugriffspolicy-EventAbbildung 11 Anzeige eines Kontextmenüs für ein ausgewähltes Dokument, um dieses zu bearbeiten (am rechten Bildrand ist der Menüpunkt zu finden)
Abbildung 12: Abb_ILF_ePA_eAB-XML-ContainerformatAbbildung 12 Eingabemaske mit der vorausgefüllten Einstellung, dass ein Dokument (am unteren Bildrand ist der Menüpunkt zu finden)
Abbildung 15 Anzeige der elektronischen Medikationsliste im Primärsystem
8.4 Tabellenverzeichnis
Tabelle 1: Tab_ILF_ePA_IHE-TransaktionenProfileTabelle 1: TabILF_Kurzübersicht_PS-CS-Typen
Tabelle 2: Tab_ILF_ePA_Identifier_für_Versicherte_und_AktenTabelle 2: I_Information_Service::getRecordStatus
Tabelle 3: Tab_ILF_ePA_Zugriffsberechtigungsstatus pro RecordIdentifierTabelle 3: I_Authorization_Service::getNonce
Tabelle 4: Tab_ILF_ePA_Zugriffsberechtigungen Tabelle 4: I_Authorization_Service::send_Authorization_Request_SC
Tabelle 5: Tab_ILF_ePA_Funktionsmerkmale_Beteiligung_VersicherterTabelle 5: I_Authorization_Service::send_AuthCode
Tabelle 6: Tab_ILF_ePA_Operation_getHomeCommunityIDTabelle 6: TAB_ILF_Zertifikate
Tabelle 7: Tab_ILF_ePA_Operation_ActivateAccountTabelle 7: I_Entitlement_Management::setEntitlementPs
Tabelle 8: Tab_ILF_ePA_Operation_RequestFacilityAuthorizationTabelle 8: I_Information_Service::getConsentDecisionInformation
Tabelle 9: Tab_ILF_ePA_Zugriffsberechtigungs-EndedatumTabelle 9: I_Medication_Service_eML_Render
Tabelle 10: Tab_ILF_ePA_Operation_GetAuthorizationListTabelle 10: I_Medication_Service_FHIR
Tabelle 11: Tab_ILF_ePA_Operation_GetAuthorizationStateTabelle 11: Tab_ILF_ePA_Profilierung
Tabelle 12: Tab_ILF_ePA_PHRServiceTabelle 12: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_Suchen
Tabelle 13: Tab_ILF_ePA_DM_ProfilierungTabelle 13: Tab_ILF_ePA_Namensräume
Tabelle 14: Tab_ILF_ePA_Einschränkungen_auf_XDS.bTabelle 14: Tab_ILF_ePA_KDL-Mapping
Tabelle 15: Tab_ILF_ePA_ClientInformationenTabelle 15: XML-Struktur für Arztbrief im DischargeLetterContainer-Format
Tabelle 16: Tab_ILF_ePA_Zugriffsinformation_WerteDatenfelder_Selbstauskunft
Tabelle 17: Tab_ILF_ePA_IHE-Profilierung_ITI41Tabelle 17: Tab_ILF_ePA_KTR_Metadatenkennzeichnungen
Tabelle 18: Tab_ILF_ePA_Operation_Dokument_einstellenTabelle 18: I_Health_Record_Relocation_Service::startPackageCreation
Tabelle 19: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_einstellenTabelle 19: I_Health_Record_Relocation_Service::startPackageImport
Tabelle 20: Tab_ILF_ePA_IHE-Profilierung_ITI18Tabelle 20: I_Entitlement_Management::setBlockedUserPolicyAssignment
Tabelle 21: Tab_ILF_ePA_Operation_Dokument_suchenTabelle 21: I_Entitlement_Management::deleteBlockedUserPolicyAssignment
Tabelle 22: Tab_ILF_ePA_FindDocuments_PflichtfelderTabelle 22: I_Entitlement_Management::getBlockedUserPolicyAssignment
Tabelle 23: Tab_ILF_ePA_StoredQueriesTabelle 23: Widersprüche im Rahmen des Medikationsprozesses
Tabelle 24: Tab_ILF_ePA_Fehlerbehandlung_Dokumente_SuchenTabelle 24: I_Consent_Decision_Management::updateConsentDecision
Tabelle 25: Tab_ILF_ePA_IHE-Profilierung_ITI43Tabelle 25: I_Consent_Decision_Management::getConsentDecision
Tabelle 26: Tab_ILF_ePA_Operation_Dokumente_anzeigenTabelle 26: I_Audit_Event_Service
Tabelle 27: Tab_ILF_ePA_IHE-Profilierung_ITI86Tabelle 27: I_Information_Service::setUserExperienceResult
Tabelle 28: Tab_ILF_ePA_Operation_Dokumente_löschenTabelle 28: Tab_UX_KPI_Messung_ePA_PS
Tabelle 29: Tab_ILF_ePA_NamensräumeTabelle 29 Dokumente suchen, filtern und sortieren - UX Optimaler Klickpfad
Tabelle 30: Tab_ILF_ePA_BenachrichtigungsquellenTabelle 30 Dokumente suchen, filtern und sortieren - UX Optimaler Klickpfad
Tabelle 31: Tab_ILF_ePA_Benachrichtigungs_InfoModellTabelle 31 Dokument bearbeiten - UX Optimaler Klickpfad
Tabelle 32: Tab_ILF_ePA_Infoquelle_FehlermeldungTabelle 32 Dokument hochladen aus Karteikarte - UX Optimaler Klickpfad
Tabelle 33: Tab_ILF_ePA_ErrorSeverityTabelle 33 Dokument hochladen aus KIM-Workflow - UX Optimaler Klickpfad
Tabelle 34: Tab_ILF_ePA_IHE_Success_and_Error_ReportingTabelle 34 Medikationsliste öffnen - UX Optimaler Klickpfad
Tabelle 35: Tab_ILF_ePA_DifferenzFehlerhandlingTabelle 35 Medikationsliste als Übersicht anzeigen - UX Optimaler Klickpfad
Tabelle 36: Tab_ILF_ePA_Handlungsanweisung_im_FehlerfallTabelle 36 Medikationslisteneintrag im Detail anzeigen - UX Optimaler Klickpfad
Tabelle 37: Tab_ILF_ePA_abgekündigte_Fehlermeldungen_des_Fachmoduls_ePATabelle 37: Medikationsliste herunterladen - UX Optimaler Klickpfad
Tabelle 38: Tab_ILF_ePA_IHE-Fehlermeldungen_AktensystemTabelle 38: Tab_ILF_ePA- Übersicht der REST-Fehlermeldungen
Tabelle 39: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten NFD/DPETabelle 39: Tab_ILF_ePA_DifferenzFehlerhandling
Tabelle 40: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eMPTabelle 40: Tab_ILF_ePA_IHE_Success_and_Error_Reporting
Tabelle 41: Tab_ILF_ePA_Nutzungsvorgaben für Metadaten eABTabelle 41: Tab_ILF_ePA_IHE-Fehlermeldungen_Aktensystem
Tabelle 42: Value Set authorRole
Tabelle 43: Value Set authorSpecialty
Tabelle 44: Value Set classCode
Tabelle 45: Value Set confidentialityCode
Tabelle 46: Value Set eventCodeList
Tabelle 47: Value Set healthcareFacilityTypeCode
Tabelle 48: Value Set practiceSettingCode
Tabelle 49: Value Set typeCode
8.5 Referenzierte Dokumente
8.5.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
||
[gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
||
[gemKPT_ePAfuerAlle] |
gematik: Grobkonzept der "ePA für alle" |
||
[gemSpec_ |
gematik: Spezifikation |
||
[gemSpec_ |
gematik: |
||
[gemSpec_EPAAuditEvent] |
Datenstruktur für Audit-Protokolle im Aktensystem: |
||
[gemSpec_Kon] |
gematik: Spezifikation Konnektor |
||
[gemSpec_VZD_FHIR_Directory] |
gematik: Spezifikation Verzeichnisdienst FHIR-Directory |
||
[gemSpec_IDP_Frontend] |
gematik: Spezifikation Identity Provider – Frontend |
||
[gemSpec_OM] |
gematik: Übergreifende Spezifikation Operations und Maintenance |
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
[gemSpec_PKI] |
gematik: Spezifikation PKI |
||
[gemSpec_Voc_ePA] |
gematik: Vocabulary ePA |
||
[gemSpec_IG_ePA] |
gematik: Implementation Guides für strukturierte Dokumente |
||
[I_Information_Service] |
gematik: I_Information_Service |
||
[I_Authorization_Service] |
gematik: I_Authorization_Service |
||
[I_Entitlement_Management] |
gematik: I_Entitlement_Management |
||
[I_Health_Record_Relocation_Service] |
gematik: I_Health_Record_Relocation_Service |
||
[I_Consent_Decision_Management] |
gematik: I_Consent_Decision_Management |
||
[I_Audit_Event] |
gematik: I_Audit_Event |
||
[I_Medication_Service_eML_Render] |
gematik: I_Medication_Service_eML_Render |
||
[I_Medication_Service_FHIR] |
gematik: I_Medication_Service_FHIR |
||
[PHR_Common.xsd] |
Schemadefinition für einen Arztbrief nach § 383 SGB V |
||
8.5.2 Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
[BasicProfile1.2] |
Basic Profile Version 1.2 |
[BasicProfile2.0] |
Basic Profile Version 2.0 |
[IHE-ITI-RMD], enthält [ITI-62], [ITI-86] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework Supplement, Remove Metadata and Documents (RMD), Revision 1.6 – Trial Implementation, http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RMD.pdf |
[IHE-ITI-RMU], enthält [ITI-92] |
IHE International (2021): IHE IT Infrastructure (ITI) Technical Framework Supplement, Restricted Metadata Update (RMU), Revision 1.3 – Trial Implementation, https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RMU.pdf |
[IHE-ITI-TF1] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework, Volume 1 (ITI TF-1) – Profile definition, use-case analysis, actor definition, and use of transactions and content, Revision 20.0, https://profiles.ihe.net/ITI/TF/Volume1/ |
[IHE-ITI-TF2a], enthält [ITI-18] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework, Volume 2 (ITI TF-2) – Transaction definitions and constraints, Revision 20.0, https://profiles.ihe.net/ITI/TF/Volume2/ |
[IHE-ITI-TF-2b], enthält [ITI-38], [ITI-39], [ITI-41], [ITI-43], [ITI-45] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework, Volume 2 (ITI TF-2) – Transaction definitions and constraints, Revision 20.0, https://profiles.ihe.net/ITI/TF/Volume2/ |
[IHE-ITI-TF2x] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework, Volume 2 (ITI TF-2) – Transaction definitions and constraints, Revision 20.0, https://profiles.ihe.net/ITI/TF/Volume2/ |
[IHE-ITI-TF3] |
IHE International (2023): IHE IT Infrastructure (ITI) Technical Framework, Volume 3 (ITI TF-3) – Cross-Document Sharing Metadata and Content Profiles, Revision 20.0, https://profiles.ihe.net/ITI/TF/Volume3/ |
[IHE-ITI-VS] |
IHE Deutschland (2021: Value Sets für Aktenprojekte im deutschen Gesundheitswesen, Implementierungsleitfaden, Version 3.0 |
[KBV Portal] |
Portal der Kassenärztliche Bundesvereinigung |
[KDL-ILF] |
DVMD: KDL Implementierungsleitfaden 2024 |
[MTOM] |
W3C (2005): SOAP Message Transmission Optimization Mechanism, https://www.w3.org/TR/soap12-mtom/ |
[Richtlinie eArztbrief] |
Kassenärztliche Bundesvereinigung (2021): Richtlinie über die Übermittlung elektronischer Briefe in der vertragsärztlichen Versorgung gemäß § 383 SGB V, Richtlinie Elektronischer Brief |
[SOAP] |
W3C (2007): SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), |
[VHITG_AB] |
VHTIG (2006), Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das Deutsche Gesundheitswesen, Implementierungsleitfaden, Version 1.50, http://download.hl7.de/documents/cdar2-arztbrief/Leitfaden-VHitG-Arztbrief-v150.pdf |
9 Anhang A- Vorschläge zur verkürzten Ansicht der Auswahl von Werten aus Value Sets
Die in [gemSpec_Voc_ePA] vorgegebenen Value Sets beinhalten in der Regel eine hohe Anzahl von Werten, die nicht für jeden Sektor oder jede Berufsgruppe gleichermaßen relevant sind. Um dem Anwender die Nutzung zu erleichtern, wird für die Auswahl der Werte die Anzeige einer gefilterten Ansicht der Tabellen empfohlen.
Hinweis: Neue Nutzergruppen, die im Folgenden noch nicht berücksichtigt sind, sollten sich nach Vorbild der vorliegenden Vorschläge eine verkürzte Ansicht bilden. Neue Nutzergruppen werden schrittweise auch explizit Berücksichtigung finden.
Tabelle 42: Value Set authorRole
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Krankenhaus |
Apotheke |
1 |
Einweiser |
Prozessrollen für Autoren |
x |
x |
|
|
2 |
Entlassender |
|
|
x |
|
|
3 |
Überweiser |
x |
x |
|
|
|
4 |
Durchführender |
x |
x |
x |
x |
|
5 |
durchführendes Gerät |
|
|
|
|
|
6 |
Betreuer |
|
|
|
|
|
7 |
Pflegender |
|
|
|
|
|
17 |
Begutachtender |
|
|
|
|
|
8 |
Behandler |
x |
x |
x |
|
|
9 |
Erstbehandler außerhalb einer Einrichtung |
x |
x |
|
|
|
10 |
Bereitstellender |
|
|
|
|
|
11 |
Dokumentierender |
x |
x |
x |
x |
|
12 |
dokumentierendes Gerät |
|
|
|
|
|
13 |
Validierer |
|
|
|
|
|
14 |
Gesetzlich Verantwortlicher |
|
|
|
|
|
15 |
Beratender |
|
|
|
|
|
16 |
Informierender |
|
|
|
|
|
101 |
Hausarzt |
Patientenbeziehungsrollen für Autoren |
x |
|
|
|
102 |
Patient |
|
|
|
|
|
103 |
Arbeitgebervertreter |
|
|
|
|
|
104 |
Primärbetreuer (langfristig) |
x |
x |
|
x |
|
105 |
Kostenträgervertreter |
|
|
|
|
Tabelle 43: Value Set authorSpecialty
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Krankenhaus |
Apotheke |
11001 |
FA Allgemeinmedizin |
Facharzttitel der Ärztekammern |
x |
|
x |
|
12901 |
SP Geriatrie |
|
|
|
|
|
21001 |
FA Anästhesiologie |
|
|
x |
|
|
21002 |
FA Anästhesiologie und Intensivtherapie |
|
|
|
|
|
31001 |
FA Anatomie |
|
|
|
|
|
41001 |
FA Arbeitshygiene |
|
|
|
|
|
41002 |
FA Arbeitsmedizin |
|
|
|
|
|
51001 |
FA Augenheilkunde |
x |
|
x |
|
|
61001 |
FA Biochemie |
|
|
|
|
|
71107 |
FA Allgemeinchirurgie |
x |
|
x |
|
|
71101 |
FA Allgemeine Chirurgie |
|
|
|
|
|
71001 |
FA Chirurgie |
|
|
|
|
|
71102 |
FA Gefäßchirurgie |
|
|
x |
|
|
71002 |
FA Herzchirurgie |
x |
|
x |
|
|
71202 |
FA Kinder- und Jugendchirurgie |
|
|
|
|
|
71003 |
FA Kinderchirurgie |
x |
|
x |
|
|
71004 |
FA Orthopädie |
|
|
|
|
|
71103 |
FA Orthopädie und Unfallchirurgie |
|
|
|
|
|
71005 |
FA Plastische Chirurgie |
|
|
|
|
|
71106 |
FA Plastische und Ästhetische Chirurgie |
|
|
x |
|
|
71201 |
FA Plastische; Rekonstruktive und Ästhetische Chirurgie |
|
|
|
|
|
71104 |
FA Thoraxchirurgie |
|
|
x |
|
|
71105 |
FA Visceralchirurgie |
|
|
x |
|
|
71108 |
FA Viszeralchirurgie |
|
|
x |
|
|
72001 |
SP Gefäßchirurgie |
|
|
|
|
|
72002 |
SP Rheumatologie (Orthopädie) |
|
|
|
|
|
72003 |
SP Thoraxchirurgie in der Chirurgie |
|
|
|
|
|
72004 |
SP Thoraxchirurgie in der Herzchirurgie |
|
|
|
|
|
72005 |
SP Unfallchirurgie |
|
|
|
|
|
72006 |
SP Visceralchirurgie |
|
|
|
|
|
73001 |
TG Echokardiologie herznaher Gefäße |
|
|
|
|
|
73002 |
TG Gefäßchirurgie |
|
|
|
|
|
73003 |
TG Herz- und Gefäßchirurgie |
|
|
|
|
|
73004 |
TG Kinderchirurgie |
|
|
|
|
|
73005 |
TG Plastische Chirurgie |
|
|
|
|
|
73006 |
TG Rheumatologie (Orthopädie) |
|
|
|
|
|
73007 |
TG Thorax- und Kardiovaskularchirurgie |
|
|
|
|
|
73008 |
TG Thoraxchirurgie |
|
|
|
|
|
73009 |
TG Unfallchirurgie |
|
|
|
|
|
81001 |
FA Frauenheilkunde |
|
|
|
|
|
81002 |
FA Frauenheilkunde und Geburtshilfe |
x |
|
x |
|
|
81003 |
FA Gynäkologie und Geburtshilfe |
|
|
|
|
|
82101 |
SP Gynäkologische Endokrinologie und Reproduktionsmedizin |
|
|
|
|
|
82102 |
SP Gynäkologische Onkologie |
|
|
|
|
|
82103 |
SP Spezielle Geburtshilfe und Perinatalmedizin |
|
|
|
|
|
91001 |
FA Hals-Nasen-Ohrenheilkunde |
x |
|
x |
|
|
91002 |
FA Phoniatrie und Pädaudiologie |
|
|
|
|
|
91101 |
FA Sprach-; Stimm- und kindliche Hörstörungen |
|
|
|
|
|
93001 |
TG Audiologie |
|
|
|
|
|
93002 |
TG Phoniatrie |
|
|
|
|
|
93003 |
TG Phoniatrie und Pädaudiologie |
|
|
|
|
|
101001 |
FA Dermatologie und Venerologie |
|
|
|
|
|
101002 |
FA Haut- und Geschlechtskrankheiten |
x |
|
x |
|
|
111001 |
FA Humangenetik |
|
|
|
|
|
121001 |
FA Hygiene |
|
|
|
|
|
121002 |
FA Hygiene und Umweltmedizin |
|
|
|
|
|
131001 |
FA Immunologie |
|
|
|
|
|
141002 |
FA Innere Medizin |
x |
|
x |
|
|
141110 |
FA Innere Medizin und Angiologie |
|
|
|
|
|
141111 |
FA Innere Medizin und Endokrinologie und Diabetologie |
|
|
|
|
|
141112 |
FA Innere Medizin und Gastroenterologie |
|
|
|
|
|
141903 |
FA Innere Medizin und Geriatrie |
|
|
|
|
|
141113 |
FA Innere Medizin und Hämatologie und Onkologie |
|
|
|
|
|
141904 |
FA Innere Medizin und Infektiologie |
|
|
|
|
|
141114 |
FA Innere Medizin und Kardiologie |
|
|
|
|
|
141115 |
FA Innere Medizin und Nephrologie |
|
|
|
|
|
141116 |
FA Innere Medizin und Pneumologie |
|
|
|
|
|
141117 |
FA Innere Medizin und Rheumatologie |
|
|
|
|
|
141102 |
FA Innere Medizin und Schwerpunkt Angiologie |
|
|
|
|
|
141103 |
FA Innere Medizin und Schwerpunkt Endokrinologie und Diabetologie |
|
|
|
|
|
141104 |
FA Innere Medizin und Schwerpunkt Gastroenterologie |
|
|
|
|
|
141901 |
FA Innere Medizin und Schwerpunkt Geriatrie |
|
|
|
|
|
141902 |
FA Innere Medizin und Schwerpunkt gesamte Innere Medizin |
|
|
|
|
|
141105 |
FA Innere Medizin und Schwerpunkt Hämatologie und Onkologie |
|
|
|
|
|
141106 |
FA Innere Medizin und Schwerpunkt Kardiologie |
|
|
|
|
|
141107 |
FA Innere Medizin und Schwerpunkt Nephrologie |
|
|
|
|
|
141108 |
FA Innere Medizin und Schwerpunkt Pneumologie |
|
|
|
|
|
141109 |
FA Innere Medizin und Schwerpunkt Rheumatologie |
|
|
|
|
|
141003 |
FA Internist/Lungen- und Bronchialheilkunde |
|
|
|
|
|
141005 |
FA Lungen- und Bronchialheilkunde |
|
|
|
|
|
141004 |
FA Lungenheilkunde |
|
|
|
|
|
142001 |
SP Angiologie |
|
|
|
|
|
142002 |
SP Endokrinologie |
|
|
|
|
|
142901 |
SP Endokrinologie und Diabetologie |
|
|
|
|
|
142003 |
SP Gastroenterologie |
|
|
|
|
|
142004 |
SP Geriatrie |
|
|
|
|
|
142005 |
SP Hämatologie und Internistische Onkologie |
|
|
|
|
|
142006 |
SP Infektiologie |
|
|
|
|
|
142007 |
SP Kardiologie |
|
|
|
|
|
142008 |
SP Nephrologie |
|
|
|
|
|
142009 |
SP Pneumologie |
|
|
|
|
|
142010 |
SP Rheumatologie |
|
|
|
|
|
143001 |
TG Diabetologie |
|
|
|
|
|
143002 |
TG Endokrinologie |
|
|
|
|
|
143003 |
TG Gastroenterologie |
|
|
|
|
|
143004 |
TG Hämatologie |
|
|
|
|
|
143005 |
TG Infektions- und Tropenmedizin |
|
|
|
|
|
143006 |
TG Kardiologie |
|
|
|
|
|
143901 |
TG Kardiologie und Angiologie |
|
|
|
|
|
143007 |
TG Lungen- und Bronchialheilkunde |
|
|
|
|
|
143008 |
TG Nephrologie |
|
|
|
|
|
143009 |
TG Rheumatologie |
|
|
|
|
|
151002 |
FA Kinder- und Jugendmedizin |
x |
|
|
|
|
151001 |
FA Kinderheilkunde |
|
|
|
|
|
152901 |
SP Endokrinologie und Diabetologie in der Kinder- und Jugendmedizin |
|
|
|
|
|
152902 |
SP Gastroenterologie in der Kinder- und Jugendmedizin |
|
|
|
|
|
152001 |
SP Infektiologie |
|
|
|
|
|
152201 |
SP Kinder- und Jugend-Hämatologie und -Onkologie |
|
|
|
|
|
152202 |
SP Kinder- und Jugend-Kardiologie |
|
|
|
|
|
152101 |
SP Kinder-Hämatologie und -Onkologie |
|
|
|
|
|
152002 |
SP Kinder-Kardiologie |
|
|
|
|
|
152906 |
SP Kinderpneumologie |
|
|
|
|
|
152003 |
SP Neonatologie |
|
|
|
|
|
152903 |
SP Nephrologie |
|
|
|
|
|
152102 |
SP Neuropädiatrie |
|
|
|
|
|
152904 |
SP Pädiatrische Rheumatologie |
|
|
|
|
|
152905 |
SP Pulmologie in der Kinder- und Jugendmedizin |
|
|
|
|
|
153001 |
TG Kinderdiabetologie |
|
|
|
|
|
153002 |
TG Kindergastroenterologie |
|
|
|
|
|
153003 |
TG Kinderhämatologie |
|
|
|
|
|
153004 |
TG Kinderkardiologie |
|
|
|
|
|
153005 |
TG Kinderlungen- und -bronchialheilkunde |
|
|
|
|
|
153006 |
TG Kinderneonatologie |
|
|
|
|
|
153007 |
TG Kindernephrologie |
|
|
|
|
|
153008 |
TG Kinderneuropsychiatrie |
|
|
|
|
|
161001 |
FA Kinder- und Jugendpsychiatrie |
|
|
|
|
|
161002 |
FA Kinder- und Jugendpsychiatrie und -psychotherapie |
|
|
|
|
|
171001 |
FA Laboratoriumsmedizin |
x |
x |
x |
|
|
173001 |
TG Medizinische Mikrobiologie |
|
|
|
|
|
181001 |
FA Mikrobiologie |
|
|
|
|
|
181002 |
FA Mikrobiologie und Infektionsepidemiologie |
|
|
|
|
|
181101 |
FA Mikrobiologie; Virologie und Infektionsepidemiologie |
|
|
|
|
|
191001 |
FA Kieferchirurgie |
|
x |
x |
|
|
191002 |
FA Mund-Kiefer-Gesichtschirurgie |
x |
x |
x |
|
|
191901 |
FA Oralchirurgie |
|
|
|
|
|
201001 |
FA Nervenheilkunde |
|
|
|
|
|
201002 |
FA Nervenheilkunde (Neurologie und Psychiatrie) |
|
|
|
|
|
201003 |
FA Neurologie und Psychiatrie (Nervenarzt) |
|
|
|
|
|
203001 |
TG Kinderneuropsychiatrie |
|
|
|
|
|
211001 |
FA Neurochirurgie |
|
|
|
|
|
221001 |
FA Neurologie |
x |
|
x |
|
|
222901 |
SP Geriatrie |
|
|
|
|
|
231001 |
FA Nuklearmedizin |
|
|
|
|
|
241001 |
FA Öffentliches Gesundheitswesen |
|
x |
|
|
|
251001 |
FA Neuropathologie |
|
|
|
|
|
251002 |
FA Pathobiochemie und Labordiagnostik |
|
|
|
|
|
251003 |
FA Pathologie |
x |
|
x |
|
|
251004 |
FA Pathologische Anatomie |
|
|
|
|
|
251005 |
FA Pathologische Physiologie |
|
|
|
|
|
253001 |
TG Neuropathologie |
|
|
|
|
|
261001 |
FA Klinische Pharmakologie |
|
|
|
|
|
261002 |
FA Pharmakologie |
|
|
|
|
|
261003 |
FA Pharmakologie und Toxikologie |
|
|
|
|
|
263001 |
TG Klinische Pharmakologie |
|
|
|
|
|
381201 |
Phoniatrie und Pädaudiologie |
|
|
|
|
|
271001 |
FA Physikalische und Rehabilitative Medizin |
|
|
|
|
|
271002 |
FA Physiotherapie |
|
|
|
|
|
281001 |
FA Physiologie |
|
|
|
|
|
291001 |
FA Psychiatrie |
|
|
|
|
|
291002 |
FA Psychiatrie und Psychotherapie |
x |
|
x |
|
|
292101 |
SP Forensische Psychiatrie |
|
|
|
|
|
292901 |
SP Geriatrie |
|
|
|
|
|
301101 |
FA Psychosomatische Medizin und Psychotherapie |
|
|
|
|
|
301001 |
FA Psychotherapeutische Medizin |
|
|
|
|
|
301002 |
FA Psychotherapie |
|
|
|
|
|
311001 |
FA Diagnostische Radiologie |
|
|
|
|
|
311002 |
FA Radiologie |
|
|
|
|
|
311003 |
FA Radiologische Diagnostik |
|
|
|
|
|
312201 |
SP Kinder- und Jugendradiologie |
|
|
|
|
|
312001 |
SP Kinderradiologie |
|
|
|
|
|
312002 |
SP Neuroradiologie |
|
|
|
|
|
313001 |
TG Kinderradiologie |
|
|
|
|
|
313002 |
TG Neuroradiologie |
|
|
|
|
|
313003 |
TG Strahlentherapie |
|
|
|
|
|
321001 |
FA Rechtsmedizin |
|
|
|
|
|
351001 |
FA Strahlentherapie |
|
|
|
|
|
361001 |
FA Blutspende- und Transfusionswesen |
|
|
|
|
|
361002 |
FA Transfusionsmedizin |
|
|
|
|
|
371001 |
FA Urologie |
x |
|
|
|
|
1 |
Zahnärztin/Zahnarzt |
Qualifikationen zahnärztlicher Autoren |
|
x |
|
|
2 |
FZA Allgemeine Zahnheilkunde |
|
x |
|
|
|
3 |
FZA Parodontologie |
|
x |
|
|
|
4 |
FZA Oralchirurgie |
|
x |
|
|
|
5 |
FZA Kieferorthopädie |
|
x |
|
|
|
6 |
FZA öffentliches Gesundheitswesen |
|
x |
|
|
|
1 |
Gesundheits- Sozial-, Sportmanagement |
Qualifikationen nicht ärztlicher Autoren |
|
|
|
|
2 |
Arzthilfe, Praxisorganisation, -verwaltung |
x |
x |
|
|
|
3 |
Kaufmann/-frau - Gesundheitswesen |
|
|
|
|
|
4 |
Medizinischer Fachangestellter |
|
|
|
|
|
6 |
Zahnmedizinischer Fachangestellter |
|
x |
x |
|
|
7 |
Arztsekretär |
|
|
|
|
|
8 |
Sozial-, Gesundheitsmanagement |
|
|
|
|
|
9 |
Gesundheitsaufseher/Hygienekontrolleur |
|
|
|
|
|
10 |
Assistent Gesundheits- und Sozialwesen |
|
|
|
|
|
11 |
Beamte Sozialversicherung |
|
|
|
|
|
12 |
Beamte Sozialverwaltung |
|
|
|
|
|
13 |
Betriebswirt |
|
|
|
|
|
14 |
Gesundheitsmanager |
|
|
|
|
|
15 |
Sozialökonom, -wirt |
|
|
|
|
|
16 |
Sozialversicherungsfachangestellte |
|
|
|
|
|
17 |
Sportmanagement |
|
|
|
|
|
18 |
Sportassistent |
|
|
|
|
|
19 |
Fachwirt Fitness |
|
|
|
|
|
20 |
Sport- und Fitnesskaufmann |
|
|
|
|
|
21 |
Sportmanager, Sportökonom |
|
|
|
|
|
22 |
nichtärztliche medizinische Analyse, Beratung, Pflege, Therapie |
|
|
|
|
|
23 |
Gesundheitsberatung, -förderung |
|
|
|
|
|
24 |
Assistenten für Gesundheitstourismus, -prophylaxe |
|
|
|
|
|
25 |
Diätassistent |
|
|
|
|
|
26 |
Gesundheitsförderer, -pädagoge |
|
|
|
|
|
27 |
Gesundheitswissenschaftler |
|
|
|
|
|
28 |
Oekotrophologe |
|
|
|
|
|
29 |
Tai-Chi-Chuan- und Qigong-Lehrer |
|
|
|
|
|
30 |
Yogalehrer |
|
|
|
|
|
31 |
Sportfachmann |
|
|
|
|
|
32 |
Sportwissenschaftler |
|
|
|
|
|
33 |
Kranken-, Altenpflege, Geburtshilfe |
|
|
|
|
|
34 |
Altenpflegehelfer |
|
|
|
|
|
35 |
Altenpfleger |
|
|
|
|
|
36 |
Fachkraft Pflegeassistenz |
|
|
|
|
|
37 |
Gesundheits- und Kinderkrankenpfleger |
|
|
|
|
|
38 |
Gesundheits- und Krankenpflegehelfer |
|
|
|
|
|
39 |
Gesundheits- und Krankenpfleger |
|
|
|
|
|
40 |
Haus- und Familienpfleger |
|
|
|
|
|
41 |
Hebamme/Entbindungspfleger |
x |
|
x |
|
|
42 |
Heilerziehungspfleger |
|
|
|
|
|
43 |
Helfer Altenpflege |
|
|
|
|
|
44 |
Helfer stationäre Krankenpflege |
|
|
|
|
|
45 |
Heilerziehungspflegehelfer |
|
|
|
|
|
46 |
Pflegewissenschaftler |
|
|
|
|
|
47 |
Nichtärztliche Behandlung, Therapie (außer Psychotherapie) |
|
|
|
|
|
48 |
Akademischer Sprachtherapeut |
|
|
|
|
|
49 |
Atem-, Sprech- und Stimmlehrer |
|
|
|
|
|
50 |
Ergotherapeut |
|
|
|
|
|
51 |
Fachangestellter für Bäderbetriebe |
|
|
|
|
|
52 |
Heilpraktiker |
|
|
|
|
|
53 |
Klinischer Linguist |
|
|
|
|
|
54 |
Kunsttherapeut |
|
|
|
|
|
55 |
Logopäde |
|
|
|
|
|
56 |
Masseur und medizinische Bademeister |
|
|
|
|
|
57 |
Motologe |
|
|
|
|
|
58 |
Musiktherapeut |
|
|
|
|
|
59 |
Orthoptist |
|
|
|
|
|
60 |
Physiotherapeut |
|
|
|
|
|
61 |
Podologe |
|
|
|
|
|
62 |
Sporttherapeut |
|
|
|
|
|
63 |
Sprechwissenschaftler |
|
|
|
|
|
64 |
Staatlich anerkannter Sprachtherapeut |
|
|
|
|
|
65 |
Stomatherapeut |
|
|
|
|
|
66 |
Tanz- und Bewegungstherapeut |
|
|
|
|
|
68 |
Sozialtherapeut |
|
|
|
|
|
69 |
Pharmazeutische Beratung, Pharmavertrieb |
|
|
|
|
|
70 |
Apotheker/Fachapotheker |
|
|
|
x |
|
71 |
Pharmazeut |
|
|
|
|
|
72 |
Pharmazeutisch-technischer Assistent – PTA |
|
|
|
x |
|
73 |
Pharmazeutisch-kaufmännischer Angestellter |
|
|
|
x |
|
74 |
Psychologische Analyse, Beratung, Therapie |
|
|
|
|
|
75 |
Gesundheits- und Rehabilitationspsychologe |
|
|
|
|
|
76 |
Kinder- und Jugendpsychotherapeut |
|
|
|
|
|
77 |
Klinischer Psychologe |
|
|
|
|
|
78 |
Kommunikationspsychologe |
|
|
|
|
|
79 |
Pädagogischer Psychologe |
|
|
|
|
|
80 |
Psychoanalytiker |
|
|
|
|
|
81 |
Psychologe |
|
|
|
|
|
82 |
Psychologischer Psychotherapeut |
|
|
|
|
|
83 |
Sportpsychologe |
|
|
|
|
|
84 |
Verkehrspsychologe |
|
|
|
|
|
85 |
Wirtschaftspsychologe |
|
|
|
|
|
86 |
Rettungsdienst |
|
|
|
|
|
87 |
Ingenieur Rettungswesen |
|
|
|
|
|
88 |
Notfallsanitäter |
|
|
|
|
|
89 |
Rettungsassistent |
|
|
|
|
|
90 |
Rettungshelfer |
|
|
|
|
|
91 |
Rettungssanitäter |
|
|
|
|
|
92 |
med. Datenverarbeitung |
|
|
|
|
|
94 |
Medizinischer Dokumentar |
|
|
|
|
|
95 |
Medizinischer Dokumentationsassistent |
|
|
|
|
|
173 |
Fachangestellter f. Medien- und Informationsdienste - Medizinische Dokumentation |
|
|
|
|
|
174 |
Medizinischer Informationsmanager |
|
|
|
|
|
96 |
Soziales, Pädagogik |
|
|
|
|
|
97 |
Kinderbetreuung, -erziehung |
|
|
|
|
|
98 |
Pädagoge |
|
|
|
|
|
99 |
Kinderdorfmutter, -vater |
|
|
|
|
|
100 |
Kinderpfleger |
|
|
|
|
|
101 |
Erzieher |
|
|
|
|
|
102 |
Erzieher Jugend- und Heimerziehung |
|
|
|
|
|
103 |
Lehrer |
|
|
|
|
|
104 |
Orientierungs- und Mobilitätslehrer |
|
|
|
|
|
105 |
Medien-, Kulturpädagogik |
|
|
|
|
|
106 |
Musikpädagoge |
|
|
|
|
|
107 |
Sozialberatung, -arbeit |
|
|
|
|
|
108 |
Sozialarbeiter/Sozialpädagoge |
|
|
|
|
|
109 |
Betreuungskraft/Alltagsbegleiter |
|
|
|
|
|
110 |
Gerontologe |
|
|
|
|
|
111 |
Psychosozialer Prozessbegleiter |
|
|
|
|
|
112 |
Rehabilitationspädagoge |
|
|
|
|
|
113 |
Sozialassistent |
|
|
|
|
|
114 |
Seelsorge |
|
|
|
|
|
115 |
Religionspädagoge |
|
|
|
|
|
116 |
Gemeindehelfer, Gemeindediakon |
|
|
|
|
|
117 |
Theologe |
|
|
|
|
|
118 |
Medizintechnik, Laboranalyse |
|
|
|
|
|
119 |
Medizin-, Orthopädie- und Rehatechnik |
|
|
|
|
|
120 |
Assistent Medizinische Gerätetechnik |
|
|
|
|
|
121 |
Augenoptiker |
|
|
|
|
|
122 |
Hörakustiker/Hörgeräteakustiker |
|
|
|
|
|
123 |
Hörgeräteakustikermeister |
|
|
|
|
|
124 |
Ingenieur Augenoptik |
|
|
|
|
|
125 |
Ingenieur - Hörtechnik und Audiologie |
|
|
|
|
|
126 |
Ingenieur - Medizintechnik |
|
|
|
|
|
127 |
Ingenieur - Orthopädie- und Rehatechnik |
|
|
|
|
|
128 |
Medizinphysiker (z.B. in Strahlenmedizin) |
|
|
|
|
|
129 |
Orthopädieschuhmacher |
|
|
|
|
|
130 |
Orthopädietechnik - Mechaniker |
|
|
|
|
|
131 |
Zahntechniker |
|
x |
|
|
|
132 |
Glasbläser (Fachrichtung Kunstaugen) |
|
|
|
|
|
133 |
staatlich geprüfter Techniker der Fachrichtung Medizintechnik |
|
|
|
|
|
134 |
Medizinisch-technische Assistenz |
|
|
|
|
|
135 |
Anästhesietechnischer Assistent |
|
|
|
|
|
136 |
HNO Audiologieassistent |
|
|
|
|
|
137 |
Medizinisch-Technischer Assistent Funktionsdiagnostik – MTA-F |
|
|
|
|
|
138 |
Medizinisch-Technischer Laboratoriumsassistent – MTA-L |
|
|
|
|
|
139 |
Medizinisch-Technischer Radiologieassistent – MTA-R |
|
|
|
|
|
140 |
Operationstechnischer Angestellter |
|
|
|
|
|
141 |
Operationstechnischer Assistent |
|
|
|
|
|
143 |
Zytologieassistent |
|
|
|
|
|
144 |
Chemie, naturwissenschaftliche Laboranalyse (außer MTA) |
|
|
|
|
|
145 |
Biochemiker (z.B. klinische Chemie) |
|
|
|
|
|
146 |
Chemiker (z.B. klinische Chemie) |
|
|
|
|
|
147 |
Humangenetiker |
|
|
|
|
|
148 |
Mikrobiologe |
|
|
|
|
|
149 |
Dienstleistungen am Menschen (außer medizinische) |
|
|
|
|
|
150 |
Körperpflege |
|
|
|
|
|
151 |
Fachkraft Beauty und Wellness |
|
|
|
|
|
152 |
Friseur |
|
|
|
|
|
153 |
Kosmetiker |
|
|
|
|
|
154 |
Bestattungswesen |
|
|
|
|
|
155 |
Bestattungsfachkraft |
|
|
|
|
|
156 |
Berufe aus sonstigen Berufsfeldern |
|
|
|
|
|
157 |
Umwelt |
|
|
|
|
|
165 |
Jurist |
|
|
|
|
|
169 |
Taxifahrer bei Krankentransport |
|
|
|
|
|
180 |
Pharmazieingenieur |
|
|
|
|
|
182 |
Apothekerassistent |
|
|
|
|
|
181 |
Apothekenassistent |
|
|
|
|
|
1 |
Arzt in Facharztausbildung |
Ärztliche Berufsvarianten |
|
|
|
|
2 |
Hausarzt |
|
|
|
|
|
3 |
Praktischer Arzt |
|
|
|
|
Hinweis: Im Zuge der Value Set-Pflege wurde das Code-System "S_BAR2_WBO" (OID 1.2.276.0.76.5.114) für Fachgruppen-Codes nach der Weiterbildungsordnung Bundesarztregister in das neue Code-System "Facharzttitel der Ärztekammern" (OID: 1.2.276.0.76.5.514) konsolidiert, welches zukünftig das alte System ersetzt. Aufgrund der notwendigen Abwärtskompatibilität muss im Value Set "DocumentEntry.authorSpecialty" (OID: 1.2.276.0.76.11.31) für Spezialisierungen eines Dokumentenautors weiterhin das Code-System "S_BAR2_WBO" durch ePA-Produkttypen, welche IHE ITI XDS-Metadaten verarbeiten, lesend unterstützt werden. Für das Value Set "SubmissionSet.authorSpecialty" gilt dies analog. Neue Dokumente oder SubmissionSets dürfen nicht mehr mit Codes aus "S_BAR2_WBO" gekennzeichnet werden.
Tabelle 44: Value Set classCode
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Krankenhaus |
Apotheke |
ADM |
Administratives Dokument |
Dokumentenklassen |
x |
x |
x |
x |
ANF |
Anforderung |
|
|
|
|
|
ASM |
Assessment |
|
|
|
|
|
BEF |
Befundbericht |
x |
x |
x |
x |
|
BIL |
Bilddaten |
x |
x |
x |
x |
|
BRI |
Brief |
x |
x |
x |
x |
|
DOK |
Dokumente ohne besondere Form (Notizen) |
x |
x |
x |
x |
|
DUR |
Durchführungsprotokoll |
x |
x |
x |
|
|
FOR |
Forschung |
|
|
|
|
|
GUT |
Gutachten und Qualitätsmanagement |
|
|
|
|
|
LAB |
Laborergebnisse |
x |
x |
x |
x |
|
AUS |
Medizinischer Ausweis |
x |
x |
x |
x |
|
PLA |
Planungsdokument |
x |
x |
x |
x |
|
57016-8 |
Patienteneinverständniserklärung |
Logical Observation Identifier |
x |
x |
x |
x |
VER |
Verordnung |
Dokumentenklassen |
x |
x |
x |
x |
VID |
Videodaten |
x |
x |
x |
x |
Tabelle 45: Value Set confidentialityCode
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Krankenhaus |
Apotheke |
LEI |
Dokument einer Leistungserbringerinstitution |
ePA-Vertraulichkeit |
x |
x |
x |
x |
KTR |
Dokument eines Kostenträgers |
x |
x |
x |
x |
|
PAT |
Dokument eines Versicherten |
x |
x |
x |
x |
|
LEÄ |
Leistungserbringeräquivalentes Dokument eines Versicherten oder Kostenträgers |
x |
|
|
|
|
N |
normal |
Confidentiality |
x |
x |
x |
x |
R |
restricted |
x |
x |
x |
x |
|
V |
very restricted |
x |
x |
x |
x |
|
PV |
gesperrt |
Betroffeneneinschätzung der Vertraulichkeitsstufe |
|
|
|
|
PR |
erhöhte Vertraulichkeit |
|
|
|
|
|
PN |
übliche Vertraulichkeit |
|
|
|
|
Tabelle 46: Value Set eventCodeList
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Kranken- |
Apotheke |
urn:ihe:iti:xdw:2011:eventCode:open |
Workflow offen |
DocumentReference Format Code Set |
|
|
|
|
urn:ihe:iti:xdw:2011:eventCode:closed |
Workflow abgeschlossen |
|
|
|
|
|
H1 |
vom Patienten mitgebracht |
Dokumenten-Warnhinweise |
x |
x |
x |
x |
H2 |
noch nicht mit Patient besprochen |
|
|
|
|
|
H3 |
eventuell veraltete Daten |
|
|
|
|
|
H4 |
vorläufiges Dokument |
|
|
|
|
|
E100 |
ambulanter Kontakt |
Fallkontext bei Dokumentenerstellung |
x |
x |
x |
x |
E110 |
ambulante OP |
x |
x |
x |
|
|
E200 |
stationärer Aufenthalt |
|
|
x |
|
|
E210 |
stationäre Aufnahme |
|
|
|
|
|
E211 |
Aufnahme vollstationär |
|
|
|
|
|
E212 |
Aufnahme/Wiederaufnahme teilstationär |
|
|
|
|
|
E213 |
Aufnahme Entbindung stationär |
|
|
|
|
|
E214 |
Aufnahme eines Neugeborenen |
|
|
|
|
|
E215 |
Aufnahme des Spenders zur Organentnahme |
|
|
|
|
|
E230 |
stationäre Entlassung |
|
|
|
|
|
E231 |
stationäre Entlassung nach Hause |
|
|
|
|
|
E232 |
stationäre Entlassung in eine Rehabilitationseinrichtung |
|
|
|
|
|
E233 |
stationäre Entlassung in eine Pflegeeinrichtung/Hospiz |
|
|
|
|
|
E234 |
Entlassung zur nachstationären Behandlung |
|
|
|
|
|
E235 |
Patient während stationärem Aufenthalt verstorben |
|
|
|
|
|
E250 |
stationäre Verlegung |
|
|
|
|
|
E251 |
Verlegung innerhalb eines Krankenhauses |
|
|
|
|
|
E252 |
Verlegung in ein anderes Krankenhaus |
|
|
|
|
|
E253 |
externe Verlegung in Psychiatrie |
|
|
|
|
|
E270 |
kurzzeitige Unterbrechung einer stationären Behandlung |
|
|
|
|
|
E280 |
Konsil |
x |
x |
x |
|
|
E300 |
Behandlung im häuslichen Umfeld |
x |
x |
|
|
|
E400 |
Virtual Encounter |
x |
x |
x |
|
Tabelle 47: Value Set healthcareFacilityTypeCode
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Kranken- |
Apotheke |
APD |
Ambulanter Pflegedienst |
Einrichtungsarten der |
|
|
|
|
APO |
Apotheke |
|
|
|
x |
|
BER |
Ärztlicher Bereitschaftsdienst |
x |
|
|
|
|
PRA |
Arztpraxis |
x |
x |
|
|
|
BAA |
Betriebsärztliche Abteilung |
x |
|
|
|
|
BHR |
Gesundheitsbehörde |
|
|
|
|
|
HEB |
Hebamme/Geburtshaus |
x |
|
x |
|
|
HOS |
Hospiz |
|
|
x |
|
|
KHS |
Krankenhaus |
|
|
x |
|
|
MVZ |
Medizinisches Versorgungszentrum |
x |
x |
|
x |
|
HAN |
Medizinisch-technisches Handwerk |
|
|
|
|
|
REH |
Medizinische Rehabilitation |
|
|
|
|
|
HEI |
Nicht-ärztliche Heilberufs-Praxis |
|
|
|
|
|
PFL |
Pflegeheim |
|
|
|
|
|
RTN |
Rettungsdienst |
|
|
|
|
|
SEL |
Selbsthilfe |
|
|
|
|
|
TMZ |
Telemedizinisches Zentrum |
x |
|
|
|
|
BIL |
Bildungseinrichtung |
Einrichtungsarten außerhalb der |
|
|
|
|
FOR |
Forschungseinrichtung |
|
|
|
|
|
GEN |
Gen-Analysedienste |
|
|
|
|
|
MDK |
Medizinischer Dienst der Krankenversicherung |
|
|
|
|
|
PAT |
Patient außerhalb der Betreuung |
|
|
|
|
|
SPE |
Spendedienste |
|
|
|
|
|
VER |
Versicherungsträger |
|
|
|
|
Tabelle 48: Value Set practiceSettingCode
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Kranken- |
Apotheke |
ALLG |
Allgemeinmedizin |
Ärztliche Fachrichtungen |
x |
|
|
|
ANAE |
Anästhesiologie |
x |
x |
x |
|
|
ARBE |
Arbeitsmedizin |
x |
|
|
|
|
AUGE |
Augenheilkunde |
x |
|
x |
|
|
CHIR |
Chirurgie |
x |
|
x |
|
|
ALCH |
Allgemeinchirurgie |
|
|
|
|
|
GFCH |
Gefäßchirurgie |
|
|
|
|
|
HZCH |
Herzchirurgie |
|
|
|
|
|
KDCH |
Kinderchirurgie |
|
|
|
|
|
ORTH |
Orthopädie |
|
|
|
|
|
PLCH |
Plastische und Ästhetische Chirurgie |
|
|
|
|
|
THCH |
Thoraxchirurgie |
|
|
|
|
|
UNFC |
Unfallchirurgie |
|
|
|
|
|
VICH |
Viszeralchirurgie |
|
|
|
|
|
FRAU |
Frauenheilkunde und Geburtshilfe |
x |
|
x |
|
|
GEND |
Gynäkologische Endokrinologie und Reproduktionsmedizin |
|
|
|
|
|
GONK |
Gynäkologische Onkologie |
|
|
|
|
|
PERI |
Perinatalmedizin |
|
|
|
|
|
GERI |
Geriatrie |
x |
|
x |
|
|
HNOH |
Hals-Nasen-Ohrenheilkunde |
x |
|
x |
|
|
HRST |
Sprach-, Stimm- und kindliche Hörstörungen |
|
|
|
|
|
HAUT |
Haut- und Geschlechtskrankheiten |
x |
|
x |
|
|
HUMA |
Humangenetik |
x |
|
x |
|
|
HYGI |
Hygiene und Umweltmedizin |
x |
|
x |
|
|
INNE |
Innere Medizin |
x |
|
x |
|
|
ANGI |
Angiologie |
|
|
|
|
|
ENDO |
Endokrinologie und Diabetologie |
|
|
|
|
|
GAST |
Gastroenterologie |
|
|
|
|
|
HAEM |
Hämatologie und internistische Onkologie |
|
|
|
|
|
KARD |
Kardiologie |
|
|
|
|
|
NEPH |
Nephrologie |
|
|
|
|
|
PNEU |
Pneumologie |
|
|
|
|
|
RHEU |
Rheumatologie |
|
|
|
|
|
INTM |
Intensivmedizin |
x |
|
x |
|
|
INTO |
Interdisziplinäre Onkologie |
x |
|
x |
|
|
INTS |
Interdisziplinäre Schmerzmedizin |
x |
|
x |
|
|
KIJU |
Kinder- und Jugendmedizin |
x |
|
x |
|
|
KONK |
Kinder-Hämatologie und -Onkologie |
|
|
|
|
|
KKAR |
Kinder-Kardiologie |
|
|
|
|
|
NNAT |
Neonatologie |
|
|
|
|
|
NPAE |
Neuropädiatrie |
|
|
|
|
|
KPSY |
Kinder- und Jugendpsychiatrie und -psychotherapie |
x |
|
x |
|
|
LABO |
Laboratoriumsmedizin |
x |
x |
x |
|
|
MIKR |
Mikrobiologie, Virologie und Infektionsepidemiologie |
x |
|
x |
|
|
MKGC |
Mund-Kiefer-Gesichtschirurgie |
x |
x |
x |
|
|
NATU |
Naturheilverfahren und alternative Heilmethoden |
x |
|
x |
|
|
NOTF |
Notfallmedizin |
x |
x |
x |
|
|
NRCH |
Neurochirurgie |
x |
|
x |
|
|
NEUR |
Neurologie |
x |
|
x |
|
|
NUKL |
Nuklearmedizin |
x |
|
x |
|
|
GESU |
Öffentliches Gesundheitswesen |
x |
x |
x |
x |
|
PALL |
Palliativmedizin |
x |
|
x |
|
|
PATH |
Pathologie |
x |
|
x |
|
|
NPAT |
Neuropathologie |
|
|
|
|
|
PHAR |
Pharmakologie |
x |
x |
x |
x |
|
TOXI |
Toxikologie |
|
|
|
|
|
REHA |
Physikalische und Rehabilitative Medizin |
x |
|
x |
|
|
PSYC |
Psychiatrie und Psychotherapie |
x |
|
x |
|
|
FPSY |
Forensische Psychiatrie |
|
|
|
|
|
PSYM |
Psychosomatische Medizin und Psychotherapie |
x |
|
x |
|
|
RADI |
Radiologie |
x |
|
x |
|
|
KRAD |
Kinderradiologie |
|
|
|
|
|
NRAD |
Neuroradiologie |
|
|
|
|
|
RECH |
Rechtsmedizin |
x |
x |
x |
|
|
SCHL |
Schlafmedizin |
x |
|
x |
|
|
SPOR |
Sport- und Bewegungsmedizin |
x |
|
x |
|
|
STRA |
Strahlentherapie |
x |
|
x |
|
|
TRAN |
Transfusionsmedizin |
x |
|
x |
|
|
TROP |
Tropen-/Reisemedizin |
x |
|
x |
|
|
UROL |
Urologie |
x |
|
x |
|
|
MZKH |
Zahnmedizin |
|
x |
x |
|
|
ORAL |
Oralchirurgie |
|
x |
x |
|
|
KIEF |
Kieferorthopädie |
|
x |
|
|
|
MZAH |
Allgemeine Zahnheilkunde |
Zahnärztliche Fachrichtungen |
|
x |
|
|
PARO |
Parodontologie |
Ärztliche Fachrichtungen |
|
x |
|
|
ZGES |
Öffentliches Gesundheitswesen (Zahnheilkunde) |
Zahnärztliche Fachrichtungen |
|
x |
|
|
TRPL |
Transplantantionsmedizin |
Ärztliche Fachrichtungen |
|
|
x |
|
ERG |
Ergotherapie |
Nicht-ärztliche Fachrichtungen |
|
|
x |
|
ERN |
Ernährung und Diätetik |
x |
|
x |
|
|
FOR |
Forschung |
|
|
|
|
|
PFL |
Pflege und Betreuung |
|
|
|
|
|
ALT |
Altenpflege |
|
|
|
|
|
KIN |
Kinderpflege |
|
|
|
|
|
PAT |
Patient außerhalb der Betreuung |
|
|
|
|
|
PHZ |
Pharmazeutik |
|
|
x |
x |
|
POD |
Podologie |
x |
|
x |
|
|
PRV |
Prävention |
|
|
|
|
|
SOZ |
Sozialwesen |
|
|
|
|
|
SPR |
Sprachtherapie |
|
|
|
|
|
VKO |
Versorgungskoordination |
|
|
|
|
|
VER |
Verwaltung |
|
|
|
|
|
PST |
Psychotherapie |
x |
|
x |
|
Tabelle 49: Value Set typeCode
Code |
Anzeigename |
Code-System |
Arzt/ Rolle Med |
Zahnarzt |
Kranken- |
Apotheke |
ABRE |
Abrechnungsdokumente |
Dokumententypen |
x |
x |
x |
x |
|
|
|
|
x |
|
|
ANTR |
Anträge und deren Bescheide |
x |
x |
x |
x |
|
|
Anästhesiedokumente |
x |
x |
x |
|
|
BERI |
Arztberichte |
x |
x |
x |
|
|
BESC |
Ärztliche Bescheinigungen |
x |
x |
x |
x |
|
BEFU |
Ergebnisse Diagnostik |
x |
x |
x |
|
|
|
Bestrahlungsdokumentation |
|
|
x |
|
|
|
Einweisungs- und Aufnahmedokumente |
|
|
x |
|
|
EINW |
Einwilligungen/Aufklärungen |
x |
x |
x |
x |
|
|
Ergebnisse Funktionsdiagnostik |
x |
|
x |
|
|
BILD |
Ergebnisse bildgebender Diagnostik |
x |
x |
x |
x |
|
FALL |
Fallbesprechungen |
x |
x |
x |
|
|
FOTO |
Fotodokumentation |
x |
x |
x |
|
|
FPRO |
Therapiedokumentation |
x |
x |
x |
|
|
IMMU |
Ergebnisse Immunologie |
x |
|
x |
|
|
INTS |
Intensivmedizinische Dokumente |
x |
|
x |
|
|
KOMP |
Komplexbehandlungsbögen |
x |
|
x |
|
|
MEDI |
Medikamentöse Therapien |
x |
x |
x |
x |
|
MKRO |
Ergebnisse Mikrobiologie |
x |
x |
x |
x |
|
OPDK |
OP-Dokumente |
x |
x |
x |
|
|
ONKO |
Onkologische Dokumente |
x |
|
x |
|
|
PATH |
Pathologiebefundberichte |
x |
|
x |
|
|
|
Patienteneigene Dokumente |
|
|
|
|
|
|
|
x |
x |
x |
x |
|
PFLG |
Pflegedokumentation |
x |
|
x |
|
|
|
Patienteneinverständniserklärung |
Logical Observation |
|
|
|
|
|
Qualitätssicherung |
|
x |
x |
x |
x |
|
Rettungsdienstliche Dokumente |
|
x |
|
x |
|
|
|
x |
x |
x |
x |
|
|
Schwangerschafts- und Geburtsdokumentation |
x |
|
x |
|
|
|
Sozialdienstdokumente |
|
|
|
|
|
|
|
x |
x |
x |
x |
|
|
Transfusionsdokumente |
x |
x |
x |
|
|
|
Transplantationsdokumente |
x |
x |
x |
|
|
|
|
x |
x |
x |
x |
|
|
Verträge |
x |
x |
x |
|
|
|
Ergebnisse Virologie |
x |
x |
x |
|
|
WUND |
Wunddokumentation |
x |
x |
|
|