An ABA practice service portfolio register is the versioned inventory of what the organization actually offers. Each row defines a service, population, setting, modality, geography, schedule, qualified clinical ownership, staffing model, payer or financial route, access supports, launch state, capacity, dependencies, evidence, and change owner. It prevents a website, contract, license, or old program description from becoming an unsupported promise of care.

Define the service portfolio register

Sana creates one row per materially different offer, such as center-based assessment for one age range under a named payer product. She does not collapse several sites, populations, modalities, or payment paths into a vague label such as full-service ABA. 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 program and version, client population and lawful published criteria, service and code family, setting and modality, site and service area, days and hours, clinical owner, qualified roles and supervision, capacity unit, access and communication supports, emergency and continuity route, payer or self-pay paths, authority and source dates, system and vendor dependencies, launch state, temporary limits, stop condition, evidence, review date, and change owner.

Separate source facts from practice decisions

For each program offer, record the authority, contract, payer term, license, policy, system evidence, or qualified judgment that establishes its scope. 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 program-offer row is created, when the offer may be used, who reviews it, what 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, scheduling, clinical, authorization, billing, reporting, and continuity workflows rely on each program-offer 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 publishes controlled offer states to the teams that need them. Marketing sees approved language and geographic limits. Intake sees eligibility and access routes. Clinical leaders see the population, service, and supervision model they approved. Scheduling sees actual hours, settings, and capacity. Payer operations sees supported product paths. A conditional or paused configuration carries the exact unmet gate and the person who can resolve it. The practice compares downstream tools with the register after every change so a retired offer does not remain on a website, referral form, directory, intake script, or schedule template.

Reconcile independent source populations

Reconcile the service portfolio against signed contracts, licenses, payer directories, schedules, claims, clinical records, marketing pages, and staff or client reports that can reveal an unsupported or stale offer. Differences receive an owner, consequence, next action, due date, and validation instead of disappearing through manual overwrites.

A fictional example

Sana locks 24 offered configurations. Eighteen have a current clinical owner, staff model, location, payer path, access plan, capacity rule, and release evidence. Two list unsupported hours, one uses an expired site approval, one lacks AAC support, one mixes two payer products, and one has no qualified clinical owner. Five repair. The final offer stays paused. 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 portfolio completeness is 18 of 24, or 75.0%. Twenty-three configurations validate, or 95.8%. Programs, configurations, sites, payer routes, staff roles, and available slots remain separate units.

Control the main risk

A broad service label can hide incompatible rules. Sana treats each distinct combination as its own configuration and preserves limits in marketing, intake, scheduling, and capacity tools.

Test hard cases

Test new assessment service, center program, home program, telehealth, temporary staffing cap, payer-only offer, private pay, access request, site closure, paused launch, and retired program. 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 service portfolio 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 service portfolio register, prove a row is complete, or grant authority for whether a program can be offered, marketed, staffed, and released.

Apply voluntary compliance guidance carefully

When reviewing the service portfolio 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 service portfolio 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 service portfolio 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 service portfolio 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 service portfolio 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.

Related resources

Sources