Clinic chatbots: 7 use cases, MIS integration and patient data requirements
For a clinic with a reception team, a medical information system (MIS) and an established appointment flow, the question before launch is “How will we accept the bot’s work?” This checklist covers seven use cases, including an internal staff-training flow. Each needs a source of truth, an owner for exceptions and a testable outcome. The bot should call an appointment confirmed only after the scheduling system confirms it; “request received” is a different state.
For a broader look at possible functions, see our medical clinic chatbot overview. Here we focus on what the clinic should verify before launch and at acceptance.
Seven use cases and acceptance conditions
Before comparing vendor proposals, name the clinic owner, available data, expected result and exceptions for each use case. These are suggested acceptance criteria, not claims about existing BotLabs features.
| Use case | Decide before development | Verify at acceptance |
|---|---|---|
| Appointment booking | Which system owns the schedule, how slots are reserved and how concurrent requests are handled | Two requests for the same slot cannot both receive confirmed bookings; an uncertain result is reconciled |
| Reminders and confirmations | Send time, channel, delivery status, rescheduling and cancellation | A changed visit removes the old reminder; a sent message is never counted as attendance |
| Preparation instructions | Approved copy, procedure mapping, version and update owner | An ambiguous procedure goes to staff rather than producing new clinical advice |
| Administrative FAQ | Official hours, addresses and prices, and who maintains them | Missing or stale information leads to staff contact, not an invented price |
| Feedback | Where complaints go, who responds and under what internal rule | A concern reaches a named owner; an invitation to leave a public review does not depend on the patient's rating |
| Return visits | Whose approved plan is relayed and which messages are permitted | The bot relays an existing plan and allows unwanted messages to stop; it does not invent intervals |
| Staff learning | Separate login, roles, branches and offboarding | A former employee loses access; training modules do not expose patient records |
The last use case belongs to an internal staff system. The Astra Dent case describes a closed Telegram training bot with modules, FAQ, knowledge checks and access by branch and role. It is an example of staff learning, not evidence of patient booking through an MIS.
The MIS determines whether a booking really happened
Before fixing project scope, ask the MIS vendor to demonstrate the available API operations: reading open slots, creating, changing and cancelling an appointment, finding a booking after an uncertain response, and using a test environment. Check access rights, rate limits and other ways the schedule can change, including reception staff, phone calls and the website. The MIS product name alone does not prove that the required integration exists.
Agree on three patient-visible states: confirmed in the MIS, request awaiting reception, and action failed. If the MIS response is lost or times out, the bot should first check whether the booking was created. Retrying creation blindly can produce a duplicate. Until reconciliation, the patient sees a request status and a staff member gets a task with an owner and handling deadline. Rescheduling or cancellation must also update pending reminders.
If the API only reads the schedule, or no API exists, start with requests that need human confirmation. Reception creates the booking in the MIS; only then does the patient receive confirmation. This is a smaller but honest pilot scope.
Patient data: flow, access and deletion
Health data require a separate assessment of purpose, lawful grounds and safeguards. With the clinic's counsel, determine these for the specific workflow, as well as clinic and vendor roles, message copy, retention and deletion. A patient contacting a messenger bot does not determine a lawful basis.
| Data or event | Purpose | Location and access | Decide before launch |
|---|---|---|---|
| Contact and preferred time | Contact the person and process a request | Minimum necessary in the bot; authorised reception staff | Retention, duplicate handling and deletion route |
| Confirmed appointment | Show the correct status | MIS as source of truth; bot receives only the needed status | Who may view and change it; error reconciliation |
| Reason for visit, results, diagnosis | Clinical care | Designated system and authorised clinical staff | Do not put into free-form chat without a separate, justified process |
| Permission for additional messages | Separate service notices from marketing | Permission record system | Record the decision and stop unwanted messages |
| Staff learning material | Train the team | Separate roles and accounts | Offboarding and no patient chart access |
Even a specialty or visit time may reveal sensitive context. Review reminder wording and the display on a shared family phone separately. A phone number can help locate a request, but it alone does not authorise access to someone else's medical record.
Where the administrative bot and AI stop
The bot can help people find an address, opening hours, available services and the status of an administrative request using clinic-approved information. Pass free-text symptom questions to qualified staff through the clinic's agreed process. For this project, do not scope generated diagnosis, interpretation of test results, medication doses or urgency ranking. A responsible clinic professional approves and updates any preparation instructions.
This is a proposed boundary for an administrative product, not a claim that every medical use of AI is illegal. In the vendor brief, specify when the bot answers from approved material, when it says it does not know and who receives the handoff.
A pilot with baseline and acceptance metrics
Choose one branch and one administrative flow, such as booking requests. Before the pilot, count incoming requests, confirmed appointments, changes, duplicates, missed visits and reception handling time using consistent definitions. Assign an owner for these measures. Compare equivalent periods and note changes in season, staffing or demand; a universal pilot duration means little without transaction volume.
Agree acceptance thresholds before implementation: how many test cases to run, what error level the clinic accepts, how quickly staff resolve uncertain requests and who signs off. Do not equate messages sent with messages delivered, delivered messages with patient confirmations, or confirmations with actual attendance.
A 2013 Cochrane review of studies through August 2012 found low to moderate quality evidence that SMS/MMS reminders can increase attendance compared with no reminder. It does not establish the effect of a modern messenger bot or the return on investment for your clinic. Evaluate the pilot using appointments actually attended or refilled and full operating costs; saved staff minutes do not automatically become cash savings.
What to put in the vendor brief
Provide the MIS name and version, its vendor contact and available API documentation, branches and booking channels, request volume, the reception process owner, approved message templates, permitted data and the exception queue. Add concrete cases: two people pick the same slot; a booking succeeds but the response is lost; a patient reschedules; several relatives share one phone. Ask vendors to price this scope and its pilot criteria, rather than an undefined “clinic chatbot”.
For a discussion of the first administrative workflow, see BotLabs' healthcare solutions. Do not send patient data in an initial lead request; the MIS name, workflow and clinic contact are enough.
Conclusion
Accept a clinic chatbot based on appointment states, exceptions, data boundaries and reception work, not the appearance of its conversation alone. Start with one workflow: check the MIS capabilities, agree on human handling of failures, define the minimum data and record the baseline. Expand only after the pilot demonstrates correct operations.
Frequently asked questions
The bot may collect a request, but should not call it a confirmed appointment. Reception enters the booking in the MIS, after which the patient gets confirmation.
A “checking your request” status or a failed-action message, depending on reconciliation. Under the agreed workflow, a visit is not confirmed without an MIS record.
The number alone does not authorise access to another person's appointment. The clinic must decide how to verify identity and how much information to display.
A responsible clinic professional approves the exact wording and version. If the procedure is ambiguous, the bot hands the question to staff.
Record the cancellation, the slot becoming available for a new booking, and the new patient's actual attendance. Clicking “cancel” alone does not prove recovered revenue.
No. Track send attempts, delivery, replies and actual attendance from the MIS or reception as separate events.
Sources
- Ukraine’s Law on Personal Data Protection — review the current wording and application to the workflow with clinic counsel.
- Cochrane: reminders for healthcare appointments — a review of SMS/MMS, not evidence for a modern bot.
- BotLabs Astra Dent case — an example of staff training, not patient-booking confirmation.
Clinic chatbot consultation
In a 15-minute consultation with a BotLabs implementation specialist, we’ll discuss your clinic’s scheduling system, booking process and what happens when something fails. We’ll identify the system and workflow information needed to scope an initial booking pilot.
Discuss your booking flow.
Identify the next step.
Identify the scheduling-system and workflow information needed to scope a pilot.
