Run an eligibility check or sweep

Outcome

A real-time confirmation that the payer recognizes a member and will cover a service date — for one member or for an entire roster — with the result attached to the member's coverage record so claims will not be rejected for lack of eligibility.

Prerequisites

Scope	What it lets you do
clinical.eligibility.read	View results
clinical.eligibility.run	Submit 270 transactions

A trading partner with the 270 capability (5.6 — Trading partner credentials). Without it, the platform falls back to manual entry of the response.

Real-time vs. batch sweep

	Real-time	Batch sweep
Volume	1 member	1–10,000 members
Latency	Seconds	Minutes
Scheduling	On demand	Cron or manual
Best for	Pre-visit verification, COB question	Monthly roster refresh, intake of new members

Real-time check

/eligibility opens a search panel. Pick:

Field	Notes
Member	Search by name / MRN.
Payer	Defaults to the member's primary coverage.
Service date	Defaults to today.
Service type	Defaults to 30 - Health Benefit Plan Coverage.

Click Submit 270. The platform composes the 270, sends it to the payer through the routing rule, and parses the 271 response into a structured panel:

Section	Meaning
Subscriber confirmation	Names match? DOB matches?
Plan effective dates	When this plan is active.
Coverage details	Per service-type breakdown.
Cost shares	Deductible YTD, copays, coinsurance.
Other coverage	Additional payers the payer knows about (used for COB).
Errors	If 271 is AAA (rejection), the reason.

Save the response → it lands on the member's Coverage tab as the latest eligibility check, with a timestamp.

Batch sweep

/eligibility/sweeps. A sweep runs a batch of 270s through the partner.

1. Click + New sweep. Pick a roster source:

   • All active members — fires for every active member.
   • Members on a facility — narrows by facility.
   • Members on a coverage policy — re-verifies one payer's roster.
   • Upload CSV — list of MRNs.

2. Set the schedule: run now or schedule a recurring cron (e.g. monthly, on the 1st).

3. Click Submit. The sweep enters RUNNING.

4. Open the sweep detail at /eligibility/sweeps/:id to watch progress. The page shows:

   • Total members, processed, succeeded, failed.
   • Members whose coverage changed (membership ended, new plan, COB detected). These are surfaced for review.

5. Triage changes. The sweep does not auto-edit coverage. Each delta appears as a row with Apply / Reject / Investigate:

   Delta	Action
   Coverage termed	If the payer says termed, the member's coverage policy is moved to Termed.
   New plan detected	Add as new coverage with the appropriate priority.
   Other-payer detected (COB)	Add as additional coverage; the platform will run COB on the next claim.

6. Apply changes. Audit-logged per row.

Validation

Check	Expected
271 response visible within seconds (real-time)	Yes (clearinghouse latency varies).
Sweep completes within an hour for 1,000 members	Yes; depends on partner throughput.
Coverage delta rows have a clear before / after	Yes.
Applied deltas update member coverage immediately	Yes.

Troubleshooting

Symptom	Cause	Fix
271 returns AAA - Subscriber not found	Member ID typo, or coverage not yet effective	Confirm the member ID; check the date relative to the plan's effective window.
Sweep stuck in RUNNING for hours	Partner throughput cap or outage	Open the sweep → click Pause; resume after the partner's status page clears.
271 response missing cost-share data	Some payers do not return cost shares on a generic 270	Run a service-type-specific 270 (e.g. 47 - Hospital).
Delta misclassifies "new plan" when it is really a payer name change	Payer's 271 changed display name	Add the new name as an alias on the existing payer (5.1).

Next

3.5 — Per-diem & institutional billing