Opens in a new tab

Nothing Told You Your Medical Claims Stopped

A report describes what happened. Detection tells you something changed. Almost every practice has one and assumes it has both.
Updated September 2026

You are on a call with whoever runs your reports, and you ask a question that sounds almost too simple. How would we know if our claims to the insurance companies stopped going out? The answer usually starts with “we’d notice.” Ask again, and mean it: how would we know this week, without anybody happening to look?

In most practices the honest answer is that nothing would say so. Somebody would feel that things were quiet, or one insurance company would go strangely silent. Or the cash would arrive short six weeks later and the search would start from there.

That is not a reporting failure, and the reports are fine. Reporting and detection are two different jobs, and almost every practice bought the first one and assumed the second came with it.

Here is the path this sits on. A visit happens, and someone turns it into a charge, the visit written up as a billable line. The charge becomes a claim, the bill sent to the insurance company.

The claim travels through a clearinghouse, the middleman service that carries it to the insurer, and the insurer answers with a payment or a denial, a refusal to pay with a reason code. Every one of those steps can quietly stop. This piece is about how you would know, and it belongs to the job of watching the whole money path.

How would we know if medical claims stopped going out?

Only if something is watching for it. A report tells you what happened and waits to be read. Detection watches one condition, claims sent yesterday equal to zero on a working day, and speaks when it is met. At a practice we operate, one insurance company’s enrollment, the paperwork that lets claims move electronically, showed “approved” for three years and carried no payment. Nothing said so. Nothing was watching.

If nobody can tell you what would fire, who would receive it, and how fast, you have reporting. The gap between the two is measured in weeks every time something goes wrong.

What is the difference between reporting and detection?

A report describes what happened and waits to be read. It answers a question you thought to ask, and it answers it well. Detection is a small number of rules that run on their own and produce a message when a rule is met, and silence otherwise. It tells you about something you did not know to look for.

The two get confused because both come out of the same billing system, and because a good report feels like it should catch everything. It cannot, for a reason that has nothing to do with how well it was built.

Why a stall leaves no record

Every record in a billing system exists because something happened. A note was written. A charge was created. A claim went out. A payment was posted, meaning the insurance company’s answer was recorded against the visit. The system is a complete and honest record of events, as far as that goes.

A stall is a thing not happening, so nothing gets written, because there is nothing to write. No report can read a record that does not exist, no matter how well the report is built.

The question a report answers is what happened. The question detection has to answer is what should have happened by now and did not. Nothing in standard reporting asks it, and it is the only question that catches a stall.

Four conditions worth watching

Detection is a handful of conditions, not a dashboard. Each has a rule, and each produces a message when the rule is met. Four of them cover most of what goes wrong on the money path.

Something that normally arrives daily and did not. Claims sent, charges created, payment reports received, meaning the insurance company’s electronic explanation of what it paid. Each has a normal daily rhythm, and a day at zero is an event even though it writes no record. This is the condition that answers the question at the top of this page.

Something that has moved outside its own normal range. An insurance company that used to decide on claims in twelve days and now takes thirty. A provider whose notes take twice as long to get signed. One denial reason showing up at four times its usual rate. The comparison is against that item’s own history, never an industry benchmark, because a benchmark says nothing about whether something changed here.

Something approaching a date. The filing deadline, the insurance company’s cut-off for accepting a claim. The appeal window, the time you have to challenge a denial. An authorization, the insurer’s advance approval for a service, running out. A card on file expiring. These are the easiest conditions to check and the most commonly ignored, because a future date makes no noise when it passes.

Something sitting longer than it should. A signed note with no charge after two days. A finished claim unsent after one. A payment report unposted after three. Each has a reasonable wait and an unreasonable one, and the difference is a rule somebody can write down.

Real situations, and what the report said at the time

At a practice we measured, the cancellation report showed zero cancellations in five months across more than forty thousand appointments. Nobody believed it. The row said zero because nothing was recording them, and a report can only total what was written down.

At another, a large insurance company went quiet in April. The aging report, the list of unpaid bills sorted by how long each has waited, showed the money getting older and nothing else. The mind filled the gap with “they stopped paying.” The claims had never reached them at all.

Why it has to run without anybody deciding

This is the part practices get wrong even after they accept everything above. A check somebody remembers to run is a check that runs when there is time, and there is never time in the week it matters. The week it matters is the week something has already gone wrong and everyone is busy.

So the condition has to run on a schedule, whatever anybody is thinking about that day. The message has to land with a named person instead of sitting in a report waiting to be opened. That is the whole difference between finding a problem in three days and finding it in three months. Same analysis. It runs whether or not anybody started it.

What good detection looks like in practice

Five mechanisms, and each is one of the four conditions applied to a specific failure. A circuit breaker stops a claim that matches a pattern already known to fail, before it goes out, so the same denial is not worked over and over.

Drift detection watches a number against its own past, so a practice turning care into cash in nine days that slides toward fourteen sees a flag instead of a bad quarter.

Lapse detection compares each patient’s expected return date against booked appointments. It turns a patient who quietly stopped coming into a name on a list. Expiration monitoring runs against every stored date that matters, from cards on file to a provider’s approval to bill an insurer, all of which fail silently on a known date.

Checking claims against your own history uses your own payment reports instead of published rules. It catches the failures specific to your practice and your insurers, the ones a scrubber, the automatic check a claim gets before it is sent, was never told about. Each is a spoke, not a strategy. What makes them detection is that each runs on its own and speaks only when a condition is met.

Where to start

One condition, not a system. Take the daily one, because it is the simplest and it answers the question this page opened with. Claims sent yesterday. If the number is zero on a working day, somebody should know before lunch.

That single rule catches a failed batch, a clearinghouse problem, and an enrollment gap that blocks a whole insurance company. All of those take weeks to surface today, and all of them are cheap on the first day. Then add the second condition, and the third. A practice with four working rules is in a different position from one with forty reports.

What this means for you

Ask the question at the top of this page and listen to the answer. If somebody can tell you exactly what would fire, who would receive it, and how long it would take, you have detection, and this article does not describe you. If the answer involves somebody noticing, a monthly report, or the cash looking odd, what you have is reporting.

The check is one number: claims sent yesterday, on your screen this morning, with a rule that says zero on a working day is a message to a named person.

Grab 30 minutes with us. Prep nothing. You will see which of the four conditions your own data could already be watching.

Questions people ask

What is the difference between reporting and detection?

A report describes what happened in a period and waits for somebody to read it. Detection watches for a specific condition and speaks when it is met, without anybody asking. One answers a question you thought to ask. The other tells you about something you did not know to look for, which is where stalled money hides.

How would I know if medical claims stopped going out?

Only if something is watching for it. Count the claims sent yesterday, every working day, with a rule that a zero produces a message to a named person. Without that rule a failed batch or a blocked insurance company surfaces weeks later, when the cash arrives short and the search starts from there.

Why do standard reports not catch stalled work?

Because every record exists because something happened, and a stall is a thing not happening. There is no record to read. Reports answer what happened. Catching a stall means asking what should have happened by now and did not, and standard reporting never asks that.

What conditions should a practice watch for?

Four. Something that normally arrives daily and did not. Something that moved outside its own normal range. Something approaching a date, like a filing deadline or an expiring card. Something sitting longer than it should. Nearly every failure on the money path fits one of those four.

Why does detection have to be automatic?

Because a check somebody remembers to run gets run when there is time, and there is never time in the week it matters. The rule has to run on a schedule regardless of what anybody is thinking about, and its message has to reach a named person instead of a report nobody opened.

ParseError: syntax error, unexpected identifier "s", expecting ")"