Amidst the pandemic, NHS doctors are being overwhelmed by queries from patients with generic problems which can be resolved with generic advice. This is not an efficient use of NHS resources.
To solve this issue, the NHS want to design automated medical advice chatbots. These chatbots should be accessible over SMS in order to reach as many patients as possible. Many chatbot design platforms exist, with Voiceflow being the NHS’s preferred choice. However, none of these platforms support exporting chatbot designs over SMS.
This project creates an ecosystem for designing and deploying SMS chatbots. We provide a standalone desktop application allowing anyone to use a Voiceflow design and publish it as an SMS chatbot behind a real phone number in 3 clicks. Immediately, this chatbot becomes accessible to anyone in the UK.
The above diagram provides a general overview on the context of where we aim to fit in with our application, and the process we’d expect a clinician to take from designing a chatbot to delivering it to their patients.
In the end we expect any trainee clinician to use our user guide, which we will provide to Health Education England, to be able to upload and deploy a chatbot in a few clicks.
This project can help the NHS provide the automated chatbots it needs and make more efficient use of their human resources. In addition, the larger community can benefit from our project in the following ways:
- We design a set of standard formats and APIs that make it easy to expand our solution with more types of input designs and SMS backend services
- We provide two published, documented, and tested open-source software libraries as implementations of these standards
- With these packages, anyone can create their own global SMS bots in 3 lines of code!
- We incorporate 3 types of automated testing - Unit, Integration, End-to-End
Our key project deliverables are elaborated later in this post.
Zvezdin Besarabov, Project Management, Mentoring & Oversight
Thowhid Ahmed, SMS Services & Backend
Michael Khot, Frontend & Testing
The Art of Navigating Uncertainty
If we had to pick one way this project stands out, it would be via uncertainty. It took us roughly 2 months before we had enough evidence even to know what kind of project this is - is it backend heavy, is it a mobile app, is it a website, or something else? What the main job was or the problem it solves was also uncertain. This was because the tools we needed to solve the original client request simply weren’t available. So we had to adapt around that by shifting the project’s goals, developing our own tools, or figuring some other way through.
The reason why we expand on that here is because this project did not flow from “requirements” to “research” to “implementation”. We took an agile approach with many iterations over all these categories. We have done our best to separate our knowledge along these sections but keep in mind that it is definitely not chronologically ordered.
We are happy that in the end, we managed to solve all uncertainty, develop a fully functioning and tested user-friendly application, as well as provide the tools to enable the wider development community to expand it.
Around half of our development time was spent on research and building proof of concept scripts on multiple iterative cycles. The implementation of the different modules making up our end product started around January, with the most exciting contributions to the field taking place in February and March.