gemSpec_FM-AdV_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Fachmodul AdV

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
02.08.17
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSpec_FM-AdV
     
    

Dokumentinformationen

Änderungen zur Vorversion

Überarbeitung zum Online-Rollout (Stufe 2.1).

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das Fachmodul AdV als Teil des Konnektors in der Leistungserbringerumgebung ist Bestandteil der dezentralen TI. Es bietet einem berechtigten Clientsystem („LE-AdV-Terminal“) die technischen Schnittstellen, um einem Versicherten die Wahrnehmung seines Rechts auf Datenhoheit zu ermöglichen. Für die Umsetzung fachanwendungs-spezifischer Anwendungsfälle nutzt das Fachmodul AdV die Funktionalität weiterer Fachmodule.

Die vorliegende Spezifikation definiert die externen Schnittstellen, die das Fachmodul AdV berechtigten Clientsystemen anbietet. Es werden grundsätzlich zwei Arten der Umsetzung von Anwendungsfällen durch das Fachmodul AdV unterschieden. Anwendungsfälle, die ausschließlich durch das Fachmodul AdV abgearbeitet werden, und Anwendungsfälle, die das Fachmodul AdV an andere Fachmodule (z. B. NFDM, VSDM, AMTS) weiterleitet.

Die Anforderungen, die durch das Fachmodul AdV umgesetzt werden, sind im Anforderungskatalog AdV [gemAnforderungen_AdV] motiviert und in der Systemlösung AdV [gemSysL_AdV] festgelegt.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller des Produkttyps „Fachmodul AdV“ sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematik-Infrastruktur des deutschen Gesundheitswesens für den Online-Rollout Stufe 2.1 (ORS2.1) Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

In diesem Dokument werden die Schnittstellen spezifiziert, die das Fachmodul AdV den berechtigten Clientsystemen anbietet. Schnittstellen anderer Fachmodule und von Diensten des Basiskonnektors, die vom Fachmodul AdV genutzt werden, sind in den referenzierten Fachmodulspezifikationen und der Spezifikation des Konnektors beschrieben, die diese Funktionalitäten bereitstellen. Sie sind im Anhang gelistet (siehe Anhang A5).

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

Diese Spezifikation beschreibt ausschließlich die Schnittstellen und Abläufe, die für das Fachmodul AdV in einem Konnektor in der AdV-Leistungserbringer-Umgebung gelten. Sie macht keine Aussagen über die AdV-Funktionalität in einer AdV-Umgebung im Auftrag der Kostenträger oder einer @home-Umgebung.

Aufgrund der Erklärung in [gemSysL_AdV#1.5.2] werden in der aktuellen Spezifikationsphase die Operationen, die für die folgenden Anwendungsfälle benötigt werden, nicht durch die LE-AdV-Umgebung umgesetzt:

• 3.6.4: AdV-UC_30, AdV-UC_31, AdV-UC_32 (Einwilligungen und Verweise lesen/schreiben/löschen in DF.HCA)
• 3.6.3 Übergreifende Funktionen: AdV-UC_24, AdV-UC_25, AdV-UC_26, AdV-UC_27 (Zertifikat von eGK lesen, mit eGK verschlüsseln/entschlüsseln/signieren)

Die auf der eGK vorhandenen Anwendungen GDD und OSE werden aktuell nicht durch das Fachmodul AdV unterstützt.

In der aktuellen Ausbaustufe ist der Leistungsumfang des Fachmoduls AdV statisch festgelegt. Die Operation list_Applications übermittelt als Aufzählung die angebotenen Schnittstellenfunktionen. Da diese statisch ist und keine vom Auslieferungszustand abweichende Information für das LE-AdV-Terminal liefert, ist die Umsetzung der Operation nicht erforderlich.

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 Textmarken angeführten Inhalte.

1.5.1 Hinweis auf offene Punkte

Die Response auf die Operation GetUpdates (siehe Kapitel 6.2.3.2) ist noch nicht festgelegt. Es soll dem LE-AdV-Terminal ermöglicht werden, seine Firmware-Updates über das Fachmodul AdV und den Basiskonnektor vom KSR zu beziehen.

2 Systemüberblick

Unter dem Begriff Anwendungen des Versicherten (AdV) werden Anwendungsfälle zusammengefasst, die der Versicherte als Akteur initiiert und die zusätzlich eine oder mehrere der folgenden Eigenschaften haben:

• Der Versicherte führt diesen Anwendungsfall eigenständig aus, um sein Auskunftsrecht für die auf seiner Gesundheitskarte oder in der Telematikinfrastruktur über ihn gespeicherten Daten wahrzunehmen.
• Der Anwendungsfall darf aus fachlichen oder rechtlichen Gründen nur durch den Versicherten allein durchgeführt werden, beispielsweise aufgrund der Vertraulichkeit der anzuzeigenden oder zu bearbeitenden Daten.
• Der Versicherte führt diesen Anwendungsfall aus, um die Nutzung seiner Fachanwendungen zu verwalten.
• Der Versicherte führt diesen Anwendungsfall aus, um Fachdaten seiner Fachanwendungen zu verwalten.

Diese Anwendungen werden dem Versicherten mit dem Fachmodul AdV und dem LE-AdV-Terminal zur Verfügung gestellt. Das Fachmodul AdV ist Bestandteil des Konnektors, das LE-AdV-Terminal ist ein eigener Produkttyp, der in einem separaten Dokument spezifiziert ist.

Im Einzelnen ermöglicht das Fachmodul AdV zusammen mit dem LE-AdV-Terminal dem Versicherten

• persönliche und medizinische Daten anzuzeigen, die mittels der eGK gespeichert sind,
• das Zugriffsprotokoll der Karte anzuzeigen,
• Einwilligungen in freiwillige Anwendungen einzusehen, Daten zu Einwilligungen zu löschen,
• Daten von freiwilligen Anwendungen auf der eGK zu löschen,
• freiwillige Anwendungen auf der eGK zu verbergen und sichtbar zu machen
• die PINs auf seiner eGK zu verwalten (ändern, entsperren, einschalten, ausschalten)

Das Fachmodul AdV darf ausschließlich durch dafür berechtigte Clientsysteme, die LE-AdV-Terminals, genutzt werden. Ein LE-AdV-Terminal darf in den Räumen von Leistungserbringer-Institutionen (Arzt- oder Zahnarztpraxis, Apotheke, Krankenhaus, Psychotherapeuten) aufgestellt werden. Bei der Einbindung eines LE-AdV-Terminals in das LAN der Leistungserbringer-Institution muss der Administrator die Beziehungen zwischen Mandant, Clientsystem, Arbeitsplatz und Kartenterminal so konfigurieren, dass kein Zugriff von der LE-Umgebung auf die eGK des Versicherten am LE-AdV-Terminal möglich ist. Bei der Einbindung des LE-AdV-Terminals muss der Administrator ebenso sicherstellen, dass kein Zugriff vom LE-AdV-Terminal auf das Clientsystem und den Arbeitsplatz des Leistungserbringers möglich ist. Ein Mandant ist allgemein eine Nutzergruppe, die auf einen Server zugreifen kann, ohne die Daten einer anderen Nutzergruppe sehen oder bearbeiten zu können. Im vorliegenden Kontext ist ein Mandant ein abstrakter Karteninhaber einer SM-B, die dem Versicherten auf der eGK Zugriffsrechte in der Leistungserbringerumgebung freischaltet („SM-B für LE-AdV“, frühere Bezeichnung: SM-B Profil 10).

Das Fachmodul AdV unterstützt eGKs der Generationen G2 und höher.

3 Systemkontext

3.1 Akteure und Rollen

Der einzige Akteur, der direkt mit dem Fachmodul AdV kommuniziert, ist eine technische Komponente, das LE-AdV-Terminal. Das Fachmodul AdV ist integraler Bestandteil des Konnektors und gehört damit auch zur TI. Als zugriffsgesichertes Fachmodul stellt es Anforderungen an Clientsysteme, die darauf zugreifen wollen (siehe [gemSpec_Kon#3.4]). Um Zugriff auf das Fachmodul AdV zu erhalten, muss das LE-AdV-Terminal die Anforderungen an berechtigte Clientsysteme erfüllen (vgl. Kap. 5.2).

Der fachliche Akteur „Versicherter“ ruft am LE-AdV-Terminal die fachlichen Operationen des Fachmoduls AdV auf, um auf seine eGK zuzugreifen. Zusätzlich benötigt er dafür die Authentisierung durch die fachliche Rolle „AdV in der Leistungserbringer-Umgebung“ (LE-AdV). Diese Rolle wird technisch durch das Zugriffsprofil der beteiligten SM-B repräsentiert.

Der fachliche Akteur „AdV-Administrator“ ruft am LE-AdV-Terminal die administrativen Operationen des Fachmoduls AdV auf, die über die Schnittstelle AdVManagement angeboten werden. Damit kann er feststellen, ob das Fachmodul betriebsbereit ist und ggf. die PIN der SM-B am Kartenterminal des LE-AdV-Terminals eingeben. Ferner kann er das Update des LE-AdV-Terminals anstoßen.

Die Konfiguration des AdV-Terminals als berechtigtes Clientsystem ist am Konnektor einzutragen und ist Aufgabe des für den Konnektor zuständigen Administrators. Die Administratoren von AdV und Konnektor sind nicht notwendig identisch.

3.2 Nachbarsysteme

Als berechtigtes Clientsystem außerhalb des Konnektors greift ein LE-AdV-Terminal auf das Fachmodul AdV zu. Das Fachmodul AdV stellt dazu die SOAP-Schnittstelle AdVService für die Anwendungen des Versicherten und die SOAP-Schnittstelle AdVManagement für die administrativen Aufrufe des Fachmoduls bereit.

Abbildung 1: PIC_FM_AdV_001 Systemkontext

Innerhalb des Konnektors nutzt das Fachmodul AdV die Dienste diverser anderer Fachmodule sowie Dienste des Basiskonnektors. Die dafür genutzten Interfaces und Fachmodule sind in

• A5.1 – Dokumente der gematik und
• A6 – Verwendete Operationen und Interfaces

gelistet.

Falls Zugriffe auf zentrale Dienste der Telematikinfrastruktur nötig sind, bspw. zur Onlineprüfung und -aktualisierung der Versichertenstammdaten, so erfolgen sie ausschließlich über die aufgerufenen Fachmodule oder den Basiskonnektor.

4 Zerlegung des Produkttyps

Eine weitere Untergliederung der Aufbaustruktur des Fachmoduls AdV ist nicht erforderlich.

5 Übergreifende Festlegungen

5.1 Transportsicherung

Die Kommunikation zwischen einem LE-AdV-Terminal und dem Konnektor muss mittels TLS unter Verwendung des Verfahrens zur gegenseitigen Authentisierung gesichert sein. Diese Forderung wird durch die Basisfunktionalität des Konnektors durchgesetzt, die die Anforderungen für berechtigte Clientsysteme und zugriffsgesicherte Fachmodule definiert.

5.2 Beschränkter Zugriff auf das Fachmodul AdV

Das Fachmodul AdV ist ein zugriffsgesichertes Fachmodul. Nur LE-AdV-Terminals als berechtigte Clientsysteme dürfen auf seine Interfaces AdVService und AdVManagement zugreifen. Damit ist sichergestellt, dass Clientsysteme des Leistungserbringers keinen Zugriff auf die allein dem Versicherten vorbehaltenen Anwendungsfälle erhalten, z. B. die Einsichtnahme in das Zugriffsprotokoll EF.Logging. Die Zugriffsbeschränkungen für dieses Fachmodul werden vom Konnektor durchgesetzt. Sie sind in [gemSpec_Kon „Fachliche Anbindung der Clientsysteme“] beschrieben.

Das Informationsmodell des Konnektors bietet gemäß TIP1-A_6027 dem Administrator des Konnektors die Möglichkeit, Clientsysteme mit zugriffsgesicherten Fachmodulen zu assoziieren und sie damit zu berechtigten Clientsystemen zu deklarieren. Als ServiceName für die zugriffsgesicherten Interfaces des Fachmoduls AdV werden „AdVService“ und „AdVManagement“ festgelegt.

Alle Aktionen, die für die Ausführung durch den Versicherten in der AdV-Umgebung beim Leistungserbringer vorgesehen sind, sind entweder durch die PIN-Eingabe des Versicherten oder durch eine Card-to-Card-Authentisierung mit einer „SM-B für LE-AdV“ geschützt. Dementsprechend muss der Mandant für diese Aufrufe über eine „SM-B für LE-AdV“ verfügen. Bestimmte Anwendungsfälle darf der Versicherte aus fachlichen und rechtlichen Gründen nur alleine durchführen. Daher muss durch die Konfiguration des Konnektors gesichert sein, dass auf eine eGK, die der Versicherte in der LE-AdV-Umgebung liest oder bearbeitet, kein Mandant mit anderen Rechten als den durch die „SM-B für LE-AdV“ gewährten zugreifen kann.

Die Variante „SM-B für LE-AdV“ des Kartentyps SM-B lässt sich anhand des spezifischen Object-Identifiers (OID) im X.509-AUT-Zertifikat ermitteln (im Element extensions.Admission.professionOID des Zertifikats C.HCI.AUT).

Ein authentisierter AdV-Administrator darf die Schnittstelle AdVManagement am LE-AdV-Terminal nutzen, um die Betriebsbereitschaft des Fachmoduls zu ermitteln und gegebenenfalls herzustellen und um Firmware-Updates des LE-AdV-Terminals zu initiieren.

5.3 Clientschnittstelle

Das Fachmodul AdV bietet seine Schnittstellen als SOAP-Schnittstellen an. Für die Beschreibung der SOAP-Schnittstellen zum Clientsystem wird in dieser Spezifikation WSDL Version 1.1 [WSDL1.1] eingesetzt. Die Interoperabilität zwischen verschiedenen SOAP-Implementierungen wird durch die Vorgaben des WS-I Basic Profile V1.2 [BasicProfile1.2] erreicht.

Da das Fachmodul ADV die Kodierung UTF-16 nicht unterstützt, muss das Clientsystem alle Requests 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.

Sofern weitergehende Festlegungen erforderlich sind, werden diese durch die gematik erfolgen.

Für die Fehlerbehandlung gelten die Festlegungen von [gemSpec_Kon].

5.4 Kommandobearbeitung

Zum Lesen oder Bearbeiten der Anwendungsdaten delegiert das Fachmodul AdV die Verarbeitung seiner Aufrufe an die spezifischen Fachmodule, wenn diese die entsprechende Funktionalität anbieten. Die für die Weiterleitung notwendigen Vorbereitungsschritte sind für alle diese Aufrufe einheitlich; sie sind im Standard-Ablauf in Kapitel 6.3.5 beschrieben. Für manche Fachmodul-Operationen sind jeweils spezifische Parameter zu ergänzen; sie sind anhand der Aufrufparameter der AdV-Schnittstelle zu bestimmen. Die Mapping-Tabellen im Kapitel 6.2 zeigen, wie die Aufrufparameter der AdV-Schnittstellenoperationen auf die Parameter der Fachmodul-Schnittstellen abzubilden sind (siehe jeweils die Tabelle „Mapping der Parameter für Operation…“). Konstante Parameterwerte werden nicht beim Aufruf durch das LE-AdV-Terminal übermittelt, sondern vom Fachmodul AdV gemäß der Spezifikation eingefügt.

Die Referenz auf die SM-B – die als CardHandle oder als CardSession gefordert sein kann – wird nicht durch das LE-AdV-Terminal übergeben, sondern durch das Fachmodul AdV ergänzt.

Eine mögliche Vorgehensweise, wie das Fachmodul AdV die SM-B ermitteln und die Anforderung „AdV-A_2183 Auswahl SM-B“ erfüllen kann, ist in Kapitel 6.3.3 beschrieben.

Die Beschreibungen in den Mapping-Tabellen orientieren sich an den Namen und Parametern der SOAP-Schnittstellen der aufgerufenen Fachmodule. Das hat zur Folge, dass laut Mapping-Tabelle beispielsweise ein CardHandle übergeben werden muss, obwohl AdV bereits die CardSession ermittelt hat. Da es sich hierbei um Aufrufe innerhalb des Konnektors handelt, ist es dem Hersteller überlassen, ob er dies so übernimmt oder ob er die Schnittstellen zwischen dem Fachmodul AdV und den spezifischen Fachmodulen in anderer Form technisch realisiert.

Zur Adressierung der Fachanwendungen, auf die sich die AdV-Aufrufe beziehen, sind die Identifier zu verwenden, die in Tabelle 63: TAB_FM_AdV_062 Identifier der Anwendungen gelistet sind. Sie entsprechen denen aus der Systemlösung [gemSysL_AdV#AnhangC]. Die Responses der Fachmodule werden unverändert an das aufrufende LE-AdV-Terminal weitergereicht.

5.5 Protokollierung

5.5.1 Protokollierung im Fachmodul

Zur Protokollierung nutzt das Fachmodul den Protokollierungsdienst des Konnektors (s. [gemSpec_Kon]). Ereignisse vom Typ Sec (Security) werden unter Hinzufügung des Fachmodulnamens „AdV“ in das Sicherheitsprotokoll des Konnektors geschrieben. Fehler-, Ablauf- und Debug-Meldungen und -Ereignisse werden in das fachmodulspezifische Protokoll geschrieben. Dabei gelten folgende spezifische Anforderungen.

Der Protokollierungsdienst des Konnektors stellt jedem Fachmodul ein Fachmodulprotokoll und ein Fachmodul-Performanceprotokoll zur Verfügung. Das per Konfiguration ein- bzw. abschaltbare Performance-Logging ist in [gemSpec_Perf#GS-A_5130] spezifiziert.

Die Konfigurationsmöglichkeiten für diese Protokolldateien sind in [gemSpec_Kon] in TIP1-A_4717 spezifiziert.

Ziel ist es, Administratoren, Betreibern und Testern einen Einblick in den internen Ablauf zu ermöglichen und die Analyse von Fehlersituationen zu erleichtern.

Zum Schreiben der Protokolleinträge stellt der Protokollierungsdienst des Konnektors den Fachmodulen den TUC_KON_271 „Schreibe Protokolleintrag“ zur Verfügung ([gemSpec_Kon]).

5.5.2 Zugriffsprotokolleinträge auf der eGK

Die Protokolleinträge auf der eGK dokumentieren für Zwecke der Datenschutzkontrolle, welche Leistungserbringer bzw. welche Leistungserbringerinstitutionen auf die Daten des Versicherten zugegriffen haben. Dazu stellt der Konnektor den Fachmodulen den TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ zur Verfügung, der zu diesem Zweck einen Eintrag in die Datei EF.Logging auf der eGK schreibt.

Um unnötige PIN-Eingaben für eine eGK der Generation 2.0 zu vermeiden, gibt es den folgenden Sonderfall: Für eine eGK G2.0 wird pro eGK-Sitzung, welche mit dem Stecken der eGK durch den Versicherten beginnt und spätestens mit dem Ziehen der eGK beendet wird, genau ein Protokolleintrag durch AdV vorgenommen, um die Tatsache des Zugriffs des Versicherten auf seine eigenen Daten festzuhalten.

Für alle höheren Versionen der eGK wird dieser Logeintrag nicht benötigt, da das Logging innerhalb der ausgeführten Anwendungsfälle erfolgt.

In Tabelle 1: TAB_FM_AdV_073 DataType und AccessType in der AdV-Umgebung sind die Werte für DataType und AccessType aufgelistet, die von Anwendungsfällen für die Einträge in EF.Logging verwendet werden.

Tabelle 1: TAB_FM_AdV_073 DataType und AccessType in der AdV-Umgebung

5.6 Konfiguration und Datenspeicherung

Zur Administration und Einsichtnahme in das Fachmodulprotokoll bietet der Konnektor dem Administrator eine Managementschnittstelle an (siehe [gemSpec_Kon])

5.7 Fehlerbehandlung

Gemäß [gemSpec_OM#GS-A_3785] müssen Fehler, die während der lokalen Bearbeitung auftreten, erkannt, verarbeitet und im Rahmen einer Fehlermeldung an den aufrufenden Produkttyp gemeldet werden. Dies wird mit den folgenden Anforderungen umgesetzt.

Die Anforderungen TIP1-A_4520 Bildung von Fehler-Trace-Strukturen und TIP1-A_4521 Protokollierung von Fehlern inkl. Trace-Struktur gelten auch für AdV.

Entstehen Fehler oder Warnungen in aufgerufenen Fachmodul-Operationen, so gilt hierfür das gleiche Verhalten wie in AdV-Operationen: Fehler führen zum Abbruch der aufgerufenen Fachmodul-Operation. Wird der Fehler in der aufrufenden AdV-Operation nicht explizit abgefangen und durch ein spezielles Verhalten behandelt, so wird auch die aufrufende AdV-Operation abgebrochen, und an das aufrufende LE-AdV-Terminal wird ein gematik-SOAP-Fault gemeldet:

Der erste Eintrag in der Trace-Liste beschreibt den ursprünglichen, d.h. verursachenden Fehler. Ihm folgen ggf. weitere Fehlereinträge von Zwischenaufrufern. Demnach ist der letzte Eintrag in der Liste von GERROR:Trace der fachliche Fehler, der vom Client ausgewertet wird.

Bei Warnungen wird der Ablauf i. d. R. fortgeführt, sofern nicht explizit etwas Anderes gefordert ist. Dies kann insbesondere bei konnektorinternen Operationen (TUCs) der Fall sein. Das Fachmodul AdV kann den Fehler in seinem Kontext neu interpretieren und ggf. eine abweichende Reaktion formulieren.

Im Erfolgsfalle oder bei Fehlern, die nicht zum Abbruch der Operation führen, gibt das Fachmodul AdV die für diese Operation spezifizierte Response zurück und trägt gemäß [gemSpec_Kon#TIP1-A_5058] im Status-Element den Wert OK bzw. WARNING ein.

Ein Beispiel für einen Fehlertrace befindet sich im Anhang B.

5.8 Status-Rückmeldung

Das Fachmodul AdV verwendet zur Übermittlung des Ausführungsstatus einer Operation das Element „Status“, das in ConnectorCommon.xsd definiert ist. Mit diesem Element wird lediglich der Erfolg oder Misserfolg der Operationsdurchführung gekennzeichnet, jedoch nicht das Operationsergebnis. Beispielsweise kann eine PIN-Verifikation ergeben, dass die PIN blockiert ist. Damit ist die Durchführung erfolgreich, das Ergebnis jedoch negativ.

Das Status-Element wird im Erfolgsfall oder bei Fehlern, die nicht zum Abbruch der Operation führen, an das aufrufende Clientsystem zurückgegeben. Es ist in [gemSpec_Kon] ausführlich beschrieben und in PIC_KON_107 „XML-Struktur des Status-Elements einer SOAP-Antwort“ des Konnektors abgebildet.

6 Funktionsmerkmale

Das Kapitel 6.1 gibt eine Übersicht über die Operationen der beiden externen Schnittstellen AdVService und AdVManagement des Fachmoduls AdV, d. h. der Funktionen, die berechtigte Clientsysteme mit SOAP-Requests aufrufen können.

Eine Beschreibung der Operationen folgt in Kapitel 6.2. Die Requests sind so gestaltet, dass zunächst die auszuführende Funktion gewählt wird, z. B. ReadData. Das Objekt auf der eGK, auf das zugegriffen werden soll, wird als Parameter des Requests genannt, z. B. eine Applikation oder das Zugriffsprotokoll. Diese Syntax ermöglicht eine Erweiterung der Funktionalität, ohne den Schnittstellen weitere Operationen hinzuzufügen.

Für einige der Requests können weitere Angaben erforderlich sein, z. B. um das Zielobjekt eindeutig identifizieren zu können oder um einen Abarbeitungsmodus einzustellen. Da die passenden Parameter in einer generischen Beschreibung nicht allgemeingültig festgelegt werden können, enthalten die Requests die Möglichkeit, zusätzlich anwendungsspezifische Parameter als Key-Value-Paare zu übergeben. Hierfür steht das optionale Element „AdditionalParameter“ zur Verfügung, das mehrfach enthalten sein kann.

Das Fachmodul AdV beantwortet nicht alle Requests selbst, sondern delegiert die Verarbeitung an einen Basisdienst des Anwendungskonnektors oder an weitere Fachmodule, die jeweils für eine Kartenapplikation zuständig sind. In allen Fällen sind vorbereitende Aktionen notwendig. Da sie allen Operationen gemeinsam sind, werden sie im Kapitel 6.3.5 zusammengefasst.

6.1 Externe Schnittstellen – Dienste

Das Fachmodul AdV bietet die zugriffsgesicherten Interfaces „AdVService“ und „AdVManagement“ an, welche nur durch berechtigte Clientsysteme aufgerufen werden dürfen.

6.1.1 AdVService

Die Schnittstelle AdVService enthält die Operationen, die der Versicherte zum Zugriff auf seine eGK aufrufen kann. Damit realisiert das Fachmodul die in der Systemlösung vorgesehenen Schnittstellen I_Application_Management und I_PIN_Management.

6.1.2 AdVManagment

Die Schnittstelle AdVManagement enthält die in I_Terminal_Management der Systemlösung definierten administrativen Funktionen, die zum Starten und zum Aktualisieren eines LE-AdV-Terminals benötigt werden. Sie sind zur Nutzung durch einen Systemadministrator vorgesehen.

6.2 Externe Schnittstellen – Operationen

6.2.1 AdVService – Anwendungsverwaltung

6.2.1.1 Operation StartAdVSession

Am Beginn einer Kartensitzung müssen diverse Prüfungen durchgeführt werden, um sicherzustellen, dass die elektronische Gesundheitskarte echt ist und dass niemand anderes als der Karteninhaber auf die Karte zugreift, und um zu ermitteln, ob die Karte gültig ist.

Zur besseren Nutzerführung am LE-AdV-Terminal ist es zudem wünschenswert, dass ein aufrufendes LE-AdV-Terminal Informationen über den Zustand der auf der Karte befindlichen Applikationen liefert.

Die Außenoperation StartAdVSession führt die dazu notwendigen Aktionen durch. Falls ein LE-AdV-Terminal diese Operation nicht als erstes aufruft, so würde das Fachmodul AdV gemäß AdV-A_2233 die Echtheit und die Gültigkeit der eGK sowie die Authentizität des Benutzers beim Aufruf einer beliebigen anderen Operation prüfen, die als erste aufgerufen wird. Dem LE-AdV-Terminal fehlen dann jedoch die Informationen zum Status der eGK sowie die Status der medizinischen Anwendungen und ihrer Multireferenz-PINs.

Echtheitsprüfung

StartAdVSession prüft zunächst die Echtheit und die Gültigkeit der eGK. Um die Echtheit der Karte nachzuweisen, muss die Karte sich authentisieren. Dazu wird der TUC_KON_005 „Card-to-Card authentisieren“ genutzt. Die dazu benötigte zweite Karte ist die „SM-B für LE-AdV“.

Eine eGK ist gültig, wenn jede der folgenden Bedingungen erfüllt ist:

• der HCA-Container der eGK ist aktiv (nicht gesperrt)
• das AUT-Zertifikat der eGK ist offline gültig, d. h.
• die aktuelle Zeit liegt innerhalb von Beginn und Ende der Gültigkeit des Authentifizierungszertifikates
• die kryptographisch Prüfung des Authentifizierungszertifikates liefert das Ergebnis, dass das Zertifikat kryptographisch korrekt ist
• das AUT-Zertifikat der eGK ist online gültig, d. h. das Ergebnis des Zertifikatsvalidierungsdienstes lautet „VALID“ oder „INCONCLUSIVE“.

Diese Merkmale können mit dem TUC_KON_018 „eGK-Sperrung prüfen“ geprüft werden. Die Auswertung des Ergebnisses von TUC_KON_018 ist der Tabelle TAB_FM_AdV_005 Ablauf StartAdVSession zu entnehmen.

Status der Applikationen

Nicht alle im Objektsystem spezifizierten Anwendungen müssen auf der eGK auch vorhanden sein, und nicht alle vorhandenen Anwendungen müssen auch sichtbar sein. Beispielsweise ist AMTS eine optionale Anwendung; es sind die Varianten „AMTS_vorbereitet“ und „AMTS_angelegt“ möglich. „AMTS_vorbereitet“ heißt, auf der Karte ist lediglich freier Speicher für das spätere Anlegen der Applikation AMTS vorhanden. Des Weiteren kann der Versicherte in einer vorhergehenden Sitzung Anwendungen verborgen haben.

Die Operation StartAdVSession listet die Anwendungen auf, die für einen Versicherten in der AdV-Umgebung zur Verfügung gestellt werden können. Die Liste wird einerseits dadurch beeinflusst, welche Fachmodule im Konnektor implementiert sind, andererseits dadurch, welche Objekte auf der Karte vorhanden sind und welche davon sichtbar oder verborgen sind. Mit diesen Informationen kann ein LE-AdV-Terminal seine Nutzerführung optimieren.

AdV-A_2197 - Operation StartAdVSession

Das Fachmodul AdV MUSS die Operation StartAdVSession gemäß folgenden Beschreibungen anbieten:

Tabelle 5: TAB_FM_AdV_004 Operation StartAdVSession

Name	StartAdVSession
Beschreibung	Diese Operation prüft die Echtheit und die Gültigkeit der eGK. Zur Absicherung, dass nur der Versicherte selbst die Karte lesen kann, wird seine PIN geprüft. Zusätzlich liefert diese Operation eine Liste der Applikationen, die auf der eGK vorhanden sind oder sein könnten, und deren Status. Unterstützt werden alle eGKs ab G2.
Aufruf-parameter
	Name		Beschreibung
	EhcHandle		Adressiert die eGK, die geprüft werden soll.
	Context		MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	VerificationResult	Authentic			Gibt Auskunft über die Echtheit der Karte
		Disabled			Gibt Auskunft, ob DF.HCA gesperrt ist
		Valid			Ergebnis der mathematischen Prüfung des AUT-Zertifikats in DF.ESIGN
		CertificateResult			Gibt Auskunft über den Sperrstatus des AUT-Zertifikats: VALID (nicht geperrt), INVALID (gesperrt, zurückgezogen), INCONCLUSIVE (nicht ermittelbar)
		ExpirationDate			Ablaufdatum des AUT-Zertifikats
	AppName	Name der Anwendung
	AppStatus	Status der Anwendung auf der Karte: AVAILABLE: Die Anwendung ist auf der Karte vorhanden und sichtbar. HIDDEN: Die Anwendung ist auf der Karte vorhanden, aber verborgen. TERMINATED: vorhanden, aber terminiert ABSENT: Die optionale Anwendung ist auf der Karte nicht vorhanden.
	PinInfo	Information über den Zustand der PIN
		PinName		Name der PIN/MRPIN laut [gemSpec_eGK_ObjSys]
		PinStatus		Status der PIN { OK = bereits verifiziert BLOCKED = gesperrt DISABLED = PIN-Schutz abgeschaltet VERIFIABLE = nicht gesperrt und nicht verifiziert TRANSPORT-PIN = PIN im Transport-Status; muss erst umgewandelt werden }
		LeftTries		Im Falle von VERIFIABLE wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Eingangs-bedingungen	keine
Nachbedingung	Die Informationen wurden an das LE-AdV-Terminal versendet.

Tabelle 6: TAB_FM_AdV_005 Ablauf StartAdVSession

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Alle Aktionen gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) durchführen. Ein Fehler in TUC_KON_018 „eGK-Sperrung prüfen“ führt nicht zum Abbruch, sondern wird ausgewertet, siehe Schritt „Ergebnis von TUC_KON_018 auswerten“ Ein Fehler in TUC_KON_005 mit der gemäß „AdV-A_2183 Auswahl SM-B“ korrekt ermittelten SM-B führt in jedem Fall zu Abbruch.
2.	Ergebnis von TUC_KON_018 „eGK-Sperrung prüfen“ auswerten	Die Ergebnisse von TUC_KON_018 sind wie folgt in StartAdVSessionResponse einzubetten: In Disabled wird der Wert von „DF.HCA gesperrt“ eingetragen (true | false) In Valid wird das Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats eingetragen (gültig  true | ungültig  false) In CertificateResult ist der Sperrstatus des C.CH.AUT-Zertifikats einzutragen (gut  OK | gesperrt  REVOKED | nicht ermittelbar  UNKNOWN) Tritt ein Fehler auf, so endet der Use Case hier mit dem Versenden einer StartAdVSessionResponse mit dem Status = Warning und unter Angabe des Fehlers aus TUC_KON_018. Alle bis dahin ermittelten Werte sind in die Response einzufügen.
3.	Ergebnis von TUC_KON_005 auswerten	Meldet TUC_KON_005 keinen Fehler, ist Authentic = true. Liefert UC_KON_005 einen der Fehler 4093 oder 4094, so entfällt das optionale Element Authentic, denn sie wurden nicht durch die Karte verursacht; die Echtheit der Karte ist damit nicht entscheidbar. In allen anderen Fällen ist Authentic = false.
4.	TUC_KON_033 „Zertifikatsablauf prüfen“	Aufruf von TUC_KON_033 {       cardSession = ehcSession;       doInformClients = false } Der Wert für expirationDate ist in StartAdVSessionResponse einzubetten.
5.	Applikationen selektieren und Status ermitteln	Dieser Schritt wird nur durchgeführt, wenn Schritt 1 „Aufruf vorbereiten“ erfolgreich beendet wurde (wenn sich der Akteur nicht als rechtmäßiger Inhaber der Karte ausgewiesen hat, darf er auch keine Informationen über die Status der Anwendungen sehen). Für jede in Tabelle TAB_FM_AdV_062 Identifier der Anwendungen gelistete Anwendung auf der Karte: { Ermittle applicationIdentifier (AID) gemäß [gemSpec_eGK_ObjSys] Aufruf von TUC_KON_221 „Liefere Anwendungsstatus“ {     ehcSession,     applicationidentifier } Ermittle PIN-Referenzen der Anwendung gemäß [gemSpec_eGK_ObjSys] Für jede in AdV nutzbare PinRef der Anwendung: Aufruf von TUC_KON_022 „Liefere PinStatus“ { ehcSession, PinRef } AppName = Anzeigename der Anwendung (lt. Tabelle TAB_FM_AdV_062 Identifier der Anwendungen) AppName, AppStatus und PinInfo in StartAdVSessionResponse einfügen. PIN.CH wird zusammen mit AppName=FA_VSDM angezeigt. }

Hinweis: MRPIN.home kann in AdV nicht genutzt werden.

Tabelle 7: TAB_FM_AdV_006 Fehlercodes der Operation „StartAdVSession“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4051	Technical	Error	Falscher Kartentyp
4234	Technical	Error	Kartenversion wird vom Konnektor nicht unterstützt
6205	Technical	Error	Zugriff auf die Karte nicht erlaubt
6210	Technical	Error	Operation für diese Kartenversion nicht möglich

[<=]

6.2.1.2 Operation ReadData

Diese Außenoperation dient dazu, Daten von der eGK zu lesen. Dazu gehören die Daten der Anwendungen des Versicherten und das Zugriffsprotokoll.

AdV-A_2198 - Operation ReadData

Das Fachmodul AdV MUSS die Operation ReadData gemäß folgenden Beschreibungen anbieten:

Tabelle 8: TAB_FM_AdV_007 Operation ReadData

Name	ReadData
Beschreibung	Diese Operation liest die zu einer Fachanwendung gehörenden Daten von der eGK und liefert sie an den Aufrufer.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, von der die Daten gelesen werden sollen.
	Application	Identifier der Fachanwendung, deren Daten gelesen werden sollen, gemäß Tabelle TAB_FM_AdV_062 Identifier der Anwendungen
	AdditionalParameter	Zusätzliche Parameter, falls vom Fachmodul benötigt (optional)
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Enthält die gelesenen Anwendungsdaten. Der konkrete Datentyp wird durch die Response des Fachmoduls festgelegt, an das der Aufruf delegiert wird, oder durch Fachmodul AdV, wenn es den Aufruf selbst bearbeitet.
Vorbedingung	keine
Nachbedingung	Die Daten der Fachanwendung wurden an das LE-AdV-Terminal versandt.
Ablauf	Bei Delegation an ein Fachmodul: Standardablauf gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „FM“), Parameter-Mapping gemäß Tabelle TAB_FM_AdV_008 Mapping der Parameter für Operation „ReadData“. Für Application = Protokoll: Ablauf gemäß 6.2.1.2.1 „Spezialfall ReadProtocol“
Fehlercodes	Neben den Fehlercodes der aufgerufenen Fachmoduloperation können die Fehlercodes aus 6.3.3, 6.3.4 und 6.3.5 und der aufgerufenen TUCs auftreten.

Tabelle 9: TAB_FM_AdV_008 Mapping der Parameter für Operation „ReadData“

Application	Aufruf/Parameter des FM/Rückgabe	Quelle
	EhcHandle	Das CardHandle der eGK wird aus dem AdV-Aufruf übernommen.
	HpcHandle	das gemäß „AdV-A_2183 Auswahl SM-B“ ermittelte smcHandle übergeben
	Context	Unverändert aus dem AdV-Aufruf übernehmen
FA_AMTS
Aufruf	Operation ReadMP	Aufruf über AMTS_LE_AdV_Service, vgl. [gemSpec_FM_AMTS]
Parameter	UsingPIN	Name der PIN gemäß Objektsystemspezifikation, die Freischaltung der AMTS-Daten genutzt werden soll (MRPIN.AMTS)
Rückgabe	ReadMPResponse	Wie im Fachmodul AMTS definiert
FA_AMTS_CON
Aufruf	Operation ReadConsent	Aufruf über AMTS_LE_AdV_Service, vgl. [gemSpec_FM_AMTS]
Rückgabe	ReadConsentResponse	Wie im Fachmodul AMTS definiert
FA_DPE
Aufruf	Operation ReadDPE	Vgl. [gemSpec_FM_NFDM]
Parameter	EmergencyIndicator	Fixer Wert: false (es liegt kein Notfall vor)
	UpdateIndicator	Fixer Wert: false
Rückgabe	ReadDPEResponse	Wie in DPEService.xsd definiert
FA_NFD
Aufruf	Operation ReadNFD	Vgl. [gemSpec_FM_NFDM]
Parameter	EmergencyIndicator	Fixer Wert: false (es liegt kein Notfall vor)
	UpdateIndicator	Fixer Wert: false
Rückgabe	ReadNFDResponse	Wie in NFDService.xsd definiert
Protokoll
Aufruf	Spezialfall ReadProtocol		Siehe 6.2.1.2.1 Spezialfall ReadProtocol
Rückgabe	ReadProtocolResponse		wie in 6.2.1.2.1 definiert
FA_VSDM
Aufruf	Operation ReadVSDAdV	Vgl. [gemSpec_FM_VSDM]
Rückgabe	ReadVSDResponse	Wie in VSDService.xsd definiert

[<=]

6.2.1.2.1 Spezialfall ReadProtocol

Mit dieser Operation wird die Logging-Datei der eGK des Versicherten ausgelesen.

AdV-A_2199 - Spezialfall ReadProtocol

Das Fachmodul AdV MUSS für die Operation ReadData den Spezialfall ReadProtocol gemäß den folgenden Beschreibungen anbieten:

Tabelle 10: TAB_FM_AdV_009 Spezialfall ReadProtocol

Element	Beschreibung
Name	ReadProtocol
Beschreibung	Diese Operation liefert die Einträge aus der Datei EF.Logging der eGK des Versicherten. Es werden stets sämtliche vorhandenen Datensätze geliefert. Eine Interpretation der Daten, z. B. Umwandlung von DataType in Anwendungsname oder TypeOfAccess in eine verständliche Beschreibung der Zugriffsart, wird nicht vorgenommen. Dies obliegt dem aufrufenden Client.
Version	Unterstützt werden alle eGKs ab G2.
Eingangsdaten	ehcHandle     (die eGK, deren Logging-Einträge gelesen werden sollen) Context (MandantId, CsId, WorkplaceId (siehe 6.4.3.1))
Ausgangsdaten	XML-Dokument mit Liste von Einträgen der Datei EF.Logging der eGK
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	LogEntry	Timestamp	Zeitpunkt des Datenzugriffs
		DataType	Kürzel, das die Fachanwendung identifiziert
		TypeOfAccess	Kürzel für die Zugriffsart, wie von den Fachanwendungen festgelegt
		ActorID	ICCSN des HBA oder der SM-B des zugreifenden Akteurs
		ActorName	Name des zugreifenden Akteurs
Nachbedingung	Die Logging-Daten der eGK wurden an den Aufrufer geliefert

Tabelle 11: TAB_FM_AdV_011 Ablauf ReadProtocol

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle 60, Spalte „AdV“) abarbeiten (die notwendige PIN-Prüfung ist im Standardablauf enthalten) Wenn die Gesundheitsanwendung gesperrt ist, bricht die Operation mit dem Fehler 6207 ab.
2.	Records lesen	Für jeden Record mit Nr. n (n=1,..,50) der Datei EF.Logging: { Aufruf von TUC_KON_209 „LeseRecord“ { cardSession = ehcSession; fileIdentifier = FID von EF.Logging; folder = AID von DF.HCA; recordNumber = n } bzw. Aufruf mit dem SFI der Datei Ende des Lesevorgangs, wenn Kartenfehlercode ´6A 83´ RecordNotFound (wenn keine weiteren Datensätze vorhanden sind) Wenn der Record nicht leer ist, dann die Daten als LogEntryType in ReadProtocolResponse einfügen. Die abzubildende Struktur der Datensätze aus EF.Logging ist in [gemSpec_Karten_Fach_TIP] beschrieben. } Bei einem Lesefehler (´62 81´ CorruptDataWarning) eines Datensatzes ist der Ausführungsstatus der Operation auf WARNING zu setzen und der Fehler 6206 mit Angabe der Satznummer zu tracen. Falls die Karte Daten zu diesem Record geliefert hat, werden sie normal in die Response eingefügt. Die Schleife wird mit dem nächsten Record fortgesetzt.
3.	Response vorbereiten	Element Status in ReadProtocolResponse ergänzen. Wenn in EF.Logging kein Record vorhanden ist, dann entfällt das Element LogEntry. Status erhält auch in diesem Fall den Wert „OK“.
4.	Return	ReadProtocolResponse in die ReadDataResponse einfügen;

Tabelle 12: TAB_FM_AdV_012 Fehlercodes für den Spezialfall „ReadProtocol“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlern aus dem in Tabelle 60 beschriebenen Ablauf und den aufgerufenen TUCs können folgende Fehlercodes auftreten:
6206	Technical	Warning	Datensatz Nr. <x> beschädigt
6207	Technical	Error	eGK gesperrt

[<=]

6.2.1.3 Operation WriteData

Diese Außenoperation dient dazu, Daten einer der Anwendungen des Versicherten auf die eGK zu schreiben. Sie kann z. B. angewendet werden, um den Datensatz Persönliche Erklärungen zu aktualisieren. Sie dient nicht dazu, die Daten mit Nullen zu überschreiben – dafür ist EraseData zu verwenden. Für die Übertragung von Daten des Versicherten von der alten eGK auf die neue eGK – derzeit nur für AMTS definiert – ist die Operation CopyData zu verwenden.

AdV-A_2200 - Operation WriteData

Das Fachmodul AdV MUSS die Operation WriteData gemäß den folgenden Beschreibungen anbieten.

Tabelle 13: TAB_FM_AdV_013 Operation WriteData

Name	WriteData
Beschreibung	Diese Operation schreibt Dateninhalte einer Anwendung in den entsprechenden Container der eGK.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, von der die Daten gelesen werden sollen.
	Application	Identifier der Fachanwendung, deren Daten geschrieben werden sollen, gemäß Tabelle TAB_FM_AdV_062 Identifier der Anwendungen
	DataToBeWritten	Die Daten, die geschrieben werden sollen. Das Format wird durch die Fachanwendung bestimmt.
	AdditionalParameter	Zusätzliche Parameter, falls sie vom Fachmodul benötigt werden (optional), z. B. Position der Daten oder Recordnummer.
	Context	Aufrufkontext: MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Enthält die Antwort des Fachmoduls. Der konkrete Datentyp wird durch die Response des Fachmoduls, an das der Aufruf delegiert wird, oder durch das Fachmodul AdV festgelegt, wenn es den Aufruf selbst bearbeitet.
Vorbedingung	keine
Nachbedingung	Die übergebenen Daten wurden auf die Karte geschrieben
Ablauf	Standardablauf gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „FM“), Parameter-Mapping gemäß Tabelle TAB_FM_AdV_014 Mapping der Parameter für Operation „WriteData“
Fehlercodes	Neben den Fehlercodes der aufgerufenen Fachmoduloperation können die Fehlercodes aus 6.3.3, 6.3.4 und 6.3.5 und der aufgerufenen TUCs auftreten.

Tabelle 14: TAB_FM_AdV_014 Mapping der Parameter für Operation „WriteData“

Application	Aufruf/Parameter des FM/Rückgabe	Quelle
alle	EhcHandle	Das CardHandle der eGK wird unverändert aus dem AdV-Aufruf übernommen.
	HpcHandle	das gemäß „AdV-A_2183 Auswahl SM-B“ ermittelte smcHandle übergeben
	Context	Unverändert aus dem AdV-Aufruf übernehmen
FA_DPE
Aufruf	Operation WriteDPE	Vgl. [gemSpec_FM_NFDM]
Parameter	DPE_Document	DataToBeWritten (Parameter DPE_Document gemäß DPE_Document.xsd)
Rückgabe	WriteDPEResponse	Wie in DPEService.xsd definiert (Rückgabe vom Fachmodul NFD)

[<=]

6.2.1.4 Operation EraseData

Diese Außenoperation dient dazu, die Daten einer Anwendung auf der eGK zu löschen, indem die Datei mit Nullen überschrieben wird.

AdV-A_2201 - Operation EraseData

Das Fachmodul AdV MUSS die Operation EraseData gemäß den folgenden Beschreibungen anbieten:

Tabelle 15: TAB_FM_AdV_015 Operation EraseData

Name	EraseData
Beschreibung	Diese Operation überschreibt die Daten einer Fachanwendung auf der eGK mit Nullen.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, auf die zugegriffen werden soll.
	Application	Identifier der Fachanwendung, deren Daten ausgenullt werden sollen, gemäß Tabelle TAB_FM_AdV_062 Identifier der Anwendungen
	AdditionalParameter	Zusätzliche Parameter, die vom Fachmodul benötigt werden (optional), z. B. RecordNumber zur Adressierung einzelner Einwilligungs-Datensätze
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Der konkrete Datentyp wird die Response des Fachmoduls festgelegt, an den der Aufruf delegiert wird, oder durch das Fachmodul AdV, wenn es den Aufruf selbst bearbeitet
Vorbedingung	keine
Nachbedingung	Die Daten der Fachanwendung auf der Karte sind mit Nullen überschrieben
Ablauf	Standardablauf gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „FM“); Parameter-Mapping gemäß Tabelle TAB_FM_AdV_016 Mapping der Parameter für Operation „EraseData“
Fehlercodes	Neben den Fehlercodes der aufgerufenen Fachmoduloperation können die Fehlercodes aus 6.3.3, 6.3.4 und 6.3.5 und der aufgerufenen TUCs auftreten.

Tabelle 16: TAB_FM_AdV_016 Mapping der Parameter für Operation „EraseData“

Application		Aufruf/Parameter des FM/Rückgabe	Quelle
alle		EhcHandle	Das CardHandle der eGK wird unverändert aus dem AdV-Aufruf übernommen.
		HpcHandle	das gemäß „AdV-A_2183 Auswahl SM-B“ ermittelte smcHandle übergeben
		Context	unverändert aus dem AdV-Aufruf übernehmen
FA_AMTS_CON
Aufruf	Operation DeleteConsent		Vgl. [gemSpec_FM_AMTS]
Rückgabe	DeleteConsentResponse		Wie im Fachmodul AMTS festgelegt.
FA_DPE
	Gemäß EraseDPE		[gemSpec_FM_NFDM]
	EraseDPEResponse		Wie in DPEService.xsd definiert (aus dem Fachmodul NFDM)
FA_NFD
	Gemäß EraseNFD		[gemSpec_FM_NFDM]
	EraseNFDResponse		Wie in NFDService.xsd definiert (aus dem Fachmodul NFDM)

[<=]

6.2.1.5 Operation CopyData

Die Operation CopyData überträgt die medizinischen Anwendungsdaten von einer eGK auf eine neuere eGK des Versicherten. Dies kann erfolgen, wenn der Versicherte eine neue eGK von seiner Krankenkasse erhält und noch im Besitz der alten eGK ist.

Die Systemlösung sieht vor, dass am AdV-Terminal für die eGK nur ein Slot zur Verfügung steht, so dass die beiden eGKs nacheinander gesteckt werden müssen. In diesem Ausnahmefall dürfen die medizinischen Daten des Versicherten über den Steckzyklus der Quellkarte hinaus im Konnektor gespeichert werden, genauer: in dem für das Fachmodul AdV reservierten Bereich des sicheren Speichers im Konnektor. Nach dem Ende des Vorgangs müssen die Daten gelöscht werden (vgl. AdV-A_2195).

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

Die Operation CopyData soll auch dann möglich sein, wenn das AUT-Zertifikat der Quellkarte zeitlich abgelaufen oder online ungültig ist. Daher muss das Fachmodul AdV eine eGK auch in diesem Fall akzeptieren (siehe B13 in AdV-A_2233).

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

AdV-A_2202 - Operation CopyData

Das Fachmodul AdV MUSS die Operation CopyData gemäß den folgenden Beschreibungen anbieten.

Tabelle 17: TAB_FM_AdV_017 Operation CopyData

Name	CopyData
Beschreibung	Diese Operation überträgt Daten einer oder mehrerer Anwendungen von einer eGK auf eine neuere eGK desselben Versicherten
Aufruf-parameter
	Name		Beschreibung
	EhcHandle		Adressiert die alte eGK des Versicherten
	Application [1..n]		Identifier der Fachanwendungen (gemäß ApplicationId in TAB_FM_AdV_062 Identifier der Anwendungen), deren Daten übertragen werden sollen
	Context		Aufrufkontext: MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der durch AdV geleisteten Anteile der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	AppResult [1..n]	Name		Beschreibung
		AppName		Name der Applikation
		Status		Ausführungsstatus der durch das anwendungsspezifische Fachmodul geleisteten Anteile der Operation
Vorbedingung	keine
Nachbedingung	Die Daten wurden auf die Zielkarte übertragen. In EF.Logging der Zielkarte befindet sich je bearbeiteter Anwendung ein neuer Eintrag, der dokumentiert, dass die Daten dieser Anwendung aus der Übernahme von einer anderen eGK des Versicherten stammen. Auf der Quellkarte sind die bearbeiteten Anwendungen verborgen Auf der Zielkarte haben die erfolgreich bearbeiteten Anwendungen den Status (verbogen/sichtbar) der Quellkarte. Tritt ein Fehler beim Schreiben auf die Zielkarte auf, wird der Ausgangsstatus der betroffenen Anwendung auf der Zielkarte wiederhergestellt.
Ablauf	Siehe Tabelle 18: TAB_FM_AdV_069 Ablauf CopyData
Fehlercodes	Neben den Fehlern, die bei Erfüllung der Zugriffsbedingungen erkannt wurden, können Fehler der aufgerufenen TUCs und Fachmoduloperation auftreten.

Die in Tabelle 18 genannten aufzurufenden Methoden getData() und putData() sind in Kapitel 6.2.1.5.1 erläutert.

Tabelle 18: TAB_FM_AdV_069 Ablauf CopyData

Nr.	Schritt	Beschreibung
	Erfolgsbedingungen sicherstellen	Sicherstellen, dass für die aktuelle Karte folgende Bedingungen erfüllt sind: Die Zugriffsberechtigung für das Triple Mandant / Clientsystem / Arbeitsplatz wurde geprüft (B10) Es handelt sich um eine eGK (B04) die Version dieser eGK kann von AdV verarbeitet werden (B06) Die Echtheit der eGK ist erwiesen (B05) DF.HCA ist aktiv (B13) Die C2C-Authentisierung mit einer für die AdV-Umgebung geeigneten SM-B wurde durchgeführt (B05) Die Versicherten-PIN wurde verifiziert (B14)
	Prüfdaten speichern	Daten der eGK speichern: ICCSN der Karte KVNR des Versicherten, Gültigkeitsbeginn-Datum des AUT-Zertifikats Version des Objektsystems der eGK
	getData()	Schleife über alle in den Eingangsparametern angegebenen Anwendungen: {     1. Anwendungstatus speichern und danach ggf. die          Anwendung sichtbar machen durch Aufruf von           TUC_KON_222 „Anwendung aktivieren/deaktivieren“ {             cardSession = ehcSession;             applicationIdentifier;             enable = true             }     2. Aufruf bei dem Fachmodul, das diese Anwendung         implementiert:         getData(             ehcSession,             WorkplaceId,             objsysVersion,             application = der zu Application gehörige Identifier             in der Karten-Spec gemäß TAB_FM_AdV_062)         );     3. applicationData (Daten der Anwendung) im sicheren         Speicher ablegen     4. Falls die Anwendungsdaten erfolgreich gelesen und        abgelegt wurden wird die Anwendung auf der Quell-eGK        verborgen durch Aufruf von           TUC_KON_222 „Anwendung aktivieren/deaktivieren“ {             cardSession = ehcSession;             applicationIdentifier;             enable = false             }     5. Falls ein Aufruf mit einem Fehler beendet wird, so wird         der Fehlertrace, den AdV vom aufgerufenen Fach-         modul erhalten hat, in ein eigenes Element AppResult         eingefügt. Ein AdV-Fehlercode wird für die         entsprechende Fehlersituation nicht definiert. }
	Anmeldung beim EventService	Das Fachmodul AdV prüft, ob es beim Ereignisdienst des Konnektors angemeldet ist, um CARD/INSERTED- und CARD/REMOVED-Events für das Kartenterminal und den Kartenslot, in dem die Quellkarte steckt, zu empfangen. Ggf. meldet sich das Fachmodul dort an.
	Kartenwechsel	Event werfen: topic = ADV/SWAPCARD; eventType=Op; severity=Info; parameters={ctId=$ctId; slotId=$slotId; KVNR=$KVNR} Das Fachmodul AdV setzt einen Status, so dass es beim darauffolgenden CARD/REMOVED-Event für dieses CardHandle die gelesenen Anwendungsdaten nicht verwirft. Es wird erwartet, dass das AdV-Terminal nach dem Empfang des ADV/SWAPCARD den Versicherten auffordert, seine eGK zu ziehen und die neue eGK zu stecken.
	eGK-Sitzung initialisieren	Wenn die neue Karte gesteckt wurde (Ereignis CARD/INSERTED wurde empfangen), dann führt das Fachmodul AdV alle Schritt zum Initialisieren der neuen Kartensitzung gemäß AdV-A_2233 durch.
	Prüfdaten abgleichen	Prüfdaten der neuen eGK mit denen der alten eGK vergleichen: Wenn ICCSNalt = ICCSNneu, dann Abbruch der Operation mit Fehler 6217. Wenn KVNRalt <> KVNRneu (Karteninhaber nicht identisch), dann Abbruch mit Fehler 6218 Sei validfrom das Gültigkeitsbeginn-Datum des X.509-AUT-Zertifikats. Wenn validfromneu < validfromalt, dann Abbruch mit Fehler 6219 Bei Abbruch: gespeicherte Daten der Quellkarte aus dem sicheren Speicher löschen.
	putData()	Schleife über alle Anwendungen, für die getData() Anwendungsdaten geliefert hat: {     1. ggf. Anwendung sichtbar machen durch Aufruf von         TUC_KON_222 „Anwendung aktivieren/deaktivieren“ {             cardSession = ehcSession;             applicationIdentifier;             enable = true             }     2. putData(             ehcSession,             WorkplaceId,             objsysVersionSrc,             objsysVersionDest,             application,             applicationData     );     3. Falls ein Aufruf mit einem Fehler endet, so wird der         Fehlertrace, den AdV vom aufgerufenen Fachmodul         erhalten hat, in ein eigenes Element AppResult eingefügt.         Ein AdV-Fehlercode wird für die         entsprechende Fehlersituation nicht definiert.         Im Fehlerfall wird der Anwendungstatus der Ziel-eGK         wieder hergestellt: Falls auf der Ziel-eGK die Anwendung         verborgen war wird sie wieder verborgen durch Aufruf von         TUC_KON_222 „Anwendung aktivieren/deaktivieren“ {             cardSession = ehcSession;             applicationIdentifier;             enable = false             }         wobei ehcSession die CardSession der Ziel-eGK ist.     4. Wenn die Anwendung auf der Quellkarte verborgen         gewesen war, diese gemäß appStatus wieder         verbergen durch Aufruf von         TUC_KON_222 „Anwendung aktivieren/deaktivieren“ {             cardSession = ehcSession;             applicationIdentifier;             enable = false             }         wobei ehcSession die CardSession der Ziel-eGK ist. }
	Abschluss	Alle zwischengespeicherten Anwendungsdaten aus dem sicheren Speicher entfernen AppResult-Elemente in CopyDataResponse eintragen

Tabelle 19: TAB_FM_AdV_070 Fehlercodes der Operation „CopyData“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlern aus den Bedingungen B10, B04, B06, B05, B13 und B14 (siehe Tabelle TAB_FM_AdV_058 Fehlercodes von „eGK-Sitzung initialisieren“ und aus den aufgerufenen TUCs können folgende Fehlercodes auftreten:
6216	Technical	Error	Zielkarte nicht innerhalb des Timeouts gesteckt
6217	Technical	Error	dieselbe Karte noch einmal gesteckt
6218	Technical	Error	Karteninhaber nicht identisch
6219	Technical	Error	die Zielkarte ist älter als die Quellkarte

[<=]

6.2.1.5.1 Required Interface zu den anwendungsspezifischen Fachmodulen

Das Fachmodul AdV ruft bei den anwendungsspezifischen Fachmodulen die internen Methoden getData() und putData() auf. Sie müssen von jedem anwendungsspezifischen Fachmodul implementiert werden, das Daten von einer eGK zu einer anderen eGK übertragen soll. Die Beschreibung der internen Methoden ist informell und dient lediglich dem Zweck, die Verantwortlichkeiten der Module zu benennen und den Ablauf aus Sicht das Fachmoduls zu beschreiben. Die konkrete Signatur und die Implementierung der internen Aufrufe sind herstellerspezifisch,

Tabelle 20: TAB_FM_AdV_071 Benötigte Methode getData()

Tabelle 21: TAB_FM_AdV_072 Benötigte Methode putData()

In Tabelle TAB_FM_AdV_073 DataType und AccessType in der AdV-Umgebung sind die Werte für DataType und AccessType aufgelistet, die von den Fachmodulen für die Einträge in EF.Logging innerhalb der Methode putData verwendet werden.

6.2.1.6 Operation DeactivateApplication

Diese Außenoperation dient dazu, die Daten einer Anwendung des Versicherten auf der eGK zu verbergen.

AdV-A_2203 - Operation DeactivateApplication

Das Fachmodul AdV MUSS die Operation DeactivateApplication gemäß den folgenden Beschreibungen anbieten:

Tabelle 22: TAB_FM_AdV_020 Operation DeactivateApplication

Name	DeactivateApplication
Beschreibung	Diese Operation versetzt eine freiwillige Anwendung der eGK in den Betriebszustand „deactivated“. In diesem Zustand führt die Karte keine Lese- oder Schreiboperationen auf Dateien dieser Anwendung aus (die Karte meldet: ´69 82´ Zugriffsbedingung nicht erfüllt); ebenso erlaubt sie keine Nutzung der Schlüssel dieser Anwendung. PIN-Operationen mit der MRPIN, die zum Aktivieren der Anwendung benötigt wird, sind möglich.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, deren Anwendung verborgen werden soll
	Application	Identifier der Fachanwendung, die verborgen werden soll, gemäß Tabelle 63: TAB_FM_AdV_062 Identifier der Anwendungen
	Context	MandantId, CsId, WorkplaceId (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
Vorbedingung	keine
Nachbedingung	Im Erfolgsfall (Ausführungsstatus der Operation = OK) hat der Anwendungscontainer auf der Karte den Betriebszustand „deactivated“. Im Erfolgsfall hat EF.Logging auf einer eGK der Generation 2.1 (oder höher) einen neuen Eintrag, der dokumentiert, dass die Daten der ausgewählten Anwendung verborgen wurden.

Tabelle 23: TAB_FM_AdV_021 Ablauf Deactivate Application

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) abarbeiten. Wenn die Gesundheitsanwendung gesperrt ist, bricht die Operation mit dem Fehler 6207 ab.
2.	Kartenversion prüfen	Prüfe anhand von CARD.CARDVERSION, ob es eine eGK G2 oder höher ist. Wenn die Version der eGK nicht von AdV unterstützt wird, dann Abbruch mit Fehlercode 6210
3.	ApplicationIdentifier ermitteln	Ermittle applicationIdentifier entsprechend dem Wert von Application (gemäß [gemSpec_eGK_ObjSys]). Wenn applicationIdentifier nicht existiert, wird die Operation mit einem gematik-SOAP-Fault unter Angabe des Fehlers 4046 „Kartenapplikation existiert nicht“ beendet.
4.	Zustand der Anwendung ermitteln	Aufruf von TUC_KON_221 „Liefere Anwendungsstatus“{ cardSession = ehcSession; applicationIdentifier } Wenn der Status der Anwendung „ABSENT“ oder „TERMINATED“ ist, dann Abbruch der Operation mit SOAP Fault und Fehlercode 4046 „Kartenapplikation existiert nicht“. Wenn der Status der Anwendung „HIDDEN“ ist, dann beende die Operation erfolgreich mit Status.Result = OK.
5.	pwdIdentifier ermitteln	Ermittle den Passwort-Identifier pwdIdentifier der MRPIN, mit der das Zugriffsrecht zum Aktivieren für die zu bearbeitende Fachanwendung (Application ) gesetzt werden kann (siehe [gemSpec_eGK_ObjSys]) Wenn keine PIN definiert ist, mit der diese Anwendung abzuschalten wäre, wird die Operation mit dem Fehler 6200 abgebrochen.
6.	MRPIN verifizieren	Ermittle displayName = Anzeigename der Fachanwendung (aus Tabelle 63 mit applicationId = $Application entnehmen) Aufruf TUC_KON_012 „PIN verifizieren“ { cardSession = ehcSession; workplaceID = $Context.workplaceID; pinRef = Referenz auf die dafür spezifizierte MRPIN der Anwendung actionName = displayName + „verbergen“, } Tritt hierbei ein Fehler auf, wird die Operation mit einem SOAP-Fault und dem Fehler 6209    „PIN-Freischaltung gescheitert“ beendet und die ursprünglichen Fehler zusätzlich in GERROR:Error eingetragen. Wenn TUC_KON_012 anstelle eines Fehlers das Result ERROR liefert, dann den Fehler 6208 „Nutzer-Abbruch oder Bearbeitungsfehler“ REJECTED liefert, dann den Fehler 4061 „Falsche alte PIN, verbleibende Eingabeversuche <x>“ BLOCKED liefert, dann den Fehler 4063 „PIN bereits gesperrt (BLOCKED)“ in GERROR:Error eintragen. actionName ist der Verwendungszweck für die PIN-Eingabe, wie er am Kartenterminal angezeigt werden soll. Beispiel: Für Application = FA_NFD ist als actionName anzugeben: „NFD verbergen“
7.	Anwendung deaktivieren (verbergen)	Aufruf von TUC_KON_222 „Anwendung aktivieren/deaktivieren“ { cardSession = ehcSession; applicationIdentifier; enable = false }
8.	Zugriffsprotokolleintrag auf eGK erstellen	Für eine eGK der Generation 2.1 (oder höher) wird ein Logeintrag durch Aufruf von TUC_KON_006 "Datenzugriffsaudit eGK schreiben" erstellt. Die Belegung der Parameter erfolgt gemäß Tabelle TAB_FM_AdV_073 DataType und AccessType in der AdV-Umgebung.
9.	Return	DeactivateApplicationResponse, Status.Result = OK

Tabelle 24: TAB_FM_AdV_022 Fehlercodes der Operation „DeactivateApplication“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4046	Technical	Error	Kartenapplikation existiert nicht
6210	Technical	Error	Operation für diese Kartenversion nicht möglich
6200	Technical	Error	Operation für diese Anwendung nicht definiert
6207	Technical	Error	eGK gesperrt
6209	Technical	Error	PIN-Freischaltung gescheitert

[<=]

6.2.1.7 Operation ActivateApplication

Diese Außenoperation dient dazu, die Daten einer Anwendung des Versicherten wieder sichtbar zu machen.

AdV-A_2204 - Operation ActivateApplication

Das Fachmodul AdV MUSS die Operation ActivateApplication gemäß den folgenden Beschreibungen anbieten:

Tabelle 25: TAB_FM_AdV_023 Operation ActivateApplication

Name	ActivateApplication
Beschreibung	Diese Operation versetzt eine freiwillige Anwendung der eGK in den Status „activated“. In diesem Status ist die Ausführung der Operationen gemäß [gemSpec_eGK_ObjSys] auf dieser Anwendung möglich.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, deren Anwendung sichtbar gemacht werden soll.
	Application	Identifier der Fachanwendung, die sichtbar gemacht werden soll, gemäß Tabelle 63: TAB_FM_AdV_062 Identifier der Anwendungen
	Context	MandantId, CsId, WorkplaceId (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
Vorbedingung	keine
Nachbedingung	Im Erfolgsfall (Ausführungsstatus der Operation = OK) hat der Anwendungscontainer auf der Karte den Betriebszustand „activated“. Im Erfolgsfall hat EF.Logging auf einer eGK der Generation 2.1 (oder höher) einen neuen Eintrag, der dokumentiert, dass die vorborgenen Daten der ausgewählten Anwendung wieder sichtbar gemacht wurden.

Der Ablauf für ActivateApplication ist analog zu TAB_FM_AdV_021 Ablauf Deactivate Application, jedoch wird im Schritt 4 auf „HIDDEN“ geprüft, und im Schritt 8 wird der TUC_KON_222 „Anwendung aktivieren/deaktivieren“ mit dem Parameter enable = true zum Aktivieren der Anwendung aufgerufen.

Tabelle 26: TAB_FM_AdV_024 Ablauf Activate Application

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Wie im Ablauf Deactivate Application
2.	Kartenversion prüfen	Wie im Ablauf Deactivate Application
3.	AID ermitteln	Wie im Ablauf Deactivate Application
4.	Zustand der Anwendung ermitteln	Aufruf von TUC_KON_221 „Liefere Anwendungsstatus“{ cardSession = ehcSession; applicationIdentifier = AID } Wenn der Status der Anwendung „ABSENT“ oder „TERMINATED“ ist, dann Abbruch der Operation mit SOAP Fault und Fehlercode 4046 „Kartenapplikation existiert nicht“. Wenn der Status der Anwendung „AVAILABLE“ ist, dann beende die Operation erfolgreich mit Status.Result = OK.
5.	pwdIdentifier ermitteln	Wie im Ablauf Deactivate Application
6.	MRPIN verifizieren	Wie im Ablauf Deactivate Application, jedoch actionName = displayName + „aktivieren“,
7.	Anwendung aktivieren	Aufruf von TUC_KON_222 „Anwendung aktivieren/deaktivieren“ { cardSession = ehcSession; applicationIdentifier; enable = true }
8.	Zugriffsprotokolleintrag auf eGK erstellen	Für eine eGK der Generation 2.1 (oder höher) wird ein Logeintrag durch Aufruf von TUC_KON_006 "Datenzugriffsaudit eGK schreiben" erstellt. Die Belegung der Parameter erfolgt gemäß TAB_FM_AdV_073 DataType und AccessType in der AdV-Umgebung.
9.	Return	ActivateApplicationResponse, Status.Result = OK

Tabelle 27: TAB_FM_AdV_025 Fehlercodes der Operation „ActivateApplication“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4046	Technical	Error	Kartenapplikation existiert nicht
6210	Technical	Error	Operation für diese Kartenversion nicht möglich
6200	Technical	Error	Operation für diese Anwendung nicht definiert
6207	Technical	Error	eGK gesperrt
6209	Technical	Error	PIN-Freischaltung gescheitert

[<=]

6.2.1.8 Operation QuitAdv

Diese Außenoperation dient dazu, die Kartensitzung der eGK zu beenden und die vom Fachmodul gecachten Daten zu löschen. Sie kann z. B. nach längerer Inaktivität des Nutzers automatisch durch das AdV-Terminal aufgerufen werden, um Daten einer evtl. vergessenen Karte vor Einsichtnahme durch Unbefugte zu schützen.

AdV-A_2559 - Operation QuitAdv

Das Fachmodul AdV MUSS die Operation QuitAdv gemäß den folgenden Beschreibungen anbieten:

Tabelle 28: TAB_FM_AdV_074 Operation QuitAdv

Name	QuitAdv
Beschreibung	Diese Operation beendet eine Kartensitzung einer eGK und löscht die Daten, die das Fachmodul AdV zu dieser Karte gespeichert hat.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, deren gecachte Daten gelöscht werden sollen.
	Context	MandantId, CsId, WorkplaceId (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
Vorbedingung	keine
Nachbedingung	Im Erfolgsfall (Ausführungsstatus der Operation = OK) ist die Kommunikation mit der Karte beendet und die Karte ist elektrisch / logisch deaktiviert. Bei Kartenterminals mit entsprechendem Mechanismus wurde die Karte ausgeworfen. Die kartenspezifischen Daten, die das Fachmodul AdV für die Dauer der Kartensitzung gespeichert hatte, sind gelöscht.

Tabelle 29: TAB_FM_AdV_075 Ablauf QuitAdv

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler, dann bricht die Operation mit dem Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung zur eGK durch den Aufruf TUC_KON_000 { $context.mandantId; $context.clientsystemId; $context.workplaceId; $ehcHandle } Wenn TUC_KON_000 den Fehler 4008 liefert (Karte nicht als gesteckt identifiziert), dann setzt das Fachmodul AdV die Operation mit dem mit dem Schritt „Daten löschen“ fort. Wenn TUC_KON_000 einen anderen Fehler liefert, dann bricht die Operation mit dem Fehlercode 6205 ab.
3.	TUC_KON_253 „Liefere Karten_Liste“	Liste der Karten holen mit TUC_KON_253 { $context.workplaceId; $context.clientsystemId; $context.mandantId; CardType = „EGK“ }
4.	Parameter ermitteln	Anhand des EhcHandles die Parameterwerte für das Kartenterminal ctID und die Slot-Nummer slotNo ermitteln. Wenn für das EhcHandle kein ctID und/oder slotNo gefunden werden kann, Abbruch mit Fehler 4047 „Karte-Handle ungültig“
5.	TUC_KON_057 „Karte auswerfen“	Das Fachmodul AdV veranlasst den Kartenauswurf durch den Aufruf TUC_KON_057{       CtId = ctID;       SlotID = slotNo.,       DisplayMsg = “Bitte Karte aus Slot x entnehmen”         TimeOut = 30 }. (x = Slotnummer) Wenn TUC_KON_057 einen Fehler meldet, wurde das Kommando zum Auswerfen der Karte möglicherweise nicht korrekt abgearbeitet. Dies führt nicht zum Abbruch. Der Intention der Operation QuitAdV folgend, setzt das Fachmodul AdV mit Schritt 6. Daten löschen fort.
6.	Daten löschen	Das Fachmodul AdV löscht die zu diesem EhcHandle gecachten Daten, z. B. die Status der Anwendungen oder Informationen über bereits geprüfte Erfolgsbedingungen sowie die für CopyData gespeicherten Daten einer eGK, sofern sie nicht bereits als Reaktion auf das Event „Karte entfernt“ gelöscht wurden.
7.	Return	QuitAdvResponse

Tabelle 30: TAB_FM_AdV_076 Fehlercodes der Operation „QuitAdv“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4047	Technical	Error	Karten-Handle ungültig
6205	Technical	Error	Zugriff auf die eGK nicht erlaubt

[<=]

Die durch die Operation CopyData gecachten Daten der Quellkarte werden entweder nach erfolgreicher Datenübertragung durch die Operation CopyData selbst gelöscht oder – im Falle längerer Nutzerinaktivität – durch die Operation QuitAdV.

6.2.2 AdVService – PIN-Verwaltung

6.2.2.1 Operation ChangePin

Diese Außenoperation dient dazu,

1. die PIN des Versicherten zu ändern, wobei sie als PIN.CH oder eine der Multireferenz-PINs adressiert werden kann,
2. Die Vertreter-PIN in der AMTS-Anwendung zu ändern.
3. Die PIN.QES des Versicherten zu ändern, sofern sie auf der Karte vorhanden ist.

Für eGKs der Generation G2.0 ist es in bestimmten Situationen sinnvoll, beim ChangePin die Versicherten-PIN als Multireferenz-PIN zu adressieren statt als PIN.CH. Das ist immer dann der Fall, wenn der Versicherte bereits eine Fachanwendung zur Bearbeitung ausgewählt und dafür die passende MRPIN verifiziert hat. Da die MRPIN im Container der Fachanwendung abgelegt ist und nicht – wie die PIN.CH – im Wurzelverzeichnis, würde der Freischaltzustand der MRPIN verloren gehen, wenn das Verzeichnis zwecks Änderung der PIN.CH verlassen wird. Bei Änderung als MRPIN braucht der Fachcontainer zum Ändern des Geheimnisses nicht verlassen zu werden. Eine neuerliche PIN-Eingabe, die bei der Rückkehr in die Fachanwendung nötig wäre, wird damit eingespart.

In eGKs der Generation G2.1 liegen alle MRPINs im Wurzelverzeichnis. Beim Wechsel zu einer anderen Anwendung verliert eine bereits verifizierte MRPIN nicht ihren Status. Daher ist es für die Bedienfreundlichkeit unerheblich, ob die Versicherten-PIN als PIN.CH oder MRPIN.xxxx geändert wird.

AdV-A_2206 - Operation ChangePin

Das Fachmodul AdV MUSS die Operation ChangePin gemäß folgenden Beschreibungen anbieten:

Tabelle 31: TAB_FM_AdV_030 Operation ChangePin

Name	ChangePin
Beschreibung	Diese Operation dient dazu, die PIN des Versicherten oder die AMTS-Vertreter-PIN auf der eGK G2 zu ändern. Zulässig sind PIN.CH, alle MRPINs (außer MRPIN.home), die PIN.QES und die AMTS-Vertreter-PIN. Der Versuch, MRPIN.home zu ändern, führt zum Fehler 4058. Wenn die Operation für diese Kartenversion der eGK nicht unterstützt wird, beendet AdV die Operation mit dem Fehler 6210.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK G2, auf der die PIN geändert werden soll.
	PinRef	Name der PIN gemäß Objektsystemspezifikation, deren Geheimnis geändert werden soll
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe im Erfolgsfall
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	PinResult	Status der PIN (OK, REJECTED, BLOCKED)
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	PinResult = OK:: Die PIN wurde auf der Karte geändert PinResult = REJECTED: Die PIN wurde auf der Karte nicht geändert. Die Anzahl der verbleibenden Versuche für die PIN-Eingabe der eGK wurde um 1 verringert. PinResult = BLOCKED: Die PIN wurde auf der Karte nicht geändert. PIN ist gesperrt.

Tabelle 32: TAB_FM_AdV_031 Ablauf ChangePin

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) abarbeiten (enthält auch Prüfung der Kartenversion).
2.	PIN-Typ prüfen	Wenn PIN-Typ = MRPIN.home, dann Fehler 4058.
3.	TUC_KON_019 „PIN ändern“	TUC_KON_019 { cardSession = ehcSession; workplaceId = ID des Arbeitsplatzes, an dem das                        Kartenterminal mit der eGK steht; pinRef = PinRef; }
4.	Ergebnis von TUC_KON_019 auswerten	Wenn pinResult = OK, dann Status.Result = OK, ChangePinResponse.PinResult = OK. Wenn Fehler 4063 oder Fehler 4082 oder pinResult=BLOCKED,       dann Status.Result = OK und ChangePinResponse.PinResult = BLOCKED. Wenn Fehler 4061 oder pinResult = REJECTED,       dann Status.Result = OK und       ChangePinResponse.PinResult = REJECTED       und ChangePinResponse.LeftTries = leftTries. Alle anderen Fehler werden als gematik-SOAP-FAULT mit dem Fehlercode 6212 zurückgegeben.

Tabelle 33: TAB_FM_AdV_032 Fehlercodes der Operation „ChangePin“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs und denen aus 6.3.3, 6.3.4 und 6.3.5 können folgende weitere Fehlercodes auftreten:
4058	Security	Error	Aufruf nicht zulässig
6212	Technical	Error	PIN-Operation fehlgeschlagen

[<=]

6.2.2.2 Operation UnblockPin

Diese Außenoperation dient dazu, eine gesperrte PIN der eGK zu entsperren.

AdV-A_2207 - Operation UnblockPin

Das Fachmodul AdV MUSS die Operation UnblockPin gemäß den folgenden Beschreibungen anbieten.

Tabelle 34: TAB_FM_AdV_033 Operation UnblockPin

Name	UnblockPin
Beschreibung	Diese Operation entsperrt die PIN.CH oder die PIN-QES des Versicherten oder die AMTS-Vertreter-PIN auf der eGK G2. Zulässig sind PIN.CH, alle MRPINs (außer MRPIN.home), PIN.QES und die AMTS-Vertreter-PIN. Der Versuch, MRPIN.home zu entsperren, führt zum Fehler 4058. Wenn die Operation für diese Kartenversion der eGK nicht unterstützt wird, beendet AdV die Operation mit Fehler 6210.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, auf der die PIN entsperrt werden soll.
	PinRef	Name der PIN gemäß Objektsystemspezifikation, die entsperrt werden soll.
	SetNewPin	Angabe, ob eine neue PIN gesetzt werden soll (true) oder ober die alte PIN weiterverwendet werden soll (false) (optional, Standard = false) PIN.AMTS_REP: true PIN.QES: false
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	PinResult	Status der PIN (OK, REJECTED, BLOCKED)
	LeftTries	Nur vorhanden, wenn PinStatus = REJECTED: Bei PIN.AMTS_REP enthält LeftTries die Anzahl der verbleibenden Versuche (1 .. 2) für die Versicherten-PIN. Bei allen anderen PINs und MRPINs enthält LeftTries die Anzahl der verbleibenden Versuche (1 .. 9) für die Eingabe des PUK der Versicherten-PIN.
Vorbedingung	keine
Nachbedingung	PinResult = OK: Die angegebene PIN ist entsperrt und hat auf der Karte ggf. einen neuen Wert. PinResult = REJECTED: Die PIN auf der Karte bleibt gesperrt. Die Anzahl der verbleibenden Versuche für die PUK-Eingabe der eGK wurde um 1 verringert (Bei PIN.AMTS_REP: Anzahl der verbleibenden Versuche für die Eingabe der Versicherten-PIN) PinResult = BLOCKED: Die PIN auf der Karte bleibt gesperrt. Für PIN.CH, PIN.QES oder eine MRPIN ist die Entsperrung durch den PUK nicht mehr möglich. Die PIN.AMTS_REP kann entsperrt werden, nachdem die Versicherten-PIN entsperrt und MRPIN.AMTS freigeschaltet wurde.

Tabelle 35: TAB_FM_AdV_034 Ablauf UnblockPin

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) abarbeiten (enthält auch Prüfung der Kartenversion). Dabei den Schritt „Zugriff protokollieren“ überspringen, da er die freigeschaltete PIN.CH voraussetzt.
2.	PIN-Typ prüfen	Wenn PIN-Typ = MRPIN.home, dann Fehler 4058.
3.	TUC_KON_021 „PIN entsperren“	TUC_KON_021 { cardSession = ehcSession; workplaceId = ID des Arbeitsplatzes, an dem das                        Kartenterminal mit der eGK steht; pinRef = PinRef; setNewPin;
4.	Ergebnis von TUC_KON_021 auswerten	Wenn FC = 4064 oder result = BLOCKED,       dann Status.Result = OK und                UnblockPinResponse.PinResult = BLOCKED. Wenn FC = 4062 oder result = REJECTED,       dann Status.Result = OK und                UnblockPinResponse.PinResult = REJECTED und                UnblockPinResponse.LeftTries = leftTries. Wenn result = OK,        dann Status.Result = OK,                UnblockPinResponse.PinResult = OK. Alle anderen Fehler werden als gematik-SOAP-FAULT mit dem Fehlercode 6212 zurückgegeben.

Tabelle 36: TAB_FM_AdV_035 Fehlercodes der Operation „UnblockPin“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs und denen aus 6.3.3, 6.3.4 und 6.3.5 können folgende weitere Fehlercodes auftreten:
4058	Security	Error	Aufruf nicht zulässig
6212	Technical	Error	PIN-Operation fehlgeschlagen

[<=]

6.2.2.3 Operation EnablePin

Die Außenoperation EnablePin dient dazu, einen abgeschalteten PIN-Schutz wieder einzuschalten. Z. B. besitzen die Anwendungen NFD und DPE je eine abschaltbare PIN. Die Referenz der gewünschten PIN muss gemäß der Bezeichnung der Objektsystemspezifikation [gemSpec_eGK_ObjSys] erfolgen.

AdV-A_2208 - Operation EnablePin

Das Fachmodul AdV MUSS die Operation EnablePin gemäß folgenden Beschreibungen anbieten.

Tabelle 37: TAB_FM_AdV_036 Operation EnablePin

Name	EnablePin
Beschreibung	Diese Operation dient dazu, den PIN-Schutz für eine Fachanwendung einzuschalten. Der Versuch, eine nicht-abschaltbare PIN anzuschalten (z. B. MRPIN.home oder MRPIN.NFD_READ), führt zur Fehlermeldung mit Fehlercode = 4058 bzw. Fehlercode = 4085. MRPIN.AMTS ist in G2.1 abschaltbar, in G2.0 jedoch nicht. Wenn die Operation für diese Kartenversion der eGK nicht unterstützt wird, beendet AdV die Operation mit dem Fehler 6210.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, auf die zugegriffen werden soll.
	PinRef	Name der PIN gemäß Objektsystemspezifikation, deren Schutzfunktion angeschaltet werden soll.
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	PinResult	Status der PIN (OK, REJECTED, BLOCKED)
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	PinResult = OK: Der Zugriffsschutz durch diese MRPIN wurde auf der Karte angeschaltet. PinResult = REJECTED: Der Zugriffsschutz durch diese MRPIN wurde nicht geändert. Die Anzahl der verbleibenden Versuche für die Eingabe der Versicherten-PIN wurde um 1 verringert. PinResult = BLOCKED: Der Zugriffsschutz durch diese MRPIN wurde nicht geändert. Die Versicherten-PIN ist gesperrt.

Tabelle 38: TAB_FM_AdV_037 Ablauf EnablePin

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) abarbeiten (enthält auch Prüfung der Kartenversion).
2.	PIN-Typ prüfen	Wenn PIN-Typ = MRPIN.home dann Fehler 4058. Wenn eGK eine G2.0-Karte und PIN-Typ = MRPIN.AMTS, dann Fehler 4058.
3.	TUC_KON_027 „PIN-Schutz ein-/ausschalten“	Aufruf von TUC_KON_027 { cardSession = ehcSession; pinRef = PinRef; enable = true }
4.	Ergebnis von TUC_KON_027 auswerten	Wenn pinResult = OK,       dann Status.Result = OK,                EnablePinResponse.PinResult = OK. Wenn pinResult = BLOCKED,       dann Status.Result = OK und                EnablePinResponse.PinResult = BLOCKED. Wenn pinResult = REJECTED,       dann Status.Result = OK und                EnablePinResponse PinResult = REJECTED und                EnablePinResponse LeftTries = leftTries. Alle anderen Fehler werden als gematik-SOAP-FAULT mit dem Fehlercode 6212 zurückgegeben.

Tabelle 39: TAB_FM_AdV_038 Fehlercodes der Operation „EnablePin“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs und denen aus 6.3.3, 6.3.4 und 6.3.5 können folgende weitere Fehlercodes auftreten:
4058	Security	Error	Aufruf nicht zulässig
6212	Technical	Error	PIN-Operation fehlgeschlagen

[<=]

6.2.2.4 Operation DisablePin

Der Zugriff auf die Daten von Anwendungen ist durch verschiedene PINs geschützt. Dieser Schutz kann für einige dieser PINs auf Wunsch des Versicherten ausgeschaltet werden, d. h. die jeweilige PIN wird in einen Zustand versetzt, als wäre sie permanent freigeschaltet. Der Zugriff auf die Daten der entsprechenden Anwendung setzt dann nur eine C2C-Authentisierung mit einer SM-B oder einem HBA voraus.

Die Außenoperation DisablePin dient dazu, die PINs, für die das entsprechende Zugriffsrecht definiert ist, abzuschalten.

AdV-A_2209 - Operation DisablePin

Das Fachmodul AdV MUSS die Operation DisablePin gemäß den folgenden Beschreibungen anbieten:

Tabelle 40: TAB_FM_AdV_039 Operation DisablePin

Name	DisablePin
Beschreibung	Diese Operation dient dazu, den PIN-Schutz für eine Fachanwendung partiell abzuschalten. Zulässige PIN-Referenzen für DisablePin sind bei eGK G2 z. B. MRPIN.NFD und MRPIN.DPE – allgemein, alle MRPINs, die die Kartenoperation DISABLE VERIFICATION REQUIREMENT zulassen. MRPIN.AMTS ist in G2.1 abschaltbar, in G2.0 jedoch nicht. Der Versuch, eine nicht ausschaltbare PIN auszuschalten, wird vom aufgerufenen TUC mit dem Fehlercode 4085 (Zugriffsregel nicht erfüllt) beantwortet. Für MRPIN.home ist der Aufruf nicht zulässig (Fehler 4058). Wenn die Operation für diese Kartenversion der eGK nicht unterstützt wird, beendet AdV die Operation mit dem Fehler 6210.
Aufruf-parameter
	Name	Beschreibung
	EhcHandle	Adressiert die eGK, von der die Daten gelesen werden sollen.
	PinRef	Name der PIN gemäß Objektsystemspezifikation, deren Schutzfunktion abgeschaltet werden soll
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	PinResult	Status der PIN (OK, REJECTED, BLOCKED)
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	PinResult = OK: Der Zugriffsschutz durch diese MRPIN wurde auf der Karte ausgeschaltet. PinResult = REJECTED: Der Zugriffsschutz durch diese MRPIN wurde nicht geändert. Die Anzahl der verbleibenden Versuche für die Eingabe der Versicherten-PIN wurde um 1 verringert. PinResult = BLOCKED: Der Zugriffsschutz durch diese MRPIN wurde nicht geändert. Die Versicherten-PIN ist gesperrt.

Tabelle 41: TAB_FM_AdV_040 Ablauf DisablePin

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	Aufruf vorbereiten	Sequenz gemäß AdV-A_2234 (Tabelle TAB_FM_AdV_059 „Aufruf vorbereiten“, Spalte „AdV“) abarbeiten (enthält auch Prüfung der Kartenversion).
2.	PIN-Typ prüfen	Wenn PIN-Typ = MRPIN.home dann Fehler 4058. Wenn eGK eine G2.0-Karte und PIN-Typ = MRPIN.AMTS, dann Fehler 4058.
3.	TUC_KON_027 „PIN-Schutz ein-/ausschalten“	Aufruf von TUC_KON_027 { cardSession = ehcSession; pinRef = PinRef; enable = false }
4.	Ergebnis von TUC_KON_027 auswerten	Wenn pinResult = OK, dann Status.Result = OK, PinResult = OK. Wenn result = BLOCKED,       dann Status.Result = OK und                DisablePinResponse.PinResult = BLOCKED. Wenn pinResult = REJECTED,       dann Status.Result = OK und                 DisablePinResponse.PinResult = REJECTED und                 DisablePinResponse.LeftTries = leftTries. Alle anderen Fehler werden als gematik-SOAP-FAULT mit dem Fehlercode 6212 zurückgegeben. Der Error-Trace enthält zusätzlich die konkrete Fehlermeldung des TUC_KON_027.

Hinweis: Es ist zulässig, den PIN-Typ nicht vorab zu prüfen, sondern den Antwortcode der Karte auszuwerten. Schritt 2 dient lediglich der Reduktion der Kartenzugriffe.

Tabelle 42: TAB_FM_AdV_041 Fehlercodes der Operation „DisablePin“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs und denen aus 6.3.3, 6.3.4 und 6.3.5 können folgende weitere Fehlercodes auftreten:
4058	Security	Error	Aufruf nicht zulässig
6212	Technical	Error	PIN-Operation fehlgeschlagen

[<=]

6.2.3 AdVManagement

Die Operationen dieser Schnittstelle dienen der Verwaltung eines LE-AdV-Terminals und dürfen nur von einem berechtigten AdV-Administrator aufgerufen werden, der sich gegenüber dem LE-AdV-Terminal authentisiert hat. Sie werden daher in einer eigenen Schnittstelle zusammengefasst.

Die Operationen ListAvailableUpdates und GetUpdates dienen dazu, Firmware-Updates zu erfragen und herunterzuladen, die der Hersteller des LE-AdV-Terminals beim Konfigurationsdienst der TI (KSR, Konfigurations- und Software Repository) bereitgestellt hat. Dabei dient der Konnektor als Vermittler. Das Format der Update-Pakete und die Schnittstellen zum KSR werden von [gemSpec_KSR] vorgegeben. Der LE-AdV-Terminal-Hersteller kann das Konzept der Firmware-Gruppen auf seine Update-Pakete anwenden. Zusätzlich zu den Nutzdaten liefert der KSR Metadaten in zwei XML-Files.

6.2.3.1 Operation ListAvailableUpdates

AdV-A_2211 - Operation ListAvailableUpdates

Das Fachmodul AdV MUSS die Operation ListAvailableUpdates gemäß den folgenden Beschreibungen anbieten.

Tabelle 43: TAB_FM_AdV_045 Operation ListAvailableUpdates

Name	ListAvailableUpdates
Beschreibung	Diese Operation liefert eine Liste der Update-Dateien, die am KSR für das LE-AdV-Terminal zur Verfügung stehen.
Aufruf-parameter
	Name	Beschreibung
	ProductVendorID	Hersteller des LE-AdV-Terminals, gemäß [gemSpec_KSR#Tab_KSR_028]
	ProductCode	Identifikator des LE-AdV-Terminals, Produktkürzel gemäß [gemSpec_KSR#Tab_KSR_029]
	HWVersion	ID der Hardware-Version gemäß [gemSpec_KSR#Tab_KSR_030] (falls vorhanden, sonst leer)
	FWVersion	Derzeitige Firmware-Version des LE-AdV-Terminals gemäß [gemSpec_KSR#Tab_KSR_031]
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	listUpdatesResponse	Liste der für den Clienttype verfügbaren Firmware-Updates, bestehend aus FirmwareGroupReleaseNotes und UpdateInformation gemäß [gemSpec_KSR].
Vorbedingung	keine
Nachbedingung	Die Informationen wurden an das LE-AdV-Terminal versendet.

Hinweis auf offenen Punkt: Die Prüfung von productVendorID und productCode obliegt dem KSR und erfolgt anhand von Zertifikaten (und Token) für das KSR Upload Interface. Die konkrete Verfahrensweise ist noch festzulegen.

Tabelle 44: TAB_FM_AdV_046 Ablauf ListAvailableUpdates

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 { $context.mandantId; $context.clientsystemId; $context.workplaceId; $context.userIdI } Wenn TUC_KON_000 einen Fehler liefert, dann bricht die Operation mit dem Fehler 6214 ab.
3.	TUC_KON_285 „UpdateInformationen für Produkt beziehen“	Aufruf von TUC_KON_285 „UpdateInformationen für Produkt beziehen“ { productVendorID = $ProductVendorID; productCode = $ProductCode; hwVersion = $HWVersion; fwVersion = $FWVersion; } Die Updateinformationen werden im XML-Document listUpdatesResponse geliefert. Wenn TUC_KON_285 einen Fehler liefert, dann bricht die Operation mit dem Fehler 6214 ab.
4.	Return	Die Antwort listUpdatesResponse des TUC_KON_285 und die Statusinformation in die ListAvailableUpdatesResponse einbetten

Tabelle 45: TAB_FM_AdV_047 Fehlercodes der Operation „ListAvailableUpdates“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
6214	Technical	Error	Administrative Operation fehlgeschlagen

[<=]

Die Datenstruktur listUpdatesResponse ist in [gemSpec_KSR] verbindlich festgelegt. Sie enthält unter anderem in den Elementen Firmware.Firmwarefiles und Firmware.Documentationfiles jeweils ein bis mehrere Dateinamen („Filename“), die als URLs für den Download der Dateien zu verwenden sind.

6.2.3.2 Operation GetUpdates

AdV-A_2212 - Operation GetUpdates

Das Fachmodul AdV MUSS die Operation GetUpdates gemäß folgenden Beschreibungen anbieten:

Tabelle 46: TAB_FM_AdV_048 Operation GetUpdates

Name	GetUpdates
Beschreibung	Diese Operation bewirkt den Download von Update-Dateien, die dem LE-AdV-Terminal über den KSR zu Verfügung stehen, durch den Konnektor. Zur detaillierten Spezifikation der Eingangs- und Ausgangsparameter siehe [gemSpec_KSR].
Aufruf-parameter
	Name	Beschreibung
	PackageURL	Dateiname inklusive absolutem Pfad; Entspricht den Elementen Firmware.Firmwarefiles bzw. Firmware.Documentationfiles des listAvailableUpdatesResponse, das dem LE-AdV-Terminal als Ergebnis der Operation ListAvailableUpdates (siehe Kapitel 6.2.3.1) zur Verfügung steht.
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning, ERROR), ggf. mit Fehlertrace
	FileDescription	Beschreibung der Datei
	FirmwareFile	Inhalt des UpdateFiles
Vorbedingung	keine
Nachbedingung	Die Update-Dateien liegen im AdV-Terminal vor.

Tabelle 47: TAB_FM_AdV_049 Ablauf GetUpdates

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 { $context.mandantId; $context.clientsystemId; $context.workplaceId; } Ein Fehler in TUC_KON_000 führt zum Abbruch der Operation.
3.	TUC_KON_286 „Paket für Produkt laden“	Aufruf von TUC_KON_286 „Paket für Produkt laden“{ packageIdentifier = $Path; } Wenn TUC_KON_286 einen Fehler liefert, dann bricht die Operation mit dem Fehler 6214 ab.
4.	Return	Die Antwort des TUC_KON_286 (Namen und Ablageorte der Dateien im Basiskonnektor) sowie die Statusinformation in die GetUpdatesResponse einbetten

Tabelle 48: TAB_FM_AdV_050 Fehlercodes der Operation „GetUpdates“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
6214	Technical	Error	Administrative Operation fehlgeschlagen

[<=]

6.2.3.3 Operation AdVReady

AdV-A_2213 - Operation AdVReady

Das Fachmodul AdV MUSS die Operation AdVReady gemäß den folgenden Beschreibungen anbieten.

Tabelle 49: TAB_FM_AdV_051 Operation AdVReady

Name	AdVReady
Beschreibung	Diese Operation prüft die Betriebsbereitschaft des Fachmoduls AdV. Dies umfasst: Test der Erreichbarkeit des Konnektors (ausgehend vom LE-AdV-Terminal eine TLS-Verbindung mit gegenseitiger Authentisierung aufbauen) Check, ob dem Mandanten eine SM-B zugeordnet ist, ob sie gesteckt ist ob sie freigeschaltet ist. Information über die Betriebsbereitschaft der zugeordneten Kartenterminals
Aufruf-parameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	CtId	Identifikator des Kartenterminals
	CtName	FriendlyName des Kartenterminals
	IsConnected	Verfügbarkeitsstatus des Kartenterminals; true, wenn die TLS-Verbindung zum Konnektor besteht
Vorbedingung	keine
Nachbedingung	Die Informationen wurden versendet.

Tabelle 50: TAB_FM_AdV_052 Ablauf AdVReady

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, dann bricht die Operation mit Fehler 4000 ab.
2.	Verfügbarkeit der Kartenterminals ermitteln	TUC_KON_252 „Liefere KT_Liste“ { workplaceId = $context.workplaceId; clientSystemId = $context. clientSystemId mandantId = $context. mandantId } Für jedes Kartenterminal aus dieser Liste sind die Werte für CtId, CtName und IsConnected in die Antwortnachricht AdVReadyResponse zu übertragen: CT_Info.CtId = CardTerminal.CtId; CT_Info.CtName = CardTerminal.Name CT_Info.IsConnected = CardTerminal.Connected Wenn TUC_KON_252 mit einem Fehler endet, dann bricht die Operation mit dem Fehler 6213 ab. Wenn nicht alle Kartenterminals betriebsbereit sind, dann erzeugt FM AdV die CT_Info, setzt Status.Result = Warning und trägt den Fehler 6213 in das Trace-Element von Status.Error ein. Wenn keines der Kartenterminals betriebsbereit ist, dann bricht die Operation mit dem Fehler 6213 ab.
3.	6.3.3 CardSession einer zulässigen SM-B ermitteln	Ermittelt smcSession einer zum Mandanten $context.mandantId gehörenden „SM-B für LE-AdV“ (Einzelheiten siehe Kap. 6.3.3). Wenn keine CardSession ermittelt werden kann, bricht die Operation bereits in 6.3.3 mit dem Fehler 6201 bzw. 6203 ab.
4.	Status der PIN.SMC ermitteln	Aufruf TUC_KON_022 „Liefere PIN-Status“ { cardSession = smcSession; workplaceId = $context.workplaceId; PIN.Ref = PIN.SMC; } Wenn TUC_KON_022 einen Fehler meldet, dann bricht die Operation mit dem Fehlercode 6202 ab. Wenn TUC_KON_022 den PINStatus VERIFIED meldet, dann Status.Result = OK VERIFIABLE, BLOCKED oder TRANSPORT_PIN meldet, dann Status = WARNING und Fehler 6202 in das Trace-Element von GERROR:Error eintragen.

Tabelle 51: TAB_FM_AdV_053 Fehlercodes der Operation „AdVReady“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
6201	Technical	Error	Dem Mandanten ist keine zulässige SM-B zugeordnet
6202	Technical	Error	SM-B nicht betriebsbereit (z. B. PIN.SMC nicht freigeschaltet)
6203	Technical	Error	Die konfigurierte SM-B steckt nicht.
6213	Technical	Error	Kartenterminal/s nicht betriebsbereit

[<=]

6.2.3.4 Operation VerifyPinSmc

AdV-A_2230 - Operation VerifyPinSmc

Das Fachmodul AdV MUSS die Operation VerifyPinSmc gemäß den folgenden Beschreibungen anbieten.

Tabelle 52: TAB_FM_AdV_066 Operation VerifyPinSmc

Name	VerifyPinSmc
Beschreibung	Diese Operation ruft die PIN-Eingabe für die implizit zugeordnete SM-B auf. Die Eingabe erfolgt am Kartenterminal des aufrufenden LE-AdV-Terminals.
Aufruf-parameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId; (siehe 6.4.3.1)
Rückgabe
	Name	Beschreibung
	Status	Ausführungsstatus der Operation (OK, Warning), ggf. mit Fehlertrace; siehe 5.7
	PinResult	Status der PIN (OK, REJECTED, BLOCKED, TRANSPORT_PIN) Bedeutung: OK: Die PIN ist freigeschaltet REJECTED: Die PIN-Eingabe war falsch. Die Anzahl der verbleibenden Versuche ist in LeftTries angegeben. BLOCKED: Die PIN ist gesperrt. TRANSPORT_PIN: Die PIN befindet sich noch im Transportzustand und muss vor der ersten Benutzung geändert werden.
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	Bei Erfolg: die SM-B ist freigeschaltet.

Tabelle 53: TAB_FM_AdV_067 Ablauf VerifyPinSmc

Nr.	Aufruf TUC oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, dann bricht die Operation mit Fehler 4000 ab.
2.	6.3.3 CardSession einer zulässigen SM-B ermitteln	Ermittelt smcSession einer zum Mandanten $context.mandantId gehörenden „SM-B für LE-AdV“ (Einzelheiten siehe Kap. 6.3.3). Wenn keine CardSession ermittelt werden kann, bricht die Operation bereits in 6.3.3 mit dem Fehler 6201 bzw. 6203 ab.
3.	SM-B freischalten	Aufruf TUC_KON_012 „PIN verifizieren“ { cardSession = smcSession; workplaceId =$context.workplaceId; PIN.Ref = PIN.SMC; verificationType = Sitzung } Wenn TUC_KON_012 keinen Fehler meldet, dann Status.Result = OK Wenn TUC_KON_012 einen Fehler liefert, dann bricht die Operation mit dem Fehlercode 6209 ab. Ergebnis der PIN-Verifikation wird in PinResult und ggf. LeftTries eingetragen.

Tabelle 54: TAB_FM_AdV_068 Fehlercodes der Operation „VerifyPinSmc“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
6201	Technical	Error	dem Mandanten ist keine zulässige SM-B zugeordnet
6203	Technical	Error	Die konfigurierte SM-B steckt nicht.
6209	Technical	Error	PIN-Freischaltung gescheitert

[<=]