Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme – Telematikinfrastruktur (TI)

(einschließlich VSDM, QES-Basisdienste, KOM-LE)

    

     

      
Version
      
2.22.0
     
     

      
Revision
      
930341
     
     

      
Stand
      
23.02.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Dokument beschreibt die für die Implementierung des Versichertenstammdatenmanagements und der Basisdienste QES, Signatur und Verschlüsselung in Primärsysteme erforderlichen Vorgaben.

Der Implementierungsleitfaden beschreibt darüber hinaus die praktische Anwendung folgender Konzepte und Spezifikationen:

• Systemspezifisches Konzept VSDM [gemSysL_VSDM]
• Spezifikation Fachmodul VSDM [gemSpec_FM_VSDM]
• Spezifikation Schnittstelle Primärsystem [gemSpec_SST_PS_VSDM]
• Spezifikation Mobiles Kartenterminal [gemSpec_MobKT]
• Spezifikation Konnektor [gemSpec_Kon] 

Die Kenntnis dieser Dokumente bzw. der entsprechend relevanten Teile wird als Arbeitsgrundlage für die Nutzung des vorliegenden Dokuments angenommen. Sie enthalten die normativen Vorgaben an die entsprechenden Komponenten.

1.2 Zielgruppe

Das Dokument richtet sich maßgeblich an Hersteller von Primärsystemen (Praxisverwaltungssysteme und Krankenhausinformationssysteme) von Leistungserbringern.

1.3 Geltungsbereich

Die in diesem Dokument formulierten Anforderungen sind informativ für Primärsysteme, die am Produktivbetrieb der TI teilnehmen. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben. 

Alle Anforderungen zur Durchführung von Online-Prüfungen und -aktualisierungen sowie zur Übernahme von Prüfungsnachweisen gelten für Primärsysteme gemäß der Vorgaben für vertrags(zahn)ärztliche Leistungserbringer. Dies kann Psychotherapeuten betreffen, die in einem Arztregister eingetragen sind, betrifft jedoch nicht den stationären Bereich.

Die Anforderungen können für Implementierungsleitfäden bzw. Konformitätsprofile der Sektoren verwendet werden.

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 Abgrenzung des Dokuments

Innerhalb dieses Dokuments wird auf die fachliche und technische Umsetzung in den Primärsystemen der Leistungserbringer eingegangen. 

Für nicht an der vertragsärztlichen Versorgung teilnehmende Leistungserbringer (z. B. Krankenhaus, Apotheke) sind die Anforderungen zur VSDM-Online-Prüfung und -aktualisierung sowie zum Prüfungsnachweis informativ.

Festlegungen für interne Geschäftsprozesse der Leistungserbringer sind nicht Bestandteil dieses Dokuments.

Weiterhin werden keine Festlegungen zur Zuordnung von HBA zu Primärsystem und Mandant getroffen, d.h. Identitätsmanagement sowie Rollen- und Rechteverwaltung liegen in der Hoheit des Primärsystems.

Die Aufrüstung von BCS-Kartenterminals auf den Standard eHealth-KT ist nicht Gegenstand dieses Dokuments. Der Zugriff auf BCS-Terminals vom Primärsystem aus ist ebenfalls nicht Bestandteil dieses Dokument. Entsprechende Beschreibungen finden sich im Leitfaden aus dem Basis-Rollout [gemLF_Impl_eGK] in der Version 1.4.

Die Außenschnittstelle des Konnektors wird durch [gemSpec_Kon] abschließend spezifiziert.

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 innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

Die Darstellung der Anwendungsprozesse erfolgt prinzipiell auf der Grundlage der BPMN-Modellierung.

Die Darstellung der Versichertenstammdaten mittels Klassendiagramm erfolgt in UML.

Listing, Bezeichner, Variablen oder XML-Elemente werden in Courier dargestellt.

In diesem Dokument werden die Begriffe Clientsystem und Primärsystem synonym verwendet. Der Begriff Clientsystem umfasst streng genommen zusätzlich Systeme in Geschäftsstellen der Kostenträger, welche aber nicht behandelt werden.

Der Implementierungsleitfaden beschreibt die Nutzung der Schnittstellen der

• Konnektor-Produkttypversion 1 sowie
• erst für nachfolgende Konnektor-Produkttypversionen implementierbare Konnektorschnittstellen und Anforderungen. Die Beschreibung der neu in dieser Produkttypversion des Konnektors hinzukommenden Leistungsmerkmale werden mit Benennung des logischen Versionsnamens des Konnektors gekennzeichnet, z. B. <PTV2> für den Produkttyp eines Konnektors mit der Hauptversionsnummer 2 (hier ohne Angabe von Nebenversions- und Releasenummer).

Der PS-Hersteller kann sich über den Leistungsumfang des Konnektors und seine Produkttypversion (PTV_ATV_Festlegungen, Spezifikationen, Produkttypsteckbriefe, Schnittstellenversionen usw.) auf dem Fachportal der gematik informieren (https://fachportal.gematik.de/).

2 Systemüberblick

Auf der Grundlage der Spezifikationen der Fachanwendung VSDM und der Basis-TI beschreibt der Implementierungsleitfaden (ILF) die Nutzung von Komponenten und Schnittstellen der Telematikinfrastruktur durch Primärsysteme von Leistungserbringern im Rahmen des Wirkbetriebs der TI. Die zentralen Funktionen im Wirkbetrieb der TI sind die Fachanwendung des Versichertenstammdatenmanagements und der Basisdienste QES, Signatur und Verschlüsselung.

Das Primärsystem arbeitet als dezentrales System in der Umgebung des Leistungserbringers und kommuniziert über dezentrale Komponenten der TI (Konnektor) mit der Telematikinfrastruktur.

Abbildung 1: Primärsystem im Systemkontext

Mit Beginn des Online-Rollouts werden die Kartenterminals nicht mehr direkt durch das Primärsystem kontrolliert. Der Konnektor übernimmt die Kommunikation mit den Kartenterminals und den darin befindlichen Karten. Alle Sicherheitsleistungen werden vom Konnektor erbracht, so dass das Primärsystem nicht mehr direkt auf die Karten zugreift, sondern diese Aufgaben an den Konnektor delegiert.

Die Kommunikation zum Konnektor geschieht mittels SOAP an die vom Konnektor bereitgestellten Webservice-Schnittstellen. Ausnahmen hiervon bilden

• das Auslesen der verfügbaren Dienste am Dienstverzeichnisdienst des Konnektors (http),
• das Auslesen der Versichertenstammdaten aus mobilen Kartenterminals (CT-API),
• und das Übermitteln von Ereignissen vom Ereignisdienst des Konnektors an das Primärsystem (cetp).

Abbildung 2: Komponenten und Schnittstellen am Primärsystem

Abbildung 2: Komponenten und Schnittstellen am Primärsystem stellt die Komponenten und Schnittstellen abstrakt dar und verwendet keine formalen Namen von Schnittstellen. Die Verbindung in die TI ist stark vereinfacht und dient nur der Übersicht.

Das mobile Kartenterminal (mobKT) wird über eine seitens des Primärsystems bereits existierende Schnittstelle angesprochen (CT-API), was in der entsprechenden Spezifikation normativ beschrieben ist [gemSpec_MobKT]. Gegenstand dieses Dokuments sind die „neuen“ Schnittstellen des PS zum Konnektor. Die Schnittstelle zum mobilen Kartenterminal (mobKT) ist daher nicht Bestandteil dieses Dokuments und ist nur der Vollständigkeit halber dargestellt.

3 Konfiguration

3.1 Umgebung des Leistungserbringers

3.1.1 Begriffe der Konfigurationseinheiten

• Mandant (M): Ein Mandant ist innerhalb des Primärsystems eine eigenständige Organisationseinheit (z. B. ein Vertragsarzt). Der Datenhaushalt eines Mandanten ist in sich abgeschlossen. Werden innerhalb des Primärsystems mehrere Mandanten verwaltet, werden die Datenhaushalte voneinander abgegrenzt.
• Primärsystem (PS): Unter dem Begriff Primärsystem werden die Praxisverwaltungssysteme (PVS) in Arzt-/Zahnarztpraxen, ggf. Praxen von Psychotherapeuten, die Krankenhausinformationssysteme (KIS) und die Apothekerverwaltungssysteme (AVS) zusammengefasst.
• Arbeitsplatz (AP): Ein Arbeitsplatz ist eine fest installierte Einheit bestehend aus Bildschirm, Tastatur, Arbeitsplatzrechner und Kartenterminal und kann von mehreren Personen benutzt werden.
• Kartenterminal (KT): Mit der Einführung der Telematikinfrastruktur kommt ein durch die gematik GmbH zugelassenes, netzwerkgestütztes eHealth-Kartenterminal zur Anwendung. Das Kartenterminal kann entweder am Online- oder am Offline-Konnektor angeschlossen sein.
• Online-Konnektor: Konnektor, der online mit der TI verbunden ist
• Offline-Konnektor: Konnektor ohne Online-Zugang zur TI.
• Das mobile Kartenterminal (mobKT) ist ein durch die gematik GmbH zugelassenes, offline arbeitendes Kartenterminal für mobile Einsatzszenarien (z.B. Hausbesuch), welches zur Datenübernahme direkt an das Primärsystem angeschlossen und über Standardprotokolle von Kartenterminals (CT-API) angesprochen wird. Das mobKT wird nicht über den Konnektor verwaltet und nicht über dessen Schnittstellen angesprochen. Es ist nicht Bestandteil der Konnektorkonfiguration.

3.1.2 Beziehungen der Konfigurationseinheiten

Im folgenden Diagramm und den nachfolgenden Tabellen werden die möglichen Konfigurationen in medizinischen Einrichtungen dargestellt.

Abbildung 3: Grober Überblick über Konfigurationseinheiten

Eine tabellarische Aufstellung der Beziehungen zwischen den Konfigurationseinheiten befindet sich im Anhang 9.1.2.

Für die Zuordnung zwischen Karten und Akteuren gelten folgenden Annahmen/Festlegungen

• Eine SMC-B kann einem oder mehreren Mandanten zugeordnet werden.
• Ein HBA ist immer einem Heilberufler (z. B. Arzt) zugeordnet, entspricht also genau einer natürlichen Person.
• Es gibt keine feste Zuordnung von HBA zu Mandant. Ein Heilberufler kann im konkreten Umfeld einer Leistungserbringerorganisation mehreren Mandanten (Organisationen) zugeordnet sein.

Mandantenfähige Primärsysteme sind in der Lage, eine strikte Datentrennung für die einzelnen Mandanten durchzusetzen. Der Konnektor unterstützt diese Mandantentrennung. Der Konnektor erlaubt dazu eine mandantenbezogene Zugriffsteuerung auf die Ressourcen, die er verwaltet. Im Kern verwaltet der Konnektor die Zugriffsteuerung auf kryptographische Identitäten der Karten.

Für jeden Mandanten lassen sich separate Zugriffsregeln im Konnektor konfigurieren. Ein wichtiger Aspekt ist dabei, welcher Mandant auf welche SM-B zugreifen darf, um mit ihr beispielsweise Dokumente zu signieren oder zu entschlüsseln.

Für die Zuordnung zwischen Kartenterminals und Mandanten gelten folgende Annahmen:

• Die Mandanten einer LE-Institution sind bekannt und sollten daher statisch fest im Primärsystem konfiguriert werden.
• Der Konnektor kann so konfiguriert werden, dass mehrere Mandanten auf ein Kartenterminal zugreifen können.
• Ein Mandantenwechsel soll nur dann erfolgen, wenn er unbedingt erforderlich ist, und so implementiert sein, dass er im laufenden Betrieb wenig Aufwand verursacht (s. dazu Kapitel 3.3.1).

Wenn ein HSM-B anstelle einer SMC-B zum Einsatz kommt, verhält sich dieses aus Sicht des Primärsystems funktional wie eine SMC-B. Der Konnektor kapselt die funktionale Verwendung des HSM-B. Daher wird im Folgenden immer nur die SM-B angesprochen.

Außenstellen einer Praxis werden in diesem Dokument nicht gesondert betrachtet, da davon ausgegangen wird, dass die Außenstellen Bestandteile der Praxis sind (zusätzlicher Arbeitsplatz mit KT und z. B. VPN-Verbindung).

3.1.3 Berechtigungsregeln

Die Fachmodule im Konnektor verwenden ausdifferenzierte Berechtigungsregeln zur Kontrolle der Zugriffe auf die medizinischen Daten der eGK. Die anwendungsspezifischen Implementierungsleitfäden machen hierzu detaillierte Vorgaben.

Auf Berufsgruppen bezogene Rollendefinitionen werden technisch in den Zugriffsregeln der SMC-Bs und HBA der jeweiligen Berufsgruppen abgebildet. Anhand dieser technischen Zugriffsregeln wird im Zuge der Card-to-Card-Authentisierung zwischen eGK einerseits und SMC-B bzw. HBA andererseits die Anwendung auf der eGK ggf. freigeschaltet.

Die Berechtigungen der SMC-Bs einer Berufsgruppe sind im Allgemeinen von den Berechtigungen der HBAs einer Berufsgruppe abgeleitet, weil Heilberufler ihre SMC-B selbst nutzen und sie auch ihre Gehilfen im Allgemeinen dafür autorisieren können, auf die Anwendungen der eGK mit den gleichen Rechten zuzugreifen.

3.2 Arbeitsplätze in der Leistungserbringerumgebung

Um in der Umgebung des Leistungserbringers die Online-Prüfung und -Aktualisierung durchzuführen, können grundsätzlich drei verschiedene Szenarien verwendet werden, die sich in der Konfiguration der Arbeitsplätze widerspiegeln.

• Online-Szenario am Arbeitsplatz eines Primärsystems mit TI-Anbindung (3.2.1) oder im
• Standalone-Szenario mit Arbeitsplatz/Kartenterminal am Online-Konnektor und Lesen der VSD am Offline-Konnektor (physische Trennung, 3.2.2) sowie

Leistungserbringer, die ihr Primärsystem bzw. das lokale Netz nicht direkt über den Konnektor an die TI oder an das Internet anbinden wollen, können das Standalone-Szenario nutzen (siehe 3.2.2).

Nachfolgend werden die verschiedenen Szenarien dargestellt, wobei die Dienste nur schematisch und nicht streng zugeordnet zur TI dargestellt sind (beim Sicherheitsgateway eines Bestandnetzes (z. B. SNK) ist nur der Zugangspunkt Teil der TI).

3.2.1 Online-Szenario

Abbildung 4: Online-Szenario

Im Online-Szenario gemäß Abbildung 4 ist der Konnektor sowohl mit dem Praxisnetz als auch mit der TI, Bestandnetzen (z. B. SNK) sowie dem Secure Internet Service (SIS) verbunden (je nach Konfiguration). Alle Dienste stehen über sichere Verbindungen dem Clientsystem zur Verfügung. In der Minimalausprägung kommt nur ein Terminal am Empfang zum Einsatz, wobei der Arztarbeitsplatz ohne KT arbeiten kann, sofern entsprechende Funktionen nicht genutzt werden sollen (z. B. QES).

3.2.2 Standalone-Szenario mit Online-Konnektor und Offline-Konnektor

Abbildung 5: Standalone-Szenario mit physischer Trennung

Im Standalone-Szenario besteht keine Netzanbindung des Primärsystems an die Telematikinfrastruktur (TI). Es kommen ein zusätzlicher Konnektor und ein zusätzliches Kartenterminal zum Einsatz. Das Praxisnetz ist nicht mit dem Online-Konnektor resp. dem Internet oder Bestandnetzen (z. B. SNK) verbunden. Um die Online-Prüfung und -Aktualisierung der eGK durchzuführen, wird die eGK in das Kartenterminal am Online-Konnektor gesteckt. Die Online-Prüfung und -Aktualisierung wird daraufhin automatisch gestartet. Während der Durchführung werden dem Benutzer auf dem Display Hinweise zum Status und/oder Fehlermeldungen angezeigt (z. B. eGK gesperrt). Nach der Online-Prüfung und -Aktualisierung wird die eGK in ein am Offline-Konnektor angeschlossenes Kartenterminal gesteckt, welches standardmäßig einem Arbeitsplatz des Primärsystems zugeordnet ist, und die VSD inkl. Prüfungsnachweis werden übernommen. Der Ablauf erfolgt analog des in 4.3.4.2 beschriebenen Ablaufs.

Am Online-Konnektor ist der Betrieb eines „Kommunikations-PC“ (einzelner, nicht mit dem Praxisnetz verbundener PC) möglich, an dem – je nach Konnektorkonfiguration – alle Online-Funktionen genutzt werden können.

<PTV4>Das Standalone-Szenario verhindert die Nutzung der elektronischen Patientenakte. Daher ist bei Nutzung eines PTV4-Konnektors das Standalone-Szenario nicht zulässig.</PTV4> 

3.2.3 Parallelbetrieb-Szenario mit Internetzugriff über IAG als Default-Gateway des Clientsystems

Im Falle einer bereits vorhandenen Infrastruktur im dezentralen Bereich können die Produkte der TI, insbesondere der Konnektor, so in die Infrastruktur integriert werden, dass Bestandsanwendungen bereits erprobte Kommunikationswege weiter nutzen können.

Für die Clientsysteme muss in diesem Szenario je nach individuellem Anforderungsprofil entschieden werden, ob das jeweilige Clientsystem über die Telematikinfrastruktur kommunizieren können soll und den gesicherten Internetzugang (SIS) nutzen soll oder nicht.

Soll ein Clientsystem nicht über die Telematikinfrastruktur kommunizieren (Parallelbetrieb), bleibt der IAG als Default-Gateway dieses Clientsystems konfiguriert. In diesem Fall routet der IAG die eingehenden IP-Pakete mit öffentlichen Zieladressen weiter in das Internet. 

Im Parallelbetrieb soll das Primärsystem einen DNS-Resolver integrieren, der Anfragen zu den Domänen *.splitdns.ti-dienste.de und *.telematik an den Konnektor sendet. Im Parallelbetrieb soll das Primärsystem für offene Fachdienste und WANDA Smart eine Weiterleitung für Zieladressen aus dem Adressbereich 100.102.0.0/15 durch Konfigurieren einer Route einrichten. Für die Referenzumgebung RU ist der Adressbereich mit 10.30.0.0/15 zu konfigurieren.

Im Parallelbetrieb soll das Primärsystem eine Liste von Telematikservern (z.B. Bestandsnetze, KIM-Fachdienste oder E-Rezept-Dienste) abrufen und für die dort enthaltenen Dienste Routen zum Konnektor auf dem Primärsystemrechner hinterlegen.

Der Downloadpunkt im Internet für die Datei Bestandsnetze.xml lautet
http://download.crl.ti-dienste.de/bestandsnetze 
Neben der Datei Bestandsnetze.xml befindet sich unter dem Downloadpunkt auch die Signaturdatei Bestandsnetze.sig.
Bevor das Clientsysstem die Datei Bestandsnetze.xml verarbeitet, muss ihre Gültigkeit geprüft werden. Diese Prüfung muss aus zwei Schritten bestehen:

• Das Clientsystem prüft die Signatur der Datei Bestandsnetze.xml (die Datei Bestandsnetze.sig) auf Gültigkeit über die Außenoperation VerifyDocument des Konnektors.
• Das Clientsystem prüft das dazugehörige Signaturzertifikat über die Außenoperation VerifyCertificate des Konnektors.
• • Das Clientsystem untersucht dabei das Ergebnis von VerifyCertificate, ob die zurückgegebene technische Rolle "oid_bestandsnetze" ist.

3.3 Arbeitsplätze, Mandanten und Kartenterminals konfigurieren

Der Konnektor hat keine eigene Benutzerverwaltung und vertraut der Benutzerverwaltung (Konfigurationsverwaltung) des Primärsystems (vgl. [gemKPT_Arch_TIP#4.2]).

In der Konfiguration des Primärsystems wird die Zuordnung zwischen Mandanten, Karten, Arbeitsplätzen und Kartenterminals verwaltet sowie die eindeutige Zuordnung zwischen Heilberuflern und ihren UserIDs.

Die Konfigurationsverwaltung des Primärsystems ermöglicht es einem Konnektor-Administrator, diese Parameter so in der Konnektorkonfiguration zu verwenden, dass sie der Konfiguration im Primärsystem entsprechen.

3.3.1 Aufrufkontext

Der Konnektor benötigt von seinen Clientsystemen die Angabe des Kontextes, aus dem heraus die Aufrufe erfolgen, um Aufrufberechtigungen überprüfen zu können. Im Aufrufkontext von Funktionsaufrufen sind Angaben zu Mandant, Arbeitsplatz und Primärsystem verpflichtend, Identifikation des Benutzers ist optional (für bestimmte Aufrufe notwendig).

Abbildung 6: Abb_ILF_PS_Element_Context_gemäß_ConnectorContext.xsd

Die Parameter MandantId, ClientSystemId und WorkplaceId bilden das Datenelement Context, gemeinsam mit der optionalen und nur für den Zugriff auf den HBA in einigen Aufrufkontexten erforderlichen UserId.

Mandantenfähige Primärsysteme sollen Identifikatoren als MandantId verwenden, die ihrer internen Mandantenverwaltung entsprechen, falls vorhanden. Nicht jedem Mandant muss zwingend eine eigene, separate SM-B zugeordnet werden, vielmehr können mehrere Mandanten dieselbe SM-B verwenden. Die Leistungserbringerinstitution soll Mandanten gemäß ihrer Bedürfnisse konfigurieren. (vgl. auch Kapitel 4.2.3 und Kapitel 3.3.3). Die Konfigurationen der Kontextparameter am Primärsystem und am Konnektor müssen dabei identisch gestaltet werden. Die Parameter im Primärsystem müssen hierzu editierbar sein.

Nicht mandantenfähige Primärsysteme oder solche, in denen immer nur ein Mandant vorhanden ist, müssen die MandantId durchgängig auf einen festgelegten Wert setzen, welcher dem Wert in der Konnektorkonfiguration entspricht. Die Parameter im Primärsystem müssen hierzu editierbar sein.

Das Primärsystem einer LE-Umgebung muss einen Identifikator besitzen, der für Konnektoraufrufe als Primärsystem-Identifier (ClientSystemId) genutzt werden kann. Für jedes Clientsystem muss eine eigene ClientSystemId verwendet werden.

Jeder Arbeitsplatz mit einem lokalen Kartenterminal innerhalb einer LE-Umgebung muss einen lokal eindeutigen Identifikator besitzen, der als WorkplaceId genutzt werden kann. Gibt es mehrere Arbeitsplätze ohne lokales Kartenterminal, können diese über eine WorkplaceID im Informationsmodell abgebildet werden. An diesen Arbeitsplätzen können nur Anwendungsfälle ausgeführt werden, für die weder eine Karte gesteckt, noch ein PIN eingegeben werden muss (z.B. KIM, ePA). Erfolgen Aufrufe des Primärsystems nicht direkt vom Arbeitsplatzsystem (im Sinne eines Rich Clients), sondern werden über eine Server-Komponente des Primärsystems geleitet (Thin Client, z. B. Web-Applikationen) muss der Server trotzdem eine Arbeitsplatz-ID des Aufrufers an den Konnektor übermitteln.

Die UserId ist eine von einem Clientsystem vergebene, innerhalb des Clientsystems eindeutige ID für den Nutzer des HBA, die nur bei Zugriffen auf einen HBA erforderlich ist. Sie wird temporär im Konnektor gespeichert und einem Clientsystem und HBA zugeordnet, wenn eine HBA-Kartensitzung in einen erhöhten Sicherheitszustand versetzt wird (PIN-Eingabe). Sie bleibt gespeichert und zugeordnet, solange die Kartensitzung gültig ist (i. d. R. solange der HBA gesteckt bleibt). Bei Zugriffen auf den HBA im weiteren Verlauf muss die bei der Eröffnung verwendete UserId im Kontext korrekt angegeben sein (z. B. Signatur oder Entschlüsselung). Das PS kann als UserID eine persistente interne Referenz eines Benutzers oder eine temporär generierte ID verwenden. Es muss sicherstellen, dass sie eindeutig ist und nicht mehrfach für verschiedene Benutzer verwendet wird. Ein Login-Name oder ein Klartextname sollten nicht verwendet werden. Bei der Komfortsignatur wird die UserID wie ein Token verwendet (siehe Kapitel Komfortsignatur).

3.3.2 LE-Umgebungen

Mehrere Selektionsstrategien sind möglich:

• Setzen von selektierenden Parametern in den Funktionsaufrufen von GetCards und GetCardTerminals aufgrund von konfigurativen Zuordnungen zwischen Arbeitsplatz und Kartenterminal
• Nutzung des Ereignisdienstes durch zielgerichtetes Abonnieren von Kartensteckereignissen (s. 4.1.4)
• Dialogsteuerung zur Auswahl unter verfügbaren Karten. Ein Auswahldialog kann notwendig sein, wenn an einem Arbeitsplatz mehrere Karten verfügbar sind, mit denen gleichartige Aktionen möglich sind. Ein Beispiel wäre die Auswahl unter mehreren am selben Arbeitsplatz verfügbaren SM-B oder HBAx im Rahmen des Signierens von Dokumenten. Auswahldialoge sollen vermieden werden, wenn sie nicht durch Anwendungsfälle motiviert sind.

Das Primärsystem sollte für Zugriffe auf TI-Komponenten von unterschiedlichen Arbeitsplätzen aus unabhängige Anfragen durchführen, ohne selbst zu versuchen, die Abarbeitung durch ein Pipelining zu steuern. Zeitgleiche Zugriffe durch unterschiedliche Clients auf dieselbe Smartcard werden vom Konnektor koordiniert und nach Vorgabe von [gemSpecPerf#4.1.2] in Hinsicht auf die Performance der Ressourcenzugriffe optimiert.

Für die Kartenzugriffe ReadVSD und SignDocument (QES) reserviert der Konnektor beteiligte Smartcards innerhalb der Anwendungsfälle, damit sich Anwendungsfälle bei der Nutzung der Kartenressourcen nicht gegenseitig stören.

3.3.3 Größere LE-Umgebungen

In größeren LE-Umgebungen werden mehrere SMC-Bs oder Mandanten eingesetzt. Bei der Konfiguration des Infomodells des Konnektors sind durch den Dienstleister vor Ort per Administration persistent „Mandant“ für die vorgesehene Anzahl von Mandaten, „SM-B_Verwaltet“ sowie entsprechende Entitätenbeziehungen zwischen Mandant und SM-B aufzunehmen.

Im Normalfall ist ein LE-Institution gesamthaft einem SM-B zugeordnet. Es kann aber auch der Sonderfall von unterschiedlichen SM-Bs zugeordneten Teilen von LE-Institutionen auftreten.

<PTV3> Dadurch wird sichergestellt, dass für die Fachanwendungen KOM-LE die SMTP- bzw. POP3-Benutzernamen gemäß TabelleTab_ILF_PS_Bildungsregel_SMTP-POP3_Benutzername konfiguriert sind, so dass der KOM-LE-Client mit der korrekten SM-B arbeitet.</PTV3>

Die korrekte Konfiguration ist relevant für die Zugriffsprotokollierung auf der eGK. Die für den Zugriff auf die eGK selektierten SMC-B bzw. HBA werden auf dem Logfile der eGK gemäß [gemSpec_Karten_Fach_TIP#4.1] protokolliert. Neben der Art (VSDM, NFDM, eMP usw.) und dem Zeitpunkt des Zugriffs werden im Falle des Zugriffs mittels SM-B der commonName zum OSIG-Zertifikat (s. Tab_ILF_PS_SektorspezifischeBildungsregeln_Actor-Name_eGK-Log) und im Falle des Zugriffs über den HBA der Nachname (GN), gefolgt vom Vornamen (SN) aus dem AUT-Zertifikat des HBA protokolliert.

Tabelle 1: Tab_ILF_PS_SektorspezifischeBildungsregeln_Actor-Name_eGK-Log

Um bei der Verwendung mehrerer SMC-Bs oder Mandanten in einzelnen Leistungserbringerinstitutionen ein unnötiges häufiges Wechseln der auf die eGK zugreifenden SMC-B oder der Mandanten zu verhindern, sind nur spezielle Aspekte der Zugriffsprotokollierung bei der Konfiguration der Mandanten zu beachten.

Beachtet werden muss, dass die Einträge im Zugriffsprotokoll der eGK dem Versicherten Transparenz über die Verarbeitungsprozesse der eGK bieten sollen, so dass der Versicherte in den Zugriffsprotokollen der eGK die Institution wiedererkennen kann, die seine eGK freigeschaltet hat.

Andere Protokollierungsaspekte erfordern in Kontexten, in denen mehrere SMC-Bs im Einsatz sind, nicht einen Mandantenwechsel:

• Mit welcher SMC-B eine LEI über den VPN-Zugangsdienst sich für die Aktualitätsprüfung der eGK mit der TI verbindet, wird weder auf der eGK, noch am Intermediär und auch nicht an den Fachdiensten des VSDM protokolliert.
• Am Prüfungsnachweis ist die Identität der SMC-B nicht erkennbar, mit deren Hilfe die Aktualisierung durchgeführt wurde.

Falls am Primärsystem unterschiedliche Mandanten vorkonfiguriert werden, soll im laufenden Betrieb gegebenenfalls ein Mandantenwechsel durchführbar sein, bei dem ein anderer vorkonfigurierter und abgespeicherter Kontextparameter bzw. Aufrufkontext inklusive Mandant-ID für den Kartenzugriff genutzt wird. Eine Implementierung, die über ein User-Interface unterschiedliche Aufrufkontexte auswählbar macht, ist einer Implementierung vorzuziehen, bei der im laufenden Betrieb ein Kontext manuell umkonfiguriert werden muss.

Wenn in einer größeren Leistungserbringerinstitution mehrere separat voneinander konfigurierte Konnektoren eingesetzt werden sollen, muss das PS die Informationsmodelle der separaten Konnektoren inklusive der Mandantenkonfiguration in die eigene Arbeitsplatzkonfiguration integrieren können, um vom jeweiligen Arbeitsplatz aus einen passenden Konnektor ansteuern zu können. Die Exportschnittstelle des Informationsmodelles am Konnektor ist herstellerspezifisch.

3.3.4 Ablösung der BCS-Kartenterminal-Schnittstelle

Aufgrund der Ansteuerung von eHealth-Kartenterminals über die entsprechenden Konnektorschnittstellen ist mit dem Online-Produktivbetrieb eine direkte Ansteuerung von eHealth-BCS-Kartenterminals durch das Primärsystem obsolet und funktional unzureichend. Mithilfe von eHealth-BCS-Kartenterminals, die über eine CT-API-Schnittstelle am Primärsystem angebunden sind, lassen sich

• eGK-Gültigkeitsprüfungen nicht durchführen
• Prüfnachweise nicht erzeugen und
• <PTV2> Signaturdienste des Konnektors und KOM-LE nicht nutzen.</PTV2>

Jedoch lassen sich in der Konfiguration des Basis-Rollouts mittels eHealth-BCS-Kartenterminals bis zum Zeitpunkt der Entfernung der GVD aus dem frei auslesbaren Bereich der eGK über die CT-API-Schnittstelle VSD aus dem ungeschützten Bereich der eGK auslesen.

Zur technischen Unterstützung eines Ersatzszenarios (z. B. bei einem temporären Ausfall des Konnektors) sollen Primärsysteme in der Übergangszeit, in der die GVD zusätzlich noch im frei auslesbaren Bereich der eGK enthalten sind, weiterhin konfigurativ die Anbindung von eHealth-BCS-Kartenterminals über CT-API-Schnittstelle unterstützen.

3.4 Einsatz Prüfkarte eGK

Für Produkt- und Zulassungstests werden Testobjekte eingesetzt, u.a. Testkarten in den verschiedenen Ausprägungen. Diese Tests laufen in den dafür konzipierten Referenz- und Testumgebungen RU/TU. Für die Prüfung der Produkte und Anwendungen in der produktiven Umgebung (PU), kann die Prüfkarte eGK (PK eGK) eingesetzt werden.

Durch geeignete Merkmale wird der Missbrauch und die Verwechselung mit einer echten eGK eines Versicherten der PU ausgeschlossen. Nachfolgend werden diese Unterscheidungsmerkmale zwischen PK eGK und echten Versichertenkarte beschrieben.

3.4.1 Optische Darstellung

Zu den erkennbaren Merkmalen der PK eGK nach Abb. 7 zählen insbesondere eine auffällige optische Gestaltung (Nur für Prüfzwecke), eine eigens für Prüfkarten definierte Institutskennung (109500969, Test GKV-SV) und die Verwendung von Personalisierungsdaten fiktiver Identitäten (Dienstleister vor Ort), die eine Verwechselung mit realen Versicherten ausschließen.

Abbildung 7 Beispiel-Layout der Prüfkarte eGK

3.4.2 Ungültige Versichertennummer (KVNR)

Ein weiteres Unterscheidungsmerkmal der PK eGK gegenüber einer echten Versichertenkarte erfolgt durch die Vergabe einer ungültigen Versichertennummer (KVNR), die die KVNR-Bildungsregel verletzt. Die KVNR der Prüfkarte beinhaltet mehr als drei gleiche, aufeinanderfolgende Ziffern (“0000“), was gemäß [Richtlinien_KVNR#2.2] in einer echten Versichertenkarte nicht auftreten darf.
Somit können Praxisverwaltungssysteme für die Prüfung ihrer internen Abläufe die KVNR als Kriterium für die Erkennung und Unterscheidung zwischen der Prüfidentität der PK eGK und der Identität eines echten Versicherten auswerten

4 Funktionsmerkmale

4.1 Inbetriebnahme

Primärsystem und Konnektor sind gemeinsam betriebsbereit, wenn

• die Konfiguration des Gesamtsystems (inklusive mindestens einem Kartenterminal) erfolgt ist und die Konfiguration von Primärsystem und Konnektor an einander angeglichen sind,
• zwischen beiden Systemen eine Verbindung (HTTP oder HTTPS) besteht,
• das Primärsystem aktuelle Informationen über verfügbare Dienste hat,
• Ereignisse über den Ereignisdienst des Konnektors abonniert sind (sofern vorgesehen) und
• mindestens eine freigeschaltete SM-B verfügbar ist.

Um den Leistungsumfang des Wirkbetriebs der TI nutzen zu können, muss vom Primärsystem eine freigeschaltete SM-B verwendet werden. Dabei muss die Person, die den Konnektor in Betrieb nimmt, die PIN der SM-B eingeben und ggf. initialisieren.

Abbildung 8: Betriebsbereitschaft herstellen

4.1.1 Verbindungsaufbau zwischen Primärsystem und Konnektor

Die Kommunikation zwischen Primärsystem und Konnektor basiert auf den Protokollen

• HTTP (verpflichtend),
• CETP (optional) und
• LDAP (verpflichtend)

4.1.1.1 HTTP

Am Konnektor kann grundsätzlich die Absicherung der HTTP-Verbindung in 4 Stufen konfiguriert werden [gemSpec_Kon#3.5], wobei für bestimmte Szenarien nur die Konfigurationen mit höherem Sicherheitsniveau technisch möglich sind (siehe 4.1.1.1.1 Komfortsignatur  und 4.1.1.1.2 TI-Gateway  ).

Die vier Konfigurationen wirken auf HTTP folgendermaßen (mit Konnektor als TLS-Server und Primärsystem als TLS-Client):

Tabelle 2: Tab_ILF_PS_Konfigurationsvarianten_HTTP

Wenn der Konnektor so konfiguriert wird, dass TLS nicht erzwungen wird, bietet der Konnektor ggf. einen HTTP-Port an, sowie einen HTTPS-Port. Das Primärsystem kann den Konnektor in diesem Fall unter beiden Ports erreichen.

4.1.1.1.1 Komfortsignatur

Die Funktionalität Komfortsignatur (vgl. gemSpec_Kon#Komfortsignatur) ist nur dann verwendbar, wenn für die HTTP-Verbindung Stufe 3 oder Stufe 4 konfiguriert ist. Dies wird vom Konnektor technisch durchgesetzt.

4.1.1.1.2 TI-Gateway

Im Falle des TI-Gateway (vgl. gemF_TI-Gateway) ist der Highspeed-Konnektor so konfiguriert, dass ausschließlich Stufe 4 für HTTP-Verbindungen verwendet werden kann. Dies ist innerhalb der virtuellen Konnektor-Instanzen nicht änderbar.

4.1.1.2 CETP

Für die CETP-Verbindung (mit Primärsystem als TLS-Server und Konnektor als TLS-Client) gibt es zwei Konfigurationsvarianten:

Tabelle 3: Tab_ILF_PS_Konfigurationsvarianten_CETP

Da das Primärsystem bei der CETP-Verbindung als Server agiert, muss es sich bei Verwendung von TLS mit einem Zertifikat (und dem privaten Schlüssel dazu) authentisieren. Die Voraussetzungen dafür sind automatisch gegeben, wenn Stufe 4 bei der HTTP-Verbindung verwendet wird, da dafür bereits ein Schlüsselpaar und Zertifikat im Primärsystem konfiguriert wurde.

4.1.1.3 LDAP

Für Verbindungen zum LDAP-Proxy im Konnektor muss der Konnektor nur die Clientauthentisierung mit Zertifikat (Stufe 4 in der Tabelle Tab_ILF_PS_Konfigurationsvarianten_HTTP) verpflichtend unterstützen. Die Authentisierung mit Username/Passwort (Stufe 3 in der Tabelle Tab_ILF_PS_Konfigurationsvarianten_HTTP) bei LDAPS wird für den LDAP-Proxy im Konnektor nicht unterstützt. Eine Konfigurationsmöglichkeit für ein Client-Zertifikat für LDAPS ist optional.

Die Konfigurationsvarianten des Konnektors zur Absicherung der Verbindungen zwischen Konnektor und Primärsystem sind in [gemSpec_Kon#3.5"Fachliche Anbindung der Clientsysteme"] beschrieben.

4.1.1.4 Dienstverzeichnisdienst (DVD)

In seinem Dienstverzeichnisdienst stellt der Konnektor unter einer definierten URL in einem XML-Dokument („connector.sds“) die Liste aller Dienste, sowie deren Versionen und Endpunkte bereit, die vom Konnektor angeboten werden.

Es ist am Konnektor möglich, die Transportsicherung zum Dienstverzeichnisdienst des Konnektors anders zu konfigurieren als die Transportsicherung zu den restlichen Diensten.

4.1.1.5 Zu unterstützende Modi und Algorithmen

Informativ werden im Folgenden die drei in der Anforderung A_24586 aufgeführten Anforderungen an den Konnektor aufgeführt.

4.1.1.6 Client-Authentisierung

4.1.1.6.1 Client-Authentisierung per HTTP-Basic-Authentication

Für Basic Authentication (auch „Basic Access Authentication“, ein Standard der HTTP-Authentifizierung) muss das Primärsystem die notwendigen Parameter „Benutzername“ und „Passwort“ verwalten. Das Primärsystem muss über zwei entsprechende Konfigurationsparameter verfügen, die sich über die Systemkonfiguration des PS eingeben bzw. verändern lassen. Wird als Authentisierungsmethode Basic Authentication vereinbart, müssen hier die gleichen Werte für Benutzername und Passwort eingegeben sein, wie in der Managementschnittstelle des Konnektors.

4.1.1.6.2 Zertifikatbasierte Client-Authentisierung

Für die zertifikatsbasierte Client-Authentisierung mittels im Konnektor erzeugter Zertifikate wird im Konnektor ein Zertifikat sowie ein privater Schlüssel erzeugt und exportiert. Es liegt als standardisiertes Format (p12) [PKCS#12] vor, wobei der Schlüsselspeicher durch eine PIN geschützt ist.

Am Konnektor-Managementinterface erzeugte und von dort exportierte Clientzertifikate ([gemSpec_Kon#3.5], TIP1-A_4517*) werden in die Clientsysteme importiert. Das PS importiert und verwaltet das Client-Zertifikat aus der p12-Datei. Dazu muss während des Import-Vorgangs die PIN des Zertifikats eingegeben werden (Transportsicherung). Anschließend hat das Primärsystem Zugriff auf den für den TLS-Verbindungsaufbau benötigten privaten Schlüssel.

Für die zertifikatsbasierte Client-Authentisierung mittels extern erzeugter Zertifikate muss außerhalb des Konnektors ein asymmetrisches Schlüsselpaar erzeugt und der öffentliche Schlüssel in ein X.509-Zertifikat eingebunden werden. Bei der Auswahl von Algorithmen und Schlüssellängen ist auf Kompatibilität mit dem verwendeten Konnektor zu achten (siehe gemSpec_Kon#TAB_KON_866). Das X.509-Zertifikat wird über das Managementinterface in den Konnektor eingespielt.

Das Primärsystem nutzt einen Systemschlüsselspeicher, z. B. den Zertifikatsspeicher von Windows oder den des Java JRE. Auch hier ist für den Import-Vorgang ein Passwort des Schlüsselspeichers einzugeben. Anschließend stehen das Zertifikat und der Schlüssel über entsprechende Systemfunktionen/Bibliotheken zur Verfügung. Idealerweise kann der Administrator des PS in diesem Zertifikatsspeicher „browsen“ und das gewünschte Zertifikat für die Verwendung auswählen. Alternativ kann in der PS-Konfiguration eine eindeutige Referenz des Zertifikats (Name oder Index) eingegeben werden.

Für die Unterstützung des TI-Gateway ist TLS mit zertifikatbasierter Client-Authentisierung die einzig zulässige Verbindungsmethode.

4.1.1.7 Server-Authentisierung

Der Konnektor verwendet je nach Konfiguration als TLS-Server-Zertifikat:

• Zertifikat der ID.AK.AUT - Der private Schlüssel dazu ist in der gSMC-K geschützt, das Zertifikat wird entweder von der gSMC-K gelesen oder falls es bereits über die TI erneuert wurde aus dem Speicher des Konnektors . Der CommonName dieses Zertifikats ist mit der ICCSN und dem Herausgabedatum befüllt und nicht mit dem Hostnamen des Konnektors. Eine Hostnamenprüfung darf mit diesen Identitäten nicht durchgeführt werden. Die Zertifikate tragen alle Subject.AltNames DNSName="konnektor.konlan". Je nach Herstellungsdatum gibt es neben der RSA 2048 Version dieser Identität auch eine ECC 256 Identität auf Basis von Brainpool Kurven. RSA mit Schlüssellänge 2048 Bit wird in der TI nur bis Ende 2025 verwendet.
• Extern generiertes Zertifikat - Das Schlüsselmaterial wird ebenso extern generiert. Privater Schlüssel und Zertifikat werden in den Konnektor importiert. Die kryptographischen Verfahren sind in TAB_KON_866 festgelegt.
• Im Konnektor generiertes selbstsigniertes Zertifikat - Das Schlüsselmaterial wurde ebenso vom Konnektor erzeugt. Die kryptographischen Verfahren sind in TAB_KON_866 festgelegt. Die Zertifikate können den aktuellen, vom Nutzer vergebenen Hostnamen des Konnektors enthalten, so dass eine reguläre Hostnamevalidierung möglich ist.

Umstellung bei Zertifikatserneuerung

Der Konnektor sendet nach erfolgreicher automatischer Erneuerung der Zertifikate ein Ereignis mit dem Topic SMC_K/UPDATE/SUCCESS. Das Primärsystem sollte diese Information beziehen, den Anwender geeignet über das erfolgreiche Zertifikatsupdate informieren und eine Warnung ausgeben, dass bei Verwendung der ID.AK.AUT für die Server-Authentisierung eine Umstellung auf das neue AK.AUT-Zertifikat manuell vom Administrator vorgenommen werden muss.

Nach einer erfolgreichen Erneuerung der Identität ID.AK.AUT kann der Zeitpunkt der Verwendung von dieser erneuerten Identität vom Administrator frei gewählt werden, wobei je nach Konnektor ggf. eine automatische Anwendung des erneuerten C.AK.AUT stattfindet, wenn das bisherige kurz vor dem Ablaufdatum steht. 

Generierte / importierte Zertifikate

Die Möglichkeit im Konnektor generierte oder von Extern importierte nicht-TI-Zertifikate als Serverzertifikate zu nutzen wurde mit PTV5 eingeführt, um eine reguläre Hostnamevalidierung möglich zu machen. Außerdem wurde damit möglich gemacht, die nur bis Ende 2025 zulässigen RSA-2048 Schlüssel auch durch RSA-3072 oder ECC-Material basierend auf NIST-Kurven abzulösen. Das auf der gSMC-K bei Dualpersonalisierung vorhandene ECC-Material basiert auf Brainpool-Kurven, welche nur von wenigen Frameworks unterstützt werden.

Der Zeitpunkt der Verwendung von generierten oder importierten Zertifikaten kann vom Administrator frei gewählt werden und ist unabhängig vom Zeitpunkt der Generierung oder des Imports. Der Administrator kann jederzeit zwischen der Verwendung vom generierten oder importierten Zertifikat oder dem Zertifikat zum auf der gSMC-K gespeicherten Schlüssel hin- und herschalten.

Für das TI-Gateway ist die Verwendung eines für die jeweilige virtuelle Konnektor-Instanz individuellen Zertifikats vorgeschrieben, damit diese Konnektor-Instanz durch zugreifende Clients eindeutig identifiziert werden kann. Dies kann herstellerabhängig sowohl durch Instanz-individuelle C.AK.AUT TI-Zertifikate als auch durch - wie oben beschrieben - individuelle nicht-TI-Zertifikate (in der Instanz generiert oder in die Instanz importiert) erreicht werden. Letztere Variante wird dabei am häufigsten auftreten, konkret die Generierung eines self-signed Zertifikats innerhalb der virtuellen Instanz. Dadurch wird die Verwendung solcher nicht-TI-Zertifikate für die Authentisierung der Konnektor-Instanz im TI-Gateway die Regel sein.

Prüfung des TLS-Server Zertifikats

Jedes Clientsystem muss die Vertrauenswürdigkeit des TLS-Serverzertifikats prüfen. Für eine Prüfung des TLS-Server-Zertifikates des Konnektors durch das Primärsystem sind verschiedene auch kombinierbare Umsetzungsvarianten möglich.

Mit dem Import und der Speicherung von vertrauenswürdigen TLS-Serverzertifikaten werden alle vom Konnektor unterstützten Varianten abgedeckt. Die Konfiguration hat nutzerfreundlich zu erfolgen, z.B. indem das Konnektor-TLS-Server-Zertifikat bei dem ersten Verbindungsaufbau zum Konnektor durch einen Administrator akzeptiert und dadurch im Primärsystem als vertrauenswürdig hinterlegt wird, analog wie an einem Browser eine Ausnahmeregelung für das Zertifikat einer Webseite gespeichert werden kann, wenn dies durch den Browser nicht geprüft werden kann. Dabei muss dem Administrator die Möglichkeit gegeben werden, den Fingerprint des Zertifikats abzugleichen (dieser muss also angezeigt werden).

Im Falle eines Konnektorwechsels, einer Zertifikatsverlängerung oder eines konfigurativen Wechsels des TLS-Serverzertifikats (RSA<->ECC, generiert, importiert) muss der Import des TLS-Server-Zertifikats erneut durchgeführt werden. Dieser Import des neuen Server-Zertifikats kann auch bei der ersten Verbindung automatisch erfolgen, wenn das Primärsystem zuvor den Fingerprint des neuen Server-Zertifikats per Event vom Konnektor über einen beidseitig authentisierten TLS-Kanal empfängt. Bei der ersten Verbindung mit dem neuen Server-Zertifikat, kann dies gegen den zuvor authentisch empfangenen Fingerprint abgeglichen werden. Zum Empfang des Events darf das alte Server-Zertifikat also noch nicht abgelaufen sein und das Primärsystem muss das entsprechende Event erfolgreich abonniert haben.

Für die Unterstützung des TI-Gateway ist die Prüfung, dass die virtuelle Konnektor-Instanz genau das konfigurierte vertrauenswürdige Serverzertifikat präsentiert die einzig zulässige Authentifizierungsmethode, unabhängig davon, ob das Zertifikat aus der TI-PKI, einer anderen PKI oder selbstsigniert ist. Die im folgenden beschriebene Methode verifiziert, dass ein TI-Konnektor-Zertifikat vorliegt. Da dabei nicht die konkrete Identität der Konnektor-Instanz geprüft wird, ist diese Prüfung nicht ausreichend. Für generierte oder importierte Zertifikate ist diese Prüfung nicht anwendbar. Bei Verwendung eines Einboxkonnektors in einer abgeschlossenen Umgebung kann diese Authentifizierungsmethode angewendet werden.

Mit der Prüfung gegen die SubCA, die das TLS-Serverzertifikat ausgestellt hat, wird das Vertrauen zu allen Zertifikaten dieser CA etabliert. Die Prüfung für ID.AK.AUT kann in diesem Sinne gegen die produktive Komponenten-SubCA der TI erfolgen. Dabei ist der Lebenszyklus der in der TSL veröffentlichten TI-Komponenten-SubCA zu beachten. Die SubCA ist 8 Jahre gültig und wird über diesen Zeitraum in der TSL veröffentlicht. Nach spätestens drei Jahren werden jedoch End-Entity-Komponenten-Zertifikate von einer neu hinzugefügten SubCA abgeleitet, damit eine SubCA immer mindestens noch 5 Jahre gültig ist, wenn sie die letzten Zertifikate bestätigt. Das PS muss also damit rechnen, TLS-Server-Zertifikate von Konnektoren gegen mindestens drei produktive SubCAs validieren zu können, weil es im Feld End-Entity-Konnektorzertifikate geben kann, die aus unterschiedlichen SubCAs abgeleitet sind. Am Laufzeitende einer TI-Komponenten-SubCA verliert diese ihre Gültigkeit und wird aus der TSL entfernt. Die aktuelle TSL ist unter http://download.crl.ti-dienste.de/TSL-ECC/ECC-RSA_TSL.xml verfügbar.

Darin befinden sich Zertifikate mit dem Namen GEM.KOMP-CA*, also z.B. GEM.KOMP-CA1, GEM.KOMP-CA3, o.ä. sowohl für RSA als auch für ECC. Die Verwendung des ECC-Zertifikats der gSMC-K muss in der Administrationsoberfläche des Konnektors eingeschaltet werden. Dieses sollte erst erfolgen, wenn das Primärsystem die ECC-Zertifikate prüfen kann.

Wird ein Zertifikat aus einer lokalen PKI als TLS-Server-Zertifikat in den Konnektor importiert, soll die Prüfung gegen das entsprechende lokale SubCA-Zertifikat stattfinden.

4.1.2 Konnektordienstverzeichnis lesen

Aus der Konnektordokumentation des Herstellers ist die URL zu entnehmen, unter dem der Konnektor sein Dienstverzeichnis anbietet. Innerhalb der URL können Hostname und Domain-Name je nach Konfiguration der LE-Umgebung individuell konfiguriert sein. In diesem Falle muss die URL entsprechend in der Primärsystemkonfiguration angepasst werden.

Beispiel #: URL des Konnektordienstverzeichnisses

Dieser Parameter muss in der Primärsystemkonfiguration erfasst werden.

Durch das Auslesen des Dienstverzeichnisdienstes erhält das Primärsystem Webservice-Endpunkte von versionierten Diensten des Konnektors.

Beispiel #: Dienstkonfiguration

Das Listing zeigt eine beispielhafte Dienstkonfiguration, wobei nur für den ersten Dienst die oberste Ebene dargestellt (aufgeklappt) ist. Für den Dienst ReadVSD sind neben einer Kurzbeschreibung eine versionsabhängige Beschreibung und die Endpunkte für die Schnittstellenbeschreibung (WSDL) und die Kommunikation zu entnehmen. Je nach Sicherheitskonfiguration des Konnektors kann dabei ein Protokoll für verschlüsselte (https) oder unverschlüsselte Kommunikation vorgegeben werden. Ebenso kann der Port von den http-/https-Standardports abweichen.

Die vollständigen Schemadefinitionen des XML-Dokuments „connector.sds“ finden sich gemäß [gemSpec_Kon#4.1.3.1] in den Dateien ServiceDirectory.xsd, ProductInformation.xsd und ServiceInformation.xsd.

Da nicht davon ausgegangen werden kann, dass die Inhalte des Dienstverzeichnisdienstes statisch sind, sollte das Lesen des Verzeichnisses beim Programmstart, in Fehlersituationen (Verbindungsprobleme, Dienst nicht erreichbar) und nach Bootup des Konnektors erfolgen, um den Dienstverzeichnis-Cache zu erneuern. Die weitere Kommunikation mit den Diensten des Konnektors erfolgt dann über die im Dienstverzeichnisdienst propagierten Dienstendpunkte.

4.1.3 Nutzung von Webservice-Schnittstellen

Das Primärsystem MUSS den Request in UTF-8 kodieren. Diese Festlegungen gelten nur für die eigentliche SOAP-Nachricht. Sind in der SOAP-Nachricht base64-encodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichencodierungen aufweisen. Falls in der SOAP-Nachricht base64-encodierte (verschlüsselte) XML-Elemente vorhanden sind, können diese XML-Elemente andere Zeichenkodierungen als UTF-8 aufweisen.

Die Dienste des Konnektors sind versioniert. Es ist möglich, dass ein Konnektor mehrere Versionen eines Dienstes gleichzeitig anbietet. Die Versionierung der Dienste hilft dem Primärsystem dabei, genau die Dienstversionen zu nutzen, die es client-seitig implementiert hat.

Die Konnektor-Schnittstellen haben eine dreistellige Versionsnummer mit einer Hauptversionsnummer (1. Stelle), Nebenversionsnummer (2. Stelle) und einer Revisionsnummer (3. Stelle). Wenn das Primärsystem am Konnektor eine Schnittstelle aufruft, muss dieses in Hauptversionsnummer und Nebenversionsnummer mit seiner Implementierung übereinstimmen, während sich die Revisionsnummer unterscheiden darf. Bezüglich einer abweichenden Revisionsnummer können folgende Konstellationen auftreten:

• RPrim < RKon. Ist die Revisionsnummer der Schnittstelle des Konnektors RKon größer als die Revisionsnummer der implementierten Primärsystemschnittstelle RPrim, so werden alle Schnittstellenaufrufe vom Konnektor derart beantwortet, als wäre RKon= RPrim. Die Use Cases können weiter abgearbeitet werden.
• RPrim > RKon. Ist RPrim > RKon, so sind alle in RKon vorhandenen Operationen mit denen in RPrim identisch. Die alten Operationen können ohne Einschränkungen aufgerufen werden. Jedoch können neue Operationen in RPrim hinzugekommen sein, die vom Konnektor in RKon noch nicht implementiert sind. Ohne gesonderte Behandlung führen Aufrufe an Konnektoren, in denen die neuen Operationen noch nicht implementiert sind, zu einer technischen Fehlermeldung (nicht implementierte SoapAction). Diese Fehlerkonstellation wird beim Leistungserbringer nicht auftreten, falls dieser die Firmware des Konnektors aktuell hält (s. Kapitel 4.1.4.6).

Trifft das PS auf einen DVD, in dem u.a. Dienstversionen vorliegen, die in der Haupt- oder Nebenversionsnummer von der Erwartung des Primärsystems abweichen, so muss das PS nach Möglichkeit eine Version auswählen, die es unterstützt.

Gemäß den Schnittstellenvorgaben erfolgt die SOAP-Kommunikation über http oder https.

Beispiel #: HTTP-SOAP-Header

4.1.4 Ereignisdienst/Systeminformationsdienst

Das Primärsystem kann den Ereignisdienst als Basisanwendung des Systeminformationsdienstes (EventService) des Konnektors nutzen, um über konnektorspezifische Ereignisse zeitnah in einem Push-Mechanismus informiert zu werden. Die dabei an das Primärsystem zurückgegebenen Informationen können vom Primärsystem zu folgenden Zwecken genutzt werden:

• Anzeige von Statusinformationen zu TI-Komponenten, z. B. Verbindungsstatus des Konnektors
• Verwaltung von Informationen zu gesteckten Karten
• Kontrolle der Kartenverfügbarkeit
• Einlesen von Karten zum Zeitpunkt des Steckens der Karte in das Arbeitsplatzterminal
• Ablaufoptimierung und Performance-Verbesserung durch Push-Kommunikation

Neben den eigentlichen Operationen für das Verarbeiten von Ereignissen (siehe 4.1.4.1) stellt der EventService auch Operationen zum Zugriff auf Ressourcen und Abfragen verfügbarer Karten und Kartenterminals bereit (siehe 4.2.1). Details finden sich in den WSDL- und XSD-Dateien zur entsprechenden Service-Schnittstelle EventService.wsdl und EventService.xsd.

4.1.4.1 Ereignismeldungen mittels Protokoll CETP

Der Ereignisdienst des Systeminformationsdienstes nutzt das leichtgewichtige proprietäre Protokoll CETP (Connector Event Transport Protocol), das das Abonnieren bestimmter Ereignistypen (Topics) durch das Primärsystem erfordert, siehe [gemSpec_Kon#4.1.6].

Abbildung 9: PIC_KON_022 Grundsätzlicher Aufbau der Ereignisnachricht

Abbildung 10: XML-Element Event

Beispiel #: Vollständigen Ereignisstruktur einer CETP-Event-Nachricht

Das Attribut Filter des Elements Topic ist nicht angegeben, da es optional und nur beim Abonnieren von Ereignissen zu verwenden ist (siehe folgender Abschnitt).

Für die Umsetzung des Ereignisdienstes auf Primärsystemseite ist – abhängig von Architektur und eingesetzter Technologie – zu entscheiden, ob ein solcher Dienst im Primärsystem (server-seitig) einmalig oder auf jedem Arbeitsplatz (client-seitig) bereitgestellt wird.

Sonderfall CardType=UNKNOWN

Wird durch den Benutzer eine Karte gesteckt, die durch den Konnektor nicht korrekt identifiziert und gelesen werden kann (falsche Karte, Karte falsch gesteckt, Karte defekt), meldet der Konnektor dies durch das Ereignis CARD/INSERTED mit dem speziellen Kartentyp UNKNOWN. Das Primärsystem sollte eine entsprechende Meldung ausgeben und den Benutzer ggf. zur Korrektur auffordern.

4.1.4.2 Abonnieren von Ereignissen

Zum Abonnieren von Topics stellt der Konnektor die Funktionen Subscribe, Unsubscribe und GetSubscription zur Verfügung. Beim Abonnieren von Topics lassen sich Filter auf Ereignisse setzen, wobei sich mittels XPath-Ausdrücken Ereignisse über Typ und Severity filtern lassen. Alternativ können auch alle Ereignisse abonniert werden. In diesem Fall muss das Primärsystem bei jedem Empfang einer Ereignisnachricht entscheiden, ob und wie diese zu verarbeiten ist.

Wenn es eine Vielzahl von Kartenterminals gibt, die im Netzwerk registriert sind, kann der Fall eintreten, dass mehrere Karten gleichzeitig gesteckt sind. Mit Hilfe selektierender Informationen lassen sich Kartenzugriffe auf die Karten einschränken, die genutzt werden sollen. Die selektierenden Informationen können aus dem Ereignisdienst bezogen werden und helfen dabei, CardHandles zu erlangen, mit denen Kartenzugriffe realisiert bzw. Kartensitzungen aufgebaut werden können.

Ereignisse können gezielt abonniert werden, so dass einzelne Arbeitsplätze nur Ereignisinformationen erhalten, welche die Steckung von Karten in Kartenterminals betreffen, die ihnen zugeordnet sind.

Eine Reihe von Informationen über den Status von Karten können unmittelbar zum Zeitpunkt des Steckens einer Karte zur Verfügung gestellt werden, insbesondere die Kartenterminal-ID, an dem aktuell eine Karte gesteckt ist.

Abbildung 11: Struktur des Elements Subscribe

Tabelle 5: Tab_ILF_PS_Wichtige_Topics_für_Kartenereignisse

Eine vollständige Übersicht der vom Konnektor erzeugten Ereignisse mit den dazugehörigen Key/Value-Parametern findet sich in [gemSpec_Kon#8 AnhangF].

Die Ereignisse, die durch Fachmodul VSDM erzeugt und über den Konnektor übermittelt werden, finden sich in 4.3.4.4.

Beispiel #: SOAP-Request einer Subscription

Im obigen Beispiel werden Ereignisse des Typs CARD/INSERTED abonniert. Es findet dabei zusätzlich ein XPath-Ausdruck als Filter Anwendung, der nur Ereignisse liefert, die sich auf das Kartenterminal mit der Nummer 101 (CtID=101), auf den Kartentyp EGK beziehen (CardType=EGK) sowie Severity=Info (normale Verarbeitung). Das Beispielereignis CARD/INSERTED aus 4.1.4.1 würde damit an cetp://ap007.local:20000 zugestellt werden.

Alternativ kann der Filter im obigen Beispiel auch so geschrieben werden:

<m:Filter>
/Event/Message/Parameter[Key="CtID" and Value="101" and ../Parameter[Key="CardType" and Value="EGK"] and ../../Severity="Info"] </m:Filter>

4.1.4.3 Ereignisse für Konnektorinformationen

Informationen über den Status bzw. Statusänderungen des Konnektors können durch den Ereignisdienst aktuell zur Verfügung gestellt werden, insbesondere zur Online-Verbindung des Konnektors.

Tabelle 6: Tab_ILF_PS_Topics_für_Konnektorinformationsereignisse

Beispiel #: Subscription-Ausschnitt für kritische Konnektorereignisse

In diesem Beispiel werden alle Konnektorereignisse mit dem Topic „OPERATIONAL_ STATE“ auf Topic-Ebene 1 mit dem Schweregrad „Critical“ abonniert. Dies könnte genutzt werden, um den Anwender auf diesen Zustand des Konnektors hinzuweisen, um ggf. weitere Maßnahmen durchzuführen (Fehleranalyse am Konnektor durch Administrator). Werden – wie in diesem Beispiel – keine Topics der Ebene 2 oder 3 angegeben, werden alle entsprechenden Ereignisse zugestellt.

4.1.4.4 Ereignisdienst-Szenario VSDM-Informationen

Durch den Ereignisdienst können Statusinformationen zum Prozess eines angestoßenen VSDM-Updates sowie das Auslesen der VSD für eine Fortschrittsanzeige sofort zur Verfügung gestellt werden. Die entsprechenden Ereignisse VSDM/PROGRESS/UPDATE und VSDM/PROGRESS/READVSD sind im Abschnitt 4.3.4.4 beschrieben.

Das Primärsystem soll den Ereignisdienst dazu nutzen, den Nutzern eine Fortschrittsanzeige zum Prozess eines VSDM-Updates zur Verfügung zu stellen.

4.1.4.5 Erneuerung von Abonnements

Es liegt in der Verantwortung des Primärsystems dafür zu sorgen, seine Abonnements/Subscriptions aktiv zu halten.

In folgenden Fällen ist eine Erneuerung der Ereignis-Abonnements erforderlich:

• Regelhafte Erneuerung

Die Gültigkeit einer Subscription ist auf einen Zeitraum von 25 Stunden begrenzt. Soll sie darüber hinaus weiterbestehen, muss sie rechtzeitig vor Erreichen der TerminationTime erneuert werden.

• Erneuerung nach Restart Konnektor

Wenn der Konnektor neu gestartet wurde, erhält das Primärsystem vom Konnektor einen „BOOTUP/BOOTUP_COMPLETE” Event. Danach sind im Konnektor alle Subscriptions gelöscht und das Primärsystem muss sich erneut subscriben.

• Erneuerung nach Nichterreichbarkeit des Primärsystems

Ist das Primärsystem für den Konnektor nicht erreichbar – was z. B. der Fall ist, wenn das Primärsystem ausgeschaltet ist – dann löscht der Konnektor nach einer konfigurierbaren Anzahl von Zustellversuchen EVT_MAX_TRY die Subscriptions des Primärsystems.

Das Primärsystem muss Situationen erkennen, in denen es seit der letzten Erneuerung der Subscriptions für den Konnektor aus durch das Primärsystem erkennbaren Gründen nicht erreichbar war, und daraufhin die Subscriptions erneuern. Dies ist beispielsweise der Fall, wenn das Primärsystem gestartet wird.

In den verbleibenden Fällen, in denen der Konnektor die Subscriptions löscht, aber das Primärsystem nicht erkennen kann, dass es durch den Konnektor nicht erreichbar war, sollte es eine Möglichkeit für den Nutzer geben, die Erneuerung der Subscriptions über die Nutzeroberfläche manuell anzustoßen. Dies kann indirekt geschehen, wenn durch den Benutzer eine Aktion ausgelöst wird, welche sonst durch ein Event gesteuert automatisch startet. An der manuellen Aktivität kann das Primärsystem erkennen, dass ein Event offensichtlich nicht empfangen wurde und daraufhin die Subscribtions überprüfen. Nutzer erkennen einen solchen Zustand insbesondere daran, dass auf das Stecken von Karten kein Event im Primärsystem angezeigt wird und Lesevorgänge manuell gestartet werden müssen.

Für die Erneuerung muss mindestens der erste der beiden Schritte durchgeführt werden:

• Beim Aufruf von RenewSubscriptions muss neben dem Aufrufkontext die SubscriptionID mitgeliefert werden, die bei der erstmaligen Anmeldung erzeugt wurde und das Ereignisabonnement identifiziert, das erneuert werden soll. Die Response des Aufrufes von RenewSubscriptions gibt Auskunft über den Status der Erneuerung und die TerminationTime zur SubscriptionID.
• Wenn das Renew nicht erfolgreich war, muss ein erneutes Subscribe erfolgen, wie in 4.1.4.2 geschildert.

Eine inhaltliche Überprüfung der Subscription kann das Primärsystem durchführen, indem es mit GetSubscription eine Liste seiner Subscriptions vom Konnektor anfordert, die eigene Liste der Subscriptions damit abgleicht und bei Bedarf erneut über die Operation Subscribe am Konnektor die fehlenden Subscriptions einstellt.

4.1.4.6 Informationen zum Vorliegen von Konnektor-Firmware-Updates

Der Konnektor stellt Informationen über das Vorliegen von Konnektor-Firmware-Updates über den Systeminformationsdienst zur Verfügung, insbesondere über den Topic KSR/UPDATES_AVAILABLE.

Diese Informationen sollten gemäß den Betriebsprozessen des Primärsystems beim Leistungserbringer sorgfältig berücksichtigt werden, da Firmware-Updates des Konnektors einen maßgeblichen Einfluss auf die Konnektorschnittstellen des Primärsystems haben:

• Bei Abschluss des Downloads von Update-Paketen für den Konnektor setzt der Konnektor das Systemereignis zum Topic KSR/UPDATE/KONNEKTOR_DOWNLOAD_END ab. Es werden Informationen bereitgestellt zu: Produktinformationen, Firmware Version, Deadline (spätester Zeitpunkt für Installation), Priorität und Release Notes.
• <PTV3> Handelt es sich dabei um ein sicherheitskritisches Update-Paket, dann sendet der Konnektor das Ereignis EC_Connector_Software_Out_Of_Date (Typ Op, Schwere Info, Topic OPERATIONAL_STATE).</PTV3>
• <PTV3> Wurde die Deadline für ein sicherheitskritisches Update-Paket erreicht, dann wird der Konnektor in einen kritischen Betriebszustand versetzt, der mit dem EventEC_FW_Not_Valid_Status_Blocked gemeldet wird. Die Verbindung zur TI wird durch den Konnektor solange blockiert, bis eine Aktualisierung der Konnektor-Firmware durch den Administrator erfolgt ist.</PTV3>
• <PTV3> Die Deadline des spätesten Aktualisierungstermines wird im Parameter Deadline zum Topic KSR/UPDATES_AVAILABLE übermittelt, falls Events zum Betriebszustand abonniert wurden (topic = OPERATIONAL_STATE).</PTV3>

Das Primärsystem sollte diese Informationen beziehen (siehe Kap. 4.1.4.3) und den Anwender geeignet informieren, um eine Sperrung des Zugangs zur Telematikinfrastruktur zu vermeiden.

4.1.4.7 Informationen zu Fehlern bei der Zertifikatserneuerung (Laufzeitverlängerung gSMC-K)

Der Konnektor stellt Informationen über ggf. aufgetretene Fehler bei der Erneuerung der Zertifikate der gSMC-K über den Systeminformationsdienst zur Verfügung, insbesondere über den Topic SMC_K/DOWNLOAD/ERROR und SMC_K/UPDATE/ERROR.

Diese Informationen sollten gemäß den Betriebsprozessen des Primärsystems beim Leistungserbringer sorgfältig berücksichtigt werden, da eine fehlerhafte oder unvollständige Erneuerung der Zertifikate der gSMC-K zu einem Ausfall der TI-Anwendungsfälle führen und einen Konnektor-Tausch notwendig machen kann. Das Primärsystem sollte diese Informationen daher beziehen (siehe Kap. 4.1.4.3) und den Anwender geeignet informieren.

Ebenso stellt der Konnektor Informationen über aufgetretene Fehler bei der Reregistrierung mit erneuertem Zertifikat zur Verfügung, insbesondere über den Topic SMC_K/REGISTER/ERROR. Bei Auftreten des Fehlers mit Parameter Fail=No_Smcb muss in der Leistungserbringerumgebung dafür gesorgt werden, dass eine freigeschaltete SMC-B verfügbar ist, die der Konnektor für die Re-Registrierung verwenden kann.</PTV5>

4.1.5 Karten/PIN-Handling

4.1.5.1 PS-Dialoge

Das Primärsystem soll für den Benutzer Dialoge zur Verfügung stellen, um die PIN einer SMC-B, eines HSM-B oder eines HBA zu ändern sowie um diese Karten freizuschalten (PIN-Eingabe zur Erhöhung des Sicherheitszustands).

Eine PIN-Änderung ist notwendig, wenn die entsprechende Karte mit einer Transport-PIN ausgeliefert wurde. Diese PIN muss geändert werden, damit die Karte bezüglich entsprechender Sicherheitsfunktionen verwendet werden kann. Ferner kann der LE die PIN zyklisch ändern, um ein höheres Sicherheitsniveau zu gewährleisten. Zur PIN-Änderung muss das Primärsystem die Liste der verfügbaren Karten abfragen und der Benutzer anschließend die gewünschte Karte auswählen. Durch Aufruf der Operation changePIN (siehe 4.1.5.2) und anschließender Eingabe der alte PIN (ggf. Transport-PIN) sowie einer neue PIN am Kartenterminal erfolgt die Änderung auf der Karte.

Die Freischaltung einer Karte erfolgt in ähnlicher Weise, indem nach Auswahl einer verfügbaren Karte (Dialog im PS) die Operation verifyPIN für diese Karte am Konnektor aufgerufen wird. Die Freischaltung einer Karte zur Erhöhung des Sicherheitszustands ist in 4.1.5.4 beschrieben.

Das Primärsystem soll immer einen Hinweisdialog anzeigen, wenn der Zugriff auf eine Karte wegen eines nicht erhöhten Sicherheitszustands fehlschlägt oder das PS anderweitig eine PIN-Eingabe für eine Karte initiiert. In diesem Fall soll der Benutzer zur weiteren Eingabe an das entsprechende Kartenterminal verwiesen werden.

Die bei PIN-Operationen möglicherweise auftretenden Fehler sind in Tab_ILF_PS_Fehlercodes_PIN-Handling in Kap. 6.6 aufgeführt.

Darüber hinaus können PIN-Operationen (ohne dass ein Fehler geworfen wird) das PinResult "REJECTED" haben (PIN wurde verkehrt eingegeben), oder "BLOCKED", "NOWBLOCKED" oder "WASBLOCKED" (PIN wurde drei Mal verkehrt eingegeben und ist nun gesperrt). Das Result der PIN-Operation ist in diesen Fällen ein technisches "OK", auch wenn die PIN-Eingabe gescheitert ist.

Das PS soll Fehler und Falscheingaben bei PIN-Operationen abfangen und unter Auswertung der Response des Konnektors nutzerfreundliche Anwendungsprozesse implementieren.

4.1.5.2 PIN-Änderung

Die Initialisierung der PIN.SMC der SM-B erfolgt im Rahmen der erstmaligen Nutzung des Konnektors bzw. der SM-B durch das Primärsystem. Eine zyklische Änderung der PIN erfolgt mit Hilfe der gleichen Funktion.

Das Erfordernis, eine Transport-PIN durch ChangePin zu ändern, liegt in folgenden Fällen vor:

1.     Aufruf GetPinStatus: Rückgabe PinStatus = „TRANSPORT_PIN“;

2.     Aufruf VerifyPin: Rückgabe PinResult = „TRANSPORT_PIN“.

Beispiel #: Webservice-Call CardService.ChangePin für einen HBA

Alle PIN-Eingaben erfolgen über eine sichere PIN-Eingabe am Kartenterminal.

4.1.5.3 PIN-Entsperrung

Bei mehrfacher Falscheingabe einer PIN kann die daraus resultierende Sperrung durch CardService.unblockPIN aufgehoben werden.

Beim Entsperren einer blockierten PIN kann der Nutzer eine neue Geheimzahl vergeben oder die bisherige PIN weiter benutzen. Für PIN.QES des HBA ist es nicht möglich, während der PIN-Entsperrung eine neue PIN zu setzen. In jedem Fall muss der Nutzer den Entsperr-Schlüssel (PUK) aus seinem PIN-Brief eingeben. Im Resultat von unblockPIN gibt bei fehlerhaften Eingaben der Ergebnisparameter leftTries darüber Auskunft, wie viele der ursprünglich 10 Versuche verbleiben, die PUK einzugeben. Wenn die PUK 10-malig verwendet wurde, ist eine weitere Entsperrung nicht mehr möglich. 

Wenn der Nutzer lediglich die Geheimzahl ändern möchte und die PIN nicht blockiert ist, muss die Operation ChangePin verwendet werden.

Bei Entsperrung einer PIN der eGK ist die Verwendung des PinTyp „PIN.CH“ funktionsgleich zur Verwendung der Pin-Typen MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE, MRPIN.DPE_READ, MRPIN.GDD, MRPIN.OSE und MRPIN.AMTS. Beim PIN-Objekt vom Pin-Typ PIN.AMTS_REP wird mittels CardService.unblockPIN die Entsperrung unter Eingabe der PIN.CH durchgeführt (nicht unter Eingabe der PUK). Außerdem kann PIN.AMTS_REP jederzeit mittels changePIN unter Eingabe der PIN.CH neu gesetzt werden, s. [gemILF_PS_AMTS#6.3.9].

Um den Nutzungszähler der Karte nicht unnötig zu dekrementieren, soll das Entsperren der PIN auf folgende Konstellationen beschränkt werden, in denen zuverlässig ermittelt wurde, dass eine PIN gesperrt ist:

1. Aufruf GetPinStatus: Rückgabe PinStatus = "BLOCKED", oder
2. Aufruf VerifyPin: Rückgabe PinResult = "WASBLOCKED" oder "NOWBLOCKED", oder
3. Aufruf ChangePin: Rückgabe PinResult = "WASBLOCKED" oder "NOWBLOCKED".

4.1.5.4 Freischaltung von Karten

Bestimmte Operationen erfordern einen erhöhten Sicherheitszustand eines HBA bzw. SM-B (SMC-B oder HSM-B). Die entsprechende Karte muss im Rahmen einer Inbetriebnahme freigeschaltet werden, d. h. der Benutzer muss während definierter Prozesse (z. B. tägliche Inbetriebnahme des Konnektors und/oder des Primärsystems) durch Aufruf der Operation verifyPIN angestoßen die PIN eingeben und so den Sicherheitszustand der SM-B erhöht haben.

In größeren Institutionen (z.B. in einem Krankenhaus) sollten mehrere Kartenterminals an mehreren Arbeitsplätzen statisch im Informationsmodell des Konnektors als Remote-PIN-Kartenterminals definiert werden, damit sie bei Bedarf zum Freischalten der SMC-B oder des HBA genutzt werden können. Dabei gilt im Sonderfall mehrerer lokaler Kartenterminals an einem Arbeitsplatz die Vorgabe des Konnektors in Tabelle TAB_KON_510 aus [gemSpec_Kon#4.1.1.1], dass nur eines (oder keines) dieser Kartenterminals für die Remote-PIN-Eingabe im Informationsmodell des Konnektors konfiguriert wird.

Das Primärsystem kann den aktuellen Status einer Karte mittels der Operation GetPinStatus abfragen um zu prüfen, ob eine Freischaltung notwendig ist. Unter den verpflichtenden Rückgabewerten gilt: VERIFIED zeigt den erhöhten Sicherheitszustand an, der Wert PinStatus.VERIFIABLE zeigt an, dass eine Freischaltung noch nicht durchgeführt wurde. Die Rückgabewerte TRANSPORT_PIN und EMPTY_PIN bedeuten, dass die PIN noch mit einer Transport- bzw. Leer-PIN ausgestattet ist und noch initialisiert werden muss. Zur Initialisierung sind noch die in LeftTries angegebene Anzahl von PIN-Eingabeversuchen möglich. Das Primärsystem kann den Nutzer auf die Anzahl noch möglicher PIN-Eingaben aufmerksam machen, was insbesondere dann vorteilhaft ist, wenn nur noch ein einziger, letzter Versuch möglich ist. Der Rückgabewert BLOCKED weist darauf hin, dass die PIN dreimal falsch eingegeben wurde.

Konkret ist die Eingabe einer PIN in den folgenden Szenarien erforderlich:

• Hochsetzen des Sicherheitszustandes einer SM-B pro Kartensitzung SM-B durch Eingabe der PIN.SMC.  
  Anwendungsfälle: Aufbau der TLS-Verbindung zum Intermediär mit gegenseitiger Authentifizierung, Nutzung der SM-B im Rahmen der Card-to-Card-Authentisierung, einfache Signatur (siehe 4.4.1.1).
• Hochsetzen des Sicherheitszustandes des HBA pro Kartensitzung HBA durch Eingabe der PIN.CH.  
  Anwendungsfall: Nutzung des HBA zur Card-to-Card-Authentisierung.
• Die Eingabe der PIN.QES des HBA im Zuge der Erstellung der QES. (s. 4.4.1.7)
• <PTV4>Die Eingabe der PIN.CH der eGK bei den Anwendungsfällen der ePA "Aktenkonto aktivieren" (Operation ActivateAccount) und "Adhoc-Berechtigung erteilen" (Operation RequestFacilityAuthorization).<PTV4>

Für den Zugriff auf die geschützten Daten der eGK ist die Benutzung einer durch Eingabe der PIN.SMC freigeschalteten SM-B oder eines HBA erforderlich. Durch die Freischaltung wird der Sicherheitszustand der Karten auf das erforderliche Niveau gebracht. Auf diesem Sicherheitsniveau bleiben sie solange, bis sie den Sicherheitszustand verlieren, etwa durch Ziehen der Karte aus ihrem Kartenslot oder durch Neustart des Konnektors.

Die freigeschaltete Kartensitzung der SM-B kann von einem Clientsystem des freischaltenden Mandanten nachgenutzt werden. Zur Nachnutzung des freigeschalteten HBA muss nicht nur der Mandant, sondern auch die User-ID identisch sein und die personenbezogene Verwendung des HBA belegen.

Der Aufbau des SOAP-Request entspricht dem in Beispiel 7: Webservice-Call CardService.ChangePin.

4.2 Kartensitzungen

4.2.1 Aufbau von Kartensitzungen

Die Fachanwendung VSDM sowie der Basisdienste QES Signatur und Verschlüsselung erfordern Zugriffe auf eGK, HBA (im Folgenden analog zu verwenden: HBA-qSig, ZOD 2.0) und SM-B. Zu diesen Karten müssen vom Primärsystem aus Kartensitzungen aufgebaut werden, was dem Besitz eines gültigen Karten-Handles einer gesteckten Karte entspricht.

Der Aufbau einer Kartensitzung erfolgt entweder über den Ereignisdienst (siehe 4.1.4.2), was die komfortable und schnellste Möglichkeit aus Sicht des Primärsystems ist, ein CardHandle zu erlangen, oder das Primärsystem muss unter den vorhandenen Karten je nach Anwendungsfall vorhandene Karten abfragen und die gewünschte Karte selektieren. Der Zugriff auf die Karten wird dabei auf ihren Nutzungskontext eingeschränkt. Bei der Angabe des Nutzungskontextes (Context, vgl. 3.3.1) sind MandantID, PrimärsystemID und ArbeitsplatzID generell verpflichtend.

Kartenoperationen zum Abruf von Karten durch das Primärsystem werden durch den Konnektor über den Systeminformationsdienst EventService mit den Operationen GetCardTerminals, GetCards (siehe [gemSpec_Kon#4.1.6]) sowie dem Kartendienst CardService [gemSpec_Kon#4.1.5] angeboten.

4.2.1.1 GetCards

Mittels Systeminformationsdienst EventService.getCards kann das Primärsystem direkt ein CardHandle anfordern. Dazu ist der entsprechende Context (insbesondere die Identifikation des Arbeitsplatzes) korrekt zusammenzustellen. Im Ergebnis der Operation erhält das Clientsystem eine Liste der verfügbaren zugeordneten Karten (siehe normative Vorgaben in [gemSpec_Kon#4.1.6.5.2]). Falls gewünscht, kann unter den zurückgegebenen Karten anhand des Typs CARDCMN:CardType die eGK ausgewählt werden (Wertetabelle Kartentypen: [gemSpec_Kon#TAB_KON_500]).

Im Normalfall sollte jedem Arbeitsplatz ein Kartenterminal zugeordnet sein. Falls in einer Umgebung mit mehreren Kartenterminals (größere Praxis, Aufnahme im Krankenhaus) einem Arbeitsplatz mehrere Terminals zugeordnet sind, sollte der Benutzer im Primärsystem auswählen können, welches für den aktuellen Zugriff zu verwenden ist. Gleiches gilt für den Terminal-Slot, sofern mehrere Slots im KT zur Verfügung stehen.

Abbildung 12: Aufrufparameter von GetCards

Beispiel #: SOAP-Aufruf GetCards

Im Beispiel oben werden durch das Primärsystem (bzw. einen konkreten Arbeitsplatz) beim Konnektor alle verfügbaren Karten angefordert, die im Kartenterminal mit der ID 101 im Slot 01 stecken. Durch die genaue Angabe eines konkreten Slots kann maximal eine Karte zurückgeliefert werden.

Abbildung 13: GetCardsResponse

Die Abbildung 12 zeigt die Schemadefinition des Wrapper-Elements GetCardsResponse mit dem wiederholbaren Element Card. Diese entspricht einem Kartenobjekt im Konnektor, welches detailliert in [gemSpec_Kon#4.1.6.5.2]) beschrieben wird. Eine entsprechende SOAP-Antwort könnte folgendermaßen aussehen (nur ein Kartenobjekt gemäß dem obigen Request).

Beispiel #: GetCardsResponse mit einem Kartenobjekt als Rückgabe

Hinweis: Innerhalb der GetCardsResponse beinhaltet das Element CardVersion Versionsinformationen zu einer eingelesenen eGK (COS-Version, Objektsystemversion, usw.).

Beim Aufruf von GetCards ist die Angabe von Slot und Kartenterminal optional. Wird diese weggelassen, prüft der Konnektor die Verfügbarkeit von Karten in allen Slots aller dem Arbeitsplatz zugeordneten Kartenterminals. Sind dem Arbeitsplatz am Empfang eines MVZ, z. B. 3 Kartenterminals mit je 2 Slots zugeordnet, könnten maximal 6 Kartenobjekte vom Konnektor zurückgeliefert werden. Darüber hinausgehend kann mittels des Attributs mandant-wide="true" eine Abfrage initiiert werden, die die Kartenobjekte für sämtliche gesteckte Karten zurückliefert, die sich in allen dem Mandanten zugeordneten Kartenterminals befinden. Die Einschränkung auf die Zuordnung zum angegebenen Arbeitsplatz entfällt damit, d. h. die entsprechenden Werte csid0001 und wpid007 im folgenden Beispiel werden ignoriert. Das Primärsystem kann dazu über einen Schalter „alle Kartenterminals abfragen“ verfügen, den der Benutzer bei Bedarf aktiviert, wenn z. B. das eigene bzw. Standard-Kartenterminal momentan nicht verfügbar ist.

Beispiel #: Context mit „mandantwide=true“

Die Operation getCards liefert bei Verwendung eines oder mehrerer HSM in der Leistungserbringerumgebung als Kartentyp HSM-B zusammen mit einem CardHandle zurück, das eine virtuelle Karte repräsentiert. Aus Sicht der Schnittstelle sind SMC-B und HSM-B gleichwertig, die entsprechenden Karten-Handles gleichartig zu verwenden. Falls der Sonderfall auftritt, dass in der Liste der zurück gelieferten Karten sowohl solche des Typs SMC-B als auch des Typs HSM-B enthalten sind, obliegt dem aufrufenden System die Entscheidung, welche zu verwenden ist (z. B. anhand von Priorisierung bezüglich Performance der verschiedenen „Karten“).

4.2.1.2 GetCardTerminals

Mit der Operation GetCardTerminals des Systeminformationsdienstes kann das PS alle zugeordneten KTs bzw. Slots abfragen und dem Benutzer eine Liste zur Auswahl anbieten.

Dieser Fall kann sinnvoll sein, falls die Verfügbarkeit von Kartenterminals im Betrieb geprüft werden soll oder ein Abgleich der Konfiguration damit angestoßen wird.

Der Aufruf und die Operation ist ähnlich dem Aufruf von GetCards und detailliert in [gemSpec_Kon#4.1.6.5.1] beschrieben.

4.2.1.3 RequestCard

Als Alternative zum Kartenzugriff mittels Informationen des Systeminformationsdienstes - die im Push-Verfahren vom Konnektor bereit gestellt werden – gibt es für das Primärsystem die Möglichkeit, Informationen für den Kartenzugriff im Pull-Verfahren direkt vom Kartenterminal zu beziehen. Dazu dient die Konnektorschnittstelle CardTerminalService.RequestCard.

Tabelle 7: Tab_ILF_PS_Operation_RequestCard

Name	RequestCard
Beschreibung	Liefert die Information zu einer Karte, die in dem Slot eines Kartenterminals steckt oder innerhalb einer bestimmten Zeit (Timeout) gesteckt wird.
Aufrufparameter
	Name	Beschreibung
	CCTX:Context	MandantId, CsId, WorkplaceId verpflichtend
	CT:Slot	Adressiert den Slot eines Kartenterminals über die Identifikation des Kartenterminal CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId
	CARDCMN: CardType	Ein Kartentyp aus {EGK, KVK, HBAx, SM-B} als optionaler Filter. Wenn angegeben, werden nur Karten vom spezifizierten Typ zurückgegeben.
	CT:DisplayMsg	Diese Nachricht wird am Display des Kartenterminals angezeigt, um den Nutzer zum Stecken der Karte aufzufordern.
	CT:TimeOut	Die Zeit in sec, die maximal gewartet wird bis zum Stecken einer Karte. Wird dieser Parameter nicht übergeben, SOLL der Konnektor den Wert 20 sec verwenden. Optional KANN dieser Default-Wert im Konnektor konfigurierbar sein.
Rückgabe
	Name	Beschreibung
	CONN:Status	Enthält den Ausführungsstatus der Operation (OK oder Warning mit Fehlermeldung)
	CT:AlreadyInserted	Dieses optionale Flag gibt an, ob die Karte bereits vor der Anfrage steckte (Wert true) oder erst auf Anforderung dieses Aufrufs gesteckt wurde (Wert false oder Element nicht vorhanden).
	CARD:Card	Falls eine Karte gesteckt ist, werden Informationen zur Karte zurückgegeben: GetCardsResponse, wie als Response von GetCards beschrieben (4.2.1.1).

4.2.1.4 Exkurs 1: Auswurf von Karten mittels EjectCard

Einige Kartenterminals besitzen mechanische Vorrichtungen zum Auswurf von Karten aus dem Kartenleser. Diese Funktion kann mittels CardTerminalService.EjectCard genutzt werden, um Karten auszuwerfen. Eine geeignete Anzeige auf dem Display des Kartenterminals informiert den Benutzer darüber, die Karte zu entnehmen. Diese Anzeige fordert auch im Falle von Kartenlesern, die nicht über eine Auswurf-Funktion verfügen, dazu auf, die Karten zu entnehmen.

Tabelle 8: Tab_ILF_PS_Operation_EjectCard

Name	EjectCard
Beschreibung	Beendet die Kommunikation mit der Karte und wirft sie aus, falls das Kartenterminal eine solche mechanische Funktion hat.
Aufrufparameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId verpflichtend
	CONN: CardHandle	Adressiert die Karte, die ausgeworfen soll. Unterstützt werden die Kartentypen EGK, KVK, HBAx, SM-B und UNKNOWN.
	CT:Slot	Adressiert alternativ den Slot eines Kartenterminals, aus dem die Karte ausgeworfen werden soll. Die Adressierung erfolgt über die Identifikation des Kartenterminals CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId.
	CT: DisplayMsg	Das optionale Feld kann genutzt werden, um den Nutzer über eine Display-Message zu anzuzeigen, die von der Standard-Display-Message abweicht.
	CT:TimeOut	Die Zeit in msec, die maximal gewartet wird bis eine Karte gezogen ist. Wird dieser optionale Parameter nicht übergeben, verwendet der Konnektor den Wert 5000 msec, falls kein anderer Wert im Konnektor konfiguriert wurde.
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation (OK oder Warning mit Fehlermeldung)

4.2.1.5 Exkurs 2: Verarbeitung von Karteninformationen

Beim Stecken einer Karte in ein Kartenterminal [gemSpec_Kon#4.1.5.3.1] ermittelt der Konnektor die kartenindividuellen Daten ICCSN, Name des Karteninhabers und ggf. KVNR. Eine Authentisierung der Karte findet zu diesem Zeitpunkt noch nicht statt. Das Event CARD/INSERTED, welches als Reaktion auf das Stecken der Karte an das Primärsystem geschickt wird, enthält somit nicht authentisierte Kartendaten. Dieselben Daten werden über den Systeminformationsdienst als Antwort auf die Außenoperation GetCards und GetResourceInformation an das Primärsystem übertragen. Eine Authentisierung der gesteckten Karte findet erst statt, wenn ein VSD-Anwendungsfall dies erfordert (u.A. durch Card-to-Card-Authentisierung).

Die kartenindividuellen Daten des Eventservice informieren den Nutzer darüber, mit welcher Karte er es zu tun hat, und ihm die Auswahl der verfügbaren Anwendungsfälle ermöglichen. Das Primärsystem verwendet die Karteninformationen in den Kartensitzungen, die es benötigt, um die verfügbaren Anwendungsfälle an der Konnektorschnittstelle aufzurufen.

Für Anwendungsfälle, bei denen Patientendaten authentisiert sein müssen, sind Daten, die nur vom Eventservice geliefert wurden (ohne ReadVSD), nicht ausreichend, weil die Daten des Eventservice nicht authentisiert sind.

4.2.2 Kartensitzung eGK

Die Kartensitzung einer eGK wird durch das Primärsystem dadurch aufgebaut, dass es ein CardHandle für diese eGK erlangt und nutzt. Dies erfolgt nach dem Stecken der eGK in ein Kartenterminal über eine Ereignismeldung vom Konnektor oder durch eine Benutzerinteraktion am PS (erzeugt EventService.getCards).

Sobald ein CardHandle für eine gesteckte eGK im Primärsystem vorliegt, bleibt diese gültig, solange die Karte im Kartenterminal gesteckt bleibt. Der Konnektor speichert entsprechende Informationen für die Dauer des Vorhandenseins der eGK – ebenso wie etwaige Veränderungen des Sicherheitszustands der eGK, z. B. durch eine C2C-Authentisierung mittels SMC/HBA.

4.2.3 Kartensitzung SM-B

Die Kartensitzung einer SM-B wird durch das Primärsystem dadurch aufgebaut, dass es ein CardHandle für diese SM-B erlangt und nutzt.

Mittels Systeminformationsdienst EventService.getCards kann das Primärsystem direkt ein CardHandle anfordern. Dazu ist der entsprechende Context (insbesondere die Identifikation des Mandanten) korrekt zusammenzustellen. Sofern ein bestimmtes Kartenterminal für die SM-B vorgesehen ist, sollte die entsprechende Kartenterminal-ID im Aufruf enthalten sein.

Im Ergebnis der Operation erhält das Clientsystem eine Liste der verfügbaren zugeordneten Karten (s. [gemSpec_Kon#4.1.6.5.2]). Gegebenenfalls muss unter den zurückgegebenen Karten anhand des Typs die SM-B (bzw. eine der verfügbaren SM-Bs) ausgewählt werden.

Darüber hinaus kann der Ereignisdienst dazu verwendet werden, das CardHandle zu erhalten (siehe Kap. 4.1.4). Dazu muss das Primärsystem ein passendes Topic am Ereignisdienst abonniert haben und ggf. eine Interaktion an dem korrespondierenden Arbeitsplatz auslösen.

Zur Nutzung einer SM-B muss eine Kartensitzung, bestehend aus CardHandle und Context in den Schnittstellenaufrufen verwendet werden. Das Primärsystem kann das CardHandle von SM-B für eine geeignete Zeit zwischenspeichern (Caching) und muss bei Bedarf (z. B. Handle ungültig geworden) ein entsprechendes Handle beim Konnektor neu abfragen.

4.2.4 Kartensitzung HBAx

Im Folgenden bezeichnet „HBAx“ den HBA sowie die HBA-Vorläuferkarten wie HBA-qSig und ZOD-2.0.

Die Anwendungsfälle Signieren und Verschlüsseln sind auf eine zuverlässige Identifikation des HBA bzw. seiner Vorläuferkarten angewiesen. Dabei muss die Nutzung der Signaturkarte durch die Person erfolgen, auf welche die Signaturkarte ausgestellt ist. Die HBAx-Kartensitzung, mit der eine Anwendungsschnittstelle (Signieren oder Entschlüsseln, siehe 4.4) aufgerufen wird, muss aus Context inklusive UserId, sowie dem CardHandle bestehen. Die Angabe der UserId stellt den Bezug zu einem konkreten Benutzer her und ist bei Signaturerstellung und Entschlüsselung verpflichtend. In einigen wenigen speziellen Anwendungsfällen, etwa beim Auslesen des AUT-Zertifikates des HBAx, ist es möglich, eine HBA-Kartensitzung ohne UserId zu verwenden.

Mittels Systeminformationsdienst EventService.getCards kann das Primärsystem direkt ein CardHandle anfordern. Dazu ist der entsprechende Context (insbesondere die Identifikation des Arbeitsplatzes) korrekt zusammenzustellen. Sofern ein bestimmtes Kartenterminal für den HBA vorgesehen ist, sollte die entsprechende KartenterminalID im Aufruf enthalten sein.

Im Ergebnis der Operation erhält das Clientsystem eine Liste der verfügbaren zugeordneten Karten (s. [gemSpec_Kon#4.1.6.5.2]). Gegebenenfalls muss unter den zurückgegebenen Karten anhand des Typs der HBAx (bzw. einer der verfügbaren HBAs) ausgewählt werden.

Darüber hinaus kann der der Push-Mechanismus des Ereignisdienstes dazu verwendet werden, das CardHandle zu erhalten (siehe 4.1.4).

Zur Nutzung eines HBAxs muss eine Kartensitzung, bestehend aus CardHandle und Context inklusive UserId in den Schnittstellenaufrufen verwendet werden.

Beispiel zur Komfortsignatur (siehe 4.4.2):

Eine HBA-Inhaberin arbeitet in einer Praxisgemeinschaft an einem Arbeitsplatz (A) mit einem Clientsystem (C) für drei verschiedene Mandaten (M1, M2, M3). Sie möchte in allen drei Mandatenkontexten Komfortsignaturen mit ihrem HBA, der in einem KT steckt, das allen Mandaten zugeordnet ist, ausführen. Am Beginn des Arbeitstages aktiviert sie in einem Mandantenkontext (bspw. M2) den Komfortsignaturmodus für ihren HBA. Das PS generiert die UserID U1 und verwendet den Aufrufkontext (M2, A, C, U1) beim ActivateComfortSignature-Request an den Konnektor. Nach erfolgreicher Verifikation der PIN.QES befindet sich die dem Aufrufkontext  (M2, A, C, U1) zugeordnete Kartensitzung im Konnektor in einem erhöhten Sicherheitszustand. Wenn die HBA-Inhaberin nun Komfortsignaturen in den Mandantenkontexten M1, M2, M3 ausführen möchte, verwendet das Primärsystem für die SignDocument-Requests in allen drei Mandantenkontexten den Aufrufkontext (M2, A, C, U1), um die im Konnektor beim ActivateComfortSignature im Mandantenkontext M2 etablierte Kartensitzung mit erhöhtem Sicherheitszustand nachzunutzen.

4.3 Fachanwendung VSDM

4.3.1 Übersicht

In diesem Kapitel wird das Lesen der VSD von der eGK beschrieben. Die zugrunde liegenden Anwendungsfälle sind in der Systemlösung VSDM [gemSysL_VSDM] beschrieben.

Nach dem 1.1.2015 ist die KVK nur noch für den Bereich der Sonstigen Kostenträger ein gültiger Nachweis des Leistungsanspruches, jedoch nicht mehr für den Bereich der GKV-Kostenträger. Daher darf nach dem 1.1.2015 die KVK gemäß [KBV_ITA_VGEX_Mapping_KVK] nur noch im Bereich der Sonstigen Kostenträger verarbeitet werden^{([KBV_ITA_VGEX_Mapping_KVK], Kap. 2.2.2 mit Verweis auf die Regelungen gemäß Anlage 4a BMV-Ä/EKV)}.

Eine Aufstellung der notwendigen Arbeitsplatzkonfigurationsparameter befindet sich im Anhang 9.1.

Abbildung 14: Übersicht der Schnittstellen des Fachmoduls VSDM

4.3.2 Schnittstelle I_VSDService

Die normativen Festlegungen, Schemadarstellung und detaillierte Erläuterung der Parameter zur Schnittstelle befinden sich in [gemSpec_SST_PS_VSDM#4]. Die Schnittstelle stellt die Operation ReadVSD [gemSpec_SST_PS_VSDM#4.2] zur Verfügung, mit der sowohl die Online-Prüfung und -Aktualisierung als auch das Lesen der VSD und des Prüfungsnachweises erfolgt.

Abbildung 15: Eingangsparameter ReadVSD

Das folgende Schema zeigt die Antwortstruktur der Operation. Dabei sind zwei Elemente optional: Das Element GeschützteVersichertendaten wird nur geliefert, wenn der Zugriff durch eine Card-to-Card-Authentisierung mit entsprechender Rolle freigeschaltet wurde. Der Pruefungsnachweis wird nur zurückgeliefert, wenn er angefordert worden ist und entschlüsselt werden konnte. Näheres zum Fehlerhandling, wenn der Prüfungsnachweis nicht gelesen werden konnte, findet sich in 6.2.1.

Abbildung 16: Abb_SST_PS_VSDM_05 - Schema der Ausgangsparameter ReadVSD

Abbildung 17: Abb_SST_PS_VSDM_06 - Schema von VSD_Status

Eine detaillierte Beschreibung zur Kodierung der Daten in den Containern befindet sich im Abschnitt 4.3.5.3 und zum Informationsmodell VSD (Inhalt der dekodierten Container) in Abschnitt 4.3.5.1 sowie im Anhang der Systemlösung VSDM [gemSysL_VSDM].

4.3.3 Anwendungsfall „VSD lesen mit/ohne Online-Prüfung“

Die nachfolgende Prozessmodellierung wurde zur Verbesserung der Lesbarkeit in Subprozesse aufgeteilt.

Subprozesse werden durch ein „+“ in der Aktivität dargestellt

Abbildung 18: Anwendungsfall „VSD lesen mit/ohne Online-Prüfung“

Abbildung 19: Subprozess „eGK einlesen“

Abbildung 20: Subprozess „VSD von eGK lesen“

Der Anwendungsfall „VSD lesen mit/ohne Online-Prüfung“ kann gemäß Abbildung 18: Subprozess „eGK einlesen“ durch einen manuellen Aufruf aus dem Primärsystem oder durch den Ereignisdienst des Konnektors initiiert werden. Die entsprechenden Ereignisse und Parameter sind in 4.1.4.3 beschrieben.

4.3.4 Abläufe im Primärsystem

Im Primärsystem dient bei der Anmeldung die eGK zur Aufnahme bzw. Identifikation des Versicherten. Dabei werden die Versichertenstammdaten ausgelesen und im Primärsystem gespeichert.

Beim Erstkontakt eines Versicherten im Quartal muss zusätzlich eine Online-Prüfung und -Aktualisierung durchgeführt und die Gültigkeit der eGK überprüft werden.

Dies kann auch in einem begründeten Verdacht eines Leistungsmissbrauchs unabhängig von der quartalsweisen Online-Prüfung und -Aktualisierung notwendig werden. Vor dem Einlesen der Versichertenstammdaten muss die Identität des Versicherten anhand der vorgelegten eGK geprüft werden.

4.3.4.1 Patientendatensatz anzeigen

Die Versichertennummer der eGK ist lebenslang gültig und eindeutig. Im Folgenden ist mit der Abkürzung „KVNR“ der 10-stellige unveränderliche Teil der Versichertennummer gemeint.

Im Gegensatz zur manuellen Suche des Versicherten (z. B. mittels Name, Vorname und Geburtsdatum) besteht durch den Einsatz der eGK die Möglichkeit, den Versicherten anhand seiner eindeutigen Krankenversicherungsnummer (KVNR) automatisch im Primärsystem zu identifizieren. Beim erstmaligen Einlesen einer eGK zu einem bekannten Patienten ist eine manuelle Zuordnung zum bereits vorhandenen Patientenstamm nötig.

Zur Aufnahme eines Versicherten wird die eGK in das Kartenterminal gesteckt. Grundsätzlich lässt sich der Aufnahmeprozess auf zwei unterschiedliche Arten durchführen:

1. Automatische Identifikation des Datensatzes des Versicherten im Primärsystem beim Stecken der eGK
2. Manuelle Identifikation des Datensatzes des Versicherten im PS vor dem Stecken der eGK oder bei nicht erfolgreicher Identifikation mittels KVNR der eGK

Auf welche Weise der Aufnahmeprozess gestartet wird, wird in der Konfiguration des Primärsystems festgelegt oder ist ein Leistungsmerkmal des PS. Empfohlen wird die Unterstützung der automatischen Suche im PS, die – falls dies nicht erfolgreich war – immer durch eine manuelle Suche ergänzt werden können muss.

Automatische Identifikation des Versicherten

Voraussetzung für die automatische Identifikation des Versicherten mittels KVNR ist deren Kenntnis. Dies kann, ohne Auslesen der VSD, durch ein Abonnement des Events „Karte gesteckt“ oder durch eine Statusabfrage der gesteckten Karte(n) beim Konnektor erfolgen.

Nach der Übermittlung der KVNR durch den Konnektor prüft das Primärsystem, ob sich der Versicherte bereits im Patientenstamm des Primärsystems befindet.

Die Identifikation des Versicherten wird durch das Einlesen der eGK mittels ReadVSD abgeschlossen. Die Fachanwendung VSDM überprüft dabei den Status und die Authentizität der eGK.

Befindet sich der Versicherte noch nicht im Patientenstamm, wird der Benutzer darüber informiert. Im Falle einer Neuanlage werden die Versichertenstammdaten von der eGK gelesen und zur Neuaufnahme angezeigt.

Manuelle Identifikation des Versicherten

Bei dieser Konfiguration muss der Benutzer vor dem Stecken der eGK die Patientenstammdaten anhand von Suchparametern (z. B. Name, Vorname und Geburtsdatum) im Bestand des Primärsystems suchen. Anschließend steckt er die eGK des Versicherten in das Kartenterminal, um die Daten des Versicherten einzulesen. Dieser Ablauf sollte nur in Ausnahmefällen angewendet werden, wenn die Identifikation anhand einer manuell oder automatisch ermittelten KVNR fehlschlägt.

Bei einer manuellen Identifizierung des Versicherten im PS sollte der Benutzer beim Öffnen des Patientendatensatzes einen speziellen Hinweis erhalten, wenn die eGK des Patienten im laufenden Quartal bereits eingelesen worden ist, aber noch keine erfolgreiche Online-Prüfung durchgeführt werden konnte (Prüfungsnachweis aus laufendem Quartal ist zwar vorhanden, das Ergebnis ist aber 3-6).

4.3.4.2 eGK einlesen

Ist der Versicherte nicht im Patientenstamm vorhanden, kein gültiger Prüfungsnachweis aus dem laufenden Quartal vorhanden oder liegen andere Gründe für eine Aktualisierung vor, muss das Primärsystem das Lesen der eGK initiieren und dabei ggf. eine Online-Prüfung und -Aktualisierung anstoßen.

Ein Online-Prüfung und -Aktualisierung muss dabei in folgenden Fällen durchgeführt werden:

• erster Besuch des Versicherten im laufenden Quartal
• vorhandener aktueller Prüfungsnachweis aus im Quartal vorangegangener Online-Prüfung mit den Ergebnissen
• • 3 = Aktualisierung VSD auf eGK technisch nicht möglich,
  • 4 = Authentifizierungszertifikat eGK ungültig,
  • 5 = Online-Prüfung des Authentifizierungszertifikats technisch nicht möglich,
  • 6 = Aktualisierung VSD auf eGK technisch nicht möglich, da maximaler Offline-Zeitraum überschritten
• wenn der Benutzer dies anfordert
• falls im Primärsystem hinterlegt ist, dass die Online-Prüfung immer durchgeführt werden soll, um bestmögliche Aktualität der Daten zu erreichen

Tabelle 9: Tab_ILF_PS_Konfigurationsparameter_zur_Online-Prüfung_und_-Aktualisierung

Um mittels Prüfnachweis eine erfolgreiche Onlineprüfung zu dokumentieren, muss beim ersten Besuch im Quartal ein ReadVSD mit Onlineprüfung stattfinden. (Die Häufigkeit der Prüfung kann jedoch gemäß Tabelle Tab_ILF_PS_Entscheidungstabelle_Parametrisierung_ReadVSD so konfiguriert werden, dass auch bei Folgekontakten im selben Quartal eine Prüfung stattfindet.)

Hinweis: In größeren Einrichtungen, bei denen Versicherte nicht persönlich bekannt sind, ist eine Online-Prüfung der Authentizität der eGK auch bei Folgebesuchen im Quartal geeignet, um Missbrauch zu vermeiden. Dieser Zweck wird erfüllt, indem der Konfigurationswert des Parameters MODE_ONLINE_CHECK auf den Wert ALWAYS gesetzt wird. Dann wird die Identifizierung des Patienten durch eine Online-Aktualitätsprüfung seiner eGK komplettiert.

Die Tabelle Tab_ILF_PS_Entscheidungstabelle_Parametrisierung_ReadVSD zeigt die notwendigen Werte der Parameter ReadOnlineReceipt und PerformOnlineCheck in Abhängigkeit von der Systemkonfiguration (des gewünschten Verhaltens) und des Vorhandensein eines gültigen Prüfungsnachweises für das aktuelle Quartal.

Tabelle 10: Tab_ILF_PS_Entscheidungstabelle_Parametrisierung_ReadVSD

*) Diese Spalte entspricht dem Element Pruefungsnachweis. Ergebnis und bedeutet für die Werte 1 und 2 einen im PS vorlegenden Prüfungsnachweis nach fehlerfreier Online-Prüfung (1=Aktualisierung erfolgreich durchgeführt, 2=keine Aktualisierung notwendig). Die Werte 3-6 deuten auf einen Fehler bei der Online-Prüfung oder -Aktualisierung und damit die Notwendigkeit einer erneuten Prüfung hin.

Wenn ein Prüfnachweis auf der eGK nicht entschlüsselt werden kann, ist die entsprechende Fehlermeldung ein Hinweis darauf, dass der Prüfnachweis von einem anderen Leistungserbringer stammt. Im Falle eines für das Quartal noch nicht vorliegenden Prüfnachweises muss die Online-Prüfung durchgeführt werden, damit der LE nach einem erneuten Einlesen einen gültigen PN für das Quartal erhält.

4.3.4.2.1 Online-Szenario

Damit das Clientsystem steuern kann, ob eine Online-Prüfung durchgeführt werden soll, bietet die Operation den Parameter PerformOnlineCheck. Ist der Parameter auf true gesetzt, führt das Fachmodul eine Aktualisierungsanfrage durch. Es wird davon ausgegangen, dass das Primärsystem die durchgeführten Online-Prüfungen aufzeichnet.

Ist der Parameter auf false gesetzt, führt das Fachmodul nur aus fachlichen Gründen gemäß [gemSysL_VSDM#VSDM-UC_01] eine Aktualisierungsanfrage durch, z. B. wenn die Gesundheitsanwendung der eGK bereits gesperrt ist.

Ebenfalls legt das Clientsystem mittels des Parameters ReadOnlineReceipt fest, ob ein Prüfungsnachweis zurückgegeben wird. Ist der Parameter ReadOnlineReceipt=true gesetzt, wird ein Prüfungsnachweis zurückgegeben, andernfalls enthält die Antwort (Response) keinen Prüfungsnachweis.

Im Online-Szenario ist die Parametrisierung PerformOnlineCheck=false und ReadOnlineReceipt=true nicht sinnvoll.

4.3.4.2.2 Standalone-Szenario (Primärsystem mit Offline-Konnektor verbunden)

Im Standalone-Szenario ist die Parametrisierung PerformOnlineCheck=true beim Aufruf ReadVSD nicht zulässig („Offline-Konnektor“), da in diesem Fall die Aktualisierung immer scheitert und dadurch ein entsprechend negativer Prüfungsnachweis erzeugt würde. Im Standalone-Szenario ist der Parameter über die Konfiguration des Primärsystems auf false zu setzen.

Im Standalone-Szenario ist die Parametrisierung PerformOnlineCheck=false und ReadOnlineReceipt=true der Standardfall und im normalen Ablauf zu setzen. Es ist davon auszugehen, dass am Online-Konnektor zuvor immer eine Prüfung und ggf. Aktualisierung der Karte stattgefunden hat sowie dabei ein entsprechender Prüfungsnachweis erzeugt und auf die Karte geschrieben worden ist. Dieser wird durch diese Parameterkombination von der Karte gelesen.

4.3.4.3 Benutzerinteraktionen/Anforderungen

Ist eine Online-Prüfung und -Aktualisierung nicht notwendig, soll dem Benutzer ein entsprechender Hinweis angezeigt werden. Er kann nun entscheiden, ob die VSD von der eGK gelesen werden sollen. Dies kann der Fall sein, wenn die eGK im Quartal bereits eingelesen wurde, aber eine Aktualisierung der VSD in einer anderen Praxis stattgefunden hat. So können die Daten im Primärsystem an den aktuellen Stand angepasst werden.

Der Benutzer muss die Möglichkeit haben, eine Online-Prüfung auch manuell durchzuführen.

Kann die Online-Prüfung und -Aktualisierung nicht durchgeführt werden, z. B. weil der Konnektor zum Zeitpunkt der Anfrage offline ist, darf ein für das aktuelle Quartal im Primärsystem existierender Prüfungsnachweis nicht überschrieben werden.

Unabhängig von einer Protokollierung der Ausführungszeiten im Primärsystem stehen im Fachmodul des Konnektors Performance- und Fehlerprotokolle zur Auswertung zur Verfügung.

Nach Beendigung wird das Ergebnis der Prüfung durch das Primärsystem angezeigt.

Im Fehlerfall muss dem Benutzer eine aussagekräftige Meldung mit der Fehlerursache angezeigt werden, damit das Ersatzverfahren eingeleitet werden kann.

Bei einer fehlerfreien Durchführung werden die Stammdaten des Versicherten am Primärsystem angezeigt.

Liegen Unterschiede zwischen den im Primärsystem gespeicherten und den von eGK gelesenen VSD vor, soll das PS dem Benutzer die Unterschiede in geeigneter Form darstellen, z. B. Vergleich Alt/Neu mit Hervorhebung der Veränderungen.

Der Prüfungsnachweis muss in das Praxisverwaltungssystem übernommen werden, da er Bestandteil der Abrechnung ist.

Zur Prüfung des Leistungsanspruchs des Versicherten prüft das Primärsystem das aktuelle Tagesdatum gegen die Angaben zum Versicherungsschutz. Die eGK ist kein gültiger Leistungsanspruchsnachweis, wenn das Tagesdatum vor Beginn des Versicherungsschutzes oder nach dessen Ende liegt.

Dies ist auch der Fall, wenn ein ruhender Leistungsanspruch vorliegt.

4.3.4.3.1 Manuelle Online-Prüfung und -Aktualisierung

Bei dieser Konfiguration entscheidet der Benutzer, ob eine Online-Prüfung und -Aktualisierung durchgeführt wird. Dazu erhält er vom Primärsystem die Information, ob es sich um den Erstbesuch des Versicherten im Quartal handelt (siehe auch [VSDM-A_2532]), oder ob eine erneute Online-Prüfung und -Aktualisierung (z. B. offline) erforderlich ist.

Der weitere Ablauf entspricht dem der oben genannten Online-Prüfung und -Aktualisierung.

Hinweis zur Konfiguration des Gesamtsystems bei automatischem ReadVSD: Das Primärsystem kann ein ReadVSD (inklusive Online-Prüfung) ermöglichen, das durch ein Kartensteck-Event automatisch ausgelöst wird. In diesem Fall müssen Umgebungen, in denen mehrere Clientsysteme ReadVSD am selben Kartenterminalslot aufrufen sollen, so konfiguriert werden, dass nur ein Clientsystem die Komfort-Konfiguration eines automatisierten ReadVSD am selben Kartenterminalslot nutzen darf, und alle anderen Clients für diesen Kartenterminalslot auf eine manuelles ReadVSD konfiguriert sind. Auf das Ereignis des Steckens einer eGK darf nur ein Client sofort automatisch ReadVSD inklusiver automatischer Online-Prüfung durchführen. Dabei sollte ein automatisiertes EjectCard nicht stattfinden, um den anderen Clientsystemen den nachfolgenden manuell ausgelösten Zugriff auf die eGK nicht zu verwehren.

4.3.4.4 Nutzung der VSDM-Ereignisse des Systeminformationsdienstes

Folgende Tabelle beschreibt die über den Systeminformationsdienst (EventService) des Konnektors durch das Fachmodul bereitgestellten Ereignisse. Sofern das Primärsystem entsprechende Ereignisse abonniert hat (bezogene auf bestimmte Kartenterminals oder alle), werden diese Ereignisse entsprechend zugestellt (siehe Lane „Konnektor“ in Abbildung 18).

Tabelle 11: Tab_ILF_PS_VSDM-Ereignisse

Die Nutzung des Systeminformationsdienstes soll sowohl zum Auswerten von Kartenereignissen (Karte gesteckt, Karte entfernt) als auch der VSDM-Ereignisse für eine Fortschrittsanzeige vom Primärsystem umgesetzt werden.

4.3.4.5 Beispiele ReadVSD

Das in der WSDL angegebene SOAP-Encoding „document/literal“, sorgt in Kombination mit dem definierten Schema VSDService.xsd und dem darin enthaltenen Root-Element ReadVSD für die Kodierung im Beispiel unten (wrapped document/literal, keine Typangaben innerhalb der Elemente, das Element ReadVSD entspricht dem Namen der Methode). Damit lässt sich der Body der SOAP-Nachricht direkt gegen das Schema prüfen.

Beispiel #: Ausschnitt aus VSDService.wsdl

Beispiel #: Beispiel für einen SOAP-Call ReadVSD

In obigem SOAP-Aufruf wird die Operation ReadVSD mit folgenden Parametern aufgerufen:

Karten-Handle:

• eGK-Karten-Handle „ehc0123456789“, welches zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt wurde
• SM-B-Karten-Handle „hpc112233“, welches zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCard() ermittelt wurde

Online-Prüfung und Prüfungsnachweis:

• mit dem Parameter PerformOnlineCheck=true wird eine Online-Prüfung und -Aktualisierung durch den Konnektor initiiert, bevor die VSD zurückgegeben werden
• mit dem Parameter ReadOnlineReceipt=true wird der Prüfungsnachweis als Bestandteil von ReadVSDResponse angefordert. Dieser wird im Online-Szenario direkt während der Verarbeitung von ReadVSD durch das Fachmodul erzeugt und je nach Status (erfolgreich, nicht notwendig, Warnung) mit entsprechendem Ergebnis zurückgeliefert

Context:

• MandantId mit Wert „m0001“, die sowohl im Primärsystem als auch im Konnektor so hinterlegt sein muss
• ClientSystemId mit Wert „cs0001“, die im Primärsystem fest hinterlegt und im Konnektor konfiguriert und dem Mandanten „m0001“ zugeordnet sein muss
• WorkplaceId „wp007“, die sowohl im Primärsystem als auch im Konnektor konfiguriert ist und im Konnektor dem Mandanten „m0001“ als auch dem Primärsystem „cs0001“ zugeordnet ist
• Die Angabe eines Benutzers (UserID) ist für ReadVSD nur notwendig, wenn ein Karten-Handle eines HBAx verwendet wird (anstelle SM-B).

Auf diese Anfrage zum Fachmodul VSDM des Konnektors sind verschiedene Antworten möglich. Dabei sollen drei Fälle unterschieden werden:

• Erfolg: Rückgabe der VSD inklusive erfolgreich durchgeführter Online-Prüfung und -Aktualisierung (bzw. nicht notwendiger Prüfung)
• Warnung: Rückgabe der VSD, aber mit nicht erfolgreicher Online-Prüfung (entsprechende Ergebnis-Codes im Prüfnachweis)
• Fehler: SOAP-Fault (siehe 6.2.1)

Beispiel #: ReadVSDResponse bei Erfolg oder Warnung

Die Inhalte der Elemente PersoenlicheVersichertendaten, AllgemeineVersicherungsdaten, GeschuetzteVersichertendaten und Pruefungsnachweis sind komprimiert sowie base64-kodiert (siehe 4.3.5.3) und müssen vor dem Parsen entsprechend dekodiert werden.

4.3.5 Informationsmodell VSD

4.3.5.1 Versichertenstammdaten GKV

Abbildung 21: Informationsmodell Versichertenstammdaten GKV

Die Tabelle Tab_ILF_PS_Änderungen_im_VSD-Schema_5.2 zeigt einige für das Primärsystem relevante Änderungen in der VSD-Schemaversion 5.2 gegenüber Version 5.1. Die meisten Änderungen betreffen die Verarbeitungslogik und/oder Datenspeicherung im Primärsystem (z. B. Änderung der Kardinalität oder zusätzliche Daten).

Tabelle 12: Tab_ILF_PS_Änderungen_im_VSD-Schema_5.2

Im Wirkbetrieb der TI kann bei bereits im Feld befindlichen Karten der Generation 1plus auch ein Schema der Version 5.1 gespeichert sein und mittels ReadVSD geliefert werden. Dies geschieht, wenn die betreffende Karte nicht zuvor auf das Schema 5.2 aktualisiert wurde. Die Schemaversion 5.1 ist Bestandteil des Basis-Rollouts und die normativen Vorgaben entsprechend im Release 0.5.3 veröffentlicht.

4.3.5.2 Versichertenstammdaten PKV

Mit der Einführung des Versichertenstammdatenmanagements für die privaten Krankenversicherer wird ein eigenes VSD-Schema in der Schemaversion 1.0.0 eingeführt, welches sich inhaltlich an der Schemaversion 5.2.0 orientiert. 

Abbildung 22: Informationsmodell Versichertenstammdaten PKV

Die Tabelle Tab_ILF_PS_Änderungen_im_VSD-Schema_1.0.0 zeigt die für das Primärsystem relevante Änderungen der VSD-Schemaversion 1.0.0 der PKV gegenüber der VSD-Schemaversion 5.2 der GKV. Die Änderungen betreffen Zusatzinformationen, die das private Versicherungsverhältnis betreffen.

Tabelle 13: Tab_ILF_PS_Änderungen_im_VSD-Schema_1.0.0

Das vollständige Schema "Schema_VSD_PKV.xsd" ist in GitHub veröffentlicht: https://github.com/gematik/api-telematik/tree/OPB4/fa/vsds 

4.3.5.3 Prüfungsnachweis GKV

Mit Einführung des Versichertenstammdatenmanagements wird in der Regel auch der Prüfungsnachweis an das Primärsystem übergeben. Für jeden Patienten wird der für das jeweilige Quartal gültige Prüfungsnachweis im Primärsystem gespeichert. Der auf der eGK des Versicherten befindliche Prüfungsnachweis wird bei erneuter Online-Prüfung und -Aktualisierung überschrieben, so dass sich immer nur der Prüfungsnachweis der letzten Online-Prüfung und -Aktualisierung auf der eGK befindet.

Abbildung 23: Informationsmodell Prüfungsnachweis GKV

4.3.5.4 Prüfungsnachweis PKV

Abbildung 24: Informationsmodell Prüfungsnachweis PKV

Tabelle 14: Tab_ILF_PS_Änderungen_im_Prüfungsnachweis_PKV

Das vollständige Schema "Prüfungsnachweis_PKV.xsd" ist in GitHub veröffentlicht: https://github.com/gematik/api-telematik/tree/OPB4/fa/vsds 

4.3.5.5 Zeichenkodierung von Daten

Die von ReadVSD und ReadKVK zurück gelieferten Ausgangsparameter (Response der SOAP-Nachricht sind mehrheitlich base64-kodierte und gzip-komprimierte XML-Strukturen (VSD_Status).

Zur besseren Einordnung hier eine Übersicht der verschiedenen Datenformate und Konvertierungen für die Container PD, VD, GVD und Prüfungsnachweis.

Tabelle 15: Tab_ILF_PS_Übersicht_Datenformate

Bevor die eigentlichen Datenstrukturen verarbeitet werden können, müssen eine Dekodierung des Base64-Formates und eine Dekomprimierung erfolgen. Anschließend kann das Parsen und Validieren der XML-Strukturen durchgeführt werden.

Bis zu einem durch die Vertragspartner festzulegenden Zeitpunkt werden GVD zusätzlich im ungeschützten Bereich der eGK gespeichert.

4.3.5.6 Dekodierung und Schemavalidierung

Die Elemente PersoenlicheVersichertendaten, AllgemeineVersicherungsdaten, GeschuetzteVersichertendaten und Pruefungsnachweis müssen vor dem Parsen/Auslesen zunächst mittels des Base64-Algorithmus dekodiert werden und anschließend mit Hilfe von gzip dekomprimiert werden.

Danach stehen mindestens 2 XML-Elemente (PersoenlicheVersichertendaten, AllgemeineVersicherungsdaten) sowie ggf. die optionalen Elemente (GeschuetzteVersichertedaten, Pruefungsnachweis) zur weiteren Verarbeitung im Primärsystem zur Verfügung.

4.3.6 Schnittstelle I_KVKService

Da die KVK bis auf weiteres noch für den Bereich der Sonstigen Kostenträger und die PKV einen gültigen Versicherungsnachweis darstellt, muss dieser Kartentyp auch weiterhin verarbeitbar sein. Hierzu bietet das Fachmodul VSDM den Aufruf ReadKVK an, dem lediglich der Parameter KVKHandle übergeben werden muss. Analog zu den bisherigen Abläufen muss das Kartenhandle KVKHandle mittels der Basisfunktionen des Konnektors (z. B. GetCards) ermittelt werden. In der Rückgabe des Aufrufes erhält man ein base64Binary-kodiertes ASN.1-Objekt, das Versichertendatentemplate der KVK. Dieses Objekt wurde vom Fachmodul entsprechend den Anforderungen aus [gemSpec_FM_VSDM] geprüft, so dass es wie bisher direkt verarbeitet werden kann.

4.3.7 Datenaustausch mit mobilen Einsatzgeräten

Mobile Kartenterminals kommen im Normalfall immer dann zum Einsatz, wenn die Daten nicht direkt in dem Abrechnungssystem erfasst werden können. Diese Fälle treten ein bei

• Hausbesuch
• Leistungserbringung im Umfeld eines anderen Leistungserbringers
• Notfallbehandlung.

Das Einlesen und Speichern von Versichertendaten mit Hilfe eines mobilen Kartenterminals ist auch ein mögliches Szenario für Ausfälle der dezentralen Komponenten der Telematikinfrastruktur (Konnektor bzw. Kartenterminal) als Alternative zum aufwendigeren Ersatzverfahren.

Die Schnittstelle zum mobilen Kartenterminal stellt für eGK-Daten eine Leseoperation mit 4 Ausprägungen zur Verfügung, mit denen die PD, VD, GVD sowie Statusinformationen übernommen werden können. Ein Prüfungsnachweis wird durch das mobile Kartenterminal nicht erzeugt und ist damit nicht auslesbar. Anstelle dessen wird als Bestandteil der Statusinformationen eine Zulassungsnummer des mobilen Kartenterminals übermittelt. Die Verwendung dieser Nummer zu Abrechnungszwecken erfolgt nach Maßgabe der Vertragspartner.

Da in einem mobilen Kartenterminal mehrere Datensätze gespeichert werden können, soll die Übernahme in das Primärsystem derart gestaltet sein, dass die Zuordnung zu den Patientenstammdaten möglichst automatisch abläuft. Eine mehrfache Authentisierung am mobilen Kartenterminal soll vermieden werden.

Die Schnittstelle zum Datenaustausch mit mobilen Kartenterminals basiert auf der Simulation eines Kartenterminals (CT-API) und ist in [gemSpec_MobKT] beschrieben. Die komprimierten Container (gzip) können dabei über spezielle Kartenkommandos direkt gelesen werden. Die anschließende Weiterverarbeitung entspricht der nach der Base64-Dekodierung der XML-Elemente im Anschluss an ReadVSD der Webservice-Schnittstelle.

Um mehrere Datensätze auslesen zu können, muss das Primärsystem die Fortschaltsperre des mobilen Kartenterminals in seinem Leseprozess berücksichtigen. Die Fortschaltsperre am MobKT macht es erforderlich, Datensätze einzeln auszulesen und nach dem Auslesen zu löschen, um weitere Datensätze lesen zu können. Durch das Löschen des als übertragen markierten Datensatzes durch das Primärsystem wird sichergestellt, dass Datensätze nicht mehrfach ausgelesen werden können. Die Notwendigkeit des Löschens als ausgelesen markierte Datensätze (Fortschaltsperre) wird vom MobKT durchgesetzt (vgl. [gemSpec_MobKT]#6.5).

4.4 <PTV2> Signaturerstellung und Verschlüsselung

Der Konnektor stellt generische Schnittstellen für QES-Basisdienste zur Verfügung (SignatureService, EncryptionService, CertificateService, AuthSignatureService), sowie Schnittstellen für die tokenbasierte Authentisierung. Diese Schnitt­stellen können vom Primärsystem in einer Vielzahl von Szenarien genutzt werden:

• Signatur und Signaturprüfung mit Identitäten von SMC-B, HBA und HBA-Vorläuferkarten;
• Ver- und Entschlüsselung von Dokumenten und Daten mit SMC-B, HBA und HBA-Vorläuferkarten;
• Authentisierung mit SMC-B, HBA und HBA-Vorläuferkarten;
• Smartcard-Zertifikatsabfragen und Prüfung von Zertifikaten.

Die Operationen dieser Dienste können einzeln genutzt werden. Sie ermöglichen, Dokumente mithilfe von Zertifikats- und Verschlüsselungsmaterial von Smartcards zu verschlüsseln und zu signieren. Wenn es sich bei der Smartcard um eine sichere Signaturerstellungseinheit für qualifizierte Signaturen handelt, so wird das Niveau einer qualifizierten elektronischen Signatur (QES) erreicht.

Das Primärsystem kann den Leistungsumfang des Signaturdienstes des Konnektors nur nutzen, wenn am Konnektor der entsprechende Parameter konfiguriert ist.

Die Anzeige für zu signierende oder zu prüfende Dokumente findet im Clientsystem statt. Das Clientsystem kommuniziert direkt mit dem Konnektor.

Damit die für Anzeige und Benutzerinteraktion verantwortliche Komponente die Verarbeitung einer Stapelsignatur abbrechen kann, stellt der Konnektor einen besonderen Mechanismus bereit: Der Konnektor gibt über die Operation GetJobNumber eine Jobnummer heraus, die beim Aufruf der Operation SignDocument am Konnektor als Aufrufparameter mitgegeben werden muss und mit der eine laufende Verarbeitung durch Aufruf der Operation StopSignature am Konnektor abgebrochen werden kann.

Der Konnektor kann den Revocation-Status von Zertifikaten im Rahmen des Signatur- und Verschlüsselungsdienstes nur dann überprüfen, wenn der Konnektor die volle Online-Funktionalität nutzt.

Formate von Dokumenten sind dem Clientsystem bekannt und müssen an den unten beschriebenen Schnittstellenaufrufen auch dem Konnektor bekannt gegeben werden, damit dieser die dokumententypspezifischen Verarbeitungsschritte durchführen kann.

Die nicht-XML-Formate werden dabei nach MIME-Typ-Klassen unterschieden:

• „PDF/A” für MIME-Typ „application/pdf-a",
• „Text” für MIME-Typ „text/plain”,
• „TIFF“ für MIME-Typ „image/tiff”
• „Binär“ für alle übrigen MIME-Typen.

<PTV4>Um die Interoperabilität der Dokumentenvalidierung zu gewährleisten, muss für das Format PDF/A die PDF/A-ID als XML-Element in den Metadaten des Dokuments stehen, etwa in der Form
<pdfaid:part xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">1</pdfaid:part>
</PTV4>

<PTV4> Nach der Einführung von elliptischen Kurven auf TI-Smartcards der Generation G2.1 ist es optional möglich, bei Operationen des Signatur- und Zertifikatsdienstes und der Authentisierung auszuwählen, ob ECC- und einer RSA-Zertifikate verwendet werden. 

Das Defaultverhalten an der Konnektorschnittstelle ist so beschaffen, dass ohne explizite Steuerung der Optionen RSA oder ECC durch das PS der Konnektor unter Auswertung der verfügbaren Karten die geeigneten Zertifikate auswählt.

Wenn ein PS das Default-Verhalten des Konnektors durch Nutzung der Auswahloption übersteuern möchte, ist es darauf angewiesen, den Typ der verwendeten Karte zu ermitteln. Im Rückgabewert von getCards ist an der VersionInfo in CARD:CardVersion/CARD:ObjektSystemVersion erkennbar, ob eine Karte der Generation G2.1 oder höher mit einem ECC-Zertifikat vorliegt. Jede Smartcard mit einer Objektsystemversion >= 4.4.0 (Major.Minor.Revision-Versionsnummer) enthält ECC-Zertifikate.</PTV4>

An PTV3-Konnektoren werden auch bei Karten der Generation G2.1 deren RSA-Zertifikate verwendet.

4.4.1 Erstellen digitaler Signaturen

Der Konnektor bietet seinen Clients im SignatureService eine Operation zum Signieren von Dokumenten mittels Smartcards an (SignDocument) sowie eine Operation zum Verifizieren von signierten Dokumenten (VerifyDocument).

Die Anzeige der Jobnummer dient dem Nutzer dazu, die Jobnummer, die am Kartenterminal bei der Aufforderung zur PIN-Eingabe angezeigt wird, dem Signaturauftrag zuordnen zu können. Unter Angabe der Jobnummer kann das Primärsystem mit StopSignature das Signieren von Dokumentenstapeln abbrechen.

Hinweis: Eine normative und noch detailliertere Beschreibung der Signaturschnittstelle erfolgt in [gemSpec_Kon#4.1.8.5]. Dort finden sich ggf. auch Erläuterungen zu den Parametern OptionalInput etc., die alle Signaturvarianten betreffen und hier nicht aufgeführt sind. Die im Folgenden beschriebenen Parameter dienen nur der Einführung in die Benutzung der Signaturschnittstelle, zu deren vollständigem Verständnis auch die Standards [OASIS-DSS], [CAdES], [XAdES] etc., sowie das Schema „SignatureService“ (z.B. bzgl. der Option OCSP-Antworten in die Signatur einzubetten) herangezogen werden müssen.

Wenn bei der Nutzung der Signatur- und Verschlüsselungsschnittstelle AdES-Profile gelten, so gelten ausschließlich die AdES-BES-Profile. Dabei gelten die Baseline-Profilierung gemäß Kapitel 6 in [XAdES Baseline Profile] für XAdES, Kapitel 6 in [CAdES Baseline Profile] für CAdES und Kapitel 6 in [PAdES Baseline Profile] für PAdES.

Die Außenschnittstellen des Basisdienstes Signaturdienst (nonQES und QES) werden in [gemSpec_Kon#4.1.8.5] festgelegt.

Die Signaturabläufe unterscheiden sich geringfügig bei Anwendungsfällen, in denen eine QES erzeugt wird, und solchen Anwendungsfällen, in denen nicht qualifiziert signiert wird.

Entscheidend dafür, ob qualifiziert signiert wird oder nicht, sind die verwendeten Zertifikate sowie der Dokumententyp. Insbesondere unterstützt die Operation SignDocument den HBAx nur für QES, nicht für nonQES. Im Parameter CCTX:Context kann der HBAx nur für die QES, nicht jedoch für nonQES verwendet werden.

Die Operation SignDocument und ihre Parameter lehnen sich an [OASIS-DSS] an. Folgende Typen von Signaturen können am Konnektor erstellt werden:

• XML-Signatur (s. 4.4.1.1), QES oder nonQES
• CMS-Signatur (s. 4.4.1.2), QES oder nonQES
• S/MIME-Signatur (s. 4.4.1.3), nonQES
• PDF-Signatur (s. 4.4.1.4), QES oder nonQES
• PKCS#1-Signatur/External Authenticate (s.4.4.5.1), nonQES

Tabelle 16: Tab_ILF_PS_Zuordnung_zwischen_HBAx_oder_SM-B,_Dokumententypen_und_Signaturtypen

Das Primärsystem muss den SignatureService mit Parametern aufrufen, die jeweils auf einen einzelnen speziellen Daten- und Signaturtyp ausgelegt sind, und die Signatur mit einer einzelnen Signaturkarte durchführen. Eine Mischung von verschiedenen Datentypen und Signaturtypen in einem einzelnen Aufruf von SignDocument ist nicht zulässig.

Das Primärsystem muss es dem Benutzer ermöglichen, SignDocument und VerifyDocument mit Stapeln von Dokumenten der Dokumententypen XML, PDF/A, Text, TIFF, MIME aufzurufen, die jeweils insgesamt nicht größer sind als 250 MB. Der gesamte, zu signierende Dokumentenstapel eines Aufrufes von SignDocument darf nicht größer als 250MB sein.

Für die Einzelsignatur wird die Schnittstelle der Stapelsignatur nachgenutzt: Bei der Signatur einzelner Dokumente besteht die Liste der zu signierenden bzw. zu verifizierenden Dokumente jeweils aus einem einzelnen Dokument.

Eine Parallelsignatur wird durch mehrmaligen Aufruf von SignDocument unter Angabe des entsprechenden Parameters erzeugt.

Dokumenteninkludierende sowie dokumentenexkludierende Gegensignaturen auf bereits im Dokument bestehende Signaturen werden durch Aufruf von SignDocument unter Angabe eines entsprechenden Parameters erzeugt.

Abbildung 25: Eingangsparameter SignDocument

Anhand der Eingangsparameter steuert der Konnektor den weiteren Signaturvorgang.

• Einfache Signatur ohne Berücksichtigung womöglich bereits bestehender Signaturen, falls dss:ReturnUpdatedSignature fehlt.
• Parallelsignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/parallel
• Dokumentinkludierende Gegensignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/counter/documentincluding
• Dokumentexkludierende Gegensignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/counter/documentexcluding

Eine Parallelsignatur wird durch mehrmaligen Aufruf von SignDocument unter Angabe des entsprechenden Parameters (dss:ReturnUpdatedSignature) erzeugt.

Gegensignaturen auf bereits im Dokument bestehende Signaturen werden durch Aufruf von SignDocument unter Angabe des entsprechenden Parameters (dss:ReturnUpdatedSignature) erzeugt. Über die Eingangsparameter lässt sich steuern, ob eine dokumenteninkludierende oder eine dokumentenexkludierende Gegensignatur erzeugt wird.

Abbildung 26: Anwendungsfall „Dokumente digital signieren“

Der Konnektor ermöglicht im Zusammenspiel mit einer geeigneten Signaturkarte eine Stapelsignatur. Das PS stellt Dokumente zu einem Stapel zusammen, um sie gemeinsam über SignDocument zu signieren.

Die Übergabe des Dokumentenstapels an den Konnektor realisiert das Primärsystem als mehrfache Anlage des in [OASIS-DSS] Section 2.4.2 spezifizierten Elementes dss:Document. Das darin enthaltene Attribut ShortText muss mit einem Ausdruck gefüllt werden, der auf die Identität des Dokumentes schließen lässt, etwa ein Name oder eine Kurzbeschreibung des Dokumentes. Es darf ausschließlich folgende Zeichen enthalten: 

• Klein- und Großbuchstaben [a-z][A-Z]
• deutsche Umlaute ä, ö, ü, Ä, Ö, Ü, ß
• Ziffern [0-9]
• Whitespace " "
• Punkt "."
• Unterstrich "_"
• Bindestrich "-"

Das Signieren eines einzelnen Dokumentes stellt den Sonderfall eines Dokumentenstapels der Größe 1 dar.

In Bezug auf die QES-Stapelsignatur unterscheiden sich HBAs von HBA-Vorläuferkarten:

• Die HBA-Vorläuferkarten können mittels Konnektor nicht für Stapelsignaturen verwendet werden. 
• Für HBAs steuert der Konnektor die Eingabe der Signatur-PIN am Kartenterminal. Wenn ein Signaturstapel mehr Dokumente enthält, als im Signaturzertifikat angegeben, wird der Signaturstapel vom Konnektor geteilt. Der Konnektor fordert in diesem Fall für jeden Teilstapel eine PIN-Eingabe an.

Listen mit Dokumenten, die nicht qualifiziert signiert werden, signiert der Konnektor ohne Abfragen einer PIN, solange die SM-B freigeschaltet ist.

<PTV4> Nach der Einführung von elliptischen Kurven auf TI-Signaturkarten der Generation G2.1 ist es möglich, mittels des optionalen Parameters Crypt auszuwählen, ob mit ECC- oder RSA-Zertifikaten signiert wird.

Tabelle 17: Tab_ILF_PS_Steuerung_Signaturalgorithmus

Sämtliche Konnektoren können mit elliptischen Kurven erstellte Signaturen validieren. Dennoch werden zunächst mit dem PTV4-Konnektor ausschließlich RSA-Signaturen erstellt. Erst wenn die Migration hin zu ECC vollständig ist, werden die Optionen „ECC“ und „RSA_ECC“ in Tabelle Tab_ILF_PS_Steuerung_Signaturalgorithmus nutzbar sein und das Defaultverhalten hin zu „ECC“ geändert.

Bei Bedarf (etwa für Verwendungszwecke der Signatur außerhalb der TI) kann das Default-Verhalten des Konnektors dennoch durch Auswahl von RSA übersteuert werden, so dass der Konnektor unabhängig von der Signaturkarte auf eine Verwendung von RSA festgelegt wird.

</PTV4>

Beim Aufruf der Operation SignDocument am Konnektor muss der Aufrufer eine JobNumber als Parameter mitgeben. Da diese JobNumber zum eindeutigen Identifizieren des Aufrufs verwendet wird, weist der Konnektor Aufrufe ab, wenn die JobNumber innerhalb der letzten 1000 Aufrufe, die insgesamt an den Konnektor gestellt wurden, bereits verwendet wurde.

Kommuniziert das Clientsystem direkt mit dem Konnektor, wird empfohlen, die Jobnummer durch den Konnektor mit der Operation GetJobNumber generieren zu lassen. Erzeugt das Clientsystem die Jobnummer selbst, so muss das Primärsystem die Eindeutigkeit der Jobnummer, wie vom Konnektor verlangt, sicherstellen.

Das Einbetten von OCSP-Antworten wird vom Konnektor nur für die QES unterstützt (nicht jedoch bei PDF-Signaturen). Für die nonQES ist das Einbetten von OCSP-Antworten nicht möglich.

<PTV5+>
Ab der Konnektor Produkttypversion PTV 5.61.0 gibt es eine neue Version des SignatureService V7.5.6 mit zwei semantischen Änderungen:

• Es wird das Einbetten von OCSP-Antworten jetzt auch bei nonQES-Signaturen unterstützt.
• Es ändert sich der Konnektor-interne Ablauf bei der Erstellung von QES und nonQES-Signaturen: Einzubettende OCSP-Antworten werden jetzt nach der Erstellung der Signaturen eingeholt und eingebettet. Dies hat möglicherweise Einfluss auf das bisherige Handling von Stapelsignaturen durch die Primärsysteme.

Das Einbetten von OCSP-Antworten wird vom Konnektor sowohl für die QES als auch für die nonQES unterstützt (nicht jedoch bei PDF-Signaturen).

<\PTV5+>

Das Primärsystem muss für QES-Signaturen SIG:IncludeRevocationInfo so setzen, dass OCSP-basierte Sperrinformationen in die Signatur einbettet werden. Diese PS-Konfiguration sorgt dafür, dass der Sperrstatus zum Zeitpunkt der Erzeugung der Signatur standardmäßig eingebettet wird, ohne dass der Signierende darüber in jedem Einzelfall entscheiden muss. Als Konsequenz dieser Konfiguration ist bei der Überprüfung einer Signatur keine OCSP-Anfrage mehr erforderlich.

Das Primärsystem muss zu jedem Dokument, das qualifiziert signiert wird, in Form eines Kurztextes Metainformationen bereitstellen, der Benutzern einen Hinweis auf den Inhalt dieser Dokumente gibt. Bei dem Kurztext bzw. der Metainformation kann es sich beispielsweise um einen Dateinamen handeln, falls das zu signierende Dokument eine Datei ist. Die Kurztexte werden angezeigt, um dem Benutzer transparent zu machen, welches Dokument signiert wird. Dies ist insbesondere bei größeren Dokumentenstapeln vorteilhaft, bei denen die Gefahr besteht, dass Dokumente unbeabsichtigt mitsigniert werden. Der Kurztext wird der Schnittstelle SignDocument vom Primärsystem dem zu signierenden Dokument im Attribut ShortText übergeben. Zu beachten sind die Erläuterungen in Kapitel 4.4.1.

4.4.1.1 XML-Signatur

Die XML-Signatur wird per Default als XMLDsig/ XAdES-X (extended) Enveloped Signature umgesetzt, wenn SignDocument nicht anderslautend parametrisiert wird.

Eine normative und vollständige Beschreibung der Signaturschnittstelle erfolgt in [gemSpec_Kon#4.1.8.5] und den dort referenzierten Standards.

Im Element sp:GenerateUnderSignaturePolicy können Signaturpolicies ausgewählt werden, indem für jede Signaturrichtlinie ein definierter Bezeichner (URI) bei der Signatur als SigPolicyId im Feld SignaturePolicyIdentifier eingebettet wird.

Abbildung 27: Element GenerateUnderSignaturePolicy

Für die Fachanwendung NFDM wird der Identifier der Signaturepolicy in [gemRL_QES_NFDM#Kap. 3.1] festgelegt. Die Verfügbarkeit von Signaturrichtlinien richtet sich nach der Produkttypversion des Konnektors.

4.4.1.2 CMS-Signatur

Beim Erzeugen einer CMS-Signatur gemäß [RFC5652] wird als Default-Signaturverfahren eine Detached Signature erzeugt, wenn SignDocument nicht anderslautend parametrisiert wird.

4.4.1.3 S/MIME-Signatur

Das Erzeugen einer S/MIME-Signatur gemäß [RFC5751] erfolgt entsprechend den Vorgaben der CMS-Signatur.

4.4.1.4 PDF-Signatur

Die Signatur eines PDF erfordert keine zusätzlichen steuernden Parameter, sie wird ausschließlich gemäß [PAdES-2] in der Variante einer CMS-basierten Enveloped Signature (eingebetteten Signatur) umgesetzt (vgl. 4.4.1.2).

4.4.1.5 Nicht-qualifizierte elektronische Signatur

Das Primärsystem löst eine Signatur durch Übergabe der Kartensitzung, des Dokumentes bzw. des Dokumentenstapels, sowie einiger formatabhängiger Detailfestlegungen aus.

Abbildung 28: Subprozess nonQES-Signatur auslösen^{(Der abgebildete Ablauf setzt voraus, dass die zu signierenden Dokumente nicht angezeigt werden.)}

Tabelle 18: Tab_ILF_PS_Ablauf_Signaturerzeugung_nonQES-Signatur

4.4.1.6 Qualifizierte elektronische Signatur

Zur Auslösung der QES kann die SM-B mangels qualifiziertem Signaturzertifikat nicht verwendet werden. Binärdaten können nicht qualifiziert signiert werden. 

Das Context-Element muss dabei im Falle einer QES-Signatur eine userID enthalten, die einen eindeutigen Bezug auf den Nutzer enthält, der die Signatur auslöst.

Beispiel #: Beispiel qualifizierte CMS-Signatur auf einem Text-Dokument

Das PS kann Dokumente über den SignatureService des Konnektors qualifiziert signieren, unabhängig vom Szenario (Online-Szenario, Standalone-Szenario mit Online- und Offline-Konnektor). Wenn eine OCSP-Anfrage online durchgeführt werden kann, kann das Ergebnis in die Signatur eingebettet werden, so dass beim Verifizieren bekannt ist, dass das benutzte Zertifikat zum Zeitpunkt der Erstellung gültig war. Das Erstellen einer QES ist ansonsten auch ohne OCSP-Anfrage möglich.

Abbildung 29: Subprozess QES-Signatur auslösen

Tabelle 19: Tab_ILF_PS_Ablauf_Signaturerzeugung

Mit dem (optionalen) Einblenden eines Hinweises der Form "Bitte beachten Sie die Anzeige an Ihrem Kartenterminal“ kann das Primärsystem dafür sorgen, dass die Abfrage einer PIN-Eingabe am Kartenterminal vom Benutzer nicht übersehen wird.

4.4.1.7 Grundsätze zur Integration der Signaturfunktionen in die Arbeitsabläufe des Primärsystems

Da verschiedene Tätigkeiten im Behandlungsablauf eine Signatur oder qualifizierte Signatur erfordern, ist es Aufgabe des Primärsystems, die Signaturvorgänge so in den Arbeitsablauf einzubetten, dass Behandlung durch eine notwendige Autorisierung bzw. PIN-Eingabe sowie die Dauer des technischen Signaturvorgangs nicht gestört wird. Neben der Unterstützung der Komfortsignatur sind dazu folgende Grundsätze umzusetzen. Ergänzt werden diese Grundsätze durch anwendungsspezifische Implementierungsleitfäden:

4.4.2 <PTV4> Komfortsignatur

Die Komfortsignatur ermöglicht die Erstellung von bis zu 250 qualifizierten elektronischen Signaturen im Laufe eines Tages mit nur einer PIN-Freischaltung des HBA. Die PIN-Freischaltung erfolgt bei der täglichen Aktivierung der Komfortsignaturfunktion, anschließend können die Signaturen mit der Identifizierung durch das Primärsystem ohne erneute PIN-Eingabe erstellt werden. 

Folgende Voraussetzungen MÜSSEN erfüllt sein, um die Komfortsignaturfunktion nutzen zu können:

•      Der Administrator muss am Konnektor SAK_COMFORT_SIGNATURE = Enabled konfigurieren.

•      Zwischen Konnektor und PS MUSS eine TLS-Verbindung in der Stufe 3 (TLS mit Server-Authentisierung und Client-Authentisierung auf Ebene von http mit Username und Passwort) oder Stufe 4 (TLS mit Server-Authentisierung und Client Authentication) konfiguriert sein (s. Kap. 4.1.1).

•      Der HBA muss während der Dauer der Freischaltung durchgehend gesteckt bleiben. Nur dann bleibt der Sicherheitszustand der Karte erhalten. Das bedingt in der Regel, dass der HBA an einem zugriffsgeschützten Kartenterminal gesteckt ist, dass von allen Arbeitsplätzen als Remote-KT konfiguriert ist.

•      Der Leistungserbringer muss mindestens einmal pro Tag mit der Operation ActivateComfortSignature die Komfortsignatur aktivieren. Dafür muss er die PIN.QES seines HBA eingeben. Das Primärsystem generiert bei jeder Aktivierung der Komfortsignatur eine neue starke UserID gemäß A_19259-02 für den aktivierenden Nutzer.

•      Das Primärsystem muss vor dem Auslösen der Signatur im Rahmen der Komfortsignatur den Unterschreibenden zuverlässig identifizieren. Das Primärsystem gewährleistet die erfolgreiche Identifizierung indem es im Context des Signaturauftrags die gleiche starke UserID verwendet, wie bei der Aktivierung der Komfortsignatur, bei der die PIN.QES eingegeben wurde. Wie die Identifizierung erfolgt, liegt in der Entscheidung des Primärsystems. Alle Signaturaufrufe erfolgen mit der gleichen ClientSystemId im Context. 

Die Obergrenze für den Konnektor-Konfigurationsparameter SAK_COMFORT_SIGNATURE_MAX liegt bei 250 Dokumenten (Default-Einstellung: 100). Der Komfortsignaturzähler zählt jede einzelne erzeugte Signatur, d.h. alle Signaturen, die für alle Dokumentenstapel erzeugt wurden.

Das Zeitintervall, innerhalb dessen in einer Session signiert werden kann (1-24 h), ist ebenfalls über den Parameter SAK_COMFORT_SIGNATURE_TIMER änderbar (Default-Einstellung: 6h). 

Die Komfortsignatur bleibt solange aktiviert, bis entweder

•      DeactivateComfortSignature aufgerufen wird oder

•      SAK_COMFORT_SIGNATURE_MAX Dokumente signiert wurden oder

•      der SAK_COMFORT_SIGNATURE_TIMER abgelaufen ist oder

•      die HBA-Kartensitzung beendet wird oder

•      der HBA gezogen wird oder

•      der Sicherheitszustand des HBA zurückgesetzt wurde.

4.4.2.1 Gesamtablauf Komfortsignatur

Abbildung 30: Übersicht Faktoren der Komfortsignatur

Tabelle 20: Tab_ILF_PS_Übersicht_Ablauf_Komfortsignatur

4.4.2.2 Verwalten der Komfortsignaturfunktion

Primärsystem-Arbeitsplätze sollen so eingerichtet werden, dass berechtigte HBA-Nutzer an ihnen die Komfortsignatur nutzen können. Der HBA ist personengebunden. Wenn unterschiedliche Nutzer am selben Arbeitsplatz arbeiten wollen, muss das Primärsystem sicherstellen, dass nur die Person einen Signaturauftrag zu einer UserID erstellt, die die Komfortsignatur zu dieser UserID mit Eingabe der PIN.QES aktiviert hat. Es dürfen nicht unterschiedliche Nutzer auf denselben HBA zugreifen können. Unterschiedliche Nutzer dürfen somit nicht dieselbe Komfortsignatursession (für einen bestimmten Nutzer aktivierter Komfortsignaturmodus seines HBA) nutzen.

Szenario 1: Nutzung der Komfortsignatur mit mehreren Arbeitsplätzen

Der HBA wird in einem Kartenterminal gesteckt, dass von allen Arbeitsplätzen als RemoteKT zugreifbar ist. Dieses KT sollte gegen Zugriff Unbefugter geschützt sein. Der HBA wir von einem Arbeitsplatz mit ActivateComfortSignature unter Eingabe der PIN freigeschaltet. Bei Bedarf kann dieses über RemotePIN erfolgen, wenn der HBA nicht in dem lokalen Kartenterminal des Arbeitsplatzes steckt. Die dabei verwendete ClientSystemId und UserId muss bei allen Signaturaufträgen im Rahmen der Komfortsignatur verwendet werden. Da für das Auslösen eines Signaturauftrages keine PIN-Eingabe erforderlich ist, wird an den anderen Arbeitsplätzen kein Kartenterminal benötigt.

Im Resultat kann ein HBA-Inhaber in verschiedenen Behandlungszimmern die Komfortsignatur nutzen. Die zuverlässige Zuordnung über alle Arbeitsplätze zwischen Person, HBA und UserId liegt in der Verantwortung des Primärsystems. Arbeitsplätze können innerhalb von Thin-Client-fähigen Primärsystemen mit einem geeigneten Authentisierungsmerkmal durch den HBA-Inhaber aktiviert werden, sofern das Primärsystem die Option ”zusätzliches Authentisierungsmerkmal” nutzt.

Szenario 2: Nutzung der Komfortsignatur an nur einem Arbeitsplatz.

Das KT steht z.B. auf dem Schreibtisch des Arztes. Der Komfortsignaturmodus wird durch lokale PIN-Eingabe aktiviert. Es werden anschließend so lange Komfortsignaturen von diesem Arbeitsplatz ausgelöst, bis der HBA aus dem Kartenterminal gezogen, der Komfortsignaturmodus aktiv ausgeschaltet (das Primärsystem ruft die Operation DeactivateComfortSignature am Konnektor auf) wird oder der Nutzungszähler oder die Dauer für die Komfortsignatur abgelaufen sind.

Zur Steuerung der Benutzeroberfläche und der Arbeitsabläufe im Primärsystem bietet der Konnektor die Möglichkeit den Signaturmodus abzufragen:

Die Operation GetSignatureMode informiert, in welchem Modus der HBA freigeschaltet ist (PIN oder COMFORT), wie viele Signaturen noch im Komfortmodus möglich sind (CountRemaining)und wie lange der Komfortmodus noch aktiv ist (TimeRemaining). Mit diesen Informationen kann das Primärsystem den Anwender rechtzeitig zu einer erneuten Aktivierung der Komfortsignatur auffordern.

Das Primärsystem muss es dem Anwender ermöglichen, jederzeit die Freischaltung des HBA aufzuheben, auch wenn der HBA gesteckt bleibt. Die Funktion sollte leicht zugängig neben dem Status des Komfortsignaturmodus zu finden sein.

Das Primärsystem soll den Nutzer darüber informieren, dass der Aufruf von DeactivateComfortSignature wohlüberlegt erfolgen muss, insbesondere weil mit dem Aufruf alle zu einem HBA geöffneten Komfortsignatur-Sessions (auf allen Kommunikationskanälen zu diesem HBA und von allen Clientsystemen zu diesem HBA) geschlossen werden.

Da der Konnektor die UserID prüft, sobald der HBA einen erhöhten Sicherheitszustand hat, kann die Komfortsignatur nicht aktiviert werden, wenn die PIN.CH für eine Authentifizierungs- oder Entschlüsselungsfunktionen freigeschaltet ist. Aufrufe mit einer neuen UserID beantwortet der Konnektor mit Fehler 4018.

Das Primärsystem soll dem Anwender nach dem Aktivieren der Komfortsignatur anbieten, auch die PIN.CH freizuschalten, um Entschlüsselungen oder Authentifizierungen mit dem HBA zu ermöglichen.

In der folgenden Abbildung ist ein möglicher Ablauf der Komfortsignatur-Aktivierung dargestellt. Hier ist die PIN.CH bereits vor der Aktivierung freigeschaltet. Nach der Komfortsignatur-Aktivierung und der damit verbundenen Generierung einer neuen starken UserID muss die Freischaltung von PIN.CH für diese neue UserID erneut erfolgen.

Abbildung 31 Beispielhafter Ablauf der Komfortsignatur-Aktivierung

Hinweis: Wenn das Verhalten der Konnektoren von dem dargestellten Ablauf abweicht, insbesondere wenn nach dem EjectCard und RequestCard das ActivateComfortSignature immer noch nicht erfolgreich durchgeführt wird, muss das Primärsystem den Anwender auffordern, die Karte zu ziehen und neu zu stecken.

4.4.2.3 Auslösen der Komfortsignatur

Das Primärsystem ruft mit der Operation SignDocument wie in Kapitel 4.4.1 beschrieben gemäß [gemSpec_Kon#4.1.8.5.1] die Komfortsignatur auf, solange der Komfortsignaturmodus aktiv ist. Andernfalls löst der Signaturauftrag eine PIN-Freischaltung aus.

Der Aufruf kann von unterschiedlichen Arbeitsplätzen aus erfolgen, sofern der Aufruf von SignDocument im Context die gleiche ClientSystemId und UserId enthält wie der Aufruf von ActivateComfortSignature zu diesem HBA.

Für die Identifikation des Signierenden kann das Primärsystem eine erfolgte Authentifizierung des Nutzers am Primärsystem verwenden (Option ”Nachnutzung Primärsystem-Authentisierung”), oder das Primärsystem führt eine erneute Authentifizierung des Signierenden durch (Option ”zusätzliches Authentisierungsmerkmal”), etwa ein biometrisches Merkmal, ein Token oder eine spezielle PIN.

Das Primärsystem kann diese Optionen (Option a: ”Nachnutzung Primärsystem-Authentisierung”; Option b: ”zusätzliches Authentisierungsmerkmal”) wie folgt implementieren:

1.    Das Primärsystem stellt generell nur eine der beiden Optionen (a oder b) bereit.

2.    Das Primärsystem bietet beide Optionen an (a und b). HBA-Nutzer oder Primärsystem-Administrator wählen eine der Optionen (a oder b) dauerhaft im Zuge der Primärsystem-Konfiguration.

3.    Das Primärsystem bietet beide Optionen an (a und b). Der HBA-Nutzer entscheidet während der Einschaltung und Nutzung der Komfortsignatur darüber, welche Option verwendet wird (a oder b).  Falls das Primärsystem dem Leistungserbringer die Wahl zwischen einer der beiden Optionen gibt, muss die Entscheidung, die Abfrage des Authentisierungsmerkmals auszusetzen, mit einer Eingabe des Authentisierungsmerkmals am Primärsystem bestätigt werden.

Zu prüfen ist, ob die Grenzen für die Anzahl der Dokumente und die Zeit ausreichen, um den anstehenden Signaturauftrag auszuführen. Falls die Grenze für die Anzahl der Dokumente oder die Zeit mit dem anstehenden Signaturauftrag überschritten wird, soll das Primärsystem eine Warnmeldung an den Nutzer ausgeben. Der Nutzer kann dann den Signaturauftrag abbrechen.

Der HBA-Nutzer löst die Komfortsignatur als eine qualifizierte elektronische Signatur im Authentisierungsdialog in einer bewussten Handlung aus. Dadurch ist ausgeschlossen, dass die Signaturauslösung versehentlich geschieht.

Die Protokollierung soll es den Nutzern im Nachhinein ermöglichen, erstellte Signaturaufträge nachzuvollziehen und fachlich einzuordnen. Protokolleinträge sollen daher die Art der signierten Daten enthalten, z.B. E-Rezept, eAU, Arztbrief, Notfalldaten, Dispensierdaten. Darüber hinaus soll die Protokollierung Hinweise auf Inhalte der signierten Daten enthalten, z.B. verschriebene bzw. dispensierte Medikamente, jedoch ohne Personenbezug.

4.4.3 Verifizieren digitaler Signaturen

Das Primärsystem muss es dem Benutzer ermöglichen, VerifyDocument mit Stapeln von Dokumenten der Dokumententypen XML, PDF/A, Text, TIFF, MIME aufzurufen, die jeweils nicht größer sind als 25 MB.

Zusätzlich kann VerifyDocument aufgerufen werden, um Signaturen im Format PKCS#1 (V2.1) gemäß [RFC3447] zu prüfen.

Die Verifikation qualifizierter und nicht-qualifizierter Signaturen unterscheidet sich aus Sicht der Primärsysteme nicht.

Wenn über den Konnektor im Verifikationsprozess keine OCSP-Abfrage durchgeführt werden kann, wird dies im Ergebnis der Verifikation vermerkt.^{(Eine scheiternde OCSP-Anfrage, etwa bei Verwendung eines Offline-Konnektors, ist kein Fehlerfall.)}

Tabelle 21: Tab_ILF_PS_Ablauf_Verifizieren_digitaler_Signaturen

Das PS ruft die Verifikationsschnittstelle unter Angabe des signierten Dokumentes, des Dokumententyps, sowie einiger formatabhängiger Detailfestlegungen auf.

Das Feld SIG:IncludeRevocationInfo soll durch eine Konfigurationseinstellung im Primärsystem standardmäßig mit dem Wert true oder false belegt werden, so dass nicht der Nutzer in jedem Einzelfall über die Belegung des Wertes entscheiden muss. Da schon bei der Signaturerzeugung der Sperrstatus eingebettet wurde, und so die Gültigkeit zum Zeitpunkt der Erstellung bekannt sein sollte, kann eine erneute Überprüfung des Sperrstatus zum Zeitpunkt der Verifikation entfallen.

Bei der Signaturprüfung von PKCS#1 – Signaturen müssen abweichend von den oben genannten Parameterstrecken der anderen Dokumententypen folgende Werte clientseitig gefüllt werden:

Tabelle 22: Tab_ILF_PS_Parameter_VerifyDocument_im_Spezialfall_PKCS#1-Signatur

Über den Parameter ReturnVerificationReport kann ein ausführlicher Prüfbericht nach [OASIS-VR] angefordert werden (Rückgabeelement vr:VerificationReport). Dieser VerificationReport informiert über das Ergebnis jeder durchgeführten Signaturprüfung sowie Prüfdetails und Signatureigenschaften, wie das Ergebnis der Zertifikatsprüfung, den Prüfzeitpunkt, den Signaturzeitpunkt, signierten Kurztext und signierte Attribute.

4.4.4 Zertifikatsdienst

Der CertificateService des Konnektors bietet Operationen zum Abfragen von Kartenzertifikaten und ihrer Gültigkeit an.

<PTV4> Nach der Einführung von elliptischen Kurven auf TI-Signaturkarten der Generation G2.1 ist es möglich, bei ReadCardCertificate und CheckCertificateExpiration die Auswahl von ECC- und RSA-Zertifikaten zu steuern, und zwar durch eine Belegung des optionalen Parameters Crypt. Der Defaultwert ist "RSA".

Tabelle 23: Tab_ILF_PS_Steuerung_Zertifikatsauswahl

</PTV4>

4.4.4.1 Ablaufdatum von Zertifikaten prüfen

Der Anwender soll auf die Meldung differenziert reagieren können mit [OK, Später erinnern, Nie mehr erinnern] um sowohl die Erinnerungsfunktion als auch ein ungestörtes Arbeiten zu ermöglichen.

Eine Warnung kann auch mehr als drei Monate vor Ablauf erfolgen.

Die Prominenz der Warnung kann reduziert werden, wenn der Anwender bestätigt hat, dass er einen neuen Konnektor, eine neue SMC-B oder neue gSMC-KT bestellt hat.

Wenn das Primärsystem einen Benachrichtigungsmechanismus für professionellen IT-Support umgesetzt hat, kann die Anzeige durch eine Benachrichtigung des IT-Supports ersetzt werden. Hierfür ist z.B. eine konfigurierbare E-Mail-Benachrichtigung vorzusehen.

Der Operation CheckCertificateExpiration wird kein CardHandle übergeben. Für das Konnektorzertifikat wird der Eintrag selektiert, der keine CtID enthält. Für Einträge mit CardHandle muss die Kartenart ermittelt werden. Es gibt Firmwareversionen, bei denen die gSMC-KT-Information fehlt.

Beispiel #: Ablaufdatum der gSMC-K auslesen

Beispiel #: Response mit gSMC-K-Zertifikat

4.4.4.2 Kartenzertifikat lesen

Das Auslesen von Kartenzertifikaten ermöglicht Clientsystemen eine Reihe von Optionen, darunter das Auslesen des öffentlichen Verschlüsselungsschlüssels, um beim Aufruf von EncryptDocument das ENC-Zertifikat mitzuliefern.

Die Operation ReadCardCertificate liest folgende Zertifikate aus:

Die Operation ReadCardCertificate unterstützt das Lesen von Zertifikaten der eGK nicht. Als Resultat erhält das Primärsystem Zertifikatsinformationen, insbesondere Issuer-Name, Seriennummer und das ASN.1-codierte X509-Zertifikat.

Beispiel #: Beispiel Lesen des C.QES Zertifikates

4.4.4.3 Zertifikate verifizieren

Das Primärsystem muss es Nutzern ermöglichen, X.509-Zertifikate über die Konnektorschnittstelle VerifyCertificate zu verifizieren. Unterstützt werden X.509-Zertifikate von SM-B und HBAx.

Die vollständige und kanonische Darstellung der Schnittstelle zum Verifizieren von Zertifikaten findet sich in [gemSpec_Kon#4.1.9.5.3].

Als Resultat erhält das Primärsystem eines der drei möglichen Prüfungsergebnisse in CERT:VerificationResult: VALID, INCONCLUSIVE oder INVALID, sowie weitere Details zu den Zuständen INCONCLUSIVE und INVALID in GERROR:Error.

Der Konnektor verifiziert die X.509-Zertifikate u. a. auch gegen den Vertrauensraum der TSL und liefert als Ergebnis Statusinformationen und Identifier der in den Zertifikaten enthaltenen Rollen.

4.4.5 Verschlüsselung

Der EncryptionService des Konnektors stellt Operationen zur kartenbasierten Hybridverschlüsselung sowie zur Entschlüsselung hybrid verschlüsselter Daten bereit.

Die Dokumentenformate XML, PDF/A, TIFF, MIME Text oder Binär können vom EncryptionService verarbeitet werden. Der Konnektor bietet die hybride und symmetrische Ver- und Entschlüsselung nach dem Cryptographic Message Syntax (CMS) Standard an [RFC5652].

Hybride Verschlüsselung wird nur für X.509-Zertifikate angeboten.

Darüber hinaus werden folgende formaterhaltende Ver-/Entschlüsselungsmechanismen unterstützt:

Wenn XML-Dokumente ver- und entschlüsselt werden, können mit einer XPath-Angabe gezielt XML-Nodes angesteuert werden, die ver- bzw. entschlüsselt werden.

CMS wird gemäß [gemSpec_Kon#4.1.7] profiliert.

Zur Nutzung des Verschlüsselungsdienstes ist eine Kartensitzung mit der verwendeten Karte erforderlich. Der Konnektor unterstützt zur Verschlüsselung die Kartentypen HBAx und SM-B, nicht aber die eGK.

Tabelle 24: Tab_ILF_PS_KeyReference_im_EncryptionService

4.4.5.1 Verschlüsseln

Durch EncryptDocument wird ein Dokument hybrid für öffentliche Verschlüsselungsschlüssel verschlüsselt. Die Verschlüsselungsschnittstelle des Konnektors ist für die Nutzung von Schlüsselmaterial konzipiert, dass aus dem Vertrauensraum der TI stammt. Für die Nutzung der Verschlüsselungsfunktion des Konnektors, etwa für Szenarien, in denen Dokumente für Kommunikationspartner verschlüsselt werden, wäre es nützlich, wenn das Primärsystem einen Zertifikatsspeicher nutzt, der die öffentlichen Verschlüsselungsschlüssel zur Übergabe an den Konnektor enthalten kann. Daneben kann das Primärsystem, geeignete Zertifikate aus öffentlichen Verzeichnisdiensten entnehmen, falls solche zur Verfügung stehen.

Die vollständige Beschreibung der Verschlüsselungsschnittstelle ist in [gemSpec_Kon#4.1.7.5] zu finden.

Beispiel #: Beispiel Verschlüsseln eines Textes mit einem C.ENC Schlüssel

<PTV4> Nach der Einführung von elliptischen Kurven auf TI-Smartcards der Generation G2.1 ist es optional möglich, bei EncryptDocument die Verwendung von ECC- und RSA-Zertifikaten durch den optionalen Parameter Crypt zu steuern.

Tabelle 25: Tab_ILF_PS_Steuerung_Verschlüsselungsalgorithmus

[gemSpec_Konn#TAB_KON_747 KeyReference für Encrypt-/DecryptDocument] listet die ausgewählten Encrypt-Zertifikate je nach Kartentyp auf.

Das PS soll den Parameter Crypt nicht verwenden oder mit dem Wert "RSA" belegen, falls das hybrid verschlüsselte Dokument zur Entschlüsselung durch einen Konnektor vorgesehen ist, der noch nicht ECC verarbeiten kann ist, d.h. noch nicht PTV4 entspricht.

Falls unbekannt ist, ob der Konnektor, der beim Entschlüsseln eingesetzt wird, ECC unterstützt, soll beim Verschlüsseln der Parameter Crypt auf "RSA_ECC" gesetzt werden, so dass zwei Chiffrate entstehen (RSA-Chiffrat und ECC-Chiffrat).

</PTV4>

Die zum Verschlüsseln benutzten öffentlichen Schlüssel können aus dem Verzeichnisdienst stammen, s. Kapitel 4.5.3.2.

Abbildung 32: Ablauf Verschlüsseln

4.4.5.2 Entschlüsseln

Die Operation DecryptDocument entschlüsselt ein hybrid verschlüsseltes Dokument. Die Parameter der Entschlüsselung sind dementsprechend analog zu den Parametern der Verschlüsselung zu verwenden.

Beispiel #: Beispiel Entschlüsseln eines Textes mit einem C.ENC Schlüssel

Im Rahmen der Entschlüsselung wird auf privates Schlüsselmaterial zugegriffen. Die verwendeten Karten müssen sich daher in einem erhöhten Sicherheitszustand befinden, der ggf. erst durch eine PIN-Eingabe hergestellt werden muss. Da man sich insbesondere beim HBAx nicht darauf verlassen kann, dass dieser Zustand vorliegt, muss das Primärsystem den Kartenzustand abfragen und die Karte ggf. einmalig freischalten.

Mit dem (optionalen) Einblenden eines Hinweises der Form "Bitte beachten Sie die Anzeige an Ihrem Kartenterminal" muss das Primärsystem dafür sorgen, dass die Abfrage einer PIN-Eingabe am Kartenterminal vom Benutzer nicht übersehen wird.

Abbildung 33: Ablauf Entschlüsseln

4.4.6 Authentisierung

4.4.6.1 External Authenticate

Die Operation ExternalAuthenticate erzeugt Signaturen mit der Identität ID.HCI.AUT der SM-B bzw. der Identität ID.HP.AUT des HBAs. Der Verwendungszweck dieser Identitäten ist die Authentisierung, wie sie etwa im Rahmen des Schlüsseltauschs beim TLS-Verbindungsaufbau verwendet wird. Das Primärsystem muss bei der Nutzung von ExternalAuthenticate den Verwendungszweck des AUT-Zertifikates (Authentisierung) beachten.

Für die dauerhafte Signatur von Inhaltsdaten werden andere Identitäten verwendet: die Identität ID.HCI.OSIG der SM-B bzw. die Identität ID.HP.QES des HBAs. Diese Identitäten werden im Rahmen der Operation SignDocument genutzt.

Die Operation ExternalAuthenticate signiert einen Binärstring nonQES.

4.5 Hinweise zu KIM

Dank KIM (Kommunikation im Medizinwesen (zuvor "KOM-LE") können Nachrichten und Dokumente künftig schnell, zuverlässig und vor allem sicher per E-Mail ausgetauscht werden. Der Versand von sensiblen Daten wie Arztbriefe, Befunde oder Abrechnungen erfolgt über die Telematikinfrastruktur. Implementierungshinweise für PS-Hersteller finden sich unter: https://github.com/gematik/api-kim/ und ein Einstieg in KIM im Fachportal:
https://fachportal.gematik.de/spezifikationen/ueberblick-ti-anwendungen/kommunikation-im-medizinwesen-kim/.

5 Status und Logging

5.1 Erfolgreiche Verarbeitung VSDM

Eine vollständig erfolgreiche Verarbeitung umfasst immer das erfolgreiche Lesen der angeforderten Daten von der eGK sowie eine erfolgreiche Online-Prüfung, falls angefordert. Letzteres kann entweder bedeuten, dass keine Aktualisierungsaufträge für die eGK vorlagen (erfolgreiche Anfrage an Update Flag Service) oder ein oder mehrere Aufträge vorlagen und die Aktualisierung(en) erfolgreich war(en). Aus Sicht des PS sind 3 Szenarien erfolgreich (ohne Warnung, ohne Fehler):

• Lesen der VSD mit dem Parameter PerformeOnlineCheck=false. In diesem Fall erfolgt online lediglich eine Überprüfung des Zertifikats der eGK, welches erfolgreich war (Zertifikat nicht gesperrt). In diesem Fall ist davon auszugehen, dass aus dem laufenden Quartal bereits ein Nachweis über ein erfolgreiches Online-Update vorliegt.
• Lesen der VSD mit den Parametern PerformeOnlineCheck=true, ReadOnlineReceipt=true und Pruefungsnachweis.Ergebnis=1 (keine Online-Prüfung notwendig, Prüfziffer vom UFS ist Bestandteil des Prüfungsnachweises)
• Lesen der VSD mit den Parametern PerformeOnlineCheck=true, ReadOnlineReceipt=true und erfolgreicher Online-Prüfung und -Aktualisierung (Pruefungsnachweis.Ergebnis=2, Prüfziffer vom CCS ist Bestandteil des Prüfungsnachweises)

Grundsätzlich ist die Prüfziffer nur Bestandteil des Prüfungsnachweises, wenn das Elementergebnis den Wert 1 oder 2 enthält.

5.2 Statusinformationen

Änderungen des Verfügbarkeitsstatus und Fortschrittsanzeigen bei länger dauernden Aktivitäten sollen dem Benutzer derart angezeigt werden, dass sie den Arbeitsablauf nicht behindern.

Der Verfügbarkeitsstatus meint hier konkret den Status der VPN-Verbindung des Konnektors zur TI, die VPN-Verbindung des Konnektors zum SIS sowie ggf. Fehlerzustände des Konnektors. Das PS kann zur Abfrage die Operation GetResourceInformation des Systeminformationsdienstes (EventService.xsd) des Konnektors verwenden. Diese Operation liefert als Bestandteil von GetResourceInformationResponse das Element Connector (sieheEventService.xsd und ConnectorCommon.xsd). Das PS soll beim Start oder erstmaligem Verbindungsaufbau zum Konnektor mindestens den VPN-Status zur TI ermitteln und eine Meldung anzeigen, falls der Konnektor offline ist. Sofern im konkreten Anwendungsfall beim LE auch der Zugang zum SIS über den Konnektor verwendet wird, sollte auch diese Verbindung abgefragt und im Fehlerfall eine entsprechende Meldung angezeigt werden. Falls der SIS nicht verwendet wird, ist keine Statusabfrage diesbezüglich notwendig.

Das Primärsystem soll einmal täglich den fehlerbehafteten Zustand OPERATIONAL_STATE/EC_LOG_OVERFLOW des Konnektors abfragen und im Fall des Vorliegens des Fehlerzustands am Sicherheitsprotokoll dem Benutzer diesen Fehlerzustand anzeigen. In diesem Fehlerzustand werden ältere sicherheitskritische Einträge im Sicherheitsprotokoll des Konnektors durch neuere überschrieben. Die Anzeige soll als Warnung formuliert werden, in der die Handlungsempfehlung enthalten ist, den Konnektor-Administrator zu informieren, damit dieser das Sicherheitsprotokoll und die Konfiguration des Konnektors prüft. Es obliegt dem Primärsystem, weitere spezifische Fehlerzustände des Konnektors abzufragen und dem Benutzer anzuzeigen (wiederholbares Element Connector/OperatingState/ErrorState).

5.3 Meldungen/Logging

6 Fehlerbehandlung

6.1 Übersicht

Die Primärsystemschnittstellen des Konnektors bzw. des Fachmoduls VSDM antworten bei nicht erwartungsgemäßer Verarbeitung mit einer Warnung oder einer Fehlermeldung.

Fehlermeldungen treten bei Abbruch der Verarbeitung auf (keine VSD) und werden über einen SOAP-Fault an das Primärsystem gemeldet (6.2.1).

Warnungen sind als Meldungen im Prüfungsnachweis zu verstehen, dass ein Problem bei der Online-Prüfung oder -Aktualisierung aufgetreten ist. Letzteres konnte nicht erfolgreich durchgeführt werden, die VSD werden aber trotzdem von der Karte gelesen und zurückgeliefert. Normative Festlegungen zur Fehlerbehandlung sind in [gemSpec_OM] zu finden.

Falls dem Anwender die Ursache bzw. die Bezeichnung für den Ausnahmefall als ErrorText oder Code des Konnektors angezeigt wird, muss das letzte Traceelement des Konnektorfehlers zur Anzeige gebracht werden. Der ErrorText/Code aus dem letzten Traceelement von Konnektorfehlern ist die Meldung der letzten Verarbeitungsebene.

6.2 Empfehlungen zur Fehlerbehandlung

Das Primärsystem sollte eine fehlertolerante Verarbeitung aufweisen. Dazu gehört:

Idealerweise lassen sich das Verhalten bei Fehlern oder Warnungen über Konfigurationsparameter einstellen (Timeout für SOAP-Requests, Retries etc.)

Wenn am PS ein Timeout für SOAP-Requests vorgesehen ist, muss dieser Timeout mindestens doppelt so lang eingestellt sein wie der Timeout beim VSD-Update, der an der Managementkonsole des Konnektors eingestellt wurde. Wenn aufgrund dieses am Fachmodul VSD eingestellten Timeouts eine VSD-Aktualisierung abgebrochen wird, tritt kein Fehlerfall ein, sondern das PS erhält die Versichertenstammdaten der eGK sowie ein Prüfnachweis mit der entsprechenden Kennziffer. Die Festlegung eines maximalen Zeitraumes, nach dem der Versuch einer VSD-Aktualisierung abgebrochen wird, muss an der Managementoberfläche des Konnektors eingestellt werden, und darf nicht über eine Einstellung von Timeout-Parametern am Primärsystem im Widerspruch zu den genannten Einstellungen am Konnektor herbeigeführt werden.

6.2.1 Handlungsanweisungen zum Leistungsanspruchsnachweis

Leistungserbringer sollen an der Nutzeroberfläche des Primärsystems eine Handlungsanweisung erhalten, wenn aufgrund einer Warnung oder Fehlermeldung unklar ist, ob die eGK als Leistungsanspruchsnachweis verwendet werden kann.

Tabelle 26: Tab_ILF_PS_Handlungsanweisungen_bei_gültiger_Karte_mit_Warnungen

Tabelle 27 : Tab_ILF_PS_Handlungsanweisungen_bei_ungültigem_Leistungsnachweis

Tabelle 28 :Tab_ILF_PS_Handlungsanweisungen_bei_nicht_nachgewiesenem_Leistungsanspruch_aufgrund_technischer_Fehler

6.3 SOAP-Fault

Bei Abbruch der Verarbeitung antwortet die Operation ReadVSD mit einem Standard-SOAP-Fault, der neben den Standardelementen faultcode und faultstring auch das optionale Element detail mit der gematik-Fehlerstruktur enthält. Das standardmäßig optionale Element actor wird nicht verwendet.

Die Fehlerstruktur ist gemäß [gemSpec_OM#3.2.1] folgendermaßen definiert:

Abbildung 34: XML-Struktur der gematik Fehlermeldung [TelematikError.xsd], Version 2.0

Beschreibungen und normative Festlegungen zur Festlegung der Fehlerstruktur finden sich in [gemSpec_OM#3.2.1].

Beispiel #: ReadVSD_SOAP-Fault

6.3.1 Sonderfall „VSD inkonsistent“

Beispiel 21: ReadVSD_SOAP-Fault weist auf einen schweren Fehler beim Auslesen der Karte hin, der zum Abbruch der Operation ReadVSD geführt hat. In diesem Beispiel ist der Fehlercode 3001 ein Hinweis auf ein zuvor fehlgeschlagenes Update oder eine beschädigte Karte, wodurch die gespeicherten Daten inkonsistent geworden sind (Update nicht korrekt beendet). In diesem Fall ist eine Wiederholung der Operation inklusive eines Online-Updates notwendig, um den Fehler zu beseitigen, indem jetzt bei Vorliegen eines Aktualisierungsauftrags gültige Daten auf die eGK geschrieben und der Vorgang korrekt abgeschlossen werden kann. Im Online Szenario muss demnach die Operation ReadVSD mit PerformOnlineCheck=true aufgerufen werden, im Standalone-Szenario muss das Auto-Update am Online-Konnektor durchgeführt werden, bevor die Karte am Offline-Konnektor durch das PS korrekt eingelesen werden kann.

Tritt der Fehler wiederholt auf, ist die Karte als nicht nutzbar zu betrachten und muss ausgetauscht werden.

6.3.2 Sonderfall „HBA/SM-B nicht freigeschaltet“

Bestimmte Operationen erfordern einen erhöhten Sicherheitszustand eines HBA bzw. SM-B (SMC-B oder HSM). Ist dieser Zustand nicht gegeben, antwortet das Fachmodul bei entsprechenden Aufrufen mit den Fehlercodes 3041 oder 3042.

In diesem Fall soll das Primärsystem den Status der entsprechenden Karten prüfen und eine Freischaltung initiieren, sofern anzunehmen ist, dass der Benutzer die Freischaltung selbst vornehmen kann (siehe 4.1.5.4). In größeren Organisationen, z. B. Krankenhaus, ist anzunehmen, dass der Benutzer die Freischaltung nicht selbst vornimmt, sondern dies durch besonders berechtigtes Personal erfolgt, z. B. Administratoren. Daher ist in diesem Fall eine Warnmeldung sinnvoll mit dem Hinweis, sich an den Support zu wenden. Der Administrator muss in diesem Fall selbst die Freischaltung initiieren, die betroffene Karte identifizieren und die PIN am entsprechenden Terminal eingeben.

6.3.3 Sonderfall „Prüfungsnachweis nicht entschlüsselbar“

Das Element Pruefungsnachweis wird nur bei der Operation ReadVSD zurückgeliefert, wenn er angefordert worden ist und – im Falle des Standalone-Szenarios – durch das Fachmodul im Offline-Konnektor entschlüsselt werden konnte. Falls der Prüfungsnachweis noch nicht vorhanden ist (neue Karte) oder zuvor bei der Online-Prüfung eines anderen Leistungserbringers verschlüsselt worden ist, kann er nicht gelesen bzw. entschlüsselt werden. Daraufhin wird die Operation ReadVSD mit speziellen Fehlermeldungen abgebrochen (Codes 3039, 3040). Das PS soll den Benutzer in diesem Fall darauf hinweisen und zur erneuten Online-Prüfung auffordern. Nach durchgeführter Online-Prüfung ist ein lesbarer und entschlüsselbarer Prüfungsnachweise auf der eGK vorhanden. In darauffolgend wiederholter Operation ReadVSD durch das PS am Offline-Konnektor können VSD und Prüfungsnachweis gelesen werden.

6.4 Warnungen

Um Warnungen verarbeiten zu können, die Bestandteil des Prüfungsnachweises sind, muss dieser vom Primärsystem bei ReadVSD durch den Parameter ReadOnlineReceipt=true angefordert werden. Nach entsprechender Dekodierung (base64, gzip, siehe 4.3.5.3) kann der Prüfungsnachweis als XML-Struktur geparst werden.

Abbildung 35: Prüfungsnachweis

Beispiel #: Prüfungsnachweis mit ErrorCode

In obigem Beispiel weist das Element PN.E=3 darauf hin, dass die Aktualisierung der eGK aus technischen Gründen nicht möglich war, die VSD aber trotzdem von der eGK gelesen worden sind. Im Errorcode PN.EC ist eine genauere Fehlerschreibung in Form des Codes 12101 enthalten. („Für die angegebene Kombination aus ICCSN und Update-Identifier liegt kein Update vor.“) Daher enthält das Element PZ in diesem Fall keine kodierte Prüfziffer.

Beispiel #: Prüfungsnachweis ohne ErrorCode

In den Fällen, in denen die TI nicht erreichbar ist (offline) oder die Prüfung der Karte bereits vorher scheitert (Zertifikat der eGK ungültig oder dessen Online-Prüfung nicht möglich), enthält der Prüfungsnachweis im Ergebnis die Werte PN.E=[4-6].

6.5 Sonderfall „Maximale Offline-Zeit der TI überschritten“

Im besonderen Fall PN.E=6 ist die Aktualisierung nicht möglich und ein im Fachmodul konfigurierter Zeitraum wurde überschritten. Dieser Zustand (TI ist lange offline) soll dem Benutzer durch das Primärsystem deutlich hervorgehoben angezeigt werden. Der LE soll Maßnahmen ergreifen, um den Fehler zu analysieren und zu beseitigen, sofern die Ursache in der Verantwortung des LE liegt.

Die Festlegung der zu konfigurierenden maximalen Offline-Zeit (der Parameter TIME-OUT_TI_OFFLINE kann wie andere Konfigurationsparameter an der Administrationsoberfläche des Fachmoduls bzw. Konnektors konfiguriert werden) erfolgt durch die Vertragspartner. Im Auslieferungszustand des Konnektors ist der Zeitraum auf 0 eingestellt. Dadurch erfolgt keine Überprüfung auf Überschreiten eines maximalen Offline-Zeitraums und die Warnung mit PN.E=6 würde nicht auftreten.

Ziel des besonderen Umgangs mit dieser Fehlersituation ist die Vermeidung von Missbrauch durch z. B. nicht hergestellte Netzwerkverbindungen, wodurch die Online-Prüfung immer fehlschlagen würde, trotzdem aber ein Prüfungsnachweis erzeugt wird. Der Zeitraum sollte so gewählt werden, dass in diesem Intervall üblicherweise selbst über ein Wochenende ein Fehler behoben werden kann. Bevor diese Warnung auftritt, ist am PS des LE bereits für die entsprechende Zeit zuvor bei jeder Online-Prüfung eine Warnung angezeigt worden: Prüfungsnachweis gleich 3 ("Aktualisierung VSD auf eGK technisch nicht möglich") oder gleich 5 ("Online-Prüfung des Authentifizierungszertifikats technisch nicht möglich"). Sofern beim Auftreten dieser ersten Warnungen eine Fehlerbehebung in üblichen Reaktionszeiten erfolgt, tritt der Sonderfall der Warnung über die lange Offline-Zeit nicht auf.

Die Fehleranalyse bzw. -behebung seitens des LE sollte in zwei Schritten erfolgen:

• Visuelle Überprüfung der lokalen Komponenten (Primärsystem, Konnektor, Kartenterminal) auf grundsätzliche Funktionsfähigkeit sowie Prüfung von physischen Netzwerkverbindungen, ggf. Neustart einzelner Komponenten und Wiederherstellung von fehlerhaften Netzwerkverbindungen
• Bei Fortbestehen des Fehlers ist der für den Support zuständige Serviceprovider zu informieren, damit dieser den Fehler analysiert und abstellt.

6.6 Fehlercodes

Fehlercodes sind in Kombination mit auslösender Komponente auszuwerten. Eine Liste der mögliche Bezeichner für Komponenten der TI befindet sich in [gemSpec_OM].

Die nachfolgenden Tabellen der Fehlercodes sollen als Auszug einen Überblick über mögliche Fehlersituationen vermitteln. Da deren Definition nicht in diesem Dokument erfolgt, müssen jeweils die gültigen Werte aus den entsprechenden Dokumenten verwendet werden. Die Fehlertexte in den Tabellen enthalten Kurzbeschreibungen der Fehler und sind keine Vorgaben für Fehlermeldungen des Primärsystems. Hier soll der Hersteller darauf achten, für die Zielgruppe verständliche Formulierungen zu verwenden.

Um in Supportanfragen zu vom Konnektor gemeldeten Fehlern die Fehler eindeutig identifizieren zu können, ist es notwendig, dass die Primärsysteme neben der Beschreibung der Fehler immer den Fehlercode angeben.

Bei herstellerspezifischen Fehlercodes aus den Fehlercode-Nummerbereichen 10000 bis 40999, bei denen der Fehlertext des Konnektorherstellers dem PS-Hersteller zum Entwicklungszeitpunkt unbekannt ist, sollte der Fehlertext des Konnektorherstellers unverändert übernommen werden. (Hinweis über Ausnahmen zu diesem Fehlercode-Nummerbereich: In Kapitel 6.2.1 aufgeführte Fehlercodes aus dem Nummernkreis 12000 bis 12999 sind nicht herstellerspezifisch, sondern stammen von Fachdiensten.)  

Einige Fehlercodes sind übergreifend und werden von verschiedenen Komponenten gleichartig verwendet, daher sind Komponenten nicht angegeben.

Tabelle 29: Tab_ILF_Generische_Fehlercodes_[gemSpec_OM]

Folgende Beispiele von Fehlercodes werden vom Konnektor erzeugt.

In der Tabelle Tab_ILF_PS_Basis-Fehlercodes_des_Konnektors sind die verursachenden Komponenten nicht explizit für jeden Fehlercode angegeben, da es sich immer um die Komponente „Konnektor“ handelt.

Tabelle 30: Tab_ILF_PS_Basis-Fehlercodes_des_Konnektors

Folgende Fehler können im Kontext von PIN-Operationen auftreten: 

Tabelle 31: Tab_ILF_PS_Fehlercodes_PIN-Handling

Folgende VSDM-spezifische Fehler werden durch das Fachmodul oder die Fachdienste erzeugt. Die verursachenden Komponenten sind dazu explizit aufgeführt.

Tabelle 32: Tab_ILF_PS_Fehlercodes_VSDM

7 Komfortfunktionen

Dieser Abschnitt beschreibt informativ einige optionale Komfortfunktionen, die das Primärsystem anbieten kann. Diese sind nicht als Anforderungen formuliert, sondern sind Empfehlungen, die Leistungsmerkmale der verschiedenen Systeme sein können.

7.1 Hintergrundverarbeitung bei Online-Prüfung

Das Primärsystem sollte die Online-Prüfung und -Aktualisierung so durchführen, dass die Weiterarbeit des Benutzers am Primärsystem nicht blockiert wird. Sofern der Patient bereits bekannt ist und für das laufende Quartal noch kein Prüfungsnachweis vorliegt, kann die Online-Prüfung im Hintergrund angestoßen und die betreffende Akte parallel geöffnet werden. In der überwiegenden Anzahl der Fälle wird nur der Prüfungsnachweis in das Primärsystem übernommen, was durch eine Statusmeldung signalisiert werden kann. Dadurch werden Wartezeiten für den Benutzer beim Stecken der eGK vermieden. Lediglich bei geänderten Stammdaten des Patienten, z. B. Adressänderungen, muss das PS eine Benutzerinteraktion initiieren, indem die Änderungen visualisiert und übernommen werden können.

7.2 Konfigurierbare Anzeige bei Prüfungsnachweis 3

Die Anzeige für den Prüfungsnachweis 3 am Primärsystem soll konfigurierbar werden, um den Ablauf in den Krankenhäusern besser als bisher zu unterstützen. 3 Einstellungen sollen möglich sein:

1. Beim Prüfungsnachweis 3 poppt ein Fenster auf, das entsprechend informiert. Das Fester muß aktiv durch den Nutzer weggeklickt werden.
2. Ein Informationsfenster poppt auf und verschwindet nach einer Zeit (z.B. 3 Sekunden) von selbst. Der Nutzer kann die Information aufnehmen oder ignorieren und muß keine Interaktion durchführen. 
3. Es poppt im Fall vom Prüfungsnachweis 3 kein Fenster auf.

Die Varianten 2 und 3 verlangen keine Interaktion des Nutzers und behindern den Ablauf in den Krankenhäusern nicht.

7.3 Auswertung von Karteninformationen (HBA/SM-B)

Beim Zugriff auf die vom Konnektor verwalteten Karten des Leistungserbringers (HBA, SM-B) kann das Primärsystem Ablaufinformationen der Kartenzertifikate prüfen und bei unterschreiten einer festen oder konfigurierbaren Frist (z.B. 3 oder 6 Monate) eine Warnung ausgeben. Dies kann nach verschiedenen Regeln geschehen (erstmalige Nutzung einer Karte pro Tag/Woche/Monat) und sollte den Benutzer nicht mit Warnungen überfrachten.

Diese Funktion kann ein wichtiges Komfortmerkmal sein, um den Leistungserbringer rechtzeitig vor Ablauf eines Kartenzertifikats zu warnen und Funktionseinschränkungen damit zu verhindern. Hintergrund ist, dass der HBA möglicherweise nicht in täglicher Routine angewendet wird (z.B. wenn der LE die Signaturfunktion nicht anwendet) und nur die SM-B zum Einsatz kommt, um den Zugriff auf die GVD der eGK freizuschalten. Die SM-B steckt aber außerhalb des Sichtbereichs in einer geschützten Umgebung in einem speziellen KT.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Beispiele

8.6 Referenzierte Dokumente

8.6.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 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.

8.6.2 Weitere Dokumente