Healthcare Chatbots

What is a healthcare chatbot?

A healthcare chatbot is software that holds a text or voice conversation with patients or staff to answer questions, collect information or complete tasks such as booking and refills, using scripted flows, a language model or both. It works inside rules that set its scope, its handoff points to people and its handling of PHI.

Two designs are common. Scripted bots follow decision trees and buttons, which makes them predictable and easy to audit. Language model bots understand free text and answer from approved content, which makes them flexible but harder to constrain. Many production bots combine them, using the model to understand the request and scripted flows to act on it.

The benefits are practical: fewer phone calls for simple questions, answers outside office hours, faster intake and a consistent reply each time. They appear only when the bot's scope is narrow and its handoff to people works.

Which jobs should a patient-facing chatbot do?

A patient-facing chatbot should do administrative and navigational jobs with clear right answers, and hand anything clinical to a person or an approved triage protocol. The narrower the scope at launch, the safer and more useful the bot.

• Good first jobs: Clinic hours, directions, parking, accepted insurance, visit preparation and portal help.
• Task completion: Booking, rescheduling and cancelling appointments, refill requests and bill payment, through the same APIs the portal uses.
• Intake: Collecting reason for visit, demographics and insurance details before an appointment.
• Reminders and follow-up: Two-way texts to confirm visits or check on post-visit questions, routed to staff when the patient asks something new.
• Out of scope: Diagnosis, medication changes, interpreting results and anything that sounds like an emergency.

Symptom questions need special care. If the service wants a bot to help with symptoms, it should run a validated triage protocol that clinicians have approved and that routes to the right level of care, not a language model improvising advice.

What can staff-facing chatbots do?

Staff-facing chatbots answer internal questions and fetch information so clinicians and administrators spend less time searching. Typical uses are policy and procedure lookup, IT help desk requests, benefit and HR questions, coding and billing reference, and drafting routine letters for review.

Clinical uses need more control. A bot that summarizes a chart or suggests next steps becomes a patient care decision support tool. Section 1557's rule at 45 CFR 92.210 expects covered entities to look for, and mitigate, discrimination risks in the patient care decision support tools they use, so a clinical bot of this kind belongs in the tool inventory and gets reviewed.

Answers should cite the internal document they came from, so staff can check the source. A policy bot that answers without showing the policy encourages people to trust it beyond its accuracy.

When must a chatbot hand off to a person?

A chatbot must hand off to a person when the user describes an emergency or risk of harm, asks a clinical question outside its scope, gets stuck, or simply asks for a human. The handoff should be one step away at all times and should carry the conversation with it.

• Emergency words: Chest pain, trouble breathing, stroke signs, suicidal thoughts or abuse trigger an immediate emergency message with numbers to call, before anything else.
• Clinical questions: Questions about symptoms, medicines or results go to a nurse line or the care team's message pool.
• Repeated failure: Two failed attempts to understand the user route to a person rather than a third try.
• Explicit request: "Agent", "person" or "human" always works, in every language the bot supports.
• Sensitive topics: Billing disputes, complaints and privacy requests go to staff who can resolve them.
• Context transfer: The transcript and anything the bot collected go with the handoff, so the patient does not start again.

Hours matter. If no person is available at night, the bot must say so plainly and give the right alternative, such as a nurse advice line or emergency services, instead of promising a callback it cannot guarantee.

How should a chatbot handle PHI?

A chatbot used by a covered provider handles PHI as soon as a patient types a symptom, a name or an appointment detail, so every vendor in its chain that receives that data needs a business associate agreement under 45 CFR 164.502(e). That includes the chat platform, the language model provider and any logging or analytics service.

• Model provider: Use a model service and plan that the vendor covers under a business associate agreement, with data retention and training use settled in writing.
• Identity before records: Verify the patient through the portal login or another proven method before the bot shows appointments, bills or results.
• Minimum data: Collect only what the task needs, and avoid asking for full identifiers in an unauthenticated chat.
• Logs: Store transcripts as PHI, with access controls and a retention period, and keep them out of general-purpose analytics tools.
• Notifications: Keep text messages and lock-screen previews free of diagnoses and clinic specialties.

Website chat widgets need a second look. An unauthenticated widget on a public page can still receive PHI when patients type it, and tracking scripts on the same page may capture it. Review the page as a whole, not only the bot.

Where is the FDA line for chatbots?

The FDA line depends on what the chatbot does with medical information. FDA's clinical decision support software guidance, finalized in January 2026, describes when software that supports clinical decisions is not a device, and patient-facing tools fall outside that carve-out, though they are not automatically devices either.

Administrative bots for scheduling, billing and directions are not medical devices. General wellness information and links to approved patient education are usually low risk. A bot that assesses a patient's symptoms and tells them what condition they may have or what to do clinically moves toward device territory, and needs a regulatory assessment before launch.

For staff-facing bots, the CDS guidance criteria matter: whether the software analyzes images or signals, whether it supports rather than replaces the clinician's judgment, and whether the clinician can review the basis for its output. Device status and device class are separate questions, so get regulatory advice early when a bot touches diagnosis or treatment.

Who owns the chatbot's answers?

Every answer a chatbot gives should trace back to content that a named owner approved. Clinic hours belong to operations, insurance answers to revenue cycle, visit preparation to the clinical team, and the emergency message to the medical director.

Hold that content in a managed library with a review date for each item, rather than inside prompts or flow diagrams. When a clinic changes its hours or a payer leaves the network, the owner updates one entry and the bot's answers follow.

Language model bots need the same discipline. Retrieval from the approved library, with the bot told to answer only from what it retrieves and to hand off when nothing fits, keeps answers inside the content owners signed off. Changes to prompts and model versions go through the same review as content changes.

Translations are content too. If the bot serves several languages, each translated entry needs review by a qualified translator and its own owner, or patients in one language get older answers than patients in another.

How do you test a healthcare chatbot before launch?

Test a healthcare chatbot with scripted conversations that cover every job in scope, every handoff trigger and every way users try to push it out of scope. Each script has an expected outcome, and the bot passes only when every safety script passes.

• Emergency scripts: Dozens of phrasings of urgent symptoms, including misspellings and other languages, all of which must produce the emergency response.
• Scope scripts: Clinical questions the bot must decline and route, including questions phrased as hypotheticals.
• Task scripts: Booking, rescheduling and refill flows end to end against a test EHR, checking that the record actually changes.
• Identity scripts: Attempts to see another person's appointments or bills without proper verification.
• Content checks: Answers compared with the approved content they came from, with any unsupported statement treated as a failure.
• Accessibility checks: The chat window works with screen readers and keyboard only, and text is readable at large font sizes.
• Load and failure: Behavior when the model service or EHR API is slow or down, which should be a clear message and a handoff.

Keep testing after launch. Review a sample of real transcripts each week, add any failure to the script set, and rerun the full set whenever the model, prompts or content change.

How Agnotic can help

Most of the work in a healthcare chatbot is scope, rules and integration, not the conversation itself. Through its fractional CTO service, Agnotic Technologies helps healthcare organizations decide what a bot should do, choose between scripted and model-based designs, set up vendor agreements and data flows, and build the EHR integrations and test suites behind it.

The client's clinical leaders approve the content, protocols and handoff rules. Agnotic implements them so every answer and every escalation can be traced and tested.

Sources

• FDA: Clinical Decision Support Software guidance
• Cornell LII: 45 CFR 164.502, including (e) disclosures to business associates
• eCFR: 45 CFR 92.210, nondiscrimination in the use of patient care decision support tools