2. Konnektor – das „Schweizer Taschenmesser“ der TI

Der Konnektor umfasst heute nahezu alle sicherheitskritischen Funktionen, die innerhalb eines lokalen Netzwerks einer Einrichtung in Bezug auf die TI anfallen. Entsprechend der zuvor als Bedarfe aufgeführten Punkte sind dies:  

Dabei besitzt der Konnektor selbst eine eigene Smartcard, die ihn mit zugehörigen Zertifikaten als geprüften Konnektor der TI ausweist. Nur über diese Zertifikate, und in Verbindung mit einer SMC-B einer Einrichtung, erhält er gegenüber der TI Einlass. Wie alle Zertifikate haben auch die Zertifikate des Konnektors eine Laufzeit von 5 Jahren.

3. Kosten des Konnektors sowie Entwicklungsdauer

Wie beschrieben, werden die verschiedenen Standard- und Spezial-Funktionen des Konnektors – wie VPN, FW, Krypto-Software und Anwendungsanteile – als Software implementiert, die aus technischer Sicht auf einem PC oder einer PC-ähnlichen Box, dem Konnektor, betrieben werden kann. Die reinen Hardwarekosten für die „Boxen“ der heutigen Konnektoren liegen in der Region von 200-400 €.
Warum sind die heutigen Konnektoren mit Preisen von 1.200-1.500 € dann so teuer?
Und warum dauert es 10-18 Monate, bis eine neue Konnektor-Version zur Verfügung steht?

Die Antwort lautet: Weil ein Großteil der Kosten sowie der Zeit bis zur Bereitstellung auf die vorgeschriebene Sicherheitszertifizierung der Konnektor-Software nach Common Criteria (CC) zuzüglich der für die Zulassung vorgeschriebenen Feldtests, entfällt. Würde ein Konnektor mit den gleichen heutigen Anforderungen an Sicherheitsnachweise und Feldtests nicht auf den bekannten Konnektor-Boxen, sondern als reine Softwarelösung auf einem PC oder Server betrieben, würde sich die Bereitstellungsdauer von dem Zeitpunkt der Veröffentlichung neuer gematik-Vorgaben bis zur Auslieferung neuer (Software)Konnektoren nicht verkürzen. Ob durch den reinen Verzicht auf eigene Hardware die Kosten für Konnektoren am Ende überhaupt gesenkt werden könnten, erscheint fraglich, denn statt eine Konnektorsoftware auf eine einzige, dem Hersteller wohlbekannte und unter seiner Kontrolle stehende Ausführungsumgebung auszurichten, müsste eine reine Softwarelösung mit den unterschiedlichsten Betriebssystemen/-versionen sowie Treiber- und Programmkombinationen im Feld zurechtkommen. Entsprechend wäre die Entwicklung und Härtung der Konnektorsoftware aufwändiger, was in Folge die Kosten für die Softwarelösung steigern würde.

Ganz unabhängig davon schwebt über einer reinen Softwarelösung noch das Risiko, dass im Rahmen der Aushandlung der Finanzierungsvereinbarung den Praxen dann auch noch die PCs bzw. Server auf denen der Softwarekonnektor dann laufen soll, durch Versichertengelder – zumindest anteilig – finanziert werden müssten. Denn gemäß gesetzlicher Regelung müssen den Einrichtungen die Kosten für eine TI-Anbindung erstattet werden und in einem solchen Fall würde die Vertretungsseite der Ärzteschaft sicherlich argumentieren, dass für einen Softwarekonnektor nicht unterstellt werden darf, dass die für diesen nötige PC-Ausstattung bereits vorhanden ist… Eine solche Finanzierung würde am Ende sogar deutlich teurer als die eigentliche Konnektor-Box werden … 

Für eine echte Kostensenkung und Beschleunigung der Bereitstellung neuer Konnektorversionen liefert entsprechend ein reiner Wechsel von Hardware- auf Softwarelösungen keine Verbesserung. Vielmehr müsste entschieden werden, ob die hohen Sicherheitsanforderungen nicht an einzelnen Stellen gesenkt bzw. der Nachweis der Sicherheit nicht auf effizienterem Wege als durch eine CC-Zertifizierung erbracht werden kann. Auch die Durchführung eines Feldtests, der für sich allein bereits zwei bis vier Monate Durchführungsdauer beansprucht und nach heutiger Festlegung erst als einzelner Schritt nach Abschluss aller vorherigen Prüfungen durchgeführt werden darf, könnte zur Beschleunigung überdacht werden. 

Ferner vergeht viel Zeit durch die gesetzlich vorgeschriebene Trennung und Reihenfolge von

1. schriftlicher Festlegung der Vorgaben durch die gematik und der
2. anschließenden Implementierung dieser Vorgaben durch unabhängige Hersteller, welche
3. anschließend durch die gematik und Prüfstellen auf Einhaltung der gematik-Vorgaben geprüft werden,  
   

bevor eine neue Konnektor-Version im Feld getestet und erst anschließend bei der medizinischen Einrichtung ankommen darf. Würde statt des marktoffenen Verfahrens direkt eine einzige Konnektor-Version durch die gematik verantwortet und herausgegeben werden (wie dies beispielsweise in Österreich der Fall ist), würde reichlich Zeit gespart und die Komplexität in der Interoperabilitätstestung reduziert werden. Dies würde sich vermutlich auch positiv auf die Kostenseite auswirken.

Hinsichtlich der strengen Sicherheitsvorgaben ist noch anzumerken, dass ausschließlich diese es sind die dazu führen, dass die Konnektorsoftware die für die Konnektor-Boxen entwickelt wird, nicht auch zusätzlich auf Servern z.B. in Rechenzentren von Krankenhäusern betrieben werden können und dürfen. Seitens der Vorgaben der gematik und der Implementierung der wesentlichen Konnektor-Software spricht hier eigentlich nichts dagegen. Entsprechend könnte durch eine Korrektur der BSI-seitigen Sicherheitsvorgaben eine leichte Skalierung der Leistungsfähigkeit der bestehenden Konnektor-Implementierungen erreicht werden: Krankenhäuser könnten so die Konnektor-Software auf gesicherten Servern ihrer Rechenzentren ausführen, statt sich – wie heute üblich – mit dutzenden Konnektor-Boxen ausstattet zu müssen; mit allen administrativen und organisatorischen Nachteilen, die sich aus multiplen Konnektor-Instanzen innerhalb einer Einrichtung ergeben.

4. Nutzungs- und Einsatzszenarien der TI und ihrer Anwendungen

Will man die heutige Situation um Konnektor und Smartcards bewerten und überlegen, wie die obigen Aspekte auch anders umgesetzt werden könnten, muss man auch die unterschiedlichen Nutzungs- und Einsatzszenarien im Blick behalten. Diese sind:  

1. Kleinere oder größere Einrichtung, deren Mitarbeiter innerhalb der Einrichtung Patienten versorgen und dazu auch Geräte und Software des lokalen Netzes nutzen (vorrangig PCs, teilweise Tablets). In diesem Szenario besteht der Bedarf, potenziell auf alle Anwendungen der TI zugreifen zu können – also neben KIM, ePA, eRezept & Co auch auf die „dritten“ Anwendungen der TI (beliebige Anbieter und weitere gesetzliche Anwendungen wie das Implantate- oder Organspenderegister) sowie auf Anwendungen in an die TI angeschlossenen Netzen, wie z.B. auf Anwendungen der KBV im „Sicheren Netz der KVen“ (SNK).
   
   
2. Ein-Personen-Einrichtungen, insbesondere im Bereich der Psychotherapie, die nur einen geringen Bedarf für einen Zugriff auf Anwendungen der TI haben. Oft nur mit einem Notebook ausgestattet, werden die medizinischen Leistungen meist in den Räumen der Einrichtung erbracht.
   
   
3. Mobile Szenarien der medizinischen Versorgung, z.B. ein Arzt bei einem Haus- oder Heimbesuch, Pfleger in der häuslichen Pflege oder auch Hebammen in der häuslichen Versorgung. Hier besteht der Bedarf des punktuellen Zugriffs einer einzelnen Person sowohl auf Daten des eigenen IT-Systems (auf dortige Patienten- und Prozessdaten) als auch auf Anwendungen der TI (insbesondere eRezepte, ePA und später Messaging).
   
   
4. Versicherte, die wahlweise per Smartphone / Tablet oder eigenem PC auf ihre Daten innerhalb der TI zugreifen und mit den Einrichtungen interagieren wollen (insbesondere eRezept, ePA und später Messaging, eMail und Videotelefonie)  
   

Bislang war die TI-Anbindung über den Konnektor praktisch ausschließlich auf Szenario 1 ausgelegt. Szenario 2 kann hierüber ebenfalls betrieben werden, erscheint manchem aber im Aufwand als übertrieben. An Lösungen für den mobilen Zugriff in Szenario 3 wird seit Jahren gearbeitet, hier stehen bislang keine Angebote zur Verfügung und der heutige Konnektor – auf den stationären Betrieb ausgerichtet – ist hierfür natürlich gänzlich ungeeignet. Für die Zugriffe der Versicherten in Szenario 4 werden den Versicherten keine Zugänge zur TI insgesamt gewährt. Vielmehr sind einzelne Anwendung über das Internet erreichbar (abgesichert über Anwendungs-Zugangsgateways). Dort wird dann lediglich der Zugriff auf festgelegte Operationen der jeweiligen Anwendung zulassen. Kommt eine neue Anwendung hinzu, muss für diese Anwendung auch ein neues Zugangsgateway angeboten werden.

Wie weiter oben bereits ausgeführt, könnten grundsätzlich alle Anwendungen und Dienste – bei Abkehr von einer geschlossenen TI – direkt im Internet betrieben werden. In diesem Fall wären alle Anwendungen in allen Szenarien ohne eine VPN-Anbindung erreichbar. Die bestehenden Sicherheitsmaßnahmen für die Dienste und Anwendungen der TI müssten in diesem Fall auf das neue Bedrohungspotential „Betrieb im Internet“ angepasst werden.  

5.  Gesetzesinitiative DVPMG

Der Aufbau der TI war schon immer als Stufenplan konzipiert. Schrittweise sollten weitere Anwendungen aufgenommen und weitere Berufsgruppen angeschlossen werden. Hinsichtlich der Anbindung an die TI wird gemäß Referentenentwurf Digitale Versorgung und Pflege - Modernisierungs-Gesetz (DVPMG) § 312 Abs. 1 Nummer 9 SGB V die gematik beauftragt, 

„bis zum  30. Juni 2022 die Maßnahmen durchzuführen, die erforderlich sind, damit Anbieter ab dem 1. Januar 2023 Komponenten und Dienste zur Verfügung stellen können, die eine sichere, wirtschaftliche, skalierbare, stationäre und mobile Zugangsmöglichkeit zur Telematikinfrastruktur ermöglichen“.

Ferner regeln im Referentenentwurf eine Reihe neuer gesetzlicher Festlegungen die Ausgabe sogenannter „digitaler Identitäten“, die auf Wunsch der jeweiligen Person anfangs zusätzlich zu eGK, HBA und SMC-B und später auf Wunsch der Person sogar vollständig anstelle der jeweiligen Smartcards ausgegeben werden sollen. Näheres hierzu regelt der Gesetzesentwurf bislang nicht.  

6. Auswirkungen auf den Konnektor, die Karten und den ganzen Rest

Betrachtet man die gesetzlichen Forderungen und stellt sie zu den oben dargestellten inhaltlichen Aspekten bezüglich Netzkopplung, Sicherheit und Betriebsstabilität sowie der Kosten und Einsatzszenarien in Relation, dann kommt man zu folgenden Schlüssen:  

• Es wird immer Versicherte geben, die kein Smartphone und keinen nPA nutzen können oder wollen, ergo werden diese Personen weiterhin ihre digitale Identität auf einem „Hardwaretoken“ erhalten müssen – Smartcards sind hier der Goldstandard für Sicherheit bei gleichzeitig günstigem Preis.
  
  
• Da weiterhin dauerhaft Smartcards im Einsatz bleiben werden (wenn auch bei Versicherten vermutlich in abnehmendem Umfang), werden auch dauerhaft Kartenleser benötigt, über die diese Karten gelesen werden können. Dies natürlich auch kontaktlos per NFC, sodass auch Smartphones mit digitalen Identitäten über deren NFC-Schnittstelle mit den Kartenlesern interagieren können.
  
  
• Heilberufler und deren Mitarbeiter, die hauptsächlich im stationären Einsatz arbeiten, werden im Rahmen ihrer täglichen Arbeit nicht ständig ihr Smartphone ziehen wollen, um sich damit an einem Kartenleser gegenüber der TI zu authentisieren oder digitale Unterschriften zu leisten. Reine Softwarelösungen kommen für digitale Identitäten aus Sicherheitsgründen nicht in Frage. Entsprechend sind hier dauerhaft sicher gesteckte HBAs und SMC-Bs von Vorteil, insbesondere, wenn viele qualifizierte elektronische Signaturen (QES) für eRezepte und eAUs vom Arzt ausgestellt werden müssen und hierfür die Komfortsignatur verwendet werden kann – was einen dauerhaft gesteckten HBA voraussetzt.
  
  
• Stationären Einrichtungen werden immer aus ihrem lokalen Netzwerk heraus über das Internet auf Anwendungen der TI zugreifen. Entsprechend wird weiterhin eine Firewall-Absicherung der lokalen Einrichtungsnetze gegenüber dem Internet benötigt. Wird die TI unverändert als geschlossenes Netz betrieben, kann auch auf den VPN-Client nicht verzichtet werden.

Die sichere digitale Vernetzung und Kommunikation im Gesundheitswesen wird entsprechend nicht ohne digitale Identitäten und Rollenauthentisierung auskommen. Für die Ausgabe und Nutzung dieser Identitäten sowie für die sichere Vernetzung sind Grundfunktionen nötig, die sich voraussichtlich in den nächsten (mindestens) 10 Jahren hinsichtlich der technischen Basis nicht ändern werden.

Bislang ist nicht absehbar, dass das digitale Gesundheitswesen gänzlich ohne Smartcards auskommen wird. Wahrscheinlicher ist, dass aus Komfortgründen verstärkt Smartphones mit von den Smartcards abgeleiteten digitalen Identitäten zusätzlich zum Einsatz kommen werden (wie beispielsweise in Estland oder im Kreditkartenbereich bereits praktiziert), dennoch aber auch teilweise Personen weiterhin ausschließlich Smartcards verwenden werden.

Damit können auch Kartenterminals nicht abgeschafft werden, da es immer Versichertenkarten (und vermutlich Institutionskarten) geben wird und diese verwaltet werden müssen. Die Software für die (kartenbasierten) Krypto-Operationen muss ebenso irgendwo sicher verortet werden, wie die sicherheitskritischen Anteile der TI-Anwendungen. Standalone „Boxen“ haben als Betriebsplattform für solch sicherheitskritische Software deutliche Vorteile gegenüber reinen Softwarelösungen, die auf PCs oder Servern der Einrichtung betrieben werden. Auch wenn Teile der heutigen Konnektorsoftware auf lokale PCs oder Server sowie optional auf zentrale TI-Server ausgelagert werden (Konnektordienste), bleibt der Bedarf sowie die Sinnhaftigkeit eines Konnektors als „Combi-Box“ der TI für alle lokal in einer Einrichtung notwendigen TI-Sicherheitssoftware auch in Zukunft bestehen.

Der Konnektor hält 10 Jahre und länger 
Die bereits ausgerollten und in Ausrollung befindlichen Konnektoren gehen nicht nach 5 Jahren „kaputt“. Der Konnektor als Gerät funktioniert weiterhin, es laufen lediglich die Zertifikate der Konnektoren ab, die dem Konnektor den Zugang zur TI ermöglichen. Dieser Umstand wurde im Rahmen der Konzeption und Spezifikation des Konnektors bereits berücksichtigt: Der Schlüsselspeicher im Konnektor hat Platz für weitere, neue Schlüssel und Zertifikate. Wird im zentralen Bereich entsprechend ein System zur Online-Zertifikatsausgabe für Konnektoren aufgebaut, können alle im Feld befindlichen Konnektoren mit neuen Zertifikaten ausgestattet werden, die jedem Konnektor dann erneut 5 Jahre Laufzeit bescheren. Mit dem Aufbau dieses Schlüssel- und Zertifikatsdeployments sollte aber zügig begonnen werden, damit dieser Mechanismus vor dem Ablauf des ersten Konnektor-Zertifikats zur Verfügung steht. Selbst über die neuerlichen 5 Jahre hinaus könnten weitere Schlüssel und Zertifikate nachgeladen werden, wenn diese anschließend in der Software des Hardwarebox-Konnektors gespeichert würden.