Bericht der Arbeitsgruppe der Gesellschafterversammlung zur vorgezogenen Lösung für die Telematikinfrastruktur und einen stufenweisen Ausbau

Transkript

1 Bericht der Arbeitsgruppe der Gesellschafterversammlung zur vorgezogenen Lösung für die Telematikinfrastruktur und einen stufenweisen Ausbau Vorsitz: Klaus Theo Schröder Mitglieder: Dirk Schladweiler Sven Tschoepe Gerd Bauer Jürgen Völlink Rainer Höfer Christian Ummerle Kerstin Tenbrock Irmgard Düster BÄK BZÄK DAV DKG GKV-SV GKV-SV KBV KZBV

2 1. Auftrag Die 36. Gesellschafterversammlung der gematik hat am den Auftrag erteilt, die Arbeit der Arbeitsgruppe (AG) fortzusetzen. Die AG wurde zur Prüfung einer vorgezogenen Lösung für die Telematikinfrastruktur und der Konkretisierung eines Stufenkonzeptes beauftragt und befasste sich in diesem Zusammenhang insbesondere mit den Fragen: - effektive Governance, - Fortentwicklung der laufenden Projekte, - Teilnahmewettbewerb und Ausschreibebedingungen, - Einführung einer qualifizierten elektronischen Signatur (QES). Die AG wurde gebeten, bis Ende November einen Bericht vorzulegen der eine Entscheidungsgrundlage für einen gemeinsamen Beschluss aller Gesellschafter auf der 37. GSV, am , darstellen sollte. Vertraulich Seite 2 von

3 2. Vorgehensweise Der Vorsitzende der AG hat ein Gutachten bei der EMDS AG, Stuttgart, in Auftrag gegeben das die Modalitäten und einen realistischen Zeitplan für die zeitnahe Implementierung der QES in das System möglichst in der 1. Stufe des Online- Rollouts geprüft hat. Der Schwerpunkt des Gutachtens lag auf der Fragestellung, unter welchen technischen, zeitlichen und projektbezogenen Rahmenbedingungen eine QES in die Lösung sinnvoll implementiert werden kann, ohne die angestrebte Reduzierung der Komplexität zu gefährden. Weiterhin wurde vom BMG, basierend auf dem Projektvorschlag Alternative 2012 (Stand August 2011) gemeinsam mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) und den Konnektorherstellern, ein Dokument verfasst, das sich mit der Erweiterung einer vorgezogenen Lösung um medizinische Anwendungen, die eine QES benötigen, befasst. Die AG selbst hat in der Zeit vom 28. Oktober 2011 bis zum 22. November 2011 insgesamt fünf Sitzungen durchgeführt. Die AG konstituierte sich am und führte gemäß des Auftrags aus der 36. GSV ihre Arbeit am 28. Oktober 2011 fort. Nach wie vor wurden dem GKV- Spitzenverband zwei Sitze in der AG zugestanden. Die übrigen Gesellschafter waren jeweils mit einem Teilnehmer vertreten. Am 22. November 2011 hat die EMDS AG, Stuttgart, die wesentlichen Ergebnisse des von ihnen kurzfristig erstellten Gutachtens vorgestellt, das ausführlich besprochen wurde. Außerdem wurde Herr Bonerz eingeladen, um das Validierungsergebnis Szenario 3 vorzustellen. Aus gesundheitlichen Gründen wurde Herr Bonerz von Herrn Bartkowiak vertreten. Am hat die AG auch ihren Bericht abgestimmt und mit einem einvernehmlichen Ergebnis abgeschlossen. Vertraulich Seite 3 von

4 3. Zusammenfassung der Ergebnisse 3.1 Voraussetzungen Alle Gesellschafter unterstreichen noch einmal ihre Bereitschaft zur Beschleunigung der Arbeiten zur elektronischen Gesundheitskarte, der Telematikinfrastruktur und ihrer Anwendungen aktiv beizutragen. 3.2 Ergebnisse Auf der Grundlage der Beschreibung der vorgezogenen Lösung für die Telematikinfrastruktur als 1. Stufe des Online-Rollouts kann nach Auffassung der AG ein stufenweiser Ausbau der Anwendungen der elektronischen Gesundheitskarte und einer entsprechenden Infrastruktur erfolgen, wenn die entsprechenden Voraussetzungen geschaffen werden, wie sie in den Anlagen 1 bis 5 durch die AG erarbeitet worden sind. Die 1. Stufe umfasst die beiden Teile VSDM mit korrespondierender Infrastruktur und QES. Die 1. Stufe wird in einem Verfahren ausgeschrieben und kann ggf. in 2 Phasen realisiert, getestet und für den Wirkbetrieb freigegeben werden. Dabei geht die AG davon aus, dass nach begründeten Aussagen z. B. der EMDS die 2. Phase QES ca. 10 Monate nach der 1. Phase realisiert werden kann. Mit der Umsetzung des Konzeptes sollte umgehend begonnen werden. Vertraulich Seite 4 von

5 Beschreibung der vorgezogenen Lösung für die Telematikinfrastruktur als 1. Stufe des Online- Rollouts Vorliegende Fassung: Stand November 2011

6 Inhaltsverzeichnis Zusammenfassung Leistungsumfang der vorgezogenen Lösung Kurzbeschreibung der vorgezogenen Lösung Anwendungsüberblick VSDM Technische Infrastruktur Erweiterbarkeit und Ausblick Leistungsumfang in den Testvorhaben Allgemeine Rahmenbedingungen Eckpunkte der regionalen Tests Auswahl der Testregionen Testziele Dauer der Tests Evaluation der Tests Leistungsumfang und Losaufteilung in den Tests Ausblick Bewertung der vorgezogenen Lösung aus der Perspektive der Datensicherheit und des Datenschutzes Datensicherheit Datenschutz Beschaffung Glossar November 2011 Seite 2

7 Zusammenfassung Das nachfolgende Dokument beschreibt die Kernpunkte des Konzeptpapiers zur vorgezogenen Lösung (Alternative 2012) des GKV-Spitzenverbandes. Um eine Beschlussfassung zu diesem Thema zu ermöglichen, wurde das Dokument wie folgt geändert: Entfernung der nachfolgenden Kapitel: o 1 Ausgangslage und Zielsetzung o 2 Unterstützung der Alternative 2012 durch das BMG o 6 Kosten der vorgezogenen Lösung o 7 Motivation der Leistungserbringer o 9 Umsetzungsorganisation o 10 Gesamtplanung Der Begriff Alternative 2012 wurde durchgängig durch vorgezogene Lösung ersetzt Die Kapitelreferenzen wurden angepasst Aussagen (Ausblick) zum bundesweiten Ausschreibungsverfahren und Rollout sowie zum Zeitplan wurden gestrichen Der Begriff Mini-Anwendungskonnektor wurde durch den Begriff Anwendungskonnektor light ersetzt. Dies entspricht dem Funktionsumfang der Phase 1 der Stufe1 gemäß Ergebnis der Arbeitsgruppe Mit diesem Anpassungen gibt das Dokument die Grundidee als Entscheidungsbasis wieder. Das Dokument kann aber nur gemeinsam mit weiteren Dokumenten / Aussagen als Beschlussvorlage für die Umsetzung dienen. Hierfür sind die folgenden Themen zu behandeln: Umsetzungsorganisation / Governance Stufenkonzept für die Einführung der Anwendungen unter Berücksichtigung der heutigen gematik-projekte Anforderungen an die Ausschreibung(en) Überarbeitung der Testteilnehmer / Anzahl der am Test teilnehmenden Primärsysteme Übergang vom Test- in den Wirkbetrieb Zeitplan gem. externer Gutachten (EMDS) November 2011 Seite 3

8 1 Leistungsumfang der vorgezogenen Lösung 1.1 Kurzbeschreibung der vorgezogenen Lösung Die vorgezogene Lösung schafft eine sichere Vernetzung der beteiligten Akteure über eine einheitliche Infrastruktur. Diese Infrastruktur ermöglicht die komplette fachliche Umsetzung des Versichertenstammdatenmanagements analog der Ziellösung 1. Darüber hinaus erlaubt die Infrastruktur die sichere Integration von Bestandsnetzen, wie z.b. KV-SafeNet mit sicherer Internetanbindung. Die vorgezogene Lösung ist prinzipiell fachlich erweiterbar, soweit die sicherheitstechnischen Eigenschaften für neue Anwendungen ausreichend sind. Grundlage für die Lösung ist der Basis-Rollout egk und die dort ins Feld gebrachten Komponenten. Im Rahmen des Basis-Rollouts ersetzt die egk die bisherige Krankenversichertenkarte und dient dem Nachweis der Berechtigung zur Inanspruchnahme von vertragsärztlichen oder -zahnärztlichen Leistungen ( 15 SGB V). Sie enthält Angaben zum Mitgliedschaftsverhältnis des Versicherten und ergänzende Angaben, die der Leistungserbringer zur Abrechnung der medizinischen Leistungen benötigt. Zum Auslesen der egk werden im Basis-Rollout die Kartenterminals (ehealth-bcs) direkt an die Primärsysteme der Leistungserbringer angeschlossen. Es wird dabei keine Online-Funktionalität bereitgestellt. Die technischen Möglichkeiten der egk können im Basis-Rollout noch nicht genutzt werden. Die vorgezogene Lösung ermöglicht eine frühzeitige Nutzung des vollen sicherheitstechnischen Funktionsumfangs der egk. Unter Verwendung der im Basis- Rollout bereitgestellten Komponenten erlaubt die vorgezogene Lösung die Verwendung der Online-Funktionen der Anwendung VSDM. Zur Verschlankung des Systems und zur schnellen und kompatiblen Einführung der vorgezogenen Lösung werden weitestgehend industrieerprobte Standards genutzt. Das Sicherheitsniveau der Lösung orientiert sich an den Erfordernissen der Anwendung VSDM. Aus diesem Grund können in der vorgezogenen Lösung anwendungsspezifische Anforderungen an die Verfügbarkeit der Prozesse und Technik und die Performance der Betriebsprozesse zu Grunde gelegt werden. Eine klare Zielsetzung des Vorhabens ist die Migrationsfähigkeit in die spätere Ziellösung. Um dies zu gewährleisten, setzt die vorgezogene Lösung auf eine frühzeitige Installation und Bereitstellung einer TI-konformen Leistungserbringer- 1 Unter Ziellösung ist die Stufe 1 der Projekte zur Neuausrichtung der TI gemeint November 2011 Seite 4

9 Infrastruktur. Damit entsteht eine homogene und planbare Ausgangssituation bei den Leistungserbringern, die eine schnellere Migration in die Ziellösung ermöglicht. Eine weitere Zielsetzung des Lösungsszenarios ist die Bereitstellung und Durchführung eines übergreifenden Supports mit größtmöglicher Ende-zu-Ende- Verantwortung Anwendungsüberblick VSDM Die an der vertragsärztlichen Versorgung teilnehmenden Ärzte, Einrichtungen und Zahnärzte sind gesetzlich verpflichtet ( 291 Abs. 2b SGB V), die vorgelegte egk bei jeder erstmaligen Inanspruchnahme von Leistungen im Quartal auf Gültigkeit und Aktualität der Versichertendaten (online) zu prüfen. Die Onlineprüfung umfasst folgende drei Schritte: 1. Prüfung der Gültigkeit der egk (Prüfung Authentifizierungs-Zertifikat) 2. Prüfung der Aktualität der Daten auf der egk 3. Aktualisieren der Daten auf der egk, sofern neuere Daten durch den Kostenträger bereitstehen Sofern der Versuch zur Onlineprüfung fehlschlägt, muss dieser entsprechend der Zielsetzung des oben genannten Gesetzes wiederholt werden, sobald der Versicherte ein weiteres Mal in die Praxis des Leistungserbringers kommt. Der Nachweis der durchgeführten Prüfung muss auf der egk gespeichert werden (Prüfungsnachweis). Das gilt auch für den Fall, dass die Onlineprüfung nicht komplett und erfolgreich durchgeführt werden konnte. Das Praxisverwaltungssystem (PVS) muss neben den Daten des Versicherten auch den Prüfungsnachweis übernehmen und verarbeiten, um diesen später den Abrechnungsdaten nach 295 SGB V hinzufügen zu können. Dabei ist sicherzustellen, dass auch nur der Leistungserbringer, der den Prüfungsnachweis erstellt hat, diesen zur Weiterverarbeitung verwenden kann. Der Prüfungsnachweis kann zusätzlich zur Speicherung auf der egk auch direkt dem PVS bereitgestellt werden. Die vorgezogene Lösung ermöglicht die Überprüfung des Status des Authentifizierungszertifikats der egk. Da die alleinige Sperrung des Authentifizierungs- Zertifikats keinen missbräuchlichen Einsatz der egk in einem Offline-Szenario verhindern kann, kann zusätzlich eine Sperrung der Gesundheitsanwendung auf der egk erfolgen. Die Sperrung und Entsperrung der Gesundheitsanwendung auf der egk erfolgt über den Fachdienst CMS. Krankenhäuser benötigen im stationären Bereich die Versichertenstammdaten für die elektronische Datenübertragung an die Krankenkassen nach 301 SGB V. Im Gegensatz zum vertragsärztlichen Versorgungsbereich besteht für den stationären Be- November 2011 Seite 5

10 reich keine gesetzliche Verpflichtung zur Onlineprüfung der Versichertenstammdaten auf der egk. Die Krankenhäuser können aber ebenfalls die Dienste der Krankenkassen zur Onlineprüfung nutzen. Der gesetzlichen Forderung, die Onlineprüfung durch Fachdienste der Kostenträger auch dann durchführen zu können, wenn das PVS nicht an das Netz der Telematikinfrastruktur angebunden ist, wird durch die Umsetzung eines sogenannten Standalone-Szenarios Rechnung getragen. Das Standalone-Szenario ist für die Umsetzung der gesetzlich geforderten Onlineprüfung und -aktualisierung der egk im Rahmen der Anwendung VSDM konzipiert. Die Wahl des Standalone-Szenarios obliegt dem Leistungserbringer. Es besteht zwischen der genutzten IT-Infrastruktur des Standalone-Szenarios und dem PVS, welches am Praxisnetz angeschlossen ist, weder eine physische noch eine logische Verbindung. Die egk muss daher nacheinander zunächst in das Kartenterminal des onlinefähigen Standalone-Szenarios gesteckt werden und anschließend in das Kartenterminal des Praxisnetzes. Die egk dient bei Nutzung des Standalone-Szenarios als Transportmedium zur Übergabe des Prüfungsnachweises und der aktualisierten Versichertenstammdaten an das PVS. Die vorgezogene Lösung stellt zur Abbildung des VSDM folgende Funktionen zur Verfügung: - Onlineprüfung mit Lesen der VSD und ggf. Aktualisierung - Onlineprüfung der VSD (Standalone-Szenario) und ggf. Aktualisierung - Lesen der VSD - Lesen der Versichertendaten von der KVK (sofern Versicherter noch nicht mit einer egk ausgestattet ist) Das Lesen der VSD von der KVK ist nur während der Übergangszeit, in der sowohl egk als auch KVK parallel gültig sind, notwendig. Die Initiierung der Anwendungsfälle erfolgt in der Regel durch einen Funktionsaufruf aus dem Primärsystem. Der Anwendungsfall Onlineprüfung der VSD kann zudem automatisiert vom Fachmodul VSDM beim Stecken einer Karte in das Kartenterminal ausgeführt werden. Dies ist z.b. im Fall des Standalone-Szenarios notwendig. November 2011 Seite 6

11 1.1.2 Technische Infrastruktur In der folgenden Abbildung wird das Lösungsszenario graphisch dargestellt und im Folgenden näher erläutert. Dezentral Zentral Backbone Kassen Namensdienst Zeitdienst Komponenten- PKI PKI-Dienst egk Arzt PC Netzkonnektor mit AK-Anteil SMC-K DSL- Modem VPN/ Internet VPN Konzentrator Intermediär Sicherheits- Gateway VPN Backbone VSDD CMS ehealth Kartenteriminal egk SMC-B SM(C)-KT Sicherheits- Gateway Bestandsnetze (z. B. KV-SafeNet) SFV eabrechnung UFS edmp Sonstige KV-Anwendungen PKI PKI-Dienst SMC-B Internet Abbildung 1: Technische Infrastruktur der vorgezogenen Lösung Die Primärsysteme sind Anwendungsprogramme für Leistungserbringer. Sie umfassen im Umfeld der vorgezogenen Lösung die Praxisverwaltungssysteme (PVS) für Ärzte und Zahnärzte und die Krankenhausinformationssysteme (KIS) der Krankenhäuser. Sie werden für die Einführung der Lösung mit einer Schnittstelle zum Konnektor erweitert, die den Zugang zur Telematikinfrastruktur und die Nutzung der Chipkarten realisiert. Die Primärsystemhersteller müssen ihre Systeme so anpassen, dass die Geschäftsvorgänge in Praxen und ggf. Krankenhäusern optimal durch die vorgezogene Lösung unterstützt werden. Innerhalb der vorgezogenen Lösung findet die Installation und Konfiguration der dezentralen Komponenten statt. Das bedeutet, dass die Primärsysteme und ehealth-kartenterminals (die per Update auf den SICCT-Standard gebracht wurden) per LAN an den zuvor installierten und konfigurierten Konnektor angebunden werden. Damit ist das Primärsystem mit der Telematikinfrastruktur vernetzt. Zur Onlineprüfung sowie für die Übernahme der Versichertendaten in das Primärsystem muss die egk nur einmal gesteckt werden. Die Primärsystemschnittstelle der vorgezogenen Lösung wird über Webservices umgesetzt, welche vom Fachmodul VSDM angeboten werden. Neben den Webservices des Fachmoduls VSDM benötigt das Primärsystem noch entsprechende Webservices zu Basisdiensten im Anwendungskonnektor. Der Konnektor (Netzkonnektor mit Anwendungskonnektor light ) als wichtige Sicherheitskomponente stellt den dezentralen Sicherheitsanker in der Telematik- November 2011 Seite 7

12 infrastruktur dar und gewährleistet, dass ein Lesen und Beschreiben einer egk nur durch berechtigte Akteure in einer vertrauenswürdigen Umgebung durchgeführt werden kann. Sichergestellt wird dies durch eine rollenbasierte Berechtigungsprüfung, welche die gleichzeitige Anwesenheit einer egk und einer Institutionskarte der Leistungsbringerinstitution (SMC-B) oder eines anderen berechtigten Akteurs (z.b. HBA) zwingend erfordert. Wie in der folgenden Abbildung dargestellt ist, sind die Bestandteile des Konnektors ein Netzkonnektor und ein Anwendungskonnektor light. Abbildung 2: Funktionsaufteilung des Konnektors für die vorgezogene Lösung Mittels des Konnektors wird der Zugriff der Primärsysteme zum Telematiknetzwerk gesteuert und die Zugriffe auf Kartenterminals durchgeführt. Der Konnektor besitzt Schnittstellen zu den Primärsystemen, zu den angebundenen Kartenterminals und über diese zu den Chipkarten sowie zum Telematiknetzwerk. Der Netzkonnektor stellt die Funktionen zur Einbindung des Konnektors in die Netzwerke der Leistungserbringer und der Telematikinfrastruktur zur Verfügung. Integriert ist eine funktionale Anwendungslogik (Anwendungskonnektor light ) u.a. für die Gültigkeitsprüfung der Versichertenstammdaten (Fachmodul VSDM), die Verwaltung der Kartenterminals und eine Funktion, die ein sicheres Nachladen weiterer Anwendungslogiken ermöglicht. November 2011 Seite 8

13 LE-Umgebung Primärsystemsoftware Anwendungs- Client Konnektor für vorgez. Lösung Netzkonnektor (nach PP-NK) Anwendungslogik für VSDM Zugang Bestandsnetze (z. B. KV-SafeNet bzw. Internet) VSDD KV-Anwendung SMC-B egk KT Verwaltung Kartenterminals Abbildung 3: Schematische Darstellung der Konnektorschnittstellen Die Schnittstelle des Konnektors zu den Primärsystemen bildet im Wesentlichen die fachlogischen Abläufe der Fachdienste ab. Sie kapselt die konkreten Abläufe zum Zugriff auf die karten- und serverbasierten Fachdienste und Datenobjekte gegenüber dem Primärsystem. Implementiert wird diese Schnittstelle über die Anbindung des Konnektors an das LAN der Leistungserbringer. Über die Schnittstelle zu den Kartenterminals kann der Konnektor auf die Chipkarten im Gesundheitswesen zugreifen. Die Schnittstelle zum Telematiknetzwerk und zum Intermediär bietet dem Konnektor den Zugriff auf serverbasierte Fachdienste. Teil des Konnektors ist ein Virtual Private Network (VPN) Client, der einen sicheren Kommunikationskanal über das letzte Stück des Transportnetzes zur Kommunikationsinfrastruktur aufbaut. Für die vorgezogene Lösung werden verschiedene Chipkarten zur sicheren Authentifizierung der Akteure, zur Verschlüsselung von Daten (z.b. durch Trusted Channel ) sowie zur elektronischen Signatur eingesetzt. Der Konnektor und das dezentrale Fachmodul der Anwendung VSDM kontrollieren den Datenfluss zwischen Kartenterminal, egk und dem Primärsystem sowie die zur Aktualisierung der egk notwendigen zentralen Dienste und die Fachdienste des Kostenträgers. Zu diesen kann, je nach Ausprägung der Fachdienste, auch der Zertifikats-Validierungsdienst gehören. Nach der Identifizierung und Authentifizierung des für die Aktualisierung der egk zuständigen Fachdienstes erfolgt die Aktualisierung der egk über einen gesicherten Transportweg ( Trusted Channel ). Einsatzfähigkeit im Krankenhaus In der vorgezogenen Lösung muss bei der Architektur des Konnektors die Skalierbarkeit, wie es insbesondere für den Einsatz im Krankenhaus notwendig ist, gewährleistet sein. Für den Krankenhausbetrieb müssen zusätzliche Faktoren, wie November 2011 Seite 9

14 Load Balancing, 24x7-Verfügbarkeit, Failover-Betriebssicherheit und eine in der Regel sehr komplexe Netzwerk-Topologie berücksichtigt werden. Bei Einsatz im Krankenhaus kann die Funktionalität des Netzkonnektors und des Anwendungskonnektors light als Konnektor Cluster bzw. Mehrkomponentenkonnektor auf mehrere Instanzen verteilt werden. Die Mandantenfähigkeit des Konnektors muss gewährleistet sein. Eine skalierbare Lösung muss dementsprechend aus mindestens folgenden Komponenten bestehen: ein oder mehrere Anwendungskonnektoren light und ein oder mehrere Netzkonnektoren. Aus Gründen der Übersichtlichkeit sind in der folgenden Abbildung Komponenten für das Szenario Krankenhauskonnektor skizziert. Je nach Netzaufbau ist es denkbar, dass der Netzkonnektor beispielsweise in einer DMZ steht. Weitere mögliche Sicherheitszonen, wie z.b. eine DMZ der Anwendungskonnektoren, sind aus Gründen der Übersichtlichkeit ebenfalls nicht abgebildet. Bestehende Verbindungen des Krankenhauses aus der DMZ heraus sind von der Implementierung des Netzkonnektors nicht betroffen und bleiben bestehen. Internet / weitere Netze eth3 Krankenhausnetz eth1 Router Firewall Switch eth2 (Skalierbar) DMZ eth0 eth0 Netzkonnektor Anwendungskonnektor light TI der Vorgezogene Lösung (Skalierbar) (Skalierbar) Abbildung 4: Darstellung der logischen Aufteilung eines Konnektors im Krankenhaus Die Systeme des Krankenhauses kommunizieren über LAN mit den Anwendungskonnektoren. Jedes Primärsystem kann mehrere Anwendungskonnektoren nutzen. Die Kartenterminals sind den Anwendungskonnektoren zugeordnet. November 2011 Seite 10

15 Zentrale Systeme Zentral wird eine einheitliche System- und Serverlandschaft aufgebaut, die die nachfolgend beschriebenen Funktionen erfüllt. Das zentrale Netz ist das Instrument, mit dem die Nutzung einzelner Dienste (Zeitdienst, Namensdienst etc.) angesteuert wird. Durch das Sicherheitsgateway wird die Sicherheit und demzufolge auch der Datenschutz gewährleistet. Dies bedeutet, dass insbesondere keine unbefugten Zugriffe und Durchleitungen erfolgen können. Dabei werden spezielle Firewalls eingesetzt. Bei diesen Komponenten handelt es sich um die marktübliche Standardnetzwerkleistung. Zu den zentralen Diensten der Lösung zählen alle zentralen Anteile, wie der Zeitdienst, der Namensdienst, die VPN-Konzentratoren inklusive Netzinfrastruktur (Gateways) sowie der Intermediär. Ebenso werden die zentralen Netze und das Transportnetz der Leistungserbringer zu den zentralen Diensten gezählt. Zur Verbindung der zentralen und dezentralen Zugangskomponente können das Internet oder andere vom Transportnetzprovider angebotene Transportplattformen, wie Festverbindungen oder private Netze, genutzt werden. Da hier kein einheitliches Sicherheitsniveau zur Erreichung von Sicherheitszielen, wie Integrität und Vertraulichkeit, vorausgesetzt werden kann, muss die Übertragung der Daten über einen sicheren Kanal erfolgen. Hierfür wird ein VPN auf Basis von IPsec genutzt, dass zwischen den Zugangskomponenten etabliert wird. Unabhängig von der im Transportnetz genutzten Netztransportplattform erfolgt die Authentifizierung der Zugangskomponenten über X.509 Zertifikate, deren Zuordnung organisatorisch nachweisbar ist. Die gegenseitige Prüfung der in den Zertifikaten hinterlegten Identitäten erfolgt während des Verbindungsaufbaus des IPSec-VPN. Das Transportnetz verbindet die dezentralen Komponenten mit den zentralen Systemen über eine kontrollierte und sichere Anbindung. Die Vernetzung der dezentralen Komponenten erfolgt über die lokalen Netze der Leistungserbringer. Als Transportnetz zu den zentralen Systemen wird das Internet über DSL (alternativ, wenn kein DSL verfügbar: ISDN) gewählt. Über das Transportnetz erfolgt die kontrollierte und sichere Anbindung der dezentralen Systeme der Leistungserbringer und Kostenträger an das zentrale Netz. Es handelt sich um eine logische Bezeichnung für alle hierfür notwendigen Netzwerksegmente und Komponenten und stellt somit kein echtes physisch getrenntes und homogenes Netzwerk dar. Der Intermediär, als zentrale Komponente, steuert und koordiniert die Verarbeitung der Nachrichten zwischen Konnektor und Fachdienst. Er lokalisiert abhängig vom Anwendungsfall den passenden Fachdienst und leitet die Nachricht an diesen weiter. Dabei reicht der Intermediär die Kommandos ohne Modifikation vom Konnektor weiter an den Fachdienst und wieder zurück. Eine Verarbeitung von Nachrichten im Intermediär findet nicht statt. Durch den Einsatz des Intermediärs kann bei mehreren Service-Instanzen die Anzahl der Verbindungen reduziert werden, wodurch die dezentralen Komponenten und die Fachdienste entlastet werden. Sie optimieren November 2011 Seite 11

16 somit die Betriebsführbarkeit, indem sie sowohl die Lokalisierung von Fachdiensten als auch Verbindungen zwischen Konnektoren und Fachdiensten auf eine beschränkte Anzahl von Gateways und Service-Busse, anstatt vieler Punkt-zu-Punkt- Verbindungen, zentralisieren. Sicherheitsgateways Ein Sicherheitsgateway ist ein System aus soft- und hardware-technischen Komponenten. Es gewährleistet die sichere Kopplung von IP-Netzen durch Einschränkung der technisch möglichen Kommunikation. Sicherheit bei der Netzkopplung bedeutet hierbei im Wesentlichen, dass ausschließlich erwünschte Zugriffe oder Datenströme zwischen verschiedenen Netzen zugelassen und die übertragenen Daten kontrolliert werden. Strukturell setzt sich ein Sicherheitsgateway aus einem Basisaufbau und modularen Erweiterungen dieser Basis zusammen. Die Basis wird dabei gebildet aus Paketfiltern und Application-Level-Gateways. Sicherheitsgateways werden am zentralen Übergang zwischen zwei unterschiedlich vertrauenswürdigen Netzen eingesetzt (siehe auch BSI-Dokument Konzeption von Sicherheitsgateways Version 1.0). Die Sicherheitsgateways erbringen zusätzliche Sicherheitsleistungen für die Nutzung von Bestandsnetzen. Sie stellen Systeme für den Schutz vor Malware, Inhaltsfilter oder Angriffserkennung auf Netzwerkebene (IDS) transparent oder über Proxy- Technologien bereit. Sie kontrollieren somit inhaltlich den Datenfluss zwischen den zentralen Systemen und den Bestandsnetzen. Die Anbindung von Bestandsnetzen erfolgt ausschließlich über die Sicherheitsgateways. Sie können hinsichtlich der Art der Anbindung und der zu transportierenden Daten konfiguriert werden. Weiternutzung bestehender Netze Der Zugang zu Bestandsnetzen (wie z.b. KV-SafeNet mit seinen Anwendungen) soll auch in der vorgezogenen Lösung möglich sein. Hierfür wird jedoch lediglich die Anbindung der Bestandsnetze an die vorgezogene Lösung realisiert. Damit wird auch das Ziel verfolgt, vorhandene bzw. sich schnell neu entwickelnde Insellösungen zu konsolidieren und in das Lösungsszenario zu integrieren. Maßgeblich für eine Integration ist jedoch, dass der Funktionsumfang des Lösungsszenarios nicht erweitert wird. Ein Bestandsnetz kann die vorgezogene Lösung als Transportnetz nutzen, sofern der zu Grunde liegende Funktionsumfang und das etablierte Sicherheitsniveau ausreichend sind. Der Zugang zu Fremdnetzen (Internet oder Bestandsnetze) beinhaltet die folgenden wesentlichen Aspekte: Auflösung unterschiedlicher Namensräume Sicherstellung der netzwerkseitigen Erreichbarkeit benötigter Adressräume November 2011 Seite 12

17 Sichere Anbindung Die Nutzung verschiedener Namensräume kann über einen DNS-Proxy-Nameserver, der die Anfragen an die jeweils zuständigen Nameserver weiterleitet, erfolgen. Die Erreichbarkeit der Systeme in unterschiedlichen Adressräumen und eine möglicherweise notwendige Adressumsetzung werden über eine Routing/NAT- Komponente gewährleistet. Datenverkehr für den definierten Adressraum wird an die Transportnetzkomponenten weitergeleitet, alle anderen Datenpakete (Default Route) an die jeweilige Zugangskomponente des Fremdnetzes. Die Umsetzung ist in der nachfolgenden Abbildung dargestellt. Abbildung 5: Weiternutzung bestehender Netze Die Weiternutzung bestehender Netzwerke erfolgt über die Anbindung der Bestandsnetze an die Sicherheitsgateways der zentralen Systeme. Durch den Netzkonnektor bzw. den zentralen DNS-Server erfolgen die Netzwerkwegewahl und die Zuordnung der Namensräume. Backbone Der Backbone dient als sicherer Anschlusspunkt und Bindeglied für die zentralen Netze und Fachdienste. Er verbindet somit diese beiden Netzsegmente und stellt die Gesamtstrecke von Leistungserbringer zu Kostenträger her. Zudem beinhaltet er die PKI-Dienste der Komponenten. VPN-Backbone / Zugangspunkte Das zentrale Netz mit den zentralen Systemen wird über dedizierte Netzanschlüsse direkt an den Backbone angebunden. Beim Betrieb mehrerer Zentraler Systeme durch einen Betreiber können diese gemeinsam über einen Netzwerkanschluss an- November 2011 Seite 13

18 gebunden werden. Eine zusätzliche technische Authentifizierung wie bei der Anbindung der Leistungserbringer ist nicht notwendig, da über organisatorische Maßnahmen die Authentizität des angebundenen Dienstes nachgewiesen werden kann. Die Anbindung von fachanwendungsspezifischen Diensten erfolgt im Standardfall identisch zu den Zentralen Netzen. Alternativ ist es möglich, diese über einen Transportnetzprovider an den Backbone anzuschließen. Hierfür ist allerdings wie bei der Anbindung von Leistungserbringern der Fachdienst über eine Zugangskomponente zu authentifizieren. An den Anschlüssen zum Backbone wird nur der für deren Nutzung erforderliche Datenverkehr weitergeleitet. Die Freischaltung der IP-Adressen bzw. TCP/UDP-Ports erfolgt über eine Stateful-Inspection Firewall. Die hierüber erbrachte Sicherheitsleistung ist integraler Bestandteil des sicheren Zugangspunktes des Backbone der Lösung. Betreiber von Zentralen Systemen und Fachdiensten können zusätzliche Sicherheitskomponenten in eigener Verantwortung an deren Zugangspunkten zum Backbone platzieren. Komponenten-PKI In der vorgezogenen Lösung ist die Kommunikation zwischen den Komponenten im Sinne von Geräten (Kartenterminal, Konnektor) und Diensten (Gateways, zentrale Infrastrukturdienste, Fachdienste) unter Einsatz von Zertifikaten und einer entsprechenden PKI abgesichert. Hierzu erhalten diese Komponenten und Dienste eine eindeutige Identität. Diese Identität wird durch ein Schlüsselpaar kryptographisch abgesichert. Der private Schlüssel dieses Schlüsselpaars hat einen sehr hohen Schutzbedarf und wird, je nach Komponente unterschiedlich, in einem besonders geschützten Schlüsselspeicher (bspw. Chipkarte oder HSM), aufbewahrt. Über den ihm zugehörigen öffentlichen Schlüssel wird ein X.509-Zertifikat ausgestellt. Diese Zertifikate werden durch die Komponenten-PKI verwaltet und herausgegeben. Als Vertrauensraum wird das durch die gematik spezifizierte Modell der Trust-service Status List (TSL) verwendet. Alle zum Einsatz kommenden Komponenten müssen diesen Vertrauensraum als Grundlage zur Verifikation von Zertifikaten verwenden. Für die Integration der Bestandsnetze wird ggf. eine eigene TSL etabliert. Fachdienste Die Fachdienste bilden den zentralen Anwendungsteil der Fachanwendungen. Bezogen auf die Anwendung Versichertenstammdatenmanagement sind dies die Fachdienste Versichertenstammdatendienst (VSDD), Update Flag Server (UFS) und November 2011 Seite 14

19 Card Management System (CMS). Die Anbindung der fachanwendungsspezifischen Dienste an die zentralen Dienste erfolgt über den Backbone. Die Fachdienste der Kassen beinhalten verschiedene Elemente, wie einen PKI-Dienst für die Gesundheitskarte, den Versichertenstammdatendienst (VSDD), das Kartenmanagementsystem (CMS) und den Update Flag Service. Sie alle sind wichtig für die Funktion des VSDM. Diese Systeme sind bereits durch die Kassen umgesetzt und spielen im kommenden Beschaffungsverfahren für den Test der vorgezogenen Lösung nur bezüglich der Integration eine Rolle Erweiterbarkeit und Ausblick Die Herausgabe der egk der Kartengeneration 2 könnte in den geplanten Zeitraum zum Betrieb des Lösungsszenarios fallen. Aus diesem Grund sieht das Lösungsszenario eine Integration neuer Karten zur Nutzung der egk G2 vor. Im Detail bedeutet dies, dass eine Interoperabilität zwischen Karten der Generation 1 und Generation 2 erzielt werden muss. Somit könnten beide Kartengenerationen parallel im Feld genutzt werden. Weitere Anpassungen der Infrastruktur werden nicht als notwendig angesehen, da zum Ende der geplanten Laufzeit des Lösungsszenarios eine vollständige Migration in die Ziellösung erfolgen soll. In der folgenden Abbildung werden die Kern-Komponenten der vorgezogenen Lösung aufgelistet und hinsichtlich ihrer Migrationsfähigkeit bewertet. Dabei wurden die Kategorien von migrierbar (in der Abbildung mit der Farbe grün dargestellt) über migrierbar mit Anpassungen/Einschränkungen (gelb dargestellt) und voraussichtlich nicht migrierbar (rot dargestellt) gewählt. Da sich die Ziellösung noch größtenteils in der Entwicklung befindet, wurden die Komponenten schwerpunktmäßig hinsichtlich Standardkonformität, Nachladefähigkeit und Erweiterbarkeit betrachtet. Bei einigen Komponenten, wie Kartenterminals, den eingesetzten Karten und den Fachdiensten, kann aufgrund des Bestandsschutzes von einem unveränderten Einsatz in der Ziellösung ausgegangen werden. Abhängig von der Ziellösung wird eine Anpassung bzw. ein Austausch von einzelnen Komponenten als notwendig angesehen und wurde entsprechend in der Kostenbetrachtung berücksichtigt. November 2011 Seite 15

20 deployment Gesamtübersicht Dezentrale Systeme Zentrale Systeme Backbone Fachdienste Arbeitsplatz-PC (Primärsystem) Komponenten-PKI TSL VSDD Konnektor Netzkonnektor OCSP-Responder CAMS AK-Anteile VPN-Konzentrator Transportnetz Gateway UFS Smartcard Sicherheitsgateway Intermediär VPN-Backbone egk-pki (OCSP-Responder) ehealth Kartenterminal Zeitdienst (NTP) Namensdienst (DNS) Zugangspunkte LEO-PKI (OCSP-Responder) grün = Migrierbar gelb = Migrierbar mit Anpassungen / Einschränkungen rot = Nicht migrierbar Abbildung 6: Bewertung der Migrationsfähigkeit einzelner Komponenten Die elektronischen Gesundheitskarten der Generation 1 plus sind schon für die Verarbeitung in der Ziellösung vorbereitet und enthalten alle notwendigen Container und Zugriffregeln. Eine ggf. notwendige Schemaanpassung an ein aktuelleres VSD- Schema in der Ziellösung kann über die Aktualisierung online durchgeführt werden. Aufgrund des definierten Bestandsschutzes wird sich die Schnittstelle der Fachdienste (UFS, VSDD, CMS) gegenüber der Ziellösung nicht verändern, so dass hier keine inhaltlichen Anpassungen durch die Kostenträger notwendig sind. Die Fachdienste müssen jedoch für die Migration in die Ziellösung an die zentrale Telematikinfrastruktur angebunden werden. November 2011 Seite 16

21 2 Leistungsumfang in den Testvorhaben 2.1 Allgemeine Rahmenbedingungen Gemäß 2 der Rechtsverordnung (RVO) haben die Testmaßnahmen das Ziel der Überprüfung und Weiterentwicklung der Telematikinfrastruktur, die für die Einführung und Anwendung der elektronischen Gesundheitskarte erforderlich ist. Die Feldtests (im Folgenden auch als regionale Tests bezeichnet) sollen dabei insbesondere die Einsetzbarkeit des Gesamtsystems unter realen Einsatzbedingungen sowie den Einfluss auf die bestehenden Geschäftsprozesse prüfen. Dadurch soll sichergestellt werden, dass die elektronische Gesundheitskarte und die dafür notwendige Telematikinfrastruktur erfolgreich in die flächendeckende Versorgung überführt werden können. Die Zielsetzung der Feldtests im Rahmen der vorgezogenen Lösung besteht in der Überprüfung der Kriterien Praxistauglichkeit, Akzeptanz, Betriebstauglichkeit und Datenschutz für Infrastrukturkomponenten und die Anwendung VSDM. Die Erkenntnisse aus den Feldtests bilden die Grundlage für die fachliche, technische und logistische Umsetzung des bundesweiten Rollouts. Die Tests der vorgezogenen Lösung werden unter der aktuellen RVO durchgeführt. Hieraus können die folgenden Rahmenbedingungen für die Durchführung der Tests abgeleitet werden: - Definition von zwei Testregionen innerhalb eines Vergabeverfahrens und unter Berücksichtigung der aktuellen RVO sowie der Finanzierungsvereinbarung mit der gematik, - Grundlage der Auswahl sind die existierenden sechs Testregionen unter Einbeziehung der Projektbüros, - Änderungen werden im Benehmen mit den jeweils zuständigen obersten Landesbehörden vorgenommen (35 Abs. 6 RVO), - Sicherstellung der Ausstattung einer möglichst hohen Anzahl an Leistungserbringern innerhalb einer Testregion (idealerweise Vollausstattung), damit genügend verwertbare Erkenntnisse nach Abschluss der Tests vorliegen, - Möglichkeit der Einbindung aller an den Tests beteiligten Parteien. Die RVO beschreibt diesbezüglich das mögliche Einrichten von Beiräten, zusammengesetzt aus Vertreterinnen und Vertretern der Leistungserbringer, der Pati- November 2011 Seite 17

22 entinnen und Patienten sowie der Kostenträger 2 zur Sicherung der Praxistauglichkeit Des Weiteren basiert die Konzeption der Tests für die vorgezogene Lösung auf den Erfahrungen aus den er Tests: - Testung mit relevanter Grundgesamtheit: Die geringe Anzahl Testbeteiligter (Leistungserbringer und Versicherte) während der er Tests hat zu wenig aussagekräftigen Ergebnissen aufgrund geringer Fallzahlen geführt. Bei den Tests der vorgezogenen Lösung ist insbesondere auf eine deutlich höhere Anzahl beteiligter Leistungserbringer und Versicherter zu achten. - Vermeidung kleinteiliger Vergabeverfahren: Aus Gründen der Interoperabilität der Komponenten werden die Lose im Vergleich zu den er Tests deutlich umfangreicher geschnitten. Die Erfahrungen aus den er Tests haben gezeigt, dass z.b. Interoperabilitätsprobleme zwischen den Komponenten der Telematikinfrastruktur und den Primärsystemen eine häufige Ursache für den fehlerhaften Betrieb der Lösung waren. - Starke Angewiesenheit auf politische Lobby innerhalb der Testregion: Die er Tests haben gezeigt, dass die politische Unterstützung des Testvorhabens in einer Testregion erfolgskritisch ist, insbesondere in Bezug auf das Zusammenspiel der beteiligten Parteien von Kostenträgern und Leistungserbringerorganisationen. - Beschaffung und Betrieb der Komponenten als einheitliches Los: Die Durchführung der er Tests haben die Problematik einer Trennung von Produktion und Betrieb einzelner Komponenten aufgezeigt. Die Beschaffung für die Durchführung der Tests der vorgezogenen Lösung sollte sich daher an einer Vergabe an gesamtverantwortliche Bieterkonstellationen orientieren. In Anbetracht der oben genannten Rahmenbedingungen werden in den folgenden Abschnitten die Eckpunkte für die Testdurchführung im Hinblick auf die Auswahl der Testregionen, der Testziele, der Testdauer und der Evaluation der Tests definiert. 2 Dritte Verordnung zur Änderung der Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte, 5 Vorgaben zur Organisation der Testung durch die Gesellschaft für Telematik (10), Stand November 2011 Seite 18

23 2.2 Eckpunkte der regionalen Tests Auswahl der Testregionen Es wird empfohlen, die Auswahl von zwei der sechs bestehenden Testregionen im Ausschreibungsverfahren den Bieterkonsortien zu überlassen, wobei Rahmenvorgaben, z.b. in Bezug auf die Anzahl einzubeziehender Leistungserbringer, gemacht werden können. Hierbei ist vorgesehen, dass sich alle Bieter für zwei Testregionen bewerben, in deren Rahmen sie die definierten Testziele erfüllen können. Eine Verbindung zweier Testregionen zu einer einzelnen, um die definierten Testziele zu erreichen, kann ebenfalls eingeräumt werden. Die finale Auswahl der Bieter für die beiden Testregionen bleibt dem Auftraggeber innerhalb des Verhandlungsverfahrens vorbehalten (siehe Kapitel 4) Testziele Ein primäres Ziel der Tests ist der Nachweis der Funktionsfähigkeit des Systems, der Betriebsprozesse in der konkreten Betriebsumgebung sowie der Prozesse und Organisation des Rollouts für die folgende bundesweite Einführung in der Fläche. Hierbei müssen die schnelle Herstellung des vollständigen Wirkbetriebs, die Erreichung der Qualitätsziele sowie der Nutzerakzeptanz sichergestellt sein. Ebenso müssen ein einheitliches Vorgehen und einheitliche Qualität bis in den Wirkbetrieb gewährleistet sein. Die Auftragnehmer müssen daher vordefinierten Anforderungen gerecht werden. - Erstellung eines Testkonzepts: Der Betreiber muss in einem Testkonzept darlegen, wie die Betriebsfähigkeit des Systems nachgewiesen wird. Dieses Betriebstestkonzept ist im Angebot zu skizzieren und in der Einführungsphase soweit auszuarbeiten, dass die darin beschriebenen Tests und Testergebnisse als Grundlage für eine Abnahme des Systems genutzt werden können. Daneben sollte das Testkonzept auch regionale Unterschiede berücksichtigen, z.b. durch die Auswahl geeigneter Testregionen/Testteilnehmer. - Durchführung der Tests: Zu den durchzuführenden Tests gehören unter anderem anwenderbezogene und funktionale Tests (Feldtests), Schnittstellenund Kommunikationstests, Lasttests, Ausfall- und Failover-Tests. Ein weiteres zentrales Testziel besteht in der Planung und Durchführung des Rollouts (Planung, Logistik, Prozesse, Abwicklung, Support/Service, etc.) sowie im Zusammenspiel der Auftragnehmer-Parteien (Generalunternehmer, Service Provider, PS-Hersteller, etc.), insbesondere um Aussagen für den anschließenden bundesweiten Rollout ableiten zu können. November 2011 Seite 19

24 - Durchführung von Tests durch die gematik: Der Auftraggeber behält sich vor, die vom Betreiber durchgeführten Tests zu wiederholen und weitere eigene Tests durchzuführen. Der Betreiber muss ihm dies ermöglichen und ihn im angemessenen Rahmen dabei unterstützen. - Durchführung von Zuslassungstests durch die gematik Die gematik wird im Zuge der Zulassung gewisser Komponenten Tests durchführen. Der Auftragnehmer verpflichtet sich, diese Tests in angemessenem Umfang zu unterstützen. Sofern diese Anforderungen gegeben sind, haben die Auftragnehmer insbesondere Testziele zu erfüllen, die sich in drei Kategorien aufteilen lassen (weitere Testziele sind gegebenenfalls zu späterem Zeitpunkt innerhalb des Verhandlungsverfahrens zu definieren): 1. Mengengerüst Für die Testung der vorgezogenen Lösung muss eine geeignete Anzahl Leistungserbringer ausgestattet werden. Unter den Krankenhäuser müssen unterschiedliche Versorgungsstufen (Größenordnungen) mit mindestens einer Universitätsklinik vertreten sein. Die Testmaßnahmen müssen die Nutzung eines erforderlichen Mehrkomponentenkonnektors ermöglichen. Hierbei wird vorausgesetzt, dass die Versicherten zum Großteil bereits mit egks ausgestattet sind und die Fachdienste der Kassen VSDM-funktionsfähig sind. Die vollständige Ausstattung der Leistungserbringer ist gleichzeitig eines der zu erfüllenden Testziele und setzt sich wie folgt zusammen: Siehe hierzu Dokument der Arbeitsgruppe. Annahmen exemplarisch bezogen auf Arztpraxen: - Anzahl einzubindender Leistungserbringer pro Testregion M Ärzte = Anzahl Primärsystemhersteller M PS = 5 - Daraus mindestens 3 PVS-Hersteller, die nicht gesellschaftlich verbunden sind - Durchschnittliche Abrechnungsfälle pro Quartal = M Abrechnungsfälle(Arzt)(Quartal) - Durchschnittliche Patientenbesuche pro Quartal = M Patientenbesuche(Arzt)(Quartal) - Im ersten Quartal liegen für alle Versicherten Updates vor (Schemaänderung) Aus diesen Annahmen ergeben sich die Ziele: - Updates im Quartal = M Ärzte x M Abrechnungsfälle(Arzt)(Quartal) - Transaktionen im Quartal = M Ärzte x M Abrechnungsfälle(Arzt)(Quartal) x M Patientenbesuche(Arzt)(Quartal) November 2011 Seite 20

25 Anmerkung: Dies setzt voraus, dass in den regionalen Tests bei jedem Patientenbesuch die egk gesteckt wird. Das Mengengerüst ist für die endgültige Ausschreibung zu aktualisieren und um das Mengengerüst für Zahnarztpraxen und Krankenhäuser zu erweitern. 2. Messung und Reports Ein weiteres Testziel ist die Bereitstellung von Testdaten für die begleitende Evaluation der Testmaßnahmen. Aus dem beschriebenen Mengengerüst lassen sich exemplarisch für Arztpraxen folgende Transaktionsraten herleiten: Transaktionen pro Arzt Gesamt (pro Testregion) pro Quartal 2.300, ,00 pro Tag (Arbeitstag) 38, ,67 pro Stunde (10 Std/Tag) 3, ,67 pro Minute 31,94 pro Sekunde 0,53 Updates pro Arzt Gesamt (pro Testregion) pro Quartal 1.000, ,00 pro Tag (Arbeitstag) 16, ,33 pro Stunde (10 Std/Tag) 1,67 833,33 pro Minute 13,89 pro Sekunde 0,23 Abbildung 7: Beispielhafte Hochrechnung der Transaktionsraten während der regionalen Tests Durch die notwendige Aktualisierung des VSD-Schemas im Online-Rollout, findet beim erstmaligen Stecken in jedem Fall ein Update der egk statt. 3. Nicht-funktionale Anforderungen an die Komponenten Schließlich müssen die Betreiber bei der Einführung des Systems die im Betriebstestkonzept definierten Tests durchführen und protokollieren. Die Protokollierung muss geeignet sein, den Erfüllungsgrad bezüglich funktionaler und nichtfunktionaler Anforderungen zu erkennen. November 2011 Seite 21

26 2.2.3 Dauer der Tests Die Tests der vorgezogenen Lösung sollten über einen geeigneten Zeitraum stattfinden, der eine ausreichende Testung der durch die Anbieter betriebenen Telematikinfrastruktur sicherstellt. Gleichzeitig muss eine Verzögerung der vorgezogenen Lösung durch eine überflüssige, ausgedehnte Testung ohne zusätzliche Erkenntnisgewinnung vermieden werden. Die Dauer der Tests wurde daher auf Basis von folgenden Kriterien festgelegt: - Die Tests finden über einen Zeitraum von mindestens drei Monaten und quartalsübergreifend statt. Hierdurch werden eine VSD-Aktualisierung durch das initiale Stecken der egk sowie eine potenzielle, weitere Aktualisierung im anschließenden Quartal sichergestellt. Weitere Transaktionen über die Telematikinfrastruktur finden zusätzlich bei jedem weiteren Arztbesuch, auch ohne VSD-Aktualisierungsvorgang, statt. Diese Transaktionen liefern ebenfalls statistisch belastbare Daten über Traffic und Performance der Lösung. - Gespräche mit Vertretern aus der Industrie haben die Dauer der Tests von drei bis sechs Monaten in Verbindung mit einer Ausstattung von ca. 500 Leistungserbringern pro Testregion als sinnvolle Parameter bestätigt, um statistisch signifikante Daten zur Verfügung stellen zu können Evaluation der Tests Die Evaluation der Tests erfolgt primär zur auftraggeberseitigen Überprüfung der Einhaltung der Leistungsversprechen bzw. Testziele der beauftragten Bieterkonsortien. Die Methodik und das Vorgehen orientieren sich an den er Tests und wird unabhängig von den Industriekonsortien auf Auftraggeberseite durchgeführt. Aufgabe der Auftragnehmer besteht in der Bereitstellung entsprechender Daten zur Überprüfung der Testziele. Des Weiteren ist die Befragung der am Test Beteiligten durch strukturierte Fragebögen in Betracht zu ziehen, z.b. in einer Akzeptanzanalyse durch Interviews sowohl bei Patienten, Leistungserbringern als auch bei Leistungserbringerorganisation und Vertretern der Kostenträger. Eine wissenschaftliche Begleitung der Evaluation hat sich bereits während der er Tests bewährt, um objektive und belastbare Aussagen zur Zielerreichung zu erhalten. Hierzu kann auf den Erfahrungen innerhalb der gematik aufgesetzt werden. November 2011 Seite 22

27 2.3 Leistungsumfang und Losaufteilung in den Tests Nachdem in den Punkten 2.1 und 2.2 die Rahmenbedingungen und der quantitative Umfang der Tests erläutert wurden, wird in diesem Abschnitt beschrieben, welche konkreten Aufgaben im Einzelnen erbracht werden müssen. Der Leistungsumfang der Tests ist entsprechend der zu beschaffenden Lose aufzuteilen. Es ist vorgesehen, zwei Lose für den egk/ti Aufbau und Betrieb (Ende-zu-Ende-Verantwortung der Dienstleister) für jeweils eine Testregion sowie ein Los für den Aufbau und Betrieb des Backbone zu vergeben. Für die inhaltliche und vergaberechtliche Begründung der Losaufteilung wird an dieser Stelle auf Kapitel 4 verwiesen. Abschließend werden Aspekte bezüglich der Zusammenarbeit zwischen Auftragnehmer und Auftraggeber bei der Testung der vorgezogenen Lösung verdeutlicht. In Anlehnung an das technische Konzept aus Kapitel 1 zeigt folgende Abbildung eine Übersicht über zentrale Komponenten des Backbone und der Fachdienste sowie über die zentralen und dezentralen Komponenten in den Regionen, die für die Durchführung des Tests in einer Region notwendig sind. Anzubinden oder zu aktualisieren Zu beschaffen Vorhanden aber anzubinden Dezentral Zentral Backbone Namensdienst Zeitdienst Komponenten- PKI Kassen PKI-Dienst egk Arzt PC Netzkonnektor mit AK-Anteil SMC-K DSL- Modem VPN/ Internet VPN Konzentrator Intermediär Sicherheits- Gateway VPN Backbone VSDD CMS ehealth Kartenteriminal egk SMC-B SM(C)-KT Sicherheits- Gateway Bestandsnetze (z. B. KV-SafeNet) SFV UFS PKI PKI-Dienst SMC-B Je Testregion Übergreifend Abbildung 8: Übersicht über die zu beschaffenden Komponenten Einige Komponenten sind dabei bereits in den Regionen vorhanden, andere müssen neu beschafft, angebunden oder aktualisiert werden. Die Auftragnehmer, die diese Testinfrastruktur umsetzen, müssen zwingend diese Komponenten einsetzen und dabei den Vorgaben (technischen Spezifikationen etc.) genügen. Nur die Testung der Gesamtverfügbarkeit ist ein sinnvolles Vorgehen, was vom Auftragnehmer die Übernahme einer Ende-zu-Ende-Verantwortung erfordert. Die Bedeutung der Übernahme übergreifender Verantwortung wird aus nachstehender Ab- November 2011 Seite 23

28 bildung ersichtlich, in der das Versichertenstammdatenmanagement als übergreifende Anwendung mit den Prozessen Lesen der VSD, Onlineprüfung der VSD ohne Aktualisierung, Onlineprüfung der VSD mit Aktualisierung (siehe auch Kapitel 1) dargestellt ist. Beteiligte Ausgesuchte Komponenten Anwendung Prozesse der innerhalb Anwendung Betreiber egk/ti 1 und 2 PS/Terminal Konnektor Zentr. System Lesen der VSD : ŁLesen der Versichertendaten im ungeschützen Bereich ŁProzesse laufen Geräte- und Betreiber übergreifend Betreiber Backbone PKI/Backbone Versichertenstammdatenmanagement (VSDM) ŁIm Basis-Rollout möglich Onlineprüfung der VSD ohne Aktualisierung : ŁTechnische Nutzbarkeit der egk prüfen ŁZertifikatsvalidierungsdienst abfragen ŁUpdate Flag Service abfragen ŁEchtheit der beteiligten Karten prüfen ŁVSD lesen, Lesen GVD protokollieren ŁPrüfungsnachweis erzeugen ŁPrüfungsnachweis und VSD an PS übergeben Onlineprüfung der VSD mit Aktualisierung : ŁWie Onlineprüfung ohne Aktualisierung der VSD inkl. Aktualisierung der VSD auf der egk durch Fachdienst (vor Echtheitsprüfung) Betreiber Kassensystem Fachdienste Konkrete Zieldauer je Prozess zu definieren Abbildung 9: Übergreifende Anwendungen VSDM Im Sinne der Ende-zu-Ende-Verantwortung sollen Auftragnehmer im Rahmen der Testung folgende Leistungen erbringen: Leistungsumfang des Auftragnehmers egk/ti Testbetrieb mit Ende-zu-Ende- Verantwortung: - Bereitstellung der Anwendung VSDM gemäß gematik-vorgaben (Prozesse, technische Spezifikationen etc.) sowie der hierfür erforderlichen dezentralen Infrastruktur-Komponenten, o Softwareanpassung des Primärsystems (Online-Schnittstelle) o Bereitstellung des Konnektors mit Anwendungskonnektor light o Installation des Transportnetzes o Beschaffung der SMC-B (inklusive SM-KT), der SMC-K und Installation o Konfiguration und Verkabelung der dezentralen Infrastruktur - Bereitstellung des Transportnetzes - Bereitstellung der zentralen Systeme o VPN-Konzentrator o Infrastrukturdienste o Intermediär November 2011 Seite 24