Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation
KTR-AdV

    

     

      
Version
      
1.7.0
     
     

      
Revision
      
829909
     
     

      
Stand
      
Wert nicht konfiguriert
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_KTR-AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps KTR-AdV.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter einer KTR-AdV sowie Hersteller und Anbieter von Produkttypen der TI, die hierzu eine Schnittstelle besitzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren 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.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 9.5).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps KTR-AdV verzeichnet.

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.

Sie 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

2.1 Einordnung des Produkttyps in die Telematikinfrastruktur

Für die eigenständige Verwaltung der Anwendungen des Versicherten auf der elektronischen Gesundheitskarte steht dem Versicherten in einer Umgebung im Auftrag der Kostenträger und @home die KTR-AdV zur Verfügung.

Mit dieser wird der Versicherte in die Lage versetzt, eigenständig seine persönlichen Daten auf der eGK einzusehen, seine freiwilligen Anwendungen zu verwalten, sowie administrative Anwendungsfälle der PIN-Verwaltung auszuführen. Die Abbildung ABB_ADV_300 zeigt die Einordnung des Produkttyps in die Telematikinfrastruktur.

Abbildung 1: ABB_ADV_300 – Überblick AdV in einer Umgebung im Auftrag der Kostenträger

Die KTR-AdV gliedert sich in die beiden blau dargestellten Komponenten AdV-App und AdV-Server sowie eine Komponente zur sicheren Speicherung der Kostenträgeridentitäten und des dazugehörigen kryptografischen Schlüsselmaterials (z.B. in einem HSM). Auf einem Gerät für die Benutzung durch den Versicherten wird die AdV-App zur Anbindung der eGK bereitgestellt. Diese AdV-App baut über eine produkttyp-interne Schnittstelle eine Verbindung zum zugehörigen AdV-Server auf, der im Auftrag einer Krankenkasse in einem Rechenzentrum betrieben wird.

Zur Freischaltung der eGK des Versicherten für die Umgebung der Kostenträger wird ein CV-Zertifikat des Kostenträgers mit einem Profil „KTR-AdV“ mit entsprechendem Schlüsselmaterial verwendet, das über ein Card-to-Card-Verfahren den Zugriff für die Anwendungsfälle auf der eGK gewährt.

Daraus folgt, dass kein anderes Zugriffsprofil für die Freischaltung der eGK verwendet werden darf.

2.2 Leistungen der TI-Plattform

Dem Produkttyp KTR-AdV stehen keine dedizierten, benachbarten Produkttypen zur Realisierung der Leistung der TI-Plattform (z.B. Konnektor) zur Verfügung. Die KTR-AdV muss die Verfahren und Systemprozesse der TI-Plattform, wie den Zugriff auf Smartcards und Zugriffe auf zentrale Dienste, implementieren.

Über die logische Komponente TIP-Consumer-Adapter stehen die Schnittstellen und Dienste der zentralen TI-Plattform zur Verfügung. Die Anbindung der eGK des Versicherten an die AdV-App und die kryptografische Verwendung der Identitäten der Kostenträger im AdV-Server erfolgen über eine logische Zugriffsschicht zur Kapselung plattformspezifischer Aspekte in Systemprozessen der TI-Plattform (vgl. Abbildung ABB_ADV_304).

Zur Anbindung der eGK an die AdV-App soll auf Geräten des Versicherten ein einfaches kontaktbehaftetes oder kontaktloses Kartenterminal angenommen werden, das seinerseits nicht notwendigerweise über Sicherheitsmerkmale verfügt. Wird die AdV-App in einem KTR-AdV-Terminal betrieben, dann erfolgt die Anbindung der eGK über ein Kartenterminal mit Sicherheitsmerkmalen (Display und PIN-Pad).

Zur Bildung eines Vertrauensraumes steht der KTR-AdV die PKI der TI zur Verfügung. Sie setzt die Mechanismen der PKI zum Aufspannen eines Vertrauensraums um. Die zertifikatsbasierte Authentisierung in Verbindung mit den kryptografischen Verfahren der TI dient der Sicherstellung des Datenschutzes, der Integrität und der Vertraulichkeit der Daten des Versicherten.

In einer Leistungserbringerumgebung stellt der Konnektor den Fachmodulen der Fachanwendungen Schnittstellen und Dienste der TI-Plattform bereit, welche diese zur Abbildung fachlicher Anwendungsfälle nutzen. Der Konnektor kapselt zusätzlich den Zugriff auf Smartcards und steuert die Kommunikation mit den entsprechenden Kartenterminals. Im Gegensatz dazu wird die Fachlogik der Fachanwendungen in der KTR-AdV mit der für die Umsetzung notwendigen Logik der dezentralen TI-Plattform in einem einzigen Produkttyp realisiert. Die Umsetzung der Fachlogik der Fachanwendungen kann sich auf AdV-App und AdV-Server verteilen.

Die von den Fachanwendungen benötigte Logik der dezentralen TI-Plattform wird in Form von Systemprozessen beschrieben. Diese stellen eine Leistungsbeschreibung dar, ohne Vorgaben an konkrete Realisierungsdetails zu machen. Sie setzen sich aus Logik-Bausteinen der verschiedenen Domänen der TI-Plattform (Karten, PKI, Kryptografie, etc.) zusammen und beschreiben fachliche Zusammenhänge. Die Fachmodule der Fachanwendungen setzen ihre fachanwendungsspezifischen Operationen in der KTR-AdV um, in dem sie auf die entsprechenden Systemprozesse verweisen. Die folgende Abbildung ABB_ADV_304 zeigt diesen Zusammenhang, ohne eine Vorgabe an die Modularisierung einer KTR-AdV-Software zu machen.

Abbildung 2: ABB_ADV_304 – Zusammenhang Systemprozesse und Fachanwendung

In Abhängigkeit von der Ablaufumgebung, z.B. dem verwendeten Kartenterminal, sind für das Funktionieren der Systemprozesse zusätzliche Umgebungsparameter oder umgebungsspezifische Operationen erforderlich. Diese werden als Eingabe- bzw. Ausgabeschnittstellen in den Systemprozessen aufgerufen und führen zu einem Tayloring (Zuschnitt) der Leistung der TI-Plattform auf eine an die Umgebung der Kostenträger angepasste „AdV-Plattform.“ Die KTR-AdV muss diese Schnittstellen als Umgebung zur Realisierung der Leistungen der TI-Plattform implementieren (Realisierungsumgebung).

Die Spezifikation der Systemprozesse findet sich in [gemSpec_Systemprozesse_dezTI]. Es werden Anforderungen an die zu erbringende Leistung gestellt, ohne Vorgaben zu den zu verwendenden Technologien zu machen. Die Ausgestaltung und Modularisierung zwischen logischer Plattformebene, Kapselung von Fachlogik der weiteren Fachanwendungen sowie der gesicherten Schnittstelle zwischen AdV-App und AdV-Server obliegt dem Hersteller einer Lösung der KTR-AdV.

3 Systemkontext

3.1 Akteure und Rollen

Im Systemkontext der KTR-AdV interagieren verschiedene Akteure (aktive Komponenten) in unterschiedlichen Rollen mit der KTR-AdV. Die folgenden Akteure interagieren mit der KTR-AdV:

• Nutzer
  Ein Nutzer ist eine natürliche Person, die Anwendungsfälle in der KTR-AdV startet
• Ausführungsumgebung
  wird durch ein Gerät mit einem Betriebssystem gebildet, das die Teilkomponente AdV-App auf Seiten des Versicherten ausführt
• Kartenterminals
  ist eine technische Komponente zur Anbindung der eGK des Versicherten, um mit dieser die KTR-Anwendungsfälle auszuführen
• Smartcards
  Smartcards der TI sind Teil der dezentralen TI-Plattform und sind an die KTR-AdV zur Unterstützung der KTR-AdV-Anwendungsfälle angeschlossen
• Zentrale TI-Plattform
  Die Dienste der zentralen TI-Plattform unterstützen die KTR-AdV in der Ausführung der KTR-AdV-Anwendungsfälle.
• Fachdienste
  sind technische Komponenten, die im Rahmen fachanwendungsspezifischer Anwendungsfälle des Versicherten aufgerufen werden

Die folgende Tabelle TAB_ADV_300 listet diejenigen Akteure auf, die in verschiedenen Rollen mit der KTR-AdV interagieren.

Tabelle 1: TAB_ADV_300 – Akteure und ihre Rollen

Der Nutzer kann in verschiedenen Rollen aktiv werden. Als Versicherter nimmt der Nutzer seine Datenschutzrechte auf informationelle Selbstbestimmung wahr, indem er fachliche Anwendungsfälle zum Anzeigen und ggfs. Bearbeiten der mittels seiner eGK gespeicherten Daten startet. Die Nutzer mit den Rollen Administration und Betrieb stellen die technische Betriebsbereitschaft der KTR-AdV her, d. h. sie konfigurieren das System für die Inbetriebnahme und stellen während des Betriebs die Betriebsbereitschaft sicher.

Gemäß den Festlegungen in [gemSpec_eGK_ObjSys#5.3.10] darf die MRPIN.home nur außerhalb der TI verwendet werden. Im Produkttyp KTR-AdV als Teil der TI findet sie somit keine Verwendung.

Für die Benutzerverifikation der Rolle des Versicherten wird die PIN.CH verwendet.

Die Ausführungsumgebung kann zwei verschiedene Ausprägungen haben und bezieht sich auf die Ausführung der Teilkomponente AdV-App. Als KTR-AdV-Terminal wird sie von einem Betreiber verantwortet und muss eine bestimmte Sicherheitsleistung erbringen, um die mittels der eGK gespeicherten Daten des Versicherten zu schützen. Das KTR-AdV-Terminal wird als separater Produkttyp der TI spezifiziert. Im Gegensatz dazu ist ein Gerät des Versicherten ein beliebiges Gerät im Zugriff des Versicherten. Hier obliegt es dem Versicherten, die mittels seiner eGK gespeicherten Daten durch geeignete Maßnahmen zu schützen, da die hier spezifizierten Sicherheitsaspekte nur bis in die beim Versicherten ausgeführte Softwarekomponente AdV-App durchgesetzt werden können.

3.2 Nachbarsysteme

Die von der KTR-AdV erreichbaren Produkttypen der TI sind

• SM-B-Identitäten der KTR-AdV,
• eGK (G2 und höher),
• SZZP,
• Dienste der zentralen TI-Plattform und
• Fachdienste.

Die SM-B-Identitäten werden in der KTR-AdV benötigt, um auf der eGK des Versicherten erweiterte Zugriffsrechte freizuschalten und Verbindungen zu Fachdiensten und zu Diensten der zentralen TI-Plattform aufzubauen. Die Dienste der zentralen TI-Plattform und Fachdienste sind beispielsweise an den Anwendungsfällen zur Gültigkeitsprüfung und Aktualisierung der eGK des Versicherten beteiligt. Die Einbeziehung der SM-B-Identitäten der KTR-AdV muss unter Verwendung eines sicheren Speichers des kryptografischen Schlüsselmaterials der verwendeten Identitäten erfolgen.

Die Außenschnittstellen des Produkttyps KTR-AdV sind in der Abbildung ABB_ADV_301 dargestellt und im Folgenden aufgelistet:

• Die Schnittstelle zu einem Kartenterminal, wie in Abschnitt 6.2.1 beschrieben.
• Die Schnittstellen des Consumer Adapters zu den zentralen Diensten der TI, wie in Abschnitt 6.2.4 beschrieben.
• Eine grafische Benutzeroberfläche, deren Aspekte in den jeweiligen Anwendungsfällen in Abschnitt 6.1 beschrieben sind.

Abbildung 3: ABB_ADV_301 – Kontextdiagramm

3.3 Ablaufumgebung

Die Komponenten der KTR-AdV werden in verschiedenen Umgebungen betrieben, die in ABB_ADV_303 dargestellt sind.

Abbildung 4: ABB_ADV_303 – Verteilungsdiagramm

Die Komponente „AdV-Server“ wird in einem Rechenzentrum betrieben:

Der Komponente „AdV-App“ stehen zwei verschiedene Ablaufumgebungen zur Verfügung.

Im nicht-öffentlichen zugänglichen Bereich (@home) wird die AdV-App auf einem Gerät des Versicherten betrieben. An diese Umgebung können keine Sicherheitsanforderungen gestellt werden. Der Schutz des eingesetzten Gerätes liegt in der Verantwortung des Versicherten. Durch geeignete Hinweise und Empfehlungen soll der Versicherte aufgeklärt werden, wie die AdV-App sicher genutzt werden kann und dass auch der Versicherte selbst hierzu beitragen kann. Im Rahmen dieser Informationen sollen insbesondere die Vorteile eines Kartenterminals mit Sicherheitsmerkmalen (bspw. Display, PIN-Pad) beschrieben und entsprechende Empfehlungen ausgesprochen werden.

Im öffentlichen zugänglichen Bereich wird die AdV-App in einem KTR-AdV-Terminal betrieben.

Das KTR-AdV-Terminal ist ein Produkttyp der TI. Anforderungen an den Produkttyp sind in [gemSpec_KTR-AdV-Terminal] spezifiziert.

4 Zerlegung des Produkttyps

Der Produkttyp KTR-AdV besteht aus den Teilsystemen AdV-Server und AdV-App.

Im Folgenden wird die Zerlegung des Produkttyps KTR-AdV dargestellt, welche für die Übersicht der funktionalen Leistungsmerkmale in vorliegender Spezifikation nötig ist.

Abbildung 5: ABB_ADV_329 – Komponentendiagramm der KTR-AdV

In Tabelle TAB_ADV_329 werden die Komponenten, ihre Verantwortlichkeit und spezifische Funktionalitäten dargestellt.

Tabelle 2: TAB_ADV_329 – Komponenten, Verantwortung und Funktionalitäten

5 Übergreifende Festlegungen

5.1 Datenschutz und Sicherheit

In diesem Kapitel werden übergreifende Anforderungen beschrieben, die sich aus den Themenfeldern Datenschutz und Sicherheit ergeben.   

5.1.1 Verarbeitung personenbezogener Daten

Um den Datenschutz des Versicherten zu gewährleisten, werden folgende Anforderungen gestellt:

Es kann vor der Abmeldung des Versicherten ein Hinweis eingeblendet werden, der es dem Nutzer ermöglicht die Session fortzuführen.

Hiermit soll erreicht werden, dass die AdV-App nur dann mit dem AdV-Server kommuniziert, wenn dies für den Anwendungsfall unbedingt notwendig ist. Beispiele hierfür sind die Gültigkeitsprüfung beim Sitzungsstart oder die Kommunikation zu den Fachdiensten VSDM für die Onlineprüfung und -aktualisierung der Versichertenstammdaten. Die Änderung einer PIN oder das Anzeigen von Protokolldaten der eGK hingegen lässt sich mit lokalen Mitteln durchführen und darf nicht über den AdV-Server umgesetzt werden.

Die AdV-App kann unter Wahrung der gesetzlichen Rahmenbedingungen die KVNR an den AdV-Server übertragen.

5.1.2 Absicherung der AdV-Komponenten

Um die verarbeiteten Daten zu schützen, werden folgende Anforderungen zur Absicherung der AdV-Komponenten erhoben:

Hierzu zählen bspw. der Zugriff über externe Schnittstellen zum Internet oder der TI, das Ausnutzen von Schwachstellen der installierten Software bzw. des Betriebssystems / der Firmware oder das Einbringen von Schadsoftware. Je nach Ausgestaltung und Funktionsumfang können geeignete Maßnahmen bspw. sein:

• Härtung des Betriebssystems (nur notwendige Software / Dienste)
• Schließen nicht verwendeter Ports
• Einsatz einer Stateful Packet Inspection/Firewall
• Einsatz von Intrusion Detection/Prevention Systemen
• Validierung von eingehenden Anfragen
• Einsatz einer Antiviren-Software inklusive regelmäßiger Aktualisierung dieser Software
• ggf. logische Trennung von anderen Anwendungen (Virtualisierung).

Mit dieser Anforderung soll erreicht werden, dass die AdV-App über den offiziellen Weg des Herstellers bzw. die technologischen Standardmechanismen einer Plattform verteilt wird. Bspw. sollte der Play-Store für die Verteilung einer Android-Variante der AdV-App verwendet werden und für PC-Installationen sollte die Anwendung von der offiziellen Website des Anbieters herunterladbar sein. Nutzer müssen ausreichend informiert werden. Zum Beispiel könnte auf der Website des Anbieters der Name und der Hersteller der AdV-App genannt werden, damit diese im jeweiligen App-Store leicht zu identifizieren ist. Ziel ist es, dem Nutzer der AdV-App Sicherheit zu geben, dass er die richtige AdV-App nutzt.

Die Reaktionszeiten auf Schwachstellen sind vom Hersteller für die einzelnen Softwarekomponenten anzugeben und werden im Rahmen der Sicherheitsprüfung bewertet.

Für die Umsetzung sind bspw. folgende Maßnahmen sinnvoll:

• Die AdV-App implementiert ein virtuelles PIN-Pad um eine externe Softwaretastatur zu umgehen, falls das Kartenterminal kein PIN-Pad besitzt.
• Die PIN wird nicht im Klartext angezeigt.

Die Verbindung zwischen AdV-Server und AdV-App wird mittels TLS gemäß den Vorgaben aus [gemSpec_Krypt] abgesichert.

Die AdV-App muss dabei in der Lage sein, auch ohne Verwaltung einer aktuellen TSL einen AdV-Server zu authentisieren. Daher benötigt sie einen Truststore, in dem sich bereits vor dem Verbindungsaufbau die TLS-Zertifikate der AdV-Server befinden, mit denen sie sich verbinden kann. Die TLS-Zertifikate müssen den Vorgaben von [gemSpec_Krypt] entsprechen.

Ein möglicher Grund, die Anforderung AdV-A_2572 nicht umzusetzen, ist die Verwendung einer Plattform für die Ausführung der AdV-App, die einen eigenen Truststore anbietet und dessen Verwendung verlangt.

Damit die AdV-App stets aktuelle Zertifikate der AdV-Server erhält, ist ein Verfahren notwendig, den lokalen Truststore der AdV-App initial zu befüllen und zu aktualisieren. Dies kann zum Beispiel durch neue Versionen der AdV-App – welche einen aktualisierten Truststore enthalten – realisiert werden. Es sind aber auch andere Verfahren denkbar.

Hinweis: Der Hersteller der AdV-App muss bei der Dokumentation der Voraussetzungen die Einsatzumgebung der AdV-App unterscheiden. Es sind zum einen die Voraussetzungen für den Betrieb einer AdV-App auf einem Endgerät des Versicherten, zum anderen die Voraussetzungen für den Betrieb einer AdV-App auf einem KTR-AdV-Terminal zu beschreiben.

5.1.3 Verbindungsaufbau und Freischaltung eGK

In diesem Kapitel ist der Verbindungsaufbau von der AdV-App zum AdV-Server und die anschließende Freischaltung der eGK durch ein Card-to-Card (C2C) beschrieben, welche im Rahmen des Anwendungsfalls „Starten einer Sitzung“ durchgeführt werden.

Abbildung 6 : ABB_ADV_333 Verbindungsaufbau und Freischaltung eGK

Das Institutskennzeichen entspricht der 9-stelligen Nummer aus dem Organizational Unit Name im Subject Distinguished Name des C.CH.AUT-Zertifikates des Versicherten.

Ein CV-Zertifikat C.KTRADV.AUTR_CVC.E256 hat das Zugriffsprofil CHA.0 und besitzt keine Rechte zum Freischalten der eGK.

Die Zuordnung zwischen der eGK und der SM-B des Herausgebers kann anhand der von der AdV-App übermittelten IK-Nummer erfolgen.

Die erwartete Antwort der eGK auf das Kartenkommando Get PIN Status ist NoError (‚90 00‘).

Ein CV-Zertifikat C.SMC.AUTR_CVC.E256 hat das Zugriffsprofil CHA.1. Das einseitige Card-to-Card schaltet die eGK frei. Der für die Statusabfrage aufgebaute Trusted Channel kann abgebaut werden.

Für Erläuterungen zum Card-2-Card und der Prüfung des Status einer PIN siehe auch [gemSpec_CardProxy].

5.1.4 Filterung von Kartenkommandos an die eGK

Während der Freischaltung der eGK durch ein Card-to-Card und der Onlineaktualisierung der VSD findet eine direkte Kommunikation zwischen der eGK und dem AdV-Server bzw. den Fachdiensten VSDM über den AdV-Server statt. Damit eine freigeschaltete eGK nicht durch einen manipulierten AdV-Server ausgelesen werden kann, muss die AdV-App alle Kartenkommandos, welche über den AdV-Server an die eGK gesendet werden, prüfen.

5.2 Logging

Der AdV-Server und die AdV-App auf dem KTR-AdV-Terminal sollen Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Bei der Erstellung von Einträgen in ein Protokoll bzw. Log sind die Anforderungen aus Kapitel 5.1.1 Verarbeitung personenbezogener Daten umzusetzen.

Ein Logging der AdV-App auf Geräten des Versicherten ist nicht vorgesehen.

Es gelten die übergreifenden Anforderungen zum Logging aus [gemSpec_OM].

Die Rolle des Testbetriebsverantwortlichen ist im Testkonzept [gemKPT_Test] beschrieben.

5.3 Nicht-funktionale Anforderungen

Die KTR-AdV ist ein dezentraler Produkttyp der TI, welcher nicht direkt in den Versorgungsprozess beim Leistungserbringer eingebunden ist. Die Beauftragung zur Umsetzung erfolgt durch die Kostenträger. Diese haben durch eine Integration der AdV-Lösung in ihre Onlinestrategie eine Möglichkeit, Mehrwert für ihre Versicherten zu schaffen. Aus diesem Grund werden Anforderungen zur Verfügbarkeit und Performance der KTR-AdV nicht durch die gematik, sondern durch den beauftragenden Kostenträger gestellt.

6 Funktionsmerkmale

6.1 Implementation der AdV Anwendungsfälle

Die folgenden Anwendungsfälle beschreiben das Außenverhalten des Systems anhand der Implementierung von AdV-Anwendungsfällen. Diese sind für den Versicherten zur Verwaltung seiner elektronischen Gesundheitskarte ausgelegt. Jeder Anwendungsfall wird durch den Versicherten eigenständig initiiert.

Dieses Kapitel beschreibt die übergreifenden Funktionalitäten der AdV Anwendungsfälle. Zur Realisierung dieser Funktionalitäten werden

• Leistungen der TI-Plattform (Plattformleistungen „PL_TUC_*“) aus [gemSpec_Systemprozesse_dezTI] und
• spezifische Fachlogik aus den entsprechenden (Fach-)Modulen NFDM [gemSpec_FLA_NFDM] und VSDM [gemSpec_FM_VSDM]

eingesetzt.

Falls während der Ausführung eines Plattformbausteins ein Fehler auftritt, liefert dieser einen Fehlercode zurück. Falls diese Fehler im lokalen Kontext des Anwendungsfalls lösbar sind, wird diese Behandlung des Fehlers dort beschrieben. Alle weiteren Fehler werden wie folgt behandelt:

6.1.1 AdV-Sitzung des Versicherten

Nach der erfolgreichen Initialisierung der AdV-Sitzung kann der Versicherte Anwendungsfälle zur Verwaltung seiner Gesundheitskarte ausführen, bspw. PINs auf seiner Karte verwalten und Anwendungsfälle weiterer Fachanwendungen ausführen.

6.1.1.1 AdV-Sitzung initialisieren

Mit diesem Anwendungsfall wird die AdV-Sitzung des Versicherten gestartet, der Start des Anwendungsfalls erfolgt implizit durch Stecken der eGK und Starten der AdV-App durch den Versicherten.

Hinweis: Unter "Stecken der eGK" kann auch der Aufbau einer Verbindung zur eGK über die kontaktlose Schnittstelle der eGK verstanden werden.

6.1.1.2 AdV-Sitzung beenden

Mit der Umsetzung dieses Anwendungsfalls wird die Sitzung des Versicherten beendet. Der Versicherte kann keine fachlichen Anwendungsfälle bis zum Start einer neuen Sitzung aufrufen. In der AdV-App und dem AdV-Server liegen keine persistent oder temporär gespeicherten, personenbezogenen oder medizinischen Daten des Versicherten vor. Auf dem Display wird eine neutrale Anzeige dargestellt.

6.1.2 Übergreifende Vorbedingungen

Die ab Kapitel 6.1.5 beschriebenen fachlichen Anwendungsfälle werden durch den Versicherten eigenständig ausgeführt, die AdV-App ruft die dort benannten Operationen nur bei explizitem Wunsch des Versicherten auf. Folgende Vorbedingungen müssen beim Start jedes Anwendungsfalls erfüllt sein.

Definiert eine Fachanwendung in ihrer Fachmodulspezifikation abweichende Kriterien oder von den in TAB_ADV_384 definierten Bedingungen abweichende Vorbedingung zur Zulässigkeit ihrer Anwendungsfälle, so sind jene der Fachanwendung bindend.

6.1.3 Hinweistext zu Fachanwendung

Nach dem Start der AdV-App und Stecken der eGK wird dem Versicherten eine Startoberfläche angezeigt, auf der klar erkennbar ist, welche Art von Daten verwaltet werden können. Hier sollen alle Anwendungen, die aktuell bereitstehen, in übersichtlicher Form angezeigt werden, auch wenn der Versicherte nicht alle Anwendungen nutzt bzw. in bestimmte Anwendungen nicht oder noch nicht eingewilligt hat.

6.1.4 Generische Anwendungsfälle

Dieses Kapitel beschreibt die generischen Anwendungsfälle, welche durch Anwendungsfälle verschiedener Fachanwendungen genutzt werden. Unter anderem wird die Möglichkeit geboten PIN-Objekte, die im Kontext einer Fachanwendung stehen, ein- oder auszuschalten.

6.1.4.1 Anwendung auf eGK deaktivieren

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.

Die folgende Abbildung ABB_ADV_305 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_14 „Anwendung auf eGK deaktivieren“ ausgeführt werden müssen.

Abbildung 7: ABB_ADV_305 – Ablauf „Anwendung auf eGK deaktivieren“

6.1.4.2 Anwendung auf eGK reaktivieren

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

Die folgende Abbildung ABB_ADV_383 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_15 „Anwendung auf eGK reaktivieren“ ausgeführt werden müssen.

Abbildung 8: ABB_ADV_383 – Ablauf „Anwendung auf eGK reaktivieren“

6.1.4.3 PIN-Verwaltung

Auf der eGK des Versicherten sind mehrere PIN-Objekte gespeichert. Wird im Aufruf der PIN-Operationen Ändern und Entsperren der Identifier einer Multireferenz-PIN (MRPIN) übergeben, so wirkt diese Operation auf die referenzierte PIN und betrifft auch alle übrigen Multireferenz-PINs, die auf diese PIN verweisen. Aktuell sind folgende PIN-Referenzen vorgesehen:

• Versicherten-PIN (PIN.CH)
  (auch verwendet als MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE, MRPIN.DPE_READ, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS)
• Vertreter-PIN für eMP/AMTS (PIN.AMTS_REP)

Die oben genannten Multireferenz-PINs können genutzt werden, um die Versicherten-PIN PIN.CH im Kontext der aktuellen Anwendung zu ändern, ohne auf der eGK zunächst in ein anderes Verzeichnis zu navigieren. Das heißt der Anwendungsfall zum Ändern oder Entsperren der Versicherten-PIN darf vom Versicherten im Kontext der jeweils aktiven Fachanwendung erfolgen, wenn der MRPIN der Fachanwendung als PIN-Referenz angegeben wird. Das Einschalten/Ausschalten einer MRPIN wirkt sich jeweils nur auf den MRPIN der referenzierten Fachanwendung aus. Die Benutzeroberfläche muss es dem Versicherten ermöglichen, den Status eines PIN-Objektes zu erfahren. Dies kann über eine Übersicht über alle PIN-Objekte oder in den Anwendungen erfolgen.

Die AMTS-Vertreter-PIN darf in den PIN-Operationen nur im Kontext der Fachanwendung AMTS referenziert werden.

6.1.4.3.1 PIN ändern

Mit der Umsetzung dieses Anwendungsfalls ändert der Versicherte eine im Parameter der Operation benannte PIN auf der eGK.

Die folgende Abbildung ABB_ADV_312 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_01: „PIN ändern“ ausgeführt werden müssen.

Abbildung 9 : ABB_ADV_312 – Ablauf des AdV-UC_01: „PIN der eGK ändern“

6.1.4.3.2 PIN auf eGK entsperren

Mit der Umsetzung dieses Anwendungsfalls entsperrt der Versicherte eine im Parameter der Operation benannte PIN auf der eGK.

Die folgende Abbildung ABB_ADV_316 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_02: „PIN auf eGK entsperren“ ausgeführt werden müssen.

Abbildung 10 : ABB_ADV_316 – Ablauf des AdV-UC_02: „PIN auf eGK entsperren“

6.1.4.3.3 PIN für Fachanwendung einschalten

Wenn die Multireferenz-PIN einer Fachanwendung deaktiviert ist, dann kann der Versicherte diese PIN mit diesem Anwendungsfall aktivieren.

Die folgende Abbildung ABB_ADV_308 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_03 „PIN für Fachanwendung einschalten“ ausgeführt werden müssen.

Abbildung 11: ABB_ADV_308 – Ablauf AdV-UC_03 „PIN für Fachanwendung einschalten“

6.1.4.3.4 PIN für Fachanwendung ausschalten

Um die Anzahl der beim Leistungserbringer notwendigen PIN-Eingaben pro Kartensteckzyklus zu minimieren, kann der Versicherte für bestimmte Fachanwendungen die Multireferenz-PIN für diese Fachanwendung deaktivieren.

Die folgende Abbildung ABB_ADV_310 zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_04 „PIN für Fachanwendung ausschalten“ ausgeführt werden müssen.

Abbildung 12: ABB_ADV_310 – Ablauf AdV-UC_04 „PIN für Fachanwendung ausschalten“

6.1.5 Verwaltung der eGK

6.1.5.1 VSD von eGK anzeigen

Mit der Umsetzung dieses Anwendungsfalls werden dem Versicherten die auf seiner eGK gespeicherten Versichertenstammdaten zur Anzeige gebracht.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_101: „VSD von eGK lesen“ ausgeführt werden müssen.

Abbildung 13: ABB_ADV_317 - Ablauf des „VSD von eGK lesen”

6.1.5.2 Zugriffsprotokoll anzeigen

Mit der Umsetzung dieses Anwendungsfalls sollen dem Versicherten das auf seiner eGK gespeicherte Zugriffsprotokoll zur Anzeige gebracht werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_21: „Zugriffprotokoll von eGK lesen“ ausgeführt werden müssen.

Abbildung 14: ABB_ADV_314 – Ablauf des AdV-UC_21: „Zugriffsprotokoll anzeigen“

AdV-A_2463 - AdV-App: Zugriffsprotokoll anzeigen

Die AdV-App MUSS den Anwendungsfall „Zugriffsprotokoll anzeigen“ gemäß TAB_ADV_350 umsetzen.

Tabelle 23: TAB_ADV_350 – Zugriffsprotokoll anzeigen

Benennung des Anwendungsfalls	„Zugriffsprotokoll anzeigen“
Hinweistext für den Versicherten	TAB_ADV_473#ADV002
Auslöser	Der Versicherte möchte das Zugriffsprotokoll seiner eGK anzeigen lassen. Dazu wählt er eine Aktion in der AdV-App aus, die das Auslesen des Protokolls startet.
Akteure	Versicherter
Vorbedingung	Siehe übergreifende Vorbedingungen.
Nachbedingung	Das Zugriffsprotokoll wird dem Versicherten angezeigt.
Standardablauf	Die Umsetzung ist in „TAB_ADV_351 – Ablaufaktivitäten – Zugriffsprotokoll anzeigen“ beschrieben. LeseRequest erzeugen LeseResponse verarbeiten Protokoll anzeigen
Diagramm	Abbildung ABB_ADV_314 – Ablauf des AdV-UC_21: „Zugriffsprotokoll anzeigen“

Tabelle 24: TAB_ADV_351 – Ablaufaktivitäten – Zugriffsprotokoll anzeigen

1. LeseRequest erzeugen
Plattformbaustein	PL_TUC_EGK_READ_PROTOCOL
Eingangsdaten
-	-
Beschreibung	Es wird das gesamte Zugriffsprotokoll auf der elektronischen Gesundheitskarte ausgelesen.
2. LeseResponse verarbeiten
Rückgabedaten
OK + Liste	„Daten wurden erfolgreich gelesen“ Beinhaltet das Zugriffsprotokoll. Den Aufbau zeigt die folgende Abbildung und wird in [gemSpec_Karten_Fach_TIP] definiert.
CorruptDataWarning +Liste	„Daten gelesen, Speicher möglicherweise defekt ” Beinhaltet das Zugriffsprotokoll. Den Aufbau zeigt die Abbildung oben.
Beschreibung	Das Auslesen des Zugriffsprotokolls auf der eGK basiert auf dem Plattformbaustein PL_TUC_EGK_READ_PROTOCOL. Dieser liefert den Status der Leseoperation und im Erfolgsfall die Recordliste zurück. Im Fehlerfall wird eine Fehlermeldung mit einem Fehlercode zurückgegeben.
3. Protokoll anzeigen
Zugriffsprotokoll zur Anzeige bringen	Die aus der eGK des Versicherten gelesenen Protokolleinträge sollen dem Versicherten vollständig zur Anzeige gebracht werden. Dazu sind sämtliche Elemente vom Typ LogEntry in einer geeigneten Form anzuzeigen. Das Protokoll umfasst bis zu 50 Einträge. Die im Protokoll enthaltenen Felder haben dabei die folgende Bedeutung: Timestamp:        Zeitpunkt, zu dem der Protokolleintrag erzeugt wurde Data Type:        Identifikator der Anwendung auf der eGK, auf die zugegriffen wurde Type of Access:        Art des Zugriffs auf die Anwendung auf der eGK Actor-ID:        Identifikator des Akteurs, des Zugriffs auf die Anwendung auf der eGK Actor Name:        Klarname des Akteurs, des Zugriffs auf die Anwendung auf der eGK

[<=]

6.1.5.3 Versicherten-PIN ändern

Mit diesem Anwendungsfall kann der Versicherte das Geheimnis der Versicherten-PIN ändern.

Für die Umsetzung wird der in Kap. 6.1.4.3.1 PIN ändern beschriebene generische Anwendungsfall genutzt.

6.1.5.4 Versicherten-PIN entsperren

Mit der Umsetzung dieses Anwendungsfalls kann die gesperrte Versicherten-PIN entsperrt werden.

Für die Umsetzung wird der in Kap. 6.1.4.3.2 PIN auf eGK entsperren beschriebene generische Anwendungsfall genutzt.

6.1.5.5 Datenübertragung bei Kartentausch

Dieser Anwendungsfall erlaubt dem Versicherten, Daten von seiner eGK auf eine weitere, d.h. ihm neu ausgestellte eGK zu kopieren. Mit der Umsetzung dieses Anwendungsfalls kann der Versicherte seine Daten – welche in der KTR Umgebung zugreifbar sind – auf eine neue eGK übertragen, wenn der Versicherte von seiner Krankenversicherung eine neue Karte ausgestellt bekommt.

Der Versicherte kann die Datenbereiche auswählen, deren Daten er auf die Zielkarte übertragen will. Dafür muss der Datenbereich dieser Anwendung(en) auf der Zielkarte leer sein. In einer Datenübertragung können ein oder mehrere Datenbereiche übertragen werden. Der Versicherte kann die Datenübertragung erneut durchführen, solange noch nicht alle Datenbereiche übertragen wurden.

Zum Zeitpunkt der Erstellung dieser Spezifikation kann in der KTR-AdV nur der Datenbereich DPE ausgewählt werden.

Die unten beschriebene Lösung sieht vor, dass am KTR-AdV-Terminal für die eGK nur ein Slot zur Verfügung steht, so dass die beiden eGKs nacheinander gesteckt werden müssen. In diesem Ausnahmefall dürfen die medizinischen Daten des Versicherten über den Steckzyklus der Quellkarte hinaus in der AdV-App gespeichert werden. Nach dem Ende des Vorgangs müssen die Daten gelöscht werden.

Die AdV-App steuert den Ablauf der Datenübertragung vom Lesen der Daten von der Quellkarte über den Wechsel der Karten bis zum Schreiben auf die neue Karte und Löschen der zwischengespeicherten Daten. Für die anwendungsspezifischen Lese- und Schreiboperationen ruft es interne Methoden der entsprechenden Fachmodule auf.

Die Datenübertragung soll auch dann möglich sein, wenn das AUT-Zertifikat der Quellkarte zeitlich abgelaufen oder online ungültig ist. Daher muss die AdV-App eine eGK auch in diesem Fall akzeptieren.

Bei den folgenden Beschreibungen wird angenommen, dass zu Beginn die Quellkarte steckt. Dies kann die AdV-App jedoch erst prüfen, wenn die Zielkarte gesteckt wurde und ihr AUT-Zertifikat ein neueres Gültigkeitsbeginn-Datum aufweist als das der anderen eGK.

Falls das Gültigkeitsbeginn-Datum der Zielkarte kleiner als das Gültigkeitsbeginn-Datum der Quellkarte ist, wird die Kopieroperation abgebrochen. Weiterhin führt zum Abbruch, wenn die Zielkarte mathematisch oder zeitlich ungültig ist oder gesperrt wurde.

Abbildung 15: ABB_ADV_315 Standardablauf – Datenübertragung bei Kartentausch durchführen

6.1.6 Verwaltung der NFD

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung des Notfalldatensatzes (NFD) beschrieben. Ein Zugriff auf medizinische Daten ist nicht möglich.

6.1.6.1 NFD auf eGK verbergen

Mit der Umsetzung dieses Anwendungsfalls soll der Notfalldatensatz des Versicherten auf seiner eGK verborgen werden.

6.1.6.2 Verborgenen NFD auf eGK sichtbar machen

Mit der Umsetzung dieses Anwendungsfalls soll der verborgene Notfalldatensatz des Versicherten auf seiner eGK sichtbar gemacht werden.

6.1.6.3 PIN für NFD einschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.NFD eingeschaltet werden.

6.1.6.4 PIN für NFD ausschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.NFD ausgeschaltet werden.

6.1.7 Verwaltung des DPE

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung der Anwendung Datensatz ‚Persönliche Erklärungen‘ (DPE) beschrieben.

6.1.7.1 Persönliche Erklärung (DPE) von eGK anzeigen

Mit der Umsetzung dieses Anwendungsfalls soll dem Versicherten der auf seiner eGK gespeicherte Datensatz Persönliche Erklärungen (DPE) zur Anzeige gebracht werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_121: „DPE von eGK anzeigen“ ausgeführt werden müssen.

Abbildung 16: ABB_ADV_359 – Ablauf des AdV-UC_121: „DPE von eGK anzeigen“

6.1.7.2 Persönliche Erklärung (DPE) auf eGK ändern

Mit der Umsetzung dieses Anwendungsfalls ändert der Versicherte eine oder mehrere Hinweise auf persönliche Erklärungen des auf der eGK gespeicherten Datensatzes Persönliche Erklärungen (DPE). Dem Ändern eines oder mehrerer Erklärungen muss ein Lesen der DPE vorausgehen, da der DPE nur im Ganzen auf die Karte geschrieben werden kann.

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

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_122: „DPE auf eGK ändern“ ausgeführt werden müssen.

Abbildung 17: ABB_ADV_361 – Ablauf des AdV-UC_122: „DPE auf eGK ändern“

6.1.7.3 Persönliche Erklärung (DPE) auf eGK löschen

Mit der Umsetzung dieses Anwendungsfalls löscht der Versicherte den gesamten Datensatz seiner persönlichen Erklärungen (DPE) auf der eGK.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_123: „DPE auf eGK löschen“ ausgeführt werden müssen.

Abbildung 18: ABB_ADV_363 – Ablauf des AdV-UC_123: „DPE auf eGK löschen“

6.1.7.4 PIN für DPE einschalten

Mit diesem Anwendungsfall kann der Versicherte die technische Notwendigkeit der Verifikation der MRPIN.DPE einschalten.

6.1.7.5 PIN für DPE ausschalten

Mit diesem Anwendungsfall kann der Versicherte die technische Notwendigkeit der Verifikation der MRPIN.DPE ausgeschalten.

6.1.7.6 Persönliche Erklärung (DPE) auf eGK verbergen

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

6.1.7.7 Verborgene DPE auf eGK sichtbar machen

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

6.1.8 Verwaltung eMP/AMTS

In diesem Abschnitt sind die Anwendungsfälle für die Verwaltung der Daten des elektronischen Medikationsplans und zur Prüfung der Arzneimitteltherapiesicherheit beschrieben. Ein Zugriff auf medizinische Daten ist nicht möglich.

6.1.8.1 AMTS-Vertreter-PIN ändern

Mit der Umsetzung dieses Anwendungsfalls kann die AMTS-Vertreter-PIN auf der eGK gesetzt oder geändert werden.

Für die Umsetzung wird der in Kap. 6.1.4.3.1 PIN ändern beschriebene generische Anwendungsfall genutzt.

6.1.8.2 AMTS-Vertreter-PIN entsperren

Mit diesem Anwendungsfall kann der Versicherte die gesperrten AMTS-Vertreter-PIN entsperren.

Für die Umsetzung wird der 6.1.4.3.2 PIN auf eGK entsperren beschriebene generische Anwendungsfall genutzt.

6.1.8.3 eMP/AMTS Datensatz verbergen

Mit der Umsetzung dieses Anwendungsfalls soll der eMP/AMTS-Datensatz des Versicherten auf seiner eGK verborgen werden.

6.1.8.4 Verborgenen eMP/AMTS Datensatz sichtbar machen

Mit der Umsetzung dieses Anwendungsfalls soll der verborgene eMP/AMTS-Datensatz des Versicherten auf seiner eGK sichtbar gemacht werden.

6.1.8.5 PIN für AMTS einschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.AMTS eingeschaltet werden.

6.1.8.6 PIN für AMTS ausschalten

Mit diesem Anwendungsfall soll die technische Notwendigkeit der Verifikation der MRPIN.AMTS ausgeschaltet werden. Das Ausschalten der MRPIN.AMTS ist bei eGK ab der Generation G2.1 möglich.

6.1.9 Fachanwendungsunabhängige Anwendungsfälle

Dieses Kapitel beschreibt Anwendungsfälle, die keiner spezifischen Fachanwendung zugeordnet sind.

6.1.9.1 Mit eGK verschlüsseln

Der Anwendungsfall ermöglicht es dem Versicherten, mit der AdV-App ein Dokument mit der eGK zu verschlüsseln.

Dieser Anwendungsfall zielt auf die @home-Umgebung, da der Versicherte dort auf einen Datenträger (z.B. USB-Stick oder lokale Festplatte) mit privaten Dokumenten zugreifen kann. In der @home-Umgebung kann in dem Anwendungsfall eine Datei auf einem lokalen Datenträger des Versicherten selektiert und der Ablageort für das Ergebnis definiert werden.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_25: „Mit eGK verschlüsseln“ ausgeführt werden müssen.

Abbildung 19: ABB_ADV_322 – Ablauf des AdV-UC_25: "Mit eGK verschlüsseln"

6.1.9.2 Mit eGK entschlüsseln

Der Anwendungsfall ermöglicht es dem Versicherten, mit der AdV-App ein Dokument mit der eGK zu entschlüsseln.

Analog zum Anwendungsfall „Mit eGK verschlüsseln“ zielt dieser Anwendungsfall auf die @home-Umgebung, da der Versicherte dort auf seine privaten Dokumente zugreifen kann.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_26: „Mit eGK entschlüsseln“ ausgeführt werden müssen.

Abbildung 20: ABB_ADV_324 – Ablauf des AdV-UC_26: „Mit eGK entschlüsseln“

6.1.9.3 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).

Die folgende Abbildung zeigt informativ, welche Schritte für Operation „Authentisierungsrequest mit eGK signieren“ ausgeführt werden müssen.

Abbildung 21: ABB_ADV_379 – Ablauf des AdV-UC_27 „Authentisierungsrequest mit eGK signieren“

6.1.9.4 Zertifikat von eGK lesen

Anwendungsfall AdV-UC_24: Zertifikat von eGK lesen wird ausgelöst, wenn ein externes Programm oder Clientsystem von der eGK des Versicherten ein Zertifikat lesen will.

Die folgende Abbildung zeigt informativ, welche Schritte für Anwendungsfall AdV-UC_24: Zertifikat von eGK lesen ausgeführt werden müssen.

Abbildung 22: ABB_ADV_381 – Ablauf AdV-UC_24: Zertifikat von eGK lesen

6.2 Realisierung der Leistungen der TI-Plattform

Der Produkttyp KTR-AdV realisiert die von den Fachanwendungen benötigten Leistungen der TI-Plattform, die in den fachlichen Anwendungsfällen der AdV genutzt werden. Die bereitgestellten Leistungen umfassen einen für die Fachanwendungen einheitlichen Zugriff auf die eGK des Versicherten, Leistungen der PKI der Telematikinfrastruktur, Kryptooperationen, etc. die in übergreifenden Spezifikationen der gematik festgelegt sind. Die Definition der Leistungen der TI-Plattform in der KTR-AdV finden sich in [gemSpec_Systemprozesse_dezTI].

Die KTR-AdV verwendet die in der Tabelle TAB_FM_ePA_KTR_019 dargestellten Plattformleistungen.

Tabelle 58: TAB_AdV_302 - Verwendete Plattformleistungen

Zusätzlich muss in der Realisierung der Leistung der Plattform – wie in 2.2 beschrieben – festgelegt werden, wie umgebungsspezifische Operationen an der Schnittstelle zu den Leistungen der TI-Plattform umgesetzt werden sollen. Diese Festlegungen werden in den folgenden Abschnitten festgelegt.

6.2.1 Transportschnittstelle für Kartenkommandos

Der hier beschriebene Produkttyp KTR-AdV ist als reines Softwareprodukt konzipiert. Als solches muss die KTR-AdV eine Schnittstelle zu Karten der TI über ein Kartenterminal herstellen. Diese Schnittstelle muss die von den Plattformprozessen erzeugten, kartenverständlichen APDUs an die Karte übertragen und wird im Folgenden als ENV_TUC_CARD_APDU_TRANSPORT bezeichnet. Neben proprietären Schnittstellentreibern von Kartenterminalherstellern existieren eine Reihe standardisierter Schnittstellen, die auch von verschiedenen Betriebssystemen zur Anbindung handelsüblicher Kartenterminals unterstützt werden.

Auf Seiten des Versicherten können Kartenterminalvarianten der Sicherheitsklassen 1 (reine Kontaktiereinheit), 2 (Kartenterminal mit eigenem PIN-Pad) oder 3 (PIN-Pad plus Display) zum Einsatz kommen. Zusätzlich ist die Ausstattung des eingesetzten Kartenterminals (Klasse 1, 2 oder 3) mit einer NFC-Schnittstelle möglich. Der Hersteller der KTR-AdV muss die von den Varianten gebotenen Features geeignet nutzen.

Das temporäre Speichern bezieht sich bei der Verwendung eines Kartenterminals der Sicherheitsklasse 1 auf das Verwenden der PIN über den Anwendungsfall hinaus, für den die PIN-Eingabe erfolgt ist, z.B. Caching während einer Sitzung. Gelangt die KTR-AdV bei der Verwendung eines Kartenterminals der Sicherheitsklassen 2 und 3 ggfs. durch Fehlkonfiguration in Kenntnis der PIN, darf es diese ebenfalls nicht temporär und nicht persistent speichern.

Auf Seite der Komponente AdV-Server in einem Rechenzentrum sind zusätzliche Varianten der Einbeziehung der Identitäten der Kostenträger in die Kartenoperationen möglich, wie z.B. Nutzung einer Webservice-Schnittstelle zu einem HSM oder das SICCT-Protokoll zur Anbindung eines HSM-B.

6.2.1.1 Kartenterminals der Sicherheitsklasse 1

Kartenterminals der Sicherheitsklasse 1 verfügen über keine Sicherheitsmerkmale, sie sind eine reine Kontaktiereinheit einer SmartCard. Sämtliche Geheimnis-Eingaben und Hinweistext-Ausgaben müssen über die KTR-AdV mittels Bildschirm und Tastatur/Maus erfolgen.

6.2.1.2 Kartenterminals der Sicherheitsklasse 2

Kartenterminals der Sicherheitsklasse 2 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses. Typischerweise werden Kartenterminals der Sicherheitsklasse 2 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

6.2.1.3 Kartenterminals der Sicherheitsklasse 3

Kartenterminals der Sicherheitsklasse 3 verfügen über eine Eingabeschnittstelle zur Eingabe eines Benutzergeheimnisses und Ausgabeschnittstelle zur Anzeige kurzer Textmeldungen. Typischerweise werden Kartenterminals der Sicherheitsklasse 3 in Anwendungsfällen mit Eingabe einer PIN bzw. PUK so angesteuert, dass das vorbereitete Kartenkommando mit einem Platzhalter des PIN-Geheimnisses an das Kartenterminal geschickt wird. Das Kartenterminal nimmt die PIN über die Eingabeschnittstelle entgegen, ersetzt den Platzhalter durch das eingegebene Geheimnis und leitet das Kartenkommando anschließend weiter an die Karte.

Während des Wartens auf eine Benutzereingabe kann ein an das Kartenterminal übergebener Text angezeigt werden. Einzelne Eingaben durch einen Benutzer werden in der Regel durch „*“-Zeichen quittiert. Ebenso besitzen Kartenterminals der Sicherheitsklasse 3 meist zusätzliche Logik, z.B. Eingaben zu verifizieren (siehe Anforderungen zum Ändern einer PIN mittels Klasse 1-Kartenterminal). Auf diese Logik soll hier nicht weiter eingegangen werden.

Die Anzeige eines Benutzerhinweises soll den Benutzer informieren zu welchem Zweck er eine Eingabe tätigen soll (z.B. alte Pin, neue PIN im Anwendungsfall PIN ändern) und welches konkretes Geheimnis abgefragt werden soll (PIN, PUK, PIN einer konkreten Anwendung).

6.2.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI

Anwendungsfälle zur PIN-Verwaltung, die Kartenfreischaltung und Anwendungsfälle weiterer Fachanwendungen können die Eingabe eines PIN- oder PUK-Geheimnisses durch den Versicherten erfordern. Der Zugriff auf Karten der TI erfolgt über die Systemprozesse PL_TUC_CARD_*. Die KTR-AdV als Realisierungsumgebung der Systemprozesse muss ihrerseits die von der Plattform geforderten Schnittstellen ENV_TUC_CARD_SECRET_INPUT implementieren, um die Kommunikation der Plattform mit dem Benutzer über die Außenschnittstelle der KTR-AdV zu ermöglichen. Die Außenschnittstelle ist in Kapitel 6.2.1 Transportschnittstelle für Kartenkommandos beschrieben und umfasst das Kartenterminal, Eingabemedium und Hinweistexte an den Benutzer. Diese kann je nach Konfiguration an einem Gerät als Kartenterminal der Sicherheitsklasse 3 oder auch eine Kombination aus Bildschirmausgabe, Kartenterminal-PIN-Pad und/oder Tastatureingabe erfolgen.

6.2.3 Schnittstelle zur Freischaltung der eGK

Um dem Versicherten zur Verwaltung seiner eGK die notwendigen Zugriffsrechte einzuräumen, muss die eGK über ein Card-2-Card-Verfahren freigeschaltet werden. Die Systemprozesse der TI-Plattform benötigen dafür eine vertrauliche, integre und authentische Schnittstelle zum Austausch von eGK-Challenge und einer Signatur dieser Challenge durch die SM-B-Identität der Kostenträger, die die Echtheit des Zertifikats und den Besitz des privaten Schlüssels zu diesem Zertifikat bestätigt.

In der Realisierungsumgebung der KTR-AdV muss dazu ein gesicherter Kanal zwischen der AdV-App beim Versicherten und dem AdV-Server in einem Rechenzentrum hergestellt werden. Anforderungen an diese gesicherte Verbindung werden im Kapitel "5.1.2 Absicherung der AdV-Komponenten" beschrieben.

6.2.4 Schnittstelle zu Diensten der zentralen TI-Plattform

Über einen sicheren zentralen Zugangspunkt (SZZP) stehen dem AdV-Server Dienste der zentralen TI-Plattform zur Verfügung.

Über den Consumer Adapter werden die in ABB_ADV_302 und in TAB_ADV_301 dargestellten Schnittstellen zu Diensten der zentralen TI-Plattform und zu Fachdiensten bereitgestellt.

Abbildung 23: ABB_ADV_302 - Schnittstellen des TIP Consumer Adapters

Tabelle 59: TAB_AdV_301 - Schnittstellen des Consumer Adapters

6.3 Schnittstelle zwischen AdV-App und AdV-Server

Die Schnittstelle zwischen der AdV-App und dem AdV-Server liegt innerhalb des Produkttyps KTR-AdV. Es handelt sich daher um eine Innenschnittstelle. An diese werden keine inhaltlichen Anforderungen gestellt. Es werden jedoch Sicherheitsanforderungen im Kapitel 5.1.2 hierzu erhoben.

6.4 Identitäten der KTR-AdV

In der Beschreibung der Leistungen der dezentralen TI-Plattform in [gemSpec_Systemprozesse_dezTI] sowie in der Plattformkomponente CardProxy erfolgt die Schnittstellendefinition für den Zugriff auf die SM-B-Identitäten und deren kryptografisches Schlüsselmaterial auf Basis einer SMC-B mit entsprechendem Objektsystem.

Mit der Verwendung eines HSM und einer herstellerspezifischen Schnittstelle für den HSM-Zugriff können sich sowohl die Schnittstellenoperationen als auch die Bezeichner der entsprechenden SM-B-Identitäten von denen in der Spezifikation der KTR-AdV unterscheiden. Diese Abweichung ist ausdrücklich zulässig, soweit die Realisierung protokollarische Vorgaben und das geforderte Sicherheitsniveau einhält.

Die KTR-AdV benötigt zwei Rollen mit entsprechenden Identitäten zur Abbildung der oben genannten Anwendungsfälle. Als Kostenträgerorganisation soll sie dem Versicherten Zugriffsrechte auf seiner eGK zur Durchführung der AdV-Anwendungsfälle freischalten. Die Angaben zu dieser Kostenträgerorganisation werden auch zur Vervollständigung des obligatorischen eGK-Protokolleintrags verwendet.

Des Weiteren muss sich die KTR-AdV mit fachanwendungsspezifischen Fachdiensten verbinden können. Hierzu muss sie als Rechenzentrums-Consumer in einer passenden Rolle authentisiert werden.

Diese zwei Aspekte müssen in der KTR-AdV über Zertifikate abgebildet werden, deren zugehöriges kryptografisches, privates Schlüsselmaterial in der Realisierung der KTR-AdV integritätsgeschützt und vertraulich gespeichert werden muss.

Die Anbindung an den AdV-Server in einem Rechenzentrum kann über eine herstellerspezifische Schnittstelle mit einem handelsüblichen HSM erfolgen, die die oben genannten Sicherheitsziele erfüllt. Eine Anbindung eines HSM-Bs via SICCT ist nicht zwingend erforderlich.

Zum Zeitpunkt der Fertigstellung dieser Spezifikation erfüllt eine zugelassene SMC-B die oben genannte Anforderung und kann als HSM eingesetzt werden.

Falls keine SMC-B als HSM zum Einsatz kommt, müssen die Zertifikate auf sichere Weise in das HSM eingebracht werden. An dieser Stelle werden keine konkreten Technologien oder Prozessschritte vorgegeben, damit der Betreiber der KTR-AdV mit einem TSP ein geeignetes Verfahren etablieren kann.

Tabelle 61: TAB_ADV_385 – Personalisierung eines HSM

Falls für diesen Prozess nur eine geringe Anzahl an Instanzen erwartet wird, kann es sinnvoll sein, Teile dieses Prozesses rein organisatorisch umzusetzen. Anstelle einer technischen Schnittstelle kann dann ein papierbasiertes Verfahren eingesetzt werden.

Abhängig von der Realisierung eines sicheren Zertifikatsspeichers in der KTR-AdV kann das Authentisierungsverfahren zur Freischaltung der eGK über ein Card-2-Card- oder auch Card-2-Server-Verfahren erfolgen.