1.

INTRODUCTION

1.1 Overview:

The “Online Doctor Appointment System” (Docpro) has been developed to override the

problems prevailing in the practicing manual system. This software is supported to eliminate

and in some cases reduce the hardships faced by this existing system. Moreover this system is

designed for the particular need of the company to carry out operations in a smooth and

effective manner.

The application is reduced as much as possible to avoid errors while entering the data. It also

provides error message while entering invalid data. No formal knowledge is needed for the

user to use this system. Thus by this all it proves it is user-friendly. Doctor Appointment

System, as described above can lead to error free, secure, reliable and fast management

system.

This web application provides doctor information, purchasing of medicines and according to

user’s needs they can book an appointment with the concerned doctor. This is designed to

assist in strategic planning and will help to ensure that your organization is equipped with the

right level of information and details for your future goals.

Page | 1
 1.2 Existing System:

The current system was manual where data is written on different pages and transferred to the

different departments, human errors were vulnerable since it was paper based and retrieval of

files was time consuming as they had to manually locate the patient some of which were even

lost and thus finding such information was hard. Per the statistics carried 90% of the users

were not contented with the system reason that is was not secure in terms of security and

storage as it was prone to damages like loss of important information, worn out papers, etc.

the speed of recording and retrieval of patients information was average yet 10% were some

ok with system reason that paper work can be used for future reference.

1.3 Proposed System:

The purpose of this system is to provide the users an easy and user friendly way to the users

to interact with the doctors according to the disease or symptoms of the patient. The user can

sign in or sign up and then interact with the doctors. Due to this online system it becomes

easy for the patients to book appointment as per their timings and no need to wait in a line to

visit a doctor like in manual system. The patients can even view the doctor details and then

book the appointment as per their needs.

The patients can even purchase the ointments or medicines as per the doctor prescribed. The

users can even ask the doctors if they have any queries. The users can even book for full body

check-up and can connect to right doctors at any time according to the specialities. The users

can even consult the doctors by booking the appointment with affordable prices. The users

can even provide a feedback according to their experience after using the website.

Page | 2
 2. Literature Survey

Appointment scheduling has become a complex task especially for healthcare

professionals like hospitals and clinics. Few reasons that could cause these complications

range from a heavy flow of patient traffic to physician that practices in a number of

clinics and moves from one medical facility to another. An ineffective appointment

management could also cause overlapping appointments, rise in number of no-shows,

patient dissatisfaction in general and revenue loss for healthcare institutions.

In recent days, many medical institutions use a combination of phone-based scheduling

and computerized scheduling. This online facility is effective add-on to any hospital or

clinic’s website. It lightens the hard work associated with managing a medical facility.

The key mission of online appointment scheduling is to reflect patient satisfaction and

revenue gains. An active appointment scheduling a bridge that connects efficient

healthcare services timely access to the services. The proposed system aims to even out

workflow and reduce the thronging of people in waiting rooms.

Similar Systems:

HSC Medical Center Appointment System:

Now a days the need to queue up for a long time to consult a doctor has minimized by

technological facilities available over internet. One such organization that has adopted

recent technological era named HSC Medical Center. The appointment system used by

HSC does not require any id and password to log-in before making any appointment and

appointment is valid within 24 hours only. The users are required to complete a form and

click submit button to finalize appointment.

Page | 3
 3. Hardware and Software Requirements

Hardware Requirements:

Primary Memory:

8GB RAM

Secondary Memory:

20GB of Storage

Monitor:

15’ and above

Software Requirements:

Development Framework:

PHP

Development Language:

HTML, Javascript, Jquery, Bootstrap, CSS

Database:

MY-SQL

Page | 4
 4. System Requirement Specifications

4.1 Introduction
The below subsections is System Requirements Specifications document that provides an
overview of entire system.

4.2 Purpose
The System Requirements Specification will provide a detailed description of the
requirements for “online doctor appointment system” (Docpro). This SRS will allow for
complete understanding of what is needed for the online doctor appointment system
construction. The clear understanding of Docpro and its functionality will allow for the
correct software to be developed for end user and thus will be sued for the development of
future stages of project. This SRS will also provide the foundation for the project. From this
SRS, the Docpro can be designed, constructed and finally tested.

This SRS will be used by the software engineers constructing the Docpro and the end users.
The software engineers will use SRS so that to fully understand the expectations of this
Docpro to construct the appropriate software. The Docpro end users will be able to use this
SRS as a test to see if the software engineers will be constructing the system to their
expectations. If it is not to their expectations then the end users can specify their choice and
the software engineers will change the SRS to fit the end user’s needs.

4.3 Document Conventions

 Database
 Entity Relationship

4.4 Intended Audience and Reading Suggestions

This project is a prototype for the doctor appointment system and it’s restricted within the
company premises. This has been implemented under the guidance of company owner and
directors. This project is useful for the hospital management team for appointment bookings
and for patients as well.

Page | 5
 4.5 Project Scope
The purpose of the online doctor appointment system is to ease appointment booking
management and to create a convenient and easy-to-use application for patients, trying to
book appointments. We will have a database server supporting hundreds of major doctors
around the country. Above all, we hope to provide a comfortable user experience along with
best doctors available.

4.6 References
 www.scribd.com
 www.github.com
 www.slideshare.com

Page | 6
 5. Overall Description

5.1 Product Perspective

The product being developed that is “Doctor Information System” is self-contained system
that manages the activities of hospital like-patient information.

This product is developed to provide details about the doctors and clinics. The doctors and
admin can view the patient’s information. The users or patients can even buy medicines
online with the help of this web application.

5.2 Product Functions

1. Users- The users can sign-up if they have not logged in to the system. The users can
login to book the appointment with the concerned doctor by selecting the date.

2. Doctors- Doctors can login through their username and password. Doctors can
manage the appointment by cancelling or confirming the appointment of the patient.
Every doctor has separate username and password for logging in into the system.

3. Admin- Admin can login through username and password. Admin has to manage the
doctors as well as the users. Admin has to manage the enquiries and the appointments
of the users.

5.3 User Characteristics and Classes

 Testers
 Test teams are continuously tasked with testing entire web applications faster
and more often.
 Qualitative assurance team
 Scrum teams - to effectively test the portability of their test cases and
application's functionality on a mobile platform.

5.4 Operating Environment

The product being developed provides a user friendly environment where the users can easily
login and can book the appointments as per their illness.

Software Configurations:
 Xampp Server
 MySql Database
 Language : PHP

Page | 7
 Hardware Requirements:
 Operating System : Windows 7 and above
 Processor: Intel core i5 or i7
 RAM : 2 GB or more

5.5 Design and Implementation Constraints:

 Database: The system shall use MySql database which is free and open source.
 Operating System: The development environment should be windows 7 and above.
 Web-Based: The system shall be web based application.

5.6 User Documentation:

Along with the software product, a user manual would be written to help people understand
the working methodology and usage of the developed prototype system.

5.7 Assumptions and Dependencies

It is assumed that there will be doctors from all over the world so that it becomes easy for the
user to book appointment from anywhere and visit the doctor.

Page | 8
 6. External Interface Requirements

6.1 User Interface

All interaction with the end-user should be via internet browser. The interface provided will
be graphical. This interface will authenticate the patient and will allow him to make
appointment request s and will also allow the doctor to go through the symptoms of the
patient through online interface. The application will also support a chatting room where the
patients can chat with the doctor.

6.2 Hardware Interface

The minimum hardware requirements are 4GB RAM, 20GB of storage.

6.3 Software Interface

The system uses PHP for development and MySQL version 5.6 for the storing the data in the
database. Docpro is an “Online Doctor Appointment” which communicates via browser.

6.4 Communication Interface

Docpro requires an internet connection to communicate with the patients and mysql server to
store the data.

Page | 9
 7. System Features
This section demonstrates Docpro most prominent features and how they can be used and
results they will give back to the user.

7.1 Functional Requirements

Functional requirements define fundamental actions that system must perform.

7.2 Login/ Signup

1.1 The system shall record the signup.
1.2 The system shall record patient’s id.
1.3 The system shall record password of patient.
1.4 The system shall record number of patients.

7.3 Booking
2.1 The system shall record the patient details.

2.2 The system shall record the booking details.

2.3 The system shall record the date of the booking.

Page | 10
 8. Non-Functional Requirements
Functional requirements define the needs in terms of performance, logical database
requirements, design constraints, standards compliance, reliability, availability, security,
maintainability and as well as portability.

8.1 Performance Requirements

It defines the acceptable response times for system functionality.

 The load time for user interface screen shall take no longer than 2 seconds.
 The log in information shall be verified within 5 seconds.
 Queries shall return within 5 seconds.

8.2 Safety Requirements

The data in this system is totally secured as without login the user/patient cannot book the
doctor’s appointment. So due this feature, the data will remain safe from any loss or damage.

8.3 Security Requirements

The bookings made by the patients are scheduled, deleted or updated by the admin or doctor
according to their availability.

8.4 Software Quality Attributes

 Code efficiency
 Save energy and less human error
 Response time
 Security
 Simple and easy code

8.5 Reliability
The system provides a storage to record the data in the database. The main pillar of reliability
of the project is the admin part where each and everything of the system is controlled by the
admin like appointments, adding or updating doctors, etc. thus, the overall stability of the
system depends on the stability of the container and its operating system.

Page | 11
 9. Other Requirements

9.1 Logical Database Requirements

It includes the retention of the following data elements.

 Patient’s id.
 Patient’s password.
 Booking date.
 Doctor details

10. System Design Description

10.1 Introduction

Software design is the process of implementing software solutions to one or more set of

problems. The software design document contains a statement of the design of Docpro. The

design contains an explanation of a way to carry out each of the product specification written

in Software Requirement Specification. The design serve as a guide to the developer. The

SDS also shows how the program is separated by modules, how the modules interact with

each other and how user sees the program.

10.1.1 Purpose

This document is designed to be a reference for any person wishing to implement or any

person interested in the design architecture of Docpro. This document describes each

application’s architecture and its associated interfaces and database design. This design will

detail the implementation of the requirements as defined in Docpro system specification

design.

Page | 12
 10.1.2 Scope

The adaptability of online doctor appointment system enhances services provided by

hospitals. This is a great way of assembling all the appointments from the website. It delivers

flexibility and simplicity to patients, that’s the reason online doctor appointment systems are

becoming popular now a days.

10.1.3 References

 www.scribd.com

 www.slideshare.com

 www.github.com

10.1.4 Overview

This document includes but is not limited to the following information for Docpro “Online

Doctor Appointment System”; system overview, design consideration, architectural strategy,

system architecture, policies, database schemas, detailed system design.

10.1.5 Intended Users

This document should be read by an individual with a technical background and has

experience reading DFDs, control flow diagrams, interface design and development

experience in event driven programming.

Page | 13
10.2 System Overview

10.2.1 Architecture Design

Page | 14
 10.2 Data Dictionary

Entity Element Definition Type Storage Scale Bounds Display Mandatory Default Modified constraints

name name format entry fill value value

format

Signup Email id User Varchar Small Na Na Required na Na Must be

email id alpha, valid id

Signup Password User Varchar Value Na Na hidden required na na Must be

password must be 6 minimum

minimum 6

Signup Name User string Up to 15 na na required na na

name char

Signup Mobile User int 10 digits na na digits required na na Must be

No contact valid 10

no digit no

Admin username Admin string Up to 10 na na chars required na na

username char

Admin Password Admin Varchar Minimum na na required na na

password 6

Page | 15
10.3 Functional Design

10.3.1 Use Case Diagram

User:

Page | 16
Admin:

Page | 17
 10.4 Behavioral Diagram

10.4.1 Activity Diagram

Activity-Main

Page | 18
Activity-User

Page | 19
State Diagram

Page | 20
Sequence Diagram:

Page | 21
 10.5 Data Design

10.5.1 Data Structure

Table: Doctor

Column Name Type Data Type Length Description

Id Primary key Integer 11 Unique id for

doctor record

Username String 100 Name of doctor

Password Varchar 100 Password of

doctor

Table: Medicine

Column Name Type Data Type Length Description

Id Primary key Integer 11 Unique id for

medicine record

Medicinename String 200 Name of the

medicine

Type String 100 Type of medicine

Price Integer 11 Price of medicine

Description String 150 Detail of

medicine

Image Image Stores image of

medicine

Manuf_date Date Stores

manufacturing

date of medicine

Page | 22
Table: Users

Column name Type Data Type Length Description

Id Primary key integer 11 Unique id for user

record

Fullname string 100 Name of the

patient

Mobile_no Integer 10 Contact number

of patient

Email_id varchar 100 Email id of

patient

Password Varchar 100 Password of

patient

Table: Admin

Column name Type Data type Length Description

Id Primary key Integer 11 Unique id for

admin record

Username String 100 Name of admin

Password Varchar 100 Password of

admin

Page | 23
Table: Booking

Column name Type Data type Length Description

Booking_id Primary key Integer 11 Unique id for

booking record

Doctor name String 100 Name of the

doctor

Doctor type String 50 Type of doctor

Location varchar 100 Location of clinic

or hospital

Fees Integer 50 Fees of doctor

Image Image Image of doctor

Page | 24
 10.5.2 Functional Design

Class Diagram

Page | 25
 10.6 Database Description

User’s table:

Name Type

Id Int

Fullname String

Mobile_No Int

Email_id Varchar

Password Varchar

Admin Table:

Name Type

Id Int

Username String

Password string

Doctor Table:

Name Type

Id Int

Username String

Password varchar

Page | 26
Booking Table:

Name Type

Booking_id Int

User_emailid Varchar

Date Date

Doctor Table:

Name Type

Doctor_id Int

Doctor_name String

Doctor_type String

Designation String

Fees Int

Image image

Medicine Table:

Name Type

Id Int

Medicine_name String

Type String

Packing String

Price Int

Image Image

Manufacturing_date Date

Description String

Page | 27
 10.7 Human Interface Design

10.7.1 Overview of User Interface

Name Description

Login Login into system as admin or doctor

Appointments Modify, cancel or confirm appointments

Admin Add or update doctor, cancel or confirm appointments

User Login or signup to system, search a doctor, book

appointment as per need

Feedback Users can provide feedback as well

Page | 28
 11. Implementation
12. Algorithm for user
13. step 1: start
14. step 2: If you are new user than sign in or else go to the
step 3
15. step 3: Enter the email id and password (Log in detail)
16. step 4: if email id and password is not correct (Log in
detail) than go to
17. step 3 otherwise go to step 5
18. step 5: Doctor's list
19. step 6: select the symptoms
20. step 7: select the doctor according to the symptoms
21. step 8: select the date and book the appointment.
22. step 9: stop
23.
24. Algorithm for admin
25. step 1: start
26. step 2: Enter the email i and password (log in detail)
27. step 3: if email id and password is not correct than go to
step 2
28. otherwise go to step 4
29. step 4: see the doctor detail and patient detail
30. step 5: add the doctor and edit the doctor details.
31. step 6: if required admin can modified the appointment of
patient
32. step 7: check the feedback of the doctor
33. step 8: stop
34.
35. Algorithm for doctor
36. step 1: start
37. step 2: enter the email id and password (log in detail)
38. step 3: if email id and password is not correct than go to
step 2
39. otherwise go to step 4
40. step 4: Check the appointments
41. step 5: check the feedbacks
42. step 6: stop

Page | 29
 12. Testing

 Unit Testing

Unit testing would allow the developer to test individual software components of the Online

Doctor Appointment System. Since the developer would follow agile method during

development phase, unit testing will be critical.

It would help the developer to schedule the agile development. The developer would be able

to verify segments of the system as well as determine the stability of modules developed.

This way the developer is also to detect and fix errors based on priority.

This section is to undertake a small part of unit testing to see whether it runs with

deliverables as expected.

Each unit of the system is would be tested individually to assure desired deliverables. Only

after each unit is tested properly, the process follows to the next phase.

Module: Login

No Test Cases Actual Results Expected Results

1 leave email and password field warning message displayed to As expected

empty prompt email and password

2 Enter invalid email and password Warning message displayed login as expected

failed

3 Enter valid and password Message displayed showing that As expected

login is successful

Page | 30
Module: Sign-Up

No Test Case Actual result Expected result

1 Leave email and Warning message As expected

password field empty displayed to prompt email

and password

2 Enter email id that Warning message As expected

already exists displayed showing email

id already exists

3 Enter email and Warning message As expected

unmatched passwords displayed enter password

correctly

4 Enter email id and Message displayed As expected

password correctly showing that sign-up is

successful

Page | 31
  Integration Testing

Integration Testing involves two-tested unit being linked into a fundamental. For example,

when a patient selects a physician from a doctor list of specific department, the system will

collect that physician’s details from database and show it in front-end view for the patient.

For the test to run, hypothetical data would be input into database to check system

functionality.

Integration Testing: Login and Sign-Up

No Test Case Actual Results Expected Results

1 Enter no email id and Warning message As expected

password displayed to prompt email

id and password

2 Enter email id which Warning message As expected

already exists displayed that email id

already exists

3 Enter newly registered Message displayed As expected

email and password and showing that login is

press login successful

Page | 32
 13.Reports

Sign-up Page:

Page | 33
Admin Login Page:

Admin page:

Page | 34
Doctor-login:

Doctor Page:

Page | 35
Appointment Page:

Doctors-list:

Page | 36
 14.Conclusion

 From the “Online Doctor Appointment” system we can conclude that it is developed

for the patients who can easily contact to the doctors through chat or call.

 The users or patients can even order medicines online through this website.

 This website is user friendly and easy for any user who wants to have an access to it.

 The patient can easily signup or login and can book an appointment by choosing the

doctor from the list according to their need.

Page | 37
 15. Future Scope

 It can be hosted as a web application in future so that it can be downloaded as an app.

 The patients will be even able to print their appointment details.

 Backup mechanism will be implemented on regular basis on different servers.

 More facilities will be provided in future if needed.

Page | 38
 16.Bibliography

 www.scribd.com

 www.slideshare.com

 www.github.com

Page | 39
 17.User Manual

a. Introduction

Docpro “online doctor appointment system” is developed using PHP and MYSQL version

5.6 to assist administrator and users on their day to day operations in running of the company.

The user manual is designed to assist the user in the effective use of system and to assist in

user registration showing all operations performed in the system and how to perform.

b. Specifications

This system has been built on specifications and some assumptions have been made which

must be known to the user.

Features of system:

 The system is capable of holding the patient details as well as booking details and be

retrieved.

 Records can be deleted from database to update records or edit system after given

period of time.

c. Requirements

Installation of valid software is needed before user can interact with the system

Hardware Requirements:

 Pentium 4 or above computer

 I5 or above processor

 4GB of RAM

 50GB Hard Disc.

Software Requirements:

 Windows 7 or above operating system

 MYSQL version 4 or above

Page | 40
User Signup Page:

This page is used by the user to create new account if the user is new.

Page | 41
User Sign-in Page:

This page is for the user who is existing or even a new user after creating an account can

sign-in to the system.

Page | 42
User-Page:

This page is called a user page where the user can change the existing password.

Page | 43