Pilotprojekt-Design Klinik-KI: Die häufigsten drei Fehler

Ein Klinik-KI-Pilot endet typischerweise so: Sechs Monate nach dem Start sitzt eine Lenkungsgruppe zusammen, liest einen knappen Erfahrungs-Bericht und stellt fest, dass keine belastbare Aussage über Erfolg oder Scheitern möglich ist. Die Diskussion verschiebt sich auf „mehr Schulung“ oder „andere Software“. Die Frage, die selten gestellt wird, ist die einzige, die an dieser Stelle weiterführt: Wie war der Pilot eigentlich gebaut? Welche Erfolgskriterien waren am Tag eins schriftlich vereinbart? Wer aus den Stationen war im Konfigurations-Pfad? Und wie schmal war der Scope? Die Implementation-Science-Forschung der letzten zwanzig Jahre ordnet diese Fragen konsequent. Sie nennt drei wiederkehrende Pilot-Design-Fehler, die unabhängig von der Software-Qualität wirken — und die einen Pilot zum Scheitern verurteilen, bevor er einen einzigen Patient:innen-Fall gesehen hat.

Die methodische Konsolidierung ist seit Mitte der 2000er-Jahre belastbar. 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. In der Folge-Empirie zeigen sich der innere Kontext und der Implementierungs-Prozess als die häufigsten Bestimmungs-Variablen. CFIR ist deskriptiv und ordnet die Determinanten, ohne Erfolgs-Wahrscheinlichkeiten zu quantifizieren. Greenhalgh et al. (2017) erweitern die Sicht im Nonadoption-Abandonment-Scale-up-Spread-Sustainability-Framework (NASSS) im Journal of Medical Internet Research auf sieben Komplexitäts-Domänen — Krankheits-Bedingung, Technologie, Wert-Proposition, Adoptanten, Organisation, weiteres System, Anpassung über Zeit. Vorhaben mit hoher Komplexität in mehreren Domänen scheitern systematisch. Die Beschreibung ist qualitativ; sie sortiert die Komplexität, sie sagt nicht voraus, welche Domäne im Einzelfall den Pilot kippt. Aus dieser Lese folgen drei Pilot-Design-Fehler — und sie sind in der Reihenfolge, in der sie typischerweise auftreten.

Erstens: zu breiter Scope am Tag eins

Der häufigste Pilot-Design-Fehler ist die Scope-Überdehnung. Die Pilot-Vereinbarung adressiert mehrere Patient:innen-Gruppen gleichzeitig, mehrere Stationen, mehrere Funktions-Bereiche der Software, mehrere Berufsgruppen — alles auf einmal. Das Argument dafür klingt vernünftig: Man wolle nicht „kleinklein“ anfangen, sondern den realen Klinik-Komplex abbilden. In der NASSS-Lese heißt das: die Komplexität ist gleichzeitig in den Adoptanten-, Organisations- und Weiteres-System-Domänen hoch — drei der sieben Komplexitäts-Domänen werden parallel belastet. Das System trägt das selten. Was als breiter Pilot startet, kippt am Ende der ersten zwei Monate in eine Lage, in der die Auswertung keine Aussage mehr liefern kann: die Pflege-Verlaufsdoku läuft anders als die ärztliche Verlaufsdoku, die Therapie-Sitzungen folgen einer dritten Logik, und die Funktions-Bereiche der Software haben sich gegenseitig beeinflusst. Welche Variable was bewirkt hat, lässt sich am Pilot-Ende nicht mehr trennen.

Beiträge in Implementation Science und in BMJ Open 2023–2026 dokumentieren das Pattern konvergent: Pilots, die mit einem klar umrissenen Anwendungsfall beginnen — typischerweise begrenzt auf einen einzelnen Stations-Bereich, ein einzelnes Patient:innen-Profil und einen einzelnen Software-Modul-Ausschnitt — und erst nach belastbarer Beleg-Lage erweitern, erreichen den Übergang in den Regelbetrieb deutlich häufiger als Pilots, die mit breitem Scope starten. Die Studien sind heterogen in der Größe, sie folgen unterschiedlichen Designs (Mixed-Methods, qualitative Fallstudien, Mehrzentren-Erhebungen), und die Effekt-Größen variieren zwischen Versorgungs-Kontexten. Die qualitative Klasse des Pattern bleibt aber stabil über Studien-Designs hinweg. Die zugrunde liegenden Erhebungen kommen vorwiegend aus angelsächsischen und westeuropäischen Häusern; die strukturelle Übertragbarkeit auf deutsche Klinik-Kontexte ist methodisch begründet, einzelne Effekt-Maße lassen sich nicht direkt umrechnen.

Zweitens: kein Vorher-Nachher-Vergleich

Der zweite Fehler ist die fehlende Erfolgsmessung. Der Pilot startet ohne vorab vereinbarte Mess-Indikatoren mit Vor-Pilot-Werten — und endet dort, wo das Sechs-Monats-Treffen bemerkt, dass kein Vergleich gezogen werden kann. Glasgow, Vogt und Boles (1999) formulieren das im RE-AIM-Framework als methodische Architektur — fünf Dimensionen einer Evaluation: Reach (welche Population wird erreicht), Effectiveness (welche Wirkung pro Erreichten), Adoption (welche Stellen übernehmen), Implementation (wie konsistent wird umgesetzt), Maintenance (wie lange bleibt die Wirkung erhalten). Im Pilot-Kontext bedeutet das: ein Pilot-Design ohne vorab definierte Indikatoren auf mindestens zwei der fünf Dimensionen entzieht sich am Pilot-Ende der Bewertbarkeit. RE-AIM ist Architektur, nicht Mess-Vorgabe — die Indikatoren pro Dimension sind kontext-spezifisch zu operationalisieren. Eine RE-AIM-Anwendung ohne saubere Indikator-Definition bleibt formal vollständig und inhaltlich leer. Die Wahl der Indikatoren ist die zentrale Pilot-Design-Entscheidung; sie muss am Tag eins schriftlich getroffen sein.

Operativ heißt das: zwei oder drei Indikatoren mit aktuellem Klinik-Wert vor dem Pilot-Start. Im Doku-Bereich etwa die mediane Doku-Zeit pro Aufnahme-Bericht in Minuten, die Vollständigkeitsquote der Pflicht-Felder im Aufnahme-Bogen und die Rate der Nachfragen aus dem Träger-Rückkanal pro hundert Aufenthalte. Im Aufnahme-Triage-Bereich die mediane Bett-Zuteilungs-Dauer, die Rate der Falsch-Zuteilungen mit Stations-Wechsel binnen 24 Stunden und die Frequenz der Aufnahme-Konflikt-Rückrufe an die ärztliche Leitung. Die Indikatoren sind nicht universal; sie hängen am konkreten Anwendungsfall. Sie müssen aber drei Eigenschaften erfüllen: ein Vor-Pilot-Wert ist messbar, der Indikator ist während des Pilots ohne Sondererhebung beobachtbar, und der Indikator ist robust gegen sekundäre Effekte (Saison, Belegungs-Schwankung, Personal-Wechsel). Wer in der Pilot-Vereinbarung keine zwei oder drei Indikatoren mit Vor-Pilot-Werten benennt, hat den Pilot strukturell aus der Bewertbarkeit heraus verhandelt.

Drittens: Schlüsselpersonen erst am Schulungs-Tag

Der dritte Fehler ist die verspätete Schlüsselpersonen-Einbindung. Aarons et al. (2011) ordnen Implementierungs-Vorhaben im Exploration-Preparation-Implementation-Sustainment-Modell (EPIS) in vier Phasen. In der Preparation-Phase werden die Schlüsselpersonen identifiziert und in die Konfigurations-Entscheidungen eingebunden. Wird diese Einbindung in die Implementation-Phase verschoben — die Multiplikator:innen sehen die Software erstmals am Schulungs-Tag —, verlagert sich der Konflikt in die Tagesarbeit, in der er teurer und sichtbarer wird. JAMIA-Beiträge 2023–2026 zur Klinik-KI-Adoption belegen das Pattern: Pilots, in denen klinische Multiplikator:innen schon in der Konfigurations-Phase an einer Reihe konkreter Software-Entscheidungen sichtbar mitgewirkt haben, zeigen in der Implementation-Phase weniger Prozess-Konflikte und höhere Adoptions-Raten als Pilots ohne diese Vor-Einbindung. Schlüsselpersonen sind selten die Personen, die in der Lenkungsgruppe sitzen — sie sind die erfahrenen Stationsleitungen, die ärztlichen Multiplikator:innen, die IT-affinen Therapeut:innen, deren Lese-Richtung in den Pflege-Übergaben und in den ärztlichen Frühbesprechungen die Software-Bewertung der ganzen Station prägt. Werden sie in der Konfigurations-Phase nicht gefragt, kommt ihre Antwort am Schulungs-Tag — und sie ist dann nicht mehr formbar.

Eine Pilot-Architektur, die alle drei Stellen am Tag eins schließt

Aus dieser Lese folgen drei konkrete Pilot-Design-Anforderungen. Erstens ein schmaler Scope: ein einzelnes Indikations-Profil, ein einzelner Stations-Bereich, ein einzelner Funktions-Ausschnitt der Software. Was sich darin strukturell trägt, wird im Anschluss erweitert; was erweitert wird, hat im engeren Pilot eine belastbare Beleg-Lage hinterlassen. Zweitens vereinbarte Mess-Indikatoren: Der Pilot startet mit zwei oder drei schriftlich festgelegten Größen samt aktuellem Klinik-Wert. Die Indikatoren sind beobachtbar, robust und kontext-spezifisch operationalisiert. Drittens frühe Schlüsselpersonen-Beteiligung: Drei klinische Multiplikator:innen wirken in der Konfigurations-Phase an mindestens drei Konfigurations-Entscheidungen sichtbar mit. Sichtbar heißt: protokolliert, beantwortet, mit Folge im System. Die Charité-Arbeitsgruppe Clinical Implementation Science in Digital Health (CIDH) im EviDoc-Programm dokumentiert dieselben drei Stellhebel als wiederkehrende Befunde in deutscher Klinik-Praxis. Die Programm-Arbeit ist akademisch, kein peer-reviewter Studien-Korpus; die Übertragung auf andere deutsche Klinik-Kontexte erfolgt durch Programm-Veröffentlichungen. Die Klasse der Empfehlung ist über internationale und deutsche Quellen konvergent.

Ein Klinik-KI-Pilot ist eine Mess-Anordnung mit Geltungsanspruch. Die drei Pilot-Design-Fehler — Scope-Überdehnung, fehlende Erfolgsmessung, verspätete Schlüsselpersonen-Einbindung — sind in der Implementation-Science-Literatur über zwei Jahrzehnte konvergent dokumentiert; sie wirken unabhängig von der Software-Qualität, und sie wirken am Tag eins. Ein Pilot mit drei klar beantworteten Design-Fragen am Start ist kein einfacherer Pilot. Er ist der einzige, dessen Auswertung am Pilot-Ende belastbar bleibt und gegen den später Beleg-Lagen geführt werden können — innerhalb der eigenen Klinik, in der Anbieter-Bewertung und in der Diskussion mit der ärztlichen Leitung über den Übergang in den Regelbetrieb.