A

Report on

ONLINE DOCTOR
APPOINTMENT SYSTEM

Prepared By
Rashmi Singh
(210360116507)
Gira Rathod
(210360116514)

Submitted to
Ayushi Gondaliya
Ast. Prof. I.T. Department
SREZ,
Rajkot
 Table of Contents
Chapter: 1 Introduction to Project .............................................................................................................................. 3
1.3 General Description ............................................................................................................................... 4
1.4 Technology Review (Introduction of software/technology) ..................................................................... 4
Chapter: 2 - Project Management ............................................................................................................................... 6
2.1 Project Planning........................................................................................................................................... 6
2.1.1 Project Development Approach............................................................................................................... 6
2.1.2 Modules of This Topic: - .......................................................................................................................... 6
2.3 Risk Management: ........................................................................................................................................... 7
2.3.1 Risk Identification: ................................................................................................................................... 7
Following the possible risk of our project… ....................................................................................................... 7
Risk Analysis: ......................................................................................................................................................... 8
Risks are of two types: ......................................................................................................................................... 8
Risk Planning: ........................................................................................................................................................ 8
Chapter 3: System Specifications................................................................................................................................. 9
3.1 Use Case Diagram:....................................................................................................................................... 9
3.2.1 Functional Requirements: ........................................................................................................................... 9
3.2.2 Non-Functional Requirements ...............................................................................................................10
IV. Usability ................................................................................................................................................12
Chapter 4: System Analysis ........................................................................................................................................13
4.1 Feasibility Study.............................................................................................................................................13
4.2 Economic Feasibility: ....................................................................................................................................13
4.3 Technical Feasibility: .....................................................................................................................................13
4.4 Behavioral Feasibility: ...................................................................................................................................13
Chapter 5: System Design ..........................................................................................................................................14
5.1 E R Diagram .............................................................................................................................................14
5.4 Data Structure Tables ...................................................................................................................................20
Chapter 6: Implementation Decisions .......................................................................................................................23
Chapter: 7 Conclusion ................................................................................................................................................24
CHAPTER: 8 References ............................................................................................................................................25

Page | 2
 Chapter: 1 Introduction to Project
Introduction:

If anybody is ill and wants to visit a doctor for a check-up, he or she must visit the hospital and wait until
the Doctor is available. The patient also waits in a queue while getting an appointment. If the Doctor
cancels the appointment for some emergency reasons, then the patient can only know about the
cancelation once he or she visits the hospital. As mobile
communication technology is developing rapidly. Therefore, mobile applications can overcome such
problems and patient inconveniences.

1. 1 Purpose

The purpose of this document is to describe the requirements for the Doctor's appointment system. The
intended audience includes all stakeholders in the potential system. These include but are not necessarily
limited to the following: Administrative Staff, doctors, patients, and developers. Developers should
consult this document and its revisions as the only source of requirements for the project. They should
only consider any requirements statements, written or verbal, as valid once they appear in this document
or its revision.

1.2 Abstract

Life is becoming too busy to get medical appointments in person and maintain proper health care. The
main idea of this work is to provide ease and comfort to patients while making appointments with
doctors, and it also resolves the problems that the patients have to face while making an appointment.
The Android application DOCTOR APPOINMENT SYSTEM acts as a client. In contrast, the database
containing the Doctor's details, patient's details, and appointment details are maintained by a website that
acts as a server.

1.3 Scope

It may help perfect collection management in detail. The collection will be apparent, straightforward, and
sensible quickly. It will help a person to know the past year's management perfectly and vividly.

1. In the computer system, the person has to fill the various forms & the number of copies of the forms can
be easily generated at a time.

2. Creating the manifest in a computer system is unnecessary, but we can print it directly, saving time.

3. To assist the staff in capturing the effort spent in their respective working areas.

4. The system generates information that can be used for various purposes.

5. To satisfy the user requirement.

6. Be easy to understand by the User and operator.

7. Have a good user interface.

Page | 3
 8. Be expandable.

1.3 General Description

1. Product Perspective

This Doctor Appointment Reservation System is a self-contained system that allows patients to book
appointments and doctors to manage appointments.

2. Product Functions

i. Provide an application enabling patients to book an appointment with any doctor.

ii. Doctors will be able to view their appointments and manage them properly.

iii. Coordinate various calendars and find available time slots for appointments.

iv. Reserve equipment and rooms for an appointment.

v. Alert patients in case there is an earlier available time slot.

3. User Characteristics

The system will be used in the hospital. The doctors and patients will be the main users, given the
condition that not all users are computer-literate. Some users may have to be trained in using the system.
The system is also designed to be user-friendly. It uses a Graphical User Interface (GUI)

• Patient: These are the people who want to make the appointment.
• Doctor: These are the specialist whom appointments are being booked for.
• Database Administrator: They are responsible for maintaining and overseeing the database of
the system.

4. General Constraints

• The system must be delivered by the proposed deadline.

• The system must be user-friendly.

1.4 Technology Review (Introduction of software/technology)

To develop this package, different types of tools and databases are used, which are as follows:

1. Android Studio (JAVA)

2. SQL database

Page | 4
Android Studio:

Android-powered devices, including tablets, have become the foremost need of all the tech-savvy people
across the world, and the prime reason is it provides an open-source platform for the development of
great apps and allows app developers to immediately publish them.

SQL database:

SQLite is very well-suited as a device-resident data manager. It is an application library and not a client-
server database, making it very flexible for applications to use. As an app-resident library, it has no
notion of "installation" It doesn't need to be configured or connected to, and its data is stored in a simple
file that is completely in the control of the application.

Page | 5
 Chapter: 2 - Project Management

2.1 Project Planning

1. This appointment-based application can be used with other appointment-based systems. The mobile
application accepts appointments by saving the appointment record on the phone calendar, synchronized
with the Google calendar. The User gets an alert based on the preset specified time before the appointment
time and date.

2. Described an Android smartphones and tablets application that is freely downloadable from the Google
play store and it provides various functionalities, including personnel medical records, to trace the position
of actual users in real-time.

3. This database consists of a portable monitoring terminal that keeps a continuous record of a patient,
including the history.

2.1.1 Project Development Approach

Choosing a suitable model for the development of the project is the main topic in the project
development. The development approach you choose can depend on things like the project team.
Size of project, structure. Location of then, etc., the development of the project is depended on the
selected development approach. We have selected the iterative waterfall model for our development.

2.1.2 Modules of This Topic: -

1. Doctor management module--> used for managing the Doctor's details.

2. Doctor schedule module--> used for managing the details of the Doctor's schedule.

3. Appointment management module--> used for managing the information and details of Appointments.

4. Booking module--> used to manage the patient details.

5. Log-in module--> used for managing the login details.

6. Users’ module--> used for managing the users of the system.

2.1.3 Advantages of Online Doctor Appointment System:

1. Online doctor appointment system services attract more patients.

2. It will make sure that there are no more phone calls.

3. It will make reminders/cancellations/reschedules easy.

4. It Will book appointments with a tap.

Page | 6
 5. An online doctor system allows for 24-hour scheduling.

6. Patients don't have to wait long hours.

7. Allows clients to book at any time and place.

8. It is user-friendly.

2.2 Project Scheduling:

Managing appointments via phone calls or in person is time-consuming and inefficient. Decuples will
help your clinic & hospitals to set up appointments for your patients in the most effective way with the
help of the mechanical appointment scheduling app. This allows smooth flow in the operations, thereby
replacing the manual work with ease and comfort.

2.3 Risk Management:

Risks to patients, staff, and organizations are prevalent in healthcare. Thus, it is necessary for an
organization to have qualified healthcare risk managers to assess, develop, implement, and monitor risk
management plans with the goal of minimizing exposure. There are many priorities for a healthcare
organization, such as finance, safety, and, most importantly, patient care.

2.3.1 Risk Identification:

Risk identification is the first step in risk management which identifies all the different risks for a
particular project. The objective of the risk team is to first of all identify the application-oriented, non-
environmental risks associated with the application system. By identifying known and predictable risks,
the project manager takes a first step towards avoiding them when possible and controlling them when
necessary.

Following the possible risk of our project…

1. Schedule Risk

Project schedules get slipped when tasks and schedule release risks are not addressed properly. Schedule
risks mainly affect a project and, finally, on company's economy and may lead to project failure.

Schedule Risk occurs due to the following reasons.

a. Wrong time estimation.

b. Resources are not tracked properly. All resources like staff, systems, and skills of individuals.

c. Unexpected project scope expansions.

2. Budget Risk
Page | 7
 a. Wrong budget estimation.

b. Cost overruns.

c. Project scope expansion.

3. Technical Risks

Technical risks generally lead to failure of functionality and performance. The causes of technical risks
are:
a. Continuous changing requirements

b. The product is complex to implement.

c. No advanced technology is available, or the existing technology is in the initial stages.

Risk Analysis:

Risk analysis and Risk management are series of steps that help a software team to understand and
manage uncertainty. Many problems can destroy a software project. A risk is a potential problem-it might
happen or not. But, regardless of the outcome, it is an excellent idea to identify it, assess its probability of
occurrence, estimate its impact, and establish a contingency plan.

Risks are of two types:

1. Protective Risk

Proactive risk management attempts to reduce the tendency of any accident happening in the future by
identifying the boundaries of activities where a breach of the boundary can lead to an accident.
Proactive risk management combines a mixed method of past, present, and future prediction before
finding solutions to avoid risks.

2. Reactive Risk

Reactive risk management attempts to reduce the tendency of the same or similar accidents which
happened in the past to be repeated in the future. Reactive risk management solely depends on past
accidental analysis and response.

Risk Planning:

Project risk planning is a process for identifying how to carry out the activities of project risk
management. Its purpose is to determine actions to efficiently respond to the identified risks that have a
positive or negative effect on at least one project objective (such as cost, scope, performance, and time).
The risk planning process should result in developing a feasible and efficient plan for minimizing the risk
occurrence rate and exploiting available opportunities.

Page | 8
 Chapter 3: System Specifications
3.1 Use Case Diagram:

3.2. User requirements

3.2.1 Functional Requirements:

1. The system should enable patients and doctors to log in.

2. The system should enable patients and doctors to register.

3. The system should enable patients and doctors to log out.

4. The system should allow patients to book appointments.

Page | 9
 5. The system should allow patients to make inquiries.

6. The system should allow patients to search for available doctors.

7. The system should allow patients to modify or cancel their appointment.

8. The system should allow patients and doctors to view and modify their profiles.

9. The system should allow doctors to set their available time.

10. The system should enable the administrator to log in.

11. The system should allow the administrator to manage users

12. The system should enable the administrator to reply to inquiries.

13. The system should allow the administrator to delete past appointments.

14. The system should allow the administrator to manage & access the database.

3.2.2 Non-Functional Requirements

i. Reliability

• The system should be available when requested for service by users.

• The system should have a very low failure rate.

ii. Performance

• The system must have a good response time.

• The system should be able to achieve a lot in a specified amount of time.

• The system must run error free while operating with a huge set of data.

iii. Security

•All external communications between the system's data server and clients must be encrypted.

• The access permissions for system data may only be changed by the system's data administrator.

Page | 10
3.3 System Requirements:

1. Functional requirements

➢ The system should enable patients and doctors to log in.

• They shall enter their username and password.

• The information given shall be valid.

• Access shall be granted/denied.

➢ The system should enable patients and doctors to register. In the case of the patient, collect user
information (Names, Date of birth, address, telephone, email, password, etc.).

• Check if the information is valid:

• Password is not empty.

• Password and confirm password are the same.

• Email hasn't been used before.

• If information is valid, save and add the User to the database.

➢ The system should enable patients and doctors to log out.

• Log the User out when the User clicks the logout button.

➢ The system should allow Patients to book appointments.

• The system shall check if the patient is logged in or not.

➢ The system should allow patients to make inquiries.

• The system shall require the customer to give their email so a response can be sent.

• The system shall require a comment to be entered, describing whatever issues the customer would
like to know.

Page | 11
Non- functional Requirements

I. Reliability

• The system should be available when requested for service by users: The system should work
24/7, it should always be up and running so that whenever the User wants to use it, it is available.

• The system should have a lower failure rate: The failure rate should be kept as minimal as possible,
preferably less than 0.01.

II. Performance

• The system should be able to achieve a lot in a specified amount of time.

• The system should be able to withstand a heavy workload.

• It should be able to respond to multiple numbers of people at the same time.

III. Security

• All external communications between the system's data server and clients must be encrypted:

• To ensure that the system is secure, a user login screen will protect access to the various subsystems
and requires a username and password.

• The access permissions for system data may only be changed by the system's data administrator.

IV. Usability

• The system must be efficient for the frequent User.

• The system must be easy to remember for the casual User.

• The User must understand what the system does.

• The User must feel satisfied with the system.

V. Safety

• The system should maintain a good backup: Maintaining backups ensures that the system's database is
secured, which means that in case of an emergency or accident, the system can be easily restored.

Page | 12
 Chapter 4: System Analysis

4.1 Feasibility Study

The feasibility study is designed to determine whether or not, given the project environment, a project
will be successful. A feasibility study may be conducted for a project emphasizing financial viability,
environmental integrity, cultural acceptability, or political practicability. It is a determination of success
and a description of how that determination should be achieved.

It analyses different aspects like the cost required for developing and executing the system, the time
required for each phase of the system, and so on. It helps in identifying the risk factors involved in
developing and deploying the system and helps in planning for risk analysis. If these important factors
are not analysed, it would impact the organization and its development, and the system would fail.

There are three types of feasibility studies: Economic, technical, and behavioural.

4.2 Economic Feasibility:

Economic feasibility is the most frequently used method for evaluating the effectiveness of a system.
This is commonly known as a cost/benefit study. The procedure is to determine the benefit and savings
expected from a system and compare them with cost, whether it is economically feasible. If yes, the
decision is made to design and implement the system. It determines whether the software is within the
budget to develop or not.

4.3 Technical Feasibility:

Technical feasibility concerns the computer system, such as hardware, software, etc. This determines
whether or not the available technical system is feasible to run our project. Suppose the current computer
is operating at 80% load; running another application could overload the computer hardware or require
additional hardware. And it affects financial consideration to enhance this system. If the budget is
available, then you can enhance it. It is determining whether the current hardware and software is
sufficient to complete project work or not. If any user wants to use a website, then its device used to at
least contain any of the web browsers, about 4GB ram, etc.

4.4 Behavioral Feasibility:

People resist change, and computers have been known to facilitate change. It analyses how the user staff
behaves towards developing a new computerized system. Computer installation will affect transfer,
retraining, and changes in employee job status. So, it is understandable that the introduced system
requires special efforts to educate and train the staff to conduct business.

Page | 13
 Chapter 5: System Design

5.1 E R Diagram

Page | 14
5.2 Sequence Diagram

i. Sequence diagram on Login

Page | 15
ii. Sequence diagram on Registration

iii. Sequence diagram on search

Page | 16
iv. Sequence diagram on Book appointment

Page | 17
v. Sequence diagram on Cancel appointment

Page | 18
vi. Sequence diagram on Add available time

Page | 19
5.3 Data Flow Diagram

5.4 Data Structure Tables

Admin:

Page | 20
Doctor:

Patients:

Page | 21
Doctor's Availability:

Appointment Status:

Page | 22
 Chapter 6: Implementation Decisions
The system was implemented based on its functional requirements. Based on the functional requirements,
the system should have the following modules:

1. User module

This is the module in which User's activities would occur. It entails the following interfaces:

i. Login

ii. Registration

iii. Home page

iv. Doctor

v. Department

vi. Appointment

vii. Contact

viii. Account Profile

2. Admin module

This is the controller module that the administrator would use to monitor and control users and database
information; it entails the following interfaces:

i. Patient

ii. Doctor

iii. Department

iv. Hospital

v. Appointment

vi. Inquiries

vii. Settings

Page | 23
 Chapter: 7 Conclusion
In conclusion, we implemented all the functionalities stated in the requirement, all were tested, and it
showed that they are all working properly except for the mail functionality, which works perfectly fine
on the local server but not on the live server; this is because we are using a server that blocks the port for
mail. Also, we implemented the system requirement quality like responsiveness, so on different devices,
the system adapts to suit it. Also, it works on browsers like Safari and Google Chrome properly.

Page | 24
 CHAPTER: 8 References

https://creately.com/diagram/example/j2stjq662/doctor-patient-online-appointment-system-classic

"https://creately.com/diagram/example/j2stjq662/Doctor%20patient%20online%20appointment%2

0system" HYPERLINK

"https://creately.com/diagram/example/j2stjq662/Doctor%20patient%20online%20appointment%2

0system" HYPERLINK

"https://creately.com/diagram/example/j2stjq662/Doctor%20patient%20online%20appointment%2

0system"appointment%20system

https://www.freeprojectz.com/entity-relationship/doctor-

appointment-system-er-diagramhttps://stackoverflow.com/questions/16669197/doctor-scheduling-

database-design 23

Page | 25