Cloud oder On-Premise? Die falsche Frage für die richtige Entscheidung

In Fachgesprächen mit IT-Verantwortlichen, Einkaufsleitungen und Logistikern im Krankenhaus über digitale Lösungen steht häufig eine Grundsatzfrage im Raum: Cloud oder On-Premise? Dabei konzentriert sich die Diskussion in der Regel rasch auf den physischen Standort des Servers.

On-Premise wird vielfach mit Kontrolle und Datenschutz assoziiert, Cloud mit Flexibilität, aber auch mit potenziellen Abhängigkeiten. Die Entscheidung über das Betriebsmodell umfasst jedoch mehr als den reinen Speicherort von Programmen und Daten. Wesentliche Kriterien sind:

• Wer übernimmt den Betrieb und die kontinuierliche Überwachung der Infrastruktur?
• Wer schließt Sicherheitslücken und führt notwendige Patches durch?
• Wie werden Datensicherungen und Wiederherstellungsszenarien gewährleistet?
• In welchem Zeitrahmen lassen sich funktionale Anpassungen oder neue Standorte integrieren?
• Welche internen IT-Ressourcen werden dauerhaft gebunden, und welche Gesamtkosten entstehen über den gesamten Lebenszyklus?

Die zentrale Frage für IT-Verantwortliche, kaufmännische Leitung und Fachbereiche lautet daher nicht „Wo steht der Server?“, sondern: Über welches Modell kann der benötigte IT-Service langfristig sicher, zuverlässig und wirtschaftlich bereitgestellt werden – bezogen auf die konkrete Anwendung?

Nicht jede Krankenhaussoftware ist gleich kritisch

In Beschaffungsprozessen werden unterschiedliche Softwaresysteme teils nach einheitlichen Maximalkriterien bewertet. Ein Krankenhausinformationssystem (KIS) oder ein Bildarchivierungssystem (PACS) weist jedoch ein anderes Risikoprofil auf als eine Software für Materialwirtschaft, Stationslogistik oder Gebäudemanagement. Drei Kriterien bestimmen die Anforderungen im Einzelfall:

• Sicherheitsbasis (anwendungsunabhängig): Authentifizierung, Verschlüsselung bei Übertragung und Speicherung, Patchmanagement, Backup/Recovery, Monitoring, Rollen- und Berechtigungskonzepte sowie Incident Management. Die ENISA betont in ihren 2026 aktualisierten Beschaffungsleitlinien für Krankenhäuser, dass Cybersecurity über den gesamten Lebenszyklus eines Systems hinweg zu berücksichtigen ist.
• Schutzbedarf der Daten: Personenbezogene Patienten-, Diagnose- und Behandlungsdaten unterliegen spezifischen gesetzlichen Schutzvorschriften. Rein logistische Daten wie Artikelnummern, Lagerorte, Mindestbestände oder Stammdaten weisen eine andere Sensitivität auf.
• Kritikalität des Prozesses: Die Auswirkungen eines Systemausfalls unterscheiden sich nach Fachbereich. Bei patientennahen Kernprozessen können kurze Ausfallzeiten kritisch sein; in der Versorgungs- und Stationslogistik lassen sich Unterbrechungen durch definierte Notfallroutinen und physische Pufferbestände meist organisatorisch überbrücken.

Eine Differenzierung nach Kritikalität bedeutet kein Absenken von Basissicherheitsstandards. Sie ermöglicht es jedoch, Anforderungen an Schutzbedarf und Ausfallsicherheit an den tatsächlichen Anwendungsfall anzupassen und Entscheidungen über Betriebsmodelle sachgerecht zu treffen.

Zwei Begriffe, viele Zwischenstufen

Bei einer On-Premise-Lösung wird die Software auf einer bereitgestellten Infrastruktur betrieben, in der Regel im krankenhafteigenen Rechenzentrum oder bei einem Dienstleister. Dies ermöglicht direkten Einfluss auf die Netzwerkarchitektur und Release-Zyklen, bedeutet jedoch auch die operative Betriebsverantwortung.

Bei Software-as-a-Service (SaaS) übernimmt der Softwareanbieter den technischen Betrieb, die Pflege der Plattform und die Skalierung. Dazwischen existieren weitere Varianten wie Private Cloud, Sovereign Cloud, Managed Hosting, IaaS, PaaS sowie hybride Modelle. In der Praxis handelt es sich selten um eine reine Schwarz-Weiß-Entscheidung.

Der regulatorische Rahmen bewegt sich

Die Zurückhaltung gegenüber Cloud-Technologien im deutschen Gesundheitswesen basierte auf strengen Datenschutzvorgaben, dem Schutz von Patientendaten und regulatorischer Unsicherheit. Dieser rechtliche Rahmen hat sich in den vergangenen Jahren weiterentwickelt:

• § 393 SGB V: Regelt seit 2024 die rechtlichen Bedingungen für die Verarbeitung von Sozial- und Gesundheitsdaten in Cloud-Umgebungen – einschließlich Vorgaben zum Verarbeitungsort (EWR/EU) und zum Nachweis eines BSI-C5-Testats (seit Juli 2025 Typ 2).
• Digitalisierungsstrategie des BMG: Die 2026 aktualisierte Strategie „Gemeinsam Digital 2026“ des Bundesministeriums für Gesundheit formuliert Zielsetzungen zur Nutzung standardisierter Cloud-Dienste, unter anderem im Kontext des Europäischen Gesundheitsdatenraums (EHDS).
• Einordnung des BSI: Das Bundesamt für Sicherheit in der Informationstechnik stuft Cloud Computing als etablierten Standard für IT-Dienste ein und verweist auf Skalierungs- und Sicherheitsmerkmale professioneller Cloud-Infrastrukturen.

Wichtig für die Praxis: Nicht jede Software im Krankenhaus verarbeitet Sozial- oder Gesundheitsdaten im Sinne von § 393 SGB V. Für reine Logistik- und Materialdaten greifen die allgemeinen datenschutzrechtlichen Vorgaben (DSGVO), was eine risikobasierte Bewertung des jeweiligen Systems erfordert.

Sieben Dimensionen, die den Unterschied ausmachen

1. Kontrolle vs. Skalierbarkeit & interne Ressourcen

On-Premise ermöglicht der IT-Leitung die direkte Kontrolle über Hardware, Netzwerk und Update-Zeitpunkte. Dies bedingt internen Aufwand für Kapazitätsplanung, Serverwartung, Patching und Monitoring. Ein wesentliches Merkmal von Cloud-Diensten ist demgegenüber die automatisierte und flexible Skalierung von Rechenleistung. Eine 2024 in npj Digital Medicine publizierte Untersuchung im deutschen Kliniksektor belegt, dass eine schrittweise Integration von Cloud-Komponenten neben bestehenden Systemen möglich ist.

2. Sicherheit ist keine reine Standortfrage

Der physische Standort eines Servers ist allein kein Beleg für ein bestimmtes Sicherheitsniveau. Maßgeblich sind vielmehr Maßnahmen wie Patchmanagement, Identitäts- und Rechtestrukturen, Netzwerksegmentierung und Incident-Response-Prozesse. Wie die ENISA darlegt, verfügen spezialisierte Rechenzentrumsbetreiber häufig über umfangreichere personelle und technische Ressourcen zur Absicherung als einzelne IT-Abteilungen, müssen jedoch Cloud-spezifische Risiken über technische und vertragliche Vereinbarungen adressieren.

3. Verantwortung im laufenden Betrieb

Der Betrieb eines On-Premise-Systems bindet Personal für Betriebssystem-Updates, Datenbankwartung und Datensicherungen. Bei SaaS-Modellen liegen diese Aufgaben beim Anbieter. Die Aufgaben der internen IT-Abteilung verschieben sich in diesem Fall von der Infrastrukturverwaltung hin zu Schnittstellenintegration, Konfigurationsmanagement und Dienstleistersteuerung. Dieser Übergang wird unter anderem in Projekten wie der Sovereign-Cloud-Initiative der Sana Kliniken mit STACKIT und Deloitte sichtbar.

4. Kostenvergleich: Total Cost of Ownership (TCO)

Die Annahme, On-Premise erfordere nur eine Einmalinvestition und Cloud laufende Zahlungen, greift rechnerisch zu kurz. On-Premise-Lösungen verursachen laufende Kosten für Softwarepflege (branchenüblich 20 bis 24 % der Lizenzkosten pro Jahr), Infrastruktur-Reinvestitionen, Energie, Backup-Systeme und interne Personalkapazitäten.

Der Unterschied liegt primär in der Kostendarstellung: SaaS-Kosten fallen als planbare Betriebsaufwände (OPEX) transparent monatlich oder jährlich an. On-Premise-Kosten verteilen sich auf Investitionen (CAPEX) und indirekte Kostenstellen. Für eine wirtschaftliche Bewertung ist eine TCO-Betrachtung über einen Zeitraum von fünf bis sieben Jahren sachgerecht.

5. Einführungszeitraum (Time-to-Value)

Bei On-Premise-Projekten müssen Vorbereitungen wie Hardwarebeschaffung, Systemintegration und Datenbankeinrichtung abgeschlossen sein, bevor Anwender auf das System zugreifen können. Bei SaaS-Lösungen steht die Betriebsumgebung ab Beginn zur Verfügung, wodurch sich Projektressourcen primär auf Schnittstellen, Stammdaten und Schulungen konzentrieren können. Auch NHS England führt kürzere Bereitstellungszeiten als Grund für die Prüfung von Cloud-Modellen an.

6. Updates: Individuelle Steuerung vs. kontinuierliche Weiterentwicklung

On-Premise erlaubt es, Updates und Versionswechsel manuell zu steuern und zu terminieren, was teils mit manuellem Testaufwand verbunden ist. SaaS-Lösungen werden zumeist kontinuierlich und zentral aktualisiert. Für stark angepasste klinische Primärsysteme kann eine manuelle Steuerung gefordert sein, während für standardisierte funktionale Prozesse die kontinuierliche Aktualisierung ressourcenschonender ist.

7. Herstellerabhängigkeit (Vendor Lock-in)

Abhängigkeiten können in beiden Betriebsmodellen entstehen. Bei On-Premise resultieren sie häufig aus proprietären Datenstrukturen, spezifischen Datenbankanforderungen oder Systemkenntnissen einzelner Personen. Bei SaaS stehen Service Level Agreements, Datenexportformate und Exit-Strategien im Vordergrund. Interoperabilität und standardisierte Schnittstellen sind unabhängig vom gewählten Modell relevant.

Kostenvergleich über den Lebenszyklus (TCO)

Ein realistischer Kostenvergleich stellt die einmaligen Lizenzkosten einer On-Premise-Lösung den periodischen Beiträgen einer SaaS-Lösung über denselben Zeitraum (fünf bis sieben Jahre) gegenüber.

Was das für digitale Materialversorgung bedeutet

Relevanz für die digitale Materialwirtschaft

Die Differenzierung nach Schutzbedarf und Kritikalität zeigt sich im Bereich der Materialversorgung:

1. Keine Behandlungsdaten: MOYAFLOW verarbeitet Artikel- und Materialstammdaten, Lagerorte, Bestände und interne Nachbestellungen – jedoch keine Patientendaten oder Diagnosen.
2. Abgrenzung des Risikoprofils: Eine Software für Versorgungslogistik erfordert eine hohe Verfügbarkeit. Bei kurzzeitigen Systemunterbrechungen greifen im Stationsbereich jedoch vorhandene Sicherheitsbestände und organisatorische Abläufe, sodass der Versorgungsbetrieb aufrechterhalten bleibt.
3. Auswirkungen auf IT-Ressourcen: Der Einsatz cloudbasierter Fachsoftware ermöglicht es Fachbereichen, funktionale Anforderungen umzusetzen, ohne dass dafür zusätzliche Serverkapazitäten intern bereitgestellt werden müssen.

MOYAFLOW wird als SaaS-Lösung in deutschen Rechenzentren (Hetzner) betrieben, die über ein BSI-C5:2020-Typ-2-Testat verfügen. Damit erfüllt die technische Basis die Anforderungen, die § 393 SGB V für die Verarbeitung von Sozial- und Gesundheitsdaten vorsieht, auch wenn im System primär logistische Daten verarbeitet werden. Neue Stationen oder Standorte können ohne lokale Serverinstallationen in das System eingebunden werden.

Fazit: Kriterienbasierte Entscheidung statt pauschaler Standortwahl

Weder Cloud- noch On-Premise-Lösungen sind per se überlegen. Eine fundierte IT-Architekturentscheidung im Krankenhaus orientiert sich an einer klaren Prüfreihenfolge:

1. Etablierung definierter IT-Sicherheitsstandards als Basis.
2. Bestimmung des tatsächlichen Schutzbedarfs der verarbeiteten Daten (Patienten- vs. Logistikdaten).
3. Bewertung der Kritikalität des jeweiligen Prozesses bei Ausfällen.
4. Auswahl des Betriebsmodells auf Basis von Gesamtkosten (TCO), Betriebsaufwand und IT-Ressourcen.

Der regulatorische Rahmen im deutschen Gesundheitswesen eröffnet differenzierte Einsatzmöglichkeiten für Cloud-Dienste. Die Leitfrage lautet daher: Welche Daten werden verarbeitet, wie kritisch ist der Prozess – und welches Modell gewährleistet den Betrieb langfristig sicher, stabil und wirtschaftlich?

Häufig gestellte Fragen (FAQ)

Dürfen Krankenhäuser in Deutschland Cloud-Lösungen einsetzen?

Ja. § 393 SGB V formuliert die Voraussetzungen für die Verarbeitung von Sozial- und Gesundheitsdaten in Cloud-Umgebungen (u. a. Verarbeitungsort EWR/EU sowie Nachweis eines BSI-C5-Typ-2-Testats). Für Anwendungen, die ausschließlich Betriebs- und Materialdaten ohne Personenbezug verarbeiten, gelten die allgemeinen Vorgaben der DSGVO.

Inwiefern unterscheiden sich die internen IT-Aufwände bei SaaS und On-Premise?

Bei SaaS übernimmt der Softwareanbieter den operativen Betrieb, Patches, Datenbankwartung und Infrastruktur-Updates. Die Krankenhaus-eigene IT konzentriert sich im Wesentlichen auf Berechtigungskonzepte, Schnittstellen und Netzwerkanbindung.

Wie wird ein fundierter Kostenvergleich (TCO) zwischen beiden Modellen durchgeführt?

Ein vollständiger Vergleich umfasst über einen Zeitraum von fünf bis sieben Jahren neben der Lizenzgebühr auch die jährlichen Wartungskosten, Aufwände für Server, Speicher, Energie, Lizenzen von Drittsoftware sowie die anteilige Arbeitszeit für den internen Betrieb.

Welche Vorkehrungen greifen bei Verbindungsausfällen im Bereich der Materialwirtschaft?

In der Stationslogistik puffern physische Lagerbestände zeitweise Ausfälle ab. Nach Wiederherstellung der Netzwerkverbindung erfolgt die Synchronisation der erfassten Buchungs- und Bestandsdaten mit dem Gesamtsystem.

Quellen & Referenzen

• § 393 SGB V – Cloud-Einsatz im Gesundheitswesen
• Bundesministerium für Gesundheit – Digitalisierungsstrategie „Gemeinsam Digital 2026“
• BSI – Kriterienkatalog C5 & Cloud-Sicherheit im Gesundheitswesen
• ENISA – Procurement Guidelines for the Cybersecurity of Hospitals, 2026
• npj Digital Medicine – Implementation of Cloud Computing in the German Healthcare System
• NHS England – Cloud Journey Guide for Healthcare Providers
• Sana Kliniken / Deloitte / STACKIT – Aufbau einer souveränen Cloud-Infrastruktur