Prior Authorization Overview

​

Key API Workflow

1. Create: Call POST to initiate, receiving required data specifications
2. Update: Use PATCH to upload documents, treatment codes, clinician info, and dates
3. Poll: Call GET to monitor status changes until reaching “ALL_REQUIRED_DATA_RECEIVED”
4. Final Update: Make additional PATCH requests if needed
5. Complete: Call POST to submit for processing

​

Status Categories

​

Creation Phase

• DATA_REQUESTED: Waiting for initial data
• DATA_RECEIVED: Data partially received
• ALL_REQUIRED_DATA_RECEIVED: All required data collected

​

Processing Phase

• AWAITING_SILNA: Silna is processing
• SUBMITTED_TO_PAYOR: Sent to insurance company
• PRELIMINARY_APPROVAL: Initial approval received
• REQUESTED: Authorization requested
• PARTIALLY_APPROVED: Some treatment codes approved

​

Action Required

• PAYOR_DENIED: Denied by payor
• PAYOR_DENIED_APPEALING: Denied, appeal in progress
• AWAITING_PROVIDER: Provider action needed

​

Terminal States

• PAYOR_APPROVED: Complete and approved
• DENIED_UNAPPEALED: Denied with no appeal
• UNNECESSARY: Authorization not needed
• WITHDRAWN: Cancelled

​

Document Types

​

General specialties

• Progress notes
• Treatment plans
• Referrals
• Assessments
• Diagnosis reports
• Authorization forms

​

ABA-specific

• ABAS
• VINELAND
• SRS_2
• PDDBI
• PSI_SIPA

​

Legacy support

​

Authorization Sequence

1. ASSESSMENT_AUTHORIZATION (optional initial evaluations)
2. INITIAL_AUTHORIZATION (post-evaluation treatment)
3. CONCURRENT_AUTHORIZATION (ongoing care)
4. AMENDMENT (modifications to existing approvals)

​

Approval Data Access

• Approval letters in “approval_files” searchable by “APPROVAL_LETTER” document type
• Treatment codes with units, timeframes, reference numbers, start/end dates in “approved_treatment_codes”
• Shared approval parameters apply across multiple codes in single entries

​

Document Validation Features

• Validates clinical documentation against payor requirements
• Takes 30-45 seconds typically
• Results accessible via GET with “with_requirements” parameter
• Failed validations prevent “ALL_REQUIRED_DATA_RECEIVED” status
• In-depth results available through Get Document Validations API
• Validations can be disabled per document type with override reasoning

​

Key Constraints

• Cannot delete prior authorizations outside DATA_REQUESTED, DATA_RECEIVED, or ALL_REQUIRED_DATA_RECEIVED states
• List field updates replace entire lists
• Required data cannot be removed once ALL_REQUIRED_DATA_RECEIVED status achieved