Vous êtes sur la page 1sur 109

Final Project Report

Hospital Management System

Project Supervisor

Sarfraz Ahmad Awan

Submitted By

f09204002

Muhammad Usman Rashid BC060200052


Tallat Yousaf MC080407658

Software Projects & Research Section,


Department of Computer Sciences,
Virtual University of Pakistan

CERTIFICATE
This is to certify that Muhammad Usman Rashid (BC060200052), Tallat
Yousaf (MC080407658) have worked on and completed their Software Project
at Software & Research Projects Section, Department of Computer Sciences,
Virtual University of Pakistan in partial fulfillment of the requirement for the
degree of BS in Computer Sciences under my guidance and supervision.

In our opinion, it is satisfactory and up to the mark and therefore fulfills the
requirements of BS in Computer Sciences.

Supervisor / Internal Examiner

Sarfraz Ahmad Awan


Supervisor,
Software Projects & Research Section,
Department of Computer Sciences
Virtual University of Pakistan

___________________
(Signature)

External Examiner/Subject Specialist


<<External Supervisor Name>>

___________________
(Signature)
Accepted By:
_____________
(For office use)

EXORDIUM
In the name of Allah, the Compassionate, the
Merciful.

Praise be to Allah, Lord of Creation,


The Compassionate, the Merciful,
King of Judgment-day!

You alone we worship, and to You alone we


pray for help,
Guide us to the straight path

The path of those who You have favored,

Not of those who have incurred Your wrath,


Nor of those who have gone astray.
DEDICATION

With the highest form of reverence that there can exist in our hearts we
wish to dedicate our work to the prime teacher of all mankind and the
only organized being that existed to give meaning to the word “Perfect”,
the pride of Islamic Ummah, our Holy Prophet,

HAZRAT MOHAMMAD S.A.W.W

Moreover, we wish to dedicate our work to our beloved parents who


continue to bless us with their un-ending support in every possible aspect
and last but not the least to our teachers who being our spiritual parents
educated us and brought out the best out of us.

All of them making us who we are today.


ACKNOWLEDGEMENT

Our Sincere thanks to our supervisor “Prof Sarfraz Ahmad Awan” who has given us this
opportunity of doing Our thesis work at Virtual University of Pakistan. My heart-felt thanks to
my family, friends and colleagues who have helped me for the completion of this work. My
special thanks to Faisal Hussain and Sir Saleem for their support and encouragement
throughout this project.

Finally we would like to direct a sincere Thank you to our family. You have always been
there, always supported me with whatever means you have had available, always encouraged
us. Especially, my wonderful parents.
PREFACE

In the modern age, growing information needs large data storage, quick processing and fast
retrieval. Henceforth to, complete the world and to live in this information era with and honor, it
has became imperative to employ modern tools and techniques to serve the said purpose.
In this perspective computer based system was designed and proposed to replace the existing
manual system and automate the above mentioned systems.
The system proposed is error free with least redundancy and remedies the problem encountered
presently and anticipated in future. The system proposed is web based. It has the capacity of
further extension to accommodate any sort of changes.
TABLE OF CONTENTS

CHAPTER NO. 1
GATHERING & ANALYZING INFO..............................10

1.1 INTRODUCTION
1.2 PURPOSE
1.3 SCOPE
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
1.5 USE CASES AND USAGE SCENARIOS
1.5.1 Use Case Diagrams
1.5.2 Usage Scenarios
1.6 SUPPLEMENTARY REQUIREMENTS
1.6.1 Usability
1.6.2 Reliability
1.6.3 System Requirements

CHAPTER NO. 2
PLANNING THE PROJECT.........................................11
2.1 INTRODUCTION
2.2 METHODOLOGY
2.2.1 AVAILABLE METHODOLOGIES
2.2.2 CHOSEN METHODOLOGY
2.2.3 REASONS FOR CHOSEN METHODOLOGY
2.4 WORK PLAN
2.5 PROJECT STRUCTURE
2.5.1 Team Structure

2.5.1 Project Schedule


CHAPTER NO. 3
DESIGNING THE PROJECT.....................................................12

3.1 INTRODUCTION
3.1.1 Introduction
3.1.2 purpose
3.2 PURPOSE
3.3 SCOPE
3.4 DEFINITIONS
3.5 ARCHITECTURE DESIGN DIAGRAM
3.6 DYNAMIC MODEL: SEQUENCE DIAGRAMS
3.7 OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM
3.8 IMPLEMENTATION VIEW
3.8.1 Overview
3.9 DEPLOYMENT MODEL
3.10 DATABASE MODEL
3.11 GRAPHICAL USER INTERFACES

Chapter no.4
DEVELOPMENT PLAN...........................................................13
INTRODUCTION
4.1 Technology Selection
4.2.1 PHP
4.2.2 WAMP Server
4.2.3 Dream Weaver Macromedia

4.3 Development Tools

CHAPTER NO.5
DEPLOYMENT......................................................................14
5.1 DEPLOYMENT PLAN
5.1.1 Introduction
CHAPTER 1
Gathering & Analyzing Info

1.1 INTRODUCTION
Hospital Management System is a web database application that is constructed with
HTML web pages, PHP programming & WAMP Server Database accessing so that
people can make online interaction easily without going outside home.
This system basically automates all the activities done manually, Which includes the
specific activities of a doctor and patient. A patient has to take appointment and get
doctor info and so on. Similarly maintains the appointment details of the doctor and
assigns suitable slots of time to patients, maintains records about patients. The HMS will
provide an interface to perform all these tasks.
In the recent years, organizations/clinics main purpose to take advantage to users by the
mean of advertising their products and providing their services to users in a very easiest
way.For providing such informating and user oriented services to their users now
organization/clinics are putting their services on the internet.
In this project we will try to learn how a typical record can be moved from manual system
to the computerized system.

1.2 PROJECT OBJECTIVES

Our main objectives are:


1. Boost up the system and facilitate the user to execute any query without depending on the
geographical location.
2. Reduce the cost
3. Reduce the processing time
4. Facilitate the large number of users
5. Reduce the conflict in data
6. Provide all information on the World Wide Web
7. Provide an organized view of data to user.
8. Provide user friendly interface that will help the patients to get information about
specialists, get appointments, and comment about their satisfaction.
9. Provide the medical community with access to medical information through the Web
browser.
10. User can find all the basic info about specialist, appointments, timings etc.
1.3 SCOPE

This Hospital Management System covers a wide range of hospital administration and
management processes. It is an integrated end-to-end Hospital Management System that provides
relevant information across the hospital to support effective decision making for patient care,
hospital administration, hospital management and critical financial accounting, in a seamless
flow.

1.3.1. Registration
1.3.2. Inpatient Management
1.3.3. Outpatient Management
1.3.4. Laboratory
1.3.5. Staff Management
1.3.6. Emergency Services
1.3.7. Blood Bank
1.3.8. Billing System

1.4 Purpose
Our main purpose is to learn advance tool and technique that help us to put the system on the
internet so that everyone can access information and services without depending on geographical
locations.

1.5 USE CASES AND USAGE SCENARIOS


1.5.1 Use Case Diagrams

Add Staff

Search Staff

Delete Staff

Modify Staff <<uses>> Room Reservation

Administrator
Set Access Rights
<<extend >> Case Papers <<uses>> Assign Doctor

<<extend >> Add Inpatient


Assign Nurse
<<uses>>
Patient ID and
Password
<<extend >>

Add Patient

<<extend >> <<uses>>


Case Papers Referred Doctor

Add Outpatient
<<extend >>
Patient ID and
Password
<<extend >>

<<extend >> Search Inpatient


Check Schedule
Receptionist
Search Patient

Search Outpatient
<<extend >>

<<extend >> Modify Inpatient Nurs

Modify Patient

Modify Outpatient
<<extend >>
<<uses>> Check Access
Rights

<<extend >> Delete Inpatient

Delete Patient

Delete Outpatient
<<extend >>
Patient

<<extend >> Organ Donation

<<extend >>
Emergency Services Blood Donation

<<extend >>Assign Ambulance

About Forget Passwod

<<uses>> <<uses>>

Check Access
Edit Profile Change Password
<<uses>> Rights <<uses>>
<<uses>>
<<uses>>

Logout Login

Check Schedule
<<extend >>
Prescribed
Medicines
Add Staff

Search Staff

Delete Staff

Modify Staff <<uses>> Room Reservation

Administrator
Set Access Rights
<<extend >> Case Papers <<uses>> Assign Doctor

<<extend >> Add Inpatient


Assign Nurse
<<uses>>
Patient ID and
Password
<<extend >>

Add Patient

<<extend >> <<uses>>


Case Papers Referred Doctor

Add Outpatient
<<extend >>
Patient ID and
Password
<<extend >>

<<extend >> Search Inpatient


Check Schedule
Receptionist
Search Patient

Search Outpatient
<<extend >>

<<extend >> Modify Inpatient Nurs

Modify Patient

Modify Outpatient
<<extend >>
<<uses>> Check Access
Rights

<<extend >> Delete Inpatient

Delete Patient

Delete Outpatient
<<extend >>
Patient

<<extend >> Organ Donation

<<extend >>
Emergency Services Blood Donation

<<extend >>Assign Ambulance

About Forget Passwod

<<uses>> <<uses>>

Check Access
Edit Profile Change Password
<<uses>> Rights <<uses>>
<<uses>>
<<uses>>

Logout Login

Check Schedule
<<extend >>
Prescribed
Medicines

Diagnose Record
1.5.2 Usage Scenarios
4.1 Login:

Use Case Title # Login


Use Case ID # 4.1

Blood Bank
Administrator Cashier
Assistant

Login

<<Uses>>

Check Access
Rights
Receptionist Lab Technician

Patient Doctor Nurse


Use case Title: Login
Abbreviated Title: None
Use case Id: 4.1
Actors: Administrator / Receptionist/Patient/Doctor/Nurse/Lab
Technician/Blood Bank Assistant/Cashier
Description: This use case shows the login step of HMS, it is necessary to gain access to
other functionality of the system.
Pre-condition: User must have a valid ID and password to login.
Task Sequence: Exceptions
1. Click on “login” from the
main page
2. Enter your ID.
3. Enter password
4. Click login/sign in button System verifies the ID and password are correct; if
found than the system will allow the user to enter to the
system.
Post Conditions: Member is logged in to the system and now the member can use the system.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.2 Add Staff:

Use Case Title # Add Staff


Use Case ID # 4.2

Administrator

Add Staff

Staff
4.3 Search Staff

Use case Title: Add Staff


Abbreviated Title: None
Use case Id: 4.2
Actors: Administrator/Staff
Description: This use case shows that the administrator can add staff into the HMS. It is
necessary for staff to gain access to other functionality of the system.
Pre-condition: Administrator clicked on the add staff button.
Task Sequence: Exceptions
1. Administrator clicked on
the add staff button.
2. Administrator gets the info
from the staff.
3. Administrator added the
member and gives him ID
and password.
Post Conditions: Now staff is the member of the system and can now use the system with
specific ID and password given to him by the administrator.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Search Staff
Use Case ID # 4.3

Search Staff

Administrator

Use case Title: Search Staff


Abbreviated Title: None
Use case Id: 4.3
Actors: Administrator
Description: This use case shows that the administrator can search the staff from the HMS.
Pre-condition: Staff member is added into the system.
Task Sequence: Exceptions
1. Administrator clicks on the System asks for the specific ID.
search button.
2. Administrator enters the ID. System searches for the specific ID.
Post Conditions: Now the staff information is available to the administrator.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.4 Modify Staff
Use Case Title # Modify Staff
Use Case ID # 4.4

Modify Staff

Administrator

Use case Title: Modify Staff


Abbreviated Title: None
Use case Id: 4.4
Actors: Administrator
Description: This use case shows that the administrator can modify the staff from the HMS.
Pre-condition: Staff member is added into the system.
Task Sequence: Exceptions
1. Administrator searches for
the specific record.
2. Administrator changes the System confirms of modification
specific record.
3. Administrator confirms. System saves the changes.
Post Conditions: Now staff information is changed. Now he will interact with the system
with modified info.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.5 Delete Staff
Use Case Title # Delete Staff
Use Case ID # 4.5

Delete Staff

Administrator

Use case Title: Delete Staff


Abbreviated Title: None
Use case Id: 4.5
Actors: Administrator
Description: This use case shows that the administrator can delete the staff from the HMS.
Pre-condition: Staff member is added into the system.
Task Sequence: Exceptions
1. Administrator searched for
the specific record.
2. Administrator deleted the
specific record. System confirms deletion.
3. Administrator confirms. System deletes the record.
Post Conditions: Now this staff member is not available in HMS.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.6 Set Access Rights
Use Case Title # Set Access
Rights
Use Case ID # 4.6

Set Access Rights

Administrator

Use case Title: Set Access Rights


Abbreviated Title: None
Use case Id: 4.6
Actors: Administrator
Description: This use case shows that the administrator can set the access rights for all the
users of this system.
Pre-condition: Users is registered into the system.
Task Sequence: Exceptions
1. Administrator clicks on a
specific department rights.
2. Administrator sets their System confirms to set access rights.
access rights.
3. Administrator confirms. System sets access right for that department.
Post Conditions: Depending upon user’s rights, some user’s are restricted to some
functionality and some got access to it.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.7 Add Patient:
Use Case Title # Add Patient
Use Case ID # 4.7

Administrator

Add patient

Receptionist

Patient

Use case Title: Add Patient


Abbreviated Title: None
Use case Id: 4.7
Actors: Administrator/Receptionist/Patient
Description: This use case shows that the receptionist can add new patient into the system.
Pre-condition: Receptionist clicked on the addpatient button.
Task Sequence: Exceptions
1. Receptionist clicked on the
add patient button.
Post Conditions: Receptionist now chooses whether the patient is an inpatient or outpatient.
Unresolved Issues: None
Extended: Inpatient Registration, Output Registration
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.8 Add Inpatient
Use Case Title # Add
Inpatient
Use Case ID # 4.8

Administrator

<<Extend>>
Add Inpatient

Add patient

Receptionist

Patient
4.9 Inpatient Case Papers
Use Case Title # Inpatient
Case Papers
Use Case ID # 4.9

Administrator

<<extends>> Inpatient Case


Papers

<<Extends>>
Add patient Add Inpatient

Receptionist

Patient

Use case Title: Inpatient


Add Inpatient
Case Papers
Abbreviated Title: None
Use case Id: 4.8
4.9
Actors: Administrator/Receptionist/Patient
Description: This use case shows that the system
receptionist
will generate
can add newcaseInpatient
papers that
intocontain
the system.
the
patient detail.
Pre-condition:
Pre-condition: Receptionist
Receptionist clicked
clicked on
on the
the add patient button.
Inpatient button.
Task
Task Sequence: Exceptions
Sequence: Exceptions
1. Receptionist clicked on the
1. System will add patient
add Inpatient
personal info.button.
2. Receptionist registered the
2. Receptionist will assign
patient
Doctor byandgetting
Nursesinfo from
to the
him.
patient.
Post
Post Conditions: Patient
Conditions: is now added into
bethe system in Inpatient
These case papers will used throughout patientsection.
treatment.
Unresolved
Unresolved Issues: None
Issues: None
Extended: Case Papers, Patient
Extended: NoneID and Password
Uses: None Doctor, Assign Nurse
Uses: Room Reservation, Assign
Authority: Private
Authority: Private
Modification
Modification History:
History: 17/12/2009
17/12/2009
Author: f090204002
Author: f090204002 (bc060200052,
(bc060200052, mc080407658)
mc080407658)
4.10 Room Reservation
U se Case Title
# R oom
Reservation
U se C ase ID
# 4.10

A dm inistrator
<<uses>>
Roo m R eservation

<<E xtend> > <<E xtend> >


Nurse
Inpatient C ase
Add patient A dd Inpatient
Papers

R eceptionist

Doctor

Patient

4.11 Assign Doctor


Use case Title: Room Reservation
Abbreviated Title: None
Use case Id: 4.10
Actors: Administrator/Receptionist/Patient/Nurse/Doctor
Description: By checking the availability, the receptionist will reserve a room for the
inpatient.
Pre-condition: Receptionist clicked on the Inpatient button.
Task Sequence: Exceptions
1. Receptionist will reserve a If room is reserved previously then the system show a
room for the patient. prompt that room is not available.
2. Receptionist will reserve
another room.
Post Conditions: Patient treatment will be done in this room.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
U se C ase Title
# As sign
Doctor
U se Case ID# 4.11

Adm inistra tor


<<uses>>
A ssign Doctor

<<Exte nd> > <<Extend>>


Inpatien t Case
A dd patient A dd Inpatient
P ap ers

R e ce ptionis t

Pa tient

4.12 Assign Nurse


Use case Title: Assign Doctor
Abbreviated Title: None
Use case Id: 4.11
Actors: Administrator/Receptionist/Patient
Description: By checking the availability, the receptionist will assign a doctor for the
inpatient.
Pre-condition: Receptionist clicked on the Inpatient button.
Task Sequence: Exceptions
1. Receptionist will assign a If doctor is not available, then the system show a
doctor. prompt that doctor is not available.
2. Receptionist will assign
another doctor.
Post Conditions: Patient treatment will be carried out by this doctor.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
Use Case Title
# Assign
Nurse
Use Case ID# 4.12

Administrator
<<uses>>
Assign Nurse

<<Extend>> <<Extend>>
Inpatient Case
Add patient Add Inpatient
Papers

Receptionist

Patient

4.13 Inpatient ID and Password

Use case Title: Assign Nurse


Abbreviated Title: None
Use case Id: 4.12
Actors: Administrator/Receptionist/Patient
Description: By checking the availability, the receptionist will assign a Nurse for the
inpatient.
Pre-condition: Receptionist clicked on the Inpatient button.
Task Sequence: Exceptions
1. Receptionist will assign a If a Nurse is not available, then the system show a
Nurse. prompt that Nurse is not available.
2. Receptionist will assign
another Nurse.
Post Conditions: Nurse will assist in patient treatment.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Inpatient ID
and Password
Use Case ID # 4.13

Administrator
<<Extend>> Inpatient ID and
Password

<<Extend>>
Add patient Add Inpatient

Receptionist

Patient

Use case Title: Inpatient ID and Password


Abbreviated Title: None
Use case Id: 4.13
Actors: Administrator/Receptionist/Patient
Description: System will generate a unique ID and Password for the inpatient. So that he can
check his diagnose detail online.
Pre-condition: Receptionist clicked on the add Inpatient button.
Task Sequence: Exceptions
1. System will generate a
unique ID and password for
the Inpatient.
Post Conditions: Inpatient will use this ID and Password to login into the system online and
check its diagnose details.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.14 Add Outpatient
Use Case Title # Add
Outpatient
Use Case ID # 4.14

Administrator

<<Extend>>
Add Outpatient

Add patient

Receptionist

Patient
4.15 Outpatient Case Papers
Use Case Title # Outpatient
Case Papers
Use Case ID # 4.15

Administrator

<<Extend>> Outpatient Case


Papers

<<Extend>>
Add patient Add Outpatient

Receptionist

Patient

Use case Title: Outpatient


Add Outpatient
Case Papers
Abbreviated Title: None
Use case Id: 4.14
4.15
Actors: Administrator/Receptionist/Patient
Description: This use case shows that the system
receptionist
will generate
can add new
caseOutpatient
papers thatinto
contain
the the
system.detail.
patient
Pre-condition: Receptionist clicked on the Inpatient
add patient
button.
button.
Task Sequence: Exceptions
1. System
Receptionist
will add
clicked
patient
on the
add Outpatient
personal info. button.
2. Receptionist will
registered
refer the
the
patient to
by agetting
doctor.info from
him.
Post Conditions: These case papers will be used throughout patient treatment.
Post Conditions: Patient is now added into the system in Outpatient section.
Unresolved Issues: None
Unresolved Issues:
Extended: None
Extended:
Uses: Case Papers, PatientDoctor
Referred ID and Password
Uses:
Authority: None
Private
Authority: History: 17/12/2009
Modification Private
Modification History:f090204002
Author: 17/12/2009(bc060200052, mc080407658)
Author: f090204002 (bc060200052, mc080407658)
4.16 Referred Doctor
U se C ase Title
# R eferred
D octor
U se C ase ID# 4.16

A d m inistrator
<<U ses>>
R eferred D octor

<<Extend>> <<E xtend> >


O utpatient C ase
A dd patient Add O utpatient
P apers

R e cep tionist

P atien t

Use case Title: Referred Doctor


Abbreviated Title: None
Use case Id: 4.16
Actors: Administrator/Receptionist/Patient
Description: By checking the availability, the receptionist will assign a doctor for the
outpatient.
Pre-condition: Receptionist clicked on the add outpatient button.
Task Sequence: Exceptions
1. Receptionist will assign a If doctor is not available, then the system show a
doctor. prompt that doctor is not available.
2. Receptionist will assign
another doctor.
Post Conditions: Patient treatment will be carried out by this doctor.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.17 Outpatient ID and Password
Use Case Title # Outpatient
ID and Password
Use Case ID # 4.17

Administrator
<<Extend>>
Outpatient ID and
Password

<<Extend>>
Add patient Add Outpatient

Receptionist

Patient

Use case Title: Outpatient ID and Password


Abbreviated Title: None
Use case Id: 4.17
Actors: Administrator/Receptionist/Patient
Description: System will generate a unique ID and Password for the outpatient. So that he
can check his diagnose detail online.
Pre-condition: Receptionist clicked on the add Outpatient button.
Task Sequence: Exceptions
1. System will generate a
unique ID and password for
the Outpatient.
Post Conditions: Outpatient will use this ID and Password to login into the system online and
check its diagnose details.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.18 Search Patient

Use Case Title # Search


Patient
Use Case ID # 4.18

Administrator

Search Patient

Receptionist

Use case Title: Search Patient


Abbreviated Title: None
Use case Id: 4.18
Actors: Administrator /Receptionist
Description: This use case shows that the receptionist can search the specific patient from the
HMS.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist clicks on the
search button.
Post Conditions: Receptionist then chooses whether the patient is an inpatient or outpatient.
Unresolved Issues: None
Extended: Search Inpatient, Search Outpatient
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.19 Search Inpatient

Use Case Title # Search


Inpatient
Use Case ID # 4.19

<<Extend>>
Search Inpatient

Administrator

Search Patient

Receptionist

Use case Title: Search Inpatient


Abbreviated Title: None
Use case Id: 4.19
Actors: Administrator /Receptionist
Description: This use case shows that the receptionist can search the specific inpatient from
the HMS by using its ID.
Pre-condition: Receptionist clicked on the search patient.
Task Sequence: Exceptions
1. Receptionist clicks on the System asks for a specific patient ID.
search inpatient button.
2. Receptionist enters the ID. System searches for the specific ID.
Post Conditions: Patient information is available to the receptionist.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.20 Search Outpatient
Use Case Title # Search
Outpatient
Use Case ID # 4.20

<<Extend>>
Search Outpatient

Administrator

Search Patient

Receptionist

Use case Title: Search Outpatient


Abbreviated Title: None
Use case Id: 4.20
Actors: Administrator /Receptionist
Description: This use case shows that the receptionist can search the specific outpatient from
the HMS by using its ID.
Pre-condition: Receptionist clicked on the search patient.
Task Sequence: Exceptions
1. Receptionist clicks on the System asks for a specific patient ID.
search outpatient button.
2. Receptionist enters the ID. System searches for the specific ID.
Post Conditions: Patient information is available to the receptionist.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.21 Modify Patient

Use Case Title # Modify


Patient
Use Case ID # 4.21

Administrator

Modify Patient

Receptionist

Use case Title: Modify Patient


Abbreviated Title: None
Use case Id: 4.21
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can modify patient record by using its
ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist clicks on the
search patient button.
Post Conditions: Now receptionist has to select to modify inpatient or outpatient record.
Unresolved Issues: None
Extended: Modify Inpatient, Modify Outpatient
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.22 Modify Inpatient
Use Case Title # Modify
Inpatient
Use Case ID # 4.22

<<Extend>>
Modify Inpatient

Administrator

Modify Patient <<Uses>>

Check Access
Rights

Receptionist
4.23 Modify Outpatient

Use case Title: Modify Inpatient


Abbreviated Title: None
Use case Id: 4.22
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can modify inpatient record by using
its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist searches for
the specific record by ID.
2. Receptionist changes the System confirms of modification
specific record.
3. Receptionist confirms. System saves the changes.
Post Conditions: Patient information is changed. Now he will interact with the system with
modified info.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Modify
Outpatient
Use Case ID # 4.23

<<Extend>>
Modify Outpatient

Administrator

Modify Patient <<Uses>>

Check Access
Rights

Receptionist

Use case Title: Modify Outpatient


Abbreviated Title: None
Use case Id: 4.23
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can modify outpatient record by
using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist searches for
the specific record by ID.
2. Receptionist changes the System confirms of modification
specific record.
3. Receptionist confirms. System saves the changes.
Post Conditions: Patient information is changed. Now he will interact with the system with
modified info.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.24 Delete Patient

Use Case Title # Delete


Patient
Use Case ID # 4.24

Administrator

Delete Patient

Receptionist

Use case Title: Delete Patient


Abbreviated Title: None
Use case Id: 4.24
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can delete patient record by using its
ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist clicked on the
delete patient button.
Post Conditions: Now receptionist has to select to delete inpatient or outpatient record.
Unresolved Issues: None
Extended: Delete Inpatient, Delete Outpatient
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)

4.25 Delete Inpatient


Use Case Title # Delete
Inpatient
Use Case ID # 4.25

<<Extend>>
Delete Inpatient

Administrator

Delete Patient <<uses>>

Check Access
Rights

Receptionist

Use case Title: Delete Inpatient


Abbreviated Title: None
Use case Id: 4.25
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can delete inpatient record by using
its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist searches for
the specific record.
2. Receptionist deletes the
specific record. System confirms deletion.
3. Receptionist confirms. System deletes the record.
Post Conditions: Now that inpatient is no longer part of the system.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.26 Delete Outpatient
Use Case Title # Delete
Outpatient
Use Case ID # 4.26

<<Extend>>
Delete Outpatient

Administrator

<<uses>>
Delete Patient

Check Access
Rights

Receptionist

Use case Title: Delete Outpatient


Abbreviated Title: None
Use case Id: 4.26
Actors: Administrator /Receptionist
Description: Depending upon its rights, the receptionist can delete outpatient record by
using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist searches for
the specific record.
2. Receptionist deletes the
specific record. System confirms deletion.
3. Receptionist confirms. System deletes the record.
Post Conditions: Now that outpatient is no longer part of the system.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.27 Diagnose Record

Use Case Title #Diagnose


Record
Use Case ID # 4.27

Administrator

Diagnose Record

Doctor

Use case Title: Diagnose Record


Abbreviated Title: None
Use case Id: 4.27
Actors: Administrator/Doctor
Description: This use case shows that the doctor will add diagnose record for a specific
patient by using its ID.
Pre-condition: Doctor clicked on the diagnose record button.
Task Sequence: Exceptions
1. Doctor clicked on the
diagnose record button.
2. Doctor added diagnostic
record of the patient.
Post Conditions: This record will be used throughout patient treatment.
Unresolved Issues: None
Extended: Prescribe Medicines, Prescribe Tests
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.28 Prescribed Medicines

Use Case Title #Prescribed


Medicines
Use Case ID # 4.28

<<Extend>> Prescribed
Medicines

Administrator

Diagnose Record

Doctor

Use case Title: Prescribed Medicines


Abbreviated Title: None
Use case Id: 4.28
Actors: Administrator/Doctor
Description: This use case shows that the doctor will prescribe medicines to the patient
which will be saved with the patient record.
Pre-condition: Doctor clicked on the diagnose record button.
Task Sequence: Exceptions
1. Doctor clicked on the
prescribed medicines
button.
2. Doctor added prescribed
medicines into the patient
record.
Post Conditions: This record will be used throughout patient access.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.29 Prescribed Tests

Use Case Title #Prescribed


Tests
Use Case ID # 4.29

<<Extend>>
Prescribed Tests

Administrator

Diagnose Record

Doctor

Use case Title: Prescribed Tests


Abbreviated Title: None
Use case Id: 4.29
Actors: Administrator/Doctor
Description: This use case shows that the doctor will prescribe tests to the patient which will
be saved with the patient record.
Pre-condition: Doctor clicked on the diagnose record button.
Task Sequence: Exceptions
1. Doctor clicked on the
prescribed test button.
2. Doctor added prescribed
tests into the patient record.
Post Conditions: This record will be used throughout patient access.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.30 Patient Billing
Use Case Title #Patient
Billing
Use Case ID # 4.30

Administrator

Patient Billing

Cashier

Use case Title: Patient Billing


Abbreviated Title: None
Use case Id: 4.30
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle patient billing details.
Pre-condition: Cashier clicked on patient billing.
Task Sequence: Exceptions
1. Cashier clicked on patient
billing.
Post Conditions: Cashier now chooses whether the patient is an inpatient or outpatient.
Unresolved Issues: None
Extended: Inpatient Billing, Outpatient Billing
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.31 Inpatient Billing
Use Case Title #Inpatient
Billing
Use Case ID # 4.31

<<Extend>>
Inpatient Billing

Administrator

Patient Billing

Cashier

Use case Title: Inpatient Billing


Abbreviated Title: None
Use case Id: 4.31
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle inpatient billing details.
Pre-condition: Cashier clicked on patient billing.
Task Sequence: Exceptions
1. Cashier clicked on inpatient
billing.
2. Cashier entered the ID of System generated the inpatient personal information.
the inpatient.
3. Cashier added the billing
detail of the inpatient.
Post Conditions: Inpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: Doctor Charges, Room Charges, Medical Treatment
Charges
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.32 Doctor Charges
Use Case Title #Doctor Charges
Use Case ID # 4.32

<<Uses>>
Doctor Charges

Administrator
<<Extend>>
Patient Billing Inpatient Billing

Cashier

Use case Title: Doctor Charges


Abbreviated Title: None
Use case Id: 4.32
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle inpatient billing including
doctor charges.
Pre-condition: Cashier clicked on Inpatient billing.
Task Sequence: Exceptions
1. Cashier will enter doctor
charges.
Post Conditions: Inpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.33 Hospital Charges
Use Case Title #Hospital Charges
Use Case ID # 4.33

<<Uses>>
Hospital Charges

Administrator
<<Extend>>
Patient Billing Inpatient Billing

Cashier

Use case Title: Hospital Charges


Abbreviated Title: None
Use case Id: 4.33
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle inpatient billing including room
charges.
Pre-condition: Cashier clicked on Inpatient billing.
Task Sequence: Exceptions
1. Cashier will enter room
charges.
Post Conditions: Inpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.34 Medical Treatment Charges
Use Case Title #Medical
Treatment Charges
Use Case ID # 4.34

<<Uses>> Medical Treatment


Charges

Administrator
<<Extend>>
Patient Billing Inpatient Billing

Cashier

Use case Title: Medical Treatment Charges


Abbreviated Title: None
Use case Id: 4.34
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle inpatient billing including
medical treatment charges. These are those medicines charges that are used during patient
treatment.
Pre-condition: Cashier clicked on Inpatient billing.
Task Sequence: Exceptions
1. Cashier will enter medical
treatment charges.
Post Conditions: Inpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.35Outpatient Billing
Use Case Title #IOutpatient
Billing
Use Case ID # 4.35

<<Extend>>
Outpatient Billing

Administrator

Patient Billing

Cashier

Use case Title: Outpatient Billing


Abbreviated Title: None
Use case Id: 4.35
Actors: Administrator/Cashier
Description: This use case shows that the cashier will handle outpatient billing details.
Pre-condition: Cashier clicked on patient billing.
Task Sequence: Exceptions
1. Cashier clicked on
outpatient billing.
2. Cashier entered the ID of System generated the outpatient personal information.
the outpatient.
3. Cashier added the billing
detail of the outpatient.
Post Conditions: Outpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: Doctor Charges
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.36 Doctor Charges
Use Case Title #Doctor Charges
Use Case ID # 4.36

<<Uses>>
Doctor Charges

Administrator
<<Extend>>
Patient Billing Outpatient Billing

Cashier

Use case Title: Doctor Charges


Abbreviated Title: None
Use case Id: 4.36
Actors: Administrator/Cashier
Description: This use case shows that the system will handle outpatient billing including
doctor charges.
Pre-condition: Cashier clicked on Outpatient billing.
Task Sequence: Exceptions
1. Cashier will enter doctor
charges.
Post Conditions: Outpatient billing process is completed.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.37 Add Test
Use Case Title # Add Test
Use Case ID # 4.37

Administrator

Add Test

Lab Technician

Use case Title: Add Test


Abbreviated Title: None
Use case Id: 4.37
Actors: Administrator/Lab Technician
Description: This use case shows that the lab technician will add new patient into laboratory
section of the system.
Pre-condition: Receptionist clicked on the add patient button.
Task Sequence: Exceptions
1. Lab technician clicked on
the add patient button.
2. Lab technician registered If patient is a former or present patient within the
the patient by getting info hospital then system will provide patient personal info
from him or from the by using its ID.
system.
Post Conditions: Patient is now added into the system in Laboratory section.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.38 Search Test
Use Case Title # Search Test
Use Case ID # 4.38

Administrator

Search Test

Lab Technician
4.39Modify Test

Use case Title: Search Test


Abbreviated Title: None
Use case Id: 4.38
Actors: Administrator /Lab Technician
Description: This use case shows that the lab technician can search the specific patient from
the laboratory section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Receptionist clicks on the System asks for a specific patient ID.
search patient button.
2. Receptionist enters the ID. System searches for the specific ID.
Post Conditions: Patient information is available to the lab technician.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Modify Test
Use Case ID # 4.39

<<Uses>> Check Access


Rights

Administrator

Modify Test

Lab Technician

Use case Title: Modify Test


Abbreviated Title: None
Use case Id: 4.39
Actors: Administrator /Lab Technician
Description: Depending upon its rights, the lab technician can modify patient record from
laboratory section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Lab Technician searches for
the specific record by ID.
2. Lab Technician changes the System confirms of modification
specific record.
3. Lab Technician t confirms. System saves the changes.
Post Conditions: Patient information is changed. Now he will interact with the system with
modified info.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.40 Delete Test
Use Case Title # Delete Test
Use Case ID # 4.40

<<Uses>> Check Access


Rights

Administrator

Delete Test

Lab Technician

Use case Title: Delete Test


Abbreviated Title: None
Use case Id: 4.40
Actors: Administrator /Lab Technician
Description: Depending upon its rights, the lab technician can delete patient record from
laboratory section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Lab Technician searches for
the specific record.
2. Lab Technician deletes the System confirms deletion.
specific record.
3. Lab Technician confirms. System deletes the record.
Post Conditions: Now that patient is no longer part of the laboratory section.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.41 Add Donor
Use Case Title # Add Donor
Use Case ID # 4.41

Administrator

Add Donor

Blood Bank
Assistant

Use case Title: Add Donor


Abbreviated Title: None
Use case Id: 4.41
Actors: Administrator/Blood Bank Assistant
Description: This use case shows that the blood bank assistant will add new patient into blood
bank section of the system.
Pre-condition: Blood Bank Assistant clicked on the add patient button.
Task Sequence: Exceptions
1. Blood Bank Assistant
clicked on the add patient
button.
2. Blood Bank Assistant If patient is a former or present patient within the
registered the patient by hospital then system will provide patient personal info
getting info from him or by using its ID.
from the system.
Post Conditions: Patient is now added into the system in blood bank section.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.42 Search Donor
Use Case Title # Search Donor
Use Case ID # 4.42

Administrator

Search Donor

Blood Bank
Assistant

Use case Title: Search Donor


Abbreviated Title: None
Use case Id: 4.42
Actors: Administrator /Blood Bank Assistant
Description: This use case shows that the blood bank assistant can search the specific patient
from the blood bank section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Blood Bank Assistant clicks System asks for a specific patient ID.
on the search patient button.
2. Blood Bank Assistant enters System searches for the specific ID.
the ID.
Post Conditions: Patient information is available to the Blood Bank Assistant.
Unresolved Issues: None
Extended: None
Uses: None
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.43Modify Donor
Use Case Title # Modify Donor
Use Case ID # 4.43

<<Uses>> Check Access


Rights

Administrator

Modify Donor

Blood Bank
Assistant

Use case Title: Modify Donor


Abbreviated Title: None
Use case Id: 4.43
Actors: Administrator / Blood Bank Assistant
Description: Depending upon its rights, the blood bank assistant can modify patient record
from blood bank section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Blood Bank Assistant
searches for the specific
record by ID.
2. Blood Bank Assistant System confirms of modification
changes the specific record.
3. Blood Bank Assistant System saves the changes.
confirms.
Post Conditions: Patient information is changed. Now he will interact with the system with
modified info.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
4.44 Delete Donor
Use Case Title # Delete Donor
Use Case ID # 4.44

<<Uses>> Check Access


Rights

Administrator

Delete Donor

Blood Bank
Assistant
1.6 SUPPLEMENTARY REQUIREMENTS

1.6.1 Usability
Up to 300 users may be using "Update Customer" at any one time.

1.6.2 Reliability
Update user will be available to users 98% of normal working hours.
The system shall be available all the time.

1.6.3 System Requirements

Operating System: Window Vista/XP

System Used: Intel Pentium Series Processor

RAM: 128

Use case Title: Delete Donor


Abbreviated Title: None
Use case Id: 4.44
Actors: Administrator / Blood Bank Assistant
Description: Depending upon its rights, the blood bank assistant can delete patient record
from blood bank section by using its ID.
Pre-condition: Patient is added into the system.
Task Sequence: Exceptions
1. Blood Bank Assistant
searches for the specific
record.
2. Blood Bank Assistant
deletes the specific record. System confirms deletion.
3. Blood Bank Assistant System deletes the record.
confirms.
Post Conditions: Now that patient is no longer part of the blood bank section.
Unresolved Issues: None
Extended: None
Uses: Check Access Rights
Authority: Private
Modification History: 17/12/2009
Author: f090204002 (bc060200052, mc080407658)
CHAPTER 2
Planning the Project
2.1INTRODUCTION
2.1.1 Introduction of the Planning Phase
In This document, we plan the entire project in order to accomplish successfully. First we
have to discuss the planning advantages to highlight the benefits of planning. Then we
have the several methodologies (Software Development lifecycle Models) which are
developed during software engineering history. After that we have to chosen the
methodology which fit the best for the adopted project and then we have to write the
reasons for why we adopted the specific methodology. Finally the Gantt chat which is the
graphically representation of entire planning of the project.

2.1.2 The advantages of planning in project:


Planning helps us to have a better idea about the course of action that we propose to take.
Planning better defines the course of action that we propose to undertake.
Planning gives a rough estimate of the time required for a project.
Planning gives us a fairly good idea about the expenses involved in the project. In fact a
budget is also a plan, a financial plan.
Planning helps us to get prepared for emergencies that may arise during the course of the
project.
A well though about plan gives us a clear idea about what is to be done every day, every
week and every month.
Planning helps avoid duplication of labor.
If a plan is followed, everyone will have a clear idea about his or her role.
2.2 METHODOLOGY

2.2.1 AVAILABLE METHODOLOGIES


There are a number of Software Development Lifecycle Models, each having its strengths
and weaknesses and suitable in different situations and project types. The list of models
includes the following:

1. Build-and-fix model

2. Waterfall model

3. Rapid prototyping model

4. Incremental model

5. Extreme programming

6. Synchronize-and-stabilize model

7. Spiral model

8. Object-oriented life-cycle models

2.2.2 CHOSEN METHODOLOGY


VU Process Model:
In this project, we choose the VU Process Model which is the combination of Waterfall
and Spiral model. In this model each stage of waterfall is preceded by identification of
alternatives and risk analysis and is then followed by evaluation and planning for the next
phase.

2.2.3 REASONS FOR CHOSEN METHODOLOGY


1. Hospital Management system is large scale-able project.

2. All the requirements are well understood from the given software Hospital
Management system(HMS).
3. Requirements are so clear and un-ambiguous that we have complete web-based
application in hand from where we already identify all the functional requirements
and there are very less chances of wrong understanding of requirements.

4. Small numbers of People are available, so the chances are mistakes are high.

5. VU Process Model is heavily dependent on risk analysis and evaluation in each phase.

6. This project runs for a long time, so maintenance required.

7. The deadline for the given project is good enough.

2.4 Work Plan:

2.5 PROJECT STRUCTURE


2.3.1 Team Structure

2.3.2 Project Schedule


CHAPTER 3
Designing the Project
3.1 INTRODUCTION
In this document following detail are provided about the HMS project:
 Class Diagram
 Database Design diagram
 Interface Design
 Deployment Diagram

3.2 PURPOSE

Hospitals are not merely profit making organizations, more over they have the
responsibility of taking care of human health. Since they provide prestigious service, they have a
higher value in the society. In order to maintain that value, hospitals must take utmost care in
providing health care services. Proper co- ordination of resources like man, machine, money and
material is required to maintain superior quality in services rendered. My Hospital Management
System is an ideal package for integrating an entire healthcare organization
Administrator can register staff by using add-staff. After successfully registering, the staff
members can use the services provided by the system. Administrator is also capable of
performing functions like search, modify and delete by depending upon the staff ID.
Receptionist is capable to adding patients (both inpatient and outpatient) and can also search,
modify and delete patient by depending on their ID. Cashier maintains the record of pay
distribution and also handles the patient billing (both inpatient and outpatient).
.Emergency services like blood bank, laboratory and ambulance are also handled by this HMS.
Patients can be added in these departments (like blood bank, laboratory) and can also be
searched, modified and deleted by depending on their ID.

3.3 SCOPE
The next important step in the development of the project is designing the system according to
the analysis.
In this chapter the design of the system is written in detail.
Designing of the system has been done according to the rules of software engineering. So we
have done the following kinds of design:
1. Logical Design
2. Physical Design

3.4 DEFINITIONS

 Class Diagram: A class represents an abstraction - the essence or the template of an


object. A class specifies an interface (the outside view - the public part) and defines an
implementation (the inside view - the private part). The interface primarily consists of the
declaration of all the operations applicable to instances of this class. The implementation
of a class primarily consists of the implementation of all the operations defined in the
interface of the class
 Database Design diagram: database design diagram depict the pictorial picture of
database design of the system.
 Interface Design: the blueprint for an architectural design of application is not complete
without a representation of front view, its various categories. All these functionalities
make up the interface design of a system. HMS interface design focuses on three area of
concern:
o The design of interfaces between software components
o The design of interfaces between the software and other nonhuman producers and
consumers of information
o The design of the interface between a user and the computer.
 Deployment Diagram: HMS deployment diagrams show a system’s physical layout,
revealing which pieces of application run on what pieces of hardware. Deployment
diagram feel the system really very simple.
3.5 Architecture Design Diagram

er
ws
b bro
We
er/
Us

Web Server

Presentation Layer

Application Layer

Communication
System Privilege Layer

Security
HMS Services

HMS HMS
HMS Patient HMS Blood HMS Staff
Laboratory Emergency
Services Bank Services Services
Services Services

Database Access Layer

Database

3.6 DYNAMIC MODEL: SEQUENCE DIAGRAMS

Login:
User

Login Page Home Page Signout HMS login Service

OpenHMS()

ID & Password()

Validate()

Alt
Redirect()
If Valid
updateRecord()

Else
Record failed

Signout()

doSignout() closeRecord()

Redirect()

Add Staff:
Administrator

Registration HMS Registration


Main Page service
Page

OpenHMS()

Redirect()

formFill()

Alt

If ID = Valid
Register()

Else
Verification

Record failed
<<create>>

SuccessfullyRegistered()
View or Modify Staff:

Administrator

Home Page Profile HMS Profile Service

Redirect()
View()

getProfile()
Edit()
doEditProfile()
providedData()
Data()

Update()
Search Staff:

Administrator

Home Page Search Search Results HMS Search Service

Redirect()

Redirect()

String()
Search()

Alt
View()
if found

else
Not
found
Delete Staff:

Administrator

Home Page Search Delete HMS Search Service HMS Delete Service

Redirect()

Redirect()

String()
Search()

Alt Delete()
if found

else
Not
found
Add Inpatient:

Admin or
Receptionist

Registration Inpatient HMS Registration


Main Page
Page Registration service

OpenHMS()

Redirect()
Redirect()

formFill()

Alt

If ID = Valid
Register()

Else
Verification

Record failed
<<create>>

SuccessfullyRegistered()
Add Outpatient:ss

Admin or
Receptionist
Registration Outpatient HMS Registration
Main Page
Page Registration service

OpenHMS()

Redirect()
Redirect()

formFill()

Alt

If ID = Valid
Register()

Else
Verification

Record failed
<<create>>

SuccessfullyRegistered()
View or Modify Patient:

Admin or Receptionist

Home Page Profile HMS Profile Service

Redirect()
View()

getProfile()
Edit()
doEditProfile()
providedData()
Data()
setAccessPermission()
Update()
Search Patient:

Admin or Receptionist

Home Page Search Search Results HMS Search Service

Redirect()

Redirect()

String()
Search()

Alt
View()
if found

else
Not
found
Delete Patient:

Admin or Receptionist

Home Page Search Delete HMS Search Service HMS Delete Service

Redirect()

Redirect()

String()
Search()

Alt Delete()
if found

else
Not
found
Inpatient Billing:

Cashier
Inpatient
Home Page HMS Billing Service
Billing

Redirect()
createBill()

getPatientInfo ()

getDoctorCharges ()

getHospitalCharges ()

getMedicalCharges ()

Data()
printFinalBill()
Outpatient Billing:

Cashier
Outpatient
Home Page HMS Billing Service
Billing

Redirect()
createBill()

getPatientInfo ()

getDoctorCharges ()

Data()

printFinalBill()
3.7 OBJECT MODEL/LOGICAL MODEL: CLASS DIAGRAM
1 1
Administrator Nurse
1 ID : String ID : String
Name : String
1 0.. * Name : String
1 Father Name : String
Gender : String
Father Name : String
Gender : String
DateOfBirth : String DateOfBirth : String
1 Address : String
mobileNo : Long
Address : String

0.. 1
mobileNo : Long

0.. *
staffType : String
1 addStaff () department Name : String
dutySchedule : String
searchStaff ()
modifyStaff ()
deleteStaff ()
getProfile ()
getProfile ()
searchPatient ()
setAccessRights ()
Logoff ()
Logoff ()

1.. *
1

Receptionist Cashier

ID : String 1 1 ID : String

0.. * Name : String


Father Name : String Login
Name : String
Father Name : String
Gender : String 0.. * 1 Gender : String
DateOfBirth : String ID : String 1 0.. * DateOfBirth : String
0.. *
Address : String Password : String Address : String
mobileNo : Long mobileNo : Long
staffType : String 1 staffType : String
department Name : String
dutySchedule : String
Login () 1 department Name : String
dutySchedule : String
addPatient () 1 1 1 payDistribution ()
searchPatient ()
modifyPatient () 1 Billing ()
getProfile ()
deletePatient ()
generateCasePapers () Logoff ()
Logoff ()

1
0.. *
0.. *

Billing
0.. *

patientID : String
0.. *

Name : String
0.. *

Doctor Patient Father Name : String


Gender : String
ID : String ID : String DateOfBirth : String
Name : String
Father Name : String
Name : String 0.. * Address : String
Father Name : String mobileNo : Long
Gender : String
DateOfBirth : String
Gender : String
DateOfBirth : String 1 referredDoctorID : String
referredDoctor Name : String
0.. * Address : String
mobileNo : Long 1 0.. *
Address : String department Name : String
mobileNo : Long admissionDate : Date
staffType : String
department Name : String
referredDoctorID : String
referredDoctor Name : String 0.. * lengthOfStay (): int
dutySchedule : String 0.. * department Name : String getProfile ()
admissionDate : Date roomCharges ()
searchPatient () doctorCharges ()
getProfile () getProfile () medicalTreatmentCharges ()
diagnoseRecord () Logoff ()
Logoff ()
0.. *
0.. *

0.. *

Lab _Technician Blood _Bank _Assistant

ID: String ID : String


Name : String
Father Name : String 1 1 Name : String
Father Name : String
0.. * Gender : String
DateOfBirth : String
Gender : String
DateOfBirth : String 0.. *
Address : String Address : String
mobileNo : Long mobileNo : Long
staffType : String staffType : String
department Name : String department Name : String
dutySchedule : String dutySchedule : String
add Donor ()
viewDoctorPrescribedTests () addDonor ()
search Donor () searchDonorbyID ()
modify Donor () searchDonor byBloodGroup ()
delete Donor () modifyDonor ()
Logoff () deleteDonor ()
Logoff ()
3.8 IMPLEMENTATION VIEW
3.8.1 Overview

After the completion of design phase, the implementation phase of the system starts to
converts the design into software with required functionality. The implementation phase
of any system is concerned with the tools used in the development work & the
components used to implement the system. This chapter explains all the steps taken for
the implementation of the system.
3.9 DEPLOYMENT MODEL

r er
ato Us
istr
min
Ad

Browser

Application Server Application Interface


DataBase Server

MySQL Database Presentation Layer

HMS Services

DB
Data Access Layer

3.10 DATABASE MODEL


Nurse
Administrator
PK ID
PK ID
Name
Name
FathrName
FathrName Gender
Gender
Date of Birth
Date of Birth
Address
Address mobileNo
mobileNo staffType
dutySchedule

Receptionist Cashier
PK ID PK ID
Login
Name Name
FathrName PK ID
FathrName
Gender Gender
Date of Birth Password
Date of Birth
Address Address
mobileNo mobileNo
staffType staffType
dutySchedule dutySchedule

Billing
Patient
PK patientID
Doctor
PK ID
Name
PK ID
Name FathrName
FathrName Gender
Name Date of Birth
FathrName Gender
Gender Date of Birth Address
Address mobileNo
Date of Birth
Address mobileNo admissionDate
mobileNo Docotor ID referredDoctorID
staffType DoctorName DoctorName
dutySchedule admissionDate length _of_ stay

Lab Technician Blood Bank Assistant

PK ID PK ID

Name Name
FathrName FathrName
Gender Gender
Date of Birth Date of Birth
Address Address
mobileNo mobileNo
staffType staffType
dutySchedule dutySchedule
3.11 INTERFACE DESIGN

Login Page:
Administrator Main Page:

Doctor Main Page:


Receptionist Main Page:
Staff Registration:
Inpatient Registration:
Outpatient Registration:
CHAPTER 4
Development
DEVELOPMENT PLAN

4.1 Introduction
After the completion of design phase, the development phase of the system starts to
converts the design into software with required functionality. The implementation phase
of any system is concerned with the tools used in the development work & the
components used to implement the system. This chapter explains all the steps taken for
the development of the system.

4.2 Technology Selection

We implemented our project using followings:

1. PHP for the server site processing request & the send back response
2. WAMP Server for making database
3. Dream Weaver Macromedia

4.2.1 PHP

PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language


that was originally designed for web development to produce dynamic web pages.
For this purpose, PHP code is embedded into the HTML source document and
interpreted by a web server with a PHP processor module, which generates the web
page document. As a general-purpose programming language, PHP code is processed
by an interpreter application in command-line mode performing desired operating
system operations and producing program output on its standard output channel. It
may also function as a graphical application. PHP is available as a processor for most
modern web servers and as standalone interpreter on most operating systems and
computing platform.PHP was originally created by Rasmus Lerdorf in 1995 and has
been in continuous development ever since. The main implementation of PHP is now
produced by the PHP Group & server as the de facto standard for PHP as there is no
formal specification. PHP is free software released under the PHP license.

4.2.2 WAMP Server


Wamp Server is a Windows web development environment. It allows you to create
Web applications with Apache, PHP and the MySQL database. It also comes with PHP
MyAdmin and SQLite Manager to easily manage your databases. Wamp Server installs
automatically (installer), and its usage is very intuitive. You will be able to tune your
server without even touching the setting files. Wamp Server is the only packaged
solution that will allow you to reproduce your production server. Once Wamp Server is
installed, you have the possibility to add as many Apache, MySQL and PHP releases as
you want. Wamp Server also has a trayicon to manage your server and its settings.

4.2.3 Dream Weaver Macromedia

Adobe Dreamweaver or Macromedia Dreamweaver is a web development application


originally created by Macromedia, and is now developed by Adobe Systems, which
acquired Macromedia in 2005.Dreamweaver is available for both Mac and Windows
operating systems. Recent versions have incorporated support for web technologies such
as CSS, JavaScript, and various server-side scripting languages and frameworks
including ASP, ColdFusion, and PHP.

4.3 Development Tools


After selecting the technologies to develop the system required by the Hospital
Management system, we decided the following tools through which we could
implement the design into a properly functioning system.

1. Microsoft FrontPage
2. Macromedia Dream Weaver MX
3. Microsoft Visio
4. Microsoft word
5. Microsoft Notepad
CHAPTER 5
Deployment
5.1 Introduction

 Test cases: testing presents an interesting anomaly for the software engineers,
who by their nature are constructive people. Test requires that the developer
discard preconceived notions of the “correctness” of application that is being
development and then work hard to design test cases to “break” the application.
the benefits of test cases are:
o A good test has a high probability of finding an error
o A good test is not redundant
o A good test should be “best of breed”.
o A good test should be neither too simple not too complex

5.2 Test Cases:


Test Case # 01

Test Case Title: Testing the Login mechanism of HMS


Test List Description Expectation
Preconditio Register to the system by add patient or add
n staff mechanism.
Action(s) • User browse to login page Browsed
• Enter ID & Password ---
• Trigger the sign-in button Verifying and
Redirecting to the
persons main page
• User logon to the system Signing-in Successful
Tested by: F09204002
Results Pass
Test Case # 02

Test Case Title: Testing the add staff mechanism of HMS


Test List Description Expectation
Precondition User currently is not a member
Action(s) • User browse to the system Browsed
• Trigger the addstaff button Redirecting to
registration page
• Filling registration form Getting correct data
• Trigger the “Register” button User is registered and
redirecting to main
page
• User is now the member of the system Registration Successful
Tested by: F09204002
Results Pass
Test Case # 03

Test Case Title: Testing the Search staff mechanism of HMS

Test List Description Expectation


Precondition Get onto the Main personal page
Action(s) • Enter ID to search ---
• Trigger Search ID found
• Show search results Successfully
Tested by: F09204002
Results Pass

Test Case # 04

Test Case Title: Testing the Modifying staff mechanism of HMS

Test List Description Expectation


Precondition Get onto the profile page
Action(s) • Trigger to Edit profile Providing the
fields to be edited
• Edit the profile ---
• Trigger “Save” Saved successfully
Tested by: F09204002
Results Pass

Test Case # 05

Test Case Title: Testing the Delete staff mechanism of HMS

Test List Description Expectation


Preconditio Get onto the main page
n
Action(s) • Entering the staff ID to be deleted found
• Trigger to Delete Confirm to delete
• Triggered confirm to delete Delete the record
• Record deleted Successfully
Tested by: F09204002
Results Pass

Test Case # 06

Test Case Title: Testing the add patient mechanism of HMS

Test List Description Expectation


Precondition User currently is not a member
Action(s) • User browse to the system Browsed
• Trigger the addpatient button Redirecting to
registration page
Tested by: F09204002
Results Pass

Test Case # 07

Test Case Title: Testing the add Inpatient mechanism of HMS

Test List Description Expectation


Precondition Addpatient button is triggered.
Action(s) • Trigger the addInpatient button Redirecting to
registration page
• Filling registration form Getting correct data
• Trigger the “Register” button User is registered and
redirecting to main page
• User is now the member of the system Registration Successful
Tested by: F09204002
Results Pass
Test Case # 08

Test Case Title: Testing the add Outpatient mechanism of HMS

Test List Description Expectation


Precondition Addpatient button is triggered.
Action(s) • Trigger the addOutpatient button Redirecting to
registration page
• Filling registration form Getting correct data
• Trigger the “Register” button User is registered and
redirecting to main page
• User is now the member of the system Registration Successful
Tested by: F09204002
Results Pass

Test Case # 09

Test Case Title: Testing the Search patient mechanism of HMS

Test List Description Expectation


Precondition Get onto the Main personal page
Action(s) • Search patient button is triggered browsed
Tested by: F09204002
Results Pass

Test Case # 10

Test Case Title: Testing the Search Inpatient mechanism of HMS

Test List Description Expectation


Precondition Search patient is triggered
Action(s) • Trigger the search inpateint button browsed
• Enter ID to search ---
• Trigger Search ID found
• Show search results Successfully
Tested by: F09204002
Results Pass
Test Case # 11

Test Case Title: Testing the Search Outpatient mechanism of HMS

Test List Description Expectation


Precondition Search patient is triggered
Action(s) • Trigger the search outpateint button browsed
• Enter ID to search ---
• Trigger Search ID found
• Show search results Successfully
Tested by: F09204002
Results Pass

Test Case # 12

Test Case Title: Testing the Modifying patient mechanism of HMS

Test List Description Expectation


Precondition Get onto the profile page
Action(s) • Trigger the modify patient button browssed
Tested by: F09204002
Results Pass

Test Case # 13
Test Case Title: Testing the Modifying Inpatient mechanism of HMS

Test List Description Expectation


Precondition Modify patient button is triggered.
• Trigger the modify inpatient button browssed
Action(s) • Trigger to Edit profile Providing the fields to
be edited
• Edit the profile ---
• Trigger “Save” Saved successfully
Tested by: F09204002
Results Pass

Test Case # 14

Test Case Title: Testing the Modifying Outpatient mechanism of HMS

Test List Description Expectation


Precondition Modify patient button is triggered.
• Trigger the modify outpatient button browsed
Action(s) • Trigger to Edit profile Providing the fields to
be edited
• Edit the profile ---
• Trigger “Save” Saved successfully
Tested by: F09204002
Results Pass

Test Case # 15

Test Case Title: Testing the Delete patient mechanism of HMS

Test List Description Expectation


Precondition Get onto the main page
Action(s) • Trigger the delete patient button browsed
Tested by: F09204002
Results Pass

Test Case # 16

Test Case Title: Testing the Delete Inpatient mechanism of HMS

Test List Description Expectation


Precondition Delete patient button is triggered
Action(s) • Trigger the delete inpatient button browsed
• Enter patient ID to be deleted found
• Trigger to Delete Confirm to delete
• Triggered confirm to delete Delete the record
• Record deleted Successfully
Tested by: F09204002
Results Pass

Test Case # 17

Test Case Title: Testing the Delete Outpatient mechanism of HMS

Test List Description Expectation


Precondition Delete patient button is triggered
Action(s) • Trigger the delete outpatient button browsed
• Enter patient ID to be deleted found
• Trigger to Delete Confirm to delete
• Triggered confirm to delete Delete the record
• Record deleted Successfully
Tested by: F09204002
Results Pass

Test Case # 18

Test Case Title: Testing the patient billing mechanism of HMS

Test List Description Expectation


Precondition Get onto the main page
Action(s) • Trigger the patient billing button browsed

Tested by: F09204002


Results Pass

Test Case # 19

Test Case Title: Testing the inpatient billing mechanism of HMS

Test List Description Expectation


Precondition Patient billing button is triggered.
Action(s) • Trigger the inpatient billing button browsed
• Patient ID is entered Patient info
• Patient billing details are added. Added
• Bill is generated Successfully

Tested by: F09204002


Results Pass

Test Case # 20

Test Case Title: Testing the outpatient billing mechanism of HMS

Test List Description Expectation


Precondition Patient billing button is triggered.
Action(s) • Trigger the outpatient billing button browsed
• Patient ID is entered Patient info
• Patient billing details are added. Added
• Bill is generated Successfully

Tested by: F09204002


Results Pass
REFERENCES
[1] Drave W.Mercer,Allan Kents,Steven D.Nowicks,D.Mercer,Dan Squier
& W.Choi,Beginning PHP5.Willey Pub Inc,2004.

[2] Roger S.Pressman,Software Engineering.Singapore:McGraw Hill,Int Edition


2010.

[3] Dick Oliver & Michael Morison,Sams Teach Yourself HTML & CSS In 24
Hours.
India:Dorling Kindersley,2006.

[4] Thomas M.conolly,Carolyn E.Begg,Database Systems A Practical Approach 2


Design Implementation & Management.Glasgow:march 2004.

[5] Christerson, Magnus, "From Use Cases to Components", Rose Architect, 5/99.

[6] Wiegers, Karl E. (2003). Software Requirements 2: Practical techniques for


gathering and managing requirements throughout the product development cycle,
2nd ed., Redmond: Microsoft Press. ISBN 0-7356-1879-8.

[7] Andrew Stellman and Jennifer Greene (2005). Applied Software Project
Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8.

[8] Ian Sommerville (2006). Software Engineering, 8th ed.. ISBN 0-321-31379-8.
[9] Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User
Guide. Addison-Wesley, 1999, pp. 219-241.

[11] Cockburn, Alistair, "Structuring Use Cases with Goals", Journal of Object-Oriented
Programming, Sep-Oct, 1997 and Nov-Dec, 1997. Also available on

[12] Cockburn, Alistair, "Basic Use Case Template", Oct .1998. Available on Coleman,
Derek, "A Use Case Template: Draft for discussion", Fusion Newsletter, April 1998.

[13] Constantine, Larry. "What Do Users Want? Engineering usability into software",

[14] Malan, R. and D. Bredemeyer, "Functional Requirements and Use Cases", June
1999.

[15] Malan, R. and D. Bredemeyer, "Use Case Action Guide", (April 2000.

[16] Pols, Andy, "Use Case Rules of Thumb: Guidelines and lessons learned", Fusion

Newsletter, Feb. 1997.

[17] Sehlhorst, Scott, , July 24, 2006. Scott's blog covers requirements-related topics.

[18] UML Specification.. We have referenced V1.3 Alpha R5, March 1999 in this paper.

[19] Karl Wiegers, "Listening to the Customer's Voice,"

[20] J.Castagnetto,Harish Rawat & Sascha Schumann,Professional PHP


Programming.
Wrox Press Ltd,nov 1999.
[21] Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice,
Addison-Wesley, 1998.

[22] Bennett, Douglas, Designing Hard Software: The Essential Tasks, Prentice-
Hall, 1997.

APPENDIX