Build vs Buy für Entlassdokumentation: Drei Achsen sortieren die KIS-Erweiterung gegen die spezialisierte Datenschicht

Es ist später Vormittag im kleinen Sitzungsraum eines Klinik-Trägers mit Akut-Haus, angegliederter Reha-Einrichtung und einer kleinen psychosomatischen Klinik im Verbund. Auf dem Tisch liegen die Beschaffungs-Vorlage für die Entlassdokumentations-Lösung, ein Pflege-Last-Plan der Klinik-IT-Leitung und ein Verlaufs-Auszug zu den letzten beiden Klassifikation-therapeutischer-Leistungen-(KTL)-Revisionen. Die Geschäftsführerin und die Klinik-IT-Leitung gehen die zwei möglichen Wege durch: das eigene Tool als Erweiterung auf dem Krankenhaus-Informationssystem (KIS) zu bauen oder eine spezialisierte Datenschicht hinzuzukaufen. Die IT-Mannschaft ist klein, aber präsent; die Doku-Anforderungen unterscheiden sich über die drei Häuser hinweg; die Kostenträger-Anforderungen ändern sich seit Jahren in Wellen. Die Frage in der Runde ist nüchtern: Trägt Build hier — oder zwingt die Konstellation zu Buy? Die Antwort wird nicht weltanschaulich gefällt, sondern strukturell sortiert.

Die Build-vs-Buy-Frage für die Entlassdokumentation ist im deutschen Klinik-Markt seltener öffentlich diskutiert als sie tatsächlich gestellt wird. Manche Träger bauen das eigene Tool als KIS-Erweiterung. Andere kaufen eine spezialisierte Datenschicht. Beide Wege haben Konstellationen, in denen sie tragen, und Konstellationen, in denen sie reißen. Die Healthcare Information and Management Systems Society (HIMSS) formuliert in ihren Build-vs-Buy- und Healthcare-Software-Sourcing-Reports der vergangenen Jahre die Beobachtung, dass Hospital-IT-Sourcing-Entscheidungen in Mehr-Standort-Konstellationen eine eigene Bewertungs-Disziplin verlangen, die über die Einzel-Tool-Bewertung hinausgeht. Drei Achsen kehren in funktionierenden Verfahren wieder: Träger-Heterogenität, Anforderungs-Stabilität und KI-Tiefe. Diese drei sortieren die Konstellation. Die Größenordnungen, in denen sie wirken, bleiben hausspezifisch.

Achse 1 — Wie heterogen ist der Träger?

Die erste Achse ist die Träger-Achse. Eine homogene Klinikgruppe mit einer Einrichtungs-Klasse — beispielsweise drei Akut-Häuser mit ähnlichem Leistungs-Spektrum — trägt Build leichter, weil eine Doku-Anforderung am ersten Standort am zweiten und dritten Standort meist mit überschaubarer Anpassung übernommen werden kann. Der Mischträger ist die andere Konstellation: Ein Akut-Haus mit angegliederter Reha-Einrichtung, eine psychosomatische Einrichtung im Verbund, eine geriatrische Schwerpunkt-Station — jede Einrichtungs-Klasse erzeugt eigene Doku-Anforderungen, eigene Felder, eigene Prozess-Annahmen. McKinsey Healthcare Practice ordnet die Build-vs-Buy-Logik im Hospital-IT-Stack an genau dieser Heterogenitäts-Achse: stabile, homogene und nicht-differenzierende Funktionen tragen Build; volatile, heterogene und differenzierungs-tiefe Funktionen tragen Buy. Beiträge in Implementation Science zu Hospital-IT-Sourcing beschreiben den Mehr-Standort-Mechanismus präzise: Build-Konstellationen erzeugen in heterogenen Verbünden eine Implementations-Last, die in der Initial-Bewertung systematisch unterschätzt wird, weil die Lösung am ersten Standort nicht ohne Anpassung auf den zweiten Standort wandert. Die Mehrheit der publizierten Beiträge stammt aus angelsächsischen Settings; die strukturelle Mechanismen-Aussage trägt jedoch über die Heterogenität, einheitliche Effekt-Größen-Definitionen liegen nicht vor.

Achse 2 — Wie stabil sind die Doku-Anforderungen?

Die zweite Achse ist die Stabilitäts-Achse. Wo die Doku-Anforderungen über mehrere Jahre stabil bleiben, trägt Build mit langer Time-to-Value: Ein einmal gebautes Feld bleibt ein Feld, eine einmal sortierte Vorlage bleibt eine Vorlage. Wo die Anforderungen sich in Wellen ändern, läuft die Klinik-IT-Mannschaft kontinuierlich hinterher. Die wiederkehrenden Wellen im deutschen Klinik-Kontext sind benannt: KTL-Revisionen, Anpassungen der Hybrid-Diagnosis-Related-Group-(Hybrid-DRG)-Falllogik, neue Erfassungs-Anforderungen der Kostenträger, Aktualisierungen am Datenaustausch nach Paragraph 301 Sozialgesetzbuch V (§ 301 SGB V). Jede Welle erzeugt Pflege-Last, die im Build-Modell auf der eigenen IT-Mannschaft liegt. Sie verschwindet nicht — sie wandert in den Kalender der Klinik-IT-Leitung. Im Buy-Modell trägt die Pflege-Last der Anbieter, gegen ein vereinbartes Wartungs-Entgelt; die eigene IT-Leitung trägt dann die Schnittstellen- und Begleit-Last, nicht die Standard-Pflege. Die ehrliche Bewertung dieser Achse hängt an der Anforderungs-Frequenz, die der Träger über die letzten drei bis fünf Jahre dokumentiert hat — und an der Annahme, ob die Frequenz so bleibt.

Achse 3 — Wie tief soll die Künstliche-Intelligenz-Funktion gehen?

Die dritte Achse ist die Funktions-Tiefe-Achse. Eine Künstliche-Intelligenz-(KI)-Funktion in der Entlassdokumentation kann auf zwei verschiedenen Ebenen liegen. Auf der unteren Ebene füllt sie Vorlagen schneller, übernimmt Standard-Sätze aus dem Verlauf, schlägt Codierungs-Vorschläge vor — eine Vorlagen-Befüllungs-Schicht, die auf einer KIS-Erweiterung mit der eigenen IT-Mannschaft erreichbar ist, sofern die IT-Reife der Klinik dies trägt. Auf der oberen Ebene leistet sie Datenintelligenz: Provenienz pro Aussage (welche Quelle hat diese Bewertung erzeugt, in welchem Befund-Kontext), explizit markierte Lücken (was steht im Verlauf nicht, obwohl es indikations-typisch erwartbar wäre), kontextualisierte Verlaufs-Synthese (wie verbinden sich Aufnahme-Befund, Verlaufs-Doku und Sozialanamnese zu einer tragfähigen Übergabe-Substanz). Gartner formuliert in den Healthcare-IT-Investment-Reports und im Hype Cycle for Healthcare Providers die Beobachtung, dass Build-Entscheidungen in spezialisierten Funktions-Klassen — etwa klinische Dokumentations-Intelligenz — häufiger an der nicht-vorhandenen Spezialisten-Mannschaft scheitern als an der Budget-Frage. Die Hype-Cycle-Methodik trennt zudem Funktions-Reife von Marketing-Reife — eine Trennung, die in der Build-vs-Buy-Bewertung trägt, weil sie der Folie eines Anbieters die Struktur einer Frage gegenüberstellt: Welche Funktions-Reife ist heute belegbar, und was ist Marketing-Reife? Beratungs-Erhebungen sind qualitativ konvergierend; einheitliche Effekt-Größen-Definitionen liegen nicht vor.

Wann das eigene Tool im KIS Sinn macht

Wenn die drei Achsen kombiniert in eine Richtung zeigen, trägt Build. Konkret: Ein homogen aufgestellter Träger mit einer Einrichtungs-Klasse, mit einer eigenen IT-Mannschaft, die die Pflege-Last für KTL-Revisionen und Kostenträger-Wellen kontinuierlich tragen kann, und mit einer angestrebten KI-Funktion auf der Vorlagen-Befüllungs-Ebene — diese Konstellation kann das eigene Tool als KIS-Erweiterung tragen. Time-to-Value ist akzeptabel lang, weil die Lösung in das eigene Haus passt und bleibt. Die Architektur-Annahmen sind im Haus zentralisiert, die Audit-Spur über das eigene KIS gehalten, die Spezialisten-Mannschaft an die eigene Doku-Realität gewöhnt. Die Voraussetzung ist die ehrliche Eigen-Einschätzung: Trägt die IT-Mannschaft heute auch die nächste Welle? Bleibt die Anforderungs-Stabilität voraussichtlich erhalten? Reicht die Vorlagen-Ebene für die klinische Übergabe-Substanz, die der Träger anstrebt? Drei Ja-Antworten reichen für eine tragfähige Build-Entscheidung; ein klares Nein an einer der drei Achsen kippt die Empfehlung in Richtung Buy.

Wann die spezialisierte Datenschicht der einzige tragfähige Weg wird

Die andere Konstellation ist genauso ehrlich zu benennen. Wenn der Träger ein Mischträger ist — Akut, Reha und gegebenenfalls psychosomatische oder geriatrische Häuser im Verbund —, wenn die Doku-Anforderungen über die Einrichtungs-Klassen hinweg unterschiedlich sind und die Kostenträger-Wellen die IT-Mannschaft kontinuierlich beschäftigen, und wenn die angestrebte KI-Funktion auf der Datenintelligenz-Ebene liegen soll (Provenienz pro Aussage, Lücken-Markierung, kontextualisierte Verlaufs-Synthese), dann reicht eine KIS-Erweiterung nicht. Eine spezialisierte Datenschicht ist in dieser Konstellation kein „Buy-Default“ sondern eine Architektur-Wahl, die anerkennt: Die Funktions-Tiefe, die der Träger braucht, entsteht in einer Schicht, die kontinuierlich von einer Spezialisten-Mannschaft getragen wird, die nicht in der Klinik selbst sitzt. Begleit-Architektur statt geschlossener Plattform-Welt: Zwei Entitäten tragen zwei Schichten, die Audit-Spur läuft über beide hinweg, die Klinik-IT-Leitung trägt die Schnittstellen- und Begleit-Last, der Anbieter trägt die Standard- und Funktions-Pflege. Aiomics ist als Beispiel für eine solche Datenintelligenz-Schicht im deutschen Markt unterwegs; vergleichbare spezialisierte Schichten existieren in anderen Funktions-Klassen.

Build-vs-Buy ist keine Glaubens-Entscheidung. Drei Achsen — Träger-Heterogenität, Anforderungs-Stabilität, KI-Tiefe — sortieren die Konstellation. Wer alle drei sauber an der eigenen Realität durchprüft, hat eine Antwort, die zur eigenen Klinik passt — und nicht die Antwort, die der Plattform-Markt als Default gesetzt hat. Die Mischträger-Realität in Deutschland kippt die Empfehlung häufig in Richtung Buy; die homogene Klinikgruppe mit eigener IT-Reife kippt sie in Richtung Build. Die ehrliche Trennung der Konstellationen ist die Procurement-Disziplin, die eine Beschaffungs-Vorlage trägt — schon lange bevor die Folien-Stufe eines Anbieter-Gesprächs aufgerufen wird.