Requirements

Project Goals

The purpose of this project is to create a bot that can efficiently obtain, analyse, and present medical data in a way that is both clear and intelligible. The project's ultimate product will be utilised by professionals such as physicians, doctors and nurses, as well as regular people, such as patients, who need to interpret medical, complex data.

Client Introduction

Who is Infosys?

Infosys is a multinational information technology company that provides business consulting, information technology and outsourcing services. It is the second largest Indian IT company and the 602th largest company in the world according to Forbes Global 2000 ranking. We had the pleasure of working with the institution as they provided us with the necessary support and mentorship in the process of exploring the TaPas model and the vast possibilities it provides.

Infosys initiated the process of developing a question-and-answer bot for clinical tabular data. What sparked the initiative was the release of Google's TaPas model, which is used to get answers from tabular data in a very efficient and accurate manner.

Project Background

Why is a question-and-answer bot for clinical data needed?

When it comes to the amount of information provided as well as the intricacy of the medical reports, they can be daunting. People who work with clinically relevant data would benefit from having a bot that can answer sophisticated, situational, and medical vocabulary based questions.

Doctors and nurses will be able to utilise the tool to swiftly assess specific objectives and how data points connect to one another, whereas patients can get help from the bot in understanding or extracting important information about their reports.

In other words, the end result of the collaboration between Infosys and UCL’s students will be a time-saving tool for effortless retrieving information from complex data sets.

Requirements Gathering

Two types of requirements were involved in our case, which are clients’ requirements and users’ requirements. In order to understand each correctly, we used different approaches as stated below:

Clients Requirement

As part of project initiation, we had our very first meeting with the clients once we gathered all of our team members. In the meeting, we discussed the goals of the project and came up with a MoSCoW requirements list so that we could draw up plans for project management and timeline.


User Requirement

To better understand the user requirements, we decided to conduct interviews with individuals from the target groups. There are two sample responses as shown below, one from a patient and the other a doctor.

Patient Interview Questionnaire

Doctor Interview Questionnaire

Personas

After meeting our client and interviewing the respected target users - medical patients and doctors, we were able to generate the following personas. This meant we could focus on the users, better understand their needs and goals, represent complex data in a compact format and provide a clear vision of a user across the project. This ensures we use a user-centred approach to our systems development.

Patient

Patient Persona Image

Doctor

Use Case

Use Cases

To better illustrate how the user would utilise our bot, we created a use case diagram to clearly state each interaction.

Patient Persona Image

MoSCoW List

To keep track of our progress easily, we agreed on a requirement list with the clients. The final list is shown below after carrying out research and experiments on the project.

Functional Requirements

  1. MUST HAVE
    • Table parsing for semi-structured (tabular) data
    • Natural language processing (NLP/NLU) for table understanding and questioning and answering (QnA)
    • Bot answers clinical-related questions

  2. SHOULD HAVE
    • Bot supports simple, casual chit-chatting
    • Appropriate testing before delivery

  3. COULD HAVE
    • Improved NLP/NLU table-parsing models

  4. WON'T HAVE
    • Image recognition for tables

Non-Functional Requirements

  1. MUST HAVE
    • Bot user interface on web browser

  2. SHOULD HAVE
    • Responsive web design
    • Waterfall dialogue to guide users

  3. COULD HAVE
    • Selected channels support

  4. WON'T HAVE
    • Support for all types of file formats
    • Multi-language