> ## 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.

# QA Testing Guide

Use this guide to test your integration with the Silna Prior Authorization API in our QA environment.
By setting a specially formatted **member number** on a patient plan, you control which outcome a prior authorization reaches after you complete the request (for example, an approval, a partial approval, a denial, or an escalation that needs your action).

<Note>
  Test scenarios only run in our QA environment (`api-qa.silnahealth.com`). They are never triggered in production.
</Note>

## How It Works

The workflow is the same as production:

1. Create a patient plan with a member number that contains a scenario code (see [Member Number Format](#member-number-format))
2. [Create a prior authorization](/api-reference/v1priorauthorizationresource/create-prior-authorization) for that patient plan
3. [Update the prior authorization](/api-reference/v1priorauthorizationresource/update-prior-authorization) until its status is `ALL_REQUIRED_DATA_RECEIVED`
4. [Complete the prior authorization request](/api-reference/v1priorauthorizationcompleterequestresource/complete-prior-authorization)
5. Poll [Get Prior Authorization](/api-reference/v1priorauthorizationresource/get-prior-authorization) until the status reaches the scenario's final status

After you complete the request, Silna runs the scenario in the background:

| Time after completing | Status |
| - | - |
| Immediately | `REQUESTED` |
| \~30 seconds | `SUBMITTED_TO_PAYOR` |
| \~90 seconds | The scenario's final status (see [Scenarios](#scenarios)) |

If the prior authorization's status changes some other way before a step runs (for example, you abort it), the scenario stops.

### Fields Silna fills in

When Silna submits a test prior authorization, it fills in any of these fields you left empty, the same way it does for a real request:

* **Requested start date:** today.
* **Requested end date:** the requested start date plus a length that depends on the scenario: `01` 180 days, `02` 90, `03` 60, `04` 180, `05` 120, `06` 180, `07` 30, `08` 365, `09` 14.
* **Requested treatment codes:** two codes for the prior authorization's specialty, at 20 units per week each.

Values you provided are never changed. Approved dates, codes, and units are based on the requested values after these are filled in.

## Member Number Format

Add `PA` followed by a two-digit scenario code anywhere in the member number:

```
A_PA[SCENARIO_CODE]_11
```

This format works with the [Benefits Check QA Testing Guide](/api-reference/v1benefitscheckresource/qa-testing-guide) too: the benefits check still reads the leading `A` and the trailing insurance code (`11`), so one test patient plan can drive both a benefits check test and a prior authorization test.

| Member Number | Scenario |
| - | - |
| `A_PA01_11` | Approved, everything matches the request |
| `A_PA05_11` | Partially approved |
| `A_PA07_11` | Denied |

Member numbers without a `PA` code, or with an unknown code, follow the normal prior authorization flow.

## Scenarios

| Code | Scenario | Final Status |
| - | - | - |
| `01` | Approved: one reference number, approved dates match the requested dates, approved codes and units match the requested codes and units | `PAYOR_APPROVED` |
| `02` | Approved: same as `01`, with a different reference number for each approved treatment code | `PAYOR_APPROVED` |
| `03` | Approved: same as `01`, with approved dates that cover a wider range than requested (start 7 days earlier, end 30 days later) | `PAYOR_APPROVED` |
| `04` | Approved: same as `01`, with one more unit approved than requested on the first treatment code | `PAYOR_APPROVED` |
| `05` | Partially approved: the last requested treatment code is not approved. If only one code was requested, half of its units are approved | `AWAITING_PROVIDER` with an open `DECISION_RENDERED__PARTIALLY_APPROVED` escalation |
| `06` | Additional documentation requested by the payor | `AWAITING_PROVIDER` with an open `ADDITIONAL_REQUIREMENTS__DOCUMENTATION` escalation |
| `07` | Denied | `DENIED_UNAPPEALED` |
| `08` | Authorization not required | `UNNECESSARY` |
| `09` | Withdrawn | `WITHDRAWN` |

### Approved scenarios (`01` - `04`)

The prior authorization response includes:

* `approved_treatment_codes` with `units`, `unit_type`, `time_frame`, `reference_number`, `approved_start_date`, and `approved_end_date`
* `reference_numbers` with every reference number on the authorization
* `approval_files` with a synthetic approval letter (`document_type` = `APPROVAL_LETTER`)

### Partially approved scenario (`05`)

Partial approvals mirror production: Silna records the approved treatment codes and an approval letter, then opens a `DECISION_RENDERED__PARTIALLY_APPROVED` escalation asking you how to proceed. Opening the escalation moves the prior authorization to `AWAITING_PROVIDER`. You can find the escalation with the [Escalations API](/api-reference/v1escalationsresource/get-escalations).

### Denied scenario (`07`)

The prior authorization response includes a synthetic denial letter in `denial_files` (`document_type` = `DENIAL_LETTER`).

<Note>
  All approval/denial letters generated by these scenarios are labeled "QA TEST" and are not real payor documents.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.