ClaimGuard: Claims Denial Prediction
Denial risk scored before submission with the specific correctable defect attached, because a probability tells a biller what they already suspected.
Client
Healthcare Provider Network, Multi-Payer Claims Estate
Industry
Revenue Cycle · Claims Operations
Duration
6 months
Year
2025
Background
A denied claim is not lost revenue so much as deferred revenue with a cost attached: someone has to work out why, correct it and resubmit, and that labour recurs on every occurrence. The defects that cause denials are mostly small and mostly knowable before submission (an unsupported code, a missing modifier, an eligibility gap) but payer adjudication rules shift faster than a billing team can track, so the same avoidable denial repeats for weeks before the pattern is noticed.
The Challenge
The obvious build is a model that scores denial likelihood, and it is close to useless. A biller told a claim is high-risk knows only what their experience already told them, and has no more idea which field to change than before. The requirement was a named, correctable defect per claim, which is a different and harder modelling problem, and it had to be produced without the people building the model ever seeing patient data.
Our Solution
SageWare built the pipeline and the modelling layer. Claims are processed in batch, with clinical entity extraction used both to de-identify records and to compare coding against what the documentation actually supports. Rather than one denial classifier, the design runs per-reason classifiers so the output names a defect class with the supporting evidence attached to it. Member identifiers are tokenised at ingress, before anything reaches the analytical layer, with re-identification keys held separately, so the separation between people who see records and people who build models is enforced by the pipeline rather than by policy.
Key Deliverables
- Per-reason classifiers naming a correctable defect rather than a denial probability
- Tokenisation at ingress, so the analytical layer never receives identifying data
- Coding compared against what the clinical documentation actually supports
- Hard tenant partitioning, with no model weights shared across payers
Results & Impact
How We Did It
01
Denial Taxonomy
Worked back from historical denials to the correctable defect behind each one, which is what determined the model structure rather than the other way round.
02
De-identification Boundary
Placed tokenisation at ingress so the analytical layer never receives identifying data, making role separation structural rather than procedural.
03
Per-Reason Classifiers
Built classification per defect class with document-level evidence attached, so a flag arrives with the reason and the supporting text.
04
Batch Pipeline & Tenanting
Parallelised processing across claim volume and partitioned tenants hard, so no model weights are shared between competing payers.
Decisions & Trade-offs
A probability is not actionable. A reason is.
A model returning “this claim has a 72% chance of denial” gives a biller nothing to do. We split the problem into per-reason classifiers so the output names a correctable defect and points at the documentation that contradicts it. It is a harder modelling problem and the headline accuracy is lower than a single binary classifier would report. It is also the difference between a queue someone works and a queue someone ignores.
The people who build the model never see a record
Tokenisation could have sat at the analytical layer, which is simpler and keeps real values available for debugging. We put it at ingress instead, so identifying data never enters the environment the modelling work happens in. It makes some debugging genuinely awkward. You cannot eyeball the record behind an odd prediction. That awkwardness is the control working, and we would rather have it than rely on everyone remembering the rule.
No shared model weights across competing payers
Claims formats are standardised enough that one model trained across every tenant would perform better than several trained separately, and we did not build it that way. A payer’s denial patterns are commercially revealing, and a model trained across competitors carries that signal whether or not anyone intended it. Each tenant is partitioned to its own weights, which costs accuracy on smaller tenants and makes cold start slower.
Scope & Boundaries
We built the ingestion, de-identification and modelling pipeline and the flag surface billing teams work in. Claim submission, payer contracts and the practice management system remained the client’s. Clinical documentation quality was reported on, not corrected. The system names what the record does not support, and stops there.
Next Case Study
FraudLens: Real-Time Transaction Fraud
Payments · Fraud Risk