CT Agency Suite for multi-state operations

One platform across every state you operate in.

Per-state configuration of programs, service codes, billing rules, and survey requirements — with cross-state reporting, a unified data model, and one team supporting it. Stop running a separate vendor stack per state and reconciling between them.

Apply for early access How multi-state works

Per-state config: Programs, codes, rules
Cross-state reporting: Aggregate or per-state
One team: Single support relationship

What multi-state requires

Configuration that varies per state

Each state has its own programs, codes, rules, and survey expectations. The platform handles those differences without forcing per-state tools.

Per-state program and service code dictionaries
Per-state billing rules and clearinghouse routing
Per-state authorization workflows (e.g., NJ SCPA)
Per-state auditor expectations and reporting
Per-state staff licensing and credential rules

Per-state config

Programs, codes, rules

Cross-state reporting

Aggregate or per-state

Multi-state import

Historical data preserved

One vendor

Single platform relationship

Why this matters

Multi-state agencies typically run a separate vendor stack per state — and pay the reconciliation tax.

When an agency operates across multiple states, the typical setup is one set of tools per state. Different case management vendors per state's program nuances. Different billing systems per state's clearinghouse and code conventions. Different reporting tools per state's auditor expectations. The agency-wide view is assembled in spreadsheets that try to reconcile data from incompatible systems — with predictable accuracy issues.

CT Agency Suite handles multi-state operation as a configuration concern, not as a separate-platform-per-state requirement. Each state is configured with its specific programs, service codes, billing rules, authorization workflows, auditor expectations, and credential requirements. Consumers, plans, visits, and staff records live on one unified data model with state context attached. Cross-state reporting aggregates or breaks down per state as needed; per-state operations work as if the agency operated in only that state.

Multi-state import support means agencies migrating from per-state stacks can preserve historical data with state context intact. Records that originated in different prior systems land in the unified data model with their state-specific provenance preserved. The migration pain is bounded; the operational benefit is permanent.

What multi-state on one platform delivers

Per-state configuration — programs, codes, rules, surveys
Unified data model — consumers, plans, visits, staff in one place
Cross-state reporting — aggregate, per-state, or comparative
Multi-state import — historical data with state context preserved
One support relationship — one team, one contract, one roadmap

Multi-state capabilities

What the platform handles for multi-state agencies.

Per-state program and service code dictionaries

Each state's specific programs (NJ DDD, state-specific HCBS waivers, etc.), service codes, modifier rules, and program tags are configured per state. Records use state-appropriate codes; reporting respects state-specific definitions.

Per-state billing rules and clearinghouse routing

Claims route to the correct clearinghouse based on the consumer's program. Per-state billing rules (modifier requirements, authorization linkage, units conventions) apply automatically. Aggregated billing reporting shows per-state and agency-wide views.

Per-state authorization workflows

NJ-specific SCPA tracking (billing-side, driven by the DDD Participant Search import) runs as built. Other states' equivalent prior-authorization concepts are configured per state. SCPA in any state stays scoped to the biller.

Per-state auditor expectations

Survey-readiness dashboards and gap detection adapt to each state's specific auditor patterns. NJ DDD's expectations differ from another state's HCBS waiver audit; the platform's per-state configuration handles both.

Cross-state reporting

Reports aggregate across all states for agency-wide views, break down per state for operational reviews, or compare across states for strategic analysis. Senior leadership sees unified financials and operational metrics; per-state operations leads see what they need without cross-state noise.

Multi-state import support

Migrating from a per-state stack: historical consumer records, plans, visits, billing history, and staff records can be imported with their state-specific provenance preserved. Each record knows what state it came from and what state it operates in now.

What it looks like in practice

A few ways teams use this.

Three-state agency closing the books

Agency operates in NJ, PA, and NY. Month-end, controller pulls the multi-state revenue dashboard. NJ DDD claims and remittance reconcile with NJ-specific rules; PA HCBS waiver claims reconcile with PA-specific rules; NY claims reconcile with NY-specific rules. Aggregated revenue rolls up; per-state breakdowns show where attention is needed. The reconciliation that used to require three separate billing systems is one workflow.

Audit in one state

NJ DDD audit underway. NJ-specific dashboard surfaces NJ-specific gaps (NJ MT visit compliance, MH/SCS Checklist completion, plan currency). PA and NY operations continue normally; audit response is scoped to NJ. The other states' operations aren't disrupted by NJ's audit cycle.

New-state expansion

Agency expands into a fourth state. New state's programs, codes, rules, and auditor expectations are configured. Consumer onboarding in the new state uses the same workflows the team already knows; the per-state configuration adapts to new-state specifics. Expansion that used to require standing up a new vendor stack is a configuration project.

Frequently asked

Common multi-state questions.

Which states does the platform support?

The platform's data model is general enough to support any state's HCBS or human services program. NJ DDD has the deepest pre-built configuration. Other states are supported through configuration during onboarding — the platform doesn't have a 'supported states' list because the architecture supports any state with the right configuration. Specific states with deep pre-built support include NJ; expansion to other states with pre-built configuration is on the roadmap as customer demand drives it.

Can different states have different module configurations?

Yes. Each state's configuration is independent. NJ might use the SCPA workflow heavily; another state might not have an equivalent. Each state's modules are configured to match what that state actually requires, without forcing one-size-fits-all across the agency.

How does cross-state reporting work for agencies that don't want state-by-state breakdowns?

Reports default to aggregated views for senior leadership use cases. Per-state breakdowns are available where they're useful (operational reviews, state-specific compliance reporting). Custom report templates can hide state distinctions for views that don't need them.

What about staff who work across states?

Staff records support multi-state work. Credentials are tracked per state (since licensing requirements vary), with the platform surfacing which credentials are current for which states. Scheduling and assignment respect per-state credentialing automatically.

How does multi-state import handle conflicting historical data?

Imports preserve state-specific provenance. If a consumer's record exists in two prior state systems with conflicting information, the import preserves both with their state context intact — the platform doesn't auto-resolve conflicts but surfaces them for review during onboarding. Manual reconciliation happens once during migration; the unified data model carries forward.

Are there per-state pricing implications?

Pricing scales with usage and modules adopted, not with state count. Multi-state operation is part of the platform's design, not an upcharge. Specific pricing for early-access partners depends on usage profile; multi-state operation typically lands meaningfully below the sum of per-state vendor contracts being retired.