.

HAWASSA UNIVERSITY
COLLEGE OF ENGINEERING AND TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: Disease Prediction System

By :
Amanu Seifu
Barnabas Mengesha
Selamawit Tamene

Advisor: Mr. Ayele S.

A Group Project Submitted to Department of Computer Science, College of

Engineering and technology, Hwassa University in meeting the preliminary project
requirement for Partial Fulfillment of Bachelor of Science Degree in Computer
Science.

HAWASSA, ETHIOPIA

MARCH 2024
 Approval letter
This Group Project entitled as “Disease Prediction System ” has been read and approved as meeting the
preliminary project requirements of the Department of Computer Science for partial fulfillment degree of
Bachelor of Science in Computer Science, University of Hawassa, Hawassa, Ethiopia.

Group members name and signature:

Name Signature
1. Amanu Seifu _____________________
2. Barnabas Mengesha _____________________
3. Selamawit Tamene _____________________

I certify that this project satisfies all the requirements as a project for the degree of
Bachelor of Science in Computer science.

Name of advisor: ___________________________________

Date ____________________ Signature _______________

Name of project coordinator: ___________________________________

Date ____________________ Signature _______________

Name of department head: ___________________________________

Date ____________________ Signature _______________

Name of examiner 1: ___________________________________

Date ____________________ Signature _______________

Name of examiner 2: ___________________________________

Date ____________________ Signature _______________

I
 Acknowledgement
First and foremost, our heartfelt appreciation goes to the Almighty God for his mercy and grace which
accompanied us during the development of the proposal as well as the accomplishment of this project.
We would like to express our sincerest thanks to our advisor Mr. Ayele .for his constructive comment and support
in supervising this research proposal starting from title selection.
Furthermore, we would like to thank department of informatics faculty, Hawassa University for giving us the
chance to conduct this study.
Lastly but not least, we want to express our gratitude towards our family and fellow friends for encouragement
during our work on our proposal.

II
Table of contents
Approval Letter……………………………………………………………………………………………I

Acknowledgement…………………………………………………………………II

List of tables…….…………………………………………………………………V

List of figures………………………………………………………………………VI

List of acronyms/abbreviations……………………………………………………VII

Abstract……………………………………………………………………………VIII

CHAPER ONE……………………………………………………………………1

1 INTRODUCTION .........................................................................................1
1.1 Background ............................................................................................................................... 1

1.2 Statement of the problem .......................................................................................................... 2

1.3 objective of the problem ............................................................................................................3

1.3.1 General objectives…………………………………………………………………………………………………………………………..3

1.3.2 Specific objectives……………………………………………………………………………………………………………………………3

1.4. scope of project ........................................................................................................................3

1.5 limitation of project ...................................................................................................................4

1.6 Methdology ............................................................................................................................... 5

1.6.1 Data collection…………………………………………………………………………………………………………………………………5

1.6.2 System Analysis and Design Methodology………………………………………………………………………………………5

1.6.3 System Implementation………………………………………………………………………………………………………………….6

1.6.4 Testing and Deployment Methodology……………………………………………………..7

1.7 Development Environment .......................................................................................................8

1.8System Requirement ..................................................................................................................9

1.9FeasibilityStudy .....................................................................................................................…10
1.9.1 Technical Feasibility .............................................................................................................. 10

1.9.2 Operational Feasibility .......................................................................................................... 10

1.9.3 Economic Feasibility ..............................................................................................................10

III
1.9.4 Cost Estimation and Schedule Breakdown-------------------------------------------------------11

CHAPTER TWO……………………………………………………………….13

2 DESCRIPTION OF EXISTING SYSTEM .................................................. 13

2.1. Introduction to exsiting system ............................................................................................. 13

2.2 Proposedsystem description .................................................................................................... 13

2.3 Strength of existing system…………………………………………………………………..14

2.4 Weakness of existing system…………………………………………....................................15

CHAPTER THREE………………………………………………………………..16

3. SYETEM FEATURES .................................................................................16

3.1 Introduction ............................................................................................................................. 16

3.2 Analysis model ........................................................................................................................17

3.2.1 use case diagram ...................................................................................................................17

3.2.2 Sequence diagram ................................................................................................................ 30

3.2.3 Activity diagram ...................................................................................................................32

3.2.4 Class diagram ....................................................................................................................... 33

3.2.5 User interface design ............................................................................................................34

CHAPTER FOUR………………………………………………………………..41

4.SYSTEM DESIGN…………………………………………………………...41
4.1 Introduction ....................................................................................................................... ….41

4.2 Purpose of the System Design Document .............................................................................. 41

4.3 Scope ....................................................................................................................................... 42

4.4 Architecture design ................................................................................................................. 44

4.4.1 Logic view ......................................................................................................................... 45

4.4.2 Process view ...................................................................................................................... 46

4.4.3 Deployment view ...............................................................................................................47

4.5 Database design .......................................................................................................................48

4.5.1 Coneptual Database design ...............................................................................................49

IV
 4.5.2 ER Diagram ....................................................................................................................... 52

4.5.3 Relational Database design ................................................................................................53

4.5.4 Normalization……………………………………………………………………………………………………………………………….55
CHAPTER FIVE……………………………………………………………………………….59

5. CONCLUSION AND RECOMMENDATION ............................................ 58

5.1 Conclusion ...............................................................................................................................58

5.2 Recommendation .....................................................................................................................58

REFFERENCE……………………………………………………………………………………………………………………………………………59

APPENDIX…………………………………………………………………………………………………………………………………………………62

LIST OF TABLES

TABLE -1---------------------------Cost estimation of the project

TABLE- 2---------------------------Schedule Breakdown

TABLE -3--------------------------- Description of Login use case

TABLE -4---------------------------Description of Add symptoms use case

TABLE- 5---------------------------Description of register use case

TABLE -6---------------------------Description of view symptoms use case

TABLE -7---------------------------Description of change password use case

TABLE -8---------------------------Description of give symptoms use case

TABLE -9--------------------------- Description of change name use case

TABLE -10---------------------------Description of view previous result use case

TABLE -11--------------------------- Description of give feedback use case

TABLE -12--------------------------- Description of analyze questionnaire use case

TABLE -13--------------------------- Patient Table

TABLE -14--------------------------- Symptom Table

V
TABLE -15--------------------------- Disease Table

TABLE -16--------------------------- Feedback Table

TABLE -17--------------------------- Admin Table

TABLE -18--------------------------- Result Table

TABLE -19--------------------------- Un normalized symptom table

TABLE -20--------------------------- symptoms detail

TABLE -21--------------------------- symptoms meta

List of figures

FIGURE-1....................................Use Case Diagram

FIGURE-2....................................Sequence Diagram for user

FIGURE-3.................................... Sequence Diagram for Admin

FIGURE-4....................................Activity Diagram

FIGURE-5....................................Class Diagram

FIGURE-6....................................User Interface Design for the home page

FIGURE-7....................................user interface for the login page

FIGURE-8.................................... User Interface Design for the admin dashboard

FIGURE-9.................................... User Interface Design for the user symptom input

FIGURE-10................................... User Interface Design for the resultpage.

FIGURE-11.................................... User Interface Design for the feedbackt

FIGURE-12....................................Architectural Design

FIGURE-13....................................Logical View

FIGURE-14....................................Process View

FIGURE-15....................................Deployment View

FIGURE-16....................................ER Diagram

VI
List of acronyms/ abbreviations
PHP Hypertext Preprocessor

HTML Hyper Text Markup Language

CSS Cascade Style Sheet

JS Java Script

MYSQL My Structured Query Language

CD Compact Disk

MAC OS Macintosh Operating System

XAMP Cross-platform apache mysql php and perl

WAMP Windows apache mysql and php

UI User Interface

VII
Abstract

This paper presents a disease prediction system developed using PHP programming language. The system utilizes
machine learning algorithms to analyze patient data and predict the likelihood of developing certain diseases. The
system takes into consideration various factors such as medical history, lifestyle choices, and genetic
predisposition to generate accurate predictions. The user-friendly interface allows healthcare professionals to
input patient information and receive real-time predictions, enabling early detection and prevention of diseases.
The system demonstrates promising results in terms of accuracy and efficiency, making it a valuable tool for
improving healthcare outcomes.

VIII
 CHAPTER ONE

1. INTRODUCTION
1.1Background of the study
It may have happened so many times when we or someone we know requires quick medical attention, but they
are not available for any reason. The Health Prediction System is an end-user support and online consultation
initiative that accurately predicts sickness based on patient input. The proposed technology enables users to
receive immediate guidance on their health issues via an intelligent health care system online. The smart health
prediction system is loaded with various symptoms as well as diseases/illnesses related with those systems. The
system allows users to discuss their symptoms and difficulties, and the system then evaluates the patient's
symptoms to look for any illnesses that may be related with them. Here are some sophisticated data mining
strategies for predicting the most likely sickness that could be related with the patient's symptoms.(1)
When someone is currently ill, they must visit a doctor, which is both time-consuming and expensive. It can also
be challenging for users who are not close to doctors and hospitals because the sickness cannot be detected. So, if
the preceding method can be done using automated software that saves time and money.(2)
Disease Predictor is a web-based application that predicts a user's disease based on their symptoms. Data sets
from numerous health-related websites were collected for the Disease Prediction system. illness Predictor will
allow consumers to predict the possibility of an illness based on the symptoms provided. People are constantly
eager to learn new things, especially as the internet becomes more popular by the day. When an issue arises,
individuals frequently want to search it up on the Internet. (2)
The suggested system's goal is to accurately forecast diseases based on users' or patients' symptoms and then
provide prescriptions or treatments, as well as nearby doctors with detailed information. (1)
Patients can seek medical assistance at any time and discuss their condition or health concerns to receive a quick
diagnosis. Doctors may gain more patients online. (1)

Page 1
 1.2Statement of the problem
Nodaway’s in Health Industry there are various problems related to machines or devices which will give wrong
or unaccepted results, so to avoid those results and get the correct and desired results we are building a program
or project which will give the accurate predictions based on information provided by the user and also based on
the data that are available in that machine.[3]
The health industry in information yet and knowledge poor and this industry is very vast industry which has lot of
work to be done. So the problem here is that many people goes to hospitals or clinic to know how is their health
and how much they are improving in the given days, but they have to travel to get to know there answers and
sometimes the patients may or may not get the results based on various factors such as doctor might be on leave
or some whether problem so he might not have come to the hospital and many more reasons will be there so to
avoid all those reasons and confusion we are making a project which will help all those person's and all the
patients who are in need to know the condition of their health, and at sometimes if the person has been observing
few symptoms and he/she is not sure about the disease he/she is encountered with so this will lead to various
diseases in future.[4]
So, to avoid that and get to know the disease in early stages of the symptoms this disease prediction will help a lot
to the various people's ranging from children to teenagers to adults and also the senior citizens.

Page 2
 1.3Objectives of the project
1.3.1 General Objective
The general objective of this project is to develop a web based disease prediction system that predicts the disease
of the patient using all their information’s and the symptoms. (4)

1.3.2 Specific Objective

 Design a disease prediction system that analyzes patient data and accurately predict the likelihood of
developing specific diseases.(5)
 Develop a user-friendly interface for the disease prediction system, allowing users or healthcare
professionals to easily input patient information and receive accurate predictions in real-time.(6)
 Implement a secure database infrastructure to store and manage patient data for the disease prediction
system, ensuring privacy and compliance with data protection regulations.(7)
 Design and implement a feedback mechanism within the disease prediction system, allowing healthcare
professionals to provide updates on patient outcomes to continuously improve the accuracy of future
predictions.[8]
 Design and develop a scalable architecture for the disease prediction system, allowing it to handle large
volumes of patient data efficiently while maintaining high performance levels.(10)
 Implement data privacy measures to ensure the confidentiality of patient information.(11)

1.4 Scope of the study

This study will focus on developing a web-based system to predict the occurrences of disease on the basis of
various symptoms. This system will let users to give symptoms and according to those symptoms, the system will
predict a disease.[12]
It also helps for the urgent guidance on their illness according to the details and symptoms they will feed to the
web-based application.
It also includes:
Data Collection:
 Gather a comprehensive database consisting of medical records, symptoms, and associated diseases.
 Ensure compliance with ethical guidelines and obtain necessary permissions for data collection.
System Architecture:
 Design a scalable architecture that can handle large volumes of patient data efficiently.
 Implement a robust database management system to store and retrieve medical records securely.
 Develop an intuitive user interface for seamless interaction between healthcare professionals and the
system.
Page 3
User Interface Development:
 Design an intuitive graphical user interface (GUI) allowing healthcare professionals to input patient
information easily.
Integration of Medical Database:
 Integrate a comprehensive medical database containing information about various diseases, symptoms,
treatments, medications, etc.
 Ensure seamless connectivity between the prediction system and the database for quick retrieval of
relevant information during diagnosis.
Real-Time Updates:
 Implement real-time monitoring capabilities to track changes in patients' health conditions continuously.

Data Privacy Measures:
 Incorporate robust security measures such as encryption techniques to protect sensitive patient
information from unauthorized access or breaches.

1.5 Limitation of the study

The limitations of this project are:
1. Treatment Recommendations: The scope typically does not include prescribing treatments. The focus is on
predicting disease likelihood rather than providing specific medical advice.
2. Emergency Situations: Excluding acute or emergency medicine predictions, the system focuses on long-term
disease risk rather than immediate patient care.
3. Research Limitations: The scope does not typically encompass extensive medical or pharmaceutical research,
but rather focuses on using existing health data for predictive analytics.
4. Biases and Health Disparities: There is a risk of introducing biases in predictive models, potentially leading
to disparities in disease predictions for different demographic groups, which could impact ethical and equitable
health outcomes.
5. Changing Health Conditions: A disease prediction system may not account for dynamic changes in an
individual's health over time, impacting the system's overall predictive accuracy and continued relevance.

Page 4
1.6 Methodology
1.6.1 Data collection
Interview
This is one of the methods used for the collection of data through direct communication by raising different
questions for Doctors/specialists about health related issue and how the existing system works. It gives us the
chance to raising new issues, asking questions back, collecting qualitative data.
Observation
This is another type of method for collecting data and information in which could witness the actual events which
happen in the organization. To understand system process we collect information by physical observation existing
system. The existing system of most hospitals/clinics in Hawassa is a face to face questionnaire between the
patient and the doctor and has many paper and document that store information.
Document and websites
Data collection has been done from the internet and from written documents to identify the disease here the real
symptoms of the disease are collected i.e. no dummy values are entered. The symptoms of the disease are
collected from different health related websites and documents.

1.6.2 System Analysis and Design Methodology

The system analysis and design methodology for a disease prediction project involves a structured approach to
identifying requirements, formulating a solution, and designing a system that effectively predicts the likelihood of
specific diseases. Here's an outline of the methodology:(13)
 Understanding User Requirements: Gather input from healthcare professionals, researchers, and
stakeholders to understand the specific diseases of interest, the target population, and the desired
functionalities of the disease prediction system.[14]
 Data Collection and Analysis: Identify and collect relevant health data, including demographic
information, medical history, genetic factors, environmental influences, and lifestyle choices, as well as
historical disease outcomes. Analyze the data to identify patterns, correlations, and predictive features.
 Requirement Specification: Document the functional and non-functional requirements of the disease
prediction system, including its user interface, data processing capabilities, predictive algorithms, and
security considerations.
 Use Case Modeling: Develop use case diagrams to capture the interactions between users and the system,
depicting how different actors (e.g., healthcare providers, individuals) will interact with the prediction
system to input data, obtain predictions, and act on the results.

Page 5
  System Architecture Design: Define the overall architecture of the disease prediction system, outlining
the components, modules, and technologies that will be used. Consider the integration of databases and
user interfaces.
 User Interface Design: Design an intuitive and user-friendly interface for inputting data, visualizing
predictions, and accessing personalized health insights. Consider the usability and accessibility of the
interface for both healthcare professionals and individuals.
 Data Security and Privacy Measures: Integrate security protocols and privacy measures to protect
sensitive health data, ensuring compliance with regulatory standards such as HIPAA and GDPR.
 Testing and Validation: Conduct thorough testing to validate the predictive accuracy and performance
of the system. Use techniques such as cross-validation, precision-recall analysis, and receiver operating
characteristic (ROC) curves to assess the model's predictive capabilities.
 Feedback and Iterative Refinement: Gather feedback from users and stakeholders to refine the system,
incorporating improvements based on real-world usage and evolving healthcare needs.
By following this methodology, the system analysis and design process ensures the development of a robust,
accurate, and user-centric disease prediction system that has the potential to positively impact proactive
healthcare and disease prevention strategies.

1.6.3 System Implementation

The system implementation phase of a disease prediction project involves translating the design and requirements
into actual software and technology solutions. Here's an outline of the key steps involved in the system
implementation: (2)
 Software Development Environment Setup: Configure the development environment, including
setting up the programming languages, frameworks, libraries, and integrated development
environments (IDEs) required for implementing the disease prediction system.
 Database Implementation: Create and configure the database system that will store and manage the
health data used for disease prediction. Using MySQL, for example, design and implement the
database schema to efficiently store patient information, medical records, and relevant variables.
 Model Implementation: Develop and implement the predictive models that will be used for disease
prediction. This may involve coding the algorithms in a programming language such as PHP and
training the models on the available health data.
 User Interface Development: Design and develop the user interface for the disease prediction
system. This may include creating web-based interfaces using HTML, CSS, and JavaScript for
accessibility.
 Data Integration and Preprocessing: Integrate the collected health data into the system, preprocess
the data to handle missing values and outliers, and prepare it for use in training the predictive models.
Page 6
  Security and Privacy Measures: Implement security measures to protect sensitive health data,
including encryption, access control, and compliance with privacy regulations such as HIPAA and
GDPR.
 Model Deployment: Deploy the predictive models within the system, ensuring that they can
efficiently generate predictions based on input data.
 Testing and Quality Assurance: Conduct comprehensive testing to validate the functionality,
accuracy, and performance of the disease prediction system. This includes unit testing, integration
testing, and end-to-end testing to ensure that the system operates as intended.
 Documentation and Training Material: Prepare detailed documentation for the implemented system,
including user manuals, technical specifications, and training materials for end users and
administrators.
 Feedback and Iterative Refinement: Gather feedback from users and stakeholders during the
implementation process to identify opportunities for refinement and improvement.
By following these steps, the system implementation phase ensures the successful realization of the disease
prediction system, integrating predictive models with robust user interfaces and secure data management
capabilities.

1.6.4 Testing and Deployment Methodology

The testing and deployment methodology for a disease prediction project involves validating the functionality,
accuracy, and performance of the system components, as well as effectively deploying the system for real-world
use. Here's an outline of the key steps involved in the testing and deployment process:
 Testing Strategy Planning: Develop a comprehensive testing strategy that includes unit testing,
integration testing, system testing, and user acceptance testing. Define the testing objectives, scope,
and success criteria.
 Unit Testing: Conduct unit tests to verify the functionality of individual system components,
including the predictive algorithms, database operations, and user interface elements.
 Integration Testing: Test the integration of different system modules and components, ensuring that
they work together seamlessly and produce the expected results.
 System Testing: Perform end-to-end testing of the entire disease prediction system, including
inputting sample data, verifying predictions, and assessing the system's response to various scenarios.
 Performance Testing: Evaluate the performance of the system under different load conditions,
ensuring that it can handle multiple concurrent users and large datasets without significant degradation
in response times.
 Security Testing: Conduct security assessments to identify vulnerabilities, implement penetration
testing, and ensure that sensitive health data is adequately protected from unauthorized access.
Page 7
  User Acceptance Testing: Engage end users, healthcare professionals, and stakeholders to participate
in user acceptance testing, gathering feedback on the system's usability, accuracy, and relevance to
their needs.
 Validation and Verification: Validate the accuracy and reliability of the predictive models by
comparing their predictions with known outcomes and verifying their alignment with established
medical knowledge.
 Documentation Review: Verify that the system documentation, including user manuals and technical
specifications, accurately represents the implemented system's features and functionalities.
 Deployment Planning: Develop a deployment plan that outlines the steps for rolling out the disease
prediction system into production, including data migration, user training, and system monitoring.
 Release Management: Coordinate the release of the disease prediction system, ensuring that the
deployment process is well-managed, minimizes downtime, and provides sufficient support for end
users.
 Post-Deployment Monitoring: Implement monitoring and logging mechanisms to track the system's
performance in the live environment, identifying any issues and addressing them promptly.
 User Training and Support: Provide training sessions for end users and administrators to familiarize
them with the system's features, interfaces, and best practices for utilization.
 Feedback and Iterative Improvement: Gather post-deployment feedback and usage data to identify
opportunities for refinement, additional features, or enhancements to the disease prediction system.
By following this comprehensive testing and deployment methodology, the disease prediction system can be
deployed with confidence, ensuring its accuracy, reliability, and usability in real-world healthcare settings.

1.7 Development Environment

The development environment for a disease prediction project typically encompasses the tools, frameworks, and
technologies used to build and test the predictive models, manage health data, and develop the user interface.
Here's an overview of the key components of the development environment for a disease prediction project:
Programming Languages and Frameworks
PHP: The scripting language itself. PHP powers the backend logic and dynamic content generation in web
applications. It's crucial for handling form submissions, database access, and more.
It is at the core of any PHP project, providing the server-side logic needed to process HTTP requests and generate
dynamic web pages.
HTML: Client side coding
CSS:For formatting
JavaScript: client side scripting, enabling the creation of responsive and interactive web pages.

Page 8
Integrated Development Environments (IDEs); IDE provides essential features for writing, editing, and
managing the code, such as Visual Studio Code, PHP Storm, or Sublime Text. It also provides essential features
like syntax highlighting, code completion, and project navigation, offering a conducive environment for PHP
code development.

Web Server
Apache: A web server to host PHP web applications, providing the infrastructure to serve PHP scripts and
process HTTP requests.
It serves as the platform for hosting and executing PHP code, delivering web content and supporting the
execution of PHP scripts.
Database Management System
MySQL: Robust open-source relational database management systems suitable for storing and managing health
data.
Web Development Technologies
HTML, CSS, JavaScript: Fundamental web development languages for creating user interfaces and interactive
web applications.

1.8 System Requirement

The system requirements for a disease prediction project encompass the hardware and software specifications
necessary to develop, implement, and maintain the predictive model and associated applications. Here's an outline
of the key system requirements:(15)

1. Hardware Requirements
 Laptop / PC: to perform all the activities concerning to the project.
 Flash : to save and transfer file
 Compact disk(CD):to backup files
 Printer : to print the document

2. Software Requirements
 Operating System: Support for common operating systems such as Windows, mac OS, or Linux,
depending on the development and deployment environment.
 Development Tools: Installation of appropriate programming languages (e.g., PHP) and their respective
libraries, as well as integrated development environments (IDEs) for coding and testing.
 Database Management System: Selection and installation of a suitable database system (e.g., MySQL)
for securely storing and managing health data.

Page 9
  Web Development Tools: If the project includes web-based interfaces, installation of web development
tools, frameworks, and libraries for creating user-friendly interfaces.
 Adobe photo shop :Edit photo
 MS office: For writing documents and presentation
 Web browser: To search different information at the time of doing the system and to run the proposed
system.
 Visual studio (VS code): To write the code
 XAMPP /WAMP server: To make database and make server
 MySQL server : For the Database

1.9 Feasibility Study

In this phase, the project's feasibility is assessed, and a business proposal is presented, along with a very generic
project design and cost estimates. During system analysis, a feasibility evaluation of the proposed system will be
conducted. This is to guarantee that the planned solution does not burden the company. Understanding the
primary system requirements is critical for feasibility analysis.(1)

1.9.1. Operational feasibility

This system can be operated by all users and provides help description to the user about how to use the system.
Accessing and operating on this system software doesn’t require programming knowledge. The users friendly
interact to the system interface and other technical modification on the system is done by the developers. So that
we can say the system is operationally feasible
.
1.9.2. Technical feasibility
The project developed is technically feasible because the system is supported by existing technology and there are
technical guarantees for the system and it provides adequate response to queries made by users and also, the
system have to be developing by using familiar programming language such as PHP, JAVA SCRIPT, CSS and
MYSQL database without any problem. The developers select this software’s because we have enough capability
to use those technologies to develop the project.(16)

1.9.3. Economic Feasibility

Economic feasibility is the measure of cost effectiveness of the project. The system is economically feasible. It
does not require any addition hardware or software. Since the interface for this system is developed using the
existing resources and technologies and also Reduce unnecessary economical wastes in different ways such as
man power, time due to delay of service, financial wastes to copy, but the proposed systems have to be reducing
the amount of time elapsed to do the functionality, man power who operate the work, paper, money and other
resource.
Page 10
1.9.4 Cost Estimation and Schedule Breakdown
Table 1.1: Cost estimation of the project
No item Amount Price per unit Total cost(birr)
(birr)
1. PC 2 18,000 36,000
2. Paper 1pack 720 720
3 Mobile card 5 25 125
4. Print 100page 5 500
5. Flash 1 500 500
6. Transportation 5 40 200
7. Software - - free

38,045birr
Total

Page 11
 Table 1.2: Schedule Breakdown

Dec 30 - Jan 06

Jan 23 - Feb 09
Dec 20 - 27

Feb 12 - 19
Jan 09 - 23
No Project phases

1 Introduction

2 Description of the
Existing System

3
System Features
4
System Design
5
Conclusion

Page 12
 CHAPTER TWO
DESCRIPTION OF EXISTING SYSTEM

2.1 Introduction to the existing system

The Existing system involves a healthcare provider asking patients about their symptoms, medical history, and
conducting a physical examination to determine the possible cause of their illness. This method has been used for
centuries and is still widely practiced today, especially in areas with limited access to advanced medical
technology. The process typically begins with the healthcare provider asking the patient about their chief
complaint and then delving into a detailed history of their present illness. This includes inquiring about the onset
and duration of symptoms, any factors that exacerbate or alleviate the symptoms, and any associated complaints.
The provider may also ask about the patient's medical history, including past illnesses, surgeries, medications,
and family history of certain diseases. Following the history-taking, the healthcare provider performs a physical
examination to assess the patient's overall health. This may involve checking vital signs such as blood pressure,
heart rate, and temperature, as well as examining specific body systems related to the patient's complaints. For
example, if a patient presents with respiratory symptoms, the provider may listen to their lungs and examine their
throat and nose. Based on the information gathered from the patient's history and physical examination, the
healthcare provider formulates a differential diagnosis, which is a list of potential conditions that could be
causing the patient's symptoms. Further diagnostic tests or procedures may be ordered to confirm or rule out these
possibilities.
Disease prediction by asking patients in person relies heavily on the healthcare provider's clinical skills,
experience, and knowledge of common diseases and their presentations. It is a personalized approach that takes
into account the patient's unique circumstances and allows for a thorough evaluation of their health. While
modern medical technology has advanced diagnostic capabilities, existing disease prediction remains an essential
component of healthcare, particularly in primary care settings and in regions where resources are limited.

2.2 Proposed system description

This system supports an end user disease checking. Here propose a framework that enables clients to get moment
direction on their medical problems through an astute social intelligent health care system online. The framework
is fed with different symptoms and the disease or illness associated with those systems. Also the system allows
user to share their symptoms and issues. Through a deep literature survey, it is found that early disease prediction
is the most demanded area of research in health care sector. The basic idea behind the project is to propose a
Page 13
system that allows users to get instant guidance on their health issues. This smart health prediction system is fed
with various symptoms and the disease/illness associated with those systems. This system allows user/patients to
share their symptoms and issues. It then processes patients symptoms to check for various illnesses and based on
input it predict the disease or disorder it feels user’s symptoms are associated with and also suggest to contact
doctor .The system can also customize real data from the predicted disease and dynamically populate the chart
with the actual predicted likelihoods of diseases based on user input. This will help the system to have more
advanced data visualization features.

2.3 Strength of existing system

The system developed offers a robust and reliable solution for predicting potential illnesses based on symptoms,
providing valuable insights to users and helping them make informed decisions about their health.

1. Personalized care: In-person discussions allow healthcare providers to build a personal rapport with patients,
leading to a better understanding of their individual health history and lifestyle, which can contribute to more
accurate disease prediction.
2. Non-verbal cues: Healthcare providers can observe the patient's body language, facial expressions, and other
non-verbal cues that may provide valuable information about their symptoms and overall health.
3. Immediate feedback: Healthcare providers can ask follow-up questions and seek immediate clarification from
patients, leading to a more comprehensive understanding of their symptoms and contributing factors.
4. Patient education: In-person discussions provide an opportunity for healthcare providers to educate patients
about disease symptoms, risk factors, and preventive measures, empowering them to take an active role in their
healthcare.
5. Cultural considerations: In-person interactions allow healthcare providers to consider cultural nuances and
sensitivities when discussing symptoms and potential disease prediction, leading to more culturally competent
care.
6. Enhanced empathy: Face-to-face communication allows healthcare providers to demonstrate empathy and
understanding, which can positively impact the patient's overall experience and willingness to share important
information.

2.4 Weakness of existing system

Clinical decisions are often made based on doctors' intuition and experience rather than on the knowledge rich
data hidden in the database. This practice leads to unwanted biases, errors and excessive medical costs which
affects the quality of service provided to patients. There are many ways that a medical misdiagnosis can present
itself. Whether a doctor is at fault, or hospital staff, a misdiagnosis of a serious illness can have very extreme and
harmful effects.
Page 14
Here are some weaknesses of existing systems:
1. Inaccuracy: Patients may not accurately report their symptoms or may forget to mention certain details,
leading to an inaccurate prediction of the disease.
2. Bias: Patients may feel embarrassed or uncomfortable discussing certain symptoms with their healthcare
provider, leading to a biased prediction.
3. Limited access: Not all patients have access to healthcare providers or may not seek medical attention for
minor symptoms, leading to missed opportunities for disease prediction.
4. Time-consuming: Asking patients in person can be time-consuming for both the patient and the healthcare
provider, which may result in delayed diagnosis and treatment.
5. Language barriers: Patients who do not speak the same language as their healthcare provider may have
difficulty communicating their symptoms accurately, leading to potential misdiagnosis.
6. Privacy concerns: Some patients may be hesitant to disclose personal information in person, leading to a lack
of trust and potentially hindering accurate disease prediction.

Page 15
 CHAPTER THREE

SYETEM FEATURES
3.1 Introduction
Functional Requirements
Functional requirement is the requirement describing the behavior of the system as it relates to the system’s functionality
that describes what the system does.
The functional requirements of a disease prediction system outline the specific capabilities and functionalities necessary for
the system to effectively analyze health data, develop predictive models, and provide valuable insights to support proactive
healthcare management. Here's an outline of the key functional requirements for a disease prediction system:
 User Registration: Users (both medical professionals and individuals) should be able to create accounts and
provide necessary information.
 Input Data Collection: The system should collect and store relevant data, including medical history, genetic
information, and lifestyle details.
 Disease Prediction: Based on the input data, the system should predict the likelihood of various diseases and
provide risk assessment scores.
 Personalized Recommendations: Generate personalized recommendations for preventive measures and
lifestyle modifications based on predicted risks.
 Reporting and Visualization: Provide interactive reports and visualizations of disease predictions and risks for
users and healthcare professionals.

Non-Functional Requirements
Functional requirement describes what a software system should do, while Non-functional requirement is any requirement
which specifies how the system performs a certain function. It will describe how a system should work and what limits
there are on its functionality. Non-functional requirements for a disease prediction system encompass aspects related to
system performance, usability, security, and regulatory compliance. Here's an outline of the key non-functional
requirements for a disease prediction system:

 Performance: The system should provide fast and reliable predictions, ensuring minimal delay in processing.
 Security and Privacy: Ensure data security and privacy compliance in handling sensitive user health information.
 Usability: The user interface should be intuitive, accessible, and user-friendly for both healthcare professionals
and individuals.

Page 16
  Scalability: The system should be able to handle a large volume of user data and adapt to changing user bases.
 Accuracy: The disease prediction model should exhibit high

3.2 Analysis model

Introduction to Analysis Models:
In the field of software engineering and system design, analysis models serve as essential tools for understanding,
documenting, and communicating system requirements and behaviors. These models form a critical part of the early stages
of the software development life cycle, aiding in the visual representation and comprehensive analysis of system
specifications.
The Objectives of having Analysis Models if for:
 Requirement Elicitation: Analysis models are utilized to capture, define, and refine system requirements,
gathering essential insights into user needs and anticipated system functionalities.
 System Understanding: These models contribute to a better understanding of system behaviors, aiding
stakeholders and development teams in comprehending the intricacies of the system and its operational dynamics.
 Visualization and Communication: Analysis models provide a means of visualizing complex system
architectures and interactions, facilitating effective communication and collaboration among project stakeholders.
 Design and Decision Support: They aid in the identification and prioritization of system features and
constraints, contributing to better-informed design decisions and requirement prioritization.

Types of Analysis models:

3.2.1 Use Case Diagram
A use case diagram is a visual representation that helps depict interactions between actors (users or external systems) and
the various use cases (functional requirements) of a system. It is commonly used in the early stages of software
development to provide a high-level overview of system functionalities and interactions.

Key Elements of Use Case Diagrams

Actors:
Actors are entities that interact with the system to achieve specific goals. These can be users, external systems, or other
software applications. Here in our system we have two actors which are patient and admin.
Use Cases:
Use cases represent specific functionalities or actions that the system performs to achieve a particular goal for the user or
actor.
Relationships:
Relationships in a use case diagram illustrate how actors interact with various use cases. These depict the ways in which
actors utilize the system's functionalities to accomplish specific tasks or goals.

Page 17
Figure 3.1: use case diagram

view symptoms
Register

Answer questions
<<include>> S
<<include>> users feedback
patient

<<include>>
Change password <<include>>
<<include>> Add symptoms
<<include>>
<<include>>
Change name LOGIN

<<include>>
<<iinclude>>
View disease
<<include>>
See previous result
<<include>> Admin

<<include>> Add admin

<<include>>
User checkups
<<include>>
<<include>>
Extends <<include>>
View users

See results <<include>>

<<include>> Change name

Give feedback

Admin checkup
LOGOUT

Change password

Add disease

Page 18
Description of use cases
Table 3.1: Description of Login use case
Use case ID SUC-001
Use Case Name Login
Actors User/patient, Admin
Description It allows users to access the system by entering their credentials.
Pre-condition The user must have a valid account in the system and must know their
username and password to access the system.
1.Users navigates to the login page
2.Users enters their user name and password
Normal Flow 3.System verifies the credentials against the database
4.If the credentials are correct, the user is granted access to the
system
Post-condition The user is successfully logged into the system and can access its
features and functionalities.
Alternative Flow 1. If the user enters incorrect credentials, they are prompted to re-enter
their username and password.
2.If the user forgets their password, they can click on a “Forgot
Password” link to reset it.

Page 19
Table 3.2: Description of Add symptoms use case
Use case ID SUC-002
Use Case Name Add Symptoms
Actors Admin
Description It allows administrators to input the new symptoms into the system for
analysis and inclusion in the system’s database.
Pre-condition The admin must be logged into the system and have the necessary
permissions to add new symptoms.
1. Admin navigates to the “Add symptoms” section of the system.
2. Admin inputs the new symptoms into the designated fields.
Normal Flow 3. Admin submits the new symptoms for inclusion in the system’s
database.
4. The system processes the new symptoms and adds them to the
database.
Post-condition The new symptoms are successfully added to the system’s database and
can be used for future disease prediction.
Alternative Flow If the admin is unsure about the classification or relevance of the new
symptoms, they can consult with a medical expert or other admins for
guidance before adding them to the database.

Page 20
Table 3.3: Description of register use case

Use case ID SUC-003

Use Case Name Register

Actors Patient

Description It represents the functionality for registering a new user or entity within
a system.

Pre-condition The user need to accesses the registration interface.

1. The user initiates the registration process by accessing the

registration interface.
Normal Flow 2. The system prompts the user to provide necessary registration
details, such as username, email address, password, and any
additional required information.
3. The user submits the registration form by providing the required
information.
4. The system validates the provided information, checking for
any errors or missing data.
5. If the provided information is valid, the system creates a new
user account and acknowledges successful registration.

Post-condition A new user account is created and added to the system’s database and
the user gains access to the system using the newly created account
credentials.

Page 21
Alternative Flow If the user provided information is incomplete or contains error, the
system prompts the user to correct the issues before proceeding with
registration.

Table 3.4: Description of view symptoms use case

Use case ID SUC-004

Use Case Name View Symptoms
Actors Admin
Description It involves the functionality for the user to access and review
information about medical symptoms within the system.
Pre-condition The user has to be logged into the system and the system need to have a
database of medical symptoms and associated information.
1. The user navigates to the “view symptoms” section within the
system interface.
Normal Flow 2. The system presents a list of available symptoms or allows the
user to search for specific symptoms.
3. The user selects a symptom of interest to view detailed
information related to that symptom, such as common causes,
related conditions, and recommended actions.

Post-condition The user is able to identify the most relatable disease based on the
symptoms he/she inserted.
Alternative Flow If the user cannot find a specific symptom, they may utilize the other
functionality within the system to insert the desired information.

Page 22
Table 3.5: Description of change password use case

Use case ID SUC-005

Use Case Name Change password
Actors Admin
Description It involves the functionality for registered users to modify their existing
system login passwords.
Pre-condition The user must first be logged into the system and the user has to go
through password management section within the system.
1. The user accesses the “change password” section within the
system interface.
Normal Flow 2. The system prompts the user to input their current password,
followed by their desired new password.
3. The user submits the password change request after providing
the required information
4. The system validates the user’s current password and the
strength of the new password based on defined criteria(e.g
length, complexity)
5. If the validation is successful, the system updates the user’s
password and acknowledges the successful password change
operation.

Post-condition The user’s login credentials are updated with the new password,
enabling future access to the system using the modified credentials.
Alternative Flow If the user provided current password is incorrect or the new password
does not meet the specified requirements, the system prompts the user
to rectify the issue before proceeding with the password change
operation.

Page 23
Table 3.6: Description of give symptoms use case

Use case ID SUC-006

Use Case Name Give Symptoms

Actors Patient
Description It involves a user inputting their symptoms into a diagnostic tool to
determine potential health issues and it will also analyze the symptoms
and provide possible causes or conditions that may be related.
Pre-condition The user must have access to a diagnostic tool or platform where they
can input their symptoms.
1. The user enters their symptoms into the diagnostic tool or
platform.
Normal Flow 2. The system analyzes the symptoms and generates potential
health issue suggestions based on the input.
3. The system displays the list of potential health issues to the
user.
4. The user reviews the suggestions and considers seeking medical
advice or further evaluation.

Post-condition The system generates potential health issue suggestions for the user.
Alternative Flow The system uses the detailed information to generate more accurate
health issue suggestions for the user.

Page 24
Table 3.7: Description of change name use case

Use case ID SUC-007

Use Case Name Change name
Actors Patient
Description This use case visually represent the interaction between the user and the
system by allowing an authorized user to change their name in the
system.
Pre-condition The user must be logged into the system and the user must have the
necessary permissions to change their name.

1. User selects the option to change their name.

2. System prompts the user to enter the new name.

Normal Flow

3. User enters the new name.

4. System validates the new name format and permissions.

5. System updates the user's name in the system.

6. Use case ends.

Post-condition The user's name is successfully updated in the system.

Alternative Flow - If the user does not have the necessary permissions to change their
name, an error message is displayed, and the use case ends.
- If the new name format is invalid, the system prompts the user to
enter a valid name format and repeats step 3.

Page 25
Table 3.8: Description of view previous result use case
Use case ID SUC-008
Use Case Name View previous result
Actors Patient
Description This use case visually represent the interaction between the user and the
system by allowing an authorized user to view their previous results or
outcomes in the system.
Pre-condition The user must be logged into the system and the user must have the
necessary permissions to view previous
1. User selects the option to view previous results.
2. System retrieves and displays the user's previous results.
Normal Flow 3. Use case ends.
Post-condition The user successfully views their previous results.
Alternative Flow If the user does not have the necessary permissions to view previous
results, an error message is displayed, and the use case ends.

Page 26
Table 3.9: Description of give feedback use case

Use case ID SUC-009

Use Case Name Give feedback
Actors Patient
Description This use case allows a user to provide feedback on their experience
with the system or a specific feature.
Pre-condition The user must be logged into the system and the user must have access
to the feedback feature.

1. User navigates to the feedback section.

2. User selects the option to provide feedback.
Normal Flow 3. User writes their feedback in the provided text box.
4. User submits the feedback.
5. System records the feedback.
6. Use case ends.
Post-condition The user successfully submits their feedback.
Alternative Flow If the user does not submit any feedback and exits the feedback section,
the use case ends without recording any feedback.

Page 27
Table 3.10: Description of analyze questionnaire use case

Use case ID SUC-010

Use Case Name Analyze questionnaires
Actors Patient
Description This use case allows a user to input their responses to a questionnaire
for analysis.
Pre-condition The user must be logged into the system and the user must have access
to the questionnaire response input feature.

1. User navigates to the questionnaire response input section.

2. User selects the option to input their responses.
Normal Flow 3. User fills out the questionnaire with their responses.
4. User submits the completed questionnaire.
5. System records the questionnaire responses.
6. System analyzes the responses for insights or recommendations.
7. Use case ends.

Post-condition The user successfully submits their questionnaire responses.

Alternative Flow If the user does not complete the questionnaire and exits the response
input section, the use case ends without recording any information.

Page 28
Table 3.11: Description of see result use case

Use case ID SUC-011

Use Case Name See result
Actors Patient
Description This use case allows a user to input their responses to a questionnaire
for analysis.
Pre-condition The user must be logged into the system and the user must have
previously submitted a questionnaire for analysis.
1. User navigates to the section displaying questionnaire analysis
results.
Normal Flow 2. User selects the option to view their specific analysis results.
3. System retrieves and displays the analysis results of the user's
questionnaire responses.
4. User reviews the analysis results and any insights or
recommendations provided.
5. Use case ends.

Post-condition The user successfully views the analysis results of their questionnaire.
Alternative Flow If the user does not have any submitted questionnaires for analysis,
they will be prompted to submit a questionnaire first before viewing
analysis results.

Page 29
3.2.2 Sequence diagram
Sequence diagrams in UML shows how object interact with each other and the order those interactions
occur. It’s important to note that they show the interactions for a particular scenario. The processes are
represented vertically and interactions are show as arrows. This article explains the purpose and the basics
of Sequence diagrams.

Figure 3.2: Sequence diagram for user

Page 30
Figure 3.3: sequence diagram for Admin

Page 31
3.2.3 Activity diagram
Activity diagrams describe the work flow behavior of a system. Activity diagrams are similar to state
diagrams because activities are the state of doing something. The diagrams describe the state of activities
by showing the sequence of activities performed. Activity diagrams can show activities that are
conditional or parallel.
Figure 3.4: Activity diagram START

Signup/Login

Authentication

Valid

Dash board

Users collection of
data and symptoms

Check collection of
data is valid

Yes

Analyze and disease

prediction

Feedback

STOP
Page 32
3.2.4 Class diagram
Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such as
classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. These perspectives become
evident as the diagram is created and help solidify the design. Class diagrams are arguably the
most used UML diagram type. It is the main building block of any object oriented solution. It
shows the classes in a system, attributes and operations of each class and the relationship
between each class. In most modeling tools a class has three parts, name at the top, attributes in
the middle and operations or methods at the bottom. In large systems with many classes related
classes are grouped together to create class diagrams.
Fig3.4 Class diagram

Page 33
3.2.5 User Interface Design

Prototyping, which is a stage in interface design with the singular aim of meeting the usability
goal of the product, is an iterative design process that involves creating a simplified version of a
product or system. The purpose of prototyping is to test and refine the design solution before
investing time and money into development. By creating a prototype, designers can evaluate the
usability, functionality, and overall user experience of their design solution.
The user interface design for a disease prediction system should prioritize ease of use,
accessibility, and the effective communication of predictive insights to both healthcare
professionals and individuals. Here's an outline of considerations and features for the user
interface design:
 Clean and Intuitive Layout: The user interface should feature a clean and intuitive
layout, with well-organized menus, navigation elements, and visual hierarchy to guide
users through the system.
 Dashboard Overview: A dashboard providing an overview of key insights, recent
predictions, and personalized risk assessments can serve as the central hub for users to
access relevant information at a glance.
 Data Input Forms: Clear and concise forms for inputting health data, allowing users to
provide essential information such as patient demographics, medical history, genetic
factors, lifestyle choices, and other relevant variables for predictive modeling.
 Accessibility Considerations: Adherence to accessibility standards and best practices to
ensure that the user interface is accessible to individuals with diverse needs, potentially
including support for assistive technologies and adherence to accessibility guidelines.
By incorporating these features into the user interface design, the disease prediction system can
provide an engaging, informative, and user-friendly experience, supporting proactive health
management and facilitating the effective utilization of predictive insights in healthcare decision-
making.

Page 34
Figure 3.5 user interface for the home page

Page 35
Figure 3.6 user interface for the login page

Page 36
Figure 3.7 user interface for the Admin dashboard

Page 37
Figure 3.8 user interface for the users symptom input

Page 38
Figure 3.9 user interface for the result page

Page 39
Figure 3.10 User interface for the feedback

The above UI prototype demonstrates a product's design and functionality to stakeholders, clients,
and potential users. A prototype gives stakeholders a better understanding of how users interact
with the product, website, or application while it's in the design and development process. It
allows user to fail fast and iterate quickly, ultimately leading to a better end result.

Page 40
CHAPTER FOUR

SYSTEM DESIGN

4.1INTRODUCTION
The disease prediction system project aims to develop a software application that can predict the
likelihood of an individual developing a certain disease based on the symptoms given by the
users.(17) The system will have a user-friendly interface that allows healthcare professionals to
input patient data, view predictions, and make informed decisions about treatment and
prevention strategies. The system will also have the capability to generate reports and
visualizations to help users understand the reasoning behind the predictions.
Overall, the disease prediction system project seeks to improve healthcare outcomes by enabling
early detection and intervention for individuals at risk of developing certain diseases.

4.2 Purpose of the System Design Document (SDD)

The System Design Document (SDD) serves as a comprehensive guide for the development team
working on the disease prediction system project. It outlines the overall architecture of the
system, including its components, interfaces, and interactions.
The SDD also details the design decisions that have been made throughout the development
process and provides rationale for those decisions.(18)
The SDD serves as a reference document for stakeholders who need to understand how the
system works and how it will be implemented. It provides a road map for future development
efforts and helps ensure that all team members are aligned on the project goals and objectives.
Here are some key purposes of the System Design Document for a disease prediction system
using PHP:
 Detailed System Architecture: The SDD describes the overall architecture of the
system, including the components, modules, layers, and their interactions. It outlines
how different system elements (e.g., front-end, back-end, database) will be structured
and integrated to achieve the desired functionality.

 Technical Specifications: The SDD specifies the technical details of the system, such
as programming languages, frameworks, libraries, and tools that will be used. It
provides guidelines for implementing various system features and functionalities using
PHP and other relevant technologies.

Page 41
  Module Design: The SDD breaks down the system into smaller modules or components
and describes the design of each module. It specifies the responsibilities, interfaces,
inputs, outputs, and interactions of each module to ensure seamless integration and
functionality.
 User Interface Design: The SDD details the design of the user interface, including wire
frames, mock ups, layouts, navigation flow, and user interactions. It ensures that the
user interface is intuitive, user-friendly, and meets the requirements of the disease
prediction system.
 Data Flow Diagrams: SDD includes data flow diagrams that illustrate how data flows
through the system, from input (user symptoms) to processing (disease prediction) to
output (prediction results). It helps visualize the data flow and interactions between
different system components.
 Scalability and Performance: The SDD addresses scalability and performance
considerations by describing how the system can handle increasing loads, optimize
resource utilization, and ensure efficient operation. It includes strategies for scaling the
system to accommodate growing user base and data volume.
Overall, the purpose of the SDD is to document the design of the disease prediction system in a
clear and organized manner so that all stakeholders can understand how it functions and how it
will be implemented.

4.3 Scope
The scope for system design in the Disease Prediction system is extensive and encompasses
various aspects crucial for its successful implementation.(19)
Some key areas within the scope of system design for this system include:
This study will focus on developing a web-based system to predict the occurrences of disease on
the basis of various symptoms. This system will let users to give symptoms and according to
those symptoms, the system will predict a disease.
It also helps for the urgent guidance on their illness according to the details and symptoms they
will feed to the web-based application.
It also includes:
System Architecture:
 Design a scalable architecture that can handle large volumes of patient data efficiently.
 Implement a robust database management system to store and retrieve medical records
securely.
 Develop an intuitive user interface for seamless interaction between healthcare
professionals and the system.

Page 42
User Interface Development:
 Design an intuitive graphical user interface (GUI) allowing healthcare professionals to
input patient information easily.
Integration of Medical Database:
 Integrate a comprehensive medical database containing information about various
diseases, symptoms, treatments, medications, etc.
 Ensure seamless connectivity between the prediction system and the database for quick
retrieval of relevant information during diagnosis.
Real-Time Updates:
 Implement real-time monitoring capabilities to track changes in patients' health
conditions continuously.
Data Privacy Measures:
 Incorporate robust security measures such as encryption techniques to protect sensitive
patient information from unauthorized access or breaches.

Having the scope of the system design for a disease prediction system based on these
components and considerations, the system creates a comprehensive and effective solution for
predicting specific diseases.

Page 43
4.4 Architectural Design

The conceptual model that describes a system's behavior, structure, and other aspects is called
systems architecture. A system's formal description and representation, structured to facilitate
inference about the system's behaviors and structures, is called an architecture description.
System components, their outwardly evident characteristics, and the connections between them
can all be included in a system design.(20) The database server, user browser, and local server
comprise the three layers of the system architecture model that are depicted in the diagram below.

FIG: 4.1 Architectural design

Page 44
4.4.1 Logical View
The logical view of system architecture design provides a high-level abstraction that focuses on
the structure and behavior of the system's components and their interactions, without concern for
implementation details or physical deployment.[21]
A logical view of a disease prediction system can be represented using a high-level architectural
diagram that shows the key components and their interactions.

FIG: 4.2 Logical view

Page 45
4.4.2 Process View
Process View is a way of looking at work as a series of steps or actions that transform inputs into
outputs.(22) It helps to understand how different processes interact and communicate with each
other, and how they affect the performance and quality of the system. Process View can be used
to design, analyze, improve, and manage work processes of our platforms. This figure design
view below shows the core features and interaction within the patient interface, so that the
patients/users can navigate, see results and perform various activities. It includes the key parts
such as symptoms, user accounts as well as account creation, registration, and log in
processes. Through such elements, stakeholders would get a picture of how their patients/users
navigate the disease predicting management system.

Fig 4.3Process View

Page 46
4.4.3 Deployment View
Deployment diagrams model the physical architecture of a system. Deployment diagrams show
the relationships between the software and hardware components in the system and the physical
distribution of the processing. It consists of nodes and their relationships. (23) Deployment
diagrams are used for describing the hardware components where software components are
deployed. They are mainly used by system engineers. These diagrams are used to describe the
physical components (hardware), their distribution and association. To clarify it in details we can
visualize deployment diagrams as the hardware components/nodes on which software
components reside. So the usage of deployment diagrams can be described as follows:
 To model the hardware topology of a system.
 To model embedded system.
 To model hardware details for a client/server system.
 To model hardware details of a distributed application.
 To design the hardware components efficiently.
FIG: 4.4 Deployment view

This architectural design provides a structured framework for developing and implementing the
Disease Prediction System, ensuring scalability, reliability, and efficiency in predicting potential
diseases based on user symptoms.

Page 47
4.5 Database Design
Database design is the process of organizing data according to a database model. The designer
or database administrator can determine what data must be stored and how the data elements
interrelate. With this information, they can begin to fit the data to the database model. A database
management system manages the data accordingly [24].
The process of database design involves classifying data and identifying interrelationships. By
determining the relationships and dependencies among the different pieces of data it is possible
to organize the data into a logical structure which can then be mapped into the storage objects
supported by the database management system.

The main objectives of database design in DBMS are to construct logical and physical designs
models of the database system under consideration. A well-designed database should be capable
of handling a large amount of data and at the same time provide faster access to the data. It
should also provide data integrity and security. To elaborate Logical design involves mapping
the conceptual design to a specific data model, such as relational, hierarchical, or network, and
defining the constraints, keys, and indexes for each entity. Physical design involves choosing the
storage structures, file organizations, and access methods that optimize the performance, security,
and availability of the database. The logical model is largely focused on data needs, and
considerations must be made in terms of monolithic concerns, and so the stored physical data
must be stored independently of physical conditions. The physical database design model, on the
other hand, involves a translation of the logical design model of the database by maintaining
control of physical media utilizing hardware resources and software systems such as Database
Management System (DBMS).
The following points describe the significant considerations that may be considered while
stressing the importance of database design.
 Ensures simplicity: A well-designed database makes it easy to write queries and access
data in a user-friendly way.
 Eliminates redundancies: A good database design avoids unnecessary data duplication,
which saves disk space.

Page 48
  Enables analysis: A structured database design allows for effective data retrieval,
reporting, and analytics, which can help online learning platforms measure and improve
their performance.

 Maintains accuracy: A reliable database design ensures that the data stored is valid,
complete, and up-to-date.

4.5.1 Conceptual database design

Conceptual database design is part of the database design process, which consists of the activities
requirements gathering and analysis, conceptual modeling, logical database design and database
implementation.
ENTITIES
User
Symptom
Disease
Result
Feedback

Table Description of each Entity:

1. Patient Table:

Attribute Data type Constraint

ID Varchar(10) Primary key
U_name Varchar(100) UNIQUE KEY
Pasword Varchar(100) NOT NULL
Contact Varchar(100) NOT NULL
Reg_date timestamp NOT NULL
Result int(10) NOT NULL

Page 49
2. Symptom Table:

Attribute Data type Constraint

Symptom_ID Varchar(50) Primary key
ID int(50) NOT NULL
Symptoms_name Varchar(100) NOT NULL
Disease_ID_ Int(50) FOREIGN KEY

3. Disease Table:
Attribute Data type Constraint
ID int(10) NOT NULL
Disease_ID int(100) PRIMARY KEY
Cause Varchar(255) NOT NULL
Disease_name Varchar(100) NOT NULL

4. Result table:

Attribute Data type Constraint

ID int(10) Primary key
Experience Varchar(255) NOT NULL
comments Varchar(255) NOT NULL
name Varchar(255) NOT NULL
email Varchar(255) NOT NULL
C_date timestamp NULL DEFUALT

Page 50
5. Feedback table
Attribute Data type Constraint
F_ID Varchar(10) Primary key
Message Varchar(200) NOT NULL
Name Varchar(30) NOT NULL
Email Varchar(20) NOT NULL

6. Admin table
Attribute Data type Constraint
ID int(30) PRIMARY KEY
User Name Varchar(255) NOT NULL
Password Varchar(100) NUT NULL

Page 51
4.5.2 ER Diagram
An entity relationship model is a way of representing the data and its relationships in a
database. It uses symbols to show the entities, attributes, and relationships that are relevant to a
specific domain of knowledge. An entity relationship model can help to design and understand a
database by showing the logical and physical structure of the data and how it can be manipulated.
An E-R diagram, or entity-relationship diagram, is a way of representing the data and its
relationships in a database. It uses symbols to show the entities, attributes, and relationships that
are relevant to a specific domain of knowledge. An E-R diagram can help to design and
understand a database by showing its logical and physical structure. An E-R diagram consists of
symbols that represent entities, attributes, and relationships. An entity is a thing of interest that
can be identified and distinguished from others. An attribute is a property or characteristic of an
entity. A relationship is an association or connection between two or more entities. The
following diagram is the entity relationship diagram for Disease prediction system.
FIG: 4.4; ER diagram

Page 52
4.5.3 Relational database design
Relational database design focuses on the logical structure of the database, including the tables,
their relationships, and the constraints that govern those relationships. It involves designing the
database schema, specifying the tables, columns, primary keys, foreign keys, and relationships
between tables.

Relationships:
The database establishes relationships between tables to maintain data integrity and coherence.
1. Patient Table ↔ Symptom Table:
One-to-Many relationship: A patient can report multiple symptoms.

User/Patient Symptom

User ID Symptoms_ID

Username ID

Password Symptoms_name

contact
Reg_date Disease_ID

Result

2. Symptom Table ↔ Disease Table:

Many-to-Many relationship: A symptom can be associated with multiple diseases, and vice
versa. Since it’s not directly possible to implement many to many (M:N) relationship in a
database. We have to break it up into two one-to-many relationships. To do so, create a new
entity between those two tables. In the diagram mentioned there exists many to many
relationship between symptom and disease. So create a new entity; we might call it “produces”
that link the two entities

Page 53
 Produces
Symptom Disease
Symptoms_ID User ID ID
ID Disease_ID
Symptoms_name Disease_name Disease_name

Disease_ID Cause

3. Patient Table ↔ Prediction/User Result Table:

One-to-Many relationship: A patient can have multiple prediction results.

User/Patient User_result
User ID ID
Username Experience
Password Comments
contact User_name
Reg_date Email
Result C_date

4. Admin Table ↔ Disease Table

One-to-Many relationship: An Admin can be associated with multiple diseases.

Disease
Admin ID
A_ID Disease_ID
Username Disease_name
Password

Cause

Page 54
4.5.4 Normalization
Normalizing database tables is crucial for reducing redundancy, ensuring data consistency, and
maintaining data integrity. Let's normalize the table by taking examples(based on assumptions
about relationships) into their first, second, and third normal forms:
Eg. Un normalized symptom table

ID Symptom _ID Symptom _name Disease _Id

1. SI1 Feeling tired, easily 1
upset, grouchy
2. SI2 Gritty, Burning, 2
Stinging in the eye
3. SI3 Redness on the eye 2
4. SI4 Blurred vision 3

1. First Normal Form (1NF): Ensures each table has atomic values and no repeating groups.
So, in our case we need to separate multiple values in symptom_name into individual rows.

ID Symptom _ID Symptom _name Disease _Id

1. SI1 Feeling tired 1
1. SI1 Easily upset 1
1. SI1 Grouchy 1
2. SI2 Gritty 2
2. SI2 Burning 2
2. SI2 Stinging in the eye 2
3. SI3 Redness on the eye 2
4. SI4 Blurred vision 3

Page 55
2. Second Normal Form (2NF): In addition to 1NF, it eliminates partial dependencies by
removing columns dependent on only a portion of the primary key.
Identify the primary keys to ensure that all attributes are fully dependent on them.

We introduce a new table symptoms detail with columns symptom id, symptom name and
disease id.
Table: Symptoms_Details
Symptom _ID Symptom _name Disease _Id
SI1 Feeling tired 1
SI1 Easily upset 1
SI1 Grouchy 1
SI2 Gritty 2
SI2 Burning 2
SI2 Stinging in the eye 2
SI3 Redness on the eye 2
SI4 Blurred vision 3

Another table symptoms meta with columns ID and symptom id as the primary key.
Table :Symptoms_Meta
ID Symptom _ID
1. SI1
2. SI2
3. SI3
4. SI4

3. Third Normal Form (3NF): In addition to 2NF, it further eliminates transitive dependencies
by ensuring all attributes are dependent only on the primary key.
So, in our case no further normalization is required as we have already ensured that all attributes
directly depends on the primary key in the normalized tables.

Page 56
By normalizing the original symptoms tables into the first, second and third normal forms, we
achieve a structurally organized database that avoids data redundancy and maintains data
integrity effectively.

Page 57
 CHAPTER FIVE
5.1 CONCLUSION

So, Finally we conclude by saying that, this project Disease prediction using PHP is very much
useful in everyone's day to day life and it is mainly more important for the healthcare sector,
because they are the one that daily uses these systems to predict the diseases of the patients based
on their general information and there symptoms that they are been through. Now a day's health
industry plays major role in curing the diseases of the patients so this is also some kind of help
for the health industry to tell the user and also it is useful for the user in case he/she doesn't want
to go to the hospital or any other clinics, so just by entering the symptoms and all other useful
information the user can get to know the disease he/she is suffering from and the health industry
can also get benefit from this system by just asking the symptoms from the user and entering in
the system and in just few seconds they can tell the exact and up to some extent the accurate
diseases. If health industry adopts this project then the work of the doctors can be reduced and
they can easily predict the disease of the patient. The Disease prediction is to provide prediction
for the various and generally occurring diseases that when unchecked and sometimes ignored can
turns into fatal disease and cause lot of problem to the patient and as well as their family
members.

5.2 RECOMMENDATION

The user has not received a prescription recommendation from this project. Prescription
recommendations can therefore be included in the project. A user's medical history can be
recorded in a log, and prescription recommendations can be put into action.
Engage healthcare professionals in the development process to ensure that the system aligns with
clinical best practices and effectively supports medical decision-making.
Implement processes for ongoing validation, testing, and refinement of predictive models to
enhance accuracy and relevance in real-world healthcare scenarios.

Page 58
REFERENCES

[1] Dr.shivi Sharma, 5 may 2021, disease prediction using machine learning, Retrieved from;
chrome-

[2] Markus, M. L. (2004). Techno change management: using IT to drive organizational

change. Journal of Information technology, 19, 4-20.

[3] Parra, G., Bradnam, K., & Korf, I. (2007). CEGMA: a pipeline to accurately annotate core
genes in eukaryotic genomes. Bioinformatics, 23(9), 1061-1067.

[4] Bodenheimer, T. (2005). Helping patients improve their health-related behaviors: what
system changes do we need?. Disease Management, 8(5), 319-330.

[5] Subahi, A. F., Khalaf, O. I., Alotaibi, Y., Natarajan, R., Mahadev, N., & Ramesh, T. (2022).
Modified Self-Adaptive Bayesian algorithm for smart heart disease prediction in IoT
system. Sustainability, 14(21), 14208.

[6] Ahmed, Z., Mohamed, K., Zeeshan, S., & Dong, X. (2020). Artificial intelligence with
multi-functional machine learning platform development for better healthcare and precision
medicine. Database, 2020, baaa010.

[7] Jagadeeswari, V., Subramaniyaswamy, V., Logesh, R., & Vijayakumar, V. (2018). A study
on medical Internet of Things and Big Data in personalized healthcare system. Health
information science and systems, 6, 1-20.

[8]Thapa, C., & Camtepe, S. (2021). Precision health data: Requirements, challenges and
existing techniques for data security and privacy. Computers in biology and medicine, 129,
104130.

[9] Jenkins, D. A., Sperrin, M., Martin, G. P., & Peek, N. (2018). Dynamic models to predict
health outcomes: current status and methodological challenges. Diagnostic and prognostic
research, 2(1), 1-9.

[10] Manogaran, G., Varatharajan, R., Lopez, D., Kumar, P. M., Sundarasekar, R., & Thota, C.
(2018). A new architecture of Internet of Things and big data ecosystem for secured smart
healthcare monitoring and alerting system. Future Generation Computer Systems, 82, 375-387.

[11] Simpson, R. L. (1994). Ensuring patient data, privacy, confidentiality and security. Nursing
Management, 25(7), 18-22.

Page 59
[12] Laskar, M. T. R., Hossain, M. T., Kamal, A. R. M., & Rashid, N. (2016). Automated disease
prediction system (ADPS): a user input-based reliable architecture for disease
prediction. International Journal of Computer Applications, 133(15), 24-29.

[13] Willbert J, ,Health PHP document, Retrieved from;

https://www.scribd.com/document/632164345/HEALTH-PHP-DOCUMENT

[14] Balsamo, S., Di Marco, A., Inverardi, P., & Simeoni, M. (2004). Model-based performance
prediction in software development: A survey. IEEE Transactions on Software
Engineering, 30(5), 295-310.

[15] Davis, M. E., & Phillips, J. A. (2007). Learning PHP & MySQL: Step-by-Step Guide to
Creating Database-Driven Web Sites. " O'Reilly Media, Inc.".

[16] Chawla, N. V., & Davis, D. A. (2013). Bringing big data to personalized healthcare: a
patient-centered framework. Journal of general internal medicine, 28, 660-665.

[17] The SDD also details the design decisions that have been made throughout the development
process and provides rationale for those decisions.

[18] Kumari, Y., Bai, P., Waqar, F., Asif, A. T., Irshad, B., Raj, S., ... & Asif, A. T. (2023).
Advancements in the management of endocrine system disorders and arrhythmias: a
comprehensive narrative review. Cureus, 15(10).

[19] Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science
research methodology for information systems research. Journal of management information
systems, 24(3), 45-77.

[20]Sage, A. P., & Lynch, C. L. (1998). Systems integration and architecting: An overview of
principles, practices, and perspectives. Systems Engineering: The Journal of The International
Council on Systems Engineering, 1(3), 176-227.

[21]Garvin, D. A. (1998). The processes of organization and management. MIT Sloan

Management Review.

[22] Luján-Mora, S., & Trujillo, J. (2006). Physical modeling of data warehouses using UML
component and deployment diagrams: design and implementation issues. Journal of Database
Management (JDM), 17(2), 12-42.

Page 60
[23] "Wikipedia," january 2024. [Online]. Available:
https://en.wikipedia.org/wiki/Database_design. [Accessed 11 feburary 2024].
[24] [Online]. Available: https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model.
[Accessed 12 feburary 2024].
[25]Colquhoun, H. L., Squires, J. E., Kolehmainen, N., Fraser, C., & Grimshaw, J. M. (2017).
Methods for designing interventions to change healthcare professionals’ behaviour: a systematic
review. Implementation Science, 12(1), 1-11.

extension://efaidnbmnnnibpcajpcglclefindmkaj/https://ijcrt.org/papers/IJCRT2105229.pdf

Page 61
 APPENDIX I

DISEASE PREDICTOR

Tick all your symptom

Sore throat sneezing low fever

Coughing headache runny nose

Sweating body aches fatigue

Constipation congestion abdominal pain

Dizziness blurred vision lose motion

Watery faeces paleness frequent urination

Nausea upset stomach weakness

Rare fever high fever weight loss

Vomiting low BP yellow skin

submit

Page 62
 APPENDEX II

These are the questions we analyzed which while making the document
1. How does the existing system work?
2. What is the organizational structure of the current system?
3. What are the existing systems drawbacks?
4. What are the key symptoms and risk factors associated with the diseases to be predicted?
5. Are there any specific generic factors that need to be considered for the disease prediction?
6. How frequently do patients visit healthcare providers for monitoring their health?
7. What demographic information should be collected from patients for disease prediction?
8. What are the main challenges faced by healthcare provider in predicting and diagnosing
disease accurately?

Page 63