> ## 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. # Overview ## Background: What Is an Escalation? An escalation is a structured request or notification sent to the provider through the Silna platform. Each escalation has: * **`escalation_type`**: A hierarchical identifier that classifies what the escalation is about. * **`action_type`**: Either `SUBMISSION` (the provider must respond) or `NOTIFICATION` (informational only). * **`reason`**: A human-readable explanation of what happened and what is needed. * **`status`**: The current lifecycle state of the escalation. The public API (`GET /public/v1/escalations`) returns escalations for **Benefits Checks** and **Prior Authorizations** only. *** ## Action Types The `action_type` field tells you whether the provider needs to take action or is simply being informed. | `action_type` | Provider Action Required? | What It Means | | -------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SUBMISSION` | **Yes** | The escalation is **blocking** - Silna cannot continue processing the request until the provider submits the requested information, documents, or decision. The provider must respond through Silna's platform. | | `NOTIFICATION` | **No** | The escalation is **informational** - Silna is notifying the provider of something relevant (a payor decision, a data discrepancy, etc.). The provider should review it but does not need to submit anything. These may be auto-resolved by Silna. | ### How action\_type Relates to Blocking Any escalation with `action_type = SUBMISSION` is **blocking** - Silna cannot continue processing the request until the provider responds. Any escalation with `action_type = NOTIFICATION` is **non-blocking**. The `action_type` depends on both the escalation type and the resource type. For example, `DECISION_RENDERED__DENIAL` is `SUBMISSION` on Prior Authorizations (the provider must choose to appeal, accept, etc.) but does not apply to Benefits Checks at all. At a high level: * All `ADDITIONAL_REQUIREMENTS__*` types are `SUBMISSION`. * `DECISION_RENDERED__DENIAL`, `PARTIALLY_APPROVED`, and `CANCELLED` are `SUBMISSION` (the provider must choose a next action). * `DECISION_RENDERED__APPROVED` and `DECISION_RENDERED__INELIGIBLE` are `NOTIFICATION` (final outcomes, no further input needed). * All `NOTIFICATION__*` types are `NOTIFICATION`. *** ## Category 1: Additional Requirements - Documentation **Action type: `SUBMISSION` (always blocking)** **Resource types: Benefits Check, Prior Authorization** This type is used when the payor is explicitly asking the provider to upload a document. This is distinct from the "Specific Details" types below - `DOCUMENTATION` means the payor wants a file (a form, a clinical report, etc.), not a specific data point. | Type | Description | Common Triggers | | ---------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ADDITIONAL_REQUIREMENTS__DOCUMENTATION` | The payor needs clinical documentation uploaded. | Payor requests a plan of care, progress notes, medical records, letter of medical necessity, referral, assessment, treatment plan, diagnosis report, or authorization form. The `reason` field will contain the specific document needed. | **Example `reason`:** "The payor requires an updated plan of care for this patient. Please upload the document so we can submit it to the payor for review." *** ## Category 2: Additional Requirements - Specific Details **Action type: `SUBMISSION` (always blocking)** **Resource types: Benefits Check, Prior Authorization** These types are used when the payor has identified a **concrete data problem** - something is missing, incorrect, or needs confirmation. Unlike `DOCUMENTATION`, these escalations ask for specific data points (a corrected member ID, a date of birth, an NPI number) rather than a full document upload. ### Patient Information These escalations relate to data about the patient whose benefits check or prior authorization is being processed. | Type | Description | Common Triggers | | ------------------------------------------------------------------ | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__INSURANCE` | The patient's insurance plan details are missing or incorrect. | Member ID does not match payor records, group number is wrong, subscriber relationship is incorrect, insurance card needed for verification. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__DEMOGRAPHICS` | The patient's demographic information is missing or incorrect. | Date of birth does not match, address is missing, phone number is incorrect, patient name mismatch between provider and payor records. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__STATUS` | The patient's status with the provider needs clarification. | Payor needs to know if the patient is active or discharged, effective dates of care, enrollment status confirmation. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__DIAGNOSIS` | The patient's diagnosis or condition information is missing or incorrect. | ICD-10 codes are missing or incorrect, clinical description of condition needed, date of diagnosis not provided, diagnosis does not support medical necessity. | ### Provider Information These escalations relate to data about the healthcare provider or clinician performing the service. | Type | Description | Common Triggers | | --------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__CLINICIAN` | The treating clinician's details are needed. | Rendering provider name missing, clinician credentials or specialty not on file, payor says "therapist name should be on line 4 of the form." | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__LOCATION` | The service location information is missing or incorrect. | Facility address does not match, place of service code is wrong, payor cannot verify the service location. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__IDENTIFIERS` | The provider's identifiers are missing or incorrect. | NPI is not enrolled with the payor, Tax ID (TIN) does not match, PTAN is expired or missing, state license number needed. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__NETWORK_STATUS` | The provider's network participation status needs clarification. | Payor says provider is out-of-network, network effective dates are in question, payor needs confirmation of in-network status before processing. | ### Treatment Information These escalations relate to the clinical service or treatment being authorized. | Type | Description | Common Triggers | | ----------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__CLINICAL` | Clinical details about the treatment are needed. | Medical necessity justification insufficient, clinical rationale not provided, treatment history needed to support the request, payor's medical reviewer has questions. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__DATES` | Treatment date information is missing or incorrect. | Authorization start/end dates not provided, treatment dates don't align with the request, retro authorization dates needed, frequency of service unclear. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__TREATMENT_CODES` | Procedure or service codes need clarification. | CPT codes are incorrect or not covered, HCPCS codes missing, units or modifiers are wrong, payor needs different codes than what was submitted. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__PEER_TO_PEER` | A peer-to-peer review has been requested or needs to be scheduled. | The payor's medical reviewer wants to speak directly with the treating clinician to discuss clinical necessity. This is common during prior authorization medical review when the written documentation alone has not satisfied the payor. The provider must schedule or complete the call. | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__BILLING` | Billing or claims-related information is needed. | Claim number needed for an appeal, billing codes don't match authorization, expected charges required, place of service code for billing purposes. | *** ## Category 3: Decision Rendered **Resource types: varies by decision (see table below)** These escalations are created when the payor has made a **final determination** on a prior authorization or benefits check. The `reason` field will contain details about the decision, and for denials and partial approvals, supplemental documents (like the payor's denial letter) may be attached via `supplemental_file_ids`. The action type varies by decision type: | Type | Action Type | Description | Resource Type | Provider Next Steps | | --------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `DECISION_RENDERED__APPROVED` | `NOTIFICATION` | The request has been **fully approved**. The payor authorized all requested services, units, and dates. No further action is needed from the provider or Silna. | Prior Authorization | None required. The provider can proceed with the authorized treatment. | | `DECISION_RENDERED__PARTIALLY_APPROVED` | `SUBMISSION` | The request was **partially approved**. The payor authorized some but not all of the requested services - the approved dates, codes, or units differ from what was requested. | Prior Authorization | The provider must choose a next action: **accept** the partial approval, **appeal** with supporting documentation, **resubmit** with changes, **request modification**, **schedule a peer-to-peer** review, or **withdraw** the request. | | `DECISION_RENDERED__DENIAL` | `SUBMISSION` | The request was **fully denied**. The payor refused to authorize the requested services. The `reason` field and any attached supplemental documents will explain the denial rationale. | Prior Authorization | Same options as partial approval: **accept**, **appeal**, **resubmit**, **request modification**, **schedule a peer-to-peer**, or **withdraw**. | | `DECISION_RENDERED__CANCELLED` | `SUBMISSION` | The request was **cancelled** by the payor. This can happen when the request was withdrawn, is a duplicate, or the patient's coverage terminated before a decision was made. | Prior Authorization | The provider must choose: **accept**, **appeal**, **resubmit**, or **withdraw**. | | `DECISION_RENDERED__INELIGIBLE` | `NOTIFICATION` | The patient was determined to be **ineligible** for benefits under their current plan. This is not a clinical denial - the patient's coverage simply does not include these services, or the patient is not eligible for coverage at all. | Benefits Check | The provider should review the patient's insurance information. They may **accept** the finding, **retry** the benefits check with corrected information, or **discharge** the patient from the workflow. | ### Decision Rendered - Reason Format For `DENIAL` and `PARTIALLY_APPROVED` escalations, the `reason` field is prefixed with a standard header: * **Denial:** "This authorization has been denied by the payor. Please review the attached document for full details." * **Partial Approval:** "This authorization has been partially approved by the payor. Please review the attached document for full details." This is followed by the specific details extracted from the payor's decision document. *** ## Category 4: Notifications **Action type: `NOTIFICATION` (always non-blocking)** These escalations inform the provider about data discrepancies or updates that Silna discovered while processing the request. No response is required from the provider - Silna is sharing information that may be relevant to the provider's records or understanding of the case. Notification types mirror the "Specific Details" subcategories above. The key difference: `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__*` means "the payor needs you to fix/provide this data before we can proceed." `NOTIFICATION__*` means "we noticed something about this data that you should be aware of, but we don't need anything from you." ### Patient Notifications | Type | Description | Resource Type | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | | `NOTIFICATION__PATIENT__INSURANCE` | Notifying the provider about the patient's insurance plan. Examples: coverage changes detected, plan updates, secondary insurance found. | Benefits Check | | `NOTIFICATION__PATIENT__DEMOGRAPHICS` | Notifying the provider about patient demographics. Examples: payor has a different address or date of birth on file, name discrepancy. | Benefits Check | | `NOTIFICATION__PATIENT__STATUS` | Notifying the provider about the patient's status. Examples: coverage became active or inactive, eligibility period changed. | Benefits Check | | `NOTIFICATION__PATIENT__DIAGNOSIS` | Notifying the provider about diagnosis information. Examples: diagnosis codes on the payor's file differ from what the provider submitted. | Benefits Check | ### Provider Notifications | Type | Description | Resource Type | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------- | | `NOTIFICATION__PROVIDER__CLINICIAN` | Notifying the provider about clinician data. Examples: payor has different credentials on file for the treating clinician. | Benefits Check | | `NOTIFICATION__PROVIDER__LOCATION` | Notifying the provider about service location data. Examples: address on file with payor differs from provider records. | Benefits Check | | `NOTIFICATION__PROVIDER__IDENTIFIERS` | Notifying the provider about identifier data. Examples: NPI enrollment status update, TIN discrepancy. | Benefits Check | | `NOTIFICATION__PROVIDER__NETWORK_STATUS` | Notifying the provider about network status. Examples: network participation status change, contract update. | Benefits Check | ### Treatment Notifications | Type | Description | Resource Type | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | | `NOTIFICATION__TREATMENT__CLINICAL` | Notifying the provider about clinical details. Examples: payor noted a clinical documentation discrepancy during review. | Benefits Check, Prior Authorization | | `NOTIFICATION__TREATMENT__DATES` | Notifying the provider about treatment dates. Examples: authorized dates differ from requested dates, schedule update from payor. | Benefits Check, Prior Authorization | | `NOTIFICATION__TREATMENT__TREATMENT_CODES` | Notifying the provider about procedure codes. Examples: CPT code coverage update, code-level benefit information. | Benefits Check, Prior Authorization | | `NOTIFICATION__TREATMENT__PEER_TO_PEER` | Notifying the provider about peer-to-peer review status. Examples: scheduled peer-to-peer update, review outcome notification. | Benefits Check, Prior Authorization | | `NOTIFICATION__TREATMENT__BILLING` | Notifying the provider about billing information. Examples: claim status update, billing code discrepancy. | Benefits Check, Prior Authorization | *** ## Resource Type Compatibility Matrix Not all escalation types apply to both resource types. The table below shows which types can appear for each product line. | Escalation Type | Benefits Check | Prior Authorization | | ----------------------------------------------------------------------- | -------------- | ------------------- | | `ADDITIONAL_REQUIREMENTS__DOCUMENTATION` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__INSURANCE` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__DEMOGRAPHICS` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__STATUS` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__DIAGNOSIS` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__CLINICIAN` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__LOCATION` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__IDENTIFIERS` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__NETWORK_STATUS` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__CLINICAL` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__DATES` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__TREATMENT_CODES` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__PEER_TO_PEER` | Yes | Yes | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__BILLING` | Yes | Yes | | `DECISION_RENDERED__APPROVED` | No | Yes | | `DECISION_RENDERED__PARTIALLY_APPROVED` | No | Yes | | `DECISION_RENDERED__DENIAL` | No | Yes | | `DECISION_RENDERED__CANCELLED` | No | Yes | | `DECISION_RENDERED__INELIGIBLE` | Yes | No | | `NOTIFICATION__PATIENT__INSURANCE` | Yes | No | | `NOTIFICATION__PATIENT__DEMOGRAPHICS` | Yes | No | | `NOTIFICATION__PATIENT__STATUS` | Yes | No | | `NOTIFICATION__PATIENT__DIAGNOSIS` | Yes | No | | `NOTIFICATION__PROVIDER__CLINICIAN` | Yes | No | | `NOTIFICATION__PROVIDER__LOCATION` | Yes | No | | `NOTIFICATION__PROVIDER__IDENTIFIERS` | Yes | No | | `NOTIFICATION__PROVIDER__NETWORK_STATUS` | Yes | No | | `NOTIFICATION__TREATMENT__CLINICAL` | Yes | Yes | | `NOTIFICATION__TREATMENT__DATES` | Yes | Yes | | `NOTIFICATION__TREATMENT__TREATMENT_CODES` | Yes | Yes | | `NOTIFICATION__TREATMENT__PEER_TO_PEER` | Yes | Yes | | `NOTIFICATION__TREATMENT__BILLING` | Yes | Yes | **Summary:** * All `ADDITIONAL_REQUIREMENTS__*` types apply to both product lines. * `DECISION_RENDERED__APPROVED/PARTIALLY_APPROVED/DENIAL/CANCELLED` are Prior Authorization only (these are authorization decisions). * `DECISION_RENDERED__INELIGIBLE` is Benefits Check only (this is an eligibility determination). * `NOTIFICATION__PATIENT__*` and `NOTIFICATION__PROVIDER__*` are Benefits Check only. * `NOTIFICATION__TREATMENT__*` applies to both product lines. *** ## Implementation Priority Not all escalation types occur with equal frequency. The table below groups types by how often they appear in production to help you prioritize your integration. ### High Frequency (must handle) These types make up the vast majority of escalations. Your integration should have explicit handling for all of them. | Escalation Type | Product Line | \~Frequency | | ----------------------------------------------------------------------- | ------------------- | -------------------------------------------------- | | `ADDITIONAL_REQUIREMENTS__DOCUMENTATION` | Both | \~40% of all escalations across both product lines | | `NOTIFICATION__PATIENT__INSURANCE` | Benefits Check | \~35% of BC escalations | | `DECISION_RENDERED__PARTIALLY_APPROVED` | Prior Authorization | \~25% of PA escalations | | `DECISION_RENDERED__DENIAL` | Prior Authorization | \~15% of PA escalations | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__INSURANCE` | Both | \~10% of BC, \~4% of PA | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__CLINICAL` | Prior Authorization | \~8% of PA escalations | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__TREATMENT_CODES` | Prior Authorization | \~5% of PA escalations | For Benefits Checks, the top three types (`DOCUMENTATION`, `NOTIFICATION__PATIENT__INSURANCE`, `PATIENT__INSURANCE`) account for over 90% of all escalations. For Prior Authorizations, the distribution is more spread out. Documentation requests and payor decisions (partial approvals and denials) dominate, but treatment-related additional requirements are also very common - payors frequently ask for more clinical justification during the authorization process. ### Moderate Frequency (should handle) These types appear regularly and warrant dedicated handling. | Escalation Type | Product Line | | --------------------------------------------------------------------- | ------------------- | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__DATES` | Prior Authorization | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PATIENT__DEMOGRAPHICS` | Both | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__CLINICIAN` | Both | | `DECISION_RENDERED__CANCELLED` | Prior Authorization | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__TREATMENT__PEER_TO_PEER` | Prior Authorization | | `NOTIFICATION__TREATMENT__CLINICAL` | Both | | `DECISION_RENDERED__APPROVED` | Prior Authorization | | `NOTIFICATION__TREATMENT__PEER_TO_PEER` | Prior Authorization | | `ADDITIONAL_REQUIREMENTS__SPECIFIC_DETAILS__PROVIDER__NETWORK_STATUS` | Both | | `NOTIFICATION__PROVIDER__NETWORK_STATUS` | Benefits Check | Peer-to-peer types deserve special attention despite moderate volume as they require the treating clinician to schedule a call with the payor's medical reviewer, which is time-sensitive. ### Low Frequency (handle generically) The remaining types appear infrequently. Rather than building dedicated handling for each, treat them generically using the `action_type`, `reason`, and `status` fields. Your integration should not break on any valid escalation type - if you encounter a type you don't have specific handling for, fall back to displaying the `reason` text and the `action_type` to indicate whether provider action is needed. *** ## Statuses Each escalation moves through a lifecycle tracked by the `status` field. | Status | Meaning | Typical Duration | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | `NEW` | The escalation was just created. The provider has not viewed or interacted with it yet. | Until the provider opens the escalation in Silna's UI. | | `IN_PROGRESS` | The provider has started working on the escalation but has not yet submitted their response. | Variable - depends on how quickly the provider gathers the needed information. | | `RESOLVED` | The escalation is complete. For `SUBMISSION` types, the provider submitted their response. For `NOTIFICATION` types, the provider acknowledged or Silna auto-resolved it. | Terminal state. | | `WITHDRAWN` | Silna withdrew the escalation because it is no longer relevant. This can happen when the underlying request was cancelled, a duplicate escalation was detected, or circumstances changed. | Terminal state. |