Home/White Papers/The Prior Auth Command Center

OPERATING MANUAL · EDITION 2026.2

Prior authorization is a pipeline, not an errand.

Q: What is a prior authorization command center?

A single operating surface where every open authorization request is triaged by urgency, routed to the correct payer channel, polled to determination, escalated on a defined ladder, and reconciled against the claim it eventually supports. It replaces the inbox, the spreadsheet, and the coordinator's memory with one queue and one owner.

Q: How should prior authorization intake be triaged?

By clinical urgency and by dollar exposure, not by arrival order. Expedited clinical requests run against the 72 hour payer clock, standard requests against the 7 calendar day clock, and recurring service reauthorizations against the units-remaining trigger rather than the calendar.

Q: When should an ABA reauthorization packet be started?

At 80 percent of authorized units consumed, not at a fixed number of days before expiry. A 97153 authorization consumed by RBT session hours can exhaust weeks ahead of its end date, so the units meter is the real clock and the expiry date is only the backstop.

Q: What is auth-to-claim reconciliation?

A tie-out that matches the authorization number, the approved units by code, the rendering credential, and the date span against the claim lines actually submitted and paid. Variances become root cause work before they become denials or unbilled services.

Most organizations run prior authorization as a pile of tasks distributed across whoever has time. A command center runs it as inventory with a clock on every unit: triaged at intake, routed by payer rule, polled to determination, escalated on a ladder, and reconciled against the claim it was supposed to protect.

Get my free denial and auth audit → See the automation capability

Care delay

95%

Of physicians say prior authorization delays access to necessary care, 2025 AMA survey

Weekly burden

13 hours

Physician and staff time per week on prior authorization, 2025 AMA survey

Payer clock

72h / 7d

Expedited and standard decision limits under CMS-0057-F from 2026

Cost per request

$4 to $8

Automated prior authorization versus $14 to $26 manual, CAQH Index

Module 01 · the diagnosisThe bottleneck is coordination, not clinical judgment.

Prior authorization is the only revenue cycle function that gates care before it happens and gates payment after it happens. When it fails, a patient waits and a claim denies from the same root cause. The failure is almost never a disagreement about medicine. It is a packet that sat, a portal that was the wrong portal, a status nobody polled, and an approval that expired while sessions kept running.

The 2025 AMA prior authorization physician survey, released by the American Medical Association in May 2026, puts hard numbers on the cost of that coordination failure. Ninety five percent of surveyed physicians said prior authorization delays access to necessary care. Seventy nine percent reported patients abandoning treatment because of authorization barriers. Twenty six percent said prior authorization led to a serious adverse event for a patient in their care. On the administrative side, physicians complete roughly forty prior authorization requests per week and burn about thirteen hours of physician and staff time doing it. Thirty two percent said their requests are often or always denied.

Those are not evenly distributed costs. They land on the practices with the highest authorization density: applied behavior analysis, behavioral health, advanced imaging, infusion, and specialty pharmacy. In those service lines authorization is not an exception path. It is the main path, and every unit of service has to be granted before it can be delivered and matched after it is billed.

95%

Physicians reporting prior authorization delays access to necessary care, 2025 AMA survey

Prior authorization requests completed per physician per week, 2025 AMA survey

13 hrs

Physician and staff time consumed per week by prior authorization, 2025 AMA survey

$4 to $8

Cost per automated prior authorization versus $14 to $26 manual, CAQH Index

↔ Swipe chart

Exhibit 1 · The last bar is the one that shapes the escalation ladder in Module 06. Only sixteen percent of physicians say the health plan reviewer on a peer to peer call often or always has the appropriate qualifications, which is why the ladder documents who was on the call and what they were board certified in.

Source: American Medical Association, 2025 prior authorization physician survey, released May 13, 2026. ama-assn.org press release. Cost per transaction figures are drawn from the CAQH Index and are consistent with the ranges published on our prior authorization automation capability page.

WHAT THIS MEANS If thirteen hours a week disappear into authorization work, the correct response is not more staff. It is a pipeline where the routine ninety percent never reaches a human and the exceptional ten percent reaches the right human immediately.

Module 02 · intakeTriage by urgency and exposure, never by arrival order.

The single most expensive habit in authorization operations is a first in first out queue. It treats a stat imaging order for a patient in pain and a routine reauthorization for a stable recurring service as the same object. They are not. They run on different clocks, carry different clinical risk, and fail in different ways. A command center sorts every arriving request into one of three lanes within minutes of intake, and each lane has its own service level, its own owner, and its own escalation trigger.

LANE A · EXPEDITED

Clinical urgency

A delay would seriously jeopardize life, health, or the ability to regain maximum function. Under CMS-0057-F, impacted payers must return expedited decisions within 72 hours. Your internal clock has to be tighter than the payer clock or you have no room to correct a rejected packet.

PACKET OUT: 4 business hours
FIRST POLL: 12 hours
ESCALATE: 48 hours with no determination

LANE B · STANDARD

Scheduled service

Elective imaging, procedures, infusions, and new courses of therapy. Impacted payers must return standard decisions within 7 calendar days. The practical constraint is the scheduling date, so the intake clock runs backward from the appointment rather than forward from the order.

PACKET OUT: 1 business day
POLL CADENCE: every 4 hours
ESCALATE: day 5 of 7 with no determination

LANE C · RECURRING

Units and reauthorization

Applied behavior analysis, physical and occupational therapy, dialysis, and any service authorized as a pool of units across a date span. These do not arrive as orders. They surface as meters, and the trigger is consumption, not the calendar.

TRIGGER: 80 percent of units consumed
HARD TRIGGER: 95 percent or 30 days
ESCALATE: any session without active auth

Lane C is where most organizations lose the most money and notice it the least. Lanes A and B fail loudly: someone calls, a schedule slips, a patient complains. Lane C fails silently. An authorization simply runs out of units in week nine of a twelve week span, sessions continue because the calendar says the authorization is still active, and nothing surfaces until a remittance comes back short. That is the specific failure Module 07 is built to prevent.

Triage also has a dollar dimension that sits on top of urgency. Within each lane, requests are ranked by the exposure they carry: a single infusion authorization can be worth more than forty routine requests combined. When capacity is short, the lane sets the clock and the dollar rank sets the order inside the lane.

Module 03 · the pipelineSix stages, one owner, no dark queues.

A dark queue is any place a request can sit where no clock is running and no name is attached. Faxes waiting for a callback, portal submissions with no receipt logged, a coordinator's personal follow up list: all dark queues. The pipeline below exists to make them impossible. Every request is in exactly one stage at all times, every stage has an entry condition and an exit condition, and every stage has a service level that fires an alert when it is breached.

ASP-RCM FRAMEWORK · THE SIX STAGE AUTHORIZATION PIPELINE

↔ Swipe diagram

Exhibit 2 · The two loops are where the operational skill lives. Loop A is a documentation request, which is not a denial and should never be treated as one. Loop B is a denial, which enters the escalation ladder rather than a generic appeal queue.

Intake and triage

Order or reauthorization trigger lands, lane assigned, owner assigned, clock started. Nothing waits for a morning huddle.

SLA 15 MINUTES

Packet assembly

Demographics, clinical documentation, assessments, and payer specific form fields pulled from the record. The rule library gap checks before submission.

SLA 4 HOURS

Channel routing

Correct portal, fax queue, or EDI endpoint per payer per service code. Misfiled packets add two to four days, so routing is deterministic, never remembered.

SLA SAME DAY

Status polling

Structured 276 and 277 status cycles every four business hours. Determinations post the same business day rather than whenever someone logs in.

EVERY 4 HOURS

Exception triage

Documentation requests answered within twenty four hours. Clinical revisions routed to the ordering physician with a specific question, not a form.

SLA 24 HOURS

Reconciliation

Approved units, rendering credential, and date span tied out against the claim lines actually submitted and paid. Variances become root cause work.

AT PAYMENT

Stage three deserves a word of its own. Wrong portal submission is the most under measured defect in authorization operations because it never produces an error message. The packet lands somewhere real, a human somewhere reads it, and two to four days later it is redirected or silently dropped. The only durable fix is a payer rule library that carries the active channel per payer per service code and refreshes on a schedule rather than when someone notices a change. Our AI for prior authorization capability page describes how that library is applied deterministically at the moment of submission.

THE ONE RULE No request may exit the routing stage without a logged submission receipt. That single rule eliminates the largest dark queue in most authorization operations.

Module 04 · the state modelAn authorization has nine states, and only nine.

Most authorization trackers carry a free text status field. Free text is how an organization ends up with forty seven distinct spellings of pending and no way to count anything. A command center replaces the status field with a state machine: a closed set of states, a defined set of legal transitions between them, and a timestamp on every transition. Once the model is closed, every operational question becomes a query rather than an opinion.

↔ Swipe diagram

Exhibit 3 · Two states are routinely mismodeled. Documentation requested is treated as a denial in many trackers, which inflates denial rates and sends packets into an appeal workflow they do not belong in. Partially approved is treated as approved, which is how a service gets delivered at a volume nobody authorized.

Why partially approved deserves its own state

When a payer grants sixty units against a request for ninety, a tracker that records approved has just created a future denial. The scheduling team sees an active authorization and books to the clinical plan. Thirty units of delivered service will never be paid. A distinct partially approved state forces two actions: the schedule is rebuilt to the approved volume, and a supplemental request for the difference either goes out immediately or is consciously abandoned. Either outcome is fine. The silent one is not.

The transition timestamps carry as much value as the states. The interval between submitted and pending is payer intake latency and belongs on the payer scorecard in Module 06. The interval between pending and any determination is the payer decision clock that CMS-0057-F now constrains. The interval between documentation requested and your response is entirely yours and is the fastest metric to improve.

Module 05 · the regulationCMS-0057-F turns payer behavior into a measurable clock.

The CMS Interoperability and Prior Authorization Final Rule, rule number CMS-0057-F, was published in the Federal Register on February 8, 2024 at 89 FR 8758 and took effect April 8, 2024. It does two separate things on two separate schedules. The operational provisions land in 2026 and constrain how fast payers must decide and what they must tell you. The interoperability provisions land in 2027 and change how requests travel.

Rule of record

Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes, final rule CMS-0057-F, document 2024-00895, published February 8, 2024, 89 FR 8758, effective April 8, 2024. Impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee for service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. Primary sources: federalregister.gov and the CMS fact sheet.

↔ Swipe timeline

Exhibit 4 · The 2026 provisions are already in force as of this edition. The 2027 API provisions are the ones providers can still prepare for, and preparation means having a clean state model and a clean payer rule library before the interfaces arrive.

CMS-0057-F requirements and compliance dates
Requirement	Date	What it obligates the payer to do	What it changes for your pipeline
Expedited decision limit	72 hours Jan 1 2026	Impacted payers must send expedited prior authorization decisions within 72 hours of receipt.	Lane A internal service level must be tighter than 72 hours so a rejected packet can still be corrected.
Standard decision limit	7 cal days Jan 1 2026	Impacted payers must send standard prior authorization decisions within 7 calendar days.	Lane B escalates on day 5 of 7, not on day 8. The breach is evidence, not an inconvenience.
Specific denial reason	Jan 1 2026	Payers must provide a specific reason for a denied prior authorization request.	Denial reason becomes a structured field, which makes the escalation ladder routable by reason code.
Public metrics posting	Mar 31 2026	Annual public posting of prior authorization metrics on the payer website, first covering calendar year 2025. Covers medical items and services; drugs are excluded.	Payer scorecards stop being anecdotal. Published approval, denial, appeal overturn, and decision time data becomes an input.
Prior Authorization API	Jan 1 2027	FHIR based API that conveys requirements, supports submission, and returns status and decision.	Packet assembly moves from portal keystrokes to structured payload. Rule library becomes the map to the payload.
Provider Access API	Jan 1 2027	Payers share patient claims, encounter, and prior authorization data with in network providers.	Prior authorization history stops being a phone call. Duplicate requests become detectable before submission.
Payer to Payer API	Jan 1 2027	Data exchange between payers when a patient changes plans, on patient request.	Reduces the reauthorization cliff at plan change, historically a major cause of gap days.
Patient Access API additions	Jan 1 2027	Existing Patient Access API extended to include prior authorization information.	Patients can see status directly, which shifts some inbound status calls away from your staff.

Compliance dates vary by payer type. For Medicare Advantage organizations and state Medicaid and CHIP fee for service programs the API date is January 1, 2027; for Medicaid and CHIP managed care it is the first rating period beginning on or after January 1, 2027; for Qualified Health Plan issuers on the Federally Facilitated Exchanges it is plan years beginning on or after January 1, 2027. Sources: CMS-0057-F fact sheet, cms.gov, CMS Prior Authorization API FAQ, and 89 FR 8758, federalregister.gov.

What the rule does not cover

Two exclusions matter operationally. Drugs are outside the prior authorization provisions of CMS-0057-F, so specialty pharmacy and infusion authorizations obtained on the pharmacy benefit continue to run on their own timelines. And the impacted payer list stops at Medicare Advantage, Medicaid and CHIP in both fee for service and managed care, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. Commercial group business and self funded ERISA plans are not covered. For a practice with a heavy commercial mix, the 2026 clocks apply to part of the book and not the rest, which is exactly why a payer scorecard remains necessary rather than optional.

PLANNING NOTE The organizations that will benefit most from the 2027 APIs are the ones that already have a closed state model and a maintained payer rule library. An interface into an unstructured process just moves the mess faster.

Module 06 · escalationThe peer to peer ladder, four rungs.

A denial is not a verdict. It is the start of a defined sequence in which each rung has a decision maker, a time box, and an exit criterion. The reason the sequence has to be written down is in Exhibit 1: only sixteen percent of physicians told the AMA that the health plan reviewer on a peer to peer call often or always had appropriate qualifications for the clinical question at hand. If the reviewer is not qualified, that fact is your strongest argument at the next rung, and it only helps you if somebody recorded it.

RUNG
01

Reconsideration on the record

Before any clinical conversation, confirm the denial is not a documentation defect wearing a denial label. Pull the specific denial reason, which impacted payers must now provide, and check it against the submitted packet. A material share of denials at this rung are missing attachments, a wrong place of service, or a credential mismatch, all correctable without a physician's time.

OWNER: Authorization specialistTIME BOX: 24 hoursEXIT: Corrected resubmission or rung 2

RUNG
02

Clinical package rebuild

A senior specialist rebuilds the packet against the payer's own published medical policy for the service, citing the specific criteria met and the evidence that meets them. Conservative therapy history, functional assessment scores, and failed prior treatments go in explicitly rather than by inference. This rung resolves a large share of medical necessity denials without ever reaching a peer to peer call.

OWNER: Senior specialistTIME BOX: 48 hoursEXIT: Approval or peer to peer request

RUNG
03

Peer to peer review

The ordering physician speaks with the plan's reviewer. Three preparation rules make the difference. First, the physician receives a one page brief with the denial reason, the policy criteria, and the three clinical facts that satisfy them, never the whole chart. Second, the call is scheduled into a real calendar slot rather than accepted on a call back window. Third, the command center records the reviewer's name, specialty, and board certification, because under the AMA survey the odds are meaningful that the reviewer is not a specialty match.

OWNER: Ordering physicianTIME BOX: 72 hours to scheduleEXIT: Overturn or formal appeal

RUNG
04

Formal appeal and external review

Written appeal with the full evidence file, followed where available by independent external review and, in the pattern cases, a filing with the state insurance regulator. This rung is rare by design but its existence changes behavior at rungs one through three. Pattern denials against valid authorizations are a regulatory matter, not a customer service matter, and payers respond differently once the file is assembled that way.

OWNER: Appeals leadTIME BOX: Per plan and state ruleEXIT: Overturn, external review, or regulator

Ladder discipline pairs with a payer scorecard. The scorecard answers a question no individual case can: which payers cost you the most in cycle time and rework, and which behaviors are worth escalating as a pattern rather than case by case. From March 31, 2026, part of that scorecard stops being your own observation and becomes the payer's own published data, since impacted payers must post prior authorization metrics annually on their websites.

Payer scorecard dimension	Green	Amber	Red	How it is measured
Intake latency	< 2 hrs	2 to 8 hrs	> 8 hrs	Submitted state to pending state, from transition timestamps
Decision time, standard	< 3 days	3 to 7 days	> 7 days	Pending state to any determination, against the CMS 7 day limit
Decision time, expedited	< 24 hrs	24 to 72 hrs	> 72 hrs	Pending state to determination, against the CMS 72 hour limit
First pass approval	> 85%	70 to 85%	< 70%	Approved on initial submission with no rework, by payer
Documentation request rate	< 8%	8 to 15%	> 15%	Doc requested state entries divided by submissions
Channel stability	0 changes	1 change	2+ changes	Unannounced portal or form changes per quarter per payer
Peer to peer match rate	> 70%	40 to 70%	< 40%	Reviewer specialty matched the clinical question, from call logs
Appeal overturn rate	> 60%	40 to 60%	< 40%	Your overturns, cross checked against the payer's posted metrics

Thresholds are ASP-RCM operating bands, not regulatory standards. The 72 hour and 7 calendar day limits in rows two and three are the CMS-0057-F requirements for impacted payers; see the CMS fact sheet.

An authorization is not a document. It is perishable inventory with two clocks on it: a date that expires and a unit balance that drains. Track only the date and you will run out of units in week nine and never see it coming.
The Prior Auth Command Center · ASP-RCM Solutions · Edition 2026.2

Module 07 · the two clocksExpiring authorizations and units remaining.

Every active authorization carries two independent countdowns. The date clock is visible, sits in the record, and is easy to report on. The unit clock is invisible unless someone builds it, drains at the pace of the delivered schedule, and is the one that actually runs out first in recurring service lines. A command center displays both on every active authorization and triggers on whichever will exhaust sooner.

AUTH #A-3982ACT NOW

ABA adaptive behavior treatment97153 · 480 units · 6 month span

UNITS USED 456 / 480DATE LEFT 5 days

Both clocks are near zero. Reauthorization packet submitted with the current assessment attached. RBT session schedule capped at remaining units until the new approval posts.

AUTH #A-4471TRIGGERED

ABA adaptive behavior treatment97153 · 384 units · 6 month span

UNITS USED 317 / 384DATE LEFT 41 days

The unit clock fired at 80 percent while the date clock still shows six weeks. This is the ordinary case in ABA and the one a date based tracker misses entirely. Packet queued, assessment refresh requested from the BCBA.

AUTH #A-5120HEALTHY

ABA adaptive behavior treatment97153 · 520 units · 6 month span

UNITS USED 229 / 520DATE LEFT 64 days

Consumption is tracking the authorized pace. RBT session logs are posting on schedule and the projected exhaustion date sits inside the authorization span. No action, weekly review only.

Exhibit 5 · Illustrative countdown exhibit. Figures are anonymized and representative of the console described on our prior authorization automation capability page. No client information is shown.

The ABA 97153 case

Applied behavior analysis makes the two clock problem unavoidable, which is why it is the clearest teaching case. Code 97153, adaptive behavior treatment by protocol, is delivered by Registered Behavior Technicians under the direction of a Board Certified Behavior Analyst. It is authorized as a pool of fifteen minute units across a date span, often several hundred units across three or six months. The BCBA writes the treatment plan and supervises. The RBTs deliver the direct hours that consume the pool.

Consumption is therefore driven by RBT staffing and family attendance, not by the calendar. A client scheduled for twenty hours a week burns eighty units a week. If the plan was authorized assuming sixteen hours a week, the pool that was supposed to last six months exhausts in under five. Nothing in a date based tracker fires. The authorization still shows as active because its end date has not arrived. Sessions continue, the RBTs deliver real care, and the claims for every session past unit exhaustion come back unpaid.

The inverse failure is just as expensive and much quieter. If the RBT team is short staffed and the client receives twelve hours a week against a plan authorized at sixteen, the pool never exhausts. The authorization expires on its date with a hundred and twenty approved units unused. Nothing denies, because nothing was billed. That is approved, reimbursable, clinically indicated care that simply never happened, and it will not appear on any denial report. Our companion paper, The Authorization Ledger, treats that utilization gap as the master metric of ABA revenue.

The control is a projection rather than a threshold. Take units remaining, divide by the trailing four week consumption rate, and you get a projected exhaustion date. Compare it to the authorization end date. If projected exhaustion lands before the end date, the reauthorization packet starts now and the BCBA is told how many weeks of runway remain. If projected exhaustion lands after the end date, the schedule is under the authorized pace and the BCBA is told how many additional hours per week would consume the approval. Both conversations are actionable. Neither is possible from a status field.

Client engagement · multi state ABA provider

Two clocks, one meter, zero unbilled sessions.

A multi site ABA provider was managing 97153 authorizations from a spreadsheet keyed on expiry date. Reauthorization work started thirty days before expiry, which felt disciplined and was in fact arbitrary. Roughly one authorization in five was exhausting its unit pool weeks before its end date, and the RBT teams kept delivering sessions against an authorization that looked active on the calendar and had no units left in it.

ASP-RCM moved the trigger from the date to the meter. Every active authorization got a units consumed percentage, a trailing consumption rate, and a projected exhaustion date. Packets queue automatically at eighty percent of units consumed and again at ninety five percent, with the current assessment pulled and routed to the supervising BCBA for review. The date remained as a backstop trigger at thirty days, but it stopped being the primary signal.

80%Units trigger, first packet

95%Hard trigger, escalation

0Sessions delivered without active auth

Client, payers, and volumes anonymized. Engagement describes real ASP-RCM work in the ABA service line, staffed by BCBAs and RBTs.

THE TRIGGER RULE Start the reauthorization packet at eighty percent of units consumed or thirty days before expiry, whichever arrives first. In recurring service lines the units trigger fires first far more often than the date trigger does.

Module 08 · the tie-outAuth to claim reconciliation closes the loop.

An approved authorization is a promise about four things: which service, how many units, delivered by which credential, inside which date span. A paid claim is a statement about the same four things. Reconciliation is the routine comparison of the two, and it is the only stage that can prove the pipeline worked. Everything upstream is activity. This is outcome.

Four variance classes come out of the tie-out, and each routes to a different owner. Units billed above units approved is an overbill exposure that will deny or, worse, pay and be recouped later. Units approved above units billed is the utilization gap, which never denies because it never becomes a claim. A credential mismatch means service was delivered by one credential tier and billed against a pool granted for another, which burns the wrong pool and strands the right one. And a date span breach means service fell outside the authorized window, which is the one variance that is usually unrecoverable.

Variance class	What it looks like	Recoverable	Routes to	Prevention control
Overbilled units	Billed units exceed approved units on the same auth	Usually no	Billing lead, pre-submission edit	Hard stop edit at claim scrub against remaining balance
Utilization gap	Approved units expire unbilled and unused	No	Scheduling and clinical lead	Weekly units meter review with projected exhaustion date
Credential mismatch	Rendering credential does not match the authorized pool	Sometimes	Authorization specialist	Credential tier carried on the auth record and checked at scheduling
Date span breach	Service date falls outside the authorized window	Rarely	Scheduling lead	Scheduling block on dates outside any active authorization
Auth number absent	Claim submitted with no authorization reference	Usually yes	Billing lead	Claim edit requiring an auth number for auth-required codes
Partial approval ignored	Schedule built to requested units, not approved units	Sometimes	Authorization specialist	Distinct partially approved state that forces a schedule rebuild

The reconciliation cadence that works is weekly at the authorization level and monthly at the payer level. Weekly catches the drift while the schedule can still absorb a correction. Monthly aggregates the variance into a payer pattern, which is what feeds the scorecard and, where the pattern is systemic, rung four of the ladder. The same reconciliation discipline appears in our Three-Way Match Handbook as the match between schedule, session note, and claim line.

The benchmark set

Nine metrics run the command center. They are deliberately few, because a dashboard that reports forty numbers reports nothing. Each has a target, a warning threshold, and a review cadence, and each has a named owner who is accountable for the number rather than for the activity behind it.

Command center metric	Target	Warning	Cadence	Owner
Requests with a named owner	100%	Below 100%	Daily	Auth manager
Packet out, lane A	4 business hrs	Over 8 hrs	Daily	Auth specialist
First pass approval rate	Above 85%	Below 70%	Weekly	Auth manager
Documentation request turnaround	Under 24 hrs	Over 48 hrs	Daily	Auth specialist
Wrong channel submissions	0	Any	Weekly	Rule library owner
Authorizations past units trigger	0 unqueued	Any unqueued	Weekly	Reauth lead
Services rendered without active auth	0	Any	Daily exception	Scheduling lead
Auth to claim variance rate	Under 2%	Over 5%	Weekly	Billing lead
Peer to peer scheduled within 72 hrs	Above 90%	Below 75%	Weekly	Appeals lead

Targets are ASP-RCM operating standards for authorization-heavy service lines and are not regulatory requirements. Payer decision limits referenced elsewhere in this paper are regulatory and are sourced to cms.gov.

WHERE TO START Pick two metrics: requests with a named owner, and services rendered without an active authorization. Both should be at their targets within thirty days, and neither requires new software to achieve.

Module 09 · FAQSix questions operators ask us.

What is a prior authorization command center?

A single operating surface where every open authorization request is triaged by urgency, routed to the correct payer channel, polled to determination, escalated on a defined ladder, and reconciled against the claim it eventually supports. It replaces the inbox, the spreadsheet, and the coordinator's memory with one queue and one owner.

What does CMS-0057-F require and when?

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), published at 89 FR 8758 on February 8, 2024, requires impacted payers to issue expedited prior authorization decisions within 72 hours and standard decisions within 7 calendar days, give a specific reason for denial, and publicly report prior authorization metrics, generally beginning January 1, 2026. The FHIR API requirements, including the Prior Authorization API, Provider Access API, and Payer-to-Payer API, carry compliance dates generally beginning January 1, 2027.

Which payers are impacted by CMS-0057-F?

Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the Federally Facilitated Exchanges. Commercial group plans and ERISA self-funded plans are outside the rule, which is why a payer scorecard still matters after 2027.

How should prior authorization intake be triaged?

By clinical urgency and by dollar exposure, not by arrival order. Expedited clinical requests run against the 72 hour payer clock, standard requests against the 7 calendar day clock, and recurring service reauthorizations against the units-remaining trigger rather than the calendar.

When should an ABA reauthorization packet be started?

At 80 percent of authorized units consumed, not at a fixed number of days before expiry. A 97153 authorization consumed by RBT session hours can exhaust weeks ahead of its end date, so the units meter is the real clock and the expiry date is only the backstop.

What is auth-to-claim reconciliation?

A tie-out that matches the authorization number, the approved units by code, the rendering credential, and the date span against the claim lines actually submitted and paid. Variances become root cause work before they become denials or unbilled services.

Keep goingWhere this connects.

Companion white paper The Authorization Ledger

Authorization utilization as the master metric of ABA revenue: the 85 to 95 percent operating range, and the four ways authorizations fail without ever denying.

READ THE LEDGER → Capability AI for Prior Authorization

The production layer under this operating manual: packet assembly, payer routing, 276 and 277 polling, appeal triage, and reauthorization automation.

SEE THE CAPABILITY → Service line ABA Billing Services

The team that runs authorization operations for practices staffed by BCBAs and RBTs, including 97153 unit management and reauthorization pipelines.

SEE THE SERVICE →

How many authorizations are running without an owner?

Send us ninety days of authorization and denial data. A senior partner returns a written audit: your lane mix, cycle time by payer against the CMS-0057-F limits, units at risk of expiring unbilled, and a thirty day corrective plan.

Get my free denial and auth audit See prior auth automation

Aparna Suresh, CPBCertified Professional Biller · President and Founder, ASP-RCM Solutions