SNF Prior Authorization Tracking: Timelines, Scope and Recovery

Record the request as a sequence

A resident can have one episode, several authorization requests and many uploaded documents. Use one identifier for the episode and another for each request. Link supplements to the request they support. Otherwise an extra upload can inflate the request count, while an overwritten end date can make an undecided extension look approved.

The core record contains the requested services/dates, payer/product, transmission attempts, confirmed receipt, actual responses, decided scope and next action. Save the original response alongside any internal category.

Apply a scoped timing rule

The CMS improving prior authorization FAQ sets out the MA non-drug request timeframes used in the example below: at most 72 hours for expedited requests and 7 calendar days for standard requests, with decisions required sooner when the person's medical condition requires. Check the applicable MA conditions and any permitted extension. The FAQ expressly excludes Qualified Health Plan issuers on the Federally-facilitated Exchanges from these timing provisions; do not apply them to every payer or request type.

The clock starts at payer receipt. A coverage-requirements check alone does not start it. Additional documentation not disclosed at original submission does not stop or restart the clock under the FAQ; permitted extensions are a separate question.

Walk a weekend example to completion

This original fictional timeline assumes an applicable MA expedited non-drug request, appropriate urgency classification, no extension and no earlier medical-condition-based deadline. All timestamps use the same stated local time zone. It illustrates administration, not a clinical urgency decision.

The timing arithmetic is Friday 3 p.m. + 72 hours = Monday 3 p.m. The local failed attempt at 1 p.m. is not the receipt event. A different earlier deadline required by medical condition would still matter; the maximum is not permission to wait.

If no receipt is confirmed, the first task is to establish request delivery. If the applicable deadline has passed with no decision, preserve the evidence and route the case through the facility's qualified escalation process. Do not change urgency or invent a receipt time to improve the dashboard.

Compare the response with the request

Assume request R1 asks for November 6–12, while the fictional decision grants November 6–10. The record must show both. Requested dates 11–12 have not become approved by association with the same authorization number.

Create any later continued-stay request as R2, linked to the episode. R1 remains decided; R2 can be pending. If a response for R1 arrives after R2 is created, attach it by identity, not arrival order. A request for information is not automatically a denial, and a denial's specific reason should remain visible even if the local routing category is broader.

The covering role needs access to the source documents and authority to obtain the missing material. Two notification emails do not prove that someone accepted the work. Test the actual backup permissions before a weekend handoff.

Calculate the queue without flattering it

In a fictional cohort of 10 requests, 6 are approved, 2 denied and 2 pending. Approval among all requests is 6/10 = 60%; approval among decided requests is 6/8 = 75%. Publish the denominator and pending count. Neither percentage alone describes the unresolved workload.

If a denial later changes after appeal, preserve the first result and later outcome. Do not relabel the first decision. These are original internal measurement examples, not claims that the facility reproduces a payer's required public metric.

An API must preserve the same evidence

The CMS interoperability and prior authorization final-rule fact sheet separates operational requirements from API implementation dates. Neither proves a proposed vendor supports the facility's actual connection. Record exact payer/product, workflow step and deployment status: live, pilot or planned.

A simulated response can demonstrate how software handles approved scope, denial or additional information. It cannot prove a live payer connection. Test an outage and a channel change: the fallback should preserve the same request identity and receipt history. If only requirements discovery is available, record submission and receipt as remaining staff work rather than calling the whole process automated.