Katalog / Erkennung von Anomalien, Betrug und Integritätsverstößen / ANOM-007

Erkennung von Abrechnungs- und Erstattungsbetrug im Gesundheitswesen

Leistungserbringer-Abrechnungen und -Rechnungen bei gesetzlichen und privaten Krankenversicherern, öffentlichen Kostenträgern und Krankenhäusern werden bewertet, um Upcoding, Phantomabrechnung, doppelte Abrechnungen und organisierte Abrechnungsringe für menschliche Ermittler sichtbar zu machen.

Kostenträger verlieren einen spürbaren Teil ihrer Ausgaben durch Betrug, Verschwendung und Missbrauch: Abrechnung nicht erbrachter Leistungen, Upcoding, Unbundling, doppelte oder unplausible Abrechnungen und abgestimmte Netzwerke von Leistungserbringern. KI bewertet Abrechnungen und Leistungserbringer im Vergleich zu Vergleichsgruppen und bekannten Mustern, sodass ein kleines Ermittlungsteam die wenigen relevanten Fälle prüft. Das Modell entscheidet nie über Schuld; es ordnet Fälle nach Priorität und erklärt, warum, und ein menschlicher Ermittler oder die Compliance-Einheit des Kostenträgers handelt.

Problem & Nutzen

  • Wer: gesetzliche Krankenkassen (GKV, mit Pflichtstellen zur Bekämpfung von Fehlverhalten nach § 197a SGB V), private Krankenversicherer, öffentliche Kostenträger (Programme vom Typ Medicare/Medicaid), Krankenhauskonzerne, die ihre eigene Abrechnungs-Compliance prüfen, und Dienstleister für Abrechnungsprüfung [1].
  • Heute: regelbasierte Plausibilitätsprüfungen, zufällige oder beschwerdegetriebene Prüfungen und manuelle Sichtung durch Sachbearbeiter und Medizinische Dienste. Regeln erfassen bekannte Schemata; sich anpassende Schemata und Ringe rutschen durch.
  • Ausmaß (US-Referenz): Die National Health Care Anti-Fraud Association (NHCAA) beziffert die Verluste auf „zig Milliarden Dollar pro Jahr“, mit einer vorsichtigen Schätzung von etwa 3 % der Gesundheitsausgaben, manche Behörden nennen bis zu 10 % [2]. Die Health Care Fraud Unit des US-Justizministeriums gibt an, bei der Nutzung fortgeschrittener Datenanalytik zur Aufdeckung neu entstehender Schemata führend zu sein, was zu einigen ihrer größten Fälle führte [3]. Eine vergleichbare einzelne EU-Zahl gibt es nicht; nationale Schätzungen unterscheiden sich in der Methode, zitieren Sie sie daher nur mit Quelle.
  • KI-Nutzen: bessere Priorisierung (mehr bestätigte Befunde je Ermittlerstunde), Erkennung neuer Muster und Netzwerke, schnellere Fallvorbereitung und Prüfung vor Zahlung, die die Zahlung stoppt, statt sie nachträglich zurückzufordern.

Varianten

  • Gesetzlicher/privater Krankenversicherer (DE/EU): Bewertung auf Abrechnungsebene für ambulante, stationäre, Apotheken-, Heilmittel-, Hilfsmittel-, häusliche Pflege- und Transportabrechnungen.
  • Öffentlicher Kostenträger / Programme im Medicare-Stil: Prüfungen vor Zahlung plus Netzwerkanalytik zu Leistungserbringern.
  • Compliance von Krankenhaus / Leistungserbringer: interne Prüfung der eigenen Kodierung, um Prüfungsbeanstandungen zu vermeiden (teilt Technik mit HLTH-005).
  • Apotheken- und Verordnungsbetrug: Anomalien in Verordnungsmustern, wiederholte Abgabe, Abrechnung von Rezepturen.
  • Häusliche Pflege und Pflegeabrechnung: Plausibilität von Zeit und Fahrtweg abgerechneter Besuche.
  • Abrechnungsprüfdienste / Unterstützung des Medizinischen Dienstes: Dokumentenprüfung bei Krankenhausrechnungen.
  • Private Nutzung: nicht anwendbar; Einzelpersonen können nur ihre eigenen Rechnungen prüfen (siehe DOC-001 für die allgemeine Rechnungs-Pipeline).

So funktioniert es

  1. claims & invoices (EDI/DTA, APIs, PDF/scan)
  2. normalisation, pseudonymisation, code-master joins (ICD-10-GM, OPS, EBM, DRG)
  3. feature building (per claim, provider, patient, provider-pair, time window)
  4. detectors in parallel: rules/edits (unbundling, impossible combinations, frequency limits) supervised model (gradient boosting on confirmed past cases) unsupervised outliers vs. peer group (specialty, region, size) graph analysis (shared patients, referrals, addresses, bank accounts)
  5. score fusion + reason codes
  6. LLM-assisted case dossier (summary of evidence, document extraction, code lookups)
  7. investigator review (human-in-the-loop)
  8. payment hold / audit / recovery / prosecutor referral
  9. outcome feedback = new labels
  • Der Kern ist klassisches ML: Gradient-Boosted Trees auf tabellarischen Abrechnungsmerkmalen bleiben das Arbeitspferd; unüberwachte Detektoren (Isolation Forest, Autoencoder, Z-Scores gegen die Vergleichsgruppe) decken ungelabelte neue Schemata ab; Graph-Merkmale machen Ringe sichtbar.
  • Die Rolle des LLM ist unterstützend: Felder aus Rechnungen und ärztlichen Notizen extrahieren, die Abrechnungshistorie eines Leistungserbringers zusammenfassen, Begründungscodes in verständlicher Sprache erklären und Fragen zu Gebührenordnungsregeln per RAG beantworten. LLMs sollten nicht die Betrugsentscheidung treffen.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Jede nachteilige Maßnahme (Zahlungsverweigerung, Rückforderung, Abgabe nach § 197a Abs. 4 SGB V) ist eine dokumentierte menschliche Entscheidung [1].

Datenaufbereitung

Abrechnungs- und Rechnungsdaten (ICD-10-GM-, OPS-, EBM/GOP- oder DRG-Codes, Tarifpositionen, Beträge, Pseudonyme von Leistungserbringern und Patienten) liegen im Kernsystem der Leistungsabrechnung oder im Data Warehouse; Stammdaten der Leistungserbringer, Zulassungen und Ausschlusslisten stehen in getrennten Registern; Rechnungen und ärztliche Auszüge kommen als PDF, Scan oder Papier an. Frühere Ermittlungsergebnisse, die einzigen echten Labels, liegen oft in Fallakten oder Tabellen.

Typische Lücken: Codesysteme, die sich jährlich ändern, Dubletten und Korrekturen über Versionen hinweg, nicht verknüpfte Identitäten von Leistungserbringern (mehrere IDs je Praxis), fehlende Ermittlungsergebnisse, gescannte Rechnungen und strenge Zugriffsrechte für besondere Kategorien von Daten.

Schritte der Aufbereitung: - Ein Schlüsselkonzept für Patienten und Leistungserbringer mit Pseudonymen aufbauen, die über Systeme hinweg stabil bleiben (PREP-022). - Abrechnungsversionen und Stornos zusammenführen und Codetabellen je Jahr harmonisieren. - Labels aus abgeschlossenen Ermittlungsfällen und Hinweisen gewinnen (PREP-020) und mit Ermittlern einen Evaluationsdatensatz aufbauen (PREP-018). - Rechnungen per OCR erfassen und Felder extrahieren (PREP-006, DOC-014). - Die Rechtsgrundlage für die Sekundärnutzung dokumentieren (PREP-025). - Zugriff rollenbasiert beschränken und protokollieren.

Werkzeuge: SQL, Pipelines im dbt-Stil, Paperless-ngx oder OCR-Engines für Scans, pandas. Die Aufbereitung macht typischerweise 50–60 Prozent des Aufwands aus; GUIDE-003 bietet einen Reifegrad-Check, PREP-005 die Systemextraktion.

Umsetzungswege

Welcher Weg für wen

  • Großunternehmen: Weg C, weil Abrechnungsdaten Gesundheitsdaten (besondere Kategorie) enthalten, die Volumina groß sind und Kostenträger Open-Source-Bewertung auf ihrer eigenen HW2-Infrastruktur unter eigener Kontrolle betreiben können.
  • Öffentlicher Sektor: Weg C, weil gesetzliche Kostenträger und öffentliche Stellen souveränes Hosting, Prüfbarkeit und Unabhängigkeit von einem einzelnen Anbieter brauchen.
  • Entwickler: Weg C, weil tabellarische und Graph-Modelle Open Source sind und die sensiblen Daten die kontrollierte Umgebung nicht verlassen dürfen.

Weg A — Kaufen (Standardsoftware)

  • Spezialisierte Plattformen für Payment Integrity / Betrugserkennung: Shift Technology (FR, Abrechnungsbetrug und Payment Integrity im Gesundheitswesen), Cotiviti, Optum Payment Integrity, Gainwell und ähnliche Anbieter; SAS Fraud Management und Verisk-Analytik sind in der Versicherung verbreitet. In DE bieten IT-Dienstleister der Krankenkassen (z. B. GKV-Informatikdienstleister) und Prüfdienstleister Plausibilitätsprüfungen an. Prüfen Sie Produktumfang und EU-Hosting bei jedem Anbieter aktuell.
  • A wählen, wenn: Sie kein Data-Science-Team haben, eine bewährte Regelbibliothek brauchen und vom Anbieter gepflegte Modelle wollen. Bestehen Sie auf erklärbaren Begründungscodes, EU-Datenhaltung und Prüfprotokollen.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Tabellarisches ML + Feature Store in einer EU-Cloud-Region (verwaltete Gradient-Boosting- und AutoML-Dienste von Azure, AWS Frankfurt, Google Cloud EU; STACKIT und IONOS als EU-souveräne Optionen).
  • LLM-Schicht: ein Frontier- oder EU-Anbieter-Modell (z. B. Mistral, Claude oder Gemini über EU-Endpunkte) für Dossiererstellung und Rechnungsextraktion; nur pseudonymisierte Daten, kein Training auf Prompts, AVV vorhanden.
  • Orchestrierung: n8n oder Camunda für den Fall-Workflow; Anbindung an Fallwerkzeuge (z. B. bestehendes Fallmanagement).
  • B wählen, wenn: Sie ein Datenteam haben und eigene Logik wollen, aber einen Auftragsverarbeiter nach DSGVO Art. 28 akzeptieren. Gesundheitsdaten sind Daten besonderer Kategorien (Art. 9): erfordert eine klare Rechtsgrundlage.

Weg C — Selbst betreiben (Open Source)

  • Stack: Python mit scikit-learn, XGBoost/LightGBM, PyOD für Ausreißererkennung (BSD-2-Lizenz, 60+ Detektoren, mit dem ADBench-Benchmark) [4], NetworkX oder eine Graphdatenbank für Netzwerkanalyse und ein LLM mit offenen Gewichten (z. B. Qwen-, Llama- oder Mistral-Familien) über vLLM für Dossierentwürfe und Dokumentenextraktion.
  • Werkzeuge: Docling oder PaddleOCR für das Parsen von Rechnungen (siehe DOC-001), MLflow für die Modellverwaltung, Postgres/OpenSearch für Merkmale und Fälle.
  • Hardware: HW2 genügt für tabellarische Modellierung plus ein quantisiertes LLM bis 30B; das Training auf Abrechnungsdaten läuft überwiegend auf der CPU. Das ist die naheliegende Wahl für Kostenträger, die Gesundheitsdaten nicht in eine Cloud verlagern dürfen.

Weg D — Eigenes Training

Lohnt sich für große Kostenträger mit jahrelang untersuchten Fällen: überwachte Modelle auf bestätigten Ergebnissen trainieren (positive Labels sind knapp und zugunsten früher geprüfter Leistungserbringer verzerrt), Graph Neural Networks zur Ringerkennung ergänzen und kleine Encoder für die textbasierte Code-Plausibilität feintunen. Braucht Labels aus Ermittlungsergebnissen, saubere Stammdaten und eine leckagesichere Evaluation (zeitbasierte Splits, Splits auf Ebene der Leistungserbringer).

Stand der Technik (2026)

  • Hybride Stacks gewinnen: Regeln + überwachte Bäume + unüberwachte Ausreißer + Graph-Merkmale, zu einem Score mit Begründungscodes verschmolzen. Benchmarks wie ADBench zeigen, dass kein einzelner unüberwachter Detektor über alle Datensätze gewinnt; Ensembles und Fachmerkmale zählen daher mehr als Modellneuheit [4].
  • Bewertung vor Zahlung ersetzt „Pay and Chase“, wo Recht und Verträge es erlauben.
  • LLMs/Agenten entwerfen inzwischen Falldossiers, lesen Auszüge aus der medizinischen Dokumentation und prüfen Codes gegen Gebührenordnungen; am nützlichsten sind sie als Assistenten der Ermittler, nicht als Bewerter.
  • Netzwerkanalytik findet Absprachen zwischen Leistungserbringern, Patienten und Intermediären, die Modelle auf Abrechnungsebene übersehen.
  • Grenzen und Fehlerbilder: Label-Verzerrung (nur geprüfte Leistungserbringer haben Labels), Konzeptdrift, wenn sich Schemata anpassen, Fehlalarme, die ehrliche Leistungserbringer belasten (z. B. ungewöhnliche, aber legitime Spezialpraxen), Datenqualitätsprobleme bei Code-Zuordnungen und gezielte Anpassung der Täter. Behandeln Sie eine Anomalie nie als Beweis für Fehlverhalten.

Gemeinsame Bausteine & Kombinationen

  • Gleicher Fähigkeits-Stack (tabular-ml + anomaly-detection + graph-ml): ANOM-003 (Versicherungsbetrug bei Leistungsfällen), ANOM-019 (Leistungsbetrug), ANOM-002 (Geldwäsche-Transaktionsüberwachung), ANOM-009 (Spesen- & Beschaffungsbetrug), ANOM-006 (Hauptbuch-Anomalien). Ein Feature Store, eine Graphdatenbank und ein Fallmanagementsystem können alle bedienen.
  • Dokumentenschicht (ocr-docparse + llm-general): DOC-001 (Rechnungsverarbeitung), ANOM-017 (Dokumentenfälschung) für gefälschte Rechnungen oder Verordnungen; HLTH-005 (medizinische Kodierung) liefert Wissen zur Code-Plausibilität und markiert Kodierfehler, die kein Betrug sind.
  • Hardware: Ein einzelner HW2-Server betreibt die OCR-/VLM- und LLM-Dienste für alles Genannte; die Bewertungsmodelle brauchen keine GPU.
  • Gemeinsame Daten: Stammdaten der Leistungserbringer, Ausschlusslisten, Gebührenordnungen und Codekataloge werden über Anwendungsfälle hinweg wiederverwendet.

Aufwand, Kosten & Kennzahlen

  • Weg A: 3–9 Monate inklusive Datenintegration; die Lizenz richtet sich typischerweise nach Abrechnungsvolumen oder Zahl der Versicherten.
  • Weg B: 6–12 Monate für ein erstes Produktivmodell plus Workflow.
  • Weg C: 6–12 Monate, ein Data-Science-/Engineering-Team plus ein kleiner Server.
  • Weg D: 12+ Monate inkl. Label-Aufbau; laufende Überwachung und Nachtraining.
  • Kostentreiber: Datenintegration und -bereinigung, Ermittlerkapazität, Label-Qualität.
  • Kennzahlen: Trefferquote (bestätigte Befunde / geprüfte Fälle), zurückgeholte oder vermiedene Euro je Ermittler-VZÄ, im Widerspruch bestätigte Zahlungsstopps, Fehlalarmquote je Gruppe von Leistungserbringern, Zeit vom Alarm bis zur Entscheidung, Drift-Indikatoren.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung und die Leitung von Revision/Ermittlung zu Beginn ein, dann die/den Datenschutzbeauftragte(n), Legal/Compliance und Informationssicherheit, bevor Daten angefasst werden, weil Abrechnungsdaten Gesundheitsdaten sind (GUIDE-005, GUIDE-013). IT und die Datenverantwortlichen des Abrechnungssystems liefern Extrakte; Ermittler sind die täglichen Nutzer und sollten Begründungscodes und Prüf-Workflow mitgestalten. Leistungserbringer und Versicherte sind von der Ausgabe betroffen, daher müssen Rechtsgrundlage und Verfahrensregeln für ihre Ansprache klar sein.

Betriebsrat: abhängig vom Einzelfall. Die Bewertung betrifft Leistungserbringer und Abrechnungen, nicht das Verhalten von Beschäftigten, aber Aktivitätsprotokolle der Sachbearbeiter und Produktivitätsstatistiken im Workflow-Werkzeug können zur Überwachung nach §87 Abs. 1 Nr. 6 BetrVG geeignet sein, und §90 Abs. 1 Nr. 3 verlangt Information über KI-geplante Arbeitsverfahren. Öffentliche Kostenträger beziehen den Personalrat ein (GUIDE-004). Eine DSFA nach Art. 35 DSGVO ist sehr wahrscheinlich (besondere Kategorien, systematische Bewertung), dazu ein AVV für jeden Auftragsverarbeiter.

Fördern Sie die KI-Kompetenz der Ermittler (Art. 4 KI-Verordnung, GUIDE-006). Beginnen Sie mit einem kleinen Pilotteam, lassen Sie das Modell im Schattenbetrieb neben den bestehenden Prüfungen laufen und stellen Sie klar, dass ein Score ein Hinweis ist, nie eine Entscheidung: Menschen prüfen jeden Fall, bevor eine Zahlung zurückgehalten oder ein Leistungserbringer angesprochen wird. Typische Sorgen sind falsche Beschuldigungen und Intransparenz; begegnen Sie ihnen mit erklärbaren Begründungscodes (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): Die Einstufung hängt von der Nutzung ab. Die reine Aufdeckung von Betrug gegen einen Kostenträger, bei der Menschen entscheiden, ist für sich genommen in der Regel kein Anwendungsfall nach Anhang III; Systeme jedoch, die den Anspruch auf öffentliche Gesundheitsleistungen oder -dienste bewerten oder diese kürzen, widerrufen oder zurückfordern (Anhang III Nr. 5(a)) oder die Risiko und Preisgestaltung in der Lebens- und Krankenversicherung beurteilen (Nr. 5(c)), können Hochrisiko sein. Die Ausnahme für die Aufdeckung von Finanzbetrug in Anhang III Nr. 5(b) betrifft die Kreditwürdigkeitsprüfung und sollte nicht als Abdeckung anderer Nutzungen angenommen werden. Dokumentieren Sie den Verwendungszweck und führen Sie eine Einstufungsprüfung durch; bei Hochrisiko gelten Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht und Transparenz (Art. 9–15) [5]. Verbotene Praktiken (Art. 5), etwa Social Scoring von Personen, dürfen nicht angenähert werden: bewerten Sie Abrechnungen und Leistungserbringer, nicht die allgemeine Vertrauenswürdigkeit von Menschen.
  • DSGVO: Gesundheitsdaten sind Daten besonderer Kategorien (Art. 9); nötig sind eine Rechtsgrundlage (z. B. gesetzliche Pflichten der GKV-Stellen nach § 197a SGB V und §§ 67c ff. SGB X) [1], Datenminimierung, Pseudonymisierung, DSFA (Art. 35) und Schutzmaßnahmen nach Art. 22: keine ausschließlich automatisierten nachteiligen Entscheidungen über Einzelne.
  • Fachrecht: SGB V (§ 197a, §§ 106 ff. Abrechnungsprüfungen), StGB § 263 (Betrug) und §§ 299a/b (Korruption im Gesundheitswesen), Regeln des Medizinischen Dienstes; für US-Programme der False Claims Act und HIPAA.
  • Fairness und Rechte der Leistungserbringer: Ermittlungen müssen rechtsstaatlichen Verfahren folgen; erklärbare Begründungscodes und das Recht zur Stellungnahme schützen ehrliche Leistungserbringer.
  • Sicherheit: Behandeln Sie Fallakten und Modellmerkmale als hochsensibel; rollenbasierter Zugriff, Prüfprotokolle, keine rohen Gesundheitsdaten an externe LLMs.

Erste Schritte

  1. Legen Sie den Umfang fest (Abrechnungsbereich wie Apotheke oder häusliche Pflege) und sichern Sie Rechtsgrundlage sowie die Beteiligung von Datenschutzbeauftragter/m und Betriebsrat.
  2. Erfassen Sie die Daten: Abrechnungen, Stammdaten, frühere Prüfungsergebnisse; messen Sie Menge und Qualität der Labels.
  3. Bauen Sie eine Basislinie: Ausreißerbericht gegen die Vergleichsgruppe je Fachgebiet und Region plus einfache Regeln; prüfen Sie die Top 50 mit den Ermittlern.
  4. Ergänzen Sie ein überwachtes Modell auf bestätigten Fällen, mit zeitbasierter Evaluation und Begründungscodes; pilotieren Sie im Schattenbetrieb.
  5. Führen Sie den Falldossier-Assistenten ein (RAG über Gebührenordnungen, pseudonymisierte Daten) und richten Sie Ergebnisrückmeldung und Driftüberwachung ein.

Quellen

  1. § 197a SGB V (Stellen zur Bekämpfung von Fehlverhalten im Gesundheitswesen) — https://www.gesetze-im-internet.de/sgb_5/__197a.html
  2. NHCAA — The Challenge of Health Care Fraud — https://www.nhcaa.org/tools-insights/about-health-care-fraud/the-challenge-of-health-care-fraud/
  3. US DOJ Criminal Division — Health Care Fraud Unit (data analytics, National Health Care Fraud Takedown) — https://www.justice.gov/criminal/criminal-fraud/health-care-fraud-unit
  4. PyOD — Python library for anomaly detection (incl. ADBench) — https://github.com/yzhao062/pyod
  5. Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj