Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifendes Datenschutz- und Sicherheitskonzept der TI

Version
3.2.1
Revision
1511152
Stand
02.02.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemKPT_DS_Sich_TI

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Es handelt sich um eine inhaltliche Weiterentwicklung des Dokuments. Neben redaktionellen Änderungen wurde insbesondere der Abschnitt zur TI 2.0 aktualisiert und ein Abschnitt zur Einbindung der TI in den Europäischen Gesundheitsdatenraum ergänzt.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Das vorliegende Dokument ist das übergreifende Datenschutz- und Sicherheitskonzept zur Telematikinfrastruktur (TI) des deutschen Gesundheitswesens.

1.1 Zielsetzung

Dieses Dokument hat zum Ziel die Umsetzung des Datenschutzes und der Informationssicherheit in der Telematikinfrastruktur auf einem übergeordneten und produktübergreifenden Niveau darzustellen. Dazu wurden strategische Aspekte und methodische Grundlagen sowie die Sicherheitsarchitektur der Telematikinfrastruktur in ihren technischen und organisatorischen Aspekten beschrieben.

1.2 Zielgruppe

Dieses Konzept richtet sich an die gematik sowie an Aufsichtsbehörden, die für die Telematikinfrastruktur bzw. die gematik zuständig sind.

1.3 Geltungsbereich

Dieses Dokument hat informativen Charakter. Es ist ein zu den normativen Regelungen (Konzepte, Leitlinien, Richtlinien, Arbeitsanweisungen) für die gematik und den Spezifikationen der gematik für die Telematikinfrastruktur begleitendes Dokument, welches die Grundlagen und Rahmenbedingungen für die dort getroffenen Maßnahmen des Datenschutzes und der Informationssicherheit beschreibt.

1.4 Abgrenzung des Dokuments

Dieses Datenschutz- und Sicherheitskonzept beschreibt die Rahmenbedingungen, die Datenschutz- und Sicherheitsstrategie sowie die Sicherheitsarchitektur in übergreifender Weise für die gesamte TI. Damit weichen die Inhalte dieses Dokuments von üblichen Datenschutz- bzw. Sicherheitskonzepten ab – ausgenommen Anhang B. Dort finden sich Ergebnisse mit übergreifendem Charakter aus der Anwendung der von der gematik verwendeten Methoden für anwendungs- bzw. komponenten- bzw. dienstspezifische Datenschutz- und Sicherheitskonzepte.

Das Dokument enthält keine unmittelbar auf ein Produkt, Hersteller oder Anbieter wirksamen Maßnahmen bzw. Anforderungen. Diese werden in weiteren Dokumenten der gematik formuliert.

Das Datenschutz- und Sicherheitskonzept gliedert sich wie folgt in eine Dokumentenhierarchie ein:

Abbildung 1: Dokumentenhierarchie

1.5 Methodik

Im Rahmen dieses Dokuments wird der Begriff „Verarbeitungsvorgang“ aus der Datenschutz-Grundverordnung [DSGVO] synonym zum Begriff „Anwendungsfall“ aus den Dokumenten der gematik verwendet.

Der hier verwendete Begriff „Anwendung“ ist synonym zum Begriff „Fachanwendung“, wie er in anderen Dokumenten der gematik verwendet wird.

Der Begriff „digitale Identitäten“, der hier, wie im SGB V, verwendet wird, entspricht dem Begriff „elektronische Identität“, wie er z.B. in [TR03107] verwendet wird.

2 Rahmenbedingungen

Die Telematikinfrastruktur ist die nationale Arena, in der alle Akteure des deutschen Gesundheitswesens zusammenspielen. Als Schauplatz der Digitalisierung ist die TI der Treffpunkt für alle, die sensible Informationen digital speichern, verwalten oder miteinander austauschen wollen. Damit die TI von allen beteiligten Akteuren akzeptiert wird, bedarf es eines besonderen Schutzes der in der TI verarbeiteten Gesundheitsdaten. Dies wird auch vom Gesetzgeber so gesehen, der dementsprechend gesetzliche Rahmenbedingungen zum Datenschutz und der Informationssicherheit der Telematikinfrastruktur im SGB V festgelegt hat.

2.1 Gesetzlicher Auftrag

Das Fünfte Buch Sozialgesetzbuch – Gesetzliche Krankenversicherung – regelt sowohl die grundsätzlichen Anforderungen an die Telematikinfrastruktur als auch an die gematik.

Nach § 306 Abs. 1 SGB V ist die Telematikinfrastruktur die interoperable und kompatible Informations-, Kommunikations- und Sicherheitsinfrastruktur, die der Vernetzung von Leistungserbringern, Kostenträgern, Versicherten und weiteren Akteuren des Gesundheitswesens sowie der Rehabilitation und der Pflege dient.

Dabei gilt nach § 306 Abs. 3 SGB V für die Verarbeitung der zu den besonderen Kategorien im Sinne von Artikel 9 der DSGVO gehörenden personenbezogenen Daten in der Telematikinfrastruktur ein dem besonderen Schutzbedarf entsprechendes hohes Schutzniveau. Diesem ist durch entsprechende technische und organisatorische Maßnahmen im Sinne des Artikels 32 der DSGVO Rechnung zu tragen.

Demzufolge besteht nach § 311 SGB V eine Aufgabe der gematik darin, für die im Rahmen des Auftrags nach § 306 Absatz 1 und nach Maßgabe der Anforderungen gemäß § 306 Absatz 3 zu schaffende Telematikinfrastruktur die funktionalen und technischen Vorgaben einschließlich eines Sicherheitskonzepts zu erstellen.

Nach § 311 Abs. 4 SGB V hat die gematik bei der Wahrnehmung ihrer Aufgaben die Interessen von Patienten zu wahren und die Einhaltung der Vorschriften zum Schutz personenbezogener Daten sowie zur Barrierefreiheit sicherzustellen.

Daneben regelt das SGB V viele Details zu Anwendungen, Komponenten und Diensten der TI sowie die datenschutzrechtlichen Verantwortlichkeiten in der TI und die Zusammenarbeit der gematik mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) und der oder dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI).

2.2 Weiterentwicklung der TI

Große Veränderungen im Gesundheitswesen, rasante technologische Entwicklung und Fortschritt gesetzlicher und politischer Rahmenbedingungen schaffen Bedarf für eine Weiterentwicklung der TI, wie sie ursprünglich konzipiert wurde. Die TI der Zukunft wird das deutsche Gesundheitswesen durchgängig digital vernetzten, die Versorgungsszenarien werden über die Leistungserbringerumgebung hinausgehen und viele neue Akteure werden eingebunden.

Mit dem Leitgedanken der TI als Arena im Markt der digital vernetzten medizinischen Versorgungsleistungen, in der sich Rechtskonformität und Unterstützung für Nutzer und Anbieter verbinden, richtet die gematik ihre Rolle als Nationale Agentur für Digitale Medizin im Spannungsfeld zwischen Durchsetzung regulatorischer Anforderungen und Innovationsförderung neu aus. Hierbei wird die TI als eine Infrastrukturmaßnahme gesehen, die auf folgende Ziele ausgerichtet ist:

• Bereitstellung digitaler Identitäten für Akteure
• Schaffung von Vertrauen durch engmaschige Sicherheit
• Interoperabilität von Diensten durch etablierte Standards und einheitliche Schnittstellen

Die TI wird eine vereinfachte Integration von Nutzern und ihren Systemen bieten und die intersektorale und internationale Interoperabilität fördern. Sie wird zukünftige Anwendungsszenarien bspw. In der Versorgungsunterstützung und der Forschung unterstützen.

Die Neuausrichtung reduziert die Komplexität im Regelbetrieb und verbessert die betriebliche Steuerung durch die gematik. Dies gewährleistet einen stabilen und sicheren Betrieb und verbessert die Wirtschaftlichkeit.

Bei allen Veränderungen, die eine Weiterentwicklung der TI mit sich bringt, gilt nach wie vor das Prinzip, dass sich alle Maßnahmen am Schutzbedarf der verarbeiteten Daten orientieren. Damit bleibt das Sicherheitsniveau der TI unverändert hoch – auch wenn sich zukünftig die Sicherheitsarchitektur verändert.

2.3 Akteure der TI

Die „Spieler“ in der Arena Telematikinfrastruktur sind die Akteure der TI. Die Regeln der TI gelten für diese Akteure und spiegeln gleichzeitig ihre Bedürfnisse und ihre Eigenschaften wider. In diesem Dokument werden deshalb die einzelnen Akteure unterschieden, wo eine Unterscheidung sinnvoll und notwendig ist.

Abbildung 2: Die Akteure der TI

Die Rollen und Rechte der einzelnen Akteure der TI finden sich in Konzepten und Spezifikationen der Anwendungen, Komponenten und Dienste der TI sowie deren Realisierung in Produkten wieder. Grundlage hierfür ist die Gesetzgebung (insbes. SGB V), die grundsätzlich die Rollen und Rechte für den Zugriff auf die in den Anwendungen der TI verarbeiteten Daten festlegt.

Die Rollen- und Rechtekonzepte des für den Betrieb von Komponenten und Diensten der TI notwendigen Personals (z.B. Administratoren) werden von den jeweiligen Anbietern festgelegt. Dies gilt auch für Hersteller und ihren Softwareentwicklungsprozess.

Die einzelnen Akteure sollen im Folgenden kurz portraitiert werden.

Versicherte und Vertreter

Die Versicherten sind als souveräner Akteur an der TI beteiligt. Sie sind Nutzer der gesetzlichen Anwendungen der TI und Nutzer von Angeboten der gesetzlichen Krankenkassen, privaten Krankenversicherungen und von Leistungserbringern sowie von digitalen Gesundheitsanwendungen (DiGA) und digitalen Pflegeanwendungen (DiPA).

Ein Versicherter ist eine natürliche Person, die in einem Versicherungsverhältnis mit einer gesetzlichen oder privaten Krankenversicherung steht. Versicherte, die sich in einem Versorgungskontext befinden, werden auch als Patienten bezeichnet.

Als Authentisierungsmittel dienen Versicherten die elektronische Gesundheitskarte (eGK), eine digitale Identität oder andere, alternative Authentisierungsmittel, die ein ausreichendes Sicherheitsniveau erreichen.

Vertreter von Versicherten müssen sich ebenso mit einem solchen Authentisierungsmittel mit ausreichendem Sicherheitsniveau in der TI ausweisen können. Welche Befugnisse Vertreter haben, ist von Anwendung zu Anwendung unterschiedlich.

Leistungserbringer

Leistungserbringer sind insbesondere (also nicht abschließend) Ärzte, Zahnärzte, Apotheker, Psychotherapeuten, Angehörige von Pflegeberufen. Sie sind Nutzer der gesetzlichen Anwendungen der TI und Nutzer von Angeboten der Standesvertretungen und Organisationen der Leistungserbringer, Angeboten regionaler Versorgungsnetzwerke sowie Dienstleistern.

Als Authentisierungsmittel dienen Leistungserbringern elektronische Heilberufsausweise (HBA) oder digitale Identitäten.

Ganze Leistungserbringerinstitutionen authentisieren sich mittels der Institutionskarte (SMC-B) oder einer digitalen Identität. Auch berufsmäßige Gehilfen, die über keinen eigenen HBA verfügen, können mittels der SMC-B auf Daten in einer Anwendung der TI zugreifen, wenn sie für diesen Zugriff von einer Person autorisiert wurden, die über einen Heilberufsausweis oder eine digitale Identität verfügt und nachprüfbar elektronisch protokolliert wird, wer auf welche Daten zugegriffen hat und von welcher Person der berufsmäßige Gehilfe für den Zugriff autorisiert wurde.

Kostenträger

Die gesetzlichen Krankenkassen und die privaten Krankenversicherungen finanzieren über die Beiträge ihrer Versicherten die TI. Als Akteure der TI sind sie Nutzer von Anwendungen der TI, z.B. des Versichertenstammdatenmanagements (VSDM), der elektronischen Arbeitsunfähigkeitsbescheinigung (eAU) oder anderer Kommunikationsmittel zwischen Leistungserbringern und Kostenträgern, wie der Kommunikation im Medizinwesen (KIM).

Das Authentisierungsmittel eines Kostenträgers ist seine Organisationskarte, ähnlich wie einer Institutionskarte. Eine Authentisierung einzelner Mitarbeiter eines Kostenträgers ist in der TI nicht vorgesehen.

Die gesetzlichen Krankenkassen sind zudem verpflichtet eine Ombudsstelle einzurichten, an die sich Versicherte mit Anliegen im Zusammenhang mit ihrer elektronischen Patientenakte wenden können. Neben Beratungstätigkeiten können Ombudsstellen Versicherten auch ihre Protokolldaten aus der ePA zur Verfügung stellen und Befugnisse im Auftrag des Versicherten verwalten. Für den hierfür notwendigen technischen Zugriff auf Patientenakten werden Ombudsstellen mit einem gesonderten Authentisierungsmittel ausgestattet.

Hersteller

Komponenten und Dienste werden von Herstellern produziert. Damit eine Komponente bzw. ein Dienst von der gematik zugelassen werden kann, muss der Hersteller die Anforderungen der gematik umsetzen.

Für Softwareprodukte eines Herstellers muss dieser die von der gematik geforderte Qualität (insbesondere Sicherheit) seiner Softwareentwicklungsprozesse nachweisen.

Hersteller müssen ihre Produkte warten und weiterentwickeln, wenn sie die Produkte dauerhaft im Feldeinsatz halten wollen.

Sie besitzen keine Authentisierungsmittel für die TI, da sie keine Nutzer von TI-Anwendungen sind.

Anbieter/Betreiber

Anbieter sind für den Betrieb zugelassener Dienste verantwortlich. Möglicherweise lässt der Anbieter den Betrieb durch einen Betreiber durchführen.

Auch Anbieter/Betreiber besitzen keine Authentisierungsmittel für die TI, da sie keine TI-Anwendungen nutzen. Im Gegenteil: Da sie im Allgemeinen keine berechtigten Nutzer sind – was auch für den durch sie selbst betriebenen Dienst gilt – werden sie im Falle der Verarbeitung von personenbezogenen medizinischen Daten durch technische Maßnahmen vom Zugriff auf diese Daten ausgeschlossen. Eine Ausnahme bilden Anbieter/Betreiber, die von Gesetzes wegen berechtigt sind auf Dienste der TI zuzugreifen.

Weitere Akteure des Gesundheitswesens

Zu den weiteren Akteuren des Gesundheitswesens gehören Anbieter von Anwendungen, die die TI für ihre Zwecke nutzen.  Dies können digitale Gesundheitsanwendungen (DiGA), digitale Anwendungen der Pflege (DiPA) oder weitere Anwendungen gem. § 312 Abs. 9 SGB V sein. Je nach Anwendungsfall erhalten diese Akteure auch Authentisierungsmittel für die TI. Zudem gehören hierzu Hersteller, Anbieter und andere Akteure des Gesundheitswesens ohne Verbindung zur TI, die ggf. mit ihren Produkten oder Dienstleistungen in Konkurrenz zu den Komponenten und Diensten der TI stehen. Diese Gruppe besitzt keine Authentisierungsmittel für die TI.

gematik

Die gematik tritt in mehreren Rollen auf. Auf der einen Seite ist sie für die Formulierung der Spielregeln (Policy der TI) und die Kontrolle der Einhaltung verantwortlich und auf der anderen Seite tritt sie sowohl als Hersteller (z.B. des E-Rezept-Frontend des Versicherten) als auch als Anbieter (z.B. des Verzeichnisdienstes der TI) auf.

Die gematik erteilt Zulassungen für Komponenten und Dienste der Telematikinfrastruktur sowie für Anbieter operativer Betriebsleistungen am Produktivbetrieb der TI.

In der Rolle der betriebskoordinierenden Instanz für die TI übernimmt sie die Steuerungs- und Aufsichtsfunktion gegenüber Dienstleistern (TI-Governance), die Definition der Rahmenbedingungen (z.B. Spezifikation, Test, Zulassung) und die Überwachung der Serviceerbringung (z.B. Service Monitoring, Risikomanagement, Audits).

Selbstverständlich muss die gematik die von ihr formulierten Spielregeln auch selbst einhalten. Dass sie dem nachkommt, ist aus Gründen der Glaubwürdigkeit im Interesse der gematik selbst – aber auch im Interesse des Gesetzgebers, der für solche Fälle externe Sicherheitsgutachten vorsieht (vgl. § 323 Abs. 2 und § 360 Abs. 10 SGB V), die vom BSI geprüft und bestätigt werden müssen.

3 Datenschutz- und Sicherheitsstrategie

Dieses Kapitel beschreibt, welche Datenschutz- und Informationssicherheitsziele mit der TI aus der Sicht verschiedener Akteure verfolgt werden und legt die methodischen Grundlagen, um beurteilen zu können, ob diese Ziele erreicht werden. Dazu wird der Lebenszyklus der Produkte der TI in Phasen eingeteilt, damit die Beurteilung anhand der spezifischen Charakteristika der einzelnen Phasen erfolgen kann.

3.1 Ziele des Datenschutzes und der Informationssicherheit der TI

Die Beschreibung der Ziele des Datenschutzes und der Informationssicherheit der TI erfolgt aus der Sicht der verschiedenen Akteure der TI, in gewisser Weise also aus der jeweiligen Nutzerperspektive in Form von User-Stories. Mit dieser Vorgehensweise wird zugleich das Ziel der mehrseitigen Sicherheit erreicht. Mehrseitige Sicherheit umfasst die Einbeziehung der Schutzinteressen aller Beteiligten sowie das Austragen daraus resultierender Schutzkonflikte.

3.1.1 Ziele der Versicherten/Patienten

Zunächst wird die Perspektive der Versicherten bzw. Patienten eingenommen:

Als Versicherter/Patient möchte ich, dass

• meine personenbezogenen medizinischen Daten, die in Anwendungen der TI verarbeitet werden, Unbefugten nicht zur Kenntnis gelangen,
• ich darüber bestimme, wer meine Daten einsehen darf,
• meine Daten nicht verfälscht werden können,
• meine Daten verfügbar sind, wenn ich sie brauche oder ein von mir Berechtigter sie braucht,
• immer nur die Daten von und über mich verarbeitet werden, die für den jeweiligen Behandlungs-, Versorgungs- bzw. Forschungskontext notwendig sind,
• meine Daten – auch die Metadaten, die ich durch die Nutzung von Anwendungen erzeuge – nicht für eine unerwünschte Profilbildung missbraucht werden,
• ich nachvollziehen kann, wer wann auf meine Daten zugegriffen hat,
• ich meine Daten jederzeit löschen (lassen) kann,
• meine Daten nur verarbeitet werden, wenn ich der Verarbeitung zugestimmt habe oder es eine gesetzliche Grundlage für die Verarbeitung gibt,
• ich alle meine datenschutzrechtlichen Betroffenenrechte jederzeit in einer für mich praktikablen Art und Weise wahrnehmen kann,
• ich mich bei Bedarf umfassend über die Verarbeitungen und Datenschutz- sowie Sicherheitsmaßnahmen in der Telematikinfrastruktur informieren kann, bevor ich meine Daten in der TI bzw. in einer ihrer Anwendungen zur Verfügung stelle,
• ich in zugelassenen Produkten der TI keine Funktionen nutzen muss, die nicht unmittelbar für die Anwendung der TI erforderlich sind (Kopplungsverbot),
• ich mich bei vermuteten Sicherheitsvorfällen und Datenschutzverstößen an eine zentrale Stelle zur Aufklärung wenden kann.

3.1.2 Ziele der Leistungserbringer

Die Sicht der Leistungserbringer wird wie folgt formuliert:

Als Leistungserbringer möchte ich, dass

• die Anwendungen, in denen die personenbezogenen medizinischen Daten meiner Patienten verarbeitet werden, meine Pflicht zur Verschwiegenheit gewährleisten,
• die Daten meiner Patienten verfügbar sind, wenn ich sie benötige,
• ich den Daten meiner Patienten ansehen kann, aus welcher Quelle sie stammen,
• die IT in meiner Leistungserbringerumgebung nicht durch die Nutzung der TI gefährdet wird und
• niemand ein Profil über mein Arbeitsverhalten bilden kann.

3.1.3 Ziele der Kostenträger

Als Kostenträger in der Rolle eines Nutzers von Anwendungen der TI möchte ich, dass

• die Anwendungen der TI, die ich nutze, datenschutzkonform und sicher sind und
• ich die Anwendungen der TI ohne Einbuße in der Sicherheit der eigenen IT nutzen kann.

3.1.4 Ziele der Anbieter

Auch die Perspektive von Anbietern von (Fach-)Diensten ist wichtig:

Als Anbieter eines (Fach-)Dienstes, der personenbezogene medizinische Daten verarbeitet, möchte ich, dass

• zu keiner Zeit der Verdacht besteht, dass ich auf die Daten, die ich verarbeite, zugegriffen haben könnte,
• die TI bzw. die gematik mich darin unterstützt meine Pflichten als Teil einer kritischen Infrastruktur wahrzunehmen,
• ich mich darauf verlassen kann, dass ein von der gematik zugelassenes Produkt datenschutzkonform und sicher ist und
• ich im Falle einer Störung, eines Sicherheitsvorfalls oder Datenschutzverstoßes koordinierende Unterstützung durch die gematik erhalte.

3.1.5 Ziele der Hersteller

Hersteller sind weitere Akteure der TI:

Als Hersteller von Komponenten oder Diensten der TI, die personenbezogene medizinische Daten verarbeiten, möchte ich, dass

• meine Produkte eine Zulassung von der gematik erhalten und
• meine Produkte, die ich nach den Vorgaben der gematik herstelle, datenschutzkonform und sicher sind.

Als Hersteller von Komponenten oder Diensten, die mit der TI interagieren und die personenbezogene medizinische Daten verarbeiten, möchte ich, dass

• meine Produkte eine Konformitätsbestätigung von der gematik erhalten – falls diese gefordert ist.

3.1.6 Ziele der weiteren Akteure des Gesundheitswesens

Als weiterer Akteur des Gesundheitswesens, der die TI nutzt, möchte ich, dass

• meine Anwendung Komponenten und (Fach-)Dienste der TI nutzen kann,
• ich mich auf die Datenschutzkonformität und Sicherheit der (Fach-)Dienste der TI verlassen kann und
• die interne Verfügbarkeit der IT-Services, für die ich verantwortlich bin, durch die Nutzung der TI nicht negativ beeinflusst wird.

3.1.7 Ziele der gematik

Nicht zuletzt ist die gematik ein Akteur in der TI und verfolgt in ihren verschiedenen Rollen diese Ziele:

Die gematik in der Rolle des Entwicklers von Konzepten und Spezifikationen möchte, dass

• bereits im Design von Komponenten und Diensten Datenschutz und Sicherheit verankert sind,
• kein unberechtigter Akteur über alle Mittel verfügt, um systematisch auf schützenswerte medizinische Daten der Versicherten zuzugreifen,
• Hersteller die Vorgaben so umsetzen können, dass daraus datenschutzkonforme und sichere Produkte resultieren,
• Anbieter durch die Erfüllung der Vorgaben einen sicheren Betrieb von Diensten gewährleisten können,
• Hersteller und Anbieter Datenschutz- und Sicherheitsmaßnahmen nach Stand der Technik umsetzen können,
• unabhängige Dritte bereits anhand des Designs von Komponenten und Diensten deren Datenschutzkonformität und Sicherheit überprüfen können und
• die Umsetzung der Datenschutz- und Sicherheitsmaßnahmen durch unabhängige Dritte überprüfbar ist.

Die gematik in der Rolle eines Herstellers möchte, dass

• meine Produkte hohen Datenschutz- und Sicherheitsansprüchen genügen und
• unabhängige Dritte die Datenschutzkonformität und Sicherheit meiner Produkte bestätigen.

Die gematik in der Rolle einer Zulassungsstelle möchte, dass

• die Zulassungs- und Bestätigungsverfahren dazu führen, dass nur datenschutzkonforme und sichere Komponenten und Dienste in den Produktivbetrieb kommen.

Die gematik in der Rolle der betriebskoordinierenden Instanz möchte, dass

• ein datenschutzkonformer und sicherer Betrieb von Komponenten und Diensten der TI gewährleistet ist,
• Anbieter und Hersteller ihren betrieblichen Mitwirkungspflichten jederzeit nachkommen und eine intrinsische Motivation im Kontext Datenschutz und Informationssicherheit vorweisen
• sich alle an der TI beteiligten Akteure an die TI-Policy halten, die TI als kritische Infrastruktur hoch verfügbar ist,
• ein Mandat als auch die technischen Möglichkeiten bestehen, um die Einhaltung der Informationssicherheit und des Datenschutzes im Rahmen der Governance Funktion überwachen zu können und
• wirksame Mechanismen bestehen, um im Falle von Datenschutzverstößen oder Sicherheitsvorfällen den Verursacher zu identifizieren, und wirksam reagieren zu können (z.B. durch temporäre Sperrung von Zugängen)

3.1.8 Gewährleistungs- und Schutzziele

Aus den Zielen der Akteure können die wesentlichen Gewährleistungs- und Schutzziele für die Anwendungen und Systeme der TI mit ihren Verarbeitungsvorgängen und Informationsobjekten TI abgeleitet werden, die in dieser Form auch in allgemeinen Datenschutz- (vgl. [SDM]) und Informationssicherheitsmethoden (vgl. [BSI-200-2]) Berücksichtigung finden:

Vertraulichkeit:

• Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Informationsobjekte dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein.
• Die Vertraulichkeit der in den Anwendungen der TI verarbeiteten personenbezogenen medizinischen Daten zu gewährleisten, ist ein wesentliches Ziel bei deren Entwicklung und Betrieb.

Integrität:

• Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Informationsobjekten. Der Verlust der Integrität von Informationsobjekten bedeutet insbesondere, dass das Informationsobjekt selbst, oder Metadaten wie z.B. Angaben zum Autor oder Zeitangaben zur Erstellung des Informationsobjekts von Personen unberechtigt oder aus Versehen oder durch Fehler in der verarbeitenden Software verändert wurden.
• Die Integrität personenbezogener medizinischer Daten ist von entscheidender Wichtigkeit, wenn diese in Diagnosen und für Therapien verwendet werden. Eine unbemerkte Manipulation kann zu Gefahr für Leib und Leben führen.
• Auch für Forschungszwecke sind integre Daten wichtig, da man hier sonst zu falschen Ergebnissen kommen kann.

Verfügbarkeit:

• Die Verfügbarkeit von Anwendungsprozessen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können.
• Je nach Versorgungsprozess bestehen unterschiedliche Anforderungen an die Anwendungsprozesse, die diesen unterstützen.
• Das Spannungsfeld zwischen dem Ziel der Vertraulichkeit und dem der Verfügbarkeit ist im Einzelfall abzuwägen.

Datenminimierung:

• Die Verarbeitung personenbezogener Daten muss auf das dem Zweck angemessene, erhebliche und notwendige Maß beschränkt werden.
• Für alle Verarbeitungstätigkeiten in der TI müssen die Zwecke klar festgelegt und beschrieben werden. Gemäß [SDM] muss „die Zweckbeschreibung den Zweck so eng fassen, dass die Grenzen der Verarbeitungstätigkeit mit den für den Prozess der Verarbeitung notwendigen und erforderlichen Daten im dafür angemessenen Umfang technisch und datenschutzrechtlich bestimmbar sind.“
• Es ist in der TI zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten durch Trennungsmaßnahmen getrennt verarbeitet werden (Zwecktrennung).
• Insbesondere unter Beschlagnahmeschutz fallende Daten sind getrennt von Daten ohne Beschlagnahmeschutz zu speichern. Der Beschlagnahmeschutz wurde im §97 Abs. 2 StPO auf die im Besitz des Versicherten befindliche eGK erweitert, damit die Versicherten bei Nutzung der TI darauf vertrauen können, dass ihre zugreifbaren medizinischen Daten in der TI tatsächlich nur für den beabsichtigten Zweck der medizinischen Versorgung verwendet werden und das Vertrauensverhältnis zwischen Arzt und Patient geschützt bleibt.
• Protokolldaten müssen genau die Informationen enthalten, die zur Erfüllung des Zwecks der Protokollierung (z.B. Datenschutzkontrolle durch Versicherten) erforderlich sind, aber keine darüberhinausgehenden Informationen.
• Die Datenverarbeitung und der Zugriff auf Daten in der TI müssen anonymisiert oder pseudonymisiert werden, soweit dies nach dem Verwendungszweck möglich ist und keinen im Verhältnis zu dem angestrebten Schutzzweck unverhältnismäßigen Aufwand erfordert.
• Bei der Pseudo- oder Anonymisierung sind Verfahren nach Stand der Technik zu verwenden, die eine Depseudo- oder Deanonymisierung wirksam verhindern.
• Falls eine Depseudonymisierung in der TI erforderlich ist, darf dies soweit möglich nur durch die das Pseudonym betreffende Person erfolgen.
• Um den Schaden bei einer ungewollten Depseudonymisierung zu verringern, müssen die Pseudonyme in der TI in regelmäßigen Abständen oder anlassbezogen neu erstellt werden können.
• Pseudonyme sollen nicht für mehrere Zwecke verwendet werden.

Nichtverkettung:

• Personenbezogene Daten dürfen nicht unerlaubt zusammengeführt, also verkettet, werden, insbesondere dann, wenn die zusammenzuführenden Daten für unterschiedliche Zwecke erhoben wurden.
• Die Identifikationsdaten der TI (insbesondere die KVNR) sind zweckgebunden für das Gesundheitswesen und dürfen nicht zugleich als einheitliches Personenkennzeichen in Anwendungen außerhalb des Gesundheitswesens genutzt werden.
• Die TI muss vorzugsweise durch technische Maßnahmen eine unerlaubte Profilbildung in der TI erschweren bzw. verhindern.
• Die in der TI erzeugten Protokolldaten dürfen nur für Zwecke der Datenschutzkontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemäßen Betriebes in einem datenschutzgerechten Verfahren verwendet werden. Die in der TI erzeugten Protokolldaten müssen durch geeignete Vorkehrungen gegen zweckfremde Verwendung oder sonstigen Missbrauch geschützt werden.
• In der TI darf kein Werbe-Tracking erfolgen.

Transparenz:

• Sowohl Betroffene als auch die Betreiber von Systemen sowie zuständige Kontrollinstanzen müssen erkennen können, welche Daten wann und für welchen Zweck bei einer Verarbeitungstätigkeit erhoben und verarbeitet werden, welche Systeme und Prozesse dafür genutzt werden, wohin die Daten zu welchem Zweck fließen und wer die rechtliche Verantwortung für die Daten und Systeme in den verschiedenen Phasen einer Datenverarbeitung trägt.
• In der TI müssen Informations- und Auskunftspflichten vorgesehen werden, um für die Betroffenen und die zuständigen Kontrollstellen eine hohe Transparenz über die in der TI verarbeiteten personenbezogenen Daten zu erreichen. Dies ist zwingende Voraussetzung dafür, dass der Betroffene sein Recht auf informationelle Selbstbestimmung wahrnehmen kann.
• Betroffene müssen vor der Nutzung einer Anwendung der TI vollständig und in für den Betroffenen klarer und verständlicher Form informiert werden. Die Informationen über die Anwendung müssen insbesondere die Art und Zweckbestimmung der verarbeiteten personenbezogenen Daten, die Personen, an welche die Daten möglicherweise weitergegeben werden und die Rechte des Betroffenen, enthalten.
• Jede Erhebung, Verarbeitung und Nutzung personenbezogener Daten in der TI muss für den Betroffenen im Nachhinein nachvollziehbar sein, insbesondere von wem und zu welchem Zeitpunkt welche seiner personenbezogenen Daten verarbeitet wurden.

Intervenierbarkeit:

• Betroffene Personen müssen ihre Rechte auf Benachrichtigung, Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch und Erwirkung des Eingriffs in automatisierte Einzelentscheidungen wahrnehmen können.
• Betroffene sollen – im Rahmen der gesetzlichen Regelungen – selbst über die Verarbeitung ihrer personenbezogenen Daten in der TI bestimmen können. Sie müssen die Datenhoheit über ihre personenbezogenen Daten in der TI haben.
• Durch die Prozesse der TI darf die für die Versicherten geltende freie Arzt- und Krankenhauswahl nicht eingeschränkt werden. Die Versicherten müssen unter den in der TI beteiligten Leistungserbringern und Leistungserbringerinstitutionen frei wählen können. Leistungserbringer oder Leistungserbringerinstitutionen dürfen in der TI nicht diskriminiert werden.
• Die Einwilligung in die Nutzung von freiwilligen Anwendungen oder freiwilligen Funktionen in Anwendungen(„Opt-in“-Funktionen) darf nicht abhängig von der Nutzung anderer Funktionen sein, sofern diese nicht fachlich zwingend erforderlich sind (Kopplungsverbot).
• Es muss ein jederzeitiger Widerruf der Einwilligung möglich sein mit der Konsequenz, dass die personenbezogenen Daten dann nicht mehr weiterverarbeitet und unter Einhaltung gesetzlicher Fristen gelöscht werden.
• Den datenschutzrechtlich Betroffenen müssen in der TI praktikable Maßnahmen in angemessenem Umfang und zum unentgeltlichen Gebrauch zur Verfügung stellen werden, mit denen sie ihre datenschutzrechtlichen Betroffenenrechte mit zumutbarem Aufwand wahrnehmen können.
• Die Gestaltung der Produkte und Anwendungen der TI muss die Praktikabilität bzgl. der verschiedenen Betroffenengruppen im Gesundheitswesen und die dabei auftretende Heterogenität bzgl. ihrer Handlungs- und Entscheidungsfähigkeit berücksichtigen. Maßnahmen zur Wahrnehmung der Patientenrechte dürfen nicht dazu führen, dass bestimmte Personengruppen benachteiligt werden und datenschutzrechtliche Einbußen erfolgen.
• Betroffenen soll in der TI auch durch technische Geräte ermöglicht werden, selbstständig ihre Betroffenenrechte wahrzunehmen.
• Die in den technischen Benutzerschnittstellen dargestellten Informationen müssen für die Betroffenen übersichtlich und in einer verständlichen Form aufbereitet werden. Insbesondere müssen Versicherte unbeobachtet und in einer für sie praktikablen Weise die zum Zwecke der Datenschutzkontrolle erzeugten Protokolldaten einsehen können.

In einzelnen Fällen kann es erforderlich sein, weitere Schutzziele in eine Sicherheitsbetrachtung für eine Anwendung bzw. ein System der TI einzubeziehen. Mögliche weitere Schutzziele sind u.a. Authentizität, Nichtabstreitbarkeit und Verbindlichkeit.

3.2 Phasenmodell zur Sicherstellung von Datenschutz und Informationssicherheit

Der Lebenszyklus der Produkte der TI lässt sich in vier Phasen gliedern – Entwicklung, Herstellung, Zulassung, Betrieb – in denen jeweils spezifische Maßnahmen für den Datenschutz und die Informationssicherheit getroffen werden.

Abbildung 3: Phasen des Lebenszyklus der Produkte der TI

Die folgende Abbildung zeigt die Phasen mit ihren jeweiligen datenschutz- und sicherheitsrelevanten Artefakten im Überblick:

Abbildung 4: Überblick der Artefakte in den Phasen des Lebenszyklus der Produkte der TI

Im Hinblick auf die zeitliche Abfolge von Datenschutz- und Sicherheitsmaßnahmen zur Prävention, Detektion und Reaktion ist der Zusammenhang zu den o.g. Phasen des Lebenszyklus wie folgt abbildbar:

Abbildung 5: Datenschutz- und Sicherheitsmaßnahmen in den Phasen des Lebenszyklus

In den folgenden Abschnitten werden die Phasen und Aktivitäten zur Sicherstellung von Datenschutz und Informationssicherheit in der TI näher erläutert.

3.2.1 Entwicklung

In der Entwicklungsphase werden die funktionalen und nichtfunktionalen Eigenschaften von Anwendungen und Systemen der TI beschrieben. Dies kann in Form von Konzepten und Spezifikationen oder auch durch Schnittstellenbeschreibungen erfolgen.

In dieser Phase werden die grundlegenden Datenschutzfunktionen (Privacy by Design) und Sicherheitsmechanismen (Security by Design) für eine Anwendung bzw. ein System der TI festgelegt. Bereits hier finden auch wesentliche Design-Entscheidungen statt, z.B., dass technische Maßnahmen Vorrang vor organisatorischen haben.

Ebenso werden die Pflichten von Akteuren definiert, z.B. die Anforderungen an einen Hersteller sichere Softwareentwicklungsprozesse im Herstellungsprozess zu etablieren oder die Mitwirkungspflichten eines Anbieters an der betrieblichen Überwachung der vom ihm betriebenen Dienste.

Bereits in der Entwicklung werden die Grundlagen für eine erfolgversprechende Detektion von Anomalien im Betrieb durch die Festlegung von Anwendungsfällen und zu liefernden Informationen über deren Ausführung gelegt.

3.2.2 Herstellung

In der Herstellungsphase werden Komponenten und Dienste nach den Vorgaben aus der Entwicklungsphase hergestellt. Die Herstellungsprozesse müssen ebenfalls bestimmten Kriterien entsprechen, die in der Entwicklungsphase festgelegt wurden.

Hersteller bringen Produkte auf den Markt, die von Endnutzern oder Anbietern bzw. Betreibern betrieben werden. Es muss gegenüber der gematik nachgewiesen werden, dass die Herstellung den Anforderungen genügt. Für die Herstellung eines Produktes müssen Hersteller folgende Voraussetzungen und Fähigkeiten nachweisen:

• Die Entwicklungs- und Testumgebungen der Hersteller werden sicher betrieben. Diese beiden Umgebungen sind untereinander durch Segmentierung und sicherheitsrelevante Kontrollmechanismen an den Segmentgrenzen abgesichert. Es werden nur Werkzeuge eingesetzt, die für einen sicheren Betrieb der Entwicklungs- und Testumgebungen geeignet sind und die wiederholte Herstellung eines sicheren Produktes ermöglichen.
• Es wird nachweisbar geschultes Personal für die sichere Herstellung eingesetzt. Art und Umfang des für die Herstellung eingesetzten Personals müssen der technischen Umgebung und der eingesetzten Technologie angemessen sein. Für das eingesetzte Personal muss ein Rollenkonzept etabliert sein, das die Rollendefinitionen und Rollenverteilung enthält.
• Es sind sichere Softwareentwicklungsprozesse für die Herstellung etabliert. Dies bedeutet mindestens, dass Sicherheitsmaßnahmen etabliert sind, die schädliche Änderungen am Produkt oder in der Zielumgebung effektiv verhindern. Die Wartbarkeit und Evolvierbarkeit des Produktes muss zu jeder Zeit sichergestellt sein, um neue Schwachstellen durch Softwareanpassungen behandeln zu können. Die herstellerseitige Konfiguration des Produktes muss sicher und datenschutzkonform sein (engl. „security by default“ und „privacy by default“).
• Es müssen skalierbare Testfähigkeiten etabliert sein, sodass das Produktverhalten und der Produktzustand mindestens bzgl. Regressionen, Kernfunktionen und Sicherheit zuverlässig wiederholbar geprüft werden können. Die Entwicklungs- und Testdaten müssen datenschutzkonform sein und dürfen keine schützenswerten personenbezogenen Daten enthalten.

Der Nachweis der Erfüllung erfolgt über einen unabhängigen Sicherheitsgutachter in einem Gutachten, das der Hersteller im Rahmen der Zulassung seines Produkts durch die gematik bestätigen lassen muss.

3.2.3 Zulassung

Die gematik ist die offizielle Zulassungsstelle für sämtliche Komponenten und Dienste der TI sowie für Hersteller, Anbieter operativer Betriebsleistungen und weiterer Anwendungen. Sofern diese die Anforderungen an Interoperabilität, Sicherheit und Funktionsfähigkeit nachweisen können, erteilt die gematik Zulassungen und Bestätigungen für die TI.

Die Zulassungs- bzw. Bestätigungsprozesse der gematik sollen sicherstellen, dass die Ergebnisse der Herstellungsphase – also Komponenten und Dienste – die Anforderungen aus der Entwicklungsphase erfüllen. Nur Komponenten und Dienste, für die der Hersteller ausreichende Nachweise über die Erfüllung der Anforderungen erbringt, erhalten eine Produktzulassung und dürfen in den Wirkbetrieb überführt werden. Die Nachweise hierfür sind verschiedener Art und unterscheiden sich in Aufwand und Aussagekraft des Nachweises.

Grundlage für die Erstellung und Prüfung von Sicherheit- bzw. Produktgutachten ist die Richtlinie zur Prüfung der Sicherheitseignung der gematik ([gemRL_PruefSichEig_DS]).

Ggf. notwendige Zertifizierungen liegen in der Hoheit des BSI. Die fachlichen Anforderungen für Zertifizierungen werden in Abstimmung zwischen gematik und BSI festgelegt.

Zugelassen werden nicht nur Komponenten und Dienste, sondern auch Hersteller und Anbieter.

Eine Übersicht über die Anforderungen, deren Erfüllung im Rahmen einer Zulassung nachzuweisen sind, finden sich im jeweiligen Anbietertyp-, Produkttyp- bzw. Anwendungssteckbrief. Die Details zu den Zulassungsverfahren stehen in den entsprechenden Verfahrensbeschreibungen.

Herstellerzulassung

Eine Herstellerzulassung ist für Hersteller von Frontends des Versicherten (FdV) vorgesehen, die auf FdVs auf Fachdienste zugreifen, die durch die gematik nach SGB V zur Verfügung gestellt werden. Dies ist z.B. bei den FdVs der Krankenkassen für die elektronische Patientenakte der Fall, die den Zugriff auf E-Rezepte integriert haben.

Produktzulassung

Zugelassene Hersteller stellen Komponenten oder Dienste her, die durch die gematik ebenfalls zugelassen werden müssen, damit diese in den Produktivbetrieb der TI dürfen.

Die Datenschutzkonformität und Sicherheit von Komponenten bzw. Diensten, die Daten mit sehr hohem Schutzbedarf verarbeiten, müssen mindestens durch ein Produktgutachten geprüft werden. Bei bestimmten Komponenten sind – je nach Art und Kritikalität der Komponente – auch Zertifizierungen durch das BSI erforderlich.

Ein Aspekt der Produktzulassung ist der Nachweis, dass der Hersteller über einen sicheren Softwareentwicklungsprozess verfügt. Diesen Nachweis erbringt der Hersteller über ein Sicherheitsgutachten, in dem ein unabhängiger Gutachter die Einhaltung der diesbezüglichen Anforderungen der gematik prüft. Die geprüfte Qualität des Softwareentwicklungsprozesses soll sicherstellen, dass das vom Hersteller erstellte Produkt möglichst auch zwischen zwei Produktprüfungen keine Schwachstellen aufweist und der Hersteller bei der Erstellung von Impact Assessment Reports (IAR) die notwendige Sorgfalt walten lässt.

Anbieterzulassung

Anbieter zugelassener Produkte müssen für ihre Betriebsleistung ebenfalls eine Zulassung erlangen.

Die Datenschutzkonformität und Sicherheit der Betriebsleistung wird über ein Sicherheitsgutachten über den sicheren Betrieb nachgewiesen. Dies gilt für den Betrieb von Komponenten bzw. Diensten die Daten mit sehr hohem oder hohem Schutzbedarf verarbeiten.

Daneben findet im Rahmen der Anbieterzulassung eine Integration des Anbieters in die betrieblichen Sicherheitsprozesse und -tools der gematik statt. Die Tiefe der Integration hängt von der Kritikalität des Produkts ab, die sich aus der Bewertung des Schutzbedarfs der verarbeitenden Daten hinsichtlich Vertraulichkeit und Integrität sowie aus der erforderlichen Verfügbarkeit des Produkts im Kontext von Versorgungsprozessen ergibt.

3.2.4 Betrieb

In der Betriebsphase werden alle betrieblichen Sicherheitsaspekte zusammengefasst, die im laufenden operativen Betrieb für die Aufrechterhaltung des erforderlichen Sicherheitsniveaus notwendig sind. Eine wesentliche Aufgabe in der Betriebsphase ist es, zu verifizieren, dass alle Anbieter ihren bestehenden Verpflichtungen im Kontext der Informationssicherheit kontinuierlich im laufenden Betrieb nachkommen. Weiterhin ist es Aufgabe der betrieblichen Sicherheit, die Anbieter bei der Aufrechterhaltung der Sicherheit zu unterstützen und auch eigene Maßnahmen zur Überwachung der Sicherheit für Dienste und Anwendungen der TI zu etablieren.

Diese Aufgaben werden auf Seiten der gematik durch ihre Prüfungs- und Auditaktivitäten sowie die Aktivitäten im Cyber Defence Center wahrgenommen. Der Gesetzgeber hat dies mit Melde- und Berichtspflichten flankiert, denen die beteiligten Akteure im Rahmen der Anbietersteuerung der gematik nachkommen müssen.

Die Erkennung von Anomalien in der Ausführung von Anwendungsfällen und eine Reaktion auf Verdachtsfälle gewinnt – auch und gerade im Hinblick auf die Einführung einer Zero Trust Architektur - an Bedeutung in den betrieblichen Sicherheitsprozessen und -tools.

3.3 Methodische Grundlagen

In den folgenden Abschnitten werden grundlegende Festlegungen getroffen, die für eine Bewertung des Datenschutzes und der Informationssicherheit der TI allgemein, aber auch für einzelne Anwendungen und Systeme der TI gelten.

3.3.1 Privacy and Security by Design

Die Entwicklung von Komponenten und Diensten der TI werden von Anfang an aus Sicht des Datenschutzes und der Sicherheit methodisch begleitet, um durch eine angemessene Auswahl technischer und organisatorischer Maßnahmen die Rechte der Betroffenen zu wahren und die Sicherheit der Verarbeitung zu gewährleisten. Hierbei unterstützten das Standard-Datenschutzmodell [SDM] und die Grundschutz-Methodik des BSI [BSI-200-2], insbesondere die darin definierten Gewährleistungs- bzw. Schutzziele des Datenschutzes und der Sicherheit (vgl. Abschnitt 3.1.8). Aspekte der methodischen Begleitung sind insbesondere die Bestimmung des Schutzbedarfs der Daten sowie der Risiken für die Rechte und Freiheiten der Betroffenen. Bereits in der Entwicklungsphase werden das BSI und der BfDI miteinbezogen (vgl. Abschnitt 3.5).

3.3.2 Mehrschichtige Sicherheit

Eine TI-Anwendung durchläuft mit Entwicklung, Herstellung, Zulassung und Betrieb verschiedene Phasen. Jede Phase ist geprägt von Medienbrüchen und der Zusammenarbeit von verschiedensten Personen. Dabei können sich Fehler einschleichen. Insbesondere ist die sicherheitstechnisch korrekte Implementierung oft eine große Herausforderung. Deshalb ist es Ziel, je nach Möglichkeit und unter Beachtung des Kosten-/Nutzenverhältnis verschiedene unabhängige Sicherheitsschichten zu erzeugen – Schwachstellen in einer Schicht werden so durch die folgende, unabhängige Schicht neutralisiert. Auf diese Weise kann ein durchgehender risikoarmer Betrieb gewährleistet werden.

3.3.3 Sicherheitsmechanismen nach Stand der Technik

In den Anwendungen, Komponenten und Diensten der TI sollen Sicherheitsmechanismen nach Stand der Technik eingesetzt werden. Dafür werden verschiedene nationale und internationale Normen und Standards verwendet.

Die Technische Richtlinie 03116-1 ist für die kryptographischen Verfahren der TI normativ. Die Empfehlungen der Technischen Richtlinie 02102-01 bis -04 werden in der TI umgesetzt. Insbesondere im Bereich der qualifizierten elektronischen Signaturen gelten die Vorgaben aus dem SOGIS-Katalog [SOGIS].

Der „Stand der Technik“ aus dem Bundesverband IT-Sicherheit e. V. [TeleTrusT] dient als Leitlinie für die Interpretation dieses Terminus.

Die Umsetzung der Vorgaben wird durch den Zulassungsprozess überprüft. Im laufenden Betrieb wird die Einhaltung der Vorgaben überwacht und auf die Änderungen der Empfehlungen reagiert. In einigen Bereichen dient dabei die ISO-27001 als Grundlage. Durch die Prüfungs- und Auditmaßnahmen wird die Einhaltung der Vorgaben regelmäßig überprüft.

3.3.4 Datenschutzfolgenabschätzungen in der TI

In der TI und deren Anwendungen sowie den dazu benötigten Komponenten und Diensten werden in der Regel personenbezogene medizinische Daten verarbeitet. Dadurch besteht grundsätzlich ein hohes Risiko für die Rechte und Freiheiten der Betroffenen, so dass der Verantwortliche eine Datenschutz-Folgenabschätzung gemäß Artikel 35 DSGVO durchzuführen hat.

Für die TI gibt es keinen singulären datenschutzrechtlich Verantwortlichen. Die Verantwortlichkeiten sind verteilt, wobei der § 307 SGB V die datenschutzrechtlich Verantwortlichen für die TI festlegt. Von diesen ist entsprechend ihrem Verantwortungsbereich eine Datenschutz-Folgenabschätzung durchzuführen, falls hierfür die Voraussetzungen erfüllt sind.

Die gematik ist grundsätzlich kein Verantwortlicher. Daher werden i.d.R. durch die gematik auch keine Datenschutz-Folgenabschätzungen erstellt. Ausnahmen sind beispielsweise der Verzeichnisdienst der TI nach § 313 SGB V und das E-Rezept Frontend des Versicherten. In der methodischen Begleitung in der Entwicklungsphase der Komponenten und Dienste der TI werden von der gematik jedoch alle in Artikel 35 Absatz 7 DSGVO geforderten Schritte anhand der Methodik zur Datenschutzkonzeption in der Telematikinfrastruktur [gemMeth_DSKonz] durchgeführt und in produkttypspezifischen Datenschutz- und Sicherheitskonzepten dokumentiert.   

3.3.5 Methodik der Datenschutzkonzeption

Die Methodik der Datenschutzkonzeption ([gemMeth_DSKonz]) gewährleistet eine einheitliche methodische Vorgehensweise zur Betrachtung und vollständigen Bewertung des Datenschutzes in der TI. Die Methodik leitet aus den Grundsätzen für die Verarbeitung personenbezogener Daten nach Art. 5 DSGVO Anforderungen an Aspekte ab, die in Fachanwendungen der TI bzw. Produkten der TI (Komponenten oder Dienste) in der Entwicklungsphase verbindlich zu berücksichtigen sind.

Durch die verpflichtende Anwendung der Methodik wird der Datenschutz schon zu Beginn des Entwicklungsprozesses in der TI berücksichtigt und trägt so zur Umsetzung der Anforderung des Privacy (Data Protection) by Design und Privacy (Data Protection) by Default bei.

Durch die Anwendung der Methodik werden Entscheidungen transparent dokumentiert.

Die Methodik zur Datenschutzkonzeption strukturiert die technischen und organisatorischen Maßnahmen zur Umsetzung der Grundsätze des Datenschutzes anhand der im Standard-Datenschutzmodell [SDM] beschriebenen Gewährleistungsziele Datenminimierung, Nichtverkettung, Transparenz, Intervenierbarkeit, Vertraulichkeit, Integrität und Verfügbarkeit. Im Standard-Datenschutzmodell [SDM] und den dazu veröffentlichten Referenzkatalogen bzw. Bausteinen sind Maßnahmen zu finden, die zur Umsetzung der Gewährleistungsziele beitragen können.

3.3.6 Methodik der Sicherheitskonzeption

Die Methodik der Sicherheitskonzeption verwendet im Lebenszyklus der Produkte Methoden der Informationssicherheit, um für eine Anwendung bzw. ein Produkt der TI ein angemessenes Sicherheitsniveau auf Spezifikationsebene, im Produkt selbst sowie für dessen Betrieb zu erreichen.

Die Beschreibung der Methoden

• Asset-Erfassung,
• Schutzbedarfsfeststellung,
• Business Impact Analyse,
• Bedrohungs- und Schwachstellenanalyse,
• Gefährdungs-/ Sicherheitsanalyse und
• Risikoanalyse

findet sich in [gemMeth_SiKonz].

3.4 Dokumentation und Veröffentlichungen

Wie in Abschnitt 2.3 dargestellt, ist die gematik in verschiedenen Rollen an der TI beteiligt. Aus diesem Grund sind weite Teile der Aufbau- und Ablauforganisation der gematik – vollständig oder teilweise – mit der TI beschäftigt. Dies spiegelt sich auch in den datenschutz- und sicherheitsrelevanten Regelungen bzw. Dokumenten der gematik wider.

Die folgende Abbildung listet einerseits diese Dokumente in ihrer Dokumentenhierarchie auf (Diese Auflistung ist nicht abschließend.) und ordnet sie andererseits ihren Anwendungsbereichen zu.

Die Hersteller und Anbieter auf der anderen Seite besitzen ihre eigene Dokumentation. In den Anforderungen der gematik sind Datenschutz- und Sicherheitskonzepte sowie Notfallkonzepte gefordert.

Abbildung 6: Datenschutz- und sicherheitsrelevante Dokumente der gematik

Die gematik veröffentlicht zur Schaffung von Transparenz alle Konzepte und Spezifikationen im Fachportal der gematik.

Zudem werden die technischen Schnittstellenbeschreibungen für die Nutzung durch die Primärsysteme der Leistungserbringer sowie durch die Frontends des Versicherten auf GitHub – einem netzbasierten Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte – veröffentlicht.

Sofern eine Anwendung FHIR-Profile verwendet, werden diese in Implementation Guides veröffentlicht.

Ebenso veröffentlicht wird der Quellcode von datenschutz- und sicherheitsrelevanten Komponenten und Diensten, die durch die gematik bzw. in ihrem Auftrag hergestellt werden.

Diese Transparenzmaßnahmen ermöglichen es jedem Interessierten, die getroffenen Maßnahmen zum Datenschutz und zur Informationssicherheit zu prüfen und entdeckte Mängel an die gematik zu melden. Die gematik prüft wiederum solche Meldungen auf Relevanz und ergreift ggf. Maßnahmen – in der Regel durch Änderungen der Spezifikation und infolgedessen durch Anpassungen an den Produkten im Feld. Auch diese Spezifikationsanpassungen werden dann veröffentlicht.

Darüber hinaus ist die gematik verpflichtet, auf ihrer Internetpräsenz und in analogem Format Informationen für die Versicherten in präziser, transparenter, verständlicher, leicht zugänglicher und barrierefreier Form u.a. über die Maßnahmen zur Datensicherheit zur Verfügung zu stellen (siehe z.B. [gemInfo_DS_IS_Whitepaper]).

Die produkttypspezifischen Datenschutz- und Sicherheitskonzepte werden nicht veröffentlicht. Sie dienen der gematik-internen Produktentwicklung und der Information der Aufsichtsbehörden.

3.5 Einbeziehung BSI und BfDI

Der Gesetzgeber hat festgelegt, dass die gematik die für die TI getroffenen Festlegungen und Maßnahmen im Benehmen mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) treffen muss – sofern Fragen der Datensicherheit berührt sind. Festlegungen und Maßnahmen, die Fragen des Datenschutzes berühren, sind im Benehmen mit der oder dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) zu treffen. Für einzelne Komponenten legt das BSI die Maßnahmen direkt in Form vom Protection Profiles (PP), Technischen Richtlinien (TR) und Prüfvorschriften fest.

Daneben hat der Gesetzgeber mittels weiterer Festlegungen zu speziellen Themen die Zusammenarbeit zwischen BSI, BfDI und gematik im SGB V verankert. Dies betrifft z.B. sichere Verfahren zur Übermittlung medizinischer Daten über die Telematikinfrastruktur (vgl. § 311 Abs. 6 SGB V), Festlegungen zum Aufbau und Betrieb der nationalen eHealth-Kontaktstelle nach § 219d Absatz 6 Satz 1 (vgl. § 312 Abs. 1 Nr. 14 SGB V) sowie die Nutzung der Telematikinfrastruktur für weitere Anwendungen und für Zwecke der Gesundheitsforschung (vgl. § 312 Abs. 9 SGB V).

Sowohl das BSI als auch die oder der BfDI sind im Digitalbeirat der gematik vertreten. Der Digitalbeirat berät die gematik laufend zu Belangen des Datenschutzes und der Datensicherheit sowie zur Nutzerfreundlichkeit der Telematikinfrastruktur und ihrer Anwendungen. Er ist vor der Beschlussfassung der Gesellschafterversammlung der gematik insbesondere auch zu Fragen der medizinischen und ethischen Perspektiven zu hören.

Im Regelfall erbringen von der gematik zugelassene Anbieter Betriebsleistungen in der TI. Sollte die gematik einzelne Komponenten und Dienste der zentralen Infrastruktur selbst betreiben, so ist ein mit dem BSI abgestimmtes externes Sicherheitsgutachten zu erstellen, das durch das BSI bestätigt werden muss (vgl. § 323 Abs. 2 SGB V).

In der Betriebsphase bestehen durch die gesetzlichen Vorgaben des SGB V und des BSI-Gesetzes ([BSIG]] zwischen Anbietern und gematik auf der einen Seite und der gematik und dem BSI auf der anderen Seite Verpflichtungen zum Melden von Störungen bzw. Ansprüche zur Beseitigung von Mängeln.

4 Sicherheitsarchitektur

Die Sicherheitsarchitektur der TI ist ein Teil ihrer Gesamtarchitektur. Deshalb wird in diesem Kapitel zunächst die Architektur der TI skizziert und danach wird die Sicherheitsarchitektur und deren Umsetzung in den verschiedenen Phasen des Lebenszyklus der Produkte der TI beschrieben. Schließlich wird die Migration auf die nächste Ausbaustufe der TI beschrieben.

4.1 Architektur der TI

Die Architektur der aktuellen Ausbaustufe der TI 1.0 folgt einem Zonenkonzept, das festlegt, welche Komponenten und Dienste miteinander Daten austauschen dürfen. Abbildung 7 zeigt die Komponenten und Dienste der TI in den ihnen zugewiesenen Zonen.

Abbildung 7: Architektur der TI 1.0 im Überblick

Die Zonen im Einzelnen:

Dezentrale TI­Plattform­Zone

Die TI­Plattform ist in eine zentrale und eine dezentrale Zone unterteilt. Die dezentrale TI-Plattform Zone enthält die dezentralen Komponenten. Zu diesen gehören die Karten aller Beteiligten in der Telematikinfrastruktur (elektronische Gesundheitskarte des Versicherten, elektronischer Heilberufsausweis, elektronischer Praxisausweis), Kartenterminals, der Konnektor sowie die Gerätekarten, die den Kartenterminals und Konnektoren eine eindeutige Identität zuordnen. Diese Komponenten werden von den Nutzern der Telematikinfrastruktur eingesetzt, sie befinden sich also grundsätzlich dezentral in den Arztpraxen, Krankenhäusern etc. Ausnahmen davon bilden Consumer und das TI-Gateway.

Zu den personengebundenen Karten gehört insbesondere die elektronische Gesundheitskarte (eGK). Sie speichert digitale Schlüssel und Daten des Versicherten. Das sind die Versichertenstammdaten und, falls der Versicherte dies wünscht, zusätzlich die Notfalldaten und ein elektronischer Medikationsplan. Die digitalen Schlüssel sind eine digitale Identität des Versicherten in der Telematikinfrastruktur. Der Versicherte kann sich damit in der Telematikinfrastruktur authentisieren, um beispielsweise auf seine elektronische Patientenakte (ePA) oder E-Rezepte zuzugreifen. Sensible Daten und die digitalen Schlüssel auf der Gesundheitskarte sind technisch vor unberechtigtem Zugriff geschützt. Hier gibt es zwei Schutzmaßnahmen: die Eingabe der PIN des Versicherten und eine Authentisierung zwischen zwei Karten, also der Authentisierung eines Leistungserbringers (in seiner Rolle als Arzt, Apotheker etc.) mittels elektronischen Heilberufsausweis direkt gegenüber der eGK eines Versicherten (Card-to-Card-Authentisierung).

Die PIN der eGK wird dem Versicherten von seiner Krankenkasse in einem Brief mitgeteilt. Sie ist sechsstellig und kann vom Versicherten geändert werden.

Durch diese Schutzmaßnahmen wird technisch verhindert, dass jemand mit einer gefundenen oder gestohlenen Gesundheitskarte Zugriff auf die sensiblen Daten oder Schlüssel auf der Karte erhält. Verliert der Versicherte seine Gesundheitskarte, muss er dies trotzdem unverzüglich seiner Krankenkasse melden, damit diese die Karte sperren kann und somit eine missbräuchliche Nutzung verhindert werden kann (bspw. Ist die Autorisierung zum Datenabruf für berechtigte Teilnehmer der TI – also bspw. Arztpraxen oder Apotheken – nur mit Übergabe der eGK und somit ohne Eingabe der PIN möglich).

Auch Ärzte, Zahnärzte, Psychotherapeuten und Apotheker besitzen eine Karte: den elektronischen Heilberufsausweis (HBA). Für die Mitarbeiter in den Institutionen des Gesundheitswesens (Arztpraxis, Krankenhaus, Apotheke) gibt es den Praxisausweis (Institutionskarte, SMC-B). Auch diese Karten besitzen Schlüssel, über die die Leistungserbringer und Leistungserbringerinstitutionen ihre Identität nachweisen können. Heilberufsausweis und Praxisausweis ermöglichen Leistungserbringern, auf medizinische Daten auf der Gesundheitskarte mittels Card-to-Card-Authentisierung zuzugreifen wie auch auf die Daten der elektronischen Patientenakte und des E-Rezept-Fachdienstes, wenn sie vom Versicherten dazu berechtigt wurden. Unterschiedliche Gruppen von Leistungserbringern haben verschiedene Zugriffsrechte (abgestuftes Rollen- und Rechtekonzept). Ein Arzt hat beispielsweise andere Rechte als ein Apotheker. Zur Nutzung seines Heilberufsausweises oder seines Praxisausweises muss der Leistungserbringer eine PIN eingeben. Erst dann kann er damit auf Daten des Versicherten zugreifen. Daher ist eine gefundene oder gestohlene Karte eines Leistungserbringers nutzlos, man kann damit keine Daten eines Versicherten einsehen. Auf dem Heilberufsausweis befindet sich zudem Schlüsselmaterial für eine qualifizierte elektronische Signatur (QES). Mit einer solchen Signatur versichert der Leistungserbringer rechtsverbindlich, der Urheber der signierten Daten zu sein. Die qualifizierte elektronische Signatur ist das digitale Pendant zur handschriftlichen Unterschrift. Bei der Beantragung eines Heilberufsausweises bzw. eines Praxisausweises werden Leistungserbringer sicher identifiziert und es wird ihre Berufsgruppenzugehörigkeit geprüft. Damit wird ausgeschlossen, dass Unbefugte eine solche Karte erhalten.

Auch der Konnektor und die Kartenterminals besitzen eine eigene Karte. Die Konnektorkarte (gSMC-K) ist fest verbaut und somit Teil des Konnektors. Die Karten der Kartenterminals (gSMC-KT) stecken dauerhaft in den Terminals, sind aber nicht fest in diesen verbaut. Die Gerätekarten werden beispielsweise für den Aufbau von geschützten Verbindungen (TLS) verwendet.

Die Kartenterminals sind die Bindeglieder zwischen der Gesundheitskarte des Versicherten sowie den Karten der Leistungserbringer und dem Konnektor. Sie stellen eine transportgeschützte (TLS-) Verbindung zum Konnektor her, damit die Daten, die von den Karten gelesen bzw. auf sie geschrieben werden, von unbefugten Personen nicht abgefangen oder unbemerkt manipuliert werden können. Die Kartenterminals für die Telematikinfrastruktur werden als E-Health-Kartenterminals bezeichnet und besitzen ein PIN-Pad, ein Display und mindestens zwei Kartenschlitze, in die jeweils eine elektronische Gesundheitskarte und ein Heilberufsausweis bzw. ein Praxisausweis gesteckt werden können. Zusätzlich gibt es einen Kartenschlitz für die Karte des Kartenterminals. Da diese Karte nicht direkt in dem Gerät verbaut ist, wird sie mit einem fälschungssicheren Siegel überklebt, wodurch eine Manipulation am Gerät sofort erkennbar ist. Dank einer Transportverschlüsselung nach Stand der Technik können keine Daten, die zwischen den Karten im Kartenterminal und dem Konnektor ausgetauscht wurden, nachträglich entschlüsselt werden. Das E-Health-Kartenterminal ist an einen festen Standort gebunden. Es wird z. B. in einer Arztpraxis oder in einem Krankenhaus aufgestellt. Damit Leistungserbringer auch außerhalb der Institution, etwa bei einem Hausbesuch, auf die Gesundheitskarte eines Versicherten zugreifen können, gibt es ein mobiles Kartenterminal. Dieses können Leistungserbringer zum Patienten mitnehmen. Die Versichertenstammdaten lassen sich mit einem mobilen Kartenterminal allerdings nicht aktualisieren.

Die Leistungserbringer benötigen einen Zugang zur TI. Dieser wird aktuell über den Konnektor realisiert. Er ist die steuernde Komponente bei den Leistungserbringern vor Ort. Der Konnektor bietet Schnittstellen für die IT-Systeme der Leistungserbringer an, über die die verschiedenen Funktionen der TI aufgerufen werden können, und kontrolliert die Kommunikation mit den Kartenterminals bei den Kartenzugriffen. Auch die Card-to-Card-Authentisierung wird vom Konnektor gesteuert. Damit die Leistungserbringer auf die zentrale TI-Plattform zugreifen können, baut der Konnektor einen sicheren Kanal zu den VPN-Zugangsdiensten der TI auf. Diese auf Netzebene gesicherte Verbindung (VPN-Tunnel mittels IPsec) zur zentralen TI-Plattform wird über das Internet hergestellt. Sensible Daten, die über diese Verbindung versandt werden, sind zusätzlich mit TLS transportgeschützt. Der Konnektor stellt die Basisfunktionalität und die Sicherheitsfunktionen (wie Verschlüsselung und Authentisierung) zur Verfügung. Diese werden zum einen von Anwendungen genutzt, die nur im Konnektor als Fachmodul realisiert sind und keinen Fachdienst nutzen (z. B. das Notfalldaten-Management und der elektronische Medikationsplan) und zum anderen können die Leistungserbringer die Funktionen des Konnektors auch direkt nutzen und etwa Dokumente verschlüsseln lassen oder diese mittels ihres HBA qualifiziert elektronisch signieren.

Secure Consumer Zone

Der Konnektor umfasst somit auch anwendungsspezifische Teile der Telematikinfrastruktur. Zum anderen können die Leistungserbringer bestimmte Basisfunktionen des Konnektors auch direkt nutzen und etwa Dokumente verschlüsseln lassen oder diese mittels ihres Heilberufsausweises qualifiziert elektronisch signieren. In seiner Funktion als Firewall schützt der Konnektor sowohl die IT-Systeme der Leistungserbringer als auch die zentrale TI-Plattform. Die IT-Systeme der Leistungserbringer werden vor Angriffen aus dem Internet, aber auch vor unberechtigten Zugriffen aus der zentralen TI-Plattform geschützt. Der Anschluss an die TI bedeutet also nicht, dass zentrale Dienste der TI-Plattform auf das IT-System des Leistungserbringers zugreifen können. Nur wenn der Leistungserbringer dies aktiv auslöst, werden von seinem IT-System Informationen über ihn oder seine Patienten an Dienste der Telematikinfrastruktur übertragen oder auf die eGK geschrieben. Für die Anwendung Versichertenstammdaten-Management müssen keine Daten aus den IT-Systemen der Leistungserbringer an den Konnektor übertragen werden. Für medizinische Anwendungen auf der Gesundheitskarte, etwa zur Pflege von Notfalldaten, werden medizinische Daten vom IT-System des Leistungserbringers an den Konnektor und von dort aus auf die eGK geschrieben – vorausgesetzt, der Leistungserbringer löst dies aus. Die Kommunikation zwischen dem IT-System des Leistungserbringers und dem Konnektor sowie die Kommunikation zwischen dem Konnektor und der zentralen TI-Plattform werden stets vom Leistungserbringer initiiert.

Neben den Konnektoren gibt es für den Zugriff von Organisationen des Gesundheitswesens (bspw. Krankenkassen oder kassenärztliche Vereinigungen) eine Zugangslösung, die im RZ betrieben wird, der Basis-Consumer. Dieser Basis-Consumer ist auf die Bedürfnisse der o.g. Nutzergruppe zugeschnitten und bieten einen kleineren Funktionsumfang (KIM und Zugriff auf ePA) aber mit höherer Performance.

Consumer Zone

Die IT-Systeme der Nutzer werden als Primärsysteme zusammengefasst. Darunter befinden sich Praxis- und Apothekenverwaltungssysteme, Krankenhausinformationssysteme und Clientsysteme von zugreifenden Organisationen des Gesundheitswesens wie Krankenkassen und Kassenärztliche Vereinigungen. Diese Primärsysteme werden der Consumer Zone zugeordnet. Gleiches gilt für andere Clients, die direkt auf den Konnektor zugreifen wie das KIM Client Modul und den Authenticator.

Zentrale TI-Plattform Zone

Die zentrale TI-Plattform Zone enthält die zentralen Dienste der TI-Plattform, die die Anwendungen der Telematikinfrastruktur mit grundlegenden Funktionalitäten unterstützen.

Die VPN-Zugangsdienste stellen für die Anbindung von Leistungserbringerinstitutionen die Verbindung zwischen dezentraler und zentraler TI-Plattform dar. VPN steht für Virtual Private Network, ein in sich abgeschlossenes (privates) Netzwerk, mit dem sich Daten über ungeschützte Netze wie das Internet verschlüsselt und manipulationsgeschützt versenden lassen. Der Konnektor beim Leistungserbringer baut einen sogenannten VPN-Tunnel auf, der bei den VPN-Zugangsdiensten der zentralen TI-Plattform endet. Bevor eine solche Verbindung aufgebaut werden kann, muss der Konnektor registriert werden. Dafür ist ein Praxisausweis notwendig. Daher können nur medizinische Institutionen mittels des Konnektors das zentrale Netz der Telematikinfrastruktur und darüber die zentralen Dienste und Fachdienste erreichen.

Das zentrale Netz der Telematikinfrastruktur verbindet die zentralen Dienste, Fachdienste und die VPN-Zugangsdienste. Es handelt sich um ein geschlossenes Netz, zu dem der Zugang nur über sichere Zugangspunkte möglich ist. Die Dienste bzw. die Rechenzentren, in denen die Dienste betrieben werden, sind dabei direkt an das zentrale Netz der TI angebunden. Aus dem Internet kann man somit nicht auf das zentrale Netz der Telematikinfrastruktur zugreifen.

Grundvoraussetzung für eine datenschutzkonforme und sichere Vernetzung des Gesundheitswesens ist die zweifelsfreie Identifikation der Teilnehmer. Hierzu wird jedem Teilnehmer eine in der TI eindeutige technische Identität zugeordnet – seien es Versicherte, Leistungserbringer, medizinische Institutionen, dezentrale Komponenten oder auch Dienste der zentralen TI-Plattform.

Die Identitäten der Telematikinfrastruktur werden in einer Public Key Infrastructure (PKI) verwaltet und bestehen aus Schlüsselpaaren und Zertifikaten. Eine Authentisierung verläuft dann technisch über das Vorweisen eines Authentisierungszertifikats und eine Signatur mit dazugehörigem privatem Schlüssel. Für Versicherte ist dieses Schlüsselmaterial sicher auf der eGK gespeichert und mittels Eingabe der PIN nutzbar. Leistungserbringer authentisieren sich ebenso über Ihre Smartcards mit Hilfe der PKI. Ebenso gibt es in der PKI TLS-Zertifikate für Komponenten und Dienste für authentisierte Verbindungen zwischen diesen. Entsprechend gelten für die Ausgabe von Zertifikaten in der Telematikinfrastruktur besonders hohe Sicherheitsstandards. Diese Zertifikate zum Identitätsnachweis haben eine begrenzte Gültigkeitsdauer und können gesperrt werden.

Die Identität eines Teilnehmers wird benötigt, wenn dieser sich in der Telematikinfrastruktur ausweist, für ihn verschlüsselt werden soll oder er signiert. Für jeden dieser Zwecke besitzt der Teilnehmer in der TI-PKI ein separates Schlüsselpaar und ein dazugehöriges Zertifikat. Somit wird durch die Prüfung des Zertifikats technisch eindeutig festgestellt, mit wem eine Kommunikation stattfindet, für wen etwas verschlüsselt wird oder wer etwas signiert hat.

Für Versicherte gibt es für die Authentisierung zusätzlich auch bereits die sogenannte GesundheitsID (siehe 4.2.4), über die eine Token-basierte Anmeldung unter Nutzung eines Identity Providers (IDP) möglich ist. Für die Authentisierung gegenüber dem IDP ist nicht jedes Mal die Nutzung der eGK mit PIN erforderlich. Für einen begrenzten Zeitraum kann ein auf dem Smartphone des Versicherten gespeichertes Schlüsselpaar zur Authentisierung gegenüber dem IDP verwendet werden. Auch für Leistungserbringer soll es zukünftig die GesundheitsID geben.

Für die weiter oben genannte Card-to-Card-Authentisierung und das damit verbundene Rollen- und Rechtekonzept ist den Teilnehmern der Telematikinfrastruktur über ein gesondertes Zertifikat eine Rolle (z. B. »Arzt« oder »Apotheker«) zugeordnet. Darüber werden den unterschiedlichen Leistungserbringerrollen jeweils nur die gesetzlich festgelegten Zugriffsrechte auf Daten der Gesundheitskarte gewährt.

Für die Identitäten aus der TI-PKI gibt es zudem einen Verzeichnisdienst. Dieser ist mit einem Telefonbuch für die Telematikinfrastruktur vergleichbar. Er speichert Zertifikate von Leistungserbringern, medizinischen Institutionen und Organisationen des Gesundheitswesens (z. B. Krankenkassen), mit denen Informationen für den jeweiligen Teilnehmer verschlüsselt werden können (Verschlüsselungszertifikat). Weiterhin können Informationen gespeichert werden, die spezifisch für eine Anwendung der Telematikinfrastruktur benötigt werden. Ein Beispiel hierfür sind die in der Anwendung Kommunikation im Medizinwesen (KIM) benötigten E-Mail-Adressen von Teilnehmern dieser Anwendung. Die Informationen des Verzeichnisdienstes sind für jeden Teilnehmer der Telematikinfrastruktur einsehbar.

Neben den genannten Diensten gibt es auf der zentralen TI-Plattform weitere Dienste, die Funktionen anbieten, die in jeder Kommunikations-IT-Infrastruktur benötigt werden. Hierzu gehören ein Zeitdienst für eine einheitliche Zeit in der Telematikinfrastruktur sowie ein Namensdienst, um Dienste zu finden. Zudem gibt es einen Konfigurationsdienst, um die Software und die Konfigurationen der dezentralen Komponenten wie Konnektor und Kartenterminals zu aktualisieren.

Provider Zone

Der Provider Zone sind die Fachdienste der Anwendungen der TI zugeordnet. Es gibt Fachdienste, die von einem Fachmodul im Konnektor angesprochen werden (z.B. VSDM, ePA) und Fachdienste, die direkt von den Primärsystemen der Leistungserbringer angesprochen werden (z.B. E-Rezept) bzw. von anderen Komponenten in der Consumer Zone (KIM Client Modul). Fachdienste, die von Frontends des Versicherten angesprochen werden, besitzen hierfür eine Schnittstelle zum Internet.

Zur Provider Zone gehören ebenfalls die Weiteren Anwendungen (WANDA smart), die Dienste der TI in der Zone TI-Plattform zentral nutzen.

Existing Application Zone

Diese Zone beinhaltet sog. Bestands- bzw. Backendsysteme. Diese Systeme gehören nicht zur TI, kommunizieren aber mit Systemen in der Provider Zone.

Hinzu kommen die Weiteren Anwendungen (WANDA basic), die Dienste der TI in der Zone TI-Plattform zentral nicht nutzen, sondern lediglich über das Netz der TI von den Primärsystemen erreichbar sind.

Personal Zone

Die Frontends des Versicherten (FdV) bzw. Apps, die über Module verfügen, die mit der TI kommunizieren, werden der Personal Zone zugeordnet. Die FdV bzw. Apps laufen auf (mobilen) Geräten der Versicherten.

4.2 Technische Maßnahmen

Das oben beschriebene Zonenkonzept mit den Komponenten und Diensten der TI beschreibt in erster Linie die grundsätzlich erlaubte Kommunikation zwischen Komponenten und Diensten der TI sowie zu angrenzenden Systemen.

Die Absicherung der erlaubten Kommunikationsbeziehungen und die Absicherung der kommunizierenden und datenverarbeitenden Systeme werden durch technische Maßnahmen erreicht, von denen eine Auswahl in den folgenden Abschnitten erläutert wird.

4.2.1 Ende-zu-Ende-Sicherheit

Ziel bei der Entwicklung aller Anwendungen der TI ist das Herstellen einer Ende-zu-Ende-Sicherheit. Neben dem Schutzziel Integrität, triff dies insbesondere auf das Schutzziel Vertraulichkeit zu. Dabei besteht das Ziel, die Enden, zwischen denen die Sicherheit hergestellt wird, möglichst nahe am jeweiligen Kommunikationspartner zu platzieren.

Eine Möglichkeit Vertraulichkeit Ende-zu-Ende herzustellen, ist eine Ende-zu-Ende-Verschlüsselung (E2EE).

E2EE kommt bei Anwendungen der TI zum Einsatz, die dafür gedacht sind, personenbezogene medizinische Daten zwischen den Kommunikationsteilnehmern auszutauschen – ohne dass die Daten auf dem Weg zwischen den Kommunikationsteilnehmern verändert bzw. ergänzt werden sollen. Gemäß dem Grundsatz mehrschichtiger Sicherheitsarchitektur wird zusätzlich zu gewöhnlicher Absicherung von Verbindungen auf Transport-Ebene, welche ggf. nicht Ende-zu-Ende erfolgt, sondern zwischenzeitlich terminiert, auch auf Verschlüsselungsverfahren auf Inhaltsebene gesetzt. Hierbei werden soweit möglich sowohl die tatsächlichen Inhalte der Nachrichten als auch sensible Metadaten betrachtet, um jegliche Kommunikation im Gesundheitswesen über die TI mit angemessener Vertraulichkeit umzusetzen. Auch hier werden soweit möglich, sinnvoll und verfügbar etablierte Technologien eingesetzt.

Anwendungen (z.B. E-Rezept) bei denen eine Verarbeitung der Daten im Fachdienst erfolgt, können nicht Ende-zu-Ende verschlüsselt sein. Hier wird die Ende-zu-Ende-Sicherheit durch eine Kette von (Transport-)Verschlüsselungen und anderen Mechanismen (z.B. vertrauenswürdige Ausführungsumgebung) hergestellt.

Unabhängig davon, wie eine Ende-zu-Ende-Sicherheit realisiert ist, wird damit technisch ausgeschlossen, dass Unbefugte auf personenbezogene medizinische Daten zugreifen können. Grundsätzlich trifft das auch auf die Anbieter bzw. Betreiber von Fachdiensten zu.

4.2.2 Vertrauenswürdige Ausführungsumgebung

Eine serverseitige Klartext-Verarbeitung von personenbezogenen medizinischen Daten und personenbezogenen Daten erfordert den technischen Ausschluss von Zugriffen des Anbieters – sofern keine gesetzliche Grundlage für den Zugriff durch den Anbieter/Betreiber existiert. Dies umfasst insbesondere Zugriffe durch Personen aus dem betrieblichen Umfeld des Anbieters bzw. Betreibers.

Die Vertrauenswürdige Ausführungsumgebung (VAU) dient der datenschutzrechtlich zulässigen und sicheren unverschlüsselten Verarbeitung von schützenswerten Daten innerhalb eines Fachdienstes. Die VAU stellt dazu einen Verarbeitungskontext bereit, in dem die Verarbeitung sensibler Daten unverschlüsselt erfolgen kann. Dieser Verarbeitungskontext ist entsprechend geschützt.

Die Gesamtheit aus der für eine Verarbeitung der unverschlüsselten Daten erforderlichen Software, dem für diese Verarbeitung genutzten physikalischen System sowie den für die Integrität dieser Verarbeitung erforderlichen organisatorischen und physischen Rahmenbedingungen bildet die Vertrauenswürdige Ausführungsumgebung.

Der Verarbeitungskontext innerhalb einer VAU grenzt sich von allen weiteren, im betrieblichen Kontext beim Anbieter des Fachdienstes vorhandenen Systemen und Prozessen dadurch ab, dass die unverschlüsselten Daten von Komponenten innerhalb des Verarbeitungskontextes erreichbar sind oder sein können, während sie dies von außerhalb des Verarbeitungskontextes nicht sind. Die schützenswerten Daten verlassen den Verarbeitungskontext ausschließlich gemäß wohldefinierten (Zugriffs-)Regeln und in verschlüsselter Form.

Zur Vertrauenswürdigen Ausführungsumgebung gehören neben dem Verarbeitungskontext alle für seine Erreichbarkeit und betriebliche Steuerung erforderlichen Komponenten. Diese Komponenten dürfen nur soweit unbedingt erforderlich als Teil des Verarbeitungskontextes implementiert sein (Minimierung der Trusted Computing Base).

Die VAU benötigt mindestens eine kryptographische Identität, um sich gegenüber Nutzern auszuweisen, sowie ggf. (symmetrisches) Schlüsselmaterial für die Datenspeicherung außerhalb der VAU, um für persistierte Daten den Anbieter vom Zugriff. Der Vertrauensanker für die Identität sowie die Funktionen zur Vorhaltung, Generierung oder Ableitung von Persistenz-Schlüsseln werden von einem HSM bereitgestellt. Das HSM bzw. ein mit dem HSM verbundener Attestationsdienst muss die Integrität eines Verarbeitungskontextes feststellen können (Attestation), bevor die Identität oder Persistenz-Schlüssel bzw. für die Ableitung solcher Schlüssel erforderliches Schlüsselmaterial an den Verarbeitungskontext übermittelt werden oder der Zugriff auf die zur Nutzung von im HSM gehaltenen Schlüsseln autorisiert wird.

Systeme zur Ausführung von Verarbeitungskontexten müssen über geeignete Sicherheitsmechanismen zum Ausschluss von Zugriffen durch den Anbieter verfügen.

Die Einrichtungsprozesse für das HSM und seiner Beziehungen zu Systemen, die Verarbeitungskontexte ausführen, müssen Manipulationen aus der Umgebung des Anbieters ausschließen und ein zeremoniell geführtes Mehr-Augen-Prinzip unter Einbeziehung einer qualifizierten, vom Anbieter unabhängigen Instanz umsetzen (z.B. von der gematik).

Um zu verhindern, dass Verarbeitungsvorgänge eines Akteurs schadhaft auf Verarbeitungsvorgänge anderer Akteur einwirken können, werden Mechanismen zur Trennung der Verarbeitungskontexte durch die VAU umgesetzt.

Systeme und Software der VAU müssen von Systemen und Software unbekannter Herkunft oder unklarer sicherheitstechnischer Eignung isoliert betrieben werden.

4.2.3 Anwendungen mit mobilen Clients

Mobile Clients (FdV, Apps) für den Zugriff auf Fachdienste in der TI gewinnen zunehmend an Bedeutung für die Versicherten. Im Zuge dessen legt die gematik beim Design der Anforderungen ein verstärktes Augenmerk auf die Besonderheiten, die sich für die Sicherheit von Clients auf mobilen Endgeräten ergeben. Neben gängigen Standards für diese Szenarien, wie den OWASP-Top-10-Mobile rücken hierbei auch weitere Mobil-spezifische Themen ins Blickfeld, die bei stationären Clientsystemen bisher nur eine untergeordnete Rolle spielten, wie z.B. Abschottung von TI-Clientanwendungen gegenüber anderen Anwendungen auf den mobilen Plattformen.

Für den Zugriff auf personenbezogene medizinische Daten wird bei bestimmten Anwendungen (z.B. ePA) eine Registrierung des Geräts durch den Nutzer durchgeführt, um die Identifizierung und Authentisierung des Nutzers mittels des Geräts zu ermöglichen. Zusätzlich zum Nachweis über die Identität des Nutzers wird damit beim Zugriff auf die Anwendung der Nachweis über den Besitz des registrierten Endgerätes erbracht. So kann verhindert werden, dass der Besitz eines ID-Token ausreicht, um eine erfolgreiche Autorisierung am Fachdienst zu erreichen. Dies dient auch dazu, eine Allmachtstellung des IDP als Aussteller des ID-Token zu verhindern.

Mit der zukünftigen Einführung einer Zero Trust Architektur in die nächste Ausbaustufe der TI wird die Gerätebindung flächendeckend für alle Anwendungen der TI umgesetzt.

4.2.4 GesundheitsID

Fachdienste müssen Nutzer vor der Gewährung von Zugriff auf personenbezogene (medizinische) Daten sicher identifizieren, authentifizieren und autorisieren. Die GesundheitsID als digitale Identität im Gesundheitswesen soll künftig als Alternative zur eGK (siehe Erläuterungen zur PKI in 4.1) eingesetzt werden und bietet Versicherten somit einen kartenlosen Zugang zu allen Anwendungen der Telematikinfrastruktur. Die Krankenkassen stellen ihren Versicherten seit dem 1.1.2024 auf Wunsch eine digitale Identität in Form einer GesundheitsID zur Verfügung. Um den Einsatz der digitalen Identität vor Missbrauch zu schützen, ist eine 2-Faktor-Authentifizierung notwendig. Aktuell ist vorgesehen, dass die GesundheitsID zyklisch durch eine Anmeldung über die Online-Ausweisfunktion des Personalausweises oder über die eGK mit PIN bestätigt werden muss.

Die Umsetzung digitaler Identitäten erfolgt durch verteilte und dezentrale Identity Provider und Access Provider. Identity Provider bestätigen die Identität sowie die im minimalen Datensatz enthaltenen Claims (zusätzliche Identitätsinformationen) über ID-Token. Access Provider müssen die Berechtigung eines Nutzers zur Verwendung eines Fachdienstes bestätigen und daher Access Token ausstellen. Auf deren Basis entscheidet der Fachdienst über den Zugriff. Die Rolle des Access-Providers kann vom Betreiber eines Fachdienstes – oder wie im Falle E-Rezept durch den Identitiy Provider – übernommen werden. Die ausgestellten Token sind an das vom Nutzer verwendete Gerät gebunden. Die Identity und Access Provider müssen beim Federation Master der gematik registriert werden und die zentralen Richtlinien für solche Provider einhalten. Bei der Registrierung müssen die Betreiber der Provider zudem nachweisen, welches Vertrauensniveau auf Basis der technischen und organisatorischen Maßnahmen erreicht werden kann. Zusätzlich können Provider, falls erforderlich, auf Nutzergruppen oder Anwendungsfälle beschränkt werden. Diese Beschränkungen sind öffentlich innerhalb der Föderation bekannt und müssen von den Fachdiensten auf Basis der ausgestellten Tokens ausgewertet und durchgesetzt werden. Verstöße gegen die Beschränkungen oder weitere Auflagen der zentralen Richtlinie sind durch den Betreiber des Fachdienstes der gematik umgehend mitzuteilen. Zusätzlich müssen Betreiber von Providern technische und organisatorische Maßnahmen ergreifen, welche auch gegenüber Innentätern sicherstellen, dass Provider nicht missbraucht werden können. Es müssen zudem Maßnahmen getroffen werden, welche insbesondere die Ausstellung von Tokens für nicht zugehörige Identitäten verhindern.

Innerhalb der Föderation der Provider und Fachdienste besteht eine gegenseitige Anerkennung der ausgestellten Tokens. Diese werden mit Informationen über das erreichte Sicherheitsniveau und technischen Details bzgl. Authentifizierung und Identifikation des Nutzers versehen. Die Tokens werden validierbar und manipulationssicher ausgestellt und übermittelt.

Die Fachdienste entscheiden auf Basis der Schutzbedarfsfeststellung, welches Vertrauensniveau für unterschiedliche Anwendungsfälle erreicht werden muss. Tokens mit unzureichendem Vertrauensniveau müssen abgelehnt und der Nutzer zu starker Authentifizierung aufgefordert werden. Der zur Aufnahme in die Föderation notwendige minimale Datensatz eines Nutzers wird von der gematik in der zentralen Richtlinie für Provider festgelegt. Fachdienste können darüber hinaus weitere Informationen über den Nutzer anfordern, welche aus unterschiedlichen Quellen bereitgestellt werden können. Möglich sind zentrale oder auch dezentrale Quellen. Abhängig von der Quelle der Informationen, ist eine Prüfung der Gültigkeit bzw. Verifikation der Richtigkeit durch den Fachdienst erforderlich.

Alle Betreiber von Providern innerhalb der Föderation müssen Sperrmeldungen von Nutzern, Fachdiensten, weiteren TI-Teilnehmern oder Dritten entgegennehmen. Hierbei müssen mindestens die Standardkommunikationskanäle bereitgestellt werden, welche in der zentralen Richtlinie für Provider genannt werden. Es obliegt den Betreibern, die Rechtmäßigkeit der Sperrmeldungen zu prüfen.

Betreiber von Providern müssen sicherstellen, dass der betriebene Provider sowohl durch interne als auch durch externe Täter nicht zum Zwecke der unerlaubten Profilbildung missbraucht werden kann. Diesem Risiko muss bereits vom Hersteller in der Entwicklungsphase des Providers entgegengewirkt werden. Sowohl Hersteller als auch Betreiber müssen die getroffenen Maßnahmen zur Einhaltung der Datenschutz- und Sicherheitsanforderungen der TI nachweisen.

4.2.5 Prüfidentitäten in der Produktivumgebung

Zur Vermeidung von Störungen und für einen ordnungsgemäßen Betrieb der TI, z.B. zur Change-Validierung oder eines Troubleshootings, können in der Produktivumgebung (PU) der TI-Prüfidentitäten eingesetzt werden.

Prüfidentitäten können für die in Abschnitt 2.3 genannten Akteure der TI erstellt werden, insbesondere für Versicherte, Leistungserbringer oder Leistungserbringerinstitutionen. Die Identitätsdaten einer Prüfidentität dürfen keine Echtdaten einer tatsächlich existierenden Identität enthalten bzw. mit einer solchen verwechselt werden können. Die kryptographischen Identitäten von Prüfidentitäten sind jedoch aus der PKI der PU. Dies unterscheidet sie von Testidentitäten, deren kryptographische Identitäten keine PU-Identitäten sind und daher nicht in der PU genutzt werden können.  

Aufgrund des hohen Risikos für die Rechte und Freiheiten der Betroffenen in den Verarbeitungen der personenbezogenen Daten in der TI, muss in der PU technisch ausgeschlossen werden, dass mit Prüfidentitäten auf Echtdaten tatsächlich existierender Akteure zugegriffen werden kann. Es dürfen beispielsweise keine Prüfidentitäten zum Zugriff auf medizinische Echtdaten von Versicherten berechtigt werden. In der PU müssen daher die Verarbeitungsvorgänge mit Prüfidentitäten/-daten von jenen mit Echtidentitäten/-daten vollständig technisch getrennt werden. Eine Vermischung muss technisch ausgeschlossen werden.

Von diesem Abschnitt nicht betroffen sind die Regelungen für den Einsatz von Prüfnutzeridentitäten gemäß § 331 SGB V durch die gematik. Für deren Einsatz gelten die Vorgaben des § 331 SGB V.

4.3 Organisatorische Maßnahmen

Obwohl grundsätzlich technische Maßnahmen zum Datenschutz und der Informationssicherheit bevorzugt werden, sind organisatorische Maßnahmen unerlässlich. Einerseits als Ergänzung zu technischen Maßnahmen, anderseits als alleinstehende Maßnahmen, wenn keine Technik einsetzbar ist.

4.3.1 Betriebliche Security Governance

Die zentrale Aufgabe der gematik in der Betriebsphase ist die Steuerung der verschiedenen Anbieter und Betreiber bei der Wahrnehmung ihrer betrieblichen Verantwortung für die von ihnen betriebenen Produkte der Telematikinfrastruktur. Die gematik nimmt im Rahmen der Steuerung aus Sicherheitssicht insbesondere die folgenden Aufgaben wahr:

Qualitätssicherung

Ein wesentlicher Aspekt bei der Steuerung der Anbieter ist die regelmäßige Verifikation, ob die im Rahmen der Zulassung initial geprüften Sicherheitsanforderungen auch kontinuierlich im Betrieb aufrechterhalten werden. Dies umfasst neben den über Anforderungen geforderten Konfigurationen der technischen Systeme auch die allgemeinen betrieblichen Leistungen (z.B. Zutrittsschutz im Rechenzentrum) sowie die kontinuierliche Umsetzung der spezifizierten organisatorischen Prozesse. Im Rahmen der Aufgabe werden regelmäßig Audits, Sicherheitsüberprüfungen und Notfallübungen bei den Anbietern der TI-Dienste durchgeführt, um zu verifizieren, dass die Anforderungen hinsichtlich der Verfügbarkeit und Sicherheit der Betriebsleistung erfüllt werden. Die Ergebnisse werden dem Anbieter präsentiert und gegebenenfalls Gegenmaßnahmen vorgeschlagen.

Technische Überwachung

Neben den in Spezifikationen geforderten Anforderungen an Anbieter überwacht die gematik im operativen Betrieb kontinuierlich und anbieterunabhängig alle relevanten Systeme der Telematikinfrastruktur. Beispiele hierfür sind das kontinuierliche Monitoring der Internetschnittstellen der Telematikinfrastruktur sowie die Durchführung von regelmäßigen Schwachstellenscans und Penetrationstests. Eine Detaillierung der Maßnahmen ist im Konzept Überwachung der Sicherheit in der Telematikinfrastruktur ([gemKon_ÜberSi_TI]) zu finden.

Unterstützung

Aufgrund der verteilten Verantwortung für die Produkte der Telematikinfrastruktur durch mehrere Anbieter ist es für einen Anbieter nicht oder nur schwer möglich, jederzeit die Abhängigkeiten und Gesamtzusammenhänge zu erfassen. Daher unterstützt die gematik die Anbieter bei der Wahrnehmung ihrer betrieblichen Verantwortung. Dies umfasst die enge Abstimmung im Rahmen von Partnerworkshops, regelmäßigen Security Calls oder dem Arbeitskreis Datenschutz und Informationssicherheit aber auch die operative Unterstützung durch Weiterleitung von Security Advisories (z.B. UP KRITIS Meldungen) sowie die anonyme Weiterleitung von Hinweisen bei Sicherheitsvorfällen an andere Anbieter, die ebenfalls betroffen sein könnten.

Sanktionierung

Obwohl die gematik im Bereich der Anbietersteuerung im operativen Betrieb immer eine partnerschaftliche Zusammenarbeit anstrebt, ist es dennoch im Bedarfsfall erforderlich, Sanktionen bei grobem Fehlverhalten zu verhängen, insbesondere, wenn das Fehlverhalten zu schweren Schwachstellen oder Sicherheitsvorfällen geführt hat. Möglichkeiten zur Sanktionierung sind Bußgelder, Geld- bzw. Freiheitsstrafen, die temporäre Deaktivierung eines Dienstes aufgrund von unmittelbarer Gefährdung für die TI sowie der komplette Entzug der Zulassung.

4.3.2 Risikomanagement

Risiken sind komplexen IT-Systemen wie der TI inhärent. Dies betrifft insbesondere auch Datenschutz- und Sicherheitsrisiken. Datenschutz- und Sicherheitsrisiken können in jeder der Phasen des Phasenmodells (vgl. 3.2) auftreten.

Das übergreifende Risikomanagement der gematik dient als Mittel zur Erreichung der Unternehmensziele sowie als Instrument zur Steuerung der Organisation und ihres gesetzlichen Auftrages, indem Entscheidungen auf Basis einer pflichtgemäßen Abwägung von Risiken und Chancen getroffen werden. Risikomanagement wird in diesem Zusammenhang ganzheitlich als Risiko- und Chancenmanagement verstanden und gelebt. Die gematik orientiert sich im Kontext des Risikomanagements an der internationalen Norm ISO 31000.

Die Einzelheiten des Risikomanagements der gematik, wie Rollen und Verantwortlichkeiten und der Risikoprozess sind in der Richtlinie Risikomanagement ([RL_RMS]) festgelegt.

4.3.3 Notfallmanagement

Mit der steigenden Bedeutung der TI für die Versorgungsprozesse im Gesundheitswesen wird es immer wichtiger auf Situationen reagieren zu können, die zu einer Nichtverfügbarkeit von Anwendungsfällen führen. Das Notfallmanagement der gematik für die TI greift bei übergreifenden Schadensereignissen, die nicht allein durch die lokale Notfallorganisation von beteiligten Teilnehmern der TI zu bewältigen sind oder welche schwerwiegende Auswirkungen auf Services bzw. Produkte von weiteren TI-Teilnehmern haben. Ein TI-Notfall hebt sich insbesondere dadurch hervor, dass die Telematikinfrastruktur (TI) beziehungsweise ein TI-Service in beträchtlichem Maße – auch im Kontext der Sicherheit – gestört oder stark gefährdet ist.

Für diese Situationen hat die gematik ein Notfallkonzept für die TI erarbeitet, das auch notfallrelevante Aspekte in den einzelnen Produktspezifikationen berücksichtigt. Hierbei fließen die Erkenntnisse der Business-Impact-Analysen (BIA, vgl. 3.3.6) ein, die für die Produkte der TI abschätzen, wie sich die Störung eines Service über die Zeit auf die TI auswirkt. Dabei werden auch die Abhängigkeiten von Services untereinander betrachtet.

Alle Anbieter von Produkten der TI sind verpflichtet, ein eigenes, für das von ihnen betriebene Produkt spezifisches Notfallkonzept zu erstellen und zu pflegen oder die für die Telematikinfrastruktur (TI) betriebenen Dienste in ein bestehendes Notfallkonzept einzubinden. Die Anbieter sollen dabei dem BSI-Standard 100-4 folgen.

4.3.4 Melde- und Anweisungsflüsse

Durch die gesetzlichen Vorgaben des SGB V bestehen zwischen Anbietern und gematik auf der einen Seite und der gematik und dem BSI auf der anderen Seite Verpflichtungen zum Melden von Störungen bzw. Ansprüche zur Beseitigung von Mängeln.

Abbildung 8: Melde- und Anweisungsflüsse nach SGB V

In Tabelle 1 werden die einzelnen Regelungen, die zwischen der gematik, dem BSI, dem BMG und dem Anbieter eines zugelassenen bzw. bestätigten Dienstes gelten, erläutert.

Tabelle 1: Regelungen und gesetzliche Grundlagen aus dem SGB V der Melde- und Anweisungsflüsse

4.3.5 Koordinierende Stelle für Versicherte

Die datenschutzrechtliche Verantwortlichkeit in der TI lässt sich mit Blick auf die gesetzlich gewollte Verteilung von Aufgaben und Kompetenzen nicht auf eine einzelne Stelle festlegen. Insbesondere ist die gematik nicht der singuläre datenschutzrechtlich Verantwortliche für die TI. Tatsächlich sind verschiedene Unternehmen in eigener Verantwortung mit der Verarbeitung personenbezogener Daten innerhalb der TI befasst, so dass die datenschutzrechtlich Verantwortlichen in der TI verteilt sind. Der § 307 SGB V legt fest, welcher Verantwortliche für welche Komponenten oder Dienste der TI verantwortlich ist.

Auch wenn es in der TI nicht den singulären Verantwortlichen gibt, der die Pflichten gegenüber einem Versicherten vollständig erfüllen kann, muss dennoch gewährleistet sein, dass die Grundsätze für die Verarbeitung personenbezogener Daten eingehalten werden und die Versicherten ihre Betroffenenrechte effektiv geltend machen können. Die verteilten Verantwortlichkeiten in der TI dürfen nicht dazu führen, dass Betroffene in der Wahrnehmung ihrer Betroffenenrechte gehemmt werden. Es ist ihnen insbesondere nicht zuzumuten, aus der Vielzahl der Verantwortlichen der TI diejenigen auszuwählen, die für ihre Anfrage im Einzelfall zuständig sind.

Die gematik richtet daher gemäß § 307 Abs. 5 SGB V für die Betroffenen eine koordinierende Stelle ein. Die koordinierende Stelle erteilt den Betroffenen allgemeine Informationen zur TI sowie Auskunft über Zuständigkeiten innerhalb der TI, insbesondere zu datenschutzrechtlichen Verantwortlichkeiten.

Die gematik als koordinierende Stelle erhält dabei selbst keine Kenntnis über personenbezogene medizinische Daten oder diese Daten betreffende Vorgänge. Sie leitet die Versicherten lediglich an den zuständigen Verantwortlichen weiter, bei dem Versicherte ihre Betroffenenrechte mittels der dort bestehenden Datenschutzprozesse wahrnehmen können.

4.4 Migration zur TI 2.0

Der Systemumfang der TI 2.0 orientiert sich nicht mehr an netztechnischen Grenzen als vielmehr am Geltungsbereich und Regelungsumfang der TI-Policy. Der einheitliche Zugang zu allen Diensten der TI für alle Nutzer in stationären und mobilen Szenarien direkt über das Internet bedingt, dass technische Zonenkonzepte auf dem Maßstab der TI obsolet sind. So definieren sich die Systemgrenzen TI über die Reich- und Tragweite der TI-Policy.

Vollständig im Regelungsumfang der TI-Policy enthalten sind Dienste der Anwendungen der TI (Fachdienste), Anwendungsunterstützende Dienste, Infrastrukturdienste, TI-Attestations- und Registrierungs- sowie Vertrauensdienste. Vollständiger Regelungsumfang heißt, dass abhängig vom Schutzbedarf der verarbeiteten Daten und den damit verbundenen datenschutzrechtlichen Risiken für die Rechte und Freiheiten der Betroffenen

• die Datenschutz- und Sicherheitseigenschaften der Dienste von der gematik vorgegeben werden,
• die Anforderungen an die Qualität des Herstellungsprozesses von der gematik vorgegeben werden,
• zur Erfüllung der Anforderungen Nachweise durch den Hersteller erbracht werden müssen,
• Hersteller und Produkt zugelassen sein müssen,
• der Anbieter/Betreiber seine Eignung hinsichtlich des Datenschutzes und der Informationssicherheit nach Anforderungen der gematik nachweisen muss und
• der Dienst von der gematik hinsichtlich des Datenschutzes und der Informationssicherheit überwacht und der Anbieter von der gematik auditiert wird.

Andere Akteure und Komponenten werden von der TI-Policy berührt, aber nicht vollständig geregelt, da z.B. andere bzw. weitere (gesetzliche) Vorgaben gelten, Regelungen von Standesorganisationen zum Tragen kommen oder (betriebliche) Aspekte in der Eigenverantwortung des Nutzers liegen. Der Einfluss der TI-Policy beschränkt sich dabei auf Aspekte, die für eine datenschutzkonforme und sichere Nutzung der Dienste der TI wichtig sind. Betroffen hiervon sind z.B. die Herausgabeprozesse für die Nachweise von Identitäten, die auf Daten der TI-Dienste zugreifen wollen und die Integrität von Soft- und Hardware, mit der auf die Dienste der TI zugegriffen wird.

Von der TI-Policy unberührt sind das Internet oder auch die Attestationsdienste von Anbietern mobiler Plattformen.

Abbildung 9: System- und Regelungsgrenzen der TI 2.0

Auf dem Weg zur vollständigen Umsetzung der TI 2.0 werden mehrere Migrationsschritte vollzogen.

4.4.1 Umbau der Netzwerkkommunikation

So wurde in einem ersten Schritt eine weitere Zugangsmöglichkeit für alle Nutzergruppen geschaffen, die den für die TI 1.0 notwendigen Konnektor nicht (mehr) lokal in ihrer Umgebung nutzen wollen, sondern in der Umgebung eines professionellen Anbieters: Das TI-Gateway. Kern des TI-Gateways ist ein Highspeed-Konnektor, der den Funktionsumfang des Konnektors mit performanter im Rechenzentrum betriebener Hardware kombiniert. Zudem wird ein Zugangsmodul vom Anbieter TI-Gateway betrieben, über welches die Nutzer angebunden werden. Ein lokal betriebener Konnektor ist somit für die Nutzer nicht mehr notwendig, um die (Fach-)Dienste der TI im zentralen Netz erreichen zu können.

Im zweiten Migrationsschritt werden (Fach-)Dienste der TI direkt im Internet verfügbar gemacht. Die Kommunikation vom Primärsystem zu diesen Diensten benötigt dann weder einen Konnektor noch ein TI-Gateway. Durch den Wegfall des Konnektors in der Leistungserbringer- bzw. Kostenträgerumgebung, müssen diese Umgebungen auf einem anderen Weg gegenüber dem Internet geschützt werden. Die Verantwortung hierfür liegt bei den jeweils Verantwortlichen für diese Umgebungen. Die ersten Dienste, die direkt über das Internet erreichbar sind, sind die Dienste des TI-Messengers, die VSDM 2.0 Fachdienste und der anwendungsunterstützende Dienst des Proof of Patient Presence (PoPP).

Abbildung 10: Netzkommunikation in der Migration TI 1.0 zu TI 2.0

Das Zielbild hinsichtlich der Netzwerkkommunikation der TI 2.0 sieht die Ablösung des zentralen Netzes der TI und jeglicher speziellen Zugangstechnik vor. Stattdessen werden alle Dienste von allen Nutzern direkt über das Internet erreichbar sein. Die Sicherheitsziele des zentralen Netzes – der geschlossene Benutzerkreis, die reglementierten Kommunikationsbeziehungen sowie die vertrauliche Datenübertragung – werden über bereits etablierte Mechanismen (z.B. TLS) und neue Mechanismen (z.B. Zero Trust Architektur) erreicht.

4.4.2 Einführung einer Zero Trust Architektur

Das Zero Trust-Modell ist ein Sicherheitskonzept, das auf dem Prinzip strenger Zugriffskontrollen und dem grundsätzlichen Misstrauen (kein implizites Vertrauen) gegenüber jedem Kommunikationsteilnehmer beruht, selbst denen, die sich bereits innerhalb eines Netzwerkperimeters befinden. Es handelt sich um ein Sicherheitsrahmenwerk, das erfordert, dass alle Benutzer und deren Clients (Gerät und App), unabhängig von Netzwerkperimetern, authentifiziert, autorisiert und kontinuierlich auf ihre Sicherheitskonfiguration und Sicherheitsnachweise überprüft werden, bevor ihnen Zugriff auf Anwendungen und Daten gewährt oder dieser aufrechterhalten wird. Motiviert durch den „Assume Breach“-Ansatz basiert dieses Architekturdesign-Paradigma im Kern auf dem Prinzip der minimalen Rechte aller Entitäten in der Gesamtinfrastruktur (vgl. https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Zero-Trust/zero-trust_node.html)

Die Umsetzung von Zero Trust in der TI wird als Zero Trust Access (ZETA) bezeichnet. Dabei erfolgt die Einführung von ZETA schrittweise in zwei Dimensionen. Die eine Dimension ist die Entwicklung der ZETA Client-Komponenten von ungeprüften Informationslieferanten, die nicht nachprüfbare Aussagen über die verwendete Client Software machen, hin zu Komponenten, die prüfbare Informationen über den Client liefern. Diese Informationen werden von Dritten (z.B. Google, Apple) oder über den ZETA Guard mittels des TPM (Trusted Platform Module) des Geräts, auf dem der ZETA Client läuft (z.B. Windows, Linux), attestiert. In der anderen Dimension findet die schrittweise Einführung von ZETA statt, ausgehend von einzelnen Komponenten und Diensten der TI hin zu einer lückenlosen Umsetzung in allen Komponenten und Diensten der TI sowie allen Clients, die sich mit Diensten der TI verbinden. Zudem erfolgt im Laufe der Einführung von ZETA die Verfeinerung und Verbesserung der ZETA-Zugriffsregeln anhand der während der Einführung erlangten Erkenntnisse und Erfahrungen.

Abbildung 11: Komponenten und Dienste von ZETA

ZETA besteht aus den folgenden Komponenten und Diensten:

ZETA Guard

Der ZETA Guard besteht im Wesentlichen aus einem Policy Enforcement Point (PEP) und einem Policy Decision Point (PDP). Der PEP dient dazu, den Zugriff auf Ressourcen, basierend auf vordefinierten Richtlinien, zu kontrollieren und durchzusetzen. Der Policy Decision Point (PDP) ist die wesentliche Komponente von ZETA, die Zugriffsentscheidungen trifft, indem sie Richtlinien (Policies) interpretiert und anhand dieser Richtlinien Zugriffsanfragen bewertet. Im PDP erfolgt zudem die Client-Registrierung. Alle Clients, die mit Diensten der TI2.0 kommunizieren, sind zur Laufzeit bekannt. Mit einer Attestierung in Abhängigkeit von verfügbaren Mechanismen der Laufzeitumgebung (Geräte-Features, Betriebssystem) kann ein Vertrauen und eine Wiedererkennung von Clients und Geräten aufgebaut werden. Dabei wird zusätzlich der Mechanismus OAuth 2.0 Demonstrating Proof of Possession (DPoP) verwendet, der verhindert, dass gestohlene Access und Refresh Token durch Angreifer verwendet werden können, um Zugriff auf den Resource Server zu erhalten. Ein ZETA Guard wird in die Systeme jedes Dienstes der TI 2.0 und die Betriebsprozesse des jeweiligen Dienstanbieters integriert.

ZETA Client (ZC)

Der ZETA Client ist eine Komponente innerhalb einer Client-Anwendung, die auf einem stationären oder mobilen Gerät läuft. Der ZETA Client ist insbesondere für die Erzeugung, sichere Speicherung und Prüfung der kryptographischen App/Geräte-Identität, die Erzeugung der App/Geräte-Attestierung und die Ermittlung und Übertragung der Eigenschaften der Laufzeitumgebung (Betriebssystem, Betriebssystem Version, etc.) zuständig. Die Implementierung bzw. Integration in die Client-Anwendung erfolgt durch den jeweiligen Hersteller dieser Software.

ZETA PIP / PAP

Der PIP (Policy Information Point) ist für die Bereitstellung von Informationen über Sicherheitsrichtlinien zuständig. Er dient als zentraler Informationsdienst, der anderen Systemen und Komponenten im Zero Trust-Netzwerk Zugriff auf aktuelle Sicherheitsrichtlinien ermöglicht. Der PIP wird in Verantwortung der gematik betrieben, die auch für die Sicherheitsrichtlinien zuständig ist.

Der PAP (Policy Administration Point) ist für die Verwaltung und Konfiguration von Sicherheitsrichtlinien verantwortlich. Er bietet eine Schnittstelle über die Richtlinien in hoheitlicher Verantwortung definiert, geändert und gelöscht werden können. Dies ist Aufgabe der gematik.

Die Umsetzung von ZETA erfolgt schrittweise mit der Einführung von Diensten der TI 2.0.

4.4.3 Migration zur Ende-zu-Ende-Sicherheit

Die Verarbeitung strukturierter Daten in Fachdiensten, der Austausch von Daten zwischen verschiedenen Anwendungen und die Zurverfügungstellung von Daten für die Forschung ohne, dass ein Versicherter dies durch eine explizite Handlung ermöglichen muss, erfordern ein Sicherheitskonzept, das ohne eine versichertenindividuelle Verschlüsselung auskommt. So ermöglicht neben dem E-Rezept auch die „ePA-für-alle“ eine Verarbeitung der Daten im Fachdienst und eine Zurverfügungstellung der Daten für die Forschung, indem statt einer Ende-zu-Ende-Verschlüsselung eine Ende-zu-Ende-Sicherheit durch eine Kette von (Transport-)Verschlüsselungen und anderer Mechanismen (z.B. vertrauenswürdige Ausführungsumgebung, siehe 4.2.2) zum Einsatz kommt.

Durch den Wegfall des Konnektors und der darin integrierten Fachmodule für einzelne Anwendungen verschiebt sich das Ende der Sicherheit für diese Anwendungen bei den professionellen Nutzern der TI in deren IT-Systeme. Ob diese Systeme ein Sicherheitsniveau einhalten, das für den Zugriff auf Dienste der TI gefordert ist, wird durch Zero Trust Access geprüft.

4.4.4 Etablierung einer Health Care Confidential Computing Plattform

Healthcare Confidential Computing (HCC) realisiert das mit der vertrauenswürdigen Ausführungsumgebung (VAU) verbundene Sicherheitsniveau der TI für die Verarbeitung personenbezogener medizinischer Daten in Infrastrukturen mit dem Betriebsmodell einer Cloud. Statt einer Vielzahl von dedizierten on premise betriebener VAUen von verschiedenen Herstellern in verschiedenen Implementierungen und mit verschiedenen betrieblichen Abläufen, soll eine einheitliche technische und organisatorische Plattform für die Nutzung durch Anbieter von Diensten zur Verarbeitung personenbezogener medizinischer Daten geschaffen werden. Diese Plattform baut auf einer oder mehreren Confidential Computing Technologien von führenden Hardware-Herstellern auf. Die Aufgabe der Anbieter dieser Dienste ist dann lediglich die Bereitstellung der anwendungsspezifischen Software.  Dieses Vorgehen ermöglicht ein homogenes hohes Sicherheitsniveau, eine hohe Verfügbarkeit und eine günstigere Bereitstellung für Dienste und ihre Anbieter.

Die HCC Plattform muss noch etabliert werden. Wenn diese zur Verfügung steht, können neue Dienst sie von Anfang an nutzen. Dienste, die mit einer VAU eingeführt wurden, werden dann sukzessive auf die HCC Plattform migriert.

4.4.5 Ausweitung der digitalen Identitäten

Zukünftig werden auch für weitere Akteure der TI (z.B. Leistungserbringer) digitale Identitäten für das Gesundheitswesen zur Verfügung gestellt werden, die nicht an Chipkarten gebunden sind.

Die technischen Details und organisatorischen Abläufe hierzu sind noch in der Entwicklungsphase.

4.4.6 Integration entfernter (qualifizierter) Signaturen

Mit der Migration von kartenbasierten Identitäten auf digitale Identitäten und den Wegfall des Konnektors müssen auch neue Wege für die Erstellung von Signaturen in der TI ermöglicht werden. Die Lösung hierfür besteht in der Bereitstellung von interoperablen eIDAS-konformen Fernsignaturdiensten für qualifizierte elektronische Signaturen (QES) und Fernsignatur- bzw. Siegeldiensten für Institutionssignaturen.

Solche Dienste sind bereits am Markt vorhanden. Die Integration in die Anwendungsfälle der TI wird evaluiert und muss noch erfolgen.

4.4.7 Feststellen des Versorgungskontextes

Proof of Patient Presence (PoPP) ist ein Nachweis, der belegt, dass sich ein Versicherter zu einem bestimmten Zeitpunkt in einem Versorgungskontext mit einer bestimmten Leistungserbringerinstitution (LEI) befindet. Im kryptographisch gesicherten PoPP-Token sind somit Informationen über die LEI und über den Versicherten zusammengeführt. Dabei ist es die Aufgabe der PoPP-Lösung, die Authentifizierung der LEI durchzuführen und durch Authentifizierung des Versicherten per GesundheitsID oder Authentifizierung der elektronischen Gesundheitskarte (eGK) eines Versicherten den Versorgungskontext zu bestätigen. Das Ergebnis ist das PoPP-Token, das der LEI zur Autorisierung für den Zugriff auf die Daten des Versicherten in Diensten der TI dient.

Abbildung 12: Komponenten und Dienste von PoPP

Die Lösung besteht aus dem zentralen Server und verschiedenen Client-Komponenten:

• PoPP-Service – Dieser anwendungsunterstützende Dienst erstellt PoPP-Token für eine LEI. Die LEI authentisiert sich dafür mit der SM(C)-B. Ein Versicherter authentisiert sich entweder mit seiner eGK oder seiner GesundheitsID.
• PoPP-Client (PC) – Dieses logische Konstrukt enthält die Funktionalität für die Kommunikation des Primärsystems mit dem PoPP-Service. Dazu gehört die Anfrage zur Erzeugung von PoPP-Token für den eGK- und den GesundheitsID-Pfad und die Bereitstellung des PoPP-Token durch den PoPP-Service.
• PoPP-Modul (PM) für Versicherte (PoPP-Modul) – ist ein integriertes Anwendungsmodul in Apps von Krankenkassen, Versicherern oder Drittanbietern, mittels dessen ein Versicherter das Check-in bei einer LEI mit seiner GesundheitsID starten kann.

PoPP löst die temporären Brückenlösungen zum Nachweis eines Versorgungskontextes ab, die für die TI 1.0 eingeführt wurden.

4.5 Einbindung in den Europäischen Gesundheitsdatenraum

Der Europäische Gesundheitsdatenraum (EHDS) ist eine zentrale EU-Initiative, die den sicheren Austausch und die Nutzung von Gesundheitsdaten in Europa fördern soll. Sein Hauptzweck ist es, den Zugang zu Gesundheitsdaten für Bürger, Fachkräfte und Forscher zu verbessern. Bürger sollen dadurch die Kontrolle über ihre eigenen Gesundheitsdaten haben und diese einfach in der gesamten EU nutzen können. Dies erleichtert beispielsweise den Zugang zu medizinischer Versorgung bei Reisen oder Wohnsitzwechsel in andere EU-Länder. Für Gesundheitsdienstleister ermöglicht der EHDS einen schnellen und sicheren Zugriff auf relevante Patientendaten, um eine bessere Diagnose und Behandlung zu gewährleisten. Gleichzeitig soll der EHDS den Datenschutz und die Datensicherheit gewährleisten, indem er klare Regeln für den Umgang mit sensiblen Gesundheitsinformationen festlegt. Darüber hinaus fördert der EHDS die sekundäre Nutzung von Gesundheitsdaten für Forschung, Innovation und politische Entscheidungsfindung. Dies unterstützt die Entwicklung neuer Medikamente, Therapien und Gesundheitstechnologien. Ein weiteres Ziel ist die Stärkung der digitalen Gesundheitsinfrastruktur in Europa durch die Harmonisierung von Standards und Interoperabilität. Insgesamt soll der EHDS die Gesundheitssysteme effizienter machen, die Versorgungsqualität verbessern und die gesundheitliche Chancengleichheit in der EU fördern.

In Artikel 2 der EHDS-Verordnung ([EHDSVO]) werden die Begriffe „System für elektronische Gesundheitsaufzeichnungen“ oder „EHR-System“ (electronic health record system) als jedes System bezeichnet, „bei dem die Software oder eine Kombination aus Hardware und Software des Systems es ermöglicht, personenbezogene elektronische Gesundheitsdaten, die zu den durch diese Verordnung eingeführten prioritären Kategorien personenbezogener elektronischer Gesundheitsdaten gehören, zu speichern, zu vermitteln, zu exportieren, zu importieren, zu konvertieren, zu bearbeiten oder anzuzeigen und das vom Hersteller zur Verwendung durch Gesundheitsdienstleister bei der Patientenversorgung oder durch Patienten für den Zugang zu ihren elektronischen Gesundheitsdaten bestimmt ist“.

Die Mitgliedsstaaten der EU sind aufgefordert, bei der Ermöglichung des Zugangs und der Übermittlung elektronischer Gesundheitsdaten Kategorien wie etwa Patientenkurzakten, elektronische Verschreibungen und Abgaben von Arzneimitteln, Medizinische Bildgebung und damit zusammenhängende, auf Bildgebung gestützte Befunde, Ergebnisse medizinischer Untersuchungen wie Laborergebnisse und damit zusammenhängende Berichte sowie Entlassungsberichte prioritär zu betrachten.

Bezogen auf die Telematikinfrastruktur stehen diesbezüglich zuerst der E-Rezept-Fachdienst (elektronische Verschreibungen und Abgaben von Arzneimitteln, § 361 Abs. 5 SGB V) und die Aktensysteme der elektronischen Patientenakten (Patientenkurzakten, § 351 Abs. 2 Nr. 2 SGB V) im Fokus der europäischen Einbindung.

Die Anbindung an das europäische Netz erfolgt in den einzelnen Mitgliedstaaten durch die nationalen Kontaktstellen für digitale Gesundheit mittels eines NCPeH (National Contact Point for e-Health). Für den Aufbau und Betrieb des NCPeH in Deutschland ist der Spitzenverband Bund der Krankenkassen, Deutsche Verbindungsstelle Krankenversicherung – Ausland verantwortlich. Die Spezifikation des NCPeH erfolgte durch die gematik, die auch die zu erstellenden Produkt- und Sicherheitsgutachten prüft. Bei den Verarbeitungsvorgängen, an denen sie beteiligt sind, fungieren die nationalen Kontaktstellen für digitale Gesundheit als gemeinsam Verantwortliche für die übermittelten personenbezogenen elektronischen Gesundheitsdaten. Die Kommission der EU fungiert dabei als Auftragsverarbeiter.

Die folgende Abbildung zeigt als Beispiel die europäische Anbindung des E-Rezept-Fachdienstes für die Einlösung von deutschen E-Rezepten im europäischen Ausland (Land B):

Abbildung 13: Europäische Anbindung des E-Rezept-Fachdienstes

Die gematik verfolgt das Ziel, das Datenschutz- und Sicherheitsniveau der Telematikinfrastruktur auch unter den Bedingungen der europäischen Integration aufrecht zu erhalten.

Für die beiden oben genannten Anwendungen (E-Rezept, Patientenkurzakte) bedeutet dies eine freiwillige Nutzung durch in Deutschland Versicherte und das Erfordernis für die Leistungserbringer im Land B bei einem Zugriff auf Daten des Versicherten in Diensten der TI einen Zugriffscode mitzuliefern, den sie vom Versicherten erhalten haben.

Der NCPeH in Deutschland wird auf dem Niveau eines Fachdienstes der TI spezifiziert, umgesetzt, geprüft und betrieben – auch wenn er selbst nicht Teil der TI ist.

Auch in weiteren Ausbaustufen hinsichtlich der europäischen Integration wird das Datenschutz- und Sicherheitsniveau der TI beibehalten, womit auch immer das europäische Mindestniveau erfüllt wird.

5 Anhang A – Verzeichnisse

5.1 A1 – Abkürzungen

5.2 A2 – Glossar

Das Glossar wird als eigenständiges Dokument zur Verfügung gestellt.

5.3 A3 – Abbildungsverzeichnis

5.4 A4 – Tabellenverzeichnis

5.5 A5 – Referenzierte Dokumente

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellen, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

Folgende Dokumente sind gematik intern und werden nicht veröffentlicht:

Weitere Referenzierungen:

6 Anhang B – Übergreifende Ergebnisse aus der Anwendung der Methoden

In diesem Anhang finden sich Ergebnisse mit übergreifendem Charakter aus der Anwendung der von der gematik verwendeten Methoden.

6.1 B1 – Grundlegende Schutzbedarfsfeststellung

Grundlage der Schutzbedarfsfeststellung ist eine Liste von Informationsobjekten und Anwendungsprozessen einer zu betrachtenden Komponente bzw. eines zu betrachtenden Dienstes. Informationsobjekte sind Informationen mit passiven Eigenschaften, die in Anwendungsprozessen dynamisch erzeugt, verarbeitet oder gespeichert werden.

Im Folgenden wird der Schutzbedarf von grundlegenden Informationsobjekten und Anwendungsprozessen festgelegt, wie sie typischerweise in Komponenten und Diensten der TI vorkommen.

Schutzbedarf von Informationsobjekten

Tabelle 2: Schutzbedarf grundlegender Informationsobjekte

Schutzbedarf von Anwendungsprozessen

Tabelle 3: Schutzbedarf grundlegender Anwendungsprozesse

6.2 B2 – Grundlegendes Bedrohungsmodell

Gemäß BSI Grundschutz Glossar ist eine Bedrohung ein Umstand oder Ereignis, der oder das die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen beeinträchtigen kann, wodurch dem Besitzer bzw. Benutzer der Informationen ein Schaden entstehen kann.

Im Folgenden werden grundlegende Bedrohungen für die TI formuliert. Dabei werden Bedrohungen, die die Gesellschaft der Bundesrepublik Deutschland in Gänze in einem Maß bedrohen, dass bei einem von ihnen induzierten Schaden die Mehrheit der Bevölkerung nicht mehr den Erhalt der Funktionalität der TI erwartet, nicht betrachtet (z.B. kosmische Ereignisse, Auflösung der gesellschaftlichen Ordnung).

Von den verschiedenen Ursachen von Bedrohungen wird hier ausschließlich das unterlassene bzw. schädigende Handeln von Menschen betrachtet. Weitere Ursachen finden bei der Betrachtung konkreter Komponenten und Dienste der TI Beachtung.

In der folgenden Tabelle sind die für das Bedrohungsmodell der TI relevanten Einzelpersonen und Personengruppen aufgeführt.

Tabelle 4: Einzelpersonen und Personengruppen des Bedrohungsmodells

6.3 B3 – Übergreifende Bedrohungen

In diesem Kapitel werden aus dem oben entwickelten Bedrohungsmodell Bedrohungen für die TI abgeleitet und die Abhilfemaßnahmen der Sicherheitsarchitektur beschrieben.

Die Bedrohungen werden dabei nach den Phasen des Lebenszyklus der Produkte der TI gegliedert.

Bedrohungen für die Entwicklungsphase

Die folgenden Bedrohungen betreffen die Entwicklungsphase, also die Phase, in der die gematik Konzepte und Spezifikationen erstellt. Fehler im Design können dazu führen, dass Innen- oder Außentäter Schwachstellen ausnutzen, um Informationen zu löschen, zu kopieren, zu modifizieren, zur Kenntnis zu nehmen, zu offenbaren oder Profile daraus zu bilden. Weitere Bedrohungen betreffen das Verändern, Verbergen, unbefugte Ausführen oder Verhindern von Prozessen.

Tabelle 5: Bedrohungen für die Entwicklungsphase

Bedrohungen für die Herstellungsphase

Bedrohungen der Herstellungsphase entstehen durch Fehler in der der Umsetzung der Spezifikationen (z.B. durch Programmierfehler) und können dazu führen, dass Innen- oder Außentäter diese Schwachstellen ausnutzen, um Informationen zu löschen, zu kopieren, zu modifizieren, zur Kenntnis zu nehmen oder zu offenbaren sowie Profile daraus zu bilden.

Tabelle 6: Bedrohungen für die Herstellungsphase

Bedrohungen für die Zulassungsphase

Bedrohungen der Zulassungsphase entstehen durch fehlerhafte Verfahrensmodellierung, fehlerhafte Verfahrensbeschreibung bzw. fehlerhafte Verfahrensumsetzung oder unzureichende Koordination und Kooperation und können zu Schwachstellen führen, die durch Innen- oder Außentäter in der Herstellungs- bzw. Betriebsphase ausgenutzt werden, um Informationen zu löschen, zu kopieren, zu modifizieren, zur Kenntnis zu nehmen oder zu offenbaren oder Profile daraus zu bilden sowie Prozesse zu verändern, verbergen, unbefugt auszuführen oder zu verhindern.

Tabelle 7: Bedrohungen für die Zulassungsphase

Bedrohungen für die Betriebsphase

Bedrohungen der Betriebsphase entstehen durch Konfigurationsfehler, mangelnde Resistenz der Hardware, mangelnde physische Sicherheit der Umgebung, fehlerhafte Verfahrensmodellierung, fehlerhafte Verfahrensbeschreibung, fehlerhafte Verfahrensumsetzung, fehlerhafte Rollen- oder Rechtezuweisung, unzureichende Koordination und Kooperation sowie Offenheit für Social Engineering, mangelnde Kenntnis, mangelnde Sorgfalt, Fahrlässigkeit oder Fehlbarkeit und können dazu führen, dass Innen- oder Außentäter diese Schwachstellen ausnutzen, um Informationen zu löschen, zu kopieren, zu modifizieren, zur Kenntnis zu nehmen oder zu offenbaren oder Profile daraus zu bilden, Hard-/Software zu modifizieren, zu entfernen, zu zerstören, Ausfälle herbeizuführen, Außerbetriebnahmen zu veranlassen, Überlastungen zu erreichen, unberechtigte Nutzung zu ermöglichen sowie Prozesse zu verändern, zu verbergen, unbefugt auszuführen oder zu verhindern.

Tabelle 8: Bedrohungen für die Betriebsphase

6.4 B4 – Grenzen der Sicherheitsleistung

Die Grenzen der Sicherheitsleistung der TI ergeben sich aus dem gesetzlichen Rahmen in dem die gematik agiert. Die gematik kann darüber hinaus zwar nicht normativ aber zumindest unterstützend wirken. Im Endeffekt verbleibt die Verantwortlichkeit für die Gestaltung der lokalen Abläufe, Strukturen und Systeme bei den Nutzern der TI und ihren Herstellern und Anbietern.

Die folgenden Missbrauchsszenarien bestehen zwar aus einer Gesamtsicht für Anwendungen, Dienste und Komponenten, liegen aber außerhalb des Verantwortungsbereichs der gematik und damit außerhalb der Systemgrenzen der TI. Für ein normatives Wirken der gematik in diesen Bereichen müsste der gesetzliche Auftrag der gematik erweitert werden.

Bedrohungen und Schwachstellen – und damit mögliche Angriffs- bzw. Missbrauchsszenarien, die im Gesamtkontext der medizinischen Versorgung außerhalb der Systemgrenzen der TI auftreten können, müssen durch die jeweils verantwortlichen Regulierungs- bzw. Aufsichtsorgane betrachtet und ggf. abgewendet werden. Gleichwohl bieten die Komponenten und Dienste der TI hierfür in einzelnen Fällen unterstützende Leistungen an.

• Die Endgeräte des Leistungserbringers liegen nicht im Verantwortungsbereich der gematik. Die nicht normativen Anforderungen in den Implementierungsleitfäden können nur begrenzt Gefährdungen entgegenwirken, die durch eine unsichere Konfiguration oder unsachgemäße Handhabung der mobilen bzw. stationären Geräte entstehen.
• Die Einhaltung der geforderten organisatorischen Maßnahmen zum Schutz von TI-Komponenten in der Leistungserbringerumgebung liegt nicht im Verantwortungsbereich der gematik. Diese wird durch den Leistungserbringer selbst verantwortet.
• Die TI kann eine missbräuchliche Nutzung von TI-Fachdiensten aus der Umgebung des Leistungserbringers durch eine Übernahme der Kontrolle über alle dafür notwendigen Komponenten (z.B. eine Schadsoftware auf einem PVS) nicht erkennen, sofern sich Angreifer innerhalb der Verhaltensprofile von Leistungserbringern bewegen.
• Dokumenten, die Schadsoftware beinhalten, können durch Dienste der TI transportiert werden und Endgeräte eines Benutzers infizieren. Ende-zu-Ende-verschlüsselte Dokumente können nicht durch Dienste in der TI auf Schadsoftware geprüft werden.
• Dokumente, die illegale Inhalt beinhalten (Bilder, Terrorpläne usw.), können durch Dienste der TI transportiert oder gespeichert werden. Ende-zu-Ende Verschlüsselte Dokumente können nicht durch Dienste in der TI auf illegale Inhalte geprüft werden.
• Die Endgeräte des Versicherten liegen nicht im Verantwortungsbereich der gematik. Die Ausgestaltung eines FdV und der AdV können nur begrenzt Gefährdungen entgegenwirken, die durch eine unsichere Konfiguration oder unsachgemäße Handhabung der mobilen bzw. stationären Geräte entstehen.

Benutzer eines FdV werden mittels verschiedener Quellen über einen sachgemäßen Gebrauch ihrer Mobilgeräte informiert. Dennoch ist nicht auszuschließen, dass Nutzer jedwede Sicherheitsfunktion ihres Mobilgeräts deaktivieren und zudem die Möglichkeit einer lokalen Authentifizierung am FdV nicht nutzen. Für die Sicherheit der mobilen Endgeräte der Versicherten, auf denen das FdV installiert ist, sind deren Nutzer selbst verantwortlich. Gleiches gilt für die AdV und die stationären Geräte, auf denen sie läuft.

• Der Sachgemäße Umgang der Nutzer der TI mit ihren Authentisierungsmitteln liegt in der Verantwortung des jeweiligen Nutzers. Die Bandbreite des potenziell möglichen Schadens ist bei einem Missbrauch einer Identität eines Nutzers durch einen Unbefugten sehr hoch. U.U. ist nur ein einzelner Versicherter betroffen, z.B. wenn dieser seine eGK verliert oder sie ihm entwendet wird. In anderen Fällen können tausende Versicherte betroffen sein, z.B. falls eine Leistungserbringerinstitution für den Zugriff auf Patientenakten dieser Versicherten berechtigt ist und die Identität der Institution unbefugt verwendet werden kann. Sachgemäßer Umgang bedeutet, dass ein Nutzer sein Authentisierungsmittel ausschließlich mit vertrauenswürdiger Hardware und Software in dafür vorgesehenen Anwendungsfällen verwendet. Zu einem Sachgemäßen Umgang mit einem Authentisierungsmittel gehört auch die Meldung des Nutzers an den Herausgeber des Authentisierungsmittels, wenn er merkt, dass er nicht mehr die alleinige Kontrolle über sein Authentisierungsmittel hat, damit die Sperrprozesse hierfür greifen können. Mit der Etablierung von Zero Trust Mechanismen können solche Missbrauchsszenarien erschwert, aber nie ganz abgewendet werden.
• Beim Zugriff von Leistungserbringern aus dem europäischen Ausland auf Daten von deutschen Versicherten in Systemen der TI bildet der NCPeH in Deutschland in Verbindung mit den NCPeH in den europäischen Ländern die Grenze der Sicherheitsleistung der TI. Insbesondere verlassen sich die Systeme der TI auf die Information, dass ein Zugriff durch einen Leistungserbringer erfolgt, der im EU-Ausland zu einem zugriffsberechtigten Personenkreis nach den gesetzlichen Regelungen des EU-Landes gehört und dort sicher authentifiziert ist.