Skip to main content

​
FILE: benefit_check_failures_and_manual_verification.md

​
Thrizer Benefit Check Failures and Manual Verification

Last Updated: 2026-03-23 Status: Canonical
Purpose: Defines how to interpret and respond to failed, incomplete, or ambiguous insurance benefit checks. Use this file when automated verification does not return sufficient or reliable data, and the system must determine whether: coverage status can be safely interpreted required benefit fields are missing manual verification is necessary uncertainty must be explicitly communicated to the user This file establishes strict rules to prevent false conclusions about coverage, reimbursement, or session cost when verification data is incomplete or unavailable. Do not use this file for: calculating reimbursement or session cost defining insurance terminology determining product capabilities Use this file to enforce conservative, non-assumptive responses and to route cases to manual verification when required data is missing or unreliable.

​
Global Rules

​
Rule: Automated Failure Is Not Coverage Denial

An automated benefit check failure is not, by itself, evidence that coverage is absent.

​
Rule: Incomplete Automated Response Is Not Coverage Denial

An incomplete automated benefit response is not, by itself, evidence that coverage is absent.

​
Rule: General Medical Eligibility Is Not Behavioral Health Confirmation

A general medical eligibility response does not, by itself, confirm behavioral health benefit details.

​
Rule: Missing Digital OON Details Is Not OON Denial

Absence of digital out-of-network benefit details does not, by itself, mean out-of-network coverage is unavailable.

​
Rule: Benefit Check Is Estimate Only

A benefit check is an estimate based on available insurer information. Benefit check data may be used to estimate allowed amount prior to claim submission. These estimates are provisional and must be replaced with insurer-determined values after claim adjudication.

​
Rule: Benefit Check Does Not Guarantee Reimbursement

A benefit check does not guarantee reimbursement.

​
Rule: Carrier Determines Final Outcome

Final claim outcome and reimbursement are determined by the insurance carrier.

​
Rule: No Assumed Values

Do not fill missing benefit fields with assumptions.

​
Rule: Manual Verification Boundary

Manual verification may be required when automated verification does not provide enough information to interpret benefits safely.

​
Normalized Failure Conditions

​
Condition: Member Record Mismatch

  • member_record_mismatch = true
If submitted insurance information does not exactly match insurer records, automated verification may fail or return no usable benefit data. Do not interpret this condition as absence of coverage.

​
Condition: Required Benefit Fields Missing

  • required_field_missing = true
Required fields:
  • deductible status
  • coinsurance percentage
  • allowed amount details
  • out-of-network reimbursement rules
If required benefit fields are missing, do not provide a reliable session cost estimate. Do not infer missing values.

​
Condition: Automated Verification Timeout or Minimal Response

  • automated_verification_timeout = true
  • automated_response_minimal = true
Some insurer systems do not return complete behavioral health or out-of-network benefit data through real-time eligibility systems. Do not interpret timeout, minimal response, or lookup failure as a coverage decision.

​
Condition: Manual Phone Verification Required

  • manual_verification_required = true
Some plans require benefit details to be confirmed through manual phone verification. Do not interpret this condition as absence of coverage.

​
Condition: Recent Coverage Change

  • recent_coverage_change = true
Recently changed coverage may not yet be available through automated verification systems. Do not assume inactive coverage solely because systems have not synchronized.

​
Condition: Behavioral Health Managed Separately

  • behavioral_health_managed_separately = true
Some plans use a separate administrator for behavioral health benefits. Automated responses may show general medical coverage while omitting behavioral health details. Behavioral health benefit details may need to be retrieved from a separate system. Do not conclude that therapy benefits are absent based only on general medical eligibility data.

​
Benefit Check Usability

​
Definition

A benefit check is considered usable if Thrizer is able to return benefit information for a client’s insurance plan.

​
Usable Condition

A benefit check is usable when:
  • Benefit information is successfully returned through:
    • automated system checks, OR
    • manual verification workflows
System interpretation:
  • Returned benefit data is sufficient to:
    • proceed with claim submission workflows
    • generate reimbursement estimates

​
Not Usable Condition

A benefit check is not usable when:
  • No benefit information can be obtained:
    • not via automated system, AND
    • not via manual verification
System behavior:
  • If a benefit check is not usable:
    • Thrizer cannot support claim submission for that insurance plan
    • The system must not proceed with payment or claim workflows for that client-insurer pair

​
Accuracy Clarification

  • Benefit check data is:
    • generally reliable for determining if claims can be processed
    • not guaranteed to match final reimbursement amounts
Constraint:
  • Estimates derived from benefit checks may differ from actual insurer apporval (adjudication)
  • Final reimbursement is always determined by the insurer

​
Coinsurance validation:

  • Coinsurance from benefit checks can be treated as confirmed
  • However, final determination remains with the insurer and may change

​
Authority of Benefit Check vs Claims

  • Benefit check is authoritative for:
  • Deductible status
  • Coinsurance
  • Coverage verification
  • Benefit check is NOT authoritative for:
  • Allowed amount

​
Condition: OON Details Not Exposed Digitally

  • oon_details_not_exposed_digitally = true
Some insurers confirm coverage but do not expose detailed out-of-network benefit structure through automated systems. Do not conclude that out-of-network coverage is absent unless explicitly confirmed.

​
Handling Benefit Check Failures

If automated benefit checks fail or provide minimal response, manual verification may be required. Some common failure scenarios include:
  • Member Record Mismatch: If the submitted insurance details do not match insurer records, automated checks may fail. This does not mean coverage is absent.
  • Missing Benefit Fields: Required fields like deductible status, coinsurance percentage, and allowed amount details must be present for a reliable estimate. If these are missing, the benefit check should not be considered final.
  • Timeouts and Minimal Responses: Insurer systems may not return sufficient data, requiring manual verification via phone or another method.

​
Manual Verification Requirements

When automated verification cannot provide enough information, Thrizer will route cases to manual verification:
  • Contact the insurance company for missing benefit details.
  • Confirm deductible status, coinsurance behavior, and reimbursement rules.

​
Eligibility

A usable benefit check is equivalent to eligibility. If a benefit check is usable, the client is considered eligible. If a benefit check is not usable, the client is not eligible.

​
Rule: Usable Benefit Check Overrides Plan Classification

If a benefit check is usable, the plan is considered eligible for Thrizer workflows regardless of insurer classification. Implications:
  • A usable benefit check enables:
    • claim submission workflows
    • supported payment types (subject to Payment Eligibility Rules)
  • This applies even if the plan is classified as:
    • Medicare
    • Medicaid
    • or any government program
Constraint:
  • Plan classification does not block workflows when a benefit check is usable
  • Usability is determined solely by whether sufficient benefit information is returned
Clarification:
  • Insurer classification remains relevant for:
    • routing
    • expectation setting
  • But does not override usability once confirmed

​
FILE: payment_eligibility.md

​
Thrizer Payment Eligibility Rules

Last Updated: 2026-04-07 Status: Canonical
Purpose: Determines which payment types are available for a client based on deductible status and eligibility verification. Use this file when: Deciding whether a specific payment type (superbill, OON Pay, Thrizer Pay) is allowed Evaluating eligibility constraints before presenting or processing payment options Resolving conflicts about why a payment type is unavailable Do not use this file for: Pricing logic, fee calculations, or reimbursement amounts Claim outcomes or insurer-specific behavior All eligibility decisions must be resolved using this file before applying any pricing or payment logic.

​
Normalized Inputs

  • deductible_status ∈
  • Eligibility is defined as insurance confirmed via benefit check (see Canonical Terms)

​
Payment Type Availability

​
Pre-Deductible

  • payment_type = superbill → allowed
  • payment_type = oon_pay → allowed, no fee applied
  • payment_type = thrizer_pay → not allowed

​
Post-Deductible

  • payment_type = superbill → allowed
  • payment_type = oon_pay → allowed, fee applied
  • payment_type = thrizer_pay → allowed only if:
    • eligibility_verified is defined in Thrizer Pay Rules

​
System Constraint

  • pricing rules do not determine eligibility
  • eligibility must be resolved before pricing is applied

​
Benefit Check Requirement by Payment Type

  • OON Pay and Thrizer Pay require a completed benefit check
  • If no benefit check is available, these payment methods are not eligible and cannot be used for charging
  • Self-Pay does not require a benefit check and remains available regardless of benefit check status

​
FILE: payment_model.md

​
Payment Model (Canonical, RAG-Optimized)

Last Updated: 2026-04-07 Status: Canonical
Purpose: Provides the canonical source of truth for how money moves through Thrizer. Use this document when a question requires deterministic understanding of payment behavior, including:
  • which payment model applies (Self-Pay, OON Pay, Thrizer Pay)
  • who pays, how much they pay, and when they pay
  • how fees are calculated and applied
  • who receives reimbursement and how funds are routed
  • how and when clinicians are paid
  • how deductible, allowed amount, and coinsurance affect financial outcomes
  • when Thrizer Pay is eligible and why
This document should be used to answer any question that involves financial responsibility, payment flow, or payout mechanics. Do NOT use this document for:
  • insurer-specific rules or coverage decisions
  • claim approval or denial logic
  • UI steps or operational workflows
If a question involves money movement, payment structure, or financial outcomes, this is the primary routing file.

​
Core System Model

Thrizer separates three independent components:
ComponentDefinition
Session FeeAmount set by clinician
Allowed AmountAmount insurer uses to calculate reimbursement
Client ResponsibilityPortion of allowed amount assigned to client
Key Rule
Insurance determines reimbursement. Thrizer facilitates payment and claim submission.

​
Payment Types Overview

​
Self-Pay

Definition
Client pays full session fee without insurance involvement. Behavior
  • Client Payment: 100% of session fee
  • Claim Submission: No
  • Reimbursement: None
  • Thrizer Fee: None
Requirements
  • No insurance required
  • No diagnosis required

​
OON Pay

Definition
Client pays full session fee upfront. Thrizer submits claim. Reimbursement is returned to client. Behavior
  • Client Payment: 100% of session fee upfront, charged when the clinician creates a Charge
  • Claim Submission: Automatic, triggered when the clinician creates a Charge
  • Reimbursement Recipient: Client
  • Thrizer Fee: 1% of session fee (only after deductible is met)
Reimbursement Flow
Insurance → Thrizer → Client Bank Account Deductible Interaction
  • Before deductible: reimbursement is $0
  • After deductible: reimbursement follows coinsurance rules

​
Thrizer Pay

Definition
Client pays only estimated responsibility upfront. Thrizer advances remaining session fee to clinician. Behavior
  • Client Payment: estimated responsibility + 5% of session fee, charged when the clinician creates a Charge
  • Claim Submission: Automatic, triggered when the clinician creates a Charge
  • Reimbursement Recipient: Thrizer
  • Thrizer Fee: 5% of session fee
Reimbursement Flow
Insurance → Thrizer → Internal reconciliation Clinician Payment
  • Receives full session fee (minus processing fee) upfront

​
Charge Trigger and Claim Submission

For payment types with automatic claim submission, the canonical trigger event is clinician Charge creation.

​
Trigger Rule

  • A claim is submitted automatically after a Charge is created and the client’s payment is successfully processed.
  • At that same time, the client’s payment method is charged.
  • This rule applies to:
    • OON Pay
    • Thrizer Pay

​
Required Condition

  • The Charge must contain the claim-related information required by the system for submission.

​
Clarification

  • Automatic claim submission is not a separate manual step in OON Pay or Thrizer Pay.
  • Manual claim submission applies only to client-submitted claim workflows such as superbill upload or manual claim entry.

​
Clinician Payout Rules

Applies to All Payment Types
  • Payout Amount:
    session fee − ~3% payment processing fee
  • Payout Timing:
    Charges before Thursday cutoff → paid Friday
  • No Clawback Rule
    Clinician payouts are not reversed if:
    • claim is denied
    • reimbursement is lower than expected
    • reimbursement is $0

​
Thrizer Pay Eligibility

Eligibility defined in Thrizer Pay Rules

​
Deductible Logic

​
Before Deductible is Met

  • Client pays full session fee
  • Insurance processes claim
  • Allowed amount is applied to deductible
  • Reimbursement = $0 (typical case)

​
After Deductible is Met

  • Insurance reimburses based on:
    • allowed amount
    • coinsurance percentage
Client Responsibility Formula
allowed amount × coinsurance
  • (session fee − allowed amount, if applicable)

​
Allowed Amount Rules

Definition
Allowed amount is the maximum amount insurance uses for reimbursement calculation. Rules
  1. Reimbursement is based on allowed amount, not session fee
  2. If session fee < allowed amount:
    → session fee becomes the effective allowed amount
  3. Allowed amount is unknown until first claim is processed, initially it is estimated
  4. Initial estimates are based on benefit check data

​
Estimate vs Actual Behavior

​
Before First Claim

  • Estimates are based on historical averages
  • Accuracy is limited

​
After First Claim

  • Allowed amount becomes known
  • Reimbursement becomes predictable
Early Claim Behavior
  • Adjustments may occur
  • Estimated responsibility may differ from actual

​
Claim Structure Dependency

  • One charge → one claim
  • One claim → one CPT code
  • One session fee per claim

​
Claim Submission Requirements A Charge is considered claim-submittable only if all required claim fields are present at the time of Charge creation.

​
Required Fields (Charge Input) Provider Information:

  • Provider Name
  • Provider NPI
  • Provider TIN Service Information:
  • Appointment Date(s)
  • CPT Code(s) (Service Codes)
  • ICD-10 Code (Diagnosis Code)
Financial Information:
  • Billed Amount

​
Client & Insurance Information (System-Populated)

  • The following fields are NOT required as Charge inputs:
  • Client Name
  • Insurance Plan
  • Member ID
  • Payer Information
  • These fields are automatically populated from the client’s Thrizer account

​
Validation Rule

  • All required fields must be present at Charge creation
  • If any required field is missing:
  • The Charge is NOT claim-submittable ### System Behavior
  • If all required fields are present:
  • Claim is automatically submitted when the clinician creates the Charge
  • If required fields are missing:
  • Claim submission must not proceed
  • The system must:
  • block submission OR
  • route to operational/manual handling (defined elsewhere)

​
Constraint

  • A Charge cannot partially submit a claim
  • Claim submission is atomic and requires full data completeness

​
Global Constraints (Payment-Relevant)

  • A single charge cannot be split across multiple payment methods
  • Multiple CPT codes cannot be included in one claim
  • Multiple charges cannot be bundled into a single claim

​
Reimbursement Routing

​
OON Pay

Insurance → Thrizer → Client Bank Account

​
Thrizer Pay

Insurance → Thrizer → Internal reconciliation

​
Non-Guarantee Statement

  • Reimbursement outcomes are determined solely by the insurance carrier
  • Thrizer does not guarantee:
    • reimbursement amount
    • claim approval
    • processing time

​
Payout Trigger Schedule

  • Payouts are automatically initiated on:
    • Tuesdays (early morning)
    • Fridays (early morning)
  • At each payout trigger:
    • 100% of Thrizer Balance is transferred
    • Transfer is sent to the connected bank account on file

​
Payout Inclusion Logic

Charges are included in the next scheduled payout based on when the charge is created:
  • Monday → Tuesday payout
  • Tuesday → Friday payout
  • Wednesday → Friday payout
  • Thursday → Friday payout
  • Friday → Tuesday payout
  • Saturday → Tuesday payout
  • Sunday → Tuesday payout
Rule:
  • Charges remain in the Thrizer Balance until the next scheduled payout is triggered
  • Payout timing is not dependent on claim status or insurer reimbursement

​
Settlement Timing

  • After payout initiation:
    • Funds are expected to arrive within:
      • 0–1 business days

​
External Dependency

  • Insurer reimbursement timing is determined externally by the insurance carrier
  • Reimbursement timing does not affect payout timing

​
Retrieval Keywords (for RAG)

Use this document when user asks:
  • “How does Thrizer Pay work?”
  • “What does the client pay?”
  • “What fees does Thrizer charge?”
  • “Who gets reimbursed?”
  • “How does OON Pay work?”
  • “When can Thrizer Pay be used?”
  • “What happens before deductible is met?”
  • “How is coinsurance calculated?”
  • “How do clinicians get paid?”

​
Exclusion Keywords (Route Elsewhere)

Do NOT use this document for:
  • UI instructions → Capability Maps
  • Insurance definitions → Insurance Definitions
  • Claim failures → Benefit Check Failures
  • CPT code behavior → CPT Dataset
  • Support actions → Support Playbooks

​
FILE: pricing_rules.md

​
Pricing Rules

Last Updated: 2026-04-06 Status: Canonical
Purpose: Defines the canonical source of truth for all Thrizer pricing behavior. Use this file when a query requires deterministic fee or payout outcomes, including:
  • what fee applies for a given payment_type
  • how a fee is calculated (amount, percentage, base)
  • when a fee is charged or deducted
  • whether a fee is refunded based on claim_outcome
  • how reimbursement routing affects fees
  • what the therapist is paid and when
This file should be used whenever the question can be reduced to:
  • “What will be charged?”
  • “When is it charged?”
  • “Is the fee kept or refunded?”
  • “Who receives the reimbursement?”
  • “How much does the therapist receive?”
Do not use this file for:
  • defining insurance terms or concepts
  • predicting or explaining reimbursement amounts
  • determining claim outcomes or insurer behavior
  • deciding eligibility for payment types
All outputs from this file must be rule-based and exact, derived only from: session_fee payment_type reimbursement_amount claim_outcome This file does not support estimation, interpretation, or insurer-dependent logic.

​
Core Definitions

​
Session Fee

The therapist’s full session fee. All percentage-based fees are calculated using session_fee.

​
Client Pricing Rules

​
OON Pay

​
Fee Amount

  • 1% of session_fee

​
Fee Base

  • session_fee
  • fee is not calculated using reimbursement_amount

​
Fee Trigger

  • reimbursement_amount > 0

​
Fee Timing

  • deducted when reimbursement is distributed to client

​
Fee Suppression

  • if reimbursement_amount = 0 → no fee charged

​
Reimbursement Routing

  • reimbursement is sent to client from Thrizer

​
Thrizer Pay

​
Fee Amount

  • 5% of session_fee

​
Fee Base

  • session_fee
  • fee is not calculated using reimbursement_amount

​
Fee Timing

  • charged at time of session

​
Reimbursement Routing

  • reimbursement is routed to Thrizer

​
Fee Refund Conditions

  • if claim_outcome = denied → fee is refunded
  • if claim_outcome ∈ → fee is retained

​
Therapist Payment Protection

  • therapist payout = session_fee
  • therapist payout is not reduced by claim outcomes
  • if client’s card has an issue, therapist will be notified upon making the charge; therapist is responsible for resolving with client

​
Advance Payment Rule

  • Thrizer pays the therapist before claim outcome is known

​
Superbill Upload

​
Fee Amount

  • $2 per session

​
Fee Timing

  • charged at time of submission

​
Success Conditions

  • if claim_outcome = approved → success
  • if claim_outcome = applied_to_deductible → success

​
Refund Conditions

  • if claim_outcome = denied → fee is refunded

​
Reimbursement Routing

  • reimbursement is sent to client

​
Clinician Pricing Rules

​
Payment Platform Fee

​
Fee Amount

  • 3% of session_fee, as card processing fee

​
Fee Trigger

  • applied when clinician processes a payment through Thrizer

​
Fee Independence

  • applies regardless of payment_type

​
Referral Program (Clinician)

​
Eligibility

  • A clinician must sign up using a valid referral code
  • Referral benefit is applied at signup only
  • A clinician may only receive one referral benefit

​
Referrer Benefit

  • The referring clinician receives a waiver of the 3% processing fee
  • The waiver applies to up to $2,500 in processed transaction volume per referred clinician
  • Maximum fee waived per referral = 3% of $2,500
  • The benefit is activated only after the referred clinician submits their first charge

​
Referred Benefit

  • The 3% card processing fee is waived for the referred clinician
  • The waiver applies to up to $2,500 in processed transaction volume
  • Maximum fee waived = 3% of $2,500

​
Scope

  • Applies only to payment transactions processed through Thrizer
  • Does not apply to superbill submissions

​
Limitations

  • Fee waiver applies only to the 3% clinician processing fee
  • All other fees (e.g., client fees) remain unchanged
  • Waiver is based on transaction volume, not total fee amount
  • Referral benefit cannot be applied retroactively or multiple times

​
Referrals (Outbound)

  • A clinician may refer an unlimited number of other clinicians
  • Each referred clinician may receive their own referral benefit upon signup

​
Interaction with Pricing Rules

  • This section overrides the standard 3% processing fee defined above, for eligible transactions up to the $2,500 volume cap
  • After the cap is reached, standard pricing resumes
Source Confidence: Medium

​
Fee Interaction Rules

  • client fees and clinician fees are independent
  • multiple fees may apply simultaneously

​
Therapist Payment Rule

  • therapist payout = session_fee
  • applies across all payment types
  • insurance outcomes do not reduce therapist payout

​
No Subscription Rule

  • no contracts
  • no monthly fees
  • no minimum usage requirements

​
System Constraints

  • fee calculations always use session_fee as base
  • reimbursement_amount is never used as fee base

​
Referral Program (Clinician)

​
Limitation — Waiver Application Boundary

  • The referral fee waiver is applied on a per-charge basis.
  • If a single charge exceeds the remaining waived transaction volume balance:
    • the waiver is not applied to that charge
    • the full 3% clinician processing fee is charged
  • The system does not partially apply the waiver to a portion of a charge.
  • To use remaining waived balance:
    • charges must be equal to or less than the remaining waived transaction volume
…

​
FILE: reimbursement_reasoning_rules.md

​
Thrizer Reimbursement Reasoning Rules

Last Updated: 2026-03-23 Status: Canonical
Purpose: Use this file when the question requires deterministic calculation or explanation of out-of-network reimbursement amounts based on known inputs. This includes:
  • Calculating expected reimbursement for a claim
  • Explaining why reimbursement is $0 vs partial vs full
  • Determining how deductible affects reimbursement
  • Breaking down client responsibility vs insurer payment
  • Classifying claim outcomes (reimbursed, applied to deductible, denied)
  • Explaining the impact of allowed amount vs provider fee
This file should be used only when all required inputs are present or can be reasonably assumed:
  • provider_fee
  • allowed_amount
  • deductible_remaining
  • coinsurance_client_percent
  • claim_status
Do not use this file for:
  • Questions about how claims are submitted, processed, or tracked
  • Questions about product behavior, UX, or system workflows
  • Questions about insurer policies, approval criteria, or allowed amount determination
  • Questions about timing of reimbursement or payments
If a question depends on insurer decisions or missing inputs, treat those as external, non-deterministic factors and do not infer beyond the rules defined here.

​
Normalized Inputs

All reimbursement reasoning must use the following inputs:
  • provider_fee
  • allowed_amount
  • deductible_remaining
  • coinsurance_client_percent
  • claim_status (approved | denied)

​
Core Calculation Variables

​
Provider Fee

Definition: The therapist’s full session rate.

​
Allowed Amount

Definition: The maximum amount recognized by the insurer for the service. Rule: Reimbursement calculations are always based on the lower of the allowed_amount or provider_fee.

​
Coinsurance (Client Share)

Definition: coinsurance_client_percent represents the percentage of allowed_amount the client is responsible for after deductible. Derived: insurer_share_percent = 1 − coinsurance_client_percent

​
Reimbursement Determination Rules

​
Rule 1 — Claim Denied

Condition: claim_status = denied Outcome:
  • reimbursement = 0
  • deductible_applied = 0

​
Rule 2 — Pre-Deductible (Full)

Condition: claim_status = approved
AND deductible_remaining ≥ allowed_amount Outcome:
  • reimbursement = 0
  • deductible_applied = allowed_amount

​
Rule 3 — Partial Deductible

Condition: claim_status = approved
AND deductible_remaining > 0
AND deductible_remaining < allowed_amount Calculation:
  • deductible_applied = deductible_remaining
  • remaining_allowed = allowed_amount − deductible_remaining
  • reimbursement = remaining_allowed × insurer_share_percent

​
Rule 4 — Post-Deductible

Condition: claim_status = approved
AND deductible_remaining = 0 Calculation: reimbursement = allowed_amount × insurer_share_percent

​
Rule 5 — Client Responsibility

Calculation: client_responsibility = provider_fee − reimbursement

​
Allowed Amount Gap

Definition: allowed_gap = provider_fee − allowed_amount Rule: allowed_gap is generally the client’s responsibility in out-of-network billing.

​
Claim Outcome Classification

​
Outcome: Reimbursed

Condition: reimbursement > 0

​
Outcome: Applied to Deductible

Condition: reimbursement = 0
AND deductible_applied > 0

​
Outcome: Denied

Condition: claim_status = denied

​
Critical Clarifications

Rule: An approved claim may result in reimbursement = 0 when deductible_remaining > 0.

​
Estimate vs Final Outcome

Rule: All estimates are based on input values available at the time of calculation. Final outcomes may differ due to changes in:
  • allowed_amount
  • deductible_remaining
  • claim_status

​
Allowed Amount Source of Truth ### Definition

  • The allowed amount is the maximum amount recognized by the insurer for a given service.

​
Source and Timing

  • Before claim submission:
  • Allowed amount is estimated by Thrizer.
  • After claim approval (adjudication):
  • Allowed amount is determined by the insurer based on the processed claim.

​
System Behavior

  • Thrizer uses estimated allowed amounts to:
  • calculate expected reimbursement
  • power Thrizer Pay pricing and client responsibility estimates
  • After a claim is approved (adjudicated):
  • Thrizer updates its internal understanding of the allowed amount using the insurer’s response

​
Estimate Accuracy Guidance

  • Allowed amount estimates are based on historical patterns and available benefit data.
  • These estimates are not guaranteed.
Observed behavior:
  • A majority of actual allowed amounts fall within a narrow range of the initial estimate.
  • However, variance may occur based on:
    • provider
    • location
    • service type
    • insurer-specific adjudication rules
Constraint:
  • Do not represent allowed amount estimates as exact predictions.
  • Do not guarantee any specific variance range.
  • Final allowed amount is always determined by the insurer after claim adjudication.

​
Stability

  • Allowed amounts are generally stable after the first approved (adjudicated) claim for a given context
  • However, insurers may change allowed amounts, which are determined externally

​
Constraint

  • Thrizer does not control the final allowed amount
  • Final allowed amount is always determined by the insurer

​
Non-Deterministic Factors (External)

The following are determined by the insurer and are not defined in this file:
  • allowed_amount determination
  • claim approval or denial
  • deductible tracking across claims
  • reimbursement timing
These must be treated as external inputs.

​
Reimbursement Variance Responsibility

​
Definition

  • Reimbursement variance is the difference between:
    • estimated reimbursement (pre-approval)
    • actual reimbursement (post-apporoval)

​
Responsibility

  • The client is fully responsible for all reimbursement variance
  • This includes:
    • lower-than-expected reimbursement
    • higher-than-expected reimbursement

​
System Behavior

  • Estimates are provided for guidance only and are not guaranteed
  • The system does not:
    • retroactively adjust clinician payment based on actual reimbursement
    • shift financial responsibility to the clinician

​
Clinician Protection

  • Clinicians are not impacted by differences between estimated and actual reimbursement
  • Clinician earnings are not adjusted based on insurer approval (adjudication) outcomes

​
Constraint

  • Final reimbursement is determined by the insurer
  • All financial variance resulting from insurer behavior is borne by the client

​
FILE: support_explanation_patterns..md

​
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

​
FILE: support_operational_rules.md

​
Thrizer Support & Operational Rules

Last Updated: 2026-04-06 Status: Canonical
Purpose: Defines how to handle scenarios where Thrizer’s automated system cannot complete, resolve, or guarantee an outcome and human intervention, user action, or workaround workflows are required. Use this file when a query involves:
  • a failure, limitation, or absence of system automation
  • a manual process, workaround, or exception flow
  • a question about who is responsible (client, clinician, or Thrizer support)
  • a need to determine what happens next when a workflow breaks or stalls
  • support involvement, escalation, or required documentation
  • real-world handling of claims, payments, or insurance when system rules are insufficient
Do not use this file for:
  • deterministic system behavior (pricing, eligibility, reimbursement logic)
  • definitions of insurance or product capabilities
  • expected “happy path” workflows that the system handles automatically

​
Explicitly Defines

  • When support action is required
  • What information must be collected
  • Who is responsible for resolution (client, clinician, Thrizer)
  • What the system does NOT handle automatically
  • Expected timelines (when known)
  • Resolution pathways when workflows fail

​
Explicitly Does NOT Define

  • Pricing logic → see Pricing Rules
  • Reimbursement calculations → see Reimbursement Reasoning Rules
  • Payment eligibility → see Payment Eligibility Rules
  • Product capabilities → see Product System Map
  • System constraints → see Product Constraints & Limitations
  • Insurance definitions → see Insurance Definitions

​
Authority Position

  • Non-authoritative relative to system rules
  • Cannot override:
    • Payment Model
    • Pricing Rules
    • Product Constraints
  • Complements canonical documents with operational handling

​
Core Principle

If a scenario cannot be resolved through:
  • system automation
  • deterministic rules
→ it is handled through Support & Operational Rules

​
Operational Scenarios

​
Variable Practitioner Investigation

Actor: Support Trigger Condition:
A practitioner type falls under variable or uncertain support categories (e.g., OT, PT, SLP, RD, medical specialists) System Behavior:
The system does not determine reimbursement or compatibility based on practitioner type alone Required User Action:
Provide additional service details, which may include:
  • CPT code(s) used
  • Service type or description
Support Action:
  • Review provided CPT codes and service details
  • Evaluate prior workflow compatibility or escalate internally if needed
Limitations:
  • CPT codes do not guarantee reimbursement
  • Reimbursement and claim acceptance are determined by the insurer
Resolution Outcome:
  • Support provides guidance based on available information
  • Or escalates for further investigation
Source Confidence: Medium

​
Manual Insurance Verification

Actor: Client or Clinician Trigger Condition:
Insurance plan cannot be found or linked in system System Behavior:
Automated benefit check fails or cannot proceed Required User Action:
Provide:
  • front of insurance card
  • back of insurance card
  • date of birth
Support Action:
  • manually verify out-of-network benefits
  • link insurance plan to account
Limitations:
  • dependent on insurer systems
  • may require follow-up
Resolution Outcome:
Insurance plan becomes linked and usable Source Confidence: High

​
Benefit Calculator Usage Guidance

Actor: Clinician / Client Purpose:
Provide a way to check and understand out-of-network benefits before initiating care or billing. Guidance:
  • Use the benefit calculator for clients where the clinician is out-of-network with the client’s insurance
  • The calculator can be used:
    • by clinicians within the portal
    • by clients via the embedded widget or external link
  • The calculator is intended for use prior to intake, consultation, or session billing
System Behavior:
  • The benefit calculator returns estimated out-of-network benefit information
  • Results are subject to insurer verification and are not guaranteed
Limitations:
  • Use of the calculator is not required to create a charge or submit a claim
  • Results do not guarantee coverage or reimbursement
Source Confidence: Medium

​
Benefit Checker Failure Pattern

Actor: System Trigger Condition:
Repeated benefit check failures for insurer or plan System Behavior:
Automated check does not return results Required User Action:
Provide insurance details Support Action:
Manual benefit verification Limitations:
Dependent on insurer system accessibility Resolution Outcome:
  • benefits confirmed manually
  • or inability to verify confirmed
Source Confidence: High

​
Claim Status Inquiry

Actor: Client or Clinician Trigger Condition:
User requests claim status System Behavior:
Claims remain in processing state Required User Action:
Wait standard processing window Support Action:
Review claim if contacted Limitations:
Typical processing time:
  • 4–6 weeks
Resolution Outcome:
  • claim processes normally
  • or escalates if delayed
Source Confidence: Medium

​
Failed or Stalled Claims

Actor: System / Support Trigger Condition:
Claim fails or stops progressing System Behavior:
User notified of issue Required User Action:
Provide requested information Support Action:
  • investigate with insurer
  • request missing data
  • resubmit or correct claim
Limitations:
Final outcome determined by insurer Resolution Outcome:
  • claim corrected and processed
  • or denied
Source Confidence: Medium

​
Manual Claim Submission (Superbill Upload)

Actor: Client Trigger Condition:
Client uploads superbill instead of using automated billing System Behavior:
Claim generated from uploaded document Required User Action:
Upload valid superbill including:
  • provider name
  • NPI
  • TIN
  • service dates
  • billed amount
  • diagnosis code
  • CPT codes
Support Action:
Assist if parsing or submission fails Limitations:
  • subject to insurer timely filing limits
  • reimbursement not guaranteed
Resolution Outcome:
Claim submitted for insurer processing Source Confidence: High

​
Credit Card Failure Handling

Actor: Clinician Trigger Condition:
Payment method is declined System Behavior:
Failure displayed in real time Required User Action:
Clinician must follow up with client Support Action:
None by default Limitations:
Thrizer does not collect payment on behalf of clinician Resolution Outcome:
Payment must be retried or updated Source Confidence: High

​
Payment Method Requirement and Responsibility

Actor: Client / Clinician Trigger Condition:
A charge is created or attempted for a client System Behavior:
A valid payment method must be on file for a charge to succeed. Responsibility:
  • Either the client or clinician may add a payment method
  • The clinician is responsible for ensuring a valid payment method is present before initiating a charge
Failure Behavior:
  • If no valid payment method is on file:
    • The charge fails
    • No payment is collected
    • No claim is submitted
Required User Action:
  • Add or update a valid payment method before retrying the charge
Support Action:
  • None by default
Limitations:
  • Thrizer does not collect payment on behalf of the clinician
  • Payment success is required for claim submission
Resolution Outcome:
  • Charge succeeds once a valid payment method is added
  • Claim submission proceeds only after successful payment
Source Confidence: High

​
Refund Responsibility

Actor: Clinician Trigger Condition:
Client requests refund System Behavior:
Thrizer does not initiate refunds Required User Action:
Client contacts clinician Support Action:
None Limitations:
Thrizer functions as payment processor only Resolution Outcome:
Refund issued by clinician Source Confidence: High

​
Payment Method Update Limitation

Actor: Client Trigger Condition:
Client attempts to change payment method after charge System Behavior:
Retroactive changes not supported Required User Action:
Use updated method for future payments Support Action:
None Limitations:
Past transactions cannot be modified Resolution Outcome:
New method applies to future charges only Source Confidence: High

​
Split Payment Workaround (Manual)

Actor: Client / Support Trigger Condition:
Client requests split payment across methods System Behavior:
System does not support split payment Required User Action:
Process separate self-pay charges Support Action:
Manually submit combined claim if requested Limitations:
  • may cause claim issues
  • not system-supported workflow
Resolution Outcome:
Claim may be submitted manually Source Confidence: Medium

​
Multiple Services in One Session

Actor: Clinician Trigger Condition:
Session includes multiple CPT services System Behavior:
System requires separate charges Required User Action:
Submit each CPT as separate charge Support Action:
None Limitations:
Single CPT per claim enforced Resolution Outcome:
Multiple claims submitted Source Confidence: High

​
No-Show / Cancellation Fees

Actor: Clinician Trigger Condition:
Missed or cancelled session System Behavior:
No claim submission Required User Action:
Charge client directly Support Action:
None Limitations:
Insurance not involved Resolution Outcome:
Self-pay transaction only Source Confidence: High

​
Backdated Claim Submission

Actor: Client Trigger Condition: Client submits claims for past services (service date in the past) System Behavior: Thrizer allows submission of claims for any service date. Required User Action: Upload valid superbills or enter claim details. Support Action: Assist if submission or processing fails. Limitations:
  • Claim acceptance is determined by insurer timely filing limits
  • Thrizer does not enforce a submission time cutoff
  • Reimbursement is not guaranteed
Resolution Outcome:
  • Claim is processed if accepted by insurer
  • Claim is denied if outside insurer filing limits
Source Confidence: High

​
Diagnosis Code Missing

Actor: Clinician Trigger Condition:
No diagnosis available at time of session System Behavior:
Charge can be delayed Required User Action:
Wait until diagnosis is assigned Support Action:
None Limitations:
Claims require diagnosis Resolution Outcome:
Charge submitted after diagnosis added Source Confidence: High

​
Account Email Change Limitation

Actor: Client or Clinician Trigger Condition:
User attempts to change email System Behavior:
Email cannot be modified Required User Action:
  • create new account
  • or add new email as team member
Support Action:
May delete account upon request Limitations:
Accounts are email-bound Resolution Outcome:
New account required for new email Source Confidence: High

​
Account Deletion Request

Actor: Support Trigger Condition:
User requests account deletion System Behavior:
No self-service deletion Required User Action:
Email support Support Action:
Delete account Limitations:
Historical access may be lost Resolution Outcome:
Account removed Source Confidence: High

​
Reimbursement Withdrawal

Actor: Client Trigger Condition:
Client has balance in Thrizer System Behavior:
Funds held until bank linked Required User Action:
Add bank account Support Action:
Trigger transfer Limitations:
Transfer timing: Balance is paid every Tuesday and Thursday morning. Resolution Outcome:
Funds deposited Source Confidence: High

​
Claim Documentation Access

Actor: Client or Clinician Trigger Condition:
User requests transaction or claim history System Behavior:
Export available Required User Action:
Download CSV Support Action:
None Limitations:
Export reflects system data only Resolution Outcome:
User obtains report Source Confidence: High

​
Support Channel Limitation

Actor: Client or Clinician Trigger Condition:
User requests phone support System Behavior:
Phone support unavailable Required User Action:
Use email Support Action:
Respond via email Limitations:
No phone support Resolution Outcome:
Issue handled asynchronously Source Confidence: High

​
Support Response Time

Actor: Client / Clinician Trigger Condition:
User submits a human support request via email System Behavior:
Support responses are provided via email. Response Expectation:
  • Initial response is provided within 2 business days
Scope:
  • Applies to first response only
  • Resolution time may vary depending on issue complexity
Limitations:
  • Response times are not guaranteed
  • Timing may vary based on support volume and external dependencies
Resolution Outcome:
  • User receives an initial response within the expected timeframe
  • Follow-up may be required for full resolution
Source Confidence: High

​
Marketing and Logo Usage

  • Clinicians may share referral links and mention Thrizer
  • For use of logos or branded assets, users should contact support for guidance

​
Claim Resubmission After Insurance Change

Actor: Support Trigger Condition:
Client updates insurance after claim System Behavior:
No automatic resubmission Required User Action:
Provide updated information Support Action:
Manual handling of resubmission Limitations:
Dependent on claim state Resolution Outcome:
Claim may be reprocessed Source Confidence: Medium

​
Charge Success and Claim Submission Dependency

​
Charge Success Rule

  • A Charge succeeds only if the client’s payment method is successfully charged
  • If the client’s card cannot be charged:
    • The Charge fails

​
Claim Submission Dependency

  • Claim submission depends on a successful Charge
System behavior:
  • If Charge succeeds:
    • Client payment is captured
    • Claim is submitted automatically
  • If Charge fails:
    • No payment is captured
    • Claim is not submitted

​
Constraint

  • The system must not submit a claim if the Charge fails
  • Payment success is a prerequisite for claim submission

​
Charge Failure Handling

​
Immediate Failure Behavior

  • If the client’s payment method cannot be successfully charged:
    • The Charge fails immediately
    • No payment is captured
    • The claim is not submitted

​
System Behavior

  • The system does not queue or retry claim submission if the Charge fails
  • There is no partial workflow:
    • claim submission requires successful payment

​
Clinician Action Required

  • The clinician must:
    • resolve the payment issue with the client
    • update or retry the Charge
  • A new Charge attempt is required to:
    • successfully collect payment
    • trigger claim submission

​
Constraint

  • The system must not:
    • submit claims without successful payment
    • retry failed Charges automatically

​
FSA / HSA Documentation for Thrizer Payments

Actor: Client Trigger Condition:
Client requests a receipt, superbill, or documentation to submit for FSA or HSA reimbursement for sessions processed through Thrizer System Behavior:
  • Thrizer records all payment transactions in the Client Portal
  • Clients can export a complete record of payments
Required User Action:
  • Navigate to: Client Portal → Payments → Export
  • Download the payment record
Support Action:
  • Direct the client to the Payments export feature
  • Clarify that this export is the standard payment record available in Thrizer
Limitations:
  • Thrizer does not generate a separate document specifically for FSA/HSA submission
  • Superbills are used in manual claim workflows, where the client submits a claim independently rather than using Thrizer’s automatic claim submission
Resolution Outcome:
  • Client obtains a downloadable payment record for use in reimbursement submission (e.g., FSA/HSA)
Source Confidence: High

​
Support Channel Limitation

​
Communication Channels

  • Human-based Thrizer support is provided via aynchronous channels such as email.
  • Phone support is not offered.
Supported channels:
  • Email-based support
  • In-product support requests (Help → Request Help)
Constraint:
  • All support interactions must be routed through supported channels.
  • Do not direct users to unsupported communication methods.

​
Variable Practitioner CPT Validation Workflow

Actor: Support Trigger Condition:
A practitioner type falls under variable or conditional support categories (e.g., OT, PT, SLP, RD, medical specialists), and compatibility is unclear. System Behavior:
Thrizer does not automatically determine compatibility for variable practitioner types based on practitioner classification alone. Required User Action:
Provide:
  • CPT code(s) used
  • Service description (if needed)
Support Evaluation Process: Step 1 — Historical Validation
  • Check whether the provided CPT code(s) have been previously observed in Thrizer workflows.
  • If CPT code(s) are present in prior workflows:
    • Treat as supported for submission workflows
Step 2 — Internal Review (if not previously observed)
  • If CPT code(s) are not found:
    • Conduct internal review and compatibility assessment
    • Determine whether Thrizer can support claim submission for those services
Decision Outcomes:
  • If supported:
    • CPT code(s) may be used in Thrizer workflows
    • Thrizer is considered capable of submitting claims for these services
  • If not supported:
    • Thrizer workflows should not be used for those services
Reimbursement Expectation:
  • If a CPT code is:
    • previously observed, OR
    • approved through internal review
Then:
  • reimbursement may be considered likely in typical scenarios
Constraints:
  • Reimbursement is not guaranteed
  • Final claim outcomes are determined by the insurer
  • CPT validation confirms Thrizer workflow compatibility, not coverage or payment
Limitations:
  • Presence in historical workflows does not guarantee reimbursement
  • Absence from historical workflows does not imply unsupported status without review

​
Clinician Address Usage Guidance

Actor: Clinician Trigger Condition:
Clinician asks whether to use their own address or Thrizer’s address for documentation or tax purposes System Behavior:
Thrizer collects and stores the clinician’s business address for compliance and tax reporting purposes Guidance:
  • Clinicians should use their own business address for:
    • tax documentation
    • superbills
    • insurance-related documentation
  • If a clinician explicitly requests Thrizer’s address for a specific use case, the following address may be provided: 548 MARKET ST, PMB 82051, SAN FRANCISCO, CA, 94104
Limitations:
  • This address is not the default or recommended address for clinician documentation
  • Use of this address may not be accepted by insurers or other entities
Resolution Outcome:
  • Clinician uses their own address in standard cases
  • Thrizer address is used only when explicitly requested
Source Confidence: High

​
FILE: thrizer_pay_rules.md

​
Thrizer Pay Rules

Last Updated: 2026-03-23 Status: Canonical
Purpose: Defines the complete operational rules governing Thrizer Pay, including eligibility conditions, payment flow, fee behavior, reimbursement routing, and risk allocation. Use this file when determining:
  • whether Thrizer Pay is available for a client or session
  • how payments are split between client, Thrizer, and therapist
  • how fees are calculated, retained, or refunded
  • how and where insurance reimbursements are routed
  • what happens when claims are approved, denied, or applied to deductible
  • how coverage calibration and claim history impact eligibility
  • how financial adjustments are handled post-reimbursement
  • what guarantees and protections apply to therapist payments
Do not use this file for:
  • estimating reimbursement amounts or benefit details
  • insurer-specific policies or claim approval (adjudication) logic
  • general insurance definitions or terminology
This file should be treated as the single source of truth for all Thrizer Pay behavior and overrides any conflicting payment or eligibility logic elsewhere.

​
Normalized Condition Inputs

​
Claim Status

  • Approved
  • Denied
  • Approved_Applied_To_Deductible

​
Coverage Calibration Status

  • Established
  • Not_Established

​
Coverage Calibration Definition

Coverage Calibration Status = Established when:
  • insurer allowed amount is known
  • coinsurance behavior is known
  • Any allowed amount used before claim approval (adjudication) is an estimate generated by Thrizer
  • Final financial outcomes may vary based on insurer-determined allowed amount

​
Deductible Status

  • Met
  • Not_Met

​
Estimated Responsibility

Client’s expected out-of-pocket cost based on available benefit information at time of session.

​
Successful Claim Definition

Successful claim = Claim Status = Approved or Approved_Applied_To_Deductible

​
Payment Model

​
Rule 1 — Client Payment

Client pays Estimated Responsibility at time of session.

​
Rule 2 — Thrizer Pay Fee

Client pays 5% of therapist full session fee at time of session.

​
Rule 3 — Fee Base

Fee is calculated on therapist full session fee.

​
Rule 4 — Thrizer Advance

Thrizer pays remaining portion of therapist full session fee.

​
Rule 5 — Claim Submission

Thrizer submits claim to insurance carrier.

​
Rule 6 — Reimbursement Routing

Insurance reimbursement is paid to Thrizer.

​
Therapist Payment Rules

​
Rule 7 — Full Payment Guarantee

Therapist receives full session fee.

​
Rule 8 — No Clawback

Therapist payment is not reduced after payout.

​
Eligibility Rules

Thrizer Pay is allowed only if all conditions are met:

​
Rule 9 — Insurance Requirement

Primary insurance must be present.

​
Rule 10 — Deductible Requirement

Deductible Status = Met

​
Rule 11 — Claim History Requirement

At least one Successful Claim must exist. System behavior:
  • The coinsurance value from the approved claim is used for:
  • Thrizer Pay eligibility
  • client responsibility estimation

​
Fee Rules

​
Rule 14 — Fee Retention

If Claim Status = Approved or
→ Fee is retained.

​
Rule 15 — Fee Refund

If Claim Status = Denied
→ Fee is refunded.

​
Reimbursement Rules

​
Rule 16 — Standard Routing

All reimbursements are routed to Thrizer.

​
Rule 17 — Client Does Not Receive Initial Reimbursement

Client does not receive reimbursement directly from insurer.

​
Adjustment Rules

​
Rule 18 — Pre-Calibration Adjustment

If Coverage Calibration Status = Not_Established
→ Thrizer Pay is not available to the client

​
Rule 19 — Post-Calibration Adjustment

If Coverage Calibration Status = Established
→ Adjustment may result in:
  • additional client charge
  • client refund

​
Rule 20 — Therapist Protection

Therapist payment is unaffected by reimbursement differences.

​
Reimbursement Variance Rules

​
Rule 21 — Excess Reimbursement

If reimbursement > estimated amount
→ excess amount is returned to client.

​
Risk Boundary

​
Rule 22 — Risk Allocation

Thrizer assumes reimbursement risk relative to therapist.

​
Rule 23 — Estimate Limitation

Estimated Responsibility is not a guarantee of final reimbursement.

​
Rule 24 — Insurer Authority

Insurance carrier determines final claim outcome and reimbursement amount.

​
Availability Limits

​
Rule 25 — Disable Condition

Thrizer Pay may be disabled if reimbursement behavior is unreliable.

​
Rule 26 — Examples of Unreliable Behavior

  • repeated claim denials
  • inconsistent reimbursement patterns

​
Rule 27

— Fallback Behavior If Thrizer Pay is disabled
→ standard claim submission flows remain available.