Republic Of Yemen

Graduation Project
Sana’a University
Computer Science And IT Collage
2015
Information Systems Department

Project Title

HOSPITAL MANAGEMENT
SYSTEM
For Zayed Ben Sultan Hospital for Maternity
(ZHM)

TEAM MEMBERS:
1- Rasheed Abdullghani Almohlil 12-111
2- Ibrahim Ali Abdullah Atef 12-076
3- Hani Abdullateef Ghulais 12-161
4- Ziad Mohammed Algadabi 12-118
5- Abdullah Ahmed Alsabal 12-130
6- Saddam Hussin Alqalah 12-199
7- Aymam Ahmmed Aleby 12-099
8- Ryad Rzaz Albakry 12-116

SUPERVISOR:
Dr. Adnan Almotokel

COSUPERVISOR:
Eng. Neema Abdullaziz

DATE: 17/10/2015
 QUOTATION

“Information technology and business are becoming inextricably

interwoven. I don't think anybody can talk meaningfully about one
without the talking about the other.”
Bill Gates: Chairman of Microsoft Technology Company.

“Electronic medical records are, in a lot of ways, I think the aspect of

technology that is going to revolutionize the way we deliver care.
And it's not just that we will be able to collect information, it's that
everyone involved in the healthcare enterprise will be able to use that
information more effectively.”
Risa Lavizzo-Mourey: A Famous American Businesswoman.

i
 DEDICATION
With all words of thanks and appreciation we wish to dedicate this entire
project report to:

Our Beloved Mothers and Fathers

For their tireless support they accorded to us
Ever since we were children till today.

Our Dear Brothers

For their continuous encourage and patience.

Our Honorable Teachers

For knowledge they give us and effort they spend
To teach us.

Our Friends
For their help and experience they had given
And shared with us.

And others people who help and support us to

Complete this project.

ii
ACKNOWLEDGMENT

We want to
give our thanks and
appreciation to all people who help
and support us to complete this project.
Thanks for:
Dr. Adnan Al-Mutawakil.

Eng. Neema Abdul-Aziz.

And special thanks to Eng. Abdullah Atef IT
Department Manager of ZHM who
gives us all information we
need and all employees
of the hospital.

iii
 Table of Contents

1. Introduction 1
1.1 Background 1
1.2 Problem statement 2
1.3 Objectives 2
1.4 Acceptance criteria 3
1.4.1 The patient information system 3
1.4.2 The web site 3
1.5 System definition 3
1.6 Purpose 4
1.7 Goal 4
1.8 User characteristics 4
1.9 Limitations 5
1.10 Assumptions and dependencies 6
1.11 Scope 6
1.12 Life cycle model 7
1.13 Related works 8
1.14 Project plan 8
1.15 Organization chart and responsibilities 9
2. Current system 11
2.1 Current system. 11
2.2 ACRONYMS AND ABBREVIATIONS. 11
2.3 Project Feasibility study 11
2.3.1 Financial feasibility 11
2.3.2 Operational feasibility 13
2.3.3 Technical feasibility 15
2.3.4 Schedule feasibility 15
2.3.5 Social and Ethical Considerations (Cultural) 16
2.3.6 Legal feasibility 16
2.4 Fact finding tools 17
2.4.3 Sampling of existing documentations, forms, and database or file 17
2.4.4 Research and site visits 17
3. Proposed system 19
3.1 Overview 19
3.2 User requirements 19

iv
 3.3 Hardware requirements to operate the system 19
3.3.1 Server with the following feature 19
3.3.2 Client for every user with the following features 19
3.4 Functional requirements: 20
3.5 Nonfunctional requirements: 24
3.6 System requirements structuring and modeling 26
3.6.4 DFD 26
3.1.2 Entity Relationship Diagram (ERD) 59
3.1.3 Mapping 61
4. Project interfaces 65
4.1 Overview 65
4.2 Database building 66
4.2.1 Database diagram 66
4.2.2 Database Tables 67
4.3 Interfaces building and system manual 73
4.3.1 Administration module interfaces. 73
4.3.2 Reception module interfaces 87
4.3.3 Cashier module interfaces 89
4.3.4 Doctor module interfaces 91
4.3.5 Ray module interfaces 94
4.3.6 Lap module interfaces 95
4.3.7 Emergency module interfaces 97
4.3.8 Entry & Exit module interfaces 99
4.3.9 Operation module interfaces 101
4.4 integration and system testing 103
4.4.1 System integrity testing 103
4.4.2 System testing 104
4.5 Results of the project 104
5. Recommendations and Suggestions 106
5.1 Overview 106
5.2 Suggestions 106
5.3 Recommendations 106
References 107
Accessories 108
Existing data forms of the hospital 108

v
 Table of tables
Table Table definition Page number
Table 1.1 User characteristics 4
Table 1.2 User characteristics 5
Table 2.1 Financial feasibility 12
Table 2.2 Schedule feasibility 16
Table 3.1 discount process decision table 58
Table 4.1 person table 67
Table 4.2 Assessment table 67
Table 4.3 Bed table 67
Table 4.4 Branch table 67
Table 4.5 Clinic Record table 68
Table 4.6 Bill table 68
Table 4.7 Emergency_Contact table 68
Table 4.8 User table 68
Table 4.9 Appointment table 68
Table 4.10 Department table 69
Table 4.11 Doctor table 69
Table 4.12 Doctor Schedule table 69
Table 4.13 Emergency_Patient table 69
Table 4.14 In Patient table 70
Table 4.15 Lab Record table 70
Table 4.16 Nurse table 70
Table 4.17 Operation Record table 70
Table 4.18 Order table 71
Table 4.19 Order_Service table 71
Table 4.20 Out_Patient table 71
Table 4.21 Patient table 71
Table 4.22 Patient_Charge table 71
Table 4.23 Patient_Record table 72
Table 4.24 Prescription table 72
Table 4.25 Ray Record table 72
Table 4.26 Room table 72
Table 4.27 Service table 72
Table 4.28 Technical table 73

vi
 Table of figures
Figure Explanation Page
number number
Figure 1.1 Shows life cycle model 7
Figure 1.2 Shows project plan 8
Figure 1.3 Shows organization chart and responsibilities 9
Figure 3.1 Shows context level 27
Figure 3.2 Shows level Zero 28
Figure 3.3 Shows process one of the DFD in level one 29
Figure 3.4 Shows process two of the DFD in level one 29
Figure 3.5 Shows process three of the DFD in level one 30
Figure 3.6 Shows process four of the DFD in level one 30
Figure 3.7 Shows process five of the DFD in level one 31
Figure 3.8 Shows process 1.2 of the DFD in level two 31
Figure 3.9 Shows process 1.3 of the DFD in level two 32
Figure 3.10 Shows process 1.4 of the DFD in level two 32
Figure 3.11 Shows process 1.5 of the DFD in level two 33
Figure 3.12 Shows process 2.1 of the DFD in level two 33
Figure 3.13 Shows process 2.3 of the DFD in level two 34
Figure 3.14 Shows process 3.3 of the DFD in level two 34
Figure 3.15 Shows process 5.2 of the DFD in level two 35
Figure 3.16 Shows context level of web site DFD 35
Figure 3.17 Shows level Zero of web site DFD 35
Figure 3.18 Shows patient information data flow description 36
Figure 3.19 Shows payment information data flow description 36
Figure 3.20 Shows report information data flow description 37
Figure 3.21 Shows service request data flow description 37

vii
 Figure Explanation Page
number number
Figure 3.22 Shows appointment information data flow description 38
Figure 3.23 Shows patient record data flow description 38
Figure 3.24 Shows update appointment information data flow 39
description
Figure 3.25 Shows update patient record data flow description 39
Figure 3.26 Shows user information data flow description 40
Figure 3.27 Shows patient record data flow description 40
Figure 3.28 Shows data structure 41
Figure 3.29 Shows branch data store 42
Figure 3.30 Shows department data store 43
Figure 3.31 Shows staff data store 43
Figure 3.32 Shows service data store 44
Figure 3.33 Shows appointment data store 44
Figure 3.34 Shows patient data store 45
Figure 3.35 Shows patient data store 45
Figure 3.36 Shows account id data element 46
Figure 3.37 Shows patient id data element 46
Figure 3.38 Shows salary data element 47
Figure 3.39 Shows username data element 47
Figure 3.40 Shows sex data element 48
Figure 3.41 Shows birth date data element 48
Figure 3.42 Shows phone number element description form 49
Figure 3.43 Shows department name data element 49
Figure 3.44 Shows patient name data element 50
Figure 3.45 Shows address data element 50
Figure 3.46 Shows questionnaire data flow dictionary 51

viii
 Figure Explanation Page
number number
Figure 3.47 Shows question and answer data flow dictionary 51
Figure 3.48 Shows valid user data flow dictionary 52
Figure 3.49 Shows web site data structure 52
Figure 3.50 Shows user store description from 53
Figure 3.51 Shows service data store description from 53
Figure 3.52 Shows suggestion data store description from 54
Figure 3.53 Shows question data store description form 54
Figure 3.54 Shows questionnaire store description from 55
Figure 3.55 Shows suggestion heading element description form 56
Figure 3.56 Shows suggestion text element description form 56
Figure 3.57 Shows visitor name element description form 57
Figure 3.58 Shows service description element description form 57
Figure 3.59 Shows service name element description form 58
Figure 3.60 Shows ERD of patient information system 59
Figure 3.61 Shows Web site of hospital ERD 60
Figure 3.62 Shows mapping of the ERD 61
Figure 3.63 Shows mapping of the ERD (cont). 62
Figure 3.64 Shows mapping of the ERD. 63
Figure 4.1 Shows database diagram 66
Figure 4.2 Shows how the log in interface with password as a 73
required field.
Figure 4.3 Shows how the log in interface with password after it has 74
been entered.
Figure 4.4 shows the department management interface 74
Figure 4.5 shows the adding new department interface 75
Figure 4.6 shows update existing department interface 75
Figure 4.7 shows adding new partial department interface 76
Figure 4.8 shows updating existing partial department interface 76

ix
Figure Explanation Page
number number
Figure 4.9 shows service management interface 77
Figure 4.10 shows adding new service interface 77
Figure 4.11 shows updating existing service interface 78
Figure 4.12 shows room and bedroom management interface 78
Figure 4.13 shows adding new room interface 79
Figure 4.14 shows updating existing room interface 79
Figure 4.15 shows adding new bedroom interface 80
Figure 4.16 shows updating existing bedroom interface 80
Figure 4.17 shows employees management interface 81
Figure 4.18 shows adding new employee interface (personal information) 81
Figure 4.19 shows adding new employee interface 82
(working time information)
Figure 4.20 Shows adding new employee interface (working time 82
information but after adding working time that appears in the
right of the interface)
Figure 4.21 shows adding new employee interface (privilege information) 83
Figure 4.22 shows adding new employee interface (the new employee after 83
he has been added to the system and appears in the green row
of the table)
Figure 4.23 shows users' management interface (from this interface one use 84
can be enabled or disabled or all can be enabled or disabled
except admin)
Figure 4.24 shows updating user's privilege interface (from here the admin 84
can define which module can be entered by the user)
Figure 4.25 shows report management interface 85
Figure 4.26 shows report appears in the left of the interface 85
Figure 4.27 shows the user updating his user name, password and photo by 86
clicking on the account setting in the interface
Figure 4.28 shows the message that appears when user chooses log out or 86
click on x button
Figure 4.29 shows receipt new patient interface 87
Figure 4.30 shows adding patient's personal information interface 87

x
Figure Explanation Page
number number
Figure 4.31 shows adding patient's visit information, department name and 88
type of order to see the doctor
Figure 4.32 shows query about patients or doctors interface 88
Figure 4.33 shows reception's reports interface 89
figure 4.34 shows get a price of the service interface 89
Figure 4.35 shows adding or updating bills 90
Figure 4.36 shows report interface of cashier department 90
Figure 4.37 shows all entered appointenmts from reception department 91
appears in the appointment interface
Figure 4.38 shows how to add patient's information in his visit and the 91
required procedures
Figure 4.39 shows how to add patient's information in his visit and the 92
required lap exams
Figure 4.40 shows how to add patient's information in his visit and the 92
required ray exams
Figure 4.41 shows how to add patient's information in his visit and if he 93
needs to be transferred
Figure 4.41 shows the reports interface press view to see the report in the 93
left of the interface
Figure 4.43 shows list of the patients who need to take any ray exam 94
Figure 4.44 shows how to add rays' results 94
Figure 4.45 shows the reports' interface press view to see the report in the 95
left of the interface
Figure 4.46 shows list of the patients who need to take any lap exam 95
Figure 4.47 shows how to add lap exams' results 96
Figure 4.48 shows the reports' interface press view to see the report in the 96
left of the interface
Figure 4.49 shows the existing patients in the emergency department and to 97
add with new emergency patients (personal information tab)
Figure 4.50 shows the existing patients in the emergency department and to 97
add with new emergency patients (the responsible of patient
information tab)

xi
 Figure Explanation Page
number number
Figure 4.51 shows the existing patients in the emergency department with 98
details of every patients
Figure 4.52 shows the reports' interface of emergency department, press 98
view to see the report in the left of the interface
Figure 4.53 shows the needed information of the new inpatient's 99
information
Figure 4.54 shows the existing patients in the entry exit department with 99
details of every patient
Figure 4.55 shows the needed information of patient to be exit or 100
transferred
Figure 4.56 shows the needed information of patient to be exit or 100
transferred
Figure 4.57 shows the reports' interface of entry exit department, press 101
view to see the report in the left of the interface
Figure 4.58 shows list of patients who requested to be scheduled in the 101
operations department with the required information to be
entered
Figure 4.59 shows list of patients who has been scheduled in the operations 102
department and operation result to be entered
Figure 4.60 shows the reports' interface operation department, press view 102
to see the report in the left of the interface
Figure 4.61 shows the process of integration among modules 103
and testing
Figure 7.1 Shows biochemistry record 108
Figure 7.2 Shows C.B.C record 109
Figure 7.3 Shows Harmonies record 110
Figure 7.4 Shows microbiology record 111
Figure 7.5 Shows sleeping record 112
Figure 7.6 Shows emergency record 113
Figure 7.7 Shows serology record 114

xii
 Project Proposal Outline
Zayed ben sultan hospital for motherhood and childhood is one of the most important healthy

organization in our country whose primary goal is to offer healthy and medical services

efficiently for different community parts.

As the hospital information system is a traditional (paper based) system, the hospital has

faced difficulties in providing services for patients as they expect.

These difficulties are related to the poor management of recording, storing and retrieving of

patients' information.

As we are pre-graduated students from information system (IS) department in computer

science and information technology at Sana'a University we decide to take the opportunity to

build an electronic system that is able to manage the processes of recording, storing,

updating and retrieving of patient medical record in an efficient electronic manner.

The proposed system is also able to produce different types of reports that provide timely

information for the general management to help in making effective decisions in order to

enhance hospital services to the community. The proposed system includes - as an

independent part - a web site that provides information of the hospital and its services for the

public as well as receives and answers their suggestions and questions in order to increase

patient's royalty and enhance services.

xiii
This page is intentionally left blank

xiv
Chapter One:
Introduction
1. Introduction
1.1 Background
As technology advances, nowadays business firms and other nonprofit organizations as well

as individuals are increasingly relied on information systems and web technology. For instance,

corporations use information systems and web technology to carry out and manage their

operations, to interact with their customers and suppliers, and to make a competitive advantage in

the marketplace.

Individuals generally rely on web-based information systems for conducting much of their

personal lives activities: for socializing, studying, shopping, banking, and getting healthy

consultation, entertainment and other everyday activities.

As information systems have enabled more diverse human activities, they have used a

profound influence over society. These systems have quickened the pace of daily activities,

affected the structure and mix of organizations, changed the type of products bought, and

influenced the nature of work.

Zayed Ben Sultan Hospital for Motherhood and Childhood (ZHMC) is one of the most

important healthy organization in our country that offers many of healthy and medical services for

different parts of the community. Like most of organizations, information systems play a vital role

in the ZHMC's operations. Unfortunately, the current information system of ZHMC is a traditional

(paper based) system which is causing many problems in carrying out the hospital's daily

operations effectively and providing efficient services for its patients.

ZHMC also doesn't have a web site that provides a clear definition about what medical

services that the hospital provides to its customers.

1
1.2 Problem statement
In order to provide excellent patient care with a minimal cost, Zayed Ben Sultan Hospital

needs an information system that is fast, reliable, secure and easy to use. In addition, the hospital

should use a system that is easy to retrieve all patients' records in an efficient way.

The second thing the hospital should have a web site that has all the information about it like

where it exists, what services it can provide and what new offers it gives.

Right now, all of the hospital transactions are managed manually which made it hard to use

and wastes time, effort and money. Also the hospital doesn't have a web site which make it

unknown to a lot of people. Other hospitals use electronic information system and web sites which

can be considered as a competitive advantage in the market place. If the hospital management

continues in this manner, it will waste its time and money in doing simple things and without good

reports that electronic system provides to help improving hospital efficiency.

1.3 Objectives
• Increasing the efficiency of the hospital through easily communication among departments
by using interconnected system.
• Coordinating and regulating the patients' information through using effective database
system.
• Making a new channel of communication with customers through using an interactive web
site.
• Improving the response time to the demands of patient care because it automates the
process of collecting and retrieving patient information.

2
1.4 Acceptance criteria
1.4.1 The patient information system:
• System can add new patient or update patient record without problems.

• System can add tests' result to patient record without problems.

• System can add ray exams to patient record without problems.

• System can produce reports about patients, ray exams, tests and medicines without

problems.

• System has a good interface design.

• System can add new employees and users with no problems.

1.4.2 The web site:

• Web site has a good interface.

• Web site easy to use.

1.5 System definition

The system that we intend to build is a desktop application can make all the services of

patients easily maintained.

The system is also capable of making communication among departments and eliminate

redundancy of patient's information.

The system also can produce verity kinds of reports, for example, how many patients the

hospital serves and how many tests of the specific kind make each day with minimal average of

effort.

This system enhance the ability of hospital to coordinate care by providing a patient’s health

information and visit history at the place and time that it is needed.

The web site has many features can be produced like give the community an easy way to

locate hospital information, services and their price, and new advertisements.

3
 The web site is also has the ability to receive customers suggestions and replay their

questions.

1.6 Purpose:
• Increasing the efficiency of the services that the hospital provides.

1.7 Goal:
• The first goal of our project is to build an electronic system that is able to effectively

maintain all patients' information.

• The second goal is to make website for the hospital showing information

about the available services that the hospital provide.

1.8 User characteristics

The users that the new system serves are divided as the following table:
Table 1.1 User characteristics
User type Age Qualifications Privilege
1. Administrator 25 - more IT or IS • Manage departments of hospital
specialist • Manage doctor account
• Manage laboratory account
• Manage accountant account
• Monitor hospital events
• watch transaction reports of
patient payment
• Bed, ward, cabin status
• watch operation report
• watch birth report
• watch death report
• Bed allotment status and admit
history
• Manage noticeboard for all
users of hospital
• Manage system settings
• Watch system log of user
interactions
• Create backup and restore
anytime
• Manage own profile

4
 Table 1.2 User characteristics

User type Age Qualifications Privilege

2. Doctor 27 - more Medicine • Creating prescription for
patient
specialist
• Date and time based
prescription
• Appointment scheduling and
calendar view for
appointment
• Provide medication for
patients
• View diagnostic report of
patients.
• Creates , discharge bed
allotment for patient
• Issue for operation of
patients and creates
operation report

3. Accountant 21 - more Diploma in • Creating new patient record

or
accountant at • Creating invoice for payment
receptionist • Ordering invoice to patient
least. • Taking cash payment

4. Technical staff ( 21 - more Diploma in • Watching prescription list

Laboratory and
laboratory at • Making diagnostic report
radiologist ) • Previewing of diagnostic
least. report files

1.9 Limitations
Generally there are no major limitations that prevent us from developing the system, but we face

minimal constrains such as:

• Problems with the electricity.

• The hospital gets all its resources from the government so we may not have all the

hardware required to finish all parts of our project.

5
1.10 Assumptions and dependencies
• There is no changes in business rules during the project.

• Prices of raw materials don't change during the project life cycle.

• Additional resources will be available from the hospital as required.

1.11 Scope:
This system is designed for Zayed Bin Sultan hospital for maternity (ZHMC). The hospital is located

in Zayed ben Sultanst which is a branch of Almatarst Sana'a.

System will serve the following departments in the hospital:

• Reception and appointments department.

• Clinical departments

• Diagnostic categories Administration

• Entry and exit department.

• Operation department.

• Emergency department.

• Ray and lap departments.

6
1.12 Life cycle model:
Because the hospital has a specific function and with rarely changes in business rules, we

chose waterfall methodology.

Figure 1.1 Life cycle model

Waterfall methodology features:

• One phase has to be complete before moving onto the next phase.

• This model is only appropriate when the requirements are well-understood and changes

will be fairly limited during the design process.

• The waterfall model is mostly used for large systems engineering projects where a

system is developed at several sites.

• Every stage of project gets its needed documentation satisfactorily.

• Project can be managed much easier than the other methodologies.

7
1.13 Related works:
• 48 Modern Hospital

• Quenta web based hospital management system.

• Bayanno Hospital Management System

1.14 Project plan:

Figure 1.2 project plan.

8
1.15 Organization chart and responsibilities

Figure 1.3 Organization chart and responsibilities

9
 Chapter two:
Current System
(Theoretical side)

10
2. Current system.
2.1 Current system.
Right now all services in the hospital are accomplished using a traditional system, thus

patient's information is registered in paper.

Various reports of the provided services and daily revenue of hospital are made manually

that waste time, increase costs and may produce errors.

2.2 ACRONYMS AND ABBREVIATIONS.

2.2.1 PC: personal computer or desk top computer.
2.2.2 Server: central computer used to save data that can be accessed by network.
2.2.3 HW (Hardware): the tangible components of computer like keyboard.
2.2.4 SW (Software): the programs that are added to hardware to be operated.
2.2.5 Network: interconnected group of computers.
2.2.6 DFD (Data flow diagram): diagram used to depict the system processes in traditional
systems.
2.2.7 ERD (Entity Relationship Diagram): diagram used to depict the database entities and
the relationships between them.
2.2.8 Gantt chart: chart used to depict the timelines of the system stages.

2.3 Project Feasibility study

2.3.1 Financial feasibility
2.3.1.1 Patient information system:
Feasibility assessment is to determine potential costs and positive financial benefits to

the hospital that the proposed system will provide.

a) Tangible benefits
• Using less paper.

• Get real information whenever and wherever it is needed.

• Increase profits.

b) Nontangible benefits
• A few mistakes making.

• Decrease time of task making.

• Facilitates strategic planning.

• Help in making decision.

11
 Table 2.1 Financial feasibility
Cost
Requirements Manual System
Build Buy Rent
HR:
- Manager 5*500$*12m 5*500$*12m 5*500$*12m 7*500$*12m
- Employee 150*300$*12m 100*300$*12m 100*300$*12m 105*300$*12m
- Analyst 0 3*700$*8m 1*700$*4m 0
- Designer 0 3*700$*8m 1*700$*4m 0
- Developer 0 5*700$*8m 3*700$*4m 0
- Team leader 0 1*700$*8m 1*700$*4m 0
- Guard 7*250$*12m 7*250$*12m 7*250$*12m 7*250$*12m
HW:
- PC 0 15*600$ 15*600$ 15*600$
- Server 0 2*2500$ 2*2500$ 1*2500$
- Wires 0 30*200$ 30*200$ 40*200$
- Switch 0 2*250$ 2*250$ 2*250$
- Modem 0 5*150$ 5*150$ 5*150$
- Router 0 2*350$ 2*350$ 1*350$
SW:
- Windows 8 0 1*120$ 1*120$ 1*120$
- Windows server 0 1*120$ 1*120$ 1*120$
2008
- SQL server 2008 0 1*120$ 0 0
- Visual studio.net 0 1*150$ 0 0
2010
- Antivirus and 0 1*150$ 1*150$ 1*150$
internet protection
- Office 2013 and 1*120$ 1*120$ 1*120$ 1*120$
Project
- E-draw Max 0 1*120$ 1*120$ 1*120$
- Adobe Photoshop 1*150$ 1*150$ 1*150$ 1*150$
- Adobe Acrobat 1*120$ 1*120$ 1*120$ 1*120$
- Server Hosting and 300$ 300$ 300$ 300$
distribution
- System additional 1*120$ 1*120$ 3*250$ 7*250$
helping programs
Other sets:
- Printer 0 5*400$ 5*400$ 5*400$
- Printer invoices and 10*400$ 10*400$ 10*400$ 10*400$
receipts
- Scanner 0 5*200$ 5*200$ 5*200$
Stationary:
- Printer paper drafts 3*5*3.5$ 1*5*3.5$ 3*5*3.5$ 3*5*3.5$
- Printer invoices and 13$*60*12 13$*60*12 13$*60*12 13$*60*12
receipts paper
- Pens 100*12*0.2$ 20*12*0.2$ 20*12*0.2$ 20*12*0.2$
- Folders 5*100*2.5$ 10*1$ 50*2.5$ 100*2.5$
- Disclosures 100*1$*12 0 50*1$*12 70*1$*12
Others:
- Maintenance 0 1000$ 2000$ 0
- Renewing 0 0 2000$ 0
- Renting 15000$ 0 0 6000$
Total 609412.5$ 519055.5$ 472885.5$ 488600.5$

12
2.3.2 Operational feasibility
Depending on the discussion of the administration of the hospital, we found that they

have strong desire to build a new system and they are ready to provide all the needed

information to build this system. However, the crew of hospital finds it difficult to keep working

with the old system and they start demanding for a new system that make their work easer and

save their precious time.

The work environment will be changed dramatically from using papers to use computers

and all the needed training courses for users will be given to them as we are promised by the

general management.

All the characteristics of the system in the operational environment can be described as

the following:

2.3.2.1 Performance:
2.3.2.1.1 Throughput: system should provide 1 thousand processes at one second.

2.3.2.1.2 Response time: time between one process to another is 0.03 microsecond

2.3.2.2 Information:
2.3.2.2.1 Input: system must collect necessary information to accomplish its function and

should handle incorrect input.

2.3.2.2.2 Stored data: system should store useful data and eliminate redundancy or conflicts

in data

2.3.2.2.3 Output: system should retrieve required information easily and timely.

2.3.2.3 Economic:
2.3.2.3.1 Cost: the cost of the project can be seen in the economic feasibility.

2.3.2.3.2 Profit: system isn't for commercial use, so the profits are limited.

13
2.3.2.4 Control/ security:
2.3.2.4.1 Too low: may effect on patients privacy because the system contain confidential

information about patient, so it's important to manage access to these information

and can corrupt the system functions.

2.3.2.4.2 Too high: that reduce system performance and cause rejection of the system

2.3.2.5 Efficiency:
2.3.2.5.1 Waste time: system should not re-collect data for efficient use of time.

2.3.2.5.2 Waste materials: in case there aren't electricity or disaster, so we assumes there is no

waste materials.

2.3.2.5.3 Effort: effort will be double because we have other subjects to care, but for use we

ensure the system will be in best state.

2.3.2.5.4 Required materials: mentioned above in economic feasibility.

2.3.2.6 Services:
2.3.2.6.1 Inaccurate, inconsistent or unreliable result: there will not be any of these problem

in the system.

2.3.2.6.2 Easy to learn/to use: the system must be easy to use and learn by users.

2.3.2.6.3 Inflexible: system should process unexpected situations.

2.3.2.6.4 Incompatible: system should be compatible with other programs to perform

organization business.

Decision: the system is suitable from operational side.

14
2.3.3 Technical feasibility
Depending on the discussion with the manager of information system department in the

hospital, most of the needed technologies of the intended system are exist like PCs and internal

network except the server but it can be obtained in the implementation of the system as we

are promised by the management.

The hospital has all the needed experience to use that technologies because the hospital

has a dedicated information system department with all experts that the system needs.

Decision: the system is suitable from technical side.

2.3.4 Schedule feasibility

The system will be developed during six months which is suitable for organization and us.

The learning of the system doesn't take more than one week to learn the basic functions of

the system because the system has a graphical user interface system (GUI).

The timeframes of delivering the system is not mandatory, so all the functions will be met

the purpose without errors.

The following table 2.2 can provide a clear view of the project timeframes.

15
 Table 2.2 Schedule feasibility
Initiation phase: 14 days
Task Period
Selecting 4 days (12/10/2014) – (16/10/2014)
Planning 10 days (17/10/2014) – (27/10/2014)
Analysis phase: 50 days
Task Period
Requirement gathering 30 days (28/10/2014) – (28/11/2014)
Requirement analysis and specification 20 days (29/11/2014) – (19/12/2014)
Design phase: 50 days
Task Period
DFD diagraming 30 days (20/12/2014) – (20/01/2015)
ERD and EERD diagraming 15 days (21/01/2015) – (05/02/2015)
Prototype design and test 5 days (06/02/2015) – (11/02/2015)
Implementation phase: 107 days
Task Period
Coding 30 days (12/02/2015) – (11/03/2015)
Testing 30 days (12/03/2015) – (11/04/2015)
Installation 10 days (12/04/2015) – (22/04/2015)
Documentation 10 days (23/04/2015) – (02/05/2015)
Training 7 days (03/05/2015) – (10/05/2015)
Support 20 days (11/05/2015) – (29/05/2015)
Decision: the system is suitable from schedule feasibility.

2.3.5 Social and Ethical Considerations (Cultural)

The system doesn't conflict with the community the system serves.

Patient's information will not be used for commercial purposes or aspects that affect the patient.

Decision: the system is suitable from social feasibility.

2.3.6 Legal feasibility

Because there is no legal framework that controls the producing of software products in

our country, our system will not conflict with any legal framework exists or is going to be built

in the future.

16
 There are some legal consideration:

1- Copyrights: we should provide a licensed copy of the system to the Zaid Ben Sultan

hospital, and source code is kept by developing team.

2- Union contracts: as attached in the appendix. It's attached as an example for your

future projects in Market, not as a real contract for our case study.

3- Financial reports: should be confidential and provides only for financial manager and

team's manager

4- Antitrust laws: when there is no trust between the organization and developing team

then the organization provides all material needed to accomplish the project and

deliver the fee at starting of the project and the other deliver at ending the project.

Decision: the system is suitable from legal feasibility.

2.4 Fact finding tools

2.4.3 Sampling of existing documentations, forms, and database or file.
2.4.3.1 Existing documentations.
• BIOCHMESTRY records.

• Sleeping records.

And other documents will be listed in the attachments.

2.4.4 Research and site visits

2.4.4.1 Research.
• Defining Assumptions and dependencies.
Book name: Project management life cycle.

• Waterfall model advantages

Book name: Software engineering.

2.4.4.2 Site visits.

• Preparing feasibility report
Web site name: University of Missouri-St.Louis

17
Chapter three:
Proposed system

18
3. Proposed system
3.1 Overview
This chapter contains information about data analyzing, facts related to system elements, finding

logical relations among them to identify new system specifications and requirements and

cataloging and coding data.

3.2 User requirements

3.2.1 Interfaces Design should be simple and easy to learn.

3.2.2 System should be closed if left for 15 minutes automatically.

3.2.3 Each interface should include help information.

3.2.4 System should provide an easy way to reversible actions.

3.3 Hardware requirements to operate the system

3.3.1 Server with the following feature
Processor Minimum: 1 GHz for x86 CPU or 1.4 GHz for x64 cpu
Recommended: 2 GHz or faster
Memory Minimum 512 MB RAM
Recommended: 2 GB RAM or more
Available disk space Minimum: 10 GB
Recommended: 40 GB or more

Additional drives DVD-ROM

Display and peripherals Super VGA or higher
Keyboard and mouse

3.3.2 Client for every user with the following features

Processor Recommended: 1 GHz for x86 CPU or 1.4 GHz

for x64 CPU

Memory Minimum 256 MB RAM

Recommended: 1 GB RAM
Available disk space Minimum: 700 MB
Recommended: 10 GB or more

Additional drives DVD-ROM

Display and peripheral Super VGA or higher
Keyboard and mouse

19
3.4 Functional requirements:
Statements of services the system should provide, how the system should react

to particular inputs and how the system should behave in particular situations.

1) The patient management:

The patient management subsystem requirements are concerned

with the management of patient information. They specify how patient

information can be managed and manipulated.

1.1. The system should allow the user type 1(reception) and 2(doctor) to

add new patients into the system. The system should assign a unique ID to

new patients.

• 1.1.1. The system should allow the user type 1 and 2 to update patient

personal information (name, address, telephone, closest relative, date of

birth…).

• 1.1.2. The system should store all patient illness history information

(past illnesses, test results, allergies).

1.2. The system should allow authorized users types to retrieve patient

personal information by patient ID or patient last name, or first name.

1.3. The system should manage the patient check-in process

• 1.3.1. The system should update the patient status to in-patient

• 1.3.2. The system should record bed, nurse, and doctor information associated

with the patient.

• 1.3.3. The system should allow the user type 1 or 2 to change bed, nurse,

and doctor information associated with the patient

20
1.4. The system should allow the user type 1 and 2 to update patient

treatment information.

1.5. The system should manage the patient check-out process.

• 1.5.1. The system should update the patient status to out-patient

• 1.5.2. The system should calculate the bill due when the patient checks out.

1.6. The system should manage patients on a waiting list:

• 1.6.1. The system should allow the user type 1 or 2 to add patients to a waiting

list.

• 1.6.2. The system should allow the user type 1 or 2 to remove patients from a

waiting list.

• 1.6.3. The system should allow the user type 1 or 2 to retrieve waiting patient

information by illness category, illness seriousness, start waiting date, patient

last name, first name, or ID.

1.7. The system should allow authorized users types to generate reports on

patient.

• 1.7.1 The system should allow user type 1,2,3(manager) to generate reports on

selected patients.

• 1.7.2 The system should allow user type 1,2,3 to generate reports of or in-

patients by ward, illness category, or check-in date.

• 1.7.3 The system should allow user type 1,2,3 to generate reports of on-waiting

patients by illness seriousness, illness category, or waiting time.

21
2) Doctor Management Subsystem

The doctor management subsystem requirements are concerned with the

management of doctor information. They specify how doctor information

can be managed and manipulated.

1.1. The system should allow the user type 3(manager) to add new doctor

to the system.

2.2 The system should allow the user type 3 to remove doctor from the

system.

2.3 The system should allow the user type 3 to update doctor information.

• 2.3.1 The system should allow the user type 3 to update doctor personal

information (name, address, telephone, email, date of birth …).

• 2.3.2 The system should allow the user type 3 to update doctor specialty

information (area of expertise, experience).

2.4 The system should allow the user type 3 to retrieve doctor information

by doctor number or last name, first name, or tax file number.

• 2.4.1 The system should allow the user type 3 to retrieve available nurse

information.

• 2.4.2 The system should allow the user type 3 to retrieve doctor information by

specialty.

• 2.4.3 The system should allow the user type 3 to retrieve doctor personal

information.

2.5 The system should update doctor available information when a doctor

is assigned to a checked-in patient.

22
 2.6 The system should allow the user type 3 to generate reports on doctor

by specialty, available status, or experience.

3) Bed Management Subsystem

The bed management subsystem requirements are concerned with the

management of bed information in the hospital. They specify how bed

information can be managed and manipulated.

3.1 The system should allow the user type 1,2,3 to add new beds to a

ward.

3.2 The system should allow the user type 1,2,3 to remove beds from a

ward.

3.3 The system should update availability status when a patient checks

in or checks out.

3.4 The system should allow the user type 1,2,3 to retrieve available bed

information by bed number.

3.5 The system should allow the user type 1,2,3 to generate reports

about beds.

• 3.5.1 The system should allow the user type 1,2,3 to generate reports about beds

by ward or availability status.

• 3.5.2 The system should allow the user type 1,2,3 to generate bed usage statistic

reports showing bed usage rates in one year by ward.

23
 4) Other requirement.

The system should backup patient, doctor, and bed data every 12 hours

automatically.

3.5 Nonfunctional requirements:

All the remaining requirements which are not covered by the functional

requirements. They specify criteria that judge the operation of a system, rather than

specific behaviors, for example: “Modified data in a database should be updated for

all users accessing it within 2 seconds.”

• 1. security

The security requirements are concerned with security and privacy issues. All

patient medical information is required by law to be kept private

• 1.1 The system should support different user access privileges.

• 1.1.1 User type 1 should have security privilege level 1. They can only

read patient current illness information. They can’t access patient illness

history information

• 1.1.2 User type 2 should have security privilege level 2. They can read

and write patient current illness information. They can only access

patient illness history information if they have been assigned to the

particular patient

• 1.1.3 User type 3 should have security privilege level 3. They can read

and write patient current illness information. They can also read patient

history information.

• 1.2 The system should protect patient illness history information

24
• 2. Maintainability

the maintainability requirements are concerned with the maintenance issues of

the system.

• 2.1 The repair time of system should be under a half hour.

• 2.2 System down time for maintenance should be less than 6 hours per

quarter of a year.

• 3. Scalability

the scalability requirements are concerned with the scalable issues of the

system.

• 3.1 The system should be able to scale up to support more workstations.

System performance should not degrade if up to twenty percent.

• 4. Usability

Our system is easy to use because of its clear and professional design also

workers can know the type of data input from its label and the validation

that we will allocate in the design code so they will learn very vast and the

system in the other hand Prevents uncorrected data.

• 5. Availability

The system is available throughout all the day and deal with the worker with

specific authentication and it gives timely report associated with the worker

who deal with the system.

25
 • 6. Realistic

Points which we have discussed above is not imaginary so our system will

cover all that points. And also we worked to make the system serve the hospital

as they need and achieve their requirements.

3.6 System requirements structuring and modeling

3.6.4 DFD
3.6.4.1 DFD diagrams
3.6.4.1.1 Scenario
• Patient provide his information to the system.

• Patient select a service to be provided to him.

• The system gives the patient what time the service will be available.

• The patient chooses what time of the available choices to get the services.

• The system gives doctor appointment information.

• The doctor inter the prescription of the patient to the system.

• System gives the doctor patient record.

• Doctor can update the patient record like adding what kind of test or radiology the

patient needs.

• Nurse can make updates to patient like what medicine the patient take while he is

sleeping in the hospital.

• Technical stuff (radiologist and laboratory) can make updates to patient record like what
was the result of the tests.

• The system gives the patient its prescription and the total price of the services.

• The system get what amount of money that the patient paid.

• The patient can get a copy of his record from the system.

• The management can make new updates to and can get reports from the system.

26
3.6.4.1.2 Context level

Figure 3.1 Context level

27
3.6.4.1.3 Level Zero

Figure 3.2 Level Zero

28
3.6.4.1.4 Level one
Process one:

Figure 3.3 Process one of the DFD in level one

Process two:

Figure 3.4 Process two of the DFD in level one

29
Process three:

Figure 3.5 Process three of the DFD in level one

Process four:

Figure 3.6 Process four of the DFD in level one

30
 Process five:

Figure 3.7 Process five of the DFD in level one

3.6.4.1.5 Level two :
Process 1.2

Figure 3.8 Process 1.2 of the DFD in level two

31
Process 1.3

Figure 3.9 Process 1.3 of the DFD in level two

Process 1.4

Figure 3.10 Process 1.4 of the DFD in level two

32
 Process 1.5

Figure 3.11 Process 1.5 of the DFD in level two

Process 2.1

Figure 3.12 Process 2.1 of the DFD in level two

33
Process 2.3

Figure 3.13 Process 2.3 of the DFD in level two

Process 3.3

Figure 3.14 Process 3.3 of the DFD in level two

34
 Process 5.2

Figure 3.15 Process 5.2 of the DFD in level two

Web site DFD

Context level:

Question and Admin information

Suggestion

New updates
Questionnaire
Citizen Admin
Data
Hospital web site Question and suggestion
Available services

Questionnaire Result

Figure 3.16 Context level of web site DFD

Level zero:
New updates
1 2
User information
Verify user Make updates
User
Information
Valid user

New services Question and

d2 Services Suggestion
D1 Users
Admin Available Citizen
Services

3 Available 4 5
Services
Fill
Locate services Contact
Questionnaire Questionnaire
Administration
Form Data
Question and
Suggestion
Questionnaire
Question and Form
d3 Suggestion
Question and suggestion
D4 Questionnaire
35 Figure 3.17 Level
Questionnaire Result
Zero of web site DFD
3.1.1 DFD descriptions:
3.1.1.1 The internal system of the hospital.
3.1.1.1.1 Data flow dictionary

Figure 3.18 patient information data flow description

Figure 3.19 payment information data flow description

36
Figure 3.20 report information data flow description

Figure 3.21 service request data flow description

37
Figure 3.22 appointment information data flow description

Figure 3.23 patient record data flow description

38
Figure 3.24 update appointment information data flow description

Figure 3.25 update patient record data flow description

39
Figure 3.26 user information data flow description

Figure 3.27 patient record data flow description

40
3.1.1.1.2 Data Structure
Patient information = patient number+
Patient name+
Birth date+
Sex+
Address+
Phone number

Bill = Bill number+

Total +
(Discount)+
Date

Staff information =Employee number+

Employee name+
Age+
Salary+
Address+
Phone number+
Department number

Service information=Service number+

Service name+
Price+
Branch number

Department information= Department number+

Department name+
Location

Branch information = Branch number+

Branch name+
Department number

Test = Group+
Unit +
Titer

Figure 3.28 data structure

41
3.1.1.1.3 Data Store

Figure 3.29 branch data store

42
Figure 3.30 department data store

Figure 3.31 staff data store

43
 Figure 3.32 service data store

Figure 3.33 appointment data store

44
Figure 3.34 patient data store

Figure 3.35 patient data store

45
3.1.1.1.4 Data elements

Figure 3.36 account id data element

Figure 3.37 patient id data element

46
 Figure 3.38 salary data element

Figure 3.39 username data element

47
 Figure 3.40 sex data element

Figure 3.41 birth date data element

48
Figure 3.42 phone number element description form

Figure 3.43 department name data element

49
Figure 3.44 patient name data element

Figure 3.45 address data element

50
3.1.1.2 Web site
3.1.1.2.1 Data flow dictionary

Figure 3.46 questionnaire data flow dictionary

Figure 3.47 question and answer data flow dictionary

51
 Figure 3.48 valid user data flow dictionary

3.1.1.2.2 Data Structure

User information = User number+

Password

Question and Suggestion = Question number+

Question content+
(Doctor Name)+
Current Date

New Service = Service number+

Service name+
Price+
Branch number

Figure 3.49 web site data structure

52
3.1.1.2.3 Data Store

Figure 3.50 user store description from

Figure 3.51 service data store description from

53
Figure 3.52 suggestion data store description from

Figure 3.53 question data store description form

54
Figure 3.54 questionnaire store description from

55
3.1.1.1.1 Data elements

Figure 3.55 suggestion heading element description form

Figure 3.56 suggestion text element description form

56
 Figure 3.57 visitor name element description form

Figure 3.58 service description element description form

57
 Figure 3.59 service name element description form

3.1.1.3 Logical Process Modeling

3.1.1.3.1 Decision Tables
Table 3.1 discount process decision table
Patient takes more than five services 10% Y Y Y Y N N N N
Patient is one of employees' family 15% Y Y N N Y Y N N
Patient is recorded in the social security 20% Y N Y N Y N Y N
Discount 0% X
Discount 10% X
Discount 15% X
Discount 20% X X
Discount 25% X
Discount 30% X
Discount 45% X

58
3.1.2 Entity Relationship Diagram (ERD)
3.1.2.1 patient information system ERD
Acc_Id Acc_Name Dept_Id Dept_Name Location Brch_Id Brch_Name

Privilege

Account Department
1 N Branch
1
N Works On Contains 1
Username

Has Pass Servc_Id

Offers
Staff_Id
Bill_Id
Status Servc_Name
Total
Staff Name N
M Price
N
Discount
Age
Service
Staff
Address Disc_Detail

Phone_No Acont_Id
N Floor
Dept_Id Bill
Room No Type
Creates
N
Working Time
Date 1
1 Branch
Pays For Room
Accountant
Details Date 1
Room_No
N Contains
N Exit Date Bed No
Branch
Takes Care
N
Assign Date
Assigns
N Bed
N
Patient_Id Sex
M
Nurse Group
Patient Name Address
Patient
Unit
Birthdate Phone_No
Experience M Titer
1
D
N D
Appt_Id N Requests_
Branch
Has Test Lab Test
Appointment
Date_Time
Date Result
Status 1 Type

N
N Requests_
Branch
N Ray
Ray Image
1 Result
Doctor Date
N Makes_ N
Branch
Operation Operation
1 Result
Specialty N
N Date Type
Working Time Branch
Prescribes

Treatment

Presc_Id Details Date Type

Figure 3.60 ERD of patient information system

59
 3.5.5.1 Web site of hospital ERD

Id Name Password ID Text Answer ID Password

Admin
1 Answer
M
Question
M
Make
1 Visitors Name

1
M

M
ID Suggestions Suggest
Rating Assessment
Id

Heading Text Id Name

M Name

Departments 1 M
Description Belongs to Services Price

Figure 3.61 Web site of hospital ERD

60
3.1.3 Mapping
3.1.3.1 Hospital management system

Figure 3.62 Mapping of the ERD

61
Figure 3.63 Mapping of the ERD (cont).

62
3.1.3.1 Hospital Web site.

Admin

id name password

Question

id text answer visitor id admin id

Visitor

Id User name Password

Suggestion

Id Text Heading Visitor id

Assessment

Visitor id Service id Rating

Service

Id Name Price Department id

Department

Id Name Description

Figure 3.64 Mapping of the ERD.

63
 Chapter Four:
Implement the System

64
4. Project interfaces
4.1 Overview
This chapter contains all the information about project database tables, database diagram,
interfaces and integration and system testing. The interfaces of the project can be divided into
nine module which are administration, reception, doctor, cashier, lap, ray, emergency, operation,
and entry and exit module.

65
4.2 Database building
4.2.1 Database diagram

Figure 4.1 shows Database diagram

66
4.2.2 Database Tables

Table 4.1 person table

Column Name Data Type Size

Person_Id bigint 8

Person_Name nvarchar 100

Birth_Date date

Gender nvarchar 5

Phone_No varchar 20

Province nvarchar 20

District nvarchar 20

Address text

Table 4.2 Assessment table

Column Name Data Type Size
MRN bigint 8
Nurse_Id bigint 8
Date_Time datetime
Assessment_Type nvarchar 50
Result nvarchar 100
Notes nvarchar 100

Table 4.3 Bed table

Column Name Data Type Size
Bed_No bigint 8
Room_No bigint 8
Branch_Id varchar 30
Status nchar 2

Table 4.4 Branch table

Column Name Data Type Size
Branch_Id varchar 30
Branch_Name nvarchar 50
Dept_Id varchar 20

67
 Table 4.5 Clinic Record table
Column Name Data Type Size
Record_No bigint 8
Procedure_Code varchar 30
Result nvarchar 100
Notes nvarchar 100

Table 4.6 Bill table

Column Name Data Type Size
Bill_No bigint 8
Total numeric (8,2)
Discount numeric (8,2)
Discount _Type nvarchar 50
Final_Cost numeric (8,2)
Notes nvarchar 50
Account_Id bigint 8

Table 4.7 Emergency_Contact table

Column Name Data Type Size
Contact_Id bigint 8
Patient_Id bigint 8
Relation nvarchar 50

Table 4.8 User table

Column Name Data Type Size
User_Id bigint 8
Email varchar 100
User_Image varchar 50

User_Type nvarchar 10

Table 4.9 Appointment table

Column Name Data Type Size
Appointment_Id float 8
Mrn bigint 8
Doctor_Id bigint 8
App_Date_Time datetime
Details nvarchar 50
Status nvarchar 50

68
 Table 4.10 Department table
Column Name Data Type Size
Dept_Id varchar 20
Dept_Name nvarchar 50
Location nvarchar 50

Table 4.11 Doctor table

Column Name Data Type Size
Doctor_Id bigint 8
Speciality nvarchar 50

Table 4.12 Doctor Schedule table

Column Name Data Type Size
Schedule _Id int 4
Doctor_Id bigint 50
Dept_Id varchar 20
Clinic_Name nvarchar 50
Day nvarchar 10
From_Time time 7
To_Time time 7
Period nvarchar 10

Table 4.13 Emergency_Patient table

Column Name Data Type Size
Person_Id bigint 8
MRN bigint 8
Patient_State nvarchar 100
Discharge_Type nvarchar 50
Discharge_Date_Time datetime
Discharge_State nvarchar 100
Notes text

69
 Table 4.14 In Patient table
Column Name Data Type Size
Person_Id bigint 8
MRN bigint 8
Bed_No int 4
Room_No int 4
Branch_Id varchar 30
Admission_Type nvarchar 50
Admission_State nvarchar 100
Doctor_Name nvarchar 100
Reference_Doctor nvarchar 100
Discharg_Type nvarchar 50
Discarge_Date_Time datetime
Notes text

Table 4.15 Lab Record table

Column Name Data Type Size
Record_No float 8
Test_Code varchar 30
Result nvarchar 50
Lab_No int 4
Period nvarchar 10
Notes nvarchar 100

Table 4.16 Nurse table

Column Name Data Type Size
Nurse_Id bigint 8
Experience nvarchar 100
Branch_Id varchar 30
Work_Period nvarchar 10

Table 4.17 Operation Record table

Column Name Data Type Size
Record_No float 8
Operation_Code varchar 30
Operation_Date_Time datetime
Anesth_Type nvarchar 50
Surgeon_Doctor nvarchar 50
Surgeon_Assistant nvarchar 50
Anesth_Doctor nvarchar 50
Anesth_Assistant nvarchar 50
Result nvarchar 100
Notes nvarchar 100

70
 Table 4.18 Order table
Column Name Data Type Size
Order_Id float 8
MRN bigint 8
Date_Time datetime
Doctor_Id bigint 8
Order_Type varchar 50

Table 4.19 Order_Service table

Column Name Data Type Size
Order_Id float 8
Service_Code varchar 30
Status char 1

Table 4.20 Out_Patient table

Column Name Data Type Size
Person_Id bigint 8
MRN bigint 8
Patient_State nvarchar 100
Bill_No float 8
Visit_Type nvarchar 5
Period nvarchar 5
Clinic_Name nvarchar 50
Discharge_Date_Time datetime
Notes text

Table 4.21 Patient table

Column Name Data Type Size
Patient_Id bigint 8
MRN bigint 8
Date_Time datetime
Dept_Name nvarchar 50
Patient_Type nvarchar 10
Doctor_Name nvarchar 100

Table 4.22 Patient_Charge table

Column Name Data Type Size
Service_Code varchar 30
MRN bigint 8
Date_Time datetime
Bill_No float 8
Quantity int 4
Total_Cost float 8

71
 Table 4.23 Patient_Record table
Column Name Data Type Size
Record_No float 8
MRN bigint 8
Order_Id float 8
Date_Time datetime
Recoed_Type nvarchar 10

Table 4.24 Prescription table

Column Name Data Type Size
Prescription_Id float 8
MRN bigint 8
Doctor_Id bigint 8
Date_Time datetime
Diagnosis nvarchar 50
Details nvarchar 100
Notes nvarchar 100

Table 4.25 Ray Record table

Column Name Data Type Size
Record_No float 8
Ray_code nvarchar 30
Result nvarchar 100
Period nvarchar 10
Films_Count int 4
Films_Size nvarchar 10
Damaged_Films int 4

Table 4.26 Room table

Column Name Data Type Size
Room_No int 4
Branch_Id varchar 30
Room_Type varchar 30

Table 4.27 Service table

Column Name Data Type Size
Service_Code varchar 30
Service_Name nvarchar 80
Price float 8
Description nvarchar 100
Branch_Id varchar 30

72
 Table 4.28 Technical table
Column Name Data Type Size
Technical_Id bigint 8
Skills nvarchar 100
Dept_Id varchar 20
Work_Period nvarchar 10

4.3 Interfaces building and system manual

4.3.1 Administration module interfaces.

in this module there are seven tabs, the first one is departments and partial departments
through it we can add new departments and partial department and update any one of them,
the second one is services through this tab we can add new services or update any one of
them, in the third tab is rooms and bedrooms tabs which used to add new rooms and
bedrooms and edit any one of them, the fourth tab is employees through this tab we can add
new employee with all his personal information and specialty information and also his
privilege information, the fifth tab is used for managing users in this tab we can update user,
activate or disabled any one of users, the sixth tab is for reports with all the available reports
in administration department, the last tab is sitting tab through it we can monitor all database
component and their state if it is activated or not and all interface components.
To open project follow this this path and as in the small screenshot
C:\Users\rash3500\Desktop\PRMS\PRMS\bin\Release\PRMS.exe

then the interface of the system start from here

Figure 4.2 shows how to log in interface with password as a required field.

73
Figure 4.3 shows how the log in interface with password after it has been entered.

Figure 4.4 shows the department management interface

74
Figure 4.5 shows the adding new department interface.

Figure 4.6 shows update existing department interface.

75
 Figure 4.7 shows adding new partial department interface.

Figure 4.8 shows updating existing partial department interface.

76
Figure 4.9 shows service management interface.

Figure 4.10 shows adding new service interface.

77
 Figure 4.11shows updating existing service interface.

Figure 4.12 shows room and bedroom management interface.

78
 Figure 4.13 shows adding new room interface.

Figure 4.14 shows updating existing room interface.

79
 Figure 4.15 shows adding new bedroom interface.

Figure 4.16 shows updating existing bedroom interface.

80
 Figure 4.17 shows employees management interface.

Figure 4.18 shows adding new employee interface (personal information).

81
 Figure 4.19 shows adding new employee interface (working time information).

Figure 4.20 shows adding new employee interface (working time information but after adding
working time that appears in the right of the interface).

82
 Figure 4.21 shows adding new employee interface (privilege information).

Figure 4.22 shows adding new employee interface (the new employee after he has been added to the
system and appears in the green row of the table).

83
 Figure 4.23 shows users' management interface (from this interface one use can be enabled or
disabled or all can be enabled or disabled except admin).

Figure 4.24 shows updating user's privilege interface (from here the admin can define which module
can be entered by the user).

84
 Figure 4.25 shows report management interface.

Figure 4.26 shows report appears in the left of the interface.

85
Figure 4.27 shows the user updating his user name, password and photo by clicking on the account
setting in the interface.

Figure 4.28 shows the message that appears when user chooses log out or click on x button.

86
4.3.2 Reception module interfaces

In this module there are there tabs the first one is receipt patient to add his personal
information if it hasn't been entered before, the second tab is to make query about patients or
doctors, the third one is to show the reports that are available in reception department.

Figure 4.29 shows receipt new patient interface.

Figure 4.30 shows adding patient's personal information interface.

87
Figure 4.31 shows adding patient's visit information, department name and type of order to see the
doctor.

Figure 4.32 shows query about patients or doctors interface.

88
 Figure 4.33 shows reception's reports interface.

4.3.3 Cashier module interfaces

In this module there are three tabs the first one is make new bills for selected services,
the second one is to edit bills, and the third one is to show the available reports in the cashier
module.

figure 4.34 shows get a price of the service interface.

89
 Figure 4.35 shows adding or updating bills.

Figure 4.36 shows report interface of cashier department.

90
4.3.4 Doctor module interfaces
In this module there are four tabs the first one is appointment tabs to show the
appointments with patients who selected that appointment, the second tab is to add the
information about his state and his visit, the third tab is to see patient state after a period of
time, the fourth tab is reports which shows the available reports in doctor module.

Figure 4.37 shows all entered appointenmts from reception department appears in the appointment
interface.

Figure 4.38 shows how to add patient's information in his visit and the required procedures.

91
Figure 4.39 shows how to add patient's information in his visit and the required lap exams.

Figure 4.40 shows how to add patient's information in his visit and the required ray exams.

92
Figure 4.41 shows how to add patient's information in his visit and if he needs to be transferred.

Figure 4.41 shows the reports interface press view to see the report in the left of the interface.

93
4.3.5 Ray module interfaces
In this module there are three tabs, the first one is working list to show the patients with
their selected ray exams and interface to enable the lap specialist add new once for patients,
the second tabs is results tab in this tab we add the results of exams, the last tab is reports
which shows the available reports in ray department.

Figure 4.43 shows list of the patients who need to take any ray exam.

Figure 4.44 shows how to add rays' results.

94
 Figure 4.45 shows the reports' interface press view to see the report in the left of the interface.

4.3.6 Lap module interfaces

In this module there are three tabs, the first one is working list to show the patients
with their selected exams and interface to enable the lap specialist add new once for patients,
the second tabs is results tab in this tab we add the results of exams, the last tab is reports
which shows the available reports in lap department.

Figure 4.46 shows list of the patients who need to take any lap exam.

95
 Figure 4.47 shows how to add lap exams' results.

Figure 4.48 shows the reports' interface press view to see the report in the left of the interface.

96
4.3.7 Emergency module interfaces
In this module there are three tabs the first one is new emergency patient to add his
personal information and the information about his responsible person information, the
second tab is list of the existing patients in this department and it shows details information
about them, and the last tab shows the available reports in emergency department.

Figure 4.49 shows the existing patients in the emergency department and to add with new emergency
patients (personal information tab).

Figure 4.50 shows the existing patients in the emergency department and to add with new emergency
patients (the responsible of patient information tab).

97
Figure 4.51 shows the existing patients in the emergency department with details of every patients.

Figure 4.52 shows the reports' interface of emergency department, press view to see the report in the
left of the interface.

98
4.3.8 Entry & Exit module interfaces
In this module there are five tabs the first one is new inpatient to add the information
about the new inpatient, the second tab is inpatients tab to shows all the detailed operations
about every inpatient in this department, the third tab is exit/transfer tab to fill information
about exit and transferred patients, the fourth tab is state of rooms and bedrooms whereas the
last tab is reports tab to show the available reports in this department.

Figure 4.53 shows the needed information of the new inpatient's information.

Figure 4.54 shows the existing patients in the entry exit department with details of every patient.

99
Figure 4.55 shows the needed information of patient to be exit or transferred.

Figure 4.56 shows the needed information of patient to be exit or transferred.

100
 Figure 4.57 shows the reports' interface of entry exit department, press view to see the report in the
left of the interface.
4.3.9 Operation module interfaces
In the operation module contains three tabs the first tab is request operation to enter the
information of operation, the schedule, surgery doctor, drug doctor, operation room number and type
of operation, the second tab is the schedule of operation to shows the list of scheduled patients and
with fields to be filled about operation result, the third tab is reports which shows the available
reports in operation department.

Figure 4.58 shows list of patients who requested to be scheduled in the operations department with
the required information to be entered.

101
Figure 4.59 shows list of patients who has been scheduled in the operations department and operation
result to be entered.

Figure 4.60 shows the reports' interface operation department, press view to see the report in the left
of the interface.

102
4.4 integration and system testing

4.4.1 System integrity testing

In the process of system testing we used Top-Down testing strategy. This strategy has
the following properties:
• Main control module used as a test driver and stubs are substitutes for
components directly subordinate to it.
• Subordinate stubs are replaced one at a time with real components
(following the depth-first or breadth-first approach).
• Tests are conducted as each component is integrated.
• On completion of each set of tests and other stub is replaced with a real
component.
• Regression testing may be used to ensure that new errors not introduced.

So in our testing process first we built the first module which is administration
module with its component and test it as one unit then we built the reception module with
all its component then we test it as one unit and integrated it with the administration
module after that we built the cashier module and test it as one unit and integrated it with
the administration and reception and we did that with other modules to the emergency
module as shown in figure 4.61.
Integrating

Integrating

Integrating

Integrating

Integrating
Integrating

Integrating Integrating
Admin

Reception
Testing

Testing Cashier

Doctor
Testing

Testing Lap

Ray
Testing

Entry exit
Testing

Operation
Testing

Emergency
Testing

Figure 4.61 shows the process of integration among modules and testing

103
 4.4.2 System testing

• Usability testing: the system is easy to use and all its properties can be accessed.
• GUI software testing: the graphics of the system is compatible with the system type
and work.
• Security testing: the system is secure and no one can access information except those
who has permission to access them.
• Accessibility: the system is not compatible with those who is disable.
• Reliability testing: the system has been used for 15 days without continuous stops.
• Overall: the system doesn’t have usual errors in its modules as small units and all the
system as a whole.

4.5 Results of the project

The result of our project we built a hospital management system can maintain
information about patients, doctors, users, nurses, departments, partial departments,
and services.
The system also has the ability to produce a variety of reports depending on
the module that belongs to it.

104
 Chapter five:
Recommendations and
Suggestions

105
5. Recommendations and Suggestions
5.1 Overview
This chapter contains the last contents of our project which are suggestion
and recommendation.

5.2 Suggestions
• Adding a new module like pharmacy, HR, financial management and so on.
• Adding new languages like English.
• Making an interactive website connected with system and use its data.
• Transfer the application from desktop application to web site application.

5.3 Recommendations
• The data of our hospital system or others after a few years should be used
to define new knowledge like that’s in data mining research.
• Our project should be connected to others system that is used in ministry
of health to help them in their work.
• Research should try to find a good way to resolve the bad custom that all
hospital used to do and also we follow in out project which is paying
before getting the service.

106
 References
1. Jason Westland, 2006, project management life cycle.
2. Ian Sommerville, 2007, software engineering.
3. Khalid alsakany and others, patient record management system for moris hospital,
supervisd by Dr. Ali Alsarafi.
4. Ramez Elmasri, Shamkant B. Navathe.—6th, 2010, Fundamentals of database
systems.
5. KENNETH E. KENDALL, 2011, system analysis and design.
6. Pavadee Katimuneetorn, IS 6840 (Fall 2008) Term Paper, Feasibility Study for
Information System Projects.

Web sites
7. Quanta-v3 Hospital Management System, www.birlamedisoft.com.
8. Bayanno Hospital Management System Pro, www.Bayanno.com.

107
 Accessories
Existing data forms of the hospital
we list here only seven forms there are others form can be seen in the CD in folder called hospital
past document

108
Figure 7.1 biochemistry record

Figure 7.2 C.B.C record

109
Figure 7.3 Harmonies record

110
Figure 7.4 microbiology record

111
Figure 7.5 sleeping record

112
Figure 7.6 emergency record

113
Figure 7.7 serology record
114