Eligibility
Eligibility answers a narrow question at check-in: is this beneficiary currently eligible with this payer? Catching a not-eligible beneficiary before care is one of the main ways pre-attendance prevents downstream glosas.
Like everything else in this flow, eligibility is informational — a not-eligible result produces a warning, never a block. The reception user can still confirm the pre-appointment.
MVP scope
The first release is deliberately narrow:
| In scope (MVP) | Out of scope |
|---|---|
| Beneficiary status only — eligible / not eligible, via the payer's web service | DUT criteria (who/when/under which circumstances a treatment is covered) |
| A limited set of pilot payers | Carência (waiting periods) |
| Today's and past appointments only | Contractual coverage and usage limits |
A later delivery integrates eligibility via Bionexo and broadens coverage. Until then, treat eligibility as a beneficiary-status signal, not a full coverage check.
How it's surfaced
Eligibility is not a separate endpoint you call — and today it is not readable in detail either. The check runs against the pre-appointment, but the only thing the API exposes is a boolean flag telling you whether the check has run, not what it returned:
GET /v1/checkin/appointments/{id}— returnseligibility_checked(true/false).GET /v1/checkin/appointments?eligibility_checked=true— filters the list by that same flag.
The detailed outcome (an eligibility status and the details of the check) is stored internally but is not projected into any API response, so an integration cannot act on the result yet. Treat eligibility_checked as "the check has run" and surface it as such.
Because the MVP only covers today's and past appointments, eligibility_checked may stay false on a future-dated appointment.
DUT, carência, contractual coverage and usage limits are explicitly out of the MVP. If your integration needs those, they belong to a later delivery — plan around beneficiary status for now.