An ABA practice post-implementation review examines a released change after enough use has matured. It compares approved scope with actual users, sites, workflow versions, adoption, training, controls, incidents, client and staff experience, payer effects, outcomes, costs, benefits, side effects, defects, and open work. The review decides whether to accept, revise, limit, expand, roll back, or retire the change.

Define the post-implementation review

Kenji schedules the review before launch and chooses a maturity window that fits the change. A one-week check may find access defects, while payer and financial outcomes may need several complete cycles. The record connects source evidence, decision authority, capacity, cash, client and workforce effects, dependencies, measures, uncertainty, actions, and proof needed for the next state.

Choose fields that support the decision

Record change and approval, intended scope, launch date and versions, sites, services and user groups, maturity rule, eligible cohort, training and readiness, adoption, actual workflow, support tickets, exceptions and workarounds, access and client experience, staff burden, clinical and payer effects, incidents, privacy and security findings, costs, expected benefits, measured results, missing data, unresolved defects, owner, corrective action, rollback state, decision, communication, archive, and next review.

Turn the plan into decision gates

Distinguish launch acceptance from operating acceptance. A deployment can be technically complete while training, access, reconciliation, or client communication remains open. Follow one routine transaction and one hard case end to end through each affected system and team. When the change differs by site or role, results stay segmented. A rollback retains records created under the released version and identifies every downstream correction. The final decision names which scope is accepted and which defects, owners, dates, and safeguards remain active.

Protect current services and required work

A post-implementation review begins with the staff, supervision, cash, systems, facilities, vendor support, and leadership time the change actually consumed. Planning begins with net available capacity. A proposed change cannot borrow hidden labor from documentation, supervision, incident response, client communication, payroll, payer deadlines, maintenance, or recovery.

Preserve qualified decisions and direct input

A post-implementation review sends clinical findings to qualified clinicians and legal, payer, workforce, privacy, security, finance, and facility findings to authorized owners. Clients, families, and affected staff receive accessible ways to identify priorities, burdens, access needs, side effects, and workable alternatives. Their input is evidence, not a ceremonial signoff.

Keep versions, assumptions, and open work visible

Preserve the implementation's approved scope, baseline, assumptions, decision, resource use, workflow version, change history, exceptions, defects, and unresolved effects. Forecast updates never rewrite the earlier forecast. A closed milestone can link to later validation without pretending that adoption, benefit, payer acceptance, clinical quality, or financial return has already occurred.

Build decision-grade evidence

Gather evidence from intended users, people affected by the workflow, source-system logs, service records, support queues, payer artifacts, financial records, access checks, incidents, and control tests. The implementer explains design decisions but does not own every conclusion. Reviewers inspect both the standard path and documented exceptions. They compare the new process with the approved baseline without erasing secular changes or concurrent work. Findings become immediate safeguards, owned defects, policy or training updates, benefit revisions, or scope decisions. The next review targets unresolved risk and maturity, not an arbitrary anniversary.

A fictional example

Kenji reviews 14 released changes. Nine have approved scope, mature cohort, adoption, controls, results, side effects, defects, and decision evidence. One lacks a maturity rule, one omits client experience, one hides workarounds, one has no cost result, and one closes with an unresolved access defect. Four repair. The access issue reopens the final change. The scenario is synthetic. It tests scope, capacity, evidence, state, and denominator logic without establishing clinical quality, legal compliance, payer approval, staffing, funding, safety, client satisfaction, financial return, or outcome.

Calculate compatible measures

Initial review integrity is 9 of 14, or 64.3%. Thirteen changes validate, or 92.9%. Changes, versions, users, transactions, defects, incidents, outcomes, actions, and decisions retain separate counts.

Control the main planning risk

Teams may ask the implementer to judge their own success. The practice records reviewer conflicts and obtains independent clinical, security, finance, payer, or user evidence when the consequence warrants it.

Test hard cases

Test single-site rollout, multi-site change, low adoption, hidden workaround, access defect, payer reject, client confusion, staff burden, security issue, rollback, partial acceptance, and follow-up review. Each case states the source, qualified owner, affected cohort, capacity and cash effect, client and workforce safeguard, dependency, decision, evidence, validation, and next review.

Close the review with unresolved work visible

Before closing the review, confirm source currency, authority, scope, capacity, resources, dependencies, assumptions, client and workforce effects, measures, exceptions, side effects, benefit evidence, corrective work, and open decisions. The post-implementation review remains draft until every named reviewer completes the required review.

Place the planning method within organizational scope

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 post-implementation review, set a planning horizon, or authorize whether a released change is operating as approved and what must happen next.

Use compliance guidance within its limits

Treat the OIG General Compliance Program Guidance as voluntary and nonbinding. Its discussions of leadership, risk assessment, training, reporting, audits, corrective action, incentives, and oversight inform planning checks. Current law, payer, professional, workforce, privacy, finance, facility, contract, and legal sources control actual obligations.

Use business-planning sources as orientation

Use the SBA Manage Your Business and Write Your Business Plan pages for broad business orientation. They give no ABA clinical, payer, facility, workforce, tax, privacy, safety, or legal authority. Page-specific sources, qualified owners, operating evidence, and current conditions support every material commitment.

Preserve clinical authority and client involvement

Apply the current BACB Ethics Code to covered people and professional activities. It addresses competence, responsibility, client involvement, documentation, supervision, risk, evaluation, billing, and reporting. BACB has no separate corporate jurisdiction. Plans allocate resources and request decisions without transferring qualified clinical judgment to owners or software.

Include leadership and workforce evidence

Use OSHA's management leadership and worker participation pages as general safety-program guidance about goals, resources, accountability, reporting, participation, and response. The pages do not create a universal ABA planning model. Workers need usable routes to surface workload, access, safety, and implementation problems without retaliation.

Keep technology-risk planning scoped

The practice may adapt the NIST Cybersecurity Framework as voluntary cybersecurity risk-management guidance for technology and information dependencies. It does not replace HIPAA, state law, payer contracts, clinical authority, or the broader operating plan. Cybersecurity assumptions, risks, controls, incidents, and recovery work remain visible within the portfolio rather than hidden in a separate technical backlog.

Review after evidence can mature

Hold an early stabilization check for safety, access, privacy, workflow, and service problems, then a later outcome review after the defined cohort has enough exposure. Do not close the implementation because the launch meeting ended. Compare intended design, actual use, exceptions, burden, benefits, harms, cost, and unresolved work. Route corrective decisions to their owners and schedule a retest rather than converting every observation into a broad success statement.

Related resources

Sources