Skip to main content
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).
Test scenarios only run in our QA environment (api-qa.silnahealth.com). They are never triggered in production.

​
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)
  2. Create a prior authorization for that patient plan
  3. Update the prior authorization until its status is ALL_REQUIRED_DATA_RECEIVED
  4. Complete the prior authorization request
  5. Poll Get Prior Authorization until the status reaches the scenario’s final status
After you complete the request, Silna runs the scenario in the background: 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:
This format works with the Benefits Check 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 numbers without a PA code, or with an unknown code, follow the normal prior authorization flow.

​
Scenarios

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

​
Denied scenario (07)

The prior authorization response includes a synthetic denial letter in denial_files (document_type = DENIAL_LETTER).
All approval/denial letters generated by these scenarios are labeled “QA TEST” and are not real payor documents.