Wenn Plattformen wachsen: Drei Skalierungs-Fragen vor jeder Anbieter-Erweiterung

Eine Vermittlungs-Plattform, die seit drei Jahren in einem Verbund läuft, ruft zur Vertrags-Verlängerung. Auf der Roadmap-Folie steht ein neues Modul: Dokumentations-Künstliche-Intelligenz (Dokumentations-KI), als Teil derselben Oberfläche. Die Demo zeigt ein Eingabe-Feld, in das ein Akut-Beispielfall eingetippt wird; das Ergebnis erscheint in einem Vorschlag, den die ärztliche Hand bestätigt. Die Geschäftsführerin fragt zurück, wie die Datenschicht für den Freitext-Verlauf umgebaut wurde. Die Antwort kommt schnell: „Wir lesen das Feld in unsere bestehende Pipeline ein.“ Die Frage bleibt im Folge-Termin liegen, der in der Beschaffungs-Realität selten so stattfindet wie auf der Folie versprochen — und genau hier entscheidet sich, ob die Erweiterung architektonisch trägt oder ob die Plattform die Tiefenschicht zur Klinik-Geschäftsführung verschiebt.

Plattform-Erweiterungen sind in der Klinik-IT die Regel, nicht die Ausnahme. Eine Plattform, die mit Vermittlung zwischen Akut-Klinik und Reha-Einrichtung begonnen hat, kündigt zwei Jahre später Dokumentations-KI an, ein weiteres Jahr später Codier-Unterstützung, und im dritten Jahr agentische Prozesse, die mehrere Schritte verketten. Die Reifegrad-Berichterstattung der Healthcare Information and Management Systems Society (HIMSS) beschreibt diesen Erweiterungs-Pfad als typische Trajektorie ihrer Healthcare-AI-Reifegrad-Modelle; Datenschicht, Personen-Adoption und Audit-Funktion entwickeln sich darin auf unterschiedlichen Zeit-Achsen, nicht synchron. Die Hype-Cycle-Methodologie von Gartner ergänzt die Beobachtung um eine Markt-Beobachtung: Erweiterungen treten häufig im Stadium der überhöhten Erwartung auf den Markt, lange bevor die Funktion produktiv tragfähig ist. HIMSS ist Branchen-Fachpublizistik mit Industrie-Beirat, kein peer-reviewed Standard; Gartner-Reports beruhen auf Analysten-Urteil. Beide Linien tragen jedoch ein gemeinsames Bild: eine Erweiterungs-Ankündigung beantwortet noch keine Frage zur strukturellen Tragfähigkeit.

Frage A: Wie wurde die Datenschicht umgebaut?

Eine Vermittlungs-Plattform liest in der Regel wenige strukturierte Felder — Diagnose-Code, Indikation, Versichertenstatus, Zielort, Zeitfenster. Eine Dokumentations-KI liest etwas anderes: Freitext-Anamnesen, Verlaufs-Notizen, Befunde, Pflege-Einträge. Die Datenschicht zwischen den beiden ist nicht dieselbe; sie ist nicht durch ein zusätzliches Feld erweiterbar. Sie muss strukturell für eine andere Tiefe gebaut werden — mit Provenienz pro Aussage, mit Konsistenz-Regeln über mehrere Verläufe hinweg, mit Zeitstempel- und Quellen-Index, der eine spätere Anfrage des Medizinischen Dienstes (MD) nicht in einer ungesicherten Spalte beantwortet. Wer eine Dokumentations-Erweiterung als „zusätzliches Feld in unsere bestehende Pipeline“ beschreibt, hat den Sprung in der Datenschicht nicht beschrieben — er hat ihn übersprungen. Das Tiefenproblem wandert dann zur Klinik-Geschäftsführung und zur Klinik-IT-Leitung, die in der laufenden Versorgung sehen werden, was die Pipeline trägt und was nicht.

Eine umgebaute Datenschicht ist im Beschaffungs-Gespräch erkennbar an drei Beobachtungen. Erstens an der Provenienz: Jede generierte Aussage lässt sich auf eine Quell-Notiz, einen Befund, einen Verlaufs-Eintrag zurückführen — und die Plattform zeigt diese Rückverfolgung in der Demo, nicht erst auf Rückfrage in einem späteren Termin. Zweitens an der Konsistenz: Wenn an drei Stellen einer Akte unterschiedliche Aussagen zur Begleit-Diagnose stehen, wird der Widerspruch sichtbar gemacht, statt in einer geglätteten Zusammenfassung weggebügelt; eine reife Plattform liefert hier eine Lücken-Anzeige, keine geschlossene Prosa. Drittens an der Versions-Spur: Eine erste Vorschlags-Version, eine ärztliche Korrektur, eine pflegerische Ergänzung lassen sich getrennt rekonstruieren. Eine Plattform, deren Erweiterung diese drei Beobachtungen in der Demo nicht zeigt, hat die Datenschicht nicht erkennbar umgebaut. Sie hat ein Eingabe-Feld hinzugefügt — und das ist eine andere Aussage als ein Datenschicht-Sprung. Die Beobachtung gilt unabhängig davon, ob das hinzugefügte Modul aus eigener Entwicklung kommt oder als zugekaufte Funktion in die Plattform integriert wurde; die Frage ist nicht, woher die Funktion stammt, sondern wie die Pipeline für ihre Tiefe verändert wurde.

Frage B: Welche neuen Personen werden adressiert — und wie tief?

Eine Vermittlungs-Plattform hat ihre Kontaktstelle in der Klinik im Sozialdienst und im Belegungs-Management. Eine Dokumentations-Erweiterung trifft eine andere Personen-Gruppe: die ärztliche Routine an der Akte, die pflegerische Verlaufs-Dokumentation, in einer zweiten Welle die Codier-Stelle. Diese Gruppen sind im Mengengerüst, in der Schulungs-Logik und in der Eskalations-Schwelle anders verfasst. Eine Sozialdienst-Anwender:in arbeitet pro Tag an einer überschaubaren Zahl von Übergängen; eine Stationsärzt:in arbeitet an dreißig bis fünfzig Akten gleichzeitig, mit Unterbrechungen, im Stehen am Computer auf dem Stationsgang. Die zweite Gruppe verzeiht eine zähe Eingabemaske weniger als die erste. Eine Plattform-Erweiterung, deren Roadmap-Folie die Sozialdienst-Personae der Gründungsphase abbildet, aber die ärztliche Akten-Routine als „weitere Anwendung“ in einem Satz erwähnt, hat den Personen-Sprung nicht eingeplant — sie hat ihn unterstellt.

Die Tiefe des Personen-Sprungs ist eine zweite Achse der Frage. Eine Erweiterung kann der ärztlichen Routine einen Vorschlag anbieten, den die Ärzt:in vor der Akte freigibt; sie kann auch generierten Text in die Akte schreiben, der ungelesen weiterläuft, weil die Schicht-Last die Freigabe-Geste verschiebt. Beide Varianten sind technisch dieselbe Erweiterung; sie sind zwei verschiedene Architektur-Entscheidungen. Die Plattform, die in ihrer Demo den Vorschlags-Modus zeigt, kann in der Produktion in den Auto-Schreib-Modus rutschen, wenn die Roadmap-Folie den Schwellen-Punkt nicht beschreibt. Die Klinik-IT-Leitung erkennt diese Achse an der Frage, ob die Plattform den Freigabe-Schritt unterscheiden kann von der Schreib-Aktion — und ob die Spur der Freigabe in der Akte sichtbar bleibt. Eine Erweiterung ohne diese Unterscheidung verlagert ärztliche Verantwortung in einen Schwebezustand, der in der Audit-Frage später aufschlägt.

Frage C: Wie verändert sich die Audit-Spur?

Eine Vermittlungs-Spur ist im Audit kompakt: Anfrage gestellt, Platz angeboten, Patient:innen-Übergabe abgeschlossen. Drei Ereignisse pro Vorgang, klare zeitliche Abfolge, klare Verantwortliche pro Stelle. Eine Dokumentations-Spur ist tiefer: pro Aussage Quelle, Zeitstempel, ärztliche Verantwortung, Korrektur-Versionen. Eine agentische Erweiterung, in der mehrere Stufen automatisch ineinandergreifen, ohne dass die ärztliche Hand zwischendurch eine Freigabe erteilt — eine Aufnahme-Notiz wird in eine Codier-Empfehlung übersetzt, die in einen Berichtsentwurf einfließt, der an die nächste Versorgungs-Stufe geht — multipliziert die Audit-Anforderung. Sie addiert sie nicht. Jeder Verkettungs-Schritt ist eine eigene Entscheidung, eine eigene Stelle der Verantwortung, eine eigene Quelle möglicher Drift gegenüber den Ausgangs-Daten. Die peer-reviewte Fachzeitschrift Implementation Science modelliert in NASSS- und CFIR-basierten Bewertungs-Rahmen genau diese Achse als unabhängige Domäne — institutionelle Audit-Erwartung — neben Datenstruktur und Personen-Adoption. Die Studien sind überwiegend US- und UK-zentriert; deutsche Klinik-Spezifika wie der Medizinische Dienst, die Deutsche Rentenversicherung (DRV) und die Förderkulisse des Krankenhauszukunftsgesetzes (KHZG) sind in den Rahmen nicht durchgängig vertreten. Die Achsen-Logik trägt jedoch — und sie zeigt, dass die Audit-Spur einer Erweiterung nicht aus der Vermittlungs-Spur durch Hinzufügung entsteht, sondern strukturell anders gebaut sein muss.

Aiomics tritt am Beschaffungs-Tisch der Erweiterungs-Diskussion nicht als Plattform-Versprechen auf; die drei Fragen sind ein Beschaffungs-Werkzeug, kein Anbieter-Etikett. Ein früheres Aiomics-Stück, „Vier Fragen vor dem Klinik-KI-Einkauf, die Anbieter:innen ungern hören“, hat vier Beschaffungs-Fragen für die Erst-Auswahl formuliert. Die drei Fragen dieses Beitrags setzen daneben — sie gelten dem Erweiterungs-Sprung einer bereits laufenden Plattform, in der die Vertrags-Verlängerung den Hebel bildet. Die Klinik-IT-Leitung kann die drei Fragen technisch verifizieren; die Datenschicht-Antwort ist in der Demo prüfbar, die Personen-Tiefe in der Roadmap-Tabelle ablesbar, die Audit-Spur in der Architektur-Skizze nachvollziehbar. Eine Plattform, die die Verifikation an einer der drei Achsen verweigert oder umgeht, beschreibt nicht ihre Erweiterungs-Tragfähigkeit; sie beschreibt nur ihre Roadmap-Folie.

Die Roadmap-Sprache wird in der nächsten Beschaffungs-Generation weiter wachsen. Das ist eine Eigenschaft des Marktes, kein Defekt einer einzelnen Plattform. Die Disziplin, die im Erweiterungs-Gespräch trägt, ist die Reihenfolge der drei Fragen — als Werkzeug, nicht als Verdacht. Eine Plattform, die die drei Fragen substantiell beantwortet, beschreibt ihren Datenschicht-Umbau, ihren Personen-Sprung und ihre Audit-Spur über die neuen Schritte hinweg. Eine, die ausweicht, nutzt das Etikett „nächste Generation“, ohne die strukturelle Tragfähigkeit zu zeigen. Eine Plattform-Erweiterung ist eine Architektur-Entscheidung über Datenschicht, Personen-Sprung und Audit-Spur — die Roadmap-Folie zeigt davon keine, und die Folge einer übersprungenen Strukturschicht trägt nachher die Klinik-Geschäftsführung über den gesamten Vertrags-Lebenszyklus der Plattform.