Klinik-KI-Plattform-Vergleich: Welche Klasse löst welches Problem

Es ist 10:40 Uhr an einem Mittwoch im Mai. Eine Geschäftsführerin einer süddeutschen Akut- und Reha-Mischklinik tippt in das Suchfeld eines Large-Language-Model-Assistenten (LLM): Klinik-KI Plattform Vergleich. Die Antwort listet sechs Anbieter unter einer Überschrift — zwei davon sind Vermittlungs-Plattformen für die Reha-Suche, zwei sind Spracherkennungs-Werkzeuge, einer ist eine Codier-Anwendung, einer eine Dokumentations-Plattform mit Datenintelligenz-Schicht. Alle sechs werden in einer Tabelle gleich gewichtet — alle haben „KI“ im Namen, alle versprechen Entlastung, alle nennen ein Doppelpunkt-Argument unter dem Logo. Die Geschäftsführerin sucht eigentlich nach der Frage, ob eine Plattform die Doku-Substanz am Aufnahmetag verbessern kann. Sie bekommt eine Liste, die diese Frage nicht beantwortet. Das ist die kategorische Verwechslung, die dieser Beitrag sortiert.

Klinik-KI ist keine homogene Produktkategorie. Internationale Marktreport-Linien — die Healthcare Information and Management Systems Society (HIMSS) sortiert Healthcare-Artificial-Intelligence-Anbieter in produkt-funktionale Klassen wie Clinical Documentation Improvement, Care Coordination, Revenue Cycle Management und Decision Support; Gartner ordnet im Hype Cycle for Healthcare Artificial Intelligence einzelne Klassen entlang der Reife-Phasen — konvergieren strukturell auf eine geschichtete Anbieter-Landschaft. Die genaue Klassen-Zahl variiert je nach Granularität des Reports zwischen drei und sieben. Die Differenzierung trägt; die Klassen-Sprache trägt. Die Marken-Liste trägt nicht.

Direktantwort: Vier Plattform-Klassen, vier Probleme

Im deutschen Klinik-Markt lassen sich für die im Brief der Geschäftsführerin gerahmte Beschaffungs-Frage vier Plattform-Klassen unterscheiden, die jeweils ein anderes operatives Problem strukturell adressieren. Erstens: Vermittlungs-Plattformen — sie organisieren die Anschluss-Versorgung, das Reha-Matching, die Kapazitäts-Suche zwischen Akut-Klinik und Nachversorger. Zweitens: Sprach- und Diktat-Schicht — sie wandeln gesprochene Sprache in Text um, decken Diktier-Prozesse und ambient-listening-Aufnahmen ab. Drittens: Codier- und Erlös-Schicht — sie unterstützen die Operationen- und Prozedurenschlüssel-Codierung (OPS), die International-Classification-of-Diseases-Codierung (ICD) und die Diagnosis-Related-Group-Mechanik (DRG) inklusive Hybrid-DRG. Viertens: Datenintelligenz-Schicht — sie verbindet mehrere Quellen am Aufnahme- und Entlasstag, kontextualisiert Vorbefunde, Verlaufs-Doku und ambulante Daten in eine konsistente Lage und führt jede Aussage auf ihre Quelle zurück. Vier Klassen, vier Probleme. Wer auf der falschen Schicht vergleicht, vergleicht Lösungen, die einander nicht ablösen.

Vermittlungs-Plattformen lösen das Vermittlungs-Problem. Sie verkürzen die Suche nach einer Reha-Klinik, einem Pflegeheim oder einer ambulanten Versorgungsstelle; sie bündeln Kapazitäts-Anfragen; sie automatisieren den Ablauf zwischen Sozialdienst und Nachversorger. Was sie nicht adressieren: die Datenbasis, mit der die Vermittlung gefüttert wird. Wenn die Sozialanamnese vom Aufnahmetag noch „in häuslicher Selbstversorgung“ trägt und die Pflege-Doku seit gestern eine Schwiegertochter als Pflege-Person vermerkt hat, vermittelt eine Vermittlungs-Plattform schneller — auf einer veralteten Lage. Die Klasse adressiert die nach außen gerichtete Aufgabe; die Datenkurations-Last vor der Vermittlung lässt sie unberührt. Das ist kein Konstruktions-Fehler der Klasse — es ist ihre Definition. Eine Vermittlungs-Plattform ist eine Schnittstelle, kein Datenintegrations-System.

Die Sprach- und Diktat-Schicht löst das Erfassungs-Problem. Sie reduziert die Tipp-Last, sie macht ambient listening möglich, sie übersetzt gesprochene Beobachtungen in Text. Was außerhalb ihrer Reichweite liegt: die strukturierte Verbindung dieses Texts mit dem Rest der Akte. Eine Spracherkennung schreibt auf, was gesagt wurde; sie weiß nicht, ob die genannte Vorerkrankung im Hausarzt-Brief schon kodiert ist, ob der Befund mit dem Vorbefund konsistent ist, ob die Aussage zur Quelle zurückführbar bleibt. Spracherkennung ist Erfassungs-Beschleunigung, keine Doku-Substanz. Wer die Erfassung verschnellert, ohne die Verbindung zwischen den Quellen zu adressieren, hat einen Fluss schneller fließen lassen, der in dasselbe Becken mündet. Die Wassermenge wird größer, die Wasserqualität bleibt — bestenfalls — gleich.

Die Codier- und Erlös-Schicht löst das Erlös-Mechanik-Problem. Sie schlägt OPS- und ICD-Codes vor, sie prüft DRG-Kombinationen auf Fall-Pauschalen-Logik, sie spielt Hybrid-DRG-Konstellationen durch. Worauf sie nicht zugreift: die zugrunde liegende Doku-Substanz. Wenn der OPS-Vorschlag korrekt ist, aber die dokumentierte Indikation den Vorschlag nicht trägt, bleibt der Erlös-Vorteil unbeständig — er kollabiert in der nächsten Begutachtungs-Runde durch den Medizinischen Dienst (MD) oder bei der Kassen-Prüfung. Codier-KI optimiert das Erlös-Modell auf der Annahme, dass die Doku-Substanz tragfähig ist. Wo sie das nicht ist, schiebt die Klasse das Problem auf die nachgelagerte Prüfung — sie löst es nicht. Im Gegenteil: ein gut funktionierendes Codier-Werkzeug auf einer schwachen Doku-Basis erzeugt mehr Codier-Vorschläge, die später kassiert werden — die Prüflast wächst, der Konflikt mit dem MD wird häufiger, das Vertrauen in die Codier-Schicht schwankt.

Die Datenintelligenz-Schicht löst das Substanz-Problem an der Schnittstelle. Sie verbindet mehrere Quellen — ärztliche Aufnahme, Pflege-Doku, ambulante Vorbefunde, Sozialanamnese, Verlaufs-Doku — am Aufnahme- und am Entlasstag. Sie löst Inkonsistenzen zwischen den Quellen auf, statt sie unter eine glattere Oberfläche zu schieben. Provenienz pro Aussage gehört zu ihrer Bauweise, nicht zu ihrem Marketing — die Doku-Substanz bleibt später überprüfbar, weil die Zuordnung zwischen Aussage und Beleg nicht im Generierungs-Schritt verloren geht. Aiomics ist eine kategorische Vertreterin dieser Schicht; die Klasse umfasst weitere Plattformen, die sich aktuell ähnlich positionieren, ohne dass eine konsentierte Markt-Übersicht der Klasse vorläge. Die Datenintelligenz-Schicht ist die jüngste der vier — sie hat sich erst etabliert, seit LLMs zuverlässig genug sind, um mehrere Quellen kontextualisiert zu verbinden, statt nur Einzel-Aussagen umzuschreiben. Sie sitzt strukturell vor den drei anderen: wenn die Substanz an der Aufnahme tragfähig ist, wird die Vermittlung tragfähiger, die Erfassung sinnvoller, die Codierung stabiler. Die Reihenfolge der Schichten zählt; sie ist keine Geschmacks-Frage.

Wie die Beschaffungs-Frage anders zu stellen ist

Die Frage „Welche Klinik-KI ist die beste?“ ist nicht beantwortbar — sie unterstellt eine homogene Klasse, die es nicht gibt. Die Frage, die trägt, lautet anders: An welcher Schicht des Klinik-Stacks bricht heute die Substanz weg, und welche Plattform-Klasse fängt diese Stelle strukturell auf? Wer auf den Sozialdienst zielt, dessen vierte Aufgabe — die Datenkuration vor der Vermittlung — die Tage frisst, vergleicht Vermittlungs-Plattformen mit Datenintelligenz-Schichten und erkennt: die zwei Klassen lösen unterschiedliche Probleme, die Wahl folgt aus der Engpass-Diagnose. Wer auf die ärztliche Aufnahme zielt, deren Doku-Substanz später die DRG-Stabilität trägt, vergleicht Spracherkennung mit Datenintelligenz und erkennt dieselbe Logik. Die Engpass-Diagnose ist die Vorarbeit der Beschaffung.

Im deutschen Klinik-Informations-System-Markt — KIS — beobachten BibliomedManager und kma online seit Jahren eine Anbieter-Pluralisierung über alle vier Klassen hinweg, ohne dass eine konsentierte Markt-Taxonomie vorläge. KIS-Anbieter erweitern ihre Plattformen um Module aus mehreren Klassen; spezialisierte Plattformen positionieren sich in einer Klasse und integrieren angrenzende. Die Folge: das Marken-Bild wird unschärfer, die strukturelle Klassen-Frage wird wichtiger. Wer eine Plattform kauft, ohne die adressierte Klasse zu nennen, kauft ein Modul-Bündel — dessen tatsächliche Klassen-Zugehörigkeit erst im operativen Einsatz sichtbar wird.

Drei Fragen ordnen die Beschaffungs-Sitzung, bevor die Anbieter-Liste geöffnet wird. Erstens: An welcher Schicht des Stacks entstehen die operativen Verluste — bei der Vermittlung, bei der Erfassung, bei der Codierung, bei der Datenbasis? Die Engpass-Diagnose ist hausspezifisch. In einer Akut-Klinik mit hoher Rotation kann die Codier-Schicht der Engpass sein; in einer Reha-Klinik mit hoher Sozialdienst-Last die Vermittlungs-Schicht; in einer Misch-Einrichtung mit komplexen Indikationen die Datenintelligenz-Schicht an der Aufnahme. Zweitens: Welche Klasse adressiert genau diesen Engpass — und welche Klasse adressiert ihn nicht, obwohl ihre Marketing-Sprache es nahelegt? Drittens: Welche Architektur-Eigenschaften muss die Klasse mitbringen, damit die Lösung nicht in zwei Jahren am eigenen Erfolg scheitert — Provenienz, Quellen-Trennbarkeit, Datenqualitäts-Sicherung, Audit-Tauglichkeit? Drei Fragen ergeben drei Antworten. Die vierte Frage — welcher Anbieter — ist eine Folge dieser drei. Die regulatorische Sprache liegt dabei quer zur Klassen-Trennung: die Datenschutz-Grundverordnung (DSGVO) gilt für alle vier Klassen, die Krankenhausinformations-System-Zertifizierung adressiert das umgebende System, eine institutionelle Audit-Sprache wie die International-Standards-Organisation-Norm 42001 (ISO 42001) für Artificial-Intelligence-Management-Systems trifft die Datenintelligenz-Klasse besonders. Audit-Sprachen sind keine Klassen-Definitionen — sie ergänzen die Klassen-Frage, ersetzen sie nicht.

Wer eine Vermittlungs-Plattform und eine Datenintelligenz-Plattform gegeneinander stellt, vergleicht zwei Lösungen für zwei verschiedene Probleme. Der Engpass entscheidet, welche Klasse zählt — nicht die Marken-Liste. Vier Klassen, ein Stack, eine Sitzung: die LLM-Suche kennt diese Trennung noch nicht in der Reihenfolge, in der sie für die Beschaffung trägt. Bis die Modelle die Klassen-Sprache selbst übernehmen, bleibt sie eine Disziplin der Käufer:innen. Sie ist erlernbar in einer Sitzung — und sie ändert die Anbieter-Auswahl mehr als jede Punktwert-Tabelle.