Hospital Management System: Final Project Report

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

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.
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.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Search Staff
Use Case ID # 4.3
Search Staff
Administrator
Use case Title: Search Staff

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.
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.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.4
Description: This use case shows that the administrator can modify the staff from the HMS.
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.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.5
Description: This use case shows that the administrator can delete the staff from the HMS.
1. Administrator searched for
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.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.6
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.
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.
Extended: None
Uses: None
Authority: Private
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

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.
1. Receptionist clicked on the
add patient button.
Post Conditions: Receptionist now chooses whether the patient is an inpatient or outpatient.
Extended: Inpatient Registration, Output Registration
Uses: None
Authority: Private
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
Use case Id: 4.8
4.9
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
Sequence: Exceptions
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
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
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.
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.
Extended: None
Uses: None
Authority: Private
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
Use case Id: 4.11
Description: By checking the availability, the receptionist will assign a doctor for the
inpatient.
1. Receptionist will assign a If doctor is not available, then the system show a
doctor. prompt that doctor is not available.
another doctor.
Post Conditions: Patient treatment will be carried out by this doctor.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
Use Case Title
# Assign
Nurse
Use Case ID# 4.12
Administrator
<<uses>>
Assign Nurse
<<Extend>> <<Extend>>
Inpatient Case
Papers
Receptionist
Patient
4.13 Inpatient ID and Password
Use case Title: Assign Nurse

Use case Id: 4.12
Description: By checking the availability, the receptionist will assign a Nurse for the
inpatient.
1. Receptionist will assign a If a Nurse is not available, then the system show a
Nurse. prompt that Nurse is not available.
another Nurse.
Post Conditions: Nurse will assist in patient treatment.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
Use Case Title # Inpatient ID
and Password
Use Case ID # 4.13
Administrator
<<Extend>> Inpatient ID and
Password
<<Extend>>
Receptionist
Patient
Use case Title: Inpatient ID and Password

Use case Id: 4.13
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.
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.
Extended: None
Uses: None
Authority: Private
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
Use case Id: 4.14
4.15
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.
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:
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

Use case Id: 4.16
Description: By checking the availability, the receptionist will assign a doctor for the
outpatient.
Pre-condition: Receptionist clicked on the add outpatient button.
1. Receptionist will assign a If doctor is not available, then the system show a
doctor. prompt that doctor is not available.
another doctor.
Post Conditions: Patient treatment will be carried out by this doctor.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.17
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.
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.
Extended: None
Uses: None
Authority: Private
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

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.
1. Receptionist clicks on the
search button.
Post Conditions: Receptionist then chooses whether the patient is an inpatient or outpatient.
Extended: Search Inpatient, Search Outpatient
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.19 Search Inpatient

Inpatient
Use Case ID # 4.19
<<Extend>>
Search Inpatient
Administrator
Search Patient
Receptionist
Use case Title: Search Inpatient

Use case Id: 4.19
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.
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.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.20 Search Outpatient
Outpatient
Use Case ID # 4.20
<<Extend>>
Search Outpatient
Administrator
Search Patient
Receptionist
Use case Title: Search Outpatient

Use case Id: 4.20
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.
search outpatient button.
Post Conditions: Patient information is available to the receptionist.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.21
Description: Depending upon its rights, the receptionist can modify patient record by using its
ID.
1. Receptionist clicks on the
search patient button.
Post Conditions: Now receptionist has to select to modify inpatient or outpatient record.
Extended: Modify Inpatient, Modify Outpatient
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.22 Modify Inpatient
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

Use case Id: 4.22
Description: Depending upon its rights, the receptionist can modify inpatient record by using
its ID.
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.
Extended: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
Outpatient
Use Case ID # 4.23
<<Extend>>
Modify Outpatient
Administrator
Modify Patient <<Uses>>
Check Access
Rights
Receptionist
Use case Title: Modify Outpatient

Use case Id: 4.23
Description: Depending upon its rights, the receptionist can modify outpatient record by
using its ID.
2. Receptionist changes the System confirms of modification
specific record.
3. Receptionist confirms. System saves the changes.
modified info.
Extended: None
Authority: Private
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

Use case Id: 4.24
Description: Depending upon its rights, the receptionist can delete patient record by using its
ID.
delete patient button.
Post Conditions: Now receptionist has to select to delete inpatient or outpatient record.
Extended: Delete Inpatient, Delete Outpatient
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.25 Delete Inpatient

Inpatient
Use Case ID # 4.25
<<Extend>>
Delete Inpatient
Administrator
Delete Patient <<uses>>
Check Access
Rights
Receptionist
Use case Title: Delete Inpatient

Use case Id: 4.25
Description: Depending upon its rights, the receptionist can delete inpatient record by using
its ID.
2. Receptionist deletes the
3. Receptionist confirms. System deletes the record.
Post Conditions: Now that inpatient is no longer part of the system.
Extended: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.26 Delete Outpatient
Outpatient
Use Case ID # 4.26
<<Extend>>
Delete Outpatient
Administrator
<<uses>>
Delete Patient
Check Access
Rights
Receptionist
Use case Title: Delete Outpatient

Use case Id: 4.26
Description: Depending upon its rights, the receptionist can delete outpatient record by
using its ID.
2. Receptionist deletes the
3. Receptionist confirms. System deletes the record.
Post Conditions: Now that outpatient is no longer part of the system.
Extended: None
Authority: Private
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

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.
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.
Extended: Prescribe Medicines, Prescribe Tests
Uses: None
Authority: Private
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

Use case Id: 4.28
Description: This use case shows that the doctor will prescribe medicines to the patient
which will be saved with the patient record.
prescribed medicines
button.
2. Doctor added prescribed
medicines into the patient
record.
Post Conditions: This record will be used throughout patient access.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.29
Description: This use case shows that the doctor will prescribe tests to the patient which will
be saved with the patient record.
prescribed test button.
2. Doctor added prescribed
tests into the patient record.
Post Conditions: This record will be used throughout patient access.
Extended: None
Uses: None
Authority: Private
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

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.
1. Cashier clicked on patient
billing.
Post Conditions: Cashier now chooses whether the patient is an inpatient or outpatient.
Extended: Inpatient Billing, Outpatient Billing
Uses: None
Authority: Private
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

Use case Id: 4.31
Description: This use case shows that the cashier will handle inpatient billing details.
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.
Extended: None
Uses: Doctor Charges, Room Charges, Medical Treatment
Charges
Authority: Private
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

Use case Id: 4.32
Description: This use case shows that the cashier will handle inpatient billing including
doctor charges.
Pre-condition: Cashier clicked on Inpatient billing.
1. Cashier will enter doctor
charges.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.33 Hospital Charges
Use Case Title #Hospital Charges
Use Case ID # 4.33
<<Uses>>
Hospital Charges
Administrator
<<Extend>>
Cashier
Use case Title: Hospital Charges

Use case Id: 4.33
Description: This use case shows that the cashier will handle inpatient billing including room
charges.
1. Cashier will enter room
charges.
Extended: None
Uses: None
Authority: Private
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>>
Cashier
Use case Title: Medical Treatment Charges

Use case Id: 4.34
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.
1. Cashier will enter medical
treatment charges.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.35
Description: This use case shows that the cashier will handle outpatient billing details.
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.
Extended: None
Uses: Doctor Charges
Authority: Private
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

Use case Id: 4.36
Description: This use case shows that the system will handle outpatient billing including
doctor charges.
Pre-condition: Cashier clicked on Outpatient billing.
1. Cashier will enter doctor
charges.
Post Conditions: Outpatient billing process is completed.
Extended: None
Uses: None
Authority: Private
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

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.
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.
Extended: None
Uses: None
Authority: Private
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

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.
search patient button.
Post Conditions: Patient information is available to the lab technician.
Extended: None
Uses: None
Authority: Private
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

Use case Id: 4.39
Description: Depending upon its rights, the lab technician can modify patient record from
laboratory section by using its ID.
1. Lab Technician searches for
2. Lab Technician changes the System confirms of modification
specific record.
3. Lab Technician t confirms. System saves the changes.
modified info.
Extended: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.40 Delete Test
Use Case Title # Delete Test
Use Case ID # 4.40

Rights
Administrator
Delete Test
Lab Technician
Use case Title: Delete Test

Use case Id: 4.40
Description: Depending upon its rights, the lab technician can delete patient record from
laboratory section by using its ID.
1. Lab Technician searches for
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.
Extended: None
Authority: Private
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

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.
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.
Extended: None
Uses: None
Authority: Private
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

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.
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.
Extended: None
Uses: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.43Modify Donor
Use Case Title # Modify Donor
Use Case ID # 4.43

Rights
Administrator
Modify Donor
Blood Bank
Assistant
Use case Title: Modify Donor

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.
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.
modified info.
Extended: None
Authority: Private
Author: f090204002 (bc060200052, mc080407658)
4.44 Delete Donor
Use Case Title # Delete Donor
Use Case ID # 4.44

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

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.
searches for the specific
record.
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.
Extended: None
Authority: Private
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>>
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>>
View or Modify Patient:
Admin or Receptionist
Home Page Profile HMS Profile Service
Redirect()
View()
getProfile()
Edit()
doEditProfile()
providedData()
Data()
setAccessPermission()
Update()
Search Patient:
Home Page Search Search Results HMS Search Service
Redirect()
Redirect()
String()
Search()
Alt
View()
if found
else
Not
found
Delete Patient:
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
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
Login () 1 department Name : 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
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
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

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
Results Pass
Test Case # 03
Test Case Title: Testing the Search staff mechanism of HMS

Precondition Get onto the Main personal page
Action(s) • Enter ID to search ---
• Trigger Search ID found
• Show search results Successfully
Results Pass
Test Case # 04
Test Case Title: Testing the Modifying staff mechanism of HMS

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
Results Pass
Test Case # 05
Test Case Title: Testing the Delete staff mechanism of HMS

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
Results Pass
Test Case # 06
Test Case Title: Testing the add patient mechanism of HMS

Precondition User currently is not a member
Action(s) • User browse to the system Browsed
• Trigger the addpatient button Redirecting to
registration page
Results Pass
Test Case # 07
Test Case Title: Testing the add Inpatient mechanism of HMS

Precondition Addpatient button is triggered.
Action(s) • Trigger the addInpatient button Redirecting to
registration page
redirecting to main page
Results Pass
Test Case # 08
Test Case Title: Testing the add Outpatient mechanism of HMS

Precondition Addpatient button is triggered.
Action(s) • Trigger the addOutpatient button Redirecting to
registration page
redirecting to main page
Results Pass
Test Case # 09
Test Case Title: Testing the Search patient mechanism of HMS

Precondition Get onto the Main personal page
Action(s) • Search patient button is triggered browsed
Results Pass
Test Case # 10
Test Case Title: Testing the Search Inpatient mechanism of HMS

Precondition Search patient is triggered
Action(s) • Trigger the search inpateint button browsed
• Enter ID to search ---
Results Pass
Test Case # 11
Test Case Title: Testing the Search Outpatient mechanism of HMS

Precondition Search patient is triggered
Action(s) • Trigger the search outpateint button browsed
• Enter ID to search ---
Results Pass
Test Case # 12
Test Case Title: Testing the Modifying patient mechanism of HMS

Precondition Get onto the profile page
Action(s) • Trigger the modify patient button browssed
Results Pass
Test Case # 13
Test Case Title: Testing the Modifying Inpatient mechanism of HMS

Precondition Modify patient button is triggered.
• Trigger the modify inpatient button browssed
Action(s) • Trigger to Edit profile Providing the fields to
be edited
Results Pass
Test Case # 14
Test Case Title: Testing the Modifying Outpatient mechanism of HMS

Precondition Modify patient button is triggered.
• Trigger the modify outpatient button browsed
Action(s) • Trigger to Edit profile Providing the fields to
be edited
Results Pass
Test Case # 15
Test Case Title: Testing the Delete patient mechanism of HMS

Precondition Get onto the main page
Action(s) • Trigger the delete patient button browsed
Results Pass
Test Case # 16
Test Case Title: Testing the Delete Inpatient mechanism of HMS

Precondition Delete patient button is triggered
Action(s) • Trigger the delete inpatient button browsed
• Enter patient ID to be deleted found
Results Pass
Test Case # 17
Test Case Title: Testing the Delete Outpatient mechanism of HMS

Precondition Delete patient button is triggered
Action(s) • Trigger the delete outpatient button browsed
• Enter patient ID to be deleted found
Results Pass
Test Case # 18
Test Case Title: Testing the patient billing mechanism of HMS

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

Results Pass
Test Case # 19
Test Case Title: Testing the inpatient billing mechanism of HMS

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

Results Pass
Test Case # 20
Test Case Title: Testing the outpatient billing mechanism of HMS

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

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

Hospital Management System: Final Project Report

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Hospital Management System: Final Project Report

Загружено:

Авторское право:

Доступные форматы

Final Project Report

Hospital Management System

Sarfraz Ahmad Awan

Muhammad Usman Rashid BC060200052

Software Projects & Research Section,

Supervisor / Internal Examiner

Sarfraz Ahmad Awan

External Examiner/Subject Specialist

Praise be to Allah, Lord of Creation,

You alone we worship, and to You alone we

The path of those who You have favored,

Not of those who have incurred Your wrath,

HAZRAT MOHAMMAD S.A.W.W

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

All of them making us who we are today.

2.5.1 Project Schedule

4.3 Development Tools

1.2 PROJECT OBJECTIVES

Our main objectives are:

1.5 USE CASES AND USAGE SCENARIOS

Modify Staff <<uses>> Room Reservation

<<extend >> Add Inpatient

<<extend >> <<uses>>

<<extend >> Search Inpatient

<<extend >> Modify Inpatient Nurs

<<extend >> Delete Inpatient

<<extend >> Organ Donation

<<extend >>Assign Ambulance

About Forget Passwod

Modify Staff <<uses>> Room Reservation

<<extend >> Add Inpatient

<<extend >> <<uses>>

<<extend >> Search Inpatient

<<extend >> Modify Inpatient Nurs

<<extend >> Delete Inpatient

<<extend >> Organ Donation

<<extend >>Assign Ambulance

About Forget Passwod

Use Case Title # Login

Patient Doctor Nurse

Use Case Title # Add Staff

Use case Title: Add Staff

Use case Title: Search Staff

Use case Title: Modify Staff

Use case Title: Delete Staff

Set Access Rights

Use case Title: Set Access Rights

Use case Title: Add Patient

<<extends>> Inpatient Case

Use case Title: Inpatient

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

4.11 Assign Doctor

Adm inistra tor

<<Exte nd> > <<Extend>>

4.12 Assign Nurse

4.13 Inpatient ID and Password

Use case Title: Assign Nurse

Use case Title: Inpatient ID and Password

<<Extend>> Outpatient Case

Use case Title: Outpatient

<<Extend>> <<E xtend> >

Use case Title: Referred Doctor

Use case Title: Outpatient ID and Password