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
Für die eGK sind genaue Bemaßungen für die unterschiedlichen Felder, zu verwendende Schriftgrößen, -arten, Farben, Zeilen- und Zeichenabstände definiert.
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
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
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
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
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 Verifiable Certificate)
Die CV-Zertifikate werden in einer zweistufigen Hierarchie ausgestellt
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).
Bespielszenario
Das folgende Beispiel veranschaulicht den Vorgang "Patientdaten speichern" innerhalb der Telematik-Infrastruktur.
|
|
Stand der Dinge
Die Elektronische Gesundheitskarte soll in mehreren Stufen eingeführt werden.
- Labortests: Die gematik testet einzelne Kompnenten, integrierte System und Basisverfahren unter Laborbedingungen, d.h. ohne Netzanbindung) mit Testdaten, Test-eKGs, Test-HBAs durch.
- 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.
- 10000er-Feldtest: Zehntausend Versicherte in Testregionen erhalten eKGs mit Echtdaten und können auf Pflichtanwendungen der eGK zugreifen.
- 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/