Page |1

HOSPITAL MANAGEMENT SYSTEM

Software Engineering

Project Report

(CSHP - 410)

Submitted by: Supervisor:

Ajay Kumar (3101)
Devanshu Taneja (3150) Dr. Anjali Thukral

2015

Department of Computer Science

Keshav Mahavidyalaya
University of Delhi
 Page |2

Problem Statement .............................................................................................................. 4

Process Model ..................................................................................................................... 5

1. Software Requirement Specification ........................................................................ 6

1.1 Overall Description ............................................................................................... 6

1.1.1 Product Functions ............................................................................................ 6

1.1.2 User Characteristics......................................................................................... 6

1.1.3 General Constraints ......................................................................................... 6

1.1.4 Assumptions and Dependencies ...................................................................... 7

1.2 External Interface Requirements ........................................................................... 7

1.2.1 User Interfaces................................................................................................. 7

1.2.2 Hardware Interfaces ........................................................................................ 7

1.2.3 Software Interfaces .......................................................................................... 7

1.3 Functional Requirements....................................................................................... 8

1.3.1 User Verification module ................................................................................ 8

1.3.2 OPD registration module................................................................................ 8

1.3.3 Admission registration module ....................................................................... 8

1.3.4 DutyAllocationmodule………………………………….…………………….9

1.3.5 Financial Activity module…………….………………………………………9

1.3.6 Test and Treatment module .…………………………………………………9

1.4 Performance Requirement ................................................................................... 10

1.5 Design Constraints .............................................................................................. 10

1.6 Data Flow Diagram ............................................................................................. 11

1.7 Data Dictionary ................................................................................................... 14

2. Estimations.............................................................................................................. 15

2.1 Function Points.................................................................................................... 15

2.2 Efforts .................................................................................................................. 17

3. Scheduling............................................................................................................... 18
 Page |3

4. Risk Management ................................................................................................... 19

5. Design ..................................................................................................................... 21

5.1 System Design ..................................................................................................... 21

5.2 Data Design ......................................................................................................... 22

6. Coding ..................................................................................................................... 23

7. Testing..................................................................................................................... 25

8. References ............................................................................................................... 29
 Page |4

PROBLEM STATEMENT

HMS is an integrated health information system, which addresses the critical

requirements of hospitals. It provides the benefits of enhanced administration and control,
improved response, cost control and improved profitability. It provides easy access to
critical information there by enabling the management to take better decisions on time.

The idea behind this project is to provide the hospital with a system with the help of
which it can get rid of the manual procedures. A system is needed that can maintain
hospital’s daily routine of patient’s registration, checkup, medicine prescription, laboratory
tests and can generate reports required by the hospital.

This HMS is a high performance database system designed specifically for keeping
records for patients, doctors, laboratory test results for each patient, daily schedule for an
employee and medicine prescribed to each patient.
 Page |5

PROCESS MODEL

Process Model used is the Waterfall model because of the following reasons:
 Time is limited.
 All the requirements are well understood.
 It will allow to develop the software in a systematic and sequential approach.
 All the requirements for the software are known.
 As the numbers of employees are less so it overcomes the waterfall model’s disadvantage of blocking
state.
 Page |6

1. SOFTWARE REQUIREMENT SPECIFICATION

1.1 OVERALL DESCRIPTION

This project gives the procedural approach how a patient gets treatment, details
about date of treatment and finally depending on different criteria like room allocated, lab
reports, treatment and medicine taken…..etc, how billing is calculated. During billing health
card facility is also considered.

1.1.1 Product Function:-

The data represented in hospital management application will perform the following
major function:-

 Patient Details: - It includes inpatient and outpatient details.

 Lab reports

 Duty allocation

 Billing Details

This software will help to calculate the bill much quicker and simpler way. This enables
the organization to keep the information in efficient and systematic way.

1.1.2 User Characteristics:-

This software is developed such that total appearance of the product to make it more
user friendly. The operator will be provided with loginid and password. General users with
basic computer skills can use this software.

1.1.3 General Constraints:-

Any update regarding the patients information from the hospital are to be recorded to
have updated and correct values.

1.1.4 Assumption and Dependencies:-

All the data entered will be correct and up to date. This software package is developed
using c++ as front end, MS SQL server 2005 as the back end which is supported by Microsoft
windows xp.
 Page |7

1.2 EXTERNAL INTERFACE REQUIREMENTS

It describes all the details that the software developer need to know for designing and
developing the system. This is typically the largest and most important part of the document.

1.2.1 User Interface:-

User interface is designed in a user friendly manner and the user, in another
end he has to give the order, for that he will interface with keyboard and mouse.

1.2.2 Hardware Interfaces:-

1) OS – windows XP

2) Hard disk – 80 GB

3) RAM – 1 GB

4) Keyboard – Standard QWERTY keyboard for interface

5) Mouse – Standard mouse with 2 buttons

1.2.3 Software Interfaces:-

1) Front end – C++ language

2) OS – Net Beans IDE 6.9.1

3) Back end – SQL Server 2005

1.3 Functional Requirements:-

1.3.1 User verification Module :-

The module receives input from the user who logs on the system. The module checks for
the validity of the user from within the system itself. The module generate the output,
displaying the validity or non-validity of the user .the module then grants access rights to
the user depending on the level of the user.

1.3.2 OPD Registration Module :-

 Page |8

The module is operated on by the operational level user. The module receives input from
the patients, which includes their details. System will record these details & generate an
OPD No. and list of Doctors available in OPD on that day. The output generated is the
OPD Card No and patient is directed to the required Doctor with that card.

1.3.3 Admission Registration Module :-

This module receives input from two areas:-

(i) From the patient himself who has to get admitted to the Hospital. This process
record patient details and issues a Admission No. .This no. is used as reference in
other modules. The module generates a admission slip as the output indicating the
ward & Bed allotted to the patient.

(ii) The record input is received from the OPD Registration module, if the OPD Doctor
recommends patient for immediate admission to the hospital. The Card No. taken as
reference so that patient details do not required entering again. The card no is now
replaced by the admission no. and output generated is same as in the case (i).

1.3.4 Duty Allocation Module :-

This module is operated by the super user in collaboration with top management who
together build-up the schedule for all employees of the Hospital. The process receives
input from the employee Master database and the process prepares schedule for a period.
The output of the process is the schedule report for the period in the consideration.

1.3.5 Financial Activity Module :-

This process receives two types of inputs:-

 Page |9

(i) First input, which is received, is for the Patient. It receives input from the admission-
registration module, and test & treatment-undertaken module, as well as the patient
master database. It records & process all the financial transactions taken place
between the hospital and the patient and generates the final bill as the output.

(ii) Second input, which is received, is for the employees of the hospital. It receives input
from the duty allocation process and the employee database for the preparation of a
salary-slip. The module records & processes various calculations and generates the
salary-slip as the output.

1.3.6 Test and Treatment Undertaken Module :-

This module receives input in the form of prescription written by the doctor for the
types of tests and treatment to be undertaken by the patient. It records and process,
the various details about the test and generates the lab-report as the output of the
module. It also generates the receipt for the tests undertaken. These receipts serve
as one of the input to the financial-activity module.

1.4 Performance Requirements:-

 P a g e | 10

The capability of the computer depends on the performance of the software. The
software can take any number of input provided the database size is large enough. This would
depend on the available memory space.

1.5 Design Constraints:-

This will help the doctors or users to view the records of the patients immediately
whenever necessary. They can also calculate the bill of the particular patients. This software
also has the ability to add, update and delete the record whenever needed. This project will
help to smoother the process of the hospital activities.

1.4 DATA FLOW DIAGRAMS

 P a g e | 11

Receptionist Patient

Bill and reports

Hospital Salary
Admin Id and password Doctor
Management
System

Salary

Id and password
Medical Superintendent Employee

DFD Level 0
 P a g e | 12

Patient Patient details

Patient details Out Patient
Receptionist Admission
Registration Patient details
In Patient

Patient_DB

Bills
Patient
Registration id Financial
Admin Activity
Salary Slips
Employee

Job Tariff

Doctor Details Duty Schedule

Doctor
MS Allocation

DFD Level 1
 P a g e | 13

Patient details Patient Outpatient details OPD

Receptionist Registrn. Registrn
.

Record (Card no) OPD Card no

Inpatient details

Pat DB Out
Patient
Patient
Admission
Adm slip
Registrn. Inpatient

No days
patient
admitted Ward no

Admin
Test and Doctor Prescription Doctor
Treatment Check-up
Medical
Reg id
Bill
Lab Reports

Financial Final Bill

Activity Patient

Emp DB
Days Worked Salary Slip

Emp id Duty
Schedule Report
MS allocati Employee
on

DFD Level 2
 P a g e | 14

1.5 DATA DICTIONARY

HMS-Hospital Management System Software

OPD-Outpatient Department

IPD-Inpatient Department

Admission Slip-Unique Patient Registration no. is generated along with details like Bed allotted, Ward no. etc.

Patient Admission Registration-Patient_id is generated by knowing patient details

Job tariff- provides employee job charges + Overtime details

OPD#=Unique outpatient card no.

Test and treatment-Tests prescribed by the doctor(Radiology, Laboratory tests etc) followed by the treatment
procedure.

Emp_id- Employee username + Employee password

Schedule Report- Schedule time or working time for Hospital Staff.

MS=Supervises overall working of software.

Admin- Manages administrative tasks of hospitals.

 P a g e | 15

2. ESTIMATIONS

2.1 Function Points

Information Optimistic Most Pessimistic Estimated Weight FP

Domain Likely Count Count
Value

# External 9 9 10 9 3 27
Inputs

#External 6 7 7 7 4 28
Outputs

#User 2 2 2 2 3 6
Inquiries

# I.L.F. 2 2 3 2 7 14

#External 3 4 5 4 5 20
Interfaces

Count Total 95
 P a g e | 16

Value Adjustment Factor

1. Does the system require reliable backup and recovery? 5

2. Are specialized data communications required to transfer information to or from the

application? 5

3. Are there distributed processing functions? 5

4. Is performance critical? 4

5. Will the system run in an existing, heavily utilized operational environment?

4

6. Does the system require online data entry? 0

7. Does the online data entry require the input transaction to be built over multiple screens
or operations? 1

8. Are the ILFs updated online? 5

9. Are the inputs, outputs, files, or inquiries complex? 1

10. Is the internal processing complex? 2

11. Is the code designed to be reusable? 4

12. Are conversion and installation included in the design? 0

13. Is the system designed for multiple installations in different organizations?

5

14. Is the application de signed to facilitate change and ease of use by the user?
4

(Fi) = 45

Function Points = Count Total * [0.65 + 0.01*(Fi)]

= 105
 P a g e | 17

2.2 Efforts

The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a
burdened labour rate of Rs.8000 per month, the cost per FP is approximately Rs.1230.

Based on the FP estimate and the historical productivity data, the total estimated project
cost is Rs.129150 and the estimated effort is 16 person-months.
 P a g e | 18

3. Scheduling

 A Timeline chart can be developed for the entire project or a separate chart canbe
developed for each function.
 A tabular form is maintained where rows indicate the tasks with milestones and
columns indicate duration(weeks/months).
 The horizontal bars that spans across columns indicate duration of the task.

Month 1 Month 2 Month 3 Month 4

Work Tasks
w1 w2 w3 w4 w1 w2 w3 w4 w1 w2 w3 w4 w1 w2 w3 w4

Problem Statement

Process Model

SRS

DFD Level 0

DFD Level 1

DFD Level 2

Data Dictionary

Function Point Metrics

Effort Estimation

Risk Analysis

Design

Coding

Testing
 P a g e | 19

4. Risk Management

S. Risks Category Probability Impact

No.

1 Inexperienced Staff ST 40% 3

2 Developing Wrong TE 20% 2

User Interface

3 Real Time BU 50% 1

Performance Short
Fall

4 Size estimate may be PS 60% 2

significantly low

5 End User Resist CU 30% 3

System

6 Lack of senior ST 40% 3

management
committee

7 Small Database Size PS 20% 2

is provided

8 Interface not easy to TE 50% 3

use

Impact values: Category values:

1 – Catastrophic PS – Product Size Risk

2 – Critical BU – Business Risk

3– Marginal TE – Technology Risk

4– Negligible ST – Staff Risk

 P a g e | 20

Risk exposure:
1. Risk identification: Only 70% of the software components scheduled will be integrated into the application.
The remaining functionality will have to be custom developed.

2. Risk Probability: 60percent (likely).

3. Risk Impact: Sixty reusable software components were planned. If only 70% can be used, 18 components
would have to be developed from scratch (in addition to other custom software that has been scheduled for
development). Since the average component is 100 LOC and local data indicate that the software engineering
cost for each LOC is Rs.14, the overall cost (impact) to develop the components would be is 18 * 100 * 14 =
Rs.25,200.

4. Risk exposure:

RE = Probability of occurrence of the risk * Cost to the project should the risk occur

RE=0.60*25,200 = Rs.15,120.
 P a g e | 21

5.Design

5.1 System Design

HMS

User Login Registration Prescription Discharge Slip

and password form

User Login and Test and Financial

OPD Adm.
Security System Treatment Activity
System System
System System

Access Access OPD Adm. Adm. Report+ Receipt of

Granted Denied Card Granted Denied Result Payment
 P a g e | 22

5.2 E-R Diagram of Hospital Management System

N
 P a g e | 23

6.Coding

int generate_finalbill()

cout<<”enter the patient id\n”;

1
cin>>pat_id;

if(pat_id!=seach_pat(pat_id))
2
{

do
3
{

cout<<”\nenter valid patient id\n”;

4
cin>>pat_id;

}while(patid!=search_pat)
5
} //end of if
6
cout<<”if patient had any tests\n”;
7
cin>>ch;

if(ch==’y’)
8
do
9
{

cout<<”\nenter the tests undertaken”;

cin>>test_type;

final_bill+=get_test_fee(test_type);
1
0 cout<<”if patient has undergone another test,enter y”;

cin>>ch1;

}while(ch1==’y’)
1
1 } //end of if
1
2
 P a g e | 24

cout<<”\nenter doctor consulted”;

cin>>dr_id;

1 finalbill+=get_dr_fee(dr_id);
3
pat_type=type_of_pat(pat_id);

if(pat_type==”inpatient”);
1
4 {

cout<<”\nEnter no. of days patient admitted”;

1
cin>>nd;
5
final_bill+=(nd*1000);

} //end of if
1
6 cout<<”\nfinal bill is”<<final_bill;
1
7 return final_bill;

}
 P a g e | 25

1
Flow Graph
2

R1 4

R4

R2 1
0
R5

1
1
1
2 R6

1
3

1
4
1
R3
5

1
 P a g e | 26

Cyclomatic Complexity

1. V(G) = number of regions

=6

2. V(G) = E-N+2 where E=no. Of edges and N= no. Of nodes

=21-17+2

=6

3. V(G) = P+1 where P=number of predicate nodes

= 5+1

=6

Paths:

P1: 1 -> 2 ->6 -> 7 -> 8 -> 12 -> 13 -> 14 -> 16 -> 17

P2: 1 -> 2 ->6 -> 7 -> 8 -> 12 -> 13 ->14 -> 15 -> 16 -> 17

P3: 1 -> 2 ->3 -> 4 -> 5->6 -> 7 -> 8 -> 12 -> 13 -> 14 -> 16 -> 17

P4: 1 -> 2 ->6 -> 7 -> 8 ->9 -> 10 -> ->11 -> 12 -> 13 -> 14 -> 16 -> 17

P4: 1 -> 2 ->3 -> 4 ->5 -> 4 -> 5 -> 6 -> 7 -> 8 -> 12 -> 13 -> 14 -> 16 -> 17

P5: 1 -> 2 ->6 -> 7 -> 8 -> 9 -> 10 ->11 -> 10 -> 11 -> 12 -> 13 -> 14 -> 16 -> 17
 P a g e | 27

Test Cases:

PATH VALID/ DATA SET EXPECTED ACTUAL

INVALID

1 VALID Pat_id=011 It should generate the bill It calculates the bill including
including only doctor charges. doctor charges only.
Ch = N

Pat_type = OutPatient

1 INVALID Pat-id = Null It should not process until a It enters a do while loop to ask
valid pat_id is not entered. for a valid pat_id.
Ch = N

Pat_type = Outpatient

2 VALID Pat_id=010 It should generate the final It generates the final bill
bill including doctor charges including doctor charges and
Ch = N
and admission details. inpatient admission details.
Pat_type = Inpatient

2 INVALID Pat_id=010 It should ask to enter a It calculates the bill including

character (Y for yes, else any doctor charges and inpatient
Ch = *
other character) to know admission details.
Pat_type = Inpatient whether to consider tests or
not.

3 VALID Pat_id=000 Pat_id=000 is not in the It enters a do while loop and

patient database, so it should asks to enter a valid patient id
Ch = N
ask to enter a valid patient id, until a valid patient id is not
Pat_type = Outpatient and generate the bill entered.
including only doctor charges
for the valid patient id.

3 INVALID Pat_id= Null It should ask to enter a valid It enters a do while loop and
patient id. asks to enter a valid patient id
Ch = N
until a valid patient id is not
Pat_type = Outpatient entered.
 P a g e | 28

4 VALID Pat_id=011 It should generate the final It generates the bill including
bill including doctor charges doctor charges and the test
Ch = Y
and the test undergone (only undergone for the patient.
Ch1= N one test).

Pat_type = Outpatient

4 INVALID Pat_id=011 It should ask to enter the test It do not consider the tests and
undergone (if any). generate the bill including only
Ch = *
doctor charges.
Ch1 =N

Pat_type = Outpatient

5 VALID Pat_id=000 Since patient id=000 is not in It generates the final bill for
the patient database, it pat_id = 011 including only
Ch = N
should ask to enter a valid doctor fees.
Pat_type = Outpatient patient id. When a valid
patient id (011) is entered, it
should generate the final bill
including doctor charges only.

5 INVALID Pat_id = Null It should ask to enter a valid IT enters a do while loop to ask
patient id, so it should enter for a valid patient id.
Ch = N
the do while loop to ask for a
Pat_type = OutPatient valid patient id.

6 VALID Pat_id=011 It should generate the final It generates the final bill
bill including all the tests including the doctor fees and all
Ch = Y
undergone (more than one) the tests fees that are
Ch1 = Y and the doctor fees. performed on the patient.

Pat_type = OutPatient

6 INVALID Pat_id=011 It should ask to enter a valid It generates the bill including
character (Y for yes, else any the doctor fees and the fees of
Ch = Y
other character) to know if only one test.
Ch1 = * there is another test done on
the patient.
Pat_type = OutPatient
 P a g e | 29

8.References

1. R.S. Pressman, Software Engineering: A Practitioner’s Approach

2. P. Jalote, An Integrated Approach to Software Engineering.

3. http://www.slideshare.net/hospital-management-system