Does a telehealth platform need a BAA with its AI model provider?

Yes, when the model receives protected health information. A provider that processes PHI to generate a summary, a triage suggestion, or a clinical note performs a function on behalf of the covered entity, which makes it a business associate under HIPAA. The covered entity needs a business associate agreement with the telehealth vendor, and the vendor needs one with any model provider it routes PHI to. The Cloud Radix finding that 57% of healthcare professionals process PHI through unauthorized AI without a business associate agreement describes this exact gap. A signed BAA is the contractual floor. It does not, on its own, enforce the minimum necessary standard or produce the per-decision audit record, which is why the technical control at the prompt still matters.

Is de-identified data still a HIPAA concern in AI prompts?

It depends on whether the data actually meets the HIPAA de-identification standard. Data de-identified under the Safe Harbor method, with the eighteen identifier types removed, or under the Expert Determination method, is no longer PHI and falls outside HIPAA. The practical problem in telehealth AI is that prompts are rarely de-identified before they are sent. A scribing tool works from raw visit audio. A summary tool reads the full encounter note. The identifiers are present because the clinical task needs the context. Applying redaction at the prompt boundary is what moves a payload toward the de-identification standard, and it has to happen before the request reaches the model. Partial removal does not reach Safe Harbor, so the redaction policy has to specify which identifier types it targets and confirm the rest are handled.

Can a telehealth platform rely on its EHR vendor's HIPAA compliance for AI features?

Not for the AI call itself. An EHR vendor's HIPAA attestation covers how that vendor stores and transmits records inside its own environment. When the platform adds an AI feature that sends prompt content to an external model, that traffic often leaves the EHR's controlled path and goes straight to a model API. Vendor due diligence at procurement differs from ongoing supervision of how PHI is handled on every request. The covered entity keeps the obligation to know what data goes into each prompt, under what policy, and with what record. An attestation collected once at signing does not answer those questions for the request sent this afternoon. The supervisory duty runs continuously, and it applies to the specific data path the AI feature creates, which usually sits outside the EHR vendor's audited boundary.

Does network DLP or a CASB cover PHI going into AI prompts?

Only if it is configured to inspect the specific AI provider domains and parse the API payload, which most deployments have not set up. A telehealth prompt posted to a model endpoint travels inside a TLS session. Standard network DLP sees an encrypted connection to a known domain and cannot read the chief complaint or the medication list inside the request body. A CASB governs sanctioned cloud applications and can flag access to an AI service, though it inspects the connection rather than the clinical content of the prompt. Reading prompt content requires terminating TLS for those endpoints and classifying the parsed payload against PHI rules. That is a different control point from the perimeter DLP stack, and it has to sit inline on the AI request path. The prompt is the data channel legacy DLP and CASB were never built to inspect.

What does the Security Rule's audit controls standard require for AI calls?

The audit controls standard at 45 CFR 164.312(b) requires hardware, software, or procedural mechanisms that record and examine activity in systems containing electronic PHI. Applied to a telehealth AI feature, the activity is the model call that carries ePHI in its prompt. A record that satisfies the standard identifies who initiated the request, what data classification applied, what policy governed the decision, and what the outcome was. An application log that records "summary generated" does not meet that bar, because it omits identity, classification, and policy state, and because the system writing the log is the same system under review. IBM's breach research puts the added cost of shadow AI breaches at $670,000 above the average. An independent per-decision record is what closes that evidentiary gap.

How does PHI redaction work without breaking the AI feature?

Redaction at the prompt boundary replaces identifier tokens with placeholders before the request reaches the model, then restores them in the response where the workflow needs them. A scribing tool can send "the patient" in place of the name and the medical record number and still produce a usable note, because the clinical reasoning works from the context rather than the identifier. Redaction is applied per field against a policy, so the platform controls which identifier types leave and which are masked. The goal is to send the minimum PHI the task requires and no more, which is the operational form of the minimum necessary standard. Feature quality holds because the model still receives the clinical narrative. What it stops receiving is the direct identifiers that the summary, triage, or scribe function never needed.

← Blog

July 19, 2026

Telehealth AI and HIPAA Compliance

Telehealth platforms are wiring AI into visit summaries, triage, and scribing, which pushes PHI into LLM prompts that network DLP cannot read. This walks through the HIPAA obligations at the AI call boundary and the identity-aware policy and per-decision records that satisfy them.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

Industry Verticalshipaaai-compliancecomplianceregulationai-governanceaudit

A telehealth platform that adds an AI visit-summary feature takes the patient's symptoms, medication list, and working diagnosis and sends them to a model API as an HTTPS POST. That payload is protected health information from the moment the clinician clicks generate. Cloud Radix reports that 57% of healthcare professionals already use unauthorized AI to process PHI, including SOAP notes and diagnostic plans, without a business associate agreement in place. The HIPAA obligations attach to that single request, and network data-loss prevention stays blind to what the prompt contains.

Visit summaries, AI triage, and clinical scribing follow the same data path. Each one lifts PHI out of the medical record and drops it into a prompt bound for a third-party model.

I want to walk through the HIPAA obligations that attach when a telehealth feature sends PHI to a model, why network DLP is blind to the content of that request, and the enforcement pattern that closes the gap at the model call boundary. I covered the general case in AI and HIPAA compliance. This piece is the telehealth-specific reading.

Three HIPAA rules apply the moment PHI enters a telehealth prompt

Three telehealth AI features are moving into production this year: visit-summary generation, AI triage, and clinical scribing. Each one reads clinical content and sends it to a hosted model. The summary tool posts the encounter note. Triage sends the chief complaint along with the relevant history. A scribe streams the full visit transcript. When the platform calls OpenAI, Anthropic, or a model on Amazon Bedrock, that content leaves as the body of an HTTPS POST to the provider's API. HIPAA's Privacy and Security Rules, enforced by the HHS Office for Civil Rights, apply to that request with no exception. Three requirements land on it directly.

Business associate coverage extends to AI sub-processors

A model provider that receives PHI to generate a summary is a business associate under HIPAA, and the prompt content is a disclosure of PHI to that provider. The covered entity needs a business associate agreement with the telehealth vendor, and that vendor needs one with the model provider it calls. The HITECH Act of 2009 made business associates directly liable, and the 2013 Omnibus Rule extended that liability to subcontractors. Some providers offer a BAA on specific enterprise tiers, and the default consumer endpoints often lack one. A platform that routes prompts to a model with no BAA covering that provider has an unbroken chain of PHI disclosure and a broken chain of contracts.

The minimum necessary standard applies to prompt content

The minimum necessary standard at 45 CFR 164.502(b) requires a covered entity to limit PHI to the minimum needed for the purpose. A scribing prompt that ships an entire patient history to summarize a fifteen-minute visit carries more PHI than the task requires. Minimum necessary has to be enforced on the prompt payload itself, field by field, before the request leaves the platform, because document-level controls stop at the point the data is copied into a prompt.

The Security Rule requires audit controls over ePHI

The Security Rule's audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that contain or use electronic PHI. When a clinician's prompt becomes an API call to a model, that call is activity involving ePHI, and the audit obligation covers it. A telehealth stack that logs "summary generated" at the application level records that something happened, without the identity, the data classification, or the policy that governed the specific request.

Network DLP cannot read the prompt inside an HTTPS POST

Healthcare security teams already run data-loss prevention on email, file shares, and web uploads. That control stops short of the AI prompt. When the telehealth application posts the request to api.openai.com or a Bedrock endpoint, the payload is wrapped in TLS. Network DLP sees an encrypted session to a known domain. It cannot read the chief complaint, the medication list, or the medical record number inside the body, unless TLS inspection is configured for that specific provider domain and the API payload is parsed and classified.

The concentration of regulated data shows up in the breach numbers. IBM's Cost of a Data Breach research found that customer PII exposure reached 65% in shadow AI breaches, compared to 53% across all breaches. The prompt is where PHI now collects, and it is the one layer the legacy DLP stack was never built to inspect.

Application-controlled logs fail the audit controls test

The audit controls standard expects records an auditor can rely on. When the telehealth application that generates the AI summary also writes the log of that event, the system under review is producing its own evidence. That arrangement carries three failure modes. The application can record the requests that succeed and skip the edge cases that fail. The log can be altered or truncated by the same code that produced it. The application can crash after the model responds but before the log commits, so the action happened and the record is gone.

Detection lag makes the gap worse. IBM found that shadow AI breaches take 247 days to detect, six days longer than standard breaches. A per-decision audit record written by a layer independent of the application is what the audit controls standard at 45 CFR 164.312(b) actually calls for.

Identity-aware policy and redaction satisfy all three rules at once

The three obligations converge on a single point: the moment the prompt leaves the platform for the model. An enforcement layer positioned there does three things on every request. First, it binds the request to the identity of the clinician or agent making it, so the audit record names the natural person rather than a shared service credential. Second, it classifies the prompt content and applies PHI redaction or a block, which enforces the minimum necessary standard on the payload before it reaches the model. Third, it commits the decision to an independent store, so the audit controls requirement is met by a system the telehealth application cannot edit.

One control point at the AI call boundary covers business associate scope, minimum necessary, and audit controls together. The pattern is identity-aware policy on the request, redaction on the content, and a decision record the application does not own.

Beyond HIPAA

HIPAA is one of several regimes reaching telehealth AI. A platform serving patients in the European Union also falls under the EU AI Act, where health and triage uses can be classified high-risk. Article 12 requires the automatic recording of events over the lifetime of the system, effective August 2, 2026. I covered the sector reading in the EU AI Act for healthcare breakdown.

State law adds more. The Texas Responsible AI Governance Act took effect January 1, 2026, with civil penalties and enforcement by the state attorney general. The California AI Transparency Act, effective the same day, mandates disclosure for AI systems above one million monthly users. Each regime uses its own language. All of them ask for the same three things at the telehealth AI boundary: a verified identity on the request, a policy decision on the content, and an independent record of what happened. The architecture that satisfies HIPAA satisfies them together.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless proxy between your authenticated users or agents and any LLM the telehealth platform calls, whether that endpoint is OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, or a self-hosted model. For every request, it evaluates the identity the application supplies, the role that identity holds, and the classification of the data in the prompt, then applies redaction or a block before the traffic reaches the model.

Every decision produces a per-decision audit record containing the identity, the role, the policy version, the data sensitivity, the outcome, and a timestamp. The record is signed and tamper-evident, and it commits before the model response returns to the application, which is the independence the Security Rule's audit controls standard expects. DeepInspect is model-agnostic and does not depend on the model refusing anything.

If your telehealth platform is adding visit summaries, triage, or scribing, and your HIPAA posture rests on logs the application controls, that posture is incomplete. DeepInspect adds the deterministic, identity-bound, externally auditable layer at the point where PHI enters an AI prompt. Book a demo today.

Frequently asked questions

Does a telehealth platform need a BAA with its AI model provider?: Yes, when the model receives protected health information. A provider that processes PHI to generate a summary, a triage suggestion, or a clinical note performs a function on behalf of the covered entity, which makes it a business associate under HIPAA. The covered entity needs a business associate agreement with the telehealth vendor, and the vendor needs one with any model provider it routes PHI to. The Cloud Radix finding that 57% of healthcare professionals process PHI through unauthorized AI without a business associate agreement describes this exact gap. A signed BAA is the contractual floor. It does not, on its own, enforce the minimum necessary standard or produce the per-decision audit record, which is why the technical control at the prompt still matters.
Is de-identified data still a HIPAA concern in AI prompts?: It depends on whether the data actually meets the HIPAA de-identification standard. Data de-identified under the Safe Harbor method, with the eighteen identifier types removed, or under the Expert Determination method, is no longer PHI and falls outside HIPAA. The practical problem in telehealth AI is that prompts are rarely de-identified before they are sent. A scribing tool works from raw visit audio. A summary tool reads the full encounter note. The identifiers are present because the clinical task needs the context. Applying redaction at the prompt boundary is what moves a payload toward the de-identification standard, and it has to happen before the request reaches the model. Partial removal does not reach Safe Harbor, so the redaction policy has to specify which identifier types it targets and confirm the rest are handled.
Can a telehealth platform rely on its EHR vendor's HIPAA compliance for AI features?: Not for the AI call itself. An EHR vendor's HIPAA attestation covers how that vendor stores and transmits records inside its own environment. When the platform adds an AI feature that sends prompt content to an external model, that traffic often leaves the EHR's controlled path and goes straight to a model API. Vendor due diligence at procurement differs from ongoing supervision of how PHI is handled on every request. The covered entity keeps the obligation to know what data goes into each prompt, under what policy, and with what record. An attestation collected once at signing does not answer those questions for the request sent this afternoon. The supervisory duty runs continuously, and it applies to the specific data path the AI feature creates, which usually sits outside the EHR vendor's audited boundary.
Does network DLP or a CASB cover PHI going into AI prompts?: Only if it is configured to inspect the specific AI provider domains and parse the API payload, which most deployments have not set up. A telehealth prompt posted to a model endpoint travels inside a TLS session. Standard network DLP sees an encrypted connection to a known domain and cannot read the chief complaint or the medication list inside the request body. A CASB governs sanctioned cloud applications and can flag access to an AI service, though it inspects the connection rather than the clinical content of the prompt. Reading prompt content requires terminating TLS for those endpoints and classifying the parsed payload against PHI rules. That is a different control point from the perimeter DLP stack, and it has to sit inline on the AI request path. The prompt is the data channel legacy DLP and CASB were never built to inspect.
What does the Security Rule's audit controls standard require for AI calls?: The audit controls standard at 45 CFR 164.312(b) requires hardware, software, or procedural mechanisms that record and examine activity in systems containing electronic PHI. Applied to a telehealth AI feature, the activity is the model call that carries ePHI in its prompt. A record that satisfies the standard identifies who initiated the request, what data classification applied, what policy governed the decision, and what the outcome was. An application log that records "summary generated" does not meet that bar, because it omits identity, classification, and policy state, and because the system writing the log is the same system under review. IBM's breach research puts the added cost of shadow AI breaches at $670,000 above the average. An independent per-decision record is what closes that evidentiary gap.
How does PHI redaction work without breaking the AI feature?: Redaction at the prompt boundary replaces identifier tokens with placeholders before the request reaches the model, then restores them in the response where the workflow needs them. A scribing tool can send "the patient" in place of the name and the medical record number and still produce a usable note, because the clinical reasoning works from the context rather than the identifier. Redaction is applied per field against a policy, so the platform controls which identifier types leave and which are masked. The goal is to send the minimum PHI the task requires and no more, which is the operational form of the minimum necessary standard. Feature quality holds because the model still receives the clinical narrative. What it stops receiving is the direct identifiers that the summary, triage, or scribe function never needed.

← All posts