gemSpec_Karten_Fach_TIP_G2_1_V3.1.0

PDF HTML Excel XML
 gemSpec_Karten_Fach_TIP_G2_1_V3.1.0



Elektronische Gesundheitskarte und Telematikinfrastruktur






Befüllvorschriften für die Plattformanteile der Karten der TI der Generation G2.1 


    

     

      Version
      3.1.0
     

     

      Revision
      902612
     

     

      Stand
      07.07.2023
     

     

      Status
      freigegeben
     

     

      Klassifizierung
      öffentlich
     

     

      Referenzierung
      gemSpec_Karten_Fach_TIP_G2.1

Dokumentinformationen

Änderungen zur Vorversion

Erweiterungen und Änderungen für Kartengeneration 2.1

Dokumentenhistorie

Version
 Stand
 Kap./ Seite
 Grund der Änderung, besondere Hinweise
 Bearbeitung
0.1.0
 26.10.17
 Ersterstellung
 gematik
1.0.0
 15.10.12
 freigegeben
 gematik
1.1.0
 12.11.12
 Einarbeitung Kommentare aus der übergreifenden Konsistenzprüfung
 P77
1.2.0
06.06.13
 Überarbeitung anhand interner Änderungsliste (Fehlerkorrekturen, Inkonsistenzen)
 P77
2.2.0
 21.02.14
 Überführung von [gemSpec_eGK_Fach_TIP] in eine übergreifende Spezifikation, Ergänzung Tabelle Kodierung EFG.Version2, Anpassung Vorgaben für EF.EnvironmentSettings
 P706.4
2.3.0
 27.03.14
 Einarbeitung Fehlerkorrektur Iteration 2b
 P706.4
2.4.0
 06.06.14
 Überarbeitung von Kapitel 4.2 Testkennzeichen, Einarbeitung Änderungen Iteration 3
gematik
2.4.3
 18.12.15
 Anpassungen zum Online-Produktivbetrieb (Stufe 1)
 gematik
2.5.0
 03.05.16
 freigegeben
 gematik
Einarbeitung weiterer Kommentare
2.6.0
 12.08.16
 freigegeben
 gematik
12.12.17
 Erweiterungen und Änderungen für G2.1
 gematik
3.0.0
 18.12.17
 freigegeben
 gematik
3.1.0 07.07.23 Einarbeitung C_11315, KVNR für eGK Prüfkarten gematik


Inhaltsverzeichnis


1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument beschreibt die für die TI-Plattform spezifischen Befüllvorschriften der Speicherstrukturen der Karten, die im deutschen Gesundheitswesen verwendet werden.

Gleichzeitig gibt das Dokument Empfehlungen für Fachanwendungen dafür, wie über einen einheitlich strukturierten Status-Container pro Fachanwendung Verwaltungsinformationen für Status, Zeitstempel und Version in der eGK definiert werden können.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Hersteller und Anbieter von Produkten der TI.

1.3 Geltungsbereich

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

Die Vorgaben im Dokument gelten für die Karten der Generation 2 (eGK, HBA, SMC-B, gSMC-K, gSMC-KT).

Schutzrechts-/Patentrechtshinweis

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

1.4 Abgrenzungen

Die Befüllvorschriften der Speicherstrukturen der Fachanwendungen werden in eigenständigen Spezifikationen festgelegt.

1.5 Methodik

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

Sie werden im Dokument wie folgt dargestellt:

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

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

Weiterhin werden in diesem Dokument Datentypen verwendet, die in Tab_Karten_Fach_TIP_001 definiert sind. Längenangaben für Informationselemente erfolgen in Byte. Hexadezimale Werte werden mit dem Präfix „0x“ gekennzeichnet. Werte ohne Präfix sind dezimal.

Tabelle 1: Tab_Karten_Fach_TIP_001 Definition der Datentypen

Datentyp
 Definition
ALPHA
 Text-String nach ISO8859-15. NULL (0x00) terminiert, falls die Textlänge die Größe des Informationselements unterschreitet.
BCD
 „Binary Coded Decimal“, z. B. 0x20 0x07 für “2007”
BINÄR
 vorzeichenloser, ganzzahliger, numerischer Wert in binärer Big-Endian-Darstellung. Beispielhaft sei hier noch erwähnt, dass der Wertebereich eines BINÄR-Wertes mit Länge 1 dementsprechend 0..255 ist und mit der Länge 2 0..65535

2 Befüllvorschriften für alle Karten

2.1 Begriffsdefinitionen und Kodierungsvorschriften

2.1.1 Produkttypen und Produktidentifikatoren

Im Zuge der Selbstauskunft einer Karte gemäß [gemSpec_OM] sind zu liefern:

  • Spezifikationsgrundlage (Produkttyp + Version)
  • Produktidentifikation (Hersteller, Produktkürzel, Produktversion)

In einer finalen, d. h. personalisierten Karte sind mehrere Produkttypen („PT_“ gemäß Produkttypensteckbrief) und demzufolge mehrere durch die gematik zugelassene
(Teil-)Produkte enthalten, die mit ihren Produktidentifikatoren („PI_“) ausgewiesen werden müssen:

Tabelle 2: Tab_Karten_Fach_TIP_012–Produkttypen und Produktidentifikatoren

Datenobjekt
 Beschreibung
 T*
 Write**
 Speicherort
PT_COS
 Bezeichnet die im Rahmen der Zulassung des Card Operating Systems (COS) im Antrag angegebene Version des für die Entwicklung des COS herangezogenen „Produkttyps Zulassungsobjekt COS“ gemäß
[gemProdT_COS_PTVx.y.z]
 I
 -
 EF.ATR
PT_ObjSys
 Bezeichnet die im Rahmen der Zulassung des Objektsystems im Antrag angegebene Version des für die Entwicklung des Objektsystems herangezogenen „Produkttyps Zulassungsobjekt Objektsystem <Kartentyp> (inkl. Kartenkörper)“, je nach Kartentyp gemäß
[gemProdT_eGK_ObjSys_PTVx.y.z]
[gemProdT_HBA_ObjSys_PTVx.y.z]
[gemProdT_SMC-B_ObjSys_PTVx.y.z]
[gemProdT_gSMC-K_ObjSys_PTVx.y.z]
[gemProdT_gSMC-KT_ObjSys_PTVx.y.z]
 I
 CMS
 EF.Version2
PT_Pers
 Bezeichnet die im Rahmen der Zulassung der Kartenpersonalisierung (sprich der finalen Karte) im Antrag angegebene Version des für die Entwicklung der Personalisierung herangezogenen „Produkttyps <Kartentyp>“. Je nach Kartentyp gemäß:
[gemProdT_eGK_PTVx.y.z]
[gemProdT_HBA_PTVx.y.z]
[gemProdT_SMC-B_PTVx.y.z]
[gemProdT_gSMC-K_PTVx.y.z]
[gemProdT_gSMC-KT_PTVx.y.z]
 P
 -
 EF.ATR
PI_Chip
 Bezeichnet die im Rahmen der Zulassung des COS im Antrag angegebene Produktidentifikation des Chips der Karte
 I
 -
 EF.ATR
PI_COS
 Bezeichnet die im Rahmen der Zulassung des COS im Antrag angegebene Produktidentifikation des COS selbst
 I
 -
 EF.ATR
PI_Kartenkörper
 Bezeichnet die im Rahmen der Zulassung des Objektsystems im Antrag angegebene Produktidentifikation des Kartenkörpers
 I oder P
 -
 EF.ATR
PI_InitialisiertesObjSys
 Bezeichnet die im Rahmen der Zulassung des Objektsystems im Antrag angegebene Produktidentifikation des Objektsystems selbst.
Identifiziert das im Rahmen der Kartenherstellung auf die Karte aufgebrachte Objektsystem
 I
 -
 EF.ATR
PI_Objektsystem
 Bezeichnet die im Rahmen der Zulassung des Objektsystems im Antrag angegebene Produktidentifikation des Objektsystems selbst
Identifiziert das zuletzt (durch Initialisierung oder nachfolgend durch Restrukturierung) auf die Karte aufgebrachte und damit aktive Objektsystem
 I
 CMS
 EF.Version2
PI_Personalisierung
 Bezeichnet die im Rahmen der Zulassung der personalisierten Karte im Antrag angegebene Produktidentifikation der Karte
Kennzeichnet somit den Personalisierungsprozess im Rahmen der Kartenherstellung
 P
 -
 EF.ATR


Hinweis: *Die Spalte „T“ kennzeichnet den Zeitpunkt, zu dem das Artefakt in die Karte eingebracht wird. I = Initialisierung, P = Personalisierung.

Hinweis: **Die Spalte „Write“ kennzeichnet, ob ein Artefakt nach dem Einbringen in die Karte unveränderbar ist (gekennzeichnet durch " ") oder durch welche Instanz es änderbar ist.

Hinweis: Leserechte werden in der Tabelle nicht dargestellt, da für alle Artefakte „Read Always“ angenommen wird.

2.1.2 Kodierung von Versionskennungen und Produktidentifikatoren

Card-G2-A_3479 - Kodierung von Versionskennungen

Jede Versionsnummer MUSS wie folgt in 3 Oktetten kodiert werden:

        1. Das 1. Oktett enthält I2OS(Hauptversionsnummer, 1)

        2. Das 2. Oktett enthält I2OS(Nebenversionsnummer, 1)

        3. Das 3. Oktett enthält I2OS(Revisionsnummer, 1)

[<=]

Versionskennung, wie sie in Produkttypen und Produktidentifikatoren verwendet werden, müssen nach einem einheitlichen Schema kodiert werden:

Card-G2-A_3480 - Kodierung von Produktidentifikatoren

Jeder Produktidentifikator MUSS wie folgt in 16 Oktetten kodiert werden:

      1. Die ersten fünf Oktette enthalten die von der gematik vergebene Hersteller-ID, wobei jedes Oktett genau ein in UTF-8 kodiertes Zeichen enthält.

      2. Die nächsten acht Oktette enthalten ein vom Hersteller gewähltes und im Rahmen der Zulassung angegebenes Produktkürzel, wobei jedes Oktett genau ein in UTF-8 kodiertes Zeichen enthält.

      3. Die Oktette 14 bis 16 enthalten eine vom Hersteller vergebene und im Rahmen der Zulassung angegebene Versionsnummer gemäß der Kodierung von Versionskennungen.

[<=]

Card-G2-A_3481 - Ausschluss für die Kodierung von Produktidentifikatoren

Die Kombination Hauptversionsnummer . Nebenversionsnummer . Revisionsnummer = 0.0.0 DARF NICHT verwendet werden. [<=]

2.2 EF.Version @deprecated

Die Datei EF.Version diente bei eGKs bis Version 1+ zur Versionierung des Card Operating Systems (COS), des eGK-Objektsystems sowie der Speicherstrukturen der eGK. Aus Gründen der Abwärtskompatibilität bleibt diese Datei und ihre Befüllung auf eGKs der Generation 2 noch erhalten. Systeme, die neu erstellt oder angepasst werden, sollten jedoch ausschließlich EF.Version2 verwenden. In kommenden Versionen des eGK-Objektsystems wird diese Datei vermutlich gestrichen werden.

Card-G2-A_3482-01 - K_Initialisierung: Speicherstruktur für EF.Version @deprecated

Wenn die Datei EF.Version auf der eGK vorhanden ist, MUSS diese die in Tabelle Tab_Karten_Fach_TIP_003 festgelegte Struktur aufweisen.



Tabelle 3: Tab_Karten_Fach_TIP_003 Struktur der Datei EF.Version @deprecated

Informations-element
 Länge in Byte
 Typ
 Initial-wert
 Bemerkung
Version des Card Operating Systems (COS)
 5
 BCD

 ‘004 000 0000’
 Berücksichtigt [gemSpec_eGK_P1] (für eGk G1 plus) einschl. gültiger SRQs bzw. [gemSpec_COS] (für eGK G2).
Version ‘004 000 0000’ adressiert eGKs-G2 und darüber. Die konkreten Versionsnummern sind EF.ATR sowie EF.Version2 zu entnehmen.
Version des eGK-Objektsystems
5
 BCD

 ‘004 000 0000’
 Berücksichtigt [gemSpec_eGK_P2] (für eGk G1 plus) einschl. gültiger SRQs bzw. [gemSpec_eGK_ObjSys] (für eGK G2).
Version ‘004 000 0000’ adressiert eGKs-G2 und darüber. Die konkreten Versionsnummern sind EF.ATR sowie EF.Version2 zu entnehmen.
Version der Speicherstrukturen
 5
 BCD
 ‘004 000 0000’
 Versioniert alle Speicherstrukturen der TI-Plattform und der Fachanwendungen, für die nicht eine eigenständige Versionierung an anderer Stelle (z. B. mittels einer fachlichen Speicherstrukturversion innerhalb eines fachlichen Statuscontainers) erfolgt.
Versionen kleiner als 4.0.0:
Berücksichtigt [gemSpec_eGK_Fach] einschl. jeweiliger SRQs und versioniert damit alle Speicherstrukturen der eGK.
Versionen ab 4.0.0
Version ‘004 000 0000’ adressiert eGKs-G2 und darüber. Die konkreten Versionsnummern sind EF.ATR sowie EF.Version2 zu entnehmen.
Hinweis: Die Speicherstrukturen der Fachanwendungen werden in spezifischen Dateien der Fachanwendungen versioniert.
Reserviert
 5
0

[<=]

2.3 EF.Version2

Die Datei EF.Version2 dient zur Versionierung grundsätzlich veränderlicher Elemente einer Karte der Generation 2. Eine Veränderung der enthaltenen Elemente, und damit die Versionierung innerhalb dieser Datei, kann nur durch ein CMS erfolgen.

Die Versionierung von Anteilen der Karte, die auch durch ein CMS nicht verändert werden können (bzw. dürfen), erfolgt über EF.ATR.

Card-G2-A_3483-01 - K_Initialisierung: Inhalt body von EF.Version2

Der Inhalt des Attributes body MUSS eine Konkatenation von primitiven Datenobjekten sein, die von einem Constructed Element umschlossen werden.
Die EF.Version2 MUSS den in Tab_Karten_Fach_TIP_002 festgelegten Inhalt aufweisen.

Tabelle 4: Tab_Karten_Fach_TIP_002 Inhalt von EF.Version2

Tag
 L
 Wert
'EF'
 'XX'
 Inhalt EF.Version2    'XX' = Länge abhängig vom Kartentyp:
'Wert von XX' für eGK,                    '2B' (= 43 Byte)
Wert von XX' für HBA und SMC-B:         '26' (= 38 Byte)
Wert von 'XX' für die gSMC-K:            '30' (= 48 Byte)
Wert von 'XX' für die gSMC-KT:            '2B' (= 43 Byte)

Tag
 L
 Wert
'C0'
 '03'
 Versionsnummer der Befüllvorschrift für EF.Version2 (2.0.0) gemäß Kodierung von Versionskennungen
'C1'
 '03'
 Version des dem aktiven Objektsystem zugrundeliegenden Produkttyps (PT_ObjSys) gemäß Kodierung der Versionskennungen
'C2'
 '10'
 Produktidentifikation des aktiven Objektsystems (PI_Objektsystem) gemäß Kodierung von Produktidentifikatoren
'C4'
 '03'
 Versionsnummer der Befüllvorschrift für EF.GDO (1.0.0) gemäß Kodierung der Versionskennungen
'C5'
 '03'
 Versionsnummer der Befüllvorschrift für EF.ATR (2.0.0) gemäß Kodierung der Versionskennungen
'C6'
 '03'
 Versionsnummer der Befüllvorschrift für EF.KeyInfo (2.0.0) gemäß Kodierung der Versionskennungen (nur gültig für die gSMC-K und die gSMC-KT)
'C3'
 '03'
 Versionsnummer der Befüllvorschrift für die Datei EF.EnvironmentSettings (1.0.0)
nur gültig für die gSMC-K, sh. Kapitel 5.1
'C7'
 '03'
 Versionsnummer der Befüllvorschrift für EF.Logging (1.0.0) gemäß Kodierung der Versionskennungen
nur gültig für die eGK, sh. Kapitel 4.1

[<=]

Card-G2-A_3484 - K_Initialisierung: Reihenfolge der Datenobjekte in body von EF.Version2

Bei der Befüllung der Dabei EF.Version2 KANN der Hersteller bei dem initialisierten body nach dem  DO 'C0' von der Reihenfolge der Datenobjekte in der Tabelle Tab_Karten_Fach_TIP_002 abweichen. [<=]

2.4 EF.ATR (Answer to Reset)

Die transparente Datei EF.ATR enthält Informationen zur maximalen Größe der APDU. Ferner dient sie zur Versionierung unveränderlicher Elemente einer Karte.

Für das Attribut body von EF.ATR gelten folgende Festlegungen:

Card-G2-A_3485 - K_Initialisierung: Datenobjekte in EF.ATR

Der Oktettstring body MUSS DER-TLV-kodierte Datenobjekte (DO) enthalten. Die Datenobjekte MÜSSEN lückenlos hintereinander konkateniert werden.

[<=]

Card-G2-A_3486 - K_Initialisierung: DO_BufferSize in EF.ATR

In body MUSS an erster Stelle genau ein DO_BufferSize mit folgenden Eigenschaften enthalten sein:

  1. Tag = ‘E0’.
  2. DO_Buffersize MUSS genau vier DO mit einem Tag ‘02’ enthalten. Das Tag ‘02’ bezeichnet einen Integer Wert, der gemäß [ISO8825-1#8.3] codiert werden MUSS.
  3. Das erste DO mit Tag ‘02’ MUSS die maximale Anzahl der Oktette enthalten, die eine ungesicherte Kommando-APDU nicht überschreiten darf.
  4. Das zweite DO mit Tag ‘02’ MUSS die maximale Anzahl der Oktette enthalten, die eine ungesicherte Antwort nicht überschreiten darf.
  5. Das dritte DO mit Tag ‘02’ MUSS die maximale Anzahl der Oktette enthalten, die eine gesicherte Kommando-APDU nicht überschreiten darf.
  6. Das vierte DO mit Tag ‘02’ MUSS die maximale Anzahl der Oktette enthalten, die eine gesicherte Antwort nicht überschreiten darf.
[<=]

Card-G2-A_3487 - K_Initialisierung und K_Personalisierung: DO_HistoricalBytes in EF.ATR

In body MUSS an zweiter Stelle genau ein DO_HistoricalBytes mit folgenden Eigenschaften enthalten sein:

  1. Tag = ‘5F52’.
  2. Das Wertfeld von DO’5F52’ MUSS Historical Bytes enthalten, die gemäß ISO/IEC 7816-4 zu kodieren sind.
  3. Das erste Oktett des Wertfeldes von DO_HistoricalBytes MUSS aus der Menge Category Indicator = {’00’, ’80’} gewählt werden.
  4. Das Wertfeld von DO_HistoricalBytes MUSS genau ein DO_PreIssuingData als COMPACT-TLV data object mit folgenden Eigenschaften enthalten:
    1. Tag/Length = ’6y’, wobei „y“ die Zahl der Oktette angibt.
    2. Das erste Oktett des Wertfeldes MUSS die Chiphersteller-ID gemäß [SD5] enthalten (siehe auch Hersteller-Kennungen).
    3. Die Oktette zwei bis sechs MÜSSEN die Kartenhersteller-ID enthalten. Informationen zur Kartenhersteller-ID sind unter [FH-SIT] verfügbar.
    4. Weitere Oktette sind herstellerspezifisch zu codieren und können eine Betriebssystemversion eineindeutig referenzieren.
  6. Das Wertfeld von DO_HistoricalBytes MUSS genau ein DO_Card Capabilities als COMPACT-TLV data object mit folgenden Eigenschaften enthalten:
  1. Tag/Length = ’73’.
  2. Das Wertfeld von DO ’73’. MUSS den Wert ’96 21 xy’ enthalten.
  3. Die obersten drei Bits in ‘xy’ MÜSSEN gesetzt sein.
  4. Die Bits b5 und b4 in ‘xy’ MÜSSEN entweder
    1. anzeigen, dass die Smartcard nur den Basiskanal unterstützt, oder
    2. anzeigen, dass die Kanalnummer von der Smartcard zugewiesen wird.
  6. Die unteren drei Bits in ‘y’ MÜSSEN die Anzahl unterstützter Kanäle anzeigen.

[<=]

Card-G2-A_3488 - K_Initialisierung: DO_PT_COS in EF.ATR

In body MUSS ein DO_PT_COS mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D0’.

      2. Das Wertfeld enthält die Produkttypversion von PT_COS  gemäß der Kodierung von Versionskennungen.

Die Angaben Hauptversionsnummer, Nebenversionsnummer und Revisionsnummer entsprechen der im Rahmen der Zulassung angegebenen Version des zugrundeliegenden Produkttyps. [<=]

Card-G2-A_3489 - K_Initialisierung: DO_PI_CHIP in EF.ATR

In body MUSS ein DO_PI_Chip mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D2’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation des Chips gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3490 - K_Initialisierung: DO_PI_COS in EF.ATR

In body MUSS ein DO_PI_COS mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D3’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation des COS gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3491 - K_Initialisierung: DO_PI_InitialisiertesObjSys in EF.ATR

In body MUSS ein DO_PI_InitialisiertesObjSys mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D4’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation des initialisierten Objektsystems gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3492 - K_Personalisierung: DO_PT_Pers in EF.ATR

In body KANN ein DO_PT_Pers mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D5’.

      2. Das Wertfeld enthält die Produkttypversion von PT_Pers gemäß der Kodierung von Versionskennungen.

      3. Die Angaben Hauptversionsnummer, Nebenversionsnummer und Revisionsnummer entsprechen der im Rahmen der Zulassung angegebenen Version des zugrundeliegenden Produkttyps.

[<=]

Card-G2-A_3493 - K_Initialisierung DO_PI_Kartenkörper in EF.ATR-Initialisierung

In body KANN ein DO_PI_Kartenkörper mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D6’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation des Kartenkörpers gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3494 - K_Personalisierung: DO_PI_Kartenkörper in EF.ATR-Personalisierung

In body MUSS ein DO_PI_Kartenkörper mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D6’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation des Kartenkörpers gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3495 - K_Personalisierung: DO_PI_Personalisierung in EF.ATR-Personalisierung

In body KANN ein DO_PI_Personalisierung mit folgenden Eigenschaften enthalten sein:

      1. Tag = ‘D7’.

      2. Das Wertfeld enthält die im Rahmen der Zulassung angegebene Produktidentifikation der Personalisierung gemäß der Kodierung von Produktidentifikatoren.

[<=]

Card-G2-A_3496 - K_Initialisierung: Weitere Datenobjekte in DO_HistoricalBytes in EF.ATR

Das Wertfeld von DO_HistoricalBytes KANN weitere COMPACT-TLV-codierte Datenobjekte enthalten.

[<=]

Card-G2-A_3497 - K_Personalisierung: Vollständige Befüllung von EF.ATR

EF.ATR MUSS mit Abschluss der Personalisierung vollständig befüllt sein. Semantisch nicht verwendeter Speicher MUSS mit DO'CF' gefüllt sein

[<=]

Hinweis: Möglicherweise wird die optionale Kennzeichnung der Personalisierung (PT_Pers und PI_Personalisierung) in einer Folgeversion verpflichtend.

2.5 EF.GDO

EF.GDO enthält die Seriennummer der Karte.

Hinweis: Die Kennung eines Kartenherausgebers (Issuer Identifier) erlaubt in Verbindung mit dem Ländercode eine weltweit eineindeutige Identifizierung des Kartenherausgebers. In Verbindung mit der Seriennummer ist es deshalb möglich, eine Karte weltweit eineindeutig zu referenzieren.

Hinweis: Die Kennung des Kartenherausgebers entsprechend [EN1867] wird in Deutschland im Auftrag des DIN durch GS1 Germany GmbH, Köln (www.gs1-germany.de) vergeben. Der Kartenherausgeber ist gewöhnlich der rechtmäßige Besitzer der ausgegebenen Karte.



Card-G2-A_3498 - K_Personalisierung: DO_ICCSN in EF.GDO

In body MUSS genau ein DER–TLV codiertes Datenobjekt DO_ICCSN mit folgenden Eigenschaften enthalten sein:

  1. Tag = ‘5A’ und Längenfeld = ‘0A’.
  2. Für das Wertfeld MUSS gelten:
  1. Das erste Oktett MUSS den Major Industry Identifier (MII) mit dem Wert ‘80’ enthalten, welcher eine Gesundheitskarte kennzeichnet (siehe [EN1867]).
  2. Die nächsten drei Nibble MÜSSEN den Country Code Deutschlands mit dem Wert ‘276’enthalten (siehe [ISO3166-1]).
  3. Die nächsten fünf Nibble MÜSSEN den Issuer Identifier enthalten.
  4. Die restlichen fünf Oktette MÜSSEN BCD codiert eine Seriennummer enthalten.
[<=]

3 Befüllvorschriften für Karten mit der Option „Lange Lebensdauer im Feld“

3.1 EF.KeyInfo (Struktur der Zugriffstabelle)

Die Datei EF.KeyInfo dient zur Adressierung der Schlüssel und zugehörigen Zertifikate einer Karte, die aktuell verwendet werden müssen. Bei der Option „Lange Lebensdauer im Feld“ wird nach Ablauf der Nutzbarkeit eines Schlüssels auf einen neuen Schlüssel und das dazugehörende Zertifikat umgeschaltet. Bei diesem Umschalten müssen die Inhalte von EF.KeyInfo entsprechend geändert werden.

Inhalt und Struktur der Datei EF.Keyinfo werden erst festgelegt, wenn Funktionalität und Schnittstellen des Certificate Update Service (CUpS) spezifiziert werden. Die damit einhergehende Befüllvorschrift erhält die Versionsnummer 2.0.0.

4 Befüllvorschriften für die Plattformanteile der eGK

4.1 EF.Logging (Protokolldaten)

Die Datei EF.Logging der eGK wird mit 50 Records fester Satzlänge rotierend beschrieben (siehe [gemSpec_eGK_ObjSys]. Die Datei EF.Logging ist auf der eGK als zyklische Datei nach dem FIFO-Prinzip umgesetzt, so dass hier keine Informationen zum Füllstand der Datei beschrieben oder verwaltet werden.

Card-G2-A_3506 - Speicherstruktur für EF.Logging

Die Rekords der Datei EF.Logging der eGK MÜSSEN die in Tab_Karten_Fach_TIP_010 festgelegte Struktur aufweisen.

Tabelle 5: Tab_Karten_Fach_TIP_010 _StrukturEF.Logging – Struktur der Rekords der Datei EF.Logging

Informations-element
 Länge in Byte
 Typ
 Initialwert
 Bemerkung
Timestamp
 4
 BINÄR
 0
 Zeitpunkt des Datenzugriffs in der Form, dass die Anzahl der Sekunden, die seit dem 1.1.1970 00:00 UTC vergangen sind, angegeben werden.
Data Type
 1
 ALPHA
 0x00
 Diese Werte werden durch die Fachanwendungen definiert.
Type of Access
 1
 ALPHA
 0x00
 Diese Werte werden durch die Fachanwendungen definiert.
Actor-ID
 10
 BCD
 0
 EU-Resolution-190-konforme ICCSN des HBA oder der SMC-B des zugreifenden Akteurs
Actor-Name
 30
 ALPHA
 0x00
 Name des zugreifenden Akteurs.
Beim Zugriff über die SMC-B wird als Akteurs-Name der CN (Common Name) des OSIG-Zertifikats verwendet.
Beim Zugriff über den HBA wird aus dem AUT-Zertifikat zunächst das Feld SN (Nachname) und anschließend das Feld GN (Vorname) verwendet. Zwischen SN und GN wird ein Komma als Trennzeichen benutzt (SN, GN).
Wenn die Zeichenkette (CN aus OSIG oder "SN,GN" aus AUT)
länger als 30 Byte ist, dann werden die ersten 30 Byte verwendet
kürzer als 30 Byte ist, dann wird die Zeichenkette am Ende mit Leerzeichen (0x20) auf 30 Byte aufgefüllt.

[<=]

4.2 Vorlage für Fachanwendungen der eGK (informativ)

Die meisten Fachanwendungen besitzen entsprechend [gemSpec_eGK_P2] bzw. [gemSpec_eGK_ObjSys] (jeweils einschl. relevanter SRQs) einen Status-Container zur Ablage von Verwaltungsinformation wie z. B. Statusinformationen, Zeitstempel und Versionsinformationen.

Ziel dieses Kapitels ist es, eine informative Vorlage zur Strukturierung des Status-Containers der Fachanwendung zu geben, damit einheitliche Mechanismen zur Abbildung von Statusattributen, Zeitstempeln für Zugriffe sowie zur Versionierung auf der eGK Anwendung finden. Die jeweils konkrete Ausprägung des Status-Containers einer Fachanwendung wird in den Dokumenten der Fachanwendung festgelegt.

Hierzu definiert Tab_Karten_Fach_TIP_011 die empfohlene Struktur des Status-Containers einer Fachanwendung. Hierbei kann der Status-Container die Verwaltungsinformation für mehrere fachliche Container beinhalten.

Tabelle 6: Tab_Karten_Fach_TIP_011 Struktur der Datei EF.Status<Fachanwendung> für eine Fachwendung

Informationselement
 Länge in Byte
 Typ
 Initialwert
 Bemerkung
Status
 1
 ALPHA

 „0“
 „1“ = Transaktionen offen
„0“ = keine Transaktionen offen
Timestamp
 14
 ALPHA
 Siehe 1.
 Timestamp in UTC der letzten Aktualisierung der <Fachanwendung> im Format YYYYMMDDhhmmss
Version fachliches Informationsmodell
 5
 BCD
 0x0000000000
 Version des fachlichen Informationsmodells, z. B. des XSD-Schema
Version fachliche Speicherstruktur
 5
 BCD
 0x0000000000
 Version der fachlichen Speicherstruktur.
Das Informationselement Timestamp wird mit dem Zeitstempel des Personalisierungszeitpunktes (UTC) vorbelegt.

4.3 KVNR für Prüfkarten eGK

Gemäß [RiKvnr#2.2] besteht eine KVNR aus einem unveränderbaren Teil, einem veränderbaren Teil und einer Prüfziffer. Für den unveränderbaren Teil legt [RiKvnr] in den Zeilen 173 bis 177 folgendes fest, Zitat:

Der unveränderbare Teil der Krankenversichertennummer beginnt an der ersten Stelle mit einem Großbuchstaben. Der Großbuchstabe wird zufällig aus dem Wertebereich A bis Z gebildet. Umlaute werden nicht verwendet. Die 2. bis 9. Stelle ist numerisch. Eine Ziffernfolge, in der mehr als drei gleiche Ziffern hintereinander auftreten, ist auszuschließen. Ebenso sind Nummern auszuschließen, welche die Ziffernfolge ‚666‘ enthalten.

Zitatende.

Hinweis: Der GKV-Spitzenverband weist darauf hin, dass die  ausschließliche Aufnahme der Ziffernfolge "666" nicht ausreichend für die Unterscheidbarkeit von Echt- und Test-KVNRn ist. Um eine eineindeutige Unterscheidbarkeit zu gewährleisten, muss mindestens viermal die gleiche Ziffer hintereinander folgen.

Für den unveränderbaren Teil der KVNR in Prüfkarten eGK wird nun absichtlich eine Bildungsregel festgelegt, welche den zuvor zitierten Vorgaben widerspricht. Diese bewusst gewählte Abweichung in der Bildungsregel ist das Unterscheidungsmerkmal zwischen Echtkarten einerseits und Prüfkarten andererseits:

A_23426 - unveränderbarer Teil der KVNR in Prüfkarten

Der Generator von KVNR für Prüfkarten eGK MUSS für deren unveränderbaren Teil folgendes Schema verwenden: "?0000nnnnP", wobei gilt:
1. "?", ein Großbuchstabe aus dem Intervall ['A', 'Z'] (Hinweis: Das Intervall enthält 26 Elemente),
2. "0000", vier aufeinanderfolgende Ziffern "0",
3. "nnnn", eine vierstellige Zahl (mit führenden Nullen) aus dem Intervall ["0001", "9999"],
4. "P", gültige Prüfziffer aus dem Intervall [0, 9] gemäß den Bildungsregeln für KVNR. [<=]

5 Befüllvorschriften für die Plattformanteile der gSMC-K

5.1 EF.EnvironmentSettings (Umgebungskennzeichnung)

Gemäß Testkonzept [gemKPT_Test#TIP1-A_2839] muss ein Hersteller eines Konnektors seine Modelle in drei Ausführungen vorsehen: Eine für die Testumgebung, eine für die Referenzumgebung und eine für die Produktivumgebung.

Damit trotz dieser Forderung die Firmware je Konnektorversion für alle drei Umgebungen identisch ist, werden die Erkennung der Umgebung, sowie die pro Umgebung notwendigen Parameter an die gSMC-K gebunden. Die gSMC-K besitzt hierzu den ReadOnly-Datencontainer EF.EnvironmentSettings.

Card-G2-A_3507 - K_Personalisierung Versionierung Inhalte von EF.EnvironmentSettings

In EF.Version2 der gSMC-K MUSS ein DO ’C3’ enthalten sein. Das DO ’C3’ MUSS die Version der Befüllvorschrift für die Datei EF.EnvironmentSettings enthalten. [<=]

Card-G2-A_3509 - K_Personalisierung Inhalt von EF.EnvironmentSettings

Das Byte 0 in der Datei EF.EnvironmentSettings der gSMC-K MUSS bei der Personalisierung von Testkarten mit dem Wert 0 gefüllt werden.
Das Byte 0 in der Datei EF.EnvironmentSettings der gSMC-K MUSS bei der Personalisierung von Produktivkarten mit dem Wert 1 gefüllt werden. [<=]

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Kürzel
 Erläuterung
ALPHA
 Datentyp siehe Tabelle 1
BCD
 Datentyp siehe Tabelle 1
COS
 Card Operating System
HBA
 Heilberufsausweis
KVNR Krankenversichertennummer
SMC-B
 Secure Module Card – Type B
TI
 Telematikinfrastruktur
XML
 Extensible Markup Language
XSD
 XML Schema Definition
eGK Elektronische Gesundheitskarte

6.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

6.3 Tabellenverzeichnis

6.4 Referenzierte Dokumente

6.4.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Version und Stand der referenzierten Dokumente sind in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in den von der gematik veröffentlichten Produkttypsteckbriefen enthalten, in der die vorliegende Version aufgeführt wird.


[Quelle]
 Herausgeber: Titel
[gemGlossar]
 gematik: Glossar der Telematikinfrastruktur
[gemSpec_COS]
 gematik: Spezifikation des Card Operating System (COS) – Elektrische Schnittstelle
[gemSpec_eGK_ObjSys]
 gematik: Spezifikation eGK-Objektsystem
[gemSpec_HBA_ObjSys]
 gematik: Spezifikation HBA Objektsystem
[gemSpec_SMC-B_ObjSys]
 gematik: Spezifikation SMC-B Objektsystem
[gemSpec_gSMC-K_ObjSys]
 gematik: Spezifikation gSMC-K Objektsystem
[gemSpec_gSMC-KT_ObjSys]
 gematik: Spezifikation gSMC-KT Objektsystem
[gemSpec_Kon]
 gematik: Spezifikation Konnektor
[gemSpec_OM]
 gematik: Übergreifende Spezifikation Operations und Maintenance

6.4.2 Weitere Dokumente

[Quelle]
 Herausgeber: Titel
[EN1867]
 EN 1867:1997
Machine readable cards – Health care applications – Numbering system and registration procedure for issuer identifiers
[FH-SIT] Fraunhofer SIT
Anträge zur Erteilung der Kartenhersteller-ID:
http://www.sit.fraunhofer.de/ ,bzw.
http://141.12.72.35/_karten_ident/SIT/pdfs/ICCM_Antrag_2006.pdf.

Übersicht bereits erteilter Kartenhersteller-IDs:
siehe [Hersteller-Kennungen]
Hersteller-Kennungen http://www.kartenbezogene-identifier.de/ http://www.kartenbezogene-identifier.de/de/chiphersteller-kennungen.html http://www.kartenbezogene-identifier.de/de/kartenhersteller-kennungen.html 
[ISO3166-1]
 ISO/IEC 3166-1: 2006
Codes for the representations of names of countries and their subdivisions – Part 1: Country codes
[RiKvnr]
 Richtlinie zum Aufbau und zur Vergabe einer Krankenversichertennummer und Regelungen des Krankenversichertennummernverzeichnisses nach § 290 SGB V
Stand 20. September 2022
https://www.gkv-datenaustausch.de/media/dokumente/kvnr/Richtlinie_20220920_Gesamtsystem-KVNR__290_SGBV_3.2.0.pdf
[SD5] ISO/IEC JTC1/SC17 STANDING DOCUMENT 5, 2006-06-19
Register of IC manufacturers