The denial fax lands at 4:42 p.m. One person sends the same records again. Another starts a peer-to-peer request. A third drafts an appeal letter. None has read the reason code or deadline.
Begin a prior authorization appeal by classifying the denial. An administrative omission, coverage exclusion, medical-necessity decision, and untimely request do not share one repair path. Read the notice, identify the controlling plan instruction, then map each disputed criterion to patient-specific evidence. The packet should make that map visible.
Before anyone writes a letter
- Save the denial notice and record when it arrived.
- Capture the exact reason, requested service, identifier, deadline, and review route.
- Decide whether the response is a correction, reconsideration, peer review, or appeal.
- Name one owner and use one packet index.
Route the denial before assembling records
Use the notice, benefit documents, and payer instructions as the controlling sources. This table is a sorting aid, not a substitute for those materials.
| Denial pattern | First question | Likely evidence task |
|---|---|---|
| Missing field, identifier, or attachment | Does the plan allow a corrected request? | Supply the exact missing item and preserve submission history |
| Service does not meet stated criteria | Which criterion is disputed? | Link each criterion to a dated patient fact or explain the disagreement |
| Benefit exclusion or noncovered service | Is this a benefit issue or a clinical-necessity issue? | Use plan language and the correct coverage-review route |
| Timeliness or no prior request | What deadline and exception rule applies? | Build the event timeline with transmission evidence |
| Level, site, frequency, or unit mismatch | What exactly did the request and denial identify? | Reconcile order, note, code, units, and authorization identifier |
| Urgent clinical risk | Does the plan provide an expedited route? | Document the clinician’s patient-specific urgency and follow that route |
CMS’s consumer appeal guidance illustrates why the notice matters: it describes internal appeals and external review for certain non-grandfathered health plans, with distinct procedures and time frames (CMS). Those federal examples do not create one deadline for every request. State law, plan type, service, and contract can change the path.
Turn the denial into an evidence map
Do not begin with a broad template letter. Copy the denial reason into a working document, split it into testable criteria, and place the source beside each one.
| Denial criterion | Patient-specific source | Packet locator | Owner |
|---|---|---|---|
| Current clinical problem | Signed encounter note dated MM/DD | Tab 2, page 3 | Clinician |
| Relevant finding or test | Report dated MM/DD | Tab 3, page 1 | Records team |
| Prior treatment and response | Medication or therapy history | Tab 4 | Clinician |
| Requested service | Signed order and request | Tab 1 | Authorization staff |
| Timing or urgency | Dated clinician statement | Tab 2, page 4 | Clinician |
The map exposes three different problems. The fact may exist but be absent from the packet. The record may contradict the request. Or the fact may never have been documented. Only the first is solved by attaching another page.
Use the medical-necessity claim-to-note check before asking a clinician for more prose. The prior-authorization documentation guide helps teams collect the initial requirement set.
Make the packet navigable
A useful submission starts with a short index. Identify the patient and request using the payer’s permitted identifiers. State the denial date, reference number, requested review, and attached documents. Put the clinician’s response next to the disputed criterion instead of hiding it in a chronology.
Keep unrelated chart material out. More pages can create privacy exposure and make the relevant evidence harder to find. Check that every attachment belongs to the right patient, date, service, and clinician before transmission.
CMS publishes electronic reason statements and document codes for its esMD workflows so a submitter can understand why a transaction was rejected or what document type was received (CMS esMD). That example supports a broader operations lesson: retain the exact response code and transmission evidence. Do not translate a specific rejection into “payer denied” and discard the details.
Keep the record and argument separate
The clinical record should state what the clinician knew and decided during care. The appeal explains how that truthful record answers the denial. Do not edit the chart to make it read like a payer policy.
If a correction or addendum is warranted, follow the authorized workflow and preserve the original. The record amendment guide covers that boundary. A late entry must show its actual author and date; it cannot pretend that later reasoning was contemporaneous.
The appeal letter should also distinguish fact from argument:
- Fact: the patient completed six weeks of documented therapy on stated dates.
- Source: the signed therapy record at a named packet tab.
- Argument: that history satisfies or should be considered under the cited criterion.
- Request: the specific decision or review the practice seeks.
If the clinician disagrees with the policy, say so directly and support the position. Do not manufacture a fact that would fit it.
Know which new CMS rules apply
The CMS Interoperability and Prior Authorization Final Rule requires certain impacted payers to provide a specific reason for denied prior authorization decisions, with compliance dates that vary by provision. Its prior-authorization API and process provisions focus on medical items and services and exclude drugs of any type from that rule’s scope (CMS fact sheet).
Do not turn that into “all payers must decide every request the same way.” Confirm whether the payer and request fall within the rule, which compliance date applies, and whether another federal or state requirement governs. For Medicare hospital outpatient department services, CMS maintains a separate FAQ and operational pathway (CMS OPD FAQ).
Put software in the evidence lane
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus Patient Square EHR from the Copilot tier or an alongside path for an existing EHR, with scheduling and messaging as you move up the plan.
The scribe prepares a draft for clinician review. Public scope does not promise payer-policy interpretation, autonomous appeal writing, appeal submission, or a coverage outcome. Hospital Copilot names a Claims Management module, but public materials do not establish a specific prior-authorization appeal workflow. Treat that as a demonstration question.
Review current statements on the security page. In a demo, use a synthetic denial and ask the team to show source attribution, clinician review, attachment handling, and any handoff that remains outside Patient Square.
Close the loop on the decision
Record the submitted route, packet version, transmission time, confirmation, deadline, and owner. When the response arrives, preserve the notice and connect it to the original request. If the result is another denial, classify it again rather than reflexively resending the same packet.
The best operational metric is not letters produced. It is denials correctly routed, evidence gaps found before submission, deadlines met, and decisions returned to the clinical and scheduling teams without losing the patient in an inbox.
Compare the Practice Copilot scope with your denial workflow using a synthetic case.