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.
It includes a search facility to know the current status of each patient. User can search
details of a patient using their 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 easy and user friendly. The data are well protected use
and makes the data processing very fast.
CHAPTER 1
INTRODUCTION

1.1 PURPOSE OF THE PROJECT

This software will help the hospital to be more efficient in registration of their patients and manage
appointments, records of patients. The purpose of this project is to computerize all details regarding
patients details and hospital details.

1.2 SCOPE
The system will be used in any hospital, clinic, pathology labs or other health institutions. The
intention of the system is to increase the number of patients that can be treated and managed
properly.

1.3 PROBLEM IN EXISTING SYSTEM

As we know, the manual handling of the record is time consuming and highly prone to error. The
purpose is to automate or make online, the process of day-to-day activities like admission of new
patient, discharge of patient, assign a doctor, and finally compute the bill etc.
CHAPTER 2
SYSTEM REQUIREMENT ANALYSIS

2.1 INTRODUCTION

2.1.1 PURPOSE OF SRS

The SRS document stands for Software Requirement Specification. In this
document, the Business Analyst will collect the Customer Requirement Specifications (CRS) from
the client and translate them into Software Requirement Specification (SRS).
The SRS contains how the software should be developed and given by the Business Analyst (BA)

2.1.2 INTENDED AUDIENCE AND READING SUGGESTIONS

Our Intended audience is doctors, administration,and accountets.

2.1.3 PRODUCT SCOPE

The system will be used in any hospital, clinic, pathology labs or other health
institutions. The intention of the system is to increase the number of patients that can be treated and
managed properly.

2.2 OVERALL DESCRIPTION

2.2.1 PRODUCT PERSPECTIVE

This project gives the procedural approach how a patient gets treatement, details
about date of treatment and finally depending on different criteria like allocated , lab reports,
treatment and medicine taken…...etc.

2.2.2 PRODUCT FUNCTION

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 Modification in schedule by patient.
o Admin access to patient’s record.
o Admin can view monthly/yearly records.

2.2.3 USER CLASSES AND 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.
•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.

2.2.4 OPERATING ENVIRONMENT

The Operating Environments are OS Windows, My Sql Server, Laser Printer, Wifi
router, etc,

2.3 EXTERNAL INTERFACE REQUIREMENTS

2.3.1User 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.
2.3.2 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.
▪ 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.

2.3.3 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.3.4 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)
 Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rate.

2.4 FUNCTIONAL REQUIREMENT

The functional requirement for the software are:
• Login
• Registration.
• Prescription.
• Doctor Module.
• Patient Module.
2.5 NON-FUNCTIONAL REQUIREMENT
2.5.1 PERFORMANCE REQUIREMENT
o Response time- The system will give responses within second after checking the
patient information and other information.
o Capacity- The system must support 1000 people at a time.

2.5.2 SAFETY REQUIREMENT

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.

2.5.3 SECURITY REQUIREMENT

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.

2.6 PROJECT PLAN

2.6.1 TEAM MEMBERS
 AMIT KUMAR MISHRA (0834CS201011)
 ANSHUL PATEL (0834CS201016) (GROUP LEADER)
 VISHAL RATHORE (0834CS201116)

2.6.2 DIVISION OF WORK

10
9
8
7
6
5 Amit
4 Anshul
3 Vishal
2
1
0
Requirement Gathering Analysis Desinging Coding
2.6.3 TIME SCHEDULE

3. ANALYSIS

3.1 METHODOLOGY USED

The system has object oriented approach and it is based on waterfall model also
known as sdlc life cycle

3.2 USE CASE DIAGRAM

3.2 USE CASE SPECIFICATION

Name of use case Register

Actors Patient, Admin, Doctor
Pre-Conditions Patient, Admin as well as Doctor
Should Access the Software
Primary flow of content  Patient can manage user details
 Admin can manage user details as
well as Doctor details.
Alternate flow of events  Reset Password / Register
Post conditions Patient, Admin and Doctor should be
able to perform their task successfully
Use case termination By clicking the close button

Name of use case Manage Patient And Doctor

Actors Admin
Pre-Conditions Admin Should be registerd in the
system
Primary flow of content  Admin can manage the Doctors
and Patients.
 Add Doctors, Patients as well as
Delete.
Alternate flow of events Close the application or go back
Post conditions Admin should be able to manage
Doctor and Patients successfully
Use case termination By clicking the close button
Name of use case Manage Format
Actors Admin
Pre Conditions Admin Should Access the Software
and should be registered in the system
Primary flow of content  Admin can manage the format
i.e. by adding or deleting a
format
Alternate flow of events  Go back or close the application
Post conditions Admin should be able to add or delete
the format successfully
Use case termination By clicking the close button

Name of use case Login

Actors Patient and Doctor
Pre Conditions
 Patient and Doctor Should
Access the Software
 Admin Should Logged in
Primary flow of content  Patient and Doctor can login in
HMS
 Patient and Doctor can login in
HMS
 Patient and Doctor can login in
HMS
Alternate flow of events Go back or close the application
Post conditions Patient and Doctor record should be
available in HMS Database.
Use case termination By clicking the close button
3.2 ACTIVITY DIAGRAM

REGISTER
MANAGE PATIENTS AND DOCTOR
MANAGE FORMAT
LOGIN
SOFTWARE REQUIREMENT SPECIFICATION
1. Introduction:-

The SRS is basically a document that defines what a given software

system needs to do and takes care of various requirements. It is written
according to the needs of the software and ensures that the software does not
cause any problems to the end-users. The different features of the software are
clearly detailed and given particular attention. SRS is used to provide certainty,
cost, risk, and time planning objectives in software development, including
project management, to increase the scope, improve the quality, and lower the
cost of a software system

The SRS is technical specifications of requirement of Hospital

Management System. This specification describe what the proposed system
should do without describing how it will do it. It also describes complete
external behavior of proposed system.

1.1 Purpose:

The main purpose of out system is to make hospital task easy and is to
develop software that replaces the manual hospital system into automated
hospital management system. This document serves as the unambiguous
guide for the developers of this software system.

1.2 Scope:

The document only covers the requirement specifications

for the hospital management system. This document does not provide any
references to the other component of the hospital management system. All the
external interfaces and the dependencies are also identified in this document.

1.3 Feasibility Study:

The overall scope of the feasibility study was to provide sufficient

information to allow a decision to be make as to weather the hospital
management system project should proceed and so, its relative priority in the
context of the other existing hospital management system.

The feasibility study of this project had undergone through various

steps which as describe as under:

(a) Identify the origin of the information at different level.

(b) Identify the expectation of user from computerized system.
(c) Analyze the drawbacks of existing system.
1.4 Definition, Acronyms, Abbreviations:-
CFD: - Context Flow Diagram
DFD: - Data Flow Diagram
Java: - Platform Independent, Object Oriented Programming Language
SQL: - Structured Query Language
SRS: - Software Requirement Specification

1.4 Reference:-

1.4 Overview:-

Hospital Management System is a process of implementing all the

activities of the hospital in a computerized automated way to fasten the
performance.

This project is to maintain the patient details, lab reports and to calculate
the bill of the patient. You can also manually edit any patient details.
SUSHILA DEVI BANSAL COLLEGE OF TECHNOLOGY
INDORE, 453331
<Font Style Times New Roman – size -18>

CERTIFICATE
<Font Style Times New Roman – size -16>

<Font Style Times New Roman – size -14>

This is to certify that STUDENTS NAME (ENROLLMENT NOS.) have

completed their project work, titled “TITLE OF THE PROJECT” as per the

syllabus and have submitted a satisfactory report on this project as a part of

fulfillment towards the degree of “BACHELOR OF ENGINEERING”(Computer

Science& Engineering) from RAJIV GANDHI PROUDYOGIKI

VISHWAVIDHYALAYA, BHOPAL.

<<Signature of the Head of the Department>> <<Signature of the project guide>>

HEAD OF THE DEPARTMENT PROJECT GUIDE

<<Signature of the Director of the college>>

DIRECTOR
SUSHILA DEVI BANSAL COLLEGE OF TECHNOLOGY
INDORE, 453331
<Font Style Times New Roman – size -18>

CERTIFICATE
<Font Style Times New Roman – size -16>

<Font Style Times New Roman – size -14>

This is to certify that <<all>>STUDENTS NAME (ENROLLMENT NOS.) have

completed their project work, titled “TITLE OF THE PROJECT” as per the

syllabus and have submitted a satisfactory report on this project as a part of

fulfillment towards the degree of “BACHELOR OF ENGINEERING” (Computer

Science& Engineering) from RAJIV GANDHI PROUDYOGIKI

VISHWAVIDHYALAYA, BHOPAL.

<<Signature of the Internal Examiner>> <<Signature of the External Examiner>>

INTERNAL EXAMINER EXTERNAL EXAMINER

(A typical specimen of table of contents)

<Font Style Times New Roman>
TABLE OF CONTENTS
CHAPTER TITLE PAGE NO.
ABSTRACT i
LIST OF TABLESii
LIST OF FIGURES iii
LIST OF SYMBOLS iv

1 Introduction 1

1.1 Purpose of the project

1.2 Scope
1.3 Problem in existing system
1.4 Statement of Problem

2 System Requirement Analysis

2.1 Introduction
2.1.1 Purpose of SRS
2.1.2 Intended Audience and Reading Suggestions
2.1.3 Product Scope

2.2 Overall Description

2.2.1 Product Perspective

2.2.2 Product Functions
2.2.3 User Classes and Characteristics
2.2.4 Operating Environment

2.3 External Interface Requirements

2.3.1 User Interfaces

2.3.2 Hardware Interfaces
2.3.3 Software Interfaces
2.3.4 Communications Interfaces

2.4 Functional Requirement(description of product functions)

2.4.1 System Feature 1

2.4.2 System Feature 2 (and so on)

2.5 Nonfunctional Requirements(any two)

2.5.1 Performance Requirements

2.5.2 Safety Requirements
2.5.3 Security Requirements
2.5.4 Availability Requirements

2.6 Project Plan

2.6.1 Team Members

2.6.2 Division of Work
2.6.3 Time Schedule (Show with the help of gantt chart)

Analysis

1 Methodology Used ( Object Oriented)

2 Use Case Diagrams (Also include use case specifications)
3 Activity Diagram
4 Sequence Diagram
5 Class Diagram(Description of Identified Classes, Identified Attributes, Identified Methods, Identified
Relationships)

Design
1 Architectural Design
1.1 System Architecture Diagram
1.2 Description Of Architectural Design
2 Database Design
2.1 Normalization
3 Interface Design
3.1 Screenshots

Implementation
1 Language and database system used for the implementation
2 Features of language and database used for the project
3 Description of third party tools used (If any)

Testing (Theory of testing is not required. Only write how u have tested the system)

6.1 White Box Testing (Basis path testing)

Test Case-n
i Purpose
ii Inputs
iii Expected Outputs & Actual Outputs

6.2 Black Box Testing

6.2.1 Interface testing

8.Conclusion
9. Reference (include references of the project in IEEE format)

`
INDEX

1. Introduction…….…………..……………………….……………….……...
2. Objective…………………………………………………………………….
3. Project Category……………………………………………………………..
4. Technology Used…………………………………………………………….
5.Software Requirement………………………………………………………..
6. Hardware Requirement………………………………………………………
7. Feasibility Study………………………………………………………………
8. Design………………………………………………………………………….
9. Project Planning and Scheduling…………………………………………….
10. Implementation of security mechanisms at various levels…………………
11. Future scope and enhancement……………………………………………...
12.Bibiography……………………………………………………………………