How to Track Prior Authorization Changes

Track prior authorization changes by keeping one dated record per request and preserving a history of every status update. Record the payer and plan, requested service, submission details, information requests, decision and reason, approved scope, expiration condition, and next action. Reconcile the record against payer notices and portal updates.

This is a practical workflow, not a CMS-prescribed log template. CMS requires responses through the Prior Authorization API to approve and state when authorization ends, deny with a specific reason, or request more information. CMS’s Prior Authorization API FAQ describes those response outcomes.

1. Create one record for each request

Use a spreadsheet, an existing authorization workflow, or a system your organization can maintain securely. Give every request a stable internal case identifier. Follow your organization’s privacy and access controls; avoid putting unnecessary patient details into shared or unsecured documents.

Field	What to record
Case identifier	Internal ID or another identifier handled under your privacy controls.
Payer and plan	Payer, plan name, and relevant line of business when known.
Benefit	Medical or pharmacy; note that CMS-0057-F generally excludes drug prior authorizations from its API and process requirements.
Requested service	Procedure, item, service, or medication; include ordering clinician and destination provider when useful.
Authorization requirement	Whether authorization is required and where that determination was checked, such as a payer policy or portal.
Submission	Date and time, channel (portal, API, fax, phone, or other), confirmation or reference number, and submitted materials location.
Status history	Each status, timestamp, source of the update, and the person who recorded it.
Information requests	What the payer requested, when it was received, who owns the response, and when and how the response was sent.
Decision	Decision date, approved/denied/pending outcome, specific denial reason if applicable, and approved scope.
End condition	Authorization end date or the circumstance under which it ends, as stated by the payer.
Next action	Action owner, due date, escalation or appeal status, and the event that should trigger follow-up.

Keep changes as dated events instead of overwriting the previous value. A current-status column is useful for sorting, but the event history is what lets staff establish what changed and when.

2. Record the submission and establish ownership

Confirm whether authorization is required for the requested item or service and note the source and date checked.
Submit through the appropriate payer channel. Save the confirmation, reference number, and a copy or location of the submitted documentation according to your records policy.
Enter the submission timestamp and channel in the request record.
Assign a person to monitor the request and a due date for the next check. Set the follow-up based on applicable payer or program rules and local policy.
When you receive a portal update, notice, phone response, or API response, record the update timestamp and source before changing the current status.

CMS says the Prior Authorization API is intended to support checking whether authorization is required, identifying covered items and services and documentation requirements, and exchanging requests and responses. The API is an implementation path, not a substitute for a local process that assigns ownership and preserves the request history. See the CMS fact sheet and CMS general FAQ.

3. Track every status change and payer response

Use consistent statuses that distinguish a decision from a request for more information. For example:

Draft: Request is being prepared and has not been sent.
Submitted: Request sent; save confirmation or reference number.
Pending: Payer has not issued a decision.
More information requested: Record exactly what is needed, the receipt date, owner, response due date, and submission date.
Approved: Record the approved service or scope and end date or ending circumstance.
Denied: Record the payer’s specific reason and route the case for review, appeal, or other next steps under applicable policy.
Closed: Request is complete; retain the history and supporting notices under your organization’s retention policy.

These labels are workflow suggestions. They are not a CMS-required status vocabulary. CMS describes three response outcomes for the API: approval with an end date or circumstance, denial with a specific reason, or a request for additional information. Do not record an information request as a denial or treat “pending” as a decision.

For each update, preserve the previous status, new status, timestamp, source, and evidence. If a portal and a written notice disagree, record both with their dates and follow your escalation process to resolve the discrepancy.

4. Reconcile the record with payer evidence

Check open requests on a regular cadence appropriate to the applicable rules and your organization’s workflow. Compare the tracking record with payer portal entries, letters, fax notices, API responses, and phone-call notes. Record the date of the reconciliation and any mismatch. For phone calls, capture the date, contact or department if available, reference number, and summary of what was communicated.

When an approval arrives, verify that the approved scope matches the requested service and that the record includes the stated end date or circumstance. When a denial arrives, copy the specific reason from the payer response and retain the notice. When more information is requested, track the exact documents or facts requested and close the loop when they are submitted.

5. Maintain a separate log for policy and system changes

Request-level changes and broader payer or regulatory changes are different kinds of work. Keep a separate change log so an upcoming policy update does not get mistaken for the status of an individual authorization.

Change-log field	Purpose
Rule or guidance title and source	Identify the authoritative notice or implementation material.
Publication or update date	Show when the information was issued or last checked.
Payer/program affected	Identify the payer type and regulated line of business in scope.
Effective or compliance date	Track the stated timeline, including payer-specific variation.
Local impact	Document affected forms, staff procedures, interfaces, training, and system configuration.
Owner and review date	Assign responsibility for validation and implementation follow-up.

CMS released the Interoperability and Prior Authorization Final Rule, CMS-0057-F, on January 17, 2024. Operational provisions generally begin January 1, 2026, and API development or enhancement requirements generally begin January 1, 2027; exact dates vary by payer type. Check the CMS implementation page and current payer-specific materials before relying on a date.

The rule covers specified impacted payer types, including Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid managed-care plans and CHIP managed-care entities, and certain Qualified Health Plan issuers on Federally-facilitated Exchanges. It does not apply to every insurer or every authorization workflow. The APIs and process requirements generally exclude drug prior authorizations, though CMS says payers may include certain drugs covered under a medical benefit in Prior Authorization APIs. Verify applicability for the payer, program, service, and request at hand using CMS’s general FAQ.

CMS encourages implementers to consult HL7 FHIR Da Vinci implementation guides, including Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). These are technical resources for implementation, not consumer tracking apps. CMS also says applicable response timeframes are measured in calendar time and apply regardless of submission channel; check program applicability and exceptions before assigning a deadline. See the CMS process FAQ.

6. Use a simple audit and follow-up routine

At submission: Confirm the record has a timestamp, channel, reference number, owner, and next check date.
At every payer update: Append a dated event and save or reference the supporting evidence.
At an information request: Assign the response owner and due date; record what was sent and when.
At a decision: Verify the outcome, reason or approved scope, and end condition against the actual notice.
At closure: Confirm there is a complete timeline and retain it under the organization’s recordkeeping rules.
On a regular review: Look for open requests without owners, overdue next actions, conflicting evidence, and upcoming payer changes.

CMS says required prior-authorization data must be accessible for at least one year after the last status change. That is an API data-access requirement; it does not replace an organization’s own recordkeeping policy. See the CMS general FAQ.

7. Choose the tracking method that fits your workflow

A spreadsheet may suit a small team with low request volume if it has controlled access, clear ownership, and an append-only history. A payer portal is useful for payer-specific status and source documents, but staff may still need a cross-payer tracker. An EHR, practice-management system, clearinghouse, or API-connected workflow can reduce duplicate entry when it fits existing records and processes. Compare options on payer and benefit coverage, status timestamps, information requests and denial reasons, alerts and ownership, audit history, interoperability, privacy controls, and implementation cost.

CMS’s rule creates relevant API requirements for specified impacted payers, but CMS does not evaluate or endorse commercial tracking products. Confirm the tool’s actual payer coverage and workflow fit before adopting it.

8. Common tracking problems and fixes

Problem	Likely cause	Fix
The tracker says “pending” after a payer asks for documents.	The request for information was not treated as a distinct event.	Record the request date, exact information needed, owner, response deadline, and submission date; update the current status.
Staff cannot tell when status changed.	The current value was overwritten without a history.	Append each update with timestamp, source, previous and new status, and evidence reference.
An approval is unusable or unclear.	Approved scope or end condition was omitted from the record.	Check the payer notice and record approved service, scope, date or ending circumstance, and any conditions.
A denial is recorded without a reason.	The reason was paraphrased, missed, or not copied from the notice.	Capture the payer’s specific stated reason and retain the denial evidence; assign the next review or appeal action.
Portal and letter show different statuses.	Sources may have different update times or the request may have changed.	Log each source and timestamp, preserve both pieces of evidence, then use the payer’s contact or escalation route to reconcile.
A request has no recent follow-up.	No owner or next-action date was assigned.	Require an owner and next check date at submission and after every response or status change.
A CMS deadline is applied to every payer or drug request.	The rule’s scope or payer-specific dates were generalized.	Check payer type, line of business, benefit, applicable exception, and current CMS implementation guidance before applying a deadline.
Payer metrics are compared as if they were equivalent.	Reporting periods or metric definitions differ.	For each metric, record payer, definition, reporting year, and source document. CMS requires annual reporting of certain metrics, with initial reporting beginning in 2026 for the prior year; that requirement alone is not a performance benchmark. See the CMS rule page and process FAQ.

9. Or skip the browser setup

When your team needs a screenshot of a payer portal or public policy page as supporting evidence, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-shot options accept cookie or consent banners like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

Use your API key in place of YOUR_API_KEY. See the ScreenshotNeo API documentation for request parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

The same API supports full-page capture, element selection, viewport and device presets, custom CSS and JavaScript, waits, request blocking, headers, cookies, caching, PDF options, async jobs, bulk capture, and other controls. Pricing is 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000, and yearly billing gives two months free. Every feature is on every plan.

Start with 1,000 screenshots a month free, with no card required: Create a free ScreenshotNeo account.

Frequently asked questions

Does a tracker need to be an EHR or payer API?

No. The essential practice is a dated record with ownership and evidence. Choose a tool that fits your team’s volume, privacy controls, and existing systems.

Does CMS-0057-F cover every payer?

No. It applies to specified impacted payer types and regulated lines of business. Check CMS guidance and payer-specific applicability.

Are prescription drug authorizations included?

They are generally excluded from the rule’s API and process requirements. CMS notes that certain drugs covered under a medical benefit may be included in Prior Authorization APIs.

How long should the organization retain its own tracker?

Follow your organization’s recordkeeping policy and applicable requirements. CMS’s one-year minimum concerns access to required API data after the last status change and does not set the organization’s full retention policy.