Healthcare Chatbot Use Cases That Actually Hold Up

The line that decides everything: does it touch PHI?

Before comparing features, sort the use case into one of three buckets. Almost every downstream decision, including whether you can use an off-the-shelf chatbot at all, follows from which bucket you are in.

Bucket one: public information, no patient identity

The chatbot answers from content already published on your website. Opening hours, accepted insurers, services offered, clinician bios and specialties, preparation instructions for a procedure, parking and building access, referral policy, billing policy, how to request records. Nobody identifies themselves. Nothing said in the conversation is protected health information, because it is not individually identifiable health information created or received by a covered entity about a specific person.

This is the only bucket a general-purpose chatbot platform belongs in, and it is genuinely useful. A large share of calls to a practice front desk are questions the website already answers, and inbound calls are the most expensive channel a practice runs. ContactBabel's 2026 US Contact Center Decision-Makers' Guide puts the average inbound call at $7.20, 47% more than an email and 23% more than a web chat.

Bucket two: identified patients and their data

The moment the conversation involves a named patient, an appointment on a specific chart, an insurance member ID, a balance owed, a refill request or anything about a person's condition, you are handling PHI. That triggers the full HIPAA apparatus described further down, including a signed Business Associate Agreement with every vendor that stores or transmits it.

Plenty of vendors serve this bucket properly. They integrate with the EHR or practice management system, they sign BAAs, they run access controls and audit logging, and they charge accordingly. They are a different purchase from a $29-a-month website chatbot, and they should be.

Bucket three: anything clinical

Symptom assessment, triage recommendations, medication guidance, mental health intervention. Software that is intended to inform a clinical decision can meet the legal definition of a medical device. In the EU, symptom assessment tools have been certified under the Medical Device Regulation. In the US, the FDA's Clinical Decision Support Software guidance sets out which software functions fall inside the device definition and which were excluded by the 21st Century Cures Act. This is not a configuration setting on a chatbot. It is a regulatory pathway with clinical evidence, a quality management system and audits attached.

The non-clinical healthcare chatbot use cases, one by one

These are the ones with real value and low risk. The PHI column is the important one, because it tells you whether an off-the-shelf website chatbot can do the job or whether you need a vendor that will sign a BAA. The last column exists because no honest source publishes a reliable industry-wide savings figure for any of these. Measure your own baseline first, then measure again.

Read the table as a boundary line rather than a menu. Everything marked no can run on a general website chatbot trained on your public pages. Everything marked yes needs a vendor under a BAA with an integration into the system of record. Trying to fake the second group with the first is the single most common mistake in this category. The same split logic applies in other regulated verticals, and the insurance chatbot use cases page works through the equivalent boundary for policy and claims data.

When a chatbot is not the answer here

Plenty of practices do not need one of these, and most of the ones that do need it for far less than they first imagined. Four stages, in the order they tend to arrive.

Stage one: answering it yourself is genuinely fine

One site, one receptionist, a phone that rings at a manageable rate and a website that already reads clearly. Someone asks about parking, someone answers, and that is the end of it. A person answering a person is not a failure of automation. It is the warmest and cheapest version of this work, and it stays that way until the volume changes. If that is where you are, write the pages your website is missing and stop there.

Stage two: the friction starts

The same handful of questions begins eating the same part of every morning. The phone goes during check-in. Calls arrive after hours and land in a voicemail box that somebody works through at lunch. The answers are on the site, but patients ring anyway, because ringing is easier than searching. Nothing is broken yet. You are simply paying for it through the most expensive channel a practice runs, and paying again in your front-desk staff's attention while a patient stands in front of them waiting to be seen.

Stage three: it turns into a liability

The liability arrives with the temptation to widen the scope. Someone suggests the bot could confirm an appointment. Then look up a balance. Then answer the question a patient actually came to ask, which was about a symptom. Each step looks small on its own, and together they carry a public-information tool into work it has no business doing.

Clinical questions are not scope creep. Neither is anything about a named individual's condition, medication or treatment, and neither is anything that amounts to regulated advice. Those belong to the separate, often regulated category described further up this page. Protected health information behaves the same way: the moment an answer depends on a specific patient's record, appointment, balance or insurance details, you need a vendor operating under a signed Business Associate Agreement rather than a website chatbot with a longer prompt. In every one of those cases the bot's job is to stop and hand the conversation to a person, straight away, without attempting an answer first. A refusal that reaches a human is a correct outcome. A helpful-sounding guess is not.

Stage four: the edge case that breaks it

The one that breaks the model is the question that looks administrative and is not. Preparation instructions are published content, so a bot can repeat what they say. Then a patient asks whether they should still take their tablets before the scan, which is medication guidance wearing the clothes of a logistics question. Free text does the same damage from the other direction. Someone types a paragraph about how they have been feeling into a box that only asked which clinic they wanted, and a tool you scoped to hold nothing sensitive is now holding it in a transcript.

Neither of those is rare. Both need a refusal policy written before launch, a human on the other end of it, and a retention decision made in advance. And both are the reason the narrow scope argued for on this page is caution rather than timidity.

Symptom triage and mental health support: a different product category

These get the most attention and deserve the most caution. The point of this section is not that they are impossible. It is that the organisations doing them credibly built purpose-specific, in some cases regulated products, and that a general chatbot platform is not a lighter version of one of those.

Symptom assessment

Symptom assessment software takes reported symptoms and returns possible causes or a suggested level of care, which can bring it inside medical device regulation.

Ada Health's enterprise product, Ada Assess, is certified as a Class IIa medical device under EU Regulation 2017/745, and the company announced that certification in December 2022. That is what the serious end of this category looks like: a notified body, a certified quality management system under ISO 13485, technical documentation and clinical evidence. Ada's consumer app remains available and was still being updated in mid-2026. Buoy Health also operates a consumer symptom checker in the US.

Note that Ada Health GmbH, at ada.com, is a completely different company from Ada Support Inc., the customer-service automation vendor at ada.cx. They are regularly confused in vendor round-ups. Only one of them makes a symptom assessment device.

The cautionary example is Babylon Health, which built a widely promoted symptom checker and a large digital-first primary care business. Its US entity filed for Chapter 7 liquidation in August 2023 and the UK business was sold to eMed. A symptom checker is not a durable product simply because the model is good. It carries clinical, regulatory and commercial weight that most software businesses are not built to hold.

What this means for a practice

• If you want symptom assessment on your site, you are procuring a clinical product, not configuring a chatbot.
• Ask for the regulatory classification in writing, in every market you operate in.
• Ask who carries clinical liability when the tool tells a patient their symptoms are probably minor.
• A general chatbot answering "what should I do about this pain" from your marketing pages is a serious safety problem, not a feature.

Examples: Ada Assess (EU-MDR Class IIa), Buoy Health symptom checker

Mental health support chatbots

Conversational mental health tools deliver structured therapeutic content, and the best-known one withdrew from the consumer market rather than continue without clear regulatory footing.

Woebot was the reference example in this category for years: a rule-based, clinically designed conversational agent delivering cognitive behavioural therapy techniques. Woebot Health retired the consumer app on 30 June 2025. Its own FAQ states that new accounts can no longer be created and previous accounts can no longer be accessed. Access now runs through partner organisations, and the company sells to providers and payers.

The founder told STAT in July 2025 that the shutdown was largely down to the cost and difficulty of meeting FDA requirements for marketing authorisation, and that there was a pathway for rule-based chatbots but no clear route for large language model products. That is worth sitting with. The most careful, most studied consumer mental health chatbot exited the consumer market on regulatory grounds. A general SaaS chatbot with a sympathetic system prompt is not a smaller version of that. It is an unstudied product in a domain where being wrong is dangerous.

The only safe version for a general chatbot

• Publishing crisis line numbers and service information as static, reviewed content.
• Explaining what a service offers, who is eligible and how to self-refer.
• Immediate, unconditional handoff to a human for anything that reads as distress, with no attempt to counsel first.
• Never generating reassurance, coping advice or risk assessment.

Examples: Woebot (consumer app retired 30 June 2025, now partner-access only)

HIPAA: what you actually have to do before a chatbot touches patient data

This section applies to US covered entities and their vendors. If your chatbot will store, transmit or even briefly see protected health information, the following is not optional and not something you can satisfy by ticking a box in a settings panel.

A signed Business Associate Agreement, first

A vendor that creates, receives, maintains or transmits PHI on your behalf is a business associate. HHS states that a covered entity must enter into a contract or other written arrangement with each business associate meeting the requirements at 45 CFR 164.504(e). The agreement has to restrict how the vendor may use and disclose the information, require the vendor to report any use or disclosure not permitted by the contract including breaches of unsecured PHI, require return or destruction of PHI at termination where feasible, and allow you to terminate for a material breach of the terms.

There is no such thing as a HIPAA-compliant product bought without a BAA. A vendor that says it is HIPAA compliant but will not sign one has told you it is not available for this work. Ask for the BAA before the demo, not after procurement.

The Security Rule safeguards

• Access controls. Only the people who need PHI to do their job can reach it, with unique user identification and a documented process for emergency access.
• Audit controls. Hardware, software or procedural mechanisms that record and examine activity in systems holding PHI, so you can reconstruct who saw what and when.
• Encryption in transit and at rest, plus integrity controls so you can tell whether PHI has been altered or destroyed improperly.
• Authentication. Verifying that a person or entity seeking access is who they claim to be, which for a patient-facing chatbot means real identity verification before any account-specific answer.
• Administrative safeguards around all of it: risk analysis, workforce training, sanctions, contingency planning and periodic evaluation.

Minimum necessary, applied to conversation design

The minimum necessary standard is a design constraint on the bot, not just on your staff. Ask for the least information that lets you complete the task. A reschedule flow needs enough to identify the appointment and nothing about why the patient is being seen. A billing flow needs an account reference, not a diagnosis. Free-text boxes are where minimum necessary quietly fails, because patients volunteer clinical detail nobody asked for, and once it is in a transcript it is PHI you are now responsible for storing, protecting and eventually disposing of.

Decide before launch how long transcripts are retained, who can read them, whether they are used for quality review, and how they are destroyed. Write it down. That document is part of your compliance posture, and it is also the thing that stops a well-meaning marketer from exporting conversation logs into an analytics tool.

Breach notification

If unsecured PHI is breached, covered entities must notify affected individuals without unreasonable delay and no later than 60 days after discovery, with notice to HHS and, for larger breaches, to the media. Your BAA has to make the vendor tell you fast enough that you can meet that clock. A chatbot vendor with no defined incident process is a vendor who will find out about a breach at the same time you do, from a customer.

Outside the US

UK and EU practices are under UK GDPR or GDPR, where health data is special category data requiring an Article 9 condition, a lawful basis, a data processing agreement with the vendor and usually a Data Protection Impact Assessment before launch. The specifics differ from HIPAA, but the shape of the obligation is the same: a written contract with the processor, documented safeguards, data minimisation and a breach clock.

Three kinds of vendor, and what each one is for

Healthcare buyers get sold across all three of these columns as though they were tiers of the same thing. They are not. The first column is a website tool, the second is clinical infrastructure, the third is a medical device.

To be unambiguous about where we sit: matram.ai is a column-one product. We do not sign Business Associate Agreements. We hold no HIPAA certification or attestation, no SOC 2 and no ISO 27001. We offer no on-premise, private-cloud or dedicated-instance deployment. matram.ai must not be used to handle protected health information, and we would rather lose the sale than have a clinic discover that after go-live. What it is genuinely good for in healthcare is the public-information half of the table above: a practice website bot that answers from your published pages, cites the page it used, and hands off to a person the moment a question gets specific to an individual.

How to scope a healthcare chatbot you will not regret

The projects that survive their first year are the ones that were scoped narrowly on purpose. The ones that get switched off tried to do clinical work with administrative tooling.

If you want to sanity-check the economics before committing, work from your own call volume and your own handling cost rather than a vendor benchmark. The chatbot ROI calculator takes your numbers, and the general chatbot best practices guide covers the escalation and transcript-review habits that make any of this work.

What getting this wrong costs, long after the invoice

The subscription is the smallest number in this decision. The costs that matter are second order, they arrive late, and none of them appears on a bill.

Start with the patient who acted on a wrong answer. Someone reads a confident line about which insurers you take, travels in, and finds out at the desk that the plan changed at renewal. Someone else turns up on a Friday because the bot quoted opening hours that were true last year. The bill is not the subscription. It is a wasted slot and a difficult conversation your receptionist did not cause. And it is one patient who now files the whole practice under careless, because nobody separates the software from the organisation that put it on its own website.

The second cost turns up in a review, and it is always about something nobody decided. Somebody asks what the chatbot stores, how long transcripts are kept, who can read them and how they are disposed of. If the honest answer is that it never came up, then free-text boxes have been quietly collecting whatever patients felt like typing since the day it launched. That isn't a bug you can patch on a Thursday. It is a gap you have to account for in a process where the accounting is the expensive part, which is exactly why retention and access belong in writing before go-live rather than in the middle of an audit.

Then there is trust, which you only get to spend once. A patient who receives one wrong answer from a tool sitting on your own website does not conclude that the tool is unreliable. They conclude that you are. They go back to ringing, which was the cost you set out to reduce, except now your receptionist is apologising as well as answering. So the question worth holding onto during a vendor demo is not how many calls this could take off the front desk. It is what happens the first time it is confidently wrong, and how quickly a person can take the conversation over.

Frequently asked questions

Sources

• HHS, Business Associate Contracts (sample provisions) - That a covered entity must enter a written contract with each business associate meeting 45 CFR 164.504(e), and the required terms on use, disclosure, breach reporting, return or destruction of PHI, and termination.
• HHS, Business Associates FAQ - The definition of a business associate as a vendor that creates, receives, maintains or transmits PHI on a covered entity's behalf.
• HHS, Summary of the HIPAA Security Rule - The administrative, physical and technical safeguards cited here: access controls, audit controls, integrity, authentication, transmission security, risk analysis and workforce training.
• HHS, Breach Notification Rule - That individuals must be notified of a breach of unsecured PHI without unreasonable delay and no later than 60 days after discovery.
• FDA, Clinical Decision Support Software guidance - That software intended to inform clinical decisions may meet the device definition, and that the 21st Century Cures Act excluded certain decision support functions from it.
• Ada Health press release, 15 December 2022 - That Ada Assess is certified as a Class IIa medical device under EU Regulation 2017/745, with an ISO 13485 quality management system.
• Woebot Health FAQ (checked 20 July 2026) - That the Woebot app was retired on 30 June 2025, that new accounts cannot be created and previous accounts cannot be accessed, and that access now runs through partner organisations.
• STAT News, 2 July 2025 - The founder's account that the shutdown was largely driven by the cost and difficulty of FDA marketing authorisation, with a pathway for rule-based chatbots but none clear for large language model products.
• TechCrunch, 31 August 2023 - That Babylon Health went bankrupt and was sold for parts, with the US entity in Chapter 7 liquidation in August 2023 and the UK business going to eMed.
• Buoy Health (checked 20 July 2026) - That Buoy Health operates a consumer symptom checker in the US as of July 2026.
• ContactBabel, 2026 US Contact Center Decision-Makers' Guide - That the average inbound call costs $7.20, 47% more than an email and 23% more than a web chat.