Patient Access Has the Highest Turnover and the Least Documentation

There is a binder at the registration desk with tabs for the major payers. Behind one of the tabs is a printout of an email. The email is from someone in the billing office and it explains an exception — for this plan, this service, this circumstance, do it differently. It is signed with a first name and no date.

That email is load-bearing. Registration staff rely on it several times a week. Nobody in the organization above the level of that desk knows it exists.

Patient access is, by a wide margin, the place I would start a knowledge program in a health system, and it is almost never where anyone starts. It is worth understanding why both of those things are true.

The worst possible combination

Take the two variables that determine how badly an organization needs written knowledge: how complicated the rules are, and how fast the people holding them turn over.

Registration and scheduling score at the extreme of both.

The rules are genuinely hard. Coverage varies by plan, by product within a plan, by service line, by site of care, and by whether this is the same episode as something three weeks ago. Authorization requirements change without notice and are communicated through payer portals that nobody monitors as a job. There are hundreds of these distinctions and they interact, and the person applying them is doing so in front of a patient who is standing there.

And the turnover is high. These roles sit near the bottom of the wage band, they are stressful, they are frequently the entry point into the organization, and the good people are promoted out of them quickly — which is a success from a career standpoint and a continuous knowledge drain from an operational one.

High complexity plus high churn is the profile where oral transmission fails hardest. A twenty-year veteran on a nursing unit can carry an enormous amount of undocumented knowledge and it stays put. A registrar with fourteen months of tenure carries it out the door, having taught a fraction of it to the person who started last month.

Why it gets skipped

Given that, why does nobody start here?

Partly because the visible problems are downstream. What leadership sees is a denial rate, and denials are managed by the revenue cycle team, who are analysts with reports. The team that manages the number is not the team that generates it, and the intervention that would help most is happening in a different building at a different pay grade.

Partly because it does not feel clinical. Knowledge programs in health systems get sponsored by nursing or informatics and scoped to clinical operations, because that is where the perceived risk is. Registration is administrative and administrative is where budget is not.

And partly because these teams are not good at asking. A department with high turnover and heavy production metrics does not generate confident internal advocates. They cope. They build binders. They print emails.

The economics are unusually clean

I am wary of overclaiming here, so let me be careful about what I am and am not saying.

I am not saying that documenting payer rules eliminates denials. Most denials have causes that no amount of front-desk knowledge would prevent — clinical documentation, medical necessity, payer behaviour that is adversarial by design. Anyone selling you a straight line from a knowledge base to a denial rate is selling you something.

What I will say is that a real fraction of denials trace back to a decision made at registration by a person who had thirty seconds and no reference. That fraction is knowable, because your denial data is already coded by reason, and the reasons that resolve to eligibility, authorization, and registration data quality are visible in it. You do not have to guess. You can go and read the number this week.

And where a denial traces to a lookup that did not happen, the intervention is cheap. It does not require a system, a project, or a vendor. It requires the answer to be findable in the vocabulary the registrar would use, in less time than it takes to ask the supervisor, who is on another call.

That is a narrow, testable claim, and it is the one worth building a business case on. Not hours saved. A specific denial reason code, a specific decision point, and whether the answer was reachable at that moment.

What to do first

Sit behind the desk for two hours. Not a formal observation with a form — just sit there and count.

Count how many times the registrar asks somebody else something. Count how many times they open the binder, and how long it takes them to find the tab. Count how many times they make a decision without checking anything, and note which ones those were, because the unchecked decisions are the interesting ones. Nobody guesses about the things they know are risky; they guess about the things they do not know are risky.

Then ask to see the personal notes. There will be personal notes — a document on the desktop, a note in a phone, a card taped under the monitor lip. Read them the way you would read a defect report, because that is what they are.

The retrieval piece is where a tool earns its keep and it is what Solution Compass is built to do — take the question in the words the person actually uses, at the moment of the decision, and return the current answer with the source attached rather than the printed email from someone whose last name nobody remembers. But the two hours behind the desk come first, and they will tell you more about your revenue cycle than the denial dashboard will.

Ask the registrar what they wish they could look up. Nobody has asked them, and they will have an answer ready.