AI in behavioral health EHRs: A buyer’s guide to evaluating vendors

AI clinical documentation in a behavioral health EHR is software that uses speech recognition, rules, machine learning, or generative models to capture, organize, summarize, suggest, or act on information generated during care. The term covers very different technologies with very different privacy, clinical, and governance implications. The breadth of that definition creates the first procurement problem. Vendors use the same word, “AI,” for workflows ranging from a macro that inserts standard text to a model that infers risk from a session.

Before comparing vendors, identify which tier is actually being sold.

The privacy and oversight requirements increase as the system moves from deterministic automation toward inference and prediction.

You should therefore ask the vendor to identify every AI function by tier. Then ask what information enters that function, what comes out, whether the output can trigger another action, and where the human checkpoint sits.

If the answer is simply “our EHR has AI,” you still do not know what you are buying.

42 CFR Part 2 became a live AI procurement issue on February 16, 2026.

That was the compliance date for the 2024 final rule aligning parts of 42 CFR Part 2 with HIPAA.^[1] In August 2025, HHS delegated authority to administer and enforce Part 2 to the Office for Civil Rights. OCR can investigate complaints, conduct compliance reviews, enter into resolution agreements and corrective action plans, and impose civil money penalties.^[2] Since February 16, 2026, OCR has been accepting complaints and breach notifications involving SUD patient records.^[3] The Part 2 penalty structure now aligns with HIPAA’s civil and criminal enforcement authorities.

For a behavioral health EHR buyer, this changes the diligence standard.

A single TPO consent does not make every SUD record interchangeable

The updated rule permits a single patient consent covering future uses and disclosures for treatment, payment, and health care operations. Certain covered entities and business associates receiving records under that consent may redisclose them according to HIPAA rules, subject to Part 2’s continuing restrictions.

The rule also says Part 2 records do not have to be technically segregated from the rest of the record.

That does not eliminate Part 2-specific controls.

HHS created a separately protected category for SUD counseling notes, meaning separately maintained notes analyzing the conversation during an SUD counseling session. A broad TPO consent does not authorize their use or disclosure. They require separate consent.

Part 2 follows the record into your vendor chain

This is why subprocessor disclosure matters.

If an AI documentation workflow sends a protected transcript to an EHR vendor, which sends it to a speech-recognition service, which sends text to a model API, you need to understand every entity handling that information and the legal basis for each disclosure.

Part 2 obligations can extend past the treating program to lawful holders of Part 2 records. Depending on the arrangement, that may include qualified service organizations and, in some cases, business associates.^[4]

A missing subprocessor in a security questionnaire is therefore more than a procurement annoyance. It can represent an unexamined disclosure path. Your AI diligence should begin with a data-flow diagram, not the note the vendor produces at the end.

Human in the loop means the AI drafts or suggests, the system applies the configured validation rules, and a named clinician reviews and attests to AI-generated clinical content before it becomes final documentation or supports a clinical claim.

That does not mean every AI action needs a person to click “approve.” There are three distinct operating modes.

Assistive draft

The AI proposes content and the clinician edits, rejects, or approves it. This is the appropriate model for progress notes, assessment summaries, treatment-plan language, diagnostic suggestions, medical-necessity narratives, and other content involving clinical meaning. The clinician retains responsibility for the final record.

Validated automation

The system checks an action against explicit configured rules before execution and logs the result. This can be appropriate for administrative workflows such as:

• Eligibility checks
• Claim scrubbing
• Work-queue routing
• Appointment reminders
• Deterministic data population
• Payer-rule validation

The value of AI and automation is partly its ability to execute defined administrative work without requiring a person to approve every low-risk action.

The control is the validation rule and the audit trail.

Autonomous clinical action

An AI output changes a diagnosis, treatment plan, risk determination, medication decision, or other clinical conclusion without a human checkpoint. That is where you should draw a hard diligence boundary.

Behavioral health magnifies the risk because a 50-minute session contains tone, context, history, nonverbal observation, crisis language, medical-necessity evidence, and Part 2-sensitive information that a summarizer can flatten.

Ask the vendor:

• Can clinical review be turned off?
• Who has permission to change that setting?
• Is the configuration change logged?
• Which person approved each clinical output, and when?
• What happens to a draft nobody signs?
• Does the system surface uncertainty?
• What happens when confidence is low?
• Can a clinician reject the output, and is that rejection recorded?

Artifact to request: Ask for a sandbox walkthrough of the review and attestation workflow and the permission matrix showing who can bypass or modify each checkpoint.

Do not accept “we use a HIPAA-compliant cloud” as an answer. You need the actual data path. Start with five questions.

Where does inference occur?

Ask whether the model runs:

• Inside your organization’s environment
• Inside the EHR vendor’s tenant
• Inside a separate vendor-controlled tenant
• Through a third-party model API
• Across more than one of these environments

The answer determines which organizations receive patient information and which contracts need to cover them.

Is tenancy shared or dedicated?

A shared cloud environment can still be securely designed, but you need to understand logical separation, encryption boundaries, access controls, and whether any customer data can enter shared processing pipelines.

Which region processes the data?

Ask for the cloud region, backup region, disaster-recovery region, and any location used by subprocessors. If data can leave the United States, ask what contractual and technical controls govern the transfer.

Which third parties touch the request?

A vendor may present the EHR as a single product while relying on separate companies for:

• Speech recognition
• Foundation models
• Content moderation
• Logging
• Monitoring
• Cloud hosting
• Support

Ask for the complete subprocessor chain, including the model provider.

What happens when the model is unavailable?

Your architecture review should show the fallback behavior. Does documentation stop? Does the system queue processing? Can the clinician document manually? Does a failed AI request appear clearly to the user?

Artifact to request: Ask for the current architecture diagram and current subprocessor register.

A salesperson saying, “We run on a major cloud provider,” does not answer any of those questions.

Retention should never be one field on an AI security questionnaire. An ambient documentation workflow can create several distinct artifacts, each with its own risk profile. Ask for separate retention periods for:

• Raw audio
• Transcript
• Prompt
• Retrieved chart context
• Intermediate model output
• Final draft
• Error logs
• Prompt and response logs
• Audit records

A vendor may delete the raw audio immediately while retaining the transcript for 30 days. Another may retain prompt logs for debugging. A model provider may have a separate policy from the EHR vendor. Those differences matter.

Ask whether zero retention is contractual

“Zero retention available” is weaker than a written commitment stating which data are not retained, by whom, and under which configuration. Ask whether the setting can change without your approval. Then ask how the vendor proves the policy is actually being applied.

Ask who can review patient content

Vendor employees or contractors may sometimes access customer data for:

• Technical support
• Quality assurance
• Abuse monitoring
• Error investigation
• Model evaluation

You need to know whether that occurs, which roles have access, whether access is time-limited, and whether every access event is logged.

Ask how deletion works

“Deleted” can mean removed from the user interface while remaining in logs, backups, or another subprocessor environment. Ask:

• What initiates deletion?
• How long until deletion completes?
• Do backups expire separately?
• Can the vendor produce evidence of deletion?
• Does termination trigger deletion automatically?
• Which records must remain because of contractual or legal retention requirements?

Artifact to request: Ask for the formal retention schedule, deletion procedure, and sample evidence showing completion of a deletion request. You are buying a data lifecycle as much as an AI feature.

Is training opt-in or opt-out?

An opt-out buried in an administrator panel creates a different risk from a contract that prohibits training unless you affirmatively authorize it. Ask whether the setting applies to:

• Identifiable PHI
• De-identified information
• Derived features
• Clinician edits
• Feedback
• Prompt logs
• Usage analytics

Check the de-identification carve-out

This is where buyers often stop too early. Under HIPAA, information that has been properly de-identified under the Privacy Rule is no longer PHI and is no longer restricted by HIPAA in the same way. HHS recognizes Safe Harbor and Expert Determination as the two de-identification methods.^[5]

So a contract that promises “we never train on PHI” may still permit training on de-identified customer data. If your policy is that your patient data should not improve a general model, say that explicitly in the contract. Address de-identified and derived data, not only PHI.

Check the upstream model terms

Your EHR vendor may promise no training while its underlying model provider has separate terms. Ask whether the vendor has an enterprise agreement that controls model-provider retention and training behavior.

Artifact to request: Ask for the data-use terms covering both the vendor and every model subprocessor.

Before you shortlist a vendor: Run a data-flow and AI oversight review. Trace one behavioral health encounter from capture through inference, retention, review, finalization, and deletion. If the vendor cannot show each hop, you do not yet have enough information to approve the workflow.

A Business Associate Agreement is essential when the vendor is acting as a HIPAA business associate. It does not automatically resolve every Part 2 question.

The 2024 final rule preserves the qualified service organization framework and expressly describes QSO obligations as distinct from HIPAA BAA obligations. It also recognizes that a business associate serving a Part 2 program may meet the definition of a QSO.

The correct contract stack depends on who you are, whether the program is subject to Part 2, what the vendor does, and how records move. For an AI vendor touching Part 2 records, your legal and compliance review should determine whether you need:

• A HIPAA BAA
• A Qualified Service Organization Agreement
• Part 2-specific terms incorporated into another agreement
• Subprocessor flow-down obligations
• Specific data-use restrictions
• SUD counseling-note controls
• Patient-consent dependencies
• Include breach obligations

The Part 2 final rule applies the HIPAA Breach Notification Rule to breaches of Part 2 records. Your vendor terms should therefore define notification responsibilities, escalation paths, information required after an incident, and obligations that flow through subcontractors.

Include AI-specific oversight terms

Two additional terms belong in the same contract. First, require that AI-generated clinical content follow your approved human-attestation policy and prevent that safeguard from disappearing through an undocumented configuration change.

Second, define your exit path. If you replace the AI component, you need more than exported notes. Ask for:

• Workflow rules
• Configuration
• Audit history
• Approval and override records
• Retention status
• Model-version history
• Data exports in usable formats

Also require notification before material model changes, so your organization can revalidate workflows before a new version affects production.

For a broader contract review, see Behavioral health EHR contracts: 12 red-flag clauses to read before you sign.

Do not let the vendor choose the only transcript in the demonstration. Bring your own test material: properly de-identified transcripts, plus role-played or simulated session audio recorded specifically for testing. Real session audio is hard to de-identify because voice prints are one of the HIPAA identifiers. Sharing real recordings can also raise Part 2 and state consent issues. Have your privacy officer approve the test set before it goes to any vendor you have not yet contracted with.

Use a representative session and a deliberately difficult one. A meaningful behavioral health test set should include several conditions.

Test a real session length

Use a 50-minute encounter rather than a five-minute sample. Longer conversations test whether the system preserves context, recognizes topic changes, handles repeated themes, and keeps the clinically relevant material without turning the note into a transcript summary.

Test group therapy

Give the product a group session with multiple speakers. Check whether it:

• Separates participants correctly
• Avoids placing one member’s disclosure in another member’s draft
• Produces individualized content
• Preserves the common group intervention without copying identical patient responses

Test crisis language

Include a passing suicidality or self-harm statement. Watch what the system does. Does it flag the content for clinician attention? Does it bury the statement inside a summary? Does it overstate what the patient said? The product should route risk-relevant content to a qualified human rather than making the clinical risk call itself.

Test behavioral health vocabulary

Use DSM-5 terminology, medication names, SUD language, abbreviations, and psychotropic vocabulary that appear in your actual programs.

Test the environment your clinicians work in

Include:

• Accents
• Telehealth compression
• Interruptions
• Background noise
• Pediatric sessions
• Caregiver participation

Then run a separate oversight test. Feed the system an audio segment that is genuinely inaudible. See whether it marks the uncertainty or invents plausible language. Then check the draft for statements the clinician never made and ask what controls prevent that class of error, not merely how often the vendor says it occurs.

Edit the generated note during the demo and then ask the vendor to find your edit in the audit log. Finally, ask them to show you the sign-off screen. Output quality is only half the test. You also need to see how the product behaves when it is wrong.

An impressive note can still create an indefensible claim. Behavioral health billing depends on details that an AI draft cannot attest to on its own.

Time-based services require verified time

Psychotherapy codes can depend on documented session duration. An AI system can identify a scheduled time, calculate elapsed audio, or suggest a code. It cannot personally attest that the clinician delivered the service for the time represented in the record. You need to know where session time comes from and who verifies it.

The note must maintain the treatment-plan connection

Payers and auditors often look for continuity between:

• Diagnosed condition
• Treatment plan
• Intervention
• Patient response
• Progress
• Medical necessity

AI can draft that connection from available context. A clinician still has to determine whether the connection is true. If the generated language sounds clinically complete while misrepresenting the session, the polished prose increases risk rather than reducing it.

The edit trail matters

Your audit trail should distinguish:

1. What the AI originally proposed
2. What the clinician changed
3. Who approved the final content
4. When approval occurred

A final signed note alone proves that a note exists. An audit trail shows how AI-generated content became the clinician’s documentation. That distinction becomes important when a payer, auditor, licensing board, compliance team, or patient questions the record. Ask whether the audit history survives note amendments and whether administrators can retrieve it without engineering support.

For a deeper behavioral health billing example, see The top 5 CPT codes every behavioral health practice bills and how each one gets denied.

AI governance inside an EHR is a configurable rules layer that validates AI outputs against your organizational policies, payer requirements, state rules, program conditions, and clinical controls before an output is allowed to execute, and records what happened.

This is the procurement layer that matters more as model capabilities converge. A better language model may improve the draft. It does not define what your organization allows that draft to do.

Require validation before execution

For a clinical draft, the rule may require named clinician attestation. For an administrative action, the rule may permit execution when deterministic conditions are satisfied. For a risk signal, the rule may require escalation to a licensed professional. The governance layer should apply the rule before the action reaches the record, claim, patient, or downstream system.

Require configurable rules

Your organization should be able to change governance rules when:

• A payer changes policy
• A state adopts a new AI requirement
• A clinical program changes protocol
• Your compliance committee changes an approval threshold

If every policy change requires a vendor engineering sprint, the technology will lag the regulations you are trying to govern.

Require a per-action audit trail

For material AI actions, ask whether the audit record can capture:

• Input or source context
• AI suggestion
• Model/version
• Rule applied
• Validation result
• Human decision where required
• Override
• User identity
• Timestamp

Require model change management

A model update can change output behavior without changing your workflow screen. Require notification before material model changes and a process for revalidation. NIST’s Generative AI Profile emphasizes risk management across the AI lifecycle, while Joint Commission and CHAI guidance calls for governance, local validation, ongoing quality monitoring, risk assessment, and clear accountability.

Ask who owns monitoring on the vendor side and who owns it on yours. Then ask what happens when monitoring finds drift. You need an incident path, rollback capability, and a named accountable owner before that first incident occurs.

Your AI environment will probably contain more than one vendor.

You may have:

• EHR-native AI
• An ambient documentation tool
• A coding assistant
• A prior authorization agent
• A patient engagement bot
• An internal model built by your analytics team

Each one may arrive with its own privacy terms, logging format, model lifecycle, and definition of human review. If your governance framework applies only to AI supplied by the EHR vendor, every connected agent becomes a separate control environment. That is difficult to defend at scale.

Ask whether governance travels with the workflow

Your buyer questions should include:

• Do the same validation rules apply to third-party agents?
• Can a connected agent write into the EHR without passing through the governance layer?
• Can you bring an AI product you already own?
• Does that agent receive the same audit treatment?
• Can you restrict its data access independently?
• Can you require clinical attestation even when the third-party vendor does not?
• Can you disable one agent without disrupting the workflow around it?

Joint Commission and CHAI guidance specifically frames healthcare AI governance as an organization-wide responsibility covering third-party, internally developed, and AI-embedded tools.

The governance perimeter therefore belongs to the healthcare organization.

Ask what happens when the best model changes

Model quality is moving quickly. The model you prefer today may be surpassed in 18 months. Your procurement architecture should let you replace the intelligence while preserving:

• Workflow
• Rules
• Audit trail
• Data connections
• User experience
• Compliance controls

Otherwise model selection becomes a long-term system lock-in decision.

Artifact to request: Ask for governance documentation, a real audit-log sample, and the integration terms applied to third-party agents.

Then ask the vendor to show a connected agent passing through the same approval rule as a native one. That demonstration tells you more about the architecture than a catalog of AI features.

AI transparency has two layers: information the vendor can show you about the model, and controls your organization needs over what the model is allowed to do.

Predictive DSI source attributes can give you useful evidence

If an AI capability qualifies as a Predictive Decision Support Intervention supplied as part of certified health IT subject to the §170.315(b)(11) criterion, ASTP/ONC requires support for source attributes and related transparency capabilities.^[6]

Those source attributes can include information related to:

• Intervention purpose
• Inputs
• Intended users
• Training and validation
• Performance
• Fairness
• Ongoing monitoring
• Update practices

The requirement does not mean every generative AI feature in every EHR is automatically a Predictive DSI. Ask whether the specific tool you are evaluating falls within the criterion and, if so, request the available source-attribute information.

A risk score may tell you what the model predicts. Source attributes help you understand how that prediction was developed and evaluated. Your governance rule then determines what the score may trigger.

A suicidality or acuity score should route to a qualified human for clinical interpretation. It should not independently change a treatment plan.

State law needs per-state configuration

Behavioral health AI law is already developing along several regulatory patterns.

Clinical-use restriction models: Illinois, Nevada, and Colorado have enacted rules restricting or prohibiting specified AI uses in therapy or mental health care and preserving professional responsibility for clinical activity.^[7][8]

Disclosure and consent models: California requires disclosures for certain AI-generated patient clinical communications unless a licensed professional reviewed them, while Utah requires specific disclosures for mental health chatbots.^[9]

Broader AI governance and consumer-protection models: Colorado has enacted broader requirements for automated decision-making technologies used in consequential decisions, including health care decisions.^[10]

Your legal team should assess the law in each jurisdiction where patients receive services rather than configuring AI solely around the state where your corporate headquarters sits. That means your EHR should support per-state settings for consent, disclosure, feature availability, review requirements, and patient-facing workflows.

AI that sits outside the clinical workflow creates extra clicks, duplicate context, and another system to govern. Your technical review should determine whether the AI can operate inside the existing behavioral health workflow while preserving the controls your organization requires.

Start with interoperability

Ask which standards the vendor supports:

• FHIR
• HL7 v2
• SMART on FHIR where relevant
• APIs for third-party agent connections
• Webhooks or event-based workflows

Then ask which interfaces are standard product capabilities and which require custom development. Also ask whether the AI uses the EHR’s single sign-on and role-based permissions, and request the expected and maximum latency for transcription, note generation, and any action that writes back to the workflow.

Measure the clinician workflow

Ask the vendor to show exactly where review and approval occur. Count the clicks. If clinicians have to leave the EHR, open another application, find the patient again, review a draft, approve it, and return to the chart, the integration exists technically while the workflow remains fragmented.

Test failure behavior

Ask:

• What happens when the model provider is down?
• What happens when an API times out?
• Can the clinician continue documenting?
• How are failed actions surfaced?
• Are actions retried automatically?
• Can IT identify which component failed?
• Does a failure ever create a partial chart write?

Ask for a sandbox

Your IT and clinical informatics teams should be able to test:

• Model behavior
• Integration
• Permissions
• Audit logs
• Governance rules
• Error handling
• Third-party agent connections

before production use.

Confirm who can change the rules

Ask whether an authorized administrator can change validation and workflow rules without waiting for vendor development. Then ask whether those administrative changes are themselves logged. Finally, test openness.

Can you connect an AI tool from another vendor through the API layer and apply the same governance standard? If the answer is no, you are purchasing an AI stack whose future capabilities depend on one vendor’s roadmap. That may be acceptable for your organization, but it should be an explicit procurement choice.

Some diligence failures should move a vendor from “needs clarification” to “do not shortlist.”

Walk away when the data flow is hidden

Red flags include:

• No written subprocessor list
• No architecture diagram
• No clear answer about model-provider access
• Unclear processing regions
• Vendor staff access with no logging or controls

Walk away when retention cannot be contractually defined

Warning signs include a vendor that:

• Refuses to document zero-retention terms
• Cannot separate audio and transcript retention
• Cannot explain backup deletion
• Treats deletion as a support request with no completion evidence

Walk away when Part 2 is reduced to a BAA

A vendor serving SUD programs should be able to discuss its Part 2 role, QSO implications where applicable, subprocessor flow-down, breach handling, and consent-sensitive workflows. A generic “we sign a BAA” response is incomplete.

Walk away when accuracy has no method behind it

“95% accurate” means very little unless the vendor can explain:

• What was measured
• On which population
• Against which reference
• For which task
• Under which audio conditions
• How performance is monitored after deployment

Walk away when the demo is controlled too tightly

A vendor that refuses your de-identified transcript or will only show polished internal samples has not demonstrated performance in your environment.

Walk away when clinical output can silently become final

Clinical AI should have a defined review and attestation path. Ask whether it can be disabled, by whom, and whether the change is audited.

Walk away when governance stops at the vendor boundary

Other red flags include:

• No audit trail separating AI output from clinician revision
• No per-state configuration
• No model-change notification
• No override path
• Overrides that are not logged
• No accountable AI owner on the vendor side
• No monitoring for drift
• No rollback process
• No credible answer for replacing the AI component later

A buyer should be able to see the checkpoint, the rule, and the log. If the vendor can only show the output, you have seen the least important part of the system.