i

Secure Access of Patient’s Medical and Clinical Data Us-

ing HL7 Protocol

SARA MOHAMED JAWAD AL-FALLOGI

DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OF

MASTER OF COMPUTER SCIENCE

FACULTY OF COMPUTER SCIENCE AND

INFORMATION TECHNOLOGY

UNIVERSITY OF MALAYA

August 2009

ii

ACKNOWLEDGMENTS

First of all, I would like to express my deepest gratitude to my supervisor Dr. Teh Ying

Wah for his help and support throughout this research.

As well as, I would like to express my heartfelt appreciation to my beloved parents, Dr. Al-

Dujaily, Amal and Dr. Al-Fallogi Mohamed J. for their emotional, spiritual and financial

support, and for their endless encouragement and love.

Specifically, I would like to dedicate a deepest thankfulness to my dearest Brother Mr. Al-

Fallogi, Haidar, for his precious help, encouragement and support. I would never been able

to finish this project without him.

Moreover, a would like to devote a special thanks to my real friends, who stood by me all

the way along

iii

Abstract

Undoubtedly, the universal recognition of web-based communication has

become remarkable lately. However, the knowledge of the driving factor of such

communication is yet uncertain for many people. This project examines the mean-

ing of interoperability throughout illustrating two fundamental concepts on how

computers can communicate. Such as: ―functional interoperability‖ and ―semantic

interoperability‖.

Accordingly, the project addresses the topic of adopting a secure protocol, which

specifically designed for healthcare applications. Such protocol guarantees an ap-

propriate communication among healthcare participants with the intention of en-

suring a secure access to patients‘ medical and clinical data. On the other hand,

increases the effectiveness and efficiency of healthcare delivery for the benefit of

all.

The project presents a prototype of user-friendly interface for a web-based appli-

cation. Such interface facilitates an easy access to patients‘ medical and clinical

data across integrated servers that are distributed throughout healthcare arena.

Furthermore, the suggested interface enables patients to access their personal

records remotely, in terms of on line registration, medical consultation, tracing re-

sults and performing payments.

Consequently, having reliable healthcare system would play an important role in

assuring the secure access to patient‘s medical records. This issue has triggered

the critical need for a secure protocol that enables the secure access without

iv

breaching patients‘ confidentiality. Bearing in mind, that comprehensive health-

care system can perform securely according to the expected needs and behavior of

healthcare participants. Therefore, the proposed system has strongly considered

the security as a biggest issue, in sense of overcoming patient‘s fears of nothing is

totally secured.

Ultimately, the proposed prototype has been uploaded into the internet server, in

order to be accessible by physicians and patients beyond the intranet boundaries.

Therefore, implementing such application in the medical arena would possibly

have a remarkable impact on the interoperability among different networks with

high level of information confidentiality.

v

TABLE OF CONTENTS

Page

1. INTRODUCTION

1.1 Chapter Preview ............................................................................................. 1

1.2 Medical and Clinical Records Background ..................................................... 1

1.3 Project description ......................................................................................... 5

1.4 Project potential benefits ................................................................................ 6

1.5 Project challenges .......................................................................................... 6

1.6 Motivation ..................................................................................................... 6

1.7 Scope of research ........................................................................................... 6

1.8 Research objectives ........................................................................................ 7

1.9 Chapter Summary .......................................................................................... 7

2. LITERATURE REVIEW ...................................................................................... 8

2.1 Chapter Review ................................................................................................... 9

2.2 Internet Communication Technology (ICT) ......................................................... 9

2.2.1 Patient-Driven Communication .................................................................. 11

2.2.2 Issues that must be addressed .....................................................................11

2.2.3 Technical issues .........................................................................................14

2.3 Clinical Information System ................................................................................15

2.3.1 Functions of clinical system ........................................................................15

2.3.2 Clinical Information Requirement ...............................................................16

2.3.3 Traditional Healthcare systems ....................................................................16

2.3.4 Web based healthcare system ......................................................................17

2.4 Security Issues .....................................................................................................17

2.5 Electronic records History ....................................................................................18

2.6 HL7 Protocol .......................................................................................................19

2.6.1 Why HL7 ....................................................................................................19

2.6.2 HL7 History ................................................................................................20

2.6.3 Comparison among versions .......................................................................21

2.6.4 Failure of Current Protocol ..........................................................................25

2.7 Choice of proposed solution .................................................................................25

2.7.1 Properties of the proposed solution ...................................................................25

2.7.2 Advanced issues of HL7 ...................................................................................26

vi

2.8 Chapter Summary .............................................................................................. 27

3. METHODOLOGY .............................................................................................. 28

3.1 Chapter preview ................................................................................................. 29

3.2 Chosen Methodology ......................................................................................... 29

3.2.1 HDF background ....................................................................................... 30

3.2.2. HL7 Development Framework: HDF ....................................................... 30

3.2.2.1 Use cases model ..................................................................................... 32

3.2.2.2 Information Models ................................................................................ 32

3.2.2.3 Interaction Models ................................................................................. 32

3.2.2.4 Message Models ..................................................................................... 32

3.3 HDF objectives .................................................................................................. 33

3.3.1 HDF Requirement Framework .................................................................. 34

3.3.2 Requirement Methodology process of HD ................................................. 34

3.3.3 RIM (reference information Model) core classes ....................................... 35

3.4 HL7 V3 and the Flow of Health Information ...................................................... 36

3.5 Chapter Summary .............................................................................................. 40

4. SYSTEM ANALYSIS & REQUIREMENTS ..................................................... 41

4.1 Chapter Preview ........................................................................................... 42

4.1.1 Requirement gathering techniques ............................................................ 42

4.1.2 System requirements analysis .................................................................... 43

4.2. System functional and nonfunctional requirements ........................................... 43

4.2.1 Functional requirements ............................................................................ 43

4.2.2 Non functional requirements ..................................................................... 44

4.3. Tools and techniques proposed ........................................................................ 45

4.3.1 Chosen framework .................................................................................... 45

4.3.2 Chosen web database ................................................................................ 46

4.3.3 Chosen data Access Technology ............................................................... 47

4.3.4 Chosen web server .................................................................................... 47

4.3.5 Chosen development language .................................................................. 48

4.3.6 Chosen development tools ......................................................................... 48

4.4 Hardware and software Requirements ............................................................... 49

4.4.1. Hardware requirements ........................................................................... 49

4.4.1.1 Client side .............................................................................................. 49

4.4.1.2 Server side ............................................................................................. 50

4.4.2 Software Requirements ............................................................................. 50

4.4.2.1 Client side .............................................................................................. 50

4.4.2.2 Server side ............................................................................................. 50

vii

4.5 Chapter Preview ................................................................................................ 51

5. SYTEM ARCHITECTURE & DESIGN ............................................................. 52

5.1 Chapter Preview ................................................................................................ 53

5.1.1 Design Overview ...................................................................................... 53

5.2 System Architecture ........................................................................................... 54

5.3 Chosen development platform ............................................................................ 59

5.4 System Components .......................................................................................... 60

5.5 Implementation .................................................................................................. 74

5.6 Chapter Summary .............................................................................................. 74

6. TESTING & VALIDATION ............................................................................... 75

6.1 Chapter Preview ................................................................................................ 76

6.2 Testing and validation ........................................................................................ 76

6.3 Conclusion ......................................................................................................... 90

6.4 Further Study ..................................................................................................... 91

6.5 Chapter Summary .............................................................................................. 92

REFERENCES ............................................................................................................

viii

LIST OF FIGURES

Figure Page

1 ISO-OSI 7 layer model....................................................................................... 4

2 Clinical Data repository ..................................................................................... 13

3 Without HL7 ―Point-to-Point Interfaces ............................................................ 21

4 reusable HL7 interfaces ...................................................................................... 21

5 HL7 Development Framework ........................................................................... 31

6 Methodology Key concepts ................................................................................ 34

7 RIM Core classes ............................................................................................... 36

8 Structure of HL7 v2.x ........................................................................................ 38

9 Structure of HL7 v3 ........................................................................................... 38

10 Models Phases ................................................................................................. 39

11 Hierarchical Message Descriptions (HMD) ...................................................... 40

12 Microsoft.Net Framework ................................................................................. 46

13 SOA Architecture.............................................................................................. 56

14 Patient‘s main page ........................................................................................... 61

15 Registration Conformation Page ........................................................................ 61

16 Patients‘ Login ................................................................................................. 62

17 Patient‘s Summery record ................................................................................ 63

18 Patient‘s Demographic Information .................................................................. 63

19 Available Doctor‘s contact ............................................................................... 64

20 Payment Page................................................................................................... 65

21 Patient‘s Medical Information .......................................................................... 65

22 Patient‘s Private Record (PPR) ......................................................................... 66

23 Pharmacy‘s Page .............................................................................................. 66

24 Laboratory‘s Page ............................................................................................ 67

25 Doctor‘s Login ................................................................................................. 68

26 Browsing patient‘s PPR ................................................................................... 69

27 Lab order ........................................................................................................ 70

28 X-ray result ...................................................................................................... 71

29 Recommended Medicine .................................................................................. 72

30 Admin Login .................................................................................................... 73

Tables

Table 1 .................................................................................................................. 24

ix

CHAPTER ONE

INTRODUCTION

1

1.1 Chapter Preview

In particular this chapter will emphasize dissertation structure throughout the next

chapters. In which, it demonstrates a background of previous studies and issues of

medical and clinical records and user interfaces. Furthermore identifies previous

and recent methods of exchanging patient‘s data throughout healthcare organiza-

tions. On the other hand, describes the ISO-OSI seven layers Model that identifies a

communication standard protocol which is widely recognized as HL7. This will in-

clude an overview of the protocol establishment and functionality with relation to

the ISO-OSI seven layers Model. Moreover, this chapter will determine the project

description, objectives, motivation, scope, challenges and potential benefits respec-

tively according to the proposed system requirements.

1.2 Medical and Clinical Records Background

Within the last several years, advances in computer technology and the field of in-

formatics have created extraordinary chances for improving the completeness, time-

liness, and quality of public health data. Regardless of their incredible potential,

these chances are accompanied by a new set of challenges. From the scientific pers-

pective, computers can only share information if they communicate through a com-

mon protocol. Likewise, people from various countries with absolutely dissimilar

native tongues are unable to communicate with each other unless they can speak a

common language. From the interoperability perspective, system‘s components are

able to communicate together among different organizations and exchange informa-

tion. In accordance to this hypothesis, the project demonstrates two fundamental

concepts on how medical computers can communicate: Physically ―functional inte-

roperability‖, throughout sending and receiving documents, storing and sharing data

and Information, semantically ―semantic interoperability‖ by sharing a common

language that allows them to share an accepted vocabulary, in order to understand

complex medical conditions and processes (HL7 International, 2007).

2

Previously, medical data was collected with paper, pencil, and exchanged through

manageable transfers of large databases. Clinical data is stored electronically in lit-

erally hundreds of different kinds of information systems. To provide optimal care

for patients, the data needs to be shared between systems. Computer to computer in-

terfaces can help to make this information available when and where it is needed.

Message standards define the structure and content of data that can be exchanged

between systems, as well as the policies and procedures that guide the exchange. In-

terfaces are also essential for communication of data between different healthcare

enterprises and between private institutions and governmental agencies. Data shar-

ing between healthcare associations is important for the public reporting of health,

in terms of gathering data for clinical research as well as managing patients‘ bills

and accounts (Huff, 1998).

Huff (1998) indicated that Message Development Organizations (MDOs) were es-

tablished around 1980‘s. Such organizations intended to identify special standards,

which are specifically designed to perform the electronic exchange of patient‘s clin-

ical data. Given that such organizations aimed to minimize the cost of interfaces in

terms of creating, installing, and maintaining. Consequently, implementing a com-

puterized patient record could result in both time and cost savings for both the pa-

tient and physician. Bearing in mind that a having a clinical data exchange network,

would play an important role in reducing the cost of diagnostic testing and facilitate

better prescribing. According to the Health level international (2007), the HL7

(Healthcare Level Seven) protocol, has been developed in 1987 and was identified

as a communication standard. Such protocol was founded particularly for the

healthcare environment, in order to allow a sufficient communication amongst vari-

ous fields of healthcare organizations. Using HL7 assists in handling healthcare‘s

communication multitasks of among different organization. Meanwhile, improves

the efficiency of the communication process.

The concept idea of HL7 depends on the communication contents and the exchange

formats within the seventh layer (application layer) of the seven-layer model, which

responsible of the communication between open systems. This led to the name

Health Level Seven. Health Level Seven is a leading, global, accredited Standards

3

Development Organization (SDO) operating in the healthcare arena. HL7 domain is

clinical and administrative data. ―Level seven‖ refers to the highest level of the In-

ternational Organization for Standardization (ISO) communications model for Open

Systems Interconnection (OSI) – the application level. The application level ad-

dresses definition of the data to be exchanged, the timing of the interchange, and the

communication of certain errors to the application. The seventh level supports such

functions as security checks, participant identification, availability checks, and ex-

change mechanism negotiations and, most importantly, data exchange structuring

(HL7 International, 2007).

Previous researches have indentified medical interfaces‘ goal as an obvious trans-

mission of information between medical systems. With the accordance to the basic

model of all interfaces, which has been illustrated by the International Standards

Organization Open Systems Interconnection (ISO-OSI) As shown in Figure 1, this

model classified the process of messaging into seven logical layers according to

(Huff, 1998) and (Bailey, 2001). Each layer defines a specific function of transmit-

ting messages between systems. Bailey has discussed the function of each layer of the

ISO-OSI layer Model. The seven layers classified are as follows:

Physical link: This Layer contains both the software and the hardware device driv-

ers for each communication‘s device. Such as interface devices, modems and com-

munication lines. Furthermore defines the mechanical and electrical aspects of inter-

facing to a physical medium for transferring data.

Data link: This layer is in charge of the establishment establishes an error-free

communications pathway between network nodes over the physical channel. More-

over, checks integration of received messages, manages access to the channel, struc-

tures messages for transmission, and ensures appropriate sequence of transferred da-

ta.

Network control: This layer is responsible of addressing messages, setting up the

pathway between communicating nodes, routes messages across overriding nodes,

and controls the flow of messages between nodes.

4

Transport: This layer is in charge of providing end-to-end control of a communica-

tion session once this path is recognized. On the other hand, allowing reliable and

sequential processes to exchange. Accordingly, independent systems can communi-

cates or their location in the network.

Session control: This layer is responsible of the establishing and controlling sys-

tem‘s dependent aspects of communications sessions between specific nodes in the

network. Meanwhile, bridges the gap between the logical functions running under

the operating system in a participating node and the services that are provided by

the transport layer and

Presentation control: This layer is in charge of verifying that encoded data that has

been transmitted is translated and converted into a specific format, which enables

the storage of the data in a database forms that can be understood and directly ma-

nipulated by users. As well as enables the proper display on terminal screens.

Application/User: This layer is responsible of providing the services that directly

support user and application tasks and overall system management. Examples of

services and applications provided at this level are remote file access, database

management, resource sharing, file transfers, and network management.

7. Application

6. Presentation

5. Session

4. transport

3. Network

2. Data link

1. Physical

Figure 1: The ISO-OSI 7 layer Model.

5

Over the previous decades, the implantation of the lower layers has become a chal-

lenging issue. Essentially, people spent most the time worrying about RS-232 con-

nectors, wire sizes, and electronic communication methods such as asynchronous

and synchronous and the variation in their modems. Rather than just passing a bit

stream between two systems. Nowadays, there are reliable, standardized, economi-

cal implementations of levels 1-5 such as Ethernet, TCP/IP, IIOP, and Berkley

socket connections (Tanenbaum, 2003). In particular, most attention focused pre-

cisely on levels 6 and 7 of the OSI model. In which, implementations of the lower

levels of the OSI model have become more standardized and reliable. Accordingly,

the major effort of determining medical interfaces has specifically focused on level

7.

This includes different views: Firstly, illustrates the business needs and circums-

tances, during which, data exchange between medical systems. Secondly, identifies

the real world‘s specific issues that ―trigger‖ the messages exchange. Thirdly, speci-

fies the information content for each type of message including the fields and col-

lections of fields to be sent with their data type or format type, and their allowed

values. Fourthly, specifies the sequence, in which related messages will be passed to

accomplish a business need. Finally, defines specific protocols for application level

acknowledgement of messages, and strategies for communicating application level

errors. Hence, application level errors are those that occur because of receiving

invalid messages. Consequently, the frequent use of standard message contents, re-

liable network services and common data types, decrease the analysis and pro-

gramming that are required for new interfaces installation.

1.3 Project description

1 Adopt HL7 standard to facilitate secure exchanging of patient‘s medical and

clinical data among servers

2 Increase effectiveness and efficiency of health care delivery for benefit of all

3 Reduce the time and cost required to achieve health information system inte-

roperability

6

1.4 Project potential benefits

Improve patient care, by collaborating with health care information Technology

users to ensure that HL7 standards meet real-world emergent requirements.

Increase operational efficiency, in term of reducing the overall cost of software

development in order to ensure faster delivery with minimum failures

Simplify the implementation of a Data integration platform that protect and se-

cure data for reporting

1.5 Project challenges

Adoption of a new standard will be expensive and in one way or another, the

provider will foot the bill.

Adoption of HL7 v3 will take time, meaning the eventual replacement of all ex-

isting interfaces.

New technology means interfaces could be less reliable for some period of time

1.6 Motivation

The need to share clinical and medical data without violating patient confidentiality

is the major motive to adopt an efficient protocol which is electronic, accessible,

confidential, secure, and acceptable to both clinicians and patients. On the other

hand, integrated with other, non-patient-specific information in order to access or

transform private data without breaching patient confidentiality.

1.7 Scope of Research

The scope of this study illustrated through the movement of medical records beyond

intranet environments within a secure healthcare system, the significant lays in the

importance of the remote access and exchange of patient‘s medical and clinical da-

ta.

7

1.8 Research Objectives

1. To adapt flexible, cost effective standards.

2. To achieve healthcare information system interoperability throughout the

secure sharing of electronic medical records.

3. To enable patients to interact with the system remotely 24/7

1.9 Chapter Summary

This chapter intended to present concept idea of patient‘s medical records data

transmissions throughout simplifying the concepts of computers communication‘

mechanism and interoperability and how this support user interfaces. On the other

hand, the critical role of Standards Development Organization (SDO) was fairly

identified throughout recognizing the significance role of Healthcare Level (HL7)

protocol in the transmission of a medical data amongst seven layers of ISO-OSI

model. Additionally, project objectives, scope, motivation and potential benefits

were identified according to the expected outcomes of the proposed system.

8

CHAPTER TWO

LITERATURE REVIEW

9

2.1 Chapter Preview

This chapter summarizes the review of literature on the medical records and the evolu-

tion of electronic medical records. As well it demonstrates a brief understanding of the

differences between traditional and web based medical records taking into consideration

security and technical issues. On the other hand this chapter includes in-depth under-

standing of the proposed HL7 protocol, specifications, properties, objectives, varies

versions differences, causes of failure for the previous protocol HL7v2, reasons of

adopting HL7v3 and HL7 advance issues.

2.2 Internet Communication Technology (ICT)

Over the past few decades, inefficiencies and frustrations associated with the use of pa-

per-based medical records have increased gradually. Therefore many studies such as

(Tang and Hammond, 1991) and (Shortliffe, 1999) have addressed the emerging need

for developing a new record-keeping concept. Since then most organizations had a cer-

tain challenge to adopt a paperless, computer-based clinical record.

Over the recent decades healthcare systems had shown a remarkable usage of web tech-

nologies, in terms of diagnoses, treats and managing disease, since both patients and

doctors had become more relying on web application. Given in the past, healthcare in-

dustry had to struggle to find new ways of keeping up with patients, doctor-patient

communication and diseases. Comparatively, nowadays patients had become much

more knowledgeable about their own health. Therefore, providing them with proper in-

formation would assist them to follow up their own matters, and also obtain an appro-

priate care and treatment (Whitten and Cook, 2004).

From wellbeing perspective, Healthcare is the prevention, treatment, and management

of illness and the safeguard of mental and physical well being through the services of-

fered by the medical, nursing, and associated health professions. Accordingly, Health-

care encloses all the supplies and services designed to promote health, including ―pre-

ventive, curative and palliative interventions, whether directed to individuals or to pop-

10

ulations‖ according to the World Health Organization Report (WHO, 2000). Ferguson

and Frydman (2004) addressed the importance of the electronic forms of information

and communications in promoting the patients as strategic partners that emerge in

health care arena. Whereas, Delbanco and Sands (2004) noted that integrated, compre-

hensive, two-way information and communication technology (ICT) are envisaged as

part of the future of patient-physician communication. Likewise Kaplan (2001) indi-

cated that patient‘s effective usage of electronic mail, personal health records, and the

Internet, especially integrated within the context of an effective physician-patient rela-

tionship, would possibly improve both individual and organizational health outcomes.

However, the implementation and integration of patient-use ICT are yet facing several

barriers. In their study Winkelman and Leonard (2004) noted that such barriers could be

identified as political, financial, and cultural. In case of patient-accessible electronic

medical records (EMR), few barriers occur at the level of health care organizations, in-

surers, and health systems. Whilst at the physician level other barriers might occur.

Such as: Patients misunderstanding of physicians‘ annotations or the over loss of con-

trol. Given that patient interactions and extreme workload, would complicate the accep-

tance of these technologies. At the patient level, barriers such as individual‘s state of

general health, uncertainty, age, education, income, race, general literacy, functional

health literacy, learning styles, psychological profile , perceived self-efficacy, access to

computers and the Internet, perceived cost, and perceived difficulties of health provider

accessibility.

Nevertheless, patients are being able to implement information technology in self-care

and self-management successfully regardless of those barriers. Researchers have shown

strong evidences on the rapid growth in the Internet usage by the general public, in or-

der to seek health information. This variation occurs as a result of patient‘s assessment

for both the value of the Internet accompanied by the capacity to use the Internet from

their own perceived needs. This would increase patient acceptance of using the Internet

for seeking health information. As they recognized that might strongly fit their per-

ceived needs, wants, and capabilities (Gustafson and Wyatt, 2004).

11

Previously, many studies addressed the lack of a definite description of the patient‘s

point of view. Lin and Ross (2003) noted patient‘s point of view might be responsible

to a certain extent for the uneven record of patient-directed ICT and the access to the

electronic medical records. Whereas Eysenbach et al (2004) highlighted the main im-

pacts of online peer-to-peer communities in achieving consistent and measurable health

outcomes. Consequently, there is a vital need to adopt a reliable protocol that facilitate

an appropriate and secure access to patients Medical and clinical information.

2.2.1 Patient-Driven Communication

In general, patient-doctor communications varies in accordance to various methods, in

fee-for-service method, doctors and hospitals got paid for each service they performed.

There were no limits on their treatment decisions; doctors or hospitals could order as

many tests as they felt necessary, as doctors and hospitals made a lot of money under

this system because they decided the prices charged for every visit.

As for patient-driven communication, Electronic communication offers opportunities

for the significant participation of patients in managing illnesses, decision making, and

knowledge creation according to (Delbanco and Sands, 2004) and (Ross and Lin, 2004).

For patients with chronic illnesses, useful electronic medical records facilitates several

communication tools, such as e-mail, online bulletin boards, chat rooms, and online

consultation services that enhanced the communication among patients, physicians, ca-

regivers and other healthcare providers. Such enhancement provides patients with criti-

cal diseases greater personal control over the course of their illness and educate them

how the interactions with physicians would be initiated (Hunter, 1997).

2.2.2 Issues That Must Be Addressed

There are several issues that must be consistently considered as major factors in creat-

ing effective medical record systems:

12

1. The vital need for standardized clinical terminology: The richness and variety of

medical concepts yet are considered as major barriers in formulating a common-

ly standardized clinical vocabulary that is suitable for encoding patient-specific

information in the electronic medical record (Shakir, 2007).

2. Concerns about security, confidentiality, and data privacy: Many people are still

conscious of storing patient-specific information in computers as this might lead

to an appropriate release and use of data. In this regard, a study of National Re-

search Council (NRC) of the National Academy of Sciences in Washington,

D.C. (1997) addressed the NRC properly suggested policies and procedures for

protecting the confidentiality and security of patient‘s clinical data in different

computers. However, another study indicated that the major vulnerabilities are

associated with the inappropriate use of patient-specific information by health

staff that has access to those data as part of their usual job. Given that, such risks

are greater when data are stored in paper charts (Savvy, 2006).

3. Challenges of data entry by physicians: combining computer use with the

workflow of busy clinicians is obviously challenging, especially when the work

requires data entry by physicians. In this regard few systems have been effec-

tively adopted. As a result, many record-system developers have highlighted the

critical need for physicians to use alternative methods for data entry, such as

dictating notes for online transcription or filling out coded data forms that are

scanned or transcribed into the computer. Some researchers such as (Crow, 2004)

and (Poon, Fagan and Shortliffe, 1996) indicated previous effort to design inter-

active features for be both attractive and efficient for clinicians in terms of time

and performance. Additionally, development of newer point-and-click technolo-

gies, or pen-based selection methods, led to increase systems attractions.

4. Difficulties associated with the integration of record systems with other infor-

mation resources in the health care setting: Greenes and Shortliffe (1991) identi-

fied the physicians are ―horizontal‖ users of information technology. Instead of

becoming ―power users‖ of a narrowly defined software package, they access a

wide variety of systems and resources. Thus routine use of computers, and of

13

electronic medical records, will be most easily achieved if the computing envi-

ronment offers physicians a critical collection of services that are both smoothly

integrated and useful for almost every patient encounter (Finnell et al, 2003).

Bearing in mind, that the evolving of networked systems within health-care as-

sociations produced new opportunities to combine a variety of resources

throughout a particular clinical workplaces. The nature of the integration tasks is

illustrated in Figure 2, according to (Shortliffe, 1999). In such figure various

workstations shown at the upper left (that are used by patients, clinicians, or

clerical staff) connected to an enterprise network, or ―intranet‖. In such an envi-

ronment, diverse clinical, financial, and administrative databases all need to be

accessed and integrated by using networks to combine them together and a wide

range of standards for sharing data among them. The vital entity of this model is

the clinical database (or clinical data repository) is the central resource that is in

charge of gathering and integrating clinical data from various sources such as:

radiology department, chemistry laboratory, pharmacy, and microbiology labor-

atory.

Figure “2”, Clinical data repository according to enterprise intranet

14

2.2.3 Technical issues

Technical challenges still exist for medical wireless networks. Some of the key is-

sues that need to be dealt with are the challenges of sharing of information, the risk

of RF interference, and handwriting recognition. As medical practice in the United

States moves increasingly away from the patient-one doctor model to a team-based

approach where there are multiple providers handling specific aspects of the pa-

tient‘s care, there is a critical need to share information quickly and accurately

across practice and organizational boundaries (J. Grimson, W. Grimson and Has-

selbring, 2000). In their study Grimson, et al. (1998) discussed three ways of coor-

dinating the sharing of information; messaging, data warehousing, and a common

architecture approach. Most current systems utilize messaging systems based on the

HL7 protocol. Although these systems are functional, they have restrictions in their

scalability as the number of data interactions.

Data warehousing is another issue in the data management technology, which has

been projected for the healthcare. Data warehousing is primarily designed for static

data that necessary be used as a reference to historical activity, in which it is scala-

ble and capable of managing large amounts of data. Accordingly, J. Grimson, W.

Grimson and Hasselbring (2000) noted that using a data warehouse in a dynamic

operational context might cause data duplication. Therefore, J. Grimson, W. Grim-

son and Hasselbring (2000) proposed a solution to these problems by creating a

common architecture of building blocks to create data packages that are customized

for specific situations and departments.

Radio Frequency (RF) interference is a concern whenever devices share the same

portion of the radio spectrum. IEEE 802.11b network systems share the 2.4 GHz

band with medical devices. Yet technical risk if interference is small compared to

the actual risk of an event.

15

According to FDA survey from for the period from September 1993 to September

1994, around 0.052% of all reported issues were attached to electromagnetic com-

patibility issues (Fransicsco, 2003). The network that the University Hospital has

implemented uses equipment designed for the IEEE 802.11b standard. Staff at that

hospital has not seen any incidents where the wireless network has impeded with

medical devices according to Intel, 2003a. Additionally, handwriting recognition is

considered as another concern for both tablet systems and PDA based systems in

which pen-based data entry has been used frequently. Users of such system need to

be educated and trained on the usage of such equipments in order to use the system

properly.

2.3 Clinical Information System

2.3.1 Functions of Clinical Information System

Generally, clinical data are acquired to be entered by patients, physicians,

and the healthcare providers. Such data is classified into three general categories,

firstly, historical information that is provided by patients, secondly, information

that is obtained from the physical examination, finally, some test‘s results or pro-

cedures that are performed on patients‘ tissues or body fluids. Specifically, the data

that is collected by physicians and healthcare organizations‘ providers is based on

the results of observation or examination. Such data would be directly entered by

any of three sources (patient, physician, or other healthcare provider) throughout

various methods and techniques. Basically, input methods varies according to dif-

ferent healthcare organizations either by selecting items from a computer screen

menu, or through typing, light pens, bar code readers, optical scanners, monitors

connected to patients and voice recognition systems and traditional hand-written

systems. In particular, such Data could be stored in the memory of the clinical data

systems or on paper, computer tape, smartcards, computer disk or optical laser

disk. Taking into consideration that primary data, this is gathered from unanalyzed

source need to be analyzed, in order to allow the linkage to other data elements,

summarization and interpretation (Finnell, 2003).

16

2.3.2 Clinical Information requirements

In fact, the integration of clinical and administrative data systems involves signifi-

cant reorientation as well as system developments, which would lead to open access

amongst the systems‘ data. The major role of the administrative data system lies in

generating bills. Whereas, the main purpose of clinical data system lies in providing

appropriate care to particular patients. Therefore, clinical data systems are responsi-

ble of supporting administrative various functions as well accessing the data, which

is enclosed in the administrative systems. Furthermore, the increased increasing so-

phistication in the administrative data systems necessitates an easy access to indi-

vidual data and clinical information (Ross and Lin, 2004).

2.3.3 Traditional health care system

The paper-based medical record is absolutely inadequate for meeting the needs of

modern medicine. It arose in the 19th

century as a highly personalized ―lab note-

book‖ that clinicians could use to record their observations and plans so that they

could be reminded of pertinent details when they next saw that same patient. There

were no officious requirements, no assumptions that the record would be used to

support communication among varied providers of care, and extremely few data or

test results to fill up the record‘s pages. The record that met the needs of clinicians a

century ago has struggled to adjust over the decades so as to accommodate to new

requirements as health care and medicine have changed. Having adequate health

care is extremely important to people. Even successful medical treatment can in-

volve pain, anxiety, risk, and, inevitably, lots of money. Castro (1994) sated that the

last thing a patient in a hospital wants to think about is ―how am I going to pay for

all of this?‖ Ideally, instead of worrying about money, a patient should be concen-

trating on getting well. The Health care system encompasses everyone and every-

thing from the individual who is sick and in need of care, the clinic doctor who sees

homeless people and families with no health insurance, to the hospital surgeon who

performs state-of-the-art surgeries for thousands of dollars. It also includes execu-

tives and other business people who make decisions about health care that influence

millions of people, and government officials who are desperate to reform (improve)

health care (Castro, 1994).

17

2.3.4 Web based healthcare system

It has been widely recognized that the evolvement of internet and web-based appli-

cations have an important impacts on the development of electronic medical

records, electronic patients orders and electronic patients‘ private records. Imple-

menting such technology in medical arena played an important role in reducing

medical mistakes and enhancing the communication amongst healthcare profession-

als and patients. This would lead to fewer mistakes. For example in emergency case

patients have full details records that help healthcare provider to access such records

and proceed the expected treatment, which will avoid the wasted time required for

gathering unconnected sources (tang and Hammond, 1997).

2.4 Security Issues

According to the nature of the data being collected and stored, several associated

security and regulatory issues ought to be considered during the planning phase of

a networked medical records system. Relatively many studies have addressed the

significant role of security in medical records. In his study Shortliffe (1999) identi-

fied the basic requirement for assuring long-term medical records, such as being

secure, and flexible. On the other, medical records mostly need to be retained legal

requirements. Accordingly Shortliffe (2000) discussed the dynamic nature of pa-

tient care data and suggested that non-normalized databases with complex record

structures may be more useful to developers of record systems as they intend to

achieve the required flexibility to match the various practice patterns healthcare

providers. Consequently, wireless systems create additional security challenges to

users and administrators. Matt and Marsden (2005) discussed various security issues

that are inherent in wireless systems. The most significant issue lays on the fact that

wireless networking utilizes radio frequency transmissions to pass data from clients

to host servers. Such transmissions with the access points into the physical LAN of

the hospital need to be secured (Savvy, 2006). As a result, vendors of wireless net-

working equipments provide instructions to users and system administrators on

how to implement appropriate levels of security in their networks (Microsoft,

18

2003). In their study Barnes and Scornavacca (2005) noted that most wireless ap-

plications, using the 128-bit version of the wireless encryption protocol (WEP) and

selecting only specified computers that can access to the network are sufficient

safety measures for physical security.

Additionally, The Health Information and Portability Accountability Act of 1996

have added new requirements for privacy and security as the act came into full force

during calendar year 2003. Baumer, Earp & Payton (2000) indicated that the soli-

tude requirements of this act was aggravated in part by both the inadequate nature of

protecting private citizens under existing law and the disparate nature of privacy

regulation at the state level. Yet, a significant amount of confusion occurs about the

acceptable implementation methods by government. Baumer, Earp and Payton

found that there is a considerable amount of agreement between healthcare person-

nel about what information should be kept private besides the regulations that have

been issued by the United States Department of Health and Human Services.

2.5 Electronic records (History)

Electronic medical records concept was firstly recognized in the 1960s, by physi-

cian named Lawrence L. Weed, during which Weed illustrated the concept of com-

puterized medical records. As he described a system, which is able to computerize

and rearrange patient medical records, in order to enhance their performance so this

would lead to improve patient care.

In particular, Weed‘s work shaped the basis of the PROMIS project at the Univer-

sity of Vermont. This was combined effort among physicians and information tech-

nology experts, which started in 1967 to develop a computerized electronic medical

record system. This project aimed to develop a system that would provide patient‘s

data sequentially and timely to the physician, and allow the quick collection of data

for epidemiological researches, medical examinations and business assessments.

The group‘s hard work led to the development of the problem-oriented medical re-

cord, or POMR. Furthermore, the Mayo Clinic began the development of electronic

medical record systems.

19

In 1970, the POMR was firstly employed in a medical ward of the Medical Centre

Hospital of Vermont. Concurrently, the technology of touch screen had been inte-

grated into data entry procedures.

Over the next few years, the program was adjusted as drug information elements

were included. This allowed physicians monitor drug actions, allergies, dosages,

side effects as well as interactions. At the same time, over 600 common medical

problems‘ diagnostic and treatment plans were formulated.

For the period between 1970s and 1980s, numerous electronic medical records were

developed and more recognized by a range of academic and research institutions.

During that time the Technician system was hospital-based, and Harvard‘s

COSTAR system created records for the ambulatory care. Likewise, the HELP sys-

tem and Duke‘s ‗The Medical Record‘ were of early in-patient care systems. More-

over, Indiana‘s Registries record was one of the initial united in-patient and outpa-

tient systems.

Since, progression in computer and diagnostic applications that was recognized dur-

ing the 1990s, electronic medical record systems became increasingly sophisticated

and widely used by practices. In the 21st century, the implementation of electronic

medical records practices has shown a remarkable increase (Gustafson and Wyatt,

2004).

2.6 HL7 protocol

2.6.1 Why HL7?

In particular, there is a recognizable confusion about HL7 exact function, as

some research noted that it develops software. Whereas, other agreed that it de-

velops specifications. Messaging standard has become the most widely used, in

which it enable different healthcare applications to exchange keys sets of clini-

cal and administrative data. Accordingly, the adoption of HL7 as a unique pro-

tocol is significant, in order to focus on the interface requirements of the entire

health organization, whilst other systems might focus on the requirements of a

20

particular department. Additionally, HL7 develops ongoing feedback from all its

various members including individuals, vendors and institutions (Health Infor-

matics, 2003).

HL7 advantages:

Using HL7 allows the same information to be re-used by disparate computer

systems.

Reduces the need to ‗Re-enter‘ data.

Reduces errors introduced by ‗Re-entering‘ data.

Reduces redundancies of data entry effort.

HL7 helps provide more accurate information which leads to reduced patient

and medical errors and at the same time decreases operating & interfacing

costs

2.6.2 HL7 – History

1987 Founded and version 1.0

1988 Version 2.0

1990 – 1999: Versions 2.1 to 2.3

1994 ANSI Accreditation

21

Figure „3‟: Without HL7: Point to point interfaces, according to (Health Informatics, 2007).

Figure „4‟: Reusable HL7 Interfaces

2.6.3 Comparison among Versions

Since the origination of HL7 in 1987, HL7 v2 has facilitated information exchange

of amongst various systems. Hence, HL7 Board of committee has agreed to con-

tinue it evolvement as long as there is a wide usage of version 2. However, most us-

22

ers have used v2 for appropriate and structured clinical data; numerous efforts had

to be done to aggregate on a larger scale, either for research or public health that is

concerned about the same issue (Core Point Health, 2007).

On the other hand, v2.x messages have a positional format, variable-length, and

consist of lines (―segments‖) of ASCII text. Each line of text is a sequence set of

data elements as (= fields or data items) separated by delimiters. In particular each

data item is well defined in HL7 standards document. For example: HL7 v2.5 en-

closes around 1700 data items, as each data element is usually separated by vertical

bar (or pipe ―|‖) characters, may have components (separated by ―^‖ characters) and

may repeat such as: Numerous patient IDs, phone numbers (Core Point Health,

2007).

In October 6, 2000 HL7 v2.4 for healthcare messaging became an ANSI accredited

standard. During which introduced conformance query profiles in chapters 5, and

added messages for application management, laboratory automation and personnel

management. Whilst version 2.5 is considered as the latest updated version in the

HL7 version 2.x series, as it contains new messages and updates to the previous

version. In fact, version 2.5 contains more messages and covers a broader scope of

health care than version 3. Additionally, v2.5 offers backward compatibility with

other versions of 2.x series, and is commonly implemented word wide. Moreover,

the natural flexibility to define optional message content in the form of Z segments

extend v2.5 acceptance. However, v2.5 trade off occurred due to the loss of intero-

perability and the capability to certify it fulfillment (Core Point Health, 2007) and

(Mead, n.d.).

In September 2004, version 2.6 completed the first ballot cycle and contained the

latest enrichments to the HL7 Version 2.x series. Yet, V2.6 will consist of new mes-

sages and updates to HL7 version 2.5. Meanwhile, it will propose backward com-

patibility with other 2.x Versions. In particular, V2.6 will include enhancements that

allow the communication of Electronic Health Record (EHR) (Core Point Health,

2007).

23

Afterwards, the HL7.org Board has agreed on the origination of V2.7 once the work

on V2.6 has being practiced. Consequently, correct implementation of the HL7

V2.x inter-version compatibility rules allows different versions of HL7 to the ex-

changing of data without any considerable problems. Bearing in mind, that the ad-

justment in the functionality of newer versions is unable cannot be support an older

version. In particular, HL7 Version 3 represents a definite modify compared to the

Version 2.x series, as it adopts a new methodology for exchanging messages. His-

torically, Version 2.x did not have an exact development methodology; as a result,

different components of the standard were developed in different ways. On the con-

trast Version 3 is strongly recommended. With accordance to its specific and thor-

ough methodology that binds together over-arching information and application in-

teraction models with messages sets and twits them to syntax and semantics specifi-

cations. However, the problem gap for HL7 is associated with the interoperability

requirements of healthcare providers and stakeholders in a specified domain of

healthcare arena (Mead, n.d.).

Version 3 is being constructed in a single object model, which is Reference Infor-

mation Model (RIM). The current draft of version 3 specifications is distinct by 96

―Hierarchical Message Descriptors‖ (HMDs), which are specified into individual

message types. Version 3 is more focused on terminology, models, specific contexts

and conceptual definitions and relationships compared to version 2.x that is typical-

ly focused on the general triggers, structure and for communication layout (HL7 In-

ternational, 2007).

Therefore, there is a critical need to move on from v2 to v3 due to significant differ-

ences between previous HL7 v2.x and current HL7 v3 (Mead, n.d.). Given that ver-

sion 2 series do not contain much patient related information. More importantly the

v2 information was static and the vertical bar notations are recently outdated as

these were ongoing since 18 years ago. Consequently, this issue has pointed to the

importance of allocating more resources to v3, since it will allow the addressing the

main impact of SOA and semantic web on Electronic Health records in accordance

to the emerging of Personal Health Records scheme (Arsanjani, 2004). The following

24

table describes the comparison between HL7v2.x and HL7v3 strengths and weak-

nesses according various characteristics (Core Point Health, 2007):

Characteristics Version 2.x Version 3

Strengths Weaknesses Strengths Weaknesses

Participation Multi vendor and us-

er world wide

Dominated by large

US Bodies

Large US vendor and

US users with

worldwide input

Smaller vendors and

users not so active

Development Fast and responsive Fast and responsive Still responsive slower

Stability

Very stable with

good backward com-

patibility

No further develop-

ment being autho-

rized

Still able to embrace

new requirements.

Still not sufficiently

stable to encourage

implementation

Current use Widespread Very limited

Ease of use Relatively simple

concepts

Significant ambigui-

ty Said to be simple Complex concepts

Internal rigor

Improved on the

base of refinement in

use

Poor just grew on the

bases of need

Intended to be com-

prehensive

Significant compro-

mises in some areas

Use Domain Acute sector predo-

minates Primary care

Intended to be all

embracing

Unproven in clinical

systems

XML Support

Messages can be

produced using de-

fined DTDs

Ambiguity of repre-

sentation

Designed for native

support for XML

Unproven in messag-

ing complex docu-

ments

Implementation issues Significant expertise

available

Life limited to

around 10 -15 years

Some UK expertise

available Fitness unproven

Cost of message im-

plementation

Lowest current op-

tion

Only certain for the

full understanding of

requirements

Should be easy to

quantify

Unknown ,should be

no higher than v2,

but more demanding

of infrastructure

Table „1‟ version 2 and version 3 comparison

The difference in message formats between a HL7 V2 and V3 message (Core Point

Health, 2007):

MSH|^~\&|AcmeHIS|StJohn|ADT|StJohn|20060307110111||ADT^A04|MSGID200603071

10111|P|2.4EVN|A04PID|||12001||Jones^John||19670824|M|||123 West

St.^^Denver^CO^80020^USAPV1||O|OP^PAREG^||||2342^Jones^Bob|||OP|||||||||2

|||||||||||||||||||||||||20060307110111|AL1|1||3123^Penicillin||Produces

hives~Rash~Lossof appetite

“HL7 V2.X message”

25

“HL7 V3 message”

2.6.4 Failure of current protocol

Version 2.x did not have an exact development methodology, and consequently, dif-

ferent parts of the standard were developed in different ways, in which the exchange

of healthcare data has become complicated.

2.7 Choice of proposed solution

This project focuses on how HL7 V3 differs from V2, and why health care IT or-

ganizations need to begin adopting V3 rather than expecting that an improved V2‖

will enable the healthcare IT sector to realize data interchange (Shakir, 2007).

2.7.1 Properties of proposed protocol

Using HL7 V3 protocol enables the system to collect accurate electronic data from

medical devices according to specific applicable regulations and requirements in

26

which the system should support communication and presentation of data captured

from medical devices (Shakir, 2007).

2.7.2 Advance issues of HL7

First unencumbered HL7 V3 Java SIG code available

The first free version of unencumbered HL7 V3 Java SIG code is now available to

test. It has been published by the Regenstrief Institute, Indianapolis, USA. Note that

this is not a full release yet, but code disencumbered from HL7 intellectual property

(HermetechNZ, 2009).

Spinal Tap –an integration application connecting corporate data spine archi-

tectures

Quicksilva‘s ―Spinal Tap‖ is an integration application which connects up corporate

data spine architectures. It is an innovative message handler, enabling applications

to connect seamlessly to the data spine. ―Spinal Tap‖ acts as a broker between any

local and central system or two local systems (HermetechNZ, 2009).

.

7Edit –A new Visual HL7 V2.x Tool

7Edit –the visual HL7 tool to browse, edit, search and validate HL7 V2.x data

MIRTH –Open Source HL7 Messaging Middleware

The open source release of Mirth 1.0 Was announced today. MIRTH is free, open

source HL7 messaging middleware and is designed to dramatically reduce the time

and cost required to achieve health information system interoperability (Herme-

techNZ, 2009).

27

Sybase e-Biz Impact Integration Tool

The Sybase e-Biz Impact integration solution supports HL7, filters incoming mes-

sages, stores them for guaranteed delivery, processes transformations and enables

dynamic routing (many-to-one and one-to-many) to any number of destination sys-

tems (HermetechNZ, 2009).

2.8 Chapter Summary

The evolution of HL7 versions have considered to fundamental concepts security

and message structure. Since the security issue is the biggest concern of the pro-

posed project, HL7v3 protocol was adopted for the sake of assuring a secured

transmission of paint‘s clinical and medical records. On the other hand, to resolve

the problem of interoperability that occurred in previous versions. The chapter also

covered a concept idea, of improving web based medical records according to clini-

cal and functional requirements, taking under account the importance of technical

and security issues.

28

CHAPTER THREE

METHODOLOGY

29

3.1 Chapter Preview

This chapter focuses on identifying the chosen methodology, as the project employs

two main research techniques that include action research and prototyping, taking into

consideration both integrated and distributed perspectives. On the other hand this

chapter will demonstrate HL7 Development Framework, objectives, models, phases

and activities.

3.2 Chosen Methodology

The mechanism that allows the communication between possible parts called an in-

teraction system. In the distributed perspective, a system is considered as a composi-

tion of interacting parts (Pires, 1994). A service corresponds to an interaction of the

system if it was viewed from distributed system perspective. The use of action re-

search in the study is to improve the quality of an organization and its performance.

In this research action was used in an attempt to develop solutions that are of practical

value for users.

A prototype is a working model for one or two aspects of the projected system. It is

constructed and tested quickly in order to test out assumptions. The Easylink proto-

type is developed to produce implementation steps for users to improve their ser-

vices. The project adopts two complementary approaches comprising theoretical

analysis (such as historical development and present scenario of aggregation current

research in aggregation server) and qualitative analysis (such as design, implementa-

tion and evaluation of aggregation server prototype).

30

3.2.1 HDF: Background

In particular, the Message Development Framework (MDF) was established by

HL7 in 1997. Such framework intended to illustrate the model driven develop-

ment methodology that produces the specifications of HL7 Version 3.0 message.

It was obsolete by the Healthcare development Framework (HDF). The specifica-

tions formed by HL7 targeted numerous aspects of the interoperability challenge,

including specification of information models, clinical documents, vocabularies,

implementation technology, messaging, context management standards, profile,

and conformance. The models being used in the HDF development methodology

are based on the Unified Modeling Language (UML) as chosen syntax. The HDF

is a replacement for the extension of Message Development Framework (MDF).

The HDF differs from MDF and strongly improves the alignment between the un-

derlying Meta model leading well-formed HL7 models with the Meta model of

UML. In addition applies the model driven process to all of the technical specifi-

cations of HL7, not only messages (Health Informatics, 2007a)

3.2.2 HL7 Development Framework: HDF

In particular, health informatics exchanges information amongst healthcare in-

formation systems, and allows the communications between different entities.

Frequently it takes the form of a composed message, triggered by some event.

This is recognized as a sender and a receiver. The interaction among HL7 various

applications occurs according to several messages exchange, the consistent ex-

change of such massages lead to adequate interoperability. Figure ‗5‘ descries The

HL7 Development Framework specifications through several phases, activities

and models. The essential specification of a messaging standard is a Reference In-

formation Model (RIM) that completely covers the domain being addressed. The

31

RIM and the vocabulary domains are the bases for the semantic specification of

message elements. The Domain Information Model (DIM) defines the informa-

tion content for a specific area of expertise or interest. The DIM represents one

group‘s view of the world. A suitable subset of the RIM, called Refined Message

Information Model (R-MIM) is used to state the information content for one or

more related messages. The R-MIM provides one method of controlling

processes. The Hierarchical Message Description (HMD) specifies a set of mes-

sages based of one R-MIM. A message type is specified in one HMD.

Figure „5‟ HL7 Message Development Framework—Excerpt from HL7 V3

According to (Regio, 2005).

32

3.2.2.1 Use cases Model:

Basically, a use case diagram is a simple form of behavioral diagram,

which is defined by the Unified Modeling Language (UML). Its main pur-

pose is to present a graphical overview of the functionality provided by a

system in terms of actors, their roles and relationships. In other words, a

use case is a textual description of specific situations within the healthcare

environment, in which communication between healthcare entities is

needed. It describes the actors who are important within the project scope,

and the activities that those actors carry out, and further analyses the me-

thodology for capturing user requirements.

3.2.2.2 Information Models:

In particular, information models are the components, which are defined in

a meta-model and the textual representation maintained in a database, and

graphical representations maintained using UML (Unified Modeling lan-

guage). Three types of Information models are defined in the modeling

process: DIM defined for administrative process, RIM a coherent shared

information model for all derived messages and R-MIM takes the generic

RIM and defines a constrained subset that deals with a specific set of

events. The R-MIM permits the adding of message specific constraints.

3.2.2.3 Interaction Model:

This describes a specific example of information exchange. It specifies the

trigger event, the message content and the tasks of the receiver.

3.2.2.4 Message Model:

This identifies the format of HL7 messages and relates them to interac-

tions (the HMD or Hierarchical Message Description)

33

3.3 HDF: Objectives

The HL7 Development Framework (HDF) is a replacement or an extension to the

HL7 Message Development Framework (MDF). It is the major deliverable of the

HDF project. The HDF varies from the MDF in terms of the following:

Use of UML Notation: the Unified Modeling Language (UML) is a standar-

dized specification language for the object modeling. In which, UML is a mul-

ti-purpose modeling language that is consist of a graphical notation used to

create an abstract model of a system, referred to as a UML model. On the oth-

er hand, UML models might be mechanically transformed to other representa-

tions such as Java in term of queries, views and transformations). Further it

can be supported by the OMG (Object Management Group).

Life cycle Management: in fact, The Specification of the HDF Methodology is

a ―living document‖, which intended to keep speed the improvements in me-

thodology. The management of HDF Life cycle uses verified techniques in

managing document, configuration and version control. The HDF is antic-

ipated to be accepted as an informative, background document as a component

of the HL7 specification approval process and it will be re-accepted as it

changes eventually.

The main objective of the HL7 Development Framework Methodology Specifica-

tion is to document the processes, context and work products, during which it

compromise the whole development Life cycle of HL7 standard. The HDF me-

thodology consists of theoretical processes that can possibly be applied to any

particular of in the specification or development project. This objective of HDF is

to initiate the processes, illustrate their deliverables and document their interde-

34

pendencies. Secondly, HDF serves as a specific input to the development guides,

in which it focuses on particular types of projects and specifications.

3.3.1 HDF Requirement framework:

Essentially, the requirements of the documentation process generate a set of arte-

fact that clearly illustrates the healthcare business in a given domain, during

which it would be familiar to the people who work in such business area. In par-

ticular, the artefacts set are recognized as the requirements specification. These

artefacts have been used in order to develop and enhance HL7 v3 messaging stan-

dards according (Health Informatics, 2007a).

Figure „6‟, Methodology key concepts

3.3.2 Requirement Methodology process of HDF:

HL7 HDF Requirements Documentation process is to:

1. Document Business Process: Dynamic Behavior and Static Structure

35

2. Capture Process Flow: Activity Diagram

3. Capture Business Rules: Relationships, Triggers, and Constraints

4. Harmonize the Domain Analysis Model with HL7 Reference Models.

5. Capture Structure: Domain Analysis Model and Glossary

According each Clinical Activity uses the following format:

<Title>

<Clinical use-case document reference> <Storyboard document reference>

< Narrative detail>

<Assumptions>

<Health Service Event section>

<Actors>

<Assumptions>

<Workflow Event Steps>

3.3.3 RIM (reference information model) Core Classes

Figure ‗7‘ describes the core classes in the reference information model, accord-

ing to Stevens (2003) and HL7 International (2007), Act represents any action

that occurs and is documented throughout the process as health care is managed

and provided.

o Participation: An association between an Act and a Role with an Ent-

ity which is playing the role

o Act Relationship: A directed association between a source Act and

target Act.

36

- An Entity represents any physical thing and/or beings that or have an interest

and take part in health care.

- A Role describes the task that Entities play/provide as they participate in

heath care Acts:

o RoleLink: A connection between two roles expressing a dependency

between those roles

Figure „7‟, RIM core classes

3.4 HL7 V3 and the Flow of Health Information

In particular, patients‘ health records are one kind of data that needs to be coded into

a message, which allows transmission between health organizations. Thus, health

records are gathered and stored for several of reasons such as: Decision support,

memory aids for healthcare‘s patient, research, analysis and audit) Health Informatics

(2003). Accordingly, information content is based on the following aspects:

1. The accuracy, completeness and recording method

2. The actual or perceived purpose of the recoding data

37

3. how the information is communicate between both originating and target

records

Basically, messages are formed by communication requirements, in terms of order-

ing, reporting or informing healthcare information. Seeing that, the nature of the mes-

sage is derived from the following:

the specific purpose for the communication

the requested data for health

the specific person or association who is in charge of gathering or retrieving

the information

the information about a individual event

the requested information from the service

Therefore, HL7 Reference Information Model is used to specify the necessary infor-

mation for interoperability amongst various information systems. RIM is a recognized

as comprehensive source of all information that is used in any HL7 specifications.

This allows loosely-coupled information systems to interoperate. Figures 8&9 illu-

strate the structural changes from HL7 V2.x to HL7 V3 according to (McKesson,

2000) and (Health Informatics, 2003a):

38

Figure „8‟, Structure of HL7 V2.x

Figure „9‟, Structure of HL7 V3

39

Models developed in Phases. Figure 10 describes the function of each step within an

HL7 V3, in which all models are inter-related.

Figure „10‟ Models Phases

Basically, HL7 V3 translates everything into "building block" models which are then

transformed into a Hierarchical Message Description (HMD). Once a message is trans-

mitted to another HL7 V3- compliant system, the recipient system is able to interpret the

message because it uses the same model specifications according to according to

(McKesson, 2000) and (Health Informatics, 2003a).

40

Models Used to Build the Hierarchical Message Description (HMD). According to

according to (McKesson, 2000) and (Health Informatics, 2003a).

As shown in figure 11.

Figure „11‟, Hierarchical message description models (HMD)

3.5 Chapter Summary

This chapter had shown the mechanism of HL7 v3 data flow throughout varies faces, and

how such mechanism would assists in patient‘s data transmission amongst various

healthcare servers. In particular HL7 V3 translates everything into "building block" mod-

els that will be transformed into a Hierarchical Message Description (HMD). This would

allow the recipient system to interpret the message because it uses the same model speci-

41

fications. The HDF methodology consists of theoretical processes that apply to any par-

ticular kind of specification or development project.

CHAPTER FOUR

SYSTEM ANALYSIS & REQUIREMENTS

42

4.1 Chapter Preview

This chapter is concerned about system analysis throughout identifying an appro-

priate information gathering technique for the proposed system as well as analys-

ing the system requirements throughout illustrating the functional and non func-

tional requirements. On the other hand, demonstrates the proper tools and tech-

niques for the proposed system. Such as: chosen framework, chosen development

platform, chosen data access technology and chosen development language.

4.1.1 Information gathering techniques

1. References & printed materials

2. Internet research

3. Research done or previous thesis

4. Brain storming

5. Prototyping

Prototyping is a relatively modern technique for gathering requirements

and can work well with Web development. In this approach, it can be used

to gather preliminary requirements that helps build an initial version of the

solution—a prototype. For additional requirements we can change the ap-

plication and cycle around with the customer again. This repetitive process

continues for an agreed number of iterations or until the product meets the

critical business needs.

43

4.1.2 System Requirements Analysis

A requirement is a feature of the system or description of something that

system is capable of doing in order to fulfil the system purpose. Concur-

rently capturing the right requirements would assure a comprehensive

functionality for any system (Melonfire, 2006).

The project requirements analysis is conducted with the following objec-

tives:

1- Identify user needs

2- Evaluate the system concept for feasibility

3- Allocate function to Hardware, Software, Database and other system

elements

4- Perform techniques analysis

4.2 System‟s Functional and non-functional requirements

Choosing appropriate functional and non-functional requirements is the

key to system success, given that the key to success relies on how the sys-

tem will be used and who are the right users.

4.2.1 Functional Requirements

Functional requirements are identified as the ability to describe interaction

between the system and the environments. Functional requirements also

refer to the services that the system should provide, how the system should

react to a particular inputs and how the system should behave in particular

situation. Personal Demographics Service (PDS).Each person's care record

will be comprised of both demographic information, such as name, ad-

dress, date of birth and NHS Number, and medical information. A detailed

Electronic Records Service will allow the healthcare system to move away

from its current organization -centered patient records, to records that are

44

centered on the patient. This will make caring for patients across organiza-

tional boundaries safer and more efficient. It will also give patients them-

selves access to a record that covers care across organizations (Binary

Spectrum, 2007).

The services provided are:

1- Health management

2- Patient‘s private and summary records

3- Health assessment

4- Pharmaceutical information

5- Laboratory information

6- Health improvement

7- Health conditions information

8- General medical information

4.2.2 Non Functional Requirements

A non-Functional requirement is a special requirement that is specific to a

particular system. There is a wide range of performance, security, and in-

terconnectivity information (Binary Spectrum, 2007), operational re-

quirements and constraints under which system must operate, and stan-

dards that have been delivered by the proposed system.

Operational Requirements are:

1. User friendly, and understandable

2. Reliability should be used in reasonable manner without costly failure

or danger.

45

3. Understand-ability in term of coding

4. Security Requirements, secured ID available for each registered user.

5. Confidentiality when dealing with medical data

6. Ease of Maintainability

7. Number of users, system should be flexible for wide range

8. Response time, fast without waiting delays.

9. Availability no restriction 24/7

10. Connectivity needed for user sites, PC users connected on TCP/IP land

or dial-up lines

11. Interoperability: Means that Data can be transmitted accessed without

transmission without need for semantic interpretation or translation.

12. Usability: The ability allocating, retrieving and interpreting the

records.

13. Integrity: Means that information and programs can only be changed

in a specific and authorized manner, that all computer resources operate

correctly and all it content not subject to unauthorized changes or modifi-

cations.

4.3 Tools and technologies proposed

4.3.1 Chosen framework

Microsoft .NET Framework is recommended because it's built on XML and Web

services standards, in order to enable high connectivity across the healthcare are-

na. Microsoft has prioritized the deployment of technologies that help to protect

customers and their information, offering automated security measures to prevent

misuse, breaching and unauthorized access.

46

Figure „12‟, Microsoft .NET Framework

4.3.2. Chosen web database

Databases are the primary key for all EHR systems, Modern database sys-

tem may hold billions of data items, and manage thousands of transactions

per second. Microsoft Access 2003 was chosen for the prototype. For the

actual system windows 2000 server and SQL server recommended.

47

4.3.3. Chosen data Access technology

Open Database Connectivity (ODBC), The Microsoft Open Database

Connectivity (ODBC) interface is a C programming-language interface

that allows applications to access data from a variety of Database Man-

agement Systems (DBMS). Applications that use this API are limited to

accessing relational data sources only. ODBC is available on the 64-bit

Windows operating system.

For the actual system SQLODBC is recommended, Microsoft SQL Server

ODBC Driver (SQLODBC) enables access to Microsoft SQL Server.

However, SQL Native Client is recommended for creating new applica-

tions or enhancing existing applications that must take advantage of new

SQL Server features in SQL Server 2005. SQLODBC will continue to be

supported and is available on the 64-bit Windows operating system.

4.3.4 Chosen web server

The Internet Information Service IIS (6.0) used to setup the web server,

windows 2000 server 0.5 can be useful from hosting a simple website to

building an e-commerce application.

Advantages of IIS (6.0)

1. Reliability: as IIS 6.0 uses a new request-processing architecture and

application isolation environment that enables individual web applications

to function within a self-contained worker process. The new environment

includes proactive application pool health.

48

4. Scalability: IIS 6.0 introduces a new kernel-mode driver for HTTP

parsing and caching, specifically tuned to increase Web server

throughput and scalability of multiprocessor computers, thereby sig-

nificantly increasing the following:

The number of sites a single IIS 6.0 server can host

The number of concurrently active worker processes

3. Security: IIS 6.0 provides significantly improved security over earlier

versions of IIS. To reduce the attack surface of systems, IIS is not installed

by default on the operating systems in the Windows Server 2003 family.

Administrators must explicitly select and install IIS. IIS installs by default

in a locked-down state, capable of serving only static content. Using the

Web Service Extensions node, Web site administrators can configure IIS

for Dynamic Content IIS functionality based on the individual needs of

their organization. IIS 6.0 includes a variety of security in IIS 6.0 features

and technologies to help ensure the integrity of the Web and FTP site con-

tent, as well as the data transmitted through the sites.

4.3.5 Chosen development language

The default scripting language used for writing ASP is VBScript, (Micro-

soft's version of JavaScript). Implementation Technology specifications,

such as: XML (Extensible Mark-up Language), and OLE (Object Linking

and Embedding).

4.3.6 Chosen development tools

HL7 software application development will use the following Microsoft

development and platform technologies:

49

Microsoft Visual Studio 2005 Team System

Web Services Enhancements for Microsoft .Net version 2.0

Microsoft .Net Framework

Microsoft BizTalk Server 2004

Microsoft SQL Server

Microsoft Active Directory

Microsoft Windows Server Platform

4.4 Hardware and Software Requirements

4.4.1 Hardware Requirements

4.4.1.1 Client Side

Hardware Requirement

Processor Intel(R) Pentium(R) 160GHZ or any Compatible

Higher processors

Memory (RAM) Minimum 64MB (128 MB or more recommended)

Hard disc space Minimum 2GB

Others Network interface card and other standard computer

Peripherals

50

4.4.1.2 Server Side

Hardware Requirement

Processor Pentium III 800 MHZ or higher and other

Equivalent processors

Memory (RAM) Minimum of 256MB, 1GB recommended

Hard disc space Minimum of 10GB or more recommended

Others Network interface card and other standard computer

Peripherals

4.4.2 Software Requirements

4.4.2.1 Client Side

Software Requirement

Operation system Microsoft Windows XP Professional

Browser Microsoft Internet Explorer 5.01 or above

4.4.2.2 Server Side

Software Requirement

Operation System Microsoft Windows XP Professional

51

Web Server Microsoft internet information server 6.0

Web Database Microsoft My SQL server 2000

Browser Microsoft Internet Explorer 5.01 or above

4.5 Chapter Summary

Above all the key of success lies on how the system will be used and who are the

rights users. In order to achieve a comprehensive system certain requirements ought

to be met in terms of choosing the appropriate tools and platforms, developing lan-

guage. In addition, determining the proper functional and non functional require-

ments would play an important role and meeting system criteria.

52

CHAPTER FIVE

SYSTEM

ARCHITECTURE & DESIGN

53

5.1 Chapter preview

In this chapter, will define the Easylink model and elaborate its design objectives

and Functional Overview. On the other hand, the chapter will present the proposed

architecture, framework and design components. Furthermore, examines the func-

tionality of the proposed system by designing an easy access user-friendly interfaces

that are presented throughout multipurpose screens and can only be accessed by pa-

tients, physicians and healthcare administrations.

5.1.1 Design Overview

The successful design and development of any software depends on capturing

the right user requirement. If requirements do not reflect the exact needs of the

end user a lot of misunderstandings and mistakes will occur and this may lead

to product failure on all counts. Philips stated that "The design is an important

process in the development of the proposed project and should be carried out

thoroughly before production of final system is started‖ (1997).

The main purpose of Easylink is to present the time order flow of information

among aggregated servers which are appropriate for large data sets in general

and responsible for the continuing of the real-time data in particular. Easylink

is an appropriate and useful web based application that enables patients, doc-

tors and system providers, to electronically interact, exchange medical and

clinical information in an integrated behavior. The powerful programming se-

mantic for handling the exchange of continuous data allows the process to be

extended over relatively long period of time in real time (Tsang, Lau, Leung,

2005). In the context of Easylink the flow of exchange data refers to a network

communication facility by means of which two distributed applications are

54

connected via their end-point interfaces. The flow of exchanged data will be

based on HL7 Version 3 which essentially describes a transfer protocol that is

used between health care databases, in which, it has some proficient features,

and utilizes XML to make it much more accessible.

5.2 System Architecture:

Two architectures were considered in this project, client server architecture and

peer-to-peer architecture. Client-server architecture where clients make request

to a centralized server, this server is responsible for processing requests from

all clients. Peer-to-peer architecture is more of a distributed architecture where

every machine on the network performs as a client and server. The architecture

adopted for the prototype is Service-oriented architecture (SOA) hybrid peer-

to-peer combination of both client server and peer-to-peer architecture. Clients

can request from a central server and other clients. This is supposed to be a

suitable solution as it reduces dependency on the server and at the same time

clients will also be able to connect to their peers when requesting from files.

The peer-to-peer architecture allows machine resources on client machines to

be well utilized and reduce server load (Arsanjani, 2004).

Service-oriented architecture (SOA) is an open and flexible architecture on

which applications and services can be run. SOA can also be regarded as a

style of information systems architecture that enables the creation of applica-

tions that are built by combining loosely coupled and interoperable services

(Tsai, Chen, & Fan, 2006). These services inter-operate based on a formal de-

finition such as (WSDL) that is independent of the underlying platform and

programming language. The interface definition hides the implementation of

the language-specific service. SOA based systems can therefore be indepen-

dent of development technologies and platforms (such as Java, .NET etc). In

addition, applications running on either platform can consume services running

on the other as Web services (Utschig, Rodriguez, & Buelow, 2006).

55

The proposed architecture focuses on the services rather than the application.

This also eliminated the dependencies on databases supported by vendors. The

flexibility of the architecture was insured by adoption of standard technologies

for all layers of the architecture and the messaging itself.

HL7 RIM V3 as the messaging format was decided for this architecture HL7

is a healthcare standard for messaging which is widely being adopted by

healthcare and related service providers in their initiative for unified interoper-

able electronic health standards and implementation of nationwide Electronic

Health records (Shakir et al, 2007) and (Regio, 2005). The messaging included

a layer of abstraction in the form of an intermediate XML format. There was a

multi version support of the application for database structure and application

behaviors for easy change/upgrade and switching functionalities. We present a

clearly defined mapping from the physical data model onto the logical data

model and from the triggers used by the application to those used in the inter-

faces. Messaging hub has a robust tracking and logging system, which logs

everything (including wrappers, etc.) that which is actually send or received is

crucial. The design also addressed issues related to failure of real-time interac-

tion and how the message would be handled for receipt and delivery of mes-

sage. There was also consideration of data synchronization for queries, queues,

and so forth.

The scope and function of each of the architectural components is as follows:

56

Figure “13”, SOA Architecture

1. Authentication and Authorization.

This portion of the architecture provides technologies and processes used to au-

thenticate users and authorize their access to system applications and resources.

Authentication uses a LDAP implementation to authorize personnel and re-

sources to access application system. The directory includes identification, de-

mographic,

2. Health Alert Network (HAN).

This portion of the architecture provides technologies and processes used to

communicate notifications, warnings, and alerts. The alerts may be initiated by an

authorized user or by detection of triggering events within application systems. A

personnel directory is used to maintain the identification, demographics, and

communication addresses for potential alert recipients. A customizable set of

rules is used to determine the appropriate communication mode to use for a given

type of alert (telephone, email, pager, or fax) and to determine the escalation re-

quired for communications that are not acknowledged by the recipient within a

predetermined threshold of time

57

3. PHIMS Inbound Message Processing.

This portion of the architecture provides the technologies and processes necessary

to receive data electronically from external partners (e.g., Hospitals, Laboratories,

and Physician Offices) and internal application systems. The inbound message

processing component is configured to accept data in a variety of standard and

proprietary formats. Supported standard formats include HL7 v2, v3 and CDA,

X12, and NCPDP. Proprietary formats include any form of ASCII file including

XML documents, delimited and no delimited flat files, and encapsulated files

such as PDFs and images. Data are extracted from inbound transactions and

placed into a staging area for use in importing into the Operational Data Store

(ODS) and creation of outbound messages.

4. PHIMS Outbound Message Processing.

This portion of the architecture provides the technologies and processes necessary

to send data electronically to external partners (e.g., Hospitals, Laboratories, and

Physician Offices) and other application systems. The outbound message

processing component is configured to create outbound transactions in a variety

of standard and proprietary formats depending upon the requirements of the re-

ceiving application. Supported standard formats include HL7 v2, v3, and CDA,

X12, and NCPDP. Proprietary formats include any form of ASCII data file. Data

for outbound transactions are retrieved from a staging area populated from the op-

erational data store (ODS) or directly from functional area modules. Outbound

message processing transforms the data in the staging areas into the appropriate

transaction format for the recipient.

5. Knowledge Management System (KMS).

This component of the architecture provides the technologies and processes ne-

cessary to maintain coded terminologies and lexicons used in inbound and out-

bound messages, the ODS, and functional area modules. The KMS component is

configured to import clinical terminologies such as SNOMED, LOINC, and CPT

as well as proprietary coding systems. Linkages are maintained between coded

58

terminologies that facilitate the translation of codes from one terminology to

another as well as provide a knowledgebase for use in rules processing, inference

logic, and workflow management.

6. Public Health Data mart

This component of the architecture provides the technologies and processes ne-

cessary to extract, transform, and load data from the ODS and inbound message

staging area into a star-schema based data structure used for analytical reporting.

The data mart is a collection of fact tables and conforming dimension tables de-

signed to provide an integrated multidimensional view of public health data.

Common dimensions include factors such as time, location, demographics, and

organization. Facts include items such cases, admissions, and observations.

7. Business Intelligence Environment (Public Health Dashboard).

This component of the architecture provides the technologies and processes ne-

cessary to provide access to data in the data mart for use in analysis and visualiza-

tion. The Business Intelligence Environment included multidimensional analysis

tools, statistical tools, and geo-mapping tools to provide a comprehensive view of

public health data. The Business Intelligence Environment includes a public

health dashboard application that provides a set of measures declared by county

management to be of greatest interest, quick links to information of interest, and

Web services that expose information from other PAMs and external services.

Users of the dashboard application can drill down into the numbers which influ-

ence the measures from there they can slice, dice, and pivot the data as needed.

The mapping software enables the data to be plotted on maps that can also be

drilled and customized to fulfill a particular analytical need.

8. Operational Data Store.

This component of the architecture provides the technologies and processes ne-

cessary to integrate data from inbound processing and functional area modules in-

to a single data store. The design of the ODS is based upon the Health Level Sev-

59

en (HL7) Reference Information Model (RIM). The data store is highly abstracted

allowing it to collect any data that can be mapped to the entity, role, participation,

act paradigm of the HL7 RIM. Data to be imported into the ODS are first placed

into a staging area and are then transformed and imported into the ODS. An ODS

API is under construction. The API will accept any HL7 v3 styled transactions

and generate RIM objects. The RIM objects are then stored in the ODS using

ORM software (i.e., Hibernate). The API will simplify the importing of data into

the ODS. Inbound messages of any type can be transformed into HL7 v3 styled

transactions and automatically mapped for import into the ODS.

9. Functional Area Modules (PAMS, CAMS and Shared Services).

This component of the architecture is the most essential. The functional area

modules include the applications, common routines, and services used to address

tactical public health information processing requirements. Applications such as

communicable disease reporting, nursing practice management and laboratory in-

formation management make up the functional area modules as well as services

such as geo-coding, identity managements, and record locator.

5.3 Chosen Development platform

Microsoft Windows XP Professional

Advantages of using windows XP Professional:

The reason why Microsoft Windows XP Professional is chosen because it

offers variety of features which is unavailable in the Home Edition such

as:

1. Internet Information Services (IIS) Microsoft's HTTP and FTP server.

2. Provide the ability of being part of Windows Server domain, in which

several computers can be remotely managed by one or many central com-

puters.

60

3. Encryption File System, providing encryptions for files which are stored

on computer's hard drive so they cannot be read by another user, even with

physical access to the storage medium.

4. Remote Desktop server, by allowing the PC to be operated by another

Windows XP user over local network or Internet.

5. Centralized administration features, including Automatic Software Installa-

tion and Maintenance, Roaming user profiles and Remote Installation ser-

vice (RIS).

5.4 System Components

1- Patients:

As the proposed project aimed to provide easy and secure access for patient‘s in-

formation, patients are the most beneficiary of the system outcome. In normal

healthcare procedures new patients have to go to clinic or hospital and fill in a regis-

tration form and wait to be diagnosed and then have to wait for long time for an

available doctor, but with Easy link patients can register online, they just have to

sign up and fill-in the registration form. By having an authorized access online they

can check their result, contact their doctors and furthermore they will be able to pay

online. Easy link is a system that facilitates an easy access for patient‘s accounts

24/7 from any location. In which cost and time have been taken into consideration.

61

Figure “14”, Patient‟s Main page

Then Patient information will be saved in the clinic database and a National

Health Number (NHS) number, which is unique for each patient, will be automat-

ically generated and sent to the patient via Email. In terms of security

Figure “15”, Registration conformation

62

Once the patient has received the NHS number and has confirmed by signing in

through the URL link sent to him, he can easily login to his Easylink account, in

order to activate it.

Figure “16”, Patient‟s login

Each Patient has two, Electronic Medical Records (EMR):

1. Summary Record:

The summary record is accessible by patient and consists of two parts: clinical

and medical information.

63

Figure “17”, Patient‟s Summery Record

Clinical information:

Patient‘s Demographic Information. This information contains patient's personal

information that can be updated frequently

Figure “18”, Patient‟s Demographic Information

Available Doctors‘ list, from which patient can select a specialized doctor from

the list for any inquiries or consultations

64

Figure “19”, Available doctor‟s Contacts

Payment information in which patient can proceed online payment, incase of phar-

macy payment or print out the receipt and pay at any branch for Lab and ADT

payments

Figure “20”, Payment page

65

Medical Information:

Medical information is accessible by patient but not changeable. Patient can view medi-

cal information such as medication and test result but unauthorized to perform any

changes like edit or delete.

Figure “21”, Patient‟s Medical Information

2. Detailed Record:

The Patient's private record (PPR) which is accessible by doctors and healthcare

providers, but not accessible by patients (PPR) contains:

PPR contains Patients health history,

66

Figure “22”, Patient‟s Private record (PPR)

Medications which are assigned by doctors

Figure “23”, Pharmacy‟s Page

Laboratory and radiology results

67

Figure “24”, Laboratory‟s page

2- Doctors:

Doctors are the backbone of Easylink in the sense that all interactions and exchange

of medical information among Patients, Laboratory, and Pharmacy are issued and

approved by doctors, as well as responses to patient's inquiries and, online consulta-

tions.

Assuming that doctors are already part of Easylink, all doctor have and ID Number

and password that enable them to login

68

Figure “25”, Doctor‟s login

When Doctors login they can trace the patient's private information by entering the

patient‘s NHS

69

Doctor‟s login Figure “26”, Browsing Patient‟s Private records

By entering a patient's NHS number, a doctor can access PPR, view the patient's

medical history, make a decision whether, the patient needs to do tests or x-rays and

then send the order to the laboratory

70

Figure “27”, Requested X-ray

71

After getting results from the laboratory, a doctor has to update PPR and assign ap-

propriate medicine to the patient by sending on order to the Pharmacy accordingly.

Figure ―28‖, X-ray results Updated by Lab

72

Figure “29”, Recommended Medicine

73

3. Administration

The admin role in Easylink depends on patient‘s medical situation, in case of admission

and discharge. Admin can login and follow up patients throw their NHS, to produce ad-

mission, discharge, procedure and payments procedures.

Figure „30”, Administration Login

74

5.5 Implementation

The implementation phase is the next stage after testing the system according to

the required specifications. Easylink ought to be uploaded on a local clinic server

connected with several computers for testing purpose. By using IIS services.

The implementation phase includes the following steps:

System installation: The system must be installed in a proper environment

on local intranet network for testing.

User training: System users ought to be provided with sufficient training,

with accordance to user acceptance of the tested system specification.

Training for patients would be provided through out online documentation

guidance. Whereas, Doctors and healthcare providers would be provided

with manual guidance.

After the implementation phase Easylink can be uploaded on the internet for pa-

tient‘s registration and interactions.

5.6 Chapter Summary

This chapter presents the very top objective of the proposed system, throughout

facilitating a secured web-based system, which is user friendly, available 24/7

with quick response time and wide accessibility by healthcare participants such as

patients, doctor and healthcare providers. It also has a principle idea, in which ag-

gregating everything into one electronic process would help in eliminating the

cost, time and drudgery associated with previous schemes. Sufficient training and

maintenance is suggested for system implementation

75

CHAPTER SIX

TESTING & VALIDATION

76

6.1 Chapter Preview

This Chapter focuses on the system testing and validation according to the pro-

posed specifications, which will include programming codes and testing forms

and a general conclusion of the entire dissertation. Additionally further study will

be addressed.

6.2 Testing and validation

Chan and Chen (2002) in their study have classified the testing object oriented programs

into various levels and identified several testing techniques, such as state-based testing,

testing against formal specifications, UML based techniques, Data flow analysis and fault

based techniques.

This study will focus on the testing against formal specification, in which each input must

match the system‘s forms specifications as following:

Patients

Patients Login:

Username: sara

Password:******

Submit

User name and password used for testing

User name: Sara

Password: Sara

77

For actual system patients login the username and password that they have entered in the registra-

tion form.

In order to perform the above patient login valid data must be entered to avoid the occur-

rence of error message, for testing reasons both user ID and Password were identified as

alphabets, entering a digit in any field will generate an error message. On the other hand

the above form is to be used by registered patients only because after login patients in-

formation will be validated against their registration form. Any incorrect input will cause

invalid operation. For the above Patient Id: Sara and Password: Sara

The following codes demonstrate the user login and information validation.

<%@LANGUAGE="JAVASCRIPT" CODEPAGE="1252"%>

<!--#include file="../Connections/easylink2.asp" -->

<%

// *** Edit Operations: declare variables

// set the form action variable

var MM_editAction = Request.ServerVariables("SCRIPT_NAME");

if (Request.QueryString) {

MM_editAction += "?" + Server.HTMLEncode(Request.QueryString);

}

// boolean to abort record edit

var MM_abortEdit = false;

// query string to execute

var MM_editQuery = "";

%>

<%

// *** Insert Record: set variables

if (String(Request("MM_insert")) == "form2") {

var MM_editConnection = MM_easylink2_STRING;

var MM_editTable = "Patients";

var MM_editRedirectUrl = "conformation.asp";

78

var MM_fieldsStr =

"First|value|last|value|sex|value|Date|value|address|value|Contact|value|email|value|username|value|password|value|aller

gies|value|prior surgeries|value|Personal injuries|value|previous treatment|value|Medical conditions|value";

var MM_columnsStr =

"Fname|',none,''|Lname|',none,''|Gender|',none,''|DOB|',none,NULL|address|',none,''|ContactNo|none,none,NULL|[Email

Address]|',none,''|username|',none,''|password|',none,''|Allergies|',none,''|[Prior surgeries]|',none,''|[personal injuries or ac-

cident]|',none,''|[Previous treatment]|none,none,NULL|[Health conditions]|',none,''";

// create the MM_fields and MM_columns arrays

var MM_fields = MM_fieldsStr.split("|");

var MM_columns = MM_columnsStr.split("|");

// set the form values

for (var i=0; i+1 < MM_fields.length; i+=2) {

MM_fields[i+1] = String(Request.Form(MM_fields[i]));

}

// append the query string to the redirect URL

if (MM_editRedirectUrl && Request.QueryString && Request.QueryString.Count > 0) {

MM_editRedirectUrl += ((MM_editRedirectUrl.indexOf('?') == -1)?"?":"&") + Request.QueryString;

}

}

%>

<%

// *** Insert Record: construct a sql insert statement and execute it

if (String(Request("MM_insert")) != "undefined") {

// create the sql insert statement

var MM_tableValues = "", MM_dbValues = "";

for (var i=0; i+1 < MM_fields.length; i+=2) {

var formVal = MM_fields[i+1];

var MM_typesArray = MM_columns[i+1].split(",");

var delim = (MM_typesArray[0] != "none") ? MM_typesArray[0] : "";

var altVal = (MM_typesArray[1] != "none") ? MM_typesArray[1] : "";

var emptyVal = (MM_typesArray[2] != "none") ? MM_typesArray[2] : "";

if (formVal == "" || formVal == "undefined") {

formVal = emptyVal;

} else {

if (altVal != "") {

formVal = altVal;

79

} else if (delim == "'") { // escape quotes

formVal = "'" + formVal.replace(/'/g,"''") + "'";

} else {

formVal = delim + formVal + delim;

}

}

MM_tableValues += ((i != 0) ? "," : "") + MM_columns[i];

MM_dbValues += ((i != 0) ? "," : "") + formVal;

}

MM_editQuery = "insert into " + MM_editTable + " (" + MM_tableValues + ") values (" + MM_dbValues + ")";

if (!MM_abortEdit) {

// execute the insert

var MM_editCmd = Server.CreateObject('ADODB.Command');

MM_editCmd.ActiveConnection = MM_editConnection;

MM_editCmd.CommandText = MM_editQuery;

MM_editCmd.Execute();

MM_editCmd.ActiveConnection.Close();

if (MM_editRedirectUrl) {

Response.Redirect(MM_editRedirectUrl);

}

}

}

%>

<%

var allergies = Server.CreateObject("ADODB.Recordset");

allergies.ActiveConnection = MM_easylink2_STRING;

allergies.Source = "SELECT * FROM Allergies";

allergies.CursorType = 0;

allergies.CursorLocation = 2;

allergies.LockType = 1;

allergies.Open();

var allergies_numRows = 0;

%>

<%

var hconditions = Server.CreateObject("ADODB.Recordset");

hconditions.ActiveConnection = MM_easylink2_STRING;

hconditions.Source = "SELECT * FROM [Health condition]";

hconditions.CursorType = 0;

hconditions.CursorLocation = 2;

80

hconditions.LockType = 1;

hconditions.Open();

var hconditions_numRows = 0;

%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Untitled Document</title>

<style type="text/css">

<!--

body {

background-image: url(../pictures/bp.gif);

}

#Layer1 {

position:absolute;

left:25px;

top:41px;

width:299px;

height:187px;

z-index:1;

}

.style1 {

font-size: 18px;

font-weight: bold;

}

.style2 {font-size: 12px}

.style3 {font-size: 14px}

#Layer2 {

position:absolute;

left:361px;

top:36px;

width:316px;

height:401px;

z-index:2;

}

-->

</style>

</head>

81

<body>

<div class="style1" id="Layer1">

<p>Exsisting Patient : </p>

<p><a href="plogin.asp">Click here </a></p>

</div>

<div class="style1" id="Layer2">

<p>Or Register here : </p>

<form ACTION="<%=MM_editAction%>" METHOD="POST" name="form2" id="form2">

<h3>Add New Patient</h3>

<p>First name:

<input type="text" name="First" />

<br />

Last name:

<input type="name" name="last" />

<br />

<input type="radio" name="sex" value="M" />

Male

<input type="radio" name="sex" value="F" />

Female <br />

DOB:

<input type="Date of birth" name="Date" value="dd/mm/yyyy" />

<br />

Address:<br />

<textarea name="address" cols="40" rows="3" wrap="virtual" id="address"></textarea>

<br />

Contact No:

<input type="text" name="Contact" />

<br />

Email address:

<input type="text" name="email" />

<br />

Username:

<input name="username" type="text" id="username" />

<br />

Password:

<input type="password" name="password" />

<br />

Allergies to Medication:

<label>

<select name="allergies" id="allergies">

<%

82

while (!allergies.EOF) {

%>

<option val-

ue="<%=(allergies.Fields.Item("Allergies").Value)%>"><%=(allergies.Fields.Item("Allergies").Value)%></option>

<%

allergies.MoveNext();

}

if (allergies.CursorType > 0) {

if (!allergies.BOF) allergies.MoveFirst();

} else {

allergies.Requery();

}

%>

</select>

</label>

<br />

Prior Surgeries:

<label>

<select name="prior surgeries" id="prior surgeries">

<option value="Yes">Yes</option>

<option value="No">No</option>

</select>

</label>

<br />

Personal Injury or Accident:

<select name="Personal injuries" id="Personal injuries">

<option value="Yes">Yes</option>

<option value="No">No</option>

</select>

<br />

Previous Treatment:

<select name="previous treatment" id="previous treatment">

<option value="Yes">Yes</option>

<option value="No">No</option>

</select>

<br />

Medical Condition:

<select name="Medical conditions">

<%

while (!hconditions.EOF) {

%>

83

<option value="<%=(hconditions.Fields.Item("Health Condi-

tions").Value)%>"><%=(hconditions.Fields.Item("Health Conditions").Value)%></option>

<%

hconditions.MoveNext();

}

if (hconditions.CursorType > 0) {

if (!hconditions.BOF) hconditions.MoveFirst();

} else {

hconditions.Requery();

}

%>

</select>

</p>

<p>

<label>

<input type="submit" name="Submit2" value="Submit" />

</label>

<br />

</p>

<input type="hidden" name="MM_insert" value="form2">

</form>

</body>

</html>

<%

allergies.Close();

%>

<%

hconditions.Close();

%>

Doctors

Doctors Login:

Doctor ID: 1

Password:****

84

Submit

User IDs and Passwords that has been used for testing are:

IDs Range from 1 -9

Passwords From x10x – x90 respectively

In order to perform the above Doctor‘s login the system will check each Doctor validity,

as the ID contain only digits and must be within the range from 1 to 9, whereas the pass-

word contains both digits and alphabets. For testing the chosen values where from x10x

x90x respectively. If invalid values have been enter an error message will appear in the

login procedure must be repeated. For example for ID: 1, the Password is: x10x and so

on.

The following code will examine the validity of Doctors login

<%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>

<!--#include file="../Connections/easylink.asp" -->

<%

' *** Validate request to log in to this site.

MM_LoginAction = Request.ServerVariables("URL")

If Request.QueryString<>"" Then MM_LoginAction = MM_LoginAction + "?" + Serv-

er.HTMLEncode(Request.QueryString)

MM_valUsername=CStr(Request.Form("textfield"))

If MM_valUsername <> "" Then

MM_fldUserAuthorization=""

MM_redirectLoginSuccess="doc.asp"

MM_redirectLoginFailed="error.html"

MM_flag="ADODB.Recordset"

set MM_rsUser = Server.CreateObject(MM_flag)

MM_rsUser.ActiveConnection = MM_easylink_STRING

MM_rsUser.Source = "SELECT ID, Password"

If MM_fldUserAuthorization <> "" Then MM_rsUser.Source = MM_rsUser.Source & "," &

MM_fldUserAuthorization

85

MM_rsUser.Source = MM_rsUser.Source & " FROM Docs WHERE ID='" & Replace(MM_valUsername,"'","''") &"'

AND Password='" & Replace(Request.Form("textfield2"),"'","''") & "'"

MM_rsUser.CursorType = 0

MM_rsUser.CursorLocation = 2

MM_rsUser.LockType = 3

MM_rsUser.Open

If Not MM_rsUser.EOF Or Not MM_rsUser.BOF Then

' username and password match - this is a valid user

Session("MM_Username") = MM_valUsername

If (MM_fldUserAuthorization <> "") Then

Session("MM_UserAuthorization") = CStr(MM_rsUser.Fields.Item(MM_fldUserAuthorization).Value)

Else

Session("MM_UserAuthorization") = ""

End If

if CStr(Request.QueryString("accessdenied")) <> "" And false Then

MM_redirectLoginSuccess = Request.QueryString("accessdenied")

End If

MM_rsUser.Close

Response.Redirect(MM_redirectLoginSuccess)

End If

MM_rsUser.Close

Response.Redirect(MM_redirectLoginFailed)

End If

%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Untitled Document</title>

<style type="text/css">

<!--

body {

background-image: url(../pictures/bp.gif);

}

#Layer1 {

position:absolute;

left:25px;

top:41px;

width:299px;

height:187px;

86

z-index:1;

}

.style1 {

font-size: 18px;

font-weight: bold;

}

.style2 {font-size: 12px}

.style3 {font-size: 14px}

#Layer2 {

position:absolute;

left:362px;

top:44px;

width:165px;

height:257px;

z-index:2;

background-image: url(../pictures/doc.jpg);

}

-->

</style></head>

<body>

<div class="style1" id="Layer1">

<p>Doctors Login : </p>

<form id="form1" name="form1" method="POST" action="<%=MM_LoginAction%>">

<label>

<span class="style2">Doctor ID : </span>

<input name="textfield" type="text" size="10" maxlength="5" />

</label>

<pre class="style2">Password:<input type="password" name="textfield2" />

</pre>

<label></label>

<p>

<label>

<input type="submit" name="Submit" value="Submit" />

</label>

</p>

</form>

</div>

<div id="Layer2"></div>

</body>

</html>

87

Administration:

Administration Login:

Username: admin

Password:*****

Submit

Username and Password that has been used for testing are:

Username: admin

Password: Admin

The above form validates the Authorization system‘s Admin, as only authorized admin

can login to the above form, otherwise will cause invalid operation. For testing purpose

both user ID and Password were identified as Admin any invalid input will cause the ac-

cordance of error message

<%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>

<!--#include file="../Connections/easylink.asp" -->

<%

' *** Validate request to log in to this site.

MM_LoginAction = Request.ServerVariables("URL")

If Request.QueryString<>"" Then MM_LoginAction = MM_LoginAction + "?" + Serv-

er.HTMLEncode(Request.QueryString)

MM_valUsername=CStr(Request.Form("textfield"))

If MM_valUsername <> "" Then

MM_fldUserAuthorization=""

MM_redirectLoginSuccess="adminsearch.asp"

MM_redirectLoginFailed="error.html"

MM_flag="ADODB.Recordset"

set MM_rsUser = Server.CreateObject(MM_flag)

MM_rsUser.ActiveConnection = MM_easylink_STRING

88

MM_rsUser.Source = "SELECT username, password"

If MM_fldUserAuthorization <> "" Then MM_rsUser.Source = MM_rsUser.Source & "," &

MM_fldUserAuthorization

MM_rsUser.Source = MM_rsUser.Source & " FROM admin WHERE username='" & Re-

place(MM_valUsername,"'","''") &"' AND password='" & Replace(Request.Form("textfield2"),"'","''") & "'"

MM_rsUser.CursorType = 0

MM_rsUser.CursorLocation = 2

MM_rsUser.LockType = 3

MM_rsUser.Open

If Not MM_rsUser.EOF Or Not MM_rsUser.BOF Then

' username and password match - this is a valid user

Session("MM_Username") = MM_valUsername

If (MM_fldUserAuthorization <> "") Then

Session("MM_UserAuthorization") = CStr(MM_rsUser.Fields.Item(MM_fldUserAuthorization).Value)

Else

Session("MM_UserAuthorization") = ""

End If

if CStr(Request.QueryString("accessdenied")) <> "" And false Then

MM_redirectLoginSuccess = Request.QueryString("accessdenied")

End If

MM_rsUser.Close

Response.Redirect(MM_redirectLoginSuccess)

End If

MM_rsUser.Close

Response.Redirect(MM_redirectLoginFailed)

End If

%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Untitled Document</title>

<style type="text/css">

<!--

body {

background-image: url(../pictures/bp.gif);

}

#Layer1 {

position:absolute;

left:25px;

89

top:41px;

width:299px;

height:187px;

z-index:1;

}

.style1 {

font-size: 18px;

font-weight: bold;

}

.style2 {font-size: 12px}

.style3 {font-size: 14px}

#Layer2 {

position:absolute;

left:362px;

top:44px;

width:165px;

height:257px;

z-index:2;

background-image: url(../pictures/doc.jpg);

}

-->

</style></head>

<body>

<div class="style1" id="Layer1">

<p>Administrator Login : </p>

<form id="form1" name="form1" method="POST" action="<%=MM_LoginAction%>">

<label>

<span class="style2">Username : </span>

<input name="textfield" type="text" />

</label>

<pre class="style2">Password:<input type="password" name="textfield2" />

</pre>

<label></label>

<p>

<label>

<input type="submit" name="Submit" value="Submit" />

</label>

</p>

</form>

</div>

90

<div id="Layer2"></div>

</body>

</html>

6.3 Conclusion

Over the past few decades Patients‘ information confidentiality has been an emer-

gent issue that required to be dealt with constantly. However, many studies have

been conducted in this area, yet some studies lack to identify the actual gap be-

tween traditional medical records and web-based medical system that involve pa-

tient‘s interaction. Such gap occurs due to the lack of patient‘s knowledge about

new technologies. Consequently, the main concern of recent researches is focused

on facilitating a high level of security for patient‘s information transmission. This

project has clearly demonstrated the importance of a web based medical record

system that can be effectively used by patients to follow up clinical results, la-

boratory tests, drug supplies, and create reports for funding organizations. The

study intends to encourage patients to go on line in order, to follow-up their lab

results, medications records, requests refills and appointments and e-mail their

physicians for non –urgent medical questions. However, there are various issues

about patients‘ privacy, costs and time constraints need to be taken into considera-

tion,

The main concern of the proposed project is the portability of medical care. As

patient can remotely use the system while vacation or abroad does not have to

worry about consistency in care. Accordingly If patients need to acknowledge

their employers about a certain health condition, they could easily download a re-

port from a secured a Web portal. On the other hand, they system allows patients

with infectious illnesses or those who feel too embarrassed to go to a clinic for a

91

checkup, to register on line and request a consultation, fix appointments and fol-

low-up their results and medications after being diagnosed.

Furthermore, data security and patient‘s confidentiality can only be achieved if

users have complex passwords that enable them to only access the required parts

of the site. Additionally, having a centralized database, would allow the computer

data to be physically secure and backed-up regularly. The facility of viewing pa-

tient details securely via the electronic medical record plays an important role in

avoiding the information that is sent by non-secure e-mail. Moreover the encryp-

tion of the transferred data ought to be done with the use of Healthcare Level 7

(HL7) rather than Secure Socket Layer (SSL).

The system is expected to assist patients with all aspects of services, especially

patients with infectious illnesses who are an able to communicate with doctors in

person. However, the implementation of such system might face some challenges

in rural areas with the accordance of lack of knowledge and low internet connec-

tivity. Therefore, further studies ought to facilitate an appropriate system that

overcomes rural area challenges.

6.4 Further Study

Expected intend of HL7 v3, is to produce a consistent definition for different in-

formation objects and throughout an appropriate message structure, which al-

lows easier implementation and illustrate a clearer conformance requirements.

Furthermore, HL7 V3 standards were developed as syntax-independent models.

The current preferred implementation technology is Extensible Mark-up Lan-

guage (XML). HL7 is well represented in the World Wide Web Consortium

(W3C) concerned with the future development. Another driving factor in HL7's

future direction is the globalization of the marketplace and the resulting need to

share information across national boundaries. Additionally, the rapid increase in

92

technology techniques might widen the usage of HL7 standards in healthcare

arena worldwide.

6.5 Chapter Summary

The system testing and validation is important to examine the validation of the

system and to determine the extent to which the proposed system met the required

criteria. The healthcare providers ought to weigh patient‘s awareness against the

upscale fact of nothing is totally secured. Adopting an HL7 protocol would assist

in assuring the secure exchange of patient‘s clinical and medical data. Further-

more by using such system patients would be capable to work hand in hand with

healthcare participants. Consequently, the importance of this system lays in the

significant of the secure and remote access. However, the adoption of such proto-

col might face some challenges at early stage.

References

Arsanjani, A. (2004, November, 9). Service-Oriented modeling and architecture: How to identify, Specify, and realize ser-

vices for your SOA, IBM. Retrieved April 20, 2008 from http://www.ibm.com/developerworks/library/ws-soa-

design1/

Barnes, S., Scornavacca, E. (2005). Unwired business: cases in Mobile Business. Hershey, U.S.A.: IRM press.

Bailey, A. (2001). Network technology for digital audio, pp.53-60. London, England: Focal Press.

Binary Spectrum. (2007). Client - Server Based EMR - a case study. Binary Spectrum. Retrieved August 25, 2007 from

http://www.binaryspectrum.com/casestudies/Client-Server-Based-EMR.html

Baumer, D., Earp, J., Payton, F. (2000, December). Privacy of medical records: IT implications of HIPAA. Association for

computer Machinery, 30(4), 40-47. Retrieved February 3rd, 2007 from

http://delivery.acm.org/10.1145/580000/572261/p40-

bau-

mer.pdf?key1=572261&key2=6050298721&coll=GUIDE&dl=GUIDE&CFID=96696435&CFTOKEN=20857063

Castro, J. (1994). The American way of health: How Medicine Is Changing and What It Means to You. U.S.A: Amazon.com.

Chan, W., Chen T. (2002). An Overview of Integration Testing Techniques for Object-Oriented Programs.

International Association for Computer and Information Science 2nd ACIS Annual International Conference on

Computer and Information Science. Mt. Pleasant, Michigan. Retrieved December 5, 2007 from

http://www.cs.hku.hk/research/techreps/document/TR-2002-03.pdf

Contributor Melonfire. (2006, July 17). Capture the right user requirements with these best practices for writing software

specifications. TechRepublic. Retrieved March, 15, 2008 from http://articles.techrepublic.com.com/5100-

10878_11-6094986.html?tag=rbxccnbtr1

Core Point Health. (2007). The HL7 Evolution: Comparing HL7 version 2 to version 3, including a history of version

2. Core Point Health. Retrieved February 12, 2007 from

http://www.corepointhealth.com/sites/default/files/whitepapers/hl7-v2-v3-evolution.pdf

Crow, A. (2004). Defining the balance for now and the future - Clinicians perspective of implementing a care coordination

information systems management. Informit, 3.4. Retrieved September 20, 2006 from

http://search.informit.com.au/documentSummary;dn=885965610322532;res=IELHSS

Delbanco,T., Sands, D. (2004). Electrons in flight--e-mail between doctors and patients. The New England Journal of Med-

icine NEJM, 350(17), 1705-1707. Retrieved June 19, 2007 from

http://content.nejm.org/cgi/content/short/350/17/1705?query=prevarrow

Eysenbach G, Powell J, Kuss O, Sa ER. (2002, May 22). Empirical studies assessing the quality of health information for

consumers on the World Wide Web: A systematic review. JAMA, 287(20), 2691-2700. Retrieved October 2nd, 2007

from http://jama.ama-assn.org/cgi/reprint/287/20/2691

Ferguson, T., Frydman, G. (2004, May 15). The first generation of e-patients. British Medical Journal, 328(7449), 1148-

1149. Retrieved November 3rd, 2007 from http://www.bmj.com/cgi/content/extract/328/7449/1148

Finnell, J., Overhage, J., Dexter, P., Perkins, S., Lane, K., McDonald, C. (2003). Community Clinical Data Exchange for

Emergency Medicine Patients. AMIA 2003 Symposium Proceedings, 2003, 235-238. Retrieved October, 20, 2007

from http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1480174/pdf/amia2003_0235.pdf

Fransicsco, J. (2003, December). A Networked Patient Records Management System for Health Care Facilities. Journal of

Social Sience Research Network. Retrieved March, 2007 from

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=607447

Greenes, R., Shortliffe, E. (1990, February 23). Medical Informatics: An emerging discipline with academic and institution-

al priority Journal of American Medical Association, 263(8), 1114-1120. Retrieved June 12, 2007 from

http://www-ksl.stanford.edu/KSL_Abstracts/KSL-87-26.html

Grimson, J., Grimson, W., Berry, D., Stephens, G., Felton, E., Karla, D., Toussaint, P., Weier, O. (1998). A CORBA-Based

Integration of distributed electronic healthcare records using the synapses. ApproachIEEE Transactions on infor-

mation technology biomedicine, 2(3). Retrieved april 25, 2008 from

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00735777

Grimson, J., Grimson, W., Hasselbring, W. (2000, June 1st). This is challenge in Health care Information technology: ob-

vious integration challenges. Access My Library. Retrieved January 13, 2007 from

http://www.accessmylibrary.com/coms2/summary_0286-27927974_ITM

Gustafson, D., Wyatt, J. (2004, May 15). Evolution of e-health systems and services. British Medical Journal, 324(7449),

p.1150. Retrieved April 10, 2007 from http://www.bmj.com/cgi/content/extract/328/7449/1150

Health Informatics. (2003). Health Level 7. Medical informatics: Dalhouse University. Retrieved October 16, 2007 from

http://healthinfo.med.dal.ca/HL7Intro/963/992/992.html

Health Informatics. (2003a). Introduction to HL7: HL7V3 The flow of information. Health Informatics. retrieved Septem-

ber 10, 2007 from

Health Informatics. (2007. Getting started with HL7 V3: HL7 Overview: HL7 Version 3. Health Informatics.Retrieved De-

cember31st,2006 from http://healthinfo.med.dal.ca/HL7Intro/gettingstarted.html

Health Informatics. (2007a). Health Level 7: HL7 healthcare development framework. Health Informatics: Modeling and

methodology Work Group. Retrieved January 18, 2008 from http://healthinfo.med.dal.ca/HL7Intro/HDF_1.5.pdf

HL7 International. (2007). HL7 Standards. Health Level 7 international: Unlocking the power of Health information. Re-

trieved march 12, 2007 from http://www.hl7.org/implement/standards/index.cfm?ref=nav

HL7 International. (2007a). HL7 reference information model. Health Level 7 international: Unlocking the power of Health

information. Retrieved march 13, 2007 from http://www.hl7.org/implement/standards/rim.cfm

HermetechNZ. (2009). Easy HL7 products. Retrieved November 20, 2008 from

http://www.hermetechnz.com/EasyHL7/Default.asp?SessionID=C19F46AC-4717-4FF7-B77A-F62DFDB04C0C

Huff, S. (1998). Clinical Data Exchange Standards and Vocabularies for Messages. Intermountain Health Care. 1091(8280),

62-67. Retrieved November 29, 2006 from

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2232190/pdf/procamiasymp00005-0099.pdf

Hunter, I. (1997). Critical success factors for electronic medical records access by primary healthcare professionals: Patients

attitudes to electronic medical records. Thesis for Massy University, Auckland, New Zealand. Retrieved March 23,

2008 from http://www.privacy.org.nz/assets/Files/6257966.pdf

Imai, H., Rahman, MG., Kobara, K. (2005). Wireless communications security. Tokyo, Japan: Artech House.

Kaplan B. (2001). Consumer informatics supporting patients as co-producers of quality. Jornal of American Medical Infor-

matics Association, 8(4), 309, 316. Retrieved november 12, 2007 from

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC130075/pdf/0080309.pdf

Lin, C., Ross, S. (2003, April). The effects of promoting access to medical records. Journal of the American Medical In-

formatics Association, 10(2). Retrieved March 15, 2007 from

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC150366/pdf/0100129.pdf

McKesson, M. (2000, August 23). Health Level Seven Version 3 and XML. WEDI Technology Forum. Retrieved Septem-

ber 10, 2007 from http://healthinfo.med.dal.ca/hl7intro/indexorig.html

Matt, J., Marsden, G. (2005). Mobil Interaction design. London, U.K.: John Wiley and Sons.

Mead, C. (n.d.). Data interchange standards in healthcare IT—Computable semantic interoperability: Now

Possible but still difficult, Do we really need a better mousetrap?. Journal of health information management, 20(1). 71-78. Retrieved September 26, 2007 from http://74.125.155.132/scholar?q=cache:H-

qXVMCKCVQJ:scholar.google.com/&hl=en&as_sdt=2000

Phillips, R. (1997). The Developer's Handbook to Interactive Multimedia - A Practical Guide for Educational Applications.

London: Kogan Page.

Pires, F. (1994). Architectural notes: a framework for distributed systems development. Thesis for Doctorate. Retrieved

August 15, 2007 from http://doc.utwente.nl/66784/1/ferreira_pires-thesis.pdf

Poon, A., Fagan, L., Shortliffe, E. (1996). The PEN-Ivory project: exploring user-interface design for the selection of items

from large controlled vocabularies of medicine. Journal of the American Medical Informatics Association, 3(2),

168-83. Retrieved december 19, 2007 from http://www.biomedexperts.com/Abstract.bme/8653453/The_PEN-

Ivory_project_exploring_user-

interface_design_for_the_selection_of_items_from_large_controlled_vocabularies_of

Regio, M. (2005, April). Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Refer-

ence Implementation. MSDN Architecture Center. Retrieved July, 2007 from http://msdn.microsoft.com/en-

us/architecture/ms954603.aspx

Rodriquez, J., Utsching, C., Buelow, H. (2007, April 3rd). Web Services and SOA Practical Interoperability Approaches,

WS-Security and WS-Addressing Explained. SOA World. Retrieved June 15, 2008 from http://in.sys-

con.com/node/291043?page=0%2C0

Savvy doc. (2006, march 24). Fears over Patient Privacy. Savvy doc. Retrieved November 13, 2007 from

http://savvydoc.wordpress.com/2008/03/24/savvydoc-make-easy-appointments-online

Shakir, AM., Gardenas, D., Datta, G., Mittara, D., Basu, A., Rini, V. (2007).Design and Development of Standards (HL7

V3) Based Enterprise Architecture for Public Health Programs Integration at the County of Los Angeles. Interna-

tional Journal of Healthcare Information Systems and Informatics, 2(2), 53-66. Retrieved December 4, 2007 from

http://www.igi-global.com/Bookstore/Article.aspx?TitleId=2204

Shneiderman, B., Plaisant , C. (2004). Designing the User Interface: Strategies for Effective Human-Computer Interaction.

(4th ed.). Fremont, CA, U.S.A.: Pearson Addison-Wesley

Shortliffe, E. (1999, April). The evolution of electronic medical records. Journal of The Academic Medicine, 74(4), 414-

419. Retrieved January12, 2007 from

http://journals.lww.com/academicmedicine/Abstract/1999/04000/The_evolution_of_electronic_medical_records.38

.aspx

Shortliffe, E. (2000). Medical Informatics: Computer Applications in Health Care and Biomedicine. New York: Springer-

Verlag.

Stevens, H. (2003, October 30). Introduction to HL7 Version 3 Advanced Tutorial. Halifax.

Tanenbaum, A. (2003). Computer networks, (4th ed.), pp.498-530. U.S.A: Prentice Hall.

Tang, P., Hammond, W. (1997). A Progress Report on Computer-Based Patient Records in the United States. Journal of the

National Academies Press. Retrieved October, 11, 2007 from

http://www.nap.edu/openbook.php?record_id=5306&page=1

Tsang, C., Lau, C., Leung, Y. (2005).Object-Oriented Technology: from diagram to code with Visual Paradigm for UML.

Auckland, New Zealand: McGraw-Hill Companies.

Whitten, P., Cook, D. (2004). Understanding health communications technologies, (1st ed.). San Francisco, Calif. : Jossey-

Bass

WHO. (2000). The world health report 2000 - Health systems: improving performance. World Health Orgization Report.

Geneva: Switzerland. Retrieved March 12, 2007 from http://www.who.int/whr/2000/en/whr00_en.pdf

Winkelman, W., Leonard, K. (2004). Overcoming Structural Constraints to Patient Utilization of Electronic Medical

Records. Journal of the American Medical Informatics Association Volume 11 (2). Retrieved June 19, 2007 from

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC353022/pdf/151.pdf

Appendix

For implementation purpose the software has been uploaded into the internet server to be accessible by wide range of users

and health organizations.

The following web-pages explain the function of each component of Easylink system.

After accessing the URL address: http://www.easylink.co.nr/ the above front page will appear,

The system encloses three end users with different level of security as fallowing:

1. Patients

Patients can register online, they just have to sign up and fill-in the registration form. By having an authorized access online

they can check their result, contact their doctors and furthermore they will be able to pay online. Easy link is a system that

facilitates an easy access for patient‘s accounts 24/7 from any location. In which cost and time have been taken into consid-

eration.

The above page appears after selecting patients Icon from the front page

If the patient is unregistered they have to fill up the above form and clicks submit. So an NHS number will be assigned to

them once they validate their account. While, registered patients can log into their page from exiting patient‘s option by se-

lecting click here. The below page will appear.

After log in patients update their personal profile, view a list of available doctors and check their current payment sta-

tus. Note for every new patient the NHS number will appear in their personal page as following:

2. Doctors

Doctors can log in to the system using the Doctor ID and password when they register through the Admin. For

example

Doctor Id :1

Password : x10x

The following page will appear

By logging into their account, Doctors are able to perform the following function:

1. Doctor can perform a life chat via the Clinic Bulletin from as above

Through selecting the forward and backward arrows, and post reply

2. Search patients record by selecting the search icon on the top right of the page by clicking on the search

Icon a small page appear as bellow, where the doctor can enter

Patient NHS number as following

During viewing patients' private records doctors are able to:

1. Assign or change medicine by clicking on the pharmacy link

2. Right notes on patients lab result and assign and change the require test or x-ray according to

patient's health condition this will be done by clicking on the lab link

As explained in the following page:

3. Admin

Admin can log in into their account by entering their user name and password for example:

Username: haidoor

Password: Admin

Accordingly the following page will appear

By Logging into their account admin are able to trace patients‘ payments by clicking the search Icon on the top right of the

page, and are also able to chat on line with doctors. Additional admin is responsible of registering new doctors by clicking

on the bellow icon which refers to add new doctor

While the right icon link to the SQL and file manager

The above icons appears on each page refer to return to the front page, main page, and search respectively. Note: the

search icon is only used by doctors and admin to trace patients‘ information, where as patients are unable to search their pri-

vate record

Finally the main icon contain the system mission and general medical advice as below

Additionally, by clicking the below icon on page will return to the previous page