Thrizer Benefit Check Failures and Manual Verification
Last Updated: 2026-03-23 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.Thrizer Canonical Terms
Purpose: Use this file to resolve the precise meaning of any Thrizer-specific term or insurance-related concept referenced in a query. Route here when: A question depends on the definition of a term (e.g., “What is Allowed Amount?”). Multiple terms could be confused or need disambiguation (e.g., Provider Fee vs Allowed Amount). A response requires consistent, canonical wording of a concept. A downstream answer depends on understanding a term before applying logic. Do not route here when: The query requires workflows, calculations, eligibility rules, or system behavior. The query asks “how,” “when,” or “why” something happens rather than “what it means.” This file is the single source of truth for terminology only.Thrizer Observed CPT Entries and Billing Patterns
Purpose: Use this file only for historical lookup of CPT entries, non-CPT service entries, appointment labels, durations, and billing patterns previously observed in Thrizer workflows. Route here when the task is to answer questions such as: Has this code appeared before? What appointment type was it associated with? What durations were previously seen? Has this code combination or add-on pattern been observed in usage? Do not route here for questions about whether a code is valid, covered, reimbursable, compliant, supported now, or allowed in a current workflow. This file is observational only, not normative.Thrizer Canonical Insurer Recognition and Routing
Purpose: Use this file when a question requires insurer-name recognition or insurer-level routing in Thrizer. This file is the source of truth for matching insurer inputs to canonical insurer records and aliases, assigning insurer_match_status (matched, no_match, or ambiguous_match), identifying whether the insurer has prior workflow presence in this dataset, and returning insurer-level routing fields such as thrizer_pay_available, eligibility_check_route, and program_type. Do not use this file for coverage determinations, eligibility outcomes, reimbursement outcomes, reimbursement estimates, or any plan-level decision.Thrizer Insurance Definitions
Purpose: Provides canonical definitions for insurance terms used across Thrizer. Use this file when a query requires precise meaning, interpretation, or disambiguation of insurance terminology (e.g., deductible, allowed amount, coinsurance, claim status, reimbursement). Route here for: Term definitions or clarification of insurance concepts Understanding relationships between financial inputs (provider fee, allowed amount, deductible, coinsurance) Interpreting claim statuses, outcomes, or result types Explaining how estimates (reimbursement, out-of-pocket) are constructed at a conceptual level Do not use this file for: Product behavior, workflows, or user actions Pricing rules, fee calculations, or payout timing Insurer-specific policies or plan details Determining actual claim outcomes or guarantees All interpretations derived from this file must respect global constraints: insurance carriers control claim decisions, reimbursement amounts, and deductible application; all estimates are non-guaranteed.Practitioner Eligibility Reference (Canonical)
Purpose: Use this file when determining whether a practitioner can be considered eligible or supported at a classification level, based on license validity, supervision status, legal permissibility, and general reimbursement possibility. This file should be referenced when: The question involves whether a specific practitioner type is supported or unsupported The question involves license types, supervision status, or practitioner categories The chatbot needs to apply eligibility constraints (license valid, legal, reimbursable) The chatbot must classify a provider as supported, conditionally supported, or unsupported The chatbot needs to handle uncertainty for supervised or variable-support practitioners This file should NOT be used when: Determining actual reimbursement amounts, claim outcomes, or insurer decisions Evaluating plan-specific coverage or benefits Explaining payment flows, claim submission, or timing Providing guarantees of reimbursement or eligibility This file provides structural eligibility logic and practitioner classification only, not outcome determination.Thrizer Supported Diagnosis Codes
Purpose: Routes queries that require verification of whether a diagnosis code is supported in Thrizer’s admin workflows. Use this file when: The user asks if a specific diagnosis code (e.g., F32.1) is supported The user asks if a specific diagnosis description is supported and can be mapped to a code The task involves validating inputs during clinician client setup The task requires confirming whether a diagnosis can be used within Thrizer workflows (not billed, not reimbursed) Do not use this file when: The question is about clinical meaning, ICD-10 definitions, or coding guidance The question is about insurance coverage, reimbursement, or claim approval The question is about documentation requirements or medical necessity If a diagnosis code is present in this file, treat it as supported for admin workflow usage only, not as validation of clinical correctness or insurer acceptance.Thrizer Payment Eligibility Rules
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.Payment Model (Canonical, RAG-Optimized)
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
- insurer-specific rules or coverage decisions
- claim approval, denial, or adjudication logic
- UI steps or operational workflows
Pricing Rules
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
- “What will be charged?”
- “When is it charged?”
- “Is the fee kept or refunded?”
- “Who receives the reimbursement?”
- “How much does the therapist receive?”
- defining insurance terms or concepts
- predicting or explaining reimbursement amounts
- determining claim outcomes or insurer behavior
- deciding eligibility for payment types
Thrizer Product Constraints & Limitations
Purpose: Defines the hard system constraints and unsupported behaviors of the Thrizer platform. Use this file when determining what is not possible, what must be structured in a specific way, or why a requested workflow cannot be completed as described. This file should be consulted when: A user asks if a workflow, billing setup, or payment configuration is supported A request involves combining, splitting, or modifying charges, claims, or payments There is ambiguity about system behavior vs. user/insurance behavior An error, limitation, or workaround needs to be explained Multiple actions are being attempted that may conflict with system rules This file provides deterministic system boundaries. It should override assumptions from other files when conflicts arise about what the system can or cannot do.Thrizer Reimbursement Reasoning Rules
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
- provider_fee
- allowed_amount
- deductible_remaining
- coinsurance_client_percent
- claim_status
- 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
Thrizer Support Explanation Patterns (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
Thrizer Support & Operational Rules
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
- deterministic system behavior (pricing, eligibility, reimbursement logic)
- definitions of insurance or product capabilities
- expected “happy path” workflows that the system handles automatically
Thrizer Pay Rules
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
- estimating reimbursement amounts or benefit details
- insurer-specific policies or claim adjudication logic
- general insurance definitions or terminology
Client Capability & Surface Map
Purpose: Defines the complete set of client-facing portal surfaces and capabilities within Thrizer, including where each surface is located, what actions a client can take, and which fields, filters, and options are visible. Use this file when the question is about what exists in the client portal or how a client interacts with it, including: Where to find a feature or page in the client portal Whether a client can perform a specific action What fields, filters, or options are shown in a given screen What information is displayed in lists, details, or forms What inputs are required when entering or editing data Do not use this file for: Payment behavior, fee calculations, or reimbursement outcomes Insurance logic, benefit calculations, or claim adjudication Definitions of statuses, results, or financial values beyond what is visibly displayed This file serves as the source of truth for client UI structure and capabilities, not for underlying system logic or business rules.Clinician Capability & Surface Map
Purpose: Defines the complete inventory of clinician-facing portal surfaces and their capabilities. Use this file to determine whether a feature exists, where it is located in the clinician portal, who can access it, and what UI elements (fields, filters, actions, options, and displayed values) are present. Routing Guidance for RAG Query this file when the user is asking about: Where to find something in the clinician portal How to perform an action in the UI (navigation, clicks, steps) Whether a clinician or admin can perform a specific action What inputs, fields, filters, or options appear in a screen What data is shown in a specific view (lists, detail pages, exports) What capabilities exist within a specific surface (Clients, Payments, Claims, Benefits, Widget, Team, Settings, etc.) Do not use this file when the question involves: Fees, pricing, or payout calculations Reimbursement amounts or insurance outcomes Benefit estimation logic or claim adjudication Policy interpretation or business meaning of values This file answers “what exists and how it appears in the UI”, not “how the system behaves financially or logically.”Product System Map
Purpose: Defines the canonical product-system rules for Thrizer. Use this file when the question is about what exists in the product, how product concepts are modeled, which fields and statuses are canonical, what each role can access or do, which portal surfaces expose which information, how core objects relate to each other, how payment-type eligibility works, how pricing and fees are determined, how reimbursement is routed, how first-claim calibration works, and which global system constraints apply. This file is the routing authority for structural and policy questions about the Thrizer product model. It should be consulted for questions about roles, objects, state models, payment types, claim fields and outcomes, eligibility conditions, reimbursement destination, fee triggers, and portal field exposure. Do not use this file for UI click paths, step-by-step user instructions, support macros, Help Center phrasing, insurer-specific adjudication rules, or assistant behavior.external_link_router.md
Purpose
Map user intents to external links.Do not interpret, summarize, or extract content from these links.
These links are non-canonical and must not be used to determine product behavior, pricing, eligibility, or reimbursement logic.
Admin Capability & Surface Map (Capability_Surface_Map_Admin.md)
Purpose: Defines the complete inventory of admin-facing portal surfaces and capabilities in Admin v2. Use this file to determine whether an admin feature exists, where it is located in the admin portal, and what UI elements are present, including fields, filters, actions, options, detail pages, and reachable management screens. Routing Guidance for RAGQuery this file when the user is asking about: Where to find something in the admin portal
How to perform an action in the admin UI (navigation, clicks, steps)
Whether an admin can perform a specific action
What inputs, fields, filters, controls, or options appear in a screen
What data is shown in a specific admin view (lists, detail pages, forms, tabs, drawers, exports)
What capabilities exist within a specific admin surface such as User Management, Claim Management, Transactions Manager, Referrals, or Notifications & Feedback Do not use this file when the question involves: Fees, pricing, or payout calculations beyond what is visibly shown in the admin UI
Reimbursement amounts, benefit reasoning, or insurance outcomes
Claim adjudication or insurance logic
Policy interpretation or business meaning of admin-visible values unless explicitly stated in the source map This file answers “what exists and how it appears in the admin UI,” not “how the system behaves financially or logically.”