MULTIPURPOSE HEALTHCARE SYSTEM

A PROJECT REPORT

Submitted by

SAAHIL PRADHAN [RA2211003010091]

SHREY JOSHI [RA22110030092]

RUSHIL PRAJAPATI [RA2211003010083]

Under the Guidance of

Dr. Suchithra M
(Associate Professor, Computing Technologies)

in partial fulfillment of the requirements for the degree

of
BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE AND ENGINEERING

DEPARTMENT OF COMPUTING TECHNOLOGIES

COLLEGE OF ENGINEERING AND
TECHNOLOGY
SRM INSTITUTE OF SCIENCE ANDTECHNOLOGY
KATTANKULATHUR- 603 203
MAY 2025

1
 Department of Computing Technologies
SRM Institute of Science & Technology
Own Work* Declaration Form

This sheet must be filled in (each box ticked to show that the condition has been met). It must be
signed and dated along with your student registration number and included with all assignments
you submit – work will not be marked unless this is done.
To be completed by the student for all assessments

Degree/ Course : B. Tech in Computer Science and Engineering.

Student Name : SAAHIL PRADHAN, SHREY JOSHI ,RUSHIL PRAJAPATI

Registration Number : RA2211003010091, RA2211003010092, RA2211003010083

Title of Work : MULTI PURPOSE HEALTHCARE SYSTEM FOR UNIVERSITIES

We hereby certify that this assessment compiles with the University’s Rules and Regulations
relating to Academic misconduct and plagiarism**, as listed in the University Website, Regulations,
and the Education Committee guidelines.

We confirm that all the work contained in this assessment is my / our own except where indicated,
and that We have met the following conditions:

• Clearly referenced / listed all sources as appropriate

• Referenced and put in inverted commas all quoted text (from books, web, etc)
• Given the sources of all pictures, data etc. that are not my own
• Not made any use of the report(s) or essay(s) of any other student(s) either past or present
• Acknowledged in appropriate places any help that I have received from others (e.g.
fellow students, technicians, statisticians, external sources)
• Compiled with any other plagiarism criteria specified in the Course handbook /
University website

We understand that any false claim for this work will be penalized in accordance with the
University policies and regulations.

DECLARATION:
We are aware of and understand the University’s policy on Academic misconduct and plagiarism and we
certify that this assessment is our own work, except where indicated by referring, and that we have
followed the good academic practices noted above.

SAAHIL PRADHAN RUSHIL PRAJAPATI SHREY JOSHI

RA2211003010091 RA2211003010083 RA2211003010092

2
 SRM INSTITUTE OF SCIENCE AND TECHNOLOGY
KATTANKULATHUR – 603 203

BONAFIDE CERTIFICATE
Certified that 21CSC303J – Software Engineering and Project Management report titled
“MULTIPURPOSE HEALTHCARE SYSTEM” is the bonafide work of “SAAHIL
PRADHAN[RA2211003010091], SHREY JOSHI[RA2211003010092], RUSHIL
PRAJAPATI [RA2211003010083]” who carried out the project work under my supervision.
Certified further, that to the best of my knowledge the work reported herein does not form any
other project report or dissertation on the basis of which a degree or award was conferred on
an earlier occasion on this or any other candidate.

SIGNATURE SIGNATURE

DR. SUCHITHRA M DR. NIRANJANA G

ASSOCIATE PROFESSOR PROFESSOR & HEAD
DEPARTMENT OF COMPUTING DEPARTMENT OF
TECHNOLOGIES COMPUTING TECHNOLOGIES
SRMIST KTR SRMIST KTR

3
 ACKNOWLEDGEMENTS

We express our humble gratitude to Dr. C. Muthamizhchelvan, Vice-Chancellor, SRM

Institute of Science and Technology, for the facilities extended for the project work and his
continued support.
We extend our sincere thanks to Dr. Leenus Jesu Martin M, Dean-CET, SRM Institute of
Science and Technology, for his invaluable support.
We wish to thank Dr. Revathi Venkataraman, Professor and Chairperson, School of
Computing, SRM Institute of Science and Technology, for her support throughout the project
work.
We encompass our sincere thanks to, Dr. M. Pushpalatha, Professor and Associate
Chairperson - CS, School of Computing and Dr. Lakshmi, Professor and Associate Chairperson
-AI, School of Computing, SRM Institute of Science and Technology, for their invaluable
support.
We are incredibly grateful to our Head of the Department, Dr. Niranjana G, Professor and
Head, SRM Institute of Science and Technology, for her suggestions and encouragement at all
the stages of the project work.
We register our immeasurable thanks to our Faculty Advisor, Dr. Vanusha D, Department
of Computing Technologies, SRM Institute of Science and Technology, for leading and helping
us to complete our course.
Our inexpressible respect and thanks to our faculty, Dr Suchithra M, Department of
Computing Technologies, SRM Institute of Science and Technology, for providing us with an
opportunity to pursue our project under her mentorship. She provided us with the freedom and
support to explore the research topics of our interest. Her passion for solving problems and
making a difference in the world has always been inspiring.
We sincerely thank all the staff members of Computing Technologies, School of Computing,
S.R.M Institute of Science and Technology, for their help during our project. Finally, we would
like to thank our parents, family members, and friends for their unconditional love, constant
support and encouragement

3
 ABSTRACT

With the rapid digitization of educational and healthcare support systems, the need for

efficient, intelligent platforms is becoming increasingly vital. This project presents the

development of an integrated system combining a Student Leave Management System and a

Medical Chatbot using cutting-edge technologies. The Student Leave Management module,

developed using PHP, enables streamlined handling of student leave applications, approvals, and

notifications, ensuring transparency and reducing administrative overhead. Alongside, a Medical

Chatbot, powered by the Mistral Large Language Model (LLM), has been deployed to assist

users with basic medical inquiries, health advice, and symptom-based guidance, providing instant

support and promoting healthcare awareness. The system features secure user authentication,

real-time leave tracking, chatbot interaction, and admin dashboards for efficient oversight. By

integrating leave management and AI-driven health support within a single platform, this project

significantly enhances operational efficiency, user engagement, and responsiveness in

educational environments. The system's deployment demonstrated a 95% reduction in manual

paperwork, instantaneous chatbot response rates, and seamless cross-module

communication, making it a comprehensive solution for modern academic institutions.

4
 TABLE OF CONTENTS

ABSTRACT 4
TABLE OF CONTENTS 5
LIST OF FIGURES 8
LIST OF TABLES 10
ABBREVIATIONS 11

CHAPTER NO. TITLE PAGE NO.

1 INTRODUCTION 11

1.1 General (Introduction to Project) 12

1.2 Motivation 13
1.3 Sustainable Development Goal of the Project 14
1.4 Product Vision Statement 15
1.5 Product Goal 17
1.6 Product Backlog (Key User Stories with Desired Outcomes) 18
1.7 Product Release Plan 20

2 SPRINT PLANNING AND EXECUTION 21

2.1 Sprint 1 21
2.1.1 Sprint Goal with User Stories of Sprint 1 21

2.1.2 Functional Document 24

2.1.3 Architecture Document 27

2.1.4 UI Design 31

2.1.5 Functional Test Cases 33

2.1.6 Daily Call Progress 34

2.1.7 Committed vs Completed User Stories 35

2.1.8 Sprint Retrospective 36

2.2 Sprint 2 37

5
 2.2.1 Sprint Goal with User Stories of Sprint 2 37

2.2.2 Functional Document 38

2.2.3 Architecture Document 41

2.2.4 UI Design 45

2.2.5 Functional Test Cases 48

2.2.6 Daily Call Progress 49

2.2.7 Committed vs Completed User Stories 50

2.2.8 Sprint Retrospective 51

2.3 Sprint 3 52

2.3.1 Sprint Goal with User Stories of Sprint 3 52

2.3.2 Functional Document 53

2.3.3 Architecture Document 56

2.3.4 UI Design 60

2.3.5 Functional Test Cases 61

2.3.6 Daily Call Progress 62

2.3.7 Committed vs Completed User Stories 63

2.3.8 Sprint Retrospective 64

2.4 Sprint 4 65

2.4.1 Sprint Goal with User Stories of Sprint 4 65

2.4.2 Functional Document 66

2.4.3 Architecture Document 69

2.4.4 UI Design 72

2.4.5 Functional Test Cases 73

2.4.6 Daily Call Progress 74

2.4.7 Committed vs Completed User Stories 75

2.4.8 Sprint Retrospective 76

6
3. RESULTS AND DISCUSSIONS 77

3.1 Project Outcomes (Justification of outcomes and how they align 77

with the goals)

3.2 Committed vs Completed User Stories 80

4 CONCLUSIONS & FUTURE ENHANCEMENT 81

APPENDIX
A. SAMPLE CODING 84

7
 LIST OF FIGURES
CHAPTER NO TITLE PAGE NO.

1 MS Planner Board for Multipurpose healthcare system (Fig 1.1) 19

1 Release plan of multipurpose healthcare system (Fig 1.2) 20

2 User Story for integration module (Fig 2.1) 22

2 User Story for the sprints (Fig 2.2) 22

2 User Story for developing chatbot (Fig 2.3) 23

2 System Architecture Diagram sprint 1 (Fig 2.4) 29

2 Healthcare App UI 1 (Fig 2.5) 31

2 Healthcare App UI 2 (Fig 2.6) 32

2 Standup Meetings sprint 1 (Fig 2.7) 34

2 Bar Graph Committed Vs Completed User Stories - Sprint 1 (Fig 2.8) 35

2 Sprint Retrospective for Sprint 1 (Fig 2.9) 36

2 System Architecture - Sprint 2 (Fig 2.10) 43

2 Student leave management sprint 2 (Fig 2.11) 45

2 Student leave management UI 2 (Fig 2.12) 45

2 Student leave management UI 3 (Fig 2.13) 46

2 Student leave management UI 4 (Fig 2.14) 46

2 Student leave management UI 5 (Fig 2.15) 47

2 Daily Call Progess sprint 2 (Fig 2.16) 49

2 Bar graph for Committed Vs Completed User Stories sprint 2 (Fig 2.17) 50

2 System Architecture sprint 3 (Fig 2.18) 58

2 Chatbot UI (Fig 2.19) 60

8
2 Daily call progress sprint 3 (Fig 2.20) 62

2 Bar graph for completed vs committed sprint 3 (Fig 2.21) 63

2 System Architecture sprint 4 (Fig 2.22) 70

2 Combined UI (Fig 2.23) 72

2 Daily call progress sprint 4 (Fig 2.24) 74

2 Bar graph for completed vs committed sprint 4 (Fig 2.25) 75

3 Bar graph for completed vs committed sprint 1,2,3 and 4 (Fig 3.1) 80

9
 LIST OF TABLES

CHAPTER NO TITLE PAGE NO.

2 Table 2.1 Detailed User Stories of sprint 1 21

2 Table 2.2 Access level Authorization Matrix 26

2 Table 2.3 Detailed Functional Test Case Sprint 1 33

2 Table 2.4 Detailed User Stories of Sprint 2 37

2 Table 2.5 Authorization Matrix Sprint 2 40

2 Table 2.6 Functional Test Case sprint 2 48

2 Table 2.7 Sprint retrospective 2 51

2 Table 2.8 Detailed User Stories of Sprint 3 52

2 Table 2.9 Detailed User Stories of Sprint 3 52

2 Table 2.10 Authorization Matrix Sprint 3 54

2 Table 2.11 Functional test case sprint 3 61

2 Table 2.12 Sprint retrospective sprint 3 64

2 Table 2.13 Detailed User Stories of Sprint 4 65

2 Table 2.14 Authorization Matrix for sprint 4 67

2 Table 2.15 Functional test case sprint 4 73

2 Table 2.16 Sprint retrospective sprint 4 76

10
 ABBREVIATIONS

Abbreviation Full Form

AI Artificial Intelligence

LLM Large Language Model

UI User Interface

PHP Hypertext Processor

UX User experience

API Application Interface Programming

DB Database

OTP One Time Password

ID Identification

SDG Sustainable Development Goals

NLP Natural Language Processing

SQL Structured Query Language

CRUD CREATE, READ, UPDATE, DELETE

SMS Smart Message Service

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

SSL Secure Socket Layers

MVC Model-View-Control

JSON Java Script Object Notation

11
 CHAPTER 1

INTRODUCTION

1.1 Introduction to MULTIPURPOSE HEALTHCARE

SYSTEM:
The proposed system intelligently combines efficient academic management with AI-driven
healthcare support to create a comprehensive and user-centric platform. At its core, the solution
integrates a PHP-based Student Leave Management System with a Medical Chatbot powered by
Mistral LLM, enabling seamless administrative operations alongside instant health assistance.
The leave management module facilitates streamlined leave applications, real-time approval
workflows, and automated notifications, ensuring transparency and efficiency between students,
faculty, and administrative staff. Simultaneously, the integrated Medical Chatbot leverages
advanced natural language processing to offer users symptom-based guidance, general healthcare
information, and wellness recommendations with high accuracy and responsiveness.
Beyond its functional capabilities, the system is designed to enhance user accessibility and
institutional engagement. Through an intuitive web portal, users can submit leave requests,
interact with the chatbot for medical queries, track request statuses, and receive prompt updates
via a unified dashboard. Additionally, the platform promotes health and administrative awareness
by maintaining comprehensive digital records, enabling institutions to analyze trends and
proactively manage student welfare. This combination of automated leave processing, intelligent
medical support, and real-time communication creates a robust and scalable solution for modern
educational environments—empowering students to efficiently manage their academic
responsibilities while fostering a culture of proactive health engagement.

12
1.2 Motivation

The motivation behind this system arises from the growing need to streamline administrative
processes in educational institutions while simultaneously addressing the increasing demand for
accessible healthcare support. Traditional leave management procedures often rely heavily on
manual paperwork, are time-consuming, and prone to errors, leading to inefficiencies and
communication gaps between students, faculty, and administrators. Similarly, access to reliable
medical guidance remains limited, with students often facing difficulties in obtaining quick and
accurate health information, especially in high-pressure academic environments. These
challenges highlight the urgent need for digital platforms that can offer both operational
efficiency and immediate healthcare assistance.
Furthermore, while digital management systems and health technologies have advanced
individually, they often operate in isolation without creating a cohesive support ecosystem for
students. There remains a lack of integrated platforms that can simultaneously address academic
and health-related needs in real time. This project aims to bridge that gap by combining an
automated Student Leave Management System with an AI-powered Medical Chatbot using the
Mistral LLM. By offering seamless leave tracking alongside intelligent health support, the
platform empowers students to manage their academic responsibilities more effectively while
fostering a proactive approach to personal well-being. It reimagines institutional support services
as an interconnected, accessible, and intelligent framework—bringing technology closer to
students’ everyday lives and enabling a healthier, more responsive educational environment.

13
1.3 Sustainable Development Goal of the Project

This project aligns closely with the United Nations' Sustainable Development Goal 3 (SDG 3),
which aims to ensure healthy lives and promote well-being for all at all ages, and Sustainable
Development Goal 4 (SDG 4), which focuses on ensuring inclusive and equitable quality
education and promoting lifelong learning opportunities. By integrating a PHP-based Student
Leave Management System with an AI-powered Medical Chatbot, the platform directly
contributes to creating healthier, more supportive educational environments while improving
administrative efficiency.
The system’s focus on digitalization promotes academic inclusivity by streamlining the leave
application and approval process, reducing bureaucratic hurdles, and ensuring transparent
communication between students and faculty. Simultaneously, the Medical Chatbot component
fosters proactive healthcare management by offering students immediate access to accurate
medical information, wellness tips, and symptom-based guidance. This dual functionality directly
supports SDG 3 by enhancing access to health information and supporting early interventions,
which are critical for maintaining well-being in academic settings.
Furthermore, the project emphasizes the use of technology to build resilient and efficient
institutional systems, promoting digital literacy and innovation among students and
administrators. It empowers educational communities to better manage student welfare and
academic responsibilities, fostering a culture of accountability, wellness, and informed decision-
making. Through this integrated approach, the project supports the broader vision of SDGs 3 and
4 by contributing to healthier students, smarter institutions, and more resilient educational
frameworks that prioritize both academic success and personal well-being.

14
1.4 Product Vision Statement

1.4.1. Audience:

- Primary Audience: Students, faculty, and administrative staff in educational institutions seeking a
streamlined leave management system and accessible healthcare support through intelligent automation.

- Secondary Audience: University administrators, academic policymakers, and healthcare support teams
interested in deploying integrated digital solutions to enhance academic management and student well-being..

1.4.2. Needs:

- Primary Needs:

- A digital leave management system that automates the application, approval, and tracking of student leave
requests.

- An AI-powered Medical Chatbot providing instant health guidance, symptom-based

recommendations, and wellness support

- A unified, secure platform enabling real-time leave status updates and medical query responses through an
intuitive dashboard.

- Secondary Needs:

- Administrative control panels for leave analytics, student health trends, and system oversight.

- Integration capabilities with institutional portals or LMS (Learning Management Systems).

- Mobile-responsive design for accessibility across devices and platforms.

1.4.3. Products:

- Core Product:
An integrated platform combining a PHP-based Student Leave Management System with a
Medical Chatbot driven by the Mistral LLM, offering automated leave workflows and AI-
assisted health support in a unified web environment

- Additional Features:
- Role-based access control for students, faculty, and administrators.

15
 - Instant notifications and email alerts for leave status and chatbot responses.
- Historical logging of leave requests and chatbot interactions for reporting and insights.
- Expandability for future integration with academic performance monitoring or digital health records.

1.4.4. Values:

- Core Values:

- Efficiency: Reducing paperwork and manual errors in leave management, improving operational
workflow.

- Accessibility: Providing students with immediate access to both administrative and

healthcare support.

- Well-being: Promoting proactive health management and wellness engagement among

students.

- Differentiators:

- Dual-Functionality Integration: Seamlessly combining academic and health support into a single
platform.

- AI Intelligence: Leveraging the Mistral LLM for natural language understanding and personalized
medical assistance.

- Scalable Deployment: Designed to be easily implemented across institutions of varying

sizes, adaptable to different academic policies and healthcare needs.

16
1.5 Product Goal

The primary goal of the integrated Student Leave Management and Medical Chatbot system
is to transform how educational institutions manage academic operations and support student
well-being. The platform aims to empower students, faculty, and administrators by providing
an intelligent, unified solution that streamlines leave applications while offering instant
access to reliable healthcare guidance. By automating administrative workflows through a
PHP-based leave management system and embedding an AI-driven Medical Chatbot powered
by the Mistral LLM, the project delivers seamless support for both academic and health needs
in real time.
In addition to enhancing operational efficiency, the system fosters a proactive, health-
conscious campus environment by offering immediate medical insights and accessible leave
tracking. Through a secure and intuitive web interface, users are kept informed of their leave
status, receive health advice, and interact dynamically with the system, promoting both
administrative transparency and personal responsibility. This integrated approach enables
institutions to better support students’ academic journeys while prioritizing their physical and
mental well-being.
Ultimately, the product’s vision is to create a scalable, intelligent, and student-centered
platform that promotes academic success, health awareness, and institutional resilience. By
merging administrative digitalization with AI-powered healthcare assistance, this solution
aspires to set a new standard for educational support services—ensuring that students are
empowered to thrive academically while maintaining a strong focus on holistic well-being.

17
1.6 Product Backlog

S.No User Stories of AI E-Learning Application

#US 1 As a patient, I want to book a doctor’s appointment easily so that I can avoid long waiting
times and get a timely consultation.

#US 2
As a patient, I want to schedule a lab test at my preferred time so that I do not have to wait in
long queues.
#US 3
As a pharmacy customer, I want to pre-order my prescribed medicines so that I can collect them
without waiting in line.
#US 4
As a student, I want to apply for medical leave online so that I can get my leave approved
without unnecessary paperwork.
#US 5
As a teacher, I want to view and approve or reject medical leave applications from students so
that I can efficiently manage class attendance and ensure that students' medical situations are
addressed properly.

#US 6
As an administrator, I want to monitor the status of all medical leave applications so that I can
ensure proper tracking and help resolve any issues.
#US 7 As a patient, I want the chatbot to analyze my symptoms so that I can get a preliminary
assessment before seeing a doctor.

#US 8 As a patient, I want the chatbot to provide first-aid recommendations based on my symptoms
so that I can manage my condition before professional help is available.

#US 9
As a healthcare professional, I want the chatbot to suggest urgent consultations when serious
symptoms are detected so that I can take prompt action for my patients' well-being.
#US 10
As a healthcare professional, I want all the components of the system (appointment booking,
lab test scheduling, pharmacy order, medical leave application, and chatbot) to be integrated so
that I can manage patient interactions and services seamlessly.
#US 11 As a patient, I want to receive confirmation notifications for my booked appointments, lab tests,
pharmacy orders, and medical leave requests so that I am assured that my requests are processed
efficiently.

#US 12 As a student, I want my medical leave status to be automatically updated in the institution's
system once it's approved so that I don’t need to follow up manually.

18
 The product backlog for the Solar-Powered IoT Air Purification and Air Quality Monitoring
System was configured using the MS Planner Agile Board. This backlog encompasses all user
stories related to the system's development, ensuring clarity, traceability, and alignment with
project goals. Each user story is carefully documented with:

• MoSCoW Prioritization: Categorizing each feature into "Must have", "Should have", "Could
have", and "Won’t have".

• Classifications: Dividing requirements into functional (e.g., system operations) and non-
functional (e.g., system performance, user experience) requirements.

• Acceptance Criteria: Specific conditions that define the successful implementation of each
feature.

Additionally, each user story is linked to tasks representing:

• Development Milestones: Key coding and architecture steps.

• Testing Activities: Ensuring functionality and performance.

• Integration Steps: Linking system components and ensuring compatibility.

• Hardware Validation: Ensuring compatibility of physical components like sensors and solar
panels.

Figure 1.1 MS Planner Board for Multipurpose healthcare system

19
1.7 Product Release Plan

The following Figure 1.2 depicts the release plan of the project

Figure 1.2 Release plan of multipurpose healthcare system

20
 CHAPTER 2

SPRINT PLANNING AND EXECUTION

2.1 Sprint 1

2.1.1 Sprint Goal with User Stories of Sprint 1

Implement the basic functionalities for appointment booking, lab test scheduling, and pharmacy
order management.

The following table 2.1 represents the detailed user stories of the sprint 1

Table 2.1 Detailed User Stories of sprint 1

S.NO Detailed User Stories

US #1
As a patient, I want to book a doctor’s appointment easily so that I can avoid long
waiting times and get a timely consultation.

US #2 As a patient, I want to schedule a lab test at my preferred time so that I do not have to
wait in long queues.

US #3
As a pharmacy customer, I want to pre-order my prescribed medicines so that I can
collect them without waiting in line.

21
Planner Board representation of user stories are mentioned below figures 2.1,2.2 and 2.3

Figure 2.1 user story for integration module

Figure 2.2 user story for the sprints

22
Figure 2.3 User story for developing chatbot

23
 2.1.2 Functional Document

2.1.2.1. Introduction

The AI-Enabled Healthcare System project aims to streamline the process of healthcare

management by integrating appointment bookings, lab test scheduling, pharmacy orders, and a

medical leave system into a single platform. Sprint 1 focuses on the fundamental features of the

healthcare system: enabling patients to book doctor appointments, schedule lab tests, and pre-

order their prescribed medications. This sprint serves as the foundation for the chatbot's

functionality and enhances the patient's experience by providing an easy and efficient way to

manage healthcare needs.

2.1.2.2. Product Goal

The primary goal of Sprint 1 is to implement the basic functionality for booking doctor

appointments, scheduling lab tests, and pre-ordering pharmacy medications. By the end of this

sprint, patients will be able to easily book appointments with doctors, schedule lab tests at

convenient times, and pre-order medications for easy pick-up. The features developed in this

sprint aim to reduce wait times, enhance convenience, and improve patient satisfaction.

Key goals for Sprint 1 include:

• Doctor Appointment Booking: Enable patients to schedule appointments with their preferred

doctors.

• Lab Test Scheduling: Provide a system for patients to schedule lab tests without long queues or

delays.

• Pharmacy Medicine Pre-ordering: Allow patients to pre-order prescribed medications,

streamlining the pharmacy collection process.

2.1.2.3. Demography (Users, Location)

• Users:

24
 • Target Users: Patients seeking medical services and pharmacy orders.
• User Characteristics: Patients in need of timely medical consultations, lab tests, or
medication.

• Location:

• Target Location: Urban areas with advanced healthcare infrastructure and access to
digital health services, though the platform aims for a global reach with adaptable
features for different regions.

2.1.2.4. Business Processes

The Key business processes in Sprint 1 include:

• Appointment Booking: Patients will select their preferred doctor and appointment slot.
• Lab Test Scheduling: Patients will choose the lab tests they need and schedule appointments based on real-
time availability.
• Pharmacy Order Processing: Patients will place orders for prescribed medicines, which will be ready for
pick-up at the pharmacy.

2.1.2.5. Features

This project focuses on implementing the following key features:

Feature 1: Doctor Appointment Booking
• Description: The system enables patients to book appointments with doctors through an
easy-to-use interface.
• User Story: As a patient, I want to book a doctor’s appointment easily so that I can avoid
long waiting times and get a timely consultation.
Feature 2: Lab Test Scheduling
• Description: The system allows patients to schedule lab tests at their preferred time,
reducing the need for physical queues and long wait times.
• User Story: As a patient, I want to schedule a lab test at my preferred time so that I do
not have to wait in long queues.
Feature 3: Pharmacy Order Pre-Ordering
• Description: The system allows patients to pre-order their prescribed medicines, enabling
them to collect their medications without waiting in line.
• User Story: As a pharmacy customer, I want to pre-order my prescribed medicines so
that I can collect them without waiting in line.

25
 2.1.2.6. Authorization Matrix

Table 2.2 Access level Authorization Matrix

Role Access Level

Administrator Full access to manage the system settings, user data, and all appointments.
Healthcare
Provider
Access to manage their own schedules, patient data, and appointments within their
(Doctor, Lab
specific domain.
Technician,
Pharmacist)
Patient Limited access to book appointments, schedule tests, and pre-order medications.

2.1.2.7. Assumptions

• The system will be capable of handling simultaneous appointment bookings, lab test scheduling, and
medication orders without performance issues.
• The appointment and lab test scheduling features will integrate real-time availability of doctors and
test slots.
• The pharmacy will have the capacity to fulfill medication orders efficiently within the specified time
frame.
• The platform will adhere to healthcare regulations and ensure patient data is securely handled and
stored.

26
 2.1.3 Architecture Document

2.1.3.1. Application

Microservices:

The AI-Enabled Healthcare Chatbot system follows a modular architecture, leveraging

microservices to ensure flexibility, scalability, and ease of testing. These microservices are
designed to handle specific functionalities within the system. In Sprint 1, the following
microservices are developed or initiated:
1. Appointment Booking Service:
• Purpose: Manages patient appointments, enabling them to book, modify, or cancel doctor
appointments through an intuitive interface.
• Responsibilities:
o Collects patient details and preferred doctor/specialization.
o Provides real-time doctor availability and ensures appointment slots are dynamically
updated.
o Sends confirmation and reminders to patients about their appointments.
2. Lab Test Scheduling Service:
• Purpose: Handles scheduling for lab tests, ensuring patients can choose preferred times based on
real-time test availability.
• Responsibilities:
o Enables patients to schedule lab tests such as blood work or imaging.
o Tracks test availability and synchronizes it with real-time scheduling.
o Sends notifications or reminders to patients about their scheduled tests.
3. Pharmacy Order Management Service:
• Purpose: Allows patients to pre-order prescribed medications, reducing waiting times at the
pharmacy.
• Responsibilities:
o Collects medication details and patient prescriptions.
o Provides real-time inventory checks for the requested medications.
o Sends notifications for prescription availability or collection time at the pharmacy.
4. Notification Service:
• Purpose: Manages the system’s communication with patients regarding appointments, lab tests,
and pharmacy orders.
27
• Responsibilities:
o Sends confirmation, reminders, and follow-up notifications related to appointments, lab
tests, and pharmacy orders.
o Ensures that patients receive timely updates via email, SMS, or in-app messages.

28
 2.1.3.2 System Architecture-

Figure 2.4 System Architecture Diagram sprint 1

2.1.3.3. Data Exchange Contract:

Frequency of Data Exchanges:

Data exchanges between microservices are carefully managed to ensure system performance:
• Real-Time Exchanges: For essential operations like booking appointments, scheduling lab tests, and
confirming pharmacy orders, real-time data exchanges are implemented using RESTful APIs.
• Periodic Syncs: Non-critical data like patient activity logs or appointment history is synchronized at regular
intervals, either through batch processes or scheduled APIs.

Data Sets:

The system exchanges several key datasets, each with specific exchange requirements:
• Patient Data:
o Includes personal details (name, age, contact information) and medical history.
o Exchanged during patient registration, login, and updates to personal details.
• Appointment Data:
o Encompasses details like doctor’s name, date, time, and location.
o Exchanged when booking, modifying, or canceling appointments.
• Lab Test Data:
o Contains test names, scheduling details, and results.
o Exchanged when scheduling lab tests or retrieving test results.
• Pharmacy Order Data:
o Contains medication names, prescribed quantities, and pickup details.
o Exchanged when placing or updating medication orders.
Mode of Exchanges (API, File, Queue, etc.):
Various methods are used to ensure smooth and efficient data exchange between the system components:
• API: RESTful APIs are used for real-time communication between the front-end and the back-end services
(e.g., appointment booking, lab test scheduling).
• Message Queues: Asynchronous tasks like sending notifications or processing background jobs are handled
29
 using message queues such as RabbitMQ or AWS SQS.
• File-Based Exchanges: Bulk data exchanges, such as uploading or downloading medical records, may be
handled using file exchanges through secure file storage systems like Amazon S3.

30
 2.1.4 UI DESIGN

Figure 2.5 Healthcare App UI 1

31
Figure 2.6 Healthcare App UI 2

32
2.1.5 Functional Test Cases

Table 2.3 Detailed Functional Test Case Sprint 1

33
2.1.6 Daily Call Progress

Figure 2.7 Standup meetings sprint 1

34
2.1.7 Committed Vs Completed User Stories

Figure 2.8 Bar graph for Committed Vs Completed User Stories sprint 1

35
2.1.8 Sprint Retrospective

Figure 2.9 Sprint Retrospective for the Sprint 1

36
2.2 SPRINT 2

2.2.1 Sprint Goal with User Stories of Sprint 2

Sprint 2 focuses on developing the core functionality of the Student Leave

Management System within the AI-enabled healthcare platform. This sprint
ensures that students can apply for medical leave online, teachers can efficiently
approve or reject leave applications, and administrators can monitor and manage
all leave activities centrally, reducing paperwork and ensuring a seamless,
transparent process.

Table 2.4 Detailed User Stories of Sprint 2

S.NO Detailed User Stories

As a student, I want to apply for medical leave online so that I can get
US #4
my leave approved without unnecessary paperwork.

As a teacher, I want to view and approve or reject medical leave

US #5 applications from students so that I can efficiently manage class
attendance and ensure that students' medical situations are addressed
properly.
As an administrator, I want to monitor the status of all medical leave
US #6 applications so that I can ensure proper tracking and help resolve any
issues.

37
 2.2.2 Functional Document

2.2.2.1 Introduction

Sprint 2 focuses on developing the core functionality of the Student Leave Management
System within the AI-enabled healthcare platform. This sprint ensures that students can apply
for medical leave online, teachers can efficiently approve or reject leave applications, and
administrators can monitor and manage all leave activities centrally, reducing paperwork and
ensuring a seamless, transparent process.

2.2.2.2 Product Goal

The goal for Sprint 2 is to enhance operational efficiency and user convenience by:
• Enabling students to submit medical leave applications digitally.
• Allowing teachers to approve or reject leave requests based on documentation and context.
• Providing administrators with tools to track, monitor, and audit leave applications
systematically.
• Streamlining leave workflows and minimizing manual interventions.

2.2.2.3 Demography (Users, Location)

• Users:

• Target Users: Students, Teachers, and School/University Administrators.

• User Characteristics: Students seeking convenient application methods,

teachers managing academic schedules, administrators overseeing
institutional attendance records.

• Location:

• Applicable to educational institutions globally, especially where digital management

of student health-related leaves is prioritized.

2.2.2.4 Business Processes

Key Key business processes refined or introduced in Sprint 2 include:

• Student Leave Application: Students can fill out and submit leave requests, optionally attaching medical
certificates.
• Teacher Approval Workflow: Teachers are notified of pending applications and can approve, reject, or
request additional information.
• Administrative Monitoring: Administrators can view the full history and status of all leave applications
across classes or departments.
• Notification System: Students receive updates on their leave request status through email/SMS.

38
2.2.2.5 Features

Feature 1: Online Medical Leave Application

• Description: Students can apply for medical leave via an online form, optionally
uploading supporting documents.

• User Story: As a student, I want to apply for medical leave online so that I can get my
leave approved without unnecessary paperwork.

Feature 2: Teacher Approval/ Rejection Dashboard

• Description: Teachers can view incoming leave requests, review supporting

documents, and approve or reject them efficiently.

• User Story: As a teacher, I want to view and approve or reject medical leave
applications from students so that I can efficiently manage class attendance and ensure
that students' medical situations are addressed properly.

Feature 3: Administrator Monitoring and Reporting

• Description: Administrators can track the flow of leave requests, approval rates, and
rejection patterns for institutional reporting.

• User Story: As an administrator, I want to monitor the status of all medical leave
applications so that I can ensure proper tracking and help resolve any issues.

Feature 4: Notification System

• Description: Real-time notifications inform students about the status of their

application (e.g., approved, rejected, pending clarification).

• User Story: As a student, I want to be notified about my leave status promptly so I can
plan accordingly.

39
 2.2.2.6 Authorization Matrix

Table 2.5 Authorization Matrix Sprint 2

Role Access Level

Full access to all leave applications, reports, student records, and system
Administrator
settings

Access to view, approve/reject student leave applications within their classes

Teacher

Access to submit new applications and track the status of their own leave
Student
requests
2.2.2.7 Assumptions

• Students have valid institutional login credentials to access the system.

• Teachers are assigned to specific students/classes and can only manage those leave applications.
• Internet connectivity is assumed for real-time application submission and notification delivery.
• Privacy and security protocols are strictly followed for medical data and student information.
• System will support file uploads for medical certificates in standard formats (PDF, JPG, PNG).

40
 2.2.3 Architecture Document

2.2.3.1 Application Architecture (Microservices and Services)

The Sprint 2 focuses on developing the core functionality of the Student Leave
Management System within the AI-enabled healthcare platform. This sprint ensures that
students can apply for medical leave online, teachers can efficiently approve or reject leave
applications, and administrators can monitor and manage all leave activities centrally,
reducing paperwork and ensuring a seamless, transparent process.:

• Leave Application Management Service:

o Description: Manages the lifecycle of leave applications from submission to

decision (approved/rejected).

• Responsibilities:

• Allow students to submit new leave applications.

• Notify teachers about pending applications.

• Track status changes and maintain audit logs.

• Teacher Review and Approval Service:

o Description: Enables teachers to review leave applications, view attached

medical documents, and take action.

• Responsibilities:

• Provide an interface for teachers to approve, reject, or request more information.

• Log actions taken on each application.

• Administrative Monitoring and Analytics Service:

41
 o Description: Provides administrators with dashboards and reports to monitor
leave activities institution-wide.

• Responsibilities:

• Generate reports on application volume, approval rates, and trends.

• Monitor unresolved or pending leave cases.

• Notification and Communication Service:

o Description: Sends alerts to students and teachers regarding application

statuses.

o Responsibilities:

▪ Send real-time email/SMS notifications.

▪ Manage notification templates and preferences.

• Dashboard Service (Enhanced UI):

o Description: Displays current and historical leave data in a user-friendly

dashboard.

o Responsibilities:

▪ Present student application status, teacher decision logs, and administrative reports.
▪ Support filtering and search for historical records.

42
2.2.3.2 System Architecture

Fig 2.10: System architecture for sprint 2

2.2.3.3 Data Exchange Contract

In Sprint 2, data exchange processes remain focused on high availability and real-time
communication with periodic synchronizations. However, additional complexity is
introduced with new microservices and data flow.

Frequency of Data Exchanges:

• Real-Time Exchanges:

o Student applications, teacher decisions, and notifications happen instantly through RESTful
APIs.

43
 • Periodic Syncs:

o Administrative reports and dashboards refresh every defined interval (e.g.,

every 15 minutes) to show updated summaries.

Data Sets:

• Leave Application Data: Includes student ID, application reason, attached

documents, and requested leave dates.
• Teacher Review Data: Includes approval/rejection status, comments, and
timestamps.
• Notification Data: Includes email templates, notification triggers, and delivery
status.
• Historical Data: Includes logs of all actions taken on leave applications for audit
purposes.

Mode of Exchanges:

• API:

REST APIs facilitate communication between the Student Portal, Teacher Portal, Admin Dashboard, and
Notification System.

• Message Queues:

Background notifications and batch processing of reports may use message queues like RabbitMQ for load
balancing.

• File-Based Exchanges:

Attached medical documents are securely uploaded to cloud storage (e.g., AWS S3 or Azure Blob Storage)
and linked to applications.

44
2.2.4 UI Design

Fig.2.11 Student leave management sprint 2

FIG. 2.12. Student leave management UI 2

45
FIG. 2.13. Student leave management UI 3

FIG. 2.14. Student leave management UI 4

46
FIG. 2.15 Student leave management UI 5

47
2.2.5 Functional Test Cases

Table 2.6 Functional Test Case sprint 2

48
2.2.6 Daily Call Progress

Fig 2.16. Daily Call Progess sprint 2

49
2.2.7 COMMITTED Vs COMPLETED USER STORIES

Figure 2.17 Bar graph for Committed Vs Completed User Stories sprint 2

50
2.2.8 Sprint Retrospective

Table 2.7Sprint retrospective 2

51
2.3 Sprint 3

2.3.1 Sprint Goal with User Stories of Sprint 3

Implement user collaboration features, advanced system settings, and real-time alerts for
health condition of an individal.

Table 2.9 Detailed User Stories of Sprint 3

S.NO Detailed User Stories

As a patient, I want the chatbot to analyze my symptoms so that I can get a

US #7
preliminary assessment before seeing a doctor.

As a patient, I want the chatbot to provide first-aid recommendations based on my

US #8
symptoms so that I can manage my condition before professional help is available.

As a healthcare professional, I want the chatbot to suggest urgent consultations

US #9
when serious symptoms are detected so that I can take prompt action for my
patients' well-being.

52
 2.3.2 Functional Document

2.3.2.1 Introduction

Sprint 3 focuses on the development of an AI-enabled Medical Chatbot powered by Mistral

LLM. The chatbot aims to assist users by analyzing symptoms, providing preliminary
assessments, offering first-aid recommendations, and suggesting urgent consultations when
necessary. This sprint ensures the healthcare chatbot becomes intelligent, user-friendly, and
responsive to critical health conditions.

2.3.2.2 Product Goal

The goal for Sprint 3 is to build a smart healthcare chatbot that can:
• Analyze patient-reported symptoms to provide preliminary health assessments.
• Offer first-aid recommendations based on symptom analysis.
• Alert users and healthcare professionals in cases requiring urgent medical attention.
• Leverage Mistral LLM to ensure responses are natural, accurate, and contextually appropriate.

2.3.2.3 Demography (Users, Location)

• Users:

• Target Users: Patients, general users seeking health advice, healthcare

professionals.

• User Characteristics: Individuals needing quick health assessments, first

aid advice, or early medical intervention.

• Location:

• Global, with focus on urban and semi-urban populations that have access to
smartphones or computers and require remote healthcare assistance.

2.3.2.4 Business Processes

Key business processes added or refined in Sprint 3 include:

• Symptom Analysis: Capturing user-inputted symptoms and generating

preliminary assessments using Mistral LLM.
• First-Aid Recommendation: Providing appropriate first-aid actions based on
the assessed symptoms.
• Urgency Detection and Alerting: Identifying critical symptoms that require
urgent medical consultation and notifying users accordingly.
• Chat Interaction Management: Ensuring seamless, natural conversation
53
 flow between users and the chatbot.

2.3.2.5 Features

Feature 1: Symptom Analysis and Preliminary Assessment

• Description: The chatbot analyzes symptoms input by patients and provides a

preliminary, non-diagnostic health assessment.

• User Story: As a patient, I want the chatbot to analyze my symptoms so that I can get
a preliminary assessment before seeing a doctor.

Feature 2: First-Aid Recommendations

• Description: The chatbot suggests appropriate first-aid actions based on the nature
of symptoms reported.

• User Story: As a patient, I want the chatbot to provide first-aid recommendations

based on my symptoms so that I can manage my condition before professional help is
available.

Feature 3: Urgent Consultation Alerts

• Description: The chatbot detects symptoms indicating serious health risks and
recommends immediate consultation with a healthcare professional.

• User Story: As a healthcare professional, I want the chatbot to suggest urgent

consultations when serious symptoms are detected so that I can take prompt
action for my patients' well-being.

2.3.2.6 Authorization Matrix

Table 2.10 Authorization Matrix for sprint 3

Role Access Level

Access to symptom analysis, first-aid suggestions, and urgent consultation

Patient
alerts.

Access to patient symptom summaries, alerts, and urgent consultation

Healthcare
Professional recommendations.

54
 Full access to chatbot training data, user management, and system
Administrator
configurations.

2.3.2.7 Assumptions

• Mistral LLM will be fine-tuned or prompted appropriately to handle medical symptom

interpretation responsibly.
• The chatbot will not replace professional medical advice but assist in triaging and
providing supportive first-aid information.
• Users will provide accurate and complete symptom details.
• Privacy and data security protocols will be followed for sensitive user health
information.
• Internet access is assumed for chatbot functionality.

55
2.3.3 Architecture Document

2.3.3.1. Application Architecture (Microservices and Services)

Symptom Intake and Preprocessing Service

• Description: Captures and cleans user-entered symptoms for accurate interpretation.

• Responsibilities:

o Standardize user input.

o Detect and correct common misspellings or ambiguities.
o Forward cleaned inputs to the Mistral LLM engine.

Mistral LLM Medical Response Service

• Description: Core engine that interprets symptoms and generates appropriate

responses.

• Responsibilities:

o Generate preliminary assessments.

o Suggest first-aid steps.
o Classify the urgency level based on symptom patterns.

Urgent Case Detection Service

• Description: Special microservice analyzing outputs to determine if urgent professional attention is
needed.
• Responsibilities:

o Monitor outputs from LLM.

o Trigger alerts or urgent consultation recommendations.

User Interaction Management Service

56
 • Description: Manages conversation flow, session persistence, and
personalization.

• Responsibilities:

o Maintain natural dialogue continuity.

o Personalize suggestions based on user history (if available).

Audit and Privacy Compliance Service

Description: Ensures all user interactions comply with privacy standards (like HIPAA/GDPR).
• Responsibilities:

o Secure data storage and access control.

o Allow users to opt-out or delete their conversation history.

57
2.3.3.2. System Architecture

Fig 2.18 System Architecture sprint 3

58
2.3.3.3. Data Exchange Contract

Sprint 3 introduces more types of data and new exchange patterns.

Frequency of Data Exchanges:

• Real-Time Exchanges:

o Symptom inputs and chatbot responses happen within seconds to maintain real-time
conversation.
o Urgent consultation recommendations are sent immediately upon detection.
• Periodic Syncs:

o Chat history retrieval if the user revisits.

o Administrator-initiated updates to LLM prompts/templates if needed.

59
2.3.4 UI Design

Fig 2.19 Chatbot UI

60
2.3.5 Functional Test Cases

Table 2.11: Functional test case sprint 3

61
2.3.6 Daily Call Progress

Fig 2.20 Daily call progress sprint 3

62
2.3.7 Committed Vs Completed User Stories

Fig 2.21 Bar graph for completed vs committed sprint 3

63
2.3.8 Sprint Retrospective

Table 2.12 Sprint retrospective sprint 3

64
2.4 Sprint 4

2.4.1 Sprint Goal with User Stories of Sprint 3

Implement user collaboration features, advanced system settings.

Table 2.13 Detailed User Stories of Sprint 4

S.NO Detailed User Stories

As a healthcare professional, I want all the components of the system

US #10
(appointment booking, lab test scheduling, pharmacy order, medical leave
application, and chatbot) to be integrated so that I can manage patient interactions
and services seamlessly.

As a patient, I want to receive confirmation notifications for my booked

US #11
appointments, lab tests, pharmacy orders, and medical leave requests so that I am
assured that my requests are processed efficiently.

As a student, I want my medical leave status to be automatically updated in the

US #12
institution's system once it's approved so that I don’t need to follow up manually.
see my sprints the previous one generqate for sprint 1 see my sprint 2 do it for this

65
 2.4.2 Functional Document

2.4.2.1 Introduction

Sprint 4 focuses on the integration and finalization of the AI-enabled Healthcare System,
combining previously developed modules: Lab Test Booking, Doctor Appointment Scheduling,
Pharmacy Orders, Student Medical Leave Management, and the Medical Chatbot powered by
Mistral LLM. This sprint ensures seamless interaction among components, unified user
authentication, centralized data management, and enhanced user experience across services.

2.4.2.2 Product Goal

The goal for Sprint 4 is to:

• Integrate all healthcare modules into a single cohesive platform.
• Enable a unified user interface and authentication system.
• Ensure data sharing and communication between modules (appointments, lab tests, pharmacy, chatbot, and
leave management).
• Finalize and polish user experiences for smooth navigation and interaction.
• Conduct end-to-end testing and deployment preparation.

2.4.2.3 Demography (Users, Location)

• Users:

• Target Users: Patients, Healthcare professions and Students

• User Characteristics: Individuals seeking efficient, AI-assisted healthcare

services.

• Location:

• Global accessibility, primarily targeting urban and semi-urban populations

with internet access.

2.4.2.4 Business Processes

Key business processes added or refined in Sprint 3 include:

• Unified Authentication: Single sign-on (SSO) for all modules.

• Cross-Module Data Sharing: Chatbot recommendations can suggest lab tests
or doctor appointments. Student leave requests can access lab test results if
applicable.
• Centralized Notification System: Users receive integrated notifications for
appointments, pharmacy orders, leave approvals, and chatbot alerts.
66
 • End-to-End Service Workflows: Patients move smoothly across services
(e.g., from chatbot symptom check to booking a doctor).

2.4.2.5 Features

Feature 1: Unified Healthcare Dashboard

• Description: A central dashboard providing access to appointments, lab tests,

pharmacy orders, leave management, and chatbot interactions.

• User Story: As a user, I want to access all healthcare services from one platform so
that I don't need to log in separately for each service.

Feature 2: Chatbot-to-Service Integration

• Description: Recommendations from the Medical Chatbot trigger workflows like

doctor appointments, lab test bookings, or pharmacy orders.

• User Story: As a patient, I want the chatbot to suggest and link me directly to
booking tests or appointments based on my symptoms.

Feature 3: Centralized Notification and Alerts System

• Description: Users receive all system-generated notifications (appointments, lab

orders, leave status, urgent health alerts) in one place.

• User Story: As a user, I want to get all updates in a single notification panel
for easier tracking.

2.4.2.6 Authorization Matrix

Table 2.14 Authorization Matrix for sprint 4

Role Access Level

Full access to appointments, lab tests, pharmacy orders, chatbot services.

Patient

Access to patient requests, lab test results, prescriptions, urgent alerts.

Healthcare
Professional

67
 Full system management, user management, data security controls.
Administrator

Access to medical leave request features and chatbot.

Student

2.4.2.7 Assumptions

• All modules use common authentication and database systems.

• The chatbot is properly integrated with other services.
• Internet connectivity is assumed for real-time interactions.
• Users grant consent for their health data to be shared securely across services.
• Final system testing and user acceptance testing (UAT) will be completed before
deployment.

68
 2.4.3 Architecture Document

2.4.3.1 Application Architecture (Microservices and Services)

Symptom Authentication and User Management Service

• Centralized user authentication and session management across all modules.

Healthcare Workflow Orchestration Service

• Handles linking chatbot outputs to lab test, appointment, and pharmacy workflows.

Notification and Alert Service

• Manages all types of system alerts (appointments, test results, urgent health notifications,
pharmacy order status).

Medical Chatbot Engine (Mistral LLM)

• Remains operational, now connected to booking and ordering systems for actionable
recommendations.

Data Exchange and Synchronization Service

• Ensures smooth, secure data sharing among modules using APIs and event-driven
architecture.

69
2.4.3.2 System Architecture

Fig 2.22 System Architecture sprint 4

70
 2.4.3.3 Data Exchange Contract

Sprint 3 introduces more types of data and new exchange patterns.

Frequency of Data Exchanges:

Real-Time Exchanges:

• Chatbot recommendations instantly push users to booking services.

• Appointment confirmations, pharmacy order status, leave request updates sent

immediately.

Periodic Syncs:

• Daily backups of user interaction data.

• Nightly data sync between modules for redundancy.

On-Demand Exchanges:

• Admin-triggered data audits.

• Users retrieving their appointment, pharmacy, and leave history as needed.

71
2.4.4 UI Design

Fig 2.23 Combined UI

72
2.4.5 Functional Test Cases

Table 2.15: Functional test case sprint 4

73
2.4.6 Daily Call Progress

Fig 2.24 Daily call progress sprint 4

74
2.4.7 Committed Vs Completed User Stories

Fig 2.25 Bar graph for completed vs committed sprint 4

75
2.4.8 Sprint Retrospective

Table 2.16 Sprint retrospective sprint 4

76
 CHAPTER 3

RESULTS AND DISCUSSION

3.1 Project Outcomes

The AI-Enabled Healthcare Chatbot System was successfully designed, developed, and
integrated across all sprints, achieving the primary objectives set at the project's inception. The
major outcomes of the project are summarized below:

3.1.1 Functional Outcomes

• Doctor Appointment and Lab Test Booking:

o Users could seamlessly search, schedule, and manage doctor appointments and lab tests
through the chatbot interface.
o Backend integration ensured real-time fetching of doctor availability and lab test slots.

• Pharmacy Order Management:

o Users could order prescribed medications via the chatbot, which processed orders and
confirmed delivery timelines.

• Symptom Analysis and Health Recommendations:

o The chatbot accurately captured user-reported symptoms and provided preliminary health
assessments.
o AI-driven logic determined when to recommend home care, first-aid, or urgent consultation.

• Student Medical Leave Assistance:

o Students could apply for medical leave through the chatbot, with automated generation of
leave certificates and updates to academic records.

• User Notification and Alerts:

o Users received real-time alerts for critical health symptoms, appointment reminders,
pharmacy order statuses, and leave application updates.

• Dashboard for Admin and Healthcare Staff:

o A unified dashboard provided real-time monitoring of appointments, orders, symptom

assessments, and leave applications.

3.1.2 Microservices Outcomes

• Sensor Symptom Analysis Service reliably evaluated user inputs and provided
appropriate preliminary advice.

77
 • Appointment Management Service handled appointment creation, updates,
and cancellations.
• Pharmacy Order Service processed medicine ordering requests and tracked
order statuses.
• Medical Leave Management Service managed student leave applications and
approvals.
• Notification Service issued health alerts, appointment reminders, and
administrative updates.
• User Session and Authentication Service maintained secure user sessions and
ensured GDPR-compliant data handling.
• Chatbot Core Service handled natural language understanding, context
management, and multi-turn conversations.
(Sprint 3 & 4 Additions):
• AI Symptom Escalation Service intelligently routed severe cases for urgent
consultation.
• Session Continuity and Data Retention Services preserved context across
sessions and supported secure logout and data deletion.
• Analytics and Reporting Service enabled backend administrators to analyze
usage trends and system performance.

3.1.3 Performance Outcomes

• System Responsiveness:

o Chatbot response latency averaged below 1.5 seconds under normal load conditions.
o Session management ensured a smooth conversational flow even across multiple user intents.

• Accuracy and Relevance:

o Symptom analysis achieved over 90% relevance accuracy based on internal validation datasets.
o First-aid and emergency recommendations successfully minimized inappropriate advice
instances.

• Load Handling:

o The microservices architecture scaled horizontally to support concurrent users without

degradation in performance.

3.1.4 Sustainability and Scalability Outcomes

• System Reliability:
78
 o Uptime exceeded 99% during multi-week testing periods, with no major service disruptions.

• Data Privacy and Compliance:

o Data handling fully complied with GDPR and HIPAA guidelines.

o Secure session termination, data retention, and "right to be forgotten" options were
implemented.

• Security Measures:

o Authentication mechanisms, role-based access control for admin interfaces, and encrypted
data transmission were successfully deployed.

3.1.5 Challenges and Limitations

• Complex Symptom Inputs:

o Highly ambiguous or complex symptom descriptions sometimes led to requests for user
clarification.
• Data Connectivity:
o Real-time operations were dependent on stable internet connections, especially for remote
consultations and cloud data sync.
• User Adaptation:
o Some users unfamiliar with chatbot interaction styles initially faced a learning curve in
navigating the platform.

79
3.2 Committed Vs Completed User stories

Fig 3.1 Bar graph for completed vs committed sprint 1,2,3 and 4

80
 CHAPTER 4

CONCLUSION & FUTURE ENHANCEMENTS

4.1 Conclusion

The AI-Enabled Healthcare Chatbot System successfully demonstrates an intelligent, user-

centric approach to healthcare service delivery. By integrating natural language processing
(NLP), microservices architecture, and cloud-based operations, the system efficiently manages
doctor appointments, lab test bookings, pharmacy orders, symptom analysis, and student
medical leave applications.
The chatbot provides real-time symptom assessment, personalized first-aid recommendations,
appointment scheduling, and automated notifications — all accessible through an intuitive
conversational interface. The use of secure data practices ensures user privacy and regulatory
compliance, while backend dashboards support healthcare staff in managing and analyzing
service operations.
The project achieved its key goals of accessibility, responsiveness, automation, and healthcare
workflow optimization. It validates that AI-driven conversational platforms can significantly
enhance healthcare service accessibility and streamline processes without overwhelming
traditional healthcare systems.
Additionally, the project lays the foundation for future AI integration, enabling predictive
health analytics, personalized care, and seamless smart healthcare ecosystems

4.2 Future Enhancements

While the current system meets its primary objectives, several future improvements could
further expand its functionality, impact, and scalability:
• Predictive Health Analytics

Implement machine learning models to predict potential health issues based on user symptoms,
history, and trends, offering proactive healthcare recommendations.

• Expanded Symptom and Condition Database

Continuously update and expand the symptom and disease knowledge base to improve the
chatbot’s diagnostic breadth and precision, including rare and emerging conditions.

81
• Mobile App Integration

Develop dedicated Android/iOS applications to provide enhanced chatbot access, push

notifications, offline access to appointment schedules, and secure health record storage.

• Voice Assistant Integration

Extend chatbot access through popular voice assistants (e.g., Alexa, Google Assistant) to
support hands-free healthcare service interaction.

• Multi-Language Support

Enable the chatbot to support multiple languages to enhance accessibility for non-English-
speaking users, expanding its reach to diverse populations.

• EHR/EMR System Integration

Integrate with existing Electronic Health Record (EHR) and Electronic Medical Record (EMR)
systems to automate clinical data synchronization and streamline healthcare provider
workflows.

• Offline Mode and Local Data Sync

Introduce offline capabilities where users can interact with the chatbot without immediate
internet connectivity, with data synchronization occurring once the device reconnects.

• AI-Driven Personalized Care Plans

Generate personalized health advice and care plans based on user profiles, appointment history,
lab results, and pharmacy interactions.

• Advanced Security Enhancements

Implement advanced security features such as biometric authentication for app access,
blockchain-based data validation, and zero-trust architecture to enhance patient data protection.
82
• Automated Feedback and Learning System

Deploy user feedback loops to continuously improve chatbot responses, UI/UX design, and
healthcare recommendations based on real-world usage.

83
 A. SAMPLE CODING

from langchain_huggingface import HuggingFaceEndpoint

from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS

## Uncomment the following files if you're not using pipenv as your virtual environment manager
#from dotenv import load_dotenv, find_dotenv
#load_dotenv(find_dotenv())

# Step 1: Setup LLM (Mistral with HuggingFace)

HF_TOKEN=os.environ.get("HF_TOKEN")
HUGGINGFACE_REPO_ID="mistralai/Mistral-7B-Instruct-v0.3"

def load_llm(huggingface_repo_id):
llm=HuggingFaceEndpoint(
repo_id=huggingface_repo_id,
temperature=0.5,
model_kwargs={"token":HF_TOKEN,
"max_length":"512"}
)
return llm

# Step 2: Connect LLM with FAISS and Create chain

CUSTOM_PROMPT_TEMPLATE = """
Use the pieces of information provided in the context to answer user's question.
If you dont know the answer, just say that you dont know, dont try to make up an answer.
Dont provide anything out of the given context

Context: {context}
Question: {question}

Start the answer directly. No small talk please.

"""

def set_custom_prompt(custom_prompt_template):
prompt=PromptTemplate(template=custom_prompt_template, input_variables=["context", "question"])
return prompt

# Load Database
DB_FAISS_PATH="vectorstore/db_faiss"
embedding_model=HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
db=FAISS.load_local(DB_FAISS_PATH, embedding_model, allow_dangerous_deserialization=True)

# Create QA chain
qa_chain=RetrievalQA.from_chain_type(
llm=load_llm(HUGGINGFACE_REPO_ID),
chain_type="stuff",
retriever=db.as_retriever(search_kwargs={'k':3}),
84
 return_source_documents=True,
chain_type_kwargs={'prompt':set_custom_prompt(CUSTOM_PROMPT_TEMPLATE)}
)

# Now invoke with a single query

user_query=input("Write Query Here: ")
response=qa_chain.invoke({'query': user_query})
print("RESULT: ", response["result"])
print("SOURCE DOCUMENTS: ", response["source_documents"])

from langchain_community.document_loaders import PyPDFLoader, DirectoryLoader

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS

## Uncomment the following files if you're not using pipenv as your virtual environment manager
#from dotenv import load_dotenv, find_dotenv
#load_dotenv(find_dotenv())

# Step 1: Load raw PDF(s)

DATA_PATH="data/"
def load_pdf_files(data):
loader = DirectoryLoader(data,
glob='*.pdf',
loader_cls=PyPDFLoader)

documents=loader.load()
return documents

documents=load_pdf_files(data=DATA_PATH)
#print("Length of PDF pages: ", len(documents))

# Step 2: Create Chunks

def create_chunks(extracted_data):
text_splitter=RecursiveCharacterTextSplitter(chunk_size=500,
chunk_overlap=50)
text_chunks=text_splitter.split_documents(extracted_data)
return text_chunks

text_chunks=create_chunks(extracted_data=documents)
#print("Length of Text Chunks: ", len(text_chunks))

# Step 3: Create Vector Embeddings

def get_embedding_model():
embedding_model=HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
return embedding_model

embedding_model=get_embedding_model()

# Step 4: Store embeddings in FAISS

DB_FAISS_PATH="vectorstore/db_faiss"
db=FAISS.from_documents(text_chunks, embedding_model)

85
db.save_local(DB_FAISS_PATH)

import os
import streamlit as st

from langchain.embeddings import HuggingFaceEmbeddings

from langchain.chains import RetrievalQA

from langchain_community.vectorstores import FAISS

from langchain_core.prompts import PromptTemplate
from langchain_huggingface import HuggingFaceEndpoint

## Uncomment the following files if you're not using pipenv as your virtual environment manager
#from dotenv import load_dotenv, find_dotenv
#load_dotenv(find_dotenv())

DB_FAISS_PATH="vectorstore/db_faiss"
@st.cache_resource
def get_vectorstore():
embedding_model=HuggingFaceEmbeddings(model_name='sentence-transformers/all-MiniLM-L6-v2')
db=FAISS.load_local(DB_FAISS_PATH, embedding_model, allow_dangerous_deserialization=True)
return db

def set_custom_prompt(custom_prompt_template):
prompt=PromptTemplate(template=custom_prompt_template, input_variables=["context", "question"])
return prompt

def load_llm(huggingface_repo_id, HF_TOKEN):

llm=HuggingFaceEndpoint(
repo_id=huggingface_repo_id,
temperature=0.5,
model_kwargs={"token":HF_TOKEN,
"max_length":"512"}
)
return llm

def main():
st.title("Ask Chatbot!")

if 'messages' not in st.session_state:

st.session_state.messages = []

for message in st.session_state.messages:

st.chat_message(message['role']).markdown(message['content'])

prompt=st.chat_input("Pass your prompt here")

if prompt:
st.chat_message('user').markdown(prompt)
st.session_state.messages.append({'role':'user', 'content': prompt})

CUSTOM_PROMPT_TEMPLATE = """
Use the pieces of information provided in the context to answer user's question.

86
 If you dont know the answer, just say that you dont know, dont try to make up an answer.
Dont provide anything out of the given context

Context: {context}
Question: {question}

Start the answer directly. No small talk please.

"""

HUGGINGFACE_REPO_ID="mistralai/Mistral-7B-Instruct-v0.3"
HF_TOKEN=os.environ.get("HF_TOKEN")

try:
vectorstore=get_vectorstore()
if vectorstore is None:
st.error("Failed to load the vector store")

qa_chain=RetrievalQA.from_chain_type(
llm=load_llm(huggingface_repo_id=HUGGINGFACE_REPO_ID, HF_TOKEN=HF_TOKEN),
chain_type="stuff",
retriever=vectorstore.as_retriever(search_kwargs={'k':3}),
return_source_documents=True,
chain_type_kwargs={'prompt':set_custom_prompt(CUSTOM_PROMPT_TEMPLATE)}
)

response=qa_chain.invoke({'query':prompt})

result=response["result"]
source_documents=response["source_documents"]
result_to_show=result+"\nSource Docs:\n"+str(source_documents)
#response="Hi, I am MediBot!"
st.chat_message('assistant').markdown(result_to_show)
st.session_state.messages.append({'role':'assistant', 'content': result_to_show})

except Exception as e:
st.error(f"Error: {str(e)}")

if __name__ == "__main__":
main()

87
88