Healthcare Chatbots

Four Questions That Decide Whether You Can Deploy One, and the Tier Where the Answer Starts Costing Money

Quick answer: Almost every healthcare chatbot guide opens with use cases. That is the wrong end. Four questions decide the project, in order, and the first one you can answer in a minute. Does HIPAA reach you at all? If it does, the second question is whether the bot will touch protected health information, and the answer is usually yes even when the bot never discusses a condition, because OCR's own list of business associate examples includes an AI chatbot doing "symptom assessment, medical reminders, and appointment scheduling" on a patient portal. The third question follows immediately: will your platform sign a Business Associate Agreement, and on which tier? Across our fifteen published reviews, exactly one names a BAA on a named tier in a vendor document. Four platforms put HIPAA on a named tier, and in three of them that tier is custom-priced. The fourth, Intercom, states HIPAA on published per-seat tiers and our own review can only call the BAA "likely in Expert tier," which is a published price attached to an unverified contract. No published tier anywhere in the set carries a vendor-written BAA. The fourth question is the one that saves projects: what can you ship that genuinely never touches PHI, and how would you prove it rather than assume it?

Question one: does HIPAA reach you?

HIPAA runs to a defined set of parties and not to everyone holding health information. Covered entities are health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with a covered transaction such as a claim. Business associates are the vendors those entities engage to handle protected health information on their behalf, and a business associate's own subcontractors are business associates too.

A dental practice, a physiotherapy clinic, a mental health group practice billing insurance electronically: covered entities. The scheduling vendor, the transcription service and the chatbot platform they engage: business associates. A supplement retailer, a fitness app, a consumer symptom checker sold direct to the public: usually neither.

Neither is not the same as unregulated, and this is where guides tend to stop too early. The FTC's Health Breach Notification Rule, in force since 2009 and amended in 2024 to make its application to health apps and connected devices explicit, was written precisely for companies HIPAA does not reach. Washington's My Health My Data Act carries a private right of action, which means the enforcement risk is not limited to a regulator's attention. If you land in the third category, your homework is different, not absent.

If you are in the first two categories, keep reading. If you are in the third, the rest of this guide is still worth skimming, because the vendor questions in the procurement script below are good questions regardless of which statute is asking them.

Question two: will the bot touch PHI? Yes, more often than you think

The common plan is to stay clear of HIPAA by keeping the bot away from anything clinical. Hours, directions, insurance carriers accepted, parking. No symptoms, no records, no exposure.

That plan works less often than it looks, for two reasons.

The first is the regulator's own example list. OCR's Business Associates guidance, whose page recorded a last-review date of 30 July 2026 when we read it, includes among its examples of business associates a "Third-party vendor Artificial Intelligence (AI) chatbot on a provider's patient portal that provides services involving the patient's PHI such as symptom assessment, medical reminders, and appointment scheduling." Scheduling and reminders are named there alongside symptom assessment. The intuition that appointments are administrative rather than medical does not survive contact with the definition, because the fact that a named individual has an appointment with a named provider is itself information about that person's health care.

The older escape route is also closed. Vendors used to argue they were mere "conduits," like the postal service, and therefore outside the business associate definition. OCR limits that exception to entities providing transmission only, including temporary storage incident to transmission, and says that entities accessing PHI "on a regular or frequent basis to perform a service" are not conduits. A bot that reads a message in order to classify or route it has accessed the data.

The second reason is that you do not control what people type. A website bot built for billing questions will receive messages describing conditions, medications and appointments, because that is what patients want to talk about. Free-text fields collect what is put into them. Our entity extraction entry covers the mechanism; the consequence here is that "our bot does not collect PHI" is a claim that has to be settled by transcripts, however confidently it was made about design intentions.

Question three: the BAA, and where it sits in the price list

If PHI is in scope, the gate is a signed Business Associate Agreement. Our companion entry on the Business Associate Agreement covers what the document must contain and why a vendor page reading HIPAA compliant is not the same thing. The short version is that HHS says, of Security Rule certifications specifically, that it does not endorse or recognize private organizations' certifications and that they do not absolve you of your obligations under that Rule. The statement is scoped to that Rule and it is enough on its own, because no purchased badge moves a duty off you. Against that, 45 CFR 164.502(e) makes the contract a precondition of the disclosure.

The buying consequence is what most guides omit, so here is our own corpus.

Fourteen of fifteen reviews use the word HIPAA. One names a BAA on a tier from a vendor document: Botpress, at the custom-priced Enterprise tier. The distinction in row two is not pedantry. Chatbase gates HIPAA eligibility to Enterprise and never writes the word BAA in its own material; Tars puts HIPAA at Enterprise and ships a HIPAA-compliant webhook, but the word BAA in that review is ours; Intercom states HIPAA across all three tiers and our own review says the BAA is "likely in Expert tier" and tells the reader to verify. A vendor that will not write the word is a vendor whose answer you do not yet have.

Beneath the custom tiers sit published prices you can pay today with no vendor-written BAA attached: Botpress Plus at $189 a month monthly-billed, Tars Premium at $499, Chatbase Pro at $500, and cheaper tiers below those still at Chatbase Hobby $40. All four figures are monthly-billed rates rather than annual-billed headlines, and the Botpress review carries $189 in ten separate passages including its pricing table and screenshot caption, against $89 in three others (a pros-and-cons card and two FAQ answers), so we use the figure the table and the caption both support and have flagged the discrepancy for correction. Intercom is the exception worth naming rather than burying: it states HIPAA on published per-seat tiers from $29 upward, and our review records the BAA as unverified rather than absent. Manychat's review records the flattest negative, that the vendor does not sign them at all.

So the cost of the BAA is not a price step. It is a step out of self-serve. A sales cycle, an annual commitment, a minimum you cannot see from the pricing page, and weeks rather than an afternoon. Three platforms is not a market, and this is the pattern our own corpus supports rather than a claim about every vendor selling chatbots. Two consequences for planning. Budget the calendar, not only the money. And decide the compliance question before you shortlist platforms, because a shortlist assembled on features will be full of tools you cannot legally use, and the demo will not tell you.

Question four: what you can ship without PHI

There is a real project here for clinics that do not want an enterprise contract, and it is worth being concrete about its shape rather than pretending the whole category is off-limits.

A pre-authentication information bot. Opening hours, locations, parking, which insurance carriers are accepted, what to bring to a first visit, how to reach a human. Published information, delivered faster. Not preparation instructions for a procedure. Those are clinical instructions, a wrong one has a clinical consequence, and they belong in a document a clinician has signed off on rather than in an answer a model generates.

What makes it defensible is the boundary, not the content. No identifiers collected, no free-text stored, no appointment lookup, no account linking, and a handoff to a phone number or a secure portal the moment a conversation turns personal. Ahead of every other rule, an unconditional emergency exit: if a message could be describing an urgent symptom, the bot stops answering and surfaces emergency services and your clinical phone line. That rule fires first, and it is not a fallback. Our human handoff entry covers designing that exit so it does not feel like a dead end.

What makes it fail is scope creep, and it creeps in a predictable order: someone adds "check my appointment," then "reschedule," then a callback form with a name and a phone number and a reason for the visit. Each step is small, and the last one leaves you in a different compliance posture. Write the boundary into the project brief, not the release notes.

Two more design points follow from the boundary. Keep the retention window on that bot short and deliberate, because a transcript store is where an accidental disclosure sits waiting; our data retention policy entry explains why the number has to come from you rather than from a template. And put the transcript review from the callout above on a schedule, because the claim decays as traffic changes.

The line we would not cross

An editorial position, stated plainly rather than hedged: do not build symptom triage or anything resembling clinical advice on a general-purpose SMB chatbot platform.

The reason is not regulatory in the first instance. It is that these systems produce fluent, confident, wrong answers as a normal mode of operation, not as a rare fault, and the reader of a wrong answer in this setting may act on it. Our AI hallucination entry describes the failure and our guide to reducing chatbot hallucinations covers the mitigations, all of which reduce a rate and none of which reaches zero. A tolerable error rate for a shipping-status bot is not tolerable when the output is health guidance.

Clinical decision support is a regulated product category with its own rules, its own evidence expectations and its own vendors, and it is outside both this guide and the platforms we review. If your plan requires it, that is a clinical software procurement, not a chatbot procurement. Our guide on when not to use a chatbot covers the general form of this decision.

The procurement script

Seven questions. For three of them, what a weak answer sounds like.

1. Will you sign a BAA, and on which tier? Weak: "we are HIPAA compliant." That answers a different question.
2. Can I see the BAA template before I commit? Weak: any version of "after you sign." You are being asked to buy the tier to read the contract.
3. Which subprocessors will touch this data, and are they under BAAs with you? Failure to hold subcontractor BAAs is one of the ten items for which OCR can pursue a business associate directly.
4. If a model provider is in the path, which one, under what terms, and is my data used for training? See LLM security for why this belongs on the list.
5. What is the default retention period on my tier, is it configurable, and does deletion propagate to analytics and to the model provider?
6. How and how fast will you tell me about a security incident? The Security Rule requires the reporting term in the contract; the operational answer is what you actually need.
7. What happens at the end of the contract, to the transcripts and to the derived data? Weak: silence, or a pointer to a general privacy policy rather than to the BAA.

Take the answers in writing. Our chatbot QA testing protocol is where this paperwork belongs in a launch checklist, and chatbot security and PII handling covers protecting the data once you legitimately hold it. If your patients are in the EU as well as the US, the GDPR and AI Act guide covers a separate contract with a separate name, and the two are not interchangeable.

FAQ

Related guides

• Business Associate Agreement (glossary) — this guide's companion, and the contract everything above turns on
• Data retention policy (glossary) — how long the transcripts live, which the BAA does not decide for you
• Chatbot security and PII handling — protecting the data once you legitimately hold it
• GDPR and the AI Act for chatbot operators — the European contract, which is a different document
• Reducing chatbot hallucinations — why the clinical line in this guide is drawn where it is
• When not to use a chatbot — the general form of that decision
• Chatbot QA testing protocol — where the procurement script belongs in a launch checklist
• AI hallucination (glossary) — the failure mode behind the clinical boundary
• Entity extraction (glossary) — how data you did not ask for arrives anyway
• Human handoff (glossary) — designing the exit that keeps the bot inside its boundary
• LLM security (glossary) — the surface a model provider adds to the chain

Sources

• U.S. Department of Health and Human Services, Office for Civil Rights, "Business Associates" guidance, read 24 August 2026; the page recorded "Content last reviewed July 30, 2026". Source of: the covered entity and business associate definitions summarized in question one; the AI chatbot example quoted verbatim in question two and the FAQ; the conduit exception language, including that entities accessing PHI "on a regular or frequent basis to perform a service" are not conduits; the subcontractor BAA requirement; and the 45 CFR 164.502(e) disclosure condition. We quote the page as OCR's guidance and make no claim about when the AI chatbot example was added to it. hhs.gov
• OCR FAQ #2003, "Are we required to 'certify' our organization's compliance with the standards of the Security Rule?" (HHS page carrying "Content last reviewed July 26, 2013"), read 24 August 2026, for both certification quotations. Scope note: the FAQ addresses the Security Rule rather than HIPAA as a whole, and this guide says so where it is quoted. It establishes that HHS does not recognize private certifications and that they do not absolve legal obligations. hhs.gov
• OCR, "Direct Liability of Business Associates" fact sheet, read 24 August 2026, for the enumerated list of ten items for which business associates are directly liable to OCR under the HITECH Act and the 2013 final rule (78 FR 5566). The subcontractor-BAA item cited twice here is item 9 of that list. hhs.gov
• U.S. Federal Trade Commission, Health Breach Notification Rule as amended in 2024, effective 29 July 2024, referenced for the single proposition that the Rule was updated to make its application to health apps and connected devices explicit for entities outside HIPAA. This is a secondary reading rather than a reading of the Federal Register text, and the Rule's detailed obligations are outside this guide's scope. ftc.gov
• Washington State My Health My Data Act, named only for the existence of a private right of action and the fact that health-data duties can attach outside HIPAA. Secondary reading, not analyzed here, and deliberately not generalized to other states.
• Chatbotscape review corpus, searched and read 24 August 2026, published so the counts reproduce. Denominator: ls sample-reviews/*-review.md | wc -l returns 15. Mentions: grep -rliE "hipaa" sample-reviews/*-review.md returns 14 paths, all except typebot-review.md. Three searches were run and the table is the union of all three, because no single one produces it. grep -rliE "business associate" sample-reviews/*-review.md returns 7 paths and grep -rlE "\bBAA\b" sample-reviews/*-review.md returns 11; neither is a subset of the other, six files use only the acronym and two only the spelled-out term, and the union of the two narrow searches is 13, so the remaining two rows, Blip and Botpenguin, rest on the broad hipaa search alone. Each matched file was then read end to end and every hit quoted before classification rather than being classified from the grep line. The five-row split and its labels are our classification. Price figures are monthly-billed rates per our pricing methodology, quoted as our reviews recorded them at their own verification dates and not re-verified against vendor pricing pages for this guide. None of the compliance findings in the underlying reviews was established hands-on. Three contradictions inside our own corpus surfaced during this audit; they are documented in full on the companion glossary entry rather than repeated here, and all three are flagged for manual correction. Separately, the headline count on this page moved from two to one during review, on the test that the vendor rather than we must write the word BAA.
• Rule-of-three approximation for the zero-events upper confidence bound (95 percent bound ≈ 3 ÷ n). A standard statistical result, applied here to transcript sampling by us; the thresholds of 300 and 1,500 conversations are our arithmetic from it and assume a random sample of independent conversations. It is not a regulatory threshold and no authority endorses it for this purpose.
• Ahrefs Keywords Explorer, US overview, queried 24 August 2026 — the demand, difficulty, CPC and parent-topic figures in this page's keyword note, including the checks behind declining 'hipaa compliant ai', 'protected health information', 'chatbot for doctors' and 'patient intake form'.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy and is written for the clinic manager, practice owner or operations lead choosing a platform, not for a compliance officer running a program. It covers four decisions in order: whether HIPAA reaches you, whether the bot will touch protected health information, what the resulting contract costs in practice, and what can be shipped without triggering any of it. It contains no affiliate links; some linked reviews do, and our affiliate disclosure explains the arrangement. What we do with your data is in our privacy policy.

Methodology

Every regulatory statement on this page except two was read from HHS's own published guidance on 24 August 2026 and is attributed in Sources to the page it came from. The two exceptions are secondary rather than primary and are labeled where they appear: the 2024 amendment to the FTC Health Breach Notification Rule, and the existence of a private right of action under Washington's My Health My Data Act. Platform facts come from our own published reviews at their stated verification dates and were not re-verified against vendor pages for this guide.

The editorial judgment on this page, listed here rather than flagged line by line:

1. The four-question ordering itself, which puts the threshold question before use cases. Standard guides in this category do the reverse, and the reversal is the argument.
2. The reading that appointment scheduling is inside the definition rather than administratively outside it. This follows OCR's example list directly, but the emphasis is ours, because it is the assumption we most often see buyers make.
3. The classification of our own fifteen reviews into five kinds of evidence. The categories are ours, and the strict test in row one — that the vendor, not us, must write the word BAA — is the judgment that moved Chatbase out of that row and cut the headline count from two to one during review. Another editor could draw the boundary between rows one and two differently; we would defend drawing it at whose language it is.
4. The framing of the BAA cost as a step out of self-serve rather than a price step. That is an inference from three platforms in one corpus, not a market-wide finding, and it is stated with the sample size visible.
5. The transcript-sampling arithmetic, which applies a standard statistical rule to a compliance question nobody applies it to. Useful, and ours.
6. The refusal to cover symptom triage, stated as a position rather than as a caveat. It narrows the guide's usefulness for anyone who wanted that answer, and we think that is correct.
7. The decision to bound the guide at HIPAA plus two named non-HIPAA regimes, leaving state law, FDA device rules and telehealth uncovered. Recorded in the length note as a deliberate trade against a word target the three previous runs overshot.

We have run no compliance audit, we have not read any vendor's BAA, and no statement here is legal or clinical advice. See our methodology for how platform facts are verified.

Last updated

26 August 2026.