Assembling the Supporting Packet for a Prior-Auth Letter

A prior-auth letter is a short piece of writing surrounded by a large amount of retrieval. The clinician’s part is a paragraph. Around it sits the authorization record, the referral, the relevant prior notes, the imaging or study reports the payer named, the problem list entries that establish history, and a cover page addressed to whichever fax number that plan is using this quarter. Most of the elapsed time on an authorization submission is spent gathering, not writing.

That gathering is done by the most experienced person in the department, because knowing which documents a given plan wants for a given request is knowledge that lives in someone’s head. It is also the reason the work does not scale. A practice can add authorization volume faster than it can grow people who know which attachments matter.

The clock is not sympathetic. Under the federal interoperability and prior authorization rule, impacted payers must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests. Faster payer turnaround only helps a practice that can put a complete packet in front of them; an incomplete submission restarts the clock rather than beating it.

The packet is a retrieval problem with a deadline

Split an authorization submission into its parts and the automatable share is large.

There is the authorization record itself, which carries the request, the plan, the requested service, and the current status. There are the supporting documents already filed in the chart. There is the problem list, which establishes the history the payer is checking against. And there is the cover sheet, which is practice reference data plus a destination.

Every one of those is a lookup. None requires reading a document and deciding what it means.

What is left after the automation runs is the necessity statement, and that is written by the clinician who is requesting the service. It is not generated, not drafted, and not assembled from prior letters. The packet arrives at the clinician complete except for that paragraph, which is a very different ask than arriving as an empty request for documentation.

Per-plan requirements belong in configuration, not in a person

Which documents a plan wants is stable enough to write down and volatile enough that nobody does.

The workable artifact is a per-plan, per-service checklist held as configuration. When a request is created, the automation resolves the checklist, gathers what it can, and produces a gap list of what is missing. That gap list is the actual product for the coordinator, because it converts a research task into a retrieval task.

Building the checklist is not a big-bang exercise. Start with the plans and services that produce the most volume, capture the requirements as they are learned from denials, and let the list grow. A checklist covering the top handful of plans removes most of the guesswork.

The part that must not be automated is deciding that a missing item is not needed. When the checklist says a document is required and it does not exist, that is a decision for a person, not a default.

Scheduling and authorization have to stay attached

The packet is only half the story. The other half is timing, and it is where practices lose claims they thought were safe.

Procedures scheduled outside the prior-auth window by human schedulers are a routine source of write-offs. The visit happens, the work is done, and the claim dies later. Nothing in the scheduling flow knows about the authorization window, so nothing prevents it.

Rescheduling makes it worse. Moving an appointment silently breaks the link to the existing authorization, and an appointment whose authorization has not returned can only be pushed later, never pulled earlier.

So the packet workflow has to publish back to scheduling rather than ending at submission. Authorization status, the window, and the linkage to the booked appointment all have to be visible where the person moving the appointment is standing. This is the one place where forms work and schedule work are the same workflow, and treating them separately is what produces the write-off.

Tracking to a decision, not to a submission

Most authorization tracking stops at sent, which is the least useful place to stop.

A submitted packet has three possible futures. It gets approved, it gets denied with a reason, or it goes quiet. The third is the most common and the least handled, because nothing generates a task when nothing happens.

Aging is the fix and it is unglamorous. Every submitted request carries a follow-up date derived from the plan’s own stated timeframe. When that date passes without a decision, the item surfaces. The status call to the plan is the most delegable task in the department and the one most often done by the person who should be building the checklist instead.

Denials deserve their own path. Beginning in 2026 the same federal rule requires impacted payers to provide a specific reason for a denied prior authorization, which makes denial reasons a structured input rather than a phone call. A practice that captures reason codes over a quarter can see which requirement it keeps missing, and fix it upstream in the checklist.

Where the clinician owns it

The line here is narrow and absolute, and it is worth restating because authorization work sits closer to clinical content than most front-office automation.

The automation retrieves documents, matches them against a checklist, assembles them in the order the plan wants, produces a cover page, submits, tracks, and escalates. It does not read the clinical content of a retrieved document and decide whether it supports the request. It does not summarize a note. It does not draft the necessity statement, propose language for it, or reuse language from a prior letter.

When a packet is ambiguous, the useful output is a prepared question rather than an answer: this request, this plan, this checklist, these documents found, these missing, this deadline.

That is a coordinator’s job description with the tedium removed, and it is the version that survives a compliance review.

Key Takeaways

Treat the packet as retrieval and the necessity statement as writing. The automation should hand a clinician a complete packet with one paragraph missing.
Hold per-plan, per-service document requirements as configuration and produce a gap list. Requirements living in one experienced person’s head is the reason authorization work does not scale.
Never let the automation decide a missing required document is unnecessary. That is a human decision, not a default.
Publish authorization status and window back into scheduling. Appointments booked outside the window and reschedules that break the auth link are how approved work turns into a write-off.
Age every submission against the plan’s own stated timeframe rather than closing the item at sent. Silence is the most common outcome and the least handled.
Capture denial reason codes over a quarter and fix the checklist upstream instead of appealing the same gap repeatedly.

Authorization teams are usually not short on skill, they are short on hours, and the hours go to retrieval rather than judgment. Automating the gathering, the assembly, the sending, and the chasing leaves the department doing the part that actually needed people: deciding what a payer really wants, and writing the paragraph only a clinician can write.

Sources