Skip to main content
Payor Inference extracts and confirms insurance plan details so you can create accurate patient plans in Silna. It supports two workflows: processing insurance card images and confirming plan details directly with the payor. Using Payor Inference before creating patient plans is optional, but recommended. It catches incorrect member numbers, mismatched payors, and other data quality issues before they cause downstream failures in benefits checks and prior authorizations.
  1. Create a patient (POST /v1/patients)
  2. Run Payor Inference — BASE if you have an insurance card, CONFIRMATION if you already have plan details
  3. Poll until COMPLETED (GET /v1/payor_inference/{id})
  4. Create patient plans — review any confirmation results, but you can always proceed regardless of the outcome

​
Strategies

The strategy field on the create request determines which processing steps run and what inputs are required.

​
BASE

Use BASE when you have an insurance card. Silna will parse the document, identify the payor, confirm the extracted details directly with the payor, and return the results along with any corrections. This is the most thorough strategy and typically takes a few minutes. Required inputs: patient_document_file_ids

​
NEAR_REALTIME

Use NEAR_REALTIME when you have an insurance card and need results quickly. Silna will parse the document and identify the payor, but will not confirm with the payor. Results typically come back in seconds. Required inputs: patient_document_file_ids

​
CONFIRMATION

Use CONFIRMATION when you already have plan details and want to confirm them directly with the payor without processing any documents. This is useful when plan information was entered manually, came from an EHR, or you want to verify existing data before creating a patient plan. Required inputs: individuals array with plan details to confirm. See Create Payor Inference for input details. If confirmation is not available for the specified payor, the request completes immediately with confirmation set to null. You can proceed with creating the patient plan — confirmation is not required.

​
Understanding the Confirmation Response

When the BASE or CONFIRMATION strategy is used, each plan in the response may include a confirmation object with the following fields:
  • result — CONFIRMED or NOT_CONFIRMED
  • requested — The values that were sent to the payor (payor, member number, patient demographics)
  • detected — The payor’s version of the details. Present only when CONFIRMED. If detected values differ from requested, review the differences — the payor’s values are generally more reliable.
  • error — Why the payor could not confirm the plan. Present only when NOT_CONFIRMED. Error types are AAA (payor rejection), CAQH_CORE_ERROR (clearinghouse error), or INTERNAL_ERROR.

​
What to do with confirmation results

  • null — No confirmation was performed. Proceed with creating the patient plan using the returned values as-is.
  • CONFIRMED — You’re good to go. Create the patient plan using the result values. If detected values differ from requested (e.g., a corrected member number or date of birth), verify the corrections look right before proceeding.
  • NOT_CONFIRMED — This does not necessarily mean the plan details are wrong. The payor may have been temporarily unavailable, or there may have been an internal issue. The error field may provide a clue, but it’s not guaranteed to be actionable. Double-check what was entered, make any corrections if needed, and retry — or go ahead and create the patient plan anyway. Confirmation is not required to proceed.
See the GET endpoint for full response examples.