Most practices have a prior authorization policy written down somewhere. Fewer have the thing the person booking an appointment can read in the time a patient will hold on the phone.
A policy and a lookup answer different questions
A prior authorization policy exists to establish that the practice has a process. It gets written for an auditor, or for a manager assembling something an auditor might one day ask for, and it reads that way: scope, roles, escalation, review date.
It is not the document anyone opens at ten forty on a Tuesday with a patient on hold. The question then is narrow. This service, this plan, this patient: does something have to happen before the visit, and whose job is it. Somebody who has to read three paragraphs to find out will stop reading and book the appointment, which is a sensible decision in the moment and the beginning of a denial nobody sees for six weeks.
What the working version holds
The version that gets used is a table short enough to scan. Down one side, the services the practice orders often enough for the answer to matter. Across the top, the plans it actually sees. In each cell the shortest true answer, which is required, not required, or the one nobody enjoys writing down, that the payer has not been consistent about it.
The rest is the context that makes a cell usable rather than merely accurate. A cell reading required still leaves open who obtains it and roughly how long that has been taking lately, which matters because a two day turnaround and a three week one lead to different scheduling decisions. The other thing that ends up on the page is what the payer has been asking for in support, and whether anything can be done after the fact, since that separates an expensive error from an annoying one.
Payer name is the wrong level of detail
The most common way one of these quietly fails is being organized by payer. A single insurer's commercial plans, its Medicare Advantage product and its Medicaid managed care line can carry different requirements for the same service, and the card a patient reads out over the phone shows the payer name in large type and the product line in small type, when it shows it at all.
Around here that is worse than a single-state practice would expect, since patients cross in from Northern Kentucky and Southeast Indiana and the same insurer's plan in one state is not the plan in another. A table built at the payer level does not produce uncertainty. It produces a confident answer that is wrong, which is harder to catch.
It only works if it goes stale slowly
Requirements change, and they change quietly. A notice arrives in a portal or a bulletin or a fax, it lands wherever payer correspondence lands, which is almost always billing, and it concerns a decision scheduling will be making next week. The distance between where that news arrives and where it is needed is most of what turns a rule change into a denial.
Closing it is not really a document problem. It is a named route from wherever notices land to whoever keeps the table, plus a date on the table saying when it was last touched. An undated reference gets trusted exactly as much as a dated one and has done less to earn it.
Whoever works denials is already holding most of it
The material for a first version is usually in the building. The person working authorization denials has watched which payers deny, for which services, and how the rule was worded when they appealed it. That knowledge tends to sit as experience rather than as anything written, which is fine until they are out for a week.
Starting there also settles the scope, and scope is where these stall. A matrix that begins with every service and every plan is a project that dies in its second week. One that begins with what has actually been denied in the past year is short and uneven and covers most of the exposure.
What it does not tell you
A matrix reports whether an authorization is required. It says nothing about whether this one will be approved, how long this particular request will sit, or whether the documentation supports it. Those stay individual work, and reading the table as a prediction is how a schedule ends up built on an approval that has not happened yet.
It does not remove the phone call either. What changes is which calls get made: fewer that open by asking whether something is needed, more that open from knowing it is. That is a modest return for the upkeep the table takes. Where it lasts, it is treated as a page somebody owns rather than as an initiative, and where it stops being current, usually nobody was named.
About the author. Marina Davar has managed a private medical practice of about fifty people since 2020. She writes here about how the operational side of an independent practice fits together. More about Marina Davar, or her work in healthcare education.