Seminar zum Thema. egovernment. Schwerpunkt: bit4health Projekt

Transkript

1 Seminar zum Thema egovernment Schwerpunkt: bit4health Projekt Vorgelegt der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität Fribourg von Jacqueline Wanner eingereicht bei Prof. Dr. Andreas Meier Research Group Information Systems Universität Fribourg Jacqueline Wanner Neumattstrasse Dulliken

2 Abbildungs- /Abkürzungsverzeichnis I Inhaltsverzeichnis I Inhaltsverzeichnis...I II Abbildungsverzeichnis...II III Abkürzungsverzeichnis...II 1 Einleitung Zugrundeliegende Begriffe Chronologie Ziele Aufgaben von bit4health Arbeitspaket Arbeitspaket UAP 1: Akzeptanzbildung UAP 2: Projektmanagement UAP 3: Qualitätssicherung UAP 4: Wissenschaftliche Begleitung sowie Kosten-Nutzen-Analyse UAP 5: Begleitung des ersten Jahres der Betriebsphase Rahmenarchitektur RM-ODP Entwurfsprinzipien der Rahmenarchitektur Verwendung der Rahmenarchitektur Umsetzung der Rahmenarchitektur Sicherheitsinfrastruktur Datenschutz und Datensicherheit Grundlegende Sicherheitsanforderungen Festlegungen der Rahmenarchitektur Lösungsarchitektur Erstellung einer Lösungsarchitektur Testvorhaben Fazit...18 IV Bibliographie I

3 Abbildungs- /Abkürzungsverzeichnis II Abbildungsverzeichnis Abbildung 1 Abbildung 2 egk als Basis für patientenorientierte Dienstleistungen Reference Model Open Distributed Processing (RM-ODP) III Abkürzungsverzeichnis BMGS EGK GKV GMG HBA ISO KVK RM-ODP SAGA UAP Bundesministerium für Gesundheit und Soziale Sicherung Elektronische Gesundheitskarte Gesetzliche Krankenversicherung Gesetz zur Modernisierung der Gesetzlichen Krankenversicherung Heilberufsausweis International Standardisation Organization Krankenversichertenkarte Reference Model of Open Distributed Processing Standards und Architekturen für egovernment-anwendungen des Bundesministeriums des Innern Unterarbeitspaket II

4 Einleitung 1 Einleitung Zur Unterstützung des Projekts Elektronische Gesundheitskarte (egk) 1 wurde in Deutschland vom Bundesministerium für Gesundheit und Soziale Sicherung nach einer europaweiten Ausschreibung ein Projektkonsortium bestehend aus den Firmen IBM Deutschland GmbH, dem Fraunhofer-Institut für Arbeitswissenschaft und Organisation (IAO), der SAP Deutschland AG & Co KG, der InterComponentWare AG und der ORGA Kartensysteme GmbH beauftragt. Am 3. September 2003 fand das Kickoff-Meeting für das Projekt bit4health bessere IT für bessere Gesundheit statt. Zunächst werden in den folgenden Unterkapiteln die zugrundeliegenden Begriffe erklärt und die Chronologie und die Ziele des Projekts aufgezeigt. Im zweiten Kapitel dieser Arbeit wird näher auf die Aufgaben des bit4health Projektteams eingegangen, welche in verschiedene Arbeitspakete unterteilt sind. Weiter werden die Sicherheitsinfrastruktur und die Rahmenarchitektur detaillierter besprochen, welche zum fünften Kapitel, der Lösungsarchitektur, überführen. Zur detaillierten Betrachtung dieses Projekts erscheint es sinnvoll, zunächst einige zugrundeliegende Begriffe zu klären. 1.1 Zugrundeliegende Begriffe Die egk verbindet als elektronischer Schlüssel alle Beteiligten des Gesundheitswesens: 70 Millionen Krankenversicherte mit rund Ärzten, Zahnärzten, 2000 Krankenhäusern, Apotheken und 300 Krankenkassen. Sie ist daher untrennbar mit dem Aufbau einer vertrauenswürdigen und flächendeckenden Informations- und Kommunikationsinfrastruktur verbunden. Basis dafür ist eine bundesweit einheitliche Telematik- Rahmenarchitektur, die Schnittstellen, Standards, Anwendungen, Initiativen und Projekte für den Einsatz der Gesundheitskarte beinhaltet. Die Rahmenarchitektur von bit4health gibt basierend auf den gesetzlichen Vorgaben die Leitlinien für die Implementierung der Funktionen der egk und der unterstützenden technischen Infrastruktur vor. Sie bildet den, einem Bebauungsplan ähnlichen Rahmen, innerhalb dessen 1 Für Details zur egk verweise ich auf das Paper von Emanuel Stoll 1

5 Einleitung sich die Einzellösungen der Telematik im Gesundheitswesen bewegen können und müssen. Dazu liefert sie eine modellhafte Sicht auf ein komplexes Gesamtsystem. In der Lösungsarchitektur der egk erfolgt an Hand der in der Rahmenarchitektur vorgegebenen Regeln die Beschreibung der Telematik-Infrastruktur. Ähnlich des für den Bau eines Hauses notwendigen Detailplans findet hier die konkrete Beschreibung der Lösung statt. Die tatsächliche Umsetzung der Rahmenarchitektur in eine Lösungsarchitektur ist eine Aufgabe, die im Konsens mit Selbstverwaltung, Wissenschaft und Industrie durchgeführt werden muss Chronologie Im Oktober 2003 wurde das GKV-Modernisierungsgesetz (GMG) verabschiedet, das die gesetzliche Grundlage für die Einführung der egk in Deutschland bildet. Wesentlicher Inhalt dieses Gesetzes ist die Verpflichtung der gesetzlichen Krankenkassen, allen Versicherten bis zum eine egk zur Verfügung zu stellen. Im März 2004 wurde die Rahmenarchitektur termingerecht durch bit4health übergeben, im Juli 2004 wurde die Solution Outline (Lösungsansätze basierend auf der Rahmenarchitektur) veröffentlicht. Seit anfang 2005 werden die Gesundheitskarten nun in verschiedenen Testregionen auf ihre Tauglichkeit überprüft Ziele Das Ziel des Projekts bit4health ist es, die bundesweite Einführung der egk vorzubereiten, welche die bisherige Krankenversichertenkarte (KVK) ablöst. Die KVK wird durch die egk ersetzt, weil sie eine geringere Speicherkapazität hat und mit ihr keine sensiblen medizinischen Daten übermittelt werden können. Die egk sorgt dafür, dass alle benötigten Gesundheitsdaten jederzeit überall verfügbar, zugleich aber auch geschützt sind. Damit werden für die Patienten belastende und zeitraubende Doppel- und Mehrfachuntersuchungen reduziert. Die Therapie kann schneller beginnen, im Notfall Leben retten. Die Gesundheitskarte wird technisch so weiterentwickelt sein, dass sie in der Lage ist, neben ihren administrativen Funktionen auch Gesundheitsdaten verfügbar zu machen. Mit der Einführung der Gesundheitskarte will man die Wirtschaftlichkeit und die Qualität des 2 siehe Glossar des Projektes bit4health 3 Siehe Chronologie der egk 2

6 Einleitung Gesundheitswesens in Deutschland nachhaltig steigern. Dies bedeutet eine Verbesserung der Qualität der medizinischen Versorgung, eine Verbesserung von patientenorientierten Dienstleistungen und die Stärkung der Eigenverantwortung, Mitwirkungsbereitschaft und Eigeninitiative der Patienten. Um dies zu erreichen, muss die elektronische Gesundheitskarte bis zu diesem Zeitpunkt technisch geeignet sein, Authentifizierung, Verschlüsselung und elektronische Signatur zu ermöglichen. Auf die technischen Eigenschaften der Karte wird im Kapitel Sicherheitsinfrastruktur noch näher eingegangen. Abbildung 1: egk als Basis für patientenorientierte Dienstleistungen 3

7 Aufgaben des bit4health Projekts 2 Aufgaben von bit4health Aufgabe des bit4health Projektes ist es, Vorarbeiten zu leisten, um die Einführung der Gesundheitskarte, aber auch den Aufbau der dazu erforderlichen Informations- und Sicherheitsinfrastruktur zu unterstützen. Die Arbeitsschwerpunkte des Projektteams sind die Erstellung einer Rahmenarchitektur, die Vorbereitung der Testphase sowie die professionelle Begleitung des Projektes einschließlich der Konzeption von Akzeptanzmaßnahmen Arbeitspaket 1 Im Arbeitspaket 1 geht es um die konsequente und zeitnahe Beschreibung einer homogenen Architektur. Zur Definition der Telematik-Rahmenarchitektur wird das von SAGA empfohlene ISO/ITU Standard RM-ODP (Reference Model of Open Distributed Processing) eingesetzt. Dieses bietet einen standardisierten Rahmen für die Entwicklung und Beschreibung von verteilten Anwendungen, die in einer offenen, heterogenen und verteilten Systemumgebung interagieren können sollen. Um komplexe, verteilte Anwendungen fassbarer und verständlicher zu beschreiben, werden verteilte Anwendungen beim RM-ODP mit unterschiedlichen so genannten Viewpoints betrachtet. Dies sind verschiedene Sichten einer Spezifikation, die entsprechend verschiedene Aspekte eines Systems beschreiben. Auf das RM-ODP wird im Detail im Kapitel 3.1 eingegangen. 2.2 Arbeitspaket 2 In Arbeitspaket 2 geht es um die Begleitung der Einführung der Gesundheitskarte. Dieses Arbeitspaket ist in verschiedene Unterarbeitspakete unterteilt UAP 1: Akzeptanzbildung Die Akzeptanzbildung sowohl unter den Leistungserbringern, bei den Investoren, den Medien, in wissenschaftlichen und politischen Gremien als auch in der Bevölkerung ist unverzichtbar für eine erfolgreiche Einführung der Gesundheitskarte. Die Akzeptanz hängt ab vom 4 siehe Kick Off Meeting zum bit4health-projekt, S. 9 ff. 4

8 Aufgaben des bit4health Projekts wahrgenommenen Mehrwert, der Glaubwürdigkeit und der Transparenz einer technologischen Innovation. Bei der Gesundheitskarte ist jedoch zu berücksichtigen, dass es heterogene Akteure mit unterschiedlichen Interessen sowie spezifischer Risiko- und Chancenwahrnehmung sind, eine hohe Emotionalität des Themenkomplexes vorliegt und das Finanzbudget für akzeptanzbildende Marketing und PR-Maßnahmen begrenzt ist. Daher wird eine Anforderungsanalyse erstellt wo analysiert wird, welche Anforderungen die verschiedenen Akteure an die egk haben, welche akzeptanzbildenden Anreizmodelle für die verschiedenen Akteure denkbar sind und wie eine gemeinsame Kommunikationsstrategie mit den Institutionen der Akteure aussehen könnte. Die Ergebnisse der Anforderungsanalyse fließen schlussendlich in die Konzeption der Gesundheitskarte ein. Maßnahmen zur Akzeptanzbildung bei niedergelassenen Ärzten sind in einer ersten Phase beispielsweise die Herausarbeitung und Kommunikation der Vorteile der egk für den Arzt, das Aufzeigen von Synergien des Gesamtkonzeptes einer ehealth-telematik-infrastruktur oder das Ansprechen von möglichen Migrationsproblemen und die Vorstellung von Lösungswegen und Supportangeboten. Zu den Maßnahmen aus dem Kommunikations-Mix zählen Artikel in Verbandszeitschriften sowie Online-Medien, Infoveranstaltungen gemeinsam mit kassenärztlichen Vereinigungen und Messestände auf Fachmessen. Während der Einführungsphase werden die Ärzte mit angepasstem Informationsmaterial für die Patienten versorgt und durch die Einrichtung eines Call Centers bei weiterführenden Fragen der Patienten entlastet UAP 2: Projektmanagement Ziel ist es, mit professionellem und kontinuierlichem Projektmanagement als zentrales Steuerungs- und Bindeglied den Projektgesamterfolg zu gewährleisten. Das Projektteam wird die typischen Projektaufgaben (z.b. Risikomanagement, Qualitätssicherung,...) in engster Abstimmung mit dem Auftraggeber, also dem BMGS, abwickeln. Das Ergebnis ist ein laufendes Projektmanagement und -überwachung mit entsprechendem Berichtswesen an den Auftraggeber. 5

9 Aufgaben des bit4health Projekts UAP 3: Qualitätssicherung Das Ziel der Qualitätssicherung ist die Definition und Erreichung von Qualitätszielen, die Identifikation von Projektrisiken und die Erarbeitung geeigneter Strategien zur Risikovermeidung. Als Ergebnis gelten eine revisionsgerechte Dokumentation aller ergriffenen Maßnahmen zur Qualitätsplanung und sicherung und die kontinuierliche Messung der Qualitätszielerreichungsgrade. Die folgende Tabelle gibt einen Überblick über die Hauptkomponenten und deren Ergebnisse: Initialisierung / Qualitätsplanung Festlegung des organisatorischen und abwicklungstechnischen Rahmens Prüfungsvorbereitung Festlegung von Methoden, Kriterien und Vorgehensweisen zur Vorbereitung der Prüfung Prüfung Durchführung der Qualitätssicherungsmaßnahmen Kontrolle Kontrolle der Ergebnisse der Prüfungen Risikobetrachtung Erkennen der Risiken und Maßnahmen zur Risikobeherrschung erarbeiten Berichtswesen Dokumentation der Ergebnisse des Qualitätsmanagementprozesses Qualitätsmanagementhandbuch, Qualitätssicherungsplan, Prüfplan Prüfplan, -spezifikation, -prozedur Prüfung der Ergebnisse der Arbeitspakete, Prozessprüfung, Prüfprotokolle Auswertung der Prüfprotokolle, Controlling Risikoidentifikation, -analyse, -überwachung, - behandlung Berichtsdokumentation, Präsentation, Qualitätsmanagement-Handbuch UAP 4: Wissenschaftliche Begleitung sowie Kosten-Nutzen-Analyse Das Ziel dieses Unterarbeitspakets ist die Abschätzung der Kosten-Nutzenpotenziale von Telematikanwendungen und der Gesundheitskarte. Als Ergebnis erhält man einen Bericht über die Kosten-Nutzenpotenziale von Telematikanwendungen und der Gesundheitskarte. Dieser Bericht entsteht durch die Zusammenführung der Ergebnisse aus analytischen und empirischen Untersuchungen. Bei der analytischen Untersuchung werden quantitative und qualitative 6

10 Aufgaben des bit4health Projekts Nutzenpotenziale und Aufwände auf Annahmenbasis ermittelt und Szenarien für Finanzierungsmodelle aufgestellt. Bei den empirischen Untersuchungen werden quantitative und qualitative Nutzenpotenziale und Aufwände auf Basis empirischer Informationen aus den Testregionen ermittelt und damit die Liste der Nutzenpotenziale vervollständigt. Anhand des Berichts zur Kosten-Nutzenanalyse werden die Szenarien bewertet und entsprechende Empfehlungen abgeleitet UAP 5: Begleitung des ersten Jahres der Betriebsphase Ziel dieses Arbeitspakets ist die professionelle Unterstützung der Arbeiten zum Betrieb der Telematikplattform unter Berücksichtigung der Key Performance Indikatoren aus der Planungsund Testphase. Zu den Performance Indikatoren zählen beispielsweise: Anzahl der Versicherten, die die Gesundheitskarte bei jedem Arztbesuch einsetzen Anzahl der Ärzte und Krankenhäuser, die EDV Systeme einsetzen Anzahl derjenigen, die per earztbrief kommunizieren Als Ergebnis dieses Arbeitspakets gilt die Begleitung zu Akzeptanz, Qualität, Performance und Änderungsnotwendigkeiten und die Beratung der umsetzenden Parteien aus Bund, Ländern, Selbstverwaltung, Wissenschaft und Industrie in Hinblick auf die Erreichung der Qualitäts- und Performanceziele. 7

11 Rahmenarchitektur 3 Rahmenarchitektur Die von bit4health erarbeitete Rahmenarchitektur sieht vor, dass die Infrastruktur jederzeit offen für Einzellösungen verschiedener Anbieter sein muss. Dafür werden notwendige Randbedingungen vorgegeben, die für alle Anwendungen gelten müssen, wie etwa bei den Themen Sicherheit und Datenschutz. Zudem wurden Schnittstellen innerhalb der Telematik- Infrastruktur und den umgebenden IT-Systemen identifiziert. Die Rahmenarchitektur beschreibt darüber hinaus Mechanismen, über die die Telematik-Infrastruktur mit neuen Diensten erweitert werden kann. Dabei muss die Infrastruktur so konzipiert sein, dass sie in die gegenwärtige Landschaft der IT-Systeme der Praxen, Apotheken und Krankenhäuser integrierbar ist und eine reibungslose Kommunikation zwischen allen Beteiligten ermöglicht. Darüber hinaus ist ein Sicherheitskonzept erforderlich, das für die Gesundheitskarte und alle Beteiligten wie Ärzte, Apotheken und Krankenhäuser Authentifizierung, Verschlüsselung und elektronische Signatur beinhaltet, um eine maximale Sicherheit der hochsensiblen, persönlichen Daten zu gewährleisten. 3.1 RM-ODP RM-ODP bietet fünf Viewpoints auf eine offene verteilte Datenverarbeitung an, die unterschiedliche Aspekte abdecken. 5 Enterprise View: Hier werden die Anforderungen eines Unternehmens an die verteilte Anwendung und den Verwendungszweck beschrieben. Der Enterprise View spezifiziert Zielsetzung, Anwendungsbereich, Verfahren und Regeln einer Anwendung. Die besondere Herausforderung besteht beim bit4health Projekt darin, dass hier nicht nur der Blickwinkel einer Organisation oder eines Unternehmens berücksichtigt werden muss, sondern mehrere Sektoren einer ganzen Branche zu betrachten sind. Information View: Diese beschreibt die Ausprägung und Semantik der verarbeiteten Daten, sowie die detaillierten Prozesse zur Datenverarbeitung. Computational View: Darstellung der Zerlegung einer Anwendung in Objekte und deren Dienste, die sie anderen Objekten zur Verfügung stellen. 5 siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S. 18 ff. 8

12 Rahmenarchitektur Engineering View: Darstellung der Verteilung der einzelnen Komponenten des Systems auf die physikalische Infrastruktur und Beschreibung deren Verbindung. Technology View: Beschreibung der zur Realisierung des Systems verwendeten Technologien. Abbildung 2: Reference Model Open Distributed Processing (RM-ODP) Dieses Architekturmodell stellt die Grundstruktur von E-Government-Anwendungen in den unterschiedlichen Sichten dar und gibt Modelle, Standards und Technologien an die Hand, um die Anwendungen zu modellieren und zu realisieren. Mit Hilfe der fünf Sichten können sowohl existierende Systeme als auch neue Systeme und Anwendungen sowie deren Zusammenspiel modelliert werden. Zur Darstellung der Rahmenarchitektur wurde eine Vielzahl von einzelnen Arbeitsprodukten erstellt, die unterschiedliche Aspekte der Telematik im Gesundheitswesen, der Sicherheitsinfrastruktur und der egk abdecken. Auf die einzelnen Arbeitsprodukte wird hier nicht näher eingegangen, da dies den Rahmen dieser Arbeit sprengen würde. 9

13 Rahmenarchitektur 3.2 Entwurfsprinzipien der Rahmenarchitektur Bei der Erstellung der Rahmenarchitektur der Telematik-Infrastruktur finden folgende zehn Entwurfsprinzipien durchgehend Anwendung 6 : Wirtschaftlichkeit: Alle Entscheidungen im Bereich der Rahmenarchitektur sind unter wirtschaftlichen Gesichtspunkten zu prüfen und werden so getroffen, dass der größtmögliche Gesamtnutzen für die Telematik-Infrastruktur besteht. Beteiligung: Die Beteiligten innerhalb der Telematik-Infrastruktur werden an der Entscheidungsfindung beteiligt. Verfügbarkeit und Zuverlässigkeit: Medizinische Prozesse dürfen nicht durch mangelhafte Verfügbarkeit oder Zuverlässigkeit der IT-Systeme behindert oder unterbrochen werden. Verwaltung Daten und Anwendungen: Den Beteiligten ist der Zugang zu allen benötigten Daten und Anwendungen zu ermöglichen. Sie sind konsistent und möglichst redundanzfrei zu verwalten. Die Anforderungen der Sicherheit und des Datenschutzes sind zu gewährleisten. Standards: Es sollen die zu definierenden Standards übergreifend verwendet werden um eine Interoperabilität der Daten, Anwendungen und Technologie sicherzustellen. Interoperabilität: Die Rahmenarchitektur soll die Systeme oder Systemkomponenten befähigen, Informationen gemeinsam zu nutzen und kooperierende Prozesse in verteilten Anwendungen ermöglichen. Informationssicherheit: Daten, Verfahren und Systeme sind vor unzulässiger Manipulation und Verwendung durch geeignete Maßnahmen und Sicherheitsfunktionen zu schützen. Unabhängigkeit: Anwendungen können herstellerunabhängig entwickelt werden und können daher auf unterschiedlichen technischen Plattformen eingesetzt werden. Anwenderfreundlichkeit: Die Architektur entspricht den marktüblichen Entwicklungstendenzen und kann durch die Beteiligten angewandt werden. Zukunftsfähigkeit: Die Rahmenarchitektur ist so flexibel, dass sie zukünftige Entwicklungen aufnehmen und die vielfältigen spezifischen Umsetzungen aus ihr ableitbar sind. 6 siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S

14 Rahmenarchitektur 3.3 Verwendung der Rahmenarchitektur Die Telematik-Rahmenarchitektur muss in einem moderierten und koordinierten Prozess in eine Lösungsarchitektur überführt werden. Dabei sind folgende wesentliche Punkte zu beachten 7 : Die Lösungsarchitektur muss den Herstellern von Komponenten der Telematik- Infrastruktur realisierbare Voraussetzungen liefern, um die Umsetzung mit angemessenem Zeit- und Ressourcenaufwand zu ermöglichen. Die Lösungsarchitektur muss auf den Vorgaben und Leitlinien der Rahmenarchitektur basieren. Die Lösungsarchitektur muss ihrerseits erweiterbar sein, um weitere existierende sowie neue Anwendungen im Gesundheitswesen integrieren zu können. Die Lösungsarchitektur muss gepflegt werden. Die Lösungsarchitektur muss den freien Wettbewerb zwischen den Erstellern der Lösungen ermöglichen. 3.4 Umsetzung der Rahmenarchitektur Die empfohlenen Schritte zur Umsetzung der Rahmenarchitektur zu einer Lösungsarchitektur sind wie folgt: 1. Umsetzung der Bestandteile der Rahmenarchitektur 2. Konsentierung der Charakteristika der Rahmenarchitektur mit der Selbstverwaltung und der Industrie 3. Genehmigung der Lösungsarchitektur durch das BMGS Die Konsentierung stellt eine wesentliche Aufgabe bei der Umsetzung dar. Sie dient im Wesentlichen dazu, einerseits die Anforderungen der verschiedenen Beteiligten im Gesundheitswesen, also der Anwender der Telematik-Infrastruktur, sicherzustellen und andererseits die Interessen der Industrie zu wahren. 8 7 siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S. 70 ff. 11

15 Sicherheitsinfrastruktur 4 Sicherheitsinfrastruktur Der Telematikinfrastruktur im Gesundheitswesen muss eine den Sicherheitsanforderungen entsprechende Sicherheitsinfrastruktur zu Grunde liegen, um die Datensicherheit und den Datenschutz im Gesundheitswesen zu gewährleisten. Um dies zu realisieren, sind zum einen eine Sicherheitsarchitektur, aus der sich eine Sicherheitsinfrastruktur ableitet, und zum anderen Sicherheits-Policies, die den Umgang mit personenbezogenen administrativen und medizinischen Daten festlegen, notwendig. Die Rahmenarchitektur orientiert sich an dem deutschen, weitgehend akzeptierten und verbreiteten Standard SAGA (Standards und Architekturen für egovernment Anwendungen), der eine Architektur gemäss RM-ODP vorsieht. RM-ODP sieht eine Sicherheitsarchitektur nach ISO vor. Somit ist die Konformität zu internationalen Standards und damit zu einer international anerkannten Vorgehensweise sichergestellt Datenschutz und Datensicherheit Im Kontext der Telematikinfrastruktur im Gesundheitswesen fallen Aspekten des Datenschutzes sowie der Datensicherheit eine besonders grosse Bedeutung zu Grundlegende Sicherheitsanforderungen Folgende grundlegende Sicherheitsziele müssen von Systemen zur medizinischen Datenverarbeitung gewährleistet werden 10 : Authentizität (Zurechenbarkeit): Der Urheber von patientenbezogenen bzw. der Verantwortliche für patientenbezogene Daten sowie der Auslöser eines Verarbeitungsvorgangs bzw. der Verantwortliche für einen Verarbeitungsvorgang muss jederzeit eindeutig feststellbar sein. Nutzungsfestlegung: Medizinische Datenverarbeitungssysteme müssen es ermöglichen, für jedes patientenbezogene Dokument den Nutzerkreis sowie abgestufte Nutzungsrechte festzulegen und Nutzungsausschlüsse zu definieren. 9 siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S. 54 ff. 10 siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S. 15 ff. 12

16 Sicherheitsinfrastruktur Vertraulichkeit: Wer sich in Behandlung begibt, muss und darf erwarten, dass alles, was der Arzt im Rahmen seiner Berufsausübung über seine gesundheitliche Verfassung erfährt, geheim bleibt und nicht zur Kenntnis Unberufener gelangt. Integrität: Personenbezogene Daten müssen während allen Phasen der Verarbeitung unversehrt, vollständig, gültig und widerspruchsfrei bleiben. Nicht-Abstreitbarkeit von Datenübermittlungen: Einerseits ist zu gewährleisten, dass der Sender eines patientenbezogenen Dokuments sicher sein kann, dass das Dokument seinen Empfänger erreicht hat, und er darf nicht abstreiten können, genau dieses Dokument an genau den Empfänger gesendet zu haben. Die Nicht-Abstreitbarkeit ist eine Voraussetzung der Revisionsfähigkeit. Revisionsfähigkeit: Die Verarbeitungsprozesse müssen lückenlos nachvollzogen werden können und es muss festgestellt werden können, wer wann welche patientenbezogenen Daten auf welche Weise verarbeitet hat. Rechtssicherheit: Für jeden Verarbeitungsvorgang und dessen Ergebnisse ist der Verursachende bzw. Verantwortliche beweiskräftig nachweispflichtig. Validität: Personenbezogene Daten müssen aktuell in der für den Nutzungszweck angemessenen Qualität verarbeitet werden. Verfügbarkeit: Personenbezogene Daten müssen zeitgerecht zur Verfügung stehen und ordnungsgemäss verarbeitet werden können Festlegungen der Rahmenarchitektur In diesem Kapitel wird dargestellt, wie sich die Rahmenarchitektur zu den einzelnen im Kapitel erwähnten Punkten verhält siehe Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, S. 66 ff. 13

17 Sicherheitsinfrastruktur Authentizität (Zurechenbarkeit): Generell muss zwischen der Zurechenbarkeit der Handlungen der Leistungserbringer, die stets über einen Heilberufsausweis (HBA) oder Berufsausweis verfügen, und über die Zuordnung der Handlungen der Patienten, die stets über eine egk verfügen, unterschieden werden. Handlungen der Leistungserbringer (Personen des Gesundheitswesens) sind zum einen über den HBA auf Ebene des Zugriffs auf eine egk mittels HBA und zum anderen über die Verwendung qualifizierter elektronischer Signaturen zurechenbar. Die Rahmenarchitektur fordert eine gegenseitige Authentifizierung zwischen HBA und der egk, um sicherzustellen, dass Auf die egk nur berechtigte Personen zugreifen können Heilberufler nur auf gültige egks Daten schreiben können Nutzungsfestlegung: Die Zugriffskontrollfunktion auf die Anwendungen wird in der Rahmenarchitektur in zwei Stufen aufgeteilt und an unterschiedlichen Stellen der Rahmenarchitektur platziert: Generelle Zugriffsrechte für Berufsgruppen und die zugehörigen im Gesundheitswesen festgelegte Rollen. Diese Zugriffsrechte werden direkt von dem Betriebssystem der egk geprüft und Zugriffe entsprechend den vorgegebenen Regelungen erlaubt. Spezifische Zugriffsrechte auf einzelne Angehörige einer Berufsgruppe für einzelne Anwendungen mit der jeweiligen Autorisierung des Versicherten. Diese Zugriffsrechte werden innerhalb der bit4health-dienste, aber ausserhalb der egk geprüft. Vertraulichkeit: Die personenbezogenen medizinischen Daten können über ungesicherte Netze übertragen werden, wenn diese nach aktuellem Stand der Informationstechnik auf Netzwerkebene verschlüsselt werden sowie eine gegenseitige, sichere Authentifizierung der beiden Entitäten des Gesundheitswesens stattfindet. Diese müssen zusätzlich in allen zwischenspeichernden Stellen verschlüsselt abgelegt werden, so dass ein Zugriff von Administratoren oder allgemein von Dritten nicht erfolgen kann. Integrität (Erkennbarkeit einer möglichen Verletzung der Integrität): Die Integrität von administrativen und medizinischen Daten wird im Rahmen der Geschäftsvorfälle, die eine elektronische Signatur des Leistungserbringers erfordern, implizit über die elektronische Signatur gewährleistet. 14

18 Sicherheitsinfrastruktur Nicht-Abstreitbarkeit von Datenübermittlungen: Die Rahmenarchitektur gibt einen zentralen, anwendungsneutralen Dienst zur Sicherstellung der Nicht-Abstreitbarkeit von Datenübermittlungen vor. Die konkrete Ausgestaltung dieses Dienstes liegt bei der Lösungsarchitektur, wird jedoch in seiner technischen Realisierung ein Quittierungsverfahren unter Verwendung elektronischer Signaturen sein. Revisionsfähigkeit: Die Forderung nach Revisionsfähigkeit geschieht in allen Geschäftsvorfällen, die den Einsatz der elektronischen Signatur der bearbeitenden Leistungserbringer erfordern, unmittelbar mittels der elektronischen Signatur. Verarbeitungsschritte, die nicht im Rahmen dieser Signaturen erfasst werden, wie z.b. das Leben von personenbezogenen medizinischen Daten, müssen manipulationssicher protokolliert werden. Rechtssicherheit: Die Rechtssicherheit ist in allen Geschäftsvorfällen gegeben, in denen die qualifizierte elektronische Signatur zum Einsatz kommt. Validität: Die Validität medizinischer Daten ist nicht Gegenstand der Telematikinfrastruktur wohl aber der Medizin. Verfügbarkeit: Die Rahmenarchitektur ist bewusst offen für unterschiedliche Formen der Datenhaltung der Telematik im Gesundheitswesen. Aus diesem Grunde formuliert die Rahmenarchitektur Anforderungen bezüglich der Verfügbarkeit, die von möglichen Lösungsarchitekturen erfüllt werden müssen. In diesem Kapitel wird ersichtlich, dass viele Sicherheitsanforderungen durch die elektronische Signatur abgedeckt werden. Auf die elektronische Signatur wird nicht weiter eingegangen, da dies Thema eines anderen Papers ist. 15

19 Lösungsarchitektur 5 Lösungsarchitektur 5.1 Erstellung einer Lösungsarchitektur Die Rahmenarchitektur ist eine Architekturdefinition mit Leitliniencharakter. Für die Umsetzung ist die Erstellung einer Lösungsarchitektur erforderlich. Es wird empfohlen, diese Lösungsarchitektur, ausgehend von den Pflichtanwendungen der Gesundheitskarte, schrittweise zu entwickeln und umzusetzen. Bei den Pflichtanwendungen sind Anwendungen gemeint, die sich insbesondere auf die administrativen Daten des Versicherten sowie die Übermittlung ärztlicher Verordnungen (meistens Rezepte) beziehen. Die Lösungsarchitektur sollte dann durch die freiwilligen Anwendungen, die hauptsächlich die medizinischen Daten des Versicherten betreffen, erweitert werden. Die Erstellung der Lösungsarchitektur ist vor der Realisierung der Testvorhaben sinnvoll und notwendig, um den Herstellern von Primärsystemen 12 die Möglichkeit für sichere Investitionen zu geben. 5.2 Testvorhaben Die Testvorhaben dienen nicht nur dazu, die Tauglichkeit der Rahmenarchitektur zu überprüfen, sondern es sollen auch veränderte Prozesse und Abläufe bei der Versorgung, akzeptanzfördernde Maßnahmen und die Wirtschaftlichkeit der elektronischen Gesundheitskarte getestet werden. Die evaluierende Begleitung und die Bewertung der Testvorhaben wird durch das bit4health Projekt angeboten, um einheitliche Kriterien anwendbar zu machen. 13 In einer quasi experimentellen Felduntersuchung werden die Funktionsweise der egk geprüft und gegebenenfalls Optimierungen vorgenommen sowie die durch die Einführung der egk hervorgerufenen Auswirkungen erfasst und untersucht. Die Evaluation erfolgt in den Bereichen: Technik (z.b. Rahmenarchitektur, Kartenspezifikationen, Schnittstellen) Organisation (z.b. Geschäftsprozesse) 12 IT-System, das bei einem Leistungserbringer eingesetzt wird, z.b. eine Praxisverwaltungssoftware oder eine Apothekensoftware 13 siehe Rahmenarchitektur für die Telematikinfrastruktur im Gesundheitswesen, S. 78 ff. 16

20 Lösungsarchitektur Qualität (z.b. Veränderung der medizinischen Behandlungsqualität durch den Zugriff auf Notfalldaten oder durch den Einsatz freiwilliger Anwendungen wie Arzneimitteldokumentation) Akzeptanz (Z.B. Akzeptanz bei allen Zielgruppen, Wirksamkeit akzeptanzbildender Massnahmen) Wirtschaftlichkeit (z.b. Kosten/Nutzen innerhalb und zwischen den einzelnen Szenarien Überführung in einen Echtbetrieb (z.b. Übertragbarkeit, Praktikabilität der in den Testvorhaben eingesetzten Vorgehensweisen zur Einführung und Betrieb der egesundheitskarte in der Breite) siehe Anforderungen an die Konzeption zur Durchführung eines Testvorhabens, S. 7 17

21 Fazit 6 Fazit Die Gesundheitskarte sollte ab nächstem Jahr in Deutschland eingeführt werden. Das Projekt ist bisher soweit fortgeschritten, dass die Karten nun in verschiedenen Regionen getestet werden. Treten bei diesen Tests keine grösseren Komplikationen auf, sollte der Einführung der egk im nächsten Jahr nichts mehr im Wege stehen. Trotzdem gibt es einige Punkte, welche hier noch speziell erwähnt werden sollten. Die egk soll im Gegensatz zur KVK erhebliche Verbesserungen mit sich bringen. Wenn man diese Verbesserungen jedoch genau unter die Lupe nimmt, profitieren nicht alle in einem erheblichen Ausmass von der Einführung dieser neuen Karte. Auf Seite der Patienten soll die Karte die Eigenverantwortung stärken. Nun ist es aber nicht nachgewiesen, dass auch alle Patienten diese Eigenverantwortung übernehmen wollen oder können. Z.B. der heute häufig vorkommende Arztvergleich (man holt sich bei zwei verschiedenen Ärzten eine Meinung ein) wird mit der Einführung der egk praktisch ausgeschlossen. Konnte man sich früher Meinungen von verschiedenen Ärzten einholen, wird das mit der egk nicht mehr möglich sein, ohne dass der Arzt einsehen kann, welche Diagnose der zuvor behandelnde Arzt gemacht hat. Der Patient muss sich daher auf die Meinung eines einzigen Arztes verlassen. Zudem stellt sich die Frage, ob gewisse Patienten mit dieser Karte technisch nicht einfach überfordert werden. Gerade ältere Leute, welche technisch nicht gerade begabt sind, können wohl kaum nachvollziehen, wofür diese Karte gut sein sollte und werden dementsprechend unsicher im Umgang mit der Karte sein. Auf der Seite der Ärzte soll die egk die Prozesse verbessern, so dass Ärzte mehr Zeit für ihre Patienten haben. Führt die egk aber bei Ärzten nicht auch dazu, dass sie sich auf die Daten im Computer verlassen und sich so weniger auf den Patienten selbst konzentrieren? Oder aber wenn sich der Arzt nicht auf die Daten verlassen will, braucht er wie bisher genau gleich viel Zeit, um den Patienten zu behandeln. Wird beispielsweise ein Patient in ein Krankenhaus eingeliefert, bei dem eine Bluttransfusion nötig ist: vertraut der Arzt auf die auf der egk angegebene Blutgruppe oder untersucht er das Blut vorher trotzdem noch einmal? Wer trägt die Verantwortung, wenn dem Patienten aufgrund der Daten auf der egk das falsche Blut gegeben wird? Die egk fordert zusätzlich technische Voraussetzungen, über welche wohl nicht jeder Arzt verfügt. So sind eine technische Infrastruktur und zusätzliche Fähigkeiten des Personals nötig, welche für den Arzt erhebliche Kosten verursachen. 18

22 Fazit Zudem stellt sich die Frage, ob der Arzt überhaupt auf all diese Doppelbehandlungen verzichten will, welche man mit der Gesundheitskarte vermeiden will. Bisher konnte auf diese Weise jeder Arzt etwas an der Behandlung eines einzelnen Patienten verdienen. Solche Doppelbehandlungen sind sicherlich nicht wirtschaftlich, aber mit den Zielen der Einführung der egk werden von den Beteiligten (hier Ärzte und Patienten) Verhalten vorausgesetzt, die so nicht einfach angenommen werden dürfen. Die Ziele wie schlussendlich Kostensenkungen werden nämlich nur erreicht, wenn die vorausgesetzten Annahmen in Wirklichkeit von den Beteiligten auch so umgesetzt werden. Grundsätzlich ist die egk wohl erforderlich im heutigen Zeitalter der Technik. Trotzdem ist nach all den Anforderungen und nötigen Voraussetzungen fraglich, ob eine solche egk das Gesundheitswesen wirklich effizienter gestaltet. Vergleicht man die im Vorfeld und bei der Einführung anfallenden Kosten mit den nachträglich erwarteten Einsparungen (welche nur empirisch basiert sind), darf man nur hoffen, dass diese Karten dann auch alle Erwartungen erfüllen. Schliesslich sollte die egk die Wirtschaftlichkeit des Gesundheitswesens fördern und nicht jene Zweige unterstützen, die für die Einführung oder Umsetzung der egk verantwortlich sind. Die Einführung der Karte bringt den beteiligten Dienstleistern (Krankenhäusern, Ärzten,...) im Vergleich zu den bei ihnen anfallenden Kosten wie oben erwähnt nur bedingt Vorteile. Wer hauptsächlich von der Einführung der neuen Karte profitiert, sind all jene Unternehmen, welche für die Einführung der Karte verantwortlich sind. Als letzter Kritikpunkt bleibt da noch die Sicherheitsinfrastruktur. Wie in dieser Arbeit dargelegt, werden die Sicherheitsanforderungen genau beschrieben und nötige Massnahmen dafür eingeleitet. Theoretisch tönt das alles sehr gut, ob das aber in der Praxis auch wirklich genau so umgesetzt werden kann? Auch dies könnte ein weiterer Grund dafür sein, warum vielleicht nicht gerade alle Patienten oder auch Dienstleister über die Einführung der egk begeistert sind. Zum Vorgehen zur Einführung der egk ist abschliessend zu sagen, dass viele Länder von der Art und Weise, wie das in Deutschland gemacht wird, profitieren könnten. Auf der Homepage zum bit4healt Projekt ( sind alle wichtigen Informationen über das Projekt verfügbar. Der Interessierte hat also die Möglichkeit, was die Vorbereitung zur Einführung der egk angeht, immer auf dem neusten Stand zu sein. 19

23 Bibliographie IV Bibliographie Die vorliegende Arbeit basiert grundlegend auf den nachfolgend angegebenen Dokumenten: Anforderungen an die Konzeption zur Durchführung eines Testvorhabens, verfügbar via zugegriffen am 5. Januar 2005 Chronologie der egk, verfügbar via zugegriffen am 3. Januar 2005 Glossar des Projektes bit4health, verfügbar via zugegriffen am 3. Januar 2005 Kick Off Meeting zum bit4health-projekt (Das Projektmanagement bit4health), verfügbar via zugegriffen am 5. Januar 2005 Rahmenarchitektur für die Telematikinfrastruktur des Gesundheitswesens, verfügbar via zugegriffen am 3. Januar