An ABA practice payer and product register is the controlled inventory of each payer, plan, product, line of business, network, contract, enrollment, roster, effective date, authorization path, claim route, and current source. It keeps benefit, authorization, clinical, claim, adjudication, and payment states separate. A payer logo, directory listing, NPI, accepted claim, or verbal confirmation does not establish every configuration.

Define the payer and product register

Uma creates one row per provider, location, service, payer, product, network, and effective period when any of those fields can change the operational route. She stores evidence and uncertainty instead of a single accepted-payer checkbox. Every row has a stable identifier, owner, custodian, source, effective period, state, evidence, exception, change trigger, next review, and relationship to the decisions it supports.

Choose fields that support the decision

Record payer and legal entity, plan and product, line of business, network, contract and amendment, provider and location, enrollment, credentialing, roster, participation state, effective and termination dates, service and code scope, authorization and referral route, portal, companion or claims guide, submitter and clearinghouse, remittance and EFT setup, contact and reference, source date, owner, supported state, exception, test transaction, stop rule, and next review.

Separate source facts from practice decisions

For every payer-product combination, record the contract, enrollment evidence, payer publication, system response, policy, or qualified interpretation that establishes its current terms. The practice's supported, held, conditional, retired, or exception state appears in a separate field with an owner and date. A portal result, marketing statement, verbal comment, identifier, or old approval never silently becomes controlling evidence.

Set entry, review, and retirement rules

Define when a payer-product row is created, when staff may rely on it, who reviews it, which enrollment or contract changes reopen review, and when it is retired. Source expiry, staff changes, new sites, payer updates, system releases, incidents, audit findings, contract changes, and capacity shifts can trigger review. Historical versions remain available for older transactions and explanations.

Connect fields to real workflow gates

Trace which intake, authorization, scheduling, clinical, billing, collections, and reporting workflows rely on each payer-product field. Software may surface a current state and block a defined release. Authorized roles decide exceptions and qualified clinicians retain clinical judgment. The operational record keeps each decision and author visible.

Make a bounded operating decision

The practice gives every configuration a small state machine: discovered, under verification, supported, conditional, held, terminating, or retired. The state changes only when named evidence arrives and a responsible owner approves the transition. Benefit verification and authorization stay in member-specific records, while the register stores reusable product rules and supported workflows. If a claim succeeds despite an unsupported configuration, the practice investigates the evidence without promoting the route automatically. If a source conflicts with a portal or representative, the row stays held or conditional until written clarification resolves the operational question.

Reconcile independent source populations

Reconcile the payer-product register against contracts, amendments, payer portals, enrollment notices, directories, remittances, denials, claims, and staff reports. Differences receive an owner, consequence, next action, due date, and validation instead of disappearing through manual overwrites.

A fictional example

Uma locks 28 payer-product configurations. Twenty have current contract or other payment-path evidence, enrollment and roster states, source dates, authorization routes, and claim routes. Two mix products, two use unverified directories, one has a pending location, one lacks a termination date, and two have no tested path. Six repair. Two remain unsupported. The scenario is synthetic. It tests scope, evidence, state, exception, and denominator logic without establishing legal compliance, clinical quality, coverage, payment, licensure, competence, security, financial accuracy, client satisfaction, or outcome.

Calculate compatible measures

Initial supported-configuration completeness is 20 of 28, or 71.4%. Twenty-six validate, or 92.9%. Payers, products, networks, providers, locations, services, authorizations, claims, and payments stay separate.

Control the main risk

A clean claim from one member cannot validate an entire payer. Uma binds evidence to the specific product, configuration, service, date, and workflow step it actually supports.

Test hard cases

Test new contract, nonparticipating route, Medicaid product, commercial product, roster lag, site addition, product termination, directory conflict, portal change, test claim, denial, and unsupported configuration. Each case shows the source, owner, current state, affected workflow, immediate safeguard, exception route, correction, validation, and retirement or next-review rule.

Close the review with open work visible

Before closing the review, confirm population completeness, source currency, decision authority, qualified ownership, evidence, cross-register links, exceptions, change triggers, workflow use, validation, unresolved work, and next review. The payer and product register remains draft until every named reviewer completes the required review.

Use CASP as organizational context

Use the CASP Organizational Guidelines public overview for high-level business, clinical-operations, and risk-management context. CASP sells the detailed guidance. The public page does not prescribe this payer and product register, prove a row is complete, or grant authority for whether a payer configuration is supported for intake, authorization, claims, and follow-up.

Apply voluntary compliance guidance carefully

When reviewing the payer and product register, treat the OIG General Compliance Program Guidance as voluntary and nonbinding. Its discussions of risk assessment, policies, training, reporting, audits, corrective action, incentives, and oversight help test register design. Current law, contract, payer, professional, workforce, privacy, finance, and operational sources control each real decision.

Keep business orientation separate from authority

For broad business context around the payer and product register, use the SBA Manage Your Business guide as orientation across finances, employees, compliance, marketing, emergencies, and closure. It gives no ABA clinical, payer, privacy, licensure, facility, credentialing, tax, or legal authority. The register cites current primary sources for every material state.

Preserve clinical decision rights

For professional duties reflected in the payer and product register, apply the current BACB Ethics Code only to covered people and professional activities. The Code addresses competence, responsibility, client involvement, documentation, supervision, risk, evaluation, billing, and reporting. BACB has no separate corporate jurisdiction. Organizational ownership and register custody never replace qualified case-specific clinical judgment.

Scope privacy and security fields

For electronic PHI represented in the payer and product register, use HHS risk-analysis guidance when a covered entity or business associate must assess risks and vulnerabilities to all electronic protected health information it creates, receives, maintains, or transmits. HHS minimum-necessary guidance informs role-based PHI access when that standard applies. Neither source mandates a particular database, register, score, spreadsheet, or vendor product.

Use cybersecurity and provider identifiers within limits

For cybersecurity and identifier dependencies in the payer and product register, the practice can adapt the NIST Cybersecurity Framework as voluntary risk-management guidance while current legal and contractual requirements remain controlling. The CMS NPI fact sheet distinguishes individual and organizational identifiers and states that an NPI does not establish licensure, credentialing, enrollment, or payment. Identifiers connect records; they do not validate the underlying configuration.

Separate a product label from operating proof

A familiar payer name or renamed product does not prove that network, enrollment, authorization, claim, or payment terms stayed the same. Create a dated product row, link the current contract and payer evidence, and show unresolved fields explicitly. Reconcile schedules, authorizations, provider configurations, billing rules, and family communication before relying on the change. Preserve the earlier product identity for historical claims and decisions.

Related resources

Sources