C_11635_Anlage_V1.0.0


1 Änderungsbedarf

Es ist gesetzlich gefordert, dass die eGK G2.1 kontaktlos verwendbar ist (SGB V §312 Absatz 1 Nummer 11). 
In der Spezifikation für das eHealth-Kartenterminal ist seit der Produkttypversion 1.8.0 die Verwendung einer kontaktlosen Schnittstelle als Option vorgesehen.
Nach Rückmeldung aus der Industrie ist für eine interoperable Umsetzung in Richtung der Konnektoren (SICCT Schnittstelle) eine Spezifikationsschärfung bei der Verwendung von Functional Unit Type zur Bezeichnung der Slots notwendig.

Hierbei geht es um die Bezeichnung der kontaktlosen Schnittstelle in der Kommunikation zwischen eHealth-Kartenterminal (eHealth-KT) und Konnektor.
Gemäß [SICCT#Tabelle 6] werden Slots für Smartcards anhand von Functional Unit Type (Qualifier) [FU Type]  und Functional Unit Index Value [FU.Index-Value] unterschieden und sind damit eindeutig adressierbar. Der Functional Unit Type (Qualifier) für kontaktbehaftete Slots hat demnach den Wert 0x00, während dieser Wert für kontaktlose Slots den Wert 0x10 hat.

Es fehlen explizite Anforderungen an den Konnektor.

2 Änderung

Es werden explizite Anforderungen an eHealth-KT und Konnektor gestellt, um die interoperable Adressierung von verwendeten kontaktlosen oder kontaktbehafteten Kartenslots klar festzulegen.
Aufgrund der langen Änderungszyklen (Entwicklung nach Spezifikation - (CC-) Zertifizierung und Zulassung- Rollout im Feld) sowohl bei den Konnektoren als auch bei den eHealth-KT, die sich auch nicht synchronisieren lassen, wird eine einstufige, pragmatische Lösung spezifiziert. Es sollen die Entwicklungs- und Migrationsaufwände bei den Herstellern und den Nutzern möglichst gering gehalten werden. 
Es wird eine vom SICCT-Standard abweichende Lösung spezifiziert, die darauf abzielt, dass die Implementierungen und Deployments der eHealth-KTs und der Konnektoren unabhängig voneinander erfolgen kann.

  • Ein eHealth-KT meldet seine n kontaktbehafteten Kartenslots SICCT konform und verwendet für den ersten kontaktlosen Slot den FU-Type "kontaktbehaftet" (was nicht SICCT konform ist) und den FU-Index "n+1".
  • Die Verwendung der kontaktlosen Slots ist im Auslieferungszustand eines eHealth-KT immer deaktiviert.
  • Es wird ein Konfigurationsmöglichkeit für das eHealth-KT spezifiziert, mit dem ein DVO die Verwendung der kontaktlosen Schnittstelle administrieren kann.

2.1 Konzept

Anforderungen an eHealth-KT:

Gesetzt den Fall, ein eHealth-KT ist zusätzlich zu den genau vier kontaktbehafteten Slots mit einem oder mehreren kontaktlosen Slots ausgestattet. Dann verwendet das eHealth-KT für den (ersten) kontaktlosen Slot als FU Type 0x00 und FU-Index 0x05.
Aus Sicht eines Konnektors scheint das eHealth-KT über einen fünften, kontaktbehafteten Slot zu verfügen.
(Für den Konnektor ist es unerheblich, ob auf eine Karte kontaktbehaftet oder kontaktlos zugegriffen wird. Die Unterschiede im Handling wird vom eHealth-KT gekapselt.)

Anforderungen an Konnektor:

Der Konnektor akzeptiert neben den mindesten vier kontaktbehafteten Slots weitere kontaktlose Slots. Diese werden ihm wie oben beschrieben signalisiert.  (Nicht SICCT konform; bspw. FU Type 0x00 und FU-Index 0x05 )

------------------

Anmerkung aus Industrie zum Fehler-Handling 

  • könnte eine kontaktlos angesprochene Karte während der Operation den Erfassungsbereich kurz verlassen. Soll dann die Operation abgebrochen werden oder soll versucht werden die Operation zu beenden?
    • Karte wird im Feld verschoben
    • Karte wird umgedreht
    • Karte wird schnell weggezogen

Anmerkungen gematik:

  1. Dasselbe Szenario lässt sich auch für kontaktbehaftete Karten konstruieren. Dort wird es "Karte ziehen" genannt. Ich schlage folgende Definition für den Terminus "Karte ziehen" vor: Eine kontaktbehaftet angesprochene Karte wird aus der Kontaktiereinheit entfernt, oder eine kontaktlos angesprochene Karte wird aus dem Betriebsvolumen entfernt.
  2. Diesen Fällen gemeinsam ist, dass die Karte  (zunächst) nicht mehr verfügbar ist. Sollte sie wieder in die Kontaktiereinheit oder in das Betriebsvolumen eingeführt werden, dann wird sie aktiviert. Der Zustand der Karte nach der Aktivierung ist typischerweise anders, als vor dem "Karte ziehen". Allgemein lässt sich nicht sagen, ob dann ohne Mitwirkung des Konnektors eine Fortführen der Operation möglich ist.
  3. gematik empfiehlt, dass im Falle "Karte ziehen" kontaktlos genau so verfahren wird wie im im kontaktbehafteten Fall.

--------------------------

2.2 Anpassungen der Spezifikation

2.2.1 Änderung in gemSpec_Kon

Im Kapitel 4.1.4 "Kartenterminaldienst";  Unterkapitel 4.1.4.2  "Durch Ereignisse ausgelöste Reaktionen" wird die neue Anforderung A_25832 oberhalb von TIP1-A_4541 eingefügt.

Mit der Einführung der Option_CL bei den eHealth-Kartenterminals wird dem Konnektor vom Kartenterminal abweichend von [SICCT] die Verwendung eines kontaktlosen Slots mit Functional Unit (FU) Type = 0x00 und FU-Index (Anzahl kontaktbehafteter Slots + x) signalisiert. 

A_25832 - Reaktion auf kontaktlose KT-Slot-Ereignisse (KT.Option_CL)

Der Kartenterminaldienst MUSS Ereignisnachrichten "Slot-Ereignis – Karte eingesteckt“ ([SICCT#6.2.4.4], TAG ‚84’) und „Slot-Ereignis – Karte entfernt“ ([SICCT#6.2.4.4], TAG ‚85’) verarbeiten, mit Functional Unit (FU) Type = 0x00 und FU-Index aus dem Intervall [1, 14] = [0x01, 0x0e]. [<=]


(==> Prüfverfahren: funktionale Eignung/ Test)

Konnektor mappt die kontaktlosen Slots in die bereits vorhandene Liste CT.SlotId in die gleiche Liste . 
Vorteil: keine IF Änderung bei Events und "GetCards"

Im Kapitel 4.1.4 "Kartenterminaldienst";  Unterkapitel 4.1.4.2  "Durch Ereignisse ausgelöste Reaktionen" werden die Anforderungen TIP1-A_4551 und TIP1-A_4542 entfernt und durch die neuen Anforderungen TIP1-A_4541-02 und TIP1-A_4542-02 ersetzt.

TIP1-A_4541-02 - Reaktion auf KT-Slot-Ereignis – Karte eingesteckt

Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte eingesteckt“ ([SICCT#6.2.4.4], TAG ‚84’) wie folgt reagieren:

  • das meldende Kartenterminal CT in CTM_CT_LIST ermitteln,
  • den in der Ereignisnachricht benannten Slot ( FU Type und FU Index Value FU-Nummer) in CT.SLOTS_USED aufnehmen,
    • kontaktbehaftet und kontaktlos: SlotNo =  FU Index Value
  • zur weiteren internen Bearbeitung rufe TUC_KON_256 {
        topic = „CT/SLOT_IN_USE“;
        eventType = Op;
        severity = Info;
        parameters = („CtID=$CT.CTID,
            SlotNo=<FU-Nummer aus Ereignisnachricht>„);
        doLog = false;
        doDisp = false } auf.
[<=]

TIP1-A_4542-02 - Reaktion auf KT-Slot-Ereignis – Karte entfernt

Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte entfernt“ ([SICCT#6.2.4.4], TAG ‚85’) wie folgt reagieren:

  • das meldende Kartenterminal CT in CTM_CT_LIST ermitteln,
  • den in der Ereignisnachricht benannten Slot ( FU Type und FU Index Value FU-Nummer) aus CT.SLOTS_USED entfernen,
    • kontaktbehaftet und kontaktlos: SlotNo =  FU Index Value
  • zur weiteren internen Bearbeitung rufe TUC_KON_256 {
        topic = „CT/SLOT_FREE“;
        eventType = Op;
        severity = Info;
        parameters = („CtID=$CT.CTID,
            SlotNo==<FU-Nummer aus Ereignisnachricht>„„);
        doLog = false;
        doDisp = false }
    auf.
[<=]

Im Kapitel 5.5.2 "Weitere Dokumente" wird die Referenz auf die SICCT-Spezifikation aktualisiert:

alt:
[SICCT]
TeleTrusT (17.12.2010): SICCT Secure Interoperable ChipCard Terminal,
Version 1.21
https://www.teletrust.de/fileadmin/docs/projekte/sicct/SICCT-Spezifikation-1.21.pdf 

neu: 

TeleTrusT (30.09.2016): SICCT Secure Interoperable ChipCard Terminal,
Version 1.2.3
https://www.teletrust.de/fileadmin/docs/projekte/sicct/SICCT-Spezifikation_V_1.2.3_vom_30.09.2016.pdf 

Errata zu SICCT1.2.3, Version 1.0 vom 5. Mai 2021
https://www.teletrust.de/fileadmin/user_upload/Errata-Sheet-SICCT_Spezifikation-123_V1_20210505.pdf 

2.2.2 Änderung in gemILF_PS

(SlotID > 4 bedeutet: kontaktlose Kommunikation)

In Kapitel 4.2.1.1 (Kartensitzungen) "GetCards"  oder im Kapitel 4.2.1.5  (Kartensitzungen) "Exkurs 2: Verarbeitung von Karteninformationen" wird ein erläuternder Satz ergänzt:

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