Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Erste Fassung der Spezifikation

Transkript

1 Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Erste Fassung der Spezifikation Version 1.0 vom 14. März 2005

2

3 Inhalt Inhalt 1 Einleitung Ziel des FuE-Projekts Einordnung des Dokuments in den Projektkontext Aufbau des Dokuments Nicht betrachtete Aspekte Status des FuE-Projekts 15 2 Leitlinien und Grundsätze Patientenorientierung und Datenhoheit Übertragung von Daten Integration von externen Systemen Anwendungsübergreifend einheitliche Lösungen Technologie- und Produktneutralität Verwendung von Standards und erprobten Konzepten Migrationsfähigkeit und Skalierbarkeit 17 3 Anwendungen und Akteure der egk Pflichtanwendungen Arzneimittelverordnung Versichertenstammdaten Freiwillige Anwendungen Akteure Versicherte und Versicherungen Leistungserbringer Primärsysteme Betreiber 25 4 Spezifikation der Lösungsarchitektur Gesamtübersicht Lösungsarchitektur Systemgrenzen der Telematikinfrastruktur Grobarchitektur Beispiel: Einstellen und Lesen eines erezepts Anwendungs- und Infrastrukturdienste Schichtenmodell Sicherheits- und Datenschutzkonzept Sicherheitsdienste, -mechanismen, -objekte und - maßnahmen Sicherheitsanforderungen Schutzbedarfe der Anwendungsdaten und Funktionen Sicherheitsmaßnahmen Bedrohungsszenarien 67 i

4 Inhalt Sicherheitsmaßnahmen Sicherheitszonen Sicherheitsarchitektur Public Key Infrastruktur Zugang zur Infrastruktur Virtuelle Sektorennetze Dezentrale Zugangskomponenten Nutzung von Diensten der Telematikinfrastruktur Lokalisierung von Diensten Verwaltung von Anwendungsdaten Anforderungen an Zugangssicherung und Datenhaltung Zugangs- und Integrationsschicht (ZIS) Ausstellen und Einlösen von Tickets Rollen und Zugriffe Aufbau von t-nodes Zusammenspiel der egk-schutzmechanismen mit dem ZIS Verteilung des ZIS und der verwalteten Daten Umsetzung der Anforderungen Spezifikation der Lösungskomponenten Dezentrale Komponente: Konnektor Allgemeines Anforderungen Entwurfsprinzipien Konzeptionelle Architektur Schnittstelle Konnektor Primärsystems Dezentrale Komponente: Kartenterminal Allgemeines Ist-Analyse und abgeleitete Anforderungen Architekturentscheidung Spezifikation der Kartenterminalschnittstelle Ausführungsort der Kartenterminalschnittstelle Migrationsszenarien Dezentrale Komponente: Access Gateway Dienst: Aufbau einer Verbindung zur Kommunikationsinfrastruktur Dienst: Zuordnung von Dienstadressen Dienst: Vergabe von IP-Nummern Dezentrale Komponente: Service Gateway Topologie der Kommunikationsinfrastruktur Spezifikation der Zugriffs- und Integrationsschicht (ZIS) Informationsmodelle der verwendeten Objekte TicketToolkits 177 ii

5 Inhalt Verzeichnishierarchie Informationsmodell: t-node Informationsmodell: Ticket Anwendungsdatensatz Zentrale Komponente: Datenspeicher Bedrohungs- und Risikoanalyse Nicht-funktionale Anforderungen Verwendung der Komponente und Nutzung anderer Komponenten Funktionale Dekomposition der Komponente und ihrer Dienste Dienst: Speicherung von Anwendungsdaten Dienst: Speicherung von Verzeichnissdaten Dienst: Transportdienst Dienst: Logging-Dienst Dienst: Zugriffs- und Integrationsschicht (ZIS) Bedrohungs- und Risikoanalyse Nicht-funktionale Anforderungen Verwendung der Komponente und Nutzung anderer Komponenten Funktionale Dekomposition der Komponente und ihrer Dienste Schnittstellen des ZIS-Dienstes Spezifikation der Anwendungsdienste Einbettung der Anwendungsdienste in die Telematikinfrastruktur Nutzung des Ticket-Verfahrens zum Zugriff auf die Anwendungsdienste Szenario 1: Daten auf Server, kein Ticket in der egk Szenario 2: Daten auf Server, Ticket auf der egk Schnittstellen der Anwendungsdienste Spezifikation und Kartenmanagement der egk Spezifikation Teil 1: Kommandos, Algorithmen und Funktionen der COS-Plattform Teil 2: Basis-Anwendungen und Funktionen Teil 3: Elektronisches Rezept Teil 4: Freiwillige Anwendungen Produktion einer egk Rahmenbedingungen Überblick Skizzierung des Ablaufs: Personalisierungsdaten bereitstellen Skizzierung des Ablaufs: Karte initialisieren 240 iii

6 Inhalt Skizzierung des Ablaufs: Karte personalisieren Skizzierung des Ablaufs: egk an Versicherten übergeben CVC Erzeugung Nachpersonalisierung der Signaturfunktion Daten für das Karten Life Cycle Managament Kryptografische Schlüssel in der egk für die Nutzungsphase Einrichten, Sperren und Freigeben von Anwendungen Card-2-Server Authentisierung Sperren/Freigeben der egk und Ungültig-Setzen der Gesundheitsanwendung Einrichten von freiwilligen Anwendungen Sperren und Freigeben von Anwendungen Spezifikation der Infrastrukturdienste OID-Dienst Funktionale Anforderungen an zu erzeugende Object- Identifikatoren Vorgaben zur Struktur der Object-IDs Einsatz des OID-Dienstes Nutzung des OID-Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der lokale OID-Dienst OID-Dienst der Ebene Der Wurzel-OID-Dienst Query-Dienst Einsatz des Query-Dienstes Nutzung des Query-Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der lokale Query-Dienst Query-Dienst eines AccessGateway Transportdienst Spezifikation der Sicherheitscharakteristik Spezifikation der Transportcharakteristik Einsatz des Transportdienstes Nutzung des Transportdienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der Teildienst TD-Sender Der Teildienst TD- Empfänger Logging-Dienst (syslog-dienst) 281 iv

7 Inhalt 9.5 Network Time Protocol - Dienst (NTP-Dienst) Standards Einsatz des NTP-Dienstes Nutzung des NTP-Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der lokale NTP-Dienst NTP-Dienst eines Access Gateway bzw. Service Gateway Der zentrale NTP-Dienst der Tekematikinfrastruktur Protokoll-Dienst Verzeichnisdienst Standards Einsatz des Verzeichnisdienstes Nutzung des Verzeichnisdienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der lokale Verzeichnisdienst Verzeichnisdienst eines Access Gateways bzw. Service Gateways Empfohlene Standards Der zentrale Verzeichnisdienst der Telematikinfrastruktur Sperrprüfdienst Einsatz des Dienstes Nutzung des Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der Sperrprüfdienst Der X.509-Verzeichnisdienst Einsatz des Dienstes Nutzung des Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der Verzeichnisdienst im Bereich A Der Verzeichnisdienst im Bereich B Zeitstempeldienst Einsatz des Dienstes Nutzung des Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der Zeitstempeldienst Konfigurationsdienst 310 v

8 Inhalt Einsatz des Konfigurationsdienstes Nutzung des Konfigurationsdienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Konfigurationsdienst (Server) Zugriff auf den Konfigurationsdienst Lokalisierungsdienst Einsatz des Dienstes Nutzung des Dienstes Bedrohungs- und Risikoanalyse Nichtfunktionale Anforderungen Funktionale Dekomposition des Dienstes Der lokale Lokalisierungsdienst Lokalisierungsdienst eines Access Gateways Literatur 325 A Allgemeines 336 A.1 Abkürzungsverzeichnis 336 A.2 Glossar 336 A.3 Abbildungsverzeichnis 336 A.4 Tabellenverzeichnis 337 B Anforderungen an die Lösungsarchitektur 339 B.1 Gesetzliche Vorgaben 349 B.1.1 GKV-Modernisierungsgesetz und SGB V 341 B.1.2 Bundesdatenschutzgesetz 342 B.1.3 Signaturgesetz / Signaturverordnung 345 B.1.4 Sonstige Regelungen 346 B.1.5 Anwendungslandschaft im Gesundheitswesen 347 B.2 Nichtfunktionale Anforderungen 348 B.2.1 Architektur 349 B.2.2 Skalierbarkeit 351 B.2.3 Technologien und Produkte 351 B.2.4 Verfügbarkeit 352 B.2.5 Performance 352 B.2.6 Transportkapazitäten 352 B.2.7 Benutzerakzeptanz 352 B.2.8 Sicherheit 353 B.3 Funktionale Anforderungen 356 C Zugriffsrechte 358 vi

9 Einleitung Danksagung Die Einbeziehung eines arbeitsfähigen Kreises von Experten des BMGS sowie aus der Industrie und der Selbstverwaltung war entscheidend, um zu einer umsetzbaren und akzeptierten Lösungsarchitektur zu kommen. Die eingeladenen Experten aus der Industrie und der Selbstverwaltung haben mit ihrer Expertise wesentlich an den erzielten Ergebnissen mitgewirkt. Das FuE- Projekt möchte sich hiermit bei allen Beteiligten für deren intensive und konstruktive Mitarbeit und die eingebrachten Ideen bedanken. Die Projektleitung Prof. Dr. Herbert Weber Dr. Arne Fellien Dr. Jörg Caumanns 7

10 Einleitung 1 Einleitung Das Bundesministerium für Gesundheit und Soziale Sicherung (BMGS) hat mit der für 2006 geplanten Einführung (egk) eines der größten und innovativsten IT-Projekte weltweit in Gang gesetzt. Smart Cards gelten als Schlüsseltechnologie für den sicheren und unkomplizierten Zugang zu personalisierten Anwendungsdiensten. Mit der Einführung der egk für alle gesetzlich Krankenversicherte und dem Aufbau einer unterstützenden Telematikinfrastruktur werden die vorhandenen IT-Systeme in Praxen, Apotheken und Krankenhäusern vernetzt. Damit wird eine nahtlose Unterstützung von heute noch häufig papierbasierten Prozessen im Gesundheitswesen erreicht, bei der die egk des Versicherten sowohl als Datenträger wie auch als Schlüssel zum Zugang zu Anwendungsdiensten benutzt werden kann. Für die Versicherten wird es möglich, über einen Dienst der egk gezielt medizinische Daten z. B. für eine Arzneimitteldokumentation zu speichern und im Bedarfsfall dem Arzt oder Apotheker zugänglich zu machen. Mit seiner Karte behält der Versicherte dabei die Kontrolle über die Speicherung und Verarbeitung der Daten. Die egk kann zukünftig leicht um neue, patientenorientierte Anwendungen erweitert werden. Für die Vernetzung wird eine Kommunikationsinfrastruktur geschaffen, die ein abgesichertes, virtuelles, privates Netz innerhalb des zugrunde liegenden Internets bildet. Gateways stellen dabei sicher, dass nur autorisierte Nutzer Zugang zur Kommunikationsinfrastruktur erhalten. Durch die egk werden insbesondere die folgenden Verbesserungen in der Effektivität und Qualität der Gesundheitsversorgung erzielt: - Durch die Vermeidung von Medienbrüchen (z. B. Einscannen von Papierrezepten) können in großem Umfang Kosten gespart werden, - durch eine erhöhte Transparenz und Verfügbarkeit von Gesundheitsdaten wird eine Stärkung der Eigenverantwortung der Versicherten erreicht, - durch eine einrichtungsübergreifenden Zusammenarbeit von Leistungserbringern werden Modelle einer integrierten Gesundheitsversorgung unterstützt, - durch auf den Gesundheitsdaten der Versicherten aufsetzende, freiwillig nutzbare Anwendungen der egk wird eine Qualitätsverbesserung in der gesundheitlichen Versorgung erreicht und 8

11 Einleitung - durch die einrichtungsübergreifende Verfügbarkeit von medizinischen Daten des Versicherten und die Dokumentation von Untersuchungsergebnissen und Medikationen wird die Anzahl der Fehlbehandlungen vermindert. Im Rahmen eines Forschungs- und Entwicklungsvorhabens hat im Herbst 2004 ein Konsortium von Instituten der Fraunhofer Gesellschaft die Arbeiten an einer der elektronischen Gesundheitskarte aufgenommen. Der Zuwendungsgeber für das FuE-Projekt ist das BMGS. Mit der Spezifikation der Lösungsarchitektur ist ein wesentlicher Schritt zur Einführung der egk im Jahr 2006 erfolgt. Die hier vorgelegte erste Fassung der Spezifikation stellt eine ganzheitliche Sicht auf die Lösungsarchitektur dar. Die Abstimmung mit den Projektgremien für die weitere Ausarbeitung sowie die Einbeziehung einer breiten Fachöffentlichkeit durch ein Kommentierungsverfahren erfolgen zeitnah. Das FuE-Projekt ordnet sich in ein übergeordnetes Projekt zur Einführung der egk ein, dass die gematik (Gesellschaft für Telematikanwendungen der Gesundheitskarte) ggmbh durchführt. Die gematik ist eine im Dezember 2004 von der gemeinsamen Selbstverwaltung gegründete Betriebsorganisation. Auf Basis der Ergebnisse des FuE-Projekts kann - durch die gematik ggmbh und die Organe der gemeinsamen Selbstverwaltung mit dem Aufbau der Telematikinfrastruktur (zentrale Dienste und Verzeichnisdienste) begonnen werden und - durch die Industrie mit der Entwicklung und Anpassung von Produkten an die Spezifikationen der dezentralen Lösungskomponenten (Konnektor, Access-Gateway) und mit dem Aufbau der Kommunikationsinfrastruktur begonnen werden sowie - eine Erprobung der Telematikinfrastruktur in ausgewählten Testregionen ab 2005 stattfinden. 1.1 Ziel des FuE-Projekts Das Ziel des FuE-Projekts ist die Erarbeitung einer interoperablen, erweiterbaren Lösungsarchitektur, die die stufenweise Einführung der im Gesundheitsmodernisierunggesetz [GMG] vom Gesetzgeber geforderten Pflicht- und freiwilligen Anwendungen im Rahmen des übergeordneten egk- Projekts vorbereitet. Das FuE-Projekt setzt dabei auf die z. T. sehr weitreichenden konzeptionellen und technologischen Vorarbeiten aus den Projekten bit4health und protego.net auf. Das Projekt stimmt sich eng mit dem BMGS, mit den Organen 9

12 Einleitung der Selbstverwaltung und mit zu diesem Zweck gegründeten Projektgremien (Architektur- und Steering Board) ab, an denen auch Vertreter der Industrie beteiligt sind. Im Antrag für das FuE-Projekt vom werden dessen Aufgaben folgendermaßen zusammengefasst:»[zu betrachten sind]... die Anwendungsdienste des Versichertenstammdatenmanagements, das Verordnungsmanagement und das Kartenmanagement. Im weiteren Schwerpunkt werden die zentralen Komponenten und Dienste der Telematikinfrastruktur spezifiziert. Dies betrifft u. a. den Übergang von Primärsystemen in die Telematikinfrastruktur, das Management von Karten und Kartenterminals, Signaturfunktionen, Sicherheitsfunktionen und die offene Dienstvermittlung in Form eines Konnektors. Bei den einheitlichen Infrastrukturdiensten sind die SAVe-Dienste zu berücksichtigen.«ergänzend sind nach [IntAB04] die folgenden Fachanwendungen durch das FuE Projekt zu spezifizieren: - Arzneimittelverordnung (ohne BTM) - Arztbrief - Arzneimitteldokumentation - Unterstützung Notfallversorgung (Notfalldaten) 1.2 Einordnung des Dokuments in den Projektkontext Die mit diesem Dokument vorliegende erste Fassung der Spezifikation der Lösungsarchitektur stellt eine ganzheitliche, grobgranualare Sicht auf die Lösungsarchitektur dar und fasst die in weiteren Dokumenten noch zu beschreibenden Sichten und Spezifikationen zusammen. Davon ausgenommen ist die Spezifikation der egk (Teil 1-3), die zusammen mit der vorliegenden ersten Fassung der Spezifikation fertiggestellt wurde. 10

13 Einleitung Abbildung 1 Dokumente der Lösungsarchitektur Spezifikation der Lösungsarchitektur Anforderungen an die Lösungsarchitektur Dezentrale Komponenten IT-Spezifikation des Konnektors IT-Spezifikation der Gateways IT-Spezifikationen der Infrastrukturdienste Dienste der Telem atikinfrastruktur Fachlogische Modellierung IT-Spezifikationen der Verzeichnisdienste IT-Spezifikationen der Anwendungsdienste Karten und Kartenanwendungen Sicherheits- und Datenschutzkonzept IT-Spezifikation der egk (Teil 1-3) IT-Spezifikation der Sicherheitsarchitektur Netze und IT-Infrastruktur Glossar Die Ergebnisse des FuE-Projekts und das Formular zum Kommentierungsverfahren sind unter verfügbar. 11

14 Einleitung 1.3 Aufbau des Dokuments Die weiteren Kapitel dieses Dokuments sind inhaltlich wie folgt zuzuordnen: Kapitel 2 Leitlinien und Grundsätze Die auf Basis der Vorprojekte entwickelten Leitlinien und Grundsätze bilden einen übergeordneten, einheitlichen Bezugsrahmen für die Entscheidungsfindung innerhalb des Projekts und die Kommentierung durch die Gremien des FuE-Projekts. Kapitel 3 Anwendungen und Akteure der egk Das Kapitel 3 gliedert sich in zwei in enger Beziehung stehende Abschnitte. Aus den vom Gesetzgeber geforderten freiwilligen und Pflichtanwendungen der egk werden die maßgeblichen Anforderungen für die Ausgestaltung der Lösungsarchitektur abgeleitet. Die Sicht der Akteure im zweiten Teil bildet die Basis für die Modellierung der fachlogischen Geschäftsvorgänge, die von der Telematikinfrastruktur unterstützt werden. Kapitel 4 Spezifikation der Lösungsarchitektur In diesem Kapitel werden die zentralen Konzepte (Karten, Konnektor, Gateways, Zugriffs- und Integrationsschicht) der Lösungsarchitektur in einem Überblick dargestellt und in Beziehung zu Sicherheits- und Datenschutzanforderungen gesetzt. Kapitel 5 Spezifikation der Lösungskomponenten Die Grobspezifikationen der Komponenten der Lösungsarchitektur sowie der von ihnen erbrachten Dienste sind Gegenstand dieses Kapitels. Die Spezifikation des Konnektors und des Kartenterminals enstand im Rahmen des von der TU Wien durchgeführten Teilprojekts T-Stich Weitere Schwerpunkte sind die Spezifikationen der Accessund Service Gateways. Kapitel 6 Spezifikation der Zugriffs- und Integrationsschicht (ZIS) 12

15 Einleitung Die in diesem Kapitel beschriebene Zugriffs- und Integrationsschicht (ZIS) wird von den Anwendungsdiensten zur Verwaltung der Anwendungsdaten und der darauf geltenden Zugriffsrechte genutzt. Anwendungsdienst und ZIS sind die elementaren Bestandteile jeder Anwendungskomponente. Kapitel 7 Überblick über die Anwendungsdienste In diesem Kapitel wird ein Überblick über die Anwendungsdienste für die Pflicht- und freiwilligen Anwendungen (u. a. Versichertendaten-, Verordnungsdaten-, Arzneimitteldokumentations- und Notfalldatendienst) der egk gegeben. Kapitel 8 Spezifikation und Kartenmanagement der egk Die technische Spezifikation der elektronischen Gesundheitskarte besteht aus den folgenden vier Teilen, die in diesem Kapitel im Überblick dargestellt werden: Teil 1: Kommandos, Algorithmen und Funktionen der COS- Plattform Teil 2: Basis-Anwendungen und Funktionen Teil 3: Elektronisches Rezept, Teil 4: Freiwillige Anwendungen Weitere Themen dieses Kapitels sind die Produktion einer egk sowie das Einrichten, Sperren und Freigeben von Anwendungen. Kapitel 9 Spezifikation der Infrastrukturdienste In diesem Kapitel werden Infrastrukturdienste spezifiziert, die sowohl von den dezentralen Komponenten (Konnektor) als auch von den Anwendungsdiensten genutzt werden. Dazu gehören u.a. der Query- Transport- und OID-Dienst. Für jeden Dienst wird eine Bedrohungs- und Risikoanalyse durchgeführt. Kapitel 10 Literatur Verzeichnis aller der Spezifikation der Lösungsarchitektur zugrunde liegenden Standards sowie der sonstigen verwendeten Literatur 13

16 Einleitung Anhang A Allgemeines Abkürzungsverzeichnis, Tabellen- und Abbildungsverzeichnis Anhang B Anforderungen an die Lösungsarchitektur Überblick über die wesentlichen gesetzlichen, nichtfunktionalen und sich aus der Betrachtung von Sicherheitsaspekten ergebenden Anforderungen, sowie eine Zusammenfassung der maßgebliche Architeturentscheidungen aus den Vorprojekten Anhang C Zugriffsrechte Tabellarische Zusammenfassung der Zugriffsrechte einzelner Akteure (Rollen) auf die Operationen der egk- Anwendungen 1.4 Nicht betrachtete Aspekte Im Mittelpunkt der Betrachtungen bei der vorliegenden Spezifikation der Lösungsarchitektur standen die im 291a des SGB V [SGBV] beschriebenen Anwendungen. Hierbei gab es vielfältige Berührungspunkte zu anderen in diesem Umfeld stattfindenden Aktivitäten, zu denen in Abstimmung mit dem BMGS und der gemeinsamen Selbstverwaltung eine klare Abgrenzung getroffen wurde: - Abrechnungsvorgänge, die zwischen Leistungserbringern und Kostenträgern stattfinden, wurden bei der Spezifikation der Lösungsarchitektur nicht betrachtet. Im Rahmen der Anforderungserhebung wurde jedoch darauf geachtet, dass die Schnittstelle zwischen Primärsystem und Konnektor so gestaltet wird, dass eine Synchronisation mit Abrechnungsprozessen möglich ist. Auch die Verfügbarkeit von für Abrechnungen benötigten Informationen ist als Teil der fachlichen Anforderungen in der Spezifikation der Lösungsarchitektur berücksichtigt worden. - Die konkreten Informations- und Datenmodelle der Anwendungen sind Gegenstand der Arbeit in verschiedenen über das BMGS und/oder die gemeinsame Selbstverwaltung koordinierten Gremien. Für die Lösungsarchitektur wurden daher lediglich strukturelle Vorgaben für die Informationsmodelle der Anwendungsdaten spezifiziert, in die zwischen den Betroffenen noch abzustimmende konkrete Datenmodelle eingepasst werden können. 14

17 Einleitung - Die Migration von der aktuell verwendeten Krankenversichertenkarte zu der elektronischen Gesundheitskarte inklusive des schrittweisen Aufbaus der Telematikinfrastruktur wurde im Rahmen der Anforderungserhebung betrachtet. Es werden jedoch keine Vorgaben für den konkret zu wählenden Migrationspfad gemacht. Grundsätzlich sind Fragen der Migration sehr stark von organisatorischen Rahmenbedingungen geprägt und damit nicht Gegenstand des FuE-Projekts. - Die sich außerhalb der Telematikinfrastruktur befindenden externen IT- Systeme bei den Leistungserbringern des Gesundheitswesens (z. B. Primärsysteme) oder die IT-Systeme der Kostenträger (z. B. in Rechenzentren) werden im Rahmen des FuE-Projekts nicht betrachtet. 1.5 Status des FuE-Projekts Mit dem Vorliegen der ersten Fassung der Spezifikation der Lösungsarchitektur hat das FuE-Projekt einen wesentlichen Meilenstein erreicht. Die für die weitere Ausarbeitung und Verfeinerung der Projektergebnisse erforderliche vollständige Klärung konzeptioneller Fragen ist erfolgt. Die weitere Ausarbeitung u. a. der IT-Feinspezifikationen erfolgt wie schon die Spezifikation der Lösungsarchitektur unter Beteiligung von Vertretern der Selbstverwaltung und der Industrie. Für die Einbeziehung einer breiten Fachöffentlichkeit wird ein Kommentierungsverfahren durchgeführt. 15

18 Leitlinien und Grundsätze 2 Leitlinien und Grundsätze Die Erstellung der Lösungsarchitektur erfolgte unter Bezug auf eine Reihe von Leitlinien, die die in den Vorprojekten getroffenen Grundsatzentscheidungen aufnehmen und weiterentwickeln. Damit existiert ein übergeordneter, einheitlicher Bezugsrahmen für die Entscheidungsfindung innerhalb des Projekts und die Kommentierung durch die Gremien des FuE-Projekts. Insbesondere die kritische Auseinandersetzung mit den in der Anlage zum Solution Outline [b4hsoloutl] beschriebenen Architekturentscheidungen beeinflusste die Erstellung der nachfolgenden Leitlinien maßgeblich. 2.1 Patientenorientierung und Datenhoheit Die Datenhoheit der in der Telematikinfrastruktur übertragenen und gespeicherten personenbezogenen Daten liegt beim Versicherten. Der Versicherte ist»herr seiner Daten«und bestimmt über deren Verwendung. Durch die egk und deren Anwendungen darf für die Patienten keine Erschwerung bei der Inanspruchnahme von Leistungen des Gesundheitswesens entstehen. Die Kontrolle des Informationsflusses und der Zugriffsrechte auf medizinische Daten durch den Versicherten muss sichergestellt sein. Die Rechte des Versicherten (Auskunftsrecht, Sperrung und Löschung) von Daten sind konzeptionell zu berücksichtigen und durch geeignete technische Maßnahmen abzusichern. 2.2 Übertragung von Daten Der Telematikinfrastruktur für die Anwendungen der egk liegt eine Kommunikationsinfrastruktur zu Grunde, die auf das Internet aufsetzt. Die Aufgabe der Telematikinfrastruktur ist das Verfügbarmachen, die Übertragung und (temporäre) Speicherung von personenbezogenen medizinischen Daten für bzw. zwischen Beteiligten im Gesundheitswesen. 16

19 Leitlinien und Grundsätze Jedliche Speicherung von Daten innerhalb der Telematikinfrastruktur darf nur unter Berücksichtigung von Sicherheitsrichtlinen erfolgen. 2.3 Integration von externen Systemen Die Anbindung von externen Systemen an die Telematikinfrastruktur muß mit minimalen Anpassungen an diesen Systemen über einheitliche Komponenten und Schnittstellen möglich sein. 2.4 Anwendungsübergreifend einheitliche Lösungen Alle Anwendungen sollen möglichst gleichartig strukturiert sein, um ein Höchstmaß an Wiederverwendung von Lösungskomponenten zu erreichen und Sicherheits- und Infrastrukturdienste skalierbar gestalten zu können. 2.5 Technologie- und Produktneutralität Die im Rahmen des FuE-Projekts erstellten IT-Grob- und Feinspezifikationen ermöglichen einen diskriminierungsfreien Wettbewerb unterschiedlicher Anbieter von Komponenten und Dienstleistungen für die Telematikinfrastruktur. 2.6 Verwendung von Standards und erprobten Konzepten Für die Lösungsarchitektur der Telematikinfrastruktur werden existierende Produkte sowie nationale und internationale Standards wo immer sinnvoll und möglich berücksichtigt und übernommen. Existierende stabile Produkte und Standards sind für eine zeitgerechte Einführung zu verwenden. 2.7 Migrationsfähigkeit und Skalierbarkeit Die egk muss als Basisfunktionalität das Nachladen von Applikationen und damit die Nutzung neuer Anwendungsdienste ermöglichen. Die derzeitigen papierbasierten Prozesse (mit Medienbrüchen) müssen in geeigneter Form als Ersatz- bzw. Notfallmaßnahmen auch zukünftig durchführbar sein. 17

20 Anwendungen und Akteure der egk 3 Anwendungen und Akteure der egk Aus den vom Gesetzgeber geforderten freiwilligen und Pflichtanwendungen der egk werden in diesem Kapitel die maßgeblichen Vorgaben für die Ausgestaltung der Lösungsarchitektur abgeleitet. Insbesondere von den freiwilligen Anwendungen wird eine Verbesesserung der Qualtiät der gesundheitlichen Versorgung und eine Stärkung der Eigenverantwortung des Versicherten durch die Verfügbarmachung von Gesundheitsdaten erwartet. Die im zweiten Teil vorgestellten Akteure der egk stehen in einem engen Zusammenhang mit den Anwendungen. Die Sicht der Akteure bildet die Basis für die Modellierung der fachlogischen Geschäftsvorgänge, die von der Telematikinfrastruktur unterstützt werden. Eine vom FuE-Projekt durchgeführte detaillierte Modellierung der wesentlichen Geschäftsvorgänge ist im Ergebnisdokument»Fachlogische Modellierung und spezfische Anwendungsdienste der Gesundheitskarte«[eGK-FachlModAnw] enthalten. 3.1 Pflichtanwendungen Die Pflichtanwendungen der egk sind die Anwendungen, die sich insbesondere auf die administrativen Daten des Versicherten sowie die Übermittlung ärztlicher Verordnungen beziehen ( 291a Abs. 2 SGB V/GMG) Arzneimittelverordnung Das GKV-Modernisierungsgesetz schreibt vor, dass mit der elektronischen Gesundheitskarte die Übermittlung ärztlicher Verordnungen in elektronischer und maschinell verwertbarer Form möglich sein muss. Die Arzneimittelverordnung stellt als häufigster Vorgang im Zusammenhang mit medizinischer Behandlung für die Versicherten den am deutlichsten erkennbaren Fortschritt bei der Einführung der egk dar. Für die Versicherten wird die elektronische und damit für ihn zunächst unsichtbare Weitergabe der Verordnungsdaten vom verordnenden Arzt zum einlösenden Apotheker damit zum Inbegriff der egk werden. Die Akzeptanz der egk bei den Versicherten hängt damit wesentlich von der Unterstützung und Optimierung aller ihm bekannten Abläufe rund um die Verschreibung ab. Insbesondere die Möglichkeit der Einlösung in Abwesenheit des Versicherten und die Sicherstellung der Dispensierung bei Störungen der beteiligten Systeme stellen in diesem Kontext wesentliche Anforderungen an die Telematikinfrastruktur. Es ist sicherzustellen, dass der Versicherte eine dem jetzigen Zustand entsprechende Vertraulichkeit der Daten erreichen kann. Diese werden durch die Möglichkeiten des selektiven Versteckens von Verordnungen gewährleistet. 18

21 Anwendungen und Akteure der egk Für die Kostenträger stehen die Optimierung der Abläufe und die damit erreichbare Kostenreduktion im Vordergrund. Durch die Nutzung eines vollständig elektronisch unterstützten Prozesses von der Ausstellung über den Transport bis zur Einlösung und Abrechnung einer Arzneimittelverordnung wird aus Sicht der Kostenträger das Maximum an Einsparpotenzial realisiert. Aus Sicht der Leistungserbringer stehen die Funktionen an den Schnittstellen zu den Primärsystemen im Vordergrund. Dafür ist die nahtlose Anschlussfähigkeit der für die Arzneimittelverordnung definierten Prozesse an die betrieblichen Abläufe und deren Unterstützung durch die entsprechenden Systeme (PVS, AVS, KIS) maßgeblich. Die Risiken, die sich durch dem möglichen teilweisen oder vollständigen Ausfall der Telematikinfrastruktur ergeben können, sind zu berücksichtigen (Rückfall auf papierbasierte Prozesse) Versichertenstammdaten Aus Sicht des Versicherten geht die egk kartenseitig nur unwesentlich über die derzeit realisierte Lösung hinaus. Die Konsequenzen für den Behandlungsprozess sind als marginal anzusehen. Neu sind die Realisierung der Prozesse, die einen automatischen Abgleich der Stammdaten zwischen Primärsystemen und Infrastruktur erlauben. Hierdurch werden die Missbrauchsmöglichkeiten wesentlich eingeschränkt. Als Pflichtanwendung der Überprüfung eines gültigen Versicherungsschutzes sind hiervon vor allem die Prozesse bei den Leistungserbringern berührt. Die routinemäßige Überprüfung des Versichertenstatus stellt einen, gegenüber heutiger Praxis, zusätzlichen Schritt dar, der durch entsprechende Dienste der Infrastruktur und der sie nutzenden Erweiterung der Primärsysteme im Standardfall vollständig automatisiert ablaufen kann. Auch für die Kostenträger bedeutet die Einführung dieser routinemäßigen Überprüfung zusätzliche Investitionen in die Erweiterung ihrer Systeme. Gemessen an dem durch missbräuchliche Verwendung der Versichertenkarten jetzt entstehenden Schaden, ist jedoch die Unterstützung des Versichertenstatus als wesentlicher Fortschritt anzusehen. 3.2 Freiwillige Anwendungen Neben diesen beiden Anwendungen schreibt der Gesetzgeber in 291a, Abs. 3 sowie 305, Abs. 2 SGB V/GMG eine Reihe weiterer Anwendungen vor, die nicht unmittelbar umzusetzen sind, deren Realisierungsanforderungen jedoch in der Spezifikation der egk und der unterstützenden Telematikinfrastruktur berücksichtigt werden müssen. Es sind dies: - Speicherung von Notfalldaten Hierzu gehören die Angaben zu Vor- und chronischen Erkrankungen, 19

22 Anwendungen und Akteure der egk Allergien und Unverträglichkeiten, laufende Behandlungen etc. des Versicherten. Eine vollständige Dokumentation der in medizinischen Notfällen relevanten Daten und die Möglichkeit einer möglichst auch mobilen Nutzung durch behandelnde Ärzte kann zu einer deutlichen Verbesserung der Notfallbehandlungen beitragen. - Elektronischer Arztbrief Analog zu der Diskussion der elektronischen Arzneimittelverordnung ist die elektronische Übermittlung von Befunden, Diagnosen, Therapien, Konsilen etc. zur Unterstützung der behandlungsbegleitenden Abläufe vorgesehen. Damit ist zunehmend die Möglichkeit der sektorenübergreifenden Integration im Gesundheitswesen geschaffen. - Arzneimitteldokumentation Durch die dauerhafte Dokumentation der Medikamentation wird eine Optimierung der Behandlung von insbesondere chronisch Kranken erwartet. Die Arzneimitteldokumentation ist eine Grundlage für die teilautomatisierten Unverträglichkeits- und Kontraindikationsprüfungen. - Patientenakte Mit Blick auf eine aufwands- und qualitätsorientierte sektorenübergreifende Integration perspektivisch aller medizinischen Sektoren gewinnt eine überall zugreifbare und von allen beteiligten Heilberuflern sowie in Teilen auch vom Patienten selbst fortgeschriebene Patientenakte weitreichende Bedeutung. Die hierfür notwendigen Basisfunktionen zur Speicherung von medizinischen Daten und zum patientenkontrolliertem differenzierten Zugriff auf diese sind bei der Spezifikation zu berücksichtigen. - Patientenquittung Zur Erhöhung der Kostentransparenz und mit dem Ziel eines entsprechend kostenbewussten Umgangs sollen auch die in Anspruch genommenen Leistungen dokumentiert werden können. Diese Dokumentation hat engen Bezug zur Pflichtanwendung Arzneimittelverordnung. Zentral für alle diese Anwendungen ist, dass die für sie notwendigen Daten gemäß Gesetz erst dann erhoben, verarbeitet und genutzt werden dürfen, wenn der/die Versicherte hierzu jeweils gegenüber dem Arzt, Zahnarzt oder Apotheker dazu seine/ihre Einwilligung gegeben haben. Diese Einwilligung ist bei der ersten Verwendung der Karte vom Leistungserbringer auf der Karte zu dokumentieren. Diese gesetzlich festgeschriebene Hürde entspricht dem hohen Sicherheitsbedürfnis und Vertraulichkeitsanspruch, den Versicherten mit Bezug auf ihre medizinischen Daten haben. Die Erfüllung dieser Ansprüche hat damit höchste Priorität, da andernfalls die Akzeptanz für die freiwillligen Anwendungen für eine breite Einführung zu gering sein dürfte. Im positiven Fall stellen diese Anwendungen für die Versicherten eine maßgebliche Unterstützung der Behandlungsprozesse dar. Dies gilt insbesondere für 20

23 Anwendungen und Akteure der egk komplexere und chronische Krankheiten, bei denen sektorenübergreifend eine Vielzahl von Heilberuflern beteiligt ist. Für die Leistungserbringer stellen die freiwilligen Anwendungen unmittelbar eine Reduktion der Aufwände für die Beschaffung und den Versand von medizinischen Informationen dar. Mittelbar ermöglichen diese Anwendungen jedoch eine Reduktion der Prozesskosten, sowohl intern (z. B. durch eine Verschlankung der Aktenführung) als auch sektorenübergreifend. (Optimierung der Informationsflüsse). Mit der damit erwartbaren Verbesserung der Informationsqualität ist eine Verbesserung der Behandlungsprozesse erreichbar. Für die Leistungserbringer stellt die bessere Verfügbarkeit einer vollständigen Krankenakte einen Schritt in Richtung effizienterer fallbezogener Kooperation dar, der das Risiko von Behandlungsfehlern reduziert. Sowohl hierdurch als auch aufgrund der Reduktion von»reibungsverlusten«an den Sektorengrenzen steht für die Kostenträger durch die Einführung der freiwilligen Anwendungen eine Verringerung der fallbezogenen Aufwände zu erwarten. Die genaue Ausgestaltung der für diese freiwilligen Anwendungen notwendigen höherwertigen Dienste kann erst nach der Einführung und Erprobung der egk sowie flankiert durch die Entwicklung integrierter Versorgungsmodelle geschehen. Allerdings lassen sich aus den benannten freiwilligen Anwendungen folgende Anforderungen für die elektronische Gesundheitskarte und die unterstützende Telematikinfrastruktur ableiten, die in der Konzeption berücksichtigt wurden. - Medizinische Daten müssen zumindest für die Notfallversorgung auf der Karte gespeichert werden können, - medizinische Daten müssen aufgrund des zu erwartenden Volumens (z. B. Röntgenbilder als Teil der Patientenakte) auf Servern gespeichert werden können, wobei der Zugriff über die elektronische Gesundheitskarte erfolgt, - Versicherte müssen in der Lage sein, eigene Daten auf der Karte bzw. einem Server abzulegen, mit Zugriffsrechten zu schützen sowie Daten und Rechte zu pflegen, - über das generische, auf Standesgruppen ausgerichtete Rechtemanagement hinaus ist ein individuelles Rechtemanagement zu realisieren, das sowohl einzelne Daten als auch einzelne Leistungserbringer berücksichtigt, - Einwilligungserklärungen müssen von Leistungserbringern geschrieben und von Versicherten widerrufen werden können. 21

24 Anwendungen und Akteure der egk 3.3 Akteure Akteure bilden die Basis für die Modellierung der fachlogischen Geschäftsvorgänge, die von der Telematikinfrastruktur unterstützt werden. Alle Aktionen werden entweder von einem menschlichen Akteur oder einem System durchgeführt. Die Akteure stehen untereinander in Beziehung und können in vielen Fällen als Rollenbezeichnung verwendet werden. Die folgenden drei Abschnitte geben eine Gesamtübersicht. Auf wesentliche Akteure wird dabei im Detail eingegangen Versicherte und Versicherungen Abbildung 2 Akteure - Versicherte und Versicherungen << zu ge ordn et >> Person Kartenherausgeber Kartenproduzent Vertretung Vertrag Krankenversicherer <<zugeordnet>> Vertreter/in Versicherte/r Mitarbeiter/in Kostenträger PKV GKV Administrator/in Kostenträger Kundenbetreuer/in Kostenträger Versicherte Versicherte sind Personen, die in einem Vertragsverhältnis mit dem Krankenversicherer stehen und dadurch Leistungen des Gesundheitswesens in Anspruch nehmen können. Für die Versicherten soll die elektronische Gesundheitskarte mehr Transparenz und Qualität in der Gesundheitsversorgung bei gleichzeitig reduzierten Kosten und effizienterer Kommunikation mit Leistungserbringern und Kostenträgern bringen. Die Versicherten sind in erster Linie Personen und können durch andere Personen vertreten werden (siehe Abbildung 2). Die rechtliche Manifestation dieser Vertretung ist für die hier untersuchten Vorgänge nicht von Bedeutung, da keine Überprüfung mit den Hilfsmitteln der Gesundheitstelematik gefordert ist. Jeder Versicherte ist einer Versicherung zugeordnet, von der er seine Gesundheitskarte ausgestellt bekommt. Wenn er noch weitere Versicherungen oder Versorgungsansprüche hat, werden diese auf andere Weise nachgewiesen. 22

25 Anwendungen und Akteure der egk Versicherung Die Kostenträger, aktuell sind nur Versicherungen betrachtet, werden nach Gesetzlichen und Privaten Krankenversicherern unterschieden (siehe Abbildung 2). In den betrachteten Abläufen kann diese Unterscheidung meist entfallen, da sich nur im Bereich der Abrechnung der Verordnungen veränderte Abläufe ergeben, die aber außerhalb der Betrachtung liegen. Die Kostenträger fungieren auch als Herausgeber der egk, wobei sich aber auch mehrere Versicherungen zusammenschließen können, um die Herausgabe der Karten zusammenzufassen. Ein Kartenproduzent wird vom Herausgeber der egk mit der Produktion beauftragt. Eine feste Bindung an einen Kartenproduzenten ist nicht notwendig, im Prinzip können auch mehrere Produzenten vom gleichen Herausgeber beauftragt werden Leistungserbringer Die Leistungserbringer (siehe Abbildung 3) werden danach unterschieden, ob sie Verordnungen ausstellen oder einlösen, da diese beiden Teilprozesse wesentlich vom Einsatz der egk beeinflusst werden. Abbildung 3 Akteure - Leistungserbringer <<vertritt>> Leistungserbringer/in Ve rordn ung se in lö ser/in Krankenhaus <<zugeordnet>> <<zugeordnet>> <<zugeordnet>> Apotheker/in Sonstige Leistungserbringer/in Zahnarzt/ärztin Arzt/Ärztin Medizinisches PersonalAufnahmepersonal Krankenhaus <<zugeordnet>> <<zugeordnet>> <<zugeordnet>> Pharmazeutisches Personal Zahnarzthelfer/in Arzthelfer/in 23

26 Anwendungen und Akteure der egk Die Krankenhäuser werden gesondert betrachtet, da hier sehr viele unterschiedliche Konstellationen möglich sind. Ein Krankenhaus tritt auch nie direkt auf, sondern wird durch die dort beschäftigten Personen repräsentiert. Es sei noch angemerkt, dass Einzelpersonen in besonderen Situationen auch abwechselnd wie Verordnungsaussteller und Verordnungseinlöser agieren können. Dies ist z. B. der Fall, wenn ein Arzt zusätzlich als Physiotherapeut zugelassen ist und auch für andere Ärzte Patienten behandelt. Das entsprechende Primärsystem muss dann alle Funktionen unterstützen, die ein Arzt und ein Physiotherapeut benötigt, und unterscheiden, in welcher Rolle die Person das System nutzt Primärsysteme Abbildung 4 Akteure Primärsysteme Primärsystem PC/Kiosk VVS PVS ZP VS AVS KIS Kartenleser (Autonom) Die Primärsysteme stellen die Anwendungsprogramme für die Leistungserbringer und Versicherungen zur Verfügung. Die Primärsysteme der Leistungserbringer werden für die Einführung der Gesundheitstelematik mit einem Konnektor erweitert, der den Zugang zur Telematik und die Behandlung der Karten realisiert. Aus fachlicher Sicht, also für die Personen die Leistungen mit Hilfe der Telematik erbringen oder in Anspruch nehmen, sind aber nur die Oberflächen und damit die Primärsysteme relevant. Daher sind in den Modellen auch immer nur die Primärsysteme als Akteure vorhanden. Viele Funktionen sind über alle Primärsysteme identisch und dieses wird über eine Generalisierung im Modell realisiert (siehe Abbildung 4). Die Primärsystemhersteller müssen ihre Systeme so anpassen, dass die in den Geschäftsvorgängen identifizierten Fachdienste umgesetzt werden. Allerdings sollte auch die Benutzerführungen an die Prozessveränderungen angepasst werden. 24

27 Anwendungen und Akteure der egk Betreiber Die Betreiber von Diensten und Kommunikationsinfrastrukturen sind wesentliche Akteure innerhalb der Telematik. Da aber zum aktuellen Zeitpunkt noch keine Betreibermodelle vorliegen und daher auch noch keine Geschäftsvorgänge untersucht werden konnten, sind diese in den Modellen nicht vorhanden. 25

28 Lösungsarchitektur 4 Spezifikation der Lösungsarchitektur In der Lösungsarchitektur zur Unterstützung der Anwendungen der elektronischen Gesundheitskarte sind die die Infrastruktur aufspannenden Komponenten und Dienste in ihrer Funktion, ihren Schnittstellen, ihren nichtfunktionalen Anforderungen und ihrem Zusammenspiel spezifiziert. In diesem Kapitel wird die Lösungsarchitektur im Überblick beschrieben. Hierzu wird zunächst der Aufbau der Infrastruktur mit ihren wesentlichen Lösungskomponenten skizziert. Wesentlich für die Ausgestaltung der Lösungskomponenten und deren gegenseitige Dienstenutzung ist die Einhaltung eines übergreifenden Sicherheits- und Datenschutzkonzepts. Aus den dem Sicherheitskonzept zugrunde liegenden Sicherheitszonen und den Schutzbedarfen der Anwendungen (und ihrer Daten) lassen sich Anforderungen an die Notwendigkeit der Nutzung von Sicherheitsdiensten sowie Vorgaben für die Verteilung von Komponenten und Diensten innerhalb der Telematikinfrastruktur ableiten. Schutzbedarfe, Sicherheitsanforderungen und Sicherheitsdienste sind Gegenstand von Abschnitt 4.1. Eng verknüpft mit Fragen der Sicherheit und des Datenschutzes sind die folgenden drei wichtigen, die Konzeption und Spezifikation der gesamten Infrastruktur wesentlich prägenden, Lösungskonzepte des FuE-Projekts: 1. Aufteilung der Telematikinfrastruktur in Sicherheitszonen, die gekapselte Einheiten mit exakt definierten Schnittstellen darstellen 2. Herstellung eines sicheren Zugangs zu serverbasierten Diensten für eine geschlossene Nutzergruppe über eine durch Access und Service Gateways abgesicherte Kommunikationsinfrastruktur (siehe Abschnitt 4.3) 3. Verwaltung von Anwendungsdaten über ein virtuelles, ticket-basiertes Dateisystem, über das anwendungsübergreifend einheitlich Zugriffsrechte auf Daten verwaltet und (berechtigte) Zugänge zu Daten hergestellt werden (siehe Abschnitt 4.4) Ziel dieses Kapitels ist es, verschiedene Sichten auf die Lösungsarchitektur darzustellen, die statische Aufbauten und dynamische Abläufe in ganzheitlich ausgerichteten Darstellungen zusammenführen sollen. Hierdurch soll der Rahmen aufgespannte werden, in den sich die in den Kapiteln 5 bis 9 im Detail beschriebenen Lösungskomponenten und Dienste einordnen. 26

29 Lösungsarchitektur 4.1 Gesamtübersicht Lösungsarchitektur Um eine Gesamtübersicht über die Lösungsarchitektur zu geben, werden zunächst die Systemgrenzen der Telematikinfrastruktur schematisch dargestellt. Anschließend wird grob ihre interne Struktur skizziert. Das funktionale Zusammenspiel ihrer Komponenten wird am Beispiel des elektronischen Rezeptes verdeutlicht. Schließlich gibt eine klassifizierte Auflistung aller Dienste einen Ausblick auf die folgenden Kapitel Systemgrenzen der Telematikinfrastruktur Abbildung 5 stellt die Systemgrenzen und wesentlichen Bausteine der Lösungsarchitektur in einer schematischen Übersicht dar. Die von der Lösungsarchitektur spezifizierte Telematikinfrastruktur erstreckt sich dabei über alle Lösungskomponenten, die unter einer einheitlichen Sicherheitspolicy und auf Basis der in der Lösungsarchitektur spezifizierten Schnittstellen und Vorgaben betrieben werden müssen. Abbildung 5 Schematische Darstellung der Systemgrenzen der Telematikinfrastruktur Telematikinfrastruktur Primärsysteme Kommunikationsinfrastruktur Anwendungsdienste Medizinische und personenbezogene Daten bei Krankenkassen, KVen und anderen Daten- und Diensteanbietern Heim-PCs Zugangspunkte bei Leistungserbringern, an ekiosken und PCs ekioske Dienste und Verzeichnisse zur Konfiguration und zum Betrieb der Telematikinfrastruktur Infrastruktur- Dienste Wesentliche Aufgabe der Telematikinfrastruktur ist die Bereitstellung von medizinischen Datenobjekten (erezepte, Arzneimitteldokumentation, Eintrag aus der Patientenakte etc.) zur Nutzung im Rahmen des Gesundheitsversorgungssystems. Diese Daten können sowohl innerhalb der Telematikinfrastruktur als auch außerhalb verwaltet werden. Maßgeblich für diese Unterscheidung sind dabei keine technologischen Aspekte, sondern Fragen der Datenhoheit und der Sicherheitspolicy. Anwendungsdaten, die unter den in der Lösungsarchitektur spezifizierten Sicherheitsrichtlinien und mit 27

30 Lösungsarchitektur Hilfe der die Vorgaben des 291a abbildenden Zugriffsschutzmechanismen betrieben werden und die in der Datenhoheit des Versicherten stehen, sind innerhalb der Telematikinfrastruktur anzusiedeln. Anwendungsdaten, die nur über die Telematikinfrastruktur bereitgestellt und transportiert werden, aber ansonsten in der Hoheit eines Betreibers liegen und eigenen Schutzzielen und -mechanismen unterliegen, sind außerhalb der Telematikinfrastruktur angesiedelt. Medizinische Datenobjekte sind immer einer Anwendung (erezept, epatientenakte, earztbrief etc.) zugeordnet. Ein Zugang zu den Daten ist immer nur über einen sog. Anwendungsdienst möglich, der ein anwendungsspezifisches Rechtemanagement auf Basis der in 291a definierten Rahmenbedingungen realisiert und über die reine Datenbereitstellung hinausgehende Dienste anbieten kann. Die Nutzung der Daten und darauf aufbauenden Dienste geschieht durch die Leistungserbringer (Ärzte, Apotheker, etc.) und deren Primärsysteme (PVS, AVS, KIS). Versicherten wird über ekioske und PCs ein Zugang zu den über sie gespeicherten Daten ermöglicht. Eine besondere Bedeutung kommt dabei dem ekiosk zu, der durch die Aufstellung in einem öffentlichen Raum und die Möglichkeit der PIN-Authentifizierung des Versicherten für die Ausführung besonders sicherheitskritischer Funktionen wie z. B. der Vergabe und dem Entziehen von Zugriffsrechten für einzelne Leistungserbringer geeignet ist. Bedingt durch diese Sonderrolle muss der ekiosk im Gegensatz zu den Primärsystemen der Leistungserbringer und der Hard- und Software zum Zugang vom heimischen PC aus kontrollierbar unter den Sicherheitsrichtlinien der Telematikinfrastruktur und letztendlich auch unter der Hoheit des Betreibers der Telematikinfrastruktur angesiedelt sein. Alle auf die Anwendungsdienste zugreifenden Systeme sind über Zugangspunkte (Access Points) an eine Kommunikationsinfrastruktur angebunden, die den sicheren Transport von medizinischen Datenobjekten zwischen den diese Daten anbietenden bzw. verwaltenden Einrichtungen und den die Daten nutzenden Leistungserbringern und Versicherten realisiert. Zugangspunkte koordinieren die Kommunikation mit den angebundenen Kartenterminals und den über die Kommunikationsinfrastruktur angebotenen (Anwendungs-)Diensten und stellen die Kommunikationsverbindung zur Kommunikationsinfrastruktur her. Die Kommunikationsinfrastruktur bildet ein in sich abgeschlossenes Netz. Die Zugänge zu diesem Netz sind über so genannte Gateways gesichert, die auf Seiten der Datennutzer die Zugangsberechtigung eines Zugangspunkts feststellen und auf Seiten der Datenanbieter die grundsätzliche Nutzungsberechtigung eines Anwendungsdienstes prüfen. Zur sicheren Nutzung der Anwendungsdienste wird eine Reihe von unterstützenden Infrastrukturdiensten benötigt, die z. B. die Lokalisierung von 28

31 Lösungsarchitektur Diensten und die Authentifizierung von Leistungserbringern realisieren. Infrastrukturdienste kapseln vor allem Verzeichnisdienste, die vom Betreiber der Telematikinfrastruktur bereitgestellt werden, und dezentralisieren damit die Zugriffe auf Verwaltungsinformationen wie z. B. Dienste- und Zertifikatslisten. Diese Verzeichnisdienste sowie einige Wurzeldienste (d. h. Dienste, die nur von abgeleiteten Diensten genutzt werden) werden vom Betreiber der Telematikinfrastruktur bereitgestellt Grobarchitektur Die nachfolgende Abbildung 6 stellt die Grobarchitektur der Telematikinfrastruktur dar. Hierbei ist dargestellt, wie die grundsätzlichen Lösungskonzepte durch Komponenten und Dienste umgesetzt werden. Abbildung 6 Übersicht über die Lösungsarchitektur Dienstenutzer Telematikinfrastruktur Diensteanbieter Primärsystem Praxis / Krankenhaus Primärsystem Apotheken ekiosk Konnektor egk HBA/SMC Konnektor egk HBA/SMC Access Gateway Access Gateway Kommunikationsinfrastruktur VPN Arzt Infrastrukturdienste VPN Apotheker Infrastrukturdienste Service Gateways Service Gateways VSDD VODD ZIS ZIS Anwendungsdienste KAMS Kostenträger Konnektor Access Gateway VPN Kiosk Service Gateways epa ZIS Versicherter@Home egk SMC Zugangssoftware Portal Konnektor Access Gateway VPN Versicherter@Home Service Gateways Anwendungsdienste Bestandssystem egk SMC Gematik Gateway Wurzeldienste Verzeichnisdienste 29