A prior authorization tracking system is a field list, a set of states and one weekly reconciliation. Get the fields wrong and the claim dies at adjudication. Get the states wrong and nobody notices until the payer recalculates. Here is the record to keep, the sources worth trusting and the numbers that show whether the system is holding.
Why prior authorization tracking fails quietly
Almost nobody loses an authorization by forgetting to request one. The loss comes later, when the approval that came back covers a different provider, a different place of service or fewer units than the claim bills. A number typed into a scheduling note survives right up to adjudication, then stops being evidence of anything.
Three mismatches do most of the damage. The payer approved three units and the claim bills four. The approval names the ordering provider while the claim bills a different NPI in the same group. The plan month turned over between the approval and the visit.
The remittance flags it eventually. X12 deactivated CO-15, the old code for a missing or invalid authorization number, on 1 May 2018. The code carrying that message now is CARC 197: precertification, authorization, notification or pre-treatment was absent. Map your denial report against the current X12 list, because retired codes keep circulating.
The fields a prior authorization tracking record has to carry
A tracking record is not an authorization number. It is the smallest set of facts that lets a biller prove, four months later, that the service billed is the service the payer approved, for the provider who rendered it, on the day it was rendered.
| Field | What it has to say | What breaks when it is missing | Where it comes from |
|---|---|---|---|
| Authorization number | The payer’s identifier for the approved request | The claim carries no match and CARC 197 returns | Portal detail, 278 response or confirmation letter |
| Payer reference number | The payer’s case number, not always the authorization number | A follow-up call has no handle on the file | Portal case detail or confirmation letter |
| Approved units and unit type | How many, and whether visits, 15-minute units, hours or days | The claim bills past the quantity or the wrong unit | Portal authorization detail |
| Effective and expiration dates | The window the payer will pay against, first date through last date | A service outside the window is treated as unauthorized | Portal detail or approval letter |
| Rendering provider | Name and NPI of the clinician billing the service | The payer matches another NPI and denies the line | Schedule and authorization detail |
| Ordering or supervising provider | Name and NPI of the prescriber or supervisor | Imaging, therapy and assistant-at-surgery claims fail on that link | The order and authorization detail |
| Place of service | The setting approved, such as office or hospital outpatient | The payer prices another setting or voids the approval | Authorization detail and charge entry |
| Codes authorized | Every CPT, HCPCS or revenue code approved | A code added at the visit goes out unapproved | Portal authorization detail |
Unit type is the field dropped most often and it changes the arithmetic. Fifteen-minute units, visits per week, hours per day and days per authorization are not interchangeable. An approval for 20 hours a week and a claim written in 15-minute units look identical in a spreadsheet. ABA authorizations need the unit type as its own field.
- Open the authorization detail screen, not the summary line, before the number enters the record
- Store approved units and unit type as two fields, never one note
- Copy the expiration date, then set reminders at 30 days and 7 days before it
- Attach the confirmation: a timestamped portal file, a 278 response or a call reference
A denial for a missing authorization is winnable when the record shows the approval existed and the units were never exceeded. With only a number on file, it becomes a write-off.
Where the data comes from, and why a portal screenshot is not enough
Authorizations arrive through three doors and each one leaves a different trail. The payer portal is the fastest. The 278 transaction is the most structured. The fax or the phone call is the fallback, and the fallback is where records go thin.
| Source | What it gives you | What it does not prove | What to keep |
|---|---|---|---|
| Payer portal | Units, dates, codes, place of service and provider on one screen | That the payer’s adjudication system holds the same values | A timestamped copy of the detail screen |
| 278 transaction | A structured request and response in defined fields | Nothing about a service the payer later excludes | The payload stored next to the response |
| Fax or phone | A decision when the other two paths are closed | That the decision sits on a reference anyone can find again | The fax page, the representative’s name, the call reference |
A screenshot answers one question: what the portal displayed at a single moment. It does not carry the payer’s case reference, it can hide fields on a second screen, and it goes stale when a plan year turns over. The 278 warrants the same care: store the submitted payload beside the response, because the response is what shows the units the payer approved.
Get the representative’s name, the call reference number and the date. Ask for written confirmation if the payer offers it. An approval with no reference number is one you will have to prove twice.
Lifecycle states, and the transitions that need a human
An authorization passes through a handful of states, and software can hold every one of them. Each state has a trigger: the service appears on a payer list, an acknowledgement comes back, the payer pends the case, a decision lands. What software cannot do is notice that a request went out under the wrong member ID.
| State | What moves it forward | Human needed |
|---|---|---|
| Identified | A request goes out with the order and clinical note | Yes. Confirm the requirement on the payer’s list |
| Submitted | Acknowledgement, case number and expected decision date | Yes. Match the acknowledgement to the request |
| Pended | Records go out, or the request is corrected and resubmitted | Yes. A pended case should never run on a timer |
| Approved | Values go into the record and against the schedule | Yes. Approval is where the fields get verified |
| Denied | Appeal, peer-to-peer or corrected request on the payer’s timeline | Yes. A denial needs an owner and a dated next step |
| Verified against the claim | The claim goes out | Yes. This check prevents CARC 197 |
- 01
Set the review cadence by state, not by date
Pended cases get a look every two business days. Approved cases get reconciled against the schedule within one.
- 02
Give every denial a named owner
Leave the biller who requested the authorization on the case until it is resolved or written off.
- 03
Retire the record when the claim is paid
Close the record against the paid claim, not the decision. An approval that never became a paid claim is the leak.
The reconciliation that catches a mismatched authorization
Reconciliation is one comparison run on a schedule: the values the payer approved against the values the claim will carry. Run it 72 hours before the visit and again before submission. Both passes take minutes on a worklist.
- Codes: every CPT, HCPCS or revenue code on the claim appears in the authorization, including codes added later
- Units: the billed quantity sits inside the approved quantity, converted to the authorization’s unit type
- Dates: the date of service falls between the effective date and the expiration date, plan year included
- Providers: the rendering NPI and any ordering or supervising NPI match what the payer approved
- Place of service: the setting billed is the setting the payer approved
Where the record and the claim disagree, three fixes cover almost everything. Correct the claim when the authorization is right and the data entry is wrong. Request a corrected or retroactive authorization when the service changed after the approval. Escalate to a peer-to-peer when the payer reads its own policy differently than the chart supports.
| Mismatch | Usual cause | Fix | Timing |
|---|---|---|---|
| Code billed, not authorized | A code added at the visit for a separate finding | Corrected authorization request, or bill only the approved code | Before submission |
| More units than approved | Unit type mismatch or a longer visit than planned | Recheck the unit type, then request the additional units | Before submission |
| Expired authorization | The visit moved past the approval window | Retroactive request with the clinical note, where the payer allows it | Same week as the reschedule |
| Wrong provider or setting | A locum, a new associate or a move to hospital outpatient | Correct the claim, or ask the payer to reassign the approval | Before submission |
The metrics worth watching
| Metric | How to build it | What a bad reading looks like | Where the data lives |
|---|---|---|---|
| Approval turnaround | Median days from submission to decision, split expedited and standard | Expedited past 72 hours, standard past seven calendar days | Submission and decision dates in the record |
| Requests denied | Share of submitted requests the payer denies, by payer and service line | One payer or service line far above the rest | Decision status joined to the remittance |
| Denials rooted in authorization | CARC 197 volume as a share of all denials, plus how many had a matching approval on file | A rising share where the record shows an approval | Denial report joined to the tracking record |
The turnaround metric has a reference point nobody has to invent. CMS-0057-F requires impacted payers to decide expedited requests within 72 hours and standard requests within seven calendar days, from 1 January 2026. A payer running past those windows is outside the ceiling CMS set. Keep all three numbers narrow enough that one person can produce them on a Monday morning and post them where the work happens.
Prior authorization burden reported by physicians, 2024 AMA survey
Source: AMA 2024 prior authorization physician survey, 1,000 practicing physicians, fielded December 2024.
The third metric improves the other two. Split authorization denials into those where the record shows a matching approval and those where it does not. The first group is a clinical or coding dispute. The second is a tracking failure, the only group your practice can fix by changing its own work. Run that split through your denial management process.
What CMS-0057-F makes machine-readable, and when
CMS released the Interoperability and Prior Authorization final rule, CMS-0057-F, on 17 January 2024 and published it in the Federal Register on 8 February 2024. It binds 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. Medicare fee-for-service and most commercial group business sit outside it.
Two groups of obligations sit inside it and they do not share a date. The process obligations, covering how fast a payer must decide and what it says when it denies, generally begin 1 January 2026. The API obligations, the four HL7 FHIR interfaces the rule requires, generally begin 1 January 2027. Each provision carries its own date in the CMS fact sheet.
| Requirement | What changes for a practice | Compliance date | Applies to |
|---|---|---|---|
| Prior Authorization API | Requests, responses and denial reasons move electronically against a published list of covered items and documentation rules | Beginning 1 January 2027 | Impacted payers |
| Patient Access API with authorization data | Patients see their own authorization information in the app they choose | By 1 January 2027 | Impacted payers |
| Provider Access API | In-network providers pull claims, encounter and authorization data for patients in a treatment relationship | By 1 January 2027 | Impacted payers |
| Payer-to-Payer API | Claims, encounter and authorization data follow the patient to a new payer, limited to five years | By 1 January 2027 | Impacted payers |
| Decision timeframes | Expedited requests decided within 72 hours, standard within seven calendar days | Beginning 1 January 2026 | Impacted payers except QHP issuers on the FFEs |
| Specific denial reason | Every denial states its reason whatever channel carried the request | Beginning 2026 | Impacted payers |
| Public prior authorization metrics | Payers post their own authorization metrics each year | First set by 31 March 2026 | Impacted payers |
Decision windows for impacted payers from 1 January 2026
Source: CMS, CMS Interoperability and Prior Authorization final rule (CMS-0057-F) fact sheet.
A practice in a state with its own prior authorization statute holds a second lever. Michigan’s Public Act 60 of 2022, codified at MCL 500.2212e, requires insurers to modify prior authorization requirements based on provider performance.
The mechanism in practice is a gold card. UnitedHealthcare’s Michigan gold card program, which cites that section, exempts a provider from requesting authorization for a service when it holds a final approval rate of 92% or higher in each of two evaluated years, on at least 10 requests a year for that service. That covers commercial members in Michigan, so it is a state lever and not a national one. Our prior authorization services build the approval-rate record the exemption depends on.
When it published the rule, HHS said it would apply enforcement discretion to the HIPAA X12 278 prior authorization standard. A payer that builds an all-FHIR prior authorization API will not be enforced against for leaving the 278 out. Build for both.
Questions practices ask us about this
What has to be in a prior authorization tracking record?
At minimum: the authorization number, the payer’s own reference or case number, the approved units and unit type, the effective and expiration dates, the rendering provider and any ordering or supervising provider with NPIs, the place of service, the codes authorized, and the plan and member identifier.
Why keep the payer reference number if I already have the authorization number?
They are usually different values serving different purposes. The authorization number is what the claim and the payer’s adjudication system match on. The reference or case number is what the call centre uses to pull the file. Without it, a follow-up call may have no way to find a decision that was already made.
Is a portal screenshot enough to prove a prior authorization exists?
It is evidence, not a record. A screenshot shows what the portal displayed at one moment. It does not always carry the payer’s case reference, it may omit approved units held on another screen, and it goes stale when a plan year turns over. Keep the 278 response or written confirmation beside it.
How do we catch an authorization that does not match the claim that was billed?
Compare five values on a schedule: codes, units converted to the same unit type, dates of service against the effective and expiration dates, the rendering and ordering or supervising NPIs, and the place of service. Run it 72 hours before the visit and again before submission. Most mismatches come from a code added at the visit.
What does CMS-0057-F change for a practice, and when does it start?
The process provisions start 1 January 2026: expedited decisions within 72 hours, standard decisions within seven calendar days, a stated reason on every denial, and public payer metrics with the first set due by 31 March 2026. The four FHIR APIs, including the Prior Authorization API, follow from 1 January 2027.
Does Michigan’s prior authorization law help a practice outside Michigan?
No. Public Act 60 of 2022, codified at MCL 500.2212e, governs insurers writing Michigan business, and gold card programs built on it cover Michigan members. A practice in another state has to look at its own statute and the payer contracts that follow it. Treat every state programme as state-specific.
Want the authorizations tracked properly?
We run prior authorization, eligibility and denial work for practices across the country. Send us a month of authorizations and we will show you where the mismatches are.
Book a free billing review- CMS, CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet, 17 January 2024. cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f
- CMS, Prior Authorization and the 2024 CMS Interoperability and Prior Authorization Final Rule. cms.gov/initiatives/burden-reduction/overview/interoperability/policies-regulations/cms-interoperability-prior-authorization-final-rule-cms-0057-f
- Federal Register, Advancing Interoperability and Improving Prior Authorization Processes, 8 February 2024. federalregister.gov/documents/2024/02/08/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability
- AMA, 2024 prior authorization physician survey (1,000 physicians, fielded December 2024). ama-assn.org/practice-management/prior-authorization/exhausted-prior-auth-many-patients-abandon-care-ama-survey
- X12, Claim Adjustment Reason Codes, current list. x12.org/codes/claim-adjustment-reason-codes
- Michigan Compiled Laws 500.2212e, prior authorization modification program. legislature.mi.gov/Laws/MCL?objectName=mcl-500-2212e
- UnitedHealthcare, Michigan gold card exemptions, provider FAQ. uhcprovider.com/content/dam/provider/docs/public/prior-auth/gold/mi-gold-card-faq.pdf
