Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme – Telematikinfrastruktur (TI)

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

    

     

      
Version
      
2.23.0
     
     

      
Revision
      
962715
     
     

      
Stand
      
05.07.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 und ist durch ein Passwort geschütz.

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

Während des Import-Vorgangs soll das importierte Zertifikat keiner CA-Prüfung unterzogen werden, da es selbstsigniert oder nur über eine PKI des Konnektor-Herstellers prüfbar ist.

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.6.3 Schlüsselqualität der Clientzertifikate

Der Konnektor überwacht, ob die Qualität der Clientzertifikate den Mindestanforderungen entspricht und setzt diese bei der Erzeugung oder dem Import von Clientzertifikaten durch. Wenn durch Updates oder die Übernahme bestehender Konfigurationen Zertifikate mit RSA-2048-Schlüsseln konfiguriert sind, so wird dieses durch den Betriebszustand EC_TLS_Client_Certificate_Security (Sec; Info) angezeigt und kann über das Event OPERATIONAL_STATE/EC_TLS_Client_Certificate_Security dem Clientsystem gemeldet werden. Um den Betriebszustand zu beseitigen, müssen neue Clientzertifikate entsprechend TAB_KON_866 konfiguriert werden.

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.

Werden an der Schnittstelle zwischen Kartenterminal und Konnektor Identifier für Kartenslots verwendet, dann lässt sich an der vom Konnektor gemeldeten SlotId erkennen, ob eine Karte kontaktbehaftet oder kontaktlos angesteuert wird.

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.1.6 Information zu ungültigen Karten

Aktuelle Konnektorversionen führen nach dem Stecken eines HBA oder einer SMC-B eine Zertifikatsprüfung durch und senden im Fehlerfall das Event CERT/CARD/STATUS an Clientsysteme mit passender Subscription. Dadurch kann der Anwender sofort informiert werden, wenn eine gesteckte Karte noch nicht vollständig in Betrieb genommen wurde (CERTSTATUS=unknown) oder widerrufen wurde (CERTSTATUS=revoked).

Da Karten der Generation 2.0 nicht die ab 01.01.2026 vorgeschriebenen Schlüssel enthalten, prüft der Konnektor nach dem Stecken eines HBA oder einer SMC-B die Kartengeneration und erzeugt für jede G2.0-Karte einen Betriebszustand EC_G2_HBA_USED($pseudonym) bzw. EC_G2_SMCB_USED($pseudonym) mit dem Parameter Ablaufdatum.

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.