What happens when your AI therapy scribe vendor is breached: HIPAA breach notification, mental health data, and the on-device alternative

The upstream breach problem for cloud AI scribes

On February 21, 2024, Change Healthcare — a unit of UnitedHealth Group that processes roughly 40 percent of US medical claims transactions — was taken offline by a ransomware attack. The breach affected protected health information held by Change Healthcare on behalf of thousands of covered entities: hospitals, physician practices, dental offices, pharmacies, and others that routed transactions through Change Healthcare's clearinghouse services. None of those covered entities had been breached themselves. Their own records were intact. But their business associate had been compromised, and the PHI Change Healthcare held on their behalf was within the scope of the breach.

The result was a cascade of HIPAA breach notification obligations running through the business associate relationship: Change Healthcare notified covered entities; covered entities were required to identify which of their clients' PHI had been affected, notify those individuals, notify HHS, and in states with large affected populations notify prominent media outlets. The breach at one vendor created millions of individual notification obligations for entities that had never made a documentation error or security misstep of their own.

This upstream breach dynamic is precisely the risk that cloud AI therapy scribe vendors create for covered entity therapists. A cloud AI scribe vendor is a business associate under HIPAA. When you use one, the vendor signs a BAA, receives session audio, processes it, and retains audio files, transcripts, and AI-generated note drafts under the vendor's own data retention policies. If the vendor's infrastructure is compromised — through ransomware, external intrusion, an insider threat, or supply chain attack against the vendor's own software dependencies — the session content the vendor holds from your practice is within the scope of the breach. The notification cascade follows the same path it followed after Change Healthcare.

The HIPAA Breach Notification Rule: the three-stage pipeline

The HIPAA Breach Notification Rule (45 CFR §§ 164.400–414) establishes a three-stage notification pipeline for breaches involving business associates.

Stage one: vendor notifies covered entity. Under 45 CFR § 164.410(b), a business associate must notify the covered entity of a breach "without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach." The notification must include, to the extent possible: identification of each individual whose PHI was accessed, a description of what happened and when, the types of PHI involved, recommended protective steps for affected individuals, what the vendor is doing to investigate and mitigate, and contact information for the vendor's breach response team. In large-scale breaches — where the vendor processes PHI for thousands of covered entity customers — this notification may arrive weeks after the breach was discovered internally, and may initially describe the affected population in aggregate terms rather than client-by-client.

Stage two: covered entity notifies individuals. Under 45 CFR § 164.404, the covered entity must notify each affected individual "without unreasonable delay and in no case later than 60 calendar days" after discovering the breach. For vendor breaches, discovery typically occurs when the vendor's stage-one notification arrives — but the covered entity's obligation to act "without unreasonable delay" applies from the moment of discovery, not just at the 60-day deadline. Written notification by first-class mail to the individual's last known address is the default; email is permissible if the individual previously authorized it.

Stage three: covered entity notifies HHS and, for large breaches, media. Under 45 CFR § 164.406 and § 164.408, the covered entity must notify HHS of each breach — for breaches affecting 500 or more individuals, contemporaneously with individual notifications; for smaller breaches, in an annual log submitted within 60 days after the calendar year ends. For breaches affecting 500 or more individuals in a single state or jurisdiction, the covered entity must also provide "prominent media outlets serving" that state with notification. For a solo therapist in private practice, the 500-individual media threshold may seem remote — but it applies to the individual practice's total affected client count for the calendar year, not to the vendor's aggregate.

Why mental health data makes the harm analysis especially difficult

The HIPAA Breach Notification Rule contains a risk-assessment exception: if the covered entity can demonstrate a "low probability that the protected health information has been compromised" based on a four-factor assessment, the presumption of breach is rebutted and individual notification is not required. The four factors are: (1) the nature and extent of the PHI involved, including types of identifiers and the likelihood of re-identification; (2) who accessed the PHI or to whom it was disclosed; (3) whether the PHI was actually acquired or viewed; and (4) the extent to which the risk has been mitigated.

For mental health session content, satisfying the low-probability exception is substantially harder than for most categories of administrative health data. Consider what a typical cloud AI scribe retains from a therapy session:

• Session audio containing the client's verbatim disclosures about mental health diagnoses, trauma history, relationship conflicts, substance use, suicidal ideation, and other content shared in the confidence of the therapeutic relationship
• Processing transcripts converting those verbal disclosures into text accessible to any system that can read the vendor's files
• AI-generated note drafts keyed to session identifiers, often associating the client's name, session date, and diagnostic formulation with structured clinical content
• Session metadata: timestamps, session duration, session dates, device identifiers, and potentially client demographic fields used in note generation

The specific harms from unauthorized access to this content are concrete and well-catalogued. Employment discrimination based on mental health status remains pervasive — employers conducting informal background screening, professional licensing boards weighing mental health history, and security clearance adjudicators all use mental health treatment history adversarially. Child custody proceedings routinely involve requests for therapy records. Life insurance, disability insurance, and long-term care insurance underwriting routinely disqualifies applicants with mental health diagnoses and treatment histories. And for clients who are domestic violence survivors, stalking victims, or individuals whose session disclosures could identify their location or safety planning, unauthorized access to session content creates direct physical safety risks.

Given these specific and concrete harms, it is extremely difficult for a covered entity to demonstrate a low probability that a breach of therapy session content compromised PHI in a meaningful way. The third factor in the harm analysis — whether the PHI was actually acquired or viewed — requires the covered entity to affirmatively show that the attacker did not access specific files. In most ransomware attacks and many intrusion incidents, attackers do exfiltrate data before encrypting, and forensic determination of what was actually accessed often cannot be completed within the 60-day notification window. The fourth factor — extent of risk mitigation — requires showing that the risk has been reduced. Encryption at rest, which most cloud vendors implement, satisfies the "unsecured PHI" threshold for some breach types, but data exfiltrated before encryption is applied or accessed via authorized credentials is not protected by encryption-at-rest.

The vendor notification gap: what vendors often cannot tell you

When a cloud AI scribe vendor is breached, the covered entity's ability to perform a meaningful harm assessment for specific clients — and potentially avoid notifying some of them — depends entirely on what the vendor can characterize about the breach's scope. Vendors are contractually required under the BAA to notify covered entities and to provide specific information about what was accessed. In practice, breach forensics at scale are slow and frequently inconclusive.

The Change Healthcare breach response illustrates the timeline gap directly. UnitedHealth Group began sending individual notifications months after the initial February 2024 breach. Many covered entities were unable to accurately identify which patients were affected or which specific transaction records were involved. Forensic determination of exactly which data was accessed, in what form, and by whom extended far beyond the regulatory timelines that governed notification obligations.

For cloud AI scribe vendors — which may retain audio files organized by session identifier, timestamp, and device ID but without always maintaining an explicit client-name-to-file mapping that supports rapid enumeration — the question "whose sessions were accessed?" may be structurally difficult to answer from server logs. If the vendor's audit logging recorded only that a storage bucket or database table was accessed during a given window, without recording which individual files were read, the covered entity has no basis for a client-specific harm assessment.

This creates what practitioners and OCR enforcement staff sometimes call the wall-of-uncertainty problem: the covered entity cannot rule out that any specific client's PHI was accessed, and therefore cannot affirmatively demonstrate low probability of harm for any individual. When this happens, the presumption of breach effectively applies to every client whose sessions were processed by the vendor during the breach window — which for a therapist using the same cloud scribe across three years of practice may mean several hundred current and former clients, each requiring a separate notification letter, individually addressed and mailed.

State law layers on top of HIPAA

HIPAA breach notification establishes a federal floor. Several states impose requirements that are stricter, and that layer on top of HIPAA when clients in those states are affected.

California. The California Confidentiality of Medical Information Act (CMIA, Civil Code § 56.10 et seq.) and California's broader data breach notification statute (Civil Code § 1798.82) require notification without unreasonable delay and by no later than 45 days after discovery for breaches involving California residents' medical information — shorter than the federal 60-day window. California also permits per-violation civil penalties for unauthorized disclosure of medical information, and the California Attorney General may bring enforcement actions on behalf of affected individuals.

Texas. The Texas Medical Records Privacy Act (Health & Safety Code § 181.001 et seq.) applies to covered entities and their business associates handling Texans' protected health information, with definitions that are broader in some respects than federal HIPAA. The breach notification provisions under § 181.154 provide for enforcement by the Texas AG with civil penalties up to $25,000 per violation per day for knowing violations, and up to $250,000 per violation per day for intentional violations.

New York. The New York SHIELD Act (General Business Law § 899-aa) requires entities holding New York residents' private information — including health information — to maintain reasonable security and to provide prompt notification following a breach. New York also has sector-specific mental health confidentiality requirements under the New York Mental Hygiene Law that apply to certain mental health records independently of HIPAA.

Washington. Washington's My Health MY Data Act (effective March 2024) creates a private right of action for Washington residents for certain health data breaches, covering "consumer health data" that includes mental health conditions and treatment — and covers some entities that are not HIPAA covered entities at the federal level.

For therapists whose client base spans multiple states — a common pattern in teletherapy practices and for therapists licensed under the PSYPACT compact — a single vendor breach may trigger overlapping notification obligations from several state frameworks simultaneously, each with its own timeline, content requirements, and enforcement mechanism. The strictest applicable deadline governs the practical notification window for the entire batch of affected clients in that state.

The notification letter and secondary disclosure

The HIPAA breach notification letter itself creates a secondary disclosure problem specific to mental health practices. The required content under 45 CFR § 164.404(c) — a description of what happened and what types of PHI were involved — requires the covered entity to state, in a written communication typically sent by first-class mail, that the recipient's mental health records were involved in a data breach.

For many therapy clients, this letter arriving at their home address discloses their status as a mental health treatment recipient to anyone who handles their mail: a partner, a parent, a housemate. The required notification may itself constitute a secondary disclosure of sensitive information the client never intended to share with their household. This is a direct consequence of HIPAA's built-in tension between the right of individuals to be notified about breaches of their health information and the privacy interest in not having that notification delivered in ways that expose the treatment relationship to third parties.

Email notification is permissible when the individual has provided a valid email address and has not requested paper communications. For many practices, email is the less-exposing channel for mental health breach notification — a message to the client's personal email is less likely to be seen by household members than an envelope addressed with a healthcare provider's return address. But not every client has a current email address on file, and some clients specifically prefer paper communications for their own privacy reasons.

The notification letter problem cannot be solved by careful drafting. The minimum required content of a HIPAA breach notification letter unavoidably identifies the recipient as a healthcare patient and describes the nature of the PHI involved. As the limits of business associate agreements make clear, the BAA cannot prevent a vendor breach, cannot limit the covered entity's downstream notification obligations, and cannot resolve the secondary disclosure problem that arises when those notifications must be sent.

On-device processing: eliminating the vendor archive

On-device processing eliminates the vendor-side breach risk at the architectural level by preventing the vendor archive from existing. If session audio, processing transcripts, and AI-generated note drafts are processed entirely on the therapist's Mac and never transmitted to external vendor infrastructure, there is no third-party archive to be breached. The HIPAA Breach Notification Rule creates obligations in response to breaches of PHI held by covered entities and their business associates — but if the business associate never receives the PHI, a compromise of the vendor's infrastructure cannot involve the covered entity's clients' session content.

This eliminates, structurally:

• The 60-day business associate breach notification obligation — the vendor has no PHI to breach
• The covered entity's downstream individual notification obligation — no breach of client PHI occurred at the vendor
• The HHS notification and media notification obligations that apply to large-scale breaches
• The state-law notification obligations stacked on top of HIPAA for clients in California, Texas, New York, Washington, and other states with stricter health data breach frameworks
• The wall-of-uncertainty problem — there is no opaque vendor log, because there is no vendor archive
• The secondary disclosure problem — there are no breach notification letters to send

The therapist's own device security obligations remain in place. HIPAA compliance for private practice in 2026 covers the covered entity's own security requirements: encrypted storage for session files, secure backup with access controls, device lock and multifactor authentication, and documented retention and destruction policies. A breach of the therapist's own device — if the Mac is stolen and the disk is not encrypted — could still constitute a breach of unsecured PHI. But that device-level breach risk is of a fundamentally different scale than the vendor-level breach risk. A stolen unencrypted laptop is a breach affecting the clients whose sessions were on that device. A breached cloud vendor with 50,000 therapist customers is a breach potentially affecting millions of clients — each of whom requires a separate notification letter from their individual therapist.

What cloud AI scribes actually transmit to vendor servers is not just a data flow question — it is a breach surface question. The data that never leaves the device has zero vendor breach surface. A subpoena directed at the vendor reaches nothing if the vendor holds nothing. The architectural principle — "HIPAA by architecture, not by contract" — applies to breach risk precisely as it applies to subpoena risk: a contract (the BAA) cannot prevent a vendor breach; an architecture that creates no vendor archive eliminates the risk that the contract was meant to manage.

Frequently asked questions