gemSpec_MobKT_V2.13.0

PDF HTML Excel XML
gemSpec_MobKT_V2.13.0





Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation
Mobiles Kartenterminal
(inkl. Mini-AK und Mini-PS) 


    

     

      Version
      2.13.0
     

     

      Revision
      548770
     

     

      Stand
      02.10.2019
     

     

      Status
      freigegeben
     

     

      Klassifizierung
      öffentlich
     

     

      Referenzierung
      gemSpec_MobKT


Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Version
 Stand
 Kap./ Seite
 Grund der Änderung, besondere Hinweise
 Bearbeitung
1.0.0
 13.11.08
freigegeben
Die vorliegende Version setzt auf dieser Version, die Historie wurde gekürzt und kann ggf. in Version 1.0.0 nachgelesen werden.
 gematik
1.0.11
 13.08.12
grundlegend überarbeitet für den Online-Rollout (Stufe 1), zusätzlich formale Überarbeitung
 P77
1.0.12
 21.08.12
zur Abstimmung freigegeben
 PL P77
2.0.0
 15.10.12
Einarbeitung Gesellschafterkommentare
 P77
2.1.0
 12.11.12
Einarbeitung Kommentare aus der übergreifenden Konsistenzprüfung
 P77
2.2.0
 29.05.13
Einarbeitung Gesellschafterkommentare, Bieterfragen und interner Kommentare
 P 77
2.3.0
 06.06.13
freigegeben
 gematik
2.4.0
 15.08.13
Einarbeitung lt. Änderungsliste vom 08.08.13
 P 77
2.5.0
 21.02.14
Losübergreifende Synchronisation
 P77
2.6.0
 17.06.14
Streichung der Maßangaben in [TIP1-A_3702], konfigurierbares Druckmodul [TIP-A_4415], Anpassung Begriff „Verbindung“ [TIP-A_3754], Ergänzung Ausnahmeregelung für TOE Reset Pin [TIP1-A_3766] gemäß P11-Änderungsliste
 P77
2.7.0
 26.08.14
Anpassungen zu Cross-CV-Zertifikaten in #5.2.2.5, #7.4.3 und #10.1.7 gemäß P12-Änderungsliste (C_4560)
 gematik
2.8.0
 24.08.16
Anpassungen zum Online-Produktivbetrieb (Stufe 1)
 gematik
2.9.0
 28.10.16
Anpassungen gemäß Änderungsliste (Ergänzung TIP1-A_6706)
 gematik
2.10.0 21.04.17 11.1.4 3.3.4
 Anpassungen gemäß Änderungsliste
 gematik
2.10.1
 18.05.17
Redaktionelle Anpassungen (Lesbarkeit Abb)
 gematik
2.11.0 14.05.18
Anpassungen gemäß Änderungsliste P 15.2 und P 15.4
 gematik
2.11.1 05.06.18
Aktualisierung Angaben Deckblatt
 gematik
2.12.0 15.05.19
Einarbeitung P18.1
 gematik
Einarbeitung P20.1 (Unterstützung für G1+ eGK angepasst) gematik
2.13.0 02.10.19 freigegeben gematik

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Dieses Dokument spezifiziert das Mobile Kartenterminal inklusive der Schnittstelle zum Primärsystem zur Übertragung zwischengespeicherter Daten. In diesem Dokument wird die Einboxlösung, bei der die drei Komponenten Mini-AK, Mini-PS und Kartenterminal-Modul zusammen in einem Gerät umgesetzt sind, spezifiziert. Das Gesamtsystem ist konzipiert für den Einsatz außerhalb der Arztpraxis, z. B. bei Hausbesuchen, um abrechnungsrelevante Versichertenstammdaten (VSD) von einer Krankenversicherungskarte (KVK) oder einer elektronischen Gesundheitskarte (eGK) zu lesen und diese für Abrechnungszwecke an das Primärsystem (PS) des Leistungserbringers zu übertragen.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Mobilen Kartenterminals sowie Hersteller und Anbieter von Primärsystemen.

Es enthält zudem Informationen für die Leistungserbringer.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung im Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

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

1.4 Abgrenzung des Dokumentes

In diesem Dokument werden spezifische Anforderungen an Mobile Kartenterminals erhoben. Anforderungen, die neben dem mobilen Kartenterminal auch durch andere Produkttypen umgesetzt werden müssen, werden in übergreifenden Spezifikationen spezifiziert.

Festlegungen, welche im Schutzprofil (Protection Profile) des Mobilen Kartenterminals gemäß Common Criteria getroffen werden, werden hier nur angeführt, soweit es für das Verständnis erforderlich ist.

1.5 Methodik

1.5.1 Designansatz

Dieses Dokument spezifiziert die Komponente als Black Box, d. h. es beschreibt normativ die Außenschnittstellen (System- und Benutzerschnittstellen) und das äußere Verhalten der Komponente. Die innere Struktur wird durch dieses Dokument nicht geregelt. Um die komplexen Verhaltensmuster an den äußeren Schnittstellen besser beschreiben zu können, verwendet dieses Dokument eine modellhafte Beschreibung des inneren Verhaltens so weit, wie es für die verständliche Festlegung des Außenverhaltens erforderlich bzw. hilfreich ist.

Die Modellierung des inneren Verhaltens und der inneren Struktur dient auch als Hinweis auf Aspekte, deren Berücksichtigung bei der Sicherheitsevaluierung notwendig oder ratsam ist, um die Sicherheitsziele der Schutzprofile zu erfüllen. Die innere Struktur der realen Komponente bleibt jedoch vollständig eine herstellerseitige Definition, deren Schutzprofilkonformität allein der Hersteller im Rahmen seiner Komponentenevaluierung nachzuweisen hat (siehe auch Kapitel 2.1.2.1 Nachgewiesene Sicherheit).

1.5.2 Diagramme

Die Darstellung der Spezifikationen von Komponenten erfolgt auf der Grundlage einer durchgängigen Use-Case-Modellierung als

  • technische Use Cases (eingebundene Grafik sowie tabellarische Darstellung mit Vor- und Nachbedingungen),
  • Sequenz- und Aktivitätsdiagramme,
  • Klassendiagramme sowie
  • XML-Strukturen und Schnittstellenbeschreibungen.

1.5.3 Anforderungen

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

Sie werden im Dokument wie folgt dargestellt:

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

1.5.4 Rolle Administrator

In dieser Spezifikation wird der Begriff „Administrator“ verwendet. Hierunter ist keine Berufsbezeichnung zu verstehen, sondern die Rolle Administrator, welche zur Verwaltung der Komponente besondere Rechte und Aufgaben hat. Darüber, welche Person diese Rolle ausfüllt, werden keine Vorgaben gemacht.

1.5.5 Hinweis auf offene Punkte

Auf offene Punkte wird durch einen Text in nachfolgendem Format hingewiesen:

Beispiel Formatierung offener Punkte

2 Systemüberblick

2.1 Grundlagen

2.1.1 Einsatz des Mobilen Kartenterminals

Das Mobile Kartenterminal kommt hauptsächlich außerhalb der Arztpraxis, z. B. bei Hausbesuchen oder Behandlungen in Heimen und bei Notdiensten zum Einsatz. Es soll dem Leistungserbringer ermöglichen, außerhalb seiner Praxis die Versichertenstammdaten seiner Patienten zu Abrechnungszwecken zu erfassen sowie anzuzeigen.

Um Zugriff auf die geschützten Daten (geschützte VSD) einer eGK zu erlangen, muss diese mittels eines HBAs oder einer SMC-B (im Folgenden als „berechtigte Karten“ bezeichnet) freigeschaltet werden. Für den Zugriff auf die Daten einer KVK bzw. auf die ungeschützten VSD der eGK ist keine Freischaltung erforderlich. Während der Datenerfassung wird der Erfassungszeitpunkt protokolliert. Ein zwischengespeicherter Datensatz besteht aus den gelesenen VSD, dem zugehörigen Erfassungszeitpunkt sowie der Zulassungsnummer des Mobilen Kartenterminals. Auf Benutzerwunsch können VSD einer gesteckten Karte sowie zwischengespeicherte VSD am Mini-PS zur Anzeige gebracht werden. Schreibender Zugriff auf gesteckte Karten ist nur zum Zwecke der Protokollierung auf den Logging-Container der eGK zulässig. Weitere schreibende Zugriffe sind nicht erlaubt. Da die zwischengespeicherten Daten einen hohen Schutzbedarf besitzen und zu Abrechnungszwecken genutzt werden, müssen sie vor Zugriff durch Unbefugte, Manipulation und Missbrauch geschützt werden.

Um die zwischengespeicherten Daten für die Abrechnung mit den Krankenkassen zu nutzen, kann der Arzt sie auf sein Primärsystem (Praxisverwaltungssystem (PVS) bzw. Krankenhausinformationssystem (KIS)) übertragen (im Folgenden wird für beide nur noch der Begriff Primärsystem verwendet). Die Übertragung erfolgt über die so genannte Host-Schnittstelle, welche das CT-API-Protokoll [CT-API] zur Übertragung nutzt. Zwischengespeicherte Daten können auch ohne vorherige Übertragung an das Primärsystem gelöscht werden. Optional können die zwischengespeicherten VSD auch über einen integrierten oder extern angeschlossenen Drucker ausgedruckt werden.

Hersteller seien darauf hingewiesen, dass die mobilen Komponenten auch in Einsatzumgebungen verwendet werden können, die einem erhöhten Übertragungsrisiko für Infektionen, z. B. durch häufigen Hand- und Hautkontakt, ausgesetzt sind. Die regelmäßige Desinfektion der eingesetzten Geräte beim Leistungserbringer, dazu gehören auch die mobilen Komponenten, ist eine Maßnahme zur Verminderung des Übertragungsrisikos und zur Einhaltung entsprechender Vorgaben, z. B. denen des Arbeitsschutzgesetzes. Weiterführende Informationen sind unter anderem den folgenden Dokumenten zu entnehmen:

  • Anforderungen an die Hygiene bei der Reinigung und Desinfektion von Flächen des Robert-Koch-Institutes [RKI],
  • Technischen Regeln für Biologische Arbeitsstoffe im Gesundheitswesen und in der Wohlfahrtspflege [TRBA 250]
  • Hygieneleitfaden des Deutschen Arbeitskreises für Hygiene in der Zahnmedizin [DAHZ].

2.1.2 Sicherheit

Um Zugriff auf die geschützten Daten einer eGK zu erlangen, ist eine Freischaltung der eGK mittels einer berechtigten Karte erforderlich. Die Freischaltung erfolgt im Hintergrund mittels Card-to-Card-Authentisierung (C2C) zwischen berechtigter Karte und eGK. Die Ablaufsteuerung der C2C-Authentisierung übernimmt der Mini-AK.

Damit die berechtigte Karte eine eGK freischalten kann, muss die berechtigte Karte mittels PIN-Eingabe freigeschaltet werden. Hierfür muss das Mobile Kartenterminal über ein Display und ein PIN Pad verfügen. Die PIN-Eingabe muss direkt am Mobilen Kartenterminal erfolgen.

Das Mobile Kartenterminal stellt sicher, dass ein Abhören, Zwischenspeichern oder Manipulieren der PIN nicht möglich ist. Die PIN wird ausschließlich an die berechtigte Karte gesendet und verlässt das Mobile Kartenterminal nicht über andere Schnittstellen. Der Benutzer muss überprüfen können, ob die eingesetzten Komponenten Mobiles Kartenterminal, Mini-AK und Mini-PS, zugelassen, vertrauenswürdig, authentisch und integer sind. Manipulationen an den Komponenten müssen mit hoher Wahrscheinlichkeit vom Benutzer erkennbar sein. Die Dauer der Freischaltung einer berechtigten Karte ist zeitlich begrenzt. VSD werden für die Zwischenspeicherung mit einer berechtigten Karte verschlüsselt. Das Mobile Kartenterminal stellt sicher, dass vertrauliche Daten (personenbezogene Daten, medizinische Daten etc.) nicht unberechtigt ausgelesen oder verändert werden können.

2.1.2.1 Nachgewiesene Sicherheit

Die Sicherheit von dezentralen Komponenten der Telematikinfrastruktur wird durch CC-Evaluierung und Zertifizierung nachgewiesen. Für die Evaluierung des Mobilen Kartenterminals sind die im Schutzprofil (Protection Profile) [BSI-CC-PP-0052] definierten Sicherheitsziele maßgeblich. Alle Sicherheitsziele werden dort definiert, die umgesetzten Maßnahmen einer Herstellerlösung müssen mindestens diese Ziele nachweislich erfüllen.

Da die Schutzprofile mit der angeschlossenen Sicherheitsevaluierung den Kern der Sicherheitsumsetzung bilden, werden im Rahmen dieser Spezifikation Anforderungen an die Sicherheit nur so weit erfasst, wie sie Auswirkungen auf andere funktionale oder nichtfunktionale Anforderungen haben oder wie eine Umsetzung einer reinen Sicherheitsanforderung Belange der Interoperabilität berührt. Spezifikation und Schutzprofil bilden hier eine Einheit der Anforderungen an ein Mobiles Kartenterminal.

2.2 Zulassungsverfahren, Zertifikat

Für die Zulassung des Mobilen Kartenterminals sind sicherheitstechnische und funktionale Prüfungen erforderlich. Das Zulassungsverfahren unterliegt den Vorgaben und der Aufsicht der gematik. Die Erteilung einer Zulassung erfolgt durch die gematik oder von ihr bevollmächtigte Dritte.

Eine durch die gematik akkreditierte Prüfstelle konzentriert Herstellererklärungen, Nachweise und Teilzertifikate, bewertet die Eignung, erstellt einen zusammenfassenden Bericht und reicht diesen an die Zulassungsstelle weiter, welche die Vollständigkeit und die Korrektheit überprüft. Die normativen Vorgaben zur Zulassung sind im Dokument „Zulassung von dezentralen IT-Komponenten in der Telematikinfrastruktur (Mobile Kartenterminals)“ [gemZul_MobKT] beschrieben.

Im Zuge der funktionalen Zulassung wird lediglich die korrekte Funktionalität an den Geräteschnittstellen getestet (Black-Box-Test). Die Sicherheitsevaluierung bezieht sich jedoch auch auf die internen herstellerspezifischen Umsetzungen.

2.3 Komponentenmodell

Diese Spezifikation beschreibt das Mobile Kartenterminal als Einboxlösung, d. h. eine Lösung, die in einem einzigen, geschlossenen Gehäuse zusammengefasst ist.

Um das Gerät verständlicher in die Telematikinfrastruktur einordnen zu können, wird zur Beschreibung eine Modularisierung gemäß einer stationären Ausstattung eines Leistungserbringers gewählt: Konnektor, Kartenterminal und Primärsystem. Diese Modularisierung ist ein architektonischer Ansatz zur Beschreibung des Außenverhaltens des Geräts, basierend auf bekannten Strukturen. Eine reale, direkte Umsetzung in diese Module ist für das Mobile Kartenterminal als Einboxlösung nicht erforderlich.


Abbildung 1: Komponentenmodell (logische Sicht)

Im Folgenden werden die Module des Mobilen Kartenterminals im Überblick beschrieben. Details zu den einzelnen Punkten sind dem normativen Teil zu entnehmen.

2.3.1 Kartenterminal-Modul

Das Kartenterminal-Modul bildet die logische Einheit, die für die physikalische Interaktion mit den Karten sowie die Nutzerinteraktion bei Kartenoperationen (Beispiel PIN-Eingabe) zuständig ist. Gemäß dem hier vorgestellten Komponentenmodell entspricht dieses Modul dem eHealth-Kartenterminal.

2.3.2 Mini-Anwendungskonnektor

Der Mini-AK ist eine Minimalversion des Anwendungskonnektors, dessen Funktionalität auf das für das mobile Szenario Notwendige beschränkt ist. Zu seinen Aufgaben zählen:

  • die Durchsetzung der Abläufe entsprechend der Spezifikation,
  • die C2C-Authentisierung,
  • die Karten- und Kartenterminalverwaltung,
  • die Display-Ansteuerung des Kartenterminal-Moduls,
  • das Melden von Events (z. B. Karte gesteckt) an das Mini-PS,
  • das Melden von Fehlern,
  • die Ver- und Entschlüsselung,
  • die Dekomprimierung von Daten.

Es ist zu beachten, dass die im Mini-AK durchgeführte X.509-Zertifikatsprüfung aufgrund der eingeschränkten Fähigkeiten des Mobilen Kartenterminals stark von der Prüfung in anderen Telematikinfrastruktur-Komponenten abweicht. Die Zertifikatsprüfung umfasst ausschließlich die Gültigkeits- und Rollenprüfung. Eine mathematische Prüfung bzw. eine Prüfung bzgl. des Vertrauensraums findet nicht statt.

2.3.3 Mini-Primärsystem

Das Mini-PS ist eine Minimalversion eines Primärsystems. Aus logischer Sicht liest das Mini-PS analog zum stationären Primärsystem (PS) Daten aus. Daher ist das Mini-PS aus logischer Sicht auch der Speicherort der zwischenzuspeichernden Daten und somit für den Schutz und die Übertragung der Daten an das Primärsystem zuständig. Neben dem Zwischenspeichern und Übertragen von Daten ist die Hauptaufgabe des Mini-PS die Benutzerinteraktion. Ereignisse werden an das Mini-PS gemeldet, welches in weiterer Folge den Anwender über das Ereignis informiert. Es bietet eine Benutzerschnittstelle zur Interaktion. Abläufe wie z. B. „VSD lesen“ werden über das Mini-PS gestartet.

2.3.4 Management-Modul

Um das Mobile Kartenterminal konfigurieren zu können, ist ein Management-Modul erforderlich. Über dieses können alle Aspekte, auf die ein Administrator oder ein normaler Anwender Einfluss nehmen können muss, erreicht werden. Beispiele hierfür sind das Einspielen einer neuen Firmware und das Einstellen der Systemzeit.

2.3.5 Systemuhr

Das Mobile Kartenterminal muss für die Protokollierung von Zugriffen über eine eigene Systemuhr verfügen.

2.3.6 Erweitertes Display

Im Gegensatz zu einem stationären eHealth-Kartenterminal, welches ein Display vorrangig zur Benutzerführung während der PIN-Eingabe benötigt, müssen an dem Mobilen Kartenterminal umfangreichere Daten angezeigt werden können. Es wird daher ein entsprechend dimensioniertes Grafikdisplay benötigt, für welches zur Abgrenzung der Begriff des „erweiterten Displays“ eingeführt wird.

2.3.7 Drucker

Um VSD einer Karte oder zwischengespeicherte VSD auszudrucken, wird ein Drucker benötigt. Dieser ist in allen Fällen optional.

2.3.8 Ansteuerung externer Komponenten

Die technische Ausprägung der Schnittstelle, über die eine externe Komponente an das Mobile Kartenterminal angebunden wird, ist herstellerspezifisch. Geräte verschiedener Hersteller müssen nicht interoperabel sein. Unter externen Komponenten sind Peripheriegeräte des Mobilen Kartenterminals zu verstehen, wie z. B. ein Drucker oder gegebenenfalls das externe erweiterte Display.

2.3.9 Technische Ausprägungen

2.3.9.1 Einboxlösung

Diese Spezifikation definiert ausschließlich die Anforderungen an eine Einboxlösung, in der die in den Kapiteln 2.3.1 bis 2.3.3 (Mini-AK, Kartenterminal-Modul und Mini-PS) beschriebenen Module eine physikalische Einheit bilden (d. h. sie sind von einem gemeinsamen Gehäuse umgeben).

2.3.9.2 Mehrkomponenten-Lösung

Bei einer Mehrkomponentenlösung bilden die Komponenten keine physikalische Einheit, sondern sind auf getrennten Geräten umgesetzt. Dies bedeutet, dass die Komponenten über externe Schnittstellen miteinander verbunden werden müssen.

2.4 Einbettung in das Anwendungsumfeld

Es ergeben sich folgende Schnittstellen des Mobilen Kartenterminals mit seinem Umfeld:

  • Kartenschnittstellen in Form von ID-1-Kontaktiereinheiten, die sich zur Aufnahme von KVKs, eGKs und HBAs eignen. Um den HBA und die Karte des Versicherten (KVK oder eGK) gleichzeitig stecken zu können, verfügt das Mobile Kartenterminal über mindestens 2 ID-1-Kontaktiereinheiten. Das Kartenterminal soll auch Plugin-Karten im ID-000-Format aufnehmen. Plugin-Karten können auch mittels Adapter in einen ID-1-Slot eingebracht werden.
  • Das Userinterface bildet eine weitere Schnittstelle. Es ist hauptsächlich auf den Leistungserbringer ausgerichtet, da der Versicherte, abgesehen vom Stecken und Ziehen seiner eGK, nicht in Anwendungsfälle des Mobilen Kartenterminals involviert ist. Das Userinterface bietet die Möglichkeit, Vorgänge zu starten und zu steuern, sich über Fehlerzustände und Ereignisse zu informieren sowie Konfigurationseinstellungen vorzunehmen. PINs werden direkt am PIN Pad des Mobilen Kartenterminals eingegeben.
  • Die Host-Schnittstelle dient zur Übertragung der im Mini-PS zwischengespeicherten Daten an das stationäre Primärsystem, wobei die zwischengespeicherten Daten unverändert an das stationäre PS übertragen werden. Es kommt das CT-API-Protokoll [CT-API] zum Einsatz sowie das in Kapitel 11 beschriebene Übertragungsprotokoll an der Host-Schnittstelle zur Übertragung zwischen Mobilem Kartenterminal und Primärsystem. Eine Übertragung der Daten ist erst nach erfolgreicher Authentifizierung des Arztes möglich. Daten dürfen auch mittelbar über eine Dockingstation an das PS übertragen werden. Die Anforderungen an die Host-Schnittstelle müssen in diesem Fall von der Dockingstation umgesetzt werden.

2.5 Standards und Normen

Die Spezifikation basiert auf der Normenreihe ISO/IEC 7816 für die Chipkartenansteuerung und Chipkartenkommunikation [ISO7816-2], [ISO7816-3] sowie [ISO7816-10], [ISO7816-12].

3 Allgemeine Anforderungen

Dieses Kapitel definiert Anforderungen, die für das Mobile Kartenterminal als Ganzes sowie für alle in dieser Spezifikation spezifizierten Module (Kartenterminal-Modul, Mini-Anwendungskonnektor, Mini-Primärsystem etc.) verbindlich sind. Dies umfasst sowohl die funktionalen und nicht-funktionalen Anforderungen als auch die Sicherheitsanforderungen.

TIP1-A_3738 - Definition Einboxlösung

Der Hersteller des Mobilen Kartenterminals MUSS bei einer Einboxlösung des Mobilen Kartenterminals das Kartenterminal-Modul, den Mini-AK und das Mini-PS innerhalb desselben Gehäuses realisieren, um diese als physikalische Einheit abzubilden.

[<=]

Das erweiterte Display kann extern realisiert werden.

Dies bedeutet auch, dass Anforderungen, die an mehrere Komponenten gestellt werden, im Rahmen einer Einboxlösung einmalig umgesetzt werden können, wobei diese einmalige Umsetzung durch alle Komponenten genutzt werden kann (z. B. Systemuhr, Managementschnittstelle, Firmware Update, Fehleranzeige, Stromquelle, Prüfzeichen, ...).

3.1 Logische und Funktionale Trennung

Damit es nach einer erfolgreichen Evaluierung eines Mobilen Kartenterminals auch weiterhin möglich bleibt, Software oder Daten, die keinen direkten Einfluss auf Sicherheitsfunktionen des Evaluierungsgegenstands (EVG) aufweisen, ohne eine Re-Evaluierung definiert auszutauschen, hinzuzufügen oder zu erweitern, ist eine Separation der Komponenten des EVG anzuraten.

Implementiert der Hersteller keine bzw. nicht ausreichende Separationsmechanismen, so ist bei bestimmten Update-Arten von einer aufwändigen Re-Evaluierung des entsprechenden EVGs auszugehen. Die Separation dient also der Trennung zwischen ausführbarem Code des EVG, welcher Sicherheitsfunktionen umsetzt, und zusätzlichem ausführbarem Code auf dem Mobilen Kartenterminal, welcher keine Sicherheitsfunktionen umsetzt.

Die Wahl der Separationsmechanismen steht dem Hersteller frei und muss in den Sicherheitsvorgaben für den EVG beschrieben und als solcher evaluiert werden. Aus diesen Sicherheitsvorgaben ergibt sich auch, welche Update-Arten bei welchen Separationsmechanismen eine Re-Evaluierung des EVG erfordern und wie aufwändig diese Re-Evaluierung ausfällt.

Die funktionale und logische Trennung bezieht sich daher nicht auf die physische Ausprägung (d. h. sie schließt keine gemeinsame Nutzung von Hardwarekomponenten, Klassen oder Bibliotheken aus).

3.2 Integration in die Telematikinfrastruktur

Es ist keine Online-Anbindung bzw. keine Anbindung an einen stationären Konnektor vorgesehen.

3.3 Physikalische Anforderungen

3.3.1 EMV-Prüfung

Seit 01.01.1996 ist die EU-Richtlinie EMV (89/336/EWG) auf elektrische und elektronische Produkte anzuwenden, welche durch die Richtlinie (2004/108/EG) ersetzt wurde.

TIP1-A_5014 - EMV-Prüfung

Das mobile Kartenterminal MUSS die Anforderungen der gültigen EU-Richtlinie über die elektromagnetische Verträglichkeit erfüllen.

[<=]

In Deutschland ist die EU-Richtlinie EMV umgesetzt durch das EMVG (Gesetz über die elektromagnetische Verträglichkeit von Geräten). Die CE-Kennzeichnung erfordert die Einhaltung des EMVG.

Der Nachweis der Einhaltung der Schutzanforderung erfordert die Prüfung durch ein akkreditiertes Prüflabor. Die Ergebnisse sind durch geeignete Prüfprotokolle nachzuweisen.

3.3.2 Vibrationstest

TIP1-A_4947 - Vibrationstests I

Jede physische Komponente des Mobilen Kartenterminals MUSS den folgenden Normen entsprechen:

  • Schwingen DIN EN 60068 T2-6/6.90
  • Vibration DIN EN 60068 T2-27/8.29
  • Dauerschock DIN EN 60068 T2-29/8.29
[<=]

TIP1-A_5373 - Vibrationstests II, Falltest

Jede physische Komponente des Mobilen Kartenterminals SOLL der folgenden Norm entsprechen:

  • Falltest DIN EN 60068-2-32
[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung verzichtet werden.

3.3.3 Klima

TIP1-A_3805 - Umweltanforderungen für den Einsatz in mobilen Szenarien bei Lagerung

Jede physische Komponente des Mobilen Kartenterminals DARF durch eine Lagertemperatur von -20°C bis 60°C und einer relativen Luftfeuchtigkeit von 5% bis 95% NICHT defekt werden.

[<=]

TIP1-A_3712 - Umweltanforderungen für den Einsatz in mobilen Szenarien

Das Mobile Kartenterminal MUSS mindestens im Bereich der Raumtemperatur von 0°C bis 40°C funktionieren.

[<=]

Geprüft wird nach der Normenreihe DIN IEC 68.

3.3.4 Stromversorgung

TIP1-A_3802 - Mobile Szenarien: Interne Stromquelle

Das Mobile Kartenterminal MUSS über eine interne Stromquelle verfügen, die austauschbar oder wiederaufladbar sein MUSS.

[<=]

Das Mobile Kartenterminal kann zusätzlich den Betrieb über eine externe Stromquelle unterstützen.

TIP1-A_7033 - Austauschbare Pufferbatterien

Verbaut der Hersteller des mobilen Kartenterminals nicht wiederaufladebare Batterien im Mobilen Kartenterminal, so SOLL das Mobile Kartenterminal deren Austauschbarkeit durch den Benutzer ermöglichen.

Hierzu zählen auch interne Stromquellen wie Pufferbatterien gemäß [TIP1-A_4412] oder [TIP1-A_3709].

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung verzichtet werden.

TIP1-A_7034 - Stromloser Zustand – Verlust der Uhrzeit und Übertragung von Daten

Hat das Mobile Kartenterminal durch einen stromlosen Zustand beim Wechsel der Pufferbatterie gemäß [TIP1-A_7033] die eingestellte Uhrzeit verloren und sind im Zwischenspeicher des Mobilen Kartenterminals VSD gemäß [VSDM-A_2876] gespeichert, MUSS das mobile Kartenterminal ausschließlich die Übertragung der VSD über die Hostschnittstelle oder das Löschen der im Zwischenspeicher gespeicherten VSD erlauben. Unabhängig davon MUSS das Mobile Kartenterminal einen Werksreset ermöglichen. Das mobile Kartenterminal MUSS den Benutzer auf diesen Umstand hinweisen.

[<=]

TIP1-A_7035 - Stromloser Zustand – Einstellen der Uhrzeit

Hat das mobile Kartenterminal durch einen stromlosen Zustand beim Wechsel der Pufferbatterie gemäß [TIP1-A_7033] die eingestellte Uhrzeit verloren und sind im Zwischenspeicher des Mobilen Kartenterminals keine VSD gespeichert, MUSS das Mobile Kartenterminal das Lesen von Daten einer eGK verhindern bis die Uhrzeit durch den Administrator eingestellt wurde. Das mobile Kartenterminal MUSS den Benutzer auf diesen Umstand hinweisen.

[<=]

TIP1-A_3847 - Mobile Szenarien: Betriebsdauer mittels interner Stromquelle

Das Mobile Kartenterminal SOLL mit seiner internen Stromquelle den Betrieb mindestens 6h aufrecht erhalten können.

[<=]

TIP1-A_3803 - Mindestdauer der Standbyzeit für Mobile Kartenterminals

Das Mobile Kartenterminal SOLL eine Standbyzeit von mindestens 300h sicherstellen.

[<=]

3.3.5 Transportierbarkeit

TIP1-A_3713 - Transportierbarkeit für den Einsatz in mobilen Szenarien

Das Mobile Kartenterminal MUSS in jeder Ausprägung weniger als 0,7 Kilo wiegen und ein Volumen kleiner als 1 dm3 aufweisen.

[<=]

3.3.6 Schnittstelle zum Primärsystem

TIP1-A_3689 - Lokaler Anschluss zur Übertragung an das HOST-System

Das Mobile Kartenterminal MUSS über mindestens einen lokalen Anschluss zur Übertragung der zwischengespeicherten Daten an das Primärsystem verfügen.

[<=]

TIP1-A_3690 - mobile Szenarien: Datenübertragung an das Primärsystem mittels Dockingstation

Die Dockingstation des Mobilen Kartenterminals MUSS, wenn das Mobile Kartenterminal diese zur Übertragung der zwischengespeicherten Daten benötigt, über einen lokalen Anschluss an das Primärsystem verfügen.

[<=]

3.3.7 Gehäuse

3.3.7.1 Versiegelung

Aufgrund des hohen Schutzbedarfs der verarbeiteten Daten und der hohen Anforderungen an die zuverlässige Durchführung der Abläufe müssen entsprechend wirkungsvolle Mechanismen zum Schutz der Integrität des Mobilen Kartenterminals angewendet werden. Die entsprechenden Anforderungen an das Gehäuse und dessen Versiegelung sind dem PP [BSI-CC-PP-0052] zu entnehmen.

3.3.7.2 Prüfzeichen

Die Berechtigung zur Nutzung des Prüfzeichens durch den Hersteller erfolgt mit der Zulassung der Geräte durch die gematik. Im Rahmen des Zulassungsverfahrens werden den Herstellern die beiden Versionen des gematik-Prüfzeichens im Encapsulated-PostScript-Format (EPS) zur Verfügung gestellt. Das Prüfzeichen bietet einen Wiedererkennungswert für zugelassene Mobile Kartenterminals, es sind keine Sicherheitsfunktionen damit verbunden.

Die Farbgebung des Prüfzeichens ist vierfarbig CMYK:

  • für den Grün-Anteil:    C40, M0, Y60, K0
  • für den Rot-Anteil:    C0, M100 , Y100 , K0
  • für den Gelb-Anteil:    C0 , M20 , Y100 , K0

Die entsprechenden Pantone-Farben aus der Palette PANTONE(R) process coated EURO sind:

  • für den Grün-Anteil:    Pantone DE 286-4 C
  • für den Rot-Anteil:    Pantone DE 73-1 C
  • für den Gelb-Anteil:    Pantone DE 5-1 C




Abbildung 2: PIC_mobKT_0001 – gematik Prüfzeichen

TIP1-A_4406 - Spezifizierung gematik-Prüfzeichen

Das Mobile Kartenterminal MUSS auf dem Gehäuse über ein gematik-Prüfzeichen verfügen, welches nicht unbeschadet ablösbar sein darf.

[<=]

TIP1-A_4408 - Optische Gestaltung des Prüfzeichens

Der Hersteller des Mobilen Kartenterminals MUSS sicherstellen, dass die optische Gestaltung des Prüfzeichens einer der beiden Varianten aus Abbildung [PIC_mobKT_0001] entspricht.

[<=]

TIP1-A_4267 - mobile Szenarien: Aufbringung eines inversen Prüfzeichens

Das Mobile Kartenterminal KANN das gematik Prüfzeichen in inverser Form (Weiß auf schwarzem Untergrund) tragen.

[<=]

TIP1-A_3758 - Mindestgröße des Prüfzeichens

Der Hersteller des Mobilen Kartenterminals MUSS das gematik Prüfzeichen an dem mobilen Kartenterminal mit folgende Mindestgröße verwenden: 8 mm Höhe.

[<=]

TIP1-A_3757 - Einhalten des Seitenverhältnisses des Prüfzeichens

Der Hersteller des Mobilen Kartenterminals MUSS das gematik-Prüfzeichen in dem vorgegebenen Seitenverhältnis gemäß der durch die gematik bereitgestellten EPS-Datei verwenden.
[<=]

TIP1-A_4407 - Anbringung gematik-Prüfzeichen

Der Hersteller des Mobilen Kartenterminals MUSS das gematik-Prüfzeichen an einer während der PIN-Eingabe für den Benutzer gut sichtbaren Stelle am mobilen Kartenterminal aufbringen.

[<=]

3.4 Betriebsanforderungen

3.4.1 Wartbarkeit

Das Mobile Kartenterminal wird in der Regel in einem Umfeld mit geringer Betriebsführungsintensität betrieben. Es ist daher wartungsarm auszulegen. Das Mobile Kartenterminal hat einen, bis auf das Einspielen von Firmware Updates sowie ein eventuelles Nachladen oder Austauschen der internen Stromquelle, wartungsfreien Betrieb zu erlauben.

3.4.2 Anzeige des Betriebszustandes

TIP1-A_3696 - Mobile Szenarien, Betriebsbereitschaft: Anzeige der Betriebsbereitschaft im Rahmen der Benutzerführung

Das Mobile Kartenterminal MUSS seine Betriebsbereitschaft anzeigen.

[<=]

Eine Anzeige des Standby-Modus ist nicht erforderlich.

TIP1-A_4260 - Mobile Szenarien: Anzeige der Fehlerzustände

Das Mobile Kartenterminal MUSS Fehlerzustände, die im Rahmen der Betriebsbereitschaft auftreten, anzeigen.

[<=]

3.4.3 Betriebssicherheit

Das Mobile Kartenterminal darf nur in den Verkehr gebracht werden, wenn Sicherheit und Gesundheit von Anwendern nicht gefährdet werden. Dazu muss der Anwender der Produkte über alle Sicherheitsinformationen zum Produkt informiert werden. Auch muss der Hersteller den Lebenszyklus seines Produktes beobachten und bei bekannt gewordenen Mängeln die zuständige Behörde informieren und gegebenenfalls einen Rückruf einleiten. Das Mobile Kartenterminal muss den Anforderungen aus dem Produktsicherheitsgesetz (PRODSG) [PRODSG] entsprechen. Darüber hinaus kann die Betriebssicherheit des Mobilen Kartenterminals durch ein Prüfzeichen (z. B. VDE, GS) nachgewiesen werden.

3.4.4 Zuverlässigkeit

Zuverlässigkeitsaspekte sind Differenzierungsmerkmale verschiedener Produkte und Hersteller. Durch die hohe Anzahl von Steckzyklen und die häufige Nutzung unterliegen die Mobilen Kartenterminals im Gesundheitssystem anderen Beanspruchungen als Consumer-Geräte. Dies ist zu berücksichtigen.

TIP1-A_3800 - Mobile Szenarien: Haltbarkeit der Geräte

Das Mobile Kartenterminal MUSS bei 24/7-Betrieb eine Mean Time Between Failures (MTBF) von mindestens 3 Jahren bzw. 100.000 Steckzyklen gewährleisten.

[<=]

TIP1-A_3801 - Mobile Szenarien: Zuverlässigkeitsprognose der Geräte

Der Hersteller des Mobilen Kartenterminals MUSS eine nachvollziehbare Zuverlässigkeitsprognose für das Mobile Kartenterminal mit Darstellung der zugrunde gelegten Ausfallraten und Stückzahlen der Bauelemente und der anderen zuverlässigkeitsrelevanten Elemente (Lötstellen, Leiterbahnen, etc.) bereitstellen. Hat der Hersteller in dieser Zuverlässigkeitsprognose Schätzungen verwendet, MUSS er diese erläutern.

[<=]

3.4.5 Fehlertoleranz

TIP1-A_4275 - Überbrücken von Fehlerzuständen bei der Kartenkommunikation

Das Mobile Kartenterminal MUSS transiente bzw. überbrückbare Fehlerzustände bei der Kartenkommunikation erkennen und automatisch bereinigen.

[<=]

Insbesondere, aber nicht ausschließlich, bezieht sich dies auf die Resynchronisation der Kartenkommunikation.

TIP1-A_3698 - Anzeige von Bedienfehlern und ungültigen Eingaben am Mobilen KT

Das Mobile Kartenterminal MUSS Bedienfehler und ungültige Eingaben anzeigen oder ignorieren.

[<=]

TIP1-A_3711 - Blockieren von ungültigen und fehlerhaften Kommandos

Das Mobile Kartenterminal MUSS fehlerhafte oder ungültige Kommandos erkennen und abweisen.

[<=]

3.4.6 Auslieferungszustand

TIP1-A_3766 - mobKT Werkszustand - Kennwörter

Das Mobile Kartenterminal MUSS im Auslieferungszustand leere/ungesetzte Kennwörter besitzen. Wird zur Umsetzung des weiteren Werksreset-Mechanismus gemäß [TIP1-A_5427] die im Protection Profile [BSI-CC-PP-0052] beschriebene und im Auslieferungszustand bereits gesetzte TOE Reset PIN implementiert, bleibt diese hiervon unberührt.

[<=]

TIP1-A_3767 - mobKT Werkszustand - erlaubte Funktion

Das Mobile Kartenterminal MUSS im Auslieferungszustand sicherstellen, dass ohne vorheriges Setzen des Administratorenpasswortes keine weitere Funktion angeboten wird.
[<=]

TIP1-A_3870 - mobKT im Werkszustand erlaubte Funktion

Das Mobile Kartenterminal MUSS sicherstellen, dass es im Auslieferungszustand, also wenn das Administratorenpasswort noch nicht gesetzt ist, nicht möglich ist, Daten einer eGK einzulesen und zu speichern.

[<=]

3.4.7 Werksreset

TIP1-A_4954 - Möglichkeit zum Werksreset

Das Mobile Kartenterminal MUSS über eine Möglichkeit zum Werksreset verfügen.

[<=]

TIP1-A_3761 - Definition Werksreset

Das Mobile Kartenterminal MUSS bei einem Werksreset die Konfigurationen wieder in den Auslieferungszustand setzen, nicht jedoch die Firmware und die Firmware-Gruppe.

[<=]

TIP1-A_4955 - Werksreset Administrator

Das Mobile Kartenterminal MUSS die Möglichkeit zum Werksreset gemäß [TIP1-A_4954] ausschließlich dem Administrator zur Verfügung stellen.

[<=]

TIP1-A_5427 - Weiterer Mechanismus für Werksreset

Der Hersteller des Mobilen Kartenterminals MUSS für den Werksreset neben [TIP1-A_4955] einen weiteren Mechanismus zur Durchführung anbieten, welcher die Arbeitsabläufe beim Leistungserbringer nur minimal unterbricht.

[<=]

TIP1-A_5428 - Authentisierung für weiteren Werksreset Mechanismus

Das Mobile Kartenterminal MUSS sicherstellen, dass der Mechanismus gemäß [TIP1-A_5427] ausschließlich nach Authentisierung durch eine Kombination aus Username und Passwort oder einen mindestens gleich starken Mechanismus ausgeführt werden kann.

[<=]

TIP1-A_5429 - Dokumentation Werksreset Mechanismus

Der Hersteller des Mobilen Kartenterminals MUSS die Umsetzung von [TIP1-A_5427] in der Benutzerdokumentation beschreiben und die aus Sicht des Anwenders notwendigen Schritte verständlich darstellen.

[<=]

TIP1-A_5430 - Ausführung eines Werksreset ohne Authentisierung

Der Hersteller des Mobilen Kartenterminals KANN einen zusätzlichen Werksreset-Mechanismus ohne vorherige Authentisierung implementieren (d.h. der Werksreset ist von jeder Person ausführbar).

[<=]

TIP1-A_5431 - Aktivierung/Deaktivierung des Werksreset ohne Authentisierung

Falls der zusätzliche Werksreset-Mechanismus ohne Authentisierung gemäß [TIP1-A_5430] implementiert wird, MUSS das Mobile Kartenterminal ausschließlich dem Administrator die Aktivierung und Deaktivierung dieses Mechanismus ermöglichen.
[<=]

TIP1-A_5432 - Standardeinstellung Werksreset ohne Authentisierung

Falls der zusätzliche Werksreset-Mechanismus ohne Authentisierung gemäß [TIP1-A_5430] implementiert wird, MUSS das Mobile Kartenterminal diesen Mechanismus als Standardeinstellung deaktivieren.

[<=]

Wenn der Werksreset-Mechanismus ohne vorherige Authentisierung implementiert und aktiviert ist, kann der Anwender im Einzelfall wählen, welchen der Werksreset-Mechanismen (authorisiert oder unauthorisiert) er ausführen möchte.

TIP1-A_3869 - Werksreset nicht dauerhaft unausführbar

Das Mobile Kartenterminal DARF durch einen Werksreset bei sachgemäßer Handhabung und ohne technisches Versagen NICHT einen Zustand annehmen, der einen erneuten Werksreset unausführbar macht. Der Auslieferungszustand für das Administratorenpasswort gemäß [TIP1-A_3767] bleibt hiervon unberührt.

[<=]

Die Umsetzung des Werksreset-Mechanismus ist herstellerspezifisch.

TIP1-A_3748 - mobile Szenarien: Löschen des Zwischenspeichers bei Rücksetzen auf Werkseinstellungen

Das Mobile Kartenterminal MUSS sicherstellen, dass beim Rücksetzen des Mobilen Kartenterminals in den Auslieferungszustand alle Daten im Zwischenspeicher gelöscht werden.

[<=]

3.4.8 Firmware Update

TIP1-A_3743 - Sicherer Firmware-Update-Mechanismus

Das Mobile Kartenterminal MUSS über eine gesicherte Update-Möglichkeit seiner Firmware verfügen.

[<=]

TIP1-A_3744 - Erkennung von Übertragungsfehlern während des Firmware Updates

Das Mobile Kartenterminal MUSS beim Firmware Update selbständig Übertragungsfehler und nicht authentische Übertragungen erkennen.

[<=]

TIP1-A_3839 - Manipulationsgeschützte Speicherung des Sicherheitsattributes für die Sicherung des FW- Updates

Das Mobile Kartenterminal MUSS das zur Erkennung von Übertragungsfehlern und nicht authentischen Übertragungen notwendige Sicherheitsattribut für Firmware Updates in einem manipulationsgeschützten Bereich des Gerätes ablegen.

[<=]

Das Verwaltungsverfahren muss mindestens den Anforderungen entsprechen, die in der Sicherheitsevaluierung und dem zugehörigen Protection Profile sowie den Sicherheitszielen zu Grunde gelegt werden.

TIP1-A_3747 - Mobile Szenarien, Firmware Update: Zulässige Verfahren zur Sicherung des FW-Updates

Das Mobile Kartenterminal MUSS sicherstellen, dass die Aktualisierung der Firmware mittels asymmetrischer kryptographischer Verfahren geschützt wird.

[<=]

Festlegungen zu zulässigen kryptographischen Verfahren werden in [gemSpec_Krypt] getroffen. Konkret wird nur eine Sicherung der Authentizität und Integrität gewährleistet werden. Dies ist durch eine Signatur durch den Hersteller zu gewährleisten. Die Signatur durch den Hersteller dient dazu sicherzustellen, dass bei der Übermittlung und den anschließenden Prüf- und Verarbeitungsschritten innerhalb der prüfenden und zulassenden Stelle keine beabsichtigten oder unbeabsichtigten Verfälschungen der Firmware („Bitdreher“) auftreten können. Das Format der Firmware (d. h. des Binärfiles) bleibt herstellerspezifisch.

TIP1-A_3746 - Mobile Szenarien, Firmware Update: Verantwortlichkeit der Prüfung der neuen Firmware

Das Mobile Kartenterminal MUSS sicherstellen, dass die aktive Firmware, die auch die öffentlichen Schlüssel für die Signaturprüfung enthalten MUSS, die einzuspielende Firmware-Version prüft.

[<=]

Ein Wechsel des Schlüsselmaterials ist damit über die Einbeziehung einer neuen Schlüsselgeneration in die Firmware möglich. Auch ist es zulässig (und sogar empfohlen), dass eine Firmware nur die öffentlichen Schlüssel einer übergeordneten CA enthält und das konkrete Zertifikat zur Signatur in das bzw. an das Signaturenvelope ein- bzw. angefügt wird.

TIP1-A_3699 - Versionierung der Firmware

Das Mobile Kartenterminal MUSS für jede Firmware-Version des Mobilen Kartenterminals über eine Versionsnummer verfügen.

[<=]

Die Art der Versionierung ist unter der Einhaltung der Vorgaben aus [gemSpec_OM] herstellerspezifisch.

TIP1-A_3700 - Sicherstellung von Authentizität und Integrität eines FW-Updates

Das Mobile Kartenterminal MUSS vor Austausch der Firmware-Version die Authentizität und Integrität des Updatepakets prüfen.

[<=]

TIP1-A_3701 - Übernahme als aktive Firmware

Das Mobile Kartenterminal MUSS sicherstellen, dass die neue Firmware korrekt und vollständig in den Speicher übernommen wurde, bevor die Kennzeichnung als aktive Firmware von der bisherigen auf die neue übernommen wird.

[<=]

3.4.8.1 Konzept der Firmware-Gruppen

Das Konzept der Firmwaregruppen wird in [gemSpec_OM] beschrieben. Über die dortigen Anforderungen hinaus gilt:

TIP1-A_3825 - Ausführen eines zulässigen Downgrades

Der Hersteller des Mobilen Kartenterminals MUSS dafür sorgen, dass der Administrator vor dem Ausführen eines zulässigen Downgrades auf die möglichen Konsequenzen hingewiesen wird - z.B. im Rahmen der Benutzerdokumentation - und die Möglichkeit erhält, den Downgrade-Prozess noch abzubrechen.

[<=]

3.4.9 Produkttypversion und Selbstauskunft

Die Anforderungen bezüglich der Produkttypversion und Selbstauskunft sind in [gemSpec_OM] festgelegt. Hierüber hinaus gilt:

TIP1-A_4273 - Selbstauskunft: Produkt-Versionsstand

Das Mobile Kartenterminal MUSS die Rückgabe der Selbstauskunft über die Administrationsschnittstelle mittels Benutzerschnittstelle ermöglichen.

[<=]

TIP1-A_4274 - Selbstauskunft: Firmware-Gruppen-Version

Das Mobile Kartenterminal MUSS im Zuge der Selbstauskunft die aktuell installierte Firmware-Gruppen-Version darstellen.

[<=]

3.4.10 Kompatibilität zukünftiger Kartenversionen

Im Hinblick auf die Spezifikation zukünftiger Kartenversionen der durch das Mobile Kartenterminal verarbeiteten Kartentypen eGK, HBA und SMC-B ist die gematik auf Informationen der Hersteller angewiesen, ob über die spezifizierten Zugriffe (Verwendung von Kartenkommandos bzw. Zugriffe auf Kartenobjekte) hinaus herstellerspezifisch weitere sicherheitsrelevante Zugriffe erfolgen. Die gematik wird diese Information zukünftig im Rahmen von Impact-Analysen bei anstehenden Änderungen an den relevanten Kartenspezifikationen nutzen.

TIP1-A_6485 - Mobiles KT: Kompatibilität zukünftiger Kartenversionen

Der Hersteller des Mobilen Kartenterminals MUSS im Rahmen der Zulassung erklären, ob sein Mobiles Kartenterminal über die in Anhang A6 aufgeführten Kartenzugriffe hinaus weitere sicherheitsrelevante Kartenzugriffe vornimmt. Der Hersteller MUSS diese weiteren herstellerspezifischen sicherheitsrelevanten Zugriffe unter Verwendung der in Anhang A6 vorhandenen Tabellenform darstellen.

[<=]

Der Hersteller des mobilen Kartenterminals kann die Informationen über Kartenzugriffe, welche Sicherheitsleistungen im Sinne des [BSI-CC-PP-0052] erbringen, im Rahmen einer Re-Evaluierung bzw. Re-Zertifizierung seines Produktes ebenfalls nutzen. Die für die Sicherheitsleistung des Mobilen Kartenterminals relevanten Zugriffe sind in der Tabelle im Anhang A6 gelistet.

3.5 Sicherheitstechnische Anforderungen

3.5.1 Schutz der KVK

TIP1-A_4973 - Schreibschutz KVK

Das Mobile Kartenterminal DARF NICHT schreibend auf die KVK zugreifen.

[<=]

3.5.2 Schutz der eGK

TIP1-A_3717 - Freischaltung der eGK mittels PIN

Das Mobile Kartenterminal DARF die Freischaltung einer eGK mittels PIN-Eingabe NICHT ermöglichen.

[<=]

TIP1-A_3754 - Schutz vor Kartenzugriff bei Anschluss an das Primärsystem

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn es unmittelbar oder mittelbar (z. B. über das Mini-PS und den Mini-AK) mit dem stationären Primärsystem verbunden ist, Kartenzugriffe auf gesteckte eGKs oder KVKs nicht möglich sind. Maßgeblich ist hier die physikalische Verbindung (Kabel gesteckt) zwischen dem Mobilen Kartenterminal und einem Hostsystem (einem beliebigen Computer).

[<=]

Wenn das Mobile Kartenterminal bei Auslegung mit USB-Schnittstelle eindeutig erkennen kann, dass es nur zum Laden an einem USB-Ladegerät (nicht Hostsystem) angeschlossen wird, so ist dies zulässig und verletzt die Anforderung [TIP1-A_3754] nicht.

Wenn das Mobile Kartenterminal - beispielsweise bei Verwendung einer seriellen Schnittstelle - die physikalische Verbindung zwischen Mobilem Kartenterminal und Hostsystem nicht erkennen kann, so lässt sich die Anforderung [TIP1-A_3754] wie folgt erfüllen:
Im Mobilen Kartenterminal wird die Schnittstelle zum Hostsystem derart gestaltet, dass sie durch den Nutzer softwaretechnisch per Schalter aktivierbar und deaktivierbar ist. Wenn die Schnittstelle aktiviert ist, darf das Mobile Kartenterminal einen Zugriff auf gesteckte eGKs oder KVKs nicht ermöglichen. Ist die Schnittstelle zum Hostsystem deaktiviert, darf das Mobile Kartenterminal einen Zugriff über die Schnittstelle vom Hostsystem aus nicht ermöglichen.

3.5.3 Vertraulichkeit

Das mobile Kartenterminal vermittelt Daten mit medizinischen und personenbezogenen Inhalten. Diese haben einen hohen oder sehr hohen Schutzbedarf und es muss daher sichergestellt werden, dass sie nur im Rahmen der explizit vorgesehenen und beschriebenen Verfahren preisgegeben werden. Die Maßnahmen zum Schutz von diesen Informationsobjekten mit hohem und sehr hohem Schutzbedarf (z. B. PINs, Schlüssel, medizinische Daten) drücken sich im PP des Mobilen Kartenterminals in organisatorischen Anforderungen der Einsatzumgebungen und sicherheitstechnischen Maßnahmen des Mobilen Kartenterminals aus.

3.5.4 Lebensdauer sensibler Daten

TIP1-A_3852 - Lebensdauer sensibler, medizinischer Daten

Das Mobile Kartenterminal MUSS nach Abschluss jedes Prozessschrittes, bei dem sensible Daten wie VSD oder PINs verarbeitet werden, diese sensiblen Daten aus seinem Arbeitsspeicher unwiderruflich entfernen.

[<=]

3.5.5 Protokollierung des Zugriffs

Nach Vorgabe des [SGB V §291a] sind Protokollierungen des Zugriffs auf Daten durchzuführen.

Der Mini-AK muss für bestimmte Aktionen Protokolleinträge auf die eGK schreiben. Das Format der Protokolleinträge ist in Kapitel 10.1.8 beschrieben.

TIP1-A_4948 - Ausprägung des Zugriffsprotokolls

Der Hersteller des Mobilen Kartenterminals MUSS es ermöglichen, dass bei Zugriffen von Personen nach Absatz 4 Satz 1 Nr. 1 [SGB V §291a] Buchstabe d und e sowie Nummer 2 Buchstabe d und e, die über keinen elektronischen Heilberufsausweis oder entsprechenden Berufsausweis verfügen, nachweisbar in elektronischer Form außerhalb des Mobilen Kartenterminals protokolliert werden kann, wer auf die Daten zugegriffen hat und von welcher Person, die über einen elektronischen Heilberufsausweis oder entsprechenden Berufsausweis verfügt, die zugreifende Person autorisiert wurde.

[<=]

Beim in der obigen Anforderung genannten Personenkreis handelt es sich um Personen, die nicht über einen eigenen elektronischen Heilberufsausweis verfügen. In diesem Fall ist als berechtigte Karte eine Institutionskarte SMC-B im mobilen Kartenterminal vorhanden. Auf einer verarbeiteten eGK wird in einem solchen Fall protokolliert, mit welcher SMC-B zugegriffen wurde, nicht aber, welche Person zugegriffen hat. Diese Information muss außerhalb der verarbeiteten eGK und letztendlich außerhalb des mobilen Kartenterminals protokolliert werden, damit dieses Protokoll nicht bei Verlust des Geräts ebenfalls verloren geht.

Der Hersteller kann hier unterstützend eine technische Lösung implementieren. Es kann aber auch durch organisatorische Maßnahmen beim Leistungserbringer sichergestellt werden, dass zu jedem Zeitpunkt in elektronischer Form nachvollziehbar ist, welche Person auf die Daten zugegriffen hat und durch wen sie autorisiert wurde. Der Hersteller muss in der Dokumentation entsprechende Möglichkeiten beschreiben.

TIP1-A_4949 - Beschreibung des Verfahrens für das Zugriffsprotokoll

Der Hersteller des Mobilen Kartenterminals MUSS das Verfahren gemäß [TIP1-A_4948] in der Benutzerdokumentation beschreiben.

[<=]

3.5.6 Anschluss weiterer Komponenten

TIP1-A_4405 - Sicherheit bei Anschluss externer Komponenten

Der Hersteller des Mobilen Kartenterminals MUSS sicherstellen, dass eventuell angeschlossene externe Komponenten die Sicherheit des Mobilen Kartenterminals nicht nachteilig beeinflussen.

[<=]

4 Anforderungen an das Kartenterminal-Modul

Dieses Kapitel beschreibt die zu erfüllenden funktionalen und nicht-funktionalen Anforderungen an das Kartenterminal-Modul.

4.1 Display und PIN Pad

TIP1-A_3715 - Display zur Anzeige am Mobilen KT

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS über ein Display verfügen.

[<=]

TIP1-A_3867 - Mobile Szenarien: Am Display darstellbare Zeichen

Das Display des mobilen Kartenterminal MUSS mindestens zwei Zeilen á 16 Zeichen ISO646DE-Text darstellen können.

[<=]

Die Fähigkeit zur Anzeige von weiteren Sonderzeichen ist erlaubt.

TIP1-A_3716 - PIN Pad zur PIN-Eingabe am Mobilen KT

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS über ein PIN Pad oder eine vergleichbare Eingabeeinheit, welche sich zur Eingabe einer numerischen PIN und zur damit verbundenen Authentisierung eignet, verfügen.

[<=]

Weitere Sensoren/Eingabeeinheiten können im Kartenterminal-Modul vorgesehen sein.

Das Kartenterminal-Modul kann statt eines eigenen Displays auch das erweiterte Display nachnutzen. Siehe hierzu Kapitel 8.2 [TIP1-A_4425].

4.2 PIN-Eingabe und PIN-Änderung

Die Mechanismen zum Schutz der PIN ergeben sich aus den Festlegungen zum Angriffspotential sowie des EAL (Evaluation Assurance Level. In der Common Criteria definierte Vertrauenswürdigkeitsstufen, EAL 1-7), welche im zugehörigen Protection Profile getroffen werden.

TIP1-A_3861 - Mobiles KT: Vorgaben zum Kommando SICCT PERFORM VERIFICATION

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS für die PIN-Eingabe die Vorgaben zum Kommando SICCT PERFORM VERIFICATION (siehe [SICCT#5.19.1,5.19.2]) - außer für die Dauer der Wartezeiten bei der PIN-Eingabe - umsetzen.

[<=]

TIP1-A_3862 - Mobiles KT: Timeout bei der PIN-Eingabe (erstes Zeichen)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS bei der PIN-Eingabe - abweichend von [SICCT#5.19.2] - standardmäßig 30 Sek. (statt 15 Sek. laut SICCT) auf die Eingabe des ersten Zeichens oder die Betätigung der Abbruchtaste warten.

[<=]

TIP1-A_3863 - Mobiles KT: Timeout bei der PIN-Eingabe (weitere Zeichen)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS - abweichend von [SICCT#5.19.2] - standardmäßig 30 Sek. (statt 5 Sek. laut SICCT) auf die Eingabe des jeweils nächsten Zeichens oder die Betätigung der Abbruch- bzw. Bestätigungstaste warten.

[<=]

TIP1-A_3864 - Mobiles KT: Vorgaben zum Kommando SICCT MODIFY VERIFICATION

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS für die PIN-Änderung die Vorgaben zum Kommando SICCT MODIFY VERIFICATION (siehe [SICCT#5.20.1,5.20.2]) - außer für die Wartezeiten bei der PIN-Änderung – umsetzen.

[<=]

TIP1-A_3865 - Mobiles KT: Timeout bei der PIN-Änderung (erstes Zeichen)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS bei der PIN-Eingabe - abweichend von [SICCT#5.20.2] - standardmäßig 30 Sek. (statt 15 Sek. laut SICCT) auf die Eingabe des ersten Zeichens oder die Betätigung der Abbruchtaste warten.

[<=]

TIP1-A_3866 - Mobiles KT: Timeout bei der PIN-Änderung (weitere Zeichen)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS - abweichend von [SICCT#5.20.2] - standardmäßig 30 Sek. (statt 5 Sek. laut SICCT) auf die Eingabe des jeweils nächsten PIN-Zeichens oder die Betätigung der Abbruch- bzw. Bestätigungstaste warten.

[<=]

TIP1-A_3806 - Bestätigung der PIN-Eingabe am Mobilen KT

Das Mobile Kartenterminal MUSS sicherstellen, dass, unabhängig davon ob es sich um eine Eingabe von einer PIN mit variabler oder fixer Länge handelt, die Eingabe der PIN durch Drücken einer „Enter"-Taste (dies legt nicht die Beschriftung dieser Taste, sondern lediglich ihre Funktion bei der PIN-Eingabe fest) bestätigt werden muss.

[<=]

TIP1-A_4976 - Enter-Taste bei bekannter PIN-Länge

Das Mobile Kartenterminal DARF bei bekannter PIN-Länge und falls diese unterschritten wird, die "Enter"-Taste NICHT akzeptieren.

[<=]

Siehe hierzu Abbildung 3 Pic_MOKT_0023 Verhalten bei PIN-Eingabe mit bekannter Länge.

TIP1-A_4958 - Abbruchtaste bei PIN-Eingabe

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS dem Benutzer die Möglichkeit bieten, die PIN-Eingabe jederzeit mittels Drücken einer "Abbruch"-Taste abbrechen zu können.

[<=]


Abbildung 3: Pic_MOKT_0023 Verhalten bei PIN-Eingabe mit bekannter Länge

TIP1-A_4922 - Mobiles KT: sicherer Modus

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS sich im Betrieb immer im sicheren Modus befinden, der sicherstellt, dass eine PIN über keine andere Schnittstelle als die zu der Karte, die für die PIN-Eingabe vorgesehen ist, übertragen wird und nicht zwischengespeichert, dupliziert oder manipuliert werden kann.

[<=]

Eine Anzeige des sicheren Modus ist nicht erforderlich.

TIP1-A_3875 - Freischaltung der berechtigten Karte mittels PIN

Das Mobile Kartenterminal MUSS es dem Leistungsbringer ermöglichen, den HBA und die SMC-B mittels PIN-Eingabe am Kartenterminal-Modul des Mobilen Kartenterminals freizuschalten.
[<=]

4.3 Zugriffsanzeige

TIP1-A_3799 - Signalisieren der Kartenzugriffe

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS bei Kartenzugriffen (Lesen, Schreiben, Operationszugriffe) den Umstand, dass auf eine Karte zugegriffen wird, für die gesamte Dauer des Zugriffs für den Benutzer gut sichtbar anzeigen, z.B. mittels einer LED, die bei Kartenzugriffen blinkt.

[<=]

Es ist nicht erforderlich, Zugriffe für jede Karte separat anzuzeigen.

Das Kartenterminal-Modul kann hierzu auch das erweitere Display nachnutzen.

4.4 Performanz

TIP1-A_4423 - Übertragungsraten zu den Chipkarten

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS die Übertragungsraten zu den Chipkarten gemäß den technischen Spezifikationen ([KVK], [eGK], [HBA] und [SMC-B]), unterstützen.

[<=]

4.5 Kartenorientierte Anforderungen

Die Beschreibung der Kartenschnittstelle ist auf den Einsatz kontaktbehafteter Gesundheitskarten abgestimmt. Die Basis für alle Anforderungen ist die internationale Normenreihe ISO/IEC 7816. Die technischen Anforderungen an die Chipkartenschnittstelle sind in der SICCT-Spezifikation [SICCT] beschrieben.

TIP1-A_4946 - Umsetzung der Chipkartenschnittstelle entsprechend [KVK], [HBA], [SMC-B] und [eGK]

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS die Karten:KVK [KVK], HBA [HBA], SMC-B [SMC-B] und eGK [eGK] unterstützen.

[<=]

4.5.1 Stromversorgung der Chipkarten

Das Kartenterminal-Modul bedient in erster Linie ISO/IEC-kompatible Chipkarten und daher ist der Standard ISO/IEC 7816-3 [ISO7816-3] maßgeblich.

TIP1-A_4401 - Dauerhafte Stromversorgung der gesteckten Chipkarte(n)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS während des Betriebs eine dauerhafte Stromversorgung der Chipkarte(n) mit dem Maximalstrom nach den derzeit gültigen internationalen Standards ([ISO7816-3]) gewährleisten.

[<=]

Dabei ist zu beachten, dass Chipkarten kurzzeitig auch einen höheren Stromverbrauch haben können.

TIP1-A_4411 - Kurzzeitig höherer Strombedarf von Chipkarten (Spike)

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS bei kurzzeitig höherem Stromverbrauch der Chipkarten (Spike gemäß [ISO7816-3]) die volle Funktionsfähigkeit des Kartenterminal-Moduls gewährleisten.

[<=]

TIP1-A_3765 - Mobiles KT: Karten-Versorgungsspannung

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS einer Karte die im Rahmen der ATR-Prozedur ausgehandelte Versorgungsspannung in folgender Reihenfolge (absteigend) anbieten:

  1. 5V (verpflichtend)
  2. 3V (verpflichtend)
  3. 1,8V (optional).
[<=]

4.5.2 Anzahl Kontaktiereinheiten

TIP1-A_3718 - Mindestanzahl der Kontaktiereinheiten am mobilen Kartenterminal

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS über zwei Kontaktiereinheiten zur Aufnahme von Chipkarten im ID-1-Format verfügen.

[<=]

TIP1-A_3719 - Mindestanzahl gleichzeitig aufnehmbarer ID-1-Karten

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS zwei Karten im ID-1-Format gleichzeitig aufnehmen können.

[<=]

TIP1-A_3720 - Gleichzeitig aufnehmbare ID-1-Karte und Plug-In-Karte

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS eine Karte im ID-1-Format und eine Karte im ID-000-Format gleichzeitig aufnehmen können.

[<=]

Das Format der für die Aufnahmen von ID-000-Modulen bestimmten Kontaktiereinheiten ist herstellerspezifisch, da das ID-000-Modul auch mittels eines Adapters gesteckt werden kann.

TIP1-A_3721 - Anzahl Kontaktiereinheiten im Sinne der Zukunftssicherheit

Das Kartenterminal-Modul des Mobilen Kartenterminals SOLL - zusätzlich zu den beiden ID-1-Kontaktiereinheiten - über eine eigenständige Kontaktiereinheit zur Aufnahme von Karten im ID-000-Format verfügen.

[<=]

4.5.3 Ausprägung Kontaktiereinheiten

Die KVK, eGK und der HBA verlangen kontaktbehaftete Schnittstellen mit Kontaktiereinheiten der Größe ID-1 (mit dem Maßen 85,6mm x 54,0 mm).

TIP1-A_3702 - Format der Kontaktiereinheit zur Aufnahme von Karten im ID-1-Format

Die kontaktbehafteten Schnittstellen des Kartenterminal-Moduls des Mobilen Kartenterminals mit der Kontaktiereinheitengröße ID-1 MÜSSEN der Norm ISO/IEC 7810 [ISO7810] entsprechen.

[<=]

TIP1-A_3807 - Format der zu unterstützenden Plug-In-Karten

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS Secure Module Cards (SMC) als kontaktbehaftete Karte im Format ID-1 oder ID-000 (Plug-in-Karte) nach CEN ENV 1375-1 [CEN ENV] unterstützen.

[<=]

TIP1-A_4977 - Lage Kartenkontakte

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS die Lage und Zuordnung der Kontakte entsprechend der Norm ISO/IEC 7816-2 [ISO7816-2] umsetzen.

[<=]

Generell sind alle Kontaktierungstypen zulässig, sofern die generellen mechanischen Anforderungen der folgenden Abschnitte eingehalten werden.

TIP1-A_4978 - Unterstützung Kartenkontakte

Das Mobile Kartenterminal SOLL die Kartenkontakte C4, C6 und C8 NICHT unterstützen.

[<=]

TIP1-A_4979 - Elektrischer Anschluss Kartenkontakte

Das Mobile Kartenterminal SOLL die Kartenkontakte C4, C6 und C8 NICHT elektrisch anschließen.

[<=]

TIP1-A_4262 - Verwendung von Kontaktschonenden Kontaktiereinheiten

Die kontaktbehafteten Schnittstellen des Kartenterminal-Moduls des Mobilen Kartenterminals MÜSSEN kontaktschonend sein.

[<=]

TIP1-A_3763 - Landende Kontakte

Das Mobile Kartenterminal SOLL Kontaktiereinheiten mit landenden Kontakten als kontaktschonende Kontaktiereinheiten verwenden.

[<=]

TIP1-A_3812 - Kartenkontakte und Umschalten in andere Betriebsmodi

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn die Kartenkontakte C4, C6 und C8 für spezielle Betriebsmodi wie ISO7816-12 erforderlich sind, diese nicht vor dem Umschalten in einen solchen Modus aktiviert werden.

[<=]

TIP1-A_3813 - Kartenkontakte und Umschalten Betriebsmodi

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn die Kartenkontakte C4, C6 und C8 für spezielle Betriebsmodi wie ISO7816-12 erforderlich sind, diese initial, vor dem Umschalten in einen solchen Modus potentialfrei sind.

[<=]

TIP1-A_3804 - Umschalten aus einem speziellen Betriebsmodus

Das Mobile Kartenterminal MUSS sicherstellen, dass nach dem Umschalten des Mobilen Kartenterminals aus einem speziellen Modus in den Standardmodus die Kartenkontakte C4, C6 und C8 wieder deaktiviert werden.

[<=]

4.5.3.1 ID-1-Kartenkontaktierungen

TIP1-A_4402 - Vermeidung von Beschädigungen der Karte durch die Kontaktiereinheit

Das Mobile Kartenterminal MUSS sicherstellen, dass die Entnahme oder Einführung der Chipkarte in das Mobile Kartenterminal nicht zu einer Beschädigung der Bedruckung bzw. der Funktionalität der Karte durch die Kontaktiereinheit führt.

[<=]

TIP1-A_3703 - Zeitpunkt der Schaltung des „Card-In-Schalters“

Das Mobile Kartenterminal MUSS sicherstellen, dass der „Card-In"-Schalter des Mobilen Kartenterminals (d.h. der Schalter zur Kartenpräsenzerkennung) nicht vor Kontaktierung der Kontaktflächen und Erreichen des Kontakt-Enddrucks geschaltet wird.

[<=]

TIP1-A_3704 - Anpressdruck der Kontaktflächen

Das Mobile Kartenterminal MUSS sicherstellen, dass der Anpressdruck der Kontakte der Chipkartenkontaktiereinheit auf die Kontaktflächen zwischen 0.2N und 0.6N beträgt.

[<=]

Das Kartenterminal-Modul kann anzeigen, ob sich eine Chipkarte korrekt in der Kontaktiereinheit befindet und diese mit Strom versorgt ist.

4.5.3.2 ID-000 Kartenkontaktierungen

Nicht jeder Terminaltyp muss ID-000-Kontaktierungen besitzen.

Sofern ID-000-Kontaktierungen vorhanden sind gilt:

  • Der Zugriff auf die Plug-In-Karte(n) kann möglich sein. Der Zugang zur Plug-In-Karte muss jedoch zum Zwecke des Diebstahlschutzes beschränkt sein
  • Eine Versiegelung des Zugangs kann erforderlich werden, wenn die Gehäuseöffnungen Zugang zu sicherheitsrelevanten Teilen des Kartenterminalinneren bieten, oder als Maßnahme zum Schutz gegen das Abgreifen oder Manipulieren der Kontaktiereinheit.
  • Es ist kein Card-In-Kontakt erforderlich.

TIP1-A_4413 - Beschränkung des Zugangs zu Plug-In-Karten

Das Kartenterminal-Modul des mobilen Kartenterminals SOLL, sofern es über native ID-000-Kontaktiereinheiten verfügt, den Zugang zur Plug-In-Karte zum Zwecke des Diebstahlschutzes beschränken.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung verzichtet werden.

4.5.4 Chipkartenprotokolle

TIP1-A_3705 - Umsetzung der Kartenkommunikation

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS die Kartenkommunikation und das Reset-Verhalten gemäß den Spezifikationen der KVK [KVK], des HBA [HBA], der SMC-B [SMC-B] und der eGK [eGK] umsetzen.

[<=]

Das Kartenterminal-Modul muss nachfolgend aufgeführte synchrone und asynchrone Übertragungsprotokolle zu den Chipkarten unterstützen. Die Protokolle sind nach den Vorgaben der jeweiligen internationalen Normen zu implementieren.

TIP1-A_4263 - Handhabung von Fehlerfällen, Verhinderung von Deadlock-Situationen

Das Mobile Kartenterminal MUSS das Auftreten eines Deadlocks während der Kartenkommunikation verhindern.

[<=]

TIP1-A_4256 - Zu unterstützende Übertragungsprotokolle zu den asynchronen Chipkarten

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS das asynchrone Chipkartenprotokoll:

  • T=1, Block-orientiertes Halbduplex-Protokoll gemäß ISO/IEC 7816-3 [ISO7816-3]

unterstützen.

[<=]

TIP1-A_4257 - Zu unterstützende Übertragungsprotokolle zu den synchronen Chipkarten

Das Kartenterminal-Modul des Mobilen Kartenterminals MUSS für synchrone Chipkarten das synchrone Chipkartenprotokoll gemäß der Norm ISO/IEC 7816-10 [ISO7816-10] unterstützen. Dabei gilt:

  • S=10 für 2-Wire-Bus Chipkarten gemäß ISO/IEC 7816-10 [ISO7816-10] und dort referenzierter Spezifikationen
  • S=8 für I2C-Bus Chipkarten ISO/IEC 7816-10 [ISO7816-10]
  • S=9 für 3-Wire-Bus Chipkarten nach Herstellerspezifikation und ISO/IEC 7816-10 [ISO7816-10].
[<=]

TIP1-A_3874 - Gewährleistung der Sicherheit bei Unterstützung kontaktloser Karten

Der Hersteller des Mobilen Kartenterminals DARF, im Fall der Unterstützung von kontaktlosen Chipkarten, bei der Implementierung die Sicherheit des Gesamtsystems "Mobiles Kartenterminal" NICHT verletzen.

[<=]

5 Anforderungen an den Mini-Anwendungskonnektor

Dieses Kapitel beschreibt die Basismechanismen und Basisdienste des Mini-AK sowie die umzusetzenden technischen Use Cases der Fachanwendungen. Das Verhalten der Basisdienste des Mini-AK ist im Kapitel 10.1 beschrieben.

5.1 Basismechanismen

Die Basismechanismen sind Protokolle und Algorithmen, die für die Basisdienste implementiert werden.

5.1.1 Zufallszahlen und Schlüssel

Der Mini-AK unterstützt das Erstellen von Zufallszahlen und Einmalschlüsseln. Sie kommen zum Beispiel für Verschlüsselungen zum Schutz von medizinischen Daten zum Einsatz.

TIP1-A_4936 - Mobiles KT: Anforderung an Zufallszahlen

Der Mini-AK des Mobilen Kartenterminals MUSS im Rahmen der Zufallszahlen die Anforderung [gemSpec_Krypt#GS-A_4367] umsetzen.

[<=]

Die Güte und der ordnungsgemäße Betrieb des Zufallsgenerators sind geeignet sicherzustellen. Der Abschnitt [gemSpec_Krypt#2.3] enthält Hinweise zur Umsetzung dieser Anforderungen für deterministische Zufallszahlengenerierung.

TIP1-A_3860 - mobile Szenarien: Verwendung des Zufallszahlengenerators einer berechtigten Karte

Das Mobile Kartenterminal KANN als Quelle für Zufallszahlen gemäß [TIP1-A_4936] den Zufallszahlengenerator der berechtigten Karte verwenden, welcher die Anforderungen gemäß [gemSpec_Krypt#GS-A_4367] an Qualität und Güte der Zufallszahlen erfüllt.

[<=]

TIP1-A_4937 - Mobiles KT: Anforderung an Einmalschlüssel

Der Mini-AK des Mobilen Kartenterminals MUSS im Rahmen der Einmalschlüssel die Anforderung [gemSpec_Krypt# GS-A_4368] umsetzen.

[<=]

5.2 Basisdienste

Die Basisdienste enthalten die fachlogikneutralen Teile des Mini-AK. Sie stellen primär die verfügbaren Sicherheitsfunktionen des Mini-AK bereit und regeln den Zugriff auf die verfügbaren Karten.

5.2.1 Kartenterminaldienst

Der Kartenterminaldienst des Mobilen Kartenterminals hat bei Zugriff auf Ressourcen eines Kartenterminal-Moduls die Kommunikation zu koordinieren. Er empfängt und verarbeitet vom Kartenterminal-Modul gesendete Ereignisse und stellt den Zugriff auf die Ressourcen „Tastatur (PIN-Pad)“, „Display“ und die „Kartenslots“ bereit. Die Schnittstellen des Kartenterminaldienstes sind herstellerspezifisch.

Das Kartenterminal-Modul sendet Ereignisse über das Stecken und Ziehen einer Karte an den Kartenterminaldienst des Mini-AK, welcher empfangene Ereignisse entweder an den Kartendienst weiterleitet oder selber dafür Sorge trägt, dass die Liste der vom Kartendienst verwalteten Karten aktualisiert wird.

Meldet während einer Kartenaktion das Kartenterminal das Ziehen der Karte, so kann die ausgeführte Aktion nicht erfolgreich zu Ende geführt werden.

TIP1-A_3840 - mobile Szenarien: Freigabe von Ressourcen bei Fehlersituation

Das Mobile Kartenterminal MUSS, falls während einer Kartenaktion das Ziehen der Karte gemeldet wird, die entsprechende Ressource nach Erkennung der Fehlersituation freigeben.

[<=]

TIP1-A_3868 - mobile Szenarien: Freigabe von Ressourcen ohne manuelles Eingreifen

Der Kartenterminaldienst des Mobilen Kartenterminals DARF zur Freigabe der Ressource gemäß [TIP1-A_3840] ein manuelles Eingreifen NICHT erfordern.

[<=]

Weitere Details zur Umsetzung sind herstellerspezifisch.

5.2.2 Kartendienst

TIP1-A_4956 - Mobiles KT: Kartendienstunterstützung für eGK, HBA, SMC-B und KVK

Der Mini-AK des Mobilen Kartenterminals MUSS in der Lage sein, mindestens die Karten eGK [eGK], HBA [HBA], SMC-B [SMC-B] und KVK [KVK] zu erkennen und zu unterstützen.

[<=]

Der Kartendienst stellt für die von ihm verwalteten Karten die im Folgenden beschriebenen Funktionen bereit:

5.2.2.1 Identifikation des Kartentyps und der Version

TIP1-A_3788 - Mobiles KT: Bestimmung des AID einer Prozessorkarte nach [ISO7816-3]

Der Mini-AK des Mobilen Kartenterminals MUSS für die Identifikation des Kartentyps und der Version einer Karte den Typ einer Prozessorkarte nach [ISO7816-3] anhand des Application Identifier (AID) des Master File (MF) gemäß Tab_MobKT_002 "Application Identifier der Kartentypen" bestimmen.

[<=]

TIP1-A_3815 - Mobiles KT: Bestimmung der AID aus File Control Parameter oder Application Template

Der Mini-AK des Mobilen Kartenterminals MUSS für die Identifikation des Kartentyps und der Version einer Karte gemäß [TIP1-A_3788] die AID aus dem File Control Parameter des Master File über ein SELECT oder aus dem Application Template in /MF/EF.DIR beziehen.

[<=]

TIP1-A_4938 - Mobiles KT: Bestimmung der AID einer Speicherkarte nach [KVK#4.1]

Der Mini-AK des Mobilen Kartenterminals MUSS für die Identifikation der KVK den Typ der Speicherkarte anhand des Application Identifier (AID) in DIR-data (siehe [KVK#6.2.2]) bestimmen.
[<=]

Tabelle 1: Tab_MobKT_002 Application Identifier der Kartentypen

Kartentyp
 Kriterien
eGK
 AID des MF: siehe [eGK]
HPC
 AID des MF: siehe [HBA]
SMC-B
 AID des MF: siehe [SMC-B]
KVK
 AID innerhalb der DIR-data: siehe [KVK#6.2.2]

TIP1-A_4957 - Mobiles KT: Unterstützung Kartenversionen von eGK, HBA und SMC-B

Der Mini-AK des Mobilen Kartenterminals MUSS die Versionen für [eGK], [HBA] und [SMC-B] unterstützen, wenn die Versionen des Betriebssystems und des Objektsystems der jeweiligen Karte dem Mini-AK bekannt sind.

[<=]

Die Kartenversion der Kartentypen eGK, HBA und SMC-B setzt sich aus der Version des Betriebssystems (COS) und der Objektsystemversion des jeweiligen Kartentyps zusammen. Im Rahmen der Prüfung auf Karten-Inkompatibilität gemäß [TIP1-A_3816] sind diese beiden Versionsnummern zu berücksichtigen.

Für die Karten-Generation 2 und 2.1 werden zum jeweiligen Release, in welchem der Produkttypsteckbrief des Mobilen Kartenterminals enthalten ist, die Versionen der zu unterstützenden Karten veröffentlicht.

TIP1-A_3816 - Mobiles KT: Karten-Inkompatibilität als Ergebnis der Kompatibilitätsprüfung

Der Mini-AK des Mobilen Kartenterminals MUSS in einem ersten Schritt, wenn die durch das Mobile Kartenterminal ermittelte Kartenversion kleiner als alle durch den Mini-AK zu unterstützenden Kartenversionen gemäß [TIP1-A_4957] ist oder die ermittelte Kartenversion nicht gemäß [TIP1-A_4957] bekannt und kleiner als die größte zu unterstützende Kartenversion ist, von einer inkompatiblen Karte ausgehen und die weitere Verarbeitung der Karte direkt abbrechen.

Der Mini-AK des Mobilen Kartenterminals MUSS in einem zweiten Schritt, wenn die durch das Mobile Kartenterminal ermittelte Kartenversion größer als alle durch den Mini-AK zu unterstützenden Kartenversionen gemäß [TIP1-A_4957] ist, von einer kompatiblen Karte ausgehen und versuchen, diese zu verarbeiten.

[<=]

Das bedeutet, dass der Mini-AK des Mobilen Kartenterminals zunächst unbekannte ältere Versionen (mindestens die Version des Betriebssystems oder die Objektsystemversion des jeweiligen Kartentyps ist kleiner als die zu unterstützenden Versionen) bzw. unbekannte Versionen, die aber kleiner als die größte ihm bekannte Version sind, als inkompatibel identifiziert und die Verarbeitung der zugehörigen Karte direkt mit einer Fehlermeldung gemäß [TIP1-A_4271] abbricht.

Der Mini-AK muss dann bei unbekannten neueren Versionen (mindestens die Version des Betriebssystems oder die Objektsystemversion des jeweiligen Kartentyps ist größer als die zu unterstützenden Versionen) von einer kompatiblen Karte ausgehen und versuchen, diese zu verarbeiten.

TIP1-A_4271 - Mobiles KT: Fehlermeldung Karten Inkompatibilität

Der Mini-AK des Mobilen Kartenterminals MUSS, wenn die durch das Mobile Kartenterminal ermittelte Kartenversion zu keiner dem Mini-AK bekannten gemäß [TIP1-A_4957] kompatibel ist, eine geeignete Fehlermeldung auf dem erweiterten Display des Mobilen Kartenterminals darstellen.

[<=]

5.2.2.2 Zugriff auf Dateien der Karte

Die Daten der verschiedenen fachlichen Anwendungen wie auch die Zertifikate sind auf der Karte in Dateien verschiedener Ausprägung (transparent, Record orientiert, Data Object orientiert) gespeichert.

TIP1-A_4939 - Mobiles KT: Extended Length der Karten

Der Kartendienst des Mobilen Kartenterminals MUSS das Extended Length Feature der Karten unterstützen.

[<=]

Das heißt, der Mini-AK muss zunächst anhand des ATRs der Karte erkennen, ob Extended Length unterstützt wird. Anschließend muss er EF.ATR auswerten, um zu bestimmen, welche Längen für Datenfelder in den APDUs unterstützt werden (siehe hierzu [eGK], [HBA] und [SMC-B]). Beim Lesen und Schreiben von Daten auf die Karte muss, basierend auf der maximal unterstützten Länge, die Anzahl der benötigten APDUs zum Übertragen der Daten von oder zu der Karte minimiert werden. Der Zugriff auf die Dateien der eGK erfordert in der Regel eine vorausgehende Card-to-Card-Authentisierung.

Die Durchführung dieser für die eGK benötigten Autorisierungen wird in der Regel durch das jeweilige Fachmodul im Mini-AK angestoßen (siehe auch Kapitel 5.2.2.5).

5.2.2.3 PIN-Verifikation und PIN-Management

Der Zugriff auf Sicherheitsfunktionen oder Dateien der Karte kann u. a. durch PIN geschützt sein. Eine Karte kann mehrere PINs haben (z. B. eine separate PIN für die qualifizierte elektronische Signatur, wobei diese im Bereich des mobilen Einsatzszenarios nicht betrachtet wird).

Bei HBA und SMC-B stößt der Kartendienst des Mini-AK bei Bedarf automatisch eine PIN-Verifikation an, um den Zugriff auf einen privaten Schlüssel der Karte zu autorisieren (s. a. TUC_MOKT_405 authenticateCardToCard).

5.2.2.4 Ereignisse

Der Kartendienst muss die vom Kartenterminaldienst empfangenen Ereignisse verarbeiten. Die vom Kartenterminal mitgeteilten Statusänderungen der Karten müssen direkt nach Eintreffen zu einer Anpassung des Status der vom Kartendienst verwalteten Kartenobjekte führen. Wird eine Karte gesteckt, so wird ein entsprechender Eintrag in die Liste der verfügbaren Karten aufgenommen werden. Wird eine Karte gezogen, so wird der entsprechende Eintrag aus der Liste der verfügbaren Karten entfernt.

5.2.2.5 Card-to-Card-Authentisierung und sichere Kanäle

TIP1-A_3787 - Mobiles KT: durch Kartendienst bereitzustellende Funktionen für sichere Kommunikation zwischen Karten

Der Kartendienst des Mini-AK des Mobilen Kartenterminals MUSS Funktionen für die Durchführung von Card-to-Card-Authentisierung ohne Aufbau eines sicheren Kanals (d. h. Aushandeln eines symmetrischen Schlüssels für die sichere Kommunikation zwischen beiden Karten) bereitstellen, und ggf. die benötigten Cross-CVCs bereithalten und bei Bedarf in die Karten laden.

[<=]

Ein Beispiel für Card-to-Card-Authentisierung ohne Aufbau eines sicheren Kanals ist die Authentisierung zwischen HBA bzw. SMC-B und eGK (siehe hierzu [eGK], [HBA] und [SMC-B]).

Die Umsetzung von C2C mit Aufbau eines sicheren Kanals kann optional unterstützt werden.

Wenn die Herausgeber-CV-Zertifikate beider Karten ihren Ursprung bei derselben Root haben, lassen sich die Zertifikatsketten auf geradem Weg durchlaufen. Wenn die Roots aber unterschiedlich sind, kann eine Karte das fremde CA-Zertifkat nicht mit dem eigenen Root-Key prüfen. Sie benötigt ein Zertifikat, das von der eigenen Root signiert ist und den Root-Key der fremden Karte bestätigt. Diese Zertifikate heißen Cross-CV-Zertifikate (Cross-CVCs). Der Mini-AK muss für jedes mögliche Paar aus Root-Keys zwei Cross-CVCs bereithalten (in jeder Richtung eines) und bei Bedarf in die Zertifikatskette einhängen. Damit verlängert sie sich um einen Schritt, kann letztlich aber auf dieselbe Weise wie bisher abgearbeitet werden: als mehrfache Abarbeitung der Sequenz {Schlüssel des Signierers selektieren + Zertifikat prüfen}.

Die Referenz des Root-Keys ist im CA-Zertifikat der Karte als Parameter CAR (Certificate Authority Reference) enthalten. Da die CAR weltweit eindeutig ist, genügt es, die CARs der CA-Zertifikate der beiden beteiligten Karten zu vergleichen, um festzustellen, ob sie von unterschiedlichen Roots abstammen.

Daher müssen im Mini-AK die entsprechenden Cross-CVCs zur Verfügung stehen.

TIP1-A_4940 - Mobiles KT: Nachladen von Cross-CVCs

Der Kartendienst des Mobilen Kartenterminals MUSS bei einer Card-to-Card-Authentisierung erkennen, ob und welche Cross-CVCs nötig sind und diese dann bei Bedarf in die jeweilige Karte laden.

[<=]

Der Ablauf einer Card-to-Card-Authentisierung ist im Rahmen von Kapitel 10.1.7 dargestellt. Bei Rollenauthentisierungen mit HBA und SMC-B stößt dabei der Kartendienst des Mini-AK bei Bedarf automatisch eine PIN-Verifikation an, um den Zugriff auf den für die Card-to-Card-Authentisierung verwendeten privaten Schlüssel der Karte zu autorisieren.

5.2.2.6 Datenzugriffsaudit

Der Mini-AK hat für bestimmte Aktionen Protokolleinträge auf die eGK zu schreiben. Wann eine Protokollierung vorzunehmen ist und welchen konkreten Inhalt der Eintrag jeweils hat, legen die Fachanwendungen fest.

TIP1-A_3724 - Schreibender Zugriff auf die eGK nur auf den Logging-Container

Der Kartendienst des Mobilen Kartenterminals MUSS sicherstellen, dass schreibende Zugriffe ausschließlich auf den Logging-Container der eGK möglich sind.

[<=]

TIP1-A_3842 - Referenzuhr zur Bestimmung des Zeitpunktes für Log-Einträge der eGK

Das Mobile Kartenterminal MUSS zur Bestimmung des Erfassungszeitpunktes zum Logging auf die eGK die Systemuhr des Mini-AKs verwenden.

[<=]

5.2.3 Verschlüsselungsdienst

Der Verschlüsselungsdienst stellt Funktionen zur Ver- und Entschlüsselung von Daten und Dokumenten zur Verfügung und wird z. B. vom Mini-PS verwendet, um die zwischengespeicherten Daten zu ver- bzw. entschlüsseln.

TIP1-A_3755 - Verwendung der Ver- und Entschlüsselungsfunktionen berechtigter Karten

Das Mobile Kartenterminal MUSS die Verwendung der Ver- und Entschlüsselungsfunktionen der berechtigten Karten ermöglichen.

[<=]

TIP1-A_4424 - mobile Szenarien Verschlüsselung: Zu verwendende Verfahren

Der Verschlüsselungsdienst des Mobilen Kartenterminals MUSS für die Ver- und Entschlüsselung von Daten und Dokumenten die in [gemSpec_Krypt# GS-A_4367], [gemSpec_Krypt#GS-A_4368],[gemSpec_Krypt#GS-A_4389], [gemSpec_Krypt#GS-A_4390], [gemSpec_Krypt#A_17575] und [gemSpec_Krypt#GS-A_5016] beschriebenen Verfahren und Algorithmen verwenden.

[<=]

5.2.4 Zertifikatsdienst

TIP1-A_3739 - mobile Szenarien: Ausschließliche Nutzung von HBA oder SMC-Bs

Der Zertifikatsdienst des Mobilen Kartenterminals MUSS sicherstellen, dass ausschließlich HBA und SMC-B als berechtigte Karten eine C2C-Authentisierung mit der eGK durchführen können.
[<=]

TIP1-A_4952 - mobile Szenarien: Zeitpunkt für Prüfung auf berechtigte Karte

Das Mobile Kartenterminal MUSS spätestens beim ersten Zugriff auf die Karte nach deren Initialisierung prüfen, ob es sich bei einer Karte um eine berechtigte Karte (also HBA oder SMC-B) handelt.

[<=]

TIP1-A_4953 - mobile Szenarien, Zertifikatsdienst: Überprüfung der Gültigkeit der X.509-Zertifikate einer Karte

Der Zertifikatsdienst des Mobilen Kartenterminals MUSS nach der Prüfung gemäß [TIP1-A_4952] anhand des Ablaufdatums des jeweiligen X.509-AUT-Zertifikates einer berechtigten Karte (C.HP.AUT bzw. C.HCI.AUT) und der Systemuhr nachprüfen, dass diese nicht abgelaufen sind.

[<=]

5.3 Fachanwendung VSDM

Das Fachmodul Versichertenstammdatenmanagement (mobKT) muss die Anwendungsfälle

  • VSDM-UC_14: VSD von eGK im mobilen Einsatzszenario lesen
  • VSDM-UC_15: Versichertendaten von KVK im mobilen Einsatzszenario lesen

gemäß [gemSysL_VSDM] umsetzen:

5.3.1 Übergreifende Anforderungen

Nachfolgend werden die Anforderungen an das Fachmodul VSDM (mobKT) beschrieben, die übergreifend für die fachlichen Anwendungsfälle zu betrachten sind.

Der Schutzbedarf der verarbeiteten Informationsobjekte der Anwendung VSDM wird durch die sie verarbeitenden Sicherheitsanalysegegenstände (Komponenten, Dienste, Schnittstellen) sichergestellt.

Kann eine Aktivität oder der ganze Anwendungsfall nicht durchgeführt werden bzw. wird eine Aktivität vorzeitig beendet, muss eine eindeutige, unverwechselbare Fehlermeldung erzeugt werden. Diese Fehlermeldung muss wie in Kapitel 6.2.4 beschrieben dem Anwender signalisiert und zur Anzeige im Hinblick auf [TIP1-A_4266] gespeichert werden.

VSDM-A_2782 - Fachmodul VSDM (mobKT): Pflichtfelder zum Anzeigen auf dem Display

Das Fachmodul VSDM (mobKT) MUSS Versichertendaten mit den in Tab_mobKT_ST2_18 aufgelisteten Feldern auf seinem Display anzeigen können.
[<=]

Tabelle 2: Tab_mobKT_ST2_18 Pflichtfelder zum Anzeigen auf dem Display

Feld
 Beschreibung
 Gilt für
 Führt zum Abbruch, wenn Feld nicht gelesen werden kann
Vorname
 Vorname des Versicherten
 KVK, eGK
 Ja
Nachname
 Nachname des Versicherten
 KVK, eGK
 Ja
Geburtsdatum
 Geburtsdatum des Versicherten
 KVK, eGK
 Ja
VersichertenNr.
 Versichertennummer
 KVK, eGK
 Ja
Kostenträger
 Name des Kostenträgers
 KVK, eGK
 Ja
Kassen-Nr.
 IK der abrechnenden Krankenkasse
 KVK, eGK
 Ja
EndeVersicherungsnachweis
 Ende des Versicherungsnachweises
 KVK, eGK
 Nein
Versichertenart
 Art des Versicherten (Mitglied, Familienversicherter, Rentner und ihre Familienangehörigen)
 KVK, eGK
 Ja
Status
(wird nur angezeigt, wenn für die Freischaltung der eGK die verwendete Leistungserbringerkarte zum Lesen der GVD berechtigt ist)
 Zuzahlungsstatus
 eGK
 Nein
Ruhender Leistungsanspruch
  • Art des Ruhens
(wird nur angezeigt, wenn für die Freischaltung der eGK die verwendete Leistungserbringerkarte zum Lesen der GVD berechtigt ist)
 Angabe des ruhenden Leistungsanspruchs (falls zum Behandlungszeitpunkt vorhanden)
 eGK
 Nein

VSDM-A_2880 - Fachmodul VSDM (mobKT): Versichertendaten auf dem Display unverändert anzeigen

Das Fachmodul VSDM (mobKT) MUSS die Versichertendaten unverändert auf dem Display anzeigen.

[<=]

A_18379 - Fachmodul VSDM (mobKT): unterstützte Versionen der eGK

Das Fachmodul VSDM (mobKT) MUSS das Auslesen der Versichertenstammdaten von einer eGK der Generation 2 und 2.1 unterstützen. [<=]

Die für die Fachanwendung VSDM spezifischen Speicherstrukturen der eGK werden in [gemSpec_eGK_Fach_VSDM] beschrieben. Die Version der VSDM Speicherstrukturen wird in EF.StatusVD.Version_Speicherstruktur-Datei der eGK vorgegeben.

VSDM-A_2980 - Fachmodul VSDM: unterstützte Versionen der VSDM Speicherstrukturen auf der eGK

Das Fachmodul VSDM (MobKT) MUSS, falls die EF.StatusVD.Version_Speicherstruktur-Datei der eGK eine unbekannte Version der VSDM Speicherstrukturen referenziert, mit der folgenden, auf dem Display angezeigten, Fehlermeldung abbrechen: „Nicht unterstützte Version der VSDM Speicherstrukturen der eGK“.

[<=]

VSDM-A_2995 - Fachmodul VSDM (mobKT): Unterstützung einer neuen VSD-Speicherstruktur

Der Hersteller des mobKTs MUSS innerhalb einer jeweils durch die gematik festzulegenden Frist eine neue Version der VSD-Speicherstruktur der eGK unterstützen. Der Hersteller muss die Unterstützung in Rahmen der Zulassung erklären. Die Mindestfrist zwischen der Bekanntgabe und der Verfügbarkeit einer ggf. neuen Firmware-Version beträgt 6 Monate.

[<=]

Im Falle von geänderten Anforderungen zu den VSD (z.B. aufgrund gesetzlicher Änderungen oder neuer Vereinbarungen zwischen den Vertragspartnern) kann eine Schemaänderung notwendig werden.

VSDM-A_2962 - Fachmodul VSDM (mobKT): Unterstützung einer neuen VSD-Schemaversion

Der Hersteller des mobKTs MUSS innerhalb einer jeweils durch die gematik festzulegenden Frist eine neue VSD-Schemaversion unterstützen. Der Hersteller muss die Unterstützung in Rahmen der Zulassung erklären. Die Mindestfrist zwischen der Bekanntgabe und der Verfügbarkeit einer ggf. neuen Firmware-Version beträgt 6 Monate.

[<=]

A_18380 - Fachmodul VSDM (mobKT): alte Versionen der eGK

Das Fachmodul VSDM (mobKT) SOLL beim Auslesen der Versichertenstammdaten von einer eGK mit einer älteren Version als Generation 2 mit einer Fehlermeldung abbrechen. [<=]

VSDM-A_2927 - Anzeigen zwischengespeicherter Versichertendaten

Das Fachmodul VSDM (mobKT) MUSS das Anzeigen zwischengespeicherten Versichertendaten auf dem Display gemäß [VSDM-A_2782] ermöglichen.
[<=]

VSDM-A_2928 - Drucken von Versichertendaten

Das Fachmodul VSDM (mobKT) KANN die Kommunikation mit einem Drucker unterstützen und das Ausdrucken von VSD- oder KVK-Daten auf ein Standardformular ermöglichen.

[<=]

VSDM-A_2878 - Fachmodul VSDM (mobKT): Übertragung von Arztnummer und die Betriebsstättennummer zum Drucker

Das Fachmodul VSDM (mobKT) MUSS beim Drucken (sofern unterstützt) von VSD- oder KVK-Daten auf ein Standardformular die Arztnummer und die Betriebsstättennummer zum Drucker übertragen.

[<=]

Die genaue Ausprägung des Druckmechanismus ist herstellerspezifisch.

VSDM-A_2877 - Fachmodul VSDM (mobKT): Bedruckungsvorschriften für Formularköpfe

Das Fachmodul VSDM (mobKT) MUSS beim Drucken (sofern unterstützt) von VSD- oder KVK-Daten auf ein Standardformular mindestens die Version 1.06 die Bedruckungsvorschriften für Formularköpfe gemäß [KBV_ITA_VGEX_Mapping_KVK_1.06#2.3.3] mit Ausnahme der Bedruckungsvorschriften zum ASV-Kennzeichen einhalten (siehe auch [BMV-Ä

2014]).

[<=]

Die Bedruckungsvorschriften zum ASV-Kennzeichen (Ambulante Spezialfachärztliche Versorgung) können optional implementiert werden.

VSDM-A_3049 - Fachmodul VSDM (mobKT): Bedruckungsvorschriften ASV- Kennzeichen

Das Fachmodul VSDM (mobKT) SOLL beim Drucken (sofern unterstützt) die Bedruckungsvorschriften zum ASV-Kennzeichen umsetzen.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung von [VSDM-A_3049] verzichtet werden.

Die Umsetzung der Bedruckungsvorschriften zum ASV-Kennzeichen bedingt zusätzliche Konfigurationsmöglichkeiten zur ASV-Teamnummer (analog zu [TIP1-A_3810] und [TIP1-A_3832]) und zusätzliche Logik (wenn ein Formularkopf mit ASV-Kennzeichen gedruckt werden soll, dann ist das ASV-Kennzeichen „1“ in das Statusfeld - Druckzeile 6, Position 30 - zu drucken und anstatt der Betriebstättennummer ist die ASV-Teamnummer zu drucken). Im Falle einer Umsetzung wird die Implementierung zum ASV-Kennzeichen auf Vollständigkeit und Korrektheit geprüft.

Mit neueren Versionen der Bedruckungsvorschriften können weitere zusätzliche Funktionalitäten eingeführt werden, die gegebenenfalls weitere Konfigurationsmöglichkeiten und zusätzliche Logik im Mobilen Kartenterminal erfordern, z.B. die Angabe eines TSS-Kennzeichens.

VSDM-A_3052 - Fachmodul VSDM (mobKT): Weitere Funktionalitäten aktueller Bedruckungsvorschriften

Bei Umsetzung einer höheren Version der Bedruckungsvorschriften als der in [VSDM-A_2877] angegebenen Mindestversion SOLL das Fachmodul VSDM (mobKT) alle Funktionalitäten dieser Bedruckungsvorschriften umsetzen.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung von [VSDM-A_3052] verzichtet werden.

VSDM-A_3050 - Version der Bedruckungsvorschriften

Der Hersteller des Mobilen Kartenterminals MUSS im Rahmen der Zulassung erklären, welche Version der Bedruckungsvorschriften [KBV_ITA_VGEX_Mapping_KVK] die gemäß [VSDM-A_2877] bzw. [VSDM-A_3051] implementierte Druckfunktionalität umsetzt. Der Hersteller MUSS ebenfalls angeben, ob die Bedruckungsvorschriften zum ASV-Kennzeichen gemäß [VSDM-A_3049] implementiert sind und welche Funktionalitäten gemäß [VSDM-A_3052] der angegebenen Version der Bedruckungsvorschriften nicht umgesetzt wurden. Der Hersteller MUSS diese Informationen öffentlich zugänglich machen.

[<=]

Die gematik wird die Information zur umgesetzten Version der Bedruckungsvorschriften und ggf. Ausnahmen zu bestimmten Funktionalitäten der Bedruckungsvorschriften im Rahmen der Veröffentlichung der Zulassung mit veröffentlichen.

VSDM-A_3051 - Fachmodul VSDM (mobKT): Aktuelle Bedruckungsvorschriften für Formularköpfe

Das Fachmodul VSDM (mobKT) SOLL über [VSDM-A_2877] hinaus beim Drucken (sofern unterstützt) von VSD- oder KVK-Daten auf ein Standardformular die Bedruckungsvorschriften für Formularköpfe gemäß [KBV_ITA_VGEX_Mapping_KVK] einhalten.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung von [VSDM-A_3051] verzichtet werden.

VSDM-A_2903 - Fachmodul VSDM (mobKT): Löschen von VSD

Der Hersteller des Mobilen Kartenterminals MUSS den Leistungserbringer in der Benutzerdokumentation darauf hinweisen, dass dieser die zwischengespeicherten Versichertenstammdaten aus Datenschutzgründen spätestens nach Wegfall der Zweckbindung (Quartalsabrechnung) aus dem Zwischenspeicher löschen muss, falls diese nicht schon vorher an das PVS übertragen wurden.

[<=]

5.3.2 VSD von eGK im mobilen Einsatzszenario lesen

VSDM-A_2766 - Fachmodul VSDM (mobKT): Aktivitäten beim Lesen von der eGK

Das Fachmodul VSDM (mobKT) MUSS beim Lesen der Versichertendaten von der eGK die Aktivitäten gemäß Tab_mobKT_ST2_10 durchführen.

[<=]

Zusätzlich zu den in [gemSysL_VSDM] geforderten Aktivitäten, müssen die VSD im Zwischenspeicher des Mobilen Kartenterminals abgelegt werden.

VSDM-A_2876 - Fachmodul VSDM (mobKT): Speicherung von VSD und Protokollierungsdaten im dafür vorgesehenen Zwischenspeicher

Das Fachmodul VSDM (mobKT) MUSS VSD sowie der zugehörigen Protokollierungsdaten ausschließlich im dafür vorgesehenen Zwischenspeicher des Mini-PS persistieren.
[<=]

Tabelle 3 : Tab_mobKT_ST2_10 – VSDM-UC_14 Aktivitäten

Schritt
 Aktivität
 TUCs
1
 Technische Nutzbarkeit und Offline-Gültigkeit der eGK prüfen
 TUC_MOKT_418 checkEGK, TUC_MOKT_438 checkEGKAuthCertificate
2
 Echtheit der beteiligten Karten prüfen
 TUC_MOKT_220 fulfillAccessConditions
3
 VSD-Status-Container Lesen
 TUC_MOKT_202 readFile
4
 PD und VD von eGK lesen
 TUC_MOKT_202 readFile
5
 GVD von eGK lesen
 TUC_MOKT_202 readFile
6
 Protokolleintrag auf eGK schreiben
 TUC_MOKT_406 writeEGKAudit
7
 PD, VD und GVD im Zwischenspeicher ablegen
 TUC_MOKT_010 writeToInternalStorage
8
 Anzeigen des gelesen Datensatzes im Display

VSDM-A_2725 - Fachmodul VSDM (mobKT): Technische Fehler beim Lesen von VSD

Das Fachmodul VSDM (mobKT) MUSS das Lesen von VSD von der eGK mit der Fehlermeldung "Technischer Lesefehler" und dem jeweiligen Fehlercode des TUCs abbrechen, wenn ein technischer Fehler auftritt.

[<=]

VSDM-A_2963 - Fachmodul VSDM (mobKT): Nicht bekanntes Schema beim Lesen von VSD

Das Fachmodul VSDM (mobKT) MUSS, falls das Schema der Versichertenstammdaten nicht bekannt ist, die Verarbeitung fortführen.

[<=]

Damit können zukünftige Änderungen im Schema rückwärtskompatibel sein.

VSDM-A_3000 - Fachmodul VSDM (mobKT): Weitere Prüfungen beim Lesen von VSD

Das Fachmodul VSDM (mobKT) MUSS das Lesen von VSD von der eGK und die Ablage im Zwischenspeicher gemäß VSDM-A_2766 in folgenden Fällen mit einer entsprechenden Fehlermeldung gemäß Kapitel 6.2.4 abbrechen:

  • Daten im Container nicht lesbar (z.B. Fehler beim Entpacken des gezippten Files),
  • XML nicht gültig (well-formed) oder
  • ein XML-Element ist nicht korrekt gefüllt oder nicht vorhanden, das in Tabelle Tab_mobKT_ST2_18 als „Führt zum Abbruch, wenn Feld nicht gelesen werden kann“ gekennzeichnet ist.
[<=]

Das Fachmodul VSDM (mobKT) macht für die gelesenen VSD keine XML-Schema-Validierung, sondern liest die in der Tabelle Tab_mobKT_ST2_18 aufgelistete Pflichtfelder für das anschließende Anzeigen auf dem Display. Falls einige der den Pflichtfeldern entsprechenden Elemente nicht aus den gelesenen VSD extrahiert werden können (z.B. aufgrund einer XML Schema Änderung, indem Namen einiger XML-Elementen geändert wurden) und der Fehler entsprechend Tab_mobKT_ST2_18 nicht zum Abbruch führen soll, wird das mobKT die Verarbeitung fortsetzen und nur die erkannten Pflichtfelder anzeigen.

5.3.2.1 Technische Nutzbarkeit und Offline-Gültigkeit der eGK prüfen

Das Fachmodul VSDM (mobKT) muss mittels TUC_MOKT_418 checkEGK und TUC_MOKT_438 checkEGKAuthCertificate die Aktivität „Technische Nutzbarkeit und Offline-Gültigkeit der eGK prüfen“ ausführen, indem sie die Vorgaben der Tabelle 4 prüft.

VSDM-A_2714 - Fachmodul VSDM (mobKT): technische Nutzbarkeit und Offline-Gültigkeit der eGK prüfen

Das Fachmodul VSDM (mobKT) MUSS, wenn beim Prüfen der technischen Nutzbarkeit und Offline-Gültigkeit der eGK ein Fehlerzustand der Tabelle Tab_mobKT_ST2_11 eintritt, die Verarbeitung abbrechen und die entsprechende Fehlermeldung anzeigen.
[<=]

Tabelle 4 : Tab_mobKT_ST2_11 – Fehlerzustände Technische Nutzbarkeit und Offline-Gültigkeit der eGK prüfen

Fehlerzustand
 Auslöser
 Fehlercode
 Fehlermeldung (max. 26 Zeichen)
Karte gesperrt
 Im Falle der eGK bedeutet dies, das DF.HCA gesperrt ist
 1120
 Karte gesperrt
Karte ungültig
 AUT-Zertifikat ist nach Offline-Prüfung zeitlich nicht gültig
 1501
 Karte ungültig

Eine weitergehende Prüfung des AUT-Zertifikats, z.B. auf gültige Signatur, soll nicht durchgeführt werden, da das Mobile Kartenterminal nicht die Liste der vertrauenswürdigen Zertifikatsherausgeber kennt. Im mobilen Einsatzszenario ohne Onlineverbindung ist es nicht möglich, die Aktualität dieser Liste zu gewährleisten.

5.3.2.2 Echtheit der beteiligten Karten prüfen

VSDM-A_2762 - Fachmodul VSDM (mobKT): Echtheit der beteiligten Karten prüfen

Das Fachmodul VSDM (mobKT) MUSS die Echtheit der beteiligten Karten prüfen, indem mittels TUC_MOKT_220 fulfillAccessConditions eine gegenseitige C2C-Authentisierung durchführt.

[<=]

Der Ablauf der C2C-Authentisierung ist in Kapitel 10.1.7 dargestellt.

VSDM-A_2763 - Fachmodul VSDM (mobKT): HPC im Ablauf freischalten

Das Fachmodul VSDM (mobKT) MUSS, falls die Leistungserbringerkarte (SMC-B/HBA) noch nicht freigeschaltet ist, den Anwender dazu im Ablauf auffordern.

[<=]

5.3.2.3 VSD Status Container Lesen

Das Fachmodul VSDM (mobKT) muss das Statusflag im Container EF.StatusVD mittels TUC_MOKT_202 readFile lesen. Der Wert 1 im Element Status weist auf eine nicht abgeschlossene Transaktion und damit inkonsistente VSD hin.

VSDM-A_2717 - Fachmodul VSDM (mobKT): VSD Status Container prüfen

Das Fachmodul VSDM (mobKT) MUSS, wenn der Status-Container im Feld Status den Wert '1' enthält, die Verarbeitung abbrechen und die entsprechende Fehlermeldung gemäß Tab_mobKT_ST2_13 anzeigen.

[<=]

Die Details der Datenstruktur von EF.StatusVD sind für die eGK der Generation 2 und 2.1 in [gemSpec_eGK_Fach_VSDM] spezifiziert.

Tabelle 5: Tab_mobKT_ST2_13 – Fehlerzustände VSD Status Container Lesen

Fehlerzustand
 Auslöser
 Fehlercode
 Fehlermeldung (max. 26 Zeichen)
VSD ungültig/nicht konsistent
 EF.StatusVD ist ‚1’
 3001
 Daten inkonsistent

5.3.2.4 PD und VD von eGK lesen

VSDM-A_2718 - Fachmodul VSDM (mobKT): PD und VD lesen

Das Fachmodul VSDM (mobKT) MUSS die PD und VD aus den Containern EF.PD und EF.VD der eGK mittels TUC_MOKT_202 readFile lesen.

[<=]

VSDM-A_2764 - Fachmodul VSDM (mobKT): Warnung wenn kein Versicherungsschutz besteht

Das Fachmodul VSDM (mobKT) MUSS bei von der eGK eingelesenen Versichertendaten durch Vergleich der in den Feldern "Versicherungsschutz.Ende" und "Versicherungsschutz.Beginn" eingetragenen Werten mit der Systemuhr überprüfen, ob ein Versicherungsschutz besteht, und, wenn kein Versicherungsschutz besteht, die entsprechende Warnmeldung gemäß Tab_mobKT_ST2_14 auf dem Display des Kartenterminals anzeigen.

[<=]

Die XML-Elemente Beginn und Ende finden sich in den allgemeinen Versichertendaten im Element Versicherter unterhalb des Elements Versicherungsschutz. Falls die Elemente Beginn oder Ende leer sind, entfällt die jeweilige Prüfung.

Tabelle 6: Tab_mobKT_ST2_14 – Durch das Fachmodul VSDM (mobKT) zu erzeugende Warnmeldung

Zustand
 Warnmeldung
Beginn noch nicht erreicht
 Der Versicherungsschutz hat noch nicht begonnen.
Ende bereits erreicht
 Das Ende des Versicherungsschutzes ist erreicht

VSDM-A_2985 - Fachmodul VSDM (mobKT): Warnung bei ruhendem Leistungsanspruch

Das Fachmodul VSDM (mobKT) MUSS dem Benutzer eine Warnmeldung gemäß Tab_mobKT_ST2_19 auf dem Display des Kartenterminals anzeigen, wenn die eGK aufgrund eines ruhenden Leistungsanspruchs keinen gültigen oder einen eingeschränkten Leistungsanspruchsnachweis darstellt.

[<=]

Der XML-Element RuhenderLeistungsanspruch findet sich in den geschützten Versichertendaten.

Tabelle 7: Tab_mobKT_ST2_19 – Durch das Fachmodul VSDM (mobKT) zu erzeugende Warnmeldung

Zustand
 Warnmeldung
Ein vollständiger Leistungsanspruch
 Ein vollständiger ruhender Leistungsanspruch besteht
Ein eingeschränkt ruhender Leistungsanspruch
 Ein eingeschränkt ruhender Leistungsanspruch besteht

5.3.2.5 GVD von eGK lesen

VSDM-A_2719 - Fachmodul VSDM (mobKT): GVD lesen

Das Fachmodul VSDM (mobKT) MUSS die GVD aus dem Container EF.GVD der eGK mittels TUC_MOKT_202 readFile lesen, wenn bei der Freischaltung der eGK mittels C2C die Rolle der dabei verwendeten Leistungserbringerkarte zum Lesen der GVD berechtigt ist.

[<=]

Die Berechtigung der Leistungserbringerkarte wird vorher im Schritt 5.3.2.2 geprüft.

Nicht berechtigte Rollen sind gemäß [gemSpec_eGK_P2] bzw. [gemSpec_eGK_ObjSys] CHA.7 (Mitarbeiter im Rettungswesen) und CHA.1 SMC–B eKiosk.

Die eGK enthält derzeit eine Kopie der GVD im EF.VD Container, welcher nicht zugriffsgeschützt ist.

VSDM-A_2783 - Fachmodul VSDM (mobKT): GVD nicht aus dem Container EF.VD lesen

Das Fachmodul VSDM (mobKT) DARF NICHT die GVD aus dem Container EF.VD der eGK lesen.

[<=]

5.3.2.6 Protokolleintrag auf eGK schreiben

VSDM-A_2720 - Fachmodul VSDM (mobKT): Protokolleintrag auf eGK schreiben

Das Fachmodul VSDM (mobKT) MUSS den Protokolleintrag zum Protokollieren der Lesezugriffe auf die GVD mittels TUC_MOKT_406 writeEGKAudit gemäß Tab_mobKT_ST2_15 erzeugen und in den Container EF.Logging schreiben.
[<=]

Tabelle 8: Tab_mobKT_ST2_15 – Durch das Fachmodul VSDM (mobKT) zu erzeugender Protokolleintrag

Data-Type
 Type of Access
 Auslöser
1
 R
 Erfolgreicher, lesender Zugriff auf die geschützten Versichertendaten.

5.3.2.7 PD, VD, GVD und StatusVD im Zwischenspeicher ablegen

VSDM-A_2721 - Fachmodul VSDM (mobKT): PD, VD, GVD und StatusVD im Zwischenspeicher ablegen

Das Fachmodul VSDM (mobKT) MUSS die von der eGK gelesenen PD, VD, GVD und StatusVD sowie die Protokollierungsdaten (Erfassungszeitpunkt und Zulassungsnummer) mittels TUC_MOKT_010 writeToInternalStorage im sicheren Zwischenspeicher ablegen, um den Schutzbedarf an die VSD durchzusetzen und dabei für den Zeitstempel die Systemuhr des Mobilen Kartenterminals verwenden.

[<=]

Die Sicherheitsmechanismen sind in Kapitel 3.5 beschrieben.

VSDM-A_2768 - Fachmodul VSDM (mobKT): Versichertendaten im Zwischenspeicher überschreiben

Das Fachmodul VSDM (mobKT) MUSS, falls die Daten des Versicherten in demselben Quartal bereits im Zwischenspeicher abgelegt wurden, die Versichertendaten im sicheren Zwischenspeicher überschreiben. Ein Überschreiben der Versichertendaten im Zwischenspeicher ist nur bezogen auf denselben Kartentyp (eGK bzw. KVK) möglich.

[<=]

Eindeutiges Identifikationskriterium des Versicherten auf der eGK ist die lebenslang gültige Krankenversichertennummer (10-stelliger unveränderlicher Teil). Die eindeutige Identifikation im mobKT erfolgt über diese KVNR. Für die KVK existiert kein eindeutiges Identifikationskriterium. Die Prüfung kann daher anhand der Kriterien Vorname, Nachname, Geburtsdatum erfolgen.

5.3.3 Versichertendaten von KVK im mobilen Einsatzszenario lesen

VSDM-A_2765 - Fachmodul VSDM (mobKT): Aktivitäten KVK Lesen

Das Fachmodul VSDM (mobKT) MUSS beim Lesen der Versichertendaten von der KVK die Aktivitäten gemäß Tab_mobKT_ST2_16 durchführen.

[<=]

Zusätzlich zu den in [gemSysL_VSDM] geforderten Aktivitäten müssen die Versichertendaten im Zwischenspeicher des Mobilen Kartenterminals abgelegt werden.

Tabelle 9: Tab_mobKT_ST2_16 – VSDM-UC_14 Aktivitäten

Schritt
 Aktivität
 TUCs
1
 Versichertendaten von KVK lesen
 TUC_MOKT_202 readFile
2
 Versichertendaten prüfen
3
 Versichertendaten im Zwischenspeicher ablegen
 TUC_MOKT_010 writeToInternalStorage
4
 Anzeigen des gelesen Datensatzes im Display

5.3.3.1 Versichertendaten von KVK lesen

VSDM-A_2730 - Fachmodul VSDM (mobKT): KVK Lesen

Das Fachmodul VSDM (mobKT) MUSS die Versichertendaten von der KVK mittels TUC_MOKT_202 readFile lesen

[<=]

5.3.3.2 Versichertendaten prüfen

Das Fachmodul VSDM (mobKT) muss die Vorgaben aus Anhang B – Prüfvorgaben KVK prüfen.

VSDM-A_2731 - Fachmodul VSDM (mobKT): KVK prüfen

Das Fachmodul VSDM (mobKT) MUSS, falls die Daten der KVK nicht den Vorgaben in Anhang B – Prüfvorgaben KVK entsprechen, den Lesevorgang mit der Fehlermeldung gemäß Tab_mobKT_ST_17 abrechen.
[<=]

Tabelle 10: Tab_mobKT_ST2_17 – Fehlerzustände Versichertendaten prüfen

Fehlerzustand
 Auslöser
 Fehlercode
 Fehlermeldung (max. 26 Zeichen)
KVK Prüfsumme falsch, Daten korrupt
 Die Überprüfung der Prüfsumme des KVK Satzes oder der Vorgaben aus Anhang B – Prüfvorgaben KVK ergab einen Fehler.
 3021
 Daten inkonsistent

VSDM-A_2732 - Fachmodul VSDM (mobKT): Felder hinzufügen

Das Fachmodul VSDM (mobKT) MUSS nach der KVK-Prüfung die Felder EinleseDatum, Zulassungsnummer und PrüfsummeZusatz gemäß Tab_mobKT_ST2_03 den Daten der KVK hinfügen.
[<=]

Tabelle 11: Tab_mobKT_ST2_03 Festformat des VersichertenDatenTemplates der KVK

Datenobjekt
 Länge in Bytes
 Format
EinleseDatum*
 8
 TTMMJJJJ
Zulassungsnummer*
 38
 alphanumerisch
PrüfsummeZusatz*
 1
 XOR

*) Die Datenfelder Zulassungsnummer, EinleseDatum und PrüfsummeZusatz sind nicht auf der KVK vorhanden und werden vom Mobilen Kartenterminal erzeugt. Der PrüfsummeZusatz wird über die Datenelemente EinleseDatum und ZulassungsNummer gebildet.

VSDM-A_2769 - Fachmodul VSDM (mobKT): "GültigkeitsDatum" mit der Systemuhr überprüfen

Das Fachmodul VSDM (mobKT) MUSS bei von der KVK eingelesenen Versichertendaten durch Vergleich des im Feld "GültigkeitsDatum" eingetragenen Wertes mit der Systemuhr überprüfen, ob das Gültigkeitsdatum der Karte überschritten ist und wenn das Gültigkeitsdatum überschritten ist, die Warnmeldung „Das Gültigkeitsdatum der Karte ist überschritten“ auf allen Displays des Kartenterminals anzeigen.

[<=]

Zusätzlich kann auf diese Warnung optisch oder akustisch hingewiesen werden.

5.3.3.3 Versichertendaten im Zwischenspeicher ablegen

VSDM-A_2734 - Fachmodul VSDM (mobKT): VSD im Zwischenspeicher ablegen

Das Fachmodul VSDM (mobKT) MUSS die von der KVK gelesenen VSD mittels TUC_MOKT_010 writeToInternalStorage im sicheren Zwischenspeicher ablegen, um den Schutzbedarf an die VSD durchzusetzen.

[<=]

Die Sicherheitsmechanismen sind in Kapitel 3.5 beschrieben. Wurden die Daten des Versicherten im demselben Quartal bereits eingelesen, werden sie inklusive der Protokolldaten (Erfassungszeitpunkt und Zulassungsnummer) im Zwischenspeicher überschrieben. [VSDM-A_2768]

6 Anforderungen an das Mini-Primärsystem

Das Mini-PS hat die geforderten Anwendungsfälle bereitzustellen.

6.1 Abbildung fachlicher Anwendungsfälle auf technische Use Cases

Der Leistungserbringer kann die im Folgenden als Ellipsen dargestellten fachlichen Anwendungsfälle direkt über die Benutzerschnittstelle des Mobilen Kartenterminals auslösen. Abbildung 4 stellt die Anwendungsfälle der Fachanwendung VSDM im Mobilen Kartenterminal dar.

Abbildung 4: Anwendungsfälle der Fachanwendung VSDM

Abbildung 5 beschreibt Use Cases, die nicht von Fachanwendungen bereitgestellt werden.

Abbildung 5: Nicht fachliche Anwendungsfälle

6.2 Benutzerführung

6.2.1 Allgemeine Anforderungen

TIP1-A_4974 - Anzeige Systemzeit

Das Mini-PS des Mobilen Kartenterminals MUSS die Systemzeit im Rahmen des Startvorgangs bis zum ersten fachlichen Aufruf mindestens einmal lesbar anzeigen.

[<=]

Hierunter fällt auch die Möglichkeit zur Anzeige der Systemzeit in der Betriebsbereitschaftsanzeige bzw. im Rahmen der Freischaltung der berechtigten Karte.

TIP1-A_4975 - Prüfung Systemzeit

Der Hersteller des Mobilen Kartenterminals MUSS in der Benutzerdokumentation den Leistungserbringer darauf hinweisen, dass er die Systemzeit regelmäßig zu prüfen hat.

[<=]

6.2.2 Fachliche Aufrufe

TIP1-A_4921 - Mobiles KT: Fachliche Anwendungsfälle

Das Mini-PS des Mobilen Kartenterminals MUSS die nach Kapitel 6.1 geforderten fachlichen Anwendungsfälle bereitstellen.

[<=]

Eventuelle automatische Aufrufe von fachlichen Abläufen, z. B. beim Stecken der eGK, können herstellerspezifisch angeboten werden(Gegebenenfalls auch konfigurierbar).

6.2.3 Warnmeldungen

Vom Zertifikatsdienst des Mini-AK wird geprüft, ob die Gültigkeit der berechtigten Karte gegeben ist.

TIP1-A_3872 - Mobiles KT: Information bei Ablauf der Zertifikatsgültigkeit

Das Mini-PS des Mobilen Kartenterminals SOLL zur Erhöhung der Benutzerfreundlichkeit den Leistungserbringer auf den Ablauf der Gültigkeit des Zertifikates zu dem konfigurierten Zeitpunkt, spätestens jedoch sechs Wochen vor Ablauf des X.509-Zertifikates (EF.C.HP.AUT bzw. EF.C.HCI.AUT) der berechtigten Karte (HBA oder SMC-B), aufmerksam machen.

[<=]

TIP1-A_3873 - Mobiles KT: Konfiguration Zeitpunkt Warnung vor Ablauf Zertifikatsgültigkeit

Das Mini-PS des Mobilen Kartenterminals SOLL dem Leistungserbringer ermöglichen, den Zeitpunkt der Warnung zum Ablauf der Gültigkeit des X.509-Zertifikates der berechtigten Karte (HBA oder SMC-B) zu konfigurieren.

[<=]

TIP1-A_3856 - Mobiles KT: Einschränkungen bei Ablauf der Zertifikatsgültigkeit

Der Hersteller des Mobilen Kartenterminals MUSS den Benutzer im Handbuch des Mobilen Kartenterminals über Einschränkungen im Falles des Ablaufs der Gültigkeit des Zertifikates der berechtigten Karte informieren.

[<=]

Weitere verpflichtende Warnmeldungen sind nicht umzusetzen. Herstellerspezifische Meldungen sind freigestellt.

6.2.4 Fehlermeldungen

TIP1-A_4261 - Mobile Szenarien: Mechanismen zur Fehleranzeige

Das Mobile Kartenterminal MUSS einen Fehler optisch (z. B. LED) signalisieren.
[<=]

Die Art der Signalisierung ist herstellerspezifisch.

TIP1-A_4426 - Mobiles KT: Fehlersignalisierung über erweitertes Display

Das Mobile Kartenterminal MUSS die Signalisierung eines Fehlers über das erweiterte Display mittels eines für den Nutzer verständlichen Textes sowie eines spezifischen Fehlercodes (hierbei müssen z.B. die Fehlercodes der TUCs des Mini-AK verwendet werden, welche exaktere Informationen über die Fehlerursache liefern) realisieren.

[<=]

TIP1-A_3697 - Mobile Szenarien: Interpretation der Fehleranzeige

Der Hersteller des Mobilen Kartenterminals MUSS die Interpretation des von dem mobilen Kartenterminal signalisierten Fehlers im Benutzerhandbuch beschreiben.

[<=]

TIP1-A_4266 - mobile Szenarien: Abfrage Statusinformation über Managementschnittstelle

Das Mobile Kartenterminal MUSS es dem Benutzer ermöglichen, dass eventuelle, zur Fehleranalyse notwendige weiterführende Informationen über die Managementschnittstelle des Geräts abgefragt werden können.

[<=]

6.3 Zwischenspeicher

TIP1-A_4404 - Zwischenspeicher zur Sicherung von Daten

Das Mini-PS des Mobilen Kartenterminals MUSS über einen Zwischenspeicher zur Speicherung von Daten verfügen.

[<=]

TIP1-A_3708 - Erhaltung zwischengespeicherter Daten ohne Strom

Das Mobile Kartenterminal SOLL in seinem Speicher die in ihm zwischengespeicherten Daten auch ohne Strom erhalten.

[<=]

TIP1-A_4412 - Erhaltung zwischengespeicherter Daten mittels Pufferbatterie

Das Mobile Kartenterminal MUSS, wenn der Speicher des Mobilen Kartenterminals nicht in der Lage ist, die Daten auch ohne Strom zu erhalten, über eine Pufferbatterie verfügen, um kurzzeitige Stromausfälle zu überbrücken.

[<=]

TIP1-A_4951 - Dimensionierung des Zwischenspeichers: Mindestanzahl zwischenzuspeichernder VSD

Das Mini-PS des Mobilen Kartenterminals SOLL seinen Zwischenspeicher so dimensionieren, dass mindestens 275 verschlüsselte VSD-Datensätze in der maximalen Größe samt zugehörigen Protokollierungsdaten zwischengespeichert werden können.

[<=]

Die maximale Größe eines VSD-Datensatzes lässt sich anhand der Größenangabe „numberOfOctet“ in [gemSpec_eGK_ObjSys#5.4.2,5.4.4,5.4.9] berechnen. Zusätzlich sind die in [VSDM-A_2881] geforderten Erweiterungen zu berücksichtigen, wobei Zulassungsnummer und Prüfsumme nicht zwangsläufig zu jedem Datensatz zwischengespeichert werden müssen.

TIP1-A_4403 - Schutz der zwischengespeicherten Daten

Der Zwischenspeicher des Mini-PS des Mobilen Kartenterminals MUSS die in ihm zwischengespeicherten Daten vor Löschen, Überschreiben, unberechtigtem Auslesen und Manipulation über externe Schnittstellen schützen.

[<=]

TIP1-A_3756 - mobile Szenarien: Verschlüsselung zwischenzuspeichernder Daten

Das Mobile Kartenterminal MUSS sicherstellen, dass die zwischengespeicherten Daten mittels Verschlüsselungsdienst des Mini-AK unter Verwendung eines hybriden Verfahrens nach [gemSpec_Krypt] verschlüsselt sind.

[<=]

TIP1-A_3808 - Verschlüsselung zwischengespeicherter Daten

Das Mobile Kartenterminal MUSS sicherstellen, dass der symmetrische Schlüssel, mit dem die Daten verschlüsselt wurden, im Zuge des hybriden Verfahrens mit dem öffentlichen ENC-Key der freigeschalteten berechtigten Karte verschlüsselt wird.

[<=]

TIP1-A_3789 - Mobiles KT: unterschiedliche berechtigte Karten für die Verschlüsselung und Ablage von Daten im Zwischenspeicher

Das Mobile Kartenterminal MUSS die Nutzung von unterschiedlichen berechtigten Karten für die Verschlüsselung und Ablage von Daten im Zwischenspeicher des Mini-PS unterstützen.

[<=]

6.3.1 Zugriffsschutz Zwischenspeicher

TIP1-A_4270 - Zugriff auf zwischengespeicherte Daten erst nach Authentisierung zugelassen.

Das Mini-PS des Mobilen Kartenterminals MUSS sicherstellen, dass, bevor es Zugriff auf die Daten im Zwischenspeicher erlaubt, der autorisierte Benutzer einen aktiven Authentifizierungsstatus erreicht hat, was bedeutet, dass das Mini-PS Zugriff auf eine freigeschaltete berechtigte Karte (HBA oder SMC-B) hat, die im Kartenterminal-Modul gesteckt ist.

[<=]

TIP1-A_3722 - Verlust der aktiven Authentifizierungsstatus

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn die berechtigte Karte im mobilen Kartenterminal den Sicherheitszustand verliert oder das Mini-PS den Zugriff auf die berechtigte Karte verliert, der Benutzer seinen aktiven Authentifizierungsstatus verliert.

[<=]

TIP1-A_3710 - Manuelles Rücksetzen des Authentifikationsstatus

Das Mobile Kartenterminal MUSS dem Benutzer ermöglichen, den Sicherheitsstatus des Mobilen Kartenterminals aktiv zurückzusetzen, wobei die Karte den Sicherheitszustand verlieren MUSS.

[<=]

TIP1-A_3850 - Automatisches Rücksetzen des Sicherheitsstatus bei Inaktivität

Das Mobile Kartenterminal MUSS sicherstellen, dass der Sicherheitsstatus des Benutzers sowie der Sicherheitszustand der berechtigten Karte nach der konfigurierten Zeit bei Benutzerinaktivität zurückgesetzt wird.

[<=]

TIP1-A_3851 - Automatisches Rücksetzen des Sicherheitsstatus bei Abschalten

Das Mobile Kartenterminal MUSS sicherstellen, dass der Sicherheitsstatus des Benutzers sowie der Sicherheitszustand der berechtigten Karte bei Abschalten des Gerätes zurückgesetzt wird.

[<=]

TIP1-A_3759 - Verhalten bei Rücksetzen des Sicherheitsstatus

Das Mobile Kartenterminal MUSS sicherstellen, dass bei Rücksetzen des Sicherheitsstatus alle entschlüsselten Daten sowie temporär erzeugte Schlüssel im mobilen Kartenterminal gelöscht werden.

[<=]

6.4 Zwischenspeichern von Daten

Die in diesem Abschnitt beschriebenen Vorgaben sind vom Mini-PS bei der Durchführung der fachlichen Abläufe mit Zwischenspeicherung einzuhalten (siehe Kapitel 6.1). Das Mini-PS speichert die von der EGK gelesenen VSD mit Protokolldaten ab. Die abzuspeichernden Daten setzen sich folgendermaßen zusammen:

Die VSD bestehen aus:

  • EF.StatusVD: Dem Status des Versichertendatensatzes
  • EF.PD: Den persönlichen Versichertendaten
  • EF.VD: Den allgemeinen Versicherungsdaten
  • EF.GVD: Den geschützten Versichertenstammdaten

Die Protokolldaten bestehen aus:

  • Dem Erfassungszeitpunkt des Datensatzes. Die Systemuhr des Mini-PS dient hierbei als Referenzuhr.
  • Der Zulassungsnummer des Mobilen Kartenterminals mit welchem die Daten gelesen wurden.

TIP1-A_3733 - Erhalt eventuell vorhandener Daten eines Versicherten bei Fehler während des Zwischenspeicherns

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn während der Zwischenspeicherung ein Fehler auftritt bzw. die Daten nicht zwischengespeichert werden können, eventuell vorhandene Daten desselben Versicherten erhalten bleiben.

[<=]

Das Format, in dem die Daten verschlüsselt und zwischengespeichert werden, ist herstellerspezifisch. Der Ablauf ist in Kapitel 10.2.1 „TUC_MOKT_010 writeToInternalStorage“ beschrieben.

TIP1-A_3798 - Mobiles KT: Keine Zwischenspeicherung zusätzlicher Daten

Das Mobile Kartenterminal DARF über die von Fachmodulen übergebenen Daten hinausgehende medizinische oder personenbezogene Daten des Versicherten wie z. B. Diagnoseschlüssel NICHT persistent speichern.

[<=]

6.5 Übertragen von Daten

Die in diesem Abschnitt beschriebenen Vorgaben sind vom Mini-PS bei der Durchführung der fachlichen Abläufe mit Übertragung von Daten zum Primärsystem einzuhalten (siehe Kapitel 6.1).

Die Übertragung der am Mobilen Kartenterminal zwischengespeicherten Daten an das Primärsystem erfolgt über eine Schnittstelle – protokollseitig auch Host-Schnittstelle genannt –, deren technische Ausprägung herstellerspezifisch sein kann (siehe auch Kapitel 3.3.6).

Es werden jeweils nur die Daten im Zwischenspeicher entschlüsselt und an das Primärsystem übertragen, die auch mit der berechtigten Karten zwischengespeichert wurden, die zur Übertragung an das Primärsystem verwendet wird.

TIP1-A_3694 - Mobile Szenarien: Zu übertragende Daten

Das Mini-PS des Mobilen Kartenterminals MUSS in der Lage sein, die zwischengespeicherten Daten an ein Primärsystem zu übertragen.

[<=]

TIP1-A_3691 - Übertragungsprotokoll bei herstellerspezifischer Host-Schnittstelle

Das Mobile Kartenterminal MUSS für die Übertragung zwischengespeicherter Daten an das Primärsystem CT-API gemäß [CT-API] als Protokoll verwenden.

[<=]

VSDM-A_2930 - Fachmodul VSDM (mobKT): Übertragungsformat der KVK-Daten an der Host-Schnittstelle

Das Fachmodul VSDM (mobKT) MUSS dem Benutzer wahlweise die Übertragung der KVK-Daten im ASN.1-Format oder im Festformat ermöglichen.

[<=]

Die Festlegung wird über Einstellungen innerhalb des Management-Moduls (siehe Kapitel 7.4.2) getroffen.

TIP1-A_3693 - Mobile Szenarien: Unverfälschtheit der Daten bei Übertragung

Das Mini-PS des Mobilen Kartenterminals MUSS seine Daten unverändert an das Primärsystem übertragen.

[<=]

TIP1-A_4272 - Mobile Szenarien: Fortschaltsperre

Das Mini-PS des Mobilen Kartenterminals MUSS bei der Übertragung von Datensätzen den übertragenen Datensatz mit der Ausführung des ersten READ Kommandos der Übertragung als übertragen markieren.

[<=]

TIP1-A_5374 - Mobile Szenarien: Fortschaltsperre, Nichtaufhebbarkeit der Markierung als übertragen

Das Mini-PS des Mobilen Kartenterminals MUSS sicherstellen, dass die Markierung eines Datensatzes als übertragen gemäß TIP1-A_4272 nicht aufgehoben werden kann, ohne den vollständigen Datensatz zu löschen.

[<=]

Eine erfolgreiche Übertragung der Daten wird vom Primärsystem angezeigt, indem es die übertragenen Daten im Rahmen des Übertragungsprotokolls explizit löscht.

TIP1-A_3695 - Mobile Szenarien: Sicherstellung der Fortschaltsperre während der Übertragung

Das Mini-PS des Mobilen Kartenterminals MUSS, falls ein als übertragen gekennzeichneter Datensatz am Mini-PS des mobilen Kartenterminal existiert, der mit der zur Übertragung verwendeten berechtigten Karte zwischengespeichert wurde, sicherstellen, dass nur dieser Datensatz an das Primärsystem übertragen werden kann (Fortschaltsperre).

[<=]

Um einen weiteren Datensatz lesen zu können, hat das Primärsystem den als übertragen markierten Datensatz zuerst zu löschen. Dadurch wird sichergestellt, dass der zuletzt übertragene Datensatz gelöscht wurde, bevor es den nächsten Datensatz übertragen kann (Fortschaltsperre).

Für die Übertragung von VSD muss das Mini-PS das in Kapitel 11 beschriebene Protokoll zur Kommunikation an der Host-Schnittstelle unterstützen.

TIP1-A_3871 - Mobile Szenarien: Übertragungsrhythmus zwischengespeicherter Daten

Der Hersteller des Mobilen Kartenterminals MUSS den Leistungserbringer in der Benutzerdokumentation darauf hinweisen, dass dieser die zwischengespeicherten Daten einmal täglich an sein Primärsystem übertragen soll.

[<=]

Dies ist insbesondere deswegen durchzuführen, weil die Daten mit der berechtigten Karte entschlüsselt werden müssen und dies im Falle des Verlustes nicht mehr durchgeführt werden kann.

6.5.1 Sonderfall Dockingstation

Falls das Mini-PS über einen Proxy (Dockingstation) an das Primärsystem angebunden wird, so muss der Proxy die Vorgaben, bezüglich der Schnittstellen und Protokolle zur Kommunikation mit dem Primärsystem, dieser Spezifikation erfüllen. Die interne Kommunikation zwischen Mini-PS und Proxy ist herstellerspezifisch, es muss jedoch sichergestellt werden, dass die zwischengespeicherten Daten (VSD), das jeweilige Erfassungsdatum und die Zulassungsnummer unverändert an das Primärsystem übertragen werden.

TIP1-A_3848 - Verhinderung von Ableiten von Daten durch die Dockingstation

Die Dockingstation des Mobilen Kartenterminals DARF, wenn das Mini-PS des Mobilen Kartenterminals über eine Dockingstation mit dem Primärsystem kommuniziert, die Daten NICHT über andere externe Schnittstellen als jene, die für die Übertragung der Daten an das Primärsystem vorgesehen sind, weitergeben.

[<=]

TIP1-A_3849 - Verhinderung von Zwischenspeichern von Daten durch die Dockingstation

Die Dockingstation des Mobilen Kartenterminals DARF, wenn das Mini-PS des Mobilen Kartenterminals über eine Dockingstation mit dem Primärsystem kommuniziert, die Daten NICHT dauerhaft speichern.

[<=]

TIP1-A_3855 - mobile Szenarien, Dockingstation: Löschen des Zwischenspeichers nach Übertragung

Die Dockingstation des Mobilen Kartenterminals MUSS, wenn das Mini-PS des mobilen Kartenterminal über diese mit dem Primärsystem kommuniziert, jeden Datensatz nach seiner Übertragung aus ihrem Speicher löschen.

[<=]

6.6 Gezieltes Löschen von zwischengespeicherten Daten

TIP1-A_4258 - Mobile Szenarien: Manuelles Löschen zwischengespeicherter VSD

Das Mini-PS des Mobilen Kartenterminals MUSS dem Benutzer ermöglichen, alle zwischengespeicherten Datensätze manuell, ohne vorherige Übertragung zu löschen.

[<=]

TIP1-A_3714 - Möglichkeit zum manuellen Löschen bereits übertragener Daten

Das Mobile Kartenterminal MUSS dem Benutzer ermöglichen, als übertragen markierte Datensätze am Mini-PS manuell zu löschen.

[<=]

TIP1-A_4259 - Mobile Szenarien: Einzelnes Löschen der zwischengespeicherten Daten

Das Mini-PS des Mobilen Kartenterminals MUSS dem Benutzer ermöglichen, gezielt einzelne Datensätze zu löschen.

[<=]

Einzelnes Löschen kann entweder direkt am Mini-PS im Rahmen der Benutzerführung durchgeführt werden oder über die Primärsystemschnittstelle. Die Ausprägung des Löschmechanismus ist herstellerspezifisch.

6.7 PIN-Verwaltung

In Abhängigkeit vom Zustand der berechtigten Karte (HBA oder SMC-B) muss das Mobile Kartenterminal dem Leistungserbringer die Möglichkeit anbieten, die PIN zu ändern bzw. die blockierte Karte mit Hilfe der PUK (Personal Unblocking Key) zu entsperren (siehe Kapitel 6.1).

6.7.1 PIN ändern

TIP1-A_3790 - Mobiles KT: PIN-Änderung für HBA und SMC-B über Benutzerschnittstelle

Das Mobile Kartenterminal MUSS dem Leistungserbringer ermöglichen, an der Benutzerschnittstelle die PIN.CH eines HBA und die PIN.SMC einer SMC-B ändern bzw. die mit einem Transportschutz versehene PIN.CH oder PIN.SMC in eine Echt-PIN umzuwandeln zu können.

[<=]

Für die Funktionalität „PIN ändern“ sei auf den technischen Use Case TUC_MOKT_419 changePIN verwiesen.

6.7.2 PIN entsperren

Die Karten haben einen Wiederholungszähler für die fehlerhafte PIN-Eingabe. Bei jeder Fehleingabe wird dieser Zähler dekrementiert. Erreicht der Zähler Null, wird die Karte in den Zustand „blockiert“ gesetzt, indem keine weiteren PIN-Eingaben mehr möglich sind. Mit Hilfe der PUK können dieser Zustand und der Zähler zurückgesetzt werden.

TIP1-A_3791 - Mobiles KT: PIN-Entsperren bei blockiertem HBA oder SMC-B

Das Mobile Kartenterminal MUSS es dem Leistungserbringer ermöglichen, die PIN entsperren zu können, wenn es erkennt, dass sich der HBA oder die SMC-B im Zustand "blockiert" befindet.

[<=]

Für die Funktionalität „PIN entsperren“ sei auf den technischen Use Case TUC_MOKT_421 unblockPIN verwiesen.

6.8 Daten drucken

Die in diesem Abschnitt beschriebenen Vorgaben sind vom Mini-PS bei der Durchführung des fachlichen Ablaufs „Daten drucken“ einzuhalten (siehe Kapitel 6.1).

TIP1-A_3809 - Kommunikation zwischen Mini-PS und Drucker

Das Mini-PS des Mobilen Kartenterminals KANN mit einem Drucker kommunizieren, um Daten ausdrucken zu können.

[<=]

TIP1-A_3811 - mobile Szenarien Ausdruck von Daten: Eingabe von Arzt- und Betriebsstättennummer während Druckvorgang

Das Mobile Kartenterminal MUSS dem Nutzer ermöglichen, vor dem Starten des Druckvorganges eventuell voreingestellte Werte für Betriebsstättennummer und Arztnummer zu ändern.

[<=]

Dies kann sowohl eine temporäre Änderung nur für einen Druckvorgang als auch eine dauerhafte ab diesem Druckvorgang sein. Somit kann diese Anforderung sowohl über die Managementfunktion umgesetzt werden als auch über einen Interaktionspunkt vor dem Start eines Druckvorgangs.

7 Anforderungen an das Management-Modul

7.1 Allgemeine Anforderungen

TIP1-A_3740 - Konfigurationsschnittstelle

Das Mobile Kartenterminal MUSS über eine Schnittstelle zur Administration verfügen.

[<=]

TIP1-A_3731 - Aktionen zur Diagnose von Betriebs und Fehlerzuständen über die Managementschnittstelle

Die Managementschnittstelle des Mobilen Kartenterminals MUSS für die Diagnose von Betriebs- und Fehlerzuständen mindestens folgende Aktionen ermöglichen:

  • Anzeige der aktuellen Konfiguration,
  • Abfragen der aktuellen Softwareversion.
[<=]

TIP1-A_3728 - Export und Import von Konfigurationsdaten über die Managementschnittstelle

Das Mobile Kartenterminal KANN den Export und Import der Konfigurationsdaten über die Managementschnittstelle ermöglichen.

[<=]

TIP1-A_3737 - mobile Szenarien Konfiguration: Export/Import von Konfigurationsdaten

Das Mobile Kartenterminal MUSS, wenn es den Import von Konfigurationsdaten über die Managementschnittstelle ermöglicht, diesen Import nur für baugleiche Geräte gewährleisten.

[<=]

TIP1-A_3729 - Einschränkungen der exportierbaren Konfigurationsdaten

Das Mobile Kartenterminal DARF, wenn Konfigurationsdaten über die Managementschnittstelle exportiert werden können, es NICHT ermöglichen, dass Schlüsselmaterial als Bestandteil der Konfigurationsdaten exportiert werden kann.

[<=]

TIP1-A_3741 - Rolle Administrator an der Managementschnittstelle

Das Mobile Kartenterminal MUSS an der Managementschnittstelle die Rolle Administrator vorsehen.

[<=]

Es können weitere Rollen z. B. Benutzer existieren.

TIP1-A_3742 - Berechtigungen der Rolle Administrator an der Managementschnittstelle

Das Mobile Kartenterminal MUSS sicherstellen, dass ausschließlich der Administrator berechtigt ist, Firmware Updates einzuspielen.
[<=]

TIP1-A_3859 - Berechtigungen der optionalen Rollen an der Managementschnittstelle

Das Mobile Kartenterminal MUSS sicherstellen, dass Rollen für die Administration - außer der Rolle Administrator - nur berechtigt sind, die aktuellen Einstellungen sich anzeigen zu lassen und das Kennwort des jeweiligen Benutzers zu ändern.

[<=]

TIP1-A_3726 - Schutz der Managementschnittstelle vor unberechtigtem Zugriff

Das Mobile Kartenterminal MUSS die Managementschnittstelle vor unberechtigtem Zugriff schützen.

[<=]

TIP1-A_3727 - Schutz der Managementschnittstelle durch Username und Passwort

Das Mobile Kartenterminal MUSS sicherstellen, dass die Managementschnittstelle des Mobilen Kartenterminals durch eine Kombination aus Username und Passwort oder einen mindestens gleich starken Mechanismus vor unberechtigtem Zugriff geschützt ist.

[<=]

TIP1-A_4269 - Authentifikation der Rolle Administrator

Das Mobile Kartenterminal KANN, wenn ausschließlich die Rolle Administrator implementiert ist, während der Authentifikation auf die Abfrage des Usernamen verzichten.

[<=]

TIP1-A_4941 - Mobiles KT: Hinweis Administratorauthentisierung

Das Managementmodul des Mobilen Kartenterminals MUSS im Fall, dass die Angabe des Usernamens gemäß [TIP1-A_4269] entfällt, bei der Eingabe des Kennwortes anzeigen, dass es sich um eine Administratorauthentisierung handelt.

[<=]

TIP1-A_5006 - Dokumentation der Konfiguration

Der Hersteller des Mobilen Kartenterminals MUSS den Anwender bzw. den Administrator in geeigneter Form (z. B. in der Benutzerdokumentation) über alle für die Konfiguration notwendigen Parameter einschließlich nötiger Eigenschaften (z. B. Zweck, Wertebereich, Abhängigkeiten) informieren.

[<=]

7.2 Kennwörter zur Sicherung der Managementschnittstelle

Im Folgenden werden die Anforderungen an die Kennwörter zur Sicherung der Managementschnittstellen aufgeführt.

TIP1-A_4268 - mobile Szenarien: Geschütztes Speichern von Kennwörtern

Das Mobile Kartenterminal MUSS sicherstellen, dass Kennwörter geschützt gespeichert werden, so dass sie nicht über externe Schnittstellen ausgelesen oder verändert werden können.

[<=]

Für alle Kennwörter zur Sicherung der Managementschnittstelle gelten folgende Anforderungen.

TIP1-A_3764 - Mindestlänge, zulässige Zeichen für Kennwörter

Das Mobile Kartenterminal MUSS sicherstellen, dass Kennwörter mindestens 8 Zeichen lang sind und mindestens aus Ziffern (‚0' bis ‚9') bestehen.

[<=]

TIP1-A_3749 - mobile Szenarien: weitere Zulässige Zeichen für Kennwörter

Das Mobile Kartenterminal KANN Kennwörter, die aus einer Mischung aus Ziffern, Buchstaben und Sonderzeichen bestehen, verwenden.

[<=]

TIP1-A_3750 - mobile Szenarien: Username nicht als Bestandteil des Kennwortes

Das Mobile Kartenterminal MUSS sicherstellen, dass der Username als Teilzeichenkette nicht Bestandteil des Kennwortes sein kann.

[<=]

TIP1-A_3751 - mobile Szenarien: Kennwörter nicht auf programmierbaren Funktionstasten

Das Mobile Kartenterminal MUSS sicherstellen, dass Kennwörter nicht auf programmierbaren Funktionstasten gespeichert werden können.

[<=]

TIP1-A_3752 - mobile Szenarien: Keine Klartextanzeige des Kennwortes während Eingabe

Das Mobile Kartenterminal DARF bei der Eingabe des Kennwortes dieses NICHT im Klartext anzeigen.

[<=]

TIP1-A_3834 - mobile Szenarien: Fehlerzähler für Falscheingaben von Kennworten

Das Mobile Kartenterminal MUSS für jedes Kennwort einen Fehlerzähler für die Fehlversuche bei der Kennworteingabe vorhalten.

[<=]

TIP1-A_3753 - mobile Szenarien: Sicherung des Fehlerzählers vor Veränderung

Das Mobile Kartenterminal MUSS sicherstellen, dass der Fehlerzähler nicht über externe Schnittstellen verändert werden kann.

[<=]

TIP1-A_5007 - mobile Szenarien: Abfrage Fehlerzähler

Das Mobile Kartenterminal KANN Fehlerzähler falscher Kennworteingaben von einem Benutzer abfragbar machen.

[<=]

TIP1-A_3835 - mobile Szenarien: Sperrzeiten bei mehrfachen Fehlversuchen der Kennworteingabe

Das Mobile Kartenterminal MUSS den Zugang des jeweiligen Benutzers oder Administrators zur direkten Managementschnittstelle ab der dritten aufeinander folgenden ungültigen Kennworteingabe sperren, wobei die Dauer der Sperrzeit von der Anzahl aufeinander folgender Fehlversuche abhängig sein MUSS.

Tabelle 12: Mindestsperrzeiten in Abhängigkeit der Anzahl ungültiger Kennworteingaben

Anzahl der aufeinander folgenden ungültigen Kennworteingaben

Mindestsperrzeit für die Kennworteingabe

3-6

1 Minute

7-10

10 Minuten

11-20

1 Stunde

ab 21

1 Tag


​​

[<=]

TIP1-A_3836 - mobile Szenarien: Erhalt des Fehlerzählers im spannungslosen Zustand

Das Mobile Kartenterminal MUSS Fehlerzähler falscher Kennworteingaben im spannungslosen Zustand erhalten.

[<=]

TIP1-A_3837 - mobile Szenarien: Erhalt der verstrichenen Wartezeit im spannungslosen Zustand

Das Mobile Kartenterminal KANN die bereits verstrichene Sperrzeit während einer Administratorenpasswort-Eingabe im spannungslosen Zustand erhalten und den Zugang nach Neustart nur für die verbleibende Zeit sperren.

[<=]

TIP1-A_3838 - mobile Szenarien: Wartezeit nach Reset ohne Erhalt der verstrichenen Wartezeit

Das Mobile Kartenterminal MUSS, falls es die bereits verstrichene Wartezeit nicht im spannungslosen Zustand erhält, die Sperrzeit nach einem Neustart, unabhängig von der bereits verstrichenen Sperrzeit, wieder der dem Fehlerzähler entsprechenden Mindestsperrzeit setzen.

[<=]

Zusätzliche, nicht normative Informationen zur Handhabung von Kennwörtern sind im vom BSI herausgegebenen Maßnahmenkatalog Organisation (M 2) Abschnitt 11 „Regelungen des Passwortgebrauchs“ [BSI_2005#2.11] beschrieben.

7.3 Durchführen und Anzeigen Ergebnis-Selbsttest

TIP1-A_3760 - Softwareselbsttest

Das Mobile Kartenterminal MUSS dem Nutzer ermöglichen, die Korrektheit der installierten Software überprüfen und erkennen zu können (Selbsttest).

[<=]

7.4 Konfigurationsbereiche

Dem Architekturansatz der Unterteilung in verschiedene Module folgend, muss das Management-Modul für alle anderen Module Konfigurationsmöglichkeiten bereitstellen.

Die Mechanismen der Konfiguration sind herstellerspezifisch.

7.4.1 Konfiguration des Kartenterminal-Moduls

Für das Kartenterminal-Modul sind keine verpflichtenden Konfigurationsmöglichkeiten vorgesehen. Herstellspezifische Einstellungen sind freigestellt.

7.4.2 Konfiguration des Mini-PS

VSDM-A_2931 - Fachmodul VSDM (mobKT): Konfigurationsmöglichkeit Festformat

Das Mini-PS des Mobilen Kartenterminals MUSS es dem Benutzer ermöglichen, das Format der Datenübertragung (Festformat oder ASN.1) einstellen zu können.

[<=]

Das Mini-PS muss des Weiteren das Einstellen des Zeitraums, ab welchem vor Ablauf eines Zertifikates eine Warnung erscheinen muss (siehe Kapitel 6.2) [TIP1-A_3873], ermöglichen.

7.4.3 Konfiguration des Mini-AK

TIP1-A_3725 - Managementschnittstelle zu Diagnose- und Konfigurationszwecken des Mini-AKs

Der Mini-AK des Mobilen Kartenterminals MUSS über eine Managementschnittstelle für Konfiguration und Diagnose verfügen.

[<=]

TIP1-A_3730 - Einstellungsmöglichkeiten über die Managementschnittstelle des Mini-AKs im Falle einer Einboxlösung

Die Managementschnittstelle des Mobilen Kartenterminals MUSS für die Konfiguration des Mini-AKs des Mobilen Kartenterminals als Einboxlösung folgende Einstellungen ermöglichen:

  • Sicherheitsinformationen
    1. Import (offline) von Cross-CVCs.
[<=]

Die durch die CVC-Root-CA für die Verwendung in der TI ausgegebenen Cross-CV-Zertifikate werden auf einem Server der CVC-Root-CA sowie in der TSL veröffentlicht (siehe [gemSpec_TSL]) und können dort entnommen werden. Eine ggf. notwendige Aufbereitung für den Import in das Mobile Kartenterminal erfolgt in Abhängigkeit vom implementierten Verfahren herstellerspezifisch. Um den Betrieb des Mobilen Kartenterminals mit Karten unterschiedlicher Roots nach einem planmäßigen (siehe [gemSpec_CVC_Root#TIP1-A_5215]) oder unplanmäßigen Root-Wechsel (siehe [gemSpec_CVC_Root#TIP1-A_5218]) zu ermöglichen, müssen diese Cross-CVCs im Mobilen Kartenterminal vorhanden sein.

TIP1-A_6484 - Anzahl Cross-CVCs

Das Mobile Kartenterminal MUSS zu einem Zeitpunkt mindestens sechzehn Cross-CV-Zertifikate speichern können.

[<=]

7.4.4 Konfiguration der Fachanwendungen

7.4.4.1 Fachmodul VSDM

Dieses Kapitel hat beabsichtigt keinen Inhalt. Es bleibt jedoch bestehen, um die Kapitelstruktur im Hinblick auf mögliche Verweise beizubehalten.

7.4.5 Konfiguration der Systemuhr

Die Systemzeit setzt sich aus Datum und Uhrzeit zusammen, wobei zwischen Datum, bestehend aus Jahr, Monat und Tag und Uhrzeit, bestehend aus Stunden, Minuten und Sekunden unterschieden wird.

TIP1-A_3745 - Systemuhr im Mini-PS: Aufteilung in Datum und Uhrzeit

Das Mobile Kartenterminal MUSS sicherstellen, dass, wenn keine VSD zwischengespeichert sind, die Uhrzeit und das Datum einstellbar sind.

[<=]

TIP1-A_4414 - Einschränkungen an das Einstellen des Datums bei zwischengespeicherten Daten

Das Mobile Kartenterminal MUSS sicherstellen, dass das einstellbare Datum der Systemuhr nicht veränderbar ist, solange noch VSD im Mini-PS des Mobilen Kartenterminals zwischengespeichert sind.

[<=]

Die Uhrzeit ist von dieser Einschränkung nicht betroffen und kann immer geändert werden.

7.4.6 Konfiguration der optionalen Druckerschnittstelle

TIP1-A_3810 - Aufnahme von Arzt- und Betriebstättennummer über das Mini-PS

Das Mobile Kartenterminal MUSS, wenn das Mini-PS des Mobilen Kartenterminals über die Möglichkeit verfügt, Daten an einen Drucker zu übertragen und auszudrucken, die Eingabe einer 9-stelligen Arztnummer und einer 9-stelligen Betriebsstättennummer ermöglichen.

[<=]

TIP1-A_3832 - Persistente Speicherung von Arzt- und Betriebsstättennummer am Mini-PS

Das Mini-PS des Mobilen Kartenterminals SOLL die Arzt- und Betriebsstättennummer (so vorhanden) persistent speichern.

[<=]

TIP1-A_4415 - Mobiles KT: konfigurierbares Druckmodul

Das Mobile Kartenterminal MUSS es ermöglichen, das Druckmodul mittels Konfiguration an geänderte Druckvorschriften anpassen zu können. Eine Realisierung der Anpassung an geänderte Druckvorschriften für über diese Konfigurationsmöglichkeiten des Druckmoduls hinausgehende komplexe Änderungen bleibt hiervon unberührt.

[<=]

Es wird empfohlen, dass das Mobile Kartenterminal so flexibel wie möglich an Änderungen der Druckvorschriften angepasst werden kann, ohne dass ein FW-Update notwendig ist. Unter flexibler Anpassbarkeit wird verstanden, dass

  • Felder bezüglich Druckzeile und Position auf dem Formularkopf frei positioniert werden können,
  • die Anzeige einzelner Felder aktiviert und deaktiviert werden kann und
  • ggf. zusätzliche Felder mit Konfigurationswerten belegt werden können.

TIP1-A_6059 - Mobiles KT: flexibel konfigurierbares Druckmodul

Das Mobile Kartenterminal SOLL über die in [TIP1-A_4415] beschriebene Konfigurierbarkeit hinaus ein von der Firmware unabhängiges Druckmodul besitzen, welches eine Anpassung des Formularkopfdrucks an geänderte Druckvorschriften gemäß [KBV_ITA_VGEX_Mapping_KVK] erlaubt. Der Hersteller des Mobilen Kartenterminals SOLL bei Änderung der Druckvorschriften zeitnah, spätestens jedoch 6 Monate nach Veröffentlichung der Änderung, eine aktualisierte Version des Druckmoduls, welches diese Änderungen umsetzt, zur Verfügung stellen.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung von [TIP1-A_6059] verzichtet werden.

TIP1-A_6060 - Mobiles KT: Zulassung einer neuen Version des Druckmoduls

Der Hersteller MUSS eine aktualisierte Version des Druckmoduls bei der gematik zur Zulassung einreichen.

[<=]

Die gematik wird im Rahmen der Veröffentlichung der Zulassungen die Information über eine neue Version des Druckmoduls und die durch diese Version des Druckmoduls umgesetzte Version der Bedruckungsvorschriften ebenfalls veröffentlichen.

7.4.7 Konfiguration des automatischen Rücksetzens des Sicherheitszustand bei Benutzerinaktivität

TIP1-A_5145 - Konfigurierbarkeit der Benutzerinaktivitätszeit

Das Mobile Kartenterminal MUSS dem Administrator ermöglichen, dass die Zeit bis zum automatischen Rücksetzen des Sicherheitszustands bei Benutzerinaktivität gemäß [TIP1-A_3850] konfigurierbar ist.

[<=]

TIP1-A_5146 - Intervall der Benutzerinaktivitätszeit

Das Mobile Kartenterminal MUSS für die Konfigurationsmöglichkeit gemäß [TIP1-A_5145] ausschließlich die Einstellung der Zeit von 1 bis 60 Minuten ermöglichen.

[<=]

TIP1-A_5147 - Benutzerinaktivitätszeit im Auslieferungszustand

Das Mobile Kartenterminal MUSS für die Benutzerinaktivitätszeit gemäß [TIP1-A_5145] den Wert von 60 Minuten im Auslieferungszustand aufweisen.

[<=]

8 Anforderungen an das erweiterte Display

TIP1-A_3854 - Mobiles Kartenterminal: erweitertes Display

Das Mobile Kartenterminal MUSS über ein erweitertes Display verfügen.

[<=]

TIP1-A_3723 - Dimensionierung des erweiterten Displays

Das erweiterte Display des Mobilen Kartenterminals MUSS mindestens ein Grafik-Display sein.

[<=]

TIP1-A_3843 - Mindestanzahl an durch ein erweitertes Display darstellbaren Zeilen und Zeichen

Das erweiterte Display des Mobilen Kartenterminals SOLL bei kleinster Schriftgröße mindestens 8 Zeilen á 16 Zeichen darstellen können.

[<=]

TIP1-A_3844 - Am erweiterten Display darstellbarer Zeichensatz

Das erweiterte Display des Mobilen Kartenterminals MUSS mindestens ISO-8859-15 kodierten Text darstellen können.

[<=]

TIP1-A_5085 - Beleuchtung erweitertes Display

Das erweiterte Display des Mobilen Kartenterminals SOLL beleuchtet sein, um einen Betrieb bei schlechten Lichtverhältnissen zu ermöglichen.

[<=]

Nur bei Geräten, die auf Basis eines migrationsfähigen mobilen Kartenterminals der Ausbaustufe 1 zugelassen werden, kann auf eine Umsetzung verzichtet werden.

8.1 Kommunikation mit dem erweiterten Display

TIP1-A_3853 - Externes Display am Mini-PS

Das Mobile Kartenterminal MUSS, wenn das erweiterte Display nicht in das Gehäuse des Mobilen Kartenterminals integriert ist, eine lokale Schnittstelle für den Anschluss des erweiterten Displays anbieten.

[<=]

TIP1-A_3762 - Verbindung zwischen Mini-PS und erweitertem Display

Das Mobile Kartenterminal MUSS, falls das erweiterte Display nicht in das Gehäuse des Mobilen Kartenterminals integriert ist, die Datenübertragung zwischen Mini-PS und erweitertem Display so realisieren (z.B. durch Kabel im Sichtbereich), dass es dem Leistungserbringer ermöglicht sicherzustellen, dass die Daten ausschließlich an das zur Übertragung bestimmte erweiterte Display gesendet werden.

[<=]

Die physikalische Ausprägung der Schnittstelle zwischen erweitertem Display und Mobilen Kartenterminal ist herstellerspezifisch.

8.2 Nutzbarkeit für das Kartenterminal-Modul

TIP1-A_4425 - Verwendung des erweiterten Displays zur PIN-Eingabe

Das erweiterte Display des Mobilen Kartenterminals MUSS, wenn es in das Gehäuse des Mobilen Kartenterminals integriert ist und die Anforderungen an das Display zur PIN-Eingabe erfüllt, als Display zur PIN-Eingabe verwendet werden.

[<=]

9 Anforderungen an die Systemuhr

TIP1-A_3709 - Erhaltung Systemzeit mittels Pufferbatterie

Das Mobile Kartenterminal MUSS über ein einstellbares Datum und eine einstellbare Uhrzeit mit batteriegepufferter Systemuhr verfügen.

[<=]

Ebenso benötigt der Mini-AK für die Zugriffsprotokollierung auf der eGK eine verlässliche Systemuhr. Anforderungen bezüglich der Einstellungen der Systemuhr sind in Kapitel 7.4.5 zu finden.

TIP1-A_3732 - Mobile Szenarien: Freilaufgenauigkeit eingesetzter Systemuhren

Das Mobile Kartenterminal MUSS sicherstellen, dass die eingesetzten Systemuhren eine Freilaufgenauigkeit von mindestens ±100ppm (das einspricht 52,6 min in 365 Tagen) besitzen.

[<=]

10 Technische Use Cases

10.1 Technische Use Cases des Mini-AK

Das Verhalten der Basisdienste des Mini-AK wird im Folgenden mittels technischer Anwendungsfälle (Technical Use Case, kurz TUC) beschrieben. Dadurch wird erreicht, dass die entsprechenden Funktionsblöcke in den Fachmodulen und im Mini-AK nicht mehrfach dargestellt werden müssen.

In Abschnitt 5.3 sind die von Fachmodulen umzusetzenden Anwendungsfälle definiert. Die Fachmodule referenzieren die TUCs dieses Abschnitts, die die entsprechende Funktionalität eines Anwendungskonnektors für das Mobile Kartenterminal angepasst modelliert.

10.1.1 TUC_MOKT_200 sendAPDU

TIP1-A_3768 - Mobiles KT: „TUC_MOKT_200 sendAPDU“

Das Mobile Kartenterminal MUSS den technischen Use Case „TUC_MOKT_200 sendAPDU" gemäß Tab_MOKT_100 umsetzen.

[<=]

Abbildung 6: Pic_MOKT_001 Aktivitätsdiagramm zu TUC_MOKT_200 sendAPDU

Tabelle 13: Tab_MOKT_100 - TUC_MOKT_200 sendAPDU

TUC_MOKT_200 sendAPDU
Beschreibung
 TUC_MOKT_200 überträgt ein Kartenkommando an die Karte und nimmt die Antwort entgegen.
Anwendungsumfeld
 Zugriff auf eine Karte im MobKT
Initiierender Akteur
 MobKT
Weitere Akteure
 Karte
Auslöser
 TUC_MOKT_202 readFile
TUC_MOKT_209 readRecord
TUC_MOKT_214 appendRecord
TUC_MOKT_250 selectCardFile
TUC_MOKT_405 authenticateCardToCard
TUC_MOKT_407 selectKeyForAsymmetricExternalAuthentication
TUC_MOKT_412 verifyPIN
TUC_MOKT_418 checkEGK
TUC_MOKT_419 changePIN
TUC_MOKT_471 decryptData
Vorbedingungen
 keine
Nachbedingungen
 keine
Eingangsdaten
  • card: Karte an die das Kommando gesendet werden soll
  • command: Kommando (APDU), das an die Karte gesendet werden soll
Ausgangsdaten
  • Antwort (APDU) der Karte
Weitere Informationsobjekte
 keine
Standardablauf
 1.     Der Mini-AK MUSS das Kommando (command) über das Kartenterminal-Modul an die Karte (card) übertragen.
2.     Der Mini-AK MUSS die Antwort der Karte (card) vom Kartenterminal-Modul empfangen.
3.     Wenn die Karte mit dem Status NoError oder UpdateRetryWarning geantwortet hat, MUSS der Mini-AK den TUC_MOKT_200 mit OK beenden.
Varianten/Alternativen
  • Wenn es sich um eine synchrone Chipkarte nach [ISO7816-10] (z. B. KVK) handelt, MUSS das MobKT das Kommando wie in [MKT_10#Teil 7] beschrieben auf Interaktion mit der synchronen Chipkarte abbilden.
Fehlerfälle
  • 1, 2: wenn die Übertragung des Kommandos an die Karte in Schritt 1 oder der Empfang der Antwort in Schritt 2 scheitert, MUSS der Mini-AK TUC_MOKT_200 mit Fehler 1005 beenden.
  • 3: Wenn die Karte mit dem Status SecurityStatusNotSatisfied geantwortet hat, MUSS der Mini-AK TUC_MOKT_200 mit dem Fehler 1019 beenden
  • 3: Wenn die Karte mit einem anderen Status als NoError, SecurityStatusNotSatisfied oder UpdateRetryWarning geantwortet hat, MUSS der Mini-AK TUC_MOKT_200 mit dem Fehler 1007 beenden.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
 
 1005
 Kommunikationsfehler mit Kartenterminal-Modul oder Karte
1007
 Fehler beim Zugriff auf die Karte
 
 1019
 Kartenzugriff verweigert
Weitere Anforderungen
 Das MobKT MUSS Kartenkommandos, die voneinander abhängig sein können, pro Steckzyklus einer Karte im selben logischen Kanal (im Sinne der ISO 7816-4) an die Karte senden. Dieser Kanal KANN der Basiskanal 0 sein.
Der Mini-AK MUSS potentiell parallele Zugriffe auf die Karten soweit synchronisieren, dass die Übertragung der Daten zu und von den Karten und die Zuordnung der Antwort zu einem Kommando nicht beeinträchtigt wird.
Anmerkungen, Bemerkungen
 Die Kommunikation zwischen Karte und Kartenterminal ist Basisfunktionalität des Kartenterminal-Moduls. Es werden an dieser Stelle keine diesbezüglich spezifischen Fehlerfälle, die zu unterscheiden sind, definiert. Es liegt in der Verantwortung des Herstellers, solche Fehler für den Anwender angemessen darzustellen.
Aus funktionaler Sicht scheint es zurzeit nicht erforderlich, unterschiedliche Kanäle in einem Steckzyklus einer Karte zu verwenden.
Diese Spezifikation definiert, mit welchem Status TUC_MOKT_200 abhängig von dem von der Karte gemeldeten Status terminiert. Der aufrufende TUC muss bei manchen Kartenkommandos ggf. ein vom Status des TUCs und vom Status, den die Karte gemeldet hat, abhängiges Verhalten definieren. So kann zum Beispiel bei der PIN-Verifikation der Trailer 63 Cx nicht eindeutig der Ursache UpdateRetryWarning zugeordnet werden.
Die Trailer sind bei eGK und HBA/SMC-B soweit identisch definiert, dass oben nur auf die Spezifikation der eGK verwiesen wird (siehe [HBA_P1#16.2]) und der Mini-AK bezüglich der Antworten der Karten nicht abhängig vom Kartentyp reagieren muss.
Offene Punkte
  
Referenzen
 Pic_MOKT_001 Aktivitätsdiagramm zu TUC_MOKT_200 sendAPDU

10.1.2 TUC_MOKT_202 readFile

TIP1-A_3769 - Mobiles KT: "TUC_MOKT_202 readFile"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_202 readFile" gemäß Tab_MOKT_101 umsetzen.

[<=]

Abbildung 7: Pic_MOKT_002 Aktivitätsdiagramm zu TUC_MOKT_202 readFile

Tabelle 14: Tab_MOKT_101 - TUC_MOKT_202 readFile

TUC_MOKT_202 readFile
Beschreibung
 TUC_MOKT_202 liest Daten aus einem transparenten Elementary File (EF) einer Karte.
Anwendungsumfeld
 Lesen von fachlichen Daten, Zertifikaten u. ä von Karten
Initiierender Akteur
 MobKT
Weitere Akteure
 Karte
Auslöser
 Fachmodule
TUC_MOKT_438 checkEGKAuthCertificate
TUC_MOKT_470 encryptData
Vorbedingungen
 keine
Nachbedingungen
 keine
Eingangsdaten
  • card: Karte, von der gelesen werden soll
  • file: Identifikation des EF, aus dem gelesen werden soll (siehe Anmerkungen)
  • chunkToRead: Teil der Datei, der gelesen werden soll
Ausgangsdaten
  • data: die von der Karte gelesenen Daten
Weitere Informationsobjekte
 keine
Standardablauf
  1. Der Mini-AK MUSS gemäß TUC_MOKT_250 mit
      1. card = card
      2. fileToBeSelected = DF, in dem der zu lesende EF liegt, das DF zum EF selektieren.
  2. Endet TUC_MOKT_250 ohne Fehler, MUSS der Mini-AK in einer Schleife die Daten lesen. Dazu MUSS der Mini-AK
      1. abhängig von der von der Karte unterstützen extended length die zu lesenden Datenbereiche in geeignete Stücke zerlegen (hierbei SOLL der Mini-AK einen optimalen Datendurchsatz anstreben)
      2. und die einzelnen Teile gemäß TUC_MOKT_200 mit
        1. card = card
        2. command = READ BINARY mit shortFileIdentifier entspricht dem EF aus den Eingangsparametern und offset und length entsprechen dem zu lesenden Teil lesen.
Wenn TUC_MOKT_200 in der obigen Schleife jeweils ohne Fehler endet, MUSS der Mini-AK TUC_MOKT_202 mit OK beenden. Ergebnis der Operation sind hierbei die von der Karte gelesenen Daten.
Varianten/Alternativen
  • Wenn auf die Datei nicht mit shortFileIdentifier zugegriffen wird, MUSS der Mini-AK in Schritt 1 nicht nur das DF sondern bereits das EF zur Selektion vorgeben und bei READ BINARY in Schritt 2.b.2 keinen shortFileIdentifier angeben.
Fehlerfälle
  • 1: Wenn TUC_MOKT_250 in Schritt 1 mit Fehler endet, MUSS der Mini-AK TUC_MOKT_202 mit diesem Fehler beenden.
  • 2.b: Wenn TUC_MOKT_200 in Schritt 2.b mit dem Kartenstatus FileNotFound endet, MUSS der Mini-AK TUC_MOKT_202 mit dem Fehler 1008 beenden.
  • 2.b: Wenn TUC_MOKT_200 in Schritt 2.b mit einem Fehler aber Kartenstatus nicht gleich FileNotFound endet, MUSS der Mini-AK TUC_MOKT_202 mit diesem Fehler beenden.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1008
 Kartenapplikation existiert nicht
Siehe auch aufgerufene TUCs:
TUC_MOKT_250 selectCardFile
TUC_MOKT_200 sendAPDU
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 Eine Datei auf einer Karte wird letztlich durch das Dedicated File, in dem sich die Datei befindet, und einen fileIdentifier identifiziert. Optional kann auch ein shortFileIdentifier definiert sein.
Es wird nicht im Detail spezifiziert, in welchen Fällen der Zugriff über einen shortFileIdentifier erfolgen oder nicht über einen shortFileIdentifier erfolgen soll. Der Hersteller soll diesbezüglich eine bezüglich der benötigten Laufzeit günstige Umsetzung wählen.
Offene Punkte
Referenzen
 Pic_MOKT_002 Aktivitätsdiagramm zu TUC_MOKT_202 readFile


10.1.3 TUC_MOKT_209 readRecord

TIP1-A_3770 - Mobiles KT: "TUC_MOKT_209 readRecord"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_209 readRecord" gemäß Tab_MOKT_102 umsetzen.

[<=]

Abbildung 8: Pic_MOKT_003 Aktivitätsdiagramm zu TUC_MOKT_209 readRecord

Tabelle 15: Tab_MOKT_102 - TUC_MOKT_209 readRecord

TUC_MOKT_209 readRecord
Beschreibung
 TUC_MOKT_209 liest einen Record aus einem strukturierten Elementary File einer Karte
Anwendungsumfeld
 Lesen von Record-basierten Daten
Initiierender Akteur
 MobKT
Weitere Akteure
 Karte (eGK, HBA oder SMC-B)
Auslöser
 Fachmodule
Vorbedingungen
 keine
Nachbedingungen
 keine
Eingangsdaten
  • card: Karte, von der gelesen werden soll
  • file: Identifikation des strukturieren Elementary Files
  • recordNr: Nummer des Records
Ausgangsdaten
 Daten des gelesenen Records
Weitere Informationsobjekte
 keine
Standardablauf
  1. Der Mini-AK MUSS den DF, in dem der strukturierte Elementary File liegt, gemäß TUC_MOKT_250 mit
    1. card = card
    2. file = der Dedicated File, in dem der strukturierte File file liegt, selektieren
  2. Wenn der obige Schritt ohne Fehler endet, MUSS der Mini-AK den Record gemäß TUC_MOKT_200 mit
    1. card = card
    2. command = Kommando READ RECORD mit shortFileIdentifier entsprechend file und recordNumber gleich recordNr; die (maximale) length ergibt sich aus der Spezifikation des strukturierten Elementary Files;
      lesen.
Wenn TUC_MOKT_200 ohne Fehler endet, MUSS der Mini-AK TUC_MOKT_209 mit OK beenden.
Varianten/Alternativen
  • Wenn auf den strukturierten Elementary File nicht über ein shortFileIdentifier zugegriffen wird, MUSS der Mini-AK bereits in Schritt 1 den strukturierten Elementary File selektieren und in Schritt 2 bei READ RECORD keinen shortFileIdentifier angeben.
Fehlerfälle
  • 1: Wenn TUC_MOKT_250 in Schritt 1 mit einem Fehler endet, MUSS der Mini-AK TUC_MOKT_209 mit diesem Fehler beenden.
  • 2: Wenn TUC_MOKT_200 in Schritt 2 mit dem Kartenstatus RecoredDeactivated endet, MUSS der Mini-AK TUC_MOKT_209 mit dem Fehler 1006 beenden.
  • 2: Wenn TUC_MOKT_200 in Schritt 2 mit dem Kartenstatus FileNotFound endet, MUSS der Mini-AK TUC_MOKT_209 mit dem Fehler 1008 beenden.
  • 2: Wenn TUC_MOKT_200 in Schritt 2 mit einem anderen Fehler als Kartenstatus FileNotFound endet, MUSS der Mini-AK TUC_MOKT_209 mit diesem anderen Fehler beenden.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1006
 Kartenapplikation ist deaktiviert
1008
 Kartenapplikation existiert nicht

Siehe auch aufgerufene TUCs:
TUC_MOKT_250 selectCardFile
TUC_MOKT_200 sendAPDU
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 keine
Offene Punkte
Referenzen
 Pic_MOKT_003 Aktivitätsdiagramm zu TUC_MOKT_209 readRecord

10.1.4 TUC_MOKT_214 appendRecord

TIP1-A_3771 - Mobiles KT: "TUC_MOKT_214 appendRecord"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_214 appendRecord" gemäß Tab_MOKT_103 umsetzen.

[<=]


Abbildung 9: Pic_MOKT_004 Aktivitätsdiagramm zu TUC_MOKT_214 appendRecord

Tabelle 16: Tab_MOKT_103 - TUC_MOKT_214 appendRecord

TUC_MOKT_214 appendRecord
Beschreibung
 TUC_MOKT_214 fügt einen Record einem strukturierten Elementary File einer Karte hinzu
Anwendungsumfeld
 Schreiben der Audit-Daten
Initiierender Akteur
 MobKT
Weitere Akteure
 Karte
Auslöser
 TUC_MOKT_406 writeEGKAudit
Vorbedingungen
 keine
Nachbedingungen
 keine
Eingangsdaten
  • card: Karte auf die geschrieben werden soll
  • file: Identifikation des strukturierten Elementary Files
  • data: Daten, die in den Record geschrieben werden sollen
Ausgangsdaten
 keine
Weitere Informationsobjekte
 keine
Standardablauf
  1. Der Mini-AK MUSS den Dedicated File, in dem der strukturierte Elementary File liegt, gemäß TUC_MOKT_250 mit
    1. card = card
    2. fileToBeSelected = Dedicated File, in dem file liegt,
      selektieren.
  2. Wenn der obige Schritt ohne Fehler endet, MUSS der Mini-AK den Record gemäß TUC_MOKT_200 mit
    1. card = card
    2. command = APPEND RECORD mit shortFileIdentifier entsprechend dem strukturierten Elementary File und recordData = data,
      schreiben.
Wenn TUC_MOKT_200 ohne Fehler endet, MUSS der Mini-AK TUC_MOKT_214 mit OK beenden.
Varianten/Alternativen
  • Wenn auf den strukturierten Elementary File nicht über ein shortFileIdentifier zugegriffen wird, MUSS der Mini-AK in Schritt 1 bereits den strukturierten Elementary File selektieren und in Schritt 2 bei APPEND BINARY keinen shortFileIdentifier angeben.
Fehlerfälle
  • 1: Wenn TUC_MOKT_250 in Schritt 1 mit einem Fehler endet, MUSS der Mini-AK TUC_MOKT_214 mit diesem Fehler beenden.
  • 2: Wenn TUC_MOKT_200 in Schritt 2 mit dem Kartenstatus FileNotFound endet, MUSS der Mini-AK TUC_MOKT_214 mit dem Fehler 1008 beenden.
  • 2: Wenn TUC_MOKT_200 in Schritt 2 mit einem Fehler aber nicht Kartenstatus FileNotFound endet, MUSS der Mini-AK TUC_MOKT_214 mit diesem Fehler beenden.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1008
 Kartenapplikation existiert nicht

Siehe auch aufgerufene TUCs:
TUC_MOKT_250 selectCardFile
TUC_MOKT_200 sendAPDU
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 keine
Offene Punkte
 -
Referenzen
 Pic_MOKT_004 Aktivitätsdiagramm zu TUC_MOKT_214 appendRecord

10.1.5 TUC_MOKT_220 fulfillAccessConditions

TIP1-A_3772 - Mobiles KT: "TUC_MOKT_220 fulfillAccessConditions"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_220 fulfillAccessConditions" gemäß Tab_MOKT_104 umsetzen.

[<=]

Abbildung 10: Pic_MOKT_005 Aktivitätsdiagramm zu TUC_MOKT_220 fulfillAccessConditions

Tabelle 17: Tab_MOKT_104 - TUC_MOKT_220 fulfillAccessConditions

TUC_MOKT_220 fulfillAccessConditions (alias TUC_MOKT_220 accessConditions)
Beschreibung
 TUC_MOKT_220 führt die notwendigen Authentisierungen gegenüber der eGK durch, welche für die vorgesehenen Zugriffe erforderlich sind. Zurzeit ist die einzige vorgesehene Authentisierung eine Card-to-Card-Authentisierung mit einer Leistungserbringerkarte.
Anwendungsumfeld
 Zugriff auf geschützte Daten der eGK durch Leistungserbringer in mobilen Szenarien
Initiierender Akteur
 MobKT
Weitere Akteure
 eGK, HBA/SMC-B
Auslöser
 Fachmodule
TUC_MOKT_417 readFromEGK
Vorbedingungen
  • eGK ist eine Karte vom Typ eGK mit einer vom Mini-AK unterstützten Version.
  • hpc, falls angegeben, ist eine Karte vom Typ HBA oder SMC-B mit einer vom Mini-AK unterstützten Version.
Nachbedingungen
 keine
Eingangsdaten
  • egk: eGK, auf die zugegriffen werden soll
  • hpc: HBA oder SMC-B mit der auf die eGK zugegriffen werden soll
  • access: Liste der beabsichtigen Zugriffe, d. h. jeweils das Objekt der eGK, auf das zugegriffen wird, und die Art des Zugriffes.
    Zurzeit sind in diesem Rahmen nur Zugriffe auf Dateien (EF und die DF, in denen sie liegen, zu berücksichtigen)
Ausgangsdaten
 keine
Weitere Informationsobjekte
 eGK, HPC (HBA und SMC-B)
Standardablauf
  1. Der Mini-AK MUSS prüfen, ob alle geplanten Zugriffe auf die eGK ohne eine Authentisierung durchgeführt werden können. Diese Entscheidung ist anhand der Spezifikation der eGK zu treffen. Versionsabhängigkeiten sind zu berücksichtigen.
    Wenn obige Bedingung erfüllt ist, MUSS der Mini-AK TUC_MOKT_220 ohne weitere Aktionen mit OK terminieren.
    Ansonsten MUSS der Mini-AK prüfen, ob alle geplanten Zugriffe jeweils ohne Authentisierung oder nach einer Rollenauthentisierung von der eGK gewährt werden. Die konkreten Rollen der Zugriffsbedingungen oder der HPC werden hierbei nicht berücksichtigt.
    Falls dies nicht der Fall ist, MUSS der Mini-AK TUC_MOKT_220 ohne weitere Aktionen mit dem Fehler 1019 beenden.
  2. Falls die Bedingung zuvor hingegen erfüllt ist, MUSS der Mini-AK prüfen, ob ein hpc angegeben wurde.
    Falls kein hpc angegeben wurde, MUSS der Mini-AK den TUC_MOKT_220 mit dem Fehler 1028 beenden.
  3. Falls ein hpc angegeben wurde, MUSS der Mini-AK gemäß TUC_MOKT_405,
    1. bei einer eGK Generation 2 und 2.1 mit
      • targetCard = egk,
      • targetCVC = /MF/EF.C.eGK.AUT_CVC.E256,
      • sourceCard = hpc,
      • sourceCVC = /MF/EF.C.HPC.AUTR_CVC.E256 bzw. /MF/EF.C.SMC.AUTR_CVC.E256,
eine C2C-Authentisierung zwischen hpc und egk durchführen.
Endet TUC_MOKT_405 ohne Fehler, MUSS der Mini-AK TUC_MOKT_220 mit OK beenden.
Varianten/Alternativen
Fehlerfälle
 Wenn TUC_MOKT_405 in Schritt 3 mit einem Fehler endet, MUSS der Mini-AK TUC_MOKT_220 mit diesem Fehler beenden
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1019
 Kartenzugriff verweigert
1028
 Quellkarte für Card-to-Card fehlt

Siehe auch aufgerufene TUCs:
TUC_MOKT_405 authenticateCardToCard
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 Das MobKT prüft nicht die spezifischen Rollen der berechtigten Karten. Wenn die Karte eines Leistungserbringers aufgrund der Rolle nicht genügend Berechtigungen gegenüber der eGK besitzt, so wird zwar ein C2C durchgeführt, der Zugriff wird aber letztlich mit einer Zugriffsverweigerung der eGK abbrechen. Dieses Verhalten des MobKT stellt somit keine Einbuße an Sicherheit dar. Eine gegebenenfalls vorliegende Einschränkung der Ergonomie, da der Leistungserbringer seine PIN Eingeben muss, aber dennoch den Zugriff nicht erfolgreich durchführen kann, wird in Kauf genommen. Das MobKT ist für den Einsatz mit entsprechend berechtigten Heilberufsausweisen vorgesehen. Zurzeit gibt es in diesem Punkt keine Abhängigkeit von der individuellen eGK, da diese alle die gleichen rollenbasierten Zugriffsbedingungen haben.
Offene Punkte
Referenzen
 Pic_MOKT_005 Aktivitätsdiagramm zu TUC_MOKT_220 fulfillAccessConditions

10.1.6 TUC_MOKT_250 selectCardFile

TIP1-A_3773 - Mobiles KT: "TUC_MOKT_250 selectCardFile"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_250 selectCardFile" gemäß Tab_MOKT_105 umsetzen.
[<=]

Abbildung 11: Pic_MOKT_006 Aktivitätsdiagramm zu TUC_MOKT_250 selectCardFile

Tabelle 18: Tab_MOKT_105 - TUC_MOKT_250 selectCardFile

TUC_MOKT_250 selectCardFile
Beschreibung
 TUC_MOKT_250 selektiert ein DF oder EF auf einer Chipkarte
Anwendungsumfeld
 Selektion eines DF oder EF zwecks folgender Zugriffe auf Daten in dem Dedicated File bzw. Elementary Files
Initiierender Akteur
 MobKT
Weitere Akteure
 Karte
Auslöser
 TUC_MOKT_202 readFile
TUC_MOKT_209 readRecord
TUC_MOKT_214 appendRecord
TUC_MOKT_471 decryptData
Vorbedingungen
 keine
Nachbedingungen
 keine
Eingangsdaten
  • card: Karte auf der DF bzw. EF selektiert werden sollen.
  • fileToBeSelected: Identifikation des DF bzw. EF, der selektiert werden soll.
Ausgangsdaten
 keine
Weitere Informationsobjekte
 keine
Standardablauf
  1. soll die Selektion über einen Application Identifier erfolgen, MUSS der Mini-AK die Anwendung gemäß TUC_MOKT_200 mit
    1. card = card
    2. command = SELECT mit aid = <fileToBeSelected>
      selektieren.
      Endet TUC_MOKT_200 ohne Fehler, MUSS der Mini-AK TUC_MOKT_250 mit OK beenden.
  2. soll die Selektion über File Identifier erfolgen, MUSS der Mini-AK
    1. einen Selektionspfad vom zuletzt selektierten DF zum neu zu selektierenden File bestimmen
    2. und in einer Schleife über die Pfadelemente gemäß TUC_MOKT_200 mit
      1. card = card
      2. command = SELECT mit fid = Pfadelement
        die entsprechenden Files (DF bzw. EF) selektieren.
Enden alle TUC_MOKT_200 ohne Fehler, MUSS der Mini-AK TUC_MOKT_250 mit OK beenden.
Varianten/Alternativen
  • Der Ablauf nach Schritt 1 und Schritt 2 KANN auch kombiniert sein, d. h., dass der Pfad zu einem DF über den Application Identifier und in dem DF ein EF über File Identifier selektiert werden kann.
Fehlerfälle
  • 1: Endet TUC_MOKT_200 in Schritt 1 mit Kartenstatus FileNotFound, MUSS der Mini-AK TUC_MOKT_250 mit Fehler 1008 beenden.
  • 1: Endet TUC_MOKT_200 in Schritt 1 mit Kartenstatus FileDeactivated, MUSS der Mini-AK TUC_MOKT_250 mit Fehler 1006 beenden.
  • 1: Endet TUC_MOKT_200 in Schritt 1 mit einem anderen Fehler, MUSS der Mini-AK TUC_MOKT_250 mit diesem Fehler beenden.
  • 2.b: Endet TUC_MOKT_200 in Schritt 2.b mit Kartenstatus FileNotFound, MUSS der Mini-AK TUC_MOKT_250 mit Fehler 1008 beenden.
  • 2.b: Endet TUC_MOKT_200 in Schritt 2.b mit Kartenstatus FileDeactivated, MUSS der Mini-AK TUC_MOKT_250 mit Fehler 1006 beenden.
  • 2.b: Endet TUC_MOKT_200 in Schritt 2.b mit einem anderen Fehler, MUSS der Mini-AK TUC_MOKT_250 mit diesem Fehler beenden.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1006
 Objekt ist deaktiviert
1008
 Objekt existiert nicht

Siehe auch aufgerufene TUCs:
TUC_MOKT_200
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 keine
Offene Punkte
Referenzen
 Pic_MOKT_006 Aktivitätsdiagramm zu TUC_MOKT_250 selectCardFile

10.1.7 TUC_MOKT_405 authenticateCardToCard

TIP1-A_3774 - Mobiles KT: "TUC_MOKT_405 authenticateCardToCard"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_405 authenticateCardToCard" gemäß Tab_MOKT_107 umsetzen.
[<=]

TUC_MOKT_405 verwendet zur besseren Lesbarkeit die in Tabelle Tab_MOKT_120 beschriebene Generalisierung von Artefakten der beteiligten Karten in Zusammenhang mit verschiedenen eGK-Kartengenerationen.

Tabelle 19: Tab_MOKT_120 - Generalisierte Bezeichnung von Artefakten bei CardToCard-Authentication

Bezeichner generalisiert
 G1/G1+
 G2
asymRoleCheck
 rsaRoleCheck
 elcRoleCheck
asymRoleAuthentication
 rsaRoleAuthentication
 elcRoleAuthentications
EF.C.eGK.AUT_CVC
 EF.C.eGK.AUT_CVC
 EF.C.eGK.AUT_CVC.E256
EF.C.CA_eGK.CS
 EF.C.CA_eGK.CS
 EF.C.CA_eGK.CS.E256
PrK.eGK.AUT_CVC
 PrK.eGK.AUT_CVC
 PrK.eGK.AUT_CVC.E256
EF.C.CA_HPC.CS
 EF.C.CA_HPC.CS.R2048
 EF.C.CA_HPC.CS.E256
EF.C.CA_SMC.CS
 EF.C.CA_SMC.CS.R2048
 EF.C.CA_SMC.CS.E256
PrK.HPC.AUTR_CVC
 PrK.HPC.AUTR_CVC.R2048
 PrK.HPC.AUTR_CVC.E256
PrK.SMC.AUTR_CVC
 PrK.SMC.AUTR_CVC.R2048
 PrK.SMC.AUTR_CVC.E256


Abbildung 12: Pic_MOKT_008 Aktivitätsdiagramm zu TUC_MOKT_405 authenticateCardToCard

Tabelle 20: Tab_MOKT_107 - TUC_MOKT_405 authenticateCardToCard

TUC_MOKT_405 authenticateCardToCard (alias TUC_MOKT_405 authenticateC2C)
Beschreibung
 TUC_MOKT_405 führt eine asymmetrische Card-to-Card Authentisierung zwischen einer Leistungserbringerkarte (HPC) und einer Gesundheitskarte (eGK) durch. Es wird keine Aushandlung von Sitzungsschlüssel veranlasst.
Anwendungsumfeld
 Freischaltung der eGK im Rahmen fachlicher Zugriffe
Initiierender Akteur
 MobKT
Weitere Akteure
 eGK, HPC (HBA oder SMC-B)
Auslöser
 TUC_MOKT_220 fulfillAccessConditions
Vorbedingungen
  • targetCard ist eine Karte vom Typ eGK.
  • sourceCard ist eine Karte vom Typ HBA oder vom Typ SMC-B.
  • sourceCard Zertifikat ist nicht abgelaufen (siehe Kapitel 5.2.4)
  • targetCard und sourceCard haben vom Mini-AK unterstützte Versionen.
  • targetCVC4 entspricht /MF/EF.C.eGK.AUT_CVC.
  • sourceCVC4 entspricht /MF/EF.C.HPC.AUTR_CVC bzw. /MF/EF.C.SMC.AUTR_CVC.
Nachbedingungen
  • Eine beidseitige Card-to-Card-Authentisierung zwischen sourceCard und targetCard ist durchgeführt worden.
Eingangsdaten
  • targetCard: Zielkarte
  • targetCVC: Festlegung des CV-Zertifikats der Zielkarte
  • sourceCard: Quellkarte
  • sourceCVC: Festlegung des CV-Zertifikats der Quellkarte
Ausgangsdaten
 Keine
Weitere Informationsobjekte
Standardablauf
  1. wenn eine Card-to-Card Authentisierung mit denselben Parametern bereits einmal erfolgreich durchgeführt wurde, ohne dass seitdem der Sicherheitsstatus der Zielkarte vom MobKT zurückgesetzt wurde, dann MUSS der Mini-AK den TUC_MOKT_405 sofort mit OK beenden.
  2. Anderenfalls MUSS der Mini-AK gemäß TUC_MOKT_407 die öffentlichen Schlüssel für die asymmetrische externe Authentisierung ohne SM selektieren, und zwar
    1. in der Zielkarte mit
      1. card = targetCard,
      2. cvc = sourceCVC,
      3. zu CV-CA- und Cross-CV-Zertifikaten siehe unten
      4. algorithm = asymRoleCheck
    2. und in der Quellkarte mit
      1. card = sourceCard,
      2. cvc = targetCVC,
      3. zu CV-CA- und Cross-CV-Zertifikaten siehe unten
      4. algorithm = asymRoleCheck
Die notwendigen CA-CV-Zertifikate (/MF/EF.C.CA_eGK.CS, /MF/EF.C.CA_HPC.CS, bzw. MF/EF.C.CA_SMC.CS) KANN der Mini-AK den beteiligten Karten entnehmen. Eventuell notwendige Cross-CV-Zertifikate MUSS der Mini-AK selbst bereitstellen.
  1. Wenn der vorherige Schritt ohne Fehler beendet ist, MUSS der Mini-AK eine PIN-Eingabe für die PIN.CH bzw. PIN.SMC der Quellkarte gemäß TUC_MOKT_412 mit
    1. card = sourceCard
durchführen.
  1. Wenn der vorherige Schritt ohne Fehler beendet ist, MUSS der Mini-AK gemäß TUC_MOKT_200 die Schlüssel und Algorithmen für die interne Authentisierung selektieren, und zwar:
    1. für die Quellkarte mit
      1. card = sourceCard,
      2. command = MANAGE SECURITY ENVIRONMENT mit
        crtTag = internalAuthenticate,
        dem Schlüssel(Es sind die zum CV-Zertifikat korrespondierenden Schlüssel zu selektieren. Zurzeit werden im MobKT nur diese Zertifikate/Schlüssel verwendet, sodass man die Schlüssel an dieser Stelle fest vorgeben kann.) /MF/PrK.HPC.AUTR_CVC bzw. MF/PrK.SMC.AUTR_CVC
        und dem Algorithmus asymRoleAuthentication,
    2. und für die Zielkarte mit
      1. card = targetCard,
      2. command = MANAGE SECURITY ENVIRONMENT mit
        crtTag = internalAuthenticate,
        dem Schlüssel /MF/PrK.eGK.AUT_CVC
        und dem Algorithmus asymRoleAuthentication.
  2. Wenn der vorherige Schritt ohne Fehler beendet ist, MUSS der Mini-AK die Authentisierung der Zielkarte gegenüber der Quellkarte durchführen. Dazu MUSS der Mini-AK in der dargestellten Reihenfolge
    1. von der Quellkarte eine Challenge anfordern gemäß TUC_MOKT_200 mit
      1. card = sourceCard,
      2. command = GET CHALLENGE,
    2. die Challenge von der Zielkarte signieren lassen gemäß TUC_MOKT_200 mit
      1. card = targetCard,
      2. command = INTERNAL AUTHENTICATION,
    3. und diese Signatur von der Quellkarte prüfen lassen gemäß TUC_MOKT_200 mit
      1. card = sourceCard,
      2. command = EXTERNAL AUTHENTICATION.
  3. Wenn der vorherige Schritt ohne Fehler beendet ist, MUSS der Mini-AK die Authentisierung der Quellkarte gegenüber der Zielkarte durchführen. Dazu MUSS der Mini-AK in der dargestellten Reihenfolge
    1. von der Zielkarte eine Challenge anfordern gemäß TUC_MOKT_200 mit
      1. card = targetCard,
      2. command = GET CHALLENGE,
    2. von der Quellkarte die Challenge signieren lassen gemäß TUC_MOKT_200 mit
      1. card = sourceCard,
      2. command = INTERNAL AUTHENTICATION,
    3. und diese Signatur von der Zielkarte prüfen lassen gemäß TUC_MOKT_200 mit
      1. card = targetCard
      2. command = EXTERNAL AUTHENTICATION.
  4. Wenn der vorherige Schritt ohne Fehler beendet ist, MUSS der Mini-AK den TUC_MOKT_405 mit OK beenden.
Varianten/Alternativen
 keine
Fehlerfälle
  • 2.a: endet TUC_MOKT_407 in 2.a mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 sofort mit diesem Fehler und Fehler 1025 beenden.
  • 2.b: endet TUC_MOKT_407 in 2.b mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 sofort mit diesem Fehler und Fehler 1024 beenden.
  • 3: endet TUC_MOKT_412 in 3 mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 sofort mit diesem Fehler und 1024 beenden.
  • 2.b: endet TUC_MOKT_200 in 4.a mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 sofort mit diesem Fehler und Fehler 1024 beenden.
  • 2.b: endet TUC_MOKT_200 in 2.b mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 sofort mit diesem Fehler und Fehler 1025 beenden.
  • 5.a, 5.c, 6.b: endet TUC_MOKT_200 in 5.a, 5.c oder 6.b mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 jeweils sofort mit diesem Fehler und Fehler 1024 beenden.
  • 5.b, 6.a, 6.c: endet TUC_MOKT_200 in 5.b, 6.a oder 6.c mit einem Fehler, so MUSS der Mini-AK TUC_MOKT_405 jeweils sofort mit diesem Fehler und Fehler 1025 beenden.
Das MobKT MUSS es bei der Darstellung obiger Fehler neben der Angabe der eigentlichen Fehlerursache ermöglichen zu unterscheiden, bezüglich welcher der beiden beteiligten Karten der Fehler aufgetreten ist, d. h. ob der Fehler beim Zugriff auf die Quellkarte (Error 1024) oder die Zielkarte (Error 1025) erfolgte.
Technische Fehlermeldungen
 Fehler Code
 Bedeutung
1024
 Fehler bei der C2C-Authentisierung, Quellkarte
1025
 Fehler bei der C2C-Authentisierung, Zielkarte

Siehe auch aufgerufene TUCs:
TUC_MOKT_407 selectKeyForAsymmetricExternalAuthentication
TUC_MOKT_412 verifyPIN
TUC_MOKT_200 sendAPDU
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 keine
Offene Punkte
Referenzen
 Pic_MOKT_008 Aktivitätsdiagramm zu TUC_MOKT_405 authenticateCardToCard

10.1.8 TUC_MOKT_406 writeEGKAudit

TIP1-A_3775 - Mobiles KT: "TUC_MOKT_406 writeEGKAudit"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_406 writeEGKAudit" gemäß Tab_MOKT_108 umsetzen.

[<=]

Abbildung 13: Pic_MOKT_009 Aktivitätsdiagramm zu TUC_MOKT_406 writeEGKAudit

Tabelle 21: Tab_MOKT_108 - TUC_MOKT_406 writeEGKAudit

TUC_MOKT_406 writeEGKAudit
Beschreibung
 TUC_MOKT_406 schreibt einen Audit-Eintrag in EF.Logging der eGK
Anwendungsumfeld
 Zugriffe auf geschützte Daten der eGK müssen auf der eGK auditiert werden.
Initiierender Akteur
 MobKT
Weitere Akteure
 eGK, HPC (HBA oder SMC-B)
Auslöser
 Fachmodule
Vorbedingungen
  • hpc ist eine Karte vom Typ HBA oder SMC-B.
  • Das AUT- bzw. OSIG-Zertifikat der zugreifenden Karte ist verfügbar und korrekt, d. h. es ist syntaktisch korrekt und enthält einen Subject-DN.
  • eGK ist eine Karte vom Typ eGK.
  • eGK und hpc haben vom Mini-AK unterstützte Versionen.
  • die ICCSN der zugreifenden Karte (hpc) ist verfügbar.
Nachbedingungen
 Der Audit-Eintrag wurde mit Selektion von EF.Logging und dem Kommando APPEND RECORD an die eGK übertragen.
Eingangsdaten
  • loggingData: die Logging-Daten soweit sie nicht von der zugreifenden Karte oder dem System bezogen werden, d. h.:
    • Data Type
    • und Type of Access.
  • hpc: die zugreifende Karte
  • eGK: als Karte auf die der Protokolldatensatz geschrieben werden soll
Ausgangsdaten
 keine
Weitere Informationsobjekte
 Audit-Eintrag
Standardablauf
  1. Der Mini-AK MUSS einen Protokolldatensatz in der Struktur der Datei EF.Logging gemäß [gemSpec_eGK_Fach_TIP#TIP1-A_5144] mit folgenden Daten zusammenstellen:
    1. Timestamp: die aktuelle Systemzeit des MobKT
    2. Data Type: entsprechend der Eingangsdaten
    3. Type of Access: entsprechend der Eingangsdaten
    4. Actor-ID: ICCSN der zugreifenden Karte
    5. Actor-Name: entsprechend dem Zertifikat der zugreifenden Karte
  2. Der Mini-AK MUSS den Protokolldatensatz schreiben gemäß TUC_MOKT_214 mit
    1. card = eGK,
    2. file = /MF/DF.HCA/EF.Logging (siehe [eGK])
    3. data = Protokolldatensatz aus dem Schritt oben.
Der Mini-AK MUSS TUC_MOKT_406 mit dem Fehlerstatus von TUC_MOKT_214 beenden.
Varianten/Alternativen
 Keine
Fehlerfälle
Technische Fehlermeldungen
 Siehe aufgerufene TUCs:
TUC_MOKT_214 appendRecord
Weitere Anforderungen
 keine
Anmerkungen, Bemerkungen
 TUC_MOKT_406 veranlasst kein C2C, um auf die Auditdaten der eGK schreiben zu können. D. h., dies muss bereits vorher erfolgt sein. Wenn nicht, wird TUC_MOKT_406 mit einer entsprechenden Zugriffsverweigerung der Karte terminieren.
Offene Punkte
Referenzen
 Pic_MOKT_009 Aktivitätsdiagramm zu TUC_MOKT_406 writeEGKAudit

10.1.9 TUC_MOKT_407 selectKeyForAsymmetricExternalAuthentication

TIP1-A_3776 - Mobiles KT: "TUC_MOKT_407 selectKeyForAsymmetricExternalAuthentication"

Das Mobile Kartenterminal MUSS den technischen Use Case "TUC_MOKT_407 selectKeyForAsymmetricExternalAuthentication" gemäß Tab_MOKT_109 umsetzen.

[<=]