The ABA Data Collection Trap (And How to Get Out)
Most ABA centers spend 40% of their billable session time on data entry. Here's how the workflow gets broken — and the four changes that fix it.
If you run an ABA or EIDBI center, you already know the math. A 3-hour session with one client. Forty trial DTT data points. Three target behaviors logged by frequency. Eight task analysis steps recorded. Skill program graphs to update.
By the time the RBT finishes the session, there can easily be another 30–45 minutes of data entry waiting in a clinical portal — a meaningful share of session time spent re-typing what was already written on a clipboard.
How the trap forms
Most centers ended up here through three legitimate decisions, each one made for good reasons:
- Data was first collected on paper because clinicians needed something fast at the table.
- A clinical portal was added because supervisors needed graphs and parent reports.
- A separate billing system was added because the clinical portal didn't handle MN MA claim formats.
Each step solved a real problem. But now a single session touches three systems that don't talk to each other, and the RBT becomes the integration layer.
The four changes that fix it
1. Collect data once, in the place you'll use it. If your RBT writes a frequency tally on paper at the table, that should be the same input that updates the parent graph and ties to the billable unit. One collection event. Anything else is duplicate entry.
2. Make data collection match the clinical method. DTT, task analysis, frequency, duration, ABC — these aren't interchangeable. A "trial counter" UI is wrong for task analysis the way a stopwatch is wrong for frequency counting. Forcing one tool to handle all collection methods is why RBTs fall back to paper.
3. Auto-graph at session end. The reason supervisors need the second portal is to see graphs. If your collection tool graphs trial data automatically and rolls into mastery criteria, you've eliminated the export/import step.
4. Tie the session to the unit at submit time. The RBT presses "End session." That action should: lock the data, generate the parent-facing summary, queue the billable unit, and update goal mastery. If any of those is a separate workflow, you've reintroduced re-entry.
What this looks like in practice
Lumix collects DTT, task analysis, frequency, duration, and interval data with method-specific UIs at the table. Skill programs auto-graph. Behavior reductions and acquisitions roll into the parent summary. The "End session" action locks data, queues the claim, and updates goal mastery in one transaction.
How much time you'd reclaim depends on your specific session count, RBT roster, and which method-specific data you're collecting. We can walk through your numbers in a demo and show you the math against your current workflow — no spreadsheet required.