What We Learned Building a Healthcare Chatbot for International Patients

💡 Quick Summary (TL;DR):

• The Project: VaniBot supports pre-consultation communication and structured intake for international patient inquiries at Vanity Hospital, then hands the conversation to the relevant team.
• The Engineering Choice: In our original evaluation, a hosted OpenAI model fit our conversation quality, reliability, and operational requirements better than the self-hosted alternatives we tested.
• The Lesson: In this deployment, the chatbot reduced repetitive communication work without taking medical judgment or high-stakes decisions away from qualified people.

At Vanity Cosmetic Surgery Hospital, most international patient inquiries begin through digital channels. They arrive from different countries and time zones throughout the day.

In our workflow, delayed replies often meant that a conversation did not resume. That made response time an operational problem, not just a messaging metric. We started VaniBot to shorten those delays and keep suitable inquiries from stalling.

The project soon extended beyond the chat interface. It affected internal processes, ownership, integrations, and how patient relations teams worked with technology.

We have run the system for roughly a year. Internally, we call it VaniBot, but its scope is not the same as a retail FAQ bot. International patient inquiries can involve personal and medical context around a serious decision such as surgery.

One boundary is essential: VaniBot supports pre-consultation communication and intake. It does not make the final medical assessment or treatment decision. When professional judgment is needed, the conversation belongs with patient relations and qualified medical staff.

I am not documenting VaniBot's data architecture in this article. Any team using a hosted model in a health workflow must separately review what data reaches the model, who can access it, how long it is retained, and which privacy obligations apply. OpenAI's current API data-controls documentation also makes clear that retention and zero-data-retention eligibility depend on the endpoint, feature, and configuration.

The lessons below are about operating the wider system: ownership, channels, integrations, model choice, and the point where automation must hand over to a person.

Key Lessons from the Process

1. It's Not a Set-It-and-Forget-It Project

A chatbot isn’t something you build once and move on. Response times, handoff quality, workflow failures, and actual user interactions need regular review. Improvements have to continue after launch.

It is not only the IT team's responsibility. Everyone whose work the bot supports or changes needs to be involved.

2. In Our Team, the Bot Supported People Instead of Replacing Them

No one in our team lost their job because of VaniBot. In this deployment, it removed repetitive communication tasks and gave staff more room for work that required context and judgment.

Over time, the team began treating it like a shared digital assistant. The degree to which daily work had adapted around the system became its clearest sign of operational adoption.

3. The Real Cost Isn’t Just Money

The most common misconception: “We’ll pay a vendor 5K a month and it’ll all be handled.”

The reality? To build something that actually works, you need:

• Real focus from your team
• Collaboration across departments
• A strong IT infrastructure
• Ongoing support and ownership
• Even when working with a vendor, a long-term partner who understands the goal

Otherwise, even with a technical service provider, maintenance and process ownership can remain unclear.

4. Multichannel Integration Is the Toughest Part

Integrating a bot into a website was the simpler part for us. Keeping the same workflow reliable across channels such as WhatsApp and Instagram created much more complexity.

5. Having a Solid Internal API Layer Helped a Lot

We already had stable internal APIs for our CRM and other operational systems. That meant we didn’t need to reinvent the integration layer. We could focus on the bot's logic and conversation design, which saved time and complexity.

6. Our Model Decision: Self-Hosted or Managed Service?

We considered a self-hosted open-source model and I ran some small tests. For the models, infrastructure, and requirements available to us at that point, a hosted OpenAI model was the better fit.

The decision was specific to this project:

• The hosted model performed better in our tests for conversational coherence, context retention, and the interaction style we needed.
• Self-hosting would have added GPU capacity, performance, uptime, scaling, and logging to the team's responsibilities.
• Across that year of use, the hosted service was operationally reliable for us apart from one or two global outages.

That is not a universal ranking of hosted and open-source models. A self-hosted model may be the better choice when the task is narrower or greater control over data and infrastructure is required. For us, operational reliability mattered as much as model quality.

Where Automation Ends and Human Handoff Begins

We also tested some bot flows with a limited group of inquiries to see whether they could keep the pre-consultation process moving without creating pressure or confusion.

The goal was not to let a bot persuade someone into a medical decision. It was to build a system that could recognize when to provide routine information, when to collect the next required input, and when to step aside for a person. We did not publish conversion or clinical-outcome measurements from these tests, so I treat them as an operational experiment rather than proof of commercial impact.

What VaniBot Taught Us

With VaniBot, we learned that a chat interface is not a solution on its own:

• Repetitive communication work declined; work that required context and judgment remained with the team.
• The system can work only when the technology team, patient relations team, and relevant operational owners monitor and improve it together.
• Existing infrastructure such as the CRM and internal APIs made the workflow easier to build. Automation can move routine steps forward, but medical assessment and high-stakes decisions must remain with clearly identified people.

In this project, we did not just build a chat interface. We built an operational system that the team monitors, improves, and uses as part of its daily work.