ClaimGuard
Prior-authorisation decision clocks, payer rules and denial root causes, inside Odoo.
The short answer
ClaimGuard is a revenue-cycle layer for US specialty clinics and surgical centres that keep the clinical system they already run. It stores prior authorisations with a computed decision clock, records which CPT codes each payer requires authorisation for, and keeps every denial with the codes the payer returned and a written root cause. Encounters here are billable facts, not charts.
Last updated
What it is for
A payer has had a prior authorisation for over a week and nobody in the office is counting. The regulatory decision window is the only pressure a practice has, and it works only if somebody knows the exact moment one is crossed. In most offices that somebody is a person with a spreadsheet and a memory. The same gap runs through the rest of the revenue cycle: a coverage that terminated before the date of service, a diagnosis the payer will not accept for that CPT, an authorisation still pending when the claim went out. All three are knowable before the claim is sent, and all three come back as denials anyway.
- Platform
- Odoo
- Category
- Regulated records
- Works with
- Odoo 19
- Technical name
claimguard- Status
- Direct from webbox
- Pricing
- Paid
What is inside it
- 01
The clock
The submitted timestamp plus the window that urgency earns gives a decision due date. Clock status and hours remaining are stored computed fields, so a breach is a fact about the record rather than a flag somebody sets.
- 02
Payer rules
One row per payer and CPT code, saying whether authorisation is required and which documents that payer expects with it. The binder, the bookmark and one person's head become records.
- 03
Denials
Every denial keeps its amount, the CARC and RARC codes the payer returned, a category and a written root cause. Triaged, appealing, overturned and upheld are states, so nothing goes quiet.
- 04
Encounters
Patient, coverage, date, place of service, and service lines with their CPT and ICD codes. Deliberately thin: enough to price, scrub and authorise, with no attempt on the chart.
- 05
The board
Seven tiles over charts for denials by category, authorisations by state and scrub status per line. Clicking a tile opens the records it counted.
What it looks like in practice
-
An authorisation sits two days past the point the payer owed an answer
A standard request was submitted nine days ago and the payer has still not decided. Nobody has flagged it, because nobody was counting.
Decision due, clock status and hours remaining are computed from the submitted timestamp and the urgency, so the record reads Breached on its own and hours remaining goes negative and stays negative. The breach tile counts only requests still submitted or pending, since a decided request cannot breach.
- Submitted
- nine days ago
- Urgency
- Standard (7 days)
- Hours remaining
- -48.02
Figures from the module's own demo data, on a fresh install. Install with demo data and open the prior authorisation PA00003.
The clockThe board
-
A denial names the earlier step that could have gone differently
Three denials sit in the workqueue for the period, and the amount attached to them is the practice's own money.
Each one keeps the CARC and RARC codes the payer returned, a category drawn from the recurring set of eligibility, coding, prior authorisation, medical necessity, timely filing and duplicate, plus a written root cause. That is what turns a list into a prevention list.
- Denials this period
- 3
- Amount
- $20,142
Figures from the module's own demo data, on a fresh install. Install with demo data and click the Denials tile on the ClaimGuard board.
DenialsThe board
-
One service line fails the scrub before the claim leaves
Service lines across the period each carry a scrub status. One of them fails, and it would otherwise be found on a remittance weeks later.
Scrub status lives per line on the encounter, and the clean-scrub tile counts passes against the total. The failing line is visible on the encounter beside its CPT and ICD codes, which is where somebody can still fix it.
- Clean scrub
- 75%
- Lines
- 3 pass, 1 fail
Figures from the module's own demo data, on a fresh install. Install with demo data and click Clean scrub on the ClaimGuard board.
EncountersThe board
What it deliberately does not do
- No live clearinghouse or EDI
- Eligibility and authorisation records are real and enforced, but nothing transmits. The protocol field reads Mock, and connecting a clearinghouse or a FHIR endpoint is a later phase, not this one.
- No machine-learned risk scoring
- Risk score is a number on the line that you or an import set. There is no trained model behind it today, and the module does not pretend otherwise.
- No claim submission or 837
- This is the layer that decides whether a claim should go out clean. Producing and sending the claim itself is not here.
- Not an EMR
- Encounters are billable facts, not charts. No clinical notes, no orders and no results, which is the point of the design.
Questions
Can I install this on Odoo Online?
Does it send eligibility checks or authorisations to a payer?
Is the risk score predictive?
Who can read the raw eligibility payload?
Have something to build?
Tell us the problem. We'll come back with a plan, a price, and who'd actually build it.
- Free scoping call
- Reply within 1 business day
- No lock-in