In keiner Branche klafft zwischen KI-Schlagzeilen und KI-Realität eine größere Lücke als im Gesundheitswesen. Die Schlagzeilen versprechen algorithmische Diagnosen; die Realität in den meisten Kliniken und Praxen sind Ärzt:innen und Pflegekräfte, die einen großen Teil ihres Tages mit Dokumentation, Kodierung und Terminplanung verbringen, Arbeit, die KI schon heute entlasten kann, mit deutlich geringerem regulatorischem Risiko als alles, was eine Diagnose berührt. Ein Rahmen gilt für diesen gesamten Artikel: KI im Gesundheitswesen unterstützt das klinische Personal, sie ersetzt niemals dessen Urteil. Systeme, die diese Linie technisch, organisatorisch und rechtlich respektieren, sind die, die es in den Regelbetrieb schaffen. Dies ist eine Landkarte des Realistischen, keine medizinische Aussage: Jeder klinische Einsatz braucht seine eigene regulatorische und klinische Validierung.
Die Use Cases, geordnet nach Payback und regulatorischem Gewicht
Im Gesundheitswesen lässt sich das Payback-Ranking nicht von der regulatorischen Einstufung trennen: Ein Use Case, der auf dem Papier in Monaten zurückzahlt, aber eine Medizinprodukte-Zertifizierung braucht, hat eine völlig andere reale Zeitachse. Diese Tabelle ordnet nach der Kombination. Die regulatorischen Einordnungen sind Orientierung, die tatsächliche Einstufung hängt immer von der konkreten Zweckbestimmung ab und gehört in fachkundige Hände.
| Rang | Use Case | Typischer Payback-Horizont | Regulatorisches Gewicht (Orientierung) |
|---|---|---|---|
| 1 | Klinische Dokumentation & Arztbrief-Entwürfe | 6-12 Monate | Geringer, wenn jede Ausgabe klinisch geprüft und freigegeben wird; DSGVO/Patientendatenrecht gelten immer |
| 2 | Kodier- & Abrechnungsunterstützung | 6-12 Monate | Gering bis mittel; menschliche Validierung vor Einreichung ist Pflicht |
| 3 | Termin- & Kapazitätsplanung (OP, Betten, Personal) | 9-18 Monate | Geringer; operative Daten, keine diagnostische Funktion |
| 4 | Triage- & Priorisierungsunterstützung | 12-24 Monate | Hoch; je nach Zweckbestimmung mutmaßlich Medizinprodukte-Terrain, strenge menschliche Aufsicht erforderlich |
| 5 | Bildgebungs-Assistenz (Markierung zur radiologischen Prüfung) | 18 Monate+ | Hoch; typischerweise MDR-zertifizierte Software und Hochrisiko nach EU AI Act, zertifiziert kaufen statt selbst bauen |
Die regulatorische Realität: MDR, EU AI Act, DSGVO
Drei Rahmenwerke prägen jede KI-Entscheidung im europäischen Gesundheitswesen, und ihre Zweckbestimmungs-Logik entscheidet mehr als jede technische Eigenschaft. Software mit medizinischer Zweckbestimmung (Diagnose, Prävention, Überwachung, Vorhersage, Therapie) ist in aller Regel ein Medizinprodukt nach MDR; KI-Systeme, die Sicherheitskomponenten von Medizinprodukten sind oder selbst regulierte Produkte, fallen in aller Regel in die Hochrisiko-Kategorie des EU AI Act, mit Pflichten zu Risikomanagement, Daten-Governance, Transparenz, menschlicher Aufsicht und Protokollierung. Gesundheitsdaten sind besondere Kategorien nach DSGVO. Nichts davon verbietet Gesundheits-KI, es definiert den Eintrittspreis je Use Case, und der ist am niedrigsten, wo KI administrativ bleibt.
| Rahmenwerk | Wann es greift | Praktische Konsequenz |
|---|---|---|
| MDR (Medizinprodukteverordnung) | Software mit medizinischer Zweckbestimmung (Diagnose, Therapieentscheidungen, Überwachung) | Konformitätsbewertung, klinische Bewertung, Qualitätsmanagementsystem, Marktüberwachung |
| EU AI Act | KI als/in einem regulierten Medizinprodukt: Hochrisiko-Klasse | Risikomanagement, Daten-Governance, menschliche Aufsicht, Protokollierung, technische Dokumentation |
| DSGVO / nationales Gesundheitsdatenrecht | Jede Verarbeitung von Patientendaten, auch für Training und Piloten | Rechtsgrundlage, Datenminimierung, DSFA, und in Deutschland typischerweise Betriebsrats- bzw. Personalratsbeteiligung |
Das Scheitermuster: erst klinischer Pilot, dann Compliance
Das charakteristische Scheitern im Gesundheitswesen ist Enthusiasmus-Reihenfolge: Ein Team baut auf retrospektiven Daten einen beeindruckenden klinischen Vorhersage-Piloten, präsentiert ihn, und fragt erst danach Recht, Datenschutz und Betriebsrat, wie er in die Versorgung kommt. Die Antworten kommen in dieser Reihenfolge: unklarer MDR-Pfad, fehlende Rechtsgrundlage für die Trainingsdaten, kein Konzept für menschliche Aufsicht, und das Projekt friert auf unbestimmte Zeit ein. Der Pilot war echt; der Weg in den Betrieb wurde nie entworfen.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Beeindruckende retrospektive Ergebnisse, nach 18 Monaten kein Einsatz | Regulatorischer Pfad vor dem Bauen nie geklärt | Zweckbestimmung (MDR/AI Act) vor der ersten Zeile Code einordnen |
| Datenschutz stoppt das Projekt mitten im Flug | Trainings- und Pilotdaten ohne solide Rechtsgrundlage genutzt | DSFA und Rechtsgrundlage als Deliverables der ersten Woche, nicht als Nachtrag |
| Klinisches Personal misstraut dem Tool und umgeht es | Ohne klinische Fürsprecher gebaut; Ausgaben nicht nachvollziehbar | Co-Design mit Kliniker:innen; jede Ausgabe nachvollziehbar und überstimmbar |
| „KI-Strategie“ besteht aus einem Bildgebungs-Moonshot | Die administrativen Use Cases mit echtem, unglamourösem Payback übersprungen | Erst Dokumentations- und Planungs-Gewinne, klinische Unterstützung danach |
Das Team: kaufen, leihen oder ausbilden
Gesundheits-KI-Teams brauchen eine Rolle, die andere Branchen überspringen können: jemanden, der den regulatorischen und klinischen Sicherheitspfad als tatsächlichen Job verantwortet. Alles Weitere folgt der bekannten Kaufen/Leihen/Ausbilden-Logik, immer mit klinischem Personal als Mitverantwortlichen statt als nachträglich Befragten.
| Rolle | Kaufen / leihen / ausbilden | Warum |
|---|---|---|
| Senior ML Engineer (Erfahrung mit klinischen Daten) | Kaufen, oder erst leihen, dann kaufen | Langfristiger Kern; muss mit Audit-Trails und Validierungsdisziplin umgehen können |
| Data Engineer (KIS, Interoperabilität) | Kaufen | HL7-/FHIR-Anbindung und Pseudonymisierungs-Pipelines sind dauerhafte Infrastruktur |
| Regulatory-/Qualitäts-Spezialist:in (MDR, AI Act) | Leihen, mit wachsendem Portfolio Richtung Festanstellung | Knappes Profil; erst externe Beratung, mit mehr Use Cases interne Verantwortung |
| Klinische:r Fürsprecher:in (ärztliche/pflegerische Leitung) | Ausbilden (intern, Teilzeitrolle) | Nicht extern einkaufbar; Glaubwürdigkeit bei den eigenen Leuten ist der ganze Punkt |
| Datenschutzbeauftragte:r | Bestehend intern + externe Beratung | DSFA, Rechtsgrundlage und Betriebsratsprozess laufen von Tag eins über diese Rolle |
Pragmatische erste 90 Tage
Das richtige erste Quartal in der Gesundheits-KI wählt bewusst einen administrativen Use Case, Dokumentationsunterstützung ist die übliche Wahl, und behandelt Governance als Teil des Aufbaus, nicht als parallele Bürokratie. Das Ziel: ein Workflow live mit klinischer Freigabe jeder Ausgabe, und eine Governance-Vorlage, die jeder spätere Use Case wiederverwendet.
| Phase | Wochen | Was passiert |
|---|---|---|
| Zuschnitt & Governance-Aufbau | 1-3 | Einen administrativen Use Case und eine Station/Abteilung wählen; DSFA gestartet, Rechtsgrundlage geklärt, Betriebsrat informiert, Baseline gemessen (Dokumentationsminuten je Fall) |
| Daten & Integration | 4-7 | Zugriff auf die relevanten Systeme (KIS, Diktat), Pseudonymisierung wo nötig, Prompt-/Output-Protokollierung von Anfang an auditierbar gebaut |
| Begleiteter Pilot | 8-11 | Klinisches Personal nutzt Entwürfe in der echten Dokumentation mit verpflichtender Prüfung und Korrektur; Korrekturaufwand und Zeitersparnis gegen die Baseline gemessen |
| Auswertung & Vorlage | 12-13 | Entscheidungsvorlage: skalieren, nachbessern oder stoppen; Governance-Artefakte (DSFA, Prüf-Workflow, Protokollierung) als Vorlage für Use Case Nummer zwei verpackt |
