Back to Top

Implementation

Home → Implementation

PRIDAR Chatbot Implementation

User Authentication and Login

img

Sendgrid was used as part of the authentication system to e-mail the users for verification.

APIs, Tools and Dependencies

Retrieve and update user account details and update user scores.

Used to retrieve information regarding PRIDAR standard as well as posting user queries.

Deployment of the chatbot

Data Visualisation

img

Quickchart is the API used to generate visualisations of user data

Implementation Overview

Key Features

  1. Voiceflow diagram flowchart
  2. Login/Register
  3. Tests
  4. Score check
  5. Viewing resources
  6. Q&A
  7. Use on telegram

Voiceflow implementation overview:

Voiceflow allows developers to design a diagram flowchart for conversations between the user and the chatbot. At each step in the flowchart either a response in the form of texts or choices is sent or customised javascript code can be executed to assist the functionalities of the chatbot as well as being able to make API calls to exchange data with external services.

User Login and Authentication System

1. Upon launching, credentials of all users are extracted from the Airtable database using its API, then users are asked whether they have an account or not, if they do then they are asked to register for an account.

2. Registering for an account requires the user to enter an account name and password. The account name is checked against the existing credentials using a sequential search to make sure it is not in use, an email address is also prompted for password recovery.

The email is verified by generating a random 6 digit number and having it sent to the email address using Sendgrid, The user is prompted to enter the 6 digit code and only if the code matched is the account name, password and email stored in the database using Airtable’s API. 3. Logging in requires the user to enter their account name and password, if the account name does not exist in the database or if the password does not match the account name, users are prompted whether they have an account again. 4. Upon successful completion of either log in or sign up users are then prompted the main menu.

Test Knowledge implementation overview:

  1. Once “Test Knowledge” option is selected, the test questions are loaded through a GET request from jotform and then sorted by subject using a code block.
  2. The resources corresponding to each subject is then loaded through a GET request and sorted by subject using a codeblock.

  3. The questions are iterated through by topic, if the answer to a question in a topic is “No”, then the flowchart redirects the user to questions from the next topic and a score of 0 is recorded for the topic, otherwise the next question from this topic is presented until either questions for this topic has run out or a “No” is recorded.

  4. For each question within a topic, options “Yes”, “No” and “I don’t know” are recorded. If a “Yes” is recorded then a point is added for that topic, if a “No” is answered then the topic is added to the revision list, if a “I don’t know” is answered then either an explanation for the question or for the topic is presented depending on whether an explanation for that topic exists, after which the question is prompted again with only “Yes”, “No” options.

  5. After iteration through each topic is finished the score of that topic is calculated using the score for that topic, difference in scores from the last attempt on the same topic and the size of that topic. After iteration through all topics are completed the total score is calculated by equally weighing each topic score.

  6. The UK average score for each topic is then retrieved using a GET request to Airtable which is used along with the user’s scores to generate a radar graph of the user’s score and the UK averages using Quickchart.

  7. The user’s scores are then uploaded to Airtable overwriting the previously recorded scores using a PATCH request. The new UK averages are then calculated using the number of scores recorded and the new user scores which are then used to update the averages in Airtable using a PUT request.

  8. Users are then asked if they want to view resources for topics they scored 0 in, if so then the resources are iterated through by topic to find ones corresponding to the 0 scoring topics and then presented to the user.

Q&A implementation overview:

  1. If the user chooses the “Ask Question” option, they are prompted to first enter the topic of their question which is length checked to make sure it isn’t too long and then asked to enter their question.

  2. The user’s recorded email together with the topic and question are then added to the Q&A table on Jotform using a POST request.

  3. Clinicians can then collaborate on Jotform to answer the question and email back to user using the email recorded with the question.

Score implementation overview:

  1. If the user chooses the “View Score” option, the UK average scores and the user’s previous score is retrieved from Airtable using a GET request, if there are no stored scores for the user then the user is informed of this.
  2. The number of topics with recorded scores for both the user and the UK average are checked that they are the same, if not the user is prompted to take the test, otherwise a radar graph is generated using a GET request to QuickChart and displayed to the user.

View Resources feature implementation:

If “View Resources” is selected, The resource for each topic is retrieved using a GET request to jotform which are then sorted based on topic and then listed to the user.

Telegram Bot Implementation Overview:

Function name Parameters Functionality
launch message implements API calls to VoiceFlow for first message
sendMsg message implements API calls to VoiceFlow
start message forwards the payload extracted from the response to the user (only implemented when "/start" command is received)
handle_message message forwards the payload extracted from all responses to the user after first message

Click here for documentation.

  1. Running PRIDAR chatbot as a telegram bot
    The PRIDAR chatbot is implemented using Voiceflow and deployed as a telegram bot, which is implemented with a python backend to receive and send messages from telegram. The backend makes https requests to Voiceflow with the received messages using the acquired Voiceflow API key and extracts the response payload to forward back to telegram.
  2. How the PRIDAR chatbot interacts with the user
    The python backend uses the “pyTelegramBotAPI” library together with a generated API key for the telegram bot to initialise a “telebot” instance which is used to handle all incoming messages from the user using two implemented message_handler().
    The first message_handler() is called when the “/start” command is received, which is implemented to call launch() and forwards the payload extracted from the response to the user.
    The second message_handler() is called on all other messages, which is implemented to call sendMsg(). The payload is then extracted from the response and forwarded to the user.
  3. How the backend interacts with Voiceflow
    launch() and sendMsg() implements the API calls to Voiceflow using the message parameter and the generated API key for Voiceflow. Each API call is made with the appropriate type and the message as the payload. The endpoint used also contains the id attribute of the message which is unique to each user so that Voiceflow can track where each user’s state in its diagram flowchart and hence be able to respond with correct message.
  4. How the backend determines the correct Voiceflow API call type
    For each Voiceflow API response that requires a user reponse it is either of text or choice type. The backend uses a type flag to store the type of the latest response, if it is of choice type then all choices and its corresponding request body has to be stored for use in the next API call. When sendMsg() is called it checks the type flag, if it is set to text then the type is set to text and the payload set to the response from the user. If the flag is set to choice then the stored request body matching with the choice is used to make the API call to Voiceflow.