ABA schedule test data governance controls which fictional, synthetic, de-identified, or otherwise authorized data may be used to test scheduling systems. It records purpose, provenance, approved environment, fields, expected outcomes, access, refresh, retention, and deletion. The workflow prevents real client information from entering casual tests, keeps test records out of production decisions, and makes results reproducible without presenting a test label as a privacy status.

Start with the test purpose

Name the workflow, risk, decision, environment, and cases the data must support. A field belongs only when the test needs it. Distinguish functional, integration, performance, access, security, migration, recovery, and training uses. One oversized golden client record encourages broad copying and makes it harder to know whether each field has an approved source and lifecycle.

Classify data provenance

Mark records as purpose-built fictional, generated synthetic, transformed, de-identified under a documented method, or authorized real data under a specific route. Record creator, source, method, date, restrictions, and reviewer. Synthetic is a provenance description rather than a legal status. Inspect generated and transformed data for retained names, identifiers, rare facts, and production links before use.

Prefer purpose-built fictional cases

Create realistic but invented clients, staff, sites, payers, services, time zones, access needs, series, exceptions, cancellations, and conflicts. Reserve identifiers that cannot collide with live records. Include clear visual and machine labels. Fictional cases support reproducible tests while reducing the need to move client data. Keep the scenarios varied and update them when workflows change.

Keep clinical examples bounded

The BACB Ethics Code supports confidentiality and qualified clinical accountability for covered people. Test cases may represent clinical gates and documented decisions without claiming that the fictional content is a universal protocol. Qualified reviewers should approve safety-sensitive cases and expected outcomes within their scope.

Classify security obligations

Determine entity, data, system, vendor, and environment scope. For HIPAA covered entities and business associates, the HHS Security Rule overview frames safeguards for ePHI. An environment called test does not reduce duties for real ePHI. Control access, credentials, logging, transmission, storage, backup, incident routing, and disposal according to actual data.

Separate environments

Use unmistakable organization, user, domain, API, database, bucket, queue, notification, calendar, and payment endpoints. Block test identities from production and production identities from test unless an approved case requires a narrow route. Display environment labels. Test that a wrong credential, endpoint, or configuration cannot send a fictional reminder to a real person or create a live appointment.

Define expected results

Give every case inputs, preconditions, action, expected source state, destination state, user view, side effects, and cleanup. Version both data and expectation. A passed test without a defined expected result can merely confirm that the system did something. Preserve accepted rounding, ordering, timing, and error behavior for later comparison.

Govern data refresh

State when test data resets, ages forward, re-seeds, or migrates. Preserve stable cases used for regression while keeping date-sensitive features realistic. Test leap days, daylight-saving changes, expired authorizations, inactive staff, and old app versions through controlled variants. A nightly refresh should not erase evidence from a failed test before the owner captures it.

A fictional data audit

Pine Coast ABA reviews 35 schedule test data sets. Twenty-nine have approved purpose, provenance, environment, access, expected results, and deletion rules. Two contain copied production identifiers, two have no owner, one can trigger a live notification, and one has an unknown refresh. Governance completeness is 29 of 35, or 82.9%.

Build the test-data register

Use data-set ID, purpose, workflow, provenance, generation or transformation method, fields, environment, record IDs, owner, reviewers, access, credentials, integrations, expected outcomes, seed and refresh versions, restrictions, retention, cleanup, last validation, defects, and retirement. Link detailed sensitive evidence through restricted storage. Keep the register readable enough for a release reviewer to choose the correct data set.

Test privacy and access

Attempt cross-organization lookup, direct URL access, copied IDs, export, log search, notification preview, calendar sharing, and use after role removal. Verify masked or fictional labels do not become the only protection. Review who can create, modify, approve, and export cases. Separate permission to run a test from permission to inspect every underlying field.

Test production barriers

Try to submit test clients, providers, sites, authorizations, visits, messages, and reports into live routes. Confirm the system blocks or safely quarantines them. Test reverse contamination by pointing a test client at a live destination. Monitor for known test prefixes and IDs in production. Give every detected crossover an incident owner and reconciliation cohort.

Control performance data

Large-volume tests need realistic distribution without cloning a live population casually. Define volumes, time range, relationships, rare cases, and resource limits. Preserve generation seeds and code versions. Review whether fabricated patterns expose real business information or create unsafe load. Keep performance results tied to the exact data shape and environment instead of generalizing from an unrepresentative set.

Retain and delete deliberately

Assign retention to input sets, generated records, logs, screenshots, exports, failed cases, and result packets. Remove temporary data after the approved need while preserving evidence required for the decision. Confirm deletion across databases, storage, calendars, vendors, caches, and backups according to their paths. Record holds and unresolved copies rather than marking the data set closed prematurely.

Retire obsolete cases

Review tests after schema, status, payer, clinical, access, and integration changes. Update expected results or retire the case with a replacement link. Preserve older cases needed for historical versions. Remove credentials and destinations that no longer support testing. An obsolete regression case can falsely fail a correct release or pass an old behavior that the practice intended to eliminate.

Measure test-data health

Report sets due, approved, fictional, synthetic, de-identified, otherwise authorized, ownerless, stale, production-connected, privacy-failed, cleanup-failed, and retired. Track defect escape and reproducibility. Pair counts with high-consequence findings. Review before releases and after incidents. Close gaps only after the corrected set and its barriers pass retest.

Validate realism without copying a person

Review whether the data set represents the combinations that make scheduling difficult: recurring exceptions, changing availability, cross-zone times, long names, language and access needs, inactive staff, overlapping services, expired evidence, late events, and partial integrations. Build those patterns deliberately from invented facts. Keep the distribution and relationships plausible enough to exercise constraints while avoiding a composite that reproduces a real person's distinctive history. Document why each boundary case exists and which expected result it tests. Invite operational, clinical, accessibility, privacy, and technical reviewers only for the cases within their scope. When a production defect supplies a new scenario, translate the causal structure into a fresh fictional case instead of copying the affected record. This approach improves regression value while keeping provenance clear and the test suite understandable. Review the fictional names, addresses, identifiers, and dates together so their combination cannot accidentally point to a real person.

Related resources

Sources