How We Built DrCliniq: A Clinical Assistant That Lives in WhatsApp

DrCliniq is a product we designed, built and run ourselves. It is a clinical assistant for Indian clinics and doctors that works inside WhatsApp. It answers routine patient questions, books appointments, flags urgent cases for the doctor, and in its higher plan reads lab reports and voice notes. This article explains the decisions behind it. It is not a client case study, and we have left out usage figures on purpose.

The problem we started with

In India, many patients already message their doctor on WhatsApp. They ask about clinic timings, fever doses, follow-ups and lab results, at all hours. For a small clinic this is a second, unpaid job. Most of these messages are routine and have well-known answers, but a few are urgent, and the urgent ones are easy to miss in a busy inbox.

We did not want to build another app that patients would need to download. The useful question was narrower: can routine messages be handled where patients already are, while the doctor stays in control of anything clinical?

Decision 1: WhatsApp, not a new app

Choosing WhatsApp removed the biggest adoption problem, because patients do not have to install or learn anything. It also set hard engineering constraints. DrCliniq runs on the official WhatsApp Business API from Meta, so every interaction has to follow WhatsApp's rules for business messaging.

The most important of those rules is the customer service window. A business can reply freely for 24 hours after the patient's last message. Messages the clinic starts itself, such as day 3 and day 7 follow-ups, must use message templates that Meta has approved in advance. That shaped the product: follow-ups are designed as short, pre-approved templates rather than free-form text.

Decision 2: protocols, not an open-ended chatbot

A general chatbot that answers any medical question is the wrong product for a clinic. The doctor is responsible for the advice their patients receive, so the doctor needs to decide what the assistant says. DrCliniq is built around protocols: ready-made flows for common situations such as pediatric fever, cough and cold, diabetes follow-up, BP review, pregnancy queries, prescription refills and lab report intake. The library starts with more than 50 of them.

Doctors edit protocols in plain English rather than code. This was one of the most important choices we made. It keeps clinical judgement with the doctor, makes the assistant's behaviour predictable, and lets a clinic adapt the product without asking us for changes. Patients choose from interactive WhatsApp menus built from the clinic's own protocols.

Decision 3: the doctor stays in the loop

The assistant handles the routine and escalates the rest. Urgent cases are flagged to the doctor instead of being answered automatically. On the Clinic+ plan, a morning briefing gives the doctor a summary of what came in. We treat this as a core design rule, not a feature: an AI system in healthcare should reduce the doctor's workload without quietly taking over decisions that belong to them.

Decision 4: Hindi and English from day one

Patients write in Hindi, in English and in a mix of both. DrCliniq detects the language automatically and replies in kind, with no setup by the clinic. Every protocol therefore exists in both languages. Supporting two languages from the start was more work early on, but adding a language later would have meant revisiting every protocol and every message template.

Handling messages that are not text

Real patients send voice notes, photos of prescriptions and PDF lab reports. Each of these has to become structured information before the assistant can do anything useful with it: a voice note has to be transcribed, and a lab report has to be read and its values extracted. On the Clinic+ plan, DrCliniq handles voice notes and lab report parsing, and the Pro plan accepts images and documents. Each input type adds a step that can fail, so each one needs a clear fallback to the doctor when the system is not confident.

Data handling

Health data needs careful treatment. DrCliniq stores data on servers in India, encrypts it at rest and in transit, and limits access on a least-privilege basis. Under India's Digital Personal Data Protection Act, the doctor is the data fiduciary for their patients and DrCliniq processes data on their behalf. Patient message retention follows the clinic's policy, with a default of 12 months. These rules are set out in DrCliniq's privacy policy.

Pricing as a product decision

DrCliniq has a free plan for solo doctors with a small number of protocols and a daily message limit, and two paid plans priced in rupees, with payments through Razorpay. A free plan means the product has to be cheap to run per clinic, which in turn shapes engineering choices such as how much work is done per message and when more expensive processing, like voice and lab reports, is used. Building billing and plan limits in from the start was simpler than adding them later.

What building it taught us

• Meet users in the channel they already use. The channel's rules then become product requirements, so learn them early.
• Constrain the AI to what the expert has approved. Editable protocols made the assistant both safer and easier to trust.
• Design the hand-off to a human first. Escalation is what makes automation acceptable in a clinic.
• Treat every new input type, such as voice or PDFs, as its own pipeline with its own failure cases.
• Unit cost matters as much as capability when there is a free plan.

We bring the same thinking to client work: start from the workflow people already have, keep the person responsible in control, and integrate with the systems already in use.