healthdirect Symptom Checker Facebook chat-bot overview

Transcription

1 healthdirect Symptom Checker Facebook chat-bot overview V. 2.0 Atik Zahan 12 th May 2017

2 Contents: Overview Proposed Architecture Example flow Facebook messaging limitations Conclusions

3 Overview: The healthdirect symptom checker provides an interface that tries to recreate the triage process a user would go through with a nurse. To this end it asks for a symptom, some basic information about the user and then a series of questions which lead to a recommended course of action. This back and forth lends itself perfectly to a messenger bot or a conversational interface. By transforming the existing application into a conversation, it should be more engaging to the user and bring the experience closer to a true discussion with a medical professional.

4 Current Architecture: For an app that works with Facebook messenger we require the following: A Facebook account A Facebook page to link the messenger to (Dev and Prd versions) A Facebook app (Dev and Prd versions) An AWS Lambda instance with API Gateway (Dev and Prd stages) Dynamo DB instance to store temporary variables between questions The existing healthdirect Symptom Checker DMS façade API, as used for the App Potentially we may also need to use a third party natural language processing system. Currently handled with regular expressions.

5 Lambda Functions: symptom-checker-chatbot: Handles all messenger logic, this is the main processing part of the chat-bot and includes node dependencies, the main tasks it performs are: Basic NLP, regular expressions to match an entered symptom to a symptom flow Process information like the user s age and gender information to start a session Process answers and respond with the next question in the flow Show buttons for terminology, why are we asking and further information Show the correct disposition with relevant actions, information buttons and reference number Maps to /processmessages in the API Gateway. symptom-checker-chat-htmlparse: A simple HTML parsing function, when a user taps one of the information buttons (terminology, why asking, disposition information, etc.) in the messenger it calls this endpoint and passes information from the DMS payload in query strings that are returned as a web view in the messenger. Maps to /htmlrender in the API Gateway. symptomcheckermessenger-sessionstore: Handles storage of the variables required to start the symptom checker flow while the user enters their age, needed because the symptom is the first thing chosen. POST writes senderid, questionno, scriptid and usersymptom to the database with senderid as the partition key. GET retrieves the information for a supplied senderid. Maps to /sessionstore in the API Gateway and uses the table facebookmessenger-sessionstore in DynamoDB.

6 Example Flow: Welcome screen: Contains the following: header image and logo for the app Name of the app/bot Type of service Personalised welcome message (name is available from Facebook) Clinical warning Get Started button which starts the chatbot Start screen: Contains the following: Personalised welcome message Emoji can be used in messages (if appropriate) Open question to enter symptoms Fixed menu at the bottom User messaging field at the top of the menu

7 Menu screen: For the most part, the menu is now constant while using the messenger: Help: Displays some help text Restart: Shows first message again and prompts user to enter symptoms again Privacy policy: Opens policy in healthdirect site (in app browser or a new tab) Terms of use: Opens terms in healthdirect site (in app browser or a new tab) Help message: Gives user some suggested inputs for various sections of the messenger and the option to call healthdirect if they are struggling.

8 Enter symptom: User enters a symptom, based on keywords the closest symptom flow will be offered to the user. For Fever you could type the following: I am burning up I feel very warm My skin is clammy Similar keywords are set up for: Bites and sting Colds and flus Rashes and skin problems Urinary infections and problems Emergency symptom: For symptoms mentioned in the welcome page warning or serious phrases the user will be immediately directed to call 000, examples are: I think I m having a heart attack I m having difficulty breathing I m bleeding profusely

9 Unrecognised symptom: For symptoms or text entries that do not match any of the regular expression, a default message will be displayed. Selected symptom: When the user taps Start symptom check, they are then asked their age to ask the right questions, their gender has already been provided by Facebook. They could enter their age in several formats: I am years old 18 months Once an age has been entered the symptom flow starts and the user is asked the first question.

10 Why are we asking? If the question has additional information related to why it is being asked then a button with Why are we asking? as the title will be appended to the end of the question bubble. When tapped the information will open in a compact web view.

11 Question terminology: If the question has additional information related to terminology used within the question then a button with Question terms as the title will be appended to the end of the question bubble. When tapped the information will open in a tall web view.

12 Further information: If the question has general further information related to the question then a button with Further info. as the title will be appended to the end of the question bubble. When tapped the information will open in a compact web view.

13 Answer questions: Questions will be asked in a single message bubble up to 640 characters long and then the options will be presented as a row of buttons. When the user taps a button, it will be submitted and the next question will be sent to the user. Questions continued: The answers may just be a simple Yes or No or there may be a more varied range of options. We can also send bullet points for the Prompt lists which are generally a list of symptoms.

14 Disposition: The main section of the disposition is returned in one message bubble truncated at 640 characters. All dispositions will then have a button which is titled Full care info.. This contains the full disposition text, first aid information and self care information (if available). If the user is told to go to a health service, we display a button to open the service finder. They can also call healthdirect, unless the disposition is to call 000 where a button to call 000 would be displayed instead. We also return the reference number in a message. Full care info: All additional disposition information sections are displayed in a tall web view. Full care info contains: Full disposition text First aid information Self care information (if available)

15 General info: If available a General info. Button will be shown which displays more general information on the disposition in a tall web view. Keep watch for: If available a Keep watch for Button will be shown which displays symptoms to watch out for in a tall web view.

16 Service finder: Service finder opens in the in-app browser within messenger, allowing the user to quickly find a service near them. Restart symptom check: Selecting Restart symptom check from the menu will display the clinical warning and then prompt the user to enter a symptom again.

17 Limitations of Messenger UI elements: Symptom Selection: Responses with buttons are limited to 3 options and the text for these options is limited to 30 characters Basic Details: Gender returned automatically, user must provide age. Whether the check is for yourself or someone else and your location are options that may be added later. Questions: Can t go back, no previous question but you can scroll through your previous conversations to see question and answer flows. Markdown and HTML tags cannot be rendered in messages so this needs to be stripped from the Capita responses. To allow more than 3 options for a question we can use quick replies but they are limited to 20 characters, currently many are longer. Dispositions: Messages are limited to 640 characters; many dispositions are longer than this limitation. Tab content returned as web views launched with buttons, however, there is a limitation that you can only have 3 buttons. We have decided on the following 3: o Full care info.: Full disposition text, first aid text and self care information o General information: same as desktop app o Keep watch for: same as desktop app For service finder, there may be an option to share location and see services near you in the future, currently it links to the mobile service finder on the healthdirect website.

18 Conclusion and next steps: The healthdirect symptom checker is certainly a good candidate for a Facebook messenger bot however it is a lot more complex than many messengers currently on the market which deal with a single interaction (eg what is the weather like today, show me some headlines, find events near me, etc). The following considerations should define the experience moving forward: Can we simplify and shorten both questions and answers without risking clinical integrity and without having to completely re-write the symptom flows? (Ada app does a good job of this) Selecting an appropriate tone of voice for the messenger. Potentially expanding the natural language processing capabilities through a 3 rd party service. Handling invalid user input currently there is one default message for all instances. What analytics are available to see drop offs or return visits? What information (if any) does Facebook as a company have access to? Are there any other messenger platforms that would be a good fit?