EHEALTH AS A-SERVICE A ERVICE BASED DESIGN APPROACH FOR LARGE SCALE EHEALTH ARCHITECTURE ·...

EHEALTH-AS-A-SERVICE: A SERVICE-

BASED DESIGN APPROACH FOR LARGE

SCALE EHEALTH ARCHITECTURE

Alofi Shane Black

Master Information Technology

Submitted in fulfilment of the requirements for the degree of

Doctor of Philosophy

School of Electrical Engineering and Computer Science

Science and Engineering Faculty

Queensland University of Technology

2018

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture i

Keywords

design science research; eHealth; eHealth-as-a-Service; eHaaS; information

manufacturing systems; Information quality; Microservices; MyHR; Patient Journey;

SAAS; service oriented architecture.

ii eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

Abstract

A significant challenge for the design of large scale (national) eHealth systems

is the fluid nature of the Patient Journey, particularly in primary healthcare modalities.

In this context, a patient’s journey is predisposed to organic growth rather than

intelligent design. As a result, clinical tasks requiring access to high quality

information may occur as a function of known healthcare patterns or as a response to

a patient’s state of health. Whilst Australia’s national eHealth system provides the

infrastructure to accommodate the self-organizing flexibility and dynamism

characteristic of complex information-based ecosystems, the system neglects certain

information quality attributes. Specifically, accuracy, timeliness and completeness,

which may lead to improved coordination of patient care. Based on the premise that

the quality of patient information plays a significant role in the performance of health

professionals, consideration must be given to these information quality dimensions as

an overarching goal for eHealth architectural design activities. Framed as a problem

concerning the design of large scale eHealth architecture that improves the quality of

health information, this perspective presents a timely research opportunity.

Within a prescriptive design science research (DSR) framework, this thesis is an

example of a multi-methodological approach to create and evaluate a purposeful

eHealth-as-a-Service (eHaaS) design artifact, which will improve patient information

quality. This was achieved by firstly, deriving abstract meta-requirements from an

ethnographic examination of care pathways to establish the technical goals of the

solution space. Secondly, defining the functions, organization, and structure of an

eHaaS conceptual model as an example of how service-based architectures might

deliver high quality information services. Finally, by establishing the validity of the

conceptual model with the development of a novel evaluation strategy to explain the

predicted change produced by an eHaaS design artifact.

Several original contributions emerged from the research. First and foremost, the

developed eHaaS conceptual model, which encapsulates a set of design principles,

service-based architectural patterns and implementation strategies represents a new

class of eHealth solution. One that embodies a shift away from data-centric monolithic

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture iii

architecture to process oriented, event-driven application services. To demonstrate the

benefits of this shift, an electronic patient information system (ePIMS) was developed

as an original solution for orchestrating clinical information services as personalised

patient workflows. Another significant contribution of this thesis is a novel evaluation

strategy for validating the utility of large scale eHealth systems at the design stage. It

is innovative in its use of business process and data modelling techniques (e.g. data

flow diagrams, business process modelling notation, information product mapping),

which measure the effect of functions and processes on the quality of clinical

information.

In this respect, the presented evaluation is among the first to find empirical

support for the information quality benefits of process oriented, event-driven eHealth

architecture. Based on their positive influence on the continuity of care, two quality

attributes, accuracy and timeliness, were evaluated. As a baseline for measuring the

accuracy of patient information, simulations of the largely paper based traditional

healthcare information system reported between 1.52% and 4.59% likelihood of error

propagation and information degradation. In comparison, simulations modelling the

ePIMS design artifact showed a lower risk of introducing accuracy deficiencies with

results of 0.54% and 1.02%. Whereas simulations of Australia’s National EHR system

(MyHR) reported error levels of 1.48% and 4.64%. From a timeliness perspective,

results from the ePIMS simulation reported a 15.22% decrease in the average

timeliness of information products when compared with the results of traditional

healthcare information systems. In comparison, the MyHR showed a more modest

0.63% decrease. Notably, this result must be considered in the context of a healthcare

system characterised by business processes intended to support manual data

management practice. When simulation models were adjusted to take advantage of

design features and functionality specific to each system, results from the eHaaS

experiment showed a 13.93% improvement in the average timeliness of information.

In comparison, the MyHR showed a more modest 3.52% improvement. Therefore, it

is reasonable to conclude that an eHaaS design can affect a positive change in the

quality of clinical information. In this respect, the implications for stakeholders are

promising with eHaaS architecture providing an innovative link between the

individual and their information that is available to multiple healthcare professionals

when needed.

iv eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

Table of Contents

Keywords .................................................................................................................................. i

Abstract .................................................................................................................................... ii

Table of Contents .................................................................................................................... iv

List of Figures ......................................................................................................................... vi

List of Tables .......................................................................................................................... ix

List of Abbreviations .............................................................................................................. xi

List of Published Materials ................................................................................................... xiv

Statement of Original Authorship ...........................................................................................xv

Acknowledgements ............................................................................................................... xvi

Chapter 1: Introduction ...................................................................................... 1

1.1 Background .....................................................................................................................1

1.2 Research Aims and Objectives .......................................................................................3

1.3 Contributions of this thesis .............................................................................................6

1.4 Structure of the Thesis ....................................................................................................7

Chapter 2: Literature Review ........................................................................... 11

2.1 Contextualizing the Problem Domain ..........................................................................11

2.2 The Australian eHealth Program ..................................................................................13

2.3 An International Perspective of eHealth Programs .......................................................16

2.4 Establishing a Design Framework for eHealth-as-a-Service ........................................19

2.5 Shaping an Evaluation Strategy for eHealth-as-a-Service ............................................33

2.6 Summary .......................................................................................................................44

Chapter 3: Research Design .............................................................................. 47

3.1 Introduction ..................................................................................................................47

3.2 Theoretical Orientation .................................................................................................49

3.3 A Design Science Research Framework .......................................................................51

3.4 Research Methodology .................................................................................................53

3.5 Conclusion ....................................................................................................................61

Chapter 4: Problem Definition ......................................................................... 63

4.1 Introduction ..................................................................................................................63

4.2 Background ...................................................................................................................64

4.3 Study Design .................................................................................................................67

4.4 Methodology .................................................................................................................68

4.5 Findings ........................................................................................................................70

4.6 Discussion .....................................................................................................................78

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture v

4.7 Conclusion ....................................................................................................................89

Chapter 5: Artifact Design ................................................................................ 91

5.1 Introduction ..................................................................................................................91

5.2 eHealth-as-a-Service Conceptualized ...........................................................................93

5.3 Designing an Electronic Patient Information Management System ...........................101

5.4 Case Study ..................................................................................................................108

5.5 Discussion ...................................................................................................................127

5.6 Conclusion ..................................................................................................................133

Chapter 6: Evaluation ..................................................................................... 135

6.1 Introduction ................................................................................................................135

6.2 System Evaluation Strategy ........................................................................................137

6.3 Evaluation Design .......................................................................................................139

6.4 Model Verification and Validation .............................................................................140

6.5 Case Study ..................................................................................................................142

6.6 Results ........................................................................................................................160

6.7 Discussion ...................................................................................................................167

6.8 Conclusion ..................................................................................................................178

Chapter 7: Conclusions ................................................................................... 180

7.1 Research Contributions ...............................................................................................181

7.2 Validating the Program of Work ................................................................................183

7.3 Future Directions ........................................................................................................186

7.4 What did we learn? .....................................................................................................187

Bibliography ........................................................................................................... 191

Appendices .............................................................................................................. 215

Appendix A BPMN Models ..................................................................................................215

Appendix B IMAM Matrix ...................................................................................................216

Appendix C IP-Map Models .................................................................................................217

Appendix D Raw Data Elements ..........................................................................................221

Appendix E Input Parameters ...............................................................................................226

Appendix F Example Process Narrative ...............................................................................229

vi eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

List of Figures

Figure 1.1. Thesis structure. ........................................................................................ 8

Figure 2.1. The Patient Journey represented as possible pathways through the

health system adapted from AIHW (2012). ................................................. 22

Figure 2.2. Six architectural strategies proposed by Wilcox et al. (2006)................. 26

Figure 2.3. An empirical approach to defining data quality from Wang and

Strong (1996). .............................................................................................. 36

Figure 2.4. Proper representation of a real world system from Wand and Wang

(1996). .......................................................................................................... 37

Figure 2.5. Design deficiencies (i) Incomplete, (ii) ambiguous (iii) meaningless

from Wand and Wang (1996). ..................................................................... 38

Figure 2.6. Two cases of garbling (i) IS meaningless state. (ii) Meaningful but

incorrect IS state from Wand and Wang (1996). ......................................... 39

Figure 3.1. Overview of the research plan, highlighting a multi-methodological

approach. . .................................................................................................... 48

Figure 3.2. Composite design science research approach used in this thesis. ........... 54

Figure 3.3. Components of an information systems design theory adapted from

Walls, et al. (1992). ...................................................................................... 57

Figure 4.1. Data Flow Diagram symbols. .................................................................. 69

Figure 4.2. Care events examined within a patient's journey. ................................... 70

Figure 4.3. Data flow diagram illustrating the flow of information associated

with diagnostic support processes. ............................................................... 72

Figure 4.4. Data flow diagram illustrating information flows resulting from

activities associated with hospital outpatient processes............................... 74

Figure 4.5. Data flow diagram illustrating the information flows associated

with surgical and inpatient processes. .......................................................... 76

Figure 4.6. Data flow diagram of information flows associated with an

emergency presentation and subsequent Specialist attendance. .................. 77

Figure 5.1. Architecture of cross-organizational workflow view. ............................. 96

Figure 5.2. eHaaS event-driven architecture. ............................................................ 98

Figure 5.3. Implementation model describing eHaaS as the delivery of a set of

sophisticated technologies within a service-based model. ......................... 100

Figure 5.4. A simplified example of the ‘Patient Journey’ establishing the

patient domain model within its own context. Adapted from Millett

and Tune (2015). ........................................................................................ 102

Figure 5.5 . Workflow and Patient Aggregates. ...................................................... 103

Figure 5.6. Event sequence using the ePIMS example. ........................................... 104

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture vii

Figure 5.7. Simplified ePIMS Server example using microservices

architecture. ................................................................................................ 106

Figure 5.8. Example of ePIMS task-based UI flow associated with the clinician

accessing a patient’s workflow to view the results from a radiology

task. ............................................................................................................ 107

Figure 5.9. Clinician consultation and recommendation for a pathology test

with the inclusion of MyHR related activities as shaded objects. ............. 113

Figure 5.10. Patient registration sub-process. .......................................................... 114

Figure 5.11. Pathology episode with the inclusion of MyHR related activities

(shaded objects). ........................................................................................ 115

Figure 5.12. Transmit pathology results process. .................................................... 116

Figure 5.13. ePIMS appointment booking process. ................................................. 118

Figure 5.14. ePatient service sub-process. ............................................................... 118

Figure 5.15. eAppointment Sub-process. ................................................................ 119

Figure 5.16. Example of a clinical consultation demonstrating the benefits of

eHaaS. ........................................................................................................ 121

Figure 5.17. eFlow Sub-process. ............................................................................. 123

Figure 5.18. ePOE Sub-process. .............................................................................. 124

Figure 5.19. ePIMS processes associated with a pathology episode. ...................... 126

Figure 5.20. Receive pathology results (ePIMS) Process........................................ 127

Figure 5.21. Clinical consultation and diagnostic support processes

emphasising the patient’s role in information sharing. .............................. 130

Figure 5.22. A patient information management solution utilising dynamic

workflow metadata composition. ............................................................... 132

Figure 5.23. Materialised view of events describing changes made to

Workflow and Task.................................................................................... 133

Figure 6.1. Process highlighting critical realist perspective of the research

validation phase inspired by Johnston and Smith (2010). ......................... 137

Figure 6.2. IP-Map depicting the CSHIS clinical consultation process and the

manufacture of a pathology report ............................................................. 146

Figure 6.3. IP-Map depicting CSHIS laboratory medicine processes ..................... 147

Figure 6.4. Example of IP-Map entities with input parameters and process

narrative (CSHIS). ..................................................................................... 156

Figure 6.5. CSHIS Accuracy Results for experiments CSHIS_AE1 and

CSHIS_AE2. .............................................................................................. 161

Figure 6.6. Information manufacturing system results for accuracy experiment

AE1 by information product. ..................................................................... 168

Figure 6.7. Information manufacturing systems results for accuracy

experiment AE2 by information product. .................................................. 169

viii eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

Figure 6.8. Information manufacturing systems results for timeliness

experiment TE1 by information product. ................................................... 175

Figure 6.9. Information manufacturing systems results for timeliness

experiment TE2 by information product. ................................................... 177

Figure A.1. eProvider sub-process. .......................................................................... 215

Figure A.2. eCollaborate sub-process. ..................................................................... 215

Figure B.3. Example of IMAM matrix used for validating simulation models

by verifying relationships between data items and system functions. ....... 216

Figure C.4. eHaaS IP-Map - GP consultation event. ............................................... 217

Figure C.5. eHaaS IP-Map - Pathology collection and reporting. ........................... 218

Figure C.6. MyHR IP-Map - Clinical consultation event. ....................................... 219

Figure C.7. MyHR IP-Map - Pathology collection and reporting. .......................... 220

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture ix

List of Tables

Table 2.1 Defining continuity of care. Adapted from Reid, Haggerty, and

McKendry (2002) ......................................................................................... 20

Table 2.2 Comparison of eHealth programs............................................................. 32

Table 2.3 Seven attributes for quality health records provided by RACGP

(2013) ........................................................................................................... 33

Table 2.4 Information quality criteria based on the INFOQUAL framework

developed by Price and Shanks (2005a) ..................................................... 43

Table 4.1 Meta-requirements and design principles derived from ethnographic

study ............................................................................................................. 87

Table 5.1 Meta-requirements derived from ethnographic study conducted in

Chapter 4 ..................................................................................................... 95

Table 6.1 IP-Map constructs and symbols adopted from Shankaranarayanan,

et al. (2000) ................................................................................................ 144

Table 6.2 Data Outputs (Information Products) considered for analysis .............. 145

Table 6.3 Effect of functional processes on the accuracy of raw data item

RDPA1 ....................................................................................................... 152

Table 6.4 CSHIS accuracy results for experiments CSHIS_AE1, CSHIS_AE2

and timeliness results for experiments CSHIS_TE1, CSHIS_TE2 ............. 160

Table 6.5 Attribute values derived from CSHIS timeliness experiment

CSHIS_TE1 ................................................................................................ 162

Table 6.6 MyHR accuracy and timeliness results for experiments MyHR_AE1

and MyHR_AE2 ......................................................................................... 163

Table 6.7 MyHR timeliness results for experiment MyHR_TE1 ............................. 164

Table 6.8 MyHR timeliness results for experiment MyHR_TE2 ............................. 164

Table 6.9 eHaaS accuracy results for experiments eHaaS_AE1, eHaaS_AE2

and timeliness results for experiments eHaaS_TE1. eHaaS_TE2 ............. 165

Table 6.10 eHaaS timeliness results for experiment eHaaS_TE1........................... 166

Table 6.11 eHaaS timeliness results for experiment eHaaS_TE2........................... 167

Table 6.12 Functional processes evaluated for each system actor (information

manufacturing systems) ............................................................................. 171

Table 6.13 Data collection processes and system boundary transitions ................. 171

Table 6.14 Timeliness results for experiment TE1by information product .............. 174

Table 6.15 Summarised Timeliness results for experiment TE2 by data items ........ 176

Table D.1 Raw data elements................................................................................. 221

Table E.2 Estimated error ratios for information transformation functions .......... 226

Table F.3 CSHIS process narrative – Data Source Blocks ..................................... 229

x eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

Table F.4 CSHIS process narrative – Process Blocks ............................................ 231

Table F.5 CSHIS process narrative – Quality Blocks ............................................. 234

Table F.6 CSHIS process narrative – Storage Blocks ............................................ 235

Table F.7 CSHIS process narrative – System Boundaries ...................................... 236

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture xi

List of Abbreviations

ABS Australian Bureau of Statistics

ACHI Australasian College of Health Informatics

AIHW Australian Institute of Health and Welfare

API Application Programming Interface

BI Business Intelligence

BPMN Business Process Model and Notation

CDI Component Data Items

CIS Clinical Information System

CPOE Computerised Physician Order Entry

CQRS Command Query Responsibility Segregation

CSHIS Current State Healthcare Information System

DDD Domain-Driven Design

DFD Data Flow Diagrams

DQ Data Quality

DR Design Research

DS Design Science

DSR Design Science Research

EA Enterprise Architecture

EBM Evidence Based Medicine

ED Emergency Department

eHaaS eHealth-as-a-Service

EHR Electronic Health Record

ePIMS electronic Patient Information Management System

EPU Emergency Planning Unit

xii eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

ES Event Sourcing

ESB Enterprise service Bus

GP General Practitioner

HCP Healthcare Professional

HEA Health Enterprise Architecture

HIE Health Information Exchange

HIMSS Healthcare Information and Management Systems Society

HIS Health Information System

HIT Health Information Technology

HL7 Health Level 7

HTTP Hypertext Transfer Protocol

ICD International Classification of Diseases

ICT Information Communication Technology

ICT Information Communication Technology

IEEE Institute of Electrical and Electronics Engineers

IF2.0 NEHTA’s interoperability framework v2.0

IHI Individual Health Identifier

IMAM Information Manufacturing Analysis Matrices

IMS Information Manufacturing System

IOM Institute of Medicine

IP Information Products

IP-Map Information Product Map

IS Information Systems

ISDR Information Systems Design Research

ISDT Information Systems Design Theories

ISV Information Services View

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture xiii

IT Information Technology

LIS Laboratory Information System

MVC Model–View–Controller

MyHR My Health Record

NEHTA National eHealth Transition Authority

NpfIT NHS National Programme for IT

PCEHR Personally Controlled Electronic Health Record

PHR Personal Health Record

PMS Practice Management System

SCR Shared Summary Care Record

SEHR Shared Electronic Health Record

SOA Service Oriented Architecture

SOC Service Oriented Computing

SQL Structured Query Language

SSOT Single Source of the Truth

TOGAF Open Group Architectural Framework

UDDI Universal Description, Discovery, and Integration

UI User Interface

WHO World Health Organization

xiv eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

List of Published Materials

• Black, Alofi Shane & Sahama, Tony R. (2014) eHealth-as-a-Service

(eHaaS): Empowering stakeholders universally. e-Health Technical

Committee Newsletter, 3(1), pp. 1-3.

• Black, Alofi Shane, Sahama, Tony R., & Gajanayake, Randike (2014)

eHealth-as-a-Service (eHaaS): a data-driven decision making approach in

Australian context. In Studies in Health Technology and Informatics [e-

Health - For Continuity of Care], IOS Press, Istanbul, Turkey, pp. 915-919.

• Black, Alofi Shane & Sahama, Tony (2014) eHealth-as-a-Service (eHaaS):

the industrialisation of health informatics, a practical approach.

In Proceedings of the 16th International Conference on E-health

Networking, Application and Services (Healthcom), IEEE, Natal, Brazil, pp.

555-559.

• Black, Alofi Shane & Sahama, Tony (2016) Chronicling the Patient

Journey: Co-creating value with digital health ecosystems. In The 9th

Australasian Workshop on Health Informatics and Knowledge Management

(HIKM 2016), 2-5 February 2016, Australian National University,

Canberra, ACT.

eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture xv

Statement of Original Authorship

The work contained in this thesis has not been previously submitted to meet

requirements for an award at this or any other higher education institution. To the best

of my knowledge and belief, the thesis contains no material previously published or

written by another person except where due reference is made.

Signature: _________________________

Date: ______12th June 2018___________________

QUT Verified Signature

xvi eHealth-as-a-Service: A Service-Based Design Approach for Large Scale eHealth Architecture

Acknowledgements

First and foremost, I would like to express my sincere gratitude to my

supervisors Dr. Ernest Foo and Dr. Amina Tariq for their wise counsel and for being

the voice of reason when navigating the more trying aspects of my PhD journey. Their

enthusiasm and words of encouragement, particularly during the writing of this thesis,

served as a beacon of light for a weary and at times frustrated research novice. Thanks

also goes to the Science and Engineering faculty who generously provided their

support and I must also acknowledge Dr. Tony Sahama who encouraged me to pursue

research in the area of eHealth.

I am especially in debt to Ken Hall, a friend, colleague and most importantly a

mentor in life. We are changed by the people we meet but few can profoundly shape a

person’s life in the way that Ken has shaped mine. In the years that we have known

each other he has constantly challenged me to boldness in every aspect of my life and

shown me the value of completely believing in yourself.

Finally, and by no means least, heartfelt gratitude must go to my children:

Rebecca, Daniel, Kelly-Lee, Christian and Joshua for allowing me to pursue this

challenge. I must apologise for the fact that I was not always as present as they would

have liked me to be. Their patience, understanding and willingness to support my goals

gave me the freedom to complete this journey of discovery.

Chapter 1: Introduction 1

Chapter 1: Introduction

Establishing a precise understanding of a patient’s condition as they progress

along different care pathways requires an iterative process of gathering complete,

accurate and timely information across diverse settings. This places emphasis on

ubiquitous access to patient information and effective collaboration as critical

antecedents for coordinating the delivery of care. In this respect, a well-designed health

information technology (HIT) system can contribute in a positive way by providing

access to high quality information and enhancing communication among healthcare

professionals and patients (Balogh, Miller, & Ball, 2016; El-Kareh, Hasan, & Schiff,

2013).

Drawing a connection to Australia’s efforts in this problem domain, the Federal

Government has made a significant investment in large scale eHealth systems. A

commitment in 2010 to spend $466.7 million dollars on implementing a national EHR

system heralded a shift to a more effective and safer patient centric HIT environment

(Pettigrew, 2010). However, operationalisation of the Personally Controlled Electronic

Health Record (PCEHR) in 2012, which was later rebranded as the My Health Record

(MyHR), has resulted in poor adoption rates and criticism from healthcare providers

largely sceptical of the system’s utility and safety (AMA, 2013; Deloitte, 2014; Reddy,

2017). This has placed the broader utilitarian opportunities available with Australia’s

national EHR system at risk. Considering this, the thesis seeks to critically examine

the role played by architectural design choices, implementation approach and related

antecedent conditions that influence the development of large scale eHealth systems.

The aim is to develop an architecture for delivering eHealth technologies which

realizes the benefits of well-designed health HIT systems and meets the individual

needs of clinicians and patients.

1.1 BACKGROUND

Dobrev et al. (2008) observe increasing complexity of healthcare processes, a

consumer approach to healthcare, and service productivity improvements is providing

impetus for significant government investment in eHealth programs globally.

However, in some respects eHealth has fallen short of its potential to transform

2 Chapter 1: Introduction

healthcare (Black et al., 2011; Fontaine, Ross, Zink, & Schilling, 2010; Vitacca,

Mazzù, & Scalvini, 2009). Although the goal of eHealth initiatives is to optimize the

delivery of care, the complexities and cost of embedding technology-driven systems

for sharing patient information has emerged as a significant obstacle to adoption. With

the introduction of the Australian MyHR system, the Australian Digital Health

Agency, formally known as National eHealth Transition Authority (NEHTA), has

implemented an open standards infrastructure that aspire to thematic priorities in

common with many international eHealth programs. That notwithstanding, as the

centerpiece of the country’s national EHR strategy, the implementation of the MyHR

has resulted in poor adoption rates with criticism from stakeholder groups expressing

concerns about functionality, transparency and accountability (e.g., privacy,

confidentiality and information security) (McDonald & James, 2013). Indeed,

widespread adoption will continue to be tentative until current systems and practices

are perceived to add more value to clinical care processes.

Did Australia get it wrong or are eHealth technologies difficult to implement at

scale? A review of the specialist literature identifies complex socio-technical factors

with limited empirical evidence of long term improvements at the national level

(Black, et al., 2011). Yet the World Health Organization (WHO) and the European

Commission have become strong advocates for the diffusion of eHealth technologies,

particularly in low and middle-income countries. Indeed, almost half of the member

states of the United Nations are engaged in eHealth projects of some type with

international initiatives making incremental progress such as Denmark, New Zealand

and Singapore. At the same time, there are countries who have met with considerable

challenges for example England, the United States (US) and Australia. On closer

examination, it would seem that the development of nation-scale eHealth systems

typically mirrors the structure and processes of the healthcare systems they are

intended to support. For this reason, it is important to recognize the folly of simply

automating extant processes and services and migrating them to the web (Hagland,

2001). The effectiveness of an eHealth solution must be predicated on the alignment

of information technology (IT) with organizational objectives, specifically clinical and

patient outcomes. In this respect, a key objective for healthcare is improving the

coordination and continuity of care which establishes care pathways (the Patient

Journey) as a potential solution space. However, creating large scale eHealth systems


which effectively coordinate care across organizational and disciplinary boundaries is

complex. The challenge for the system designer is accommodating a diversity in

clinical disciplines and care provider types concomitant with different care pathways.

In response, this thesis asserts that, as a universal phenomenon in healthcare, the

Patient Journey must be used as a central organizing mechanism for integrating

relevant electronic patient information services in the delivery of multidisciplinary

care.

From this perspective, the promise of electronic health records and eHealth

technologies in the form of high quality informational services attracts special

attention. As a catalyst for coordinated care and clinical collaboration, these services

have the capacity to improve information quality through unambiguous information

sharing, data management and information representation. Whilst this thesis postulates

that this approach must be addressed at the architectural level, an examination of the

forces shaping the development of national eHealth systems reveals several different

architecture-based strategies. Therefore, an opportunity to examine whether there is a

relationship between eHealth architecture and patient information quality emerges. As

an overarching goal, research focuses on the conceptualization of eHealth architecture

which deliver measurable information quality improvements within the highly

complex and emergent context of Patient Journeys.

1.2 RESEARCH AIMS AND OBJECTIVES

This thesis aims to create and evaluate a purposeful and innovative design

artifact as a case study for applying a set of design principles, architectural patterns

and service-based applications to typical clinical scenarios. It is noteworthy however,

that the scope of this thesis does not consider mediating factors such as individual and

institutional values and the capacity to change or adopt new technologies. Similarly,

due to the scale and maturity level of national-scale eHealth systems, a multi-method

research framework is required to adequately address the full dimensionality of a

research project which is applied in nature. Design science research plays a key role

in the structure of this thesis by establishing a prescriptive set of guidelines for the

design process. This has resulted in three research directions aligned with Hevner’s

(2007) three cycles of activities, relevance cycle, design cycle and rigor cycles.

Accordingly, the following research questions and objectives are organised to reflect


these cycles of activity. Subsequent chapters provide the narrative for each of the

activities.

1.2.1 Relevance cycle

Effective communication and information transfer across care settings is

perceived by patients as an important dimension of care coordination (Waibel, Henao,

Aller, Vargas, & Vázquez, 2011). Therefore, understanding information flows as

patients traverse different care pathways plays a prominent role in designing

technology systems for optimising the coordination of care. This prompts the

following research questions:

• RQ1: What are the quality issues associated with current patient information

practices in Australian primary healthcare settings?

• RQ2: How might patient information flows be optimised to encourage

access to high quality patient information as well as better support care

coordination in primary healthcare settings?

• RQ3: What meta-requirements and design principles are required for

developing eHealth systems which positively influence ubiquitous access to

high quality patient information?

1.2.2 Design cycle

Activities associated with the design cycle are based on the notion that there is

limited systematic research examining the development of large scale technical

solutions for sharing electronic patient information. This presents an opportunity to

design and demonstrate eHealth architectural forms and functions described in this

thesis as eHealth-as-a-Service (eHaaS) in order to identify testable propositions. With

a focus on the conceptualization of eHaaS, the following research question is

examined:

• RQ4: What is a practical technological response for providing ubiquitous

access to high quality information services as a patient navigates different

care pathways?

1.2.3 Rigor cycle

According to Byrd and Byrd (2012), effective methods to validate the link

between infrastructure, information quality and healthcare quality is poorly


understood. To address this, an evaluative framework is required which identifies and

prioritises those key dimensions of information quality (IQ) that support the goals of

safe healthcare. The development of this framework requires an explanatory research

approach in order to draw conclusions about how well the change produced by the

eHealth design artifact addresses the problem it is intended to solve. Therefore, the

overall aim of this cycle is to collect evidence of changes, caused by the eHaaS

conceptual model, to assess if the predictions of a testable proposition are satisfied.

The following research questions frame the activities associated with explaining

observable relationships between the artifact and the problem domain:

• RQ5: In the context of this research, is there an effective evaluation

framework for examining the role of information quality as a mediator

between information technology architecture and healthcare quality?

• RQ 6: What is the predicted effect of change produced by the solution design

and is there an observable impact by the artifact on the problem it is intended

to address?

1.2.4 Research Objectives

In alignment with Hevner’s (2007) three cycles of activities, six research

objectives may be synthesized from the proposed research questions:

Relevance Cycle Objectives

1. Provide a perspective of Australian eHealth systems and its implications for

information quality and clinical information flows as a means to support

continuity of care.

2. Synthesize meta-requirements for an eHealth solution that will optimise

information quality. Derive normative design principles specifying the

characteristics that satisfy these meta-requirements.

Design Cycle Objectives

3. Present a practical example of how a set of architectural patterns and

applications may be implemented to solve a real-world problem relevant to

eHealth-as-a-Service.


4. Demonstrate a novel method for the efficient assembly of patient clinical

information as personalized workflows utilizing eHaaS design and

architectural concepts.

Rigor Cycle Objectives

5. Develop an evaluation strategy to determine whether there is any observable

impact, with an instantiation of the eHaaS conceptual model, on the quality

of information associated with dynamic patient care pathways.

6. Validate an instantiation of the eHaaS conceptual model and provide

empirical evidence that the proposed solution will have a positive effect on

information quality.

1.3 CONTRIBUTIONS OF THIS THESIS

As a problem-solving process, the principal contribution of this thesis is a case

study for the development and evaluation of the eHaaS conceptual model. In this

regard, the thesis is an example of an applied, multi-methodological approach. It is

applied with respect to: (i) the study of an important phenomena in the area of

information systems and healthcare and (ii) the creation of an artifact which attempts

to solve an identified real-world problem. It is multi-methodological with respect to

theory building, conceptual frameworks, systems development and evaluation. This

required data collection and analysis of qualitative data from an ethnographic study

and quantitative data from simulation models grounded in a critical realist theoretical

orientation.

Key learnings emerged as practical contributions made by this thesis. These

include advances in knowledge areas corresponding with the three DSR activity

cycles:

Relevance cycle

• Provided an in-depth analysis of how health information is created and

propagated within the Australian healthcare system

• Consolidates understanding about the effect of extant information

management practices on information quality specifically accuracy,

timeliness and completeness.


• Identified a potential causal relationship between eHealth architecture and


• Derived theoretically grounded meta-requirements and design principles for

creating eHealth solutions that will have a positive influence on information

quality.

Develop cycle

• Development of an eHealth-as-a-Service conceptual model encapsulating a

set of design principles, architectural patterns, service-based applications

and implementation strategy.

• A practical example of how a set of architectural patterns and applications

deployed using eHaaS architecture has the potential to optimise information

flows in clinical settings.

• Demonstration of differences between eHaaS and Australia’s national EHR

system in the context of a clinical consultation and pathology test analysis

scenario.

Rigor cycle

• Development of a novel evaluation strategy for service-based information

management systems.

• Empirical evidence was obtained proving that the eHaaS conceptual model

will deliver measurable information quality improvements.

1.4 STRUCTURE OF THE THESIS

The thesis structure adheres to a composite framework based on a prescriptive

DSR approach. In view of this, the creation and evaluation of eHaaS is organized as a

sequential problem-solving process. As illustrated in Figure 1.1, the Relevance Cycle,

which is distinguished by the problem identification and define objectives steps,

defines the problem domain and establishes the research effort as a problem-centered

approach. Chapter 2 provides a macro view of the problem domain with a review of

the specialist literature. In this respect, the operationalization of large scale eHealth

systems and the role played by the technical architecture, implementation approach,

healthcare models and information quality are investigated. Chapter 3 establishes the

theoretical orientation and examines the use of design science as a scientifically


rigorous framework for creating eHealth solutions. Chapter 4 offers a micro view of

the problem domain. An ethnographic case study is presented documenting the effects

of a national eHealth system on health information flows as a patient traverses a system

of care pathways. The synthesis of solution meta-requirements and design principles

from the findings of the case study are grounded in semiotic theory in order to satisfy

research objectives one and two.

Figure 1.1. Thesis structure.

The Design Cycle encompasses conceptualization of the eHaaS design artifact.

In this regard, Chapter 5 satisfies research objectives three and four by providing a

meta-description of the eHaaS conceptual model. Representing a set of design

principles, architectural patterns and implementation strategies, it is demonstrated how

the model can be implemented in primary healthcare settings. As an instantiation of

the eHaaS conceptual model, an electronic patient information management system

(ePIMS) is presented as a novel solution for assembling disparate application services

as personalized patient workflows. Key differences are identified between ePIMS and

an existing eHealth system suggesting that the potential for process oriented solutions

to improve information quality is strong.

The Rigor Cycle attempts to answer the questions “does the artifact work?” and

“is it useful?”. To achieve this and satisfy research objectives five and six, Chapter 6


adopts an ex ante perspective to examine how well the change produced by the eHaaS

design artifact addresses a real-world problem. This is achieved by evaluating the

behaviours of three system actors and their effect on the quality of information flows

within a typical clinical scenario. Chapter 7 brings the thesis to a conclusion with a

summary of key themes and a discussion about the limitations and future directions of

this research.

Chapter 2: Literature Review 11

Chapter 2: Literature Review

The aim of this chapter is to consolidate understanding of constructs and theory

related to the development of large scale eHealth systems, their application in national

and international settings and the challenges associated with their implementation.

Gaps in knowledge will be identified and insights provided about how eHealth

architectural forms and functions can contribute to the coordination of care and deliver

information quality improvements.

It is acknowledged that the topic of eHealth and the multifaceted nature of

information quality cannot be adequately covered in one chapter. In light of this, the

literature review will establish an abridged but focused narrative that will firstly,

contextualize the problem area by providing a definition of eHealth with an account of

the history, challenges and realizable benefits within a broader healthcare context.

Secondly, examine Australia’s experience with implementing a national Electronic

Health Record (EHR) providing insights into the challenges of delivering eHealth

projects at scale. Thirdly, compare and contrast three international eHealth programs

to identify key concepts in the design and implementation of nation scale eHealth

systems. Fourthly, discuss these concepts in the context of solution space,

implementation approach, technical architecture and architecture patterns in order to

establish the thematic scaffolding for developing eHealth-as-a-Service architecture.

Finally, the literature review will conclude with an examination of information quality.

This will establish the theoretical foundation for developing an evaluation strategy in

which to validate the utility of an eHaaS design artifact.

2.1 CONTEXTUALIZING THE PROBLEM DOMAIN

Electronic health (eHealth) used interchangeably with Health Information

Technology (HIT), Telemedicine, Telehealth and more recently, Mobile Health

(mHealth), Health 2.0 and Medicine 2.0 locates its origins in the field of

telemedicine(Bashshur, Grigsby, Krupinski, & Shannon, 2011; Pagliari et al., 2005;

van Gemert-Pijnen et al., 2011). An area of healthcare where the convergence of

medicine and analogue telephony enabled medical practitioners to coordinate care

remotely at the turn of the twentieth century. The eHealth term emerged as part of the

12 Chapter 2: Literature Review

“e-movement” that included eCommerce, eGovenment, eBusiness and other domains

in response to the success of electronic data systems and the proliferation of the

Internet (Bashshur, et al., 2011). To provide an all-encompassing, normative definition

of eHealth, the World Health Organization (WHO) adopted Resolution WHA58.28 at

the Fifty-eighth World Health Assembly which states:

“eHealth is the cost-effective and secure use of information and

communications technologies in support of health and health-related fields,

including health-care services, health surveillance, health literature, and

health”.

Whereas Eysenbach (2001) suggested a definition that characterised both the

broad and dynamic nature of the eHealth paradigm by highlighting the complex

relationship that exists between people, technology and medicine:

“eHealth is an emerging field in the intersection of medical informatics, public

health and business, referring to health services and information delivered or

enhanced through the Internet and related technologies. In a broader sense, the

term characterizes not only a technical development, but also a state-of-mind,

a way of thinking, an attitude, and a commitment for networked, global

thinking, to improve healthcare locally, regionally, and worldwide by using

information and communication technology” (Para 3).

However, van Gemert-Pijnen, et al. (2011) observed in their analysis of 16

eHealth frameworks, a propensity for researchers to provide their own definition of

eHealth that is dependent on, and related to the technology their frameworks

respectively focus on. Thereby confirming the observation by Meier, Fitzgerald, and

Smith (2013) that the definition of eHealth, like many technology based neologisms is

evolving and “comes most sharply into focus when considering specific use cases” (p.

360).

Because of the many definitions, the term eHealth often serves as umbrella

nomenclature for allied information and communication technologies (ICT) that

include electronic health records (EHR), personal health records (PHR), computerised

provider order entry (CPOE), picture archiving and communication systems (PACS),

ePrescribing and computerised decision support systems (DSS). As a consequence,

there are numerous eHealth publications that identify clinical and administrative

benefits available with the adoption of eHealth technologies within diverse healthcare


settings (Bell & Thornton, 2011; Buntin, Burke, Hoaglin, & Blumenthal, 2011;

Chaudhry et al., 2006; Shekelle, Morton, & Keeler, 2006). On the other hand, a highly

cited systematic review of the impact of eHealth on the quality and safety of health

care, led by academic Ashly D. Black, concluded that a lack of empirical evidence of

long term improvements and the divergent methods used for determining the

effectiveness of these technologies warrant further research (Black, et al., 2011).

Nonetheless, the WHO and the European Commission have become strong advocates

for realising the potential of eHealth to improve patient outcomes and deliver

significant healthcare efficiencies particularly for low and middle-income countries

(Blaya, Fraser, & Holt, 2010; Piette et al., 2012).

Remarkably, more than a decade has passed since resolution WHA58.28

endorsing eHealth was adopted by the WHO and its member states (Al-Shorbaji &

Geissbuhler, 2012) . In that time, almost half of the 192 independent nation states

enrolled as official members of the United Nations have engaged in an eHealth project

with varying levels of success. Accordingly, investment in national programs is

increasing, for example the United States have committed approximately US$38

billion, England 12.8 billion pounds, and Australia over A$2 billion, (Black, et al.,

2011; NEHIPC, 2008; Reddy, 2017). From this perspective, Black, et al. (2011)

discuss how huge investments in large scale eHealth related information and

communication technologies (ICT) are largely justified. They observe that this

expenditure is considered acceptable due to the belief that eHealth technologies are

more cost-effective and more efficient than other means for improving healthcare

quality. Nevertheless, Eason et al. (2012) observed that, notwithstanding the huge

investment, “very few national-scale systems exist” (p. 18). With such widespread

investment in eHealth technologies, it is reasonable to question the validity of

engaging in large scale initiatives where there appears to be little return. In this respect,

an examination of Australia’s experience provides useful insights into the challenge of

delivering national-scale eHealth systems.

2.2 THE AUSTRALIAN EHEALTH PROGRAM

Australia’s healthcare system is a complex mix of funding and governance with

responsibilities split among the federal, state and territory governments. As a result,

the diffusion of healthcare technologies has been patchy and fragmented with different

IT capability and maturity levels observed across the Australian healthcare system


(Bond, Hacking, Milosevic, & Zander, 2013). Early eHealth efforts under the auspices

of the HealthConnect initiative were localised and encumbered with issues related to

governance, privacy concerns and a lack of standards or a national patient identifier

(Vest, 2012). Therefore, it was perceived by policy makers at all levels of government

that the introduction of national eHealth infrastructure and a personally controlled

electronic health record (PCEHR) would deliver a consistent approach for the

implementation of interoperable information systems (Foley, 2009).

In order to accommodate heterogeneous solutions and various transition

programs, a middle-out implementation approach was adopted. We define a middle-

out approach as an implementation strategy which combines government direction

with increased local autonomy This permitted the development of different

architectures within an interoperability framework supported by national and

international standards (Mudaly, Moodley, Pillay, & Seebregts, 2013). The National

E-Health Transition Authority (NEHTA) was established to coordinate a national

program of work overseeing the development of the national eHealth architecture,

national standards for data and its exchange and security frameworks (Jolly, 2011;

Morrison, Robertson, Cresswell, Crowe, & Sheikh, 2011; NEHIPC, 2008). NEHTA

also introduced the unique healthcare identifier in association with Medicare,

Australia’s national healthcare insurance program, and was the principal driver for

operationalizing the PCEHR (Vest, 2012). Using a centralised architecture, the

PCEHR is an opt-in repository for aggregating summary health information (Deloitte,

2011). Muhammad, Teoh, and Wickramasinghe (2012) describe the PCEHR as a

hybrid system that attempts to integrate the Personal Health Record (PHR) with a

clinical Electronic Health Record (EHR) system. A key characteristic of the PCEHR

is Internet based access to summary patient records which is shared by healthcare

professionals (HCPs) and patients however, control of the record remains intrinsically

with the patient.

2.2.1 Operationalizing a National EHR System

Whilst some of the work required for the PCEHR was not completed on time,

the development and implementation roadmap presented by NEHTA clearly

articulated project milestones and objectives that were largely achieved over the life

of the project. However, several red flags signalled the challenges that would be

encountered by the beleaguered system in terms of design choices, implementation


approach and policy decisions. Firstly, adopting a centralised repository for

aggregating health information utilising standardised structured data required

modifications to existing clinical information systems in order to transfer information

(Kruys, 2013). Conceivably, this would require a significant investment in time and

resources to develop, test, implement and support the modifications at an additional

cost that would have to be absorbed by the vendor or passed onto the consumer.

Secondly, the PCEHR was implemented as an opt-in model where the Australian

public were not required to use the system. Consequently, there was no guarantee that

the system would gain broad adoption justifying the changes made by vendors to their

respective systems (Bushell-Embling, 2013). Thirdly, control of clinical information

by the individual meant that HCPs could not be confident they were seeing an

individual’s complete medical history which could adversely affect their decision

making. As a result, there was much editorialising in the Australian media regarding

the lack of inclusive stakeholder governance, useful health information content,

resistance by healthcare practitioners and unrealised consumer expectations (Glance,

2013; Lehnbom, Brien, & McLachlan, 2014; LeMay, 2013; McDonald & James,

2013).

In response to stakeholder criticism, the Australian Coalition Government

commissioned a review of the PCEHR in 2013 (LeMay, 2014). A panel that drew from

the health sector and information technology approached organizations and individuals

for input and feedback and returned with 38 recommendations addressing key

concerns (Royle, Hambleton, & Walduck, 2013). More importantly, the review

established a critical checkpoint for the next phase of Australia’s National eHealth

strategy.

2.2.2 Australia’s Progress

Since the release of the report adoption by Public Hospitals in all jurisdictions

have progressed with many hospitals uploading discharge summaries and allowing

clinicians to view the PCEHR (Hambleton, 2014). Moreover, NEHTA’s programme

of work for 2015 was to see meaningful use of the PCEHR through seamless delivery

aligned with health practitioner’s work processes. However, Dearne (2014) observed

that after “two years and more than $1 billion in costs, only 26,332 shared health

summaries have been uploaded by doctors to the troubled Personally Controlled e-

Health Record system” (p. 2). Whilst NEHTA and the Department of Health


announced 1.7 million Australians had registered for the PCEHR, Dearne (2014)

observed that less than one-third of registered users had bothered to look at their

PCEHR even once. A more telling statistic was the number of clinically relevant

documents uploaded by HCPs. Dearne (2014, p. 2) reported that “there are only 71,132

potentially useful medical records available for just a tiny fraction of those 1.7 million

people who signed up in the hope of better healthcare through information-sharing”.

In April 2016, an industry journal reported that only 300 general practice clinics

were using the service regularly however, the Department of Health stated that, of the

8625 general practices in Australia, 5312 connected to the My Health Record system

(Cowan, 2016). As of February 2017, recommendations made by the 2013 review

continued to be implemented, the most visible being a name change accompanied by

efforts to improve the usability of the system. The PCEHR is now referred to as My

Health Record (MyHR) and uploads of shared health summaries is increasing due to

changes in clinician incentive payments. Nevertheless, there remains a sizeable gap

between the total number of uploads versus the total number of clinical attendances.

The principle goal of Australia’s national eHealth infrastructure is to deliver a

nationally consistent approach for the implementation of interoperable information

systems. However, resistance by practitioners and unrealised consumer expectations

bring into question the effectiveness of the current system. Widespread adoption by

HCPs may continue to be tentative until current systems and practices are perceived

to add more value to clinical care processes. Therefore, solutions that meet the

requirements of all stakeholders in the Australian context warrants further research.

2.3 AN INTERNATIONAL PERSPECTIVE OF EHEALTH PROGRAMS

Given the debate about the efficacy of eHealth and the challenges emerging from

the Australian experience, it is reasonable to ask the question: how are eHealth

technologies being developed and implemented in other sovereignties? Many

countries are currently engaged in creating information-sharing eHealth architectures

with several programs achieving some degree of success. For example, New Zealand,

Denmark and Singapore are making incremental progress at much lower cost than

other larger countries (Bowden, 2011). However, there are international eHealth

projects that have encountered challenges for example England and the United States.


2.3.1 England

The English National Health Service (NHS) is one of the few nation-scale,

single-payer health systems with centralised management and governance structures

which has encouraged a top-down approach to system architecture, standards

compliance and procurement. England’s eHealth project, the National Programme for

Health IT (NPfIT) also known as ‘Connecting for Health’ was discontinued in 2011

due to issues with missed deadlines and poor progress (Bowden & Coiera, 2013). The

technical architecture used a centralised model based on infrastructure known as the

“NHS Spine” and a nationally shared summary care record (SCR) located centrally to

enable all clinicians to add or read information. Drawing from a clinician-held

electronic record, an SCR contains information about current medications, details of

allergies and a summary of a patient’s health data (Jolly, 2011). However, adopting a

top down approach in the specification, governance, management and implementation

of a centralised system resulted in problems with the system not meeting the local

needs of clinicians (Mudaly, et al., 2013). Similarly, concerns about completeness and

accuracy of clinical information with fears about personal privacy erosion led to

distrust in the system (Bowden & Coiera, 2013). As a result, England have since

commenced moving towards decentralised architecture. On the other hand, Scotland

and Wales are making progress in developing sustainable systems for sharing clinical

information having learned from the lessons of the NpfIT (Bowden & Coiera, 2013).

It is noteworthy that Singapore has also adopted a top-down approach with a

centralised architecture but unlike England, is progressing to plan. In Singapore, the

national eHealth record (NEHR) was created in just 18 months following changes to

legislation permitting the exchange of health information between institutions

(Accenture, 2012).

2.3.2 The United States

The healthcare system in the United States is highly fragmented and

decentralized with a wide range of public and private providers. This has encouraged

a bottom up approach based on regional HIEs that do not create a single health record.

The information system landscape is decentralised comprising fragmented systems

where the architecture differs between systems and networks. Economic and

productivity benefits are derived from utilising existing systems designed to meet local

needs (Coiera, 2009). The architecture uses a federated model which connects systems


at a regional level permitting a virtual view of patient records. The expectation is that

information will eventually aggregate at the national level (Mudaly, et al., 2013). It

has been reported that there are concerns with the current HIE strategy centered around

the low number of HIEs with sustainable business models (Bowden & Coiera, 2013).

Likewise, it is unclear how much information can be made available to participating

clinicians in a patient’s journey due to incompatible data models leading to data quality

problems and interoperability issues (Coiera, 2009; Eason, Dent, Waterson, Tutt,

Hurd, et al., 2012).

2.3.3 New Zealand

As an example of an eHealth program that has made some progress, New

Zealand has a ‘hybrid’ publicly/privately funded health system with responsibilities

for service delivery located at the regional level with central government providing

oversight and funding. New Zealand’s health information technology (HIT)

environment has a high level of complexity and fragmentation which has led to their

strong capability for linking disparate systems on a point-to-point basis as well as with

national systems and regional solutions. HIT infrastructure and process automation has

largely been developed by the private sector, working closely with regional and central

government agencies (Deloitte, 2015). Like Australia, New Zealand has adopted a

middle out approach by following a set of standards to enable the linking of their

disparate systems to create ‘Virtual’ EHRs. There have been several attempts to build

technical architecture using a federated model similar to the US with key data

replicated to regional repositories within a hub and spoke configuration (Bowden &

Coiera, 2013). Whilst the use of point-to-point connectivity has limited information

accessibility, it is New Zealand’s focus on process automation and the use of B2B

concepts and provider broker services in primary healthcare settings that holds interest

as a potential point of difference. Similarly, New Zealand’s largest ever data science

research initiative, the Precision Driven Health project, positions New Zealand as the

vanguard of precision medicine and personalized healthcare (McDonald 2016).

As illustrated in these very different examples, creating national-scale eHealth

systems is difficult suggesting that a paradigm shift is required. In support of this, van

Gemert-Pijnen, et al. (2011) state: “approaches that are being used to develop eHealth

technologies are not productive enough to create technologies that are meaningful,

manageable, and sustainable” (p. 2). Providing a different perspective, Mandl and


Kohane (2012) argue that the opportunity for Healthcare to benefit from improved,

agile, safe and more cost-effective technology tools is often frustrated by EHR vendors

who perpetuate the view that Health IT is “qualitatively different” from other IT

products. From their perspective, many eHealth components can be generic requiring

just a handful of loosely coupled information technologies that are specific to

healthcare. Their recommendation for the introduction of open technologies that

support biomedical processes and an IT foundation based on homogenized data types,

care workflows and encoded knowledge, offers a reasonable alternative when

considering the design of large scale eHealth architecture (Mandl & Kohane, 2012).

Although this view perhaps oversimplifies the operational complexity of healthcare

technology systems and clinical workflows, it does emphasize van Gemert-Pijnen and

colleagues’ call to action for a paradigm shift in design and development of eHealth

systems.

2.4 ESTABLISHING A DESIGN FRAMEWORK FOR EHEALTH-AS-A-

SERVICE

In response to this call to action, eHaaS is intended to provide an architectural

pattern which permits access to information located in one or more existing

applications or data repositories within the healthcare enterprise via a system that

combines internal and external infrastructure components (Chang, Abu-Amara, &

Sanford, 2010). To achieve this, several themes were synthesized from the Australian

and international eHealth implementation experiences in the form of solution space,

implementation approach, technical architecture, applications/integration architecture

and evaluation framework. Through synthesis, the following sections hypothesize

structural and behavioural concepts to incorporate these themes into a framework for

conceptualizing an abstract eHaaS model.

2.4.1 Defining the eHaaS Solution Space

The Australian Government’s focus on establishing an interoperable eHealth

environment is centered on the notion that EHR interoperability facilitates efficient

workflows, better information quality and enables the transfer of data between systems

and stakeholders (Begoyan, 2007; Bhartiya & Mehrotra, 2013; Manos, 2016; Rusu et

al., 2011). However, while the use of EHRs is increasing, the remit of the MyHR is

focused on aggregating patient summary data rather than longitudinal patient

information (NEHTA, 2012). Design choices have centered on data collection with


access controlled by the patient which seems to contradict the principles espoused by

the Institute of Medicine (IOM). Specifically, timely access to accurate and complete

patient information that is relevant at the point of care (Kohn, Corrigan, & Donaldson,

2000). Similarly, the WHO state “the key to effective patient information systems is

to retain the link between the individual and the data collected over time and to make

those data available to multiple health care providers when needed” (WHO, 2012, p.

9). Therefore, developing the solution space requires recognition that electronic health

systems should be designed to encourage continuity of high quality information

particularly in primary healthcare settings where information continuity is often

fragmented.

Care Coordination and Information Continuity

According to the Australian Institute of Health and Welfare (AIHW), a key

objective for primary healthcare is improved coordination of care particularly for the

management of an increasing incidence of chronic diseases (AIHW, 2014). This is

emphasised where a patient’s progression through a healthcare system involves

multiple healthcare professionals (Harris et al., 2011). Thus, optimization of

information flows is ensuring that the link between patients and accurate and complete

information remains intact across different care pathways (WHO & ITU, 2012). Yet,

with respect to the broad adoption of EHRs, little is being done to improve the

coordination of care (Bates, 2015).

As a key dimension of care coordination, effective continuity of care is

associated with improved patient outcomes, reduced health service use and improved

patient satisfaction (AIHW, 2014; Banfield et al., 2013). Characterised by access to

high quality patient information, consistent care management and strong relationships

between patients and HCPs, continuity of care plays a significant role in primary

healthcare (AIHW, 2014). However, it is important to note that continuity of care may

be defined differently by individual practitioners. Table 2.1 summarises three widely

accepted categories: relational, management and informational.

Table 2.1

Defining continuity of care. Adapted from Reid, Haggerty, and McKendry (2002)


Type Description

Informational continuity Information about prior events is used to provide care

that is appropriate to the patient's current circumstance.

Relational continuity Acknowledges the patient as a person and recognizes

the ongoing relationship between patients and

providers over time and discontinuous events

Management continuity Ensures that care received from different providers is

connected in a coherent way. Usually focused on

specific, often chronic, health problems.

Relational or interpersonal continuity (RC) refers to the ongoing relationship

between HCPs and the patient which may extend across care events and over time.

Thus, RC embodies longevity and the quality of the relationship and is influenced by

the medical knowledge, confidence and attentiveness of the HCP (Health Quality

Ontario, 2013).

Management continuity (MC) refers to the delivery of coherent and timely care

by multiple HCPs adhering to standards and protocols. Key characteristics are:

flexibility to adapt to care needs, accessibility in the context of appointments and

medical tests and care coordinated by HCPs to ensure smooth transition of care.

However, it is informational continuity (IC) which presents a critical class of

problem requiring a specific technological response. IC consists of two dimensions,

(i) information transfer which is concerned with the exchange of information between

multiple HCPs in cross-functional settings and (ii) accumulated knowledge which

refers to the HCPs knowledge of medical and non-medical information e.g. patient

preferences and social contexts. In this respect, seamless sharing of multi-disciplinary

information is fundamental for achieving continuity of care (Katehakis,

Kostomanolakis, Tsiknakis, & Orphanoudakis, 2000). A meta-synthesis of qualitative

studies investigating the patient’s perspective suggests that effective communication

and information transfer across care settings as well as access to holistic patient

information were perceived as necessary to achieve IC (Waibel, et al., 2011).

Therefore, understanding the flow of information and the implications for information

quality within healthcare settings emerges as a critical aspect of optimising IC which


establishes the Patient Journey as a potential solution space for applying eHealth-as-

a-Service architecture.

Figure 2.1. The Patient Journey represented as possible pathways through the health system adapted

from AIHW (2012).

The challenge for the system designer when developing solutions for the Patient

Journey is accommodating a diversity in disciplines and care provider types

concomitant with the different care pathways and their dynamic nature (Eason &

Waterson, 2014). Figure 2.1 was adapted from AIHW (2012a) by removing patient

self-management elements. Whilst it is not unusual for people to seek information

online, or by talking with friends and family when starting to manage a health issue

themselves, the aim is to show that the Patient Journey represents many possible

pathways through the Australian healthcare system. This emphasizes the

heterogeneous nature of healthcare provider engagement. More importantly, as a


universal phenomenon in healthcare, a patient’s journey serves as an effective means

of integrating healthcare delivery. This is achieved by orchestrating relevant electronic

patient information services to support multidisciplinary providers working across

organizational boundaries (Eason, Dent, Waterson, Tutt, Hurd, et al., 2012). Similarly,

the use of patient journey modelling in healthcare improvement projects shows

promise. The goal is to optimize information collection, streamline activities, improve

communication and provide unambiguous information to the patient (Curry,

Fitzgerald, Prodan, Dadich, & Sloan, 2014). Thus, the goal for eHaaS design activities

must focus on the Patient Journey as a central organizing mechanism for orchestrating

eHealth technologies and services.

2.4.2 Defining a User Centered Approach for eHealth-as-a-Service

Identifying an effective implementation strategy for eHaaS requires an

understanding of strategies currently used with national programs. Drawing on the

typology proposed by Coiera (2009), a description of four national eHealth programs

in the previous section suggests that either a ‘top down’, ‘middle out’ or ‘bottom up’

perspective is used. Top down refers to an approach that attends to management or

national imperatives potentially at the risk of a mismatch between management

requirements and operational usefulness. This approach mandates a standard

architecture within a centralized governance framework i.e. standard compliance and

procurement policies. As a result, local systems that do not comply with national

standards are replaced with compliant systems which may not suit local needs. This in

turn encourages a top down architecture which is relatively inflexible and over time

may become increasingly out of sync with changing local requirements (Coiera, 2009;

Eason, Dent, Waterson, Tutt, & Thornett, 2012).

A middle out approach is founded on the notion that stakeholders in large

eHealth systems have individual starting points, resources and goals. It is perhaps best

characterized by the most beneficial attributes of a bottom up approach adopted within

an agreed policy/strategy framework with centralized leadership and resources. Thus,

the role of Government is not to mandate standards compliance but fund the

development process. In this way, healthcare professionals are supported and

incentivized to adopt technically and functionally compliant systems (Coiera, 2009).

In contrast, bottom up refers to an approach that satisfies local requirements at

the expense of information accessibility. A bottom up approach relies on local


innovation where ‘home grown’ strategies and systems are designed to address the

needs of independent provider organizations or local health networks. In this way, new

technologies or system designs are adopted locally provided that they can connect to

some form of centralized process. However, there is a risk that data interoperability

between systems may become problematic (Eason, Dent, Waterson, Tutt, & Thornett,

2012; Mudaly, et al., 2013).

Whilst the notion of ‘one size does not fit all’ may be considered a challenge for

the design of large scale eHealth systems, the adoption of top-down, middle-out or

bottom-up strategies by existing eHealth programs provides limited evidence that

either are antecedents for successful uptake of eHealth systems. Hart and Gregor

(2010) offer a different perspective based on the notion that that information systems

(IS) are never complete because they are “usually dynamic by being modified,

adjusted, extended or otherwise changed over the course of their existence in

continuing response to altered needs and circumstances” (p. ix). This strongly suggests

an approach that is sympathetic to the benefits of enabling users to interact and adapt

their eHealth systems in a way that supports their individual cognitive processes and

is aligned with their specific work practices.

An Information Services View (ISV)

Within this mind space, Hovorka and Germonprez (2010) contend that service-

based information systems undergo many more iterations of design than the traditional

design stages typical to extant systems development methodologies. They refer to

secondary design phases where systems undergo continuous re-design as users

discover the potential for unknown or unanticipated services that a system might

provide (Germonprez, Hovorka, & Collopy, 2007). Thus, an information services view

(ISV) represents a unique class of information systems with a focus on flexible

information services which engage users as secondary designer-developers. It

represents a shift away from systems design that is predisposed to over-engineering

the IT artifact with a limited set of data structures, interfaces and reporting systems

which impose constraints on work practices. The ISV offers a rational perspective of

service-based socio-technical information systems that are mutable, loosely coupled

and emergent which mirrors the behaviours of care pathways. Based on individualised

process oriented orchestration of information services, designers are encouraged to


develop “a reflective environment in which users’ thinking, goal identification and the

identification of meaning are supported” (Hovorka & Germonprez, 2010, p. 7).

In this way, an ISV approach enables users to identify and integrate information

services as a means to create personalised information systems. Germonprez and

Hovorka (2008, p. 365) state this vision as “the realization of user-enabled, real-time

production of ad hoc information systems”. Their perspective creates the impetus for

designing an innovative and purposeful artifact and establishes the rationale for

architectural influences discussed in the following section. In contrast to a top down,

middle out, bottom up approach, this may be considered an outside-in approach where

service providers offer information services based on the individual needs of the

clinician. This construct is very much focused on the voice of the customer to ensure

that their needs, wants and expectations drive innovation. Therefore, an ISV institutes

a user centered design paradigm for the creation of an IT artifact by considering the

relationship of users with information service systems. For this reason, the ISV offers

a design philosophy well suited to an outside-in approach.

2.4.3 Defining the Technical Architecture for eHealth-as-a-Service

Eason, Dent, Waterson, Tutt, Hurd, et al. (2012) acknowledge the debate about

the merits of top down, middle out and bottom up strategies by paying attention to its

implications for supportive design activities at each of the levels. They assert that

different technical architectures have different implications for the users of eHealth

systems. For example, an examination of the forces shaping the development of

national eHealth programs reveal that although there are several architectures

strategies available for providing access to electronic patient information, practitioner

literature limit the discussion to three common models: the centralized model, the

federated model and hybrid models (Barrows & Ezzard, 2011). Moreover, in practice

“the distinction between the three models is not clear cut, and there are vague areas

between the categories” (Accenture, 2012, p. 27).

The centralized model is typically referred to as a means for connecting

healthcare professionals and patients to a central repository containing patient

information collected from local sources. The model is effective for aggregating

information from multiple sources in a consolidated data warehouse within a

centralized governance framework. The federated model is referred to as the

decentralized or distributed model. Clinical information is stored at the source to


ensure that HCPs retain control over their patient’s information. A record locator

service manages request, search and retrieve tasks in order to enable HCPs to exchange

information. The hybrid model combines attributes of both the centralized and

federated models into a hybrid architecture. Clinical information is stored either at the

source or at regional levels. However, a central data repository and some form of

record locator service enables a patient’s journey between clinicians to be tracked

(Protti, 2008).

Figure 2.2. Six architectural strategies proposed by Wilcox et al. (2006).

Whilst this provides a succinct overview of different architectures, from a design

perspective it is useful to consider the more granular taxonomy provided by Wilcox et

al. (2006) who modeled six architectural strategies as a continuum. The model ranges

between separated (non-integrated) systems and fully-integrated monolithic systems

as illustrated by Figure 2.2. In this respect, their description of various federated

models form much of the continuum with increasing coordinating functionalities

added as the perspective shifts from separated to monolithic architectures (Barrows &

Ezzard, 2011). The architectural continuum may be defined as follows:

Separated systems are characterized by systems which store information locally

in data siloes. Communication of information among HCPs is manual e.g. telephone,

fax or the patient themselves. This is typically the most common method for sharing

medical information.

Separated federated models simply provide access to information contained in

separated systems to external HCPs. There is no requirement for synchronous

communication between systems.

Separated federated model with notification reflects the previous model with the

additional capability to send notifications to HCPs about the presence of data on

Architectural Strategies Continuum

Sep

arat

ed s

yste

m

Sep

arat

ed f

eder

ated

m

od

el

Sep

arat

ed f

eder

ated

m

od

el w

ith

no

tifi

cati

on

Co

nte

xt-a

war

e fe

der

ated

mo

del

Cen

tral

ised

rep

osi

tory

m

od

el

Mo

no

lith

ic s

yste

m


different non-integrated systems. However, there is a requirement for the centralization

and automation of patient identification across systems.

Context-aware federated models address the authentication and patient selection

processes of the previous model. In this respect, there is a requirement for centralized

coordination of system users as well as patient tracking among systems. Similarly, the

architecture must be able to accommodate clinical context messaging in order to

maintain the context of the clinician and patient within different systems.

Centralized repository models typically aggregate patient information in a

central location. Participating systems must transmit data to a centralized repository

where it is combined in a structured format. Therefore, there is a requirement for

agreed standards and guidelines to ensure that data is sent and received correctly.

Monolithic systems that share information are characterized by tightly integrated

systems. Components are interdependent and interconnected in a tightly-coupled

architecture requiring all participants to use the same electronic medical record. Thus,

exchange of information can occur at the direct data level provided that system

configuration is standardized across locations.

Whilst eHealth architectures exist along Wilcox’s six-part continuum, the

federated models used by New Zealand and the United States offer promising solutions

for the Australian environment where information silos and limited inter-institutional

communication is common. Specifically, it is hypothesized that the context-aware

federated model which allows HCPs to access separate applications or electronic

health records without having to re-authenticate or select patients offers a suitable

technical architecture. In this context, a patient’s information is accessed through

multiple and new channels at its source but movement between sources is significantly

simplified by taking advantage of the unique health identifier implemented by

NEHTA.

To permit access through multiple channels requires architecture that integrates

easily, is available on-demand with real-time capability and can scale infinitely. More

importantly, the Patient Journey may be considered a sequence of medical events

encompassing diagnosis and treatment of a medical condition. These care events,

particularly in large healthcare systems are evolutionary in nature predisposed to

organic growth rather than intelligent design (Poksinska, 2010). Moreover, subjective


patient choice of interdisciplinary health services reflects a self-organizing flexibility

and dynamism characteristic of healthcare ecosystems. Therefore, the amorphous

nature of a patient’s journey in primary healthcare settings introduces a level of

complexity characterised by a lack of homogeneity with regard to process lists, tasks

list or clinical workflows underscoring a significant challenge for system designers

(Carter, 2016). Consequently, the solution space requires the creation of systems and

applications around an event-driven architecture which is, by design, more normalised

for asynchronous processing in unpredictable environments (Hanson, 2005). A

potential solution is the Microservices architecture pattern. Microservices takes the

form of light-weight collaborating services developed and deployed independently of

each other with each service implementing a set of related functions which can be

accessed by multiple devices. The next section examines the Microservices

architecture pattern further in order to determine whether it is a natural fit for eHaaS.

2.4.4 Identifying an Architecture Pattern for eHealth-as-a-Service

Cloud computing has emerged as an increasingly popular computing paradigm

for delivering distributed application services across the Internet. Characterised by

superior scalability and decoupling as well as more effective control over development

and implementation, Cloud computing systems rely on distributed architectures.

Consequently, distributed architectures deliver significant benefits over n-tier and

monolithic architectures. Applications within distributed architectures tend to be more

robust and more responsive due to their typically self-contained nature thereby

simplifying change control and maintenance (Richards, 2015). Whereas, changes to

traditional monolithic applications typically increase the risks exponentially due to the

number of dependencies that grow over time (Avrem, 2015). Distributed architectures

encourage modularity which is the notion of encapsulating components of an

application in self-contained services. Services can be individually designed,

constructed, and implemented with minimal dependency on other components in the

application. This embodiment of end-to-end processes deployed as services

demonstrates a key benefit of service-based architectures. As the building blocks for

constructing distributed applications, services may be defined as:

“a mechanism to enable access to one or more capabilities, where the

access is provided using a prescribed interface and is exercised consistent


with constraints and policies as specified by the service description.”

(MacKenzie et al., 2006, p. 12).

By this definition, a service must possess a well-defined interface, some sort of

capability and a well-defined contract for access. Additionally, services are further

defined by service taxonomy, organizational ownership, and granularity. Service

taxonomies identify how services are organised within an architecture and refers to

two general types; service type and business area. The service type is defined at the

architectural pattern level. It denotes the role a service plays within the architecture

which may include business functionality or some other type such as system functions.

The second type is business area which is defined at the architecture implementation

level and denotes the role of a business service within a business functional area

(Richards, 2015). As examples, service oriented architecture (SOA) and the emerging

microservices architecture are considered service-based architectures centered on the

service as the principle architectural component for delivering business and non-

business functionality. Whilst they share many characteristics they are significantly

different architectural styles.

Service Oriented Architecture

A common approach used with service-based architecture is SOA which has

found broad adoption for integrating heterogeneous systems and different middleware

systems (Rodriguez-Loya, Aziz, & Chatwin, 2014). Widely used in domains that

include industrial, transportation, utilities and financial services, SOA is gaining

prominence in healthcare for integrating health information system (HIS) applications

that were not developed with integration as a priority (Mantzana, Koumaditis, &

Themistocleous, 2010).

Important design principles have been formulated in the context of SOA which

include loose coupling, discoverability, reusability, autonomy, abstraction,

statelessness, composability, sub-systemization, modularity and encapsulation of

functionality and data structures (Gaß, et al., 2013). As a result of these key principles,

benefits emerge that include increased agility through the application of new services

(O'Brien, Merson, & Bass, 2007), a reduction in operations and maintenance costs,

(Krafzig, Banke, & Slama, 2005) and more responsive service management (Petkov

& Helfert, 2013).


Central to service oriented integration is the enterprise service Bus (ESB). The

ESB implements a high protocol communication system between software

applications to achieve enterprise application integration. However, practitioner

literature suggests that a significant challenge for adopting SOA is service

incompatibility and the integration of loosely coupled data (Petkov & Helfert, 2013).

As an alternative, microservices architectures presents an approach to address some of

the challenges inherent with complex SOAs as well as the issues emerging from large

monolithic systems.

Microservices Architecture

Richards (2015) brings to light the fundamental difference between SOA and

microservices by observing that SOA with its ‘share-as-much-as-possible’ architecture

pattern emphasises abstraction and business functionality reuse. In contrast,

microservices is a ‘share as little as possible’ architecture pattern which emphasises

the concept of a bounded context. Drawing from domain-driven design (DDD), the

bounded context concept refers to the coupling of services to its associated data with

minimal dependencies forming a single closed unit.

A characteristic of microservices architecture is the use of services as the unit of

modularity which corresponds to a business capability. Described as “fine grained

SOA”, the microservices architecture pattern offers an alternative solution for complex

application scenarios due to its use of language agnostic application programming

interfaces (API) enabling independent processes to communicate with each other.

Newman (2014), describes the benefits of microservices as:

• Can easily reflect domain level entities and operations.

• Can be more easily aligned to the structure of an organization and adapt to

its evolution.

• Can be independently deployed - supports continuous delivery through

redeployment of services independently from the rest of the system.

• Allows simplified adoption of new technologies - with a single monolithic

system it is very difficult to mix technologies.


• Permits a fine-grained approach to performance tuning or scaling - instead

of scaling an entire system, in this way scaling can be applied to only those

parts that require it (De Simone, 2014, para 3).

In an enterprise context, microservices represents a move away from the over

engineered and perhaps outdated ESB products which offer complex and often

proprietary service orchestration, security and discovery extensions and an

overabundance of standards. Microservices architecture gives emphasis to simplicity

over complexity and is vendor agnostic (Kainulainen, 2014). The challenge for

developing microservice-based systems is overcoming the resistance of domain

models, transactions and queries to decomposition (Richardson, 2016). However, there

are various strategies which support the partitioning of the system into microservices

in order to ensure that each service possesses a small set of responsibilities based on

the single responsibility principle (SRP) (Richardson, n.d.):

• Decompose by business capability to define services based on business

capabilities.

• Decompose by DDD subdomain to define services based on the problem

space within the context of the subdomain within that larger business

domain.

• Decompose by resources to define a service responsible for the operation of

entities of a particular type e.g. an ePatient service that is responsible for

managing a patient’s information.

• Decompose by use case to define a service responsible for specific actions

e.g. an eAppointment service for creating appointments with clinicians.

Grounded in these concepts, the eHaaS design artifact may be positioned as a

service-based architectural pattern that is well placed to deliver the functionality

required to support complex multidisciplinary scenarios. Services become the unit of

modularity which correspond to a business capability for example, medication

management diagnostic imaging services. By structuring applications as a set of

loosely coupled, collaborating services, Microservices enables eHaaS to be more

easily aligned to the structure of the provider organization and adapt to its evolution

while also allowing for easy adoption of new technologies which highlights its

versatility as a technology consumption model.


Table 2.2

Comparison of eHealth programs

England United States Australia New Zealand eHealth-as-a-Service

Program NHS National Programme

for IT (NpfIT)

Health Information

Exchange (HIE)

National EHR

System (MyHR)

National EHR

System

eHaaS

Healthcare

System

Nation-scale, single-payer

health system

Fragmented and

decentralized health

system

Bifurcated health

system

Mixed

public/private

health system

Universal

Implementation

Approach

Top down Bottom up Middle out Middle out Outside in

Technical

Architecture

Centralised Federated Centralised Federated Federated (Context-

aware)

Comments Information quality issues,

cost overruns, paring back

of promised functionality.

Incompatible data

models, information

quality problems,

interoperability issues.

Usability issues,

information quality

concerns, lack of

meaningful

information.

Point to point

linking of systems

limits information

accessibility.

Design for the Patient

Journey. Focus on

process automation

and information

quality.


Based on the review of the literature in Section 2.1 and Section 2.3, Table 2.2

summarizes key concepts used to compare and contrast existing and future-state

eHealth systems. A consistent theme emerging from the Australian and international

eHealth programs is a lack of trust in the quality of health information. Through this

lens, it is reasonable to postulate that a causal relationship exists between information

quality and the level of information technology in an organization (Byrd & Byrd, 2012;

Wixom & Watson, 2001). However, a gap in the knowledge exists for effective

methods to validate the link between technology architecture, information quality and

healthcare quality (Byrd & Byrd, 2012). Therefore, consideration must be given to

this relationship in any endeavour concerned with the design, implementation and

evaluation of large scale eHealth systems. As a key value-proposition for adopting

eHaaS architecture, the next section reviews information quality literature to establish

a solid theoretical foundation for an evaluation strategy to validate the influence of

eHealth architectural designs on information quality.

2.5 SHAPING AN EVALUATION STRATEGY FOR EHEALTH-AS-A-

SERVICE

The WHO (2003) have stated, “the quality of health care is measured by the

quality of the data in the medical record” (p. 19). Yet the healthcare domain is

identified among those with the worst level of information quality with an estimated

one to five per cent of data considered to be of poor quality (Batini & Scannapieco,

2016). In their efforts to address this, the Royal Australian College of General

Practitioners (RACGP) developed a health records quality guide for application across

the Australian primary healthcare sector (RACGP, 2013). The guide which was

derived from the work undertaken by the British Medical Association, the Royal

College of General Practitioners and the UK Department of Health proposed seven

attributes for quality health records summarized by Table 2.3. Whilst useful as a set of

guidelines, the definitions provide a high-level perspective only, lacking objective

functions or metrics to permit meaningful evaluation.

Table 2.3

Seven attributes for quality health records provided by RACGP (2013)


Dimension Definition

Completeness Sufficient information is collected to reliably serve multiple

purposes.

Consistency Standards relating to terminology and clinical coding are used to

complement free text narrative.

Legibility Health information is legible and understandable and includes that

information collectors’ identity, handwriting, document scanning,

form layouts and suitable typefaces.

Accuracy Patient consultation records correctly reflect information captured

in that consultation.

Relevance Health records contain information that is meaningful and

appropriate for multiple purposes, including the provision of safe

and effective health care at the individual and practice level.

Accessibility Health information is organized in a way that information is easily

retrievable and is respectful, unambiguous and meaningful to

others.

Timeliness Consultation information is recorded in the patient record during the

consultation or as soon as practicable afterwards. Information from

other sources are incorporated into the patient health record within

a reasonable timeframe.

Despite the efforts by the RACGP, the challenge with formulating effective

evaluation strategies for health information is further emphasized by quality criteria

with “no universally agreed definition of what constitutes ‘good’ data” (AIHW, 2012b,

p. 24). However, these challenges are not unique to the healthcare sector with the same

issues reflected in the broader information quality domain. Information quality

literature suggests that there is no consensus on which set of dimensions define data

quality and generally, dimensions are not formally defined in a measurable way.

However, there are different approaches used to propose definitions of quality

dimensions (Batini & Scannapieco, 2016).


2.5.1 Defining Data and Information Quality

Data warehousing, business intelligence (BI) and the advent of Internet based

information sharing have encouraged academic interest in information quality research

(Shankaranarayanan & Cai, 2006; Shankaranarayanan & Even, 2004; Wixom &

Watson, 2001). Furthermore, research over the past three decades has produced a rich

body of work in the fields of data and information quality. As a result, there are three

foundational approaches for proposing definitions of data quality dimensions;

intuitive, theoretical, and empirical. An intuitive approach synthesizes quality

dimensions based on the practitioner’s experience or intuitive knowledge. The

theoretical approach is model based where dimensions are derived from an

understanding of the relationship between an information system and the real-world.

Whereas, an empirical approach adopts a data consumer perspective to derive

dimensions to understand data’s fitness for use (Batini & Scannapieco, 2016;

Sebastian-Coleman, 2012; Wang & Strong, 1996). Similarly, ongoing research efforts

in this area may be characterised in two ways: by the research approach which includes

intuitive, empirical, and theoretical orientations and by the research perspective which

distinguishes an objective versus a subjective view (Price & Shanks, 2005a). The

following sub-sections address these two perspectives in greater detail.

Intuitive Approach

As the term implies, an intuitive approach to information quality is not grounded

in theory and lacks theoretical development. It is reliant on ad hoc observations and

the experience of the observer (Price & Shanks, 2008). Similarly, methodologies

explaining how information quality dimensions are derived is limited (Rasmussen,

2008). On the other hand, a key benefit of this approach is a flexibility in the

application of quality attributes that are best suitable for the specific goals of the

analysis (Wang & Strong, 1996). This approach is useful when selection of quality

attributes for eHealth scenarios is based on the individual’s experience. In this respect,

an ethnographic study of a patient’s journey provides an intuitive understanding about

what attributes are considered important. To supplement this, a widely cited approach

providing a comprehensive set of information quality dimensions was proposed by

Redman (1996) who adopts a data modelling perspective. In this way, information

quality dimensions are associated with components of a data item which are organized

in three general categories: data model (conceptual schema), the data value, and data


format (internal representation). The data model or conceptual view of data reflects

the real-world through a common sense set of choices. Thus, the ad hoc selection of

dimensions at a specific level of granularity and precision offers flexibility at the

expense of rigor. The data value category includes a set of four dimensions: accuracy,

completeness, currency, and consistency. Whereas the data format category

encompasses eight dimensions: appropriateness and interpretability, portability,

format precision, format flexibility, ability to represent null values, efficient use of

storage and representational consistency.

Empirical Approach

The empirical approach based on the widely adopted notion of fitness of use is

examined in the context of data quality by Wang and Strong (1996) who ground their

discussion in a consumer perspective.

Figure 2.3. An empirical approach to defining data quality from Wang and Strong (1996).

This provides a useful lens for examining the effectiveness of eHealth systems

as it establishes a comprehensive framework to ensure all potential attributes are

considered. Figure 2.3 illustrates their conceptual framework for DQ based on an

empirical approach that included a two-stage survey and two-phase sorting procedure.

The two-level framework embodies 20 dimensions of data quality organized in four

categories considered important by information consumers. The categories are defined

as intrinsic DQ, contextual DQ, representational DQ, and accessibility DQ.

Empirical Approach

Contextual Data Quality

RepresentationalData Quality

IntrinsicData Quality

AccessibilityData Quality

Interpretability Ease of understanding

Representational consistencyConcise representation

AccessibilityAccess Security

Value-addedRelevancyTimeliness

Completeness Appropriate amount of

data

BelievabilityAccuracy

ObjectivityReputation


Intrinsic DQ describe attributes that are independent of a specific context

focusing on the conformance of data values with actual values e.g. accuracy,

objectivity, believability and reputation. This establishes data as having quality in its

own right, placing emphasis on all four attributes as a measure of high quality.

Contextual DQ encompass attributes “that must be considered within the task at hand”

(Wang & Strong, 1996, p. 20). Therefore, data must be timely, complete, relevant and

deliver an appropriate amount of data in order to add value within the context of the

data consumer’s task. Both categories are independent of information systems whereas

representational DQ describe attributes associated with the format of data (e.g. data is

concise and is a consistent representation) and meaning of data (e.g. data is

interpretable and easy to understand). Thus, this category is related to the output of an

information system where the aim is to ensure that data is well represented.

Accessibility DQ describes the accessibility of data in information systems and the

level of security associated with access.

Theoretical Approach

Alternatively, the theoretical approach proposed in Wand and Wang (1996)

explains the role of an information system (IS) as a representation of the real-world

(RW). With this approach, the IS and the RW are observed as formal models in terms

of states and laws.

Figure 2.4. Proper representation of a real world system from Wand and Wang (1996).

Figure 2.4 describes the IS as a proper representation of RW when two mappings

exist: (i) each lawful state of the RW is mapped to a minimum of one lawful state of

the IS i.e. there exists exhaustive mapping of each state in RW and (ii) it is possible to

RW IS


relate an IS state back to a corresponding RW state i.e. no two RW states can be

mapped back to the same IS state (“the inverse mapping is a function”) (p. 91).

Any differences between the inferred IS view of the RW and the actual view of

the RW is defined as representational deficiencies which fall into two areas, design

deficiencies and operation deficiencies. Figure 2.5 illustrates three categories

associated with design deficiencies: (i) incomplete representation, (ii) ambiguous

representation, and (iii) meaningless states. Incomplete representation occurs when the

mapping between the IS and the RW is not exhaustive. Therefore, lawful states of the

RW cannot be represented. Ambiguous representation is a result of an IS state mapping

to more than one RW state and there is insufficient information to infer which RW

state is represented. Meaningless states are lawful states in the IS which cannot be

mapped to an RW state.

Figure 2.5. Design deficiencies (i) Incomplete, (ii) ambiguous (iii) meaningless from Wand and Wang

(1996).

Operation deficiencies typically emerge from incorrect human activities during

system operation. It is characterised by garbling, this is where a RW state might be

mapped to an incorrect IS state. This manifests as two cases depicted in Figure 2.6: (i)

if meaningless states of the IS exist then the data consumer will not be able to map

back to the RW state and (ii) the mapping is to a meaningful but incorrect IS state

resulting in the data consumer inferring back to an incorrect RW state.

Based on a review of the information quality literature, Wand and Wang defined

the following five quality dimensions as representative of an internal view (design and

operation). Accuracy is the absence of garbling in the sense that the IS represents a

RW state correctly. Reliability signifies that the data can be trusted to deliver correct

information. Timeliness is defined by the delay between changes in the RW state and

RW IS RW IS RW IS

(i) (ii) (iii)


the update of the corresponding IS state. Completeness refers to the representation of

every meaningful state of the RW by the IS. Consistency in the Wang and Wand model

relates to the value of data only and refers to multiple states of the IS matching a state

of the RW (Batini & Scannapieco, 2016). However, supported by specialist literature

(Banfield, et al., 2013; Elder, Meulen, & Cassedy, 2004), quality dimensions used in

the evaluation phase of this thesis was informed by findings in Chapter 4 which

concluded that accuracy and timeliness may lead to improved continuity of care.

Figure 2.6. Two cases of garbling (i) IS meaningless state. (ii) Meaningful but incorrect IS state from

Wand and Wang (1996).

2.5.2 Information Quality: A Research Perspective

There is scholarly agreement that data or information quality is contextual and

multidimensional requiring evaluation relative to the context of the user (Strong, Lee,

& Wang, 1997; Stvilia, Gasser, Twidale, & Smith, 2007; Wixom & Watson, 2001).

Similarly, there has been considerable intellectual activity around the definition of

taxonomies of information quality dimensions (Stvilia, et al., 2007; Wand & Wang,

1996). However, this has resulted in overlapping and in some instances conflicting

interpretations (English, 2009; Redman, 1996; Wang & Strong, 1996).

Discussion in previous sections highlights a lack of consensus with respect to

what the term information quality means. Competing views are either product-based

or service-based establishing a perspective of quality as both an objective (meeting

requirements) and subjective (meeting expectations) phenomena (Kahn, Strong, &

Wang, 2002; Price & Shanks, 2005a; Wand & Wang, 1996). Objective measures of

information quality typically evaluate data conformance to either a set of

specifications, integrity rules or the corresponding real-world equivalent. This is

perhaps at the risk of overlooking contextual aspects that include presentation, delivery

and use of information as well as how it is perceived by the information consumer.

Consequently, data evaluated to be of high quality by objective measures may not be


acceptable to consumers due to these contextual properties. A subjective approach

attempts to address this issue by using measures based on consumer feedback where

contextual properties of data are considered with the quality of data (Price & Shanks,

2008). In this way, the design and evaluation of eHealth systems should account for

this dual nature of quality.

It is noteworthy that this objective/subjective duality brings attention to the

distinction between the use of the terms data and information which Price and Shanks

(2005a, p. 89) describe as “distinguishing between what is stored (i.e. stored data

values) and what is retrieved from data collections (i.e. received data values)”. This

perspective may be considered representative of the academic field and useful in the

context of this research. Thus, this thesis uses the term data as reference for the stored

contents of web-based services and databases which are typically subjected to

objective measures. Whereas information refers to stored data as well as received data

which is defined by presentation, delivery and use of data. In connection herewith,

information quality refers to both a subjective and objective perspective (Price &

Shanks, 2005a, 2008).

Bharosa, Janssen, Rao, and Lee (2008) point out that despite the interest in

defining the various dimensions of quality, there are relatively few contributions on

how to improve information quality. Understanding the relationships and concepts in

information quality as well as the quantitative and qualitative value of information can

assist in the design and evaluation of eHealth systems. Indeed, emphasis on the use of

quality management techniques for information quality improvement in information

systems (IS) provides the foundations for well-designed eHealth systems. To achieve

this, a framework that identifies and prioritises key dimensions of information quality

in alignment with the goals of safe healthcare is required.

2.5.3 Identifying an Information Quality Framework

There is no shortage of information quality frameworks described in IS literature

(Eppler, 2006). Several generic frameworks intended to be applicable to a broad class

of information systems have been proposed (Kahn, et al., 2002; Katerattanakul & Siau,

1999; Price & Shanks, 2005a; Wang & Strong, 1996). Examination of these

frameworks reveal some overlap of quality dimensions which include accessibility,

accuracy, completeness, consistency, relevancy and timeliness. However, a general

criticism within the information quality domain is a lack of methods for the assessment


of quality dimensions. In this respect, operationalisation and metrics tend to change

with the context of their application (Stvilia, Mon, & Yi, 2009). Thus, the challenge

for this thesis is not only the identification of relevant quality dimensions to inform

the design process but also the development of metrics in order to evaluate the design

artifact, (this is explored further in Chapter 6).

As discussed in previous sections, the theoretical approach proposed by Wand

and Wang (1996) is useful as a guide for system design and operation however,

deriving and defining criteria which is objective in nature limits the scope of a potential

framework by ignoring the subjective quality criteria of information quality. It must

also be noted that intuitive and empirical approaches may result in some

inconsistencies due to the definition of quality categories and the derivation of criteria

(Eppler & Wittig, 2000; Price & Shanks, 2005a). Thus, there are trade-offs between

rigor, relevance and scope (Price & Shanks, 2008). In response to these limitations,

Price and Shanks (2005a); Price and Shanks (2005b) offer a semiotic-based framework

which they state is rigorous and comprehensive. The authors contend that the InfoQual

framework provides a useful approach for designing effective data quality

improvement strategies. In the context of this thesis, the InfoQual framework

established the scaffolding for deriving the meta-requirements and design principals

in Chapter 4.

More importantly, semiotics holds a long standing relationship with medical

science, even though the term itself may be more contemporary. In this respect,

medical semiotics can also be referred to as semiology ‘Semiologie’, relating to the

theories of signs rather than the doctrine of it (Nöth, 1995). Thus, adopting a semiotic-

based framework establishes a theoretically grounded bridge between design and

information quality by considering the interpretation of a sign by an interpreter. It is

the notion that authentic interpretation of the sign is contextually bound to the

interpreter’s sociolinguistic and individual circumstances that draws a defensible

connection between information quality and the applicability of semiotics (Price &

Shanks, 2005a). In fact, semiotic theory has a rich basis in data quality literature

(Ballou, Wang, Pazer, & Giri, 1998; Price & Shanks, 2005a; Stamper, Liu, Hafkamp,

& Ades, 2000). However, inspiration is drawn from the work of Price and Shanks

(2005a) who posit that data serves as signs in the IS context. As a corollary, data

represents phenomena in the real world with metadata representing real world rules.


2.5.4 Semiotics: Sense Making Through Signs and Symbols

Semiotics is the study of meaning-making through signs and symbols and how

it is communicated. Whilst this area of interest embodies various theoretical stances

and methodological tools, contemporary semiotics is concerned with the study of

signs. Morris (1938) developed a behaviourist semiotics perspective by drawing from

the work of Peirce (1931) to derive three classifications that embrace traditional

branches of linguistics: (i) semantics examines the connection of signs with meaning,

(ii) syntactic establishes the structural relationship between signs or its form without

regard to meaning and (iii) pragmatics which is the use, (intension, communication

and negotiation), of the sign. This taxonomy may also be applied to interoperability

across collaborative systems (Neiva, David, Braga, & Campos, 2016). From this

perspective, semiotics provides a philosophical perspective for explaining the

predicted behaviour of information quality.

2.5.5 A Semiotic Framework

The InfoQual framework proposed by Price and Shanks (2005a) draws from

semiotic theory to provide a rigorous, comprehensive set of quality categories with

clearly defined criteria. In so doing, the framework defines information quality at three

levels syntactic, semantic and pragmatic. Drawing a connection to the three strata of

contemporary semiotics – syntactic (form), semantic (meaning), and pragmatic (use),

a basic structure for information quality may be fashioned using the definitions below.

Syntactic refers to the logic and grammar of sign systems. Consideration is given

to the structure of data and the level of conformance between stored data and stored

metadata (rules that govern their form). Here the focus is on quality dimensions

concerned with consistency. For example, a patient’s Medicare number is 65795238,

thus the stored data conforms to the metadata which requires a numeric value and that

the value must be eight digits in length.

Semantic refers to the meaning of symbols and is built on syntactic structure.

Meaning is subject to sociolinguistic and individual interpretation given that

uniformity between stored data and a real-world equivalent may differ for different

interpreters. Consequently, quality dimensions at the semantical level focus on

accuracy and comprehensiveness. In this respect the InfoQual framework expands on

Wand and Wang’s theoretically derived ontological framework for objective criteria


which relates the state of the information system with the state of the real-world. Wand

and Wang (1996) amended their quality criteria to address the inconsistencies

observed in their original analysis. Against this background, data accuracy

concentrates on how well the stored data reflects the state of the real-world whereas

comprehensiveness is concerned with the extent that stored data values reflect a real-

world state. For example, the Medicare number stored in various clinical information

systems is the same as the number appearing on a patient’s Medicare card.

From the perspective of this thesis, pragmatic refers to the use of signs.

Consideration is given to the relationship of stored data with its interpretation as a

consequence of a specific activity, context and user characteristic (Price & Shanks,

2005a). Thus, pragmatic understanding of the data is reliant on the social context and

purpose for which the data is used. Quality dimensions at the pragmatic level are

concerned with usability which encompass quality criteria at the syntactic and

semantic level but also include other usability attributes listed in Table 2.4. As an

example, timely, a key quality dimension for healthcare located at the pragmatic level

establishes a useful criterion for evaluation. This quality dimension concentrates on

whether the stored data is up-to-date for the specified task (Shanks & Darke, 1998).

Table 2.4

Information quality criteria based on the INFOQUAL framework developed by Price and Shanks

(2005a)

Criteria Description

Syntactic Criteria

Complete All external phenomenon is represented

Semantic Criteria

Unambiguous

An identifiable data unit represents at most one specific real-

world phenomenon

Correct An identifiable data unit correctly maps to its corresponding

real-world phenomenon. Properties mapped correctly (present,

appropriate, matching): Non-identifying (i.e. non-key) attribute

values in an identifiable data unit match the property values for

the represented external phenomenon.


Criteria Description

Consistent Each external phenomenon is either represented by at most one

identifiable data unit or by multiple but consistent identifiable

units or by multiple identifiable units whose inconsistencies are

resolved within an acceptable time frame

Meaningful An identifiable data unit represents at least one specific real-

world phenomenon

Pragmatic criteria

Accessible Quick and easy retrieval of data

Presentation

(context)

Data are presented in a manner appropriate for their use, with

respect to format, precision, units, and the type of information

displayed

Dynamic

Presentation

(flexibility)

Manipulation of data and customisation of the presentation as

needed, with respect to aggregating data and changing the data

format, precision, units, or type of information displayed

Timely The currency (age) of data is appropriate to their use

Understandable Data are presented in an intelligible manner

Secure Data are appropriately protected from damage or abuse

(including unauthorized access, use, or distribution)

The criteria listed in Table 2.4 plays a vital role in the design process by

augmenting the synthesis of meta-requirements and design principles. More

importantly, adopting semiotic theory provides a scientifically rigorous framework for

evaluating the design artifact in Chapter 6.

2.6 SUMMARY

The literature review has provided an account of the challenges faced by policy

makers and healthcare stakeholders when implementing large scale eHealth programs.

More importantly, it has identified gaps in the knowledge and provided insights into

how architectural forms and functions may contribute in a positive way to patient

outcomes. From an operational perspective, the Australian MyHR system and an open

standards infrastructure represents a nascent step towards a broader more patient-


centred approach to the delivery of care. As such, Australia’s national EHR system

requires continued support from policy makers, healthcare leaders and HCPs.

However, design choices with a focus on aggregating summary information perhaps

limits the potential of the MyHR solution to that of an electronic filing cabinet. As the

cornerstone of a larger process oriented, service-based framework, the MyHR and the

national eHealth infrastructure presents a unique opportunity for Australian HCPs to

leverage eHealth in innovative ways to add value to patient information flows across

the continuum of care. However, there is an impoverished account of the nature of

information flows at the individual patient level. This will be attended to in Chapter 4

as part of the problem identification phase. System requirements will be identified

which will inform choices for the design of a future state eHealth system.

A review of the literature in Section 2.4.1 provided evidence for an assertion of

this thesis that the continuity of care and patient safety may be improved through well

designed eHealth systems. However, they must be focused on delivering information

quality improvements within the context of a patient’s journey. This was underpinned

by insights drawn from the domains of eHealth and information quality providing

context and guidance for the design and evaluation of future-state eHealth architecture.

Emerging technology trends are driving the scaling of systems integration beyond

organizational and geographical boundaries placing renewed emphasis on the sharing

of information. Accordingly, there is a requirement to design systems to not only

collect data but more importantly enrich data for dissemination as high-quality

information services. Chapter 5 will address this gap by synthesising key concepts to

create and demonstrate an alternative eHealth design artifact.

Importantly, the information quality literature suggests that more emphasis

needs to be placed on information quality management as a necessary antecedent for

well-designed eHealth systems. However, this chapter has highlighted that effective

methods to validate the link between information technology infrastructure,

information quality and healthcare quality is poorly understood. To address this, an

evaluation strategy which identifies and operationalizes accuracy and timeliness as key

dimensions of information quality is required. This will be examined further in Chapter

6 with the development of a novel evaluation strategy suitable for service-based

information management systems.

Chapter 3: Research Design 47

Chapter 3: Research Design

3.1 INTRODUCTION

The aim of this chapter is to present a coherent research design describing how

different research components of this thesis fit together. Subsequent chapters will

convey the selection and application of specific data collection and analysis methods

adopted for operationalising each phase of the research.

An approach was adopted that shaped activities complimentary to research that

is applied in nature but also flexible enough to evolve over time. This was due to the

complex nature of the problem domain where neither a pure/exclusive qualitative or

quantitative methodology could adequately address the full dimensionality of the

research questions. Therefore, a multi-methodological approach was adopted

influenced by Nunamaker and colleagues’ assertion that “an integrated multi-

dimensional and multi-methodological approach will generate fruitful IS research

results” (Nunamaker Jr, Chen, & Purdin, 1990, p. 89). That notwithstanding,

Zachariadis, Scott, and Barrett (2010) postulate that philosophical concerns may be a

barrier to more extensive use. However, their examination of the value of critical

realism as a theoretical foundation to inspire and inform a mixed methods approach

establishes a philosophical touchstone for this thesis. This is grounded in the notion

that the research effort seeks to solve a real-world problem as much as discover a truth.

Consequently, data collection and analysis employed a mixed-method (qualitative, and

quantitative) approach grounded in a critical realist theoretical orientation. Similarly,

a design science research (DSR) approach established an appropriate theoretical

structuring context to organise the knowledge created by a hybrid research endeavour.

A principal driver for the adoption of DSR was its strength as an evaluation

methodology attuned to the benefits of mixed method design (Hevner, 2007).

Figure 3.1 provides an overview of the research plan highlighting a multi-

methodological approach. The diagram describes key process steps with expected

outputs, flows of knowledge and the cognitive processes associated with various

phases of the research. In conjunction with a design science sensibility, the process

steps are organised to reflect a linear DSR methodology as part of a problem-solving

process that is sequential and iterative in nature. Key phases of the research process

48 Chapter 3: Research Design

are characterised as define objectives - design and development – demonstration –

evaluation – communication and will be addressed separately by individual chapters

as denoted in Figure 3.1.

Figure 3.1. Overview of the research plan, highlighting a multi-methodological approach. .


Commencing with Section 3.2, the chapter provides a detailed explanation of

critical realism as the theoretical foundation for a mixed method research approach.

This is followed by Section 3.3 which examines the DSR paradigm and elaborates a

hybrid DSR framework which is complimentary to the design of large scale systems

in a healthcare context. The chapter concludes with a description of a mixed methods

research approach operationalised within three cycles of activity: relevance cycle,

design cycle and rigor cycle.

3.2 THEORETICAL ORIENTATION

In order to ground methodological logic and criteria, it is useful to establish a

theoretical perspective. In this respect, several advocates of DSR suggest pragmatism

as a philosophical posture (Hevner, March, Park, & Ram, 2004; March & Smith,

1995). However, clarification of the underpinning philosophies in information systems

(IS) related DSR is limited (Carlsson, Henningsson, Hrastinski, & Keller, 2011).

Indeed, the majority of existing research efforts manifest a philosophical polarity

around positivism, pragmatism or traditional realism. That being said, Bhasker’s

(1975) development of critical realism offers a valuable theoretical perspective for the

mixed methods approach adopted for this research.

Critical realism is undergoing a renaissance in IS and allied fields due in part to

the authority this approach establishes in the reconciliation between social theory and

research practice (Carter, 2000; Smith, 2006). Specifically, its ability to supersede

some of the more enduring social science dualisms for example positivism vs.

interpretivism, and structure vs. agency (Smith, 2006). However, extant literature

suggests that ontologically it is still a work in progress and thus open to

oversimplification in mixed method research (Lipscomb, 2011). Against this

background, Carlsson, et al. (2011) draws inspiration from the work of Bhaskar with

their contention that IS DSR may be grounded in alternative theoretical perspectives,

advocating the potential for critical realism’s objective ontology and subjective

epistemology. In this regard, a critical realist orientation permits the resolution of

theory-practice inconsistencies “through a reinterpretation of the activity of science”

(Smith, 2006, p. 192). It is the use of non-deterministic, non-Humean causal language

to describe the world, a central tenet of critical realism, which provides ontological

guidance for this thesis. Grounded in the work by Sayer (1992), Easton (2010) explains

that a critical realist view of the world is conveyed through informed causal language


that parallels the everyday explanation of the processes that are routinely adopted.

Similarly, a critical realist’s ontological assumptions include the existence of a

differentiated and stratified naturalist world that is independent of our knowledge of

it. This ontological stratification is observed in three domains: real, actual and

empirical. The real domain contains physical and social objects with behavioural

characteristics called mechanisms. Thus, theory development is focused on explaining

why, using a transcendental lens to identify enduring underlying causal relationships

(generative mechanisms) (Johnston & Smith, 2010).

This thesis seeks to examine generative mechanisms associated with eHealth

architecture and information quality. The actual domain is where these mechanisms

may or may not trigger events. Therefore, information flows and the effect of eHealth

on continuity of care are examined as patients traverse different care pathways. The

empirical domain is where these events may or may not be observed (Bygstad, 2010).

In this respect, appropriate validation tools and modelling techniques were used to

observe the empirical traces e.g. data flow diagrams, BPMN, IP-Maps and computer

simulation models.

3.2.1 Mechanism Classification

Notably, emergence is a key construct in critical realism suggesting that

attributes on the whole are not derived but emerge from the relationships of its sub

parts (DeLanda, 2006). The goal for critical realist analysis is to identify and explain

mechanisms that emerge from the investigation of the phenomena. DeLanda describes

two types of mechanism, i) micro-macro mechanisms, a bottom-up ontology that

explains emergent behaviour where outcomes at the macro level emerge from the

interactions between constituent parts, and ii) macro-micro mechanisms explains how

the macro level enable and constrain constituent parts thereby establishing the bounds

for novel performance.

DeLanda’s approach to analysis offers guidance by fostering knowledge of

health information infrastructures as complex multi-level structures. Entities, events

and mechanisms of Australia’s national EHR system were examined at the micro and

macro level to explain relationships and behaviours. At the macro level, a review of

the literature in Chapter 2, Section 2.2 provided insights into the implementation of

Australia’s national EHR system, its effect on information quality and its potential as

a framework for sharing patient information. At the micro level, an ethnographic case


study was utilised in Chapter 4 to advance understanding of patient information flows

as a patient traverses a care pathway and its implications for future state eHealth

architectures. This was an important aspect of the first phase of a multi-phase DSR

approach as it defined the problem domain and established research objectives. The

next section examines the DSR paradigm in order to establish an appropriate DSR

process model for this thesis.

3.3 A DESIGN SCIENCE RESEARCH FRAMEWORK

Whilst the design science methodology offers a prescriptive approach for

research, there remains a lack of consensus for a universally accepted process model.

Four widely cited guidelines by March and Smith (1995), Vaishnavi and Kuechler

(2004), Hevner (2007) and by Peffers, Tuunanen, Rothenberger, and Chatterjee (2007)

were examined in order to identify an epistemology that is aligned with the objectives

of this thesis. Following is a brief overview:

March and Smith (1995) draw from the design and natural sciences in their

discussion about research activities suggesting a four-phase approach: build – evaluate

– theorise - justify. The first two phases, build and evaluate, represent design science

activities and the remaining two phases, theorise and justify, bring a natural science

sensibility to the research process. The build phase encompasses the construction of

an artifact which addresses a specific problem domain. Evaluation identifies whether

the artifact can demonstrate a change (improvement) when compared to the

performance of existing artifacts. The theorise phase demonstrates how and why the

artifact works. Finally, the justification process is characterised by an empirical and/or

theoretical approach to test the proposed theories. Iivari (2003) asserts that March and

Smith’s presumption that evaluation should be empirical requiring formal

mathematical analysis perhaps suggest a criterion too restrictive.

Vaishnavi and Kuechler (2004) adapted a computable design process model

developed by Takeda, Veerkamp, and Yoshikawa (1990) to elaborate their ‘knowledge

using’ and ‘knowledge building’ processes. They typify the DSR process as:

awareness of problem – suggestion – development – evaluation - conclusion where the

contribution to knowledge occurs through circumscription in order to generate

“understanding that could only be gained from the specific act of construction”


(Vaishnavi & Kuechler, 2004, p. 10). Their contribution shows promise as the

methodological flesh for this project’s DSR framework.

However, it is Hevner’s problem identification – build – evaluate - theorize

process for obtaining DSR knowledge of the world (Hevner, et al., 2004) that may be

loosely aligned with the methodological guidance offered by numerous practitioners

in the DSR community. In the same way, Hevner, et al. (2004) regard design science

as a problem solving process. They posit that, as an outcome in the construction and

application of an artifact, a design science approach is predicated on the acquisition of

knowledge. This in turn informs understanding of the design opportunity or problem

and its solution which is a fundamental principal underpinning their seven guidelines

for effective design science research. Guideline 1 establishes the imperative for

creating a purposeful (it must address the specified problem), innovative artifact.

Guideline 2 requires the artifact to add value to the specified problem environment

whilst guideline 3 outlines the evaluative goals. Guideline 4 focuses on the

significance of innovation and guideline 5 calls for scientific rigour. Guideline 6

defines the search process and its iterative nature for the construction of an artifact as

a solution to a specific problem area. Finally, guideline 7 emphasises the significance

of communicating results from the design-science research process to technical and

managerial audiences for implementation or further research (Hevner, et al., 2004).

We consider these guidelines as a useful validation framework for our research in

Chapter 7.

In a similar fashion, inspiration was taken from Hevner’s later embodiment of

DSR as three closely related cycles of activities. Hevner (2007) offers a prescriptive

approach that is initiated by the relevance cycle which encompasses discovery and

goal setting, the design cycle involves artifact conceptualization and evaluation and

the rigor cycle which encompasses research validation and contribution to the

knowledge base. This provided the methodological signposting for the research plan.

However, a slight variation to Hevner’s three cycle taxonomy was introduced in order

to emphasise the cognitive processes that must be adopted in order to overcome

potential practice-theory inconsistencies.

Finally, the linear view of the DSR process advocated by Peffers, et al. (2007)

was considered. Their method is predicated on the notion that artifacts are designed as

part of a problem-solving process that is sequential and iterative in nature. Their


methodology follows the process: problem identification and motivation - define

objectives of a solution - design and development – demonstration – evaluation -

communication. A feature of their approach is the flexibility of the model where

research efforts may commence within a corresponding phase of the linear process

described above. It is this tractability in research perspective that best supports the

process (set of activities) and product (artifact) duality of DSR as an IS research

paradigm (Walls, Widmeyer, & El Sawy, 1992). In this respect, the applicability of

Peffers, et als’. (2007) ISDR framework to this research endeavor was high.

Epistemologically, a six step process model operationalized within Hevner’s three

cycles of activity helped to articulate a precise orchestration of the research process

while borrowing methodological elements from Vaishnavi and Kuechler (2008),

Hevner (2007) and Pries-Heje, Baskerville, and Venable (2008) resulting in a

composite DSR model as illustrated by Figure 3.2. In this way, the diagram brings

together additional methodological detail and purpose by describing the problem

domain, research objectives, design artifact, evaluation strategy and how the

knowledge will be communicated.

3.4 RESEARCH METHODOLOGY

A description of a composite design science research approach has been offered

aligned with Peffers and colleagues’ nominally sequential structure while also drawing

from Hevner’s three cycles of activities: the relevance cycle, the design cycle and the

rigor cycle will be adopted. The relevance cycle is distinguished by Peffers, et als’.

(2007) Problem Identification and Motivation and Define Objectives of a Solution

steps which establishes the application domain by identifying meta-requirements and

design principles from the contextual environment and criteria for evaluation of the

artifact. The design cycle includes the Design and Development and Demonstration

activities and is highly iterative focusing on theory building, creation of an artifact and

its evaluation in order to refine the design. The rigor cycle encompasses the final two

activities of the DSR research process, evaluation and communication which focuses

on the selection and application of appropriate theories for evaluating the artifact and

the subsequent contribution to the knowledge base. The following sub-sections

explicate each cycle of the DSR research process in further detail.


Figure 3.2. Composite design science research approach used in this thesis.

Rigor CycleEvaluate eHaaS

Computer SimulationComparative Analysis

Design Cycle Conceptualise eHaaS.

BPMNCase Study

Relevance CycleLiterature Review

Ethnographic Case StudyData Flow Diagrams

Ho

w t

o

kn

ow

led

ge

Identify and define problem

Define objectives and contribution of the solution artifact

Design and develop the artifact

Demonstrate artifact in context

Evaluate to determine ability to solve the problem

Communication

Efforts to operationalise a national scale eHealth

system has been problematic.

There is a potential relationship between

eHealth architecture and information quality.

Problem: designing large scale eHealth systems which have a positive

effect on health information quality

Provide perspective of

eHealth in Australian

healthcare and the implications for

patient information

quality.

Synthesize meta-requirements and

design an appropriate

technological solution.

eHealth-as-a-Service (eHaaS) construct design

and development.

Concept System Model.

Data Flow Diagrams

Theories:

Information Services View

Semiotic Theory

“Use in context” Scenarios

Case Study

BPMN

Evaluate the eHaaS framework to

ascertain impact on the problem.

IP-MAP (Information

Quality)

Computer Simulation Models

Comparative Analysis

Scholarly Publications

Thesis

Problem-centered approach

Objective-centered approach

Design & development-

centered approach

Observing the solution

Research entry point

Inte

rfac

e

Theo

ry

Met

rics

, an

alys

is

kn

ow

led

ge

Dis

cip

linar

y

kn

ow

led

ge


3.4.1 Relevance Cycle (Chapters 2 and 4)

The thesis commenced with the problem identification and definition phase in

which a patient’s perspective was adopted in order to examine the flow of medical

information as a patient traverses a care pathway (the Patient Journey). This was

coupled with a review of Australia’s national and international EHR systems in

specialist literature as the principal methods for collecting and analysing qualitative

data. The output from these activities were data flow diagrams (DFD) documenting

the effect of data management practices on information flows within the context of a

patient’s journey. In this respect, the ethnographic case study helped to identify

plausible interrelationships and patterns that emerged from observations of the

provision of care and clinical decision making.

Scoping review (Environmental Scan)

A literature review was undertaken as the first activity of the problem

identification and definition phase. In adherence to a design science approach, this

established a top-down approach for the synthesis of current knowledge (macro view),

in order to consolidate understanding of a multidisciplinary coherence between

technology, environment and healthcare stakeholders. The goal was to distil key

concepts and identify common themes related to the socio-technical aspects of eHealth

technologies and information quality.

The Patient Journey: An Ethnographic Perspective

The identify and define phase adopted an ethnographic case study approach to

apply a behavioural science lens to the problem identification and definition phase. In

this way, an understanding of organizational phenomena in context was fostered.

Adopting a participant observation method provided a truthful view of the world. This

perspective established a rich understanding and description of the problem domain

and, in this instance, the critical alignment between information communication

technology (ICT) strategies and healthcare and between the enterprise (organizations)

and IS architectures. This phase also facilitated data collection for synthesizing meta-

requirements and design principles to guide design activities.


Ethical Considerations

The magnitude of risk associated with the case study was considered low due to

the nature of the data being collected. To mitigate any risk of harm, all collected data

was de-identified. The participant (researcher) was fully aware of the benefits and risks

of providing information (identified or de-identified) to the study including how the

data would be used and how the data would be protected from disclosure. The

Queensland University of Technology (QUT) Human Research Ethical Committee

reviewed the study protocol and confirmed its negligible risk status.

Limitations

Ethnographic methods are immersive in approach in order to build an in-depth

knowledge of specific situations and contexts. To achieve this level of detail required

a significant investment in terms of time for fieldwork, analysis and write up. Whilst

this approach to detailed scientific inquiry may be observed as an advantage, its narrow

focus has been criticised due to the limitation in developing more generic models

(Myers, 1999). However, there are numerous examples of the use of ethnography in

healthcare scenarios (Cain & Haque, 2008; Guite, Lang, McCartan, & Miller, 2006;

Perrott, 2004; Waring, McDonald, & Harrison, 2006). The reliability of a study refers

to the degree a study can be replicated using the same methods. This emerged as a

challenge due to the nature of the data and the research process. Ethnographic data is

contingent on the social relationship of the researcher with subjects (LeCompte &

Goetz, 1982). Thus, the content of the data was influenced by social conditions and

situations as well as the choice of informant. Whilst the social, interpersonal and geo-

temporal contexts were clearly defined they were subject to change.

3.4.2 Design Cycle: Conception and Theory Development (Chapter 5)

As already observed with the multiplicity of DSR variants there occurred a

degree of opaqueness in a prescriptive approach to the design process. In pursuit of

guidance, Gacenga, Cater-Steel, Toleman, and Tan’s (2012) distillation of

methodological themes from the works of Peffers, et al. (2007) and Evbuomwan,

Sivaloganathan, and Jebb (1996) proved useful for identifying extant design practice.

Key concepts emerged from the review suggesting that design which embodies

theoretical principles is expected to deliver more effective IS given that IS components

are subject to natural and social laws.


Information Systems Design Theory (ISDT)

As a manifestation of the DSR design process, information systems design

theories (ISDT) may be observed as a “general solution to a class of problems”

(Baskerville, Pries-Heje, & Venable, 2009, p. 1). Accordingly, the seminal work of

Walls, et al. (1992) distinguishes two aspects of ISDT, the design process and the

design product. The design process defines the planning and proportioning of an

artifact to satisfy all requirements. Whereas, the design product represents a method

for operationalizing an artifact (Walls, Widmeyer, & El Sawy, 2004).

Figure 3.3. Components of an information systems design theory adapted from Walls, et al. (1992).

Whilst this is explored further in Chapter 4 and Chapter 5, Figure 3.3 illustrates

five components of the Walls and colleagues’ conceptualization: kernel theories, meta-

requirements, meta-design, design method and testable design product and process

hypotheses. Kernel theories provide the explanatory knowledge that guides the design

process and explains why the design works. In this instance, this thesis draws from the

information quality domain, specifically Pierce/Morris semiotic theory which studies

signs in terms of their logical components: representation and interpretation (Morris,

1938).

Against this background, meta-requirements and the subsequent design

principles which constitute the design theory were derived from an ethnographic study

and supplemented by a review of the literature. In the context of this thesis, the aim of

the meta-requirement was to derive higher-order functional specifications by defining

a collection of system behaviours required to achieve a goal or function. Therefore, it

is recognized that these are generalised goals and normative principles only, each has


a specific set of underpinning principles drawn from their respective domain literature.

The meta-design which describes a class of artifacts that satisfy the meta-requirements

was articulated as an information system design theory (ISDT) describing the design

principles of an abstract artifact. Design evaluation was attended to by the

identification of testable propositions based on the notion that the IS artifact will have

a positive effect on the quality of health information.

3.4.3 Rigor Cycle: Evaluation and Synthesis (Chapter 6)

DSR encourages validation as a primary goal of the evaluation process by

establishing assessment criteria to examine how well the change produced by the

artifact meets the specified criteria (March & Smith, 1995; Petter, Khazanchi, &

Murphy, 2010). There is a broad spectrum of evaluation methods and techniques used

to examine the validity of the design process and the artifact which may occur ex ante

or ex post, artificially or naturalistically, and using either hard or soft evaluation

methods (Petter, et al., 2010). The implications for DSR is that the understanding about

how and why a system works may not occur until after the fact (Gregor & Jones, 2007).

Ex Ante Evaluation

Based on this view, the conceptualization of eHealth-as-a-Service (eHaaS) as a

design artifact presents somewhat of a research conundrum when contemplating

evaluation activities. This was due to its scale and the nascent nature of operational

infrastructure for distributed health information services. However, a constructed IT

artifact perspective was adopted from Pries-Heje, et al. (2008) to anchor this cycle of

the research. They frame evaluation within an ex ante (evaluating the design) or ex

post (evaluating the artifact) binary providing a vocabulary which accommodates

DSR’s design research/design science duality. Hence, the opportunity to apply their

evaluation framework normatively encouraged an ex ante (prior to artifact

implementation) orientation to the evaluation of an eHaaS design artifact.

Using an ex ante perspective is well-suited to examining technologies or systems

prior to selection, acquisition or implementation (Pries-Heje, et al., 2008). The

challenge for this thesis is that relatively few theories effectively describe generative

mechanisms when viewed through the lens of critical realism. Johnston and Smith

(2010) observe that the majority of extant theories may explain the regularities

between entities identified within the Actual domain however understanding the Real


domain is the proper role of science. They cite theoretical contributions by Rogers

(1983) (diffusion of innovation), Ajzen (1991) (theory of planned behaviour), Davis

(1989) (technology acceptance model), Venkatesh, Morris, Gordon, and Davis (2003)

(unified theory of acceptance and use of technology), as examples with pre-disposed

assumptions for explaining technology adoption but under specific conditions and

from specific perspectives. Similarly, a review of theses and recent studies draws

attention to a conventional approach commonly used in IS research. This is

characterised by the conceptualization of a theoretically grounded instrument followed

by survey validation. The approach, while suitable in most IS studies, may not be

appropriate (or relevant) to projects where evaluation can be ex ante in nature or more

receptive to artificial rather than naturalistic methods.

To circumvent a debate about the ongoing tension between a positivist and

interpretivist view of evaluation, it would be remiss to ignore the central role that the

determination of value plays in this tension. This thesis acknowledges that

consideration must be given to the social, psychological, ethical and cultural

dimensions, (as is the want of the critical realist). However, it is not addressed due to

the adoption of a purely technical-rationalist lens in order to maintain a level of rigor

and validity. In this respect, adopting an ex ante perspective for evaluation provided

an appropriate prism for theoretically validating and evaluating an IT artifact based on

its design specifications.

The Benefits of Experimental Research

Drawing conclusions about the validity of the IT artifact requires an examination

of how well the change produced by the artifact addresses the problem it is intended

to solve. In which case, the evaluation cycle was located within the domain of

explanatory research rather than descriptive or exploratory research. In other words,

experimental research was considered favourably when adopting an explanatory

research approach due to its utility for examining the impact of the design artifact on

the problem it is intended to address.

Simulated Scenarios as an Evaluation Tool

Drawing a connection to the evaluation of an eHaaS artifact, kernel theories that

originate from reference disciplines such as information quality and service-based

architecture were considered. Semiotic theory and an information services view (ISV)

provided complementary constructs which include quality of information as products


and service-based computing to explain the predicted effect of change. As output from

the relevance and design cycles, these predicted changes were characterised by

generative mechanisms that emerged from the application of eHaaS architectural

concepts in a specific setting and the observed change to information quality.

A review of eHealth literature indicates that little attention is given to

methodologies for evaluating the influence of eHealth architectural designs on

information quality. Thus, a novel strategy encompassing a combination of data

modelling and business process modelling techniques was developed for

experimentation. Taking advantage of the modelling techniques adopted in Chapters 4

and 5, (e.g. data flow diagrams and business process models), a model documenting

information production processes was constructed in order to observe the effect of the

IT artifact on information quality. In this way, information production models ensured

that the computer simulation models exhibited external validity.

Based on logical deduction, it was predicted that eHaaS architectural concepts

will have a positive effect on information quality under controlled laboratory

conditions. Computer simulations described in Chapter 6 provided the basis for an

evaluative analysis to generate the empirical traces necessary for observation. This

approach facilitated an examination of operational information at the data structure,

data flow and business process levels providing important insights into the complex

interrelationships between these dimensions.

For the purpose of analysing accuracy, likely error rates were derived from

healthcare literature. Whilst these studies report a wide range of error rates, they also

indicate consistent behaviours suggesting that errors are common and may be

considered pattern based. Therefore, a range of values were applied as input

parameters to determine the likelihood of errors introduced during various state

transitions. A full list of error and their values used in the experiments is included in

Appendix D.

Simulation techniques, modelling concepts and time estimates used by Ballou,

et al. (1998) in their analysis of timeliness in a healthcare scenario provided the

framework and indicative baseline for experimentation. This was supplemented by

data values obtained from published time and motion studies (Carvalho et al., 2010;

Overhage, Perkins, Tierney, & McDonald, 2001; Pizziferri et al., 2005; Poissant,

Pereira, Tamblyn, & Kawasumi, 2005; Zheng, Haftel, Hirschl, O'Reilly, & Hanauer,


2010). A full list of input parameters and process narratives used in the timeliness

analysis is included in Appendix E.

3.5 CONCLUSION

IS research offers a rich diversity in methodological viewpoints and research

subfields. This multiplicity of perspectives in scientific discourse indicates that there

is no one right way to conduct research and there exists significant overlap in ideas

and methods. With respect to the clusters of research fields which focus on specific

epistemological interests within the broader discipline, for example eHealth, health

informatics, health information technology and their broad spectrum of subfields, it is

valuable to understand the fundamental goal of the research activity. This may

manifest as proving a truth or identifying a solution to a problem. In this respect, a

coherent plan for describing research design and methods was established. By locating

the research effort within a composite DSR framework ensures a scientifically rigorous

approach that is widely accepted in IS research. Epistemologically, the hybrid

framework was based on a six-step process model organized in three cycles of activity.

In this respect, the framework borrowed methodological elements from prominent

DSR practitioners in order to articulate a precise orchestration of the research process.

Against this methodological background, the adoption of a critical realist philosophical

orientation complimented a multi-method research process. More importantly, it is

grounded methodological logic and criteria in a research perspective that permits the

resolution of theory-practice inconsistencies.

Chapter 4: Problem Definition 63

Chapter 4: Problem Definition

4.1 INTRODUCTION

The aim of this chapter is to consolidate understanding of clinical information

flows as a patient navigates a care pathway (the Patient Journey).

As part of the problem identification and definition phase of the DSR framework,

an extensive review of Australia’s national and international EHR systems coupled

with studies on information flows in inter-institutional scenarios were supplemented

by an ethnographic analysis. A key justification for ethnographic methods (participant

observation) is the notion that it is most useful in the early stages of a user-centered

design project due to its focus on developing an understanding of the design problem

in complex scenarios (Therias, 2013). During the ethnographic analysis, the primary

method for data capture was unbiased descriptive observation in order to answer the

question “what is going on here”? Through this prism, an ethnographic analysis

examined the influences of a national eHealth system on clinical information

management practices. Insights into how and why particular phenomena contribute to

information management practice were then used to inform the synthesis of solution

objectives (meta-requirements) and normative recommendations (principles).

The researcher, with 20 years of experience developing and implementing

information systems (IS), participated in an ethnographic study as a patient in

ambulatory and in-patient scenarios. With this approach, the Patient Journey served as

a case study providing a detailed account of complex and dynamic processes located

within a specific geo-temporal context. Drawing on the researcher’s skills as an analyst

and system designer, the process of investigation helped to consolidate understanding

of healthcare institutions, clinical processes and information management practice.

Meta-requirements, informed by key concepts obtained from information quality

(IQ) and IS literature, were identified and formalised as normative design principles

for the conceptualization of an eHealth design artifact. To simplify solution finding,

common themes emerging from this case study were organised within four problem

domains (i) clinical workflow integration, (ii) optimising clinical decision making, (ii)

enhancing continuity of patient information and (iv) improving the quality of patient

64 Chapter 4: Problem Definition

information. In that vein, the findings from this study correspond to themes emerging

from existing research studies examining care pathways in England and the United

States. This suggests that the identified problem domains offer a consistent view of the

challenges associated with managing information flows in diverse healthcare settings.

4.1.1 Contributions

This chapter makes the following contributions:

• Presents an in-depth analysis of how health information is created and

propagated within the Australian healthcare system. This enabled a better

understanding of the impact of extant information management practices on

information quality and the continuity of care.

• Identifies four meta-requirements, and design principles as a technological

response to the problem domain with clear arguments supporting why the

requirements hold significance in the context of distributed delivery of care.

The chapter begins by identifying key themes emerging from existing research

in the management of information flows occurring within inter-institutional settings.

Sections 4.3 and 4.4 provides a description of the study design, philosophical

orientation, methodology and limitations establishing the methodological framework

for the analysis. Findings in Section 4.5 present observations from the ethnographic

study highlighting issues and opportunities associated with the management of patient

information in cross domain work flows. Section 4.6 concludes the chapter with a

discussion about the findings and draws from the literature to identify meta-

requirements and design principles.

Findings in this chapter were also presented in the publication: “Chronicling the

Patient Journey: Co-creating Value with Digital Health Ecosystems” in Proceedings

of the Australasian Computer Science Week Multiconference, (Black & Sahama,

2016).

4.2 BACKGROUND

The Patient Journey is considered a sequence of medical events encompassing

diagnosis and treatment of a medical condition. Characterised by nonlinear process

flows, clinical workflows are emergent and complex, influenced by subjective choice

of interdisciplinary health services (Chatterjee, 2012). Each of these services use


processes which incorporate many different micro processes influenced by the

clinician’s preference for care, area of expertise and the patient’s state of health. For

example, an obstetrician’s exam requiring an ultrasound of the patient will be different

from an orthopaedic surgeon who may want x-rays of the patient prior to each

examination (Cooper, Copenhaver, & Copenhaver, 2001). As a result, information

sharing between clinicians in cross-functional settings presents a critical class of

problem requiring a specific technological response to ensure smooth transition of

care. According to Chiappelli (2014):

“[continuity of care] depends not only on the efficacy and effectiveness of

diagnostic and treatment interventions, but also on the quality of information

flow, interpersonal skills, and the overall coordination of care” (p. 60).

Despite considerable work to identify problems with the delivery of care in

primary healthcare processes, efforts to better understand information flows in inter-

institutional scenarios is limited. That notwithstanding, an evaluative study examining

eHealth record sharing in England mapped nine healthcare pathways providing

insights into information sharing across organizational boundaries (Eason, Dent,

Waterson, Tutt, Hurd, et al., 2012). The study suggested that seamless continuity of

care requires information systems to be based around the care pathway (i.e. systems

should be designed for the Patient Journey).

Additionally, several themes concerned with the flow of information emerged

from the English study. Firstly, electronic system use was widespread, but most

systems cannot share information with other systems. Often, it was necessary to re-

enter data contained in order systems, particularly in situations where the information

was initially paper-based. This restricted access to up-to-date clinical records and

increased the risk of clerical error. Moreover, many different administrative processes

existed for managing information flows subject to the internal policies and preferences

of the organization.

Secondly, there were common methods for sharing information for example,

unstructured and structured electronic data transfer, facsimile (fax), email attachments,

letter, or a combination of these formats. As a result, the burden on clinicians and

administrative staff could be significant in order to ensure all incoming information

was processed and the proper actions taken to update patient records. The report stated

that it was “a problem that raises issues of efficiency; a great deal of time and money


seems to be spent moving back and forth between electronic and paper forms” (p. 74).

Thirdly, the timeliness, quality and usefulness of information was extremely variable.

This was based on the perspective of GPs with concerns that information might either

be detailed and useful or cursory, omitting important information. In this respect,

information quality was reliant on the source irrespective of the method used for

sharing.

Similarly, a study in the United States by Khan, Kukafka, Payne, Bigger, and

Johnson (2007) provided a more task oriented perspective using observational studies

of clinical research workflows. Their findings highlighted needs and inefficiencies

considered representative of community practice settings. Moreover, these

inefficiencies were emphasized when viewed through the prism of information

management principles. Firstly, paper-based processes led to issues with dissemination

and replication providing limited error checking and poor timeliness of information.

Secondly, redundant data entry resulting from transcription between forms and entry

of the same information for different purposes and audiences increased the risk of

transcription and omission errors. Equally, maintaining this redundant data over time

resulted in further inefficiencies. Thirdly, processes did not provision for reuse of data

due to limited system integration encouraging redundant data entry practices and

limiting the sharing of information. Fourthly, communication mechanisms either failed

to provide timely information or resulted in several duplications of clinical

information.

Irrespective of the care pathway or healthcare setting, recurring themes emerging

from these studies can be organised into four broad problem domains; (i) clinical

workflow integration, (ii) optimising clinical decision making, (ii) enhancing

continuity of patient information and (iv) improving the quality of patient information.

Whilst these bounded areas of application provide focus for deriving solution goals, it

is necessary to look in more detail at specific situations from a patient’s perspective.

Drawing inspiration from the work of Easton (2010), the aim of an ethnographic study

was to: (i) depict major activities in the Patient Journey and the informational

relationships between them; (ii) identify the organizations and roles that undertook

each of the major activities and (iii) identify the information management practices

used by the organizations and how information was shared across organizations. This


raised questions about data collection, study design and the mapping of clinical

information flow.

4.3 STUDY DESIGN

Locating its roots in the biological, social and cultural domains of anthropology,

ethnography is the systematic method of studying people and cultural phenomena

within a specific context (LeCompte & Goetz, 1982). It is reflective in nature, building

understanding of the social aspects of human behaviour in order to articulate a credible

view of the real world (Blomberg, Giacomi, & Swenton-Wall, 1993). As a technique

incorporated in systems designs, ethnography has achieved broad adoption in the study

of information systems (Ball & Ormerod, 2000). This is due to its suitability for

providing information systems researchers with “rich insights into the human, social

and organizational aspects of information systems development and application”

(Harvey & Myers, 1995, p. 22). Thus, the objective of this chapter is to provide a

descriptive narrative of the Patient Journey based on ethnographic work.

4.3.1 Theoretical Orientation

This section draws a connection between a critical realist orientation discussed

in Chapter 3 and the problem articulation process. From a critical realist perspective,

it is important to acknowledge the ontological assumption that whilst there is a real

world, it may be difficult to comprehend. This is addressed by establishing a stratified

view of the world in order to theorise about the nature of reality. In this way an

analytical perspective is brought to bear on information management practice in

Australian clinical scenarios based on the ideas of Easton (2010). He states that critical

realists maintain the existence of entities or objects, in this instance the Australian

national EHR system, as an entity that has the capacity to influence and be influenced

by other entities. In turn, the entity may possess internal structures organised in a

specific way (i.e. hierarchical, network or value constellation) such as hospitals, clinics

and HCPs that possess their own influence. Relationships may emerge between entities

because of this influence which may also be contingent in nature, for example between

a patient and different HCPs as the patient progresses along different care pathways.

Consequently, it is the perceived relationships between entities resulting in an event

that is identified as generative mechanisms.


As a data collection method, ethnography and participant observation offer

compatible methods for developing understanding of causal mechanisms. (Ackroyd,

2004). Indeed, Edwards, O’Mahoney, and Vincent (2014) argue that ethnography is

most effective when conducted within a critical realist orientation and similarly a

critical realist approach can benefit from adopting ethnographic methods. They

conclude that the real benefit of gathering micro-level data through ethnographic

enquiry emerges from locating and interpreting data ‘in the wild’ in order to include

geo-temporal, economic and social contexts. Rather than a mere data collection

process, a critical realist framework encourages the linking of observations to context

in order to explain social phenomena rather than just providing a description.

4.4 METHODOLOGY

Participating in the role of a patient presented the researcher with a variety of

challenges due to the complexity and emergent nature of a patient’s journey. Ideally,

the aim of the ethnographic researcher is to present their methods at a level of detail

that other researchers can use as an operating manual in order to reproduce the study.

However, the analytic processes used to construct ethnographies are often intuitive,

vague and “personalistic” (LeCompte & Goetz, 1982, p. 36). This brings into sharp

focus both external and internal reliability issues when describing phenomena in a

consistent manner. From a critical realist perspective, the researcher was interpreting

and describing socially constructed objects, for example clinical processes, medical

protocols and technological infrastructure which reside in the intransitive dimension.

Specifically, the flow and type of information (structured or unstructured, text or

image) being created and how it was being managed and utilised. The intention was

not to identify an exhaustive set of generative mechanisms but to make sense of

repeating causal patterns as explanations for observed outcomes. This required an in-

depth knowledge of healthcare contexts and situations.

The use of analytical tools e.g. data flow diagrams (DFD) and business process

model and notation (BPMN) (OMG, 2008), as a graphical representation of patient

information flow and clinical processes provided further insight into the potential for

process optimisation and information quality improvements. However, this required a

multi-tool approach in order to examine the problem domain from different

perspectives and explain the complex interrelationship between clinical processes and

patient information. BPMN models, explained at length in Chapter 5, provided a


common vocabulary for documenting clinical workflows. Whereas, data flow

diagrams documented the processing of data within a system based on inputs and

outputs. Often used as a preliminary step for redesigning a system DFDs provided a

set of visual symbols to define data sources and destinations, information flow and

data storage as shown in Figure 4.1.

The analytical tools used in the study provided a ‘black box’ perspective of how

information moves within a healthcare system. The rationale for this approach was to

minimise any bias (perceived or institutional), introduced by technological constraints,

medico-legal concerns, organizational policy or professional culture. The focus of the

study was on the how, what and why of information management with the results being

used to inform user-centered design.

Figure 4.1. Data Flow Diagram symbols.

4.4.1 Location and Timeline

The research method provided guidelines for conducting observations at

government and private primary and allied healthcare organizations located in

Brisbane Australia between October 2013 and July 2014. Figure 4.2 depicts one such

care pathway which emerged as a result of abnormal blood test results. This particular

Patient Journey serves as a useful analogue for many possible care pathways in order

to understand the nature of information flows within the Australian healthcare system.

4.4.2 Data Collection

A patient’s care pathway is organised as a procedural sequence of care events.

For example, a patient may consult with a GP who might order pathology tests

resulting in a consultation with a Specialist who in turn may order further pathology

tests and so on. The process of delivering care however, may not be considered linear

due to the emergent nature of diagnostic medicine where each event is the creation and

ProcessPerformed by the

system.

External EntityA source or a destination of

data.

Data StoreWhere data is held between

processes.

Data Flow


result of feedback loops that must be agile enough to accommodate unexpected

outcomes. Due to this characteristic, data collection primarily from observation and to

a lesser extent informal conversation occurred serendipitously influenced by the

dynamic and, at times, ad hoc nature of a patient’s progression through a healthcare

system.

Figure 4.2. Care events examined within a patient's journey.

4.4.3 Materials

Taking guidance from Whitehead (2006), an open-ended approach was adopted

with the intention of recording as much information allowable in each care event.

Sharp mental notes were taken based on careful observation and reflections on

conversations from each encounter. This was aided by transcription to field notes

immediately upon departing the setting observed. The primary method for data

collection was unbiased descriptive observation in order to answer the question: what

is going on here?

4.5 FINDINGS

This section details the findings of the ethnographic case study in the form of a

narrative describing the researcher’s experience as a patient. The intention was not to

reproduce the various care processes verbatim. From a design perspective, it was

useful to identify areas requiring further examination in order to understand the


characteristics of managing patient information in complex multidisciplinary

scenarios.

The patient (principle researcher), is a healthy, active 53 year old male with no

pre-existing medical conditions or disabilities. He has not visited a general practitioner

(GP) in the past five years and considers himself in good shape due to regular exercise

and a sensible diet. The patient’s selection of GP is typically based on convenience

resulting in fragmented medical records distributed across national and international

boundaries. Whilst his intent was to attend a general health check, what emerges is a

sequence of unplanned care events where the patient engaged with multidisciplinary

HCPs which emphasizes the dynamic nature of healthcare.

My Health Record (MyHR) is the current nomenclature used for the personally

controlled health record (PCEHR) and is used in this narrative to identify the role

played by Australia’s national EHR system. Reference to data objects in the Patient

Journey overview is denoted in the following data flow diagrams by their

corresponding letters and numbers in parentheses e.g. (P1:D2) refers to ‘Process 1:

Data flow 2’ or (D23) refers to ‘Data flow 23’.

4.5.1 A Patient’s Journey: Preliminary Activities

Registration for a MyHR was completed mid 2013 as a preliminary step in order

to investigate the utility and value of a personal health record (PHR). Access to the

system is secure, requiring verification of an individual’s identity before a PHR is

created. The record serves as a repository for summarised health information and is

used to digitally collect demographic details, current medications, allergies, and

advance care directives. The default privacy settings were accepted by the patient

permitting general access to his records by HCPs. An appointment was arranged by

telephone for a general health check at a mid-sized metropolitan medical centre in

Brisbane, Australia. The patient has no history with the clinic and it was assumed that

the MyHR would be used as part of their clinical workflow.

4.5.2 General Practitioner Consultation Pathway

Figure 4.3 illustrates the flow of information associated with diagnostic support

processes. Commencing with the arrival of the patient at the general practitioners’

(GP) clinic, the patient was required to manually complete a clinic registration form to

collect demographic details and medical history (P1:D27). The MyHR was not used


by the medical centre due to concerns about the security and utility of the system. It

was noted by the patient that the registration information (demographic data) was

available for download from his MyHR but not accessed (S2). This indicated that there

was evidence of duplication of effort increasing the clinic’s administrative burden in

order to transcribe readily available information into an electronic practice

management system (PMS).

Figure 4.3. Data flow diagram illustrating the flow of information associated with diagnostic support

processes.

A health check by the GP revealed no obvious problems but a routine blood test

was recommended. A handwritten pathology test order using a pre-printed order form

was given to the patient to take to their choice of pathology laboratory (D4). A local

laboratory was selected where a blood specimen was collected for analysis. The

handwritten pathology order containing details of the patient’s demographic data, the

E2General

Practitioner

D25. Patient Details

E1PatientP7

Ultrasound Registration(Radiology)

D14. PatientDetails

E4Radiologist

S5PACS

(Radiology)

S2eHealth Store

S1Patients

(GP)

D24. ProcedureRequest P10

Specialist Referral

(GP)

D3. Medicare Event Summary

D15. Ultrasound

D20. ClinicalEvent

Summary

E5HospitalP5

Blood testFollow-up

D10. Request for medical

history (email)

P4Pathology

Test

D8. Results

D5. Patient Details

D9. Require

more information

P6Ultrasound

Referral

D11. Procedure Request

D12. ReferralLetter

S4Patients

(Radiology)

D21. Radiologist Report P8

TakeUltrasound

D16. Ultrasound Image

D19. Report

P9Develop

Ultrasoundimages

D17. Ultrasound

D18. UltrasoundImage

P3Record

Medicare health event

D2. Clinical Event

Summary

P2Consultation

(GP)

D22. Ultrasound &

RadiologistReport

D23. RadiologistResults

D1. Consultationdetails

E3Pathology

Lab

D4. ProcedureRequest

S3Patient

(Pathology)

S6Patient

(Hospital)


D7. BloodAnalysis

D6. SpecimenDetails



D28. PatientDetails

P1Consultation Registration


tests and clinical information were recorded indicating an increased risk of information

quality issues due to transcription errors. The central role played by the patient in

clinical information flows with the associated risk of inaccurate information recall was

noted. This was evidence that there is a reliance on the patient participating in the role

of courier and an assumption that patients possess the necessary competency to relay

complete and accurate information.

4.5.3 Diagnostic Support Pathway

Five days later, the patient received an email about abnormal test results from

the GP (D8). Inquiries were made about a family history of kidney disease which

prompted some vague information about a close relative who had suffered kidney

problems (P5:D10). An ultrasound was recommended requiring the patient to collect

a hand-written referral form from the medical centre (a round trip of 60 minutes),

before booking an appointment at a Radiology clinic of the patient’s choice (P6:D12).

On arrival, the patient registered at the Radiologists’ clinic with the referral form

issued by the GP (P7:D14). Ultrasound images were taken and hardcopy images (D17)

were prepared by the sonographer for the radiologist to interpret and complete a report

(D19). Hardcopy images and the report were given to the patient for delivery to the

GP. The patient subsequently scheduled an appointment with the GP six days later for

a review of the ultrasound images (D23). It was recommended that a consultation with

a Specialist was required (P10:D25). A referral to a Specialist at a public hospital was

arranged by the GP.

The DFD in Figure 4.3 highlights the central role played by the patient (E1)

emphasising a reliance on memory and communication skills which may impact their

value in the principal role of information transfer. The requirement for the patient to

collect the referral letter from the GP’s reception (D12) and the completion of clinical

forms with information already contained in the MyHR (P1, P4, P7) emphasizes poor

system interoperability underlining the challenge of propagating patient information

between multidisciplinary HCPs. Similarly, the transfer of sensitive medical

information by the patient (D12, D22) raises concerns about information privacy and

security.

It was observed that collection of demographic data by the radiology clinic is

further evidence of the duplication of administrative effort. When observed as a


downstream process of multiple manual information collection processes, the risk of

errors being introduced to clinical information is compounded. From a data storage

perspective, there is evidence of a proliferation of siloed data represented by Data

stores; S1, S2, S3, S4 and S6. These discrete data stores contain homogenous but

potentially inconsistent information which further underscore concerns about


4.5.4 Hospital Outpatient Care Pathway

Figure 4.4 illustrates the data flows resulting from activities associated with

hospital outpatient processes. The Patient Journey continues three weeks later after the

patient received an appointment letter from the hospital’s outpatient services

(P11:D32). The patient presented at the hospital outpatients with the ultrasound images

and radiologist letter in hand. Manual registration at reception was now a familiar

routine however, in this instance, a check was made to verify the patient’s details

contained in a referral letter sent by the GP to the hospital (P12:D35).

Figure 4.4. Data flow diagram illustrating information flows resulting from activities associated with

hospital outpatient processes.

A review of the patient’s diagnostic information by the specialist resulted in a

recommendation for further tests which included a Computer Tomography (CT) scan

(D38). The Specialist completed an order form for the test and gave it to the patient

E6Patient

S8Outpatient

Appointments

P11 Schedule

Outpatientappointment

D31. Appointment details

D32. Appointment Letter

S7Patients

(Hospital)

E6Patient

P12Outpatient

Registration

D34. PatientDetails

D35. PatientDetails


P13Specialist

Consultation

E7Specialist

P15Schedule CT

Scan

P20Fill Prescription

S11PACS

(Hospital)

P16Archive

Ultrasound Image

E9Pharmacy

D55. Prescription

D33. Confirmation

D37. Prescription

D38. CT Scan Request

D39. Event detail

D40. Prescription

D36. UltrasoundResults

S10eHealth Data

StoreP14 Record


D59. Medicationinformation

P18Access Patient

PCEHRS12

Patients(Pharmacy)

D58. MedicationInformation

D53. PCEHRActivity Details

D49. Ultrasound Image

P19PCEHR Audit

Control

D51. HealthcareIdentifier

D50. HealthcareIdentifier

S9Radiology

Appointments

D56. PrescriptionDetails

D42. MedicareSummary D52. Patient

Information


D47. AppointmentDetails


D48. UltrasoundImages

D45. AppointmentDetails

D54. PCEHRActivity

Alert

D46. PatientDetails


D57. DispensaryInformation

E8Radiology(Hospital)

P17Take

CT Scan

D60. CT Scan Image

D62. CT ScanResults

D61. CT ScanImage


(D43). Medication was recommended to manage the diagnosed condition and a

prescription was handwritten by the clinician (D40). An appointment for the CT scan

was arranged by the patient with the radiology department at the same hospital

(P15:D44). The order form was given to reception and an appointment scheduled

(D47). At the request of the radiology department, the patient’s ultrasound images

were scanned into the hospital’s picture archiving and communication system PACS

(P16:D49). When the patient next checked his email, he observed a notification that

his MyHR had been accessed by the hospital however no new information had been

added (P19:D54). The prescription was filled at a local pharmacy and the medication

self-administered by the patient (P20:D55).

CT scans were completed three weeks later (P17:D61). While travelling home

from the hospital, the patient was contacted to return for a second set of scans which

made him uneasy. These feelings were intensified when no additional information or

results were provided until he met with the Specialist weeks later. Figure 4.4

emphasises this underlying theme of data siloing by giving evidence of multiple

systems and data stores, some of which are located within the same organization e.g.

the hospital clinical information system (CIS) (S7, S8, S9) and PACS (S11). Similarly,

the archiving of patient image data indicates that multiple copies of patient information

are distributed across various systems.

Notification of access to the patient’s MyHR suggested that auditing systems

were in place alerting the patient to activity in his record (P19:D54). No new data was

added which may have been a missed opportunity to allay the concerns of the patient

about the requirement for additional CT scans. It is acknowledged however that

unregulated access to information must be balanced with the potential risk of providing

inappropriate and/or irrelevant information to patients prior to consultation with their

HCP.

4.5.5 Surgical and Inpatient Care Pathway

Figure 4.5 illustrates the surgical and inpatient data flows to resume the Patient

Journey ten weeks after the CT scans (P20:D63). Following a consultation with his

Specialist, the patient agreed to surgery which was scheduled later in the year (D68).

Six weeks after the Specialist consultation, a letter was received from the hospital with

admission instructions and details of the surgical procedure (P22:D72).


On the day of surgery, the patient arrived at reception and was provided with

admission paperwork requiring demographic information, current medications list and

a health assessment (P23:D75). Immediately prior to the surgical procedure he

underwent an examination by the anaesthesia team to identify any potential risks or

history of anaesthesia related issues (P24:D77). Following surgery, the patient was

transferred to an inpatient ward and subjected to a four-hour cycle of observations for

vital signs (e.g. pulse and blood pressure) (P25:D79) which was collected on a

handwritten chart by nursing staff. The patient was released two days later and was

issued with aftercare literature and a prescription for pain medication printed from the

hospital information system (P26:D84).

Figure 4.5. Data flow diagram illustrating the information flows associated with surgical and inpatient

processes.

Manual registration during inpatient admission suggests that policies and

procedures are in place to ensure a patient’s current information and health status is

collected prior to a surgical procedure (P32:D75). This places an administrative burden

on the admission process and underscores the requirement for improved data

S13Appointments

P22Patient

AppointmentScheduling


S14Patients

(Hospital)

E10Patient

P23Hospital

Admission

D74. Demographic Information

D75. PatientDetails

P20Specialist

Consultation

E9Specialist

P27Fill Prescription

E13Pharmacy

D85. Prescription

D73. Confirmation

D64. Surgical Procedure Request

D63. TestResults

D67. Event Detail

S15eHealth Data

StoreP21

RecordMedicare Health

Event

D88. MedicationDetails

D66. Medicare Summary

D65. ConsultationSummary

S16Patients

(Pharmacy)

D89. PrescriptionDetails

D90. DispensaryEvent

D87. MedicationDetails

D62. CT Scan Results


D71. Availability D69. Patient Details

P24Pre-surgical

exam

(Anaesthetist)

D76. PatientMedicalHistory(Tacit)

E11Anaesthetist

D77. PatientMedicalHistory

D78. PatientSurgical Readiness

details

D68. SurgeryRequest

E10Patient

P25Inpatient

Observations

D79. Vital Signs

D80. PatientData

P26Patient

Assessment & Release

D84. AftercareLiterature

& Prescription E12Registrar

D82. Authorisation

D83. Patient Release Details

D86. Prescription

D81. PatientStatus

D91. PBS Record


management practices. Whilst the information is current, the manual nature of data

collection increases the risk of information quality issues e.g. transcription errors. The

interview by the anaesthesia team underlines the criticality of ensuring timely, accurate

and complete information is available to clinical staff. However, there remained a

reliance on the patient’s memory for key information which calls into question the

accuracy and comprehensiveness of the information being provided (D76).

Consequently, relevant ’quality data’ events resulting from previous anaesthesia

episodes are not available to the anaesthesia team (e.g. irregular heart rhythm, drop of

blood pressure). In this context, access to reliable quality data may be considered a

critical antecedent for optimal patient outcomes.

4.5.6 Unscheduled Care Pathway

Figure 4.6. Data flow diagram of information flows associated with an emergency presentation and

subsequent Specialist attendance.

Figure 4.6 depicts the flow of data resulting from an emergency presentation and

the completion of this Patient Journey. The narrative continues one day following

release from hospital, the patient had lost consciousness and was transported to an

Emergency Department (ED) at a hospital closer to his home. On arrival at the ED, he

S18Appointments

P32Patient

AppointmentScheduling


S17Patient

(Hospital 2)

E14Patient

P29Emergency

DepartmentRegistration

D94. Demographic &Medical History

(Tacit)

D95. PatientDetails

P33Consultation

E16Specialist

D106. Confirmation

D110. PatientStatus

D109. Assessment

D101. Event detail

S20eHealth data

Store

P34Record


D112. Medicare Summary

D111. ConsultationSummary

D108. PatientHistory


D103. Availability


P30Tests &

Treatment

D96. Medical History(Tacit)

D97. PatientEvent

Details & Results

P28Triage

Assessment

D92. Vital Signs

D93. PatientData

P31Patient

Assessment & Release

E15Registrar

D99. Authorisation

D100. PatientReleaseDetails

D98. PatientStatus

S19Patient

(Hospital 1)

E14Patient

D107. HealthCondition Details


underwent a triage assessment, (P28) and registration process in order to collect

demographic information and health status (P29:D94). Effective clinical decision

making may have been hampered due to ED staff limited awareness of the patient’s

state of health. As a result, he was subjected to various diagnostic tests, (P30:D97),

underwent treatment for an injury sustained during the fall and was released hours later

after tests revealed no irregularities (P31). He experienced no further health events and

met with the Specialist for a post-surgery follow-up six weeks later where he was

assessed and given the all clear (P33).

An unplanned emergency event brings into sharp focus a reliance on the patient’s

capacity to provide details about pre-existing conditions and demographic information

in emergency scenarios. This is emphasized by poor interoperability between hospital

information systems which limits clinical access to timely and accurate medical

information. Data stores S17 and S19 highlights the cross organizational boundary for

critical information stored in information silos. This perhaps limited the efficiency of

clinical staff in the diagnostic process necessitating potentially unnecessary diagnostic

tests. From an operational perspective, the time and resources required to assess and

treat the patient may have been significantly reduced if access to complete and accurate

medical information was available.

On reflection, the patient was happy with the outcome of the surgery however,

it becomes clear that traditional systems for managing medical information in multi-

disciplinary scenarios is not optimised for continuity of care. The following discussion

examines the implications of these findings for designing eHealth architectures for

seamless sharing of multi-disciplinary information.

4.6 DISCUSSION

The overall picture emerging from the findings suggests that systems which

support information continuity in Australian primary healthcare settings can be

improved, particularly when a patient’s care pathway includes cross-boundary and

cross institutional processes. In which case, a discussion about how and why particular

phenomena emerged from the findings contribute to the identification of solution

objectives (meta-requirements) and normative recommendations (principles)

informing design activities. In this respect, the findings are not an extrapolation that

can be applied to the whole of Australian healthcare but serves as the basis for


designing an artifact to solve a particular problem. Thus, this discussion focuses on

four problem domains identified in the study; (i) clinical workflow integration, (ii)

enhancing clinical decision making, (ii) improving continuity of patient information

and (iv) improving the quality of patient information. Drawing from the work of Price

and Shanks (2005a), the analysis and design of a future state eHealth solution is

influenced by their InfoQual framework. Through this lens, semiotic theory is used to

provide the explanatory power for system design choices.

4.6.1 Clinical Workflow Integration

A frequent observation made by the case study was the level of process

inefficiencies resulted from duplication of effort. A principal cause can be attributed

to the collection of homogenous information by multiple HCPs for processing and

storage in localised data silos (e.g. Figure 4.4 [S7, S8, S9, S11]). Within the scope of

this study, behaviours resulting from manual and hybrid paper based/electronic

processes appear to be entrenched in all clinical settings but more importantly, they

present a potential risk for poor information quality e.g. accuracy, completeness,

consistency and timeliness. Similarly, redundant administrative practices perpetuating

poor process efficiencies and extra costs, particularly in paper to electronic transfer of

information, is common place (e.g. Figure 4.3 [P1, P4, P7]). Underpinning this

behaviour is poor systems integration and the lack of interoperability. This required

patients to supply homogeneous information repeatedly and largely from memory

when engaging with multidisciplinary HCPs. The case study showed evidence that

duplication of administrative effort coupled with an additional layer of administration

imposed by the introduction of the MyHR added to the burden perceived by HCPs.

The following quote from a review of Australia’s MyHR emphasises this view:

“the administrative processes associated with the PCEHR [MyHR] are

‘clunky’ and overly bureaucratic, the process of accessing information from

the record for clinicians can be time consuming, difficult and disruptive to

their normal workflows and very little account was taken of issues relating to

managing the data in practices that is needed to populate the PCEHR

[MyHR]” (Royle, et al., 2013, p. 58).

Regrettably, current interoperability efforts are not concerned with the inherent

nature of healthcare delivery processes (Sadeghi, Benyoucef, & Kuziemsky, 2012).

The MyHR has been designed to improve continuity of care by aggregating a subset


of summarised clinical information using non-value adding processes. The current

focus on the technical aspects of interoperability (data, terminologies, information

models, standards, architypes, messaging, health records, security, etc.) may not be

sufficient to solve the problem at hand. The developers have neglected to consider how

the system can deliver overall health information quality improvements. Sadeghi, et

al. (2012) argue that design for interoperable systems must occur at “all levels of

interoperability such as people, processes and technologies” (p. 59). Therefore, design

choices must consider information system (IS) architectures that effectively support

clinical processes as well as improve the quality and presentation of information.

Similarly, the study provided evidence that the Patient Journey is information

centric with architectural design choices focused on localised collection and storing of

information. Consequently, each discrete care event is typically supported by siloed

information systems which are designed to support internal workflows only (e.g.

Figure 4.3 [S1, S3, S4, S5, S6]). Qualitative studies investigating the patient

perspective indicate that patients have a high expectation for information continuity

(Waibel, et al., 2011). This finding is reflected in the frustration felt by the patient over

the requirement to register his details each time he attended a new HCP. In light of

this, systems must be designed to make information accessible at any point of the care

process. Only then will patients be able to forego the unnecessary practice of repeating

information or tests, leading to more efficient use of time (Nair, Dolovich, Ciliska, &

Lee, 2005; Wong, Watson, Young, & Regan, 2008).

The patient’s journey manifests as a workflow encompassing several internal

workflows used by diverse clinical functions. Taking this into account, information

continuity between care events would benefit from a coherent and integrated process

when a patient’s workflow includes cross-boundary activities. Thus, designing process

oriented architectures that facilitate access to information from discrete care events

linked over time must be a prerequisite. In view of this, the first meta-requirement is

grounded within the InfoQual framework at the pragmatic level. This requires IS

architecture that supports an appropriate level of process interoperability. The aim is

to ensure that information is accessible and presented in a manner appropriate for

clinical use. Information must be understandable, delivered in a way that is consistent

with its use by people and processes. Thus, the meta-requirement may be identified as:


MR1: Technology solutions must align with clinical workflows and achieve an

appropriate level of interoperability to reduce the burden of collecting, managing

and processing patient information.

In order to reduce the administrative burden of collecting and managing patient

information, eHealth solutions must align with clinical workflows to deliver an

appropriate level of workflow interoperability (process integration). This assumes an

evolutionary step is required to supplement the current focus on semantic and syntactic

interoperability efforts. In this way, the following design principle may be defined as:

DP1: Design for optimised continuity of care using technologies that enhance

process interoperability and reduce the administrative burden of collecting and

managing patient information.

4.6.2 Clinical Decision-Making Effectiveness

Balogh, et al. (2016) describe the diagnostic process as a series of tasks that are

contained in and connected by a workflow that may be implicit or explicit. They state:

“a variety of challenges can occur with the tasks and workflow that are

required to make a diagnosis, including problems with the information

(amount, accuracy, completeness, appropriateness), communication issues,

the complexity of the task, a lack of situational awareness, poor workflow

design, interruptions, and inefficiencies.” (p. 127).

From this perspective, presenting heterogeneous information in a coherent and

unified way represents a material opportunity to improve clinical decision making.

Findings from the case study suggests that information associated with the Patient

Journey is fragmented particularly in cross-boundary and cross institutional scenarios.

For example, there was evidence that information required by different HCPs was

grouped and presented in an ad hoc manner, delivered in various formats and was

reliant on multiple electronic and manual transfer methods (e.g. Figure 4.3 [D10, D12,

D18], Figure 4.4 [D32, D40, D43, D45]). At no time was all of the patient’s

information presented in a comprehensive and integrated manner. Consequently, it was

not possible for HCPs to form a central organising picture of his progression through

the care pathway.

According to Balogh, et al. (2016), a well-designed user interface may help

clinicians in the diagnostic process to develop a comprehensive view of a patient’s


condition by presenting a patient’s complete health information in one place.

Therefore, there is a requirement for a method of presenting heterogeneous

information in a coherent and unified way, one that will enable HCPs to construct a

central organising picture for mental model mapping. In this respect, a graphical

representation of accurate and timely information supporting the processes used by

HCPs to collect and analyse data elements represents a significant opportunity as the

source of decision making processes and actions. Atomic processes could be presented

in a graphical user interface to create a context aware composite view of a patient’s

workflow. The view is dynamic as events trigger updates based on the status and

context of clinicians and other information consumers involved in the delivery of care

(Dang, Hedayati, Hampel, & Toklu, 2008).

Creating this in real time if at all is challenging. According to the Institute of

Medicine (IOM), assembling information for contextualized action could facilitate

dynamic real time decision making by reducing the cognitive burden on clinicians

(IOM, 2012). Immediate benefits are achievable with a reduction in unnecessary

duplication of costly and potentially unsafe pathology and imaging tests, processing

errors and inefficiencies in practitioner and patient time (Taylor, Champeaux, & Bruce,

2011). In light of this, access to single, comprehensive, near-real-time sources of

information assembled as personalized clinical workflows will have a positive effect

on clinical decision making. Thus, the second meta-requirement draws from the

InfoQual framework at the pragmatic level. This adopts a consumer-centered

perspective concerned with the degree that information is suitable for a given use.

Focus is on the following aspects: (i) presenting information in an intelligible way,

(i.e. understandable), (ii) information is presented in a way that is appropriate for its

use, (i.e. presentation context) and (iii) information is easily manipulated and the

presentation customised as required (i.e. presentation flexibility).

MR2: The solution must support a logical view of accurate patient information

constructed in real time. Heterogeneous information must be assembled in a

coherent and unified way to form a central organising picture of a patient’s clinical

workflow.

Balogh, et al. (2016) posit that a principal feature of an effective user interface

is simplicity. Similarly, Belden, Grayson, and Barnes (2009) state that simplicity in

design “refers to everything from lack of visual clutter and concise information display


to inclusion of only functionality that is needed to effectively accomplish tasks” (p. 9).

To that end, information should be assembled and presented in the context of a

patient’s individualised workflow. Thus, a second design principle may be defined as:

DP2: Design for intelligent user interfaces that present information in a

manner that reduces cognitive load, increases situational awareness and encourages

collaboration.

4.6.3 Continuity of Care

Retaining data in the form of a longitudinal patient record is a key element of an

effective eHealth program (IOM, 2010). However, the study found that the delivery of

care in clinical silos resulted in inconsistent referral processes and poor visibility of

the information associated with a patient’s progress. In this respect, visibility of a

patient’s entire workflow was typically limited to the patient only (e.g. Figure 4.3 [E1],

Figure 4.4 [E6], Figure 4.5 [E10]), Figure 4.6 [E14]). Information collected and stored

in the MyHR, whilst useful as a summarised timeline of a Patient Journey, lacked the

contextual detail that would add a more nuanced view for information consumers.

Similarly, it was observed that Medicare and PBS records uploaded to the MyHR

provided a précised view of clinical and pharmaceutical events, with limited access to

valuable detailed content.

From a patient safety perspective, a cross-sectional survey of 32 primary

healthcare clinics found that missing clinical information was associated with 15.6%

of reported errors (Smith, Araya-Guerra, Bublitz, & et al., 2005). Whereas, an analysis

of emergency department patients showed that 25% had information stored in the

systems of other hospitals limiting its accessibility (Finnell et al., 2003). Thus, as a key

dimension of an integrated care delivery system, information continuity must be

considered in the design process. Banfield, et al. (2013) postulated that the benefits of

continuity of information can be realised through a reduction in duplication of effort

and improved accessibility by other HCPs. Indeed, according to the World Health

Organisation (WHO), “the key to effective patient information systems is to retain the

link between the individual and the data collected over time and to make those data

available to multiple health care providers when needed” (WHO, 2012, p. 9). In this

respect, longitudinal patient information must be made accessible to all stakeholders

within and external to the system (Oliver-Baxter, Brown, & Bywood, 2013).


This acknowledgement that eHealth systems must be designed to encourage the

availability of patient information across the continuum of care establishes a design

goal for future state systems. The priority is to ensure that an IS can track all patient

encounters at a level of detail that will suit the specific requirements and conditions of

all participating HCPs. Thus, a goal (meta-requirement) is to provide authorised

consumers the means to access a patient’s relevant medical history in real-time from

any location, using any device. Drawing from the InfoQual framework, the focus of a

third meta-requirement addresses two dimensions, (i) completeness which ensures that

every external phenomenon is represented and (ii) timeliness where the age of the

information is appropriate for its use. To achieve this, the meta-requirement may be

identified as:

MR3: The technological solution must provide a means to securely access a

patient’s relevant medical history at any time, from any location using any device.

In order to satisfy the information needs of HCPs in an information-intensive

domain requires a design principle for organising complex and distributed information

systems as a single coherent functional model. As a potential solution, Cloud based

infrastructure permitting secure access to complete longitudinal patient information

shows promise in the following use cases: (i) chronic disease and emergency scenarios,

(ii) where patients are moving between healthcare settings and (iii) engaging with

multiple HCPs and carers. Federated IS architectures utilising intelligent information

services may minimize the impact of interoperability by facilitating access to

information stored by the information creator/owner within an appropriate governance

framework. Thus, the following design principle may be defined as:

DP3: Design for multidisciplinary information seeking and retrieval using

dynamic and distributed information services.

4.6.4 Information Quality

Information quality emerges as a significant causal mechanism influencing

clinical processes and the quality of care. In the United Kingdom (UK) the majority of

general practices process hundreds of patient record transfers each year resulting in a

significant administrative burden as well as increased risk of information quality issues

e.g. transcription errors and omissions (Car et al., 2008). This risk is brought into sharp

focus by a qualitative analysis of error reports made by primary healthcare clinicians


in the United States (US) which identified that 30.9% of errors were due to

administrative failures (Dovey et al., 2002). Considering this, information intensive

processes such as the coordination of care in primary healthcare settings is vulnerable

to missing information which has been linked to adverse clinical events in Australia

and the US (Elder, et al., 2004; Harrison, Gibberd, Hamilton, & Wilson, 1999; Smith,

et al., 2005).

Drawing a connection to Australia’s national I system, the MyHR has been

operationalised as a system designed to address specific information quality

dimensions such as accessibility and continuity. However, the current implementation

fails to consider important quality attributes such as timeliness and accuracy. As

identified by the case study, this is due in part to the current practice of manually

collecting homogenous information for storage in clinical silos. More importantly, the

focus on the physical aggregation of patient information, (i.e. transferring data from

one repository to another) emphasises the risk of information quality issues that were

observed with the UK example.

The case study identified examples of multiple copies of information stored in

multiple locations e.g. patient demographic information, shared health summaries,

specialist letters and consumer-entered notes. This was emphasised when the patient

attended different healthcare providers that required some type of form filling. This

meant that administrative processes associated with localised collection, checking and

entering of information into a clinical system was often duplicated (e.g. Figure 4.3

[D5, D14, D26, D28]). In which case, there was an issue with multiple data repositories

often containing the same information but due to the timing of collection or errors

introduced during data entry, this information might not be consistent between

healthcare providers (e.g. Figure 4.3 [S1, S3, S4, S5, S6]). The synchronisation of this

information emerged as a significant challenge when building a complete picture of a

patient’s current health status. This is emphasised further by the clinician’s reliance on

first‐hand clinical information from trusted sources. Yet, the adoption of a 2nd-hand

data approach by the MyHR threatens to reduce the incremental value of a patient’s

medical history to summarised information and personal comments. In turn, this

reduces the likelihood of time-poor HCPs accessing the information. Particularly when

the majority of HCPs see GP practice management computer systems (PMS) or


hospital clinical information systems (CIS) as the source of the truth for patient

information (ACHI, 2011).

Reorienting current health information systems thinking to the notion of

information creators exposing complete, single source of the truth (SSOT) information

may alleviate many of these challenges. In this context, SSOT information is defined

as the one source of information that is agreed by all stakeholders contains real and

trusted data (Murphy, 2011). This requires a design that structures IS architectures

such that every data element is stored once, all linkages to the data element is by

reference only. Updates are propagated across the enterprise ensuring that data is

referrable, consistent, and authentic (Sanchez, Hampson, & Vaux, 2016). From a

quality perspective, it is reasonable to argue that information sharing with a focus on

SSOT will improve the quality of information. In this respect, the study concluded that

a causal relationship between IS architecture and information quality exist.

Referencing the InfoQual framework, the fourth meta-requirement attempts to address

various information quality dimensions e.g. syntactic, semantic and pragmatic criteria.

In view of this, the technology solution must ensure that information conforms to data

integrity rules as well as deliver information that is unambiguous and timely. Thus, the

meta-requirement is defined as:

MR4. The solution must ensure accurate Single Source of the Truth (SSOT)

patient information is delivered in a timely manner in order to support dynamic real-

time decision making.

As an alternative to traditional data management practices, design efforts must

be founded on the premise that IS architecture is designed to deliver the right

information to the right person at the right time. Establishing Cloud based IS

architecture which enable access to clinical information at their source (e.g. medication

management systems, diagnostic imaging departments, pathology labs, etc.), rather

than run parallel systems which require clinicians to upload patient information, may

build trust that the information is complete, accurate and timely. Similarly, establishing

single source of the truth patient information referenced by a unique identifier should

streamline current clinical practices and reduce administrative burden.

DP4: Design for efficient propagation of high quality single source of the truth

information to facilitate dynamic real-time support of multiple and interdependent

decision makers.


Table 4.1

Meta-requirements and design principles derived from ethnographic study

Problem

Domain Observation Meta-requirement Design Principle

Workflow

Integration

"Clinical workflow inefficiencies were

observed due to duplication of effort with

multiple HCPs collecting the same

information in the same way and storing this

information in internal silos resulting in

duplicated administrative burden and

increased risk of information quality issues."

Technological solutions must align with

clinical workflows and achieve an

appropriate level of interoperability to

reduce the burden of collecting,

managing and processing patient

information.

Design for optimised continuity of

care using technologies that

enhance process interoperability

and reduce the administrative

burden of collecting and managing

patient information.

Clinical

Decision

Making

" At no time was it observed that information

could be presented in a comprehensive and

integrated manner in order to form a central

organising picture of the patient’s journey."

The solution must support a logical view

of accurate patient information

constructed in real time. Heterogeneous

information must be assembled in a

coherent and unified way to form a

central organising picture of a patient’s

clinical workflow.

Design for intelligent user

interfaces that present information

in a way that reduces cognitive

load, increases situational

awareness and encourages

collaboration.


Problem

Domain Observation Meta-requirement Design Principle

Continuity of

Information

"Access to a patient’s complete medical

history in emergency scenarios could have

accelerated the triage process while also

mitigating the requirement for unnecessary

tests."

The technological solution must provide

a means to access a patient’s relevant

medical history at any time, from any

location using any device.

Design for multidisciplinary

information seeking and retrieval

using dynamic and distributed

information services.

Information

Quality

"It was observed that patient information is

fragmented and there is a reliance on the

individual to supply the same information

repeatedly and largely from memory when

engaging with multidisciplinary HC”s."

The solution must ensure accurate

Single Source of the Truth (SSOT)

patient information is delivered in a

timely manner in order to support

dynamic real-time decision making.

Design for efficient propagation of

high quality single source of the

truth information to facilitate

dynamic real-time support of

multiple and interdependent

decision makers.


Table 4.1 summarises four solution objectives (meta-requirements) based on findings

from the case study. Clear arguments of why the objectives hold significance in the

context of the Patient Journey have been offered. Similarly, the requirements for a

suitable technological response have been synthesised and design principles derived

from a mix of practitioner experience and academic theory. Thus, it is theorised that

propagating clinical information using a service-based architectural pattern will

optimise information quality.

4.7 CONCLUSION

As part of the problem identification and definition phase of a DSR approach,

an ethnographic analysis adopted an end to end, cross domain view of a patient’s

journey within the Australian healthcare system. Findings from the study identified

information quality, clinical process inefficiencies and system interoperability as

mainstream issues associated with information management practice in cross boundary

and cross institutional scenarios. In this respect, the findings correspond to themes

emerging from extant research studies examining care pathways in the United States

and England. This increased confidence that the four identified problem domains

represent a consistent view of the issues associated with information flows in different

healthcare settings.

It was concluded that a plausible causal relationship exists between eHealth

architecture and information quality. Therefore, consideration must be given to

information quality dimensions that are relevant for supporting this goal. More

importantly, designing systems that link discrete elements of a patient’s information

flow over time must be considered a prerequisite for effective continuity of care. In

light of this, eHealth solutions must be flexible enough to permit architectural

innovation on a structural level while remaining malleable enough to accommodate

the emergent and complex nature of the Patient Journey. Taking this into account,

meta-requirements for an eHealth solution were synthesized and normative design

principles specifying the characteristics satisfying these requirements were derived

and grounded in key concepts from semiotic theory.

The next chapter presents an applied example of an IT artifact designed to

achieve these solution goals. The objective is to construct eHealth-as-a-Service as an

example of a set of design and architectural concepts supporting the theory that


propagating clinical information using a service-based architecture will deliver

information quality improvements.

Chapter 5: Artifact Design 91

Chapter 5: Artifact Design

5.1 INTRODUCTION

The aim of this chapter is to present a practical example of how a set of

architectural patterns and applications deployed using the eHealth-as-a-Service

(eHaaS) conceptual model will optimise information flows in cross domain scenarios.

Representative of the design phase of the design science research process, a key

outcome of this chapter is a testable proposition asserting the relationship between

eHealth architecture and information quality. To achieve this, an electronic patient

information management system (ePIMS) is presented as an instantiation of the eHaaS

design artifact offering a novel solution for assembling heterogenous clinical

information as personalised patient workflows.

5.1.1 Contributions

Contributions made by this chapter include:

• Conceptualization of an eHealth-as-a-Service design artifact comprising a

set of design principles, architectural patterns, service-based applications

and implementation strategy.

• An applied perspective of how an eHaaS design artifact might be

implemented. This will demonstrate the efficacy of process oriented,

service-based architecture for delivering measurable information quality

improvements.

• Business processes modelling of clinical consultation and specimen analysis

scenarios advances knowledge about the process implications of

operationalizing the eHaaS design artifact.

• A novel method for efficient assembly of clinical information as

personalised patient workflows establishes a compelling use case for eHaaS

architecture.

5.1.2 Background

A review of the literature in Chapter 2 consolidated understanding about national

and international eHealth systems at the architectural level. Technical concepts

92 Chapter 5: Artifact Design

considered important for the creation of the eHaaS design artifact were identified

providing the scaffolding for this phase of the design process. In order to provide the

structure and functionality necessary to support complex multidisciplinary scenarios,

microservices in conjunction with domain-driven design principles was offered as a

suitable event-driven architecture pattern. At the process level, Chapter 4 provided a

micro view of the challenges associated with information management practice in

primary healthcare settings, identifying information quality as an overarching goal for

design activities. Meta-requirements and design principles were synthesized from the

findings of an ethnographic study and grounded in semiotic theory to establish a bridge

between information systems design and information quality. As the second phase of

the case study, this chapter draws these concepts together to construct an eHaaS design

artifact and demonstrate it in context e.g. a clinical consultation and pathology analysis

scenario.

The chapter commences by providing a high-level conceptualization of the

eHaaS design artifact. Architecture patterns and concepts are presented and mapped to

meta-requirements synthesized in Chapter 4. Section 5.3 demonstrates how a

microservices architectural pattern and domain-driven design concepts may be applied

to instantiate the eHaaS design artifact as an electronic patient information

management system (ePIMS). This provides a practical example for the use of eHaaS

application services. Section 5.4 presents a case study comparing ePIMS with the

Australian national EHR system (MyHR) by presenting process models describing a

clinical consultation and pathology specimen processing scenarios. BPMN is used to

illustrate the processes associated with these system architectures in order to examine

the influence of eHaaS concepts on clinical processes. Section 5.5 discusses key

differences between the process models and investigates whether the eHaaS design

artifact satisfies the meta-requirements summarised in Table 5.1.

Findings from this phase of the study were included in the researcher’s published

paper: Black, A. S., & Sahama, T. (2014). eHealth-as-a-Service (eHaaS): The

Industrialization of Health Information Technology, a Practical Approach. In 16th

International Conference on E-health Networking, Application & Ser–ices - IEEE

Hea’thcom'14, (Black & Sahama, 2014).


5.2 EHEALTH-AS-A-SERVICE CONCEPTUALIZED

As a conceptual model, eHealth-as-a-Service is defined as a set of design

principles, architectural patterns, service-based applications and implementation

strategies. In this respect, eHaaS architecture patterns, processes and services were

informed by, and is consistent with, general constructs used within Enterprise

Architecture (EA) frameworks. Whilst several frameworks and a variety of process

models have been proposed for EA, the intent of this thesis is not to create a new

framework nor follow the conventions, principles or practices established for any

particular EA framework. Indeed, the mapping of relations between eHaaS and EA

concepts is by no means complete as this is not possible in the scope of a single PhD.

However, in order to conceptualize and evaluate a design artifact and its processes, it

is necessary to identify key elements of the proposed solution and the underlying

rationale for their selection. To this end, several themes were synthesized from

Australian and international experiences in the creation of national-scale eHealth

programs. Structural and behavioural concepts in the form of solution space,

implementation approach, technical architecture and applications/integration

architecture were identified to frame the conceptualization of the eHaaS design

artifact. Coupled with the meta-requirements and design principles derived in Chapter

4, it is possible to provide a high-level meta-description describing the structure,

organization, and functioning of the eHaaS design artifact.

5.2.1 A Meta-Description of eHaaS

First and foremost, eHaaS has been designed around care pathways (the Patient

Journey). Unlike existing national-scale eHealth programs where development appears

to be function based and influenced by the structure of the healthcare model, the

premise and a key point of difference for eHaaS is its support for the fluid nature of a

patient’s journey. Based on the notion that the Patient Journey serves as a central

organising mechanism for orchestrating relevant information services, an eHaaS

solution seeks to offer dynamic composition of discreet process-driven application

services. In this respect, eHaaS may be viewed as a unique combination of concepts

from three perspectives: (i) design approach, (ii) technical architectures and (iii)

implementation strategy.


(i) Design Approach

From a design perspective, as with real-life problems, the design of large scale

eHealth solutions must begin with the notion of an expanded problem domain.

Particularly in healthcare where events may occur as a function of known patterns or

as a response to the patient’s state of health. In this context, solutions require a design

sensibility that encourages designers to decompose dynamic care pathways into more

understandable and manageable pieces and deliver each piece as independent service

applications. Well-suited is the Domain-Driven Design (DDD) philosophy introduced

by Evans (2003) which is a mindset focused on accelerating software projects within

complex domains. DDD consists of a set of patterns for developing enterprise

applications based on a domain model making it possible to generalise and extend

eHaaS architecture to ensure alignment with different clinical priorities and business

strategies. At the project level, the fundamental reason eHaaS is being created and its

principal advantage over other eHealth systems is to improve the coordination of care

as a patient navigates the continuum of care. This core domain was examined in

Chapter 4 Section 4.6 and solution objectives derived in order to create models to solve

the problem. To demonstrate the DDD approach, many of the strategic, tactical and

technical aspects are described in the development of an electronic patient information

management system in Section 5.3.

(ii) Technical Architectures

Meta-requirements summarised in Table 5.1. focus on clinical workflow

integration, intelligent presentation of heterogenous information and improved access

to high quality clinical information which requires a unique set of technologies. To

this end, eHaaS incorporates several inter-related technology strategies and concepts

which encompass service-based computing, event driven architecture, context aware

federated architecture and context aware composition of services. Whilst these

concepts are discussed in Chapter 2, it is useful to relate them to the meta-requirements

in order to establish the rationale for design choices made in the conceptualization of

an eHaaS design artifact.

Meta-requirement MR1 requires Information System (IS) architecture that

supports an appropriate level of process interoperability to ensure that information is

accessible and presented in a manner relevant to the context of its use by people and

processes. This can be satisfied by adopting an architecture pattern that supports


interaction with clinical information as a view of a patient’s cross-organizational

workflow. One method is the merging of patient workflows crossing organizational

boundaries where collaboration between organizations occur without their full

knowledge of the structure of each other’s processes and without exposing confidential

data.

Table 5.1

Meta-requirements derived from ethnographic study conducted in Chapter 4

Code Meta-requirement

MR1 Technological solutions must align with clinical workflows and achieve an

appropriate level of interoperability to reduce the burden of collecting,

managing and processing clinical information.

MR2 The solution must support a logical view of accurate clinical information

constructed in real time. Heterogeneous information must be assembled in a

coherent and unified way to form a central organizing picture of a patient’s

clinical workflow.

MR3 The technological solution must provide a means to access a patient’s relevant

medical history at any time, from any location using any device.

MR4 The solution must ensure accurate Single Source of the Truth (SSOT) clinical

information is delivered in a timely manner in order to support dynamic real-

time decision making.

Drawing inspiration from the work of Xu (2014), Figure 5.1 illustrates a general

framework for view-based process modelling. An extracted clinical process-view,

which is an aggregate abstraction of a base process, is viewed as an external interface

of the internal process. In this way, the interface can be adapted to suit the specific

needs of the collaborating clinician. For example, a clinician might be required to work

with a wide variety of information related to an individual’s health condition: patient

history, pathology test results, ultrasounds, CT Scans, medication information and so

on. Using this approach, clinical information can be accessed and tracked by extracted

processes in the form of individual application services.


Figure 5.1. Architecture of cross-organizational workflow view.

However, to improve efficiency, clinicians participating in a patient’s inter-

organizational workflow are better served if each of these functions were integrated

into a single application. This becomes a significant challenge due to the emergent

nature of a patient’s journey. In this context, choice of component information services

and functionalities are influenced by the patient’s condition and the clinician’s

environment, objectives, constraints and personal preferences. To accommodate this

and satisfy meta-requirement MR2 which focuses on a consumer-centered

presentation of information assembled in a unified and logical way, context-aware

composition and execution of services emerges as an important characteristic of

eHaaS. Taking guidance from the works of Bucchiarone, Marconi, Pistore, and Raik

(2017) and Zhou et al. (2011), eHaaS design is based on the notion that business

processes are refined during execution within an actual operational context rather than

hard-coded at design time. As a key point of difference, eHaaS service composition is

characterised by the automatic composition of existing services provided by other

systems according to the context is which they are executed.

This requires an enabling technology characterised by just in time, scalable and

elastic behaviours which are also necessary for other meta-requirements. For example,

meta-requirement MR3 specifies that the solution must provide a means to securely

access a patient’s relevant medical history at any time, from any location using any

device. To achieve this, eHaaS adopts a service centric approach using Cloud

technologies. This allows eHaaS to contextualize its usage where information

dynamically behaves according to clinical functionality. Relying on distributed

architectures eHaaS offers significant benefits over n-tier and monolithic architectures.

This is because distributed architectures encourage modularity which is the notion of

encapsulating components of an application in self-contained services. These services

Organisation 2

Interface

Internal Process

Integrated Process

Clinical System

2

ClinicalData

Organisation 1

Internal Process

Integrated Process

Clinical System

1

Interface

ClinicalData

Meta-DatabaseTask {…}

Workflow {…}Extracted

Process

(Microservice)

Extracted

Process

(Microservice)


can be individually designed, constructed, and implemented with minimal dependency

on other components in the application. Each service has its own set of responsibilities,

autonomous of other services, but linked to services through an Application

Programming Interface (API). In this way, application, processes and information

consumed ‘as a service’ may be aligned with individual care pathways. To this effect,

the Microservices architecture pattern emerges as well suited for an eHaaS solution.

The architecture takes the form of light-weight collaborating services developed and

deployed independently of each other with each service implementing a set of related

functions which can be accessed by multiple devices.

Hypothetically, adoption of micro-services in this context is centered on the

notion that a shift away from data-centric monolithic architecture to process oriented

application services will have a positive effect on information quality. This leads to

meta-requirement MR4. Its focus is on information quality and the requirement for

accurate information to be delivered in a timely manner from a single source. As

illustrated in Figure 5.2, by adopting a context-aware federated architecture model,

information from care events and consumer entered data can be made accessible

beyond the typical clinical silo. Patient identification is centralized and automated

across systems with notifications sent to clinicians about the presence of data.

Similarly, the architecture accommodates clinical context messaging in order to

maintain the context of the clinician and patient within different systems. This

manifests as event metadata which is generated by a patient’s workflow and is hosted

centrally. Clinical systems contain their own data component of the patient’s workflow

to ensure information is the only ‘source of the truth’.

Event-driven architecture which is by design more normalised for asynchronous

processing in unpredictable environments was identified as a natural fit for eHaaS.

Event-driven architecture (EDA) is an architecture pattern encouraging the production,

detection, consumption of, and reaction to events (Vernon, 2013). Figure 5.2 provides

a high-level view of an eHaaS event-driven architecture and illustrates how all

activities associated with a patient’s journey is captured as a stream of events. By

using temporal queries, it is possible to replay a sequence of events for any part of the

patient’s history providing a valuable tool for analysing a patient’s condition

(Chatterjee, 2012). The events become the system of record and can be processed by

different healthcare professionals based on the use case and permissions.


Figure 5.2. eHaaS event-driven architecture.

Context Aware Federated Model

Systems LevelEvents

Event-driven architectureContext Aware Federated Model

Systems LevelEvents

Personal Health Record

Healthcare Provider and Patient Portal

Services

Service Broker

Clinical Records Repository

Clinical WorkflowServices

Pharmaceutical Records Repository

Medication Information

Services

EventIDX

PACS Repository

Diagnostic Imaging Services

Diagnostic SupportServices Pathology Records

Repository

Hospital Records Repository

Patient Information Services

Temporal Query

Event Stream

Diagnostic support Systems

Diagnostic Imaging Systems

Event Metadata

Event Metadata

Event Metadata

Event Metadata

Event Metadata

Event Metadata

HospitalSurgical Systems

ClinicalSystems

Pharma-

ceutical

WorkflowIDX

TaskIDX

Patient Portals

Collects and replays information for events as streams.


Data lineage is also preserved because data is never deleted providing an

immutable log for each data change. These important concepts are appearing in other

domains for example supply chain systems, eCommerce and crypto-currency (i.e.

blockchain networks). Section 5.3.2 demonstrates how ‘Event Sourcing’ offers a

suitable strategy for ensuring that any changes to application state are persisted as a

sequence of ordered events. Thus, an append-only store becomes an authoritative data

source representing the current state of clinical information.

(iii) Implementation Strategy

From an implementation perspective, adoption of an outside-in approach was

discussed in Chapter 2 as an alternative to traditional eHealth implementation

strategies. This is where service providers use a utility consumption model to offer

application services based on the individual needs of the clinician. By encapsulating

eHealth tools in a utility consumption model for the provision of infrastructure and

applications ‘as a service’ introduces a high level of technological agility to the process

of coordinating care, emphasizing the adaptability of eHaaS for any given scenario.

Figure 5.3 illustrates how eHaaS might be implemented to deliver a set of sophisticated

technologies within a service-based model. In fact, several models may be defined, for

example Platform-as-a-Service (PaaS) (1) in the form of mobile application tools, data

analytic tools, development tools and hosting services; Infrastructure-as-a-Service

(IaaS) (2) providing hosting for private/hybrid Cloud networks and data centres;

archival services (3) for long term storage of large amounts of clinical data in the

Cloud; and Software-as-a-Service (SaaS) (4) for the deployment of many types of

healthcare applications including scheduling, healthcare provider directories,

diagnostic, telehealth and decision support services. This translates into the

development of microservices (5) for supporting inter-organizational clinical

processes that are managed “outside in” by Service Providers. With this approach,

eHaaS focuses on the collaboration and integration of healthcare institutions using

context aware federated (6) and event driven architectures (7). This allows healthcare

providers to access a multitude of services and applications for clinical decision

support in the context of a patient’s journey.


Figure 5.3. Implementation model describing eHaaS as the delivery of a set of sophisticated technologies within a service-based model.

Clinician’s Context Aware

Composite View

Patient’s Summarised View

Care Event Details

Consumer entered information

Healthcare providers

Individuals and their

representatives

Care Team

Clinical systems may use eHaaS

applications and/or infrastructure

Individuals and their

representatives

Infrastructure as a Service (IaaS)

Data Centers

Private/Hybrid Cloud Network

Patient MetadataRepository

Platform as a Service (PaaS)

Hosting Services

Data Analytics

Tools

Develop-ment Tools

Mobile App

Tools

Archival Services

Diagnostic Tests

Archive

Imaging Archive Pathology

ArchivePrescription

Archive

Software as a Service (SaaS)

Scheduling Services

PCEHR

Decision Support Services

Telehealth Services

Diagnostic Services

Directory Services

Multidisciplinary Healthcare eHR

systems, & Insurance information

Personal Health

Records

Medicare Repository

Pharma

Clinical

Diagnostic

Delivered as Micro-services

Service Provider

Context aware federated

architectures

Utility consumption model using an “outside in” approach

eHealth-as-a-Service (eHaaS)

Event driven architecture

1

2

3

4

56

7


This meta-description is intended to provide an abstract “blueprint” or

architecture describing the eHaaS design artifact. The following sections demonstrates

these concepts in context with the description of a patient information management

system. However, rather than design a complete system, the intention is to provide

practical examples for how microservices architecture using a DDD design philosophy

may be applied to address the meta-requirements identified in Chapter 4.

5.3 DESIGNING AN ELECTRONIC PATIENT INFORMATION

MANAGEMENT SYSTEM

eHaaS is a conceptual model defined as a set of design principles, architectural

patterns, service-based applications and implementation strategies. Based on identified

meta-requirements and design principles, eHaaS has been designed around care

pathways (the patient journey), predicated on the notion that the patient journey serves

as a central organizing mechanism for orchestrating relevant information services.

Thus, the eHaaS solution seeks to offer dynamic composition of discreet process-

driven application services. To demonstrate eHaaS concepts, ePIMS is an electronic

patient information management system presented as an example of how an eHaaS

design artifact might be implemented in a clinical consultation and pathology analysis

scenario. The principal purpose for ePIMS is to assemble information services as

personalised workflows in order to support shared decision making in cross-domain

care settings.

5.3.1 A Design Approach

With a focus on improving the coordination of care, a significant design

challenge is nonlinear process flows and the requirement for dynamic component

information services associated with a patient’s workflow. To overcome this, adoption

of concepts used in DDD encourages a ubiquity in approach and vocabulary for

distilling a complex problem domain in order to create models. In this respect, ePIMS

must accommodate a dynamic combination of components and sub-systems (extracted

clinical process-views), all of which form an essential part of the care giving process.

As an important construct in DDD, a model has context which is implicitly defined

within a subdomain. Therefore, multiple models must accommodate many domain

concepts and perform many clinical use cases. In complex scenarios such as the

patient’s journey, the bounded context defines the applicability of a model naturally.

It offers a method for decomposing complex systems into their constituent parts and


to explicitly establish their interrelationships. Thus, a large system is composed of

multiple bounded contexts containing shared and unrelated objects and functions.

5.3.2 Establishing the ePIMS Domain Model

In the context of the Patient Journey, the patient emerges as a domain concept

that can be applied to a specific context as a means to decompose and organise the

problem space. Figure 5.4 shows the bounded context as strategic patterns designed to

integrate discrete care events represented by the dotted circles. The Patient domain

model represented by the solid ellipse is a smaller, focused concept within its own

context. As an example, when referencing a patient in the context of the pathology

subdomain, they are not referred to as a patient requiring a pathology test, it is a patient

in a defined context. In this way, the context defines the responsibility of the model.

From a systems perspective, bounded contexts typically take care of its own

presentation, domain logic and persistence responsibilities with communication

between different bounded contexts occurring by raising events.

Figure 5.4. A simplified example of the ‘Patient Journey’ establishing the patient domain model

within its own context. Adapted from Millett and Tune (2015).

Several of the many bounded contexts available with ePIMS have been defined

for this example. They include the workflow management bounded context,

appointment booking bounded context and practitioner order management bounded

context. It is noteworthy that additional bounded contexts can be added as required

emphasizing the versatility of eHaaS architecture. In fact, a key value proposition for

Domain Conceptsin Context

Domain ModelGeneral Practice

Context

Patient PathologyContext

Patient

SpecialistContext

Patient

Diagnostic ImagingContext

Patient

In-patientContext

Patient


ePIMS is its capacity to dynamically orchestrate information services associated with

a patient’s clinical workflow.

On this point, the workflow management bounded context is central to the

functionality of ePIMS. Accordingly, a clinician can create and manage personalized

clinical workflows to optimise coordination of care. After creation, details of the

workflow can be accessed by authorised users using the identifier eFlowID to view

detailed information about related tasks. A query of the event store using Workflow

ID, task ID and the clinician’s identifier populates a ‘TaskDetails’ aggregate.

Aggregates permit the decomposition of the domain model into manageable

components. Figure 5.5 demonstrates how this would be applied using the ePIMS

domain model which comprise aggregates such as Workflow, Patient and Provider.

The Workflow aggregate includes a Workflow root entity with various value objects

including SubscriberList, ScheduleInfo and one or more Tasks value objects. The

Patient aggregate consisting of a Patient root entity includes the SubscriberList value

object whereas the Provider aggregate consists of a Provider root entity and includes

the ScheduleInfo value object. In this way, aggregates provide units of persistence and

a way of enforcing consistency boundaries in the context of domain concepts.

Figure 5.5 . Workflow and Patient Aggregates.

5.3.3 Adopting an Event Driven Approach for ePIMS

When an aggregate instance undergoes a state change as a result of processing a

command, the new state of the instance is persisted to a store. Aggregates in the domain

model raise events to publish information about its state to subscribers, such as other

aggregates, bounded contexts or process managers. An event is considered an

historical object and is immutable, meaning that once it is appended to the event log it

WorkFlow Service

WorkFlow Aggregate

SubscriberList

Patient Service

Patient Aggregate

Appointment Service

Provider Aggregate

WorkFlow

PatientID

WorkFlowStatus

TaskItem

TaskType

Patient

...

Task

DemographicInfo

Provider

ProviderID

ScheduleInfoScheduleInfo

SubscriberList


cannot be re-ordered or removed. Consequently, the event store is central to event-

sourced microsystems behaving like the Message Broker. In this fashion, events are

one-way messages with a single source that publishes the event but may have one or

more subscribers as recipients. (Betts, Domínguez, Melnik, Simonazzi, &

Subramanian, 2012). Event parameters include additional information and describe

business intent e.g. “John required a pathology test”. As a vital feature of ePIMS it is

necessary to capture a complete record of the care events in a patient’s journey. In this

context care events require an event sourcing mechanism that can be used to

reconstruct the state of a patient’s history at any moment in time. Event Sourcing (ES)

is a strategy that simplifies persistence permitting the capture of concepts with

complex behavioural properties (Vernon, 2013). This approach achieves atomicity by

drawing from concepts used in database transaction logs as a method for persisting

events in microservices architecture. In this way, ES represents the state of an

aggregate as a sequence of ordered events that have occurred since it was created.

According to Bastani (2016) key benefits for event sourcing in a microservices

architecture are: (i) it establishes an audit trail that can be replayed to reconstruct an

object’s current state; (ii) utilises event stream processing technologies which include

event visualization, event-driven middleware, and event processing languages; (iii)

mitigates complex synchronisation between microservices enabling asynchronous

non-blocking operations between microservices and (iv) enables temporal querying in

order to determine the state of an application at any point in time.

Figure 5.6. Event sequence using the ePIMS example.

A central concept of event sourcing is ensuring that all state changes are persisted

as an event object and stored as a sequence of events as shown in Figure 5.6. Events

representing state changes associated with a patient’s workflow are stored as a stream

eFlow ID 23456

WorkflowService

eHaaSServices

PathologyTestRequest

PathologyResult

ShortConsultationGP

...

WorkflowCreated

Subscribe to events

Add eventFind event

Event Store

ShortConsultationGP


of events by the workflow service e.g. WorkflowCreated, ShortConsultationGP,

PathologyTestRequest and so on. Thus, temporal queries are possible by replaying the

sequence of events to determine the state and the originating activity for any part of

the patient’s history. To ensure compatibility with event-sourcing, aggregates have to

be able to determine their state by applying a sequence of events. The benefit of this is

that aggregates are more behaviour oriented (Millett & Tune, 2015).

5.3.4 A Context Aware Federated Approach for ePIMS

A major challenge when implementing ES with context aware federated

architectures is the use of efficient queries. Consider an SQL query for completed

tasks associated with a patient’s workflow. In practical terms, the query will require a

join of the Workflow and Task tables. However, joins are not possible with

microservices architecture due to the ownership of tables by multiple services

(Richardson, 2017). The Command Query Responsibility Segregation (CQRS)

architectural pattern offers an elegant alternative by separating the responsibility for

updating and querying application data with a write model and a read model. This

simplifies the code using Martin’s (2003) single-responsibility principle by assigning

responsibility for either updating data or querying data with different sets of objects.

When making changes to the data, the user interface (UI) of applications utilising

a CQRS approach send commands instead of the traditional data-centric data transfer

object (DTO). Commands are behaviour-centric representing operations in the domain

which encapsulate a user’s intent more effectively than DTOs (Betts, et al., 2012). The

API gateway acts as a router of representational state transfer (REST) requests to the

backend servers and communicates events using WebSocket messages. The Workflow

and Task command side services manage requests, (e.g. HTTP POST, PUT and

DELETE), to create and update the Workflows and Tasks aggregates. Whereas, the

Workflow and Task query side services manage query requests (e.g. HTTP GET) and

maintain a materialised view of the respective Workflow and Task events.

The usefulness of CQRS becomes apparent when used with the bounded

contexts described in this section. As an example, Figure 5.7 illustrates the use of the

CQRS pattern deployed as a microservices architecture pattern. The UI uses a Model–

View–Controller (MVC) pattern which divides an application into three

interconnected components. This effectively separates the representation of

information from user input and the consumption of information. The increasing


ubiquity of client-side JavaScript used in web applications is driving demand for more

robust JavaScript-based web applications resulting in the emergence of MVC

frameworks.

Figure 5.7. Simplified ePIMS Server example using microservices architecture.

5.3.5 A Context Aware Composite View with the ePIMS User Interface

An important benefit of CQRS is the notion that user interfaces associated with

a bounded context can be incorporated in a single application providing a single

context aware composite view of all parts of the problem domain (Dahan, 2009).

Commands attached to domain operations are issued from the UI which are designed

to determine the user’s intent from their actions. Capturing a user’s intent in a

command simplifies construction of intuitive and natural UIs which use concepts of

the domain that users already understand. The design of the UI focuses on guiding

users through a process based on how users want to use the application.

Figure 5.8 demonstrates this design sensibility by presenting an implementation

of a deliberately simplified UI flow associated with the clinician accessing a patient’s

Workflow command-side service

Task command-side service

Task query-side service

Workflow query-side service

API Gateway

Browser

RESTAPI

WebSocket

STOMPAPI

Event Store

Task 67890

CreatedDatestamp

OrdReqID

ProviderID

WorkflowID

...

WorkFlow 12345

CreatedDatestamp

ProviderID

PatientID

...

Meta-DatabaseTask {…}

Workflow {…}

WebSocket Gateway

RESTProxy

RESTAPI

RESTAPI

RESTAPI

RESTAPI

RESTAPI

WorkflowService

<<aggregate>>Workflow

TaskService

<<aggregate>>Task

WorkflowQueryService

Workflow eventhandler

Workflow Updateservice

TaskQueryService

Task eventhandler

TaskUpdateservice

JavaScript ‘MVC’ framework

Status


workflow to view the results from a radiology task. In this example, the results take

the form of an ultrasound image and radiology report. The first screen populates a list

of tasks associated with the workflow by transferring data from the backend to the UI.

Selecting a task will take the user to the second screen which displays the details of

the clinical task with links to the results. The system is able to redirect the user to the

radiology provider enabling access to the ultrasound images by utilising the

functionality of a browser based viewer. Taking advantage of the functionality coupled

with the information, users are able to add additional notes if necessary. The intent of

the user is clear, and the system is able to guide them through the process of accessing

the patient’s ultrasound image. Commands representing the user’s intent are simple to

construct with this style of interface, for example the entry of user comments is

delivered by the UpdateNotes functionality located in the ‘Access results content’

screen in Figure 5.8.

Figure 5.8. Example of ePIMS task-based UI flow associated with the clinician accessing a patient’s

workflow to view the results from a radiology task.

The application of DDD techniques to the design and implementation of ePIMS

has many benefits, particularly in the distillation and modelling of very complex

Workflow• Workflow ID• Name• Description• Date created• Status

Select clinical task

Clinical Content• Task ID• Date created• Modality

Task• Task ID• Name• Description• Required by date

• Status• Creator ID

• Content access

Patient Workflow Clinical tasks for this workflow

Back Open task

Show clinical task details

Patient WorkflowDetails of clinical task

Select results

Back View results

Results available for viewing

Patient WorkflowAccess results content

BackReturn to workflow

Data retrieved using a query

OpenContent• Task ID• SourceID• Content API



Send command

Show results

Enter notes

Leave a comment

UpdateNotes• Task ID• User ID• Notes

Send Command


domain logic. Better systems design, more reliable/maintainable solutions and

improved user experience are seen as the direct result of this approach. However,

ePIMS represents just one example of how an eHaaS design artifact is instantiated to

satisfy the meta-requirements listed in Table 5.1. What is important here is the

opportunity to automatically compose existing services provided by other systems

according to the context in which they are executed. This highlights a generalisability

for the application of eHaaS architecture not available with current eHealth

implementations. In this respect, eHaaS architecture represents an evolutionary step

forward in the way eHealth technologies are implemented and consumed.

5.4 CASE STUDY

Whilst the examples in previous sections provide a simplified overview of

architectural concepts associated with an eHaaS design artifact, it is useful to

demonstrate the design in context. This section describes how an eHaaS conceptual

model is operationalised to support collaborative decision making at the point of care.

As a comparison, this case study brings into sharp focus key differences between

eHaaS processes and extant clinical processes in Australian primary healthcare

settings. Utilising BPMN (OMG, 2008), models were created to document processes

observed with three architectural configurations. This provides a process modelling

lens in which to compare and contrast the influence eHaaS architectural concepts on

clinical processes. System actors examined in this section comprise: (i) the traditional

healthcare information system (CSHIS) which is largely paper based, (ii) Australia’s

national EHR system (MyHR) and (iii) ePIMS, as an instantiation of eHaaS service-

based architecture.

5.4.1 Case Study Methodology

When constructing the business process models, it was necessary to define the

boundaries of this study to ensure that the models are tractable and easily accessible

by the reader. Care was taken to ensure the size of the boundary was large enough to

examine the utility of the design product but not too broad as to lose sight of the reason

for the analysis.

BPMN is an ideal candidate for expressing service-based architecture concepts

due to its process-centricity. Moreover, BPMNs well defined translation into WS-

BPEL achieves a high degree of automation as executable service-based processes


(WS-BPEL Coalition, 2004). This is particularly useful for documenting internal

processes associated with application programming interfaces in order to clearly define

the services, interconnections and their dynamic and static dependencies. A principal

driver for the selection of BPMN is its accessibility to both technical and clinical

observers. As a standard for business process modelling, BPMN provides a common

vocabulary and graphical representation for documenting clinical workflows. Whilst

BPMN is yet to gain broad adoption in the modelling of clinical processes, the method

has been applied with some degree of success in the health sector (Martinho, Rijo, &

Nunes, 2015; Rolón, García, Ruíz, Piattini, & Calahorra, 2010). As a practical case

study, this novel application of BPMN techniques provides a suitable vocabulary for

arguing the utility of an eHaaS design artifact.

The case study has been organised in two parts to provide a clear comparison of

the existing system (Part A) and the proposed new system (Part B). Part A presents a

scenario describing a clinical consultation and pathology episode drawn from an

ethnographic study conducted in 2014 and discussed at length in Chapter 4 (Black &

Sahama, 2016). The narrative provides insights into CSHIS and MyHR processes

which served as reference for designing ePIMS features and functionality.

Assumptions made about process tasks and roles were supplemented by information

obtained from guidelines published by peak healthcare industry bodies, National

eHealth Transition Authority (NEHTA) specification documents and clinical

documentation. Due to many common tasks, MyHR features and functions were

encapsulated within the CSHIS business process models and presented together. In

order to differentiate the two process models, activities associated with the MyHR are

depicted as shaded objects for emphasis. These models serve as an analogue for

highlighting procedural differences associated with the eHaaS artifact whose processes

are explained in Part B. The processes and roles associated with the eHaaS artifact was

based on event-driven architectural patterns and implementation methods discussed in

Chapter 2.

5.4.2 Process Actors

The following sub-section describes the actors and roles within the clinical

consultation and pathology episode domain.

Current State Health Information System (CSHIS)


CSHIS is a system actor that may be considered the traditional semi-digitalized

or hybrid paper based/computerized systems in common use within Australian

healthcare. CSHIS embodies tasks characteristic of healthcare professionals (HCP)

whose systems are not integrated with the national eHealth system.

My Health Record (MyHR)

MyHR, as a system actor, supports the centralised online storage of electronic

health records (EHR) to support clinicians in the provision of care. Also referred to as

personally controlled health record (PCEHR) and shared electronic health record

(SEHR). MyHR processes offer a hybridised configuration of activities and roles that

extend the traditional CSHIS by incorporating Cloud based features and functionality

operationalised by Australia’s national EHR system.

Electronic Patient Information System (ePIMS)

As an instantiation of the eHaaS design artifact, ePIMS is a system actor using a

Cloud based solution based on domain-driven design principles. Microservices

architecture establishes the foundations for an approach to assembling clinical

information as personalised patient workflows. Its purpose is to provide support for

dynamic cross-domain processes by improving information quality.

Clinical Information System (CIS)

The clinical information system is a system actor that supports clinicians in the

provision of care. Also referred to as Electronic Medical Record (EMR) system or GP

Desktop Software.

Laboratory Information System (LIS)

The laboratory information system is a system actor that supports pathologists

and laboratory workers in the provision of pathology services.

Authorised User

A human actor who is authorised to access information located within

computerised systems.

Individual

A human actor seeking medical support to address a health-related condition.

Clinician


A human actor qualified in a medical specialty participating in the role of HCP

providing care to an individual.

Reception

Human actors participating in the role of administrative support. They interact

with the information systems and provide support for clinical logistics, scheduling,

information management and financial management activities.

Laboratory Worker

A human actor who performs and reviews results of pathology investigations

and interacts with the LIS to access and store pathology related information. May be

authorised to create and send pathology result reports.

Pathologist

A human actor qualified in a medical specialty who performs, and reviews

results of pathology investigations and interacts with the LIS to access and store

information related to the pathology domain. The pathologist is authorised to create

and send pathology result reports.

Requester

A human actor participating in the role of clinician who has requested pathology

investigations to be used in the clinical care of an individual.

5.4.3 Part A: Processes Associated with CSHIS and MyHR System Actors

A typical set of activities resulting from an individual’s self-referral to a clinician

and the subsequent interaction with pathology services was considered an appropriate

domain view for making a meaningful comparison. Diagrams show the high-level

activities and inter-relationships between entities that constitute Part A scenarios. In

acknowledgement of the evolving maturity of Australia’s national EHR system, the

shaded objects represent MyHR functions and features that were operationalized at

the time of this case study. In order to improve readability, individual tasks depicted

in the BPMN diagrams are denoted by process ID within square brackets e.g.

[processID].


Clinical consultation (CSHIS and MyHR)

The following process describes activities and roles associated with a clinical

consultation. The process commences with the individual seeking a consultation with

a clinician for a general health check. Creation of a MyHR account has occurred prior

to this stage of the clinical consultation process. Establishing a MyHR account requires

the individual to register for an online health record which collects demographic

information, current medications, allergies, and advance care directives.

Figure 5.9 illustrates how the MyHR implementation might be observed as

increased administrative burden by HCPs due to additional process steps [5, 6 and 9].

The inclusion of MyHR functionality in this context has not reduced manual

information collection or mitigated issues with information quality and workflow

inefficiencies. The patient registration sub-process [2] is completed by the individual

on arrival at reception with patient demographic and health details subsequently

entered into the clinical information system by the receptionist. This activity is

expanded in the ‘Patient Registration’ sub-process below. The individual undergoes a

pre-consultation check [3] where collection of vital signs and details about their

complaint, medications and allergies are added to an internal medical record by the

practice nurse.

The consultation with the clinician commences by reviewing available

information about the individual [4]. This includes access to the individual’s MyHR

[5] which requires system validation checks using the individual’s Health Identifier

(IHI). The clinician is able to view records based on the status of the records [6]. Three

states are available: (i) the record is advertised, (ii) a patient initiated digital health

record access code is in effect or (iii) a health record is not found or not advertised.

The clinician recommends a blood test [7] and completes a manual (handwritten)

pathology test order for the individual to seek a provider and arrange specimen

collection. The individual’s medical record is updated by the clinician [8] within the

internal clinical information system. At the conclusion of the consultation the clinician

is prompted to upload an event summary based on how the CIS is integrated with the

MyHR. The event summary is auto-populated from the internal medical record and the

clinician is prompted to confirm details before upload is initiated [9]. At this point, the

individual completes check-out administration activities at reception [10].


Figure 5.9. Clinician consultation and recommendation for a pathology test with the inclusion of MyHR related activities as shaded objects.


Patient Registration

Figure 5.10 shows the sub-process for the ‘Patient Registration’ task performed

by an individual when attending a consultation with a clinician. The data collected

with this process is already available in the MyHR system but is not accessed due to

limited integration with on-premise clinical systems.

Reception commences the registration sub-process in response to the arrival of

the individual. If the individual is not new, existing records are retrieved from the CIS

[2] and reviewed by reception and details contained in the record are verified as current

and correct [3].

Figure 5.10. Patient registration sub-process.

If the individual is new, then registration commences by creating a patient

record. This may also include a paper-based file to expedite data entry activities [4].

The individual manually (handwritten) completes a pre-printed registration form for

the collection of demographic and health related information [5]. In turn, reception

transcribe the individual’s handwritten information into an electronic format to be

stored within the CIS [6]. This may occur at a later date based on time and resource

constraints. The individual is added to the clinician’s schedule as per practice policy

by reception [7].

Pathology Episode (CSHIS/MyHR)

Figure 5.11 shows the high-level activities associated with a pathology episode

combining the CSHIS and MyHR system actors as discussed above. All possible

scenarios and variations which may occur as a result of a pathology episode are not

covered as the main aim of the study is to compare the effects of architectural concepts

on common clinical processes. Guidance for MyHR processes were drawn from


NEHTA (2009) specification documents however, these may have been superseded by

later revisions.

Figure 5.11. Pathology episode with the inclusion of MyHR related activities (shaded objects).

A pathology episode commences in response to the arrival of the individual for

collection and analysis of a blood specimen. Reception staff verify the details of the

pathology order and registers the individual for collection of specimens [2]. A search

for the individual’s records in the laboratory information system (LIS) is completed

[3]. A new record is created if an existing record is not found [4]. Reception manually

enter the individual’s demographic information and order details into the LIS from the

information contained in the pathology order [5]. Information quality issues are

emphasised due to manual data entry of information contained in a pathology order

which in turn may have been manually copied from information already containing

data entry errors.

Pat

ho

logy

Ep

iso

de

Re

cep

tio

nLa

bo

rato

ry W

ork

er

Pat

ho

logi

stin

div

idu

alR

eq

ue

ste

r

4. Create LIS record

5. Update LIS record

RecordNot Exists

3. Search and retrieve records Record

Exists

6. Collect Specimens and

affix labels.

7. Update LIS record.

9. Perform analysis and enter results

into LIS

11. Transmit pathology report.

LIS

Pathologyorder

Patient & Order details

Specimen Details

Patient & Specimen Details

Specimen analysis

Result Message

8. Receive specimens and

reconcile to record

2. Verify order and check in

individual

10. Create Pathology Result Report Message.

Pathologyreport

Pathologyreport

12. End

1. Start


The specimens are subsequently received by the pathologist and reconciled to

the individual’s record stored in the LIS [8] and an analysis is performed. The

Pathologist enters the results into the LIS [9] and initiates a pathology test report [10].

Within the context of the CSHIS, the report will be manually sent in a paper-based or

electronic format to the requester. However, a variation to this activity is observed with

MyHR integration, the LIS creates a message suitable for electronic communication,

based on the SDT-PRR and the Interchange Format – Pathology Result Report

(NEHTA, 2009). The LIS then initiates electronic communication containing the

pathology report for transfer to the requester’s CIS for processing [11].

Receive Pathology Results

The following sub-process explains the ‘Receive Pathology Results’ process

initiated by the ‘Pathology Episode’ process. The receipt of pathology results is

fundamentally unchanged from the traditional CSHIS approach as depicted in Figure

5.12. This process was informed by procedures at a large medical centre in Brisbane’s

southern suburbs which may be different in other clinics. Similarly, whilst clinicians

currently receive an electronic copy of pathology test results transmitted via Facsimile

(Fax), an increasing number of pathology services offer online access. It is noteworthy

that MyHR features and functionality have not been included because a process had

not been clearly defined by NEHTA specification documents at the time of the case

study.

Figure 5.12. Transmit pathology results process.

Tran

smit

Pat

ho

logy

Res

ult

s

Clin

icia

nR

ecep

tio

nLa

bo

rato

ry

2. Receive Pathology

Report

3. Reconcile & attach to

medical record

4. Retrieve & review report

5. Notify individual

CIS

Pathology Results

PathologyresultsIndividual’s

EMR

Pathologyresults

6. End

1. Start


The process commences in response to the receipt of pathology results by

reception checking for electronic copies [2]. Reception searches for and retrieves the

individual’s medical record, attaches the pathology test report [3] and alerts the

clinician. The clinician retrieves the individual’s medical record for review [4], notifies

the individual of the results and delivery of care proceeds [5].

5.4.4 Part B: Processes Associated with ePIMS

The process models described in the previous section provides a useful analogue

for examining the implications of implementing an electronic patient information

management system . More generally, the previous section emphasises that the MyHR

may be observed as an electronic filing cabinet for aggregating summarised patient

information. In its current form, one could argue that the MyHR offers limited clinical

value to HCPs (Dearne, 2014; Deloitte, 2014; Kruys, 2014). In contrast, ePIMS is

designed to automate and optimise clinical processes using a process oriented, service-

based paradigm. The following diagrams will bring to light how clinical processes will

change and in doing so add value to the way HCPs deliver care. Due to the highly-

integrated nature of eHaaS related processes, it is necessary to include additional

processes not detailed in Part A. In this respect, sub-processes associated with

individual APIs which are shaded in blue have been included to provide context and

additional detail.

Appointment Booking Process

The following process illustrated by Figure 5.13 is a required activity for creating

an appointment code which will be scanned as part of the clinical engagement process.

The objective is to reduce administrative overhead associated with patient registration.

The process for booking an appointment with an HCP is initiated by an individual

accessing a patient portal to arrange an appointment with a clinician. The individual is

required to review and update current demographic and health related information

using the ePatient service shown below in Figure 5.14 [2]. The individual selects a

clinician based on their requirements and available appointments are reviewed and

booked using the eAppointment service illustrated in Figure 5.15. Confirmation is

received indicating a successful booking via a user-defined notification method, email,

SMS message or hard copy [4]. An appointment reminder is received by the individual

based on a clinician configured time based trigger [5].


Figure 5.13. ePIMS appointment booking process.

ePatient Sub-process

The sub-process documented in Figure 5.14 expands the ePatient service which

is utilised for the management and/or retrieval of an individual’s demographic

information and health-related information. The ePatient service manages creation and

management of a personal health record (PHR) and plays a significant role in the

linking of patient maintained information to a clinician’s electronic health record

(EHR). The aim of the ePatient service is to provide access to high quality single

source of the truth information satisfying meta-requirement MR2. As an intrinsic

aspect of a patient portal, the ePatient API provides a gateway service to ensure that

personal health information is current and correct. The portal facilitates secure patient

communications, appointment scheduling, and access to prescription refills and

diagnostic results etc.

Figure 5.14. ePatient service sub-process.

This process commences when the patient portal is accessed by an authorised

user which initiates the ePatient service. The PHR data store is queried using the

individual’s unique health identifier [2]. In this way, access control is enforced with

the validation of the health identifier. A new record is created by invoking the record

Ap

po

intm

ent

bo

oki

ng

Ind

ivid

ual

ePatient API eAppointment API

eDirectory API

2. Manage patient

InformationePatient API

Individual Health Identifier (IHI)

3. Select HCP & book

appointment eAppointment

API

4. Receive confirmation of

appointment

5. Receive Appointment

Reminder

Location &Specialty

AppointmentConfirmation

AppointmentAlert

1. Start 6. EndDefault ReminderTrigger


creation method if the individual’s PHR does not exist [3]. Alternatively, any existing

records contained in the PHR was retrieved by populating the record details aggregate

for review by the authorised user based on the policy constraints and initiating method

[4]. Any updates to the PHR are facilitated by invoking a method to update the

individual’s information which is saved to the PHR data store [5]. If necessary, a

method can be invoked to synchronise data with external clinical systems. This may

occur when updates to an individual’s information have been initiated by authorised

clinical staff as part of the check-in process [6]. As a final step, a method is invoked

to update the Event store with activity metadata resulting from the activities associated

with the ePatient service [7].

eAppointment Sub-process

This sub-process illustrated by Figure 5.15 explains the activities associated with

an eAppointment service. The service enables criteria based selection of an HCP by

an individual. The aim is to streamline the HCP engagement process and reduce

administrative overhead for HCPs.

Figure 5.15. eAppointment Sub-process.

The process commences as a result of an individual accessing the eAppointment

service to schedule an appointment with a clinician. The individual identifies a

provider [2] by retrieving a list of available HCPs with the eProvider service (included

in Appendix A), which enables the following activities:

• Accepts input of location details and specialty requirements.

• Lists available HCPs.

• Accepts selection of an HCP.

• Returns an HCP reference to initiating process.

ScheduleStore

Event StoreWorkflow metadata

Schehduledata

Metadata Event details

Appointment details

Confirmation

Appointmentdetails

2.Select providereProvider API

3. Review available

appointments

4. Book appointment

5. Update metadata

6. Transmit confirmation

message

7. Transmit reminder message

1. Start

Default Reminder Trigger

8. End


On selection of the HCP, the individual is able to review available appointments.

The ‘Appointment Availability’ aggregate is populated by querying for appointment

and cancellation events enabling the individual to select a suitable appointment [3].

Several methods in the domain model are invoked to book the appointment [4], update

the HCP’s schedule, (which might be external) and update the individual’s workflow

metadata [5]. A messaging method is invoked to transmit a confirmation notification

to the HCP and the individual. Confirmation will include machine-readable code to

facilitate the eCheck-in process [6]. A reminder messaging method activated by a time-

based trigger (usually configured by the HCP), is invoked to send reminder messages

to workflow subscribers [7] which terminates the eApointment sub-process.

Clinical Consultation (ePIMS)

The process depicted by Figure 5.16 brings an eHaaS lens to the clinical

consultation activities described in Part A. The aim is to align common tasks but also

introduce several additional processes that seek to take advantage of a class of service-

based architecture that is mutable, loosely coupled and emergent. In this way, the

benefits of an eHaaS design may be observed.

The clinical consultation process demonstrates a reduction in the administrative burden

on reception with an automated patient check-in service (eCheck-in). Using scanner

technologies which identifies the individual and retrieves their SSOT demographic and

health-related information satisfies meta-requirement MR1. The risk of errors is

reduced with the minimisation of human mediated transformation activities leading to

better information quality (Ballou & Pazer, 1985). It is assumed that clinicians are

using a web-native CIS (ePractice) however, consideration is given to legacy systems

storing information locally however, an eArchive service is available which automates

the storage of clinical practice data in Cloud based archives. This addresses business

continuity and record retention requirements and satisfies meta-requirement MR3. The

process commences as a result of an individual making an online appointment for a

general health check using the eAppointment service (refer sub-process above).

On arrival at the clinic, the individual provides a health identifier (IHI) or

presents the appointment confirmation code. Reception proceeds to check in the

individual using the eCheck-in service which encompasses the following activities [2]:


Figure 5.16. Example of a clinical consultation demonstrating the benefits of eHaaS.

ePractice API or on-Premise

Clin

icia

n C

on

sult

atio

n (

eH

aaS)

Re

cep

tio

nC

linic

ian

Nu

rse

ePatient API eAppointment API

eProvider API

eFlow API ePOE API

3. Check Vitals

4. Consult with patient

RecommendTests

9. Check out patient

On-PremiseSystem?

No

YesYes

No

HealthIdentifier

Healthstatus

Clinical notes

ElectronicMedical

Record (EMR)

Demographic & billing details

HealthIdentifier

5. View/Create Patient Workflow

eFlow API

6. Create pathology order

ePOE API

eFlowIDPatient’s HIProvider ID

Workflow ID

Order Ref

8. Archive EMR

eArchive API

CISArchiveEvent

Store

W/Flow IDDatestamp EMR

Appointment Booking

Patient demographicinformation

Workflow metadata

7. Update clinical notes.

ePractice API

Demographicinformation

CIS

10. End1. Start

2. eCheck-in

Query on HI or scan QR Code

from document (electronic or h/copy)

Add to clinician’s schedule

Validate demographic informationePatient API


• Accepts entry of the IHI or scans the confirmation code generated by the

eAppointment service which may be in hard copy or electronic form.

• The individual’s PHR is queried and their demographic information

retrieved and validated by reception in consultation the individual utilising

the ePatient service (refer sub-process above). If required, changes are

updated, saved to the PHR and synchronised with the CIS for billing

purposes.

• Reception adds the individual to the clinician’s schedule as per practice

policy.

The individual undergoes a pre-consultation check [3] where the collection of

their vital signs and details about their complaint, medications and allergies are added

to the individual’s electronic workflow by the practice nurse. The clinician commences

consultation with the individual by reviewing their workflow information using the

eFlow service (refer Figure 5.17) [4]. A new workflow entity is created if one does not

exist. Creation of the workflow will generate a unique workflow ID (eFlowID) which

is associated with all care events and activities associated with this consultation [5]. If

a pathology test is required, the clinician creates an online pathology order using the

ePOE service by providing the individual’s HI, the HCP’s ID and attaching the

eFlowID. The ePOE service creates a document with patient instructions and a

machine-readable code containing the patient’s HI, eFlowID and ePOE Order ID for

scanning by the laboratory to locate the electronic order [6]. On completion of the

consultation, the clinician enters progress notes and updates the individual’s problem

list if required. An event is triggered by the CIS which may be a cloud native service,

(ePractice) that causes event metadata to be added to the individual’s electronic

workflow [7]. If the CIS is an on-premise implementation, then the system will

automatically store the electronic medical record in a Cloud based archival repository

and update the individual’s event store and electronic workflow with a link to the

record for viewing by authorised users [8]. The process ends with the individual

completing the check-out process at reception that include billing and administrative

activities [9].


eFlow Sub-process

The eFlow sub-process shown in Figure 5.17 explains the activities associated

with creating, reviewing and updating patient workflows to collaborate with inter and

intra organizational stakeholders in the delivery of care. This sub-process highlights

the benefits of using service-based architecture to provide a logical view of an

individual’s workflow by enabling access to federated data constituencies from a

single referential repository.

Figure 5.17. eFlow Sub-process.

The sub-process begins as a result of an authorised user accessing an individual’s

electronic workflow. The workflow metadata aggregate is populated by using the IHI

permitting selection of an appropriate workflow and access to the child task events

subject to the terms of the access policy [2]. If a new workflow is required, the

authorised user selects ‘New Workflow’ to invoke a domain method for creation of

the workflow as well as trigger the subsequent update of event and metadata stores

with details about the workflow [3]. If a new workflow is created, details of the new

workflow with an eFlowID is transmitted to the external clinical store if required by

the user [4]. Alternatively, the authorised user can view detailed information about

specific tasks associated with the workflow. Workflow ID, task ID and Access Policy

(subscription list) is referenced to populate the ‘Task Details’ aggregate resulting from

a query of the event store [5]. Similarly, an authorised user is able to add notes

associated with the task using the eCollaborate sub-process included in Appendix A.

The process ends when the authorised users exits the application.

ePOE Sub-process

The sub-process shown in Figure 5.18 describes the activities associated with

creating an electronic order for a pathology test. Functionality typical of Computerised

Physician Order Entry (CPOE) systems is provided by the ePOE service which is used

eFlow API

2. Select Workflow

3. Create new workflow

New workflow?

5. Review Tasks

Event Store

Workflow metadata

Workflowsummary

information

Yes

No

4. Return WorkFlow reference Workflow

details

Workflowdetails

Task Details

6. View & update eventseCollaborate

API

ClinicalStore

Workflow ID

1. Start 7. End


by the clinician to create and monitor pathology orders and enables downstream HCPs

to access, update and close orders in a collaborative way. The ePOE sub-process is

reusable and may be utilised for other specialty specific orders e.g. diagnostic imaging

and medication management. More importantly, this sub-process is an example of how

coordinated care is achievable with dynamic inter-organizational workflow

cooperation.

Figure 5.18. ePOE Sub-process.

The process commences as a result of the requester creating an electronic order

for a pathology test. If adding an order, the requester selects from the order catalogue

[2]. The order catalogue aggregate is populated by querying for specialty-specific

order-sets which may be organised by 2 major types.

• Type 1 consist of orders for defined patient conditions or diagnosis.

• Type 2 are pre-defined orders (pick lists) that include medication groups,

laboratory tests and diagnostic imaging modalities.

On selection of an order, a method is invoked which queries clinical guidelines

for ancillary requirements and patient instructions e.g. fasting for 4 hours. This is

reviewed by the requester to confirm inclusion in the electronic order [3]. At this point,

the requester selects Create Order which invokes a method in the domain model to

generate the electronic order. Order details include references to the individual’s IHI,

workflow ID and requester ID [4]. In this way, details contained in the electronic order

ePOE API

eDocument

2. Review order catalogue

4. Generate electronic

order

Hardcopy Required?

3. Review guidelines & instructions

9. Update workflow

7. Create eDocument

ePOE Store

6. Update order

Yes

No

Workflow Metadata

Order-sets

Commentsinstructions

ClinicalGuidelines

Instructions &requirements

Event details

Requester ID

Clinical StorePHR

Workflow ID

Individual’sHI

Order

View/Update

Add

5. Review order

HIOrder ID

Requester ID

8. Close orderClose

Orderstatus

Event Store

1. Start

10.End


can be retrieved with the IHI, Order ID and Requester ID. A query populates the order

details aggregate for review by authorised users based on the access policy [5].

Electronic orders may be updated by authorised users. A method is invoked to update

the order with user entered comments and instructions in order to encourage inter/intra

organizational collaboration [6].

Authorised users may also create an eDocument from the electronic order which

may be created in paper-based or electronic format. A method is invoked from the

domain model to create the eDocument with patient instructions or a machine-readable

code. The code may incorporate details about the patient’s IHI, WorkflowID, TaskID

and Requester ID [7]. If closing an order, authorised users must select an appropriate

action code. This invokes a method to set the status in the electronic order to closed.

Action codes are defined as ‘Complete’, ‘Cancelled’, ‘Expired’, ‘Not required’ [8]. On

conclusion of each activity (add, update, close), a method is invoked to update the

event store, workflow metadata and if required, an external clinical store. An alert is

sent to the subscriber list which is managed with the eFlow service to ensure all

authorised stakeholders are alerted to workflow events [9].

Pathology Episode (ePIMS)

The process described by Figure 5.19 shows a pathology episode. The laboratory

information systems will be referred to as (e)LIS. This is to denote that it may be

implemented as an ‘on-premise’ system with local data storage or may be a Cloud

native service. The activities listed below highlight the benefits of a CPOE when

integrated with patient information such as lower test utilisation, improved decision

support with recommendations and reminders (Adler-Milstein & Bates, 2010).

Continuity of care, where the technology is aligned with clinical workflows, will be

optimised though improved collaboration between HCPs resulting in a reduction in the

use of health services. This satisfies meta-requirement MR1.

The process begins as a result of the individual presenting to a laboratory for

specimen collection. The individual provides their IHI or presents the pathology order

code for scanning. Reception proceed to check in the individual using the eCheck-in

service described by [2]. Reception retrieves and verifies the pathology order utilising

the ePOE service. Order details are downloaded if the (e)LIS is an on-premise

implementation [3]. The laboratory worker collects specimens from the individual and

affixes labels with information from the (e)LIS [4].


Figure 5.19. ePIMS processes associated with a pathology episode.

The laboratory worker updates the individual’s record in the (e)LIS with date,

time and details of the specimen collection. The individual’s personalised workflow is

updated with metadata signifying that the collection event has occurred [5]. Specimens

are received by the pathologist and the labels scanned for reconciliation to the

individual’s record stored in the (e)LIS [6]. The pathologist performs the analysis and

enters the results into the (e)LIS in order to generate a report [7]. If the LIS is an on-

premise implementation, the system will automatically archive the electronic medical

record to a Cloud based archival repository. At this point, a domain method is invoked

to update the individual’s event store and electronic workflow with a link to the

pathology report for interaction by authorised providers and carers [8]. To finalise the

process, the pathologist sets the electronic order status to closed using the ePOE

service which sends an alert to registered workflow subscribers. The registered

subscriber list is managed with the eFlow service ensuring all authorised users are

alerted to workflow events [9].

eLIS API or on-Premise

Pat

ho

logy

Ep

iso

de

(e

Haa

S)

Re

cep

tio

nP

ath

olo

gist

Lab

ora

tory

Wo

rke

r

ePatient API ePOE API

HealthIdentifier

DemographicInformation

3. Retrieve & verify pathology order

ePOE API

QR Code

4. Collect Specimens and

affix labels

Order details

Orderdetails

Demographic information

6. Receive specimens and

reconcile to System record

On-PremiseSystem?

Yes 8. Archive laboratory records.

eArchive API

9. Close order & alert subscriber list

ePOE API

No

Activity status code

LISArchive

W/Flow IDProvider IDDatestampReport URL

Laboratoryrecords

EventStore

Workflow metadata

7. Perform analysis & enter results & generate

pathology report.eLIS API

5. Update record with specimen details.

eLIS API

W/Flow IDProvider IDDatestamp

LIS

1. Start

2. eCheck-in

Query on IHI or scan QR Code

from document (electronic or h/copy)

Add to Lab schedule

10. End

Validate demographic

details ePatient API


Receive Pathology Results (ePIMS)

The sub-process shown in Figure 5.20 explains the activities associated with

accessing the results from a pathology test. With the use of the eFlow and eCollaborate

services, the opportunity to access timely SSOT information and collaborate with

stakeholders in the delivery of care highlights the benefits emerging from this process

and satisfies meta-requirements MR1 and MR3.

Figure 5.20. Receive pathology results (ePIMS) Process.

The process begins as a result of an alert sent to the clinician from the ePOE

service indicating that pathology results are available in the individual’s electronic

workflow. The clinician locates the individual’s personal workflow and views the tasks

using the eFlow service [2]. The pathology results are available by accessing a

Universal Resource Locator (URL) to a viewer API that exposes the details of the

report at its source e.g. the laboratory’s information system. As an API, additional

functionality is available to the clinician specific to the domain of the service as well

as the ability to add comments for the individual and downstream HCPs using the

eCollaborate service [3]. Similarly, the individual is alerted that there has been activity

with their workflow and is able to access, review and leave comments for the clinician

if required [4].

5.5 DISCUSSION

A case study documenting the processes associated with three healthcare system

actors provides a high-level perspective of the influence of eHaaS architectural

concepts on clinical processes. This section discusses these differences and explains

how an instantiation of the eHaaS design artifact satisfies the meta-requirements listed

in Table 5.1. In keeping with a DDD sensibility, the discussion is organised by sub-

Rec

eive

P

ath

olo

gy R

esu

lts

Clin

icia

n

eFlow API eCollaborate API

2. View Patient WorkfloweFlow API

3. Access pathology results

eCollaborate API4. Notify patient

IHI ResultsComments

5. End1. Start


domains in order to compare and contrast the system actors. This establishes a natural

division in the solution space for encapsulating activities, application services and data

models demonstrating key differences. For time and space considerations, the

discussion focuses on three bounded contexts only, (i) pre-consultation, (ii) electronic

order management and (iii) workflow management.

5.5.1 Pre-consultation

It was observed in Chapter 4 that the process for scheduling a clinical

consultation encompasses a standard set of tasks e.g. selection of an appropriate

provider, some form of communication to arrange an appointment and manual

collection of an individual’s personal information. These activities are typical of the

pre-consultation phase of a patient’s journey and as such, may be encapsulated in its

own bounded context. As a key concept of this bounded context, the patient health

record (PHR) is represented in both the MyHR and ePIMS processes. Accordingly,

both require the individual to create an online PHR containing information that relate

to their demographic details, current medications, allergies, advance care directives,

etc. In its current form as a centralised repository, the functionality of the MyHR is

limited to data collection only. All other activities associated with pre-consultation

remain the same as CSHIS. Therefore, processes associated with registration is still

manual and prone to error and workflow inefficiencies.

In contrast, ePIMS takes full advantage of process automation by utilising

multiple service applications operating within the domain model. In this example, the

individual is required to manage their personal details in a PHR prior to accessing other

services as illustrated by Figure 5.14. As the first step in the process of HCP selection

and appointment scheduling, this helps to ensure information contained in these value

objects are up to date and correct. In this respect, all information is single source and

is as accurate and timely as possible which satisfies meta-requirement MR4. Similarly,

the encapsulation of the patient registration process with provider selection and

appointment scheduling tasks transforms the patient engagement process from a

collection of disparate manual activities to an automated check-in process. In this

respect, the burden of collecting, managing and processing patient information is

reduced satisfying meta-requirement MR1. Automation of the engagement process

represents a distinct advantage over the traditional approach employed with the CSHIS

and MyHR in two dimensions: a reduction in administrative burden and improved


information quality. This leads to a testable proposition which contends that the risk

of information quality issues associated with the burden of collecting information will

be resolved by ePIMS.

5.5.2 Order Management

A key aspect of the diagnostic process is the ordering of pathology services

highlighting the potential value of electronic ordering. The specialist literature

suggests that electronic ordering systems, typically referred to as computerised

provider order entry (CPOE), can lead to improved quality of care particularly when

used in conjunction with clinical decision support (CDS) (Khajouei & Jaspers, 2010;

Simon et al., 2013). However, broad adoption of these systems had been slow with key

system functionality underutilised or poorly implemented (Georgiou et al., 2012). As

observed in Chapter 4, clinicians continue to use paper-based orders for diagnostic

tests with the associated risk of error resulting from legibility issues, misidentification

of specimens and the potential for duplication of test orders (Mekhjian et al., 2002).

Thus, it is useful to examine the order management process as a bounded context.

In a simplified form, the order management bounded context represents a

domain characterised by three basic functions: firstly, creation of an order by the

clinician (requester). Secondly, processing of the order by the laboratory which

includes collection and analysis of a pathology specimen with the results

communicated to the requestor. Thirdly, receipt of the results by the clinician in the

form of a report and the subsequent completion of the order.

The CSHIS and MyHR processes associated with a pathology episode have been

operationalised as discrete tasks that are manual and paper based. Typically, this

activity requires transcription into different systems which may potentially add to

workflow interruptions and inefficiencies. In contrast, ePIMS encapsulate many of

these functions in an electronic order entry (ePOE) management service. Designed to

bidirectionally support the workflows of the clinician and the laboratory in the process

of creating, consulting, tracking and managing an order, the ePOE endeavours to

satisfy meta-requirement MR1. Accordingly, users could access the ePOE service

remotely from any location and use any device to send and receive orders satisfying

meta-requirement MR3. Similarly, information entered electronically by the clinician

(requester) can be accessed at the source by the laboratory to assist with identification

and reconciliation of collected specimens as well as the communication of results.


Immediate benefits are available with ePIMS through improved communication

and turn-around times. This is supported by a comparative study that observed

empirical evidence of significant reductions in the reporting times of laboratory results

when using electronic order entry (Mekhjian, et al., 2002). A hypothesis about the

effect of ePIMS on the problem domain suggests that further benefits may be realised

through improved information quality. This is due to reduced transcription errors and

the introduction of functionality to prevent or detect information quality issues which

satisfies meta-requirement MR4. Additionally, the ePOE service may be integrated

with clinical decision support tools utilising a rules engine service to provide clinical

alerts during the ordering process. There is wide variability in the features available

with CPOE systems (Wright et al., 2009). However, a key strength of eHaaS is a

flexibility for including additional services to enhance system functionality.

Figure 5.21. Clinical consultation and diagnostic support processes emphasising the patient’s role in

information sharing.

5.5.3 Clinical Workflow Management

Currently there is no standard method in the CSHIS and MyHR systems for

managing a centralised view of a patient’s workflow. Whilst the MyHR provides a

summarised view of patient information, organization of information is ad hoc with

access to information perceived as disruptive to the normal workflows of HCPs

(Royle, et al., 2013). To illustrate this, Figure 5.21 summarises the activities and

Lab

Seek Adivce

Lab Order

Blood Test results

Lab Order

Diagnostic imaging

Diagnostic Imaging Order

Report & Images

Report & Images

Report & ImagesReferral

Diagnostic Imaging

Order (2)Diagnostic

imaging

Diagnostic Imaging

Order (2)Report &

Images (2)

PharmaMedicationOrder

MedicationOrder

Diagnostic Imaging Order

Ge

ne

ral

pra

ctit

ion

er

Spe

cial

ist

Pat

ien

t


information flows associated with the initial primary healthcare episodes described in

Chapter 4. The diagram highlights the central role played by the patient in the

integration of information created and used by diverse clinical functions. Each box

represents internal workflows comprising discrete care events that are generally

supported by siloed information systems. Effective care coordination is degraded due

to inconsistent referral processes and poor visibility of the entire Patient Journey.

As discussed in Chapter 4, providing access to information about discrete care events

linked over time is a prerequisite for effective coordination of care. In this respect,

ensuring that continuity between care events is coherent and interconnected when a

patient’s workflow includes cross-domain activities requires access to comprehensive,

near-real-time sources of information. Considering this, the grouping and presentation

of heterogeneous information should support task sequence and align with users’

requirements (Khajouei & Jaspers, 2010). This is grounded in the hypothesis that

organising and presenting clinical information as personalised clinical workflows

extends well beyond the benefits of simply accessing a patient’s complete history. For

this reason, meta-requirement MR2 requires that an eHaaS design artifact provides for

the dynamic composition of workflow metadata. As a key design feature of the eFlow

service, it is possible to view a patient’s complete information in the context of a

workflow. To achieve this, an HCP creates new workflows or manages existing ones

within the Workflow Management bounded context.

Figure 5.22 provides a conceptual view of how the eFlow service improves visibility

of multiple sub-processes. Workflow metadata composition is used to establish a

central organising picture of all tasks associated with a care pathway. HCPs can access

single source of the truth (SSOT) tasks without the need to install local applications

by utilising intelligent integration architecture. In this respect, information services are

aligned with the contextual requirements of the user. The patient is moved from

playing a significant role in the transfer of information to a position of oversight.

Similarly, all authorised stakeholders are now able to view the entire patient workflow

in near real time.

Privacy and security is preserved with federated identity architecture which enables

the portability of identities, entitlements and attributes in cross-boundary scenarios.

HCPs in one organization can use single sign-on (SSO) to access services across the

federation with trust relationships associated with their identity. Using eFlow as an


example, an HCP gains access using the patient’s health identifier and access code

after a new Workflow is created.

Figure 5.22. A patient information management solution utilising dynamic workflow metadata

composition.

The access code is generated by the eFlow service with visibility of the

Workflow and underlying Tasks controlled by the patient and the creating HCP.

Visibility of a patient’s information can be limited to task level, workflow level or

display their complete history. Using this approach, a patient may have workflows for

many different health events which might include dental or optometry. By so doing, a

materialised view of sensitive workflows is limited to the respective clinical staff.

Figure 5.23 illustrates how the events are used to update a materialised view of

a patient’s workflow as HCPs create new Workflows and create, update and close

Tasks. Notably, interactive activities now occur primarily between authorised HCPs

Lab

Invoke healthcareevent

workflow

Invoke LabOrder

View Blood Test results

Monitor

Diagnostic imaging

Invoke Diagnostic Imaging

Alert

ViewReport & Images

Referral

Invoke Diagnostic Imaging (2)

Diagnostic imaging

Pharma

Invoke Medication

Order

Mo

nit

or

Acc

ess

Acc

ess

Alert

Monitor

ViewReport & Images

View Medication

List

Alert

Monitor

ViewReport & Images

Monitor

Workflow Meta-data Composition

Interactive activities

Ge

ne

ral p

ract

itio

ne

rSp

eci

alis

t

Pat

ien

t

WokflowID: 23456

Lab Task Order RefGP Consultation

Task Rec ID

Task Test Results ID

Diag, Image Task Order Ref

Task Diag. Report IDTask Diag. Image ID

GP Consultation Task Rec ID

Specialist Task Ref

Specialist Consultation Task

Rec IDDiag, Image 2 Task

Order Ref

Diag. Report 2 IDDiag. Image 2 ID

Med List Access Key

Medication Task Order ID


and are published as events to the workflow subscriber community. These events

model a materialised view of the Patient Journey as personalised clinical workflows

which can be used to dynamically populate parts of the system’s user interface.

Figure 5.23. Materialised view of events describing changes made to Workflow and Task.

This approach for delivering service applications within the context of

personalised workflows represents a key point of difference when compared to

existing eHealth systems. In this respect, the eHaaS design artifact represents a shift

from data-centric, monolithic thinking to process oriented, service innovation and

must be considered a practicable architectural alternative to extant eHealth solutions.

5.6 CONCLUSION

A high-level conceptualization of eHaaS architecture was established as a theory

driven response to satisfy meta-requirements identified in Chapter 4. Informed by this

model, a practical example of how a set of architectural patterns and applications can

optimise processes and information flows in clinical settings was offered. Utilising

microservices architecture with domain-driven design principles, a novel solution for

assembling heterogenous clinical information as personalised patient workflows was

demonstrated. Key differences were identified between an eHaaS design artifact and

existing eHealth system actors suggesting that the potential for process oriented

solutions is strong. A significant point of difference is the artifact’s dynamic

User Interface (UI)

Workflow created

Task 1 created

Task 2 created

Task 1 results

Task 1 closed

Materialised View

Task

Workflow ID

Task ID

Task Type

Task Name

...

Workflow

Workflow ID

Patient

Date

Status

...

Event store

Publishedevents

eHaaSApplications &

external systems

Query current view of entities as actions

Replayedevents


composition of discreet process oriented application services. In this respect, eHaaS

architecture is flexible and agile enough to adapt to the needs of a variety of users. As

an instantiation of the eHaaS design artifact, ePIMS, demonstrated some of the

innovative features of a system designed for improving information quality in cross

boundary and cross institutional scenarios. From an information quality perspective,

findings from an ethnographic study in Chapter 4 suggests that information quality

attributes: accuracy, timeliness and continuity, may lead to improved continuity of

care. Whilst the conceptual model is a supposition based, suggested improvement to

the process, which is neither validated nor tested, it is now possible to establish the

foundations for a testable proposition based on the notion that an eHaaS design artifact

will have a positive effect on information quality, specifically accuracy and timeliness.

Chapter 6 proceeds to determine the validity of the proposition by testing the effect of

these design choices on the quality of health information.

Chapter 6: Evaluation 135

Chapter 6: Evaluation

6.1 INTRODUCTION

The aim of this chapter is to validate the eHealth-as-a-Service (eHaaS) design

artifact by evaluating the behaviours of three system actors and their effect on the

quality of information flows within a generalised Patient Journey. In doing so, findings

derived from primary evidence in this thesis established a possible causal relationship

between information quality attributes and eHealth architecture. Consequently,

information quality emerges as an overarching goal for design activities. Meta-

requirements for an eHealth solution were synthesized and normative design principles

specifying the characteristics satisfying these requirements were derived and grounded

in key concepts from semiotic theory. Chapter 5 presented a practical example of how

an eHaaS architectural pattern might address these requirements by establishing the

technical foundations for a priori hypotheses. With this knowledge, a testable

proposition was offered suggesting that the implementation of an eHaaS design artifact

will have a positive effect on information quality.

However, there is currently an impoverished account of effective methodologies

for evaluating the influence of eHealth architecture on information quality at the design

stage. Taking guidance from the works of information quality practitioners such as

Ballou and Pazer (2003), Parssian, Sarkar, and Jacob (2004) and Shankaranarayanan,

Ziad, and Wang (2003), an evaluation approach was conceived to demonstrate the

predicted effect of change produced by the eHaaS design artifact. By so doing,

evaluation comprising mathematical models examined the behaviors of three system

actors and their effect on patient information flows within one of the most common

scenarios within the Patient Journey e.g. clinical consultation and pathology specimen

processing. Thus, this evaluation framework has several strengths. Using a

combination of data and business process modelling techniques the framework

provided a scientifically rigorous basis for information manufacturing system (IMS)

modelling which can also be applied outside of healthcare. To this end, the framework

facilitated an examination of operational information at the data structure, data flow

and business process levels. This provided important insights into the complex

interrelationships between these aspects of an IMS. Whilst, it shed light on the

136 Chapter 6: Evaluation

influence of architectural design choices on information quality, this approach to

evaluation is itself a contribution to the knowledgebase.

The following contributions have been made by this chapter:

• A novel evaluation strategy for eHealth design artifacts utilising techniques

and tools adapted from the information quality and business process

modelling domains.

• Empirical evidence that an eHealth-as-a-Service design artifact will deliver

information quality improvements in the context of a patient’s journey.

Based on the assumptions used within the scope of this analysis, the following

findings emerged:

• The eHaaS design artifact demonstrated an improvement in the accuracy of

patient information in cross domain scenarios. The findings highlight that

information quality improvements are achievable through process

improvement. Specifically, minimization of human mediated

transformation activities using data flow automation and process redesign.

• The ‘My Health Record’ (MyHR) system did not have a significant effect

on improving information quality within the Patient Journey. However, the

accuracy of information produced by the MyHR simulation trended slightly

higher than that observed with traditional methods due in part to the

inclusion of a unique health identifier. It is reasonable to perceive the MyHR

as a clinical document management system where accessibility to patient

information is improved however, there is no meaningful effect on quality

attributes measured by the analysis.

• Results from the first group of timeliness experiments indicate no strong

statistical evidence that MyHR and eHaaS system actors will produce a

significant change in the timeliness of information products. However, it

was found that manual data management practices have a moderating effect

on the relationship between timelines and system actors. This was confirmed

with the second group of experiments which examined the effects of

removing delays resulting from outdated communication practices and

manual data collection processes. The MyHR results were marginally


significant however, the eHaaS results showed meaningful gains in

individual data item timeliness as well as overall processing time.

The chapter is organised as follows. Section 6.2 to Section 6.4 establishes the

rationale and requirements for a novel evaluation strategy. As a case study, Section 6.3

outlines the experimental process and environment for developing and implementing

simulation models to evaluate the artifact. Section 6.4 presents the results from two

groups of experiments that were performed to examine an IMS actor’s effect on

accuracy and timeliness. Section 6.5 discusses the findings and provides a systematic

description of the effectiveness of design choices for large scale, distributed

information management systems.

6.2 SYSTEM EVALUATION STRATEGY

Figure 6.1. Process highlighting critical realist perspective of the research validation phase inspired by

Johnston and Smith (2010).

In order to draw conclusions about the validity of the eHaaS design artifact

requires an examination of how well the change produced addresses the problem it is

intended to solve i.e. measuring the influence of eHaaS architectural concepts on

information quality. Figure 6.1, inspired by Johnston and Smith’s (2010), provides a

critical realist perspective of the validation phase. The aim of the creators was to show

that the generative mechanism described by a given theory produces the actual events


that constitute the domain to which the theory applies. In this respect, the goal of this

phase is to collect evidence that the generative mechanism, shown in the middle right

of Figure 6.1, explains the events emerging in the broader domain. Based on logical

deduction, it was predicted that eHaaS architectural concepts will have a positive effect

on information quality. Simulations provide the basis for an evaluative analysis using

information quality mapping (IP-Map) to generate the empirical traces for observation

processes (Ballou & Pazer, 1985; Shankaranarayanan, Wang, & Ziad, 2000). This

locates an evaluative analysis within the information quality domain giving focus to

the concept of information as products. In this context, information products (IP) are

produced by IMSs which is analogous to traditional systems that manufacture physical

products.

Three system actors were investigated which are defined as: (i) current state

health information system (CSHIS), (ii) the MyHR implementation and (iii) an eHaaS

design artifact.

(i) CSHIS is a system actor that may be considered the traditional semi-

digitalized or hybrid paper based/computerized systems in common use

within Australian healthcare. CSHIS embodies tasks characteristic of

healthcare professionals (HCP) whose systems are not integrated with

the national eHealth system.

(ii) MyHR, as a system actor, supports the centralised online storage of

electronic health records (EHR) to support clinicians in the provision of

care. Also referred to as personally controlled health record (PCEHR)

and shared electronic health record (SEHR). MyHR processes offer an

integrated configuration of activities and roles that extend the traditional

CSHIS by incorporating Cloud based features and functionality

operationalised as Australia’s national EHR system

(iii) eHaaS design artifact, as a system actor, is a Cloud based solution

grounded in domain-driven design principles. A Microservices

architecture establishes the foundations for a novel approach to

assembling patient information. Its purpose is to provide support for

dynamic cross domain processes by improving information quality.


Computer simulations modelling the clinical consultation and pathology

specimen processing scenarios used in Chapter 5 were developed to enable

experimentation in a virtual space.

6.3 EVALUATION DESIGN

According to Catwell and Sheikh (2009), it is useful to evaluate eHealth design

artifacts in the early stages of development and deployment in order to maximise its

benefits while minimising any risks. Yet, literature describing the design of eHealth

technologies provide an impoverished account of effective evaluation methodologies

(Dansky, Thompson, & Sanner, 2006). Thus, the conceptualization of eHealth-as-a-

Service (eHaaS) as a design artifact presents a challenge when contemplating

evaluation activities.

Validity of the eHaaS design artifact requires confidence that an observable

causal relationship exists between the eHaaS design artifact and the problem it was

intended to address i.e. improving the quality of clinical information. This required a

research design method that is explanatory in nature. Thus, a novel evaluation strategy

encompassing a combination of data modelling and business process modelling

techniques was used for experimentation. Data flow diagrams used in Chapter 4

established a graphical representation of patient information flow with BPMN models

documenting scenarios created for a case study in Chapter 5 providing a holistic view

of the simulation environment. However, IP-Maps, which is an information

management method to document information production processes, was adopted as

an effective technique for creating a process view of data flows across information

systems and organizational boundaries. In this respect, IP-Maps synthesised from the

developed BPMN models ensured that simulation models exhibited an acceptable

level of external validity.

In order to operationalise the experiments, computer simulations comprising a

set of logical relationships and mathematical equations were developed using

spreadsheets to model information flows. This choice was influenced by Abu-Taieh

(2008) and Namekawa, Shiono, Ueda, and Satoh (2011) whose work in this area

offered a scientifically rigorous approach for operationalizing assumptions about the

system being modelled. Thus, utilising spreadsheets as a platform for experimentation

offered a reliable, general purpose means for developing simulation models. It is


argued that a disadvantage with using an experimental design approach is poor external

validity. This is because models may not account for socio-technical and contextual

considerations (Catwell & Sheikh, 2009). Whilst, this perspective is acknowledged,

the overall aim of this chapter is to collect evidence that changes caused by the design

artifact satisfied the predictions of the testable hypotheses. In this respect,

experimental research provided complete control over extraneous variables. With

careful manipulation of specific variables in controlled circumstances, experiments

conducted in artificial settings ensured a high level of internal validity. This instilled

confidence that observed empirical traces were due to the influence of independent

variables that had been manipulated for each experiment. Moreover, the following

validation and verification techniques were adopted to ensure the models were a

reasonable representation of external phenomena.

6.4 MODEL VERIFICATION AND VALIDATION

To minimise the risk of bias, development of the evaluation framework drew

from the works of several notable academics in the information quality domain e.g.

Ballou and Pazer (2003), Parssian, Sarkar, and Jacob (2004) and Shankaranarayanan,

Ziad, and Wang (2003). More importantly, the simulation approach and mathematical

models were based on the work of these academics and as such, this evaluation

framework may be applied to any large-scale architecture at the design stage. From a

quality dimension perspective, development of the framework was grounded within a

recognised information quality framework (Infoqual) and drew from literature on

information quality in the healthcare domain. Similarly, techniques and methods (e.g.

IP-mapping) were also based on recognised and accepted techniques.

During development, simulation models underwent numerous iterations as part

of the validation and verification process. Performance measures obtained from the

models were compared with assumptions made about the real world. However, the

subjective nature of what constitutes a good model for measuring process effectiveness

demanded an approach that ensured the model was a reasonable representation of

external phenomena. In practice, examining suitability of a model occurs along two

dimensions, (i) model verification; does the model operationalise assumptions about

the system being modelled correctly?, and (ii) model validation; are assumptions made

about the system reasonable? (Hillston, 2003). This section outlines the rationale and


utilisation of a combination of validation techniques and tests used to check the

suitability of the simulation models developed for this study.

6.4.1 Validation

The output from the computer simulations provided a set of results leading to

insights and conclusions about the design choices viewed through the prism of

information quality. It is important to acknowledge that the introduction of information

quality defects under laboratory conditions might seem somewhat contrived. Although

the aetiology of information quality deficiencies is not explored here in depth, all

efforts were made to utilise measures that correspond with the real world. This was

achieved by emulating the effects of the generative mechanisms that produced them,

for example, errors introduced during data entry or removed during edit and validation

checks (see Section 6.5.5 for a detailed discussion). It must be noted that consideration

was given to common business practices based on the ethnographic study and existing

clinical time and motion studies. It is acknowledged that these processes do not apply

to all possible clinical scenarios. In the context of this analysis, estimates for error rates

were considered exogenous to the systems being modelled and were consistent for all

systems and are listed in Appendix E. This is because the significance for this research

was not in discovering which variables are frequently in error, (although this is useful),

but to ensure that data deficiencies were tracked consistently and were measurable at

any given point in time.

6.4.2 Verification

To address verification requirements, the construction of information

manufacturing analysis matrices (IMAM) developed by Ballou, et al. (1998) were a

valuable tool for verifying simulation models. Although their motivation for

developing IMAMs is the analysis of information manufacturing systems for potential

improvements, in the context of this analysis, the matrices provided a means of

verifying relationships between data items and system functions. The process of

constructing each IMAM introduced a systematic method for checking attributes and

variables used in the information product manufacturing process. As illustrated by the

figure in Appendix B, a simple two dimensional matrix was populated by values

derived from each simulation model.


This approach fostered useful quality assurance habits by encouraging iterative

walk-throughs of each model to inspect the characteristics of each state change.

Similarly, tracing output data items in the IMAM enforced a high level of data

relationship correctness by identifying faulty behaviour in the IMS models. For

example, erroneous attribute values due to faulty process links or incorrect input

parameters.

6.5 CASE STUDY

In order to conduct experiments examining the influence of eHaaS architectural

concepts on information quality, three IMSs commonly associated with clinical

consultation and pathology specimen processing scenarios were selected. The IMSs

are defined as: (i) the traditional healthcare information system (CSHIS) which is

largely paper based, (ii) Australia’s national EHR system (MyHR) and (iii) an

instantiation of an eHaaS design artifact. As a case study, experiments were

operationalised utilising a methodology consisting of two phases. Phase one

consolidated understanding about how information is produced and consumed by

transformation functions and event transitions. Phase two describes the steps required

to operationalise experiments i.e. the evaluation of three IMS. Phase one commences

with mapping the flow of information using a technique called IP-Map modelling.

6.5.1 Mapping the Flow of Information in Clinical Consultation and Pathology

Specimen Processing Scenarios (Phase One)

A goal of the analysis was the representation of data movement as patients

navigate different care pathways. The challenge for an analysis of this type was the

notion that health information is composed of a limitless array and combinations of

potential data items (Davis & LaCour, 2014). Consequently, articulation of this

complex collection of data items was complimented by the adoption of graphical

presentation methods. BPMN (OMG, 2008), which was used in Chapter 5, was

considered in the first instance however, its focus primarily on activities lacked the

necessary emphasis on information flows or information quality. Similarly, data flow

diagrams (DFD) created in Chapter 4 which defined processes as well as inputs and

outputs did not clearly describe data relationships or changes to the data. However, the

Information Product Map (IP-Map) developed by Shankaranarayanan, et al. (2003)

offered a useful documentation technique for creating a process view of data. Their

conceptualization of IP-Map notation for graphically representing and analysing


information products (IP) provided an effective technique for examining information

quality management processes. This became particularly useful when explaining

information flows across information systems and organizational boundaries. More

importantly, it was easily adaptable permitting the conflation of BPMN and IP-Map

constructs and objects to illustrate and better understand the nuances of clinical

information flows.

6.5.2 IP-Map Construction

An information as product perspective brings a manufacturing sensibility to the

creation and management of information. Raw data, like raw materials undergoes a

series of processes to produce an end-product that has utility for the user, in this case

an IP. The analogy used in the specialist literature is one of the production line where

IPs are standard products comprising data components which are stored or regenerated

for each use of the product. Data components are assembled by processes that may be

internal or outsourced to external agencies utilising different computing resources

(Ballou, et al., 1998; Shankaranarayanan, et al., 2003). In the context of this study it is

defined by the information manufacturing stages identified within clinical consultation

and pathology specimen processing scenarios.

Documenting the information manufacturing process requires a descriptive

approach to assist in the visualisation of the information production process. IP-Maps

offered methods and a graphical notation for systematically documenting processes,

information and organizational boundaries, process owners and quality attributes of

the manufacturing process. In this respect, IP-Map modelling adopts a top-down

approach where the requirements of the information product guide the design of the

IP-Map. The modelling constructs used in IP-Map notation consist of eight types

which are given unique names and may be described by a set of metadata

(Shankaranarayanan, et al., 2000). Table 6.1 summarises the constructs with their

associated symbols. As a novel approach to its traditional use, IP-Mapping concepts

used in this analysis were adapted to include BPMN swim lanes in order to clearly

define organizational and role boundaries. The aim was to improve the visualisation

of information flows across boundaries and between process owners. Figures 6.2 and

6.3 illustrate scenarios used in the analysis as an example of this hybrid modelling

technique.


Table 6.1

IP-Map constructs and symbols adopted from Shankaranarayanan, et al. (2000)

Symbol Construct Description

<Name>

Data source or Data

Vendor

Designates the source of supplier of a raw

data item.

<Process Identifier>

Process Block Designates data operations on some or all

raw and component input data items

required to produce the information product

e.g. calculation, sort or aggregation.

<StorageName>

Storage Block Designates a repository that captures raw

and/or component data items for storage or

further processing.

<Criteria>

Decision Designates a conditional process for

evaluation and flow control based on some

criteria.

QualityCriteria

Quality/Inspection

Block

Designates a quality check on raw and/or

component input data items deemed

essential in producing a “defect free”

information product.

<Org/dept

Name>

Organizational

Boundary

Designates the transfer of raw and/or

component data items across departmental

or organizational boundaries.

<System Name>

System Boundary

Designates changes to raw and/or

component data items as they move

between information systems. These

system changes may be intra or inter-

business units.


Symbol Construct Description

<Name>

Data Sink or

Consumer Block

Designates the consumer of the information

product. The data elements constituting the

“finished” information product is specified

by the consumer.

6.5.3 IP-Map Process

The first step in construction was the identification of common data outputs.

Using a production line analogy, data outputs are defined as component data items,

which are assembled by processes as work in progress, and the information product

which is the final output. Table 6.2 lists data outputs used in this analysis.

Table 6.2

Data Outputs (Information Products) considered for analysis

Identifier Information Product Event

CDPA3 Patient Demographic

Data

Clinical Information System is populated

IPCN1/CDCN8 Clinical Summary of

consultation

Clinical summary available for

Consumer, repository, service.

IPPR2 Pathology Requisition

Order

Order Delivered to Consumer

CDPR8 Order received in LIS Laboratory Information system is

populated.

IPSD3 Specimen Details Details printed for tracking specimens

CDTR12 Pathology Test results Results available for Consumer,

repository, service.

IPTR4 Patient Clinical

History/Workflow

Patient's current clinical status reviewed

Four information products were identified for this analysis, (i) the patient’s

clinical summary denoted by IPCN1 and CDCN8, (ii) a pathology requisition order

denoted by IPPR2, (iii) pathology test results denoted by CDTR12 and (iv) the

patient’s clinical workflow history denoted by IPTR4.


Figure 6.2. IP-Map depicting the CSHIS clinical consultation process and the manufacture of a pathology report


Figure 6.3. IP-Map depicting CSHIS laboratory medicine processes

Pat

ho

logy

Se

rvic

es

(CSH

IS)

Pat

ho

logi

stR

ece

pti

on

Lab

ora

tory

Wo

rke

r

Collect test requisition order

DS5IPPR2


STO2

RDPR5

Validity & Completeness

QB2CDPR7

CDPR8

Collect SpecimensDS6 RDSD6

CDSD9

CDPR8 + CDSD9

Match labels to verify

QB3

CDSD10CDTR11

CDPR8 + CDSD9 + CDTR11

Analyse SpecimensDS7

IPSD3LABCB2

RDTR7

Enter analysis Details

P6

Generate Pathology Test Report

P7

Update Patient record with

specimen detailsP5

Create Specimen Labels

Electronic Form to Paper Form

SB5

Collect patient details and

OrderPaper form to

Electronic FormSB4

Transfer from GP

to Pathology

ServiceOB1


Consideration was also given to the inclusion of important component data items

(CDI) in order to evaluate quality as a measure of process effectiveness e.g. CDPA3,

CDPR8, IPSD4. As a rule, component items used in the analysis comprise patient

demographic data and pathology test results.

The second step identified the source of all raw (primitive) data items. Data was

collected from three sources; (i) the patient, (ii) the clinician’s office (reception, nurse

and clinician) and (iii) the pathology laboratory as shown by the swim lanes in Figures

6.2 and 6.3. The final step of construction required the translation of business

processes documented in the BPMN models to IP-Map constructs. These constructs

served as an aid to visualise data composition and track raw and component data items

considered important for the manufacture of the IPs. Figure 6.3 shows an IP-Map

representing the manufacture of a pathology report for the CSHIS. Additional IP-Maps

documenting the MyHR and eHaaS information manufacturing systems are available

in Appendix C.

6.5.4 Experimental Setting (Phase Two)

The following sub-sections describe the steps taken to operationalise

experiments for the evaluation of CSHIS, MyHR and eHaaS. The CSHIS system actor

was used to establish baseline measures in order to compare and contrast the

behaviours of MyHR and eHaaS. Using the techniques discussed in Section 6.3, the

quality attributes of data outputs (component data items and information products),

were systematically monitored and measured to analyse the processing effectiveness

of each system actor.

Quality dimensions used in the analysis was informed by findings in Chapter 4

which concluded that accuracy and timeliness may lead to improved continuity of care

and this was supported by specialist literature (Banfield, et al., 2013; Elder, et al.,

2004). Using a functional approach and differential calculus, it was possible to

accurately estimate the effect of transformation functions on these quality attributes

and they are relatively straightforward to model. Simulations were constructed in such

a way that for each system actor, two groups of simulation experiments were

performed. The first group denoted by [System Actor] _AE (Accuracy Experiment),

measured the effect of system actor processes on the accuracy of output data items.

The second group, denoted by [System Actor] _TE (Timeliness Experiment),

measured the effect of system actor processes on the timeliness attribute of output data


items. Each group of experiments were performed twice with changes made to the

mathematical model or to specific input parameters. The process of constructing

accuracy and timeliness simulation models was the same for all IMSs therefore, only

the construction of CSHIS simulations is described here in detail.

Information quality Dimension: Accuracy

A common definition of accuracy in information quality (IQ) literature is the

proximity of data attributes to its corresponding real-world state (Batini &

Scannapieco, 2016; Görz & Kaiser, 2012). However, it is important to note that three

types of accuracy metrics are commonly proposed; Boolean, degree and value-

deviation. A Boolean metric returns a binary value (1=true, 0=false) to indicate if the

data item is correct whereas a degree metric is typically represented as a range between

0 and 1 indicating the confidence of how accurate the data is. A value-deviation metric

measures the distance between a stored data item and its real-world counterpart

represented by a number between 0 (poor) and 1 (good) (Peralta Costabel, 2006).

To characterise this further, there are two archetypal functions utilised with

accuracy metrics, (i) ratio and (ii) average: (i) A ratio approach determines the

percentage of accurate data versus actual data items in a system. In mathematical

terms, let 𝐴𝑖 denote the specified accuracy of data item 𝑖. Thus, Boolean metrics are

used to express accuracy with 𝐴𝑖 ∈ {0,1}, 1 ≤ 𝑖 ≤ 𝑛. (ii) The average technique is the

most commonly utilised with the three types of metrics listed above. However, there

are different methods used for computation which include average with sensibilities

and weighted average. Average with sensibilities is used to moderate the importance

of errors and provide an average of sensitised values. In contrast, a weighted average

applies weights to data elements based on their relative importance to the data item

(Ballou, et al., 1998).

Against this background, in order to determine the effect of processing functions

on the quality of input data items required a high level of granularity. Aggregation

techniques providing an overall assessment of the accuracy of an information product

which may comprise data at various levels of quality and encompass multiple stages

of processing had to be considered. Thus, it was decided that Ballou’s weighted

average technique would give the precision required to assess the quality dimensions

at individual data component level. A formula based on a processing function

aggregating multiple input data items 𝑥1, 𝑥2, … , 𝑥𝑛 was used to form a weighted


average of the created output data item 𝑦 = 𝑓(𝑥1, … , 𝑥𝑛). In this instance, let 𝐴(𝑥𝑖)

denote the measure of proximity of data item 𝑥𝑖 with reality. A continuous scale

between 0 indicating poor congruence and 1 representing reality was adopted. Ballou,

et al. (1998) provide an equation where Data Component (DC) satisfies 0 ≤ 𝐷𝐶 ≤ 1

and can be derived from:

𝐷𝐶 =

∑ 𝑤𝑖 ∗ 𝐴(𝑥𝑖)𝑛𝑖=1

∑ 𝑤𝑖𝑛𝑖=1

where 𝑤𝑖 = |𝜕𝑓

𝜕𝑥𝑖| ∗ |𝑥𝑖|. (1)

Based on this foundation, models measuring the accuracy of output data items

were constructed.

Process for Constructing Accuracy Simulations

The first step and a key dimension of evaluating accuracy was identifying data

elements that make up CDIs and IPs. Analysis was conducted at a data element level

in order to provide a more detailed view of output data item quality. This necessitated

the use of fine-grained data provenance techniques in order to isolate and track

primitive data elements. A review of clinical forms and clinical systems requirements

documents provided the necessary level of detail required to identify a typical set of

primitive data elements. A full list of data elements is included in Appendix D.

The second step examined the transformation functions used to produce the

seven output data items discussed in Section 6.5.4. This required a process-driven

approach in order to simulate the behaviours associated with manufacturing IPs. Six

functions were monitored for accuracy; source blocks, process blocks, quality blocks,

system boundaries, organizational boundaries and storage blocks. Commencing with

the source blocks it was necessary to establish the accuracy of raw data items however,

a precise calculation can be quite difficult. Ballou, et al. (1998) suggest a subjective

approach based on the researcher’s experience and/or information audits. For the

purpose of the analysis, a decision was taken to supplement Ballou and colleagues’

approach by deriving likely error rates from healthcare literature which is discussed in

the next sub-section.

Deriving Accuracy Input Parameters

A descriptive study measuring error rates of manually entered data across

clinicopathological fields in Australia reported error rates of 2.8% across all fields with

errors ranging from 0.5% to 6.4% identified for individual fields. Notably, 16.8% of


records had errors in one field only whereas 4.3% had two or more incorrect fields and

2.9% had 3 – 5 errors (Hong et al., 2013). Secondly, a study by Arndt, Tyrrell,

Woolson, Flaum, and Andreasen (1994) estimated a 2.4% error rate for observer rating

scores in a multicentre field setting in the United States (US). Thirdly, a large study of

data errors in several clinical research databases at a single academic medical centre

in the US, reported errors ranging from 2.3% to 26.9% detected by the double-entry

method. The study reported that errors were due to data entry and misinterpretation of

information in the original documents (Goldberg, Niemierko, & Turchin, 2008).

Clearly, these studies report a wide range of error rates however, they also indicate

consistent behaviours suggesting that errors are common and may be considered

pattern based. Therefore, it was reasonable to adopt the following range of error rates;

2.8%, 2.4% and 2.3%, as the basis for assumptions used in the experiments. A point

estimate of 2.5 (𝜇) was established and a 95% confidence interval for 𝜇 derived (2.416,

2.584). This range of values were applied as input parameters to determine the

likelihood of errors introduced during various state transitions. A full list of errors and

their values is included in Appendix E. The next sub-section describes how the

accuracy simulations were operationalized.

Operationalizing the Accuracy Simulations

As an illustrative example, the patient check-in process described in Figure 6.2

is represented in Table 6.3 to show how error rates were applied to a raw data item,

(RDPA1) and their influence on output data items at the data element level. These raw

output data items were subsequently used as input component data items by

downstream activity blocks e.g. process block P1, system boundary SB1 and quality

block QB1. As a process associated with a patient registration task, data item RDPA1

was received from the patient and underwent various functional processes: P1, SB1

and QB1 to produce CDPA1 and CDPA2. As an example, the output data quality value

for item CDP2 and function QB1 will be calculated based on the simulation rule: (QB1

= [1 − (1 − 𝐴𝑐𝑐𝐼𝑛) ∗ 𝑀𝐼]) using values derived from an input parameter table e.g.

magnitude of improvement (MI) = .95. A full list of input parameters is included in

Appendix F.

Calculating the Effect of Transformation Functions

A key dimension of this evaluation strategy was an analysis of the effectiveness

of functional processes. In this context, processing effectiveness (ProcEff) is


represented as the probability that a process introduces error to data items (Ballou, et

al., 1998).

Table 6.3

Effect of functional processes on the accuracy of raw data item RDPA1

ID Data

Elements RDPA1 P1 CDPA1 SB1 CDPA2 QB1

RDPA1 Surname 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 First Name 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 DOB 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Gender 0.998 0.85 0.92 1.00 0.96 1.00

RDPA1 Street Address 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Preferred

Name

0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Postal Address 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Mobile

Number

0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Home Phone 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Work Phone 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Email 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Occupation 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Medicare

Number

0.998 0.85 0.92 0.95 0.94 0.25

RDPA1 Medicare Ref

No

0.998 0.85 0.92 0.95 0.94 0.25

RDPA1 Medicare Exp

Date

0.998 0.85 0.92 0.05 0.21 0.25

RDPA1 Pension/HCC

No.

0.998 0.85 0.92 0.76 0.84 0.25


ID Data

Elements RDPA1 P1 CDPA1 SB1 CDPA2 QB1

RDPA1 Next of Kin

Details

0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Allergies 0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Current

Medications

0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Family

History

0.998 0.85 0.92 0.76 0.84 0.95

RDPA1 Medical

History

0.998 0.85 0.92 0.76 0.84 0.95

Mean 0.998 0.92 0.82

Thus, the formula for calculating process effectiveness may be defined as: let

ProcEff denote processing effectiveness with a domain of 0 to 1 where ProcEff = 1

will not introduce errors and ProcEff = 0 will result in a corruptive effect on the quality

of output data. The accuracy of output data item 𝑦 can be denoted by 𝐷𝑎𝑡𝑎𝐴𝑐𝑐(𝑦) and

is determined by the accuracy of input data and processing effectiveness obtained

from:

𝐷𝑎𝑡𝑎𝐴𝑐𝑐(𝑦) = 𝑓(𝐷𝑎𝑡𝑎𝐶𝑜𝑚𝑝, 𝑃𝑟𝑜𝑐𝐸𝑓𝑓).

Simulation experiments employed various methods for the functional

relationship including subtraction, equivalence and cumulative functional

relationships described by Ballou, et al. (1998), for example:

𝐷𝑎𝑡𝑎𝐴𝑐𝑐(𝑦) = √𝐷𝑎𝑡𝑎𝐶𝑜𝑚𝑝 ∗ 𝑃𝑟𝑜𝑐𝐸𝑓𝑓. (2)

The cumulative method was utilised for the first group of simulation experiments

denoted by Accuracy Experiment 1 (AE1). The functional relationship between

CDPA1, SB1 and CDPA2 listed in Table 6.3 provides an example of the cumulative

effect of processing errors.

A second group of simulation experiments, denoted by Accuracy Experiment 2

(AE2), utilised a simplified subtraction functional relationship obtained from:


𝐷𝑎𝑡𝑎𝐴𝑐𝑐(𝑦) = 𝐷𝑎𝑡𝑎𝐶𝑜𝑚𝑝 − 𝑃𝑟𝑜𝑐𝐸𝑓𝑓. (3)

Storage blocks do not have any effect on accuracy whereas quality blocks

typically produced better output data quality than that of the input data items. Quality

blocks representing specific pre-determined inspections and other validation tasks (e.g.

validity checks or checks for missing data elements) were considered as part of the

evaluation. However, implementation of quality blocks in the analysis was at a

relatively high level of abstraction. The rationale was to avoid a comprehensive

examination of the nature of the defects identified and the corrective action taken.

More importantly, this approach allowed the effect of the quality block to be applied

consistently in the simulations using a subjectively derived magnitude of improvement

(MI). By specifying the output data unit’s deficiencies as a fraction of the input data

units will give a consistent estimate for the effect of quality functions on input data.

This is computed using:

𝐴𝑐𝑐𝑂𝑢𝑡 = [1 − (1 − 𝐴𝑐𝑐𝐼𝑛) ∗ 𝑀𝐼]. (4)

As an example, QB1 listed in Table 6.3 has an estimated MI value of .25 for data

element ‘Medicare Ref No.’ which is located within data component CDPA2. This is

based on the notion that the individual’s Medicare card is visually checked to confirm

congruence with the data in the computer system. Based on equation (4), the quality

block will eliminate 75% of the difference between the quality of the input data item,

𝐴𝑐𝑐𝐼𝑛 = 0.935, and the highest possible quality of 𝐴𝑐𝑐𝑂𝑢𝑡 = 1 on a continuous scale

between 0 and 1. This will result in an output value of 0.983 for the data element in

output data item CDPA3.

Executing Accuracy Experiments

Model parameters were updated to simulate the effect of processing functions

on the quality of input data items for each system actor. Two groups of simulation

experiments were performed denoted as [System Actor]_AE1 and

[System_Actor]_AE2 utilising the cumulative and subtraction functional relationships

respectively to simulate process efficiency, see above for explanation. In this way,

information products received an accuracy score based on the quality of data

components and the compounded effect of errors resulting from multiple stages of

processing. For example, the ‘Clinical Summary’ IP represented as IPCN1 comprise

data elements from two raw data items which have undergone different stages of


processing. Thus, a weighted average was calculated based on the number of data

elements inherited from each raw data item in order to establish an overall accuracy

score.

A benefit of implementing an eHaaS design artifact is a reduction in functions

introducing errors. Thus, the purpose of including the second group of experiments

(AE2) is to advance understanding of the effect of human mediated transformation

functions in the information manufacturing process. In this respect, the purpose of

equation (3) is to emphasise the influence of transformation functions on individual

data elements. By adopting this approach, results brought to light the compounding

effect of errors caused by multi-source data elements when exposed to multiple stages

of processing. For example, elements of a patient’s demographic data, (e.g. name,

address, telephone number etc.), collected at the beginning of the business process may

undergo multiple transformation functions to be individually re-used as data elements

in the manufacture of different information products. As a result, the accuracy of

information products containing homogenous data elements may have different levels

of accuracy dependent on the type of transformation functions used in their

manufacture.

Timeliness – An Overview

The timeliness dimension of an IP is ensuring that information stored by the

system actor reflects state changes in the real world. Ballou, et al. (1998) posit that a

timeliness value is dependent on when the information is received by the consumer.

Thus, for a comparative analysis, they contend that a timeliness value can be used to

establish an absolute metric rather than a relative scale for measuring the effectiveness

of the system.

The first step in calculating timeliness requires a measurement of currency and

volatility. Currency is a function of (i) Delivery Time, when the IP is received by the

consumer; (ii) the Input Time, when the data unit is collected; and (iii) the Age of the

data unit, how old the data item is when it is received. Currency is defined as:

𝐶𝑢𝑟𝑟𝑒𝑛𝑐𝑦 = (𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑇𝑖𝑚𝑒 − 𝐼𝑛𝑝𝑢𝑡 𝑇𝑖𝑚𝑒) + 𝐴𝑔𝑒 (5)

Volatility is an indicator of the time an item remains valid. Its use is analogous

to the shelf life of a product (Ballou, et al., 1998). Data with high volatility will have

a short shelf life whereas others with low volatility may be infinite. In this way, sources


of raw or primitive data units will determine the length of time the data item remains

valid. Thus, it follows that timeliness is defined as a function of volatility and currency.

To derive the timeliness value for primitive data units requires the following equation

returning a number between 0 (poor) and 1 (excellent):

𝑇𝑖𝑚𝑒𝑙𝑖𝑛𝑒𝑠𝑠 = 𝑚𝑎𝑥 {0,1 −

𝐶𝑢𝑟𝑟𝑒𝑛𝑐𝑦

𝑉𝑜𝑙𝑎𝑡𝑖𝑙𝑖𝑡𝑦}. (6)

Operationalizing the Timeliness Simulations

As a first step, construction of the timeliness simulations proceeded with the

creation of process narratives documenting each transformation function with their

estimated completion times.

Figure 6.4. Example of IP-Map entities with input parameters and process narrative (CSHIS).

As an example, Figure 6.4 shows an excerpt of a process narrative containing

information that was used to formulate the input parameters for each simulation run.

The next step was the construction of spreadsheet models depicting the time

behaviours of each system actor. These models have to be dynamic in order to

represent the time-evolution of the system. To accommodate this, the flow of time was

approached in a next-event fashion progressing time from state to state. In this way, a

Input Block Output Activity Seq TTC Delay Narrative

Null DS1 RDPA1 1 1 0.0000

DS1 represents the patient registering for an episode of care. Form filling is a manual data collection process

performed by the patient to record their demographic information and medical history. This process represents

the start of a new workflow and as the point of reference for the analysis, the input time is set to 0.

CDVS6 DS2 RDCN2 3 1 0.0167

DS2 are observations of the patient's condition used to populate clinical notes. This is typically keyed directly into

the clinical system by the GP. The IP (IPCN1) is the clinical summary. We assume this is a short consultation (15

mins) with post consulation data entry estimated at 5 mins. The age of this data is 0 as it represents information

created by the clinician.

CDVS6 DS3 RDPR3 3 2 0.0033

DS3 commences the pathology test workflow. The IP is the pathology request order. DS3 cannot commence until

CDVS8 completes.

CDPA3 DS4 RDVS4 2 1 0.0083

DS4 represents the vital signs collected by the nurse pre-consultation - this proceeds the consultation. Its

volatility is high with a short shelf life due to the type of data. DS4 cannot commence until CDPA3 completes. We

have based this on the Time&Motion worksheet and rounded down to 5 minutes. Shelflife is set to 1 time period

(10 hours) in line with the policy directive - 3.2.3 from Royal Prince Alfred Hospital. (2010, June). Patient

Observation (Vital Signs) Policy - Adult.

IPPR2 DS5 IPPR2 4 1 0.0000

DS5 is a data source representing the patient presenting to the pathology lab with the test requisition order

IPPR2.

NULL DS6 RDSD6 5 1 0.0000

DS6 represents the commencement of the pathology test workflow which includes the collection of specimens,

its transfer to the lab for abalysis and post-analysis activities. The input to this workflow is the IPPR2 information

product created during the GP consultation workflow.

IPSD3 DS7 RDTR7 6 1 0.0000 DS7 represents the start of the analysis and post-analysis pathology tasks. Ths input for this process is IPSG3

CDTR12 DS8 CDTR12 7 1 0.0000

DS8 represents the receipt of pathology results by the requesting clinic in the form of a fax retrieved from a fax

gateway.


time line ordered by variable durations was constructed from time units calculated as

each activity completed.

Time estimates used by Ballou, et al. (1998) in their analysis of timeliness in a

healthcare scenario served as a baseline for experimentation e.g. their ten hour work

day was used to define a standard time period. Based on the notion that the time to

complete most tasks is typically measured in minutes, there was a requirement to

convert minutes to a value representing a proportion of the working day. This was

achieved by using:

𝑇𝑇𝐶 =

𝑀𝑖𝑛𝑢𝑡𝑒𝑠

60 ∗ 𝐻𝑟𝑠𝑊𝑜𝑟𝑘𝑒𝑑. (7)

Adopting a simple process interaction approach, data items and functional

processes can be added to the model in a sequence specified by the IP Maps. Once the

simulation framework was established, timeliness input parameters were derived.

Deriving the Timeliness Input Parameters

Simulation models can have numerous input variables and identifying those that

have a significant influence can be a formidable challenge. In light of this, parameter

variables were synthesised from the literature and values obtained from published time

and motion studies (Carvalho, et al., 2010; Overhage, et al., 2001; Pizziferri, et al.,

2005; Poissant, et al., 2005; Zheng, et al., 2010). Following is an overview of factors

used in the experiments, a full list of input parameters and process narratives is

included in Appendix F.

T1: A computed value that determines the time when an output data unit is

available for the next activity. TTC (Time to complete) and Delay are derived from the

activity producing the output data item.

𝑇1 = 𝑇2 + 𝑇𝑇𝐶 + 𝐷𝑒𝑙𝑎𝑦. (8)

T2: A computed value that determines the actual time when processing can

commence on input data items. Processing cannot commence until all data items are

available or at a scheduled time Delay. Current process time, ProcTime is compared

to ensure output from the function is synchronised correctly with the process timeline.

In this way, T2 is the larger of 𝑚𝑎𝑥{𝑡1 + 𝐷𝑒𝑙𝑎𝑦} and ProcTime. To account for

multiple input data items, mathematically let 𝑀𝐷𝐼 = {𝐷𝐼𝑇11+ 𝐷𝑒𝑙𝑎𝑦1, 𝐷𝐼𝑇12

+

𝐷𝑒𝑙𝑎𝑦2, … , 𝐷𝐼𝑇1𝑛+ 𝐷𝑒𝑙𝑎𝑦𝑛}, thus T2 is derived by:


𝑇2 = max[𝑀𝐷𝐼, 𝑃𝑟𝑜𝑐𝑇𝑖𝑚𝑒]. (9)

ProcTime: Describes the process timeline. A cumulative value derived from time

units associated with state transitions.

TTC: Time to complete is an estimated value provided as a parameter. Even

though the values were sourced from the literature, they are considered estimates.

Delay: A delay may result from a queuing or scheduling delay and is applied as

an estimated value. Delays are input from a parameter based on estimated upper limits

observed in clinical business processes.

𝐴𝑔𝑒(𝑦): A computed value that denotes the age of the data unit when it is

received by the activity. For simplicity, age is initialised to 0 as a raw data item and

treated as a simple cumulative equation:

𝐴𝑔𝑒(𝑦) = 𝐴𝑔𝑒(𝑥𝑖) + 𝐷𝑒𝑙𝑎𝑦𝑖 + 𝑇𝑇𝐶𝑖. (10)

Where there are multiple input data items, a composite age is computed using

the age of each input data item applied as a weighted average. Weighting is based on

the number of data elements inherited from the parent CDI. Mathematically. let

𝐴𝑔𝑒(𝑥𝑖) signify the age of 𝑥𝑖, let 𝑥𝑖𝑑𝑒denote the count of data elements inherited from

the input data item 𝑥𝑖 and let 𝑦 = 𝑓(𝑥1, 𝑥2, … , 𝑥𝑛) be the output data item. The

composite age of y is computed with:

𝐴𝑔𝑒(𝑦) =

∑ 𝑤𝑖 ∗ 𝐴𝑔𝑒(𝑥𝑖)𝑛𝑖=1

𝑛 . (11)

InputTime: Identifies when the data unit is obtained for processing. For the

purpose of this analysis, input time is set to the current process time stored in the

ProcTime variable. In the event of multiple input data components, a composite input

time is derived using a weighted average approach.

DelTime: Delivery time is the time the consumer receives the IP. Denoted as

DelTime, the variable is assigned a value stored in ProcTime at the point in time when

the IP is delivered to the consumer.

Currency: Indicates how promptly data is updated. The metric is computed by

subtracting the delivery time of the data item from the input time and adding the age.

ShelfLife: An estimated value input from a model parameter. In practice,

ShelfLife determines the period of time information has utility for the purpose it was


collected. Thus, it is reasonable to consider that the shelf life of data produced by care

events is limited to the point in time when it is delivered as an information product.

However, due to this definition, timeliness declines significantly when the IP is

delivered to the consumer. An assumption was made that the range constraint for shelf

life be calculated at a 10-time unit granularity (equivalent to two business weeks): 0 ≤

𝑆ℎ𝑒𝑙𝑓𝐿𝑖𝑓𝑒 ≤ 10. A 10-time unit shelf life is a reasonable metric for evaluating

information flows of the type typical for HCP/patient consultations and establishes a

consistent baseline for comparison. However, the impact of a standardised approach

includes inaccurate shelf life values for data elements with low volatility in the real-

world e.g. date of birth, gender or name.

Timely(y): Defines timeliness, a formulated value indicating the probability that

the IP received by the consumer is up to date. Refer above for a detailed discussion

about timeliness. In the event of multiple input data components, a composite

timeliness value was computed as an output from a process function. Let 𝑇𝑖𝑚𝑒𝑙𝑦(𝑥𝑖)

denote the timeliness of 𝑥𝑖, let 𝑥𝑖𝑑𝑒 represent the count of data elements inherited from

the input data item 𝑥𝑖 and let 𝑦 = 𝑓(𝑥1, 𝑥2, … , 𝑥𝑛) be the output data item. The

composite timeliness of y is computed with:

𝑇𝑖𝑚𝑒𝑙𝑦(𝑦) =

∑ 𝑤𝑖 ∗ 𝑇𝑖𝑚𝑒𝑙𝑦(𝑥𝑖)𝑛𝑖=1

∑ 𝑤𝑖𝑛𝑖=1

𝑤ℎ𝑒𝑟𝑒 𝑤𝑖 = ∑ 𝑥𝑖𝑑𝑒

𝑛𝑖=1

𝑥𝑖𝑑𝑒

. (12)

Executing Timeliness Experiments

For each system actor, two experiments were performed in order to analyse the

timeliness of information delivery times. The first experiment [System Actor]_TE1

measured the time to complete scenarios illustrated by the IP-Maps. The timeliness of

information products manufactured by the CSHIS was utilised as a baseline for

comparing the performance of the MyHR and eHaaS systems. However, the findings

in Chapter 4 indicate that information flows are influenced by delays due to manual

data management practices and outdated communication practices. Therefore, it was

necessary to conduct a second experiment which accounted for systems designed to

overcome delayed communication in information transfer. The second experiment

[System Actor]_TE2 examined the effects of each system actor based on the notion

that delivery-times of CDIs and IPs are determined by when information is made

available as a result of functional and process design benefits. For example, the


consumer should be able to access information immediately if created and stored using

Cloud native technologies. Taking this into account, any delays resulting from the

transfer of information were adjusted according to the design features of each system

actor.

6.6 RESULTS

6.6.1 CSHIS Results

A simulation of the CSHIS system actor was conducted in order to establish a

baseline control for comparison of the effects on different data outputs. Two groups of

experiments were performed to examine a systems actor’s effect on accuracy and

timeliness, each group comprising two experiments.

Table 6.4

CSHIS accuracy results for experiments CSHIS_AE1, CSHIS_AE2 and timeliness results for

experiments CSHIS_TE1, CSHIS_TE2

IP Description AE1 AE2 TE1 TE2

CDPA3 Patient Registration 0.983 0.959 0.992 0.992

IPCN1 Clinical Summary 0.987 0.969 0.996 0.996

IPPR2 Pathology Order 0.981 0.942 0.988 0.988

CDPR8 Order received in LIS 0.981 0.927 0.691 0.691

IPSD3 Specimen Details 0.990 0.959 0.874 0.874

CDTR12 Pathology Test results 0.985 0.951 0.240 0.240


History/Workflow

0.987 0.972 0.039 0.039

Mean1

0.985 0.954 0.689 0.689

Table 6.4 lists seven information products (IP) and component data items (CDI)

accompanied by their individual accuracy and timeliness results for each experiment.

1 Arithmetic mean is the ratio of the sum of a set of values to their total number in the set. Thus, the

arithmetic mean m for a total of n numbers in a data set with values given by a group of x-values can

be derived using the formula 𝑚 =𝑥1+𝑥2+⋯+𝑥𝑛

𝑛.


Their order, top to bottom, reflects the typical order of manufacture in a clinical

consultation and pathology specimen processing scenario.

CSHIS Accuracy

The first experiment CSHIS_AE1 returned an overall arithmetic mean of 0.985.

This indicated a likely error rate of 1.5% introduced across all data items, a low rate

when compared with those reported in the literature. However, results from the second

experiment (CSHIS_AE2) exhibited a mean of 0.954 indicating that errors were

introduced by functional processes at an average rate of 4.49%, which is significantly

higher. Typically, each IP and DCI comprise data elements from different sources

which may have passed through separate processing functions. As a consequence,

some data elements exerted a greater influence on accuracy at the component and

product level. For example, Figure 6.5 shows lower accuracy levels for items IPPR2

and CDPR8. Based on the assumptions of the analysis, this can be explained by the

influence of patient demographic information that have been subjected to multiple

human mediated transform functions. Thus, their influence is particularly emphasized

by the use of equation (3) in experiment CSHIS_AE2. However, for the purpose of a

comparative analysis, the results may be considered reasonable as they exhibit

behaviours that correspond with the real world.

Figure 6.5. CSHIS Accuracy Results for experiments CSHIS_AE1 and CSHIS_AE2.

CSHIS Timeliness

When information flows are examined through the lens of timeliness, results

from both experiments CSHIS_TE1 and CSHIS_TE2 show an overall mean of 0.689.


Whilst the result may suggest a satisfactory outcome, the significance of an IP’s

timeliness measure is subjective and open to interpretation by the consumer. This is

reflected in the DQ literature where variations in timeliness and availability cannot be

consistently explained. However, results of the CSHIS simulations serves as a

reasonable baseline to evaluate the effect of the MyHR and eHaaS simulation models.

Table 6.5

Attribute values derived from CSHIS timeliness experiment CSHIS_TE1

CSHIS TE1 CDPA3 IPPR2 IPCN1 CDPR8 IPSD3 CDTR12 IPTR4

Age 0.042 0.060 0.021 3.075 1.240 4.565 5.568

Input Time 0.000 0.033 0.095 3.116 3.125 3.126 3.126

Delivery

Time

0.042 0.095 0.116 3.132 3.141 6.161 7.163

Currency 0.084 0.123 0.042 3.091 1.255 7.600 9.606

Timeliness 0.992 0.988 0.996 0.691 0.874 0.240 0.039

Simulation

Time

0.042 0.095 0.116 3.132 3.141 6.161 7.163

Table 6.5 summarises key variables used with experiment TE1. Time to

complete all activities associated with a clinical consultation and pathology specimen

processing scenario measured 7.163 time units. Results from the second experiment

TE2 have not been included as the output was the same i.e. changes were not made to

the input parameters. The sequence in which each IP is manufactured, left to right, is

clearly represented in Table 6.5. As was expected, the Timeliness value declined as

the Age of an IP’s data elements increased. A weighted average was used to calculate

values where an IP or CDI comprise multiple input data items. For example, the

manufacture of the CDTR12 item required three separate CDIs, each with different

input times. Therefore, to accurately calculate the effect on timeliness required derived

weighted averages using the age and input time of data components at the time of

manufacture. Based on the scope and assumptions of the analysis, these results may

be considered a reasonable approximation of the corresponding real-world.


6.6.2 MyHR Results

MyHR Accuracy

Table 6.6 summarises the results for MyHR accuracy experiments MyHR_AE1,

MyHR_AE2 and timeliness experiments MyHR_TE1, MyHR_TE2.

Table 6.6

MyHR accuracy and timeliness results for experiments MyHR_AE1 and MyHR_AE2


CDPA3 Patient Registration 0.985 0.961 0.992 0.992

IPCN1 Clinical Summary 0.988 0.972 0.997 0.997

IPPR2 Pathology Order 0.981 0.944 0.987 0.987

CDPR8 Order received by LIS 0.983 0.932 0.691 0.691

IPSD3 Specimen Details 0.990 0.962 0.858 0.858

CDTR12 Pathology Test results 0.985 0.953 0.233 0.233


History/Workflow

0.984 0.952 0.032 0.232

Mean

0.985 0.954 0.684 0.713

With an overall mean value measuring 0.985, the MyHR_AE1 result is not

statistically distinguishable from the CSHIS results. This is reasonable due to several

common functional processes. Similarly, the results of the second experiment

MyHR_AE2 shows an overall mean value of 0.954 which is also comparable to the

CSHIS results. In this instance, whilst the influence of individual data elements is

emphasised, it is not enough to make a measurable difference overall due to the

moderating effect of functional processes not included in both simulation models.

MyHR Timeliness

Timeliness results for experiment MyHR_TE1 shows an overall arithmetic mean

of 0.684 which is marginally lower than the CSHIS_TE1 result at 0.689. This variance

can be explained by the influence of additional data elements and processes unique to

the MyHR simulation model. As expected, Table 6.7 shows a total simulation time of

7.161 time units which is consistent with the CSHIS simulation.


Table 6.7

MyHR timeliness results for experiment MyHR_TE1

MyHR TE1 CDPA3 IPPR2 IPCN1 CDPR8 IPSD3 CDTR12 IPTR4

Age 0.042 0.063 0.021 3.078 1.409 4.638 5.641

Input Time 0.000 0.030 0.112 3.117 3.125 3.126 3.126

Delivery Time 0.042 0.095 0.117 3.132 3.141 6.159 7.161

Currency 0.084 0.128 0.026 3.093 1.425 7.671 9.676

Timeliness 0.992 0.987 0.997 0.691 0.858 0.233 0.032

Simulation

Time

0.042 0.095 0.117 3.132 3.141 6.159 7.161

Adjusted delay values were applied in experiment MyHR_TE2 in order to

examine the effects of accessing Cloud based pathology test results. An overall mean

of 0.713 representing a 4.23% improvement in timeliness when compared with the

MyHR_TE1 experiment was observed. Similarly, a 3.48% improvement in average

timeliness emerges when compared with the equivalent results of the CSHIS

experiments. This may be explained by additional MyHR functionality which permits

pathology test results (IPTR4) to be uploaded to a Cloud based record. Thus, the delay

resulting from transmission, receipt and reconciliation activities typical of the CSHIS

model has been eliminated in the MyHR model.

Table 6.8

MyHR timeliness results for experiment MyHR_TE2


Age 0.042 0.063 0.021 3.078 1.409 4.638 4.641

Input Time 0.000 0.030 0.112 3.117 3.125 3.126 3.126

Delivery

Time

0.042 0.095 0.117 3.132 3.141 6.159 6.161

Currency 0.084 0.128 0.026 3.093 1.425 7.671 7.676

Timeliness 0.992 0.987 0.997 0.691 0.858 0.233 0.232



Simulation

Time

0.042 0.095 0.117 3.132 3.141 6.159 6.161

As highlighted by Table 6.8, this has the effect of reducing the end-to-end

process time from 7.161 time units reported by experiment MyHR_TE1 to 6.161 time

periods. The results suggest that measurable improvements are achievable if current

business processes are altered to take advantage of MyHR functionality. It is

noteworthy however, that the timeliness benefits gained from uploading IPTR4 had a

negative influence on the accuracy of this information product.

6.6.3 eHaaS Results

Table 6.9 summarises the results for accuracy experiments, eHaaS_AE1,

eHaaS_AE2 and timeliness experiments eHaas_TE1, eHaaS_TE2.

eHaaS Accuracy

An overall mean of 0.995 reported by experiment eHaaS_AE1 indicates a high

level of accuracy on a scale of 0 (poor) to 1 (excellent). When compared to the results

from the CSHIS and MyHR models, the experiments confirm that an eHaaS design

artifact will deliver greater information quality improvements.

Table 6.9

eHaaS accuracy results for experiments eHaaS_AE1, eHaaS_AE2 and timeliness results for

experiments eHaaS_TE1. eHaaS_TE2


CDPA3 Patient Demographic Data

(CIS)

0.993 0.987 0.890 0.890

IPPR2 Pathology Order (CPOE) 0.997 0.994 0.984 0.984

CDCN8 Clinical Summary (CIS) 0.991 0.982 0.968 0.968

CDPR10 Pathology Order (LIS) 0.995 0.991 0.314 0.914

IPSD3 Specimen Details (LIS) 0.996 0.992 0.606 0.949

IPTR4

(CDTR12)

Pathology results (LIS) 0.992 0.988 0.190 0.332



IPMD5 Patient History (ePatient) 0.997 0.995 0.135 0.454

Mean

0.995 0.990 0.584 0.784

This trend is reflected by the results of experiment eHaaS_AE2 which reported

an overall mean of 0.990. In comparison to the first experiment, a standard deviation

of 0.004 with a 95% confidence level of .004 signals a wider distribution around the

average. This result is consistent with the error amplifying effect of equation (3) on

functional processes. However, this effect is marginal when comparing the results of

the two experiments. This suggests that an eHaaS design can be more successful at

reducing the introduction of errors during processing.

eHaaS Timeliness

The timeliness results for experiment eHaaS_TE1 shows an overall mean value

of 0.584 for timeliness indicating a relatively poor performance comparatively. This

may be attributed to the inherent design of eHaaS architecture. No consideration has

been given to process redesign or the way the technology should be integrated into

extant clinical practice in these experiments. Thus., the notion of using single source

information suggests that data elements will typically have a greater Currency value

which is a measure of how long ago the information was recorded which in turn will

have a negative effect on timeliness.

Table 6.10

eHaaS timeliness results for experiment eHaaS_TE1

eHaaS TE1 CDPA3 IPPR2 CDCN8 CDPR10 IPSD3 IPTR4 IPMD5

Age 0.552 0.149 0.318 3.456 1.984 4.901 5.967

Input Time 0.000 0.602 0.631 0.234 1.692 1.766 1.795

Delivery Time 0.552 0.614 0.634 3.636 3.646 6.663 7.664

Currency 1.105 0.161 0.322 6.858 3.937 9.799 11.836

Timeliness 0.890 0.984 0.968 0.314 0.606 0.190 0.135

Simulation

Time

0.552 0.614 0.634 3.636 3.646 6.663 7.664


In contrast, the results from experiment eHaaS_TE2 shows a 25.6%

improvement over the results from the first experiment with an overall mean of 0.784.

Table 6.11 shows that an adjustment of delay parameters to complement eHaaS design

features resulted in all activities completing within 3.664 time units. This represents a

significant improvement from experiment eHaaS_TE1 and a meaningful improvement

when compared to the CSHIS and MyHR simulation models.

Table 6.11

eHaaS timeliness results for experiment eHaaS_TE2

eHaaS TE2 CDPA3 IPPR2 CDCN8 CDPR10 IPSD3 IPTR4 IPMD5

Age 0.552 0.149 0.318 0.456 0.270 3.341 2.777

Input Time 0.000 0.602 0.631 0.234 0.407 0.326 0.985

Delivery Time 0.552 0.614 0.634 0.636 0.646 3.663 3.664

Currency 1.105 0.161 0.322 0.858 0.509 6.679 5.456

Timeliness 0.890 0.984 0.968 0.914 0.949 0.332 0.454

Simulation

Time

0.552 0.614 0.634 0.636 0.646 3.663 3.664

6.7 DISCUSSION

The purpose of simulating a clinical consultation and pathology specimen

analysis scenario was to compare and contrast the capability of three system actors to

deliver health information quality improvements. Thus, the goal of this section is to

provide a systematic description of the effectiveness of design choices for large scale,

distributed information management systems. In this way, the CSHIS system actor

provides a baseline comparison in which to examine the efficacy of MyHR and eHaaS

system design choices.

6.7.1 Accuracy

In many respects, the results reported by the MyHR simulation are not

significantly different from those observed with the CSHIS simulation. As predicted,

there was a high level of congruence in results due to common functional processes

which may be viewed as an intentional design choice centered on integrating the

MyHR with existing clinical workflows.


Figure 6.6. Information manufacturing system results for accuracy experiment AE1 by information

product2.

The modest difference in accuracy observed between the MyHR_AE1 and

CSHIS_AE1 experiments illustrated by Figure 6.6 can be explained by the MyHR

unique Individual Health Identifier (IHI) data element which increased the overall

mean from 0.984 to 0.985. The introduction of an IHI data element which is easily

validated has a statistically positive effect on reducing accuracy deficiencies. It is

noteworthy however, that in the context of the MyHR, the prescribed use of the IHI is

perceived as a barrier to adoption by some health care professionals (Royle, et al.,

2013).

The second experiment using the subtraction functional relationship indicates

that while there is congruence in the accuracy of several output data items created by

the CSHIS and MyHR simulations, Figure 6.7 shows a large variation observed with

the IPTR4 data item. A higher accuracy value of 0.972 (CSHIS_AE2) when compared

to a result of 0.952 (MyHR_AE2) can be explained by the inclusion of quality block

QB4 in the CSHIS model. The quality block encapsulates the reconciliation of

pathology results with a patient’s record thereby having a positive effect on accuracy.

This validation process is omitted from the MyHR simulation model because test

2 Data names in parentheses denote corresponding data items used by the eHaaS simulation models


results are typically uploaded to the MyHR repository by the creator i.e. the report is

not transmitted to the requesting clinic thereby omitting the quality checking process.

Figure 6.7. Information manufacturing systems results for accuracy experiment AE2 by information

product.

Processes intended to support manual data management practices in this instance

demonstrates a positive influence on accuracy. This places particular emphasis on the

notion that information quality management is about more than just technology, it is

also about processes. In a discussion about information quality taxonomies, Batini and

Scannapieco (2016) refer to an information-driven vs. process-driven classification

that relate to general strategies for delivering quality improvements. An information-

driven approach is founded on the exclusive use of information sources to improve

information quality. However, this approach has to be repeated which will lead to

higher costs in the long term. With a process-driven approach, the information

manufacturing process is examined and potentially redesigned to remove the root

cause of quality issues.

Process-driven strategies are characterised by two phases: process control and

process redesign. Process control applies checks and control procedures to the

information manufacturing process whenever modification events are detected as a

means to mitigate error propagation and information degradation. Process redesign is


applied to manufacturing processes in order to produce better quality information and

to remove the root cause of quality issues. In this respect, a process-driven approach

optimises the effectiveness and cost of information quality management.

On closer inspection, a principle driver for the MyHR business case is the

aggregation of patient records in order to optimise collection and searching of

information. However, many of these data collection functions encompass manual

processes, e.g. patient registration, pathology test orders and specimen collection.

While patient demographic data is available in electronic format with the MyHR, the

existing practice of using paper-based documents with electronic patient records

invariably result in data inconsistencies. These inconsistencies are subsequently

magnified by downstream functional processes and potentially transferred back to the

MyHR. Moreover, MyHR design and policy choices which include collection of

information at the summary level as well as voluntary clinical participation has

fostered the perception that the system is pointless. In this respect, recommendations

by the Australian Medical Association suggest that the record should only be used as

a memory prompt for the patient (Glance, 2015). These factors perhaps hinder any

meaningful contribution to the quality of clinical information particularly within cross

boundary and cross institutional scenarios.

In its current implementation, it is reasonable to perceive the MyHR as a clinical

document management system where accessibility to patient information is improved

however, there is no significant improvement in the accuracy of information. As a

comparison, the eHaaS simulation model did affect the level of accuracy observed in

information products. Figure 6.6 illustrates consistent improvement in accuracy levels

for all IPs and CDIs and this is further emphasized by results from the AE2 group of

experiments. Figure 6.7 compares the AE2 accuracy levels for the three system actors

bringing to light the impact of cumulative errors resulting from transformation

functions. Cumulative error rates are more marked in data items which have been

subjected to two or more human mediated transform functions (e.g., CDPR8).

However, it is the disproportionate variance reported by results of experiment

eHaaS_AE2 that bears further examination. Individual data items and data production

constructs were examined to see if there is a causal relationship between processing

efficiencies and the accuracy of their component data items.


Table 6.12

Functional processes evaluated for each system actor (information manufacturing systems)

Type CSHIS MyHR eHaaS

Raw Data Sources 8 8 10

Processes 8 8 17

System Boundaries 5 5 2

Organizational Boundaries 2 2 2

Quality Blocks 4 3 4

Storage Blocks 2 3 5

Table 6.12 lists functional processes, data sources and other data production

constructs used by each model. Of note is the number of functional processes observed

with the eHaaS simulation model, which is greater than the combined total of the

MyHR and CSHIS models. Similarly, there is a noticeable difference in the number of

system boundaries, the eHaaS model has less than half that of the other two system

actors. Intuitively, this would suggest that an increase in processing functions and a

decrease in system boundaries will have a positive effect on information quality.

Table 6.13

Data collection processes and system boundary transitions

Process CSHIS MyHR eHaaS Description

P1(eHaaS) X Individual updates demographic data

online (ePatient service).

P1(CSHIS/

MyHR)

X X Individual manually completes

registration form in clinic.

SB1 X X Patient registration form transcribed into

clinical information system (CIS).

P2 X X X Pre-consultation check - nurse updates

patient record.

P7 X X X Post-consultation - Clinician enters

consultation notes.


Process CSHIS MyHR eHaaS Description

P5(eHaaS) X Create diagnostic test order online (ePOE

service).

SB2 X X Clinician manually completes pathology

test order form.

SB4 X X Lab reception transcribe requisition order

into laboratory information system (LIS).

P6 X X X Technician updates patient record with

specimen details.

P12 X X X Lab enters analysis findings into LIS.

Table 6.13 offers a closer examination of the functional processes used to

manufacture IPs offering insights into the differences between the simulation models.

Two processes prefixed with P1 represent the collection of demographic information

from the individual. However, within the context of the eHaaS model, this information

is entered directly into an online health record by the individual with a predicted error

rate of 2.42%. Whereas, the MyHR and CSHIS models utilise a manual method for

collecting information requiring an additional system boundary block, (SB1) in order

to transfer the information to an electronic format. Based on the assumptions listed in

Appendix F, the inclusion of this system boundary will result in an error rate of 2.58%.

Similarly, eHaaS process P5 represents the creation of an online pathology test

order by the clinician which, based on the study assumptions, will have a 2.42% error

rate. In contrast, both the CSHIS and MyHR models utilise human mediated

transformation functions resulting in two additional system boundaries. Firstly, system

boundary SB2 represents the handwritten creation of the pathology test order by the

clinician with a predicted error rate of 2.42%. Secondly, system boundary SB4 is

defined as the transcription of the pathology test order into the laboratory information

system (LIS) with a predicted error rate of 2.58%. The effect of these functions

highlights the impact of cumulative errors resulting from transformation functions.

Ballou and Pazer’s (1985) observation that the influence of errors may be diminished

or accentuated by functional processes brings into sharp focus the implications of

minimising manual (human) activities. The literature identifies human error as a

principal cause of data problems (Experian Information Systems, 2015), with a high


degree of errors occurring at transition points in the care process (Cain & Haque,

2008). Therefore, a reduction in data collection processes and system boundary

transitions requiring human intervention observed with eHaaS clearly demonstrates a

positive influence on accuracy levels.

The information quality literature suggests that data errors are common and often

non-random. Only a small number of errors can be stopped by commonly applied

information quality methods. For example, integrity checks or constraints by

parameter-specific ranges address only a small percentage of potential errors

(Goldberg, et al., 2008). To remain effective, data driven strategies require an iterative

approach resulting in increasing cost implications in the long term. Whereas process-

driven techniques, specifically process redesign activities deliver a more effective

result by addressing the root cause to resolve problems permanently (Batini &

Scannapieco, 2016). To locate the concept in the context of this thesis, the data-driven

approach employed by the MyHR focuses on data integration, standardisation and

error localisation and correction. In contrast, an eHaaS design artifact seeks to optimize

health information quality through process improvement. This requires the

minimization of human mediated transformation activities through the use of

automation and process redesign. This is reflected by design choices that include

service-based architecture and single source information propagation concepts. More

importantly, the technology is grounded in eHaaS architecture which embraces the

redesign of information production processes. The eHaaS simulation model has

successfully demonstrated the benefits derived from accessing SSOT information

using a context-aware federated model. From an accuracy perspective, it is reasonable

to conclude that the meta-design principles operationalised with the eHaaS model

shows evidence of a positive effect on accuracy.

6.7.2 Timeliness

Table 6.14 summarises the results from the TE1 group of experiments. The

MyHR result with a value of 0.684, (overall arithmetic mean) is marginally lower than

the CSHIS result of 0.689. The eHaaS model results however, indicate a mean value

of 0.584 for timeliness suggesting a relatively poor performance in comparison. Part

of the variance between CSHIS and MyHR can be explained by the greater age of

additional data elements included in MyHR component data items which will

influence the currency value e.g. the Individual Health Identifier (IHI). This is


reasonable according to Islam (2013) who posits that age plays a significant role in

regulating the timeliness of data.

Table 6.14

Timeliness results for experiment TE1by information product

Manufactured Data Items CSHIS MyHR eHaaS

CDPA3 0.992 0.992 0.890

IPCN1 (CDCN8) 0.996 0.997 0.968

IPPR2 0.988 0.987 0.984

CDPR8 (CDPR10) 0.691 0.691 0.314

IPSD3 0.874 0.858 0.606

CDTR12 (IPTR4) 0.240 0.233 0.190

IPTR4 (IPMD5) 0.039 0.032 0.135

Mean 0.689 0.684 0.584

Using a weighted average approach to calculate combined ages of multiple input

data items highlights this sensitivity. Similarly, an additional .0008 variance between

the CSHIS and MyHR models can be explained by a difference in the flow of time.

Using a next-event approach to progress time from state to state increases sensitivity

to changes in the sequence of processes. Both models employ many common

functional processes however, some of these functions may be completed in parallel

or in a different sequence. Nonetheless, the variance in timeliness between CSHIS and

MyHR is statistically insignificant with little evidence that the MyHR will have a

positive effect on the timeliness of information.

Results from the eHaaS TE1 simulation shows the significant effect of manual

processing delays on the eHaaS model’s inherent design. Patient demographic

information self-entered online prior to attending the clinic has a negative effect on the

timeliness of data item CDPA3 when compared to other system actors. To investigate

this further, Figure 6.8 illustrates how the timeliness of data items decline rapidly when

a short shelf life (volatility) is applied. In this scenario, ten time units were used as a

standardised approach for all items and simulations. Whilst all three system actors

exhibit the same behaviours, the eHaaS simulation model did not perform as well in


comparison. This can be explained by the poor Currency value of input component

data item CDPA3 which includes patient demographic data elements entered online

i.e. some CDPA3 data elements have an earlier input-time and therefore a greater age.

Figure 6.8. Information manufacturing systems results for timeliness experiment TE1 by information

product.

Data elements inherited by data item CDPR10 from CDPA3 are subject to this

standardised approach whereas in the real-world they may in fact have extremely low

volatility e.g. an individual’s date of birth or name. It is noteworthy however, that the

IPMD5 output data item shows an improvement in timeliness when compared with the

MyHR and CSHIS models. This is the result of six input data components applied as

weighted averages. IPMD5 represents the materialised view of a patient’s workflow

and thus will include timely workflow meta-data created dynamically as information

is produced.

The results from the TE1 group of experiments indicated weak statistical

evidence that MyHR and eHaaS system actors produced a change in IP timeliness.

This was not unexpected in the context of a healthcare system characterised by

business processes intended to support manual data management practices. As the

discussion above suggests, process redesign plays a significant role in removing the

causes of poor information quality. To test this, a second group of experiments (TE2)

were performed to examine the effects of each system actor based on the notion that

CDI and IP delivery-times are determined by when the information is created.

Specifically, it is assumed that consumers can access information immediately if the


IP is created by Cloud native applications. To reproduce this, delays resulting from

processes associated with the transfer of information were adjusted according to design

features and functionality specific to each IMS.

Table 6.15

Summarised Timeliness results for experiment TE2 by data items

Timeliness CSHIS MyHR eHaaS

CDPA3 0.992 0.992 0.890

IPCN1 (CDCN8) 0.996 0.997 0.968

IPPR2 0.988 0.987 0.984

CDPR8 (CDPR10) 0.691 0.691 0.914

IPSD3 0.874 0.858 0.949

CDTR12 (IPTR4) 0.240 0.233 0.332

IPTR4 (IPMD5) 0.039 0.232 0.454

Mean 0.689 0.713 0.784

Table 6.15 summarises the results from the TE2 experiment which shows that

the CSHIS results are consistent with the results of experiment CSHIS_TE1. What is

interesting is the change in overall arithmetic mean observed with MyHR_TE2 (.713)

representing a 4.24% improvement in timeliness. Similarly, experiment eHaaS_TE2

(.784) reported a 34.25% improvement over the equivalent TE1 results. Whilst, the

overall improvement in timeliness observed with the MyHR is marginally significant,

the results of individual data items remain consistent with corresponding output data

items produced by the CSHIS model. In contrast, the eHaaS results show a significant

difference from the first experiment (eHaas_TE1) and a meaningful improvement

when compared to the other system actors.

The effects of removing delays caused by a reliance on outdated communication

practices and manual data collection processes is emphasized in Figure 6.9. The

decline in timeliness is less severe given that information is made available to the

consumer in real time. Concomitant with an improvement in timeliness, the eHaaS


model significantly reduced the end-to-end process time of a clinical scenario to 3.664

time units, (compared to - CSHIS_TE2:7.163 and MyHR_TE2:6.161).

Figure 6.9. Information manufacturing systems results for timeliness experiment TE2 by information

product.

A reasonable conclusion prior to experimentation is that the time to complete an

end-to-end process is largely influenced by the activities of the patient. However, on

closer inspection, there are several factors that are determined by the type of functional

processes. Attendant to the temporal vagaries of spanning interorganizational

boundaries, delivery of information is principally influenced by internal administrative

factors. These include dissemination policies and practices inculcated within the

sending healthcare organization, e.g. batched overnight or sent as they are created.

Similarly, at the receiving end, receipt and reconciliation practices of the requester

contribute to temporal overheads, e.g. results may be processed at scheduled times or

in an ad hoc manner. Other temporal factors like time-of-day and day-of-week further

highlight the sensitivity to the influence of administrative practices. As an illustrative

example, retrieval and reconciliation of faxed pathology results may take up to two

business days before information reaches the intended recipient as reported by one

medical centre in the southern suburbs of Brisbane, Australia. Therefore, results from

the eHaaS_TE2 experiment provides evidence that an eHaaS design artifact can

deliver patient information in a timely manner information when coupled with process

redesign activities.


6.8 CONCLUSION

In this chapter, a novel evaluation strategy encompassing a combination of data

modelling and business process modelling techniques was used to quantitatively

examine information quality. Computer simulations provided a process-driven

analysis of the effectiveness of information production functions observed with three

system actors. In this respect, an examination of the eHaaS design artifact produced

insights about the quality improvements achievable with the implementation of

process oriented service-based architectures. As a means for validating a design

artifact, there is evidence that the techniques and methods used in this ex ante

evaluation holds utility. In light of this, these concepts will help to extend conventional

thinking about process-driven evaluation for information quality in other domains.

A key learning from the analysis is that the benefits achievable with an eHaaS

design artifact are constrained by extant administrative processes. As an enabling

technology, eHaaS architecture must be perceived as the stimulus for innovative

redesign of core administrative processes. This is not suggesting that healthcare

processes require redesign, the focus should be on what eHaaS can improve within the

environment. As the literature suggests, the aim is to avoid simply automating

processes and services and migrating them to the web which is fraught with problems.

Whilst this is not a new idea, consideration must be given to understanding clinical

workflows and how clinicians work. Thus, it is reasonable to conclude that eHaaS and

MyHR can affect a positive change in the quality of clinical information when coupled

with process redesign activities. More importantly, a testable proposition suggesting

that the implementation of an eHaaS design artifact will deliver measurable

information quality improvements was demonstrated. Findings from this analysis

provides empirical evidence about the validity of the proposition establishing a

compelling recommendation for implementing an eHaaS solution.

180 Chapter 7: Conclusions

Chapter 7: Conclusions

In the context of Australian primary healthcare settings, this thesis presented a

case study for the creation of an innovative eHealth-as-a-Service (eHaaS) design

artifact which delivers measurable information quality (IQ) improvements. Adopting

a problem-centred approach, research efforts aimed to create and validate a purposeful

design artifact. Problem solving was premised on the proposition that an observable

causal relationship existed between eHealth architecture and IQ. This prompted three

research directions encapsulated within a linear problem-solving process:

1. Problem identification and definition – As a critical dimension of

coordinated delivery of care, effective communication and information

transfer across care settings and access to holistic patient information is

perceived by patients as necessary (Waibel, et al., 2011). Therefore,

consolidating understanding about patient information flows within primary

healthcare settings emerges as a critical precursor for designing systems to

improve care coordination.

2. Design and develop – limited research explaining the effects of technical

solutions on sharing electronic patient information establishes academic

purpose for designing and demonstrating eHealth architectural forms and

functions to solve a real-world problem. A systematic approach to the

validation of testable propositions emerging from the design process

advanced knowledge in this area.

3. Evaluate – little attention has been given to effective methods for examining

the role of information quality as a mediator between information

technology architecture and healthcare quality (Byrd & Byrd, 2012).

Development of an evaluation strategy examining operational information

at the data structure, data flow and business process level will provide

important insights into the complex interrelationships between these

dimensions of an eHealth solution.

Whilst all three research directions require further investigation, findings

emerged from this thesis giving evidence of clear and verifiable contributions to

Chapter 7: Conclusions 181

advance knowledge in the area of health informatics, information quality and

healthcare service management. As a research outcome, it was considered reasonable

that adopting a domain driven design approach, microservice architecture and an

‘outside in’ implementation strategy would result in a solution that delivers measurable

information quality benefits in primary healthcare settings.

7.1 RESEARCH CONTRIBUTIONS

This thesis is a case study for the creation and evaluation of distributed systems

architecture which solves the real-world problem of improving patient information

flows and information quality in primary healthcare. In this respect, eHaaS

demonstrates the practical benefits of process oriented, service-based information

systems by encapsulating a set of design principles, architectural patterns, service-

based applications and implementation strategies. Another significant contribution of

this research identified the patient’s journey as a central organizing mechanism for

orchestrating contextualized electronic information services. Considering this, the

eHaaS framework was designed to support individualised patient care pathways by

delivering coordinated process-driven application services. By doing so, clinicians

were able to form a central organising picture of patients’ personal journeys for more

effective coordination of care. More importantly, this approach to systems

development has application outside the healthcare domain. These include supply-

chain, complex customer service environments and asset management. As use cases,

asset intensive industries such as aerospace, automotive, industrial products and

defence require improved management of complex, high-value assets across all stages

of their life cycle. In this context, concepts and techniques developed for eHaaS, (e.g.

domain driven design, microservices and context aware federated strategies), may be

applied in the propagation of contextualized information about assets ‘in the field’

providing a consistent view both within and across an asset’s entire lifecycle.

Several practical contributions also emerged from this thesis. Chapter 2 provided

an account of how Australia’s summary health record system (MyHR) was designed,

developed and implemented and was compared with other international eHealth

projects. Important concepts informing the development of the proposed eHaaS

conceptual model were synthesized from themes emerging from this comparison. Key

stakeholders were also identified with an examination of whether their expectations

had been met and if not why not. Conclusions were corroborated by findings from an


in-depth ethnographic analysis presented in Chapter 4 consolidating understanding

about how health information is created and propagated within a patient’s journey. It

was concluded that a plausible causal relationship exists between eHealth architecture

and IQ. The ethnographic analysis also identified that care processes are emergent in

nature, predisposed to organic growth rather than intelligent design. For this reason,

eHealth systems must be flexible enough to allow architectural innovation on a

structural level and malleable enough to support the information requirements of

complex care pathways. Abstract meta-requirements and normative design principles

were derived from these findings to define the overall solution space. This informed

the conceptualization of the functions, organization, and structure of an innovative

eHaaS design artifact which was presented in Chapter 5. When compared to other

eHealth implementations, a significant point of difference is the artifact’s dynamic

composition of discreet process oriented application services. As an instantiation of

the eHaaS design artifact, a novel electronic patient information management system

(ePIMS) was presented. ePIMS demonstrated some of the innovative features of a

system designed for improving information quality in cross boundary and cross

institutional scenarios. Key differences were identified in a comparison between the

eHaaS artifact and existing Australian healthcare system actors underscoring the

potential for eHaaS as an alternative solution for complex clinical scenarios.

An examination of how well an eHaaS design artifact addressed the selected

real-world scenarios in Chapter 6 motivated the development of a novel approach for

evaluating service-based information services. Computer simulations used with data

modelling and business process modelling techniques provided a process-driven

analysis of the effectiveness of eHealth systems to improve information quality. One

of the more significant findings was empirical evidence showing the influence of

design choices on information quality attributes. Quantifiable metrics were defined

and prioritized in order to evaluate the effectiveness of eHealth systems to resolve

certain information quality issues. In this respect, it was concluded that quality

attributes, accuracy and timeliness, may lead to improved continuity of care (Banfield,

et al., 2013; Elder, et al., 2004). From an accuracy perspective, simulations modelling

the ePIMS design artifact showed a lower risk of introducing accuracy deficiencies to

information manufacturing processes. Whereas simulations of Australia’s National

EHR system (MyHR) and traditional healthcare information system (CSHIS), which


is largely paper based, resulted in a higher likelihood of error propagation and

information degradation. It was observed that cumulative error rates were more

marked in data items which have been subjected to human mediated transform

functions which are significantly reduced with eHaaS. However, a high level of

congruence in CSHIS and MyHR results were due to many common functional and

human mediated transform processes. Therefore, in its current implementation, it is

reasonable to perceive the MyHR as a clinical document management system where

accessibility to patient information is improved however, there is no significant

improvement in the accuracy of information.

From a timeliness perspective, results from the eHaaS simulation reported a

decrease in the average timeliness of information products when compared with the

results of the CSHIS simulation. In comparison, the MyHR showed a more modest

decrease. Based on these findings, it was concluded that there is no evidence to suggest

that the MyHR and eHaaS systems produced a positive change in the timeliness of

information products. However, this result must be considered in the context of a

healthcare system characterised by administrative processes intended to support

manual data management practice. This emphasizes the role of process redesign in

removing the causes of poor information quality. To test this, a second group of

experiments adjusted process delays according to design features and functionality

specific to each system. Results from the eHaaS experiment showed a marked

improvement in the average timeliness of information products when compared with

the CSHIS results. In comparison, the MyHR showed a more modest improvement.

Through this lens, it is reasonable to conclude that the benefits achievable with

eHaaS architecture may be constrained by extant administrative processes. Therefore,

implementation of an eHaaS solution must be underpinned by redesign of

administrative processes where required in order to avoid simply automating existing

processes and services. Consideration must also be given to understanding clinical

workflows and how HCPs work.

7.2 VALIDATING THE PROGRAM OF WORK

A key benefit of adopting a DSR approach is the use of prescriptive guidelines

for guiding the design and evaluation processes. As discussed in Chapter 3, the

framework for effective DSR proposed by Hevner and colleagues offers seven


guidelines which is useful for validating an information systems (IS) research program

of work (Hevner, et al., 2004). The guidelines are used in the following sub-sections

as a validation framework to determine how well the contribution of this thesis satisfies

the intent of the DSR framework and demonstrates the contribution made to

scholarship, research and practice.

7.2.1 Problem Relevance

The objective of DSR is to develop technology-based solutions to address

important and relevant business problems. The problem domain addressed by this

thesis was located in the efficacy of eHealth and the challenge of delivering large scale

(national) eHealth programs to improve patient IQ. This was observed with the

implementation of a national EHR system which, at a cost of over A$2.5 billion,

continues to experience ambivalence from healthcare professionals (HCP) and patients

limiting its contribution to information quality improvements (Dearne, 2014). In

contrast, Cloud and Enterprise Computing technologies are maturing in other domains

creating opportunities for service innovation and information quality improvements

which could be translated to healthcare (Adenuga, Kekwaletswe, & Coleman, 2015).

7.2.2 Design as a Search Process

The search for an effective artifact requires utilizing available means to reach

desired ends while satisfying laws in the problem environment. In this respect, a

review of eHealth literature and an analysis of Australia’s national EHR system in

Chapter 2 provided the context for the examination of a patient’s journey. This

consolidated understanding about the impact of the ‘My Health Record’ (MyHR)

system on patient information flows which will be examined in Chapter 4. Meta-

requirements and design principles grounded in kernel theories were synthesised from

the findings and informed design and architectural concepts for an eHealth-as-a-

Service design artifact in Chapter 5.

7.2.3 Design as an Artifact

Design science research must produce a viable artifact in the form of a construct,

a model, a method, or an instantiation. To achieve this, a conceptualization of eHaaS

was offered as a design artifact in Chapter 5. Drawing on Cloud computing and

service-based architecture concepts, an eHaaS conceptual model was proposed as an


alternative solution for delivering information quality improvements in Australian

primary healthcare settings.

7.2.4 Design Evaluation

The utility, quality, and efficacy of a design artifact must be rigorously

demonstrated via well-executed evaluation methods. Adopting an explanatory

research approach characterised by experimental research in laboratory settings,

evaluation of an instantiation of an abstract eHaaS conceptual model was conducted

in two phases. In the first phase, the effectiveness of the artifact was demonstrated in

Chapter 5 using BPMN diagrams and simulated scenarios. The second phase was

attended to in Chapter 6 with the use of computer simulations and a comparative

analysis to observe the impact of the design artifact on the problem it is intended to

address. The effectiveness of the artifact to exhibit a change (improvement) when

compared to the performance of existing artifacts was also validated.

7.2.5 Research Rigor

Design science research relies on the application of rigorous methods in both the

construction and evaluation of the design artifact. Consequently, the design and

evaluation of an eHaaS artifact within a DSR framework establishes a rigorous

foundation for the layering of research activities drawing on kernel theories from

reference disciplines which include semiotic theory, information services view and

service-based architecture. Kernel theories provide the explanatory knowledge that

guide the design process and explains why the design works. In this way, claims for

the efficacy of an eHaaS design artifact is explained by past research.

7.2.6 Research Contributions

Effective design science research must provide clear and verifiable contributions

in the areas of the design artifact, design foundations, and/or design methodologies. In

this respect, this thesis contributed the conceptualization and evaluation of eHaaS as a

design artifact. Search and design activities provided understanding of a complex

socio-technical system in an Australian healthcare context in the form of grounded

analysis and experimental research. Evaluation results took the form of a comparative

analysis to advance understanding of the benefits of process oriented service-based

eHealth architecture.


7.2.7 Communication of Research

Design science research must be presented effectively both to technology-

oriented as well as management-oriented audiences. To expedite this, peer reviewed

publications and this thesis is aimed at researchers in Health Informatics and

Information Systems. In a similar fashion, research findings are aimed at policy makers

and healthcare leaders to inform strategic planning activities in the area of eHealth.

7.3 FUTURE DIRECTIONS

Due to the scale and nascent nature of operational eHealth architecture, the

conceptualization of eHaaS as a design artifact was a significant task for a single PhD.

To convey sufficient knowledge about an operational example of eHaaS in order to

elicit meaningful feedback would require a significant investment in time and

resources without guarantee of consequential findings. This underlines a limitation in

accommodating all scenarios particularly those that include complex large-scale socio-

technical systems. In this regard, operationalising eHaaS must be a serious

consideration for future work. Meta-requirements and design principles, derived from

a literature review and an ethnographic study of one patient’s journey, would be

refined by additional studies in different care settings. Similarly, the interrelationship

between information technology, information quality and healthcare quality warrants

further examination in order to supplement the work commenced by this research

endeavour. Whilst the thesis identified quality benefits for stakeholders and

demonstrated the practicability of eHaaS, future research must examine the social,

psychological, ethical and cultural dimensions which have not been addressed in the

scope of this project.

From an artifact validation perspective, computer simulations developed for this

thesis established a promising framework for evaluating large scale eHealth systems.

However, adopting a manual approach for the modelling and documentation of

information production processes is a time intensive and labour-intensive endeavour,

prone to error when tracing semantic mismatches and calculation rules. Future efforts

in the evaluation of service-based information systems will be simplified by

integrating evaluation methods into the design process. BPMN and IP-Mapping

techniques used in this thesis may be extended further in future iterations to include


process meta-data and model parameters as part of an automated simulator permitting

designers to perform what-if analysis during the design process (Rizzi, 2016).

An assumption made by the simulation models is the independent influence of

quality characteristics on data items. However, some data elements are more

vulnerable to inherent deficiencies. For example fields in text formats are significantly

more error-prone than those with direct measurements or involving numerical figures

(Hong, et al., 2013). Due to time constraints, the evaluation undertaken in this thesis

focused on a subset of quality characteristics which describe a specific scope,

(accuracy, timeliness). Future iterations of the models should consider additional

measures e.g. completeness and consistency in order to more closely reflect real-world

systems and perhaps highlight broad systematic biases.

Another consideration is the concept that information with errors typically result

in lost time through rework. This can have a negative effect on the timeliness of

information which was not examined in the simulation models. To pursue this further,

there are strong interrelationships between information quality dimensions that

suggests caution when selecting them. The causal effect of focusing on one dimension

over another for a particular application may result in negative consequences for other

data quality dimensions (Islam, 2013). The interdependencies between accuracy and

timeliness have attracted special attention and have been modelled as trade-offs

(Ballou & Pazer, 1995). However, in the context of the evaluation this

interrelationship, whilst briefly acknowledged, has not been considered. Future models

should be extended to model the trade-offs between accuracy and timeliness.

The evaluation of the design artifact adopted a subjective approach for assessing

parameters while drawing from the literature to synthesise a set of input parameters

for the models. A greater level of granularity will help to yield more meaningful

insights into the effect of composite data items. This requires additional data and

processes to inform the development of more sophisticated simulation models. Future

iterations of the model might also consider other techniques. For example, one possible

approach is a cost based assessment using data acquisition and maintenance costs.

7.4 WHAT DID WE LEARN?

As with the majority of developed countries, Australian healthcare must confront

growing challenges resulting from an aging population, increasing healthcare costs,


persistent health inequalities, and increasing incidence of chronic disease.

Concomitant to these challenges is a complexity and diversity in healthcare that is

manifest in care processes, organizations, supporting technologies and information.

Recent attempts to address these issues by policy makers in Australia have resulted in

a consumer-driven approach to eHealth adoption via government sponsored product

development. The implementation of Australia’s MyHR system has resulted in

resistance by healthcare professionals and unrealised consumer expectations which

brings into question the effectiveness of the current system. With this knowledge, it is

imperative to recognize that the value of patient information lies not merely in the

collection of data but in the integration of patient-centred information into clinical

processes. Due to the complexity of care processes, this requires a shift away from

systems design that is predisposed to over-engineering the artifact with a limited set of

data structures, interfaces and reporting systems which impose constraints on clinical

work practices. Designing process oriented eHealth architectures that facilitate access

to information from discrete care events linked over time must be a prerequisite.

Characterized by service-based computing concepts and controlled access to

patient information, eHaas offers a novel architectural paradigm for the consumption

of technology in the healthcare domain, suitable for the digital consumer of the 21st

Century. The consumer in this context describes those stakeholders requiring

information to deliver improved patient outcomes. However, technological

sophistication and innovation will continue to evolve along with stakeholder values,

expectations and use of technology. Therefore, the focus should be on constructing a

framework that will manage this change effectively and efficiently while encouraging

innovation within a safer patient care model. In this respect, eHaaS has the potential

to place tailored eHealth services within the reach of healthcare professionals

irrespective of economic, geographical and technology related constraints.

With a focus on the consolidation of cloud-based services, which provide

seamless and efficient access to high quality health information from multiple

platforms at any time from any location, these services are aligned to operational

requirements in order to deliver value specific to the individual needs of the

stakeholders. Thus, at the administrative level encompassing clinical workflows and

care process models, eHaaS offers an approach for identifying service models that will

facilitate collaboration and knowledge sharing across the continuum of care. Thus, the


opportunity to address diverse requirements inherent in complex multidisciplinary

scenarios illustrate the potential for eHaaS to improve the delivery of care via access

to high quality information.

Australia is on the cusp of realizing the promise of its eHealth initiative however,

design choices influenced by repository thinking perhaps limits the potential of the

initiative to that of an electronic filing cabinet. Emerging technology trends are driving

the scaling of systems integration beyond organizational and geographical boundaries

placing renewed emphasis on the sharing of information. In this respect, design choices

must consider information system (IS) architectures that effectively support clinical

processes as well as improve the quality and presentation of information. Findings

from this thesis suggests that service-based architectures that are process oriented are

more likely to lead to improved information quality. More importantly, the thesis

concludes that information quality is a process improvement activity which can be

enhanced by using technology not the other way around. Therefore, designing systems

that enhance information quality management efforts is a necessity instead of an

option. This requires the minimization of human mediated transformation activities

through the use of automation and process redesign. With a shift to process oriented

service-based information systems, this thesis has demonstrated the potential of

eHealth-as-a-Service as an effective solution to achieve this.

Bibliography 191

Bibliography

Abu-Taieh, E. M. (2008). Computer Simulation Using Excel without Programming:

Universal-Publishers.

Accenture. (2012). Connected Health: The Drive to Integrated Healthcare Delivery.

Retrieved from http://nstore.accenture.com/acn_com/PDF/Accenture-

Connected-Health-Global-Report-Final-Web.pdf

ACHI. (2011, July). Response to request for comment on the draft PCEHR Concept of

Operations. Retrieved February 8 2015 from

http://www.achi.org.au/docs/ACHI_Response-PCEHR_ConOps_V1.2.pdf

Ackroyd, S. (2004). Methodology for Management and Organisation Studies: Some

Implications of Critical Realism. In S. Fleetwood & S. Ackroyd (Eds.), Critical

realist applications in organisation and management studies (pp. 137-163):

Psychology Press.

Adenuga, O. A., Kekwaletswe, R. M., & Coleman, A. (2015). eHealth integration and

interoperability issues: towards a solution through enterprise architecture.

Health Information Science and Systems, 3(1), 1.

Adler-Milstein, J., & Bates, D. W. (2010). Paperless healthcare: Progress and

challenges of an IT-enabled healthcare system. Business Horizons, 53(2), 119-

130. doi:10.1016/j.bushor.2009.10.004

AIHW. (2012a). Australia’s health 2012. Retrieved from

http://www.vision2020australia.org.au/uploads/resource/57/Australia-s-

health-2012.pdf

AIHW. (2012b). Australia’s health 2012. Retrieved December 4 2015 from

http://www.aihw.gov.au/WorkArea/DownloadAsset.aspx?id=10737422169

AIHW. (2014). Australia’s health 2014. Retrieved December 4 2015 from

http://www.aihw.gov.au/WorkArea/DownloadAsset.aspx?id=60129548150

Ajzen, I. (1991). The theory of planned behavior. Organizational behavior and human

decision processes, 50(2), 179-211.

Al-Shorbaji, N., & Geissbuhler, A. (2012). Establishing an evidence base for e-health:

the proof is in the pudding. Bulletin of the World Health Organization, 322-

322. doi:10.2471/BLT.12.106146

192 Bibliography

AMA. (2013). UGPA calls on Government to address clinical utility of the PCEHR as

an urgent priority. Retrieved from Australian Medical Association website:

https://ama.com.au/media/ugpa-calls-government-address-clinical-utility-

pcehr-urgent-priority

Arndt, S., Tyrrell, G., Woolson, R. F., Flaum, M., & Andreasen, N. C. (1994). Effects

of errors in a multicenter medical study: Preventing misinterpreted data.

Journal of Psychiatric Research, 28(5), 447-459. doi:10.1016/0022-

3956(94)90003-5

Avrem, A. (2015). The Benefits of Microservices InfoQ. Retrieved from

http://www.infoq.com/news/2015/03/benefits-microservices

Ball, L. J., & Ormerod, T. C. (2000). Putting ethnography to work: the case for a

cognitive ethnography of design. International Journal of Human-Computer

Studies, 53(1), 147-168. doi:10.1006/ijhc.2000.0372

Ballou, D., Wang, R., Pazer, H., & Giri, K. T. (1998). Modeling Information

Manufacturing Systems to Determine Information Product Quality.

Management Science, 44(4), 462-484.

Ballou, D. P., & Pazer, H. L. (1985). Modeling Data And Process Quality In Multi-

Input, Multi-Output Information Systems. Management Science (pre-1986),

31(2), 150.

Ballou, D. P., & Pazer, H. L. (1995). Designing Information Systems to Optimize the

Accuracy-timeliness Tradeoff. [Article]. Information Systems Research, 6(1),

51.

Ballou, D. P., & Pazer, H. L. (2003). Modeling completeness versus consistency

tradeoffs in information decision contexts. IEEE Transactions on Knowledge

and Data Engineering, 15(1), 240-243. doi:10.1109/TKDE.2003.1161595

Balogh, E. P., Miller, B. T., & Ball, J. R. (2016). Improving diagnosis in health care:

National Academies Press.

Banfield, M., Gardner, K., McRae, I., Gillespie, J., Wells, R., & Yen, L. (2013).

Unlocking information for coordination of care in Australia: a qualitative study

of information continuity in four primary health care models. BMC Fam Pract,

14, 34. doi:10.1186/1471-2296-14-34

Barrows, R. C., & Ezzard, J. (2011). Technical Architecture of ONC-Approved Plans

For Statewide Health Information Exchange. AMIA Annual Symposium

Proceedings, 2011, 88-97. Retrieved from PMC.

Bibliography 193

Bashkar, R. (1975). A realist theory of science: Routledge

Bashshur, R., Grigsby, J., Krupinski, E., & Shannon, G. (2011). The taxonomy of

telemedicine. [Report]. Telemedicine and e-Health, 17, 484-494. Retrieved

from Health Reference Center Academic.

Baskerville, R., Pries-Heje, J., & Venable, J. (2009). Soft design science methodology.

Paper presented at Proceedings of the 4th International Conference on Design

Science Research in Information Systems and Technology, Philadelphia,

Pennsylvania.

Bastani, K. (2016). Event Sourcing in Microservices Using Spring Cloud and Reactor.

Retrieved from http://www.kennybastani.com/2016/04/event-sourcing-

microservices-spring-cloud.html

Bates, D. W. (2015). Health information technology and care coordination: the next

big opportunity for informatics? Yearbook of medical informatics, 10(1), 11.

Batini, C., & Scannapieco, M. (2016). Data and Information Quality: Dimensions,

Principles and Techniques: Springer.

Begoyan, A. (2007). An overview of interoperability standards for electronic health

records. USA: society for design and process science.

Belden, J. L., Grayson, R., & Barnes, J. (2009). Defining and testing EMR usability:

Principles and proposed methods of EMR usability evaluation and rating.

Retrieved from

https://mospace.umsystem.edu/xmlui/bitstream/handle/10355/3719/Defining

TestingEMR.pdf?sequence=1&isAllowed=y

Bell, B., & Thornton, K. (2011). From promise to reality achieving the value of an

EHR. . [Article]. HFM (Healthcare Financial Management), 65(2), 50-56.

Betts, D., Domínguez, J., Melnik, G., Simonazzi, F., & Subramanian, M. (2012).

Exploring CQRS and Event Sourcing: Microsoft.

Bharosa, N., Janssen, M., Rao, H. R., & Lee, J. (2008). Adaptive information

orchestration: Architectural principles improving information quality. In

Proceedings of the 5th International ISCRAM Conference (pp. 556-565).

Bhartiya, S., & Mehrotra, D. (2013). Exploring Interoperability Approaches and

Challenges in Healthcare Data Exchange. In D. Zeng, C. Yang, V. Tseng, C.

Xing, H. Chen, F.-Y. Wang & X. Zheng (Eds.), Smart Health (Vol. 8040, pp.

52-65): Springer Berlin Heidelberg.

194 Bibliography

Black, A. D., Car, J., Pagliari, C., Anandan, C., Cresswell, K., Bokun, T., . . . Sheikh,

A. (2011). The impact of eHealth on the quality and safety of health care: a

systematic overview. PLoS Medicine, 8(1).

doi:10.1371/journal.pmed.1000387

Black, A. S., & Sahama, T. (2014). eHealth-as-a-Service (eHaaS): The

Industrialisation of Health Information Technology, a Practical Approach. In

16th International Conference on E-health Networking, Application &

Services - IEEE Healthcom'14. (Accepted).

Black, A. S., & Sahama, T. (2016). Chronicling the patient journey: co-creating value

with digital health ecosystems. In Proceedings of the Australasian Computer

Science Week Multiconference (pp. 60): ACM.

Blaya, J. A., Fraser, H. S., & Holt, B. (2010). E-health technologies show promise in

developing countries. Health affairs (Project Hope), 29(2), 244-251.

doi:10.1377/hlthaff.2009.0894

Blomberg, J., Giacomi, J. M., A, & Swenton-Wall, P. (1993). Ethnographic field

methods and their relation to design. In D. Schuler & A. Namioka (Eds.),

Participatory Design: Principles and Practices (pp. 123-155): Taylor &

Francis.

Bond, A., Hacking, A., Milosevic, Z., & Zander, A. (2013). Specifying and building

interoperable eHealth systems: ODP benefits and lessons learned. Computer

Standards & Interfaces, 35(3), 313-328. doi:10.1016/j.csi.2011.12.005

Bowden, T., & Coiera, E. (2013). Comparing New Zealand's ‘Middle Out’ health

information technology strategy with other OECD nations. International

Journal of Medical Informatics, 82(5), e87-e95.

doi:10.1016/j.ijmedinf.2012.12.002

Bowden, T. C. (2011). EHR strategy: top down, bottom up or middle out? In ITCH

(pp. 138-142).

Bucchiarone, A., Marconi, A., Pistore, M., & Raik, H. (2017). A context-aware

framework for dynamic composition of process fragments in the internet of

services (Vol. 8).

Buntin, M. B., Burke, M. F., Hoaglin, M. C., & Blumenthal, D. (2011). The Benefits

Of Health Information Technology: A Review Of The Recent Literature Shows

Predominantly Positive Results. Health Affairs, 30(3), 464-471.

Bushell-Embling, D. (2013). PCEHR under review, but is it “unfixable”? Technology

Decicions. Retrieved from Technology Decisions website:

Bibliography 195

http://technologydecisions.com.au/content/it-management/article/pcehr-

under-review-but-is-it-ldquo-unfixable-rdquo--210107464

Bygstad, B. (2010). Generative mechanisms for innovation in information

infrastructures. Information and Organization, 20(3–4), 156-168.

doi:10.1016/j.infoandorg.2010.07.001

Byrd, L. W., & Byrd, T. A. (2012, 4-7 Jan. 2012). Developing an Instrument for

Information Quality for Clinical Decision Making. In 2012 45th Hawaii

International Conference on System Sciences (pp. 2820-2829).

Cain, C., & Haque, S. (2008). Organizational Workflow and Its Impact on Work

Quality. In R. Hughes (Ed.), Patient Safety and Quality: An Evidence-Based

Handbook for Nurses. Rockville (MD): Agency for Healthcare Research and

Quality (US).

Car, J., Black, A., Anandan, C., Cresswell, K., Pagliari, C., McKinstry, B., . . . Sheikh,

A. (2008). The Impact of eHealth on the Quality & Safety of Healthcare: A

Systemic Overview & Synthesis of the Literature. Retrieved from

https://www1.imperial.ac.uk/resources/32956FFC-BD76-47B7-94D2-

FFAC56979B74/

Carlsson, S. A., Henningsson, S., Hrastinski, S., & Keller, C. (2011). Socio-technical

IS design science research: developing design theory for IS integration

management. Information Systems and eBusiness Management, 9(1), 109-131.

doi:10.1007/s10257-010-0140-6

Carter, B. (2000). Realism and Racism: Concepts of race in sociological research:

Psychology Press.

Carter, J. (2016). NIST and AHRQ Workflow Reports: A Few Observations Clinical

Workflow Center. Retrieved from

https://www.clinicalworkflowcenter.com/articles/workflow-in-practice/47-

nist-and-ahrq-workflow-reports-a-few-observations

Carvalho, E. C. A. d., Jayanti, M. K., Batilana, A. P., Kozan, A. M. O., Rodrigues, M.

J., Shah, J., . . . Pietrobon, R. (2010). Standardizing Clinical Trials Workflow

Representation in UML for International Site Comparison. PLoS ONE, 5(11),

e13893. doi:10.1371/journal.pone.0013893

Catwell, L., & Sheikh, A. (2009). Evaluating eHealth interventions: the need for

continuous systemic evaluation. PLoS medicine, 6(8), e1000126.

Chang, W. Y., Abu-Amara, H., & Sanford, J. F. (2010). Networked Service

Management. In Transforming Enterprise Cloud Services (pp. 189-230).

Dordrecht: Springer Netherlands.

196 Bibliography

Chatterjee, A. (2012). Healthy Architectures-Using CQRS and Event Sourcing for

Electronic Medical RecordsInfoQueue. Retrieved from

https://www.infoq.com/articles/healthcare-emr-ehr

Chaudhry, B., Jerome, W., Shinyi, W., Maglione, M., Mojica, W., Roth, E., . . .

Shekelle, P. G. (2006). Systematic Review: Impact of Health Information

Technology on Quality, Efficiency, and Costs of Medical Care. Annals of

Internal Medicine, 144(10), E12-W18.

Chiappelli, F. (2014). Comparative Effectiveness Analysis and Evidence-Based

Decisions. In Fundamentals of evidence-based health care and translational

science (pp. 33 - 64): Springer.

Coiera, E. (2009). Building a National Health IT System from the middle out. Journal

of the American Medical Informatics Association, 16(3), 271-273.

doi:10.1197/jamia.M3183

Cooper, J., Copenhaver, J., & Copenhaver, C. (2001). Workflow in the Primary Care

Physician’s Office: A Study of Five Practices. Information Technology for the

Practicing Physician, 23-34.

Cowan, P. (2016). Most Australian GP clinics aren't using e-health records. IT News.

Retrieved from ITNews website: http://www.itnews.com.au/news/most-

australian-gp-clinics-arent-using-e-health-records-417807

Curry, J., Fitzgerald, A., Prodan, A., Dadich, A., & Sloan, T. (2014). Combining

patient journey modelling and visual multi-agent computer simulation: a

framework to improving knowledge translation in a healthcare environment.

Stud Health Technol Inform, 204, 25-31.

Dahan, U. (2009). Clarified CQRSThe Software Simplist. Retrieved from

http://udidahan.com/2009/12/09/clarified-cqrs/

Dang, J., Hedayati, A., Hampel, K., & Toklu, C. (2008). An ontological knowledge

framework for adaptive medical workflow. Journal of Biomedical Informatics,

41(5), 829-836. doi:10.1016/j.jbi.2008.05.012

Dansky, K. H., Thompson, D., & Sanner, T. (2006). A framework for evaluating

eHealth research. Evaluation and Program Planning, 29(4), 397-404.

doi:10.1016/j.evalprogplan.2006.08.009

Davis, F. D. (1989). Perceived Usefulness, Perceived Ease of Use, and User

Acceptance of Information Technology. MIS Quarterly, 13(3), 319-340.

doi:10.2307/249008

Bibliography 197

Davis, N. A., & LaCour, M. (2014). Health information technology (Vol. 3rd). St.

Louis, Mo: Elsvier/Saunders.

De Simone, S. (2014). Sam Newman: Practical Implications of Microservices in 14

Tips. Retrieved from InfoQ website:

http://www.infoq.com/articles/microservices-practical-

tips?utm_source=infoq&utm_medium=related_content_link&utm_campaign

=relatedContent_news_clk

Dearne, K. (2014). An analysis of Commonwealth Government annual reports

covering e-health and PCEHR activities in 2013-14. Retrieved January 21

2015, from http://ceha.org.au/wp-content/uploads/2014/12/AnalysisPCEHR-

Final.pdf

DeLanda, M. (2006). A new philosophy of society: Assemblage theory and social

complexity. GB: Bloomsbury UK.

Deloitte. (2011). Expected benefits of the national PCEHR system. Australia:

Retrieved from

http://www.yourhealth.gov.au/internet/yourhealth/publishing.nsf/content/2EF

73F20EC08DC20CA257A090003C0FE/$File/PCEHR%20summary2103201

3.pdf.

Deloitte. (2014). Report to the Commonwealth Department of Health on the public

consultation into the implementation of the recommendations of the Review of

the Personally Controlled Electronic Health Record. Retrieved August 1, 2015

from

http://www.health.gov.au/internet/main/publishing.nsf/Content/17BF043A41

D470A9CA257E13000C9322/$File/Report%20-

%20Consultation%20on%20PCEHR%20Review%20Recommendations%20-

%20Sep2014.pdf

Deloitte. (2015, July 16 2015 ). Independent review of New Zealand’s Electronic

Health Records Strategy. Retrieved from

https://www.health.govt.nz/system/files/documents/publications/independent-

review-new-zealand-electronic-health-records-strategy-oct15.pdf

Dobrev, A., Stroetmann, K. A., Stroetmann, V. N., Artmann, J., Jones, T., &

Hammerschmidt, R. (2008). The conceptual framework of interoperable

electronic health record and ePrescribing systems. Retrieved from

http://www.ehr-

impact.eu/downloads/documents/EHRI_D1_2_Conceptual_framework_v1_0.

pdf

198 Bibliography

Dovey, S. M., Meyers, D. S., Phillips, R. L., Jr., Green, L. A., Fryer, G. E., Galliher,

J. M., . . . Grob, P. (2002, 2002/09//). A preliminary taxonomy of medical errors

in family practice. . Quality and Safety in Health Care, 11, 233+.

Eason, K., Dent, M., Waterson, P., Tutt, D., Hurd, P., & Thornett, A. (2012). Getting

the benefit from electronic patient information that crosses organisational

boundaries. Retrieved from

http://www.netscc.ac.uk/hsdr/files/project/SDO_FR_08-1803-226_V03.pdf

Eason, K., Dent, M., Waterson, P., Tutt, D., & Thornett, A. (2012). Bottom-up and

middle-out approaches to electronic patient information systems: a focus on

healthcare pathways. Informatics in Primary Care, 20(1), 51-56.

Eason, K., & Waterson, P. (2014). Fitness for purpose when there are many different

purposes: Who are electronic patient records for? Health Informatics Journal,

20(3), 189-198. Retrieved from

http://journals.sagepub.com/doi/abs/10.1177/1460458213501096.

doi:doi:10.1177/1460458213501096

Easton, G. (2010). Critical realism in case study research. Industrial Marketing

Management, 39(1), 118-128. doi:10.1016/j.indmarman.2008.06.004

Edwards, P. K., O’Mahoney, J., & Vincent, S. (2014). Critical Realism and

Ethnography. In Studying Organizations Using Critical Realism. Oxford:

Oxford University Press.

El-Kareh, R., Hasan, O., & Schiff, G. D. (2013). Use of health information technology

to reduce diagnostic errors. BMJ Qual Saf, 22 Suppl 2, ii40-ii51.

doi:10.1136/bmjqs-2013-001884

Elder, N. C., Meulen, M. V., & Cassedy, A. (2004). The identification of medical

errors by family physicians during outpatient visits. The Annals of Family

Medicine, 2(2), 125-129.

English, L. P. (2009). Information Quality Applied: Best Practices for Improving

Business Information, Processes and Systems. Hoboken: Wiley [Imprint].

Eppler, M. J. (2006). Managing Information Quality: Increasing the Value of

Information in Knowledge-intensive Products and Processes: Springer Berlin

Heidelberg.

Eppler, M. J., & Wittig, D. (2000, October 20-22). Conceptualizing Information

Quality: A Review of Information Quality Frameworks from the Last Ten

Years. In Proceedings of the 2000 Conference on Information Quality (pp. 83-

96).

Bibliography 199

Evans, E. (2003). Domain-driven design: tackling complexity in the heart of software:

Addison-Wesley Professional.

Evbuomwan, N., Sivaloganathan, S., & Jebb, A. (1996). A survey of design

philosophies, models, methods and systems. Proceedings of the Institution of

Mechanical Engineers, Part B: Journal of Engineering Manufacture, 210(4),

301-320.

Experian Information Systems. (2015). The data quality benchmark report. Retrieved

from

Eysenbach, G. (2001). What is e-health? Journal of Medical Internet Research, 3(2),

e20. doi:10.2196/jmir.3.2.e20

Finnell, J. T., Overhage, J. M., Dexter, P. R., Perkins, S. M., Lane, K. A., & McDonald,

C. J. (2003). Community clinical data exchange for emergency medicine

patients. In AMIA Annual Symposium Proceedings (Vol. 2003, pp. 235):

American Medical Informatics Association.

Foley, E. (2009, July). E-health e-volves. Australian Nursing Journal, 17, 21.

Fontaine, P., Ross, S. E., Zink, T., & Schilling, L. M. (2010). Systematic review of

health information exchange in primary care practices. The Journal of the

American Board of Family Medicine, 23(5), 655-670.

Gacenga, F., Cater-Steel, A., Toleman, M., & Tan, W.-G. (2012). A Proposal and

Evaluation of a Design Method in Design Science Research. Electronic

Journal of Business Research Methods, 10(2), 89-100. Retrieved from

ProQuest Central.

Georgiou, A., Vecellio, E., Toouli, G., Eigenstetter, A., Li, L., Wilson, R., &

Westbrook, J. (2012). The impact of the implementation of electronic ordering

on hospital pathology services On: Report to Commonwealth of Australia,

Department of Health and Ageing, Quality Use of Pathology Committee.

Sydney, Australian Institute of Health Innovation University of New South

Wales.

Germonprez, M., & Hovorka, D. (2008). The Information Services View. In M.

Barrett, E. Davidson, C. Middleton & J. I. DeGross (Eds.), Information

Technology in the Service Economy: Challenges and Possibilities for the 21st

Century: IFIP TC8 WG8.2 International Working Conference August 10–13,

2008, Toronto, Ontario, Canada (pp. 365-366). Boston, MA: Springer US.

200 Bibliography

Germonprez, M., Hovorka, D., & Collopy, F. (2007). A Theory of Tailorable

Technology Design. Journal of the Association for Information Systems, 8(6),

351.

Glance, D. (2013). Unfixable: time to ditch personally controlled e-health record

scheme The Conversation. Retrieved from

http://theconversation.com/unfixable-time-to-ditch-personally-controlled-e-

health-record-scheme-19834

Glance, D. (2015). New name and opt-out policy won’t save the personal health

record. Retrieved from http://theconversation.com/new-name-and-opt-out-

policy-wont-save-the-personal-health-record-41601

Goldberg, S., Niemierko, A., & Turchin, A. (2008). Analysis of data errors in clinical

research databases. In AMIA: Citeseer.

Görz, Q., & Kaiser, M. (2012). An Indicator Function for Insufficient Data Quality–A

Contribution to Data Accuracy. In Knowledge and Technologies in Innovative

Information Systems (pp. 169-184): Springer.

Gregor, S., & Jones, D. (2007). The Anatomy of a Design Theory. Journal of the

Association for Information Systems, 8(5), 312-323,325-335.

Guite, J., Lang, M., McCartan, P., & Miller, J. (2006). Nursing admissions process

redesigned to leverage EHR. Journal of Healthcare Information Management,

20(2), 55.

Hagland, M. (2001). Finding the e in healthcare. Healthcare Informatics, 18(11), 21-

24. Retrieved from

http://www.manyhatscreative.com/Portfolio/Scripts/Cerner/Finding%20the%

20e%20in%20Healthcare.doc.

Hambleton, S. (2014, December 2014). Making the right connections. The Health

Advocate.

Hanson, J. (2005). Event-driven services in SOAJava World. Retrieved from

https://www.javaworld.com/article/2072262/soa/event-driven-services-in-

soa.html

Harris, M. F., Jayasinghe, U. W., Taggart, J. R., Christl, B., Proudfoot, J. G., Crookes,

P. A., . . . Davies, G. P. (2011). Multidisciplinary Team Care Arrangements in

the management of patients with chronic disease in Australian general practice.

Med J Aust, 194(5), 236-239.

Bibliography 201

Harrison, B. T., Gibberd, R. W., Hamilton, J. D., & Wilson, R. (1999). An analysis of

the causes of adverse events from the Quality in Australian Health Care Study.

Med J Aust, 170(9), 411-415.

Hart, D., & Gregor, S. (2010). Information Systems Foundations: The Role of Design

Science. Canberra: ANU ePress.

Harvey, L. J., & Myers, M. D. (1995). Scholarship and practice: the contribution of

ethnographic research methods to bridging the gap. Information Technology &

People, 8(3), 13-27.

Health Quality Ontario. (2013). Continuity of Care to Optimize Chronic Disease

Management in the Community Setting: An Evidence-Based Analysis. Ontario

Health Technology Assessment Series, 13(6), 1-41. Retrieved from PMC.

Hevner, A., March, S. T., Park, J., & Ram, S. (2004). Design science research in

information systems. MIS Quarterly, 28(1), 75-105.

Hevner, A. R. (2007). A three cycle view of design science research. Scandinavian

Journal of Information Systems, 19(2), 87-92.

Hillston, J. (2003). Model Validation and Verification. Retrieved from

http://www.inf.ed.ac.uk/teaching/courses/ms/notes/note14.pdf

Hong, M. K., Yao, H. H., Pedersen, J. S., Peters, J. S., Costello, A. J., Murphy, D. G.,

. . . Corcoran, N. M. (2013). Error rates in a clinical data repository: lessons

from the transition to electronic data transfer—a descriptive study. BMJ open,

3(5), e002406.

Hovorka, D., & Germonprez, M. (2010). Identification-interaction-innovation: a

phenomenological basis for an information services view. In S. Gregor & D.

Hart (Eds.), Information Systems Foundations Part Three : The Role of Design

Science (pp. 3-20). Canberra: ANU Press.

Iivari, J. (2003). The IS core-VII: Towards information systems as a science of meta-

artifacts. Communications of the Association for Information Systems, 12(1),

37.

IOM. (2010). Digital Infrastructure for the Learning Health System: The Foundation

for Continuous Improvement in Health and Health Care: Workshop Series

Summary. Washington DC: National Academies Press.

IOM. (2012). Health IT and Patient Safety:Building Safer Systems for Better Care.

Washington, DC: National Academies Press.

202 Bibliography

Islam, M. S. (2013). Regulators Of Timeliness Data Quality Dimension For Changing

Data Quality In Information Manufacturing System (IMS). In The Third

International Conference on Digital Information Processing and

Communications (pp. 126-133): The Society of Digital Information and

Wireless Communication.

Johnston, R. B., & Smith, S. P. (2010). How critical realism clarifies validity issues in

theory-testing research: Analysis and case. In S. Gregor & D. Hart (Eds.),

Information Systems Foundations Part Three : The Role of Design Science.

Canberra: ANU Press.

Jolly, R. (2011). The e health revolution—easier said than done. Retrieved from

http://www.aph.gov.au/About_Parliament/Parliamentary_Departments/Parlia

mentary_Library/pubs/rp/rp1112/12rp03.

Kahn, B. K., Strong, D. M., & Wang, R. Y. (2002). Information quality benchmarks:

product and service performance. Communications of the ACM, 45(4), 184-

192.

Kainulainen, P. (2014). The Microservice Architecture Sounds Like Service-Oriented

ArchitecturePetri Kainulainen [Web Log]. Retrieved from

http://www.petrikainulainen.net/software-development/design/the-

microservice-architecture-sounds-like-service-oriented-

architecture/#comment-393430

Katehakis, D. G., Kostomanolakis, S., Tsiknakis, M., & Orphanoudakis, S. C. (2000).

Evaluating Alternative Approaches for Integrating Clinical Information

Systems: Messaging" vs. federating. In: proceedings of the TEHRE 2000

Conference, London, UK.

Katerattanakul, P., & Siau, K. (1999). Measuring information quality of web sites:

development of an instrument. In Proceedings of the 20th international

conference on Information Systems (pp. 279-285): Association for Information

Systems.

Khajouei, R., & Jaspers, M. W. (2010). The impact of CPOE medication systems'

design aspects on usability, workflow and medication orders. Methods of

information in medicine, 49(1), 3.

Khan, S. A., Kukafka, R., Payne, P. R., Bigger, J. T., & Johnson, S. B. (2007). A day

in the life of a clinical research coordinator: observations from community

practice settings. Stud Health Technol Inform, 129(Pt 1), 247-251.

Kohn, L. T., Corrigan, J. M., & Donaldson, M. S. (2000). To Err Is Human: Building

a Safer Health System. Washington: National Academies Press.

Bibliography 203

Krafzig, D., Banke, K., & Slama, D. (2005). Enterprise SOA: service-oriented

architecture best practices: Prentice Hall Professional.

Kruys, E. (2013). eHealth records: there are alternatives to the PCEHRDoctor's Bag

[Blog]. Retrieved from http://doctorsbag.net/2013/04/14/ehealth-records-

there-are-alternatives-to-the-pcehr/

Kruys, E. (2014). This is why I will not use the PCEHR Doctor's Bag. Retrieved from

http://doctorsbag.net/2014/12/04/this-is-why-i-will-not-use-the-pcehr/

LeCompte, M. D., & Goetz, J. P. (1982). Problems of Reliability and Validity in

Ethnographic Research. Review of Educational Research, 52(1), 31-60.

doi:10.2307/1170272

Lehnbom, E. C., Brien, J. E., & McLachlan, A. J. (2014). Knowledge and attitudes

regarding the personally controlled electronic health record: an Australian

national survey. Internal Medicine Journal, 44(4), 406-409.

doi:10.1111/imj.12384

LeMay, R. (2013). Doctor supergroup calls for PCEHR overhaul. Delimiter. Retrieved

from Delimiter website: http://delimiter.com.au/2013/10/25/doctor-

supergroup-calls-pcehr-overhaul/

LeMay, R. (2014). PCEHR review recommends NEHTA be ‘dissolved’. Delimiter -

Just Australia. Just Technology.

Lipscomb, M. (2011). Critical realism and realist pragmatism in mixed method

research: the problematics of event identity and abductive inference. Paper

presented at American Educational Research Association Annual Meeting,

2011, New Orleans, Louisiana, USA. Retrieved from

http://eprints.uwe.ac.uk/14188

MacKenzie, C. M., Laskey, K., McCabe, F., Brown, P. F., Metz, R., & Hamilton, B.

A. (2006). Reference model for service oriented architecture 1.0. OASIS

standard, 12, 18.

Mandl, K., & Kohane, I. (2012). Escaping the EHR Trap -- The Future of Health IT.

The New England Journal of Medicine, 366(24), 2240-2242. Retrieved from

ProQuest Central.

Manos, D. (2016). Does healthcare need a more modern way to define and measure

EHR interoperability? Healthcare IT News. Retrieved from

http://www.healthcareitnews.com/news/does-healthcare-need-more-modern-

way-define-and-measure-ehr-interoperability

204 Bibliography

Mantzana, V., Koumaditis, K., & Themistocleous, M. (2010, 3-5 Nov. 2010). Is SOA

a solution to Healthcare Information Systems interoperability? In Proceedings

of the 10th IEEE International Conference on Information Technology and

Applications in Biomedicine (pp. 1-4).

March, S. T., & Smith, G. F. (1995). Design and natural science research on

information technology. Decision support systems, 15(4), 251-266.

Martin, R. C. (2003). Agile Software Development: Principles, Patterns, and

Practices: Pearson Education.

Martinho, R., Rijo, R., & Nunes, A. (2015). Complexity Analysis of a Business

Process Automation: Case Study on a Healthcare Organization. Procedia

Computer Science, 64, 1226-1231.

McDonald , K. (2016). $38m precision driven health initiative officially kicks

offPulse+IT. Retrieved from https://www.pulseitmagazine.com.au/new-

zealand-ehealth/3392-38m-precision-driven-health-initiative-officially-kicks-

off

McDonald, K., & James, S. (2013). Clinical Utility of PCEHR an urgent priority:

UGPA. Pulse+IT. Retrieved from

http://www.pulseitmagazine.com.au/index.php?option=com_content&view=a

rticle&id=1623:clinical-utility-of-pcehr-an-urgent-priority-

ugpa&catid=16:australian-ehealth&Itemid=328

Meier, C. A., Fitzgerald, M. C., & Smith, J. M. (2013). eHealth: Extending, Enhancing,

and Evolving Health Care. Annual Review of Biomedical Engineering, 15(1),

359-382. doi:10.1146/annurev-bioeng-071812-152350

Mekhjian, H. S., Kumar, R. R., Kuehn, L., Bentley, T. D., Teater, P., Thomas, A., . . .

Ahmad, A. (2002). Immediate benefits realized following implementation of

physician order entry at an academic medical center. Journal of the American

Medical Informatics Association, 9(5), 529-539.

Millett, S., & Tune, N. (2015). Patterns, Principles, and Practices of Domain-Driven

Design. US: Wrox Press Ltd.

Morris, C. W. (1938). Foundations of the Theory of Signs (Vol. 3): University of

Chicago Press Cambridge University Press.

Morrison, Z., Robertson, A., Cresswell, K., Crowe, S., & Sheikh, A. (2011).

Understanding contrasting approaches to nationwide implementations of

electronic health record systems: England, the USA and Australia. Journal of

Healthcare Engineering, 2(1), 25-42.

Bibliography 205

Mudaly, T., Moodley, D., Pillay, A., & Seebregts, C. J. (2013). Architectural

frameworks for developing national health information systems in low and

middle income countries. In Enterprise Systems Conference (ES), 2013 (pp. 1-

9): IEEE.

Muhammad, I., Teoh, S. Y., & Wickramasinghe, N. (2012). Why Using Actor

Network Theory (ANT) Can Help to Understand the Personally Controlled

Electronic Health Record (PCEHR) in Australia. International Journal of

Actor-Network Theory and Technological Innovation (IJANTTI), 4(2), 44-60.

doi:10.4018/jantti.2012040105

Murphy, C. (2011). How To Get One Version Of The Truth. InformationWeek.

Retrieved from http://www.informationweek.com/it-leadership/how-to-get-

one-version-of-the-truth/d/d-id/1101181?

Myers, M. (1999). Investigating information systems with ethnographic research.

Communications of the AIS, 2(4es), 1.

Nair, K. M., Dolovich, L. R., Ciliska, D. K., & Lee, H. N. (2005). The perception of

continuity of care from the perspective of patients with diabetes. Fam Med,

37(2), 118-124.

Namekawa, M., Shiono, Y., Ueda, Y., & Satoh, A. (2011). General purpose simulation

system based on Excel language. In 19th International Congress on Modelling

and Simulation-Sustaining Our Future: Understanding and Living with

Uncertainty, MODSIM2011.

NEHIPC. (2008). National e-Health Strategy. Retrieved August 28 2013 from

http://www.health.gov.au/internet/main/publishing.nsf/Content/604CF066BE

48789DCA25751D000C15C7/$File/National%20eHealth%20Strategy%20fi

nal.pdf

NEHTA. (2009). Pathology Test Report: Structured Document Template Version 1.0.

National E-Health Transition Authority Ltd.

NEHTA. (2012). High-Level System Architecture PCEHR System Version 1.35 - 11

November 2011 Final. Online: NEHTA Retrieved from

http://www.nehta.gov.au/implementation-resources/ehealth-foundations/EP-

1001-2011.

Neiva, F. W., David, J. M. N., Braga, R., & Campos, F. (2016). Towards pragmatic

interoperability to support collaboration: A systematic review and mapping of

the literature. Information and Software Technology, 72, 137-150.

doi:10.1016/j.infsof.2015.12.013

206 Bibliography

Newman, S. (2014). GeeCON 2014: Sam Newman - The Practical Implications Of

Microservices. [Video File]. Retrieved from http://vimeo.com/99531595

Nöth, W. (1995). Handbook of Semiotics: Indiana University Press.

Nunamaker Jr, J. F., Chen, M., & Purdin, T. D. (1990). Systems development in

information systems research. Journal of management information systems,

7(3), 89-106.

O'Brien, L., Merson, P., & Bass, L. (2007). Quality attributes for service-oriented

architectures. In Proceedings of the international Workshop on Systems

Development in SOA Environments (pp. 3): IEEE Computer Society.

Oliver-Baxter, J., Brown, L., & Bywood, P. (2013, Aug). Integrated care: What

strategies and other arrangements support and influence integration at the

meso/organisational level? Retrieved Dec 30th, 2013, from

http://www.phcris.org.au/phplib/filedownload.php?file=/elib/lib/downloaded

_files/publications/pdfs/phcris_pub_8415.pdf

OMG. (2008). Business Process Modeling Notation (BPMN) Specification V1.1:

Object Management Group.

Overhage, J. M., Perkins, S., Tierney, W. M., & McDonald, C. J. (2001). Controlled

Trial of Direct Physician Order Entry: Effects on Physicians' Time Utilization

in Ambulatory Primary Care Internal Medicine Practices. Journal of the

American Medical Informatics Association, 8(4), 361-371. Retrieved from

http://dx.doi.org/10.1136/jamia.2001.0080361.

doi:10.1136/jamia.2001.0080361

Pagliari, C., Sloan, D., Gregor, P., Sullivan, F., Detmer, D., Kahan, J. P., . . .

MacGillivray, S. (2005). What is eHealth (4): a scoping exercise to map the

field. Journal of medical Internet research, 7(1), e9. doi:10.2196/jmir.7.1.e9

Parssian, A., Sarkar, S., & Jacob, V. S. (2004). Assessing data quality for information

products: impact of selection, projection, and Cartesian product. Management

Science, 50(7), 967-982.

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design

science research methodology for information systems research. Journal of

management information systems, 24(3), 45-77.

Peirce, C. S. (1931). Collected Writings. 8 Vols. Ed. Charles Hartshorne, Paul Weiss

& Arthur W Burks. On: Cambridge, MA: Harvard University Press.

Bibliography 207

Peralta Costabel, V. d. C. (2006). Data freshness and data accuracy: a state of the art.

Reportes Técnicos 06-13.

Perrott, D. (2004). Achieving rapid implementation without disrupting workflow:

Medication administration technology meets nurses’ need for “perfect”

technology. Journal of nursing administration, 34, 5-6.

Petkov, P., & Helfert, M. (2013). Developing a Data Quality Methodology in Service

Oriented Context Using Design Science Approach. In A. Kobyliński & A.

Sobczak (Eds.), Perspectives in Business Informatics Research: 12th

International Conference, BIR 2013, Warsaw, Poland, September 23-25, 2013.

Proceedings (pp. 254-266). Berlin, Heidelberg: Springer Berlin Heidelberg.

Petter, S., Khazanchi, D., & Murphy, J. D. (2010). A Design Science Based Evaluation

Framework for Patterns. Database for Advances in Information Systems, 41(3),

9-26,27.

Pettigrew, L. (2010). A Rising Tide of Expectations Health Voices(7). Retrieved from

https://www.chf.org.au/pdfs/chf/Health_Voices_November_2010.pdf.

Piette, J. D., Lun, K. C., Moura, J. L. A., Fraser, H. S. F., Mechael, P. N., Powell, J.,

& Khoja, S. R. (2012). Impacts of e-health on the outcomes of care in low- and

middle-income countries: where do we go from here? Bulletin of the World

Health Organization, 90(5), 365-372. doi:10.2471/BLT.11.099069

Pizziferri, L., Kittler, A. F., Volk, L. A., Honour, M. M., Gupta, S., Wang, S., . . .

Bates, D. W. (2005). Primary care physician time utilization before and after

implementation of an electronic health record: a time-motion study. Journal of

biomedical informatics, 38(3), 176-188.

Poissant, L., Pereira, J., Tamblyn, R., & Kawasumi, Y. (2005). The Impact of

Electronic Health Records on Time Efficiency of Physicians and Nurses: A

Systematic Review. Journal of the American Medical Informatics Association

: JAMIA, 12(5), 505-516. Retrieved from PMC. doi:10.1197/jamia.M1700

Poksinska, B. (2010). The current state of Lean implementation in health care:

literature review. Quality Management in Healthcare, 19(4), 319-329.

Price, R., & Shanks, G. (2005a). A semiotic information quality framework:

development and comparative analysis. Journal of Information Technology,

20(2), 88-102. doi:10.1057/palgrave.jit.2000038

Price, R., & Shanks, G. (2008). Data Quality and Decision Making. In Handbook on

Decision Support Systems 1: Basic Themes (pp. 65-82). Berlin, Heidelberg:

Springer Berlin Heidelberg.

208 Bibliography

Price, R. J., & Shanks, G. (2005b, 03-06 Jan. 2005). Empirical Refinement of a

Semiotic Information Quality Framework. In Proceedings of the 38th Annual

Hawaii International Conference on System Sciences (pp. 216a-216a).

Pries-Heje, J., Baskerville, R., & Venable, J. (2008). Strategies for Design Science

Research Evaluation. In Conference Proceedings, 16th European Conference

on Information Systems: National University of Ireland.

Protti, D. J. (2008). The Health Information Bank: Revisiting Bill Dodd's Idea of 10

Years Ago. Electronic Healthcare, 6(4). Retrieved from

http://www.longwoods.com/product/19628.

RACGP. (2013). Quality health records in Australian primary healthcare: The Royal

Australian College of General Practitioners. Retrieved from

http://www.racgp.org.au/download/Documents/PracticeSupport/2013qualityh

ealthrecords.pdf

Rasmussen, K. B. (2008). The SAGE Handbook of Online Research Methods. In:

SAGE Publications, Ltd.

Reddy, S. (2017). My Health Record: the resuscitation of e-health, or a data placebo?

News & Insights. Retrieved from

http://www.kwm.com/en/au/knowledge/insights/myhr-my-health-record-

digital-health-records-data-secure-online-20170328

Redman, T. C. (1996). Data quality for the information age. Boston: Artech House.

Richards, M. (2015). Microservices vs. Service-Oriented Architecture. United States

of America: O’Reilly Media.

Richardson, C. (2016). Developing Transactional Microservices Using Aggregates,

Event Sourcing and CQRS - Part 1. InfoQueue. Retrieved from

https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-

richardson

Richardson, C. (2017). Developing Transactional Microservices Using Aggregates,

Event Sourcing and CQRS - Part 2. InfoQueue. Retrieved from

https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-2-

richardson

Richardson, C. (n.d.). Pattern: Microservice ArchitectureMicroservice Architecture.

Retrieved from http://microservices.io/patterns/microservices.html

Bibliography 209

Rizzi, S. (2016). What-If Analysis. In L. Liu & M. T. Özsu (Eds.), Encyclopedia of

Database Systems (pp. 1-6). New York, NY: Springer New York.

Rodriguez-Loya, S., Aziz, A., & Chatwin, C. (2014). A service oriented approach for

guidelines-based clinical decision support using BPMN. Stud Health Technol

Inform, 205, 43-47.

Rogers, E. M. (1983). Diffusion Of Innovations Third Edition. New York: The Free

Press.

Rolón, E., García, F., Ruíz, F., Piattini, M., & Calahorra, L. (2010). Healthcare Process

Development with BPMN. In Handbook of Research on Developments in E-

Health and Telemedicine: Technological and Social Perspectives (pp. 1024-

1047). Hershey, PA, USA: IGI Global.

Royle, R., Hambleton, S., & Walduck, A. (2013, December). Review of the Personally

Controlled Electronic Health Record. Retrieved March, 2015 from

http://health.gov.au/internet/main/publishing.nsf/Content/46FEA5D1ED0660

F2CA257CE40017FF7B/$File/FINAL-Review-of-PCEHR-December-

2013.pdf

Rusu, M., Saplacan, G., Sebestyen, G., Todor, N., Krucz, L., & Lelutiu, C. (2011).

eHealth: towards a healthcare service-oriented boundary-less infrastructure.

Applied Medical Informatics, 27(3), 1-14.

Sadeghi, P., Benyoucef, M., & Kuziemsky, C. E. (2012). A mashup based framework

for multi level healthcare interoperability. [journal article]. Information

Systems Frontiers, 14(1), 57-72. doi:10.1007/s10796-011-9306-0

Sanchez, A. X., Hampson, K. D., & Vaux, S. (2016). Delivering Value with BIM: A

Whole-of-life Approach: Taylor & Francis.

Sayer, A. (1992). Method in social science: A realist approach (2nd ed.). London:

Routledge.

Sebastian-Coleman, L. (2012). Measuring Data Quality for Ongoing Improvement: A

Data Quality Assessment Framework: Elsevier Science.

Shankaranarayanan, G., & Cai, Y. (2006). Supporting data quality management in

decision-making. Decision Support Systems, 42(1), 302-317.

doi:10.1016/j.dss.2004.12.006

Shankaranarayanan, G., & Even, A. (2004). Managing metadata in data warehouses:

Pitfalls and possibilities. The Communications of the Association for

Information Systems, 14(1), 47.

210 Bibliography

Shankaranarayanan, G., Wang, R. Y., & Ziad, M. (2000). IP-MAP: Representing the

Manufacture of an Information Product. In Proceedings of the 2000

Conference on Information Quality (pp. 1-16).

Shankaranarayanan, G., Ziad, M., & Wang, R. Y. (2003). Managing data quality in

dynamic decision environments: An information product approach. Journal of

Database Management, 14(4), 14-32.

Shanks, G. G., & Darke, P. (1998). Understanding Data Quality and Data

Warehousing: A Semiotic Approach. In IQ (pp. 292-309).

Shekelle, P. G., Morton, S. C., & Keeler, E. B. (2006). Costs and benefits of health

information technology. Evidence report/technology assessment(132), 1-71.

Simon, S. R., Keohane, C. A., Amato, M., Coffey, M., Cadet, B., Zimlichman, E., &

Bates, D. W. (2013). Lessons learned from implementation of computerized

provider order entry in 5 community hospitals: a qualitative study. [journal

article]. BMC Medical Informatics and Decision Making, 13(1), 67.

doi:10.1186/1472-6947-13-67

Smith, M. L. (2006). Overcoming theory-practice inconsistencies: Critical realism and

information systems research. Information and Organization, 16(3), 191-211.

doi:10.1016/j.infoandorg.2005.10.003

Smith, P. C., Araya-Guerra, R., Bublitz, C., & et al. (2005). Missing clinical

information during primary care visits. JAMA, 293(5), 565-571.

doi:10.1001/jama.293.5.565

Stamper, R., Liu, K., Hafkamp, M., & Ades, Y. (2000). Understanding the roles of

signs and norms in organizations - a semiotic approach to information systems

design. Behaviour & Information Technology, 19(1), 15-27.

doi:10.1080/014492900118768

Strong, D. M., Lee, Y. W., & Wang, R. Y. (1997). Data quality in context.

Communications of the ACM, 40(5), 103-110.

Stvilia, B., Gasser, L., Twidale, M. B., & Smith, L. C. (2007). A framework for

information quality assessment. Journal of the American Society for

Information Science and Technology, 58(12), 1720-1733.

doi:10.1002/asi.20652

Stvilia, B., Mon, L., & Yi, Y. J. (2009). A model for online consumer health

information quality. Journal of the American Society for Information Science

and Technology, 60(9), 1781-1791. doi:10.1002/asi.21115

Bibliography 211

Takeda, H., Veerkamp, P., & Yoshikawa, H. (1990). Modeling design process. AI

magazine, 11(4), 37.

Taylor, C., Champeaux, D., & Bruce, D. (2011). The eHealth Readiness of Australia’s

Medical Specialists. Retrieved July 15 2015, from

http://www.health.gov.au/internet/publications/publishing.nsf/Content/CA25

78620005D57ACA25790900158A0A/$File/Medical%20Specialist%20ehealt

h%20readiness%20survey%20report.pdf

Therias, E. (2013). Ethnography – When and how to use Spotless. Retrieved from

http://www.spotless.co.uk/insights/ethnography-when-and-how

Vaishnavi, V., & Kuechler, W. (2004). Design Science Research in Information

Systems. Retrieved from http://desrist.org/desrist/content/design-science-

research-in-information-systems.pdf

Vaishnavi, V., & Kuechler, W. (2008). Design science research methods and patterns:

innovating information and communication technology (Vol. illustratition).

Boca Raton: Auerbach Publications.

van Gemert-Pijnen, J. E., Nijland, N., van Limburg, M., Ossebaard, H. C., Kelders, S.

M., Eysenbach, G., & Seydel, E. R. (2011). A holistic framework to improve

the uptake and impact of eHealth technologies. J Med Internet Res, 13(4), e111.

doi:10.2196/jmir.1672

Venkatesh, V., Morris, M. G., Gordon, B. D., & Davis, F. D. (2003). User Acceptance

of Information Technology: Toward a Unified View. MIS Quarterly, 27(3),

425-478. doi:10.2307/30036540

Vernon, V. (2013). Implementing domain-driven design: Addison-Wesley.

Vest, J. R. (2012). Health Information Exchange: National and International

Approaches. In N. Menachemi & S. Singh (Eds.), Health Information

Technology in the International Context (Advances in Health Care

Management, Volume 12) (pp. 3-24): Emerald Group Publishing Limited.

Vitacca, M., Mazzù, M., & Scalvini, S. (2009). Socio-technical and organizational

challenges to wider e-Health implementation. Chronic Respiratory Disease,

6(2), 91-97. doi:10.1177/1479972309102805

Waibel, S., Henao, D., Aller, M.-B., Vargas, I., & Vázquez, M.-L. (2011). What do we

know about patients' perceptions of continuity of care? A meta-synthesis of

qualitative studies. International Journal for Quality in Health Care, mzr068.

212 Bibliography

Walls, J. G., Widmeyer, G. R., & El Sawy, O. A. (1992). Building an Information

System Design Theory for Vigilant EIS. Information Systems Research, 3(1),

36-59.

Walls, J. G., Widmeyer, G. R., & El Sawy, O. A. (2004). Assessing information system

design theory in perspective: how useful was our 1992 initial rendition? JITTA:

Journal of Information Technology Theory and Application, 6(2), 43.

Wand, Y., & Wang, R. Y. (1996). Anchoring data quality dimensions in ontological

foundations. Communications of the ACM, 39(11), 86-95.

doi:10.1145/240455.240479

Wang, R. Y., & Strong, D. M. (1996). Beyond accuracy: What data quality means to

data consumers. Journal of management information systems, 5-33.

Waring, J., McDonald, R., & Harrison, S. (2006). Safety and complexity: inter-

departmental relationships as a threat to patient safety in the operating

department. Journal of health organization and management, 20(3), 227-242.

Whitehead, T. (2006). Workbook for descriptive observations of social settings, acts,

activities & events. Cultural Ecology of Health and Changes:

Ethnographically Informed Community and Cultural Assessment Research

Systems (EICCARS) Workbooks, 1-11.

WHO. (2003). Improving data quality: a guide for developing countries: Manila:

WHO Regional Office for the Western Pacific.

WHO. (2012). Management of patient information: trends and challenges in Member

States: based on the findings of the second global survey on eHealth. Retrieved

Sep 8th 2013 from

http://apps.who.int/iris/bitstream/10665/76794/1/9789241504645_eng.pdf

WHO, & ITU. (2012). National eHealth Strategy Toolkit. World Health Organization

and International Telecommunication Union 2012 Retrieved from

http://apps.who.int/iris/bitstream/10665/75211/1/9789241548465_eng.pdf.

Wilcox, A., Kuperman, G., Dorr, D. A., Hripcsak, G., Narus, S. P., Thornton, S. N., &

Evans, R. S. (2006). Architectural Strategies and Issues with Health

Information Exchange. AMIA Annual Symposium Proceedings, 2006, 814-818.

Wixom, B. H., & Watson, H. J. (2001). An empirical investigation of the factors

affecting data warehousing success. MIS quarterly, 17-41.

Wong, S. T., Watson, D. E., Young, E., & Regan, S. (2008). What do people think is

important about primary healthcare? Healthcare policy, 3(3), 89.

Bibliography 213

Wright, A., Sittig, D. F., Ash, J. S., Sharma, S., Pang, J. E., & Middleton, B. (2009).

Clinical decision support capabilities of commercially-available clinical

information systems. Journal of the American Medical Informatics

Association, 16(5), 637-644.

WS-BPEL Coalition. (2004). WS-BPEL Business Process Execution Language for

Web Services–Specification Version 1.1.

Xu, L. D. (2014). Enterprise Process Modeling and Workflow Management. In

Enterprise Integration and Information Architecture (pp. 219-254): Auerbach

Publications.

Zachariadis, M., Scott, S., & Barrett, M. (2010). Exploring critical realism as the

theoretical foundation of mixed-method research: evidence from the

economics of IS innovations. Judge Business School Working Papers.

Zheng, K., Haftel, H. M., Hirschl, R. B., O'Reilly, M., & Hanauer, D. A. (2010).

Quantifying the impact of health IT implementations on clinical workflow: a

new methodological perspective. Journal of the American Medical Informatics

Association, 17(4), 454-461. doi:10.1136/jamia.2010.004440

Zhou, J., Gilman, E., Palola, J., Riekki, J., Ylianttila, M., & Sun, J. (2011). Context-

aware pervasive service composition and its implementation. Personal and

Ubiquitous Computing, 15(3), 291-303.

Appendices 215

Appendices

Appendix A

BPMN Models

Figure A.1. eProvider sub-process.

Figure A.2. eCollaborate sub-process.

eCollaborate API

Query for events associated with

patient Metadata

Invoke access control method

Workflow metadata

Event Store

Return Error State

No Access

AccessAllowed

Invoke method to view content

and/or collaborate with

subscribers

Update metadata & event store

Event details

Changesmade

No change

ExternalStore

Archival system orauthorised data access in operational systems

216 Appendices

Appendix B

IMAM Matrix

Figure B.3. Example of IMAM matrix used for validating simulation models by verifying relationships between data items and system functions.

Appendices 217

Appendix C

IP-Map Models

Figure C.4. eHaaS IP-Map - GP consultation event.

Clin

ical

Co

nsu

ltat

ion

(e

Haa

S)

Nu

rse

Re

cep

tio

nC

linic

ian

eH

aaS

Pat

ien

t

Pat

ho

logy

Se

rvic

es

Collect Vital SignsDS3

RDVS2


QB2

Clinical Information System (CIS)

STO2

CDPA2

CDPA3

CDPA2

CDVS4

CDCN8Make record of

consultationDS6

RDCN5

RDPR4

CDPR6

CDPA2

RDMD3

CDPA2

CDMD5+

CDPA2

CDPR6CDMD9

PatientCB1

CDMD5 +CDMD7 +CDMD9

IPMD1

Requester (Practitioner)

CB3

IPMD5Review Pathology

Test ReportsDS11

CDMD18 + IPTR4 +IPCN1

Generate workflow view

eFlow APIP9

Create Diagnostic Test Order

P5ePOE API

Create New WorkflowP4

eFlow API

CDPR6

CDMD5 +CDMD7 +CDMD9 +CDMD16

IPTR4

Generate Results with progress notes

Workflow View P17

eCollaborate API

IPPR2Recommend

Diagnostic test DS5

Initiate Patient Workflow

DS4

Patient presents at clinic

DS2

Update Event StoreP6

ePOE API

CDMD7

Update EventP8

eFlow API

CDCN8 +CDPA3

CDCS17

PatientCB1

IPMD5

IPCN1

CDMD18

Alert subscribers to order completion

P16ePOE API

Check-in PatientP2

(eCheck-in API)

Update patient recordP3

Update clinical notesP7

Create diagnostic test request

Electronic to Paper FormSB1

ePOE API

W/Flow Metadata &Event Stores

STO3

CDMD15Update Event Store

& metadataP15

ePOE API

CDMD16Electronic

OrdersSTO4

Pathology Services Process

P14

CDCS14

Manage Patient admin & health

dataDS1

Personal Health RecordSTO1

RDPA1 CDPA1 CDPA2Validity &

CompletenessQB1

Enter patient information

P1ePatient API


STO5

Synchronise patient

demographic data with CIS

OB1ePatient API

218 Appendices

Figure C.5. eHaaS IP-Map - Pathology collection and reporting.

Appendices 219

Figure C.6. MyHR IP-Map - Clinical consultation event.

Clin

ical

Con

sult

atio

n (m

yHR

)

Rec

epti

onCl

inic

ian

Nur

se

myH

R

RDPA1 CDPA1 CDPA2Validity &

CompletenessQB1

CDPA3

CDCN4

Consultation with patient

DS2

Register patient

DS1

RDCN2

RDPR3

CDPR5

CDCN4 + CDPR5 + CDPA3

IPPR2Patient

CB1

IPCN1

Practice Management System (PMS)

STO1

Collect Vital SignsDS4

RDVS4

CDVS6

Pathology Test Reports

DS8CDTR12 CDTR14

RequesterCB3

IPCS4

Recommend Diagnostic Test

DS3

Update patient record

P2

Request Diagnostic TestP3

Enter clinical notesP4

Collect patient information

P1

Retrieve Pathology results and progress

notes P8

Paper form to Electronic Form

SB1

Create and attest Care Summary for upload to MyHR

Electronic template

SB3

Create Pathology Test Order

Electronic to Paper Form

SB2

MyHRSTO3

IPCN1

CDTR13

IPCN1

CDPA3 +CDCN4

Transfer from

Pathology Services to

GPOB2

Upload to

MyHROB1

220 Appendices

Figure C.7. MyHR IP-Map - Pathology collection and reporting.

Pat

ho

logy

Ser

vice

s (m

yHR

)

Pat

ho

logi

stR

ecep

tio

nLa

bo

rato

ry W

ork

er

myH

R

CDTR13

Collect test requisition order

DS5IPPR2


STO2

RDPR5


QB2CDPR7

CDPR8

Collect SpecimensDS6 RDSD6

CDSD9

CDPR8 + CDSD9

Match labels to verify

QB3

CDSD10CDTR11

CDPR8 + CDSD9 + CDTR11

CDTR12Analyse Specimens

DS7

IPSD3LABCB2

RDTR7Enter analysis

Details P6

Generate Pathology Test Report

P7

Update Patient record with

specimen detailsP5

Create Specimen Labels

Electronic Form to Paper Form

SB5

Collect patient details and

OrderPaper form to

Electronic FormSB4

MyHRSTO3

Transfer from GP

to Pathology

ServiceOB1

Upload to

MyHROB3

Appendices 221

Appendix D

Raw Data Elements

Table D.1

Raw data elements

ID Data Attribute CSHIS MyHR eHaaS

Patient Registration

RDPA1 Individual Health Identifier

X X

RDPA1 Surname

RDPA1 First Name

RDPA1 DOB

RDPA1 Gender

RDPA1 Street Address

RDPA1 Preferred Name

RDPA1 Postal Address

RDPA1 Mobile Number

RDPA1 Home Phone

RDPA1 Work Phone

RDPA1 Email

RDPA1 Occupation

RDPA1 Medicare Number

RDPA1 Medicare Ref No

RDPA1 Medicare Expiry Date

RDPA1 Pension/HCC Number

RDPA1 Next of Kin: (Name, Address & Telephone

number)*

RDPA1 Allergies

222 Appendices


RDPA1 Current Medications

RDPA1 Family History

RDPA1 Past Medical History

Health Status Notes

RDVS4 Patient Name

RDVS4 Patient Medical Record ID

RDVS4 Findings

RDVS4 Date

WorkFlow Metadata

X

RDMD3 WorkFlowID

X

RDMD3 ConsumerIHI

X

RDMD3 ProviderID

X

RDMD3 Description

X

RDMD3 DateTimeCreated

X

RDMD3 Status

X

GP Consultation Notes

RDCN2 Date

RDCN2 Patient Name

RDCN2 Patient Medical Record ID

RDCN2 Findings (subjective, objective, assessment,

plan)

RDCN2 Diagnostic, therapeutic, information (type, name,

status)

RDCN2 Medicines (description, doses, status, reason)

RDCN2 Immunisations*

Appendices 223


RDCN2 Newly identified allergies, adverse effects*

RDCN2 Health care Provider Details (Name, practice

details) *

RDCN2 Date/Time Attested

X

Consultation Task Metadata

CDMD9 TaskID

X

RDMD3 WorkFlowID (Auto-populated from RDMD3)

X

RDPA1 ConsumerIHI (Auto-populated from CDPA3)

X

RDMD3 ProviderID (Auto-populated from RDMD3)

X

CDMD9 Description (Auto-populated from RDCN2)

X

CDMD9 DateTimeCreated (System Generated)

X

CDMD9 Content_Reference (URL) (Auto-populated from

RDCN2)

X

CDMD9 Status

X

CDMD9 TaskType

X

Pathology Test Order

Information supplied by requester

RDPR3 Tests requested

CDCN4 Clinical status of patient (if required)

RDPR3 Requester Provider Name

RDPR3 Requester Contact details

RDPR4 QR CODE = referencing electronic order

X

RDPR4 Requester Provider ID

X

RDPR4 RequestID

X

RDPR4 Patient Instructions

X

224 Appendices


RDPR4 Order Status

X

RDPR4 RequiredByDate

X

Pathology Request Task Metadata

CDMD7 TaskID

X

RDMD3 WorkFlowID (Auto-populated from RDMD3)

X

RDPA1 ConsumerIHI (Auto-populated from RDPA1)

X

RDMD3 ProviderID (Auto-populated from RDMD3)

X

RDPR4 Description (Auto-populated from RDPR4)

X


X

CDMD7 Content Reference (URL) (Auto-populated from

RDPR4)

X

CDMD7 Status (System generated default)

X

CDMD7 TaskType

X

Pathology Test Results

Information supplied by LAB

RDSD4 Specimen reference details

RDSD4 Date and time of collection*

RDSD4 Anatomical site of tissue specimens

RDSD4 Type of Specimen (e.g. urine, joint aspirate)

RDSD4 Person collecting*

RDSD4 Specimen characteristics which may provide

information relevant to interpretation of results

RDTR5 Date and time of receipt in the Laboratory

RDTR5 Analysis (Validated results data)

RDTR5 Identity of the Laboratory issuing the report

Appendices 225


RDTR5 Date and time of report release

RDTR5 Content Reference (URL)

X

Pathology Results Task Metadata

CDMD16 TaskID

X

RDMD3 WorkFlowID

X

RDPA1 ConsumerIHI

X

RDTR5 ProviderID (Auto-populated from RDTR5)

X

CDMD16 Description (Auto-populated from RDTR5)

X


X

CDMD16 Content_Reference (URL) (Auto-populated from

RDTR5)

X

CDMD16 Status

X

CDMD16 TaskType

X

226 Appendices

Appendix E

Input Parameters

Table E.2

Estimated error ratios for information transformation functions

Description Process

Type

Est.

Error

%

Notes

Handwriting/Machine

(human transcription)

H2Mt 2.58 Value is dependent on the quality of the

handwriting (legibility) and the data entry

operator's level of understanding and skill level.

A single-entry procedure is assumed.

Machine/Machine (data

transfer - intrinsic data

mapping)

M2M 0.01 It is assumed that errors introduced during this

process is negligible. Errors must be observed as

systemic e.g. errors in data mapping,

transmission errors.

Machine/ePaper (printing,

fax, email)

M2Pp 0.01 Introduced semantic and syntactic errors are

negligible (see above).

Machine/Paper (human

transcription)

M2Ph 2.42 Value derived from the ability of the human to

copy data from a machine source. Influencing

factors are largely environmental or contextual

e.g. time constraints, stress level, distractions.

Print/Machine (Data entry) P2Mh 2.42 Largely determined by the skill of the data entry

operator.

Print/Machine (OCR) P2Mo 0.02 Influenced by the quality of the print source

(legibility) and OCR capability of the software.

Raw data - Human Source RDH 0.02 Largely influenced by the individual's

knowledge and memory of key information.

Appendices 227

Description Process

Type

Est.

Error

%

Notes

Raw data - Machine

generated

RDS 0.01 Influenced by the quality of the software

generating the data. It is assumed that the level

of introduced errors is negligible.

Human/Machine

(form filling)

H2Mf 2.42 Influenced by the competency level of the user.

Errors most commonly introduced would be

syntactic (spelling).

Human/Paper

(form filling)

H2Pf 2.42 Form filling is dependent on the type of form

however the level of influence is aligned with

H2Mf

System Data

(data generated by machine)

SD 0.01 Influenced by the quality of the software

generating the data. It is assumed that the level

of introduced errors is negligible.

Quality (Inspection) Block

Form based field validation

(some fields)

FBFV 25 Form based validation that include existence

(required field) or drop-down lists that is selected

by the user e.g. address fields

Human validation by visual

Comparison

HVVI 25 A visual inspection for completeness or checking

against source data e.g. ensuring entered value

matches the number of a Medicare card.

No Quality Effect NQE 0 A defined variable with no influence on quality

Timeliness

Shelf Life Slife 10 Ballou's computation of timeliness is highly

sensitive to shelf life, the higher the shelf life the

more improved result for the timeliness measure.

As a comparative study, it was agreed that a

standard shelf life for all attribute values across

all scenarios. A 10 time unit shelf life is a

228 Appendices

Description Process

Type

Est.

Error

%

Notes

reasonable metric for evaluating information

flows of the type typical for provider/patient

consultations and establishes a consistent

baseline for comparison.

Appendices 229

Appendix F

Example Process Narrative

Table F.3

CSHIS process narrative – Data Source Blocks

Input Source

Block Output Activity Seq TTC Delay Narrative

Null DS1 RDPA1 1 1 0.0000

DS1 represents the patient registering for an episode of care. Form filling is

a manual data collection process performed by the patient to record their

demographic information and medical history. This process represents the

start of a new workflow and as the point of reference for the analysis, the

input time is set to 0.

CDVS6 DS2 RDCN2 3 1 0.0167

DS2 are observations of the patient's condition used to populate clinical

notes. This is typically keyed directly into the clinical system by the GP. The

IP (IPCN1) is the clinical summary. We assume this is a short consultation

(15 mins) with post consultation data entry estimated at 5 mins. The age of

this data is 0 as it represents information created by the clinician.

230 Appendices

Input Source


CDVS6 DS3 RDPR3 3 2 0.0033

DS3 commences the pathology test workflow. The IP is the pathology request

order. DS3 cannot commence until CDVS8 completes.

CDPA3 DS4 RDVS4 2 1 0.0083

DS4 represents the vital signs collected by the nurse pre-consultation - this

precedes the consultation. Its volatility is high with a short shelf life due to

the type of data. DS4 cannot commence until CDPA3 completes. We have

based this on the Time & Motion worksheet and rounded down to 5 minutes.

Shelf life is set to 1 time period (10 hours) in line with the policy directive -

3.2.3 from Royal Prince Alfred Hospital. (2010, June). Patient Observation

(Vital Signs) Policy - Adult.

IPPR2 DS5 IPPR2 4 1 0.0000 DS5 is a data source representing the patient presenting to the pathology lab

with the test requisition order IPPR2.

NULL DS6 RDSD6 5 1 0.0000 DS6 represents the commencement of the pathology test workflow which

includes the collection of specimens, its transfer to the lab for analysis and

post-analysis activities. The input to this workflow is the IPPR2 information

product created during the GP consultation workflow.

IPSD3 DS7 RDTR7 6 1 0.0000

DS7 represents the start of the analysis and post-analysis pathology tasks.

The input for this process is IPSG3

Appendices 231

Input Source


CDTR12 DS8 CDTR12 7 1 0.0000 DS8 represents the receipt of pathology results by the requesting clinic in the

form of a fax retrieved from a fax gateway.

Table F.4

CSHIS process narrative – Process Blocks

Input Process


RDPA1 P1 CDPA1 1 2 0.0250 P1: Collect patient information - patient completes a form drawing largely

from memory and information to hand. The time to collect is based on my

experience registering at various healthcare clinics.

RDVS4 P2 CDVS6 2 2 0.0367 P2: Update patient record with vital signs collected by nurse. The time to

complete is the time taken to update the information after locating the

patient's file. Based on average input time reported in study by Carvalho

et al (2010).

232 Appendices

Input Process


RDPR3 P3 CDPR5 3 5 0.0017 P3: Request Diagnostic test - clinician recommends a set of pathology tests

to assist with the diagnostic process and adds a record of the tests required

with relevant notes to the patient record. Estimate 1 minute

RDCN2 P4 CDCN4 3 3 0.0033 P4: Enter clinical notes - entered by the GP as a record of the consultation.

Estimate 2 mins to update/create patient information.

RDSD6 P5 CDSD9 5 2 0.0083 P5: include all pre-analytical processes which include details about the

collection of the specimens. Enter collection date and time. Estimate TTC

= 5 mins. The TTC is informed by the median data entry time reported by

Georgiou et al (2012, p. 22)

RDTR7 P6 CDTR11 6 2 0.0167 3 P6: Enter analysis results - describes the process of entering results from

the laboratory tests on the specimens. Estimate TTC as 10 mins. We have

included a delay of 3 time-periods to account for the delivery of specimens

to the lab and the analysis process. Whilst Georgiou et al (2012) report a

median laboratory turn-around time of 82.4 minutes for the analysis of a

specimen, an additional delay was added to account for transportation of

the specimens from the site of collection to the laboratory, receipt,

matching and scheduling of analysis and reporting. It must be noted that

additional time resulting from orders with errors have not been factored

Appendices 233

Input Process


into this analysis. Georgiou et al (2012) report that the median TAT for an

order increased by 220% (181 minutes) when errors were encountered in

the requisition order (p. 22).

CDTR8,

CDPR9,

CDSD11

P7 CDTR12 6 3 0.0033 P7 represents the task of assembling the pathology test report and

despatching to the requester. We estimate 2 min TTC. For the purpose of

this analysis, transfer of data is in the form of a fax received electronically

by the requester - based on fax machine baud rates we consider 2 minutes

reasonable as an upper limit.

CDCN4,

CDTR13

P8 IPCS4 7 4 0.0010 P8 represents the retrieval of the pathology results aggregated with the

patient's current episode of care details for action by the GP. The output

from this is the final IP. Ballou et al use a value of 0.001 of a time-period

to represent the time required to complete an IBM query (p. 482). We

consider this appropriate for this analysis.

234 Appendices

Table F.5

CSHIS process narrative – Quality Blocks

Input Quality


CDPA2 QB1 CDPA3 1 4 0.0002 The check includes completeness to ensure all "required" fields are

populated and valid to ensure accuracy of key fields e.g. Medicare number

matches card presented by the patient. Ballou suggests a cost reflecting the

checking and pro-rata cost to cover any rework. They have used a value of

$0.10. Similarly, the time estimate is quite small with 0.0002 days identified

as an upper limit (p. 483 para 1).

CDPR7 QB2 CDPR8 4 4 0.0002 See explanation for QB1

CDSD10 QB3 IPSD3 5 5 0.0002 See explanation for QB1

RDTR8 QB4 CDTR13 7 3 0.0002 See explanation for QB1

Appendices 235

Table F.6

CSHIS process narrative – Storage Blocks

Input Storage


STO1 0.0002 In their real-world example, Ballou et al provide an estimate of $0.1 for storing

master file data which includes retrieval time and storage costs. They estimate

the time to retrieve an item as 0.0002 time units (this works out to 12 seconds

based on a 10 hour work day (p. 483 para 1)). We will use these estimates as

our baseline for the purpose of this analysis.

STO2 0.0002

236 Appendices

Table F.7

CSHIS process narrative – System Boundaries

Input System

Boundary Output Activity Seq TTC Delay Narrative

CDPA1 SB1 CDPA2 1 3 0.0167 SB1 represents a system boundary defined by data entry of a patient

registration form by clinical admin staff - they are required to interpret the

handwriting of the patient and key the information into the system.

CDPA3,

CDPR5

SB2 IPPR2 3 4 0.0033 SB2 represents a system boundary defined by the Creation of the

Pathology Test Order - this may constitute manual or electronic

completion of a form thereby requiring the copying of data from one

location to another. We have adopted a paper based ordering approach that

is manually completed by the GP. Time to complete this exercise is

estimated at 2 minutes

CDCN4 SB3 IPCN1 3 6 0.0008 SB3 is a system boundary defined by the printing of the clinical summary

at the request of the patient. This requires minimal involvement by the GP

- < minute

RDPR5 SB4 CDPR7 4 3 0.0150 SB4 - a system boundary representing the creation of a new record in the

LIS and the data entry required to capture the details of the paper based

order requisition. Estimate TTC = 9 mins based on mean time identified

by Georgiou, et al. (2012).

Appendices 237

Input System

Boundary Output Activity Seq TTC Delay Narrative

CDPR8,

CDSD9

SB5 CDSD10 5 4 0.0008 SB5- a system boundary defined by the printing of specimen and patient

details on labels. TTC estimated at < 1 min

238 Appendices

EHEALTH AS A-SERVICE A ERVICE BASED DESIGN APPROACH FOR LARGE SCALE EHEALTH ARCHITECTURE ·...

Documents

Transcript of EHEALTH AS A-SERVICE A ERVICE BASED DESIGN APPROACH FOR LARGE SCALE EHEALTH ARCHITECTURE ·...