Building a Smarter Fraud Detection System for Healthcare RCM

Fraud detection in healthcare revenue cycle management cannot be treated like a side project anymore.

For years, most RCM organizations have focused on getting claims out the door, reducing denials, accelerating cash, and improving collections. Those things still matter. They always will. But the next evolution of revenue cycle is not just about collecting faster. It is about knowing whether the claim, payment, denial, adjustment, or provider behavior makes sense in the first place.

That is where fraud, waste, abuse, and revenue integrity all start to overlap.

A good fraud detection system should not simply ask, “Was this claim paid?”

It should ask better questions.

Was this service expected?
Was the billing pattern normal?
Does the documentation support the service?
Does this provider look different from similar providers?
Did the behavior change suddenly?
Are there relationships between patients, providers, suppliers, labs, or referring entities that should be reviewed?
Is this a one-off issue, or is it part of a larger pattern?

That is the real challenge. Fraud does not always show up as one obvious bad claim. Many times, it shows up as a pattern.

Why This Matters Now

The scale of healthcare fraud is not theoretical. In June 2025, the Department of Justice announced a national healthcare fraud takedown involving 324 defendants and more than $14.6 billion in alleged intended loss. CMS also reported preventing more than $4 billion from being paid in response to false and fraudulent claims tied to that enforcement effort.

GAO also reported in 2026 that CMS uses data analytics to identify anomalous Medicare billing patterns, such as billing spikes, that may indicate emerging fraud schemes. CMS estimated that it prevented $11.9 billion in potentially fraudulent Medicare payments from fiscal years 2022 through 2024 through administrative actions such as payment suspensions, revocations, deactivations, overpayment recoveries, and prepayment reviews.

That tells us something important.

The future of fraud detection is not just manual auditing. It is not just rules. It is not just machine learning. It is a connected intelligence system that combines data, rules, models, explainability, workflow, and human review.

“Fraud detection is not a model. It is a learning system built on data, context, explainability, and human review.”
– Christopher Benefield

First, Be Careful with the Word Fraud

One thing has to be clear up front.

A model should not be making a legal conclusion that fraud occurred. Fraud usually requires intent, and intent is not something a model can prove on its own.

The better way to frame this is:

The system detects fraud risk, suspicious behavior, unusual patterns, waste, abuse, overbilling indicators, and claims that deserve review.

That wording matters. It protects the credibility of the system. It also keeps the organization from overstating what AI can do.

AI can flag.
AI can prioritize.
AI can explain.
AI can compare patterns.
AI can assemble evidence.

But people still need to review, validate, and decide what action should be taken.

The Foundation: Clean, Connected RCM Data

Before talking about models, the data foundation has to be right.

A fraud detection system is only as good as the data underneath it. If claim data, remittance data, provider data, contract data, authorization data, denial data, and clinical documentation are all sitting in separate systems, the model will only see part of the story.

The system needs a common data model that brings together the major RCM signals:

837 claim data
835 remittance data
CPT, HCPCS, ICD-10, modifiers, units, and place of service
CARC and RARC codes
Charges, payments, adjustments, and write-offs
Provider, rendering, referring, billing, and facility identifiers
Payer and plan information
Authorization data
Eligibility indicators
Contract expected reimbursement
Patient encounter history
Denial and appeal outcomes
Audit findings and review dispositions

This is where the semantic layer becomes critical.

Raw claims data tells you what happened. The semantic layer helps explain what it means.

For example, a model may see that a certain CPT code is being billed more often. That is useful, but not enough. The system also needs to understand specialty, payer, location, diagnosis mix, patient acuity, provider history, medical necessity rules, and reimbursement impact.

Without that context, fraud detection becomes noisy. With that context, the system becomes explainable.

Layer One: Rules Still Matter

Rules are not outdated. Bad rules are outdated.

There are many known patterns that should still be handled through deterministic logic. These are the things the organization already knows how to identify.

Examples include:

Duplicate claims
Impossible billing combinations
Modifier misuse
Excessive units
Billing after discharge
Billing before the date of service
Mutually exclusive procedures
Services billed without expected supporting events
High-dollar codes used at abnormal frequency
Repeated corrected claims
Claims submitted just below review thresholds

Rules are especially useful when they are tied to policy, coding guidance, contract logic, or known internal controls.

But the rule should not just say, “Flagged.”

It should tell the user why.

Which rule fired?
Which claim line triggered it?
What policy or business logic was used?
Is this a coding issue, documentation issue, medical necessity issue, payment issue, or potential fraud/waste/abuse concern?

The explanation is just as important as the flag.

Layer Two: Supervised Models for Known Patterns

Supervised learning is useful when you already have labeled history.

That history may come from confirmed audit findings, payment integrity reviews, SIU referrals, compliance investigations, payer takebacks, refund requests, or known bad billing patterns.

In this layer, the model is learning from the past.

Models like logistic regression, random forest, XGBoost, LightGBM, and CatBoost can work well with structured claims and RCM data. The goal is not to create a mysterious black box. The goal is to score claims, providers, or accounts based on known indicators of risk.

The output should look something like this:

Risk Score: 87 out of 100
Risk Category: High
Primary Drivers: abnormal modifier usage, units above peer group, diagnosis/procedure mismatch, unusual payment variance, sharp increase in high-dollar codes over the trailing 90 days

That is useful because it gives the reviewer somewhere to start.

The weakness of supervised learning is that it mostly finds more of what you have already seen. If your historical labels are limited, biased, incomplete, or outdated, the model will inherit those limitations.

That is why supervised learning is not enough.

Layer Three: Unsupervised Learning for the Unknown

The harder problem is finding the thing you do not already know to look for.

That is where unsupervised learning becomes valuable.

Instead of asking, “Does this look like fraud we have seen before?” unsupervised learning asks, “Does this behavior look abnormal compared to what we expected?”

That is a very different question.

This matters because new schemes often do not match last year’s rule set. Bad actors adapt. Billing behavior changes. Payer rules change. New service lines emerge. New vendors, suppliers, and referral patterns enter the ecosystem.

Unsupervised techniques can help identify outliers, clusters, and sudden behavior changes. Common approaches include Isolation Forest, Local Outlier Factor, clustering methods, autoencoders, association rule mining, and change point detection.

Research has supported the use of unsupervised learning and explainable methods for healthcare fraud and overbilling detection, especially where labeled fraud data is limited or incomplete. One Medicare-focused study used unsupervised machine learning to identify provider patterns consistent with fraud or overbilling while still providing interpretable reasoning for users.

The key is peer grouping.

You cannot compare every provider to every other provider and expect meaningful results. A cardiologist should not be compared to a dermatologist. A rural clinic should not be compared to a large urban health system. An oncology practice should not be compared to a low-acuity primary care clinic.

The system has to compare behavior against the right baseline:

Specialty
Geography
Payer
Facility type
Patient acuity
Diagnosis mix
Contract structure
Service line
Historical provider behavior
Trailing 30, 60, and 90 day trends

Unknown fraud risk is often not found in one claim. It is found in movement over time.

Layer Four: Graph Analytics Shows the Network

Some suspicious activity only becomes visible when you connect the relationships.

A single claim may look normal.
A single provider may look normal.
A single patient may look normal.

But the network may not look normal.

Graph analytics can connect providers, patients, referring entities, suppliers, labs, pharmacies, billing companies, addresses, phone numbers, NPIs, Tax IDs, and claim activity.

That allows the system to look for patterns such as:

Unusual referral clusters
Shared addresses across unrelated entities
Circular referral behavior
High-risk supplier relationships
Patients connected to multiple unusual billing entities
Sudden network growth around a high-dollar service
Billing companies connected to abnormal provider behavior
Small groups of providers driving a large share of questionable claims

This is important because many fraud schemes are not isolated events. They are networks.

The claim is the transaction.
The graph shows the story.

Layer Five: Sequence Analysis Finds Behavior Over Time

RCM data is not just a set of transactions. It is a timeline.

A patient has a journey.
A provider has billing behavior.
A payer has adjudication patterns.
A denial has a history.
An appeal has a sequence.
A claim has a lifecycle.

Fraud and abuse can show up in the order of events.

For example:

A provider suddenly shifts from low-complexity to high-complexity codes
A service is billed repeatedly after similar diagnoses
Authorization timing does not line up with the service
Claims are corrected and resubmitted in unusual patterns
Payment behavior changes without a clear business reason
High-dollar services spike after a new referral source appears
A provider repeatedly bills just below review thresholds

Sequence models help answer a basic but powerful question:

Does the order of events make sense?

In RCM, that question matters.

Layer Six: LLMs Can Help, But They Should Not Be the Judge

Large language models can play a role, but they need to be used carefully.

An LLM should not be the final fraud detection engine. It should not be making final determinations. It should not be allowed to accuse a provider, deny a claim, or make a legal conclusion by itself.

Where LLMs can help is in the review process.

They can summarize why something was flagged.
They can translate denial codes and claim signals into plain language.
They can compare documentation against billed services.
They can help assemble an evidence packet.
They can summarize appeal history.
They can identify missing documentation.
They can help reviewers move faster.

That is valuable.

The model might say:

“This claim was flagged because the billed units are significantly higher than the provider’s peer group, the modifier pattern changed in the last 60 days, the diagnosis does not commonly support this service, and similar claims have recently resulted in medical necessity denials.”

That kind of explanation helps the human reviewer understand what to look at.

The LLM should not say:

“This is fraud.”
That is the line.

Human Review Is Not Optional

Healthcare is too complex, and the consequences are too high, to remove people from the process.

CMS’s WISeR model is a good example of the direction the industry is moving. The model uses enhanced technologies such as AI and machine learning, along with human clinical review, to support timely and appropriate Medicare payment for selected services. CMS also states that recommendations for non-payment are determined by appropriately licensed clinicians using standardized, transparent, evidence-based procedures.

That is the right idea.

Technology should prioritize the work.
People should make the decision.

The workflow should look something like this:

A claim, provider, or pattern is scored
The system explains the risk drivers
An evidence packet is created
The case is routed to the right queue
A reviewer validates the issue
The outcome is coded
The model learns from the result
Rules and thresholds are updated

That last part is where the value compounds.

The Feedback Loop Is Where the System Gets Smarter

The best fraud detection system is not the one with the most complicated model. It is the one that learns from every review.

Every case should end with a structured disposition.

Confirmed fraud
Suspected fraud
Waste
Abuse
Billing error
Coding error
Documentation gap
Medical necessity concern
Contract issue
Payment issue
False positive
Needs more information

Those outcomes should feed back into the system.

Rules get better.
Models get better.
Peer groups get better.
Thresholds get better.
Dashboards get better.
Review queues get better.

Without that feedback loop, the system gets stale. With it, the organization starts building institutional intelligence.

What Leaders Should See

Executives do not need a dashboard full of model outputs. They need to understand exposure, action, and impact.

A good dashboard should show:

Total claims screened
Claims flagged by risk level
Dollars at risk
Payments prevented or held for review
Overpayments identified
Recoveries initiated
Top risk categories
Top provider outliers
Top payer or service line concentrations
False positive rate
Review cycle time
Confirmed findings
Emerging anomaly clusters
Model precision by risk tier
Trends over time

The dashboard should also separate categories clearly.

Fraud risk is not the same thing as coding error.
Waste is not the same thing as abuse.
A payment issue is not the same thing as intent.

That distinction protects the credibility of the program.

The Future: Closed-Loop Revenue Integrity

The future of fraud detection in RCM is not a standalone fraud tool. It is a closed-loop revenue integrity system.

That system connects claim creation, coding validation, authorization history, clinical documentation, contract reimbursement, payer adjudication, denial outcomes, appeal activity, provider behavior, patient utilization, and audit findings.

Once those pieces are connected, the organization can stop looking at claims as isolated events.

It can start seeing patterns.

That is where the real value is.

Traditional RCM asks:

“Did we get paid?”

Modern revenue integrity asks:

“Should this have been billed, paid, denied, reviewed, appealed, or escalated?”

Fraud detection belongs inside that second question.

Final Thought

Known fraud patterns can be handled with rules, history, and supervised models.

Unknown risk patterns require anomaly detection, peer comparison, graph analytics, sequence analysis, and strong feedback loops.

LLMs can help explain and summarize, but they should not be the decision maker.

The real goal is not to build a system that screams “fraud” every time something looks different. The goal is to build a system that understands normal behavior well enough to know when something deserves a closer look.