The problem
A lot of the accounts sitting in your self-pay and uninsured queue are not actually uninsured. Medicaid redetermination churn, high-deductible plans, and plain paperwork mean patients show up presenting as self-pay while they quietly still carry active coverage (Medicaid, Medicare, or a commercial plan). Those accounts drift toward bad-debt and charity-care write-off, and the revenue that was billable the whole time walks out the door.
The usual fix (a batch coverage-discovery vendor) is an opaque black box, bills you per hit, and shows no work, so you cannot defend a result or tell a false positive from a real one.
How it works
You hand us demographics only (name, date of birth, and optionally SSN), with no member ID. From there the discovery span does the work:
- looks up the payer-policy context for the roster it is about to probe,
- fans a read-only eligibility probe across a declared payer roster (Medicaid, Medicare, and the major commercial payers) using a demographic 270 inquiry, with a FHIR Coverage read as fallback,
- re-verifies every candidate hit as actually active and billable (not just a name match),
- aggregates and dedups the verified hits across payers and ranks them by billability confidence,
- renders a found-coverage report, with PHI de-identified on the way out.
The whole thing is composition on AYA's verification spine (six existing capabilities wired together as data, no bespoke black box), and it fails closed without a consent token, so nothing runs on a patient you were not authorized to check.
What you get
A found-coverage report per account: the ranked list of active coverage discovered from demographics (payer, plan, effective dates, and a billability-confidence score), each hit re-verified as active, PHI de-identified on egress. In plain terms, a billable-coverage worklist instead of a write-off queue, and a result you can actually defend line by line.
Who it is for
Hospital and health-system revenue-cycle teams, self-pay and financial-clearance departments, patient-access groups, and the eligibility and RCM vendors that serve them. It lands hardest where Medicaid churn and high-deductible volume have swollen the self-pay bucket, and it sits right next to the Luigi eligibility and prior-authorization work already in the healthcare line.
Pricing
Pricing is a set of hypotheses we are validating, not a committed price sheet.
- Batch discovery, priced per account scrubbed or as a flat batch fee (a one-time pass over your self-pay worklist).
- Value-metered, a percentage of newly billable coverage you actually recover (you pay on discovered, verified, billable coverage, not on raw probes).
- Platform, continuous discovery wired into registration and financial clearance, so every self-pay account is probed at intake before it can route to write-off.
Proof (dogfood)
We run the discovery span on ourselves first. AYA feeds its own synthetic self-pay roster (demographic-only patient records with no member ID) through the exact deliverable a customer would buy, watches it fan the read-only probe across the default payer roster, verify hits, rank them, and render the report, all as a structural dry run with no live payer call.
What is actually true today: the deliverable pattern (AYA-3SPN-INSURANCE-DISCOVERY-SELF-PAY-v1) is on disk, PQS-scored at 91 (Grade A), and all six of its composed capabilities resolve to existing atoms. The eligibility probe at the center of it is backed by a handler already wired into AYA's task orchestrator, so it is real substrate, not a slide.
Honest note
This is a structural build, not a live-customer result. Two things stand between the dry run and a real batch, and we say them out loud. First, if a given payer's live eligibility adapter hard-requires a member ID and rejects a demographic-only inquiry, that payer needs a small adapter adjustment before it can be probed this way, so we verify against the live adapter before any customer run. Second, real runs need live payer or clearinghouse credentials, consented demographics, and a booted system. Until those are in place, the number that is real is the one above: a built, scored, reference-resolving pattern, dogfooded on synthetic data. We would rather tell you that than sell you a black box.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*