Design and Implementation of a Distributed e ...

Design and Implementation of a Distributed e-Healthcare System Based on Principles of e-Government Applications

A Thesis Submitted to the Council of the College of Commerce University of Sulaimani in Partial Fulfillment of the Requirements for the degree of Master in Information Technology

By

Roshna Mohammed M. Amin

Supervised by

Dr. Subhi R. M. Zeebaree Assistant Professor

June 2015

Pushpar 2715

‫‪‬‬ ‫ير َفع ّ‬ ‫دَر َجات)‬ ‫َللاه الّذينَ آ َم هنوا من هك ْم َوالّذينَ أهو هتوا ا ْلع ْل َم َ‬ ‫( ْ‬

‫‪‬‬ ‫سورة المجادلة‬

Dedication

This thesis is dedicated to  My father’s spirit  My respected Mother  My dear husband  My love daughter(Alle) and My Son(Lawe)

Acknowledgments

First of all praise be to Allah for all his Graces in granting me patience and faith to complete the present study.  I would like to express my special thanks and appreciations to my supervisor, (Dr. Subhi Rafeeq Mohammed) for his guidance, encouragement, and the advice that he gave me throughout the progress of this study.  My thanks to IT Dept.-College of Commerce, specially the head of the department (Dr. Rezan Hama Rashid) for her support and encouragement.  Thanks goes to the Mathematics Dept.-School of Science EducationFaculty of Science and Science Education at University of Sulaimani.  My Thanks to private Soma hospital for helping the researcher to get real data.  My special thanks to Mr. Giyath Zebari at Akre Computer Institute for his great help in this work.  Special thanks to Mr. Noor Najeeb Qaqos at Shekhan Technical Institute.  My special thank also goes to the staff of Computer Science Institute at Sulaimani Polytechnic University for facilitating the use of their specific labs to complete the tests.  I would like to express my deepest gratitude to my lovely husband Hussen for his patience, constant encouragement, continuous care and support during my study. Finally my thanks to all who helped me to complete this work.

I

Abstract Technology results in improvements on many facets in all societies, one of these societies is Kurdistan Region-Iraq (KR). Being a traditional system, the sector of healthcare suffered continually from being a slow-paced processes consuming effort, time , money and safety. Patients and healthcare-center staffs must spent a lot of efforts for communicating with one another. The proposed system Electronic Healthcare System (EHS) that deals with real time availability and is controlled by an administrator. This system provides the feature that all prototypes are integrated in one homepage. The proposed system deals with both of two Tier Architecture (2TA) and three Tier Architecture (3TA) which have been designed and implemented in this thesis. The proposed EHS facilitates a fully automating and complete healthcare system and eliminate any paperwork, saves time and integrates all healthcare center

sections

(i.e.

patients,

physicians,

pharmacies,

radiographers,

laboratories, receptionists, administrative) and is available online. The attractiveness of the proposed system is in reducing patient’s pre-visit and postvisit as the patient can reserve appointments and get the result of lab-tests via the internet. In order to determine the server efficiency (time response and data flow) two different techniques were adopted; the first technique is the traditional handwriting program by Hypertext Preprocessor (PHP) script code, and the second one is ready application, namely Wireshark (Network Protocol Analyzer). Both techniques will help to find out least response time with 2TA and 3TA, over two different platforms Operating System (OSs) which are; Microsoft Windows-7 and the open source OS Linux-Ubuntu version14.04. For network-efficiency evaluation, a professional simulation tool, called Optimized Network Engineering Tool (OPNET), is depended on to check the system with large networks for both 2TA and 3TA. II

The results showed that 3TA is more powerful than 2TA in term of dataprotection and time delay by splitting the services between both of http-server and database-server. Hence it will provide more performance specially when dealing with very large networks with thousands (or millions) clients.

III

List of Contents Chapter One: Introduction 1.1

Overview……………………………………………………………………

1

1.2

Literature Review…………………………………………………………...

4

1.3

Problem Statement………………………………………………………….

6

1.4

Aims of Thesis……………………………………………………………...

6

1.5

Thesis Layout……………………………………………………………….

7

Chapter Two: Background Theory 2.1

Introduction…………………………………………………………………

8

2.2

Brief History of E-Healthcare……………………………………………..

8

2.3

Approach of System Development…………………………………………

9

2.4

Transferring from Manual Government to Electronic Government………..

10

2.5

Principles of Electronic Government……………………………………….

11

2.6

Electronic Healthcare Systems……………………………………………...

12

2.7

E-healthcare and the Related Variation Models…………………………….

14

2.8

General E-Healthcare System Elements……………………………………

14

2.8.1 The Web……………………………………………………………..

16

2.8.2 Web Server and the Related Technologies………………………….

16

2.8.3 Web Browser……………….……………………………………….

17

2.8.4 PHP and MySQL…………………………………………………….

18

Component-Level Designing and Architectures…………………………….

19

2.9.1 Two-Tier Architecture (2TA)……….……………………………….

19

2.9.2 Three-Tier Architecture (3TA)…………………….………………...

20

2.9

I

2.10

Wireshark (Network Protocol Analyzer)………………………………….....

22

2.11

Optimized Network Engineering Tool (OPNET) Tool………………………

23

Chapter Three:Design and Implementation of the Propose EHS 3.1

Introduction…………………………………………………………………

25

3.2

Structure of the Proposed EHS……………………………………………...

25

3.3

System Requirements Interface……………………………………………..

28

3.4

Proposed System Services and Related Algorithms …...………………..….

32

3.4.1 Patient Module ………………………………………………………

34

3.4.1.1 Implementation of Patient Module Algorithm …………….....

35

3.4.2 Doctors Module……………………………………………………..

40

3.4.2.1 Implementation of Doctors Module……………………........

41

3.4.3 Laboratories Module………………………………………………...

46

3.4.3.1 Implementation of Laboratories Module ……………………..

47

3.4.4 X-ray Module ……………………………………………………….

48

3.4.4.1 Implementation of X-ray Module…………………………….

49

3.4.5 Pharmacy Module…………………………………………………….

50

3.4.5.1 Implementation of Pharmacy Module………………………..

51

3.5

3.4.6 Receptionist Module…………………………………………………..

52

3.4.6.1 Implementation of Receptionist Module…………………….

53

3.4.7 Administrator Module………………………………………………..

54

3.4.7.1 Implementation of Administrator Module……………………

55

3.4.8 Contact us……………………………………………………………….

57

Structure of the Established Database……………………………………….

58

II

Chapter Four: Performance Analysis of the Proposed EHS 4.1

Introduction…………………………………………………………………

62

4.2

Performance Analysis Implementation Criteria…………………………….

62

4.3

Time-Consume Analysis approaches……………………………………….

63

4.4

The Testing Media Strategy………………………………………………...

64

4.5

Operating System Windows with Tiers Architectures……………………...

65

4.5.1 Window-7 with 2TA………………………………..………………..

65

4.5.2 Window-7 with 3TA………………………………..………………..

70

Operating System Linux with Tiers Architectures…………………………..

74

4.6.1 Linux Ubuntu-14.04 with 2TA……………………………………….

74

4.6.2 Linux Ubuntu-14.04 with 3TA…………………………………….....

78

4.7

Load and Performance Test………………………………………………….

82

4.8

Additional Test Using OPNET Tool…………………………………………

84

4.6

4.8.1 Results Obtained for Four-Evaluation-Scenarios Using OPNET Tool... 85 4.8.2 Results Obtained for Large Number of Clients Using OPNET Tool..... 4.9

91

Evaluation and Comparison………………………………………………....... 100

Chapter five: Conclusions and Suggestions For Future Work 5.1

Conclusions………………………………………………………………....

103

5.2

Suggestions for Future Work……………………………………………….

104

References………………………………………………………………..

105

Appendix-A: Database Design Appendix-B: Network Mechanism Using OPNET Simulator III

List of Figure Figure

Page no.

Title

2.1

The Participants in E-government

11

2.2

The Current Healthcare Landscape

13

2.3

Models Variation related to e-healthcare

14

2.4

Architecture of the developed web based application

15

2.5

Two-Tier Architecture

20

2.6

Three-Tier Architecture

21

2.7

E-healthcare Three-Tier Architecture

22

3.1

2TA and 3TA Architectures

27

3.2

Basic phases of the establishment of proposed EHS

28

3.3

Hardware part of EHS proposed system 2TA

31

3.4

Hardware part of EHS proposed system 3TA

31

3.5

Proposed system services

32

3.6

The main window of EHS

33

3.7

Patient login window

35

3.8

Patient registration window

36

8 3.9

The message of patient successful registration

36

3.10

Patient homepage

37

3.11

Get appointment window

38

3.12

Cancel appointment page

38

3.13

Patients previous diagnosis details

39

3.14

Edit patient’s personal information

39

3.15

Patients forgot password window

40

3.16

Doctor login window

42

3.17

Daily doctor appointments

42 IV

Title

Figure

Page no.

3.18

Appointment for patient in Laboratory

43

3.19

Appointment for patient in X-ray department

44

3.20

Medical prescription for patient

45

3.21

Search for patient previous diagnosis by doctors

46

3.22

Laboratories homepage

48

3.23

Appointment’s patient for X-ray

50

3.24

Pharmacy daily patients list for medicines

51

3.25

Pharmacy patients list for medicines in period

52

3.26

Patient registration by receptionist

53

3.27

Emergency registration by receptionist

54

3.28

Administrator login page

56

3.29

Main administrator

56

3.30

Semi-admin homepage(pharmacy)

57

3.31

Contact us form

57

3.32

EH database tables

58

4.1

The established network for EHS

65

4.2

Average consumed-time for 2TA Windows-7

69

4.3

Total Dataflow for 2TA Windows-7

70

4.4

Average Consumed-time for 3TA Windows-7

73

4.5

Total Dataflow for 3TA with Windows-7

74

4.6

Average Consumed-time for 2TA with Linux Ubuntu -14.04

77

4.7

Total Dataflow for 2TA with LinuxUbuntu-14.04

78

4.8

Average Consumed-time for 3TA with Linux Ubuntu-14.04

81

4.9

Total Dataflow for 3TA with Linux Ubuntu-14.04

81

4.10

Average Consumed-time for 2TA and 3TA using Windows-7

83

V

Figure

Page no.

Title

4.11

Average Consumed-time for 2TA and 3TA using Linux Ubuntu -14.04

83

4.12

Four evaluation-scenarios for 2TA using OPNET-tool

85

4.13

Total-Network-Delay comparison of the Four evaluation-scenarios for 2TA using OPNET-tool.

86

4.14

Server-Delay comparison of the Four evaluation-scenarios for 2TA using OPNET-tool

87

4.15

Server-Load comparison of the Four evaluation-scenarios for 2TA using OPNET-tool

87

4.16

Four evaluation-scenarios for 3TA using OPNET-tool

89

4.17

Total-Network-Delay comparison of the Four evaluation-scenarios for 3TA using OPNET-tool

90

4.18

HTTP-Server-Delay comparison of the Four evaluation-scenarios for 3TA using OPNET-tool

90

4.19

HTTP-Server-Load comparison of the Four evaluation-scenarios for 3TA using OPNET-tool

91

4.20

Evaluation-scenario-1 with three different-size-networks connected to a server via a Router for 2TA using OPNET-tool

92

4.21

(HTTP+Database)-Server Delay and Load (bits/Sec.) for 2TA of Figure (4.20) using OPNET-tool

93

(HTTP+Database)-Server Load (Requests/Sec.) for 2TA of Figure (4.20) using OPNET-tool.

93

Evaluation-scenario-2 with three different-size-networks connected to a server via Internet for 2TA using OPNET-tool

94

(HTTP+Databse)-Server-Load (Requests/Sec.) for 2TA of Figure (4.23) using OPNET-tool

95

(HTTP+Database)-Server Delay for 2TA of Figure (4.23) using OPNETtool

95

Evaluation-scenario-3 with three different-size-networks connected to a servers via a Router for 3TA using OPNET-tool.

96

4.27

Database-Server Delay and Load (bits/Sec.) for 3TA of Figure (4.26) using OPNET-tool

97

4.28

HTTP-Server Load (bits/Sec.) for 3TA of Figure (4.26) using OPNET tool

97

(HTTP +Datab 4.22 ase)Server Delay 4.23 and Load (bits/Se 4.24 c.) for 2TA of Figure 4.25 (4.22) using OPNE 4.26 T-tool

VI

Figure

Page no.

Title

4.29

Total- HTTP-Server-Load (Requests/Sec.) for 3TA of Figure (4.26) using OPNET-tool

98

4.30

Evaluation-scenario-4 with three different-size-networks connected to a servers via Internet for 3TA using OPNET-tool

98

4.31

HTTP-Server Load (bits/Sec.) for 3TA of Figure (4.30) using OPNET-tool

99

4.32

Total- HTTP-Server-Load(Requests/Sec.)for 3TA of Figure(4.30) using OPNET-tool

99

VII

List of Tables Table

Page no.

Title

3.1

The specification of the database tables

59

4.1

Consumed-time and Dataflow of 2TA with Windows-7 using (1, 5 and 10)-clients

67

4.2

Consumed-time and Dataflow of 2TA with Windows-7 using 20- Clients

68

4.3

Average Consumed-time and Total Dataflow for 2TA with Windows-7 using (one, five, ten and twenty) clients

69

4.4

Consumed-time and Dataflow of 3TA with Windows-7 using (1, 5 and 10)-Clients

71

4.5

Consumed-time and Dataflow of 3TA with Windows-7 using 20-Clients

72

4.6

Average Consumed-time and total Dataflow of 3TA with Windows-7

73

4.7

Consumed-time and Dataflow of 3TA with Linux Ubuntu14.04 using (1, 5 and 10)-Clients

75

4.8

Consumed-time and Dataflow of 2TA with Linux Ubuntu14.04 using 20Clients

76

4.9

Average Consumed-time and Dataflow of 2TA with Linux Ubuntu-14.04

77

4.10

Consumed-time and Dataflow of 3TA with Linux Ubuntu14.04 using(1, 5 and 10)-Clients

79

4.11

Consumed-time and Dataflow of 3TA with Linux Ubuntu-14.04 using 20Clients

80

4.12

Average Consumed-time and total Dataflow of 3TA with Linux Ubuntu14.04

81

VIII

Table

Page no.

Title

4.13

Average Consumed-time for 2TA and 3TA using Windows-7

82

4.14

Average Consumed-time for 2TA and 3TA using Linux Ubunutu-14.04

83

4.15

Total-Network-Delay and Server-Load for 2TA using OPNET-tool

86

4.16

Total-Network-Delay and Server-Load for 3TA using OPNET-tool

89

IX

List of Abbreviations Abbreviation

Description

2TA

Two-Tier Architecture

3TA

Three-Tier Architecture

ACT

Average Consumed Time

ASP

Active Server Page

CA

Controller Agent

CBIS

Computer Based Information System

CGI

Common Gateway Interface

CPU

Central Processing Unit

CSS

Cascade Style Sheet

DA

Doctor Agents

EGDI

Electronic Government Development Index

EH

Electronic Healthcare

EHS

Electronic Healthcare System

G2B

Government-to-Business

G2C

Government-to-Citizens

G2G

Government-to-Government

GOe

Global Observatory for eHealth

GUI

Graphic User Interface

HIS

Healthcare Information System

HTML

Hyper Text Markup Language

HTTP

Hyper Text Transfer protocol

ICT

Information and Communication Technology

IIS

Internet Information Server

IS

Information Systems

KR

Kurdistan Region X

Abbreviation

Description

LAMP

Linux Apache MySQL and PHP

LAN

Local Area Networks

M-Government

Manual Government

MOH

Ministry of Health

OPNET

Optimized Network Engineering Tool

PA

Patient Agents

PC

Personal Computers

PHP

Hypertext Preprocessor

SD

Server Delay

SL

Server Load

SNS

Social Network Services

SQL

Structure Query Language

TCP/IP

Transmission Control Protocol/Internet Protocol

TH

Traditional Health

TND

Total Network Delay

WAMP

Windows Apache MySQL and PHP

WBH

Web Based Health

WHO

World Health Organization

XML

Extensible Markup Language

XI

Chapter One Introduction 1.1 Overview Healthcare has been primarily concentrated in the hospital domain. With the current technology trends, some e-healthcare services have evolved. However, healthcare has not been accessible for the common man [1]. In general, hospital information systems are operated independently of each other. Medical institutions are developing devices for monitoring patients in hospitals, and for remote healthcare, by which patients can be treated at their homes [2]. Large-scale distributed systems, such as e-healthcare systems, are difficult to develop due to their complex and decentralized nature. The Service Oriented Architecture facilitates the development of such systems by supporting modular design, application integration and interoperation, and software reuse [3]. In modern healthcare, the use of web based electronic health system has increased remarkably because of its world-wide accessibility and the facility of the collaborative work among multiple users. Major drawbacks of such centralized web based system are link failure and low or no fault tolerance. In an unreliable network, it is common place that service is unavailable due to connection failure [4]. E-healthcare utilizes the latest information and communication technology (ICT) in healthcare. Electronic healthcare is becoming a vital part of our living environment and exhibits advantages over paper-based legacy systems. Privacy is the foremost concern of patients and the biggest impediment to e-healthcare deployment. In addressing privacy issues, conflicts from the functional

1

Chapter-1

Introduction

requirements must be taken into account. One such requirement is efficient and effective response to medical emergencies [5]. E-healthcare is the use of web-based systems to share and deliver information across the internet that is easy to disclose private data provided by customers. The private data has to be protected through proper authorization and access control models for e-health systems in a large health organization. Usage access control is considered as the next generation access control model with distinguishing properties of decision continuity. It has been proven efficient to improve security administration with flexible authorization management. Usage control enables finer-grained control over usage of digital objects that offers a better access control to private information in e-healthcare systems [6]. Although social network services (SNS) have high possibility as a communication tool, there are many problems as to the use of e-healthcare. It has too many functions and has difficult human interfaces for beginners. Moreover, how introducing a user to an SNS and retain the user’s motivation are important issues [7]. Nowadays, healthcare is one of the most important subjects in our life. Increasing the level of patients demand across the world obliges healthcare services in a more flexible and uniform manner so that patients can get useful health services in the home environment without going to the health center personally. The e-healthcare is a new kind of healthcare system and it is very popular at this time where patients can send their confidential information via internet to the organization and get services from the organization via internet. In this way, lots of time is saved and patients can get services efficiently without unnecessary harassments or travel to the organization [8]. Instead of being measured face to face, e-healthcare is a new promising technology that facilitates monitoring patients’ health related parameters continuously and in real time which reduces heavy dependence on specialized

2

Chapter-1

Introduction

healthcare staff and thus it is a desirable technique for countries that lack sufficient medical infrastructure and trained staff [9]. Ubiquitous technologies in e-healthcare systems are playing a vital role to perform a non-stop monitoring of patients’ health in hospitals or outpatient [10]. The e-healthcare systems are often interacting closely in cooperation with the physical environment and the surrounding people, where such exposure increases security vulnerabilities in cases of improperly managed security of the information sharing among different healthcare organizations. Hence, healthcare-specific security standards such as authentication, data integrity, system security and internet security are used to ensure security and privacy of patients' information [11]. E-healthcare is an emerging and promising healthcare system to meet the increasing medical demand from aging population. It requires extensive data storage, pervasive data access, and reliable computing resources to support the real-time communication of critical health information and the real-time diagnosis [12]. Information and communication technology (ICT) is not only beneficial for the business sector but also has a lot to offer for the public sector as well. In fact, the public sector can benefit the most by the advancement of ICT as it offers numerous potential benefits in terms of improvements for patients, health and elderly care professionals and decision makers [13]. With all of the difficulties that arising and related with increases quality of healthcare, there have been much research invested into providing healthcare in a manner such as to utilize all healthcare resources available efficiently (including caregivers' time) with the help of the rapidly evolving technology existing today. Research grants from private organizations and the government have given universities and research facilities the impetus to develop farreaching solutions to these ever growing problems to both specific diseases as well as provide general healthcare domain solutions[14]. 3

Chapter-1

Introduction

1.2 Literature Review

In 2007, Firat K.,G. Miao, L. E. Moser ,and P. M. Melliar [3], described a distributed e-healthcare system that used the Service Oriented Architecture as a basis for designing, implementing, deploying, invoking and managing healthcare services. The healthcare system that they had developed provided support for physicians, nurses, pharmacists and other healthcare professionals, as well as for patients and medical devices used to monitor patients. Multimedia input and output, with text, images and speech make the system more user friendly than existing e-healthcare systems.

In 2011, Jaya R., A. Das, and N. Iyengar [8], proposed a system in which the transaction of data was processed by Patient Agents (PA), Doctor Agents (DA) and Controller Agent (CA). The user can use the PA to connect with the controlling server of the e-healthcare system. The CA control the demand of the patients as well as the activity of the doctors. When the doctor wants to check-up the patient then he/she connects with the DA. Using the DA, every doctor prescribes some medicine to the patient about the query and, if required, refers the patient to another doctor. In the current study, the agent is computing in a network of workstations and forms a powerful paradigm for building distributed applications. The agent technology is used to fulfill the patient’s needs which include availability, speedy response, and efficiency. The agent in the ehealthcare creates connectivity on an anytime-anywhere-any-device basis to provide specific services required by the patients from the doctors.

4

Chapter-1

Introduction

In 2013, Oguntunde and Odim[15], offered a brief overview about a system which was designed by using a 3-tier internet service architecture consisting of a client tier (web browser), an application tier built on Apache and PHP, and a database tier running on MySQL. Each tier could be run either on a single machine. They presented a framework for the development of a web based information system for doctor’s directory. The system connected patients with medical specialists (consultants) in diverse areas of medicine, and provided information about the specialists; the patient could also secure an appointment with the specialists.

In 2014, Gheyath M. [16], proposed an e-healthcare system in which all prototypes were integrated in one homepage and connected by the hyperlink recommendation method. All tiered architectures namely single, two, and three have an important role in future Web-Based Healthcare (WBH) system and each of them can be used for different purposes in the Hospital/Clinic. The integrated WBH system or e-health system was proposed, designed and implemented using both Two-Tier Architecture (2TA) and Three-Tier Architecture (3TA) models.

According to the World Health Organization (WHO)and the Ministry of Health (MOH) of Iraq, the lack of computerized Healthcare Information System (HIS) in most Iraqi hospitals leads to poor data analysis and information flow within the hospital environment. Also, the healthcare system in Iraq is still centralized and hospital-based [17]. Based on that, this work aims to propose an Electronic Healthcare System (EHS) for healthcare and finds the performance of implementing such system on 2TA and 3TA.

5

Chapter-1

Introduction

1.3 Problem Statement This thesis focuses on the design and implementation of web healthcare system and evaluate its performance on both Two-Tier Architecture (2TA) and Three-Tier Architecture (3TA) with different operating systems; Windows and Linux. Modifying the semi electronic healthcare system to fully electronic healthcare system in Kurdistan Region (KR) is the main task of this system. Despite the advent of computer-internet or information communication technology (ICT), the system of the government in KR is still traditional system. This thesis deals with solving the problems of huge physical activity efforts for communication between the patients and healthcare-center staff. Hence solving the traditional healthcare (TH) problems that suffers from being a slow-paced process; besides , being health & safety, time and money consuming for the patients and TH-Centers with lots of untidiness, and paper work that effect unfairness of information delivery between them. The thesis will solve the real life problem by using technology.

1.4

Aims of Thesis

The aim of this thesis is to design and implement a proposed Electronic Healthcare System (EHS). Further, the thesis tries to compare the performance of implementing EHS by using heterogeneous platforms, These platforms are Windows and Linux, using the same hardware and application software. Such platforms can also be implemented by using 2TA and 3TA. Finally, the performance of implementing EHS on different architectures can be found depending on different tools such as Wireshark and OPNET.

6

Chapter-1

Introduction

1.5 Thesis Layout In addition to chapter one, the remaining part of this thesis consists of five chapters: Chapter Two: Is entitled” Background Theory”. This chapter contains the necessary information to understand the E-government types, components and new technologies of EHS. Chapter Three: Is entitled “Design and Implementation of the Proposed EHS”. This chapter

describes the general structure of the

design and related algorithms for the proposed EHS. Also, it deals with the implementation of the proposed system depending on the proposed design. Chapter Four: Is entitled “Performance Analysis of the Proposed EHS”. This chapter analyzes the performance of the proposed EHS with different architectures using a standard tool named Wireshark or the script code (PHP) over two operating systems Windows and Linux. Also, a professional evaluation and designing tool called OPNET has been addressed. Chapter Five: Is entitled “Conclusions and Future Work Suggestions”. In this chapter, a list of derived conclusions and remarks is given, in addition to some suggestions for future works.

7

Chapter Two Background Theory

2.1 Introduction The methodology related to e-healthcare systems will be addressed in this chapter together the system development method, knowing that the transformation from manual government to an electronic government is the demand. e-healthcare conversion is one of the e-government conversions that needs keeping tracks. The chapter will also deal with the models variation related to e-healthcare systems. E-healthcare‟s components, architecture and component-level design will be illustrated to have a wider view on the efficiency of e-health systems. Finally, the chapter will address two active evaluation tools; Wireshark (Network Protocol Analyzer) and Optimized Network Engineering Tool (OPNET) tools ; that will be used later for system evaluation.

2.2 Brief History of E-healthcare The term "e-health", coined in the latter part of the twentieth century, can already be found in around 4,000,000 Web pages. In the latter part of the nineteenth and early part of the twentieth century, medical applications were quick to derive benefit from the progress being made in the field of analogue telephony. The technology enabled not only individuals to call the doctor but also hospitals to transmit electrocardiograms over telephone lines. These were the early days of "tele"-medicine, or medical care delivered remotely. However, bandwidth limitations and the consequent low rate of data transfer over the copper wires then in use, coupled with interference and various types of noise, put a brake on the expansion of these analogue techniques. Since then, the boom in data digitization, computerization and digital networks witnessed in the mid8

Chapter-2

Background Theory

twentieth century has moved beyond telemedicine and has led to a multiplicity of e-health applications. These have emerged from academic research laboratories and have increasingly become part of people's everyday lives. Digital telemedicine has experienced tremendous growth over the past 25 years and is now a major component of e-health. It enables, among other things, the exchange of healthcare and administrative data and the transfer of medical images and laboratory results. Improvement in these processes has gone handin-hand with the technological progress that is generating ever higher bandwidths, greater storage and processing capacities, smaller and smaller components and higher levels of security. Different definitions have been used over time to designate ICT applications in the service of health. Around 1970, the term "medical informatics", was considered to be the state-of the-art technology, and was used to refer to the processing of medical data by computers. However, the importance of "information processing" was to be rapidly superseded by that of "information communication", as seen in the extremely rapid development of the internet.[18]

2.3 Approach of System Development An e-healthcare system integrates scattered healthcare data sources across heterogeneous network environments. The challenges of the data collection and data preparation functioning in e-healthcare system are huge, particularly in terms of integrating and communicating across systems and database boundaries. The application of e-healthcare system is based on the efficient data integration. e-healthcare system contains mostly unstructured texts that contain the patient‟s self description and structured medical data. The integration of unstructured text and structured data and data in other formats is the core of ehealthcare system development and application [19].

9

Chapter-2

Background Theory

2.4 Transferring from Manual Government to Electronic Government A common feature of e-government is the automation or computerization of existing paper-base procedures to enhance access to and delivery of government services to the citizens. More importantly, it aims to help strengthen government‟s drive towards effective governance and increased transparency for better management of resources, for growth and development. Nowadays, the best and more reliable approach to obtain information quickly in any field is the web. It is a very popular and excellent source of information, since the web developed most of governmental categories to electronic [20]. It is over a decade since the United Nations started assessing the global egovernment development through the initiative “Benchmarking E-government: Assessing the United Nations Member States” in 2001. Since then, there has been increasing evidence through public policy formulation and implementation that e-government, among others, has played an effective enabling role in advancing national development. At the same time, theUnited Nations EGovernment Survey has gained wide acceptance as a global authoritative measure of how public administrations provide electronic and mobile public services.The biennial edition of the United Nations E-GovernmentSurvey aims to exemplify successful e-government strategies, pioneering practices with a view towards administrative reform and sustainable development. The conceptual framework of the E-Government Development Index (EGDI) remains unchanged since its inception in 2001. Based on a holistic view of egovernment development, the methodological framework has remained consistent across Survey periods, while at the same time its components are carefully adjusted to reflect evolving knowledge of best practices in egovernment and changes in the underlying supporting ICT infrastructure, human capacity development and online service advancement, among other factors.

10

Chapter-2

Background Theory

2.5 Principles of Electronic Government In discussion, from the different tracks through which e-government services are delivered, four generic ones are well-known: Government-to-Business (G2B), Government-to-Citizens (G2C), Government-to-Government (G2G) and Government-to-Employee [20].

An e-government solution is a solution to

conduct government using technology, through an intra-, extra- or internet solution [21]. As shown in figure (2.1), e-government makes the interaction between government and citizens (G2C), government and business enterprises (G2B), and inter-agency relationships (G2G) more friendly, convenient, transparent, and inexpensive.

Figure (2.1) represents the participants in e-

government. [22].

Figure (2.1) The Participants in e-government

Figure (2.1) shows the four mentioned tracks are their relation to the proposed EHS is (G2C), as illustrated the e-government

creates links of

communication between the government and private individuals or residents. G2C communication most frequently takes place through ICTs, and can also include direct mail and media campaigns. G2C stands in contrast to G2B, a variety of e-government and operated by ICT where citizens interact with the government via the information of both the citizens and the government.

11

Chapter-2

Background Theory

To measure progress for e-government initiatives and to establish a road map to achieve the desired levels of constituency service, “Gartner‟s Four Phases of e-government Model” classifies e-government into four distinct phases. This can serve as a reference to position where a project fits in the overall evolution of an E-government strategy [23]: Stage 1: Presence – This stage is classified by a simple information-providing website of a passive nature, sometimes described as „brochure ware‟, indicating the same level of functions as a paper brochure. Stage 2: Interaction – The interaction stage offers simple interactions between governments and citizen (G2C), government to business (G2B), or government agency to government agency (G2G). Interaction stage websites provide e-mail contact and interactive forms that generate informational responses. Stage 3: Transaction – The transaction stage enables transactions such as paying for license renewals online, paying taxes or fees, or submitting bids for procurement contracts. Stage 4: Transformation – The highest stage, most closely aligned with the concept of governance, involves a reinvention of how government functions are conceived and organized.

2.6 Electronic Healthcare Systems E-healthcare is an online healthcare application and processing system that allows healthcare centers to advertise their information on EHS applications via the internet. Using a powerful medium like internet, patients no longer hassle for pre-visit & post-visit to healthcare centers in this enhanced era. From the relevant literature, the words e-healthcare, online healthcare, e-healthcare or 12

Chapter-2

Background Theory

internet healthcare are synonymous. Basically e-healthcare refers to the use of the internet to facilitate processes by advertising healthcare centers or contract applications electronically. It can be conducted using an organization‟s own corporate web site or a web-base healthcare site [24]. Over the past decades, there have been great advances in ICTs for health, and the World Health Organization (WHO) has responded by establishing the Global Observatory for eHealth (GOe) to assess the adoption of e-health in Member States as well as the benefits that ICTs can bring to healthcare and patients‟ well-being [25]. Healthcare systems are in a period of transition. Buffeted by rising costs and increasing demands for resources, many are flawed systems that need to be fixed. However, the challenges involved in this process have the potential to create many benefits, transformational solutions require the adoption of disruptive innovations that leverage technology. Data is translated into healthcare information that can provide meaningful insights to the provider, engage the consumer, and lead to connected care focused on prevention. Figure (2.2) illustrates the current healthcare landscape [26].

Figure (2.2): The Current Healthcare Landscape

13

Chapter-2

Background Theory

2.7 E-healthcare and the Related Variation Models Many models have been developed to handle e-healthcare requirements and needs, and they are considered as parts of e-government. Figure (2.3) shows the interaction between EHS and patients, healthcare center and the government. G2C or (EHS to patient), as illustrated in figure (2.3), covers the EHS supported by the government and run by the public sector. Thus, in public hospitals/clinic which adopts a EHS, with the support of the e- government, patient treatment takes less time, further, the system will reduce costs on patients as they can get full benefit of the system at home. Besides, it results in a better communication between patients and the healthcare staff. The system is more or less like G2C egovernment where communication between government and citizen is via internet or Local Area Networks (LANs) [16].

Figure (2.3) Models Variation related to e-healthcare

2.8 General E-Healthcare System Elements The five important components that must come together in order to produce an E-healthcare or Computer-Based Information System (CBIS) for healthcare [27]: 14

Chapter-2

Background Theory

1. Hardware: The term hardware refers to machinery. This category includes the computer itself, which is often referred to as the Central Processing Unit (CPU) capacity, and all of its support equipment. Among the support equipment are input and output devices, storage devices and communication devices. 2. Software: The term software refers to computer programs and the manuals (if any) that support them. Computer programs are machine-readable instructions that direct the circuitry within the hardware parts of the CBIS to function in ways that produce useful information from data. Programs are generally stored on some input/output medium, often a disk or tape. 3. Data: Data are facts that are used by programs to produce useful information. Like programs; they are generally stored in machine-readable like a disk or a tape until the computer needs them. 4. Procedures: Procedures are the policies that govern the operation of a computer system. 5. People: Every CBIS needs people if it is useful. Often the most over-looked element of the CBIS is the people, probably the component that most influences the success or failure of information systems. In the following some e-healthcare basic terms are defined with frontend, Middleware, and Backend. Figure (2.4) shows the main parts of adopted architecture of an established EHS.

Figure (2.4) Architecture of the developed web based application 15

Chapter-2

Background Theory

2.8.1 The Web Users put material on the web and retrieve information from it any time they want. The web consists of an enormous collection of documents in different formats, located on computers worldwide. These documents are created by academic, professional, governmental, and commercial originations, or are created by individuals. The server allows retrieving documents to each computer that provides web server. A web communication medium consists of the following elements [28]: 1. Servers: Continually running programs that serve information to the web. 2. Clients: Web browsers that allow users to access the web. 3. Protocols: The Hypertext Transfer Protocol (HTTP) that web clients and servers use as well as Transmission Control Protocol/Internet Protocol (TCP/IP) on which HTTP depends. 4. Documents: Web pages, mostly coded in HTML that supply information on the Web. 5. Networks: connected devices to a local area network and a wide area network with the form of Internet.

2.8.2 Web Server and the Related Technologies A Web server is a program that uses the client/server model and the World Wide Web's Hypertext Transfer Protocol (HTTP) serving the files from Webpages to web users (whose computers contain HTTP clients that forward their requests) [29]. Every computer on the Internet that contains a Website must have a web server program. It can be seen across a network as an IP address (e.g. 192.168.2.23) and possibly domain name (e.g. http//domainname.com). Two

16

Chapter-2

Background Theory

leading Web servers are Apache and Microsoft's Internet Information Server (IIS). The meaning of web services is exactly web technology such as; Windows Apache MySQL and PHP (WAMP) and Linux Apache MySQL and PHP (LAMP). The WAMP Platform is a multi-tier enterprise application: the web server tier, PHP programming tier, database server tier and business logic tier. WAMP as a group software often used to build dynamic Websites or server, which is a separate program but because it is often used together with an increasing compatibility, it constitutes a powerful Web application platform [30]. LAMP is a popular setup for Ubuntu servers. There is a plethora of open source applications written using the LAMP application stack. Some popular LAMP applications are Content Management Systems and Management Software such as phpMyAdmin. One advantage of LAMP is the substantial flexibility for different database, web server, and scripting languages. Popular substitutes for MySQL include PostgreSQL and SQLite. Python, Perl, and Ruby are also frequently used instead of PHP [31].

2.8.3 Web Browser The client-side is the simplest part of the system because client-side PHP is completely unnecessary, unless to code something like a real-time chat program. Thus, the only thing the client should be concerned with is the web browser, that is the applications need to render in the browser such as Hypertext Markup language (HTML). HTML provides a set of tags that describe the layout of the Webpage, but most browsers accept more than HTML and the only alternative of HTML is XML. Originally, enabling technology of describing “mark up” languages lets one define one‟s own tags [32]. 17

Chapter-2

Background Theory

2.8.4 PHP and MySQL Currently, the complex question is about the reason of using PHP and MySQL? (PHP) and MySQL belong to a class of software known as an open source. This means that the source code to any application is available to anyone who wants to see it or make use of an open source development model, which allows anyone interested to participate in the development project. PHP is extremely useful to embed dynamic text into static text. The following advantages of PHP and MySQL are strong motives behind their utilization in developing various web-applications [29]:  It is fast and easy: PHP has managed the perfect mix of power, and it is easy to use and learn. It offers the best opportunity to develop powerful web applications; furthermore common may be an excellent reasons for choosing PHP. PHP users believe the syntax of PHP is superior to those of Active Server Page (ASP) and JavaScript Page (JSP).  It is cross-platform: In the rundown of web architecture, PHP run on windows and UNIX and with both IIS and Apache, but the cross-platform abilities of PHP work on a wide variety of systems as any other available products for example Linux, UNIX and etc.  It accesses everything: whatever the web-designer needs to use. It is more than likely that PHP has a built-in set of functions that makes getting whatever the designer need very easy. That means, it is easier than other products and supports most of the platforms.  It is constantly being improved: users employing the open source development might be surprised by the quality of the software and the variety of developers looking to improve the product. MySQL is also improving at amazing rates and works on many different platforms  It is free to download (without any cost): Linux, Apache, MySQL and PHP are completely free, that means users install and use it and pay 18

Chapter-2

Background Theory

nothing in the process. Free download or install make PHP a popular software. MySQL is a program that can store large amounts of information in an organized format that is easily accessible from scripting languages. The MySQL software delivers a robust SQL database server.  It is cost effective: The oracle installation cost is incredible, there is no doubt that Oracle, Sybase, and Informix create terrific databases, but the cost involved is prohibitive for many and MySQL free.  It is quick and powerful: MySQL may not have every bell and whistle for relational database, but for most users, there is plenty (for example, creating a moderately size commerce site).

2.9 Component-Level Designing and Architectures In the following subsections, some of the modern design models of the software application are illustrated.

2.9.1 Two-Tier Architecture (2TA) The 2TA actually has three parts; a client, a server, and a protocol. The protocol bridges the gap between the client and server tiers. The 2TA design is very effective for network programming as well as for Graphic User Interface (GUI) programs. The 2TA is an architecture where a client presents a GUI to the user and uses the user‟s data entry and actions to perform requests of database server which is running on a different machine. Any application is running on two computers; for instance a typical Web Common Gateway Interface (CGI) application that runs on a web browser (client) and a web server, has two tiers. 2TA consists of two layers: client and server, see figure (2.5). The 2TA design allocates the user system interface exclusively to the client. It places database managements on the server and splits the processing management between client and server, creating two layers. A 2TA refers to client/server architecture in 19

Chapter-2

Background Theory

which the user interface runs on the client and the database stored on the server. The more actual application logic can run either on the client or the server. In figure (2.5), the presentation and processing components are grouped on the client side with access to shared data resource using a network connection. This works well with the single database and secures fast networking .

Figure (2.5) Two-Tier Architecture

There are few benefits in using the 2TA. The first benefit is that application development in the distributed environment is much quicker than the older legacy environment. The second benefit is that the tools available for 2TA development are relatively easy to learn and quite robust. Other advantages include supporting prototyping and rapid development techniques and being able to work well in static environments. There are some limitations in the two tier model, they include the lack of scalability, to effectively scale up to thousands of users (only suitable for up to hundred of users), and its difficulty to maintain, changes the application logic need to be distrusted to all clients, also the 2TA can be difficult to administer and maintain [28].

2.9.2 Three-Tier Architecture (3TA) The main reason for developing three-tier architecture systems is the incapability of the 2TA. Designers avoid using 2TA because if the user likes to scale up to larger projects in the future, the 2TA approach is not enough and 20

Chapter-2

Background Theory

usually results in an ineffective system, as the server becomes weighted down with users. To properly scale to huge numbers of users, it is usually necessary to move to 3TA, see figure (2.6). With this architecture type, elements presentations, processing and data are fully separated. Presentation components manage user‟s interaction, and request application (processing) services by calling the middle tier components, and these components make requests to database.

Figure (2.6) Three-Tier Architecture

As the complexities and security requirements of a company increase, IT specialists move to 3TA or more. The front-end is still the user's desktop PCs, but the server function is divided into two (or more) parts. 3TA application designs can be used as a proper solution for different types of distributed applications; as an example, consider the issue of website development. Basically a three tiers e-healthcare architecture includes: A. Database (Data tier, MySQL database). B. A web server (Application tier, PHP). C. Web browsers (Client tier, Users of the site).

Figure (2.7) shows the relationship between the elements of three tiers EHS architecture. Using 3TA leads to a system having the following advantages: [28]

21

Chapter-2

Background Theory

A. Load balancing: if the server is getting more requests then it can handle, then it‟s possible to locate the server side processing on another machine. B. Better security: data protection and security are simpler to obtain, therefore it makes sense to run critical business processes that work with security sensitive data on the server. C. Maintenance: alteration to the components of the server is faster and easier to achieve for numerous Personal Computers (PCs). 3TA is more maintainable than the 2TA. The following are disadvantages of 3TA: A. It is more complex structure B. More difficult to set up and maintain it as well C. The physical separation of application servers containing business logic functions and database servers containing databases may moderately affect performance.

Figure (2.7) E-healthcare Three-tier architecture

2.10 Wireshark (Network Protocol Analyzer) Wireshark tool is a network packet analyzer used to capture the packets during live migration. The captured packets are stored in the Wireshark tool and can be used for the analysis. The following are some of the many features Wireshark provides [33,34]: 22

Chapter-2

Background Theory



Available for UNIX and Windows.



Capture live packet data from a network interface.



Display packets with very detailed protocol information.



Open and Save packet data captured.



Import and Export packet data from and to a lot of other capture programs.



Filter packets on many criteria.



Search for packets on many criteria.



Colorize packet display based on filters.



Create various statistics.

2.11 Optimized Network Engineering Tool (OPNET) Tool OPNET Technologies Inc. is a software business that provides performance management for computer networks and applications. The company was founded in 1986 and went public in 2000. It is head quartered in Bethesda, Maryland and has offices in Cary, North Carolina; Nashua, New Hampshire; Dallas, Texas; and Santa Clara, California. It has international offices in Slough, United Kingdom; Paris,France; Ghent, Belgium; Frankfurt, Germany; and Singapore with staff and consultants in multiple locations in Asia and Latin America[35]. OPNET is a high level event based network level simulation tool. Simulation operates at “packet level”, originally built for the simulation of fixed networks. OPNET contains a huge library of accurate models of commercially available fixed network hardware and protocols. Nowadays, the possibilities for wireless network simulations are also very wide. The simulator has a lot of potential, but there exists typically a lack of the recent wireless systems. Much of the work considering new technologies must be done by oneself. OPNET can be used as a

23

Chapter-2

Background Theory

research tool or as a network design/analysis tool (end user). The threshold for the usage is high for the developer, but low for the end user [36]. The OPNET is a very powerful network simulator. Main purposes are to optimize cost, performance and availability. The goal of this tool is to learn the basics of how to use Modeler interface, as well as some basic modeling theory. The following tasks are considered: • Build and analyze models. • Configure the object palette with the needed models. • Set up application and profile configurations. • Model a LAN as a single node. • Specify background utilization that changes over a time on a link. • Simulate multiple scenarios simultaneously. • Apply filter to graphs of results and analyze the results[37].

24

Chapter Three Design and Implementation of the Proposed EHS

3.1 Introduction The two main parts of the system preparing (design and implementation) will be explained in this chapter. In general the proposed system has been designed with 2TA and 3TA. The system requirements are also addressed here with its two parts (software and hardware), and the features of used hosts addressed here too. The establishment steps of the e-healthcare system is addressed with the related algorithms of the system. In order to explain the activity of the proposed system, the implementation steps of the proposed system will be described in relative with the associated design-steps.

3.2 Structure of the Proposed EHS Any electronic system must be designed according to known rules which can be called standard rules. One of these rules, is the architecture of the system that will be the core of the general structure to build the related algorithms. Firstly, there was 1TA that depends on the features of the mainframes whereas the have been represented by terminals. After that other architectures have been appeared; like 2TA (i.e. using one host as a server and many hosts as clients), also 3TA (i.e. using two hosts as servers and many hosts as clients). The rank of the architecture can be increases by increasing number of the servers, either in cascade direction by connecting more than two servers serially (splitting the database system into sequence of continued parts), or in cascode direction by

25

Chapter-3

Design and Implementation of the Proposed EHS

connecting more than two servers in parallel (splitting the database system into many parts of on level stage). The proposed system is designed to run either on 2TA or 3TA (because there is no need to 1TA). Both tiered architectures are client/server base networked computers with any network scales. There are several areas of concern when first setting up E-healthcare system: Back-end, Application Data and Front-end. In 3TA systems, the step that has the highest priority in the system establishment schedule is the design of back-end module because most of the errors in the systems return to the inaccuracy of the back-end module. MySQL is an outstanding tool to implement the database system. It is prefer to test the ability of operating such these systems with more than one operating systems. Because of that the most famous OSs nowadays in Kurdistan are Windows and Linux, so these OSs have been depended in this proposed system (taking in consideration that these OSs may be used by other works that done Kurdistan). All electronic healthcare (EH) pages are built using HTML, CSS, AJAX, JavaScript and JQuery in a client-side, while the PHP acts as an interpreter for the server side with Window-7 OS as a server using WAMP application, and for Linux- Ubuntu 14.04 OS as a server using LAMP application. Figure (3.1) shows 2TA and 3TA architectures, PHP has been depended as an easy language that could be used to handle requests between the web application software and the database system. Figure (3.2) shows the basic phases of the established EHSs.

26

Chapter-3


Used Tier Architectures

Two-tier Architecture

Client Web browser

C/S Based

Client Web browser

Fat Two-tier architecture

Three-tier Architecture

Middleware (PHP + Apache)

Database Server (MySQL)

Thin Two-tier architecture

Middleware (PHP + Apache)

Figure (3.1): 2TA and 3TA Architectures

27

Database Server (MySQL)

Chapter-3


Figure (3.2): Basic phases of the establishment of proposed EHS

3.3 System Requirements Interface Every electronic system needs requirement of both of software and hardware parts. It is prefer to have two different types of computers; the servers-side computers must be more powerful than those of clients-side (but if the clienthosts are powerful too, it is not a problem). So, it is necessary to describe all software and applications used for designing the proposed system. Also, all hardware equipment features depended for the proposed system machinery must be described. The system is implemented using hosts with different features in order to provide more practical applications and to be close to the real situation.

Software required for windows- 7 used of the EHS:  Development server:WAMP(W:Windows platform,A: Apache HTTP server,M:MySQL,P: PHP)  Operating System: Windows-7

28

Chapter-3

   


Backend: (Database) MySQL Frontend: HTML, Ajax, JQuery, CSS and JavaScript Server Side Scripting Language: PHP Applications:Text Editor sublime, Almost any web browser, Wireshark,OPNET.

Software required for Ubuntu 14.04 used of the EHS:  Development server: LAMP (L: Linux platform,A: Apache HTTP server,M:MySQL,P: PHP)  Operating System: Ubuntu 14.04  Backend: (Database) MySQL  Frontend: HTML, Ajax, JQuery, CSS and JavaScript  Server Side Scripting Language: PHP  Applications:Text Editor sublime, Almost any web browser, Wireshark,OPNET. Host’s features depended in implementing of the EHS: 1- Server host:A-Server-one(Application Server)    

CPU: Core(TM) i5-4200U CPU 2.30 GHZ Architecture: 64 bits RAM: 8GB HD: 1000GB

B-Server –two(database server)    

CPU: 2.30 GHZ Architecture: 64 bits RAM: 8GB HD: 1000GB

2-Client hosts:   

CPU: Pentium(R) dual-core CPU 2.60CGHZ Architecture: 64 bits RAM:3GB HD:256 GB

29

Chapter-3


Required features of communication equipment used for the EHS: 1- properties of HUB Switch  Name: TP-Link  Number of Ports:24 ports  Speed: 10/100 Mbps 2- properties of Cable:  Type: UTP-CATE5E  Maximum Length: 25 meter  Connector:RJ-45

The hardware part consists of two sub-parts; first part is related to the servers-side and the other relates to the clients-side. Servers-side can be organized into two structures; either consisting of one host which contains both of application tier and the database tier (2TA) as shown in figure (3.3); or consisting of two hosts (3TA) as shown in figure (3.4). First host is specified for the application tier and the other specified for database tier. These servers must connected directly via a cable within same room provided with special conditions. The servers-side must be connected with the clients-side via Internet. The clients-side hardware consists of two parts internal and external clients. There are a number of hosts (let equals m1) of Internal-clients. Certainly, the hosts are to be inside the hospital/clinic and specified for: administrator, doctors, pharmacies, x-ray, laboratory, and receptionist. The Internal-clients are connected to the servers-side via internet may be by cables when dealing with short distances. Hence, there is a number of hosts (let equals m2) to work as External-clients. These hosts are basically outside of the hospital/clinic and specified for external users (almost all are patients). These External-clients are connected to the servers-side via Internet.

30

Chapter-3


Figure (3.3) Hardware part of EHS proposed system 2TA

Figure (3.4) Hardware part of EHS proposed system 3TA

31

Chapter-3


3.4 Proposed System Services and Related Algorithms The proposed EHS system site consists of several services provided by related modules. This structure is depended on the real field research in a local hospital called (“Private Soma Hospital” which is located in Sulaimani/ Kurdistan). These modules are illustrated in figure (3.5).

Hospital Services

Doctor’s information

Labs Information Lab1: Hematology Lab2: Biochemistry Lab3: Cytology Lab4: Biology

Pharmacy Information

X-ray Information X-Ray1: Floroscopic

Pharmacy1

Reception informatio n Patient registration

X-Ray: UltraSound

Pharmacy2

X-Ray: General X-Ray4: CT scan X-Ray: Panoromic X-Ray6:Mammography

Patient register for emergency

Administrator

Main Administrator Full control overall the system (add, delete, edit) patients, doctors staff and subadministrators information

Semi Administrators Control the pharmacies management add, delete, edit drugs

Figure( 3.5) Proposed system services

32

Chapter-3


The established web-healthcare site consists of seven modules: patient‟s module, doctors module, pharmacies module, x-ray module, laboratories module, receptionist module and administrator(s) module. Figure (3.6) shows the main EH page of the established EH prototype.

Figure (3.6) The main window of EHS

However, below represents general steps of the proposed system. General Steps of Proposed System : Step1

:

Start with hospital services

Step2

:

Is the patient has been registered before? Yes: go to step 5

Step3

:

Do the patient want to register? No: end

Step4

:

Start registration phase

Step5

:

Start login to the system

Step6

:

Display provided services for patients including (get appointment, display previous appointments and treatments, update personal information)

Step7

:

Get new appointment? No: end

Step8

:

Appointment phase

Step9

:

Diagnosis phase including (meeting doctor, labs, X-ray, pharmacy …)

33

Chapter-3


Step10 :

Treatment phase

Step11 :

Is the case need re diagnosis Yes: go to step 7

Step12 :

End

3.4.1 Patient Module Patients that have registered before and remembered their username and password can login to the EHS; otherwise the patient must fill one of the two forms namely; registration form or forget password form. Then, the patient is simply able to login to the system and see the whole patient‟s member facilities (such as get appointment, cancel appointment, display diagnosis, edit personal information and logout). Steps below represents the patient‟s module. Steps of Patient Module: Step1

:


Step2

:

Is the patient has been registered before? Yes: go to step 5

Step3

:

Do the patient want to register? No: end

Step4

:

Start fill registration form

Step5

:

Start login to the system using username and password

Step6

:

Step7

:

Is the patient used correct username and password? Yes: go to step 8 Is the patient forgetting the password? Yes: fill a form, to get password by email automatically, then go to step5

34

Chapter-3


Step8

:

Step9

:

Step10 :

Display provided services for patient including (Get appointment, Cancel appointment, Display diagnosis, Edit personal information, Logout) Is the patient want to use any services? Yes: select the service and do as required End

3.4.1.1 Implementation of Patient Module At the patient module, before anything the patient must register himself which browsed at patient login window, as shown in Figure (3.7).

Figure (3.7): Patient login window

(a) Implementation of Patient’s Sign up Form The registration of the patient will start with filling the patient-information form as shown in Figure (3.8). The confirmed information will be created and stored in the database; thus, he/she becomes a registered patient to the system. Figure (3.9) shows a successful registration message to patient.

35

Chapter-3


Figure (3.8) Patient registration window

Figure (3.9) The message of patient successful registration

After the successful registration, the patient enters the username and password, the PHP script compares them with those in the database. If there a matching, the script reads the patient detail‟s including (patient username and password) and then logs in. Then the patient can see all of the related

36

Chapter-3


hyperlinked options: Get appointment, Cancel appointment, Display previous diagnosis, Edit personal information, Logout. Figure(3.10) shows a successful login to the system.

Figure (3.10) Patient homepage

If the username and password are incorrect, then the system will not permit the user to login, and prompts a message to let the user know that login failed.

(b) Implementation of Get/Cancel appointment Without going to the healthcare center, the patient will be able to get an appointment with the desired doctor depending on the available date and time for the doctor scheduling. At the same time the patient has the ability of cancelling any appointment and get any other available appointment (if it is necessary). Figures (3.11 and 3.12) represent getting and Cancelling appointment respectively.

37

Chapter-3


Figure (3.11) Get appointment window

Figure (3.12) Cancel appointment page

Figure (3.11) Get appointment page

Figure(3.12)cancel appointment page

38

Chapter-3


(c) Implementation of Patient’s Diagnosis The patient has the authority of displaying any previous executed appointment, view the diagnosis in addition to the test results, X-rays, and drugs if any. Figure (3.13) shows the patients previous diagnosis.

Figure (3.13) Patients previous diagnosis details

(d) Implementation of Edit Information The patients can edit his/her information except the username. Figure (3.14) shows the edit patients personal information page.

Figure (3.14) Edit patient’s personal information

39

Chapter-3


(e) Implementation of Forgot Password If for any reason the password has been forgotten, the user (patient) should click on the hyperlink “Forgot your password, if there is matching then the password will be sent to the user-email automatically. This option is the same for all users. Figure (3.15) shows the forgot password form.

Figure (3.15): Patients forgot password window

Logout Any user should quit the system via logout option which is necessary for the security purposes. This is the same for all users and returns them to the homepage.

3.4.2 Doctors Module The doctors are registered to the system by the administrator. In case the doctor forgot username or password must notify the administrator to get username and password back. Upon successful login, the doctor can view all member facilities such as (display appointments, laboratories section, x-ray sections, medical prescription, patients history diagnosis, logout the system).

40

Chapter-3


The attractiveness of the proposed system is that the doctor can connect to each of these facilities by a single click. Steps below represents the doctor‟s module. Steps of Doctors Module : Start with hospital services Start using specialist username and password that created by the administrator to enter the system Is the specialist doctors used correct username and password? Yes: go to step 5

Step1 Step2

: :

Step3

:

Step4

:

Is the specialist doctor forgetting the password? Yes: fill a form, to get password by email automatically, then go to step 2

Step5

:

Display provided services for the specialist doctor including (Display daily appointments, Laboratories, X-ray department, medical prescription, Previous diagnosis, Logout)

Step6

:

Is the doctor have to use any services? Yes: select the service and do as the services required

Step7

:

End

3.4.2.1 Implementation of Doctors Module The doctor side holds two hyperlinks; Login and Forgot Password. each link helps the doctors to transfer to other webpages to do specific task(s).

(a) Implementation of Doctor Login The pre-registered doctor can get access to the system through the login web page, login doctor and other modules (Laboratories, X-rays, Pharmacies, Receptions) same login to the system, as shown in figure (3.16) .

41

Chapter-3


Figure (3.16): Doctor login window

(b) Implementation of Daily appointments When the username and password of doctor login window are correct, the window shown in Figure (3.17) will be browsed. The doctor will be able to view a list of all his/her daily appointments booked by patients. The booked appointments by patients immediately transfers to database and daily appointments displays all today appointments.

Figure (3.17): Daily doctor appointment

42

Chapter-3


(c) Implementation of Laboratory department: There is an online form that fill-in by doctor and send it to laboratory via internet. The test-form reach to laboratory before the patients arrives. It is an excellent communication between laboratory and doctor without any papers and safe time. The results of any test should be sent back to doctor via Internet or a copy of the results can be given to the patient. Figure (3.18) shows the appointment reservation for patient testing laboratory

Figure (3.18) Appointment for patient in Laboratory

(d) Implementation of X-ray department: After reserving appointments for the patient in X-ray department; the doctor can display daily X-rays taken for patients, these results help the doctor to make the diagnosis and making decision about patients. Figure (3.19) shows the Appointment for patient in X-ray department.

43

Chapter-3


Figure (3.19) Appointment for patient in X-ray department

(e) Implementation of medical prescription Doctor can write a conclusion report diagnosis about the patients. Hence, selecting the specific pharmacy where the patient can get drugs from pharmacy. The doctor makes diagnosis directly based on patient symptoms if no need for tests, if needs the test for x-ray and laboratories the doctor send patient to lab and x-ray after return the result the doctor write diagnosis report. Figure (3.20) shows the medical prescription for patient.

44

Chapter-3


Figure (3.20) Medical prescription for patient

(f) Implementation of Previous diagnosis The doctor can reach the specific patient by making a search of patient ID (username) or diagnosis date. The doctor can display the diagnosis with any other appended results from labs and X-rays, which gives more information about the patient case. Figure (3.21) shows search for patient previous diagnosis.

45

Chapter-3


Figure (3.21) Search for patient previous diagnosis by doctors

Logout: The necessary for the security purposes and it is the same for all users and returns them to the homepage.

3.4.3 Laboratories Module Because of that laboratory staff are also employees, for this module there is no need to repeat the login and forgot password steps as illustrated in doctors module. Below represents the steps of laboratories module.

Steps of Laboratory Module : Step1

:


Step2

:

Start using username and password that created by the administrator to enter the system

Step3

:

Is the laboratory doctor used correct username and password? Yes: go to step 5

46

Chapter-3


Step4

:

Is the laboratory doctor forgetting the password? Yes: fill a form, to get password by email automatically, then go to step 2

Step5

:

Display provided services for the laboratory doctor including (Display daily appointments, Edit personal information, Logout)

Step6

:

Is the laboratory doctor have to use any services? Yes: select the service and do as the services required

Step7

:

End

3.4.3.1 Implementation of Laboratories Module The system allows laboratory staff to access the EHS and view the whole laboratory‟s member facilities such as (Daily appointment, Edit personal information, Logout), after entering the correct username and password. Below are some LABs and tests that mentioned in this thesis (hematology lab, biochemistry lab, cytology lab, biology lab), all labs are special username and password. The daily appointments reserved for patients that by the doctors for each lab are displayed. Hence, the LAB-staff will select the patients whose name exists in the reservation list and calls When the test is completed, the labdoctor will enters

results into the database. This authority provides some

facilities for lab-doctors. Figure (3.22) shows the four LABs addressed in this thesis.

47

Chapter-3


Hematology Lab

Biochemistry

Cytology Lab

Biology Lab

Figure (3.22) Laboratories homepage

3.4.4 X-ray Module The proposed system allows x-ray employees to access the EHS and view the whole x-ray‟s member facilities such as (daily appointment, edit personal information, Logout), after entering the correct username and password. Below represents the steps of X-ray module.

48

Chapter-3


Steps of X-ray Module : Step1 : Start with hospital services Step2 : Start using username and password that created by the administrator to enter the system Step3 : Is the radiographer used correct username and password? Yes: go to step 5 Step4 : Is the radiographer forgetting the password? Yes: fill a form, to get password by email automatically, then go to step 2 Step5 : Display provided services for the radiographer including (Daily appointments, Edit personal information, Logout) Step6 : Is the radiographer have to use any services? Yes: select the service and do as the services required Step7 : End

3.4.4.1 Implementation of X-ray Module The option includes information about x-ray type and the body part recommended by the doctor. When the x-ray finish, the radiologist enters his report to the database. The radiologist will uploads the x-ray image to the server that can be displayed by the doctor and the patient as well, the radiologist select the patient in order for taking x-ray. Figure (3.23) shows the list of the daily patient appointments for x-ray.

49

Chapter-3


Appointment for X-ray

Figure (3.23) Appointment’s patient for X-ray

3.4.5 Pharmacy Module This section includes both of algorithm of pharmacy module and the implementation of this module, the system proposes two pharmacy section (namely pharmacy-1 and pharmacy-2 ) dedicated to prevent traffic on the network. The pharmacy‟s module mechanism is illustrated in the steps below. Steps of Pharmacy Module: Step1 : Start with hospital services Step2 : Start using username and password that created by the administrator to enter the system Step3 : Is the pharmacist used correct username and password? Yes: go to step 5 Step4 : Is the pharmacist forgetting the password? Yes: fill a form, to get password by email automatically, then go to step 2 Step5 : Display provided services for the pharmacist including (Display daily patient list, patient list in period, Logout) Step6 :

Is the pharmacist have to use any services? Yes: select the service and do as the services required

Step7 :

End

50

Chapter-3


3.4.5.1 Implementation of Pharmacy Module Displaying daily list includes the name of all patients recommended by the doctors to get medicine in the appropriate pharmacy with all the related information for the individual patient. The information includes: patient name, doctor name, medicine name, dosage, times per day, total price and a confirm button. This button is used by the pharmacist after giving the prescription to the patient to close his/her status and subtract the medicines from the total stored medicines. Hence, the system will prepare a copy of the consumed (sold) medicines in a suitable medicine-table related to that pharmacy to be used later for statistics purposes. Figure (3.24) shows the pharmacy‟s daily list of patient for medicines.

pharmacy-1

Figure (3.24): Pharmacy daily patients list for medicines

Also, there is an option called patient list in period that enables the pharmacist to display patient lists in period of date. Adding to that the pharmacist will have full view about the patients who got his medicines in the same day, the pharmacist can displays a list for previous days to know which of the patients did not get his/her medicines for any reason, Figure (3.25) shows the patients in a list like records or medicine documentation.

51

Chapter-3


pharmacy-1

Patient list in period Figure (3.25): Pharmacy patients list for medicines in period

Figure(3.25):Pharmacy patients list for medicines in period

3.4.6 Receptionist Module The receptionist job location is in the information desk within the main building gate. All details of this module mechanism are shown in steps below. Steps of Receptionist Module: Step1 : Start with hospital services(reception side) Step2 : Start using employ username and password that created by the administrator to enter the system Step3 : Is the employer used correct username and password? Yes: go to step 5 Step4 : Is the employer forgetting the password? Yes: fill a form, to get password by email automatically, then go to step 2 Step5 : Display provided services for the employer including (patient registration, patient registration for emergency) Step6 : Is the employer have to use any services? Yes: select the service and do as the services required Step7 :

End

52

Chapter-3


3.4.6.1 Implementation of Receptionist Module The reception and Information face to face are traditional healthcare system, the position of reception is at the main door of the building of healthcare center. The reception module has a great role for guiding patients and new staff in providing a assistance to those patients who have difficulties finding specific place in the healthcare center.

(a) Implementation of Patient registration Receptionist to register for those patients who cannot registered to the system because they are not familiar with the system or those who got difficulties in registration. The receptionist either assists patients in registration, or registers the patients and give him/her the username and password for next login to the system. Figure (3.26) shows the registration form by receptionist to patients.

Patient registration of Receptionist

Figure (3.26): Patient registration by receptionist

53

Chapter-3


(b) Implementation of emergency registration for patient Patients with emergency cases or accidents attend to healthcare centers the receptionist immediately fill in a form for any patient attending the emergency department. This option is used for the reason of statistics by the system; for example, to know the percentage of patient‟s visits to the emergency department. . Figure (3.27) shows the registry form for emergency patients.

Emergency registration

Figure (3.27) Emergency registration by receptionist

3.4.7 Administrator Module The pre-registered pharmacist can get access to the system through the login webpage all the steps for controlling

integrated web-healthcare system by

administrator module. Below represents the steps of administrator module. Steps of Administrator Module: Step1

:

Start with username and password

Step2

:

Are the username and password are correct? No: go to step 1

54

Chapter-3


Step3

:

Are all privileges available?

Step4

:

Yes: go to step 11

Step5

:

Start the authority of co-admin (Pharmacy Admin)

Step6

:

Add, delete and edit drugs information

Step7

:

Entering incoming drugs bills

Step8

:

Add and delete drugs categories and providers

Step9

:

No Display pharmacy statistical reports

Step10 :

Go to step 14

Step11 :

Add, delete and edit patients, staff and sub-administrators

Step12 :

Manage pharmacy department

Step13 :

Display statistical reports in PDF type

Step14 :

End

3.4.7.1 Implementation of Administrator Module The administrator module is the backbone of every website and excellent role in the security of the sites. There are two different types of admin in the proposed system; the first one is the main admin and the other is the semiadmin. The main admin controls all the integrated website models with full privileges, but the semi-admin holds partial privileges. All the main- admin and semi-admin have same login page but with different username and password. Figure (3.28) shows the administrator login .

55

Chapter-3


Figure (3.28): Administrator login page

The main admin has full privileges that provide full controlling the overall integrated modules system. It can make changes within the modules; staff, patients, Doctors information activities (i.e. change ID/Password). Figure (3.29) illustrates the privileges associated with the main admin in the integrated webhealth.

Figure(3.29): Main administrator

The semi-admin has limited privileges only related to pharmacies it can control of drugs information such as add new drugs and delete drugs. Figure (3.30) partial privileges are used in the semi-admin authority in pharmacy module.

56

Chapter-3


Figure (3.30) Semi-admin homepage(pharmacy)

3.4.8 Contact us In the proposed system the „Contact us‟ hyperlink let patients and staff write their suggestions regarding the healthcare center or system, are much better than the traditional comment and suggestion box, because it is much faster than the traditional one. The sending message for the administrator this helps the EH to improve their weaknesses and help the evaluation purposes. Figure (3.31) shows the Contact us.

Figure (3.31) Contact us form

57

Chapter-3


3.5 Structure of the Established Database The established database interacts with the webpage dedicated to the individual systems (i.e., patients, doctors, pharmacies, x-ray, laboratories, reception(s),and administrator(s).The database (backend) is one of the important and major components of the established EHS system. Figure (3.32) shows the list of tables of the established EHS which comprises twenty seven tables. Table (3.1) describes the specifications of these twenty seven tables. The relationship among these tables with their structures are illustrated in Appendix-A.

Figure (3.32) EH database tables

58

Chapter-3

Design and Implementation of the Proposed EHS Table(3.1)The specification of the data base tables

No.

System activity

DB Name

Table Name

Description Contains data about the

1

Doctor prescription

hospital system

doctor_prescription

medical treatment and the pharmacy name.

2

Patient diagnosis

hospital system

doctor_diagnosis

Contains details on the patient’s disease. Contains necessary data on

3

X-ray department

hospital system

xray_section

any patient having an appointment in X-ray section Contains necessary data on

4

Ultra sound department

hospital system

xray_section_ultraso

any patient having an

und

appointment in ultra sound section

5

Patients information

hospital system

patient_info

Contains data on patients’ information. Contains data on

6

Staff information

hospital system

staff_info

hospital/clinic staff information. Contains necessary data for

7

Get appointments

hospital system doctor_appointment

getting appointment with specific specialist in specific dates Contains necessary data on

8

Laboratories department

hospital system

biochemistry_lab

any patient having an appointment for a test in this lab

59

Chapter-3

9



hospital system

biochemistry_lab_res

Contains necessary data on

ults

any patient with test result Contains necessary data on

10


hospital system

biology_lab


11


hospital system

biology_serology_res

12

Laboratories department hospital system

biology_verology_res

13


biology_widal_res

Contains necessary data on any patient with test results Contains necessary data on any patient with test result Contains necessary data on any patient with test result Contains necessary data on

14


cytology_lab


15


hospital system

cytology_lab_res_gse

16


hospital system

cytology_lab_res_gue

Contains necessary data on any patient with test result Contains necessary data on any patient with test result Contains necessary data on

17


hospital system

hematology_lab

any patient having an appointment for test in lab

18


19

Emergency department

hospital system

hematology_lab_resu

Contains necessary data on

lts

any patient with test result

emeregency_section

60

Contains data about patients’ information.

Chapter-3

20

21

22

23

24

25

26

27

Administrators privileges


hospital system

Contact the administrator

hospital system

Pharmacies medicines management

medicines.

phar1_invoice_entry,

Contains necessary data

phar2_invoice_entry

about medicine bills

phar1_invoice_detail,

Contains the medicines bill

hospital system

har2_invoice_detail

details

hospital system

phar_categories

hospital system


Contains the categories of all medicines. Contains the companies


Contains user suggestions

phar2_medicines


administrator’s login.

Contains data about all


contact_us

Contains data on

phar1_medicines, hospital system


admin_login_control

hospital system

phar_providers

name which provides the pharmacies with medicines

hospital system

phar1_sells, phar2_sells

61

Contains some necessary data about the spent(sold)medicines

Chapter Four Performance Analysis of the Proposed EHS 4.1 Introduction Performance analysis of the proposed EHS is described in this chapter by web technologies WAMP and LAMP. The response time testing is used for EH over both types of 2TA and 3TA. Four connection-LAN networks are addressed for testing the proposed EHS depending on both of 2TA and 3TA, using Windows OS and Linux OS. The two techniques of testing are manually tested (hand-writing code PHP) by a programmer for testing response time (in seconds), and Wireshark ready software application for testing response time (in seconds). Finally, different organizations are addressed which proposed for this system of 2TA and 3TA with different scenarios using OPNET-tool.

4.2 Performance Analysis Implementation Criteria It is impossible to calculate the time-consuming in Regular Performance (RP) due to changeability of human mode or activity. Virtual performance, however for example web performance is very easy to calculate. There is a direct relation between technology and performance because better communication tools reduce response-time. Therefore, the results of experiments are important to compare the performance of different technologies with the example of an EHS. Performance analysis is

implemented by three techniques; PHP script,

Wireshark and OPNET tools. A copy of the proposed EHS is run on the server side of the four types of computer-LAB namely ; LAN-1, LAN-2, LAN-3, and LAN-4 for the reason of testing and to find out the optimal time-consume by (response time). 2TA and 3TA has been depended with Windows and Linux operating systems. The results of the system is evaluated by comparing them 62

Chapter-4

Performance Analysis of the Proposed EHS

with professional tools called Wireshark and OPNET as well as by handwriting scripts in php (response time). The tests depended (1, 5, 10 and 20) hosts for the client-side and server/servers side with (2TA and 3TA). The test is to find out which architecture is better when dealing with databases (takes less time to load information from the database or into the database).The investigation tests of the developed criteria records are shown in detail in the coming sections.

4.3 Time-Consume Analysis approaches: There are different ways to test the response time for the proposed EHS, the hand writing script code (PHP code) by a programmer and ready software applications Wireshark and OPNET. In the proposed EHS, Wireshark is an application software that is used to find response time of the proposed EHS. The alternative hand writing script is a ready to use application Wireshark for performance analysis. The Wireshark should be installed on the clients and run to find about the performances. There are several differences between both techniques; Wireshark has a user interface and the scripts php techniques without any interface, besides Wireshark must be installed and run (no need to write scripts because it is a ready application) but the hand writing is scripting. On the other hand, the OPNET tool is a professional one that can helps for designing and implementing huge networks, especially those depending on the principles of the Client/Server. The average delay time for the overall network or related with part of it can be measured. Also, the amount of dataflow can be measured for small or huge numbers of used hosts. This tool provides for the configuration of the designed network.

63

Chapter-4


4.4 The Testing Media Strategy The testing of EHS response time with the middle size of media strategy network was conducted in a computer-LAB that was established for the purpose of testing modules of the proposed system. The topology of the established network was star topology with which ten clients are connected through a switch hub to two servers. Figure (4.1) illustrates the established network for EHS. The proposed system is evaluated by several seminar evaluations, all of which took place in the computer LAB was established for the purposes of the proposed system. Apart from the two servers, all clients’ specifications are the same. 2TA and 3TA architecture are used in the test to find out which architecture is better for dealing with databases (take less time to load information from the database or into the database). The preparation process of the network implied the following steps: 1. Installing the required OS on the servers: Windows OS for first test and Linux OS for the second one. 2. Installing WAMP technology (for Windows OS) on server-hosts to be used as servers. 3. Installing LAMP technology (for Linux OS) on server-hosts to be used as servers. 4. Connect the clients to server through a hub switch and provide them static IP address. 5. Preparing the required related tools such as: AJAX, JQuery, JavaScript, HTML, CSS and Wireshark.

64

Chapter-4


Figure (4.1): The established network for EHS

4.5 Operating System Windows with Tiers Architecture The implementation results using Windows-7 OS with both 2TA and 3TA are illustrated in this section. Both techniques (PHP Code and Wireshark tool) have to be run in order to test and find out response time individually.

4.5.1 Windows-7 with 2TA Four different groups of client samples have been depended to obtain an excellent and accurate result, these groups depend on the number of client-hosts in the LAN. Sample-1 is only a client that is directly connected to the server, sample-2 contains five clients connected to the server, sample-3 contains ten clients that connected to the server and sample-4 contains twenty clients connected to the server. The proposed system application runs on the server and the clients only with browsers. The use of one-client or two-clients for implementation in a LAN is very difficult to get a satisfactory result, however using of up to ten-clients achieves better results. The system has no problems when using more than two clients at the same time, hence, group sample-1- and 65

Chapter-4


group sample-2- are not very accurate compared with those of group samples- 3 and 4. The recommended registration,

phases to implement from proposed system (i.e.

appointment,

medical

prescription,

pharmacy,

LABs

and

radiography). The implemented results are illustrated in tables (4.1 and 4.2). These results are related to the consumed-time and dataflow of 2TA depending on Windows-7 OS using one, five, ten and 20 clients respectively. While Table (4.3) represents the average values of consumed-time and the total dataflow for 2TA for the same implementation, figures (4.2 and 4.3) show the relationship between the number of clients with the average consumed-time and the total dataflow respectively. Table (4.1) describes the consumed-time of 2TA with Windows-7 using one, five and ten clients including the number of clients, client number, implementation phase, consumed time (in seconds) and dataflow (in bytes). At the beginning only one computer (client) with a web browser was connected to the server containing the application programs and the database system; then five clients were connected to the same server, and finally ten clients were connected to the same server. Table (4.2) represents the same information as table (4.1) using twenty clients connected to the same server for the same purposes. Table (4.3) represents the average consumed-time and the total dataflow of 2TA using Windows-7 for one, five, ten and twenty clients respectively.

66

Chapter-4


Table (4.1): Consumed-time and Dataflow of 2TA with Windows-7 using (1, 5 and 10)-clients No. of Clients

One

Five

Client No.

Consumed Time (Sec.) Implemented Phase

Dataflow (byte)

PHP code

Wireshark

Request

Response

Client-1

Registration

0.028

0.032

802

1401

Client-1

Registration

0.019

0.026

802

1402

Client-2

Get Appointment

0.014

0.020

606

512

Client-3

Biology lab results

0.002

0.007

685

610

Client-4

Radiographer result

0.023

0.039

8192

1056

Client-5

Medical prescription

0.084

0.089

730

893

Client-1

Registration

0.013

0.019

799

1402

Client-2

Get Appointment

0.013

0.020

610

510

Client-3

Send patient to X-ray

0.036

0.041

650

822

Client-4

Send patient to lab

0.036

0.040

627

771

Client-5

X-ray results

0.027

0.066

9673

1057

Client-6

Lab results

0.001

0.007

685

610

Client-7


0.023

0.028

717

899

Client-8

Patient get medicines

0.037

0.045

983

1181

Client-9

Patient review results

0.004

0.013

624

1191

Client-10

Emergency register

0.018

0.023

717

1026

Ten

67

Chapter-4


Table (4.2): Consumed-time and Dataflow of 2TA with Windows-7 using 20- Clients. Consumed Time (Sec.) Client No.

Dataflow (byte)

Implemented Phase PHP code

Wireshark

Request

Response

Client-1

Registration

0.015

0.021

822

1736

Client-2

Get Appointment

0.014

0.022

619

1783

Client-3

Cytology Lab result

0.003

0.008

650

2268

Client-4

X-ray result

0.029

0.068

650

2236

Client-5


0.024

0.038

200

1514

0.035

0.039

700

651

Client-6


Client-7

Send patient to Lab

0.037

0.041

726

1816

Client-8

Patient get medicine

0.038

0.046

1146

900

Client-9


0.005

0.015

633

2483

Client-10

Emergency register

0.020

0.026

736

1860

Client-11

Registration

0.016

0.021

822

1736

Client-12

Add new drug

0.015

0.020

405

1000

Client-13

Get appointment

0.013

0.021

619

1783

Client-14


0.025

0.028

174

1514

Client-15

Search for doctor

0.018

0.023

210

700

Client-16

Send patient to ultrasound

0.036

0.040

700

651

Client-17

Ultrasound result

0.009

0.014

750

2236

Client-18

Test to patient

0.011

0.016

700

400

Client-19

Get appointment

0.014

0.018

619

1783

Client-20


0.026

0.030

174

1514

68

Chapter-4


Table (4.3): Average Consumed-time and Total Dataflow for 2TA with Windows-7 using (one, five, ten and twenty) clients. Average Consumed Time (Sec.)

Total Dataflow (Byte)

No of clients PHP code

Wireshark

Request

Response

One

0.028

0.032

802

1401

Five

0.028

0.036

11015

4473

Ten

0.020

0.030

16085

9469

Twenty

0.020

0.027

12055

30564

Figure (4.2) shows the average consumed-time of 2TA with Windows-7 using one, five, ten and twenty clients. The PHP code is shown in blue line

Time (seconds)

while the red line is for Wireshark ready software.

0.04 0.035 0.03 0.025 0.02 0.015 0.01 0.005 0

PHP code Wireshark

One

Five

Ten

twenty

No. of Clients

Figure (4.2): Average Consumed-time for 2TA with Windows-7

Figure (4.3) shows the total dataflow for 2TA using Windows-7 for one, five, ten and twenty clients measured in bytes.

69

Chapter-4


35000

Dataflow (Bytes)

30000 25000 20000

Request

15000

Response

10000 5000 0 One

Five

Ten

twenty

No. of Clients

Figure (4.3): Total Dataflow for 2TA with Windows-7

4.5.2 Windows-7 with 3TA The same test in 2TA ,with the same phases, is repeated for 3TA. The 3TA components (backend, middleware, frontend) are separately connected in three computers (two servers and a number of clients). Server-1 is middleware (Apache and PHP) and the frontend is the client’s computer (web browser), while server-2 is the database server (MySQL). All software needed to achieve the proposed system are be installed on the server side in both tier architecture 2TA and 3TA. The same phases adopted

for 2TA are implemented with 3TA. The

implemented results are illustrated in tables (4.4 and 4.5). These results are related with the consumed-time and the dataflow of 3TA depending on Windows-7 OS using one, five, ten and twenty clients respectively. While table (4.6) represents the average values of consumed-time and total dataflow for 3TA for the same implementation, figures (4.4 and 4.5) show the relationship between number of the clients used with the average consumed-time and the total dataflow respectively.

70

Chapter-4


Table (4.4): Consumed-time and Dataflow of 3TA with Windows-7 using (1, 5 and 10)-Clients Consumed Time No. of Clients

Client No.

Dataflow (byte)

(Sec.) Implemented Phase PHP

Wireshark Request Response

code One

Five

Ten

Client-1

Registration

0.010

0.015

803

1402

Client-1

Registration

0.007

0.012

803

1400

Client-2

Get Appointment

0.011

0.016

606

511

Client-3

Biology lab results

0.006

0.012

686

609

Client-4

Radiography result

0.010

0.019

5382

1056

Client-5


0.011

0.017

709

893

Client-1

Registration

0.015

0.023

795

1403

Client-2

Get Appointment

0.012

0.021

605

510

Client-3

Send patient to Radiography

0.014

0.020

650

869

Client-4

Send patient to lab

0.010

0.014

627

772

Client-5

Radiography results

0.011

0.031

2371

1052

Client-6

LAB results

0.006

0.011

686

610

Client-7


0.011

0.015

718

899

Client-8

Patient get medicines

0.012

0.016

984

1182

Client-9


0.015

0.025

624

1190

Client-10

Emergency register

0.010

0.016

728

1027

71

Chapter-4


Table (4.5): Consumed-time and Dataflow of 3TA with Windows-7 using 20-Clients. Consumed Time Client No.

(Sec.)

Implemented Phase

PHP code

Dataflow (byte)

Wireshark

Request

Response

Client-1

Registration

0.015

0.022

822

1736

Client-2

Get Appointment

0.013

0.020

619

1783

Client-3

Cytology Lab result

0.007

0.011

666

2268

Client-4

X-ray result

0.023

0.028

650

2236

Client-5


0.013

0.018

174

1514

0.016

0.023

700

758

Client-6


Client-7

Send patient to Lab

0.013

0.020

750

1816

Client-8


0.015

0.019

1146

900

Client-9


0.016

0.021

633

2483

Client-10

Emergency register

0.011

0.017

736

1860

Client-11

Registration

0.015

0.022

850

1736

Client-12

Add new drug

0.014

0.019

405

958

Client-13

Get appointment

0.012

0.018

619

1783

Client-14


0.012

0.016

174

1514

Client-15

Search for doctor

0.016

0.023

210

700

Client-16


0.034

0.038

700

651

Client-17

Ultrasound result

0.010

0.015

650

2236

Client-18

Test to patient

0.010

0.015

700

300

Client-19

Get appointment

0.014

0.019

619

1783

Client-20


0.013

0.018

174

1514

72

Chapter-4


Table (4.6) Average Consumed-time and total Dataflow of 3TA with Windows-7 Average Consumed Time (Sec.)



Wireshark

Request

Response

One

0.010

0.015

803

1402

Five

0.009

0.015

8186

4469

Ten

0.011

0.019

8788

9514

Twenty

0.014

0.020

11997

30529

Figures (4.4 and 4.5) show the average consumed-time and total dataflow for 3TA with Windows-7 using one, five, ten and twenty clients. PHP showed in blue line and Wireshark in red line.

0.025

Time (seconds)

0.02 0.015

PHP code Wireshark

0.01 0.005 0 One

Five

Ten

Twenty

Figure (4.4) Average Consumed-time for 3TA with Windows-7

73

Chapter-4


35000 30000

Dataflow (Bytes)

25000 20000

Request

15000

Response

10000 5000 0 One

Five

Ten

Twenty

No. of Clients

Figure (4.5) Total Dataflow for 3TA with Windows-7

4.6 Operating System Linux with Tiers Architecture Both techniques must be run to test and find out results for Ubuntu-Desktop 14.04 OS with 2TA and 3TA individually. 4.6.1 Linux Ubuntu 14.04 with 2TA To avoid repetition and redundancy, this section only includes the results obtained with 2TA when using Windows 7 OS, in section (4.5.1) applied with Linux Ubuntu version 14.04 OS. The server contains the application programs and the MySQL Database. All system requirements such as; PHP, Apache and Database on Linux Ubuntu version 14.04 are installed on the server. The implemented results are illustrated in tables (4.7, 4.8 and 4.9). Figures (4.6 and 4.7) show the relationship between the number of the clients, the average consumed-time and total dataflow respectively.

74

Chapter-4


Table (4.7): Consumed-time and Dataflow of 3TA with Linux Ubuntu14.04 using (1, 5 and 10)-Clients No. of Clients

Consumed Time

Client No.

Dataflow (byte)


Wireshark

Request

Response

code One

Five

Ten

Client-1

Registration

0.031

0.034

808

1739

Client-1

Registration

0.041

0.044

810

1735

Client-2

Get Appointment

0.045

0.049

619

1781

Client-3

Biology lab results

0.037

0.042

700

652

Client-4

Radiography result

0.037

0.047

180

1515

Client-5


0.092

0.097

722

1817

Client-1

Registration

0.030

0.033

827

1739

Client-2

Get Appointment

0.038

0.040

620

1780

Client-3

Send patient to radiography

0.020

0.023

666

2268

Client-4

Send patient to lab

0.024

0.027

650

2237

Client-5

Radiography results

0.038

0.070

188

1515

Client-6

Lab results

0.036

0.040

701

650

Client-7


0.099

0.102

726

1815

Client-8


0.095

0.099

569

609

Client-9


0.002

0.005

633

2487

Client-10

Emergency register

0.027

0.032

753

1861

75

Chapter-4


Table (4.8): Consumed-time and Dataflow of 2TA with Linux Ubuntu 14.04 using 20-Clients Consumed Time (Sec.) Client No.

Implemented Phase

Client-1

Dataflow (byte)

PHP code

Wireshark

Request

Response

Registration

0.032

0.036

900

1736

Client-2

Get Appointment

0.037

0.042

619

1783

Client-3

Cytology Lab result

0.038

0.041

666

2268

Client-4

X-ray result

0.039

0.045

650

2236

0.010

0.104

200

1514

0.024

0.025

700

750

Client-5 Client-6

Medical prescription Send patient to X-ray

Client-7

Send patient to Lab

0.025

0.029

726

1816

Client-8


0.094

0.101

1146

855

Client-9


0.008

0.011

750

2483

Client-10

Emergency register

0.030

0.033

736

1860

Client-11

Registration

0.029

0.032

822

1736

Client-12

Add new drug

0.025

0.029

405

900

Client-13

Get appointment

0.030

0.033

619

1783

Client-14


0.098

0.101

174

1514

Client-15

Search for doctor

0.027

0.030

210

700

Client-16


0.035

0.038

700

651

Client-17

Ultrasound result

0.011

0.013

650

2236

Client-18

Test to patient

0.014

0.017

700

300

Client-19

Get appointment

0.033

0.036

619

1783

Client-20


0.098

0.099

174

1514

76

Chapter-4


Table (4.9) Average Consumed-time and Dataflow of 2TA with Linux Ubuntu -14.04

Average Consumed Time (Sec.)



Wireshark

Request

Response

One

0.031

0.034

808

1739

Five

0.050

0.055

3031

7500

Ten

0.040

0.047

6333

1696

Twenty

0.036

0.044

12166

30418

0.06

Time (seconds)

0.05 0.04 PHP code

0.03

Wireshark 0.02 0.01 0 One

Five

Ten

Twenty

No. of Clients

Figure (4.6) Average Consumed-time for 2TA with Linux Ubuntu -14.04

77

Chapter-4


35000

Dataflow (Bytes)

30000 25000 20000

Request

15000

Response

10000 5000 0 One

Five

Ten

Twenty

No. of Clients

Figure (4.7) Total Dataflow for 2TA with Linux Ubuntu -14.04

4.6.2 Linux Ubuntu 14.04 with 3TA To avoid repetition and redundancy, this section only includes the results obtained with 3TA when using Windows 7 OS, in section (4.5.2) applied with Linux Ubuntu version 14.04 OS. The server contains the application programs and the MySQL Database. All system requirements such as; PHP, Apache and Database on Linux Ubuntu version 14.04 are installed on the server. The implemented results are illustrated in Tables (4.10, 4.11 and 4.12). Figures (4.8 and 4.9) show the relationship between the number of the clients, the average consumed-time and the total dataflow respectively.

78

Chapter-4


Table (4.10): Consumed-time and Dataflow of 3TA with Linux Ubuntu 14.04 using (1, 5 and 10)-Clients No. of Clients

Consumed Time

Client No.

Dataflow (byte)


Wireshark

Request

Response

code One

Five

Ten

Client-1

Registration

0.029

0.032

808

1740

Client-1

Registration

0.030

0.032

810

1737

Client-2

Get Appointment

0.033

0.037

619

1783

Client-3

Biology lab results

0.045

0.049

700

650

Client-4

X-ray result

0.032

0.040

167

1515

Client-5


0.076

0.079

726

1817

Client-1

Registration

0.020

0.032

822

1736

Client-2

Get Appointment

0.035

0.039

619

1783

Client-3

Send patient to Radiography

0.010

0.032

666

2268

Client-4

Send patient to lab

0.020

0.024

650

2236

Client-5

Radiography results

0.019

0.023

174

1514

Client-6

Lab results

0.037

0.040

700

651

Client-7


0.094

0.099

726

1816

Client-8


0.084

0.090

1146

855

Client-9


0.008

0.011

633

2483

Client-10

Emergency register

0.027

0.030

736

1860

79

Chapter-4


Table (4.11): Consumed-time and Dataflow of 3TA with Linux Ubuntu -14.04 using 20-Clients Consumed Time (Sec.) Client No.

Implemented Phase

Client-1

Dataflow (byte)

PHP code

Wireshark

Request

Response

Registration

0.022

0.028

822

1736

Client-2

Get Appointment

0.030

0.038

619

1783

Client-3

Cytology Lab result

0.021

0.027

666

2268

Client-4

X-ray result

0.017

0.020

700

2236

Client-5


0.075

0.080

185

1514

0.013

0.015

700

651

Client-6


Client-7

Send patient to Lab

0.021

0.025

726

1816

Client-8


0.060

0.064

1146

855

Client-9


0.007

0.010

633

2483

Client-10

Emergency register

0.016

0.021

736

1860

Client-11

Registration

0.021

0.025

822

1736

Client-12

Add new drug

0.019

0.026

405

950

Client-13

Get appointment

0.029

0.033

619

1783

Client-14


0.073

0.076

174

1514

Client-15

Search for doctor

0.023

0.027

310

700

Client-16


0.036

0.038

700

651

Client-17

Ultrasound result

0.010

0.014

650

2236

Client-18

Test to patient

0.012

0.015

700

300

Client-19

Get appointment

0.026

0.031

750

1783

Client-20


0.055

0.067

174

1514

80

Chapter-4


Table (4.12) Average Consumed-time and total Dataflow of 3TA with Linux Ubuntu 14.04 Average Consumed Time (Sec.)


No of clients

PHP code

Wireshark

Request

Response

One

0.029

0.032

808

1740

Five

0.043

0.047

3022

7502

Ten

0.035

0.042

6872

17202

Twenty

0.029

0.034

12237

30369

0.05

Time (seconds)

0.04 0.03

PHP code Wireshark

0.02 0.01 0 One

Five

Ten

Twenty

No. of Clients

Figure (4.8) Average Consumed-time for 3TA with Linux Ubuntu -14.04

35000 30000

Dataflow (Bytes)

25000 20000

Request

15000

Response

10000 5000 0 One

Five

Ten

Twenty

No. of Clients

Figure (4.9) Total Dataflow for 3TA with Linux Ubuntu -14.04

81

Chapter-4


4.7 Load and Performance Test Generally, the Average Consumed Time (ACT) can be calculated by the sum of all testing results of computers divided on the number of computers which are tested. The aim is to show the average consumed time for (one, five, ten and twenty) clients for 2TA and 3TA with the different operating system Windows and Linux.

The least results of ACT in seconds will

indicate the best

performance. As EHS is part of e-government, the request of dataflow by byte for patients to get appointment is showing in booking appointment by patients or vice versa. The proposed system time-consume is reliable and accurate because the response-time to Get appointment in the proposed system is approximately one second. Due to two servers in 3TA, the proposed system never got crashed (got down). The most suitable test to assess the proposed system is load and performance. The time of 3TA is balancing load by two servers of system architecture making the optimum capacity and increasing performance. The results of the performance tests of proposed system are given in table (4.13), while figure (4.10) shows the relationship between the ACT and number of the clients for both 2TA and 3TA using Windows-7 OS. Table (4.14) represents the results performance testing of proposed system, while Figure (4.10 and 4.11) shows the relationship between the ACT and number of the clients for both 2TA and 3TA using (Windows-7 and Linux Ubunutu-14.04).

Table (4.13) Average Consumed-time for 2TA and 3TA using Windows-7 2TA

No of

3TA

clients

PHP code

Wireshark

PHP code

Wireshark

One

0.028

0.032

0.01

0.015

Five

0.028

0.036

0.009

0.015

Ten

0.020

0.030

0.0116

0.0192

Twenty

0.020

0.027

0.0146

0.0201

82

Chapter-4


0.04 0.035 0.03

2 Tier PHP code

0.025

2 Tier Wireshark

0.02 0.015

3 Tier PHP code

0.01

3 Tier Wireshark

0.005 0 One

Five

Ten

Twenty

Figure (4.10) Average Consumed-time for 2TA and 3TA using Windows-7

Table (4.14) Average Consumed-time for 2TA and 3TA using Linux Ubuntu -14.04 2TA

3TA

No of clients

PHP code

Wireshark

PHP code

Wireshark

One

0.031

0.034

0.029

0.032

Five

0.050

0.055

0.043

0.047

Ten

0.040

0.047

0.035

0.042

Twenty

0.036

0.044

0.0293

0.034

0.06 0.05 2 Tier PHP code

0.04

2 Tier Wireshark

0.03

3 Tier PHP code

0.02

3 Tier Wireshark

0.01 0 One

Five

Ten

Twenty

Figure(4.11)Average Consumed-time for 2TA and 3TA using Linux Ubuntu -14.04

83

Chapter-4


4.8 Additional Test Using OPNET Tool In order to have a wide view of the proposed system, it is necessary to apply simulation-tests to the system for different loads during certain periods. Hence, as an additional test applied to the proposed system, the OPNET tool has been depended that provides simulation tests for such these systems. Different organizations have been proposed for this system of 2TA and 3TA with different scenarios using OPNET-tool. There are two main parts of the evaluation, firstly, the same scenarios applied for 2TA and 3TA use both Windows 7 and Linux Ubunutu-14.04 OSs are adopted here using (five, ten, fifteen and twenty) clients. The consumed-time and the dataflow for the overall network and the server(s) have been determined using OPNET tool. Finally, other scenarios have been proposed using large numbers of clients to be as maximum as possibly close to the real conditions. The type of the OS is not important here because in real applications the proposed EHS will be treated with the distributed systems that have different types of OSs and there must be transparency for the used OSs feature. The first part of the simulation was run for one hour, and HTTP-server was supposed to be a heavy browsing server, while the database server was supposed to be a medium load database server, while for the second part of the simulation was run for several minutes. The proposed prototypes have been simulated depending on the mechanism illustrated in Appendix-B. So, only the general diagrams of the proposed scenarios will be displayed in this chapter, and there is no need for a detailed description-steps.

84

Chapter-4


4.8.1 Results Obtained for Four-Evaluation-Scenarios Using OPNET Tool The same four scenarios declared in section (4.5.1) are adopted here to be tested using OPNET-tool. Figure (4.12) represents the four evaluation-scenarios for 2TA using OPNET-tool using five, ten, fifteen and twenty clients. Table (4.15) represents Total-Network-Delay (TND), Server Delay (SD) and ServerLoad (SL). Figures (4.13, 4.14 and 4.15) represent TND, SD and SL comparisons of the four evaluation-scenarios for 2TA using OPNET-tool.

(a)

(b)

(c)

(d)

Figure (4.12): Four evaluation-scenarios for 2TA using OPNET-tool: (a) Using 5 clients. (b) Using 10 clients. (c) Using 15 clients. (d) Using 20 clients.

85

Chapter-4


OPNET tool has the capability of determining many features for the depended network, but only these features (i.e. TND, SD and SL) considered here that are related to the system performance measurements. From this table and figures it is clear that the overall delay of the network is greater than that of the server-host (which are normal and expected results). In general, because of that both of web application program and database system are placed at one server-host (for 2TA), so the server load can be noticed clearly.

Table (4.15): Total-Network-Delay and Server-Load for 2TA using OPNET-tool. No. of

Total Network Delay

Server Delay

(Sec.)

(Sec.)

4

0300.4

0.0000188

195,462

20

0300.49

0.0000185

541,.26

24

0300.44

0.0000185

4.6,165

10

0300.444

0.0000185

659,561

Clients

Server Load (bits/sec.)

Figure (4.13): Total-Network-Delay comparison of the Four evaluation-scenarios for 2TA using OPNET-tool. 86

Chapter-4


Figure (4.14): Server-Delay comparison of the Four evaluation-scenarios for 2TA using OPNET-tool.

Figure (4.15): Server-Load comparison of the Four evaluation-scenarios for 2TA using OPNET-tool.

87

Chapter-4


Figure (4.15) illustrates the effect of increasing number of clients on the amount of server load in term of (bit/sec). Hence, there is a direct proportion between number of client and server load. The same four scenarios declared in section (4.5.2) are depended here to be tested using OPNET-tool. Figure (4.16) represents the evaluation-scenarios for 3TA using OPNET-tool using five, ten, fifteen and twenty clients. Table (4.16) represents Total-Network-Delay (TND), Server Delay (SD) and Server-Load (SL). Figures (4.17, 4.18 and 4.19) represent TND, SD and SL comparisons of the four evaluation-scenarios for 3TA using OPNET-tool. It can be shown from table (4.16) that the TND is greater relatively with respect to those values of 2TA because of adding an additional server. Also, the SD values here are less than those of 2TA because just http-server is considered (i.e. the delay of that server that contains just the web application program). While the http-server load will has higher load than that of 2TA because the additional server in 3TA. The effect of these results are illustrated clearly in the plotted curves in Figures (4.17, 4.18 and 4.19) that are extracted from Table (4.16).Figure (4.17) shows the effect of average values of TND for 3TA, and the differences can be noticed. Figure (4.18) represents the average values of http-server-delay using (5, 10, 15 and 20) clients. It is clear that there are no large differences among these values because just this server will face all received packets and the effect of communication between this server and database server can be neglected. The effect of increasing number of clients on the http-server is illustrated in figure (4.19) and this relation is direct proportion with increasing server load.

88

Chapter-4


(a)

(b)

(c)

(d)

Figure (4.16): Four evaluation-scenarios for 3TA using OPNET-tool: (a) Using 5 clients. (b) Using 10 clients. (c) Using 15 clients. (d) Using 20 clients. Table (4.16): Total-Network-Delay and Server-Load for 3TA using OPNET-tool. No. of

Total Network Delay

HTTP-Server Delay

HTTP-Server Load

Clients

(Sec.)

(Sec.)

(bits/sec.)

4

0.0035

0.0000186

151,524

20

0.0035

0.0000186

546,664

24

0.0036

0.0000186

944,909

10

0.0037

0.0000185

2,056,046

89

Chapter-4


Figure (4.17): Total-Network-Delay comparison of the four evaluation-scenarios for 3TA using OPNET-tool.

Figure (4.18): HTTP-Server-Delay comparison of the four evaluation-scenarios for 3TA using OPNET-tool.

90

Chapter-4


Figure (4.19): HTTP-Server-Load comparison of the four evaluation-scenarios for 3TA using OPNET-tool.

4.8.2 Results Obtained for Large Number of Clients Using OPNET Tool The second part is related to scenarios that have been proposed using large numbers of client to be as maximum as possibly close to the real conditions. Hence (100, 1000 and 10,000) clients have been proposed as prototypes to simulate three networks connected via (Router or Internet) around Kurdistan. These clients are also used to participate in these scenarios for both 2TA and 3TA. Figure (4.20) represents scenario-1 organization; both of HTTP application software and database are at the same server. The server is connected to the three networks via a Router. This structure has been proposed when assuming that the connected three networks will be connect in turns to the server-hosts via a router. This assumption will neglect the drawbacks and problem of the Internet. Figure (4.21) represents the (HTTP+Database)-Server time-delay and its load measured by (bits/Sec.) for 2TA of the evaluation scenario-1 illustrated in figure (4.20) using OPNET-tool. While the server load that measured by

91

Chapter-4


(Requests/Sec.) for 2TA of the evaluation-scenario-1 is illustrated in figure (4.22). Because of the huge packet-traffic for this test, the simulation has been implemented for several minutes depending on the RAM-size of the used computer. It can be shown from figure (4.21) that the average time delay of the server will remain at a certain level at the beginning and will be increased after reaching the packet-traffic within the system to the rated level. While, the server-load will be increased rapidly for the rated packet-traffic. There is a large gap between these results comparing with those of figures (4.14 and 4.15) for the same architecture (2TA) but using (5, 10, 15 and 20) clients for both serverdelay and server-load respectively. As an additional results-field, the rate of the requests/second has been determined at the server as shown in figure (4.22). it is clear that at the second (100 which is equivalent to 1min+40sec of the figure (4.21)) with begin the real packet-traffic. Hence Requests/Sec rate has been increased rapidly in the same style of bit/Sec of figure (4.21).

Figure (4.20): Evaluation-scenario-1 with three different-size-networks connected to a server via a router for 2TA using OPNET-tool.

92

Chapter-4


Figure (4.21): (HTTP+Database)-Server Delay and Load (bits/Sec.) for 2TA of Figure (4.20) using OPNET-tool.

Figure (4.22): (HTTP+Database)-Server Load (Requests/Sec.) for 2TA of Figure (4.20) using OPNET-tool. 93

Chapter-4


Figure (4.23) represents the organization of scenario-2 organization for 2TA using OPNET tool. Both of HTTP application software and database are at the same server. The server is connected to the three networks via Internet. Figure (4.24)

represents

the

(HTTP+Database)-server

load

measured

by

(Requests/Sec.) for 2TA of the evaluation scenario-2 and illustrated in figure (4.23) using OPNET-tool. While the server time-delay is illustrated in figure (4.25). Depending on the rules of connection establishing and then starting the exchange of data between the server-side and the clients-side, there will be a waste time for starting recording of as a simulation processing. Figure (4.24) shows that there is no server-load recorded by the simulationtest at the server-side from (0 Sec.) until (100 Sec.). Then, the server-load started from (0 bit/Sec.) and increased rapidly to take its style of tracking the changes of the packets-traffic. In the same manner, Figure (4.25) shows that the server-delay has been recorded at the (1min+40 Sec.) which is considered as a high average of time-delay then decreased to its rate values.

Figure (4.23): Evaluation-scenario-2 with three different-size-networks connected to a server via Internet for 2TA using OPNET-tool.

94

Chapter-4


Figure (4.24): (HTTP+Databse)-Server-Load (Requests/Sec.) for 2TA of Figure (4.23) using OPNET-tool.

Figure (4.25): (HTTP+Database)-Server Delay for 2TA of Figure (4.23) using OPNETtool.

Figure (4.26) represents the organization of scenario-3 for 3TA using OPNET tool. HTTP application software server is separated from databaseserver. The servers are connected to three networks via a Router. Also, here the servers have been considered to be connected to the clients-side via a router neglecting using the Internet.

95

Chapter-4


Figure (4.27) represents the database-server time-delay and its load measured by (bits/Sec.) for 3TA of the evaluation scenario-3 as illustrated in Figure (4.26) using OPNET-tool. While the HTTP-server load measured by (bit/Sec.) for this scenario is illustrated in figure (4.28); the HTTP-server load measured by (Requests/Sec.) for this scenario is illustrated in figure (4.29). The upper curve of figure (4.27) shows that the average value of the databaseserver-delay has approximately steady-state until (100 Sec.) Then the load has been increased rapidly to reach its rate of packet-traffic changes. While, the lower curve indicates that there is approximately no load at this server, because the really load will be done at the http-server, and the connection of the database-server with the clients-side is via http-server. Because of the packets-traffic, the http-server time-delay and load will start at (100 Sec.) and increase rapidly to reach their rate values as shown in figures (4.28 and 4.29) respectively.

Figure (4.26): Evaluation-scenario-3 with three different-size-networks connected to a servers via a router for 3TA using OPNET-tool.

96

Chapter-4


Figure (4.27): Database-Server Delay and Load (bits/Sec.) for 3TA of figure (4.26) using OPNET-tool.

Figure (4.28): HTTP-Server Load (bits/Sec.) for 3TA of figure (4.26) using OPNET-tool.

97

Chapter-4


Figure (4.29): Total- HTTP-Server-Load (Requests/Sec.) for 3TA of figure (4.26) using OPNET-tool.

Figure (4.30) represents the organization of scenario-4 for 3TA using OPNET tool. The HTTP application software server is separated from the database-server. The server is connected to the three networks via Internet. Figure (4.31) represents the HTTP-server load measured by (bit/Sec.) for this scenario. And the HTTP-server load that is measured by (Requests/Sec.) for this scenario is illustrated in figure (4.32).

Figure (4.30): Evaluation-scenario-4 with three different-size-networks connected to a servers via Internet for 3TA using OPNET-tool. 98

Chapter-4


Figure (4.31): HTTP-Server Load (bits/Sec.) for 3TA of figure (4.30) using OPNET-tool.

Figure (4.32): Total- HTTP-Server-Load (Requests/Sec.) for 3TA of figure (4.30) using OPNET-tool.

Both of http-server load (bit/Sec. and Request/Sec.) start at the (100 Sec.) of the simulation time as shown in Figures (4.31 and 4.32) respectively. Then these values change rapidly and reach their rate values depending on the packettraffic. This delay of start recording is due to the Internet establishing and exchanging data.

99

Chapter-4


4.9 Evaluation and Comparison The overall evaluation of the proposed system shows that the 3TA is perfectly reliable with optimum results for both mentioned techniques. This section deals with two main parts; the first part deals with the comparison related to both architectures of the proposed system (2TA and 3TA). Whereas the second part deals with the evaluation of the obtained results compared with those of previous works.  Evaluation and Comparison of the Results Obtained by this Thesis There are two architectures adopted in this thesis: 2TA means that there is only one computer at the server-side, while 3TA contains two computers as a server. Figure (4.10) shows a direct comparison of the average Consumed-time between the results of 2TA and 3TA using Window-7. While figure (4.11) represents the same comparison but using Linux OS. Using OPNET simulator as a professional evaluation and designing tool and an important performance evaluation tool indicated the efficiency of 3TA than those 2TA.  Evaluation and comparison of results Obtained in this thesis and previous works Due to the lack of previous work in this field, there is no chance to compare the results of this thesis to any other previous work. As an evaluation tool, this system has been tested with one of the most reliable technologies tool namely (Wireshark) as illustrated in the previous sections of this chapter. Moreover ,another professional simulation software for measuring network-performance and network path determination namely (OPNET), is depended in this work, taking into consideration that there is no other previous work which have used all these evaluation tools in one work. The nearest work to this thesis is Giyath [16] who used the same tier architectures and OSs with Wireshark tool. But, still the number of clients that 100

Chapter-4


have been depended in this thesis is greater than those depended in his thesis who used only (10 clients for lab testing); this thesis, however, depended (20 clients for lab testing). The thesis takes the lead in adopting the OPNET tool and expand the testing of up to 10,000 clients. For purposes of comparison between the features of the system developed in this thesis and those of previous related works, the following points should be taken into consideration:

1. There is no previous detailed; literature tackling the architectures 2TA and 3TA as tackled in this thesis, including the performance evaluation methods. 2. The full statistical abilities of every service produced by the system is presented in the present thesis. No other previous work conducted similar steps except for [16]. 3. This system provides a special database system for pharmacy management that works as a part within the general database of overall system. And this system provides the maximum possible services (i.e. 4 Labs each has multi tests, Radiography department), while the previous works, such as[15], covered few of these services. Again the only work that tackles these services in detail is [16]. But adding to that of [16], the databases and consequently the related programming have been taken in the consideration to support any additional department, Lab or emergency details. 4. This thesis has depended on investigation technique during the steps of the project. The investigation was applied in two fields: a. Ministry of Higher Education - University of Sulaimani: i. Faculty of Medicine. ii. College of Nursing. 101

Chapter-4


b. Ministry of Health: i. Republic Hospital. ii. Education Hospital. This investigation provided strength points to this thesis and supported additional improvements to the structure of programming the related.

102

Chapter Five Conclusions and Suggestions for Future Work

5.1 Conclusions The following important points are concluded from the implementation of the proposed EHS in this thesis: 1. The results obtained from the implementation of the proposed ehealthcare system show effectively in the reduction of important factors such

as:

process-consumed-time,

overhead-effort,

consumed-cost,

reducing the issues of conjunction traffic, and even decreasing the side effects of environment causes, reduce health & safety hazards.

2. Depending on the obtained results from this system that proved by evaluator software called Wireshark, the performance of the system using 3TA was more accurate than that of 2TA. As a result of using two servers in 3TA, high security is provided by splitting both of application-server and DB-server. Adding to that, using OPNET simulator as a professional evaluation and designing tool and an important performance evaluation tool indicated the efficiency of 3TA than that of 2TA.

103

Chapter-5

Conclusions and Suggestions for Future Work

5.2 Suggestions for Future Work The following suggestions can be taken into consideration for future research work: 1. Designing and implementing human resource management system related to the administration part. Applying the details proposed by this system about additional services such as: emergency section, operation rooms.

2. Adding facility of video conference as a communication stage between patient and doctors (in case when it is necessary for the doctor to talk online to the patient). Also, adding additional services to the current EHS that communicates between the emergency unit and the ambulances via GPS system to determine the correct position of the patients when this unit receives the emergency call. 3. Depending on the proposed system that has been designed, implemented and evaluated, the next phase will be connecting the hospitals within each city together. This step can be applied after walking big steps in the direction of e-government applications. And hence, these cities can be connected together to build an efficient e-healthcare system.

104

References [1]

Sung-Ho A.,V. Joseph, J. kwak., K. Lee ,and D. Kim, "Embedded Healthcare System based on SIP using Telephone ", Embedded Software Technology Center CSTL/ETR, pp. 813-817, 2003.

[2]

Nam-Ho K.,Y. Jeong, S. Song.,and D. Shin, "Middleware Interoperability based Mobile Healthcare System", ISBN 978-895519-131-8 93560, pp.209-213, Feb. 12-14, 2007 ICACT, 2007 .

[3]

Firat K.,G. Miao, L. E. Moser ,and P. M. Melliar,"A Distributed Ehealthcare System Based on the Service Oriented Architecture", IEEE International Conference on Services Computing 0-7695-29259/07, (SCC 2007).

[4]

Debkumar P., S.Ray, J. Mukhopadhyay, B. Majumdary, and A. K. Majumdar ,"Achieving E-health Care in a Distributed EHR System", IEEE Transaction, 978-1-4244-5014-5, pp. 101-107, 2009.

[5]

Jinyuan S., Y. Fang, and X. Zhu, " Privacy And Emergency Response In E-healthcare Leveraging Wireless Body Sensor Networks ", IEEE Wireless Communications, pp. 66-73, February 2010.

[6]

Lili S., and H.Wang, "A Purpose Based Usage Access Control Model for E- Healthcare Services", IEEE Transaction, 978-1-45770866-4/11, pp. 41-46, 2011.

[7]

Masaomi O, "The Characteristics of the use of Twitter by Beginners", IEEE Transaction, 978-1-4577-0653-0/11, pp. 12681273, 2011.

[8]

Jaya R., A. Das, and N. Iyengar,"A Small E-health Care Information System with Agent Technology", IEEE Transaction, DOI 10.1109/CICN, pp. 68-72, 2011.

[9]

Archana T. and Prachi, "Securing E-healthcare applications with PPS and PDS" IEEE Transaction, DOI 10.1109/ACCT, pp. 45-49, 2013.

[10]

Ndibanje B., G. Hwang, and H. Lee , "A Hybrid and Fast Authentication Protocol for Handoff Support in E-healthcare Systems among WSNs " IEEE Transaction, ICTC, pp. 72-77, 2013. 105

References

[11]

Ndibanje B., M. Sain, and H. Lee, "A Support Middleware Solution for e-Healthcare System Security”, ISBN 978-89-968650-3-2, ICACT, pp. 44-47, February 16-19, 2014.

[12]

Qinghua S., X. Liang, X. Shen, X. Lin, and H. Luo, " A Reliable and Efficient Cloud Cooperation Scheme in E-healthcare", 978-1-47991353-4/13, Crown, pp.2736-2741, 2013.

[13]

Lazar R., Y. Huang, and A. Rizvi, "Strategic IT Alignment in Swedish Public Healthcare System " M.D. Lytras et al. (Eds.): WSKS 2008, LNAI 5288, pp. 105– 113, Springer-Verlag Berlin Heidelberg 2008, pp.105-113, 2008.

[14]

Mark C., "An Integrated Framework For Home Delivery " UMI Number: 1504129, August, 2011.

[15]

Oguntunde B. ,and M. Odim ,”A framework for a multi-tier Internet Service architecture for doctors’ directory”, International Journal of Computers & Technology , ISSN 2277-3061, Volume 4 No. 2, pp.184-191, March-April, 2013.

[16]

Gheyath M., "Tiered Architecture Performance Analysis of Webbased Healthcare Systems"University of zakho degree of master of science in computer scienc, 2014.

[17]

Nawzat S., and N. Yasin, “ Factors Affecting Cooperation Among physicians in Sharing Information Within The Hospital environment: A study Of Two Hospitals ”, Journal of Computer Science 10 (5),pp.794-808, ISSN 1549-3636 , Science Publications, 2014.

[18]

Jean C., ''Implementing e-Health in Developing Countries Guidance and Principles '' ITU 2008 International Telecommunication Union (ITU), Geneva, 2008.

[19]

Baosheng Y., Z. Rong, and J. Xiao, "A Data Integration Approach to E-healthcare System" IEEE 1-4244-1120-3/07 ,pp.1129-1132, 2007. 106

Healthcare

References

[20]

Akunyili D.,”ICT and E-government” The World Congress on Information Technology, Amasterdam, The Netherlands 25th- 27th may 2010. URL http://www.goafrit.wordpress.com/2010/06/12/ictand-e-government-in-nigeria- prof-akunyili/Access Date: 20 July 2014.

[21]

Mandip S., ”Development of 3 Tier Revenue Forecasting System”, MSc thesis, Computer Science Department, University of Greenwich, 2001.

[22]

Ilaria E., and E. Guezel, ”E-government and e-health portals”, Information Systems Research Group, Department of Informatics, University of Fribourg, pp.1-31, 7 December 2007.

[23]

Mohammed A.,"E-government principles: implementation, advantages and challenges" ,Nathan Campus, Griffith University, pp.1-16, 2012.

[24]

Sanderson S., ”Electronic Health Records in the Physician Office”, McKesson Corporation, pp.70- 107,2007.

[25]

Misha K., J. Santos, and M. Takane, "Management of patient information", Global Observatory for e-Health series, 2012.

[26]

Patrick W., "E-healthcare Patient Management Without Walls", Oracle and/or its affiliates, 2010.

[27]

Carina E. and S .Valentin , ” Information Systems As a Business Resource”, Publisher, ISSN 2344 – 3685/ISSN-L 1844 – 7007, pp. 271-274,2014.

[28]

Faraj K., “Design and Implementation of an Automated ERecruitment System”, PhD thesis, Sulamani University, 2009.

[29]

Greenspan J., and B. Bulger, ”Mysql/PHP Database Applications”, M&T Books, 2001.

[30]

Jie Z.," Development Of E-commerce Web Application Using WAMP” ,San Diego State University, 2010.

[31]

Hemke M., and A. P Hudson, "Ubuntu Unleashed 2011 Edition" Library of Congress Cataloging-in-Publication, USA, 2010. 107

References

[32]

Wolff F., and U. Frank,” A Multi-Perspective Framework for – Source Evaluation Conceptual Models In Organizational Change”, University of Minnestoa, 2001.

[33]

Prakash R., R. Anala, and G. Shobha, ” Performance analysis of transport protocol during Live migration of virtual machines e”,ISSN : 0976-5166,Vol. 2 No. 5, pp. 715-722, Oct-Nov 2011 .

[34]

Richard S., and E. Warnicke, ”Wireshark User's Guide for Wireshark 1.7” published by the Free Software Foundation, NS Computer and +Services P/L Ed Warnicke , 2011.

[35]

OPNET Technologies, Inc, "OPNET: Text And Image Sources, Contributors, And Licenses" http://www.riverbed.com/products/performance-managementcontrol/opnet.html?redirect=opnet, Dec. 2012.

[36]

Jarmo P., "OPNET Network Simulator", Simulations and Tools for Telecommunications 521365S, Tietotalo, University of Oulu, 22.04.2008.

[37]

Tommy S., and P. Alex, "OPNET Modeler Development of laboratory exercises based on OPNET Modeler", Master thesis MEE 03:24 , pp.1-268, June 2003.

108

Journal of Zankoy Sulaimani – Part A For Pure and Applied Sciences (JZS-A) ISSN 1812-4100 Issued by the University of Sulaimani www.univsul.edu.iq Ref: (469) Date: (19-4-2015)

Notification of Acceptance Dears (Roshna Mohammed M. Amin1, Dr. Subhi R. M. Zeebaree2) 1

(Roshna): Mathematic Dept.-Educational Science-Sulaimani University , Sulaimani, KurdistanIraq. 2

(Subhi): IT Dept.-Akre Technical College-Duhok Polytechnic University, Duhok, KurdistanIraq Paper Code: (JZS-469). We are very pleased to inform you that your paper titled; (Performance Analysis of 2TA and 3TA Web-based Healthcare Systems Using Different Operating Systems) is accepted by our Editor-in-chief for our journal Journal of Zankoy Sulaimani – Part A (JZS-A), and it will be published in Vol.(17), No.(3), (2015).

With kind regards,

Prof.Dr. Karwan Hama Faraj Jwamer Secretary of Journal Journal of Zankoy Sulaimani-Part A (JZS-A) University of Sulaimani, Sulaimani, Kurdistan Region, Iraq Email: [email protected]

Appendix-A: Database Design

A-1

Appendix-A

Database Design

A-2

Appendix-A

Database Design

CREATE DATABASE `Hospital System` Table structure for table `doctor_appointment` CREATE TABLE `doctor_appointment` ( `num` bigint(20) NOT NULL auto_increment, `Did` varchar(7) character set utf8 collate utf8_unicode_ci NOT NULL, Àdate` date NOT NULL, Àtime` varchar(10) character set utf8 collate utf8_unicode_ci NOT NULL, `Pid` varchar(7) character set utf8 collate utf8_unicode_ci NOT NULL, `status` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=79 ; ---------------------------------------------------------Table structure for table `doctor_prescription` CREATE TABLE `doctor_prescription` ( `no` bigint(20) NOT NULL auto_increment, `Pid` varchar(6) NOT NULL, `Did` varchar(6) NOT NULL, `PharmacyN` varchar(30) NOT NULL, `medicine` text NOT NULL, `dosage` varchar(20) NOT NULL, `TimesPerDay` varchar(20) NOT NULL, `BAeat` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `Pre_date` date NOT NULL, `status` varchar(6) NOT NULL, PRIMARY KEY (`no`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=36 ; ---------------------------------------------------------Table structure for table `patients_info` CREATE TABLE `patients_info` ( `Pid` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `Pname` varchar(40) character set utf8 collate utf8_unicode_ci NOT NULL, `Ppassword` varchar(10) character set utf8 collate utf8_unicode_ci NOT NULL, `Paddress` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `Psex` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `Pdob` date NOT NULL, `Pmobile` int(18) NOT NULL, `Poccupation` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `work_place` varchar(65) character set utf8 collate utf8_unicode_ci NOT NULL, `Pemail` varchar(25) character set utf8 collate utf8_unicode_ci NOT NULL, `Pneighbor` varchar(35) character set utf8 collate utf8_unicode_ci NOT NULL, `Nmobile` varchar(18) NOT NULL, PRIMARY KEY (`Pid`)) ENGINE=InnoDB DEFAULT CHARSET=latin1; ---------------------------------------------------------Table structure for table `staff_info` CREATE TABLE `staff_info` ( `Did` varchar(6) collate utf8_unicode_ci NOT NULL, `Dname` varchar(40) collate utf8_unicode_ci NOT NULL, `Dpassword` varchar(10) collate utf8_unicode_ci NOT NULL, `Daddress` varchar(30) collate utf8_unicode_ci NOT NULL, A-3

Appendix-A

Database Design

`Dsex` varchar(6) collate utf8_unicode_ci NOT NULL, `Ddob` varchar(20) collate utf8_unicode_ci NOT NULL, `Dmobile` varchar(18) collate utf8_unicode_ci NOT NULL, `certificate` varchar(100) collate utf8_unicode_ci NOT NULL, `work_place` varchar(20) collate utf8_unicode_ci NOT NULL, `Demail` varchar(25) collate utf8_unicode_ci NOT NULL, `holidays` varchar(50) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`Did`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; --------------------------------------------------------Table structure for table èmergency_section` CREATE TABLE èmergency_section` ( ìd` bigint(20) NOT NULL auto_increment, `name` varchar(40) character set utf8 collate utf8_unicode_ci NOT NULL, àddress` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `gender` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `dob` varchar(20) character set utf8 collate utf8_unicode_ci NOT NULL, `mobile` int(18) NOT NULL, `work_place` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, PRIMARY KEY (ìd`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ; --------------------------------------------------------Table structure for table `medical_diagnosis` CREATE TABLE `medical_diagnosis` ( ìd` bigint(20) NOT NULL auto_increment, `Pid` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `Did` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `disease_type` varchar(50) character set utf8 collate utf8_unicode_ci NOT NULL, `diagnosis_detail` text character set utf8 collate utf8_unicode_ci NOT NULL, `diagnosisDate` varchar(12) character set utf8 collate utf8_unicode_ci NOT NULL, `patient_case` varchar(25) character set utf8 collate utf8_unicode_ci NOT NULL, `status` varchar(10) character set utf8 collate utf8_unicode_ci NOT NULL, PRIMARY KEY (ìd`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=36 ; --------------------------------------------------------Table structure for table `phar1_drugs` CREATE TABLE `phar1_drugs` ( `barcode` varchar(13) NOT NULL, `name` varchar(35) NOT NULL, `category` varchar(20) NOT NULL, èxpire` varchar(12) character set utf8 collate utf8_unicode_ci NOT NULL, `sell_price` int(11) NOT NULL, `balance` int(11) NOT NULL default '0', PRIMARY KEY (`barcode`)) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------Table structure for table `phar1_invoice_detail` CREATE TABLE `phar1_invoice_detail` ( àuto_no` bigint(20) NOT NULL auto_increment, `counter` bigint(20) NOT NULL, `barcode` varchar(18) collate utf8_unicode_ci NOT NULL, A-4

Appendix-A

Database Design

èxpire` date NOT NULL, `b_price` int(11) NOT NULL, `qty` int(11) NOT NULL, PRIMARY KEY (àuto_no`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=8 ; -- -------------------------------------------------------Table structure for table `phar1_invoice_entry` CREATE TABLE `phar1_invoice_entry` ( `counter` bigint(20) NOT NULL, `dat` date NOT NULL, `bill_no` varchar(12) collate utf8_unicode_ci NOT NULL, `bill_date` date NOT NULL, `provider` varchar(45) collate utf8_unicode_ci NOT NULL, `bill_total` bigint(11) NOT NULL, `note` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`counter`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; -- -------------------------------------------------------Table structure for table `phar_categories` CREATE TABLE `phar_categories` ( `phar_name` varchar(25) NOT NULL, `categories` varchar(20) NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1; ---------------------------------------------------------Table structure for table `phar_providers` CREATE TABLE `phar_providers` ( `phar_name` varchar(25) NOT NULL, `providers` varchar(45) character set utf8 collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1; ---------------------------------------------------------Table structure for table `sells_phar1` CREATE TABLE `sells_phar1` ( `barcode` varchar(18) NOT NULL, `name` varchar(35) NOT NULL, `price` int(11) NOT NULL, `qty` varchar(5) NOT NULL, `dat` date NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1; ---------------------------------------------------------Table structure for table `contact_us` CREATE TABLE `contact_us` ( `counter` bigint(20) NOT NULL auto_increment, ìd` varchar(7) collate utf8_unicode_ci NOT NULL, `name` varchar(35) collate utf8_unicode_ci NOT NULL, èmail` varchar(45) collate utf8_unicode_ci NOT NULL, `content` text collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `readed` varchar(4) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`counter`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=23 ; ---------------------------------------------------------Table structure for table `xray_section` CREATE TABLE `xray_section` ( `num` bigint(20) NOT NULL auto_increment, `Pid` varchar(8) character set utf8 collate utf8_unicode_ci NOT NULL, `Did` varchar(8) character set utf8 collate utf8_unicode_ci NOT NULL, `d_note` text character set utf8 collate utf8_unicode_ci NOT NULL, `xray_d` varchar(25) character set utf8 collate utf8_unicode_ci NOT NULL, A-5

Appendix-A

Database Design

`xray_note` text character set utf8 collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `xray_type` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `body_part` varchar(25) character set utf8 collate utf8_unicode_ci NOT NULL, `status` varchar(6) character set utf8 collate utf8_unicode_ci NOT NULL, `readed` varchar(4) character set utf8 collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=36 ; --------------------------------------------------------Table structure for table `xray_section_ultrasound` CREATE TABLE `xray_section_ultrasound` ( `num` bigint(20) NOT NULL, ùltrasound_result` longtext collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; ----------------------------------------------------------Table structure for table àdmin_login_control` CREATE TABLE àdmin_login_control` ( ùsername` varchar(10) character set utf8 collate utf8_unicode_ci NOT NULL, `password` varchar(8) character set utf8 collate utf8_unicode_ci NOT NULL, `name` varchar(30) character set utf8 collate utf8_unicode_ci NOT NULL, `priviledge` varchar(20) character set utf8 collate utf8_unicode_ci NOT NULL, PRIMARY KEY (ùsername`)) ENGINE=InnoDB DEFAULT CHARSET=latin1; -----------------------------------------------------------Table structure for table `cytology_lab` CREATE TABLE `cytology_lab` ( `num` bigint(20) NOT NULL auto_increment, `Pid` varchar(8) collate utf8_unicode_ci NOT NULL, `Did` varchar(8) collate utf8_unicode_ci NOT NULL, `d_note` text collate utf8_unicode_ci NOT NULL, èxaminer_note` text collate utf8_unicode_ci NOT NULL, èxaminer` varchar(35) collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `test_type` varchar(12) collate utf8_unicode_ci NOT NULL, `status` varchar(6) collate utf8_unicode_ci NOT NULL, `readed` varchar(4) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=10 ; -- -------------------------------------------------------Table structure for table `cytology_lab_res_gse` CREATE TABLE `cytology_lab_res_gse` ( `num` bigint(20) NOT NULL, `color` varchar(15) collate utf8_unicode_ci NOT NULL, `RBC` varchar(20) collate utf8_unicode_ci NOT NULL, `pus_cells` varchar(20) collate utf8_unicode_ci NOT NULL, `cyst` varchar(20) collate utf8_unicode_ci NOT NULL, òva` varchar(20) collate utf8_unicode_ci NOT NULL, òthers` varchar(20) collate utf8_unicode_ci NOT NULL

A-6

Appendix-A

Database Design

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; ---------------------------------------------------------Table structure for table `cytology_lab_res_gue` CREATE TABLE `cytology_lab_res_gue` ( `num` bigint(20) NOT NULL, àppearance` varchar(15) collate utf8_unicode_ci NOT NULL, `sp_gravity` varchar(15) collate utf8_unicode_ci NOT NULL, `reaction` varchar(15) collate utf8_unicode_ci NOT NULL, àlbumin` varchar(15) collate utf8_unicode_ci NOT NULL, `sugar` varchar(15) collate utf8_unicode_ci NOT NULL, `kitten_bodies` varchar(15) collate utf8_unicode_ci NOT NULL, `bile_pigment` varchar(15) collate utf8_unicode_ci NOT NULL, ùrobinogen` varchar(15) collate utf8_unicode_ci NOT NULL, `leukocytes` varchar(15) collate utf8_unicode_ci NOT NULL, `blood` varchar(15) collate utf8_unicode_ci NOT NULL, `RBC` varchar(15) collate utf8_unicode_ci NOT NULL, `pus_cells` varchar(15) collate utf8_unicode_ci NOT NULL, `casts` varchar(15) collate utf8_unicode_ci NOT NULL, àmorphousurate` varchar(15) collate utf8_unicode_ci NOT NULL, `ca_oxalate` varchar(15) collate utf8_unicode_ci NOT NULL, òthers` varchar(20) collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode -----------------------------------------------------------------------Table structure for table `biochemistry_lab` CREATE TABLE `biochemistry_lab` ( `num` bigint(20) NOT NULL auto_increment, `Pid` varchar(8) collate utf8_unicode_ci NOT NULL, `Did` varchar(8) collate utf8_unicode_ci NOT NULL, `d_note` text collate utf8_unicode_ci NOT NULL, èxaminer_note` text collate utf8_unicode_ci NOT NULL, èxaminer` varchar(35) collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `test_type` varchar(20) collate utf8_unicode_ci NOT NULL, `status` varchar(6) collate utf8_unicode_ci NOT NULL, `readed` varchar(4) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ; ---------------------------------------------------------Table structure for table `biochemistry_lab_results` CREATE TABLE `biochemistry_lab_results` ( ìd` bigint(20) NOT NULL auto_increment, `num` bigint(20) NOT NULL, `test_name` varchar(15) collate utf8_unicode_ci NOT NULL, `result` varchar(10) collate utf8_unicode_ci NOT NULL, ùnits` varchar(10) collate utf8_unicode_ci NOT NULL, `flag` varchar(10) collate utf8_unicode_ci NOT NULL,

A-7

Appendix-A

Database Design

`reference_range` varchar(12) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (ìd`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=19 ; ---------------------------------------------------------Table structure for table `biology_lab` CREATE TABLE `biology_lab` ( `num` bigint(20) NOT NULL auto_increment, `Pid` varchar(8) collate utf8_unicode_ci NOT NULL, `Did` varchar(8) collate utf8_unicode_ci NOT NULL, `d_note` text collate utf8_unicode_ci NOT NULL, èxaminer_note` text collate utf8_unicode_ci NOT NULL, èxaminer` varchar(35) collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `test_type` varchar(20) collate utf8_unicode_ci NOT NULL, `status` varchar(6) collate utf8_unicode_ci NOT NULL, `readed` varchar(4) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=14 ; ---------------------------------------------------------Table structure for table `biology_serology_res` CREATE TABLE `biology_serology_res` ( `num` bigint(20) NOT NULL, `CRP` varchar(15) collate utf8_unicode_ci NOT NULL, `RA_latex` varchar(15) collate utf8_unicode_ci NOT NULL, ÀSO_titter` varchar(15) collate utf8_unicode_ci NOT NULL, `toxoplasmosis` varchar(15) collate utf8_unicode_ci NOT NULL, `pregnancy_test` varchar(15) collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; ---------------------------------------------------------Table structure for table `biology_virology_res` CREATE TABLE `biology_virology_res` ( `num` bigint(20) NOT NULL, `HBs_Ag` varchar(15) collate utf8_unicode_ci NOT NULL, `HCV_Ab` varchar(15) collate utf8_unicode_ci NOT NULL, `HIV` varchar(15) collate utf8_unicode_ci NOT NULL, `HBs_Ab` varchar(15) collate utf8_unicode_ci NOT NULL, `HBe_Ag` varchar(15) collate utf8_unicode_ci NOT NULL, `HBe_Ab` varchar(15) collate utf8_unicode_ci NOT NULL, `HBc_Ab` varchar(15) collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; ---------------------------------------------------------Table structure for table `biology_widal_res` CREATE TABLE `biology_widal_res` ( `num` bigint(20) NOT NULL, `typhi_O` varchar(15) collate utf8_unicode_ci NOT NULL, `typhi_H` varchar(15) collate utf8_unicode_ci NOT NULL,

A-8

Appendix-A

Database Design

`paratyphi_AO` varchar(15) collate utf8_unicode_ci NOT NULL, `paratyphi_AH` varchar(15) collate utf8_unicode_ci NOT NULL, `paratyphi_BO` varchar(15) collate utf8_unicode_ci NOT NULL, `paratyphi_BH` varchar(15) collate utf8_unicode_ci NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; ---------------------------------------------------------Table structure for table `hematology_lab` CREATE TABLE `hematology_lab` ( `num` bigint(20) NOT NULL auto_increment, `Pid` varchar(8) collate utf8_unicode_ci NOT NULL, `Did` varchar(8) collate utf8_unicode_ci NOT NULL, `d_note` text collate utf8_unicode_ci NOT NULL, èxaminer_note` text collate utf8_unicode_ci NOT NULL, èxaminer` varchar(35) collate utf8_unicode_ci NOT NULL, `dat` date NOT NULL, `test_type` varchar(20) collate utf8_unicode_ci NOT NULL, `status` varchar(6) collate utf8_unicode_ci NOT NULL, `readed` varchar(4) collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`num`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=10 ; ---------------------------------------------------------Table structure for table `hematology_lab_results` CREATE TABLE `hematology_lab_results` ( `num` bigint(20) NOT NULL, `HB` varchar(10) collate utf8_unicode_ci NOT NULL, `PCV` varchar(10) collate utf8_unicode_ci NOT NULL, `RBC` varchar(10) collate utf8_unicode_ci NOT NULL, `MCV` varchar(10) collate utf8_unicode_ci NOT NULL, `MCHC` varchar(10) collate utf8_unicode_ci NOT NULL, `MCH` varchar(10) collate utf8_unicode_ci NOT NULL, `BG` varchar(10) collate utf8_unicode_ci NOT NULL, `CT` varchar(10) collate utf8_unicode_ci NOT NULL, `BT` varchar(10) collate utf8_unicode_ci NOT NULL, `total` varchar(10) collate utf8_unicode_ci NOT NULL, `neutrophils` varchar(10) collate utf8_unicode_ci NOT NULL, `lymphocytes` varchar(10) collate utf8_unicode_ci NOT NULL, `monocytes` varchar(10) collate utf8_unicode_ci NOT NULL, èosinophils` varchar(10) collate utf8_unicode_ci NOT NULL, `basophilic` varchar(10) collate utf8_unicode_ci NOT NULL, èsr` varchar(10) collate utf8_unicode_ci NOT NULL, `platelets` varchar(10) collate utf8_unicode_ci NOT NULL, `reties` varchar(10) collate utf8_unicode_ci NOT NULL, ìmmature` varchar(50) collate utf8_unicode_ci NOT NULL, KEY `num` (`num`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

A-9

Appendix-B: Network Mechanism Using OPNET Simulator

Steps in general form to connect any network using OPNET simulator 1. Network contains many computers work as a clients connected by each other using transmission medium and network devices such as switch, router, hub….etc. And also one server or more depending on the proposed network. 2. Transmission mediums that used to connect the network were twisted pair cables with data rate equal to 100 Megabits/sec which means data are transmitted 100 mega per one second . 3. The servers that connected to the network were HTTP and DataBase servers. The HTTP server has been assumed to be (Heavy browsing) while the Database server to be (High Load Database). 4. Many parameters such as delay (sec.) and Load (bits/sec.) are used to measure the performance of a complete network.

Steps to create a network and obtain results using OPNET Simulator Project and Scenario: When creating a new network model, you must first create a new project and scenario. Project: A project is a group of related scenarios that each explore a different aspect of the network design. Projects can contain multiple scenarios. Once you have created a new project, you can use the Startup Wizard to set up a new scenario. Adding Components:  If it is not already open, open the object palette by clicking on the Object Palette action button (first button on the left).  Find the Ethernet_client (computers), Switches, ethernet_server and any other devices you want to used it in the network in the palette and drag it into the workspace.  Find the 100 BaseT link object in the palette, click on it and drag it to the workspace B-1

Appendix-B

Network Mechanism Using OPNET Simulator

Finally, you need to add configuration objects to specify the application traffic that will exist on the network  Find the Application Config object in the palette and drag it into the workspace.  Right-click to indicate you are finished placing this kind of object.  Find the Profile Config object in the palette and drag it into the workspace.  Close the object palette Statistics:  Now that you added the traffic, you are ready to collect some statistics.  There are two ways to collect statistics: A. You can collect statistics from individual nodes in your network (object statistics). B. From the entire network as a whole (global statistics) Global Statistics: Global statistics can be used to gather information about the network as a whole. For example, you can find out the delay for the entire network by collecting the global Delay statistic:  Right-click in the project workspace and select Choose Individual Statistics from the Workspace pop-up menu.  Click the plus sign next to Global Statistics in the Choose Results dialog box.  Click the plus sign next to Ethernet.  Check the box next to Delay (sec) to turn on collection.  Click OK to dismiss the Choose Results dialog box Run the Simulation: Now that you have specified the network, traffic, statistics to collect and saved the project, you are ready to run your simulation. To run a simulation:  From the Simulation menu, choose Configure Simulation. Note: You can also open the Configure Simulation dialog box by clicking on the Configure Simulation action button.  Type for example 1 hour in the Duration.

B-2

Appendix-B

Network Mechanism Using OPNET Simulator

View Results: To view the server Ethernet load for example of the simulation:  Right-click on the server node choose View Results from the server’s Object pop-up menu. The node’s View Results dialog box opens.  Click on the arrow next to Ethernet under Office network.  Click on the box next to Load (bits/sec) to indicate that you want to view that result.  Click the Show button in the View Results dialog box. The graph of the server load appears in the Project Editor

B-3

‫تصميم وتهفير‪ -‬نظام املوشع للسعاية الصحية األلكرتونية بهاءً‬ ‫على مبادئ تطبيكات احلكومة األلكرتونية‬

‫زضالة‬ ‫مكدمة اىل جملظ كلية التجازة ‪ -‬جامعة الطليمانية‬ ‫كجصء مو متطلبات نيل دزجة املاجطتري علوم يف‬ ‫تكهولوجيا املعلومات‬

‫مو قبل‬ ‫زوشها حممد حممد امني‬

‫بأشساف‬ ‫الدكتوز صبحى زفيل حممد‬ ‫األضـتاذ املطاعد‬

‫جمادي الثانً ‪1436‬‬

‫حزٌران ‪2015‬‬

‫ثوختة‬ ‫شةردةمى تةكهوَلوجياى نوىَ ثيَشكةوتهيَكى زوَرى لةطةلَ خوَى ييَها لة زوَر ئاراشتةدا بوَ يةموو‬ ‫كوَمةلَطا‪،‬يةكيَك لةو كوَمةلَطايانة كوَمةلَطاى يةريَنى كوردشتانى عيَراقة (‪ .)KR‬شةربارى ثيَشكةوتهى شيصتةمى‬ ‫ضاوديَرى تةندروشتى لة يةريَنى كوردشتاى بةالَم شيصتةميَكى شةرةتايى ية وة كيَشةى يةية بةدةشت‬ ‫ثروَشةيةكى خاو كة بوةتة يوَى بة فريوَدانى كات و ثارة و ماندوو بونى نةخوَش و كارمةندى تةندروشتى‪.‬‬ ‫ئةم ماشتةر نامةية ثيَشهيازيَك ثيَش كةش ئةكات بة ناوى شيصتنى ضاوديَرى ئةلكرتونى )‪ (EHS‬كة‬ ‫مةبةشتى لة طةرِانةوةى كاتة بوَ نةخوَش و كارمةندانى تةندروشتى‪,‬وة بة ِريَوة دةبريَت لة اليةى‬ ‫شةرثةرشتياريَكى مالَجةرى ئةنتةرنيتةوة‪,‬ئةم شيصتةمة تايبةمتةنديةكى طرنطى تياداية ئةويش يةموو‬ ‫زانياريةكاى لة مالَجة ِريَكداية كة ئةطات بة كوَمةلَطا لة ِريَطةى ئةنتةرنيَتةوة‪.‬‬ ‫ئةةةةم شيصةةةتةمة مامةلَةةةة ئةةةةكات لةطةةةةلَ يةةةةردوو ديسايهةةةى )‪(2TA‬‬

‫و )‪ (3TA‬كةةةة لةةةةم ماشةةةتةر‬

‫نامةيةةةةدا تةةةوانرا ديةةةسايو بكريَةةةت و جةةة َى بةةةةج َى بكريَةةةت وة شيصةةةتنى )‪ (EHS‬بةتةةةةواوةتى شيصةةةةتنى‬ ‫ضةةةاوديَرى تةندروشةةةتى ئةةةةكات بةةةة شيصةةةتنيَكى ئوَتوَمةةةاتيكى ‪ .‬بةةةةكار ييَهةةةانى كا ةةةةز لةةةة فةرمانطةةةةكانى‬ ‫تةندروشةةةةتى دا ناميَهيَةةةةت و كةةةةاتيَكى زوَرى بةةةةةفريوَ دراو ئةطة ِريَتةةةةةوة وة يةةةةةروةيا يةةةةةموو بةشةةةةةكانى‬ ‫فةرمانطةكةةةةةة يةةةةةة ئةةةةةةخات وة (نةخوَش‪,‬ثسيشك‪,‬دةرماخنانة‪,‬تاقيطة‪,‬تيشك‪,‬بةشةةةةةى ثيَشةةةةةوازى‪,‬كارطيَرى) وة‬ ‫لةطةةةةلَ بةةةةردةوامى ئةةةيش كردنةةةى شيصةةةتةمةكة ‪.‬شةرجنرِاكيَشةةةى ئةةةةم شيصةةةتةمة لةوةدايةةةة كةةةة شةةةةردانى‬ ‫نةةةةةخوَش بةة ة َو نةخوَشةة ة انة كةةةةةم دةكاتةةةةةوة ئةةةةةويش لةةةةة رِِِيَطةةةةةى ئةنتةرنيَتةةةةةوة ئاشةةةةانكارى كةةةةراوة بةة ةوَ‬ ‫نةخوَش‪.‬‬ ‫ليًَاتووى و ضوشتى شيصتةمةكة ثشت دةبةشتيَت بة دوو تةكهيكى جياواز يةكةم تةكهيك ثشت بةشرتاوة‬ ‫بةثروَطرامى )‪ ( PHP‬كة نوشيهى كوَدةكانى شيصتنةكةية وة تةكهيكى دووةم بةكارييَهانى شوَفت ويَرى‬ ‫ئامادةكراوى )‪ (Wireshark‬ئةم دوو تةكهيكة يارمةتى شيصتةمةكة دةدات كة كةمرتيو كاتى بةكارياتوو‬ ‫بدوَزيَتةوة لة يةردوو ديسايهى )‪(2TA‬و)‪ (3TA‬لة )‪ (Operating system‬ى دوو ظيَرذنى جياواز‬ ‫)‪ (Windows-7‬و )‪(Linux-Ubuntu version 14.04‬‬ ‫يةلَصةنطاندنى ليًَاتووى ت َورِةكة ثشت دةبةشتيَت بة بةكار ييَهانى ئامرازي )‪ (OPNET‬تا شيصتةمةكة‬ ‫بجشكهيَت لةطةلَ ت َورِى طةورةدا بوَ يةردوو ديسايهى )‪ (2TA‬و )‪.(3TA‬‬ ‫ئةجنامى كارةكة نيشانياى دا كة )‪ (3TA‬بةييَسترة لة )‪ (2TA‬لة ثاراشتهى داتا و كةمى كاتى بةكارياتوو‬ ‫ئةويش بة دابةش كردنى شيَرظةر بة دوو بةشةوة )‪ (http-server‬و)‪ (database-server‬ئةمةش وا‬ ‫ئةكات كة بةدةشتى بًيَهيَت ليًَاتوى و ضاالكى بوَ شيصتنةكة‪ .‬وة مامةلَة بكات لةطةلَ توَرى زوَر طةورة بة‬ ‫يةزاراى ياى مليَونةيا بةكارييَو‪.‬‬

‫ملخص‬ ‫عصر التكنولوجٌا الجدٌد تحسن فً اتجاهات عدٌدة لجمٌع المجتمعات‪ ،‬وأحد هذه المجتمعات‬ ‫هو مجتمع إقلٌم كوردستان‪-‬العراق )‪ . (KR‬قبل هذا العصر كانت الرعاٌة الصحٌة فً ‪ KR‬نظام‬ ‫تقلٌدي‪ .‬لكون نظام الرعاٌة الصحٌة هنا كان والٌزال نظام تقلٌدي‪ ،‬فإن عملٌة الرعاٌة الصحٌة‬ ‫تعانً باستمرار من كونها عملٌة الخطى البطٌئة وتستهلك الصحة والسالمة‪ ،‬والوقت والمال‪.‬‬ ‫وبالتالً‪ٌ ،‬تحتم على المرضى والعاملٌن فً الرعاٌة الصحٌة القٌام بالكثٌر من الجهود والنشاط‬ ‫البدنً لالتصال فٌما بٌنهم‪.‬‬ ‫هذه األطروحة تقدم نظام مقترح للرعاٌة الصحٌة اإللكترونٌة (‪ )EHS‬التً تتعامل مع توافر‬ ‫الوقت الحقٌقً‪ ،‬وٌتم التحكم من قبل مسؤول‪ .‬وٌوفر هذا النظام مٌزة أن جمٌع النماذج تتكامل فً‬ ‫صفحة رئٌسٌة واحدة ومتصلة بواسطة طرٌقة توصٌة‪-‬االرتباط التشعبً غٌر ذكٌة‪ .‬وٌتناول‬ ‫النظام المقترح مع كال فئتً المعمارٌة )‪ (2TA‬ثالثة فئات المعمارٌة )‪ (3TA‬وقد تم تصمٌم هذه‬ ‫البنى وتنفٌذها فً هذه األطروحة‪ .‬و ‪ EHS‬المقترح ٌسهل أتمتة كامل نظام الرعاٌة الصحٌة تماما‬ ‫والقضاء على العمل بالنظام الورقً وٌوفر الوقت وأٌضا دمج أقسام مركز الرعاٌة الصحٌة (أي‬ ‫المرضى واألطباء‪ ،‬الصٌدلٌات‪ ،‬فنً األشعة‪ ،‬المختبرات‪ ،‬موظف استقبال‪ ،‬إداري) مع توافر‬ ‫الخدمة اونالٌن‪ .‬فً النظام القائم تم أعتماد أسالٌب ذكٌة تعتمد على التوفٌق بٌن المرضى‬ ‫واألطباء‪ .‬جاذبٌة النظام المقترح هو تجنب معظم ما قبل الزٌارة المرٌض وبعد الزٌارة كما‬ ‫ٌستطٌع المرٌض حجز المواعٌد والحصول على النتٌجة من المختبر اختبارات عبر اإلنترنت‪.‬‬ ‫من أجل تحدٌد كفاءة الخادم (زمن االستجابة وتدفق البٌانات) تم أعتماد تقنٌتٌن مختلفتٌن‪ .‬التقنٌة‬ ‫األولى هً الطرٌقة التقلٌدي للكتابة الٌدوٌة بواسطة البرنامج التشعبً )‪ (PHP‬رمز البرنامج‬ ‫النصً‪ ،‬والثانً هو تطبٌق جاهز وهً )‪.Wireshark (Network Protocol Analyzer‬‬ ‫وستساعد التقنٌتٌن فً معرفة أقل وقت األستجابة مع ‪ 2TA‬و‪ ، 3TA‬مع منصات مختلفة ألنظامة‬ ‫التشغٌل )‪ (OS‬التً هً)‪ (Microsoft Windows-7‬مع )‪(OS Linux-Ubuntu14.04‬‬ ‫لتقٌٌم كفاءة الشبكة‪ ،‬تم أعتماد أداة محاكاة المهنٌة األمثل أداة هندسة الشبكات )‪ (OPNET‬وذلك‬ ‫للتحقق من النظام مع الشبكات الكبٌرة لكال )‪ (2TA‬و ‪.. (3TA‬‬ ‫وأظهرت النتائج بأن ‪ 3TA‬أقوى من ‪ 2TA‬من حٌث حماٌة البٌانات والوقت المستغرق وذلك‬ ‫عن طرٌق تقسٌم الخدمات بٌن كال من( ‪ )http-server‬و(‪ .(database-server‬وبالتالً‬ ‫فإنه سٌتم توفٌر المزٌد من األداء خصٌصا عند التعامل مع شبكات واسعة جدا مع اآلالف (أو‬ ‫المالٌٌن) من العمالء‪.‬‬

Design and Implementation of a Distributed e ...

Design and Implementation of a Distributed e ...

Suggest Documents

Design and Implementation of a Distributed ... - People.csail.mit.edu

design and implementation of distributed programmable ... - CiteSeerX

Design and Implementation of Distributed Databases ...

Design and Implementation of Three-tier Distributed

Design and reference implementation of a distributed URN ... - RedIRIS

Design and Implementation of a Distributed ... - Semantic Scholar

Design and Implementation of a Secure Distributed Data ... - CiteSeerX

Design and Implementation of a Distributed Router - CiteSeerX

Design and Implementation of a Distributed ... - Semantic Scholar

Design and Implementation of a Secure Distributed Data ... - CiteSeerX

design and implementation of a distributed monitor for ... - CiteSeerX

Design and Implementation of a Distributed File ... - Semantic Scholar

design and implementation of a distributed systems ... - Rochester CS

Design and Implementation of a Distributed Content Management ...

Design and Implementation of a Distributed Content ... - CAC@Rutgers

Design and Implementation of a Distributed Database System ... - ijcer

Design and Implementation of a Practical Secure Distributed ...

Design and reference implementation of a distributed URN registry ...

The Design and Implementation of a Self-Calibrating Distributed ...

Design and Implementation of a Distributed Authenticated ... - Brown CS

Design and Implementation of E-Learning ...

Design and Implementation of E-Learning ...

Design & Implementation of Fuzzy Parallel Distributed ... - viXra

Design and Implementation Issues for A Distributed ...