# Healthcare *Fraud Detection* 18.764 Abrechnungen, drei Modellfamilien und die Frage, warum die besten öffentlichen Notebooks zu diesem Datensatz zu gut sind, um wahr zu sein. > Projektseite: https://clemenshoeller.at/projekte/fraud-detection > Gattung: analytics/python ## Eckdaten - **Kurs** · Data Management & Analytics - **Ort** · WU Wien, Master - **Datum** · 2026 - **Mein Teil** · Klassifikation - **Ergebnis** · ROC-AUC 0,88 ohne Leakage - Vollständiges Notebook ↗: https://clemenshoeller.at/projects/healthcare-fraud-detection.html ## /01 Die Frage Abrechnungsbetrug im Gesundheitswesen kostet Kostenträger weltweit dreistellige Milliardenbeträge pro Jahr. Das Problem ist nicht, dass die Fälle unsichtbar wären, sondern dass sie zwischen Millionen völlig gewöhnlicher Abrechnungen liegen und Prüfteams nur einen Bruchteil davon manuell ansehen können. Der Kurs gab einen Datensatz mit 18.764 einzelnen Versicherungsabrechnungen vor. Wir haben ihn entlang von drei Fragen bearbeitet, die je einer Methodenfamilie entsprachen: 1. Lassen sich Abrechnungen in sinnvolle Gruppen mit unterschiedlichem Risikoprofil segmentieren? (Clustering) 2. Lässt sich der genehmigte Erstattungsbetrag aus den Merkmalen der Abrechnung vorhersagen? (Regression) 3. Lässt sich eine Abrechnung **zum Einreichungszeitpunkt** als betrügerisch markieren, also bevor sie bearbeitet wurde? (Klassifikation) Die dritte Frage war mein Teil, und sie enthält die eigentliche Pointe des Projekts. Zu diesem Datensatz existieren öffentliche Notebooks mit nahezu perfekten Ergebnissen. Die Frage war, ob sich das reproduzieren lässt und ob es überhaupt etwas bedeutet. - Abrechnungen: 18.764 - Features danach: 60 - Betrugsanteil: 8,7% - Cluster: 4 ## /02 Vorgehen Gearbeitet wurde in JupyterLab mit Python, pandas und scikit-learn. Die Aufbereitung lief gemeinsam, danach übernahm je eine Person eine der drei Methodenfamilien. ### Aufbereitung - **Fehlende Werte** in drei Spalten (600, 663 und 828 Einträge). Eine Korrelationsanalyse bestätigte, dass sie völlig zufällig fehlen und nicht mit der Zielvariable zusammenhängen. Kategorien bekamen „Unknown“, die Vorbesuche eine 0. - **Ausreißer** bei den Betragsspalten auf das 99. Perzentil gekappt statt gelöscht, damit keine Beobachtung verloren geht. - **Feature Engineering:** zehn zusätzliche Variablen, darunter Finanzverhältnisse, Datumsmerkmale und binäre Patienten- und Anbieterindikatoren. - **Skalierung und Encoding** ergaben einen Endstand von 18.764 Beobachtungen und 60 Features. ### Was die anderen beiden Teile ergaben Das **Clustering** (K-Means über elf Merkmale, Betrugslabel bewusst ausgeschlossen und nur zur Validierung genutzt) fand vier Gruppen mit sehr unterschiedlichem Risiko: drei große Cluster zwischen 3,7 % und 10,9 % Betrugsanteil und ein kleines, klar abgesetztes Cluster mit 618 Abrechnungen und einem Betrugsanteil von 98,9 %. Auffällig dort: hohe Antragsverhältnisse, große Differenzen zwischen gefordertem und genehmigtem Betrag und sehr kurze Einreichungsfristen. Die **Regression** auf den genehmigten Betrag erreichte ein R² von rund 0,93, aber die ehrliche Lesart ist eine andere: Der geforderte Betrag allein trägt etwa 99 % des Koeffizientengewichts. Ohne ihn erreichten alle vier Modelle ein negatives R², waren also schlechter als der Mittelwert. Patientenalter, Diagnose, Fachrichtung und Versicherungstyp tragen praktisch nichts bei. ### Mein Teil: die Klassifikation Verglichen wurden Logistische Regression, ein Decision Tree und ein Random Forest. Weil nur rund 8,7 % der Abrechnungen betrügerisch sind, wäre Accuracy hier nutzlos: Ein Modell, das immer „kein Betrug“ sagt, läge bei 91 %. Bewertet wurde deshalb über Konfusionsmatrix, Precision, Recall, F1 und ROC-AUC für die Betrugsklasse, mit stratifiziertem Split und class_weight="balanced". Der entscheidende Schritt war, jedes Modell in **zwei Feature-Szenarien** laufen zu lassen: - **Voller Satz:** alle Features, so wie es die öffentlichen Notebooks machen. - **Nur Einreichungszeitpunkt:** ohne die sechs Features, die erst existieren, nachdem der Versicherer die Abrechnung bearbeitet hat, also genehmigter Betrag, Bearbeitungsstatus und die daraus abgeleiteten Verhältnisse. Das ist die realistische Situation. ## /03 Ergebnisse Die nahezu perfekten Werte lassen sich reproduzieren. Sie beruhen aber auf Informationen, die es zum Einreichungszeitpunkt noch gar nicht gibt. Das ist Data Leakage, und der Abstand dazwischen ist messbar. - Voller Feature-Satz *enthält Nachbearbeitungs-Signale*: 0,997 · F1 0,86 - Nur Einreichungszeitpunkt *realistische Situation*: 0,88 · F1 0,39 *ROC-AUC des Random Forest in beiden Feature-Szenarien. Der Abstand von rund 0,11 zeigt sich bei allen drei Modellfamilien gleich, ist also eine Eigenschaft der Features und nicht eines einzelnen Modells.* Der wichtigste Treiber der Leakage ist das Verhältnis von gefordertem zu genehmigtem Betrag. Es beschreibt im Grunde bereits das Urteil des Versicherers und beantwortet damit die Frage, die das Modell eigentlich stellen sollte. Eine fünffache stratifizierte Kreuzvalidierung bestätigte, dass die 0,88 im ehrlichen Szenario stabil sind und nicht an einem glücklichen Split hängen (Standardabweichung rund 0,007). ### Der Schwellwert ist der eigentliche Hebel Im ehrlichen Szenario stand der Random Forest zunächst nutzlos da: Beim Standard-Schwellwert von 0,5 erkannte er fast keinen Betrug. Das ist kein Modellfehler, sondern eine Folge der Klassen-Schieflage, denn bei seltenen Positivfällen überschreiten die gemittelten Wahrscheinlichkeiten eines Waldes selten 0,5. Die Rangfolge der Fälle war die ganze Zeit gut, nur der Schnitt lag falsch. *Recall (erkannter Betrug)* - Schwellwert 0,50 *Standardeinstellung*: praktisch unbrauchbar - Schwellwert 0,21 *auf bestes F1 getunt*: 0,51 · Precision 44 % F1 0,51 *Derselbe Random Forest, dieselben Features, dieselbe ROC-AUC. Nur der Entscheidungs-Schwellwert wurde verschoben. Am getunten Punkt markiert das Modell rund 460 von etwa 3.750 Test-Abrechnungen, darunter rund 200 der 325 echten Betrugsfälle.* ### Woran das ehrliche Modell Betrug erkennt Drei unabhängige Sichten (Impurity-Importance des Random Forest, die robustere Permutation-Importance und die Koeffizienten der Logistischen Regression als Odds Ratios) zeigen dasselbe Bild. Mit Abstand am wichtigsten ist die **Zeit zwischen Leistung und Einreichung**: Sie führt beide Importance-Ranglisten an, und ihre Permutation kostet ein Vielfaches an ROC-AUC gegenüber jedem anderen Merkmal. Zweiter Faktor ist der **Rechnungsbetrag**. Auch der Entscheidungsbaum trennt an der Wurzel genau danach. Betriebswirtschaftlich ergibt das Sinn: Betrügerische Abrechnungen werden hier auffällig schnell nach der Leistung eingereicht (Median rund 4 Tage gegenüber 15 bei legitimen) und sind tendenziell überhöht. Alle übrigen demografischen und Codierungs-Merkmale tragen kaum noch etwas bei, sobald diese beiden berücksichtigt sind. ## /04 Einordnung Ja, eine Abrechnung lässt sich zum Einreichungszeitpunkt markieren, aber deutlich unspektakulärer als die öffentlichen Notebooks nahelegen. Und das ehrliche Modell ist trotzdem brauchbar, nur für eine andere Aufgabe. Der Schwellwert ist dabei kein technisches Detail, sondern eine Geschäftsentscheidung: Senkt man ihn, erkennt man mehr Betrug und prüft mehr unauffällige Fälle mit; hebt man ihn, bleiben die Prüfungen fokussiert. Der sinnvolle Einsatz ist deshalb nicht die automatische Ablehnung, sondern die Priorisierung: Das Modell sortiert die Warteschlange für die menschliche Prüfung. > **Einschränkungen** — Der Datensatz ist synthetisch erzeugt. Der fast perfekte lineare Zusammenhang zwischen gefordertem und genehmigtem Betrag ist mit hoher Wahrscheinlichkeit ein Artefakt der Datenerzeugung und kein Abbild echter Erstattungsprozesse. Die Ergebnisse sind deshalb als methodische Demonstration zu lesen und nicht als direkt übertragbarer Praxisbefund. ### Was ich daraus mitgenommen habe Die technische Arbeit war der kleinere Teil. Der größere war, einer ROC-AUC von 0,997 nicht zu glauben. Ein Modell, das die eigene Zielfrage schon im Input stehen hat, sieht großartig aus und ist wertlos, und genau das passiert in der Praxis ständig, weil Feature-Tabellen selten dokumentieren, wann ein Wert eigentlich entsteht. Seitdem ist meine erste Frage bei jedem Modell nicht mehr, wie gut es ist, sondern zu welchem Zeitpunkt jedes Feature bekannt sein wird. **Skills daraus:** Python · scikit-learn · Klassifikationsmodelle · Data-Leakage-Erkennung · Threshold-Tuning · Kreuzvalidierung · Datenanalyse & Statistik ## /05 Verwandte Projekte Die Projekte hängen stärker zusammen, als die Kacheln auf der Startseite vermuten lassen. Hier stehen alle anderen, sortiert nach Nähe zu diesem Projekt: - [Google vs. ChatGPT](https://clemenshoeller.at/projekte/google-vs-chatgpt) - [Prompt Injection](https://clemenshoeller.at/projekte/prompt-injection) - [Consulting-Cases](https://clemenshoeller.at/projekte/consulting-cases) - [AURORA](https://clemenshoeller.at/projekte/aurora) - [Zotter-Marketingplan](https://clemenshoeller.at/projekte/zotter-marketingplan) - [KI-Automatisierungen](https://clemenshoeller.at/projekte/ki-automatisierungen) - [AI Talent Gap](https://clemenshoeller.at/projekte/ai-talent-gap) - [LLMs & Kreativität](https://clemenshoeller.at/projekte/llms-kreativitaet) - [Diese Website](https://clemenshoeller.at/projekte/diese-website) - [VWA: Entstehung des Internets](https://clemenshoeller.at/projekte/vwa) --- *Englische Fassung: https://clemenshoeller.at/en/projects/fraud-detection.md* *Master-Projekt Data Management & Analytics (WU Wien): Betrugserkennung auf 18.764 Abrechnungen mit Python und scikit-learn, inklusive Nachweis von Data Leakage und Threshold-Tuning als Business-Hebel.*