a case study investigating integration and

A case study investigating integration andinteroperability of Health Information

Systems in sub-Saharan Africa

Norah Elisabeth Nguyen

Thesis submitted for the degree ofMaster of Network and System Administration

60 credits

Department of InformaticsFaculty of Mathematics and Natural Sciences

UNIVERSITY OF OSLO

August 2019

i

Abstract

The purpose of integration of health information systems is to facilitate informationsharing between and across information systems. However, the challenges relatedto health systems are often donors targeting specific disease, creating parallel healthprogrammes. Information systems are developed to support monitoring of theseprogrammes. Yet there are no agreed-upon standards for data exchange betweenthe systems, leading to a nature of silo architecture.

To enable the sharing of information between and across information systems, westudy the integration approaches of health information systems in Malawi. Previ-ous work has failed to address the technical details of integrating health informationsystems. We aim to fill this gap by conducting a qualitative case study on sites wheredevelopment of integration methods is advancing. Interviews, documents and ob-servations are conducted providing insights on integration processes. A qualitativecase study was conducted in Malawi. Data collection methods like interviews, ob-servations and documents were used to investigate the integration approaches ofhealth information systems.

The results indicate that the integration of health information systems can be achievedthrough an open health information exchange architecture. The interoperabilitylayer in the architecture manages and orchestrate the data exchange between sys-tems. Additionally, desktop integration is another approach present at the facilityand patient level. The context server plays a central role between applications. Fur-ther, the results show that an agreed-upon standard for messaging, structure andcontent, and clinical terminologies and codes is crucial for the integration of healthinformation systems. The contribution of this thesis is that the health informationexchange architecture facilitates the exchange of aggregate and patient data, basedon the mediators that were built in Malawi. The desktop integration facilitates thesharing of patient information. The results also shed light on the use of infrastruc-ture technologies to improve the development pipeline of components in the openhealth information exchange architecture. Furthermore, it significantly improvedthe management of the infrastructure.

Keywords: health information systems, integration, health information exchange,data exchange, standard, national health information system.

iii

Acknowledgements

First of all, I am deeply thankful for my supervisor Jens Johan Kaasbøll for excellentguidance, encouragement and helpful contributions throughout this thesis. Addi-tionally, I would like to thank Flora Nah Asah for valuable feedback and usefuldiscussions in the car on our way to visit research sites. A special thank you goesto Dag Langmyhr and the board of Network and System Administration (NSA) forallowing me to write about this subject.

Secondly, I want to thank Blessings Nyirenda, Rebecca Mtegha and Joseph Wu fora warm welcome to Malawi. I am grateful for them, and their team for wanting toparticipate in this study and allow me to go and be an observant. I can genuinelysay that without their openness, this study would not have been possible. Also, Iwould like to thank fellow students and researchers for contributing to interestingdiscussions and enlighten me on other perspectives.

Finally, I would like to thank my friends and family the support.

This thesis has been supported by the projects Scholarly Health Informatics Learning(UTF-2016-long-term/10032) and ExTending Health Informatics Capacity (NORPART-2016/10134).

Norah Elisabeth NguyenOslo, July 2019

v

Contents

Abstract i

Acknowledgements iii

Acronyms xiii

1 Introduction 11.1 Research Questions and Objectives . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Personal Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Research Context 52.1 Malawi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Related Literature 93.1 Health Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Information systems (IS) . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Health Information Systems (HIS) . . . . . . . . . . . . . . . . . 103.1.3 Clinical Information Systems (CIS) . . . . . . . . . . . . . . . . . 10

3.2 Challenges with Information Systems to Support Healthcare Servicesand Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.1 The Support from Donors . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Paper-based Records and Paper-based Systems . . . . . . . . . 133.2.3 The Lack of Standards . . . . . . . . . . . . . . . . . . . . . . . . 133.2.4 Lack of Integration and Interoperability . . . . . . . . . . . . . . 143.2.5 Inadequate Infrastructure and Network . . . . . . . . . . . . . . 143.2.6 Lack of Unique National Identifiers . . . . . . . . . . . . . . . . 15

3.3 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Vertical Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.2 Horizontal Integration . . . . . . . . . . . . . . . . . . . . . . . . 183.4.3 Health Information Exchange (HIE) . . . . . . . . . . . . . . . . 19

HIE architecture models . . . . . . . . . . . . . . . . . . . . . . . 203.4.4 The Open Health Information Exchange (OpenHIE) Architec-

ture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 Health Data Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5.1 International Organization for Standard (ISO) . . . . . . . . . . 233.5.2 World Health Organization (WHO) . . . . . . . . . . . . . . . . 243.5.3 Messaging Standards . . . . . . . . . . . . . . . . . . . . . . . . . 243.5.4 Structure and Content Standards . . . . . . . . . . . . . . . . . . 26

vi

3.5.5 Clinical Terminologies and Coding . . . . . . . . . . . . . . . . . 273.6 Proposed Solutions for Integration . . . . . . . . . . . . . . . . . . . . . 283.7 Cybersecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7.1 Information Security . . . . . . . . . . . . . . . . . . . . . . . . . 313.7.2 System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.3 Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.8 Open Systems Interconnections (OSI) model . . . . . . . . . . . . . . . 323.8.1 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 333.8.2 Session Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.8.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.8.4 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.8.5 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.8.6 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.9 IT Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Methodology 394.1 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Data Collection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.3 Direct Observations . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Purposeful Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.5 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6 Quality of Research Design . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.6.1 Construct validity . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6.2 Internal validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.3 External validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.4 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 Ethical Considerations 455.1 Participant Information Letter . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Written Consent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Findings 476.1 Integration Approaches to Health Information Systems . . . . . . . . . 47

6.1.1 Integration at National Level . . . . . . . . . . . . . . . . . . . . 476.1.2 Integration at the Facility and Patient Level . . . . . . . . . . . . 50

6.2 Technical Challenges with Integration . . . . . . . . . . . . . . . . . . . 536.2.1 Language Barrier for Health Information Systems . . . . . . . . 536.2.2 Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 546.2.3 Poor Management of the Infrastructure and Network . . . . . . 556.2.4 Lack of a Strategy for Information Security . . . . . . . . . . . . 57

6.3 The Integration Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3.1 Better Information Flow in the Health System . . . . . . . . . . 586.3.2 Improved Infrastructure Management and Development Pipeline 58

6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

vii

7 Discussion 637.1 Integration Approaches to Health Information Systems . . . . . . . . . 63

7.1.1 Integration at National Level . . . . . . . . . . . . . . . . . . . . 637.1.2 Integration at Facility and Patient Level . . . . . . . . . . . . . . 65

7.2 Technical Challenges with Integration . . . . . . . . . . . . . . . . . . . 667.2.1 Language Barrier for Health Information Systems . . . . . . . . 667.2.2 Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . 687.2.3 Poor Management of Infrastructure and Network . . . . . . . . 687.2.4 Lack of a Strategy for Preserving Information Security . . . . . 69

7.3 The Integration Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.3.1 Information Flow in the Health System . . . . . . . . . . . . . . 707.3.2 Improved Infrastructure Management and Development Pipeline 71

7.4 Limitations of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4.3 Research Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4.4 Construct Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 737.4.5 External Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.4.6 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Conclusion and Future Work 758.1 Implications for Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Appendix 87Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

ix

List of Figures

2.1 The health system in Malawi . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Generic SOA with an ESB, as presented in Oracle (2019) . . . . . . . . . 193.2 HIE architectural models, as presented in McCarthy et al. (2014) . . . . 203.3 OpenHIE architecture framework, as presented OpenHIE-Community

(2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Overview of the CDA Levels, as presented in Boone (2011) . . . . . . . 273.5 The OpenHIE architecture framework in Rwanda, as presented by

Crichton et al. (2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Overview of the OpenHIM architecture components in Rwanda, as

presented by Crichton et al. (2013) . . . . . . . . . . . . . . . . . . . . . 303.7 Overview of the OSI model and rotocols . . . . . . . . . . . . . . . . . . 35

6.1 The OpenHIE Architecture in Malawi . . . . . . . . . . . . . . . . . . . 486.2 Overview of HIS at Mzuzu Central Hospital in Mzuzu, Malawi . . . . 506.3 Context Server enables bi-directional communication . . . . . . . . . . 516.4 Network topology at Kuunika . . . . . . . . . . . . . . . . . . . . . . . . 566.5 The roadmap for National Data Sharing Infrastructure OpenHIE in

Malawi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

xi

List of Tables

3.1 Overview of CIS, as presented in Islam et al. (2018) . . . . . . . . . . . . 113.2 The Interoperability Levels, as presented in van der Veer and Wiles

(2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Mapping Standards and Interoperability. Adopted from Adebesin

et al. (2013). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Data collection methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2 Overview of interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Interview participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 Overview of findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.1 Standards and Interoperability level mapping . . . . . . . . . . . . . . . 78

xiii

Acronyms

ADX Aggregate Data Exchange.

ANC Antenatal Care.

ART Antiretroviral Therapy.

CDA Clinical Document Architecture.

CI/CD Continuous Integration and Development.

CIS Clinical Information Systems.

CPOE Computerized Provider Order Entry.

CR Client Registry.

CVIS Cardiology Information System.

DDE Demographic Data Exchange.

DHAMIS Department of HIV/AIDS Management Information System.

DHIS2 District Health Information Systems.

DICOM Digital Imaging and Communications in Medicine.

EA Enterprise Architecture.

EHR Electronic Health Record.

EMR Electronic Medical Record.

ESB Enterprise Service Bus.

FHIR Fast Healthcare Interoperability Resources.

FR Facility Registry.

HIE Health Information Exchange.

HIS Health Information Systems.

HMIS Health Information Management Systems.

HWR Health Worker Registry.

ICD-10 International Classification of Diseases.

ICUS Intenive Care Unit System.

xiv

IS Information Systems.

LIS Laboratory Information System.

LOINC Logical Observation Identifiers Name and Tags.

MoH Ministry of Health.

OIS Oncology Information System.

OLIMS Open Laboratory Information System.

OPD Outpatient-Diagnosis.

OpenHIE Open Health Information Exchange.

OpenHIM Open Helath Information Mediator.

OSI Open Systems Innterconnections.

PACS Picture Archiving Communication System.

POC Point-of-Care Systems.

RIS Radiology Information System.

SHR Shared Health Record.

SNOMED-CT Systematized Nomenclature of Medicine - Clinical Terms.

SOA Service-Oriented Architecture.

TS Terminology Service.

UHC Universal Health Coverage.

1

Chapter 1

Introduction

Developing countries are facing an increasing burden of diseases and health trends.Health Information Systems (HIS) is a concept of capture, store, manage and trans-mit information for evidence-based decision-making regarding the management ofhealth services and delivery, and patient care. As diseases are indivdually easierto target, donors create parallel health programmes to monitore these individually.Furhtermore, vendors develop silo HIS to support their health programmes (Mwak-ilama et al., 2014). This leads to a silo architecture where systems cannot share infor-mation (Crichton et al., 2013).

Information systems in developing countries consist of both paper-based and elec-tronic information systems. Often, there is a lack of agreed-upon standards for mes-saging standards, content and structure and clinical terminologies and codes Mwak-ilama et al. (2014). This, in turn, makes communication between systems less inter-operable because they are not compliant to a specific standard.

Developing countries often have inadequate infrastructure and network around theirhealth systems. Inconsistent network connectivity is a tremendous problem becausesystems often rely on electronic data exchange. Consequently, information is notavailable for those who need it. Managers make decisions based on inadequate data(poor and duplicate data) or do not use data in their decision-making. Addition-ally, the workload of health workers increase when these systems cannot commu-nicate with each other and share information (Dlodlo and Hamunyela, 2017), andpotentially affect patient care. Based on this, the Ministry of Health (MoH) and re-searchers, stresses the need for integration of health information systems, to enablecommunication and information sharing.

Crichton et al. (2013) argue that integration is achieved through an Open HealthInformation Exchange (OpenHIE) architecture on a scalable level while Boochever(2003) argues that desktop integration is another approach to health informationsystems integration. Desktop integration make use of a context server for client ap-plications to communicate without back-end servers. Dlodlo and Hamunyela (2017)argue that integration can be achieved with Application Programming Language(API) enabling data exchange between systems. Based on this, three integrationapproaches are suggested: integration through the OpenHIE architecture, desktopintegration and integration with API’s. However, technical details and integrationchallenges have been less forthcoming in these proposed solutions.

2 Chapter 1. Introduction

The guidance on how to integrate Health Information Systems (HIS) and technicaldetails have been less forthcoming. Fragmented, weak and underperformed HISis a common phenomenon facing HIS in many developing countries. Therefore,we want to investigate integration approaches of HIS in the landscape of silos inMalawi. We assume that understanding the processes can be helpful to other coun-tries in a similar situation. Based on this background, the study intends to explorethe processes of integrating HIS in Malawi for the purpose of facilitating informa-tion sharing and achieve Universal Health Coverage (UHC).

The research method in this study is qualitative research, and the design is a casestudy design. This allows us to understand the complex phenomenon. The datacollection method is interviews, observations and documents. With these types ofsources and the following research questions, we aim to get insights into the inte-gration approaches of health information systems in Malawi.

1.1 Research Questions and Objectives

1.1.1 Research Questions

Based on the research scope, the research questions are described as follows:

RQ1: How is the integration of Health Information Systems conducted at the na-tional and local level?

RQ2: What technical challenges affect the Health Information Systems?

RQ3:What is the outcome of these integration types?

1.1.2 Research Objectives

The objective of this study is to investigate the integration types of Health Informa-tion Systems and identify the technical challenges of integration.

1.2 Personal Motivation

This thesis is written for the research group Information Systems (IS). Studying in-formation systems and understanding to what extent these systems have the abilityto support the health system and healthcare services had been an interest of mine.I am grateful for been accepted into the master program Network and System Ad-ministration. The compulsory courses in the program had extended my knowledgein networking, IT operations and infrastructure. I am grateful for the opportunity towrite a thesis that combines my two interest domains.

1.3. Thesis Structure 3

The study will be based on how developing countries are approaching the integra-tion of health information systems.

1.3 Thesis Structure

The remaining chapters are organized as follows:

Chapter 2: Research ContextPresents an of the context where the research took place.

Chapter 3: Related LiteratureIntroduce relevant literature to provide an understanding of 1) information systemsand HIS, 2) HIS challenges, 3) the process of integration and interoperability, and 4)security and infrastructure. The understanding from these concepts creates a base-line which can be used when analyzing and discussing the empirical findings.

Chapter 4: MethodologyDescribes and justified the selected methodology and methods used.

Chapter 5: Ethical ConsiderationsPresents the ethical considerations before conducting the study.

Chapter 6: FindingsPresent the empirical findings of the study.

Chapter 7: DiscussionDiscusses the related literature and the empirical findings to answer the researchquestions.

Chapter 8: Conclusion and Future WorkPresents the conclusion of the research questions and propose future work to beconducted.

5

Chapter 2

Research Context

This chapter provides the context of the research project. This chapter aims to pro-vide a better background for the research.

2.1 Malawi

Malawi is a landlocked country in southeast Africa. The country is bordered to Zam-bia to the northwest, Tanzania to the northeast and to Mozambique to the east. In2017 the Government of the Republic of Malawi presented a Health Sector StrategicPlan 2 for the period 2017-2022, aiming towards Universal Health Coverage (UHC).The strategy plan was omitted because the Government of Malawi has the goal toensure health and quality of life. They see it as an obligation to achieve the goal byaddressing social risk factors and ensuring universal health coverage. The strate-gic plan aims at reducing child mortality, combating HIV/AIDS and malaria, whichare some wide-spread diseases within the country. The succeeded Health SectorStrategic Plan 2011-2016, had success, with decreasing under-5 mortality and infantmortality, maternal mortality ratio and neonatal mortality rate. However, the ma-ternal mortality ratio and the neonatal mortality rate are still among the highest insub-Saharan Africa (Government of Malawi, 2017).

The health system in the country is organized in four levels, see Figure 2.1. Malaw-ians can access health services in public, private for-profit and private not for profitsectors. Health services at the public sector are free at the point of use, while theother sectors charge a user fee for their services.

6 Chapter 2. Research Context

FIGURE 2.1: The health system in Malawi

Malawi is a country that is very much depended on funding. Lack of essential med-ical products and technologies was due to inadequate funding, weak supply changemanagement and reckless use of medicine. According to the Government of Malawi,the goal of the strategic plan is to “move towards Universal Health Coverage (UHC)of quality, equitable and affordable quality health care with the aim of improvinghealth status, financial risk protection and client satisfaction”. The plan has eightobjectives, and we are particularly interested in the objective of Health InformationSystems (HIS). The objective is to generate quality information and make it accessi-ble for all users in their decision-making through standardized tools across all pro-grammes.

The current state of their Health Information Systems is faced with parallel report-ing systems, which creates structural challenges and weakened the ability to moni-tor and evaluate at the higher level of the health system. The data that are availableare of poor quality, and there is no data use culture in the country – people usetheir intuition and judgement for their decision-making. Going back to funding,Malawi, like many other low-income countries in Africa, is depended on funding.Donors develop stand-alone systems for specific functionalities to monitor a par-ticular disease-specific programmes. This leads to the nature of many silo healthinformation systems, which are not integrated. Therefore, with the strategic plan,the Government of Malawi aims to change the current environment of HIS, wherethey aim to build a national infrastructure that enables sharing of health data, acrosshealth programmes and health system levels.

2.2 Summary

This chapter presents the research context. It describes the recent assessment andstrategies for better health services and health provisioning in Malawi. Further, itpresents the levels of the health system and denotes the current state with health

2.2. Summary 7

information systems in the country.

The next chapter presents a review of the literature related to Health InformationSystems (HIS) and integration. It provides concepts like integration, interoperabil-ity, health data standards, cybersecurity, OSI model and infrastructure to understandthe integration of HIS in developing countries. The chapter also presents some pro-posed solutions to integration.

9

Chapter 3

Related Literature

This chapter presents a review of the literature and present concepts that provide afoundation for discussion about Health Information Systems (HIS) challenges andthe complexity of integration. The chapter also includes concepts of network andcybersecurity. This will give more understanding of the orchestra needed to achieveintegration of health information systems.

3.1 Health Information Systems

In this section, introduce the concept of Health Information Systems (HIS). As theterm is wide and covers many subsystems, we look at the term Information Systems(IS) to understand the concept and be able to define the HIS concept. Clinical Infor-mation Systems (CIS) is also under the umbrella of HIS, which we will also cover inthis section.

3.1.1 Information systems (IS)

Information Systems (IS) is a broad term. The concept of information system is de-scribed by Lippeveld et al. (2000), as "any collection of components that work to-gether to achieve a common objective". This means that components of informationsystems should support the collection, transmission, analysis and presentation ofmeaningful information.

Generally, newer research suggests information systems should have a socio-technicaldesign, recognizing the interaction between people and technology in the work-place. Mumford (2006) describes a socio-technical design as a process with a human-istic set of principles associated with technology and change. For instance, peoplestray from using information systems when the functionalities of the system do notsupport getting the tasks done, leading to articulation work. This arguably createsmore tension in the interaction between people and technology in the workplace.However, Kling (2002) argues that technological failures are not a factor for the ten-sion between people and technology in the workplace. Instead, it is the context anduse of the technology that is a factor for information systems to succeed in the work-place. Additionally, Kling (2002) argues that information systems should be viewedas complex socio-technical systems encompass human interactions, hardware andsoftware, support resources (training) and information structures (rules, norms and

10 Chapter 3. Related Literature

regulations).

In line with Kling (2002), Braa and Sahay (2012) argue that a socio-technical perspec-tive can be used as a foundation to understand information systems in the contextof health in developing countries (p. 12). As Health Information Systems (HIS) indeveloping countries are described as "a mesh of people, computers, paper, decision-making, management, procedures and institutions, with all the dynamics of a socialsystem". This definition argues that we have to balance the view between peopleand technology equally, as technology are a part of the workplace to support col-lection, transmission, analysis and presentation of information for people to use intheir decision-making.

3.1.2 Health Information Systems (HIS)

Several researchers define Health Information Systems (HIS) as a system that cap-ture, store, manage or transmit information to improve healthcare management de-cisions at all levels of the health system (Lippeveld et al., 2000; Sirintrapun and Artz,2015). The purpose of HIS is to provide health information to support evidence-based decision-making.

As several researchers have stated, HIS is a general term, covering a variety type ofinformation systems related to health (Lippeveld et al., 2000; Sirintrapun and Artz,2015). In developing countries, these systems could, for example, be, Health Infor-mation Management Systems (HMIS) focus on aggregated data. Logistics Manage-ment Information Systems (LMIS) supports health supply chain and are concernedwith the administrative and managerial aspect supports planning and distributionof health commodities Nielsen and Sæbø (2015). Electronic Medical Record (EMR)contains a patient’s medical history, diagnosis, and treatments. Electronic HealthRecord (EHR) are patient records designed to be shared among healthcare serviceproviders. Radiology Information System (RIS) emphasis on medical imaging forpatient treatments. Laboratory Information System (LIS) focuses on laboratory re-lated data. Furthermore, other information systems deal with finance, logistics, hu-man resource, administration, departmental operations, and needs or are program-specific, in the context of health. We will further present Clinical Information Sys-tems (CIS) as it is systems that concern patient data and information.

3.1.3 Clinical Information Systems (CIS)

Clinical Information Systems (CIS) or Point-of-Care Systems (POC) are informationsystems that deal with treatment and diagnosis of patients. In a similar view, Islamet al. (2018) describes CIS as information systems applied to patient care. Kushnirukand Patel (2004) describes CIS’s as "designed to collect, store and timely transfer clin-ical information to support clinicians in their decision-making" (p. 71). This meansthat CIS collect data from various sources and are used by clinicians, physicians andother healthcare workers to provide healthcare services to patients.

3.1. Health Information Systems 11

Types of Clinical Information Systems

Islam et al. (2018) identified the following three major areas within clinical informa-tion systems ( p. 83):

Ambulatory and Inpatient Information Systems This category consists of the Elec-tronic Medical Record (EMR) system, Computerized Provider Order Entry (CPOE),and inpatient and outpatient information system. The EMR contains a patient’smedical history, diagnosis and treatments. CPOE is a system that enables a physi-cian to enter and send medication orders and treatments instructions. This systemenables communication with other departments (e.g. laboratory, radiology, phar-macy, intensive care unit). Inpatient and outpatient information systems can operatearguably under this section as well.

Specialty Information Systems According to Islam et al. (2018), specialty systemscovers Intenive Care Unit System (ICUS), Oncology Information System (OIS) andCardiology Information System (CVIS). ICUS is used in the hospital to treat patientsthat suffer from severe or life-threatening conditions. OIS is used for the treatmentof cancer patients. Also, a CVIS is used for monitoring, management, evaluation forcardiac diseases.

Ancillary Information Systems These information systems provide necessary in-formation to support decisions about the condition of the patients and treatments.Radiology Information System (RIS)) is used in the radiology department and storesmedical imagery. Some essential functions of RIS are patient management, schedul-ing, patient tracking, result reporting, image tracking and billing. Laboratory Infor-mation System (LIS) is used in the lab and stores laboratory results Grann Fia et al.(2011). Picture Archiving Communication System (PACS) is used for management,storage, retrieval and distribution of medical images. The information system isused within radiology enabling request (CT scan, MRI and ultrasonography) frommedical devices and viewing medical images (Islam et al., 2018).

Areas Type of Clinical Information Systems

Ambulatory andInpatient Clinical

Information Systems

Ambulatory electronic medical record (Ambulatory EMR)Computerized order entry (CPOE)

Outpatient electronic medical record (OPD EMR)Inpatient electronic medical record (Inpatient EMR)

Speciality SystemsIntensive care unit information system (ICU)

Cardiology information systems (CVIS)Oncology information systems (OIS)

Ancillary InformationSystems

Cardiology information system (RIS/PACS)Laboratory information system (LIS)

Pharmacy information system

TABLE 3.1: Overview of CIS, as presented in Islam et al. (2018)

Table 3.1 provides an overview of the types of clinical information systems. In thecontext of developing countries, it is not uncommon that some of these systems are


paper-based. This means that health workers use paper registries to fill in informa-tion about the patients’ health encounters. Additionally, not all developing coun-tries have a unique national identifier, e.g. South Africa, Malawi and Uganda. Thisleads to different patient identities in different systems. Paper-based patient registra-tion often leads to misidentifications events due to inadequate patient identificationspractices Latham et al. (2012). Further, Latham et al. (2012) argue that wristband asa patient identification could be a solution, as the wristband is tangible and visible.

3.2 Challenges with Information Systems to Support Health-care Services and Delivery

Generally, developing countries face similar challenges related to Health Informa-tion Systems (HIS). The literature highlights the same challenges, and in this chap-ter, we present the challenges with Health Information Systems (HIS) to supporthealthcare services and delivery. We identified six challenges.

3.2.1 The Support from Donors

Over time, we have seen that donors (international aid agencies and non-governmentalorganizations) want to participate in the improvement of healthcare services in de-veloping countries. The support from donors has been observed to be supportinga budget or provide some solution for better healthcare services. Generally, donorswant to have autonomy over the funds, which usually include organizing stand-alone programmes, addressing a specific health condition or disease or comprehen-sive requirements for data collection. Which allows them to monitor health prob-lems and control their funding.

In a study by Chilundo and Aanestad (2004), they observed a pool of disease-specificprogrammes driven by donors, for example, TB, malaria and HIV/AIDS. This leadsto distinct information streams and fragmentation of disease spsecific programmes,where each health programmes collects different types of data. Further, donors de-velop their own HIS to support their disease-specific programmes, because the ma-jority of existing data cannot be trusted or there is little quality assessment of data,as shown in Braa et al. (2012). This leads to a health system with a silo architectureconsisting of many disparate HIS. A silo architecture leads to information fragmen-tation, where poor data quality also leads to no evidence-based decision-making.

Even Sæbø et al. (2013) agrees that fragmented information systems that are fundedand developed by diverse organizations are one of the challenges developing coun-tries face when it comes to their HIS. Braa and Sahay (2012) state that a vicious datacycle becomes evident when we develop disparate HIS because the existing datacannot be trusted.

3.2. Challenges with Information Systems to Support Healthcare Services andDelivery

13

3.2.2 Paper-based Records and Paper-based Systems

Another challenge with information systems to support healthcare services and de-livery is the existence of paper-based records and paper-based information systems.Paper is a common tool for health workers to use to collect data, both aggregated andpatient data. Data is collected from various sources, e.g. diverse health programmes,patient record cards, and reports. Evans et al. (2014) argue that paper-based infor-mation systems are commonly inaccurate or incomplete and difficult to access. Thisargument becomes valid, especially when there is no standard format. Lousy hand-writing and interpretation of data elements also lead to poor data quality.

Additionally, paper-based enable micro-mobility. However, mobility is a two-fold,it can be an advantage for those who currently have it, but at the same time inacces-sible for those who need it. In result, this affects the quality of data and accessibilityof information to support evidence-based decision-making.

The paper as an artifact creates challenges for data quality but also the use of in-formation systems. In a study by Lium et al. (2008), they studied two hospitals inNorway went through a process of changing from paper-based medical records toelectronic medical records (EMR). There was a scanning process for old paper-basedmedical records into the new EMR system. However, it was shown that the paperas an artifact supported the mobile work more than the EMR system, which healthworkers appreciated. Therefore, physicians would print out medical records fromthe EMR system and keep it by hand during patient interactions.

3.2.3 The Lack of Standards

A majority of health systems consists of many levels where there are many processes,actions and various actors. Lack of a standard on what data to collect, and standardsfor tools, data exchange between information systems, terminology, architecture andinfrastructure affects the quality of healthcare services and delivery. Additionally, itaffects the ability to plan and manage at higher levels of the health system.

Some researchers argue that HIS is difficult to sustain because of organizational com-plexity and uncoordinated structures (Kimaro and Nhampossa, 2005; Sæbø et al.,2013). This argument can be interpreted as valid as the arrival of donors increasesthe organizational complexity and introduces new structures. In turn, this affectsthe management and the purpose and expectations of information systems.

A case study by Sæbø et al. (2011) shows that an agreed-upon essential data set pro-vided better quality and availability of data was found in South Africa. The studyalso shows that there are other approaches where actors agreed to "combine the man-agement of data from all programs, which prove to have some increase in the useof information. However, agreeing on a shared set of data has shown to providehigh data quality and level of use. Regarding data dictionary or a list of vocabularyor medical terminologies, Hicken et al. (2004) also argue that clinical informationsystems face data quality and integration problems without a shared data dictio-nary. Their study investigated the difference between common data elements in


three separate information systems. Only 17% of the sample data elements had thesame meaning and structure across the three systems, and only 22% of the sampledata elements resulted in a complete match between the two systems. These empiri-cal results show the importance of standards, especially a shared data dictionary, sowe can eliminate various medical meanings in disparate information systems andpotential errors caused by humans to affect the data quality. On a more generalnote, Mwakilama et al. (2014) argue that standards on architecture, data dictionary,security, messaging, and network and infrastructures are required for integrationand interoperability of HIS.

As established standards prove to increase the data quality, it means that standardsplay an essential role for integration and interoperability of HIS – the ability for aHIS’s to be able to share and access meaningful health information. It shows that alack of standards creates challenges for information systems to support healthcareservices and delivery. Also, it does not enable interoperability because interoperabil-ity relies on systems speaking the same language.

3.2.4 Lack of Integration and Interoperability

The nature of silo architecture and disparate HIS have led to researchers suggest in-tegrating HIS. Developing countries are faced with fragmented HIS, with no abilityto share information between various systems. This affects the ability of evidence-based decision-making and making information systems inadequate to support bet-ter healthcare services and delivery.

Integration is not a straightforward process. Aligning various actors and establish-ing standards are crucial factors for integration. Chilundo and Aanestad (2004) ar-gue that integration is not just technical or organizational; it instead means bringtogether data, organizational behaviour, workforce and policies. Mwakilama et al.(2014) and Dlodlo and Hamunyela (2017) argue that integration is challenging be-cause information systems are built differently, runs on different databases, devel-oped in different programming languages and operating systems. In addition, theydo not communicate with each other, a result of a lack of standards – messaging stan-dards. Dlodlo and Hamunyela (2017) add that the lack of integration of informationsystems lead to the additional workload for health workers. Further, Stansfield et al.(2008) state that the absence of integrated information use leads to data duplication,which results as a burden for health workers.

Therefore, several studies address the need for HIS to be integrated, enabling easyaccess to information to support decision-making and better healthcare services andpatient care. However, it is interpreted as the process is slow for most developingcountries. This is because integration is not a straightforward process, includingmany stakeholders and requires a proper roadmap Mwakilama et al. (2014).

3.2.5 Inadequate Infrastructure and Network

Many low-income countries have limited infrastructure and network. In rural com-munities, the foundational infrastructure and network are even more limited com-pared to major cities and towns. Adebesin et al. (2013) state that internet connectivity

3.2. Challenges with Information Systems to Support Healthcare Services andDelivery

15

is deficient in developing countries. In a study by Ahmadian et al. (2017), networkfailure was identified as one of the common challenges with clinical information sys-tems. The inconsistent power supply leads to system failures and no ability to enterdata and access information from HIS, posing workload on health workers to collectdata manually and at a later stage enter into the systems.

Inadequate infrastructure and network also affect the integration of HIS as it needsnetwork connectivity to be able to exchange data between the systems.

3.2.6 Lack of Unique National Identifiers

Another challenge with information systems to support healthcare services and de-livery is the lack of unique national identifiers. The landscape of HIS in developingcountries are disparate HIS developed and implemented by various funders.

A patient can have multiple identities in various HIS Dlodlo and Hamunyela (2017).In most HIS, patients are unique in that particular system, e.g. the electronic med-ical record system, but is identified differently in another system. Lack of a uniquenational identifier makes it very difficult to track patient’s demographic and moreimportantly, it becomes difficult to track patients through systems, departments andfacilities. Adding to this, Fernandes et al. (2017), states that the different identitiesof the particular patient are not necessarily linked. This shed light on the need fora unique national identifier. A study by Latham et al. (2012) look at the perspectiveof potential risk, stated that misidentification of patients is common and a cause ofpatient harm. Another study by Carine and Parrent (1999), argues that uniquelyidentifying a patient at the point of registration is an important process in the devel-opment of a comprehensive patient record.

The literature reveals that the lack of a unique national identifier hinders the abilityto track the patient as they walk through the various departments of a facility orfacilities. Additionally, it indicates that a comprehensive patient record and patientcare becomes difficult without a unique national identifier in the interactions withthe health system. Consequently, it will become a factor that hinders informationsystems from supporting healthcare services and delivery.


3.3 Interoperability

The concept of interoperability is described as the ability to share and access infor-mation from other information systems by adhering to common standards Braa andSahay (2012)(p. 67). Interoperability should not be mistaken with integration, asinteroperability refers to the ability to share information and make use of it. Mainly,this means that the information must be meaningful for others. In the context ofhealth, we can achieve meaningfulness by adhering to common standards such asmessaging standards and clinical terminologies and codes. With common standards,information systems can share information even if they were designed as disparatehealth information systems. A prerequisite to understanding interoperability andintegration is standards. However, agreeing on standards is cumbersome as thehealthcare environment is complex and often affected by organizational cultures andbusiness processes.

Currently, there is no strict definition for the levels or types of interoperability. Crich-ton et al. (2013) defined two levels for interoperability. Further, Whitman and Panetto(2006) defined three levels of interoperability. In this thesis, we use the four lev-els of interoperability to understand integration, as highlighted in Adebesin et al.(2013). By achieving these four levels of interoperability, the shared information canbe meaningful and make use of by others, which is the objective.

The four levels of interoperability, as presented by van der Veer and Wiles (2008):

Levels Description

Technicalinteroperability

Refers to the hardware and software components,systems or platforms that ensures machine-to-machinecommunication. This type of interoperability has ahigh focus on communication protocols (e.g. HTTP)and the infrastructure orchestra that is neededfor those protocols to operate.

Syntacticinteroperability

Refers to when two or more information systems arecapable of communicating with each other,regardless of the programming language.

Semanticinteroperability

Refers to when two or more information systems exchangedata, and the data is understandable and meaningfulto each information system

Organizationalinteroperability

Refers to the ability of organizations to communicate andefficiently transfer meaningful information. Regardless of thevariety of information systems, they have to use over variousinfrastructures, organizations areas or cultures.

TABLE 3.2: The Interoperability Levels, as presented in van der Veerand Wiles (2008)

Table 3.2 shows the four levels of interoperability, which can relate to integration,where achieving each level facilitates that the shared information can be used forevidence-based decision-making and comprehensive patient care. In the next sec-tion, we will use the four levels of interoperability as a guide to understanding inte-gration.

3.4. Integration 17

3.4 Integration

Integration has different definitions depending on various perspectives. For in-stance, Sæbø et al. (2011) view integration as integrating health data from variousdisease-specific programmes (health programmes) into one database, called a sharedhealth data warehouse. The purpose of integration in Sæbø et al. (2011) argumentis that integration of health programmes should make data more available acrossthem. While, Braa and Sahay (2012) define integration as the "process of joining todisparate systems, in such a way, that they seem whole from a particular perspec-tive." (p. 60). Braa and Sahay (2012) argue that integration should have an enter-prise perspective and "relate it to the overall view of Enterprise Architecture (EA)"(p. 62). EA refers to the description of components and relationship in an organiza-tion. Stansfield et al. (2008) state that EA can be organized to align the organizations’goals and objectives with information systems. Further, Braa and Sahay (2012) arguethat "business users" (p. 62), or in our case health managers and service providers,should define the integration needs, thereof an enterprise perspective on integra-tion. Their argument can be rationalized as any actions made should be consideringthe whole enterprise instead of a specific domain. Following this approach, we canalign the organizations’ goals and objectives with information systems.

Dlodlo and Hamunyela (2017) acknowledge that there are two types of integration:horizontal and vertical integration. Horizontal integration refers to "the coordina-tion of functions, activities or operating units at the same level in the delivery ofservices" Dlodlo and Hamunyela (2017) (p. 61). Furthermore, vertical integrationrefers to "the coordination of functions and activities of units operating at differentstages of processes involved in delivering patient services" Dlodlo and Hamunyela(2017) (p. 61). On a similar note, Braa and Sahay (2012), argues for two integrationtypes. Horizontal integration refers to an integrated architecture across health pro-grammes and services, while vertical integration refers to provide a seamless flowof data between all levels of the health system.

Therefore, it becomes evident that integration has a different meaning for peopleand occur at different levels of the health system. In our study, we investigate theintegration of disparate Health Information Systems (HIS) to generate useful infor-mation and to achieve Universal Health Coverage (UHC).

Based on the arguments form Dlodlo and Hamunyela (2017) and Braa and Sahay(2012), we interpret that there are two architectural integration types, vertical andhorizontal integration for integration of information. Braa and Sahay (2012) presentthe three-level architecture to understand integration further. The three-level archi-tecture consists of the organizational/political level, software application and infor-mation systems level, and data exchange and interoperability standards level. Sincethis study aims to investigate the integration of HIS, we will only consider the soft-ware and applications level with vertical and horizontal integration.


3.4.1 Vertical Integration

The general definition of vertical integration can be explained as a “military-style”,for instance, from the top management level and down to operational levels. On themore technical note, vertical integration refers to the process of integrating subsys-tems according to its functionality, often labelled silos. For instance, the health sys-tems of low-income countries have a tight collaboration with aid-agencies and donororganizations. Their concern is to monitor prevalent diseases; therefore, they investin information systems that help monitor particular prevalent diseases. Leading to asilo architecture, where HIS are not compatible and cannot share data between them.Braa and Sahay (2012) suggest extracting data (aggregated data and indicators) fromElectronic Medical Record (EMR) systems and other disease-specific programmessystems and load them into one database - a shared data warehouse for aggregatedata. These EMR systems and other aggregate data are often paper-based. Thismeans that health workers have to manually enter the data into the District HealthInformation Systems (DHIS2) for aggregate data, working as a shared data ware-house. This architectural integration type enables information to flow upwards tothe district and national level of the health system.

3.4.2 Horizontal Integration

Braa and Sahay (2012) argue that horizontal integration is the integration across busi-ness areas within an organization or across the organization. Moreover, to the techni-cal note, horizontal integration refers to integrating and managing data from differ-ent health information systems in various departments and health programmes. Forexample, we want DHIS2 to be integrated with other information systems, so it canmanage data and provide information for those who need it. Horizontal integrationalso refers to integrating patient-based medical records from diverse informationsystems. A shared repository is typically used for integrating patient-based medicalrecords. Integration of patient data can support better patient care and management.

Health Information Systems are developed and implemented by different vendors.They are disparate because they are built differently, runs on different databases,developed in different programming languages and operating systems (Dlodlo andHamunyela, 2017; Mwakilama et al., 2014). This makes the integration of HIS chal-lenging. Drawing inspirations from Service-Oriented Architecture (SOA) can behelpful for horizontal integration of disparate HIS. SOA is a software design wherean Enterprise Service Bus (ESB), a middleware system, enables communication be-tween software applications in the architecture. In an ESB, all services and applica-tions are connected to the bus. Even though the underlying implementations of theservices and applications can be different, the ESB can abstract over the differences.Therefore, we argue that an ESB or other middleware systems can potentially man-age and enable communications between disparate HIS.

3.4. Integration 19

FIGURE 3.1: Generic SOA with an ESB, as presented in Oracle (2019)

In a user guide from Oracle (2019) on Middleware Concepts and Architecture for itsservice bus, they introduce an SOA architecture with a service bus component. Inthe guide, they argue that the ESB supports the alignment between service clientsand services. Figure 3.1 illustrates this alignment. On an overarching level, the ESBhas capabilities to join business process interactions. Therefore, much of the successof SOA is depended on the ESB.

In both types of integration, Braa and Sahay (2012) argue that we can deploy a tightor loose strategy of integration. For them, a tight integration entails tightly coupledsystems sharing the same resource. Tight coupling is a term that describes a sys-tem which its hardware and software are linked and dependent on each other. Sincecomponents are interlinked and dependent, a shared resource could lead to a singlepoint of failure, where the failure of one component would affect the other. Oppo-site, a loosely coupled integration approach allows a buffer and flexibility betweenthe systems, where a single point of failure is not likely. This is because loosely cou-pled systems are not dependent and have no knowledge of the definitions of theother components. The ESB is an approach for achieving loose coupling in integra-tion. These integration approaches should be taken into consideration when creat-ing a roadmap for the integration of health information systems. Health informationshould be preserved, therefore having a single point of failure is not advisable as itis vulnerable to exploits.

3.4.3 Health Information Exchange (HIE)

Esmaeilzadeh and Sambasivan (2017) define Health Information Exchange (HIE)aselectronic transfer patient data and other health information between healthcareproviders. In short, HIE provides the capability to transfer healthcare informationamong HIE electronically. Wolmarans et al. (2014) also suggest a Health InformationExchange (HIE) to enable the sharing of electronic health-related information amongcompliant HIE used in health facilities.


HIE architecture models

McCarthy et al. (2014) define three architecture models for Health Information Ex-change. One is a decentralized model, also known as federated, and the second oneis a centralized model one. There is also a hybrid architecture model that combineselements from both. Figure 3.2 illustrates the three models.

FIGURE 3.2: HIE architectural models, as presented in McCarthy et al.(2014)

Centralized Model In a centralized model, all data that participants agree to shareare standardized, meaning in a standard format and terminology. This data is storedin a centralized repository (or master) where they can be accessed and used by par-ticipants according to defined policies and procedures.

Decentralized Model In a decentralized model, each participant HIE participant isresponsible for maintaining a separate control of its data (servers) at their locationand shares patient-specific data only upon request from HIE participant. Every re-quest for patient data must be made to every participating data source McCarthyet al. (2014).

Hybrid Model The hybrid model is built upon the decentralized model. From thestudy by McCarthy et al. (2014), they found two forms of the hybrid model. Thefirst, HIE participants must maintain a separate repository and share it via the HIEinfrastructure upon request. The second form combined or design to achieve thefunctionality of a normalized central repository.McCarthy et al. (2014) claim that allmodels have the same necessary technical infrastructure to support data connectiv-ity and routing. In the absence of a uniform, they observed that all sites used amaster patient index to retrieve information about a single patient who had beentreated by multiple healthcare providers.

3.4. Integration 21

3.4.4 The Open Health Information Exchange (OpenHIE) ArchitectureFramework

Open Health Information Exchange (OpenHIE) architecture is an architecture de-veloped by Jembi Health Systems OpenHIM (2019) see Figure 3.3. It supports andenables interoperability by using health information standards, flexible implemen-tations and supports the exchange of components. As OpenHIE-Community (2019)stated "each component supports well-described, core health data management func-tions and interoperates with other components to ensure that health informationfrom various point of service applications is rationalized to support person-centricand population-based healthcare needs. Reference implementations of each of thecomponents exist to validate and highlight the functionality enabled within the ar-chitecture, and also are designed to support real-world needs".

The architecture consists of the OpenHIE component layer and the interoperabilitylayer or Open Helath Information Mediator (OpenHIM). External systems are thesystems that benefit from the architecture because it facilitates communication be-tween systems with the OpenHIM. Within the OpenHIE component layer, we findthe infrastructure services that are essential components to enable easier interoper-ability between HIS. The infrastructure services are:

Terminology Service serves as a centralized source for standards and definitions.This includes terminologies, ontologies, dictionaries, code systems and value sets.

Client Registry supports the unique identification and management of patient iden-tities.

Shared Health Record a repository that contains the extensive summary of a pa-tient’s health record.

Health Information Management Systems stores routinely-collected aggregate data.

Facility Registry serves as a central authority to uniquely identify locations wherehealth services are available.

Health Worker Registry serves as a central authority to maintain the unique iden-tity of health workers.

Interoperability Layer consists of a OpenHIM and other mediator-components toenable easier interoperability by connecting infrastructure services and external sys-tems (clients). The mediators support in authorizing and validating the data thatexternal systems want to exchange.


FIGURE 3.3: OpenHIE architecture framework, as presentedOpenHIE-Community (2019)

Figure 3.3 provides an overview of the OpenHIE architecture adopted from JembiHealth Systems. At the top, we find the all the infrastructure services, from left toright. The mediators’ Authorization, Inter-Linked Registry and Entity Matching lieswithin the interoperabikity layer. Together, the components in the Interoperabil-ity Service Layer receives transactions from external information systems (clients)and authorize and validates the transactions, which "simplifies the interoperabilitybetween health information systems" (OpenHIM, 2019). External systems in the ar-chitecture include mobile, clinic, HMIS, laboratory systems and hospital systems.

3.5 Health Data Standards

In this section, we present health data standards and discuss its relation to achieveintegration and interoperability of Health Information Systems (HIS). The standardsare grouped into relevancy, where we have international standards, messaging stan-dards, structure and content standards and clinical terminologies and coding.

Standard is a vital component for information to flow between patient level to thenational level of the health system. In the context of healthcare, the ability to collect,exchange, store and retrieve information from systems is highly crucial for patientcare and administrative processes. In this section, we will explore the concept ofhealth data standards more extensively as it is perceived as a prerequisite for theintegration and interoperability of health information systems.

Standard can be defined as "a document, established by consensus and approved bya recognized body, that provides, for common and repeated use, rules, guidelinesor characteristics for activities or their results, aimed at the achievement of the op-timum degree of order in a given context" Adebesin et al. (2013) (p. 56). In otherwords, a standard is an agreed-upon blueprint for some action that we can use re-peatedly. In the regard of healthcare, Aspden et al. (2004) argue that data standardsencompass methods, protocols, terminologies, and specifications for the collection,

3.5. Health Data Standards 23

exchange, storage and retrieval of information that are associated with healthcareapplications and systems. Additionally, they argue that common standards enablehealth information systems to share information. Therefore, it can be interpretedthat the absence of healthcare data standards leads to fragmentation of data also, theinability to share information between HIS.

The process of standardizing healthcare data entails focuses on the following, adoptedfrom Aspden et al. (2004):Data elements entails that data elements must be defined appropriately for data tobe collected and exchanged. This refers to the organizational interoperability level,mentioned in van der Veer and Wiles (2008):

Data exchange formats refers to the determination of standard data formats forelectronically encoding of data elements. This refers to the syntactical interoperabil-ity level as mentioned by (Adebesin et al., 2013; van der Veer and Wiles, 2008).

Terminologies entails that "the medical terms and concepts used to describe, clas-sify, and code the data elements and data expression languages and syntax thatdescribe the relationships among the terms/concepts" (Aspden et al., 2004). Thisrefers to the semantical interoperability level as mentioned by (Adebesin et al., 2013;van der Veer and Wiles, 2008).

Knowledge representation require standard methods for representation of medicalliterature, data and clinical guidelines, which can be interpreted to be present at thesemantic interoperability level as mentioned by (Adebesin et al., 2013; van der Veerand Wiles, 2008).

The points mentioned above are equally important, as representing data and infor-mation could not be achieved and understood if data cannot be exchanged, and thecontent of data elements have a different meaning or are structure differently.

In the next sections, we provide an overview of the common standards concerningintegration and information sharing between health information systems. Adebesinet al. (2013) state that these standards are commonly used to achieve interoperabil-ity. We will categorize the standards into appropriate groups: international stan-dards, messaging standards, structure and content standards and clinical terminolo-gies and coding.

3.5.1 International Organization for Standard (ISO)

ISO is an independent non-governmental organization with 160 national standardbodies that create standards to support innovation and provide solutions to theglobal challenges we are facing. In particular, the ISO/TC 215 is a technical com-mittee that works with standardization within health informatics, including capture,exchange and use of health-related data and information as to provide knowledgeto support all aspects of the health system. Crichton et al. (2013) mentioned in their


study that an ISO/IEC/IEEE 42010 standard where used for architecture descriptionto describe their architecture for the Open Helath Information Mediator (OpenHIM)

3.5.2 World Health Organization (WHO)

WHO creates a standard for health indicators, which are open and available. In 2018,they published a Global Reference List of 100 Core Health Indicators (World HealthOrganization, 2019). This is a standard set of indicators discussed on and prioritizedby the global community to be able to asses health situation and trends based onconcise information. The 2018 edition also included indicators for the target Univer-sal Health Coverage included in the Sustainable Development Goals (World HealthOrganization, 2019)

3.5.3 Messaging Standards

The messaging standards presented in this section are the most common standardsused for the exchange of data between disparate Health Information Systems (HIS).

Health Level Seven International or known as HL7 is a non-profit, American Na-tional Standards Institute (ANSI) that develops standards for the exchange of clin-ical and administrative information in healthcare (Adebesin et al., 2013; Hinchley,2007).

The HL7 standards provides a method for data exchange between health informa-tion systems Dixon et al. (2015). Under the umbrella of HL7, we find the followingstandards; V2, V3, Clinical Document Architecture (CDA) and Fast Healthcare In-teroperability Resources (FHIR) as primary standards HL7 (2018). There are somesimilarities and differences between the standards. For example, HL7 V3 and CDAbases on Extensible Markup Language (XML) for encoding syntax of messages whilethe HL7 V2 standard uses segments and one-character delimiters to form messagesand FHIR describes data elements as "Resource" HL7 (2019a). CDA is specifically re-stricted to the exchange of clinical information, whereas FHIR has no limitations tothe content of the data. Both versions require that the content is human-readable andhave rules for specifying how the text should be presented HL7 (2019a). There arealso similarities between HL7 V2 and FHIR as they both support event-based mes-saging, meaning that an event dictates the need for data to flow among applicationsor systems HL7 (2019a).

HL7 Version 2

HL7 version 2 is a messaging standard that is considered the core of electronic dataexchange within the clinical domain. According to HL7 themselves, the standardis highly implemented and allows clinical data to be exchanged between systems.A benefit with v2 is backward compatibility, which refers to content only beingadded to the end of existing fields and components, and applications will ignoreunexpected or repeated content HL7 (2019c). Hinchley (2007) argues that it has hadsuccess enabling communication between information systems in within hospitals.


However, the need for stronger interoperability, fewer options and inclusion of in-ternational requirements resulted in a vesion 3 of the HL7 messaging standard.

HL7 Version 3

The HL7 version 3 message standard is the descendant of version 2. The previousversion provided great flexibility in terms of allowing optional data segments andelements. The standard bases on XML as a syntax for messages. The standard usesthree information models, using the same notation Hinchley (2007). Each modeldiffers based on the information, content and scope (Hinchley, 2007). Therefore,HL7 version 3 can present information in a specified clinical context that assuresthat the semantic of the information is understood upon exchange between systems(HL7, 2019a).

Fast Healthcare Interoperability Resources (FHIR)

The HL7 also created Fast Healthcare Interoperability Resources (FHIR) for exchang-ing healthcare information electronically. FHIR combines features from HL7 v2, v3and CDA while leveraging the latest web technologies (HL7, 2019). It uses REST-APIbased on the HTTP protocol, HTML, CSS for user interface integration, and JSON,XML or RDF for data representation and sharing on the Internet (HL7 FHIR, 2019).This enables implementers to easily integrate, request and transform data betweendiverse health information systems. FHIR can also leverage terminology services,SNOMED-CT, LOINC, v2 table code, v3 code system and much more.

According to HL7 themselves, "FHIR is built on a set of modular components called"Resources" (HL7, 2019d). These Resources can easily be assembled into workingsystems that solve real-world clinical and administrative problems at a fraction ofthe price of existing alternatives". They also stated that the standard is suitable inmany contexts, "mobile phone apps, cloud communications, EHR-based data shar-ing, server communication in large institutional healthcare providers, and muchmore" (HL7, 2019d). Resources share the same set of characteristics, a commonmethod for defining and representing the resources, a common set of metadata anda human-readable part.

FHIR uses of web technologies as a principle to be able to search for Resources anduse CRUD operations (Create, Read, Update and Delete). It also has other operations(HL7, 2019b). The FHIR standard also provides excellent documentation, making iteasy to read. FHIR also uses the standard protocol HTTP for communication duringthe exchange of data between a client and a server (HL7, 2019d). This is mentionedin section OSI model.

Digital Imaging and Communications in Medicine (DICOM)

The Digital Imaging and Communications in Medicine (DICOM) standard is used to"transfer, store, retrieve, print, process and display medical image information"(DICOM,2019). DICOM is used in imaging equipment, image information and other types of


equipment. The standard specifies information in datasets. By using the examplefrom DICOM itself, a file of an X-ray contains X-ray identification, so the image isalways related to identity.

Statistical Data and Metadata Exchange Health Domain (SDMX-HD)

SDMX-HD is a standard for the exchange of aggregate data and metadata in thehealth domain. SDMX-HD is implemented by the World Health Organization (WHO)based on the ISO/TS 17369:2005 SDMX standard (Adebesin et al., 2013).

3.5.4 Structure and Content Standards

In this section, we present the Clinical Document Architecture (CDA) standard byHL7. This standard is restricted to clinical content.

Clinical Document Architecture (CDA)

CDA is a document markup standard for clinical documents by the HL7 organiza-tion and based on HL7 v3 where it uses XML elements and attributes to communi-cate clinical information. Boone (2011) eßxplains that "XML shares similarities withHTML but is a standard that other markup languages are built on". The CDA stan-dard enables clinical reports (scanned, computerized, handwritten) to be exchanged.With the use of the standard, the reports can achieve interoperability.

According to Boone (2011), a clinical document is organized in two parts, a headerand body. The document header entails context of the document. Next, the headercontains information about the author, organization, patient information or otherrelated information. Lastly, the document body contains human-readable text. Theterm human-readable in this particular context refers to the ability of a system torender text in a way that a human can interpret and understand without any addi-tional applications.

The various levels in CDA provide a higher degree of semantic interoperability inthe exchange of clinical documents. A CDA document has three levels, as seen inFigure 3.4 below.


FIGURE 3.4: Overview of the CDA Levels, as presented in Boone(2011)

Figure 3.4 shows that CDA level 1 provides a set of metadata to describe the doc-ument and the content. CDA Level 2 introduces structures to transform human-readable content into HTML, where code terms are used to identify sections. Lastly,CDA level 3 provides human-readable and machine-readable semantic content.

3.5.5 Clinical Terminologies and Coding

This section refers to clinical terminology and coding systems, giving a classificationdisease conditions and other health-related events.

Systematized Nomenclature of Medicine - Clinical Terms

Systematized Nomenclature of Medicine - Clinical Terms (SNOMED-CT) is a clin-ical terminology database containing medical concepts that represent clinical in-formation, e.g. coding for diagnosis and clinical results (SNOMED-CT). Accord-ing to Adebesin et al. (2013), the clinical terminology database also supports cross-mapping to other clinical terminology and coding schemes, such as, ICD-10 codes.This facilitates semantic interoperability, as mentioned in section Interoperability.Concepts in this database are organized in a hierarchy where the linkage of conceptsis through relationships.

Logical Observation Identifiers Name and Tags (LOINC)

Logical Observation Identifiers Name and Tags (LOINC) is a clinical code system forthe exchange of clinical results (laboratory tests and clinical observations) (LOINC,2019). Semantic interoperability can facilitate through the use of universal codesnames and identifiers of medical terminologies (LOINC, 2019). LOINC has differentcodes for the different tests where the clinical significance is different. For example,a LOINC code for "manual counting of white blood cells in cerebral spinal fluid sam-ple" is represented in a LOINC code 806-0 (LOINC, 2019). The format of the LOINCcode consists of six parts: component, property, time, system, scale and method. Forthis example, the LOINC code 806-0 explains the following: leukocytes, NCnc, Pt,CSF, Qn and Manual count (LOINC, 2019).


International Classification of Diseases (ICD-10)

International Classification of Diseases (ICD-10) is an international known codingsystem, and it is used for the classification of diseases and other health-related events(Ulrik, 2019). The purpose of this standard is to provide standard codes for diseaseconditions. For example, the codes ranging from G51.0 to G51.9 represent facialnerve disorders (World Health Organization, 2004). By drawing from that example,it becomes clear that the use of an alphanumeric code to represent diseases allowsfor easy storage, retrieval and analysis of the data. As mentioned above, the codingsystem is an international classification, which means all parties know of it, makingsemantic interoperability achievable.

Mapping Clinical Terminologies and Vocabularies

Coding systems such as SNOMED-CT, LOINC and ICD-10 make it easier to definemedical concepts, diseases and clinical results. However, Liang et al. (2016) arguesthat these coding systems do not define health data concisely. Therefore, they arguethat mapping terminologies will decrease the problem and make data more availablefor analysis at a bigger scale. In their study, they developed a system that gives theuser freedom to select terminologies and making their own mapping, for instance,mapping the clinical term "Hypertension" from ICD-10 to another terminology sys-tem, READ Clinical Terminology (version 2 and 3). Further, Dixon et al. (2015) elab-orate that mapping of local terminologies to standard terminologies and vocabularyis challenging. Their study shows that even with a software system for managingthe mapping, those who perform the mapping face issues where local and standardcodes and terms are similar. This requires knowledge to be able to "find the needlein the hay".

In this section, we have presented what is considered the common standards thatresearchers mention when it comes to integration and interoperability. Messagingstandards interprets to facilitate the integration of health information systems (HL7v2, v3 and FHIR). Built on this, we can facilitate interoperability with the use of clin-ical terminology and codes (WHO indicators, SNOMED-CT, LOINC and ICD-10).Table 3.3 below, we present common standards and terminology systems linked thelevels of interoperability, as discussed in section 3.3.

3.6 Proposed Solutions for Integration

This section presents some proposed solutions for integration of health informationsystems found in the literature.

Dlodlo and Hamunyela (2017) argues that integration with the purpose of health in-formation systems exchanging data, is through databases and Application Program-ming Interface (API). API refers to facilitate applications to communicate. While,Boochever (2003) argues that desktop integration is possible for hospital informa-tion systems, RIS and PACS. A desktop integration between RIS and PACS allows

3.6. Proposed Solutions for Integration 29

Standards and Interoperability Level MappingStandard Technical Syntactic Semantic Organizational

Information ExchangeHL7 V2 X XHL7 V3 X XDICOM X X

SDMX-HD X XStructure and Content

HL7 CDA X XClinical Terminologies and Coding

ICD-10 X XLOINC X X

SNOMED-CT X X

TABLE 3.3: Mapping Standards and Interoperability. Adopted fromAdebesin et al. (2013).

bi-directional communication. The author goes in-depth explaining that PACS noti-fies RIS that medical images are available. Then, RIS creates a tag in the diagnosticreport, which will be sent as an HL7 message to the hospital information system thatresults is available for viewing. Further details on desktop integration between RISand PACS is not discussed in the article.

Several countries have suggested adopting to an Open Health Information Exchange(OpenHIE) framework. Wolmarans et al. (2014) highlights that South Africa is adopt-ing this framework and their Health Patient Registration System (HPRS) serves theclient registry, as seen in the OpenHIE architecture (see Figure 3.5). Other nationale-health strategy documentations indicate that Kenya and Uganda also plan to adoptthe OpenHIE architecture (Republic of Kenya, 2016; Republic of Uganda, 2017). How-ever, these countries are still in the project initiation and planning phase, therefore,the information has been less forthcoming.

A study by Crichton et al. (2013) describes the development of the OpenHIE architec-ture for Rwanda, as shown in Figure X. They did a study on how to enable interoper-ability in the Rwandan Health Information Exchange. Consequently, a middlewaresystem called Health Information Mediator (HIM) was implemented and deployed.The HIM enable interoperability between existing systems and the national HIS. TheHIM was based on the Enterprise Service Bus (ESB) architecture model. Rwanda, be-ing one of the low-income countries in Africa, suffered from known HIS challengessuch as fragmented applications and applications are custom built serving specificneeds.

Figure 3.5 shows the Rwandan HIE architecture. The architecture has a Health Infor-mation Mediator, which is a middleware based on the technology of ESB, to enablenetwork transmission between the various application services. According to Crich-ton et al. (2013), the infrastructure services were built by several providers. The sys-tem openEMPI were used for their Client Registry. The HC Facilities Registry refersto the ResourceMapper (InSTEDD), which is an open-source tool giving insights todistribution and location of resources (InSTEDD, 2019). The Provider Registry has a


FIGURE 3.5: The OpenHIE architecture framework in Rwanda, aspresented by Crichton et al. (2013)

custom open-source web application built on OpenLDAP (a suite of directory soft-ware) by (OpenLDAP, 2019). The Shared Record refers to the OpenMRS, their EMRsystem. Also, the Terminology Service refers to Apelon DTS for management andpractical deployment of standardized terminologies and ontologies, and a web ap-plication developed by Jembi Health Systems NPC Crichton et al. (2013).

Focusing more on the Health Information Mediator (HIM), it did not occur as therewere any standard for messaging between external systems and the HIM. However,(Crichton et al., 2013) argues that the HIM is not restricted to any standards, as astandard that covers all types of messages has not yet emerged. Figure X shows thecomponents inside the HIM, enabling it to accept most messaging standards.

FIGURE 3.6: Overview of the OpenHIM architecture components inRwanda, as presented by Crichton et al. (2013)

Figure 3.6 shows the HIM architecture. It consisted of three main components: in-terface, persistence and mediator. The interface component receives service requestsvia an application programming interface. All the received service requests use astandard protocol (e.g. HTTP) and further translated into a common format that iseasily accessible by other components. The persistence component receives the ser-vice requests in correct format, and monitors and persistently stores the transactionsthat are required to complete the service requests. The mediator component trans-lates request message within the transactions into a format that other componentscan process (e.g. XML format to HL7 v2 message). Lastly, it checks for vocabulary orclinical terms for all transactions before the service request is determined complete.The study highlighted several service providers for the infrastructure services.

3.7. Cybersecurity 31

After the implementation, they evaluated that the architecture provides a solutionto the significant problems when attempting to facilitate interoperability betweendisparate health information systems. In practice, they add that the solution was ap-propriate, adaptable, and has the potential to scale. However, Crichton et al. (2013)proposed solution did not provide implementation specifics. The HIM is also a cen-tral point in their architecture, coordinating all interactions within the OpenHIE,becoming a single point of failure. Security assessment is also not discussed in thestudy. This makes it difficult for other African countries in the same context to strivefor the same approach.

3.7 Cybersecurity

In this section, we present the concept of cybersecurity. In particular, we discuss se-curity related to information, systems and networks. We also discuss this topic withhealth information systems.

Cybersecurity is the practice of protecting information assets, systems and networksfrom digital attacks Cisco (2018). For instance, we want to protect our informationassets from unauthorized individuals. However, unauthorized access is not the onlyconcern, and we need to consider that our systems and networks can be vulnerableto exploits. Cybersecurity consists of three aspects: information security, systemsecurity and network security. We will unravel these three aspects from the perspec-tive of health information systems.

3.7.1 Information Security

Information security refers to the process and tools used to protect sensitive informa-tion, specifically from modification and inspection (Cisco, 2018). Notably, personaldata is the type of sensitive information that we want to protect. Personal data refersto identifiable data, for example, genetic and biometric data, health-related data anddata that reveals one’s ethnic origin Commision (2019). It is prevalent that healthinformation systems store both aggregate data and patient information. For exam-ple, an electronic medical record system stores patient medical records with infor-mation such as patient demographics, medical history, diagnosis and prescriptions.Andress (2011) argues that information security must take into consideration whensensitive information is stored in information systems (p.2). Therefore, protectingthe patients’ information from being altered or inspected by those who are not au-thorized to access is vital because critical consequences could arise if the informationis compromised.

Principles in Information Security

The fundamental principles in information security are confidentiality, integrity andavailability, also known as the CIA (Harris, 2013) (p. 22). Confidentiality is referredto as the ability to protect data from those who are not authorized to view it. In-tegrity refers to the ability to prevent data from being altered by someone who isnot authorized. For example, integrity is compromised when an attacker alters a


patient’s drug dosage or prescription. Availability refers to the ability to access datawhen we need it. For example, availability is compromised when attacks are per-formed to disrupt or force the system to shut down, compromising the availabilityof critical information. Therefore, mechanisms must be set forth to preserve confi-dentiality, integrity and availability of information.

3.7.2 System Security

The second aspect of cybersecurity is system security. System security encompassesall aspects of assessing information assets. This refers to authentication, softwareupdates, antivirus software and more of Nebraska-Lincoln (2019). UNL states that"security is a vital component for a device to operating it is optimum." Furthermore,the process of designing a system must consider mechanisms to prevent the systemfrom attacks and vulnerable to exploits. In the context of health information sys-tems, a Denial-of-Service attack (DoS) could be performed by an attacker, where heinitializes many invalid connection requests to the network host forcing the host useup all the resources to respond to invalid requests and ignores the legitimate request(Harris, 2013) (p. 521). This attack could be present at a health facility, where a healthworker tries to access a web application and thinks that the system has crashed, anddata can be lost.

3.7.3 Network Security

Network security is a strategy for ensuring the security of networks and traffic. Net-work security is mainly about the authorization of access to the servers and systemsin the network. The network can be private or public. Network security has manydefence layers, at both edge of the network, to prevent exploitation of vulnerabilitiesand threats. Andress (2011) argues that network segmentation, firewalls, Intrusionand Prevention Detection Systems, antivirus and anti-malware software are ways tosecure the network (p. 168). Network segmentation and firewalls can be used in ahealth facility or hospital to divide the network into smaller networks (network seg-mentation) and control the traffic coming in and out of the network by configuringrules in the firewall. It is also advisable to install antivirus and anti-malware soft-ware on all devices on the network to protect from threats and attacks.

In summation, the implementation of security mechanisms reduces the potential at-tacks and threats, and safeguard organizations and individuals from unauthorizedaccess to information and prevent attacks on systems and networks. Notably, in thecontext of health, efforts to protect sensitive information is crucial. Additionally, afocus on securing the systems and network in sites where electronic health informa-tion systems are present is presumed as a necessity.

3.8 Open Systems Interconnections (OSI) model

In this section, we present the Open Systems Innterconnections (OSI) model, devel-oped by the International Organization for Standardization (ISO). The model aims at

3.8. Open Systems Interconnections (OSI) model 33

explaining computer-to-computer communications over a network. An understand-ing of this can help with understanding the integration process of health informationsystems.

The OSI model divides the communication into seven layers: Application, Presenta-tion, Session, Transport, Network, Data link and Physical layer (Kurose, 2013). How-ever, the Internet Protocol stack (TCP/IP) has five layers, excluding the Presentationand Session layer. The OSI model is a theoretical representation of communicationbetween two nodes. Therefore, specifications about hardware and software are notpresent in the model, which in turn can be applied to any organization.

3.8.1 Application Layer

The application layer is considered the highest layer in the seven layers of networkcommunication, following a top-down approach. The primary function of this layeris to offer protocols for exchanging messages between client and server applications.The applications itself are not a part of the application layer; although it is requiredthat the applications must follow the protocols for the service provided. The applica-tion layer has many protocols to support communication between server and client.In regard to health information systems, the Hypertext Transfer Protocol (HTTP) isthe most prominent protocol, enabling message exchange on the Internet. Crichtonet al. (2013) also mentioned the HTTP protocol. In the study, the protocol was usedto receive service requests from systems and applications to the health informationmediator via an application programming interface (API).

Kurose (2013) defines the presentation layer as “provides services that allow com-municating applications to interpret the meaning of the data which are exchanged”.The services include data compression and data encryption, which frees applica-tions from worrying about the informal format of stored data that may differ fromone computer to another.

3.8.2 Session Layer

Kurose (2013) defines the session layer as providing for delimiting synchronizationof data exchange, including the means to build a checkpoint and recovery scheme.

3.8.3 Transport Layer

The primary action performed at this level is to transfer data between applications.The transport layer provides an end-to-end connection between applications andsystems that runs on many computers. The two protocols at the transport layerare TCP and UDP. By comparison, TCP offers a connection-oriented communica-tion and UDP offers a connection-less communication (Hallsteinsen et al., 2008). Inother words, in a connection-oriented communication, a connection has to be estab-lished (a three-way handshake) before data can be transmitted and the connectionis shut down after transmission, while a connection-less communication means thatthe data packages are transmitted without notice to the receiver.


3.8.4 Network Layer

The network layer is responsible for packet forwarding and routing through inter-mediate routers. Essentially, the network layer moves data into and from other net-works. Kurose (2013) state that the network layer includes many protocols. How-ever, in this study, we consider the Internet Protocol (IP) as it can be related to theresearch scope. The Internet Protocol allows packets to traverse through multiplenetworks. This protocol is a connection-less protocol and uses a best-effort servicemodel (Hallsteinsen et al., 2008). This means that it delivers as reliable and as soon asit can; thus, the protocol does not guarantee delivery of packets. The most standardversions of the Internet Protocol are namely IPv4 and IPv6.

3.8.5 Data Link Layer

At the link layer, various protocols support the exchange of packets between thenetwork layer to other nodes. The link layers’ duty is to prepare packets throughframing and other mechanisms so that the content can be transferred to the physicallayer. Some examples of protocols present at this layer are IEEE802.2, IEEE802.3 forEthernet and Local Area Network (LAN), and IEEE802.2 and IEEE802.11 for Wire-less Local Area Network (WLAN) (Hallsteinsen et al., 2008). A LAN refers to a groupof computers and devices that share a common communication line, while WLANallows devices to connect and communicate over a wireless medium. Particularly,LAN and WLAN is relatively widespread and can be found within a limited area,such as homes, universities, office buildings, health facilities, hospitals and more.

3.8.6 Physical Layer

In order for computers to be able to communicate with the Internet, a connection tothe Internet is required. The physical layer consists of several network components,and we will present the most common components in regard to the research context.A switch is a computer device that allows us to connect devices on a network. Forexample, allowing a computer to connect to the network at the health facility. It usesmethods as packet switching and forwards the data to the designated destination.The use of switches enables scalability in the network.

Another network component is routers. The use of routers enables forwarding ofdata packets between computer networks (Hallsteinsen et al., 2008). A router can beconnected to two or more networks. When a data packet comes into the router, itreads the routing table to decide the destination to forward the data packet. Othernetwork components are gateways and firewalls. Gateway is a device that forwardsthe traffic based on the information from the layers above the network layer in theOSI model, while a firewall is a device that controls the network and can filter mali-cious traffic.

Figure 3.7 illustrate all the 7-layers of the OSI model. Following a top-down ap-proach, we interpret that the application, presentation and session layers are rele-vant for data exchange between health information systems on different networks.

3.9. IT Infrastructure 35

FIGURE 3.7: Overview of the OSI model and rotocols

These layers perform encryption, compression and translation of the data, and man-age sessions between the devices. The lower layers (transport, network, data linkand physical) handle the transport of data between networks and the physical equip-ment involved in data transfer.

3.9 IT Infrastructure

In this section, we define the IT infrastructure. IT infrastructure can be related tothe infrastructure of HIS where management of the infrastructure is interpreted ascrucial work for ensuring that HIS is up and running. Additionally, the benefits withDevOps shows that it can improve the efficiency of an infrastructure.

Gartner (2019) defines an IT infrastructure as “the composite of hardware, software,network resources and service components that support the delivery of business sys-tems and IT-enabled processes". In this context, management of the infrastructurerefers to the operation and maintenance of systems. Further, it is perceived that con-cepts like configuration management, version control, monitoring, logging, storing,backup, inventory, documentation and task manager are the infrastructure servicesthat support the operation and management of the IT environment of an enterpriseLimoncelli (2007). These infrastructure services aim to support the organizations’overall objectives. For instance, configuration management refers to the concept ofmanaging the configurations of systems in the infrastructure. Tools like Puppet andAnsible support the management of systems by using a high declarative languageto describe how systems should be installed and configured (Ansible, 2019; Puppet,2019). Logging provides the ability for systems to log system information and er-ror messages can help with troubleshooting issues. This is also another strategy tomanage the infrastructure. Additionally, monitoring services provides the state ofthe systems and services in the infrastructure. The value of knowing the state of the


systems is the ability to react to error, prove compliance and be able to predict thefuture. A standard tool for version control software development is Git, allowing adeveloper to use the command like "git pull/fetch" to get new changes. However,Git can also be used to manage the infrastructure in the same way, where it can getchanges to track deployments. Semantic versioning can also be a strategy to han-dle the infrastructure and states, because it has a formal convention to distinguishversions, X.Y.Z. X stands for significant versions (significant changes), Y stands forminor versions (minor changes), and Z stands for patches (bug fixes).

Docker is a container platform that allows organizations to build, share and run anyapplications seamlessly (Docker, 2019). A Docker container is a unit of software thatpackage up code and all its dependencies into a container so applications can bereliably moved from one environment to another, e.g. from a developer’s laptopto a test environment Docker (2019). Docker is also more beneficial compared tovirtual machines, where the spawning time of containers are shorter because it doesnot run on a full operating system, using fewer resources (Docker, 2019). Based onthis, Docker can be referred to as an infrastructure technology, because it helps todecrease the resource use in the overall infrastructure – supporting the managementof the infrastructure.

DevOps

DevOps is a software development practice that combines software developmentand operations. The emergence of DevOps has proved that the software develop-ment life cycle can be shortened. Previously, the software development lifecyclecan be described as a waterfall where all the stages of development are sequential.Over time, risks can increase because the project becomes overwhelming and doesnot take customer feedback into consideration. On the other hand, DevOps follows amore agile methodology where the project is divided in iterations allowing feedbackfrom the customer to increase the quality of the product. Combining software de-velopment and operations means that customers can receive frequent updates anddelivery. Further, DevOps also allows for Continuous Integration and Development(CI/CD). Continuous integration refers to the practice where developers merge codeinto a central repository to subsequent run automated builds and tests. Git is a toolthat ensures that developers can merge code from their local laptop to the centralrepository. Continuous delivery refers to the practice where changes in the code areautomatically built, tested and prepare for release onto production RedHat (2019).The difference between continuous integration and delivery is that continuous de-livery ensures that code changes can be moved into a testing and production envi-ronment after the build RedHat (2019). Jenkins is an automation server that providesautomation in every phase of the software development life cycle, ensuring the De-vOps practices, CI/CD.

3.10. Summary 37

3.10 Summary

This chapter presented a review of the literature regarding Health Information Sys-tems (HIS) and the integration of these systems. The chapter included many con-cepts to support the understanding of the integration. The concept of Health infor-mation systems (HIS) Clinical Information Systems (CIS) is presented. Further, thechapter presented the challenges with information systems to support healthcareservices and delivery, based on the current related literature. It also described inte-gration and interoperability and health data standards. These concepts are highlyrelevant for the understanding of the integration of HIS, and the chapter also pre-sented proposed solutions for integration based on the literature. The concept of cy-bersecurity denoted methods to prevent the information, system and network fromattacks and threats. Lastly, concepts asOpen Systems Innterconnections (OSI) modeland IT infrastructure is presented.

The next chapter presents the chosen research design, method and data collectionmethods used in this study.

39

Chapter 4

Methodology

This chapter presents an overview of the research method and design and the datacollection method. It also covers a purposeful sampling of participants, analysis ofthe data, and how we measure the quality of the research design.

4.1 Research Method

The research method chosen was qualitative because we need to understand the in-tegration processes of Health Information Systems (HIS) Creswell (2007)(p. 40). Theresearch method uses an interpretive inquiry, which means that the researcher in-terprets what they see, hear and understand, avoiding rigid and structural forms.This method focuses on the participants’ perspectives and their meanings to under-stand the problem or issue, providing a holistic view for the researcher Creswell(2007)(p. 39). Qualitative research also follows an emergent research design, mean-ing research questions, data collection forms and sites visited may change duringthe research. These characteristics define qualitative research because we want tounderstand the problem or issue from the participants and to address the researchwith that information Creswell (2007).

4.2 Research Design

The research design chosen is a case study. Creswell (2007) argues that a case studyresearch design is preferred when wanting to study an issue explored through a casewithin a context (p. 73). A single instrumental case study was chosen as the objec-tive of this study was to understand the integration processes of HIS in Malawi. Yin(2014) argues that research questions that are dominated by “how” and “why” alsosuits case study research (p. 9). The data collection in a case study can draw onmultiple sources of information; documents, archival records, interviews, observa-tions and physical artifacts Yin (2014) (p. 106). The study also follows an embeddedanalysis of the data, meaning we analyze specific aspects of the case Yin (2014) (p.50).

40 Chapter 4. Methodology

4.3 Data Collection Methods

The data collection methods used in this study are interviews, documentation anddirect observations. These types of sources will provide evidence and understand-ing of the complex picture of Health Information Systems (HIS) integration processin Malawi to generate useful information and achieve Universal Health Coverage.Table 4.1 gives an overview of the data collection methods.

Methods Entails Purpose

Interviews

Interviews with individualsin the target participantgroups, with open-endedinterview guide.

Insights to integrationprocess through participants’knowledge, experiences andpersonal perspectives.

DocumentationTechnical documents,presentations and reportsverify specific details.

Understanding of concepts,strategies and objectives thatare used in terms ofintegration of HIS.

Direct ObservationStudy health workers intheir natural environment.

Get insights to healthworkers’ workflow and howthey use information systems(paper-based and digital).

TABLE 4.1: Data collection methods

4.3.1 Interviews

The most frequent used source for collecting information for evidence is interviewsYin (2014). This method provides insights, explanations and personal perspectives.The strength in interviews is that they are targeted, meaning they are focused onparticular topics for the case study. A good strategy is to have an interview guidewith open-ended questions, where one can divert from the guide when interest-ing themes are brought up. However, poorly articulated questions can lead to biasquestions and responses. In cases where the interviewee does not recall, they mightprovide inaccurate answers, which enable reflexivity where interviewee gives whatthe interviewer wants to hear.

We held several interviews to increase validity. The interview guide was sent to sev-eral key people, to eliminate leading questions and ensure questions were open forinteresting themes to occur during the interviews.

The intended context for this study was South Africa. Upon conducting a researchstudy in another country, an ethical clearance application must be sought to justifythe research. Delays in the handling of the ethical clearance process lead to a lack oftime. The delays in the ethical clearance process kept us waiting for eight months.Consequently, this led to a lack of time, and the research context and data collectionwere shifted to Malawi. Therefore, a majority of our empirical evidence comes from

4.3. Data Collection Methods 41

the data collection in Malawi, but a visit to the originated research context also pro-vided insights.

In our study, a purposeful sampling of participants was conducted before schedul-ing interviews. Table 4.2 provides an overview of interviews, where Kuunika andLuke International are two organizations where we conducted the interviews. All ofthe interviews were recorded, transcribed and saved based on the participants’ jobtitle. A recording device was used under the interview upon consent from partici-pants, see Appendix X for information letter and consent form.

Role Quantity Organization Duration in MinutesProduct Owner 1 Kuunika 23Senior SoftwareDevelopers

2Kuunika andLuke International

48, 20

Software Architect 1 Kuunika 120Head of HMIS 1 Mzuzu Central Hospital 60

TABLE 4.2: Overview of interviews

Table 4.2 shows that interviews were conducted at two sites, Kuunika and Luke In-ternational. The majority of interviews were conducted on interviewee with techni-cal background. These informants provided insights that were identified as lackingin the literature. The average time for the interviews were 54 minutes.

Other sources of evidence were informal conversations. The informal conversationsprovided insights into the state of HIS and the added workload for health workersin disparate HIS environment. Informal conversations occurred in two health facil-ities in KwaZulu-Natal, South Africa, the intended research context. Due to ethicalclearance delays, we set the research context for Malawi, where interviews and in-formal conversations took place at a central hospital in Mzuzu, at the developmentsite at Kuunika and Luke International. However, the insights from South Africaadds value to our study. Disparate HIS environment and the lack of integration ofsystems was also present in South Africa.

4.3.2 Documentation

Another source of information is documentation, which involves technical docu-ments, presentations and reports. Documentation can help verify specific details.On the other hand, there can be challenges with retrieving and accessing documents.

4.3.3 Direct Observations

Yin (2014) argues that direct observation can cover the context of the case and coveractions in real-time (p.106). Observational evidence can arguably add additional in-formation about the study topic. In this study, we do not observe patients, eventhough they are a part of the study context, we do not consider them in our observa-tion notes. Our observations are mainly focused on the workflow of health workers


and their use of various information systems in the field environment.

In our study, our observation site was at a hospital, Mzuzu Central Hospital, locatedin the city Mzuzu, north in Malawi. The hospital is divided into various departments- the main observation site was at the outpatient station where the EMR system islocated. We also observed the workflow of health workers in two health facilities inKwaZulu-Natal, South Africa.

At the Mzuzu Central Hospital, we observed that when a patient arrived at the sta-tion and handed in their health passport, the health worker would register the pa-tient in the EMR system and type in patient’s prescription. The health workers atthe outpatient station had to usually type in the prescriptions in the system, as clin-icians prefer to write these prescriptions by hand. Lastly, the system prints out theprescription and stickered it onto the health passport before the patient can go to thepharmacy for drug dispensing.

In addition to the outpatient module, the system also had a module for care andtreatment of HIV patients, while modules for other diseases is not found in the sys-tem. The EMR system is integrated with PACS, meaning that health workers canretrieve medical image results from the EMR system. The workflow of health work-ers at the outpatient station is interpreted as recurring work, as they have to type theprescriptions into the system because clinicians preferred to handwrite the prescrip-tions. This step is crucial for assuring health information is digitally available.

At the two health facilities located in KwaZulu-Natal, it was present that the processof dispensing prescriptions included the use of several information systems - addingmore subtask to pharmacist’s workflow.

4.4 Purposeful Sampling

The selection of the participants for this study is through a purposeful sampling.This technique involves the identification and selection of individuals or groups ofindividuals that are well-informed with the phenomenon of interest. The character-istics of the target participant groups bases on professional background. There aretwo participant groups, where the first participant group focus on participants thatare familiar with the use of health information systems (e.g. managing roles). Thesecond participant group was chosen as they hold technical competence and shouldbe able to explain the integration process of health information systems (e.g. soft-ware developers and software architects). Each of these participants will provideinsights and perspectives to the research issue accordingly to their role and respon-sibilities, see Table 4.3.

4.5. Analysis 43

Participants of InterviewsProduct OwnerSoftware DevelopersSystem AdministratorSoftware ArchitectHead of HMIS

TABLE 4.3: Interview participants

4.5 Analysis

In this section, we describe how the data was analyzed. The general objective ofqualitative data analysis is to be able to conclude from the data and keep a clearchain of evidence, meaning that "information at each step of the study and every decisiontaken by the researcher must be presented" Runeson and Höst (2008)(p. 151).

The data were grouped into multiple sources of evidence: interviews, observationsand documentation. For the interviews, we used a recording device and had to tran-scribe all the interviews. For observations, a reflection note was created during theobservation stage, which later was revised. We chose to use a technique called cod-ing to analyze our data. The process beings with reading through our sources of dataand label essential pieces, such as words, phrases, sentences or sections. Following,we give the essential pieces a theme or combine them into themes. Consequently,we get an overview of the themes throughout the sources of evidence and can seethe interconnections of themes.

NVivo is a software tool to support qualitative data analysis. This software supportsthe process of organizing our data into themes, or nodes as it is called in NVivo.From this, we can get an overview and produce empirically-based findings whichcan be found in Chapter 6.

4.6 Quality of Research Design

Yin (2014) argues that a good research design can use four tests to verify the qualityof the design; construct validity, internal validity, external validity and reliability (p.45). By using these four tests, we can reduce the threats to validity of a qualitativecase study.

4.6.1 Construct validity

Construct validity is defined by Yin (2014) as "identifying the correct operational mea-sures for the concepts being studied" (p. 46). There are three tests to increase constructvalidity. The first test involves using multiple sources of evidence, i.e. interviews,documents and observation. The second, establish a chain of evidence. The lasttest is about reviewing the draft of the case study. It was given to key people forreviewing purposes.


4.6.2 Internal validity

Internal validity only concerns with explanatory or causal studies Yin (2014). Ourstudy is interpretive; therefore, internal validity is not relevant (p. 47).

4.6.3 External validity

External validity concerns about whether the findings can be generalized to otherrelevant settings or groups. The use of research questions increases external validityYin (2014) (p. 48).

4.6.4 Reliability

Reliable research refers to obtaining the same result by repeating the same data col-lection methods. The purpose of reliability is to reduce error and biases. Yin (2014)argue that following a use case study protocol is a way to increase reliability in theresearch.

4.7 Summary

This chapter presented the chosen research method and design for our study: qual-itative and case study. Several types of sources (interviews, observations and docu-ments) was used for our data collection in Malawi. The strategy for selecting partici-pants was also explained. We also described the analysis of the study and discussedtests to increase the quality of our case study. The next chapter presents the ethicalconsideration we made before conducting the study.

45

Chapter 5

Ethical Considerations

This chapter present the ethical considerations that have been put forefront beforeconducting the case study.

5.1 Participant Information Letter

Participants’ information letter was provided to all the participants to read. Theparticipant information letter contains a written appeal to participate in the study,the title of the research, purpose, description of the research and their involvement.The information letter will be available in English.

5.2 Written Consent

Each of the participants will be provided with a letter explaining the research study.The letter requests their participation. Consent will be sought and provided to theparticipants. By signing the consent form, they agree to participate. Clarificationswill be provided in cases of confusion or doubt.

5.3 Confidentiality

Sensitive data about the participants will not be collected, so anonymity is protected.During the data collection, the data we collect about the participant is job title andprofessional background. We collect such data as a base to better understand theparticipants’ response. Consequently, we can ensure that the identity of participantsin the study is not revealed in any discussion, description or scientific publications.

The process of preserving the confidentiality of consent forms separately from thedata is only to address participants job title in our data.

Participant information letter and written consent form can be found in AppendixX.

46 Chapter 5. Ethical Considerations

5.4 Summary

This chapter presented the ethical considerations we made before conducting thisstudy. An information letter was handed to participants. Further, we described themethod of protecting the confidentially of participants. The next chapter presentsthe findings of our study.

47

Chapter 6

Findings

This study aims at investigating the integration processes of Health Information Sys-tems (HIS) in Malawi. In this chapter, we present the empirical findings and state-ments of the conducted study. In the analysis of our data, the same themes discov-ered in Chapter 3, was also present: integration, standards and infrastructure. Thefindings will be presented accordingly to the three themes.

6.1 Integration Approaches to Health Information Systems

Our empirical study shows that the integration of Health Information Systems (HIS)is present at two levels of the health system, national and facility and patient level.

6.1.1 Integration at National Level

At the national level, the objective of integration is for health information to be eas-ily shared and accessed across multiple information systems. The Open Health In-formation Exchange (OpenHIE) architecture was used as a guide for the enterprisearchitecture the team at Kuunika are currently developing, as mentioned in section3.4. A team of consultants at Kuunika adopts this architecture framework, whichaligns with the objective and Ministry of Health (MoH) vision regarding the sharingof health information.

The integration approach at this level is building a national data sharing infrastruc-ture. This infrastructure framework is adopted from OpenHIE architecture frame-work. The architecture consists of two layers, a component layer and an interoper-ability layer, as mentioned in section 3.4.4. The component layer consists of infras-tructure services, which are essential components to enable easier interoperabilitybetween health information systems. The interoperability layer consists of a soft-ware component called Open Helath Information Mediator (OpenHIM). It also hascomponents to authenticate, link and match the requests from external systems. Ex-ternal information systems, such as clinical information systems that want to connectto the OpenHIM, have to adhere to the predefined data exchange standard. Stan-dards are discussed in section 3.5. The interoperability acts as a central point whereit connects the external systems and infrastructure services to enable interoperability.

48 Chapter 6. Findings

The OpenHIE in Malawi follows a centralized model, where data is intended to bestored in a centralized repository at the national level. Each remote facility will alsohave their local repository, which will be harmonized with the central repository, asmentioned in section 3.4.4.

The project of developing and building OpenHIE architecture for Malawi has atimeframe of 4 years. In this solution, there are two use cases, an Department ofHIV/AIDS Management Information System (DHAMIS) and a Open LaboratoryInformation System (OLIMS). DHAMIS and OLIMS are the two national core infor-mation systems that want to push data into the District Health Information Systems(DHIS2).

The preliminary work was developing mediators in the OpenHIM. The team de-veloped a mediator called Aggregate Data Exchange (ADX), see Figure 6.1. Themediator facilitates data migration from the national core systems into DHIS2. TheADX mediator was built because DHIS2 deals with aggregate data. The ADX medi-ator transforms the data from the two core national systems into a format that ADXunderstands and validates it before it is pushed into the system. Further, the teamalso have another mediator in the OpenHIM, namely Demographic Data Exchange(DDE), see Figure 6.1. The DDE mediator issues unique patient IDs. It also detectsand resolves any duplicate patient data record and enable the sharing of patient de-mographics. Based on this, the informants at Kuunika state that the mediator playsa crucial role for the development for supporting infrastructure services and a na-tional data sharing infrastructure.

FIGURE 6.1: The OpenHIE Architecture in Malawi

6.1. Integration Approaches to Health Information Systems 49

Figure 6.1 shows the flow in the architecture. External systems wanting to push datainto the national core systems must connect to the interoperability layer. Upon con-necting, these systems must adhere to the Fast Healthcare Interoperability Resources(FHIR), a standard for exchange of health data, as mentioned in section 3.5. Our em-pirical evidence shows that the FHIR standard uses the standard protocol HTTPduring the exchange, enabling technical interoperability. This refers to the Applica-tion Layer in the OSI model, as mentioned in section 3.8. Requests from the externalinformation systems go to the OpenHIM core, where mediators must be registeredto be able to interact with the core. Then, the mediators in the core authenticate re-quests and transform and validate, before data is migrated to a particular system.

Consequently, a response is given to the OOpenHIM core and further to the client(external systems) via an OpenHIM console. The OpenHIM console allows clientsto see an overview of the transactions. This is possible because the OpenHIM coreshares the information via REST API to the OpenHIM console. An email is also sentout at the end of the migration process containing an executive summary.

A factor that challenges the development of the interoperability layer is inadequateinfrastructure and poor network connectivity in the country. Informants at Kuunikaenlighten us that they have built the OpenHIM and two mediators (ADX, DDE), andone infrastructure service, the Facility Registry (FR). One of the mediators they havebuilt has considered the network connectivity issues in the country. Therefore, func-tions were added to handle such edge cases. The software architect states:

The infrastructure services are the building blocks; which means you cannot dointeroperability without them. Based on this, it almost seems like we are doingthings backwards - Software Architect

The software architect reflects on the proposed solution decided with scale in mind.Therefore, he described that the integration processes could feel backwards becauseall components of the OpenHIE architecture must be built and handle cases such asnetwork issues.


6.1.2 Integration at the Facility and Patient Level

At the Mzuzu Central Hospital, we observed that the hospital uses both electronicand paper-based health information systems.

FIGURE 6.2: Overview of HIS at Mzuzu Central Hospital in Mzuzu,Malawi

The overview in Figure X shows that there is a lack of integration between manysystems.The national Electronic Medical Record (EMR) system has three modules;Outpatient-Diagnosis (OPD), Antenatal Care (ANC), and Antiretroviral Therapy(ART). Some of the systems are paper-based, such as inpatient and pharmacy. Itwas observed that pharmacist had no record of drugs that had been dispensed, eventhough the health worker at the outpatient station use the dispensing function inthe EMR system to specify the drugs for the patients. The laboratory informationmanagement system (LIMS) is a stand-alone information system in the hospital’sHIS architecture. The HIV dispensary module is integrated with the ANC and ARTmodule. The HIV Testing and Counselling Services (HTS) is integrated with DHIS2for aggregate data. The HTS system is not integrated with any modules in the na-tional EMR system, but a paper-based testing activity register is often used whenthere is no network connectivity. Then, one functioning integration is between out-patient diagnosis module and Picture Archiving Communication System (PACS).Through the outpatient diagnosis module, one can use the Radiology Exam func-tion to request orders and view results.

At this level, the empirical evidence shows that the integration approach betweenclinical information systems is desktop integration. Particularly, at the Mzuzu Cen-tral Hospital, we found out that there was a desktop integration between the na-tional EMR system and PACS. This approach was also mentioned in section 3.6.


Context Sharing

The integration approach between national EMR and PACS makes use of a contextserver. The context server acts as a mediator component to facilitate integration be-tween IMPAX client and other third-party applications. Client applications mustbe registered to the context server. After that, it can communicate with the contextserver via its public interface, asking for permission to dictate studies. Furthermore,our technical guide on desktop integration explains that context sharing enables bi-directional communication. We interpret this as communication between two regis-tered applications. Figure 6.3 illustrate this communication.

FIGURE 6.3: Context Server enables bi-directional communication

The IMPAX 6.2 Client uses a scripting language to provide automation. The guidesuggests writing VB.NET programs to control the behaviour of the IMPAX clientand access the objects it obtains. This means one can create scripts to dictate studies.Some behaviour functionalities that we want to call from our IMPAX application(outpatient module) is:

Logging into IMPAX client Scripts must be created to sign-on from both parties:IMPAX client and the third-party application. Sign-off scripts must also be createdfor the user to sign-off from the applications.

Select studies for display Scripts must be created to be able to identify studies andload study images.

Display study images Scripts must be created to change the display of studies.

Dictating studies Scripts must be created to dictate studies from both parties: IM-PAX client and the third-party application.

According to the guide, it was prevalent that this integration approach was limitedto applications that reside on workstations. There is only one instance of the contextserver running on the computer, and ongoing dictations from one client cannot bedisturbed by another client. This type of integration discrete and do not scale withcomprehensive workflows.


The desktop integration for national EMR system and PACS were done by the teamat Luke International, even though Baobab Health developed and implemented theEMR system. The software developer at Luke International state that integrationof information systems at the facility level is difficult because donor organizationsand aid-agencies fund most systems. Since donors are interested in using a specificinformation system to monitor their health programmes, technical people do not seethe point of integrating when donors are only concern with a particular system.

6.2. Technical Challenges with Integration 53

6.2 Technical Challenges with Integration

This section presents the challenges with the integration of Health Information Sys-tems (HIS). These challenges regard standards, connectivity, and infrastructure andnetwork. Therefore, we identify them as technical challenges.

6.2.1 Language Barrier for Health Information Systems

The objective of enabling information sharing across Health Information Systems(HIS) has two aspects. The first aspect is integrating systems by enabling them tospeak the same language, for example, using the same messaging standard for theexchange of health data. The other aspect is using the same terminology and codeswhen referring to diseases and conditions, so that data is meaningful for other sys-tems upon data exchange. Our empirical evidence shows that both aspects werepresent with the interoperability layer.

In the first aspect, all of the informants highlighted the importance of informationsystems, speaking the same language to be able to exchange data and to share infor-mation. Without an agreed-upon standard for health data exchange, a language bar-rier appear for systems and integration is impossible. During the project planning ofthe interoperability layer, the team at Kuunika decided to use the Fast Healthcare In-teroperability Resources (FHIR) standard for health data exchange. This means thatexternal systems must also use the standard when connecting to the interoperabilitylayer to push data. The software architect provided this statement FHIR during theinterview.

We have a very strict policy about exposing FHIR resources to all of our clientsby default – Software Architect

He justified the statement by explaining that the decision on using the messagingstandard FHIR is because it is the most prominent standard across health data shar-ing. The decision to command FHIR to external systems upon connecting to theinteroperability layer is a vital factor for integration and interoperability. The ratio-nale is that the standard is universally agreed upon, and many resources are makingit easy and intuitive to use. The interviews also illuminate a global consumer optiontowards using the FHIR standard. With consumers, the option comes with a naturalnudge, as the resources are widely available and big actors also use the standard,then it must be easy to use and lead to innovation.

The other aspect refers to having a mechanism to map clinical terminologies andcodes that different health information systems use. Regarding the Open Health In-formation Exchange (OpenHIE) architecture, the Terminology Service (TS) will dothe mapping for various terminologies and codes. The senior software developerat Kuunika explains that mapping International Classification of Diseases (ICD-10)codes and Logical Observation Identifiers Name and Tags (LOINC) codes will makesystems interoperable. The software architect, adds to this, stating the WHO indica-tor list will be a reference for all the terminologies and codes that various systems


use.

Our empirical evidence shows that the desktop integration at the facility and pa-tient level between national Electronic Medical Record (EMR) and Picture Archiv-ing Communication System (PACS) rely on the IMPAX Context Server to be able torequest and display medical images.

6.2.2 Network Connectivity

Network connectivity is the biggest challenge when it comes to electronic data ex-change between HIS. Since at the facility and patient level, systems are often downbecause of lack of network connectivity. In these circumstances, health workers haveto collect data using paper, then enter information manually into the systems. Ourobservations also show that some systems did not have the ability for back dataentry, meaning entering historical data.

Poor network connectivity also affects integration because most messaging stan-dards exchange health data electronically. In Malawi, it was apparent that mostdata are located in local facility sites, where data migration requires data to be sentover the Internet to national servers using a standard HTTP protocol, as mentionedin section 3.8 (OSI model) and section 3.3 (Interoperability). This means that inte-gration relies on Internet connectivity, and technical interoperability is achieved byusing the HTTP protocol. The senior software developer at Kuunika shed light onbuilding mediators with mechanisms to detect failed data migrations. A rationalefor creating such logic is due to poor network connectivity; for instance, no networkconnectivity between the interoperability layer, Aggregate Data Exchange (ADX)mediator, and District Health Information Systems (DHIS2) results in data not beingmigrated into DHIS2.

The ADX has a console, where clients (external systems) can view the process oftheir migrations on a dashboard. Since data is migrated from a local server into thenational DHIS2, it requires HTTP communication. In particular, there is an HTTPrequest and response between the ADX mediator and the client. For instance, theclient pushes the data, sending an HTTP POST message code to the ADX. The ADXreceives the request, and several types of HTTP message code could be given in re-sponse. The software architect explains that HTTP 200, 202 and 203 is the standardHTTP message code. HTTP 200 state that the request was received and understoodand is being processed. HTTP 202 means that the request was received but not pro-cessed, and HTT0 203 indicates that the request was received and understood, but"the enclosed payload has been modified" Fielding and Reschke (2014). The soft-ware architect at Kuunika informs that the network connectivity is slow. Thereforean HTTP request/response connection cannot be open for the whole migration pro-cess. Therefore, the connection gets killed, and the client gets a migration ID, wherethey are able to track the process via the user interface (ADX console).

An executive summary is sent to the clients after the migration via email. The sum-mary can list the following: number of data elements received, number of success-fully migrated data elements, number of data elements with validations issues, and


number of data elements that were not migrated due to network connectivity.

Furthermore, the software architect shares the idea of using several instances ofDHIS2 to reduce bottleneck when it comes to data migration. The migration periodwould commonly be at the end of the reporting period for most health programmes.

6.2.3 Poor Management of the Infrastructure and Network

Poor management of the infrastructure and network also affect the integration ofHealth Information Systems (HIS). At Kuunika, the development site of the inter-operability layer, it was explained that the use of many physical servers takes timeto spawn up and can slow down the development process. Here, the system ad-ministrator refers to the development of the OpenHIM. He adds that there was anincident where they tried to host some server virtually, which eventually lead tomemory leaks. This affects the systems and servers and requires management ofthe infrastructure. In hindsight, a dedicated hypervisor would be appropriate fora virtual machine acting as a server. The use of virtual machines and containers asservers were preferable over physical servers, as their spawning time is shorter anduse fewer resources, avoiding memory leaks.

The system administrator state that he uses infrastructure technologies (e.g. Docker)because it helps to decrease the resource use in the overall infrastructure, as men-tioned in section X. The administrator shares that he introduces containers where itis appropriate because containers use fewer resources than virtual machines, and itis easy to spawn up and takedown. Containers are a "standardized piece of softwarethat package code and all its dependency, so the application runs quickly and reli-ably from one computing environment to another" Docker (2019). In particular, heshares that they have a specific virtual machine were the applications run in Dockercontainers and that DHIS2 were containerized. It was also observed that an au-tomation server (Jenkins) was used at Kuunika for automation of the developmentlife cycle of the interoperability layer and infrastructure services in the OpenHIEcomponent layer. From the system administrator’s perspective, the infrastructuretechnologies enable him to do Continuous Integration and Development (CI/CD)as mentioned in section 3.9. This allows frequent updates and delivery of the prod-uct. He also wants to install a local Git server (version control system) so developerscan build, test, on their local.


DevOps was also a topic which came up during the interview. He played with theidea of DevOps as the role of being a system administrator has limited functionswhen the interoperability layer is deployed. The concept of DevOps refers to a con-cept where a developer also does operations tasks. Going further, he states:

I think DevOps is the way to go, and also I’m currently doing a Google cloudplatform course and want to look into AWS. I also finally decided to learn python- System Administrator

This statement shows the excitement for the use of known infrastructure technolo-gies where it is suitable. The software architect also advocates for using cloud tech-nologies in this project. He states:

Hypothetically, hosting DHIS2 on Amazon Web Services (AWS) cloud couldfacilitate replication of DHIS2 instances and distribute these instances acrossmany servers to avoid bottlenecks during the migration process - Software Ar-chitect

Going back to the network, the previous topology of the network at Kuunika wasunorganized. The system administrator illustrates the new topology consisting ofone firewall and two switches, see Figure 6.4. The firewall is a tool to protect thenetwork and monitor the incoming and outgoing traffic. The switches segregate thenetwork into a LAN and WLAN. This is mentioned in section 3.8. Additionally, weobserved that the system administrator used tools to monitor the network activity,applications activity and performance ensures that assessment of the infrastructureand the network is easy. He receives weekly and monthly notifications from themonitoring services, which enables more control of the infrastructure and network.

FIGURE 6.4: Network topology at Kuunika


Figure 6.4 shows that the network where the team are building the interoperabilitylayer is small, consisting of one firewall, two switches that segregate the networkinto a LAN and a WLAN.

6.2.4 Lack of a Strategy for Information Security

Informants at Kuunika shed light on their concerns for preserving information pri-vacy when it comes to their national data sharing infrastructure (OpenHIM). Thesoftware architect adds to this by raising the importance of creating policy docu-ments regarding data governance and information privacy. Based on this, it can beinterpreted that the software architect is concerned with preserving the triangular ofinformation security principles, confidentiality, integrity and availability (CIA). Hestated that the development of the SHR would require policies and mechanisms topreserve the CIA triangular. The system administrator also added to the concern ofinformation security and stated that the importance of having an organized networktopology and use tools to monitor the incoming and outgoing traffic of the network.Here, the system administrator refers to preserving the system and network secu-rity. Mechanisms like network segmentation and firewall provide him control overthe network and the infrastructure.

These perspectives ground that a lack of a strategy for preserving information se-curity could hinder the integration of health information systems. Notably, a lackof authentication and authorization in the interoperability layer (OpenHIM) meansthat external systems cannot access data (e.g. a patient record), which contradictsthe purpose of integrating disparate health information systems. Policies and mech-anisms must be in place to handle "who can see what data and when". The team atKuunika have developed a roadmap for future implementation, where data gover-nance is included as one of the tasks, see Figure 6.5.

FIGURE 6.5: The roadmap for National Data Sharing InfrastructureOpenHIE in Malawi

Figure 6.5 shows that developing a strategy for information security is consideredvital for future steps. The figure also shows the subsequent development of infras-tructure services is Terminology Service (TS), expanded health data exchange serviceand the Shared Health Record (SHR)


6.3 The Integration Effect

This section presents the outcomes of Health Information Systems (HIS). Two out-comes were highlighted, better information flow and an improved developmentpipeline.

6.3.1 Better Information Flow in the Health System

The development of the interoperability layer at the national level, allow data to beexchanged between health information systems, and ease interoperability betweenthem. This means that information is more available for those who need it. Specif-ically, aggregated data from the national core information systems can be pushedto the District Health Information Systems (DHIS2). The interoperability layer alsoconsiders the exchange of patient data, where the development of the DemographicData Exchange (DDE) mediator is a step towards enabling patient information shar-ing. Additionally, developing the facility register FR provides an overview of facili-ties, and its services are available through a single web user interface. Consequently,improved information flow allows managers to make evidence-based decisions, in-cluding strategic planning and resource monitoring.

At the facility and patient level, our empirical evidence proved that at a desktop inte-gration of the outpatient diagnosis module and Picture Archiving CommunicationSystem (PACS) eased the workflow of health workers. The IMPAX (PACS) Con-text Server facilitated a bi-directional communication, between outpatient diagnosismodule and PACS. Obtaining functionalities from PACS to the outpatient diagnosismodule were achieved by creating scripts. Consequently, desktop integration al-lows patient information to be shared between the Electronic Medical Record (EMR)system and PACS, supporting patient care.

6.3.2 Improved Infrastructure Management and Development Pipeline

In the process of building the Open Health Information Exchange (OpenHIE) archi-tecture, informants at Kuunika shed light on the use of industry-known infrastruc-ture technologies to reduce bottlenecks and improve their development pipeline.The system administrator state that with the use of virtual machines and containers,development and testing become easier, because the spawning time is short com-pared to physical servers. This shows that industry-known infrastructure technolo-gies such as Docker and Jenkins enable him to do continuous integration and devel-opment. This is particularly appropriate in a large project with developers workingon the same tasks. The system administrator also shed light on DevOps, a conceptwhere a developer also does operations tasks. He adds that the value with DevOpsis recognizable and can be beneficial for development projects.

6.3. The Integration Effect 59

In summation, the findings regarding the current two integration approaches ofhealth information systems enable information sharing between systems. Develop-ing the Open Helath Information Mediator (OpenHIM) enable information systemsto request data to be migrated into DHIS2. Also, developing infrastructure servicessuch as a facility register provides an overview of facilities in the country via a webuser interface. These actions are a step in the direction of making information avail-able and accessible for those who need it. At the facility and patient level, our empir-ical evidence also showed that desktop integration decreases the added workload ofhealth workers, having to use several systems because they cannot share informa-tion. Table 6.1 summarizes all the findings in our study.

The next chapter discusses these findings with the related literature to be able toanswer the research questions.


6.4 Summary

6.4. Summary 61

Themes Topic and Summary

Integration Approachesto Health InformationSystems

National LevelAt this level, the integration approach wasdeveloping an interoperability layer (OpenHIM)was an approach to integration and interoperabilitybetween health information systems.

Facility and Patient LevelAt this level, the integration approach wasa desktop integration between nationalEMR and PACS.

Technical Challengeswith Integration

Language Barrier for Health Information Systems

The lack of an agreed-upon messaging standard hindersdata exchange between health information systemsNetwork Connectivity

Inadequate and poor network connectivity can affectdata exchange between health information systemsPoor Management of Infrastructure and Network

Poor management of systems and servers can affect theintegration of health information systems, especiallywith the interoperability layer as an approach.Lack of a Strategy for Preserving Information Security

The lack of a strategy to ensure security of information,systems and network can affect integration of healthinformation systems.

The IntegrationEffect

Better Information Flow in the Health System

Information becomes available andaccessible for those who are authorized to see it.In addition, integration of health information systemsalso eases the workload of health workers.Improved Development Pipeline

The use of infrastructure technologies could ease thedevelopment of the interoperability layer and reduce bottlenecks.

TABLE 6.1: Overview of findings

63

Chapter 7

Discussion

The purpose of this chapter is to review the related literature and the empirical find-ings to build a foundation to answer the research questions. The objective of thisstudy is to understand the the integration of Health Information Systems (HIS).

The central topics we will discuss in this chapter is related to the integration ap-proaches, standards, infrastructure and network, and information security. Again,our research questions are:

1. How is the integration of Health Information Systems (HIS) conducted at thenational and local level?

2. What technical challenges affect the integration of Health Information Systems(HIS)?

3. What is the outcome of these integration types?

7.1 Integration Approaches to Health Information Systems

This section discusses the first research question:R1: How is the integration of Health Information Systems (HIS) conducted at thenational and local level?

We identified two approaches of integrating Health Information Systems (HIS), whichare further discussed in this section.

7.1.1 Integration at National Level

At the national level of the health system, the integration of Health InformationSystems (HIS) is achieved by adapting to theOpen Health Information Exchange(OpenHIE) architecture. The architecture consists of the Health Information Medi-ator (HIM) or the interoperability layer and the OpenHIE component layer or in-frastructure. External systems can connect to the interoperability layer to exchangeinformation with other systems. The infrastructure services enable interoperabilitybetween systems, as mentioned in section 3.4. Several researchers have also sug-gested the OpenHIE architecture for sharing information between HIS (Crichtonet al., 2013; Dlodlo and Hamunyela, 2017; Wolmarans et al., 2014). Therefore, theteam at Kuunika adopts to the OpenHIE architecture framework and develops the

64 Chapter 7. Discussion

interoperability layer and infrastructure services to support the sharing of informa-tion between disparate health information systems in Malawi.

The interoperability layer uses a messaging standard calledFast Healthcare Interop-erability Resources (FHIR), to support the exchange of health data, as mentioned insection 3.5. This indicates that any external systems must adhere to FHIR upon con-necting to the interoperability layer. Within the interoperability layer, the team hasdeveloped mediators to perform data and message translation, validation and au-thentication of data before migrating to national core systems. These functionalitiessupport the ability to exchange health data. The OpenHIE architecture frameworkfocuses on scalability, as the interoperability acts as an intermediary for systems toconnect and exchange health data, instead of integration between two systems. Thisintegration approach found at the national level indicates that the purpose of in-tegration in Malawi are viewed with a lens where health data is exchanged acrosshealth information systems.

The study by Crichton et al. (2013), also showed that health information mediatorwas developed to facilitate information sharing between disparate information sys-tems and applications. Crichton et al. (2013) identified Rwanda as one of the low-income countries in Africa who also suffers from fragmented applications and ap-plications are built to serve specific needs, as mentioned in section 3.6. To handlewith these issues, they point out that implementing a mediator component can fa-cilitate information sharing between participating health information systems andapplications in the national HIS. In 2012, Rwanda’s health information mediator wasimplemented and deployed together with the infrastructure services. Following thedevelopers Rwanda health information exchange blog, showed that the deploymentof the solution was not straightforward. With consequences considered, it still in-spired other countries. Crichton et al. (2013) argued that the OpenHIE architecture is"a solution to the major problems faced when attempting to facilitate interoperabilitybetween many disparate HIS". The solution showed that it is appropriate, adaptableand has the potential to scale. In addition, The Tanzanian MoH also suggested asimilar solution, where an health information mediator acts as a middleware com-ponent facilitating information sharing between external information systems in thenational HIS Mzeru and Mwendo Hamis (2019). National e-health strategic plans inKenya and Uganda also indicate that a national Health Information Exchange (HIE)architecture is an integration approach suitabl for the countries (Republic of Kenya,2016; Republic of Uganda, 2017).

When it comes to the integration of information systems, our empirical evidencesignified that the solution in Malawi relies on the FHIR standard. Moreover, the in-teroperability layer would then facilitate data exchange. While, in Rwanda’s casestudy, the researchers state their HIM architecture uses a normalization and de-normalization transformation defined to allow any data format to be transformedinto and out of a format that the HIM understands. They argue this decision willensure syntactic interoperability and making the architecture flexible to multipledomains within the health sector, as no standard will be sufficient for all messag-ing needs. In a study by Sæbø et al. (2011) they state that standards must be agreedupon in order to achieve health information systems integration. In Malawi, MoH


mandated all e-health implementers to develop and deploy information systems tobe compliant with the HL7 messaging standard Mwakilama et al. (2014)( p. 6).

7.1.2 Integration at Facility and Patient Level

In the literature, Boochever (2003) refers to desktop integration as an approach forintegrating health information systems, specifically integration between RadiologyInformation System (RIS) and Picture Archiving Communication System (PACS).Our empirical evidence showed that desktop integration is a way to integrate appli-cations with no back-end connectivity. This approach was present at the facility andpatient level. In particular, the findings show a desktop integration between the na-tional Electronic Medical Record (EMR) and PACS. Based on the integration guide,the context server serves as a mediator component where it handles all requests fromIMPAX clients. Applications must be registered to the context server and after thatcan communicate with the context server via its interfaces. Scripts can be created todictate studies. The context server facilitates information sharing between applica-tions. However, the approach does not scale well, as it only considers applicationswith no back-end connectivity. Additionally, Boochever (2003) does not address thescalability of this approach. Instead, Boochever (2003) focuses on the bi-directionalcommunication between IMPAX client and third-party applications. The researcheralso focuses on how the approach supports simple workflows. We argue that thecontext server does not have the capabilities to facilitate information sharing in thesame manner as the interoperability layer, as the approach is a silo integration. Here,a silo integration refers to the ability to only integrate one application with another.

Through observations, we raised a question to why the landscape of integrated in-formation systems at Mzuzu Central Hospital was so narrow (see Figure 6.2). Oneof the senior software developers stated that donor organizations and aid-agenciesfund most of the information systems. Donors want specific information systemsto monitor diseases and health trends. Further, information systems are then devel-oped and implemented by various vendors to monitor specific-disease programmes.The health system still are dependent on funding, implying that when donors do notsee the need for integration, there will not be any incentive for it either. A study byTweya et al. (2016) argued that an increase in patients with co-infected HIV and TB(tuberculosis) in sub-Saharan Africa led to an integration of the health services, HIVand TB. A national EMR system with ART module already exists in over 140 sitesin Malawi, so patient with HIV are recorded in the EMR system, while the samepatient with TB or suspected TB suspect is recorded in paper registers. The increaseof co-infected patient led to the development of an ART-TB module in the nationalEMR system in some clinics in the capital Lilongwe. Therefore, the informants’ argu-ment is valid, as the study by Tweya et al. (2016) illustrated that increase in diseasesor a linkage between conditions is a valid rationale to integrate health informationsystems or modules.


7.2 Technical Challenges with Integration

This section discusses the second research question:RQ2: What technical challenges affect the integration of?

Our empirical evidence identified four challenges for integration of Health Informa-tion Systems (HIS), as mentioned in Chapter 6. From the findings, we found that themain challenges for integration of Health Information Systems (HIS) are perceivedas technical. These will be discussed further.

7.2.1 Language Barrier for Health Information Systems

On all levels of the health system, integration of Health Information Systems (HIS)is challenging, regardless of the integration method. A study by Mwakilama et al.(2014) argued that achieving integration and interoperability require standards. Specif-ically, standards on architecture, data dictionary, messaging standards, security, net-work and infrastructure. A MEASURE evaluation of HIS interoperability readi-ness in Uganda (2018) indicates a lack of defined technical standards for HIS dataexchange leads to full autonomy for application providers (MEASUREEvaluation,2018). In a similar notion with Mwakilama et al. (2014), Adebesin et al. (2013) arguethat standards are the key enabler for the seamless exchange of health information.

In the following sections, we highlight that the lack of an agreed-upon messagingstandard and the ability to map clinical terminologies and codes perceive as chal-lenges for integration and interoperability.

Messaging Standards

The literature and our empirical evidence provide insights on how to solve this lan-guage barrier. For example, mandating all implementers of health solutions to becompliant with the HL7 messaging standard was a strategy from the MoH in Malawi(Mwakilama et al., 2014). This makes integration easier as there is an agreed-uponstandard for the exchange of health data. However, mandating all external systemsto use a specific standard could also make the integration of systems slow-moving asit requires work for the implementers of systems. Another strategy is through the in-teroperability layer. Here, we consider two cases. The study by Crichton et al. (2013)showed that the interoperability layer in Rwanda had mechanisms to perform thetranslation of messaging standards. They argued that there was a lack of a standardto ensure all messaging needs. On the other hand, our empirical evidence showedthat the interoperability layer in Malawi mandates all external systems to use themessaging standard FHIR. The developers argue that FHIR is the most prominentmessaging standard on the market, and there are a lot of resources available. Com-paring the two cases, we interpret that the Malawian interoperability layer ensuresscalability, as Crichton et al. (2013)’s strategy requires more work for the developers.The software architect also argued that it would not be sufficient to do the transla-tion of standards when there is a considerable number of external systems that wantto connect to the interoperability layer.


Data Dictionary

The objective of integrating Health Information Systems (HIS) is also for shared in-formation to be meaningful between and across systems, ensuring semantic inter-operability. Here, the language barrier between systems also creates a challengefor integration. HIS uses different codes and have different ways to classify medi-cal terminologies. Consider that we want to achieve semantic interoperability, thenthere must be a strategy to organize clinical terminologies and codes in a way thatis meaningful for all. The lack of ensuring that clinical terminologies and codes ismeaningful could lead to fatal consequences affecting the patients.

The literature on terminologies and coding indicate that semantic interoperability isachieved by mapping terminologies and codes. Our empirical findings show thatmapping of clinical terminologies across information systems can be achieved witha terminology service (TS). The team at Kuunika decided to use the national EMRsystem as a use-case for the terminology service, as the system already had a conceptdictionary. Hicken et al. (2004) that integration becomes challenging and raises dataquality problems when there is a lack of a shared data dictionary. Further, the teamat Kuunika plans on mapping the concepts in the EMR system with ICD-10 codes,which is a medical classification list by WHO. There have been previous mappingattempts by the MoH, but there were no use-cases, and they did not fully succeed.However, the team can retrieve some of the mappings done by MoH and use themas reference. Furthermore, a system called Open Concept Lab (OCL) can be used topush the concepts into the source cloud-based platform for collaborative terminol-ogy management Lab (2017). OCL allows the user to access standardized sourcesof concepts like LOINC, SNOMED, ICD-10, and map concepts. OCL illustrates themapping with an example, where "Ebola" is the concept, and code like A98.4 is theidentifier for Ebola in ICD-10 WHO, which means that we can map the concept ofEbola as following: WHO: ICD-10: A98.4 "Ebola virus disease" Lab (2016).

In the interviews, the software architect also reflects on the technology choice for themapping of clinical terminologies. The team decide to use OCL as it is free, but thedrawback is that one cannot hide the concepts as the software is open-source. An-other disadvantage of using OCL is that it is online-only, meaning network connec-tivity is a prerequisite. As mentioned in Chapter 6, the country struggles with poornetwork connectivity, which is arguably a disadvantage of using OCL in this con-text. In the study by Crichton et al. (2013), they went for Apelon DTS, another open-source terminology system providing somewhat the same functionalities. However,Apelon DTS has some paid versions. Hence, the choice was OCL for Malawi. Insummation, our empirical evidence implies that problems with ensuring semanticinteroperability between and across information systems are solvable using suchsystems to support the mapping of medical terminologies.

Our technical documents on the integration of national EMR and PACS did not pro-vide information on medical translation and mapping. However, the purpose ofintegrating these two systems was to be able to request orders and view medicalimages through the outpatient diagnosis module. Consequently, placing radiologyorder and viewing medical image does not contain medical terms. Upon radiologyorder, the health worker selects the area of the body that they wish to take an X-ray.


When the results are back, the health worker can choose an order if there were sev-eral and view the selected results. From our observation and documents, we foundout that there is no particular translation and mapping needed, as medical termi-nologies are not present.

7.2.2 Network Connectivity

Empirical evidence shows that inadequate infrastructure and inconsistent connec-tivity creates a challenge for integration, as mentioned in 3.2. Juma et al. (2012)argue there is a lack of strategy of getting connectivity to "the last mile," meaningleveraging its capacity to the end. In a study by Kiberu et al. (2017), the researchersstated that power blackouts and weak internet connectivity hinders e-Health inno-vations. Therefore, any integration approach must consider this. In regards to theinteroperability layer, a solution for handling poor internet connectivity during datamigration is to have a proxy interoperability layer at remote facilities to enable syn-chronization with the centralized version to harmonize the shared information. Thisis also referred to as a centralized model of Health Information Exchange (HIE), asmentioned in section 3.4.3. This ensures that a local version of the infrastructureservices at the remote facility sites is available. Then whenever the connectivity isfunctional again, information can be synchronized with the centralized version. Asmentioned in Chapter 6, the ADX mediator in the interoperability layer has mech-anisms to detect failed migrations. The failed migrations are shown in the execu-tive summary sent by e-mail to clients (external systems). This mechanism enablesclients to be aware of the possibility of poor or lost connectivity during migration, asit is shown in summary. These mechanisms within the interoperability layer ensureto the extent that integration could be achieved in the environment of inconsistentnetwork connectivity.

7.2.3 Poor Management of Infrastructure and Network

At Kuunika, the development site of the OpenHIM, it was observed that the team fo-cuses a lot on managing the infrastructure and network. The consultant team gainedvaluable lessons from the experience. The system administrator informed that theyhave physical servers in the infrastructure. These servers take up resources, so therewas an attempt to virtually host them but it led to memory leaks. The role of a sys-tem administrator is to manage the infrastructure and make sure that all systems andservers are up and running, as mentioned in section 3.9. Therefore, they leveragedthe use of virtual machines and containers as much as possible because these spawnup quicker than physical servers. Infrastructure technologies such as Docker andJenkins were also used because it uses fewer resources than virtual machines andphysical servers. Consequently, containers gave value to the system administratoras it was easy to spawn up and takedown. For example, our observations showedthat containers were used for a DHIS2 testbed. The emergence of infrastructuretechnologies seemed to also add value for the developers, where the infrastructurewas easy to manage and could improve the software development lifecycle. How-ever, the current literature does not shed light on the effects of using infrastructuretechnologies in the development of the interoperability layer. Therefore, it becomesdifficult to argue whether these technologies have an impact on the development of


the interoperability layer.

As mentioned in section 3.7, a focus on the security of network prevents one fromthe exploitation of vulnerabilities and threats. Network segmentation, firewall, an-tivirus and antimalware software installed on desktops and access control was someof the security measurements found at the development site of the interoperabilitylayer. A firewall enables control of incoming and outgoing traffic in the network.The firewall can be configured with accepting all traffic and have drop rules forspecific traffic or vice versa. Through our observations, we interpret that the con-figuration of the firewall at Kuunika was by default drop rules and accept rules forspecific traffic. Network segmentation is considered another method to prevent thenetwork from attacks. The system administrator also plans on using Virtual PrivateNetwork (VPN) and Secure Socket Shell (SSH) for an encrypted connection, whichis also useful for protecting information during transmission, as mentioned in sec-tion 3.7. This is advisable with regards to protection from attacks and unauthorizedaccess to health data and information.

7.2.4 Lack of a Strategy for Preserving Information Security

Braa and Sahay (2012) argued that integration should have an enterprise perspec-tive, meaning that managers and health service providers should define the needfor integration. Here, we interpret that the need for integration was raised becausedisparate health information systems do not have the ability to exchange data. Theteam at Kuunika confirms that mediators in the OpenHIM and infrastructure ser-vices have yet to be developed. Additionally, the team also have to establish astrategy for preserving information security in the proposed solution for integration.Concerns related to information security was emphasized by the software architectand the system administrator. They stated that the interoperability layer has to havemechanisms to authenticate and authorize who should be able to grant access to thedata. Establishing a strategy where information security is preserved is important.Firstly, it means that the solution has an enterprise perspective where data exchangeis a central functionality. Secondly, having the availability of data for the authorizedentities.

In a study by Crichton et al. (2013), it was apparent that one of the components oftheir OpenHIM had mechanisms to ensure the integrity of the data and control theaccess from unauthorized parties. Additionally, national strategy policy documentsalso signify that e-health solutions should ensure preserving of information securityregarding health information (Republic of Kenya, 2016; Republic of Uganda, 2017).Consequently, this means that a lack of strategy for preserving information securityhinder the purpose of integration of disparate health information systems. Further-more it can become a dangerous aspect in the future.


7.3 The Integration Effect

This section discusses the final research question:R3: What is the outcome of these integration types?

7.3.1 Information Flow in the Health System

Consider as one of the most valuable outcomes of the interoperability layer is theability for information to flow between levels of the health system. This flow of in-formation is useful for strategic planning and resource monitoring, in other wordsevidence-based decision-making.

The integration between national Electronic Medical Record (EMR) system and Pic-ture Archiving Communication System (PACS) has decrease the workload of healthworkers, which our observations can confirm. In a study by Dlodlo and Hamunyela(2017), they confirm that lack of integration causes additional workload for healthworkers. In the outpatient diagnosis module, anyone that is authorized can place ra-diology order and view the results, instead of having to use two systems in parallelto achieve the same task. The outcome of this integration method is for informationto asset patient care and facility management, planning and drug procurement.

The empirical findings seem promising compared to other countries. Both inte-gration processes are a step towards ensuring information sharing and informa-tion availability. However, the process of integration between national EMR andPACS has its limitations in terms of scale compared to the interoperability layer. Inthe Open Health Information Exchange (OpenHIE) architecture, the interoperabilitylayer facilitates external systems to migrate data into other systems. In our case, thedevelopers at Kuunika decided to use a messaging standard, FHIR, which all exter-nal systems must adhere. This allows them to avoid standard translation for eachinformation systems that want to connect to the interoperability layer, ensures scal-ability of the architecture. While an integration process similar to the one desktopintegration between national EMR and PACS requires customization, resulting in anincrease of workload for those responsible for integration when more systems haveto be integrated.

Moreover, the work of mapping medical terminologies and codes (terminology ser-vice) seem to be a crucial preparatory work for the phase of developing a SharedHealth Record (SHR), a step in the direction of achieving a national informationsharing framework.

Other national strategy plans show that countries like Uganda and Kenya are in thesame process of developing a national HIE architecture. Kenya stresses the need tobuild client registry and terminology service, to achieve interoperability. In the samenotion, South Africa also developed a Health Patient Registration System (HPRS) toprovide a patient registry in their adopted OpenHIE architecture. This architectureis named e-Health Interoperability Health Normative Standard Framework. WhileUganda is in the process of defining standards and create interoperability guidingdocuments. Comparing to these countries, Malawi is at the forefront of developing

7.3. The Integration Effect 71

and implementing a national HIE architecture that enables interoperability betweenHIS, compared to the mentioned countries.

7.3.2 Improved Infrastructure Management and Development Pipeline

Through interviews and documents, we understand that integration via the inter-operability layer is a comprehensive process with interconnected tasks and infor-mation flows to take in consideration. As the process is immense, it was illustratedthat infrastructure technologies support the management of the infrastructure. Thepresence of the system administrator led to better management of the infrastructure.For instance, virtual servers and containers were preferable over physical servers,as the spawning time is shorter and they are more flexible. Furthermore, infrastruc-ture technologies as automation server (Jenkins) ensure Continuous Integration andDelivery (CI/CD). This implies that the team has taken the scale of this project intoconsideration.

Going back to the immense landscape of the interoperability layer project, it wasalso illustrated that the team developing the interoperability layer follows an iter-ative model, where developing Minimum Viable Product (MVP), appreciate userfeedback and rewind seems like their preferred method. This way of working iscomparable with the Lean Startup mentality, where validated learning is highly val-ued Ries (2011).


7.4 Limitations of the Study

This section presents the limitations of this study. One has to take into considerationthat the data collection time was limited, as the study was initially to be carriedout in a different context. We assume other findings could occur if the study wereconducted at other times.

7.4.1 Interviews

The interview at Luke International was short, and there was little time to get toknow one another. A possible lack of trust could affect the validity of the response.The interviews with the team at Kuunika provided extensive information. In retro-spect, more interviews should be held as we only interviewed key team members.Also, the data collection period should be extended to gain more information onhow the team decide on solving patient data exchange.

Some questions felt leading at times. However, the knowledge gained from the pre-vious interviews, significantly improved the precision of the later interviews. Infor-mal conversations were a significant element to increase validity.

7.4.2 Observations

The observation took place at one site. In hindsight, observations should be carriedout at several locations to increase validity and more findings.

7.4.3 Research Context

The original case study protocol was intended for South Africa, as that was the ini-tial research context. Due to ethical clearance delayed in eight months, we decidedto choose Malawi as the research context for this study. Both countries are facingthe same issues with disparate health information systems, putting them in a posi-tion where information cannot be shared between and across information systems.Following Yin (2014), well-defined research questions increase external validity. Inour case, the research questions were not limited to one country. Additionally, anopen-ended interview guide allowed us to collect evidence regarding the integra-tion processes of HIS, without limiting to one country. However, unfortunate ethicalclearance delays limited the time to investigate the phenomenon deeply.

In Malawi, we had to reach out to our contacts to help us facilitate sites for data col-lection. Before collection our data, we spent much time reading through documentsand reports to asses and strategies to improve the health system. A complete under-standing of every aspect of the health system in Malawi is not present, as the natureof is of many interconnected actors. To increase the validity of our data, interviews,observation notes, technical documents, reports and strategic plans where used toget a comprehensive understanding of the research context.

7.5. Summary 73

7.4.4 Construct Validity

Following Yin (2014)’s three tests to increase validity, we used to use multiple sourcesof evidence: interviews, documents and observations.

7.4.5 External Validity

The research questions defined are not limited to a research context, therefore; ageneralization is possible. For example, asking the same research questions for low-income countries in Africa.

7.4.6 Reliability

To increase the reliability of the study, we follow Yin (2014)’s advice following thecase study procedure. The descriptions were detailed enough for us to follow.

7.5 Summary

This chapter discussed the two integration approaches found in our research site,Malawi. Further, we discussed the advantages and disadvantages of both approaches.Specifically, we identified technical and organizational challenges regarding the in-tegration process. Further, we discuss the outcomes of the integration process foundin Malawi. A section was also dedicated to reflecting on the limitations of our study.

The next chapter concludes our findings and discussions. We also propose somefuture work.

75

Chapter 8

Conclusion and Future Work

The objective of this study was to understand integration of Health Information Sys-tems (HIS). The research method, design and data collection methods used are ex-plained in Chapter 4. The findings of the study and further discussion are presentedin Chapter 6 and Chapter 7. This chapter provides a conclusion of our research, andwe pose some future work.

The first research question identified the integration of Health Information Systems(HIS) is present at two levels: national and facility and patient level. In line withthe study by Crichton et al. (2013), integration and interoperability were achievedwith the Open Health Information Exchange (OpenHIE) architecture. The interop-erability layer acts as an intermediary between external systems and the OpenHIEcomponents layer, which also called the infrastructure services. Empirical evidenceshowed that the Open Helath Information Mediator (OpenHIM) allow external sys-tems to connect by adhering to a common messaging standard, Fast Healthcare In-teroperability Resources (FHIR). The OpenHIE components is key to informationsharing between systems, as they provide a common language for systems to usewhen referring to the same things.

The OpenHIE architecture facilitate the sharing of aggregate data and patient data.Particularly, all systems must use the FHIR standard to be able to connect to theOpenHIM. Furthermore, the aggregate data exchange (ADX) mediator handles themigration process of aggregate data. The demographic data exchange (DDE) media-tor handles patient data to a certain degree by issuing unique patient identifiers anddetecting duplicate patient data record. In addition, the terminology service (TS)is one of the infrastructure services in the OpenHIE component layer that managepatient data. Furthermore, mapping medical terminology and codes are crucial foran patient electronic health record (SHR).

At the facility and patient level, desktop integration was illuminated. A desktopintegration makes use of a context server, acting as a mediator to integrate IMPAXclient with third-party applications. The context server manages requests and dicta-tions from the IMPAX client. Scripts can be created to establish communication withthe context server before dictating any functions from the IMPAX client (e.g. displayimage), which was not discussed in (Boochever, 2003). Notably, we observed that thedesktop integration was between outpatient diagnosis module (national ElectronicMedical Record (EMR)) and Picture Archiving Communication System (PACS) atone central hospital. The outcome of desktop integration enables medical images to

76 Chapter 8. Conclusion and Future Work

be included in a patient’s medical record. Therefore, we conclude that desktop inte-gration facilitated the exchange of patient data. However, this integration approachis restricted to client applications communication without back-end servers. More-over, we draw similarities to silo integration because the context server can onlyintegrate two or three applications, which eliminates scalability.

Our empirical evidence showed that the ADX mediator handles aggregate data andthe DDE mediator deals with patient data. Calls to the terminology service (TS) alsoserve patient information sharing, while, in Crichton et al. (2013) study, no specificmediators were built to handle aggregate and patient data. Instead, Crichton et al.(2013) built a general OpenHIM to do standard-translation and uses infrastructureservices to translate the request into a format that service providers understand. Thismeans that Crichton et al. (2013), OpenHIM have mechanism for the translation ofall standards for external systems, making on-boarding to the OpenHIM easy. In thecase of Malawi, the OpenHIM mandated external systems to adhere to their stan-dard for data exchange. This means that external systems at facility level have toadapt to the FHIR standard by programming accordingly. Both OpenHIM solutionsconsider the prospect of scalability.

Crichton et al. (2013) argues an emphasize on translation of standards, implying aneasy on-boarding for external systems. However, the consequence of this argumentare heavier workload on the developers side. As the empirical evidence suggest, theOpenHIM in Malawi focuses on the FHIR standard implying that external systemshas to adapt to the new standard. Furthermore, this can affect the data exchange inregards to delays as adapting to the new standard takes time.

The empirical evidence also showed that the development of the OpenHIE architec-ture and infrastructure technologies can be used to provide continuous integrationand delivery. Furthermore, it can also reduces bottlenecks as infrastructure tech-nologies multiple instances. This finding is a theoretical contribution on integrationliterature.

The second research question discussed the technical challenges with the two iden-tified approaches of Health Information Systems (HIS) integration in Malawi. Inboth cases, we interpret that different standards for exchange of data are recognizedas an obstacle for integration. Information systems are generally developed and im-plemented by various vendors providing information to health programmes. Thesesystems are designed in different programming languages and run on different op-erating systems posing challenges for the exchange. When information systems donot use the same standard for exchange, no communication between the systemsis implied. This finding was viewed differently by (Crichton et al., 2013). The re-searchers argued that there was no messaging standard on the market that wouldcover all message needs. Therefore, their OpenHIM included standard translationfor requests from external system, implying a less scalable solution. Whereas, ourempirical evidence, rationalized that scalability was taken into consideration, andthus chose not to translate standards. Instead, all external systems must do standardtranslation to Fast Healthcare Interoperability Resources (FHIR), upon connecting tothe OpenHIM.

Chapter 8. Conclusion and Future Work 77

In regard to standards, Mwakilama et al. (2014) argued that agreed-upon standardsabout architecture, data dictionary, security, messaging standards, and networks andinfrastructure is required to achieve integration and interoperability. Our empiricalstudy shows that the terminology service (TS) provides a list with the mappingsof terminologies and codes used in various systems. Since the terminology serviceuses the Open Concept Lab (OCL) system, the concepts will be available to all. Thisaligns with Mwakilama et al. (2014)’s argument where a set of standardized clinicalconcepts enable sharing of data or information and prevent medical errors. We alsodiscovered that mapping clinical terminologies and codes, increase semantic inter-operability, as clinical terminologies and codes is interpretive by all systems. Thefindings presents that the OpenHIM forces the FHIR standard on all informationsystems that want to connect to it, enabling syntactic and semantic interoperability.While, at the facility and patient level, it was not clear that a universally agreed uponstandard must be established, even though in the same study by Mwakilama et al.(2014) it was noted that Ministry of Health (MoH) mandated that health systemsimplementers in Malawi had to be compliant to the HL7 messaging standard. How-ever, the researchers did not specify what version of HL7 messaging standard.

Documents and interviews show that preserving information privacy is importantfor the development of the shared health record (SHR). Policies, documents andmechanisms should be developed for persevering privacy and data governance.This was also highlighted in Wolmarans et al. (2014). Other countries also plan toestablish strategic plans to ensure confidentiality, integrity and availability of healthdata and information (Republic of Kenya, 2016; Republic of Uganda, 2017). As ofright now, in Malawi, information security and privacy are in the initial develop-ment stages.

Network and infrastructure weaknesses creates a challenge for integration and in-teroperability. Weak network connectivity affects the integration process, becausedata exchange requires internet connectivity. Through informal conversations wefound that several districts were supported by partners with hardware equipmentand data bundle for internet connectivity. Additionally, the Ministry of Health planon expanding the Wide Area Network (WAN) to decrease weak network connec-tivity in the country. Our findings suggest that external systems struggles with datamigration into national core systems as an implication of weak network connectivity.

To summarize the aspect of standards to achieve integration and interoperability, weidentified that these standards were used in Malawi. Table 8.1 illustrates the stan-dards that were prevalent in our empirical evidence. An agreed-upon minimumindicator set for the country enables organizational and semantic interoperability.FHIR was the messaging standard for the interoperability layer, achieving technical,syntactic and semantic interoperability. The DICOM standard for medical imageswas used with PACS at the central hospital. The primary standards for clinical ter-minologies and codes were prominent ICD-10 and LOINC – mapping these willenable semantic interoperability. Similar to Mwakilama et al. (2014) discovered thata national unique identifier would also enable semantic interoperability.

Comparing this table to the table from Adebesin et al. (2013), our evidence showed

78 Chapter 8. Conclusion and Future Work

that standards like Fast Healthcare Interoperability Resources (FHIR) and Interna-tional Classification of Diseases (ICD-10) are the newly emerged standards withinhealth, achieving interoperability. Adebesin et al. (2013) presents a review of inter-operability standards but does not highlight that a national minimum set of indica-tors could achieve interoperability, as our empirical evidence pointed out. DigitalImaging and Communications in Medicine (DICOM) is the standard that is presentin our evidence and in Adebesin et al. (2013)’s paper. Further, Adebesin et al. (2013)also include standards like HL7 v2, v3 and CDA in their table of interoperabilitystandards. Our empirical evidence on integration of HIS at the national and facilityand patient level did not address these standards. However, Mwakilama et al. (2014)had stated that MoH had mandated that all health systems implementer should becompliant with the HL7 messaging standard (p.6). This could mean that the sys-tems in Malawi still uses HL7 standards for messaging, but it was not prevalent inour data collection.

Standards and Interoperability Level MappingStandard Technical Syntactic Semantic Organizational

International StandardsNational Minimum Set X X

Information ExchangeFHIR X X X

DICOM X XClinical Terminologies and Coding

ICD-10 X XLOINC X X

TABLE 8.1: Standards and Interoperability level mapping

The third research question discussed the outcomes of the integration types. Weargued that information availability is a positive outcome of integrating health in-formation systems. Integrating disparate HIS enables information to flow betweenthe health system levels and become available for those who need it, enabling se-mantic and organizational interoperability. The study discovered that the integra-tion approaches that was found have the potential to facilitate information sharingand direct the health system in Malawi to achieve Universal Health Coverage.

Our empirical evidence shows that the use of newer infrastructure technologies (e.g.virtual machine, containers, automation server and version control systems) in thedevelopment of the OpenHIE architecture could improve the development pipelineand ensure prominent improvement of management in the infrastructure. This find-ing has not been emphasized in the literature.

This study was seen from a technical perspective, an attempt to fill the gap in theintegration of Health Information Systems (HIS) in the existing literature. The studytakes into account that integration is important and necessary to share informationbetween and across information systems. This enables semantically more usefulinformation and is a step towards achieving Universal Health Coverage.

8.1. Implications for Practice 79

8.1 Implications for Practice

The research literature and our evidence show that adopting an Open Health In-formation Exchange (OpenHIE) architecture is a promising framework for integra-tion and interoperability. The literature states there is a need for integration andargues it can enable information sharing between disparate health information sys-tems. Malawi and other countries in sub-Saharan Africa have adopted the OpenHIEframework architecture. With regards to scalability, this framework enables manyinformation systems to share information rather than two systems that share infor-mation with the desktop integration method. As long as all external systems agree toadhere to the data exchange standards of the interoperability layer, the first step to-wards information sharing is actioned. The empirical evidence shows that Malawi isadvancing in the development of the component layer and the interoperability layercompared to other countries, such as Kenya and Uganda.

Adopting a framework architecture like OpenHIE requires a national effort andaligning goals and objectives with various parties and stakeholders. In terms ofthat, using infrastructure to manage the IT infrastructure, preserving informationsecurity and agreed-upon messaging standards, structure and content, and clinicalterminologies is perceived as central for information sharing. Additionally, the LeanStartup mentality that the team at Kuunika holds, also adds to the successful de-velopment of other services and mediators (facility registry, and the ADX and DDEmediators).

For further development of the interoperability layer, using infrastructure technolo-gies could improve the software development lifecycle. Infrastructure technologiessuch as Docker containers, version control with Git, and automation with Jenkinsmake the infrastructure easy to manage and could advance Malawi’s technical posi-tion in terms of the development of an information sharing framework (OpenHIM).Additionally, a focus on security, in terms of establishing a disaster recovery planand strategies for infrastructure, hardware, software and data. This is discussed insection 3.7. This refers to having a predefined plan and strategy for solving un-planned occurring events.

For future work, in-depth investigation in the development and deployment of theinteroperability layer would be interesting and contributable for other countriesaiming for the same approach. Since the interoperability layer plays a crucial partin facilitating information sharing, more attention to security aspects is consideredvital. Also, a greater focus on the use of infrastructure technologies and its capa-bilities to support the development of the interoperability layer could provide newperspectives.

81

Bibliography

Adebesin, F., Foster, R., Kotzé, P., and van Greunen, D. (2013). A review of interop-erability standards in e-health and imperatives for their adoption in africa. SouthAfrican Computer Journal, 50:55–72.

Ahmadian, L., Dorosti, N., Khajouei, R., and Hajesmaeel Gohari, S. (2017). Chal-lenges of using hospital information systems by nurses: comparing academic andnon-academic hospitals. Electronic Physician, 9:4625–4630.

Andress, J. (2011). The Basics of Information Security: Understanding the Fundamentalsof InfoSec in Theory and Practice, volume 4 of 10. Elsevier Science, New York, 6th ededition.

Ansible, R. (2019). Use case of configuration management? Retrieved from: https://www.ansible.com/use-cases/configuration-management.

Aspden, P., Corrigan, J. M., Wolcott, J., and Erickson, S. M. (2004). Patient Safety:Achieving a New Standard for Care. The National Academies Press, Washington,DC.

Boochever, S. (2003). His/ris/pacs integration: getting to the gold standard. Radiol-ogy management, 26:16–24; quiz 25.

Boone, K. W. (2011). The cda tm book.

Braa, J., Heywood, A., and Sahay, S. (2012). Improving quality and use of datathrough data-use workshops:. zanzibar, united republic of tanzania. Bulletin of theWorld Health Organization, 90:379–84.

Braa, J. and Sahay, S. (2012). Integrated Health Information Architecture: Power to theUsers. Matrix Publ, New Dehli.

Carine, F. and Parrent, N. (1999). Improving patient identification data on the patientmaster index. Health Information Management, 29(1):14–17.

Chilundo, B. and Aanestad, M. (2004). Integrating the information systems ofdisease-specific health programmes: Negotiating multiple rationalities. EJISDC,20:1–28.

Cisco (2018). What is information security? Retrieved from: https://www.cisco.com/c/en/us/products/security/what-is-information-security-infosec.html.

Commision, E. (2019). What personal data is considered sensitive? Retrievedfrom: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/legal-grounds-processing-data/sensitive-data/what-personal-data-considered-sensitive_en.

https://www.ansible.com/use-cases/configuration-management

https://www.ansible.com/use-cases/configuration-management

https://www.cisco.com/c/en/us/products/security/what-is-information-security-infosec.html



https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/legal-grounds-processing-data/sensitive-data/what-personal-data-considered-sensitive_en



82 BIBLIOGRAPHY

Creswell, J. W. (2007). QUALITATIVE INQUIRY & RESEARCH DESIGN ChoosingAmong Five Approaches, volume 4 of 10. Sage, Thousand Oaks, California, 2nd ededition.

Crichton, R., Moodley, D., Pillay, A., Gakuba, R., and J, S. C. (2013). An architectureand reference implementation of an open health information mediator: Enablinginteroperability in the rwandan health information exchange. In Weber, J. andPerseil, I., editors, Foundations of Health Information Engineering and Systems, vol-ume 4 of 5, chapter 6, pages 87–105. Springer Publishing Company, Incorporated,3 edition.

DICOM (2019). Overivew - dicom standard. Retrieved from: https://www.dicomstandard.org/about/.

Dixon, B. E., Hook, J., and Vreeman, D. J. (2015). Learning from the crowd in termi-nology mapping: The loinc experience. Laboratory medicine, 46 2:168–74.

Dlodlo, N. and Hamunyela, S. (2017). The status of integration of health informationsystems in namibia. Electronic Journal of Information Systems Evaluation, 20 2:p61–75.

Docker (2019). What is a container? Retrieved from: https://www.docker.com/resources/what-container.

Esmaeilzadeh, P. and Sambasivan, M. (2017). Patients’ support for health informa-tion exchange: a literature review and classification of key factors. BMC MedicalInformatics and Decision Making, 17.

Evans, W., Ashbury, F., Hogue, G., Smith, A., and Pun, J. (2014). Implementing aregional oncology information system: Approach and lessons learned. CurrentOncology, 21:224–33.

Fernandes, L., Burke, J., and O’Connor, M. (2017). Applying innovation to the pa-tient identification challenge. Journal of the American Health Information ManagementAssociation, 88:26–29.

Fielding, R. and Reschke, J. (2014). Hypertext transfer protocol (http/1.1): Se-mantics and content. Retrieved from: https://tools.ietf.org/html/rfc7231#section-6.3.4.

Gartner (2019). It infrastructure. Retrieved from: https://www.gartner.com/it-glossary/it-infrastructure/.

Government of Malawi (2017). Health sector strategic plan ii 2017-2022 - towardsuniversal health coverage. Technical Report 2, Government of the Republic ofMalawi.

Grann Fia, A., Erichsen, R., Nielsen, A., Frøslev, T., and Thomsen, R. (2011). Existingdata sources for clinical epidemiology: The clinical laboratory information sys-tem (labka) research database at aarhus university, denmark. Clinical epidemiology,3:133–8.

Hallsteinsen, ø., Klefstad, B., and Skundberg, O. (2008). Innføring i datakommu-nikasjon, volume 4 of 10. TISIP Gyldendal akademiskk, Trondheim, 2nd ed edi-tion.

Harris, S. (2013). CISSP : exam guide, volume 4 of 10. McGraw-Hill, New York, 6thed edition.

https://www.dicomstandard.org/about/

https://www.dicomstandard.org/about/

https://www.docker.com/resources/what-container

https://www.docker.com/resources/what-container

https://tools.ietf.org/html/rfc7231#section-6.3.4

https://tools.ietf.org/html/rfc7231#section-6.3.4

https://www.gartner.com/it-glossary/it-infrastructure/

https://www.gartner.com/it-glossary/it-infrastructure/

BIBLIOGRAPHY 83

Hicken, V. N., Thornton, S. N., and Rocha, R. A. (2004). Integration challenges ofclinical information systems developed without a shared data dictionary. Studiesin health technology and informatics, 107 Pt 2:1053–7.

Hinchley, A. (2007). Understanding version 3 : a primer on the HL7 version 3 HealthcareInteroperability Standard - normative edition. 10. Alexander Mönch Publ., Munich,4th ed edition.

HL7 (2018). Hl7 standards - section 1: Primary standards. Retrieved from: https://www.hl7.org/implement/standards/product_section.cfm?section=1.

HL7 (2019a). Comparison - fhir v4.0.0. Retrieved from: https://www.hl7.org/fhir/comparison.html.

HL7 (2019b). Fhir cheatsheet. Retrieved from: https://fire.ly/wp-content/uploads/2017/02/cheatsheet-dstu1.pdf.

HL7 (2019c). Hl7 version 2 product suite. Retrieved from: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185.

HL7 (2019d). Welcome to fhir R©4. Retrieved from: http://hl7.org/fhir/?utm_referrer=http%3A%2F%2Fwww.hl7.org%2Fimplement%2Fstandards%2Fproduct_brief.cfm%3Fproduct_id%3D491.

InSTEDD (2019). Resource map. Retrieved from: https://instedd.org/technologies/resource-map/.

Islam, M., Poly, T., and Li, Y.-C. (2018). Recent advancement of clinical informationsystems: Opportunities and challenges. Yearbook of Medical Informatics, 27:083–090.

Juma, K., Nahason, M., Apollo, W. M., Gregory, W., and Patrick, O. A. (2012). Cur-rent status of e-health in kenya and emerging global research trends. In Interna-tional Journal of Information and Communication Technology Research.

Kiberu, V., Mars, M., and Scott, R. (2017). Barriers and opportunities to implemen-tation of sustainable e-health programmes in uganda: A literature review. AfricanJournal of Primary Health Care & Family Medicine, 9.

Kimaro, H. and Nhampossa, J. (2005). Analyzing the problem of unsustainablehealth information systems in less-developed economies: Case studies from tan-zania and mozambique. Information Technology for Development, 11:273 – 298.

Kling, R. (2002). What is social informatics and why does it matter? D-Lib Magazine,5.

Kurose, James. F, R. K. W. (2013). Computer networking : a top-down approach, volume 4of 10. Pearson Education, Harlow, 6th ed edition.

Kushniruk, A. and Patel, V. (2004). Cognitive and usability engineering methodsfor the evaluation of clinical information systems. Journal of biomedical informatics,37:56–76.

Lab, O. C. (2016). About ocl. Retrieved from: https://github.com/OpenConceptLab/ocl_user_wiki/wiki/About-OCL.

Lab, O. C. (2017). Ocl features. Retrieved from: https://github.com/OpenConceptLab/ocl_user_wiki/wiki/OCL-Features.

https://www.hl7.org/implement/standards/product_section.cfm?section=1

https://www.hl7.org/implement/standards/product_section.cfm?section=1

https://www.hl7.org/fhir/comparison.html

https://www.hl7.org/fhir/comparison.html

https://fire.ly/wp-content/uploads/2017/02/cheatsheet-dstu1.pdf

https://fire.ly/wp-content/uploads/2017/02/cheatsheet-dstu1.pdf

https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185

https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185

http://hl7.org/fhir/?utm_referrer=http%3A%2F%2Fwww.hl7.org%2Fimplement%2Fstandards%2Fproduct_brief.cfm%3Fproduct_id%3D491



https://instedd.org/technologies/resource-map/

https://instedd.org/technologies/resource-map/

https://github.com/OpenConceptLab/ocl_user_wiki/wiki/About-OCL

https://github.com/OpenConceptLab/ocl_user_wiki/wiki/About-OCL

https://github.com/OpenConceptLab/ocl_user_wiki/wiki/OCL-Features

https://github.com/OpenConceptLab/ocl_user_wiki/wiki/OCL-Features

84 BIBLIOGRAPHY

Latham, T., Malomboza, O., Nyirenda, L., Ashford, P., Emmanuel, J., M’baya, B.,and Bates, I. (2012). Quality in practice: Implementation of hospital guidelinesfor patient identification in malawi. International journal for quality in health care :journal of the International Society for Quality in Health Care / ISQua, 24.

Liang, S., Porat, T., Tapuria, A., Ethier, J.-F., Delaney, B., and Curcin, V. (2016). Adynamic medical terminology mapping system – metmaps. In Data Mining forMedical Informatics workshop.

Limoncelli, T. A. (2007). The practice of system and network administration. Addison-Wesley, Upper Saddle River, N.J, 2nd ed edition.

Lippeveld, T., Sauerborn, R., and Bodart, C. (2000). Design and implementation ofhealth information systems. World Health Organization.

Lium, J.-T., Tjora, A., and Faxvaag, A. (2008). No paper, but the same routines: Aqualitative exploration of experiences in two norwegian hospitals deprived of thepaper based medical record. BMC medical informatics and decision making, 8:2.

LOINC (2019). Loinc term basics. Retrieved from: https://loinc.org/get-started/loinc-term-basics/.

McCarthy, D., Propp, K., Cohen, A., Sabharwal, R., A Schachter, A., and Rein, A.(2014). Learning from health information exchange technical architecture and im-plementation in seven beacon communities. eGEMs (Generating Evidence and Meth-ods to improve patient outcomes), 2:1–17.

MEASUREEvaluation (2018). Building a strong and interoperable digital health in-formation system for uganda. Retrieved from: https://www.measureevaluation.org/resources/publications/fs-18-296.

Mwakilama, S., Chawani, M., Monwe, m., Kapokosa, G., and Gadabu,O. (2014). Interoperability, integration and standardization of e-healthinitiatives in malawi: Current efforts and prospects. Retrieved from:https://repository.ubuntunet.net/bitstream/handle/10.20374/51/2014_UbuntuNet-Connect_Proceedings.pdf?sequence=1&isAllowed=y.

Mzeru, M. R. and Mwendo Hamis, M. (2019). Improving interoperabil-ity of health information system in tanzania. Retrieved from: https://www.childhealthtaskforce.org/sites/default/files/2018-09/data_wkshp_tanz_interop_his.pdf.

Nielsen, P. and Sæbø, J. (2015). Three strategies for functional architecting: Casesfrom the health systems of developing countries. Information Technology for Devel-opment, 22.

of Nebraska-Lincoln, U. (2019). System security. Retrieved from: https://its.unl.edu/bestpractices/system-security.

OpenHIE-Community (2019). Achitecture. Retrieved from: https://ohie.org/architecture/.

OpenHIM (2019). About. Retrieved from: http://openhim.org/#about.

OpenLDAP (2019). Openldap software. Retrieved from: https://www.openldap.org/software/.

https://loinc.org/get-started/loinc-term-basics/

https://loinc.org/get-started/loinc-term-basics/

https://www.measureevaluation.org/resources/publications/fs-18-296

https://www.measureevaluation.org/resources/publications/fs-18-296

https://repository.ubuntunet.net/bitstream/handle/10.20374/51/2014_UbuntuNet-Connect_Proceedings.pdf?sequence=1&isAllowed=y

https://repository.ubuntunet.net/bitstream/handle/10.20374/51/2014_UbuntuNet-Connect_Proceedings.pdf?sequence=1&isAllowed=y

https://www.childhealthtaskforce.org/sites/default/files/2018-09/data_wkshp_tanz_interop_his.pdf



https://its.unl.edu/bestpractices/system-security

https://its.unl.edu/bestpractices/system-security

https://ohie.org/architecture/

https://ohie.org/architecture/

http://openhim.org/#about

https://www.openldap.org/software/

https://www.openldap.org/software/

BIBLIOGRAPHY 85

Oracle (2019). Fusion middleware concepts and architecture for oracle ser-vice bus. Retrieved from: https://docs.oracle.com/cd/E28280_01/doc.1111/e15020/introduction.htm#OSBCA107.

Puppet (2019). What is configuration management? Retrieved from: https://puppet.com/solutions/configuration-management.

RedHat (2019). What is ci/cd? Retrieved from: https://www.redhat.com/en/topics/devops/what-is-ci-cd.

Republic of Kenya (2016). Kenya national ehealth policy 2016-2030. towards attain-ment of the highest standard of health through adoption and use of ict. Technicalreport, Republic of Kenya.

Republic of Uganda (2017). Uganda national ehealth strategy 2017 - 2021. Technicalreport, Republic of Uganda.

Ries, E. (2011). The lean startup : how constant innovation creates radically successfulbusinesses, volume 4 of 10. Portfolio Penguin, London, 5th ed edition.

Runeson, P. and Höst, M. (2008). Guidelines for conducting and reporting case studyresearch in software engineering. Empirical Software Engineering, 14(2):131.

Sæbø, J., Braa, J., Kossi, E., Jalloh, M., and Manya, A. (2013). Developing decen-tralised health information systems in developing countries –cases from sierraleone and kenya. Journal of Community Informatics, 9.

Sæbø, J., Kossi, E. K., Titlestad, O. H., Tohouri, R.-R., and Braa, J. (2011). Compar-ing strategies to integrate health information systems following a data warehouseapproach in four countries. IT for Development, 17:42–60.

Sirintrapun, S. J. and Artz, D. (2015). Health information systems. Surgical pathologyclinics, 8 2:–68.

Stansfield, S., Orobaton, N., Lubinski, D., Uggowitzer, S., and Mwanyika, H. (2008).The case for a national health information system architecture: A missing link toguiding national development and implementation.

Tweya, H., Feldacker, C., Gadabu, O., Ng’ambi, W., L. Mumba, S., Phiri, D., Kam-vazina, L., Mwakilama, S., Kanyerere, H., Keiser, O., Mwafilaso, J., Kamba, C.,Egger, M., Jahn, A., Simwaka, B., and Phiri, S. (2016). Developing a point-of-careelectronic medical record system for tb/hiv co-infected patients: Experiences fromlighthouse trust, lilongwe, malawi. BMC Research Notes, 9.

Ulrik, M. (2019). Icd-10 i store medisinske leksikon. Retrieved from: https://sml.snl.no/ICD-10.

van der Veer, H. and Wiles, A. (2008). Etsi white paper no. 3. achieving techni-cal interoperability - the etsi approach. Retrieved from: https://www.etsi.org/media-library/white-papers.

Whitman, L. and Panetto, H. (2006). The missing link: Culture and language barriersto interoperability. IFAC Annual Reviews in Control, 30 2:233–241.

Wolmarans, M., Solomon, W., Tanna, G., Venter, J., Solomon, W., Venter, J., Parsons,A., Chetty, M., and Dombo, M. (2014). ehealth programme reference implementa-tion in primary health care facilities. South African Health Review, 2014/2015(1):35–43.

https://docs.oracle.com/cd/E28280_01/doc.1111/e15020/introduction.htm#OSBCA107

https://docs.oracle.com/cd/E28280_01/doc.1111/e15020/introduction.htm#OSBCA107

https://puppet.com/solutions/configuration-management

https://puppet.com/solutions/configuration-management

https://www.redhat.com/en/topics/devops/what-is-ci-cd

https://www.redhat.com/en/topics/devops/what-is-ci-cd

https://sml.snl.no/ICD-10

https://sml.snl.no/ICD-10

https://www.etsi.org/media-library/white-papers

https://www.etsi.org/media-library/white-papers

86 BIBLIOGRAPHY

World Health Organization (2004). Diseases of the nervous system. Retrievedfrom: https://apps.who.int/classifications/apps/icd/icd10online2005/fr-icd.htm?gg50.htm+.

World Health Organization (2019). Health statistics and information systems. Re-trieved from: https://www.who.int/healthinfo/indicators/2018/en/.

Yin, R. K. (2014). Case study research : design and methods, volume 4 of 10. Sage, LosAngeles, California, 5th ed edition.

https://apps.who.int/classifications/apps/icd/icd10online2005/fr-icd.htm?gg50.htm+

https://apps.who.int/classifications/apps/icd/icd10online2005/fr-icd.htm?gg50.htm+

https://www.who.int/healthinfo/indicators/2018/en/

Interview guide - technical Field date and location: Start time: End time: Interviewee: Position/title: Education: Post experience: Warm up

1. What is your professional background?

2. What are your responsibilities at here? Job description?

Data use and culture

3. How would you describe the data use culture in Malawi today?

4. In what ways, do you improve data for decision making?

Status of HIS

1. How would you describe some of the challenges with HIS?

2. How would you describe the architecture of current HIS? (architecture type)

3. How would you describe the infrastructure at the various levels (national, district,

facility)?

4. Do you see any challenges with the current infrastructure?

5. Can you give an overview of the information systems that currently exist at national,

district and facility?

6. Please explain to me the information flow between these levels.

7. How is the integration process/method of various information systems?

8. How can health data be exchanged between two silo systems?

9. In what ways can one enable interoperability between HIS?

10. Do you acknowledge any challenges with the exchange of data among the systems at

the facility level or any other levels?

11. What kinds of data standards is used exchanging data?

BIBLIOGRAPHY 87

Appendix A

Infrastructure

1. How do you manage the infrastructure? What technologies do you use to support

the IT infrastructure?

2. How would you describe the network setup (network topology)?

3. What are the biggest security concerns, and do you conduct security assessment? (In

other words, do you have established and defined processes to address computer

security breaches?)

4. What technologies do you use, that could detect attack and intrusion?

5. Do you routinely manage, monitor and/or analyze the collection of logs of user

activity, network activity, performance data, application activity, and/or flow data in

your infrastructure?

Closing

1. Do you have any questions for me?

2. Is there anything you want to add that you feel we have not covered?

LETTER OF INFORMATION

Title of the Research Study: A case study investigating integration and interoperability of Health Information Systems in sub-Saharan Africa

Principal Investigator/s/researcher: Norah Elisabeth Nguyen, Bsc Co-Investigator/s/supervisor/s: Jens Johan Kaasbøll, Prof, Research Group for Information Studies, University of Oslo.

This research is part of my master thesis project as required by the University of Oslo. The proposal for this study has been registered at the Norwegian Social Science Data Services (NSSDS), Reference #: 981260.

The purpose of this study is to understand the processes of Health Information Systems integration in the Sub-Saharan Africa with emphasis on the technical details for the purpose of generating quality data to achieve Universal Health Coverage. This study is an ongoing process which shall be conducted in Malawi, as part of my study to enable for me to finish my degree at the University of Oslo.

It will involve you sharing me on the processes, practices and experiences on how they manage.

Our discussion will involve the participant talking and sharing with their experiences with the integration processes and the different information systems that have been integration, with the researcher. A part of the participation involves giving the researcher access to reports from the Department of Health or other software and technical documentation that is relevant for the researcher to gain knowledge about the integration processes. Furthermore, participation involves me observing your workflow. The researcher will observe the participants workflow. The purpose of direct observation is to gain knowledge about the infrastructure and workflow of health personnel in the healthcare facility. The researcher will take notes when she observes. The discussion will take about 45 minutes to an hour.

Participation is voluntary and free, and there is not remuneration for participation. During the course of our discussion, you are either free not to answer any question or withdraw without any circumstances. We will not collect sensitive data about you. Therefore, in any circumstances, all information about you will be anonymous. There will be no negative consequences for you if you chose not to participate or later decide to withdraw. Your participation in this project will not affect your place of work/employer.

The interviews shall be taped and transcript. The transcripts of the interview, photo (if any) taken during the interviews shall be preserved on the researcher’s computer, which will be locked away when not in use for research purposes. The files will be protected, e.g. password-protected access.

The identity of participants will not be revealed in any discussion, description or scientific publications by the researchers. Sensitive data about me will not be collected and information about me will be made anonymous and confidential. Any new information or

BIBLIOGRAPHY 89

Appendix B

benefit that develops during the course of the study will be shared as follows: the final report will be sent by e-mail to the participants.

Persons to Contact in the Event of Any Problems or Queries:

Supervisor Researcher Jens Johan Kaasbøll University of Oslo Email: Email: [email protected]

Norah Elisabeth Nguyen University of Oslo Tel: +47 48350224 Email: [email protected]

CONSENT Statement of Agreement to Participate in the Research Study:

• I hereby confirm that I have been informed by the researcher, ____________ (name

of researcher), about the nature, conduct, benefits and risks of this study.

• I have also received, read and understood the above written information (Participant

Letter of Information) regarding the study.

• I am aware that the results of the study, including personal details regarding name and

profession will be anonymously processed into a study report.

• In view of the requirements of research, I agree that the data collected during this

study can be processed in a computerized system by the researcher.

• I may, at any stage, without prejudice, withdraw my consent and participation in the

study.

• I have had sufficient opportunity to ask questions and (of my own free will) declare

myself prepared to participate in the study.

• I understand that significant new findings developed during the course of this research

which may relate to my participation will be made available to me.

_____________________ _______ _______ _____________________

Full Name of Participant Date Time Signature

I, __________________ (name of researcher) herewith confirm that the above participant has been fully informed about the nature, conduct and risks of the above study. _____________________ _______ _______ _____________________

Full Name of Researcher Date Time Signature