ABSTRACT

Our project Hospital Management system includes registration of patients, storing

their details into the system, and also booking their appointments with doctors.
Our software has the facility to give a unique id for every patient and stores the
details of every patient and the staff automatically. User can search availability
of a doctor and the details of a patient using the id. The Hospital Management
System can be entered using a username and password. It is accessible either by
an administrator or receptionist. Only they can add data into the database. The
data can be retrieved easily. The interface is very user-friendly. The data are
well protected for personal use and makes the data processing very fast.

It is having mainly two modules. One is at Administration Level and other one is
of user I.e. of patients and doctors. The Application maintains authentication in
order to access the application. Administrator task includes managing doctors
information, patient’s information. To achieve this aim a database was designed
one for the patient and other for the doctors which the admin can access. The
complaints which are given by user will be referred by authorities.
The Patient modules include checking appointments, prescription. User can also
pay doctor’s Fee online.

Table of Contents

SNO TOPIC Page No

1. PROBLEM STATEMENT 9
2. PROCESS MODEL 11
3. SOFTWARE REQUIREMENTS 15
SPECIFICATION

1|Page
 4. CONTEXT LEVEL DIAGRAM 18
5. DFD LEVEL 1 19
6. DFD LEVEL 2 20
7. USE CASE DIAGRAM 24
8. USE CASE DESCRIPTION 25
9. DATA DICTIONARY 35
10. ER DIAGRAM 36
11. DATA DESIGN 37
12. COMPONENT LEVEL DIAGRAM 40
13. PROJECT SCHEDULING 44
14. TIMELINE CHART 45
15. FUNCTION POINT METRICS 46
16. COCOMO MODEL 52
17. SAMPLE SCREENSHOTS 56
18. RISK ANALYSIS 68
19. TESTING 69
20. CONCLUSION 74

LIST OF FIGURES USED IN THE PROJECT

FIGURE_NO NAME PAGE No

2.1 CONTEXT LEVEL DFD 18

2.2 LEVEL – 1 DFD 19

2.3 LEVEL – 2 REGISTRATION 20

2.4 LEVEL – 2 LOGIN 20

2.5 LEVEL – 2 MAKE APPOINTMENT 21

2|Page
2.6 LEVEL – 2 ADD DESCRIPTION 21

2.7 LEVEL – 2 DOCTOR MODULE 22

2.8 LEVEL – 2 PAYMENT 22

2.9 LEVEL – 2 CANCEL APPOINTMENT 23

2.10 LEVEL – 2 PAITENT MODULE 23

6.1 HOME PAGE 57

6.2 SELECT LOGIN 57

6.3 PATIENT LOGIN PAGE 58

6.4 REGISTRATION 58

6.5 PATIENT PROFILE 59

6.6 PATIENT UPDATE DETAILS 59

6.7 PATIENT BOOK APPOINTMENT 60

6.8 PATIENT APPOINTMENT STATUS 60

6.9 PATIENT CANCEL APPOINTMENT 61

6.10 PAYMENT 61

6.11 PATIENT PAYMENT RECIPET 62

6.12 PATIENT VIEW PAYMENT HISTORY 62

6.13 PATIENT VIEW DOCTORS 63

6.14 DOCTOR LOGIN PAGE 63

6.15 DOCTOR PROFILE 64

6.16 DOCTOR VIEW APPOINTMENT 64

6.17 DOCTOR ADD DESCRIPTION 65

6.18 ADMIN LOGIN PAGE 65

6.19 ADMIN ADD DOCTOR 66

6.20 ADMIN UPDATE DOCTOR DETAILS 66

3|Page
6.21 ADMIN PAYMENT REQUEST 67

6.22 ADMIN VIEW RECORDS 67

LIST OF TABLES USED IN THE PROJECT

TABLE NO NAME PAGE NO

4.1 DATA DICTIONARY 38

4.2 PATIENT 40
4.3 APPOINTMENT 40
4.4 DOCTOR 41
4.5 PRESCRIPTION 41
4.6 ADMIN 42
4.7 BILL 42
5.1 PROJECT SCHEDULING 44
5.2 TIMELINE CHART 45
5.3 FUNCTION POINT COMPLEXITY 49
WEIGHTS
5.4 COCOMO II COMPLEXITY 52
WEIGHTS
PRODUCTIVITY RATE FOR 53
5.5 OBJECT POINT COUNTS
7.1 RISK ANALYSIS 68

PROBLEM STATEMENT

4|Page
In this busy world we don’t have the time to wait in infamously long hospital
queues. The problem is, queuing at hospital is often managed manually by
administrative staff, then take a token there and then wait for our turn then ask
for the doctor and the most frustrating thing - we went there by traveling a long
distance and then we come to know the doctor is on leave or the doctor can’t
take appointments.

HMS will help us overcome all these problems because now patients can book
their appointments at home, they can check whether the doctor they want to
meet is available or not. Doctors can also confirm or decline appointments, this
help both patient and the doctor because if the doctor declines’ appointment
then patient will know this in advance and patient will visit hospital only when
the doctor confirms’ the appointment this will save time and money of the
patient.

Patients can also pay the doctor’s consultant fee online to save their time.

HMS is essential for all healthcare establishments, be it hospitals, nursing

homes, health clinics, rehabilitation centers, dispensaries, or clinics. The main
goal is to computerize all the details regarding the patient and the hospital. The
installation of this healthcare software results in improvement in administrative
functions and hence better patient care, which is the prime focus of any
healthcare unit.

Benefits of implementing a hospital management system:

• Appointment booking o Helps patients cut the long

queue and saves their time o Is equipped with
features like automated email and text message
reminders
• Role-Based Access Control o Allows employees to
access only the necessary information to effectively
perform their job duties
o Increases data security and integrity

5|Page
 • Overall cost reduction o Cuts down paper costs as all
the data are computerized o No separate costs for
setting up physical servers

• Data accuracy o Removes human errors

o Alerts when there’s a shortage of stock

• Data security o Helps to keep patients records private

o Restricts access through role-based access control

• Revenue management
o Makes daily auditing simple
o Helps with statistics and other financial aspects

PROCESS MODEL

Hospital Management System follows INCREMENTAL MODEL

because initially software requirements are reasonably well defined
but the overall scope of development effort is a purely linear process.
There may be other requirements of the user which will be known
later. So, those requirements can the implemented and delivered in
the following next increments. Our project is a short term project of 3
months and 3 weeks only and staffing available is also low (3
persons).

6|Page
 CHAPTER 1
INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS
1.4 REFERENCES
1.5 OVERVIEW

1.1 PURPOSE

This software will help the company to be more efficient in registration of their
patients and manage appointments, records of patients. It enables doctors and
admin to view and modify appointments schedules if required. The purpose of
this project is to computerize all details regarding patient details and hospital
details.

1.2 SCOPE

The system will be used as the application that serves hospitals, clinic,
dispensaries or other health institutions. The intention of the system is to
increase the number of patients that can be treated and managed properly.

7|Page
If the hospital management system is file based, management of the hospital
has to put much effort on securing the files. They can be easily damaged by fire,
insects and natural disasters. Also could be misplaced by losing data and
information.

1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS

1. Cardiologist - treats heart disease.

2. Pediatrician - treats infants, toddlers, children and teenagers.
3. Plastic Surgeon - restores, reconstructs, corrects or improves in the shape and
appearance of damaged body structures, especially the face.
4. Psychiatrist - treats patients with mental and emotional disorders. 5.
Ophthalmologist - treats eye defects, injuries, and diseases
6. ENT- Ear, Nose and Throat Specialist.

• SRS: Software Requirement Specification.

• DFD: Data Flow Diagram.
• ENT- Ear, Nose and Throat Specialist.
• BG - Blood group

✓ Appt – Appointment.
✓ Sign up - Creating New User.
✓ Log in - Logging in Existing User.
✓ PhNo - Mobile number.
✓ Addr – Address.
✓ Expr – Experience.

1.4 REFERENCES

➢ [Link]
➢ [Link]
systemfeatures-objectives-62eeb13f4fc4

8|Page
 ➢ R.S Pressman, Software Engineering: A Practitioner’s Approach, Mc-Graw-
Hill, Edition-7 (2010).
➢ P. Jalote, an Integrated Approach to Software Engineering, Narosa
publication house, Edition -3 (2011).

1.5 OVERVIEW

Our application contains two modules – the admin module and the user
module. Our application will not only help the admin to preview the
monthly and/or yearly data but it will also allow them to edit, add or
update records. The software will also help the admin to monitor the
transactions made by the patients and generate confirmations for the
same. The admin will be able to manage and update information about
doctors.
The user module can be accessed by both the doctors and the patients.
The doctor can confirm and/or cancel appointments. The doctors can
even add prescriptions for their patients using our application. The
patients will be able to apply for the appointment and make transaction
for the same, and can even cancel appointments with the doctors. They
can track details about the previous transactions made by them.

Advantages

• The system automates the manual procedure of managing hospital

activities.
• Doctors can view their patients’ treatment records and details easily.
• It even generates an instant bill.
• The system is convenient and flexible to be used.
• It saves their time, efforts, money and resources.

Disadvantages

9|Page
• Requires large database.
• The admin has to manually keep updating the information by entering the
details in the system.
• Need Internet connection.

CHAPTER 2
SOFTWARE REQUIREMENT
SPECIFICATION
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 System Specifications
[Link] H/W Requirement
[Link] S/W Requirement
2.1.3 Communication Interfaces
2.2 Product functions
2.3 Data Flow Diagram (DFD)
2.3.1 Context Level Diagram
2.3.2 DFD Level – 1
2.3.3 DFD Level – 2
2.4 Use Case Diagram
2.5 Use Case Description
2.6 User characteristics
2.7 Constraints

10 | P a g e
 2.8 Assumptions and dependencies

2.1 Product Perspective

This Hospital Patient Info Management System is a self-contained system that

manages activities of the hospital.
Due to improperly managed details medical center faces quite a lot of
difficulties in accessing past data as well as managing present data. The fully
functional automated hospital management system which will be developed
through this project will eliminate the disadvantages caused by the manual
system by improving the reliability, efficiency and performance. The usage of a
database to store patient, employee, stock details etc. will accommodate easy
access, retrieval, and search and manipulation of data. The access limitations
provided through access privilege levels will enhance the security of the system.
The system will facilitate concurrent access and convenient management of
activities of the medical center.

2.1.1 System Interfaces

❖ User Interfaces
▪ This section provides a detailed description of all inputs into and outputs
from the system. It also gives a description of the hardware, software
and communication interfaces and provides basic prototypes of the user
interface.
▪ The protocol used shall be HTTP.
▪ The Port number used will be 80.
▪ There shall be logical address of the system in IPv4 format.

❖ Hardware Interfaces
▪ Laptop/Desktop PC-Purpose of this is to give information when Patients
ask information about doctors, medicine available lab tests etc. To
perform such Action it need very efficient computer otherwise due to
that reason patients have to wait for a long time to get what they ask for.
▪ Laser Printer (B/W) - This device is for printing patients’ info etc.

11 | P a g e
 ▪ Wi-Fi router - Wi-Fi router is used to for internetwork operations inside
of a hospital and simply data transmission from pc’s to sever.

❖ Software Interfaces
▪ JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers,
game consoles to scientific supercomputers, cell phones to the Internet,
▪ Mysql server - Database connectivity and management
▪ OS Windows 7/8/8.1- Very user friendly and common OS
▪ JRE 1.8 - JAVA Runtime Environment for run Java Application and System

2.1.2 System Specifications

[Link] H/W Requirement

 Core i5 processor  2GB Ram.
 20GB of hard disk space in terminal machines
 1TB hard disk space in Server Machine

[Link] S/W Requirement

 Windows 7 or above operating system
 JRE 1.8
 Mysql server

2.1.3 Communication Interfaces

 NIC (Network Interface Card) – It is a computer hardware component

that allows a computer to connect to a network. NICs may be used for
both wired and wireless connections.
 CAT 5 network cable- for high signal integrity
 TCP/IP protocol- Internet service provider to access and share
information over the Internet
 Ethernet Communications Interface- Ethernet is a frame-based
computer network technology for local area networks (LANs)

12 | P a g e
  Ubiquitous, easy to set up and easy to use. Low cost and high data
transmission rate.

2.2 Product functions

o Provide access to registered users only.

o Registration of new patients. o Enable patient to view their record. o Enable
patient to update their record. o Generate appointment date and timing.
o Confirmation by doctor. o Patients can do Payment. o Modification in
schedule by patient. o Admin access to patient’s record.
o Admin Verify Payment and Generate Bill/Receipt.
o Admin can view monthly/yearly records.

2.3 DATA FLOW DIAGRAM (DFD)

CONTEXT LEVEL DIAGRAM

13 | P a g e
FIGURE 2.1 CONTEXT LEVEL DFD

DFD LEVEL – 1

14 | P a g e
FIGURE 2.2 LEVEL – 1 DFD

15 | P a g e
FIGURE 2.3LEVEL – 2 Registration

FIGURE 2.4
LEVEL– 2 Login

16 | P a g e
FIGURE 2.5LEVEL – 2 Make Appointment

17 | P a g e
FIGURE 2.6 LEVEL – 2 Add Description

FIGURE 2.7LEVEL – 2 Doctor Module

18 | P a g e
FIGURE 2.8LEVEL – 2 Payment

19 | P a g e
 FIGURE 2.9 LEVEL – 2 Cancel Appointment

FIGURE 2.10 LEVEL – 2 Patient Module

20 | P a g e
2.4 USE CASE DIAGRAM

21 | P a g e
2.5 USE CASE DESCRIPTION

(1) PATIENT

* REGISTRATION

DESCRIPTION - The new patient can register themselves and add their details like
name, age , gender, blood group etc. The patient entry will be made in the hms
database.

PRE -CONDITION – The patient must be a new patient, If necessary fields left by
user then prompt user to fill the necessary fields.

MAIN FLOW OF EVENTS

1. Patient selects sign up in login
module. 2. A registration form get
displayed
3. Patient fills the required details.

POST CONDITIONS - Patient record is added to hms database.

* UPDATION

DESCRIPTION-The patient should be enabled to update his/her details and the

changes should reflect in hms database.

PRE-CONDITION – The patient must be a registered patient, The patient cannot

update details after treatment starts.

MAIN FLOW OF EVENTS

1. Patient logs in to the system.
2. Patient view his record
3. Patient selects update details.

22 | P a g e
4. Now patient may change the necessary fields.
5. Pop of update details.

POST CONDITION - The record of patient is updated in hms database.

*APPOINTMENT

DESCRIPTION - It shows users a list of available doctors, timings, dates and

enables patients to select the most suitable appointment date and doctor. The
patient may also the cancel the appointment.

PRE-CONDITION - The patient must be a registered patient, Patient can fix only one
appointment for a particular department.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Create a new appointment or cancel the appointment..

POST CONDITIONS - patient details are displayed and a new appointment is fix or a
existing appointment is cancelled. The hms database is updated.

*PAYMENT

DESCRIPTION – It enables user to pay the consultant fee of Doctor online.

PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants

to pay online he/she can pay by cash also.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.

23 | P a g e
3. Appointment confirmed by the Doctor then go for Payment.

POST CONDITIONS – A Reciept will be displayed. The hms database is updated

(2) DOCTOR

DESCRIPTION- The doctor view patient record/ update his details and add
description of the treatment given to patient.

PRE-CONDITION – The doctor must be a registered doctor, System does not allow
the doctor to modify the qualification, hospital managed details.

MAIN FLOW OF EVENTS

[Link] logs in to the system.
2. Doctor may select view patient.
2.1 Patient record is displayed with treatment history.
3. Doctor add description of patient treatment.
4. Doctor may select appointment details
4.1 Appointment Requests is displayed with schedule.
5. Doctor confirm or cancel appointment.

POST CONDITION – The patient and doctor ‘s database are updated.

(3) ADMIN

DESCRIPTION - The admin add doctor, update docotr details and verify payment
and generate Bill/Reciept for the same.

MAIN FLOW OF EVENTS

1. Admin logs in the system.
2. Admin may add doctor new doctor.
2.1 admin fills the doctor’s details.
3. Admin view Doctor record.
3.1 Admin enters the doctor id in the system.

24 | P a g e
 3.2 Doctor details are displayed, Admin can update details.
4. Admin Verify the payment submited by the Patient.
4.1 Generate Bill/Reciept and confirmation message for the same.

PRE –CONDITION - Admin must first log in with his/her credentials.

POST CONDITION - The hms database is updated.

2.6 User characteristics

ADMIN
Admin has the full access to the system which means he is able to manage any
activity with regard to the system. He is the highest privileged user who can
access to the system.

Key functions:
•Access patient record, doctor Record.
•Add new doctor entry in system database.
• Confirm Payment and Generate Bill.
• View Records.(Total no of patients treated, doctor added/remove, consultant
fee).

PATIENT
Patients can choose the best preferred appointments from the options provided
and can also change the appointment schedule or cancel it. After appt. is
confirmed by the respective doctor they can pay their consultant fee online.
Patients have access to only their records.

Key functions:
• Make appointment.
• Cancel appointment.
• Update Details.
• Payment.

25 | P a g e
• View Payment History.
DOCTOR
Doctors can view the patient appointment list and provide the confirmation or
make changes in the appointment list if required. Doctors have access to only
records of those patients whom they are treating.

Key functions:
• Confirmation of appointment.
• Cancellation of appointment.
• Modification of appointment list.
• Add Prescription.

2.7 Constraints

• System is wirelessly networked with an encryption.

• System is only accessible within the hospital’s website only.
• Database is password protected.
• Should use less RAM and processing power.
• Each user should have individual ID and password.
• Only administrator can access the whole system.

2.8 Assumptions and dependencies

▪ Each user must have a valid user id and

password ▪ Server must be running for the
system to function ▪ Users must log in to
the system to access any record.
▪ Only the Administrator can delete records.

26 | P a g e
 CHAPTER 3 SPECIFIC
REQUIREMENTS
3.1 Performance requirements
3.2 Safety requirements
3.3 Security constraints
3.4 Software system attributes
3.4.1 Usability
3.4.2 Availability
3.4.3 Correctness
3.4.4 Maintainability
3.4.5 Accessibility
3.5 Functional Requirements

3.1 PERFORMANCE REQUIREMENTS

27 | P a g e
 o Response time- The system will give responses within 1 second after checking
the patient information and other information. o Capacity-The system must
support 1000 people at a time o User interface- User interface screen will
response within 5 seconds

3.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to catastrophic
failure, such as a disk crash, the recovery method restores a past copy of the
database that was backed up to archival storage and reconstructs a more current
state by reapplying or redoing the operations of committed transactions from the
backed up log, up to the time of failure. All the administrative and data entry
operators have unique logins so system can understand who is login in to system
right now no intruders allowed except system administrative nobody cannot
change record and valuable data.

3.3 SECURITY REQUIREMENTS

1. Want take the responsibility of failures due to hardware malfunctioning.

2. Warranty period of maintaining the software would be one year.
3. Additional payments will be analyzed and charged for further maintenance.
4. If any error occur due to a user’s improper use. Warranty will not be allocated to
it.
5. No money back returns for the software.

3.4 SOFTWARE SYSTEM ATTRIBUTES

3.4.1 Usability: Software can be used again and again without distortion.

3.4.2 Availability: The system shall be available all the time.

3.4.3 Correctness: Bug free software which fulfills the correct

need/requirements of the client.

28 | P a g e
 3.4.4 Maintainability: The ability to maintain, modify information and
update fix problems of the system.

3.4.5 Accessibility: Administrator and many other users can access the
system but the access level is controlled for each user according to their work
scope.
3.5 FUNCTIONAL REQUIREMENTS

[Link]. MODULE APPLICABLE DESCRIPTION

NAME ROLES
1. LOGIN PATIENT PATIENT: Can login using unique Id and
DOCTOR Password after this system shall show his/her
ADMIN profile.

DOCTOR: Can login using unique Id and

Password after this system shall show his/her
profile.

ADMIN: Can login using unique Id and

Password after this system shall show a
profile with links to maintain the website.
2. REGISTRATION PATIENT PATIENT: Can Register by filling all the
required details, after this the system will
verify the details and check if already
registered or not.
3. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and
make an appointment request after this
system shall show a confirmation for
appointment request.
4. CANCL APPT. PATIENT PATIENT : Can Cancel appointment if want to
DOCTOR by just one click after this system shall ask
for re-schedule or refund of payment.

29 | P a g e
 DOCTOR : Can Cancel appointment if want
to by just one click after this system shall
send a message to the patient.
5. PAYMENT PATIENT PATIENT : Enter payment details and make
payment after this system shall show the
generated bill by the hospital.
6. DOCTOR ADMIN ADMIN : Can add a new doctor by filling all
MODULE the details after this system shall show a
confirmation message.
Can Remove a doctor by just one click after
this system shall show confirmation
message.
7. PATIENT PATIENT PATIENT : Can view payment history or can
MODULE search for a particular bill also after this
system shall show a bill or history.

Can also See or search for a doctor by

entering dept. name or doctor id if known
after this system will check for the doctor if
found shall show doctor’s profile.

Can also update details after this system shall

ask for re-enter password and after verifying
password shall update details.
8. ADD DOCTOR DOCTOR : Enter Patient Id and after this all
PRESCRIPTION the treatment details and medicine, remark
and advice for the patient after this system
shall show a message for update.

30 | P a g e
 CHAPTER 4
DESIGN
4.1 Data Dictionary
4.2 ER Diagram
4.3 Data Design
4.4 Component Level Diagram

31 | P a g e
4.2 ER DIAGRAM

32 | P a g e
33 | P a g e
34 | P a g e
4.3 DATA DESIGN

DESCRIPTION
S NO. COLUMN DATA CONSTRAINTS
NAME TYPE

1. P_ID Varchar(50) Primary Key Contains Unique Id

2. Name Varchar(50) - Contains Name
3. DOB Varchar(50) - Contains Date Of Birth

4. Gender Varchar(50) - Contains Gender

5. Blood Group Varchar(50) - Contains Blood Group
6. Email ID Varchar(50) - Contains Email Id
7. Address Varchar(50) - Contains Address
8. Mobile No. Integer - Contains Mobile No.
9. CGHS/Private Varchar(50) - Contains Category
Table 4.2 Patient

DESCRIPTION
S NO. COLUMN DATA CONSTRAINTS
NAME TYPE

1. P_ID Varchar(50) Primary Key Contains Unique Id

Patient
2. Specialization Varchar(50) - Contains Name of the
Department in which
Patient wants to visit
3. Doctor’s Name Varchar(50) - Contains Doctor
Name Patient Wants
To Visit
4. Consultant Fee Integer - Contains Consultant

35 | P a g e
 Fee Of Doctor
5. Date Date - Contains Date For The
Appointment
6. Time Time - Contains Time For The
Appointment
Table 4.3 Appointment

CHAPTER – 9
CONCLUSION

Working on the project was an excellent experience. It helped us to understand the

importance of planning, designing and implementation so far we have learnt in our
theory books. It helped us unleashing our creativity while working in a team. It also
realized the importance of team working, communication as a part of this project.

The project was successfully completed after a lot of efforts and work hours. This project
underwent number of compiling, debugging, removing errors, making it bug free,
adding more facilities in Hospital Management System and interactivity making it more
reliable and useful.

36 | P a g e
This project focused that scheduling a project and adhering to that schedule creates a
hard sense of time- management. It has also let us known that co-operative teamwork
always produce effective results.

The entire project has been developed and deployed as per the requirements stated by
the user. It is found to be bug free as per the testing standards that are implemented.

The estimated cost of the project is (efforts) 12 and the estimated size of the project is
(FP) 209.72.

There are also few features which can be integrated with this system to make it more
flexible. Below list shows the future points to be consider :
• Getting the current status of patient.
• Including a different module for pharmacy, LAB, Bed Allotment and many more.
• Including a Frequently Asked Questions Section.

Finally, we like to conclude that we put all our efforts throughout the development of
our project and tried to fulfill most of the requirements of the user.

37 | P a g e
38 | P a g e
39 | P a g e