Einführung der Gesundheitskarte

Transkript

1 Einführung der Gesundheitskarte Spezifikation der Broker Services BROKER SERVICE AUDIT SERVICE SECURITY SERVICES Version: Stand: Status: freigegeben gematik_inf_brokerservices_v1_1_0.doc Seite 1 von 175

2 Dokumentinformationen Änderungen zur Vorversion Die Änderungen im aktuellen Dokument betreffen neben dem Broker Service i. e. S. insbesondere den Auditdienst (Audit Service) als die Komponente zur versichertenzentrierten Protokollierung der Zugriffe auf die Telematikinfrastruktur. Eingearbeitet wurden dabei Änderungen zu Umfang und Ablage der im Auditprotokoll abzulegenden Daten (Reduktion und versichertenindividuelle Verschlüsselung der Auditdaten) sowie die Einbindung des Aufrufs des Audit Service in die Verarbeitung von Telematiknachrichten (asynchron statt synchron). Im Abschnitt über den Broker Service wurde das Konzept der Brokersequenz als Bausteine der Broker-Sequenzen eingeführt. Inhaltliche Änderungen gegenüber der Vorversion sind gelb markiert. Sofern ganze Kapitel eingefügt wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gembroker] gematik ( ): Einführung der Gesundheitskarte - Spezifikation der Broker Services Version Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Ersterstellung und Grobstrukturierung gematik, AG bis /06 bis 11/06 Ausgestaltung der Kapitel gematik, AG interne QS gematik, AG Einarbeitung der Review-Kommentare gematik, AG freigegeben zur Vorkommentierung gematik Einarbeitung externer Review-Kommentare gematik, AG freigegeben gematik Einarbeitung der Änderungen am AuditS gematik, AG Einarbeitung der Review Kommentare gematik, AG freigegeben gematik gematik_inf_brokerservices_v1_1_0.doc Seite 2 von 175

3 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Aufbau und Inhalt des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Verwendung von Schlüsselworten und Konventionen Verwendung von Schlüsselworten Konventionen zur Kennzeichnung von Referenzen und Abkürzungen Konventionen zur Kennzeichnung von Architektur-Tiers Konventionen zur Kennzeichnung von offenen Punkten Notationen Anforderungen und Annahmen Einleitung Funktionale Anforderungen Nichtfunktionale Anforderungen Funktionale Annahmen Nichtfunktionale Annahmen Die Broker Services im Überblick Einordnung: Telematik-Gesamtarchitektur Primärsysteme (Consumer Tier) Telematikinfrastruktur (Telematik-Tier) Fachdienste (Service Provider Tier) Die Broker Services als Teil der Telematikinfrastruktur Aufgaben der Telematikinfrastruktur Aufgaben und Ziele der Broker Services...25 gematik_inf_brokerservices_v1_1_0.doc Seite 3 von 175

4 4.3 Die Broker Services im Einzelnen Basisfunktionalität Architektur Deploymentsicht Broker-Instanzen Registrierungsinstanzen Auditinstanzen Netzwerksicht Anbindung VPN-Zugangsnetz Anbindung an das Backend-Netzwerk Sicherheitssicht Kommunikationssicht Broker Service (i. e. S.) Security Services (TrustedS, SVS, SCS) Schnittstellen TrustedS zu SVS und SCS Schnittstelle SVS zum OCSP-Responder Schnittstelle SCS zu Hardware Security-Modul ( Krypto-Box ) Hochverfügbarkeitssicht Aspekte der Hochverfügbarkeit: Cluster, Ausfallsicherheit und Lastverteilung Globales vs. lokales Clustering: Gesamtsicht vs. Betreibersicht Globale Lastverteilung: Sektorales Betreibermodell Globales Failover: Rückfallszenario bei Ausfall eines Betreibers Lokale Lastverteilung innerhalb eines Betreibers Lokales Failover: Ausfallsicherheit innerhalb eines Betreibers Verteilungssicht Physische Architektur von Broker- und Security-Instanzen Netzwerkanbindung von Broker- und Security-Instanzen Verfügbarkeitsstrategie für Broker- und Security-Instanzen Skalierungsstrategie für Broker- und Security-Instanzen Physische Architektur von Auditinstanzen Netzwerkanbindung von Auditinstanzen Verfügbarkeitsstrategie für Auditinstanzen Skalierungsstrategie für Auditinstanzen Konzeptionelle Umsetzung Plattformunabhängigkeit der Services Web Services als plattformunabhängige Remoting-Technologie Remoting, Plattformunabhängigkeit und Performance Versichertenzentrierte Auditierung von Online-Datenzugriffen Verarbeitungssteuerung durch Broker-Sequenzen Begriffsdefinition: Broker-Sequenz Abgrenzung: Servicetypen vs. Broker-Sequenzen Konfiguration Sequenzschritte Sequenzschritt: Auditierung Sequenzschritt: Anonymisierung Sequenzschritt: Fachdienstaufruf Abarbeitung Leersequenz...56 gematik_inf_brokerservices_v1_1_0.doc Seite 4 von 175

5 5.3.6 MessageTrace Fehlerbehandlung Fachlicher Fehler Technischer Fehler in einem aufgerufenen Service Technischer Fehler im Broker Transaktionssicherheit Caching von Verzeichnis-Informationen (SDS Registry Cache) Abwehr von Replay-Attacken Beispielszenarien Beispiel 1: Update Versichertenstammdaten initiieren Beispiel 2: Verordnung dispensieren Sicherheitsaspekte Allgemeine Grundsätze Konformität mit 291a: Zweistufigkeit der Sicherheitsservices Hybride Verschlüsselung aller medizinischen Daten Nachrichtenbasierte Authentisierung Sicherheitszonen und Sicherheitsdienste Konsequenzen aus der Bedrohungsanalyse Grundsätzliche Überlegungen Maßnahmen zur Abwehr konkreter Bedrohungen System Management Perspektiven auf das System Management Zentrale Überwachung der Service Level Agreements Verfügbarkeit (Availability) Lastzahlen und Antwortzeiten (Performance) Dezentrales Monitoring und Management der Broker Services Lokale Monitoringschnittstellen Lokale Managementschnittstellen Serviceübergreifende Festlegungen Verwendung von Standards Telematikweites Protokoll für den Nachrichtenaustausch Spezifikation TelematikTransport-Details TelematikTransport-Adaptierung Struktur der Telematiknachrichten Transport-Header Telematik-Header Security-Header Body (Fachdaten) Beidseitige Authentifizierung auf Transportebene...76 gematik_inf_brokerservices_v1_1_0.doc Seite 5 von 175

6 8.4 Anforderungen aus Netzwerksicht Anforderungen an Web Service-Endpunkte Anforderungen an Web Services-Clients Anforderungen an sonstige TCP-basierte Netzwerkverbindungen TelematikCoreMessage vs. Standard-Szenario für Web Services Konfiguration und Versionierung Konfiguration der Broker Services i. w. S Versionierung in der Telematikinfrastruktur Änderung von Broker-Sequenzen zu einem Stichtag Transparente Versionierung des Fachdiensts Extern sichtbare Versionierung des Fachdiensts über neue URL Versionierung der Transportschnittstelle (Telematiknachricht) Fehlerbehandlung Struktur der Servicebeschreibungen Aufbau der Kapitel zur Servicebeschreibung XML-Schema-Beschreibungen und Web Service-Definitionen Broker Service i. e. S. (BrokerS) Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Prüfung der Broker-Sequenz Konfiguration Bestimmen der Broker-Sequenz Lokalisierung mit Hilfe des Verzeichnis-Cache Lokalisierung der Auditinstanzen im Verzeichnis-Cache Lokalisierung der Fachdienste im Verzeichnis-Cache Abarbeiten der Broker-Sequenz Sequenzschritt Auditierung Sequenzschritt Anonymisierung Sequenzschritt Fachdienstaufruf Service-Operationen Operation TelematikExecute Validieren der Nachricht gegen das XML-Schema der TelematikEnvelope Initialisierung und Aktualisierung des Verzeichnis-Cache Service Consumer Schnittstellen Schnittstelle zum Audit Service Schnittstellenbeschreibung AuditS:WriteAudit Schnittstelle zu den Security Services (hier: TrustedS) Schnittstellenbeschreibung TrustedS:Anonymize Schnittstelle zum Registrierungsdienst (SDS)...97 gematik_inf_brokerservices_v1_1_0.doc Seite 6 von 175

7 Schnittstellenbeschreibung SDS:get_registeredInfo Schnittstellenbeschreibung SDS:find_binding Schnittstellenbeschreibung SDS:get_bindingDetails Schnittstellenbeschreibung SDS:find_service Schnittstelle zu den Fachanwendungen Schnittstellenbeschreibung <Fachdienst>:Execute Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Audit Service (AuditS) Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Datenpflege Versichertenindividuelle Verschlüsselung Kartenabhängiges symmetrisches Master-Key-Verfahren Verschlüsselte Auditierung Lesezugriff auf das Auditprotokoll Datenerhalt: Historie kartenabhängiger Pseudonyme Auditinformationen Datenelemente für Auditeinträge Struktur der AuditMessage Ermittlung der Audit Service-Instanz für einen Versicherten Schutz der Integrität der Auditprotokolle Service-Operationen WriteAudit Request Response Service Consumer Schnittstellen Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Security Services Überblick Anforderungen und Annahmen Fachliche Anforderungen Annahmen Konzeptionelle Umsetzung Service-Operationen gematik_inf_brokerservices_v1_1_0.doc Seite 7 von 175

8 Operation Anonymize (Trusted Service) Operation Validate (Security Validation Service) Operation Sign (Security Confirmation Service) Service Consumer Schnittstellen Schnittstelle zum OCSP-Responder Konfiguration Fehlerhandling Management- und Monitoringschnittstelle Service Level Objectives und Volumenmodell Einordnung Segmentierung der SLOs: Segment Broker-Operationen Mengengerüste Verfügbarkeitsanforderungen Verfügbarkeitskategorien Verfügbarkeitsziele für das Segment Broker-Operationen Antwortzeitverhalten Antwortzeitziele Antwortzeitvorgaben für das Segment Broker-Operationen Fehlermanagement, Logging und Tracing Fehlermanagement Abgrenzung: Fehler als unerwartete Abweichungen Informationsmodell: Fehlerschlüssel und Fehlerdetails Fehlerschlüssel Fehlerdetails Anforderungen an die Fehlerbehandlung Transport von Fehlern in der Telematikinfrastruktur Persistentes Speichern von Fehlern in der Telematikinfrastruktur Bereitstellung von Fehlerschlüsseln für das System Management Normative Fehlermeldungen in den Broker Services Logging und Tracing Begriffsbestimmung: Logging vs. Tracing Konzepte für das Logging und Tracing Loglevel Logger Appender Layouts Anforderungen an die Logging- und Tracing-Komponente Datensicherheit Regeln für Log-Meldungen ohne konkreten Fehlerbezug Regeln für Log-Meldungen mit konkretem Fehlerbezug gematik_inf_brokerservices_v1_1_0.doc Seite 8 von 175

9 Anhang A A1 Abkürzungen A2 - Glossar A3 - Abbildungsverzeichnis A4 - Tabellenverzeichnis A5 - Referenzierte Dokumente Anhang B: Leseanleitung für XML-Schema-Fragmente Anhang C: XML-Schema für die Konfiguration der Broker-Sequenzen Anhang D: Broker-Sequenzen Offene Punkte gematik_inf_brokerservices_v1_1_0.doc Seite 9 von 175

10 1 Zusammenfassung Mit Verabschiedung des Gesetzes zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz GMG) wurde die Einführung der elektronischen Gesundheitskarte (egk) für das deutsche Gesundheitswesen beschlossen. 291b des Fünften Sozialgesetzbuches (SGB V), welches zum in Kraft getreten ist, fordert in der Konsequenz den Aufbau und Betrieb der für die Einführung und Anwendung der egk erforderlichen Telematikinfrastruktur. Innerhalb dieser Infrastruktur sind zentrale Brokerdienste bereitzustellen, welche zur Vermittlung von Nachrichten innerhalb der Telematikinfrastruktur zwischen den Konnektoren, Fachdiensten und anderen mittelbaren oder unmittelbaren Diensten dienen. Die sogenannten Broker Services (i. w. S.) bestehen aus mehreren miteinander interagierenden Diensten: Broker Service (BrokerS i. e. S.), Registrierungsdienst (Service Directory Service, SDS), Audit Service (AuditS) sowie Trusted Service (TrustedS) mit den Unterservices Security Validation Service (SVS) und Security Confirmation Service (SCS). Bis auf den Registrierungsdienst (SDS) erfolgen die Spezifikationen all dieser Services in diesem Dokument. Der Registrierungsdienst wird im Dokument [gemregd] beschrieben, weil er eine standardisierte Schnittstelle implementiert, während die oben genannten Dienste Individuallösungen darstellen. Der Broker Service vermittelt auf der Basis von Aufrufketten, den sog. Broker-Sequenzen, Telematiknachrichten innerhalb der Telematikinfrastruktur. Mittels des Registrierungsdiensts (SDS) lokalisiert er die zu adressierenden Fachdienste. Durch Einbeziehung des Trusted Service und der nachgelagerten Dienste SVS und SCS anonymisiert er bestimmte Nachrichtentypen, indem er Signaturen von Heilberuflern validiert, die Rolle aus dem zur Signatur gehörigen Zertifikat in die Nachricht überträgt und durch eine eigene Signatur bestätigt. Der Audit Service protokolliert versichertenzentriert alle Online-Zugriffe auf die Telematikinfrastruktur. Das Konzept der Broker Services basiert auf dem serviceorientierten Architekturansatz ({SOA}) unter Verwendung eines intermediären Kommunikationsstils. Physisch werden die Broker Services als lastverteilte Mehrschichtarchitektur umgesetzt, wobei vor allem die Hochverfügbarkeit der Dienste im Vordergrund steht. gematik_inf_brokerservices_v1_1_0.doc Seite 10 von 175

11 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Die Einführung der elektronischen Gesundheitskarte bedingt den Betrieb verschiedener verteilter Dienste und Komponenten, angefangen von dezentralen Komponenten, wie dem Konnektor, über zentrale Dienste der Telematikinfrastruktur wie Vermittlungs- und Anonymisierungsdienste, Lokalisierungsdienste, Zertifikatserstellungs- und prüfungsdienste (PKI). Gegenstand dieses Dokuments ist die Spezifikation der sog. Broker Services als der zentralen dienstevermittelnden ( intermediären ) Komponente der Telematikinfrastruktur. Die Spezifikation von Protokollen, Komponenten und Diensten im Kontext der Broker Services erfolgt insbesondere mit Sicht auf den Broker als Gateway-Komponente zu den Fachanwendungen, die mit Hilfe von Web Service-Technologien zu implementieren ist. Die Vertraulichkeit und Integrität der vom Broker bearbeiteten Daten wird dabei durch Verschlüsselung und Signatur auf der Basis kryptographischer Verfahren umgesetzt. Zusätzliche Sicherheit wird gewährleistet durch den Betrieb eines abgesicherten Netzes, das nur Benutzergruppen zugänglich ist, die nachweislich authentisiert wurden sowie Komponenten nutzen und Dienste verwenden, deren Authentizität und Zulassungsstatus verifizierbar ist. Diese Spezifikation baut auf der Gesamtarchitektur für die Einführung der Gesundheitskarte [gemgesarch] auf und berücksichtigt dadurch die Architekturentscheidungen der Gesellschafter der gematik und des Architekturboards. Das Gesamtarchitektur-Dokument ist Grundlage und Ausgangspunkt des vorliegenden Dokuments. Wo es zur eigenständigen Lesbarkeit dieser Spezifikation 1 erforderlich ist, werden bewusst Redundanzen in Kauf genommen und Inhalte aus der Gesamtarchitektur wiedergegeben. Diese Stellen sind dann aber eindeutig durch Verweise auf die entsprechenden Abschnitte bzw. Abbildungen aus der Gesamtarchitektur gekennzeichnet. Im Zweifelsfall haben die Festlegungen des Gesamtarchitektur-Dokumentes Vorrang. 2.2 Aufbau und Inhalt des Dokuments Die Spezifikation des Broker Service umfasst die folgenden Themenbereiche: Kapitel 1 Zusammenfassung Kapitel 1 fasst im Sinne eines Management Summary die inhaltlichen Kernaussagen dieses Dokumentes zusammen. 1 d. h. unabhängig davon, ob dem Leser gleichzeitig auch das Gesamtarchitektur-Dokument [gemgesarch] vorliegt gematik_inf_brokerservices_v1_1_0.doc Seite 11 von 175

12 Kapitel 2 Einführung Das vorliegende Kapitel 2 beschreibt die Zielsetzung, Gliederung, Zielgruppen, Geltungsbereich, Arbeitsgrundlagen und Rahmenbedingungen für dieses Dokument sowie die Abgrenzung zu anderen, thematisch verwandten Dokumenten. Kapitel 3 Anforderungen und Annahmen Im Rahmen des Kapitels Anforderungen werden die wichtigsten funktionalen und nichtfunktionalen Anforderungen an die Broker Services als der zentralen Vermittlungskomponente tabellarisch erfasst. Spätere Dokumentteile referenzieren diese Anforderungen, um den Bezug zwischen Lösungsvorschlag und Problemstellung herzustellen. Anforderungen, die sich auf die Spezifikation anderer Komponenten beziehen und dort noch nicht abschließend festgelegt sind, werden gesondert als Annahmen aufgeführt. Sie dienen als Arbeitshypothesen bis zu ihrer Bestätigung im Rahmen des Anforderungsmanagements. Diese Verfahrensweise ist notwendig, da wesentliche Teile der fachlichen und technischen Spezifikationen der gematik aktuell parallel zu diesem Dokument entstehen und somit die Konsistenz von Anforderungen nicht abschließend prüfbar ist. Kapitel 4 Die Broker Services im Überblick Der Überblick beschreibt Zweck, Grundlagen, Basisfunktionalität und die Grobstruktur der Broker Services. Ausgangspunkt sind dabei die in Kapitel 3 formulierten Anforderungen sowie andere referenzierte Dokumente, insbesondere die Gesamtarchitektur [gemgesarch], die Bedrohungs- und Risikonanalyse [gembur] und das Netzwerkkonzept [gemnet]. Hierzu wird die Einordnung der Broker Services in die Telematik-Tier der Gesamtarchitektur hergeleitet, die Basisfunktionalität und zugrunde liegende Architektur beschrieben sowie eine Trennung der Sicherheits- und Funktionsbereiche vorgenommen und erklärt. Außerdem werden die detaillierteren technischen Spezifikationen in den folgenden Abschnitten begründet. Kapitel 5 Konzeptionelle Umsetzung In diesem Kapitel werden einige konzeptionelle Hintergründe zur gewählten Architektur näher beleuchtet bzw. auf geeignete Abschnitte der Gesamtarchitektur [gemgesarch] verwiesen, in denen weiterführende Informationen zu finden sind. Es wird insbesondere das Konzept der Broker-Sequenzen eingeführt, über die sich die durchzuführenden Abarbeitungsschritte für eine beim Broker eintreffende Nachricht in Abhängigkeit vom Servicetyp flexibel konfigurieren lassen. Außerdem werden zwei Beispiele für Broker-Sequenzen zur Abbildung fachlicher Use Cases angegeben. gematik_inf_brokerservices_v1_1_0.doc Seite 12 von 175

13 Kapitel 6 Sicherheitsaspekte Die wichtigsten Grundsätze der Sicherheitsarchitektur für die Telematikinfrastruktur und die aus der Bedrohungsanalyse resultierenden Konsequenzen für die Spezifikation der Broker Services werden erläutert. Kapitel 7 System Management Die Konfiguration und insbesondere der laufende Betrieb des Brokers und der ihm zugeordneten Services müssen sorgfältig geplant und ständig überwacht werden. In Erfüllung ihrer Betriebsverantwortung überwacht die gematik die Einhaltung von Service Level Agreements durch die Betreiber von Broker-Instanzen mit Hilfe von Agenten, die Testnachrichten an die Broker-Komponenten senden. Eine nähere Spezifikation erfolgt in [gemsysmgmt]. Ergänzend stellen die Broker Services ein eigenes Management- und Monitoring-API für die lokale Überwachung und Sicherstellung der Service Level Agreements durch die Betreiber zur Verfügung. Kapitel 8 Serviceübergreifende Festlegungen In diesem Kapitel werden alle Festlegungen von serviceübergeifendem Charakter getroffen, die in gleicher Weise für die in den Kapiteln 10 bis 12 beschriebenen Services gelten. Dazu gehören die zu verwendenden Standards und Kompatibilitätsanforderungen, die Definition der Telematiknachrichtenstruktur, Anforderungen zu Konfigurationsmanagement und Versionierung sowie zur fachlichen Fehlerbehandlung. Kapitel 9 Struktur der Servicebeschreibungen Dieses Kapitel definiert die Struktur der Servicebeschreibungen für die einzelnen Schnittstellen, wie sie für die Beschreibung der Services in den Kapiteln 10 bis 12 verwendet wird. Kapitel 10 Broker Service i. e. S. (BrokerS) In diesem Kapitel wird der Broker Service i. e. S. als zentraler Verteilerknoten der Telematikinfrastruktur im Detail spezifiziert. Kapitel 11 Audit Service (AuditS) Dieses Kapitel beschreibt die Detailfunktionalität sowie die Schnittstellen des Audit Service. Dieser Dienst übernimmt die versichertenzentrierte Auditierung von Zugriffen auf die Fachdienste über die Telematikinfrastruktur. Kapitel 12 Security Services (SVS, SCS, TrustedS) Im Kapitel 12 werden die Security Services spezifiziert: Auf der Strecke zwischen Konnektoren (Service-Consumer-Tier) und Fachdiensten (Service- Provider-Tier) anonymisiert der Broker mit Hilfe der Security Services, gematik_inf_brokerservices_v1_1_0.doc Seite 13 von 175

14 abhängig von der eingehenden Nachricht, die Heilberufler-Identitäten in der Nachrichten. Kapitel 12 Security Services (SVS, SCS, TrustedS) Im Kapitel 12 werden die Security Services spezifiziert: Auf der Strecke zwischen Konnektoren (Service-Consumer-Tier) und Fachdiensten (Service- Provider-Tier) anonymisiert der Broker mit Hilfe der Security Services, abhängig von der eingehenden Nachricht, die Heilberufler-Identitäten in der Nachrichten. Kapitel 13 Service Level Objectives und Volumenmodell In Ergänzung der nicht-funktionalen Anforderungen ist in betrieblicher Hinsicht die detaillierte Formulierung spezieller Zielgrößen für die Dienstgüte (Quality of Service) erforderlich. Diese werden als Service Level Objectives {SLO} bezeichnet. Die endgültige Festlegung konkreter Service Level Objectives für die Broker Services kann erst nach der Definition detaillierter Mengengerüste für die einzelnen fachlichen Use Cases (anstelle der augenblicklichen Grundsatzannahmen zum Volumenmodell) und eingehender Abstimmung mit verschiedenen Arbeitsgruppen der gematik erfolgen und in dieses Dokument mit aufgenommen werden. Kapitel 14 Fehlermanagement, Logging und Tracing Das Kapitel beschäftigt sich mit den Anforderungen an das Fehlermanagement innerhalb der Broker Services sowie den Anforderungen an ein Logging und Tracing-Framework. Dieses Dokument ist unter der Prämisse entstanden, dass die Spezifikation in ihrer Gesamtheit Herstellerunabhängigkeit und Produktneutralität gewährleisten muss. Dies bedingt, dass die Spezifikation in ihrer Gesamtheit wesentlich allgemeiner bleiben muss als bei einer Orientierung an proprietären Lösungen, da sie nur auf herstellerübergreifenden Standards aufbauen kann. Der Vorteil dieses Verfahrens liegt jedoch in der Offenheit, Stabilität und Verfügbarkeit vieler alternativer Produkte bzw. Frameworks für die Implementierung einer Lösung zu einer konkreten Problemstellung. 2.3 Zielgruppe Dieses Dokument richtet sich primär an: die Beteiligten im Angebotsprozess bzw. bei der Vertragsgestaltung für die Entwicklung und Implementierung des Broker Services (seitens gematik und seitens des jeweiligen Anbieters/Vertragspartners) Business-Analysten, Architekten und Entwickler desjenigen Anbieters/Unternehmens, das Vertragspartner für die Entwicklung und Implementierung ist bzw. wird. die Rechtsabteilung der gematik (mittelbar) gematik_inf_brokerservices_v1_1_0.doc Seite 14 von 175

15 die Arbeitsgruppe Entwicklung der gematik (als Leitfaden für eine prototypische Implementierung der Broker Services) die Beteiligten bei der Vertragsgestaltung für den Produktionsbetrieb der Broker Services (seitens gematik und seitens des jeweiligen Anbieters/Vertragspartners). alle sonstigen Personen und/oder Institutionen innerhalb und außerhalb der gematik, die mittelbar oder unmittelbar an Architektur, Design, Entwicklung, Betrieb und System Management der Software- und Infrastrukturkomponenten für die Broker Services beteiligt sind. 2.4 Geltungsbereich Alle in diesem Dokument vorgenommenen Festlegungen sind im Kontext der Telematikinfrastruktur des Gesundheitswesens als verbindlich zu betrachten, außer dort, wo dies explizit ausgewiesen wird. 2.5 Arbeitsgrundlagen Grundlage für die Spezifikation der Broker Services bilden die Anforderungen und Festlegungen aus den folgenden Dokumenten: gematik Gesamtarchitektur [gemgesarch] gematik Bedrohungs- und Risikoanalyse [gembur] nicht öffentlich gematik Schutzbedarfsfeststellung [gemschbedf] nicht öffentlich gematik Sicherheitsanforderungen an die Infrastrukturdienste Broker Services [gemsha_br] gematik Sicherheitsanforderungen an die Infrastrukturdienste Allgemeiner Teil [gemsha_allg] gematik Netzwerkspezifikation [gemnet] gematik Spezifikation Fehlerbehandlung [gemspec_fm] gematik System und Service Level Monitoring [gemsysslm]. gematik Spezifikation TelematikTransport-Details [gemspec_ttd] gematik Spezifikation von Versionsnummern in Schnittstellendefinitionen und Software-Komponenten [gemspec_versnr] gematik Policy [gempolicy] gematik Anforderungen aus Sicht der Wartbarkeit und Änderbarkeit der TI (in Vorbereitung) [gemga_wartg] gematik_inf_brokerservices_v1_1_0.doc Seite 15 von 175

16 gematik Spezifikation des Registrierungsdienstes [gemregd] Diese wie alle weiteren in diesem Konzeptpapier referenzierten fachlichen und technischen Dokumente sind in Anhang A5 aufgelistet. 2.6 Abgrenzung des Dokuments Nicht im Fokus dieses Dokuments sind konzeptionelle Überlegungen zu Netzwerk- Infrastruktur und -Routing, sowie zum Namensdienst (DNS) und Systemzeitdienst (NTP). Existenz und Verfügbarkeit dieser physikalischen und logischen Komponenten werden allerdings vorausgesetzt. Details hierzu finden sich in [gemnet] und [gemntp]. Ebenfalls nicht im Fokus der Betrachtungen sind die Ausprägung anderer Telematikinfrastruktur- und Anwendungsschicht-Dienste (z. B. Verzeichnisdienste, PKI, Datenbank- Anwendungen, etc.) sowie betriebliche Belange. Diesbezüglich wird auf die Arbeitsergebnisse der anderen Arbeitsgruppen der gematik verwiesen. Dieses Dokument macht mit Absicht keinerlei Aussagen oder Empfehlungen hinsichtlich der zu verwendenden Softwareprodukte, Frameworks oder Hardwareplattformen und ist somit insbesondere herstellerneutral. Im Dokument wird mehrfach der Begriff Web Service Provider bzw. von Web Service Consumer verwendet. Diese Begriffe werden hier im Kontext einer serviceorientierten Architektur verwendet. Dieses Konzept basiert auf einer Anzahl voneinander unabhängiger, lose gekoppelter Dienste. Ein Dienst wird von einem Service Provider angeboten. Ein Service Consumer stellt eine Anfrage (Service Request) an einen Dienst und empfängt daraufhin eine Antwort (Service Response) vom Anbieter. Für den Zugriff aus der Consumer Tier (Primärsysteme der Leistungserbringer) ist dabei nur die Schnittstelle zwischen dem Consumer Adapter (Konnektor) und dem Broker Service i. e. S. (siehe Kapitel 10) relevant. Alle übrigen hier beschriebenen Services stellen also keine Funktionalität der Telematik Tier bzw. Service Provider Tier nach außen zur Verfügung. 2.7 Verwendung von Schlüsselworten und Konventionen Verwendung von Schlüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden und in Großbuchstaben geschriebenen deutschen Schlüsselworte verwendet: MUSS. Absolut gültige und normative Festlegungen sind durch das Schlüsselwort MUSS gekennzeichnet. DARF NICHT. Absolut gültige und normative Ausschlüsse sind durch das Schlüsselwort DARF NICHT gekennzeichnet. SOLL. Empfehlungen zu Festlegungen sind durch das Schlüsselwort SOLL gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. gematik_inf_brokerservices_v1_1_0.doc Seite 16 von 175

17 SOLL NICHT. Empfehlungen zu Ausschlüssen sind durch das Schlüsselwort SOLL NICHT gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. KANN bzw. Vollständig fakultative Eigenschaften sind durch das Schlüsselwort KANN gekennzeichnet und haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. OPTIONAL. Wahlweise freigestellte Funktionen sind durch das Schlüsselwort OPTIONAL gekennzeichnet. Sie haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. Jedoch muss bei Verzicht auf die Eigenschaften die uneingeschränkte Funktionalität des beschriebenen Sachverhaltes sichergestellt sein Konventionen zur Kennzeichnung von Referenzen und Abkürzungen Referenzen auf weitere Dokumente und Standards sind in [eckige Klammern] gesetzt und werden im Anhang aufgelöst. Abkürzungen werden bei ihrer ersten Verwendung in {geschweifte Klammern} gesetzt und werden im Abkürzungsverzeichnis aufgelöst Konventionen zur Kennzeichnung von Architektur-Tiers Die Gesamtarchitektur unterscheidet insgesamt sechs Tiers (engl. Fachbegriff für Architekturebene; siehe [gemgesarch], Abschnitt 5: Logische Architektur Tier- und Systemgrenzen). Abbildung 1: Architektur-Tiers und Systemgrenzen In den Abbildungen werden wo immer möglich die folgenden farblichen Konventionen für die Tiers verwendet: Komponenten, Services und Funktionen der Service-Consumer und -Adapter Tiers sind ROT markiert Komponenten, Services und Funktionen der Telematik und Provider-Adapter-Tiers sind GELB markiert Komponenten, Services und Funktionen des Service-Provider-Tiers sind GRÜN markiert gematik_inf_brokerservices_v1_1_0.doc Seite 17 von 175