Skip to main content

​
Thrizer Support Explanation Patterns (Canonical)

Last Updated: 2026-04-07 Status: Canonical

​
Purpose

Defines standardized explanation patterns used to translate Thrizer system behavior into clear, consistent support responses. This file:
  • Composes logic across canonical rule files
  • Produces user-facing explanations without introducing new logic
  • Ensures consistency across support interactions

​
Scope

This file is:
  • A composition and explanation layer
  • Dependent on canonical rule files
This file is NOT:
  • A source of system rules
  • A source of eligibility, pricing, or reimbursement decisions
  • Allowed to override canonical documentation

​
Authority Constraints

​
Rule: Non-Override

This file must not override:
  • Payment Model
  • Pricing Rules
  • Payment Eligibility Rules
  • Reimbursement Reasoning Rules
  • Product System Map

​
Rule: Canonical Field Usage

This file may use:
  • Canonical normalized inputs:
    • PRIMARY_INSURANCE_ON_FILE
    • DEDUCTIBLE_MET
    • ALLOWED_AMOUNT_VERIFIED
    • COVERAGE_VERIFIED
  • Canonical system fields:
    • claim_status
    • payment_type
  • Canonical derived conditions:
    • successful_claim_exists (from successful claim definition)
No new input systems may be introduced.

​
Rule: External Determination

The following are always determined by the insurer:
  • allowed_amount
  • reimbursement_amount
  • claim approval or denial
  • deductible application
These must never be guaranteed or inferred.

​
Retrieval Guidance

Use this file when:
  • The user asks “why” something happened
  • The answer requires combining multiple rule domains
  • The question involves:
    • estimate vs actual differences
    • claim outcomes
    • reimbursement confusion
    • adjustments
    • Thrizer Pay availability
    • system timelines
Do NOT use this file for:
  • calculating reimbursement
  • determining eligibility
  • pricing or fee logic

​
Pattern Structure

Each pattern is a deterministic retrieval unit:
  • Pattern ID
  • Intent Triggers
  • Required Inputs
  • Rule Sources
  • Explanation Logic
  • Output Components (atomic, reusable)
  • Constraints

​
Patterns

​
EXP-ESTIMATE-VS-ACTUAL-001

Intent Triggers:
  • cost difference
  • unexpected charge
  • estimate mismatch
Required Inputs:
  • ALLOWED_AMOUNT_VERIFIED
  • claim_status (optional)
Rule Sources:
  • Payment Model
  • Product System Map (First-Claim Calibration)
  • Benefit Check Failures

​
Explanation Logic

  1. Before a claim is processed:
    • allowed amount is estimated
  2. ALLOWED_AMOUNT_VERIFIED = false:
    • estimate is based on benefit check data
  3. After a successful claim:
    • allowed amount becomes verified
    • system calibrates to actual insurer behavior
  4. If estimate differs from actual:
    • financial responsibility changes

​
Output Components

  • “Initial costs are based on estimates from your insurance benefits.”
  • “The exact amount is only confirmed after your insurance processes the claim.”
  • “Once processed, your actual cost may differ from the estimate.”

​
Constraints

  • Do not define allowed amount before claim
  • Do not guarantee estimate accuracy

​
EXP-CLAIM-OUTCOME-001

Intent Triggers:
  • $0 reimbursement
  • approved but not paid
  • claim denied
Required Inputs:
  • claim_status
  • DEDUCTIBLE_MET
Rule Sources:
  • Product System Map (Claim Outcomes)
  • Reimbursement Reasoning Rules
  • Insurance Definitions

​
Explanation Logic

  1. claim_status = Approved:
    • claim accepted by insurer
  2. If DEDUCTIBLE_MET = false:
    • allowed amount may be applied to deductible
    • reimbursement may be:
      • $0, or
      • partial (if deductible remaining is less than allowed amount)
  3. If DEDUCTIBLE_MET = true:
    • reimbursement follows coinsurance
  4. claim_status = Denied:
    • no reimbursement
    • no deductible credit

​
Output Components

  • “An approved claim means the insurer accepted it, not that they will always pay money.”
  • “If your deductible isn’t met, the amount may be applied to your deductible instead of reimbursed.”
  • “Depending on your remaining deductible, you may receive partial reimbursement.”

​
Constraints

  • Do not equate Approved with reimbursement
  • Do not assume full or zero reimbursement without inputs

​
EXP-PAYMENT-TIMELINE-001

Intent Triggers:
  • what happens after payment
  • reimbursement timing
  • process explanation
Required Inputs:
  • payment_type
Rule Sources:
  • Payment Model
  • Product System Map (Charge + Claim)
  • Reimbursement Timing

​
Explanation Logic

  1. Clinician creates Charge
  2. System:
    • charges client
    • submits claim (if applicable)
  3. Claim is processed by insurer
  4. Reimbursement occurs if applicable
  5. Timing:
    • typically 4–6 weeks
    • controlled by insurer

​
Output Components

  • “Your payment is processed when the session is charged.”
  • “A claim is submitted to your insurance automatically when applicable.”
  • “Insurance typically processes claims in about 4 to 6 weeks.”

​
Constraints

  • Do not guarantee timing
  • Do not describe insurer internal processes

​
EXP-THRIZERPAY-ELIGIBILITY-001

Intent Triggers:
  • Thrizer Pay unavailable
  • cannot select Thrizer Pay
Required Inputs:
  • PRIMARY_INSURANCE_ON_FILE
  • DEDUCTIBLE_MET
  • COVERAGE_VERIFIED
  • successful_claim_exists
Rule Sources:
  • Payment Eligibility Rules
  • Thrizer Pay Rules
  • Product System Map
  • Benefit Check Failures

​
Explanation Logic

Thrizer Pay requires all:
  1. Primary insurance must be present
  2. Deductible must be met
  3. At least one successful claim must exist (coverage calibration established, coverage_verified must be true)
If any condition is unmet → not available

​
Output Components

  • “Thrizer Pay is only available once your insurance is fully confirmed.”
  • “This includes having active insurance, verified coverage, and meeting your deductible.”
  • “At least one processed claim is needed so the system understands your actual coverage.”

​
Constraints

  • Do not imply partial eligibility
  • Do not bypass claim history requirement

​
Conflict Note

  • Canonical Thrizer Pay Rules allow post-calibration adjustments (additional charge or refund)
  • External descriptive materials may differ
→ Canonical rules take precedence

​
EXP-ADJUSTMENT-RECONCILIATION-001

Intent Triggers:
  • additional charge after claim
  • refund after claim
  • balance adjustment
Required Inputs:
  • ALLOWED_AMOUNT_VERIFIED = true
  • claim_status = Approved
Rule Sources:
  • Payment Model
  • Reimbursement Reasoning Rules
  • Thrizer Pay Rules
  • Product System Map

​
Explanation Logic

  1. Initial charge is based on estimate
  2. Claim processed → actual values determined by insurer
  3. Compare:
    • estimated responsibility
    • actual responsibility
  4. If difference exists:
    • system adjusts balance
  5. Adjustment may result in:
    • additional charge OR refund

​
Output Components

  • “Your initial charge was based on an estimate.”
  • “Once your insurance processed the claim, the actual cost was determined.”
  • “If there is a difference, your balance is adjusted accordingly.”

​
Constraints

  • Always attribute adjustments to insurer-determined values
  • Do not describe as system error

​
Composition Map

  • cost_difference →
    • EXP-ESTIMATE-VS-ACTUAL-001
      • EXP-ADJUSTMENT-RECONCILIATION-001
  • $0_reimbursement →
    • EXP-CLAIM-OUTCOME-001
  • thrizer_pay_unavailable →
    • EXP-THRIZERPAY-ELIGIBILITY-001
  • process_question →
    • EXP-PAYMENT-TIMELINE-001

​
Composition Rules

​
Rule: Deterministic Combination

Only combine patterns defined above.

​
Rule: No Duplication

Reuse output components. Do not repeat equivalent statements.

​
Rule: Output Order

  1. Eligibility
  2. Timeline
  3. Outcome
  4. Adjustment

​
Disallowed Behavior

  • Do not:
    • introduce new logic
    • infer missing inputs
    • override canonical rules
    • guarantee insurer outcomes
If inputs are missing: → respond with uncertainty

​
EXP-INNETWORK-CONTRACT-001

Intent Triggers:
  • can I submit OON if I’m in-network
  • do I need to terminate contract
  • in-network vs out-of-network billing
  • can I use Thrizer if I’m contracted
Required Inputs:
  • none
Rule Sources:
  • External (insurer/provider contract)

​
Explanation Logic

  1. Thrizer supports out-of-network claim submission workflows
  2. However:
    • Whether a provider can submit out-of-network claims depends on their contract with the insurance carrier
  3. If a provider is in-network:
    • their agreement with the insurer may restrict or prohibit out-of-network billing
  4. Providers may need to review or modify their agreement depending on contract terms

​
Output Components

  • “Thrizer supports out-of-network claim submission, but whether you can use it depends on your contract with the insurance provider.”
  • “If you’re in-network with a plan, your agreement with that insurer may limit how you can bill for services.”
  • “Some contracts may restrict out-of-network billing, so you may need to review or modify your agreement.”

​
Constraints

  • Do not state that contract termination is required
  • Do not generalize across insurers
  • Do not block usage at the system level
  • Always label as externally determined

​
Explaining Thrizer Workflows (Charge-Based vs Superbill-Based)

Thrizer supports multiple workflows for submitting out-of-network claims. These workflows differ based on how claims are generated.

​
Core distinction

There are two ways claims are generated in Thrizer:
  1. Structured (Charge-Based) Workflow
    • Claims are generated automatically from appointment and billing data entered when charging a client through Thrizer
    • Claim submission is triggered by a successful charge
  2. Document (Superbill-Based) Workflow
    • Claims are generated from superbills uploaded to Thrizer
    • Claim submission is triggered by a successful superbill upload
Both workflows use similar underlying claim data (e.g. CPT codes, diagnosis codes), but differ in how that data is provided and submitted.

​
Support explanation rule

When explaining these workflows, support should:
  • Describe both workflows clearly and neutrally
  • Map the user’s stated preferences or workflow to the corresponding option
  • Use conditional explanations (e.g. “If you prefer…”, “If you are currently…”)
Support should not:
  • Recommend or prioritize one workflow over the other
  • Describe one workflow as “better”, “more favorable”, or “preferred”
  • Frame the distinction as “copay vs full pay” or “automated vs manual”

​
Explanation guidance

Use workflow-based mapping:
  • If a user is charging clients through Thrizer → explain the structured (charge-based) workflow
  • If a user is not charging through Thrizer or their client prefers to upload superbills → explain the document (superbill-based) workflow
Focus explanations on:
  • How claims are triggered
  • What the user needs to do
  • What happens after submission
Avoid introducing comparisons that imply ranking or superiority.

​
Explaining the Thrizer Widget (Benefits Calculator)

The Thrizer Widget is a surface-level entry point for running out-of-network benefit checks.

​
What the widget is

  • The widget uses the same underlying logic as standard Thrizer benefit checks
  • It applies this logic to a specific clinician’s practice, including their rates and services
  • It allows prospective clients to check their out-of-network benefits and estimated costs before starting care
  • It can be shared as a link or embedded on a clinician’s website
The widget does not introduce a new calculation method or different insurance logic. It uses the same benefit check system, configured with practice-specific inputs.

​
How to interpret widget results

Widget results should be treated the same as any benefit check:
  • All values are estimates based on information returned by the insurance plan
  • Final reimbursement and coverage are determined by the insurer after claims are processed
  • Estimates may change as claims are submitted and processed
Support should apply the same explanation rules used for standard benefit checks when discussing widget outputs.

​
Support usage guidelines

Support may reference or recommend the widget when:
  • A prospective client wants to understand expected costs before starting care
  • A clinician wants to help clients pre-check benefits and reduce intake friction
When doing so, support should:
  • Position the widget as a way to preview estimated costs
  • Clarify that results are estimates, not guarantees
  • Avoid presenting widget outputs as final or confirmed reimbursement amounts

​
Constraints

  • The widget should not be used to guarantee reimbursement or final costs
  • It does not replace claim adjudication by the insurer
  • It follows all standard benefit check limitations and uncertainty rules

​
1099 Request Handling

1099 forms are fulfilled manually by the support team upon request.

​
Request requirements

To process a 1099 request, support must have:
  • The practice email address associated with the Thrizer account
If no tax year is specified, assume the request is for the current tax year. If a different tax year is needed, the requester must specify it.

​
Support workflow

  • Requests are handled manually by the support team
  • Once received, support will process the request and send the 1099 form via email
  • Requests are fulfilled within standard support email response timelines

​
Constraints

  • 1099 forms are only provided upon request, if not already sent by the system
  • Support may follow up if additional information is needed to complete the request