Managed IT Services für Kliniken: Was in den Vertrag gehört

Ein Managed-Services-Vertrag entscheidet sich nicht am Tag der Unterschrift, sondern in der ersten Störung um drei Uhr nachts: Wer wird alarmiert? Was gilt als Priorität 1? Wann ist das System wiederhergestellt — und wer haftet, wenn nicht? Kliniken, die den Betrieb ihrer IT ganz oder teilweise auslagern, kaufen kein Produkt, sondern ein Versprechen. Wie belastbar dieses Versprechen ist, steht im Vertrag. Dieser Leitfaden zeigt, welche Regelungen hineingehören — und welche Formulierungen sich später rächen.

Was sind Managed IT Services im Klinikumfeld?

Managed IT Services bezeichnen den laufenden Betrieb definierter IT-Systeme durch einen externen Dienstleister mit vertraglich vereinbarten Service-Leveln — im Klinikumfeld typischerweise Monitoring, Störungsbeseitigung, Patch-Management, Backup und Service Desk für klinische und administrative Systeme. Im Unterschied zum klassischen Projektgeschäft wird nicht eine einmalige Leistung geschuldet, sondern ein dauerhafter Zustand: verfügbare, aktuelle und gesicherte Systeme. Genau deshalb sind die Vertragsinhalte wichtiger als bei jedem Einzelprojekt.

Der Leistungsschein: Was genau betrieben wird

Grundlage jedes Managed-Services-Vertrags ist eine präzise Leistungsbeschreibung, meist als Leistungsschein je Servicebaustein:

• Systemliste: Welche Systeme, Server, Anwendungen und Standorte sind umfasst — namentlich, nicht pauschal. Ein „Betrieb der Serverlandschaft” ohne Inventarliste ist im Streitfall wertlos.
• Leistungsabgrenzung: Was ist enthalten (z. B. Störungsbeseitigung, Updates), was ist gesondert zu beauftragen (z. B. Erweiterungen, Projekte, Herstellersupport von Drittsystemen)?
• Mitwirkungspflichten der Klinik: Zugänge, Ansprechpartner, Freigabeprozesse, Informationspflichten bei eigenen Änderungen.
• Schnittstellen zu Dritten: Wer koordiniert Medizintechnik-Hersteller, KIS-Anbieter oder Netzbetreiber, wenn eine Störung mehrere Zuständigkeiten berührt?

Je klarer die Abgrenzung, desto seltener die teuerste aller Diskussionen: „Dafür sind wir nicht zuständig.”

SLA richtig definieren: Reaktionszeit ist nicht Wiederherstellungszeit

Der häufigste Fehler in Service-Level-Vereinbarungen ist die Verwechslung zweier Begriffe:

Für Kliniken kommt eine Besonderheit hinzu: Nicht jedes System ist gleich kritisch. Ein sinnvoller Vertrag klassifiziert Systeme nach Versorgungsrelevanz (etwa: PACS und KIS hochkritisch, Archivrecherche mittel, Testsysteme niedrig) und ordnet jeder Klasse eigene Reaktions- und Wiederherstellungszeiten samt Servicezeiten zu. Ebenso wichtig: eine eindeutige Prioritätendefinition — wer entscheidet im Zweifel, ob eine Störung Priorität 1 ist, und nach welchen Kriterien? Vereinbaren Sie außerdem, welche Folgen SLA-Verletzungen haben (Berichtspflicht, Eskalation, Vertragsstrafen oder Gutschriften) — ein SLA ohne Konsequenz ist eine Absichtserklärung.

Monitoring: Umfang, Alarmierung, Berichtswesen

„Monitoring inklusive” kann alles bedeuten — vom Ping auf den Server bis zur Überwachung von Diensten, Schnittstellen, Speicherfüllständen, Zertifikatslaufzeiten und Backup-Erfolg. In den Vertrag gehören:

• Monitoring-Umfang je System: Was genau wird überwacht (Erreichbarkeit, Dienste, Kapazitäten, Anwendungsfunktion)?
• Alarmierungsketten: Wer wird wann, auf welchem Weg und in welcher Reihenfolge informiert — auch nachts und am Wochenende?
• Proaktive Pflichten: Führt der Dienstleister Kapazitätsprognosen und meldet absehbare Engpässe, oder reagiert er nur auf Ausfälle?
• Berichtswesen: Regelmäßige Service-Reports mit Störungsstatistik, SLA-Erfüllung, Kapazitätstrends — als Grundlage der Service-Review-Termine.

Patch-Management im 24/7-Klinikbetrieb

Patchen im Krankenhaus ist ein Balanceakt zwischen Sicherheitspflicht (§ 75c SGB V verlangt Vorkehrungen nach dem Stand der Technik) und Verfügbarkeitsanspruch. Der Vertrag sollte regeln:

• Patch-Fenster: Feste, mit dem klinischen Betrieb abgestimmte Wartungsfenster je Systemklasse — inklusive Verfahren für Notfall-Patches außerhalb der Fenster bei aktiv ausgenutzten Schwachstellen.
• Test und Freigabe: Werden Patches vor dem Produktivbetrieb getestet? Wer gibt frei?
• Sonderfall Medizinprodukte: Systeme mit Medizinprodukte-Eigenschaft (etwa PACS-Komponenten) dürfen nur im Rahmen der Herstellerfreigaben verändert werden. Der Vertrag muss festlegen, wer Herstellerfreigaben einholt und wie mit Systemen umgegangen wird, für die kein Patch freigegeben ist (kompensierende Isolation).
• Dokumentation: Nachvollziehbare Patch-Historie je System — auch als Nachweis gegenüber Prüfern.

Backup ist nichts ohne Restore-Test

Die Backup-Klausel ist die wichtigste Versicherungspolice des Vertrags — und die am häufigsten unpräzise formulierte:

1. RPO und RTO je Systemklasse: Wie viel Datenverlust ist maximal hinnehmbar (Recovery Point Objective), wie schnell muss wiederhergestellt sein (Recovery Time Objective)? Ohne diese beiden Werte ist „tägliches Backup” keine belastbare Aussage.
2. Angriffsresistente Kopien: Mindestens eine Sicherung offline oder unveränderbar, getrennt von der Produktivumgebung — sonst verschlüsselt Ransomware das Backup gleich mit.
3. Regelmäßige, dokumentierte Restore-Tests: Vereinbaren Sie Intervall, Umfang (Einzeldatei bis kompletter Systemschwenk) und Berichtspflicht. Ein Backup, dessen Wiederherstellung nie geprobt wurde, ist eine Vermutung.
4. Aufbewahrung und Löschung: Sicherungszyklen im Einklang mit den langen medizinischen Aufbewahrungsfristen und den Löschpflichten der DSGVO.

Datenschutz: Auftragsverarbeitung nach Art. 28 DSGVO

Sobald der Dienstleister Zugriff auf Systeme mit Patientendaten hat — und sei es nur im Störungsfall —, liegt eine Auftragsverarbeitung vor. Erforderlich sind:

• ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO mit dokumentierten technischen und organisatorischen Maßnahmen,
• geregelte Subunternehmer-Ketten (Zustimmungsvorbehalt, Informationspflicht bei Wechseln),
• Klarheit über Verarbeitungsorte — insbesondere bei Fernwartung und Cloud-Werkzeugen des Dienstleisters,
• Verschwiegenheits- und Zugriffsregeln für das eingesetzte Personal sowie Protokollierung administrativer Zugriffe.

Die datenschutzrechtliche Verantwortung bleibt bei der Klinik — der Vertrag muss sie in die Lage versetzen, dieser Verantwortung nachzukommen (Auditrechte, Nachweispflichten des Dienstleisters).

Exit-Klauseln: An das Ende denken, bevor es beginnt

Jeder Betriebsvertrag endet irgendwann — durch Kündigung, Neuausschreibung oder Insolvenz. Regeln Sie den Ausstieg bei Vertragsschluss:

• Herausgabepflichten: Vollständige Übergabe von Dokumentation, Konfigurationen, Passwörtern und Betriebshandbüchern in verwertbarer Form.
• Mitwirkung bei der Transition: Unterstützung bei der Überleitung auf einen Nachfolger oder die eigene IT, mit definiertem Zeitraum und Vergütungsmodell.
• Datenrückgabe und -löschung: Nachweisliche Löschung beim Dienstleister nach erfolgreicher Übergabe.
• Weiterbetrieb während der Übergangsphase: SLA gelten bis zum letzten Tag — nicht nur bis zur Kündigung.

Checkliste für die Vertragsprüfung

1. Leistungsschein mit namentlicher Systemliste und klarer Abgrenzung vorhanden?
2. Reaktions- und Wiederherstellungszeiten je Systemklasse vereinbart, mit Servicezeiten und Konsequenzen bei Verletzung?
3. Monitoring-Umfang, Alarmierungsketten und Berichtswesen definiert?
4. Patch-Fenster, Notfall-Patch-Verfahren und Umgang mit Medizinprodukte-Freigaben geregelt?
5. RPO/RTO, angriffsresistente Backup-Kopien und dokumentierte Restore-Tests vereinbart?
6. AVV nach Art. 28 DSGVO inklusive Subunternehmerregelung geschlossen?
7. Exit-Klauseln mit Herausgabe-, Mitwirkungs- und Löschpflichten enthalten?

Häufige Fragen

Brauchen wir 24/7-Service für alle Systeme?

Nein — aber für die richtigen. Sinnvoll ist eine Klassifizierung nach Versorgungsrelevanz: Systeme, deren Ausfall die Patientenversorgung unmittelbar beeinträchtigt, brauchen 24/7-Servicezeiten mit kurzen Wiederherstellungszeiten; für nachgelagerte Systeme genügen oft Business Hours. Das hält den Vertrag bezahlbar, ohne die kritischen Prozesse zu gefährden.

Bleibt die Klinik trotz Auslagerung verantwortlich?

Ja. Sowohl die Pflichten zur IT-Sicherheit (§ 75c SGB V) als auch die datenschutzrechtliche Verantwortung verbleiben bei der Einrichtung. Der Vertrag verlagert die operative Durchführung — nicht die Verantwortung. Deshalb sind Berichtspflichten, Auditrechte und Nachweise des Dienstleisters kein Misstrauen, sondern Pflichterfüllung.

Was unterscheidet einen guten von einem schlechten Managed-Services-Vertrag?

Ein guter Vertrag ist im Störungsfall eine Betriebsanleitung: Er beantwortet ohne Interpretationsspielraum, wer was bis wann tut. Ein schlechter Vertrag ist eine Beschreibung guter Absichten. Der Test: Lesen Sie den Vertrag aus der Perspektive eines Priorität-1-Ausfalls am Sonntagmorgen — bleibt eine Frage offen, gehört sie hinein.

Fazit

Managed IT Services entlasten Klinik-IT wirksam — wenn der Vertrag das Betriebsversprechen präzise macht: benannte Systeme, echte Wiederherstellungszeiten, geregelte Patch-Fenster, getestete Backups, sauberer Datenschutz und ein geordneter Ausstieg. Wer diese Punkte vor der Unterschrift klärt, bekommt einen Partner statt eines Lieferanten.

easequence betreibt klinische IT mit Managed IT Services auf Basis klar definierter Service-Level — von Monitoring über Patch-Management bis zum 24/7 Service Desk — und ergänzt sie bei Bedarf um IT-Security-Leistungen. Für eine Bestandsaufnahme Ihrer Betriebsorganisation eignet sich der Workflow Check.