> ## Documentation Index
> Fetch the complete documentation index at: https://docs.silnahealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Benefits Check Overview

# Benefits Check Status

* `REQUESTED`
* `AWAITING_SILNA` → Silna is working on the benefits check
* `AWAITING_PROVIDER` → There is an open escalation on a benefits check which requires provider action
* `COMPLETE` → The benefits check is finished and you can use the response from GET Benefits Check API. This is a terminal state.
* `WITHDRAWN` → The benefits check will no longer be worked on. A benefits check can be withdrawn when a patient plan is archived or through the Silna app. This is a terminal state.

# Benefits Check Lifecycle

When you create a benefits check, it will move into the `REQUESTED` and then into the `AWAITING_SILNA` state automatically.
When Silna is finished completing the benefits check, it will move to the `COMPLETE` state. This is the happy path!

If there is a problem completing a benefits check, we might need to raise an escalation. When we raise an escalation for a
benefits check, it will move to the `AWAITING_PROVIDER` state. Once a provider resolves the escalation, it will move back to
the `AWAITING_SILNA` state.

If a benefits check is no longer needed, then a provider can withdraw it. When this happens, it moves to a `WITHDRAWN` state.

# Creating Benefit Check for a New Patient

To create a benefit check, you will need to do the following steps:

1. Follow the guide for [Patient Creation](/api-reference/v1patientsresource/create-patient) to create a new patient.
   * You can also use the [Create or Update Patient API](/api-reference/v1patientsresource/create-or-update-patient)
2. Use the `patient_id` from the response above to create a patient plan by following the guide for [Patient Plan Creation](/api-reference/v1patientplanresource/create-patient-plan).
   * You can also use the [Put Patient Plan API](/api-reference/v1patientplanresource/put-patient-plan).
3. Use the `patient_plan_id` from the response above to create a benefit check by following the guide for [Benefit Check Creation](/api-reference/v1benefitscheckresource/create-benefit-check).
4. It can take some time for Silna to complete a benefit check. We recommend polling the benefit check status
   by calling the [Get Benefits Check API](/api-reference/v2benefitscheckresource/get-benefits-check-v2) (with the `benefits_check_id` returned by the above API call). Terminal states for a Benefits Check
   are `COMPLETE` and `WITHDRAWN`. At times, it can take a couple of days for a benefits check to move to a terminal state so we recommend polling every hour or so.
5. Once the benefits check is complete, you can get the benefits check pdf report by calling the
   [Get Benefits Check Report API](/api-reference/v1benefitscheckreportresource/generate-benefits-check-report) and then calling the
   [Get File API](/api-reference/v1fileresource/get-file) with the `file_id` from the response.

# Creating a Benefit Check for an Existing Patient

To create a benefit check for an existing patient, you will take the same steps as above with the below modifications.

* Instead of using the Create Patient API, you will use the [Update Patient](/api-reference/v1patientresource/update-patient) or
  [Create or Update Patient API](/api-reference/v1patientsresource/create-or-update-patient) if you need to update any patient information. If you are storing the Silna `patient_id`
  in your system, then you can use the Update Patient API. If you are using your own id (`source_id`), then you should use the
  Create or Update Patient API. If this state of the patient in our system is unknown to you, then use the Create or Update Patient API.
* If you want to create a benefits check for a new plan, you will need to follow the guide for [Patient Plan Creation](/api-reference/v1patientplanresource/create-patient-plan).
  If it's for an existing plan, you will use the [Get Patient Plans API](/api-reference/v1patientplansresource/get-patient-plans) or [PUT Patient Plan API](/api-reference/v1patientplanresource/put-patient-plan)
  . Again, if the state of the patient plan in our system is unknown to you, then use the [PUT Patient Plan API](/api-reference/v1patientplanresource/put-patient-plan).

# Duplicate Protection

Duplicate protection is enabled by default for all API-created benefits checks. When you submit a request to create a benefits check, the API checks for duplicates based on the **patient plan** and **specialties** in the request. A request will be rejected in either of the following cases:

1. **Open benefits check exists** — If there is already a benefits check for the same patient plan and specialties that has not yet reached a terminal state (`COMPLETE` or `WITHDRAWN`), the API will return an error. There is no need to create a new benefits check while one is still being processed.

2. **Recently completed benefits check** — If a benefits check for the same patient plan and specialties was completed within the **last 2 days**, the API will return an error. Benefits data does not change frequently enough to warrant re-verification within this window.

<Note>
  If you are running into duplicate protection errors during QA testing, we recommend using our [QA Testing Guide](/api-reference/v1benefitscheckresource/qa-testing-guide). The guide explains how to use specific member IDs that automatically complete benefits checks, allowing you to quickly move past the 2-day window. If you need Silna to manually adjust dates for testing purposes, reach out to your Silna contact.
</Note>

# (Near) Realtime Benefits

To use Silna's realtime benefits checks, please reach out to your Silna contact to create a realtime template for you to use.
They will then give you the name of the template.
To get realtime benefits for a patient plan through the Silna API, you need to pass in the correct `template_id` to the [Post Benefits Checks API](/api-reference/v1benefitscheckresource/create-benefits-check).
You can get the correct `template_id` by searching the [Get Benefits Check Templates API](/api-reference/v1benefitschecktemplatesresource/get-benefits-check-templates)
with the template name provided by your Silna contact. Since `template_ids` can change, we recommend always using the  [Get Benefits Check Templates API](/api-reference/v1benefitschecktemplatesresource/get-benefits-check-templates)
to retrieve the latest `template_id` for the template name provided by your Silna contact.

It usually takes a few seconds for a Silna realtime benefits checks to complete, but you should be prepared for it to take up
to a minute in some cases.

# QA Testing

To test your benefits check integration without hitting real payors, see the [QA Testing Guide](/api-reference/v1benefitscheckresource/qa-testing-guide). It covers how to use specially formatted member numbers to simulate different insurance types, requirement flags, and rejection scenarios in our QA environment.

# Blue Cross Blue Shield Benefit Checks

### Understanding Your Benefit Check: BCBS Plans & Prefixes

When you receive a completed Benefit Check from Silna for a Blue Cross Blue Shield (BCBS) client, you may occasionally see a "Home Plan" listed that is located in a different state than your facility.

This is not an error—it is a specialized feature of Silna designed to ensure benefits are verified accurately.

### What is a "Home Plan"?

BCBS is a network of independent companies. A client might live in your state but have a policy issued by an employer in a different state.

#### The Prefix

The first three letters/numbers of the Member ID (e.g., XOS, YLS, ZCD) is a prefix and acts as a "routing code" to identify which specific home plan a member belongs to.

Silna's technology reads this prefix to find the home plan to determine the client's benefit details such as deductible, co-pay, and visit limits.

### Why does my Benefit Check show a different state plan?

If your facility is in Florida, for example, but the benefit check says BCBS of Illinois, it means the client's policy is managed in Illinois.

#### Why Silna lists the home plan instead of your local plan:

* **Verifying Benefits**: The home plan decides the deductible, co-pay, and visit limits.
* **Valid Authorizations**: To get a "Prior Auth," we must contact the Home Plan to determine if they are required and how they are managed. If we requested an authorization from your local office instead of the Home Plan, that authorization would be invalid, and you would not get paid.

### How to Verify a Prefix

If you would like to double-check a client's home plan yourself, you can use the official BCBS tool:

* Identify the first 3 characters of the Member ID.
* Visit the BCBS Member Services Tool.
* Enter the prefix to see the specific plan name and contact details.