Individual oder Standard — eine Frage der digitalen Souveränität

Krankenhäuser, Labore und Pharmaunternehmen müssen bei der Softwareentscheidung mehr abwägen als Kosten und Funktionsumfang. Wer die Kontrolle über seine Systeme verliert, verliert im KRITIS-Kontext mehr als Effizienz.

Ein Krankenhaus wechselt sein Krankenhausinformationssystem. Ein Pharmaunternehmen evaluiert eine neue LIMS-Lösung. Ein Medizintechnikhersteller sucht Software für die Produktionsdokumentation. Die erste Frage in diesen Projekten lautet fast immer: Standard oder Individual? Die eigentlich entscheidende Frage kommt danach — und sie wird selten gestellt: Wer kontrolliert die Software, wenn es darauf ankommt?

Im Healthcare-Bereich ist das keine rhetorische Debatte. Es ist eine Frage der Betriebssicherheit, der Regulatorik und zunehmend auch der nationalen Infrastrukturstrategie. Denn Krankenhäuser, Labore, Blutspendedienste und Pharmahersteller gehören in weiten Teilen zur kritischen Infrastruktur im Sinne des deutschen IT-Sicherheitsgesetzes und der europäischen NIS2-Richtlinie. Was das konkret bedeutet: Softwareentscheidungen sind in diesem Umfeld keine rein technischen Entscheidungen mehr.

Was Healthcare von anderen Branchen unterscheidet

In der Fertigungsindustrie bedeutet ein Softwareausfall ungeplante Stillstandszeiten. Im Healthcare-Bereich kann er Patientenversorgung gefährden. Dieser Unterschied prägt jede Softwareentscheidung — oder sollte es zumindest. KRITIS-Betreiber im Gesundheitswesen sind verpflichtet, ihre Systeme auf dem aktuellen Stand der Technik zu halten und das nachzuweisen. Sie müssen Sicherheitsvorfälle melden, und sie müssen Drittanbieterabhängigkeiten bewerten können. Ein System, dessen Architektur niemand im eigenen Haus vollständig versteht, macht diese Anforderungen praktisch unkontrollierbar.

Hinzu kommt der zeitliche Druck: Das KRITIS-Dachgesetz und die NIS2-Richtlinie verschärfen die Anforderungen an Cybersicherheit und Lieferkettensicherheit. Wer heute Softwareentscheidungen trifft, ohne diese Perspektive einzubeziehen, löst morgen ein Compliance-Problem, das mit der ursprünglichen Kaufentscheidung begann.

Standardsoftware: Stärken und die kritische Grenze

Standardsoftware — ob ein marktführendes KIS, eine etablierte LIMS-Plattform oder eine branchenübliche QM-Lösung — bietet echte Vorteile: schnelle Verfügbarkeit, bewährte Prozesse, Herstellersupport, regelmäßige Updates und eine breit dokumentierte Validierungsbasis. Für viele Anwendungsfälle im Healthcare-Bereich ist sie die richtige Wahl. Aber sie hat eine Grenze, und diese Grenze verläuft genau dort, wo digitale Souveränität beginnt.

Wer Standardsoftware einsetzt, delegiert Kontrolle: über den Releasezyklus, über Sicherheitspatches, über Schnittstellenkompatibilität mit anderen Systemen — und über die strategische Frage, ob der Hersteller in drei Jahren noch existiert, die Lösung weiterentwickelt oder das Produkt abkündigt. Im KRITIS-Kontext ist diese Abhängigkeit kein Komfortproblem. Es ist ein strukturelles Risiko, das sich regulatorisch nicht mehr einfach wegdokumentieren lässt.

Die zentrale Frage für Healthcare-Einrichtungen lautet daher nicht: „Ist Standardsoftware gut oder schlecht?" Die Frage lautet: Welche Systeme dürfen wir uns nicht leisten, nicht zu kontrollieren?

Individuallösungen: Mehr Kontrolle, mehr Verantwortung

Eine Individuallösung gibt der Einrichtung maximale Kontrolle über Prozesslogik, Schnittstellen und Quellcode. Sie passt sich dem Prozess an, nicht umgekehrt — ein entscheidender Unterschied in Einrichtungen mit hochspezifischen Arbeitsabläufen, strengen Validierungsanforderungen nach IEC 62304 oder GxP und komplexen Geräteschnittstellen. Im KRITIS-Kontext bietet das echte Vorteile: Die Einrichtung kann Sicherheitsupdates selbst steuern, Abhängigkeiten dokumentieren und die Software unabhängig von Herstellerentscheidungen betreiben.

Der Preis dafür ist Verantwortung. Eine Individuallösung ist nur dann souverän, wenn sie auch langfristig gewartet wird. Genau hier liegt das Risiko: Viele Einrichtungen haben über Jahre Individualsoftware entwickelt — maßgeschneidert auf ihre Prozesse, von internen Entwicklern oder kleinen Dienstleistern gebaut. Diese Entwickler sind längst weg. Die Dokumentation ist lückenhaft. Und was auf dem Papier wie maximale Souveränität aussieht, ist in der Realität das Gegenteil: eine Software, die niemand mehr vollständig versteht, auf Hardware, die kaum noch beschaffbar ist.

Das dritte Szenario: Legacy als verstecktes Souveränitätsproblem

Zwischen der bewussten Entscheidung für Individual- oder Standardsoftware liegt in vielen Healthcare-Einrichtungen ein drittes Szenario, das selten als solches erkannt wird: gewachsene Altsysteme, die einmal als Individuallösung gebaut wurden und deren ursprüngliche Kontrollstruktur längst erodiert ist. Diese Systeme laufen — meist stabil, oft unverzichtbar — aber niemand kann mit Sicherheit sagen, was passiert, wenn ein kritischer Fehler auftritt, eine neue Windows-Version inkompatibel wird oder ein Prüfer fragt, wer für den Betrieb dieser Software verantwortlich ist und wie lange das noch gilt.

Digitale Souveränität ist kein Zustand, den man einmal erreicht. Sie ist ein Prozess — und er beginnt damit, den Ist-Zustand ehrlich zu beschreiben.

Eine selbst entwickelte Software, die niemand mehr warten kann, ist nicht souverän. Sie ist eine tickende Abhängigkeit ohne definierten Ansprechpartner und ohne Fallback. Der erste Schritt zur Souveränität ist deshalb nicht eine neue Software. Es ist das vollständige Verstehen der bestehenden.

Wie eine strukturierte Entscheidung aussieht

Für Healthcare-Einrichtungen empfiehlt sich eine Differenzierung nach Kritikalität: Systeme, die unmittelbar zur patientennahen Versorgung beitragen oder regulatorisch direkt bewertet werden, brauchen eine andere Souveränitätsstrategie als administrative Systeme. Die Frage ist nicht, welcher Softwaretyp grundsätzlich besser ist — sondern welche Kontrolltiefe für welches System notwendig ist.

Standardsoftware ist sinnvoll, wenn ein Prozess standardisierbar ist, ein Hersteller mindestens 80 Prozent der Anforderungen abdeckt und eine Exit-Strategie für den Fall eines Herstellerwegfalls definiert werden kann. Eine Individuallösung ist sinnvoll, wenn der Prozess wirklich einzigartig ist, eine Quellcodekontrolle regulatorisch oder strategisch zwingend erforderlich ist und eine langfristige Wartungsstrategie — intern oder über einen festen Partner — realistisch gesichert werden kann. Für bestehende Altsysteme gilt: Reverse Engineering der Businesslogik und strukturierte Übergabe an ein team mit klarer Verantwortlichkeit sind in vielen Fällen der kürzeste Weg zur tatsächlichen Souveränität — und schaffen den Spielraum für eine durchdachte Ablöse- oder Migrationsentscheidung ohne Zeitdruck.

Fazit: Souveränität ist eine Strategie, keine Software

Die Entscheidung zwischen Individual- und Standardsoftware hat im Healthcare-Kontext keine generische Antwort. Sie hat eine kontextabhängige — und die hängt davon ab, ob das System zur kritischen Infrastruktur gehört, ob eine Wartungsstrategie existiert und ob die Einrichtung tatsächlich Kontrolle über ihre Systeme hat. Was im KRITIS-Bereich nicht akzeptabel ist: eine Software zu betreiben, ohne zu wissen, was passiert, wenn der Hersteller wegfällt, ein kritischer Fehler auftritt oder eine Aufsichtsbehörde im Audit fragt, wie der Betrieb in den nächsten drei Jahren gesichert ist.

Digitale Souveränität im Healthcare bedeutet nicht, alles selbst zu entwickeln. Es bedeutet, strategisch zu entscheiden, was man kontrollieren muss, was man delegieren kann — und für beides eine belastbare, auditfähige Antwort parat zu haben.

Über VIALUTIONS 

VIALUTIONS consult GmbH, Berlin, unterstützt Unternehmen im Healthcare-, Pharma- und MedTech- Bereich bei der strukturierten Übernahme, Analyse und Ablösung von Legacy-Systemen, sowir bei der Neuentwicklung Unternehmenskritischer Anwendungen — mit Fokus auf Compliance, KRITIS-Anforderungen und digitale Souveränität. Kontakt: hepfner@vialutions.com · www.vialutions.com

REGULATORISCHER HINTERGRUND

BSI-Gesetz (BSIG) & KRITIS-Verordnung — Schwellenwerte und Pflichten für kritische Infrastrukturen im Gesundheitsbereich

EU-Richtlinie NIS2 (2022/2555) — Mindestanforderungen an Cybersicherheit für Betreiber wesentlicher Einrichtungen

KRITIS-Dachgesetz (KRITIS-DachG) — Umsetzung der CER-Richtlinie in deutsches Recht

IEC 62304 — Lebenszyklusanforderungen für Medizingeräte-Software

EU AI Act (2024/1689) — Anforderungen an KI-Systeme in regulierten Umgebungen, inkl. Hochrisiko-Klassifikation für medizinische Anwendungen

Von Andreas Hepfner, Gründer und Geschäftsführer von VIALUTIONS