The denial was not a coding miss. It was not a payer mistake. It started in the OR, when staff under time pressure grabbed an implant that was closer at hand than the one the authorization covered.

That is the uncomfortable lesson in Sergio Quiej's story. He traced a cluster of surgical authorization denials past the dashboard into the procedure room, and found a root cause no back-end report could see: size variance created in real time at the point of care. Within three months, a live handoff process cut that denial category in half - and gave the surgery department a credible case for one and a half full-time employee (FTE) of added support.

For RCM leaders in systems with high surgical volume, this is worth sitting with. If the root cause lives in the procedure room, retrospective classification only speeds up the paperwork on losses that were never preventable from a desk. By the time the denial reaches the back-end team, the organization is already working from a weaker position. The question is whether the denial program has any mechanism to reach the point where the variance is actually being created, and if not, what that gap is costing.

Where the Denial Actually Originated

Quiej, Patient Financial Services Support Manager at Adventist Health, started the way most denial work starts: with the data. He looked at a bulk of authorization denials, then pushed past the summary into individual claims and charges. Was it an implant? A supply? What specifically was denying, and why?

The pattern pointed to implants. The payer wasn't denying on utilization. It was denying on size. The authorization specified certain measurements - square centimeters, in his example. The item used in the OR was a different size. In the claims he traced, the mismatch between the authorized size and the item used was a key driver of the denials.

The dashboard could tell him what but it could not tell him why. So he asked for time in the surgery room. As he told it, that was a hurdle in itself, and it happened because his leader had his back.

“We have to look beyond the metrics. We have to look beyond the metrics.” said Quiej.

What he found in the OR was not ignorance or carelessness. Staff were working against the clock. In his words: "Well, we don't have much time. So they're under time constraint. And when we go, it's just grab and go." When a supply was closer at hand than the one on the preference card, they grabbed it. It wasn't a knowledge gap about whether two-by-four versus four-by-four made a difference. It was proximity and turnaround.

That is the actual root cause of the denial category. It is also invisible to any tool that only looks at claims after they have been coded and submitted.

The Access Problem Nobody Talks About

Getting to that observation was not automatic. Clinical-origin denial work often requires access and buy-in that back-office teams do not have by default.

Quiej spent a full week in surgery across different scenarios. As he put it, "It could be ortho, it could be a general surgery," before he tried to diagnose anything specific. He told the team he was there to observe and take notes, and made a point of communicating that it wasn't an audit. By day two or three, his presence had normalized. When he finally asked what triggered a particular item selection, the answer came without defensiveness: not enough time.



“There’s so much value in observing without saying a word,” said Quiej. “You can learn so much from observing.”

The operator principle here is not "spend a week in the OR." It is that clinical-origin denial diagnosis requires trust, unhurried access, and a non-audit framing. Honest workflow information tends to surface only when the person asking is positioned as a collaborator. Whoever conducts this work - internal staff, a partner, a cross-functional improvement team - has to be positioned that way, or the observations will not be reliable.

The Fix Was Live, Not Retrospective

Once Quiej had the mechanism, the fix did not require an IT build. It required a real-time handoff.

The circulating nurse sends the item number during the procedure. On the other end, a designated staff member begins root-cause work and payer outreach immediately - before coding is complete, not after the denial arrives. As Quiej put it: "not after or after the coding, it's already missed, but live, let's make it happen live."

The result: denials in that category were cut in half in three months.

That is the point most denial programs never reach. Back-end appeals analytics classify what already went wrong. A live variance capture workflow intervenes before the claim is even built. The capability the organization needs is the ability to catch authorization variance at the point of care and act on it while there is still time to talk to the payer. Whether that is a nurse texting an item number, an EHR-based signal, or a partner-supported workflow is a downstream choice. The requirement is the same: something has to close the loop in near-real time.

Funding Clinical FTEs From Preserved Net Revenue

The second unusual move: Quiej used the denial work to justify a staffing addition inside the surgery department, not inside revenue cycle.

During his week of observation, he asked staff a plain question: "if you had a wish for Christmas in July, what would you want?" The answer was unanimous. They wanted enough coverage that people could step away for a drink or a snack. In Sergio's recounting: "We would actually, if we had one extra person helping, it would allow us to go get a drink, to go get a snack."

That is not a metric anyone tracks. It is also directly connected to the denial pattern, because the same time pressure driving the item mismatch was the pressure eliminating breaks.

The project created a one and a half FTE role within six months. A transition person freeing staff from one room to another. Sergio framed the business case in a way that pre-empted the CFO's reflex. In his framing, when the approver's first reaction is "we don't have the budget," you reverse-engineer the answer: acknowledge the budget is set, then show implemented process changes already reducing losses, and connect the resulting net revenue improvement to the ask.

“Every dollar that we write off, it’s every opportunity that we cannot serve our community,” Quiej said.

The approver wasn't being asked to bet on a projection. They were being shown a documented recovery already in motion, tied to a specific operational ask.

This is the operator move worth borrowing. Denial analytics is not just a cash recovery tool. It is a funding argument for the staffing and workflow changes that prevent the next round of write-offs. The mechanic works whether the analysis is done in-house or through a partner. What matters is that preserved revenue is translated into a specific, defensible request.

The Metrics This Should Change

Denial rate, appeal overturn rate, and days to appeal are necessary and insufficient.

If the Adventist Health example generalizes at all, an additional question belongs in the operating review for any high-surgical-volume service line:

• What percentage of authorization denials trace to clinical-origin variance - size mismatches, preference card deviations, proximity-driven selection under time pressure - rather than payer policy or eligibility failure, and what mechanism is capturing that variance before the claim is submitted?

Retrospective classification alone cannot answer that. That does not make classification wrong. It means the coverage is incomplete, and the incomplete part is often where the largest preventable losses sit.

Most teams will say they do not have OR access or spare staff time to do what Sergio did. That's real. It also required his leader's air cover to get through the door at all. The work still has to happen somewhere. The underlying capability - point-of-care variance capture, cross-functional observation, live handoff to payer follow-up - has to exist somewhere in the operating model. Whether it is built internally, supported by a partner, or a mix depends on the system's size, service line mix, and current maturity. What does not work is assuming the back-end appeals queue will catch it.

What Changes Monday

Quiej's story is not a template. Adventist Health had a specific denial pattern, a specific service line, and a leader willing to give him time in surgery. Copying his exact org chart is not the takeaway.

The transferable moves are narrower.

Pick one recurring authorization denial category with meaningful dollars behind it. Trace it from the summary bucket to the actual denied charges. If the pattern points to a clinical decision - implant sizing, supply substitution, preference card divergence - do not solve it from the desk. Get eyes on the workflow, and get them there as a partner, not an auditor.

When the root cause turns out to be time pressure or supply proximity, design the intervention live. A circulating nurse sending an item number mid-procedure is not sophisticated technology. It is a workflow choice that works because it exists now, while the payer conversation is still possible.

Then use the recovery math to fund what the front line actually needs. Quiej turned a denial project into a floater role inside surgery. That crossed a silo most RCM leaders never cross, and it worked because he framed the request against implemented improvements, not projected ones.

The change is simpler to state than to execute. Denial management stops being a back-office function and becomes a cross-functional discipline with point-of-care reach. The denial in Sergio's story was never a coding problem. It was a supply proximity problem the authorization was never written for. Every denial program should at least know whether it can see that - and if it can't, what to do about it.