Requirements

Background of the Project:


The current method of analysing a cancer patient's holistic health status, and identifying issues and the solutions, is through a form called the Electronic Holistic Needs Assessment. This assessment is given to patients once they check in at the hospital and they fill parts of it out prior to their appointment.


This form can also be filled out through Macmillan's eHNA system, an online form version of the holistic health assessment. This method, however, was not successful: The web form was unintuitive, filling it out took a lot of time, and the quality of data collection was not improved compared to the on-paper holistic needs assessment.


The holistic needs assessment's outcome is a completed table identifying the issues, the summary of discussion, and then the plan of action to improve upon the mentioned issues. In particular, we want to digitalize the London Cancer North and East Holistic Needs Assessment sheet. Our goal is to recreate the table on the second page after the patient talked to the chatbot.


Over the summer, a Masters student worked on this conversational chatbot. While he was able to create the architecture for a chatbot platform, his consideration to use RiveScript (a type of pattern-matching syntax for manually creating messages for chatbots) hinders us from achieving the goal. We found this attempt at a solution to be limited, and didn't actually fit the use cases of the chatbot application. Therefore, we are working on a separate solution fitting to the brief.

Our Client


Our client, Dr. Navin Ramachandran, is a radiologist at UCLH. We meet with our client for approximately 15-20 minutes every week to discuss our progress, issues and our aims for the near future. In addition, we stay in constant contact with him - and the rest of the UCLH peach teams - over the messaging application Ryver.

Problem Statement


Currently, patients provide their holistic health data to their doctor/nurse through a physical flat-structured form. This is slow, tedious and often takes up time in their consultation.


We, and our client, have a vision of digital-only patient consultation, and want to make the first step in this direction. Therefore, we are building a chatbot to automate the process of gathering information from patients via the chatbot. This improves accessibility and efficiency of the data gathering process, and can be extended to or integrated with a universal digital health platform in the future.

Requirement Gathering


Our requirement gathering process was completed through many consultations with our client, as well as further contextual research into the problem we were trying to solve. Concretely, we discussed the state of the art of chatbots with our client, to then form a consensus on feasible functions.


Throughout the project, we iterated on these requirements, and made sure to verify that what we were building has approval of our client.


Additionally, our technical supervisor and a medical student involved in the project gave additional input, which we took into consideration.

MoSCoW Analysis


  • view_listMust Have
    - The user can respond to chatbot messages.
    - The user can see the previous messages the chatbot sent within the current conversation, and their own replies.
    - The user can send and receive messages to/from the chatbot.
    - The bot asks questions about relevant areas of concern (e.g. Physical concerns).
    - The user can indicate the problem areas within each ‘concern bracket’, i.e. each category of concerns (physical, emotional etc.).
    - The system allows questions in multiple formats: Selecting one answer out of many possible, selecting multiple answers (checkboxes). Some questions also require 'free-form' text input by the user.
    - The user can change previously given answers when editing later questions
    - The dialogue model allows the continued dialogue to vary/include more questions depending on user answers.
  • view_listShould Have
    - Integration with the Rocket.Chat messaging platform chosen by the messaging team.
    - The system shall allow retrieval of dialogue information, such that user-entered dialogues can be analysed later, and such that systems can be built that fill out the physical holistic needs assessment form based on user answers.
    - The system shall allow a later system to create APIs and interfaces that allow doctors to 'schedule' a chatbot sessions.
    - The solution is built using continuous integration.
    - Documentation outlining how to set up the system.
    - Documentation outlining use and features of the system.
    - Documentation outlining how future development can be done.
    - API documentation describing parameters and usage.
  • view_listCould Have
    - Use sentiment analysis to assess severity of user concerns.
    - The system shall include an interface for doctors to edit dialogue models.
  • view_listWon't Have
    - The bot does not use text regeneration to respond to user queries.
    - The system does not include a doctor interface such that doctors can view the filled-out forms.
    - The system does not take user input and 'fills in' the existing holistic needs assessment form based on chatbot data.
    - Doctors cannot 'schedule' chatbot sessions via an interface (yet).
    - The system does not have any sort of notification/pop up system.
    - Patients cannot enter questions themselves that the bot answers. The bot is not meant to be a medical encyclopedia.
    - The bot does not use a frame-based system or natural language processing (yet) to infer the user intent and contextual information.

Personas


  • view_listDoctor
  • view_listPatient

Chatbot actors


To fully analyse the use cases of the application we would be developing, we had to understand what the defined actors and systems interacting with the chatbot would be. The diagram below outlines what the key actors are, and the functionality they would interact with the system in order to use. This diagram is a simple pictoral display of the interactions with our system, and this has been used to further expand on the user experience through scenarios and use cases.



Use Case 1
Name Conversation
Description User wishes to provide data previously collected by eHNA or London Holistic Needs Assessment.
Actors Patient
Flow
  1. Patient has an upcoming checkup/appointment with Specialist.
  2. Patient either logs in or gets key to access chatbot/account.
  3. Patient provides data through chatbot- all the data previously collected by EHNA on paper.
  4. Patient logs out/leaves chatbot.
  5. Data is saved where Doctor can access.
Outcome Updated Holistic health information.
Use Case 2
Name Administration
Description Doctor wishes to update the question phrasing or conversation structure for the chatbot.
Actors Doctor
Flow
  1. Doctor needs to update questions, question phrasing or conversation structure for PEACH Chatbot.
  2. Doctor logs into PEACH Messaging Platform, or chatbot admin panel, and can add/delete/change questions and order of questions.
  3. Doctor saves changes, and logs out of admin panel.
  4. Patients who log into PEACH Messaging Platform after changes are made will experienced updated conversation.
Outcome Updated PEACH Chatbot conversation structure or phrasing.
Use Case 3
Name Summary
Description Doctor or medical professional wishes to acquire summary of a patient's holistic health questionnaire answers.
Actors Doctor
Flow
  1. Doctor has an upcoming appointment/checkup with a patient.
  2. Doctor needs to have the up-to-date information and Holistic Health data about the patient.
  3. Doctor logs into PEACH Messaging Platform, or Chatbot admin panel, and finds summary for relevant patient/date/time.
  4. Doctor can view summary and use this appropriately.
Outcome Doctor uses information gathered by the PEACH Chatbot within a consultation/appointment with patient.

Analysis of use cases and the user story in the early stages of this project allowed us to ensure that the project made sense in the correct context. Changes which came about due to this included the movement of the chatbot from an independent site into a component-style implementation. We also cleared up a lot of ambiguous aspects of the project through careful analysis of the context in which this chatbot would be used.


The actors in this main use case scenario is the patient and the chatbot. Our focus is ensuring the best possible experience for the user (the patient), as well as delivering on the functionality needed by doctors and other health professionals involved in this.