Payer policy changes, caught in days.
The payer changed the rules in July. Your aging report will say so in September.
A payer starts denying one code without telling anyone, and by the time the cash gap shows up on the aging report you have sent out hundreds more claims under the old assumption. The change was already in your own remittance data within a week.
Fourteen real series, one injected policy change, detection computed live in your browser.
The problem
You are watching an average that cannot move.
Every practice tracks denial rate. Almost always in aggregate, sometimes by payer, rarely by payer and code together. That is the level where a policy change actually happens: one payer, one procedure code, one adjudication rule. At the pair level the signal is unmistakable. Rolled up into a single practice-wide number it is diluted below the week-to-week noise, so the first thing anyone notices is that collections came in light, six weeks later, on claims whose appeal windows have already started closing.
The insight
A policy change is a step function. It is only invisible because of where you look.
A payer flipping an adjudication rule produces a step change in denial rate for one payer and one code, on a specific day, and it shows up in your own remits within days of the first affected claim adjudicating. Nothing exotic is required to see it. The reason nobody does is that the two obvious ways of looking both fail: aggregate monitoring dilutes the pair into invisibility, and per-pair monitoring means thousands of simultaneous tests, which without multiplicity control buries the real one under false alarms until the team stops reading the alerts. This is a multiplicity problem wearing a healthcare costume, and the fix is the one statisticians settled in 1995. Denial Radar reads remittance data and tells you a pattern changed. It does not tell you how to code a claim, whether care was medically necessary, or what to appeal.
CUSUM on day-over-day change for sustained shifts, Bayesian Online Changepoint Detection (Adams & MacKay 2007) for the abrupt ones, and Benjamini-Hochberg FDR control across every payer × code pair in the run. Three thousand six hundred tests at a 5% per-test rate would give you 180 false alarms a day. FDR control is what makes pair-level monitoring possible at all.
How it works
Four steps, no data science team
Electronic remittance advice from your clearinghouse or practice management system. Read-only, no workflow change, no new data entry.
Denial rate, days to payment, first-pass yield, appeal overturn rate, and average allowed amount, each as a daily series for every pair with enough volume to test.
Both detectors run on every pair. Benjamini-Hochberg then filters the results knowing all 3,600 tests were run, so what survives is worth a person opening.
Which payer, which code, the day the regime changed, how many claims have gone out since, and which of those still have an open appeal window.
Who it is for
The revenue cycle manager who found out from the aging report
Medical groups big enough to bill several payers across a few hundred codes, and the RCM firms that run billing for dozens of those groups at once. The RCM firm is the better shape: one integration, one detection run, denial intelligence across their whole book.
Pricing
- –Full detection engine
- –Pair-level monitoring
- –Appeal window countdown
- –Email and Slack alerts
- –Unlimited payer × code pairs
- –Cash impact estimate per finding
- –Denial reason code drilldown
- –PM/EHR writeback
- –SSO and role-based access
- –Cross-client detection
- –White-label alerts
- –API and bulk export
- –Detection tuning support
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Waystar | Clearinghouse with denial prevention and analytics on top of the claims it already routes. | Built to predict whether an individual claim will deny, using rules that update on their own release cycle. It answers a per-claim question, not "did this payer change its behaviour on Tuesday". |
| Availity | Payer connectivity network with denial reporting and payer policy feeds. | Reports what payers publish. The whole problem is the changes payers do not publish, or publish after the fact in a portal bulletin nobody read. |
| AKASA / Adonis | AI-driven revenue cycle automation: coding assistance, claim status, denial workflow. | Automates the work of processing denials faster. Faster processing of a denial wave still means the wave happened and nobody stopped the next 400 claims. |
| Your PM system reports | Athenahealth, eClinicalWorks, Epic and the rest all ship denial dashboards. | Aggregate views on a monthly cadence, reviewed when someone remembers. Every one of them has the dilution problem baked into the default grouping. |
The structural risk is that the clearinghouses have better data than we do. Waystar and Availity route remits for tens of thousands of practices, which means they can see a payer policy change across a panel and detect it before any single practice has enough claims to reach significance. If either of them decided to ship pair-level changepoint detection, they would start from a strictly stronger position and would not have to earn the integration. The bet is that they will not, because both are optimised around per-claim scrubbing and their analytics roadmaps have pointed at prediction rather than detection for years. If that bet is wrong, the only defensible position left is the RCM firm relationship, and that is a much smaller business.
Market
Priced against one avoided denial wave, not against software budget
Denial Radar pays for itself if it catches one policy change per year. A pair at 7% of a 50k-claim-a-year practice is 3,500 claims; a 17-point denial swing on those, at a $110 allowed amount, is roughly $65k of cash at risk over a quarter before anyone notices. Group tier is $21,600 a year against that. There are about 230,000 physician group practices in the US plus roughly 1,500 RCM firms. Three thousand groups on the Group tier plus 200 RCM firms is $79M ARR, and the RCM firms are the distribution channel for the rest.