PNB — SCPA tracking

SCPA kept simple, on purpose.

Support Coordination Prior Authorization is a billing concern, and the workflow is simpler than most software pretends. PNB imports the DDD Participant Search; when a consumer's monthly Monitoring Tool has been successfully uploaded, the SCPA reflects as billable. The billing team works from there. That's it.

Schedule a demo How it actually works

Billing-only: Out of every other role's way
MT-driven: Monthly upload triggers billable
Honestly simple: No fake review workflow

How SCPA actually flows

Three steps, no review process

There's no shared queue, no review status flow, no reviewer, no notifications, no audit trail. Just data.

1. DDD Participant Search lists who has MT uploaded for the month
2. PNB imports that data
3. The SCPA reflects as billable for those consumers
Billing team works from PNB; nobody else thinks about SCPA

NJ DDD

Aligned with how the program actually works

MT-driven

Monthly Monitoring Tool gates billable

Billing-only scope

Out of the SC's way

Honestly simple

No invented complexity

Why this matters

SCPA software shouldn't invent complexity that isn't there.

A lot of prior authorization software pretends SCPA is an elaborate review workflow with queues, reviewer assignment, status transitions, returns-for-more-info, notifications, and audit trails. In NJ DDD, that's not how the program actually works. Whether a service is billable comes down to a much simpler question: did the consumer's monthly Monitoring Tool get successfully uploaded? If yes, the service is billable. If no, it isn't. The DDD Participant Search is the source of truth.

PNB matches that simplicity. Import the DDD Participant Search, and SCPAs reflect billable status based on the underlying MT data. The billing team has what they need to bill correctly. Nobody else in the agency has to think about SCPA — not the support coordinators, not QA, not supervisors. Less software noise; less work that doesn't need to exist.

There is no review workflow because the program doesn't have one. No SCPA gets 'returned' to anyone. No reviewer sees a queue. No SC is notified about anything SCPA-related. SCPA is data; the billing team works the data.

What PNB SCPA gives you

DDD Participant Search import — the source of truth for billable status
SCPA billable reflection — flagged based on MT upload status
Billing-team scope — nobody else has to think about SCPA
Honest simplicity — no review workflow because the program doesn't have one

What's actually here

PNB's SCPA features — no more, no less.

DDD Participant Search import

Import the DDD Participant Search data into PNB. The list of consumers with successfully uploaded MTs for the month is the input. No manual data entry; the source of truth from DDD becomes the source of truth in PNB.

SCPA reflects billable status

Once the import is in, the SCPA shows billable for the consumers whose monthly MT was successfully uploaded. Billing works from that. There is no human-driven review workflow because the program doesn't require one — it's a data flow, not a process.

Scoped to billing

Support coordinators don't see SCPA. QA doesn't see SCPA. Supervisors don't see SCPA. SCPA lives where it belongs: with the billing team. The platform doesn't surface it to roles that don't need it.

What's coming with CT Agency Suite

CT Agency Suite is the next-generation platform. The shape of SCPA itself stays simple — the program structure isn't changing, so the platform doesn't pretend to add complexity that isn't there. What gets better is the broader operations context (dashboards, AI assist, modern UI, integrated billing workflow) that surrounds it.

What it looks like in practice

A few ways teams use this.

Billing reconciliation at month-end

Billing person opens PNB at month-end. The DDD Participant Search has been imported, and the SCPAs reflect billable status for the consumers whose monthly MT was uploaded. They generate claims for those, and don't bill for the ones whose MT didn't make it. The reconciliation is fast because the data already says what's billable.

MT upload didn't make it for a consumer

A consumer's monthly MT didn't get uploaded in time. The DDD Participant Search reflects that, and PNB's SCPA for that consumer doesn't reflect billable. Billing doesn't bill for that service. The data is consistent end-to-end — no manual reconciliation between systems, no guessing.

Frequently asked

Common questions about SCPA in PNB.

What does SCPA stand for?

SCPA stands for Support Coordination Prior Authorization. In NJ DDD, it's the authorization record that determines whether a support coordination service is billable for a given consumer-month. SCPA billable status is driven by whether the consumer's monthly Monitoring Tool was successfully uploaded, per the DDD Participant Search.

Does PNB have a review workflow for SCPA?

No. There's no shared queue, no status flow with transitions, no reviewer assignment, no return-for-more-info step, and no notifications. SCPA in NJ DDD doesn't actually require any of that — it's a data flow, not a process. PNB imports the DDD Participant Search; the SCPA reflects billable based on the underlying MT upload data; the billing team works from that. Software that pretends SCPA needs review workflows is solving a problem that isn't there.

Who works SCPA in PNB?

The billing person. SCPA is scoped to the billing team. Support coordinators don't see it, QA doesn't see it, supervisors don't see it. This is intentional: SCPA noise outside the billing team creates work that doesn't need to exist.

How does the DDD Participant Search import work?

The DDD Participant Search produces a list of consumers and whether their monthly Monitoring Tool was successfully uploaded. PNB imports that data and the SCPAs reflect billable status accordingly. Billing then works from PNB to generate claims for billable services.

What if the monthly MT wasn't uploaded for a consumer?

Then the SCPA doesn't reflect as billable for that consumer-month. Billing doesn't bill for the service. The Monitoring Tool upload is what gates billable status — that's how the program is structured, and PNB reflects that structure.

Does PNB have an audit trail for SCPA actions?

No. PNB doesn't have a per-action audit trail for SCPA. There's not much to audit because there's no review workflow — the data flows from the DDD Participant Search import to billable reflection. Richer audit capabilities for the broader operations context arrive with CT Agency Suite.

What changes for SCPA in CT Agency Suite?

The shape of SCPA stays simple — the program structure isn't changing, so the platform doesn't pretend to add complexity that isn't there. CT Agency Suite improves the broader operations context (dashboards, AI assist, modern UI, integrated billing workflow) that surrounds SCPA. PNB customers' SCPA data carries forward through the migration.

SCPA, kept as simple as it actually is.

30-minute walkthrough of how SCPA works in PNB — the DDD Participant Search import, billable reflection, and how billing works from there.

Schedule a demo Back to PNB