Eligibility & Benefits

Know coverage before the visit.

Verify coverage, parse benefit detail, and return copay, deductible, out-of-pocket, network, and coverage status before the patient arrives.

Browser-based, no API required.

Eligibility is not just active or inactive. Staff still have to interpret benefit text, find the right service category, calculate patient responsibility, and copy results into the next system.

Workflow context

These workflows commonly involve clearinghouse portals, payer eligibility portals, regional health-plan verification systems, and customer scheduling or intake queues.

Coverage confirmed. Before the patient arrives.

Asteroid runs the eligibility check, parses the response, and returns structured benefit data — coverage status, network, copay, deductible, OOP, and covered service categories — ready for downstream workflows.

What Asteroid returns

• ✓Active / inactive coverage status
• ✓Plan and network detail
• ✓Copay by service type
• ✓Deductible met / remaining
• ✓Out-of-pocket max met / remaining
• ✓Covered service categories
• ✓Source timestamp and evidence
• ✓Exception queue for unclear or missing benefit data

Before

• –Log into payer or clearinghouse portals
• –Interpret messy 271 benefit responses
• –Find copay, deductible, and OOP fields
• –Copy results into scheduling or billing
• –Recheck when data is missing or unclear

After · with Asteroid

• ✓Submit patient and visit once
• ✓Eligibility checks run automatically
• ✓Benefit details are parsed
• ✓Patient responsibility is structured
• ✓Exceptions route for review

Workflow templates

These reusable workflow templates can be configured around your payer mix, visit types, service categories, portal accounts, review rules, and output format.

Frequently asked questions

We already receive 270/271 responses. What gap does this fill?

The 271 confirms coverage is active; it rarely returns the benefit detail the front desk actually needs (copay for the specific service, remaining deductible, out-of-pocket accumulation, network status), and it misses the regional, Medicaid, and behavioral-health plans clearinghouses don't reach. That's the part that is still a portal login today. Agents pull the full benefit detail from the portal and return it alongside your existing feed.

How are benefit details normalized across clearinghouses and payer portals?

Every source maps to one result schema you define: the same copay, deductible, out-of-pocket, and network fields whether they came from a 271 or a portal screen-read, with the source recorded on each field so differences stay visible instead of being averaged away. Service-specific detail is pulled for the visit types you configure. When a portal presents a benefit the schema doesn't model, the field comes back flagged rather than silently dropped.

What happens when the response is incomplete, ambiguous, or conflicts with another source?

Ambiguity stops the run rather than shipping a guess. An incomplete or internally conflicting benefit answer routes to a person with both sources' raw responses attached, so staff resolve it once with evidence instead of re-running the check.

What happens when a payer portal or benefit layout changes?

The agent reads the page as it renders on each run, so layout changes are absorbed rather than breaking a recorded path. If a redesign genuinely removes or relocates a benefit the workflow needs, the run stops with the change identified, and maintenance is Asteroid's job, not a script your team owns.

How are PHI, credentials, evidence, and audit history handled?

Checks run on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, using your portal logins with least-privilege scoping you can rotate or revoke. Each check leaves a per-execution record: what was queried, what came back, the source evidence, and a timestamp.

What if a regional plan or portal we need is not in the library?

Regional plans are the reason this category exists, so adding one is routine: scope it against a worked example in the builder, or hand it to Asteroid to run managed. Coverage is chosen by your payer mix, not by what a clearinghouse happens to support.