Healthcare billing & reimbursement fraud detection

Payers lose a meaningful share of spending to fraud, waste and abuse: billing for services never rendered, upcoding, unbundling, duplicate or implausible claims, and collusive networks of providers. AI scores claims and providers against peer behaviour and known patterns, so a small investigation team looks at the few cases that matter. The model never decides guilt; it ranks cases and explains why, and a human investigator or the payer's compliance unit acts.

Problem & value

• Who: statutory health insurers (GKV, with mandatory anti-misconduct units under § 197a SGB V), private health insurers, public payers (Medicare/Medicaid-type programmes), hospital groups checking their own billing compliance, and billing-audit service firms [1].
• Today: rule-based edit checks, random or complaint-driven audits, and manual review by claims specialists and medical services. Rules catch known schemes; adaptive schemes and rings slip through.
• Scale (US reference): the National Health Care Anti-Fraud Association (NHCAA) calls losses "in the tens of billions of dollars each year", with a conservative estimate of about 3 % of health spending and some agencies putting it as high as 10 % [2]. The US DOJ health care fraud unit states it is a leader in using advanced data analytics to find newly emerging schemes, which led to some of its largest cases [3]. No comparable single EU figure exists; national estimates differ in method, so quote them only with their source.
• AI value: better prioritisation (more confirmed findings per investigator hour), detection of novel patterns and networks, faster case preparation, and pre-payment screening that stops payment instead of recovering it afterwards.

Variants

• Statutory/private health insurer (DE/EU): claim-level scoring for outpatient, hospital, pharmacy, remedies (Heilmittel), aids, home-care and transport billing.
• Public payer / Medicare-style programmes: pre-payment edits plus provider-network analytics.
• Hospital / provider compliance: internal check of own coding to avoid audit findings (shares tech with HLTH-005).
• Pharmacy and prescription fraud: prescription-pattern anomalies, repeated dispensing, compounding billing.
• Home care and nursing billing: time/route plausibility of billed visits.
• Billing-audit services / Medizinischer Dienst support: document review for hospital invoices.
• Private use: not applicable; individuals may only check their own invoices (see DOC-001 for the generic invoice pipeline).

How it works

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

• Core is classical ML: gradient-boosted trees on tabular claim features remain the workhorse; unsupervised detectors (isolation forest, autoencoders, peer-group z-scores) cover unlabeled new schemes; graph features expose rings.
• LLM role is supporting: extract fields from invoices and medical notes, summarise a provider's billing history, explain reason codes in plain language, and answer questions on fee-schedule rules via RAG. LLMs should not produce the fraud decision.
• Human-in-the-loop: every adverse action (payment denial, recovery claim, referral under § 197a(4) SGB V) is a documented human decision [1].

Data preparation

Claims and invoice data (ICD-10-GM, OPS, EBM/GOP or DRG codes, tariff positions, amounts, provider and patient pseudonyms) lives in the claims-processing core system or data warehouse; provider master data, licences and exclusion lists sit in separate registers; invoices and medical excerpts arrive as PDF, scans or paper. Prior investigation outcomes, the only real labels, are often stored in case files or spreadsheets.

Typical gaps: code systems that change by year, duplicates and corrections across versions, unlinked provider identities (several IDs per practice), missing investigation outcomes, scanned invoices, and strict access rights for special-category data.

Preparation steps: - Build a patient and provider key concept with pseudonyms that stay stable across systems (PREP-022). - Consolidate claim versions and reversals, and harmonise code tables per year. - Harvest labels from closed investigation cases and tip-off records (PREP-020) and build an evaluation set with investigators (PREP-018). - OCR invoices and extract fields (PREP-006, DOC-014). - Document the legal basis for secondary use (PREP-025). - Restrict access by role and log it.

Tools: SQL, dbt-style pipelines, Paperless-ngx or OCR engines for scans, pandas. Preparation is typically 50-60 percent of the effort; see GUIDE-003 for a readiness check and PREP-005 for system extraction.

Implementation paths

Which path for whom

• Enterprise: Path C, because claims data contains health data (special category), volumes are large, and payers can run open-source scoring on their own HW2 infrastructure under their control.
• Public: Path C, because statutory payers and public bodies need sovereign hosting, auditability and independence from a single vendor.
• Developer: Path C, because tabular and graph models are open source and the sensitive data must not leave the controlled environment.

Path A — Buy (off-the-shelf)

• Specialised payment-integrity / fraud platforms: Shift Technology (FR, claims fraud and healthcare payment integrity), Cotiviti, Optum payment integrity, Gainwell and similar vendors; SAS Fraud Management and Verisk analytics are common in insurance. In DE, IT service providers to the Krankenkassen (e.g. GKV-Informatikdienstleister) and audit-service firms offer plausibility checks. Verify current product scope and EU hosting with each vendor.
• Choose A when: you lack a data science team, need a proven rule library and want vendor-maintained models. Insist on explainable reason codes, EU data residency and audit logs.

Path B — Build on cloud APIs

• Tabular ML + feature store on an EU cloud region (managed gradient boosting and AutoML services of Azure, AWS Frankfurt, Google Cloud EU; STACKIT and IONOS as EU-sovereign options).
• LLM layer: a frontier or EU provider model (e.g. Mistral, Claude or Gemini via EU endpoints) for dossier writing and invoice extraction; only pseudonymised data, no training on prompts, DPA in place.
• Orchestration: n8n or Camunda for case workflow; case tool integration (e.g. existing case management).
• Choose B when: you have a data team and want custom logic but accept a processor under GDPR Art. 28. Health data is special-category data (Art. 9): requires a clear legal basis.

Path C — Self-host (open source)

• Stack: Python with scikit-learn, XGBoost/LightGBM, PyOD for outlier detection (BSD-2 licence, 60+ detectors, with the ADBench benchmark) [4], NetworkX or a graph database for network analysis, and an open-weight LLM (e.g. Qwen, Llama or Mistral families) via vLLM for dossier drafting and document extraction.
• Tooling: Docling or PaddleOCR for invoice parsing (see DOC-001), MLflow for model registry, Postgres/OpenSearch for features and cases.
• Hardware: HW2 is sufficient for tabular modelling plus a ≤30B quantised LLM; training on claims is mostly CPU. This is the natural choice for payers who may not move health data to a cloud.

Path D — Custom training

Worth it for large payers with years of investigated cases: train supervised models on confirmed outcomes (positive labels are scarce and biased towards previously audited providers), add graph neural networks for ring detection and fine-tune small encoders for text-based code plausibility. Needs labels from investigation outcomes, clean master data and a leakage-safe evaluation (time-based splits, provider-level splits).

State of the art (2026)

• Hybrid stacks win: rules + supervised trees + unsupervised outliers + graph features, fused into one score with reason codes. Benchmarks such as ADBench show no single unsupervised detector wins across datasets, so ensembles and domain features matter more than model novelty [4].
• Pre-payment scoring is replacing pay-and-chase wherever law and contracts allow it.
• LLMs/agents now draft case dossiers, read medical documentation excerpts and check codes against fee schedules; they are most useful as investigator assistants, not scorers.
• Network analytics find collusion among providers, patients and intermediaries that claim-level models miss.
• Limits and failure modes: label bias (only audited providers have labels), concept drift as schemes adapt, false positives that burden honest providers (e.g. unusual but legitimate specialised practices), data-quality problems in code mappings, and adversarial adaptation. Never treat an anomaly as proof of misconduct.

Shared resources & combinations

• Same capability stack (tabular-ml + anomaly-detection + graph-ml): ANOM-003 (insurance claims fraud), ANOM-019 (benefit fraud), ANOM-002 (AML transaction monitoring), ANOM-009 (expense & procurement fraud), ANOM-006 (ledger anomalies). One feature store, graph database and case-management system can serve all of them.
• Document layer (ocr-docparse + llm-general): DOC-001 (invoice processing), ANOM-017 (document tampering) for forged invoices or prescriptions; HLTH-005 (medical coding) supplies code-plausibility knowledge and flags coding errors that are not fraud.
• Hardware: a single HW2 server runs the OCR/VLM and LLM services for all of the above; the scoring models need no GPU.
• Shared data: provider master data, exclusion lists, fee schedules and code catalogues are reused across use cases.

Effort, cost & KPIs

• Path A: 3–9 months including data integration; licence is typically per claim volume or insured lives.
• Path B: 6–12 months for a first production model plus workflow.
• Path C: 6–12 months, one data science/engineering team plus a small server.
• Path D: 12+ months incl. label building; ongoing monitoring and retraining.
• Cost drivers: data integration and cleansing, investigator capacity, label quality.
• KPIs: hit rate (confirmed findings / cases reviewed), euro recovered or avoided per investigator FTE, pre-payment stops upheld on appeal, false-positive rate by provider group, time from alert to decision, drift indicators.

People & change

Involve management and the head of audit/investigation at the start, then the DPO, legal/compliance and information security before any data is touched, because claims data is health data (GUIDE-005, GUIDE-013). IT and data owners of the claims system provide extracts; investigators are the daily users and should shape reason codes and the review workflow. Providers and insured persons are affected by the output, so the legal basis and process rules for contacting them must be clear.

Works council: depends. Scoring is about providers and claims, not staff behaviour, but case-handler activity logs and productivity statistics in the workflow tool can be suitable for monitoring under §87(1) no. 6 BetrVG, and §90(1) no. 3 requires information on AI-planned work processes. Public payers involve the Personalrat (GUIDE-004). A DPIA under Art. 35 GDPR is very likely (special categories, systematic evaluation), plus an AVV for every processor.

Support AI literacy of investigators (Art. 4 AI Act, GUIDE-006). Start with a small pilot team, run the model in shadow mode next to existing checks, and state clearly that a score is a lead, never a decision: humans verify every case before any payment is withheld or a provider is contacted. Typical concerns are false accusations and opacity; answer with explainable reason codes (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: classification depends on the use. Pure detection of fraud against a payer, with humans deciding, is generally not an Annex III use case on its own; however, systems that evaluate eligibility for or reduce, revoke or reclaim public healthcare benefits or services (Annex III point 5(a)) or that assess risk and pricing for life and health insurance (point 5(c)) can be high-risk. The exemption for financial-fraud detection in Annex III point 5(b) concerns credit scoring and should not be assumed to cover other uses. Document the intended purpose and run a classification review; if high-risk, apply risk management, data governance, logging, human oversight and transparency (Art. 9–15) [5]. Prohibited practices (Art. 5), such as social scoring of individuals, must not be approximated: score claims and providers, not people's general trustworthiness.
• GDPR: health data is special-category (Art. 9); needs legal basis (e.g. statutory duties of GKV units under § 197a SGB V and §§ 67c ff. SGB X) [1], data minimisation, pseudonymisation, DPIA (Art. 35) and Art. 22 safeguards: no solely automated adverse decisions on individuals.
• Sector law: SGB V (§ 197a, §§ 106 ff. billing audits), StGB § 263 (fraud) and §§ 299a/b (corruption in healthcare), Medizinischer Dienst rules; for US programmes the False Claims Act and HIPAA.
• Fairness and provider rights: investigations must follow due process; explainable reason codes and the right to respond protect honest providers.
• Security: treat case files and model features as highly sensitive; role-based access, audit logs, no raw health data to external LLMs.

Getting started

1. Define scope (billing domain such as pharmacy or home care) and secure the legal basis and DPO/works-council involvement.
2. Inventory data: claims, master data, past audit outcomes; measure label volume and quality.
3. Build a baseline: peer-group outlier report per specialty and region plus simple rules; review the top 50 with investigators.
4. Add a supervised model on confirmed cases, with time-split evaluation and reason codes; pilot in shadow mode.
5. Introduce the case-dossier assistant (RAG over fee schedules, pseudonymised data), and set up outcome feedback and drift monitoring.

Sources

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