An ABA practice operational dependency map connects each critical service to the people, qualifications, systems, data, vendors, facilities, supplies, communications, payers, upstream inputs, downstream users, fallbacks, safe-stop conditions, and recovery evidence it needs. It exposes hidden single points of failure. The map supports continuity decisions, but technical availability alone does not establish clinical safety or authority to resume care.

Define the operational dependency map

Yara starts with a service outcome rather than a vendor list. For an assessment visit, she maps qualified staff, consent, client information, communication access, site, scheduling, records, payer state, safety resources, and downstream reporting. 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 critical service and owner, trigger and outcome, maximum tolerable interruption, minimum safe operating mode, qualified roles and backups, systems and data, interface and authentication dependencies, vendors and contracts, facilities and utilities, supplies and devices, communication routes, payer and authorization inputs, upstream and downstream processes, failure modes, detection, fallback, safe-stop rule, emergency route, recovery owner, acceptance checks, exercise date, finding, corrective action, and next test.

Separate source facts from practice decisions

For every operational dependency, record the contract, service commitment, system evidence, facility condition, policy, or owner confirmation that establishes its current availability. 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 dependency is mapped, when teams may rely on it, who reviews it, which outages or service changes reopen review, and when it is removed. 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 every intake, scheduling, clinical, billing, payroll, purchasing, access, safety, reporting, and recovery step that depends on the mapped resource. 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 ranks dependencies by the service harm created when they fail, then tests the highest-consequence chains. A tabletop can remove one leader, vendor, system, facility, or communication path without causing real disruption. The team identifies detection, activation, fallback, safe pause, client communication, documentation, payroll, payer deadlines, and return-to-normal decisions. Technical recovery is one milestone. Service recovery requires qualified people, current client information, accessible communication, safe settings, reconciled records, and responsible acceptance. Test findings become owned corrections with due dates and a new exercise condition.

Reconcile independent source populations

Reconcile the dependency map against contracts, vendor inventories, staffing plans, schedules, system and network logs, facility records, incidents, and workforce reports. Differences receive an owner, consequence, next action, due date, and validation instead of disappearing through manual overwrites.

A fictional example

Yara maps 20 critical services. Fourteen have complete people, system, data, facility, vendor, payer, fallback, safe-stop, and recovery evidence. Two lack qualified backups, one depends on an untested export, one has no accessible communication fallback, and two lack recovery acceptance checks. Four repair. Two remain limited to safe-stop mode. 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 dependency completeness is 14 of 20, or 70.0%. Eighteen services validate, or 90.0%. Services, dependencies, failure modes, tests, findings, and recovery actions remain separate.

Control the main risk

A backup system can restore while the service stays unsafe. Yara requires client information, qualified staff, communication access, clinical gates, payer conditions, and reconciled records before normal work resumes.

Test hard cases

Test staff absence, identity outage, EHR failure, internet loss, power outage, vendor failure, site closure, supply shortage, payer portal outage, inaccessible backup, partial recovery, and prolonged interruption. 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 operational dependency map 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 operational dependency map, prove a row is complete, or grant authority for how a critical service continues, pauses safely, or recovers after a dependency fails.

Apply voluntary compliance guidance carefully

When reviewing the operational dependency map, 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 operational dependency map, 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 operational dependency map, 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 operational dependency map, 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 operational dependency map, 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.

Trace a dependency through the real outcome

If a communications vendor fails, map which confirmations, interpreter contacts, staff notices, escalation routes, and family updates depend on it. Show approved alternatives, access needs, data flows, owners, recovery targets, and stop conditions. Test the map through a bounded scenario and record where the alternate path still relies on the failed service. A line between two systems is useful only when owners can act on the consequence.

Related resources

Sources