Model Risk in klinischer KI diagnostizieren

# Model Risk in klinischer KI diagnostizieren

2019 zeigte eine in *Science* veröffentlichte Studie, dass ein weit verbreiteter US-Algorithmus für Care Management, der jährlich auf rund 200 Millionen Menschen angewendet wird, schwarze Patienten systematisch zu selten in Hochrisiko-Versorgungsprogramme überwies. Das Modell erhielt keine Angaben zur Ethnie. Es nutzte Gesundheitskosten als Proxy für Krankheit. Weil historisch bei schwarzen Patienten mit gleichem Krankheitsgrad weniger Geld ausgegeben wurde, schloss der Algorithmus, sie seien gesünder. Waren sie nicht.

Das ist Model Risk. Kein Bug im Code, sondern eine Diskrepanz zwischen dem, was das Modell gelernt hat, und dem, was das Krankenhaus von ihm brauchte. Diese Lektion nimmt die vier Fehlermodi auseinander, die Krankenhäusern am meisten schaden, anhand real eingesetzter Fälle, und die Prüfungen, die sie erkennen, bevor ein Patient Schaden nimmt.

Was „Model Risk“ im Krankenhaus bedeutet

Model Risk ist das Risiko eines Schadens (klinisch, finanziell oder für die Reputation) durch ein Modell, das falsch ist, falsch genutzt oder falsch verstanden wird. Im Bankwesen ist dieses Konzept formalisiert. Im Gesundheitswesen ist es jünger, konvergiert aber schnell, getrieben von der US-amerikanischen FDA (Food and Drug Administration) und dem EU AI Act, der die meiste klinische Entscheidungsunterstützung als „Hochrisiko-KI“ mit verpflichtenden Monitoring-Auflagen einstuft.

Vier Fehlermodi dominieren. Lernen Sie, sie zu benennen.

Fehlermodus 1: Dataset Shift zwischen Patientenpopulationen

Dataset Shift bedeutet, dass die Daten, die das Modell im Betrieb sieht, von den Trainingsdaten abweichen. Ein Modell, das auf den Patienten eines Krankenhauses trainiert wurde, verliert in einem anderen an Leistung.

Der klassische Fall: Epics Sepsis-Modell, eingesetzt in hunderten US-Krankenhäusern. Eine externe Validierung an der University of Michigan (veröffentlicht in *JAMA Internal Medicine*, 2021) ergab, dass es rund zwei Drittel der Sepsisfälle übersah und in einer Population, die von Epics Entwicklungsdaten abwich, häufig Fehlalarme produzierte. Das Modell war nicht kaputt. Es war verschoben worden.

Drei Untertypen im Blick behalten:

• Covariate Shift: Der Patientenmix ändert sich (älter, kränker, andere Ethnie).
• Label Shift: Die Krankheitsprävalenz ändert sich (eine neue Variante, eine saisonale Welle).
• Concept Shift: Die Beziehung selbst ändert sich (ein neues Behandlungsprotokoll verändert, wie „hohes Risiko“ aussieht).

Die Prüfung: Vertrauen Sie niemals der internen AUC eines Anbieters. Fordern Sie lokale externe Validierung auf Ihren eigenen Patientendaten vor dem Go-live, und erneut nach jeder wesentlichen Veränderung der Population.

> AUC (Area Under the Curve): ein Wert von 0,5 (Münzwurf) bis 1,0 (perfekt), der misst, wie gut ein Modell kranke von gesunden Patienten trennt.

Fehlermodus 2: Automation Bias auf der Intensivstation

Automation Bias ist die menschliche Neigung, dem Output einer Maschine zu sehr zu vertrauen und kritisches Denken einzustellen. Auf der Intensivstation, wo eine Pflegekraft alle paar Minuten Alarme abarbeitet, ist das besonders akut.

Zwei Schadensrichtungen:

• Commission Errors: Die Klinikerin folgt einer falschen KI-Empfehlung, die sie ohne Unterstützung erkannt hätte.
• Alert Fatigue: Das Modell löst so oft aus, dass das Personal es ignoriert, einschließlich der True Positives. Studien schätzen, dass die Mehrheit klinischer Alerts übergangen wird. Ein Modell, das zu oft „Wolf“ ruft, trainiert Menschen darauf, den Wolfsfänger abzuschalten.

Die Governance-Antwort ist nicht bessere KI. Sie ist Workflow-Design: Alert-Schwellen an die reale Personalkapazität kalibrieren, Override-Raten loggen und eine steigende Override-Rate als Warnsignal behandeln, dass das Modell klinisches Vertrauen verloren hat.

Fehlermodus 3: Stiller Leistungsverfall

Dieser tötet leise. Ein Modell liefert beim Launch gute Leistung und driftet dann über Monate nach unten, während sich Behandlungsmuster, Geräte und Codierung ändern. Niemand merkt es, weil es keinen Alarm für „das Modell wird langsam schlechter“ gibt.

Ein konkreter Treiber: Ein Krankenhaus wechselt den Anbieter seines Laboranalysators. Kreatininwerte verschieben sich leicht in der Skala. Ein Nierenrisiko-Modell, das auf der alten Skala kalibriert wurde, bewertet nun jeden Patienten falsch, und zwar still.

Eine einfache Monitoring-Rechnung

Sie brauchen keine tiefe Mathematik, um Verfall zu erkennen. Verfolgen Sie die Kalibrierung des Modells: Stimmen die vorhergesagten Risiken mit den beobachteten Outcomes überein?

Angenommen, ein Readmission-Modell markiert pro Quartal 1.000 Patienten als „hohes Risiko (vorhergesagt 30 %)“. Beim Launch wurden 300 tatsächlich wieder aufgenommen (30 %, gut kalibriert). Zwei Quartale später:

Predicted high-risk readmission rate: 30%
Flagged patients:                     1,000
Model expects readmissions:           300
Actual observed readmissions:         180

Observed / Expected ratio = 180 / 300 = 0.60

Ein O/E-Verhältnis von 0,60 bedeutet, dass das Modell das Risiko nun um 40 % überschätzt. Kliniker werden zu Patienten geschickt, die nicht wieder aufgenommen werden, und verschwenden knappe Case-Management-Zeit. Diese Drift ist auf einem Dashboard, das nur „Modell läuft“ zeigt, unsichtbar. Auf einem O/E-Chart ist sie offensichtlich.

Setzen Sie einen Trigger: Driftet O/E etwa außerhalb von 0,8 bis 1,2 für zwei aufeinanderfolgende Perioden, anhalten und neu validieren. (Die Bandbreiten sind illustrativ; legen Sie Ihre mit Ihrem klinischen Governance-Komitee fest.)

Fehlermodus 4: Ungleiche Outcomes

Zurück zum Eingangsfall. Der Schaden war keine Absicht. Es war eine Proxy-Variable (Kosten), die für das eigentliche Ziel (Gesundheitsbedarf) einstand, kombiniert mit historischer Ungleichheit, die in diesem Proxy eingebacken war.

Wo das in Krankenhäusern auftaucht:

• Pulsoximetrie und Hautton: Geräte und nachgelagerte Modelle kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen die Sauerstoffsättigung bei Patienten mit dunklerer Haut überschätzen und so die Behandlung verzögern. Das ist ein dokumentierter Messbias, der in KI einfließt, die auf diesen Daten trainiert wurde.
• Unterrepräsentierte Gruppen: Ein Dermatologie-Modell, das überwiegend auf heller Haut trainiert wurde, übersieht Melanome auf dunkler Haut.

Die Prüfung ist die Subgruppen-Performanceanalyse. Berichten Sie nicht eine AUC. Berichten Sie sie pro Gruppe: nach Ethnie, Geschlecht, Altersband und Kostenträgertyp. Ein Modell mit 0,85 AUC insgesamt und 0,65 für eine Subgruppe ist kein 0,85-Modell. Es ist ein diskriminierendes.

Das US Office for Civil Rights und Section 1557 des Affordable Care Act erfassen Diskriminierung durch klinische Algorithmen inzwischen ausdrücklich. Ungleiche KI ist ein Compliance-Risiko, nicht nur ein ethisches.

Die Guardrails: was vor dem Deployment laufen muss

Governance verwandelt diese vier Risiken in eine Checkliste. Verankern Sie sie in realen Frameworks.

1. Das Modell unter dem anwendbaren Regime klassifizieren

• In den USA fragen Sie: Ist das ein reguliertes Medizinprodukt? Die FDA beaufsichtigt KI/ML-basierte Software as a Medical Device (SaMD). Viele klinische Entscheidungstools fallen darunter. Die Good Machine Learning Practice guiding principles der FDA sind ein kostenloser, verständlich formulierter Ausgangspunkt.
• In der EU stuft der AI Act (in Kraft seit 2024, Pflichten gestaffelt bis 2026 und 2027) medizinische KI als hochriskant ein und verlangt Risikomanagement, Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen →, menschliche Aufsicht und Post-Market-Monitoring. Medizinprodukte fallen zusätzlich unter die MDR (Medical Device Regulation).

2. Lokale Validierung fordern, nicht Anbieterversprechen

Reproduzieren Sie die Performance auf Ihrer eigenen Population vor dem Go-live. Bestehen Sie auf einer Model Card: ein kurzes Dokument, das Trainingspopulation, intendierte Nutzung, bekannte Grenzen und Subgruppen-Performance angibt.

3. Menschliche Aufsicht in den Workflow einbauen

Entscheiden Sie explizit, ob ein Mensch jeden Output bestätigen muss (Human-in-the-Loop) oder nachträglich übersteuern kann (Human-on-the-Loop). Loggen Sie Override-Raten als laufendes Sicherheitssignal.

4. Für stillen Verfall instrumentieren

Liefern Sie Monitoring mit dem Modell aus, nicht später. Verfolgen Sie Kalibrierung (O/E-Verhältnisse), Alert-Volumen und Input-Drift. Weisen Sie einen Owner zu. Ein Modell ohne Owner ist ein Incident, der noch auf seinen Namen wartet.

5. Subgruppen-Equity-Checks laufend durchführen

Nicht einmal bei der Beschaffung. Populationen verschieben sich. Führen Sie die Subgruppenanalyse nach einem Zeitplan erneut durch, der an Ihr Governance-Komitee gekoppelt ist.

6. Einen Decommission-Plan bereithalten

Jedes Modell braucht einen Aus-Schalter und einen dokumentierten Trigger für dessen Nutzung. Der Epic-Sepsis-Fall zeigt, was passiert, wenn ein breit ausgerolltes Modell nicht schnell neu eingegrenzt werden kann.

Key Takeaways

• Ein Modell, das beim Anbieter funktioniert, kann in Ihrem Krankenhaus scheitern. Dataset Shift ist der Normalfall, nicht die Ausnahme. Fordern Sie lokale externe Validierung vor jedem Go-live.
• Stiller Verfall ist der tödlichste Fehlermodus, weil nichts Alarm schlägt. Verfolgen Sie pro Periode ein einfaches O/E-Verhältnis (observed over expected); Drift außerhalb Ihres vereinbarten Bandes löst Revalidierung aus.
• Automation Bias ist ein Workflow-Problem, kein Modellproblem. Überwachen Sie Override- und Alert-Fatigue-Raten als Frühindikatoren für verlorenes klinisches Vertrauen.
• Eine einzige Gesamtgenauigkeitszahl verdeckt Diskriminierung. Berichten Sie Performance immer nach Subgruppe; unter US Section 1557 und dem EU AI Act sind ungleiche Algorithmen inzwischen ein rechtliches Risiko.
• Governance ist ein Lifecycle, kein Launch-Gate. Klassifizieren unter FDA oder EU AI Act, Owner zuweisen, Monitoring instrumentieren und einen funktionierenden Decommission-Trigger vorhalten.