What makes chat HIPAA compliant?
A transcript that joins identity to health content is protected health information, so the chat vendor processing it is a business associate: the baseline is a BAA, access controls on who can read conversations, retention limits, and encryption. But chat has a property forms do not: the widget is also a tracker. It loads on every page, typically reporting pageviews and setting identifiers for visitors who never open it. A chat product is two data flows - the conversation and the telemetry - and both need evaluating.
By chat type
| Type | The exposure | What to require |
|---|---|---|
| Live chat | Free-text symptoms and identity, read by agents | BAA, role-based access, agent training, transcript retention limits |
| Scripted bots | Structured answers - still health information when identity is present | BAA, plus flow design that collects no more than routing needs |
| AI assistants | Prompts forwarded to model providers - a chain of processors | BAA coverage down the chain, including the model API; contractual bar on training with the data |
| SMS handoff | Content and metadata move to carrier-grade channels | Deliberate platform choice and policy; assume ordinary SMS is not a covered channel |
| Social messenger widgets | The conversation is held by a social platform | Generally no BAA path - keep them off clinical and service-line contexts |
The widget tracks visitors who never chat
Before a single message is sent, most chat widgets have already loaded on every template, recorded the pages a visitor viewed, and set an identifier to greet them by history if they ever do open the window. On a provider site, that is condition-page browsing telemetry flowing to the chat vendor sitewide - the exposure exists at deploy time, not at first conversation. Evaluate the widget as a tracker first and a conversation tool second, and confine it to the templates where conversations belong.
The AI chatbot question
An AI assistant adds recipients that traditional chat never had: the model API processing every prompt, retrieval stores holding indexed content, and logging layers on each. A visitor describing symptoms is now describing them to a processing chain, and the BAA question applies to each link - including subprocessors. Vendor positions on BAAs, data retention, and training use vary widely and change quickly; treat any specific vendor's status as unverified until you have read the current agreement, and have the subprocessor list in hand when you do.
Where transcripts travel
The conversation's afterlife is the real audit surface. Transcripts sync into CRMs - carrying free-text health detail into a system designed for marketing fields. Chat events land in analytics ("chat started" on an oncology URL is a disclosure with no transcript attached). Agent notifications copy conversations into inboxes. Each destination is a recipient with its own coverage status, and each was probably switched on by a checkbox during setup.
Working rule: map the transcript's full itinerary before judging the chat vendor. In audits, the vendor is usually the most defensible stop on the route.