Why healthcare needs an engagement layer between consultations and how Tap Health is using AI to personalise chronic-care support Healthcare often works in episodes. A patient visits a doctor, undergoes a test, receives a prescription or care plan, and then returns weeks or months later. But for people living with chronic conditions, much of the outcome is determined not inside the consultation room, but in the days between appointments.
That gap is where Tap Health is positioning its technology.
Rather than building another condition-specific health app or relying primarily on a chatbot, the company describes its core technology as a patient decisioning engine an AI-powered system designed to understand a patient’s ongoing behaviour and determine whether, when and how the system should engage.
The approach is particularly focused on diabetes and obesity, where medication adherence, diet, physical activity, monitoring and follow-up can require sustained engagement over long periods.
In this interview, Tap Health discusses what it believes is missing from the current digital-health experience, how its patient decisioning engine works, the role of memory and personalisation, the challenges of delivering AI-led healthcare without human coaches, and its broader vision for applying the technology across healthcare.
Q. Tap Health calls itself healthcare’s missing engagement layer. What is missing, and why build an engine instead of another condition-management app?
Tap Health: Consider a diabetes patient. They may see their doctor three or four times a year, perhaps for around ten minutes during each consultation. But whether their blood sugar remains under control depends largely on what happens during the weeks and months between those visits.
The same challenge exists across healthcare. A patient gets tested or starts a medicine, and after that they are often largely on their own.
What is missing is not information. Most people with diabetes already know that their blood sugar is high. Many monitor it every day using a glucometer or continuous glucose monitor. They know they should eat better and be more physically active.
The difficult part is doing those things consistently.
That requires something that understands the patient well enough to deliver the right intervention at the right time. Traditional reminders and static care plans cannot do that effectively because they tend to send the same message to everyone.
We did not want to build just another diabetes app. The same engagement problem appears in medication adherence, repeat testing, post-consultation follow-up and almost every chronic condition.
So we started by building a patient decisioning engine. It looks at what we know about an individual patient from their readings and meals to their medicines and how they have responded to us previously. It then determines what that person may need next, when to reach them and, importantly, when not to reach them.
Diabetes is where we have demonstrated the approach, but the diabetes-specific logic sits on top of an underlying engine that can be adapted to different conditions and care pathways.
Q. At the core of Tap Health is a patient decisioning engine. How does it decide whether to step in, what to recommend, when, on which channel, and when to stay silent?
Tap Health: Think of a good coach who knows you well. They do not message you every hour. They notice when something is off and understand whether the situation calls for a text message or a phone call.
That is the approach we have taken with our AI.
For every patient, we maintain a live picture of how they are doing. It gets updated when they log a reading, send a meal photograph, take a medicine or respond to us. The system also remembers how they have interacted with us in the past.
Throughout the day, the engine evaluates that information and asks whether there is something worthwhile to do for that particular person at that particular moment.
Often, the answer is no.
If a patient’s readings are stable and they have logged their breakfast, we may leave them alone. That is intentional. Many health apps assume that more notifications automatically translate into more engagement. Patients quickly learn to ignore notifications when they become repetitive.
When there is a meaningful intervention to make, the engine determines what to communicate and how.
For example, if someone has had a heavy lunch, they may receive a suggestion to take a short walk afterwards because that is when physical activity can be useful for managing the post-meal glucose response.
If someone has stopped logging information, another generic notification may not help. In that situation, our AI coach can call them in their own language and ask how their week has been.
Similarly, someone with knee problems may be offered chair-based exercises rather than being told simply to go for a brisk walk.
The system then observes what happens. Did the patient respond? Did their blood sugar change? That information becomes part of what the system knows for future interactions.
Over time, two patients with the same condition can therefore receive very different forms of engagement based on their individual behaviour and responses.
Q. A lot of health apps have added an AI chatbot in the last two years. What is actually different about what you have built, and what would be hard for someone else to copy?
Tap Health: Anyone can connect an AI model to an application today. The underlying models are increasingly accessible and are becoming less expensive.
That can produce a chatbot that gives useful answers when a patient asks a question. But there is a fundamental problem: people living with diabetes often do not ask questions. Instead, they gradually disengage.
If the product is simply waiting for the patient to initiate the conversation, the system may already have lost them.
The difficult part is everything around the AI model.
The first element is memory. Most chatbots effectively start from scratch when a new conversation begins. Our system is designed to remember the patient across interactions, whether those interactions happen through the app, WhatsApp or a phone call.
For example, if a patient tells the AI coach on Monday that they are travelling for a wedding, the system can retain that context later in the week and combine it with what has happened to their blood sugar in the meantime.
The second element is decision-making. The system needs to determine when to reach out, when to remain silent and what kind of intervention is appropriate for that individual.
Underneath this sits a medical knowledge base and a set of safety checks intended to keep the AI within defined medical limits.
Another important component is the data itself. We have built our own database of Indian food containing more than 5,200 regional recipes.
Food is highly contextual. A plate of dal chawal can look very different from one household to another depending on the amount of rice, the quantity of ghee or oil and the way the food is prepared.
When a meal photograph is unclear, the system can ask questions such as whether ghee or oil was used or whether the person ate two rotis or three.
This level of contextualisation is difficult to achieve using food databases designed primarily around Western packaged foods.
Individually, these components may sound straightforward. The engineering challenge lies in making them work together reliably.
The system also becomes more informed through interactions with patients. Every response and every intervention provides information about what works and what does not.
A chatbot can potentially be built quickly. Building the patient histories, interaction data and accumulated learning that sit around the AI system is a much longer process.
Q. Your diabetes and obesity programmes run without human coaches in the standard care pathway. What have the results been, and what did they prove about the engine?
Tap Health: Our diabetes programme has been live for more than six months, so that is where we currently have the most data.
On average, a patient spends approximately 19 minutes a day with us around seven minutes on the app and 12 minutes on WhatsApp.
About 63% of the messages sent by our AI coach receive a response. We have also seen 73% of users reduce their fasting blood sugar, with an average reduction of approximately 30 mg/dL.
These results have been achieved without a human coach in the standard care pathway.
Removing the human coach is where much of the technical challenge lies. A human coach naturally fills gaps using judgement. When that person is removed, the software has to make those decisions itself.
Patient data is rarely clean or structured. Someone may send a blurry photograph of a glucometer, a picture of a thali containing several different foods, or simply say during a call that their morning sugar was 180.
The system has to interpret that information across languages and formats, while also recognising when it is uncertain and asking for clarification instead of guessing.
Silence is another important signal.
When a patient stops responding, the engine needs to determine whether they are doing well and simply do not need intervention, or whether they may be struggling. It then has to decide whether to wait, send a WhatsApp message or make a phone call.
Information from that interaction needs to flow back into the patient’s experience across the app and WhatsApp so they do not have to repeatedly explain their situation.
Safety is equally important. If no human is reviewing messages before they are sent, medical safety cannot be treated as an afterthought. Safety checks are therefore built into the system, with recommendations operating within defined medical boundaries.
The broader lesson for us is that people are willing to engage with software about their health when they feel the system is actually paying attention to them.
The 63% response rate is particularly meaningful to us because it suggests that personalised engagement can be different from simply sending reminders.
Q. You describe the engine as condition agnostic. Where else can it be used, and what is the larger vision?
Tap Health: Diabetes and obesity already run on the same underlying engine, and we have also built a version for pregnancy.
Adding a new condition requires developing the relevant medical rules and content. The underlying memory, decision-making, communication channels and safety architecture can remain the same.
That means the same approach could potentially support areas such as heart care, women’s health, chronic pain and mental health.
But the larger opportunity goes beyond individual conditions.
Healthcare today is largely organised around visits. A patient sees a doctor or receives a diagnostic test, and then there can be a long gap before the next interaction.
We want to fill that gap.
Anywhere a patient needs to take medication regularly, return for a test, book a follow-up appointment or follow a care plan, an engagement engine can potentially play a role.
Consider a diagnostic laboratory. A patient receives an HbA1c result of 7.8, receives the report, reads it and then does not return for a repeat test three months later.
A patient-engagement engine could turn that single diagnostic interaction into an ongoing care journey explaining what the number means, supporting healthier behaviours, reminding the patient about a repeat test and potentially involving a doctor if the results do not improve.
The pharmaceutical industry faces a similar challenge. A patient may start a medicine but discontinue it after a month or two without informing anyone.
Hospitals face another version of the problem when patients leave with a care plan but there is limited follow-up to understand whether it is actually being followed.
Insurers could potentially use similar technology to identify changes in health behaviour or measurements and support interventions before those issues develop into more serious episodes.
Across these use cases, the underlying challenge is capacity.
Healthcare organisations do not have enough doctors, coaches or care managers to maintain individualised contact with every patient between every visit.
Software can potentially provide that layer of engagement at scale, communicating with one patient in Hindi over WhatsApp and another in English through an app, while determining which patient needs attention today and which one should simply be left alone.
The larger proposition behind Tap Health is therefore not simply another digital health application. It is an attempt to create an intelligent engagement layer that sits between clinical encounters and helps maintain continuity in the patient’s everyday life.
The company’s approach places emphasis on personalisation, memory, contextual decision-making and multiple communication channels rather than relying solely on a conversational AI interface.
Its experience with diabetes and obesity provides the initial testing ground, while the underlying architecture is being positioned for additional conditions and healthcare stakeholders, including diagnostic laboratories, pharmaceutical companies, hospitals and insurers.
For the healthcare sector, the challenge is increasingly shifting from access to information toward sustained engagement and execution. Patients may already have access to reports, advice, medicines and digital tools. The more difficult question is how to help them act consistently between clinical encounters.
Tap Health’s model is built around that gap.
If the approach continues to scale, the company’s broader ambition is to make healthcare engagement more continuous and personalised helping patients navigate the long periods between visits while giving healthcare organisations a technology layer through which they can maintain meaningful contact at scale.
The goal is not to replace the doctor or turn healthcare into a series of automated conversations. Instead, Tap Health is positioning its technology as the layer that keeps patients connected to their care journey when the consultation room is no longer in front of them.