At Pinky Promise, we are transforming women’s healthcare with our AI-powered digital platform, making care accessible, instant, and reliable for women across India.
Here’s how it works: When a patient comes to the Pinky Promise App and describes her symptom, our chatbot-driven system begins by guiding them through an automated symptom triage. These questions are tailored to them based on their symptoms, medical history, dynamic answers, and all necessary information for an accurate diagnosis. Then our system analyses this information to create a suggested diagnosis and prescription for the doctor. In this blog we will focus on the symptom triaging question.
To accomplish this chatbot-style flow, we decided to leverage Google Dialogflow, one of the most widely used platforms for building conversational user experiences. Dialogflow offers advanced capabilities for creating intelligent and responsive virtual agents. It provides robust tools for building chatbots that can handle complex conversations, understand context, and interact with users in natural language. While Dialogflow was our final choice, we evaluated several alternatives before making this decision. The other platforms we considered included:
Microsoft Azure Bot Services (LUIS): A comprehensive solution for building intelligent chatbots, with strong integration into the Microsoft ecosystem and cognitive services.
IBM Watson Assistant: A powerful AI platform with advanced natural language understanding and analytics capabilities, ideal for building complex conversational agents.
Rasa: An open-source, customizable conversational AI platform with machine learning and rule-based dialogue management, best suited for those looking for more flexibility and control.
There were several key reasons we chose Dialogflow over the alternatives:
Integration with Google Cloud
One of the primary reasons we selected Dialogflow was its seamless integration with Google Cloud Platform (GCP). Since all our infrastructure is built on GCP, Dialogflow was a natural choice, allowing us to leverage the platform’s capabilities efficiently without additional complexity. Using Google Cloud services for other aspects of our application (like Firebase functions, hosting, Google Cloud Run for socket based services and Google Analytics for user behavior tracking) made Dialogflow a natural fit for us.
On the other hand, LUIS integrates primarily with Microsoft Azure, and IBM Watson is tied to IBM Cloud. If you are already using these respective platforms, these integrations make sense. However, for us, Google Cloud’s familiarity and ease of use outweighed the other options.
Multilingual Support
India is home to a vast linguistic diversity, with hundreds of languages spoken across the country. To ensure our platform could serve all women, we knew multilingual support would be crucial. Dialogflow, with its strong NLP capabilities, supports a wide range of languages, from widely spoken ones like Hindi and Tamil to more regional languages. Google’s NLP models have been extensively developed and optimized for various languages, which made it a solid choice for catering to a diverse audience in India. While other platforms like LUIS, IBM Watson, and Rasa also offer multilingual support, Dialogflow’s performance and ongoing improvements in NLP aligned well with our requirements.
User-friendly Interface
Another reason we opted for Dialogflow was its user-friendly interface. As a team with varying levels of technical expertise, we found the platform's simplicity and accessibility beneficial. Its graphical interface allows for defining intents (user goals) and entities (specific data) in an intuitive way, making it easier to design and manage conversational flows without extensive programming knowledge. While platforms like LUIS and IBM Watson offer robust features, they often require more setup and technical understanding. Rasa, though highly flexible as an open-source platform, demands greater technical expertise, especially for self-hosting and system management. Dialogflow’s balance of usability and functionality aligned well with our team’s needs.
Seamless Webhooks and Advanced Context Handling
Dialogflow’s built-in support for webhooks was another key feature for us. Webhooks allow easy integration of external APIs during conversation flows, which is essential for passing information between the bot and our medical team. The process is relatively straightforward through Dialogflow’s console, allowing integration of real-time responses like cards, quick replies, and rich media with minimal setup. In comparison, LUIS requires manual integration with services like Azure Functions, which can add complexity. IBM Watson also supports webhooks but involves more configuration steps through Watson Actions. Rasa provides webhook integration via Python-based custom actions, offering flexibility, but requires more coding and setup effort.
Biggest Challenges
The Context Retention Problem
Dialogflow’s default context retention of 30 minutes posed a significant challenge. This meant that if a user took a break during a conversation for more than 30 minutes, they would lose the context, and the conversation could not continue where it left off. Given that our use case involves a series of questions that may take more than 30 minutes to complete, this became a major concern. If patients were unable to resume their conversation after a break, it would result in a higher drop-off rate.
It as only after launching the app that we discovered this context retention issue when patients took breaks longer than 30 minutes. Dialogflow kept returning the message "Something went wrong. Please try again later" whenever users tried to resume the conversation. This became a major pain point, as patients were unable to continue their interactions after taking a break, leading to a higher drop-off rate. We realized that this issue needed to be addressed to ensure a seamless and uninterrupted user experience.
We investigated alternatives, but we found that most platforms, including LUIS, IBM Watson, and Rasa, had similar limitations on context retention. This was a challenge we needed to solve in order to ensure a seamless user experience.
How Dialogflow works :
For each intent, we enabled fulfillment via webhook call. Our backend service differentiates between intents based on the action parameter. Once the intent is identified, we take input from the user and the webhook returns a customized fulfillment response based on the input we get from the user.
Output contexts in Dialogflow are temporary "memory" that helps control the conversation flow. When an intent sets an output context, it stays active for a defined duration (lifespan). Follow-up intents can use this context to ensure they trigger only in the right scenario.
Example:
User: "I want to book a voice consultation."
Intent sets consultation-context as an output context. The webhook creates a consultation of type = “voice” for the patient.
Bot: "What date works for you?"
Follow-up intent checks for consultation-context to set the date for the correct consultation.
Output contexts make multi-step conversations dynamic and maintain context between turns. Dialogflow recognizes the intent to be identified based on the output contexts passed.
Our Solution: Context Persistence via Database
To address the context persistence issue, we devised a solution where we save the output contexts at each intent, along with key parameters (e.g., symptoms, consultation type, slot time, etc.), into a database. We created a new table in our postgres database to store dialogflow responses at each intent. We save the output contexts, the sent fulfillment response and the important parameters, adding a new dialogflow response after each intent. By doing this, we ensured that even if a user returned after 30 minutes or longer, we could retrieve the most recent context data and continue the conversation without any loss of information. This approach allowed us to effectively bypass the limitation of the 30-minute context retention and keep our users engaged.
The Data Parsing Hassle
DialogFlow (just like the other conversation AI services) has a custom json format to store a message with its complete context history. Displaying the text of that message directly to a chat interface is very easy, however, we have built a system which has its own custom json format. Extracting additional information from the DialogFlow json and mapping it to our json involved parsing the entire json and creating that mapping. If you have dealt with large, branching, and deeply-nested jsons, you know that this is an extremely lengthy, time consuming, tedious, and mistake-prone process to do manually.
Our Solution: ChatGPT to the rescue
We built this system a few months into the release of GPT three, and realized very quickly that this is something GPT (yes even GPT 3) excels at. We provided the two json formats, with 2-3 examples in both formats computed manually. GPT3 created the scripts to map one format to the other, and also provided a testing suite that helped us quickly test and verify that this was working correctly in all cases. Through these tests errors were caught, that were manually fed back to GPT and it modified the scripts accordingly. Because of how custom our use-case is, none of these solutions would have worked off the shelf. In a pre-GPT world we may have decided to build our own system, purely to avoid this step. Turns out we didn’t have to!
Conclusion
Choosing Google Dialogflow has been a valuable decision for our application. While there was an initial learning curve, particularly in customizing the platform to meet our unique needs, its flexibility, robust features, and seamless integrations have made it a core component of our digital healthcare app. Dialogflow’s intuitive interface, strong webhook support, and advanced context handling have allowed us to create a dynamic and user-friendly conversational experience, helping us deliver high-quality care to our users.
We’re curious to hear about your experiences with conversational UI platforms. Have you used Dialogflow or explored alternatives? What tools have worked well for you, and how have they supported your use case? If you’d like to discuss implementation challenges, share insights, or compare notes, feel free to reach out—we’d love to learn from your journey and share more about ours.
Comments