> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.usebridge.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.usebridge.com/_mcp/server.

# Hard Eligibility

The hard eligibility check is done by creating a *Service Eligibility* resource.

### Soft Eligibility

It's not a strict requirement to have run a [Soft Eligibility](/eligibility/api/soft-eligibility) check before this.
However, the Hard Eligibility check will always try to resolve the patient's benefits.
This API has a usage cost, Soft Eligibility does not.
Consider always running Soft Eligibility first, even if the UX does not make a distinction to the patient.

### Patient Input

Use the [Payer Search](/api/api-reference/search/payer-search) API for the Patient's discovery of Payers.
This API is designed to be used to drive autocomplete. An empty string for the query, will return the top national
payers.

Use the accepted list of [States](/api/resources/states).

Patients will need to input the following information.

* First Name
* Last Name
* Date of Birth
* State
* Payer
* Member ID (optional)

Inspect `Payer.memberId` to determine whether to prompt for their Member ID.
Be prepared to prompt for Member ID regardless, if an error code requires it (see below).

### Resolve the Policy

The first step, is to resolve the Patient's `Policy`, using the [Create Policy](/api/api-reference/policies/v-2/create-policy) API.

Whether the benefits are found or not, or if they're active or inactive, the `Policy` object will be created.
Inspect the `status` field, to determine what to do.

* `CONFIRMED` the Policy and benefits were found, move on to the next step. Note, the Policy may be found but with
  inactive coverage.
* `INVALID` the Payer was reached, and the benefits could not be found, review the `errors` (below)
* `PENDING` async policy resolution is in progress. You may proceed to Service Eligibility, but
  you should still resolve the Policy status (poll or listen for `policy.updated`) before
  presenting final eligibility results to the patient.

Other status values (`UNKNOWN`, `REVALIDATING`) are not expected during this flow.

Use polling, streaming, or webhooks and proceed once the status reaches a terminal state.

If the Policy status is `INVALID`, inspect the `errors` field.
See the [Policy Errors](/eligibility/api/policy-errors) for detail.

Note, there are some errors that require you to override a Payer's optional Member ID behavior, and collect it (`72`
and `76`).

### Create the Service Eligibility

*This flow creates an "anonymous" Service Eligibility, untied to a Patient or Service object.
This is the most straightforward use case. If you have a Patient resource already, contact us to discuss
implementation.*

Use the [Create Service Eligibility](/api/api-reference/service-eligibility/v-2/create-service-eligibility) endpoint.
Feed through the Policy ID from the previous step, as a single entry in the `policyIds` array.

> **Cash pay**
>
> If you do not have a Policy (self-pay), you can send an empty `policyIds` array. In that case,
> Service Eligibility will only perform licensing checks.

#### Status

Evaluate the `status` value, we're looking for `ELIGIBLE` to proceed. Given any other value, show appropriate
messages.

* `PENDING` is expected initially while validation is in progress
* `UNINSURED` Policy was found but is not active
* `INELIGIBLE` Policy is active, but the required benefits aren't available
* `INEFFECTIVE` Policy is active, the service is covered, but the date of service falls outside coverage dates

#### Providers

As with Soft Eligibility, the services may be covered by the patient's insurance but your organization may not have
Providers available.
See the `providers` array, there must be at least one to proceed.

> **Supporting multiple Provider types**
>
> If your workflow allows patients to schedule across multiple Provider Types, call the [Create Service Eligibility](/api/api-reference/service-eligibility/v-2/create-service-eligibility)
> endpoint with each Service Type in parallel. Combine the lists of Providers before filtering your
> schedule. This does **not** result in multiple "hard checks", paid requests through to the Payer.

### Estimate

See the `patientResponsibility` field for an estimate and a breakdown. Values are in USD cents. The `total` value is
the amount expected to be paid, other fields describe the split.

The `fallback` values indicate a potentially unknown, or "maximum" amount. Generally, UX should indicate that the
patient's normal copayments, deductibles and coinsurance's apply.

The `oop` values breakdown the waived amounts (the amounts that were calculated, but deducted from the total due to
already-met OOP limits).

In the Sandbox environment, use the [Test Member ID's](/api/resources/testing#service-eligibility) to test out your UI
with all permutations of PR.

### Patients / Services

The above integration does not create Patient/Service resources.
See the [Create Patient](/api/api-reference/patients/v-2/create-patient) and [Create Service](/api/api-reference/services/v-2/create-service) API's.

If you have the pre-reqs for creating these (a User in your system, an Appointment to map to), there are other ways to
manage the Policy and Service Eligibility - talk to us if this is an option.