Wenn Klinik-IT-Projekte scheitern: Drei Muster, die immer wieder auftauchen

Eine Klinik-Geschäftsführerin sitzt im Mai 2026 in einer Aufsichts-Sitzung; auf dem Tisch liegt der Sechs-Monats-Bericht zu einem KHZG-geförderten IT-Vorhaben des Hauses. Der Bericht liest sich vorhersehbar: verzögerter Go-Live, deutlich höhere Personalbindung in den Stationen als geplant, ein Anbieter-Vertrag, der die Daten-Export-Klauseln dünn hält. Die Sitzung verläuft routiniert; man verschiebt die Entscheidung auf einen Workshop. Routinen sind das eigentliche Diagnose-Material — und dieser Routinen-Verlauf zeigt, dass das Vorhaben seine strukturelle Misserfolgs-Wahrscheinlichkeit lange vor der Einführung angelegt hat. Die internationale Versorgungs- und Implementierungs-Forschung liest diese Konstellation seit zwei Jahrzehnten konvergent. Sie nennt drei strukturelle Muster, die in der Beschaffungs-Phase entstehen, in der Einführung sichtbar werden — und die unabhängig vom Anbieter, von der Software-Klasse, von der Klinik-Größe wirken.

Die methodische Konvergenz ist seit Mitte der 2000er-Jahre stabil. Damschroder et al. (2009) ordnen die Determinanten von Klinik-IT-Implementierungen im Consolidated Framework for Implementation Research (CFIR) in fünf Domänen — Charakteristika der Intervention, äußerer Kontext, innerer Kontext, individuelle Akteur:innen, Implementierungs-Prozess. Innerer Kontext und Implementierungs-Prozess sind in der Folge-Empirie die häufigsten Bestimmungs-Variablen für Erfolg oder Misserfolg. Greenhalgh et al. (2017) erweitern die Sicht im Nonadoption-Abandonment-Scale-up-Spread-Sustainability-Framework (NASSS) auf sieben Komplexitäts-Domänen und sortieren die strukturell anfälligsten Stellen — Adopter-System, Organisation, Anpassung über Zeit. Kellermann und Jones (2013) benennen in Health Affairs die klassische Misserfolgs-Diagnose der Health Information Technology — schwache Sponsor-Konstellation, unterschätzte Anpassungs-Kosten, mangelnde Interoperabilität — als wiederkehrende Klassen über Versorgungs-Systeme hinweg. Aus dieser Lese folgen drei Muster, in der Reihenfolge, in der sie typischerweise entstehen.

Erstens: die falsche Owner-Konstellation

Das Vorhaben hat formal eine:n Sponsor:in in der Geschäftsführung, faktisch aber einen IT-Anker als operativen Treiber. Die Folge ist im Lenkungs-Ausschuss sichtbar: Die Sitzungen werden mit IT-Personalen besetzt, die ärztliche und pflegerische Leitung erscheint zur Abnahme. Der Konfigurations-Pfad bewegt sich entlang technischer Logik — Datenmodell, Schnittstellen, Einführungs-Plan — ohne dass die klinischen Use-Cases am eigenen Material durchgespielt werden. Die NASSS-Domäne Adopter-System markiert genau diese Stelle: Wer die Software an den Stationen tragen muss, war im Konfigurations-Pfad nicht beteiligt. Das prozedurale Symptom ist schon im Pflichtenheft erkennbar — es listet technische Anforderungen, ohne klinische Use-Cases mit eigenen Erfolgskriterien zu spezifizieren. Im Vor-Vertrags-Gespräch fehlen die Pflegedienstleitung und die ärztliche Leitung der zentralen Fachabteilungen am Tisch. Die Frage, die in der Aufsichts-Sitzung selten gestellt wird: Welche Berufsgruppe trägt das Vorhaben strukturell — und ist sie tatsächlich am Konfigurations-Tisch?

Zweitens: die unterschätzten Prozess-Anpassungs-Kosten

Die Anschaffungs- und Implementierungs-Rechnung enthält Lizenz, Hardware, Schulung. Sie enthält nicht in voller Höhe den Anpassungs-Aufwand der Stationen — die Personal-Stellen für klinische Multiplikator:innen, die Doku-Pfad-Anpassung in den ersten zwölf bis vierundzwanzig Monaten, die Vor-Ort-Begleitung an den ersten kritischen Aufnahme- und Entlasstagen. Beiträge im Implementation Science Journal 2018–2025 dokumentieren konvergent, dass Adoption-Lücken in der Sustainment-Phase aus diesen Anpassungs-Kosten entstehen, nicht aus der Software-Auswahl. In der deutschen After-Action-Auswertung des Krankenhauszukunftsgesetzes (KHZG) hat das Förder-Tempo dieses Muster verschärft: Beiträge im Bundesgesundheitsblatt 2022–2024 beschreiben, dass Förder-Fristen die Anpassungs-Sorgfalt unter Zeitdruck stellten. Sichtbar wird das Muster in der Vor-Vertrags-Phase: Im Anbieter-Vertrag fehlt eine eigene Position für den Prozess-Anpassungs-Aufwand der Stationen; in der Total-Cost-of-Ownership-Rechnung über fünf Jahre sind die Personal-Kosten für klinische Multiplikator:innen nicht ausgewiesen; im Schulungs-Paket sind die Stellen für die Vor-Ort-Begleitung in den ersten Wochen nicht hinterlegt. Die Lücke ist nicht in den Stationen — sie ist im Vertrags-Anhang.

Drittens: die fehlende Rückfallebene

Das dritte Muster ist die Rückfallebene, die fehlt. Das Haus hat keinen Plan für den Fall, dass das System ausfällt, in einer Migrations-Phase nicht trägt, oder der Anbieter-Vertrag in eine schlechte Verfasstheit kommt. Reviews in BMJ Quality & Safety 2019–2024 dokumentieren, dass Klinik-IT-Migrations-Phasen ohne Standby-Pfad mit erhöhten Patientensicherheits-Risiken einhergehen. Die Lessons-Learned-Reviews aus NHS England Digital 2018–2024 zeigen die Resilienz-Lücke wiederholt: Häuser, die in einer Migrations-Phase keine betriebsfähige Rückfall-Architektur vorhalten, geraten bei jedem System-Ausfall in eine versorgungs-relevante Lage. Branchen-Befunde aus KLAS Decision Insights 2022–2025 betonen in derselben Linie die strukturelle Bedeutung von Anbieter-Diversifikation und Schnittstellen-Offenheit gegenüber Standards (HL7 FHIR, Integrating the Healthcare Enterprise) als Resilienz-Voraussetzung. Auch das dritte Muster ist in der Vertrags-Phase erkennbar: Die Daten-Export-Klauseln sind dünn formuliert; die Schnittstellen-Pflicht gegenüber Standards ist im Vertrag nicht verpflichtend hinterlegt; ein expliziter Migrations- oder Rückfall-Plan auf Architektur-Ebene fehlt; die Klinik-IT-Architektur hat keinen Standby-Pfad für die Kern-Versorgungs-Prozesse — Aufnahme, Medikation, Befundkommunikation. Eine Rückfallebene ist keine Anbieter-Bestrafungs-Logik. Sie ist die strukturelle Voraussetzung dafür, dass das Haus betriebsfähig bleibt, wenn das Vorhaben aus Gründen, die nicht im Pflichtenheft stehen, nicht trägt.

Branchen-Quoten zur IT-Projekt-Misserfolgs-Diagnose kursieren seit zwei Jahrzehnten in einer Bandbreite, die eine Mehrheit der Vorhaben als nicht-erfolgreich klassifiziert — die Standish-Group-CHAOS-Reports sind der bekannteste Anker. Diese Quoten sind methodisch kontrovers; sie hängen an Definitionen, die in der peer-reviewed Forschung teilweise als überzeichnet kritisiert werden. Die Größenordnung ist tragfähig genug, um die strukturelle Häufigkeit der drei Muster zu plausibilisieren — sie ist aber kein empirischer Punkt-Wert, an dem ein Vorhaben gemessen wird. Die diagnostisch tragfähige Lese liegt deshalb nicht in den aggregierten Branchen-Quoten, sondern in der konvergenten Befund-Lese der peer-reviewed Implementations-Forschung: dieselben drei Muster kehren in CFIR-, NASSS- und Health-Affairs-Diagnose wieder, sie kehren in den deutschen KHZG-After-Action-Beiträgen wieder, sie kehren in den britischen Lessons-Learned-Reviews wieder. Die Konvergenz ist die Aussage, nicht die Punkt-Quote.

Die Frühwarn-Logik: drei Fragen vor dem Vertrag

Die drei Muster sind in der Pre-Vertrags-Phase erkennbar — und genau das ist der diagnostische Wert. Die Frühwarn-Logik ist eine Drei-Fragen-Routine, die im Vor-Vertrags-Gespräch stehen kann und die das Beschaffungs-Material gegen die strukturelle Misserfolgs-Wahrscheinlichkeit prüft. Die erste Frage zielt auf den Lenkungs-Ausschuss und das Pflichtenheft: Welche Berufsgruppen sind dort stimmberechtigt im Konfigurations-Pfad, und welche klinischen Anwendungsfälle sind mit eigenen Erfolgskriterien hinterlegt — oder erscheint die Klinik im Lastenheft nur als Lieferadresse für eine fertige Software? Die zweite Frage zielt auf die Wirtschaftlichkeits-Rechnung: Trägt die Fünf-Jahres-Bilanz eine eigene Position für die Anpassungs-Architektur an den Stationen, oder ist nur Lizenz, Hardware, Schulung kalkuliert? Wenn die Anpassungs-Position fehlt, entstehen die Kosten trotzdem, nur ungeplant und mit Adoption-Folgen. Die dritte Frage zielt auf die Vertrags-Architektur: Welche Daten-Export-Klauseln, welche Schnittstellen-Pflichten gegenüber Standards, welcher Migrations-Plan auf Architektur-Ebene ist verpflichtend hinterlegt — und ist die Klinik bei einem System-Ausfall für Aufnahme, Medikation und Befundkommunikation betriebsfähig? Verbands-Stellungnahmen — der Bundesverband Gesundheits-IT (bvitg) in Deutschland, KLAS Decision Insights international — argumentieren in derselben Linie für strukturierte Beschaffungs-Standards mit klinischer Multiplikator:innen-Beteiligung und mit verpflichtenden Schnittstellen-Klauseln. Drei Fragen, drei Beschaffungs-Stellen, drei Schichten der Frühwarn-Logik.

Die drei Muster sind keine Theorie der Klinik-IT-Misserfolge; sie sind eine pragmatische Auswahl aus konvergenter Versorgungs- und Implementierungs-Forschung. Sie haben gemeinsam, dass sie sich in der Beschaffungs-Phase anlegen — im Lenkungs-Ausschuss, im Pflichtenheft, in der Fünf-Jahres-Rechnung, im Anbieter-Vertrag — und in der Einführung und in der Sustainment-Phase nur sichtbar werden. Wer die Diagnose auf die Einführung verschiebt, verschiebt die Frage; wer sie an die Beschaffungs-Stellen legt, beantwortet sie. Die Frage in der Aufsichts-Sitzung ist deshalb nicht „warum scheitert das Vorhaben jetzt“ — sie ist „welche der drei Stellen war im Pflichtenheft offen geblieben“. Das ist die Information, mit der eine Klinik-Geschäftsführung im sechsten Monat nicht mehr zwischen einem Workshop und einer Anbieter-Beauftragung steht.