Compliant on Paper but Manual in Practice: The Documents Still Running Prior Authorization

Ask most payers how close they are to CMS-0057 compliance, and the answer usually centers on transactions: CRD, DTR, PAS, all wired up and ready for January 1, 2027. That work is real, and it matters.

But ask a different question: once a request clears the automated transaction layer, what is the underlying medical policy actually built on? For a lot of organizations, the honest answer is still a spreadsheet, a PDF, or a Word document somebody updates by hand and emails around when a policy changes. That’s the part of prior authorization modernization that doesn’t show up in a compliance checklist, and it’s the part most likely to quietly undercut everything else.

The gap between automated and computable

CMS-0057 requires payers to expose CRD, DTR, and PAS through FHIR APIs, a real shift in how prior auth requests move. But moving a request through an automated pipeline isn’t the same as the policy behind that request being automated too.

Medical policy is where prior auth actually lives: the criteria, the exceptions, the effective dates, the state-by-state variation. When that policy sits in a spreadsheet or a static document, every automated transaction touching it still requires someone to interpret, transcribe, or manually reconcile it. The transaction layer meets the deadline. The policy behind it often hasn’t changed much since prior auth was entirely paper-based.

A spreadsheet can be shared and sorted. It cannot be queried by a system in real time, cannot enforce version control across states and effective dates, and cannot guarantee that the criteria a DTR call surfaces today match what a human reviewer applies next week.

Why this outlasts the compliance deadline

Some assume this problem resolves itself once the 2027 deadline passes. It won’t. Compliance deadlines force payers to expose transactions, not to rebuild how policy is maintained internally. Plenty of organizations will hit the deadline with functioning CRD, DTR, and PAS transactions and a policy library that still lives in scattered files across departments, subject matter experts, and delegated vendors.

That leaves an operational reality that persists well past the deadline: staff cross-referencing spreadsheets to confirm a policy is current, and every state or effective-date change requiring someone to manually update files by hand.

The  platform question underneath the AI question

This is also where AI conversations in prior authorization get ahead of themselves. AI tools promise faster reviews and smarter triage. But an AI model is only as reliable as the structured data it’s reasoning over. If the policy it references lives in an unstructured spreadsheet, the model is effectively guessing at intent the same way a human reviewer would, just faster.

The newest model won’t save you if the policy data underneath it is a mess. Digitizing policy with fidelity means preserving effective dates, state nuance, and edge cases instead of flattening them into a generic questionnaire, turning policy from a document into infrastructure a system can actually use.

Why this extends beyond prior authorization

Prior authorization is where this problem is most visible today, largely because CMS-0057 put a deadline on it. But it isn’t where the problem ends. Any healthcare AI application depends on the same underlying requirement: policy and clinical criteria that are structured, current, and computable.

That points to a broader shift already underway: away from point solutions, toward platforms that structure the underlying data once and apply it across multiple use cases. Itiliti Health built its own platform on that same distinction. Itiliti Health’s Policy Foundation™ structures policy and payer context into a form systems can use, while Itiliti Health’s IntelligenceOS™ applies it: handling applicability, rules, decisioning, orchestration, traceability, and interoperability across every transaction. Prior authorization is the first proven use case built on that platform. Others are expected to follow.

What this looks like in practice

None of this requires a wholesale technology overhaul on day one. It starts with an honest inventory: which policies still exist primarily as spreadsheets, PDFs, or Word documents, and how does an update actually move through the organization today? For many payers and delegated vendors, that answer surfaces gaps nobody had fully mapped out.

What matters is making sure a policy change reaches every system, reviewer, and transaction downstream. Once that’s true, compliance stops being a deadline payers scramble to meet and becomes just how the data works. The transaction layer is getting the attention right now, and it should. The policy behind it, wherever it still lives in a spreadsheet, is where prior authorization modernization will actually be won or lost.

Not sure where your policy data actually stands?

If your team is mapping out where policy still lives in unstructured, manually maintained files, contact us to talk through what that inventory could look like for your organization.