An ABA practice runbook guides a defined operational exception, incident, or outage from observable trigger through activation, safety, continuity, access, containment, evidence preservation, communication, fallback, escalation, recovery acceptance, reconciliation, and after-action review. It names roles and contacts for the event. A runbook does not create emergency powers, clinical authority, payer permission, or legal privilege.

Define the events the runbook must handle

Felix writes runbooks for events that require coordinated decisions under time pressure, such as an EHR outage, site closure, payer portal failure, missing staff coverage, or corrupted file transfer. The exception and outage response runbook has a named owner, purpose, audience, scope, sources, qualified decision boundaries, version, effective date, evidence, feedback route, change trigger, and retirement state.

Record activation, continuity, and recovery fields

Felix records runbook ID and version, event and observable trigger, severity, activation and stop authority, incident lead, qualified clinical and domain roles, contacts and backups, immediate safety action, emergency boundary, affected services and clients, continuity and safe-stop gates, systems and data, access and communication support, containment, evidence preservation, privacy and security route, payer and workforce clocks, fallback, decision log, status update, recovery prerequisites, acceptance test, temporary-record reconciliation, return authority, after-action review, action, owner, and next exercise.

Keep emergency and decision authorities explicit

Felix orders the first decisions by consequence. Immediate danger uses emergency routes. Client services proceed only when setting, qualified staff, current client information, communication access, supervision, and required administrative gates are available. Technical recovery remains separate from clinical and operational acceptance. Staff record actual service and documentation times through the approved downtime path. The runbook says who can activate, pause, escalate, communicate, and declare each recovery layer complete, with alternates when the primary leader is unavailable.

Exercise the runbook under degraded conditions

Felix runs tabletop scenarios and safe technical tests without creating real danger or contacting external emergency systems unnecessarily. Exercises vary duration, site, shift, unavailable leader, failed fallback, inaccessible communication, and partial recovery. Observers record detection, activation, decisions, access, communication, deadlines, recovery checks, and reconciliation. Expected records stay in the denominator. Findings receive immediate safeguards, owners, due dates, and a new test. Staff never rehearse an unauthorized restrictive procedure or expose real client data for convenience.

Keep activation pages, role cards, and contacts current

Felix maintains a concise activation page and separate role cards for incident leads, site staff, clinicians, technology, privacy, billing, payroll, and communications. Contact information is secured, current, and available when the primary system is down. Each fallback states what work may continue, what must pause, and which evidence must later be reconciled. Recovery requires business acceptance checks, not system availability alone. After every exercise or real event, Felix records decisions, missed dependencies, client and worker effects, temporary records, open actions, and the date of the next focused retest.

Keep the artifact family connected

Felix links the process map, state specification, procedure, checklist, job aid, runbook, training, competency record, authorization, system access, and observed-work evidence that apply. One source or workflow change identifies every dependent artifact. Owners update only affected content, preserve earlier versions for historical work, communicate the change, and remove obsolete copies from every known distribution point.

Protect client access, staff voice, and qualified authority

Felix keeps AAC, interpreters, accessible formats, accommodations, privacy, safety, and an effective reporting route within the operating design. Clients and workers can identify barriers and harmful effects. Clinical, payer, employment, privacy, security, safety, and legal decisions stay attributable to qualified roles. A procedure or checklist never delays urgent action through the authorized emergency or reporting route.

Work through Felix's fictional example

Felix reviews 20 runbook exercise records. Fourteen show trigger, roles, safety, fallback, communication, recovery acceptance, reconciliation, and action evidence. Two lack backup leaders, one omits AAC access, one declares recovery at system uptime, and two have no reconciliation test. Four repair. Two remain safe-stop only. The scenario is synthetic. It tests source, role, version, use, evidence, and denominator logic without establishing clinical quality, legal compliance, payer approval, competence, safe performance, client satisfaction, or outcome.

Calculate the example measures

Initial runbook readiness is 14 of 20, or 70.0%. Eighteen validate, or 90.0%. Events, exercises, decisions, services, communications, records, and actions remain separate.

Distinguish a runbook from a contact list

A contact list can look like a runbook while leaving decisions undefined. Felix tests who decides, with what evidence, under degraded conditions.

Test outages, missing leaders, and partial recovery

Felix tests EHR outage, internet failure, facility closure, staff absence, payer portal outage, vendor failure, missing leader, inaccessible backup, partial recovery, client communication, record reconciliation, and after-action review. Each case states the source, qualified owner, user, access and safety conditions, expected evidence, exception, immediate safeguard, correction, validation, and next review.

Close review with unresolved work visible

Felix confirms source currency, qualified authority, scope, version, distribution, access, training, authorization, actual use, exceptions, feedback, validation, obsolete-copy removal, and open work. The runbook remains draft until every named reviewer completes the required review.

Place runbooks within organizational guidance

Felix uses 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 runbook, validate adoption, or grant decision authority.

Treat compliance guidance as a control framework

Felix treats the OIG General Compliance Program Guidance as voluntary and nonbinding. Its discussions of policies, training, reporting, audits, corrective action, incentives, and oversight help test process controls. Current law, payer, professional, workforce, privacy, safety, contract, and legal sources control actual requirements.

Keep general business guidance in scope

Felix uses the SBA Manage Your Business guide only as broad orientation across employees, finances, compliance, emergencies, and closure. It gives no ABA clinical, payer, privacy, safety, facility, tax, or legal authority. Each process artifact cites its actual current sources and qualified owners.

Preserve professional accountability

Felix applies 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. An artifact can route clinical judgment but cannot assign it to an unqualified role.

Include management leadership and worker participation

Felix uses OSHA's management leadership and worker participation pages as general safety-program guidance on resources, accountability, reporting, participation, response, and nonretaliation. Staff need accessible ways to report unsafe, unusable, or inaccurate procedures and tools. The pages do not create a universal ABA process-documentation method.

Limit PHI access and manage technology risk

Felix applies HHS minimum-necessary guidance to role-based PHI access when the standard covers the use, disclosure, or request. NIST Cybersecurity Framework concepts may support voluntary technology-risk management. Neither source mandates a particular process map, training tool, workflow platform, checklist, or authorization database.

Related resources

Sources