Writing the note is often the longest part of a session. A practitioner finishes a 90-minute direct-care block, sits down at a keyboard, and then spends another 30 to 45 minutes converting a day of trials, behavior counts, and ABC incidents into a narrative that satisfies the payer, the supervising BCBA, the school team, and the parent. By the time the note is signed, the next session is already starting.
Generative AI promises to compress that step from 30 minutes to 5. The risk is that the same note, pasted into a consumer AI tool, can leak protected health information in ways that are difficult to detect, difficult to retract, and difficult to defend in a HIPAA review. A single client name in a free-text prompt, a date of birth in a behavior description, or an insurance member ID embedded in a trial answer can travel through model provider logs that the clinic does not control and cannot erase.
This guide explains how Cognix Health makes AI-assisted clinical documentation safe enough for production ABA workflows. It covers the pseudonymization layer that strips HIPAA Safe Harbor identifiers before a prompt is built, the routing choice that keeps model traffic inside a contracted cloud environment, the prompt-assembly rules that adapt to different clinical artifacts, the audit trail that records usage without recording the narrative, and the interface rules that prevent accidental overwrites of clinician-written text. It then walks through the failure modes the design is built to defend against and the practices that keep the workflow trustworthy as it scales.
Complementary reading: The Complete Guide to ABA Therapy Data Collection describes the structured trial data that feeds the AI prompt. ABC Incidents and FBA Reports describes the structured observation records that travel alongside that data. Goal Phases and Mastery Criteria explains why behavior reduction goals need different progress rules and how that distinction shows up in the prompt.
The PHI Risk Inside a “Helpful” Note
A clinical note is dense with identifiers. Even when the writer is careful, identifiers hide in places the writer may not think of as sensitive:
- A free-text goal description that names a sibling, a school, or a neighborhood.
- An antecedent note that mentions a specific transition, a teacher’s name, or a medical diagnosis phrase.
- A trial answer that quotes the client by name, mentions a medication, or includes a date.
- A session note header that contains the client identifier, the date of service, the start and end time, and the service code.
- A signature field that carries a base64 image of the rendering provider’s signature.
If any of those strings is sent to a third-party model that the clinic does not contract with, the clinic has likely disclosed PHI without a business associate agreement, without a documented purpose, and without a verifiable trail of what was sent. Most consumer AI tools explicitly state that prompts may be reviewed by humans, retained for training, or stored indefinitely. Even providers that offer a “no training” tier rarely give the customer a per-prompt audit record of what the model saw.
The safe design is not “trust the vendor.” The safe design is to send the model the smallest structured subset of the note that still produces a useful narrative, to log exactly what was sent in a way that proves PHI was not included, and to keep the clinician in the loop for the parts of the note that carry judgment.
AI Documentation Safety at a Glance
These figures describe what the workflow is designed to deliver for clinicians as of July 2026 — time back, the right note type, and a guarantee that identifiers never reach the model.
The Pseudonymization Layer: Two Defenses in Series
Cognix does not send raw session data to the model. Every record passes through a pseudonymization step that runs in two passes — a key-based redaction and a pattern-based redaction — before the prompt is assembled. The two passes cover different failure modes and are designed to be additive rather than redundant.
Key-Based Redaction: Stop the Obvious
The first pass works on field names. Any field whose name identifies a person — names, contact details, dates of birth, insurance and record numbers, internal identifiers, signatures — is dropped before the prompt is assembled, regardless of what it contains. Matching is case-insensitive and covers the naming styles that appear across real intake forms, so a field added later with an identifying name is removed automatically rather than needing to be remembered.
The pass is deliberately narrow. Clinical free-text fields are what the model needs in order to write anything useful, so they are not dropped here — they are handled by the second pass.
Pattern-Based Redaction: Catch the Leak Inside the Field
The second pass reads the values that survived the first. A field name can be perfectly innocuous while the text inside it carries an identifier, so every remaining string is scanned for the categories of identifier that HIPAA Safe Harbor calls out — government and insurance numbers, contact details, dates tied to an individual, network identifiers, geographic codes, and embedded signature images. Each match is replaced with a marker that preserves the sentence structure while removing the identifier, so the model keeps the clinical context and loses the person.
Why Two Layers, Not One
A single layer of defense always fails in the same way. Key-based redaction is fast and reliable, but it cannot catch a name that lives inside a clinical free-text field. Pattern-based redaction catches that, but pattern matching can miss an identifier that does not look like a known format. Running both in series means an identifier has to slip past two independent checks. The pseudonymization step is intentionally defensive; missing a redaction is the worse error.
The two layers also work recursively. If a top-level field is an array of objects, every object in the array is pseudonymized with the same rules. If a value is an object, every nested key is checked against the list. The output structure mirrors the input structure so the calling code does not have to do anything special with the redacted result — it passes the same shape forward, with the same keys, just safer values.
What the Model Actually Sees
The pseudonymized data becomes the data section of a structured prompt. That prompt has three parts: a system prompt that sets clinical tone and rules, a user prompt that varies by field label, and a data section that is the pseudonymized session record.
The System Prompt
The model is given a fixed clinical contract that sets tone and scope, and is instructed never to include identifying information. That contract stays constant across users and organizations so the clinic does not have to reinvent prompt engineering for every note.
The system prompt is the part of the design that sets the model’s behavioral contract. It keeps clinical tone consistent and makes the “never include identifiers” rule part of every generation, not an optional afterthought.
The User Prompt: Three Instruction Modes
A daily note, a treatment plan, and a progress review are different clinical artifacts, and they deserve different prompts. The platform selects the instruction shape that matches the artifact the clinician is writing — summary, plan, or progress — so the draft reads like the document the payer and the supervising BCBA actually expect.
The instruction mode is the part of the design that respects that difference. The insight is simple: one model, three kinds of writing, and a prompt that matches the job.
The Data Section: Skill Goals, Behavior Goals, and ABC Incidents
After the instruction comes the data. The model receives structured, de-identified counts and observations rather than free-form text — skill performance, behavior measures, and ABC incidents summarized so the draft has something concrete to write about.
The data section is the part of the design that gives the model something concrete to write about. It is also the part that protects the client: there are no client names, no staff names, no internal identifiers, and no free-text fields that have not been pseudonymized. The model has exactly what it needs to write a good note and nothing it could use to identify the client.
The Observation Session Enrichment
Not every session has direct trial data. Supervision sessions, BCBA observation sessions, and parent-coaching sessions are common parts of an ABA week, and they often do not have their own goal trials. A note for those sessions still needs to say something useful about what was observed.
Supervision and observation sessions often carry no trial data of their own, and the platform links them to the parallel direct-care session so the note reflects what was actually observed. The observation session becomes a frame for the data; the data stays tied to the session where it was collected. If no parallel session has data, the model is asked to write a professional narrative without inventing numbers it does not have.
The Audit Log: What Is Recorded and What Is Not
Every generation writes a metadata-only record — never the narrative, never the prompt, never a client identifier. The audit log is sufficient to answer the question “did anyone generate AI content for this session, on this day, in this organization?” It is not sufficient to reconstruct the narrative or to identify the client. If a regulator asks for proof that PHI was not sent to the model, the audit row is the artifact: it shows the model was called, what was billed, who called it, and when. It cannot be reverse-engineered into the underlying note.
The audit log is also scoped to the organization. Org members can see their own organization’s audit rows, but they cannot see the audit rows of other organizations. The same per-organization access controls that protect sessions protect the audit log.
The Button-State Rules
The AI generation button is the part of the interface the practitioner actually touches, and its state has to be predictable. Two promises matter most to a buyer: clinician-written text is never overwritten, and a published note cannot be regenerated.
A field with manually-written text gets no AI button at all. The clinician’s words are not at risk of being silently overwritten by a regeneration. The button is a tool for empty fields and AI-generated fields; it is not a tool for editing clinician content.
A published session cannot be regenerated. Once a note is signed and finalized, the underlying record is treated as the source of truth. The button is removed from the interface, and a generation request for a published session is refused. This is the part of the design that prevents an after-the-fact rewrite of a finalized note.
The Organization-Level Feature Gate
AI generation is a per-organization capability, not a platform-wide default. Each organization has a flag that controls whether the AI button is visible at all. When the flag is off, the button does not render, any generation request is refused, and the audit log is never written. When the flag is on, the button renders for every note field that has a narrative purpose, generation is reachable, and the audit log is written for every call.
The flag is the part of the design that gives the organization a clean way to opt out. A clinic that is not ready to introduce AI into its documentation workflow can leave the flag off and use the rest of the platform without the AI surface. A clinic that wants to introduce AI for a specific service line can leave the flag on and rely on the button-state rules to control which fields use it. A clinic that wants to introduce AI everywhere can leave the flag on and treat the generation as a default helper.
The flag is stored in the same organization record that controls subscription, branding, and other per-tenant settings, and it is exposed in the same admin interface. There is no global toggle, no environment variable that overrides the flag, and no privileged user role that can use AI for an organization that has the flag off.
The Admin Usage Dashboard
When AI is enabled, the organization gets per-organization visibility into usage, cost and response time, built from the same audit records. Clinical directors and operations leads can see whether the team is actually using the feature, whether the cost is reasonable, and whether response time is acceptable — without ever seeing the narrative or the prompt.
Best Practices for Using AI Documentation Safely
- Collect the data first, then generate. The model writes a better note from structured data than from a free-text draft. Goals, targets, trials, and behavior counts should be entered before the AI button is pressed.
- Review the generated note as if you wrote it. AI-generated text is a draft. The clinician is responsible for accuracy, completeness, and compliance with payer requirements. Editing is part of the workflow, not a sign of failure.
- Do not paste unrelated PHI into the note before generating. The pseudonymization step catches identifiers in the data, but it cannot defend against identifiers typed directly into the field by the clinician. Treat the field as if it were already signed.
- Use the right instruction mode for the artifact. A daily note, a treatment plan, and a progress review are different documents. Match the field label to the artifact, and let the prompt assembly match the field.
- Regenerate only when the underlying data has changed. A generation should be triggered by new information, not by aesthetic preference. Each generation adds a row to the audit log, and the log should reflect meaningful use.
- Prefer empty fields for generation. A field with clinician-written text disables the AI button. The design treats clinician words as the higher-trust content; let the AI fill the empty fields and keep your own edits.
- Keep the org-level flag aligned with policy. If the organization’s policy is to use AI for service summaries but not for treatment plans, the flag should reflect the policy, and the template should reflect the flag.
- Read the AI guidelines page for your organization. The guidelines page is the part of the platform that says what the AI is for, what it is not for, and what the clinician is responsible for. The guidelines are not boilerplate; they are the operating contract.
- Treat the audit log as compliance evidence. The audit row is the artifact a regulator will see. If a row is missing, the generation should be re-run. If a row is unexpected, the generation should be reviewed.
- Use the usage dashboard, not your gut, to make adoption decisions. Token counts, call counts, and per-user breakdowns are the inputs to a clinical operations decision. Impressions are not.
Common Mistakes and How to Avoid Them
How Cognix Health Supports AI-Assisted ABA Documentation
Cognix Health treats AI as a documentation accelerator, not a documentation replacement. The platform is built so that pseudonymization, prompt assembly, and audit happen in the same transaction that returns the narrative, and so that the clinician remains the final reviewer of every field.
The workflow includes:
- Two-layer pseudonymization — identifying field names dropped first, Safe Harbor identifiers scrubbed from surviving values second
- Artifact-aware prompts — daily notes, treatment plans, and progress reviews get different instruction shapes
- Structured, de-identified data — counts and observations rather than free-form text
- Observation session support — supervision and observation notes can reflect the parallel direct-care session that was actually observed
- Org-level feature gate — every organization can opt in or opt out, and the AI button disappears entirely when the flag is off
- Audit log without narrative — every generation writes a metadata-only record, never the narrative, the prompt, or a client identifier
- Overwrite protections — clinician-written text is never overwritten, and published notes cannot be regenerated
- Admin usage dashboard — per-organization visibility into usage, cost, and response time from the same audit records
The goal is to keep the clinician in the loop. The model drafts; the clinician edits; the audit row records the draft. The narrative is never assumed to be correct just because the model wrote it, and the platform never assumes the model is safe to use just because the provider is well known.
Want to see how AI-assisted documentation fits your clinical workflow? Contact Cognix Health to schedule a demo.
Frequently Asked Questions
Does the AI ever see the client’s name or other identifying details?
No. Before any data is sent to the model, it passes through two layers of redaction. Identifying field names are dropped first; remaining text is scanned for the categories of identifier HIPAA Safe Harbor calls out. The audit log records only metadata, not the original text, so it cannot be reverse-engineered into the underlying note.
What model does Cognix use, and where does the prompt travel?
A HIPAA-eligible model running inside our own contracted cloud environment. Prompts never reach a consumer AI tool, and the environment is covered by a business associate agreement.
Can AI generate a note for a published session?
No. The button is disabled for any session that is already published, and any generation request for a published session is refused. The published note is treated as the source of truth, and the platform does not support silent rewrites of finalized content.
What happens if a clinician has already written some text in the field?
The AI button is disabled for any field with manually-written text. The design treats clinician-written text as the higher-trust content, and it does not allow the AI to overwrite it. If the clinician wants to start over, they can clear the field, and the button becomes available again.
Is the AI generation allowed for every organization?
No. Each organization has a flag that controls whether AI generation is available at all. The flag is set per organization, and the AI button is hidden entirely when the flag is off. A clinic that does not want AI in its workflow can keep the flag off and use the rest of the platform normally.
Can the AI help with observation sessions that have no direct data?
Yes. Supervision and observation sessions often carry no trial data of their own, and the platform can link them to the parallel direct-care session so the note reflects what was actually observed — without inventing data when nothing is available.
How are token counts and latency measured?
Every generation request measures the start time, the input tokens billed by the model, the output tokens billed by the model, and the end time. Those four values are written to the audit log as integer counts and a millisecond latency. The admin usage dashboard aggregates them across calls, days, and users for the selected organization.
Can the model recommend a treatment plan?
The model can summarize data and suggest language, but it does not replace clinical judgment. Treatment plan recommendations belong to the supervising BCBA, and the AI generation is positioned as a draft that the BCBA reviews and edits. The prompt includes an instruction to produce recommended interventions, but the language is framed as options to consider, not as instructions to implement.
Does the audit log show what the model was told?
No. The audit log records what was billed and when, not what was sent. The pseudonymization step is the layer that ensures the prompt is safe, and the audit log is the layer that records the call happened. Showing the prompt in the audit log would defeat the purpose of the pseudonymization, because the log itself would then need to be redacted.
What happens when a generation is in progress?
The button shows a “Generating…” label with a spinner, and it is disabled. Multiple generations cannot be triggered in parallel from the same field, and a generation that takes longer than the configured timeout is treated as a failure and surfaced as a user-visible error.
How does the platform handle the case where a generation returns an empty or malformed response?
The model response is parsed for text blocks. If no text block is present, the generation returns an empty narrative and the practitioner is asked to write the field manually. A generation that returns a malformed response does not corrupt the underlying session data, and the audit log records the call regardless of whether the response was usable.
This guide reflects Cognix Health AI-assisted documentation as of July 2026. Clinical teams should use their organization’s AI policy, supervision procedures, documentation standards, and applicable payer requirements when enabling or using AI generation. The AI tool is a documentation assistant, not a documentation replacement. For questions about how Cognix Health supports safe AI documentation for ABA workflows, reach out to our team at [email protected].