Individual or standard — a question of digital sovereignty

By Andreas Hepfner, founder and CEO of VIALUTIONS

Hospitals, laboratories, and pharmaceutical companies must consider more than just cost and functionality when choosing software. In the context of critical infrastructure (KRITIS), losing control over their systems means losing more than just efficiency.

A hospital is changing its hospital information system. A pharmaceutical company is evaluating a new LIMS solution. A medical technology manufacturer is looking for software for production documentation. The first question in these projects is almost always: Standard or custom? The truly crucial question comes later—and it is rarely asked: Who controls the software when it matters most?

In the healthcare sector, this is not a rhetorical debate. It's a question of operational security, regulatory compliance, and increasingly, national infrastructure strategy. Hospitals, laboratories, blood donation services, and pharmaceutical manufacturers largely fall under the category of critical infrastructure as defined by the German IT Security Act and the European NIS2 Directive. In concrete terms, this means that software decisions in this environment are no longer purely technical.

What distinguishes healthcare from other industries

In the manufacturing industry, a software failure means unplanned downtime. In healthcare, it can jeopardize patient care. This difference shapes every software decision—or at least it should. Operators of critical infrastructure (KRITIS) in the healthcare sector are obligated to keep their systems up-to-date and to demonstrate this. They must report security incidents and be able to assess third-party dependencies. A system whose architecture no one in-house fully understands makes these requirements virtually impossible to control.

Added to this is the time pressure: The KRITIS overarching law and the NIS2 directive are tightening the requirements for cybersecurity and supply chain security. Anyone making software decisions today without considering this perspective will be solving a compliance problem tomorrow that began with the original purchase decision.

Standard software: Strengths and the critical limit

Standard software—whether a market-leading HIS, an established LIMS platform, or an industry-standard QM solution—offers real advantages: rapid availability, proven processes, vendor support, regular updates, and a well-documented validation base. For many healthcare use cases, it is the right choice. But it has its limits, and those limits lie precisely where digital sovereignty begins.

Using standard software means delegating control: over the release cycle, security patches, interface compatibility with other systems—and over the strategic question of whether the manufacturer will still exist in three years, continue developing the solution, or discontinue the product. In the context of critical infrastructure (KRITIS), this dependency is not merely a matter of convenience. It is a structural risk that can no longer be simply documented away through regulatory means.

The central question for healthcare institutions is therefore not: "Is standard software good or bad?" The question is: Which systems can we not afford not to control?

Individual solutions: More control, more responsibility

A customized solution gives the organization maximum control over process logic, interfaces, and source code. It adapts to the process, not the other way around—a crucial difference in organizations with highly specific workflows, stringent validation requirements according to IEC 62304 or GxP, and complex device interfaces. In the context of critical infrastructure (KRITIS), this offers real advantages: The organization can manage security updates itself, document dependencies, and operate the software independently of vendor decisions.

The price for this is responsibility. A custom solution is only truly effective if it is maintained long-term. This is precisely where the risk lies: Many organizations have spent years developing custom software—tailored to their processes, built by in-house developers or small service providers. These developers are long gone. The documentation is incomplete. And what looks like maximum sovereignty on paper is, in reality, the opposite: software that no one fully understands anymore, running on hardware that is becoming increasingly difficult to obtain.

The third scenario: Legacy as a hidden sovereignty problem

Between the conscious decision for custom or standard software, a third scenario exists in many healthcare facilities, one that is rarely recognized as such: legacy systems that have grown organically, were once built as custom solutions, and whose original control structure has long since eroded. These systems run—usually stably, often indispensably—but no one can say for sure what will happen if a critical error occurs, a new Windows version becomes incompatible, or an auditor asks who is responsible for operating this software and for how long that responsibility will remain valid.

Digital sovereignty is not a state that is achieved once and for all. It is a process — and it begins with an honest description of the current state.

A self-developed software that no one can maintain is not sovereign. It's a ticking time bomb with no defined point of contact and no fallback. Therefore, the first step toward sovereignty isn't new software. It's a complete understanding of the existing software.

What a structured decision looks like

For healthcare institutions, a differentiation based on criticality is recommended: Systems that directly contribute to patient care or are directly subject to regulatory evaluation require a different sovereignty strategy than administrative systems. The question is not which type of software is inherently better—but rather what level of control is necessary for each system.

Standard software makes sense if a process can be standardized, a vendor covers at least 80 percent of the requirements, and an exit strategy can be defined in case the vendor ceases operations. A custom solution makes sense if the process is truly unique, source code control is mandatory for regulatory or strategic reasons, and a long-term maintenance strategy—internally or through a dedicated partner—can realistically be ensured. For existing legacy systems: Reverse engineering the business logic and a structured handover to a team with clear responsibilities is often the quickest path to true sovereignty—and creates the necessary leeway for a well-considered replacement or migration decision without time pressure.

Conclusion: Sovereignty is a strategy, not software.

The choice between custom and standard software in the healthcare context has no generic answer. It is context-dependent—and that depends on whether the system is part of critical infrastructure, whether a maintenance strategy exists, and whether the institution actually has control over its systems. What is unacceptable in critical infrastructure is operating software without knowing what will happen if the vendor goes out of business, a critical error occurs, or a regulatory authority asks during an audit how operations will be secured for the next three years.

Digital sovereignty in healthcare doesn't mean developing everything in-house. It means strategically deciding what needs to be controlled and what can be delegated—and having a robust, auditable answer ready for both.

About VIALUTIONS

VIALUTIONS consult GmbH, Berlin, supports companies in the healthcare, pharmaceutical, and MedTech sectors with the structured acquisition, analysis, and replacement of legacy systems, as well as the development of new business-critical applications—with a focus on compliance, critical infrastructure (KRITIS) requirements, and digital sovereignty. Contact: hepfner@vialutions.com · www.vialutions.com

REGULATORY BACKGROUND

BSI Act (BSIG) & KRITIS Regulation — Thresholds and obligations for critical infrastructures in the healthcare sector

EU Directive NIS2 (2022/2555) — Minimum cybersecurity requirements for operators of essential facilities

Critical Infrastructure Protection Act (KRITIS-DachG) — Implementation of the CER Directive into German law

IEC 62304 — Lifecycle requirements for medical device software

EU AI Act (2024/1689) — Requirements for AI systems in regulated environments, including high-risk classification for medical applications