Die Vernetzung des deutschen Gesundheitswesens erfolgt über die Telematikinfrastuktur (TI) als sicheres und geschlossenes Netz, in das nur bekannte Akteure des Gesundheitswesens eingelassen werden. Für die TI spielt der Konnektor eine entscheidende Rolle. Er ist die eine Komponente, die u.a. für die Verbindung des lokalen Netzes einer Arztpraxis oder anderen Einrichtung mit der zentralen TI verantwortlich ist. Entsprechend muss jede Einrichtung, die an die TI angeschlossen werden will (oder muss), über einen solchen Konnektor verfügen.  

Die TI-Kritiker betiteln diesen Konnektor als „Steinzeitkonnektor“, das BMG antwortet im Referentenentwurf des kommenden Digitale Versorgung und Pflege - Modernisierungs-Gesetz (DVPMG) darauf mit dem Arbeitsauftrag an die gematik, die Vorgaben für einen „Zukunftskonnektor“ zu erstellen – und allenthalben ist zu hören, dass in diesem Zuge der Hardwarekonnektor durch einen reinen Softwarekonnektor ersetzt werden soll. Dabei sollen die ungeliebten Karten, allen voran die eGK, gleich mit verschwinden. Zu Zeiten des Smartphones seien sie ein Anachronismus und gehörten nicht mehr in die moderne Zeit. Im DVPMG wird entsprechend auch die Einführung „Digitaler Identitäten“ gefordert. Ab 2023 erst zusätzlich zu eGK, HBA und SMC-B, sollen diese später dann gänzlich alleine ohne Karten auskommen - wenn der Empfänger der digitalen Identität dies wünscht.

Der Wechsel von einem Hardware- zu einem Softwarekonnektor bekommt insbesondere vor dem Hintergrund Dringlichkeit, dass die Zertifikate der heutigen Konnektoren mit einer begrenzten Laufzeit von 5 Jahren ausgegeben wurden und werden. Die Zertifikate der Konnektoren laufen also nach und nach ab, beginnend ab September 2022. Wird hier nichts unternommen, werden ab diesem Zeitpunkt kontinuierlich Konnektoren, die älter als 5 Jahre sind, keine Verbindung mehr zur TI aufbauen können – diese Konnektoren sind dann nicht mehr nutzbar.

Aber was ist dran an der Idee, den Hardwarekonnektor vollständig durch eine reine Softwarelösung zu ersetzen? Und wo und wie wären diese Softwarekonnektoren ihren Hardwarekollegen eigentlich wirklich überlegen? Oder hätten sie vielleicht sogar Nachteile? Und was hat es mit den neuen „digitalen Identitäten“ auf sich? Kann man wirklich auf die „Steinzeitkarte“ eGK verzichten und stattdessen nur noch z.B. das Smartphone einsetzen? Auch für Ärzte und Einrichtungen?

Um diese Fragen sachlich bewerten und beantworten zu können, müssen die unterschiedlichen Aspekte zu funktionalen, wie sicherheitstechnischen Zielen des Konnektors und der Smartcards ebenso betrachtet werden, wie die sich ab 2023 teilweise ändernden Anforderungen an eine Anbindung an die TI bzw. eine Nutzung der Anwendungen der TI. Da die Liste der Dinge, die für eine sichere digitale Vernetzung und digitale Interaktion im Gesundheitswesen recht lang ist, heißt es jetzt: Bitte Durchhalten, damit am Ende besser verstanden werden kann, welche Schlüsse gezogen werden können oder sollten.

Ich kann Ihnen aber jetzt schon mitteilen, was Sie an dieser Stelle sicherlich bereits vermuteten: Gar so einfach und schwarz/weiß, wie es derzeit in der Politik und den Medien diskutiert wird, ist die Sache nicht. Und ausgedient haben Hardwareboxen sowie hardwarebasierte digitale Identitäten der Form eGK, HBA und SMC-B noch lange nicht, denn der hardwarebasierte Lösungsansatz hat eine Reihe wichtiger Vorteiler, u.a. sind diese sogar günstiger als ihre reinen Softwarelösungen – auch wenn dies überraschen mag. Am Ende heißt es dann vermutlich: Nicht „Entweder-oder“ sondern „Sowohl als auch!“.

(Ungeduldige finden die Bewertung nach der Erläuterung in Abschnitt 6 des zweiten Teils dieses Artikels.)

Erläutern möchte ich entsprechend:

1. Ziele und technische Zusammenhänge  

1.1 Ziele der digitalen Vernetzung im Gesundheitswesen 
1.2 Bedarf an sicheren Identitäten und Kryptografie 
1.3 Verwendung von Kartenterminals und Krypto-Software
1.4 Nicht ohne öffentliche Zertifikate und Vertrauensdiensteanbieter
1.5 Anforderungen an die sichere Vernetzung
1.6 Betriebsführung und Betriebsstabilität
1.7 Sicherheitskritische Anwendungsanteile
1.8 Zusammenfassung der Bedarfe  

2. Konnektor – das „Schweizer Taschenmesser“ der TI
3. Kosten des Konnektors und der Smartcards
4. Nutzungs- und Einsatzszenarien der TI und ihrer Anwendungen
5. Gesetzesinitiative DVPMG
6. Auswirkungen auf den Konnektor, die Karten und den ganzen Rest
7. Und nun?

1. Ziele und technische Zusammenhänge

1.2 Bedarf an sicheren digitalen Identitäten, Kryptografie und sicheren Schlüsselspeichern

Um aus einem digitalen Informationsaustausch einen sicheren digitalen Informationsaustausch zu machen, benötigt man kryptografische Verfahren, die   

Hierfür erhalten die Personen bzw. die Institutionen digitale Identitäten.

Das Mittel der Wahl für diese drei kryptografischen Verfahren sind asynchrone Kryptoverfahren. Die Person / die Institution hält einen privaten Schlüssel, zu dem ein passender öffentlicher Schlüssel existiert. Klassischer Weise wird zu dem öffentlichen Schlüssel durch eine vertrauenswürdige Stelle ein Zertifikat ausgegeben, in welchem bestätigt wird, dass der Inhaber des privaten Schlüssels zu dem im Zertifikat enthaltenen öffentlichen Schlüssel auch tatsächlich die Person / die Institution ist, die sie behauptet zu sein und dass die behaupte Rolle dieser Person / Institution innerhalb der Gesundheitsversorgung (Versicherter, Krankenkasse, Arzt, Zahnarzt, Apotheker etc.) tatsächlich stimmt (mehr dazu später). Der private Schlüssel muss dabei ganz besonders geschützt werden, denn jeder, der diesen privaten Schlüssel nutzen kann, kann sich erfolgreich für die Person / Institution ausgeben, welcher der Schlüssel eigentlich gehört. Entsprechend muss durch technische und organisatorische Maßnahmen sichergestellt werden, dass diesen Schlüssel tatsächlich nur sein Besitzer nutzen kann.

Dies führt dazu, dass diese Schlüssel idealerweise in einem gesonderten Hardwarespeicher gehalten werden, in dem die Schlüssel auch direkt verwendet werden, statt sie rein in Software zu speichern oder für die kryptografischen Verfahren in einen PC oder Server zu übertragen. Zusätzlich wird die Verwendung der Schlüssel in diesem Hardewarespeicher durch Biometrie oder Kenntnis eines Geheimnisses (PIN) geschützt.

Die verbreitetsten Formen solcher sicheren Schlüsselspeicher mit Kryptofunktionen sind:

1. HSMs – High Security Modules, die es als PC-Steckkarte sowie als eigenständige netzwerkgebundene Geräte gibt. Diese Module sind sehr leistungsstark und daher teuer (vierstelliger Euro-Betrag). Sie finden entsprechend in Rechenzentren Einsatz.
   
   
2. Smartcards – besitzen die gleichen Funktionen wie HSMs, sind aber auf gelegentlichen Einsatz ausgerichtet und sehr günstig (einstelliger Euro-Betrag). Sie finden als SIM-Karte in Handys, als neuer Personalausweis (nPA), als Kreditkarte oder eben als Versichertenkarte (eGK), Heilberufsausweis (HBA) und Institutionskarte (SMC-B) ihren Einsatz.
   
   
3. SEs – Secure Elements in Smartphones, vergleichbar mit Smartcards. Tatsächlich basieren SEs der Smartphones teilweise auf der gleichen Technik wie Smartcards, nur dass diese in die Smartphones fest verbaut sind. Smartphones werden zunehmend mit SEs ausgestattet. Diese finden z.B. als eSIM ihren Einsatz, aber auch andere digitale Identitäten können – wie auf einer Smartcard – auf diese SE gespeichert und dort genutzt werden. Die SE selbst sind wie Smartcards vergleichsweise günstig (einstelliger Euro-Betrag), stecken aber natürlich in Smartphones (drei- bis vierstelliger Euro-Betrag).
   
   
4. Krypto-USB-Sticks, meist eine Kombination aus USB-Speichermodulen sowie Smartcard-Technik in einem Stick verbaut. Die Kryptoverfahren des Smartcardanteils schützen dabei den Speicher des Sticks und ermöglichen ferner die obigen identitätsbezogenen Kryptooperationen (zwei- bis dreistelliger Euro-Betrag).

Am komfortabelsten für gelegentliche interaktive Nutzungsszenarien sind sicher Smartphonelösungen mit integriertem SE. Diese setzen aber entsprechend voraus, dass die Person, die eine digitale Identität nutzen muss, über ein entsprechendes Smartphone verfügt und es dafür auch nutzen möchte. Ferner verlangt die Nutzung dieser SE-Lösung, dass der Anwender mit seinem Smartphone interagiert, d.h. er muss es in der Hand halten und entsperren, ansonsten könnte jeder, der im ergaunerten Besitz des fremden Smartphones ist, sich in der digitalen Welt als dessen Eigentümer ausgeben.

Für das deutsche Gesundheitswesen wird ferner eine Lösung benötigt, bei der alle Versicherten (also 80 Millionen Menschen), alle an der Versorgung beteiligten Personen sowie alle an der Versorgung beteiligte Einrichtung mit digitalen Identitäten ausgestattet werden müssen (weitere Millionen Identitäten), da ansonsten die Grundvoraussetzungen für einen sicheren digitalen Informationsaustausch (zwischen authentisierten Personen und Institutionen) nicht gegeben wären.

Es ist davon auszugehen, dass nicht wirklich jeder Versicherte über ein Smartphone (mit SE!) verfügen wird oder ein Smartphone hierfür verwenden will oder kann (denken wir alleine an die vielen Menschen, die Betreuung benötigen). Entsprechend muss zumindest für eine unbestimmte Anzahl der restlichen Personen ein anderer Schlüsselspeicher angeboten werden. Auf Kostenseite ist hier die Smartcard unschlagbar. Daher ist sie auch für EC-Karten und SIM-Karten für das Telefon so weit verbreitet und daher ist auch weitgehend jeder an die Bedienung und Nutzung solcher Karten gewöhnt (Karte stecken und PIN eingeben). Es muss also zwingend eine Kartenherausgabe für Versicherte etabliert werden. Hierfür könnte auch der neue Personalausweis (nPA) als digitale Identität verwendet werden soll, den bereits viele Bürger haben – aber eben nicht alle. Für die krankenversicherten Personen, die keinen nPA haben bzw. keinen erhalten dürfen, sowie für diejenigen, die einen nPA mit deaktivierter eID-Funktion haben, besteht entsprechend weiterhin der grundsätzliche Bedarf für eine eGK. Und für medizinische Einrichtungen könnte der nPA überhaupt nicht genutzt werden, da der nPA nur an Personen herausgegeben wird, nicht aber an Einrichtungen. Hinsichtlich der Smartphonelösung wird es ein Arzt im Arbeitsalltag sicher nicht zu schätzen wissen, wenn er für jeden Vorgang, bei dem er sich als Arzt ausweisen und als Arzt unterschreiben muss (z.B. zum Signieren der dutzenden Rezepte eines Tages), jedesmal sein Smartphone zücken muss.  

1.3 Verwendung von Kartenterminals und Krypto-Software

1.4 Nicht ohne öffentliche Bestätigung der Identität und Rolle durch einen Vertrauensdiensteanbieter

1.5 Anforderungen an die sichere Vernetzung

1.6 Betriebsführung und Betriebsstabilität

Krypto-Software sowie VPN und Firewall werden im Kern immer als Softwarelösungen umgesetzt. Werden sie auf einem PC oder Server betrieben, können diese Softwareteile von den Änderungen des Betriebssystems betroffen sein. Mit jedem Patch, mit jeder neuen Betriebssystemversion, mit jedem neuen Treiber, die auf den PC / den Server aufgespielt wird, muss die Software für Krypto, VPN und Firewall gegebenenfalls angepasst werden bzw. besteht die Gefahr, dass es zu Störungen kommt. Gleiches gilt für die weitere Software, die neben diesen Anteilen zusätzlich auf dem Server bzw. dem PC installiert ist und läuft. Auch diese weitere Software kann zu Störungen und / oder Beeinträchtigungen der Krypto-, VPN- und Firewall-Software führen. Jeder, der bereits einmal einen PC oder Server für längere Zeit als Admin betreut hat weiß, wovon ich spreche. Aus diesem Grund vollziehen die großen Softwarehäuser seit einigen Jahren den Wechsel von Software, die auf den PCs ihrer Kunden betrieben wird, hin zu zentral bereitgestellter Software – Software As A Service (SAAS). Die Grundidee dabei ist, dass Aufwände, Störungen und Kosten deutlich gesenkt werden können, wenn die Software nicht direkt auf den unterschiedlichsten PCs mit unterschiedlichsten Störfaktoren betrieben wird, sondern auf dem Anbieter bekannter Hardware und Betriebssystem unter der Kontrolle der Anbieter (hier zentrale Server). Dem Anwender wird nur eine Interaktionsmöglichkeit geboten, zumeist über Browser. Dies wird selbst bei so umfangreichen und komplexen Anwendungspaketen wie Microsoft Office forciert.

Für sicherheitskritische Software, die im Fall von VPN und FW insbesondere das lokale Netz gegenüber fremden Netzen absichern soll, ist der Betrieb dieser Software auf zentralen Servern natürlich nur begrenzt sinnvoll. Die Vorteile aber, die sich durch den Betrieb der Software auf einer durch den Hersteller entwickelten und bereitgestellten „Box“ ergeben, sind denen von SAAS-Lösungen allerdings sehr ähnlich. Unter anderem aus diesem Grund haben sich DSL-Modem- & Router-Lösungen in einer Box (z.B. als AVM Fritz-Box) gegenüber Softwarelösungen auf PCs (mit eingebauten Modemkarten) durchgesetzt.

Daher ist es zeitgemäß und sinnvoll für sicherheitskritische Software, die keinerlei Interaktion mit anderen Programmen oder dem Anwender benötigt, diese auf eigenständiger Hardware zu betreiben. Meist reichen hierfür „kleine Boxen“ aus, die im Vergleich zu heutigen PCs eine vergleichsweise geringe Leistungsfähigkeit haben, für den Einsatzzweck aber mehr als ausreichend sind. Auch können diese Boxen leichter für eine Remote-Administration geöffnet werden, da auf diesen Boxen im Vergleich zu den Servern und PCs i.d.R. keine personenbezogenen Daten gespeichert werden. Daher sind die VPN+FW-Standardlösungen für kleine Einrichtungen entsprechend üblicher Weise auch immer eigenständige VPN+FW-Boxen, z.b. von den Herstellern Genua, Juniper, Cisco, Sophos und vielen weiteren.

Nun könnte man dagegenhalten, ob ein geschlossenes Netz wie die TI oder das SNK überhaupt noch zeitgemäß ist oder ob die verschiedenen Server für Infrastrukturdienste und Anwendungen nicht auch – speziell gesichert – direkt im Internet betrieben werden können. Ein Zugriff eines PCs oder Smartphone auf eine solche Anwendung wäre ja ohnehin immer über einen TLS-Kanal gesichert. Diese Frage ist berechtigt und sollte für die TI auch tatsächlich diskutiert werden. Aber auch wenn die Anwendungen und Dienste der TI zukünftig direkt im Internet betrieben würden, müsste der Internetzugang einer Einrichtung immer noch mittels Firewall gegen das Internet geschützt werden. Der Bedarf für eine FW-Box bleibt daher auch in diesem Fall erhalten.  

1.7 Sicherheitskritische Anwendungsanteile

Für einige Anwendungen der TI, insbesondere für die elektronische Patientenakte (ePA), existieren eine Reihe von Funktionen, die für das interoperable und insbesondere sichere Funktionieren der Anwendungen unerlässlich sind. Für die ePA ist beispielsweise das gesamte lokale Session- und Anwendungsschlüsselmanagement für die Sicherheit der ePA von großer Bedeutung. Wo diese Softwareanteile betrieben werden, ist wie bei VPN und Firewall letztendlich egal. Nur korrekt und sicher implementiert sowie sicher betrieben müssen sie werden. Im Falle des heutigen Konnektors werden diese Anwendungsanteile als sogenannte Fachmodule direkt auf dem Konnektor betrieben. Sie könnten natürlich auch als bereitgestellte Softwaremodule auf den PCs der Primärsysteme betrieben oder direkt in die Primärsysteme integriert werden. In diesem Fall müssten alle Primärsysteme (>300) um diese sicherheitskritischen Funktionen erweitert werden. Generell gelten auch für diese Anwendungsanteile die gleichen Herausforderungen der zuvor beschriebenen Betriebsstabilität. Im Unterschied zu VPN und Firewall könnten diese sicherheitskritischen Anwendungsanteile aber auch in zentrale Dienste innerhalb der TI ausgelagert werden und müssten nicht zwingend im lokalen Netz der Einrichtung betrieben werden.  

1.8 Zusammenfassung der Bedarfe

Um eine sichere digitale Vernetzung und Kommunikation im Gesundheitswesen aufbauen zu können, benötigt man in Summe also:

1. Digitale Identitäten sowohl für Personen und Einrichtungen als auch für deren Rollen; diese bestehen aus