gemSpec_TK_FD_V1.1.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation für Testkarten Fachdienste
(eGK)
der Generation 2

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
26.10.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_TK_FD
     
    

Dokumenteninformationen

Änderungen zur Vorversion

Erweiterung des Dokuments für eGK-Testkarten der Generation 2.1, die Änderungen sind gelb markiert.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einführung des Dokumentes

1.1 Zielsetzung

In diesem Dokument werden die im Rahmen einer Personalisierung von eGK-Testkarten Fachdienste der Generationen 2 und 2.1 (eGK-Testkarten FD) aufzubringenden elektronischen und optischen Daten sowie die zugehörigen Voraussetzungen und Prozesse beschrieben. Es wird festgelegt, wie diese Daten analog der jeweiligen Spezifikation in die Datenstrukturen der Testkarten Fachdienste VSDM zu schreiben sind.

Weiterhin werden die Vorgaben zu symmetrischen Schlüsseln und die Schlüsselableitungen für eGK-Testkarten FD beschrieben.

Mit der Nutzung der elektronischen Gesundheitskarte und der zugehörigen Telematikinfrastruktur sind hohe Anforderungen an die Verfügbarkeit, Zuverlässigkeit, Performance und die Sicherheit der eingesetzten Komponenten, Dienste und Funktionen sowie des gesamten Systems verbunden.

Speziell die eingesetzten Chipkarten (hier: eGK) müssen vor dem Einsatz in definierten Umgebungen ausführlich auf Übereinstimmung mit den Spezifikationen und mit den Vorgaben für die Funktionalität geprüft werden. Die Abbildung Abb_TK_001 zeigt die Kartentypen am Beispiel der elektronischen Gesundheitskarte, die während der Einführungsphase und auch für Freigabe und Tests im weiteren Verlauf des Projektes genutzt werden.

Abbildung 1: Abb_TK_001 Definition der verschiedenen Kartentypen am Beispiel der eGK

Testlaborkarten:

Es handelt sich um Chipkarten, die herstellerbezogen mit speziell spezifizierten Strukturen und Inhalten im Labor auf die Einhaltung der Betriebssystemspezifikation und der eGK-Spezifikationen zur Verwendung als eGK getestet werden. Die speziell dafür festgelegten Strukturen und Spezifikationen sind im Dokument [gemSpec_TLK_COS_G2]enthalten.

Testkarten

Testkarten dienen der Erprobung in Testumgebungen mit Testdaten.

Die in dieser Spezifikation spezifizierten Testkarten für den Test von Fachdiensten werden so personalisiert, dass ein Test von Fachanwendungen (z.B. mit Online-Anbindung an Systeme der TI) möglich ist.

Testkarten müssen den technischen Spezifikationen entsprechen, wie sie in den Spezifikationen für die eGK ([gemSpec_COS] und [gemSpec_eGK_ObjSys] bzw. [gemSpec_eGK_ObjSys_G2.1]) beschrieben sind.

Die Testkarten enthalten keine Echtdaten.

Die in dieser Spezifikation spezifizierten Testkarten-Fachdienste werden für den Test der Fachdienste VSDM und für den produktübergreifenden Test und den Ende-zu-Ende-Test der Fachanwendung VSDM genutzt.

Echtkarten:

Echtkarten werden im Wirkbetrieb genutzt.

Karten für Öffentlichkeitsarbeit

Karten für Öffentlichkeitsarbeit werden genutzt, um das Aussehen der jeweiligen Karte präsentieren zu können. Diese Karten sollten keine funktionalen Eigenschaften haben, auf jeden Fall dürfen sie keine CVC-Zertifikate und keine X.509-Zertifikate enthalten.

Dieses Dokument beschreibt, welche Daten zur Erstellung von Testkarten Fachdienste bereitgestellt und wie die in den verschiedenen Teilen der Spezifikation festgelegten Daten für die Testkarten Fachdienste aufbereitet und in die Testkarten Fachdienste geladen bzw. aufgedruckt werden müssen. Außerdem wird die Layout-Ergänzung für Testkarten Fachdienste beschrieben.

1.2 Zielgruppe

Dieses Dokument ist für Kartenherausgeber, Hersteller von Karten (Chipkartenhersteller und -personalisierer), Trusted Service Provider (TSP) mit den Einheiten Certification Authority (CA) und OCSP-Responder bestimmt und ermöglicht ihnen die Herstellung spezifikationsgerechter Testkarten. Informativ dient es Herstellern von Produkten bei der Testung und Entwicklung ihrer Produkte mit Testkarten.

1.3 Geltungsbereich

Das vorliegende Dokument enthält normative Anforderungen und Festlegungen, die von Herausgebern, Herstellern und Betreibern von Komponenten und Diensten der Telematikinfrastruktur zu beachten sind. Die Zuordnung der vorliegenden Version zu einem Release erfolgt über die jeweilige Dokumentenlandkarte. Diese wird zusammen mit den Dokumenten auf der Internetseite der gematik bereitgestellt.

Dieses Dokument enthält verbindliche Festlegungen zur Personalisierung von Testkarten Fachdienste und legt die Abläufe, die Datenformate und die Verantwortung für die Erzeugung der zur Erstellung einer Testkarte Fachdienste benötigten Daten fest.

Schutzrechts-/Patentrechtshinweis

Dieses Dokument ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Inhalte 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 beschriebenen Inhalte angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Die Spezifikation definiert Struktur, Inhalt und Umfang der Daten, die auf die eGK-Testkarten Fachdienste geschrieben werden müssen.

Die Festlegungen für diese eGK-Testkarten Fachdienste sind den folgenden Dokumenten zu entnehmen:

Vorgaben zu eGK-Testkarten FD der Generation 1 sind nicht Bestandteil des vorliegenden Dokuments.

1.5 Methodik

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
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.

Da es neben dieser Spezifikation für Testkarten zum Test von Fachdiensten noch eine Spezifikation für Testkarten der gematik gibt, werden in diesem Dokument in den Überschriften und in den Anforderungstiteln aller Anforderungen die Karten als Testkarten FD bezeichnet.

2 Strukturen zu Herstellung von Testkarten FD

2.1 Testkarten FD

Die Herstellung von Testkarten kann von verschiedenen Herausgebern beauftragt werden. Hierzu gehören Kostenträger, Leistungserbringerorganisationen, Hersteller von Komponenten (z.B. eHealth-Kartenterminal, Konnektor) und weitere Organisationen im Gesundheitswesen. Die Rollen für die Herstellung von Testkarten entsprechen denen der Abb_TK_016, die Verantwortlichkeiten für die verschiedenen Teilaspekte kann der Herausgeber nach seinen Erfordernissen festlegen.

Abbildung 2: Abb_TK_016 Darstellung der Abläufe für die Erstellung von Testkarten FD (mitTest-PKI)

In den folgenden Kapiteln werden die Aufgaben der in Abb_TK_016 aufgeführten Entitäten bei der Erstellung von eGK-Testkarten FD beschrieben.

3 Vorgaben zu CV-Zertifikaten der Testkarten FD

3.1 CV-Zertifikate für Testkarten FD

3.1.1 Test-Root-CVC-CAs für Testkarten FD

3.1.2 Test-CVC-CA für Testkarten FD

4 Vorgaben zu symmetrischen Schlüsseln

4.1 Schlüsselableitung eGK-Testkarten FD

Testmaßnahmen zu Fachdiensten VSDM beinhalten unter anderem die Prüfung von Updates der VSD auf einer eGK und das Sperren und Entsperren durch das CMS. Diese Updates erfordern die Etablierung eines „trusted channel“ unter Verwendung symmetrischer Schlüssel, die sowohl auf der eGK als auch beim Fachdienst VSDM, der die jeweilige eGK unterstützt, verfügbar sein müssen. Die Automatisierung der Testmaßnahmen zu den Fachdiensten VSDM, u.a. auch eine Voraussetzung für ein Remote-Testing, setzt den Einsatz einer Kartensimulation als auch die Verwendung kartenindividueller Schlüssel voraus.

Die in diesem Dokument beschriebene Schlüsselableitung für eGK-Testkarten FD ermöglicht eine Generierung kartenindividueller Schlüssel zur Laufzeit der Testmaßnahmen und vermeidet somit eine Erfassung und Verwaltung sämtlicher in Testkarte verwendeter symmetrischer Schlüssel.

Die Herausgeber von Testkarten müssen eine Variante aus den drei nachfolgend beschriebenen Verfahren auswählen, um alle von ihnen herausgegebenen Musterkarten mit gemäß Schlüsselableitung generierten symmetrischen kartenindividuellen Schlüsseln zu personalisieren.

Für jede der beschriebenen Varianten wurden für beispielhafte ICCSNs kartenindividuelle Schlüssel berechnet. Für die Testmaßnahmen ist es erforderlich, dass der jeweilige Kartenherausgeber die von ihm ausgewählte Variante der Schlüsselableitung der testdurchführenden Instanz (gematik) benennt und die seinerseits berechneten symmetrischen Schlüssel für die in diesem Dokument beschriebenen ICCSNs kommuniziert.

In diesem Dokument werden Ableitungsalgorithmen angegeben, mit deren Hilfe sich kartenindividuelle symmetrische Schlüssel für AES-128 und AES-256 aus einem Masterkey und einem kartenindividuellen Merkmal herleiten lassen.

4.2 Konkrete Werte für Masterkey

Die in diesem Dokument enthaltenen Werte für Masterkeys dürfen ausschließlich für Testlaborkarten und für Testkarten der Generation 2 bzw. Generation 2.1 verwendet werden. Die Werte für Masterkey sind explizit NICHT zulässig für Karten, welche für die Aufnahme von echten Personendaten (scharfen Karten) bestimmt sind.

Gemäß der Spezifikation des eGK-Objektsystem ist jeweils ein AES-Schlüssel mit 128 bit Schlüssellänge oder mit 256 bit Schlüssellänge zu personalisieren.

Hinweis: Die im Folgenden genannten Werte für Masterkeys sind im Wesentlichen Oktettstrings, wobei jedes Oktett um eins inkrementiert wird. Alle Werte unterscheiden sich neben der Länge ansonsten nur im ersten Oktett.

4.2.1 Schlüsseldaten

Der Masterkey (MK) besteht aus einem Oktettstring von 32 Oktett Länge.

Tabelle 1: TAB_TK_FD_001 Masterkey (MK)

4.2.2 Schlüsselbezeichner (KID)

Tabelle 2: Schlüsselbezeichner (KID)

4.3 Schlüsselableitung

4.3.1 Nomenklatur

4.3.2 Variante 1: gematik

In der Vorgängerversion dieses Dokumentes für Generation 1 wurde ein Hash-MAC basierendes Verfahren aus [ANSI X9.63#5.6.3] verwendet, welches dasselbe Prinzip verwendet, wie [TR–03111#4.3.3]. Das Hash-MAC Prinzip wird in diesem Dokument auf die kartenindividuellen Schlüssel der Testkarten FD angewendet.

Kartenindividuelle AES-Schlüssel werden in der eGK im Rahmen der Kartenadministration eingesetzt. Neben dem symmetrischen Schlüssel SK.CMS, den es seit der Generation 2 in allen Kartentypen gibt (eGK, HBA, …), ist dies die Schlüssel SK.VSD.

Anders als in [TR–03111#4.3.3.2] vorgeschlagen, wird in diesem Dokument für alle Schlüssellängen von AES stets SHA-256 verwendet um den Implementierungsaufwand zu reduzieren. Es gilt:

Die Schlüsselableitung beruht auf einer Modifikation des Verfahrens aus EMV Book 2 Anhang A1.4.3 zur Erzeugung von 16 bzw. 32 Byte langen AES-Schlüsseln.

Hierbei wird die ICCSN mit einem schlüsselindividuellen Bezeichner konkateniert. Die Berechnung des Schlüssels erfolgt dann durch AES-Verschlüsselung des zugehörigen Hashwertes mit dem Masterkey. Soweit notwendig wird der berechnete Schlüssel auf die benötigte Länge gekürzt.

Als Schlüsselbezeichner wird der Schlüsselname, erweitert um die Schlüsselverwendung, aus der Spezifikation des eGK-Objektsystems verwendet (s.u.).

SK 128 = MSB 16 (AES-ECB-ENC[MK](SHA256(ICCSN||KID)))

SK 256 = AES-ECB-ENC[MK](SHA256(ICCSN||KID))

4.3.2.1 Beispielgenerierung

iccsn = 80276883110761400005

SK.CMS.AES128.ENC = 1596958D6848403879F49D4CC089EDD7

SK.CMS.AES128.MAC = A161324DE494507F603CF9E8B35BA92A

SK.CMS.AES256.ENC = 7772AF336AF2F5FD7E925AFE86F6F53A847127AF17576520158E8D5B29B88CF7

SK.CMS.AES256.MAC = FF84DADFEE1E160BF9D6C3AE00967DDDA6EE534DE9E5C5E7BFB279D9A130EBF6

SK.VSD.AES128.ENC = 9C4C1D0B98F1779376AC9F3C5ACA02CE

SK.VSD.AES128.MAC = 96FD00847B158C557662AF0E324299FC

SK.VSD.AES256.ENC = F4EDBA04E3253E6C008DDB72AF08B4FEF9BE68F8512B03FFADCB9ACE7563E0F0

SK.VSD.AES256.MAC = D9D921537BF0C8507A8444E5E9E0AE694287343ACB81304BC628BA6ABB6A1A4E

iccsn = 80276881031971421010

SK.CMS.AES128.ENC = D4DD0F4966CE13B1C8A91BE4B17972F4

SK.CMS.AES128.MAC = 7C5DCBD4ED461C85ED4AC54B92C7F821

SK.CMS.AES256.ENC = 59D0C921AEAB21782587A68D90B355B71A9F651405B07878BB216AAF7FF5D580

SK.CMS.AES256.MAC = 175B09EE81B44315CF6B85EAE14A94A8E22CC74CE06A251363150D8A0DD1EFE7

SK.VSD.AES128.ENC = 24A379C27C6A93A27D2095D2D8CFAE72

SK.VSD.AES128.MAC = FA4BCC22476AC5F287213FFFC9A80EE5

SK.VSD.AES256.ENC = 8F533C6371DDA6F957959B1B01DD8D549E5FE8C386722584FE800B57E6A208D3

SK.VSD.AES256.MAC = FB90558ADC407B1FC545380B38D71023532CD520F518AF186C59CBC9FD97E62F

iccsn = 80276881190000003706

SK.CMS.AES128.ENC = 7CA08936B5E10527ED1A7AA49F931F02

SK.CMS.AES128.MAC = FD82005E7EBD041A24B285D295EE9F30

SK.CMS.AES256.ENC = 96B1C02977E8BB949BDF5B9BB33633C63DC34E9735DCD1090B650C9D044A8468

SK.CMS.AES256.MAC = FCFFA3067491771BB5B6B8BD7DE090E4855E2CB2DCCFC5020B519E1D79AF02E3

SK.VSD.AES128.ENC = BC87ADF84BDBDA62B18614BFE6FCB1C2

SK.VSD.AES128.MAC = E21CF109AE2F85FC2A465DAB622A2AD5

SK.VSD.AES256.ENC = AC7128316159603BAC3F999DC9D7B6DC51D3F035F6439DCB18DB3F750ED702CA

SK.VSD.AES256.MAC = 404E0CA76DCFA92DABB563EA23F57EFF5195872DD0F13385164C8113AD5B1906

iccsn = 80276881190000003723

SK.CMS.AES128.ENC = 84F2C37EB9A894A7EE716971DC95511A

SK.CMS.AES128.MAC = 564D02F053D1A181862AAA614F51608E

SK.CMS.AES256.ENC = 7872010703E6D523BE2AA9CDBD629685A266E1C54EC6DBB63BED4A3F97240065

SK.CMS.AES256.MAC = 8F82E9B4901C4A7B2D7C731459B6940C0F8E729420A5046479A726861FFE3CB5

SK.VSD.AES128.ENC = 10D2308E9DFFA822402C48AA3A594083

SK.VSD.AES128.MAC = 00B4EBF8307DFF695530D9F3DCE10DBE

SK.VSD.AES256.ENC = 778C16D9E74780829574CC016AAA24A82C87CAE6C327BE5B5211C07E2EAE4ACF

SK.VSD.AES256.MAC = B91F79FD0787C5457A4D5EFD22E3DF897D7A8D8B01D827D1A020927AB1898539

iccsn = 80276881500000001416

SK.CMS.AES128.ENC = 5BEDAB2F527A2ADB65ED458686554C36

SK.CMS.AES128.MAC = DE996C091F5D6F25E9B76B411611D15A

SK.CMS.AES256.ENC = E1F1A979C65A141C7CCA549304272B99A2BD32A615C2A3C3A50C6430CAD1829F

SK.CMS.AES256.MAC = 8CB848323D16293DE405B8B4FC7D7E1353936EC5C782F6C2A876C65AAE7C8575

SK.VSD.AES128.ENC = 0495F3524AE773910B71A16E99B3A04F

SK.VSD.AES128.MAC = D446F73FB3AAD1B4CD885AC02C5F0EAC

SK.VSD.AES256.ENC = 4C3D3CF423506BD47AADBE000B513EB8E62DA345A275CB54E251D036898CA54A

SK.VSD.AES256.MAC = FF21F6762314A62020F178B43906382FC817F05DF4D03E30DB1D946D556A1468

4.3.3 Variante 2: Atos Verfahren

Die Länge des erzeugten SK (im Algorithmus dargestellt als ICC-MK) entspricht der Länge des übergebenen MK (im Algorithmus dargestellt als IMK), d.h. zur Erzeugung von z.B. eines AES-256 Schlüssels muss ein MK mit 32 Bytes (= 256 Bits) übergeben werden.

Das Verfahren basiert auf der EMV-Spezifikation, Integrated Circuit Card, Specifications for Payment Systems, Book 2 "Security and Key Management", Version 4.3, November 2011, Annex A1.4.3 (Option C). Siehe http://www.emvco.com/specifications.aspx?id=223.

In Ergänzung zur EMV-Spezifikation gilt:

PAN = ICCSN

PAN Sequence Number = not present

Y* = Y XOR 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Somit gilt:

SK = ICC-MK = Leftmost k-bits of {AES(IMK)[Y] || AES(IMK)[Y*]}

wobei:

k = Anzahl der Bits des zu erzeugenden AES-Schlüssels (z. B. k gleich 128, 192 oder 256)

Y = 0x0000000000 || ICCSN-Bytes || 0x00

ICCSN-Bytes = BCD-kodierte ICCSN (10 Bytes)

4.3.3.1 Beispielgenerierung

Mit der ICCSN

80276001040000000001

ergeben sich mit obigen Masterkeys folgende SK-Schlüssel:

iccsn = 80276001040000000001

SK.CMS.AES128.ENC = 83B71CA85A0F940FD154409AC67AE0DB

SK.CMS.AES128.MAC = FA65036CC682E440903A9BA7F90E0F2C

SK.CMS.AES256.ENC = FA9E833E3584F7B2F27F08E2E9C4B72D4112B78A4236AF799ADF6A25584A1848

SK.CMS.AES256.MAC = FF9690C39521DD9BC7DD8D8B33B741A8888BDE8FA8DEF8DCA840079FF646AAE8

SK.VSD.AES128.ENC = 47E68B915481A7A6B772D58AB55CC48C

SK.VSD.AES128.MAC = F602F5C2F838B8230F0B623131B9A35B

SK.VSD.AES256.ENC = C82DE2D3878F8257C452F0E355A1212E2D5A3F4F96CBC4503885D3CF593C9018

SK.VSD.AES256.MAC = 1F3901DD3274FC85822853276D369BA408B5AFEE6FA2804FE42115EF0C314804

4.3.4 Variante 3: G&D Verfahren

Das Verfahren besteht aus einer Kombination von Hashwert-Bildung und AES-Verschlüsselung. Durch das Extrahieren der führenden Oktette aus dem Chiffrat wird die geeignete Schlüssellänge sichergestellt. Die Verwendung des Datentyps „Oktettstring“ ist äquivalent zu [gemSpec_COS].

Schritt 1:    HASH#1 = SHA_256(ICCSN)

Input: ICCSN als Oktettstring der Länge 10 Oktett, BCD codiert.

Output: Oktettstring, Hash-Wert der Länge 32 Oktett

Verfahren: Bildung eines Hashwertes nach [FIPS 180-4#6.2]

Schritt 2:    ENC#1 = AES_ECB(HASH#1, MK)

Input: HASH#1, Oktettstring der Länge 32 Oktett, MK, Masterkey der Länge 32 Oktett (256 Bit)

Output: Oktettstring, Chiffrat (ciphertext) der Länge 32 Oktett

Verfahren: AES-Verschlüsselung von HASH#1 im ECB-Modus mit dem Masterkey der Länge 256 Bit nach [FIPS 197]

Schritt 3:    KEY#1 = Extract_MSByte (ENC#1, 16/32)

Input: ENC#1, Oktettstring der Länge 32 Oktett, 16/32, Integer, Anzahl der zu extrahierenden Elemente

Output: Oktettstring der Länge 16/32 Oktett (128/256 Bit)

Verfahren: Extrahieren der führenden Oktette, Sicherstellung der geeigneten Schlüssellänge

5 Vorgaben für eGK-Testkarten FD

5.1 PIN- und PUK-Werte

5.1.1 PIN-Werte

5.1.2 PUK-Werte

5.1.3 CAN-Werte

5.2 Erstellung der Daten der Versicherten für Testkarten FD

5.2.1 Bereitstellung der Daten

Abbildung 3 Abb_TK_003 ICCSN für Gesundheitskarten

5.3 Erstellung der X.509-Zertifikate für Testkarten FD

5.3.1 Erstellung der X.509-Zertifikate für Testkarten FD für ENC, ENCV, AUT und AUTN

5.3.2 OID-Vorgaben für die eGK-Testkarten FD

5.4 CV-Zertifikate für die eGK-Testkarten FD

Es gelten die Anforderungen aus Kapitel 3

5.5 Secret Keys SK.CMS.AES128, SK.VSD.AES128 und SK.VSDCMS.AES128 für die eGK-Testkarten FD

Es gelten die Anforderungen aus Kapitel 4.

5.6 Optische Gestaltung der eGK-Testkarten FD

Card-G2-A_3552 - optische Gestaltung der eGK-Testkarten FD mit Bild

Die optische Gestaltung der Vorderseite der eGK-Testkarten F mit Bild MUSS gemäß Abb_TK_018 (Ausnahme Releasekennzeichnung, siehe Card-G2-A_3553) ausgeführt werden:

Abbildung 5: Abb_TK_018 Kartenvorderseite eGK-Testkarte FD der Generation 2 mit Personalisierung, mit Bild, mit CAN, mit Releasekennzeichnung

[<=]

Die Anordnung ICCSN ist jeweils beispielhaft.

Für eGK-Testkarten ist eine Fotopersonalisierung nicht verpflichtend.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellsten, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

6.6 Weitere Dokumente

7 Anhang B - Festlegungen

7.1 Festlegungen für die IK des Kostenträgers für eGK-Testkarten FD

7.2 Festlegungen zur IIN des Kartenherausgebers für Testkarten FD

7.3 Festlegungen zur KVNR für eGK-Testkarten FD

Für die Testkarten im Rahmen der Zulassungstest der Fachdienste VSDM gilt:

Die gültigen Werte für die Oberkennung (Stellen 1-3) und die Kostenträgernummer (Stellen 4-5) der einzelnen Krankenkassen sind im Anhang D in TAB_TK_FD_011 aufgeführt.

Eine Prüfung des Verbots der Nutzung von mehr als drei aufeinander folgenden gleichen Ziffern erfolgt bei der Erstellung der KVNR.

7.4 Definition der ICCSN

Die ICCSN einer Chipkarte muss weltweit eindeutig sein. Der Aufbau der ICCSN ist in Abb_TK_015 dargestellt.

Abbildung 6: Abb_TK_015 Aufbau einer ICCSN

7.5 Kodierung der ICCSN für die Testkarte FD

8 Anhang C – Testkategorien RU / TU

8.1 Testkategorien RU

In der folgenden Tabelle TAB_TK_FD_009 sind die Testkategorien für die Testkarten für den produktübergreifenden Test in der RU dargestellt.

Tabelle 7 : TAB_TK_FD_009 Kategorisierung der Testkarten eGK Fachdienste VSDM für die RU

Für Festlegungen zum Flip/Flop-Verfahren siehe [gemKPT_Test].

8.2 Testkategorien TU

In der folgenden Tabelle TAB_TK_FD_010 sind die Testkategorien für die Testkarten für den Produkttest der Fachdienste VSDM und den produktübergreifenden Test in der TU dargestellt.

Tabelle 8 : TAB_TK_FD_010 Kategorisierung der Testkarten eGK Fachdienste VSDM für die TU

Für Festlegungen zum Flip/Flop-Verfahren siehe [gemKPT_Test].

9 Anhang D – Zuordnung KVNR-Nummernkreise

Tabelle 9 : TAB_TK_FD_011 Zuordnung der KVNR-Nummernkreise