CO-170 is a prior authorization denial — the payer required advance approval for this service, and none was on file when the claim was adjudicated. Act immediately: most payers have a retro-auth window that closes within 30–60 days of the date of service. After that window, your only option is a formal appeal.
CO-170 means the payer required prior authorization for this service and didn't have one on file. Act immediately — call the payer's retro-auth line today, not next week. For emergency services, federal law generally protects you: a prudent layperson standard applies and payers cannot retroactively deny emergency care. For non-emergency services, you have a limited window to request retro-auth before your only option becomes a formal appeal.
Retro-authorization windows are fixed and non-extendable in most payer contracts. For emergency/urgent services: typically 24–72 hours from time of service, sometimes up to 30 days. For non-emergency services: typically 30–60 days from date of service. After the window closes, the claim goes to formal appeal — a longer, less reliable process with lower success rates. When you receive a CO-170, call the payer's retro-auth department the same day.
| Scenario | Why the Auth Was Missing | Action | What to Do |
|---|---|---|---|
| Auth not requested — staff didn't know this procedure required it | Payer auth requirements change quarterly. A procedure that didn't require auth last year may require it now. Staff relied on outdated knowledge or didn't check the payer's current auth list. | Retro-Auth | Call retro-auth line immediately. Submit clinical documentation package. Update your payer-specific auth-required list for this procedure going forward. |
| Patient presented as emergency — no time for prospective auth | Emergent presentation required immediate treatment. Federal law (ACA, EMTALA) and most state laws prohibit requiring prior authorization for emergency services. | Emergency Override | Appeal citing the prudent layperson standard and the patient's presenting symptoms. Attach the emergency documentation: chief complaint, vital signs, physician determination of emergency status. Federal law protects this scenario. |
| Auth obtained for wrong CPT code | The auth was requested using a different procedure code than what was ultimately performed (e.g., auth for 27447 but performed 27446, or auth for initial consult but follow-up was billed). | Retro-Auth Amendment | Call auth department, explain the code discrepancy, and request an auth amendment to cover the correct CPT. This is closer to CO-15 territory — the auth exists but was for a different code. |
| Auth obtained for different date of service | Auth was approved for a specific DOS range, and the service was rendered outside that window — patient rescheduled, procedure was delayed, or billing used the wrong date. | Retro-Auth or Appeal | If within retro-auth window: request retro-auth for the actual DOS. If the DOS is correct and the auth had the wrong date range, contact auth department to amend. If window closed: appeal with documentation showing clinical continuity. |
| Patient transferred to out-of-network facility — auth not transferred | Auth obtained for in-network facility; patient was transferred to OON hospital for level of care. The auth doesn't follow the patient across network boundaries in most payer systems. | Appeal | Appeal citing continuity of care, lack of available in-network alternatives, and the clinical necessity of the transfer. If the transfer was emergent, the emergency care federal protection applies. |
| Auth obtained under wrong insurance plan — patient had a plan change | Patient changed plans mid-auth process. Auth approved under old plan doesn't carry to new plan. Common with Medicaid managed care plan changes or employer open enrollment switching. | New Retro-Auth | Verify correct plan at time of service. Request new retro-auth under the current plan. This is also a registration issue — update patient insurance verification workflow to catch mid-care plan changes. |
| Auth approved but number not documented — claim submitted without it | Authorization was actually obtained and is on file, but the auth number was not entered into the claim. The payer's system sees no auth number and generates CO-170. | Claim Correction | Locate the auth number in your system (usually in the patient's account notes or PM system). Submit a corrected claim with the auth number in box 23 (CMS-1500) or the appropriate loop/segment (837P: loop 2300, REF*G1). No retro-auth needed — auth exists. |
| Payer added auth requirement mid-authorization process | Payer updated their auth-required list after the appointment was scheduled but before the service was rendered, creating a gap where neither the provider nor the patient could have known in advance. | Appeal | Appeal citing the payer's retroactive imposition of a requirement that wasn't in force when the appointment was scheduled. Document when the appointment was booked vs. when the payer's auth requirement took effect. Many state insurance departments consider this an unfair claims practice. |
The windows above are general guidelines. Individual plan contracts can set shorter or longer windows. The safest approach: when you receive a CO-170, call the payer's retro-auth line the same day and ask for the specific window for this plan. Document the call: date, representative name, reference number, and the window they gave you.
| Auth Parameter | What to Verify | Where It Appears on Claim | Common Mismatch |
|---|---|---|---|
| Auth Number | Auth number is documented in the patient's account and will be entered on the claim | CMS-1500 Box 23; 837P Loop 2300 REF*G1 | Auth obtained but not entered on claim → corrected claim fixes this without retro-auth |
| Date of Service | The approved DOS range on the auth covers the actual date of service — not just the scheduled date | Auth letter / payer portal auth detail | Patient rescheduled; auth expired; billing used charge capture date not the service date |
| Procedure Code | The CPT/HCPCS codes on the auth match what will be billed — including add-on codes if the payer separately requires them | Auth letter / payer portal auth detail | Auth for initial CPT; additional intraoperative procedures performed; or add-on codes not auth'd separately |
| Rendering Provider & Facility | The auth is for the specific rendering provider NPI and the specific facility NPI where the service will be rendered | Auth letter — provider and facility listed | Provider substituted day-of; patient transferred to different facility; locum tenens not listed on auth |
Auth verification done the morning of service is too late if there is a discrepancy — there is no time to correct it before the patient presents. Run your pre-service auth verification 24–48 hours before each scheduled date of service. This gives you time to amend the auth, update the DOS range, or add a missing CPT before the patient arrives.
VIA: Prior Authorization Appeals Department
Date: [Date] | Payer: [Payer Name] | Claim #: [Claim #]
Member ID: [Member ID] | Patient: [Name] | DOS: [Date of Service]
Provider NPI: [NPI] | Denied Code: CO-170 | Procedure: [CPT Code(s)]
RE: Appeal of CO-170 Denial — Prior Authorization Not Obtained
This claim was denied under CO-170 indicating prior authorization was not obtained before service was rendered on [DOS]. We respectfully appeal this determination on the following grounds:
Option A — Emergency/Urgent Presentation:
The patient presented on [DOS] with [presenting symptoms], which required immediate medical treatment. The patient's condition met the prudent layperson standard for emergency care as established by the Affordable Care Act (42 U.S.C. § 300gg-19a) and [state law citation if applicable]. Federal and state law prohibit health plans from requiring prior authorization for emergency services and from retroactively denying emergency care. We attach the emergency documentation: chief complaint, presenting vitals, and the treating physician's clinical determination. We respectfully request that this claim be reprocessed as an emergency service and paid at the in-network rate.
Option B — Service Met All Clinical Coverage Criteria:
While authorization was not obtained prospectively, the service met all of your plan's clinical coverage criteria for this procedure. We enclose the medical record, the treating physician's letter of medical necessity, and [payer coverage policy/LCD citation] demonstrating that this service was appropriate and covered. Had authorization been requested prospectively, it would have been approved. A full denial for an administratively missing authorization — when the service was clinically appropriate, medically necessary, and covered under the plan — is a disproportionate penalty that the member's contract does not require.
Option C — Administrative Error / Retroactive Requirement:
[Describe specific circumstance: auth obtained for wrong code / auth number not entered on claim / payer updated auth requirement after appointment was scheduled / etc.] We attach documentation of [auth correspondence / scheduling records / payer communication] demonstrating that [the auth was in process / the requirement was not in force at time of scheduling / etc.] and request that this claim be reprocessed accordingly.
Enclosed: Medical record, physician letter of medical necessity, coverage policy/LCD, [other supporting documentation].
Contact: [Name, Phone] | Practice: [Practice Name]
A single CO-170 is a mistake. Repeated CO-170 denials on the same payer or procedure are a process failure — and every one represents revenue your team worked to earn but can't collect. A free RCM audit identifies your specific auth workflow gaps, helps you build a payer-specific auth-required list, and implements the pre-service verification step that stops CO-170 before it starts.