Payers Without an API: How RCM Software Gets Eligibility, Claim Status, and Prior Auth Answers

Updated November 5, 2026, based on CMS, the eCFR, X12, CAQH and UnitedHealthcare as of that date.

When a payer does eligibility, claim status or prior authorization electronically, HIPAA requires the X12 standard: the 270/271, the 276/277 and the 278. That gives RCM software a common format across payers. It doesn't guarantee a useful answer. A response can be valid X12 and still leave out the detail your user needs, and that detail often sits only in the payer's portal or with a phone representative.

The federal picture is shifting for some payers. Under CMS-0057-F, Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and QHP issuers on the federally facilitated exchanges must stand up a Prior Authorization API by January 1, 2027. Commercial employer plans aren't on that list, and claim status isn't part of the rule.

The practical answer is a fallback order per payer and per workflow: EDI first, an API where one exists, then the portal, then the phone. Below is what each channel returns and where it runs out.

What X12 gives you for eligibility, claim status and prior auth

CMS's HIPAA transactions page lists the adopted transactions and says covered entities that conduct them electronically must use an adopted ASC X12N or NCPDP standard. 45 CFR Part 162 names the versions:

• Eligibility: the 270/271 (005010X279), in § 162.1202. The 271 answers whether the patient is eligible, what the plan covers, and the benefits attached.
• Claim status: the 276/277 (005010X212), in § 162.1402.
• Prior authorization: the 278 Health Care Services Review (005010X217), in § 162.1302.

Eligibility and claim status also carry federally adopted CAQH CORE operating rules. § 162.1203 adopts the CORE eligibility rules, including the 270/271 data content rules and the AAA error code rule. § 162.1403 adopts the CORE claim status rule. Part 162 adopts no operating rules for the 278.

Adoption follows the same pattern. The 2025 CAQH Index puts medical plan adoption of fully electronic eligibility verification at 96%, compared with 40% for prior authorization.

Where a response comes back thin

A 277 can be correct and still not tell your user what to do next. The X12 claim status category codes show why. P0 is "a generic message about a pended claim." P1 says the claim is in the adjudication system. P2 says it's suspended for payer review, such as medical review or repricing. None of them says specifically what is holding the claim or who has to act.

P3 is more specific. It means the payer is waiting for information it already requested from the provider, and X12 requires a claim status code naming the type of information. The request itself, such as a letter listing the records the payer wants, doesn't travel in the 277.

The 271 has a similar gap. The CORE data content rules set a floor for what eligibility responses carry, and above that floor payers differ in how much they return. Your product sees the difference as a response that parses cleanly but leaves your user without the answer.

When the response is thin, the user has two places to go: the payer's portal or its phone line.

What CMS-0057-F changes, and for whom

The CMS fact sheet on CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. By January 1, 2027, those payers must offer Patient Access, Provider Access and Payer-to-Payer APIs and a Prior Authorization API.

The Prior Authorization API has to list covered items and services, identify documentation requirements, and support requests and responses. A response must say whether the request was approved, was denied with a specific reason, or needs more information. Beginning in 2026, the same payers (except QHP issuers on the FFEs) must decide expedited requests within 72 hours and standard requests within seven calendar days. Impacted payers must also give a specific denial reason, however the request was sent. Drugs are excluded from these requirements.

The fact sheet doesn't mention commercial employer plans, and it doesn't create a claim status API. The Provider Access API carries claims and encounter data, without provider remittances or enrollee cost-sharing, which helps with history but not with "where is this claim now." For a commercial plan, or for a claim stuck in pending, the channels stay what they are today.

Portals: what they show that EDI doesn't, and what it takes to keep reading them

A payer portal can be the only place some answers live. UnitedHealthcare's Document Library is one example. For commercial plans, it holds claim letters marked "Action required," denials and approvals, prior auth letters that include insufficient-information notices, remittance advice, and appeal and dispute documents. Documents appear 24 hours after they're generated.

Under 45 CFR 162.923(b), a provider using a health plan's direct data entry must follow the standard's data content requirements but not its format. A portal transaction covers the same ground as the X12 one, and the portal can add letters, images and notes around it.

Reading portals at scale takes upkeep. The same UnitedHealthcare page says RCM and billing companies need individual One Healthcare IDs and third-party access for each tax ID they work with. Multiply that by every payer and every client, and someone has to own credential provisioning, multi-factor prompts, password rotation, and changes to the screens. Our guides to Availity automation and UnitedHealthcare portal automation cover two common portals, and browser agents vs. RPA covers how each approach handles screen changes.

Phone: when it's the only way to the answer

Some questions need a person. The CMS Medicare Contractor Beneficiary and Provider Communications Manual, chapter 6, requires Medicare Administrative Contractors to make providers use the IVR for claim status. Their first-level representatives answer basic questions that self-service options can't address, and second-level representatives handle questions that need more research.

Commercial and Medicaid plans set their own phone rules, so check each payer's provider manual. Typical reasons to call are a claim that has sat in P0 or P2 with no portal explanation, or a denial that needs explaining before an appeal. The answer is spoken, so whoever makes the call needs the payer's authentication requirements, the reference number from the call, and a place to record what the representative said.

Choosing a fallback order per payer and workflow

There's no single order that fits every payer. Build one per payer and per transaction, and revisit it when a payer changes its connectivity.

1. Start with X12 through your clearinghouse for every payer and transaction it supports. Under 45 CFR 162.925, a health plan must conduct a transaction as a standard transaction when asked.
2. Add the CMS-0057-F Prior Authorization API for impacted payers as they go live, and confirm each payer's date with that payer.
3. Map which responses come back thin for each payer. Track 277 category codes such as P0 and P2, and 271 responses missing the benefits your users ask about.
4. Route those cases to the portal, with credentials managed per payer and per tax ID.
5. Keep phone as the last step, for questions the portal can't answer, and record the call reference and outcome in your product.

Some teams automate steps 4 and 5. Others staff them or buy them from a clearinghouse or another vendor. Either way, your product needs to know which channel each payer needs for each question.

Frequently asked questions

Does CMS-0057-F require a claim status API?

No. The CMS fact sheet requires Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs. Claim status stays on the 276/277, the portal and the phone.

Does a clearinghouse cover this?

A clearinghouse covers the X12 side. 45 CFR 162.923(c) lets a covered entity use a business associate, including a clearinghouse, to conduct standard transactions. A clearinghouse passes along what the payer returns, so it can't fill in a detail the payer left out of the 271 or 277.

Is the X12 278 going away?

Not under current rules. The 278 is still the adopted standard in § 162.1302. CMS says HHS won't enforce HIPAA Administrative Simplification against covered entities that run an all-FHIR Prior Authorization API without the 278, so some payers may offer FHIR alone. Confirm with each payer which it supports.

Missing the answers your product can't get over EDI?

Champ automates portal and phone work, like eligibility checks and authorizations, behind your product. We set it up and run it, so your team and your users see only the finished results. If thin 277s and portal-only answers are holding your product back, learn more here.

This post is general information, not legal, compliance or billing advice. Rules vary by payer and change often, so confirm with each payer or your clearinghouse before acting. Champ is not affiliated with or endorsed by CMS, HHS, UnitedHealthcare, Availity, CAQH or X12.