gemKPT_Arch_TIP_V2.10.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Konzept

Architektur der TI-Plattform

    

     

      
Version
      
2.10.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
02.03.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemKPT_Arch_TIP
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die Telematikinfrastruktur ist die gesetzlich geforderte und legitimierte Informations-, Kommunikations- und Sicherheitsinfrastruktur des deutschen Gesundheitswesens. Sie wird durch die Gesellschafter der gematik gestaltet.

Das vorliegende Architekturkonzept benennt vollständig und abschließend die Produkttypen der TI-Plattform und legt die Schnittstellen der Produkttypen auf konzeptueller Ebene fest. Hierzu werden neben den funktionalen Eigenschaften der Schnittstellen auch Schutzleistungen für Informationsobjekte und nichtfunktionale Leistungen wie die Antwortzeit festgelegt. Das vorliegende Konzept schließt damit die konzeptuelle Ebene der TI-Plattform ab und definiert die Basis für die technologische Ausprägung der Schnittstellen der Produkttypen der TI-Plattform.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI und an die Anbieter weiterer Anwendungen des Gesundheitswesens sowie der Gesundheitsforschung.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis:

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Die Architektur der TI-Plattform hat als Zielsetzung die statische Darstellung des Gesamtsystems „TI-Plattform“ zum Start des Wirkbetriebes. Sie enthält keine Vorgaben zu Aufbau, Test, Zulassungsverfahren und Betrieb dieses Systems (siehe hier [gemKPT_Test] und [gemKPT_Betr]).

Das vorliegende Dokument beschreibt als systemspezifisches Konzept ausschließlich das System TI-Plattform und grenzt sich damit gegen die Fachanwendungen ab.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen, deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke angeführten Inhalte.

2 Grundlagen der Architektur der TI-Plattform

2.1 Architekturmerkmale

2.1.1 TI-Plattform als Basis der Fachanwendungen

Die Trennung von TI-Plattform und Fachanwendungen ist als dediziertes Ziel der TI-Plattform festgelegt worden und darin die Entkopplung der Systeme TI-Plattform und Fachanwendungen gefordert. Dabei ist es unerheblich, ob es sich um eine Fachanwendung der Telematikinfrastruktur oder um eine unbekannte Fachanwendung auf den Clientsystemen handelt. Ein grundlegendes Merkmal der Architektur ist die Entkopplung der TI-Plattform von den Fachanwendungen bzgl. der folgenden Aspekte:

• Technologische Entkopplung.
• Semantische und syntaktische Entkopplung.
• Entkopplung von Fehlerzuständen.
• Eindämmung von gegenseitigen Abhängigkeiten zwischen Fachanwendung und Plattform im Bereich der Releasezyklen.
• Entkopplung von Maßnahmen zur IT-Sicherheit und zum Datenschutz.

Die Dienste der TI-Plattform stellen den Komponenten der Fachanwendungen generische Funktionalitäten zur Verfügung.

Diese Dienste werden in folgende Kategorien eingeteilt:

• Basisdienst
• Infrastrukturdienste
• Netzwerkdienste

Abbildung 1: Dienst-Kategorien der TI-Plattform

Basis-, Infrastruktur- und Netzwerkdienste werden in den Schichten der TI-Plattform zur Unterstützung der Fachanwendungen mit allen nötigen technischen und organisatorischen Anteilen bereitgestellt. Dienste können und sollen andere Dienste nachnutzen, jedoch gemäß der Schichtenlogik niemals Dienste einer darüber liegenden Schicht.

Basisdienste bieten umfassende Leistungen auf der anwendungsunterstützenden Ebene an, wie z. B. die komplette Abwicklung einer Signaturvalidierung inklusive mathematischer Prüfungen und Zertifikatsprüfung.

Infrastrukturdienste bieten generische Funktionen auf Infrastrukturebene an und sind systemnäher als Basisdienste. Sie werden häufig direkt von Basisdiensten zur Erbringung ihrer Leistungen benötigt.

Netzwerkdienste bilden die Transportschnittstelle der dezentralen Komponenten zu dem geschlossenen zentralen Netz der TI-Plattform und ermöglichen den Transport von Daten zwischen den zentralen Diensten der TI-Plattform, den fachanwendungsspezifischen Diensten und den dezentralen Komponenten der TI-Plattform. Die Netzwerkdienste können von Infrastrukturdiensten, Basisdiensten und Fachdiensten direkt genutzt werden.

Für die Beschreibung der Netzwerkkommunikation werden folgende Begriffe verwendet:

• Netzwerkschicht – entspricht der OSI-Schicht 3
• Transportschicht – entspricht der OSI-Schicht 4
• Anwendungsschicht – entspricht den OSI-Schichten 5 bis 7
• Transportnetz – entspricht der Summe der OSI-Schichten 1 bis 4 die als Netzwerkdienste der TI-Plattform den Fachanwendungen und Clientsystemen bereitgestellt werden

2.1.1.1 Schnittstelle zu den Fachanwendungen

Die TI-Plattform stellt den Fachanwendungen klar definierte Leistungen zur Verfügung: An der Schnittstelle zu den Fachanwendungen bietet die TI-Plattform Dienste an. Kapitel 5.5 und 5.6 legen für alle Dienste auf Ebene von Operationen

• die spezifischen funktionalen und nichtfunktionalen Leistungsanforderungen an die TI-Plattform,
• sowie die durch den Schnittstellennutzer zu befolgende Regeln fest.

2.1.1.2 Anwendungsneutralität

Die Architektur der TI schichtet Funktionalitäten nach klar definierten Verantwortungsbereichen, die jeweils aufeinander aufbauen. Die oberste Ebene bilden die Fachanwendungen, die sich der Funktionalitäten der von der TI-Plattform bereitgestellten darunterliegenden Schichten (Basisdienste, Infrastrukturdienste, Netzwerkdienste) bedienen.

Dabei sind die Dienste, welche die TI-Plattform den Fachanwendungen anbietet, grundsätzlich anwendungsneutral. Dieser Ansatz wirkt sich positiv auf Wirtschaftlichkeit und Produkteinführungszeit bei der Einführung neuer Anwendungen aus.

Damit sind – soweit sich die Außenschnittstelle der TI-Plattform nicht ändert – Änderungen in der TI-Plattform von Änderungen der Fachanwendungen entkoppelt.

2.1.1.3 Dienstbaukasten und Erweiterbarkeit

Die TI-Plattform bietet den Fachanwendungen die freiwillige und flexible Nutzung von Diensten an. Die Fachanwendungen werden aus folgenden Gründen konzeptionell nicht eingeschränkt:

• Die Anwendungsneutralität der Dienste ermöglicht eine klare Trennung zwischen Dienst und Fachanwendung auf Konzeptionsebene.
• Wenn das Dienstangebot der TI-Plattform für eine Fachanwendung dessen Anforderungen gar nicht oder nicht bedarfsgerecht erfüllt, kann die Fachanwendung entweder eine Erweiterung des Dienstangebots der TI-Plattform motivieren oder eine eigene Alternativlösung einsetzen.

Um die Fachanwendungen in ihrem technischen Lösungsraum nicht unnötig einzuschränken, bieten Dienste der TI-Plattform ihre technische Schnittstelle vorzugsweise über bewährte (Reife, Verbreitung und Akzeptanz) Standards an.

So entsteht insgesamt ein Dienstbaukasten, aus dem sich die Fachanwendungen nach Bedarf bedienen können.

Bei der Schnittstelle zwischen Fachmodul und TI-Plattform im Konnektor, werden Schnittstellen auf logischer Ebene festgelegt.

2.1.1.4 Sichere Übermittlungsverfahren

Die TI bietet sichere Verfahren zur Übermittlung medizinischer Dokumente über die TI nach § 291b Absatz 1e SGB V (im Folgenden sichere Übermittlungsverfahren genannt) an. Die sicheren Übermittlungsverfahren werden durch die TI technisch festgelegt und spezifiziert, um übermittelte Dokumente entsprechend dem aktuellen Stand der Technik u. a. gegen unberechtigte Zugriffe zu schützen. Die übermittelten medizinischen Dokumente selbst werden nicht durch die TI normiert.

Alle oben aufgeführten Qualitätsmerkmale der TI-Plattform in Bezug auf Fachanwendungen der Telematikinfrastruktur gelten auch in Bezug auf die sicheren Übermittlungsverfahren. Sichere Übermittlungsverfahren erhalten Zugriff auf alle Leistungen, die auch den Fachwendungen der Telematikinfrastruktur angeboten werden.

2.1.1.5 Weitere Anwendungen des Gesundheitswesens

Neben den Fachanwendungen der Telematikinfrastruktur bietet die TI-Plattform auch Leistungen für weitere Anwendungen des Gesundheitswesens an (siehe [gemRL_NvTIwA]). Alle oben aufgeführten Qualitätsmerkmale der TI-Plattform in Bezug auf Fachanwendungen der Telematikinfrastruktur gelten auch in Bezug auf die weiteren Anwendungen des Gesundheitswesens. Welche konkreten Leistungen der TI-Plattform für weitere Anwendungen des Gesundheitswesens angeboten werden, ist dem Kapitel 5.6 zu entnehmen.

Abbildung 2: Anwendungskategorien von weiteren Anwendungen

Es werden drei Anwendungskategorien von weiteren Anwendungen unterschieden:

• Andere Anwendungen des Gesundheitswesens (aAdG)
• Andere Anwendungen des Gesundheitswesens mit Zugriff auf Dienste der TI aus angeschlossenen Netzen des Gesundheitswesens (aAdG-NetG-TI)
• Andere Anwendungen des Gesundheitswesens ohne Zugriff auf Dienste der TI in angeschlossenen Netzen des Gesundheitswesens (aAdG-NetG)

2.1.2 Produkttypen, Produkte und Produktinstanzen

Produkttypen sind die kleinsten Bestandteile des Gesamtsystems TI, die als eine Einheit umgesetzt und betrieben werden können. Produkttypen mit allen ihren zugrundeliegenden Vorgaben sind auch die Grundlage für die Test- und Zulassungsverfahren. Produkttypen leiten sich durch eine Systemzerlegung der Systeme der TI – also der Fachanwendung und der TI-Plattform – ab.

Durch die Konzepte und Spezifikationen der TI werden Produkttypen vollständig durch Anforderungen definiert. Basierend auf diesen Anforderungen können konkrete Umsetzungen in Produkten erfolgen. Im Wirkbetrieb werden schließlich Instanzen bzw. Installationen von Produkten mittels Produktinstanzen ausgeprägt. Es entsteht ein hierarchisches Informationsmodell für die Telematikinfrastruktur mit drei Ebenen.

Abbildung 3: Modellierung der TI mittels Produkttypen, Produkten und Produktinstanzen

Kapitel 5 des vorliegenden Dokuments führt eine Systemzerlegung der TI-Plattform durch und leitet unter Berücksichtigung funktionaler und der genannten nichtfunktionalen Aspekte die Produkttypen her. Mit der Definition der Produkttypen und ihrer Schnittstellen sind kleinste Einheiten der Verantwortlichkeitsgrenzen für die Herstellung und Betrieb geschaffen.

Ein großer Freiheitsgrad in den Produktinstanzkardinalitäten unterstützt das Prinzip des diskriminierungsfreien Wettbewerbs:

• Die Anbindung verschiedener Instanzen von fachanwendungsspezifischen Diensten der gleichen Anwendung ist grundsätzlich möglich. Sie wird durch Ausgestaltung der Netzwerkdienste und der Dienstlokalisation unterstützt.
• Wo technisch, organisatorisch oder wirtschaftlich sinnvoll, wird die Möglichkeit von konkurrierenden Infrastrukturdiensten vorgesehen.

2.1.3 Logische Architekturschichten (Zonen)

Entlang der Architekturschichten vom Consumer zum Provider erfolgt in diesem Kapitel eine Zuordnung von Building Blocks. Die Architekturschichten sind ebenso wie die Building Blocks als logische Strukturen zu verstehen. Sie implizieren zunächst keine Trennung auf Hardwareebene. Die hier betrachteten logischen Architekturschichten werden Zonen genannt. Abbildung 4 stellt die Verteilung der Building Blocks (graue und weiße Rechtecke) auf die Zonen dar. Die Trennung nach Anwendung und TI-Plattform wird durch eine farbige Darstellung in horizontale Schichten unterstrichen. In der Schicht der Anwendungen (Secure Consumer und Provider Zone) werden Leistungen für die Nutzer der TI bereitgestellt.

Abbildung 4: Logische Architekturschichten (Zonen) und Building Blocks

Die Consumer Zone steht unter Kontrolle eines Nutzers der TI (nicht Versicherter) und enthält Komponenten des Benutzerinterfaces für fachliche Funktionalität (Clientsysteme) oder separat verteil- und installierbare Komponenten der Fachanwendung (Clientmodule). Komponenten dieser Zone haben eingeschränkten Zugriff auf die Basisdienste der TI-Plattform. Im Gegensatz dazu kann den Komponenten der Secure Consumer Zone Zugriff auf alle Basisdienste gewährt werden. Ein Clientsystem kann z. B. die Software sein, die auf dem Arbeitsplatzrechner des Arztes ausgeführt wird. Clientmodule sind als Komponente der Fachanwendung identifizierbar und sind einem konkreten fachanwendungsspezifischen Dienst zugeordnet. In ihren Berechtigungen ggü. der TI-Plattform unterscheiden sich Clientmodule nicht von Clientsystemen. Daher wird im nachfolgenden Dokument nicht an allen Stellen zwischen Clientmodulen und Clientsystemen unterschieden. Aussagen für Clientsysteme gelten auch für Clientmodule.
Die Consumer Zone steht nicht unter der Kontrolle des Versicherten. Wird dort die eGK eingesetzt, so muss die Verwendung der eGK über die Telematikinfrastruktur abgesichert werden.

Hinweis: Clientmodule sind Produkttypen von Anwendungen der TI. Festlegungen zu konkreten Produkttypen sind den Systemlösungen der entsprechenden Fachanwendungen zu entnehmen.

Die TI-Plattform ist unterteilt in eine dezentrale Zone und eine zentrale Zone. Beide Zonen sind frei von Komponenten mit fachspezifischer Logik. Diese beiden Zonen erbringen die Basisdienste sowie die Infrastruktur- und Netzwerkdienste der TI-Plattform. Darüber hinaus dienen die Zonen der Vermittlung zwischen Consumer/Secure Consumer Zone und Provider Zone.

Die TI-Plattform Zone dezentral umfasst die Komponenten der TI-Plattform, die in den Umgebungen der Nutzer der TI betrieben werden - wie z. B. Konnektoren, Kartenterminals, Smartcards aber auch Basis-/KTR-Consumer . Sie dient als Schutz der Infrastruktur vor Bedrohungen aus dem Client-Netz und umgekehrt. Diese Zone wird nachfolgend auch als dezentrale TI-Plattform bezeichnet.

Zur TI-Plattform Zone zentral gehören die zentralen Dienste der TI-Plattform, wie OCSP-Responder, Konfigurationsdienst etc., hier wird die zentrale Kommunikationsleistung der Telematikinfrastruktur erbracht. Diese Zone wird nachfolgend auch als zentrale TI-Plattform bezeichnet.

Die Provider Zone ist direkt an die zentrale TI-Plattform angebunden, ermöglicht die direkte Nutzung der zentralen Dienste, liegt fachlich aber in der Hoheit von Anwendungen. Dabei unterscheiden sich Anwendungen, die Teil der TI sind (Fachanwendungen und sicherer Übermittlungsverfahren) und deren Sicherheit, Kompatibilität und Interoperabilität durch die gematik zugesichert sind und Anwendungen, die nicht Teil der TI sind und ihre Leistungen über die TI bereitstellen (weiterer Anwendungen) wobei deren Fachlichkeit nicht betrachtet wird. Aufgrund des direkten Zugriff auf zentrale Dienste der TI-Plattform müssen durch die nutzenden Dienste der Anwendungen Vorgaben der TI-Plattform erfüllt werden, sie erfüllen die Vorgaben für eine sichere Betriebsumgebung und werden betrieblich in die TI integriert. Bietet die TI-Plattform an einem Dienst eine Leistung direkt für Nutzer der TI an, so muss diese Leistung über einen TIP-Nutzerdienst in der Provider Zone angeboten werden. Dieser kann ein abgeschlossener einzelner Dienst sein oder ein Anteil eines zentralen Dienstes, der die Leistung für den Nutzer kapselt und in der Provider Zone bereitstellt.
In der Provider Zone werden die fachliche Logik und die fachlichen Schnittstellen der fachanwendungsspezifischen Dienste und die Dienste der sicheren Übermittlungsverfahren bereitgestellt. Die fachanwendungsspezifischen Dienste bilden einen Service Layer, der die Nutzung von Bestandssystemen ermöglicht. Auf die gesicherten fachanwendungsspezifischen Dienste kann nur von Fachmodulen und von fachanwendungsspezifischen Diensten nach Freischaltung zugegriffen werden.

Die fachanwendungsspezifischen Dienste der Versicherten sind auch nur von Fachmodulen erreichbar. Sie stellen zusätzlich Leistungen für die Versicherten in dessen Umgebung bereit und übernehmen dadurch einige Pflichten der TI-Plattform in Bezug auf die Absicherung der TI an diesem Zonenübergang.

Auch Dienste von weiteren Anwendungen des Gesundheitswesens mit Zugriff auf zentrale Dienste der TI-Plattform (aAdG und aAdG-NetG-TI, siehe auch [gemRL_NvTIwA]) stehen in der Provider Zone, sind aber nicht Teil der Telematikinfrastruktur.

Die Dienst-zu-Dienst-Kommunikation zwischen fachanwendungsspezifischen Diensten, den Diensten der sicheren Übermittlungsverfahren bzw. zwischen weiteren Anwendungen des Gesundheitswesens in der Provider Zone über das zentrale Netz muss für jede Verbindung explizit freigeschaltet werden.

Hinweis: Für die Fachanwendung VSDM sind nur die Schnittstellen ihrer Fachdienste Teil der TI und in der Provider Zone angesiedelt (für nähere Informationen siehe [gemSysL_VSDM]).

Die Existing Application Zone umfasst die Bestandssysteme der Fachanwendungen. Auch Netze des Gesundheitswesens mit weiteren Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste sind hier eingeordnet.

Die Personal Zone repräsentiert die Umgebung des Versicherten unter dessen Kontrolle. Die dort verorteten verschiedenen Frontends der Versicherten der einzelnen Fachanwendungen werden über die fachanwendungsspezifischen Dienste der Versicherten an die TI angebunden. Die Frontends der Versicherten laufen auf Geräten der Versicherten in der Personal Zone. Da die Personal Zone unter der Kontrolle des Versicherten steht, kann dort dessen eGK ohne gesonderte Sicherungsmechanismen der TI-Plattform eingesetzt werden. Diese Umgebungsannahme wird durch die Fachanwendungen in der Gestaltung ihrer Lösungsarchitektur berücksichtigt.

Normalerweise ist ein Produkttyp genau einem Building Block der Architektur zugeordnet. Im dezentralen Bereich gibt es aber die Möglichkeit eines Rechenzentrum-Consumers, der Elemente der Zonen TI-Plattform dezentral, Consumer und ggf. auch Secure Consumer in einem Produkttyp vereint. Auch in so einem Fall werden alle Annahmen an die einzelnen Zonen, die Regelungshoheit für die Zone und die Anforderungen an die Übergänge zwischen den Zonen innerhalb des Produkttyps umgesetzt.

2.1.4 Kontrolle der Kommunikationswege

Die grundsätzlich erlaubten Möglichkeiten zwischen den Zonen eine Verbindung zu initiieren sind in Tabelle 1 definiert. Die Regelungshoheit der TI-Plattform beschränkt sich auf die Kommunikationsmöglichkeiten zwischen oder mit Produkttypen (Zonen SC, TI_D, TI_Z und P).

Tabelle 1: Kommunikationsmatrix TI (Zonen)

^{1) Die Kommunikation innerhalb der Consumer Zone unterliegt nicht der Regelungshoheit der Telematikinfrastruktur.
2) Nur offene fachanwendungsspezifische Dienste und TIP-Nutzerdienste sind aus der Consumer Zone erreichbar.
3) Diese Kommunikation beschränkt sich auf die Anbindung von Netzen des Gesundheitswesens mit weiteren Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste (aAdG-NetG)und den sicheren Internetzugang.
4) Diese Kommunikation ist nur erlaubt, wenn nach dem Publish-Subscribe Pattern zuvor eine Registrierung vorgenommen wurde.
5) Die Kommunikation zwischen Fachmodulen erfolgt nur, wenn die beteiligten Fachanwendungen diese vorgesehen haben.
6) Diese Kommunikation ist nur für das Service Monitoring erlaubt.
7) Diese Kommunikation darf nicht aus einem Netz des Gesundheitswesens mit weiteren Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste (aAdG-NetG)erfolgen.
8) Diese Kommunikation kann nur in Richtung eines fachanwendungsspezifischen Dienstes der Versicherten oder eines TIP-Nutzerdienstes erfolgen
9) Diese Kommunikation ist nur für Probes des Service Monitorings auf vom Anbieter benannte Dienste in Netzen mit aAdG-NetG erlaubt, um die prinzipielle Erreichbarkeit des Netzes zu prüfen.}

Die in diesem Rahmen zwischen Produkttypen erlaubten Kommunikationswege definiert Kapitel 7.2. Pro Operation wird festgelegt, welcher Produkttyp als Aufrufer erlaubt ist.

In der TI-Plattform zentral ist die Kommunikation in Richtung aller zugelassenen Dienste und angeschlossenen weiteren Anwendungen im Rahmen des Test-, Bestätigungs- und Zulassungsverfahrens freizuschalten. Im dezentralen Bereich ist die Kommunikation zu Pflichtanwendungen gemäß §291a SGB V [SGB V] immer erlaubt. Die Kommunikation in Richtung aller Netze des Gesundheitswesens mit anderen Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste (aAdG-NetG) ist grundsätzlich freigeschaltet, kann durch den Administrator aber für jedes einzelne Netz explizit unterbunden werden. Dabei wird immer das Netz als Ganzes und nicht einzelne Dienste im Netz freigeschaltet.

Die fachanwendungsspezifischen Dienste der Versicherten stellen Leistungen für Versicherte in dessen Umgebung über das Internet bereit. Ggf. betrifft dies auch die Weiterleitung der Leistungen zentraler Dienste. Daher müssen durch diese Dienste bestimmte Rahmenbedingungen eingehalten werden.

2.2 Betrieb und Wartung (Operation and Maintenance)

Die übergreifenden betrieblichen Anforderungen an die Architektur der TI-Plattform und Fachdienste werden großteils in der übergreifenden Spezifikation Operation and Maintenance [gemSpec_OM] aufgegriffen und umgesetzt.

Damit Informationen zum aktuellen Betriebszustand der TI hinsichtlich ihrer Verfügbarkeit und der Einhaltung definierter Antwortzeiten auf Dienstebene an einer zentralen Stelle zusammengefasst und angezeigt werden können, führt die Architektur der TI-Plattform den Infrastrukturdienst „Monitoring Betriebszustand“ ein und setzt ihn durch den Produkttypen „Störungsampel“ bzw. „Service Monitoring" um.

2.3 Bedarfsgerechte Leistungsfähigkeit (Performance)

Das vorliegende Dokument beinhaltet nicht das Performancemodell der TI-Plattform. Das Performancemodell wird unter Berücksichtigung der konzeptionellen Architektur auf Ebene der übergreifenden Spezifikationen festgelegt und weist die Leistungsparameter

• Antwortzeit je Einzelanfrage,
• Anfragerate je Einzelanfrage und
• Verfügbarkeit je Produkttyp

aus.

2.4 Sicherheitsleistung der TI-Plattform

2.4.1 Abgrenzung zwischen TI-Plattform und Fachanwendung

Für die Ende-zu-Ende-Sicherheit einer Fachanwendung ist ausschließlich die Fachanwendung selber verantwortlich. Die TI-Plattform stellt den Fachanwendungen ihre Funktionen mit definierten Sicherheitsniveaus zur Verfügung. Die korrekte Verwendung dieser Funktionen sowie die Kombination der Funktionen und die Ergänzung um Eigenleistungen zur Erreichung der seitens der Fachanwendungen benötigten Gesamtsicherheit obliegen der Fachanwendung.

Damit die Fachanwendungen dieses Prinzip erfolgreich anwenden können, benötigen Sie Angaben, welche maximalen Schutzbedarfe die Funktionen der TI-Plattform hinsichtlich Vertraulichkeit, Integrität und Authentizität verarbeiten können. Die jeweils durch die TI-Plattform garantierten maximalen Schutzbedarfe der transportierten und verarbeiteten Informationsobjekte werden für jeden Parameter einer jeden Operation ausgewiesen (siehe Kapitel 5.5 und 5.6). Die Fachanwendungen dürfen sich darauf verlassen, dass die TI-Plattform alle erforderlichen Maßnahmen einleiten wird, damit die garantierten Höhen der verarbeitbaren Schutzbedarfe erreicht werden.

Die TI-Plattform unterscheidet in der Bewertung und Verarbeitung zwei Klassen von Daten:

1. Daten der Fachanwendungen
2. Daten der TI-Plattform

Hinsichtlich der Daten der Fachanwendungen gilt, dass die TI-Plattform zu keinem Zeitpunkt Kenntnis über die Semantik der Fachdaten besitzt. Ob es sich im Einzelfall der seitens einer Fachanwendung an die TI-Plattform übergebenen Daten um Daten mit Personenbezug oder mit medizinischem Inhalt handelt, kann die TI-Plattform nicht erkennen. Die TI-Plattformoperationen weisen immer das von ihnen maximal bearbeitbare Sicherheitsniveau aus. Es obliegt der Fachanwendung in ihren Sicherheitskonzepten zu prüfen, welche konkreten Schutzbedarfe ihre Daten haben, die sie an die Schnittstellen der TI-Plattform übergibt bzw. von ihr erhält. Ferner wird die TI-Plattform Daten der Fachanwendungen nur für die von der Fachanwendung vorgegebene, notwendige Dauer des Transports oder die von der Fachanwendung angeforderte Bearbeitung in der TI-Plattform halten. Dies gilt auch für Fachdaten, die auf der eGK oder dem mobilen Kartenterminal gespeichert werden. Die Ordner der eGK bzw. die Speicherbereiche des mobilen Kartenterminals, in denen diese Daten abgelegt werden, gelten als Speicherort der Fachanwendungen.

Hinsichtlich der Daten der TI-Plattform gilt, dass die Fachanwendungen bezüglich intern bewegter Plattformdaten keine Sicherheitsbetrachtungen durchführen müssen. Die TI-Plattform garantiert, dass alle in ihr intern bewegten Daten ihren Schutzbedarfen entsprechend ver- und bearbeitet werden.

Eine Verantwortung der Fachanwendung für Daten der TI-Plattform ergibt sich dann, wenn Daten der TI-Plattform an die Fachanwendungen weitergereicht werden. In diesem Fall übernimmt die Fachanwendung die Verantwortung für die sicherheitsgemäße Verarbeitung der entgegengenommenen Plattformdaten. Diese Daten sind im Rahmen der Sicherheitsanalyse der Fachanwendungen zu berücksichtigen. Beispiele hierfür sind Statusmeldungen der TI-Plattform an die Fachanwendung oder Ressourcenidentifikatoren mit erhöhtem Schutzbedarf.

2.4.2 Sicherheitsleistung der Produkttypen

Der in der TI-Plattform verfolgte grundsätzliche Ansatz zur Sicherung schutzbedürftiger Daten basiert auf dem Prinzip der Kapselung. Daten, die an eine Einheit übergeben werden, werden von dieser Einheit vertrauenswürdig verarbeitet. Diesem Prinzip folgend wird als Grundanforderung an jeden Produkttyp aufgenommen, dass Daten, die der Produkttyp über seine Außenschnittstellen erhalten hat oder die im Produkttyp erzeugt wurden, hinsichtlich Vertraulichkeit, Integrität und Authentizität zu schützen sind. Der Produkttyp wird in diesem Fall als Blackbox betrachtet, die grundsätzlich alle Daten in ihr vor einem unberechtigten Zugriff von außen bis zu einer maximale Höhe schützt – unabhängig vom konkreten Schutzbedarf der einzelnen Daten. Die von einem Produkttyp zu erreichende Höhe der maximal verarbeitbaren Schutzbedarfe wird je Operation am Produkttyp ausgewiesen.

2.5 Rollen der TI-Plattform

2.5.1 Personenkreise der Telematikinfrastruktur

In §291a SGB V [SGB V] wird der zugriffsberechtigte Personenkreis für die Nutzung von §291a-Fachanwendungen abschließend festgelegt. Die TI-Plattform muss bei der Erbringung der Plattformleistungen diesen zugriffsberechtigte Personenkreis durch ein geeignetes Rollenmodell unterstützen. Tabelle 2 enthält den im Kontext der eGK beteiligten Personenkreis des §291a SGB V [SGB V].

Tabelle 2: Zugriffsberechtigter Personenkreis (PK) nach §291a SGB V

Über die in §291a SGB V [SGB V] genannten Personenkreise hinaus, gibt es noch weitere Personenkreise, die nicht zur Nutzung von §291a-Fachanwendungen berechtigt sind, aber die Telematikinfrastruktur nutzen oder mit ihr interagieren. Diese Personenkreise werden benannt, um die nachfolgend festgelegten Rollen den jeweiligen Personenkreisen zuordnen zu können und damit deren Verhältnis zum §291a SGB V darzustellen. Tabelle 3 benennt diese Personenkreise.

Tabelle 3: Personenkreis ohne Zugriffsberechtigung nach §291a SGB V

2.5.2 Rollen

In der Konzeption der Architektur der TI-Plattform werden die nachfolgend genannten fachlichen, betrieblichen und technischen Rollen verwendet.

Die fachlichen und betrieblichen Rollen werden auf den zugriffsberechtigten Personenkreis nach § 291a SGB V gemäß der folgenden Tabelle abgebildet. Eine Abbildung der technischen Rollen erfolgt nicht, da der zugriffsberechtigten Personenkreis nach § 291a SGB V sich auf Berechtigungen von Personen bzw. Personengruppen bezieht und unabhängig von einer technischen Umsetzung formuliert ist.

Die dargestellten Rollen können auf Ebene der Spezifikationen ergänzt und verfeinert werden.

Tabelle 4: Fachliche Rollen

Die fachliche Rolle „Leistungserbringer“ wird für die Schnittstellen zu den Fachanwendungen bereits auf Ebene der Konzeption in einer feineren Untergliederung benötigt.

Tabelle 5: Tab_ArchTIP_002 Rollenmodell in der Außensicht der TI-Plattform

Tabelle 6: Betriebliche Rollen

Tabelle 7: Technische Rollen

3 Leistungen der TI-Plattform in der Außensicht

3.1 Qualifizierte elektronische Signatur

Eine qualifizierte elektronische Signatur gemäß [eIDAS] ist ein verlässliches Mittel um eine juristische Willenserklärung in elektronischer Form abzugeben oder andere rechtlich verbindliche Vorgänge abzusichern und so eine Rechtsicherheit (hier insbesondere Beweissicherheit) herzustellen. Die TI-Plattform bietet Leistungserbringern die Möglichkeit eine QES in ihre fachlichen Prozesse zu integrieren und so den Aufwand aufgrund papiergestützter Verfahren zu mindern. Die TI-Plattform unterstützt in diesem Zusammenhang auch die QES Stapelsignatur (gemäß TR-03114).

Eine detaillierte Beschreibung der angebotenen Leistung (insbesondere unterstützte Dokumentenformate und Policies) ist im Kapitel 5.5.1.3 zu finden.

3.2 Einfache digitale elektronische Signatur

In vielen fachlichen Abläufen ist der Nachweis der Integrität und Authentizität der zu verarbeitenden Daten unerlässlich. Die TI-Plattform unterstützt dies durch das Angebot einfache digitale elektronische Signaturen über Daten zu erstellen und zu prüfen.

Eine detaillierte Beschreibung der in diesem Zusammenhang durch die TI-Plattform angebotenen Leistung ist dem Kapitel 5.5.1.2 zu entnehmen.

3.3 Ver- und Entschlüsselung

Um die Vertraulichkeit fachlicher Daten zu gewährleisten, bietet die TI-Plattform an, diese zu verschlüsseln und an berechtigter Stelle wieder zu entschlüsseln. Dies ist besonders im Bereich von persönlichen medizinischen Daten in der Fachlichkeit unumgänglich.

Eine detaillierte Beschreibung der in diesem Zusammenhang durch die TI-Plattform angebotenen Leistung ist dem Kapitel 5.5.1.11 zu entnehmen.

3.4 Public Key Infrastructure (PKI)

Die vorhergehend beschriebenen Leistungen der TI-Plattform sind technisch nur umsetzbar, wenn eine Public Key Infrastructure besteht, auf welche die Dienste aufsetzen können. Die TI-Plattform bietet eine PKI an, welche die Bedürfnisse aller angebotenen Dienste abdeckt.

3.5 Tokenbasierte Benutzerauthentisierung

Die tokenbasierte Benutzerauthentisierung basiert auf WS-Trust und WS-Federation um eine flexible Integration von Identity Providern (IDP) bzw. Security Token Services (STS) zu ermöglichen. Die TI-Plattform stellt Funktionen zur Verfügung, um Benutzer als Mitarbeiter einer Leistungserbringerinstitution zu authentisieren. Dabei handelt es sich um eine Transformation von Zertifikatsdaten der SMC-B in eine entsprechende Identitätsbestätigung, ohne dass in diesem Zusammenhang eine Authentifizierung des Benutzers durch die TI-Plattform erfolgt.

Es ist eine Authentisierung als Mitarbeiter der Leistungserbringerinstitutionen direkt über eine SMC-B möglich oder ein lokaler Identity Provider (IDP) kann die Authentisierung durch eine SMC-B bestätigen lassen. Für die inhaltliche Korrektheit der Authentisierung des lokalen IDP ist allein der lokale IDP verantwortlich.

Hinweis: Ein Identity Provider (IDP) ist ein Dienst gemäß WS-Trust bzw. WS-Federation, der Identitätsinformationen nach direkter Authentifizierung eines Nutzers erstellt, pflegt und verwaltet oder den Nutzer auf Basis der Identitätsinformation eines anderen IDPs authentifiziert.

Die Tokenbasierte Benutzerauthentisierung der TI-Plattform stellt eine Unterstützungsleistung dar, durch die Identitätsbestätigungen gemäß WS-Trust und WS-Federation erzeugt werden können. Der Dienst umfasst keine Prüfung ob der Nutzer be-rechtigt ist und verifiziert nicht die Inhalte der Identitätsbestätigung. Die Aussagekraft der Identitätsbestätigung ist direkt abhängig davon, wie der Zugang zu den Komponenten der TI geregelt ist und dass die Komponenten der TI nicht unberechtigt verwendet werden können.

3.6 Smartcards des Gesundheitswesens

Der Nutzen einer PKI hängt maßgeblich davon ab, dass die Gewissheit besteht, dass private Schlüssel sicher gespeichert und sich unter alleiniger Kontrolle des Schlüsselinhabers befinden. Um dies mit der Anforderung nach einem orts-ungebundenen Einsatz des Schlüsselmaterials zu verbinden, speichert die TI-Plattform Schlüsselmaterial auf HBAs, eGKs und Security Module Cards (nachfolgend auch oft als „SMC“ oder „Karten“ referenziert). Diese stehen unter Aufsicht des jeweiligen Inhabers und stellen sicher, dass gespeichertes Schlüsselmaterial nicht exponiert wird.

Die eGK kann im gewissen Umfang zusätzlich als sicherer Speicherort für Fachdaten verwendet werden.

Der Zugriffsschutz für Fachdaten und Schlüsselmaterial wird durch die Security Module Card sichergestellt. Um den Zugriff freizuschalten ist je nach Informationsobjekt eine PIN-Eingabe oder eine Card-to-Card-Authentifizierung notwendig.

3.7 Anbindung an das geschlossene Netzwerk der TI

Die TI-Plattform stellt ein geschlossenes Netz für die bekannten Akteure des deutschen Gesundheitswesens zur Verfügung. An dieses können sich Leistungserbringer, Kostenträger oder fachanwendungsspezifische Dienste der Fachanwendungen der Telematikinfrastruktur unter Verwendung der entsprechenden Komponenten der TI-Plattform anbinden und über dieses Netz miteinander kommunizieren.

3.8 Zugang zu weiteren Anwendungen des Gesundheitswesen

Neben der Telematikinfrastruktur existieren im deutschen Gesundheitswesen verschiedene weitere Anwendungen des Gesundheitswesens (teils in Netzen des Gesundheitswesens), die Leistungserbringern Anwendungen bereitstellen. Die TI-Plattform ermöglicht es Leistungserbringern, die angeschlossenen weiteren Anwendungen des Gesundheitswesens über die TI-Plattform erreichen und nutzen zu können.

3.9 Sicherer Internetzugang

Neben dem sicheren Zugang in die Telematikinfrastruktur bietet die TI-Plattform Clientsystemen die Möglichkeit, über einen sicheren Internetzugang in das Internet zu gelangen. Der sichere Internetzugang wird zur optionalen Nutzung durch den VPN-Zugangsdienst bereitgestellt.

3.10 Außensicht der TI-Plattform im Ganzen

Nachfolgend wird die Außensicht der TI-Plattform in der Gesamtheit über alle Dienste dargestellt. Dabei ist der Darstellung zu entnehmen, für welche Nutzer die konkreten Dienste an den entsprechenden Schnittstellen bereitgestellt werden.

• Blau stellt Dienste dar, die ausschließlich Fachanwendungen der TI, sichere Übermittlungsverfahren und teils auch weiteren Anwendungen des Gesundheitswesens mit Zugriff auf zentrale Dienste zugänglich sind.
• Grün stellt Dienste dar, die sowohl Fachanwendungen der TI als auch Fachanwendungen auf Clientsystemen oder Clientmodulen zugänglich sind.
• Weiße Schnittstellen dienen administrativen Vorgängen. Das vorliegende Dokument weist nur administrative Schnittstellen aus, die für die konzeptionelle Erbringung einer  funktionalen Leistung erforderlich sind. Weitere administrative Schnittstellen werden im Einklang mit der Konzeption des Betriebs auf Ebene der Spezifikationen der Produkttypen festgelegt.

Die detaillierte Beschreibung der verschiedenen Dienste ist den Kapiteln 5.5 und 5.6 zu entnehmen.

Abbildung 5: Außensicht der TI-Plattform

Hinweis: Weiteren Anwendungen des Gesundheitswesens mit Zugriff auf zentrale Dienste stehen alle Schnittstellen „Zentral“ bis auf die nachfolgend genannten zur Verfügung:

I_Directory_Application_Maintenance, P_Directory_Application_Registration, P_Directory_Maintenance, I_Directory_Maintenance, P_DNS_Zone_Delegation, P_CVC_Provisioning, P_Sub_CA_Certification_CVC, P_Sub_CA_Certification_X.509, I_Monitoring_Update, I_TLS, I_Remote_Sign_Operations, I_Key_Provisioning .

4 Lösungen der Architektur der TI-Plattform

4.1 Einsatz von Smartcards in der TI

In der TI werden Smartcards einerseits zur Realisierung eines mobilen Identitäts-managements und andererseits als sicherer Speicher zum Transport von versicherten-bezogenen Daten verwendet. Sie speichern kryptographisches Schlüsselmaterial für Personen, Institutionen sowie Geräte des Gesundheitswesens und identifizieren diese zuverlässig. Weiterhin können auf Smartcards Daten von Anwendungen der TI gespeichert werden, was nur die elektronische Gesundheitskarte (eGK) betrifft. Technologiebedingt sind Smartcards nur bedingt als Datenspeicher geeignet. Daher beschränkt sich die Speicherung auf der eGK auf solche Daten, wo dies gesetzlich vorgesehen ist oder für die ein Konsens der Gesellschafter der gematik vorliegt.

So dient die eGK dem Versicherten als mobiles Identifikations- und, im Rahmen der gesetzlichen Vorgaben oder der Konsensentscheidungen der Gesellschafter der gematik, Speichermedium, um sich bei einem Arztbesuch in der Praxis des Leistungserbringers eindeutig zu authentisieren und, basierend darauf - i.V.m. der eindeutigen Authentisierung des Arztes (HBA) - diesem Zugriff auf bestimmte Daten zu gewähren.

Der HBA bietet dem Leistungserbringer (LE) innerhalb seiner LE-Umgebung an verschiedenen Arbeitsplätzen oder ggf. umgebungsübergreifend, wenn der LE in verschiedenen LE-Umgebungen tätig ist, die Möglichkeit, sich in seiner Rolle als Arzt und als Person gegenüber Dritten auszuweisen. Anhand der SMC-B übergibt die Leistungserbringerorganisation der Leistungserbringerinstitution eine Identität, die deren sektorspezifische Kassenzulassung bestätigt.

Konnektoren und Kartenterminals werden als dezentrale Komponenten identitätslos produziert und erhalten erst über gSMC-K und gSMC-KT eine eindeutige und bestätigte Identität innerhalb der TI. gSMC-K und gSMC-KT werden nur in zugelassenen Komponenten installiert, wodurch sich alle Kommunikationspartner sicher sein können, mit zugelassenen Komponenten zu interagieren.

In der TI werden Smartcards in den folgenden Ausprägungen (Produkttypen) eingesetzt:

Tabelle 8: Smartcards in der TI

Im Folgenden wird der Begriff „Karte“ synonym genutzt zu „Smartcard zur Nutzung innerhalb der TI, die einem der Produkttypen eGK, HBA, SMC-B, gSMC-K, gSMC-KT zugeordnet ist“.

Die nachfolgenden Kapitel definieren den übergreifenden Rahmen für die Karten der TI. Hier werden die übergreifenden Leistungen der Karten durch COS und Objektsystem definiert. Welche Leistung in welcher konkreten Karte oder durch eine Fachanwendung genutzt wird, ist der Produkttypbeschreibung in Kapitel 5.3 oder der entsprechenden Spezifikation der Fachanwendung zu entnehmen.

4.1.1 Domänen- / Informationsmodell der Karten der TI

Das Domänenmodell beschreibt konzeptionell den Lösungsbereich des Einsatzes von Karten in der TI-Plattform. Technische Details werden zu Informations- bzw. Domänenklassen zusammengefasst. Es werden folgenden Sub-Domänen definiert:

• Identität,
• Daten,
• Autorisierung und Kartenadministration (Zugriffsregeln).

Abbildung 6: Domänenmodell Karten der TI

Hinweis: Die Notation der Abbildung entspricht den Fundamental Modeling Concepts (FMC, www.fmc-modeling.org).

4.1.1.1 Identitätsträger

Unter einer Identität im Kontext der Domäne „Karten der TI“ ist immer eine kryptogra-phische Identität, bestehend aus einem privaten Schlüssel und dem dazugehörigen Zertifikat, zu verstehen. Hierzu werden eindeutige Identifikationsmerkmale der realen Identitäten an eindeutige technische Identifikationsmerkmale über Endnutzerzertifikate gekoppelt. Diese kryptographischen Identitäten werden zum Zweck der Erstellung und Prüfung von Signaturen, Authentisierung und zur Ver- und Entschlüsselung von Daten verwendet, wobei geheimes Schlüsselmaterial die Smartcard nie verlässt, weil die kryptographischen Operationen innerhalb der Smartcard ausgeführt werden. Der Mechanismus der Authentisierung ist Grundlage der Autorisierung des Zugriffs auf Fachdaten.

Eine Smartcard speichert eine oder mehrere Identitäten pro Verwendungszweck für Personen, Institutionen oder Geräte der TI (vgl. Anhang B).

Zur Erfüllung des Einsatzzwecks der jeweiligen Identität muss die Smartcard die nötigen kryptographischen Operationen anbieten.

4.1.1.2 Sicherer Datenspeicher

Smartcards sind eingeschränkt auch als sicherer Datenspeicher einsetzbar. Die Speicherung von Daten auf der eGK beschränkt sich auf solche Daten, wo dies gesetzlich vorgesehen ist oder für die ein Konsens der Gesellschafter der gematik vorliegt. Diese Daten sind somit ohne weitergehende Schutzmaßnahmen transportabel und können am jeweiligen Bestimmungsort, bspw. eines authentisierten Leistungserbringers, durch Erfüllung zugeordneter Zugriffsregeln, zur Verwendung freigegeben werden.

Dieses Leistungsmerkmal wird nur im Produkttyp eGK verwendet.

Datenobjekte können strukturiert und hierarchisch organisiert, analog zu einem PC-Dateisystem, auf Smartcards gespeichert werden. Dazu bieten Smartcards Ordner an, die bzgl. des Inhalts und der Struktur der gespeicherten Datenobjekte unter Hoheit der TI-Plattform oder einer zugeordneten Fachanwendung stehen. Der Ordner einer Fachanwendung wird nachfolgend „fachanwendungsspezifische Karten-Applikationen“ genannt. In der TI werden fachanwendungsspezifische Karten-Applikationen nur auf dem Produkttyp eGK umgesetzt.

Bestimmte Umstände können es erforderlich machen, eine fachanwendungsspezifische Karten-Applikation aus datenschutzrechtlichen Gründen zu verbergen. Die betroffene fachanwendungsspezifische Karten-Applikation wird dazu auf der eGK deaktiviert. Eine deaktivierte fachanwendungsspezifische Karten-Applikation kann zu einem späteren Zeitpunkt wieder aktiviert und dadurch sichtbar gemacht werden.

4.1.1.3 Autorisierung und Kartenadministration (Zugriffsregeln)

Vorrangiges Ziel einer Karte ist es, die auf ihr gespeicherten Kartenobjekte vor unberechtigtem Zugriff zu schützen. Daher ist für jedes Kartenobjekt festzulegen, unter welchen Bedingungen welche Identität mit welcher Operation auf dieses Kartenobjekt zugreifen darf. Der Zugriffsschutz erfordert zwei Schritte:

1. Authentifizierung des Zugreifenden und
2. Autorisierung des Zugriffs auf Basis von Zugriffsregeln.

Für die Authentifizierung werden durch die Karten folgende Mechanismen unterstützt.

Die Authentifizierung auf Basis von CV-Zertifikaten (C2C, C2S) erfordert die Prüfung der Zertifikatskette. Dafür sind auf der prüfenden Karte öffentliche Schlüssel akzeptierter Wurzel-Zertifizierungsstellen (Vertrauensanker der CVC-Hierarchie) vorhanden. Es können ausschließlich CV-Zertifikate erfolgreich authentifiziert werden, die auf einen dieser Vertrauensanker zurückführbar sind. Unterschieden wird zwischen dem CV-Vertrauensanker der TI-Plattform (CVC-Root) und eventuell existierende CV-Vertrauensanker als Basis der asymmetrischen Authentifizierung bei der Kartenadministration (Administrations-Root).

Die notwendigen Zugriffsberechtigungen für Operationen (vgl. Kap. 4.1.3) mit Datenobjekten der Karten werden über Zugriffsregeln formuliert. Diese sind auf den Karten an den entsprechenden Datenobjekten zugeordnet und durch die Karte nach erfolgreicher Authentifizierung durchgesetzt werden. Sie definieren unter welchen Bedingungen und nach welchen erfolgreichen Authentifizierungen auf Datenobjekte zugegriffen werden kann.

CV-Zertifikate tragen neben dem öffentlichen Schlüssel einer Identität auch Informationen zur Rolle der Identität oder feingranulare Berechtigungsinformationen für Zugriffe auf Datenobjekte. Die prüfende Karte autorisiert Zugriffe auf ihre Karten-Objekte nur unter Beachtung der Berechtigungsinformationen der CV-Zertifikate.

4.1.1.4 PINs

Da die PIN das persönliche Geheimnis des Karteninhabers oder eines Berechtigten im Besitz der Karte darstellt, muss diese durch ihn, bzw. den Berechtigten bestimmbar/änderbar sein.

Zur Verbesserung der Benutzbarkeit soll die Karte die Möglichkeit bieten, eine zentrale PIN für viele Applikationen zu nutzen. Die Entscheidung ob eine konkrete PIN als Referenz auf die zentrale PIN (Multireferenz-PIN) oder als normale PIN mit eigenem Geheimnis ausgeprägt wird, obliegt der Fachanwendung und der anwendungstechnischen Notwendigkeit der Abgrenzung zu weiteren, auf der Karte gespeicherten Anwendungen. Im Allgemeinen wird die Ausprägung als Multireferenz-PIN gewählt, um dem Kartenbesitzer das Wissen um viele verschiedene PINs zu ersparen. Jede PIN hat einen eigenen Verifikationsstatus unabhängig davon, ob sie als normale PIN oder als Multireferenz-PIN ausgeprägt ist.

4.1.2 Objekttypen der Karten

Die Karte setzt die oben genannten Elemente der Sub-Domänen in Form von Karten-Objekten, wie in Tabelle 9: Karten-Objekttypen und Domänen-Mapping aufgeführt, um.

Tabelle 9: Karten-Objekttypen und Domänen-Mapping

4.1.3 Operationen auf Objekte der Karten

Die oben beschriebenen Funktionalitäten auf gespeicherte Objekte bieten die Karten über die in Tabelle 10 genannten, fachlichen Schnittstellen und Operationen an.

Die in Tabelle 10 genannten, logischen Schnittstellen decken den Funktionsumfang der benötigten Kartenoperationen zur Speicherung von (Fach-)Daten, Authentisierung, Ver-/Entschlüsselung und Signatur ab und werden nachfolgend im Dokument unter der logischen Schnittstelle I_Smartcard_Operations subsummiert.

Kartenzugriffe in der TI werden vom Konnektor gekapselt. Die vom Konnektor innerhalb der TI gekapselten Operationen sind über die folgenden logischen Schnittstellen erreichbar:

Tabelle 11: Mapping logische Smartcard- zu Konnektor-Schnittstellen

Die in Tabelle 11 dargestellten Operationen des Konnektors entsprechen funktional den Operationen der angegebenen logischen Kartenschnittstelle. Daher werden diese an den Karten-Interfaces nachfolgend nicht mehr einzeln beschrieben.

4.2 Zugriff auf Karten

Bei personen- und organisations-/institutionsbezogenen Karten wird ein Mechanismus umgesetzt, der es dem Karteninhaber ermöglicht, seine Karte (sprich, die über die Karte erreichbaren Funktionen) unter seiner Kontrolle zu behalten.

Da sich im Zuge von Karteninteraktionen der Sicherheitszustand der Karte über eine PIN-Eingabe oder eine Card-to-Card-Freischaltung ändern kann, muss sichergestellt sein, dass nachfolgend nur berechtigte Anwender diesen erhöhten Sicherheitszustand der Karte nutzen können. Welche Anwender berechtigt sind, hängt vom Kartentyp ab. Bei organisations-/institutionsbezogenen Karten dürfen alle berechtigten Mitarbeiter der Organisation/Institution, mit der die Karte assoziiert ist, die erreichten Sicherheitszustände dieser Karte nutzen. Der Sicherheitszustand des HBA ist an die Person gebunden, die sich authentisiert hat. Für die eGK gilt das Zwei-Karten-Prinzip. Ein erreichter Sicherheitszustand darf nur im Zusammenhang mit der organisations-/institutions- oder personenbezogenen Karte genutzt werden, die die eGK freigeschaltet hat. Die Freischaltung einer eGK durch PIN.home ist ebenfalls möglich, aber da Umgebungen, die nicht Bestandteil der dezentralen TI–Plattform sind, in diesem Dokument nicht betrachtet werden, werden hierzu keine konzeptionellen Aussagen getroffen.

Der Konnektor benötigt daher zuverlässige Informationen über den Aufrufkontext, in dem eine Kartenoperation ausgeführt werden soll. Der Aufrufkontext besteht aus personenbezogenen und systembezogenen Informationsanteilen. Um die Mandantenfähigkeit des Konnektors zu gewährleisten, muss der Aufrufkontext auch den Mandantenbezug enthalten.

Dezentralen Ressourcen der TI-Plattform (z. B. Karten) werden auf konzeptioneller Ebene über RessourceIdentifier adressiert. Vor der Nutzung von direkten Kartenoperationen und solchen Operationen, die Kartenzugriffe implizieren, wie Signieren oder Entschlüsseln, muss der Aufrufer den RessourceIdentifier der Karte zusammen mit dem Aufrufkontext einmalig an die TI-Plattform übermitteln. Aus der Kombination von RessourceIdentifier der Karte und Aufrufkontext erzeugt der Konnektor eine Referenz (CardUsageReference), die für alle folgenden Kartenoperationen innerhalb desselben Aufrufkontexts zu verwenden ist.

Anhand der CardUsageReference ermittelt der Konnektor bei jedem Aufruf den gespeicherten Aufrufkontext und steuert damit den Zugriff auf Karten mit möglicherweise erhöhtem Sicherheitszustand.

Die abstrakte Definition der CardUsageReference reicht aus, um auf Konzeptebene die Interaktionen der Clientsysteme und Fachmodule über den Konnektor mit den Karten modellieren zu können. Wie der spätere tatsächliche technische Mechanismus ausgestaltet werden wird, der die obigen Anforderungen (Abgrenzung der Sicherheitszustände von verschiedenen Aufrufern) umsetzt, wird auf Spezifikationsebene unter Berücksichtigung von Sicherheitsaspekten entschieden.

Abbildung 7: CardUsageReference

4.3 Mandantenfähigkeit

Mandantenfähigkeit bedeutet für die TI-Plattform, dass mehrere Organisationseinheiten dezentrale Produkttypen der TI-Plattform gemeinsam nutzen, wobei eine strikte Trennung der Daten einzelner Mandanten vorgenommen werden muss.

Produkttypen der TI-Plattform müssen dann mandantenfähig implementiert werden, wenn sie entweder

1. Daten verarbeiten, die nur im Kontext eines definierten Mandantenbezugs gelesen, erzeugt oder verändert werden dürfen und / oder
2. andere dezentrale Produkttypen verwalten und verwenden, die im Kontext eines definierten Mandantenbezugs stehen.

Anwendung der Kriterien auf die Komponenten der TI-Plattform

Das Kriterium a) trifft nur auf die Produkttypen SMC-B und HSM-B zu. Beide Produkttypen beinhalten private Schlüssel (Daten) für einen oder mehrere Mandanten. Alle anderen Produkttypen der TI-Plattform bearbeiten nur Daten, die im direkten Nutzerbezug stehen.

Das Kriterium b) trifft nur auf den Konnektor zu. Dieser verwaltet die lokalen Kartenterminals, die lokal verfügbaren Karten bzw. HSM (eGK, SMC-B/HSM-B, HBA) und steuert die Zugriffe auf diese Komponenten. Alle anderen Komponenten der TI-Plattform sind nur für sich selbst verantwortlich.

Hinweis: Für Fachmodule und Fachdienste kann Kriterium a) durchaus erfüllt sein. Diese werden jedoch hier nicht betrachtet.

Umsetzung der Mandantenfähigkeit in der TI-Plattform

SMC-B

SMCs besitzen keine Benutzerverwaltung und können daher nicht eigenständig erkennen, ob ein aufrufender Nutzer zu einem bestimmten Mandanten gehört. SMCs (wie alle Smartcards) koppeln die Nutzung privater Schlüssel an die Erreichung des dafür nötigen Sicherheitszustands. Dieser wird erreicht, wenn (je nach Konfiguration) eine erfolgreiche PIN-Verifikation oder ein erfolgreiches Card to Card durchgeführt wurde. Anschließend können die privaten Schlüssel genutzt werden. Die Smartcard verlässt sich dabei darauf, dass ihre Umgebung sicherstellt, dass nur der Benutzer die privaten Schlüssel nutzen darf, der ursächlich die Erreichung des erhöhten Sicherheitszustands auch erfolgreich ausgelöst hat.

Die SMC delegiert die Durchsetzung der mandantenbezogenen Datentrennung an die Außenwelt, die mit ihr interagiert, in diesem Fall an die Fachmodule und den Konnektor. Da Fachmodule in der Hoheit der Fachanwendungen liegen, ist die mandantenbezogene Nutzung der SMC-B durch die Fachanwendungen umzusetzen. Die Betrachtung der Bedeutung für den Konnektor erfolgt im nächsten Abschnitt.

HSM-B

Grundsätzlich gelten die Aussagen der SMC-B auch für das HSM-B. Das HSM-B kann allerdings zusätzlich Daten für mehrere Mandanten beinhalten und muss eine Selektion bei Zugriff auf die Daten mit Mandantenbezug unterstützen.

Konnektor

Mandantenfähigkeit bedeutet für den Konnektor eine sichere Umgebung für jeden Mandanten innerhalb der dem Konnektor zugeordneten Leistungserbringer- oder Kostenträgerumgebung zu schaffen. Ein Beispiel ist eine Praxisgemeinschaft mit einem Konnektor und jeweils einem Mandanten pro Arzt. Die konkreten Konstellationen können hier, speziell im Krankenhausumfeld, sehr unterschiedlich sein und müssen durch den Ansatz abdeckbar sein.

Durch die Delegation der mandantenbezogenen Datentrennung der SMC-Bs an den Konnektor, ist er in der Pflicht sicherzustellen, dass nur Aufrufer im erlaubten Mandantenkontext die SMC-B nutzen. Der Konnektor seinerseits verwendet die SMC-B nie eigenmächtig, d. h. es findet keine implizite Nutzung der SMC-B durch den Konnektor statt. Alle SMC-B-Interaktionen geschehen durch einen Aufruf eines Clientsystems (Primärsystems). Daher wird diese Pflicht vollständig durch die oben aufgeführte Zugriffsautorisierung erfüllt. Analoge Aussagen gelten für das HSM-B, wobei hier durch den Konnektor eine Selektion der Daten und Funktionen mit Mandantenbezug (gedanklich der zugrundeliegenden SMC-B) auf dem HSM-B durchzuführen ist.

Primärsysteme sind vertrauenswürdig, und der Konnektor ist gehalten „der Userverwaltung und -authentisierung der Primärsysteme für einen Zugriff auf Karten des Leistungserbringers und institutionsbezogene Sicherheitsmodule [zu] vertrauen [,] um in den dezentralen Komponenten der TI-Plattform auf eine weitere User-Verwaltung verzichten zu können“. Eine eigene Benutzerverwaltung innerhalb des Konnektors ist daher nicht erforderlich und damit auch keine mandantenfähige Benutzerverwaltung. Ebenso kann der Konnektor die Information der Mandantenzuordnung vom Primärsystem als Aufrufparameter erhalten und dieser Information vertrauen.

Eine Detaillierung der Umsetzung der Mandantenfähigkeit erfolgt in der Spezifikation des Produkttyps Konnektor. Fachmodule müssen die TI-Plattform an den definierten Schnittstellen mit der benötigten Mandanteninformation versorgen.

4.4 Remote-PIN

Die Telematikinfrastruktur ermöglicht dem Anwender für alle angebotenen Funktionen, die PIN-Eingaben an HBAs oder an SMC-B/HSM-B benötigen, die für diese Funktion nötige PIN wahlweise lokal einzugeben oder per Remote-PIN-Eingabe durchzuführen.

Das Verfahren zur Remote-PIN-Eingabe ermöglicht es Fachmodulen und Clientsystemen, die PIN-Eingabe für eine Smartcard Y in einem Kartenterminal Y über ein zweites Kartenterminal X vorzunehmen.

Um den Schutzbedarf der PIN hinsichtlich des Schutzziels Vertraulichkeit beim Transport zu erfüllen, wird über eine Smartcard X im Kartenterminal X ein sicherer Kanal zur Smartcard Y im Kartenterminal Y oder zu einem HSM-B aufgebaut. Beim Aufbau des Kanals findet eine gegenseitige Authentisierung der Karten mittels CV-Zertifikaten statt.

Smartcard X agiert als Remote-PIN-Sender und Smartcard Y als Remote-PIN-Empfänger. Die PIN wird zum Transport vom Remote-PIN-Sender verschlüsselt und erst vom Remote-PIN-Empfänger im Rahmen der Verifikation entschlüsselt.

Die beteiligten Komponenten des Remote-PIN-Verfahrens skizziert Abbildung 8:

Abbildung 8: Beteiligte Komponenten beim Remote-PIN-Verfahren

Den Ablauf des Remote-PIN-Verfahrens legt Kapitel 7.2.11.3 normativ fest.

Folgende Anforderungen werden an die beteiligten Komponenten des Remote-PIN-Verfahrens gestellt:

4.5 Mobile Szenarien

Bei der Beschreibung der in der Architektur der TI-Plattform definierten Dienste wird zunächst davon ausgegangen, dass die nutzenden Systeme an das Netz des Gesundheitswesens angebunden sind und bei Bedarf Leistungen online abrufen können. Hierfür wird die TI-Plattform mit einem geschlossenen Netz aufgebaut, in der die besonderen Sicherheits- und Nutzungsforderungen des Gesundheitssektors umgesetzt werden.

Es gibt allerdings auch bei vollständiger Vernetzung aller Partner im Gesundheitswesen Szenarien, in denen keine Online-Verbindung möglich ist. Diese Szenarien werden unter dem Begriff Mobile Offline-Szenarien zusammengefasst. Mobile Offline-Szenarien werden durch mobile Fachmodule im Produkttyp Mobiles Kartenterminal (MobKT) realisiert. Dieses mobile Kartenterminal bietet den mobilen Fachmodulen die notwendigen Leistungsmerkmale in einer Ausprägung ohne Online-Verbindung an.

Bezüglich der Dienste des mobilen Kartenterminals lassen sich drei Fälle unterscheiden:

• Dienste, die für die mobilen Offline-Szenarien und den stationären Fall identisch sind.
• Dienste, die sich in ihrer Funktionalität unterscheiden, weil z. B. im stationären Fall eine Online-Anbindung gefordert ist, die in den mobilen Offline-Szenarien nicht zur Verfügung steht.
• Dienste, die nur für den mobilen Fall zur Verfügung stehen.

In den Dienstbeschreibungen wird ersichtlich, welcher der Fälle auf den jeweiligen Dienst zutrifft. Die Zuordnung eines Dienstes zum mobilen Szenario wird durch die ausgewiesene Berechtigung für mobile Fachmodule für diesen Dienst ersichtlich.

Dieser Logik folgend, gibt es nur am Produkttyp Mobiles Kartenterminal (siehe Kapitel 5.3.8) eine zusammenhängende Darstellung der Dienste für die mobilen Offline-Szenarien.

Ungeachtet der Tatsache, dass Dienste für die mobilen Offline-Szenarien und den stationären Fall funktional identisch sein können, sind Anforderungen an die zu verarbeitende Größe von Fachdaten der einzelnen Dienste nur verbindlich für den stationären Fall. Die Größe der verarbeitbaren Fachdaten in mobilen Szenarien orientiert sich an den Bedürfnissen der Fachanwendungen, aber auch an der Leistungsfähigkeit der eingesetzten Systeme und wird daher erst in der Spezifikation des Mobilen Kartenterminals abschließend festgelegt.

4.6 Rechenzentrums-Consumer

Ein Rechenzentrums-Consumer (RZ-Consumer) beschreibt einen möglichen Produkttyp der TI-Plattform oder einer Fachanwendung der TI, der in der Rolle eines Consumers mit der TI interagiert und dabei sowohl Anteile der TI-Plattform als auch Anteile der Fachanwendung oder eines sicheren Übermittlungsverfahrens enthält. Er vereint die Zonen TI-Plattform dezentral, Consumer und ggf. Secure Consumer in einem Produkttyp. Der Betrieb des RZ-Consumers in einem Rechen-zentrum gemäß von der TI definierten Anforderungen ermöglicht die Durchsetzung von Anforderungen an den RZ-Consumer und erleichtert die Umsetzung von Sicherheitsanforderungen, da Annahmen bzgl. der Umgebung getroffen werden können.

Der RZ-Consumer ist an das Zentrale Netz der TI angebunden. Die in ihm enthaltenen Leistungen der TI-Plattform beschränken sich auf die Absicherung ggü. dem Zentralen Netz, dem Zugriff auf zentrale Dienste und der Bereitstellung von Basisfunktionen. Die Leistungen der TI-Plattform im RZ-Consumer werden durch den Consumer-Adapter der TI-Plattform im RZ-Consumer durchgesetzt.

Hinweis: Der RZ-Consumer ist KEIN Produkttyp der TI-Plattform und kann daher nicht analog der Produkttypen der TI-Plattform in diesem Konzept beschrieben werden. Er ist ein konzeptioneller Begriff für einen möglichen Produkttyp der TI-Plattform oder einer Fachanwendung und wird in diesem Konzept oder in der Systemlösung der Fachanwendung, die einen RZ-Consumer realisiert, als konkreter Produkttyp beschrieben.

Die Einführung der virtuellen Komponente „Consumer-Adapter“ schafft die Möglichkeit, dass Leistungen der TI-Plattform in einen Produkttyp der Fachanwendung eingebracht werden (ähnlich einer Library), so dass die Verantwortung der TI-Plattform bzgl. der Absicherung von zentralen Diensten und die Störungsfreiheit anderer Teilnehmer der TI gewährleistet wird. Es kann so darauf verzichtet werden, dass zwei in Reihe geschaltete separate Produkttypen der Fachanwendung und der TI-Plattform geschaffen werden müssen, die beide spezifiziert, entwickelt und zugelassen werden müssten.

4.7 Langfristige Verschlüsselung

Wenn Daten mit entsprechendem Schutzbedarf in der TI gespeichert werden, dann werden diese Daten Nutzer-individuell verschlüsselt, um zum einen eine größtmögliche Sicherheit zu erreichen und zum anderen über die Verschlüsselung auch eine weitere Schicht der Autorisierung des Datenzugriffs umzusetzen, da nur derjenige auf die Daten zugreifen kann, der im Besitz des richtigen Schlüsselmaterials ist. Im Normalfall kommen dabei asymmetrische Verschlüsselungsverfahren zum Einsatz.

Ein Nachteil der asymmetrischen Verschlüsselungsverfahren ergibt sich, wenn Daten langfristig verschlüsselt gespeichert werden sollen. Da das eingesetzte asymmetrische Schlüsselmaterial der Nutzer in seiner Laufzeit begrenzt ist, ergibt sich die Notwendigkeit, die verschlüsselten Daten nach Ablauf des Schlüsselmaterials regelmäßig für das neue Schlüsselmaterial des Nutzers umzuschlüsseln. Da das Umschlüsseln erst ein Entschlüsseln der Daten erfordert, kann dies nur in hochsicheren Umgebungen oder Umgebungen unter der alleinigen Kontrolle des Nutzers erfolgen.

Eine Umschlüsselung wird verhindert, wenn der benötigte private Schlüssel nicht mehr verfügbar ist, da z.B. die entsprechende Karte defekt ist oder verloren wurde.

Aus diesem Grund wird für eine langfristige Verschlüsselung vorgesehen, dass ein mehrstufiges symmetrisches Verfahren mit abgeleiteten Schlüsseln zum Einsatz kommt. Dabei ist wichtig, dass zwei unterschiedliche, durch Schlüsselgenerierungsdienste  (SGD) zweier unabhängiger Anbieter erzeugte, Schlüssel zum Einsatz kommen. Ein SGD (SGD 2) wird durch die TI-Plattform als zentraler Dienst bereitgestellt, der andere SGD (SGD 1) muss durch den Anbieter des nutzenden fachanwendungsspezifischen Dienst (FAD) bereitgestellt werden. Die zu sichernden Daten werden durch den Client erst mit dem Schlüssel des SGD 1 (FAD) verschlüsselt. Danach wird das erzeugte Chiffrat durch den Client mit dem Schlüssel des SGD 2 der TI-Plattform verschlüsselt, bevor sie im FAD gespeichert werden. Dies stellt sicher, dass die verschlüsselten Daten weder von der TI-Plattform noch vom Anbieter des FAD entschlüsselt werden können.

Abbildung 9: Verschlüsselungskonzept für langfristige Verschlüsselung

Die Schlüsselgenerierungsdienste erzeugen Nutzer-individuelle symmetrische Schlüssel. Nach erfolgreicher Authentifizierung des Nutzers auf Basis seiner kryptographischen AUT-Identität wird aus einem Masterkey unter Verwendung der Nutzer-individuellen Kennung aus dem Zertifikat (Telematik-ID bzw. unveränderlicher Anteil der KVNR) und ggf. fachanwendungsspezifischen Informationen ein Schlüssel abgeleitet. Dies stellt sicher, dass ein SGD für einen Nutzer in einer Fachanwendung immer denselben Schlüssel erzeugt. Die Masterkeys werden regelmäßig erneuert, so dass dann neu erzeugte Schlüssel von unterschiedlichen Masterkeys abgeleitet werden.

5 Produkttypen der TI-Plattform

In diesem Kapitel werden die Produkttypen der TI-Plattform festgelegt. Dabei wird auf konzeptioneller Ebene die Verantwortlichkeit eines jeden Produkttyps benannt und die Bereitstellungspunkte der Leistungen der TI-Plattform auf die Produkttypen verteilt.

5.1 Übersicht des Gesamtsystems

Abbildung 10 zeigt eine Übersicht des Gesamtsystems Telematikinfrastruktur, um so ein Verständnis der Verteilung der verschiedenen Produkttypen zu unterstützen. Die Darstellung erfolgt in diesem Fall in einer Netzwerksicht, da dies dem zu vermittelnden Bild am nächsten kommt. Nachfolgend wird die produkttypbezogene Modellierung aber vornehmlich in UML erfolgen.

Abbildung 10: Übersicht des Gesamtsystems der TI

5.2 Festlegungen zu Produkttypen der TI-Plattform

In diesem Kapitel werden Aspekte der Produkttypen aufgegriffen, die mehrere oder alle Produkttypen der TI-Plattform betreffen.

Nachfolgend werden Festlegungen getroffen, die mehrere oder sogar alle Produkttypen betreffen und nicht direkt an eine funktionale Leistung der TI-Plattform gebunden sind.

Für die Details der Schnittstellen siehe Kapitel 5.5, 5.6 und 5.7.

5.3 Produkttypen der Zone TI-Plattform dezentral

Produkttypen der dezentralen Zone der TI-Plattform bilden alle Anteile des Building Blocks „dezentrale Komponenten der TI-Plattform“ der Zone „TI-Plattform – dezentral“ vollständig ab.

Dabei unterliegen Produkttypen der TI-Plattform die eine Smartcard darstellen dem Bestandsschutz. Die Spezifikation der Smartcards der Generation 2 ist nicht Bestandteil dieses Projektes. Daher werden die Smartcards in den folgenden Abschnitten nur kurz beschrieben.

5.3.1 Produkttyp elektronische Gesundheitskarte (eGK)

Die eGK ist eine Smartcard und wird zur Authentisierung des Versicherten in der TI sowie zur Signatur und Entschlüsselung von Daten des Versicherten eingesetzt. Zusätzlich können auf der eGK in begrenztem Umfang Daten der Fachanwendungen in sog. Fachanwendungsspezifischen Karten-Applikationen (vgl. Kap. 4.1.1) gespeichert werden. Die Zugriffsmöglichkeiten auf die jeweiligen Daten können auf bestimmte Rollen eingeschränkt werden.

5.3.2 Produkttyp Heilberufsausweis (HBA)

Der HBA ist eine Smartcard und wird zur Authentisierung des Leistungserbringers in der TI sowie zur Signatur und Entschlüsselung von Daten der Fachanwendungen eingesetzt.

5.3.3 Produkttyp Security Module Card Organisationen des Gesundheitswesens (SMC-B)

Die SMC-B ist eine Smartcard und wird zur Authentisierung der Organisationen des Gesundheitswesens in der TI sowie zur Signatur und Entschlüsselung von Daten der Fachanwendungen eingesetzt. Die SMC-B einer Leistungserbringerinstitution ist bei ihrem Zugriff auf Anwendungen der eGK gemäß §291a SGB V organisatorisch immer an einen HBA gebunden der diesen Zugriff legitimiert. Diese Bindung der SMC-B einer Leistungserbringerinstitution an einen HBA wird durch die Kartenherausgeber durchgesetzt.

5.3.4 Produkttyp Hardware Security Module Organisationen des Gesundheitswesens (HSM-B)

Der Produkttyp HSM-B ist für die Telematikinfrastruktur vorgesehen. Fragen der Umsetzung eines HSM-Bs sind derzeit in Klärung.

Das HSM-B ist ein spezielles HSM und wird zur Authentisierung von Organisationen des Gesundheitswesens in der TI sowie zur Signatur und Entschlüsselung von Daten der Fachanwendungen eingesetzt. Es kann in größeren Organisationen des Gesundheitswesens anstatt der SMC-B zum Einsatz kommen, falls die Performance der SMC-B nicht ausreichend ist.

5.3.5 Produkttyp Security Module Card Kartenterminal (gSMC-KT)

Die gSMC-KT dient zur Authentisierung des Kartenterminals bei der Kommunikation mit dem Konnektor.

5.3.6 Produkttyp Security Module Card Konnektor (gSMC-K)

Die gSMC-K dient zur Authentisierung des Konnektors bei der Kommunikation mit dem VPN-Zugangsdienst, dem Kartenterminal und dem HBA.

5.3.7 Produkttyp eHealth-Kartenterminal (KT)

Das eHealth-Kartenterminal dient der Interaktion mit Smartcards. Gemäß Bestandsschutz ist die hardwareseitige Ausprägung der Kartenterminals durch die eHealth-Spezifikation zum Online-Rollout R4.0.0 gesetzt. Dies bedeutet im Wesentlichen: Einhaltung des SICCT-Standards, Netzanschluss, Display, PIN-Pad, mindestens einen ID-1- sowie einen ID-000-Steckplatz.

Die nachfolgenden Festlegungen stehen nicht im Konflikt mit dem geltenden physikalischen und elektrophysikalischen Bestandschutz des eHealth-Kartenterminals, da sie entweder die Firmware des KTs betreffen oder durch Vorgaben der Arbeitsgruppe „Einsatzumgebung Kartenterminal“ adressiert werden. Bei den Vorgaben der Arbeitsgruppe „Einsatzumgebung Kartenterminal“ handelt es sich um gematik-interne Vorgaben, die bei der Umsetzung von Anforderungen an das eHealth-Kartenterminal innerhalb der Spezifikationen der gematik berücksichtigt worden sind.

5.3.8 Produkttyp Mobiles Kartenterminal (MobKT)

Das mobile Kartenterminal ist ein Gerät, mit welchem mobil mit Karten des Gesundheitswesens interagiert werden kann. Es vereint die Funktionen eines eHealth-Kartenterminals (Karten-Slots, Display, PIN-Pad) mit den Funktionen eines mobilen Kleincomputers/PDAs (grafische Benutzerführung, Daten speichern/laden/bearbeiten). Auf einem mobilen Kartenterminal werden mobile Fachmodule betrieben, die die Funktionen zur fachlichen Interaktion bereitstellen. Mobile Fachmodule steuern die Benutzerinteraktion sowie die fachlogische Kommunikation mit Daten und Schlüsseln der lokal gesteckten Karten.

Ein mobiles Kartenterminal hat keinen Zugang zur zentralen TI-Plattform oder einem Konnektor. Es wird zur Übertragung von Daten lokal an einen Arbeitsplatzrechner angeschlossen und kommuniziert ausschließlich mit diesem. Optional kann ein mobiles Kartenterminal auch so gestaltet werden, dass es als eHealth-Kartenterminal betrieben werden kann.

Die HBA-Vorläuferkarten HBA-qSig und ZOD-2.0 werden im mobilen Kartenterminal nicht unterstützt.

Die Leistungsfähigkeit des migrationsfähigen, mobilen Kartenterminals der Stufe 1 ist beschrieben in [Spezifikation Mobiles Kartenterminal Ausbaustufe 1].

5.3.9 Produkttyp Konnektor

Der Konnektor, als Bestanteil der TI verbindet die Clientsysteme der Leistungserbringer und Kostenträger auf dezentraler Seite mit der TI. Dazu implementiert der Konnektor Teile der Basis- und Infrastrukturdienste der TI-Plattform und stellt die relevanten Basisdienste und Infrastrukturdienste den Clientsystemen zur Verfügung. Ferner beinhaltet der Konnektor die Fachmodule der Fachanwendungen.

Der Zugriff auf eHealth-Kartenterminals sowie der Zugriff auf eGK, HBA und SMC-B im lokalen Netz erfolgt ausschließlich über den Konnektor. Weiterhin stellt der Konnektor einen Signaturproxy bereit. Der Signaturproxy gehört zwar zum Produkttyp Konnektor, wird aber als Softwarekomponente auf Arbeitsplatzrechnern der Leistungserbringer installiert.

Der Konnektor stellt eine sichere Verbindung über ein unsicheres Transportnetz (z. B. Internet) in das zentrale Netz der TI bereit. Er schützt das lokale Netzwerk des Leistungserbringers oder Kostenträgers und die dort installierten Clientsysteme vor Angriffen aus der TI und umgekehrt, die TI vor Angriffen aus dem lokalen Netzwerk des Leistungserbringers oder Kostenträgers.

Für die Nutzung von angeschlossenen Netzen des Gesundheitswesens mit aAdG-NetG und die Weiternutzung vorhandener Internetzugänge ermöglicht der Konnektor die Auflösung von FQDN aus den entsprechenden Namensräumen und die Weiterleitung von IP-Paketen an die jeweiligen Adressräume. Der Konnektor ermöglicht zusätzlich die Nutzung eines sicheren Internetzugangs über einen getrennten VPN-Kanal.

5.3.9.1 Konfigurationsmodell des Konnektors

Entsprechend (LH-BasisTI-A_1982) und (LH-BasisTI-A_1983) muss der Konnektor ein Konfigurationsmodell unterstützen, um unterschiedliche durch die gematik definierte Funktionsumfänge auf der gleichen Hard- und Firmwarebasis zu unterstützen. Durch Konfigurationsänderungen am Konnektor muss ein Wechsel zwischen den definierten Funktionsumfängen möglich sein.

Durch die definierten Funktionsumfänge soll einerseits das Standalone-Szenario mit einer physischen Trennung durch 2 Konnektoren unterstützt werden, andererseits die QES getrennt aktivierbar gemacht werden.

Hierzu müssen Konnektoren ohne spezielle Konfiguration den Basisfunktionsumfang unterstützen um als primärsystemseitige Sicherheitskomponente im Standalone-Szenario mit physischer Trennung eingesetzt werden zu können. Im Basisfunktionsumfang muss eine Online-Verbindung in die TI unterbunden werden, weiterhin darf keine QES unterstützt werden. Alle anderen Dienste der TI-Plattform werden unterstützt, sind ggf. aber durch die fehlende Online-Anbindung eingeschränkt.

Durch zwei unabhängig voneinander zu betrachtende Konnektorkonfigurationen LU_Online und LU_SAK kann die Online-Anbindung an die TI und die QES konfiguriert und der Basisfunktionsumfang des Konnektors erweitert werden. Insgesamt werden durch den Basisfunktionsumfang des Konnektors und die zwei unabhängigen Konfigurationen vier Funktionsumfänge des Konnektors unterstützt.

1. LU_Offline
2. LU_Offline + LU_Online
3. LU_Offline + LU_SAK
4. LU_Offline + LU_Online + LU_SAK

Hinweis: Falls die Konfiguration LU_SAK ohne die Konfiguration LU_Online vorhanden ist, wird der Basisdienst Erstellung_Prüfung_QES lediglich im Offline-Modus unterstützt, d. h. analog zu dem Fall einer fehlenden bzw. gestörten Online-Verbindung.

5.3.9.2 Anforderungen an den Konnektor

Hinweis: Die Entscheidung zur Umsetzung von TIP1-A_2517 wird auf der Ebene der Spezifikation des Produkttyps Konnektor getroffen.

5.3.10 Produkttyp Basis-Consumer

Der Basis-Consumer ermöglicht es Gesellschaftern der gematik und denen durch sie vertretenen Organisationen, als Nutzer an der TI teilzunehmen. Genutzt werden können dabei die sicheren Übermittlungsverfahren (SÜV) und die weiteren Anwendungen des Gesundheitswesens. Der Zugriff auf Fachanwendungen der TI ist nicht gestattet. Dieser Produkttyp enthält keine Fachmodule, aber ein Clientmodul KOM-LE, zur Nutzung des sicheren Übermittlungsverfahrens.

Der Produkttyp Basis-Consumer ist ein RZ-Consumer entsprechend Kapitel 4.6 und stellt seine Leistungen in der Rechenzentrumsumgebung des Nutzers bereit. Der Produkttyp ist für die Nutzung der SMC-B der Gesellschafterorganisationen ausgelegt, die in Kartenform vorliegt oder in einem HSM gespeichert ist.

5.3.11 Produkttyp KTR-Consumer

Der KTR-Consumer ermöglicht es Krankenkassen, als Nutzer an der TI teilzunehmen. Genutzt werden können dabei Fachanwendungen, bei der die Krankenkassen als berechtigte Nutzer festgelegt sind (mit Ausnahme von VSDM), die sicheren Übermittlungsverfahren (SÜV) und die weiteren Anwendungen des Gesundheitswesens. Dieser Produkttyp enthält Fachmodule und ein Clientmodul KOM-LE zur Nutzung des sicheren Übermittlungsverfahrens.

Der Produkttyp KTR-Consumer ist ein RZ-Consumer entsprechend Kapitel 4.6 und stellt seine Leistungen in der Rechenzentrumsumgebung des Nutzers bereit. In seinen Leistungen deckt der KTR-Consumer alles ab, was ein Basis-Consumer leistet, enthält zusätzlich aber auch noch Fachmodule für die Nutzung von Fachanwendungen. Der Produkttyp ist ausschließlich für die Nutzung der SMC-B der Krankenkassen ausgelegt, die in einem HSM gespeichert ist.

5.4 Produkttypen der Zone TI-Plattform zentral

Produkttypen der zentralen Zone der TI-Plattform bilden alle Anteile des Building Blocks „zentrale Dienste der TI-Plattform“ der Zone „TI-Plattform – zentral“ vollständig ab.

5.4.1 Produkttyp Zentrales Netz TI (Zentrales Netz)

Das Zentrale Netz TI ermöglicht den Transport von IP-Daten zwischen den angeschlossenen Nutzern der TI. Dies beinhaltet die Infrastruktur zur Kontrolle des Zugangs zum Zentralen Netz der TI und die eigentliche zentrale Transportplattform.

Um das Zentrale Netz der TI vor Angriffen aus den angeschlossenen Fachdiensten sowie aus angeschlossenen weiteren Anwendungen oder sicheren Übermittlungsverfahren und umgekehrt, die Fachdienste vor Angriffen aus dem Zentralen Netzwerk der TI, zu schützen, wird an jedem Übergangspunkt eine Stateful Inspection Firewall eingesetzt. Diese ermöglicht ausschließlich die fachlich erforderliche Kommunikation in den zulässigen Kommunikationsrichtungen. D. h. Dienste der TI-Plattform-Zone zentral dürfen nur mit Diensten innerhalb dieser Zone Verbindungen aufbauen und fachanwendungsspezifische Dienste dürfen nur Verbindungen zu anderen fachanwendungsspezifischen Diensten sowie zu zentralen Diensten der TI-Plattform aufbauen.  Weitere Anwendungen des Gesundheitswesens in der Provider Zone (aAdG bzw. aAdG-NetG-TI) dürfen nur mit anderen aAdG bzw. aAdG-NetG-TI kommunizieren. Ein Verbindungsaufbau in die TI aus Netzen des Gesundheitswesens mit Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste (aAdG-NetG) wird verhindert. Nur Clientsysteme aus der Consumer Zone dürfen auf aAdG-NetG zugreifen.

5.4.2 Produkttyp Zeitdienst

Auf Basis von NTP-Servern wird die gesetzliche Zeit den NTP-Clients der Dienste und Komponenten der TI zur Verfügung gestellt. Der Zeitdienst dient dabei als Zeitquelle für die TI, mit der sich andere NTP-Server und NTP-Clients synchronisieren.

5.4.3 Produkttyp Namensdienst

Zur Auflösung von Fully Qualified Domain Names (FQDN) in IP-Adressen wird in der TI das Domain Name System (DNS) verwendet. Das Wurzelverzeichnis (DNS-Root) der TI wird über den Namensdienst bereitgestellt.

Der Betrieb und die Verwaltung des Namensraumes der TI erfolgt durch den Betreiber dieses Produkttyps. Der Betrieb und die Verwaltung von definierten Teilen des Namensraumes (Subdomains) kann an andere Dienstbetreiber delegiert werden (DNS-Zone-Delegation).

Weiterhin wird der Namensdienst zur Lokalisierung von Diensten (DNS-Service Discovery) genutzt.

5.4.4 Produkttyp Verzeichnisdienst

5.4.5 Produkttyp TSL-Dienst

Durch den TSL-Dienst wird der zentrale Vertrauensraum der X.509-PKI der TI bereitgestellt. Er stellt zusätzlich die Vertrauensliste der BNetzA in der TI bereit.

5.4.6 Produkttyp Konfigurationsdienst (Konfigdienst)

Der Konfigurationsdienst stellt für die Produkttypen Konnektor und eHealth-Kartenterminal Konfigurationsdaten und Softwareupdates bereit. Der Produkttyp MobKT wird nicht durch den Konfigurationsdienst unterstützt.

5.4.7 Produkttyp VPN-Zugangsdienst (Zugangsdienst)

Der VPN-Zugangsdienst ermöglicht den Konnektoren einen IPsec-Tunnel über ein Transportnetz zum VPN-Zugangsdienst aufzubauen und verbindet darüber die Organisationen des Gesundheitswesens mit dem zentralen Netz der TI.

Zusätzlich ermöglicht der VPN-Zugangsdienst den Konnektoren den Aufbau eines separaten IPSec-Tunnels über das Transportnetz, durch den der sichere Internetzugang erreichbar ist.

5.4.8 Produkttyp Sicherheitsgateway Bestandsnetze (SG-BNet)

Der Produkttyp Sicherheitsgateway Bestandsnetze ermöglicht den Clientsystemen die Nutzung von weiteren Anwendungen des Gesundheitswesens ohne Zugriff auf zentrale Dienste (aAdG-NetG) in angeschlossenen Netzen des Gesundheitswesens, wie dem sicheren Netz der KVen (SNK).

Jedes Netz des Gesundheitswesens mit aAdG-NetG wird über eine eigene Instanz des Produkttyps Sicherheitsgateway Bestandsnetze an die TI angebunden. D.h. für jedes Netz des Gesundheitswesens mit aAdG-NetG werden separate Verbindungsregeln verwaltet und es ist eine Rückwirkungsfreiheit zwischen den angebundenen Netzen des Gesundheitswesens mit aAdG-NetG gesichert. Ob dies durch physikalische oder virtuelle Instanzen erreicht wird, ist nicht festgelegt. Die Anbindung des Netzes des Gesundheitswesens mit aAdG-NetG an das Sicherheitsgateway Bestandsnetze über ein VPN ist Teil des Produkttyps.

Um die TI vom SNK bzw. anderen Netzen des Gesundheitswesens mit aAdG-NetG abzuschotten, werden an diesen Netzübergängen Sicherheitsgateways eingesetzt werden.

5.4.9 Produkttyp Trust Service Provider X.509 nonQES (TSP-X.509nonQES)

Der Trust Service Provider X.509 nonQES stellt X.509-nonQES-Zertifikate für berechtigte Personen (z. B. Zertifikate des HBA und der eGK), Organisationen und technische Komponenten aus und ermöglicht die Abfrage des Sperrstatus von durch ihn ausgestellten X.509-nonQES-Zertifikaten.

5.4.10 Produkttyp Trust Service Provider X.509 QES (TSP-X.509QES)

Der Trust Service Provider X.509 QES stellt X.509-QES-Zertifikate für berechtigte Personen (z. B. Zertifikate des HBA und der eGK) aus und ermöglicht die Abfrage des Sperrstatus von durch ihn ausgestellten X.509-QES-Zertifikaten.

5.4.11 Produkttyp gematik Root-CA

Die gematik Root-CA stellt X.509-Sub-CA-Zertifikate (nur nonQES) für berechtigte TSPs aus. Die CA-Zertifikate für eGKs können auf eigenen PKI-Strukturen basieren oder sich auch von der gematik Root-CA ableiten.

5.4.12 Produkttyp Trust Service Provider CVC (TSP-CVC)

Der Trust Service Provider CVC betreibt eine von der gematik CVC-Root-CA abgeleitete CVC-Sub-CA (CA der zweiten Ebene) nach den Regularien der gematik und erstellt CV-Zertifikate mit den spezifizierten Rollenattributen für berechtigte Personen (HBA, eGK) und Organisationen/Institutionen (SM-B).

5.4.13 Produkttyp CVC-Root

Die CVC-Root ist die zentrale Root-CA der PKI für CV-Zertifikate in der TI.

5.4.14 Produkttyp OCSP-Responder Proxy (OCSP-Proxy)

Der OCSP-Responder Proxy ermöglicht es Statusauskünfte für Zertifikate aus dem Vertrauensraum der TI, deren OCSP-Responder im Internet stehen, innerhalb der TI verfügbar zu machen. Dafür leitet er die entsprechenden Anfragen ins Internet weiter und liefert die zugehörige Statusauskunft zurück. Dies wird für die zeitlich begrenzt unterstützten HBA-Vorläuferkarten benötigt.

5.4.15 Produkttyp Störungsampel

Die Störungsampel spiegelt zentral den Betriebsstatus der zentralen Dienste der TI-Plattform und der fachspezifischen Dienste wieder.

5.4.16 Produkttyp Service Monitoring

Perspektivisch wird das Service Monitoring die Aufgaben der Störungsampel übernehmen. In der Übergangsphase sind beide Produkttypen aktiv und ihre Nutzung wird betrieblich koordiniert.

Das Service Monitoring testet durch Probes die Verfügbarkeit zentraler Dienste, sicherer Übermittlungsverfahren und fachanwendungsspezifischer Dienste. Die Erreichbarkeit von Netzen mit aAdG-NetG wird durch Probes auf vom Anbieter benannte Dienste dieser Netze geprüft.

Darüber hinaus sammelt es die Performance-Reports der verschiedenen Dienste ein. Die Erkenntnisse zum Betriebsstatus der einzelnen Dienste werden berechtigten Nutzern des Dienstes bereitgestellt.

5.4.17 Produkttyp Signaturdienst

Der Signaturdienst erlaubt es, die alternative kryptographische VersicherteniIdentität ID.CH.AUT_ALT der eGK im sicheren Schlüsselspeicher des Dienstes zu speichern und durch den Versicherten ausgelöste Signaturen mit dieser Identität zu erstellen, um sich ohne Einsatz der eGK ggü. der TI zu authentisieren. Als TI-Plattform-Nutzerdienst ist dieser Dienst in der Provider Zone angesiedelt.

Hinweis: Ein TSP X.509 nonQES eGK muss nicht immer alle Zertifikatsprofile der eGK unterstützen. So ist es möglich, dass ein TSP X.509 nonQES eGK nur die für eine Personalisierung der eGK nötigen Zertifikatsprofile oder ausschließlich das Zertifikatsprofil C.CH.AUT_ALT unterstützt. Welche Zertifikatsprofile der TSP unterstützt wird im Rahmen der Zulassung angezeigt.

5.4.18 Produkttyp Schlüsselgenerierungsdienst (SGD)

Der Schlüsselgenerierungsdienst erzeugt über eine Ableitung aus einem Masterkey, einer Nutzer-ID (Telematik-ID oder unveränderlicher Teil der KVNR) und weiteren fachanwendungsspezifischen Daten einen eindeutigen symmetrischen Schlüssel für die langfristige Verschlüsselung von Daten in der TI. Das Verschlüsselungskonzept (siehe Kapitel 4.7) schreibt vor, dass für eine Verschlüsselung immer zwei Schlüsselgenerierungsdienste zum Einsatz kommen müssen. Einer wird als zentraler Dienst bereitgestellt, der andere muss durch den Anbieter des verwendenden fachanwendungsspezifischen Dienstes bereitgestellt werden. Jeder SGD verwendet eigene MasterKeys, die regelmäßig gewechselt werden.

Bei der Nutzung von SGDs durch ein Frontend des Versicherten wird die Absicherung des Zugriffs auf die verwendeten SGDs durch den FAD der Versicherten geleistet (siehe Kapitel 2.1.3).

5.5 Interfaces der TI-Plattform Dezentral

In den nachfolgenden Kapiteln werden alle Außenschnittstellen der Produkttypen der TI-Plattform mit ihren Operationen und Parametern beschrieben und detailliert für welchen Nutzer sie angeboten werden. Dabei sind folgende Nutzer vorgesehen: Leistungserbringer (LE), Clientsystem oder Clientmodule (CS), Fachmodul (FM), Fachmodul für mobile Kartenterminals (MFM), TI-Plattform (TIP), fachanwendungsspezifische Dienste (FAD), Frontend des Versicherten (FdV), sichere Übermittlungsverfahren (SÜV), weitere Anwendungen des Gesundheitswesens in der Provider Zone (WA) und Administratoren (A). Neben der Benennung des Interfaces und der Operation mit ihren Parametern und Ergebnissen ist auch vermerkt, ob das Interface von der TI-Plattform bereitgestellt (provided) oder benötigt (required) wird.

An den Operationen ist ferner ausgewiesen, welche Schutzleistung die TI-Plattform für die übergebenen Parameter in Bezug auf Vertraulichkeit, Integrität und Authentizität (V, I, A) übernimmt, bzw. welcher Schutzbedarf für die Ergebnisse der Operationen gesehen wird. Ferner wird ausgewiesen, welche Schutzleistung die Operationen in Bezug auf Verfügbarkeit und Nichtabstreitbarkeit haben. Bei der Festlegung der Schutzleistung bzw. des Schutzbedarfs wurde immer das Maximumprinzip angewendet. Sie werden zur Erreichung der Schutzziele der TI benötigt. In Tabelle 37 werden die für die Dokumentation verwendeten Abkürzungen erklärt.

Tabelle 41: Legende zu den Abkürzungen in den Operationstabellen

Für alle Parameter der Operationen wird jeweils ausgewiesen, wie sie im Informationsmodell der TI-Plattform einzuordnen sind. Dabei wird ein Kürzel (z. B. IM101) als Referenz zum Informationsmodell in Abbildung 53 verwendet.

Die aus Kapitel 4.3 geforderten Parameter, die für eine Umsetzung der Mandantenfähigkeit benötigt werden, sind nur für die Operationen an der Schnittstelle I_KV_Card_Handling explizit ausgewiesen, da diese Operationen einen sehr starken Bezug zur Mandantenfähigkeit haben. Für alle anderen Operationen mit Bezug zur Mandantenfähigkeit werden keine zusätzlichen Parameter zum Call-Context beschrieben. Die Information darüber, welche Operationen betroffen sind, können dem Kapitel 3.1 entnommen werden.

5.5.1 Basisdienste

5.5.1.1 Benutzerinteraktion_KT

5.5.1.1.1 I_KT_Operations (Provided)

5.5.1.2 Erstellung_Prüfung_Signatur

5.5.1.2.1 I_Sign_Operations (Provided)