To turn ABA session data into a draft note without an unsafe tool, either strip every identifier from the data and use a client code, or use only a tool your vendor contract covers with a signed business associate agreement (BAA). Either way the draft must come from the technician's data, and a BCBA must check every line before signing.
The temptation is to paste a messy data sheet into a free chatbot and ask for a note. Do not. Free consumer accounts are the wrong place for anything about a child with a diagnosis, and "I removed the name" is weaker protection than it sounds. The workflow below is designed for a practice owner who wants to save note-writing time while keeping the clinical content in clinicians' hands.
Decide the route before you write a single prompt
There are two safe routes, and a practice should choose one as policy, not leave it to each technician's judgement.
Route A: de-identified data in a general tool. Staff convert each session's data into a coded form with no personal details, paste that into an approved AI account, and copy the draft back into the practice's record system, where the code is replaced with the client's real record. This keeps identifiable details out of the AI tool, but it only works if the coding is disciplined. Treat it as the cheaper, more labour-intensive route.
Route B: a tool covered by a BAA. You use a product whose vendor has signed a BAA with your practice for that exact product and plan, with retention and training settings checked. Identifiable data can then be handled inside the tool, within the limits of the contract. This route costs more and needs more checking, but it removes the coding step. The sibling tutorials on which AI vendors sign a BAA for therapists and whether ChatGPT is compliant on its free, business and clinician plans go through the vendor checks. Verify the position on the vendor's page on the day you sign, because plans and terms change.
Whichever route you pick, three rules hold. Only the practice's own accounts are used, never a technician's personal login. No one pastes in recordings, photographs or video of a child. And the AI never decides what happened in the session: it formats what the data says.
What counts as an identifier here
A name is the obvious one. The less obvious ones are what make a record identifiable to a parent, a teacher or a neighbour. Treat all of these as identifiers in Route A: names of the child, parents, siblings, teachers and classmates; school or clinic names; exact dates and times; the child's address or town; unusual details such as "the only child at the centre who uses a particular device"; and free-text phrases the child said that are distinctive. Replace them with a client code, "session 23", an age band and generic roles ("a peer", "a parent").
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowA worked example, from the data sheet to the draft note
This is an illustration with invented numbers. A technician runs a 120-minute session in a client's home for a child coded C-17, aged 4 to 5. The treatment plan has three programmes active this week: requesting items by pointing or signing ("mand training"), matching colours, and tolerating a wait before a preferred item arrives. The technician collects trial data on the first two and a frequency count of a behaviour for the third.
The raw sheet, de-identified for Route A, looks like this:
Client: C-17 | Session 23 | Age band: 4-5 | Duration: 120 min | Setting: home
Staff role: RBT | Supervisor: BCBA-1
Programme 1: Manding (point or sign) for 4 preferred items, 10 trials
Trials: + + - + + P + + - +
(+ = independent, P = prompted, - = incorrect or no response)
Independent: 7/10 = 70%. Prompted: 1. Incorrect: 2.
Prior session independent: 5/10 = 50%.
Programme 2: Colour matching, 3 colours, 12 trials
Trials: + + + + + + + + + P + +
Independent: 11/12 = 92%. Prompted: 1.
Mastery criterion in plan: 90% across 3 sessions. Sessions at or above 90% so far: 2.
Programme 3: Waiting for a preferred item
Wait duration target this session: 20 seconds.
Wait completed without protest: 4 of 6 opportunities.
Behaviour: Protest (crying or dropping to the floor): 2 episodes, 40 s and 75 s.
Antecedent for both: item delayed. Consequence: calm wait prompt, item given after calm.
Other: Child had a cold, nose running. Parent present, practised the wait routine once with RBT.Notice what is in the sheet and what is not. Every number comes from the technician's data. The percentages were worked out by the technician (7 of 10 is 70%). The mastery line comes from the plan, not from the AI. Anything the AI might be tempted to invent, such as mood or progress "towards goals", is absent.
The prompt
The instruction needs to restrict the model, not encourage it:
You are helping a registered behaviour technician draft a session note from
data they collected. Use ONLY the information in the data below. Do not add
any observation, reason, outcome or goal that is not in the data. Do not
interpret behaviour. If a field is missing, write "[not recorded]".
Format:
1. Session details (one line)
2. For each programme: what was run, the results with the numbers given, and
change from the prior session if the data states it
3. Behaviour events: antecedent, behaviour, consequence, duration, as recorded
4. Parent involvement, as recorded
5. Items for BCBA review (list anything unclear or inconsistent)
Write in neutral, past-tense, plain language. No praise words such as "great"
or "excellent". Keep it under 250 words.
DATA:
[paste the coded session sheet]A realistic draft and what the reviewer fixes
Here is the kind of draft a good tool returns for that sheet. It is an illustration.
Session 23, client C-17, 120 minutes, home setting, run by an RBT under BCBA-1.
Manding: 10 trials across 4 preferred items. Independent responses 7/10 (70%),
prompted 1, incorrect 2. The previous session was 5/10 (50%) independent.
Colour matching: 12 trials, 3 colours. Independent 11/12 (92%), prompted 1.
This is the third session in a row at or above 90%? [see review item 1]
Waiting: target 20 seconds. Completed without protest 4 of 6 opportunities.
Two protest episodes (crying or dropping to the floor), 40 s and 75 s.
Antecedent: preferred item delayed. Consequence: calm wait prompt, item
given after calm.
Parent involvement: parent practised the wait routine once with the RBT.
Child had a cold, running nose.
Items for BCBA review:
1. Mastery: data shows 2 sessions at or above 90% so far including this one?
Please confirm the count.Three things deserve the reviewer's attention. First, the colour-matching line guesses. The sheet says "sessions at or above 90% so far: 2" without saying whether that includes today, and the draft filled the gap with "the third session in a row?". The fix sits in the data sheet and the prompt: write "including this session" or "before this session" on the sheet, and tell the model to quote the count and say nothing about mastery. Second, "Child had a cold" is in the data, but a note that mentions illness may need to be tied to why a number looks low, and only the RBT knows whether that is true. Third, the draft did not say "good progress", which is what you want; if it ever does, delete the phrase, because a note that evaluates is a clinical judgement and belongs to the BCBA.
What the BCBA checks before signing
The review step is where the workflow earns the right to exist. Give the reviewer a short, fixed checklist and an expected time of about three minutes per note.
- Numbers match the data sheet, trial by trial and percentage by percentage. Recompute at least one.
- Nothing appears that is not on the sheet. Look for feelings, causes, reasons and praise.
- Goals named are goals in the current treatment plan, in the same wording.
- Behaviour events are factual: antecedent, behaviour and consequence as observed, without interpretation.
- Prompt levels and session length match the schedule and the billing entry.
- Anything marked "[not recorded]" is either filled in by the technician or left blank on purpose.
- Dates, names and codes are replaced correctly when the note moves back to the record system (Route A).
If the note fails any item, send it back to the technician for correction, not to the AI for another attempt, and record the reason. A pattern of the same failure tells you to adjust the prompt or the data sheet, or to stop using AI for that note type.
Five variations that practices run into
These examples show how the same workflow bends.
- A parent-training session. The data is about the parent's performance of a procedure, such as "implemented the wait routine correctly 3 of 4 times". The prompt should say the subject is the caregiver, and the draft must not read like a critique. Route the note through the BCBA, who decides how to phrase feedback.
- A school-based session. Teachers, classmates and school names are the identifiers most likely to slip through. Replace them with "a teacher" and "a peer" in the sheet, and check the draft for any detail like a room name.
- A session with a safety incident. Do not use AI. Incident reports follow their own procedure, are written by the people who were there and go to the BCBA and the practice's reporting process immediately.
- A cancelled or shortened session. The data sheet may record only the reason and the minutes delivered. The prompt must not turn that into a narrative. A short factual line is the whole note.
- Two technicians, one session. If the sheet merges data from two staff, the draft can blur who did what. Keep one sheet per technician and say so in the prompt.
Design the data sheet so the draft needs less fixing
Most poor AI drafts come from poor input. A technician's shorthand that makes sense on the day, such as "mand 7/10 gd, J refused wait x2, mum helped", gives the model plenty of room to guess. Spend an hour with your BCBAs designing one standard sheet that every technician fills in the same way. It makes human-written notes better too.
A good sheet has fixed fields, in a fixed order: session code and number, age band, duration, setting, staff role; then one block per programme with the target, the trial string, the counts you have worked out and the prior session's result; then a behaviour block with antecedent, behaviour, consequence and duration for each event; then a short free-text line limited to facts the technician saw. Keep that last line to one or two sentences so a technician cannot bury a long narrative that carries identifiers.
Before and after: shorthand into a coded sheet
Take that shorthand line. Here is the same session information as a technician might first scribble it, and as it should be after the coding step. Both are invented for the illustration.
BEFORE (do not paste anywhere):
[child's first name]'s mum let me in at 9. mand 7/10 gd. refused wait x2 (cried, floor).
mum helped w/ wait. ear infection last wk. back at school Mon w/ Mr [surname].
AFTER (safe to use as input in Route A):
Client: C-17 | Session 23 | Age band: 4-5 | Duration: 120 min | Setting: home
Programme 1: Manding, 7/10 independent.
Behaviour: Protest x2 (crying, dropping to floor). Antecedent: item delayed.
Parent involvement: parent practised the wait routine once.
Other: child recently unwell. Return to school next week.Notice what the coding step removed or generalised: the child's name, the parent's role as a named person, the time of arrival, the infection detail, the day of the week and the teacher's name. It also added the antecedent, which the shorthand missed. If the technician cannot supply an antecedent, the sheet says "[not recorded]" and the BCBA decides what to do. The coding step takes a technician about two minutes once practised; if it takes ten, the sheet design is wrong.
A second prompt for behaviour events
Behaviour events are where an AI is most likely to add interpretation, so use a narrower instruction for them rather than one general prompt:
Rewrite each behaviour event below as one factual sentence in the form:
"Antecedent: ... Behaviour: ... Consequence: ... Duration: ...".
Do not use the words "tantrum", "meltdown", "attention-seeking", "manipulative",
"noncompliant" or any other label. Do not state a function of the behaviour.
If any of the four parts is missing, write "[not recorded]" for it.
Output nothing else.A sample result for the two protest episodes above would read "Antecedent: preferred item delayed. Behaviour: crying and dropping to the floor. Consequence: calm wait prompt, item given after calm. Duration: 40 seconds" and then the same for 75 seconds. That is the entire output, and it is the kind of constrained task AI handles well. Identifying the function of the behaviour is the BCBA's analysis. A note that states a function on the strength of one session is an assessment made by software.
Training technicians to use it properly
A policy is only as good as the first week of use. Run a 45-minute session for the team with three exercises. First, give everyone the same raw sheet and ask them to code it, then compare what each person removed. The differences show which identifiers people miss. Second, hand out a draft with three planted errors, say an invented praise word, a percentage that does not match the trials and a goal that is not in the plan, and ask them to find all three in five minutes. Third, ask what they would do if they pasted the wrong sheet into the tool. The right answer is to tell the practice owner at once, not to quietly delete the chat.
Keep a short log of questions that come up in the first month. They tend to be the same four: what counts as an identifier, who signs, what to do with a cancelled session, and whether the model can fill in a missing number. The answer to the last is never. A missing number is a gap in the record, and the technician or supervisor fills it in from what they know, or leaves it marked as missing.
Where this goes wrong, and how it shows up
Three failure patterns turn up repeatedly. The first is invented continuity: the model writes "continued to make progress on mand training" because notes usually say something like that. Block it with the "use ONLY the data" rule and the ban on evaluative words, and find it in review by searching for "continued", "progress", "improved" and "demonstrated".
The second is near-identical notes. If every session note across a caseload uses the same sentences, a funder reviewing records may question whether the notes reflect real sessions. Notes should differ because the data differs. Ask the reviewer to compare two notes for the same client side by side every month and check the wording follows the data, not a template. Payer documentation rules differ, so check your funders' written requirements; I have not assumed any here.
The third is identifier leakage on the way back. In Route A the AI works with a code, but when the draft is pasted into the record system someone may type the client's name into the same text, or paste the original sheet into a chat to "fix a typo". Make the rule simple: the original sheet never goes into any AI tool, only the coded version.
Setting the policy down on one page
A one-page policy that every technician and BCBA signs covers six lines. Which AI tool is approved, and for which route. What data may be put in, and what may never be. Where the key linking client codes to children is stored (not in the AI account). Who reviews and signs notes. What to do if identifiable data goes into an unapproved tool: report it to the practice owner the same day, so the owner can decide what follows. And how often the policy is reviewed, say every quarter. How to write an AI usage policy for your small business gives a general skeleton you can narrow for a clinical setting.
Time and cost are worth a quick sum. Suppose a technician spends 12 minutes writing each note by hand and sees 5 clients a day, which is an hour a day of note-writing. With data sheets already tidy, drafting and checking might take 5 minutes, saving roughly 35 minutes a day per technician. Those figures are illustrative; time your own staff for a week before and a week after. Set against that, count the BCBA's review time, the cost of a BAA-covered tool if you take Route B, and the time to train staff. If the net saving is small, keep AI for the notes where it helps most, such as long sessions with a lot of trial data, and skip it elsewhere. For other jobs worth considering across a practice, see AI for ABA therapy practices: seven admin jobs and three to keep human.
How to check the workflow is still working after six months
A workflow that worked in the pilot can drift. Technicians get busy, the coding step gets skipped, and reviewers start skimming. Put three checks in the calendar. Each quarter, the practice owner pulls ten notes at random and reads each against its data sheet, counting numbers that do not match and phrases that are not in the data. Each quarter, someone confirms the vendor's retention and training settings are unchanged, since a plan upgrade or a new feature can alter them. And each time the treatment plan template changes, the prompt is updated to match it.
Set a stop rule in advance. If a quarterly sample finds more than one invented fact in ten notes, pause the AI step for that note type until the cause is found. A pause costs a few days of slower note-writing. An invented fact in a signed clinical record costs far more, and it is the practice owner who answers for it.
Testing the workflow before you roll it out
Run a two-week pilot with one BCBA and two technicians, using de-identified past sessions, never live ones in a first run. Have each technician write the note the usual way and also produce the AI draft from the same data. The BCBA reviews both blind and records the corrections needed. You are looking for three things: whether the AI drafts need fewer or more corrections than the hand-written ones, which kinds of error appear, and how long the whole process takes including review.
If the corrections are mostly formatting, you have a useful tool. If they include invented content more than once or twice, tighten the prompt or drop the use. For an extra read on what consent and notice to give families, the guide to AI scribe notes, reports and consent checks for psychologists covers wording that carries over to behaviour-analytic practice, and nothing here is legal advice. Check your funder's, regulator's and certification board's own rules on documentation, supervision and the use of AI before you start.
Questions practice owners ask about AI and session notes
Is removing the client's name enough to make data safe?
No. Dates, a rare diagnosis detail, a school, a sibling's name, a unique behaviour or an unusual schedule can identify a child even without a name. Use a client code, session numbers instead of dates and age bands instead of birthdays, and keep the key that links the code to the child in your own system.
Does a BAA make a chatbot safe for session notes?
A business associate agreement is a contract that sets the vendor's duties for protected health information. It does not cover every product or plan: OpenAI, for example, says it offers no BAA for ChatGPT Business, and that a BAA alone does not make you compliant. Confirm in writing that your exact product and plan is covered, check retention and training settings, and keep staff off personal accounts.
Can the AI choose which goals to mention?
It should not. The goals, targets and behaviour plans come from the treatment plan the BCBA wrote. Give the AI only the data for goals worked on that session and tell it to write nothing about any goal that was not in the data, so it cannot pad a note with activity that did not happen.
Who signs a note an RBT drafted with AI?
Whoever the funder and your supervision rules require, usually the technician who ran the session and then a BCBA review. AI does not change who is responsible. The signer must have read every sentence and confirmed it against the data, because the signature says the content is true.
Further reads
- Is Claude HIPAA Compliant? Which Plans Offer a BAA — The same plan-by-plan BAA check for Claude.
- AI Scribe Security: Audio, Retention and BAA Vendor Questions — Audio, retention and BAA questions to put to any vendor.
- AI Usage Policy for a Medical Practice: Template and HIPAA Rules — A clinical AI usage policy template to adapt.
- How to Write NDIS Progress Notes: An AI-Assisted Audit Checklist — A progress-note audit checklist from a sister care sector.
- Care Staff Supervision Template: Notes and Action Logs With AI — Supervision notes and action logs drafted with AI.
- ChatGPT for Clinicians: Does the Individual BAA Cover Your Practice? — What an individual BAA does and does not cover.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: official guidance on business associate contracts and OpenAI's help article on BAAs (both read 4 November 2026); your own treatment plan and funders' documentation rules; vendor trust and BAA pages for the exact product and plan you use. No vendor is endorsed here.