Cloud or On-Premises? The Wrong Question for the Right Decision

In technical discussions with IT leadership, procurement heads, and logistics managers in hospitals regarding digital solutions, one fundamental question consistently emerges: Cloud or on-premises? The debate often quickly narrows down to the physical location of the server.

On-premises is frequently associated with control and data privacy, whereas cloud computing is linked to flexibility, alongside concerns regarding vendor lock-in. However, choosing an operating model encompasses far more than where software and data reside. Essential criteria include:

Who operates and continuously monitors the infrastructure 24/7?
Who addresses security vulnerabilities and applies necessary patches promptly?
How are data backups and disaster recovery scenarios guaranteed?
In what timeframe can functional updates or new sites be integrated?
What internal IT resources are tied up over the long term, and what total costs emerge across the entire lifecycle?

The central question for IT decision-makers, commercial directors, and operational departments is therefore not “Where is our server located?”, but rather: Which model can provide the required IT service securely, reliably, and economically over the long term—specifically for this application?

Not Every Hospital Software System Carries the Same Criticality

Procurement evaluations often apply identical maximum-security criteria across all software categories. Yet, an electronic health record (EHR/KIS) or a picture archiving and communication system (PACS) carries a fundamentally different risk profile than specialized software for materials management, ward logistics, or facility management. Three criteria determine specific requirements in each case:

Baseline Security (Application-Independent): Authentication, encryption in transit and at rest, patch management, backup and recovery, monitoring, role-based access control, and incident management. In its 2026 updated procurement guidelines for hospitals, ENISA emphasizes that cybersecurity must be addressed throughout the entire system lifecycle.
Data Protection Level: Personal patient, diagnostic, and clinical treatment data are subject to specific legal protection requirements. Purely logistical data—such as item numbers, storage bins, minimum inventory levels, or master data—exhibit an entirely different sensitivity level.
Process Criticality: The operational impact of system downtime varies by department. In direct clinical workflows, even brief outages can be critical. In supply and ward logistics, interruptions can typically be bridged through established fallback routines and physical buffer stocks.

Differentiating by criticality does not mean lowering baseline security standards. Instead, it allows protection and availability requirements to match the actual use case, enabling objective decisions on operating models without stalling uncritical operational workflows in internal IT backlogs.

Two Terms, Many Intermediate Stages

In a traditional on-premises deployment, software runs on dedicated infrastructure, typically within the hospital’s own data center or via a contracted hosting provider. This provides direct control over network architecture and release schedules, but also demands full operational responsibility.

In Software-as-a-Service (SaaS), the software provider manages the technical operations, platform maintenance, and scalability. Between these models lies a broad spectrum: private cloud, sovereign cloud, managed hosting, IaaS, PaaS, and hybrid architectures. In practice, this is rarely a binary decision.

The Regulatory Framework Is Shifting

Historical hesitation toward cloud adoption in the German healthcare sector was understandable, driven by strict data protection laws, medical confidentiality, and regulatory ambiguity. This framework has evolved considerably:

Section 393 SGB V: Since 2024, German social law provides legal certainty for processing social and healthcare data in cloud environments, setting requirements regarding processing locations (EEA/EU) and mandatory compliance with the BSI C5 attestation (Type 2 mandatory since July 2025).
Federal Ministry of Health (BMG) Digital Strategy: The updated “Gemeinsam Digital 2026” strategy actively encourages the adoption of standardized cloud services, particularly in the context of the European Health Data Space (EHDS).
BSI Position: The German Federal Office for Information Security (BSI) recognizes cloud computing as an established standard for IT services and highlights the scalability and resilience characteristics of certified cloud architectures.

Operational Insight: Not every software system in a hospital processes social or health data as defined by Section 393 SGB V. Purely logistical and materials data fall under general GDPR requirements, reinforcing the need for a risk-based evaluation rather than blanket cloud prohibitions.

Seven Dimensions That Determine the Difference

1. Control vs. Scalability & Internal Resources

On-premises gives IT leadership direct oversight over hardware, networks, and update schedules. However, this demands internal resources for capacity planning, hypervisor maintenance, operating system patching, and monitoring. Conversely, certified cloud services provide automated, elastic scaling. A 2024 study published in npj Digital Medicine examining cloud implementation in German healthcare demonstrated that phased integration alongside legacy systems is achievable without abrupt system overhauls.

2. Security Is Not Merely a Matter of Server Location

The physical location of a server alone does not determine its security level. Decisive factors include active patch management, identity and access management, network segmentation, and incident response procedures. As highlighted by ENISA, dedicated cloud providers often allocate significantly more specialized personnel and capital to security measures than an individual, overburdened hospital IT team can maintain, provided that cloud-specific risks are managed via technical and contractual agreements.

3. Responsibility in Ongoing Operations

Operating an on-premises system permanently consumes staff capacity for OS updates, database maintenance, vulnerability scanning, and backup validation. In SaaS models, the vendor handles these operational tasks. The role of the internal IT team does not disappear; rather, it shifts from routine infrastructure maintenance toward interface integration, identity governance, and vendor management. This operational shift is evident in major hospital initiatives, such as the sovereign cloud strategy developed by Sana Kliniken alongside STACKIT and Deloitte.

4. Cost Comparison: Total Cost of Ownership (TCO)

Assuming that on-premises requires only a one-time purchase while cloud involves perpetual payments is financially incomplete. On-premises deployments incur recurring costs for software maintenance (typically 20% to 24% of initial license fees annually), periodic hardware replacement, energy, cooling, storage, secondary licenses, and administrative labor.

The key difference lies in visibility: SaaS costs appear as transparent, predictable operational expenses (OPEX). On-premises costs are often dispersed across capital expenditures (CAPEX) and indirect cost centers. A realistic financial assessment requires evaluating Total Cost of Ownership across a five-to-seven-year timeframe.

5. Time-to-Value

On-premises projects often require substantial lead times for hardware procurement, server provisioning, and database installation before users ever access the software. With SaaS, the operating environment is immediately available, allowing project resources to focus directly on interface configuration, master data migration, and staff onboarding. NHS England explicitly cites rapid deployment times as a key driver for evaluating cloud models.

6. Updates: Manual Scheduling vs. Continuous Improvement

On-premises environments allow manual scheduling of updates and version migrations, which often entails dedicated testing phases and maintenance windows. SaaS solutions are typically updated centrally and continuously. For heavily customized core clinical systems, manual scheduling may remain appropriate; for standardized operational workflows like inventory replenishment, continuous deployment is substantially more resource-efficient.

7. Vendor Lock-In

Dependencies can emerge in either operating model. In on-premises setups, lock-in often stems from proprietary data schemas, legacy database dependencies, or specialized institutional knowledge held by individual administrators. In SaaS, attention centers on service level agreements, structured data export capabilities, and exit strategies. Open interoperability and standardized APIs are critical regardless of the architecture selected.

Lifecycle Cost Comparison (TCO)

A valid cost comparison evaluates the initial licensing and operational overhead of an on-premises setup directly against the recurring subscription of a SaaS solution across an identical five-to-seven-year operational window.

Relevance for Digital Materials Management

Applying risk- and criticality-based criteria is particularly instructive for hospital supply chain management:

No Patient Treatment Data: MOYAFLOW processes item and material master records, storage bin locations, inventory balances, and replenishment requests—not patient records or clinical diagnoses.
Distinct Risk Profile: Supply chain software demands high operational stability. However, temporary network latency does not compromise immediate bedside care, as established physical buffer stocks on the wards bridge short-term interruptions.
Preservation of IT Resources: Adopting modern logistics software should not stall because internal IT teams lack available server hardware or database administrative capacity.

MOYAFLOW operates as a SaaS platform hosted in ISO-certified German data centers (Hetzner) that maintain a BSI C5:2020 Type 2 attestation. Consequently, the underlying technical infrastructure satisfies the security benchmarks mandated by Section 393 SGB V for sensitive healthcare processing, even though the platform primarily handles operational inventory data. New clinical wards, external storage depots, or subsidiary facilities can be integrated without requiring local server rollouts or sustained hardware upkeep from the hospital IT department.

Conclusion: Criteria-Based Decisions Instead of Blanket Rules

Neither cloud nor on-premises is inherently superior across every scenario. A sound architectural decision in hospital IT follows a structured assessment:

Establish non-negotiable IT baseline security requirements.
Determine the actual protection classification of the data (clinical vs. operational).
Evaluate process criticality during potential system interruptions.
Select the operating model based on realistic Total Cost of Ownership (TCO), operational overhead, and internal resource availability.

The regulatory environment in healthcare supports differentiated cloud adoption. The decisive question is therefore: What specific data does the application process, how critical is the underlying workflow, and which operating model ensures secure, dependable, and cost-effective operations over the long term?

Frequently Asked Questions (FAQ)

Are German hospitals legally permitted to use cloud solutions?

Yes. Section 393 SGB V defines explicit regulatory parameters for processing social and health data in cloud environments, including processing within the EEA/EU and validation via a BSI C5 Type 2 attestation. For systems processing purely operational, non-personal supply chain and inventory data, standard GDPR regulations apply.

How does internal IT workload differ between SaaS and on-premises?

In a SaaS model, the software provider is responsible for server maintenance, patch management, database tuning, and infrastructure redundancy. The hospital’s IT department focuses primarily on role definitions, identity management, and API integration.

How should hospitals calculate Total Cost of Ownership (TCO) between models?

An accurate comparison must span five to seven years and account for upfront software licenses, annual vendor maintenance fees (20–24%), physical server hardware, storage, power, facility cooling, secondary system licenses, and the internal labor required for continuous administration.

How do supply chain systems handle network outages?

In ward and warehouse logistics, physical inventory buffers absorb temporary connectivity interruptions. Once network connectivity is restored, local transactions and inventory tallies automatically synchronize with the central system.

Sources & References

Section 393 SGB V – Cloud Computing in the German Healthcare System
German Federal Ministry of Health (BMG) – Digitalization Strategy “Gemeinsam Digital 2026”
BSI – Cloud Computing Compliance Criteria Catalogue (C5) & Healthcare Cybersecurity
ENISA – Procurement Guidelines for the Cybersecurity of Hospitals and Healthcare Providers, 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 – Implementation of a Sovereign Cloud Infrastructure