Claim Intelligence

The cheapest denial to work is the one you never get.

Coverage, authorisation, coding and submission checks run before the claim goes out. Every issue comes back in plain English, with what the payer will do about it and what to attach or change to clear it.

Book a Demo See how it works

Issues arrive with their fix
Suggested codes cite the chart
Blocking issues called out

Claim validation results across six categories, with a high-severity eligibility finding: the service date falls outside the patient's active coverage period.

Validation results grouped by category. One failing category fails the claim, and each issue carries its explanation and the recommended correction.

What it does

Confirms coverage

Active coverage on the date of service, the right payer order when there are two plans, deductible and benefit detail — checked before billing rather than discovered after.

Checks the coding

Procedure and diagnosis pairings, bundling conflicts, required modifiers, laterality, units and place of service — the edits that turn into avoidable denials.

Explains in plain English

Not a rule code and a shrug. Each issue says what the payer will do, the policy behind it, and the documentation needed to clear it.

Separates blockers from judgement

Only genuinely blocking issues hold a claim. A judgement call is raised for review without stopping work, so the queue stays credible.

How it works

1
Check the patient and the plan
Coverage active on the date of service, the payer order confirmed, and any authorisation the service needs actually on file.
2
Validate the claim
Codes, modifiers, diagnoses, units and place of service, against what this payer will accept.
3
See what would happen
Issues are grouped by area and rated, with a single failing area failing the claim rather than being averaged into a pass.
4
Fix it and send it clean
Apply the correction, attach what was asked for, and the claim goes out without the round trip.

An issue without a fix is just bad news

“Claim failed validation” tells a biller nothing they can act on, and a queue of unactionable warnings is how validation gets switched off. Every issue here comes with what to do about it.

What the payer will do, stated in a sentence rather than as a rule code.
The policy the issue rests on, so it can be checked and argued rather than taken on faith.
The documentation to attach, named explicitly, so nobody guesses which note is wanted.
Where the fix is mechanical, the specific correction to apply.

Areas checked

Patient and eligibility
Coverage dates, plan status, coordination of benefits.
Provider and network
Rendering provider, identifiers, participation.
Coding and clinical validation
Procedure and diagnosis consistency, modifiers, bundling.
Documentation and attachments
What the payer needs enclosed for this service.
Claim structure and submission
Units, charges, place of service, formatting.

Stopped before it is billed, not after

The encounters that quietly cost the most are the ones sitting between the visit and the claim — coverage that lapsed, an authorisation nobody chased, charges never captured. They generate no denial because they generate no claim.

Held encounters get their own queue, ranked by what is at risk and how close the filing deadline is.
Each hold names the specific blocker and the step that clears it.
Dollars at risk are totalled, so the backlog has a number attached rather than being a vague worry.
Anything approaching its filing limit is surfaced while filing is still possible.

Caught before submission

Coverage inactive on the date of service
The plan was not in force when the service was rendered.
Plan termed, primary unconfirmed
Two coverages, and the payer order is not established.
Prior authorization missing
The service requires one and none is on the claim.
Authorization expired or exhausted
The approval lapsed or its units ran out before the visit.
Charges not captured
Documentation incomplete, so the encounter cannot be billed.
Submission edit failing
The claim would reject at the payer's front end as it stands.

Coding suggestions a coder can check

A suggested code you cannot trace is a code you have to re-derive yourself, which is slower than coding it from scratch. Each suggestion shows the document and the exact sentence in the chart it came from.

Hover a suggested diagnosis and see its source document and the supporting text verbatim.
Each suggestion carries a confidence level and a payer-compliance flag.
Codes can be removed or added by hand — the suggestion is a starting point, not a decision.
Charge capture pairs each procedure with the diagnoses that justify it, and the reasoning for the pairing.

On every suggested code

Source document
Which chart or note it was drawn from.
Supporting text
The sentence that justifies it, quoted.
Confidence
How strongly the documentation supports it.
Payer compliance
Compliant, needs review, or not valid for this payer.

Before billing

Caught while it is still fixable

Not after the payer has said no

Explained

Plain English on every issue

With the documentation to attach

Cited

Suggested codes show their source

The sentence in the chart behind each one

Prioritised

Blocking issues come first

Judgement calls flagged, not enforced

Common questions

Does this replace our clearinghouse scrubber?: It runs ahead of it. A scrubber tells you a claim will reject on format; these checks tell you why the payer will refuse to pay it — coverage dates, a missing authorisation, a bundling conflict — while the encounter can still be corrected.
Will it stop claims for trivial reasons?: No. Only genuinely blocking issues hold a claim. Judgement calls are raised for review, and a claim can be ready to send with a review item still open.
Can we see why a code was suggested?: Yes. Each suggested diagnosis links to the document it came from and the exact sentence supporting it, with a confidence level and a payer-compliance flag alongside.
What happens once the filing window has passed?: The product says so rather than letting you rework in vain — a corrected claim filed after the limit will reject as untimely, so the remaining path is an appeal.

Explore the rest of the platform

See Claim Intelligence run against your own claims.

We’ll walk your team through a live workspace using a sample of your data, and show exactly where the recoverable dollars are.

Book a Demo Back to overview