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