Prior Authorization Code Lists: What 278 Payers Actually Publish

In brief: In September 2026 we collected every public prior authorization list we could find from 278 US payers, 3,144 files in all. Of those, 2,359 are PDFs. Only 48 of the 254 payers we assessed publish a list that a system can read without a person in the middle. For four payers in five, the answer to "does this code need prior auth" is already public and still unusable.

What we did

We collected the public prior authorization material published by 278 US payers in September 2026: national carriers, Blues plans, Medicaid managed care organisations, state Medicaid fee-for-service programmes and the delegated review vendors they use. We downloaded every prior authorization list, policy and code grid each payer posts on its own provider site, extracted the text, and wrote an assessment for 254 of them. Then we counted what format each list came in and what was actually inside it.

Every number below is a count of public documents we collected on 15 September 2026. It is not a count of members, claims or plans.

The answer is public. The file is not.

Almost every payer answers the question. Virtually none of them answers it in a form software can use. Across the 278 payer folders, 230 carry at least one prior authorization list document, and the 3,144 list files break down like this.

We arrived at 3,144 by counting the original documents in each payer's prior authorization folder and excluding the plain-text extracts we generate for searching.

Three quarters of everything a payer publishes about which codes need review is a PDF. A PDF is a picture of a table. To use it, someone has to read it, or a parser has to guess at the column boundaries and be re-tuned every time the payer changes the template. Neither is a foundation for an automated check.

Only 48 of 254 payers publish a file a system can open

Of the 254 payers we assessed, 48 publish at least one downloadable prior authorization list in Excel, JSON or CSV. The other 206 publish PDFs, HTML pages or a lookup tool behind a provider login. That is the whole finding: the data exists, the distribution is broken.

The best lists are much richer than people expect.

San Francisco Health Plan's file is the clearest example of how far ahead a good list is. It does not just say which codes need review. It says which codes need review for which of its three benefit plans, and whether the answer changes in or out of network. A clinic checking a Medi-Cal member and a D-SNP member gets two different answers from the same file, without a phone call.

A handful of payers go further and publish the documentation requirement alongside the code. HCSC's Texas STAR and CHIP grid carries a column naming the records needed for each code, for example a pre-operative evaluation, a history and physical including functional impairment, and an operative report. That is the single most valuable column on any list we collected, and almost nobody publishes it.

Everyone else publishes a PDF grid, or a login

The 206 payers without a readable file are not hiding the answer. They are publishing it in a shape that costs someone an hour. The patterns repeat.

• A service-category list with no codes. Health Alliance Plan's public list is a two-page PDF naming 30 service categories. The code-level list sits behind the provider login. CareSource's 2026 lists are written for members: inpatient, out of network, transplants, some elective surgeries. Useful to a patient, useless to a billing system.
• A login-gated lookup tool. L.A. Care's code lookup sits behind an access-manager login and cannot be downloaded. Blue Cross of Idaho points its administrative policies at a procedure-code lookup tool that also needs a login, so no static code list exists at all. Blue Cross and Blue Shield of Louisiana publishes no code-level commercial list; codes are checked one at a time in its portal. CareFirst is the same pattern with PDF quick-reference guides on top.
• A file that promises a spreadsheet and serves a picture. UPMC Health Plan publishes a single cross-line-of-business code list. The link is labelled as a spreadsheet, but what comes back is a 36-page PDF rendition of it, with the columns intact and the data locked in.
• A per-code web tool instead of a bulk file. Most Centene marketplace and Medicaid state sites answer one code at a time through a "pre-auth needed?" tool with no bulk export. Elevance's legacy Medicaid sites in nine states publish prose plus a lookup tool and no downloadable list. The information is free. Getting all of it takes tens of thousands of queries.

None of this is unusual or negligent. It is what happens when a list is designed for a person with a specific patient in front of them rather than for a system checking a schedule overnight.

The lists change, and almost nothing records what changed

This is where the operational cost lands. Of all the documents we collected, 52% carry an effective date and 40% carry a revision history. Among prior authorization lists specifically, only 2% carry any change history at all.

Meanwhile the lists move. Twenty-two of the payers we assessed describe their prior authorization list as reissued monthly or quarterly, which we counted by reading the list-format section of each assessment. Highmark reissues monthly. Fidelis Care publishes a new authorization grid per line of business every month. HCSC posts quarterly code grids per state and line of business, and publishes the next quarter's grid alongside the current one.

So a payer replaces a 2,000-row PDF with a new 2,000-row PDF, and the only way to learn what moved is to compare the two documents yourself. Seven of the 254 payers we assessed mention a change log in their list at all. Meridian Illinois ships one inside the workbook. Blue Cross and Blue Shield of Rhode Island posts the current and draft grids side by side, each dated by its effective window, which lets you see next month's answer before it takes effect.

For a provider organisation, the cost of the other 98% is a standing task: someone re-downloads the lists, re-reads them, and hopes they spot the change before a denial does. For a payer, the cost is a call centre answering a question the payer already published.

What a good prior authorization code list looks like

Nothing in this requires new technology or a standards project. The payers who do it well are publishing a spreadsheet with six columns.

1. The code. CPT or HCPCS, one per row, no ranges written as prose.
2. The description. So a human can sanity-check a match.
3. A yes or no flag, per plan and per state. Not a sentence, not a footnote. One row per code per plan is what makes the file answerable. San Francisco Health Plan does this and its file is large for exactly that reason.
4. The reviewing vendor or programme. Who actually decides, so the request goes to the right place first time. Highmark's UM programme column and Meridian's reviewer column both do this.
5. The effective date. The date the row started applying, so two versions of the file can be compared automatically.
6. The governing policy. The policy number and, ideally, a link, so the clinical criteria behind the yes are one click away.

Add a seventh column naming the documentation required for approval, as HCSC does for Texas Medicaid, and the list stops being a gate and starts being instructions.

What this means for you

For payers

You are already publishing the answer. Publishing it as a CSV or JSON file next to the PDF costs a report export, not a programme. It reduces inbound calls about requirements, it removes a class of avoidable denials and appeals, and it is the same content your Prior Authorization API will have to expose under CMS-0057-F. If you are scoping that work, the list is the cheapest part to get right and the easiest to ship early. Our CMS-0057-F readiness scoping guide covers where it sits in the wider programme.

For providers and RCM teams

Your payer mix decides how much of this you can automate, and it is the first thing a revenue cycle team should check. If a meaningful share of your volume sits with the 48 payers publishing a readable file, you can load those lists and check requirements before the visit rather than after the denial. For the rest, the honest answer today is a person and a PDF. Knowing which payers fall in which bucket is a one-afternoon exercise and it tells you where automation will actually pay. The true cost of prior authorization gives the industry benchmarks to size it against.

For vendors building tools

Any product that promises to tell a clinic whether a code needs review is mostly a document pipeline, not a rules engine. Budget for PDF parsing, for scraping HTML pages whose markup changes, for per-code lookup tools with no bulk export, and for version diffing across monthly reissues. Coverage of the readable 48 is a weekend. Coverage of the other 206 is the product. Treat the list as the first layer of your interoperability work, not an afterthought bolted on beneath the FHIR surface, because the workflow engine behind a prior-auth API is only as good as the requirement data feeding it.

How to check your own position

1. Take your top 20 payers by volume and find the list. Not the lookup tool, the file. Note the format, the URL and whether it needs a login. Twenty tabs, one afternoon.
2. Check whether each file has a date on it. If it does not, you cannot tell whether the copy you are using is current, and that is a denial waiting to happen.
3. Download this month's copy and last month's copy of two payers and compare them. The number of rows that moved without an announcement is usually the thing that changes the conversation internally.
4. Count your denials that trace back to a missed requirement. Split them by payer, then check that split against which of those payers publish a readable file. The overlap is your automation shortlist.
5. Ask the payers who do not publish one. Provider relations can usually supply a flat export even where the website has none. The ask is small and specific: the same list you already publish, as a CSV, with an effective date column.

Limitations

These counts are a snapshot taken on 15 September 2026 and payers change what they publish. We collected public documents only, so anything behind a provider login, in a portal or supplied by contract is out of scope by definition, and a payer marked here as publishing no readable file may well supply one on request. Counts are of documents and payer folders, not of members, claims or plans, so a large national carrier and a single-county Medicaid plan count the same. We assessed 254 of the 278 payer folders in writing; the rest hold collected documents without a full assessment. And "machine-readable" here means a file that opens as data, not a file whose contents are necessarily clean, complete or consistent with the payer's own portal.

If you are building prior authorization checks against payer requirement data, or preparing the Prior Authorization API that CMS-0057-F requires, we do this work every day. Explore our healthcare product engineering services for the ingestion and versioning pipeline behind a payer rules layer, and our healthcare AI solutions for extracting structured requirements from the documents that will stay PDFs for years yet. Talk to our team about your payer mix.

More from this research series

All four posts draw on the same September 2026 review of public payer policy documents.

• Which payers publish their prior authorization criteria
• InterQual or MCG: which payers use which
• Who decides your prior authorization: the review vendors