Home/Technology/Eligibility AI Engine

continuous · sub-300ms P95 · 1,200+ payer adapters

Continuous eligibility, not point-in-time.

Coverage changes mid-cycle every day. Patients switch employers, age into Medicare, hit deductibles, get terminated by Medicaid redetermination. Point-in-time eligibility misses all of it. Our engine runs 270 transactions on a sweep cadence so the active benefit at the date of service is the one used. 99.4 percent intake catch on the active book.

Get a free coverage audit → See the engine

Sweep cadence T-7, T-1, day-of, post-claim Mid-cycle change detection Deductible-reset tracking

The sweep cadence

Four checks. Every visit.

Point-in-time eligibility breaks every time coverage changes between scheduling and the date of service. The cadence on the right is what makes the difference. T-7 days catches plan switches at open enrollment and job changes. T-1 day catches Medicaid redetermination and termination notices. Day-of catches walk-ins and last-minute changes. Post-claim catches the few that slipped, with enough time to correct the claim before submission.

Cache freshness is keyed per payer per benefit category. Commercial benefits cache for 24 hours; Medicaid for 12; Medicare Advantage for 48. The freshness window balances 270 transaction cost against the risk of acting on stale benefits. The sweep ensures the day-of-service benefit is always fresh regardless of cache.

Eligibility sweep · per scheduled visit

T-7d

Pre-visit sweepCatches plan switches, job changes, open enrollment

280msP95

T-1d

Day-before re-verifyCatches Medicaid redetermination, termination

280msP95

T-0

Day-of registrationLive 270 at the front desk, walk-ins included

280msP95

T+1d

Post-claim sweepCatches the 0.6% that slipped, correct before submission

280msP95

Cache: commercial 24h · Medicaid 12h · MA 48h · sweep overrides cache

What the front desk sees

Per-CPT benefit detail. Before the visit.

The eligibility result, parsed into actionable fields. Not the raw 271 X12 segment. The front desk sees the active payer, the policy state, the deductible remaining, the copay due, the prior-auth requirement per CPT, and any mid-cycle change since last verification. One screen, every visit.

Eligibility · Patient ID redacted · DOS 2026-06-19 · Anthem BCBS PPO

Coverage status

Verified 11 minutes ago · sweep T-0

Policy state

Active

Plan year

2026 (reset 01/01)

Deductible remaining

$1,247 of $2,500

OOP max remaining

$4,890 of $7,500

CPT 99213 · office visit

$30 copay

CPT 73721 · MRI knee

Prior auth required

Mid-cycle change

None since T-7

Coordination of benefits

Primary (no secondary on file)

The capabilities

Six capabilities. One adapter library.

Each capability runs through the same payer adapter library and the same sweep scheduler. The library is what makes the 1,200-payer count real and the latency consistent across commercial, Medicaid, Medicare, and Medicare Advantage.

01 · 270/271 protocol

X12 over EDI, the right way.

Real 270 transactions, parsed 271 responses, structured into actionable fields. Not a wrapper around a clearinghouse portal. Edge gateway, payer adapter, response parser, and benefit-category normalization all in our stack so the response shape is consistent across payers regardless of source.

02 · Payer adapter library

1,200+ adapters, mostly EDI.

Roughly 1,200 payer adapters in production. EDI clearinghouse routes for most, payer-direct portal scrapes for the small minority of Medicaid plans without a 271 endpoint, FHIR Coverage and CoverageEligibilityResponse where the payer offers it. Same library our certified specialists work from, applied deterministically.

03 · Mid-cycle change detection

Delta detection, every sweep.

Every sweep compares the new 271 against the cached benefit on file. A delta on policy state, benefit category, prior-auth requirement, or deductible triggers a re-verification workflow and flags the upcoming claim before submission. Biggest recoveries on FQHC and behavioral-health books where Medicaid redetermination cadence is the leak.

04 · Deductible reset tracking

Reset date, plan-year aware.

Deductibles reset January 1, on plan-year anniversaries, or fiscal-year dates. The 271 carries the remaining amount but not the reset date directly. We carry the reset date in the adapter library and surface a warning on every claim that crosses the boundary so patient responsibility stays accurate. Reduces the single most common post-year-end statement complaint.

05 · Prior-auth surfacing

Policy library, per CPT.

The 271 often does not carry prior-auth requirements directly, so we cross-check the procedure code against the payer's active medical policy library at the moment of verification. The eligibility result surfaces the requirement, the documentation needed, and the route. Feeds the prior-auth automation workflow before the visit, not after the denial.

06 · Cache + freshness window

Per-payer, per-category.

Cache freshness keyed per payer per benefit category. Commercial 24h, Medicaid 12h, MA 48h. Repeat queries within the window do not re-hit the payer. Out-of-window responses expire and a fresh 270 fires. The sweep overrides cache so the day-of-service benefit is always fresh regardless of upstream cache state.

How a visit runs

Four steps. Coverage gap closed.

From scheduling to claim submission. The engine handles the protocol, the adapter library handles the payer differences, and the sweep cadence handles the time dimension. Below is the workflow per scheduled visit.

Step 01

Schedule triggers sweep.

EHR scheduler push enqueues the visit for the T-7 sweep. Payer adapter loads, benefit category resolves, 270 fires. Response parses, normalizes, and posts to the patient record. Front desk sees coverage status before the visit week opens.

Step 02

Pre-day re-verify.

T-1 sweep re-runs the 270. Delta detection compares against the T-7 cached benefit. Any change in policy state, prior-auth requirement, or deductible flags the visit. Re-verification workflow runs if delta detected.

Step 03

Day-of registration.

Live 270 at the registration desk completes in sub-300ms P95. Walk-ins and last-minute changes verified before the visit starts. Copay and deductible surfaced to the front desk so point-of-service collection is accurate. Prior-auth flag visible if required.

Step 04

Post-claim sweep.

T+1 sweep catches the small percentage of cases that slipped (after-hours arrivals, emergency walk-ins). Correction routes back through claim before submission. Same audit trail per verification, same adapter library, same latency.

What clients see

Measured outcomes from continuous eligibility.

Across our active book. Anonymized; individual results depend on payer mix, scheduling cadence, and pre-engagement baseline. The numbers below are honest measurement, not headline.

99.4%

Intake catch rate

Patients arriving with verified eligibility on file at registration. The remaining 0.6 percent are walk-ins, after-hours arrivals, and emergencies. Every uncaught intake is a future denied claim or write-off. Catching the gap before the visit is what turns front-end work into back-end revenue.

280ms

P95 response latency

95th-percentile response time edge to payer adapter and back. Clearinghouse average is 2.4 seconds. The 8x difference is what makes live registration verification work without breaking the front-desk workflow. The patient at the counter does not wait.

70%

Eligibility-denial reduction

Drop in eligibility-category denials against pre-engagement baseline on the active book. Driven by mid-cycle change detection on the T-1 sweep and the prior-auth surfacing at T-7. Largest impact on FQHC and behavioral-health books where Medicaid redetermination drives volume.

Common questions

Frequently asked: continuous eligibility.

What is continuous eligibility and why does it matter?

Point-in-time eligibility checks coverage at one moment, usually at scheduling or registration, and assumes that snapshot holds through the date of service. It does not. Patients lose coverage mid-cycle, switch employers, age into Medicare, hit deductibles, and get terminated by Medicaid redeterminations every day. Continuous eligibility re-runs 270 transactions on a sweep cadence (T-7, T-1, day-of, post-claim) so the active benefit at the date of service is the one used. The cadence is the difference between catching a coverage change before billing versus after a denied claim.

What does sub-300ms P95 mean in practice?

The 95th-percentile response time for a 270 transaction through our edge gateway to the payer adapter and back is under 300 milliseconds. That matters because the front desk runs eligibility live at registration, not in a nightly batch. The patient is standing at the counter. A check that takes 6 seconds breaks the workflow; a check that returns before the registration screen finishes loading does not. Our cache layer holds responses with a freshness window keyed per payer per benefit category, so repeat queries within the window do not re-hit the payer.

How many payers are connected and how?

Roughly 1,200 payer adapters in production. Most are X12 270/271 over EDI clearinghouse routes. The rest use payer-direct portal scrapes (a small minority, kept current because some Medicaid plans never published a 271 endpoint) or FHIR Coverage and CoverageEligibilityResponse resources where the payer offers them. The adapter library is the same library our certified eligibility specialists use, applied deterministically at the moment of query.

What is the 99.4 percent intake catch?

99.4 percent of patients arriving for a scheduled visit have an eligibility verification on file at registration. The other 0.6 percent are walk-ins, after-hours arrivals, and emergencies where the 270 had not yet run. The catch rate matters because every uncaught intake is a future denied claim, write-off, or patient-statement collection problem. Catching the coverage gap before the visit is what turns front-end work into back-end revenue.

What is mid-cycle change detection?

Most coverage changes do not happen at the start of the year. Job changes, marriage, Medicaid redetermination, COBRA conversion, plan switches at open enrollment, and termination all happen on rolling dates. Mid-cycle detection runs a 270 sweep at intervals (T-7 pre-visit, T-1, day-of, and post-claim) and compares the 271 response against the cached benefit on file. A delta triggers a re-verification workflow and a flag on the upcoming claim before submission. Recoveries are largest on FQHC and behavioral-health books where the Medicaid redetermination cadence is the biggest source of preventable denials.

How does deductible reset tracking work?

Deductibles reset January 1 for most commercial plans, on the plan-year anniversary for self-funded employer plans, and on the fiscal-year date for some Medicare Advantage. The 271 carries the deductible remaining, but not the reset date directly. We carry the reset date in the payer adapter library and surface a warning on every claim that crosses the reset boundary so patient responsibility calculations remain accurate. The single most common patient-statement complaint after a plan year ends is the unexpected deductible reset; surfacing it pre-visit reduces inbound calls materially.

What about prior authorization requirements?

The eligibility response often does not carry prior-auth requirements directly, so we cross-check the procedure code against the payer's active medical policy library at the moment of verification. If a prior auth is required, the eligibility result surfaces the requirement, the documentation needed, and the route. That flag feeds the prior-auth automation workflow before the visit, not after the denial. Same payer rule library used for both products.

What is the cache freshness window?

Cache freshness is keyed per payer per benefit category. Commercial benefits cache for 24 hours; Medicaid for 12 hours given the redetermination cadence; Medicare Advantage for 48 hours. The freshness window balances the cost of repeat 270 transactions against the risk of acting on stale benefits. Any response cached over the window expires and a fresh 270 fires. The sweep cadence ensures the day-of-service benefit is always fresh regardless of the cache.

Pairs with

Where the eligibility engine compounds.

The engine reaches further when paired with the rest of the stack. Three places it lifts hardest.

Prior auth AI

Same payer rule library, applied at auth.

The prior-auth requirement surfaced at eligibility feeds the auth automation workflow before the visit. TAT compressed from 8 days to 32 hours median, 89 percent initial auto-approval on the active book.

Active payer at the date of service.

The coding engine needs to know the active payer and benefit at the date of service. Continuous eligibility provides the authoritative input. Payer-specific coding rules apply against the verified benefit.

Provider-payer enrollment, kept current.

Eligibility surfaces the active payer; CredPro v6 surfaces whether the rendering provider is enrolled with that payer. Mismatch flags the claim before submission. Same audit-trail discipline across both systems.

Send 30 days of eligibility denials. We send back the coverage map.

A free 30-day eligibility audit. Drop your last 30 days of denied claims and eligibility-related write-offs. We return a four-page audit covering eligibility-category denials by payer, mid-cycle changes you missed, prior-auth surfaces that would have caught the denial, and a 90-day fix plan. An ASP-RCM senior partner on the call.

Get my free coverage audit See prior-auth AI