FILE: Capability_Surface_Map_Client.md

Client Capability & Surface Map

Last Updated: 2026-03-23 Status: Canonical

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.

Retrieval Rules

Each ## CAP- section is a deterministic retrieval chunk.
Chunk IDs are stable and immutable.
Display labels are surface-only unless defined in another canonical file.
Status, result, payment type, and benefit values are not defined here.
This file does not define workflow rules outside direct UI surface behavior.

Field Schema

Type
Portal
Roles
Objects
Intents
Title
Where
Fields
List fields
Detail fields
Filters
Options shown
Actions
Supports
Outcome
Constraint
Display values
Entry sections and fields
Sections shown

Client Portal

CAP-CLIENT-CLINICIANS-ADD-001

Type: capability Portal: client Roles: client Objects: clinician Intents: can_i, how, where Title: Add clinician Where:

Client Portal â†’ Clinicians â†’ Add Clinician

Fields:

First name
Last name
Clinician email

Outcome:

Sends invite for clinician to join Thrizer.

CAP-CLIENT-CLINICIANS-SEARCH-001

Type: capability Portal: client Roles: client Objects: clinician Intents: how, where Title: Search clinicians Where:

Client Portal â†’ Clinicians â†’ Search

CAP-CLIENT-CLINICIANS-VIEWLIST-001

Type: capability Portal: client Roles: client Objects: clinician Intents: how, where Title: View clinician list Where:

Client Portal â†’ Clinicians

List fields:

Clinician name
Payment type for clinician
Email address
Practice name
Status

Display values:

Payment type is shown as displayed in the product
Status may display invite pending if not set up

List fields:

Email address
Practice name
Status

CAP-CLIENT-CLINICIANS-REMOVE-001

Type: capability Portal: client Roles: client Objects: clinician Intents: can_i, how, where Title: Remove clinician Where:

Client Portal â†’ Clinicians â†’ Action â†’ Remove Clinician

CAP-CLIENT-PAYMENTS-FILTER-DATERANGE-001

Type: capability Portal: client Roles: client Objects: payment Intents: how, where Title: Filter payments by date range Where:

Client Portal â†’ Payments â†’ Date range filter

CAP-CLIENT-PAYMENTS-VIEWLIST-001

Type: capability Portal: client Roles: client Objects: payment Intents: how, where Title: View payments list Where:

Client Portal â†’ Payments

List behavior:

Sorted newest to oldest

List fields:

Date
Clinician
Appointment date
Charge type
Amount
Payment type

CAP-CLIENT-PAYMENTS-EXPORT-001

Type: capability Portal: client Roles: client Objects: payment Intents: how, where Title: Export payments Where:

Client Portal â†’ Payments â†’ Export

CAP-CLIENT-PAYMENTS-VIEWDETAILS-001

Type: capability Portal: client Roles: client Objects: payment Intents: how, where Title: View payment details Where:

Client Portal â†’ Payments â†’ More Details (select a transaction)

Detail fields:

Transaction date
Appointment date
Charge type
Clinician rate
Claim number

CAP-CLIENT-CLAIMS-ADD-UPLOAD-001

Type: capability Portal: client Roles: client Objects: claim, superbill Intents: can_i, how, where Title: Add claim by uploading superbill Where:

Client Portal â†’ Claims â†’ Add Claim

Supports:

PDF upload

Use cases:

Clinician is not on Thrizer
Visit occurred before using Thrizer

CAP-CLIENT-CLAIMS-ADD-MANUAL-001

Type: capability Portal: client Roles: client Objects: claim Intents: how, where Title: Add claim by manual entry Where:

Client Portal â†’ Claims â†’ Add Claim â†’ Manual Entry

Entry sections and fields:

Appointment information
Diagnosis code
Provider information:
- Provider name
- Practice name
- Provider NPI
- Group NPI
- Tax ID
- Address

CAP-CLIENT-CLAIMS-VIEWLIST-001

Type: capability Portal: client Roles: client Objects: claim Intents: how, where Title: View claims list Where:

Client Portal â†’ Claims

List behavior:

Sorted newest to oldest

List fields:

Date
Claim number
Clinician
Appointment date
Status
Result

CAP-CLIENT-CLAIMS-VIEWDETAILS-001

Type: capability Portal: client Roles: client Objects: claim Intents: how, where Title: View claim details Where:

Client Portal â†’ Claims â†’ Select claim

Sections shown:

General information:
- Claim number
- Date submitted
- Appointment date
- Billed amount
- CPT code
- Status
- Result
Client information:
- Client name
- Client DOB
- Insurance company
- Member ID
- Diagnosis code
- Primary insurance holder
Clinician information:
- Clinician name
- Individual NPI
- Group NPI
- Tax ID

CAP-CLIENT-HELP-REQUESTHELP-001

Type: capability Portal: client Roles: client Objects: support Intents: can_i, how, where Title: Request help Where:

Client Portal â†’ Help â†’ Request Help

CAP-CLIENT-HELP-REQUESTBENEFITCHECK-001

Type: capability Portal: client Roles: client Objects: benefit_check, support Intents: how, where Title: Request benefit check request Where:

Client Portal â†’ Help â†’ Request Benefit Check Request

CAP-CLIENT-ME-EDITGENERAL-001

Type: capability Portal: client Roles: client Objects: account Intents: how, where Title: Edit account settings (general) Where:

Client Portal â†’ Me â†’ Account Settings â†’ General

Fields:

First name
Last name
Email address
Phone number
Street address

Constraint:

Email address cannot be edited after account creation

CAP-CLIENT-ME-INSURANCE-ADDVERIFYEDIT-001

Type: capability Portal: client Roles: client Objects: insurance Intents: can_i, how, where Title: Add, verify, or edit insurance Where:

Client Portal â†’ Me â†’ Insurance

Detail fields:

Deductible
Amount remaining on deductible
Estimated reimbursement amount

Display values:

Estimated reimbursement amount is shown after deductible is met

CAP-CLIENT-ME-PAYMENTMETHODS-ADD-001

Type: capability Portal: client Roles: client Objects: payment_method Intents: how, where Title: Add payment method Where:

Client Portal â†’ Me â†’ Cards and Bank â†’ Payment Methods

Supports:

Multiple payment methods
Setting a default preferred method

CAP-CLIENT-ME-REIMBACCT-CONNECT-001

Type: capability Portal: client Roles: client Objects: bank_account Intents: how, where Title: Connect reimbursement account Where:

Client Portal â†’ Me â†’ Cards and Bank â†’ Reimbursement Account

Fields:

Account number
Routing number
Account type

CAP-CLIENT-ME-PAYMENTTYPE-SELECT-001

Type: capability Portal: client Roles: client Objects: payment Intents: how, where, can_i Title: Select payment type Where:

Client Portal â†’ Me â†’ Payment Type

Options shown:

Thrizer Pay
OON Pay
Self-Pay

Outcome:

Thrizer Pay is only available if:
- the eligibility is met according to Thrizer Pay Eligibility Rules

CAP-CLIENT-ME-LOGOUT-001

Type: capability Portal: client Roles: client Objects: account Intents: how, where Title: Log out Where:

Client Portal â†’ Me â†’ Logout

End of document.

FILE: Capability_Surface_Map_Clinician.md

Clinician Capability & Surface Map

Last Updated: 2026-04-07 Status: Canonical

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.â€

Retrieval Rules

Each ## CAP- section is a deterministic retrieval chunk.
Chunk IDs are stable and immutable.
Display labels are surface-only unless defined in another canonical file.
Status, result, payment type, benefit values, and referral metrics are not defined here.
Prerequisites appear only when required for surface access.
This file does not define workflow rules outside direct UI surface behavior.

Field Schema

Type
Portal
Roles
Objects
Intents
Title
Where
Fields
List fields
Detail fields
Filters
Options shown
Actions
Supports
Outcome
Constraint
Prerequisite
Display values
Sections shown
Inputs shown
Capabilities
Enablement note

Clinician Portal

CAP-CLIN-CLIENTS-VIEWNOTIFICATIONS-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: practice Intents: how, where Title: View product update notifications Where:

Clinician Portal â†’ Clients (top of page)

CAP-CLIN-CLIENTS-FILTER-ACTIVEARCHIVED-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Filter clients (active vs archived) Where:

Clinician Portal â†’ Clients â†’ Active/Archived filter

CAP-CLIN-CLIENTS-SEARCH-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Search clients Where:

Clinician Portal â†’ Clients â†’ Search

CAP-CLIN-CLIENTS-ADD-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: can_i, how, where Title: Add client Where:

Clinician Portal â†’ Clients â†’ Add Client

Fields:

First name
Last name
Email address

Outcome:

Email invitation is sent to client
Client must accept

CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client, payment Intents: how, where, can_i Title: Select payment type for a client Where:

Clinician Portal â†’ Clients â†’ Client list â†’ Select Payment

Options shown:

OON Pay
Thrizer Pay
Self-Pay

CAP-CLIN-CLIENTS-ADDCHARGE-FROMOVERVIEW-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: charge Intents: how, where, can_i Title: Add charge from Clients overview Where:

Clinician Portal â†’ Clients â†’ Add Charge

Inputs shown:

Select client
Select clinician (in group practice)
Client payment method
Amount
Date
Location
Service
Duration

System behavior:

Creating a Charge initiates the payment workflow for the selected payment type.
For OON Pay and Thrizer Pay, creating a Charge initiates claim submission (completed after successful payment).
The clinician does not separately submit the claim for these automatic claim flows.

Options shown:

Appointment
Client No-Show
Miscellaneous

Clarification:

The “Select clinician” field determines the provider of record for the Charge.
The logged-in user creating the Charge may differ from the selected clinician.

CAP-CLIN-CLIENTS-OPTIONS-MANAGE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Manage client from list Where:

Clinician Portal â†’ Clients â†’ Options (â€¦) â†’ Manage Client

CAP-CLIN-CLIENTS-OPTIONS-PIN-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Pin client Where:

Clinician Portal â†’ Clients â†’ Options (â€¦) â†’ Pin Client

CAP-CLIN-CLIENTS-OPTIONS-ARCHIVE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Archive client Where:

Clinician Portal â†’ Clients â†’ Options (â€¦) â†’ Archive Client

CAP-CLIN-CLIENTS-OPTIONS-REMOVE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client Intents: how, where Title: Remove client Where:

Clinician Portal â†’ Clients â†’ Options (â€¦) â†’ Remove Client

CAP-CLIN-CLIENTDETAIL-GENERAL-DIAGNOSIS-MANAGE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: diagnosis Intents: how, where, can_i Title: Manage client diagnosis codes Where:

Clinician Portal â†’ Client â†’ General â†’ Diagnosis

Actions:

Add diagnosis code (with name/description)
Delete diagnosis code

CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-ADD-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment_method Intents: how, where Title: Add client payment method Where:

Clinician Portal â†’ Client â†’ General â†’ Payment Methods

Supports:

HSA / FSA cards
Credit/debit cards (Visa, Mastercard, American Express, Discover)

Fields:

Card number
Expiration date
Security code (CVC)
Country
Zip code
Card holder name not required

CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-DELETE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment_method Intents: how, where Title: Delete client payment method Where:

Clinician Portal â†’ Client â†’ General â†’ Payment Methods â†’ Delete

CAP-CLIN-CLIENTDETAIL-INSURANCE-EDIT-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: insurance Intents: how, where Title: Add or edit client insurance plan Where:

Clinician Portal â†’ Client â†’ Insurance â†’ Add/Edit

CAP-CLIN-CLIENTDETAIL-INSURANCE-VIEWBENEFITS-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: insurance, benefit_check Intents: how, where Title: View client benefits (OON) Where:

Clinician Portal â†’ Client â†’ Insurance â†’ View benefits

Detail fields:

OON deductible and deductible remaining/progress
Coverage amount represents the amount insurance will pay per appointment based on plan details

CAP-CLIN-CLIENTDETAIL-PAYMENTS-VIEWLIST-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment Intents: how, where Title: View client transactions list Where:

Clinician Portal â†’ Client â†’ Payments

List behavior:

Newest to oldest

CAP-CLIN-CLIENTDETAIL-PAYMENTS-EXPORTCSV-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment Intents: how, where Title: Export client transactions (CSV) Where:

Clinician Portal â†’ Client â†’ Payments â†’ Export (CSV)

CAP-CLIN-PAYMENTS-VIEWDETAILS-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment Intents: how, where Title: View payment details Where:

Clinician Portal â†’ Client â†’ Payments â†’ Select transaction

Detail fields:

Transaction ID
Transaction date
Charge type
Payout date
Clinician
Client
Appointment date
Gross amount
Processing fee (as displayed in the product)
Net amount
Payment type
Client paid
Payment status: Displays whether payment was successful or failed
Refund status (if applicable)

Description: Clinicians can view detailed payment information for each transaction, including processing fees and payment statuses (successful, failed, etc.). Supports:

Displays the 3% clinician processing fee applied to payments for all session fees.
Payment status reflects whether the payment was successfully processed or failed.

Outcome:

Clinician receives comprehensive transaction details, including processing fees and payment status.

CAP-CLIN-CLIENTDETAIL-PAYMENTS-REFUND-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: refund, payment Intents: can_i, how, where Title: Refund a client charge Where:

Clinician Portal â†’ Client â†’ Payments â†’ Select transaction â†’ Refund

Outcome:

Creates a refund transaction record.

CAP-CLIN-CLIENTDETAIL-CLAIMS-VIEWLIST-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: claim Intents: how, where Title: View client claims list Where:

Clinician Portal â†’ Client â†’ Claims

List behavior:

Newest to oldest

List fields:

Claim number
Submission date
Appointment date
Status
Result

CAP-CLIN-CLIENTDETAIL-CLAIMS-FILTER-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: claim Intents: how, where Title: Filter client claims Where:

Clinician Portal â†’ Client â†’ Claims â†’ Filters

Filters:

Date range
Charge type
Payment type
Clinician (group practice)

CAP-CLIN-CLIENTDETAIL-CHARGINGPROFILE-EDIT-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: charge Intents: how, where Title: Edit charging profile Where:

Clinician Portal â†’ Client â†’ Edit Charging Profile

Fields:

Service
Amount
Appointment duration
Location

CAP-CLIN-PAYMENTS-PRACTICE-OVERVIEW-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment, payout Intents: how, where Title: View practice payments overview Where:

Clinician Portal â†’ Payments

Sections shown:

Payout dashboard
Confirmed Charges (See All, Export)
Pending Charges (See All, Export)
Payout History (See All, Export)

CAP-CLIN-PAYMENTS-PRACTICE-EXPORT-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: payment, payout Intents: how, where Title: Export practice payments Where:

Clinician Portal â†’ Payments â†’ Export
Also available per section (Confirmed Charges / Pending Charges / Payout History)

CAP-CLIN-BENEFITS-INSTANTCHECK-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: benefit_check Intents: how, where, can_i Title: Use Instant Benefit Checker Where:

Clinician Portal â†’ Benefits â†’ Instant Benefit Checker

Inputs shown:

Rate
Service
First name
Last name
Date of birth
Insurance company
Member ID

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: widget Intents: how, where Title: Configure Thrizer Widget Where:

Clinician Portal â†’ Benefits â†’ Thrizer Widget

Capabilities:

Customize Widget (branding, name, colors)
Website Embed
Shareable Link (Thrizer-hosted)
Analytics (traffic over time)

Enablement note:

At least one team member must be active with a service to enable widget.

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: team_member, widget Intents: how, where Title: Add team member for widget services and rates Outcome:

Team member services and rates determine what clients can select in the public benefits calculator Where:
Clinician Portal â†’ Benefits â†’ Thrizer Widget â†’ Add Team Member
Also accessible via Me â†’ My Team (management surface)

CAP-CLIN-HELP-REQUESTHELP-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: support Intents: how, where Title: Request help Where:

Clinician Portal â†’ Help â†’ Request Help

CAP-CLIN-HELP-REQUESTBENEFITCHECK-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: benefit_check, support Intents: how, where Title: Request benefit check request for a client Where:

Clinician Portal â†’ Help â†’ Request Benefit Check Request Use case:
Used when automated benefit check is unavailable or fails

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: referral Intents: how, where, can_i Title: Share referral invite Where:

Clinician Portal â†’ Referral

Actions:

Share signup code
Share link
Email invite to colleague

Detail fields:

Waived balance (remaining waived revenue amount)

CAP-CLIN-ME-MYTEAM-VIEW-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: team_member Intents: how, where Title: View team members Where:

Clinician Portal â†’ Me â†’ My Team

List fields:

Name
Email
Role
Status

Display values:

Status may display Invited or Accepted

CAP-CLIN-ME-MYTEAM-ADD-001

Type: capability Portal: clinician Roles: practice_admin Objects: team_member Intents: can_i, how, where Title: Add team member Where:

Clinician Portal â†’ Me â†’ My Team â†’ Add Team Member

Fields:

First name
Last name
Email address
Individual NPI
Role

Display values:

Role may display Practice Administrator or Clinician

CAP-CLIN-ME-MYTEAM-RESENDINVITE-001

Type: capability Portal: clinician Roles: practice_admin Objects: team_member Intents: how, where Title: Resend team member invite Where:

Clinician Portal â†’ Me â†’ My Team â†’ Actions â†’ Resend Invite

CAP-CLIN-ME-MYTEAM-REMOVE-001

Type: capability Portal: clinician Roles: practice_admin Objects: team_member Intents: how, where Title: Remove team member Where:

Clinician Portal â†’ Me â†’ My Team â†’ Actions â†’ Remove Member

CAP-CLIN-ME-CHECKBENEFITS-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: benefit_check Intents: how, where Title: Check client benefits (from My Account) Where:

Clinician Portal â†’ Me â†’ Check Client Benefits

CAP-CLIN-ME-SETTINGS-PERSONAL-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: account Intents: how, where Title: Edit personal information Where:

Clinician Portal â†’ Me â†’ Account Settings â†’ Personal Information

Fields:

Profile photo
Legal first name
Email address
Individual NPI
Reset password request

Constraint:

Email address cannot be changed
New email requires new Thrizer account

CAP-CLIN-ME-SETTINGS-BUSINESS-001

Type: capability Portal: clinician Roles: practice_admin Objects: business_settings Intents: how, where Title: Edit business information Where:

Clinician Portal â†’ Me â†’ Account Settings â†’ Business Information

Fields:

Business name
Practice name (DBA)
Business tax ID
Group NPI
Entity type
Business address

CAP-CLIN-ME-SETTINGS-BANK-001

Type: capability Portal: clinician Roles: practice_admin Objects: bank_account Intents: how, where Title: Add or edit payout bank account Where:

Clinician Portal â†’ Me â†’ Account Settings â†’ Bank Account

Fields:

Account number
Routing number
Account type

Display values:

Account type may display Business Checking, Business Savings, Personal

CAP-CLIN-ME-FEEDBACK-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: feedback Intents: how, where Title: Submit feedback Where:

Clinician Portal â†’ Me â†’ Feedback Center

Actions:

Rate and send notes

CAP-CLIN-ME-LOGOUT-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: account Intents: how, where Title: Log out Where:

Clinician Portal â†’ Me â†’ Logout

CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

Type: capability Portal: clinician Roles: clinician, practice_admin Objects: client, payment Intents: how, where, can_i Title: Select payment type for a client Where:

Clinician Portal â†’ Clients â†’ Client list â†’ Select Payment

Options shown:

Thrizer Pay (Only available if the eligibility is met according to Thrizer Pay Eligibility Rules)
OON Pay
Self-Pay

Outcome:

Clinician cannot select Thrizer Pay unless the eligibility is met according to Thrizer Pay Eligibility Rules.

CAP-CLIN-CLIENTDETAIL-CLAIMS-EXPORT-SUPERBILL-001

Type: capability Portal: clinician Roles: clinician Objects: claim Intents: how, where, can_i Title: Export superbill as PDF Where:

Clinician Portal â†’ Client â†’ Payments â†’ Export Superbill

Description: Clinicians can generate a PDF superbill directly from a clientâ€™s profile for self-pay clients who wish to submit claims to their insurance independently without using Thrizer for reimbursement. How it works:

Open the client’s profile.
Go to the Payments tab.
Select Export superbill to generate the PDF.

Supports:

PDF export for self-pay clients only.
Clients can submit the generated superbill to their insurance without Thrizer’s involvement.

Outcome:

Generates a downloadable PDF superbill for client submission.

End of document.

FILE: product_constraints_limitations.md

Thrizer Product Constraints & Limitations

Last Updated: 2026-04-02 Status: Canonical

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.

Payment Constraints

RULE: MULTIPLE-CARDS-PER-SESSION-NOT-SUPPORTED

Type: Deterministic Statement
A single session charge cannot be split across multiple payment methods, such as two credit cards. Implications

Clients must use one payment method to cover the full cost of the session
If a client wishes to use multiple payment methods, separate charges must be made for each card

Risks

The system cannot bundle charges from multiple cards into one claim submission

RULE: ONE-CHARGE-PER-CLAIM

Type: Deterministic Statement
Each charge corresponds to a single claim. Implications

Charges cannot be combined into a single claim
Splitting a session into multiple charges results in multiple claims

Billing & Coding Constraints

RULE: SINGLE-CPT-PER-CHARGE

Type: Deterministic Statement
Each charge supports only one CPT code. Implications

Multiple services must be billed as separate charges
Each CPT code generates its own claim

RULE: NO-AUTOMATIC-BUNDLING

Type: Deterministic Statement
Thrizer does not support bundling multiple charges into a single claim. Implications

Manual workarounds (e.g., superbill submission) may be required
Bundling requests are not supported at the system level

Payout & Financial Constraints

RULE: NO-CLINICIAN-PAYOUT-SPLITS

Type: Deterministic Statement
Thrizer does not support automated revenue splits between clinicians. Implications

All payouts go to a single linked bank account
Practices must manually distribute funds

RULE: SINGLE-BANK-ACCOUNT-PER-TEAM

Type: Deterministic Statement
Each team can only have one payout bank account. Implications

Individual clinicians within a team cannot receive direct payouts
Team-level financial routing is required

Account & Identity Constraints

RULE: EMAIL-NOT-EDITABLE

Type: Deterministic Statement
Account email addresses cannot be modified after account creation. System Behavior

The email address is a fixed identifier tied to the account.
Users must continue using the original email for authentication.

Workarounds

Create a new account with the desired email
Add a new email as a team member

Access Continuity

Account access persists as long as valid login credentials are used.
Email immutability does not prevent access to:
- historical data
- prior transactions
- claims and records

Implications

Email lifecycle outside Thrizer (e.g., deactivation by provider) does not modify the account.
Users are responsible for maintaining access to their login credentials.

Constraints

Email cannot be changed retroactively
Account identity is permanently bound to the original email

RULE: ONE-ACCOUNT-PER-EMAIL-PER-TEAM

Type: Deterministic Statement
An email address can only be associated with one Thrizer team at a time. Implications

Users operating across multiple teams must use separate accounts or roles

Payment Method Constraints

RULE: NO-MULTIPLE-CARDS-PER-CHARGE

Type: Deterministic Statement
A single charge cannot be processed using multiple cards. Implications

Full session cost must be charged to one payment method
Workarounds require separate charges or alternative workflows

RULE: NO-RETROACTIVE-PAYMENT-METHOD-CHANGES

Type: Deterministic Statement
Completed charges cannot be reassigned to a different payment method. Implications

New payment methods apply only to future charges

Product Behavior Constraints

RULE: THRIZER-PAY-NOT-RETROACTIVE

Type: Deterministic Statement
Thrizer Pay can only be applied to future sessions. Implications

Past sessions cannot be converted to Thrizer Pay
Payment type must be selected before charge submission

RULE: DIAGNOSIS-REQUIRED-FOR-CLAIMS

Type: Deterministic Statement
A diagnosis code is required before submitting a charge that generates a claim. Implications

Claims cannot be submitted without a diagnosis
Clinicians may delay charging until diagnosis is available

Infrastructure & System Behavior

RULE: THRIZER-AS-PAYMENT-INFRASTRUCTURE

Type: Deterministic Statement
Thrizer operates as a payment infrastructure layer similar to a payment processor. Implications

Clinicians are responsible for collecting valid payment methods
Failed payments require clinician follow-up
Thrizer does not act as a collections intermediary

Data & Account Management Constraints

RULE: CLIENT-ACCOUNT-INDEPENDENCE

Type: Deterministic Statement
Client accounts are structurally independent from clinician accounts Implications

Clients can be linked to multiple practices
Moving a client between practices does not require a new account

RULE: LIMITED-ACCOUNT-MUTABILITY

Type: Deterministic Statement
Certain account attributes (e.g., email) cannot be modified after creation. Implications

Structural changes require account recreation or duplication

RULE: NO-SHOW-CANCELLATION-FEES-NOT-SUBMITTED

Type: Deterministic Statement
No-show or cancellation fees cannot be submitted to insurance carriers through Thrizer. Implications

Clinicians may charge clients directly for missed or canceled sessions but cannot submit these charges for insurance reimbursement through Thrizer.
These fees should be billed separately as self-pay charges.

Risks

Insurance claims cannot be generated for no-show or cancellation fees, and therefore, clients cannot receive reimbursement through their insurer for these fees.

Notes on Usage

These constraints are system-level limitations, not insurance or policy decisions
Workarounds may exist but are not guaranteed to produce correct claim outcomes
When constraints interact with insurance behavior, outcomes become insurance-dependent

RULE: ACCOUNT-TYPE-IMMUTABILITY-AND-INDEPENDENCE

Type: Deterministic Statement
Client accounts and clinician accounts are structurally separate and cannot be converted, merged, or repurposed. System Behavior

A client account cannot become a clinician account
A clinician account cannot become a client account
Accounts cannot be merged or transferred between roles
Each account type is created and maintained independently within the system

Email Behavior

The same email address may be used to create both:
- a client account
- a clinician account
These accounts remain fully separate despite sharing the same email

Implications

Users must create a new account if they need a different role
Data, history, and relationships do not transfer between account types
Role changes require account duplication, not modification

Constraints

No cross-role conversion
No account merging
No shared state between client and clinician account objects

FILE: Product_System_Map.md

Product System Map

Last Updated: 2026-04-07 Status: Canonical

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.

Chunking conventions

Each chunk begins with a heading that starts with ”## SYS-”.
Each SYS section is a deterministic chunk boundary.
Chunk IDs are stable. Never reuse an ID for a different meaning.
Do not add timestamps inside chunks. Only update the document header.

SYS-TAXONOMY-PAYMENTTYPES-001

Type: system_rule Domain: taxonomy Audience: client, clinician Intents: policy Objects: payment Title: Payment type canonical labels Rule:

Canonical payment types are:
- Thrizer Pay
- OON Pay
- Self-Pay

SYS-TAXONOMY-CLAIMSTATUS-001

Type: system_rule Domain: taxonomy Audience: client, clinician Intents: policy Objects: claim Title: Claim Status canonical labels Rule:

Claim Status is the primary categorical field.
Canonical Claim Status values are:
- Processing
- Investigating
- Denied
- Approved

SYS-TAXONOMY-CLAIMRESULT-001

Type: system_rule Domain: taxonomy Audience: client, clinician Intents: policy Objects: claim Title: Claim Result field model Rule:

Claim Result is a descriptive field.
Claim Result is not the primary claim state.
Claim Result may describe:
- processing state
- deductible application
- reimbursement amount
- reimbursement method
- reimbursement date

Constraints:

Claim Result does not determine reimbursement destination.
Claim Result does not replace Claim Status.

SYS-PORTALS-001

Type: system_rule Domain: surfaces Audience: internal Intents: policy Objects: portal Title: Portals and top-level surfaces Rule:

Thrizer has two primary portals:
- Client Portal
- Clinician Portal

Client Portal top-level surfaces:

Clinicians
Payments
Claims
Help
Me

Clinician Portal top-level surfaces:

Clients
Payments
Benefits
Help
Referral
Me

SYS-NORMALIZED-INPUTS-001

Type: system_rule Domain: normalization Audience: internal Intents: policy Objects: insurance, payment, eligibility Title: Normalized condition inputs Rule:

The following condition inputs are canonical for eligibility and reimbursement rules:
- PRIMARY_INSURANCE_ON_FILE = true | false
Defined as â€œPrimary Insurance On Fileâ€ in Canonical Terms
- DEDUCTIBLE_MET = true | false
- ALLOWED_AMOUNT_VERIFIED = true | false
- COVERAGE_VERIFIED = true | false

Constraint:

Do not substitute narrative phrases for these conditions in policy retrieval.

SYS-ROLES-CLIENT-001

Type: system_rule Domain: roles Audience: client Intents: can_i, policy Objects: account, insurance, payment_method, bank_account, payment, claim, support Title: Role: Client Client can:

Manage account settings:
- first name
- last name
- phone number
- street address
View email address
Manage primary insurance
Manage payment methods
Manage reimbursement bank account where applicable
Select payment type subject to eligibility rules
View payments and payment details
Export payments
Add claims by superbill upload or manual entry
View claims and claim details
Request help
Request benefit check

Client cannot:

Edit email address after account creation
Use secondary insurance or coordination of benefits
Access clinician payout dashboard
Access practice-wide transactions
Access team management
Access widget configuration

SYS-ROLES-CLINICIAN-001

Type: system_rule Domain: roles Audience: clinician Intents: can_i, policy Objects: client, charge, payment, claim, payout, benefit_check, widget, support Title: Role: Clinician Clinician can:

Add client by email invite
Search clients
Filter active and archived clients
Pin client
Archive client
Remove client
Select payment type per client subject to eligibility rules
Configure client charging profile
Manage client diagnosis codes
Manage client payment methods
Add or edit client primary insurance
View client benefits
Add charges
View payment transactions
Export payment transactions
View transaction details
Issue refunds
View client claims and claim details
Use Instant Benefit Checker
Configure Thrizer Widget if enabled
Request help
Request fallback benefit check request for client

Cost rule:

Clinician payment transactions charged through Thrizer carry a 3% card processing fee.

SYS-ROLES-PRACTICEADMIN-001

Type: system_rule Domain: roles Audience: clinician Intents: can_i, policy Objects: practice, team_member, business_settings, bank_account, payment, payout Title: Role: Practice Administrator Practice Administrator can:

Perform all clinician capabilities
Add and manage team members
Assign roles
Resend invites
Remove members
Manage business compliance settings
Manage payout bank account
View practice-wide payments
View payout dashboard

SYS-OBJ-CLIENT-001

Type: system_rule Domain: objects Audience: client, clinician Intents: policy Objects: client, insurance, payment_method, bank_account Title: Object: Client Definition:

A Client is the end user receiving services and paying for services.

Core fields:

Identity:
- first name
- last name
- email
- DOB
Primary insurance:
- insurance company
- member ID
- primary insurance holder
- OON deductible
- deductible remaining
Diagnosis:
- diagnosis codes
Payment methods:
- cards on file
Reimbursement account:
- bank account
Payment type selection:
- Thrizer Pay
- OON Pay
- Self-Pay

States:

Active
Archived
Removed

Relationships:

Client has many Charges.
Client has many Payment Transactions.
Client has many Claims.

Constraints:

Secondary insurance is not supported on this object.

SYS-OBJ-CLINICIAN-001

Type: system_rule Domain: objects Audience: client, clinician Intents: policy Objects: clinician, practice Title: Object: Clinician Core fields:

first name
last name
email address
practice name
status
payment type displayed in client portal for the clinician relationship
compliance identifiers:
- individual NPI
- group NPI
- tax ID
- business address

Relationships:

Clinician has many Clients.
Clinician creates Charges for Clients.
Clinician views Claims for Clients.
Clinician receives payouts for Charges.

SYS-OBJ-CHARGE-001

Type: system_rule Domain: objects Audience: clinician Intents: policy Objects: charge Title: Object: Charge Definition:

A Charge is a billed instance created by a clinician against a client.

Charge types:

Appointment
Client No-Show
Miscellaneous

Charge creation inputs:

client
clinician
client payment method
amount
date
location
service
duration

Actor vs Provider Distinction

The logged-in user (clinician or practice admin) is the actor who creates the Charge.
The selected clinician on the Charge is treated as the provider of record for:
- claim submission (provider NPI and claim data)
- payout attribution
The rendering clinician does not need to be the logged-in user.

Implications:

A practice administrator or team member may create Charges on behalf of a clinician
Claims and payouts are always tied to the selected clinician, not the acting user

Charging profile fields:

service
amount
appointment duration
location

Charge-triggered workflow:

When a clinician creates a Charge, the system automatically:
- charges the client’s selected payment method
- submits a claim, when the selected payment flow includes claim submission
- a claim is submitted only if the payment is successful
- constraint: If payment fails, the claim must not be submitted
This trigger applies to both:
- OON Pay
- Thrizer Pay

Constraint:

Charge creation is the canonical trigger event for both client card charging and automatic claim submission in supported payment flows.

Constraint:

Payment status is not modeled here as a separate canonical taxonomy.

SYS-OBJ-PAYMENTTXN-001

Type: system_rule Domain: objects Audience: client, clinician Intents: policy Objects: payment, transaction, refund, payout Title: Object: Payment Transaction Definition:

A Payment Transaction is a recorded financial transaction related to a charge.
A Refund Transaction is a Payment Transaction representing reversal or offset of a prior charge.

Client payment fields:

transaction date
appointment date
clinician
charge type
amount
payment type
claim number

Clinician payment fields:

transaction ID
transaction date
payout date
clinician
client
appointment date
charge type
gross amount
processing fee
net amount
payment type
client paid
refund indicator where applicable

Constraint:

Existence of a refund transaction does not define fee-refund policy.
Fee-refund policy must be defined only in pricing rules.

SYS-OBJ-CLAIM-001

Type: system_rule Domain: objects Audience: client, clinician Intents: policy Objects: claim, superbill Title: Object: Claim Definition:

A Claim is a submission to an insurance company for reimbursement or deductible credit.

Claim creation sources:

Automatic submission triggered when a clinician creates a Charge in a payment flow that supports automatic claim submission
Manual submission by client superbill upload or manual entry

Automatic claim trigger:

For OON Pay and Thrizer Pay, claim submission occurs automatically when the clinician creates a Charge.
At the same time, the client’s payment method is charged using the information attached to that Charge.
No separate manual claim-submission action is required for these automatic claim flows.

Client claim input fields:

appointment information
diagnosis code
provider name
practice name
provider NPI
group NPI
tax ID
address

Claim detail fields:

claim number
date submitted
appointment date
billed amount
CPT code
status
result
client name
client DOB
insurance company
member ID
diagnosis code
primary insurance holder
clinician name
individual NPI
group NPI
tax ID

Constraint:

This file defines claim object structure.
It does not define insurer adjudication logic.

SYS-CLAIM-OUTCOMES-001

Type: system_rule Domain: state_model Audience: client, clinician Intents: policy Objects: claim Title: Claim outcome interpretation Rule:

Claim Status = Approved may correspond to either:
- reimbursement
- deductible application with reimbursement amount = $0
Claim Status = Denied corresponds to:
- no reimbursement
- no deductible credit
Reimbursement and deductible application are both successful claim-processing outcomes.
Denied is an unsuccessful claim-processing outcome.

Constraint:

Approved does not by itself identify reimbursement destination.
Approved does not by itself guarantee cash reimbursement to the client.

SYS-ELIG-DEDGATING-001

Type: system_rule Domain: eligibility Audience: client Intents: policy Objects: deductible, payment Title: Deductible gating Rule:

Payment type availability is determined exclusively by the Thrizer Payment Eligibility Rules.

Constraint:

This file must not define or duplicate payment type eligibility logic.
All eligibility decisions must be routed to:
- Thrizer Payment Eligibility Rules

Clarification:

Deductible status impacts payment type availability only through the Payment Eligibility Rules.
This file may reference deductible status but must not independently determine payment type eligibility.

SYS-ELIG-THRIZERPAY-001

Type: system_rule Domain: eligibility Audience: client Intents: can_i, policy Objects: payment, insurance, claim Title: Thrizer Pay eligibility Rule: Thrizer Pay eligibility is determined by Thrizer Pay Rules

SYS-PRICE-CLIENT-PREDED-001

Type: system_rule Domain: pricing Audience: client Intents: policy Objects: payment, claim Title: Client pricing before deductible is met Rule:

Client platform fee = $0 when DEDUCTIBLE_MET = false.

Includes:

automatic claim submission where supported
claim status tracking
resubmissions
claim denial support

Constraint:

This rule defines client pricing only.
It does not remove clinician card-processing fees.

SYS-PRICE-CLIENT-OONPAY-001

Type: system_rule Domain: pricing Audience: client Intents: policy Objects: payment, claim, reimbursement Title: Client pricing: OON Pay Eligibility: If DEDUCTIBLE_REMAINING > 0 â†’ OON Pay allowed, no fee If DEDUCTIBLE_REMAINING = 0 â†’ OON Pay allowed, fee applies Fee rule:

Client fee = 1% of provider full session fee.

Fee trigger:

Fee is charged only when reimbursement is distributed to the client.
Fee is deducted from reimbursed funds.
If reimbursed funds amount = $0, the 1% fee is not charged.

Payment model:

Client pays provider full fee.
Client waits for reimbursement.

Includes:

automatic claim submission where supported
claim status tracking
resubmissions
denial support

SYS-PRICE-CLIENT-THRIZERPAY-001

Type: system_rule Domain: pricing Audience: client Intents: policy Objects: payment, claim, reimbursement Title: Client pricing: Thrizer Pay Eligibility: Thrizer Pay eligibility is defined in Thrizer Pay Rules. Fee rule:

Client fee = 5% of provider full session fee.

Fee trigger:

5% fee is charged upfront when the client pays their co-insurance amount.

Payment model:

Client pays co-insurance amount plus 5% fee.
Thrizer advances the remaining portion of provider full session fee.
Insurance reimbursement for the advanced portion is routed to Thrizer.

Fee refund rule:

If Claim Status = Denied, the 5% fee is refunded.
If Claim Status = Approved, the 5% fee is retained.

Risk boundary:

If reimbursement is lower than expected or not received, Thrizer absorbs the loss.
Therapist payout is not reduced by reimbursement shortfall.

Constraint:

This rule does not waive clinician card-processing fees unless another canonical pricing rule states otherwise.

SYS-PRICE-CLIENT-SUPERBILL-001

Type: system_rule Domain: pricing Audience: client Intents: policy Objects: claim, superbill, reimbursement Title: Client pricing: Superbill Upload Rule:

Client fee = $2 per session.

Pre-deductible rule:

If claim is not successfully applied toward the deductible, the $2 fee is refunded.
If Claim Status = Approved, including deductible application, the $2 fee is retained.

Post-deductible rule:

If Claim Status = Approved, the $2 fee is retained.
If Claim Status = Denied, the $2 fee is refunded.

Constraint:

No percentage fee applies to superbill upload claims.

SYS-PRICE-CLINICIAN-PLATFORM-001

Type: system_rule Domain: pricing Audience: clinician Intents: policy Objects: payment, claim, payout Title: Clinician pricing for payment transactions Rule:

Card processing fee = 3% on clinician payment transactions charged through Thrizer.

Includes:

automatic claim submission where supported
benefits tooling where available
claim management support

Constraint:

This rule defines clinician transaction fees.
It does not define referral incentives or promotional waivers.

SYS-PRICE-CLINICIAN-SUPERBILL-001

Type: system_rule Domain: pricing Audience: clinician Intents: policy Objects: superbill, claim Title: Clinician pricing: Superbill Upload Rule:

Clinician fee = $0 when clients submit their own superbills through Thrizer.

Clinician responsibility:

Provide a superbill.

SYS-CALIB-FIRSTCLAIM-001

Type: system_rule Domain: calibration Audience: client Intents: policy Objects: claim, reimbursement, payment Title: First-claim calibration Rule:

The first claim uses a best-guess allowed amount assumption.
The first processed claim is used to calibrate future expectations.

If insurance pays less than expected on the first claim:

Thrizer adjusts expected coverage to match actual coverage.
The client may owe an adjustment.

Approved claims update system understanding of:

allowed amount
deductible status

SYS-CALIB-AFTERFIRST-001

Type: system_rule Domain: calibration Audience: client Intents: policy Objects: claim, reimbursement, payment Title: Post-calibration rule Rule:

Once true coverage is known, no back charges to clinician occur because of later reimbursement shortfall.

If insurance pays less than expected after the first claim:

Client is responsible for the difference.
Thrizer updates the client profile to match actual coverage.

Constraint:

Percentage-based fees remain based on provider full charge.

SYS-REIMB-ROUTING-001

Type: system_rule Domain: reimbursement Audience: client, clinician Intents: policy Objects: reimbursement, payment Title: Reimbursement routing by payment type Rule:

OON Pay:
- reimbursement is sent to the client
Superbill Upload:
- reimbursement is sent to the client
Thrizer Pay:
- reimbursement is sent to Thrizer

Constraint:

Claim Result wording such as bank deposit or check does not by itself identify the final destination of funds.

SYS-REIMB-TIMING-001

Type: system_rule Domain: reimbursement Audience: client, clinician Intents: policy Objects: reimbursement Title: Reimbursement timing guidance Rule:

Typical reimbursement timing is 4 to 6 weeks.
Insurance carrier timing governs actual timing.

Constraint:

Do not promise reimbursement timing beyond this guidance.

SYS-SCOPE-PRIMARYONLY-001

Type: system_rule Domain: scope Audience: client, clinician Intents: policy Objects: insurance Title: Insurance scope Rule:

Primary insurance only is supported.
Secondary insurance is not supported.
Coordination of benefits is not supported.

SYS-DISCLAIMER-BENEFITS-001

Type: system_rule Domain: constraints Audience: client, clinician Intents: policy Objects: insurance, benefits Title: Benefits and coverage disclaimer Rule:

Information shown in benefits or coverage displays is not a guarantee of coverage.
The health plan determines coverage and claim outcomes according to plan terms and processes.
Do not promise reimbursement amount based on displayed benefits information.

SYS-SURFACE-CLIENT-CLINICIANS-001

Type: system_rule Domain: surfaces Audience: client Intents: policy Objects: clinician Title: Client Portal surface: Clinicians Authoritative exposure:

clinician name
payment type for clinician relationship
email address
practice name
status
remove clinician action

SYS-SURFACE-CLIENT-PAYMENTS-001

Type: system_rule Domain: surfaces Audience: client Intents: policy Objects: payment Title: Client Portal surface: Payments Authoritative exposure:

transaction date
clinician
appointment date
charge type
amount
payment type
claim number

The Thrizer Widget allows prospective clients to check out-of-network benefits using the clinicianâ€™s configured services and rates. Clinicians can share a link to their customized widget or embed it within their practice website.

System role:

The widget collects:
- service selection
- session rate
- client insurance details
These inputs are used to generate:
- estimated reimbursement
- estimated out-of-pocket cost

Dependencies:

At least one team member must have:
- an active service
- a defined rate

Constraint:

The widget provides estimates only and does not guarantee coverage or reimbursement.
Final outcomes are determined by the insurance carrier after claim adjudication.
Client information is not saved by Thrizer

SYS-SURFACE-CLIENT-CLAIMS-001

Type: system_rule Domain: surfaces Audience: client Intents: policy Objects: claim Title: Client Portal surface: Claims Authoritative exposure:

date
claim number
clinician
appointment date
status
result
claim details

Claim creation support:

superbill PDF upload
manual entry

SYS-SURFACE-CLIENT-ME-001

Type: system_rule Domain: surfaces Audience: client Intents: policy Objects: account, insurance, payment_method, bank_account, payment Title: Client Portal surface: Me Authoritative exposure:

account settings
primary insurance
payment methods
reimbursement bank account
payment type selection

Account constraints:

email address cannot be edited after account creation

SYS-SURFACE-CLIN-CLIENTS-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: client, charge Title: Clinician Portal surface: Clients Authoritative exposure:

client list
client status
payment type selection per client
add charge
manage client
pin client
archive client
remove client

Constraint:

Payment type selection remains subject to canonical eligibility rules.

SYS-SURFACE-CLIN-CLIENTDETAIL-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: client, insurance, payment_method, payment, claim, charge Title: Clinician Portal surface: Individual Client Authoritative exposure:

diagnosis codes
payment methods
primary insurance
benefits view
client payment transactions
client claims
charging profile

Constraint:

Benefits displayed on this surface are subject to the global benefits disclaimer.

SYS-SURFACE-CLIN-PAYMENTS-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: payment, payout Title: Clinician Portal surface: Payments Authoritative exposure:

payment transactions across clients in practice scope
payout dashboard:
- Confirmed Charges
- Pending Charges
- Payout History

SYS-SURFACE-CLIN-BENEFITS-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: benefit_check, widget Title: Clinician Portal surface: Benefits Authoritative exposure:

Instant Benefit Checker
Thrizer Widget

Widget constraint:

At least one team member must be active with a service to enable widget functionality.

SYS-SURFACE-CLIN-ME-MYTEAM-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: team_member Title: Clinician Portal surface: Me â†’ My Team Authoritative exposure:

team member name
email
role
status

Supported roles:

Practice Administrator
Clinician

SYS-SURFACE-CLIN-ME-SETTINGS-001

Type: system_rule Domain: surfaces Audience: clinician Intents: policy Objects: account, business_settings, bank_account Title: Clinician Portal surface: Me â†’ Account Settings Authoritative exposure:

personal profile
business compliance information
payout bank account

Account constraint:

email address cannot be changed on the existing account

SYS-CONSTRAINTS-001

Type: system_rule Domain: constraints Audience: client, clinician Intents: policy Objects: insurance, benefits, reimbursement Title: Global constraints Rule:

Secondary insurance is not supported.
Coordination of benefits is not supported.
Benefits shown are not a guarantee of coverage.
Do not promise reimbursement amount.
Do not promise reimbursement timing beyond canonical guidance.

SYS-CLAIM-001

Type: system_rule Domain: claims Audience: client, clinician, internal Intents: definition, eligibility, policy Objects: claim, coverage, eligibility, verification Title: Successful claim definition and verification collapse Rule:

A claim is considered successful when it has been processed and accepted by the insurer.
A successful claim is the canonical source of truth for coverage verification.
If at least one successful claim exists, the following are considered verified:
- Coverage is verified.
- Allowed amount is verified.
- Coinsurance is verified.
- coverage_verified = true
No additional verification fields are required once a successful claim exists.

SYS-SUPERBILL-WORKFLOW-001

Type: system_rule
Domain: claims
Audience: client, clinician
Intents: policy
Objects: superbill, claim, payment Title: Superbill workflows and constraints Rule: Thrizer supports two distinct superbill-related workflows:

1) Client Superbill Upload (Claim Submission)

Clients may upload a superbill to submit a claim manually.
In this workflow:
- Payment may occur inside or outside Thrizer
- The client submits a claim via:
  - superbill upload, or
  - manual claim entry
Thrizer uses the submitted superbill data to generate a claim.

Ownership constraint:

Superbill submission is client-driven.
A client must have their own Thrizer account to upload or manually enter a superbill claim.
Clinicians cannot upload or submit superbill claims on behalf of clients.

Constraint:

Claim accuracy depends entirely on the uploaded superbill
Thrizer does not validate or guarantee reimbursement

2) Clinician Superbill Generation (Self-Pay Only)

Superbill generation by clinicians is only supported when the client is set to Self-Pay.
In this workflow:
- The clinician charges the client using Self-Pay (or collects payment externally)
- The clinician generates a superbill from the session
- The client submits the claim independently to their insurance
Thrizer is not involved in claim submission or reimbursement processing in this flow.

Constraint:

Superbill export is not available for OON Pay or Thrizer Pay
Claim submission responsibility lies entirely with the client

System Distinction

Self-Pay:
- payment only
- optional superbill generation
- client submits claim
OON Pay / Thrizer Pay:
- payment + automatic claim submission
- no superbill generation

Data Requirements

All superbills must include:

provider name
NPI
TIN
service dates
billed amount
diagnosis codes (ICD-10)

Constraint:

Missing required fields may result in claim denial by the insurer

SYS-DATA-VISIBILITY-001

Type: system_rule Domain: constraints Audience: client, clinician Intents: policy Objects: clinician, business_settings, address Title: Business address visibility constraints Rule:

Business address is collected for:
- payment processor compliance
- tax reporting (e.g., 1099-K)
- business verification requirements
Business address is not displayed in client-facing portal surfaces.

Constraint:

Thrizer does not explicitly transmit business address data to insurers

SYS-CLAIM-ASSOCIATE-001

Type: system_rule Domain: claims Audience: clinician, internal Intents: policy Objects: claim, clinician Title: Associate clinician claim submission behavior Rule:

Thrizer standard claim submission uses the NPI of the clinician associated with the Thrizer account.
If an associate clinician creates the Thrizer account, the associate clinician’s own NPI is used on submitted claims.
Standard claim submission does not include a supervising provider NPI.
Standard claim submission does not include dual provider representation for rendering provider and supervising provider.

Fallback handling:

If an insurer denies a claim because supervising provider information is required, support may collect supervising provider information after the denial for manual follow-up or correction where possible.

Constraints:

Thrizer does not currently provide a standard UI flow to enter a supervising provider NPI for claim submission.
Thrizer does not guarantee insurer acceptance of claims submitted under an associate clinician’s own NPI.
Requirements for supervising provider information are determined externally by the insurer.

SYS-IDENTITY-TAXID-001

Type: system_rule
Domain: identity
Audience: client, clinician, admin
Intents: policy
Objects: claim, payout, tax_reporting Title: Thrizer Tax Identification Number (TIN) Rule:

Thrizerâ€™s Tax Identification Number (TIN) is: 863015188

Tax Reporting Usage (1099-K)

Thrizer issues 1099-K forms to clinicians for payments processed through the platform.
When completing tax filings using a 1099-K issued by Thrizer:
- The payer TIN to use is Thrizerâ€™s TIN (863015188)
This applies to:
- tax software entry
- manual tax filing
- any workflow referencing the 1099-K payer

Claim Submission Usage

Claims submitted through Thrizer may require a Tax ID field.
The Tax ID used on a claim depends on the billing configuration:
- If the clinician is the billing entity:
  - The clinicianâ€™s TIN should be used
- If Thrizer is acting as the billing entity in the claim submission workflow:
  - Thrizerâ€™s TIN may be used

Constraints

Thrizerâ€™s TIN must not be assumed as the default for all claims
Tax usage (1099-K) and claim usage are separate contexts and must not be conflated

External Determination

Insurers determine claim acceptance based on submitted billing information

DATA-VISIBILITY-CONSTRAINTS

Business address is collected for:
- payment processor compliance
- tax reporting (e.g., 1099-K)
- business verification requirements
Business address is not displayed in client-facing portal surfaces
Business address is not shared with clients through Thrizer
Business address is not explicitly transmitted to insurers by Thrizer systems
Exposure of business address to external systems (e.g., insurers) is:
- not defined by Thrizer system rules
- determined externally where applicable

Overview

Canonical

Client & Clinician Surfaces

Datasets

Routing

​FILE: Capability_Surface_Map_Client.md

​Client Capability & Surface Map

​Retrieval Rules

​Field Schema

​Client Portal

​CAP-CLIENT-CLINICIANS-ADD-001

​CAP-CLIENT-CLINICIANS-SEARCH-001

​CAP-CLIENT-CLINICIANS-VIEWLIST-001

​CAP-CLIENT-CLINICIANS-REMOVE-001

​CAP-CLIENT-PAYMENTS-FILTER-DATERANGE-001

​CAP-CLIENT-PAYMENTS-VIEWLIST-001

​CAP-CLIENT-PAYMENTS-EXPORT-001

​CAP-CLIENT-PAYMENTS-VIEWDETAILS-001

​CAP-CLIENT-CLAIMS-ADD-UPLOAD-001

​CAP-CLIENT-CLAIMS-ADD-MANUAL-001

​CAP-CLIENT-CLAIMS-VIEWLIST-001

​CAP-CLIENT-CLAIMS-VIEWDETAILS-001

​CAP-CLIENT-HELP-REQUESTHELP-001

​CAP-CLIENT-HELP-REQUESTBENEFITCHECK-001

​CAP-CLIENT-ME-EDITGENERAL-001

​CAP-CLIENT-ME-INSURANCE-ADDVERIFYEDIT-001

​CAP-CLIENT-ME-PAYMENTMETHODS-ADD-001

​CAP-CLIENT-ME-REIMBACCT-CONNECT-001

​CAP-CLIENT-ME-PAYMENTTYPE-SELECT-001

​CAP-CLIENT-ME-LOGOUT-001

​FILE: Capability_Surface_Map_Clinician.md

​Clinician Capability & Surface Map

​Retrieval Rules

​Field Schema

​Clinician Portal

​CAP-CLIN-CLIENTS-VIEWNOTIFICATIONS-001

​CAP-CLIN-CLIENTS-FILTER-ACTIVEARCHIVED-001

​CAP-CLIN-CLIENTS-SEARCH-001

​CAP-CLIN-CLIENTS-ADD-001

​CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

​CAP-CLIN-CLIENTS-ADDCHARGE-FROMOVERVIEW-001

​CAP-CLIN-CLIENTS-OPTIONS-MANAGE-001

​CAP-CLIN-CLIENTS-OPTIONS-PIN-001

​CAP-CLIN-CLIENTS-OPTIONS-ARCHIVE-001

​CAP-CLIN-CLIENTS-OPTIONS-REMOVE-001

​CAP-CLIN-CLIENTDETAIL-GENERAL-DIAGNOSIS-MANAGE-001

​CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-ADD-001

​CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-DELETE-001

​CAP-CLIN-CLIENTDETAIL-INSURANCE-EDIT-001

​CAP-CLIN-CLIENTDETAIL-INSURANCE-VIEWBENEFITS-001

​CAP-CLIN-CLIENTDETAIL-PAYMENTS-VIEWLIST-001

​CAP-CLIN-CLIENTDETAIL-PAYMENTS-EXPORTCSV-001

​CAP-CLIN-PAYMENTS-VIEWDETAILS-001

​CAP-CLIN-CLIENTDETAIL-PAYMENTS-REFUND-001

​CAP-CLIN-CLIENTDETAIL-CLAIMS-VIEWLIST-001

​CAP-CLIN-CLIENTDETAIL-CLAIMS-FILTER-001

​CAP-CLIN-CLIENTDETAIL-CHARGINGPROFILE-EDIT-001

​CAP-CLIN-PAYMENTS-PRACTICE-OVERVIEW-001

​CAP-CLIN-PAYMENTS-PRACTICE-EXPORT-001

​CAP-CLIN-BENEFITS-INSTANTCHECK-001

​CAP-CLIN-WIDGET-CONFIGURE-001

​CAP-CLIN-WIDGET-TEAMMEMBER-ADD-001

​CAP-CLIN-HELP-REQUESTHELP-001

​CAP-CLIN-HELP-REQUESTBENEFITCHECK-001

​CAP-CLIN-REFERRAL-SHARE-001

​CAP-CLIN-ME-MYTEAM-VIEW-001

​CAP-CLIN-ME-MYTEAM-ADD-001

​CAP-CLIN-ME-MYTEAM-RESENDINVITE-001

​CAP-CLIN-ME-MYTEAM-REMOVE-001

​CAP-CLIN-ME-CHECKBENEFITS-001

​CAP-CLIN-ME-SETTINGS-PERSONAL-001

​CAP-CLIN-ME-SETTINGS-BUSINESS-001

​CAP-CLIN-ME-SETTINGS-BANK-001

​CAP-CLIN-ME-FEEDBACK-001

​CAP-CLIN-ME-LOGOUT-001

​CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

​CAP-CLIN-CLIENTDETAIL-CLAIMS-EXPORT-SUPERBILL-001

​FILE: product_constraints_limitations.md

​Thrizer Product Constraints & Limitations

​Payment Constraints

FILE: Capability_Surface_Map_Client.md

Client Capability & Surface Map

Retrieval Rules

Field Schema

Client Portal

CAP-CLIENT-CLINICIANS-ADD-001

CAP-CLIENT-CLINICIANS-SEARCH-001

CAP-CLIENT-CLINICIANS-VIEWLIST-001

CAP-CLIENT-CLINICIANS-REMOVE-001

CAP-CLIENT-PAYMENTS-FILTER-DATERANGE-001

CAP-CLIENT-PAYMENTS-VIEWLIST-001

CAP-CLIENT-PAYMENTS-EXPORT-001

CAP-CLIENT-PAYMENTS-VIEWDETAILS-001

CAP-CLIENT-CLAIMS-ADD-UPLOAD-001

CAP-CLIENT-CLAIMS-ADD-MANUAL-001

CAP-CLIENT-CLAIMS-VIEWLIST-001

CAP-CLIENT-CLAIMS-VIEWDETAILS-001

CAP-CLIENT-HELP-REQUESTHELP-001

CAP-CLIENT-HELP-REQUESTBENEFITCHECK-001

CAP-CLIENT-ME-EDITGENERAL-001

CAP-CLIENT-ME-INSURANCE-ADDVERIFYEDIT-001

CAP-CLIENT-ME-PAYMENTMETHODS-ADD-001

CAP-CLIENT-ME-REIMBACCT-CONNECT-001

CAP-CLIENT-ME-PAYMENTTYPE-SELECT-001

CAP-CLIENT-ME-LOGOUT-001

FILE: Capability_Surface_Map_Clinician.md

Clinician Capability & Surface Map

Retrieval Rules

Field Schema

Clinician Portal

CAP-CLIN-CLIENTS-VIEWNOTIFICATIONS-001

CAP-CLIN-CLIENTS-FILTER-ACTIVEARCHIVED-001

CAP-CLIN-CLIENTS-SEARCH-001

CAP-CLIN-CLIENTS-ADD-001

CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

CAP-CLIN-CLIENTS-ADDCHARGE-FROMOVERVIEW-001

CAP-CLIN-CLIENTS-OPTIONS-MANAGE-001

CAP-CLIN-CLIENTS-OPTIONS-PIN-001

CAP-CLIN-CLIENTS-OPTIONS-ARCHIVE-001

CAP-CLIN-CLIENTS-OPTIONS-REMOVE-001

CAP-CLIN-CLIENTDETAIL-GENERAL-DIAGNOSIS-MANAGE-001

CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-ADD-001

CAP-CLIN-CLIENTDETAIL-GENERAL-PAYMENTMETHODS-DELETE-001

CAP-CLIN-CLIENTDETAIL-INSURANCE-EDIT-001

CAP-CLIN-CLIENTDETAIL-INSURANCE-VIEWBENEFITS-001

CAP-CLIN-CLIENTDETAIL-PAYMENTS-VIEWLIST-001

CAP-CLIN-CLIENTDETAIL-PAYMENTS-EXPORTCSV-001

CAP-CLIN-PAYMENTS-VIEWDETAILS-001

CAP-CLIN-CLIENTDETAIL-PAYMENTS-REFUND-001

CAP-CLIN-CLIENTDETAIL-CLAIMS-VIEWLIST-001

CAP-CLIN-CLIENTDETAIL-CLAIMS-FILTER-001

CAP-CLIN-CLIENTDETAIL-CHARGINGPROFILE-EDIT-001

CAP-CLIN-PAYMENTS-PRACTICE-OVERVIEW-001

CAP-CLIN-PAYMENTS-PRACTICE-EXPORT-001

CAP-CLIN-BENEFITS-INSTANTCHECK-001

CAP-CLIN-WIDGET-CONFIGURE-001

CAP-CLIN-WIDGET-TEAMMEMBER-ADD-001

CAP-CLIN-HELP-REQUESTHELP-001

CAP-CLIN-HELP-REQUESTBENEFITCHECK-001

CAP-CLIN-REFERRAL-SHARE-001

CAP-CLIN-ME-MYTEAM-VIEW-001

CAP-CLIN-ME-MYTEAM-ADD-001

CAP-CLIN-ME-MYTEAM-RESENDINVITE-001

CAP-CLIN-ME-MYTEAM-REMOVE-001

CAP-CLIN-ME-CHECKBENEFITS-001

CAP-CLIN-ME-SETTINGS-PERSONAL-001

CAP-CLIN-ME-SETTINGS-BUSINESS-001

CAP-CLIN-ME-SETTINGS-BANK-001

CAP-CLIN-ME-FEEDBACK-001

CAP-CLIN-ME-LOGOUT-001

CAP-CLIN-CLIENTS-SELECTPAYMENTTYPE-001

CAP-CLIN-CLIENTDETAIL-CLAIMS-EXPORT-SUPERBILL-001

FILE: product_constraints_limitations.md

Thrizer Product Constraints & Limitations

Payment Constraints

RULE: MULTIPLE-CARDS-PER-SESSION-NOT-SUPPORTED

RULE: ONE-CHARGE-PER-CLAIM

Billing & Coding Constraints

RULE: SINGLE-CPT-PER-CHARGE

RULE: NO-AUTOMATIC-BUNDLING