Multi-Standort-Rollout: Eine Implementierung oder mehrere

In einer Konzern-Strategie-Sitzung einer Klinikgruppe mit acht Standorten liegt das Lasten-Heft für eine neue Klinik-Software auf dem Tisch. Drei der Standorte verfügen über ein Krankenhaus-Informations-System (KIS) eines Anbieters, vier ein anderes, einer betreibt eine eigene Misch-Lösung mit dreizehn Schnittstellen. Die Frage, die in dieser Sitzung selten formuliert wird, lautet nicht, welcher Anbieter gewinnt. Sie lautet: eine zentrale Einführung mit lokalen Anpassungen oder mehrfache Einführungen mit verbindlichen Konzern-Standards. Beide Wege existieren in jeder Klinikgruppe nebeneinander, beide haben Kosten, und beide werden meist nicht entschieden, sondern unter Zeitdruck delegiert — an die Konzern-IT, die zentralisiert, oder an den Standort, der zuerst startet. Zwei Jahre später ist die Wahl getroffen, die niemand explizit getroffen hat.

Warum die Strukturfrage keine IT-Frage ist

Die Implementation-Science-Forschung der letzten zwanzig Jahre ordnet die Determinanten von Klinik-Software-Implementierungen entlang konsolidierter Frameworks. Damschroder et al. (2009) ordnen sie 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. Der innere Kontext umfasst die organisationale Kultur, die verfügbaren Ressourcen, die Führungs-Aufmerksamkeit und die Vernetzung im Haus. Diese Domäne variiert je Standort, auch innerhalb derselben Klinikgruppe. Das Framework ist deskriptiv und ordnet die Determinanten, ohne Erfolgs-Wahrscheinlichkeiten zu quantifizieren. Greenhalgh et al. (2017) erweitern im Nonadoption-Abandonment-Scale-up-Spread-Sustainability-Framework (NASSS) im Journal of Medical Internet Research (JMIR) auf sieben Komplexitäts-Domänen. Multi-Site-Spread und Sustainability sind in NASSS eigene Domänen, nicht Unter-Aspekte der Adoption. Die Beobachtung trägt: eine Einführung, die an einem ersten Standort funktioniert, wiederholt sich an einem zweiten nicht zwingend identisch. Die Beschreibung ist qualitativ; sie sortiert die Komplexität, sie sagt nicht voraus, welche Domäne im Einzelfall die Adoption an welchem Standort kippt.

Die Versorgungs-Forschung bestätigt die Beobachtung. Reviews in Implementation Science (2020–2025) dokumentieren konvergent, dass Multi-Site-Implementierungen über mehrere Standorte hinweg Inter-Site-Variabilität in Adoption und Sustainment zeigen, auch wenn die zentrale Methodik identisch ist. Die Reviews aggregieren Studien unterschiedlicher Methodik und unterschiedlicher Versorgungs-Settings; die genaue Effekt-Größe variiert je Indikation und System. Die meisten Studien stammen aus US-amerikanischen oder britischen Gesundheits-Systemen mit anderer Trägerstruktur — Veterans Affairs, National Health Service, Kaiser Permanente — und sind nicht eins-zu-eins auf die deutsche Klinik-Landschaft mit gemischter Trägerschaft (öffentlich, freigemeinnützig, privat) übertragbar. Die strukturelle Beobachtung der Inter-Site-Variabilität trägt; die Punkt-Schätzungen einzelner Studien sind nicht aggregierbar.

Zwei weitere Frameworks geben der Strukturfrage Schärfe. Glasgow et al. (1999) unterscheiden im RE-AIM-Framework (Reach, Effectiveness, Adoption, Implementation, Maintenance) zwischen der Reichweite einer Implementierung über Settings und ihrer Treue (Implementation fidelity) am einzelnen Setting. Multi-Standort-Implementierungen verlieren in der Adoption- und Maintenance-Dimension, wenn die Treue nicht je Standort gemessen wird. Aarons et al. (2011) trennen im EPIS-Framework (Exploration-Preparation-Implementation-Sustainment) explizit zwei Ebenen: die System-Ebene und die Organisationen-Ebene. In einer Klinikgruppe ist die Klinikgruppe die System-Ebene, der einzelne Standort die Organisationen-Ebene. Die zentrale Beobachtung der Multi-Site-Forschung steht hier: Implementierungen scheitern systematisch, wenn die System-Ebene und die Organisationen-Ebene nicht beide bedient werden. Die Frameworks sind beschreibend; die Übertragung auf den deutschen Träger-Kontext ist methodisch, nicht eins-zu-eins-empirisch. Was sie tragen: die Strukturfrage hat zwei Ebenen, die nicht gegeneinander aufgehen.

Was den deutschen Kontext besonders macht

Die deutsche Klinik-Landschaft hat zwei Eigenheiten, die der internationale Befund nicht direkt mitführt. Erstens: die Trägerschaft ist gemischt. Das Statistische Bundesamt führt in seinen Grunddaten der Krankenhäuser Trägergruppen — öffentlich, freigemeinnützig, privat — als parallele Strukturen; Klinikgruppen mit Mehr-Standort-Trägerschaft führen zwischen einigen wenigen und über hundert Standorten unter einem gemeinsamen Träger. Diese Träger-Vielfalt ist nicht harmonisiert, und sie ist nicht einheitlich gewachsen: Akquisitionen, Fusionen und Trägerwechsel haben in den letzten zwei Jahrzehnten Standort-Konstellationen produziert, in denen Software-Bestand, Personal-Kultur und ärztliche Tradition je Standort historisch gewachsen sind. Zweitens: die Versorgungs-Logik. Die Bundesarbeitsgemeinschaft für Rehabilitation (BAR) formuliert Rahmen-Empfehlungen für Versorgungs-Strukturen über Träger und Standorte hinweg, ohne die operative Software-Wahl zu steuern. Die Empfehlung wirkt rahmend, die operative Wahl bleibt der Klinikgruppe. Was daraus folgt: jede Standort-Entscheidung trägt eine Geschichte, die jüngere Implementation-Science-Frameworks nicht immer mitführen.

Vier Merkmale, an denen sich die Wahl entscheidet

Aus der konsolidierten Forschung und der deutschen Versorgungs-Realität lassen sich vier Merkmale ableiten, an denen die Strukturfrage sich strukturell entscheidet. Erstens: die Steuerungs-Tiefe. Wer entscheidet bei einem Zielkonflikt zwischen einem Standort-Spezifikum (etwa eine eigene Therapie-Pfad-Logik in der orthopädischen Reha-Klinik) und einem Klinikgruppen-Standard (etwa ein gemeinsames Codier-Schema)? Wenn die Antwort lautet: „Das wird im Einzelfall geklärt“ — dann läuft die Implementierung in eine Drift, die in jeder NASSS-Domäne nachhall. Wenn die Antwort lautet: „Die Steuerungs-Linie ist explizit, wird vorab dokumentiert und gilt für die ersten zwölf Monate“ — dann hat die Klinikgruppe die Strukturfrage entschieden, bevor der Anbieter ausgewählt ist. Zweitens: die Vernetzungs-Pflichten. Die elektronische Patientenakte (ePA) für alle der gematik — bundesweit ausgerollt seit April 2025, Befüllungs-Pflicht seit Oktober 2025 — wirkt sektoral und über Klinik-Standorte hinweg, schafft aber selbst keine Standort-übergreifende Software-Standardisierung in der Klinikgruppe. Sie ist das Außen-Interface, nicht die innere Klinikgruppen-Architektur. Wenn die Klinikgruppe diese Differenz nicht klärt, übernimmt sie die externe Schnittstellen-Logik als interne Standard-Logik — und gerät in eine Architektur, die sie nicht entworfen hat.

Drittens: die Adaptions-Tiefe. Der zentrale Pfad mit lokalen Adaptionen kennt zwei Adaptions-Klassen — Konfiguration (innerhalb der Anbieter-Logik vorgesehene Variablen) und Customizing (Eingriff in den Anbieter-Code oder in dessen Daten-Modell). Konfiguration trägt die Standort-Heterogenität meist gut, weil sie im Anbieter-Vertrags-Standard mitläuft. Customizing trägt sie selten gut, weil jede Aktualisierung des Anbieters Customizing-Konflikte produziert, die je Standort gelöst werden müssen. Wenn die Standort-Heterogenität so tief sitzt, dass sie in Customizing-Tiefe geht, dann ist der zentrale Pfad der teurere, nicht der schlankere Weg — und der mehrfach-parallele Pfad mit gemeinsamem Codier-Schema und getrennter Software trägt strukturell besser. Viertens: die Begleitungs-Verantwortung. An welchem Standort ist namentlich benannt, wer in den ersten Wochen nach Go-Live für die Implementierung verantwortlich ist, mit Eskalations-Recht in die Klinikgruppen-Ebene? Wenn diese Stelle nicht benannt ist, sondern als Querschnittsaufgabe der Standort-Leitung verstanden wird, fällt sie in der Routine-Last der ersten Tage aus — und die Implementierung verliert ihre Sustainment-Domäne, bevor sie eine entwickelt hat.

Wo Multi-Standort-Einführungen strukturell scheitern

Die wiederkehrenden Scheitern-Pattern lassen sich aus der konvergenten Lesart der vier Frameworks gut sortieren. Das erste: die Strukturwahl wird unter Zeitdruck delegiert, statt entschieden. Die Konzern-IT zentralisiert per Voreinstellung, weil sie zentralisiert denkt; oder der Standort, der zuerst startet, setzt die Lokal-Logik als Konzern-Standard. Beide Wege sind nachvollziehbar; beide produzieren eine Strukturwahl, die niemand explizit verantworten kann. Das zweite: die Implementation fidelity wird nicht je Standort gemessen. Im RE-AIM-Sinne fällt die Klinikgruppe damit in den Bewertungs-Schatten — der Konzern weiß, was er ausgerollt hat, aber nicht, was an jedem einzelnen Standort tatsächlich angekommen ist. Das dritte: die System-Ebene und die Organisationen-Ebene werden gegeneinander geführt, statt parallel bedient. Aarons et al. nennen das die zentrale Implementierungs-Falle. In der Praxis erscheint sie als Lager-Bildung — die Konzern-IT misstraut den Standorten, die Standort-Leitung misstraut der Konzern-IT, und die Implementierung läuft in Reibungs-Verluste, die niemand budgetiert hat. Das vierte: die Sustainment-Domäne wird der Implementierungs-Domäne nachgeordnet. Die Einführung wird über die ersten neunzig Tage geplant, die Pflege über die nächsten drei Jahre nicht. Drei Jahre nach Go-Live ist die Software dieselbe; die Klinikgruppe nutzt sie nicht mehr in der ursprünglich geplanten Form, weil jeder Standort sich seine eigene Praxis-Routine angeeignet hat — und die Strukturwahl muss erneut getroffen werden, ohne dass die erste je explizit war.

Multi-Standort-Implementierungen scheitern selten an der Software. Sie scheitern an einer Strukturwahl, die nicht als Wahl behandelt wird. Wo eine Klinikgruppe explizit entscheidet, welche Stellen zentral und welche je Standort liegen, und wer bei Zielkonflikten entscheidet, hat sie eine Architektur, die ihre Inter-Site-Variabilität trägt. Wo sie diese Strukturwahl unter Zeitdruck delegiert, hat sie eine Implementierung, die zwei Jahre später als Software-Frage wieder auftaucht — obwohl sie nie eine war. Eine Implementierung oder mehrere ist die falsche Frage, wenn sie als Effizienz-Frage gestellt wird. Sie ist die richtige Frage, wenn sie als Frage der Steuerungs-Logik gestellt wird, die die Klinikgruppe leben kann.