Covered?
Most systems answer well
- Active coverage, copay, deductible from the 270/271
- The HIPAA inquiry and response pair every system runs on
Home / White papers / Eligibility and prior authorization
White paper · Front-end revenue cycle
Automated eligibility verification systems: the 2027 buyer's guide
Short answer: score eight criteria from 0 to 3 on your own payer list, weighted toward 270/271 depth and thin-271 handling. In 2027 the authorization question gets a new source, the CMS-0057-F Prior Authorization API from January 1 [1]; a system bought for 2024 cannot consume it.
8 criteria · weighted scorecard270/271 · service types namedFallback: API, voice, portalJan 1, 2027 · CMS-0057-F API
Edition
1 · 2027
Focus
Eligibility
Audience
CFO · RCM · IT
Metric
8 criteria
Payers
1,300 of 3,662 real-time
Length
14 min
11%
Share of general 270 inquiries that returned physical therapy benefits across 791 stored 271 responses on our desk; authorization indicator 0%
23% to 0
Second billed call per verification before and after naming every service type in one 270, measured on our stack
Jan 1, 2027
Prior Authorization API required of Medicare Advantage, Medicaid, CHIP and exchange QHP payers under CMS-0057-F [1]
1,300of 3,662
Payers on one clearinghouse network that support real-time eligibility (July 2026); 636 support claim status
Three questions before the visit, one new data source
Written for the people who sign the purchase order and the people who live in the queue: the transaction, the thin-271 problem, the fallbacks, the API data arriving in January, and a scorecard to put in front of any vendor, including us.
What do they owe?
Answered unevenly
- Service-type benefits, accumulators, network tier
- Only when the 270 names the service type and the payer populates it
Authorization required?
Answered badly
- From January 1, 2027 the CMS-0057-F API lists covered services, documentation requirements and decisions for impacted payers [1]
- A 2027 system must consume that answer
Three checkpoints
The cadence CorePulse runs
- Scheduling, 72 hours out, check-in
- Decision clocks of 72 h and 7 days already in force [1]
What to score, and its weight
Scorecard weights, 100 points across eight criteria
Weights reflect where the money leaks for a multi-site group; adjust for your mix.
1. 270/271 depth
20%service types and second-call rate
2. Thin-271 handling
20%verified, not stated, conflict
3. Fallback ladder
15%transaction, API, voice, portal
4. Prior authorization readiness
15%impacted payers, API, clocks
5. Benefit maxima and accumulators
10%per service type, as-of date
6. Network coverage
10%your payers that answer
7. Exception handling
5%evidence attached
8. Security posture
5%stated plainly
05101520%
Transaction and data criteriaNew in 2027Operating criteria
270/271 depth, not just connectivity
A 270 carries service type codes; a 271 returns benefit segments per service type. Therapy and procedure-level benefits have to be requested by name; on our stack that took the second billed call from 23 percent of verifications to 0.
How often a general 270 returned the specialty benefit
791 stored 271 responses, our own desk, August 2026. A system that sends a generic request and parses active coverage, copay and deductible is confirming the patient has a card, not verifying the visit.
Dental benefits
90%712 of 791
Mental health benefits
84%664 of 791
Physical therapy benefits
11%87 of 791
Authorization indicator
0%0 of 791
025%50%75%100%
Returned reliablyReturned oftenMust be requested by name
The thin 271, and what the system shows instead of a false yes
Payers meet the letter of the HIPAA standard and still return missing or ambiguous fields. The expensive failure is a parser that fills the gap with a value that looks real. Each guard is now tested against deliberate corruption of the input.
Verified
State 1
- The payer stated the value in the 271
- Show it with the timestamp
Not stated
State 2
- The payer returned nothing for that field
- Show VERIFY and route it, never a default
Conflict
State 3
- Two segments disagree, or in- and out-of-network amounts are mixed
- Hold the quote for a person
| Fabrication found in 12,484 parsed rows, our stack | Before the fix | After |
|---|---|---|
| Out-of-pocket maximum recorded as $0 the payer never stated | 10,574 | 0 |
| Deductible filled with no payer value | 9,139 | 0 |
| Copay shown as $0 with no payer value | 2,729 | 0 |
| In-network and out-of-network amounts mixed | 4,122 | 0 |
TakeawayAsk to see the system's handling of a thin 271 on a live payer. If every field has a number, ask where the numbers came from. A $0 out-of-pocket maximum tells the front desk to collect nothing; that is how a thin 271 becomes a write-off three weeks later.
Fallbacks, in the right order
Each step costs more than the last. Our voice versus 270 routing guide puts the rule in one line: send the 270 first, call when the 271 comes back thin.
RouteBest for, and limitsWhat the system must record
X12 270/271First, always
Best forActive coverage, copay, deductible, accumulators, named service types. Limit: payer-dependent depth; auth flags rarely returned
RecordRaw response, timestamp, service types requested
Payer APIFHIR, impacted payers from 2027
Best forWhether an authorization is required, documentation requirements, request status. Limit: impacted payers only; drugs excluded [1]
RecordAPI response and the payer's stated end date or denial reason
Voice callAgent or staff
Best forCPT-level authorization rules, visit limits, policy questions. Limit: slow; quoted values must reconcile to the 271
RecordCall reference, representative, every quoted field
Payer portalLast
Best forPayers with no real-time connection; document uploads. Limit: manual, fragile, unlogged unless the system logs it
RecordScreenshot or structured capture with time
ReconciliationOur stack runs the voice lane and the 270/271 lane on the same member and holds any quote where the spoken benefit and the machine-readable response disagree; see the voice agent reconciliation post. A vendor that cannot show the reconciliation step is asking you to trust a phone call.
Prior authorization data arriving in January
From January 1, 2027 impacted payers must run an API that lists covered items and services, identifies documentation requirements and returns approvals with an end date, denials with a specific reason, or requests for more information [1]. CMS tells providers to request authorizations electronically from that date and to confirm EHR vendor readiness, roadmap, integration and any module costs [2].
- 1Final rule releasedJan 17, 2024CMS-0057-F [1]
- 2Clocks startJan 1, 202672-hour and 7-day decisions; specific denial reasons
- 3Metrics postedMar 31, 2026First public prior authorization metrics on payer websites
- 4APIs requiredJan 1, 2027Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs
- 5MIPS measureCY 2027Electronic Prior Authorization measure, first performance period
How far the 271 alone gets you on the authorization question
A 35-patient physical therapy file, our own desk, August 2026. The system should show you this split, not a single yes or no.
271 alone
6 of 3517%
271 + precedence resolverpayer rules layered on top
24 of 3569%, high or medium confidence
Routed to named payer portal
11 of 3531%
010203035
271 aloneResolverPortal hand-off
| Question for the vendor | Good answer |
|---|---|
| Which of my payers are impacted payers under CMS-0057-F, and which are commercial plans outside the rule? | A list by payer, maintained |
| Can the system consume a Prior Authorization API response and store the end date and denial reason? | Yes, with the HL7 Da Vinci CRD, DTR and PAS guides named [2] |
| For non-impacted payers, where does the auth-required answer come from? | A payer rule table with a source and a review date, or a logged call |
| Does it time-stamp request and decision so the 72-hour and 7-day clocks can be enforced? | Yes, per request |
| Are drug authorizations handled separately? | Yes; drugs are excluded from the CMS-0057-F API and are the subject of a separate proposed rule |
Benefit-maximum and accumulator tracking
Therapy, behavioral health and chiropractic practices live and die by visit limits. Our stack runs three checkpoints per visit and the engine sweeps on a T-7, T-1, day-of and post-claim cadence with cache freshness per payer, as described on our eligibility engine page. Cadence matters more than latency, because coverage changes between scheduling and the date of service.
- 1T-7schedulingSweep; remaining visits and dollar maxima stored per service type with the payer's as-of date
- 2T-172 hours outRe-verify; your consumed-visit count shown next to the payer's number
- 3Day ofcheck-inRe-verify when remaining count is below your threshold; coordination of benefits surfaced
- 4Post-claimreconcilePlan-year reset dates captured; a January 1 reset is where accumulators silently go wrong
Network coverage, stated honestly
Payer identification is the other quiet failure: the same payer carries different identifiers across clearinghouses, and a collision sends the 270 to the wrong endpoint. Ask the vendor how it resolves your payer list specifically, and what percentage resolves without a human.
One clearinghouse network, July 2026: payers listed versus payers that answer
The headline number was 3,662. The useful number for a therapy group was closer to a third of that.
3,662
Payers listedheadline
1,300
36%
Support eligibility270/271
636
17%
Support claim status276/277
626
17%
Support both
ListedReal-time transactionsBoth
Payer names with an actionable label, beforeAlias index across 17 client payer lists
After rule-driven mappingResolvable identifiers rose roughly fourfold
Exceptions go to people, with the evidence attached
Our eligibility verification workbench runs every scheduled patient through the sweep, writes clean results back, and routes only the exceptions to a person, with the parsed 271 and the raw response alongside.
Eligibility automation baseline on a multi-clinic physical therapy network, 2,397 accounts after nine weeks
A vendor that reports only the automated percentage is hiding the denominator.
Fully automated
56%about 1,342 of 2,397
Medicare attestation step
34514%
Client data problemswrong member ID and similar
25711%
Engine defects we owned
23710%
True non-coverage
793%
Workflow gaps
673%
Portal-only payers
120.5%
06001,2001,8002,397
AutomatedException, external causeException, oursOtherPortal only
| Field on the exception record | Why |
|---|---|
| Reason category (payer rejection, not stated, conflict, no connection, data error) | So the fix is applied to the rule, not the account |
| Raw 271 or API response and the request that produced it | Audit trail and payer dispute evidence |
| Fallback already attempted and its result | No one repeats a call the system already made |
| Owner and due time relative to the visit | The visit is the deadline |
| Resolution written back to the PM or EHR | The front desk sees one answer, not two systems |
Security and privacy posture
Authentication
- How the system authenticates to clearinghouses and payer APIs
Retention
- How responses are stored and for how long
Access
- Who can see raw responses; how access is logged
Assessments, not logos
- The vendor's own assessments in writing
- Our stack is designed to support HIPAA-aligned controls; company audits and memberships are separate facts from software posture, and any vendor that blurs the two should separate them in writing
Score 0 to 3 on demonstrated evidence
A 3 means you watched it happen on a live payer from your own list. A 0 means the vendor could not show it.
| Criterion | Weight | Evidence that earns a 3 |
|---|---|---|
| 1. 270/271 depth | 20% | Service types per payer and second-call rate measured on your payers |
| 2. Thin-271 handling | 20% | Verified, not stated and conflict states shown; no fabricated zeros on a live thin response |
| 3. Fallback ladder | 15% | Transaction, API, voice, portal in order, with reconciliation between voice and 271 |
| 4. Prior authorization readiness | 15% | Impacted-payer list, API consumption, time-stamped clocks, drugs separated |
| 5. Benefit maxima and accumulators | 10% | Per service type with as-of date, your consumption alongside, cadence re-verification |
| 6. Network coverage | 10% | Your payer list resolved, with the percentage that answers eligibility and claim status |
| 7. Exception handling | 5% | Reason categories, raw evidence, owner and due time, write-back |
| 8. Security posture | 5% | Authentication, retention, access logging and assessments stated plainly |
Takeaway
Give every vendor the same 50 scheduled patients across your top ten payers and watch the sweep run. Count fields verified, fields unverified, fields wrong, and minutes of human time. The scorecard follows from those four numbers.
Run the scorecard, against our stack or anyone else's
Pull 50 scheduled patients across your top ten payersThe same file for every vendor, including us.
Tag each payer impacted or not under CMS-0057-FThe authorization column depends on it.
Watch a live thin 271If every field has a number, ask where the numbers came from.
Ask for the exception denominatorAutomated share and every exception cause, not the percentage alone.
Ask the EHR vendor about API consumption and costCMS says to confirm roadmap, integration capability and any upgrade or module costs [2].
Read the companion piecesOur API, voice and portal sequencing guide, the Front Office Operator issue on January 1, and the CMS-0062-P drug proposal. We run eligibility and benefit verification as a service for therapy networks, FQHCs, behavioral health and ABA on the AI suite.
Frequently asked questions
What should an automated eligibility verification system check beyond active coverage?
The benefit for the specific service type being scheduled: copay, coinsurance, deductible and out-of-pocket remaining, remaining visits or dollar maxima, network status, coordination of benefits, and whether an authorization is required. A general 270 often omits specialty benefits; on our desk a general inquiry returned physical therapy benefits only 11 percent of the time, so service types have to be named in the request.
What is a thin 271 and why does it matter?
A 271 response that meets the HIPAA standard but leaves benefit fields unstated or ambiguous. The danger is a system that fills the gaps with defaults such as a $0 out-of-pocket maximum, which tells the front desk to collect nothing. A good system shows three states: stated by the payer, not stated, and conflicting, and routes the last two to a fallback.
How does CMS-0057-F change eligibility verification in 2027?
From January 1, 2027, Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans and exchange QHP issuers must run a Prior Authorization API that lists covered services, identifies documentation requirements and returns approvals with an end date, denials with a specific reason, or requests for more information. An eligibility system can use that API to answer whether an authorization is required for impacted payers. Drug prior authorizations are excluded.
Should the system call payers by voice?
Only after the transaction. Send the 270 first; use a voice call, automated or human, when the answer lives outside the 271, such as CPT-level authorization rules or visit limits, or when the payer has no real-time connection. Every spoken value should reconcile to the 271 before it is quoted.
How do I compare vendors fairly?
Give each the same 50 scheduled patients across your top ten payers, watch the sweep run, and count fields verified, fields marked unverified, fields that were wrong, and minutes of human time. Score the eight criteria in this guide from that evidence rather than from a demo.
- CMS fact sheet, CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), January 17, 2024: impacted payers, API requirements and dates, decision timeframes, metrics, drug exclusion
- CMS, Electronic Prior Authorization overview (page updated October 21, 2026): provider steps, request authorizations electronically beginning January 1, 2027, Da Vinci test kits
- CMS, Interoperability and Prior Authorization Final Rule (CMS-0057-F) policy page: compliance dates and X12 278 enforcement discretion
Checked October 25, 2026. Rules change; confirm against the source before relying on them. Figures described as measured on our desk or our stack are internal operating measurements from 2026 and are not client outcomes or guarantees.
CapabilityAI eligibility verificationEngineEligibility engine: sweep cadence and 270/271SuiteThe ASP-RCM AI suiteBlogAutomated prior authorization 2027: API, voice or portalNewsletterThe CorePulse Brief: prior auth API day oneInsightCMS-0062-P: drug prior authorization API by October 2027White paperThe eligibility-first revenue defense
Want the scorecard run on your own payer list?
Bring 50 scheduled patients across your top ten payers. We run the sweep, show every field as verified, unverified or wrong, and hand you the scorecard, whichever system you end up choosing.