Benchmarks answer a question most practices are not actually asking.
A benchmark tells you where you sit relative to other practices. Useful once a year, in a board meeting, when somebody wants context. It tells you almost nothing about whether something in your operation changed last week.
Those are different questions and only one of them is urgent.
What is drift detection?
Watching a metric against its own recent history rather than against an external standard, so that a change surfaces as a signal rather than waiting to become a bad quarter. The comparison is you against you.
Why a benchmark hides movement
Take a practice converting care to cash in nine days, in a market where the typical figure is thirty.
That practice drifts to fourteen days. Against the benchmark it still looks excellent, so nothing about a benchmark comparison would raise a question. Against its own history it has lost more than half its advantage, and something specific caused that.
The same logic runs the other way. A practice sitting at forty days in a market averaging thirty looks poor on every report and may be entirely stable. Nothing is changing, so nothing needs urgent attention, even though the number is uncomfortable.
Benchmarks describe position. Drift describes change. Position is a strategy conversation. Change is a this-week conversation.
Why change is the more useful signal
Because change has a cause, and the cause is usually recent, specific, and still fixable.
A payer that starts adjudicating slower did something. A documentation lag that doubled has a reason. A denial reason appearing four times more often than usual traces to an edit somebody changed.
Each of those is findable while the trail is warm. Three months later the same investigation is archaeology, and the volume of affected claims has multiplied.
What to watch it on
Not everything. Four or five figures, chosen because a change in them means something specific has happened.
Days from service to payment. The whole conversion distance. Moves before anything else and moves for reasons that are always findable.
Adjudication time per payer. Per payer, not blended. A single insurer slowing from twelve days to thirty barely moves a blended average while it moves your bank balance, which is why the average is the wrong instrument.
Charge lag. Days between the visit and the charge posting. A rise means something changed in documentation or charge capture, and it will show up in cash three weeks later.
Denial rate by reason. The total is noise. A single reason code appearing at four times its usual rate is a payer edit change and it is worth knowing this week.
Patient collection at time of service. Falls quietly when front desk routine slips, and predicts the size of your outstanding balances better than any downstream figure.
Setting a rule you can actually run
Three decisions and none of them needs to be sophisticated.
What is normal. A rolling average over enough weeks to smooth ordinary variation. Long enough to be stable, short enough to still be current.
How far is far enough. Percentage change or standard deviations both work. What matters is picking one and writing it down, because an undefined threshold means the alert fires when somebody feels concerned.
How long before it counts. One day outside range is noise. Three consecutive days, or two weeks running, is a signal. Without this you get alerts constantly and stop reading them, which is worse than having none.
That last point is the one that kills most attempts. An alert that fires often gets ignored, and an ignored alert is indistinguishable from an absent one.
Where this comes from
Manufacturing worked this out decades ago and gave it a name.
A production line does not judge each part against an industry standard. It plots measurements against the line’s own recent behaviour and reacts when the pattern changes, because a process that was producing acceptable parts and starts producing slightly different acceptable parts is telling you something before it starts producing rejects.
The insight that transfers is this. A value inside acceptable limits can still be a problem if it arrived there by moving. The movement is the information, and waiting for the number to become unacceptable means waiting until the cost has already been paid.
A practice at fourteen days is inside every acceptable limit. It was at nine.
Why a monthly review does not do this
A monthly review looks at a value. Drift detection looks at a trajectory, and the two find different things.
A number moving steadily in one direction reads as normal in any single month, because the change between one month and the next is small. It only looks alarming across five or six months, by which point five or six months of claims have been affected.
This is why practices are so often surprised by a figure that has been moving for a quarter. Nobody was hiding it. Every individual month looked fine.
What this means for you
Take one metric. Days from service to payment is the best starting point because everything else feeds it.
Plot it weekly for the last twelve months rather than reading it as a monthly figure. If the line is flat, you have stability and that is worth knowing. If it has been climbing since March, you have found something, and the cause will be datable.
Grab 30 minutes with us. Prep nothing. You will see whether your numbers have been moving and since when.
Questions people ask
What is drift detection?
Watching a metric against its own recent history rather than an external benchmark, so a change surfaces as a signal rather than becoming a bad quarter. The comparison is you against you.
Why are benchmarks not enough?
Because they describe position rather than change. A practice converting in nine days that drifts to fourteen still looks excellent against a market average of thirty, while having lost more than half its advantage for a specific and recent reason.
Which metrics should a practice watch for drift?
Days from service to payment, adjudication time per payer, charge lag, denial rate by reason, and patient collection at time of service. Five figures where a change means something specific happened.
How do I set a drift threshold?
Define what normal is with a rolling average, decide how far outside it counts, and require the condition to persist before it fires. Without that last part you get constant alerts, and an ignored alert is the same as no alert.
Why does a monthly review miss drift?
Because it looks at a value and drift is a trajectory. A number moving steadily reads as normal in any single month, since the change from one month to the next is small. It only looks alarming across five or six, by which point the cost is paid.