Online Doctor Appointment
Project
Database Project Report
Group-04
Report submitted 27 March, 2022
A project submitted to Dr. Rudra Pratap Deb Nath, Associate Professor,
Department of Computer Science and Engineering, Chittagong University
(CU) in partial fulfillment of the requirements for the Database Systems Lab
course. The project is not submitted to any other organization at the same
time.
Table 1: Details of Group-04
Roll Id
18701031
18707044
18701047
18701049
10701054
10701061
Name
Azizul Karim
Tanveer Ahmed
Mosharrof Hossain
Nurul Mostafa Rahat
Sahim Salem
Shah Tareq Ahmed
Sigature
Azizul
Tanveer
Naiem
Rahat
Sahim
Tareq
1
Date
Supervisor Approval
24-03-2022
24-03-2022
24-03-2022
24-03-2022
24-03-2022
24-03-2022
Contents
1 Introduction
1.1 Background and Motivation .
1.2 Problem Statement . . . . . .
1.3 System Definition . . . . . . .
1.4 System Development Process
1.5 Organization . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Project Management
5
5
5
6
6
7
8
3 Requirement Gathering and analysis
3.1 Establishing Project Goals and Objectives . . . . . .
3.2 Identifying Stack-holders . . . . . . . . . . . . . . . .
3.3 System Study . . . . . . . . . . . . . . . . . . . . . .
3.4 Eliciting Requirements from Stack-holders . . . . . .
3.5 System Analysis and Requirements Specifications . .
3.5.1 User Requirement . . . . . . . . . . . . . . . .
3.5.2 Functional and Non Functional Requirements
3.5.3 System Requirement . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
11
11
11
11
12
4 Conceptual Modelling
14
5 Logical Modelling
16
6 Normalization
18
7 System Architecture
23
8 Implementation
28
9 Validation
30
9.1 User Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1.1 Manual for Patient . . . . . . . . . . . . . . . . . . . . 30
9.1.2 Manual for Doctor . . . . . . . . . . . . . . . . . . . . 30
10 Software Deployment
31
11 Conclusion and Future Work
32
12 Bibliography
33
2
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
System Deployment Process . . . . . . . .
Work Updates in Trello . . . . . . . . . . .
Doctor Appointment System E-R Diagram
Department Relation . . . . . . . . . . . .
Doctor Relation . . . . . . . . . . . . . . .
Patient Relation . . . . . . . . . . . . . . .
Appointment Relation . . . . . . . . . . .
System Architecture . . . . . . . . . . . .
Doctor Login . . . . . . . . . . . . . . . .
Doctor’s Scheduling Interface . . . . . . .
Patient Registration Interface . . . . . . .
Doctor Admin Interface . . . . . . . . . .
Appointment Update Interface . . . . . . .
Clinic Admin Interface . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
9
14
19
19
20
21
23
24
24
25
26
26
27
Details of Group-04 . . . . . . . . . . . . . . . . . . . . . . . .
1
List of Tables
1
Listings
1
2
3
4
5
6
Create Patient Table . . . . . . . . . . . . . . . . . .
To Project Doctors and their Respective Departments
To see All Departments Name . . . . . . . . . . . . .
Insert into Patient Table . . . . . . . . . . . . . . . .
Insert into appointment Table . . . . . . . . . . . . .
To see serial of doctor 1011 in his available day. . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
28
28
28
29
Abstract
With the rapid development of technology, many manual systems
have been replaced by computerized systems all over the world as
well as in our country.In this case, we will create a quick and smooth
appointment system between doctors and patients.
In the conventional appointment system, patients have to stand in
line at the hospitals or doctor’s chambers to make an appointment,
where patients waste much time and do not even get an appointment
on the desired day.
At present most of the people in Bangladesh are connected through
internet. So, through the internet, if people want to get connected to
their preferred doctors, a nexus might be needed. We have planned
to build a website to get an appointment for that motive. Our system
could assist people to get instant help without wasting time and effort
even they will get this service from home and overseas. By using
this system, people can quickly learn about the timing of the doctor’s
counseling period and make their meeting on every occasion they want.
The properly categorized listing will make people more comfortable
browsing their anticipated doctors.
4
1
Introduction
In our daily life, we are facing numerous problems. Sickness is one of the
most commonplace troubles in a person’s life. If anybody is ill and wants to
visit a doctor for checkup, he needs to go to the hospital and wait till the
doctor is available.
Suppose the doctor cancels the appointment for some emergency reason
after getting the appointment. In that case, the patient will not know about
the cancellation of the appointment until he goes to the clinic. So, it is
crucial to have a session with the doctors whenever we are infected with various diseases. As the internet is now available for every person, anyone can
use the online appointment system to overcome such problems and inconvenience for the patients. The vision of this task is to create a doctor-patient
managing system to help patients book doctor appointments and fulfil their
prospects. In this system, doctors are allowed to control their booking slots,
and patients can make their appointment to book empty spaces, too. that is
the reservation system for counselling with the aid of patients’ names. This
system manages different varieties of doctors simultaneously, and patients
can choose their anticipated one for booking.
This project aims to develop a database application system with the aid of
making use of the theories, methodologies, tools, and technologies we learned
in CSE 413.
1.1
Background and Motivation
As patients, we face many difficulties when we want to get an appointment
for a doctor in their chambers or hospitals. The patient needs to visit their
chambers or hospital to get an appointment, but it is a prolonged method
and wastes patients’ time. Sometimes patients visit a doctor’s chamber for a
health check, but the doctor is not available for various reasons. It is the only
way to know whether the doctor is available or not when the patient visits
their places. It harasses patients a lot. Our motivation is that if we want to
have an option to get this appointment quickly, that can be more precious.
So, we have planned to implement a web-based doctor appointment system.
1.2
Problem Statement
The primary aim of the ”Online Doctor Appointment System” is to make
a clean interface for patients who will apply for a doctor appointment. Additionally, he or she can check the doctor’s availability and presents their
feedbacks on which doctor treats them.
5
1.3
System Definition
An online doctor appointment system is managed by a computerized
method that allows patients to book an appointment from their places via
the internet-enabled device at any time and give them their doctor’s table
and save patient’s details digitally
1.4
System Development Process
We are using the waterfall model to develop our system. The waterfall
model is a classical version utilized in the system improvement life cycle to
create a system with a linear and sequential approach. It is called waterfall
because the model develops systematically from one phase to another in a
downward style. This model is split into different levels, and the output of
Figure 1: System Deployment Process
one segment is used as the input of the following section. Each segment has
to be completed before the following phase starts, and there is no overlapping
of the phases.
Requirement Gathering and analysis: All possible requirements of the
6
system to be developed are captured in this phase and document in a requirement specification doc.
Database Modeling: A database model shows the logical structure of a
database, including the relationships and constraints that determine how
data can be stored and accessed. Individual database models are designed
based on the rules and concepts of whichever broader data model the designers adopt.
System Architecture: The requirement specifications from first phase are
studied in this phase and system design is prepared. System design helps
in specifying hardware and system requirements and also helps in defining
overall system architecture.
Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality which is referred to as
unit testing.
Validation: Validation is the documented process of demonstrating that a
system or process meets a defined set of requirements. There are a common
set of validation documents used to provide this evidence.[1]
1.5
Organization
We developed a web-based system that’s an online doctor appointment
system. We have designed our workflow follows by above:
Section 1 offers an overview of the project. Section 2 describes how the
project and the resources are managed, Section 3 briefs how to acquire resources and its analysis. Section 4 indicates our system E-R diagram where
illustrates how to locate the entity types, relationships, and attributes. Section 5 offers the logical model of our system where we convert our E-R diagram to the relational model. Section 6 has the details of our database
normalization up to 3NF.
Section 7 shows our system architecture how each structure communicates, and Section 8 indicates the implementation of our database. Section
9 contains the user satisfaction with our product and system user manual.
Section 10 describes a way to install and configure our system so that a nontechnical person can use our system. In the end, the belief and the hints to
the future work are mentioned in Section 11.
7
2
Project Management
In brief, the project ”Online Doctor’s Appointment” is a web app designed
to focus on the problem of patients making appointments quickly and saving
their time by getting the proper schedule. To manage and gather the assets
of the whole project, we go through a technique referred to as SCRUM.
Scrum is a methodology that uses an iterative and incremental approach
to develop software. Throughout the project’s lifecycle, Scrum is designed
to provide value to the customer in an adaptive, fast, flexible, and effective
manner. [2]
Our SCRUM master, Azizul Karim Prithibi, came up with a concept
to make the doctor’s appointment system more fluent and less complex.
SCRUM master created a SCRUM team consisting of 6 participants, including him. SCRUM crew individuals are Azizul Karim, Sahim Salem, Tanveer
Ahmed, Nurul Mostafa Rahat, Shah Tareq Ahmed, and Mosharrof Hossain.
Here we took a 2 months sprint to satisfy the project. Furthermore, the
SCRUM master arranged an online meeting every two days.We divided into
two teams firstly, team frontend and team backend. The frontend group
includes Azizul Karim, Nurul Mostafa, Mosharrof Hossain.
This crew accumulated our designing resources from W3 schools, BootStrap and designed the frontend with HTML, CSS, js, bootstrap, and so on.
the second group, along with Azizul Karim, Tanveer Ahmed, Shaim Salem,
Shah Tareq Ahmed of the backend portion has designed sources from MySql,
PHPMyAdmin, and many others.
Zoom software has been used to arrange the SCRUM meeting as a tool.
Besides, Trello has a beautiful use of updating the entirety after the SCRUM
meetings which we have included below as a screenshot. All of the frontend
and backend codes are stored in GitHub.
8
Figure 2: Work Updates in Trello
9
3
Requirement Gathering and analysis
This chapter describes how we collect requirements, study and analyse
system. To be able to accumulate requirements, we have to go through the
following processes[3];
3.1
Establishing Project Goals and Objectives
In order to collect required data of a structured appointment system, we
set up project goals and project objectives at first. The goals of our project
are following:
i. To create a web-based online doctor appointment.
ii. To manage doctor’s profile related data.
iii. To manage patient-related information.
iv. To store patient’s records in an organized and secured way for further
use.
v. To overcome inconvenience or drawbacks of manual doctor appointment
system.
3.2
Identifying Stack-holders
The following are the stack-holders of Doctor Appointment system:
i. Doctors
ii. Patients
iii. Users
iv. System Administrators
v. Medical record department
3.3
System Study
This Section describes how we conduct system study to collect feasible
system requirements. We carried out the system study on patients, doctors,
and many departments of hospital. The main motive of the study was to
find out how we carried out patients’ information recording process. The
10
system currently utilized in patients, doctors, and hospitals is entirely manuals. When a patient requests all information be recorded manually from the
appointment, and the system is very time-consuming and hesitating from the
facts; doctor availability, and right time maintenance of the doctor appointment.
3.4
Eliciting Requirements from Stack-holders
Throughout this section, we have to go through numerous cycles of elicitation, documentation, and evaluations. To obtain a functional specification,
we have to undergo numerous confirmations, even though we can not reach to
all stack-holders; we have found out difficulties of manual appointment system from patients, doctors, and, additionally, analyzed the existing online
doctor appointment system.
3.5
System Analysis and Requirements Specifications
During the system study segment, we have classified the requirements of
the online doctor appointment system into user requirements, system requirements and functional and non-functional requirements. After analyzing the
collected information, we formulated several requirements, particularly user
requirements and system hardware software attributes. We grouped this information into user requirement, functional and non-functional requirement,
and system requirement.
3.5.1
User Requirement
During data collection, we investigated and found out how the current
system operates and attempted to find out which problems are faced and how
they can be solved. The users describe some of the primary requirements of
the system, which include the search for patients, updating the record, doctor
information file, and viewing all styles of reviews.
3.5.2
Functional and Non Functional Requirements
We have planned to add an online payment system to collect doctor’s visiting fees in the future. For this consequence, we will append the acceptance
of submissions in the form of the raw patient which will perform financial
analysis to authenticate the system’s user. Furthermore, non-useful requirements include the following; The system must verify to validate user’s input,
and the user must be notified in case of errors detected in the database.
11
3.5.3
System Requirement
This Section describes the hardware components and software requirements needed for effective and efficient running of the system.
Hardware Requirements
SL
Hardware
Minimum System
Requirement
1
Processor
2.4 GHz
speed
2
Memory
2 GB RAM
3
Disk Space
500 GB
Processor
Software Requirements
SL
Software
Minimum System
Requirement
1
Operating System
Windows
Server
2012,Windows10
2
Database
Management System
MySQL
3
Runtime Environment
phpMyAdmin
12
Documenting Requirements
After going through all of these processes mentioned above, we have found
the following requirements;
Entity
Type
Attributes
Doctor
doctor id,
doctor email etc.
doctor name,
Has
Patient
patient id,
patient age etc.
patient name,
Take
Appointment
appointment id,
appointment date etc.
13
Relationships
Check
4
Conceptual Modelling
The primary stage of the database design process is conceptual design.
The output of this process is a conceptual statistical model that describes
the principle records entities, attributes, relationships, and constraints of a
given problem area. This design is descriptive and narrative in shape. In
the case of conceptual modeling, we first need to specify the fundamental
components like entity types, relationships types, and attributes related to
them which is done in the Requirement Gathering Section. Our conceptual
data model involves:
i. Entity sets real-world objects that are our essential information factors.
ii. Relationship sets among entity types.
iii. Attributes related to entity and relationship sets.
Figure 3: Doctor Appointment System E-R Diagram
14
We list the entity sets and their attributes below, with primary keys
underlined by revisiting the requirements gathering and analysis phase.
1. Department ( department id, department name, department location)
2. Doctor ( doctor id, doctor name, doctor email id, doctor phone no)
3. Doctor Availability ( available day, available time, maximum appointment capacity)
4. Appointment ( appointment id, appointment date, appointment status)
5. Patient ( patient id, patient name, patient age,patient sex, patient phone no)
15
5
Logical Modelling
A logical data model (LDM) describes data elements in detail and is
used to develop visual understandings of data entities, attributes, keys, and
relationships[4]. This kind of model is uniquely independent of a specific
database to establish a foundational structure for the components of the semantic layer in data management systems.
ER Model to Relational Schema:
1. Create a table for each entity.
2. Entity’s attributes should become fields of tables with their respective
data types.
3. Declare primary key.
4. In the case of a one-to-one relationship, we add the primary key of
either side to another side as a foreign key.
5. In the case of a one-to-many relationship, we add the primary key of
the one side to the many sides as a foreign key.
6. Create a table for a relationship if there is a many-to-many relationship.
7. Add the primary keys of all participating Entities as fields of the table
with their respective data types.
8. If a relationship has any attribute, add each attribute as a table field.
9. Declare a primary key composing all the primary keys of participating
entities.
10. Declare all foreign key constraints.
In our database, there is a one-to-many relationship between Doctor and
Department. Hence, adding the primary key of Department (department id)
to Doctor as a foreign key:
a. Department(department id, department name, department location)
b. Doctor(doctor id, doctor name, doctor email id, doctor phone no)
There is a one-to-many relation between Doctor and Doctor Availability.
Adding primary key of Doctor(doctor id) to Doctor Availability as a foreign
key:
16
a. Doctor Availability( available day, available time, maximum appointment capacity)
There is a one-to-many relation between Patient and Appointment. Adding
primary key of Patient( patient id) to Appointment as a foreign key:
a. Appointment(appointment id, appointment date)
b. Patient(patient id, patient name, patient age, patient sex, patient phone no)
There is a one-to-many relation between Doctor and Appointment. In this
relationship primary key of doctor (doctor id) acts as a foreign key of Appointment.
17
6
Normalization
Normalization is the process of minimizing redundancy from a relation
or set of relations. Redundancy in relation may cause insertion, deletion,
and update anomalies. So, it helps to minimize the redundancy in relations.
Normal forms are used to eliminate or reduce redundancy in database tables.
1NF (First Normal Form) Rule: If a relation contains a composite or
multi-valued attribute, it violates the first normal form or the relation is
in first normal form if it does not contain any composite or multi-valued
attribute. A relation is in first normal form if every attribute in that relation
is singled valued attribute
2NF (Second Normal Form) Rule: To be in second normal form, a
relation must be in first normal form and relation must not contain any
partial dependency and all non-prime attribute in relation is fully functionally
dependent on each of the candidate key. A relation is in 2NF if it has No
Partial Dependency, i.e., no non-prime attribute (attributes which are not
part of any candidate key) is dependent on any proper subset of any candidate
key of the table.
3NF (Third normal form) Rule: A relation is in third normal form if
there is no transitive dependency for non-prime attributes as well as it is
in second normal form and non-prime attributes must not determine other
attributes.[5]
A relation is in 3NF if at least one of the following conditions holds in every
non-trivial function dependency X→Y
i. X is a super key.
ii. Y is a prime attribute (each element of Y is part of some candidate key).
At first, we have to check each of the relations whether they are on 3NF or
not. If anyone of them is not in 3NF, we will decompose it so that it will in
3NF.
1. Department: (department id, department name, department location)
Functional Dependencies:
department id →{department name, department location}
Finding Candidate key:
Closure of {department id} = {department name, department location}
As, {department id} can uniquely identify all the attributes, it can be referred as Super Key. And proper subset of this attribute is not super key ,
so it is also a Candidate Key.
Candidate key: {department id}
18
Figure 4: Department Relation
Prime Attribute: {department id}
Non-prime attributes: {department name, department location}
1NF: It satisfies 1NF as domains of all of the attributes are atomic.
2NF: There is no functional dependency as the proper subset of the candidate keys don’t uniquely identify any of the non-prime attributes.
3NF: Since department id is a super key of the relation, it satisfies 3NF also.
Hence, relation Department is in 3rd Normal Form.
2. Doctor ( doctor id, doctor name, doctor email id, doctor phone no )
Figure 5: Doctor Relation
19
Functional Dependencies:
{doctor id} → {doctor name, doctor email id, doctor phone no}
{doctor email id} → {doctor id}
{doctor phone no} → {doctor id}
Finding Candidate keys:
Closure of {doctor id} = {doctor name, doctor email id, doctor phone no}
doctor id is both candidate key and super key.
Closure of {doctor email id} = {doctor id, doctor name, doctor phone no}
doctor email id is also both candidate key and super key.
Closure of {doctor phone no} = {doctor id, doctor name, doctor email id,}
doctor phone no is also both candidate key and super key .
Candidate keys:{doctor id}, {doctor email id}, {doctor phone no}
Prime Attributes: {doctor id, doctor email id, doctor phone no}
Non-prime-attributes: {doctor name}
1NF: All of them satisfy 1NF as domains of all of the attributes are atomic.
2NF: Since all of the non-prime attributes are fully functionally dependent
on each candidate key and there is no partial dependency on any of this
functional dependencies, relation Doctor satisfies 2NF.
3NF: Right side of these FDs are doctor id, doctor email id, and doctor phone no.
Each of which are super keys. Hence, These FDs satisfy 3NF.
Thus, relation Doctor is in 3rd Normal Form.
3.Patient (patient id, patient name, patient age, patient phone no, patient sex)
Figure 6: Patient Relation
20
Functional Dependencies:
{patient id} → {patient name, patient age, patient phone no, patient sex}
{patient phone no} → {patient id}
Finding Candidate keys:
Closure of {patient id} = {patient name, patient age, patient phone no, patient sex}
Hence, patient id is both candidate key and super key.
And closure of {patient phone no} → {patient id, patient name, patient age,
patient sex}
Thus, phone no is also both super key and candidate key.
Candidate keys: {patient id}, {patient phone no}
Prime Attributes: {patient id, patient phone no}
Non-prime-attributes: {patient name, patient age, patient sex}
1NF: All of them satisfy 1NF as domains of all of the attributes are atomic.
2NF: Since all of the non-prime attributes are fully functionally dependent
on each candidate key and there is no partial dependency on any of this
functional dependencies, relation Patient satisfies 2NF.
3NF: Right side of these FDs are patient id, and patient phone no. Each of
which are super keys. Hence, These FDs satisfy 3NF.
Thus, relation Patient is in 3rd Normal Form.
4. Appointment (appointment id, appointment date)
Figure 7: Appointment Relation
21
Functional Dependencies:
{appointment id} → {appointment date}
Finding Candidate keys:
Closure of {appointment id} → {appointment date}
Hence, appointment id is both a super key and a candidate key.
Candidate key: {appointment id}
Prime Attribute: {appointment id}
Non-prime-attribute: {appointment date}
1NF: It satisfies 1NF as domains of all of the attributes are atomic
2NF: There is no functional dependency as the proper subset of the candidate keys don’t uniquely identify any of the non-prime attributes.
3NF: Since appointment id is a super key of the relation, it satisfies 3NF
also.
Hence, relation Appointment is in 3rd Normal Form.
22
7
System Architecture
A system architecture diagram is the distribution of the functional correspondences. These are formal elements, the embodiment of concepts and
information. Architecture defines the relations between elements, amongst
features, and the surrounding elements[6].
Figure 8: System Architecture
In our Advanced Clinic’s Doctors Appointment Management System , there
are in total 6 interface. Each of them are described below;
23
Doctor’s login: In this interface, doctor can login using e mail, doctor id,
password and can go to doctor’s admin interface
Figure 9: Doctor Login
Doctor’s Scheduling: Doctor can set schedule for his/her patient for
next days.
Figure 10: Doctor’s Scheduling Interface
24
Patient Registration: Patient can register by giving information about
patient name, age, gender, mobile-number, choosing doctor and suitable date
to take appointment or login(if old patient) by giving patient ID, choosing
doctor and suitable date. After login they can see their updates of appointment only for that doctor who he/she have chosen as a doctor.
Figure 11: Patient Registration Interface
25
Doctor’s Admin: In this interface, doctor can watch his recent schedule along with details of recent schedule’s patient. Also can go to doctor’s
scheduling interface.
Figure 12: Doctor Admin Interface
Appointment updates: Patient can watch their updates by giving
patient id for all doctors he/she have appointments with or past schedule
of doctors whom he/she have already visited .
Figure 13: Appointment Update Interface
26
Clinic Admin: Can delete existing doctor, department or add new doctor, department.
Figure 14: Clinic Admin Interface
27
8
Implementation
Listing 6 shows an SQL query.
1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE Patient
(
Patient_ID VARCHAR (20) NOT NULL ,
Patient_Name VARCHAR (20) NOT NULL ,
Patient_Email_ID VARCHAR (20) NOT NULL ,
Patient_Phone VARCHAR (20) NOT NULL ,
Patient_Address VARCHAR (20) NOT NULL ,
Patient_Age INT NOT NULL ,
Patient_Sex VARCHAR (20) NOT NULL ,
PRIMARY KEY ( Patient_ID )
);
Listing 1: Create Patient Table
1
2
3
SELECT Do . Doctor_Name , DE . Department_Name
FROM doctor AS Do JOIN department AS DE
WHERE Do . Department_ID = DE . Department_ID ;
Listing 2: To Project Doctors and their Respective Departments
1
2
SELECT Department_Name
FROM department ;
Listing 3: To see All Departments Name
1
2
INSERT INTO patient ( Patient_ID , Patient_Name ,
Patient_Phone , Patient_Age , Patient_Sex )
VALUES ( ’ $patient_id ’ , ’ $name ’ , ’ $mobile ’ , ’ $age ’ , ’
$ g e n d e r );
Listing 4: Insert into Patient Table
1
2
INSERT INTO appointment ( Appointment_ID ,
Appointment_Date , Patient_ID , Doctor_ID )
VALUES ( ’ $appointment_id ’ , ’ $date ’ , ’ $patient_id ’ , ’
$ d o c t o r _ i d );
Listing 5: Insert into appointment Table
28
1
2
3
4
5
6
7
8
9
10
SELECT t1 . Patient_Name , t1 . Patient_Phone , t1 .
Patient_Age , t1 . Patient_Sex , t2 . Appointment_Date
, t4 . Available_Time as Time
FROM patient as t1 JOIN appointment as t2
ON t1 . Patient_ID = t2 . Patient_ID
JOIN doctor as t3
ON t2 . Doctor_id = t3 . Doctor_id
JOIN doctor_availability as t4
ON t3 . Doctor_id = t4 . Doctor_id
AND t2 . Appointment_Date = t4 . Available_Day
WHERE t2 . Doctor_id = ’ 1011 ’
AND t2 . Appointment_Date = ’ $ d a y ;
Listing 6: To see serial of doctor 1011 in his available day.
29
9
Validation
Our system saves money and time for patients. Our current medical
system is a mess up. People come from a different city area, facing colossal
traffic jams, anticipate a doctor for hours, and if the medical doctor is absent
frequently, they do not get the notification. So it becomes a loss of time,
cost in colossal capacity. Our application provides a better answer of keep
times and price. Our application has a better notification system, which gives
patients an appointment time. If the doctor does not come on the scheduled
date, it will notify the in-person patient and the website.
9.1
User Manual
Our application system is the simplest one. We said before that we had
got stakeholders, doctors, and patients. So they may use our system simultaneously.
9.1.1
Manual for Patient
i. They can select a doctor from the department or doctor list page.
ii. Then they go to their selected doctor page.
iii. From this page, they can see doctors, the latest three scheduled, and set
an appointment with the doctor.
iv. If the doctor’s schedule is occupied, our application suggests considering
other doctors of the same department.
v. If they can set an appointment, they go to the doctor’s respective appointment page. Where they can set an appointment through form fields.
They can also show their appointment no. on their respective schedule.
9.1.2
Manual for Doctor
i. They can go to their page directly or from their respective department’s
web page.
ii. They can log in to their admin page.
iii. While the doctor goes to his respective admin web page, he can provide
a new timetable, see older time tables, see the appointment tables of respective schedules, send notifications if needed, connect with the patient
through chatbot(conceptual).
30
10
Software Deployment
Our web application can be hosted on a hosting site like Netlify, Heroku.
The hosting site will give us an address. We will use the address for our application, and it will provide doctor’s visiting cards, prescriptions, billboards,
diagnostic report cover, social media page/groups. Patients will discover this
web address in this way. They need only type/copy-paste the address to their
internet-connected device’s browser.
31
11
Conclusion and Future Work
At present, the number of patients is increasing tremendously, and it is
becoming tough to get doctors’ services. In the most chambers or hospitals,
appointments are manually taken to serve patients. However, patients have
to wait in line for a long time to have an appointment. Again many times,
if for some reason the doctor cancels the appointment, then the patient may
not know it immediately. That is why the patients have to suffer from far and
away. Not everyone knows exactly how many specialist doctors there are for
a particular type of disease. Finding a specialist doctor is tricky, especially
for those who live in rural areas.
Through our project, patients can easily make an appointment with a
specialist doctor without standing in any line. The patient does not have to
come to a specific place at a specific time to make the doctor’s appointment,
and he can take the schedule of his choice sitting at home. Patients’ phone
numbers and emails will be stored in our database at appointment time. If
the doctor cancels the schedule for any reason, the patient will be informed
via mobile S.M.S and email. Even if the patient feels that he cannot come
to the doctor for any reason, he can apply to cancel the appointment himself.
Significance of the project:
Our project is a database management system for making doctor’s appointments online. Our idea is that this project will have a very influential impact
on our daily lives. In the manual appointment system, the patient has to
talk to the receptionist or office staff face to face or on the telephone with the
required documents. If the office staff is not available directly or by phone,
the patient has to spend a long time in line or on the phone to make an appointment. Due to which much valuable time of the patient is wasted. With
the online appointment system, the patient can make an appointment at any
place of his choice. It is challenging for ordinary people, especially in rural
areas, to come to the city and find a specialist doctor. In this case, he can
easily arrange the specialist doctor’s appointment through any device with
an internet connection, and then he can appear in the doctor’s chamber at
the appointed time. Newly added doctors in the profession will increase their
popularity with the people through this project and will be able to serve the
patients efficiently. Near future, it’s going to be great easy for a massive
number of patients and doctors.
32
12
Bibliography
References
[1] Definition of ’Waterfall Model’ (2021). https://economictimes.
indiatimes.com/definition/waterfall-model.
[2] Digite, What Is Scrum Methodology and Scrum Project Management
(2021). https://www.digite.com/agile/scrum-methodology/.
[3] Jama Software, What is requirements gathering?
(2022).
https://www.jamasoftware.com/requirements-management-guide/
requirements-gathering-and-management-processes/
what-is-requirements-gathering.
[4] Techopedia, Logical Data Model (LDM) (2014). https://www.
techopedia.com/definition/30599/logical-data-model-ldm#:
%7E:text=A%20logical%20data%20model%20(LDM)%20provides%
20a%20detailed%20overview%20of,from%20the%20underlying%
20database%20technology..
[5] GeeksforGeeks,
Introduction
of
Database
Normalization
(2021).
https://www.geeksforgeeks.org/
introduction-of-database-normalization.
[6] System Architecture Diagram:
A Complete Tutorial —
EdrawMax
(2021).
https://www.edrawsoft.com/article/
system-architecture-diagram.html.
33