Elektronische Gesundheitskarte und Telematikinfrastruktur

Systemspezifisches Konzept

Anwendungen des
Versicherten (AdV)

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
15.05.2019
     
     

      
Status
      
Freigegeben für interne QS
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSysL_AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Die Änderungen zur letzten freigegebenen Version (Einarbeitung aus P17.1) sind gelb markiert.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einführung

1.1 Zielsetzung

Das vorliegende Dokument „Systemspezifisches Konzept Anwendungen des Versicherten (AdV)“ beschreibt die Fachanwendung AdV auf Systemebene im Kontext des Online-Rollout (Stufe 2.1) und bildet den Rahmen für die weiterführenden Konzepte und Spezifikationen des Projektes AdV.

Darüber hinaus erfolgt eine Zerlegung der Fachanwendung AdV in die zugehörigen Produkttypen. Die Schnittstellen zwischen den einzelnen Produkttypen werden spezifiziert.

Die Abbildung 1 zeigt schematisch die Dokumentenhierarchie im Projekt AdV, in welcher das systemspezifische Konzept AdV und die Konzepte sowie die Spezifikationen eingeordnet sind. Die Abbildung stellt nicht die vollständige Dokumentenhierarchie des Projekts Online-Rollout (Stufe 2.1) oder den Trace der Anforderungen dar.

Abbildung 1: Dokumentenlandkarte AdV

Kapitel 2 gibt einen Überblick über die Fachanwendung AdV. Es wird eine Übersicht über die notwendigen Produkttypen und deren Schnittstellen gegeben. Darüber hinaus wird ein Überblick über das Informationsmodell und das Berechtigungsmodell der Anwendungen der Versicherten gegeben.

In Kapitel 3 erfolgt eine detaillierte Beschreibung der Anwendungsfälle, die zur Erfüllung der fachlich-funktionalen Anforderungen identifiziert wurden. Das Konzept AdV definiert ein Set von Bausteinen bzw. Activities (AdV-ACT_*), die in der weiteren Beschreibung zu Basis-Anwendungsfällen (AdV-UC_*) zusammengesetzt werden. Die anschließende Beschreibung der fachlichen Anwendungsfälle setzt auf diese Basis-Anwendungsfälle auf und gibt eine Konfiguration vor, mit welchen Parametern die Basisanwendungsfälle ausgeführt werden sollen.

Die zur Ausführung der fachlichen Anwendungsfälle benötigten Operationen werden in Kapitel 4 dargestellt, sowie deren Eingangs- und Ausgangsparameter definiert.

Kapitel 5 beinhaltet die Systemzerlegung der Fachanwendung AdV in die zugehörigen Produkttypen. Die Fachanwendung AdV gliedert sich dabei in die Produkttypen AdV-Server und AdV-Terminal.

Das Kapitel 6 enthält das technische Informationsmodell der AdV.

Das Kapitel 7 gibt einen Überblick über die Zukunftsthemen der AdV.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von AdV-Produkten.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung im Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, 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.

Alle Festlegungen im Zusammenhang mit Anwendungen des Versicherten (AdV) stehen unter dem Vorbehalt, dass der Betrieb einer AdV-Umgebung unter noch festzulegenden Bedingungen erfolgt.

1.4 Abgrenzung des Dokuments

Innerhalb dieses Dokuments wird auf die technische Umsetzung zur Nutzung der Anwendungen des Versicherten eingegangen. Prozesse der Kostenträger und Leistungserbringer (z. B. Kartenherausgabe) sind nicht Bestandteil des systemspezifischen Konzeptes.

Für die Aspekte „Datenschutz“ und „Datensicherheit“ werden jeweils eigene systemspezifische Konzepte für die Fachanwendung AdV erstellt. Für die Sichten „Betrieb“ und „Test“ wird ein programmübergreifendes Konzept für den Online-Produktivbetrieb (Stufe 2.1) ausgearbeitet.

Zukunftsthemen werden mit Ausnahme der in Kapitel 7 genannten Ergänzungen zum Leistungsumfang an dieser Stelle nicht aufgenommen.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

1.5.1 Diagramme

Innerhalb von Diagrammen werden Objekte blau markiert, wenn sie im Geltungsbereich der Fachanwendung AdV liegen, und rosa, wenn es sich um Objekte aus dem erweiterten Leistungsumfang handelt.

2 Systemüberblick

2.1 Komponentenmodell AdV

Für die eigenständige Nutzung durch den Versicherten in einer Umgebung im Auftrag der Kostenträger und der privaten Umgebung des Versicherten (@home) stehen User-Interface-Komponenten zur Verfügung, welche über einen Zugang zur Telematikinfrastruktur verfügen.

In der Kostenträgerumgebung, welche die @home-Umgebung einschließt, gliedert sich die Fachanwendung AdV in die Produkttypen KTR-AdV-Terminal und KTR-AdV. Der Produkttyp KTR-AdV wird dabei gebildet aus einem AdV-Server mit zugehöriger AdV-App.

2.2 Schnittstellen

Abbildung 3: AdV-Schnittstellen in der Kostenträger-Umgebung und @home

Die AdV in der Umgebung im Auftrag der Kostenträger und @home nutzt die dargestellten Schnittstellen zur Anbindung an zentrale Dienste der TI-Plattform und Fachdienste. Die Schnittstelle zwischen AdV-Server und zugehöriger App wird nicht näher beschrieben, da AdV-Server und die zugehörige AdV-App im Verbund als Produkttyp KTR-AdV realisiert werden sollen.

Für den Zugriff auf die Karten der TI-Plattform (eGK und SM-B) in der AdV in einer Umgebung im Auftrag der Kostenträger müssen der AdV-Server und die AdV-App Leistungen der TI-Plattform bereitstellen. Die Schnittstellen sollen analog zu den durch die dezentrale TI-Plattform bereitgestellten Schnittstellen realisiert werden. Über diesen Plattformadapter können die Fachmodule der Fachanwendungen AMTS, NFDM und VSDM ihre fachlichen Anwendungsfälle in der KTR-Umgebung abbilden. Die Fachlogik des Fachmodules einer Fachanwendung kann hierbei auf ein clientseitiges und serverseitiges Modul verteilt werden.

Für die Nutzung der AdV in einer Umgebung im Auftrag der Kostenträger soll die AdV-App in ihrer lokalen Ausführungsumgebung (d. h. auf dem Computer des Versicherten oder auf einem KTR-AdV-Terminal) eine Schnittstelle anbieten, über welche der Versicherte die Anwendungsfälle der AdV in der App selbst oder mit einem der gängigen Browser initiiert. Das Auslesen der eGK soll in dieser Umgebung über eine standardisierte API (z. B. eCard-API-Anbindung) und einen Standard-Kartenleser erfolgen.

2.3 Akteure und Berechtigungen

Ein Akteur ist eine gewöhnlich außerhalb des betrachteten bzw. zu realisierenden Systems liegende Einheit, die an der in einem Anwendungsfall beschriebenen Interaktion mit dem System beteiligt ist.

Ein Akteur kann ein Mensch sein, z. B. ein Benutzer, ebenso aber auch ein anderes technisches System. Bei Akteuren werden nicht die konkreten beteiligten Personen unterschieden, sondern ihre Rollen, die sie im Kontext des Anwendungsfalls einnehmen.

Der Versicherte, der von einem Kostenträger eine eGK erhalten hat, ist Akteur in der AdV-Umgebung.

Ärzte, Mitarbeiter medizinischer Institutionen, Apotheker, Mitarbeiter Apotheke sowie Mitarbeiter Institution des Kostenträgers sind in ihrer Rolle keine Akteure in der AdV-Umgebung.

Das Clientsystem bzw. Administratoren können administrative Operationen ausführen. Diese werden nicht als Anwendungsfälle modelliert.

Der Umfang der Anwendungsfälle, welche durch den Versicherten ausgeführt werden können, variiert zwischen den AdV-Umgebungen.

Die Berechtigungsregeln für die Anwendungsfälle werden von der jeweiligen Fachanwendung festgelegt. Auf Grundlage des aktuellen Standes sind dies die Fachanwendungen NFDM, AMTS und VSDM.

2.4 Überblick Informationsmodell

Die fachanwendungsspezifischen Informationsmodelle werden in den Spezifikationen der Fachanwendungen beschrieben. Die Dokumente, in denen die Informationsmodelle der Fachanwendungen beschrieben werden, sind in TAB_ADV_091 gelistet.

Neben den fachanwendungsspezifischen Informationsobjekten gibt es im Kontext der AdV folgende Informationsobjekte:

• Protokollierung von eGK-Zugriffen
• Verwaltung freiwilliger Anwendungen mit den zugehörigen Verweisen

PIN-Objekte und Zertifikate werden an dieser Stelle als Eigenschaften der eGK behandelt, nicht als Informationsobjekte der eGK, auf die sich Datenschutzrechte der Versicherten beziehen.

Die Konfiguration der Zugriffe auf Daten des AdV-Informationsmodells wird in Kapitel 6.2 behandelt.

3 Anwendungsfälle

Die vom Versicherten in der AdV ausführbaren Anwendungsfälle lassen sich in fachanwendungsspezifische Funktionen und Kernfunktionen einteilen.

Fachanwendungsspezifische Funktionen werden fachlich durch Fachanwendungen (z. B. NFDM) verantwortet. Die AdV stellt eine Ausführungsumgebung bereit.

Kernfunktionen werden unabhängig von den Fachanwendungen bereitgestellt und dienen der allgemeinen Verwaltung von Datenobjekten auf der eGK.

Abbildung 4: Gliederung der Anwendungsfälle für den Versicherten

Ein Teil der Funktionen (z. B. Anwendungsfälle zum Patientenfach) werden erst in einer späteren Ausbaustufe der AdV realisiert. Sie sind in Form eines Ausblicks in Kapitel 7 aufgeführt, ohne dass Anwendungsfälle ausdifferenziert werden.

Für jeden Anwendungsfall erfolgt eine Detaillierung mittels einer tabellarischen Anwendungsfallbeschreibung.

Abbildung 5: Übersicht Use Cases AdV

3.1 Vorbedingungen in den Umgebungen

Damit die Anwendungsfälle ausgeführt werden können, müssen neben den Diensten der TI-Plattform und den Fachdiensten der weiteren Fachanwendungen die folgenden Komponenten in den Umgebungen im Auftrag der Kostenträger betriebsbereit sein:

• ein KTR-AdV-Terminal bzw. ein Gerät des Versicherten als Ausführungsumgebung für die AdV-App
• eine AdV-App mit Zugriff auf den AdV-Server
• ein AdV-Server
• ein Kartenterminal zur Anbindung der eGK
• eine SM-B für KTR-AdV (Profil 1)
• eine eGK

Das SM-B kann, wenn nicht anders beschrieben, in den Ausprägungen SMC-B oder in einem HSM genutzt werden.

Für die folgende Beschreibung der Anwendungsfälle wird angenommen, dass diese Vorbedingungen in den Umgebungen erfüllt sind.

3.2 Übergreifende Erfolgsbedingungen

Folgende Erfolgsbedingungen müssen für alle Operationen erfüllt sein, damit sie erfolgreich zu Ende geführt werden können. Wenn die Erfolgsbedingungen nicht erfüllt sind, so muss die Operation mit einer Fehlermeldung abbrechen.

Die Entsperrung der Gesundheitsanwendung ist durch eine Onlineprüfung und Aktualisierung im Anwendungsfall „Versichertenstammdaten von der eGK lesen“ möglich.

Damit soll sichergestellt werden, dass die Fachanwendung AdV nicht auf KVK, ec-Karten oder sonstigen Karten operiert.

Die beteiligten Smartcards sind die eGK und SM-B.

Der Aufbau der Systemmeldungen wird durch das übergeordnete Konzept zum einheitlichen Fehlermanagement bestimmt und die jeweiligen Inhalte in den Spezifikationen der AdV-Produkttypen und weiteren Fachmodulen festgelegt.

3.3 PIN-Handling

Der Zugriff des Versicherten auf die Daten der eGK (außer Persönliche Versichertendaten (PD) und Allgemeine Versicherungsdaten (VD)) ist mittels PIN-Schutz abgesichert. Die PIN.CH ist das PIN-Objekt, dessen Geheimnis durch mehrere Multireferenz-PINs, z. B. MRPIN.NFD und MRPIN.home, genutzt wird. In der Objektsystemspezifikation der eGK [gemSpec_eGK_ObjSys] ist festgelegt, welche Datenobjekte durch welche PINs freigeschaltet werden.

Die Verifikation der PIN.CH dient dem Schutz vor Missbrauch der eGK und ermöglicht das Protokollieren für die fachlichen Anwendungsfälle.

Weitere PIN-Abfragen erfolgen im Zusammenhang mit den Anwendungsfällen.

Wenn die Freischaltung eines Bereiches der eGK erfolgt ist, sollen die weitergehenden Aktionen innerhalb dieses Bereiches so optimiert werden, dass keine unnötigen Mehrfacheingaben der PIN erforderlich sind. Dabei kann der einmal für ein Datenobjekt erlangte erhöhte Sicherheitszustand der eGK genutzt werden.

In der Umgebung des Versicherten (@home) wird die MRPIN.home nicht genutzt. Die Freischaltung des Zugriffs auf die Datenobjekte wird über die AdV-App und den AdV-Server umgesetzt. Die im Anforderungskatalog AdV für den Zugriff mittels MRPIN.home vorgesehenen funktionalen Anforderungen werden dabei vollumfänglich von AdV-App und AdV-Server realisiert. Aufgrund der Anbindung der AdV-App an den AdV-Server wird für das Erreichen der Zugriffsberechtigung auf die Daten der eGK ein C2C mit einer SM-B die das Profil für @home abbildet und die Eingabe der PIN.CH bzw. der PIN der Fachanwendung genutzt. Auf diese Weise kann auch in der Umgebung des Versicherten u. a. die durch den Datenschutz geforderte Protokollierung von Datenzugriffen auf der eGK umgesetzt werden.

3.4 Zugriffsprotokollierung auf der eGK

Die Fachanwendung AdV und die weitere Fachanwendungen protokollieren Zugriffe auf die Daten der eGK in EF.Logging.

Dies kann beispielsweise durch die Spezifikation gesonderte Flags für Type of Access erfolgen.

Die AdV-Umgebung wird durch die SM-B identifiziert.

Führt der Versicherte in der AdV mit einer eGK G2 mehrere Anwendungsfälle nacheinander aus, dann muss in jedem Anwendungsfall die PIN des Versicherten zur Authentifizierung eingegeben werden. Dies gilt insbesondere, wenn mehrere Anwendungsfälle einer Fachanwendung ausgeführt werden. Für die Optimierung der Benutzerführung soll bei Nutzung der eGK der Generation 2 nur ein Eintrag im Zugriffsprotokoll am Beginn der AdV-Sitzung auf der eGK für alle ausgeführten Anwendungsfälle angelegt werden. Die Zugriffe auf die Daten der eGK in den einzelnen Anwendungsfällen werden nicht auf der eGK geloggt.

3.5 Basis-Anwendungsfälle für die Anwendungsverwaltung

In der Systemlösung werden für den Zugriff auf die Daten von Anwendungen auf der eGK Basis-Anwendungsfälle modelliert. Mit den Basis-Anwendungsfällen können Daten von der eGK gelesen, auf die eGK geschrieben, auf der eGK gelöscht, sowie freiwillige Anwendungen deaktiviert und wieder aktiviert werden.

Abbildung 6: Übersicht Basis-Anwendungsfälle AdV

Basis-Anwendungsfälle sind verallgemeinerte Anwendungsfälle für den Datenzugriff auf der eGK. Folgende Aktivitäten können in ihnen aufgerufen werden und sind somit mögliche Bausteine aus denen sich ein Anwendungsfall zusammensetzt:

• AdV-ACT_51: Gültigkeit der eGK prüfen
• AdV-ACT_52: Version der eGK prüfen
• AdV-ACT_53: Echtheit der beteiligten Karten durch C2C prüfen
• AdV-ACT_54: Authentifizierung des Versicherten mittels PIN-Verifikation einholen
• AdV-ACT_55: Daten lesen
• AdV-ACT_56: Daten schreiben
• AdV-ACT_57: Daten löschen
• AdV-ACT_58: Applikation deaktivieren
• AdV-ACT_59: Applikation aktivieren
• AdV-ACT_60: Aufruf einer fachanwendungsspezifischen Operation
• AdV-ACT_61: Datenzugriff protokollieren

Die in Abbildung 5 „Übersicht Use Cases AdV“ dargestellten fachanwendungsspezifischen Anwendungsfälle werden mittels der Basis-Anwendungsfälle umgesetzt. Dafür wird für jeden fachanwendungsspezifischen Anwendungsfall eine Konfiguration angegeben. In der Konfiguration wird festgelegt, welche Bausteine in welcher Reihenfolge mit welchen Parametern ausgeführt werden.

Bausteine können ein- oder mehrmals in einem Anwendungsfall aufgerufen werden.

Wenn die Ergebnisse von Bausteinen deterministisch und reproduzierbar sind, d. h. keine fachliche, zeitliche oder andere Abhängigkeit zwischen den Ergebnissen der Bausteine besteht, dann sollen diese mit dem Ziel einer besseren Performance parallelisiert abgearbeitet werden.

Der Baustein AdV-ACT_60 bietet die Möglichkeit über eine interne Schnittstelle die Operation eines weiteren Fachmoduls aufzurufen. Falls ein fachanwendungsspezifisches Fachmodul (NFDM, AMTS, VSDM) eine Operation für den durchzuführenden Anwendungsfall bereitstellt, wird diese genutzt. In dem Fall kapselt der Basis-Anwendungsfall die Aufrufe von Operationen der fachanwendungsspezifischen Interfaces (I_NFD_Management, I_VSDService, etc.). Die Kommunikation von AdV mit einem weiteren Fachmodul ist von der beteiligten Fachanwendung vorzusehen.

Beim Aufruf einer Operation zur Initiierung eines Basis-Anwendungsfalls an der Außenschnittstelle  der AdV-App muss eine spezifische Konfiguration referenziert werden, mit welcher der Basis-Anwendungsfall ausgeführt wird. Dafür wird der Identifier der Anwendung als Parameter angegeben.

Die Konfiguration für einen fachanwendungsspezifischen Anwendungsfall wird durch die beteiligten Fachanwendungen spezifiziert. D. h. die Fachanwendungen legen fest, welche Bausteine der Basis-Anwendungsfälle sie für ihren jeweiligen Anwendungsfall benötigen bzw. nutzen.

Im Kapitel 3.5.1 werden die Bausteine und in den folgenden Kapiteln ab 3.5.2 die Basis-Anwendungsfälle beschrieben. In den Kapiteln 3.6 und 3.7 werden die Konfigurationen der Basis-Anwendungsfälle für die Umsetzung der fachlichen Anwendungsfälle beschrieben.

3.5.1 Bausteine der Basis-Anwendungsfälle

3.5.1.1 Aktivität AdV-ACT_51: Gültigkeit der eGK prüfen

Die Aktivität prüft die Gültigkeit der eGK. Die eGK ist gültig, wenn der HCA-Ordner der eGK aktiv (nicht gesperrt) ist und das AUT-Zertifikat der eGK offline (Ablaufdatum des Authentifizierungszertifikates, rechnerische Prüfung des Authentifizierungszertifikates) und online (Ergebnis des Zertifikatsvalidierungsdienstes) gültig ist.

Funktionale Ergänzungen

Wird die Aktivität im Rahmen eines Basis-Anwendungsfalls aufgerufen, muss über die Konfiguration festgelegt werden, ob der Anwendungsfall fortgesetzt oder abgebrochen wird, falls die Online-Prüfung des Gültigkeitsstatus nicht durchgeführt werden konnte.

Über die Konfiguration der Aktivität kann die Prüfung darauf beschränkt werden, ob der HCA-Ordner der eGK aktiv ist. Als Default wird die vollständige Prüfung durchgeführt.

3.5.1.2 Aktivität AdV-ACT_52: Version der eGK prüfen

Die Aktivität liest die Version der eGK von der Karte und prüft diese gegen in der Konfiguration vorgegebenen Werte.

Die in der Konfiguration vorgegebenen Werte geben einen Bereich von Versionen der eGK an, für den das Prüfergebnis positiv ist.

3.5.1.3 Aktivität AdV-ACT_53: Echtheit der beteiligten Karten durch C2C prüfen

Die Aktivität führt eine Card-to-Card-Authentisierung zwischen zwei Smartcards durch. Die eGK (Target) wird mittels einer SM-B (Source) mit dem „gegenseitig“-Mode freigeschaltet. Bei der SM-B kann es sich um eine SMC-B oder einem HSM-B handeln.

3.5.1.4 Aktivität AdV-ACT_54: Authentifizierung des Versicherten mittels PIN-Verifikation einholen

Die Aktivität veranlasst eine Aufforderung am Kartenterminal zur Eingabe einer PIN. Das Kartenterminal übermittelt die PIN zum Verifizieren an die eGK. Das Prüfergebnis gibt Aufschluss über Erfolg oder Misserfolg der PIN-Verifikation und ggf. die Anzahl der verbleibenden Versuche zur PIN-Eingabe.

In der Konfiguration der Aktivität wird festgelegt, welche PIN abgefragt wird.

3.5.1.5 Aktivität AdV-ACT_55: Daten lesen

Die Aktivität liest Daten von der eGK.

In der Konfiguration der Aktivität wird die Datei (Elementary File (EF)) festgelegt, aus dem die Daten gelesen werden.

3.5.1.6 Aktivität AdV-ACT_56: Daten schreiben

Die Aktivität schreibt Fachdaten auf die eGK.

In der Konfiguration der Aktivität wird die Datei (EF) festgelegt, in dem die Daten geschrieben werden.

3.5.1.7 Aktivität AdV-ACT_57: Daten löschen

Die Aktivität löscht Fachdaten von der eGK.

In der Konfiguration der Aktivität wird die Datei (EF) festgelegt, aus dem die Daten gelöscht werden.

3.5.1.8 Aktivität AdV-ACT_58: Applikation deaktivieren

Die Aktivität setzt den Status eines Ordners auf der eGK auf inaktiv.

Die Funktionalität des Deaktivierens des Ordners einer freiwilligen Fachanwendung wird mit der Operation I_KV_Card_Operations::deactivate_Application als Plattformleistung der Basis-TI zur Verfügung gestellt.

In der Konfiguration der Aktivität wird der Ordner (DF) festgelegt, dessen Status geändert wird.

3.5.1.9 Aktivität AdV-ACT_59: Applikation aktivieren

Die Aktivität setzt den Status eines Ordners auf der eGK auf aktiv.

Die Funktionalität des Aktivierens des Ordners einer freiwilligen Fachanwendung wird mit der Operation I_KV_Card_Operations::activate_Application als Plattformleistung der Basis-TI zur Verfügung gestellt.

In der Konfiguration der Aktivität wird der Ordner (DF) festgelegt, dessen Status geändert wird.

3.5.1.10 Aktivität AdV-ACT_60: Aufruf einer fachanwendungsspezifischen Operation

Die Aktivität ruft die Operation eines weiteren Fachmodules über eine interne Schnittstelle auf.

Funktionale Ergänzungen

Das Ergebnis der aufgerufenen Operation wird durch das Fachmodul AdV unverändert an das AdV-Terminal weitergeleitet.

3.5.1.11 Aktivität AdV-ACT_61: Datenzugriff protokollieren

Die Aktivität schreibt einen Protokolleintrag auf die eGK. Voraussetzung ist, dass durch eine vorangegangene Card-to-Card-Authentisierung und eine Verifikation der PIN.CH bereits der benötige Sicherheitszustand hergestellt wurde.

Funktionale Ergänzungen

Aus dem Protokolleintrag muss ersichtlich sein, dass der Datenzugriff in einer AdV-Umgebung stattfand.

3.5.2 Daten von eGK lesen

Der Anwendungsfall stellt eine generische Funktionalität zum Lesen von Daten einer Anwendung von der eGK zu Verfügung. Für die Verwendung muss eine Konfiguration festgelegt werden, in der angegeben wird, auf welche Datenobjekte zugegriffen und welche Bausteine im Ablauf des Anwendungsfalls mit welchen Parametern ausgeführt werden.

Abbildung 16: Darstellung AdV-UC_11: „Daten von eGK lesen“

Tabelle 2: TAB_ADV_002 Anwendungsfall AdV-UC_11

Funktionale Ergänzungen

Die Berechtigung zum Lesen von Anwendungsdaten wird von den Fachanwendungen und dem Objektsystem der eGK gesteuert.

3.5.3 Daten auf eGK schreiben

Der Anwendungsfall stellt eine generische Funktionalität zum Schreiben von Daten einer Anwendung auf die eGK zu Verfügung.

Abbildung 17: Darstellung AdV-UC_12: „Daten auf eGK schreiben“

Tabelle 3: TAB_ADV_003 Anwendungsfall AdV-UC_12

3.5.4 Daten auf eGK löschen

Der Anwendungsfall stellt eine generische Funktionalität zum Löschen von Daten einer Anwendung von der eGK zu Verfügung.

Abbildung 18: Darstellung AdV-UC_13: „Daten auf eGK löschen“

Tabelle 4: TAB_ADV_004 Anwendungsfall AdV-UC_13

3.5.5 Daten einer Anwendung auf eGK verbergen

Der Versicherte kann die Daten einer freiwilligen Anwendung verbergen. Durch das Verbergen ist nur noch für den Versicherten selbst erkennbar, dass die freiwillige Anwendung eingerichtet ist. Die Daten der Fachanwendung sind weiterhin auf der eGK vorhanden, können aber weder angezeigt noch verändert werden.

Technisch wird der Zustand durch den Status des Ordners der freiwilligen Anwendung (z. B. DF.NFD) abgebildet.

Abbildung 19: Darstellung AdV-UC_14: „Anwendung auf eGK deaktivieren“

Tabelle 5: TAB_ADV_005 Anwendungsfall AdV-UC_14

3.5.6 Verborgene Daten auf eGK wieder sichtbar machen

Der Versicherte kann nach vorherigem Verbergen die Daten einer freiwilligen Anwendung wieder sichtbar machen.

Technisch wird der Zustand durch den Status des Ordners der freiwilligen Anwendung (z. B. DF.NFD) abgebildet.

Abbildung 20: Darstellung AdV-UC_15: „Anwendung auf eGK reaktivieren“

Tabelle 6: TAB_ADV_006 Anwendungsfall AdV-UC_15

3.5.7 Daten von eGK zu eGK kopieren

Da die TI-Plattform in dem für ORS2.1 geplanten Ausbau nicht über das Leistungsmerkmal des Daten- und Berechtigungserhalts bei Kartenwechsel verfügt, wird diese Funktionalität direkt in den AdV-Komponenten implementiert. Eine durch die TI-Plattform bereitgestellte Lösung kann diese Projektumsetzung später ersetzen.

Wenn die Krankenkasse einen Kartentausch initiiert und der Versicherte eine neue eGK erhält, soll die Möglichkeit bestehen, die Daten freiwilliger Anwendungen von der alten auf die neue Karte zu übertragen.

Der Anwendungsfall stellt eine Funktionalität zum Kopieren von Daten der Anwendungen von der Quell-eGK auf ein Ziel-eGK zur Verfügung. Hierbei werden sowohl die Anwendungsdaten als auch die Informationen zur Einwilligung übertragen.

Abbildung 21: Darstellung AdV-UC_16: „Daten von eGK zu eGK kopieren“

Tabelle 7: TAB_ADV_007 Anwendungsfall AdV-UC_16

Funktionale Ergänzungen

Die Prüfung der Gültigkeit der Quell-eGK wird darauf beschränkt, ob der HCA-Ordner der eGK aktiv ist.

Für die Umsetzung des Anwendungsfalls sind aus Gründen des Datenschutzes folgende Anforderungen zu erfüllen:

3.6 Anwendungsfälle zu Kernfunktionen

3.6.1 Protokolldaten Management

3.6.1.1 Zugriffsprotokolle der eGK lesen

Mit diesem Anwendungsfall werden dem Versicherten die auf der eGK gespeicherten Protokolleinträge angezeigt.

Tabelle 8: TAB_ADV_008 Anwendungsfall AdV-UC_21

Tabelle 9: TAB_ADV_009 Konfiguration AdV-UC_21

Die Operation zum Anwendungsfall liefert eine Liste von Einträgen des Zugriffsprotokolls zurück. Eine Sortierung oder eine Gruppierung der Einträge, z. B. nach Anwendungen, kann in der GUI erfolgen.

3.6.2 PIN Management

Abbildung 22: Übersicht Anwendungsfälle PIN-Management

Diese Anwendungsfälle stellen dem Versicherten Funktionalitäten zur Verwaltung seiner PIN-Objekte zur Verfügung. Ferner soll der Versicherte den aktuellen Status seiner PIN-Objekte einsehen können.

3.6.2.1 PIN ändern

Der Versicherte kann die im Zusammenhang mit der eGK genutzten PINs ändern. Hierzu wird er bei der Ausführung des Anwendungsfalls aufgefordert, zunächst die bisher gültige und anschließend seine neue PIN am Kartenterminal einzugeben. Mit einer wiederholten Eingabe seiner neuen PIN bestätigt er die neue PIN.

Tabelle 10: TAB_ADV_010 Anwendungsfall AdV-UC_01

Funktionale Ergänzungen

Das Objektsystem der eGK steuert, für welche PIN-Objekte der Anwendungsfall durchgeführt werden kann. Auf einer eGK der Generation 2 und höher können die PIN Objekte PIN.CH, PIN.QES und PIN.AMTS_REP durch den Versicherten geändert werden. Um die PIN.CH zu ändern, kann auch eine MRPIN beim Aufruf des Anwendungsfalls referenziert werden.

Die Funktionalität des Änderns von PIN-Objekten wird als Plattformleistung der Basis-TI zur Verfügung gestellt.

Abbildung 23: SD PIN ändern

3.6.2.2 PIN der eGK mit PUK entsperren

Ist eine PIN auf der eGK nach drei Fehleingaben gesperrt, kann die PIN mit diesem Anwendungsfall wieder freigeschaltet werden. Der Versicherte wird aufgefordert seinen Personal Unblocking Key (PUK) und eine neue PIN am Kartenterminal einzugeben.

Tabelle 11: TAB_ADV_011 Anwendungsfall AdV-UC_02

Funktionale Ergänzungen

Das Objektsystem der eGK steuert, für welche PIN-Objekte der Anwendungsfall durchgeführt werden kann. Auf einer eGK der Generation 2 und höher können die PIN-Objekte PIN.CH und PIN.QES mit ihrer PUK entsperrt werden. Für PIN.CH wird nach dem Entsperren die Eingabe einer neuen PIN gefordert. Für PIN.QES wird keine neue PIN gefordert. Das Entsperren der AMTS-Vertreter-PIN PIN.AMTS_REP erfolgt mit der PIN des Versicherten.

Die Funktionalität des Entsperrens von PIN-Objekten wird als Plattformleistung der Basis TI zur Verfügung gestellt.

Abbildung 24: SD PIN auf eGK entsperren

3.6.2.3 PIN für Fachanwendung einschalten

Wenn die Multireferenz-PIN einer Fachanwendung deaktiviert ist, dann kann der Versicherte diese PIN mit diesem Anwendungsfall aktivieren. Der Versicherte wird dafür zur Eingabe seiner PIN am Kartenterminal aufgefordert. Zuvor muss der Versicherte darauf hingewiesen werden, dass mit dem Einschalten der PIN für diese Fachanwendung, zusätzliche PIN-Eingaben notwendig werden, die einem höheren Schutz der Daten dienen.

Tabelle 12: TAB_ADV_012 Anwendungsfall AdV-UC_03

Funktionale Ergänzungen

Das Objektsystem der eGK steuert, für welche PIN-Objekte der Anwendungsfall durchgeführt werden kann. Auf einer eGK G2 können die PIN-Objekte MRPIN.NFD und MRPIN.DPE aktiviert werden. Ab einer eGK G2.1 ist der Anwendungsfall auch mit der MRPIN.AMTS durchführbar.

Die Funktionalität der Aktivierung von PIN-Objekten wird in ORS2.1 als Plattformleistung der Basis-TI zur Verfügung gestellt.

3.6.2.4 PIN für Fachanwendung ausschalten

Um die Anzahl der PIN-Eingaben pro Kartensteckzyklus zu minimieren, kann der Versicherte für bestimmte Fachanwendungen die Multireferenz-PIN für diese Fachanwendung deaktivieren. Der Versicherte wird dafür zur Eingabe seiner PIN am Kartenterminal aufgefordert. Zuvor muss der Versicherte darauf hingewiesen werden, dass mit dem Ausschalten der PIN für diese Fachanwendung, zusätzliche PIN-Eingaben, die einem höheren Schutz der Daten dienen, entfallen.

Tabelle 13: TAB_ADV_013 Anwendungsfall AdV-UC_04

Funktionale Ergänzungen

Das Objektsystem der eGK steuert, für welche PIN-Objekte der Anwendungsfall durchgeführt werden kann. Auf einer eGK G2 können die PIN-Objekte MRPIN.NFD und MRPIN.DPE deaktiviert werden. Ab einer eGK G2.1 ist der Anwendungsfall auch mit der MRPIN.AMTS durchführbar.

Die Funktionalität der Deaktivierung von PIN-Objekten wird in ORS2.1 als Plattformleistung der Basis-TI zur Verfügung gestellt.

3.6.3 Übergreifende Funktionen

3.6.3.1 Echtheit und Gültigkeit der eGK prüfen

Mit diesem Anwendungsfall werden die Echtheit und die technische Nutzbarkeit der eGK geprüft. Die Authentizität und Echtheit der eGK wird durch ein Card-to-Card mit der SM-B geprüft. Die eGK ist gültig, wenn der HCA-Ordner der eGK aktiv (nicht gesperrt) und das AUT-Zertifikat der eGK gültig ist.

Tabelle 14: TAB_ADV_014 Anwendungsfall AdV-UC_23

3.6.3.2 Mit eGK verschlüsseln

In diesem Anwendungsfall kann der Versicherte ein Dokument mit dem öffentlichen Schlüssel seiner eGK verschlüsseln. Dabei soll ein hybrides Verschlüsselungsverfahren verwendet werden, in welchem das eigentliche Dokument aus Performancegründen mit einem symmetrischen Schlüssel verschlüsselt und der verwendete Schlüssel anschließend im asymmetrischen Verfahren mit dem öffentlichen Schlüssel eines auf der eGK vorhandenen Zertifikats verschlüsselt.

Tabelle 15: TAB_ADV_015 Anwendungsfall AdV-UC_25

3.6.3.3 Mit eGK entschlüsseln

Mit diesem Anwendungsfall kann ein konform zum Anwendungsfall AdV-UC_25 verschlüsseltes Dokument entschlüsselt werden. Hierzu wird der zur Verschlüsselung verwendete symmetrische Schlüssel mit dem privaten Schlüssel der eGK entschlüsselt und anschließend das Dokument mit dem symmetrischen Schlüssel entschlüsselt.

Tabelle 16: TAB_ADV_016 Anwendungsfall AdV-UC_26

3.6.3.4 Benutzerauthentifizierung mit eGK

Die Benutzerauthentifikation mit der eGK stellt Funktionen zur Verfügung, um Versicherte gegenüber Diensten oder Portalen zu authentifizieren. Versicherte werden dabei direkt über die eGK authentisiert.

Im technischen Ablauf der Benutzerauthentifizierung gegenüber einem Dienst oder Portal wird auf einem Authentisierungsrequest eine Signatur zwecks Authentisierung erstellt. Mit diesem Anwendungsfall kann der Versicherte einen Authentisierungsrequest mit dem privaten AUT-Schlüssel oder AUTN-Schlüssel seiner eGK signieren.

Tabelle 17: TAB_ADV_017 Anwendungsfall AdV-UC_27

3.6.3.5 Zertifikat von eGK lesen

Mit diesem Anwendungsfall kann der Versicherte das ENC bzw. ENCV-Zertifikat der eGK auslesen. Das exportierte Zertifikat kann bspw. in einer externen Verschlüsselungssoftware genutzt werden.

Zukunftsthema: Falls eine eGK über ein qualifiziertes Signaturzertifikat C.QES (oder ggf. weitere Attributzertifikate) verfügt, können Attributzertifikaten ausgelesen werden, um eine anwendungsfallbezogene Auswahl unter diesen Attributzertifikaten vorzunehmen, die beim Signieren von Dokumenten mitgegeben werden, je nachdem, welche Attributzertifikate für das zu signierende Dokument passend sind.

Tabelle 18: TAB_ADV_018 Anwendungsfall AdV-UC_24

3.6.3.6 Datenübertragung bei Kartentausch

Mit diesem Anwendungsfall kann der Versicherte bei Austausch seiner eGK die Daten der medizinischen Fachanwendungen von der alten auf die neue eGK übertragen.

Tabelle 19: TAB_ADV_057 Anwendungsfall AdV-UC_28

3.6.4 Einwilligungen und Verweise

Die in diesem Abschnitt dargestellten Anwendungsfälle von GDD sind für die Verwendung auf der eGK noch nicht abschließend spezifiziert. Daher erfolgt eine Umsetzung in den Produkttypen der AdV im aktuellen Stand nicht.

NFDM und eMP/AMTS speichern Informationen zur Einwilligung des Versicherten in die Nutzung dieser Fachanwendung in ihren Anwendungs-Ordnern (z. B. DF.AMTS/EF.EinwilligungAMTS). Das Verwalten von Einwilligungen dieser Fachanwendungen sind fachanwendungsspezifische Anwendungsfälle (vgl. 3.7.2, 3.7.3 und 4).

Darüber hinaus können auf der eGK Informationen zur Einwilligung in die Nutzung in weitere freiwillige Anwendungen gespeichert werden. Die Daten zu den weiteren freiwilligen Anwendungen sind nicht auf der eGK abgelegt. Die Einwilligungseinträge dokumentieren, dass der Versicherte die Einwilligung erklärt hat.

Informationen über die Speicherorte der Daten der freiwilligen Anwendungen, die nicht auf der eGK gespeichert werden, sind in EF.Verweis abgelegt.

Auf der eGK können in EF.Einwilligung zehn Einwilligungen in weitere freiwillige Anwendungen gespeichert werden. Mit diesen Einträgen in EF.Einwilligung korrespondieren zehn Verweise für diese Anwendungen in EF.Verweis. Die Anwendungsfälle zum Verwalten der Einwilligungen betrachten die Einwilligungen und die korrespondierenden Verweise gemeinsam.

3.6.4.1 Einwilligungen und Verweise von der eGK lesen

Mit diesem Anwendungsfall werden dem Versicherten die auf der eGK in der Datei EF.Einwilligung gespeicherten Einwilligungen sowie die zugehörigen Verweise aus EF.Verweis angezeigt (siehe Kapitel 6.2.2).

Tabelle 20: TAB_ADV_019 Anwendungsfall AdV-UC_30

Tabelle 21: TAB_ADV_020 Konfiguration AdV-UC_30

3.6.4.2 Verweis auf der eGK schreiben

Es wird der Verweis für eine freiwillige Anwendung auf die eGK geschrieben.

Tabelle 22: TAB_ADV_021 Anwendungsfall AdV-UC_32

Tabelle 23: TAB_ADV_022 Konfiguration AdV-UC_32

3.6.4.3 Einwilligung und Verweis auf der eGK löschen

Mit diesem Anwendungsfall kann der Versicherte eine auf der eGK in der Datei EF.Einwilligung gespeicherte Einwilligung in eine weitere freiwillige Anwendung löschen.

Jede Einwilligung in eine weitere freiwillige Anwendung muss einzeln gelöscht werden. Dabei muss auch der korrespondierende Verweis in EF.Verweis gelöscht werden.

Tabelle 24: TAB_ADV_023 Anwendungsfall AdV-UC_31

Tabelle 25: TAB_ADV_024 Konfiguration AdV-UC_31

3.7 Fachanwendungsspezifische Anwendungsfälle

Fachanwendungen müssen für die von ihnen verantworteten Daten eine fachliche Konzeption und technische Umsetzung für die erweiterten Verfahren und Lösungen zur Wahrnehmung der Rechte des Versicherten bereitstellen.

Die AdV-Lösungen bieten eine Umgebung für die Umsetzung dieser fachanwendungsspezifischen Anwendungsfälle. Die Fachlichkeit wird durch die Fachanwendungen verantwortet.

Die Basis-Anwendungsfälle bieten die Möglichkeiten, Operationen von Fachmodulen der Fachanwendungen aufzurufen, um den Ablauf des Anwendungsfalls zu steuern (siehe Kapitel 3.5.1.10 Aktivität AdV-ACT_60: Aufruf einer fachanwendungsspezifischen Operation). Hierbei kapselt die Fachanwendung AdV die Aufrufe an die weiteren Fachmodule, in dem der Request des AdV-Clientsystem empfangen, die Ausführung an das zuständige Fachmodul delegiert und anschließend das Ergebnis an das AdV-Clientsystem zurückgegeben wird.

Abbildung 25: Übersicht fachanwendungsspezifische Anwendungsfälle

3.7.1 VSDM

3.7.1.1 Versichertenstammdaten von der eGK lesen

Mit diesem Anwendungsfall werden dem Versicherten die auf der eGK gespeicherten Versichertenstammdaten (VSD) angezeigt. Es wird eine Onlineprüfung und bei Vorhandensein eines Aktualisierungsauftrages ein Update durchgeführt.

Es gelten die übergreifenden Anforderungen der Fachanwendung VSDM aus [gemSysL_VSDM].

Abbildung 26: Darstellung AdV-UC_101: „VSD von eGK lesen“

Tabelle 26: TAB_ADV_025 Anwendungsfall AdV-UC_101

Tabelle 27: TAB_ADV_026 Konfiguration AdV-UC_101

Die Operation I_VSDService.ReadVSDAdV ist in [gemSysL_VSDM] beschrieben.

3.7.2 NFDM

Die Anwendungsfälle für das Notfalldaten-Management basieren auf der Beschreibung der fachlichen und funktionalen Abläufe in [gemSysL_NFDM].

Wo möglich, werden die in [gemSysL_NFDM] modellierten Leistungsmerkmale genutzt. Für die weiteren Anwendungsfälle werden Konfigurationen für die Basis-Anwendungsfälle der allgemeinen Anwendungsverwaltung (siehe 3.5) beschrieben.

Es gelten die übergreifenden Vorbedingungen für Anwendungsfälle der Leistungsmerkmale aus [gemSysL_NFDM].

Der Datensatz ‚Persönlichen Erklärungen‘ (Erklärung zur Organ- und/oder Gewebespende, Vorsorgevollmacht, Patientenverfügung) wird unabhängig vom Notfalldatensatz behandelt.

3.7.2.1 NFD auf eGK verbergen

Mit diesem Anwendungsfall kann der Versicherte den Notfalldatensatz auf seiner eGK verbergen.

Tabelle 28: TAB_ADV_031 Anwendungsfall AdV-UC_113

Tabelle #: TAB_ADV_032 Konfiguration AdV-UC_113

3.7.2.2 Verborgenen NFD auf eGK sichtbar machen

Mit diesem Anwendungsfall kann der Versicherte den verborgenen Notfalldatensatz auf seiner eGK wieder sichtbar machen.

Tabelle 29: TAB_ADV_033 Anwendungsfall AdV-UC_114

Tabelle 30: TAB_ADV_034 Konfiguration AdV-UC_114

3.7.2.3 DPE von eGK anzeigen

Mit diesem Anwendungsfall wird dem Versicherten der auf der eGK gespeicherte Datensatz ‚Persönliche Erklärungen‘ angezeigt.

Abbildung 27: Darstellung AdV-UC_121: „DPE von eGK anzeigen“

Tabelle 31: TAB_ADV_035 Anwendungsfall AdV-UC_121

Tabelle 32: TAB_ADV_036 Konfiguration AdV-UC_121

Die Operation I_DPE_Management.ReadDPE ist in [gemSysL_NFDM] beschrieben.

3.7.2.4 DPE auf eGK ändern

Der Versicherte kann mit diesem Anwendungsfall den auf der eGK gespeicherten Datensatz ‚Persönliche Erklärungen‘ ändern. Dafür wird der DPE von der eGK gelesen, dem Versicherten angezeigt und zum Editieren angeboten. Nach dem Editieren wird der geänderte Datensatz auf die eGK geschrieben.

Wenn noch kein DPE auf der eGK gespeichert ist, dann kann der Versicherte einen DPE anlegen.

Abbildung 28: Darstellung AdV-UC_122: „DPE auf eGK ändern“

Tabelle 33: TAB_ADV_037 Anwendungsfall AdV-UC_122

Tabelle 34: TAB_ADV_096 Konfiguration AdV-UC_122 - AdV-UC_11

Tabelle 35: TAB_ADV_038 Konfiguration AdV-UC_122 - AdV-UC_12

Die Operationen I_DPE_Management.ReadDPE und I_DPE_Management.WriteDPE sind in [gemSysL_NFDM] beschrieben.

3.7.2.5 DPE auf eGK löschen

Mit diesem Anwendungsfall kann der Versicherteden auf der eGK gespeicherten Datensatz ‚Persönliche Erklärungen‘ löschen.

Abbildung 29: Darstellung AdV-UC_123: „DPE auf eGK löschen“

Tabelle 36: TAB_ADV_039 Anwendungsfall AdV-UC_123

Tabelle 37: TAB_ADV_040 Konfiguration AdV-UC_123

Die Operation I_DPE_Management.EraseDPE ist in [gemSysL_NFDM] beschrieben.

3.7.2.6 DPE auf eGK verbergen

Mit diesem Anwendungsfall kann der Versicherte den Datensatz ‚Persönliche Erklärungen‘ auf seiner eGK verbergen.

Tabelle 38: TAB_ADV_041 Anwendungsfall AdV-UC_124

Tabelle 39: TAB_ADV_042 Konfiguration AdV-UC_124

3.7.2.7 Verborgenen DPE auf eGK sichtbar machen

Mit diesem Anwendungsfall kann der Versicherte den verborgenen Datensatz ‚Persönliche Erklärungen‘ auf seiner eGK wieder sichtbar machen.

Tabelle 40: TAB_ADV_043 Anwendungsfall AdV-UC_125

Tabelle 41: TAB_ADV_044 Konfiguration AdV-UC_125

3.7.3 eMP/AMTS

Die Anwendungsfälle für das eMP/AMTS-Management basieren auf der Beschreibung der fachlichen und funktionalen Abläufe in [gemSysL_AMTS_A].

Wo möglich werden die in [gemSysL_AMTS_A] modellierten Leistungsmerkmale genutzt. Für die weiteren Anwendungsfälle werden Konfigurationen für die Basis-Anwendungsfälle der allgemeinen Anwendungsverwaltung (siehe 3.5) beschrieben.

Es gelten die übergreifenden Vorbedingungen für Anwendungsfälle der Leistungsmerkmale aus [gemSysL_AMTS_A].

3.7.3.1 eMP/AMTS-Datensatz auf eGK verbergen

Mit diesem Anwendungsfall kann der Versicherte die Daten der Anwendung eMP/AMTS auf seiner eGK verbergen.

Tabelle 42: TAB_ADV_051 Anwendungsfall: AdV-UC_137

Tabelle 43: TAB_ADV_052 Konfiguration AdV-UC_137

3.7.3.2 Verborgenen eMP/AMTS-Datensatz auf eGK sichtbar machen

Mit diesem Anwendungsfall kann der Versicherte die verborgenen Daten der Anwendung eMP/AMTS auf seiner eGK wieder sichtbar machen.

Tabelle 44: TAB_ADV_053 Anwendungsfall AdV-UC_138

Tabelle 45: TAB_ADV_054 Konfiguration AdV-UC_138

3.7.3.3 AMTS-Vertreter-PIN auf der eGK ändern

Mit diesem Anwendungsfall kann der Versicherte die Vertreter-PIN für die Anwendung eMP/AMTS auf seiner eGK ändern. Für eine Änderungserlaubnis wird der Versicherte zur Eingabe der Versicherten-PIN aufgefordert.

Tabelle 46: TAB_ADV_055 Anwendungsfall AdV-UC_139

3.7.3.4 AMTS-Vertreter-PIN auf der eGK entsperren

Mit diesem Anwendungsfall kann der Versicherte die Vertreter-PIN für die Anwendung eMP/AMTS auf seiner eGK entsperren. Für eine Entsperrerlaubnis wird der Versicherte zur Eingabe der Versicherten-PIN aufgefordert.

Tabelle 47 : TAB_ADV_056 Anwendungsfall AdV-UC_141

4 Externe Schnittstellen

Die externen Schnittstellen sind im Kapitel 2.2 deklariert worden. Nachfolgend werden die Operationen der externen Schnittstellen definiert. Von der AdV werden Clientsystemem folgende Interfaces angeboten:

• Zertifikats-Nutzung. Über diese Schnittstelle kann der Versicherte auf Zertifikate seiner eGK zugreifen, etwa um die öffentliche Zertifikate auszulesen, oder um eine Online-Gültigkeitsprüfung durchzuführen. Die Funktionen für das Ver- und Entschlüsselns sowie das Signieren können genutzt werden.

Abbildung 30: Schnittstellen zwischen AdV-Terminal und Fachmodul AdV

Die Anwendungsfälle zum Management von Anwendungen, dem PIN-Management und der Fachanwendungen werden über die von der AdV angebotene graphische Benutzeroberfläche ausgelöst. Für sie wird keine externe Schnittstelle angeboten.

Abbildung 31: Schnittstellen zwischen Fachmodul AdV und Backend-Komponenten

Funktionalitäten, die nicht über einen Aufruf von Schnittstellen der fachanwendungsspezifischen Fachmodule realisiert werden können, werden vom AdV mit Hilfe von TIP Operationen umgesetzt.

4.1 Zertifikatsverwaltung

Das Interface I_Certificate stellt Operationen bereit, die Anwendungsfälle zur Nutzung der Zertifikate-Objekte auf der eGK initiieren

4.1.1 Operation read_Certificate

Die Operation read_Certificate initiiert den Anwendungsfall AdV-UC_24: „Zertifikat von eGK lesen“.

4.1.2 Operation encrypt

Die Operation encrypt initiiert den Anwendungsfall AdV-UC_25: „Mit eGK verschlüsseln“.

Beim hybriden Verschlüsseln von Plaintext werden ausschließlich Verschlüsselungszertifikate der eGK verwendet. Es können keine separaten Verschlüsselungszertifikate übergeben werden. Der symmetrische Schlüssel wird während der Operation erzeugt. Die Operation verhält sich konform zu [TR-03112-4#3.5.1] (Crypto Services/Encipher).

4.1.3 Operation decrypt

Die Operation decrypt initiiert den Anwendungsfall AdV-UC_26: „Mit eGK entschlüsseln“.

Beim Entschlüsseln hybrid verschlüsselter Dokumente wird Ciphertext entschlüsselt, wie er in der Schnittstelle encrypt verschlüsselt wurde. Die Operation verhält sich konform zu [TR-03112-4#3.5.2] (Crypto Services/Decipher).

4.1.4 Operation authenticate

Die Operation authenticate initiiert den Anwendungsfall AdV-UC_27: „Authentisierungsrequest mit eGK signieren“.

Die Operation versieht unter Verwendung des AUT-Zertifikates der eGK eine Message (Binärstring/Hashwert) mit einer nicht-qualifizierten elektronischen Signatur. Die Operation verhält sich konform zu [TR-03112-4#3.5.5] (Crypto Services/Sign).

5 Systemzerlegung (Deployment)

5.1 Übersicht

Die AdV in einer Umgebung im Auftrag der Kostenträger schließt die Lösung für die @home-Umgebung ein.

Die Systemzerlegung ordnet die Komponenten der Fachanwendung AdV den Zonen gemäß Zonenmodell der TI aus [gemKPT_Arch_TIP] zu.

Komponenten der AdV in einer Umgebung im Auftrag der Kostenträger:

• Produkttyp KTR-AdV mit den Komponenten AdV-Server und AdV-App
• Produkttyp Kostenträger-AdV-Terminal (KTR-AdV-Terminal)

Abbildung 32: Systemzerlegung AdV in der Kostenträger-Umgebung

Die AdV-Lösung in der Umgebung des Versicherten (@home) verfolgt denselben Architekturansatz wie die AdV in einer Umgebung im Auftrag der Kostenträger. Ein Unterschied beider Lösungen besteht darin, dass bei der Systemzerlegung der AdV in einer Umgebung im Auftrag der Kostenträger mit dem KTR-AdV-Terminal ein Produkttyp der TI entsteht, an den Anforderungen für ein öffentlich zugängliches Gerät gestellt werden. Die Hardware der @home-Umgebung (Gerät des Versicherten) unterliegt als private Umgebung der Kontrolle und Verantwortlichkeit des Versicherten, dem einzig die AdV-App zur Verwendung auf seinem privaten Gerät, sowie Hinweise zur Verwendung von Kartenterminals, zur Verfügung gestellt werden.

Der Produkttyp KTR-AdV stellt gemäß Architekturkonzept [gemKPT_ArchTIP] ein RZ-Consumer in der dezentralen Zone der TI-Plattform dar. Zugriffe auf Dienste der zentralen TI-Plattform werden über die logische Komponente ConsumerAdapter gekapselt. Als Produkttyp der Fachanwendung AdV realisiert die KTR-AdV Funktionalität in „Building Blocks“ des Zonenmodells der TI gemäß [gemKPT_ArchTIP] der Consumer Zone, Personal Zone, der Secure Consumer Zone und der TI-Plattform Zone dezentral. Entsprechend der Kommunikationsmatrix TI [gemKPT_ArchTIP] sind Kommunikationsbeziehungen von der KTR-AdV nur in Richtung der TI-Plattform zentral, in die Provider Zone und in die Existing Application Zone zulässig, wobei letztere über keinen Anwendungsfall in den Anwendungen des Versicherten verfügen. Gemäß Kommunikationsmatrix sind keine Kommunikationsbeziehungen aus der TI-Plattform zentral, aus der Providerzone oder aus der Existing Application Zone in Richtung KTR-AdV zulässig. Die Einhaltung dieser Kommunikationsregeln obliegt dem Zugangspunkt der KTR-AdV in die TI (z. B. über einen SZZP).

5.2 Übergreifende Anforderungen an AdV-Komponenten

Es gelten übergreifende Anforderungen des Datenschutzes und der Informationssicherheit.

Die Mensch-System-Interaktion soll so gestaltet werden, dass Versicherte in der Lage sind, die AdV-Anwendungsfälle selbstständig, d. h. insbesondere ohne Unterstützung Dritter, zu nutzen.

Es muss berücksichtigt werden, dass der Versicherte gegebenenfalls nicht intuitiv mit einem Computersystem interagieren kann. Daher sollen dem Versicherten Informationen zur Nutzung der AdV bereitgestellt werden.

Entsprechend dem Beschluss des Lenkungsausschusses vom 04.05.2017 sind die Bedingungen, unter denen ein AdV-Terminal eine Ausführungsumgebung für zusätzliche Anwendungen darstellen kann, noch zu klären.

Um die Akzeptanz für die Bereitstellung einer AdV-Umgebung zu erhöhen, soll auf dem AdV-Terminal die Möglichkeit bestehen, weitere von der TI unabhängige Anwendungen mit Mehrwert für den Versicherten anzubieten.

Zusätzliche Gesundheitsanwendungen außerhalb der TI nutzen die Hardware des AdV-Terminals ausschließlich als Ablaufumgebung und dürfen die Anwendungen der TI nicht beeinflussen.

5.3 Systemschnitt AdV in einer Umgebung im Auftrag der Kostenträger/@home

Mit der AdV in einer Umgebung im Auftrag der Kostenträger werden für den Versicherten AdV-Lösungen im Bereich des Gesundheitswesens (z. B. in der Geschäftsstelle einer Krankenkasse) und in der @home-Umgebung bereitgestellt.

Die Geschäftsstellen der Krankenkassen sind in eine IT-Infrastruktur mit Anbindungen an Rechenzentren eingebunden. Um diese IT-Infrastruktur nach zu nutzen, wird eine Architektur mit Rechenzentrum-basierten Servern gewählt, die eine Anbindung an die TI und eine Erreichbarkeit weiterer kassenspezifischer Anwendungen ermöglicht. In den Rechenzentren werden SM-Bs in Form von Hardware Security Modulen betrieben, die eine remote Card-to-Card-Authentisierung mit der dezentral ausgelesenen eGK durchführen können.

In der Umgebung des Versicherten wird dieser Architekturansatz ebenfalls verfolgt, sodass auch hier eine Card-to-Card-Authentifizierung erfolgen kann.

Die Verarbeitung der AdV-Daten erfolgt lokal in den KTR-AdV-Umgebungen unter direkter dezentraler Kartenkommunikation, so dass auf die Verwendung von SICCT/Netzwerk-Kartenterminals verzichtet werden kann. Die Nutzung der kontaktlosen Kartenschnittstelle der eGK ist möglich.

5.3.1 Produkttyp KTR-AdV als AdV-Server mit AdV-App

Die KTR-AdV bietet Leistungen an, die der Consumer Zone, Personal Zone, Secure Consumer Zone und TI-Plattform Zone dezentral zugeordnet werden, und

• wird im Auftrag der Krankenkasse betrieben,
• bindet die @home-Umgebung über das Internet, sowie KTR-AdV-Terminals über Netzwerke der Geschäftsstelle an,
• stellt den Kostenträger-Umgebungen sowie der @home-Umgebung die AdV-App für die in Kapitel 3 genannten Anwendungsfälle zur Verfügung,
• initiiert die Kommunikation Richtung Services der zentralen TI und gesicherter fachanwendungsspezifischer Dienste und
• stellt ein Routing zwischen den Benutzerschnittstellen des Versicherten und weiteren kassenspezifischen Anwendungen bereit.

Zu jedem AdV-Server korrespondiert eine AdV-App, die über den AdV-Server bereitgestellt wird. Die AdV-App ist der einzige berechtigte Client, der Operationen an der Schnittstelle des AdV-Servers aufrufen darf.

Der Versicherte interagiert mit der AdV-App, die im KTR-AdV-Terminal bzw. in der Umgebung des Versicherten läuft und über die der Versicherte sämtliche Anwendungsfälle startet.

Eine Übersicht der Schnittstellen in der KTR-AdV findet sich in Abbildung 3.

Die Fachanwendungen sind verantwortlich für Bereitstellung ihrer fachanwendungsspezifischen Daten und für die Vorgaben zur Anzeige der Daten.

Die Kartenzugriffe werden von der AdV-App lokal am KTR-AdV-Terminal bzw. in der Umgebung des Versicherten ausgeführt.

Mit einer remote Card-to-Card-Authentisierung zwischen eGK und SM-B wird die Authentizität der beteiligten Komponenten überprüft und die eGK für die Durchführung der AdV-Anwendungsfälle freigeschaltet.

Die zentrale TI ist für die AdV-Terminal/@home-Umgebung nur über den AdV-Server erreichbar. Die PKI und die Schnittstellen in die TI werden von der KTR-AdV nach Vorgaben der TI genutzt.

Der AdV-Server wird in einem Rechenzentrum der Krankenkassen betrieben, die in sicherheitstechnischer und betrieblicher Hinsicht den Regelungen des SGB unterliegen.

5.3.2 Produkttyp KTR-AdV-Terminal

Ein AdV-Terminal ist ein für die eigenständige Nutzung von AdV durch Versicherte in Umgebungen des Gesundheitswesens konzipiertes Benutzerendgerät.

Das KTR-AdV-Terminal ist Bestandteil der Consumer Zone und

• stellt dem Versicherten ein Benutzerinterface für die AdV zur Verfügung und
• stellt die Ausführungsumgebung der durch den AdV-Server bereitgestellten AdV-App dar.

Das KTR-AdV-Terminal muss aus Bedienelementen zur eigenständigen Nutzung des Versicherten bestehen.

Der AdV-Server stellt mit der AdV-App eine sichere Ablaufumgebung für die AdV-Anwendungsfälle bereit.

5.3.3 Umgebung des Versicherten

Die Umgebung des Versicherten ist eine private, nicht öffentlich zugängliche Umgebung des Versicherten, über die dieser die alleinige Kontrolle hat. Sie ist kein Produkttyp der TI.

Die KTR-AdV stellt für den Versicherten @home eine AdV-App, sowie Empfehlungen zur Nutzung von AdV in seiner privaten Umgebung bereit.

Die Umgebung des Versicherten ist Bestandteil der Personal Zone und

• stellt dem Versicherten ein Nutzerinterface für die AdV zur Verfügung,
• nutzt die durch den AdV-Server bereitgestellte AdV-App.

Die @home-Umgebung enthält Geräte, etwa Kartenterminal, sowie einen Computer mit geeigneten Bedienelementen, die der Versicherte zur Nutzung der AdV-App benötigt. Die @home-Umgebung kann einen marktüblichen Browser enthalten, der mit der AdV-App interagiert.

AN_@H_1:     Die Versicherten übernehmen die Verantwortung dafür, ihre eigenen IT-Systeme (GdV) in der Umgebung des Versicherten auf das für die clientseitige Nutzung des AdV-Servers angemessene Sicherheitsniveau zu bringen.

Die Einhaltung der Annahme AN_@H_1 obliegt dem Versicherten selbst.

5.3.4 Nutzung des eCard-API-Framework

Lösungen für die AdV in einer Umgebung im Auftrag der Kostenträger sollen mit einem standardbasierten Vorgehen umgesetzt werden. Es eröffnet die Möglichkeit, AdV-Komponenten mit etablierten Verfahren zur Sicherheitsbestätigung vereinbar zu machen.

Die Kommunikation zwischen eGK, Kartenleser, AdV-App und AdV-Server in den Umgebungen der Kostenträger und der @home-Umgebung und den evaluierten Rechenzentren kann gemäß den Technischen Richtlinien [TR-03112]^{(Die eCard – API wird durch das BSI bereitgestellt, siehe auch https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03112/index_htm.html)}, [TR-03124]^{(Der eID-Client zur Authentisierung des Versicherten für die Echtheitsprüfung der eGK https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03124/index_htm.html)} und [TR-03130]^{(Der eID-Server zur Freischaltung der eGK mittels Identität einer SM-B für die KTR-AdV https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03130/tr-03130.html)} des BSI erfolgen.

Ein standardbasiertes Vorgehen konform zu den technischen Richtlinien des BSI fokussiert sich dabei auf diejenigen Aspekte, die für die Nutzung der eGK durch Versicherte in der KTR- und @home-Umgebung relevant sind.

5.3.4.1 Schichtenarchitektur

In der AdV in einer Umgebung im Auftrag der Kostenträger und @home kommen Komponenten zum Einsatz, die dem Versicherten Anwendungsfälle auf bzw. mit seiner eGK und ggfs. über eine Browseroberfläche ermöglichen. Für den lokalen Zugriff auf die eGK des Versicherten stellt das BSI das eCard-API-Framework [TR-03112] zur Verfügung.

Ferner stellt das BSI mit den Richtlinien [TR-03124] und [TR-03130] zur Verwendung elektronischer Identitäten (eID) einen Mechanismus bereit, mit dem sich die eGK des Versicherten und eine SM-B mit Identität für die KTR-AdV via Card-to-Card gegenseitig authentisieren können.

Die folgende Abbildung zeigt den Aufbau des eCard-API-Frameworks [1] zur Anbindung der eGK des Versicherten an die AdV-App. Die übrigen Technischen Richtlinien bauen auf diese auf.

Abbildung 33: Architekturschichten der AdV-eCard-API

Im Rahmen der eCard-API-Architektur werden vor allem die in Abbildung 33 blau markierten Systemteile von AdV genutzt, nicht aber das vollständige eCard-API-Framework.

Der Application Layer beinhaltet die AdV-Anwendungslogik in der AdV-App und nutzt die verschiedenen Schnittstellen der eCard-API für den Zugriff auf die eGK.

Der Identity-Layer stellt der AdV-Anwendungslogik Schnittstellen für Authentisierungs- und Kryptooperationen der eGK bereit.

Der Service-Access-Layer stellt der AdV-Anwendungslogik Smartcard-Schnittstellen gemäß [ISO24727-3] für das Lesen und Schreiben von Daten von der/auf die eGK bereit. Zur Abbildung von Schnittstellenoperationen auf Kartenkommandos ist ein CardInfo-File für die jeweilige Version der eGK erforderlich.

Über den Terminal-Layer kann die AdV-App einerseits Operationen auf dem angebundenen Kartenlesegerät ausführen (z. B. Textausgabe auf einem Kartenterminaldisplay). Daneben kann die AdV-App Kartenkommandos direkt an die gesteckte eGK weiterleiten.

Die AdV-App verwendet ein lokal über die CT-API-Schnittstelle angebundenes Kartenterminal.

Die AdV-App setzt die AdV-Anwendungsfälle der Systemlösung AdV [gemSysL_AdV], sowie weitere relevante Anforderungen der TI, z. B. in Bezug auf Netzwerkkommunikation und PKI um und bedient sich dabei der Schnittstellen der eCard-API soweit ein Zugriff auf die eGK erforderlich ist.

5.3.4.2 Kommunikationsmuster

Zur Authentisierung und Freischaltung der eGK können die [TR-03124] und [TR-03130] auf Basis der eCard-API verwendet werden. Das Kommunikationsmuster der zugrunde liegenden Card-to-Card-Authentisierung ist in der folgenden Abbildung dargestellt.

Abbildung 34: Aufbau sicherer Kanal und gegenseitige Authentisierung

Kommunikationsfluss zum Aufbau eines sicheren Kanals von der AdV-App zum AdV-Server mit anschließender Card-to-Card-Authentisierung

1. Die AdV-App wird als Dienst auf dem Benutzerendgerät gestartet,
2. der Versicherte steuert über eine Webseite eines Kostenträgers die Nutzung von AdV mit seiner eGK an,
3. der Versicherte wird von der Webseite des Kostenträgers auf die lokale Adresse des AdV-App-Dienstes weitergeleitet und erhält die Adresse eines Tokenservers (z.B. Tokenserver in der Hoheit des gleichen Kostenträgers),
4. die AdV-App besorgt das Token vom Tokenserver, dessen Adresse in (3) mitgeteilt wurde.
5. Die AdV-App baut einen sicheren Kanal zum AdV-Server auf.
6. Die AdV-App initiiert die Authentisierung zwischen AdV-App und AdV-Server. Während der Authentisierung prüft der AdV-Server mit Hilfe der Public Key Infrastructure (PKI) die Echtheit der eGK. Die eGK authentisiert umgekehrt die Identität der SM-B des Kostenträgers.

Nach Abschluss des Handshakes zwischen der eGK im Zugriff der AdV-App und einer SM-B im Zugriff des AdV-Servers gelangt die eGK in einen Sicherheitszustand, der eine lokale Ausführung von AdV-Anwendungsfällen in den Umgebungen im Auftrag der Kostenträger ermöglicht.

5.4 Administration der Anwendungen des Versicherten

Der folgende Abschnitt skizziert das Konzept der Administration der an der AdV beteiligten Komponenten. Die Administration ist ein Umsetzungskonzept für geschultes Personal, welches Anpassungen an der Konfiguration der Systemkomponenten vornimmt, um eine Betriebsbereitschaft initial herzustellen und im laufenden Betrieb sicherzustellen.

5.4.1 Allgemeines

Zum Schutz vor Manipulation oder unbeabsichtigter Fehlkonfiguration durch Dritte müssen alle Komponenten einen Administrationsmodus oder -bereich haben, der durch gesonderte Zugriffsrechte geschützt ist.

Die konkreten Anforderungen an konfigurierbare Parameter ergeben sich auf Spezifikationsebene.

Folgende Log-Typen können dargestellt werden: EventLog, SecurityLog, Ablaufprotokoll, PerformanceLog, DebugLog.

5.4.2 Verwaltete Artefakte

Die folgenden Anforderungen ergeben sich aus der Systemzerlegung. Kommen durch Anpassungen weitere Komponenten hinzu, soll für diese ebenso eine Administratorschnittstelle vorgesehen werden.

6 Informationsmodell

6.1 Fachliches Informationsmodell

Die Fachanwendungen der eGK haben das technische Informationsmodell der auf der eGK des Versicherten gespeicherten Anwendungsdaten in den Dokumenten der Tabelle TAB_ADV_091 festgelegt.

Tabelle 52: TAB_ADV_091 Informationsmodell der Fachanwendungen

6.2 Technisches Informationsmodell

6.2.1 Zugriffs-Protokollierung

Einträge in die Zugriffsprotokollierung auf die eGK beinhalten Informationen darüber, wer zu welchem Zeitpunkt welche Art Zugriff auf die eGK hatte.

Abbildung 35: Informationsmodell Zugriffsprotokoll

Die Einträge Component-ID (zur Identifizierung involvierter technischer Komponenten) und Actor-ID sind optional. Die Belegung der Werte wird durch die Fachanwendungen spezifiziert (siehe [ gemSpec_Karten_Fach_TIP]).

Die Tabelle TAB_ADV_092 listet beispielhafte Protokolleinträge für zwei Aktionen aus VSDM (siehe [gemSpec_FM_VSDM#Tab_FM_VSDM_06]).

Tabelle 53: TAB_ADV_092 Beispiele für Protokolleinträge VSDM

6.2.2 Weitere freiwillige Anwendungen

In 10 Einträgen können zu einer weiteren TI-basierten weiteren freiwilligen Anwendung auf der eGK jeweils ein Verweis, sowie eine Einwilligung verwaltet werden. Die Zuordnung zwischen Verweis und Einwilligung erfolgt durch die Reihenfolge der Einträge (siehe [gemeGK_Fach#7,8]).

Abbildung 36: Informationsmodell Weitere freiwillige Anwendungen

7 Ergänzungen zum Leistungsumfang

Bereits jetzt bekannte Zukunftsthemen der AdV sind (s.a. [gemAnforderungen_AdV#5):

• Übergreifendes Leistungsmerkmal Daten- und Berechtigungserhalt
• Ausbaustufen von ORS2.1-Anwendungen:
• Zukunftsthemen NFDM
• Zukunftsthemen eMP/AMTS
• Neu hinzu kommende Anwendungen, insbesondere:
• Elektronische Organspendeerklärung
• Elektronisches Patientenfach
• Gesundheitsdatendienste (Verwaltung von Einwilligungen und Verweisen zu GDD)
• Unterstützung nachladbarer Konfigurationen für AdV-Anwendungsfälle nach Einführung eines modularen Konnektors

Beispielhaft wird das Leistungsmerkmal geschildert, das AdV der zukünftigen Anwendung elektronisches Patientenfach bereitstellt.

Die Fachanwendung AdV stellt Versicherten Grundlagen zur Verfügung, die vom Patientenfach genutzt werden können:

• Schnittstellen zum Authentisieren, Verschlüsseln und Entschlüsseln von Daten mit der eGK
• Komponenten zur eigenständigen Nutzung für Versicherte

Die Fachanwendung AdV schafft in diesem Sinne die Voraussetzungen für den Zugang des Versicherten zum Patientenfach.

8 Lieferumfang

Die Dokumentenlandkarte (Abbildung 1) gibt einen Überblick über die Dokumente, welche im Rahmen des Projektes AdV in der Konzeptions- und Spezifikationsphase bereitgestellt werden.

Tabelle 54: TAB_ADV_093 Lieferumfang Projekt AdV

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.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 entnehmen Sie bitte der aktuellen, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

9.5.2 Weitere Dokumente

10 Anhang B – Übersicht Anwendungsfälle

Die Tabelle TAB_ADV_094 bietet eine Übersicht über die durch den Versicherten in den einzelnen Umgebungen ausführbaren Anwendungsfälle.

Tabelle 55: TAB_ADV_094 Übersicht Anwendungsfälle

11 Anhang C

Die Tabelle TAB_ADV_095 bietet eine Übersicht der in der Konfiguration der Basis-Anwendungsfälle genutzten Identifier von Anwendungen.

Tabelle 56 : TAB_ADV_095 Identifier von Anwendungen