Telehealth Note Generation and the Hidden BAA Problem

Telehealth Note Generation and the Hidden BAA Problem

AI scribe products have flooded the telehealth market over the past two years. Ambient listening, real-time transcription, automatic SOAP note generation. The pitch is compelling: clinicians save 15 to 20 minutes per encounter, documentation quality goes up, burnout goes down. Vendors uniformly claim HIPAA compliance. And most of them are telling you a version of the truth that leaves out the part that actually matters.

The problem is not whether the scribe vendor will sign a Business Associate Agreement with you. They almost certainly will. The problem is what happens to the audio and text data after it leaves their front-end application.

How AI Scribe Pipelines Actually Work

A typical AI scribe product involves at least three, and sometimes five or six, distinct processing steps. Audio capture happens on a device or browser. That audio gets transmitted to a speech-to-text engine. The resulting transcript feeds into a large language model for clinical summarization. The summary may pass through a medical coding layer. Then the structured note gets pushed back to the EHR via an integration layer.

Each of those steps may involve a different company. The scribe vendor might use Google Cloud's Speech-to-Text API, OpenAI's GPT-4 for summarization, a third-party NLP service for ICD-10 coding, and a Redox or Health Gorilla integration for EHR delivery. Every one of those entities is a business associate or subcontractor under HIPAA if it touches, stores, processes, or transmits PHI. Under 45 CFR 164.502(e) and 164.504(e), covered entities need assurance that BAAs extend through the entire chain. The scribe vendor's BAA with you is necessary but not sufficient.

The Subcontractor Gap

The HIPAA Omnibus Rule of 2013 made this explicit. Business associates are directly liable for compliance, and they are required to have written agreements with any subcontractors who handle PHI on their behalf. So in theory, the chain should be covered. In practice, it often is not.

Here is what we keep seeing when we look under the hood of AI scribe architectures:

• The LLM provider has no BAA in place. OpenAI offers a BAA for its API products, but only under specific enterprise agreements. Many scribe vendors built their MVP on standard API tiers that did not include BAA coverage and never upgraded. Anthropic's Claude API has a similar structure; BAA availability depends on the contract tier.
• Audio data transits through a non-covered transcription service. Some vendors use consumer-grade speech-to-text APIs where the provider's terms of service explicitly disclaim HIPAA obligations.
• Temporary storage falls outside the BAA scope. Even when BAAs exist at each layer, they sometimes exclude transient data. Audio buffers, intermediate transcripts, and cached model outputs may sit in infrastructure that the BAA does not contemplate.
• The BAA does not address model training. This is a big one. If any entity in the chain uses patient encounter data to fine-tune or improve models, that is a use of PHI that needs to be authorized. Many LLM provider terms reserve the right to use API inputs for model improvement unless you specifically opt out, and opting out is sometimes only available at higher pricing tiers.

OCR has not yet brought an enforcement action specifically targeting AI scribe subcontractor chains, but the precedent is well established. In 2016, OCR settled with North Memorial Health Care for $1.55 million in part because a business associate lacked a proper BAA. The Advocate Medical Group settlement in 2016 ($5.55 million) also involved downstream data handling failures. The theory of liability is not new; the technology stack is just more fragmented now.

What to Actually Ask Your AI Scribe Vendor

If you are evaluating or already using an AI scribe product, here is a practical checklist. These are not gotcha questions. They are the minimum you need to confirm that your BAA coverage does not have a gap in the middle of the processing pipeline.

• Request the complete list of subcontractors who touch PHI at any point in the pipeline. Not just "our cloud provider." Every entity that processes audio, text, or structured data derived from a patient encounter.
• Ask for confirmation that a BAA or subcontractor agreement under 45 CFR 164.504(e) is in place with each one. Ask to see them, or at minimum get a signed attestation naming each subcontractor.
• Confirm that no entity in the chain uses PHI for model training, product improvement, or any secondary purpose. Get this in writing. If the vendor says "we opt out of model training with our LLM provider," ask for documentation of that opt-out.
• Ask where audio and transcript data are stored, for how long, and in what form. Transient processing buffers count. If audio is held in memory on a server for 30 seconds during transcription, that server's operator needs to be covered.
• Verify that the BAA chain addresses breach notification obligations at every layer. Under the Omnibus Rule, subcontractors must report breaches to the business associate, who reports to you. If one link in the chain has no notification obligation, you may not learn about a breach within the 60-day window required by 45 CFR 164.404.
• Ask about data residency. If any processing occurs outside the United States, that does not automatically violate HIPAA, but it introduces complexity around enforcement and jurisdiction that your risk assessment should address.
• Check whether the vendor's architecture changes when they update their AI models. A vendor might have had a clean subcontractor chain six months ago and then switched LLM providers without updating their BAA structure. Ask whether you will be notified of material changes to the processing pipeline.

A Note on "HIPAA Compliant" Marketing

There is no HIPAA certification. When a vendor says they are "HIPAA compliant," they are making a self-assessment. SOC 2 Type II and HITRUST certifications are useful signals, but they audit the vendor's own environment. They do not guarantee that every subcontractor in a multi-vendor AI pipeline meets the same standard. A SOC 2 report from the scribe vendor tells you nothing about the security posture of the LLM provider they call via API.

This is not a reason to avoid AI scribe tools. The productivity gains are real, and clinician burnout is a serious operational and patient safety issue. But the procurement process needs to account for the actual architecture of these products, not just the marketing layer on top.

How FirmAdapt Addresses This

FirmAdapt was built specifically for regulated environments where AI processing chains create compliance exposure. For healthcare organizations deploying AI tools, FirmAdapt's architecture keeps PHI within a controlled processing environment where every component is covered by enforceable agreements and auditable data flows. There is no ambiguity about which entities touch patient data, because the platform is designed to eliminate the subcontractor gaps described above.

FirmAdapt also provides continuous monitoring of your AI vendor relationships, flagging when changes in a vendor's infrastructure or terms of service could affect your BAA coverage. If you are already using AI scribe products or evaluating them, FirmAdapt can map the actual data flow against your existing BAA chain and identify gaps before OCR does.