You are on page 1of 37

Hospital Management

System

-Submitted by-
 JIT SEKHAR KAR
 LABONI SARKAR
 SIMA DAS
 SUBHAM DUTTA

Maulana Abul Kalam Azad University Of

TEchnology

1
CERTIFICATE

This is to certify that the project entitled “HOSPITAL MANAGEMENT SYSTEM”, prepared by
JIT SEKHAR KAR ,LABONI SAKAR, SIMA DAS ,SUBHAM DUTTA of M.Tech
(Computer Science & Engineering), First Semester, has been done according to the regulations of
the Degree of Master of Technology in Computer Science & Engineering. The candidates have
fulfilled the requirements for the submission of the project report. It is to be understood that, the
undersigned does not necessarily endorse any statement made, opinion expressed or conclusion
drawn thereof, but approves the report only for the purpose for which it has been submitted.

………………………………………………………………. ………………………………………………………………………
Prof. Suparna Biswas Prof. Sayantani Saha
Asst. Professor , Dept. Of CSE Asst. Professor , Dept. Of CSE
MAKAUT , Haringhata MAKAUT , Haringhata

…………………………………………………………………
Prof. Santanu Phadhikar
HOD , Dept. Of CSE
MAKAUT , Haringhata

--------------------------------------------------------------------------------------------
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

-------------------------------------------------------------------------------------------

2
ACKNOWLEDGEMENT

We would like to express our sincere gratitude to Prof.Suparna Biswas and Prof.Sayantani Saha
of the department of Computer Science and Engineering, whose role as project guide was
invaluable for the project. We are extremely thankful for the keen interest he took in advising us,
for the books and reference materials provided for the moral support extended to us. Last but not
the least we convey our gratitude to all the teachers for providing us the technical skill that will
always remain as our asset and to all non-teaching staff for the gracious hospitality they offered us.

Place: Maulana Abul Kalam Azad University Of Technology , Haringhata

Date:

………………………………………………………………………

………………………………………………………………………

……………………………………………………………………….

……………………………………………………………………….

3
Index
Contents Page nos.

1.Introduction 6-7
1.1Briefing 6
1.2Scope 6
1.3Overview 7
1.4Objectives 7
2.General Description 8
2.1Product Perspective 8
2.2Product Features 8
2.3Design & implementation Contraints 8
3.Project Planning 09-11
3.1Software Life-Cycle Model 9
3.2Statistics 10
3.3Cost Analysis 11
4.Feasibility Study 12-13
4.1Technical Feasibility 12
4.2Operational Feasibility 13
4.3Schedule Feasibility 13
5.System Requirements Specification 14-18
5.1Introduction 14
5.2Functional Requirements 15-17
5.3Non-functional Requirements 17-18
6.Interface Requirements 19
6.1User Interface 19
6.2Hardware Interface 19
6.3Software Interface 19
6.4Communication Interface 19
7.Design 20-24
7.1 Data Flow Diagram 20-22
7.2.Use Case Diagram 23
7.3Class Diagram 24
8.Data Dictionary 25-26
8.1Doctor Details 25
8.2Admin Details 26
8.3Patient Details 26
9.Coding 27-28
9.1Check login 27
9.2Patient’s Registration 27
9.3Doctor’s Index 27-28
9.4Logout 28
10.Testing 29-32
10.1Introduction 29
10.2Test Procedure 30
10.3Test Cases 31-32
11.Conclusion 33-34
11.1Project Benefits 33-34
11.2Limitations 34
11.3Future Scopes & Improvements 34
11.4Summary 34
12.References 35
13.Appendix( Screen Shots ) 36-

4
List Of Figures
Fig. No Fig. Name Page no.

1. Iterative Waterfall Model 9

2. Statistics Pie Chart 10

3. Statistics Graph 10

4. Level 0 DFD 20

5. Level 1 DFD 21

6. Level 2 DFD 22

7. Use Case Diagram 23

8. Class Diagram 24

LIST OF TABLES
Table. No Table. Name Pageno.

1. Data Dictionary Of Doctor’s Details 25


2. Data Dictionary Of Admin’s Details 26
3. Data Dictionary Of Patient’s Details 26
4. Test Cases 31-32

5
1.Introduction

1.1Briefing :
Hospital are the essential part of our lives, providing best medical facilities to people suffering from
various ailments, which may be due to change in climatic conditions, increased work-load,
emotional trauma stress etc. It is necessary for the hospitals to keep track of its day-to-day activities
& records of its patients, doctors, nurses, ward boys and other staff personals that keep the hospital
running smoothly & successfully.

But keeping track of all the activities and their records on paper is very cumbersome and error
prone. It also is very inefficient and a time-consuming process Observing the continuous increase
in population and number of people visiting the hospital. Recording and maintaining all these
records is highly unreliable, inefficient and error-prone. It is also not economically & technically
feasible to maintain these records on paper.

Thus keeping the working of the manual system as the basis of our project. We have developed an
automated version of the manual system, named as “Hospital Management System”.

1.2 Scope :
The proposed software product is the Hospital Management System (HMS).The system will be
used to get the information from the patients and then storing that data for future usagse.

i. The current system in use is a paper-based system. It is too slow and cannot provide

updated lists of patients within a reasonable timeframe.

ii. The intentions of the system are to reduce over-time pay and increase the number of

patients that can be treated accurately.

iii. Requirements statements in this document are both functional and non-functional.

6
1.3 Overview :

This Software Requirements Specification (SRS) is the requirements work product that formally
specifies Hospital Management System (HMS).

i. It includes the results of both business analysis and systems analysis efforts Various
techniques were used to elicit the requirements and we have identified your needs,
analyzed and refined them.

ii. The objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and
business rules and constraints.

1.4 Objective :

The project “Hospital management system” is aimed to develop to maintain the day –to-day state of
admission/discharge of patients, list of doctors, reports generation, and etc.It is designed to achieve
the following objectives:

1. To computerize all details regarding patient details & hospital details.

2.Scheduling the appointment of patient with doctors to make it convenient for both.

3.Scheduling the services of specialized doctors.

4.The information of the patients should be kept up to date and there record should be kept in the
system for historical purpose.

7
2.General Description

2.1Product Perspective :
This Hospital Management System is a self-contained system that manages activities of
the hospital as Patient Info.Various stakeholders are involved in the hospital patient info
system.

2.2 Product features :


The system functions can be described as follows:

2.2.1Registration & log-in: When a patient is admitted, the front-desk staff checks to see if the
patient is already registered with the hospital and can logged in the system.
If he is, his/her Personal Health Number (PHN) is entered into the computer. Otherwise
a new Personal Health Number is given to this patient/

The patient’s information such as date of birth, address and telephone number is also entered
into computer system.

2.2.2Patient check out: If a patient checks out, he/she may logged out from the system.

2.2.3Generation: The system generates reports on the following information: List of detailed
information regarding the patient who had visited earlier in the hospital.

2.2.4 :Doctor’s Login & logout: A doctor can also logged in the system to see the status of the
appointment’s of its own and Also to manages it.And Also easily checkout from the system to avail
the logout option.

2.2.5 Admin’s Login & Logout : Administrative staffs can control the whole system by logged in
into the system and also for check out , they can also avail the logout option.

2.3 Design & Implementation Constraints :


Database:The system shall use the MySQL Database, which is open source and free.

Operating System :The Development environment shall be Windows 2010.

Web-Based :The system shall be a Web-based application.

8
3.Project Planning
3.1 Software Life-cycle Model :

Fig 1 – Iterative Waterfall Model

9
3.2Statistics:

Fig 2 : Statistics Pie-chart

Fig 3 : Statistics Graph

10
3.3Cost Analysis:
In today’s time, cost estimation of the project is the major part. Whenever a project is required by
any company or organization, then the second major thing along with project requirements comes
the cost they can spent on the project. In project management, planning and resources are allocated
according to the cost it takes. Only then resources are described and assigned which includes the
effort in allocating the resources and time in allocation of resources. In our research we are going to
minimize the effort estimation non-linearly. Implementation of our project won’t be much costly.If
the implementation is done as planned it will be very cost efficient.

11
4.Feasibility Study

Depending on the results of the initial investigation the survey is now expanded to a more detailed
feasibility study. “ FEASIBILITY STUDY ” is a test of system proposal according to its
workability, impact of the organization,ability to meet needs and effective use of the resources.

4.1 Technical feasibility: A study of resource availability that may affect the ability to
achieve an acceptable system.This evaluation determines whether the technology needed for the
proposed system is available or not.

i.Can the work for the project be done with current equipment existing software technology &
available personal?

ii.Can the system be upgraded if developed?

iii.If new technology is needed then what can be developed?

This is concerned with specifying equipment and software that will successfully satisfythe user
requirement. The technical needs of the system may include:

4.1.1Front-end and back-end selection: An important issue for the development of a project
is the selection of suitable front-endand back-end. When we decided to develop the project we went
through an extensivestudy to determine the most suitable platform that suits the needs of the
organization aswell as helps in development of the project.The aspects of our study included the
following factors.

4.1.1.1Front-end selection:

1. It must have a graphical user interface that assists employees that are not from IT
background.

2. Scalability and extensibility.

3. Flexibility.

4. Robustness.

4.1.1.1Back-end selection:

1. Multiple user support.

12
2. Efficient data retrieval and maintenance.

3. Provide inherent features for security.

4. Efficient data handling.

4.2 Operational Feasibility: It is mainly related to human organizations and political aspects.
The points to be considered are

i. What changes will be brought with the system?

ii. What organization structures are disturbed?

iii. What new skills will be required? Do the existing staff members have theses kills? If no
can they be trained in due course of time?

4.3 Schedule Feasibility: Time evaluation is the most important consideration in the
development of project.The time schedule required for the developed of this project is very
important since moredevelopment time effect machine time, cost and cause delay in the
development of other systems.
A reliable Hospital Management System can be developed in the considerable amount of time.

13
5.Software Requirement Specification

A Software requirements specification (SRS), a requirements specification for a software system, is


a complete description of the behavior of a system to be developed and may include a set of use
cases that describe interactions the users will have with the software. In addition it also contains
non-functional requirements. Non-functional requirements impose constraints on the design or
implementation (such as performance engineering requirements, quality standards, or design
constraints).

5.1.Introduction :

The following subsections of Software Requirement Specifications Document should facilitate in


providing the entire overview of the Information system “Hospital Management System” under
development. This document aims at defining the overall software requirements for admin. Efforts
have been made to define the requirements of the Information system exhaustively and accurately.

5.1.1 Purpose :

The main purpose of Software Requirement Specifications Document is to describe in a precise


manner all the capabilities that will be provided by the Software Application “Hospital
Management System”. It also states the various constraints which the system will be abide to. This
document further leads to clear vision of the software requirements, specifications and capabilities.
These are to be exposed to the development, testing team and end users of the software.

14
5.2Functional Requirements :

R1 Patient
R1.2 Assign ID
The HMS shall allow front-desk staff to give each patient a ID and add it to
the patient’s record. This ID shall be used by the patient throughout his/her stay
inhospital.

INPUT : Enter Patients Name, Phone no, and Address.


OUTPUT: Unique ID assigned.

R1.3 Login
The HMS shall allow front-desk staff to login patients to the system.

INPUT : Enter Patient’s user id and the password.


OUTPUT: Successfully Logged in into the patient’s profile or Invalid Login.

R1.4 Confirm Booking


The HMS shall allow patient to confirm appointment to the specified doctor at specified date and
time.

INPUT: Select the doctor and also select the date.


OUTPUT: Patients’s appointment successfully booked.

R1.5 View Previous Bookings and Cancel Bookings


The HMS shall allow patient to view the previous bookings done by the patient and also allows the
patient to cancel a booked appointment.

INPUT : The patient can opted the option to view its previous appointments and from there also
they can cancel their bookings.
OUTPUT : Successfully cancelled the appointments.

R1.6 Update Profile


The HMS shall allow to modify his profile.

INPUT : The patient can edit his last given information and password also.
OUTPUT : Patient’s profile updated successfully.

R1.7 Logout
The HMS shall allow patient to logout from the system.

INPUT: Patient clicked the logout bottton.


15
OUTPUT: Patient logged out successfully.

R2 Doctor
R2.1 Registration
The HMS allows front-desk staff to add new doctor to the system.

R2.2 Assign ID
The HMS shall allow front-desk staff to give each doctor a ID and add it to
the doctor’s record. This ID shall be used by the patient throughout his/her stay in
hospital.

INPUT : Enter Doctor’s Name, Phone no, and specialization,consultation fess.


OUTPUT: Unique ID assigned.

R2.3 Login
The HMS shall allow front-desk staff to login doctor to the system.

INPUT : Enter Doctor’s user id and the password.


OUTPUT: Successfully Logged in into the doctor’s profile or Invalid Login.

R2.4 View Allotted Bookings and Cancel Bookings

The HMS shall allow doctor to view the allotted bookings done by the patient and also allows the
doctor to cancel a booked appointment.

INPUT : The doctor can opted the option to view his previous appointments and from there also
they can cancel their bookings.
OUTPUT : Successfully cancelled the appointments.

R2.5 Update Profile


The HMS shall allow to modify his profile.

INPUT : The doctor can edit his last given information and password also.
OUTPUT : Doctor’s profile updated successfully.

R2.6 Logout
The HMS shall allow doctor to logout from the system.

INPUT: Doctor clicked the logout bottton.


OUTPUT: Doctor logged out successfully.

R3 Admin
R3.1 Login
The HMS shall allow front-desk staff to login to the system.

INPUT : Enter Admin’s user id and the password.


OUTPUT: Successfully Logged in into the Admin’s profile or Invalid Login.
16
R3.2 Manage Patients
The HMS shall allow admin to manages the patient’s database.

INPUT : Enter to the patient’s database by choosing the option.


OUTPUT:Successfully get the information and status of appointed patientand also can delete a
patient.

R3.3 Manage Doctors


The HMS shall allow admin to manages the doctor’s database.

INPUT : Enter to the Doctor’s database and assigns a unique id.


OUTPUT:Successfully get the information and status of appointed doctor and also can delete a
doctor.

R3.4 Logout
The HMS shall allow admin to logout from the system.

INPUT: Admin clicked the logout bottton.


OUTPUT: Admin logged out successfully.

5.3.Non- functional Requirement

5.3.1Performance

i. Response Time :- The system shall give responses in 1 second after checking the patients
information.

ii. Capacity :- The System must support 1000 people at a time.

iii.User-interface :- The user-interface screen shall respond within 5 seconds.

iv.Conformity:-The systems must conform to the Microsoft Accessibility

5.3.2Security

i.Patient Identification:-The system requires the patient to identify himself /herself using PHN

ii.Logon ID :-Any user who uses the system shall have a Logon ID and Password.

iii.ModificationAny modification (inert, delete, update) for the Database shall be synchronized and
only by the administrator in the ward.

17
iv.Front Desk staff Rights:-Front Desk staff shall be able to view all information in HPIMS, add
new patients to HPIMS but shall not be able to modify any information in it.

v.Administrators' Rights:- Administrators shall be able to view and modify all information in
HPIMS.

5.3.3 Reliability

How general the form generation language is Simplicity vs. functionality of the form

language= Speeds up form development but does not limit functional.

5.3.4 Availability

The system shall be available all the time.

5.3.5 Safety

Humans are error-prone, but the negative effects of common errors should be limited.

E.g., users should realize that a given command will delete data, and be asked to confirm

their intent or have the option to undo.

5.3.6 Software Quality

Good quality of the framework= produces robust, bug free software which contains all

necessary requirements Customer satisfaction.

5.3.7 Reusability

Is part of the code going to be used elsewhere= produces simple and independent code

modules that can be reused

5.3.8 Maintainability

i.Back Up- The system shall provide the capability to back-up the Data.

ii.Errors-The system shall keep a log of all the errors.


18
6.Interface Requirements

6.1 User Interface:-

The software provides good graphical interface for the user any administrator can operate
on the system, performing the required task such as create, update, viewing the details of
the book.
i.Allows user to view quick reports like Book Issues/Returned etc in between particular
time.
ii.Stock verification and search facility based on different criteria.

6.2 Hardware interface:-


i.Operating system : window

ii.Hard disk :40 GB

iii.RAM : 4GB

iv.Processor : Intel i3

6.3 Software interface :-


i.PHP ,MySQL

ii.HTML , CSS , Bootstrap , JQuery

iii.Xampp Server (Version 3.2.2)

6.4 Communication interface:-


i.Windows

ii.Mozilla Firefox

19
7.Design

7.1 Data Flow Diagram:-

7.1.1 LEVEL 0 DFD :

Fig 4 : Level 0 DFD

20
7.1.2 LEVEL 1 DFD :

Fig 5: Level 1 DFD

21
7.1.3 LEVEL 2 DFD :

Fig 6: Level 2 DFD

22
7.2 Use-case Diagram:-

Fig 7 : Use-case Diagram

23
7.3 Class Diagram:-

Fig 8 : Class Diagram Of Hospital Management System

24
8.Data Dictionary

8.1 Doctor Details :

Name Type Size Description

Doctor_ID Int 11 ID of the Doctor

Doctor Name Varchar 255 Name of the Doctor

Specialization Varchar 255 Specialization of Doctor

Doctor fees Varchar 255 Fees of the doctor

Address longtxt 90 Address of the doctor

Contact No bigint 11 Contact No of doctor

Email Varchar 255 Email of the doctor

Password Varchar 255 Password of the doctor

Table 1 : Data Dictionary Of Doctor Details

25
8.2 Admin Details:

Name Type Size Description


Admin id int 11 ID of the Admin
User name varchar 255 User name of the
Admin
Password varchar 255 Password of the
Admin
Updation Date varchar 255 Last updation date
Table 2 : Data Dictionary Of Admin Details

8.3 Patient Details :

Name Type Size Description

Patient_ID Int 11 ID of the Patient

Name Varchar 255 Name of the patient

Email Varchar 255 Email of the Patient

Gender Varchar 255 Gender of the Patient

Address longtxt 90 Address of the Patient

Updation Date Datetime 30 Last updation date of admission

Reg Date Varchar 255 Reg. date of the patient

City Varchar 255 City of the patient

Table 3 : Data Dictionary Of Patient Details

26
9.Coding

9.1 Check Login Code :


<?php
function check_login()
{
if(strlen($_SESSION['login'])==0)
{
$host = $_SERVER['HTTP_HOST'];
$uri = rtrim(dirname($_SERVER['PHP_SELF']), '/\\');
$extra="../admin.php";
$_SESSION["login"]="";
header("Location: http://$host$uri/$extra");
}
}
?>
9.2 Patient Registration Code :
<?php
include_once('include/config.php');
if(isset($_POST['submit']))
{
$fname=$_POST['full_name'];
$address=$_POST['address'];
$city=$_POST['city'];
$gender=$_POST['gender'];
$email=$_POST['email'];
$password=md5($_POST['password']);
$query=mysqli_query($con,"insert into users(fullname,address,city,gender,email,password)
values('$fname','$address','$city','$gender','$email','$password')");
if($query)
{
echo "<script>alert('Successfully Registered. You can login now');</script>";
//header('location:user-login.php');
}
}
?>
9.3 Doctor’s Index Code :
<?php
session_start();
include("include/config.php");
if(isset($_POST['submit']))
{
$ret=mysqli_query($con,"SELECT * FROM doctors WHERE docEmail='".$_POST['username']."' and
password='".md5($_POST['password'])."'");
$num=mysqli_fetch_array($ret);
27
if($num>0)
{
$extra="dashboard.php";
$_SESSION['dlogin']=$_POST['username'];
$_SESSION['id']=$num['id'];
$uip=$_SERVER['REMOTE_ADDR'];
$status=1;
$log=mysqli_query($con,"insert into doctorslog(uid,username,userip,status)
values('".$_SESSION['id']."','".$_SESSION['dlogin']."','$uip','$status')");
$host=$_SERVER['HTTP_HOST'];
$uri=rtrim(dirname($_SERVER['PHP_SELF']),'/\\');
header("location:http://$host$uri/$extra");
exit();
}
else
{
$host = $_SERVER['HTTP_HOST'];
$_SESSION['dlogin']=$_POST['username'];
$uip=$_SERVER['REMOTE_ADDR'];
$status=0;
mysqli_query($con,"insert into doctorslog(username,userip,status)
values('".$_SESSION['dlogin']."','$uip','$status')");
$_SESSION['errmsg']="Invalid username or password";
$extra="index.php";
$uri = rtrim(dirname($_SERVER['PHP_SELF']),'/\\');
header("location:http://$host$uri/$extra");
exit();
}
}
?>
9.4 Logout Code :
<?php
session_start();
include('include/config.php');
$_SESSION['login']=="";
date_default_timezone_set('Asia/Kolkata');
$ldate=date( 'd-m-Y h:i:s A', time () );
mysqli_query($con,"UPDATE userlog SET logout = '$ldate' WHERE uid = '".$_SESSION['id']."'
ORDER BY id DESC LIMIT 1");
session_unset();
//session_destroy();
$_SESSION['errmsg']="You have successfully logout";
?>

28
10.Testing
10.1 Introduction :
Test procedure and test cases plays a critical role in assuring software quality. It serves the

purpose of quality assurance, verification and validation. Studies indicate that 50% of cost for

software development is given to testing. Basically testing procedure is an investigation

conducted to provide information about quality of product or services. It can also provide an

objective view of software to allow the user to understand the risk of the system. We use this

technique to find out software bugs or error in hospital management system. It ensures that

doctors can access their id any time and patient can check or update his treatment detail any time.

Unit testing, integration testing , white and black box testing etc are used in hospital management

system.

A test cases is a set of conditions under which a tester will determine the features of

system or software is working well or not. Generation of test cases is a time consuming process.

Hence, automation is an important issue. There are two main approaches to generate test cases –

i.Generating test cases from requirements and design specification.

ii.Using source code .

In order to fully test that all the requirement of an system are met, there must be atleast two test

cases that is one positive test and one negative test. We can define test cases as-

Formal test cases- In formal test case, test case is characterized by a known input and by an

expected output, which is worked out before the test is executed. Formal testing is done by

testing team formally.

Informal test cases- In informal test cases, testing is done by a coder before giving file to a

testing team. No procedure is used in informal testing.

29
10.2 Test procedure :
Test procedure helps in assuring software quality. The purpose of test procedure is a quality

assurance, verification and validation. Basically testing procedure is an investigation conducted

to provide information about quality of product or services. It ensures that doctors can access

their id any time and patient can check or update his treatment detail any time. Testing is the

process of executing a program with the intention of finding errors. It is used to represent the

ultimate review of specification, design, coding. Different test conditions should be thoroughly

checked and the bugs detected should be fixed. Testing in hospital management system are

fallowed as –

9.2.1Unit testing- Unit testing plays a crucial role in early phase of software testing life cycle

which helps in detection bugs; and once properly planned and executed, it reduces cost of

quality. However, if unit tests are not written well, or they are executed incorrectly, bugs go

through into the production phase. This oversight can cost a company thousands, if not

hundreds of thousands of dollars depending on the scale of the project.Unit testing needs a

deep expertise of looking into code with various perspectives such as Code coverage, Loop

coverage, Branch coverage, Condition coverage, and Fuzzing code to predict its expected

failure, predefined negative tests while developing code . This involves not just insights into

code, but a much required methodological approach towards testing the code for its afferent

and efferent coupling.

Testing Goal -Dots squares unit testing service goal is to catch as many bugs early in the

development as possible. This is achieved by writing accurate and quality unit tests, while at the

same time providing detailed documentation for the development process. This ensures that bugs

and inconsistencies we detect early in the development stage, can be re-factored by the

development team. We work intimately with your team to thoroughly ensure all project goals are

met on time and within budget.

30
9.2.2Integration testing - We normally do Integration after unit testing. Once all the individual

units are created and tested, we start combining those “Unit Tested” modules and start doing

the integrated testing. So the meaning of Integration testing is quite straight forward33

Integrate/combine the unit tested module one by one and test the behaviour as a combined

unit.

Testing goal -The main function or goal of Integration testing is to test the interfaces

between the units/modules. The individual modules are first tested in isolation. Once

themodules are unit tested, they are integrated one by one, till all the modules are integrated,

to check the combinational behaviour, and validate whether the requirements are

implemented correctly or not.

10.3 System Testing :


Test Test Expected Expected Actual Input Actual Output
Case_id input Output

1. Registration Form Name , Successfully Name , Successfully


of Patient Address Registered.You Address Registered.You
,Gender , can login now. ,Gender , can login now.
Password Password
2. Login (Patient Username , Dashboard Username , Dashboard
,Doctor,Admin) Password Page Password Page

3. Log Select the Successfully Select the Successfully


out(Patient,Doctor, Logout Logged out. Logout Logged out.
Admin) Button. Button.
4. Book Select Your Select Appointment
Appointment specialization, Appointment specialization, Successfully
Select Doctor, Successfully Select Doctor, Booked.
Choose time Booked. Choose time
and date. and date.
5. Cancel Select the Your Select the Your
Appointment & action button. Appointment action button Appointment
View Cancelled. Cancelled.
Appointment
History.(Patient)

31
Test Case_id Test Expected Expected Actual Input Actual
input Output Output

6. Cancel Select the Appointment Select the Appointment


Appointment & action button. Cancelled. action button. Cancelled.
View
Appointment
History.(Patient)
7. Add Name, Open the Name, Open the
Doctor(Admin) Address doctor’s list Address doctor’s list
,Gender, and a new ,Gender, and a new
Password, entry should Password, entry have
Select be made. Select made.
Specialization, Specialization,
Consultation Consultation
fees, fees,
Email etc. Email etc.
Table 4: Test Cases

32
11. Conclusion
11.1 Project Benefits :
11.1.1Easy Use and Better Control:

With online applications, data could be controlled and managed centrally. The better stock
organization, brought together control on rates of the organization, pay roll organization,
appointment management, better resource administration, and use, are a couple of things which
could be accomplished with the offline software model of HMS.

11.1.2 Easy Access To Patient Data

A well-implemented Hospital Information System means readily available patient data to the
care providers. It is only a matter of few clicks and all the requisite information about a patient,
from various departments in the hospital, can be available on the screen. If the treating doctor
needs to re-check the test reports of a patient, she need not go looking for the IPD file; logging
into the HIS will give her instant access to those reports and timely treatment decisions ensue.

11.1.3 Cost Effective

HMS, when implemented well, cuts out on a lot of manual work that is essentially performed in
hospitals, especially the ones where documentation and record keeping is required. It helps in
cutting down manpower because a lot of work gets automated and does not require manual
intervention to store or analyze the information. It also saves much on storage and the related
costs.

11.1.4Secured Data Backup

With fool-proof access control, hospital management software applications can help a hospital
administration in archiving data safely. As patient treatment details are considered to be
confidential, it is even more important to create electronic medical records. Such records can be
accessed only by those with login credentials, and so there in no chance of any breach.

Also, the backup of data is created over cloud to prevent any scope of data loss or damage. The
cloud-based data can be accessed by authorized users through mobile devices, saving their
considerable time in searching them manually.

11.1.5Better Control Over Hospital Administration

From managing appointments to making daily schedules for doctors, creating a record of
patient’s prescriptions and treatment history, managing pharmacy, tracking the availability of
beds, managing billing and transactions – these are some of the major administrative tasks of a
hospital that need to be accomplished on a daily basis. For the error-free management of these
administrative processes, hospitals need to take the technological help of a hospital management
software. HMS software works by automating administrative processes, so that there is no

33
chance of error. It also saves time and effort of hospital administrators, so that they can focus
more upon offering prompt solutions for requirements of patients.

11.2 Limitations :
i. The size of the database increases day-by-day, increasing the load on the database back up

and data maintenance activity.

ii.Training for simple computer operations is necessary for the users working on the system.

11.3 Future Scopes And Improvements :


The proposed system is Hospital Management System. We can enhance this system by including more
facilities like pharmacy system for the stock details of medicines in the pharmacy. Providing such
features enable the users to include more comments into the system. The scope of this document
involves in proposing architecture. All departments collaborate to provide the best care for patients, to
improve outcomes and achieve our mission, vision and goals.

11.4 Summary :
The project Hospital Management System (HMS) is for computerizing the working in a hospital.
It is a great improvement over the manual system. The computerization of the system has
speed up the process. In the current system, the front office managing is very slow. The hospital
managing system was thoroughly checked and tested with dummy data and thus is found to be
very reliable. The software takes care of all the requirements of an average hospital and is
capable to provide easy and effective storage of information related to patients that come up
to the hospital. At the beginning of this project, everything look really simple and easy but as
time went by, it was realized that there is more to the development of the software especially
the coding part, though at the end of it all it was worth it because the result is satisfying
because the main objective was realized.

34
12.References

[1] : https://en.wikipedia.org/wiki/Hospital_information_system

[2] : http://nevonprojects.com/hospital-management-system/

[3] : http://www.iisjaipur.org/iiim-current-08/mca_iv_sem_pro_eva/09.project-
hospital%20management%20system.pdf

[4] : https://projectabstracts.com/list-of-hospital-management-system-projects

[5] : https://solutiondots.com/blog/9-modules-hospital-management-system-developed-
solutiondots-systems/

[6] : https://www.slideshare.net/HimaniChopra/hospital-management-system-project

[7] : https://dl.acm.org/citation.cfm?id=2208089

[8] : http://dinus.ac.id/repository/docs/ajar/RPL-
7th_ed_software_engineering_a_practitioners_approach_by_roger_s._pressman_.pdf

[9] : https://www.pdfdrive.com/fundamentals-of-software-engineering-fourth-edition-rajib-mall-
e33307068.html

[10] : "Policy and Procedure Management Systems for Hospitals (2012)". PolicyStat LLC. 2012-
07-18. Retrieved 2012-07-18.

35
13.Appendix

Screen Shots :

36
37

You might also like