Evaluating eligibility verification platforms. Beyond 270/271.
Most platforms that call themselves "eligibility verification" run an ANSI X12 270 transaction, get back a 271, and hand you the raw response. That is table stakes. A clearinghouse with a UI does the same. Real eligibility platforms do interpretation, continuous monitoring, per-CPT benefit parsing, and Medicaid state adaptation. This guide gives you the 10 questions that separate the two, and the testing protocol that proves it before you sign.
A 271 is a wire response, not an answer.
If a vendor's product description starts and ends with "we run 270/271 in real time," they are selling you a clearinghouse with a login page. That is not enough.
Raw 271 transactions are noisy, lumpy, and often misleading. The ANSI X12 271 standard returns coverage data in loops and segments that vary by payer interpretation. Two payers can return the same benefit using completely different segment structures. A 271 from one Blue Cross plan might detail copay, coinsurance, and deductible cleanly in three separate EB segments. The same response from another Blue plan might collapse all three into one segment with the actual values buried in MSG narrative fields a registrar has to read like prose.
Worse, a 271 returned at scheduling is a snapshot. It says nothing about whether coverage will still be valid on the date of service. It says nothing about whether the specific CPT or HCPCS code you are about to bill is covered, requires prior authorization, or carves out to a different payer entity. It does not catch mid-cycle coverage changes, lump-sum benefit ambiguity, or payer-specific carveouts. A platform that just resells 271 access is a clearinghouse with a UI. The denial rate at the back end tells you so.
Real eligibility platforms do four things a clearinghouse cannot. They parse the 271 across all known payer dialects and normalize the output into a consistent benefit schema. They monitor coverage continuously between scheduling and billing. They adapt to Medicaid state quirks with a maintained state-adapter library. And they resolve to a per-CPT or per-HCPCS coverage answer, not a yes-or-no plan-level answer. If your vendor cannot show you all four behaviors in a live demo on a real registration, you are looking at a clearinghouse.
EB*1**30**HM*GOLD 123**27*1000~ EB*B**30**HM*GOLD 123*29*250~ EB*C**30**HM*GOLD 123*29*80~ MSG*OUT OF NETWORK BENEFITS APPLY~ MSG*BH SERVICES CARVED OUT TO MAGELLAN~ EB*L**30**HM*GOLD 123~ DTP*291*D8*20260101~ DTP*292*D8*20261231~
The catch. A clearinghouse hands you this. A platform reads the MSG segments, recognizes the BH carveout to Magellan, re-routes the verification, parses the in-network vs out-of-network EB rows, and returns a structured per-CPT answer. Same wire response. Different product.
Ten questions. Ask all of them.
These are the ten questions a buyer should put in writing during vendor selection. Each one filters out vendors who are running 270/271 with a brand on top. Demand answers with specifics, not adjectives.
Is it continuous monitoring or one-shot at scheduling?
One-shot at scheduling locks in a result that may not hold at DOS. Real platforms re-verify at scheduling, again 48 hours before DOS, and at billing. Ask for the monitoring cadence in writing.
How do you detect mid-cycle coverage changes?
Termination of employment, plan switch at month-end, Medicaid redetermination. Ask for the specific detection mechanism. Is it batch re-verification, payer feeds, or both?
What is your Medicaid state-adapter library?
50 states have 50 quirks. Ask which states are covered, when each adapter was last updated, and which MCOs each adapter handles. "National Medicaid coverage" without state-by-state detail is bluffing.
What is the p95 and p99 latency?
Sub-second claims are meaningless without tail latency. Average hides the tail; the tail is where your registrar waits at the desk. Demand p50, p95, p99 and the measurement window.
Per-CPT benefits or just coverage yes/no?
Yes/no plan-level coverage is what a 271 gives you. A platform should resolve coverage to the specific CPT or HCPCS you are about to bill, including modifier rules and POS interactions.
How do you handle out-of-network and self-pay?
An OON visit you billed as in-network becomes a denial or a write-off. Ask how the platform detects OON status, whether it routes to self-pay quoting, and how it integrates with your registration workflow.
How is patient responsibility calculated?
Copay alone is not enough. Real platforms calculate copay plus deductible remaining plus coinsurance plus accumulators. Ask whether the calculation uses real-time accumulator data or stale snapshots.
How do you detect secondary and tertiary payers?
Coordination of benefits errors are a top-five denial category. Ask how the platform detects multiple coverage layers, in what order they bill, and whether it pulls Medicare crossover data when applicable.
How does it integrate with my scheduling and registration?
Ask about EHR connectivity (Epic, Cerner, Athena, eClinicalWorks, NextGen), schedule sync cadence, and whether the platform writes back to your registration record or sits in a separate UI.
Rejection rate at registration vs at billing?
The only KPI that matters. After 90 days, what fraction of eligibility-related denials does the platform catch at registration vs let through to billing? Ask for a written commitment and an exit clause if missed.
State Medicaid plans behave wildly differently.
If your book has any meaningful Medicaid volume, this is the section that should drive your decision.
A platform that claims "national Medicaid coverage" without a maintained state-adapter library is bluffing. Each state has its own program structure, its own MCO ecosystem, its own carveout rules, and its own 271 interpretation conventions. The vendor needs a library of adapters, not a single 270 endpoint. Below are four representative states. Walk a vendor through each. If they cannot describe the specific quirks in their own words, they have not built it.
Behavioral health carveout.
- Mental health and SUD services carve out to county Mental Health Plans, not the medical MCO
- 271 from Medi-Cal medical MCO will return BH as "not a covered benefit" even when the member has BH coverage through the county
- Adapter must re-route BH verification to the county MHP
- Whole Child Model adds another layer for CCS-eligible kids
STAR vs STAR+PLUS routing.
- STAR for general population, STAR+PLUS for adults with disabilities, STAR Kids for children with disabilities
- Each program routes to different MCO panels with different carveout rules
- NEMT (non-emergency medical transport) is carved out separately to LogistiCare or MTM
- BH is integrated in STAR but partially carved in STAR+PLUS
HARP and HCBS layers.
- HARP (Health and Recovery Plan) overlay for adults with serious mental illness adds a second eligibility check
- HCBS waiver services have separate authorization and verification flows
- MLTC for long-term care members carves out to different MCO entirely
- 271 conventions for HARP carry status data in MSG segments, not standard loops
SMMC region quirks.
- Statewide Medicaid Managed Care splits the state into 11 regions with different MCO panels per region
- Member can have different MCOs for MMA (medical) and LTC (long-term care)
- Dental carved out to DentaQuest or MCNA depending on plan
- Adapter must resolve to the correct MCO and the correct carveout vendor per service line
Pick the two or three states that matter most to your book and put them in the vendor RFP. Ask the vendor to demonstrate eligibility verification on a real test case with the specific carveouts in play. If they cannot, the platform you are buying does not have a real state adapter library, and your Medicaid book will keep generating the same denials it always has.
One-shot verification misses 4 to 8 percent of denials.
Most eligibility platforms verify once, at scheduling. That is the single biggest gap in the category. Coverage changes between scheduling and the date of service for 4 to 8 percent of visits in most books, depending on payer mix. Employer-sponsored members switch plans at year-end. Medicaid members go through redetermination on a rolling cadence. Marketplace members change plans at month-end. Dependents age off. None of these changes are caught by a one-shot verification done at scheduling.
A real platform re-verifies at three checkpoints: at scheduling, again 48 hours before the date of service, and one more time at the moment of billing. The 48-hour re-verification catches changes in time for the registrar to call the patient, update the registration, and capture point-of-service collections accurately. The at-billing verification catches the last-mile changes that would otherwise become COB denials or termed-coverage denials thirty days later. This is not exotic engineering. It is a basic batch-scheduling pattern. Vendors who do not do it are choosing not to.
We are a vendor too. Here is the honest framing.
ASP-RCM ships an eligibility verification product. We have a horse in this race. We wrote this guide because the buyer questions in it are the same ones our own prospects ask us during due diligence, and we would rather be evaluated against a real checklist than against a brochure. If you read this page and conclude that a competitor does the ten things better, we want you to buy the competitor. If you conclude we do, we want you to pilot us against your real registrations.
If you want to see how ASP-RCM answers the ten questions in this guide, the product page is at /ai/for/eligibility-verification. The technical architecture page covering our 270/271 pipeline, state-adapter library, continuous-monitoring scheduler, and EHR write-backs is at /tech-eligibility. Both pages are written to be useful even if you are evaluating us against three other vendors. We assume you are, because if you are buying eligibility well, you should be.
One thing we will not do is tell you we are right for every book. If your volume is small and your payer mix is narrow, a basic clearinghouse may be the right product for you. If you have meaningful Medicaid managed care exposure, multiple state footprints, or specialty service lines with carveouts, the ten questions above will rule out most clearinghouse-class products quickly. That is the buyer's decision, not the vendor's pitch.
Frequently asked questions: evaluating eligibility platforms.
What is the difference between a clearinghouse and an eligibility platform?
Why does continuous monitoring matter when we already verify at scheduling?
How do I test a platform for accuracy before buying?
What about Medicaid managed care?
Should I pilot on real registrations or on test files?
How fast should eligibility verification be?
What KPIs prove ROI on an eligibility platform?
How does eligibility verification connect to denials?
Get the buyer scorecard. Free.
A two-page scorecard built around the ten questions above, with scoring rubric, a sample vendor evaluation matrix, and a 30-day pilot protocol you can hand to any vendor (us included) to test accuracy on your own registrations. Drop your email, get the scorecard. A senior partner on the call if you want one.