Anwendungsarchitektur Spezifikation einer Architektur zum sicheren Austausch von Patientendaten

Größe: px
Ab Seite anzeigen:

Download "Anwendungsarchitektur Spezifikation einer Architektur zum sicheren Austausch von Patientendaten"

Transkript

1 Anwendungsarchitektur Spezifikation einer Architektur zum sicheren Austausch von Patientendaten Editor: Oliver Boehm Verantwortlich: Fraunhofer ISST Berlin Status: Release Version: 1.0 Berlin,

2

3 Release-Planung Nr. Datum MS Version Status Bemerkungen Status x draft Kerndokument an QS und PL 1 week late Final draft Freigabe zum Review durch LK und AG-2 1 week late Abschluss des Review Release Einarbeiten der Kommentare 5 6 Änderungshistorie Nr. Datum Version Status Bemerkungen Bearbeiter Draft Gliederung; Aufschlüsselung der Zugangscodes OB Draft Schnittstellen und Sequenzdiagramme OB Draft QS PF Final Draft Abgleich mit Sicherheitsarchitektur; interne Freigabe JC Final Draft Überarbeitung/Ergänzungen OB Release Einarbeitung Kommentare Projektpartner und QS OB Anwendungsarchitektur_v1.0_ob_nach_qs.doc 1

4 Copyright Copyright (c) Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH (2006). Alle Rechte vorbehalten. Dieses Dokument und Übersetzungen, die davon angefertigt wurden, dürfen kopiert und weitergegeben werden und abgeleitete Werke, die es kommentieren, erklären, oder Hilfestellung bei der Implementierung leisten, dürfen vorbereitet, kopiert, veröffentlicht und verteilt werden, als Ganzes oder in Teilen, ohne dass hierbei Einschränkungen in irgendeiner Form bestehen; vorausgesetzt, dass die obige Urheberrechtserklärung und dieser Absatz in allen Kopien und abgeleiteten Werken enthalten sind. Dieses Dokument selbst darf nur mit schriftlichem Einverständnis der Urheber modifiziert werden. Die beschränkten Rechte, die durch obige Aussage gewährt werden, sind dauerhaft und werden von den Urhebern (Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH), ihren Nachfolgeorganisationen und Rechtsnachfolgern nicht zurückgezogen werden. Dieses Dokument und die hierin enthaltene Information werden ohne Mängelgewähr zur Verfügung gestellt. DAS FRAUNHOFER-INSTITUT FÜR SOFTWARE- UND SYSTEMTECHNIK ISST, DIE ASKLEPIOS KLINIKEN VERWALTUNGSGESELLSCHAFT MBH, DIE DEUTSCHE KRANKENHAUSGESELLSCHAFT E. V., DIE RHÖN-KLINIKUM AG, DIE SANA E.MED GMBH UND DIE AN DER ERSTELLUNG DIESES DOKUMENTS BETEILIGTEN MITARBEITER DER GENANNTEN EINRICHTUNGEN SCHLIESSEN JEDE FORM DER HAFTUNG, OB GEÄUßERT ODER VERMUTET; AUS, DAFÜR DASS DIE VERWENDUNG DER INFORMATIONEN IN DIESEM DOKUMENT KEINE RECHTE VERLETZT; DASS SIE GEBRAUCHSTAUGLICH SIND ODER SICH FÜR EINEN SPEZIELLEN ZWECK EIGNEN. 2 Letzte Speicherung des Dokuments: :23:00

5 Inhalt Copyright 2 1 Management Summary 7 2 Einleitung Einordnung in den Projektkontext Einführungsphasen Fat Clients vs. Thin Clients Notation Konventionen Gliederung des Dokuments 16 3 Grundlagen der Anwendungsarchitektur SOA und Web Services Charakteristika elektronischer Fallakten Aufbau von Fallakten Use-Cases für elektronische Fallakten Vernetzung von efa-anbietern Konzeptionelles Modell Schutz personenbezogener Daten 27 4 Lösungskonzept Funktionale Spezifikation elektronischer Fallakten Konzeptionelles Prinzip Anwendung im Kontext der elektronischen Fallakte Navigationsmodell Modell zur Zugangs- und Zugriffskontrolle Dienste Navigationsdienste Speicherdienste Löschdienste Änderungsdienste Security Token Services 41 5 Übersicht über die Anwendungsarchitektur und die Dienste der elektronischen Fallakte Überblick zu den Komponenten des Clients Überblick zu den Diensten der DMZ Überblick zu den Diensten der Servicezone Überblick zu den Diensten im Intranet 45 Anwendungsarchitektur_v1.0_ob_nach_qs.doc 3

6 6 Funktionale Spezifikation der Dienstschnittstellen Security Token (Assertions) Identity Assertion Admission Assertion Access Assertion Datentypen Identifikatoren Metadaten Lokalisierung Identity Provider Attribute Service DataChannel Service efa-token Service efa-token Service requestadmissionassertions() efa-token Service requestalladmissionassertions() efa-token Service requestadmissionassertion() efa-token Service searchadmissionassertions() efa-token Service newadmissioncode() efa-token Service requestadmissionassertion() efa-inventory efa-inventory requestaccessassertion() efa-inventory createrecord() efa-inventory removerecord () efa-inventory hasrecords() efa-inventory listrecords() efa-inventory searchrecords() efa-inventory getmetadata() efa-inventory setmetadata() efa-inventory setadmission() efa-inventory setmetadata() Object Inventory Object Inventory listobjects() Object Inventory createpartition() Object Inventory createfolder() Object Inventory getmetadata() Object Inventory setmetadata() Object Inventory getsource() Object Inventory registerdataobject() Object Inventory removeobjects() Object Inventory setstate() Object Inventory getstate() Object Inventory getstatehistory() Object Inventory getlink() Object Inventory getobjectstore() 86 4 Letzte Speicherung des Dokuments: :23:00

7 Object Inventory getstructure() Object Store Object Store getobject() Object Store removeobject() Object Store setobject() efa-broker 91 7 Funktionale Spezifikation der Schnittstellen der Komponenten auf der Seite des Clients efa-proxy efa-proxy getobject() efa-proxy setobject() efa-enabler efa-enabler getadmissionassertions() efa-enabler getmetadaten()/setmetadata() efa-enabler getstate()/setstate() efa-enabler getobject() efa-enabler setobject() 99 8 Nutzungsszenarien der elektronischen Fallakte Zugang zur elektronischen Fallakte und Zugriffsrechte Zugang zu einer elektronischen Fallakte herstellen (Fat Client) Zugang zu einer elektronischen Fallakte herstellen (Thin Client) Zugang zu einer elektronischen Fallakte einrichten (Fat Client) Zugang zu einer elektronischen Fallakte löschen (Fat Client) Zugriffsrechte auf Objekten einer elektronischen Fallakte setzen (Fat Client) Auffinden, Erzeugen und Löschen elektronischer Fallakten Auffinden elektronischer Fallakten (Fat Client) Auffinden elektronischer Fallakten (Thin Client) Erzeugen einer elektronischen Fallakte (Fat Client) Zugriff auf eine bekannte efa Löschen einer elektronischen Fallakte (Fat Client) Ändern der Metadaten einer elektronischen Fallakte (Fat Client) Ändern der Metadaten einer elektronischen Fallakte (Thin Client) Nutzungsszenarien zur Verwaltung von Partitionen, Ordnern und Datenobjekten 123 Anwendungsarchitektur_v1.0_ob_nach_qs.doc 5

8 8.3.1 Erzeugen von Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Thin Client) Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Fat Client) Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Thin Client) Ändern des Status von Objekten in einer elektronischen Fallakte (Fat Client) Ändern des Status von Objekten in einer elektronischen Fallakte (Thin Client) Verteilung elektronischer Fallakten Nutzungsszenarien verteilter elektronischer Fallakten Auffinden elektronischer Fallakten auf entfernten Knoten Auffinden von Teilen verteilter elektronischer Fallakten Erzeugen und Registrieren einer Extension-eFA Realisierungshinweise Verwaltung von elektronischen Fallakten durch das efa-inventory Zugangskontrolle zu elektronischen Fallakten durch das efa-inventory Verwaltung von Partitionen, Ordnern und Datenobjekten durch das Object Inventory Speicherung der Datenobjekte im Object Store Literatur 153 A Abbildungsverzeichnis 159 B Abkürzungsverzeichnis Letzte Speicherung des Dokuments: :23:00

9 1 Management Summary Der zeitnahe einrichtungs- und sektorübergreifende Austausch medizinischer Informationen zu Patienten ist ein Mittel, von dem sich die beteiligten Projektpartner zukünftig eine Effektivitäts- und damit Qualitätssteigerung ihrer medizinischen Dienstleistung erwarten. Die höhere Qualität soll der nachhaltigen Bindung von Patienten und Behandlungspartnern dienen. Der Zusammenschluss der beteiligten Projektpartner als Anbieter und Nutzer elektronischer Fallakten führt zu neuen technischen Herausforderungen. Der Umfang der verfügbaren Informationen steigt durch die Vernetzung der Anbieter deutlich an. Gleichzeitig wächst die Zahl der potenziellen Nutzer in dem Maß, in dem sich die Möglichkeiten rechtlicher Einflussnahme einzelner Anbieter verringern. Durch die Vernetzung ist der Großteil der Nutzer der medizinischen Informationen eines Krankenhauses selbst diesem unbekannt und befindet sich außerhalb seines Einflussbereiches. Deshalb sind die Grundvoraussetzungen für den Erfolg der elektronischen Fallakte das Vertrauen der Anbieter untereinander und vor allem das Vertrauen der Patienten in den Schutz ihrer Privatsphäre, d. h. in den Schutz der Vertraulichkeit ihrer medizinischen Daten. Die Patienten müssen sich sicher sein können, dass nur ein von ihnen autorisierter Personenkreis Zugriff auf ihre Daten erlangen kann. Ziel des vorliegenden Dokuments ist die Spezifikation einer Anwendungsarchitektur für die vernetzte elektronische Fallakte, die zum einen den funktionalen Anforderungen zur Realisierung der Unterstützung von Versorgungsabläufen im klinischen Alltag gerecht wird, zum anderen aber auch die Sicherheits- und Datenschutzanforderungen der Anbieter und der Patienten und somit auch die gesetzlichen Vorgaben in diesem Kontext erfüllt. Die umfassende Bereitstellung von medizinischen Informationen und der Schutz der Vertraulichkeit bergen einen Zielkonflikt in sich. Darum kann eine Lösung zur Realisierung der elektronischen Fallakte immer nur ein Kompromiss aus beiden Zielstellungen sein. Nicht alle wünschenswerten Funktionen lassen sich im vollen Umfang umsetzen, wenn man den Anforderungen an Sicherheit und Datenschutz gerecht werden will. Grundlage der Anwendungsarchitektur ist das serviceorientierte Paradigma. Daher werden lediglich die Schnittstellen der Services spezifiziert. Dies 7

10 bewahrt die größtmögliche Autonomie und Flexibilität der Anbieter in der Realisierung der Dienste und sichert gleichzeitig die Interoperabilität. Um die Realisierbarkeit der elektronischen Fallakte sicherzustellen, wurden im Entwurf der Anwendungsarchitektur in Absprache mit den IT-Dienstleistern der Projektpartner Konzepte und Vorgaben der Standards im Kontext von Web-Services wie z. B. SOAP [SOAP], WS-Security [WS-Security], WS- Trust [WS-Trust] und WS-Federation [WS-Federation] berücksichtigt. Neben der Spezifikation der Schnittstellen werden Szenarien aufgezeigt, die die Anwendung der Schnittstellen erläutern. Die ausführliche Darstellung des Lösungskonzepts zur Realisierung der Zugangs- und Zugriffskontrolle auf der Dienst- und Datenebene dient vor allem dem Verständnis und der Auseinandersetzung zur Schaffung öffentlichen Vertrauens. Ergänzend zu den Spezifikationen werden Hinweise zur Realisierung gegeben. 8

11 2 Einleitung Die Einführung der elektronischen Gesundheitskarte stellt insbesondere die Krankenhäuser vor große Herausforderungen. Die priorisierten Anwendungen erezept und Versichertenstatus adressieren nur marginal den für Krankenhäuser besonders wichtigen sektorübergreifenden Datenaustausch, gleichzeitig ist die Umstellung der IT-Systeme mit großen Aufwänden verbunden. Die privaten Klinikketten asklepios Klinikverwaltungsgesellschaft mbh, Rhön-Klinikum AG und Sana e.med GmbH haben daher beschlossen, ihre aktuellen Aktivitäten zur Errichtung von Ärzteportalen zu bündeln und in ein gemeinsames Projekt mit der Deutschen Krankenhausgesellschaft e. V. und dem Fraunhofer-Institut für Software- und Systemtechnik ISST einzubringen. Das Projekt wird durch einen Beirat aus Vertretern öffentlicher, privater und kirchlicher Krankenhausträger begleitet und soll die Arbeiten der gematik ergänzen. Ziel ist es, Synergieeffekte zu nutzen, und die unabhängig von der Gesundheitskarte notwendigen Investitionen in elektronische Patientenakten abzusichern. Gegenstand der auch für weitere Partner offenen Initiative ist die Spezifikation einer interoperablen Architektur, mit der bei Krankenhäusern vorgehaltene Patientendaten über verschiedene Zugangswege im Kontext sektorübergreifender Behandlungsszenarien nutzbar gemacht werden können. Dadurch werden die existierenden dezentralen Strukturen der Verwaltung medizinischer Daten beibehalten und es können Mehrfachspeicherungen vermieden werden. Neben einem auf den Spezifikationen der Gesundheitskarte basierenden Zugang für Patienten und Ärzte (elektronische Patientenakte epa) können Daten eines Behandlungsfalls zu einer»fallakte«zusammengefasst werden, die den mit der Behandlung befassten Medizinern einen sektor- und einrichtungsübergreifenden Datenaustausch ermöglicht. Einsatzszenarien für Fallakten sind insbesondere Disease Management Programme und die zunehmend an Bedeutung gewinnende integrierte Versorgung [efa_szen- 10]. 2.1 Einordnung in den Projektkontext In diesem Dokument wird die Anwendungsarchitektur beschrieben, auf der die Anwendung "elektronische Fallakte«zum einrichtungsübergreifenden Datenaustausch basiert. 9

12 Die Anwendungsarchitektur umfasst alle Komponenten und Dienste des funktionalen Kerns der Anwendung»elektronische Fallakte«und setzt damit die domain- und anwendungsspezifischen Lösungskonzepte um. Die Anwendungsarchitektur nutzt die Objekte, Mechanismen und Dienste der Sicherheitsarchitektur, wie z. B. den Identity Provider, Berechtigungsnachweise und Zugangscodes. Anwendungs- und Sicherheitsarchitektur nutzen die in der Kommunikationsarchitektur beschriebenen Mechanismen zur Kommunikation zwischen Diensten und zur Anbindung von Clientsystemen. Über sog. Bindings wird hierbei eine Abbildung der in der Anwendungsarchitektur spezifizierten Schnittstellen auf konkrete Mechanismen und Standards des Nachrichtenaustauschs vorgenommen (z. B. SOAP und WS Security). In diesem Dokument wird die Anwendungsarchitektur funktional spezifiziert. Die funktionale Spezifikation ist ein Modell von Datenstrukturen, Diensten und Komponenten, das die Außensicht der Anwendung»elektronische Fallakte«prägt. D. h., auch wenn eine Implementierung teilweise andere interne Strukturen, funktionale Dekompositionen und Datenflüsse realisiert, müssen diese von Außen betrachtet d. h. an den externen Schnittstellen konform zu der funktionalen Anwendungsarchitektur sein. Welche Dienste extern sichtbar sind, in welcher Kodierung Daten über welche zu implementierenden Schnittstellen ausgetauscht werden und welche Komponenten wie integriert werden können, wird in der auf diesem Dokument basierenden physikalischen Architektur sowie in den Bindings für die verwendeten Kommunikations- und Verteilungsmechanismen (z. B. SOAP und Web Services) spezifiziert. Hierdurch wird berücksichtigt, dass unterschiedliche Umgebungen und Nutzungskontexte auch verschiedene Umsetzungen der funktionalen Architektur erfordern können. Die Bindings der Anwendungsarchitektur für SOAP und https sind in dem Dokument»Kommunikationsarchitektur«beschrieben. Die Verteilung der Anwendungsdienste sowie deren Anbindung an die IT-Landschaft eines Krankenhauses sind Gegenstand des (nicht normativen) Dokuments»Deployment-Optionen«. In Abbildung 1 ist das Dokument zur Anwendungsarchitektur im Kontext der Projektergebnisse dargestellt. 10

13 Abbildung 1 Dokumentenübersicht Übersicht über die Projektergebnisse Fachlogik Systemgrenzen und Szenarien Formate, Dokumente und Dokumententypen Abläufe (Use Cases) Sicherheit und Datenschutz Sicherheitskonzept Sicherheitsarchitektur Implementierungsvorgaben Technik Anwendungsarchitektur Implementierungsvorgaben Kommunikationsarchitektur Implementierungsvorgaben Anforderungen an efa und epa Datentypen und Nachrichtenformate Deployment-Beispiele 2.2 Einführungsphasen Für das Projekt wird von einer Einführung der elektronischen Fallakte in drei Phasen ausgegangen: 1 Die am Projekt beteiligten Einrichtungen führen Pilot- und Testvorhaben durch. Weder HBA noch egk sind in ausreichender Dichte verfügbar und alle benötigten Dienste werden in»eigenregie«betrieben. Gleichartige Dienste verschiedener efa-anbieter sind untereinander vollständig vernetzt. 2 Die spezifizierte Fallakte kommt in einer größeren Zahl von Einrichtungen im»regelbetrieb«zum Einsatz. Eine egk ist von einzelnen Krankenkassen in einzelnen Regionen ausgegeben. Die Dienste werden in übergeordnete Organisationsstrukturen integriert und teilweise von mehreren Trägern gemeinsam oder zentralisiert angeboten und betrieben. Dienste der gematik werden soweit verfügbar genutzt. Dienste verschiedener efa-anbieter sind nach einem Föderationskonzept miteinander vernetzt. 3 egk und HBA sind flächendeckend verfügbar. Die von der gematik spezifizierte Telematikinfrastruktur ergänzt die eigenen Dienste bzw. löst diese ab. Gleichartige Dienste verschiedener efa-anbieter sind an die Telematikinfrastruktur der gematik angebunden. Die Vernetzung erfolgt dynamisch unter Nutzung der von der gematik bereitgestellten Lokalisierungsmechanismen. 11

14 Aufgrund der»kapselung«durch Sicherheits- und Kommunikationsarchitektur kann für die Anwendungsarchitektur eine hohe Stabilität erzielt werden. D. h. die Spezifikationen der gematik können potenziell zwar Änderungen an der Sicherheits- und/oder Kommunikationsarchitektur erfordern, werden aber kaum die Funktionalität der elektronischen Fallakte und damit die Anwendungsarchitektur beeinflussen. Daher ist davon auszugehen, dass die in diesem Dokument funktional spezifizierten Dienste und Schnittstellen über alle drei Einführungsphasen hinweg nur marginal verändert werden Fat Clients vs. Thin Clients Aus den Rahmenbedingungen der efa-nutzung heraus ergibt sich die Notwendigkeit, sowohl über Browser (»Thin-Client-Szenario«) als auch über einen einem Primärsystem vorgeschalteten (oder darin integrierten) Proxy (»Fat-Client-Szenario«) auf elektronische Fallakten zugreifen zu können. Bei dem Fat-Client-Szenario wird davon ausgegangen, dass als Client- System ein PVS oder KIS angebunden ist. Der Client greift dabei über einen Proxy (Konnektor) auf hinter einem Broker (Fassade) gekapselte serverseitige Dienste zu. Diese Dienste liefern Sicherheitstoken, Strukturinformationen und Schlüssel, mit denen im KIS/PVS die Aktenstruktur angezeigt und darin enthaltene Dokumente vom Server angefordert werden können. Abbildung 2 Zugriff auf die efa über ein KIS/PVS mit integriertem Proxy (Fat Client) Identity Mgmt. KIS / PVS Proxy Karten, etc. efa Broker efa Dienste Datenspeicher efa Broker efa Dienste Datenspeicher Krankenhaus/Arztpraxis Primärer efa-provider Entfernter efa-provider Das Fat-Client-Szenario ist in den Varianten mit eng gekoppeltem und mit lose gekoppeltem Proxy in [efa_secarch-10] (Abschnitte und 4.5.2) ausführlich beschrieben. 12

15 Als weitere Umsetzungsoption wird ein»thin Client«unterstützt, mit dem ohne aufwändige Softwareinstallation auf dem Client über einen Browser auf eine über ein Portal präsentierte efa zugegriffen werden kann. Serverseitig werden dabei die Anzeige einer Aktenstruktur (Präsentation), wesentliche Such- und Sortieroperationen sowie Auswahl und Abruf von Daten realisiert. In dem Thin-Client-Szenario greift der Arzt über seinen Browser der um einen Enabler bzw. ein Plug-In/Applet als»schlanke«ausführung eines Proxys erweitert wurde auf ein vom Krankenhaus oder einem anderen Provider bereitgestelltes Portal zu. Über das Portal kann der Arzt eine Fallakte auswählen und sich die Struktur der Inhalte anzeigen lassen. Die Erzeugung der Präsentation durch Dekodierung der Aktenstruktur erfolgt serverseitig auf dem Portal. Beim Anfordern eines Dokuments sind beide Modelle identisch: Das Dokument wird verschlüsselt aus einem Datenspeicher ausgelesen und erst clientseitig im»fat Client«bzw. im»enabler«des Browsers mit Hilfe eines nur dem berechtigten Empfänger zugänglichen Schlüssels entschlüsselt. Abbildung 3 Zugriff auf die efa über einen Browser (Thin Client) Identity Mgmt. Browser Enabler Karten, etc. Portal efa Broker efa Dienste Datenspeicher efa Broker efa Dienste Datenspeicher Krankenhaus/Arztpraxis Primärer efa-provider Entfernter efa-provider Das Thin-Client-Szenario in den Varianten des aktiven und des passiven Requestors ist in [efa_secarch-10] (Abschnitte und 4.5.4) ausführlich beschrieben. Wesentlicher Unterschied der beiden generellen Umsetzungsoptionen Fat Client und Thin Client in Bezug auf die Konzeption und Realisierung der Anwendungsarchitektur ist die Verteilung der im Proxy angesiedelten Funktionalität. Während im Fat-Client-Szenario die serverseitigen Dienste vorwiegend dem Berechtigungsmanagement und dem Datenzugriff dienen, müssen im Thin-Client-Szenario auch Funktionalitäten wie das Suchen nach Akten eines Patienten, die Navigation durch eine Aktenstruktur und der 13

16 Abruf von Metadaten serverseitig durch ein potenziell nicht zur Einsichtnahme in die Daten berechtigtes Portal geleistet werden können. Zusätzlich muss das Portal in der Lage sein, weite Teile der beim Fat-Client- Szenario im Primärsystem angesiedelten Funktionen zur Visualisierung von Aktenstrukturen und Metadaten zu realisieren. Die Basis für die Verlagerung weitreichender Funktionalitäten vom Client auf ein Portal wird durch das Sicherheitskonzept und die Sicherheitsarchitektur gelegt. Dadurch, dass bereits beim Suchen nach Akten bzw. beim Zugriff auf eine Akte der Personenbezug medizinischer Daten durch die Nutzung von pseudonymisierenden Zugangscodes nicht mehr gegeben ist, kann ein Portal in Bezug auf den Zugang zu Struktur- und Metainformationen als Stellvertreter des zugreifenden Arztes agieren, ohne dass dadurch der Schutzbedarf der medizinischen Daten verletzt würde. Aufgabe der Anwendungsarchitektur ist es, entsprechende Schnittstellen bereitzustellen, die sowohl von einem Client (als externer Dienstaufruf) als auch von einem Portal (als interner Dienstaufruf) genutzt werden können. Die in diesem Dokument funktional spezifizierte Anwendungsarchitektur besitzt genau diese Eigenschaft. Aus diesem Grund wird bei der Spezifikation der Dienste und Schnittstellen weitgehend von der Realisierung des Clients abstrahiert. Die Nutzung der Schnittstellen sowohl durch einen Fat Client als auch durch ein (durch einen Browser gesteuertes) Portal wird jedoch durch entsprechende Ablauf-Sichten (Sequenzdiagramme) explizit dargestellt, um die Umsetzbarkeit beider Szenarien zu demonstrieren. 2.3 Notation Zur Darstellung der funktionalen Spezifikationen von Sicherheitsobjekten, -mechanismen und -diensten wird eine formalisierte Notation verwendet. Semantische Basis der Notation ist die formale Sprache»Z«. Um die Lesbarkeit zu erhöhen und insbesondere bei der Darstellung der Dienstabläufe auch informelle Beschreibungselemente zuzulassen, wurde die»z«-semantik an vielen Stellen durch eine an objektorientierte Programmiersprachen angelehnte Syntax gekapselt. Eine kurze Einführung in die Elemente der Notation sowie Spezifikationen der grundlegenden Datentypen sind in den Anhängen A und B dieses Dokuments dargestellt. Zur Spezifikation konkreter Daten- und Nachrichtentypen (Feinspezifikation) wird XML-Schema verwendet, da Dienste der efa im Normalfall durch den Austausch von in XML kodierten Nachrichten miteinander kommunizieren. In der Kommunikation eines Thin Client mit einem Portal können andere 14

17 auch proprietäre Kodierungen zum Einsatz kommen. Es wird jedoch davon ausgegangen, dass diese Kodierungen im Rahmen der Implementierungen durch das serverseitige Binding auf XML abgebildet werden. 2.4 Konventionen Die Verbindlichkeit von in diesem Dokument enthaltenen Spezifikationen und Vorgaben wird durch die in [RFC2119] festgelegten Schlüsselwörter»MUST«,»SHOULD«,»MAY«,»SHOULD NOT«und»MUST NOT«angezeigt: MUST: Die so ausgezeichnete Spezifikation oder Anforderung ist verbindlich (normativ) in der beschriebenen Art und Weise bzw. mit dem vorgegebenen Verhalten umzusetzen. SHOULD: Eine so ausgezeichnete Spezifikation oder Anforderung sollte von jeder efa-implementierung umgesetzt werden. Es handelt sich jedoch nur um eine Empfehlung, von der in begründeten Ausnahmefällen abgewichen werden kann. MAY: Die Umsetzung einer so ausgezeichneten Spezifikation oder Anforderung ist dem Realisierer bzw. Anbieter einer efa freigestellt. SHOULD NOT: Eine so ausgezeichnete Realisierungsoption darf von einer efa-implementierung nur in begründeten Ausnahmefällen umgesetzt werden. MUST NOT: Eine so ausgezeichnete Aussage beschreibt eine Realisierungsoption, die nicht zulässig ist. Um Missverständnisse bei der Interpretation der diesen Schlüsselwörtern semantisch entsprechenden deutschen Formulierungen zu vermeiden, werden bei allen derartigen Aussagen und Spezifikationen die englischen Schlüsselwörter am Ende der Aussage in Klammern angefügt. Beispiel: Alle Implementierungen der efa müssen alle Algorithmen der als default gekennzeichneten Algorithmenfamilie unterstützen (MUST). In den Einführungsphasen 1 und 2 sollte eine zweite Algorithmenfamilie unterstützt werden (SHOULD). Diese Vorgabe wird für die Einführungsphase 3 verbindlich (MUST). 15

18 2.5 Gliederung des Dokuments In der nachfolgenden Grafik sind die Gliederung dieses Dokuments und der Zusammenhang der einzelnen Kapitel dargestellt. Abbildung 4 Dokumentenübersicht Grundlagen der Anwendungsarchitektur (Kapitel 3) Use-Cases Konzeptmodell Sicherheit / Datenschutz Konzeptionelles Prinzip Lösungskonzept (Kapitel 4) Anwendung im Kontext efa Identifikation der Dienste Datentypen Anwendungsarchitektur (Kapitel 5, 6, 7, 8) Dienstschnittstellen Nutzungsszenarien Security Token Realisierungshinweise (Kapitel 9) Der serviceorientierte Ansatz, die Charakteristik, der Aufbau und die Use- Cases der elektronischen Fallakte, das daraus resultierende konzeptionelle Modell sowie die Anforderungen hinsichtlich Vernetzung und Sicherheit bzw. Datenschutz sind in Kapitel 3 als Grundlage der Entwicklung der Anwendungsarchitektur beschrieben. Darauf folgt in Kapitel 4 das Lösungskonzept mit der Erläuterung des konzeptionellen Prinzips, seiner Anwendung im Kontext der elektronischen Fallakte, der Darstellung der aus dem konzeptionellen Modell abgeleiteten Modelle zur Navigation und zum Zugangs- bzw. Zugriffsschutz sowie der identifizierten Dienste. 16

19 Die Kapitel 5, 6, 7 und 8 beschreiben die Anwendungsarchitektur. Kapitel 5 gibt einen Überblick zu den Komponenten des Clients sowie den Diensten in der demilitarisierten Zone, der Servicezone und dem Intranet. In Kapitel 6 werden die Schnittstellen der Dienste auf der Seite der Anbieter und in Kapitel 7 die Schnittstellen der Komponenten des Clients auf der Seite der Nutzer elektronischer Fallakten spezifiziert. Die Nutzungsszenarien in Kapitel 8 verdeutlichen die Anwendung der Schnittstellen zur Realisierung der Use-Cases aus Kapitel 3. Kapitel 9 gibt Hinweise zur Unterstützung der Realisierung der Anwendungsarchitektur. 17

20 3 Grundlagen der Anwendungsarchitektur 3.1 SOA und Web Services Für die Telematik-Infrastruktur zur elektronischen Gesundheitskarte wurde bereits in der bit4health-rahmenarchitektur die Umsetzung als serviceorientierte Architektur (SOA) [SOA] empfohlen. Diese Empfehlung wurde von den nachfolgenden Konkretisierungen der Rahmenarchitektur (Solution Outline [b4h04.2], FuE Lösungsarchitektur [FuE05.1], gematik Architekturspezifikation [gem05.1], [gem05.2]) aufgegriffen und als wesentliche Anforderung an die Spezifikation der Telematik-Infrastruktur festgeschrieben. In Abbildung 5 ist der grundsätzliche Aufbau einer serviceorientierten Architektur dargestellt. Abbildung 5 Prinzipieller Aufbau einer serviceorientierten Architektur Präsentation: Primärsysteme, ekioske und über Browser zugreifbare Portale als Schnittstellen für den Nutzer Geschäftsprozesse: Verknüpfen von einzelnen Diensten zu automatisiert ablaufenden Prozessen Dienste: Erbringen der an den fachlichen Anforderungen ausgerichteten Funktionalitäten durch realisierungsunabhängige einfache bzw. zusammengesetzte Dienste Anwendungen: Realisieren einer anforderungsgerechten Verwaltung von Daten und Zugriffsrechten Presentation Business processes Services Applications Service Integration Business Process Management Infrastruktur: Datenspeicher, Systemmanagement, VPN, etc. Infrastructure Wesentliche Merkmale serviceorientierter Architekturen sind: Lose Kopplung von Diensten Dienste werden über Funktionalitäten beschrieben und über ihre Schnittstellen spezifiziert. Wenn ein Dienst einen anderen Dienst nutzen will, importiert er zunächst die Schnittstellenspezifikation und erzeugt ein entsprechend parametrisiertes Binding. Teil der Schnittstellenspezifikation können dabei auch Informationen zur 18

21 Verschlüsselung von Parametern oder zur Signierung von Teilen einer Nachricht (s. u.) sein. Die Adressierung von Diensten erfolgt auf der Anwendungsebene nicht über IP-Adressen oder URLs, sondern über logische Dienstnamen. Kommunikation über Nachrichten Dienste kommunizieren untereinander über Nachrichten. Hierbei wird auf Anwendungsebene von konkreten Transportmechanismen abstrahiert. Angaben zur Transportqualität sind Bestandteil der Schnittstellenspezifikation, auf die das Nachrichtenformat abgebildet wird. Zustandslose Dienste Dienste einer SOA sind per Definition zustandslos. Hierdurch ist ein Client nicht an eine Dienstinstanz gebunden, und Dienste können sehr leichtgewichtig realisiert werden. Enterprise Service Bus Mechanismen zum Nachrichtentransport, zur Dienstelokalisierung und zum Schutz von Nachrichten und Daten sind konzeptionell in einem Enterprise Service Bus gekapselt, der damit alle benötigten Funktionalitäten zu einer transparenten Diensteintegration bietet. Insbesondere für die Spezifikation komplexer, in bestehende Landschaften zu integrierender Anwendungssysteme sind serviceorientierte Architekturen wegen der klaren Trennung von Funktionalitäten zur Umsetzung von anwendungsspezifischen Kontrollflüssen, zur Verwaltung von Daten und zur Kommunikation zwischen Systemkomponenten gut geeignet. Sie können damit zumindest aus einer konzeptionell-funktionalen Sicht heraus eine erheblich beherrschbarere Partitionierung der Architektur beschreiben, als dies zum Beispiel bei einem objektorientierten Konzept mit enger Kopplung von Daten und darauf operierenden Diensten der Fall ist. Wesentlich hierbei ist, dass eine funktional als SOA konzipierte und beschriebene Architektur nicht zwingend auch als SOA implementiert werden muss. Für die Spezifikation elektronischer Fallakten wurde insbesondere auch deshalb SOA als grundlegendes Architekturkonzept gewählt, da davon ausgegangen wird, dass in den Krankenhäusern bereits Anwendungen zur Verwaltung medizinischer Daten existieren, die (lediglich) durch eine vereinheitlichende Dienste-Schicht gekapselt und durch Mechanismen zur Kommunikation mit anderen Akteuren ergänzt werden müssen. Durch die gegebene Flexibilität der darauf aufbauenden Abstraktionsebene der Geschäftsprozesse kann bei entsprechendem Zuschnitt der Dienste eine hohe Flexibilität erzielt werden, die es im Rahmen konkreter Umsetzungen von Fallakten ermöglicht, weitere Nutzungsszenarien zu erschließen, ohne dabei zwingend Änderungen an den serverseitigen Implementierungen vornehmen zu müssen. Zur Realisierung serviceorientierter Architekturen werden i. Allg. Web Services für die Implementierung von Diensten, WSDL [WSDL] zur 19

22 Spezifikation von Schnittstellen und SOAP [SOAP] für die Kodierung der zwischen den Diensten ausgetauschten Nachrichten eingesetzt. Für die Spezifikation von Anwendungs- und Sicherheitsarchitektur der elektronischen Fallakte wurden die Konzepte serviceorientierter Architekturen der funktionalen Spezifikation und der Dekomposition von Daten und Diensten zugrunde gelegt. Die Abläufe zur Erbringung der Anwendungslogik und insbesondere auch die Integration von Sicherheitsund Anwendungsdiensten in einem Netz von weitgehend autonomen Diensteanbietern basieren hingegen auf einer sog. Web Service Security Architecture. Besondere Merkmale einer Web Service Security Architecture sind die in Kapitel 2.3 näher beschriebenen Konzepte des Single Sign-On und des One-Stop-Shopping. Zur Weitergabe von Autorisierungen und Identitäten werden sog. Sicherheitstoken eingesetzt, die von dedizierten Diensten erzeugt und von allen in einem gemeinsamen Kontext operierenden Diensten akzeptiert werden. Die Sicherung des Nachrichtenaustauschs erfolgt für die Dienste transparent durch zuvor auf Middleware-Ebene zwischen diesen vereinbarte Sicherheitsobjekte und -mechanismen. Im Kontext von Web Service Security Architectures eingesetzte Standards sind SAML [SAML-11] sowie WS Security [WS Security] und darauf aufbauende Spezifikationen wie z. B. WS Trust [WS Trust]. Die Vernetzung von Diensten verschiedener, autonomer Provider erfordert neben einer globalen Adressierung auch Mechanismen zum Abgleich von Authentisierungen und Autorisierungen. Aus dem Konzept einer Web Service Security Architecture heraus wird dieses auf einer übergeordneten Ebene über Föderationen (siehe auch Abschnitt 3.3) realisiert. In die Architektur der elektronischen Fallakte wurde hierzu ein sog. Federation Service als Teil der Dienst-Integrations-Schicht eingefügt, der genau diese Funktionalitäten des Identity und Authorization Mapping sowie der clusterübergreifenden Lokalisierung kapselt. Für die Umsetzung der Dienstevernetzung sowohl innerhalb eines Clusters als auch zwischen Clustern können die Spezifikationen der elektronischen Fallakte auf vorhandene Spezifikationen wie z. B. WS Federation Language [WS- Federation], Liberty Identity Web Services Framework und IHE Cross- Enterprise User Authentication abgebildet werden. 3.2 Charakteristika elektronischer Fallakten In einem Behandlungsszenario dient die elektronische Fallakte (efa) als zweckgebundenes, in Bezug auf den Lebenszyklus an einen Krankheitsfall gekoppeltes Kommunikationsmedium zwischen den beteiligten Ärzten. Dabei werden verifizierbare Kopien von medizinischen Datenobjekten 20

23 ausgetauscht. Dieser Austausch geschieht auf eine vertrauliche, integre und nachvollziehbare Weise. Durch die Kopplung an einen»behandlungsfall«aus Patientensicht unterscheidet sich die efa sowohl von der verpflichtend zu führenden Behandlungsdokumentation der Leistungserbringer als auch von der Patientenakte nach 291a SGB V dar: Im Gegensatz zur Primärdokumentation ist die efa darauf ausgelegt, die Kooperation zwischen verschiedenen Einrichtungen zu unterstützen. Sie ist kein Ersatz für eine Behandlungsdokumentation, sondern dient vorrangig dem Datenaustausch zwischen verschiedenen Akteuren im Kontext der Behandlung eines Patienten. In einer efa können darüber hinaus von verschiedenen Einrichtungen erhobene Daten aus verschiedenen, mit einer Indikation im Zusammenhang stehenden Behandlungsepisoden zusammengefasst werden. Im Gegensatz zur elektronischen Patientenakte nach 291a SGB V ist die Fallakte eine von den behandelnden Ärzten geführte Akte, deren Zweck durch die Bindung an einen Behandlungsfall abgrenzbar ist. Für das Anlegen und die Nutzung einer Fallakte ist ebenso wie für die Festlegung der zugriffsberechtigten Personen und Einrichtungen die Einwilligung des Patienten die rechtliche Grundlage. Die Einwilligung betrifft jedoch immer die gesamte Akte in ihrer Charakteristik als eigenes, nur im Ganzen nutzbares»werk«. D. h. ein Verbergen einzelner Daten innerhalb der Fallakte durch den Patienten ist nicht vorgesehen. Ein Austausch von Daten zwischen Primärsystem, Patientenakte und Fallakte ist möglich und in vielen Nutzungsszenarien auch sinnvoll (siehe Abbildung 6). Hierbei ist jedoch nicht zwangsläufig eine mehrfache oder zentralisierte Datenhaltung erforderlich; vielmehr soll durch die Spezifikationen zur elektronischen Fallakte ein Konzept realisiert werden, in dem dieselben Daten über verschiedene Zugänge in unterschiedlichen Rechtskontexten nutzbar gemacht werden. 21

24 Abbildung 6 Zusammenhang zwischen elektronischer Patientenakte nach 291a und elektronischer Fallakte Lebenzyklus mit Patienten Verantwortung bei Patienten Kopien in elektronischen Patientenakten und vom Patienten selbst eingestellte (Original-)Daten ( 291a, etc.) Lebenszyklus mit Fall Verantwortung beim Arzt Einwilligung durch Patienten Übergabe (Kopie/Ref.) Übernahme (Kopie) Übergabe (Kopie) Kopien/Referenzen in elektronischen Fallakten ( 137f, 140, etc.) Übergabe (Kopie/Ref.) Übernahme (Kopie) Lebenszyklus nach Archivierungsvorschrift Verantwortung beim Arzt K IS PVS DMS Primärdaten in den Primärsystemen der Leistungserbringer Aufbau von Fallakten Elektronische Fallakten bilden immer einen Fall aus Patientensicht ab, der sich über mehrere stationäre und ambulante Behandlungen erstrecken kann. Fallakten werden serverseitig in einer flachen Struktur verwaltet, die einen Fall im Wesentlichen in einen Bereich, der alle»ambulanten Behandlungen«zusammenfasst, und je einen Bereich für die einzelnen»stationären Aufenthalte«untergliedert. Da es sich dabei um rein logische Zuordnungen handelt, können auch zeitliche Überschneidungen (ambulante Behandlung während eines stationären Aufenthalts oder überlappende stationäre Aufenthalte) abgebildet werden. 22

25 Abbildung 7 Struktur einer elektronischen Fallakte Fallakte Ambulante Behandlungen Stationäre Behandlung <Beginn 1> Stationäre Behandlung <Beginn 2>... Stationäre Behandlung <Beginn N> Pflegedaten Planungsdaten Basisdaten Verzeichnis für Aktivitätsobjekte Informationen zum Patienten, Notfalldaten, CAVE Alle Dokumente von ambulanten Behandlungen Für jeden stationären Aufenthalt ein Verzeichnis, das über das Beginndatum identifiziert wird. Dazu zählen auch ReHa-Aufenthalte. Alle darin enthaltenen Dokumente werden mit Metadaten weiter unterschieden Sonderfall bei DRG-Zusammenfassung von Aufenthalten... Verzeichnis für amb. oder stat. Pflege Z.B. Überleitungsbögen Unter der Kategorie»ambulante Behandlungen«werden alle ambulanten Behandlungen erfasst, auch wenn diese durch Ambulanzen innerhalb von Kliniken erfolgen. Motivation für diese Zusammenfassung ist, dass alle Behandlungen innerhalb einer Fallakte auch in den PVS der Niedergelassenen zu einer einzigen Akte gehören. Mehrere Akten treten dort nur dann auf, wenn zwischen den einzelnen Besuchen so viel Zeit vergeht, dass der Zugang zu einer Akte nicht mehr hergestellt wird. Wegen des Fallbezugs werden aber zeitlich und inhaltlich weit auseinander liegende ambulante Behandlungen nur selten vorkommen. Optional ist es jedoch möglich, die in diesem Bereich eingestellten Daten durch Ordner weiter zu strukturieren. Stationäre Aufenthalte als Bereich (Partition) einer Fallakte korrespondieren immer mit einem im KIS des Krankenhauses angelegten Abrechnungsfall. Es existiert umgekehrt auch eine einfache Abbildung der Abrechnungsfälle des KIS in die efa, wodurch das Einstellen von Dokumenten aus einem KIS in eine efa fast vollständig automatisiert werden kann. Alle in eine efa eingestellten Dokumente werden über Metadaten beschrieben. Anhand der Metadaten können z. B. Informationen zu Formaten und Informationstypen dargestellt und abgefragt werden. Metadaten besitzen neben ihrer informativen auch eine Struktur gebende Funktion. Das bedeutet, dass sich die von einem Client bzw. einem Portal realisierte grafische Darstellung der efa an den Meta-Daten orientieren kann. Hierdurch können aus der bei der Ablage der efa verwendeten normierten Basisstruktur unterschiedliche Sichten für unterschiedliche Nutzungskontexte erzeugt werden. Insbesondere ist so eine Abbildung von der an Zuständigkeiten orientierten Basisstruktur auf fachliche Strukturen möglich. 23

26 Abbildung 8 Abbildung der efa-struktur auf eine Sicht Sicht des Arztes Struktur der efa Fallakte Ambulante Behandlungen Stationäre Behandlung <Beginn 1> Stationäre Behandlung <Beginn 2>... Stationäre Behandlung <Beginn N> Pflegedaten Planungsdaten Basisdaten Use-Cases für elektronische Fallakten Aus den untersuchten Nutzungskontexten heraus sind die nachfolgend aufgeführten Anwendungsfälle identifiziert worden, die von den Diensten der Anwendungsarchitektur unterstützt werden müssen: Anlegen einer Fallakte gemäß einem mit dem Patienten geschlossenen Behandlungsvertrag Identifizieren aller Fallakten eines Patienten, zu denen ein Arzt zugriffsberechtigt ist Suchen der Fallakten aller Patienten eines Arztes Verknüpfen eines (Abrechnungs-) Falls mit einer Fallakte Einstellen eines medizinischen Datenobjekts in eine Fallakte Ändern der Metadaten eines medizinischen Datenobjekts Ändern des Status eines Dokuments Auslesen eines medizinischen Datenobjekts aus einer Fallakte Anlegen von Strukturelementen (Partition, Ordner, etc.) Auflisten von medizinischen Datenobjekten einer Fallakte (ggf. selektiv aufgrund der Anwendung von Filtern auf Metadaten) Anlegen von Sichten auf medizinische Datenobjekte einer Fallakte Auflösen und Archivieren einer Fallakte Ändern der Zugangsrechte zu einer Fallakte Definition von Beziehungen zwischen medizinischen Datenobjekten Anlegen bzw. Auflösen eines Verweises auf ein medizinisches Datenobjekt Beim Anlegen von Fallakten sowie beim Einstellen von Dokumenten ist zu berücksichtigen, dass diese Operationen sowohl aus einem KIS heraus als auch über eine externe Schnittstelle ausgeführt werden können.»interne«abläufe sollten dabei soweit wie möglich automatisierbar sein. 24

27 3.3 Vernetzung von efa-anbietern Ausgangspunkt der Entwicklung der Anwendungsarchitektur für die elektronische Fallakte als Kommunikationsmittel im Kontext der Behandlung eines Patienten durch mehrere Leistungserbringer ist zum einen das Verteilungsmodell und zum anderen das konzeptionelle Modell der relevanten Entitäten. Die elektronische Fallakte ist als verteilte föderative Anwendung realisiert. Dazu ist eine Infrastruktur mit gleichberechtigten vernetzten Knoten notwendig, die jeweils Dienste zur Bereitstellung und Verwaltung elektronischer Fallakten anbieten. Die Kommunikation dieser Dienstanbieterknoten erfolgt unter Nutzung des Internets über Schnittstellen, die im Kontext der elektronischen Fallakte vorgegeben werden. Abbildung 9 Logische Vernetzung von Dienstanbietern und -nutzern der elektronischen Fallakte MVZ Arzt MVZ Arzt Arzt Arzt Arzt efa- Provider efa- Provider Arzt Arzt efa- Provider Arzt Reha Arzt Reha MVZ Reha Die Anbindung der Dienstnutzer an die Systeme der efa-anbieter erfolgt ebenfalls über definierte Schnittstellen. Als Kommunikationsmedium wird das Internet verwendet. Für die beiden ersten Phasen der efa-einführung wird davon ausgegangen, dass efa-nutzer bei einem efa-anbieter registriert sind, der die Authentisierung und Autorisierung des Nutzers anhand der Registrierungsdaten durchführen kann. Ab Phase drei muss jeder efa-provider eine Anmeldung über einen HBA unterstützen. Die Inanspruchnahme von Gruppenrechten ist jedoch auch in dieser Phase 25

28 potenziell nur möglich, wenn die Authentisierung über den Provider erfolgt, der die Gruppenzugehörigkeiten des HBA-Besitzers verwaltet 1. Eine bei einem Provider durchgeführte Authentisierung wird von allen anderen Providern ggf. nach Abbildung auf die eigene Sicherheits-Policy akzeptiert. Das so realisierte Single-Sign-On ist im Detail im Kapitel 3 der Sicherheitsarchitektur zur elektronischen Fallakte beschrieben [efa_secarch-10]. Die Möglichkeit der Nutzung von efa-diensten verschiedener Anbieter bleibt hiervon unberührt. Diese werden jedoch von einem efa-nutzer nicht direkt angesprochen, sondern immer indirekt über den Broker bzw. das Portal des efa-providers, bei dem der Nutzer authentisiert wurde. Hierdurch hat jeder efa-nutzer immer einen festen Einstiegspunkt, wodurch der Client keine eigenen Funktionalitäten zur Lokalisierung und zum semantischen Mapping von Authentisierungs- und Autorisierungsnachweisen vorhalten muss und entsprechend schlanker gestaltet werden kann. Das so realisierte Brokering entspricht dem im ecommerce weit verbreiteten Konzept des One-Stop- Shopping. 3.4 Konzeptionelles Modell Die relevanten Entitäten der elektronischen Fallakte wurden in Prozessanalysen der Behandlungsszenarien identifiziert, in einem konzeptionellen Modell strukturiert und zueinander in Beziehung gesetzt. Abbildung 10 zeigt dieses konzeptionelle Modell. 1 Alternativ kann ein efa-provider in diesem Fall eine Abfrage nach Informationen zu einem HBA- Besitzer bei anderen Providern initiieren. Diese Option wird momentan jedoch lediglich empfohlen (SHOULD) und nicht verpflichtend vorgeschrieben. Sofern die über den HBA verfügbaren Attribute jedoch nicht ausreichend sein sollten, um efa-typische Berechtigungsszenarien abzubilden, wird die efa-spezifikation um eine entsprechende Abfrageschnittstelle erweitert. 26

29 Abbildung 10 Konzeptionelles Modell der elektronischen Fallakte (Objektmodell) Ein Patient wird in einem Behandlungsszenario von einem oder mehreren Leistungserbringern behandelt. Im Zuge dieser Behandlungen werden für den Patienten eine oder mehrere elektronische Fallakten mit medizinischen Datenobjekten wie Dokumenten oder Röntgenbildern zu je einem Fall angelegt. Durch eine Patienteneinwilligung gibt der Patient den Leistungserbringern oder Gruppen von Leistungserbringern die Zugriffsberechtigung auf die elektronische Fallakte. Ein Leistungserbringer, z. B. ein Arzt, behandelt einen oder mehrere Patienten, deren Identifikation (z. B. die Krankenversicherungsnummer) er kennt. Mit der Patientenidentifikation möchte er auf die elektronischen Fallakten des Patienten zugreifen und medizinische Datenobjekte in entsprechenden Partitionen und Ordnern ablegen oder aus ihnen entnehmen. 3.5 Schutz personenbezogener Daten Durch die Vernetzung der Anbieter elektronischer Fallakten werden zum einen die medizinischen Datenobjekte aus der gesicherten Umgebung des Krankenhausinformationssystems eines Dienstanbieters (Knoten) über das Internet herausgegeben. Zum anderen wird der Kreis der Personen, die potenziell Zugriff auf die Systeme zur Verwaltung medizinischer Datenobjekte erlangen können, stark vergrößert, wodurch sich auch das Risiko des unrechtmäßigen Zugriffs sowie der unrechtmäßigen Zusammenführung der Informationen wesentlich erhöhen kann. Aus diesem 27

30 Grund muss bei der Konzeption der Anwendungsarchitektur ein besonderes Augenmerk auf dem Schutz der Vertraulichkeit der medizinischen Daten eines Patienten liegen. Medizinische»Datenobjekte müssen daher so gespeichert werden können, dass sie kein Merkmal tragen, über das unberechtigte Personen auf eine Personenzuordnung schließen können.«2 Bei medizinischen Datenobjekten wie z. B. Arztbriefen oder Röntgenbildern muss man davon ausgehen, dass ein Bezug zum Patienten im Normalfall im Dokument enthalten ist 3. Die Datenobjekte selbst können nur durch eine Verschlüsselung bzw. einen entsprechend sicheren Speicherort geschützt werden. Allerdings müssen die medizinischen Datenobjekte mit Metadaten annotiert werden, um vor einer Entschlüsselung bzw. dem Zugriff eine geordnete Übersicht zu den Objekten herstellen zu können. Diese Metadaten enthalten i. d. R. auch medizinisch interpretierbare und damit schützenswerte Informationen wie z. B. eine Diagnose. Deshalb dürfen diese Metadaten keinen Rückschluss auf die Identität des Patienten zulassen weder direkt noch indirekt. Entsprechendes gilt für die Information über die Existenz einer oder mehrerer Fallakten sowie den Bezug zu den Leistungserbringern wie den behandelnden Ärzten. Allein die Information, dass ein Psychiater Zugriff auf eine elektronische Fallakte einer Person des öffentlichen Lebens hat, kann für die betroffene Person existenzbedrohend sein. Als Quelle dieser Informationen sind neben den eigentlichen Datenspeichern auch Zugriffs- bzw. Berechtigungslisten sowie Protokolle von Diensten zu berücksichtigen. Aus diesem Grund wurden bei der Analyse der Schutzbedarfe neben den Objekten selbst auch mögliche Schutzverletzungen durch Zusammenführung von Objekten entlang der die Beziehungen zwischen den Objekten kennzeichnenden Kanten des Objektmodells (Abbildung 10) betrachtet [efa_sdk-10]. 2 MDO.T.04 in [efa_sdk-10] 3 Dies ist notwendig, da ein zugreifender Arzt nur so selbst die Integrität und Authentizität der Personenzuordnung eines Dokuments verifizieren kann. 28

31 4 Lösungskonzept Um die in Kapitel 3.5 zusammengefassten, im Rahmen der Schutzbedarfsanalyse erhobenen Schutzanforderungen umzusetzen, wurde vor der Konzeption der Anwendungsarchitektur eine Sicherheitsstrategie entwickelt. Die dort formulierten technischen und architektonischen Schutzmaßnahmen Ende-zu-Ende-Verschlüsselung beim Austausch von medizinischen Daten Nutzung von Zugangscodes zur»kappung«des Patientenbezugs direkt beim Einstieg in die efa-navigation Integritätssicherung durch die Verfahren zur Bildung von Zugangscodes Ableitung von Zugangscodes und Zugangstoken entlang der Navigation bilden die Grundlage der Anwendungsarchitektur. Zum besseren Verständnis der in den Kapiteln 5 und 6 dieses Dokuments spezifizierten Anwendungsdienste sollen in diesem Kapitel zunächst die grundlegenden Konzepte und Algorithmen anhand des von konkreten Diensten abstrahierenden Objekt- und Navigationsmodells dargestellt werden. Hierzu werden die eingesetzten Mechanismen schrittweise aus den Anforderungen des Sicherheitskonzepts und der fachlogischen Analyse hergeleitet. Das Lösungskonzept beruht auf der grundsätzlichen Unterscheidung zwischen der Autorisierung eines authentisierten Nutzers zur Nutzung eines Dienstes und dem Zugriff auf die medizinischen Datenobjekte eines Patienten. Um auf Daten einer Fallakte zugreifen zu können, muss ein Nutzer deshalb zunächst eine Autorisierung zur Nutzung eines Zugangs der Anwendung»elektronische Fallakte«erlangen und anschließend nachweisen, dass er zum Zugriff auf eine konkrete Fallakte berechtigt ist. Hierdurch werden zwei Ebenen der Berechtigung auf Fallakten ermöglicht: 1 Der Patient erlaubt einer bestimmten Gruppe von Ärzten, eine Übersicht über seine vorhandenen Fallakten zu erlangen. 2 Der Patient erlaubt einer bestimmten Gruppe von Ärzten einen Zugang zu einer konkreten Fallakte. Der Übergang von der ersten zur zweiten Ebene kann dabei sowohl statisch als auch dynamisch oder regelbasiert-situationsgebunden erfolgen: Statisch: Die jeweils berechtigten Gruppen von Ärzten sind identisch. Dynamisch: Der Patient erweitert aus einer Behandlungssituation heraus die Berechtigungen zur Nutzung einer efa, d. h. ein zu den Berechtigten der ersten Ebene gehörender Arzt wird in die Gruppe der Berechtigten der zweiten Ebene aufgenommen. 29

32 Situationsgebunden: Ein Mitglied der Gruppe der zum Auflisten der efa berechtigten Ärzte wird aufgrund externer Kontextmerkmale (z. B. Vorliegen eines Notfalls) temporär in die Gruppe der Berechtigten auf der zweiten Ebene aufgenommen. Wesentlich für die Ausgestaltung der Algorithmen zum Zugang zu Fallakten ist die Forderung des Sicherheitskonzepts nach einer strikten Kappung des Personenbezugs von den medizinischen Daten. Bei der Spezifikation der Dienstschnittstellen für die elektronische Fallakte muss daher darauf geachtet werden, dass die einen Patienten identifizierenden Daten nicht in den Parametern der Operationen zusammengeführt werden. Zumindest sollte dies auf eine Stelle begrenzt werden, die besonders geschützt ist und administrativ von den die Daten verwaltenden Diensten getrennt werden kann. Aus diesen Überlegungen heraus stellt jeder Zugang zur efa-anwendung in einem ersten Schritt eine Pseudonymisierung des Patienten mit Hilfe eines sog. Zugangscodes her. Alle folgenden Operationen nutzen zur Identifizierung der dem Patienten zugeordneten Daten ausschließlich den Zugangscode. Die Authentisierung und Autorisierung eines zugreifenden Arztes erfolgt durch Dienste der efa-sicherheitsarchitektur. Die korrekte Identifizierung von Ärzten und Patienten in Bezug auf Datenzuordnungen und Berechtigungen wird durch die Kodierung der Zugangscodes sichergestellt. Die Authentisierung eines Patienten erfolgt dezentral durch den Arzt (z. B. durch Vorlage von KVK oder egk). 4.1 Funktionale Spezifikation elektronischer Fallakten Die konkret realisierten Systeme zur Verwaltung von elektronischen Fallakten geben die nachfolgend funktional spezifizierte Außensicht einer Fallakte wieder. Alle in diesem Dokument beschriebenen Dienste zum Auffinden, Bearbeiten und Nutzen von Fallakten basieren auf dieser Sicht. efa : efaid x efaaccesscode+ x efaadmissiontable x efametadata x efacontent efaid : ObjectID Jede Fallakte setzt sich demnach logisch aus den folgenden Bestandteilen zusammen: Eindeutige Objekt-ID (siehe Kapitel 4.5 der Sicherheitsarchitektur [efa_secarch-10]) Ein oder mehrere Zugangscodes Jeder authentisierte Nutzer, der einen authentischen (d. h. von einer vertrauenswürdigen Stelle signierten) Autorisierungsnachweis mit einem 30

33 dieser Zugangscodes besitzt, ist damit zumindest berechtigt, die Metadaten der efa zu sehen (Berechtigter der Ebene 1, s. o.). Datenstruktur zur Verwaltung von Zugriffsrechten auf die efa und damit die darin enthaltenen Daten Zusätzliche Informationen zu der Fallakte (siehe [efa_dado-10]) Strukturiert in die Fallakte eingestellte medizinische Datenobjekte 4.2 Konzeptionelles Prinzip Um die Vorteile der auf Zugangscodes basierenden Berechtigungsverwaltung und -prüfung aufzuzeigen und die Abläufe zum Auffinden und Nutzen von Fallakten zu verdeutlichen, wird im Folgenden ein vereinfachtes Beispiel herangezogen. Ein Patient hat eine elektronische Fallakte (Abbildung 11). Abbildung 11 Patient und elektronische Fallakte Zwischen Patient und elektronischer Fallakte existiert eine bidirektionale Beziehung. Bei diesem Modell ist es grundsätzlich möglich, zum Patienten dessen elektronische Fallakte und umgekehrt zur elektronischen Fallakte den Patienten zu ermitteln. Von den Diensten der Anwendungsarchitektur müssen zum Schutz der Vertraulichkeit personenbezogener Gesundheitsinformationen zwei Anforderungen des Sicherheitskonzepts umgesetzt werden: 1 Die Beziehung zwischen Patient und elektronischer Fallakte ist nur von berechtigten Personen herstellbar. 2 Die Beziehung zwischen Patient und elektronischer Fallakte kann nur unidirektional vom Patienten zur efa hergestellt werden. Die erste Anforderung wird dadurch realisiert, dass die direkte Beziehung zwischen Patient und elektronischer Fallakte durch eine assoziative Klasse ersetzt wird. 31

34 Abbildung 12 Beziehung zwischen Patient und efa als assoziative Klasse Die zusätzliche assoziative Klasse»Zugang«stellt über die Identifikatoren von Patient und elektronischer Fallakte die Beziehung zwischen beiden her. Die Beziehung besteht also nicht mehr direkt, sondern ist nur über einen expliziten Zugang möglich. Ein vertrauenswürdiger Dienst kann diesen Zugang für berechtigte Nutzer herstellen und anderen verweigern. Durch einen solchen Dienst kann also das Wissen um die Beziehung zwischen Patient und elektronischer Fallakte kontrolliert werden. Allerdings ist die Beziehung noch bidirektional. Um die zweite Anforderung erfüllen zu können, darf der Zugang nur vom Patienten aus zur elektronischen Fallakte erfolgen und nicht umgekehrt. Für die Realisierung muss eine unidirektionale irreversible Kodierung (one-way function) des Patientenidentifikators im Zugang zur elektronischen Fallakte verwendet werden. Für die unidirektionale irreversible Kodierung des Patientenidentifikators kann eine kryptographische Hash-Funktion in Verbindung mit einem Geheimnis verwendet werden. Dieses Geheimnis kennt nur der Dienst, der den Zugang zur elektronischen Fallakte für berechtigte Nutzer herstellt. 32

35 Abbildung 13 Unidirektionaler Zugang zur elektronischen Fallakte Bildet man den Zugang zu einer elektronischen Fallakte eines Patienten in einer Relation ab, könnte diese wie folgt aussehen: Tabelle 1 Zugang zur elektronischen Fallakte eines Patienten über eine Relation Patient Hash(Geheimnis des ausstellenden Dienstes, Identifikator Patient XYZ) Identifikator elektronische Fallakte Identifikator der efa des Patienten XYZ Der Zugang zur elektronischen Fallakte erfolgt über ein Pseudonym. Dieses Pseudonym kann nur von einem vertrauenswürdigen Dienst erzeugt werden, da es dessen Geheimnis enthält. Dieser gibt das Pseudonym nur an authentisierte berechtigte Nutzer heraus. Eine De-Pseudonymisierung ist wegen des Einsatzes einer Einwegfunktion zur Erzeugung des Pseudonyms nicht möglich. Das Pseudonym muss vom ausstellenden Dienst signiert und dessen Verwendung muss durch einen Zeitstempel gegen das Wiedereinspielen geschützt werden. In Kombination mit einer hinreichend starken Verschlüsselung der medizinischen Datenobjekte und deren Annotation mit Metadaten ohne jeglichen Patientenbezug ist ein Rückschluss auf den Patienten ausgehend von der elektronischen Fallakte, ihren Datenobjekten und den Metadaten für Unberechtigte nicht möglich. Dennoch können für Berechtigte die elektronischen Fallakten eines Patienten ermittelt und genutzt werden, wenn die den Patienten identifizierenden Daten bekannt sind. 33

36 4.3 Anwendung im Kontext der elektronischen Fallakte Im vorigen Abschnitt wurde ein Prinzip zur Identifikation von elektronischen Fallakten eines Patienten über ein Pseudonym beschrieben. Es wurde dabei vorausgesetzt, dass ein vertrauenswürdiger Dienst diese Pseudonyme nur an berechtigte Nutzer herausgibt. Die Berechtigungen der Nutzer hinsichtlich des Zugangs zu elektronischen Fallakten müssen über Zugriffskontrolllisten verwaltet werden. Diese stellen gerade bei personifizierten Berechtigungen eine Gefahr hinsichtlich des möglichen Rückschlusses auf schützenswerte Informationen zu einem Patienten dar. Der Berechtigte kann identifiziert, dadurch sein Fachgebiet ermittelt und damit können Schlussfolgerungen über die Patienten gezogen werden, zu deren efas er Zugriff hat. Der Zugriff auf die elektronische Fallakte eines Patienten bzw. dessen Kontrolle ist mindestens durch die folgenden drei Parameter gekennzeichnet: Identifikator des Patienten, zu dem die elektronische Fallakte gehört Identifikator des berechtigten Leistungserbringers bzw. der berechtigten Gruppe Identifikator der elektronischen Fallakte bzw. ihrer Daten Um den Zugriff auf die elektronischen Fallakten zu ermöglichen und zu kontrollieren, ohne dass der Zusammenhang zwischen diesen drei Zugriffsparametern erkennbar wird, sollen Zugangscodes verwendet werden, die nach dem im vorigen Abschnitt beschriebenen Prinzip erzeugt und ausgegeben werden. Abbildung 14 zeigt vereinfacht den konzeptionellen Zusammenhang. Abbildung 14 Berechtigung eines Leistungserbringers Der Patient willigt in die Berechtigung des Leistungserbringers bzw. einer Gruppe ein, auf seine elektronische Fallakte zuzugreifen. Der Zugangscode der Berechtigung wird durch eine Einwegfunktion wie folgt gebildet: 34

37 Zugangscode = func(geheimnis des ausstellenden Dienstes, Identifikator des Patienten, Identifikator des berechtigten Leistungserbringer bzw. der berechtigten Gruppe) Konkret wird hierzu der im Rahmen der Sicherheitsarchitektur spezifizierte Mechanismus eines secrethash verwendet, wobei als Eingabe die Patienten-ID und ein Identifizierer der zugriffsberechtigten Person oder Gruppe dienen (siehe auch Kapitel 5.9 der Sicherheitsarchitektur [efa_secarch-10]). efaaccesscode := secrethash( spl ) spl PatientAuthenticatedName x AccessorAuthenticatedName PatientAuthenticatedName : UniqueIdentifier AccessorAuthenticatedName: UniqueIdentifier!!: AccessorAuthenticatedName entspricht bzw. ist eindeutig abgeleitet aus oder oder (RoleIdentification x OrganisationIdentification) oder (ProfessionIdentification x OrganisationIdentification)!!: sts SecurityTokenService: fs: sts -> Secret: sts1, sts2 SecurityTokenService: fs(sts1) = fs(sts2) sts1 = sts2 Bildet man die durch Zugangscodes kodierten Berechtigungen in einer Relation ab, könnte dies beispielhaft wie folgt aussehen: Tabelle 2 Zugang zur elektronischen Fallakte eines Patienten über eine Relation Zugangscode secrethash( Identifikator Patient XYZ, Identifikator Arzt ABC) secrethash( Identifikator Patient XYZ, Identifikator der Gruppe aller Ärzte im Krankenhaus KLM) Identifikator elektronische Fallakte Identifikator der efa des Patienten XYZ Identifikator der efa des Patienten XYZ Über den Zugangscode kann geprüft werden, ob ein Leistungserbringer persönlich oder als Mitglied einer Gruppe berechtigt für den Zugriff auf die elektronische Fallakte eines Patienten ist, ohne dass ein Rückschluss zum Patienten und Leistungserbringer möglich ist. Dieser Zugangscode kann vom ausstellenden Dienst (Security Token Service) [WS-Trust] zusammen mit einem Zeitstempel in ein Security Token eingebettet und signiert werden. Dieses Security Token dient dem Nutzer als Nachweis der Berechtigung 35

38 zum Zugriff auf eine elektronische Fallakte. Der Nutzer erhält dieses Security Token nur, wenn er sich gegenüber dem ausstellenden Dienst authentisiert hat bzw. als Mitglied einer Gruppe identifiziert wurde. Der Dienst, der die elektronischen Fallakten verwaltet, gibt nach Prüfung des Security Tokens mit Hilfe der obigen Tabelle nur die efa-identifikatoren preis, deren Zugangscode mit dem des Security Tokens übereinstimmt. Dieser grundlegende Ablauf zur Ermittlung der efas eines Patienten, zu denen ein Arzt über Individual- oder Gruppenrechte zugriffsberechtigt ist, wird in dem nachfolgenden Pseudocode-Fragment noch einmal mit Hilfe der genutzten Mechanismen und Dienste verdeutlicht: // Ermitteln der efa des Patienten P zu denen Arzt A (auf Ebene 1) // zugriffsberechtigt ist AuthenticationAssertion authhp = Authenticate( A ); AttributeAssertion atthp = GetAttributes ( autharzt ); // Extrahieren der Rollen- und Gruppenzugehörigkeiten aus den Attributen PersonIdentification hpid = RoleIdentification roleid = OrganisationIdentification orgid = ProfessionIdentification profid = // Bilden der Zugangscodes accesscodehp = secrethash( P, hpid ); accesscodeorg = secrethash( P, orgid ); accesscoderole = secrethash( P, roleid ); accesscodeprof = secrethash( P, profid ); accesscodes = { accesscodehp, accesscodeorg, accesscoderole, accesscodeprof}; // Suchen der efas von P zu denen A zugriffsberechtigt ist findefas( accesscodes ) := { e efa accesscodes } Navigationsmodell Als Grundlage eines Gesamtkonzepts zum Schutz der medizinischen Daten im Kontext der elektronischen Fallakte soll ein Navigationsmodell dienen, welches aus dem konzeptionellen Modell (siehe Abbildung 10) abgeleitet wurde. Dieses Modell zeigt die erforderlichen Navigationsschritte ausgehend vom Leistungserbringer über den Patienten hin zu dessen medizinischen Daten. 36

39 Abbildung 15 Navigationsmodell der elektronischen Fallakte Möchte ein Leistungserbringer auf die elektronische Fallakte eines Patienten zugreifen, muss er zunächst die Identität des Patienten ermitteln. Dies kann in seinem Primärsystem mit Hilfe einer Patientenliste oder -suche erfolgen. Mit der Identität des Patienten erhält der Leistungserbringer eine Liste aller elektronischen Fallakten des Patienten, zu denen er Zugang hat (s. o.). Mit Hilfe der efa-zugangsliste und der Metadaten zu den dargestellten Fallakten muss der Leistungserbringer entscheiden, welche elektronische Fallakte für den aktuellen Behandlungskontext relevant ist. Aus dieser Liste wählt er eine Fallakte aus und öffnet sie. Im Ergebnis des Öffnens erhält er eine Liste der enthaltenen Partitionen. Auf Basis der annotierten Metadaten wählt er eine Partition aus, öffnet dieses und erhält eine Liste der enthaltenen Ordner bzw. Datenobjekte. Mit Hilfe der Ordnerliste kann der Leistungserbringer die Struktur der elektronischen Fallakte traversieren, bis er zum gewünschten Datenobjekt gekommen ist. Aus einer Datenobjektliste wählt er ein Datenobjekt aus, um es zu öffnen. Um die Zugriffskontrollmechanismen zu verdeutlichen, kann das Navigationsmodell zunächst vereinfacht werden. Dadurch verbleiben zunächst vier Entitäten in der Navigation vom Patienten zu dessen medizinischen Datenobjekten: efa-zugangsliste Elektronische Fallakte Datenobjektliste Datenobjekt 37

40 Die Navigation beinhaltet somit die folgenden vier Schritte: 1 Anzeigen aller efas, zu denen der Nutzer eine Zugangsberechtigung besitzt, annotiert mit Metadaten ohne Patientenbezug und Auswählen einer relevanten efa 2 Anzeigen der Metadaten (Patientenidentifikation) der ausgewählten efa und Bestätigen des Zugriffs 3 Anzeigen der enthaltenen Datenobjekte, annotiert mit den Metadaten und Auswählen eines relevanten Datenobjekts 4 Öffnen des Datenobjekts Alle vier Navigationsschritte müssen durch entsprechende Mechanismen abgesichert werden Modell zur Zugangs- und Zugriffskontrolle Das Modell zur Zugangs- und Zugriffskontrolle basiert auf dem in Abschnitt 4.1 beschriebenen Prinzip der Zugangs- bzw. Zugriffscodes, die als Security Token ausgegeben werden, sowie dem vereinfachten Navigationsmodell. Abbildung 16 Modell zur Zugangs- und Zugriffskontrolle der elektronischen Fallakte Jeder der vier Navigationsschritte des Navigationsmodells wird durch ein Security Token abgesichert, das einen bestimmten Zugangs- bzw. Zugriffscode enthält. In der folgenden Tabelle sind die Navigationsschritte und ihre Voraussetzungen aufgeführt. 38

41 Tabelle 3 Voraussetzungen für einzelne Navigationsschritte Nr. Schritt Voraussetzung 1 Anzeigen efa- Zugangsliste Identifikation des Patienten und Zugangsberechtigung des Leistungserbringers 2 Anzeigen einer efa Identifikation des Patienten, Identifikation der efa und Zugangsberechtigung des Leistungserbringers 3 Auflisten der enthaltenen Datenobjekte Entsprechende Zugriffsrechte auf der identifizierten efa 4 Zugriff auf ein Datenobjekt Identifikation des Datenobjekts und entsprechende Zugriffsrechte auf der efa, der das Datenobjekt zugeordnet ist Die in Tabelle 3 aufgeführten Voraussetzungen werden durch verifizierbare Security Token sichergestellt. Die Security Token werden entsprechend SAML 1.1 [SAML-11] durch SAML-Assertions gebildet. Die folgende Tabelle führt zu den vier Navigationsschritten die entsprechenden Security Token und ihre Inhalte auf. Tabelle 4 Security Token zur Absicherung der Navigationsvoraussetzungen Nr. Schritt Security Token Verifikation 1 Authentisierung AuthenticationAssertion Bekannte Identität und verifizierbarer Authentizitätsnachweis (siehe Kapitel 7.1 der Sicherheitsarchitektur [efa_secarch- 10]) 2 Auszeichnung als Mitglied einer berechtigten Gruppe 3 Anzeigen efa- Zugangsliste AttributeAssertion AdmissionAssertion Authentizität und Gruppenzuordnung (siehe Kapitel 7.2 der Sicherheitsarchitektur [efa_secarch-10]) Verifizierbarer Zugangscode aus dem Identifikator des Patienten und dem des Zugangsberechtigten bzw. der berechtigten Gruppe (siehe oben) 4 Anzeigen einer efa AdmissionAssertion Verifizierbarer Zugangscode aus dem Identifikator des Patienten und dem des Zugangsberechtigten bzw. der berechtigten Gruppe in Kombination mit dem Identifikator einer efa 5 Auflisten der enthaltenen Datenobjekte 6 Zugriff auf ein Datenobjekt AccessAssertion AccessAssertion Verifizierbare Zuordnung des Identifikators einer efa und der Zugriffsrechte auf der efa Verifizierbare Zuordnung des Identifikators des Objekts und der Zugriffsrechte auf dem Objekt 39

42 4.4 Dienste Auf der Grundlage der ermittelten Anforderungen an die elektronische Fallakte, des konzeptionellen Modells und des daraus abgeleiteten Navigationsmodells werden im Folgenden die notwendigen Dienste zur Navigation bzw. zum Auffinden, zur strukturierten Speicherung, zum Löschen und zum Ändern der Datenobjekte einer elektronischen Fallakte bzw. ihrer Metadaten identifiziert und beschrieben (siehe auch [efa_akpr-10]). Ergänzt werden müssen diese Dienste durch Token-ausstellende Dienste aus dem Modell zur Zugangs- und Zugriffskontrolle Navigationsdienste Aus dem im vorherigen Abschnitt beschriebenen Navigationsmodell mit seinen vier Navigationsschritten wurden die folgenden Dienste zur Realisierung der Navigation abgeleitet: Auflisten aller elektronischen Fallakten eines Patienten, zu denen ein Leistungserbringer eine Zugangsberechtigung besitzt Auflisten von Partitionen, Ordnern und Datenobjekten in einer elektronischen Fallakte Auslesen der Metadaten zu Partitionen, Ordnern und Datenobjekten einer bestimmten elektronischen Fallakte Zugriff auf ein Datenobjekt einer elektronischen Fallakte Speicherdienste Die folgenden Speicherdienste müssen realisiert werden: Erzeugen einer elektronischen Fallakte zu einem Patienten (einschließlich der Metadaten) Setzen der Zugriffsrechte auf den Datenobjekten einer elektronischen Fallakte Erzeugen von Partitionen/Ordnern mit ihren Metadaten Einstellen von Dokumenten in eine elektronische Fallakte bzw. dessen Partition/Ordner Löschdienste Datenobjekte einer elektronischen Fallakte und die dazugehörigen Metadaten dürfen nicht gelöscht werden. Entzieht der Patient die 40

43 Einwilligung in die Nutzung seiner elektronischen Fallakte, muss die gesamte Akte einschließlich aller Partitionen, Ordner und Datenobjekte dem Zugriff entzogen werden. Damit beschränken sich die Löschdienste auf den Dienst: Löschen einer elektronischen Fallakte, wobei die Löschung im Wesentlichen eine Archivierung von Aktenstruktur und Daten sowie eine Deaktivierung der entsprechenden Zugangscodes beinhaltet Änderungsdienste In einer elektronischen Fallakte dürfen einmal eingestellte Datenobjekte nicht verändert werden. Allerdings ist es notwendig, die Metadaten ändern zu können. Damit ergibt sich die Notwendigkeit für die folgenden Änderungsdienste der Metadaten für: elektronische Fallakten, Partition / /Ordner Datenobjekte. Um die Nachvollziehbarkeit zu gewährleisten, führt jede Änderung zu einer neuen Version eines Metadatums Security Token Services Im Zusammenhang mit der Authentisierung von Leistungserbringern sind die folgenden, im Rahmen der Sicherheitsarchitektur [efa_secarch-10] spezifizierten Dienste erforderlich: Identity Provider (IP) Attribute Service (AS) Der Identity Provider [WS-Federation] ist ein spezieller Security Token Service, der in einem Security Token (Identity Assertion) die Identität und Authentizität des Leistungserbringers bestätigt. Der Attribute Service reichert die Identität mit Attributen an, die die Autorisierung des Leistungserbringers im Sinne einer Gruppenzugehörigkeit verifizierbar beschreiben. Abhängig von seiner Gruppenzugehörigkeit hat ein Leistungserbringer Zugangsberechtigungen zu den elektronischen Fallakten verschiedener Patienten sowie Zugriffsrechte auf die medizinischen Datenobjekte. Für die Ausstellung der Zugangsberechtigungen bzw. deren Erteilung sind die folgenden Dienste der Anwendungsarchitektur zuständig: efa-token Service (ETS) efa-inventory (EI) 41

44 5 Übersicht über die Anwendungsarchitektur und die Dienste der elektronischen Fallakte Im vorherigen Abschnitt wurden die identifizierten Dienste kurz beschrieben. Diese Dienste werden im Folgenden ausgehend von den gesetzten Rahmenbedingungen des Projekts in einer Anwendungsarchitektur für die elektronische Fallakte strukturiert und in Beziehung gesetzt. Abbildung 17 zeigt die logische Anwendungsarchitektur der elektronischen Fallakte mit ihren Diensten. Sie unterscheidet vier Zonen: Client Demilitarisierte Zone (DMZ) Service Zone Intranet Abbildung 17 Anwendungsarchitektur der elektronischen Fallakte Thin Client DMZ Service Zone Intranet Browser efa- Enabler Portal Identity Provider Attribute Service Nutzerverwaltung Fat Client Primärsystem efa- Proxy efa- Broker efa-token Service efa- Inventory Object- Inventory DataChannel Service Komm.- Server Object-Store KIS / DMS Auf der Seite des Clients (z. B. Leistungserbringer) werden Realisierungen als Thin Client und als Fat Client unterschieden (siehe auch Kapitel 2.2.1). Der Thin Client ist ein generischer Web-Browser, der durch den efa-enabler ergänzt wird. Der efa-enabler integriert Dienste zur Authentisierung des Nutzers und zum Ver- bzw. Endschlüsseln von Dokumenten. Alle weiteren Funktionen der elektronischen Fallakte werden vom Web-Browser über das Portal abgerufen. 42

45 Als Fat Client dient das Primärsystem des Leistungserbringers wie z. B. das Patientenverwaltungssystem (PVS) eines niedergelassenen Arztes. Die Funktionalität der elektronischen Fallakte wird durch einen efa-proxy integriert. Dieser stellt lokal durch eine Programmierschnittstelle (API) alle Dienste der elektronischen Fallakte zur Verfügung. Der Client ist mit den Diensten eines Providers (z. B. Krankenhaus) über das Internet verbunden. Auf dessen Seite werden drei Zonen mit eigenen Sicherheitsanforderungen unterschieden: die demilitarisierte Zone (DMZ), die Service Zone und das Intranet. In der DMZ sind das Portal sowie der efa-broker angesiedelt. In der Servicezone befinden sich alle weiteren Dienste der elektronischen Fallakte, die über das Internet angeboten werden. Im Intranet werden z. B. die Krankenhausinformationssysteme (KIS) oder Dokumentenmanagementsysteme betrieben, in denen Patientendaten verwaltet werden. Diese Systeme dienen neben den Patientenverwaltungssystemen (PVS) der niedergelassenen Ärzte als Datenquelle für die elektronische Fallakte. Die relevanten Daten eines Patienten werden automatisiert aus dem KIS bzw. DMS über einen Kommunikationsserver zu den Diensten in der Servicezone übertragen und von diesen bereitgestellt. Die Übergänge zwischen dem Internet, der DMZ, der Servicezone und dem Intranet müssen mindestens durch die in [BSI-GSHB] und [BSI-eGov] empfohlenen Maßnahmen abgesichert werden. Aufgrund des sehr hohen Schutzbedarfs der verwalteten Daten sind weitere Maßnahmen für eine konkrete technische Realisierung nach den Vorgehen des [BSI-IT-Sich] zu ermitteln. Die hier dargestellte Dekomposition der in der Service Zone angesiedelten Dienste stellt eine funktionale Dekomposition auf Basis der Konzepte serviceorientierter Architekturen dar, bei der auf einer Applikation (im Sinne einer persistente Daten verwaltenden Komponente) aufbauende Dienste gruppiert wurden. Da die Dienste der Service Zone nach außen komplett durch den Broker gekapselt sind, kann eine Implementierung eine beliebige andere Gruppierung von Daten und Funktionalitäten vornehmen, solange diese die in diesem Dokument spezifizierten Dienstschnittstellen über den Broker bzw. ein Portal gegenüber Clients anbieten. 5.1 Überblick zu den Komponenten des Clients Auf der Seite des Clients sind die Komponenten angesiedelt, die benötigt werden, um die elektronische Fallakte nutzen zu können. Es werden zwei Varianten unterschieden: Thin Client und Fat Client. Der Thin Client dient der Integration der Nutzung der elektronischen Fallakte in bestehenden Portallösungen. Die Fat-Client-Variante zielt auf eine Integration der efa- Anwendung in bestehende Primärsysteme ab. 43

46 Tabelle 5 gibt einen Überblick zu den Komponenten auf der Seite des Clients. Tabelle 5 Überblick zu den Komponenten der Client-Seite Komponente Browser efa-enabler Primärsystem efa-proxy Funktion Der Browser stellt als Thin Client die HTML-basierten Präsentationen des Portals dar. Er dient ebenfalls der Eingabe und Auswahl von Daten. Der efa-enabler integriert als aktive Komponente Funktionalität zur Authentisierung des Leistungserbringers und zur Ende-zu-Ende- Verschlüsselung medizinischer Datenobjekte mittels Signaturkarten. Ein Primärsystem ist z. B. ein Patientenverwaltungssystem eines niedergelassenen Arztes. Das Primärsystem nutzt als Fat Client die Programmierschnittstelle des efa-proxy, um die Dienste der elektronischen Fallakte zu integrieren. Der efa-proxy stellt eine lokale Programmierschnittstelle zur Nutzung der Dienste der elektronischen Fallakte zur Verfügung. 5.2 Überblick zu den Diensten der DMZ In der demilitarisierten Zone sind das Portal sowie der efa-broker angesiedelt. Diese beiden Dienste werden direkt von den Clients aus dem Internet angesprochen. Der efa-broker leitet die Anfragen an die Dienste in der Servicezone weiter. Tabelle 6 zeigt alle notwendigen Dienste der DMZ im Überblick. Tabelle 6 Überblick zu Diensten der DMZ Dienst efa-broker Portal Funktion Der efa-broker dient dem Thin Client und dem Fat Client sowie dem Portal als zentraler Zugangspunkt zu den Diensten der elektronischen Fallakte eines Knoten. Das Portal übernimmt für den Thin Client einen Teil der Navigations- und Präsentationsfunktionalität. 5.3 Überblick zu den Diensten der Servicezone In der Servicezone werden alle Dienste der elektronischen Fallakte betrieben, die in einem Knoten bzw. bei einem Anbieter die bereitgestellten Daten verwalten. Dadurch wird ein direkter Zugriff auf die Operativsysteme im Intranet verhindert, was deren Verfügbarkeit sichert. 44

47 Tabelle 7 zeigt alle notwendigen Dienste der Servicezone im Überblick. Tabelle 7 Überblick zu Diensten der Servicezone Dienst Attribute Service Funktion Der Attribute Service bestätigt die Zugehörigkeit einer verifizierten und/oder authentisierten Identität zu einer Gruppe (Dienstspezifikation siehe»sicherheitsarchitektur«[efa_secarch-10]). DataChannel Service Der DataChannel Service öffnet und schließt einen geschützten Datenkanal zu einem anderen Dienst (Dienstspezifikation siehe»sicherheitsarchitektur«). efa-inventory efa-token Service Identity Provider Object Inventory Object Store Das efa-inventory verwaltet die elektronischen Fallakten von Patienten, die Zugangsberechtigungen mit ihren Zugriffsrechten sowie die Metadaten zu einer efa. Der Dienst ist auch ein spezieller Security Token Service der Security Token mit den Zugriffsrechten auf eine efa (Access Assertion) ausgibt. Der efa-token Service ist ein spezieller Security Token Service, der authentisierten Leistungserbringern unter Angabe eines Patientenidentifikators ein Security Token (Admission Assertion) für den Zugang zur elektronischen Fallakte des Patienten ausgibt. Der Identity Provider bestätigt die Identität und/oder Authentizität eines Leistungserbringers (Dienstspezifikation siehe»sicherheitsarchitektur«). Das Object Inventory verwaltet die Struktur der medizinischen Datenobjekte in Partitionen und Ordnern, ihre Metadaten sowie die notwendigen Verweise in den Object Store. Der Object Store speichert die medizinischen Datenobjekte einer elektronischen Fallakte. Hierbei ist transparent, ob die medizinischen Datenobjekte als Kopie im Object Store vorgehalten oder ob diese auf Anforderung vom KIS beschafft werden. Der Object Store kann so beliebige Caching-Strategien realisieren. 5.4 Überblick zu den Diensten im Intranet Im Intranet sind die Operativsysteme eines Knotens bzw. Anbieters angesiedelt. Das Intranet stellt einen geschützten Bereich dar, der nachfolgend kurz betrachtet wird. Tabelle 8 gibt einen Überblick zu den notwendigen Diensten im Intranet. Tabelle 8 Überblick zu Diensten im Intranet Dienst Nutzerverwaltung Funktion Die Nutzerverwaltung hält die Identitäten aller bekannten Nutzer in einem Knoten sowie ihre Zuordnung zu Gruppen vor. Diese Informationen werden aus dem Intranet in geeigneter Form in die Service Zone repliziert (Dienste Identity Provider und Attribute Service). 45

48 KIS/DMS Kommunikationsserver Krankenhausinformationssystem bzw. Dokumentenmanagementsystem eines Knotens bzw. eines Krankenhauses, das als Datenquelle für die medizinischen Datenobjekte der elektronischen Fallakten dient. Der Kommunikationsserver stellt die Verbindung zwischen KIS/DMS und den Diensten der Service Zone dar. Werden im KIS/DMS elektronische Fallakten angelegt oder erfolgen Änderungen an den Akten, informiert das KIS den Kommunikationsserver über eine entsprechende Nachricht (z. B. im HL7- Format). Dieser nimmt die Nachrichten entgegen und bildet sie auf die Dienste der elektronischen Fallakte in der Service Zone ab. 46

49 6 Funktionale Spezifikation der Dienstschnittstellen In diesem Abschnitt sind die notwendigen Dienste der elektronischen Fallakte mit ihren Schnittstellen funktional spezifiziert. Die konkrete Kodierung der ausgetauschten Nachrichten und der darin enthaltenen Daten ist im Dokument»Datentypen und Nachrichten«[eFA_DtNf-10] beschrieben. Diese Stufe der Konkretion ist letzten Endes jedoch nur für die Schnittstelle des Brokers relevant. Alle anderen Dienste können in der internen Kommunikation sowohl von den Schnittstellen als auch den vorgegebenen Kodierungen abweichen, solange hierbei die Anforderungen des Sicherheitskonzepts [efa_sdk-10] berücksichtigt werden. Die funktionalen Spezifikationen der Dienstschnittstellen wurden gemäß den zugrunde liegenden, persistente Daten verwaltenden Anwendungskomponenten gruppiert. Die Reihenfolge der Darstellung orientiert sich an dem Navigationsmodell, sodass die Spezifikationen in weiten Teilen aufeinander aufbauen und hierdurch in ihren Abläufen verständlicher dargestellt werden können. Aufgrund der zentralen Bedeutung für das Berechtigungskonzept und der Nutzung in fast allen Dienstschnittstellen werden jedoch zunächst die in Kapitel im Überblick dargestellten Berechtigungsnachweise (Security Token) spezifiziert. 6.1 Security Token (Assertions) Innerhalb von Sicherheits- und Anwendungsarchitektur werden drei Arten von Berechtigungsnachweisen genutzt: Identity Assertion: Nachweis über die Identität (Rollen- und Gruppenzugehörigkeiten) eines Zugriffsberechtigten. Eine Identity Assertion kann zusätzlich einen Authentisierungsnachweis einer Person enthalten. Dazu dient die AuthenticatedIdentityAssertion als Spezialisierung der Identity Assertion Admission Assertion: Nachweis über die Berechtigung, Kenntnis vom Vorhandensein einer bestimmten efa eines Patienten erlangen zu dürfen. Admission Assertions werden an Dienste des efa-inventory übergeben, um nach Fallakten eines Patienten zu suchen und deren Metadaten anzuzeigen. Voraussetzung für die Erlangung einer Admission Assertion ist der Besitz einer Identity Assertion. Access Assertion: Nachweis über die Zugriffsrechte auf eine konkrete efa und die darin 47

50 eingestellten medizinischen Daten. Access Assertions werden an Dienste des Object Inventory und des Object Store übergeben, um Inhalte einer efa aufzulisten, neue Objekte in eine efa einzustellen und Objekte aus einer efa auszulesen. Voraussetzung für die Erlangung einer Access Admission ist der Besitz einer Admission Assertion für die zu nutzende efa. Die drei Arten von Berechtigungsnachweisen bauen aufeinander auf, sodass sich für alle Nutzungsszenarien einer efa ein identisches Kommunikationsmuster ergibt: 1 Identifizierung und Authentisierung: Erlangen einer Identity Assertion mit oder ohne Authentisierungsnachweis ergänzt um Attribute zur Darstellung der Gruppenzugehörigkeit der Identität 2 Erlangen einer Admission Assertion zur Anzeige der efa auf Basis der Personenidentität bzw. Gruppenzugehörigkeit: Suchen der efas eines Patienten bzw. Öffnen einer bekannten efa 3 Erlangen einer Access Assertion für den Zugriff auf einzelne Objekte einer efa auf Basis einer Admission Assertion: Listen der Objekte einer efa und Zugriff auf die Objekte. Abbildung 18 verdeutlicht die Erzeugung der Security Token. 48

51 Abbildung 18 Security Token (Assertions) Identity Assertion (Identity Provider) Identity Authentication 1. Attribute Assertion (Attribute Service) Attribute1 Attribute Admission Assertion (efa-token Service) Admission Code Patient Identifier Admission Assertion (efa-token Service) Admission Code 3. Record Identifier Access Assertion (efa-inventory) Access Code Access Right Abbildung 19 zeigt vereinfacht den semantischen Zusammenhang zwischen den verschiedenen Assertions. Abbildung 19 Semantischer Zusammenhang zwischen den Security Token (Assertions) Identity Assertion Identity Attribute Assertion Attribute Admission Assertion Admission Code Access Assertion Ausgangspunkt ist die Identifizierung (Identity Assertion) eines Nutzer ergänzt durch eine optionale Authentisierung (Authenticated Identity 49

52 Assertion). Die Identität des Nutzers wird verwendet, um dessen Attribute bzw. Gruppenzugehörigkeit (Attribute Assertion) zu ermitteln. Die Identity sowie die Attribute werden herangezogen, um zusammen mit dem Patientenidentifikator den Zugangscode (Admission Code) zu elektronischen Fallakten des Patienten zu berechnen und in einer Admission Assertion auszugeben. Die Zugriffsrechte sind an den Zugang und damit an den Zugangscode (Admission Code) gebunden. Damit existiert eine transitive Beziehung zwischen den Zugriffsrechten auf den Objekten einer elektronischen Fallakte eines Patienten über den Zugang zu dieser Akte des Nutzers hin zu dessen Gruppenzugehörigkeit und seiner Identität. Jede der aufgeführten Assertions wird von unterschiedlichen Diensten ausgestellt und kann eine andere Gültigkeitsdauer besitzen. So ist es denkbar, Identity Assertions mit einer relativ kurzen Gültigkeitsdauer auszustatten, die an der Dauer von Sessions ausgerichtet ist. Im Gegensatz dazu können Admission Assertions durchaus eine Gültigkeit von mehreren Tagen aufweisen, gespeichert und u. U. auch weitergegeben werden. Eine Verknüpfung der Assertions auf der semantischen Ebene durch die aufgezeigten Merkmale (Admission Code, Attribute und Identity) ermöglicht eine stärkere Entkopplung der Assertion als durch eine Verknüpfung der Assertion durch Referenzen. Eine Verifizierung der semantischen Integrität ist möglich. Der Vorteil der semantischen Verknüpfung der Assertions gegenüber der referenziellen wird im Folgenden kurz erläutert. Ein Nutzer authentisiert sich, erhält eine Identity Assertion, beschafft sich mit dieser und dem Patientenidentifikator eine Admisssion Assertion für den Zugang zu einer elektronischen Fallakte des Patienten und letztlich die Access Assertion für den Zugriff auf die Objekte der efa. Die Authentisierung des Nutzers ist in der Regel an die jeweilige Sitzung der Anwendung gebunden. D. h. ihre Gültigkeit ist auf die Dauer der Sitzung begrenzt. Admission und Access Assertion können durchaus langlebiger ausgestellt, gespeichert und wieder verwendet werden. Bei einer Wiederverwendung dieser Assertions für einen direkten Zugriff auf die elektronische Fallakte müssten diese lediglich mit einer aktuellen (Authenticated) Identity Assertion bzw. Attribute Assertion kombiniert werden. Auf Basis der semantischen Verknüpfung der Assertions mit Hilfe der Merkmale Admission Code, Attribute und Identity kann die Integrität der kombinierten Assertions geprüft werden Identity Assertion Identity Assertions beschreiben die Identität eines efa-nutzers, sie ist über die Identität des Nutzers mit einer oder mehrere Attribute Assertions (Rollen- 50

53 und Gruppenzugehörigkeiten) verknüpft. Sie kann zusätzlich aus einer Authentication Assertion (Authentisierungsnachweis) bestehen. Identity Assertions werden von den Diensten Identity Provider und Attribute Service der Sicherheitsarchitektur erstellt, wobei der Attribute Service durch den Identity Provider gekapselt werden kann Funktionale Spezifikation Die funktionale Spezifikation von Identity Assertions und Attribute Assertions ist Bestandteil der Sicherheitsarchitektur. Daher wird an dieser Stelle lediglich der Aufbau dieser Assertions dargestellt. Für weitere Informationen hierzu sei auf die Kapitel 7.1 und 7.2 des Dokuments»Sicherheitsarchitektur«[eFA_SecArch-10] verwiesen. Mit einer Identity Assertion stellt der Identity Provider einen Identitätsnachweis mit Attributen für die Gruppenzugehörigkeiten z. B. die Organisation aus. Dazu stellt der Attribute Service Attribute Assertions aus, welche über die Identität mit der Identity Assertion verknüpft sind. Eine Identity Assertion kann einen Authentizitätsnachweis enthalten. Identity Assertions besitzen das folgende Format: IdentityAssertion : Identity x AttributeAssertion+ x AuthenticationAssertion? Die von einem Identity Provider erstellten Authentisierungsnachweise beinhalten zumindest die folgenden Informationen: Eindeutige Bezeichnung des ausstellenden Identity Providers Eindeutige Bezeichnung der authentisierten Entität (Person, Organisation oder Dienst) Angaben, über die ein Empfänger einer Authentication Assertion die Authentizität des Absenders prüfen kann Angaben zur Gültigkeitsdauer des Authentisierungsnachweises Angaben zum Cluster und zur Domain, in denen der Nachweis erstellt wurde Signatur des Identity Providers, mit der gegenüber genutzten Diensten die Integrität und Authentizität der Authentisierungsdaten nachgewiesen werden kann Bei einer Integration von Identity Provider und Attribute Service sind zusätzlich die die authentisierte Entität beschreibenden Attribute Bestandteil des Authentisierungsnachweises. AuthenticationAssertion : IdentityProviderRef x AuthenticatedEntity x 51

54 ConfirmationData x Validity x EntityAttributes? x DomainIdentifier x ClusterIdentifier x SignedDigest IdentityProviderRef AuthenticatedEntity ConfirmationData : AuthenticatedName : AuthenticatedName : Any!!: a AuthenticationAssertion: = IdentityProviderRef!!: a AuthenticationAssertion f: ConfirmationData x AuthenticatedEntity -> Boolean mit f( ) liefert eine Aussage darüber, ob a von AuthenticatedEntity eingereicht wurde. In einer Attribute Assertion sind Attribute enthalten, über die die Zugehörigkeit einer Person zu einer Organisation, der Typ dieser Organisation, die Rolle der Person innerhalb dieser Organisation sowie das Fachgebiet einer Person kodiert werden. Falls eine Person mehreren Organisationen angehört, muss für jede Organisationszugehörigkeit eine eigene Attribute Assertion erstellt werden: AttributeAssertion : HPIdentification x SignedDigest HPIdentification : PersonIdentification x RoleIdentification? x ProfessionIdentification?!!: ( hpident, sig) AttributeAssertion : hpident PersonIdentification x (OrganisationIdentification x RoleIdentifier?)? x ProfessionIdentification mit typeof( ) = Attribute, typeof( ) = Attribute, typeof( ) = Attribute, typeof( ) = Attribute* Kodierung Identity bzw. Authentication Assertions und Attribute Assertions werden in SAML 1.1 [SAML-11] kodiert. Vorgaben und Empfehlungen zur Anwendung von SAML 1.1 zur Kodierung der Nachweise sind Bestandteil der Kapitel 7.1 und 7.2 des Dokuments»Sicherheitsarchitektur«[eFA_SecArch-10]. Abbildung 20 zeigt eine Identity Assertion für einen die vom Identity Provider der Klinik»x«ausgestellt wurde. Sie enthält ein Attribute Statement mit einem Subject, welches die 52

55 Identität des Nutzers darstellt. Mit dem Attribut NameQualifier wird Namensraum der Identität festgelegt. Die Identitätsinformation aus dem Subject wird im Attribute Statement in den zwei Attributen»nameIdentifier«und»nameQualifier«repliziert. Weitere Attribute können ergänzt werden. Abbildung 20 Identity Assertion für die nicht authentisierte Identität eines version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a175b-9de-75ef-95a5" Issuer="http://efa-01.klinik_x.de/IdentityProvider" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AttributeStatement> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" NameQualifier="http://efa-01.klinik_x/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="nameIdentifier" AttributeNamespace="urn:de:efa:identity"> <AttributeValue> </AttributeValue> </Attribute> <Attribute AttributeName="nameQualifier" AttributeNamespace="urn:de:efa:identity"> <AttributeValue> "http://efa-01.klinik_x.de/identityprovider" </AttributeValue> </Attribute> </AttributeStatement> <ds:signature>... </ds:signature> </Assertion> Abbildung 21 zeigt eine Identity Assertion für einen die ebenfalls vom Identity Provider der Klinik»x«ausgestellt wurde. Im Unterschied zur vorherigen enthält diese Assertion einen Authentisierungsnachweise in Form eines AuthenticationStatement. In diesem Fall muss das Subject durch ein SubjectConfirmation-Element ergänzt werden. 53

56 Abbildung 21 Identity Assertion für die authentisierte Identität eines version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a175b-9de-75ef-95a5" Issuer="http://efa-01.klinik_x.de/IdentityProvider" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AuthenticationStatement AuthenticationInstant=" T22:06:33.822Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:X509-PKI"> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> <SubjectConfirmation> <ConfirmationMethod> urn:oasis:names:tc:saml:1.0:am:x509-pki </ConfirmationMethod> <SubjectConfirmationData> R1VD8fkkvlrh </SubjectConfirmationData> </SubjectConfirmation> </Subject> </AuthenticationStatement> <ds:signature>... </ds:signature> </Assertion> Abbildung 22 zeigt eine Attribute Assertion, welche die Zugehörigkeit der Organisationseinheit»kardiologie.klinik_x.de«bestätigt. Die Attribute Assertion ist über die Identität d. h. das Element»Subject«mit der Identity Assertion in Abbildung 21 oder Abbildung 20 verknüpft. Abbildung 22 Attribute Assertion ausgestellt vom Attribute Service für einen version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a145b-96de-7ef-63a5" Issuer="http://efa-01.klinik_x.de/AttributeService" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AttributeStatement> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" 54

57 NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="organization" AttributeNamespace="urn:de:efa:attributes"> <AttributeValue> kardiologie.klinik_x.de </AttributeValue> </Attribute> </AttributeStatement> <ds:signature>... </ds:signature> </Assertion> Die Attribute Assertion in Abbildung 23 bestätigt zusätzlich die Rolle»Oberarzt«der Über die semantische Verknüpfung der Attribute Assertions mit der Identity Assertions kann die Identität mit verschiedenen Attributen ausgezeichnet und die entsprechenden Assertions von unterschiedlichen Autoritäten signiert werden. 55

58 Abbildung 23 Attribute Assertion ausgestellt vom Attribute Service für einen version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a145b-96de-7ef-64f8" Issuer="http://efa-01.klinik_x.de/AttributeService" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AttributeStatement> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="role" AttributeNamespace="urn:de:efa:attributes"> <AttributeValue> Oberarzt </AttributeValue> </Attribute> </AttributeStatement> <ds:signature>... </ds:signature> </Assertion> Abbildung 24 zeigt eine Attribute Assertion über die Zugehörigkeit des deren Ableitung aus den Attributen»organization«und»role«. Die Definition der Gruppen über weitere Attribute Assertion ist insbesondere dann wichtig, wenn die zugrundeliegenen Attribute Assertions von unterschiedlichen oder fremden Autoritäten signiert werden und eine eigene Gültigkeitsdauer besitzen. Soll z. B. die werden, kann die Bestätigung, dass ein Nutzer Arzt ist z. B. von der Bundesärztekammer durch eine signierte Attribute Assertion online gegeben oder als Attributzertifikat auf dem Heilberufsausweis hinterlegt werden. Die Zugehörigkeit zu der nur in Verbindung mit dieser Bestätigung gültig. Das bedeutet, beim Ausbleiben dieser Bestätigung würde automatisch die Gruppenzugehörigkeit und damit der Zugang zu den elektronischen Fallakten der Patienten entfallen. 56

59 Abbildung 24 Attribute Assertion ausgestellt vom Attribute Service für einen version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a145b-96de-7ef-64f8" Issuer="http://efa-01.klinik_x.de/AttributeService" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AttributeStatement> <Subject> <NameIdentifier Format="urn:de:efa:nameidentifier:identity" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="role" AttributeNamespace="urn:de:efa:attributes"> <AttributeValue> Oberarzt </AttributeValue> </Attribute> <Attribute AttributeName="organization" AttributeNamespace="urn:de:efa:attributes"> <AttributeValue> kardiologie.klinik_x.de </AttributeValue> </Attribute> </AttributeStatement> <AttributeStatement> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="memberof" AttributeNamespace="urn:de:efa:attributes"> <AttributeValue> </AttributeValue> </Attribute> </AttributeStatement> <ds:signature>... </ds:signature> </Assertion> 57

60 6.1.2 Admission Assertion Admission Assertions sind Berechtigungsnachweise für den Zugang zu elektronischen Fallakten (nicht jedoch die darin enthaltenen Daten) eines Patienten. Sie werden vom efa-token Service ausgestellt Funktionale Spezifikation Jede Admission Assertion enthält einen Code für den Zugang zu elektronischen Fallakten eines Patienten. Sie ist über die Identität bzw. den Attributwert mit der Identity bzw. Attribute Assertion verknüpft, auf deren Basis die Admission Assertion ausgestellt wurde. Optionale Angaben sind der Gültigkeitsbereich des Zugangscodes. Hierbei werden zwei Gültigkeitsbereiche unterschieden: Der Zugangscode beinhaltet Angaben zu Patient und zugreifender Person/Gruppe und ist damit für alle efas gültig, für die entsprechende Zugänge definiert sind. Zugangscodes dieses Gültigkeitsbereichs können ausschließlich zum Suchen von efas und zur Erzeugung von Access Assertions (Zugriffsrechte auf den Objekten einer efa) genutzt werden. Bestandteil der Beschreibung des Gültigkeitsbereichs ist ein Hinweis auf die Berechtigungsgrundlage (Individuum, Organisation, Rolle, etc.), um innerhalb des Netzes von autonomen Einheiten durch entsprechend ausgestaltete Federation Services ein Identity und Authentication Mapping durchführen zu können. AdmissionAssertion: AdmissionCode:= AdmissionCode x IdentityAssertionRef x EFAInventoryIdentifier x ClusterIdentifier x DomainIdentifier? x Validity x SignedDigest secrethash( RecordOwnerIdentifier x HPIdentification ) EFAInventoryIdentifier: ComponentIdentifier Kodierung Admission Assertions werden als SAML 1.1 [SAML-11] Authorization Decision Assertion kodiert. Die Verknüpfung mit der Identity bzw. Attribute Assertion erfolgt mit Hilfe des Subject-Elemtents in der Authorization Decision Statement. Dieses enthält den Identifikator der Person bzw. der Gruppe (Organisation, Rolle in Organisation, Profession in Organisation) auf 58

61 dessen Basis die Admission Assertion ausgestellt wurde sowie die zugelassenen Operationen auf der elektronischen Fallakte. Der Zugangscode wird in einem Attribute Statement mit demselben Subject- Element kodiert. Abbildung 25 Admission Assertion ausgestellt vom efa-token Service für die version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a885b-22de-5ef-4a5" Issuer="http://efa-01.klinik_x.de/EFA_TokenService" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AuthorizationDecisionStatement Decision="Permit" Resource="http://efa-01.klinik_x.de/EFA_Inventory/Records"> <Subject> <NameIdentifier Format="urn:de:efa:nameidentifier:identity" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Action Namespace="urn:de:efa:action"> efa:actions:listrecords </Action> <Action Namespace="urn:de:efa:action"> efa:actions:createrecord </Action> </AuthorizationDecisionStatement> <AttributeStatement> <Subject> <NameIdentifier Format="urn:de:efa:nameidentifier:identity" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="eFAInventory" AttributeNamespace="urn:de:efa:admission"> <AttributeValue> </AttributeValue> </Attribute> <Attribute AttributeName="admissionCode" AttributeNamespace="urn:de:efa:admission"> <AttributeValue> XYKDJFEHFIUG GHFRUKG347824KJFHEKA </AttributeValue> </Attribute> </AttributeStatement> <ds:signature> 59

62 ... </ds:signature> </Assertion> Abbildung 26 zeigt eine Admission Assertion, die persönlich für den wurde. Das Subject-Element des Authorization Decision Statements enthält den Identifikator der Person. Abbildung 26 Persönliche Admission Assertion ausgestellt vom efa-token Service für den version="1.0" encoding="utf-8"?> <Assertion xmlns="urn:oasis:names:tc:saml:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" MajorVersion="1" MinorVersion="0" AssertionID="a885b-22de-5ef-4a5" Issuer="http://efa-01.klinik_x.de/EFA_TokenService" IssueInstant=" T02:00:00.173Z"> <Conditions NotBefore=" T02:00:00.173Z" NotOnOrAfter=" T02:00:00.173Z"/> <AuthorizationDecisionStatement Decision="Permit" Resource="http://efa-01.klinik_x.de/EFA_Inventory/Records"> <Subject> <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format: Address" NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Action Namespace="urn:de:efa:action"> efa:actions:listrecords </Action> <Action Namespace="urn:de:efa:action"> efa:actions:createrecord </Action> </AuthorizationDecisionStatement> <AttributeStatement> <Subject> <NameIdentifier Format=" urn:oasis:names:tc:saml:1.1:nameid-format: address " NameQualifier="http://efa-01.klinik_x.de/IdentityProvider"> </NameIdentifier> </Subject> <Attribute AttributeName="eFAInventory" AttributeNamespace=" urn:de:efa:admission"> <AttributeValue> </AttributeValue> </Attribute> <Attribute AttributeName="admissionCode" AttributeNamespace="urn:de:efa:admission"> <AttributeValue> XYKDJFEHFIUG GHFRUKG347824KJFHEKA </AttributeValue> 60

63 </Attribute> </AttributeStatement> <ds:signature>... </ds:signature> </Assertion> Access Assertion Access Assertions erlauben den Zugriff auf einzelne Objekte in einer efa, das Einstellen neuer Objekte in eine efa sowie das Auflisten der in einer efa enthaltenen Objekte. Access Assertions werden vom efa-inventory erstellt, das auch die Zugänge (Identität/Gruppe und PatientenID) zu elektronischen Fallakten verwaltet. Die Zugriffsrechte werden pro Zugang definiert. Alle Nutzer, die über einen bestimmten Zugang auf Objekte einer elektronischen Fallakte zugreifen, erhalten die gleichen Zugriffsrechte Funktionale Spezifikation Access Assertions definieren die Zugriffsrechte auf Objekte einer elektronischen Fallakte zu einem bestimmten Zugang. Der Access Code wird vom efa-inventory aus dem Identifikator der elektronischen Fallakte berechnet. Jedes Objekt einer Akte ist mit dem gleichen Access Code versehen. Er weist aus, das ein Objekt zu einer elektronischen Fallakte gehört, ohne vom Objekt auf eine efa schließen zu können. Damit sind die Zugriffsrechte, die ein Nutzer über den Zugang zu einer efa erhalten hat, auf das Objekt anzuwenden. Der Access Code ist lediglich im Kontext der angegebenen Domain gültig. AccessAssertion : ClusterIdentifier x DomainIdentifier? x ObjectAccessCode x ObjectInventoryIdentifier x AdmissionAssertionRef x AccessOperation+ x Validity x SignedDigest ObjectAccessCode := secrethash( RecordIdentifier ) RecordIdentifier : ObjectIdentifier ObjectInventoryIdentifier : ComponentIdentifier 61

64 Kodierung Access Assertions werden als SAML 1.1 Authorization Decision Assertions [SAML-11] kodiert. Die Verknüpfung mit der Admission Assertion erfolgt mit Hilfe des Subject-Elemtents im Authorization Decision Statement. Dieses enthält den Zugangscode (Admission Code), auf dessen Basis die Zugriffsrechte ermittelt und in der Access Assertion kodiert wurden. Weiterhin definiert es die zugelassenen Operationen auf den Objekten der elektronischen Fallakte. Der Zugriffscode (Access Code) wird in einem Attribute Statement mit demselben Subject-Element kodiert. Abbildung 27 Access Assertion ausgestellt vom efa-inventory zu einem bestimmten ZugangsCode <?xml version= 1.0 encoding= utf-8?> <Assertion xmlns= urn:oasis:names:tc:saml:1.0:assertion xmlns:ds= MajorVersion= 1 MinorVersion= 0 AssertionID= b85b-224e-5e Issuer= IssueInstant=» T02 :00 :00.173Z»> <Conditions NotBefore=» T02 :00 :00.173Z» NotOnOrAfter= T02:00:00.173Z /> <AuthorizationDecisionStatement Decision= Permit Resource= > <Subject> <NameIdentifier Format= urn:de:efa:nameidentifier:admission NameQualifier= > XYKDJFEHFIUG GHFRUKG347824KJFHEKA </NameIdentifier> </Subject> <Action Namespace= urn:de:efa:action > efa:actions:listobjects </Action> <Action Namespace= urn:de:efa:action > efa:actions:getobject </Action> </AuthorizationDecisionStatement> <AttributeStatement> <Subject> <NameIdentifier Format= urn:de:efa:nameidentifier:admission NameQualifier= > XYKDJFEHFIUG GHFRUKG347824KJFHEKA </NameIdentifier> </Subject> <Attribute AttributeName= objectinventory AttributeNamespace= urn:de:efa:access > <AttributeValue> </AttributeValue> </Attribute> <Attribute AttributeName=»accessCode» AttributeNamespace=»urn :de :efa :access»> <AttributeValue> AHSJFK35956HDGFJG JFKEUFN345JF </AttributeValue> </Attribute> </AttributeStatement> <ds :Signature> </ds :Signature> </Assertion> 62

65 Für die Spezifikation der Schnittstellen der Dienste werden im Folgenden die semantischen Beziehungen der Assertions als Aggregationen betrachtet, um die Schnittstellen zu vereinfachen. So enthält z. B. eine Access Assertion die zugrunde liegende Admission Assertion. Die Admission Assertion enthält die Identity Assertion, diese wiederum die Identität des Nutzers sowie die Attribute Assertions mit deren Gruppenzugehörigkeiten. Die authentisierte Identity Assertion wurde als Spezialisierung (AuthenticatedIdentityAssertion) modelliert und enthält zusätzlich eine Authentication Assertion. Die in Abbildung 28 dargestellten Aggregationsbeziehungen wurden in der Kodierung über die semantischen Verknüpfungen der in Abbildung 19 aufgeführten Merkmale realisiert, um eine Entkopplung der Assertion hinsichtlich ihrer Gültigkeit erreichen zu können. Abbildung 28 Konzeptionelle Beziehungen zwischen den Assertions Identity IdentityAssertion 0..* AttributeAssertion AuthenticatedIdentityAssertion AdmissionAssertion AuthenticationAssertion AccessAssertion 63

66 6.2 Datentypen In den Signaturen der in den folgenden Abschnitten spezifizierten Dienste werden verschiedene komplexe Datentypen für Parameter und Rückgabewerte verwendet. Dieser Abschnitt gibt zunächst einen Überblick zum konzeptionellen Zusammenhang der wichtigsten Datentypen Identifikatoren Im Anhang B der Sicherheitsarchitektur [efa_secarch10] werden die Datentypen ObjectIdentifier und PersistentObjectIdentifier spezifiziert. Zur Konkretisierung der Signaturen werden die in Abbildung 29 dargestellten Spezialisierungen unterschieden. Abbildung 29 Verwendete Datentypen für Identifikatoren Identifier code : int EFAInventoryIdentifier ObjectIdentifier ComponentIdentifier ObjectInventoryIdentifier ObjectStoreIdentifier PersistentObjectIdentifier PersistentRecordIdentifier idcode : IDCode = null PersistentFolderIdentifier Ein PersistentObjectIdentifier besteht aus dem Identifikator des verwaltenden Dienstes und dem Identifikator des Objekts. Dadurch kann ein Objekt dienstübergreifend adressiert werden. Der PersistentRecordIdentifier enthält das zusätzliche Attribute»IDCode«, das bei der Verteilung einer efa zur Identifikation der einzelnen Teile dient. Dieser Identifikationscode wird zur Erzeugung der Security Token für den Zugang (Admission Assertion) zu den Teilen einer efa benötigt. 64

67 6.2.2 Metadaten Zur Verwaltung von beschreibenden Informationen zu Objekten der elektronischen Fallakte wie die Fallakte selbst, ihre Partitionen bzw. Ordner und die Datenobjekte werden strukturierte Dokumente mit Metadaten verwendet. Ein solches Metadatendokument kann bei dem entsprechenden Dienst eingestellt und einem Objekt einer efa zugeordnet werden. Zur Konkretisierung der Signatur werden die Metadaten, wie in Abbildung 30 dargestellt, strukturiert. Abbildung 30 Unterscheidung der Metadaten zu Objekten der elektronischen Fallakte Metadata ObjectMetadata RecordMetadata FolderMetadata DataObjectMetadata Die prinzipielle Unterscheidung der verschiedenen Metadatentypen lässt Raum für die Spezifikation unterschiedlicher Eigenschaften. 6.3 Lokalisierung Wie in Abschnitt bereits beschrieben, dienen die PersistentObjectIdentifier zur Identifikation von Objekten der elektronischen Fallakte und zur Lokalisierung des diese Objekte verwaltenden Dienstes. Lokalisierungsinformationen können aber nicht nur über die Identifikatoren der Objekte transportiert werden, da sie u. U. noch nicht existieren. Aus diesem Grund basiert die Weitergabe von Lokalisierungsinformationen auf einem Zusammenspiel aus Navigation, Security Token und Identifikatoren. Abbildung 31 gibt einen Überblick zu den Datentypen, die zur Weitergabe von Lokalisierungsinformationen genutzt werden. 65

68 Abbildung 31 Weitergabe von Lokalisierungsinformationen PersistentRecordIdentifier RecordListEntry ComponentIdentifier EFAInventoryIdentifier AdmissionAssertion (from Assertion) ObjectInventoryIdentifier AccessAssertion (from Assertion) ObjectStoreIdentifier ObjectIdentifier PersistentObjectIdentifier ObjectListEntry Ausgangspunkt der Lokalisierung ist die Anforderung der Zugangsberechtigung zu den elektronischen Fallakten (Admission Assertion) eines Patienten beim efa-token Service. Dieser ermittelt mit Hilfe des efa-inventorys, zu welchen Attributen/Rollen des Anfragers ein Zugang zu elektronischen Fallakten eines Patienten möglich ist. Die vom efa-token Service ausgestellte Admission Assertion enthält die Lokalisierung des efa-inventorys für das die Admission Assertion verwendet werden kann. Unter Verwendung dieser Zugangsberechtigungen kann die Navigation zu einer bestimmten elektronischen Fallakte über eine Liste aller efas eines Patienten erfolgen. Ein Eintrag dieser Liste (RecordListEntry) enthält sowohl den PersitentRecordIdentifier einer efa als auch die für den Zugang notwendige Admission Assertion. Beide enthalten die Lokalisierung des zugehörigen efa-inventorys. Über den PersitentRecordIdentifier kann auf eine efa direkt zugegriffen werden. Die Lokalisierung in der Admission Assertion ermöglicht z. B. das Anlegen neuer Fallakten. Das gleiche Prinzip wird auch bei der Verwaltung von Objekten durch das Object Inventory angewendet. Die Access Assertion enthält die Lokalisierung des Object Inventorys bei dem sie angewendet werden kann, ein ObjectListEntry enthält PersistentObjectIdentifier zur Referenzierung von Einträgen im Object Inventory sowie die zugehörige Access Assertion. Das Object Inventory liefert die Lokalisierung des Object Store und die Identifikation der Objekte als PersitentObjectIdentifier. 6.4 Identity Provider Der Identity Provider bestätigt die Identität und/oder Authentizität eines Leistungserbringers (siehe Kapitel 7.1 der Sicherheitsarchitektur [efa_secarch10]). 66

69 Operation AuthenticatedIdentityAssertion authenticate (Authenticator a) Funktion Liefert zum angegebenen Authenticator eine IdentityAssertion. Parameter Authenticator Authenticator des Anfragers Der Authenticator kann beliebige Formen haben. Dies hängt von der Funktionalität des Identity Providers ab. Es kann sich dabei um Zertifikate oder auch um UserID und Passwort handeln. Rückgabe Authenticated- IdentityAssertion AuthenticatedIdentity Assertion des Anfragers Eine AuthenticatedIdentity Assertion ist eine Identity Assertion und besteht aus einer Authentication Assertion und einer oder mehrerer Attribute Assertion. Operation Funktion IdentityAssertion verifyidentity (Identity identity) Überprüft die angegebene Identität und liefert eine Bestätigung ihrer Gültigkeit. Parameter Identity Identität, die zu prüfen ist Rückgabe IdentityAssertion Liefert eine IdentityAssertion, wenn die Identität beim Identity Provider bekannt ist, sonst null. Diese IdentityAssertion enthält eine oder mehrere Attribute Assertion, aber keine Authentication Assertion. 6.5 Attribute Service Der Attribute Service bestätigt die Zugehörigkeit einer verifizierten und/oder authentisierten Identität zu einer Gruppe (siehe Kapitel 7.2 der Sicherheitsarchitektur [efa_secarch10]). Operation Funktion AttributeAssertion[] getattributes (IdentityAssertion iv) Bestätigt die Zugehörigkeit eines Leistungserbringers zu einer Gruppe. Parameter IdentityAssertion Verifiziert Identität zur der die Attribute ermittelt werden sollen. Rückgabe AttributeAssertion[] Liste von Attribute Assertions, welche die Attribute/Rollen der Identität bestätigen 6.6 DataChannel Service Der DataChannel Service öffnet und schließt einen geschützten Datenkanal zu einem anderen Dienst (siehe Kapitel 7.3 der Sicherheitsarchitektur [efa_secarch10]). 67

70 Operation DataChannel opendatachannel ( AccessAssertion accessassertion, ComponentIdentifier componentidentifier) Funktion Öffnet einen geschützten Datenkanal zu einem anderen Dienst. Parameter AccessAssertion Enthält Identität, Authentifikation, Attribute des Anfragers, Zugang zur efa und Zugriffsrechte. ComponentIdentifier Identifikation des Dienstes, zu dem der Datenkanal aufgebaut werden soll Rückgabe DataChannel Handle zum Zugriff auf den geschützten Datenkanal Dies ist i. d. R. ein symmetrischer Schlüssel und ein Identifikator des Security-Kontextes. Operation Funktion void closedatachannel (DataChannel channel) Schließt einen geschützten Datenkanal zu einem anderen Dienst. Parameter DataChannel Zu schließender Datenkanal Rückgabe Void 6.7 efa-token Service Der efa-token Service ist ein spezieller Security Token Service, der authentisierten Leistungserbringern unter Angabe eines Patientenidentifikators ein Security Token (Admission Assertion) für den Zugang zur elektronischen Fallakte des Patienten übergibt. Tabelle 9 gibt einen Überblick zu den Operationen des Dienstes. Tabelle 9 Operationen des efa-token Service im Überblick Signatur AdmissionAssertion[] requestadmissionassertions (IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) AdmissionAssertion[] requestalladmissionassertions (IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) AdmissionAssertion requestadmissionassertion ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode, AttributeAssertionID attributeassertionid) AdmissionAssertion[] searchadmissionassertions (IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) 68

71 EncryptedIDCode newadmissioncode (IdentityAssertion requestoridentity) AdmissionAssertion requestadmissionassertion (IdentityAssertion requestoridentity, EncryptedIDCode owneridcode, AdmissionAssertion admissionassertion) efa-token Service requestadmissionassertions() Operation Funktion AdmissionAssertion[] requestadmissionassertions ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) Liefert zur angegebenen Identität und deren Attributen bzw. Rollen alle gültigen Zugangsberechtigungen zu den elektronischen Fallakten eines Patienten auf einem Knoten. Ungültig ist eine Zugangsberechtigung, wenn kein Zugang zu einer efa mit ihr möglich ist. Parameter IdentityAssertion Identity Assertion Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. EncryptedIDCode Für den Dienst verschlüsselter Identifikationscode des Patienten Dies kann sowohl ein dauerhafter Identifikator z. B. die Krankenversicherungsnummer des Patienten als auch ein temporärer Identifikationscode z. B. aus dem Offline- Token abgeleitet sein. Rückgabe AdmissionAssertion[] Liste der gültigen Zugangsberechtigungen Die Anzahl der Zugangsberechtigungen hängt von der Anzahl der zugewiesenen Attribute bzw. Rollen ab. Für jede(s) wird eine Zugangsberechtigung erzeugt und auf Gültigkeit geprüft. 69

72 6.7.2 efa-token Service requestalladmissionassertions() Operation Funktion AdmissionAssertion[] requestalladmissionassertions ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) Liefert zur angegebenen Identität und deren Attributen bzw. Rollen alle Zugangsberechtigungen zu den elektronischen Fallakten eines Patienten auf einem Knoten, unabhängig von ihrer Gültigkeit. Ungültig ist eine Zugangsberechtigung, wenn kein Zugang zu einer efa mit ihr möglich ist. Parameter IdentityAssertion Identity Assertion Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. EncryptedIDCode Für den Dienst verschlüsselter Identifikationscode des Patienten Dies kann sowohl ein dauerhafter Identifikator z. B. die Krankenversicherungsnummer des Patienten als auch ein temporärer Identifikationscode z. B. aus dem Offline-Token abgeleitet sein. Rückgabe AdmissionAssertion[] Liste aller Zugangsberechtigungen Die Anzahl der Zugangsberechtigungen hängt von der Anzahl der zugewiesenen Attribute bzw. Rollen ab. Für jede(s) wird eine Zugangsberechtigung erzeugt efa-token Service requestadmissionassertion() Operation Funktion AdmissionAssertion requestadmissionassertion ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode, AttributeAssertionID attributeassertionid) Liefert zur angegebenen Identität und dem/der referenzierten Attribut/Rolle die entsprechende Zugangsberechtigung zu einer elektronischen Fallakte eines Patienten auf einem Knoten, unabhängig von ihrer Gültigkeit. Ungültig ist eine Zugangsberechtigung, wenn kein Zugang zu einer efa mit ihr möglich ist. Parameter IdentityAssertion [] Identity Assertion Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. EncryptedIDCode AttributeAssertionID Für den Dienst verschlüsselter Identifikationscode des Patienten Dies kann sowohl ein dauerhafter Identifikator z. B. die Krankenversicherungsnummer des Patienten als auch ein temporärer Identifikationscode z. B. aus dem Offline-Token abgeleitet sein. Identifikator der AttributeAssertion, für die die Zugangsberechtigung erzeugt werden soll Rückgabe AdmissionAssertion Zugangsberechtigung zum referenzierten Attribut 70

73 6.7.4 efa-token Service searchadmissionassertions() Operation Funktion AdmissionAssertion[] searchadmissionassertions ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode) Liefert zur angegebenen Identität und deren Attributen bzw. Rollen alle gültigen Zugangsberechtigungen zu den elektronischen Fallakten eines Patienten auf allen Knoten des Verbunds. Ungültig ist eine Zugangsberechtigung, wenn kein Zugang zu einer efa mit ihr möglich ist. Parameter IdentityAssertion [] Identity Assertion Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. EncryptedIDCode Für den Dienst verschlüsselter Identifikationscode des Patienten Dies kann sowohl ein dauerhafter Identifikator z. B. die Krankenversicherungsnummer des Patienten als auch ein temporärer Identifikationscode z. B. aus dem Offline-Token abgeleitet sein 4. Rückgabe AdmissionAssertion[] Liste der gültigen Zugangsberechtigungen zu efas auf allen Knoten Die Anzahl der Zugangsberechtigungen hängt von der Anzahl der zugewiesenen Attribute bzw. Rollen ab. Für jede(s) wird eine Zugangsberechtigung erzeugt und auf jedem Knoten auf Gültigkeit geprüft efa-token Service newadmissioncode() Operation Funktion EncryptedIDCode newadmissioncode ( IdentityAssertion requestoridentity) Liefert einen für den Anfrager verschlüsselten Identifikationscode für elektronische Fallakten eines Patienten. Dieser Identifikationscode kann z. B. für Offline-Token oder bei der Verteilung von efas genutzt werden. Parameter IdentityAssertion Identity Assertion des Anfragers Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. Rückgabe EncryptedIDCode Für den Anfrager verschlüsselter Identifikationscode des Patienten 4 Für die Version 1.0 der Anwendungsarchitektur wird von der Existenz einer einzigen, den Patienten eindeutig identifizierenden ID ausgegangen. Sofern sich für bestimmte Patientengruppen (Selbstzahler etc.) keine langfristig gültige, für alle Krankenhäuser gleichermaßen verfügbare und ohne Mehraufwände ermittelbare ID festlegen lässt, wird diese Schnittstelle so ausgeweitet, dass mehrere identifizierende Merkmale übergeben werden können. 71

74 6.7.6 efa-token Service requestadmissionassertion() Operation Funktion AdmissionAssertion requestadmissionassertion ( IdentityAssertion requestoridentity, EncryptedIDCode owneridcode, AdmissionAssertion admissionassertion) Liefert eine aktuelle Zugangsberechtigung (Admission Assertion) zu einer elektronischen Fallakte eines Patienten auf der Grundlage des Zugangscodes der angegebenen Admission Assertion. Dazu erzeugt der Dienst für die Identität selbst und für alle Attribute/Rollen der Identität zusammen mit dem IDCode Zugangscodes, vergleicht diese mit dem Zugangscode der übergebenen Admission Assertion und testet mit Hilfe des efa- Inventory, ob der Zugang noch besteht. Wenn ja, liefert die Operation eine aktuelle Admission Assertion zurück. Parameter IdentityAssertion [] Identity Assertion Die Identity Assertion kann einen Authentisierungsnachweis (Authentication Assertion) enthalten. EncryptedIDCode AdmissionAssertion Für den Dienst verschlüsselter Identifikationscode des Patienten Dies kann sowohl ein dauerhafter Identifikator z. B. die Krankenversicherungsnummer des Patienten als auch ein temporärer Identifikationscode z. B. aus dem Offline-Token abgeleitet sein. Admission Assertion, auf deren Grundlage eine neue erstellt werden soll Rückgabe AdmissionAssertion Aktuelle Admission Assertion 6.8 efa-inventory Das efa-inventory verwaltet die elektronischen Fallakten von Patienten, die Zugangsberechtigungen mit ihren Zugriffsrechten sowie die Metadaten zu einer efa. Der Dienst ist auch ein spezieller Security Token Service, der Security Token mit den Zugriffsrechten auf eine efa (Access Assertion) ausgibt. Tabelle 10 gibt einen Überblick zu den Operationen des Dienstes. Tabelle 10 Operationen des efa-inventorys im Überblick Signatur AccessAssertion requestaccessassertion (AdmissionAssertion[] adassertion, ObjectIdentifier record) PersistentRecordIdentifier createrecord (AdmissionAssertion[] requestoradmission, AdmissionAssertion newadmission, AccessRights rights, RecordMetadata metadata) Boolean removerecord (AdmissionAssertion[] adassertion, 72

75 Signatur ObjectIdentifier record) ExistenceConfirmation[] hasrecords (AdmissionAssertion[] adassertion) RecordListEntry[] listrecords (AdmissionAssertion[] adassertion) RecordListEntry[] searchrecords (AdmissionAssertion[] adassertion) RecordMetadata getmetadata (AdmissionAssertion[] adassertion, ObjectIdentifier record) Boolean setadmission (AdmissionAssertion[] requestoradmissions, ObjectIdentifier record, AdmissionAssertion newadmission, AccessRights rights) Boolean removeadmission (AdmissionAssertion[] requestoradmissions, ObjectIdentifier record, AdmissionAssertion remove) Boolean setaccessrights (AdmissionAssertion[] requestoradmissions, ObjectIdentifier record, AdmissionAssertion accessoradmission, AccessRights rights) Boolean setmetadata (AdmissionAssertion[] adassertion, ObjectIdentifier record, RecordMetadata metadata) 73

76 6.8.1 efa-inventory requestaccessassertion() Operation Funktion AccessAssertion requestaccessassertion ( AdmissionAssertion[] adassertion, ObjectIdentifier record) Gibt eine AccessAssertion mit den Zugriffsrechten für den Zugriff auf die Datenobjekte einer efa aus. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier Identifikation der elektronischen Fallakte, gegen die die Zugangsberechtigungen geprüft werden Rückgabe AccessAssertion AccessAssertion mit den Zugriffsrechten auf die Datenobjekte aus den Zugangsberechtigungen einer efa efa-inventory createrecord() Operation Funktion PersistentRecordIdentifier createrecord ( AdmissionAssertion[] requestoradmission, AdmissionAssertion newadmission, AccessRights rights, RecordMetadata metadata) Registriert eine efa im efa-inventory, erzeugt eine Zugangsberechtigung einschließlich der Zugriffsrechte und trägt die Metadaten ein. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden Rückgabe AdmissionAssertion AccessRights RecordMetadata PersistentRecord- Identifier Zugangsberechtigung für den Eigner der efa Zugriffsrechte des Eigners der efa Metadaten zur efa Verweis auf die registrierte efa Der Verweis enthält sowohl den Identifikator der efa als auch die Lokalisierung des efa-inventory. Dieser Verweis kann für den weiteren Zugriff auf die efa verwendet werden. 74

77 6.8.3 efa-inventory removerecord () Operation Funktion Boolean removerecord ( AdmissionAssertion[] adassertion, ObjectIdentifier record) Löscht eine elektronische Fallakte und alle enthaltenen Datenobjekte. Dazu sollte die efa zunächst nur markiert werden, um den Zugriff zu sperren und zu einem geeigneten Zeitpunkt archiviert werden. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier Identifikator der efa Rückgabe Boolean TRUE, wenn das Löschen erfolgreich war, sonst FALSE efa-inventory hasrecords() Operation Funktion ExistenceConfirmation[] hasrecords ( AdmissionAssertion[] adassertion) Prüft, für welche der angegebenen Zugangsberechtigungen ein Zugang zu elektronischen Fallakten möglich ist. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden Rückgabe ExistenceConfirmation[] Liste von Existenzbestätigungen Eine Existenzbestätigung enthält eine AdmissionAssertion und einen Wahrheitswert, ob zu dieser Zugangsberechtigung eine elektronische Fallakte existiert. Abbildung 32 ExistenceConfirmation ExistenceConfirmation existent : Boolean AdmissionAssertion (from Assertion) efa-inventory listrecords() Operation Funktion RecordListEntry[] listrecords ( AdmissionAssertion[] adassertion) Listet zu den angegebenen Zugangsberechtigungen Verweise zu elektronischen Fallakten eines Knoten auf, zu denen ein Zugang möglich ist. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden Rückgabe RecordListEntry[] Liste von Verweisen auf elektronische Fallakten Ein Eintrag enthält den PersistentObjectIdentifier der efa und die Zugangsberechtigung, mit der der Zugang möglich ist. 75

78 Abbildung 33 RecordListEntry RecordListEntry PersistentRecordIdentifier idcode : IDCode = null AdmissionAssertion (from Assertion) efa-inventory searchrecords() Operation Funktion RecordListEntry[] searchrecords (AdmissionAssertion[] adassertion) Sucht zu den angegebenen Zugangsberechtigungen elektronische Fallakten auf allen Knoten des Verbundes, zu denen ein Zugang möglich ist. Das Ergebnis der Suche ist eine Liste von Verweisen. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden Rückgabe RecordListEntry[] Liste von Verweisen auf elektronische Fallakten Ein Eintrag (RecordListEntry) enthält den PersistentObjectIdentifier der efa und die Zugangsberechtigung, mit der der Zugang möglich ist. Die Lokalisierung des Knotens ist in der Zugangsberechtigung (AdmissionAssertion) und im PersistentObjectIdentifier enthalten. 76

79 6.8.7 efa-inventory getmetadata() Operation Funktion RecordMetadata getmetadata (AdmissionAssertion[] adassertion, ObjectIdentifier record) Liefert die Metadaten zu einer elektronischen Fallakte. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier Identifikator der efa Rückgabe RecordMetadata Metadaten zur elektronischen Fallakte efa-inventory setmetadata() Operation Funktion Boolean setmetadata( AdmissionAssertion[] adassertion, ObjectIdentifier record, RecordMetadata metadata) Stellt die Metadaten zu einer elektronischen Fallakte ein. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier RecordMetadata Identifikator der efa Metadaten zur elektronischen Fallakte Rückgabe Boolean TRUE, wenn das Einstellen erfolgreich war, sonst FALSE efa-inventory setadmission() Operation Funktion Boolean setadmission ( AdmissionAssertion[] requestoradmissions, ObjectIdentifier record, AdmissionAssertion newadmission, AccessRights rights) Erzeugt eine neue Zugangsberechtigung zu einer elektronischen Fallakte mit Zugriffsrechten oder ersetzt die Zugriffsrechte einer vorhandenen Zugangsberechtigung. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier AdmissionAssertion AccessRights Identifikator der efa Neue Zugangsberechtigung bzw. Zugangsberechtigung, für die die Rechte ersetzt werden sollen Zugriffsrechte auf die Datenobjekte einer efa Rückgabe Boolean TRUE, wenn das Erzeugen der Zugangsberechtigung erfolgreich war, sonst FALSE 77

80 efa-inventory setmetadata() Operation Funktion Boolean removeadmission ( AdmissionAssertion[] requestoradmissions, ObjectIdentifier record, AdmissionAssertion remove) Löscht die Zugangsberechtigung zu einer elektronischen Fallakte. Parameter AdmissionAssertion[] Liste der Zugangsberechtigungen des Anfordernden ObjectIdentifier AdmissionAssertion remove Identifikator der efa Zugangsberechtigung, die gelöscht werden soll Rückgabe Boolean TRUE, wenn das Löschen der Zugangsberechtigung erfolgreich war, sonst FALSE 6.9 Object Inventory Das Object Inventory verwaltet die Struktur der medizinischen Datenobjekte in Partitionen und Ordnern, ihre Metadaten sowie die notwendigen Verweise im Object Store. Tabelle 11 gibt einen Überblick zu den Operationen des Dienstes. Tabelle 11 Operationen des Object Inventory im Überblick Signatur ObjectListEntry[] listobjects (AccessAssertion access, MetadataAttributeName[] metadata = null, ObjectIdentifier folder = null, ObjectType type = FILE, ObjectFilter filter = null) 78

81 PersistentFolderIdentifier createpartition (AccessAssertion access, FolderMetadata metadata, PersistentRecordIdentifier extension = null) PersistentFolderIdentifier createfolder (AccessAssertion access, ObjectIdentifier parentid, FolderMetadata metadata, PersistentRecordIdentifier extension = null) ObjectMetadata getmetadata (AccessAssertion access, ObjectIdentifier objectid) Boolean setmetadata (AccessAssertion access, ObjectIdentifier objectid, ObjectMetadata metadata) PersistentObjectIdentifier getsource (AccessAssertion access, ObjectIdentifier objectid) PersistentObjectIdentifier registerdataobject (AccessAssertion access, ObjectIdentifier folderid, StoreConfirmation source, State state = informationtypinitialstate, DataObjectMetadata metadata) Boolean removeobjects (AccessAssertion access) Boolean setstate (AccessAssertion access, ObjectIdentifier objectid, State state) State getstate (AccessAssertion access, ObjectIdentifier objectid) StateHistory getstatehistory (AccessAssertion access, ObjectIdentifier objectid) PersistentObjectIdentifier getlink (AccessAssertion access, ObjectIdentifier objectid) ObjectStoreIdentifier getobjectstore () EFA_Structure getstructure (AccessAssertion access, ObjectIdentifier folder = null, int depth = 1) 79

82 6.9.1 Object Inventory listobjects() Operation Funktion ObjectListEntry[] listobjects ( AccessAssertion access, MetadataAttributeName[] metadata = null, ObjectIdentifier folder = null, ObjectType type = FILE, ObjectFilter filter = null) Liefert Verweise zu den Objekten einer elektronischen Fallakte. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte MetadataAttributeName[] Liste von Attributen der Metadaten, welche im ObjectListEntry zurückgeliefert werden ObjectIdentifier ObjectType ObjectFilter Identifikator des Ordners, auf den die Liste der Datenobjekte beschränkt werden soll Der Parameter ist optional, als Default werden Datenobjekte in allen Ordnern berücksichtigt. Typ von Datenobjekten, auf den die Liste der Datenobjekte beschränkt werden soll Der Parameter ist optional, als Default werden Datenobjekte aller Typen berücksichtigt. Filter, der bei der Selektion von Datenobjekten angewendet werden soll Der Parameter ist optional, als Default werden alle Datenobjekte berücksichtigt. Rückgabe ObjectListEntry[] Liste von Verweisen auf die selektierten Datenobjekte einer efa Ein Eintrag der Liste enthält PersistentObjectIdentifier des Objekts und des Ordners, in dem das Objekt gespeichert wurde. Außerdem ist ein Verweis auf die Access Assertion, mit der zugegriffen wurde, sowie die Metadaten, deren Attributnamen angegeben wurden, enthalten. Abbildung 34 ObjectListEntry PersistentObjectIdentifier ObjectListEntry parent : PersistentObjectIdentifier {selected} AccessAssertion (from Assertion) ObjectMetadata 80

83 Parameter: ObjectType Datenobjekte bzw. Dokumente werden mit dem Pflicht-Metadatum Dokumenttyp beschrieben. Näheres zu Dokumenttypen und Metadaten ist in [efa_dado-10] spezifiziert. Als ObjectType können MIME-Types angegeben werden. Anhand dieses Metadatums kann die Beschränkung der Liste auf einen bestimmten Dokumenttyp vorgenommen werden. Parameter: ObjectFilter Der ObjectFilter ist ein generischer erweiterbarer Mechanismus, um Objekte einer elektronischen Fallakte vom Object Inventory auswählen zu lassen. Er hat einen Typ und einen interpretierbaren Ausdruck einer Filterfunktion über den Metadaten der Objekte einer elektronischen Fallakte. Ein Beipiel für die Realisierung eines Filters ist die Verwendung von XPATH [XPATH]. Der übergebene XPATH-Ausdruck wird vom Object Inventory auf den Metadaten der Objekte angewendet. Bei einem positiven Test des Ausdrucks wird ein Objekt in die Liste eingetragen und zurückgegeben, andernfalls wird es unterdrückt. 81

84 6.9.2 Object Inventory createpartition() Operation Funktion PersistentFolderIdentifier createpartition ( AccessAssertion access, FolderMetadata metadata, PersistentRecordIdentifier extension = null) Erzeugt in einer elektronischen Fallakte eine neue Partition. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Rückgabe FolderMetadata Persistent- RecordIdentifier Persistent- FolderIdentifier Metadaten zur Partition Lokation und Identifikation der Partition, falls die Partition als Erweiterung der efa auf einem anderen Knoten des Verbunds gespeichert ist Der Parameter ist optional, Standard ist null, die Partition ist lokal. Lokation und Identifikator der angelegten Partition Object Inventory createfolder() Operation Funktion PersistentFolderIdentifier createfolder (AccessAssertion access, ObjectIdentifier parentid, FolderMetadata metadata, PersistentRecordIdentifier extension = null) Erzeugt in einer elektronischen Fallakte einen neuen Ordner. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Rückgabe ObjectIdentifier FolderMetadata Persistent- RecordIdentifier Persistent- FolderIdentifier Identifikator der Partition oder Ordners, in dem der Ordner erzeugt werden soll Metadaten zum Ordner Lokation und Identifikation des Ordners, falls der Ordner als Erweiterung der efa auf einem anderen Knoten des Verbunds gespeichert ist Der Parameter ist optional, Standard ist null, der Ordner ist lokal. Lokation und Identifikator des angelegten Ordners 82

85 6.9.4 Object Inventory getmetadata() Operation Funktion ObjectMetadata getmetadata ( AccessAssertion access, ObjectIdentifier objectid) Liefert die Metadaten zum referenzierten Datenobjekt, Ordner oder zu einer Partition. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte ObjectIdentifier Identifikator des Datenobjekts, der Partition oder des Ordners Rückgabe ObjectMetadata Metadaten zum referenzierten Datenobjekt, Ordner oder zu einer Partition Object Inventory setmetadata() Operation Funktion Boolean setmetadata ( AccessAssertion access, ObjectIdentifier objectid, ObjectMetadata metadata) Stellt neue Metadaten zum referenzierten Datenobjekt, Ordner oder zu einer Partition ein. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte ObjectIdentifier ObjectMetadata Identifikator des Datenobjekts, der Partition oder des Ordners Metadaten zum referenzierten Datenobjekt, Ordner oder zu einer Partition Rückgabe Boolean TRUE, wenn das Einstellen des Objekts erfolgreich war, sonst FALSE 83

86 6.9.6 Object Inventory getsource() Operation Funktion PersistentObjectIdentifier getsource ( AccessAssertion access, ObjectIdentifier objectid) Liefert die Lokation des Speicherorts und den Identifikator des referenzierten Datenobjekts, Ordners oder einer Partition. Bei Datenobjekten handelt es sich um die Lokation des ObjectStores, bei Partitionen und Ordnern um die Lokation des ObjectInventory, auf dem diese(r) gespeichert ist. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Rückgabe ObjectIdentifier Persistent- ObjectIdentifier Identifikator des Datenobjekts, der Partition oder des Ordners Lokation und Identifikator des referenzierten Datenobjekts, Ordners oder einer Partition Object Inventory registerdataobject() Operation Funktion PersistentObjectIdentifier registerdataobject ( AccessAssertion access, ObjectIdentifier folderid, StoreConfirmation source, State state = informationtypinitialstate, DataObjectMetadata metadata) Registriert ein Datenobjekt im referenzierten Ordner oder in der referenzierten Partition einer elektronischen Fallakte. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Rückgabe ObjectIdentifier StoreConfirmation State DataObjectMetadata Persistent- ObjectIdentifier Identifikator der Partition oder des Ordners, in der/dem das Objekt registriert werden soll Bestätigung des Object Store, dass das Datenobjekt unter einer bestimmten Identifikation gespeichert wurde Initialer Zustand des Datenobjekts Dieser Parameter ist optional. Für jeden Typ des registrierten Datentyps wird ein initialer Standardzustand konfiguriert. Metadaten zum Datenobjekt Identifikator und Lokation des Datenobjekts im ObjectInventory 84

87 6.9.8 Object Inventory removeobjects() Operation Funktion Boolean removeobjects (AccessAssertion access) Löscht alle Datenobjekte in einer elektronischen Fallakte. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte. Rückgabe Boolean TRUE, wenn alle Objekte erfolgreich gelöscht wurden, andernfalls FALSE Object Inventory setstate() Operation Funktion Boolean setstate ( AccessAssertion access, ObjectIdentifier objectid, State state) Setzt den Zustand eines Objekts einer elektronischen Fallakte. Jede Zustandsänderung wird in einer Zustandshistorie erfasst. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Objekte ObjectIdentifier State Identifikator der Partition, des Ordners oder des Datenobjekts, deren/dessen Zustand geändert werden soll Zustand des Objekts einer elektronischen Fallakte Rückgabe Boolean TRUE, wenn der Zustand gesetzt wurde, andernfalls FALSE Object Inventory getstate() Operation Funktion State getstate ( AccessAssertion access, ObjectIdentifier objectid) Liefert den aktuellen Zustand eines Objekts einer elektronischen Fallakte. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Objekte ObjectIdentifier Identifikator der Partition, des Ordners oder des Datenobjekts, deren/dessen Zustand geliefert werden soll Rückgabe State Zustand des Objekts einer elektronischen Fallakte 85

88 Object Inventory getstatehistory() Operation Funktion StateHistory getstatehistory ( AccessAssertion access, ObjectIdentifier objectid) Liefert die Zustandshistorie eines Objekts einer elektronischen Fallakte. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Objekte ObjectIdentifier Identifikator der Partition, des Ordners oder des Datenobjekts, deren/dessen Zustandshistorie geliefert werden soll Rückgabe StateHistory Zustandshistorie des Objekts einer elektronischen Fallakte Object Inventory getlink() Operation Funktion PersistentObjectIdentifier getlink ( AccessAssertion access, ObjectIdentifier objectid) Liefert eine Referenz auf das angegebene Objekt einer elektronischen Fallakte im ObjectInventory. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Objekte Rückgabe ObjectIdentifier Persistent- ObjectIdentifier Identifikator der Partition, des Ordners oder des Datenobjekts, die/der/das referenziert werden soll Referenz auf das angegebene Objekt Object Inventory getobjectstore() Operation Funktion ObjectStoreIdentifier getobjectstore () Liefert die Lokation und Identifikation des Object Store, der dem Object Inventory zugewiesen ist. Beim Einstellen neuer Objekte wird diese Operation verwendet, um den Object Store zu ermitteln, in dem die neuen Objekte gespeichert werden. Parameter - - Rückgabe ObjectStore- Identifier Lokation und Identifikation des zugewiesenen Object Store. 86

89 Object Inventory getstructure() Operation Funktion EFA_Structure getstructure ( AccessAssertion access, ObjectIdentifier folder = null, int depth = 1) Liefert die Struktur (Partitionen, Folder, Datenobjekte) in einer elektronischen Fallakte als XML-Dokument. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte ObjectIdentifier Int depth Identifikator des Ordners, auf den die Liste der Datenobjekte beschränkt werden soll Der Parameter ist optional, als Default werden Datenobjekte in allen Ordnern berücksichtigt. Tiefe, in der die Struktur geliefert werden soll: 1 = nur auf der Ebene des angegebenen Ordners 0 = maximale Tiefe, die gesamte Struktur Rückgabe EFA_Structure XML-Dokument, welches die Struktur der efa wiedergibt Abbildung 35 Schema des XML-Dokuments, welches von der Operation getstructure() geliefert wird. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns = "urn:hl7-org:v3" targetnamespace = "urn:hl7-org:v3" xmlns:xs = "http://www.w3.org/2001/xmlschema" elementformdefault = "qualified"> <xs:include schemalocation="efa-metadata.xsd"/> <xs:attributegroup name="attr.id.req"> <xs:attribute name="id" type="st" use="required"/> </xs:attributegroup> <xs:simpletype name="foldertypetype"> <xs:restriction base="st"> <xs:enumeration value="partition"/> <xs:enumeration value="aggregate"/> </xs:restriction> </xs:simpletype> <xs:element name="folder" type="folderstructuretype"/> <xs:complextype name="folderstructuretype"> <xs:sequence> <xs:element ref="metadata"/> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="folder" type="folderstructuretype"/> <xs:element name="object"> <xs:complextype> <xs:sequence> <xs:element ref="metadata"/> </xs:sequence> <xs:attributegroup ref="attr.id.req"/> </xs:complextype> </xs:element> </xs:choice> </xs:sequence> <xs:attributegroup ref="attr.id.req"/> 87

90 <xs:attribute name="type" type="foldertypetype" use="optional"/> </xs:complextype> </xs:schema> Abbildung 36 Schema für die Kodierung der Metadaten. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:hl7-org:v3" xmlns:xs="http://www.w3.org/2001/xmlschema" targetnamespace="urn:hl7-org:v3" elementformdefault="qualified"> <xs:include schemalocation = "coreschemas/datatypes.xsd"/> <xs:include schemalocation="efa_basetypes.xsd"/> <xs:element name="metadata"> <xs:annotation> <xs:documentation> Dieses Schema beschreibt die Metadaten, die in der efa abgelegt werden </xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence maxoccurs="unbounded"> <xs:element name="entry"> <xs:complextype> <xs:sequence> <xs:element name="name" type="st"/> <xs:element name="value" type="st"/> <xs:element name="displayname" type="st" minoccurs="0"/> <xs:element name="codesystemversion" type="st" minoccurs="0"/> </xs:sequence> <xs:attribute name="type" type="metadatatype" default="choice"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> 88

91 6.10 Object Store Der Object Store speichert die medizinischen Datenobjekte einer elektronischen Fallakte. Hierbei ist transparent, ob die medizinischen Datenobjekte als Kopien im Object Store vorgehalten oder ob diese auf Anforderung vom KIS beschafft werden. Der Object Store kann daher beliebige Caching-Strategien realisieren. Tabelle 12 gibt einen Überblick zu den Operationen des Dienstes. Tabelle 12 Operationen des Object Store im Überblick Signature Object getobject (DataChannel datachannel, AccessAssertion accessassertion, ObjectIdentifier objectid) Boolean removeobject (AccessAssertion accessassertion, ObjectIdentifier objectid) StoreConfirmation setobject (DataChannel datachannel, AccessAssertion accessassertion, Object object) Object Store getobject() Operation Funktion Object getobject ( DataChannel datachannel, AccessAssertion accessassertion, ObjectIdentifier objectid) Liefert das Datenobjekt zum angegebenen Identifikator. Diese Operation ist nur über einen geschützten Datenkanal erreichbar. Parameter DataChannel Verweis auf den Datenkanal, über den das Objekt übertragen werden soll AccessAssertion ObjectIdentifier Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Identifikator des Datenobjekts Rückgabe Object Datenobjekt zum angegebenen Identifikator 89

92 Object Store removeobject() Operation Funktion Boolean removeobject ( AccessAssertion accessassertion, ObjectIdentifier objectid) Löscht das Datenobjekt zum angegebenen Identifikator. Parameter AccessAssertion Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte ObjectIdentifier Identifikator des Datenobjekts Rückgabe Boolean TRUE, wenn das Datenobjekt erfolgreich gelöscht wurde, sonst FALSE Object Store setobject() Operation Funktion StoreConfirmation setobject ( DataChannel datachannel, AccessAssertion accessassertion, Object object) Stellt ein Datenobjekt in den Object Store ein. Diese Operation ist nur über einen geschützten Datenkanal erreichbar. Parameter DataChannel Verweis auf den Datenkanal, über den das Objekt übertragen werden soll AccessAssertion Object Zugriffscode einer elektronischen Fallakte und Zugriffsberechtigung für den Zugriff auf deren Datenobjekte Datenobjekt, welches im Object Store gespeichert werden soll Rückgabe StoreConfirmation Bestätigung über das Speichern des Datenobjekts im Object Store Dazu signiert der Object Store den Identifikator des Objekts zusammen mit der Zugriffsberechtigung des Nutzers, mit der das Objekt eingestellt wurde. Diese Bestätigung kann das Object Inventory beim Registrieren des Objekts prüfen. Dadurch wird sichergestellt, dass nur integre Objektidentifikatoren im Object Inventory gespeichert und die Zugriffsrechte nicht verletzt werden. 90

93 Abbildung 37 StoreConfirmation PersistentObjectIdentifier StoreConfirmation signature : Signature AccessAssertion (from Assertion) 6.11 efa-broker Der efa-broker dient dem Thin Client und dem Fat Client sowie dem Portal als zentraler Zugangspunkt zu den Diensten der elektronischen Fallakte eines Knotens. Er leitet die eingehenden Nachrichten an die adressierten Dienste weiter, kann sie aber gegebenenfalls auch transformieren oder eine Lastverteilung vornehmen. 91

94 7 Funktionale Spezifikation der Schnittstellen der Komponenten auf der Seite des Clients Auf der Seite des Clients finden sich in der Anwendungsarchitektur der elektronischen Fallakte die folgenden Komponenten: (Web-)Browser efa-enabler Primärsystem efa-proxy Der Browser fungiert als Thin Client und erhält Zugang zu den Diensten der elektronischen Fallakte über den efa-enabler und das Portal. Der efa- Enabler integriert Funktionalität zur Authentisierung des Nutzers und zur Ende-zu-Ende-Verschlüsselung von Daten. Das Primärsystem erhält als Fat Client über die Schnittstelle des efa-proxy Zugang zu den Diensten der elektronischen Fallakte. Der efa-proxy ist für die Lokalisierung der entfernten Dienste und die Sicherheitsfunktionen wie Authentisierung des Nutzers und Ende-zu-Ende-Verschlüsselung von Daten verantwortlich. 7.1 efa-proxy Der efa-proxy bietet einem Primärsystem eine lokale Schnittstelle zur Nutzung der entfernten Dienste der elektronischen Fallakte. Die Schnittstelle des efa-proxy arbeitet in den Parametern und Rückgabewerten ausschließlich mit PersistentObjectIdentifier zur Identifikation von Objekten. Dies ermöglicht dem efa-proxy die Lokalisierung des zugehörigen Dienstes. Tabelle 13 gibt einen Überblick zu den Operationen des efa-proxy. Nachfolgend werden die Operationen beschrieben, die nicht nur die Weiterleitung des Aufrufes an den entsprechenden Dienst vornehmen, sondern zusätzliche Funktionalität enthalten. Tabelle 13 Operationen des efa-proxy Signatur der Operationen Identity Provider 92

95 AuthenticatedIdentityAssertion authenticate (Authenticator a) IdentityAssertion verifyidentity (Identity identity) efa-token Service AdmissionAssertion[] requestadmissionassertions (IdentityAssertion requestoridentity, IDCode owneridcode) AdmissionAssertion[] requestalladmissionassertions (IdentityAssertion requestoridentity, IDCode owneridcode) AdmissionAssertion requestadmissionassertion (IdentityAssertion requestoridentity, IDCode owneridcode, AttributeAssertionID attributeassertionid) AdmissionAssertion[] searchadmissionassertions (IdentityAssertion requestoridentity, IDCode owneridcode) IDCode newadmissioncode (IdentityAssertion requestoridentity) AdmissionAssertion requestadmissionassertion (IdentityAssertion requestoridentity, IDCode owneridcode, AdmissionAssertion admissionassertion) efa-inventory RecordListEntry[] listrecords (AdmissionAssertion[] adassertion) ExistenceConfirmation[] hasrecords (AdmissionAssertion[] adassertion) Metadata getmetadata (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record) Boolean setmetadata (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record, RecordMetadata metadata) AccessAssertion requestaccessassertion (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record) Boolean removerecord (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record) PersistentRecordIdentifier createrecord (AdmissionAssertion[] requestoradmissions, AdmissionAssertion newadmission, AccessRights rights, Metadata metadata) RecordListEntry[] searchrecords (AdmissionAssertion[] adassertion) 93

96 Boolean setadmission (AdmissionAssertion[] requestoradmissions, PersistentRecordIdentifier record, AdmissionAssertion newadmission, AccessRights rights) Boolean removeadmission (AdmissionAssertion[] requestoradmissions, PersistentRecordIdentifier record, AdmissionAssertion remove) Boolean setaccessrights (AdmissionAssertion[] requestoradmissions, PersistentRecordIdentifier record, AdmissionAssertion accessoradmission, AccessRights rights) Object Inventory ObjectListEntry[] listobjects (AccessAssertion access, MetadataAttributeName[] metadata = null, PersistentFolderIdentifier folder = null, ObjectType type = FILE, ObjectFilter filter = null) PersistentFolderIdentifier createpartition (AccessAssertion access, FolderMetadata metadata, PersistentRecordIdentifier extension = null) PersistentFolderIdentifier createfolder (AccessAssertion access, PersistentFolderIdentifier parentid, FolderMetadata metadata, PersistentRecordIdentifier extension = null) ObjectMetadata getmetadata (AccessAssertion access, PersistentObjectIdentifier objectid) Boolean setmetadata (AccessAssertion access, PersistentObjectIdentifier objectid, ObjectMetadata metadata) State getstate (AccessAssertion access, PersistentObjectIdentifier objectid) Boolean setstate (AccessAssertion access, PersistentObjectIdentifier objectid, State state) StateHistory getstatehistory (AccessAssertion access, PersistentObjectIdentifier objectid) Object-Inventory/Object Store Object getobject (AccessAssertion accessassertion, PersistentObjectIdentifier objectid) PersistentObjectIdentifier setobject (AccessAssertion accessassertion, PersistentFolderIdentifier folder, Object object, State state = informationtypinitialstate, DataObjectMetadata metadata) 94

97 7.1.1 efa-proxy getobject() Operation Funktion Object getobject ( AccessAssertion accessassertion, PersistentObjectIdentifier objectid) Liefert ein Datenobjekt einer elektronischen Fallakte zum angegebenen Identifikator. Parameter AccessAssertion Zugriffsberechtigung für das Lesen des Objekts Persistent- ObjectIdentifier Lokation und Identifikation des Objekts im Object- Inventory Rückgabe Object Datenobjekt zum angegebenen Identifikator Die Funktionalität der Operation getobject() des efa-proxys geht aus den Sequenzdiagrammen in Abbildung 43, Abbildung 46, Abbildung 47 und Abbildung 59 hervor. Die Operation führt die folgenden Schritte aus: 1 Ermitteln der Quelle des Objekts 2 Öffnen eines sicheren Datenkanals zur Quelle des Objekts, d. h. zum Object Store (bei Bedarf) 3 Lesen des Objekts aus dem Object Store 4 Schließen des sicheren Datenkanals (wenn notwendig) efa-proxy setobject() Operation Funktion PersistentObjectIdentifier setobject ( AccessAssertion accessassertion, PersistentFolderIdentifier folder, Object object, State state = informationtypinitialstate, DataObjectMetadata metadata) Speichert ein Datenobjekt in einer elektronischen Fallakte. Parameter AccessAssertion Zugriffsberechtigung für das Speichern des Objekts Rückgabe Persistent- FolderIdentifier Object State DataObjectMetadata Persistent- ObjectIdentifier Lokation und Identifikation des Folders im Object- Inventory, in dem das Datenobjekt gespeichert werden soll Das zu speichernde Datenobjekt. Initialer Zustand des Datenobjekts Der Parameter ist optional. Metadaten zum Datenobjekt Lokation und Identifikation des Datenobjekts im Object- Inventory 95

98 Die Funktionalität der Operation setobject() des efa-proxys geht aus dem Sequenzdiagramm in Abbildung 54 hervor. Die Operation führt die folgenden Schritte aus: 1 Ermitteln des Object Store beim Object Inventory 2 Öffnen eines sicheren Datenkanals zum Object Store (bei Bedarf) 3 Speichern des Objekts im Object Store 4 Registrierung des Objekts mit seiner Quelle (Object Store), seinem Zustand und seinen Metadaten im Object Inventory 5 Schließen des sicheren Datenkanals (wenn notwendig) Diese Operation muss transaktional sein, um die Konsistenz zwischen Object Store und Object Inventory sicherzustellen. 7.2 efa-enabler Der efa-enabler kapselt Funktionalität eines Thin Client, die notwendig ist, um die Dienste der elektronischen Fallakte nutzen zu können. Dazu gehören Funktionen zur Authentisierung, zum Erzeugen und Prüfen von Signaturen und zur Verschlüsselung. Die Schnittstelle des efa-enablers arbeitet in den Parametern und Rückgabewerten ausschließlich mit PersistentObjectIdentifier zur Identifikation von Objekten. Dies ermöglicht dem efa-enabler die Lokalisierung des zugehörigen Dienstes. Tabelle 14 gibt einen Überblick zu den Operationen des efa-enablers, in denen diese Funktionen verwendet werden. Nachfolgend werden die Operationen beschrieben. Tabelle 14 Operationen des efa-enablers Signatur der Operationen AdmissionAssertion[] getadmissionassertions (PatientenID patient) RecordMetadata getmetadata (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record) Object getobject (AccessAssertion accessassertion, PersistentObjectIdentifier object) Boolean setmetadata (AdmissionAssertion[] adassertion, PersistentRecordIdentifier record, RecordMetadata metadata) 96

99 ObjectMetadata getmetadata (AccessAssertion access, PersistentObjectIdentifier objectid) Boolean setmetadata (AccessAssertion access, PersistentObjectIdentifier objectid, ObjectMetadata metadata) PersistentObjectIdentifier setobject (AccessAssertion accessassertion, PersistentObjectIdentifier folderid, Object object, State state = informationtypinitialstate, DataObjectMetadata metadata) State getstate (AccessAssertion access, PersistentObjectIdentifier objectid) Boolean setstate (AccessAssertion access, PersistentObjectIdentifier objectid, State state) efa-enabler getadmissionassertions() Operation Funktion AdmissionAssertion[] getadmissionassertions (PatientenID patient) Authentisiert den Nutzer des Thin Clients und liefert die Zugangsberechtigungen für die elektronischen Fallakten eines Patienten. Parameter PatientenID Identifikator des Patienten für dessen elektronische Fallakten der Zugang angefordert wird. Rückgabe AdmissionAssertion[] Zugangsberechtigungen zu elektronischen Fallakten des angegebenen Patienten. Diese Operation kapselt den Authentisierungsmechanismus (UserID/Passwort, Zertifikat/geheimer Schlüssel) des Thin Client. Die Funktionalität der Operation getadmissionassertions() des efa-enablers geht aus dem Sequenzdiagrammen in Abbildung 44 hervor. Die Operation führt die folgenden Schritte aus: 1 Authentisieren des Nutzers beim Identity Provider und Anfordern einer Authenticated Identity Assertion 2 Verschlüsseln der PatientenID für den efa-token Service 3 Anfordern der Zugangsberechtigungen (Admission Assertion) zu den elektronischen Fallakten des Patienten beim efa-token Service efa-enabler getmetadaten()/setmetadata() Metadaten können für eine elektronische Fallakte selbst sowie für die enthaltenen Objekte (Partitionen, Ordner und Datenobjekte) verwaltet 97

100 werden. Es kann notwendig sein, bestimmte Teile der Metadaten, die einen Bezug zum Patienten enthalten, zu verschlüsseln. Aus diesem Grund sind die Operationen zum Lesen und Einstellen von Metadaten beim efa- Enabler angesiedelt. Dieser muss die Verschlüsselung der entsprechenden Teile vornehmen, da nur er Zugriff auf den Schlüssel hat efa-enabler getstate()/setstate() In zukünftigen Ausbaustufen der elektronischen Fallakte ist vorgesehen, die Nachvollziehbarkeit und Nichtabstreitbarkeit von Zustandsänderungen zu Datenobjekten einer elektronischen Fallakte über eine qualifizierte digitale Signatur abzusichern. Das Signieren entsprechender Zustandsänderungen sowie die Prüfung von Signaturen erfolgt durch den efa-enabler efa-enabler getobject() Operation Funktion Object getobject ( AccessAssertion accessassertion, PersistentObjectIdentifier object) Liefert ein Datenobjekt einer elektronischen Fallakte zum angegebenen Identifikator. Parameter AccessAssertion Zugriffsberechtigung für das Lesen des Objekts Persistent- ObjectIdentifier Lokation und Identifikation des Objekts im Object Inventory Rückgabe Object Datenobjekt zum angegebenen Identifikator Die Funktionalität der Operation getobject() des efa-enablers geht aus den Sequenzdiagrammen in Abbildung 44 hervor. Die Operation führt die folgenden Schritte aus: 1 Ermitteln der Quelle des Objekts 2 Öffnen eines sicheren Datenkanals zur Quelle des Objekts, d. h. zum Object Store (bei Bedarf) 3 Lesen des Objekt vom Object Store 4 Schließen,des sicheren Datenkanals (wenn notwendig) 98

101 7.2.5 efa-enabler setobject() Operation Funktion PersistentObjectIdentifier setobject ( AccessAssertion accessassertion, PersistentObjectIdentifier folderid, Object object, State state = informationtypinitialstate, DataObjectMetadata metadata) Speichert ein Datenobjekt in einer elektronischen Fallakte. Parameter AccessAssertion Zugriffsberechtigung für das Speichern des Objekts Rückgabe Persistent- FolderIdentifier Object State DataObjectMetadata Persistent- ObjectIdentifier Lokation und Identifikation des Folders im Object Inventory, in dem das Datenobjekt gespeichert werden soll Das zu speichernde Datenobjekt Initialer Zustand des Datenobjekts Der Parameter ist optional. Metadaten zum Datenobjekt Lokation und Identifikation des Datenobjekts im Object Inventory. Die Funktionalität der Operation setobject() des efa-enablers geht aus den Sequenzdiagrammen in Abbildung 55 hervor. Die Operation führt die folgenden Schritte aus: 1 Ermitteln des Object Stores beim Object Inventory 2 Öffnen eines sicheren Datenkanals zum Object Store (bei Bedarf) 3 Speichern des Objekts im Object Store 4 Registrieren des Objekts mit seiner Quelle (Object Store), seinem Zustand und seinen Metadaten im Object Inventory 5 Schließen des sicheren Datenkanals (wenn notwendig) Diese Operation muss transaktional sein, um die Konsistenz zwischen Object Store und Object Inventory sicherzustellen. 99

102 8 Nutzungsszenarien der elektronischen Fallakte In den folgenden Nutzungsszenarien soll die Anwendung der elektronischen Fallakte beispielhaft demonstriert werden. 8.1 Zugang zur elektronischen Fallakte und Zugriffsrechte Zugang zu einer elektronischen Fallakte herstellen (Fat Client) Dieses Szenario verdeutlicht, wie der Zugang zu einer elektronischen Fallakte eines Patienten durch einen Leistungserbringer mit Hilfe eines Primärsystems (Fat Client) hergestellt wird. Der Fat Client verwendet dazu das API des EFA-Proxys. Abbildung 38 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung des Nutzers beim Identity Provider mit Hilfe eines beliebigen Authentikators z. B. eines Zertifikats oder durch UserID und Passwort 2 Überprüfung der Identität und Authentizität durch den Identity Provider und Attributierung der Identität durch den Attribute Service sowie Rückgabe einer Identity Assertion 3 Anfordern von Admission Assertion beim EFA-Token Service Dabei erzeugt der EFA-Token Service für alle in der Identity Assertion eingebrachten Attribute (Rollen) Zugänge und überprüft deren Existenz mit Hilfe des EFA-Inventorys. 100

103 Abbildung 38 Ablauf beim Herstellen des Zugangs zu einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory Der Authenticator stellt einen Nachweis der Authentisierung dar, die auf beliebige Weise (UserID+Passwort, Zertifikat etc.) erfolgen kann. 1. authenticate(authenticator) 1.1. authenticate(authenticator) getattributes(identity) AttributeAssertion[] AuthenticatedIdentityAssertion 1.2. AuthenticatedIdentityAssertion Mit AuthenticatedIdentityAssertion (IdentityAssertion) und IDCode (patientenbezogener Identifikator der efa z. B. die KV-Nr. des Patienten) wird der Zugang (AdmissionAssertion) zur efa angefordert. 2. requestadmissionassertions(identityassertion, IDCode) 2.1. requestadmissionassertions(identityassertion, EncryptedIDCode) hasrecords(admissionassertion[]) ExistenceConfirmation AdmissionAssertion[] 2.2. AdmissionAssertion[] 101

104 8.1.2 Zugang zu einer elektronischen Fallakte herstellen (Thin Client) Dieses Szenario verdeutlicht, wie der Zugang zu einer elektronischen Fallakte eines Patienten durch einen Leistungserbringer mit Hilfe von Browser und Portal (Thin Client) hergestellt wird. Der Browser verwendet dazu das API des EFA-Enablers und das API des Portals. Abbildung 39 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 http-request des Browsers mit Anforderung der entsprechenden HTML-Seite (startefa()) 2 Rendering der HTML-Seite durch den Browser einschließlich Laden/Aktivieren des EFA-Enablers und Aufruf der Operation getadmissionassertion() mit Übergabe des Patienten-Identifikators Der EFA-Enabler übernimmt die Authentisierung und Anforderung der Admission Assertions äquivalent zum Fat Client. 102

105 Abbildung 39 Ablauf beim Herstellen des Zugangs zu einer elektronischen Fallakte (Thin Client) B : Browser E : EFA_Enabler P : Portal IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory Der Browser fordert die Startseite beim Portal an. Bei der Darstellung im Browser lädt und/oder initialisiert diese den efa-enabler. 1. startefa( ) 1.1. efa Startseite Der Browser fordert über den efa-enabler die Zugänge des Leistungserbringers zu den elektronischen Fallakten des Patienten an. 2. getadmissionassertions(patientenid) 2.1. authenticate(authenticator) getattributes(identity) AttributeAssertion[] AuthenticatedIdentityAssertion 2.2. requestadmissionassertions(identityassertion, EncryptedIDCode) AdmissionAssertion[] hasrecords(admissionassertion[]) ExistenceConfirmation 2.3. AdmissionAssertion[] 103

106 8.1.3 Zugang zu einer elektronischen Fallakte einrichten (Fat Client) Dieses Szenario beschreibt das Einrichten eines Zugangs zu einer elektronischen Fallakte eines Patienten für einen Leistungserbringer bzw. eine Gruppe oder Rolle. Für eine elektronische Fallakte eines Patienten können beliebig viele Zugänge eingerichtet werden. Abbildung 40 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung des Nutzers und Ermittlung seiner Rollen- /Gruppenzugehörigkeit 2 Überprüfung der Identität des Nutzers, für den der Zugang eingerichtet werden soll, durch den Identity Provider und Auszeichnung seiner Identität mit allen Attributen durch den Attribute Service 3 Nutzer wählt die Attribute/Rollen/Gruppen aus, für die der Zugang eingerichtet werden soll. 4 Anforderung von Admission Assertions für die ausgewählten Attribute/Rollen/Gruppen vom EFA-Token Service 5 Registrieren der Zugänge beim EFA-Inventory 104

107 Abbildung 40 Ablauf beim Einrichten des Zugangs zu einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Prüfen der Identität des neuen Zugangs 1. verifyidentity(identity) 1.1. verifyidentity(identity) getattributes(identity) AttributeAssertion[] // für neuen Zugang IdentityAssertion // für neuen Zugang, nicht authentisiert 1.2. IdentityAssertion // für neuen Zugang, nicht authentisiert Auswählen des Attributes / der Rolle für das / die der Zugang erzeugt werden soll 2. selectattributeassertion(identityassertion) requestadmissionassertion( IdentityAssertion, // für neuen Zugang EncryptedIDCode, // Identifikator des Patienten AttributeAssertionID // Identifikator des Attributes / der Rolle) 3. requestadmissionassertion(identityassertion, IDCode, AttributeAssertionID) 3.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) 3.2. AdmissionAssertion setadmission( AdmissionAssertion[], PersistentRecordIdentifier, AdmissionAssertion, AccessRights) AdmissionAssertion // des Requestors // der ermittelten efa // neuer Zugang // für neuen Zugang 4. setadmission(admissionassertion[], PersistentRecordIdentifier, AdmissionAssertion, AccessRights) 4.2. Boolean 4.1. setadmission(admissionassertion[], ObjectIdentifier, AdmissionAssertion, AccessRights) Boolean 105

108 8.1.4 Zugang zu einer elektronischen Fallakte löschen (Fat Client) Existierende Zugänge zu einer elektronischen Fallakte eines Patienten werden in diesem Szenario entfernt. Abbildung 41 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung des Nutzers und Ermittlung seiner Rollen- /Gruppenzugehörigkeit 2 Überprüfung der Identität des Nutzers, für den der Zugang gelöscht werden soll, durch den Identity Provider und Auszeichnung seiner Identität mit allen Attributen durch den Attribute Service 3 Nutzer wählt die Attribute/Rollen/Gruppen aus, für die der Zugang gelöscht werden soll. 4 Anforderung von Admission Assertions für die ausgewählten Attribute/Rollen/Gruppen vom EFA-Token Service 5 Löschen der Zugänge beim EFA-Inventory 106

109 Abbildung 41 Ablauf beim Löschen des Zugangs zu einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Prüfen der Identität des zu löschenden Zugangs 1. verifyidentity(identity) 1.1. verifyidentity(identity) getattributes(identity) AttributeAssertion[] // für neuen Zugang IdentityAssertion // für neuen Zugang, nicht authentisiert 1.2. IdentityAssertion // für neuen Zugang, nicht authentisiert Auswählen des Attributes / der Rolle für das / die der Zugang gelöscht werden soll 2. selectattributeassertion(identityassertion) requestadmissionassertion( IdentityAssertion, // für zu löschenden Zugang EncryptedIDCode, // Identifikator des Patienten AttributeAssertionID // Identifikator des Attributes / der Rolle) 3. requestadmissionassertion(identityassertion, IDCode, AttributeAssertionID) 3.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) AdmissionAssertion 3.2. AdmissionAssertion removeadmission( AdmissionAssertion[], PersistentRecordIdentifier, AdmissionAssertion) // des Requestors // der ermittelten efa // zu löschender Zugang 4. removeadmission(admissionassertion[], PersistentRecordIdentifier, AdmissionAssertion) 4.2. Boolean 4.1. removeadmission(admissionassertion[], ObjectIdentifier, AdmissionAssertion) Boolean 107

110 8.1.5 Zugriffsrechte auf Objekten einer elektronischen Fallakte setzen (Fat Client) In diesem Szenario wird verdeutlicht, wie für einen Zugang die Zugriffsrechte auf den Objekten einer elektronischen Fallakte gesetzt werden. Abbildung 42 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung des Nutzers und Ermittlung seiner Rollen- /Gruppenzugehörigkeit 2 Überprüfung der Identität des Nutzers, für dessen Zugang die Zugriffsrechte gesetzt werden sollen, durch den Identity Provider und Auszeichnung seiner Identität mit allen Attributen durch den Attribute Service 3 Auswahl des Attributes bzw. der Rolle/Gruppe, für die Zugriffsrechte gesetzt werden sollen 4 Anforderung von Admission Assertions für das Attribut bzw. die Rolle/Gruppe vom EFA-Token Service 5 Setzen der Zugriffsrechte für den Zugang beim EFA-Inventory 108

111 Abbildung 42 Ablauf beim Setzen der Zugriffsrechte auf Objekten einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Prüfen der Identität des Zugangs mit zu ändernden Zugriffsrechten. 1. verifyidentity(identity) 1.1. verifyidentity(identity) getattributes(identity) AttributeAssertion[] // für neuen Zugang IdentityAssertion // für neuen Zugang, nicht authentisiert 1.2. IdentityAssertion // für neuen Zugang, nicht authentisiert Auswählen des Attributes / der Rolle des zu ändernden Zugangs. 2. selectattributeassertion(identityassertion) requestadmissionassertion( IdentityAssertion, // für zu ändernden Zugang EncryptedIDCode, // Identifikator des Patienten AttributeAssertionID // Identifikator des Attributes / der Rolle) 3. requestadmissionassertion(identityassertion, IDCode, AttributeAssertionID) 3.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) 3.2. AdmissionAssertion setaccessrights( AdmissionAssertion[], PersistentRecordIdentifier, AdmissionAssertion, AccessRights) AdmissionAssertion // des Requestors // der ermittelten efa // zu ändernder Zugang // neue Zugriffsrechte 4. setaccessrights(admissionassertion[], PersistentRecordIdentifier, AdmissionAssertion, AccessRights) 4.2. Boolean 4.1. setaccessrights(admissionassertion[], ObjectIdentifier, AdmissionAssertion, AccessRights) Boolean 109

112 8.2 Auffinden, Erzeugen und Löschen elektronischer Fallakten Auffinden elektronischer Fallakten (Fat Client) Das folgende Szenario zeigt das Auffinden von elektronischen Fallakten eines Patienten und den Zugriff auf Datenobjekte durch einen Fat Client. In diesem Szenario wird zunächst von der Verteilung elektronischer Fallakten abstrahiert. Abbildung 43 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung und Anforderung der Rolleninformationen 2 Anfordern der Zugangsberechtigung zu den elektronischen Fallakten des Patienten 3 Auflisten der elektronischen Fallakten 4 Auswahl einer elektronischen Fallakte 5 Anfordern der Metadaten und Prüfen der Zugehörigkeit zum Patienten 6 Anfordern der Zugriffsberechtigung auf Objekte der ausgewählten efa 7 Auflisten der Objekte der elektronischen Fallakte 8 Auswahl eines Objekts 9 Ermitteln des verwaltenden Dienstes des Objekts 10 Aufbau eines sicheren Datenkanals zum Dienst des ausgewählten Objekts 11 Anfordern und Entschlüsseln des Objekts Die Schritte 9-11 werden ausschließlich durch den efa-proxy ausgeführt, da nur er Zugriff auf die notwendigen Verschlüsselungsfunktionen besitzt. 110

113 Abbildung 43 Ablauf zum Auffinden einer efa und Zugriff auf ein Datenobjekt (Fat Client) PS : Primarysystem EP : EFA_Proxy 1. authenticate(authenticator) IP : IdentityProvider 1.1. authenticate(authenticator) AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory getattributes(identity) AttributeAssertion[] 1.2. AuthenticatedIdentityAssertion AuthenticatedIdentityAssertion 2. requestadmissionassertions(identityassertion, IDCode) 2.1. requestadmissionassertions(identityassertion, EncryptedIDCode) hasrecords(admissionassertion[]) ExistenceConfirmation AdmissionAssertion[] 2.2. AdmissionAssertion[] 3. listrecords(admissionassertion[]) 3.1. listrecords(admissionassertion[]) RecordListEntry[] 3.2. RecordListEntry[] 4. selectrecord(recordlistentry[]) 5. getmetadata(admissionassertion[], PersistentRecordIdentifier) 5.1. getmetadata(admissionassertion[], ObjectIdentifier) Metadata[] 5.2. Metadata[] 6. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 6.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 6.2. AccessAssertion 7. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 7.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 7.2. ObjectListEntry[] 8. selectobject(objectlistentry[]) 9. getobject(accessassertion, PersistentObjectIdentifier) 9.1. getsource(accessassertion, ObjectIdentifier) PersistentObjectIdentifier 9.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel 9.3. getobject(datachannel, AccessAssertion, ObjectIdentifier) Object 9.4. closedatachannel(datachannel) Boolean 9.5. Object DS : DataChannelService OS : ObjectStore 111

114 8.2.2 Auffinden elektronischer Fallakten (Thin Client) Das folgende Szenario zeigt das Auffinden von elektronischen Fallakten eines Patienten und den Zugriff auf Datenobjekte durch einen Thin Client. In diesem Szenario wird zunächst von der Verteilung elektronischer Fallakten abstrahiert. Das Szenario zeigt das Wechselspiel zwischen Browser, efa-enabler und Portal. Dabei schickt der Browser immer zuerst einen http-request an das Portal. Das Portal generiert die entsprechende Präsentation als HTML-Seite und liefert diese als Antwort. Die HTML-Seite wird vom Browser dargestellt; bei der Initialisierung werden Operationen des efa-enablers aufgerufen. Dadurch ist eine Verteilung der Funktionen auf Client und Portal möglich. Abbildung 44 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Anfordern der Zugangsberechtigung zu den elektronischen Fallakten des Patienten 2 Auflisten der elektronischen Fallakten 3 Auswahl einer elektronischen Fallakte 4 Auflisten der Objekte der elektronischen Fallakte und Anzeigen der Metadaten 5 Auswahl eines Objekts 6 Aufbau eines sicheren Datenkanals zum Dienst des ausgewählten Objekts 7 Anfordern und Entschlüsseln des Objekts 112

115 Abbildung 44 Auffinden einer efa durch einen Thin Client B : Browser E : P : Portal IP : AS : ETS : EI : OI : DCS : EFA_Enabler IdentityPr... AttributeSe... EFA_TokenSe... EFA_Inve... ObjectInve... DataChannelS startefa( ) 1.1. efa Startseite 2. getadmissionassertions(patientenid) 2.1. authenticate(authenticator) getattributes(identity) AttributeAssertion[] AuthenticatedIdentityAssertion 2.2. requestadmissionassertions(identityassertion, EncryptedIDCode) hasrecords(admissionassertion[]) ExistenceConfirmation 2.3. AdmissionAssertion[] AdmissionAssertion[] 3. listrecords(admissionassertion[]) 3.1. listrecords(admissionassertion[]) RecordListEntry[] 3.2. generaterecordlist(recordlistentry) 3.3. Liste der efas eines Patienten 4. selectrecord(recordlistentry[]) 5. openrecord(admissionassertion[], PersistentRecordIdentifier) 5.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 5.2. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 5.3. generateobjectlist(objectlistentry[]) 5.4. Liste der Objekte in einer efa 6. getmetadata(admissionassertion[], PersistentRecordIdentifier) 6.1. getmetadata(admissionassertion[], ObjectIdentifier) 6.2. RecordMetadata RecordMetadata 7. selectobject(objectlistentry[]) 8. getobject(objectlistentry) 8.1. AccessAssertion 9. getobject(accessassertion, PersistentObjectIdentifier) 9.1. getsource(accessassertion, ObjectIdentifier) PersistentObjectIdentifier 9.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel 9.3. getobject(datachannel, AccessAssertion, ObjectIdentifier) Object 9.4. closedatachannel(datachannel) Booelan 9.5. Object OS : ObjectStore 113

116 8.2.3 Erzeugen einer elektronischen Fallakte (Fat Client) Das folgende Szenario demonstriert die Erzeugung von elektronischen Fallakten eines Patienten durch einen Fat Client. In diesem Szenario wird zunächst von der Verteilung elektronischer Fallakten abstrahiert. Abbildung 45 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung und Anforderung der Rolleninformationen des Anfragers 2 Anfordern der Zugangsberechtigung zu den elektronischen Fallakten des Patienten für alle Rollen 3 Verifizieren der Identität des Eigners der anzulegenden efa (z.b. Krankenhaus) und Anfordern der Rolleninformationen für die Identität des Eigners 4 Auswählen einer Rolle für die Zugangsberechtigung des Eigners (z. B. Arzt) 5 Anfordern der Zugangsberechtigung mit der Identität des Eigners, der Patientenidentifikation und der ausgewählten Rolle 6 Erstellen der elektronischen Fallakte unter Angabe der Zugangsberechtigung des Anfragers, der Zugangsberechtigung des Eigners und seiner Zugriffsrechte auf die Datenobjekte sowie der Metadaten der efa 114

117 Abbildung 45 Erzeugen einer efa durch einen Fat Client PS : Primarysystem EP : EFA_Proxy 1. authenticate(authenticator) IP : IdentityProvider 1.1. authenticate(authenticator) AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory getattributes(identity) AttributeAssertion[] 1.2. AuthenticatedIdentityAssertion AuthenticatedIdentityAssertion 2. requestalladmissionassertions(identityassertion, IDCode) 2.1. requestalladmissionassertions(identityassertion, EncryptedIDCode) AdmissionAssertion[] 2.2. AdmissionAssertion[] Zugang des Requestors. Enthält die Identität und alle Attribute bzw. Rolleninformation. 3. verifyidentity(identity) Identität desjenigen, der einen Zugang zur neuen efa erhalten soll und damit Owner der efa ist verifyidentity(identity) getattributes(identity) AttributeAssertion IdentityAssertion 3.2. IdentityAssertion 4. selectattributeassertion(identityassertion) Selektion der AttributeAssertion für die ein Zugang erzeugt werden soll. requestadmissionassertion( IdentityAssertion, // of efa-owner IDCode, // of patient AttributeAssertionID // selected attribute) 5. requestadmissionassertion(identityassertion, IDCode, AttributeAssertionID) 5.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) AdmissionAssertion 5.2. AdmissionAssertion createrecord( AdmissionAssertion[], // of requestor AdmissionAssertion, // admission of owner AccessRights, // access rights of owner RecordMetadata) 6. createrecord(admissionassertion[], AdmissionAssertion, AccessRights, Metadata) 6.1. createrecord(admissionassertion[], AdmissionAssertion, AccessRights, RecordMetadata) 6.2. PersistentRecordIdentifier PersistentRecordIdentifier 115

118 8.2.4 Zugriff auf eine bekannte efa Dieses Szenario beschreibt den Zugriff auf eine elektronische Fallakte, deren Zugehörigkeit zu einem Patienten bereits ermittelt wurde. Bei diesem Szenario wird davon ausgegangen, dass das Primärsystem Zugänge zu elektronischen Fallakten (Admission Assertion) speichern kann. Abbildung 46 und Abbildung 47 zeigen den Ablauf des Szenarios mit den folgenden Schritten: 1 Authentisierung und Anforderung der Rolleninformationen 2 Aktualisieren der gespeicherten Zugangsberechtigung zu der bekannten elektronischen Fallakte des Patienten 3 Anfordern der Metadaten und Prüfen der Zugehörigkeit zum Patienten 4 Anfordern der Zugriffsberechtigung auf Objekte der ausgewählten efa 5 Auflisten der Objekte der elektronischen Fallakte 6 Auswahl eines Objekts 7 Ermitteln des verwaltenden Dienstes des Objekts 8 Aufbau eines sicheren Datenkanals zum Dienst des ausgewählten Objekts 9 Anfordern und Entschlüsseln des Objekts Die Schritte 7-9 werden ausschließlich durch den efa-proxy ausgeführt, da nur er Zugriff auf die notwendigen Verschlüsselungsfunktionen besitzt. 116

119 Abbildung 46 Zugriff auf eine bekannte elektronische Fallakte (1/2) PS : Primarysystem EP : EFA_Proxy 1. authenticate(authenticator) IP : IdentityProvider 1.1. authenticate(authenticator) AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory getattributes(identity) AttributeAssertion[] AuthenticatedIdentityAssertion 1.2. AuthenticatedIdentityAssertion Eine gespeicherte Admission-Assertion wird aktualisiert. 2. requestadmissionassertion(identityassertion, IDCode, AdmissionAssertion) 2.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AdmissionAssertion) hasrecords(admissionassertion[]) ExistenceConfirmation AdmissionAssertion 2.2. AdmissionAssertion Zugriff auf die Metadaten der efa mit aktualisierter AdmissionAssertion und gespeichertem efa-identifikator. 3. getmetadata(admissionassertion[], PersistentRecordIdentifier) 3.1. getmetadata(admissionassertion[], ObjectIdentifier) RecordMetadata 3.2. RecordMetadata 4. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 4.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 4.2. AccessAssertion 5. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 5.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 5.2. ObjectListEntry 6. selectobject(objectlistentry[]) Nutzungsszenarien der elektronischen Fallakte DS : DataChannelService OS : ObjectStore 117

120 Abbildung 47 Zugriff auf eine bekannte elektronische Fallakte (2/2) PS : Primarysystem EP : EFA_Proxy 1 a thenticate(a thenticator) IP : IdentityProvider AS : AttributeService ObjectListEntry[] ETS : EFA_TokenService EI : EFA_Inventory 5.2. ObjectListEntry 6. selectobject(objectlistentry[]) 7. getobject(accessassertion, PersistentObjectIdentifier) 7.1. getsource(accessassertion, ObjectIdentifier) PersistentObjectIdentifier 7.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel 7.3. getobject(datachannel, AccessAssertion, ObjectIdentifier) Object 7.4. closedatachannel(datachannel) 7.5. Object Boolean 118 OI : ObjectInventory DS : DataChannelService OS : ObjectStore

121 Nutzungsszenarien der elektronischen Fallakte Löschen einer elektronischen Fallakte (Fat Client) Elektronische Fallakten werden komplett gelöscht, wenn der Patient seine Einwilligung dazu entzieht oder wenn der Zweck der Fallakte entfällt. Elektronische Fallakte werden nur als Ganzes gelöscht. Dieses Szenario beschreibt das Vorgehen. Es geht davon aus, dass der Zugang zur zu löschenden Fallakte hergestellt ist. Abbildung 48 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Das Löschen wird beim efa-inventory initiiert. 2 Das efa-inventory ermittelt die Zugriffsrechte des Nutzers und initiiert das Löschen der Objekte im Object Inventory. 3 Das Object Inventory löst das Löschen aller verwalteten Datenobjekte im Object Store aus und bereinigt seine eigenen Strukturen, es löscht also Partitionen, Ordner und Metadaten. Abbildung 48 Ablauf beim Löschen einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy EI : EFA_Inventory OI : ObjectInventory : ObjectStore Zugang zur efa herstellen: AdmissionAssertion[] efa-identifikator ermitteln: PersistentRecordIdentifier 1. removerecord(admissionassertion[], PersistentRecordIdentifier) 1.1. removerecord(admissionassertion[], ObjectIdentifier) requestaccessassertion(admissionassertion[], ObjectIdentifier) 1.2. Boolean Boolean removeobjects(accessassertion) Für jedes Objekt der efa im Object Store Boolean removeobject(accessassertion, ObjectIdentifier) Boolean 119

122 8.2.6 Ändern der Metadaten einer elektronischen Fallakte (Fat Client) Es kann notwendig sein, Metadaten einer elektronischen Fallakte während ihrer Lebensdauer zu ändern. Die Metadaten der elektronischen Fallakte werden als eigenständiges Dokument mit einer definierten Struktur betrachtet, welches der Fallakte zugeordnet ist. Demzufolge sind Änderungen an den Metadaten nur möglich, indem ein neues bzw. geändertes Metadatendokument eingestellt wird. Das Szenario geht davon aus, dass der Zugang zu den elektronischen Fallakten eines Patienten bereits angefordert wurde. Abbildung 49 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Auflisten der elektronischen Fallakten eines Patienten, zu denen der Nutzer Zugang hat 2 Auswahl der efa, deren Metadaten geändert werden sollen 3 Einstellen neuer bzw. geänderter Metadaten in das efa-inventory 120

123 Nutzungsszenarien der elektronischen Fallakte Abbildung 49 Ablauf beim Ändern der Metadaten einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy ETS : EFA_TokenService EI : EFA_Inventory Zugang zur efa herstellen: AdmissionAssertion[] efa-identifikator ermitteln z. B. über auflisten und auswählen einer efa: PersistentRecordIdentifier 1. listrecords(admissionassertion[]) 1.2. RecordListEntry[] 1.1. listrecords(admissionassertion[]) RecordListEntry[] selectrecord(recordlistentry[]) 2. setmetadata(admissionassertion[], PersistentRecordIdentifier, RecordMetadata) 2.1. setmetadata(admissionassertion[], ObjectIdentifier, RecordMetadata) 2.2. Boolean Boolean Ändern der Metadaten einer elektronischen Fallakte (Thin Client) Dieses Szenario zeigt das Ändern bzw. Einstellen von Metadaten unter Verwendung eines Browser und des Portals. Das Szenario geht davon aus, dass der Zugang zu den elektronischen Fallakten eines Patienten bereits angefordert wurde. Abbildung 50 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Auflisten der elektronischen Fallakten eines Patienten, zu denen der Nutzer einen Zugang besitzt 2 Auswahl der efa, deren Metadaten geändert werden sollen 3 Anforderung der aktuellen Metadaten vom efa-inventory mit Hilfe des efa-enablers Dessen Nutzung ist notwendig für den Fall, dass die Metadaten partiell verschlüsselt sind. 4 Ändern der Metadaten 5 Einstellen der geänderten Metadaten in das efa-inventory mit Hilfe des efa-enablers 121

124 Abbildung 50 Ablauf beim Ändern der Metadaten einer elektronischen Fallakte (Thin Client) B : Browser E : EFA_Enabler P : Portal EI : EFA_Inventory Zugang zur efa herstellen: AdmissionAssertion[] efa-identifikator ermitteln z. B. über auflisten und auswählen einer efa: PersistentRecordIdentifier 1. listrecords(admissionassertion[]) 1.1. listrecords(admissionassertion[]) RecordListEntry[] 1.3. Liste der efas eines Patienten selectrecord(recordlistentry[]) 1.2. generaterecordlist(recordlistentry) Lesen der Metadaten und Übertragung vom efa-invenzory über den efa-enabler zum Browser (partielle Entschlüsselung) 2. getmetadata(admissionassertion[], PersistentRecordIdentifier) 2.1. getmetadata(admissionassertion[], ObjectIdentifier) RecordMetadata 2.2. RecordMetadata 3. updatemetadata(metadata) Änderung der Metadaten im Browser und Übertragung über den efa-enabler (partielle Verschlüsselung) zum efa-inventory 4. setmetadata(admissionassertion[], PersistentRecordIdentifier, RecordMetadata) 4.1. setmetadata(admissionassertion[], ObjectIdentifier, RecordMetadata) 4.2. Boolean Boolean 122

125 Nutzungsszenarien der elektronischen Fallakte 8.3 Nutzungsszenarien zur Verwaltung von Partitionen, Ordnern und Datenobjekten Erzeugen von Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) Die Datenobjekte einer elektronischen Fallakte werden in Partitionen und Ordnern organisiert. Wie diese erzeugt werden, zeigt dieses Szenario. Das Szenario geht davon aus, dass die elektronische Fallakte des Patienten ermittelt und der Zugang hergestellt ist. Abbildung 51 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Anfordern der Zugriffsrechte auf die Objekte der elektronischen Fallakte beim efa-inventory 2 Erzeugen einer Partition im Object Inventory 3 Erzeugen eines Ordner in der neuen Partition 123

126 Abbildung 51 Ablauf beim Erzeugen von Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy EI : EFA_Inventory OI : ObjectInventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Rechte für den Zugriff auf die Objekte der efa anfordern. 1. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 1.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 1.2. AccessAssertion Partition erzeugen: createpartition( AccessAssertion, // Zugriffsrechte des Requestors FolderMetadata, // Metadaten der neuen Partition PersistentRecordIdentifier // optional, Verweis auf eine Extension-EFA) 2. createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) 2.1. createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) ObjectIdentifier // neue Partition 2.2. ObjectIdentifier // neue Partition Mit listobjects zum Parent-Folder navigieren. 3. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 3.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) 3.2. ObjectListEntry ObjectListEntry[] Folder erzeugen: createfolder( AccessAssertion, // Zugriffsrechte des Requestors ObjectIdentifier, // des/r Parent-Folders oder -Partition FolderMetadata, // Metadaten des neuen Folders PersistentRecordIdentifier // optional, Verweis auf eine Extension-EFA) 4. createfolder(accessassertion, PersistentFolderIdentifier, FolderMetadata, PersistentRecordIdentifier) 4.1. createfolder(accessassertion, ObjectIdentifier, FolderMetadata, PersistentRecordIdentifier) ObjectIdentifier // neuer Folder 4.2. ObjectIdentifier // neuer Folder 124

127 Nutzungsszenarien der elektronischen Fallakte Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) Vergleichbar zu den Metadaten einer elektronischen Fallakte, kann es notwendig sein, die Metadaten von Partitionen und Ordnern zu ändern. Die Metadaten zu Partitionen und Ordnern werden als eigenständiges Metadatendokument mit einer definierten Struktur betrachtet. Demzufolge ist ein Ändern der Metadaten nur möglich, indem ein neues Metadatendokument eingestellt wird. Das Szenario setzt voraus, dass die entsprechende efa ermittelt und der Zugang hergestellt ist. Abbildung 52 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Anfordern der Zugriffsrechte vom efa-inventory 2 Navigieren zum entsprechenden Ordner durch Auflisten und Auswahl der Objekte der efa 3 Anfordern der Metadaten zum Ordner vom Object Inventory 4 Ändern der Metadaten 5 Einstellen der geänderten Metadaten in das Object Inventory 125

128 Abbildung 52 Ablauf beim Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) PS : Prim arys ys tem EP : EFA_Proxy EI : EFA_Inventory OI : ObjectInventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Rechte für den Zugriff auf die Objekte der efa anfordern. 1. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 1.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 1.2. AccessAssertion Mit listobjects zum Folder / Partition navigieren. 2. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 2.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 2.2. ObjectListEntry getmetadata( AccessAssertion, // Zugriffsrechte des Requestors (Persistent)ObjectIdentifier // des ausgewählten Objekts aus dem ObjectListEntry) 3. getmetadata(accessassertion, PersistentObjectIdentifier) 3.2. ObjectMetadata 3.1. getmetadata(accessassertion, ObjectIdentifier) ObjectMetadata setmetadata( AccessAssertion, // Zugriffsrechte des Requestors ObjectIdentifier, // des ausgewählten Objekts aus dem ObjectListEntry ObjectMetadata // aktualisierte Metadaten zum Objekt) 4. setmetadata(accessassertion, PersistentObjectIdentifier, ObjectMetadata) 4.1. setmetadata(accessassertion, ObjectIdentifier, ObjectMetadata) 4.2. Boolean Boolean 126

129 Nutzungsszenarien der elektronischen Fallakte Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Thin Client) Dieses Szenario beschreibt das Lesen und Aktualisieren der Metadaten zu Partitionen und Ordnern unter Verwendung eines Browser und des Portals. Die Metadaten zu Partitionen und Ordnern werden als eigenständiges Metadatendokument mit einer definierten Struktur betrachtet. Demzufolge ist ein Aktualisieren der Metadaten nur möglich, indem ein neues Metadatendokument eingestellt wird. Das Szenario setzt voraus, dass sich der Nutzer authentisiert und die notwendigen Admission Assertions beschafft hat. Abbildung 53 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Der Browser fordert beim Portal die HTML-Seite zum Auflisten der efas eines Patienten an und stellt diese dar. 2 Der Nutzer selektiert die gewünschte efa. 3 Der Browser fordert vom Portal die HTML-Seite zum Öffnen der ausgewählten efa. Diese enthält die Liste der Partitionen (Ordner auf der obersten Ebene). 4 Gegebenenfalls erfolgt eine Navigation zum gewünschten Ordner. 5 Die Partition bzw. der Ordner, deren/dessen Metadaten geändert werden sollen, wird vom Nutzer selektiert. 6 Der Browser fordert vom Portal die HTML-Seite zur Bearbeitung der Metadaten an. Die Seite wird übertragen, und bei der Ausführung des Codes initiiert der Browser über den efa-enabler das Lesen der Metadaten. Die Nutzung des efa-enablers ist notwendig für den Fall, dass Metadaten partiell verschlüsselt sind. 7 Die Metadaten werden vom Nutzer geändert und mit Hilfe des efa- Enablers an das Object Inventory eingestellt. 127

130 Abbildung 53 Ablauf beim Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern und Objekten einer elektronischen Fallakte (Thin Client) B : Browser E : EFA_Enabler P : Portal EI : EFA_Inv entory OI : ObjectInv entory Zugang zur efa herstellen: AdmissionAssertion[] efa-identif ikator ermitteln z. B. über auf listen und auswählen einer efa: PersistentRecordIdentif ier 1. listrecords(admissionassertion[]) 1.1. listrecords(admissionassertion[]) RecordListEntry [] 1.3. Liste der efas eines Patienten 1.2. generaterecordlist(recordlistentry ) selectrecord(recordlistentry []) Ausgewählte efa öf f nen (Zugrif f ermöglichen) und die Datenobjekte (oberste Ebene) anzeigen. 2. openrecord(admissionassertion[], PersistentRecordIdentif ier) 2.1. requestaccessassertion(admissionassertion[], ObjectIdentif ier) AccessAssertion 2.2. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentif ier, ObjectTy pe, ObjectFilter) ObjectListEntry [] 2.4. Liste der Objekte in einer efa 2.3. generateobjectlist(objectlistentry []) 3. selectobject(objectlistentry[]) 4. updatemetadata(objectlistentry ) 4.1. AccessAssertion 5. getmetadata(accessassertion, PersistentObjectIdentif ier) 5.1. getmetadata(accessassertion, ObjectIdentif ier) ObjectMetadata 5.2. ObjectMetadata 6. updatemetadata(metadata) 7. setmetadata(accessassertion, PersistentObjectIdentif ier, ObjectMetadata) 7.1. setmetadata(accessassertion, ObjectIdentif ier, ObjectMetadata) Boolean 7.2. Boolean 128

131 Nutzungsszenarien der elektronischen Fallakte Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Fat Client) Dieses Szenario verdeutlicht das Speichern von Datenobjekten einer elektronischen Fallakte im Object Store und ihre Registrierung im Object Inventory. Das Szenario geht davon aus, dass die gewünschte efa ermittelt und der Zugang hergestellt wurde. Abbildung 54 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Anfordern der Zugriffsrechte (Access Assertion) vom efa-inventory 2 Auflisten der enthaltenen Objekte und Navigieren zum Ordner, in dem das neue Datenobjekt registriert werden soll 3 Einstellen des Datenobjekts mit Hilfe der transaktionalen Operation setobject() des efa-proxys Dieser ermittelt zunächst vom Object Inventory den Object Store, baut einen sicheren Kanal dorthin auf und stellt das Datenobjekt dort ein. Danach registriert der efa-proxy das Objekt im Object Inventory. Zum Abschluss wird der sichere Kanal zum Object Store geschlossen. 129

132 Abbildung 54 Ablauf beim Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy EI : EFA_Inventory OI : ObjectInventory DCS : DataChannelService OS : ObjectStore Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Rechte für den Zugriff auf die Objekte der efa anfordern. 1. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 1.2. AccessAssertion 1.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion Mit listobjects zum Parent-Folder navigieren. 2. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 2.2. ObjectListEntry 2.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] setobj ect( AccessAssertion, // Zugriffrechte des Requestors PersistentObjectIdentifier, // Identifikator des Folders des Objekts Object, // das Objekt selbst State, // initialer Zustand des Objekts DataObjectMetadata // Metadaten zum Objekt ) 3. setobject(accessassertion, PersistentFolderIdentifier, Object, State, DataObjectMetadata) Lokation des ObjectInventorys anhand des PersistentFolderIdentifier 3.1. getobjectstore( ) ObjectStoreIdentifier Öffnen eines sicheren Kanals zur Lokation des Objekts 3.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel Speichern des Objekt an seiner Lokation über den sicheren Kanal 3.3. setobject(datachannel, AccessAssertion, Object) StoreConfirmation // signed identifier of new object in ObjectStore registerdataobject( AccessAssertion, // Zugriffrechte des Requestors ObjectIdentifier, // Identifikator des Folders des Objekts PersistentObjectIdentifier, // Identifier + Lokation, an der das Objekt gespeichert wurde State, // initialer Zustand des Objekts DataObjectMetadata // Metadaten zum Objekt ) 3.4. registerdataobject(accessassertion, ObjectIdentifier, StoreConfirmation, State, DataObjectMetadata) PersistentObjectIdentifier // of new object in ObjectInventory Schließen eines sicheren Kanals zur Lokation des Objekts 3.5. closedatachannel(datachannel) Boolean PersistentObjectIdentifier // of new object in ObjectInventory 130

133 Nutzungsszenarien der elektronischen Fallakte Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Thin Client) Dieses Szenario verdeutlicht das Speichern von Datenobjekten einer elektronischen Fallakte im Object Store und ihre Registrierung im Object Inventory unter Verwendung eines Browser und des Portals. Das Szenario geht davon aus, dass die gewünschte efa ermittelt und der Zugang hergestellt wurde. Abbildung 55 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Der Browser fordert vom Portal die HTML-Seite zum Öffnen der ausgewählten efa an. Diese enthält die Liste der Partitionen (Ordner auf der obersten Ebene). 2 Die Metadaten der efa werden gelesen und zur Kontrolle der Patientenzugehörigkeit dargestellt. 3 Gegebenenfalls erfolgt eine Navigation zum gewünschten Ordner. 4 Der Browser fordert vom Portal die HTML-Seite zum Einstellen eines Objekts an. Die Seite wird übertragen, und bei der Ausführung des Codes initiiert der Browser über den efa-enabler das Einstellen des Objekts mit Hilfe der transaktionalen Operation setobject().diese ermittelt zunächst vom Object Inventory den Object Store, baut einen sicheren Kanal dorthin auf und stellt das Datenobjekt in den Object Store ein. Danach registriert der efa-proxy das Objekt im Object Inventory. Zum Abschluss wird der sichere Kanal zum Object Store geschlossen. 131

134 Abbildung 55 Ablauf beim Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Thin Client) B : Browser E : EFA_Enabler P : Portal EI : EFA_Inventory OI : ObjectInventory DCS : DataChannelService OS : ObjectStore Zugtang des Requestors anfordern: AdmissionAssertion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier efa öffnen / Zugriffsrechte anfordern 1. openrecord(admissionassertion[], PersistentRecordIdentifier) 1.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 1.2. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 1.3. generateobjectlist(objectlistentry[]) 1.4. Liste der Objekte in einer efa Metadaten der efa zur Kontrolle der Patientenzugehörigkeit 2. getmetadata(admissionassertion[], PersistentRecordIdentifier) 2.1. getmetadata(admissionassertion[], ObjectIdentifier) RecordMetadata 2.2. RecordMetadata Anfordern der HTML-Seite zum speichern des Objekts. 3. setobject( ) 3.1. HTML + AccessAssertion setobject( AccessAssertion, ObjectIdentifier, Object, State, DataObjectMetadata // Zugriffsrechte des Requestors // Identifikator des Folders des Objekts // das Objekt selbst // initialer Status des Objekts // Metadaten zum Objekt) 4. setobject(accessassertion, PersistentObjectIdentifier, Object, State, DataObjectMetadata) Das ObjectInventory liefert die Lokalisation des ObjectStores für neue Objekte 4.1. getobjectstore( ) ObjectStoreIdentifier Aufbau eines sicheren Kanals (Security-Kontext) zum ObjectStore 4.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel Speichern des Objekts im ObjectStore unter Vewendung des sicheren Kanals 4.3. setobject(datachannel, AccessAssertion, Object) StoreConfirmation // of new object in ObjectStore Registrieren des Objekts im ObjectInventory 4.4. registerdataobject(accessassertion, ObjectIdentifier, StoreConfirmation, State, DataObjectMetadata) PersistentObjectIdentifier // of new object in ObjectInventory Schließen des sicheren Kanals (Security-Kontext) 4.5. closedatachannel(datachannel) Boolean 4.6. PersistentObjectIdentifier // of new object in ObjectInventory 132

135 Nutzungsszenarien der elektronischen Fallakte Ändern des Status von Objekten in einer elektronischen Fallakte (Fat Client) Jedes Datenobjekt kann innerhalb seines Lebenszyklus verschiedene Zustände annehmen. Alle Zustandsänderungen werden in einer Historie nachvollziehbar gespeichert. Das Szenario zeigt das Lesen und Ändern des Zustands eines Objekts sowie das Lesen der Zustandshistorie. Das Szenario setzt voraus, dass die gewünschte efa ermittelt und der Zugang hergestellt wurde. Abbildung 56 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Anfordern der Zugriffsrechte (Access Assertion) vom efa-inventory 2 Auflisten der enthaltenen Objekte und Navigieren zu dem Datenobjekt, dessen Zustand geändert werden soll 3 Lesen des aktuellen Zustands 4 Setzen des neuen Zustands 5 Lesen der Zustandshistorie 133

136 Abbildung 56 Ablauf beim Ändern des Status von Objekten in einer elektronischen Fallakte (Fat Client) PS : Primarysystem EP : EFA_Proxy EI : EFA_Inventory OI : ObjectInventory Zugang des Requestors anfordern: AdmissionAsserion[] efa ermitteln oder gespeichert: PersistentRecordIdentifier Rechte für den Zugriff auf die Objekte der efa anfordern. 1. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 1.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 1.2. AccessAssertion Mit listobjects zum Dokument navigieren. 2. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 2.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) 2.2. ObjectListEntry[] ObjectListEntry[] getstate( AccessAssertion, // Zugriffsrechte des Requestors (Persistent)ObjectIdentifier // des ausgewählten Objekts aus dem ObjectListEntry) 3. getstate(accessassertion, PersistentObjectIdentifier) 3.1. getstate(accessassertion, ObjectIdentifier) 3.2. State State setstate( AccessAssertion, // Zugriffsrechte des Requestors (Persistent)ObjectIdentifier, // des ausgewählten Objekts aus dem ObjectListEntry State // aktualisierter Status zum Objekt) 4. setstate(accessassertion, PersistentObjectIdentifier, State) 4.2. Boolean 4.1. setstate(accessassertion, ObjectIdentifier, State) Boolean getstatehistory( AccessAssertion, // Zugriffsrechte des Requestors (Persistent)ObjectIdentifier // des ausgewählten Objekts aus dem ObjectListEntry) 5. getstatehistory(accessassertion, PersistentObjectIdentifier) 5.2. StateHistory 5.1. getstatehistory(accessassertion, ObjectIdentifier) StateHistory 134

137 Nutzungsszenarien der elektronischen Fallakte Ändern des Status von Objekten in einer elektronischen Fallakte (Thin Client) Das Szenario zeigt das Lesen und Ändern des Zustands eines Objekts sowie das Lesen der Zustandshistorie unter Verwendung eines Browsers und des Portals. Das Szenario setzt voraus, dass die gewünschte efa ermittelt und der Zugang hergestellt wurde. Abbildung 57 zeigt den Ablauf des Szenarios mit den folgenden Schritten: 1 Der Browser fordert beim Portal die HTML-Seite zum Auflisten der efas eines Patienten an und stellt diese dar. 2 Der Nutzer selektiert die gewünschte efa. 3 Der Browser fordert vom Portal die HTML-Seite zum Öffnen der ausgewählten efa an. Diese enthält die Liste der Partitionen (Ordner auf der obersten Ebene). 4 Gegebenenfalls erfolgt eine Navigation zum gewünschten Objekt. 5 Der Browser fordert beim Portal die HTML-Seite zur Änderung des Zustands an. Die Seite wird übertragen, und bei der Ausführung des Codes initiiert der Browser über den efa-enabler das Lesen des Zustands eines Datenobjekts. 6 Der Zustand wird geändert. 7 Der Browser initiiert das Setzen des geänderten Zustands über den efa- Enabler. Die Verwendung des efa-enablers ist notwendig, um die Nichtabstreitbarkeit einer solchen Zustandsänderung mit Hilfe einer Signatur realisieren zu können. Der efa-enabler muss in der Lage sein, eine entsprechende Signatur zu erzeugen und zu prüfen. 8 Der Browser fordert beim Portal eine HTML-Seite mit der Zustandshistorie an. 135

138 Abbildung 57 Ablauf beim Ändern des Status von Objekten in einer elektronischen Fallakte (Thin Client) B : Browser E : EFA_Enabler P : Portal EI : EFA_Inventory OI : ObjectInventory Zugang zur efa herstellen: AdmissionAssertion[] efa-identifikator ermitteln z. B. über auflisten und auswählen einer efa: PersistentRecordIdentifier 1. listrecords(admissionassertion[]) 1.1. listrecords(admissionassertion[]) RecordListEntry[] 1.3. Liste der efas eines Patienten 1.2. generaterecordlist(recordlistentry) selectrecord(recordlistentry[]) Ausgewählte efa öffnen (Zugriff ermöglichen) und die Datenobjekte (oberste Ebene) anzeigen. 2. openrecord(admissionassertion[], PersistentRecordIdentifier) 2.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 2.2. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 2.4. Liste der Objekte in einer efa 2.3. generateobjectlist(objectlistentry[]) 3. selectobject(objectlistentry[]) 4. updatestate(objectlistentry) 4.1. HTML + AccessAssertion 5. getstate(accessassertion, PersistentObjectIdentifier) 5.1. getstate(accessassertion, ObjectIdentifier) 5.2. State State 6. updatestate(metadata) 7. setstate(accessassertion, PersistentObjectIdentifier, State) 7.1. setstate(accessassertion, ObjectIdentifier, State) 7.2. Boolean Boolean 8. getstatehistory(objectlistentry) 8.1. getstatehistory(accessassertion, ObjectIdentifier) SateHistory 8.2. StateHistory HTML Presentation 136

139 Nutzungsszenarien der elektronischen Fallakte 8.4 Verteilung elektronischer Fallakten Bei der netzbasierten elektronischen Fallakte bieten verschiedene Provider efas über Dienstinstanzen in eigenen Knoten an. Die Knoten sind gleichberechtigt. Um einen Austausch der Informationen zu ermöglichen, sind ihre Dienste teilweise untereinander vernetzt. Es werden zwei Varianten der Verteilung elektronischer Fallakten unterschieden: Zum einen können für denselben Patienten vollständige elektronische Fallakten jeweils auf verschiedenen Knoten verwaltet werden. Wie die Verteilung erfolgt, hängt davon ab, bei welchem Leistungserbringer eine bestimmte Behandlung durchgeführt wurde. Dieses Verteilungsszenario wird im Wesentlichen durch das Weiterleiten von Suchnachrichten an alle vernetzten efa-provider abgedeckt. Zum anderen können lediglich einzelne Partitionen bzw. Ordner einer elektronischen Fallakte auf verschiedene Knoten verteilt werden. Diese Verteilung optimiert das Einspielen von Datenobjekten in eine efa z. B. aus einem Krankenhausinformationssystem, da auf diese Weise ggf. nur lokale Zugriffe notwendig sind. Zum Auffinden der elektronischen Fallakten eines Patienten müssen die notwendigen Dienste untereinander vernetzt werden. Jeder Knoten muss die anderen Knoten kennen, um entsprechende Anfragen weiterleiten zu können. Bei der Verteilung von elektronischen Fallakten entsprechend der zweiten Variante (dieselbe Akte wird auf verschiedenen Knoten verteilt verwaltet) sollen die Knoten weitestgehend autonom agieren können. Andererseits muss erkennbar sein, wenn der Zugriff auf einen Teil einer efa nicht möglich ist. Für die Verwaltung verteilter elektronischer Fallakten werden deshalb zwei efa- Typen eingeführt: Elektronische Fallakten vom Typ Primary stellen den Ursprung einer efa dar. Eine Fallakte dieses Typs wird immer zuerst angelegt. Sie hat einen eindeutigen Identifikator. Der Typ Primary wird in den Metadaten hinterlegt. Elektronische Fallakten vom Typ Extension stellen Erweiterungen zu einer Primary-eFA dar. Sie werden auf einem anderen Knoten verwaltet und besitzen ebenfalls einen eigenen Identifikator. Dadurch können sie völlig autonom angelegt und befüllt werden. Die Verknüpfung der efa-teile erfolgt bidirektional. In der Primary-eFA wird eine Partition oder ein Ordner mit einem Verweis auf eine Extension-eFA angelegt. Dieser Verweis besteht aus der Lokalisierungsinformation des Knotens sowie einem Identifikationscode der elektronischen Fallakte. Die Extension-eFA muss eine Back Reference auf die Primary-eFA und auf der obersten Ebene ausschließlich die entsprechende Partition bzw. den entsprechenden Ordner der referenzierenden Primary-eFA enthalten. 137

140 Abbildung 58 Verknüpfung der Teile einer elektronischen Fallakte Knoten 1 efa 4711 (Primary) Partition 1 Partition 2 Partition 3 Partition 4 Back Reference Identification Code 1 Identification Code 2 Knoten 2 efa 4712 (Extension) Partition 2 Knoten 3 efa 4713 (Extension) Partition 3 Back Reference Das Beispiel in Abbildung 58 zeigt die Verteilung einer efa auf drei Knoten. Die Primary-eFA befindet sich auf Knoten 1. Sie enthält neben den lokalen Partitionen 1 und 4 die entfernten Partitionen 2 und 3. Partition 2 der PrimaryeFA verweist auf die Extension-eFA mit dem Identifikator 4712 auf Knoten 2. Analog dazu referenziert Partition 3 auf die Extension-eFA 4713 auf Knoten Nutzungsszenarien verteilter elektronischer Fallakten In den folgenden Nutzungsszenarien soll die Anwendung der verteilten elektronischen Fallakte beispielhaft demonstriert werden Auffinden elektronischer Fallakten auf entfernten Knoten Das folgende Szenario zeigt das Auffinden von elektronischen Fallakten eines Patienten bei verschiedenen Anbietern und den Zugriff auf Datenobjekte durch einen Fat Client. Der Ablauf des Szenarios ist äquivalent zum Fat-Client- Szenario für lokale Zugriffe (siehe Abschnitt 8.1), wobei nach dem Auslesen der Lokalisierungsinformation auf den fremden Knoten gewechselt wird. Das Szenario gliedert sich wie folgt: 1 Authentisierung und Anforderung der Rolleninformationen 2 Suchen der Zugangsberechtigung zu elektronischen Fallakten des Patienten auf allen Knoten (Broadcast) 138

141 Nutzungsszenarien der elektronischen Fallakte 3 Suchen nach efas auf allen Knoten mit Zugang (selektiver Broadcast) 4 Auflisten aller gefundenen efas und Auswahl einer efa 5 Anfordern der Metadaten direkt vom Knoten der efa und Prüfen der Zugehörigkeit zum Patienten 6 Anfordern der Zugriffsberechtigung auf Objekte der efa 7 Auflisten der Objekte der elektronischen Fallakte 8 Auswahl eines Objekts (Navigieren zum Zielobjekt) 9 Lesen des Objekts 9.1 Ermitteln des verwaltenden Dienstes des Objekts 9.2 Aufbau eines sicheren Datenkanals zum Dienst des ausgewählten Objekts 9.3 Lesen des Objekts 9.4 Ggf. Schließen des sicheren Datenkanals In diesem Szenario werden in Schritt 2 beim Suchen nach Zugängen zu elektronischen Fallakten eines Patienten alle Knoten angesprochen und in Schritt 3 alle, auf denen ein Zugang existiert. Die Broadcast-Operation in Schritt 2 kann einerseits durch die Bildung von Clustern, andererseits auch in späteren Ausbaustufen durch die Verwaltung von Referenzen auf die Fallakten in der elektronischen Patientenakte oder auf der elektronischen Gesundheitskarte (egk) optimiert werden. Im Zweifelsfall muss die Suche allerdings auf allen Knoten ausgeführt werden. 139

142 Abbildung 59 Ablauf beim Auffinden elektronischer Fallakten auf entfernten Knoten (1/2) PS : Primarysystem EP : EFA_Proxy 1. authenticate(authenticator) IP : IdentityProvider 1.1. authenticate(authenticator) AS : AttributeService localets : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory remoteets : EFA_TokenService remoteei : EFA_Inventory remoteoi : ObjectInventory DS : DataChannelService getattributes(identity) AttributeAssertion[] AuthenticatedIdentityAssertion 1.2. AuthenticatedIdentityAssertion 2. searchadmissionassertions(identityassertion, IDCode) 2.1. searchadmissionassertions(identityassertion, EncryptedIDCode) requestadmissionassertions(identityassertion, EncryptedIDCode) hasrecords(admissionassertion[]) Liste von AdmissionAssertion von allen Nodes, bei denen eine Primary-eFA zu einem Patienten existiert. Die Lokalisierung des Nodes ist in der AdmissionAssertion enthalten ExistenceConfirmation[] requestadmissionassertions(identityassertion, EncryptedIDCode) Operation wird an alle bekannten Nodes weitergeleitet hasrecords(admissionassertion[]) ExistenceConfimation[] AdmissionAssertion[] 2.2. AdmissionAssertion[] 3. searchrecords(admissionassertion[]) AdmissionAssertion[] 3.1. searchrecords(admissionassertion[]) Die Operation listrecords wird bei allen Knoten aus der Liste der AdmissionAssertion ausgeführt listrecords(admissionassertion[]) Verweise auf alle Primary-eFAs eines Patienten mit Lokalisierung listrecords(admissionassertion[]) RecordListEntry[] RecordListEntry[] 3.2. RecordListEntry[] 4. selectrecord(recordlistentry[]) Nach der Auswahl einer efa wird der entsprechende Knoten im Weiteren direkt angesprochen. Die PersistentRecordIdentifier enthalten die entsprechende Lokalisierungsinformation des Dienstes. 5. getmetadata(admissionassertion[], PersistentRecordIdentifier) 5.1. getmetadata(admissionassertion[], ObjectIdentifier) RecordMetadata 5.2. RecordMetadata 6. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 6.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 6.2. AccessAssertion 7. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 7.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 140 OS : ObjectStore

143 Nutzungsszenarien der elektronischen Fallakte Abbildung 60 Ablauf beim Auffinden elektronischer Fallakten auf entfernten Knoten (2/2) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService localets : EFA_TokenService AccessAssertion EI : EFA_Inventory OI : ObjectInventory remoteets : EFA_TokenService remoteei : EFA_Inventory remoteoi : ObjectInventory DS : DataChannelService 6.2. AccessAssertion 7. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 7.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 7.2. ObjectListEntry 8. selectobject(objectlistentry[]) Die ObjectListEntries enthalten PersistentObjectIdentfier, die auf den entfernten Knoten verweisen. 9. getobject(accessassertion, PersistentObjectIdentifier) 9.1. getsource(accessassertion, ObjectIdentifier) PersistentObjectIdentifier 9.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel 9.3. getobject(datachannel, AccessAssertion, ObjectIdentifier) Object 9.4. closedatachannel(datachannel) Boolean 9.5. Object 141 OS : ObjectStore

144 8.5.2 Auffinden von Teilen verteilter elektronischer Fallakten Das folgende Szenario zeigt das Auffinden von Teilen einer verteilten elektronischen Fallakte eines Patienten und den Zugriff auf Datenobjekte durch einen Fat Client. Das Szenario verläuft äquivalent zum Fat-Client-Szenario nicht verteilter efas (siehe Abschnitt 8.1), wobei nach dem Auslesen der Lokalisierungsinformation in der Partition der Primary-eFA auf den Knoten der Extension-eFA gewechselt wird. Der Ablauf des Szenarios stellt sich wie folgt dar: 1 Authentisierung und Anforderung der Rolleninformationen 2 Anfordern der Zugangsberechtigung zu den elektronischen Fallakten des Patienten 3 Auflisten der Primary-eFAs 4 Auswahl einer elektronischen Fallakte 5 Anfordern der Metadaten und Prüfen der Zugehörigkeit zum Patienten 6 Anfordern der Zugriffsberechtigung auf Objekte der efa 7 Auflisten der Partitionen der elektronischen Fallakte 8 Auswahl einer entfernten Partition (Extension-eFA) 9 Anfordern einer Zugangsberechtigung vom Knoten der Extention-eFA mittels Lokalisierung (efa-inventory, Zugangscode) 10 Anfordern der Zugriffsberechtigung auf Objekte der Extension-eFA 11 Auflisten der Objekte der Extension-eFA 12 Auswahl eines Objekts 13 Aufbau eines sicheren Datenkanals zum Dienst des ausgewählten Objekts 14 Anfordern und Entschlüsseln des Objekts 142

145 Nutzungsszenarien der elektronischen Fallakte Abbildung 61 Ablauf beim Auffinden von Teilen einer verteilten elektronischen Fallakte (1/2) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService localets : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory remoteets : EFA_TokenService remoteei : EFA_Inventory remoteoi : ObjectInventory DS : DataChannelService - Authentisierung des Requestors - Lokalisierung der efas - Auswahl einer efa 1. selectrecord(recordlistentry[]) Nach der Auswahl einer efa wird der entsprechende Node im Weiteren direkt angesprochen. 2. getmetadata(admissionassertion[], PersistentRecordIdentifier) 2.1. getmetadata(admissionassertion[], ObjectIdentifier) RecordMetadata 2.2. RecordMetadata 3. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 3.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion 3.2. AccessAssertion 4. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) 4.1. listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) ObjectListEntry[] 4.2. ObjectListEntry 5. selectobject(objectlistentry[]) Selektiertes Objekt ist eine Partition mit entfernter efa auf anderem Node. 6. listobjects(accessassertion, MetadataAttributeName[], PersistentFolderIdentifier, ObjectType, ObjectFilter) Das ObjectInventory ermittelt anhand des PersitentObjectIdentifiers der Extension die Lokalisierung des verwaltenden Dienstes sowie den IdentifikationsCode und fordert damit den Zugang zum entfernten Teil der efa an. Dazu nimmt er die Authentication- und Attribute-Assertion (IdentityAssertion) und kombinierte diese mit dem IdentificationCode der Partition. Mit den AdmissionAssertions delegiert er den listobjects-aufruf an das entfernte ObjectInventory listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectFilter) requestadmissionassertions(identityassertion, EncryptedIDCode) hasrecords(admissionassertion[]) ExistenceConfirmation AdmissionAssertion[] Mit der AdmissionAssertion und des Identifikators der efa-extension aus dem PersistentObjectIdentifier fordert der Dienst eine AccessAssertion für den Zugriff auf die Objekte an. 143 OS : ObjectStore

146 Abbildung 62 Ablauf beim Auffinden verteilter elektronischer Fallakten (2/2) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService localets : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory remoteets : EFA_TokenService remoteei : EFA_Inventory remoteoi : ObjectInventory hasrecords(admissionassertion[]) DS : DataChannelService OS : ObjectStore AdmissionAssertion[] ExistenceConfirmation Mit der AdmissionAssertion und des Identifikators der efa-extension aus dem PersistentObjectIdentifier fordert der Dienst eine AccessAssertion für den Zugriff auf die Objekte an requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion listobjects(accessassertion, MetadataAttributeName[], ObjectIdentifier, ObjectType, ObjectListEntry[] ObjectListEntry[] 6.2. ObjectListEntry[] 7. selectobject(objectlistentry[]) Ein ObjectListEntry enthält PersistentObjectIdentifier mit der Lokalisierung des Dienstes, der die Objekte der Extension verwaltet. 8. getobject(accessassertion, PersistentObjectIdentifier) 8.1. getsource(accessassertion, ObjectIdentifier) PersistentObjectIdentifier 8.2. opendatachannel(accessassertion, ComponentIdentifier) DataChannel 8.3. getobject(datachannel, AccessAssertion, ObjectIdentifier) Object 8.4. closedatachannel(datachannel) 8.5. Object Boolean 144

147 Nutzungsszenarien der elektronischen Fallakte Erzeugen und Registrieren einer Extension-eFA Dieses Szenario geht davon aus, dass zunächst eine Primary-eFA angelegt worden ist. Unabhängig davon kann auf einem anderen Knoten eine Extension-eFA erzeugt werden. Die Extension-eFA muss danach lediglich in einer Partition der Primary-eFA registriert werden. Das Erzeugen und Registrieren einer Extension-eFA erfolgt in folgenden Schritten: 1 Erzeugen der Extension-eFA (siehe Erzeugen einer efa) 2 Anfordern eines Zugangscodes zur Identifikation von efas des Patienten 3 Verifikation der Identifikation des Primary-Knotens 5 und Anfordern seiner Attribute/Rollen 4 Auswahl eines Attributes/einer Rolle für den Zugang zur Extension-eFA 5 Anfordern einer Zugangsberechtigung für die ausgewählte Rolle und den angeforderten Zugangscode 6 Eintragen dieser Zugangsberechtigung in die Extension-eFA 7 Anfordern der Zugriffsrechte des Anfragers auf der Extension-eFA 8 Erzeugen einer korrespondierenden Partition 9 Suchen der Primary-eFA, Anfordern der Zugangsberechtigung und der Zugriffsrechte 10 Erzeugen einer gleichnamigen Partition in der Primary-eFA mit Lokalisierung und Zugangscode zur Extension-eFA 5 Für jeden Knoten verwaltet ein Identity Provider eine Identität, um daran dessen Rollen bzw. Attribute binden zu können. Dies ermöglicht die Kontrolle der Zugangsberechtigungen für elektronische Fallakten. 145

148 Abbildung 63 Erzeugen und Registrieren einer Extension-eFA (1/3) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory... siehe efa Erzeugen 1. requestadmissionassertion (IdentityAssertion, IDCode, AttributeAssertionID) 1.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) 1.2. OwnerAdmission = AdmissionAssertion AdmissionAssertion efa-extension erzeugen: createrecord( AdmissionAssertion[], // of requestor AdmissionAssertion, // of owner AccessRights, // of ow createrecord(admissionassertion[], AdmissionAssertion, AccessRights, Metadata) 2.1. createrecord(admissionassertion[], AdmissionAssertion, AccessRights, RecordMetadata) PersistentRecordIdentifier 2.2. PersistentRecordIdentifier Hier ist auch der Einstieg über efa-suchen möglich. Neuen Zugang über Primary-eFA erzeugen. 3. newadmissioncode(identityassertion) newadmissioncode(identityassertion) // of requestor 3.1. newadmissioncode(identityassertion) EncryptedIDCode // remote access 3.2. IDCode // remote access 4. verifyidentity(identity) Der IdentityProvider verwaltet auch Identitäten für die Zugriffe über andere Knoten. verifyidentity(identity) // for remote access 4.1. verifyidentity(identity) getattributes(identity) AttributeAssertions[] // for remote access IdentityAssertion // for remote access 4.2. IdentityAssertion // for remote access 146 OI : ObjectInventory RemoteOI : ObjectInventory

149 Nutzungsszenarien der elektronischen Fallakte Abbildung 64 Erzeugen und Registrieren einer Extension-eFA (2/3) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory 4.2. IdentityAssertion // for remote access Auswählen der Rolle/des Attributs über die/das der Remote-Zugriff erfolgen soll. 5. selectattributeassertion(identityassertion) requestadmissionassertion( IdentityAssertion, // of requestor EncryptedIDCode, // for remote access AttributeAssertionID // role/attribute for remote access) 6. requestadmissionassertion(identityassertion, IDCode, AttributeAssertionID) 6.1. requestadmissionassertion(identityassertion, EncryptedIDCode, AttributeAssertionID) AdmisssionAssertion // remote access 6.2. AdmisssionAssertion // remote access setadmission( AdmissionAssertion[], // of requestor PersistentRecordIdentifier, AdmissionAssertion, // new admission AccessRights // of new admisssion) 7. setadmission(admissionassertion[], PersistentRecordIdentifier, AdmissionAssertion, AccessRights) 7.1. setadmission(admissionassertion[], ObjectIdentifier, AdmissionAssertion, AccessRights) Boolean 7.2. Boolean Zugriffsrechte auf efa-extension anfordern, um die entfernte Partition anzulegen: requestaccessassertion( AdmissionAssertion[], // of requestor PersistentRecordIdentifier // separated from RecordListEntry) 8. requestaccessassertion(admissionassertion[], PersistentRecordIdentifier) 8.1. requestaccessassertion(admissionassertion[], ObjectIdentifier) AccessAssertion // of requestor 8.2. AccessAssertion // of requestor 147 RemoteOI : ObjectInventory

150 Abbildung 65 Erzeugen und Registrieren einer Extension-eFA (3/3) PS : Primarysystem EP : EFA_Proxy IP : IdentityProvider AS : AttributeService ETS : EFA_TokenService EI : EFA_Inventory OI : ObjectInventory AccessAssertion // of requestor 8.2. AccessAssertion // of requestor Partition in efa-extension anlegen: createpartition( AccessAssertion, // of requestor FolderMetadata, PersistenRecordIdentifier=null // local partition) 9. createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) 9.1. createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) ObjectIdentifier 9.2. ObjectIdentifier efa-extension und Zugang über anderen Knoten wurde erzeugt. Primärsystem hält den Zugangscode. Als nächstes wird die Primary-eFA zum Patienten gesucht (siehe efa Suchen), der Zugang (AdmissionAssertion) und der Zugriff (AccessAssertion) angefordert. Wenn der Zugang zur Primary-eFA nicht eingetragen ist, kann dieser nur mit einem Offline-Token erfolgen. Die AccessAssertion enthält durch ihren Bezug zur AdmissionAssertion die Lokalisierung der Primary-eFA. Mit dieser AccessAssertion wird die efa-extension als Partition eingetragen. Registrieren der efa-extension in der Primary-eFA: createpartition( AccessAssertion, // of requestor mit Lokalisierung Primary-eFA FolderMetadata, PersistentRecordIdentifier // Lokalisierung, Zugangscode und Identifier der efa-extension) 10. createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) createpartition(accessassertion, FolderMetadata, PersistentRecordIdentifier) ObjectIdentifier ObjectIdentifier 148 RemoteOI : ObjectInventory

151 Realisierungshinweise 9 Realisierungshinweise 9.1 Verwaltung von elektronischen Fallakten durch das efa-inventory Elektronische Fallakten besitzen einen eindeutigen Identifikator, der keinen Bezug zum Patienten zulassen darf. Des Weiteren sind sie durch einen Typ (Primary, Secondary) bzgl. ihrer Rolle für den Fall einer verteilten Erweiterung (vgl. Abschnitt 8.4) und durch Metadaten ausgezeichnet. Die Erweiterung (Secondary) einer elektronischen Fallakte wird mit dem Hauptteil (Primary) durch eine Referenz verknüpft, um eine transparente Navigation über den Teilen realisieren zu können. Tabelle 15 zeigt, wie die notwendigen Daten in einer Relation verwaltet werden können. Tabelle 15 Realtion zur Verwaltung elektronischer Fallakten efa_id Typ Teil von Metadaten efa 4711 Primary efa 4712 Primary efa 4713 Secondary PersistenObjectIdentifier der Primary-eFA <metadata> </metadata> <metadata> </metadata> <metadata> </metadata> 9.2 Zugangskontrolle zu elektronischen Fallakten durch das efa-inventory Für die Zugangskontrolle zu den elektronischen Fallakten eines Patienten durch einen berechtigten Leistungserbringer sind die folgenden Relationen hilfreich. Eine Relation bildet einen Zugangscode auf den Identifikator einer elektronischen Fallakte und die entsprechenden Zugriffsrechte für die im Zugangscode kodierten Leistungserbringer bzw. Gruppen ab. Unter Verwendung dieser Relation können elektronische Fallakten eines Patienten mit Zugangsberechtigung eines Leistungserbringers identifiziert und die Zugriffsrechte auf die Datenobjekte ermittelt werden. Tabelle 16 zeigt Beispieldaten für diese Relation. 149

152 Tabelle 16 Beispieldaten des efa-inventorys für die Zugangskontrolle zu elektronischen Fallakten der Patienten Zugangscode (Admission Code) Ablauf efa_id erlaubte Aktionen Typ, Hash(Geheimnis des ausstellenden Dienstes ETS,»Radiologe in der Parkklinik Leipzig«,»PID von Hrn. Meier«) Typ, Hash(Geheimnis des ausstellenden Dienstes ETS,»Physiotherapeut in Praxis ABC«,»PID von Hrn. Meier«) Typ, Hash(Geheimnis des ausstellenden Dienstes ETS,»Med. Personal Praxis Dr. Maus«,»PID von Hrn. Meier«) Typ, Hash(Geheimnis des ausstellenden Dienstes ETS,»Pflegedienst XYZ«,»PID von Hrn. Meier«) Typ, Hash(Geheimnis des ausstellenden Dienstes ETS, Neuhaus-Code,»PID von Hrn. Meier«) efa 4711 efa 4711 efa 4712 efa 4712 efa 4712 listobjects, getobject, listobjects, getobject, listobjects, getobject, listobjects, getobject, listobjects, getobject, Typ, Hash(Geheimnis des ausstellenden Dienstes ETS,»Dr. Schulz«,»PID von Hrn. Meier«) efa 4712 listobjects, getobject, 9.3 Verwaltung von Partitionen, Ordnern und Datenobjekten durch das Object Inventory Das Object Inventory verwaltet Partitionen und Ordner als eigenständige Objekte, da sie mit Metadaten annotiert und auf andere Knoten ausgelagert werden können. Für den Zugriff auf die Partitionen und Ordner einer elektronischen Fallakte kann die folgende Relation verwendet werden. Tabelle 17 zeigt beispielhaft konkrete Belegungen. 150

153 Realisierungshinweise Tabelle 17 Beispieldaten für die Zugriffskontrolle bezüglich der Partitionen und Ordner einer elektronischen Fallakte Zugriffscode (Access Code) ObjID Bezeichner Typ Ordner Metadaten Erweiterung Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) 001 Basisdaten Partition Null <metadata> </metadata> Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) 002 Ambulante Behandlung Partition Null <metadata> </metadata> Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) 003 Stationäre Behandlung DD.MM.YYYY Partition Null <metadata> </metadata> PersistentObjectIdentifier der Erweiterung (Secondary) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) 004 Planungsdaten Partition Null <metadata> </metadata> 005 Pflegedaten Partition Null 006 Ordner ABC Ordner Ordner DEF Ordner 003 Die folgende Relation bildet den Zugriffscode auf die Objekte einer elektronischen Fallakte auf deren Objektidentifikator und die Quelle des Datenobjekts ab. Tabelle 18 zeigt entsprechende Beispieldaten. Der Zugriff auf einen Eintrag des Object Inventorys wird nur gewährt, wenn der Access Code einer gültigen Access Assertion mit dem des Eintrags übereinstimmt. Tabelle 18 Beispieldaten für die Kontrolle des Zugriffs auf efa-objekte im Object Inventory Zugriffscode (Access Code) ObjektID Bezeichner Ordner Metadaten Quelle Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4712) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4712) 100 Bezeichner1 001 <metadata> </metadata> 101 Bezeichner2 003 <metadata> </metadata> 102 Bezeichner3 008 <metadata> </metadata> 103 Bezeichner4 009 <metadata> </metadata> 9.4 Speicherung der Datenobjekte im Object Store Die Relation in Tabelle 19 zeigt eine mögliche Speicherstruktur der Datenobjekte im Object Store. Als Zugriffskontrolle dient die Überprüfung des Access Codes von Objekt und mitgelieferter Access Assertion. 151

154 Tabelle 19 Beispieldaten für die Kontrolle des Zugriffs auf Objekte im Object Store Zugriffscode (Access Code) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4711) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4712) Hash(Geheimnis des ausstellenden Dienstes EI, efa 4712) ObjektID Daten 1100 WEJRIEWNsdfjkedfghos23975dgbd RdfhszIEWNsdfjkedfghos23975dgbd RIeEWNsdfjkreazertzos23975dgbd fzuoiziuouzzuidfjkedfghos23975dgbd. 152

155 Literatur 10 Literatur [b4h04.1] [b4h04.2] [BSI-eGov] bit4health: Rahmenarchitektur der Telematikinfrastruktur im Gesundheitswesen bit4health: Skizzierung der Lösungsarchitektur und Planung der Umsetzung (Solution Outline). Version 1.1 vom Modul: Sicherer Internet-Auftritt im E-Government, BSI, aus E-Government-Handbuch [BSI-GSHB] [BSI-IT-Sich] [efa_akpr-10] IT-Grundschutz die Basis für IT-Sicherheit IT-Sicherheitshandbuch Handbuch für die sichere Anwendung der Informationstechnik, hrsgg. Vom BSI, 1992 Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum sicheren Austausch von Patientendaten: Akteure und Prozesse. Version 1.0 vom 4. Juli 2006 [efa_dado-10] Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum sicheren Austausch von Patientendaten: Daten und Dokumente. Version 1.0 vom 8. Juni 2006 [efa_dtnf-10] Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum sicheren Austausch von Patientendaten: Datentypen und Nachrichtenformate. Version

156 [efa_komm- 10] [efa_sdk-10] [efa_secarch- 10] [efa_szen-10] [FuE05.1] [gem05.1] [gem05.2] [GMG] [HTML] Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Kommunikationsarchitektur. Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Sicherheits- und Datenschutzkonzept. Version 1.0 vom 12. Juni Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Sicherheitsarchitektur. Version 1.0 Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Systemgrenzen und Szenarien. Version 1.0 vom 2. Mai FuE-Projekt: Spezifikation der Lösungsarchitektur zur Unterstützung der Anwendungen der elektronischen Gesundheitskarte. Version 1.0 vom gematik: Gesamtarchitektur: Basisarchitektur für Testvorhaben Rahmenbedingungen. Version 0.8 vom gematik: Anhang und Erläuterungen zu [gem05.1]. Version 0.8 vom Gesetz zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz GMG), 2003 W3C - HyperText Markup Language (HTML) Home Page, 154

157 Literatur [RFC2119] [SAML-11] [SOA] S. Bradner,»Key words for use in RFCs to Indicate Requirement Levels,«RFC 2119, Harvard University, March 1997 E. Maler et al.»assertions and Protocol for the OASIS, Security Assertion Markup Language (SAML). OASIS, September Document ID oasis-sstc-saml-core SOA Special Interest Group [SOAP] W3C Note,»SOAP: Simple Object Access Protocol 1.1,«08 May [SOAP12] [WS-Federation Active] [WS-Federation Passive] [WS- Federation] W3C Recommendation,»SOAP 1.2 Part 1: Messaging Framework,«24 June 2003.»Web Services Federation Language: Active Requestor Profile«, BEA, IBM, Microsoft, RSA Security, VeriSign, July 2003»Web Services Federation Language: Passive Requestor Profile«, BEA, IBM, Microsoft, RSA Security, VeriSign, July 2003»Web Services Federation Language,«BEA, IBM, Microsoft, RSA Security, VeriSign, July [WS-I_BST-10] Web Services Interoperability Organization: Basic Security Profile. Version 1.0. Working Group Draft vom März [WS-I_STP-10] Web Services Interoperability Organization: SAML Token Profile. Version 1.0. Working Group Draft vom Januar [WS-Secure Conversation] [WS-Security] [WS- SecurityPolicy] [WS-Trust]»Web Services Secure Conversation Language«, IBM, Microsoft, RSA, VeriSign, December 2002 OASIS,»Web Services Security: SOAP Message Security,«15 March 2004.»Web Services Security Policy Language,«IBM, Microsoft, RSA Security, VeriSign, December 2002.»Web Services Trust Language«, IBM, Microsoft, RSA, 155

158 VeriSign, December 2002 [XPATH] XML Path Language (Xpath), Version 1.0 [WSDL] Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, 156

159 Anhang 157

160

161 Abbildungsverzeichnis A Abbildungsverzeichnis Abbildung 1 Dokumentenübersicht 11 Abbildung 2 Zugriff auf die efa über ein KIS/PVS mit integriertem Proxy (Fat Client) 12 Abbildung 3 Zugriff auf die efa über einen Browser (Thin Client) 13 Abbildung 4 Dokumentenübersicht 16 Abbildung 5 Prinzipieller Aufbau einer serviceorientierten Architektur 18 Abbildung 6 Zusammenhang zwischen elektronischer Patientenakte nach 291a und elektronischer Fallakte 22 Abbildung 7 Struktur einer elektronischen Fallakte 23 Abbildung 8 Abbildung der efa-struktur auf eine Sicht 24 Abbildung 9 Logische Vernetzung von Dienstanbietern und - nutzern der elektronischen Fallakte 25 Abbildung 10 Konzeptionelles Modell der elektronischen Fallakte (Objektmodell) 27 Abbildung 11 Patient und elektronische Fallakte 31 Abbildung 12 Beziehung zwischen Patient und efa als assoziative Klasse 32 Abbildung 13 Unidirektionaler Zugang zur elektronischen Fallakte 33 Abbildung 14 Berechtigung eines Leistungserbringers 34 Abbildung 15 Navigationsmodell der elektronischen Fallakte 37 Abbildung 16 Modell zur Zugangs- und Zugriffskontrolle der elektronischen Fallakte 38 Abbildung 17 Anwendungsarchitektur der elektronischen Fallakte 42 Abbildung 18 Security Token (Assertions) 49 Abbildung 19 Semantischer Zusammenhang zwischen den Security Token (Assertions) 49 Abbildung 20 Identity Assertion für die nicht authentisierte Identität eines Abbildung 21 Identity Assertion für die authentisierte Identität eines Abbildung 22 Attribute Assertion ausgestellt vom Attribute Service für einen Abbildung 23 Attribute Assertion ausgestellt vom Attribute Service für einen Abbildung 24 Attribute Assertion ausgestellt vom Attribute Service für einen Abbildung 25 Admission Assertion ausgestellt vom efa-token Service für die 159

162 Abbildung 26 Persönliche Admission Assertion ausgestellt vom efa-token Service für den Abbildung 27 Access Assertion ausgestellt vom efa-inventory zu einem bestimmten ZugangsCode 62 Abbildung 28 Konzeptionelle Beziehungen zwischen den Assertions 63 Abbildung 29 Verwendete Datentypen für Identifikatoren 64 Abbildung 30 Unterscheidung der Metadaten zu Objekten der elektronischen Fallakte 65 Abbildung 31 Weitergabe von Lokalisierungsinformationen 66 Abbildung 32 ExistenceConfirmation 75 Abbildung 33 RecordListEntry 76 Abbildung 34 ObjectListEntry 80 Abbildung 35 Schema des XML-Dokuments, welches von der Operation getstructure() geliefert wird. 87 Abbildung 36 Schema für die Kodierung der Metadaten. 88 Abbildung 37 StoreConfirmation 91 Abbildung 38 Ablauf beim Herstellen des Zugangs zu einer elektronischen Fallakte (Fat Client) 101 Abbildung 39 Ablauf beim Herstellen des Zugangs zu einer elektronischen Fallakte (Thin Client) 103 Abbildung 40 Ablauf beim Einrichten des Zugangs zu einer elektronischen Fallakte (Fat Client) 105 Abbildung 41 Ablauf beim Löschen des Zugangs zu einer elektronischen Fallakte (Fat Client) 107 Abbildung 42 Ablauf beim Setzen der Zugriffsrechte auf Objekten einer elektronischen Fallakte (Fat Client) 109 Abbildung 43 Ablauf zum Auffinden einer efa und Zugriff auf ein Datenobjekt (Fat Client) 111 Abbildung 44 Auffinden einer efa durch einen Thin Client 113 Abbildung 45 Erzeugen einer efa durch einen Fat Client 115 Abbildung 46 Zugriff auf eine bekannte elektronische Fallakte (1/2) 117 Abbildung 47 Zugriff auf eine bekannte elektronische Fallakte (2/2) 118 Abbildung 48 Abbildung 49 Abbildung 50 Abbildung 51 Abbildung 52 Ablauf beim Löschen einer elektronischen Fallakte (Fat Client) 119 Ablauf beim Ändern der Metadaten einer elektronischen Fallakte (Fat Client) 121 Ablauf beim Ändern der Metadaten einer elektronischen Fallakte (Thin Client) 122 Ablauf beim Erzeugen von Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client) 124 Ablauf beim Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern einer elektronischen Fallakte (Fat Client)

163 Abbildungsverzeichnis Abbildung 53 Ablauf beim Lesen und Aktualisieren der Metadaten zu Partitionen bzw. Ordnern und Objekten einer elektronischen Fallakte (Thin Client) 128 Abbildung 54 Ablauf beim Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Fat Client) 130 Abbildung 55 Ablauf beim Speichern und Registrieren von Objekten in einer elektronischen Fallakte (Thin Client) 132 Abbildung 56 Ablauf beim Ändern des Status von Objekten in einer elektronischen Fallakte (Fat Client) 134 Abbildung 57 Ablauf beim Ändern des Status von Objekten in einer elektronischen Fallakte (Thin Client) 136 Abbildung 58 Verknüpfung der Teile einer elektronischen Fallakte 138 Abbildung 59 Ablauf beim Auffinden elektronischer Fallakten auf entfernten Knoten (1/2) 140 Abbildung 60 Ablauf beim Auffinden elektronischer Fallakten auf entfernten Knoten (2/2) 141 Abbildung 61 Ablauf beim Auffinden von Teilen einer verteilten Abbildung 62 elektronischen Fallakte (1/2) 143 Ablauf beim Auffinden verteilter elektronischer Fallakten (2/2) 144 Abbildung 63 Erzeugen und Registrieren einer Extension-eFA (1/3) 146 Abbildung 64 Erzeugen und Registrieren einer Extension-eFA (2/3) 147 Abbildung 65 Erzeugen und Registrieren einer Extension-eFA (3/3)

164 B Abkürzungsverzeichnis ACL API AS ETS AZ BA BfD bit4health BMG BSI DMP DMS DMZ DoS efa egk EI epa FuE GMG HBA (HPC) HL7 HTML HTTP IP ITIL ITSEC IV KIS KVK MA MVZ OID Access Control List Application Programming Interface/Programmierschnittstelle Attribute Service EFA-Token Service Antwortzeit(kategorie) Berufsausweis Bundesbeauftragter für den Datenschutz Vom BMG initiiertes Projekt zu Ausarbeitung der Rahmenarchitektur zur egk Bundesministerium für Gesundheit Bundesamt für Sicherheit in der Informationstechnik Disease Management Programm Dokumentenmanagementsystem demilitarisierte Zone Denial of Service Elektronische Fallakte Elektronische Gesundheitskarte efa-inventory Elektronische Patientenakte gemäß 291a, Abs. 3, Satz 1, Nr. 4 SGB V Vom BMG initiiertes Projekt zur Spezifikation der Lösungsarchitektur zur egk Gesundheitsmodernisierungsgesetz Elektronischer Heilberufsausweis (Health Professional Card) Health Level 7 (HL7) ist ein internationaler Standard für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen. Hypertext Markup Language [HTML] HyperText Transfer Protocol Identity Provider IT Infrastructure Library Information Technology Security Evaluation Criteria Integrierte Versorgung Krankenhaus-Informations-System Krankenversicherungskarte Mitarbeiterausweis Medizinisches Versorgungszentrum Objektidentifikator 162

165 Abkürzungsverzeichnis Objekt-ID Patienten-ID P2P PVS SAML SGB V SigG/SigV SLA SMC SOA SOAP SSL/TSL UML UserID VPN WSDL XML Objektidentifikator Identifikator des Patienten Peer-to-Peer Praxis-Verwaltungs-System Security Assertion Markup Language Sozialgesetzbuch V Signatur-Gesetz/Signatur-Verordnung Service Level Agreement Security Module Card serviceorientierte Architektur Simple Object Access Protocol Secure Sockets Layer/Transport Level Security Unified Modelling Language Nutzerkennung/Identifikator des Nutzers Virtual Private Network Web Service Definition Language Extensible Markup Language 163

166 Sicherheits- und Datenschutzkonzept Spezifikation einer Architektur zum sicheren Austausch von Patientendaten Editor: Dr. Jörg Caumanns Verantwortlich: Fraunhofer ISST Status: Release; zur Kommentierung Version: 1.00 Berlin, 12. Juni 2006

167

168 Release-Planung Nr. Datum MS Version Status Bemerkungen Status xx draft Gliederung, Methodik, Skizzierung der Inhalte In time xx draft Schutzbedarfsanalyse, Sicherheitsstrategie 1 week late Final draft Fertiges Dokument von interner QS freigegeben. in time Beginn der Kommentierung durch LK und AGs Abschluss der (internen) Kommentierung 2 weeks late Release Veröffentlichung 3 weeks late Änderungshistorie Nr. Datum Version Status Bemerkungen Bearbeiter draft Erster Draft zur Verteilung innerhalb der AG-2 (MS 2) JC draft Schutzbedarfsanalyse anhand des Objektmodells JC draft Einpflegen der Kommentare (ULe, PF) JC draft Überarbeitung der Gliederung JC draft Vollständiger Text mit Grafiken. Freigabe für interne QS JC draft Kommentare der internen QS eingearbeitet JC draft Kommentare OB eingearbeitet JC Final draft Kommentare HK und HE eingearbeitet JC Final draft Kommentare der Projektpartner eingearbeitet JC Release Kommentare der QS eingearbeitet JC Sicherheitskonzept_v100 1

169 Copyright Copyright (c) Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH (2006). Alle Rechte vorbehalten. Dieses Dokument und Übersetzungen, die davon angefertigt wurden, dürfen kopiert und weitergegeben werden und abgeleitete Werke, die es kommentieren, erklären, oder Hilfestellung bei der Implementierung leisten, dürfen vorbereitet, kopiert, veröffentlicht und verteilt werden, als Ganzes oder in Teilen, ohne dass hierbei Einschränkungen in irgendeiner Form bestehen; vorausgesetzt, dass die obige Urheberrechtserklärung und dieser Absatz in allen Kopien und abgeleiteten Werken enthalten ist. Dieses Dokument selbst darf nur mit schriftlichem Einverständnis der Urheber modifiziert werden. Die beschränkten Rechte, die durch obige Aussage gewährt werden, sind dauerhaft und werden von den Urhebern (Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH), ihren Nachfolgeorganisationen und Rechtsnachfolgern nicht zurückgezogen werden. Dieses Dokument und die hierin enthaltene Information werden ohne Mängelgewähr zur Verfügung gestellt. DAS FRAUNHOFER-INSTITUT FÜR SOFTWARE- UND SYSTEMTECHNIK ISST, DIE ASKLEPIOS KLINIKEN VERWALTUNGSGESELLSCHAFT MBH, DIE DEUTSCHE KRANKENHAUSGESELLSCHAFT E. V., DIE RHÖN-KLINIKUM AG, DIE SANA E.MED GMBH UND DIE AN DER ERSTELLUNG DIESES DOKUMENTS BETEILIGTEN MITARBEITER DER GENANNTEN EINRICHTUNGEN SCHLIESSEN JEDE FORM DER HAFTUNG, OB GEÄUßERT ODER VERMUTET; AUS, DAFÜR DASS DIE VERWENDUNG DER INFORMATIONEN IN DIESEM DOKUMENT KEINE RECHTE VERLETZT; DASS SIE GEBRAUCHSTAUGLICH SIND ODER SICH FÜR EINEN SPEZIELLEN ZWECK EIGNEN. 2 Letzte Speicherung des Dokuments: :42:00

170 Inhalt Copyright 2 1 Management Summary 6 2 Einleitung Einordnung in den Projektkontext Vorgehensmodell Gliederung des Dokuments 12 3 Grundlagen des Sicherheitskonzepts Rechtliche Anforderungen Vorgaben, die eine elektronische Patientenakte nach 291a betreffen Vorgaben, die eine elektronische Fallakte betreffen Rechtssicherheit Anwendungsübergreifende, projektspezifische Anforderungen Konzeptionelles Modell Schutzziele Schutzbedarf und Bedrohungen 27 4 Schutzbedarfsanalyse Schutzziel Verfügbarkeit Anforderungen an die Ausfallsicherheit Anforderungen an die Performanz Schutzbedarfsanalyse Schutzziel Vertraulichkeit Anforderungen an die Vertraulichkeit Schutzbedarfsanalyse Schutzziele Integrität und Verbindlichkeit Anforderungen an die Integrität und Verbindlichkeit Schutzbedarfsanalyse Zusammenführung der Schutzbedarfe unter Berücksichtigung aller Schutzziele 32 5 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Medizinische Datenobjekte Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität 32 Sicherheitskonzept_v100 3

171 5.1.4 Schutzziele Verbindlichkeit Elektronische Patientenakte nach 291a SGB V Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität Schutzziele Verbindlichkeit Elektronische Fallakte (efa) Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität Schutzziel Verbindlichkeit Authentisierungsschlüssel und token (Anwendungsebene) Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität Schutzziel Verbindlichkeit Identitätsdaten Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität Schutzziel Verbindlichkeit Zugangsdaten und Autorisierungen Schutzziel Verfügbarkeit Schutzziel Vertraulichkeit Schutzziel Integrität Schutzziel Verbindlichkeit Technische Systemkomponenten Kommunikationsinfrastruktur Netzanbindung der Clients und der Dienste Infrastruktur- und Management-Dienste Kartenterminals 32 6 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Berechtigungsmodell Kodierung von Berechtigungen Vorgaben für das Berechtigungskonzept elektronischer Fallakten Organisatorische Maßnahmen Nutzungsbeschränkungen Schulung und Unterstützung der Ärzte Sicherheits- und Betriebshandbücher Umgang mit Logs und Traces 32 4 Letzte Speicherung des Dokuments: :42:00

172 6.3 Konzeptionelle Maßnahmen (Architektur und Infrastruktur) Multiple Defense Lines Reduktion der Komplexität Nutzung von offenen Standards Sicherheitszonen Strategie und Konzeption der Ausgestaltung von Sicherheitsdiensten Ende-zu-Ende-Verschlüsselung Integrität der Metadaten Zugangscodes Sichere Zugangstoken Hardwaregestützte Authentisierung gemäß Berechtigungsmodell Protokollierung Einwilligung zur efa-nutzung Erteilung von Zugriffsberechtigungen efa-zugriffe efa-zustände 32 7 Literatur 32 A Abbildungsverzeichnis 32 B Abkürzungsverzeichnis 32 Sicherheitskonzept_v100 5

173 1 Management Summary Neben der effizienten Umsetzung der aus den Versorgungsabläufen abgeleiteten funktionalen Anforderungen ist für die Nutzbarkeit und Akzeptanz elektronischer Fallakten (efa) im klinischen Alltag vor allem das Vorhandensein eines den gesetzlichen Vorgaben und den gegebenen Rahmenbedingungen genügenden Datenschutz- und Sicherheitsniveaus der verwalteten medizinischen Daten ausschlaggebend. Ziel des in diesem Dokument spezifizierten Sicherheits- und Datenschutzkonzepts elektronischer Fallakten ist es, sicherzustellen, dass die in einer efa verwalteten Daten integer und damit im Behandlungskontext nutzbar sind die Verbindlichkeit der Daten in Bezug auf Urheberschaft und Zusammenstellung verifizierbar ist die Verfügbarkeit der efa-anwendung den Anforderungen des Alltagsgeschäfsts in Krankenhäusern und Praxen entspricht und die Vertraulichkeit von Gesundheitsdaten zum Schutz der Persönlichkeitsrechte des Patienten gewahrt ist. Basierend auf einer Erhebung der Schutzbedarfe der genutzten Objekte sowie einer Analyse des aus den fachlichen Vorgaben resultierenden Navigationsmodells wird der efa-anwendung eine auf wenigen grundsätzlichen Festlegungen basierende Sicherheitsstrategie zugrunde gelegt: Berechtigungen sind immer an gesamte Fallakten geknüpft und können sowohl an Individuen wie auch an Organisationen, Organisationseinheiten und Rollen vergeben werden. Die Verknüpfung von Personen und Gruppen erfolgt im Rahmen der Authentisierung durch ein Identitätsmanagement. Verteidigungslinien werden nicht an technologischen Ebenen und Bausteinen ausgerichtet, sondern entlang der Kontroll- und Datenflüsse gezogen. Die Mechanismen zur Sicherstellung der Integrität von Fallakten und Berechtigungen zielt nicht auf einzelne Objekte, sondern vor allem auf Beziehungen zwischen Objekten entlang der Pfade des Objekt- und Navigationsmodells ab. Der Schutz der Vertraulichkeit patientenbezogener Informationen wird durch eine Pseudonymisierung des Patienten innerhalb der Abläufe realisiert. Zugangs-, Struktur- und Metadaten sowie Nachrichten zur Navigation über Fallakten enthalten keine für unberechtigte Personen auflösbaren Bezüge zu Patienten. Hierdurch können efa-navigation und Präsentation serverseitig über Portale realisiert werden ohne dass für den Portal-Provider vertrauliche Patienten-Informationen einsehbar wären. Die Vorhaltung redundanter Zugangsdaten bei verschiedenen Providern ist zu vermeiden. Jeder Nutzer und jede Gruppe kann sich gegenüber einem 6 Letzte Speicherung des Dokuments: :42:00

174 Management Summary fest zugeordneten Dienst bzw. Portal authentisieren (Single Point of Access), über den auch alle benötigten Identitätsdaten verfügbar sind. Authentisierungs- und Identitätsnachweise werden ggf. mit expliziter Verifizierung und nach Übertragung in einen anderen Sicherheitskontext von allen Diensten der efa-anwendung akzeptiert (Single Sign-On). Die Authentisierung erfolgt im Idealfall synchron zu der Granularität der Berechtigungen, d. h. wenn eine Gruppe zum Datenzugriff berechtigt wurde, ist anzustreben, dass nicht primär ein Individuum sondern die entsprechende Gruppenmitgliedschaft authentisiert wird. Sofern einzelne geforderte Schutzniveaus mit den Maßnahmen des Sicherheits- und Datenschutzkonzepts nicht umsetzbar sind, werden Nutzungseinschränkungen und andere organisatorische Maßnahmen festgelegt, um die das technologisch nicht erzielbare Schutzniveau bedingenden Anwendungsfälle geeignet einzuschränken. Hierdurch wird sichergestellt, dass die Sicherheitsinfrastruktur der efa von überschaubarer Komplexität ist und damit einfacher auf existierende, verifizierte Konzepte und Produkte abgebildet werden kann. Sicherheitskonzept_v100 7

175 2 Einleitung Die Einführung der elektronischen Gesundheitskarte stellt insbesondere die Krankenhäuser vor große Herausforderungen. Die priorisierten Anwendungen erezept und Versichertenstatus adressieren nur marginal den für Krankenhäuser besonders wichtigen sektorübergreifenden Datenaustausch, gleichzeitig ist die Umstellung der IT-Systeme mit großen Aufwänden verbunden. Die privaten Klinikketten asklepios Kliniken Verwaltungsgesellschaft mbh, Rhön-Klinikum AG und Sana GmbH & Co. KGaA haben daher beschlossen, ihre aktuellen Aktivitäten zur Errichtung von Ärzteportalen zu bündeln und in ein gemeinsames Projekt mit der Deutschen Krankenhausgesellschaft e. V. und dem Fraunhofer-Institut für Software- und Systemtechnik ISST einzubringen. Das Projekt wird durch einen Beirat aus Vertretern öffentlicher und kirchlicher Krankenhausträger begleitet und soll die Arbeiten der gematik ergänzen. Ziel ist es, Synergieeffekte zu nutzen und die unabhängig von der Gesundheitskarte notwendigen Investitionen in elektronische Patientenakten abzusichern. Gegenstand der auch für weitere Partner offenen Initiative ist die Spezifikation einer interoperablen Architektur, mit der bei Krankenhäusern vorgehaltene Patientendaten über verschiedene Zugangswege unter Beachtung des Datenschutzes im Kontext sektorübergreifender Behandlungsszenarien nutzbar gemacht werden können. Dadurch werden die existierenden dezentralen Strukturen der Verwaltung medizinischer Daten beibehalten und es können Mehrfachspeicherungen von Daten für verschiedene Zugangswege auf das notwendige Mindestmaß beschränkt werden. Neben einem auf den Spezifikationen der Gesundheitskarte basierenden Zugang für Patienten und Ärzte können Daten eines Behandlungsfalls zu einer Fallakte zusammengefasst werden, die den mit der Behandlung befassten Medizinern einen sektor- und einrichtungsübergreifenden Datenaustausch ermöglicht. Einsatzszenarien für Fallakten sind neben Einweisungen insbesondere Disease Management Programme und die zunehmend an Bedeutung gewinnende integrierte Versorgung. 2.1 Einordnung in den Projektkontext Datenschutz und Datensicherheit besitzen eine herausgehobene Bedeutung für die Umsetzung von Anwendungen zum Austausch und zur Nutzung personenbezogener medizinischer Daten. Die konsequente Berücksichtigung von Datenschutz und Datensicherheit ist entscheidend für die Akzeptanz von elektronischen Patienten- und Fallakten bei Patienten und Ärzten. Von allen 8 Letzte Speicherung des Dokuments: :42:00

176 Einleitung Akteuren akzeptierte Anwendungen zum einrichtungsübergreifenden Datenaustausch wiederum sind geeignet, existierende Schwachstellen in der Kommunikation zwischen ambulanter und stationärer Behandlung zum Vorteil von Ärzten und Patienten zu beseitigen, wodurch auch den Anbietern dieser Anwendungen erhebliche Wettbewerbsvorteile in Bezug auf die Bindung von Patienten und Zuweisern entstehen. Durch Nicht-Beachtung der Anforderungen an Datenschutz und Sicherheit entstehende Risiken betreffen analog nicht nur den Patienten, sondern auch die Anbieter von Patienten- und Fallakten, die mit ihrem Ruf und ihrem Vermögen für eine Einhaltung der geltenden gesetzlichen Bestimmungen haften. In diesem Dokument wird das Sicherheits- und Datenschutzkonzept beschrieben, auf dem Sicherheits- und Anwendungsarchitektur elektronischer Fallakten basieren. Hierzu werden zunächst die Schutzbedarfe analysiert und die objektbezogenen Sicherheitsanforderungen erhoben. Daraus abgeleitete Maßnahmen bilden das Sicherheits- und Datenschutzkonzept. Die Umsetzung der Maßnahmen ist Gegenstand der Sicherheitsinfrastruktur. Analog zu den Konzepten der FuE-Lösungarchitektur [FuE_SLA-1.0], der bit4health Rahmenarchitektur [b4h_überblick-1.1] und dem aktuellen Diskussionsstand in der gematik 1 werden Sicherheitskonzepte und -dienste auf zwei Ebenen, der Anwendungsebene und der Kommunikationsebene, angesiedelt. Die auf Anwendungsebene sichtbaren bzw. genutzten Sicherheitsdienste, -mechanismen und -objekte werden auf abstrakter Ebene realisierungsunabhängig und über ihre Funktionalitäten und Abläufe in dem Dokument Sicherheitsarchitektur beschreiben. Die Sicherheitsmechanismen der Kommunikationsebene dienen dem Aufbau authentisierter und sicherer Kommunikationskanäle zwischen Komponenten, wobei weitgehend von konkreten Transportprotokollen abstrahiert wird. Die so aufgespannte sichere Kommunikationsinfrastruktur und deren Bindings für SOAP (inklusive der Spezifikationen für die Nutzung von Web Services und WS Trust) sind in dem Dokument "Kommunikationsinfrastruktur und Deployment" beschrieben. In Abbildung 1 sind die einzelnen Dokumente zum Thema Sicherheit und Datenschutz im Kontext der Projektergebnisse dargestellt. 1 Berücksichtigt wurden die bis zum 15. Mai auf veröffentlichten Dokumente zur Architektur sowie die Protokolle des Architekturboards des BMG. Sicherheitskonzept_v100 9

177 Abbildung 1: Dokumentenübersicht Übersicht über die Projektergebnisse Fachlogik Systemgrenzen und Szenarien Formate, Dokumente und Dokumententypen Abläufe (Use Cases) Sicherheit und Datenschutz Sicherheitskonzept Sicherheitsarchitektur Implementierungsvorgaben Technik Anwendungsarchitektur Implementierungsvorgaben Kommunikationsinfrastruktur und Deployment Implementierungsvorgaben efa-client Datentypen und Nachrichtenformate 2.2 Vorgehensmodell Das Sicherheitskonzept ist neben den Ergebnissen der fachlogischen Analyse der wesentliche Anforderungsgeber für die Spezifikation der Anwendungsarchitektur und deren Umsetzung. Bei der Ausarbeitung der Anwendung elektronische Fallakte wird die Philosophie verfolgt, dass aufgrund der herausragenden Bedeutung der Themen Sicherheit und Datenschutz zunächst eine Sicherheitsstrategie mit grundlegenden, von der konkreten Lösung abstrahierenden Konzepten entwickelt werden muss. Diese Konzepte bilden dann die Basis der auszuarbeitenden Lösung bzw. sind von dieser zu berücksichtigen und zu integrieren. In der nachfolgenden Abbildung ist das diese Philosophie verfolgende Vorgehensmodell dargestellt: Schutzbedarfsanalyse, Sicherheitskonzepte ( Strategie ) und Sicherheitsmaßnahmen bilden den Ausgangspunkt für die Spezifikation der Anwendungen und geben Anforderungen für die Umsetzung und den Betrieb der spezifizierten Lösung vor. Die grau hinterlegten Elemente des Vorgehens heben die in diesem Dokument beschriebenen Ergebnisse der Sicherheitsanalyse hervor. 10 Letzte Speicherung des Dokuments: :42:00

178 Einleitung Abbildung 2: Einordnung der Sicherheitsanalyse in das Vorgehensmodell Fachlogische Analyse Szenarien, Prozesse und Objekte Sicherheitsanalyse Rechtsgrundlagen und Rahmenbedingungen Nichtfunktionale Anforderungen Funktionale Anforderungen Konzeptionelles Modell Schutzbedarfe Sicherheitskonzepte Sicherheitsmaßnahmen Design Sicherheitsarchitektur Anwendungsarchitektur Kommunikationsarchitektur Konsolidierung Schutzmaßnahmen für konkrete Dienste und Daten Umsetzung und Betrieb Das in diesem Dokument dargestellte Sicherheits- und Datenschutzkonzept und die dieses unterstützende Sicherheitsarchitektur wurden in einem weitgehend Top-Down-ausgerichteten Vorgehen entwickelt. Bottom-Up- Verfahren wurden lediglich dort eingesetzt, wo durch die Arbeiten der gematik und des Bundesministeriums für Gesundheit (BMG) im Kontext der elektronischen Gesundheitskarte konkrete Spezifikationen von Sicherheitsobjekten (z. B. Chipkarten) bzw. Empfehlungen zu Sicherheitsmechanismen als gesetzt angesehen wurden. Das Sicherheits- und das Datenschutzkonzept greift auf etablierte Architekturmodelle und Sicherheitskonzepte zurück. Dazu gehören insbesondere die Sicherheitsarchitektur nach ISO [ISO7498-2], die BSI IT-Grundschutzkataloge [BSI_GSK], die BSI Standards 100-1, und [BSI_100-1, BSI_100-2, BSI_100-3] sowie das E-Government-Handbuch [BSI_eGovernment-06]. Zur Ableitung und Umsetzung des Sicherheitskonzepts wurde ein fünfstufiges Vorgehen gewählt: Festlegung der Schutzbedarfe für die Objekte des konzeptionellen Modells und die Beziehungen zwischen diesen Objekten Bildung von Clustern aus Schutzzielen und zu schützenden Objekten zur Ausarbeitung einer ganzheitlichen Sicherheitsstrategie Sicherheitskonzept_v100 11

179 Festlegung von (technischen) Schutzkonzepten für die zu schützenden Objekte und Objektbeziehungen auf Basis der Sicherheitsstrategie Spezifikation von Sicherheitsdiensten, Sicherheitsmechanismen und Sicherheitsobjekten zur Realisierung der Schutzkonzepte Integration der Sicherheitsdienste in eine von der Anwendungsarchitektur weitgehend unabhängige Sicherheitsinfrastruktur und Spezifikation der Einbindung der Sicherheitsdienste in die fachlichen Abläufe 2.3 Gliederung des Dokuments In der nachfolgenden Grafik ist die Gliederung dieses Dokuments einschließlich der Querbeziehungen zwischen den einzelnen Kapiteln dargestellt. Der Aufbau des Dokuments orientiert sich dabei an dem oben skizzierten Vorgehensmodell. Abbildung 3: Gliederung des Dokuments Kapitel 3: Grundlagen Anforderungen Rechtsgrundlagen Anforderungen an efa und epa Projektspez. Anforderungen Rechtssicherheit Methodische Basis Schutzziele Schutzbedarfe Bedrohungen Konzeptionelles Modell Kapitel 4: Schutzbedarfsanalyse Kapitel 5: Sicherheitsanforderungen und Umsetzungsvorgaben Kapitel 6: Sicherheitskonzept (Grobdesign) Sicherheitsanalyse Schutzbedarfsanalyse Objektbezogene Sicherheitsvorgaben Sicherheits strategie und Sicherheitskonzept Organisatorische Konzepte Architektur-Konzepte Technische Konzepte Sicherheitsarchitektur Das in diesem Dokument beschriebene Sicherheits- und Datenschutzkonzept ebenso wie die darauf basierende Sicherheitsarchitektur spiegeln den aktuellen Stand der Technik wider und berücksichtigen die Erfahrungen, die mit der Entwicklung vergleichbarer Konzepte und Lösungen gemacht wurden. Neue Technologien, neue Bedrohungen und insbesondere die bei der praktischen Umsetzung der in diesem Dokument beschriebenen Konzepte gemachten Erfahrungen bedingen eine kontinuierliche Fortschreibung des Sicherheits- und Datenschutzkonzepts elektronischer Fallakten. Dies betrifft insbesondere die in 12 Letzte Speicherung des Dokuments: :42:00

180 Einleitung den Kapiteln 5 und 6 benannten Maßnahmen, die im Fall neuer Bedrohungen oder Schutzrisiken so anzupassen sind, dass die in Kapitel 4 festgelegten Schutzbedarfe durchgängig sichergestellt werden können. Sicherheitskonzept_v100 13

181 3 Grundlagen des Sicherheitskonzepts Die Grundlagen des in diesem Dokument beschriebenen Sicherheitskonzepts von elektronischen Fallakten lassen sich am einfachsten durch drei vorab zu klärende Fragen umreißen: Für welche Objekte und Abläufe d. h. für welches konzeptionelle bzw. fachlogische Anwendungsmodell müssen Sicherheitsanforderungen analysiert und Lösungskonzepte zur Realisierung des notwendigen Sicherheitsniveaus entwickelt werden? Welche Blickwinkel sind für die Analyse der Sicherheitsanforderungen einzunehmen? Welche übergeordneten rechtlichen, fachlichen und projektbezogenen Anforderungen bilden den Kontext von Analyse und Design? Die Beantwortung dieser Fragen nach den sicherheitsrelevanten Anforderungen, dem zugrunde zu legenden konzeptionellen Anwendungsmodell und den Betrachtungsgegenständen (Blickwinkeln) ist Ziel dieses Kapitels (siehe Abbildung 4). 14 Letzte Speicherung des Dokuments: :42:00

182 Grundlagen des Sicherheitskonzepts Abbildung 4: Grundlagen des Sicherheitskonzepts Anforderungen Rechtsgrundlagen Anforderungen an efa und epa Projektspez. Anforderungen Rechtssicherheit Betrachtungsgegenstände Schutzziele Schutzbedarfe Bedrohungen Konzeptionelles Modell Sicherheitsanalyse Schutzbedarfsanalyse Objektbezogene Sicherheitsvorgaben Sicherheits strategie und Sicherheitskonzept Organisatorische Konzepte Architektur-Konzepte Technische Konzepte Sicherheitsarchitektur In Abschnitt 3.1 wird zunächst auf die rechtlichen Anforderungen an Fall- und Patientenakten eingegangen. Hierbei soll bewusst lediglich ein grober Überblick gegeben werden, mit dem vor allem die Ergebnisse anderer Projekte (insbesondere bit4health und FuE) zusammengefasst werden. Spezifische Anforderungen, die sich aus dem Projekt Elektronische Fallakte und seiner Fokussierung auf die Erfordernisse einer sektorübergreifenden Kommunikation unter besonderer Berücksichtigung der existierenden Anwendungslandschaften in Krankenhäusern ergeben, sind Gegenstand von Abschnitt 3.2. Auch dieser Abschnitt hat einen stark zusammenfassenden Charakter und beschränkt sich auf die Anforderungen, die für die Analyse und die Entwicklung des Sicherheitskonzepts der elektronischen Fallakte relevant sind. Ausführlichere Informationen hierzu sind insbesondere in den Dokumenten zur fachlogischen Analyse enthalten [efa_prozesse-1.0, efa_szenarien-1.4]. Fachliche Grundlage der Analyse von Schutzbedarfen sowie der Festlegung objektbezogener Sicherheitsanforderungen und Umsetzungsvorgaben ist das konzeptionelle (fachlogische) Modell der Anwendung elektronische Fallakte. Dieses Modell wird in Abschnitt 3.3 dargestellt. Sicherheitskonzept_v100 15

183 Die restlichen Abschnitte dieses Kapitels beschreiben die Blickwinkel der Sicherheitsanalyse und damit die Grundkonzepte des Vorgehensmodells. Insbesondere werden die im Rahmen der Analyse verwendeten Klassifizierungen und Kategorisierungen dargestellt und motiviert. 3.1 Rechtliche Anforderungen In den nachfolgenden Absätzen sind die wesentlichen Rechtsgrundlagen für die Realisierung elektronischer Patienten- und Fallakten zusammengefasst. Ausführlichere Darstellungen zur elektronischen Patientenakte, in denen auch die Relevanz einzelner Gesetze bewertet wird, finden sich in [FuE_SLA-1.0] und [b4h_secanf-1.1]. Das allgemeine Persönlichkeitsrecht, das auch das Recht auf informationelle Selbstbestimmung umfasst, ergibt sich bereits aus Art. 1 (Menschenwürde, Menschenrechte) und Art 2 (Persönliche Freiheitsrechte) des Grundgesetzes. Dieses abgeleitete Recht auf informationelle Selbstbestimmung impliziert, dass jeder Bürger grundsätzlich selbst darüber entscheiden kann, ob, in welchem Umfang und in welcher Weise er personenbezogene Daten preisgibt. Für die elektronische Patientenakte und die elektronische Fallakte bedeutet das: der Patient bestimmt selbst über die Weitergabe von Krankenakten. Detailliertere Bestimmungen für die Erhebung, Verarbeitung und Nutzung personenbezogener Daten gibt das Bundesdatenschutzgesetz (insb. 3a, 9 BDSG) vor. Wesentliche Kriterien, die hier an die Bewertung von IT- Systemen angelegt werden, sind die Zweckbindung, das Gebot der Datensparsamkeit, die Vermeidung von Datenspuren und Beschränkungen hinsichtlich der Verknüpfung zentraler Datenbestände. Das Sozialgesetzbuch V (SGB V) regelt im 291a die Nutzung der elektronischen Gesundheitskarte im Rahmen freiwilliger Anwendungen wie z. B. der elektronischen Patientenakte. Wesentliche Vorgaben betreffen die freiwillige Einwilligung des Patienten sowohl zur Nutzung der Anwendung an sich als auch die Autorisierung der einzelnen Datenzugriffe. Der 291 a legt darüber hinaus auch fest, das durch das Verwaltungsvereinfachungsgesetz mögliche Berechtigungsweitergaben an Hilfspersonal oder Vertreter bei Einhaltung bestimmter Protokollierungsvorgaben zugelassen sind. In der Strafprozessordnung (SPO) sind die ärztliche Schweigepflicht bezüglich des Patientengeheimnisses sowie der Beschlagnahmeschutz der Patientendaten verankert. Eine im 30 Gesundheitsmodernisierungsgesetz (GMG) erfolgte Erweiterung des 97 SPO nimmt dabei auch explizit Bezug auf die elektronische Patientenakte nach 291a SGB V. Wichtig für die elektronische Fallakte als nicht aus dem 291a abgeleitete Anwendung ist 16 Letzte Speicherung des Dokuments: :42:00

184 Grundlagen des Sicherheitskonzepts dabei, dass der Beschlagnahmeschutz nur greift, wenn die Daten entweder bei einer Klinik liegen oder im Besitz eines Arztes sind. Neben diesen bundeseinheitlich geltenden Regelungen sind insbesondere für die Krankenhäuser als Anbieter und Nutzer von Patienten- und Fallakten auch länderspezifische Regelungen relevant. Hier sind insbesondere die jeweiligen Landesdatenschutzgesetze und Landeskrankenhausrechte zu nennen. Allen diesen Regelungen muss bei der Spezifizierung der elektronischen Patientenakte und einer auf denselben Datenbeständen aufbauenden elektronischen Fallakte Folge geleistet werden, um auf den Spezifikationen basierende Produkte im Regelbetrieb nutzen zu können. Hierbei ist jedoch zu berücksichtigen, dass eine efa keine Primärdokumentation darstellt. Zweck einer efa sind Kooperation und Kommunikation und nicht die Dokumentation. D. h. jeder behandelnde Arzt ist gesetzlich verpflichtet, unabhängig von efa und epa seine eigene Behandlungsdokumentation zu führen Vorgaben, die eine elektronische Patientenakte nach 291a betreffen Die wesentlichen datenschutzrechtlichen Vorgaben zur Nutzung von auf der elektronischen Gesundheitskarte und dem 291a SGB V basierenden Anwendungen sind im Tätigkeitsbericht des Bundesbeauftragten für den Datenschutz vom zusammengefasst: Die Datenhoheit der Patienten und der Grundsatz der Freiwilligkeit der Speicherung von Gesundheitsdaten müssen gewahrt werden. Die Patienten müssen darüber entscheiden können, welche ihrer Gesundheitsdaten aufgenommen und welche gelöscht werden. Die Patienten müssen darüber entscheiden können, ob und welche Daten sie einem Leistungserbringer zugänglich machen. Die Patienten müssen die Möglichkeit haben, die über sie gespeicherten Daten zu lesen Vorgaben, die eine elektronische Fallakte betreffen Die elektronische Fallakte (efa) wird zur Unterstützung von Behandlungsprozessen eingesetzt, an denen verschiedene Einrichtungen und/oder Ärzte beteiligt sind. Sie ist kein Ersatz für die von den Leistungsbringern in ihren lokalen Systemen verpflichtend zu führenden medizinischen Behandlungsdokumentationen. Der elektronischen Fallakte liegt immer ein hinreichend abgrenzbares Krankheitsbild bzw. eine Eingangsdiagnose zugrunde. Die Nutzung ist eingegrenzt auf mit dieser Indikation in Zusammenhang stehende ärztliche und Sicherheitskonzept_v100 17

185 pflegerische Leistungen und damit zweckgebunden. Mit Abschluss der Behandlung wird die efa geschlossen und dem externen Zugang entzogen 2. Aufgrund der Zweckbindung, der inhaltlich und zeitlich eingrenzbaren Nutzung und des erst durch die strukturierte Datenzusammenführung entstehenden Nutzwerts wird die elektronische Fallakte datenschutzrechtlich als eine Datei behandelt [Weichert_DuD-04]. Die rechtliche Stellung der efa als eine Datei hat eine Reihe von Konsequenzen für ihre Nutzung: Für die Nutzung der efa ist eine Einwilligung des Patienten erforderlich, mit der auch die Zugriffsberechtigten autorisiert werden. Die Autorisierung betrifft jedoch immer die efa als Ganzes, d. h. der Patient erteilt eine Einwilligung in der Form, dass alle als zugriffsberechtigt charakterisierten Personen auf alle in die efa eingestellten Daten zugreifen dürfen. Differenziert wird bei den Zugriffsrechten für unterschiedliche Personen oder Gruppen ggf. lediglich hinsichtlich der grundsätzlichen Art (lesend/schreibend) und möglicherweise hinsichtlich der Umstände (z. B. Notfall) des Zugriffs. Der Patient kann die Einwilligung zur efa-nutzung und zur Erteilung des Zugriffs für Personen oder Gruppen jederzeit widerrufen. Auch der Widerruf gilt immer nur für die gesamte efa, d. h. ein Ausschluss des Zugriffsrechts auf einzelne Dokumente (nur) für bestimmte Personen ist nicht möglich. Dies würde eine Änderung des Behandlungsvertrags und damit ggf. das Aufsetzen einer neuen efa erfordern 3. Die Entscheidung, welche Dokumente in die efa eingestellt werden, liegt bei den behandelnden Ärzten 4. Diese Anforderung leitet sich aus dem Charakter der efa als Sicht auf eine verteilt vorgehaltene medizinische Behandlungsdokumentation ab. 2 Das Schließen einer efa erfolgt dann, wenn der Patient seine Einwilligung zur Nutzung zurücknimmt, verstirbt oder gemeinsam mit den behandelten Ärzten der Abschluss der Behandlung festgestellt wird [efa_prozesse-1.0], d. h. für eine weitere Nutzung der efa aus Sicht aller Beteiligten keine medizinische Notwendigkeit mehr besteht. 3 Von diesem Grundsatz abweichende Regelungen können individuell zwischen Patient und behandelnden Ärzten getroffen werden. Es ist z. B. denkbar, dass ein Arzt nur in eine Behandlungsphase eingebunden ist und anschließend auch keinen Zugang zu der efa mehr hat. Prinzipiell gilt jedoch, dass die Synchronität von Behandlungsvertrag als schriftlicher Einwilligung des Patienten und auf der zugehörigen efa verankerten Zugriffsrechten gewahrt bleiben muss. 4 Hierbei sind in den jeweiligen Fachgebieten anerkannte Vorgaben und Empfehlungen zu Dokumentationsinhalten sowie strukturelle Vorgaben der efa-nutzung [efa_dokumente-1.0] zu berücksichtigen. 18 Letzte Speicherung des Dokuments: :42:00

186 Grundlagen des Sicherheitskonzepts Das Auskunftsrecht des Patienten bleibt hiervon unberührt, d. h. auch bei Umsetzung einer elektronischen Fallakte muss der Patient durch technische und/oder organisatorische Maßnahmen in die Lage versetzt werden, die über ihn gespeicherten Daten einzusehen. Auch das Recht des Patienten, eine Auflösung der efa zu verlangen, bleibt erhalten, sofern es nicht die Dokumentationspflicht der behandelnden Ärzte betrifft. Ein Auflösen betrifft jedoch immer die gesamte Akte und ist nicht auf die Ausklammerung einzelner Dokumente der Akte begrenzbar Rechtssicherheit Rechtssicherheit im Umgang mit elektronischen Medien hat unterschiedliche Facetten und Auswirkungen. Im Speziellen sind die folgenden Aspekte gemeint: 1 Nicht-Abstreitbarkeit Es muss sichergestellt werden, dass eine Person nicht leugnen kann, eine rechtsverbindliche Transaktion ausgeführt zu haben. 2 Revisionssicherheit Es muss sichergestellt werden, dass jeder Zustand, der in den Systemen geherrscht hat, exakt nachvollzogen werden kann. Dies wird insbesondere dann wichtig, wenn Entscheidungen auf Basis von zu einem Zeitpunkt verfügbaren Informationen getroffen werden müssen bzw. worden sind. 3 Unveränderbarkeit Es muss sichergestellt werden, dass rechtsverbindliche Dokumente oder Unterlagen weder vom Erzeuger noch von anderen Personen unbemerkt verändert werden können.. Diese Anforderungen kollidieren zum Teil mit den Anforderungen des Datenschutzes nach Datensparsamkeit, da zumindest die Fälle 1 und 2 eine Protokollierung oder andere Mechanismen zur Rückverfolgung von Operationen auf einer efa verlangen Rechtssicherheit für den Arzt Für den Arzt spielt die Rechtssicherheit eine große Rolle, da er die größte Verantwortung trägt. Dabei kann die Einführung von elektronischen Medien dazu führen, dass sogar höhere Anforderungen als bisher gestellt werden. 5 Auch hier können individuell zwischen Patient und behandelnden Ärzten abweichende Regelungen vereinbart werden, die z. B. ein Recht des Patienten beinhalten, für einzelne Dokumente eine Herausnahme aus der efa oder eine verschlüsselte Speicherung zu verlangen. Sicherheitskonzept_v100 19

187 Wenn der Arzt eine elektronische Akte nutzt, will er sicher sein können, dass die entsprechenden Einträge korrekt und vollständig sind. Dies ist nicht gegeben, wenn der Patient dem Arzt nur Teile der entsprechenden Dokumente zur Verfügung stellt oder wie bei im 291a für die epa verlangt einzelne Dokumente ausblenden kann. Die Korrektheit der einzelnen Einträge kann über eine Signatur durch einen Leistungserbringer gesichert werden allerdings bleibt dabei die Restunsicherheit in Bezug auf entwendete oder missbräuchlich verwendete Zugangsdaten. Hier erscheint es sinnvoll, den Arzt explizit von erweiterten Prüfpflichten zu entbinden. Nicht nur technologische, sondern vor allem auch juristische Klärungsbedarfe betreffen auch das Verbergen von Teilen der elektronischen Patientenakte für einzelne Mediziner. Wenn hier auf Grund fehlender Informationen eine Fehlentscheidung getroffen wird, so muss im Streitfall für den Arzt sicher nachzuweisen sein, welche Dokumente für ihn zu einem bestimmten Zeitpunkt zugreifbar waren. Dies lässt sich nur erreichen, wenn alle Änderungen an den Zugriffsrechten in der Patientenakte und alle Veränderungen der Patientenakte zeitgenau protokolliert werden. Auch wenn die elektronische Fallakte als arztgeführte Akte kein Ausblenden von Daten durch den Patienten vorsieht, so entsteht durch die mit dem zugrunde liegenden kooperativen Nutzungsszenario verbundene Dynamik die Anforderung der Revisionssicherheit. D. h. es muss (auch nach dem Schließen einer efa) für jeden Zeitpunkt des Lebenszyklus der efa rekonstruierbar sein, welche Dokumente Bestandteil der efa waren welche Dokumente für einen Arzt technisch verfügbar waren welche Dokumente über welche Metadaten klassifiziert wurden und welche Auswirkungen diese Klassifizierung auf die Bildung von Sichten und die Anwendung von (Such-)Filtern hatte Rechtssicherheit für den Patienten Der Versicherte muss sicher sein können, dass kein Arzt und auch kein System nachträglich Tatsachendarstellungen verändern kann. Für ihn spielt die Revisionssicherheit eine sehr große Rolle. Wenn er in seiner epa zu einem Zeitpunkt ein Dokument verborgen hat, muss nicht nur sichergestellt werden, dass dies auch tatsächlich nicht sichtbar war, sondern er muss auch nachweisen können, dass er dies verborgen hatte. Entsprechendes gilt für die Einräumung und Rücknahme von Zugriffsrechten. Wesentlich aus Sicht des Patienten ist auch die Führung eines sicheren Nachweises, dass ein Dokument zu einem bestimmten Zeitpunkt bereitgestellt 20 Letzte Speicherung des Dokuments: :42:00

188 Grundlagen des Sicherheitskonzepts wurde und die darin enthaltenen Informationen den behandelnden Ärzten hätten bekannt sein können. Eine Protokollierung dieser Aktionen auf der Karte reicht nicht aus, da die Karte gemäß aktueller egk-spezifikation lediglich Trägermedium des Protokolls ist, während das ob? und was? der Protokollierung von einem externen System mit Schreibrecht auf der Karte entscheiden wird. Da eine Manipulation dieses externen Systems nicht ausgeschlossen werden kann und die Karte weder Authenzität noch Integrität der Protokolleinträge prüfen kann, ist eine alleinige Protokollierung auf der Karte unzureichend und potenziell im Rechtsfall wenig belastbar. Auch führt die unvermeidbare statische Begrenzung der Protokollgröße auf der Karte zu»legaler«löschung von Protokolleinträgen. 3.2 Anwendungsübergreifende, projektspezifische Anforderungen Neben den gesetzlichen Grundlagen sind bei der Erstellung eines Sicherheitsund Datenschutzkonzepts sowie der Spezifikation von Sicherheitsdiensten auch weitere sich aus der Praxis (z. B. in den am Projekt beteiligten Kliniken) ergebende Anforderungen zu berücksichtigen. Diese Anforderungen resultieren aus den analysierten fachlogischen Abläufen des Umgangs von Ärzten und Patienten mit Fallakten und berücksichtigen Spezifika der einzelnen Sektoren: Es ist zu berücksichtigen, dass insbesondere in Krankenhäusern nicht alle Mitarbeiter mit Heilberufsausweisen ausgestattet sind. Krankenhausträger können in Ergänzung zum Heilberufsausweis eigene Mitarbeiterausweise herausgeben. Diese können ein entsprechendes Schutzniveau vorausgesetzt zur Authentisierung von Ärzten und Hilfspersonal gegenüber den eine Fallakte verwaltenden Diensten genutzt werden. Die Erteilung von Berechtigungen ausschließlich auf der Granularitätsstufe natürlicher Personen ist für die Behandlung im Krankenhaus weder praktikabel noch zielführend. Das Berechtigungskonzept muss daher ermöglichen, dass ein Patient auch Gruppen von Personen (z. B. alle ihn behandelnden Ärzte eines Krankenhauses) zum Datenzugriff ermächtigen kann. Inwieweit dabei Granularitätsstufen unterhalb der Gruppe behandelne Ärzte einer Einrichtung unterstützt werden, muss jedes Krankenhaus über das Konstrukt des Behandlungsvertrags mit dem Patienten individuell festlegen können. Eine Protokollierung von Datenzugriffen erfolgt ausschließlich zu Zwecken der Datenschutzkontrolle. Es dürfen keine zentralen Sammlungen von Zugriffsprotokollen entstehen, aus denen sich Bewegungsprofile von Patienten und/oder Ärzten bzw. Arbeitsnachweise für Ärzte ableiten lassen. Die zu Akten zusammengefassten Daten dienen ausschließlich der Unterstützung kooperativer Behandlungsszenarien. Eine Nutzbarmachung von elektronischen Patienten- oder Fallakten für statistische Zwecke oder Sicherheitskonzept_v100 21

189 für wissenschaftliche Auswertungen ist keine Anforderung an die spezifizierte Lösung. 3.3 Konzeptionelles Modell Die Schutzbedarfsfeststellung orientiert sich an den über IT-Systeme verarbeiteten bzw. verwalteten Objekten und den auf diese Objekte zugreifenden Diensten. Nachfolgend sind die einzelnen zu schützenden Objektklassen beschrieben. Die Schutzziele für die einzelnen Instanzen dieser Objektklassen sind in Kapitel 2.4 aufgeführt. Personenbezogene medizinische Dokumente bilden die Datenbasis der efa- und der epa-anwendung. Da es das Ziel des Projekts ist, eine mehrfache Datenhaltung zu vermeiden (efa, epa, krankenhaus-interne Portale), muss der Schutzbedarf unabhängig vom Zugangsweg analysiert werden. Es sind hierbei jeweils die Maximalanforderungen des Schutzbedarfs über die einzelnen Zugänge (efa, epa) anzulegen. Dies sind im Zweifelsfall die Vorgaben des 291a SGB V an die Speicherung und Nutzung medizinischer Daten im Kontext der freiwilligen Anwendungen. Zusammenstellung als elektronische Patientenakte (epa) 6 : Medizinische Dokumente können in einer patientengeführten Akte zusammengefasst werden. Bei der Analyse der Schutzziele sind sowohl der Schutzbedarf der Aktenstruktur und der Zuordnung von Daten zu Akten als auch ggf. existierende Personenzuordnungen zu betrachten. In Bezug auf den Datenzugang ist die Einhaltung der Schutzziele der Daten sicherzustellen. Basis der Schutzbedarfsfeststellung ist die vom BMG vorgenommene Risikoanalyse zur Lösungsarchitektur des FuE-Projekts zur elektronischen Gesundheitskarte [BMG_RA-1.1]. Zusammenstellung als elektronische Fallakte (efa): Medizinische Dokumente können in einer von den behandelnden Ärzten geführten elektronischen Fallakte zusammengefasst werden. Bei der Analyse der Schutzziele ist der Schutzbedarf sowohl der Ordnerstruktur und der Zuordnung von Daten zu einer Fallakte als auch der Metadaten der Akte zu betrachten. In Bezug auf den Datenzugang ist die Einhaltung der Schutzziele der medizinischen Daten sicherzustellen. 6 Das Ziel des Projekts ist die Ausarbeitung einer elektronischen Fallakte. Für die Sicherheitsanalyse muss jedoch auch die elektronische Patientenakte betrachtet werden, da anzustreben ist, dass zukünftig beide Anwendung auf einer gemeinsamen Datenhaltung aufsetzen. 22 Letzte Speicherung des Dokuments: :42:00

190 Grundlagen des Sicherheitskonzepts Einwilligungen: Die Nutzung der Anwendungen efa bzw. epa erfordert die explizite Einwilligung des Patienten. Für die epa als freiwillige Anwendung nach 291a SGB V ist diese Einwilligung auf der egk des Patienten zu protokollieren. Die Einwilligung zum Aufsetzen und zur Nutzung einer efa wird vom Patienten schriftlich, z. B. im Rahmen des Behandlungsvertrags, erteilt. Der Patient kann eine Einwilligung zur Nutzung einer der Anwendungen jederzeit widerrufen. Rahmenbedingungen, funktionale Anforderungen und die Struktur elektronischer Fallakten bilden die Basis eines konzeptionellen Modells, in dem Aktenstruktur, Akteure und Berechtigungen mit ihren gegenseitigen Zusammenhängen und Abhängigkeiten zusammengefasst sind. In dem konzeptionellen Modell gibt es eine Reihe von Festlegungen zur Ausgestaltung von Fallakten im Rahmen der von der Fachlichkeit offen gelassenen Entscheidungsspielräume. Diese Spielräume betreffen nicht nur die Abwägung, inwieweit die efa als Prototyp für Mehrwertdienste der egk geeignet ist, sondern auch die konkrete Ausgestaltung des Berechtigungsmanagements. Im Einzelnen sind die folgenden Festlegungen getroffen worden: Berechtigungen können nur für eine Fallakte als Ganzes vergeben werden. Einziger nach außen sichtbarer Einstiegspunkt in eine efa ist die Wurzel der efa. Partitionen sind interne Einstiegspunkte, die ausschließlich zum automatisierten Einstellen von Daten durch ein KIS genutzt werden. Partitionen können durch Ordner weiter strukturiert werden. Eine Verteilung von Fallakten auf Systeme verschiedener Provider (Krankenhäuser) ist nur auf der Granularitätsstufe von Partitionen und Ordnern möglich. Partitionen, Ordner und Informationsobjekte erben die Berechtigungen der elektronischen Fallakte, der sie zugeordnet sind. Berechtigungen können sowohl an Personen als auch an Gruppen vergeben werden. Gruppen können als Unter- und Schnittmengen anderer Gruppen definiert werden. Berechtigungen (im inhaltlichen Sinne) sind Teil der Einwilligung des Patienten zur Anlage einer elektronischen Fallakte. Die Berechtigungen im formalen oder technischen Sinne leiten sich direkt daraus ab. Die Rücknahme der Einwilligung entzieht der darauf basierenden Fallakte die Existenzgrundlage, d. h. diese ist bei Rücknahme der Einwilligung des Patienten von ihrem Anbieter dem externen Zugriff zu entziehen und zu archivieren. Die nachfolgende Abbildung stellt das konzeptionelle Modell elektronischer Fallakten als UML-Klassendiagramm dar. Sicherheitskonzept_v100 23

191 Abbildung 5: Konzeptionelles Modell der elektronischen Fallakte (Objektmodell) Eine wesentliche Anforderung sowohl an efa als auch an epa ist, dass nur berechtigte Personen Zugang zu medizinischen Daten eines Patienten erlangen. Um dies sicherzustellen, werden Objekte benötigt, die diese Berechtigungen tragen und eine eindeutige Authentisierung bzw. Identifizierung von Personen und Objekten ermöglichen. Zugangsberechtigungen, Credentials, etc.: Zugangsberechtigungen können in Form von Credentials an Personen (z. B. Dr. Meier darf alle Röntgenbilder lesen ) oder in Form von ACLs und Zugangsregeln (z. B. Auf das Röntgenbild 1234 dürfen alle Radiologen des Krankenhaus Neukölln zugreifen ) an einzelne Datenobjekte (epa-zugang) bzw. elektronische Fallakten gebunden werden. Der Schutzbedarf von Berechtigungen auf Fallakten und Datenobjekten ist getrennt voneinander zu erheben, da Zugangsrechte immer an den genutzten Zugang (efa vs. epa) gebunden sind. Die Autorisierung eines Aktenzugriffs und die Autorisierung eines Objektzugriffs bilden nicht zwangsläufig zwei voneinander unabhängige Verteidigungslinien, da nicht immer beide Zugangswege zu einem Objekt definiert sind. Authentisierungstoken (Kryptografische Schlüssel etc.): Der Zugang zum abgeschlossenen Netz sowie der Zugriff auf Dienste und Daten erfordern eine 24 Letzte Speicherung des Dokuments: :42:00

192 Grundlagen des Sicherheitskonzepts Authentisierung des zugreifenden Dienstes bzw. Nutzers (Arztes). Bei der Feststellung des Schutzbedarfs von zur Authentisierung genutzten Merkmalen und Schlüsseln sind insbesondere auch die Auswirkungen von Schutzverletzungen auf den Schutz der anderen Objekte (insbesondere medizinische Daten und deren Zugangsberechtigungen) zu untersuchen. Identitätsdaten und Privilegien drücken Identität, Rollenzugehörigkeit und Organisationszugehörigkeit eines Nutzers (Arzt oder Hilfspersonal) und die damit wahrnehmbaren Rechte aus. Identitätsdaten sind eng mit Authentisierungstoken verknüpft, sind jedoch in der Sicherheitsanalyse getrennt zu betrachten, da sie normalerweise getrennt von den Authentisierungstoken verwaltet und gepflegt werden. Patienten-Identifikatoren erlauben die systemweit eindeutige Identifizierung von Patienten. Sie können müssen jedoch nicht mit Authentisierungstoken gekoppelt sein. Da im Rahmen der efa als arztgeführter Akte Authentisierungen nur für Leistungserbringer erforderlich sind, werden in der Schutzbedarfsanalyse dem Patienten zugeordnete Token (z. B. eine egk) ausschließlich in ihrer Rolle als Identifizierungsmerkmal betrachtet. Objekt-Identifikatoren dienen der eindeutigen Identifikation von Objekten wie z. B. medizinischen Daten und Fallakten. Als zwangsläufig von außen sichtbarer Teil eines Objekts bilden Objekt- Identifikatoren einen Angriffspunkt sowohl für die jeweils dahinter stehenden Objekte als auch für die gesamte Infrastruktur. Schutzbedarf und Bedrohungen sind daher vorab zu definieren, um daraus Anforderungen an die Erzeugung, Verwendung und Verwaltung von Objekt-Identifikatoren ableiten zu können. 3.4 Schutzziele Für die Analyse von Bedrohungen sowie die Definition geeigneter Sicherheitsmaßnahmen werden für die zu schützenden Objekte die Schutzziele Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität und Nicht- Abstreitbarkeit betrachtet. Hierbei ist zu berücksichtigen, dass nicht nur die zu schützenden Objekte, sondern auch ihre Schutzziele miteinander in enger Beziehung stehen. Die Vertraulichkeit eines medizinischen Datenobjekts kann so z. B. dadurch gefährdet sein, dass die Integrität und/oder Authentizität der Zugangsberechtigungen zu diesem Objekt nicht sichergestellt ist. Das Schutzziel Vertraulichkeit zielt auf das Verhindern des unbefugten Lesens eines Objekts ab. Ein Verlust der Vertraulichkeit eines medizinischen Datenobjekts hätte so z. B. eine Verletzung der ärztlichen Schweigepflicht zur Sicherheitskonzept_v100 25

193 Folge, aber auch datenschutzrechtliche Bestimmungen wären betroffen und der Beschlagnahmeschutz der Patientendaten würde potenziell hinfällig. Im Kontext der elektronischen Gesundheitskarte werden in diversen Foren immer wieder auch Verletzungen der Vertraulichkeit von medizinischen Daten durch die erzwungene Datenfreigabe diskutiert, die z. B. im Rahmen von Bewerbungsgesprächen oder beim Abschluss von Versicherungen stattfindet. Diese Zugriffe sind letzten Endes nicht autorisiert, da die Einwilligung zur Datenfreigabe nicht wie vom Gesetz vorgeschrieben freiwillig erfolgt. Für die Anwendungen der elektronischen Gesundheitskarte sind hierzu Lösungen vorgeschlagen, die entweder präventiv greifen (z. B. Ausblenden von Daten) oder aber auf eine prinzipielle Verhinderung spontaner Einwilligungen abzielen (z. B. durch die Einführung von Patientenkiosken). Diese Missbrauchsszenarien sind für die im Mittelpunkt des Projekts stehende elektronische Fallakte zunächst nicht relevant, solange sich alle Zugriffsberechtigungen ausschließlich aus einem schriftlich fixierten Behandlungsvertrag ableiten, der nicht spontan verändert werden kann bzw. Erweiterungen von Berechtigungen ausschließlich vom Patienten ausgehen können. Die Anforderung nach Integrität hat das Ziel, unbefugte Änderungen der Inhalte, der zugehörigen Metainformationen (z. B. Diagnosecodes) und der Zusammenstellung von Daten zu verhindern. Eine Verletzung dieses Schutzziels hat Auswirkungen auf die Rechtssicherheit. Ist es beispielsweise möglich, die Dokumentation der Behandlung nachträglich zu manipulieren, können diese Daten nicht mehr als Beweis für ärztliches Fehlverhalten bzw. für die Richtigkeit der Behandlungsmethode herangezogen werden. Integritätsverletzungen können darüber hinaus Ursache von Fehlbehandlungen sein, die aufgrund von gefälschten Daten veranlasst werden. Grundsätzlich wird jedoch davon ausgegangen, dass die Entscheidung über die Sinnfälligkeit und den Nutzwert von Dokumenten in einer elektronischen Fallakte immer beim behandelnden Arzt liegt und diese Bewertung nicht zwangsläufig synchron zu dem Status der technisch verifizierten Datenintegrität sein muss. D. h. ein Arzt muss in der Lage sein, die Verwendung eines über technische Maßnahmen integritätsgesicherten Dokuments abzulehnen, wenn er aufgrund eigener Untersuchungen und Beobachtungen Zweifel an dessen medizinischer Richtigkeit und Plausibilität hat. Umgekehrt muss ein Arzt berechtigt sein, jedes in eine elektronische Fallakte eingestellte Dokument zu verwenden, wenn die Situation dies erfordert, die Dokumenteninhalte plausibel und konform zu eigenen Beobachtungen sind und keine Gefahr für Leben und Gesundheit des Patienten besteht. Dies gilt im Besonderen für vom Patienten selbst beigesteuerte Dokumente (z. B. Röntgenbilder, die sich in der Verwahrung des 26 Letzte Speicherung des Dokuments: :42:00

194 Grundlagen des Sicherheitskonzepts Patienten befanden), deren Authentizität zwar vom Patienten bestätigt werden kann, deren Integrität jedoch nur in seltenen Fällen verifizierbar ist. Verfügbarkeit umfasst den zum erforderlichen Zeitpunkt möglichen Zugriff auf Informationen entsprechend den vereinbarten Parametern wie Ausfallsicherheit und Performanz. Ist die Verfügbarkeit gestört, kann dies zum temporären Ausfall der Arbeitsfähigkeit eines Arztes führen und im Wiederholungsfall zu einem hohen Akzeptanzverlust von epa und efa bei Ärzten und Patienten kommen. Das Schutzziel der Authentizität betrifft die Verifizierbarkeit der für eine Aktivität oder ein Objekt verantwortlichen Person. Dokumente und Fallakten, die als nicht authentisch angesehen werden müssen (d. h. deren Urheber oder Bearbeiter unklar ist) sind als Grundlage für Behandlungen und Begutachtungen ungeeignet. Das Schutzziel Nicht-Abstreitbarkeit zielt darauf ab, dass weder das Einstellen eines Dokuments in eine Akte noch das Auslesen eines Dokuments aus einer Akte von der durchführenden Person abgestritten werden kann. Umgekehrt muss ein Arzt auch in die Lage versetzt werden können, zweifelsfrei nachzuweisen, dass er NICHT auf ein Dokument zugegriffen hat (z. B. bei Schadensersatzprozessen im Fall von Datenmissbräuchen). Analog zum Vorgehen im bit4health-projekt werden Authentizität und Nicht- Abstreitbarkeit im Folgenden zu dem Schutzziel Verbindlichkeit zusammengefasst. 3.5 Schutzbedarf und Bedrohungen Für jede Anwendung (einschließlich ihrer Daten) muss ein entsprechender Schutzbedarf festgestellt werden, um darauf aufbauend festzulegen, welcher Aufwand zum Schutz der Anwendungen betrieben werden muss. Dabei beziehen sich die Auswertungen auf alle oben benannten Schutzziele (Vertraulichkeit, Integrität, Verfügbarkeit und Verbindlichkeit). Die Festlegung von Schutzbedarfskategorien orientiert sich an den möglichen Schäden, die auftreten können, wenn Schutzziele von Anwendungen bzw. Daten nicht erreicht werden. Bei der Festlegung des Schutzbedarfs werden drei Kategorien unterschieden [BSI_100-2]: normal: Auswirkungen von Schutzverletzungen sind vorab quantifizierbar, eingrenzbar, bewegen sich in einer überschaubaren Größenordnung und sind für die Betroffenen hinnehmbar. hoch: Auswirkungen von Schutzverletzungen haben eine signifikante finanzielle Dimension (z. B. durch Schadensersatzklagen), sind jedoch vorab quantifizierbar, betreffen im Wesentlichen Einzelfälle oder sind kurzzeitig behebbar, haben keine negativen Auswirkungen auf soziale Sicherheitskonzept_v100 27

195 Stellung, Leben oder Gesundheit eines Patienten und bergen überschaubare Folgerisiken. sehr hoch: Auswirkungen von Schutzverletzungen bergen Risiken für soziale Stellung, Leben oder Gesundheit von Patienten, haben existenzgefährdende Auswirkungen für die Provider/Krankenhäuser, da sie neben signifikanten finanziellen Nachteilen (z. B. durch Schadensersatzklagen) auch die Existenz bedrohende Imageverluste zur Folge haben, in ihrer Dimension vorab schwer einschätzbar sind und/oder nicht absehbare Folgerisiken (z. B. weitere Schutzverletzungen) in sich bergen. 28 Letzte Speicherung des Dokuments: :42:00

196 Schutzbedarfsanalyse 4 Schutzbedarfsanalyse Nachfolgend werden die Schutzbedarfe in Bezug auf Schutzziele und zu schützende Objekte analysiert. Grundlage der Analyse ist neben den in den Abschnitten 2.1 und 2.2 zusammengefassten Anforderungen vor allem das konzeptionelle Modell der elektronischen Fallakte, aus dem die Analysegegenstände abgeleitet wurden (siehe Abbildung 6). Abbildung 6: Einordnung der Schutzbedarfsanalyse in das Dokument Anforderungen Rechtsgrundlagen Anforderungen an efa und epa Projektspez. Anforderungen Rechtssicherheit Methodische Basis Schutzziele Schutzbedarfe Bedrohungen Konzeptionelles Modell Sicherheitsanalyse Schutzbedarfsanalyse Objektbezogene Sicherheitsvorgaben Sicherheits strategie und Sicherheitskonzept Organisatorische Konzepte Architektur-Konzepte Technische Konzepte Sicherheitsarchitektur Die Analyse der Schutzbedarfe orientiert sich konsequent an den Schutzzielen und ordnet die einzelnen Objekte diesen unter. Grund hierfür ist, dass sowohl Schutzbedarfe als auch Bedrohungen insbesondere aus den Beziehungen zwischen den Objekten entstehen, d. h. eine alleinige Betrachtung der Objekte keine vollständige Analyse erlaubt. Zu jedem Schutzziel sind die primär zu schützenden Objekte und Objektbeziehungen wiedergegeben, die im Zentrum der Schutzbedarfsanalyse stehen und auf die die Betrachtung der anderen Objekte ausgerichtet wurde. Im Einzelnen sind dies: Schutz der Verfügbarkeit der in der verteilten Infrastruktur angesiedelten Daten und Dienste Schutz der Vertraulichkeit von (medizinischen, sozialen, ) Informationen über einen Patienten Sicherheitskonzept_v100 29

197 Schutz der Verbindlichkeit von medizinischen Datenobjekten und deren Klassifizierungsinformationen 4.1 Schutzziel Verfügbarkeit Das Schutzziel Verfügbarkeit ist primär für die in der (verteilten) Infrastruktur verwalteten medizinischen Datenobjekte sicherzustellen. Eine Nicht- Verfügbarkeit dieser Daten hat Störungen der Abläufe bei den Leistungserbringern zur Folge. Dieses kann zu Akzeptanzverlusten der Anwendungen, Einnahmeeinbußen beim Leistungserbringer und im Einzelfall auch zu Imageverlusten des Anbieters führen. Der Schutzbedarf der Verfügbarkeit medizinischer Datenobjekte ist daher als hoch anzusehen. Diese Einstufung entspricht der vom BMG für die Anwendung elektronische Patientenakte festgelegten Verfügbarkeitsanforderung [BMG_RA-1.1]. Um die Anforderungen an Maßnahmen zur Realisierung eines hohen Schutzes vor Nicht-Verfügbarkeit zu konkretisieren, muss der Begriff der Verfügbarkeit näher betrachtet werden: Ein Objekt oder System ist verfügbar, wenn vom Nutzer zum Zeitpunkt des Bedarfs ein Zugriff auf dieses Objekt/System und alle zum Zugriff benötigten Systeme und Kommunikationsverbindungen möglich ist. D. h. ein medizinisches Datenobjekt ist nur verfügbar, wenn der Zugriff auf dieses Objekt möglich ist und alle zur Authentisierung und Autorisierung des Zugreifers benötigten Daten und Systeme mit ausreichender Performanz verfügbar sind. Dieser Zugriff muss in einer den Geschäftsabläufen des Nutzers angemessenen Zeit erfolgen können. Wenn beispielsweise die Abläufe eines Arztes maximal 20 Sekunden zum Abruf eines medizinischen Datenobjekts vorsehen, die unterstützenden Systeme hierzu jedoch 40 Sekunden benötigen, ist das Objekt als für den Arzt nicht verfügbar anzusehen Anforderungen an die Ausfallsicherheit In der Risikoanalyse des BMG zur egk-lösungsarchitektur [BMG-RA05] wird eine hohe Verfügbarkeit über die Ausfallsicherheit der eingebundenen Systeme quantifiziert: Wiederherstellungszeitraum < 10 Minuten oder 30 Letzte Speicherung des Dokuments: :42:00

198 Schutzbedarfsanalyse Verfügbarkeit > 99,00% pro Jahr (d. h. 3,5 Tage Ausfall pro Jahr werden als tolerierbar angesehen) Zu jedem medizinischen Datenobjekt können potenziell zwei voneinander unabhängige Zugänge existieren: ein Zugang über die Anwendung elektronische Patientenakte und ein Zugang über die Anwendung elektronische Fallakte. Sind beide Zugänge gleichzeitig nicht verfügbar, sind zwangsläufig auch die hinter diesen Zugängen verwalteten medizinischen Datenobjekte nicht verfügbar. Aufgrund dieser möglichen Redundanz ist der Schutzbedarf jedes einzelnen Zugangs in Bezug auf Verfügbarkeit geringer als der entsprechende Schutzbedarf der medizinischen Datenobjekte. Allgemein lassen sich auf die Ermittlung von (als Wahrscheinlichkeiten ausgedrückten) resultierenden Verfügbarkeitswerten die Regeln der Wahrscheinlichkeitsrechnung anwenden. Die statistische Verfügbarkeit von Daten für einen (berechtigten) Nutzer lässt sich demgemäß wie folgt berechnen: Verfügbarkeit(Daten) = Verfügbarkeit(med. Datenobjekt) * (1 (1-Verfügbarkeit(ePA))*(1-Verfügbarkeit(eFA))) Beispiel: Das die Daten verwaltende System hat eine Verfügbarkeit von 98%, die beiden Datenzugänge über epa und efa sind ebenfalls jeweils zu 98% verfügbar (alle Angaben umfassen den kompletten Zugangsweg vom Aufrufer zum jeweiligen Datenspeicher). Hieraus ergibt sich die Gesamtverfügbarkeit eines über efa und epa abrufbaren Objekts als: 0,98 * (1- (1-0,98)*(1-0,98)) = 0,98 * (1-0,02 2 ) = 0,9796 Um die Verfügbarkeitsanforderung von 99,00% (= hoch) zu erfüllen, ist eine hohe Verfügbarkeit sowohl der medizinischen Datenobjekte als auch der beiden Zugänge erforderlich (Gesamtverfügbarkeit bei Einzelverfügbarkeit von jeweils 99%: 0,99 * (1-(1-0,99) 2 ) = 98,99%). Für die Phasen 1 und 2 der efa-einführung wird davon ausgegangen, dass Patienten nicht flächendeckend über eine elektronische Gesundheitskarte als Authentisierungstoken verfügen. Hierdurch entfällt für diese Phasen der direkte Datenzugang über eine patientengeführte epa. Sicherheitskonzept_v100 31

199 Die Gesamtverfügbarkeit der Daten berechnet sich hiermit für die Phasen 1 und 2 der epa-einführung als: Verfügbarkeit(Daten) = Verfügbarkeit(med. Datenobjekt) * Verfügbarkeit(eFA) Beispiel: Für die im obigen Beispiel angenommenen Verfügbarkeitszahlen der datenhaltenden Systeme und des efa-zugangs ergibt sich eine Gesamtverfügbarkeit von 0,98 * 0,98 = 0,9604 Um die Verfügbarkeitsanforderung von 99,00% (= hoch) zu erfüllen, ist bis zur dritten Einführungsphase eine Verfügbarkeit von 99,5% sowohl der medizinischen Datenobjekte als auch des Zugangs über die efa zu realisieren (Gesamtverfügbarkeit = 99,00%) Anforderungen an die Performanz Analog zur im bit4health-projekt vorgenommenen Spezifikation der nichtfunktionalen Anforderungen an die Dienste der Telematikinfrastruktur werden Anforderungen an die Ende-zu-Ende Performanz von Diensten der efa zu Antwortzeitkategorien (AZ) zusammengefasst, die jeweils über einen Normbereich (98% der Fälle), eine tolerierbare Abweichung (2% der Fälle) und eine nicht tolerierbare Abweichung (0,1% der Fälle) definiert werden: Antwortzeitkategorie AZ1: Norm: < 3 Sekunden Tolerierbar: < 8 Sekunden Nicht tolerierbar: > 8 Sekunden Antwortzeitkategorie AZ2: Norm: < 8 Sekunden Tolerierbar: < 30 Sekunden Nicht tolerierbar: > 30 Sekunden Jedem der im Rahmen der fachlogischen Analyse erhobenen Geschäftsvorfälle wird eine Antwortzeit-Kategorie zugeordnet, aus der Anforderungen an die Performanz und den Durchsatz der Dienste der efa abgeleitet werden können. 32 Letzte Speicherung des Dokuments: :42:00

200 Schutzbedarfsanalyse Während Geschäftsvorfälle Antwortzeitkategorien zugeordnet werden können, muss für Dienste der Infrastruktur eine genauere Performanzabschätzung erfolgen 7. Nur so kann anhand der Abläufe eines Geschäftsvorfalls verifiziert werden, ob die Vorgaben der Antwortzeitkategorie überhaupt eingehalten werden können. Für die Abschätzung der Performanz von Diensten der efa werden die folgenden Grundannahmen getroffen 8 : Dienstaufruf P2P-Broadcast 50 ms Overhead 250 ms Overhead Public Key sign/enc (HSM) 10 ms (.5K digest/key) Public Key sign/enc (Software) 25 ms (.5K digest/key) Public Key sign/enc (Karte) 50 ms (.5K digest/key) Public Key verify/dec (HSM) Public Key verify/dec (Software) Public Key verify/dec (Karte) 3DES enc/dec (HSM) 3DES enc/dec (Software) 150 ms (.5K digest/key) 300 ms (.5K digest/key) 500 ms (.5K digest/key) 500 ms/mb (bei Stream als delay) 1 sec/mb (bei Stream als delay) Für jede Feinspezifikation eines zur efa-umsetzung spezifizierten Dienstes ist eine theoretische Performanz auf der Basis der oben aufgeführten Rechengrößen anzugeben. Situationen, die zu einer Überschreitung der 7 Eine Einordnung von Diensten in Antwortzeitkategorien ist wenig hilfreich, da die Performanz-Spannbreiten hierdurch so groß werden, dass eine Aussage zur Ende-zu-Ende-Performanz nicht mehr möglich ist. Ein Geschäftsvorfall, der drei Dienste der Antwortzeitkategorie AZ1 nutzt, benötigt somit rein rechnerisch zwischen 0 und 9 Sekunden zur Ausführung. Um diese Beliebigkeit zu vermeiden, werden für alle Dienste konkrete Performanzabschätzungen gegeben, die als belastbare Grundlage für die Plausibilität der Zuordnung eines Geschäftsvorfalls in eine Antwortzeitkategorie dienen können. 8 Die angegebenen Werte sind Rechengrößen, die aus Produktblättern aktuell verfügbarer Lösungen entnommen wurden. Als Schlüssellängen wurden die von der Bundennetzagentur für bis Ende 2007 als sicher deklarierten Werte angenommen. Zugriffe auf Karten werden als sequentiell und nicht konkurrierend angenommen. Hard- und Softwarerealisierungen kryptografischer Algorithmen werden als horizontal skalierbar angenommen. Die aufgeführten Werte können natürlich von konkreten Umsetzungen in Abhängigkeit von der eingesetzten Hardware und der verfügbaren Infrastruktur (z. B. Anbindung der Kartenterminals) signifikant unter- oder überschritten werden. Dennoch sind sie geeignet, Hinweise darauf zu geben, ob ein in einem Dienst gekapselter Algorithmus potentiell die Einhaltung einer geforderten Antwortzeitkategorie für einen Ablauf gefährden kann oder als unkritisch anzusehen ist. Sicherheitskonzept_v100 33

201 theoretischen Performanz um mehr als 50% führen können, werden als Bedrohung für die Verfügbarkeit dieses Dienstes angesehen Schutzbedarfsanalyse Der nachfolgende Ausschnitt aus dem den Sicherheitsbetrachtungen zugrunde gelegten aus den Geschäftsprozessen abgeleiteten - Informationsmodell stellt die für die Verfügbarkeit von medizinischen Datenobjekten und den efa- Zugang relevanten Abhängigkeiten dar, die als Basis der folgenden Schutzbedarfsanalyse dienen. Abbildung 7: Für die Analyse der Verfügbarkeitsanforderungen relevanter Ausschnitt des konzeptionellen Modells Schutzbedarf der Verfügbarkeit medizinischer Datenobjekte Ein medizinisches Datenobjekt ist grundsätzlich verfügbar, wenn das Objekt selbst sowie die beschreibenden Daten verfügbar sind. In Bezug auf die beschreibenden Daten sind die Verfügbarkeitsanforderungen an die Klassifizierungsdaten, die Identifikationsdaten (Objekt-ID), die 34 Letzte Speicherung des Dokuments: :42:00

202 Schutzbedarfsanalyse Zugangsrechte und an die Daten zur Urheberschaft - und damit die entsprechenden Schutzbedarfe - zu untersuchen: Klassifizierungsdaten dienen vor allem der Filterung und der Suche. D. h. ein Datenobjekt wird einem Arzt auch dann angezeigt, wenn keine Klassifizierung verfügbar ist 9. Es wird jedoch potenziell nicht angezeigt, wenn eine Klassifizierung nicht integer ist, sodass dieses Objekt ggf. fälschlicherweise in einem Filter hängen bleibt oder von einer Suchanfrage nicht erfasst wird. Für die Verfügbarkeit der Daten ist daher nicht die Verfügbarkeit der Klassifizierungsdaten wesentlich, sondern deren Integrität. Um die hohe Verfügbarkeit medizinischer Datenobjekte sicherzustellen, sind die Anforderungen an die Verfügbarkeit von Klassifizierungsdaten normal. Die Anforderungen an die Integrität und Verbindlichkeit von Klassifizierungsdaten sind hoch. Der Zugang zu einem medizinischen Datenobjekt erfolgt erst nach erfolgreicher Authentisierung und Autorisierung der zugreifenden Person. Die Prüfung der Berechtigung eines Zugriffs erfolgt durch Abgleich der Autorisierung des Nutzers mit den einem Objekt direkt oder indirekt (z. B. über eine efa) zugeordneten Zugriffsrechten. Sind diese Informationen nicht verfügbar, erkennbar nicht integer oder nicht authentisch, wird kein Zugriff auf das Objekt gewährt. Zur Sicherstellung einer hohen Verfügbarkeit medizinischer Datenobjekte haben daher die Verfügbarkeit, Integrität und Verbindlichkeit von Zugangsinformationen und Zugriffsrechten einen hohen Schutzbedarf. Neu eingestellten Daten wird ein identifizierendes Datum (Objekt-ID) zugewiesen, unter dem sie von anderen berechtigten Nutzern abgerufen werden können. Bei Nicht-Verfügbarkeit von eindeutigen Identifizierungsdaten ist kein Einstellen neuer Objekte bzw. kein unmittelbarer Zugang zu diesen Objekten möglich. Da das Einstellen von Objekten ausnahmslos über Systeme mit der Möglichkeit der Zwischenspeicherung erfolgt und aus der fachlogischen Analyse keine Anforderung einer Nutzung der efa als synchrones Kommunikationsmedium ableitbar ist, besteht für die Verfügbarkeit von (neuen) Objekt-IDs ein normaler Schutzbedarf. Verfälschte oder doppelt vergebene Objekt-IDs können dazu führen, dass ein Objekt nicht gefunden werden kann. Hieraus ergibt sich ein hoher Schutzbedarf für die Integrität und Verbindlichkeit von Objekt-IDs. 9 Diese Aussage gilt aufgrund der Festlegung, dass ein nicht-vorhandenes Attribut immer einen Match für eine Suche oder einen Filter bedeutet. Sicherheitskonzept_v100 35

203 Medizinische Datenobjekte, zu denen keine Information über den Urheber verfügbar ist, gelten per se als nicht authentisch und werden daher nicht ausgeliefert. Der Schutzbedarf dieser Informationen in Bezug auf ihre Verfügbarkeit ist daher als hoch einzustufen Schutzbedarf der Verfügbarkeit des efa-zugangs Ein Zugang zu medizinischen Datenobjekten über die efa-anwendung schließt eine Authentisierung und Autorisierung der zugreifenden Person ein. Der Datenzugang über eine efa ist somit nur dann verfügbar, wenn die zur Authentisierung und Autorisierung erforderlichen Daten und Systeme verfügbar sind. Hierbei sind im Einzelnen die Zugangsinformationen einer Fallakte, die Identitätsdaten einer zugreifenden Person sowie das Authentisierungstoken der zugreifenden Person relevant. All diese Objekte besitzen daher in Bezug auf ihre Verfügbarkeit einen hohen Schutzbedarf Schutzbedarf von Authentisierungs- und Identifikationsdaten auf Anwendungsebene Eine Nicht-Verfügbarkeit oder Verfälschung von Authentisierungsinformationen, die einen Datenzugang für einen Nutzer ermöglichen sollen, führen zu einer Nicht-Verfügbarkeit sämtlicher Daten für diesen Nutzer. Der Schutzbedarf der Verfügbarkeit und der Integrität von dezentralen Authentisierungsdaten eines Arztes wird als normal angesehen, da nur ein eng eingrenzbarer Nutzerkreis betroffen ist. Ein nicht verfügbares oder in seiner Integrität verfälschtes Authentisierungstoken eines Dienstes führt zu einem Ausschluss dieses Dienstes aus dem sicheren Kommunikationsnetz. Hierdurch kann die Verfügbarkeit von Akten und Daten für alle Nutzer massiv beeinträchtigt sein. Der Schutzbedarf in Bezug auf Verfügbarkeit, Verbindlichkeit und Integrität für Authentisierungstoken von Diensten zur Authentisierung gegenüber anderen Diensten ist daher hoch. Die Nicht-Verfügbarkeit der Daten zur Patientenidentifikation führt dazu, dass die Daten dieses Patienten nicht gefunden werden können. Aufgrund des eingeschränkten Kreises von Betroffenen ist der Schutzbedarf der Verfügbarkeit, Integrität und Verbindlichkeit der Identifizierungsinformationen eines einzelnen Patienten unter dem Aspekt der generellen Verfügbarkeit von medizinischen Daten als normal anzusehen. 36 Letzte Speicherung des Dokuments: :42:00

204 Schutzbedarfsanalyse Schutzbedarf von Identitätsdaten von Ärzten Eine Nicht-Verfügbarkeit von Identitätsinformationen eines Nutzers (Arzt, med. Personal, etc.) führt dazu, dass diese Person nicht über Rollen- oder Organisationsrechte auf Daten zugreifen kann. Ein Zugriff über Individualrechte ist jedoch weiterhin möglich. Der Schutzbedarf der Verfügbarkeit von Identitätsinformationen eines Nutzers wird als normal eingestuft. Der Schutzbedarf für den die Identifikationsinformationen bereitstellenden Dienst ist hoch, da ein Ausfall eine Nichtverfügbarkeit eine Einschränkung der Zugriffsrechte für viele Nutzer zur Folge hätte Zusammenfassung der Schutzbedarfe Nachfolgend werden die oben motivierten Schutzbedarfe tabellarisch zusammengefasst. Zur Kennzeichnung der Schutzbedarfskategorien werden dabei Symbole verwendet (++ sehr hoch; + hoch; = normal). Leere Felder bedeuten, dass im Fokus des analysierten Schutzbedarfs kein Schutzbedarf besteht bzw. keine Aussage möglich ist. Tabelle 1: Objektbezogene Schutzbedarfe zur Sicherstellung der Verfügbarkeit von Daten und Diensten Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Med. Datenobjekt (MDO) + Information zu Ersteller des MDO + Klassifizierung (MDO) = + + Objekt-Identifizierer = + Zugang efa + Zugangsrechte (Fallakte) Identitätsdaten (Arzt) = + + Ident-Token (Patient) = = = Auth-Token (Arzt) = = = Auth-Token (Dienste) Sicherheitskonzept_v100 37

205 4.2 Schutzziel Vertraulichkeit Verletzungen der Vertraulichkeit von personenbezogenen und medizinischen Daten eines Patienten können negativen Einfluss auf die Lebensumstände des Patienten z. B. seine soziale Stellung und seine beruflichen Chancen haben. Im schlimmsten Fall können soziale Isolation und finanzieller Ruin die Folgen von Verletzungen der Vertraulichkeit medizinischer Daten sein. Der Schutzbedarf der Vertraulichkeit aller Daten und Datenzusammenführungen, die Rückschlüsse auf Krankheitsbilder, Lebensgewohnheiten und andere schützenswerte Informationen eines Patienten zulassen, ist von daher sehr hoch. Diese Einstufung ist konform zu [BSI100-2], wo die Gefahr eines gesellschaftlichen oder beruflichen Ruins des Betroffenen aufgrund eines möglichen Missbrauchs personenbezogener Daten als Charakteristikum einer massiven Beeinträchtigung des informationellen Selbstbestimmungsrechts aufgeführt ist, was wiederum einen sehr hohen Schutzbedarf bedingt 10. Aufgrund der gegebenen Rahmenbedingungen (z. B. keine Verfügbarkeit qualifizierter digitaler Signaturen) ist ein sehr hoher Schutz der Vertraulichkeit personenbezogener Informationen allein mit technischen Mitteln nicht zu realisieren. Im Vorgriff auf die in Kapitel 5.2 festgesetzten organisatorischen Schutzmaßnahmen werden daher alle Nutzungsszenarien einer efa, die einen sehr hohen Schutzbedarf der in die efa eingestellten Daten rechtfertigen, explizit ausgeschlossen. Aufgrund des Ausschlusses aller Nutzungsszenarien, die bei Verletzung des Schutzes der Vertraulichkeit personenbezogener Informationen eine Gefährdung von Leib und Leben beinhalten bzw. zum gesellschaftlicher oder beruflicher Ruin führen können, wird für die weitere Analyse von einem hohen Schutzbedarf der Vertraulichkeit personenbezogener, medizinischer Informationen ausgegangen 11. Der (verbleibende) hohe Schutzbedarf betrifft vor allem die Verknüpfung eines Patienten mit schützenswerten Informationen. Diese Verknüpfung kann dabei nicht nur explizit über ein einzelnes Objekt, sondern auch implizit durch Zusammenführung oder Verkettung mehrerer Objekte/Daten erfolgen. Die Wahrscheinlichkeit des Zutreffens der (implizierten) Information über den Patienten ist für die Bewertung des Schutzbedarfs irrelevant. Einem hohen 10 Diese Einstufung übertrifft die vom BMG für die Anwendung elektronische Patientenakte festgelegte hohe Vertraulichkeitsanforderung [BMG_RA-1.1]. 11 Diese Festlegung schließt explizit nicht aus, dass auch Nutzungsszenarien mit geringerem Schutzbedarf existieren, d. h. Konstellationen, in denen aus einer Indikation entstehende, in einer efa verwaltete Daten keinerlei Informationen offenbaren, deren Bekanntgabe mit Nachteilen für den Patienten verbunden wäre (z. B. Knochenbruch). 38 Letzte Speicherung des Dokuments: :42:00

206 Schutzbedarfsanalyse Schutzbedarf angemessene Maßnahmen sind deshalb bereits anzuwenden, wenn die Gefahr besteht, dass nicht autorisierte Personen Krankheitsbilder eingrenzen oder Wahrscheinlichkeiten zum Vorhandensein von Krankheitsbildern aus den gewonnenen Informationen ableiten können. Bei der Schutzbedarfsanalyse sind von daher nicht nur die Objekte selbst, sondern vor allem die explizit oder implizit vorhandenen Beziehungen zwischen den Objekten von Interesse. Ein Objekt efa mit der Zuordnung zu einem Patienten A und ein als Herzkatheterfilm gekennzeichnetes medizinisches Datenobjekt können z. B. jeweils für sich betrachtet einen geringen oder mittleren Schutzbedarf haben. Die Beziehung zwischen beiden Objekten, aus der sich die Vermutung ableiten lässt, dass der Patient A einen Herzinfarkt hatte, hat jedoch einen hohen Schutzbedarf. Die nachfolgende Darstellung des Objektmodells stellt die besonderen Herausforderungen des Schutzes der Vertraulichkeit bei Einbeziehung der Objektbeziehungen dar. Abbildung 8: Für die Analyse des Vertraulichkeitsschutzes relevanter Ausschnitt des konzeptionellen Modells Oberstes Schutzziel in Bezug auf die Vertraulichkeit von Patientendaten ist es, dass unbefugte Personen keine Beziehung zwischen den Objekten Patient Sicherheitskonzept_v100 39

207 und Personenbezogene Informationen herstellen können. Das Herstellen einer solchen Beziehung ist dabei grundsätzlich über jeden im Objektmodell enthaltenen Pfad zwischen diesen beiden Objekten möglich Anforderungen an die Vertraulichkeit In der Risikoanalyse des BMG zur Lösungsarchitektur des FuE-Projekts wird für die Herstellung eines hohen Schutzes von Vertraulichkeit die folgende Prozessqualität gefordert: Datenobjekte dieser Schutzbedarfskategorie sind vor unberechtigtem Zugriff durch Verschlüsselungsverfahren geschützt. Das entsprechende Schlüsselmaterial wird mit der Mechanismenstärke Mittel nach ITSEC geschützt. Der Zugriff auf ein Datenobjekt dieser Schutzbedarfskategorie ist nur nach einer Authentisierung entsprechend einem Verfahren der Prozessqualität Zertifikat und Passwort möglich 12. Beantragung, Ausstellung und Zertifikatsmanagement entsprechen dabei dem Niveau einer fortgeschrittenen Signatur nach SigG/SigV. Der Besitzer der Daten muss den Zugriff einer natürlichen Person oder einer Personengruppe auf diese Daten durch explizite Zustimmung freigeben. Wie in den obigen Ausführungen verdeutlicht, gelten diese Forderungen dabei nicht nur für den Zugang zu einem Datenobjekt, sondern auch für die Herstellung einer Beziehung zwischen einem Patienten und einer medizinischen Indikation. D. h. auf jedem Pfad von Patient zu Personenbezogene Information (und umgekehrt) muss es zumindest eine Beziehung oder ein Objekt geben, das einen hohen Vertraulichkeitsschutz besitzt. Sofern Verletzungen der Integrität von Daten zu einer Schutzverletzung der Vertraulichkeit eines Datenobjekts oder eines Pfades zwischen Patient und Personenbezogene Information führen können, ist für die Integrität dieses Objektes auch zumindest ein hoher Schutzbedarf gegeben Schutzbedarfsanalyse Basis der Schutzbedarfsanalyse ist das oben dargestellte Objektmodell. Schutzziele sind die Sicherstellung der Vertraulichkeit medizinischer 12 Diese Festlegung muss für die Nutzung der efa differenzierter ausgelegt werden, da neben Individualauch Gruppenrechte definiert sein können. D. h. auch eine Kombination aus Nutzerkennwort und Zertifikat einer Organisation ist geeignet, die formulierte Bedingung zu erfüllen. 40 Letzte Speicherung des Dokuments: :42:00

208 Schutzbedarfsanalyse Datenobjekte sowie die Verhinderung des Herstellens einer Verknüpfung von Patient und Personenbezogene Information Schutzbedarf der Vertraulichkeit medizinischer Datenobjekte Medizinische Datenobjekte können in kodierter Form Angaben zu Patienten und Krankheiten enthalten. Sie haben daher einen hohen Schutzbedarf und dürfen in unverschlüsselter Form nur berechtigten Personen zugänglich sein 13. Da aufgrund der fachlogischen Anforderungen und zur Umsetzung eines gesetzeskonformen Berechtigungsmanagements davon ausgegangen wird, dass eine Vertraulichkeit von Klassifizierungsdaten und Zugangskontrolllisten sowie eine Vertraulichkeit von deren Zuordnung zu Datenobjekten nicht sinnvoll ist, besteht ein hoher Schutzbedarf für die Zuordnung eines (verschlüsselten) medizinischen Datenobjekts zu einem Patienten. Nur so kann verhindert werden, dass anhand von Metadaten Verknüpfungen zwischen Personen und zu schützenden personenbezogene Information hergestellt werden können Schutzbedarf der Vertraulichkeit von elektronischen Patientenakten Bei der Analyse des Schutzbedarfs wird davon ausgegangen, dass in einer epa medizinische Daten eines Patienten strukturiert zusammengeführt werden. Der Schutzbedarf erstreckt sich damit auf die Vertraulichkeit der Personenzuordnung einer epa und/oder der Ablagestruktur und der darin vorgenommenen Verknüpfungen zu medizinischen Datenobjekten. Verletzungen der Vertraulichkeit der Ablagestruktur der medizinischen Daten eines Patienten als Teil einer 291a-konformen Patientenakte haben so lange keinen negativen Einfluss, wie hierdurch keinerlei Zusammenhang zwischen medizinischen und den Patienten identifizierenden Daten hergestellt werden kann. Ein Schutzbedarf der Ablagestruktur ist in diesem Fall nicht gegeben. Falls über die technische Realisierung der Ablagestruktur eine direkte oder indirekte Zuordnung von (klassifizierten) Datenobjekten zu Patienten möglich ist, ist der Schutzbedarf der Ablagestruktur hoch. 13 Siehe auch Hinweis in Kapitel 3.2 zur Einstufung des Schutzbedarfs der Vertraulichkeit personenbezogener Informationen als hoch. Sicherheitskonzept_v100 41

209 Der Schutzbedarf in Bezug auf die Vertraulichkeit, Integrität und Verbindlichkeit der Zuordnung einer epa zu einer Person ist hoch, falls die Struktur selbst nur mit niedrigem oder mittlerem Schutz versehen ist. Gründe hierfür sind, dass durch die Zusammenführung dieser Informationen nicht nur Rückschlüsse auf Krankheiten möglich wären, sondern auch gezielte Angriffe auf die Daten eines bestimmten Patienten erleichtert würden. Als weiteres Risiko wäre eine durch Kenntnis der Struktur mögliche Quantifizierbarkeit nicht auszuschließen (d. h. eine nicht-autorisierte Person kann zählen, wie viele Daten in die epa eines Patienten eingestellt sind). Falls die technische Umsetzung der Ablagestruktur einen hohen Schutz realisiert (d. h. Unberechtigte können aus der Kenntnis der Ablagestruktur heraus ein Objekt keinem Patienten zuordnen und von der Kenntnis der epa nicht auf im Baum enthaltene Objekte schließen), ist kein Schutzbedarf für die Vertraulichkeit der Personenzuordnung der epa-wurzel gegeben Schutzbedarf der Vertraulichkeit von elektronischen Fallakten Da auch in einer elektronischen Fallakte (efa) medizinische Daten eines Patienten strukturiert zusammengeführt werden, erstreckt sich der Schutzbedarf damit ebenso auf die Vertraulichkeit der Personenzuordnung der Fallakte und/oder auf der Ablagestruktur und der darin vorgenommenen Verknüpfungen zu medizinischen Datenobjekten. Verletzungen der Vertraulichkeit der Ablagestruktur der medizinischen Daten eines Patienten als Teil einer Fallakte haben solange keinen negativen Einfluss, wie hierdurch keinerlei Zusammenhang zwischen medizinischen und den Patienten identifizierenden Daten hergestellt werden kann. Ein Schutzbedarf der Ablagestruktur ist daher auch in diesem Fall nicht gegeben. Falls über die technische Realisierung der Ablagestruktur eine direkte oder indirekte Zuordnung von (klassifizierten) Datenobjekten zu Patienten möglich ist, ist der Schutzbedarf der Ablagestruktur hoch. Dies gilt auch in Anbetracht der weitgehenden Standardisierung der Ablagestrukturen, wodurch ggf. bereits aus dem Vorhandensein bestimmter Ablagestrukturen Rückschlüsse auf eine Erkrankung möglich sind. Da bei einer Fallakte vom Patienten autorisierte Zugangsrechte für die gesamte Akte gelten und nicht zwangsläufig direkt mit jedem in der Akte enthaltenen Objekt verknüpft sind, kommt der Integrität der Ablagestruktur einer efa eine besondere Bedeutung zu. Falsche Verknüpfungen von Objekten und Ordnern in der Weise, dass verschiedene efas vermengt werden, können dazu führen, dass eine falsche Berechtigungsprüfung auf ein Objekt angewandt wird. Hierdurch ist die Vertraulichkeit der Daten gefährdet. 42 Letzte Speicherung des Dokuments: :42:00

210 Schutzbedarfsanalyse Der Schutzbedarf der Integrität der Ablagestruktur einer Fallakte ist daher hoch. Der Schutzbedarf in Bezug auf Vertraulichkeit, Integrität und Verbindlichkeit der Zuordnung einer Fallakte zu einer Person ist hoch, falls die Struktur selbst nur mit niedrigem oder mittlerem Schutz versehen ist oder wenn klassifizierende Daten medizinische Indikationen implizieren. Falls die klassifizierenden Daten geeignet geschützt sind und auch die technische Umsetzung der Ablagestruktur einen hohen Schutz realisiert (d. h. Unberechtigte können ein Objekt keiner Fallakte zuordnen und umgekehrt aus der Kenntnis der Fallakte nicht auf im Baum enthaltene Objekte schließen), ist kein Schutzbedarf in Bezug auf die Vertraulichkeit der Personenzuordnung der Wurzel gegeben Schutzbedarf der Vertraulichkeit, Integrität und Verbindlichkeit von Zugangsrechten Sofern sich aus einem Datenobjekt oder einer Fallakte keine Personenzuordnung ableiten lässt, sind keine Anforderungen an die Vertraulichkeit von Zugangsrechten zu stellen. Eine Verfälschung von Zugangsrechten kann unberechtigten Personen den Zugang zu geschützten Daten ermöglichen. Da hierdurch die Vertraulichkeit dieser Daten gefährdet ist, hat die Integrität von Zugangskontrolllisten, Credentials und anderen Objekten zur Überprüfung von Berechtigungen einen hohen Schutzbedarf. Dasselbe gilt für die Verbindlichkeit dieser Objekte: Wenn aufgrund fehlender Verbindlichkeit von Zugangsinformationen ein missbräuchlicher Zugriff nicht aufgedeckt werden kann, mindert dies den Schutz der medizinischen Datenobjekte erheblich Schutzbedarf der Integrität und Verbindlichkeit von Identitätsdaten Identitätsdaten eines Arztes wie z. B. die Organisationszugehörigkeit oder die Rolle sind nicht vertraulich zu behandeln, da sie über eine Vielzahl von Stellen frei verfügbar und einsehbar sind. Da die Zugangsrechte zu Fallakten i. A. über Organisationszugehörigkeiten und Rollen spezifiziert werden, ist jedoch die Integrität und Verbindlichkeit von Identitätsdaten sehr wichtig. Verfälschte Identitätsdaten können dazu führen, dass eine Person unberechtigten Zugang zu einer Vielzahl von über Gruppenrechte geschützten Daten erhält. Um die hohe Vertraulichkeit medizinischer Datenobjekte sicherzustellen, haben die Integrität und die Verbindlichkeit von Identitätsdaten einen hohen Schutzbedarf. Sicherheitskonzept_v100 43

211 Schutzbedarf der Vertraulichkeit, Integrität und Verbindlichkeit von Authentisierungs- und Identifizierungstoken Verletzungen der Vertraulichkeit oder der Authentizität des Authentisierungstokens eines Arztes erleichtern unberechtigten Personen den Zugang zu medizinischen Daten. Neben einer Verletzung der Vertraulichkeit der Daten werden hierdurch auch Angriffe auf deren Authentizität möglich sowie die Integrität und Authentizität von Ablagestrukturen gefährdet. Wenn die Vertraulichkeit und die Authentizität des Authentisierungstokens einer Komponente nicht sichergestellt sind, wird hierdurch das Vortäuschen von Komponenten begünstigt, was wiederum zum Phishing von Daten und zur Verfälschung von Ablagestrukturen genutzt werden kann. Bedrohungen der Verbindlichkeit (Authentizität und Nicht-Abstreitbarkeit) von Authentisierungstoken können zu einer nicht berechtigten Zuordnung eines Authentisierungstokens zu einer Person führen. In Bezug auf Bedrohungen und Sicherheitsanforderungen entspricht dies einem Verlust an Vertraulichkeit. Die Schutzbedarfe von Vertraulichkeit, Integrität und Verbindlichkeit der Zugangstoken auf Anwendungsebene sind sehr hoch, da eine Schutzverletzung nicht nur die Vertraulichkeit der Daten eines Patienten, sondern potenziell die Vertraulichkeit der Daten einer schwer eingrenzbaren Menge von Patienten verletzen könnte. Die einen Patienten identifizierenden Daten (Token) haben einen normalen bis hohen Schutzbedarf, abhängig davon, inwieweit das Lösungskonzept der efa/epa die Weitergabe dieser Daten von einem Patienten an einen Arzt mit einer impliziten Zugangsfreigabe assoziiert. Findet keine weitere Authentisierung statt, ist der Schutzbedarf hoch. Findet eine von der Patienten-ID unabhängige Authentisierung statt, ist der Schutzbedarf der Identifizierungsdaten des Patienten normal und der des Authentisierungstokens des Arztes hoch. Da Verletzungen der Integrität und Authentizität von Identifizierungsdaten Ursache unberechtigter Datenzugriffe sein können, gilt für den Schutz der Integrität und Authentizität von Patienten- IDs das für das Schutzziel Vertraulichkeit Gesagte Schutzbedarf der Vertraulichkeit, Integrität und Verbindlichkeit von objektidentifizierenden Daten Medizinische Datenobjekte, Ordner von Fall- und Patientenakten sowie Fallakten werden über identifizierende Daten (Objekt-IDs) referenziert und verwaltet. Da Objekt-IDs hierdurch per se öffentlich bzw. einem großen Nutzerkreis bekannte Daten sind, muss eine Umkehrung von Schutzbedarf und Schutzmaßnahmen erfolgen; d. h. Objekt-IDs sind so zu gestalten, dass der 44 Letzte Speicherung des Dokuments: :42:00

212 Schutzbedarfsanalyse Schutzbedarf ihrer Vertraulichkeit niedrig ist. Dies ist nur möglich, wenn Objekt- IDs keine Semantik tragen, die einen Rückschluss auf ein Krankheitsbild erlaubt. Nicht-eindeutige und damit nicht-integre Identifizierungsdaten können dazu führen, dass Personen Zugang zu Daten oder Akten erlangen, zu denen sie nicht zugriffsberechtigt sind. Integrität und Verbindlichkeit von Objekt-IDs besitzen somit zum Schutz der Vertraulichkeit von medizinischen Daten einen hohen Schutzbedarf Zusammenfassung der Schutzbedarfe Nachfolgend werden die oben motivierten Schutzbedarfe tabellarisch zusammengefasst. Zur Kennzeichnung der Schutzbedarfskategorien werden dabei Symbole verwendet (++ sehr hoch; + hoch; = normal). Leere Felder bedeuten, dass im Fokus des analysierten Schutzbedarfs kein Schutzbedarf besteht bzw. keine Aussage möglich ist. Tabelle 2: Objektbezogene Schutzbedarfe zur Sicherstellung der Vertraulichkeit patientenbezogener Informationen Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Med. Datenobjekt (MDO) + epa: Ablagestruktur = 14 epa: Personenzuordnung efa: Ablagestruktur = + efa: Personenzuordnung Identitätsdaten (Arzt) + + Auth-Token (Arzt) Im Vorgriff auf die in Kapitel 5 beschriebene Sicherheitsstrategie und die daraus abgeleiteten Schutzmaßnahmen wird davon ausgegangen, dass nicht die Ablagestrukturen, sondern die Personenzuordnungen mit geeigneten Maßnahmen geschützt werden. Sicherheitskonzept_v100 45

213 Ident-Token (Patient); realisierungsabhängig =/+ =/+ =/+ Zugriffsrechte (efa) + + Objekt-Identifizierer (MDO, efa) = Schutzziele Integrität und Verbindlichkeit Bei der Analyse der Schutzbedarfe ist zu berücksichtigen, dass eine efa (oder epa) keine Primärdokumentation darstellt. Zweck einer efa sind die Unterstützung der Kooperation und Kommunikation zwischen in verschiedenen Einrichtungen/Sektoren angesiedelten Leistungserbringern und nicht die revisionssichere Dokumentation des Behandlungsablaufs. Jeder behandelnde Arzt ist gesetzlich verpflichtet, unabhängig von efa und epa seine eigene Behandlungsdokumentation zu führen. Der nachfolgende Ausschnitt aus dem Objektmodell stellt die Objekte und ihre wechselseitigen Beziehungen dar, die im Rahmen einer epa oder efa in Bezug auf die Integritätsanforderungen betrachtet werden müssen. 46 Letzte Speicherung des Dokuments: :42:00

214 Schutzbedarfsanalyse Abbildung 9: Für den Schutz der Integrität und Authentizität medizinischer Datenobjekte relevanter Ausschnitt des Objektmodells Anforderungen an die Integrität und Verbindlichkeit In der Risikoanalyse des BMG zur FuE-Lösungsarchitektur [BMG_RA-1.1] sind für die Erreichung eines hohen bzw. sehr hohen Schutzes der Integrität von Daten die folgenden Anforderungen formuliert: Hoher Schutzbedarf: Integritätsprüfung erfolgt an allen relevanten Prozessschritten, Integritätsverletzung ist erkennbar, deren Verursacher ist nicht immer ermittelbar. Sehr hoher Schutzbedarf: Integritätsprüfung erfolgt an allen relevanten Prozessschritten, Integritätsverletzung ist erkennbar, deren Verursacher ist immer ermittelbar. Für die Verbindlichkeit sind in demselben Dokument die folgenden Präzisierungen zu finden: Hoher Schutzbedarf: Handlungen sind eindeutig auf eine natürliche Person zurückführbar. Die Handlung kann von dem Ausübenden nur schwer bestritten werden. Die Nachweispflicht der Handlung liegt aber beim Kläger. Die Nichtabstreitbarkeit ist nicht sicher gegeben und hat deshalb keine Beweiskraft vor Gericht. Sehr hoher Schutzbedarf: Handlungen sind eindeutig und nachweisbar auf eine natürliche Person zurückführbar. Die Nachweispflicht der Nicht- Handlung liegt beim Handelnden. Die Nichtabstreitbarkeit gilt als sicher und hat deshalb Beweiskraft vor Gericht. Sicherheitskonzept_v100 47

215 4.3.2 Schutzbedarfsanalyse Nachfolgend werden die Schutzbedarfe der in dem oben dargestellten Ausschnitt aus dem Objektmodell erfassten Objekte festgelegt Schutzbedarf der Integrität und Verbindlichkeit von medizinischen Datenobjekten Der Schutzbedarf der Integrität und Authentizität von medizinischen Datenobjekten ist sehr hoch, da Verfälschungen Leben und Gesundheit von Patienten aufgrund falscher Medikation, Behandlung oder Therapie gefährden können. Ein sehr hoher Schutzbedarf besteht aus den genannten Gründen auch für die Integrität der Zuordnung eines medizinischen Datenobjekts zu einer Person, d. h. ein Arzt muss zweifelsfrei erkennen können, welchem Patienten ein durch eine efa übermitteltes Dokument zuzuordnen ist Schutzbedarf der Integrität und Verbindlichkeit von Klassifizierungsdaten Verfälschungen der ein medizinisches Datenobjekt beschreibenden Klassifizierungsdaten können vor allem zwei Konsequenzen haben: Die Klassifizierung impliziert ein falsches Bild des Gesundheitszustands eines Patienten. Die verfälsche Klassifizierung führt dazu, dass ein medizinisches Datenobjekt von einer Suchanfrage nicht erfasst wird bzw. von einem Filter als nicht relevant markiert und dadurch nicht an den Arzt weitergegeben wird. Sowohl die Klassifizierungsdaten an sich als auch Suchanfragen und Filter bilden lediglich redundante Zugänge zu den durch eine epa oder efa bereitgestellten Informationen. Da vorauszusetzen ist, dass ein Arzt eine sehr hohen Schutzbedarf erfordernde Integritätsannahme nicht auf Basis von selektiven oder gefilterten Zugriffen bildet, sondern sich in diesen Fällen einen vollständigen Überblick über alle verfügbaren Informationen verschafft hat, ist ein sehr hoher Schutzbedarf der Integrität von Klassifizierungsdaten nicht zu rechtfertigen. 15 Siehe auch Abschnitt Nutzungsbeschränkungen 48 Letzte Speicherung des Dokuments: :42:00

216 Schutzbedarfsanalyse Der Schutzbedarf der Integrität und Verbindlichkeit von Klassifizierungsdaten wird dennoch als hoch angesehen, da auch in nicht-kritischen Fällen eine Nicht-Beachtung von Dokumenten durch falsche Filter die Akzeptanz der efa und das Vertrauensverhältnis zum Patienten gefährden kann Anforderungen an die Integrität und Verbindlichkeit der Ablagestruktur einer epa Die Zusammenstellung und Strukturierung von medizinischen Dokumenten in einer elektronischen Patientenakte gemäß 291a SGB V liegt allein in der Verantwortung des Patienten. Da seitens der behandelnden Ärzte hierdurch weder eine Vollständigkeit noch eine korrekte Klassifizierung der Datenobjekte erwartet werden kann, ist der Schutzbedarf der Ablagestruktur einer epa in Bezug auf ihre Integrität niedrig, sofern lediglich die Integrität von einer Behandlung zugrunde liegenden Informationen betrachtet wird. Da eine nicht integre Ablagestruktur jedoch dazu führen kann, dass die darin eingestellten Dokumente nicht verfügbar oder nicht zuordenbar sind, wird für die Integrität der Ablagestruktur einer epa ein hoher Schutzbedarf angenommen. Da es sich bei der epa um eine freiwillige Anwendung der egk handelt, ist ihre Nutzung nur mit dem protokollierten Einverständnis des Patienten möglich. Der Patient kann dieses Einverständnis jederzeit widerrufen. Die Integrität und/oder Authentizität einer epa ist verletzt, wenn ohne Vorliegen einer Einwilligung bzw. nach Rücknahme der Einwilligung zur Nutzung der epa-anwendung noch ein Datenzugang über diese Anwendung besteht. Schutzverletzungen dieser Art führen dazu, dass Ärzte Dokumente in eine vom Patienten nicht autorisierte epa einstellen bzw. aus dieser auslesen. Dies kommt faktisch einer Verletzung der Vertraulichkeit der Daten gleich. Der Schutzbedarf des Zugangs zu einer epa in Bezug auf Integrität und Verbindlichkeit ist daher analog zum Schutzbedarf der Vertraulichkeit der medizinischen Daten als hoch einzustufen Schutzbedarf der Integrität und Verbindlichkeit der Ablagestruktur einer efa Elektronische Fallakten werden von den behandelnden Ärzten gemeinsam gepflegt. Die Struktur einer efa ist weitgehend - mit Anpassungen für einzelne Fachdisziplinen standardisiert. Das Einstellen von Dokumenten erfolgt ausschließlich durch Mediziner, wobei die Klassifizierung und die Einordnung von Dokumenten mit Unterstützung eines KIS bzw. PVS vorgenommen werden. Sicherheitskonzept_v100 49

217 Aufgrund der starren Strukturierung und der automatisierten Prozesse kann ein behandelnder Arzt davon ausgehen, dass ein für die Behandlung wesentliches Element nicht nur vorhanden ist, sondern auch an der dafür vorgesehenen Stelle eingeordnet wurde. Verletzungen der Integrität der Ablagestruktur einer efa können daher dazu führen, dass benötigte (und vorhandene) Informationen nicht aufgefunden und damit vom Arzt als nicht vorhanden angesehen werden. Dieses stellt eine Gefährdung der Nutzungsgrundlage der efa als Austausch- und Kooperationsplattform dar und kann Ursache für Doppeluntersuchungen und Verzögerungen im Behandlungsprozess sein. Der Schutzbedarf der Ablagestruktur einer efa in Bezug auf die Integrität ist somit hoch. Die Nutzung einer efa zur Unterstützung kooperativer Behandlungsszenarien ist nur mit dem protokollierten Einverständnis des Patienten möglich. Der Patient kann dieses Einverständnis jederzeit widerrufen. Die an eine efa geknüpften Zugangsrechte müssen zudem jederzeit auf den Personenkreis beschränkt sein, der vom Patienten z. B. im Rahmen des Behandlungsvertrags - zum Datenzugriff autorisiert wurde. Die Integrität und/oder Authentizität einer efa ist ebenso wie die einer epa verletzt, wenn ohne Vorliegen einer Einwilligung zur Nutzung der efa- Anwendung bzw. nach Rücknahme der Einwilligung noch ein Datenzugang über diese Anwendung besteht. Die Integrität und/oder Authentizität einer efa ist ebenfalls verletzt, wenn die Zugangskotrollliste der efa Personen das Recht auf einen Datenzugang einräumt, die nicht im Behandlungsvertrag aufgeführt sind. Schutzverletzungen dieser Art führen dazu, dass Ärzte Dokumente in eine vom Patienten nicht autorisierte efa einstellen, aus dieser auslesen bzw. nicht berechtigten Personen zugänglich machen. Dies kommt faktisch einer Verletzung der Vertraulichkeit der Daten gleich. Der Schutzbedarf des Zugangs zu einer efa in Bezug auf Integrität und Verbindlichkeit ist daher analog zum Schutzbedarf der Vertraulichkeit der medizinischen Daten als hoch einzustufen Schutzbedarf der Integrität von Identifizierungsdaten (Objekt-IDs) Verfälschte und/oder mehrfach vergebene Identifizierer für Dokumente und Akten könne dazu führen, dass medizinische Datenobjekte innerhalb einer elektronischen Akte nicht mehr auffindbar sind bzw. unberechtigten Personen zugeordnet werden. Verfälschte oder mehrfach vergebene Identifizierer für Ordner einer epa können dazu führen, dass große Teile eines Datenbestands nicht mehr auffindbar sind bzw. neu eingestellte Dokumente dem falschen Patienten zugeordnet werden. Die Integrität von Identifizierungsdaten besitzt daher einen hohen Schutzbedarf. 50 Letzte Speicherung des Dokuments: :42:00

218 Schutzbedarfsanalyse Schutzbedarf der Integrität anderer Objekte des Objektmodells Integritätsverletzungen von vorwiegend zur Zugangskontrolle benötigten Objekten bergen Gefährdungen für die Vertraulichkeit von medizinischen Datenobjekten oder erlauben es unberechtigten Personen, Informationen über den Gesundheitszustand anderer Menschen zu erlangen (siehe Ausführungen zum Schutzziel Vertraulichkeit ). Integritätsverletzungen von Authentisierungstoken führen dazu, dass ein Nutzer oder ein Dienst nicht auf Dienste der efa oder epa zugreifen kann. Die hieraus resultierenden Auswirkungen und die anzunehmenden Schutzbedarfe sind im Abschnitt zum Schutzziel Verfügbarkeit beschrieben Zusammenfassung der Schutzbedarfe Nachfolgend werden die oben motivierten Schutzbedarfe tabellarisch zusammengefasst. Zur Kennzeichnung der Schutzbedarfskategorien werden dabei Symbole verwendet (++ sehr hoch; + hoch; = normal). Leere Felder bedeuten, dass im Fokus des analysierten Schutzbedarfs kein Schutzbedarf besteht bzw. keine Aussage möglich ist. Tabelle 3: Objektbezogene Schutzbedarfe zur Sicherstellung der Integrität und Authentizität medizinischer Daten Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Med. Datenobjekt (MDO) Klassifizierungsdaten (MDO) + + epa: Zugang + + epa: Ablagestruktur + efa: Zugang + + efa: Ablagestruktur + + Zuordnung von MDO zu Patient Identifizierungsdaten + + Sicherheitskonzept_v100 51

219 4.4 Zusammenführung der Schutzbedarfe unter Berücksichtigung aller Schutzziele In der nachfolgenden Tabelle sind die unter den Aspekten Verfügbarkeit, Vertraulichkeit, Integrität und Verbindlichkeit einzeln erhobenen Schutzbedarfe zusammengefasst. Tabelle 4: Zusammenfassung der Schutzbedarfe Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Med. Datenobjekt (MDO) Zuordnung MDO zu Patient Information zu Ersteller des MDO Klassifizierung (MDO) = + + Objekt-Identifizierer = + + efa: Zugang efa: Ablagestruktur + + efa: Personenzuordnung epa: Zugang epa: Ablagestruktur + epa: Personenzuordnung Zugriffsrechte (Fallakte) Identitätsdaten (Arzt) = + + Auth-Token (Arzt) = ++ = ++ Ident-Token (Patient); realisierungsabhängig = =/+ + + Auth-Token (Dienste) Letzte Speicherung des Dokuments: :42:00

220 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben 5 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Aus den erhobenen Schutzbedarfen lassen sich für die einzelnen Schutzobjekte objektbezogene Vorgaben zu deren Realisierung, Verwaltung und Nutzung sowie zu deren konzeptioneller Einbettung in die Architektur machen. Die in diesem Kapitel formulierten Vorgaben beziehen sich allein auf die jeweiligen Objekte, d. h. sie gelten unabhängig von einer konkreten Architektur und einem konkreten, alle Objekte umfassenden Sicherheitskonzept. Alle Umsetzungen einer elektronischen Fallakte sind an diese Vorgaben gebunden, um ein Grundniveau an Sicherheit zu realisieren, auf dem die in Kapitel 6 beschriebenen Maßnahmen aufsetzen. Grundlage dieser von allen Implementierungen zu realisierenden Sicherheitsanforderungen und zu beachtenden Umsetzungsvorgaben sind die erhobenen Schutzbedarfe, die zu betrachtenden Bedrohungen und die rechtlichen Rahmenbedingungen der efa-nutzung (siehe Abbildung 10). Abbildung 10: Einordnung der objektbezogenen Sicherheitsvorgaben in das Dokument Anforderungen Rechtsgrundlagen Anforderungen an efa und epa Projektspez. Anforderungen Rechtssicherheit Methodische Basis Schutzziele Schutzbedarfe Bedrohungen Konzeptionelles Modell Sicherheitsanalyse Schutzbedarfsanalyse Objektbezogene Sicherheitsvorgaben Sicherheits strategie und Sicherheitskonzept Organisatorische Konzepte Architektur-Konzepte Technische Konzepte Sicherheitsarchitektur Die in diesem Kapitel zum Schutz einzelner Objekte zusammengefassten Aussagen sind so formuliert, dass sie wo immer möglich Umsetzungsspiel- Sicherheitskonzept_v100 53

221 räume erhalten, andererseits aber auch klare Vorgaben dort geben, wo diese Spielräume nicht gewünscht sind. Aus diesem Grund haben einzelne Aussagen eher den Charakter von Anforderungen, die eine (technische und organisatorische) Implementierung elektronischer Fallakten zu erfüllen hat. Wie diese Anforderungen erfüllt werden, ist der Implementierung überlassen und sollte sich an den gegebenen technischen und organisatorischen Rahmenbedingungen orientieren. Andere Aussagen zum Schutz einzelner Objekte geben wiederum mehr oder weniger konkrete Umsetzungsvorgaben vor, die von jeder Implementierung einzuhalten sind. Diese Umsetzungsvorgaben sind umso konkreter, je stärker die Interoperabilität verschiedener Implementierungen und deren Konformität zu Standards und der sich abzeichnenden Lösungsarchitektur der gematik betroffen sind. 5.1 Medizinische Datenobjekte In Tabelle 5 sind die in Kapitel 4 beschriebenen Schutzbedarfe medizinischer Datenobjekte und ihrer beschreibenden Daten zusammengefasst. Tabelle 5: Zusammenfassung des Schutzbedarfs eines med. Datenobjekts und seiner beschreibenden Daten Schutzbedarfe = : normal + : hoch ++ : sehr hoch Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Medizinisches Datenobjekt (MDO) Zuordnung MDO zu Patient Informationen zum Ersteller des MDO Klassifizierung und Metadaten (MDO) = + + Objekt-Identifizierer eines MDO = + Nachfolgend werden von efa-implementierungen zu den einzelnen Schutzzielen zu realisierende Sicherheitsanforderungen und Umsetzungsvorgaben zum Schutz medizinischer Datenobjekte aufgeführt Schutzziel Verfügbarkeit Bedrohungen für die Verfügbarkeit medizinischer Daten resultieren vor allem aus drei Szenarien: 54 Letzte Speicherung des Dokuments: :42:00

222 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Denial-of-Service-Angriffe auf die datenhaltenden Systeme Diese Angriffe können sowohl von außerhalb als auch von innerhalb des abgeschlossenen Netzes erfolgen. Nicht-Verfügbarkeit der datenhaltenden Systeme aufgrund zu niedriger Service Levels in Bezug auf die Bereitstellung bzw. Skalierbarkeit von technischen Komponenten und zur Systempflege notwendigen Managementprozessen Nicht-Verfügbarkeit von Zugangs- und Metadaten bzw. den diese verarbeitenden Systemen, was dazu führt, dass der Datenserver zwar verfügbar ist, aber die dort abgelegten Daten nicht freigegeben werden. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der folgenden Tabelle 6 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 6: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit medizinischer Datenobjekte MDO.V.01 MDO.V.02 MDO.V.03 MDO.V.04 MDO.V.05 Der Schutzbedarf aller für die Datenfreigabe benötigten Metadaten und Systeme ist mindestens so hoch anzusetzen wie der Schutzbedarf der Verfügbarkeit medizinischer Datenobjekte. DoS-Angriffe von außerhalb des geschlossenen Netzes sind durch geeignete Authentisierungsmaßnahmen beim Netzzugang sowie ggf. durch vorgeschaltete Systeme abzufangen. DoS-Angriffe von innerhalb des geschlossenen Netzes müssen erkennbar und der Verursacher muss identifizierbar sein. Der Netzzugang des Verursachers muss kurzfristig gesperrt werden können. Die existierenden Prozesse und rechtlichen Regelungen zur Datenweitergabe ohne IT-Unterstützung sind beizubehalten und ggf. anzupassen. Vorgehensweisen für den Fall eines Ausfalls der Telematik-Infrastruktur sind festzulegen. Für die datenhaltenden Systeme sind Sicherheitskonzepte und Betriebshandbücher zu erstellen, die sich am BSI- Grundschutz und an ITIL orientieren. Die maximal tolerierbaren Ausfall- und Wiederanlaufzeiten sind unter Berücksichtigung der für die Maßnahme MDO.V.04 realisierten Umsetzung anzupassen. Sicherheitskonzept_v100 55

223 MDO.V.06 Von den Betreibern der datenhaltenden Dienste sind Abschätzungen der zu erwartenden Last (Durchsatz und Zugriffsfrequenz) auszuarbeiten und im Betrieb kontinuierlich anzupassen (Capacity Management) Schutzziel Vertraulichkeit Bedrohungen für die Vertraulichkeit der Daten durch unbefugte Zugriffe gehen sowohl von außen als auch von potenziellen Innentätern aus. Auch Weiterentwicklungen in der Kryptoanalyse können zu Schwächungen von technischen Schutzmechanismen führen: Unberechtigte Personen erlangen Zugang zu den Daten und sind in der Lage diese zu dekodieren. Berechtigte Personen geben medizinische Daten an nichtzugangsberechtigte Personen weiter. Nicht berechtigte Personen sind in der Lage, über einen direkten Zugang zu den datenhaltenden Systemen medizinische Datenobjekte von Patienten einzusehen. Verschlüsselungsalgorithmen werden durch zu schwache Schlüssel bzw. zu kurze Schlüssellängen angreifbar oder durch Einsatz massiver Rechenleistung gebrochen. Genutzte Algorithmen sind aufgrund neuer technischer Entwicklungen bzw. neuer Erkenntnisse der Zahlentheorie als nicht mehr ausreichend sicher anzusehen. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der folgenden Tabelle 7 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 7: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Vertraulichkeit medizinischer Datenobjekte MDO.T.01 MDO.T.02 MDO.T.03 Datenzugriffe sind nur nach erfolgreicher Authentisierung und auf Basis einer Autorisierung des Zugreifers durch den Patienten möglich. Die Nutzung eines Datenzugangs ist nur auf Basis einer protokollierten Einwilligung des Patienten zu der entsprechenden Anwendung (epa oder efa) möglich. Medizinische Datenobjekte können auch in verschlüsselter Form nur von authentisierten und zum Zugriff berechtigten 56 Letzte Speicherung des Dokuments: :42:00

224 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Personen aus einem datenhaltenden System ausgelesen werden. Der Zugriff ist zu protokollieren. MDO.T.04 MDO.T.05 MDO.T.06 MDO.T.07 MDO.T.08 MDO.T.09 MDO.T.10 Datenobjekte müssen so gespeichert werden können, dass sie kein Merkmal tragen, über das unberechtigte Personen, die Zugang zu diesen Daten haben, auf eine Personenzuordnung schließen können. Sofern unberechtigte Personen Zugang zu den datenhaltenden Systemen haben, müssen die medizinischen Daten in diesen Systemen verschlüsselt abgelegt werden. Die genutzten Schlüssel sind geeignet zu verwahren und nur zugriffsberechtigten Personen zugänglich zu machen. Medizinische Datenobjekte verlassen den Server in einer Kodierung, die eine Entschlüsselung ausschließlich für berechtigte Personen bzw. Personengruppen (Organisationen, Rollen, etc.) ermöglicht. Eine Datenschutzkontrolle der Zugriffe kann durch eine unabhängige Stelle angefordert bzw. durchgeführt werden. Der Zugang zu einem Dokument muss gesperrt werden können, sodass im Fall einer Korrumption der Identitätsdaten des Patienten oder der Zugangsdaten eines zugriffsberechtigten Arztes keine Datenzugriffe mehr über diese Daten bzw. deren Träger möglich sind. Der Umgang mit Vertretern ist auf Basis der gesetzlichen Rahmenbedingungen zu regeln. Die Benennung eines Vertreters ist zu protokollieren. Aus den Zugriffsprotokollen müssen eine Vertreterkonstellation und die den Vertreter benennende Person rekonstruierbar sein. Die zur Verschlüsselung medizinischer Daten genutzten Algorithmen müssen austauschbar sein. Ggf. verschlüsselt gespeicherte Daten müssen in einem sicheren Verfahren auf einen anderen Algorithmus oder eine andere Schlüssellänge umgeschlüsselt werden können Schutzziel Integrität Bedrohungen für die Integrität der Daten gehen vor allem von Störungen der Speicher- und Übertragungssysteme sowie von Innentätern aus: Sicherheitskonzept_v100 57

225 Daten werden bei der Speicherung oder beim Transport über ein Kommunikationsnetz verfälscht. Daten werden in den datenhaltenden Systemen durch Sabotage oder Administrationsfehler verfälscht und damit unbrauchbar. Daten sind durch Fehler in Verschlüsselungsalgorithmen oder durch eine automatische Formatkonvertierung nicht mehr nutzbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 8 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 8: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Integrität medizinischer Datenobjekte MDO.I.01 MDO.I.02 MDO.I.03 MDO.I.04 Daten sind durch geeignete Maßnahmen vor unberechtigten Veränderungen zu sichern. Der Schutz ist von Ende zu Ende, d. h. vom Ersteller eines Objekts bis zum Nutzer dieses Objekts zu gewährleisten. Jeglicher interner Zugriff auf die datenhaltenden Systeme ist zu protokollieren. Administrationsvorgänge sind zu protokollieren. Es werden ausschließlich Implementierungen der Verschlüsselungs- und Hash-Algorithmen genutzt, die über eine entsprechende Sicherheitszertifizierung verfügen. Sicherheitsalgorithmen müssen ausgetauscht werden können. Es werden ausschließlich Produkte zur Formatkonvertierung genutzt, die über entsprechende Freigaben verfügen (z. B. durch den Lizenzhalter des Ausgangs- oder Zielformats zertifiziert sind) Schutzziele Verbindlichkeit Bedrohungen für die Verbindlichkeit gehen vor allem von Angriffen aus oder werden durch Fehler in den Prozessen begünstigt: Die Urheberschaft eines Dokuments ist unklar bzw. verfälscht. Ein Dokument wurde nach dem Einstellen verfälscht. Ein Dokument wird von einem Arzt einer falschen Person zugeordnet. 58 Letzte Speicherung des Dokuments: :42:00

226 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 9 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 9: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Authentizität medizinischer Datenobjekte MDO.A.01 MDO.A.02 MDO.A.03 MDO.A.04 MDO.A.05 Der Urheber eines Dokuments muss für den Nutzer dieses Dokuments erkennbar sein. Für den Nutzer eines Dokuments muss erkennbar sein, dass dieses in dem vorgefundenen Zustand vom Ersteller eingestellt wurde. Jedes Dokument muss (als Teil der verschlüsselten Daten) einen Hinweis auf den Patienten tragen, auf den sich das Dokument bezieht. Ein Arzt darf Entscheidungen, die Risiken für Leben oder Gesundheit eines Patienten bergen, nicht allein auf Basis von elektronischen Dokumenten treffen, sofern er sich nicht vergewissert hat, dass diese authentisch sind. Geeignete Maßnahmen beinhalten ggf. auch die Rückfrage beim Patienten oder beim Ersteller des Dokuments. Als Urheber muss immer eine natürliche Person benannt sein. Diese darf nicht stellvertretend für andere agieren. Die Benennung als Urheber eines Dokuments ist ein von der betroffenen Person wissentlich und willentlich durchgeführter Akt. 5.2 Elektronische Patientenakte nach 291a SGB V In Tabelle 10 sind die in Kapitel 4 beschriebenen Schutzbedarfe elektronischer Patientenakten zusammengefasst. Hierbei wird zwischen dem Schutz des Zugangs zu der Anwendung, der Struktur der in einer epa zusammengefassten Daten und der Zuordnung einer epa zu einem Patienten unterschieden. Sicherheitskonzept_v100 59

227 Tabelle 10: Zusammenfassung des Schutzbedarfs elektronischer Patientenakten Schutzbedarfe = : normal + : hoch ++ : sehr hoch Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit epa: Zugang epa: Ablagestruktur + epa: Personenzuordnung Nachfolgend werden Sicherheitsanforderungen und Umsetzungsvorgaben aufgeführt, die von Implementierungen elektronischer Patientenakten zu den einzelnen Schutzzielen zu realisieren sind Schutzziel Verfügbarkeit Bedrohungen für die Verfügbarkeit der Anwendung epa und der Strukturinformationen einer epa resultieren vor allem aus drei Szenarien: Denial-of-Service-Angriffe auf den Anwendungszugang und/oder die die Strukturdaten haltenden Systeme. Diese Angriffe können sowohl von außerhalb als auch von innerhalb des abgeschlossenen Netzes erfolgen. Nicht-Verfügbarkeit des Anwendungszugangs und/oder der die Strukturdaten haltenden Systeme aufgrund zu niedriger Service Levels in Bezug auf die Bereitstellung von technischen Komponenten und die zur Systempflege notwendigen Managementprozesse. Nicht-Verfügbarkeit von Zugangs- und Metadaten einer epa bzw. den diese verarbeitenden Systemen, was dazu führt, dass der Datenserver zwar verfügbar ist, aber die dort abgelegten Daten nicht freigegeben werden. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 10 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Patientenakten gestellt. Bereits im Zusammenhang mit dem Schutz medizinischer Datenobjekte dargestellte Anforderungen sind dabei nicht noch einmal aufgeführt worden. Tabelle 11: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit elektronischer Patientenakten EPA.V.01 Für alle Systeme, die Zugangs- oder Strukturdaten einer epa 60 Letzte Speicherung des Dokuments: :42:00

228 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben verwalten, sind Sicherheitskonzepte und Betriebshandbücher zu erstellen, die sich am BSI-Grundschutz und ITIL orientieren. Die maximal tolerierbaren Ausfall- und Wiederanlaufzeiten sind unter Berücksichtigung der für die Anforderung MDO.V.04 festgelegten Maßnahmen festzulegen. EPA.V.02 Einstiegspunkte in die Ablagestruktur (z. B. die Wurzel des Dateibaums) müssen Zugangsberechtigten auf verschiedenen Wegen zur Kenntnis gegeben werden können bzw. von Berechtigten abgefragt werden können Schutzziel Vertraulichkeit Bedrohungen für die Vertraulichkeit der Ablagestruktur und der Personenzuordnung gehen sowohl von außen (durch unbefugte Zugriffe) als auch von potenziellen Innentätern aus: Unberechtigte Personen können durch Traversieren der Ablagestruktur Hinweise auf den Patienten und/oder ein Krankheitsbild erhalten, wodurch gezielte Angriffe auf einzelne Daten möglich werden. Nicht autorisierte Personen können durch Datenbankabfragen oder Nutzung von Systemschnittstellen Hinweise auf die Zahl der zu einem Patienten vorgehaltenen Dokumente erhalten. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 12 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Patientenakten gestellt. Tabelle 12: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Vertraulichkeit elektronischer Patientenakten EPA.T.01 EPA.T.02 EPA.T.03 Ein Traversieren der Ablagestruktur ist nur für vom Patienten autorisierte Leistungserbringer möglich. Strukturdaten und Metadaten medizinischer Datenobjekte tragen keinen sichtbaren Hinweis auf den Patienten, dem sie zugeordnet sind. Sofern mit der Wurzel der Ablagestruktur personenidentifizierende Daten verknüpft sind, muss ein Aufwärtstraversieren der Ablagestruktur auch bei Kenntnis der gespeicherten Strukturinformationen ausgeschlossen sein. Sicherheitskonzept_v100 61

229 EPA.T.04 EPA.T.05 EPA.T.06 Ein Quantifizieren der einem Patienten zugeordneten Daten darf weder über von außen noch von innen kommende Anfragen möglich sein. Die für unberechtigte Personen von innen und außen sichtbaren Strukturdaten dürfen keinerlei Rückschluss auf ein Krankheitsbild erlauben bzw. dürfen keine Personenzuordnung implizieren. Der Zugang zu einer epa muss gesperrt werden können, sodass im Fall eines Verlusts der egk kein Missbrauch möglich ist Schutzziel Integrität Bedrohungen für die Integrität der Ablagestruktur sind weitgehend identisch mit den für die Authentizität der Daten geltenden Bedrohungen. Zusätzlich sind zu betrachten: Ein Datenobjekt wird in eine falsche Ablagestruktur eingestellt, wodurch andere als die intendierten Berechtigungsprüfungen durchgeführt werden. Durch Löschen eines Dokuments werden potenziell damit in engem Zusammenhang stehende Dokumente unbrauchbar oder in ihrer Aussage verfälscht. Durch Löschen eines Dokuments ist eine darauf basierende Entscheidung eines Arztes nicht mehr nachvollziehbar. Strukturdaten werden in den datenhaltenden Systemen durch Sabotage oder Administrationsfehler verfälscht und damit unbrauchbar. Hierdurch sind potenziell Patientendaten nicht mehr auffindbar. Strukturdaten sind durch Verlust von Schlüsseln oder Fehler in Verschlüsselungsalgorithmen nicht mehr nutzbar. Hierdurch sind potenziell Patientendaten nicht mehr auffindbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 13 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Patientenakten gestellt. Tabelle 13: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Integrität elektronischer Patientenakten EPA.I.01 Strukturdaten sind bei Speicherung und Transport durch geeignete Maßnahmen vor unberechtigten Modifikationen zu sichern. 62 Letzte Speicherung des Dokuments: :42:00

230 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben EPA.I.02 EPA.I.03 EPA.I.04 Die Einordnung eines Objekts in eine Struktur muss sicher nachprüfbar sein und darf nicht verfälscht werden können. Das Löschen eines Dokuments kann nur von einem Arzt im Auftrag des Patienten durchgeführt werden. Sofern ein Arzt ein aus einer epa ausgelesenes Dokument einer Entscheidung zugrunde legt, muss er dieses als Kopie unter Verweis auf die Quelle in sein Primärsystem übernehmen Schutzziele Verbindlichkeit Bedrohungen für die Verbindlichkeit einer epa gehen vor allem von Angriffen aus oder werden durch Fehler in den Prozessen begünstigt: Einem Arzt wird von dem Angreifer eine epa für einen Patienten vorgetäuscht, um auf diesem Weg an Daten zu gelangen, die der Arzt neu einstellt. Der Patient hat die Einwilligung zur Nutzung einer epa widerrufen. Dieser Widerruf wurde nicht allen nutzungsberechtigten Leistungserbringern übermittelt, bzw. diese gelangen nicht an diese Information. Eine epa wurde in der Form manipuliert aufgesetzt, dass ein Unberechtigter bei einer Kartenneuausstellung für den Patienten in den Besitz der Daten gelangen kann. Eine epa wird von einem Arzt einer falschen Person zugeordnet. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 14 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Patientenakten gestellt. Tabelle 14: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Authentizität elektronischer Patientenakten EPA.A.01 EPA.A.02 Die Einwilligung des Patienten zur Nutzung der epa ist so zu protokollieren, dass ein Arzt deren Status und Aktualität jederzeit verifizieren kann. Die Zuordnung einer epa zu einem Patienten muss sicher feststellbar sein (z. B. über ein unverfälschbares Patientenmerkmal oder über ein Sicherheitstoken, das sich im ausschließlichen Besitz des Patienten befindet). Sicherheitskonzept_v100 63

231 EPA.A.03 Bei einer egk-neuausstellung muss die epa sicher auf die neue Karte überschrieben werden können. 5.3 Elektronische Fallakte (efa) In Tabelle 15 sind die in Kapitel 4 beschriebenen Schutzbedarfe elektronischer Fallakten zusammengefasst. Hierbei wird wie bereits in der Schutzbedarfsanalyse (Kapitel 3) zwischen dem Schutz des Zugangs zu der Anwendung, der Struktur der in einer efa zusammengefassten Daten und der Zuordnung einer efa zu einem Patienten unterschieden. Tabelle 15: Zusammenfassung des Schutzbedarfs elektronischer Fallakten Schutzbedarfe = : normal + : hoch ++ : sehr hoch Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit efa: Zugang efa: Ablagestruktur + + efa: Personenzuordnung Nachfolgend werden Sicherheitsanforderungen und Umsetzungsvorgaben aufgeführt, die von Implementierungen elektronischer Fallakten zu den einzelnen Schutzzielen zu realisieren sind Schutzziel Verfügbarkeit Bedrohungen für die Verfügbarkeit der Strukturinformationen einer efa resultieren aus den gleichen Szenarien wie Bedrohungen für die Strukturinformationen einer epa. Ergänzend zu den bereits im Zusammenhang mit elektronischen Patientenakten benannten Vorgaben werden die nachfolgend zusammengefassten Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. 64 Letzte Speicherung des Dokuments: :42:00

232 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Tabelle 16: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit elektronischer Fallakten EFA.V.01 EFA.V.02 Zu jeder efa muss es zu jedem Zeitpunkt ihres Lebenszyklus mindestens zwei voneinander unabhängige Zugangsdatensätze geben, über die ein Zugriff möglich ist. Einstiegspunkte in eine neu angelegte efa müssen Zugangsberechtigten auf verschiedenen Wegen bekannt gegeben werden können bzw. von Berechtigten abgefragt werden können Schutzziel Vertraulichkeit Bedrohungen für die Vertraulichkeit der Ablagestruktur und der Personenzuordnung von Fallakten entsprechen weitgehend den für elektronische Patientenakten genannten Bedrohungen. Die für die epa genannten Schutzmaßnahmen sind daher auch für die efa unzusetzen Schutzziel Integrität Bedrohungen für die Integrität der Ablagestruktur sind weitgehend identisch mit den für die Authentizität der Daten und die Integrität einer epa geltenden Bedrohungen. Entsprechend sind die dort genannten Anforderungen und Maßnahmen auch für die efa zu beachten Schutzziel Verbindlichkeit Bedrohungen für die Verbindlichkeit einer efa gehen vor allem von Angriffen aus oder werden durch Fehler in den Prozessen begünstigt: Einem Arzt wird eine efa für einen Patienten vorgetäuscht, um auf diesem Weg an darin neu eingestellte Daten zu gelangen. Der Patient hat die Einwilligung zur Nutzung einer efa widerrufen. Dieser Widerruf wurde nicht allen nutzungsberechtigten Leistungserbringer durchgestellt, bzw. diese gelangen nicht an diese Information. Eine efa wird von einem Arzt einer falschen Person zugeordnet. Die Prozesse zur Kennzeichnung des Urhebers einer efa sind unsicher, so dass mehrere Personen unter dem gleichen Namen agieren können Unter Berücksichtigung dieser Bedrohungen werden zusätzlich zu den bereits für die epa aufgeführten Maßnahmen die folgenden, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Sicherheitskonzept_v100 65

233 Tabelle 17: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Authentizität elektronischer Fallakten EFA.A.01 Wenn ein Patient die Einwilligung zur Nutzung einer efa widerruft, müssen alle zuvor berechtigten Personen und Organisationen hierüber aktiv informiert werden. Die Zustellung dieser Information ist zu protokollieren. 5.4 Authentisierungsschlüssel und token (Anwendungsebene) Auf der Anwendungsebene findet eine Authentisierung durch entsprechende Authentisierungsdaten bzw. token in zwei unterschiedlichen Szenarien statt: Authentisierung von Personen bzw. Gruppen (Organisationen, Organisationseinheiten, etc.) zum Zugriff auf Akten und Daten Gegenseitige Authentisierung von (serverseitigen) Diensten zum Austausch bzw. zur Weiterleitung von Daten und Nachrichten Für beide Szenarien wird davon ausgegangen, dass die Authentisierungsdaten über eine geeignete Hardware (Smartcard, Steckkarte, Stick, HSM, etc.) bzw. z. B. im Fall von Organisationsrechten durch eine entsprechende, in Hardware ausgeführte Verkabelung der genutzten Systeme gesichert sind. Für die Analyse der Schutzbedarfe sowie die Festlegung von Sicherheitsanforderungen und Umsetzungsvorgaben wird daher nicht zwischen Authentisierungsdaten und Trägermedium differenziert. In Tabelle 18 sind die in Kapitel 4 erhobenen Schutzbedarfe für Authentisierungsschlüssel der Anwendungsebene und deren Trägermedien zusammengefasst. Tabelle 18: Zusammenfassung der Schutzbedarfe von Authentisierungsschlüsseln und -token Verfügbarkeit Vertraulichkeit Integrität Authentizität Nicht-Abstreitb. Auth-Token (Arzt) = ++ = ++ Auth-Token (Dienste) Nachfolgend werden zunächst einige generelle Anforderungen an die technische Umsetzung von Authentisierungstoken als Trägermedien von 66 Letzte Speicherung des Dokuments: :42:00

234 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Authentisierungsschlüsseln formuliert. Anschließend werden die Anforderungen und Vorgaben zusammengefasst, die die einzelnen Schutzziele adressieren. Tabelle 19: Generelle Sicherheitsanforderungen und Umsetzungsvorgaben für Authentisierungstoken AU7.G.01 AU7.G.02 Wenn zur Verwaltung von Authentisierungstoken Smartcards eingesetzt werden, sind diese nach ISO 7816 auszugestalten. Das aktuelle Protection Profile des BSI (BSI-PP ) ist anzuwenden. Wenn zur Verwaltung von Authentisierungstoken Smartcards eingesetzt werden, müssen diese einen ausreichenden Schutz des Authentisierungstokens gegen invasive und nichtinvasive Angriffe bieten Schutzziel Verfügbarkeit Bedrohungen für die Verfügbarkeit der Authentisierungsdaten der Anwendungsebene resultieren aus menschlichem Fehlverhalten (z. B. Chipkarte vergessen ) und Performanzengpässen durch hohe Last: Ein Arzt hat den Träger seines Authentisierungstokens verloren oder nicht bei sich. Ein Arzt kann nicht auf die Daten zugreifen, da er zur Aktivierung des Authentisierungstokens benötigte Informationen (PIN, Passwort, etc.) vergessen hat. Ein Authentisierungstoken ist nicht verfügbar, da seine Performanz und/oder sein Durchsatz nicht anforderungsgerecht ausgelegt bzw. umgesetzt wurden. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 20 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 20: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit von Authentisierungsdaten AU7.V.01 Die Prozesse zur Verwaltung und Pflege der einen Dienst authentisierenden Token sind so zu gestalten, dass Sicherheitskonzept_v100 67

235 Konfigurationsfehler entweder ausgeschlossen sind oder unmittelbar erkannt und behoben werden. AU7.V.02 AU7.V.03 Für alle Authentisierungstoken sind vorab die Anforderungen an Performanz und Durchsatz zu erheben und mit der vorgesehenen Realisierung abzugleichen. In eine Sperrliste eingetragene Authentisierungstoken müssen wieder entsperrt werden können. Die Prozesse zum Eintragen eines Tokens in eine Sperrliste sind so auszugestalten, dass das Zugangstoken eines Arztes nicht versehentlich oder absichtlich durch hierzu unberechtigte Dritte gesperrt werden kann Schutzziel Vertraulichkeit Bedrohungen für die Vertraulichkeit der Authentisierungsdaten gehen vor allem von menschlichem Fehlverhalten und Schwachstellen in Prozessen aus: Authentisierungstoken werden von einem Arzt oder Administrator an eine andere Person weitergegeben. Authentisierungstoken werden mit betrügerischer Absicht entwendet. Authentisierungstoken werden auch für andere Zwecke genutzt und dabei ausgelesen bzw. in ihrer Vertraulichkeit geschwächt. Aus einem Authentisierungstoken erzeugte Authentisierungsinformationen werden abgefangen und für ein späteres Wiedereinspielen genutzt (siehe auch Authentizität ). Authentisierungstoken sind bei der Erstellung oder Auslieferung für unbefugte Personen auslesbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 21 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 21: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Vertraulichkeit von Authentisierungsdaten AU7.T.01 AU7.T.02 Authentisierungstoken der Anwendungsebene sind immer genau einer natürlichen Person bzw. einer eine Gruppe eindeutig repräsentierenden Systemkomponente zugeordnet. Authentisierungstoken zum Datenzugang werden auf einem Träger gespeichert und können von Unberechtigten nicht aus diesem ausgelesen und auf diesem auch nicht überschrieben 68 Letzte Speicherung des Dokuments: :42:00

236 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben werden. AU7.T.03 AU7.T.04 AU7.T.05 AU7.T.06 AU7.T.07 Personengebundene Authentisierungstoken zur Inanspruchnahme persönlicher Zugangsrechte sind ausschließlich auf einem Träger in Besitz dieser Person gespeichert. Es werden keine Duplikate vorgehalten. Die Freigabe des Tokens (z. B. privater Schlüssel) kann nur durch diese Person erfolgen. Um dies sicherzustellen, sind geeignete Maßnahmen vorzusehen (PIN, etc.). Aus einem Authentisierungstoken erzeugte Authentisierungsinformationen haben denselben Schutzbedarf wie das Token selbst. Sie dürfen daher beim Transport über ein Netz nicht in nutzbarer Form abgefangen werden können. Authentisierungstoken zum Datenzugang müssen gesperrt werden können. Die Sperrung muss unmittelbar an alle Dienste kommuniziert werden, bzw. ein Dienst muss beim Verbindungsaufbau den Status des Authentisierungstokens eines Nutzers bzw. eines anderen Dienstes abfragen können. Die Authentisierung einer zugreifenden Person erfordert Besitz und Wissen. So ist z. B. der Besitz einer Smartcard durch die Freigabe des Authentisierungsschlüssels per PIN- Eingabe zu ergänzen. Die Prozesse zur PIN-Erzeugung, -Übermittlung und -Änderung müssen dem Schutzbedarf angemessen sein. Authentisierungstoken (Schlüssel) von Diensten können erst nach Freigabe durch einen dazu berechtigten Administrator genutzt werden. Der Dienstbetreiber hat durch geeignete technische und organisatorische Maßnahmen sicherzustellen, dass nur dazu berechtigte Personen diese Nutzungsfreigabe des Authentisierungstokens vornehmen können Schutzziel Integrität Bedrohungen der Integrität von Authentisierungstoken sind bei Umsetzung der Sicherheitsanforderung AU7.T.02 (Speicherung auf einem Träger, kein Überschreiben möglich) auszuschließen. Sicherheitskonzept_v100 69

237 5.4.4 Schutzziel Verbindlichkeit Bedrohungen der Verbindlichkeit resultieren aus einer falschen Zuordnung von Authentisierungsdaten zu einer Person bzw. einer fehlenden Nachprüfbarkeit dieser Zuordnung: Eine Signatur kann nicht verifiziert werden, da der öffentliche Schlüssel der signierenden Person von keiner unabhängigen Stelle bezogen bzw. bestätigt werden kann. Sperrlisten sind veraltet oder nicht integer. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 22 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 22: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verbindlichkeit von Authentisierungsdaten AU7.A.01 AU7.A.02 AU7.A.03 AU7.A.04 Alle öffentlichen Schlüssel, über deren private Pendants Authentisierungen durchgeführt werden, sind in entsprechende Verzeichnisse einzutragen. Die Zuordnung eines Schlüssels zu einer Person, Gruppe bzw. einem Dienst und seinem Provider muss unabhängig von den spezifizierten Authentisierungsmechanismen und den dazu genutzten Diensten für jeden Nutzer verlässlich möglich sein. Die Integrität und Aktualität einer Sperrliste muss für die Authentisierungsdienste überprüfbar sein. Die Authentizität der Einträge einer Sperrliste muss vom Anbieter der Sperrliste sichergestellt werden und für jeden Eintrag überprüfbar sein. Änderungen an Sperrlisten sind in Form zu protokollieren, die eine Nichtabstreitbarkeit der Änderung durch die durchführende Person sicher stellt. 70 Letzte Speicherung des Dokuments: :42:00

238 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben 5.5 Identitätsdaten Alle potenziell zu einer efa zugriffsberechtigten Personen sind innerhalb der efa-infrastruktur über eine (virtuelle) Identität erfasst 16. Diese Identität umfasst eine individuelle, eindeutige Identifizierung sowie die Gruppenzugehörigkeiten einer Person. Ein hoher Schutzbedarf besteht für die Integrität und Verbindlichkeit der Identitätsdaten, da Verletzungen dieser Schutzziele unberechtigte Datenzugriffe ermöglichen könnten (siehe Tabelle 23). Tabelle 23: Zusammenfassung der Schutzbedarfe von Identitätsdaten Verfügbarkeit Vertraulichkeit Integrität Authentizität Nicht-Abstreitb. Identitätsdaten (Personal in med. Einrichtungen) = + + Bei der nachfolgenden Aufstellung von Sicherheitsanforderungen und Umsetzungsvorgaben für Identitätsdaten wird davon ausgegangen, dass diese Daten über einen (verteilten) Dienst bereitgestellt werden, gegenüber dem sich eine Person mit einem Authentisierungsschlüssel authentisiert Schutzziel Verfügbarkeit Bedrohungen für die Verfügbarkeit der Identitätsinformationen entstehen durch Nicht-Verfügbarkeit des Identitätsdienstes und durch Schwachstellen in den dahinter liegenden Systemen und Abläufen: Eine Person ist nicht im Identitätsdienst erfasst. Eine Gruppenzugehörigkeit einer Person ist nicht oder unvollständig erfasst. Vertreter sind nicht erfasst. 16 Elektronische Patientenakten gemäß 291a SGB V werden im Zusammenhang mit Identitätsdaten nicht betrachtet, da der Zugriff hier nur für natürliche Personen oder über den HBA kodierte Rollenzugehörigkeiten im Zusammenspiel mit einer egk möglich ist. Hierdurch müssen für die epa keine außerhalb eines Zertifikats kodierten Identitätsdaten gepflegt werden. Sicherheitskonzept_v100 71

239 Eine Person kann keinem Identitätsdienst zugeordnet werden. Der Identitätsdienst oder einer der von ihm benötigten Dienste ist nicht verfügbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 24 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 24: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit von Identitätsdaten ID.V.01 ID.V.02 ID.V.03 ID.V.04 ID.V.05 Der Prozess des Einpflegens einer Person in einen Identitätsdienst ist von jedem Anbieter zu definieren. Hierbei soll sichergestellt werden können, dass ein Arzt innerhalb eines den Anforderungen der Geschäftsprozesse entsprechenden Zeitraums mit einer Identität versehen wird. Der Prozess der Zuordnung von Personen zu Gruppen ist von jedem Anbieter eines Identitätsdienstes zu definieren. Der Prozess zum Festlegen von Vertretern durch einen Arzt ist zu definieren. Es soll sichergestellt werden können, dass Gruppenzugehörigkeiten und Vertreterregelungen innerhalb eines den Anforderungen der Geschäftsprozesse entsprechenden Zeitraums wirksam werden. Die Zuordnung einer zugreifenden Person zu einem Identitätsdienst muss entweder vom Client oder vom Server zweifelsfrei und effizient durchgeführt werden können. Auch bei nicht verfügbarem Identitätsdienst muss ein Zugriff des Arztes als Individuum möglich sein, d. h. durch einen Ausfall des Identitätsdienstes darf lediglich die Verfügbarkeit der Berechtigungen über eine Gruppenzugehörigkeit gestört sein. Für den Identitätsdienst und seine nachgelagerten Dienste sind Sicherheitskonzepte und Betriebshandbücher zu erstellen, die sich am BSI-Grundschutz und an ITIL orientieren. Die maximal tolerierbaren Ausfall- und Wiederanlaufzeiten sind unter Berücksichtigung der für die Maßnahme ID.V.04 realisierten Umsetzung anzupassen. 72 Letzte Speicherung des Dokuments: :42:00

240 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Schutzziel Vertraulichkeit Ein Schutzbedarf für die Vertraulichkeit von Identitätsdaten liegt nicht vor. Aus diesem Grund sind hierzu auch keine Sicherheitsanforderungen zu stellen Schutzziel Integrität Bedrohungen für die Integrität der Identitätsdaten gehen vor allem von Innentätern und von unzureichend definierten bzw. umgesetzten Wartungsprozessen aus: Die Zuordnungen von Personen zu Gruppen sind nicht integer bzw. nicht aktuell. Ein Vertreter wird unberechtigterweise benannt bzw. eingetragen. Die nachfolgend zusammengestellten Sicherheitsanforderungen ergänzen die bereits zum Schutz der Verfügbarkeit aufgeführten Anforderungen. Tabelle 25: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Integrität von Identitätsdaten ID.I.01 ID.I.02 ID.I.04 Die vorgenommenen Zuordnungen von Personen zu Gruppen müssen durch die aktuellen Daten des Personal- Managements eines Krankenhauses oder andere unabhängig von der efa-anwendung abrufbare Daten verifizierbar sein. Vertreter können nur zeitlich befristet (für max. 4 Wochen) eingetragen werden. Nach Ablauf der Frist wird die Vertreter- Konstellation automatisch aus den Daten des Identitätsdienstes entfernt. Vom Anbieter eines Identitätsdienstes ist ein Prozess zu definieren und umzusetzen, mit dem kontinuierlich überprüft werden kann, dass keine nicht den zugeordneten Häusern und Arztpraxen zugeordneten Personen erfasst sind Schutzziel Verbindlichkeit Bedrohungen von Authentizität und Nicht-Abstreitbarkeit resultieren aus Schwächen in den Prozessen zur Pflege der Identitätsdaten: Ein Vertreter wird durch eine dazu nicht berechtigte Person (ggf. sogar für eine andere Person) ernannt. Sicherheitskonzept_v100 73

241 Die Grundlage der Zuordnung einer Person zu einer Gruppe ist nicht klar bzw. die Zuordnung ist nicht nachvollziehbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 26 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 26: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verbindlichkeit von Identitätsdaten ID.A.01 ID.A.02 ID.A.03 Vertreter können nur von Ärzten und nur für sich selber benannt werden. Authentizität und Nicht-Abstreitbarkeit sind ggf. durch flankierende Offline-Maßnahmen sicherzustellen. Das Eintragen einer Vertretung ist zu protokollieren. Der Zugang zu den Systemen zur Verwaltung von Identitätsdaten ist auf einen fest eingegrenzten Personenkreis zu beschränken. Zugriffe auf die Systeme sind zu protokollieren. Der Ursprung jedes Personeneintrags und jeder Gruppenzuordnung muss nachvollziehbar sein. Das Eintragen einer Vertretung ist vom Vertretenen explizit in einem von der Eintragung unabhängigen Prozess (z. B. per Mail) zu bestätigen und wird erst mit der Bestätigung wirksam. Absendung und Erhalt der Bestätigung sind zu protokollieren. 5.6 Zugangsdaten und Autorisierungen Zugangsdaten und/oder Autorisierungen sind die Daten, anhand derer entschieden wird, ob einer Person der gewünschte Zugriff auf ein Objekt erlaubt wird oder nicht. Aus diesem Zweck heraus bestehen in Bezug auf die Verfügbarkeit, Integrität und Verbindlichkeit dieser Daten hohe Schutzanforderungen (siehe Tabelle 27). 74 Letzte Speicherung des Dokuments: :42:00

242 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Tabelle 27: Zusammenfassung der Schutzbedarfe von Zugangsdaten Verfügbarkeit Vertraulichkeit Integrität Authentizität Nicht-Abstreitb. Zugangsdaten (efa/epa, Ordner, Datenobjekte) Bei der nachfolgenden Aufstellung von Sicherheitsanforderungen und Umsetzungsvorgaben für Zugangsdaten wird von deren Umsetzung abstrahiert, d. h. alle Aussagen treffen sowohl für an Objekte als auch für an Personen gebundene Zugangsdaten zu Schutzziel Verfügbarkeit Bedrohungen der Verfügbarkeit von Berechtigungsinformationen entstehen durch Nicht-Verfügbarkeit der diese Daten verwaltenden Dienste und durch Schwachstellen in den dahinter liegenden Systemen und Abläufen: Berechtigungen einer Person sind nicht erfasst. Berechtigungen können nicht auf einen Vertreter übertragen werden. Die Berechtigungen einer Person bzw. die Zugangsdaten eines Objekts können nicht identifiziert werden bzw. sind nicht zugreifbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 28 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 28: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verfügbarkeit von Autorisierungsdaten ACL.V.01 ACL.V.02 Der Prozess zur Abbildung der mit einem Behandlungsvertrag erteilten Rechte auf informationstechnisch interpretierbare Zugangsdaten ist von jedem Krankenhaus derart zu gestalten, dass die Vollständigkeit und Integrität der Abbildung sichergestellt ist. Die Zuordnung von Personen zu Berechtigungen bzw. von Objekten zu Berechtigungen muss eindeutig und zweifelsfrei sein. Sicherheitskonzept_v100 75

243 ACL.V.03 Die eine Berechtigung verwaltende Dienstinstanz muss anhand der Identität des Zugreifers, anhand des zugegriffenen Objekts oder anderer statischer Daten eindeutig ermittelbar sein Schutzziel Vertraulichkeit Ein Schutzbedarf für die Vertraulichkeit von Zugangsberechtigungen liegt nicht vor, da vorausgesetzt wird, dass über diese Daten kein Personenbezug zum Patienten herstellbar ist. Aus diesem Grund sind hierzu auch keine Sicherheitsanforderungen zu stellen Schutzziel Integrität Bedrohungen für die Integrität von Zugangsberechtigungen gehen vor allem von Innentätern und von unzureichend definierten bzw. umgesetzten Administrationsprozessen aus. Integritätsverletzungen der Zugriffsrechte auf eine efa sind dadurch gekennzeichnet, dass die im Behandlungsvertrag festgelegten Berechtigungen sich nicht in entsprechender Weise in den technischen Kodierungen widerspiegeln. Die Zuordnungen von Zugriffsrechten zu Personen oder Gruppen sind nicht integer bzw. nicht aktuell. Die Zuordnung von Zugriffsrechten (bzw. berechtigten Personen) zu einem Objekt ist nicht integer oder nicht aktuell. Die nachfolgend zusammengestellten Sicherheitsanforderungen ergänzen die bereits zum Schutz der Verfügbarkeit aufgeführten Anforderungen. Tabelle 29: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Integrität von Autorisierungsdaten ACL.I.01 ACL.I.02 Die Abbildung des Behandlungsvertrags auf Zugriffsrechte muss (für den Patienten) verifizierbar sein. Durch geeignete technische Maßnahmen ist sicherzustellen, dass die Zuordnung eines Objekts zu seinen Zugriffsberechtigungen entweder garantiert integer ist oder aber das Objekt im Fall der Verletzung der Integrität der Zuordnung bzw. der Zugangsrechte nicht abgerufen werden kann ( sicherer Zustand der Zugangsdaten als Voraussetzung für den Objektzugang). 76 Letzte Speicherung des Dokuments: :42:00

244 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Schutzziel Verbindlichkeit Bedrohungen der Authentizität und Nicht-Abstreibtarkeit von Zugangsdaten resultieren aus Schwächen in den Prozessen zur Pflege der Berechtigungen: Zugriffsrechte werden durch eine nicht dazu berechtigte Person vergeben. Die Grundlage der Vergabe eines Zugriffsrechts an eine Person oder Gruppe ist nicht klar bzw. nicht nachvollziehbar. Unter Berücksichtigung dieser Bedrohungen werden zur Erreichung der festgelegten Schutzziele die in der nachfolgenden Tabelle 30 aufgeführten, durch das objektübergreifende Sicherheitskonzept zu ergänzenden Mindestanforderungen an Umsetzungen elektronischer Fallakten gestellt. Tabelle 30: Sicherheitsanforderungen und Umsetzungsvorgaben zur Sicherstellung der Verbindlichkeit von Autorisierungsdaten ACL.A.01 ACL.A.02 Jedes Zugriffsrecht muss auf einen Behandlungsvertrag oder eine andere schriftliche Einwilligung des Patienten zurückführbar sein. Die Authentizität des Behandlungsvertrags muss sichergestellt sein. Es sind klare Regelungen zu treffen, welche Personen Behandlungsverträge anlegen können, wie die Autorisierung der Zugriffsberechtigten einer efa erfolgt und wie der Prozess der Abbildung der Rechte auf technische Systeme stattfindet. 5.7 Technische Systemkomponenten Die oben in ihrem Schutzbedarf und ihren Sicherheitsanforderungen beschriebenen fachlichen Objekte spannen im Wesentlichen die Anwendungsund Sicherheitsarchitektur auf. Dieser funktionale Kern der Architektur wird durch technische Systemkomponenten gekapselt, die Mechanismen zum Zugriff auf Objekte und zur Kommunikation zwischen Diensten bereitstellen. Die wesentlichen technischen Systemkomponenten, deren Schutzniveau direkte Bezüge zu dem realisierbaren Schutz der fachlichen Objekte aufweist, sind in Abbildung 11 dargestellt: Sicherheitskonzept_v100 77

245 die Kommunikationsinfrastruktur, über die Nachrichten zwischen clientseitigen Dienstnutzern und serverseitigen Dienstanbietern ausgetauscht werden der die clientseitigen Dienste kapselnde Proxy (Enabler, Konnektor) sowie ein lokales Netz (LAN, WLAN, etc.) zur Anbindung von Arbeitsplätzen an den Proxy der Netzzugang des Clients bzw. Proxies zur Kommunikationsinfrastruktur die Netzanbindung der serverseitigen Dienste an die Kommunikationsinfrastruktur Infrastruktur- und Managementdienste zur Konfiguration von serverseitigen Diensten und zur Bereitstellung von Domain-unabhängigen Basisdiensten (z. B. Lokalisierung) Ggf. Kartenterminals, über die auf über Smartcards gesicherte Authentisierungstoken von Ärzten und Patienten zugegriffen werden kann Abbildung 11: Technische Systemkomponenten KIS/PVS/Browser Lokales Netz Proxy Clientseitige Dienste (Stubs) Kartenterminal Token für Authentisierung und Identifikation Netzzugang Kommunikationsinfrastruktur Netzanbindung Serverseitige Anwendungsdienste Serverseitige Sicherheitsdienste Infrastrukturdienste Nachfolgend werden für die benannten technischen Systemkomponenten Sicherheitsanforderungen und Umsetzungsvorgaben formuliert, mit denen sichergestellt werden soll, dass das Sicherheitskonzept, das vorwiegend fachliche Konzepte und Dienste adressiert, auch auf technischer Ebene geeignet unterstützt wird. 78 Letzte Speicherung des Dokuments: :42:00

246 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Kommunikationsinfrastruktur Über die Kommunikationsinfrastruktur werden Dienstnutzer und Dienstanbieter physisch und logisch miteinander verbunden. Vertraulichkeit, Integrität und Authentizität in Bezug auf die Kommunikation (Nachrichtenaustausch) kann prinzipiell auf drei Ebenen unabhängig voneinander realisiert werden (siehe Abbildung 12): Auf der Netzwerkebene spannen Geräte auf Basis von gegenseitiger Authentisierung und Autorisierung ein sicheres, abgeschlossenes Netz auf. Sicherheitskontexte decken immer die Kommunikation zwischen zwei Netzwerkknoten ab. Auf der Ebene der Dienste werden durch Authentisierung und Autorisierung von Diensten sichere Kommunikationsverbindungen aufgebaut. Sicherheitskontexte decken die Kommunikation zwischen Diensten ab. Auf der Anwendungsebene authentisieren sich Nutzer (Personen, Organisationen) und werden autorisiert, um auf Daten zugreifen und schutzbedürftige Dienstfunktionalitäten nutzen zu können. Der Sicherheitskontext reicht von dem (berechtigten) Nutzer bzw. einem eine berechtigte Gruppe repräsentierenden System - bis zu den genutzten Daten bzw. Funktionalitäten. Abbildung 12: Ebenen der Authentisierung und Autorisierung Anwendung Funktionalität Daten Transport (Dienste) Dienst Dienst Dienst Dienst Netzwerk (Geräte) Geräte Sicherheitsdienste und -mechanismen der Anwendungsebene sind als Teil der Sicherheitsarchitektur spezifiziert. Sicherheitsdienste und -mechanismen der Transport- und Netzwerkebene sind Kontext der Kommunikationinfrastruktur beschrieben. Sicherheitskonzept_v100 79

247 Prinzipiell sind für alle drei Ebenen die in der folgenden Tabelle 31 zusammengefassten Sicherheitsanforderungen und Umsetzungsvorgaben in Bezug auf den Aufbau sicherer Kommunikationsverbindungen einzuhalten. Tabelle 31: Sicherheitsanforderungen und Umsetzungsvorgaben an die genutzte Kommunikationsinfrastruktur NET.01 NET.02 Bei Nutzung von Verschlüsselung oder Nachrichtenauthentisierung auf einer oder mehrere der dargestellten Ebenen müssen zu jeder semantischen Klasse von kryptografischen Algorithmen 17 mindestens zwei Algorithmen unterstützt werden (Default-Algorithmus und Rückfall-Algorithmus). Jeder Dienstanbieter hat als Teil des Betriebshandbuchs organisatorische und technische Abläufe zu definieren, mit denen der Rückfall-Algorithmus bei einer erkannten Schwäche des Default-Algorithmus aktiviert werden kann. Darüber hinaus sind die Abläufe zum vollständigen Austausch eines der beiden Algorithmen auszuarbeiten. Zwischen zwei Netzwerkknoten oder Diensten genutzte Session-Schlüssel zur Verschlüsselung von Nachrichten dürfen zueinander in keinem Bezug stehen, der ein Erraten oder eine Ableitung möglich macht Netzanbindung der Clients und der Dienste Die Netzanbindung der Clients wird im dezentralen Bereich bei einer direkten Anbindung an den Zugangspunkt über einen Proxy/Konnektor (fat client) bzw. einen Enabler/Plug-In (thin client) realisiert. Alternativ können Clients auch indirekt über einen Proxy angebunden werden, der dann auch ggf. die Authentisierung einer Gruppe übernimmt. In diesem Fall sind die Client- Arbeitsplätze über ein lokales Netz innerhalb des Krankenhauses oder der Arztpraxis mit dem Proxy verbunden. 17 Unter semantischen Klassen von kryptografischen Algorithmen werden in diesem Dokument die in ISIS- MTT Teil 6 [ISISMTT_6-1.1] zur Klassifizierung der Algorithmen genutzten Kategorien verstanden. 80 Letzte Speicherung des Dokuments: :42:00

248 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Für den vom Client bzw. einem zwischengeschalteten Proxy angesprochenen Zugangspunkt innerhalb der Infrastruktur sowie die Anbindung der Dienste an die Infrastruktur gibt es verschiedene Realisierungsoptionen, die auch miteinander kombiniert werden können: 1 Vernetzung der Zugangspunkte und Dienste über Multiplexer und De- Multiplexer (Gateways, Konzentratoren) 2 Nutzung zentraler Broker als Zugangspunkte, an die Clients und Dienste angebunden sind 3 Realisierung der Dienste als Peers, an die Clients direkt angebunden sind, wobei jedem Client ein Peer für den Zugang zu allen Diensten aller Provider fest zugeordnet ist Für die beiden ersten Einführungsphasen der efa wird die dritte Option (Peer- Netz) favorisiert. Da jedoch mit der dritten Einführungsphase ein Aufsetzen der efa auf der Telematikinfrastruktur und den Zugangsdiensten der gematik vorgesehen ist, sollen bei der Lösungskonzeption und -umsetzung die Anforderungen der ersten beiden Modelle perspektivisch berücksichtigt werden. Auch wenn die aktuell konzipierte und implementierte Lösung auf einer direkten Anbindung des Proxies/Enablers an serverseitige Dienste basiert, muss deshalb die Lösung so gestaltet sein, dass eine Migration zu einem Zugang über Gateways und/oder Broker problemlos durchführbar ist. Dies gilt umso mehr, als dass über die Topologie der Anwendungsarchitektur Elemente der beiden erstgenannten Optionen schon für die erste Einführungsphase der efa relevant sein können. Nachfolgend werden zunächst Sicherheitsanforderungen und Umsetzungsvorgaben formuliert, die für alle drei Optionen der Anbindung von Clients und Diensten gleichermaßen relevant sind. Anschließend wird auf Besonderheiten der einzelnen Topologien und die daraus resultierenden Anforderungen an die letzte Meile eingegangen. Tabelle 32: Sicherheitsanforderungen und Umsetzungsvorgaben an die Netzanbindung der Clients und Dienste CON.01 CON.02 Gemäß den Vorgaben der Projekte zur Einführung der egk wird eine reine Pull-Semantik verfolgt, d. h. es gibt keine Initiierung von Nachrichten an Clients durch serverseitige Dienste. Die Anbindung der Clients hat sicherzustellen, dass von einem Dienst kommende Nachrichten, die keine Antwort auf eine vom Client gesendete Anfrage sind, abgeblockt und nicht an den Client weitergeleitet werden. Alle Endpunkte der Client- und Dienstanbindung sind durch Sicherheitsgateways (Firewalls) zu sichern. Sicherheitskonzept_v100 81

249 CON.03 CON.04 CON.05 CON.06 CON.07 CON.08 Auf allen Endpunkten der Dienstanbindung sind Mechanismen zur Intrusion Detection umzusetzen. Prozesse zur Auswertung von potenziellen Angriffen und zur Einleitung von Gegenmaßnahmen sind als Bestandteil der Betriebs- und Sicherheitshandbücher zu definieren. Zu schützende Informationen werden nur in verschlüsselter Form durch die serverseitigen Komponenten der Netzanbindung (Gateways, Broker) geleitet. Beim Verbindungsaufbau zu einem Zugangspunkt findet eine gegenseitige Authentisierung der beiden Endpunkte statt. D. h. die Anbindung eines Clients, Proxies bzw. Dienstes an einen Zugangspunkt erfordert eine Registrierung oder sonstige Form der Bekanntgabe dieses Clients, Proxies bzw. Dienstes an dem Zugangspunkt (Gateway, Broker, etc.). Bei Anbindung der Clients über ein lokales Netz im Krankenhaus oder der Arztpraxis muss die Verbindung zwischen Client und Proxy alle Sicherheitsanforderungen der Verbindung vom Proxy zum Zugangspunkt erfüllen. Bei der Nutzung eines lokalen Proxies zur Gruppenauthentisierung wird eine Ende-zu-Ende-Verbindung zwischen Proxy und Datenspeichern aufgebaut, die alle Sicherheitserfordernisse der Ende-zu-Ende-Verbindung zwischen Client und Datenspeicher bei einer direkten Anbindung des Clients erfüllen muss. Bei der Nutzung eines lokalen Proxies zur Gruppenauthentisierung muss sich der Zugreifer über das lokale Netz gegenüber dem Proxy authentisieren. Zwischen Proxy und Client muss eine sichere Anbindung hergestellt werden, die alle Sicherheitskriterien der Verbindung zwischen Proxy und serverseitigen Diensten erfüllt. Eine Umschlüsselung auf dem Proxy ist zulässig, sofern diese komplett im Arbeitsspeicher durchgeführt wird und der Zugang zu dem Proxy nur für Mitglieder der berechtigten Gruppe und andere berechtigte Personen möglich ist Anbindung über Gateways Clients sind in diesem Modell an sog. Gateways angebunden, die als Konzentratoren fungieren. Dienste sind ebenfalls an Gateways (in den 82 Letzte Speicherung des Dokuments: :42:00

250 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Dokumenten der gematik auch als reverse connectors bezeichnet) angebunden, die als Mediatoren für ankommende Anfragen fungieren. Die Dienstlokalisierung erfolgt lokal, die Gateways dienen lediglich der Dienstvermittlung. Abbildung 13: Anbindung von Clients und Diensten über Gateways client client client client client client gateway gateway gateway Dienst Dienst Dienst Die nachfolgend aufgeführten Sicherheitsanforderungen und Umsetzungsvorgaben sind für die ersten Phasen der efa-einführung nicht relevant, müssen jedoch potenziell beim Übergang in die dritte Phase umgesetzt werden. Tabelle 33: Sicherheitsanforderungen und Umsetzungsvorgaben an die Netzanbindung über Gateways CON.GWY.01 Für Sicherheitsmechanismen von der Transportebene an aufwärts sind die Gateways unsichtbar, d. h. Authentisierung, Autorisierung, Integritätssicherung und Verschlüsselung finden von Ende zu Ende zwischen Client und Dienst statt. CON.GWY.02 Integrität und Authentizität eines Gateways müssen für jede daran angebundene Komponente (Client, Dienst, anderes Gateway) überprüfbar sein. CON.GWY.03 Die Gateways bilden untereinander auf der Netzwerkebene ein sicheres, abgeschlossenes Netz (VPN). CON.GWY.04 Gateways leiten Anfragen weiter. Sie speichern keine Daten und schreiben keine Protokolle Anbindung über Broker Anstelle von Gateways können auch Broker zur Anbindung der Clients eingesetzt werden. Die Broker fungieren nicht nur als Konzentratoren, sondern führen neben einer Ablaufsteuerung sowohl Dienstlokalisierung als auch Sicherheitskonzept_v100 83

251 Dienstvermittlung durch. Im Gegensatz zu Gateways sind Broker aufgrund ihrer angebotenen Funktionalität auch auf der Anwendungsebene sichtbar. Broker können bei der Anbindung von thin clients durch Portale gekapselt werden. Abbildung 14: Anbindung von Clients und Diensten über Broker (Mediatoren) client client client client client client broker broker Dienst Dienst Dienst Die nachfolgend aufgeführten Sicherheitsanforderungen und Umsetzungsvorgaben sind abhängig von der Anwendungsarchitektur potenziell bereits für die ersten Phasen der efa-einführung relevant, da Broker in einem Peer-to-Peer Netzwerk als Peers fungieren können, die das Routing von Aufrufen sowohl an lokale als auch an entfernte Dienste übernehmen. Tabelle 34: Sicherheitsanforderungen und Umsetzungsvorgaben an die Netzanbindung über Broker CON.BRK.01 Broker werden grundsätzlich als nicht zugangsberechtigt zu personenbezogenen medizinischen Objekten und Informationen angesehen. Es sind daher Möglichkeiten zu schaffen, die eine direkte Kommunikation zwischen Client und Dienst unter (logischer) Ausblendung des Brokers erlauben. COM.BRK.02 Bei der Konzeption der Anwendungsarchitektur sind Broker als man in the middle zu sehen. D. h. es sind Mechansimen vorzusehen, die verhindern, dass ein Broker einem Dienst einen falschen Client bzw. einem Client einen falschen Dienst vortäuscht. CON.BRK.03 Clients und Dienste sind über sichere Verbindungen (Netzwerk- und/oder Transportebene) an Broker angebunden. CON.BRK.04 Ein Broker kann sich gegenüber Clients und Diensten authentisieren. Die dazu genutzten Zertifikate können von Clients und Diensten verifiziert werden. 84 Letzte Speicherung des Dokuments: :42:00

252 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Anbindung der Clients an ein Peer-to-Peer-Dienstenetz Als dritte Option können Dienste nach einem Peer-to-Peer-Paradigma untereinander vernetzt werden. Clients sind fest an eine Dienstinstanz gebunden, d. h. die Dienstlokalisierung ist statisch, während die Dienstvermittlung dynamisch durch die Dienste selbst übernommen wird. Die zum Zugang genutzten Dienste können in diesem Modell bei der Anbindung von thin clients durch Portale gekapselt werden. Abbildung 15: Anbindung von Clients an ein Peer-to-Peer-Netz bildende Dienste client client client client client client Dienst P2P Dienst Dienst client client client Die nachfolgend aufgeführten Sicherheitsanforderungen und Umsetzungsvorgaben an die Netzanbindung der Clients sind in Ergänzung zu den oben aufgeführten generellen Maßnahmen für die beiden ersten Phasen der efa- Einführung zu beachten. Tabelle 35: Sicherheitsanforderungen und Umsetzungsvorgaben an die Netzanbindung der Clients (Phase 1 und 2) CON.P2P.01 Die Peers bilden untereinander ein sicheres, abgeschlossenes Netz. Alle Kommunikationsstrecken innerhalb dieses Netzes werden nur nach vorheriger gegenseitiger Authentisierung der beteiligten Dienste aufgebaut. CON.P2P.02 Sämtlicher Daten- und Nachrichtenaustausch zwischen Peers ist verschlüsselt und integritätsgesichert und erfolgt ausschließlich zwischen gegenseitig authentisierten Diensten. CON.P2P.03 Es wird davon ausgegangen, dass beim Lesen und Schreiben von medizinischen Daten diese über Peers geroutet werden, deren Betreiber nicht berechtigt ist, diese Daten zu lesen. Aus diesem Grund sind Mechanismen vorzusehen, die eine direkte Kommunikation zwischen Clients und Diensten unter (logischer) Ausblendung des Peer-to-Peer-Netzwerks erlauben. CON.P2P.04 Die für das Routing von Anfragen durch das Netz zuständigen Sicherheitskonzept_v100 85

253 Dienste eines Peers speichern keine Daten und schreiben keine Protokolle Infrastruktur- und Management-Dienste Gemäß den projektspezifischen Anforderungen sind zentrale Dienste zu vermeiden, da diese zentralisierte Betreibermodelle erfordern und potenziell hohe Anforderungen an Verfügbarkeit, Performanz und Durchsatz stellen. Dennoch kann an verschiedenen Stellen die Nutzung von (zentralisierten) Infrastruktur- und Managementdiensten sinnvoll sein, wie z. B. zur Erzeugung von (Wurzeln für) ISO-OIDs 18 und zur Verteilung bzw. Abfrage von Lokalisierungsinformationen. Diese Dienste sollten jedoch von den Anwendungs- und Sicherheitsdiensten soweit wie möglich entkoppelt werden, um das durch jede zusätzliche Schnittstelle und Funktionalität erhöhte Bedrohungspotenzial zu minimieren und die Komplexität der Gesamtarchitektur in Bezug auf Kontrollflüsse und Schnittstellen so gering wie möglich zu halten. Die nachfolgend aufgeführten Sicherheitsanforderungen und Umsetzungsvorgaben sind für die Implementierungen und Anbindung jeglicher Infrastruktur- und Managementdienste zu berücksichtigen. Spezielle Sicherheitsvorgaben zu einzelnen Diensten werden als Teil der Spezifikation dieser Dienste ausgeführt. Tabelle 36: Sicherheitsanforderungen und Umsetzungsvorgaben zu Infrastruktur- und Managementdiensten INFSRV.01 Clients kommunizieren ausschließlich mit Sicherheits- und Anwendungsdiensten. Es existiert daher keine (direkte) Anbindung der Clients an Infrastruktur- oder Managementdienste. INFSRV.02 Infrastruktur- und Managementdienste sind nicht an das (logische) Kommunikationsnetz angebunden, über das Dienste untereinander bzw. Clients mit Diensten kommunizieren. 18 Ob Objekt-IDs zentral erzeugt werden müssen oder von jedem Träger für die bei ihm eingestellten Objekte selbst erzeugt werden können, hängt letzten Endes davon ab, ob sichergestellt werden kann, dass sich durch für Unberechtigte sichtbare OIDs keine Beziehung zwischen einem Patienten und der ihn behandelnden Abteilung eines Krankenhaus herstellen lässt. 86 Letzte Speicherung des Dokuments: :42:00

254 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben INFSRV.03 Infrastruktur- und Managementdienste sind über (logische) Punkt-zu-Punkt-Verbindungen mit Diensten verbunden. INFSRV.04 Die Kommunikation von Sicherheits- und Anwendungsdiensten mit Infrastruktur- und Management- Diensten erfolgt immer nach dem Pull-Paradigma. Die Einhaltung dieser Vorgaben ist durch geeignete Mechanismen der Anbindung sicherzustellen. INFSRV.05 Wenn ein Infrastruktur- oder Managementdienst eine Kommunikation initiieren oder auf Daten eines Anwendungsdienstes zugreifen muss, so sind geeignete Mechanismen der Entkopplung der hierzu genutzten Daten bzw. Pull-Schnittstellen von den Anwendungsdiensten zu realisieren (z. B. Transfer-Datenbanken). INFSRV.06 Anwendungs- und Sicherheitsdienste besitzen spezielle, über Firewalls gesicherte, Schnittstellen zur Kommunikation mit Infrastruktur- und Managementdiensten. Diese Schnittstellen sind unabhängig von den Schnittstellen zur Kommunikation mit Clients und anderen Anwendungs- und Sicherheitsdiensten. INFSRV.07 Es sind immer Lösungen vorzuziehen, die zentrale (oder auch verteilte) Infrastruktur- und Managementdienste vermeiden, auf die von anderen Diensten direkt zugegriffen werden muss Kartenterminals Kartenterminals stellen eine sichere Betriebsumgebung für zur Authentisierung von medizinischem Personal genutzte SmartCards dar. Sie geben von der Anwendung ausgelöste Kommandos an die Karten weiter bzw. stellen eigene Funktionen bereit, die auf Kommandos der Karten abgebildet werden. Für die Nutzung der efa sollten ausschließlich Kartenterminals neu angeschafft und installiert werden, die den Vorgaben der gematik entsprechen (sog. ehealth-terminals). Bis zur Freigabe der entsprechenden Spezifikation durch die gematik können existierende Kartenterminals zumindest in der ersten Einführungsphase der efa genutzt werden, sofern diese den nachfolgend skizzierten Anforderungen entsprechen. Sicherheitskonzept_v100 87

255 Tabelle 37: Sicherheitsanforderungen und Umsetzungsvorgaben an die genutzten Kartenleser KT.01 KT.02 KT.03 KT.04 KT.05 KT.06 KT.07 KT.08 KT.09 Die Kartenterminals müssen ein sicheres Update der Firmware erlauben, sofern diese Funktionalität angeboten wird. Zur Freigabe von privaten Schlüsseln muss eine sichere PIN- Eingabe möglich sein. Die hierzu genutzten Key-Pads müssen entweder in den Leser integriert sein oder sicher an den Leser angebunden sein. Das Kartenterminal speichert keine PINs. Das Kartenterminal sendet an eine registrierte Anwendung asynchron eine Benachrichtigung, wenn die Karte gezogen wird. Kartenterminals können durch eine eindeutige Kennung oder einen vergleichbaren Mechanismus eindeutig identifiziert werden. Es ist technisch eine eindeutige Zuordnung von einem Kartenterminal zu einem Terminal/PC herzustellen. Dies kann entweder durch eine direkte Anbindung oder eine entsprechende Verkabelung erfolgen. Die Zuordnung muss für den Nutzer klar erkennbar sein. Medizinische Daten gehen nicht über die Kartenterminals, d. h. auch zur Signatur von Daten wird ausschließlich der Digest an das Kartenterminal und die dort gesteckte Karte geschickt. Eine Integritätssicherung auf der Verbindung zum Kartenterminal ist durch geeignete technische Maßnahmen sicherzustellen. Falls ein Kartenterminal über Ethernet an die Infrastruktur angebunden ist, muss eine sichere Ende-zu-Ende- Verbindung zum Terminal/PC aufgebaut werden (z. B. durch Nutzung von SSL/TLS [RFC_4346]). Mit der Ausgabe einer Authentisierungskarte an eine Person hat der Kartenherausgeber dafür Sorge zu tragen, dass diese Person mit der Nutzung von Kartenlesern und dem sicheren Umgang mit Karte und PIN vertraut ist. 88 Letzte Speicherung des Dokuments: :42:00

256 Objektbezogene Sicherheitsanforderungen und Umsetzungsvorgaben Sicherheitskonzept_v100 89

257 6 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Die in Kapitel 5 dargestellten objektbezogenen Sicherheitsanforderungen und Umsetzungsvorgaben adressieren vorwiegend einzelne Bedrohungen und Schutzziele. Sie sind isoliert für einzelne Systemkomponenten anwendbar und besitzen kaum gegenseitige Abhängigkeiten. In diesem Kapitel werden diese Einzelmaßnahmen durch ein ganzheitlich angelegtes Sicherheitskonzept ergänzt bzw. in dieses eingebunden. Der Anspruch an das Sicherheitskonzept ist es, objekt- und schutzzielübergreifende organisatorische, technische und architektonische Schutzkonzepte zu definieren, aus denen sich konkrete Sicherheitsdienste und Sicherheitsmechanismen ableiten lassen (siehe Abbildung 16). Abbildung 16: Einordnung des Sicherheitskonzepts in das Dokument Anforderungen Rechtsgrundlagen Anforderungen an efa und epa Projektspez. Anforderungen Rechtssicherheit Methodische Basis Schutzziele Schutzbedarfe Bedrohungen Konzeptionelles Modell Sicherheitsanalyse Schutzbedarfsanalyse Objektbezogene Sicherheitsvorgaben Sicherheits strategie und Sicherheitskonzept Organisatorische Konzepte Architektur-Konzepte Technische Konzepte Sicherheitsarchitektur Das Sicherheitskonzept hat durch seine ganzheitliche Ausgestaltung eine strategische Komponente, d. h. es basiert auf einigen wenigen Grundüberlegungen, die wiederum direkt aus den Schutzbedarfen und den fachlichen Anforderungen abgeleitet sind. Für die Umsetzung elektronischer 90 Letzte Speicherung des Dokuments: :42:00

258 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Fallakten bilden die nachfolgend aufgeführten Festlegungen den roten Faden zu allen konstruktiven Arbeiten im Bereich Datenschutz und Datensicherheit: 1. Es wird ein auf Personen und Gruppen (Identitäten) basierendes, einzelne Objekte adressierendes Berechtigungskonzept umgesetzt. Berechtigungen sind an die zu schützenden Objekte (d. h. die Fallakten) geknüpft. Autorisierungen können durch Instantiierung von Schablonen über Identitätsdaten überprüft werden. 2. Wenn Schutzziele mit technischen Maßnahmen nicht vollständig erreichbar sind, werden Nutzungsbeschränkungen der efa festgelegt, die entweder die kritischen Anwendungsfälle komplett aus der Nutzung herausnehmen oder aber eine geeignete Zusammenführung von organisatorischen und technischen Maßnahmen bei gleichzeitiger Einschränkung der Nutzungsspielräume erlauben, über die das geforderte Schutzniveau erreichbar ist. 3. In die Kontroll- und Datenflüsse werden gestufte Verteidigungslinien eingezogen. Diese bilden die Basis der Ausgestaltung von Sicherheitszonen. 4. Der Schutz der Vertraulichkeit patientenbezogener Informationen wird durch Pseudonymisierung des Patienten in den Abläufen innerhalb der Infrastruktur realisiert. Das bedeutet, dass aus den Meta- und Berechtigungsdaten sowie den verschickten Nachrichten heraus keine Beziehung zwischen einem Datenobjekt bzw. einer efa und einem Patienten hergestellt werden kann. 5. Bei den technischen Maßnahmen zur Sicherung der Integrität einer efa wird den Beziehungen zwischen Objekten (z. B. der Zuordnung eines Datenobjekts zu einer efa) eine besondere Bedeutung beigemessen. Die Integrität wird entlang der Pfade des Objekt- und des Navigationsmodells durchgängig sichergestellt. Diese fünf Grundpfeiler ( Sicherheitsstrategie ) bilden die Basis des Sicherheitskonzepts, das in der nachfolgenden Darstellung in organisatorische, architektonische und technische Konzepte gegliedert ist. Aufgrund der besonderen Bedeutung für die gesamte Konzeption von Sicherheitsmaßnahmen wird jedoch zunächst das gewählte Berechtigungsmodell motiviert und dargestellt. 6.1 Berechtigungsmodell Mit seiner Einwilligung zum Anlegen einer efa ermächtigt der Patient den im zugrunde liegenden Behandlungsvertrag benannten Kreis von Personen und Sicherheitskonzept_v100 91

259 Einrichtungen, im Kontext der Behandlung auf die in der efa verfügbaren Daten zuzugreifen. Beim Zugriff auf Daten einer efa sind somit zwei Einschränkungen in Bezug auf die Zugriffsberechtigten sicherzustellen: Nur die im Behandlungsvertrag vom Patienten ermächtigten Personen sowie die Mitglieder der ermächtigten Gruppen (Einrichtungen, Rollen, etc.) dürfen auf die Daten zugreifen und neue Dokumente in eine efa einstellen. Der Zugriff auf die Daten der efa ist diesen Personen nur im Kontext der Behandlung erlaubt (Zweckbindung). Die Einhaltung der festgelegten Zugriffsbeschränkungen muss über geeignete technische und/oder organisatorische Maßnahmen gewährleistet werden. Hierzu existieren verschiedene Konzepte, von denen die im Umfeld von efa und epa grundsätzlich realisierbaren Modelle nachfolgend im Überblick skizziert werden Kodierung von Berechtigungen Die Kodierung von Berechtigungen erfolgt direkt oder indirekt über Aussagen, die anhand von Identitäts- und/oder Kontextinformationen verifiziert werden können. Die nachfolgend vorgenommene Differenzierung der Kodierung von Berechtigungen leitet sich aus dem Schema dieser Aussagen ab Rollen, Szenarien, Objektklassen Bei der Kodierung von Berechtigungen haben die im System hinterlegten und bei jedem Objektzugriff zu prüfenden Aussagen die Form: Ein [Rolle] darf im [Szenario/Kontext] ein [Objektklasse] [lesen/ersetzen/ ] Beispiele für solche über Rollen und Szenarien kodierte Aussagen sind: Ein Chirurg darf im Rahmen der OP-Vorbereitung ein Röntgenbild lesen. Ein Labor-Assistent darf die Auswertung einer übermittelten Zellkultur in eine Akte einstellen. Die Berechtigungskodierung über Rollen und Szenarien wird in HL7 empfohlen (HL7 role engineering [HL7_rbac-1.1]). Die Kodierung der Aussagen kann in Form von Tabellen erfolgen, die an den Dokumentenflüssen innerhalb einer Behandlung ausgerichtet sind. Die nachfolgende Abbildung aus [HL7_rbac_ex- 1.1] stellt eine solche Tabelle dar. 92 Letzte Speicherung des Dokuments: :42:00

260 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Abbildung 17: Beispiel für HL7 Role Engineering Der Vorteil eines solchen Berechtigungskonzepts ist, dass Berechtigungen unabhängig von konkreten Personen und Objekten kodiert werden können und (im Idealfall) allgemeingültig sind. Sofern das Berechtigungsmodell durch den Behandlungsvertrag vom Patienten rechtlich abgesichert ist, müssen deshalb beim Anlegen einer neuen efa oder beim Einstellen eines Dokuments in eine epa keinerlei objektbezogene Berechtigungen kodiert werden. Zur Umsetzung eines rollen- und kontextbasierten Berechtigungskonzepts sind jedoch detaillierte und verifizierbare Angaben zur Rolle des Zugreifers, zum aktuellen Szenario und zur Klassifizierung des genutzten Dokuments erforderlich. Jede Einrichtung wird dabei Rollen und Rechte anhand der eigenen, internen Abläufe festlegen, was eine Nutzung in einrichtungs- und sektorübergreifenden Szenarien sehr schwierig macht. Zur Autorisierung von Zugriffen müssen die einzelnen Regeln ausgewertet werden. Dies erfordert, dass die Authentisierung des Zugreifers nicht nur dessen Rolle, sondern auch eine Feststellung des Ablaufsschritts bzw. Prozesszustands beinhaltet. Da die hierzu notwendige einrichtungsübergreifend kompatible Workflow- Unterstützung von den aktuell genutzten IT-Systemen der Krankenhäuser nicht geleistet wird, ist ein rollen- und kontextbasiertes Berechtigungsmodell für die efa zwar sinnvoll, aber nicht umsetzbar. Eine Umsetzung für die epa widerspricht den Vorgaben des 291a SGB V, in dem eine Autorisierung von Personen auf Ebene einzelner Objekte vorgesehen ist. Sicherheitskonzept_v100 93

261 egk-ticketverfahren In der egk-lösungsarchitektur des FuE-Projekts [FUE_SLA-1.0] wird für die Autorisierung des Zugriffs auf medizinische Daten ein sog. Ticket-Verfahren vorgeschlagen. Das Ticket-Verfahren basiert auf einem Challenge-Response- Mechanismus, über den der Zugreifende den Besitz eines zum Datenzugriff autorisierten Schlüssels nachweist. Eine Identifizierung des Zugreifenden ist optional und dient vor allem dem Nachweis einer Rollenzugehörigkeit. Bei dem Ticketverfahren ist jedem Objekt ein Ticket zugeordnet, dass von autorisierten Personen aus einem vom Server abrufbaren sog. Ticket-Toolkit erzeugt werden kann. Der Besitz eines gültigen Tickets berechtigt zum Zugriff auf das damit geschützte Objekt. Aussagen zu Berechtigungen innerhalb des Ticket-Verfahrens haben damit die Form: Mit dem passenden Ticket darf [Rolle] [Objekt] [lesen/aktualisieren/ ] Beispiele für Aussagen dieser Form sind: Mit dem passenden Ticket darf ein Arzt das Objekt aktualisieren. Mit dem passenden Ticket darf von einem ekiosk aus die ACL des Objekts verändert werden. Tickets sind immer an eine Karte gebunden, d. h. zu jedem Ticket-Tookit existiert genau eine Karte, mit der aus dem Toolkit ein gültiges Ticket erzeugt werden kann. Eine Berechtigungsweitergabe ist nicht möglich. Tickets machen vor allem für anonyme Zugriffe über eine egk Sinn, da der Patient beim Datenzugriff auf dem Server nicht authentisiert werden muss und damit anonym bleibt. Weder Ticket-Toolkits noch Tickets enthalten einen Patientenbezug, weshalb sich mit dem Ticketverfahren die Vorgaben des 291a SGB V und des Datenschutzes zur Nutzung freiwilliger Anwendungen vollständig umsetzen lassen. Durch den starken Bezug des Ticketverfahrens zu Karten bzw. Schlüsseln ist eine Nutzung dieses Konzepts für Zugriffe auf Daten einer efa nicht zu empfehlen. Gründe hierfür sind neben der aktuellen Nicht-Verfügbarkeit entsprechender Karten für die Patienten vor allem die Schwierigkeiten bei der Abbildung von Rechten für Gruppen (Einrichtungen, Fachrichtungen, etc.), da diese i. A. entweder keinen eigenen Schlüssel besitzen oder aber ein Zugang aller Mitglieder der Gruppe zu diesem Schlüssel nicht operationalisierbar ist. Aufgrund der hohen Konformität zu den Datenschutzvorgaben zur Nutzung medizinischer Daten im Kontext freiwilliger Anwendungen bietet sich bei Verfügbarkeit der egk jedoch eine Realisierung des Zugriffschutzes der epa über das Ticketverfahren an. Es ist daher sicherzustellen, dass eine Kapselung 94 Letzte Speicherung des Dokuments: :42:00

262 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen der in einer efa verwalteten Daten über eine auf dem Ticketverfahren basierende epa möglich ist Identitäten und Regeln Bei der Kodierung von Zugriffsrechten über Regeln wird die Annahme zugrunde gelegt, dass jede zugreifende Person über ihre eigene Identität und (potenziell daraus abgeleitete) Gruppenzugehörigkeiten beschrieben werden kann. Individuen und Gruppenzugehörigkeiten bilden die Basis der beim Objektzugriff zu verifizierenden Zugangsregeln: [Zugangsregel] darf das [Objekt] [Zugriff: CRUDE]. Die Autorisierung eines Zugriffs erfolgt durch Instantiierung der Regeln mit den Identitätsdaten der zugreifenden Person. Beispiele für einfache und komplexe, durch Personen und/oder Gruppen instanziierbare Zugangsregeln sind: Dr. Meier darf das Röntgenbild lesen. Jeder Arzt des Krankenhauses Neukölln darf die Daten im Ordner EKG der epa abc lesen. Jeder Mitarbeiter der gleichen Einrichtung wie Dr. Meier, der eine Ausbildung als Chirurg hat, darf ein Dokument in die Mappe xyz einstellen. Die Berechtigungskodierung über Personen und Objekte kommt den Vorgaben von 291a SGB V und Datenschutz sehr nahe. Insbesondere lassen sich hiermit sowohl Berechtigungskonzepte mit Opt-Out (es wird definiert, wer nicht zugreifen darf) als auch mit Opt-In (es wird definiert, wer zugreifen darf) realisieren und kombinieren. Die Nachteile dieses Verfahren sind, dass die Berechtigungsschemata für jede efa bzw. jedes Objekt einer epa definiert werden müssen. Darüber müssen durch die Kombinierbarkeit von Gruppenzugehörigkeiten bei jedem Zugriff potenziell mehrere Regeln instantiiert, verifiziert und im Fall mehrerer Treffer gegeneinander gewichtet werden. Trotz dieser Nachteile wurde in der Diskussion mit Vertretern der Krankenhäuser festgestellt, dass ein auf Zugangsregeln basierendes Berechtigungskonzept grundsätzlich einen sehr guten Kompromiss zwischen den gegebenen Anforderungen und den Beschränkungen der gegebenen Rahmenbedingungen darstellt. Insbesondere wird eine Umsetzung und Operationalisierung als mit vertretbarem Aufwand leistbar angesehen. Sicherheitskonzept_v100 95

263 6.1.2 Vorgaben für das Berechtigungskonzept elektronischer Fallakten Zugriffsrechte auf eine efa werden über ein auf Regeln basierendes Berechtigungskonzept abgebildet, wobei Regeln ausschließlich über Identitätsinformationen definiert sind. Gründe für diese Entscheidung sind die Nähe zu den stark objekt- und personenbezogenen Schutzkonzepten des 291a SGB V und vor allem die Möglichkeiten der Umsetzung von Gruppenrechten (z. B. Berechtigung für alle in eine Behandlung einbezogene Mitarbeiter einer Einrichtung). Die nachfolgende Tabelle 38 stellt die einzelnen Bausteine von Berechtigungen über Personen und Gruppen dar, aus denen Zugriffsregeln gebildet werden können: Tabelle 38: Personen und Gruppen als Basis der Erteilung von Berechtigungen Baustein Individuum Organisation Organisationseinheit Funktion Beschreibung Der Patient berechtigt explizit einen Arzt zum Zugriff. Der Patient berechtigt alle Mitglieder einer Organisation zum Zugriff. Beispiele für Organisationen sind Krankenhäuser, Gemeinschaftspraxen, MVZ und Polykliniken. Der Patient berechtigt in Ergänzung zu einer Organisation alle einer Untereinheit dieser Organisation zugehörigen Personen zum Datenzugriff. Bespiele für Organisationseinheiten sind Stationen, Administration, Aufnahme und Abteilungen, wodurch auch eine Berechtigung von Fachrichtungen ermöglicht wird (z. B. Kardiologie). Der Patient berechtigt in Ergänzung zu einer Organisationsangabe alle Inhaber einer Funktion (medizinisches, administratives oder pflegerisches Personal) zum Datenzugriff. Organisations-, Einheits- und Funktionsberechtigungen können konjunktiv verknüpft werden; z. B. kann festgelegt werden, dass der Zugriff auf eine efa nur für Mitarbeiter der Kardiologie eines bestimmten Krankenhauses möglich ist. Beispiel: Für eine Fallakte sollen ein Arzt als Person, die Mitarbeiter einer Klinik sowie die Spezialisten einer Uni-Klinik zum Datenzugriff berechtigt sein. Dies lässt sich durch die folgende Zugangsregel ausdrücken: (Individuum = Dr. Meier ) ODER (Individuum = Dr. Müller ) ODER (Organisation = Schlosspark-Klinik ) ODER (Organisation = Uni-Klinik Bonn UND Organisationseinheit = Kardiologe ) 96 Letzte Speicherung des Dokuments: :42:00

264 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Jede Person, die diese Bedingung erfüllt d. h. bei der sich durch Instantiierung der Regel mit den Identitätsdaten eine wahre Aussage ergibt gilt als zugangsberechtigt für die Dokumente der efa. Für die beiden ersten Phasen der efa-einführung ist lediglich die Unterstützung der Bausteine Individuum und Organisation verpflichtend. Ob weitere Bausteine benötigt werden, ist offen. Aus den bislang durchgeführten Untersuchungen zu der Ausgestaltung von Behandlungs- und IV-Verträgen ergibt sich kein entsprechender Bedarf Sicherstellung des Behandlungskontexts Über Schablonen kann seitens der technischen Realisierung der efa lediglich die Einhaltung der ersten der beiden eingangs genannten Einschränkungen (Personenkreis) sichergestellt werden. Eine Verifizierung, ob ein Zugriff einer zum berechtigten Personenkreis gehörenden Person im Kontext der Behandlung erfolgt, ist mit technischen Mitteln nicht möglich. Durch Eingrenzung der Zugangsberechtigungen auf die behandelnden Organisationseinheiten (Abteilungen) lässt sich der Kreis der potenziell ohne Behandlungskontext Zugreifenden allerdings erheblich einschränken. Es ist Aufgabe des eine efa nutzenden Trägers, die Einhaltung der zweiten Einschränkung (Zweckbindung) mit organisatorischen Maßnahmen zu unterstützen, die Nachweisbarkeit der erfolgten Zugriffe gegenüber dem Datenschutz und dem Patienten sicherzustellen (Protokollierung) sowie unberechtigt zugreifende Personen zu identifizieren und Sanktionen gegen sie zu verhängen. Die so zu realisierende Kombination aus technischen und organisatorischen Maßnahmen entspricht den aktuellen Regelungen für den Zugriff auf Daten in einem krankenhaus-internen KIS oder DMS Vertreterregelungen Vertretungsregelungen zwischen Ärzten müssen durch das Berechtigungskonzept abbildbar sein, d. h. ein Arzt muss einen Vertreter benennen können, der im Fall der Abwesenheit seine Rolle und damit auch seine Zugriffsberechtigungen auf eine efa übernimmt. Hierbei sollte zwischen zwei Formen der Vertretung unterschieden werden: Einerseits gibt es die klassische Stellvertretung i.s.d. 164 ff. BGB. Willenserklärungen, die in diesem Rahmen ein Vertreter innerhalb der ihm zustehenden Vertretungsmacht im Namen des Vertretenen abgibt, wirken unmittelbar nur für und gegen den Vertretenen. Der Vertreter selbst wird durch Sicherheitskonzept_v100 97

265 seine Erklärungen grundsätzlich nicht gebunden; sie»gehen durch ihn hindurch«und binden lediglich den Vertretenen. Beispiel: Der Behandlungsvertrag kommt zwischen dem vertretenen Arzt (Praxisinhaber) und dem Patienten zustande, auch wenn der Praxisvertreter die Willenserklärung abgibt. Daneben bestehen Besonderheiten bei der Praxisvertretung. Wer als Arzt für einen anderen Arzt im Rahmen einer Praxisvertretung tätig wird, steht zwar dem Praxisinhaber als Geschäftsherrn gegenüber, muss aber trotzdem im Einzelfall die Behandlung eines Patienten nach eigener Entschließung und aus eigener ärztlicher Kenntnis vornehmen. Zwar bewegt sich der Praxisvertreter im Rechtsraum des Praxisinhabers (Vertretenen), er fungiert aber daneben selbst in seiner (eigenen) Funktion als Arzt und handelt in diesem Kontext in eigener Verantwortung und haftet auch dem Patienten gegenüber deliktisch (nicht vertraglich!). Bei einer echten Gemeinschaftspraxis als gemeinsame Ausübung der ärztlichen Tätigkeit kommt der Behandlungsvertrag zwischen dem Patienten und sämtlichen Ärzten der Gemeinschaftspraxis zustande, die insoweit»vertretungsmäßig«ohne weiteres frei austauschbar sind, da hier die Gemeinschaftspraxis als solche agiert. Anderes gilt bei der bloßen Praxisgemeinschaft, in welcher sich mehrere Ärzte (als getrennt handelnde Rechtspersonen) lediglich aus organisatorischen Gründen zusammengeschlossen haben. Bei der Integration von Vertreterrechten in das Berechtigungskonzept muss daher unterschieden werden, in welcher rechtlichen Organisationsform die Beteiligten auftreten. Handelt jeder rechtlich nur für sich, bedarf es einer individuellen Ermächtigung zur Einsicht in die efa; ansonsten genügt die Ermächtigung gegenüber der Organisationseinheit. In Kliniken ist die Vertretung unproblematisch, da dort immer die Einrichtung als Vertragspartner des Behandlungsvertrages berechtigt wird 19. Auch im ambulanten Bereich wird in den existierenden Behandlungs- und IV-Verträgen häufig nicht eine Person, sondern eine Einrichtung berechtigt. Dies kann bei dem vorgeschlagenen Berechtigungskonzept über die Vergabe einer Berechtigung an die (Mitarbeiter einer) Organisation umgesetzt werden. Die Stellung MVZ ist im Innenverhältnis komplexer, da diese nach 95 SGB V in allen zulässigen Organisationsformen existieren können und oft eine 19 Dies gilt auch für die sog. wahlärztlichen Leistungen der liquidationsberechtigten Chefärzte, da auch diese Leistungen gem. 17 KHEntgG Krankenhausleistungen sind. 98 Letzte Speicherung des Dokuments: :42:00

266 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Mischform aus Gemeinschaftspraxis und Praxisgemeinschaft darstellen. Hier muss individuell auf das Gründungsdokument des MVZ Bezug genommen werden, um die Rechtsform des Außenauftritts in Erfahrung zu bringen. Um alle denkbaren Vertreterkonstellationen gleichartig umzusetzen, wird empfohlen, Berechtigungen auch im ambulanten Bereich immer an Einrichtungen zu vergeben. Hierbei ist die Möglichkeit zu schaffen, Ärzte temporär und zeitlich befristet als Mitarbeiter einer Einrichtung zu registrieren. Falls eine Berechtigungserteilung für eine einzelne Person unumgänglich ist, sind je nach Grundlage einer Vertretung beide skizzierten Varianten technisch umzusetzen: der Vertreter wird vom Patienten explizit zum efa-zugriff ermächtigt und erhält entsprechende, zeitlich befristete Zugangsrechte der vertretene Arzt registriert einen anderen Arzt als seinen Vertreter. Die Vertreterrolle wird Teil der Identität des Vertreters und führt zu einer Übernahme aller efa-zugangsrechte des Vertretenen. Eine explizite Einwilligung des Patienten ist nicht erforderlich, da die Vertretungssituation eine Annahme eines stillschweigenden Einverständnisses (mit der Option des Widerrufs) der Einbindung in den Behandlungsfall und damit des Zugangs zu der efa rechtfertigt Erweiterung von Berechtigungen durch den Patienten Durch die Kopplung an einen Behandlungsvertrag ist bei einer efa der Kreis der Zugriffsberechtigten klar abgegrenzt und wird i. A. über den Lebenszyklus der efa nur selten und dann immer zusammen mit dem Behandlungsvertrag bzw. durch eine diesen ergänzende schriftliche Vereinbarung verändert. Darüber hinaus muss es jedoch dem Patienten möglich sein, unabhängig vom Behandlungsvertrag weiteren Ärzten einen Zugang zu seiner efa zu verschaffen. Szenarien, in denen dies sinnvoll ist, reichen von Notfällen über Behandlungen am Urlaubsort, die im Kontext einer der efa zugrunde liegenden Diagnose stehen, bis zu dem Wunsch, eine Zweitmeinung zu einem medizinischen Dokument oder Bild einzuholen. Voraussetzungen für die Schaffung eines Mechanismus zur Erweiterung des zugangsberechtigten Personenkreises sind: 20 Um den Kreis der Berechtigten für den Patienten klar und nachvollziehbar zu definieren, bietet es sich an, im Rahmen des Einverständniserklärung zur efa-nutzung in allgemeiner Form darauf hinzuweisen, dass ein Arzt z. B. bei Krankheit oder Urlaub - Vertreter benennen kann. Sicherheitskonzept_v100 99

267 Die Erweiterung der Zugriffsrechte ist ein willentlicher Akt des Patienten. Die Erweiterung des Kreises der zugriffsberechtigten Personen ist zweckgebunden und zeitlich befristet. Auf diesem Wege erteilte Berechtigungen können vom Patienten jederzeit zurückgenommen werden. 6.2 Organisatorische Maßnahmen Die Architektur und die technischen Spezifikationen der elektronischen Fallakte müssen in ihrer Umsetzung von organisatorischen Schutzmaßnahmen flankiert werden, um die Einhaltung der geforderten Sicherheitsniveaus von Daten und Diensten sicherstellen zu können. Die in diesem Kapitel aufgeführten, von jedem efa-betreiber umzusetzenden organisatorischen Maßnahmen werden dabei durch zwei unterschiedliche Zielstellungen motiviert: Organisatorische Schutzmaßnahmen tragen zusammen mit den in Kapitel 4 formulierten Sicherheitsanforderungen und Umsetzungsvorgaben dazu bei, ein Grundniveau von Datenschutz und Datensicherheit aufzubauen, auf dem die durch die Architektur und die Sicherheitsdienste umzusetzenden Maßnahmen aufsetzen können. Die Anforderungen an die technischen Maßnahmen werden dahingehend reduziert, als dass diese nicht auf einem Null-Niveau aufsetzen, sondern das Vorhandensein bestimmter Prozesse und Schutzmechanismen voraussetzen können. Da diese Prozesse und Mechanismen oftmals auch die Umsetzungen der Sicherheitsdienste adressieren, wird dabei gleichzeitig auch deren Verfügbarkeit und Integrität erhöht. Organisatorische Schutzmaßnahmen relativieren Sicherheitsanforderungen und vermindern die über technische Maßnahmen zu erreichenden Schutzniveaus, indem sie Nutzungsszenarien einschränken und Nutzungskontexte konkretisieren. Hierdurch kann die Höhe und/oder Eintrittswahrscheinlichkeit von möglichen Schäden signifikant reduziert werden. Organisatorische Schutzmaßnahmen verfolgen im Kontext des Sicherheitskonzepts elektronischer Fallakten damit vor allem das Ziel, die Spannbreite des durch Architektur und Sicherheitsdienste (Technik) zu realisierenden Schutzes zu verringern (siehe Abbildung 18). Sie tragen damit maßgeblich dazu bei, dass diese Maßnahmen auf Cluster von Schutzzielen und Objekten fokussiert werden können. Hierdurch wird nicht nur die Komplexität einzelner Sicherheitsdienste reduziert, sondern es wird auch die Voraussetzung dafür geschaffen, mit einer geringen Zahl objektübergreifender Maßnahmen ein ganzheitlich angelegtes, alle Schutzbedarfe adressierendes und vor allem aufeinander abgestimmtes Bündel technischer und architektonischer Sicherheitskonzepte zu definieren. 100 Letzte Speicherung des Dokuments: :42:00

268 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Abbildung 18: Zielsetzung der organisatorischen Schutzmaßnahmen 21 Schutzbedarf Sehr hoch Organisatorische Maßnahmen Hoch Mittel Technische und organisatorische Maßnahmen Niedrig Technische und organisatorische Maßnahmen Schutzziel Verfügbarkeit Vertraulichkeit Integrität Verbindlichkeit Nutzungsbeschränkungen Die Vertraulichkeit, Integrität und Authentizität medizinischer Daten hat einen sehr hohen Schutzbedarf, da durch verfälschte Daten Leben oder Gesundheit von Patienten gefährdet sein können, bzw. Missbräuche personenbezogener Informationen zum gesellschaftlichen oder beruflichen Ruin eines Patienten führen können. Diese Feststellung eines sehr hohen Schutzbedarfs bedingt einen Einsatz qualifizierter elektronischer Signaturen, mit denen einerseits der Erstellungsprozess und die Einstellung eines medizinischen Datenobjekts in eine efa rechtssicher zurückverfolgt werden können und andererseits eine zuverlässige Integritätssicherung dieser Objekte und der die Objektzugänge schützenden Daten möglich ist. Wie in Kapitel 2 als Teil der Rahmenbedingungen und der projektspezifischen Anforderungen ausgeführt, kann zumindest für die Einführungsphasen 1 und 2 der efa nicht davon ausgegangen werden, dass Ärzte Dokumente und Metadaten qualifiziert signieren können. Aus diesem Grund müssen organisatorische Maßnahmen vorgesehen werden, mit denen entweder die Nutzung einer efa und der darin eingestellten Dokumente auf Szenarien begrenzt wird, in denen eine fortgeschrittene Signatur (z. B. durch einen 21 Die Dicke der Pfeile deutet an, in wie weit organisatorische Maßnahmen geeignet sind, die entsprechenden Schutzziele zu unterstützen. Nutzungsbeschränkungen können so z. B. Szenarien, die sehr hohe Schutzanforderungen an die Verbindlichkeit stellen explizit ausklammern, während Prozessverbesserungen im Betrieb der Systeme vor allem deren Verfügbarkeit erhöhen. Sicherheitskonzept_v

269 Dienst) ausreichend ist, oder die eine Rechtssicherheit auf anderen Wegen sicherstellen bzw. die Anforderungen an eine Rechtssicherheit reduzieren. Um den Schutzbedarf der Vertraulichkeit, Integrität und Vertraulichkeit medizinischer Datenobjekte von sehr hoch auf das technisch realisierbare Niveau hoch zu reduzieren, werden daher die folgenden Nutzungseinschränkungen einer elektronischen Fallakte festgelegt: Sofern eine mögliche Verletzung der Vertraulichkeit medizinischer Daten bzw. aus Meta- und Strukturdaten direkt oder indirekt ableitbarer personenbezogener Informationen den gesellschaftlichen und/oder wirtschaftlichen Ruin des Patienten zur Folge haben kann, ist dem Patienten seitens der behandelnden Ärzte von einer efa-nutzung abzuraten 22. Sofern der Patient dennoch die Nutzung einer efa wünscht, muss durch geeignete vertragliche Regelungen sichergestellt sein, dass er selber ausser im Fall des Vorsatzes oder der groben Fahrlässigkeit durch einen Arzt für mögliche Schäden haftet. Entscheidungen, die Risiken für Leben und Gesundheit des Patienten bergen, dürfen nie allein auf Basis von aus einer epa oder efa abgerufenen Dokumenten getroffen werden. Der Arzt muss die Echtheit der Dokumente (Integrität und Authentizität) verifizieren (z. B. durch Nachfrage beim Patienten) und/oder durch eigene Untersuchungen eine belastbare Basis für eine Echtheitsannahme schaffen 23. Die Anbieter elektronischer Fallakten haben sicherzustellen, dass alle bei ihnen registrierten efa-nutzer von diesen Nutzungseinschränkungen Kenntnis erhalten und diesen zustimmen. Die Zustimmung ist schriftlich festzuhalten. Organisatorische Maßnahmen zur Erzielung einer sehr hohen Verfügbarkeit und zur rechtssicheren Archivierung von efa-daten sind hingegen nicht erforderlich, da efa und epa kein Ersatz für die medizinische Behandlungsdokumentation des einzelnen Leistungserbringers sind. Alle in der 22 Diese Einschränkung folgt aus den Kriterien des BSI-Grundschutzes für Merkmale eines durch z. B. das Fehlen einer qualifizierten Signatur für die efa nicht realisierbaren sehr hohen Schutzbedarfs. Die Einschränkung betrifft jedoch in der Praxis eher seltene Fälle von Personen des öffentlichen Lebens mit gesellschaftlich potenziell als diskreditierend angesehenen Diagnosen (z. B. Suchterkrankungen). In den meisten Krankenhäusern werden auch intern in diesen Fällen besondere Schutzmaßnahmen für den Datenzugang über das KIS umgesetzt, die ggf. auch auf den efa-zugang abbildbar sind. 23 Diese Einschränkung der efa-nutzung ist notwendig solange keine qualifizierte Signatur eingesetzt wird, um eine Integritätssicherung medizinischer Dokumente gemäß dem erhobenen Schutzbedarf sicherzustellen. Sobald die technischen und organisatorischen Voraussetzungen existieren, dass Ärzte alle eingestellten Dokumente qualifiziert signieren und die Signatur durch jeden Arzt prüfbar ist, können die genannten Nutzungsbeschränkungen wegfallen. 102 Letzte Speicherung des Dokuments: :42:00

270 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen efa zusammengeführten Daten existieren als Primärdaten im System eines Leistungserbringers und können daher auf einem von der efa und der Telematikinfrastruktur unabhängigen Weg von dort abgerufen werden (z. B. per Fax, Mail, Telefon) Schulung und Unterstützung der Ärzte Neben dem technischen Personal der Anbieter von efa und/oder epa müssen vor allem die Nutzer (medizinisches und administratives Personal) im Umgang mit elektronischen Fallakten geschult werden. Hierdurch werden nicht nur die Akzeptanz der Anwendung und die Nutzungseffizienz gesteigert, sondern vor allem auch Fehlbedienungen vermieden, durch die Vertraulichkeit und /oder Integrität von zu schützenden Objekten gefährdet sein können. Seitens der Anbieter einer efa sind daher für alle potenziellen Nutzer Schulungen anzubieten und (ergänzende) Schulungsunterlagen bereitzustellen. Alle Informationen zur Nutzung einer efa, zum Aufbau der dahinter stehenden technischen Systeme und den verfügbaren Konfigurationsoptionen sind offen zu legen, so dass Schulungen und Selbstlernmaterialien auch von Dritten angeboten werden können. Neben der Schulung im Umgang mit dem System müssen Ärzte jedoch vor allem auch in der Aufklärung der Patienten geeignet unterstützt werden. Die Entscheidung zur Nutzung einer efa wird von Patient und Arzt gemeinsam gefällt und bedarf der schriftlichen Einwilligung des Patienten. Dem Arzt kommt dabei eine besondere Verantwortung zu, da er vom Patienten nicht nur in medizinischer Hinsicht als Vertrauensperson angesehen wird, sondern der Patient von ihm auch eine hinreichende Kenntnis der (potenziell auch technisch bedingten) Chancen und Risiken einer efa-nutzung erwartet. Um die Ärzte in dieser schwierigen Aufgabe zu unterstützen sind seitens der efa-anbieter Gesprächsleitfäden zu erstellen und die Patienten direkt adressierende Informationsmaterialien anzubieten. Hierbei sollten unterschiedliche Zielgruppen (Bildungsniveau, Indikation, etc.) berücksichtigt werden Sicherheits- und Betriebshandbücher Ein signifikanter Teil der in Kapitel 5 aufgeführten Bedrohungen der Sicherheit zu schützender Objekte wird durch eventuelle Schwachstellen in den bei einem efa-betreiber gelebten Prozessen begünstigt. Grundvoraussetzung für das Erreichen sämtlicher Schutzziele ist daher, dass die Prozesse zum Betrieb von efa-diensten bei jedem efa-betreiber klar definiert und entsprechend umgesetzt sind. Sicherheitskonzept_v

271 Um dieses sicherzustellen, sind von jedem Dienstanbieter für alle betriebenen Dienste der efa Sicherheits- und Betriebshandbücher zu erstellen, in denen die konkrete Operationalisierung der Maßnahmen des IT-Grundschutzes und der ITIL-Prozesse festgelegt ist. Die Einhaltung der Vorgaben ist durch regelmäßige interne Audits zu gewährleisten Umgang mit Logs und Traces Wie im Rahmen der Schutzbedarfsanalyse (Kapitel 3) dargelegt, entstehen Bedrohungen für die Vertraulichkeit personenbezogener Informationen nicht nur durch den missbräuchlichen Zugang zu einzelnen Objekten, sondern auch durch die Offenlegung von Objektbeziehungen und die Zusammenführung von Daten. Neben den durch die fachlichen Abläufe und Anforderungen motivierten Daten entstehen beim Betrieb der Anwendungen efa und epa jedoch potenziell weitere Daten, die vorrangig der Systempflege und -optimierung dienen. Eine gezielte Auswertung dieser Daten insbesondere wenn dies mit einer Zusammenführung mit anderen Daten verbunden ist ist eine immanente Bedrohung der Vertraulichkeit von personenbezogenen Informationen. Um dieser Bedrohung entgegenzuwirken, werden die folgenden Festlegungen für den Umgang mit beim Betrieb einer efa oder epa anfallenden Daten insbesondere Logs und Traces getroffen 24 : Das Gebot der Datensparsamkeit ist so eng wie möglich auszulegen und anzuwenden. Für alle gespeicherten Log- und Tracingdaten muss es deshalb eine nachvollziehbare Begründung für deren Erhebung und Speicherung geben. Eine Zusammenführung von Betriebsdaten, die bei verschiedenen Betreibern anfallen, ist nicht zulässig und nach Möglichkeit bereits durch technische Maßnahmen auszuschließen (z. B. durch Verwendung providerspezifisch transformierter Objekt-IDs). Die Auswertung von Betriebsdaten darf nur durch Personen erfolgen, die keine Möglichkeit des Zugangs zu Systemen und Daten haben, über die sich zu den Betriebsdaten ein Patientenbezug herstellen ließe. Betriebsdaten werden nur temporär gespeichert und nicht archiviert. Der Zeitraum der Speicherung ergibt sich aus dem Grund der Erhebung. 24 Siehe auch die Ausführungen zur Protokollierung in Kapitel Letzte Speicherung des Dokuments: :42:00

272 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Logdaten dürfen nicht zur Verhaltens- und Leistungskontrolle von Ärzten nutzbar sein. Eine Zusammenführung von Logdaten zu diesem Zweck darf durch die angebotenen Schnittstellen nicht möglich sein. 6.3 Konzeptionelle Maßnahmen (Architektur und Infrastruktur) Wie in der Einleitung dieses Dokuments skizziert, bildet das Sicherheitskonzept neben der fachlogischen Analyse der Anwendung efa den wichtigsten Anforderungsgeber für die Ausgestaltung der Anwendungsarchitektur. Die nachfolgend aufgeführten Anforderungen an die Architektur und die Dienste- Infrastruktur sind vor allem durch die Schutzbedarfe und die Sicherheitsstrategie motiviert, nehmen jedoch auch Aspekte der objektbezogenen Sicherheitsanforderungen und Umsetzungsvorgaben (Kapitel 4) auf und heben diese auf ein abstrakteres und damit allgemeingültigeres Niveau Multiple Defense Lines Sicherheitsdienste basieren auf Sicherheitsmechanismen, die ihrerseits auf Sicherheitsobjekte zugreifen. Zwischen Diensten und Mechanismen sowie zwischen Mechanismen und Objekten können m:n-beziehungen bestehen, d. h. die Sicherheit von verschiedenen Sicherheitsdiensten oder -mechanismen kann unter Umständen von der Sicherheit eines einzigen Sicherheitsobjekts (z. B. eines Algorithmus) abhängig sein. Eine Schwächung der Sicherheit dieses Objekts hätte in diesem Fall eine Schwächung mehrerer Sicherheitsmechanismen und -dienste zur Folge. Um die Abhängigkeit der Sicherheitsarchitektur von der Sicherheit einzelner Algorithmen, Datenobjekte und Token zu reduzieren, sollten innerhalb der Abläufe auf den verschiedenen Ebenen (Netzwerk, Anwendungen, etc.) unterschiedliche Sicherheitsobjekte und -mechanismen redundant eingesetzt werden. Hierdurch wird sichergestellt, dass auch bei Schwächung oder Korrumpierung eines Objekts bzw. eines Mechanismus der zweite Mechanismus (bzw. das zweite Objekt) immer noch ausreichenden Schutz bietet. Durch diese Redundanzen werden somit verschiedene Verteidigungslinien (defense lines) als Kapsel über die schützenswerten Daten gelegt. Für die efa-anwendung werden die Verteidigungslinien nicht primär über die Ebenen der Kommunikation, sondern entlang der Abläufe gezogen. Verteidigungslinien entstehen durch eine möglichst starke Unabhängigkeit der drei zum Datenzugang notwendigen Teiloperationen: Die Daten müssen identifiziert, d. h. gefunden, werden. Ein Zugriff auf die Daten muss erlangt werden. Sicherheitskonzept_v

273 Die Daten müssen dekodiert (entschlüsselt) werden. Die Unabhängigkeit dieser drei Schritte ist bei der Ausgestaltung der efa- Anwendung durch die folgenden Maßnahmen zu gewährleisten: Trennung von Authentisierung und Autorisierung, z. B. durch Realisierung über voneinander unabhängige Dienste Autorisierungsnachweise, die zum Datenzugang berechtigen, werden von unterschiedlichen, möglichst stark entkoppelten Diensten erstellt und verifiziert Die Identifizierung der Daten einer efa ist nur durch Vollziehen der vorgesehenen Navigationsschritte möglich, d. h. es gibt keine Möglichkeit der Identifizierung allein anhand von Merkmalen des Patienten Die Umsetzung der in Kapitel beschriebenen drei Kommunikations- Ebenen, auf denen Authentisierung, Integritätssicherung, Verschlüsselung und Autorisierung stattfinden, sollte nicht nach quantitativen, sondern allein nach qualitativen Gesichtspunkten und unter Berücksichtigung des zu realisierenden Schutzbedarfs erfolgen. D. h. die Umsetzung der Sicherheitsanforderungen erfolgt nicht primär durch Redundanzen in den Kommunikationsprotokollen, sondern durch mehrfache Berechtigungsprüfungen auf dem Navigationspfad von der Authentisierung bis zum Datenzugriff Reduktion der Komplexität Angriffe auf ein System, Fehlfunktionen von Schutzmechanismen und Administrationsfehler werden oftmals dadurch begünstigt, dass das betroffene System in seiner Konzeption und/oder seiner Umsetzung sehr komplex ist. Hohe Komplexität ist grundsätzlich als eine Vorstufe zur Nicht- Beherrschbarkeit anzusehen. Symptome (zu) komplexer Systeme sind: Sicherheitslücken, die dadurch entstehen, dass eine Prüfung aller technisch möglichen Systemnutzungen nicht durchführbar ist Programmierfehler, die dadurch entstehen, dass eine ganzheitliche Sicht auf das System nicht mehr herstellbar ist Fehlkonfigurationen, die dadurch entstehen, dass die wechselseitigen Abhängigkeiten zwischen Konfigurationsparametern für Nutzer und Betreiber nicht nachvollziehbar und nicht intuitiv erfassbar sind. Geeignete Mittel zur Reduktion der Komplexität eines Systems sind eine strikte Partitionierung und Modularisierung sowie eine Fokussierung einzelner Systemkomponenten auf sehr wenige Funktionalitäten ( separation of concerns ). Ein Beispiel hierfür ist die oben festgelegte konzeptionelle Trennung von Datenidentifizierung, Datenzugriff und Datenentschlüsselung. Weitere bei der Ausgestaltung der Anwendungsarchitektur zu berücksichtigende Partitionierungen sind: 106 Letzte Speicherung des Dokuments: :42:00

274 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Sicherheitsdienste werden zu einer eigenen Infrastruktur zusammengefasst, wodurch eine klare Trennung von Anwendungsfunktionalität und Sicherheit erfolgt. Anwendungen nutzen die ihrem Schutzbedarf und den verbleibenden Bedrohungen entsprechenden Sicherheitsdienste, die in ihrem Schutzniveau unabhängig von den Anwendungen skalieren können. Um die Komplexität des Berechtigungsmanagements und somit auch dessen Anfälligkeit gegen Angriffe zu reduzieren, erfolgt eine Trennung von Authentisierung und Autorisierung. Authentisierungen von Personen und die Überprüfung von Gruppenzugehörigkeiten fallen in unterschiedliche Zuständigkeiten (die nicht zwingend auf eine Organisation gebündelt werden müssen) und sind daher konzeptionell auseinander zu halten. Eine den funktionalen Anforderungen und gesetzlichen Vorgaben entsprechende Protokollierung ist als eigene Anwendung zu betrachten und auszugestalten. Anwendungsdienste von efa und epa greifen auf Protokolle über die Schnittstellen der Protokollanwendung zu. Bei der Umsetzung von efa und epa ist eine größtmögliche Härtung aller eingesetzten Systeme anzustreben. D. h. nicht zur Realisierung von epa und/oder efa zwingend benötigte Dienste und Systemkomponenten sind zu entfernen oder zu deaktivieren Nutzung von offenen Standards Schnittstellen, Austauschformate und Abläufe sollten so ausgestaltet werden bzw. so adaptierbar sein, dass für die Umsetzung aller wichtigen Systemkomponenten und Datenformate offene Standards eingesetzt werden können. Die Präferenz offener Standards liegt vor allem in deren Verifizierbarkeit und in der Austauschbarkeit von Implementierungen begründet: Offene Standards sind verifizierbar, d. h. ihre Eignung für die Umsetzung einer Anforderung kann objektiv erhoben und bewertet werden. Insbesondere etablierte offene Standards sind darüber hinaus von vielen Experten analysiert worden, sodass die Gefahr konzeptionell bedingter und/oder nicht bekannter Sicherheitslücken und Angriffspunkte relativ gering ist. Zu den meisten offenen Standards existieren verschiedene Umsetzungsmöglichkeiten, die es potenziell erlauben, für die gegebenen Rahmenbedingungen verschiedener efa-provider auch jeweils verschiedene Implementierungen auszuwählen, ohne dass dadurch die Interoperabilität der Systeme gefährdet wäre. Die Existenz alternativer Umsetzungsmöglichkeiten erlaubt eine zumindest theoretisch problemlose Austauschbarkeit von Realisierungen. Wenn eine Implementierung eines Standards als unsicher angesehen Sicherheitskonzept_v

275 werden muss, besteht daher die Option des schnellen Wechsels auf eine andere Implementierung Sicherheitszonen Die Strategie verschiedener Verteidigungslinien sowie die beschriebenen Maßnahmen zur Reduktion der Komplexität bilden die Basis der Festlegung von Sicherheitszonen als über definierte Schnittstellen miteinander verbundene gekapselte Einheiten. Die Zugehörigkeit von Diensten und Daten zu Sicherheitszonen richtet sich nach dem Betreiber, dem Schutzbedarf, dem Kreis der Zugriffsberechtigten und der Eintrittswahrscheinlichkeit von Bedrohungen. In den aktuellen Architekturkonzepten der gematik wird eine Stufung von Sicherheitszonen in dem Sinne gefordert, dass Zugriffe auf Zonen mit hohem Schutzbedarf immer nur aus bereits abgesicherten Zonen heraus erfolgen. Um ein solches Konzept zu realisieren, ist eine Konformität der Stufung von Sicherheitszonen mit den Kontroll- und Datenflüssen der Anwendungs- und Kommunikationsarchitektur erforderlich. Letzten Endes können Sicherheitszonen daher in hinreichend feiner Granulatität erst für eine definierte Grobarchitektur und in Abhängigkeit von der Topologie der Dienstevernetzung festgelegt werden. In Abbildung 19 sind mögliche Sicherheitszonen für eine an den fachlogischen Objekten orientierte Anwendungsarchitektur aufgezeigt, wobei von einer Peer-to-Peer-Vernetzung von Brokern als festen Zugangspunkten für Clients ausgegangen wurde. 108 Letzte Speicherung des Dokuments: :42:00

276 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Abbildung 19: Beispiel für Sicherheitszonen Primärdaten efa-daten efa-dienst Broker Primärdaten efa-daten efa-dienst Broker client client client client client client client client Broker efa-dienst efa-daten Primärdaten Broker efa-dienst efa-daten Primärdaten Unabhängig von der konkreten Anwendungsarchitektur und Dienste-Topologie lassen sich jedoch auch allein auf Basis der gegebenen Anforderungen einige Aussagen zur Gestaltung der Sicherheitszonen formulieren: Für die ersten beiden Umsetzungsphasen der efa steht kein Konnektor zur Verfügung. Dies bedeutet, dass es im dezentralen Bereich (Clients) keine als sicher zu deklarierende Komponente gibt. Von daher sind alle Komponenten vom Primärsystem über den Proxy bis zum (authentisierten) Zugang zur Infrastruktur und damit zum Eintritt in ein abgeschlossenes Netz ein und derselben Sicherheitszone zuzuordnen. Getrennte Sicherheitszonen sind nur in Umsetzungen vorzunehmen, in denen der Proxy zur Authentisierung von Gruppen genutzt wird und dadurch eine eigenständige Architekturkomponente darstellt. Primärsysteme bilden ebenso wie Kommunikationsserver (ggf. mit deren Transferdatenbanken) eigene Sicherheitszonen, für die in Bezug auf externe Zugriffe hohe Sicherheitsanforderungen bestehen. Die von den Clients genutzten Zugangspunkte zu den Diensten (Broker, Portal, etc.) sollten in einer eigenen Sicherheitszone angesiedelt werden. Hierdurch erfolgt einerseits eine klare Abgrenzung gegenüber dem potenziell als unsicher anzusehenden Client-Bereich, andererseits wird erst Sicherheitskonzept_v

277 so eine Stufung der Zonen durch Schaffung einer klaren Schnittstelle in den Bereich der efa-dienste und -Daten möglich. Die Peer-to-Peer-Vernetzung einzelner Dienste über Betreibergrenzen hinweg bildet eine eigene Sicherheitszone mit hohen Anforderungen an die Authentizität und Integrität der Kommunikation. Die sich aus diesen Aussagen ergebenden 6 Sicherheitszonen bilden zusammen mit den bereits formulierten Sicherheitsanforderungen und Umsetzungsvorgaben sowie dem Sicherheitskonzept eine ausreichende Basis für die Kapselung von Einheiten zur Stufung von Daten- und Dienstzugriffen. 6.4 Strategie und Konzeption der Ausgestaltung von Sicherheitsdiensten Auf Basis der Analyse der Schutzbedarfe wurde die in der Einleitung zu Kapitel 5 dargestellte generelle Sicherheitsstrategie ausgearbeitet. Durch die Einbeziehung von Charakteristika des Objektmodells und des vorgeschlagenen Berechtigungskonzepts in diese Strategie wurden eine technische Strategie und eine Konzeption zur Ausgestaltung von Sicherheitsdiensten ausgearbeitet. Wesentliche Bausteine dieser technischen Sicherheitsstrategie sind: Gespeicherte Meta- und Zugangsdaten lassen keinen Patientenbezug erkennen. Hierdurch können auch bei einem unberechtigten Zugriff auf die gespeicherten Daten keine direkten oder indirekten Verbindungen zwischen Patient und schützenswerten Informationen hergestellt werden. Abgebildet auf das Objektmodell bedeutet dies, dass jeglicher Patientenbezug direkt an der Wurzel d. h. am Objekt Patient gekappt wird. Integritätssicherung erfasst nicht nur einzelne Objekte, sondern berücksichtigt auch immer die schützenswerten Beziehungen zu anderen Objekten. Dies ist notwendig, da die Schutzbedarfsanalyse deutlich macht, dass insbesondere die Integrität von Objektbeziehungen wesentlich ist. Besonders sensibel ist dabei die Zugehörigkeit eines Objekts zu einer efa, da hiermit auch der Bezug zu den Berechtigungen hergestellt wird. Die Identifizierung einer efa durch (berechtigte) Herstellung des Bezugs zu einem Patienten ist konzeptionell vom Zugriff auf die efa und dem Zugriff auf die enthaltenen Datenobjekte zu trennen. Hierdurch ist es möglich, an verschiedenen Stellen dezentrale Merkmale einzubringen bzw. verschiedene serverseitige Schutzmechanismen auf dem Weg von der Authentisierung zum Datenzugriff zu realisieren. Die Vorhaltung redundanter Zugangsdaten bei verschiedenen Providern ist zu vermeiden. Jeder Nutzer und jede Gruppe kann sich gegenüber einem potenziell fest zugeordneten Dienst authentisieren, über den auch alle benötigten Identitätsdaten verfügbar sind. Die so erstellten Authentisierungs- und Identitätsnachweise werden ggf. mit expliziter 110 Letzte Speicherung des Dokuments: :42:00

278 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Verifizierung und nach Übertragung in einen anderen Sicherheitskontext von allen Diensten der efa-anwendung akzeptiert. Die Authentisierung erfolgt im Idealfall synchron zu der Granularität der Berechtigungen, d. h. wenn eine Gruppe zum Datenzugriff berechtigt wurde, ist anzustreben, dass nicht primär ein Individuum sondern die entsprechende Gruppenmitgliedschaft authentisiert wird. Portal bzw. efa-broker sind implizite Kandidaten für Man in the Middle - Angriffe, da jegliche Kommunikation zwischen Client (Arzt / Patient) und datenhaltenden Diensten über sie läuft. Aus diesem Grund müssen Kommunikations- und Datenkanäle logisch getrennt werden können.es muss daher auch dann, wenn die Kommunikation über ein Portal läuft, möglich sein, die Daten logisch direkt zwischen den Kommunikationsendpunkten auszutauschen (z. B. durch einen gemeinsamen Schlüssel gesichert). Aus diesen Essentials lassen sich Schutzkonzepte als Vorgaben für zu realisierende Sicherheitsdienste ableiten und einzelnen Schutzzielen und Objekten zuordnen (s. Abbildung 20). Sicherheitskonzept_v

279 Abbildung 20: Zuordnung der Sicherheitskonzepte zu den adressierten Schutzbedarfen Verbindlichkeit Integrität Vertraulichkeit Med. Datenobjekt (MDO) Information zu Ersteller des MDO Inhaltliche und formale Klassifizierung (MDO) Objekt-Identifizierer + + efa: Zugang + + efa: Ablagestruktur efa: Personenzuordnung Zugangsberechtigungen (efa; kein Patientenbezug) Identitätsdaten (Arzt) Ident-Token (Patient); realisierungsabhängig =/+ + + Authentisierungs-Token (Arzt) ++ = 5 ++ Die Schutzkonzepte beinhalten im Einzelnen (die Nummerierungen entsprechen den Kennzeichnungen in der Abbildung): 1 Ende-zu-Ende-Verschlüsselung von medizinischen Datenobjekten 2 Gemeinsame Integritätssicherung von Datenobjekten und allen beschreibenden Daten 3 Nutzung von Zugangscodes ohne Patientenbezug; Identitätsmanagement 4 Ableitung von Zugangstoken entlang der Navigation 5 Hardwaregestützte Authentisierung gemäß Berechtigungsmodell Ende-zu-Ende-Verschlüsselung Eine Verschlüsselung von medizinischen Datenobjekten muss in drei Szenarien erfolgen: 1 Ein Krankenhaus ist Datenanbieter, die Daten werden jedoch über ein Portal oder einen efa-broker geleitet, dessen Anbieter potenziell kein Zugriffsrecht auf die Daten besitzt. In diesem Fall können die Daten zwar 112 Letzte Speicherung des Dokuments: :42:00

280 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen unverschlüsselt beim Datenanbieter abgelegt sein, müssen jedoch über die gesamte Transportverbindung so verschlüsselt sein, dass eine Entschlüsselung nur für einen authentisierten, berechtigten Empfänger möglich ist. 2 Ein Krankenhaus nutzt einen externen Provider als Datenanbieter. In diesem Fall müssen potenziell alle medizinischen Datenobjekte verschlüsselt abgelegt sein, um unberechtigte Lesezugriffe des Providers zu verhindern. 3 Ein niedergelassener Arzt stellt Daten in eine efa ein. Der Arzt darf nicht davon ausgehen, dass der Provider des genutzten efa-zugangs zugriffsberechtigt ist. Die Daten müssen daher in verschlüsselter Form übermittelt werden. Um diese Szenarien zu unterstützen, werden zwei Schlüssel benötigt; ein Transportschlüssel sowie ein an eine efa und/oder einen Patienten gebundener Persistenzschlüssel. Der Transportschlüssel kann dynamisch erzeugt werden, wobei sichergestellt werden muss, dass er nur dem berechtigten Empfänger und dem datenhaltenden Dienst bekannt ist. Der Persistenzschlüssel muss einer efa oder einem einzelnen Objekt zugeordnet sein und darf nur berechtigten Empfängern bekannt gemacht werden. Erzeugung und Weitergabe der Schlüssel sind dementsprechend unterschiedlich zu gestalten: Der Transportschlüssel wird bei der Authentisierung eines Zugriffsberechtigten erzeugt bzw. dynamisch zwischen der authentisierten zugriffsberechtigten Person/Gruppe und dem datenhaltenden Dienst ausgehandelt. Hierbei muss im Fall einer serverseitigen Schlüsselerzeugung sichergestellt sein, dass der den Schlüssel erzeugende Dienst kein Teil der Kommunikationsverbindung zwischen Empfänger und Datenspeicher ist. Der Persistenzschlüssel wird clientseitig aus Daten erzeugt, die nur zugriffsberechtigten Personen bekannt sind bzw. bekannt gemacht werden. Hierdurch kann ein Zugriffsberechtigter neue Daten mit diesem Schlüssel verschlüsseln und jede andere zugriffsberechtigte Person ist in der Lage, den genutzten Schlüssel zu rekonstruieren. In der vorliegenden Version 1.0 der efa-spezifikationen werden lediglich die Erzeugung und die Nutzung der Transportschlüssel berücksichtigt, da als Szenario nur Krankenhäuser und andere Einrichtungen der Leistungserbringer als efa-provider berücksichtigt werden. Wenn mittelfristig auch Nicht- Leistungserbringer Fallakten (z. B. im Auftrag eines Krankenhauses) anbieten Sicherheitskonzept_v

281 wollen, wird hierzu die Einbeziehung der egk (oder einer Patientenkarte) erforderlich sein, da die auf der KVK gespeicherten Daten nicht geeignet sind, daraus einen dem Schutzbedarf entsprechend vertraulichen Schlüssel zu erzeugen Integrität der Metadaten Medizinische Datenobjekte müssen mit ihren beschreibenden und klassifizierenden Metadaten eine untrennbare Einheit bilden, da sich ein Arzt bei der Auswahl zu betrachtender Dokumente im Wesentlichen an diesen Metadaten orientiert und auch automatisierte Strukturierungen und Filterungen ausschließlich auf den Metadaten arbeiten. Eine absichtliche oder irrtümliche Verfälschung von Metadaten kann somit dazu führen, dass ein Arzt ein wichtiges Dokument nicht findet, in seiner Wichtigkeit nicht erkennt oder seinen Inhalt falsch interpretiert. Aus diesem Grund wird die Veränderung der Metadaten eines Datenobjekts mit einer Veränderung des Datenobjekts selbst gleichgesetzt, d. h. eine Änderung der Metadaten führt zur Erzeugung einer neuen Version des gesamten Objekts (Datenobjekt + Metadaten), die unter einer neuen Objekt-ID verwaltet wird. Integritätssichernde Maßnahmen umschließen immer Datenobjekt und Metadaten Zugangscodes Die Vertraulichkeit ist gefährdet, wenn entweder ein Bezug zwischen einem Patienten und vertraulichen Informationen hergestellt werden kann oder wenn die Integrität von Zugangsdaten bzw. Objektzuordnungen nicht gewährleistet ist. Die Herstellung eines Patientenbezugs kann dabei direkt oder indirekt erfolgen: In einem medizinischen Datenobjekt oder einem Freitextfeld der zugehörigen Metadaten sind der Name des Patienten und eine vertrauliche Information (Krankheitsbild, Suchtverhalten, etc.) kodiert. Missbräuchliche Zugriffe können durch die Ende-zu-Ende-Verschlüsselung verhindert werden (siehe ). Objekte sind einem Patienten zugeordnet und diese Zuordnung kann von unberechtigten Personen hergestellt werden. Aus den Metadaten bzw. 25 Bei flächendeckender Verfügbarkeit der egk könnte z. B. die über die PIN des Patienten vor unberechtigten Zugriffen geschützte OID.CH zur Schlüsselerzeugung genutzt werden. 114 Letzte Speicherung des Dokuments: :42:00

282 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen durch Zusammenführung von Metadaten lassen sich vertrauliche Informationen ableiten. Eine efa ist einem Patienten zugeordnet und diese Zuordnung kann von unberechtigten Personen hergestellt werden. Aus den Zugriffsrechten lassen sich Rückschlüsse auf ein Krankheitsbild ziehen (z. B. aus der Vergabe von Zugangsrechten an Spezialisten eines Fachgebiets) Diese Schutzrisiken lassen sich am besten ausschalten, wenn (innerhalb des Objektmodells) möglichst dicht am Objekt Patient Schutzmaßnahmen ansetzen, die eine Herstellung des Bezugs von einem Patienten zu anderen Objekten des Objektmodells nur für Zugangsberechtigte erlauben. Dies geschieht idealerweise dadurch, dass der Patient im statischen Objektmodell nie mit einer Identifikation auftaucht, die einen Rückschluss auf eine Person zulässt. Das zweite Risiko für die Vertraulichkeit von Patientendaten besteht in einer absichtlichen oder irrtümlichen Verfälschung von Zugangsdaten. Um die Integrität zu sichern, ist es notwendig, Zugangsdaten, Patientenidentifikation und efa-identifikation als Einheit zu betrachten. Durch eine Verfälschung eines dieser Daten wird dann die gesamte Einheit als nicht integer erkennbar und die entsprechenden Dienste können einem Aufrufer den Zugang zu dieser efa verweigern. Durch Zusammenführung dieser beiden Elemente der Sicherheitsstrategie Verbergen des Patienten und feste Verkettung von Patient, efa und Berechtigungen können Vertraulichkeit und Integrität über ein einfaches Konzept gesichert werden. Aus den Identifikationsdaten von Patient, berechtigtem Zugreifer und zu schützendem Objekt werden Zugangscodes gebildet, die innerhalb eines geeigneten Sicherheitskontextes serverseitig berechnet werden können, aber nicht in die umgekehrte Richtung in ihre Bestandteile auflösbar sind. Der Zugriff auf Objekte erfolgt ausschließlich über diese Zugangscodes. Hierdurch ist sichergestellt, dass einerseits die Integrität der zugriffsrelevanten Objektbeziehungen sichergestellt ist, andererseits aber in den Datenbanken keine Identifikatoren gespeichert werden müssen, die einen Rückschluss auf die Person des Patienten erlauben Sichere Zugangstoken Da in der elektronischen Fallakte lediglich Rechte auf der gesamten Akte definiert werden können, müssen bei der Integritätssicherung der efa zwei Aspekte berücksichtigt werden: Sicherheitskonzept_v

283 Die efa ist dem richtigen Patienten und den richtigen Berechtigten zugeordnet. Der efa sind die richtigen Datenobjekte zugeordnet (bzw. anders herum: die Datenobjekte sind der richtigen efa zugeordnet). Der erste Aspekt wird durch die Nutzung von Zugangscodes adressiert. Um neben der Integrität der Zugangsberechtigungen auch die Integrität der efa- Struktur sicherzustellen, werden Zugangscodes zu sog. SecurityToken erweitert. Differenzierung, Aufbau und Nutzung von SecurityToken basieren auf dem in Abbildung 21 dargestellten Navigationsmodell, welches aus dem konzeptionellen Modell (siehe Abbildung 5) abgeleitet wurde. Das Navigationsmodell zeigt die erforderlichen Navigationswege ausgehend vom Leistungserbringer über den Patienten hin zu dessen medizinischen Daten. Abbildung 21: Navigationsmodell der elektronischen Fallakte Möchte ein Leistungserbringer auf die elektronische Fallakte eines Patienten zugreifen, muss er zunächst die Identität des Patienten ermitteln. Dies kann in seinem Primärsystem mit Hilfe einer Patientenliste oder -suche erfolgen. Mit der Identität des Patienten erhält der Leistungserbringer eine Liste aller 116 Letzte Speicherung des Dokuments: :42:00

284 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Zugänge zu elektronischen Fallakten des Patienten. Solch ein Zugang umfasst die gesamte elektronische Fallakte. Ausgehend von der efa-zugangsliste muss der Leistungserbringer entscheiden, welche elektronische Fallakte für den aktuellen Behandlungskontext relevant ist. Durch Öffnen der Fallakte erhält der Leistungserbringer Zugang zu den Partitionen der efa und den die gesamte efa betreffenden Metadaten (incl. der Stammdaten des Patienten). Über diesen Zugang wiederum kann angezeigt werden, welche Datenobjekte in der efa bzw. der ausgewählten Partition enthalten sind. Der Leistungserbringer wählt ein Objekt aus, lädt es vom Server und zeigt es in seinem Primärsystem an. Wie das Navigationsmodell zeigt, werden die einzelnen Objekte immer in einer festen Sequenz bzw. Hierarchie aufgerufen. Eine Integritätsanforderung in der Zugehörigkeit zu einer efa und damit zu einer Berechtigung besteht dabei über den gesamten Pfad von der efa, über die Partitionen und Ordner hin zu den einzelnen Dokumenten. Wegen der sequenziellen Ausgestaltung ist die Integrität des Pfades jedoch auch dadurch sicherzustellen, dass jeweils die Integrität von zwei aufeinanderfolgenden Schritten gewährleistet ist. Statt Aussagen der Form Dokument A gehört zu efa X mit den Berechtigungen B zu kodieren, können auch Ketten von Aussagen etwa in der folgenden Form gebildet werden: Dokument A gehört zu Ordner/Partition O. Ordner/Partition O gehört zu efa E. Der Aufrufer ist berechtigt, auf efa E zuzugreifen. Sind alle diese Aussagen abgesichert, kann geschlossen werden, dass der Aufrufer zum Zugriff auf das Dokument A berechtigt ist. Solche jeweils zwei Objekte umfassenden Aussagen lassen sich anhand der im Navigationsmodell gelb hervorgehobenen Zuordnungslisten treffen. Um die Verkettung der Aussagen zu erlauben, werden sog. SecurityToken genutzt, die jeweils eine als Zugangscode kodierte Aussage und eine verifizierbare, jedoch nicht entschlüsselbare Zusammenfassung der vorangegangenen Aussagen beinhalten. Für jeden der Navigationsschritte wird ein eigener Typ von SecurityToken erzeugt, wobei ein Token immer aus dem Token der vorangegangenen Aussage abgeleitet wird. Jede in einer Datenbank verwaltete Aussage ist gegenüber dem gesamten Zugriffspfad verifizierbar, da sie über eine Zusammenfassung der eigenen Aussage mit der vorangegangenen Aussage integritätsgesichert ist. Die Prüfung erfolgt dadurch, dass die im Zugangscode kodierte Aussage mit der Sicherheitskonzept_v

285 Aussage in der Datenbank kombiniert und gegenüber der gespeicherten Gesamtaussage geprüft wird. Beispiel 26 : Ein Zugangstoken T zum Datenzugriff enthält (als Hashwert) die Aussage Partition A gehört zu efa B. In der Datenbank des datenverwaltenden Dienstes ist ein Objekt C der Partition A zugeordnet (Aussage: Objekt C gehört zu Partition A ). Zusätzlich ist ein Hashwert über (dem Hashwert) der ersten Aussage und der zweiten Aussage gespeichert. Wenn mit dem Token T das Objekt C gelesen werden soll, wird vom datenspeichernden Dienst der Hashwert beider Aussagen gebildet. Nur wenn dieser Wert mit dem gespeicherten Wert übereinstimmt d. h. die Kette C ist Teil von A, A ist Teil von B integer ist, wird das Dokument ausgeliefert. Die Schutzstärke dieses Mechanismus kann durch Einbringung eines dezentralen Merkmals oder weiterer Aussagen aus unterschiedlichen Quellen noch weiter gesteigert werden. SecurityToken können mehrfach genutzt werden. Hierzu ist die Kodierung der Aussagen so zu gestalten, dass diese auch bei einer von der Ausstellung zeitlich entkoppelten Nutzung verifizierbar sind und damit einfach reaktiviert werden können Hardwaregestützte Authentisierung gemäß Berechtigungsmodell Die Authentisierungsdaten auf Fallakten zugriffsberechtigter Personen und Gruppen haben einen sehr hohen Schutzbedarf, da Verletzungen der Vertraulichkeit und/oder Verbindlichkeit dieser Daten nicht nur zu unberechtigten Lesezugriffen führen können, sondern potenziell auch das Einstellen nicht integrer Dokumente ermöglichen, wodurch eine komplette efa nicht mehr nutzbar ist oder gar Gefährdungen für den Patienten ausgehen können. Aufgrund des sehr hohen Schutzbedarfs kommen zur Authentisierung von zugriffsberechtigten Personen nur Hardware-Token in Frage. Diese müssen den in 5.4 zusammengefassten Anforderungen entsprechen. Die 26 Dieses Beispiel soll lediglich das Konzept der über Zugangstoken verknüpften Aussagen zu Berechtigungen bei gleichzeitiger Sicherstellung der Integrität von Objekt-eFA-Beziehungen verdeutlichen und ist nicht als Vorgabe für die Spezifikation der Anwendungsarchitektur oder die Ausgestaltung des Berechtigungsmodells zu verstehen. 118 Letzte Speicherung des Dokuments: :42:00

286 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Authentisierung von Gruppen (Organisationen und Organisationseinheiten) muss ebenfalls über Hardware abgesichert sein. Dies kann z. B. über ein HSM (Hardware Security Module), eine entsprechende interne Verkabelung der Arbeitsplätze oder die Nutzung von IPSec-Hardware erfolgen. Zur Inanspruchnahme von Gruppenrechten sind damit grundsätzlich zwei unter Datenschutz- und Sicherheitsaspekten gleichwertige Authentisierungsoptionen gegeben: Eine Person authentisiert sich gegenüber einem Identity Provider, der die Authenzität des Zugreifers sowie dessen Gruppenzugehörigkeiten bescheinigt. Beide Angaben zusammen (Authentisierungsnachweis und Gruppenzugehörigkeit) ermöglichen die Inanspruchnahme von Gruppenrechten. Eine Person authentisiert sich gegenüber einem nur für Mitglieder einer Gruppe zugänglichen (krankenhaus-internen) System, das sich wiederum gegenüber einem Identity Provider authentisiert. Dieser stellt einen Authentisierungsnachweis zur Nutzung der entsprechenden Gruppenrechte aus. Da davon ausgegangen wird, dass in einer efa zugrunde liegenden Behandlungsverträgen Krankenhausmitarbeiter nie als Person, sondern immer als Mitglied der Organisation oder einer Organisationseinheit berechtigt werden, wird für die Authentisierung dieser Personengruppe die zweite der oben dargestellten Optionen zur Umsetzung empfohlen. 6.5 Protokollierung Wie in Kapitel dargestellt ist zur Herstellung einer Rechtssicherheits für Ärzte und Patienten in Bezug auf die efa-nutzung eine Protokollierung von Zugriffen auf Fallakten erforderlich. Diese hat gemäß den Vorgaben des 291a SGB V auch den Zweck, eine Datenschutzkontrolle zu ermöglichen. In Bezug auf die Protokollierung sind konzeptionell vier Anforderungsblöcke zu betrachten: Protokollierung der Einwilligung zur efa-nutzung Protokollierung der Erteilung von Zugriffsberechtigungen Protokollierung der efa-zugriffe Protokollierung zur Rekonstruktion von efa-zuständen Diese Blöcke werden nachfolgend im Detail diskutiert und mit Umsetzungsanforderungen hinterlegt. Hierbei werden auch Anforderungen an die Speicherung von Protokollen sowie deren Zusammenführung und Abfrage formuliert. Sicherheitskonzept_v

287 6.5.1 Einwilligung zur efa-nutzung Analog zu den Vorgaben des 291a SGB V zur Nutzung von freiwilligen Anwendungen der egk wird auch für die efa verlangt, dass die Einwilligung des Patienten zur Nutzung der Anwendung einzuholen und zu protokollieren ist. Dies kann entweder über eine separate Einwilligung oder zusammen mit der Erteilung von Zugriffsberechtigungen über einen Behandlungsvertrag erfolgen. Die Rücknahme der Einwilligung zur efa-nutzung führt zum unverzüglichen Schließen der Fallakte, d. h. der Status der Einwilligung ist ein wesentliches Kriterium für die Verbindlichkeit (insbesondere die Authenzität) einer efa. In Bezug auf die Speicherung und Zurverfügungstellung der Einwilligungserklärung ist zwischen den beiden genannten Motivationen zu unterscheiden, da diese jeweils andere rechtliche Hintergründe haben und auch technologisch nicht vermengt werden sollten: Abfrage des Status einer Einwilligung (erteilt, nicht erteilt, zurückgenommen) Kontrolle zu Zwecken des Datenschutzes Die Verwaltung des Status einer Einwilligung ist funktional motiviert und muss daher auf der Anwendungsebene adressiert werden. Dies erfolgt durch eine Berücksichtigung in den entsprechenden Anwendungsfällen. Auch die in dem Kapitel dieses Dokuments zusammengefassten Anforderungen und Umsetzungsvorgaben adressieren die Verwaltung des Zustands einer Einwilligung aus konzeptioneller, technischer und organisatorischer Sicht. Die Protokollierung der Einwilligung erfolgt somit ausschließlich zu Zwecken der Datenschutzkontrolle. Hierzu ist zu jeder efa ein Verweis anzulegen, über den ein Zugang zu der Einwilligung des Patienten möglich ist. Dieser Verweis muss nicht zwingend eine Referenz auf ein elektronisches Dokument sein, sondern kann auch textuell die Einrichtung benennen, in deren Akten die entsprechende Einwilligung abgelegt wurde. Der Zugriff auf die Einwilligung ist nur für Einrichtungen und Personen zu erlauben, die mit datenschutzrechlichen Kontrollaufgaben betraut sind. Sofern die Einwilligung innerhalb eines abgeschlossenen Bereichs eines Krankenhauses verwahrt wird, sind intern die Schutzmaßnahmen und Archivierungsanforderungen umzusetzen, die auch für die Verwahrung von Behandlungsverträgen gelten. Eine Speicherung in digitaler Form oder auf einem über das Internet zugänglichen System ist nicht erforderlich. 120 Letzte Speicherung des Dokuments: :42:00

288 Konzeptionelle Maßnahmen zur Sicherstellung der Schutzziele und der Sicherheitsanforderungen Erteilung von Zugriffsberechtigungen Zugriffsberechtigungen für eine efa werden im Normalfall über einen Behandlungsvertrag oder einem anderen schriftlichen Vertrag zwischen dem Patienten und den ihn behandelnden Einrichtungen erteilt. Dieser Vertrag ist entsprechend den geltenden gesetzlichen Bestimmungen zu verwahren und zu archivieren. Erteilt der Patient über den Behandlungsvertrag hinaus weiteren Ärzten oder Einrichtungen Zugriffsrechte auf eine efa, so müssen diese die entsprechende Einwilligung schriftlich einholen und protokollieren. Für die Verwahrung und Archivierung dieser Einwilligung gelten dieselben Regelungen wie für Behandlungsverträge. Sowohl der Patient als auch mit datenschutzrechtlichen Kontrollaufgaben betraute Personen und Einrichtungen müssen in die Lage versetzt werden, zu erfahren, welche Personen und Gruppen (Organisationen und Organisationseinheiten) welche Zugangsrechte zu einer efa besitzen. Diese Informationen sind auf Verlangen von dem Provider bereitzustellen, auf dessen Systemen die Wurzel der efa verwaltet wird. Eine entsprechende Schnittstelle zur Online-Abfrage ist nicht vorgesehen, da hierdurch unverhältnismäßige Anforderungen an das Accounting und die Authentisierung von potenziell darauf zugriffsberechtigten Personen entstehen würden und zumindest in den Einführungsphasen eins und zwei auch keine Möglichkeit der sicheren, elektronischen Authentisierung des Patienten besteht efa-zugriffe Alle lesenden und schreibenden Zugriffe auf eine elektronische Fallakte sind zu Zwecken der Datenschutzkontrolle zu protokollieren. Die Protokollierung erfolgt zum Zeitpunkt des Zugriffs durch die Komponente, auf deren Daten zugegriffen wird. Hierbei werden drei Arten von Protokolldaten unterschieden: Protokollierung von Zugriffen, die über Zugriffscodes erfolgen: Diese Zugriffe werden mit Datum, Uhrzeit, Objektkennzeichnung, Art des Zugriffs und genutztem Zugriffscode protokolliert. Eine Verschlüsselung der Protokolldaten ist nicht erforderlich. Protokollierung der Zuweisung von Zugangscodes an Personen oder Gruppen: Die Zuweisung eines Zugangscodes für eine efa an eine Person oder Gruppe ist mit Datum, Uhrzeit, die Gruppe oder Person eindeutig identifizierenden Daten, die efa eindeutig identifizierenden Daten, Berechtigungsgrundlage (z. B. Eintrag in einer ACL) und Zugangscode zu protokollieren. Da die Protokolldaten keinen Patientenbezug enthalten, ist eine Verschlüsselung nicht erforderlich. Protokollierung der Authentisierung einer Person als Gruppenmitglied: Sofern die Authentisierung über eine Organisation oder Organisationseinheit Sicherheitskonzept_v

289 erfolgt, ist von dieser die Authentisierung der zugreifenden Person gegenüber dem die Gruppe repräsentierenden System zu protokollieren. Die Protokollierungsdaten müssen eine Zuordnung von zugreifender Person zu einem der Gruppe zugewiesenen Zugangscode ermöglichen. Eine Verschlüsselung dieser Daten ist aufgrund des nicht vorhandenen Patientenbezugs nicht erforderlich. Die Speicherung der Protokolldaten muss in einer Form erfolgen, dass eine nachträgliche Veränderung oder eine Löschung technisch ausgeschlossen ist. Auf Verlangen des Datenschutzes oder des Patienten sind im Fall eines Missbrauchsverdachts der efa von allen efa-providern die einer konkreten efa zuzuordnenden Protokolldaten auszuhändigen. Die Zusammenführung der Protokolldaten ist ein dreigeteilter Ablauf: 1 Anfordern der zu einer bestimmten efa herausgegebenen Zugangscodes und der Namen der Personen und Gruppen, für die diese Zugangscodes vergeben wurden 2 Anfordern der Namen der Personen, die über an Gruppen vergebene Zugangscodes auf diese efa zugegriffen haben 3 Anfordern der Kette der aus den initialen Zugangscodes abgeleiteten Zugangscodes bis hinunter auf die Ebene des einzelnen Datenzugriffs Analog zu der Protokollierung von Einwilligungen ist aus Gründen der Sicherheit und der Verhältnismäßigkeit auch für die Abfrage und Zusammenführung von Protokolldaten keine Online-Schnittstelle vorgesehen efa-zustände Anhand der Protokolldaten muss sich für jeden Zeitpunkt im Lebenszyklus einer efa deren jeweiliger Zustand rekonstruieren lassen. Da einmal eingestellte Dokumente nicht mehr gelöscht werden können, sind die in vorgesehenen Protokollierungen ausreichend, um daraus die Zusammensetzung der efa sowie durchgeführte Statusänderungen nachvollziehen zu können. Ergänzend sind jedoch auch Änderungen an den Metadaten von efa-objekten (efa, Partitionen, Ordner, Informationsobjekte) zu protokollieren. Dieses kann jedoch im Rahmen der Zugriffsprotokollierung erfolgen. Aufgrund des fehlenden Patientenbezugs in den Metadaten entsteht hierdurch kein erhöhter Schutzbedarf für die Protokolldaten. 122 Letzte Speicherung des Dokuments: :42:00

290 Literatur 7 Literatur [b4h_outline ] [b4h_secarch-1.1] [b4h_überblick-1.1] [BfD_Tätigkeitsb-20] [bh4_secanf-1.1] [BMG_RA-1.1-RA05] [BMG_VTM-05] [BSI_100-1] [BSI_100-2] [BSI_100-3] bit4health: Skizzierung der Lösungsarchitektur und Planung der Umsetzung (Solution Outline). Version 1.1 vom bit4health: Erarbeitung einer Strategie zur Einführung der elektronischen Gesundheitskarte Sicherheitsarchitektur. Version 1.1 vom bit4health: Rahmenarchitektur der Telematikinfrastruktur im Gesundheitswesen. Version 1.1 vom August Der Bundesbeauftragte für den Datenschutz: Tätigkeitsbericht (20. Tätigkeitsbericht). August 2005 bit4health: Erarbeitung einer Strategie zur Einführung der elektronischen Gesundheitskarte Sicherheitsanforderungen. Version 1.1 vom Bundesministerium für Gesundheit und Soziale Sicherung: Risikoanalyse zur Einführung der elektronischen Gesundheitskarte. Version 1.1 vom 29. Juni Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte vom 2. November Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 100-1: Managementsysteme für Informationssicherheit. Version 1.0 vom Dezember Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 100-2: Grundschutz-Vorgehensweise. Version 1.0 vom Dezember Bundesamt für Sicherheit in der Sicherheitskonzept_v

291 Informationstechnik: BSI-Standard 100-1: Risikoanalyse auf der Basis von IT-Grundschutz. Version 2.0 vom Dezember [BSI_CC-2.11] Bundesamt für Sicherheit in der Informationstechnik: Common Criteria Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik. Version 2.1. [BSI_eGovernment-06] Bundesamt für Sicherheit in der Informationstechnik: egovernment-handbuch. Januar [BSI_GSK] [Cau_CW-33.05] [efa_dokumente-1.0] [efa_prozesse-1.0] [efa_szenarien-1.4] Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kataloge. Dezember Jörg Caumanns, J.: Der Patient bleibt Herr seiner Daten Realisierung des egk- Berechtigungsverfahrens über ein ticketbasiertes, virtuelles Dateisystem. Zur Veröffentlichung in einem Sonderheft des Informatik Spektrums vorgesehen.das Rückgrad des Gesundheitswesens. In: Computerwoche 33/2005, S August Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Daten, Dokumente und Dokumenttypen. Version 1.0 vom Juni Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Akteure und Prozesse. Version 1.0 vom Juni Fraunhofer ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, 124 Letzte Speicherung des Dokuments: :42:00

292 Literatur Sana e.med GmbH: Spezifikation einer Architektur zum einrichtungsübergreifenden Austausch von Patientendaten: Systemgrenzen und Szenarien. Version 1.4 vom Juni [egk_part ] [egk_part ] [FuE_SLA-1.1] [gem_rahmen/add] [gem_rahmen-0.8] [GMG_03] [HBA_ ] [HGG_WI-0505] [HL7_rbac_ex-1.1] [HL7_rbac-1.1] gematik: Spezifikation der elektronischen Gesundheitskarte Teil 1 (Kommandos, Algorithmen und Funktionen der Betriebssystem-Plattform). Version vom Februar gematik: Spezifikation der elektronischen Gesundheitskarte Teil 2 (Anwendungen und anwendungsspezifische Strukturen).Version vom März FuE-Projekt: Spezifikation der Lösungsarchitektur zur Unterstützung der Anwendungen der elektronischen Gesundheitskarte. Version 1.0 vom gematik: Anhang und Erläuterungen zu [gem- Rahmen-0.8]. Version 0.8 vom gematik: Gesamtarchitektur: Basisarchitektur für Testvorhaben Rahmenbedingungen. Version 0.8 vom Gesetz zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz GMG), 2003 Heilberufs-Ausweis und Security Module Card. Teil 2: Anwendungen und Funktionen. Version vom Mai Hornung, G., Goetz, C., Goldschmidt, A.: Die künftige Telematik-Rahmenarchitektur im Gesundheitswesen Recht, Technologie, Infrastruktur und Ökonomie. In: Wirtschaftsinformatik 47 (2005) 3, S HL7 Role-based Access Control (RBAC) Role Engineering Process Applied Example. Version 1.1 vom November HL7 Role-based Access Control (RBAC) Role Sicherheitskonzept_v

293 Engineering Process. Version 1.1 vom November [ISISMTT_1-1.1] [ISISMTT_5-1.1] [ISISMTT_6-1.1] [ISO7498-2] T7, Teletrust: Common ISIS-MTT Specifications for Interoperable PKI Applications. Part 1: Certificate and CRL Profiles. Version 1.1 vom 16. März T7, Teletrust: Common ISIS-MTT Specifications for Interoperable PKI Applications. Part 5: Certificate Path Validation. Version 1.1 vom 16. März T7, Teletrust: Common ISIS-MTT Specifications for Interoperable PKI Applications. Part 6: Cryptographic Algorithms. Version 1.1 vom 16. März International Organisation for Standarization ISO7498-2: Information Processing Systems - Open System Interconnection - Basic Reference Model. Part 2: Security Architecture [planungsauftrag-0404] Planungsauftrag erezept, earztbrief, epatientenakte und Telematikinfrastruktur vom März [protego-2.804] [RFC_4346] [SAGA-2.1] [Weichert_DuD-04] Projektbüro protego.net: Einführung der Telematik Infrastruktur. Version 2.8 vom Dezember Dierks, T.; Rescorla, E.: RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1. April Bundesministerium des Inneren: Standards und Architekturen für egovernment Anwendungen. Version 2.1. Thilo Weichert: Die elektronische Gesundheitskarte. In: Datenschutz und Datensicherheit 2004, S Letzte Speicherung des Dokuments: :42:00

294 Anhang Sicherheitskonzept_v

295

296 Abbildungsverzeichnis A Abbildungsverzeichnis Abbildung 1: Dokumentenübersicht 10 Abbildung 2: Einordnung der Sicherheitsanalyse in das Vorgehensmodell 11 Abbildung 3: Gliederung des Dokuments 12 Abbildung 4: Grundlagen des Sicherheitskonzepts 15 Abbildung 5: Konzeptionelles Modell der elektronischen Fallakte (Objektmodell) 24 Abbildung 6: Einordnung der Schutzbedarfsanalyse in das Dokument 29 Abbildung 7: Für die Analyse der Verfügbarkeitsanforderungen relevanter Ausschnitt des konzeptionellen Modells 32 Abbildung 8: Für die Analyse des Vertraulichkeitsschutzes relevanter Ausschnitt des konzeptionellen Modells 32 Abbildung 9: Für den Schutz der Integrität und Authentizität medizinischer Datenobjekte relevanter Ausschnitt des Objektmodells 32 Abbildung 10: Einordnung der objektbezogenen Sicherheitsvorgaben in das Dokument 32 Abbildung 11: Technische Systemkomponenten 32 Abbildung 12: Ebenen der Authentisierung und Autorisierung 32 Abbildung 13: Anbindung von Clients und Diensten über Gateways 32 Abbildung 14: Anbindung von Clients und Diensten über Broker (Mediatoren) 32 Abbildung 15: Anbindung von Clients an ein Peer-to-Peer-Netz bildende Dienste 32 Abbildung 16: Einordnung des Sicherheitskonzepts in das Dokument 32 Abbildung 17: Beispiel für HL7 Role Engineering 32 Abbildung 18: Zielsetzung der organisatorischen Schutzmaßnahmen 32 Abbildung 19: Beispiel für Sicherheitszonen 32 Abbildung 20: Zuordnung der Sicherheitskonzepte zu den adressierten Schutzbedarfen 32 Abbildung 21: Navigationsmodell der elektronischen Fallakte 32 Sicherheitskonzept_v

297 B Abkürzungsverzeichnis ACL BA bit4health BMG DoS efa egk epa FuE HBA (HPC) MA OID SMC VPN SOAP BSI BfD SGB V GMG KIS PVS UML AZ SigG/SigV ITSEC SLA ITIL P2P SSL/TSL IV MVZ DMP Access Control List Berufsausweis Vom BMG initiiertes Projekt zu Ausarbeitung der Rahmenarchitektur zur egk Bundesministerium für Gesundheit Denial of Service Elektronische Fallakte Elektronische Gesundheitskarte Elektronische Patientenakte gemäß 291a, Abs. 3, Satz 1, Nr. 4 SGB V Vom BMG initiiertes Projekt zur Spezifikation der Lösungsarchitektur zur egk Elektronischer Heilberufsausweis (Health Professional Card) Mitarbeiterausweis Objekt-ID Security Module Card Virtual Private Network Simple Object Access Protocol Bundesamt für Sicherheit in der Informationstechnik Bundesbeauftragter für den Datenschutz Sozialgesetzbuch V Gesundheitsmodernisierungsgesetz Krankenhaus-Informations-System Praxis-Verwaltungs-System Unified Modelling Language Antwortzeit(kategorie) Signatur-Gesetz / Signatur-Verordnung Information Technology Security Evaluation Criteria Service Level Agreement IT Infrastructure Library Peer-to-Peer Secure Sockets Layer / Transport Level Security Integrierte Versorgung Medizinisches Versorgungszentrum Disease Management Programm 130 Letzte Speicherung des Dokuments: :42:00

298 Sicherheitsarchitektur Spezifikation einer Architektur zum sicheren Austausch von Patientendaten Editor: Dr. Jörg Caumanns Verantwortlich: Fraunhofer ISST Status: Release; Zur Kommentierung Version: 1.1 Berlin, 10. Juli 2006

299

300 Release-Planung Nr. Datum MS Version Status Bemerkungen Status draft Skizzierung der»gesetzten«mechanismen In time xx draft Gliederung, Einleitung, Skizzieren der In time Sicherheitsdienste gemäß Sicherheitskonzept draft Pre-Release für AG-2 und Partner Final draft Freigabe zur Kommentierung (LK, AG-2); 6.3 fehlt in time Final draft ISST-interne Freigabe Release Veröffentlichung Änderungshistorie Nr. Datum Version Status Bemerkungen Bearbeiter draft Einarbeiten der Kommentars und Cluster JC Draft Einarbeiten der QS-Anmerkungen zu den Kapitel 1-5 JC Final Draft Federation in 6.1 und 6.2 eingebaut JC Final Draft Anmerkungen der AG.2 und des LK berücksichtigt JC Final Draft Abgleich mit Anwendungsarchitektur (insb. Assertions) JC Release Einarbeitung der Kommentare (Projektpartner, QS) OB Release Überarbeitung der Korrekturen und Auflösung von JN Kommentaren Sicherheitsarchitektur_v1.01.doc 1

301 Copyright Copyright (c) Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH (2006). Alle Rechte vorbehalten. Dieses Dokument und Übersetzungen, die davon angefertigt wurden, dürfen kopiert und weitergegeben werden und abgeleitete Werke, die es kommentieren, erklären, oder Hilfestellung bei der Implementierung leisten, dürfen vorbereitet, kopiert, veröffentlicht und verteilt werden, als Ganzes oder in Teilen, ohne dass hierbei Einschränkungen in irgendeiner Form bestehen; vorausgesetzt, dass die obige Urheberrechtserklärung und dieser Absatz in allen Kopien und abgeleiteten Werken enthalten ist. Dieses Dokument selbst darf nur mit schriftlichem Einverständnis der Urheber modifiziert werden. Die beschränkten Rechte, die durch obige Aussage gewährt werden, sind dauerhaft und werden von den Urhebern (Fraunhofer-Institut für Software- und Systemtechnik ISST, Asklepios Kliniken Verwaltungsgesellschaft mbh, Deutsche Krankenhausgesellschaft e. V., Rhön-Klinikum AG, Sana e.med GmbH), ihren Nachfolgeorganisationen und Rechtsnachfolgern nicht zurückgezogen werden. Dieses Dokument und die hierin enthaltene Information werden ohne Mängelgewähr zur Verfügung gestellt. DAS FRAUNHOFER-INSTITUT FÜR SOFTWARE- UND SYSTEMTECHNIK ISST, DIE ASKLEPIOS KLINIKEN VERWALTUNGSGESELLSCHAFT MBH, DIE DEUTSCHE KRANKENHAUSGESELLSCHAFT E. V., DIE RHÖN-KLINIKUM AG, DIE SANA E.MED GMBH UND DIE AN DER ERSTELLUNG DIESES DOKUMENTS BETEILIGTEN MITARBEITER DER GENANNTEN EINRICHTUNGEN SCHLIESSEN JEDE FORM DER HAFTUNG, OB GEÄUßERT ODER VERMUTET; AUS, DAFÜR DASS DIE VERWENDUNG DER INFORMATIONEN IN DIESEM DOKUMENT KEINE RECHTE VERLETZT; DASS SIE GEBRAUCHSTAUGLICH SIND ODER SICH FÜR EINEN SPEZIELLEN ZWECK EIGNEN. 2 Letzte Speicherung des Dokuments: :45:00

302 Inhalt Copyright 2 1 Management Summary 7 2 Einleitung Einordnung in den Projektkontext Einführungsphasen Vorgehensmodell Notation Konventionen Gliederung des Dokuments 15 3 Grundlagen der Sicherheitsarchitektur Sicherheits- und Datenschutzkonzept Sicherheitsinfrastruktur nach ISO Sicherheitsobjekte Sicherheitsmechanismen Sicherheitsdienste Vertraulichkeit Authentisierung und Autorisierung Zugriffskontrolle Integrität und Verbindlichkeit 22 4 Aufbau der Sicherheitsarchitektur Dienste zur Authentisierung und Autorisierung Ende-zu-Ende-Verschlüsselung Domains und Cluster Domains Cluster und Föderationen Inter-Domain/Intra-Cluster-Zugriffe Inter-Cluster-Zugriffe Anbindung von niedergelassenen Ärzten Erzeugung und Verifizierung von Autorisierungsnachweisen Nutzung der Sicherheitsdienste durch Client- Systeme PVS/KIS mit eng gekoppeltem Proxy PVS/KIS mit lose gekoppeltem Proxy Browser mit Active Requestor Browser als Passive Requestor PVS/KIS oder Browser mit Proxy als Intermediär 43 Sicherheitsarchitektur_v1.01.doc 3

303 5 Sicherheitsobjekte Kryptografische Schlüssel Funktionale Spezifikation Kodierung Erstellung und Verwaltung Migration Algorithmen Funktionale Spezifikation Zu unterstützende Algorithmen XML-Kodierung von Schlüsseln und Algorithmen Verwaltung Migration Personen- und Gruppen-Identifizierer Funktionale Spezifikation Anforderungen an die Kodierung von Personen- und Gruppen-Identifizierern Kodierung von Personen-Identifizierern für Patienten Kodierung von Personen-Identifizierern für Ärzte und diese unterstützendes Personal Kodierung von Organisationen-Identifizierern Kodierung von Organisationstypen Kodierung von Rollen-Identifizierern Migration und Verwaltung Domain-Identifizierer Funktionale Spezifikation Kodierung von Domian-Identifizierern Verwaltung Migration Objekt-Identifizierer Aufbau von Objekt-IDs Kodierung von Objekt-IDs Verwaltung Migration Dienst-Identifizierer Funktionale Spezifikation Kodierung von Dienst-Identifizierern Migration Zugangscodes Funktionale Spezifikation Kodierung 66 6 Sicherheitsmechanismen Ver- und Entschlüsselung von Daten Funktionale Spezifikation Kodierung verschlüsselter Daten Hybride Verschlüsselung 69 4 Letzte Speicherung des Dokuments: :45:00

304 6.3 One-Way-Hashing (Digesting) Funktionale Spezifikation Kodierung von Hash-Werten Secret Hash (Bildung von Zugangscodes) Funktionale Spezifikation Berechnung von Secret Hashes Erzeugung von initialen Zugangscodes Offline-Token Funktionale Spezifikation Kodierung und Verwaltung Umsetzungsempfehlung X.509 Zertifikate Signierung Funktionale Spezifikation Kodierung Autorisierungen Funktionale Spezifikation Kodierung Assertions (Nachweise) 83 7 Dienste der Sicherheitsarchitektur Identity Provider Nutzung Funktionale Spezifikation Kodierung von Identitäts- und Authentisierungsnachweisen Abbildung auf WS Trust Anfordern eines Authentisierungsnachweises einer anderen Domain Peer-to-Peer Weitergabe von Identitätsanfragen Migration Realisierungshinweise Attribute Service Nutzung Funktionale Spezifikation Authentizität und Nichtabstreitbarkeit Abläufe Kodierung der Gruppenzuordnungen Nachrichtenformat Migration DataChannel Service Nutzung Funktionale Spezifikation Abläufe SOAP Nachrichtenformat (Active Requestor Profile) Passive Requestor Profile 123 Sicherheitsarchitektur_v1.01.doc 5

305 7.3.6 Migration Literatur 125 A Abbildungsverzeichnis 132 B Tabellenverzeichnis 133 C Notation 135 C.1 Atomare Datentypen 135 C.2 Ableitung von Datentypen 135 C.3 Abhängigkeiten zwischen Elementen eines Datentyps 136 C.4 Operationen und Dienste 137 C.5 Dienste 137 D Zusammengesetzte und abgeleitete Datentypen 138 D.1 UniqueIdentifier 138 D.2 Identifier 139 D.3 PersistentObjectIdentifier 139 D.4 Attribut-Wert-Paare Letzte Speicherung des Dokuments: :45:00

306 1 Management Summary Die vollständige Umsetzung der Vorgaben an IT-Sicherheit und Datenschutz ist ein wesentliches Kriterium für die Akzeptanz elektronischer Fallakten bei Patienten und Ärzten. Im Rahmen eines Sicherheits- und Datenschutzkonzepts wurden daher wesentliche Festlegungen getroffen, wie der Schutz personenbezogener Daten und die Sicherheit der efa-dienste entlang der Navigationsmuster durch Pseudonymisierung, Verteidigungslinien und weitere grundlegende Konzepte sichergestellt werden kann. Die technische Umsetzung bzw. Unterstützung dieser Konzepte erfolgt durch die in diesem Dokument beschriebenen Objekte, Mechanismen und Dienste der Sicherheitsarchitektur. Hierbei wird der gesamte Komplex der Authentisierung von Nutzern und Gruppen sowie der Transportverschlüsselung medizinischer Daten durch drei Dienste gekapselt: Der Identity Provider bietet Operationen zur Identifizierung und Authentisierung von Ärzten, deren Gehilfen, Organisationen und Organisationseinheiten an. Operationen des Attribute Service stellen die Verbindung zwischen Personen und Gruppen (Organisationen, Rollen, etc.) her. Mit Hilfe des DataChannel Service kann ein Client eine Ende-zu-Endeverschlüsselte Transportverbindung zu einem Datenspeicher aufbauen. Die von Identity Provider und Attribute Service erstellten Nachweise über Authentisierungen und Gruppenzugehörigkeiten werden als SAML-Assertions kodiert und können auch gegenüber anderen als dem ausstellenden efa-provider zur Autorisierung von Datenzugriffen genutzt werden. Hierzu wird ein auf Föderationen basierendes Konzept realisiert, bei dem jeder Nutzer (Person oder Gruppe) fest einer sog. Domain zugeordnet ist. Eine Domain repräsentiert dabei den efa-provider, gegenüber dem sich der Nutzer authentisieren kann und bei dem die Gruppenzugehörigkeiten des Nutzers abrufbar sind. Zur Nutzung der efa erhält der Nutzer ausschließlich von dem Identity Provider dieser Domain die benötigten Authentisierungsnachweise (Single Sign-On). Domains mit gleicher Sicherheitspolicy (Authentisierungsverfahren, Gruppendefinitionen, etc.) und untereinander abgestimmten administrativen und operativen Betriebsvorgaben bilden ein Cluster. Ein in einer Domain eines Clusters ausgestellter Nachweis der Identifizierung, Authentisierung, oder Autorisierung eines Nutzers ist für alle Dienste aller Domains dieses Clusters verifizierbar und wird von diesen akzeptiert. Sicherheitsarchitektur_v1.01.doc 7

307 In clusterübergreifende Kommunikationsvorgänge werden die jedem Cluster zugeordneten Federation Services eingebunden. Diese sorgen im Wesentlichen dafür, in einem Cluster erstellte Nachweise in den Kontext eines anderen Clusters zu setzen, sodass diese dort verifiziert, interpretiert und damit letzten Endes akzeptiert werden können. 8 Letzte Speicherung des Dokuments: :45:00

308 2 Einleitung Die Einführung der elektronischen Gesundheitskarte stellt insbesondere die Krankenhäuser vor große Herausforderungen. Die priorisierten Anwendungen erezept und Versichertenstatus adressieren nur marginal den für Krankenhäuser besonders wichtigen sektorübergreifenden Datenaustausch, gleichzeitig ist die Umstellung der IT-Systeme mit großen Aufwänden verbunden. Die privaten Klinikketten asklepios Klinikverwaltungsgesellschaft mbh, Rhön-Klinikum AG und Sana e.med GmbH haben daher beschlossen, ihre aktuellen Aktivitäten zur Errichtung von Ärzteportalen zu bündeln und in ein gemeinsames Projekt mit der Deutschen Krankenhausgesellschaft e. V. und dem Fraunhofer-Institut für Software- und Systemtechnik ISST einzubringen. Das Projekt wird durch einen Beirat aus Vertretern öffentlicher und kirchlicher Krankenhausträger begleitet und soll die Arbeiten der gematik ergänzen. Ziel ist es, Synergieeffekte zu nutzen, und die unabhängig von der Gesundheitskarte notwendigen Investitionen in elektronische Patientenakten abzusichern. Gegenstand der auch für weitere Partner offenen Initiative ist die Spezifikation einer interoperablen Architektur, mit der bei Krankenhäusern vorgehaltene Patientendaten über verschiedene Zugangswege unter Beachtung des Datenschutzes im Kontext sektorübergreifender Behandlungsszenarien nutzbar gemacht werden können. Dadurch werden die existierenden dezentralen Strukturen der Verwaltung medizinischer Daten beibehalten und es können Mehrfachspeicherungen vermieden werden. Neben einem auf den Spezifikationen der Gesundheitskarte basierenden Zugang für Patienten und Ärzte (elektronische Patientenakte epa) können Daten eines Behandlungsfalls zu einer»fallakte«zusammengefasst werden, die den mit der Behandlung befassten Medizinern einen sektor- und einrichtungsübergreifenden Datenaustausch ermöglicht. Einsatzszenarien für Fallakten sind neben Einweisungen insbesondere Disease Management Programme und die zunehmend an Bedeutung gewinnende integrierte Versorgung [efa_szen-1.0]. 2.1 Einordnung in den Projektkontext In diesem Dokument wird die Sicherheitsarchitektur des Systems zur Realisierung elektronischer Fallakten zum einrichtungsübergreifenden Austausch von Patientendaten beschrieben. Sie ist Grundlage der Anwendungsarchitektur [efa_app-1.0] und ihrer Dienste. Ausgangspunkt Sicherheitsarchitektur_v1.01.doc 9

309 der Sicherheitsarchitektur ist ein Sicherheits- und Datenschutzkonzept [efa_sdk-1.0], in dessen Rahmen auf Basis einer Schutzbedarfsanalyse eine Sicherheitsstrategie sowie technische, organisatorische und architektonische Schutzkonzepte ausgearbeitet wurden. Die Bereitstellung von Objekten, Mechanismen und Diensten zur Umsetzung der technischen Schutzkonzepte ist Aufgabe der Sicherheitsarchitektur. Die Sicherheitsarchitektur wird in diesem Dokument auf zwei Abstraktionsebenen spezifiziert: Funktionale Spezifikation: Auf abstrakter Ebene werden Sicherheitsdienste und -mechanismen realisierungsunabhängig über ihre Funktionalitäten und Eigenschaften beschrieben. Die so entstehende funktionale Spezifikation der Sicherheitsarchitektur ist ein Modell von Datenstrukturen, Diensten und Operationen, das die Außensicht der Sicherheitsarchitektur prägt. Auch wenn eine Implementierung teilweise andere interne Strukturen, funktionale Dekompositionen und Datenflüsse realisiert, müssen diese von außen betrachtet d. h. an den externen Schnittstellen konform zu der funktionalen Architektur sein und ein zumindest gleichwertiges Schutzniveau sicherstellen. Nachrichtenflüsse: Objekte und Abläufe der funktionalen Spezifikation werden auf parametrisierte Kontroll- und Datenflusssequenzen abgebildet. Die hierbei zu verwendenden Standards werden referenziert und sofern notwendig in Bezug auf ihre konkrete Ausgestaltung beschrieben. Die Spezifikation der konkreten Nachrichtenformate erfolgt als Teil der Kommunikationsarchitektur [efa_komm-1.0]. Analog zu den Konzepten der bit4health Sicherheitsarchitektur [b4h_secarch-1.0], der FuE-Lösungarchitektur [FuE_SLA-1.0] und dem aktuellen Diskussionsstand in der gematik werden Sicherheitskonzepte und -dienste sowohl auf der Anwendungsebene als auch auf der Kommunikationsebene (Transport- und Netzwerkebene) angesiedelt. Die in diesem Dokument beschriebenen Sicherheitsdienste dienen vor allem der Absicherung der Anwendungsdaten und Anwendungsdienste und sind damit auf der Anwendungsebene sichtbar. Die darunter liegenden Sicherheitsdienste der Kommunikations- und Netzwerkebene dienen dem Aufbau authentisierter und sicherer Kommunikationskanäle zwischen Systemkomponenten. Die so aufgespannte sichere Kommunikationsinfrastruktur bildet damit eine zweite Sicherheitsebene. Die Kommunikationsinfrastruktur wird gegenüber der Anwendungsarchitektur über sog. Bindings gekapselt, über die protokollspezifische Mechanismen zum sicheren Nachrichtenaustausch in einer»neutralen«form bereitgestellt werden. Kommunikationsinfrastruktur und die Bindings für SOAP sind in dem Dokument»Kommunikationsinfrastruktur und Deployment«[eFA_KomDeploy-1.0] beschrieben. 10 Letzte Speicherung des Dokuments: :45:00

310 In Abbildung 1 sind die einzelnen Dokumente zum Thema»Sicherheit und Datenschutz«im Kontext der Projektergebnisse dargestellt. Abbildung 1: Dokumentenübersicht Übersicht über die Projektergebnisse Fachlogik Systemgrenzen und Szenarien Daten und Dokumente Akteure und Prozesse Sicherheit und Datenschutz Sicherheitskonzept Sicherheitsarchitektur Implementierungsvorgaben Technik Anwendungsarchitektur Implementierungsvorgaben Kommunikationsinfrastruktur und Deployment Implementierungsvorgaben Der efa-client Datentypen und Nachrichtenformate 2.2 Einführungsphasen Für das Projekt wird von einer Einführung der elektronischen Fallakte in drei Phasen ausgegangen: 1 Die am Projekt beteiligten Einrichtungen führen Pilot- und Testvorhaben durch. Weder HBA noch egk sind in ausreichender Dichte verfügbar und alle benötigten Dienste werden in»eigenregie«betrieben. Gleichartige Dienste verschiedener efa-anbieter sind untereinander vollständig vernetzt. 2 Die spezifizierte Fallakte kommt in einer größeren Zahl von Einrichtungen im»regelbetrieb«zum Einsatz. Eine egk ist von einzelnen Kassen in einzelnen Regionen ausgegeben. Die Dienste werden in übergeordnete Organisationsstrukturen integriert und teilweise von mehreren Trägern gemeinsam oder zentralisiert angeboten und betrieben. Dienste der gematik werden soweit verfügbar genutzt. Dienste verschiedener efa-anbieter sind nach einem Föderationskonzept miteinander vernetzt. 3 egk und HBA sind flächendeckend verfügbar. Die von der gematik spezifizierte Telematikinfrastruktur ergänzt die eigenen Dienste bzw. löst diese ab. Gleichartige Dienste verschiedener efa-anbieter sind an die Telematikinfrastruktur der gematik angebunden. Die Vernetzung erfolgt dynamisch unter Nutzung der von der gematik bereitgestellten Lokalisierungsmechanismen. Sicherheitsarchitektur_v1.01.doc 11

311 Analog zu den sich zwischen den Einführungsphasen ändernden Rahmenbedingungen und der zunehmenden Öffnung der efa sind auch die in diesem Dokument enthaltenen Spezifikationen an verschiedenen Stellen auf einzelne Phasen der efa-einführung abgestimmt. D. h. bestimmte Vorgaben betreffen lediglich einzelne Einführungsphasen bzw. die Verbindlichkeit von Vorgaben steigt synchron zu den Einführungsphasen. Eine solche abgestufte Verbindlichkeit ist insbesondere auch an allen Stellen gewählt worden, an denen von Implementierungen aktuell noch nicht festgelegte Vorgaben der gematik und des BMG zur Nutzung der egk bzw. zur Clientanbindung über Konnektoren zu beachten sein werden. 2.3 Vorgehensmodell Die Sicherheitsarchitektur ist direkt aus dem Sicherheitskonzept [efa_sdk-1.0] abgeleitet. Hiermit wird ein Vorgehensmodell realisiert, bei dem Fachlichkeit, Sicherheit und Datenschutz als wesentliche Anforderungsgeber für sämtliche technologischen Festlegungen d. h. die konkrete Spezifikation von Anwendungs- und Sicherheitsdiensten angesehen werden. Bei der Ausarbeitung der Anwendung»elektronische Fallakte«wurde daher zunächst eine Sicherheitsstrategie mit grundlegenden, von der konkreten Lösung abstrahierenden Konzepten entwickelt. Diese Konzepte bilden die Basis der auszuarbeitenden Lösung bzw. sind von dieser zu berücksichtigen und zu integrieren. In der nachfolgenden Abbildung ist das in diesem Sinne aufgesetzte Vorgehensmodell dargestellt: Schutzbedarfsanalyse, Sicherheitskonzepte (»Strategie«) und Sicherheitsmaßnahmen bilden den Ausgangspunkt für die Spezifikation der Anwendungs- und Sicherheitsarchitektur und geben Anforderungen für die Umsetzung und den Betrieb der spezifizierten Lösung vor. Das grau hinterlegte Element des Vorgehens korrespondiert zu den in diesem Dokument beschriebenen Ergebnissen des Designs der Sicherheitsdienste und der diese unterstützenden Sicherheitsarchitektur. 12 Letzte Speicherung des Dokuments: :45:00

312 Abbildung 2: Einordnung des Designs der Sicherheitsarchitektur in das Vorgehensmodell Fachlogische Analyse Szenarien, Prozesse und Objekte Sicherheitsanalyse Rechtsgrundlagen und Rahmenbedingungen Nichtfunktionale Anforderungen Funktionale Anforderungen Konzeptionelles Modell Schutzbedarfe Sicherheitskonzepte Sicherheitsmaßnahmen Design Sicherheitsarchitektur Anwendungsarchitektur Kommunikationsarchitektur Risiko- und Bedrohungsanalyse Schutzmaßnahmen für Dienste und Daten Umsetzung und Betrieb Die in diesem Dokument spezifizierte Sicherheitsarchitektur wurde in einem iterativen Prozess aus dem Sicherheitskonzept unter Berücksichtigung existierender Standards erstellt. Hierzu wurden die Vorgaben des Sicherheitskonzepts zu den technologischen Schutzkonzepten zunächst in eine sehr abstrakte funktionale Spezifikation übersetzt. Auf Basis der daraus ableitbaren funktionalen Anforderungen wurden passende Standards zur Umsetzung einzelner Sicherheitsdienste und -mechanismen ausgewählt. Die Verfeinerung der funktionalen Spezifikation wurde in einer solchen Weise durchgeführt, dass eine durchgängige Kompatibilität mit den Datenformaten und Abläufen der favorisierten Standards sichergestellt werden konnte. 2.4 Notation Zur Darstellung der funktionalen Spezifikationen von Sicherheitsobjekten, -mechanismen und -diensten wird eine formalisierte Notation verwendet. Semantische Basis der Notation ist die formale Sprache»Z«. Um die Lesbarkeit zu erhöhen und insbesondere bei der Darstellung der Dienstabläufe auch informelle Beschreibungselemente zuzulassen, wurde die»z«-semantik an vielen Stellen durch eine an objektorientierte Programmiersprachen angelehnte Syntax gekapselt. Sicherheitsarchitektur_v1.01.doc 13

313 Eine kurze Einführung in die Elemente der Notation sowie Spezifikationen der grundlegenden Datentypen sind in den Anhängen A und B dieses Dokuments dargestellt. 2.5 Konventionen Die Verbindlichkeit von in diesem Dokument enthaltenen Spezifikationen und Vorgaben wird durch die in [RFC2119] festgelegten Schlüsselwörter»MUST«,»SHOULD«,»MAY«,»SHOULD NOT«und»MUST NOT«angezeigt: MUST: Eine so ausgezeichnete Spezifikation oder Anforderung ist verbindlich (normativ) in der beschriebenen Art und Weise bzw. mit dem vorgegebenen Verhalten umzusetzen. SHOULD: Eine so ausgezeichnete Spezifikation oder Anforderung sollte von jeder efa-implementierung umgesetzt werden. Es handelt sich jedoch nur um eine Empfehlung, von der in begründeten Ausnahmefällen abgewichen werden kann. MAY: Die Umsetzung einer so ausgezeichneten Spezifikation oder Anforderung ist dem Realisierer bzw. Anbieter einer efa freigestellt. SHOULD NOT: Eine so ausgezeichnete Realisierungsoption darf von einer efa-implementierung nur in begründeten Ausnahmefällen umgesetzt werden. MUST NOT: Eine so ausgezeichnete Aussage beschreibt eine Realisierungsoption, die nicht zulässig ist. Um Missverständnisse bei der Interpretation der diesen Schlüsselwörtern semantisch entsprechenden deutschen Formulierungen zu vermeiden, werden bei allen verbindlichen Aussagen und Spezifikationen die englischen Schlüsselwörter am Ende der Aussage in Klammern angefügt, bei den anderen, nicht verbindlichen Aussagen (insbesondere»may«) werden die Schlüsselwörter ggf. auch weggelassen. Beispiel: Alle Implementierungen der efa müssen alle Algorithmen der als Default gekennzeichneten Algorithmenfamilie unterstützen (MUST). In den Einführungsphasen 1 und 2 sollte eine zweite Algorithmenfamilie unterstützt werden (SHOULD). Diese Vorgabe wird für die Einführungsphase 3 verbindlich (MUST). 14 Letzte Speicherung des Dokuments: :45:00

314 2.6 Gliederung des Dokuments In der nachfolgenden Grafik sind die Inhalte dieses Dokuments einschließlich der Querbeziehungen zwischen den einzelnen Spezifikationen dargestellt. Abbildung 3: Inhalte der Sicherheitsarchitektur ISO Sicherheits- und Datenschutzkonzept Sicherheitsobjekte Schlüssel, Algorithmen Identifier und Namen Zugangscodes Sicherheitsmechanismen Komponenten Identity Provider Attribute Service DataChannels Single Sign-On Federations Datenkanäle Der Aufbau der Sicherheitsarchitektur erfolgt gemäß den strukturellen Vorgaben von ISO [ISO7498_2-89], an denen auch die Strukturierung der Sicherheitsarchitektur ausgerichtet wurde. In Kapitel 3 dieses Dokuments wird ein kurzer Überblick über ISO gegeben und darauf basierend ein Überblick über die wesentlichen Sicherheitsobjekte, -mechanismen und -dienste gegeben. Die funktionale Ausgestaltung der Sicherheitsdienste erfolgt anhand von drei aus dem Sicherheits- und Datenschutzkonzept der efa abgeleiteten technologischen Grundsatzentscheidungen (Single Sign-On, Federations, Datenkanäle). Der hieraus resultierende grundsätzliche Aufbau der Sicherheitsarchitektur sowie die Muster der Kommunikation zwischen Clients und Sicherheitsdiensten werden in Kapitel 4 beschrieben. Die Kapitel 5 bis 7 bilden die eigentliche (technische) Spezifikation der Sicherheitsarchitektur. Hier werden die von Implementierungen umzusetzenden Sicherheitsobjekte (Kapitel 5), Sicherheitsmechanismen (Kapitel 6) und Sicherheitsdienste (Kapitel 7) funktional und in ihrer Abbildung auf existierende Standards spezifiziert. Sicherheitsarchitektur_v1.01.doc 15

315 3 Grundlagen der Sicherheitsarchitektur Entsprechend dem Stand der Technik wird für die efa-anwendung eine möglichst starke Entkopplung von Sicherheits- und Anwendungsdiensten angestrebt. Hierdurch entsteht eine austauschbare und unabhängig von funktionalen Anforderungen der Anwendung skalierbare Sicherheitsinfrastruktur. Wesentlich für die Ausgestaltung der Sicherheitsarchitektur ist daher, dass eine daraus abgeleitete Diensteinfrastruktur weitgehend autonom ist, d. h. nicht das Vorhandensein bestimmter Anwendungsdienste erfordert und unabhängig von konkreten Umsetzungen der Anwendungsfunktionalitäten ist. Dieses wird zum einen durch das Sicherheits- und Datenschutzkonzept [efa_sdk-1.0] und zum anderen durch die Ausrichtung der Sicherheitsarchitektur an den strukturellen Vorgaben der ISO unterstützt. 3.1 Sicherheits- und Datenschutzkonzept Ziel des Sicherheits- und Datenschutzkonzepts elektronischer Fallakten [efa_sdk-1.0] ist es, sicherzustellen, dass die in einer efa verwalteten Daten integer und damit im Behandlungskontext nutzbar sind die Verbindlichkeit der Daten in Bezug auf Urheberschaft und Zusammenstellung verifizierbar ist die Verfügbarkeit der efa-anwendung den Anforderungen des Alltagsgeschäfts in Krankenhäusern und Praxen entspricht und die Vertraulichkeit von Gesundheitsdaten zum Schutz der Persönlichkeitsrechte des Patienten gewahrt ist. Zur Umsetzung dieser Anforderungen werden im Rahmen einer»sicherheitsstrategie«einige wenige elementare Festlegungen getroffen, die den funktionalen Rahmen der Sicherheitsarchitektur vorgeben: Berechtigungen sind immer an gesamte Fallakten geknüpft und können sowohl an Individuen wie auch an Organisationen, Organisationseinheiten und Rollen vergeben werden. Die Zuordnung von Personen zu Gruppen erfolgt im Rahmen der Authentisierung durch ein Identitätsmanagement. Verteidigungslinien werden nicht an technologischen Ebenen und Bausteinen ausgerichtet, sondern entlang der Kontroll- und Datenflüsse gezogen. 16 Letzte Speicherung des Dokuments: :45:00

316 Die Mechanismen zur Sicherstellung der Integrität von Fallakten und Berechtigungen zielen nicht auf einzelne Objekte, sondern vor allem auf Beziehungen zwischen Objekten entlang der Pfade des Objekt- und Navigationsmodells ab. Der Schutz der Vertraulichkeit patientenbezogener Informationen wird durch eine Pseudonymisierung des Patienten innerhalb der Abläufe realisiert. Zugangs-, Struktur- und Metadaten sowie Nachrichten zur Navigation über Fallakten enthalten keine für unberechtigte Personen auflösbaren Bezüge zu Patienten. Hierdurch können efa-navigation und -Präsentation serverseitig über Portale realisiert werden, ohne dass für den Portal-Provider vertrauliche Patienten-Informationen einsehbar wären. Die Vorhaltung redundanter Zugangsdaten bei verschiedenen Providern ist zu vermeiden. Jeder Nutzer und jede Gruppe kann sich gegenüber einem fest zugeordneten Dienst bzw. Portal authentisieren (Single Point of Access), über den/das auch alle benötigten Identitätsdaten verfügbar sind. Authentisierungs- und Identitätsnachweise werden ggf. mit expliziter Verifizierung und nach Übertragung in einen anderen Sicherheitskontext von allen Diensten der efa-anwendung akzeptiert (Single Sign-On). Die Authentisierung erfolgt im Idealfall synchron zu der Granularität der Berechtigungen, d. h. wenn eine Gruppe zum Datenzugriff berechtigt wurde, ist anzustreben, dass nicht primär ein Individuum, sondern die entsprechende Gruppenmitgliedschaft authentisiert wird. Sofern einzelne geforderte Schutzniveaus mit den Maßnahmen des Sicherheits- und Datenschutzkonzepts nicht umsetzbar sind, werden Nutzungseinschränkungen und andere organisatorische Maßnahmen festgelegt, um die das technologisch nicht erzielbare Schutzniveau bedingenden Anwendungsfälle geeignet einzuschränken. Hierdurch wird sichergestellt, dass die Sicherheitsinfrastruktur der efa von überschaubarer Komplexität ist und damit einfacher auf existierende, verifizierte Konzepte und Produkte abgebildet werden kann. 3.2 Sicherheitsinfrastruktur nach ISO Bei der Ausgestaltung der Sicherheitsarchitektur zur Umsetzung der vom Sicherheits- und Datenschutzkonzept vorgegebenen Funktionalitäten wurde auf etablierte Standards und Vorgehensmodelle zurückgegriffen. Dazu gehören insbesondere die Vorgaben der ISO zum Aufbau von Sicherheitsarchitekturen [ISO7498_2-89], die IT-Grundschutzkataloge des BSI [BSI_GSK] und das E-Government-Handbuch [BSI_eGov-06]. In der nachfolgenden Abbildung werden die Bestandteile der Sicherheitsarchitektur Sicherheitsarchitektur_v1.01.doc 17

317 in Beziehung zu den in ISO spezifizierten Ebenen einer Sicherheitsinfrastruktur gesetzt. Abbildung 4: Sicherheitsdienste, Sicherheitsmechanismen und Sicherheitsobjekte Sicherheitskonzept Sicherheitsinfrastruktur Policy, Audit & Alert Management Anforderungen an & Nutzung von Sicherheitsdiensten Erstellung, Nutzung und Verwaltung von Sicherheitsobjekten Sicherheitsdienste Sicherheitsmechanismen Sicherheitsobjekte Personen-IDs Integrität Verschlüsselung (Secret) Hash Offline-Token Digitale Signatur Autorisierungen Zertifikate Assertions Gruppen-IDs Domain-IDs Objekt-IDs Dienst-IDs Schlüssel Algorithmen Auswahl und Austausch von Sicherheitsmechanismen Authentisierung Autorisierung Vertraulichkeit Verbindlichkeit Die Abstraktionsebenen der Sicherheitsdienste, -mechanismen und -objekte werden in ISO wie folgt definiert: Sicherheitsdienste bieten Funktionen an, die sich an dem Ziel orientieren, das mit ihnen erreicht werden soll. Sicherheitsmechanismen sind Funktionen, die einzeln oder in Kombination benutzt werden, um Sicherheitsdienste umzusetzen. Sicherheitsobjekte sind besonders schützenswerte Objekte, die von den Sicherheitsmechanismen benutzt werden. Anforderungen an Sicherheitsdienste und Vorgaben zu deren Nutzung basieren auf den anwendungsspezifischen Sicherheits- und Datenschutzanforderungen, Schutzzielen und Bedrohungspotenzialen. Die Sicherheitsmechanismen haben einen engen Bezug zu den Sicherheitsdiensten, müssen jedoch insoweit auch unabhängig betrachtet werden können, als dass ihre Auswahl in vielen Fällen von technologischen Faktoren abhängig ist. Insbesondere die kontinuierlichen Weiterentwicklungen in der Kryptografie und der Kryptoanalyse bringen das Erfordernis mit sich, Sicherheitsmechanismen einfach austauschen zu können, um jederzeit auf Ebene der Sicherheitsdienste das angestrebte Schutzniveau realisieren zu können. 18 Letzte Speicherung des Dokuments: :45:00

318 Dies gilt in entsprechender Weise auch für die Sicherheitsobjekte. Ungeachtet des starken Bezugs zu den darauf basierenden Mechanismen ist oftmals eine hohe Flexibilität in Bezug auf deren Erstellung und Verwaltung erforderlich, um unterschiedlichen (operativ geprägten) Rahmenbedingungen des Einsatzes einer Anwendung gerecht werden zu können. 3.3 Sicherheitsobjekte Sicherheitsobjekte sind alle Daten und Objekte, die von den Sicherheitsmechanismen und den darauf aufbauenden Sicherheitsdiensten benutzt werden. Sicherheitsobjekte haben durchgängig einen hohen Schutzbedarf in Bezug auf ihre Integrität und Verbindlichkeit. Insbesondere zur Authentisierung genutzte Sicherheitsobjekte unterliegen zusätzlich hohen Vertraulichkeitsanforderungen. Dadurch dass alle Mechanismen und Dienste auf ihnen aufbauen, bestimmt die Verfügbarkeit der Sicherheitsobjekte entscheidend die Verfügbarkeit der gesamten Architektur. Zur Umsetzung der Anwendung»elektronische Fallakte«werden die folgenden Sicherheitsobjekte verwendet: Kryptografische Schlüssel und Algorithmen zur Umsetzung von Sicherheitsmechanismen zum Schutz von Vertraulichkeit, Integrität und zur Authentisierung Zugangscodes und diese kapselnde Sicherheitstoken, die Berechtigungsnachweise zum Zugriff auf Fallakten und medizinische Daten bilden Identitätsbeschreibungen und Privilegien für Personen und Gruppen, die Basis von Mechanismen zur Authentisierung und Autorisierung sind Zugriffsregeln und Attribute, über die Rechte von Gruppen und Personen beschrieben und ausgewertet werden können IDs für Domains und Dienste, mit denen diese eindeutig lokalisiert und authentisiert werden können Objekt-IDs zur eindeutigen Identifizierung und Referenzierung von Akten und medizinischen Informationsobjekten Alle im weiteren Verlauf dieses Dokuments beschriebenen Mechanismen und Dienste bauen auf diesen einfachen Basisobjekten auf. Vorgaben und Festlegungen zur konkreten Kodierung und Nutzung der aufgeführten Sicherheitsobjekte sind Gegenstand von Kapitel 5 dieses Dokuments. 3.4 Sicherheitsmechanismen Die die Sicherheitsobjekte nutzenden Algorithmen und Konzepte, die zur Erbringung von Sicherheitsdiensten (Vertraulichkeit, Integrität, Sicherheitsarchitektur_v1.01.doc 19

319 Authentisierung, etc.) zum Einsatz kommen, werden als Sicherheitsmechanismen bezeichnet. Sowohl zwischen Sicherheitsdiensten und Sicherheitsmechanismen als auch zwischen Sicherheitsmechanismen und Sicherheitsobjekten besteht jeweils eine n:m-relation. Dies bedeutet, dass innerhalb der Hierarchie (Sicherheitsobjekte Sicherheitsmechanismen Sicherheitsdienste) auf jeder Ebene mehrfach nutzbare Bausteine für die nächsthöhere Ebene definiert werden. Die nachfolgende Abbildung aus der bit4health Sicherheitsarchitektur [hb4_secarch-1.1] stellt eine Auswahl von Sicherheitsmechanismen zur Erfüllung von Sicherheitszielen dar und gewichtet diese gegenüber Schutzbedarfen. Abbildung 5: Sicherheitsmechanismen (aus [b4hsecarch-1.1]) 3.5 Sicherheitsdienste Sicherheitsdienste sind immer auf ein Schutzziel ausgerichtet. In den nachfolgenden Abschnitten werden die einzelnen Dienste der Sicherheitsarchitektur im Überblick beschrieben; eine Spezifikation der Datenflüsse und Operationen der Sicherheitsdienste ist Gegenstand von Kapitel Letzte Speicherung des Dokuments: :45:00

Initiative»Elektronische Fallakte«

Initiative»Elektronische Fallakte« Deklarative Sicherheit zur Spezifikation und Implementierung der elektronischen FallAkte Workshop»Sichere Informationstechnologie für das Gesundheitswesen von morgen«gmds Jahrestagung 2010, Mannheim R.

Mehr

Elektronische Fallakte v2.0. EFAv2.0 für regionale Versorgungsnetze

Elektronische Fallakte v2.0. EFAv2.0 für regionale Versorgungsnetze Elektronische Fallakte v2.0 EFAv2.0 für regionale Versorgungsnetze Was ist EFA? Die elektronische Fallakte ist eine Lösung für den Austausch medizinischer Daten in regionalen Versorgungsnetzen Weitergabe

Mehr

SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN

SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN Matthias Heyde / Fraunhofer FOKUS SECURITY DESIGN PATTERN FÜR EHEALTH-PLATTFORMEN Dr. Jörg Caumanns Fraunhofer FOKUS, Berlin BEISPIELE FÜR EHEALTH ARCHITEKTUREN Security Security Security c c c c c c S

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur

Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur Sektorübergreifende Zusammenarbeit mit EFA 2.0 und Telematikinfrastruktur Dr. Andreas Kerzmann Projektleiter P75 GDD/EFA gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße

Mehr

ELEKTRONISCHE FALLAKTE

ELEKTRONISCHE FALLAKTE ELEKTRONISCHE FALLAKTE KIS RIS PACS und DICOM Treffen 6. und 7. Juli 2007 Sun Microsystems GmbH Berlin Fallakten als Kommunikationsmittel zwischen Behandlern Komplexe Behandlungsprozesse brauchen eine

Mehr

Kommunikation in der Intersektoralen Versorgung

Kommunikation in der Intersektoralen Versorgung Kommunikation in der Intersektoralen Versorgung Dr. Gert Funkat funkat@imise.uni-leipzig.de Was ist ISV? Das Informationsdilemma Die Information, die Du hast, ist nicht die, die Du willst Die Information,

Mehr

Authentisierung/Authentifizierung Überblick über die Client- und Dienstauthentisierung im Kontext der elektronischen Fallakte

Authentisierung/Authentifizierung Überblick über die Client- und Dienstauthentisierung im Kontext der elektronischen Fallakte Authentisierung/Authentifizierung Überblick über die Client- und Dienstauthentisierung im Kontext der elektronischen Fallakte Editor: Olaf Rode Dokumenten-ID: Authentisierung/ Authentifizierung Verantwortlich:

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007

Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 Informations- und Kommunikationstechnologie als Innovationstreiber für Gesundheitswesen und Medizin? Prof. Dr. Herbert Weber September 2007 1 Die Wahrnehmung der Patienten Der Umfang und die Qualität der

Mehr

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik

Manuel Koch, Dr. Herbert Bunz 10. September 2009. Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik Manuel Koch, Dr. Herbert Bunz 10. September 2009 Datenschutz fördernde Techniken als vertrauensfördernde Maßnahmen der Gesundheitstelematik 2009 gematik 2009 IBM Corporation Der Patient kann selbstbestimmt

Mehr

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr.

Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Die Spezifikation der Lösungsarchitektur zur Umsetzung der Anwendungen der elektronischen Gesundheitskarte Management Summary Prof. Dr. Herbert Weber Von Dezember 2004 bis Februar 2005 haben die Fraunhofer-Institute

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Ergebnisse der TeleTrusT-AG "SOA" SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Arbeitsergebnisse des SOA Security AKs Anfang 2009 - Themenfindung für das Dokument Mitte 2009 Vorgehenskonzept

Mehr

Interoperabilität elektronischer Aktensysteme

Interoperabilität elektronischer Aktensysteme Interoperabilität elektronischer Aktensysteme Nürnberger Archivtage 2014 Dr. Ralf Brandner Anwendungsfälle Datenaustausch auf Basis von Aktensystemen Archivierung Konsil Befundung Fallbesprechung Überweisung

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Softwaregestütztes Einwilligungsmanagement

Softwaregestütztes Einwilligungsmanagement Softwaregestütztes Einwilligungsmanagement Vom Konzept zum Prototyp Berlin, 24. März 2010 Markus BIRKLE, Oliver Heinze, Lennart Köster, Björn Bergh Sektion Medizinische Informationssysteme Agenda Begriffsbestimmung

Mehr

Positionspapier: Portalverbund und ehealth

Positionspapier: Portalverbund und ehealth Positionspapier: Portalverbund und ehealth e-government Arbeitsgruppe Integration und Zugänge (AG-IZ) Dr. Wilfried Connert Franz Hoheiser-Pförtner, MSc Rainer Hörbe Peter Pfläging Juli 2009 Inhalt Zielsetzung

Mehr

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte.

Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. Vernetzung im Gesundheitswesen. Die häufigsten Fragen zur elektronischen Gesundheitskarte. 3. Kann ich nicht einfach meine alte Krankenversichertenkarte behalten? Die elektronische Gesundheitskarte ist

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

Sichere Kommunikation für SOAP-basierte Web Services

Sichere Kommunikation für SOAP-basierte Web Services Whitepaper SOA Security Framework Sichere Kommunikation für SOAP-basierte Web Services Holger Junker, BSI, soa@bsi.bund.de Die Sicherheitsanforderungen an SOA Infrastrukturen und den darin stattfindenden

Mehr

Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg IHE Deutschland e.v. www.ihe-d.de

Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg IHE Deutschland e.v. www.ihe-d.de IHE-basierte Aktensysteme - Architekturansätze Björn Schreiweis, Oliver Heinze, Björn Bergh, Universitätsklinikum Heidelberg Agenda 1. Hintergrund / Motivation 2. Rechtliche Grundlagen 3. IHE Was ist das?

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

Mehr

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte

Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Notfalldaten und Datenerhalt mit der elektronischen Gesundheitskarte Smartcard-Workshop Darmstadt, 9. Februar 2012 Georgios Raptis Bundesärztekammer Notfalldatensatz auf der egk 2003 291a SGB V die egk

Mehr

Technische Konzeption der Bürgerportale

Technische Konzeption der Bürgerportale Technische Konzeption der Bürgerportale Armin Wappenschmidt (secunet) Weitere Informationen unter www.buergerportale.de www.bmi.bund.de 1 Agenda Technische Übersicht über Bürgerportale Postfach- und Versanddienst

Mehr

efa in a Box Dr. Jörg Caumanns Fraunhofer ISST IT Trends 2011 // Essen 21.09.11 Fraunhofer ISST

efa in a Box Dr. Jörg Caumanns Fraunhofer ISST IT Trends 2011 // Essen 21.09.11 Fraunhofer ISST efa in a Box Dr. Jörg Caumanns Fraunhofer ISST IT Trends 2011 // Essen 21.09.11 efa in a Box Motivation efa-management per Arztbrief technische Umsetzung 2 Datenschutz und Datennutz: Problemstellung Die

Mehr

Einsatz Serviceorientierter-Architekturen in der Telemedizin: Zwei Anwendungsberichte aus Forschung und Industrie

Einsatz Serviceorientierter-Architekturen in der Telemedizin: Zwei Anwendungsberichte aus Forschung und Industrie Einsatz Serviceorientierter-Architekturen in der Telemedizin: Zwei Anwendungsberichte aus Forschung und Industrie IT Trends Medizin / Health Telematics 2009 Dipl.-Inform. Sven Meister Wissenschaftlicher

Mehr

Sicherheitskonzepte in SOA auf Basis sicherer Webservices

Sicherheitskonzepte in SOA auf Basis sicherer Webservices HAW Hamburg Seminarvortrag - 16.12.2005 Thies Rubarth Folie 1 Sicherheit machen wir später...... wie hätt's auch anders sein sollen? Sicherheitskonzepte in SOA auf Basis sicherer Webservices Thies Rubarth

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

Christian J. Dietrich. 9. Kryptotag

Christian J. Dietrich. 9. Kryptotag Extended Access Control (epa epa) Christian J. Dietrich 2008-11-10 9. Kryptotag Inhalt 1. Einleitung 2. Der elektronische Personalausweis 3. Die Authentisierungsfunktion im Detail 4. Kurzvorstellung der

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

Kolloquium zur Diplomarbeit

Kolloquium zur Diplomarbeit Kolloquium zur Diplomarbeit Konzeption und prototypische Umsetzung von Authentifizierungsverfahren und Kommunikationsschnittstellen für das Identity-Management-System CIDAS unter besonderer Berücksichtigung

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216

WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216 WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit

Mehr

Offenes Benchmarking mit DMP Daten Diabetes Mellitus Typ 2 in Deutschland

Offenes Benchmarking mit DMP Daten Diabetes Mellitus Typ 2 in Deutschland Offenes Benchmarking mit DMP Daten Diabetes Mellitus Typ 2 in Deutschland 12. JÄNNER 2006 Institut für Medizinische Systemtechnik und Gesundheitsmanagement Elisabethstraße 11a, 8010 Graz Inhalt Inhaltsverzeichnis

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Datenschutzfokussiertes Sicherheitsmanagement einer elektronischen FallAkte (EFA) im Universitätsklinikum Aachen

Datenschutzfokussiertes Sicherheitsmanagement einer elektronischen FallAkte (EFA) im Universitätsklinikum Aachen Datenschutzfokussiertes Sicherheitsmanagement einer elektronischen FallAkte (EFA) im Universitätsklinikum Aachen Focussing on Data Protection Security Management of an Electronic Case Record (EFA) at the

Mehr

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen Herzlichen Dank! Projektleitung S.A.F.E.: Meinhard Wöhrmann (meinhard.woehrmann@olg-duesseldorf.nrw.de)

Mehr

April 10, 2012 CLOUD SERVICES WEGE ZU EINEM BÜRGERZENTRIERTEN GESUNDHEITSMANAGEMENT

April 10, 2012 CLOUD SERVICES WEGE ZU EINEM BÜRGERZENTRIERTEN GESUNDHEITSMANAGEMENT April 10, 2012 CLOUD SERVICES WEGE ZU EINEM BÜRGERZENTRIERTEN GESUNDHEITSMANAGEMENT Bedeutung der Cloud-Technologie 2 Als neues Schlagwort der Informationstechnik ist "Cloud Computing" in aller Munde,

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Das Ticketverfahren von D2D

Das Ticketverfahren von D2D Das Ticketverfahren von D2D Für die Verarbeitung und den Austausch von personenbezogenen Daten gilt bei elektronischen Methoden wie auch allgemein, dass dazu entweder ein Gesetz den Umgang regeln oder

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Datenschutz und Datensicherheit im Umfeld klinischer Anwendungen. Reinhard Vetter. Bayerischer Landesbeauftragter für den Datenschutz

Datenschutz und Datensicherheit im Umfeld klinischer Anwendungen. Reinhard Vetter. Bayerischer Landesbeauftragter für den Datenschutz Datenschutz und Datensicherheit im Umfeld klinischer Anwendungen Reinhard Vetter Bayerischer Landesbeauftragter für den Datenschutz Agenda I insb.rechtliche Rahmenbedingungen n Arztgeheimnis und Datenschutz

Mehr

Projekt CampusConnect Baden-Württemberg

Projekt CampusConnect Baden-Württemberg Projekt CampusConnect Baden-Württemberg Dr. Claudia Pauli Universität Ulm Berlin 11.05.2011 Kopplung von Campus Management und Learning Management Systemen Seite 2 Agenda Kopplung von ILIAS-Systemen untereinander

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

sage HR Zusatzmodul Digitale Personalakte Produktinformationen

sage HR Zusatzmodul Digitale Personalakte Produktinformationen sage HR Zusatzmodul Digitale Personalakte Produktinformationen Vorwort Für Ihr Interesse am Zusatzmodul Digitale Personalakte bedanken wir uns. Integrierte Sage HR Lösungen basierend auf einer Datenbank

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen Thomas Lenggenhager thomas.lenggenhager@switch.ch Bern, 11. Juni 2010 Übersicht Die Shibboleth basierte SWITCHaai

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Nutzerbeirat 2012 Bonn 20.11.2012

Nutzerbeirat 2012 Bonn 20.11.2012 Der neue Personalausweis Einsatzmöglichkeiten in der Lucom Interaction Platform Nutzerbeirat 2012 Bonn 20.11.2012 Henning Meinhardt Leiter Software Entwicklung Ab Version 3.2.2 unterstützt die LIP den

Mehr

Glossar zum S.A.F.E. Feinkonzept

Glossar zum S.A.F.E. Feinkonzept Glossar zum S.A.F.E. Feinkonzept Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz Version.Release:

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de

Identity Management Service-Orientierung. 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Identity Management Service-Orientierung 27.03.2007 Martin Kuppinger, KCP mk@kuppingercole.de Das Extended Enterprise verändert den Umgang mit Identitäten und Sicherheit Mitarbeiter Kunden Lieferanten

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen

Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen Höherwertige Schnittstellenkomponenten für den Datenaustausch im Gesundheitswesen C Ohr, M Krasser, Dr. R Brandner Mannheim, 06.09.2010 Agenda Kommunikationsstandards im Gesundheitswesen Notwendigkeit

Mehr

Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur

Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur Please quote as: Mauro, C.; Schweiger, A.; Sunyaev, A.; Leimeister, J. M. & Krcmar, H. (2007): Single Sign-On Clinic Card-Lösung - Ein Konzept zur zentralen Verwaltung von Gesundheitskarten im stationären

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Integration von. ERP-Systemen und epages 6. mit Webservices

Integration von. ERP-Systemen und epages 6. mit Webservices Integration von ERP-Systemen und epages 6 mit Webservices - Stand 10/2011 - Einleitung... 2 Grundlagen... 2 Überblick Datenaustausch... 3 Ablauf... 4 Verbindungstest... 4 Testen mit Beispieldaten... 4

Mehr

Identity as a Service

Identity as a Service Identity as a Service Michael Seeger Siemens IT Solutions and Services CISM. Identity as a Service Geschichtlicher Abriss Technik oder the gory details Voraussetzungen Business case Referenzen und Links

Mehr

Band M, Kapitel 7: IT-Dienste

Band M, Kapitel 7: IT-Dienste Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler ITSM Infoday 2013 Mit Business Process Management zu mehr Flexibilität, Transparenz und Stabilität Peter Brückler Copyright 2013 NTT DATA EMEA Ltd. Agenda Der Druck auf Unternehmen Business Process Management

Mehr

Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz

Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz Die Orientierungshilfe Schritte auf dem Weg zu einem praktikablen Datenschutz Bundesverband Gesundheits-IT e. V. Jan Neuhaus, Tieto Deutschland GmbH für AG Datenschutz IT-Trends, Düsseldorf, 21.9.2011

Mehr

Modernes Identitätsmanagement für das Gesundheitswesen von morgen

Modernes Identitätsmanagement für das Gesundheitswesen von morgen Modernes Identitätsmanagement für das Gesundheitswesen von morgen Berlin, 26.04.2012 Dr. Detlef Hühnlein, ecsec GmbH 2012 ID4health Copyright 2010 ecsec GmbH, All Rights Reserved. Agenda Ausgangssituation

Mehr

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur

Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Kontinuität der Behandlung Chancen durch die deutsche Telematikarchitektur Dr. Stefan Buschner gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh Friedrichstraße 136 10117 Berlin

Mehr

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor.

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor. Cloud Computing im Gesundheitswesen Cloud Computing ist derzeit das beherrschende Thema in der Informationstechnologie. Die Möglichkeit IT Ressourcen oder Applikationen aus einem Netz von Computern zu

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen SLA Software Logistik Artland GmbH Friedrichstraße 30 49610 Quakenbrück für das IT-System Meat Integrity Solution

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Sicherheit in Workflow-Management-Systemen

Sicherheit in Workflow-Management-Systemen Sicherheit in Workflow-Management-Systemen Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation KIT University of the State of Baden-Wuerttemberg and National Research Center of

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Der medizinische Fall Wie vernetzt man Leistungserbringer unterschiedlicher Sektoren datenschutzkonform?

Der medizinische Fall Wie vernetzt man Leistungserbringer unterschiedlicher Sektoren datenschutzkonform? Der medizinische Fall Wie vernetzt man Leistungserbringer unterschiedlicher Sektoren datenschutzkonform? Copyright Siemens AG 2010. All rights reserved. UK Aachen: regionale Kooperationen Page 3 Sep. 2010

Mehr

Vivantes Netzwerk für Gesundheit GmbH

Vivantes Netzwerk für Gesundheit GmbH Vivantes Netzwerk für Gesundheit GmbH IHE konforme mobile digitale Patientenakte ConhIT 2015 Auguste-Viktoria- Klinikum Humboldt-Klinikum Klinikum Am Urban Klinikum Hellersdorf Klinikum im Friedrichshain

Mehr

Fragen und Antworten zur elektronischen Gesundheitskarte (egk)

Fragen und Antworten zur elektronischen Gesundheitskarte (egk) Fragen und Antworten zur elektronischen Gesundheitskarte (egk) Einführungsphase 1 Wann kommt die elektronische Gesundheitskarte? Die gesetzlichen Krankenkassen beginnen nach intensiven Vorbereitungen ab

Mehr

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0 Leistungsbeschreibung PHOENIX Archiv Oktober 2014 Version 1.0 PHOENIX Archiv Mit PHOENIX Archiv werden Dokumente aus beliebigen Anwendungen dauerhaft, sicher und gesetzeskonform archiviert. PHOENIX Archiv

Mehr

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0.

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0. GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II Web Authentication & Authorization Service Februar Dezember 2002 Dokumentation Version 1.0 Teilnehmer AED Graphics con terra FhG ISST GIA GIUB

Mehr

Anonymität als Katalysator für elektronische Gesundheitsakten

Anonymität als Katalysator für elektronische Gesundheitsakten Anonymität als Katalysator für elektronische Gesundheitsakten Dr. Daniel Slamanig IAIK, Technische Universität Graz 7. Internationales For..Net-Symposium Anonymität. Recht Technik Menschenbild 20. April

Mehr

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards:

MSP SSO. Portalübergreifendes Single Sign-on. Von MSP SSO unterstützte Standards: MSP SSO Portalübergreifendes Single Sign-on Für das Abwickeln von Online- Geschäftsprozessen ist es wichtig, sein Gegenüber zu kennen. Das gilt sowohl für den Kunden als auch den Betreiber des Online-

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Agfa HealthCare GmbH Konrad-Zuse-Platz 1-3 53227 Bonn für das IT-System IMPAX/web.Access die Erfüllung aller

Mehr

Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management

Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management 7. Treffen der IT-Betriebszentren im Hochschulbereich 26. September 2007 Wolfgang Hommel, Leibniz-Rechenzentrum

Mehr

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011

NetScaler Integration bei Hellmann Worldwide Logistics. Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 NetScaler Integration bei Hellmann Worldwide Logistics Benjamin Kania IS Enterprise Services Manager Hannover, 13.10.2011 Agenda Firmenporträt Das Projekt Details zur Umsetzung Fazit Fakten & Zahlen Mitarbeiter

Mehr

Elektronische Gewerbemeldung

Elektronische Gewerbemeldung E-Government in der IHK-Organisation Elektronische Gewerbemeldung Arbeitshilfe für die Prozess-Implementierung: Technische Rahmenbedingungen für die Anlieferung von Gewerbemeldungen an die IHK-Organisation

Mehr

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung Einleitung und Motivation Medizinische IT-Anwendungssysteme komplexe hoch funktionale Systeme Basisfunktionen

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1 Datenschutzerklärung Datum: 16.12.2014 Version: 1.1 Datum: 16.12.2014 Version: 1.1 Verantwortliche Stelle im Sinne des Bundesdatenschutzgesetzes ist: Deutsch-Iranische Krebshilfe e. V. Frankfurter Ring

Mehr

DICOM Adapter IDeal HL7 PVS. Leistungsbeschreibung. Version 1.0

DICOM Adapter IDeal HL7 PVS. Leistungsbeschreibung. Version 1.0 DICOM Adapter IDeal KIS HL7 Cloverleaf DICOM Modalität Worklist Leistungsbeschreibung Version 1.0 PVS Dachauer Str. 11, D-80335 München Tel.: +49-(0)89-599 88 76-0 Fax: +49-(0)89-599 88 76-11 Info@Health-Comm.de

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.

Zusicherung von Qualitätskriterien bei WebServices. Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07. Zusicherung von Qualitätskriterien bei WebServices Dr. Bernhard Humm, Matthias Geiß sd&m-konferenz 2003 Web Services 17./18.07.2003 Agenda Verteilte Systeme am am Beispiel Beispiel Aspekte von Verteilung

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr