What Happens When an ABA App Records Data Incorrectly?

Contain the ABA app data error

First define the symptom and affected function. Examples include a timer that resets, duplicated taps, a wrong program version, missing offline entries, shifted timestamps, an incorrect denominator, or an export that changes labels. Pause the affected report or decision while safe care continues through an approved fallback.

Preserve original evidence

Keep device logs, screenshots, exports, paper backups, timestamps, user reports, software version, and correction history under the practice's approved process. Avoid overwriting the only copy. Identify whether the fault occurred during observation, storage, calculation, display, export, or later interpretation.

Find the full affected cohort

Search by software version, date range, clinic, program, measure, and workflow. A bug found in one graph may affect other records. Track reviewed, affected, corrected, unaffected, and unresolved records with named owners and dates.

The RBT Ethics Code requires accurate implementation and documentation under supervisor direction.

Separate technical correction from clinical judgment

Technical staff can explain system behavior and repair software. Authorized record roles can correct data under policy. The responsible clinician interprets the clinical effect, decides whether prior conclusions remain supported, and determines whether another observation is needed.

The BCBA Test Content Outline covers measurement, validity, graphing, and interpretation as examination content. The BACB Ethics Code addresses documentation, accuracy, correction, and evaluation for covered behavior analysts. The CASP public summary supports individualized evaluation at a high level.

A practical example

A release duplicates every offline tap for 18 records. Twelve used offline mode; six did not. The practice validates all 18, corrects the 12 affected records, preserves the prior exports, regenerates graphs, and asks the clinician to revisit two decisions that relied on the inflated count. Cohort review is 18 of 18, not 12 of 12.

Separate the incident into three questions

An app problem can affect system behavior, the legal or clinical record, and decisions made from that record. Each question needs a named owner.

• What did the technology do? The vendor or technical team can identify the software version, failure mode, logs, affected workflow, and repair.
• Which records are wrong or uncertain? Authorized record owners can compare app output with contemporaneous notes, backups, timestamps, and other source evidence.
• What changes clinically? A qualified clinician can determine whether a graph, conclusion, program decision, safety plan, or request still has adequate support.

A technical fix can stop future duplication while leaving older records unresolved. A corrected record can be accurate while a prior progress report still needs replacement. Keep all three tracks visible.

Families should receive a concrete explanation

When a person's record is affected, the provider should explain the known scope in understandable language. A useful update states what happened, the dates and measures under review, whether care or safety is affected, what has been preserved, who owns the correction, and when the family will hear back.

Avoid premature certainty. “We are reviewing entries from May 3 through May 9 that used offline mode” is more trustworthy than “nothing else was affected” before a cohort search is complete. If the practice later expands or narrows the scope, document that change.

Validate more than the visible graph

After correction, compare the source evidence with the stored value, calculation, graph, export, report, and any downstream interface. Check that timestamps, units, prompts, opportunities, and phase labels remain intact. A spot check may be appropriate for an isolated entry; a systematic defect requires a defined cohort and full or risk-based validation.

For high-stakes decisions, keep the affected records on hold until the validation rule is met. A graph that “looks right” is not enough when the underlying calculation or mapping failed.

Consider privacy and security separately

Some data errors also involve unauthorized access, disclosure, loss, or system interference. Route those facts to the privacy and security process rather than assuming every app defect is only a documentation problem. Preserve relevant evidence while following applicable incident and notification rules.

Families can ask whether the issue changed who could see information, whether data left the intended system, and whether another formal notice will follow. The clinical team should avoid making legal breach determinations outside its role.

Close the loop with prevention evidence

The practice can record the root cause, corrective action, software or workflow change, training, test cases, monitored release, and recurrence check. If staff workarounds contributed, improve the workflow rather than relying only on reminders. If a vendor caused the defect, confirm responsibility and evidence under the actual agreement.

Closure should mean that the affected cohort is accounted for, records and downstream outputs are reconciled, clinical impact is reviewed, families receive needed updates, and the prevention test passes. Closing the software ticket alone is too narrow.

Know when a fresh observation is safer

Sometimes source evidence can reconstruct the correct value. In other cases, the observer cannot reliably remember what occurred, device logs are incomplete, or the app failed during the event itself. The practice should avoid turning uncertain recollection into precise data.

The clinical owner can decide that the affected observation is invalid and plan a new one under current conditions. The record should retain the invalid state, reason, and downstream review. A new observation supplies new evidence; it does not retroactively repair the earlier event.

Keep billing and authorization consequences in their own track

If an incorrect entry supported a claim, authorization request, or payer report, route the issue to qualified billing, compliance, and payer roles. They can determine whether a corrected submission, disclosure, refund, appeal, or other action is required under the applicable source. The app's correction button does not make that decision.

Families should receive an understandable update if the error changes a cost estimate, service authorization, schedule, or other matter that affects them. Clinical care, record correction, and payer action can move on different timelines, so the practice should name an owner and status for each.

Ask for closure evidence

At the final update, request the confirmed date range, number of records reviewed, number affected, correction completion, graph or report disposition, clinical reassessment status, and prevention test. The totals should reconcile to the original cohort, including records found unaffected.

If any item remains unresolved, it should have an owner and due date. This closure summary helps the family understand what is finished without requiring access to confidential security details or personnel records.

Questions families can use

Ask what failed, when it began, which records were reviewed, how the original is preserved, who corrected each record, how the output was validated, which graphs or decisions changed, who interpreted impact, and what prevents recurrence.