Netzwerk-Architektur mit Cloud-Konnektor: Redundanz und Ausfallsicherheit in der Arztpraxis

Was "Cloud-Konnektor" in der aktuellen TI-Architektur bedeutet

Ein Cloud-Konnektor ist kein Gerät in der Praxis, sondern ein TI-Zugang aus dem Rechenzentrum. In der heutigen gematik-Architektur wird er als TI-Gateway umgesetzt: Die Praxis verbindet sich per gesichertem VPN mit einem Rechenzentrum, in dem ein zugelassener Highspeed-Konnektor den Zugang zur Telematikinfrastruktur für viele Einrichtungen gleichzeitig übernimmt.

Der klassische Einbox-Konnektor saß als dedizierte Hardware im Serverschrank und baute von dort den TI-Tunnel auf. Beim TI-Gateway fällt genau dieses Gerät weg. An seine Stelle tritt ein Highspeed-Konnektor (HSK), den die gematik als "skalierbare TI-Zugangskomponente für den Betrieb in leistungsfähigen IT-Umgebungen" beschreibt. Er läuft auf Standard-Hardware im Rechenzentrum und kann, in Verbindung mit dem TI-Gateway, als zentrale, hochverfügbare Instanz betrieben werden. Ein einziger HSK kann eine große Einrichtung oder viele kleine Praxen versorgen und ersetzt damit zahlreiche physische Konnektoren.

Für die Praxis ändert sich damit die gesamte Netzwerk-Architektur. Es gibt keine lokale Konnektor-Box mehr, die altern, überhitzen oder nach einem Stromausfall nicht sauber hochfahren kann. Die Frage "Was passiert, wenn die Hardware stirbt?" verschiebt sich vom Serverschrank der Praxis ins Rechenzentrum des Anbieters, der dort professionelle Redundanz betreiben kann.

Quelle: gematik Fachportal: Highspeed-KonnektorBeschreibung von HSK und TI-Gateway als zentrale, hochverfügbare Instanz. Stand: 2026-11-09.

Warum die zentrale Lösung die Ausfallsicherheit erhöht

Der größte Gewinn liegt in der geografischen und technischen Redundanz, die ein Rechenzentrum bietet und eine einzelne Praxis niemals wirtschaftlich darstellen könnte. Der Highspeed-Konnektor läuft als hochverfügbare Instanz, typischerweise mit gespiegelten Systemen, unterbrechungsfreier Stromversorgung und oft über mehrere Standorte verteilt. Fällt eine Komponente aus, übernimmt eine andere.

In der Praxis bedeutet das: Kein Gerät mehr, das nach drei Jahren Dauerbetrieb im warmen Technikraum ausfällt. Keine Lieferzeit von Tagen für ein Ersatzgerät. Keine Vor-Ort-Fahrt, nur weil der Konnektor nach einem Update hängt. Updates und Wartung laufen zentral beim Anbieter, und zwar für alle angebundenen Praxen gleichzeitig. Die operative Verantwortung für den Konnektor-Betrieb liegt vertraglich beim Anbieter, nicht mehr bei der Praxis.

Dass die alte Hardware-Generation ein echtes Problem war, zeigt die Historie: Nur RSA-fähige Konnektoren der ersten Generation sind seit dem 1. Januar 2026 nicht mehr einsetzbar. Wer bis heute auf einem solchen Altgerät saß, musste ohnehin migrieren, und der Weg ins Rechenzentrum ist für viele Praxen dabei die zukunftssichere Variante.

Die gematik hat den Zugangsweg bewusst breit aufgestellt. Zugelassen sind inzwischen mehrere Anbieter, darunter RISE, akquinet, eHealth Experts, secunet, CGI, DGN, Telekom (TI-Connect) und CGM. Die Zulassungen der Highspeed-Konnektoren selbst laufen je nach Hersteller bis April bis September 2028 (RISE) beziehungsweise bis Juni 2028 (secunet, KoCo, eHealth Experts).

Quelle: gematik Fachportalgematik: Zulassungs- und Bestätigungsübersichten, Produkte, Dienste und Anbieter. Stand: 2026-11-09.

Der Haken: Die Internetleitung wird zum Einzelpunkt

Die wichtigste Wahrheit zuerst: Ein Cloud-Konnektor beseitigt das Hardware-Risiko in der Praxis, erzeugt aber ein neues, zentrales Risiko. Weil der Konnektor im Rechenzentrum sitzt, läuft jede TI-Anwendung über die Internetleitung der Praxis. Fällt diese Leitung aus, steht die komplette TI, eRezept, eAU und ePA-Zugriff inklusive.

Beim alten lokalen Konnektor war das anders: Interne TI-Funktionen liefen auch bei wackeligem Internet weiter, weil der Tunnel vom Gerät in der Praxis aufgebaut wurde. Beim TI-Gateway gibt es diesen lokalen Rückzugsraum nicht mehr. Die WAN-Anbindung ist nicht mehr nur "wichtig", sie ist systemkritisch.

Genau hier entscheidet sich, ob ein Cloud-Konnektor wirklich mehr Ausfallsicherheit bringt oder das Risiko nur verschiebt. Eine Praxis mit einer einzigen DSL-Leitung, die zweimal im Monat für zehn Minuten weg ist, hat mit einem RZ-Konnektor nichts gewonnen. Sie hat die ausfallsichere Hardware im Rechenzentrum, aber einen fragilen einzigen Weg dorthin.

So sieht die redundante Netzwerk-Architektur konkret aus

Echte Ausfallsicherheit mit einem Cloud-Konnektor entsteht aus drei Schichten: Redundanz im Rechenzentrum (die liefert der Anbieter), Redundanz der Internetanbindung am Standort (die muss die Praxis bauen) und ein geübtes Ersatzverfahren für den Rest. Fehlt eine Schicht, bleibt eine Lücke.

Die mittlere Schicht ist die, um die sich in der Praxis alles dreht. Jeder Standort braucht mindestens zwei getrennte Wege ins Netz. Erste Wahl ist eine Glasfaser- oder VDSL-Leitung, zweite Wahl ein LTE- oder 5G-Fallback über einen Router mit Dual-WAN-Unterstützung. Dieser überwacht die Primärleitung dauerhaft und schaltet bei Ausfall innerhalb weniger Sekunden auf Mobilfunk um, ohne dass jemand eingreift.

1. 1
   Primärleitung bestimmen
   Glasfaser oder gutes VDSL als Hauptleitung. Symmetrische Bandbreite ist für die TI zweitrangig, Stabilität und geringe Latenz sind wichtiger als Spitzen-Durchsatz. 25 bis 50 Mbit/s reichen für reine TI-Nutzung meist deutlich aus.
2. 2
   Unabhängigen Fallback wählen
   LTE oder 5G über einen anderen physischen Weg als die Primärleitung. Entscheidend ist die Trennung: Ein Mobilfunk-Fallback, der über denselben Hausanschluss oder dieselbe Backbone-Trasse läuft, ist keine echte Redundanz.
3. 3
   Dual-WAN-Router mit Failover einrichten
   Der Router überwacht beide Leitungen und schaltet automatisch um. Failover-Zeit und Prüfintervall sauber konfigurieren, damit kurze Aussetzer der Primärleitung nicht zu Dauer-Umschaltungen führen.
4. 4
   VPN-Tunnel zum TI-Gateway über beide Wege testen
   Der VPN-Zugang zum Rechenzentrum muss über Glasfaser und über LTE funktionieren. Einmal real durchspielen: Primärleitung ziehen, prüfen, ob eRezept und eAU über den Fallback weiterlaufen.
5. 5
   Monitoring und Alarmierung aktivieren
   Die Praxis oder der IT-Dienstleister muss sehen, wenn die Primärleitung weg ist und der Fallback aktiv wurde. Sonst läuft die Praxis wochenlang auf teurem LTE, ohne es zu merken, bis das Datenvolumen aufgebraucht ist.

Die dritte Schicht, das Ersatzverfahren, bleibt trotz aller Redundanz Pflicht. Für den seltenen Fall, dass beide Internetwege gleichzeitig ausfallen oder eine zentrale TI-Störung vorliegt, muss das Team wissen, wie eRezept und eAU übergangsweise ohne TI ablaufen. Das gehört geübt, nicht erst im Ernstfall nachgelesen. Eine praktische Soforthilfe für den Konnektor-Ausfall haben wir separat zusammengestellt: Konnektor offline, was jetzt?.

Lokaler Konnektor gegen Cloud-Konnektor unter dem Redundanz-Blick

Betrachtet man beide Varianten nicht pauschal, sondern allein unter dem Gesichtspunkt Ausfallsicherheit, verschieben sich die Argumente deutlich. Der lokale Konnektor schützt vor Internet-Ausfällen bei internen Funktionen, trägt aber das volle Hardware-Risiko in der Praxis. Der Cloud-Konnektor dreht das Verhältnis genau um.

Die Lehre daraus: Der Cloud-Konnektor ist die ausfallsicherere Architektur, aber nur für Praxen, die die WAN-Redundanz ernst nehmen. Wer ohnehin schon mit zwei Internetleitungen arbeitet, etwa im Mehrstandort-Betrieb, gewinnt doppelt. Wer auf einer einzigen schwachen Leitung sitzt, sollte erst die Leitung sanieren und dann migrieren.

Mehrstandort-Praxen und MVZ: der eigentliche Hebel

Für Praxen mit mehreren Betriebsstätten spielt der Cloud-Konnektor seine Stärke am deutlichsten aus. Statt an jedem Standort ein eigenes Konnektor-Gerät zu betreiben, zu warten und zu überwachen, laufen alle Standorte über den zentralen Highspeed-Konnektor im Rechenzentrum. Das reduziert Hardware, Wartungsfahrten und Konfigurationsaufwand spürbar.

Der Preis bleibt derselbe wie bei der Einzelpraxis, nur multipliziert: Jeder einzelne Standort braucht seine eigene redundante Internetanbindung. Ein zentraler, hochverfügbarer Konnektor nützt wenig, wenn Standort C über eine einzige störanfällige Leitung angebunden ist. Die Kette ist so stark wie ihr schwächstes Glied, und bei verteilten Praxen gibt es mehr Glieder.

In der Architektur bedeutet das: zentraler TI-Zugang über das Gateway, dezentrale WAN-Redundanz an jedem Standort, und idealerweise ein einheitliches Monitoring, das alle Standorte und ihre Fallback-Zustände auf einen Blick zeigt. Wie die übergeordnete Vernetzung dafür aussieht, behandeln wir ausführlich unter Mehrstandort-Praxis vernetzen und für den MVZ-Kontext unter MVZ-IT-Architektur.

Wo auch die zentrale Architektur Grenzen hat

So robust ein Rechenzentrum ist, es gibt eine ehrliche Kehrseite: Eine zentrale Architektur bündelt viele Praxen hinter einem Anbieter und einer gematik-Infrastruktur. Wenn es dort klemmt, sind nicht einzelne Praxen betroffen, sondern potenziell viele gleichzeitig. Redundanz im RZ schützt vor Einzelausfällen, nicht automatisch vor systemischen Störungen.

Das ist keine Theorie. Am 12. Oktober 2026 kam es bei VPN-Verbindungen von Rise- und secunet-Konnektoren zu einer TI-Störung, die über Updates für die betroffenen Konnektoren behoben wurde. Solche Ereignisse sind selten, aber sie zeigen, dass auch die professionellste zentrale Lösung keine Garantie auf hundertprozentige Verfügbarkeit gibt. Genau deshalb bleibt das Ersatzverfahren Pflicht und gehört die Störungshistorie eines Anbieters in die Auswahl.

Für die Vertragsgestaltung heißt das konkret: Fragen Sie nach dem Redundanzkonzept (gespiegelte Systeme, mehrere RZ-Standorte), nach dem Service Level (garantierte Verfügbarkeit, Reaktionszeiten bei Störungen) und nach der dokumentierten Störungshistorie. Ein Anbieter, der diese Fragen souverän beantwortet, hat seine Hausaufgaben gemacht. Ein Anbieter, der ausweicht, ist ein Risiko.

Quelle: gematik Newsroom: Beeinträchtigungen bei der Verbindung zur TIHinweise der gematik zu TI-Störungen. Stand: 2026-11-09.

Kosten und Refinanzierung

Die laufenden Kosten für den TI-Betrieb, und damit auch für einen Cloud-Konnektor, werden über die TI-Pauschale der Kassenärztlichen Vereinigung refinanziert. Sie deckt Anschluss und Betrieb der TI pauschal ab und ist zum 1. Januar 2026 um 2,8 Prozent gestiegen. Die Höhe staffelt sich nach Praxisgröße.

Die TI-Pauschale deckt die TI-Betriebskosten ab, nicht jedoch die zusätzliche WAN-Redundanz. Der LTE-Fallback und der Dual-WAN-Router sind eine eigene Investition, gemessen am Schaden eines mehrstündigen Praxisstillstands aber eine sehr überschaubare. Wie hoch dieser Schaden ausfällt, haben wir unter IT-Ausfallkosten in der Arztpraxis durchgerechnet.

Quelle: GKV-Spitzenverband: Telematikinfrastruktur und TI-FinanzierungGKV-Spitzenverband: Telematikinfrastruktur und TI-Finanzierung. Grundlage der TI-Pauschale. Stand: 2026-11-09.

Quelle: KBV: TI-Pauschale um 2,8 Prozent gestiegen (Januar 2026)Aktuelle Staffelung der monatlichen TI-Pauschale. Stand: 2026-11-09.

ITCC unterstützt bei Architektur und Umstellung

Die Entscheidung für einen Cloud-Konnektor ist keine Produktfrage, sondern eine Architekturfrage. Entscheidend ist nicht, welchen Anbieter Sie wählen, sondern ob der Weg ins Rechenzentrum so redundant ist, dass die zentrale Hochverfügbarkeit in der Praxis überhaupt ankommt.

ITCC betreut Arztpraxen, MVZ und Praxisnetze in der Pfalz, der Metropolregion Rhein-Neckar und im Rhein-Main-Raum. Vor einer Umstellung auf das TI-Gateway messen wir die Leitungsqualität am Standort, prüfen die PVS-Kompatibilität, planen die redundante Anbindung mit Dual-WAN und Fallback und richten das Monitoring ein. Die eigentliche Umschaltung legen wir außerhalb der Sprechzeiten, mit Funktionstest aller TI-Anwendungen, bevor der alte Konnektor außer Betrieb geht.

Wenn Sie nicht sicher sind, ob Ihre aktuelle Internetanbindung einen Cloud-Konnektor trägt, oder ob sich die Umstellung für Ihre Standortstruktur lohnt: Wir analysieren die Infrastruktur und geben eine konkrete Empfehlung, inklusive ehrlicher Ansage, wenn erst die Leitung an die Reihe muss.