Change Management Klinik-IT: Was wirklich Akzeptanz schafft

Wenn die Akzeptanz der neuen Klinik-Software nach drei Monaten ausbleibt, lautet die Standard-Antwort vieler Häuser: noch ein Schulungs-Paket. Noch eine Sitzungs-Reihe für die Stationen, noch ein Blended-Learning-Modul, noch eine vorgehaltene Stelle für die Software-Multiplikator:innen. Die Implementation-Science-Forschung der letzten zwanzig Jahre liefert dazu eine unbequeme Lesart. Schulung verändert die Akzeptanz-Variable nur am Rand. Die zwei Stellen, an denen Akzeptanz strukturell entschieden wird, liegen nicht im Schulungs-Raum. Sie liegen am Arbeitsplatz selbst — und an den Personen, die in den Stationen den Ton angeben.

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 für Erfolg oder Scheitern. Die individuellen Akteur:innen sind eine von fünf Domänen, nicht das Zentrum. CFIR ist dabei 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 (JMIR) auf sieben Komplexitäts-Domänen. Die Adoptions-Domäne — die Frage, ob die Mitarbeitenden das System annehmen — ist eine von sieben. Vorhaben, die in mehreren Domänen Komplexität unterschätzen, scheitern systematisch. Die Beschreibung ist qualitativ; sie sortiert die Komplexität, sie sagt nicht voraus, welche Domäne im Einzelfall die Akzeptanz kippt.

Warum Schulung den Akzeptanz-Hebel nur leicht bewegt

Die Akzeptanz-Forschung trennt zwei Variablen, die Schulung sehr unterschiedlich berührt. Im Technology Acceptance Model (TAM) sind das die wahrgenommene Nützlichkeit (perceived usefulness) und die wahrgenommene Bedienbarkeit (perceived ease of use). Holden und Karsh (2010) fassen die Übertragung von TAM auf den Klinik-Kontext im Journal of Biomedical Informatics zusammen — über die eingeschlossenen Studien hinweg ist die wahrgenommene Nützlichkeit der konstant stärkere Prädiktor der Nutzungs-Absicht. Bedienbarkeit allein trägt nicht. Schulung adressiert primär die Bedienbarkeit: wie öffne ich eine Akte, wie speichere ich einen Befund, wie navigiere ich durch die Eingabe-Maske. Sie verändert die Nützlichkeits-Wahrnehmung kaum, weil diese erst entsteht, wenn das System auf einen echten Fall am echten Arbeitsplatz trifft. Die Übersicht ist methodisch heterogen — viele eingeschlossene Studien messen selbstberichtete Nutzungs-Absichten, keine beobachteten Nutzungs-Verläufe; das ist die Grenze der Forschungsbasis.

Die zweite Lesart ist noch grundsätzlicher. Lapointe und Rivard (MIS Quarterly 2005) zeigen am Material dreier Klinik-Fallstudien, dass Widerstand gegen IT-Einführung kein individuelles Charakter-Phänomen ist und auch keine Wissens-Lücke. Widerstand ist eine adaptive Reaktion auf wahrgenommene Bedrohung von Interessen — Autonomie über die eigene Tagesarbeit, Status in der Klinik-Hierarchie, Kontrolle über den eigenen Workflow. Wer eine Bedrohung erlebt, lernt sich nicht raus. Die Studie ist qualitativ, US- und kanadische Klinik-Daten, drei Fall-Häuser; die Übertragung auf den deutschen Kontext ist methodisch, nicht eins-zu-eins-empirisch. Die Klasse des Widerstands trägt aber: Wenn ein neues Klinik-Informationssystem (KIS) die Workflow-Kontrolle der Stationsleitung beschneidet oder die ärztliche Autonomie in der Verlaufs-Doku stärker reglementiert, ist Schulung die Antwort auf eine Frage, die niemand gestellt hat.

Die zwei strukturellen Faktoren, die Akzeptanz tragen

Aus der konsolidierten Forschung lassen sich zwei strukturelle Faktoren ableiten, an denen Akzeptanz tatsächlich kippt. Der erste betrifft die Tagesarbeit selbst — ob das neue Werkzeug am echten Routine-Fall messbar entlastet, am Arbeitsplatz, nicht im Schulungs-Beispiel. Venkatesh et al. (2003) formulieren das in der Unified Theory of Acceptance and Use of Technology (UTAUT) als Performance Expectancy: das Ausmaß, in dem die Person erwartet, dass das System die Aufgabe besser oder schneller erledigt. Über die UTAUT-Empirie hinweg ist Performance Expectancy einer der stärksten Prädiktoren der Nutzungs-Absicht. Übersetzt in den Klinik-Alltag heißt das: Wenn der Aufnahme-Bericht in der neuen Software eine Minute länger dauert als im alten Workflow, ist die Akzeptanz-Frage entschieden, bevor das Schulungs-Modul beginnt. Wenn die ärztliche Verlaufs-Doku drei zusätzliche Klicks pro Eintrag erfordert, sammelt sich der Widerstand nicht in den Sitzungs-Räumen, sondern in der täglichen Stations-Visite. Die UTAUT ist nicht im Klinik-Kontext entwickelt; die Übertragung erfolgt durch Folge-Studien, und die Prädiktor-Stärken variieren je nach Domäne — die Klasse der Variable bleibt aber dieselbe. Der operative Test ist deshalb nicht das Schulungs-Beispiel, sondern der gemessene Vorher-nachher-Workflow an einem typischen Routine-Fall: dieselbe Aufnahme, derselbe Bericht, dieselbe Verlaufs-Eintragung. Ist der Workflow ehrlich verglichen kürzer oder ergonomisch leichter, trägt der erste Faktor; ist er es nicht, kann auch das beste Schulungs-Konzept ihn nicht ersetzen.

Der zweite Faktor steht im Verhältnis zur Klinik selbst — ob der Roll-out mit den Schlüsselpersonen der Stationen geführt wird oder über sie hinweg. In der UTAUT ist das Social Influence — der wahrgenommene Druck oder die Ermutigung wichtiger Bezugs-Personen. In der CFIR-Sprache ist es der innere Kontext, ergänzt um die Domäne der individuellen Akteur:innen. Schlüsselpersonen sind in der Klinik nicht nur die Chefärzt:innen — sie umfassen die erfahrenen Stationsleitungen, die ärztlichen Multiplikator:innen, die IT-affinen Therapeut:innen, die in den Pflege-Übergaben und ärztlichen Frühbesprechungen die Lese-Richtung der Software-Bewertung vorgeben. Sie sind selten die Personen, die in einer Steuerungsgruppe sitzen, und genau das ist der Punkt: Ihre Lese-Richtung entsteht im Stations-Alltag, nicht im Steuerungs-Termin. Werden sie in die Workflow-Konfiguration eingebunden und ist ihr Eingabe-Pfad im Setup sichtbar berücksichtigt, trägt der Roll-out auch durch unbequeme Wochen — wenn die Software bei einer Subset-Funktion aussetzt, bleibt der Pilot trotzdem in Betrieb, weil die Schlüsselpersonen ihn intern decken. Wird über sie hinweg konfiguriert, kippt die Akzeptanz unabhängig vom Schulungs-Aufwand — die Software gilt dann als Geschäftsführungs-Anliegen, nicht als Stations-Werkzeug, und jede technische Schwäche sammelt sich auf dieses Etikett. Der operative Test ist die Frage, ob die Schlüsselpersonen vor dem Go-Live an mindestens drei Konfigurations-Entscheidungen sichtbar mitgewirkt haben — nicht ob sie über die Entscheidungen informiert wurden.

Was das in der Praxis verändert

Die jüngeren Klinik-IT-Empirie-Befunde aus den Jahrgängen 2023–2026 in Implementation Science, in BMJ Open und im Journal of the American Medical Informatics Association (JAMIA) konvergieren auf drei wiederkehrende Pattern erfolgreicher Roll-outs: eine benannte klinische Champion-Person, eine Vor-Ort-Begleitung der Anbieter-Seite in den ersten Wochen, und eine vorab vereinbarte Erwartungs-Disziplin zwischen Anbieter und Klinik. Die deutsche Anker-Referenz dazu ist die Programm-Arbeit der Charité-Arbeitsgruppe Clinical Implementation Science in Digital Health (CIDH) im EviDoc-Programm, in der dieselben Determinanten — Bereitschaft, Begleitung, Erwartungs-Disziplin — als wiederkehrende Befunde in deutscher Klinik-Praxis dokumentiert sind. Die Empirie ist methodisch heterogen, die Pattern sind aber stabil über Studien-Designs hinweg. Für die Geschäftsführer:in heißt das: Der Hebel liegt nicht im Schulungs-Budget. Er liegt in drei sehr konkreten Fragen — wer die klinische Champion-Person ist und welche Stundenzahl ihrer Stelle für die Implementierung explizit freigestellt ist; wie die Vor-Ort-Personentage des Anbieters in den ersten dreißig Tagen schriftlich verankert sind, nicht als „Support nach Bedarf“, sondern als zugesagte Anwesenheit; und ob die Workflow-Konfiguration mit den Schlüsselpersonen geschieht oder über sie hinweg. Die ersten beiden Fragen sind Vertrags-Fragen, die dritte ist eine Frage der internen Implementierungs-Disziplin. Alle drei kosten nichts in der Schulungs-Spalte des Implementierungs-Budgets — und alle drei verschieben den Akzeptanz-Hebel in die Richtung, in der die Forschung ihn vermutet.

Auf einen Satz verdichtet: Akzeptanz wird in den ersten zwei Wochen entschieden, am tatsächlichen Arbeitsplatz, nicht im Schulungs-Raum drei Wochen vorher. Wer das Schulungs-Paket weiter als zentralen Hebel formuliert, beantwortet eine ergonomische Frage und lässt die strukturelle offen. Die strukturelle Frage trifft die Geschäftsführer:in dort, wo sie ihre stärksten Hebel hat — in der Anbieter-Vertragsgestaltung, in der Stellen-Beschreibung der internen Champion-Person, in der Konfigurations-Disziplin gegenüber den Schlüsselpersonen der Stationen. Das verlagert das Change-Management-Geld in eine andere Spalte des Implementierungs-Budgets, und es macht die Akzeptanz-Frage zu einer Strukturfrage, die sie immer schon war.