​
How to get Prior Authorizations for a Patient Plan

  1. You can get all prior authorizations for a patient plan by calling the Get Prior Authorizations for a Patient Plan API.
  2. This will return a preview of each prior authorization. In order to get more detailed information, you should call the Get Prior Authorization API with one of the ids from the response above.

​
Prior Authorization Statuses

When a prior authorization is in the below states, a provider/api client is still in the process of creating a prior authorizatin request
  • DATA_REQUESTED -> This means that Silna is waiting for the provider to provide the required data. It is in this state after Create Prior Authorization
  • DATA_RECEIVED -> This means that Silna has received data from the provider and we are determining if the requirements have been met
  • ALL_REQUIRED_DATA_RECEIVED -> This means that Silna has all required data from the provider and the provider can call Complete Prior Authorizaiton to submit it to Silna to process When a prior authorization is in the below states, Silna is currently processing the authorization:
  • AWAITING_SILNA
  • SUBMITTED_TO_PAYOR
  • PRELIMINARY_APPROVAL -> This means the payor has provided preliminary approval but we are still waiting for either a reference number or an authorization approval letter.
  • REQUESTED
  • PARTIALLY_APPROVED
When a prior authorization is in the below states, a provider will have to take action:
  • PAYOR_DENIED
  • PAYOR_DENIED_APPEALING
  • AWAITING_PROVIDER
When a prior authorization is in the below states, the prior authorization is in a terminal state:
  • PAYOR_APPROVED -> This means that the prior authorization is complete.
  • DENIED_UNAPPEALED
  • UNNECESSARY
  • WITHDRAWN

​
Prior Authorization Document Types

​
Document Types When Creating A Prior Authorization

​
All Specialty Document Types

  • PROGRESS_NOTE
  • TREATMENT_PLAN_PLAN_OF_CARE -> Use this document type for Treatment Plans or Plans of Care.
  • REFERRAL
  • ASSESSMENT_EVALUATION
  • DIAGNOSIS_REPORT
  • AUTHORIZATION_FORM -> This is required in very rare and complex cases. Usually clients will upload all required data and we will use those inputs to create the authorization form.

​
ABA Specific Document Types

  • ABAS
  • VINELAND
  • SRS_2
  • PDDBI
  • PSI_SIPA

​
Document Types that we can return in Get Prior Authorization’s other_files field

In addition to the above document types, we can also return files with OTHER document types. This is a legacy document type that we support for backwards compatibility purposes. Note: This list of document types is not static. We will not remove document types but we will add more in the future.

​
Authorization Types

When running a benefits check for a patient plan, we will tell you whether an authorization is required. The general order of authorizations is the below:
  1. ASSESSMENT_AUTHORIZATION -> (Not always required) Requests for initial evaluations or assessments. This is typically used for a new patient.
  2. INITIAL_AUTHORIZATION -> Requests for initial treatment post-evaluation or assessment.
  3. CONCURRENT_AUTHORIZATION -> Requests for ongoing treatment of existing patients.
  • AMENDMENT -> Any addendums, extensions, or change of provider on an existing authorization.

​
Reading Approval Data From a Prior Authorization

When a prior authorization is in the PAYOR_APPROVED state, then you can read the approval data from the prior authorization.
  • The approval letter will be in approval_files. Please search for the file with the document_type of APPROVAL_LETTER. This object will have file id. If you want to download it, then you will have to use the Get File API.
  • The approved treatment codes will be in approved_treatment_codes. Each entry in this list will have a list of treatment codes that were approved (treatment_codes) and the units, unit_type, time_frame, reference_number, approved_start_date, and approved_end_date. These fields will apply across all treatment_codes in the treatment_codes list.
For example, if you have treatment codes 97153, 97154, and 97155 in the list, then units=20 and unit_type=VISITS, then you have 20 visits approved across treatment codes 97153, 97154, and 97155 i.e. 97153.visits + 97154.visits + 97155.visits = 20. All of these treatment codes will have the same start/end dates and reference numbers. Below is an example of this kind of response: 
  ...
  "approved_treatment_codes": [
    {
      "treatment_codes": [
        {
          "code": "97153",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        },
        {
          "code": "97154",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        },
        {
          "code": "97155",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        }
      ],
      "units": "20",
      "unit_type": "VISITS",
      "time_frame": "TOTAL",
      "reference_number": "123456789",
      "approved_start_date": "2025-01-01",
      "approved_end_date": "2025-06-01"
    }
  ],
  ...
If instead, you have the below response, then you have 20 units approved for each treatment code i.e. 97153.visits = 20, 97154.visits = 20, 97155.visits = 20. In this situation, it is also possible for reference numbers to be the same or different across each approved treatment code. 
  ...
  "approved_treatment_codes": [
    {
      "treatment_codes": [
        {
          "code": "97153",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        }
      ],
      "units": "20",
      "unit_type": "VISITS",
      "time_frame": "TOTAL",
      "reference_number": "123456789",
      "approved_start_date": "2025-01-01",
      "approved_end_date": "2025-06-01"
    },
    {
      "treatment_codes": [
        {
          "code": "97154",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        }
      ],
      "units": "20",
      "unit_type": "VISITS",
      "time_frame": "TOTAL",
      "reference_number": "123456789",
      "approved_start_date": "2025-01-01",
      "approved_end_date": "2025-06-01"
    },
    {
      "treatment_codes": [
        {
          "code": "97155",
          "description": "DESCRIPTION",
          "standard": "CPT",
          "treatment_code_modifiers": []
        }
      ],
      "units": "20",
      "unit_type": "VISITS",
      "time_frame": "TOTAL",
      "reference_number": "123456789",
      "approved_start_date": "2025-01-01",
      "approved_end_date": "2025-06-01"
    }
  ],
  ...

​
Creating A Prior Authorization

​
Call Sequence

  1. POST (Create) Prior Authorization. This returns a prior authorization id to use for the subsequent requests and tells the api client what data is required to complete the request
    • This will return a Prior Authorization with status DATA_REQUESTED. It will return requirements to complete the prior authorization. Each requirement marked with "required": true will need to be satisfied before completing the request.
  2. PATCH (Update) Prior Authorization. Use this API to upload documents, treatment codes, clinician data, and/or a start date. You can upload data that is not specifically required
  3. Poll GET Prior Authorization. The client can stop polling once the status moves to DATA_REQUESTED or ALL_REQUIRED_DATA_RECEIVED. A Silna background job is responsible for moving a Prior Authorization status from DATA_RECEIVED to DATA_REQUESTED or ALL_REQUIRED_DATA_RECEIVED.
  4. PATCH (Update) Prior Authorization (if step 3 returns a prior authorization with status DATA_REQUESTED then this is required). Else, the client can call this with optional files. Once we are in the ALL_REQUIRED_DATA_RECEIVED state, clients will no longer be able to remove the uploaded data which is required.
  5. POST Prior Authorization Complete Request. This moves the prior authorization to the REQUESTED state.

​
Lifecycle

Prior Authorization Lifecycle

​
Kicking off the Prior Authorization Request Process (Step #1 in Call Sequence)

Calling POST (Create) Prior Authorization will create a Prior Authorization in a DATA_REQUESTED state and return what additional data is required
  • You will need to supply three fields: a patient_plan_id, an authorization_type, and a specialty.
  • When treatement_codes.required is true then the api client will need to use the PATCH (Update) Prior Authorization to create at least one treatment code. The reason we require an additional request to upload treatment codes is because there are multiple treatment code standards (depending on the payor) and we need to let the api client know which one to use.
  • When documents.required is true, then the api client will need to use the PATCH (Update) Prior Authorization api to upload the required documents (and optionally the documents with required set to false). Similar to treatment codes, we are unable to know which documents are required until the api client initiates the creation of a prior authorization as the documents required depend on the payor, specialty, and authorization type.
    • When uploading documents, you will first need to upload the file with the POST (Upload) File API and then use the file id in the PATCH (Update) Prior Authorization api to upload the document.
    • Each item in documents.items will have a document_type and a required field. The document_type tells you what document type you need to upload and the required flag tells you whether that specific document is required.
  • When clinician_npi.required is true, then the api client will need to use the PATCH (Update) Prior Authorization to upload a clinician NPI (and optionally first and last name).
  • When start_date.required is true, then the api client will need to use the PATCH Prior Authorization API to add a start date to the authorization.

​
Updating A Prior Authorization Request (Step #2 and Step #4 in Call Sequence)

Calling PATCH (Update) Prior Authorization allows a client to complete the requirements returned by the POST (Create) Prior Authorization API. Updates to list fields will replace the entire list. If you need to make a subsequent update, you should first call GET Prior Authorization to get the current requested treatment codes and documents on file. Making calls to this API with additional data fields (like treatment codes, clinician_npi, documents, start_date) will move the status to DATA_RECEIVED. From there, Silna will determine whether the requirements have been met. If so, we move the state to ALL_REQUIRED_DATA_RECEIVED. If not all requirements have been satisfied, then we move to DATA_REQUESTED and return the requirements that are still needed. Once the status is ALL_REQUIRED_DATA_RECEIVED, the client can still add more documents, treatment codes and make changes to the clinician and start date. However, they cannot take any action that would move the prior authorization status back to DATA_REQUESTED. For example, if there is already a start date on the prior authorization, then the client cannot remove it. If they want to change the start date, they will need to update it to a new date.

​
Viewing Which Prior Authorization Requirements Have Been Satisfied (Step #3 in Call Sequence)

Poll GET Prior Authorization with the query parameter with_requirements=true to see the same requirements as the POST (Create) Prior Authorization API. This will also return a requirement_satisfied field which returns whether that individual requirement has been met. Use the status field to determine if ALL requirments have been met

​
Completing the Prior Authorization Request (Step #5 in Call Sequence)

Calling POST Prior Authorization Complete Request will move the prior authorization to the REQUESTED state. This will only return a 2XX response code if the prior authorization has status ALL_REQUIRED_DATA_RECEIVED, else it will return a 4XX error.

​
Aborting the Prior Authorization Request

If you no longer want to submit a prior authorization, you can use the DELETE (Abort) Prior Authorization API. Note: You cannot delete a prior authorization that is not in the ALL_REQUIRED_DATA_RECEIVED, DATA_REQUESTED, or DATA_RECEIVED states.