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.

API Documentation

Payors

Providers

Files

Patients

Benefit Check

Eligibility Check

Prior Authorizations

Payor Detection

Document Validation

Exports

Escalations

Background: What Is an Escalation?

Action Types

How action_type Relates to Blocking

Category 1: Additional Requirements - Documentation

Category 2: Additional Requirements - Specific Details

Patient Information

Provider Information

Treatment Information

Category 3: Decision Rendered

Decision Rendered - Reason Format

Category 4: Notifications

Patient Notifications

Provider Notifications

Treatment Notifications

Resource Type Compatibility Matrix

Implementation Priority

High Frequency (must handle)

Moderate Frequency (should handle)

Low Frequency (handle generically)

Statuses

​Background: What Is an Escalation?

​Action Types

​How action_type Relates to Blocking

​Category 1: Additional Requirements - Documentation

​Category 2: Additional Requirements - Specific Details

​Patient Information

​Provider Information

​Treatment Information

​Category 3: Decision Rendered

​Decision Rendered - Reason Format

​Category 4: Notifications

​Patient Notifications

​Provider Notifications

​Treatment Notifications

​Resource Type Compatibility Matrix

​Implementation Priority

​High Frequency (must handle)

​Moderate Frequency (should handle)

​Low Frequency (handle generically)

​Statuses

Background: What Is an Escalation?

Action Types

How action_type Relates to Blocking

Category 1: Additional Requirements - Documentation

Category 2: Additional Requirements - Specific Details

Patient Information

Provider Information

Treatment Information

Category 3: Decision Rendered

Decision Rendered - Reason Format

Category 4: Notifications

Patient Notifications

Provider Notifications

Treatment Notifications

Resource Type Compatibility Matrix

Implementation Priority

High Frequency (must handle)

Moderate Frequency (should handle)

Low Frequency (handle generically)

Statuses