Die Cloud-Zukunft der TI

Zum Hauptinhalt springen
ehex
Souverän, sicher, schrittweise.

Die TI zieht in die Cloud. Was heißt das?

Im Interview klärt Matthias die häufigsten Fragen und Missverständnisse rund um die Cloud-Migration und den Übergang von der TI 1.0 zur TI 2.0.

Die Telematikinfrastruktur wird grundlegend modernisiert. Dabei geht es nicht nur darum, Server in eine andere Betriebsumgebung zu verlagern. Mit dem Übergang von der TI 1.0 zur TI 2.0 verändern sich auch die Architektur des Zugangs, die Sicherheitslogik und die technische Grundlage für Anwendungen wie E-Rezept und ePA.

Die Cloud ist deshalb ein wichtiger Baustein der TI 2.0 – aber nicht deren Synonym. TI 2.0 steht für die schrittweise Weiterentwicklung von einer heute noch stark komponenten- und hardwaregeprägten Infrastruktur hin zu einer stärker plattformorientierten, flexibleren und perspektivisch karten- und hardwareunabhängigeren TI.

Die gematik will die TI in die Cloud bringen. Müssen sich jetzt alle auf eine aufwändige Cloud-Migration einstellen?

Es stimmt: Die gematik will so viel Cloud wie möglich nutzen. Ziel ist eine Betriebsumgebung, in der TI-Dienste standardisierter, elastischer und weniger störungsanfällig betrieben werden können. Die Cloud ist dabei jedoch nur ein Teil der TI-2.0-Architektur. Parallel verändern sich die Zugangsmodelle, die Identitäts- und Berechtigungsverfahren sowie die Sicherheitsarchitektur.
Die heutige TI 1.0 ist stark durch Konnektoren, Kartenterminals, Smartcards und weitere dezentrale Komponenten geprägt. Die TI 2.0 soll diese Abhängigkeiten schrittweise reduzieren und auch mobile sowie cloudbasierte Zugänge ermöglichen. Das bedeutet nicht, dass sämtliche Komponenten sofort ersetzt werden oder die bestehende TI von heute auf morgen abgeschaltet wird.
Die Cloud-Migration betrifft zunächst vor allem das TI-Backend – also die Dienste und technischen Plattformen, auf denen beispielsweise E-Rezept, ePA und weitere Anwendungen betrieben werden. Für Leistungserbringer geschieht dieser Teil weitgehend im Hintergrund. Im Alltag wird daher nicht jede Einrichtung eine eigene Cloud-Migration durchführen müssen. Entscheidend ist vielmehr, über welchen zugelassenen Zugang das Primärsystem oder die jeweilige Anwendung künftig an die TI angebunden wird.

Worin unterscheiden sich TI 1.0 und TI 2.0?

Die TI 1.0 arbeitet heute noch stark mit lokal installierter Hardware, Konnektoren, Kartenterminals und kartenbasierten Verfahren. Die TI 2.0 entwickelt diese Architektur schrittweise weiter: mit cloudbasierten Zugängen, zentral bereitgestellten Plattform- und Basisdiensten sowie neuen mobilen Nutzungsmöglichkeiten.
An die Stelle eines impliziten Netz- und Vertrauensperimeters tritt zunehmend ein Zero-Trust-Ansatz. Nicht der Standort eines Systems entscheidet über Vertrauen, sondern die Prüfung des konkreten Zugriffs. Digitale Identitäten wie die GesundheitsID ergänzen die bisherigen Karten und ermöglichen neue Wege zur Authentifizierung.
Die TI 2.0 soll so zu einer flexibleren Plattform werden, auf der Anwendungen wie ePA und E-Rezept sicher, standardisiert und über unterschiedliche Zugangsszenarien nutzbar bereitgestellt werden können. Der Übergang ist kein harter Schnitt: TI 1.0 und TI 2.0 werden über einen längeren Zeitraum parallel bestehen und technisch miteinander zusammenspielen.

Wer muss was tun, damit die Migration in die Cloud und zur TI 2.0 gelingt?

Die gematik trennt die Verantwortlichkeiten in klar definierte Rollen. Cloud-Service-Provider (CSP) stellen die technische Infrastruktur bereit – also Rechenkapazität, Speicher, Netzwerke und die dafür erforderlichen Betriebs- und Sicherheitsleistungen. Basisdienst-Hersteller entwickeln wiederverwendbare Plattformbausteine, zum Beispiel für Authentifizierung, Autorisierung, Verzeichnisdienste oder sichere Kommunikation. Backend-Hersteller entwickeln und betreiben die TI-Fachdienste wie ePA, E-Rezept und weitere Anwendungen. Sie greifen dabei auf standardisierte Basisdienste der Plattform zurück.
Die neue Umgebung wird nach verbindlichen technischen und sicherheitsbezogenen Vorgaben aufgebaut und anschließend mit der bestehenden TI-Landschaft integriert. Für PVS-Hersteller lautet die entscheidende Frage deshalb weniger: „Wie verschieben wir unser Produkt in die Cloud?“ Sondern vielmehr: „Wie stellen wir sicher, dass unser Produkt an die neue TI-Plattform, ihre Identitätsmodelle und ihre standardisierten Zugangsdienste anschlussfähig ist?“ Das betrifft nicht nur die Infrastruktur. Auch Schnittstellen, Zertifikats- und Schlüsselverwaltung, Mandantenfähigkeit, Monitoring und das Verhalten bei temporären Ausfällen müssen in der Produktarchitektur berücksichtigt werden.

Gesundheitsdaten sollen also in die Cloud. Ist das sicher?

Berechtigte Frage. Wichtig ist: Es geht nicht um eine beliebige Public Cloud, sondern um eine souveräne und regulierte Betriebsumgebung mit hohen Anforderungen an Datenschutz, Informationssicherheit, Verfügbarkeit und Nachvollziehbarkeit. Maßgeblich ist nicht allein, in welchem Land ein Rechenzentrum steht. Entscheidend ist das Zusammenspiel aus rechtlicher Kontrolle, Betreiberstruktur, technischer Zugriffskontrolle, Verschlüsselung, Protokollierung und nachweisbaren Sicherheitsprozessen.
Für die TI gelten dabei unter anderem die Anforderungen der DSGVO sowie hohe regulatorische und technische Vorgaben. Ein BSI-C5-Testat kann die Eignung der Cloud-Kontrollen für den vorgesehenen Betrieb nachvollziehbar dokumentieren. Ergänzend kann Confidential Computing die Verarbeitung schützen: Daten werden nicht nur bei der Übertragung und Speicherung verschlüsselt, sondern sollen auch während der Verarbeitung innerhalb einer geschützten Ausführungsumgebung vor unbefugten Einblicken geschützt sein.
Die Sicherheitsarchitektur der TI 2.0 wird außerdem auf einen Zero-Trust-Ansatz weiterentwickelt. Dabei gilt kein Netz, kein Gerät und keine Verbindung allein deshalb als vertrauenswürdig, weil sie sich innerhalb einer bekannten Umgebung befindet. Jeder Zugriff muss kontextbezogen geprüft und autorisiert werden. Berücksichtigt werden können dabei unter anderem Identität, Rolle, konkrete Berechtigung, angeforderter Dienst und Sicherheitszustand des zugreifenden Systems. Sicherheit entsteht damit nicht durch einen einzelnen Baustein, sondern durch das Zusammenwirken von Identitäten, kryptografischen Verfahren, Zugriffspolitiken, sicherem Betrieb und kontinuierlicher Überwachung.

Wann kommt die TI in die Cloud?

Die Cloud-Infrastruktur und die darauf aufbauenden Plattformdienste müssen zunächst aufgebaut, zugelassen und in die bestehende TI integriert werden. Nach den aktuellen Planungen ist der Go-Live der neuen Cloud-Plattform für 2028 vorgesehen. Mit PoPP gehen wir jedoch bereits ab 2026 einen ersten großen Schritt in diese Richtung: PoPP schafft neue Möglichkeiten für die Prüfung und Dokumentation der Leistungserbringer- beziehungsweise Versorgungssituation und ist damit ein konkreter Baustein auf dem Weg zu einer stärker digitalen, flexibleren und perspektivisch hardwareunabhängigeren TI.
Ab diesem Zeitpunkt sollen weitere TI-Dienste schrittweise auf die modernisierte Betriebsumgebung migriert beziehungsweise dort neu bereitgestellt werden. Es gibt aber zunächst keinen harten Schnitt. Die heutige TI 1.0 läuft weiter, während einzelne Zugangswege, Plattformdienste und Anwendungen der TI 2.0 nach und nach hinzukommen.
Der Übergang ist deshalb eher eine kontrollierte Evolution als ein einmaliger Systemwechsel. Beide Architekturen müssen über eine längere Phase zuverlässig zusammenspielen. Für Leistungserbringer bedeutet das: Bestehende Investitionen verlieren nicht automatisch ihre Gültigkeit. Gleichzeitig sollten neue Lösungen so geplant werden, dass sie den Übergang nicht erschweren und später nicht grundlegend neu gebaut werden müssen.
Die Richtung ist bereits heute klar. Auch wenn einzelne Zeitpunkte und Migrationsschritte von Zulassungen, technischen Reifegraden und Umsetzungsentscheidungen abhängen, hat die Entwicklung zur TI 2.0 schon jetzt konkrete Folgen für Produkt- und Architekturentscheidungen.

Was macht Produktentscheidungen heute zukunftsfähig?

Produkte sollten nicht ausschließlich für die heutige TI 1.0 optimiert werden, sondern eine belastbare Übergangs- und Zielarchitektur mitdenken. Dazu gehören eine klare Trennung zwischen Fachanwendung und TI-Anbindung, standardisierte Schnittstellen sowie die Fähigkeit, unterschiedliche zugelassene Zugangswege kontrolliert zu unterstützen.
Identität und Berechtigung sollten nicht fest an eine einzelne Karte, einen einzelnen Konnektor oder eine bestimmte lokale Infrastruktur gekoppelt sein. Eine zukunftsfähige Lösung kann unterschiedliche Authentifizierungsverfahren sicher einbinden und deren Berechtigungen nachvollziehbar verwalten. Ebenso wichtig sind cloudfähige und skalierbare Betriebsmodelle sowie ein Sicherheitskonzept, das Zero Trust in konkrete Zugriffspolitiken und technische Kontrollen übersetzt.
Für Hersteller bedeutet das auch, Betriebs- und Integrationsdaten systematisch auszuwerten. Mit belastbarem Monitoring, klaren Zustandsmodellen und nachvollziehbaren Protokollen lassen sich Störungen in einer verteilten Plattform schneller eingrenzen.
Wir bewegen uns schon heute in genau diese Richtung: Der cloudbasierte TI-Zugang ist technisch bereits möglich. Für unsere Partner gibt es damit bereits eine Integrationsebene, die den Weg von der TI 1.0 zur neuen TI-Plattform vorbereitet. Cloud-native TI-Anschlüsse sind keine Zukunftsmusik. Sie sind ein erster konkreter Schritt in Richtung einer TI, bei der Fachanwendungen, Zugangsdienste und Sicherheitsfunktionen klarer voneinander getrennt und zugleich standardisiert zusammenspielen.

Viel technischer Aufwand – wofür eigentlich?

Der Transformationsplan der gematik zielt nicht auf Cloud-Nutzung um ihrer selbst willen. Er soll die TI stabiler, besser überwachbar, skalierbarer und langfristig einfacher weiterentwickelbar machen. Die Abkehr von einer Vielzahl dezentraler Komponenten ermöglicht ein konsistenteres Monitoring über die Betriebsgrenzen einzelner Einrichtungen hinweg. Störungen können dadurch schneller erkannt, eingegrenzt und behoben werden.
Eine cloudbasierte Plattform kann ihre Kapazitäten bedarfsgerechter anpassen. Bei Lastspitzen lassen sich Ressourcen dynamisch bereitstellen, ohne jede einzelne Einrichtung dauerhaft auf die maximale Belastung auslegen zu müssen. Mehrere georedundante Standorte können sich gegenseitig ersetzen. Fällt ein Standort aus, können Dienste – abhängig von der jeweiligen Architektur und dem konkreten Dienst – über einen anderen Standort weiterbetrieben werden.
Diese Redundanz erhöht zusammen mit automatisiertem Betrieb, standardisierten Plattformdiensten und kontinuierlicher Zustandsüberwachung die Ausfallsicherheit. Ein Beispiel für diesen Entwicklungspfad ist bereits heute das TI-Gateway. Für Leistungserbringer soll daraus langfristig ein stabilerer und flexiblerer Zugang zu den TI-Anwendungen entstehen – mit weniger Abhängigkeit von lokaler Hardware und weniger manuellem Betriebsaufwand.

Was bedeutet das für die Praxis?

● Für Praxen, Apotheken, Krankenhäuser und andere Einrichtungen ändert sich nicht alles auf einmal.
● Die bestehende TI 1.0 kann zunächst weiter genutzt werden. Neue Zugangswege und Plattformdienste kommen schrittweise hinzu.
● Für Hersteller und Anbieter ist aber schon heute entscheidend, die eigene Lösung auf die TI 2.0 vorzubereiten.
● Die Cloud ist dabei nicht das Ziel allein, sondern die technische Grundlage für eine modernere, sicherere und flexiblere TI.

Die Zukunft der TI ist souverän, sicher und schrittweise – und sie beginnt nicht erst mit dem Go-Live der Cloud.

Zurück