Elektronische Gesundheitskarte

Einleitung

Die seit dem 1. Januar 1995 eingeführte Krankenversichertenkarte (KVK) sollte am 1. Januar 2006 durch die Elektronische Gesundheitskarte (eGK) abgelöst werden.

Neben der Speicherung der schon auf der KVK vorhanden Daten, soll die eGK

• das Ablegen und Auslesen von elektronischen Rezepten (eRezept) gestatten,
• Möglichkeiten zur Authentifizierung, Verschlüsselung und Signierung bieten,
• ein Berechtigungssystem für Individuen/Rollen unterstützen,
• den Karteninhaber befähigen
  • zu bestimmen, welche Daten überhaupt gespeichert werden,
  • zu bestimmen, wer Zugriff auf diese erhält,
  • nachverfolgen zu können, wer wann zugegriffen hat,
  • jederzeit Berechtigungen erteilen oder entziehen zu können.

Offensichtlich können diese Anforderungen nicht von einer reinen Speicher-Chipkarte wie der KVK erfüllt werden, daher ist die eGK eine Prozessor-Chipkarte, welche wiederum Komponente einer umfangreichen Gesundheitsinfrastruktur darstellt.

Anwendungen

Die von der eGK und der mit ihr eingeführten Infrastruktur unterstützten Anwendungen können in Pflichtanwendungen – welche von Anfang an, d.h. bei der Einführung, unterstützt werden sollten –, freiwillige Anwendungen – welche später in mehreren Stufen eingeführt werden sollten –, nichtmedizinische Anwendungen und weitere Mehrwehrtdienste unterschieden werden.

Pflichtanwendungen

Diese sind obligatorisch und können nicht vom Versicherten deaktiviert werden

Versichertenstammdatenmanagement (VSDM)

Verwaltet die (schon auf der KVK enthaltenen) Stammdaten:

• Titel, Name, Geschlecht und Anschrift der Versicherten,
• Versichertennummer, Name und Nummer der Krankenkasse
• Zuzahlungstatus,
• Zeitpunkt ab welchem die Karte gültig ist und evtl. Ablaufdatum.

So soll weiterhin eine routinemäßige, vollautomatische Prüfung des Versichertenstatus sichergestellt werden.

Verordnungsdatenmanagment (VODM)

Speichert die vom Arzt oder -gehilfen ausgestellten elektronischen Rezepte (eRezept) und ermöglicht dem Versicherten diese bei einem Apotheker oder -gehilfen einzulösen. Der Karteninhaber soll hierbei auch einzelne eRezepte verbergen können dürfen (bspw. ein eRezept für Neuroleptika bei Einlösung eines anderen für Medikamente gegen Fußpilz).

European Health Insurance Card (EHIC)

Wird wie schon bei der KVK als Sichtausweis auf der Rückseite der eGK umgesetzt (gemäß Beschluss 190 der Verwaltungskommission der EU).

Anwendungen zur Wahrnehmung der Versichertenrechte (AdV)

Jeder Versicherte soll selbst darüber entscheiden können, welche Daten gespeichert, gelöscht oder von einem Leistungserbringer (LE), d.h. Arzt, Apotheker, Krankenkasse etc., eingesehen werden können. Ausgenommen davon sind die Versichertenstammdaten.

Weiterhin muss der Karteninhaber sämtliche Zugriffe auf seine Patientendaten nachvollziehen können.

Mit Ausnahme des VODM sollten alle o.g. Funktionen der eGK schon bei ihrer Einführung bereitstehen.

Freiwillige Anwendungen

Diese können durch den Karteninhaber jederzeit aktiviert oder wieder deaktiviert werden.

Notfallversorgungsdaten (NFD)

In einem Notfall soll Notarzt auch ohne Anbindung an das Gesundheitsnetzwerk Zugriff auf notfallrelevante Diagnosen, Medikationen, Unverträglichkeiten usw. erhalten.

Hier wird außerdem – sofern vom Karteninhaber gewünscht – der Organspendeausweis und die Patientenverfügung abgelegt, da diese Anwendung als einzige den Zugriff auf medizinische Daten ohne Autorisierung durch den Karteninhaber ermöglicht.

Das Zusammenstellen der NFD kann der Versicherte vorher mit seinem Arzt durchführen.

Daten zur Prüfung der Arzneimitteltherapiesicherheit (AMTS)

Hier sollen verordnete, abgegebene, verabreichte oder von einem Krankenhaus empfohlene Medikamente, sowie medizinische Individualparameter (Laborwerte, Diagnosen, Prozeduren) gespeichert werden, sodass Therapien in Hinblick auf Unverträglichkeiten und Wechselwirkungen von Arzneien und Behandlungsmethoden besser aufeinander abgestimmt werden können.

Elektronischer Arztbrief (eArztbrief)

Diese Anwendung ermöglicht den Austausch von Befunden, Diagnosen, Therapieempfehlungen sowie Therapieempfehlungen für eine einrichtungsübergreifende, fallbezogene Kooperation.

Elektronisches Patientfach (ePF)

Persönliche, nicht für die medizinische Versorgung unbedingt notwendige Daten wie Impfausweis, Diabatesverlauf und andere vom Arzt zur Verfügung gestellte Daten werden hier abgelegt.

Elektronische Patientenakte (ePA)

Die Patientenakte enthält sämtliche Daten zu Diagnosen, Krankheitsverläufen, Operationen, Medikationen, Röntgenbildern, Zahnarztbefunden etc. und wird fortwährend von Heilberuflern ergänzt.

Durch die Speicherung der kompletten Krankheitsgeschichte des Versicherten in der eGK-Infrastruktur kann auf diese in kürzester Zeit und von überall zugegriffen werden. Die Akte liegt also beim Patienten und nicht beim Arzt.

Der Karteninhaber bestimmt als einziger, welche Teile der Patientenakte er wann, welchem Heilberufler zugänglich macht.

Elektronische Patientenquittung

Um die Kosten von Behandlung und Medikamenten für den Versicherten transparenter bzw. überhaupt nachvollziehbar zu machen, werden diese hier gespeichert.

Die freiwilligen Anwendungen werden schrittweise und teilweise erst nach der flächendeckenden Einführung der eGK gestartet.

Nichtmedizinische Anwendungen

Diese Anwendungen dienen nicht medizinischen, sondern Verwaltungszwecken, beispielweise

Card Application Management Service (CAMS)

Ermöglicht festzustellen, welche Anwendungen auf der eGK aktiviert, deaktiviert oder überhaupt vorhanden sind.

Hier kann der Benutzer freiwillige Anwendungen aktivieren oder deaktivieren.

Update-Flag Service (UFS)

Diese Anwendung zeigt an, welche Fachdienste auf die eGK zugreifen möchten. Somit muss nicht jedesmal, wenn die Karte mit dem Gesundheitsnetzwerk verbunden wird, jeder Dienst einzeln abgefragt werden, ob er ein Datenupdate für die Karte bereithält, sondern lediglich der UFS, welcher seinerseits von den entsprechenden Fachdiensten informiert wurde.

Mehrwertanwendungen

Dazu zählen alle verteilten Anwendungen, also Schnittstellen, Protokolle etc., die nicht zu den spezifizierten Komponenten der eGK-Infrastruktur gehören, diese aber in Teilen nutzen und für mindestens eine Nutzergruppe der Infrastruktur einen Nutzwert darstellen.

Äußere Gestaltung

eGK-Vorderseite

eGK-Rückseite

HBA-Varianten

Für die eGK sind genaue Bemaßungen für die unterschiedlichen Felder, zu verwendende Schriftgrößen, -arten, Farben, Zeilen- und Zeichenabstände definiert.

Feldaufteilung und Bemaßung der Vorderseite

Neben den schon von der KVK bekannten Elementen Leonardo-Logo, Krankenkassen-Logo, Krankenkassen- und Versichertendaten sind augenscheinlichste Neuerungen

• ein Foto des Versicherten
• der Schriftzug Elektronische Gesundheitskarte mit Schwarz-Rot-Gold-Balken
• der Schriftzug eGK in ertastbarer Blindenschrift

Die Rückseite wird wie schon bei der KVK der Europäische Gesundheitsausweis sein, welcher auch die Unterschrift des Versicherten enthält.

Speicherstruktur

Die auf der eGK gespeicherten Daten sind hierarchisch (MF: Master File, DF: Directory File, EF: Elementary File) organisiert.

Als Datenstrukturen kommen für Index-Tabellen, Status-Tabellen etc. Records fester oder variable Länge, deren Felder Zeichenketten (Typ ALPHA), Wahrheitswerte (Typ BINÄR, 0 oder 1) oder BCD-Codes (für Zahlen und Datumswerte) sind, sowie für Nutzdaten der Anwendungen – bspw. eRezepte – GZip-komprimierte XML-Dokumente zum Einsatz.

Die Nettodatenmenge übersteigt dabei nicht 58 Kilobyte.

MF	Master File
EF.GDO	Kennnummer der Karte
EF.ATR	Betriebsysteminformationen
EF.DIR	Liste der Anwendungstemplates
EF.ARR	Access Rule References – Zugriffsregeln (Lineare Struktur unterschiedlich langer Records)
EF.PIN	PIN für Online-Zugriff und PIN für Offline-Zugriff
EF.PrK	privater Schlüssel für Card-to-Card-Authentifizierung
EF.PuK	öffentliche Schlüssel der verschiedenen Zertifikate-Aussteller (CAs)
DF.ESIGN	ESIGN-Anwendung (elektronische Signatur, Verschlüsselung, Client-Server-Authentifizierung
EF.ARR	Zugriffsregeln
EF.C.CH.ENC	Kartenhalter-Zertifikat für Verschlüsselung
EF.C.CH.AUT	Kartenhalter-Zertifikat für Authentifizierung
EF.C.CH.ENCV	Kartenhalter-Zertifikat für Verschlüsselung von Verordnungen
EF.C.CH.AUTN	Kartenhalter-Zertifikat für Authentifizierung von Nachrichten
EF.PrK.CH.ENC	Kartenhalter-Privatschlüssel für Verschlüsselung
EF.PrK.CH.AUT	Kartenhalter-Privatschlüssel für Authentifizierung
EF.PrK.CH.ENCV	Kartenhalter-Privatschlüssel für Verschlüsselung von Verordnungen
EF.PrK.CH.AUTN	Kartenhalter-Privatschlüssel für Authentifizierung von Nachrichten
EF.DM	Display Message
DF.HCA	Gesundheitskarten-Anwendungen
EF.ARR	Zugriffsregeln
EF.VD	allgemeine Versichertendaten zum Krankenversicherungsverhältnis
EF.GVD	geschützte Versichertendaten (nur zusammen mit HBA lesbar)
EF.PD	private Versichertendaten
EF.eVOTickets	Tickets mit symmetrischen Schlüsseln sowie nur für Karteninhaber lesbare Daten (Ausstellername, -datum, Medikamentenname)
EF.eVOContainer	eRezepte (max. 8 Stück) im GZip-komprimierten XML-Format, Signaturen der Aussteller
EF.NFD	Notfalldaten, Organspendeausweis und Patientenverfügung in GZIP-komprimierten XML-Format, jeweils mit den Signaturen der bei der Erstellung beteiligten Ärzte
EF.Logging	Zugriffsprotokoll als 50 Records (Timestamp, Data Type, Actor Name, Actor ID) fester Länge in einer FIFO-Struktur
EF.Verweis	Verweise auf Einwilligungen in freiwillige Dienste (max. 10 Einträge): Diensttyp (z.B. "AMTS", "NFD") und für Karteninhaber lesbarer Dienstname
EF.Einwilligung	Einwilligungen in freiwillige Dienste: Diensttyp (z.B. "AMTS", "NFD"), Einwilligungsstatus (will / will nicht), Einwilligungsdatum, Name des beteiligten Heilberuflers
EF.StatusVD	Datum der letzten Aktualisierung, Versionsnummer der Datenstruktur, Transaktionsstatus (1 = offen, 0 = keine) für Versichertenstammdaten
EF.StatusVO	Datum der letzten Aktualisierung, Versionsnummer der Datenstruktur, Transaktionsstatus (1 = offen, 0 = keine) für Verordnungsdaten
EF.StatusNFD	Datum der letzten Aktualisierung, Versionsnummer der Datenstruktur, Transaktionsstatus (1 = offen, 0 = keine) für Notfalldaten

Gesamtarchitektur

Rund um die eGK ist eine komplexe Architektur entwickelt worden, die sich grob in drei Infrastrukturen aufteilen lässt

• Primärsysteme
• Telematik-Infrastruktur
• Fachdienste

Primärsysteme

Dazu zählen schon bestehende Infrastrukturen:

• Krankenhausinformationssysteme (KIS),
• Praxisverwaltungssysteme (PVS),
• Apothekenverwaltungsysteme (AVS),
• Systeme der Kostenträger (d.h. Krankenkassen),

aber auch neue Anwendungen:

• eKiosk: öffentlich zugängliche Terminals (z.B. in einem Krankenhaus), die den Zugriff auf die eigenen Krankendaten ermöglichen (vergleichbar mit einem Geldautomaten),
• Versicherter@Home: der Zugriff auf die eigenen Krankendaten mittels Kartenlesegerät am heimischen PC.

Telematik-Infrastruktur

Diese stellt das Herzstück des Gesundheitsnetzwerkes dar. Telematik ist in ein Kunstwort, dass sich aus Telekommunikation und Informatik zusammensetzt.

Gematik

Logo der Gematik

Die 2005 eigens gegründete Gematik – Gesellschaft für Telematik-Anwendungen der Gesundheitskarte mbH (www.gematik.de) ist mit der Einführung, Pflege und Weiterentwicklung der Telematik-Infrastruktur betraut.

Gesellschafter sind die Bundesärzte- und Zahnärztekammer sowie verschiedene Ärzte-, Zahnärzte, Apotheker- und Krankenkassenverbände.

Komponenten

Die Telematik-Infrastruktur besteht aus folgenden dezentralen

• Elektronische Gesundheitskarte (eGK)
• Heilberufsausweis (HBA) oder Security Module Card Typ A oder B (SMC-A, SMC-B)
• Kartenterminal (KT)
• Konnektor

und folgenden zentralen Komponenten

• VPN-Konzentrator
• Broker
• Audit-Service

Die Karten eGK, HBA, SMC

Um die AdV zu gewährleisten, werden sämtliche Zugriffe auf Daten, welche auf der eGK oder in den Fachdiensten des Gesundheitsnetzwerkes gespeichert sind, protokolliert und – nur für den Karteninhaber lesbar – verschlüsselt. Da nicht jeder Zugriff auf Patientendaten (z.B. NFD oder eRezepte) eine Anbindung an die Telematikinfrastruktur erfordert, werden die letzten 50 Zugriffe zusätzlich auf der Karte selbst gespeichert.

Der HBA dient der Authentifizierung des Heilberuflers, d.h. Arztes, Zahnarztes oder Apothekers. Außerdem kann ein Arzt mit diesem erstellte Patientdaten oder Rezepte signieren.

Damit auch anderem medizinischen Personal – wenn auch eingeschränkter – Zugriff auf Patientdaten, eRezept etc. ermöglicht wird, gibt es die SMC, mit welcher sich Institutionen authentifizieren. SMC können in Kartenform (Typ A) oder bereits fest in das Kartenterminal integriert (Typ B) vorkommen.

Die privaten Schlüssel für Verschlüsselung bzw. Signierung befinden sich in einem gesonderten von außen nicht zugänglichen Speicherbereich der Chip-Karte und verlassen auch niemals die Karte.

Das Kartenterminal

Stationäres Kartenterminal eHealth200 BCS der Firma SCM Microsystems

Mobiles Kartenterminal eHealth500 mobile der Firma SCM Microsystems

Das Kartenterminal stellt die Schnittstelle zwischen eGK und HBA/SMC einerseits und Konnektor andererseits dar. Der Zugriff auf sensible Patientendaten soll nur dann möglich sein, wenn sowohl eGK als auch HBA eingesteckt und durch (eine mindestens sechsstellige) PIN-Eingabe angemeldet sind (Ausnahmen sind Notfalldaten, Patientenverfügungen etc.).

Stationäre Kartenterminals dienen in erster Linie der Authentifizierung, Signierung und Verschlüsselung von Patientendaten in den Arzt- und Zahnarztpraxen, sowie Krankenhäusern.

Mobile Kartenterminals sollen dem Heilberufler erlauben, ungeschützte Patientendaten aus eGK und KVK auszulesen (z.B. Versichertenstammdaten, Notfallversorgungsdaten, Patientenverfügungen), relevante Informationen zwischenzuspeichern und später in das Primärsystem (KIS, PVS oder AVS) zu übertragen.

Der Konnektor

Card OS HealthCare Connector der Firma Siemens

Die Konnektoren als Teil der dezentralen Telematik-Infrastruktur verknüpfen einerseits Kartenterminals mit den Primärsystemen, und verbinden andererseits die denzentrale mit der zentralen Telematik-Infrastruktur über das Internet via VPN.

Es handelt sich dabei um vollwertige Rechner, in denen die (symmetrische) Verschlüsselung der Versichertendaten stattfindet und die durch eine Firewall gegen Angriffe aus dem Internet geschützt sind.

Der Konnektor wird in drei funktionale Blöcke unterteilt:

• als Netzkonnektor ist er für die Herstellung und Absicherung der VPN-Anbindung an die zentrale Telematik-Infrastruktur verantwortlich, ein LAN- bzw. WAN-Paketfilter schützt ihn sowie die jeweilige Gegenseite (also zentrale Telematik-Infrastruktur oder das lokale Netz des Leistungserbringers) vor Angriffen aus dem entsprechenden Netz,
• als Anwendungskonnektor steuert er die fachlichen Anwendungsfälle, verwaltet die Kartenterminals und darin eingeführten Karten und sichert alle Verbindungen
• als Signaturanwendungskomponente erzeugt und prüft er QES. Durch eigene Zertifikate und Signierschlüssel muss er sich auch gegenüber eGK bzw. HBA einerseits und der zentralen Telematik anderseits authentifizieren.

Der VPN-Konzentrator

Deutschlandweit sollen etwa eine 100000 (Zahn-)Arztpraxen, 2000 Krankenhäuser, 21000 Apotheken sowie 300 Krankenkassen – jede über einen eigenen Konnektor – mit dem Gesundheitsnetzwerk verbunden werden. Die VPN-Konzentratoren bündeln einserseits die verschlüsselten Anfragen an die Broker-Dienste und schützen andererseits die zentrale Telematikinfrastruktur vor Angriffen von außen.

Der Broker-Service

Der Broker-Service hat vorallem drei Aufgaben:

• Er prüft anhand von Black- und Whitelists, ob der Konnektor zum Zugriff auf die Infrastruktur überhaupt berechtigt ist.

• Er anonymisiert alle von den Konnektoren gesendeten und verschlüsselten Daten, indem er zunächst die individuellen Signaturen der Heilberufler auf Gültigkeit prüft, diese dann entfernt und durch Rollensignaturen ersetzt.

• Er verteilt die medizinischen Daten an die entsprechenden Fachdienste, die die Daten zwar speichern, aber weder lesen noch einem Heilberufler zuordnen können.

Der Audit-Service

Der Audit-Dienst protokolliert und verschlüsselt (mit dem öffentlichen Schlüssel des Versicherten) alle Transaktionen, die zwischen Konnektoren und Fachdiensten stattfinden zum Zwecke der AdV (Nachvollziehbarkeit).

Fachdienste

Diese sind als verteilte Systeme konzipiert und stellen Datenbanken sowie Dienste für die eGK-Anwendungen bereit:

• Pflichtanwendungen der eGK
  • Versicherungsstammdatendienst (VSDD)
  • Verordnungsdatendienst (VODD)
  • Anwendungen zur Wahrnehmung der Versichertenrechte (AdV)
• Freiwilligen Anwendungen der eGK
  • Notfalldatendienst (NFD)
  • Arzneimitteltherapiesicherheitsprüfung (AMTS)
  • Elektronische Patientenakte (ePA)
  • Elektronisches Patientenfach (ePF)
  • Elektronischer Arztbrief (eArztbrief)
• Nichtmedizinische Anwendungen
  • Update-Flag-Service (UFS)
  • Card Application Management Service (CAMS)
  • ...

Da alle vertraulichen Daten in verschlüsselter Form gespeichert werden, können die Fachdienste auch von durch das BSI zugelassenen privaten Dienstleistern bereitgestellt werden.

Sicherheit

Aufgrund der Sensibilität der im Gesundheitsnetzwerk gespeicherten Daten sind besonders hohe Ansprüche an die Sicherheit gestellt.

Sicherheitskonzepte

Diesem Sicherheitsbedürfnis wird durch mehrere Konzepte rechnung getragen:

Authentifizierung

Jeder datenanfordernde Teilnehmer und jede in der Infrastruktur befindliche Komponente muss sich gegenüber dem jeweiligen datensendenden Dienst ausweisen (z.B. über Qualifizierte Elektronische Signaturen).

Autorisierung

Ein fein abgestimmtes Rollensystem sowie die für den Versicherten bestehende Möglichkeit, bestimmte Daten freizugeben bzw. zu verbergen oder ganze Anwendungen zu deaktivieren, sollen sicherstellen, dass nur befugten Personen/Systemen der Zugriff auf einzelne Patienteninformationen möglich ist.

Das Zwei-Karten-Prinzip verlangt, dass beide Parteien (Heilberufler und Patient) ihre jeweilige Karte in das Kartenterminal eingeführt und mittels korrekten PIN freigeschaltet haben.

Die Broker-Dienste verwalten Listen mit für den Datenzugriff gesperrten sowie freigeschalteten Konnektoren.

Verschlüsselung

Nur nach aktuellem Stand der Technik sichere Verschlüsselungsmethoden kommen zum Einsatz.

Transportwege werden durch IPsec gesichert, Daten nur via TLS/SSL versendet, Dienste über Web Service Security angesprochen.

Patientendaten werden hybrid verschlüsselt, wobei für die Ver- und Entschlüsselung der Nutzdaten ein jedesmal neu generierter Sitzungsschlüssel anwendung findet, welcher wiederum mittels eines mindestens 2048 bit langen privaten RSA-Schlüssels verschlüsselt wird. Letzterer befindet sich auf der Chip-Karte und es darf nirgends mehr eine Kopie existieren (dies muss der Kartenhersteller gegenüber dem BSI nachweisen).

Datenvermeidung und Zweckbindung

Nur die für die jeweilige Anwendung wirklich nötigsten Informationen sollen gespeichert werden und nur die dem jeweiligen Zweck dienlichen Daten abrufbar sein.

Pseudonymisierung

Um Profiling vorzubeugen, ersetzen die Broker mit den Patientendaten empfangene individuelle Signaturen durch Rollensignaturen und stückeln die verschlüsselten Patientendaten in viele kleine Pakete, welche sie an unterschiedliche Instanzen des entsprechenden Fachdienstes weiterleiten.

Zertifizierung der Komponenten

Jede Komponente, jedes Bauteil, das für die Gesundheitsinfrastruktur hergestellt wird, muss durch die gematik bzw. das BSI geprüft und zertifiziert sein, bevor es zugelassen wird.

Periodizität und Anpassung

Die gematik und das BSI prüfen und beurteilen jährlich inwiefern die angewandten Sicherheitsmechanismen dem aktuellen Stand entsprechen. Unabhängig davon werden spätestens alle sechs Jahre sämtliche eGK, HBA und SMC durch neue ersetzt.

So ist bspw. bereits geplant, den in den Chipkarten verwendeten RSA-Algorithmus durch ECC (Elliptische-Kurven-Kryptographie), welcher bei gleicher Schlüssellänge bzw. Rechenaufwand eine höhere Sicheheit bietet, zu ersetzen.

Offenlegung aller Methoden

Alle in der Gesundheitsinfrastruktur angewandten Verfahren sind öffentlich dokumentiert, sodass einer breiten Masse von Sicherheitsexperten die Prüfung, Beurteilung und vorallem das Auffinden von Schwachstellen ermöglicht wird.

Dies ist vorallem eine Lehre aus in der Vergangenheit wiederholt ausgehebelten proprietären Sicherheitsmechanismen.

Protokollierung

Der Versicherte soll die Hoheit über seine Daten haben. Um jede Transaktion nachvollziehen zu können, werden alle Zugriffe auf Gesundheitsdaten durch den Audit-Dienst bzw. die letzten 50 Zugriffe auf der Karte selbst und nur für den Karteninhaber einsehbar gespeichert.

Rechtliche Grundlagen

Erstens sind Heilberufler gesetzlich verpflichtet (§ 203 StGB), medizinische Daten vertraulich zu behandeln.

Zweitens sind Versuche unrechtmäßig an diese zu gelangen, strafbar (§§ 202a, 202b, 202c StGB), sofern angezeigt (§ 205 StGB).

Zertifikate

Die hohen Anforderungen an die Sicherheitsarchitektur rund um die eGK verlangen eine komplexe PKI mit verschiedensten Zertifikaten, die auf mehrere Weisen in Gruppen eingeteilt werden können:

• Unterscheidung nach Funktion
  • Verschlüsselungszertifikate (ENC bzw. ENCV für anomysierte Daten)
  • Authentifizierungszertifikate (AUT bzw. AUTN für anonymisierte Daten)
  • Organisationszertifikate (OSig)
• Unterscheidung nach Inhaber
  • Personen- oder Organisationszertifikate
  • Komponentenzertifikate
• Unterscheidung nach Art
  • X.509-Zertifikate
  • CV-Zertifikate (Card Verifable Certificate)

Die CV-Zertifikate werden in einer zweistufigen Hierarchie ausgestellt

Zweistufige CVCA Hierarchie

Eine zweistufige Hierarche ist aber bei X.509-Zertifikaten aufgrund schon bestehender Strukturen nicht durchsetzbar, daher wurde von der Gematik eine Bridge-Struktur entwickelt, bei der die einzelnen TSPs (Trusted Service Provider) einer zentralen Bridge Certificate Authority in einem „Certification Practice Statement” die Erfüllung bestimmter Sicherheitsvorgaben, welche vom BSI oder der Gematik jederzeit überprüft werden können, zusichern. Die individuellen Vertrauensinformationen der TSPs werden in einer signierten XML-Datei – der Trust-service Status List – abgelegt. Analog existiert für Komponenten eine Trusted Component List (TCL).

Bridge-Struktur

Bespielszenario

Das folgende Beispiel veranschaulicht den Vorgang "Patientdaten speichern" innerhalb der Telematik-Infrastruktur.

(1) Patient und Arzt stecken jeweils ihre Karte (eGK bzw. HBA) in das Kartenterminal und authentifizieren sich mittels einer sechsstelligen PIN. (2) Die vom Arzt im Praxisverwaltungssystem bereitgestellten Patientendaten werden an den Konnektor gesandt. (3) Der Konnektor erzeugt einen neuen Sitzungsschlüssel zur symmetrischen Verschlüsselung der Patientendaten. (4) Von den verschlüsselten Daten wird ein Hashwert berechnet, welcher via Kartenterminal an den Heilberufsausweis geschickt und dort mit dem geheimen Signierschlüssel des Arztes verschlüsselt wird. (5) Die so erzeugte digitale Signatur wird zusammen mit dem Zertifikat des Arztes zurück an den Konnektor gesandt. (6) Der Konnektor verschlüsselt mit dem auf der Gesundheitskarte gespeicherten öffentlichen Schlüssel den für die Patientendaten verwendeten symmetrischen Sitzungsschlüssel. (7) Der öffentliche Schlüssel, der mit diesem verschlüsselte Sitzungsschlüssel, die mit dem Sitzungsschlüssel verschlüsseleten Patientendaten sowie die digitale Unterschrift samt Zertifikat des Arztes werden via VPN an die zentrale Telematik gesandt.

(8) Der Audit-Service liest von dem ankommenden Paket verschiedene allgemeine Informationen (Arztname, Patientenname, Typ und Kurzbeschreibung des Inhalts), ermittelt Datum und Uhrzeit des Zugriffs auf die Telematik-Infrastruktur, verschüsselt diese Daten mithilfe des öffentlichen Schlüssels des Versicherten und speichert sie schließlich in der Audit-Datenbank. (9) Der Broker prüft zunächst die Gültigkeit der individuelle Signatur des Heilberuflers und ersetzt diese anschließend durch eine Rollensignatur. (10) Schließlich werden die so neu signierten Daten an den entsprechenden Fachdienst (im Beispiel: elektronische Patientenakte) weitergeleitet.

Stand der Dinge

Testregionen für die Einführung der eGK

Die Elektronische Gesundheitskarte soll in mehreren Stufen eingeführt werden.

1. Labortests: Die gematik testet einzelne Kompnenten, integrierte System und Basisverfahren unter Laborbedingungen, d.h. ohne Netzanbindung) mit Testdaten, Test-eKGs, Test-HBAs durch.
2. Zentrale und dezentrale Anwendertests: Die gematik stellt eine Musterumgebung mit eingeschränkten Online-Funktionen bereit, in welcher ausgewählte Endnutzer (Ärzte, Apotheker) mit Testdaten, Test-eGKs (100 je Testregion), Test-HBAs (30 je Testregion) die Praxistauglichkeit prüfen.
3. 10000er-Feldtest: Zehntausend Versicherte in Testregionen erhalten eKGs mit Echtdaten und können auf Pflichtanwendungen der eGK zugreifen.
4. 100000er-Feldtest: Während dieses Tests, bei dem auch einige freiwillige Anwendungen bereitgestellt werden, wird das Basis-Rollout der eGK vorbereitet.

Obwohl die Mehrheit der Versicherten die eGK in der Evaluierungsphase positiv aufgenommen hat und Datenschützer sowie Sicherheitsexperten die Gesundheitsinfrastruktur als nicht bedenklicher als bestehende Strukturen beurteilen, wurde die bundesweite Einführung der eGK immer wieder verschoben und hat bis heute (Januar 2011, also fünf Jahre nach dem gesetzlich geplanten Termin) nicht die KVK abgelöst.

Widerstand kommt vorallem von seiten der Ärzte und privaten Krankenkassen, die die Benachteiligung behinderter und älterer Menschen befürchten, Vorbehalte gegen eine zentrale Dateneinspeisung (gegenüber der gesetzlichen Schweigepflicht) haben, oder ein Finanzierungsungleichgewicht bemängeln.

Weblinks

• http://www.bmg.bund.de/krankenversicherung/elektronische-gesundheitskarte-e-health.html
• http://www.juris.de/jportal/purl/gesetze/_ges/SGB_5
• http://www.gematik.de/
• http://www.tk.de/tk/versicherung-und-tarife/die-tk-gesundheitskarte/117694
• http://www.heilberufsausweis.de/modellregionen
• http://www.stoppt-die-e-card.de/