RTO und RPO im Krankenhaus einfach erklärt – mit Rechenbeispiel

Kaum ein Dokument zur IT-Sicherheit kommt ohne sie aus: RTO und RPO. Zwei Abkürzungen, die in Service Level Agreements, Notfallkonzepten und KRITIS-Unterlagen auftauchen und oft nur halb verstanden werden. Dabei sind sie im Kern einfach – und sie beantworten zwei sehr praktische Fragen, die jedes Krankenhaus für seine Systeme kennen sollte.

Dieser Beitrag erklärt beide Begriffe ohne Fachjargon und rechnet sie an einem konkreten Klinik-Beispiel durch.

Die zwei Fragen hinter RTO und RPO

Stellen Sie sich vor, ein wichtiges System fällt aus. Sofort stellen sich zwei Fragen:

1. Wie lange dürfen wir ohne das System auskommen, bis es wieder laufen muss?

2. Wie viel von unseren zuletzt erfassten Daten dürfen wir dabei verlieren?

Die erste Frage betrifft die Zeit. Die zweite betrifft die Daten. Genau diese beiden Dimensionen fassen RTO und RPO in Kennzahlen.

RTO – Recovery Time Objective

Die RTO ist die maximal tolerierbare Ausfalldauer. Sie beantwortet die Frage: Wie schnell muss ein ausgefallenes System wieder verfügbar sein?

Eine RTO von vier Stunden bedeutet: Ab dem Moment des Ausfalls darf es höchstens vier Stunden dauern, bis das System (oder ein tragfähiger Ersatz) wieder nutzbar ist. Alles darüber gilt als nicht mehr akzeptabel.

RPO – Recovery Point Objective

Die RPO ist der maximal tolerierbare Datenverlust, gemessen in Zeit. Sie beantwortet die Frage: Auf welchen Datenstand können wir schlimmstenfalls zurückfallen?

Eine RPO von 15 Minuten bedeutet: Im schlimmsten Fall dürfen die Daten der letzten 15 Minuten vor dem Ausfall verloren gehen – aber nicht mehr. Praktisch hängt die RPO davon ab, wie häufig Daten gesichert oder gespiegelt werden.

Eine Merkhilfe

• RTO blickt nach vorne: Wie lange bis zurück im Betrieb? → Zeit ohne System.

• RPO blickt nach hinten: Bis zu welchem Punkt sind die Daten sicher? → verlorene Zeit an Daten.

Das Rechenbeispiel: KIS-Ausfall auf einer Station

Nehmen wir eine Klinik, die für ihr Notfallkonzept Zielwerte festlegt. Für den Zugriff auf behandlungsrelevante Daten im Fall eines KIS-Ausfalls definiert sie:

• RTO = 30 Minuten. Spätestens eine halbe Stunde nach Ausfall des KIS muss das Behandlungsteam wieder Lesezugriff auf die klinisch relevanten Daten haben.

• RPO = so aktuell wie möglich. Der verfügbare Datenstand soll dem letzten Stand vor dem Ausfall entsprechen.

Was heißt das konkret?

Zur RTO: Ein System, das erst nach dem Wiederanlauf des KIS bereitsteht, verfehlt die RTO zwangsläufig – denn der Wiederanlauf des KIS kann Stunden oder Tage dauern. Um eine RTO von 30 Minuten zu halten, muss der Zugriff auf die Daten unabhängig vom KIS bestehen bleiben. Eine offlinefähige, lokal vorgehaltene Spiegelung erfüllt das: Sie ist im Moment des Ausfalls bereits da und muss nicht erst wiederhergestellt werden.

Zur RPO: Hier kommt die Art der Datenübertragung ins Spiel. Wird die Spiegelung ereignisbasiert aktualisiert – also bei jedem relevanten Vorgang wie Aufnahme, Entlassung, neuer Verordnung oder eingehendem Befund –, dann entspricht der verfügbare Stand dem letzten erfolgreich empfangenen Ereignis vor dem Ausfall. Die RPO ist damit sehr niedrig, aber nicht null: Daten, die im KIS unmittelbar vor dem Ausfall erfasst, aber nicht mehr übertragen wurden, fehlen.

Diese Ehrlichkeit ist wichtig. Kein Fallback-System kann garantieren, dass es die allerletzte Sekunde vor dem Ausfall noch abgebildet hat. Die entscheidende Frage ist, wie klein diese Lücke ist – und ob das Behandlungsteam weiß, dass sie existiert.

Warum die Werte eine bewusste Entscheidung sind

RTO und RPO sind keine technischen Konstanten, sondern Entscheidungen des Krankenhauses. Ein niedrigerer Zielwert bedeutet mehr Schutz, aber auch mehr Aufwand und Kosten. Ein Haus, das für den KIS-Ausfall eine RTO von 30 Minuten fordert, trifft eine andere Investitionsentscheidung als eines, das mit vier Stunden Papierbetrieb leben kann.

Diese Zielwerte sollten deshalb nicht in der IT allein festgelegt werden, sondern gemeinsam mit den klinischen Verantwortlichen – denn sie beschreiben letztlich, wie lange und mit welchem Informationsstand die Patientenversorgung im Ausfall weiterlaufen soll.

Der Bezug zum Notfallsystem

Für ein Resilienz- und Fallback-System sind RTO und RPO die Kennzahlen, an denen sich sein Nutzen messen lässt:

• Eine niedrige RTO erreicht man durch Offlinefähigkeit – die Daten sind lokal vorhanden und im Ausfall sofort verfügbar, statt erst wiederhergestellt werden zu müssen.

• Eine niedrige RPO erreicht man durch ereignisbasierte Spiegelung – der Datenbestand ist so aktuell wie die letzte erfolgreich empfangene Nachricht.

Genau nach diesem Prinzip arbeitet TrioMed: eine schreibgeschützte, ereignisbasiert aktualisierte Spiegelung der klinisch relevanten Daten, lokal und offlinefähig vorgehalten. Die konkreten Zielwerte für Verfügbarkeit, RTO und RPO werden dabei mit dem jeweiligen Haus abgestimmt und in einem Service Level Agreement festgehalten.

Wer RTO und RPO für seine kritischen Systeme sauber definiert, hat den ersten und wichtigsten Schritt zu einem belastbaren Notfallkonzept getan – lange bevor über konkrete Produkte gesprochen wird.

Wie sich verschiedene Lösungsansätze – Papier, Sekundär-KIS und Fallback-System – bei genau diesen Kennzahlen unterscheiden, zeigt unser Vergleichsbeitrag.