Making data useful to health workers by increasing the usefulness and usability of their tools.

(1)

Making data useful to health workers by increasing the usefulness and usability of their

tools

An experiment to increase health workers ability to detect symptoms of

health issues with the District Health Information System (DHIS2) Tracker

Capture Android app

John Melin

Thesis submitted for the degree of

Master in Informatics: Programming and networks 60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

Making data useful to health workers by increasing the

usefulness and usability of their tools

An experiment to increase health workers ability to detect symptoms of

health issues with the DHIS2 Tracker Capture Android app

John Melin

(4)

Making data useful to health workers by increasing the usefulness and usability of their tools

http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Abstract

For health data to be useful it must cater to the user’s tasks and be presented in a way that is understandable. To increase the quality of data, many health systems have started to use software tools for data collection.

But just like data, tools often suffer from not be useful to the health workers.

Also, even when the tools manage to be useful, many are too hard to use to be usable. It is the frontline health workers who bear the burden of collecting data. But making the data useful in the tools they use is often neglected.

Nurses and Community Health Worker (CHW)s in Malawi are trained to detect symptoms of health issues. Increasingly they have been adopting the Android software tool Tracker Capture for collecting data. Data for each visit is that is also relevant for them is stored as an event in the app.

It is thus available and relevant for detecting symptoms, but to retrieve the data for each event, they have to navigate back and forth through multiple pages. If they cannot detect symptoms, the app will not be useful, and if they can, but doing so talks too long, the app will not be usable. It is my claim that this way of accessing and presenting data in the Tracker App makes it neither sufficiently useful nor usable in the context of detecting signs of health issues.

With this thesis I made an attempt to increase the usefulness and usability of the Tracker Capture by developing a History Table that presents all the data for each patient on one page. The experiments and interviews that followed were based on 15 participants in the Malawian health system.

The objective was to explore the usefulness and usability of the current app and the History Table feature in the context of detecting symptoms. I also asked questions to further explore ways to both increase the usability of the History Table and ways to increase the usefulness of the Tracker Capture in other contexts.

Surprisingly, the findings showed little difference in measured usefulness between the two versions. However, the findings of experienced usefulness as well as the measured and experienced usability were found to be in favour of the History Table. With these findings in mind, one can still conclude that the History Table had a much higher usefulness in the context of detecting symptoms.

(6)

(7)

Acknowledgement

I would like to thank all the people that has assisted me in seeing this thesis to the end.

First, I would like to thank my two main and secondary advisors, Jens Johan Kaasbøkk and Esther Namatovu. I also thank my supervisor Mari Iversen for both insightful feedback, introducing me to Chibuku Shake Shake, and for being a great travel partner.

Secondly, thanks to my friends from Malawi, my external advisor Ms.

Chipo Kanjo, Yamikani Phiri and Lawrence Byson for help with finding participants for my research and for great food.

I also want to thank Ilya Nee, Zufar Ismanov, Mathias Næss, Amrit Chhetri for being great travel, drinking and safari partners.

Also, thanks also to all of my friends, who have supported me through- out my work with the thesis, and for allowing me to go "underground" for some time.

Last I also want to thnak my family, my mother, my two brothers and my sister for their support and encouragement.

(8)

(9)

Acronyms

ANC Antenatal care

CHW Community Health Worker

DHIS2 District Health Information System DHO District Health Officer

HIS Health Information System

HISP Health Information Systems Programme SDK Software Development Kit

UI User Interface UIO University of Oslo UX User Experience

(16)

(17)

List of Figures

1.1 Overview of the various levels and their relevant data needs

in a health system. (AbouZahr & Boerma, 2005) . . . 2

1.2 The flow to find the data elements. . . 6

2.1 Map over Malawi . . . 9

3.1 Examples of relevance by proximity . . . 15

3.2 A bar chart. (Europe, 2009) . . . 17

3.3 A line chart, also known as a line graph. (Europe, 2009) . . . 17

3.4 A pie chart. (Europe, 2009) . . . 18

3.5 Map presentation. (Europe, 2009) . . . 18

3.6 A single-dimensional table. . . 19

3.7 A multi-dimensional table. . . 19

3.8 The anatomy a multi-dimensional table. (Europe, 2009) . . . 20

3.9 How usability and usefulness relates to performance of the software in the context of information retrieval (Tsakonas & Papatheodorou, 2006). . . 22

4.1 How all steps fit into the action research cycle. . . 24

5.1 Architecture of Tracker Capture . . . 38

5.2 Architecture of Tracker Capture . . . 40

5.3 An example of how two UI modules defined by fragments can be combined into one activity in different devices. . . 41

5.4 An example of how Intents are delivered. . . 42

6.1 Event History Table development milestone timeline. . . 45

6.2 The stetch prototype that the implemented prototypes was based on. . . 48

6.3 The difference between landscape and portrait mode. . . 49

6.4 Prototype with the name of each Data Element in each box . 50 6.5 Prototype where the names of Data Elements are only shown in the first column . . . 51

6.6 Prototype where values for each Data Element can be entered right in the History Table . . . 52

6.7 Prototype where the history is only shown for one Data Element at a time upon data entering . . . 53

6.8 Code with cyclomatic complexity of 15 . . . 56

6.9 Part of refactored excerpt example . . . 56

(18)

6.10 Complex predicate . . . 57

6.11 Simplified predicate . . . 57

6.12 Packages in the project . . . 58

6.13 Relevant files used in the UI screen of the client list . . . 60

6.14 Relevant files used in the UI list of a client’s events . . . 61

6.15 Relevant files used in the UI for a form . . . 62

6.16 The architecture of related classes. . . 63

6.17 Sequence diagram of how the app will create and display the History Table . . . 68

7.1 How many of the 10 students detected symptoms between the apps . . . 71

7.2 How many of the 2 nurses detected symptoms between the apps . . . 71

7.3 How many of the 2 nurses detected symptoms between the apps . . . 72

7.4 How many of the total group of health workers detected symptoms between the apps . . . 73

7.5 Prototype 1 and 2. . . 75

7.6 Did the participants prefer prototype 1 or 2. . . 76

7.7 Chart of the participants preference. . . 76

7.8 List of how many participants suggested each improvement 79 7.9 The requested data elements related to illness status. . . 80

7.10 The requested data elements related to what drugs the clients are using. . . 81

7.11 The requested data elements related to ANC. . . 82

7.12 The requested data elements related to Vaccine Status. . . 82

7.13 The requested data elements related to client personalia. . . 82

7.14 Summary of types of data elements the participants requested. 83 8.1 Prototype 3 with highlight for current event . . . 91

8.2 The name of the client is only displayed in the first client list page, even though there is still space where it could be displayed. . . 92

(19)

List of Tables

4.1 Timeline of meetings . . . 25 4.2 Use-cases that was used in the experiments. Format is read

as ANC1-ANC2-ANC3-ANC4 . . . 28 4.3 Participants table . . . 29 7.1 Table of experiment interviews . . . 70

(20)

(21)

Chapter 1

Introduction

To a large extent, for a health information system to be successful, all stakeholders needs to be able to make well informed decisions based on high quality data. For stakeholders to use data in decision-making, the data they have available must be useful. This means that the health system must not only make high quality data available, but it must also make data useful to the stakeholders. The data must be easily accessible, relevant to the stakeholder’s task and presented in such a way that it makes sense to the stakeholder.

Health workers such as nurses has the knowledge to diagnose patients based on symptoms, CHWs may do client follow-ups of vaccines or detect danger signs of illnesses to refer clients to health facilities. These health workers are the first point of contact in collecting data and have increasingly started to use software tools for data collection. When creating new software tools, most efforts are made on increasing the accuracy and ease of collecting data. However, little effort is made on creating useful software tools that may present the data in a way that can help the health workers in context of the other tasks they do, making the current nature of health workers just data collectors. For software to be used it must not only be useful, it must also be usable. This means that not only can you use it to perform a task, but the user should also be able to perform the task in an accurate and reasonable fast manner.

Nurses and CHW in Malawi are one of the frontline health workers who collects data using the Tracker Capture app created by DHIS2. One of the responsibilities of nurses is collecting data on and treating pregnant women as part of the antenatal care program. But, as I will talk about later in this chapter, my claim is that the Tracker Capture currently is only catered to data collection and makes no effort at presenting data in a way that may be useful to the nurse’s task of detecting symptoms of health issues.

This thesis explores and attempts to increase the usefulness and usability of the Tracker App by presenting the data in a way so that they users may detect symptoms of health danger signs in a satisfactory manner. To do so, based on literature on data presentation, I designed and implemented a prototype History Table that present all the relevant data in one single page. I then travelled to Malawi to test out the prototype in

(22)

an experiment and interview with nurses, CHWs and a clinician. As the CHWs I met were not responsible for antenatal care, they were not used in the experiments. Instead they were only asked questions not related to antenatal care. Using other programs however, the CHWs should also be able to use the History Table.

1.1 Research context

1.1.1 High quality data

The primary function of a health information system is to provide high quality data for well-informed health decision-making. (Theo Lippeveld, 2000) High quality data is therefore the cornerstone of all well-designed health information systems. But what constitutes high quality data? In the health domain, one talks about high quality data as data that is timely, accurate and complete. Data must be timely: If the data is delivered, compiled and analysed to late, the decisions based on the data may not be relevant anymore and may drive inaccurate decisions. Data must be accurate:If the collected data is not correct, any decisions will not be based on the actual current situation. Data must be complete: Gaps in collected data will lead to a partial view of the health situation. If you don’t have the complete picture of a health situation, this will lead to uninformed decisions.

Figure 1.1: Overview of the various levels and their relevant data needs in a health system. (AbouZahr & Boerma, 2005)

1.1.2 Data needs to be useful to the stakeholders

Poor data quality leads to low data use, and low data use will make data quality remain poor. (Jørn Braa, 2012) For the data quality to be increasingly high, it needs to be used by all stakeholders in the health

(23)

information system. But, if the consumers of data do not easily have access to or understand the data it is not usable for them. As a result, the data will not be used and decisions they make will be uninformed. This ties into three of the most important aspects of making data useful and easy to use.

Accessibility,relevanceandpresentation.

Data should be easy to access

If the data cannot be easily accessed it will go unused. It’s less likely that user would use data if they would have to travel to a centre where the data is stored. Therefore, it’s important that the data can be accessed e.g. online from a server or in the tools used to collect data so that the data can be readily available when needed.

Data should have relevance

As we can see in figure 1.1, each level in the health system have their own varying needs driven by different rationales for essential information according their respective roles and their scope of decision making. For the data to be relevant to the actors in the health system, the appropriate level of detail-level must be catered to the actor’s level in the health system.

The data detail-level decreases as the hierarchy level increases. Such as that higher levels in hierarchy require less detailed information than lower levels. At the lower levels, decisions regarding the care of individuals are made. This means that the data should cater more to the individual detail-level. District level managers need data to make decisions on health programmes district. Health Doctors and nurses in the health facility level need data to make clinical diagnosis and manage health problems.

Community health workers may need data to follow up on villagers.

Data should be presented well to be useful

Making data useful is not only a matter of giving access to relevant data.

The data must also be presented in such a way so the data makes sense to the user. According to one of the principles in (Jørn Braa, 2012), presentation of data is a key aspect of making actors seeing the usefulness of data, that will lead to increased data quality. The same principle to increase data quality is mentioned in a book by Lippeveld (Theo Lippeveld, 2000) p.27, Data presentation should be customized for users at all levels to increase data. By different ways of presenting data, you may guide them to see patterns in data and focus on the important aspects of their relevant data need.

1.1.3 Software usefulness

Just as with data, software must be useful for it to be used by the users.

Software usefulness refers to if the user is able accomplish a task or objective with the software (Foundation, 2018b). Software such as browsers

(24)

are useful if the users are able to view websites with them. The usefulness of software will thus be a measurement of the ’value’ of the product given by the users. This value is determined by how useful a software’s features and data is to the task the user want to accomplish (MacDonald & Atwood, 2014). Therefore, the usefulness of data, may also affect the usefulness of the software that contain it.

Even though software may be useful, this may not be enough for users to actually use it. For software to be used, it should also be easy to use.

1.1.4 Software usability

The official definition of usability in the ISO 9241 standard is: Software is usable when it allows the user to execute his task effectively, efficiently and with satisfaction in the specified context of use. Thus, usability refers to how accurate and easy to use a system is, for the task that the user wants to perform. A kettle may provide the usefulness of being able to pour hot water, but if you often spill hot water on your hands when doing so, it’s not very usable. If software us difficult to use, users may end up generating workarounds or not using the software at all. An example of this was shown in a project from a hospital in Uganda. A lack of focus on usability increased the burden of entering data for the facility workers. This resulted in the facility workers going back to paper tools not using the software at all (Li, 2017).

1.2 Research problem

We’ve established that the literature is clear on the view that data needs to be used by all stakeholders in the health information system. The frontline health workers such as nurses collect data on patients and therefore have access to relevant historical data that could be used to detect symptoms of health issues. But if the tools used to collect this data are not made useful and usable to the user by presenting the data in a way that makes sense and promotes their ability to detect health issues in an easy-to-use manner, then the data may not be seen as useful and may end up not being used.

It is the health workers such as nurses and CHWs who are the first point of contact with the people. In practice however, most health workers only use the tools for collecting data. By increasing their ability to provide quality care for their clients, they may see the data as useful and get an inner motivation of collecting data.

Nurses responsibilities

The nurses are responsible for collecting routine data for a range of various programs such as HIV, Tuberculosis, Child growth, Diabetes and Antenatal care. Antenatal care is received by patients from during pregnancies. Its intention is to give the pregnant woman and the foetus the care they need in order to have a healthy pregnancy. (WHO, 2018) Programs such as

(25)

Antenatal care (ANC), may require several visits to complete. According to WHO’s current guidelines, the client is required to have a minimum of 4 visits (WHO, 2018).

Typical symptoms of health danger signs associated with Antenatal care is greatly decreasing weight during the pregnancy. Pregnant women tend to lose some weight due to morning sickness and the body directing.

But decreasing weight can also be an indication of the mother not getting enough nutrition, in turn giving too little nutrition to the foetus. Other symptoms of issues may be when blood pressure in rapidly increasing.

Blood pressure is separated by two data elements. Systolic blood pressure and Diastolic blood pressure. Normal blood pressure for a pregnant woman should be somewhere close to 120 systolic and 80 Diastolic while over 140 Systolic and 90 Diastolic is a cause of concern. If the blood pressure is rapidly rising towards those values it could be an indication that the mother has Hypertension.

The problem with the Tracker Capture android app

In Malawi many nurses and health workers are increasingly starting to use software tools for collecting data, such as the Tracker Capture android app.

The Tracker Capture Android App, developed by DHIS2 is a software tool for collecting routine data for clients and tracking them over time. With the Tracker Capture, data that the health workers collect, is stored and is accessible using the app. The data they collect is relevant for their detail- level. However, the data is not presented is such a way that it can be easily interpreted to promote decision-making. Each visit with a patient is stored as a so-called event on separate pages. Every time the user wants to compare data elements between events, she would have to first go tap the first event of the patient event list page as seen in step 1 of figure 1.2.

After scrolling down to the desired data element and remembering it, the user has to tap the back button in step 2. Now back on the page for all patient events, the user taps next desired event on step 3 to get to the next event page and compare the data element with the data element from the previous event. This procedure would have to be repeated for each event. One can imagine how many data elements the user would have to remember as the amount events increases. In many cases just comparing the same data element over the events would not show all danger signs.

Some danger signs, such as with blood pressure as mentioned above, might require comparing a combination of data elements from each event. This would require 6 data elements to remember over 3 events.

(26)

Figure 1.2:The flow to find the data elements.

1.3 Research response

With this thesis I aim to explore and try to increase the usefulness and usability of the Tracker App by presenting the data in such a way that the users may detect symptoms of health danger signs.

(27)

By using the existing Tracker Capture App, I designed prototypes of a History Table. Using literature on table data presentation, the History Table would present the data contained in the Tracker in a historical fashion.

I made the claim that by presenting data in a way that increases the user’s ability to detect symptoms of health danger signs, the efficiency and effectiveness of the app will increase.

To gather data I travelled to Malawi and performed experiments to test the nurses ability to detect symptoms in pregnant women enrolled in the Antenatal Care program using the current Tracker Capture app with and without the new prototype table. Following the experiments, I asked questions regarding their perceived usefulness of the History Table and features they would like to see added. As CHWs are not responsible for antenatal care, they were not used for experiments. However, as they should be able to use the History Table in other programs, I did ask them questions on perceived usefulness and features.

1.4 Research Question

Many attempts have been made in making software tools that increase the accuracy and timeliness of data, but there has been less attempts at making data useful by presenting the data in their tools that makes the tools useful and usable to the frontline data collectors.

With the research in mind, I explored making Tracker Capture useful and usable in the context of detecting symptoms of health issues, by adding a History Table feature that presents all data on one page.

To do this This thesis answers the following research questions:

1. What is the usefulness of the History Table in the context of detecting health symptoms?

2. What is the usability of the History Table in the context of detecting health symptoms?

3. What additional features would the health workers like to have accessible in the History Table?

Before answering the questions, I will first introduce some background topics that may help to understand the thesis: A small background on Malawi, country profile and status in Malawi where the experiments took place and the Health Staff in Malawi. I will then present some reviewed literature on usefulness and usability as well presentation of data. There will also be a presentation of the Health Information Systems Programme at the University of Oslo (HISP UiO), the District Health Information System (DHIS2) and the Tracker Capture software for both web and android.

(28)

1.5 Structure of Thesis

1.5.1 Chapter 1 - Introduction

Current chapter, containing research context and background, research problem and the motivation for the study.

1.5.2 Chapter 2 - Research Context

Presents a short overview of the health situation in Malawi where the study took place.

1.5.3 Chapter 3 - Background on usability, usefulness and pre- sentation of data

Gives a background on ways to present data, usability, usefulness and how they relate to each other.

1.5.4 Chapter 4 - Research methodology

Describes the methodology and methods used in this study.

1.5.5 Chapter 5 - Software platform background

Contains a brief background on HISP, DHIS and the Tracker Capture android app. Also, an explanation of Android development.

1.5.6 Chapter 6 - The design and implementation of the History Table prototypes

Presents the design and development process of the History Table.

1.5.7 Chapter 7 - Findings: Experiment and interview with Health Workers

Presents the findings from performing the experiments and interviews with the Histor Table.

1.5.8 Chapter 8 - Discussion

Discusses the findings in the context of earlier literature.

1.5.9 Chapter 9 - Conclusion

Summarises the main findings and answers the research questions and provides suggestions for future work.

(29)

Chapter 2

Research Context

2.1 Malawi Country Profile

Malawi (officially Republic of Malawi) is a small country in the Southern of Africa, bordering to Tanzania, Zambia and Mozambique. Its main capital is Lilongwe and the old capital Zomba as the fourth largest. Malawi covers more than 118.00 km/2 of land with Lake Malawi (also named the Lake of Stars by Dr Livingstone) taking up around third of the area. It has a population of around 18,1 million people (as of 2016) with around 82% of people living in the rural areas.

Figure 2.1:Map over Malawi

Malawi is among the world’s least developed countries ranking 4th place in the 10 lowest human development list according to the Human

(30)

Developed Index. Malawi faces many issues with 57 percent of the rural population is estimated to be living in poverty, a low life expectancy and a high infant mortality. The distribution of the health workers in Malawi are very uneven, with over 80% of the skilled health staff working in urban areas even though 82% of the people living in rural areas (MoH, 2017).

The current WHO recommendations suggest that all women should have at least 4 visits during her pregnancy. Malawi Antenatal care coverage is 92% for at least one 1 visit but only 57% for at least 4 visits.

2.1.1 Technology situation in Malawi and infrastructure. Mobile grid, internet, power, buildings

Being one of the poorest countries in the world, it’s no surprise that Malawi suffers from an unstable power grid. The cities suffer from bad access to power with those that can afford it such as some hospitals sometimes having access to power through expensive diesel generators. The hospitals that don’t have reported premature deaths of new-borns due to absence of power to the incubators. (The Guardian, 2018) The rural parts of the country have very limited access with only 2% of households powered by electricity (NSO, 2008). To save money, the government have also started having mandatory “blackouts” at certain times during the week, where the power grid is turned off. Luckily Malawi’s GSM signal covers as much as 93% of the population and mobile phones sell for pretty cheap. Vendors can be found almost anywhere in the streets and will sell scratch cards, giving access to internet bundles and airtime. These vouchers usually cost around 1000 Kwacha per GB (about 1.3 $). Although this is quite expensive for most people, some bundles may favorize apps like WhatsApp and Facebook by charging less data then they would when using other apps.

2.1.2 Malawi Health Surveillance Assistants

The CHW program has been deemed one of the strategies to improve Malawi’s health problems. In Malawi they are called CHWs. As of now the CHWs are making a valuable contribution to the health situation in rural areas of Africa. They know their population and collect important data and census figures about their communities. (Damtew, Kanjo, Kaasbøll, &

Williamson, 2010)

The CHWs are individuals who are recruited by the government and the community itself, trained and selected to work in the rural communities. The CHWs currently occupy as much as 30% of the whole health workforce in Malawi (MoH, 2017). They are only given from 6- 10 weeks of training before they are deployed to their community and a nearby health facility.

In the community, they are responsible for about 1000 people for whom they perform a wide range of services. (Gilroy et al., 2012) The CHWs are given a broad range of responsibilities and with only a few weeks of training it’s safe to say the knowledge, data quality and the provision of health care is low. The kind of services CHWs can be expected

(31)

to perform includes teaching the community about sanitation, nutrition, the importance of vaccines, actions for preventing diseases and treating diseases such as malaria, diarrhoea and HIV. They could also perform some maternal services, conduct client follow-up home visits, identify danger signs for more severe illness and refer clients they cannot treat to the nearest health. Their focus however remains mainly in health promotion and prevention. On a daily basis CHWs collects vital statistics and maintain village household registers. These numbers are then expected to be handed to their supervisor and their attached health facility. (Damtew et al., 2010) Their supervisor is in turn responsible for several other villages.

2.1.3 Malawi Nurses

In many facilities the most educated staff are the nurses and midwives trained by different health institutions and nursing colleges. The highest level of nurses are the registered nurses with a full university level training for 4 years, followed by a enrolled nurse at diploma level with 2 years of training who make up the majority of nurses.

2.1.4 How many nurses?

As previously mentioned Malawi are experiencing a shortage in health staff that also applies to nurses. As of 2004 Malawi had only 0.6 nurses or midwives per 1000 population. This is far below the minimum number to 80% coverage of basic health services at 2.3 per 1000 population. (WHO, 2006)

(32)

(33)

Chapter 3

Background on usability,

usefulness and presentation of data

For the health workers to use the Tracker Capture to detect symptoms, it needs to be both useful and usable. The nurses need to both be able to detect symptoms and be able to do so with high effectiveness and efficiency.

For software to be used it should be viewed as a useful tool rather than an obstacle and just something that is required to use by their managers. Thus, presenting data in a software tool to increase usefulness and usability of the tool is something that is linked together.

3.1 Software usability

The absolute definition of usability (and usefulness) is not something that is agreed upon. There is however broad agreement that usability refers to effectiveness, efficiency and satisfaction in the context of a task.

It is important not to mix the concept of a system that is easy to use, with the concept of user experience User Experience (UX). These terms are not quite the same. The term "user experience" speaks more generally about the overall experience of the system where usability is only one part of this experience that focuses on accuracy and ease of use. (Kari Rönkkö &

Hellman, 2009)

Usability can be broken down in several goals that should be followed and evaluated during testing and development. Two of the goals that I will be focusing on during this thesis is the "effectiveness" and "efficiency".

• Effectiveness: Refers to the user’s ability to achieve a goal with accuracy and completeness (Benyon, n.d.). This goal indicates whether the task the user is performed correctly with low rate of errors. An example of this done well in the current Tracker Capture app, is that fields that only should have digits as values are programmed to only accept integers. This way it reduces the data entry error and help the users perform the task of data collection

(34)

correctly. Other examples that tie in to effectiveness is using language that is easy to understand, so that the information conveys the correct message and is meaningful to the user.

• Efficiency: Refers to the resources expended in relation to the accuracy and completeness with which users achieve goals (Foundation, 2018a). Efficiency and effectiveness are easily mixed, but from the perspective of usability they are quite different. Where effectiveness measures the user ability to perform task correctly, efficiency rather measures at how fast the user can perform the task. Say if the user wanted to use the data in the current Tracker Capture to diagnose a patient. With current iteration of the Tracker app may still be possible to detect symptoms. However, the way the data is currently presented it may very inefficient. Opening the page for each previous visit where the data is stored requires several steps. The user is required to remember several values in their head, possible having to go back the previous page if values are forgotten. To measure efficiency, you could ask the following question: Once users have learned how to use a system to carry out their tasks, can they sustain a high level of productivity?(Yvonne Rogers, 2011) p.45.

• Satisfaction: Measures how do the users feel about their use of the system. The Tracker Capture Android app is a tool and the users don’t have much choice in using other apps. Considering this, and that this is an early part of the research, satisfaction will be regarded as a low priority at this point and will therefore be omitted.

3.2 Software usefulness

The usefulness of software refers to if the user is able to accomplish a specific task (Foundation, 2018b). Another definition reads: The extent to which a system’s functions and data allow users to complete a set of tasks and fulfil specific goals in a particular context of use (MacDonald

& Atwood, 2014). Just like usability, usefulness is therefore shaped by the context of the task to perform. According to (Davis, 1989) software usefulness is a lot more important to users. He found that when testing usefulness was 1.5 times better when predicting whether people would actually use a product. Users will be willing to put up with bad usability if the product delivers them great perceived value. It doesn’t really matter how easy a product is to use if it doesn’t fulfil the user’s needs.

Even though usability may be less important than usefulness, if the usability is so poor that the user is almost prevented from achieving the specified task, then usefulness will be severly limited (MacDonald &

Atwood, 2014). Imagine a word processing program. It has the usefulness of being able to produce text, but everytime you want to type in a letter, you have to select it from a drop down menu. Producing a piece of text would take ages. It can therefore be argued that a product need to have a good balance between usefulness and usability.

(35)

3.3 Presentation to increase data usefulness

As we know, presentation is a key aspect of making the health workers see the usefulness of data (Jørn Braa, 2012). The data that is presented should not only be relevant to the user’s detail-level but the way the data is presented should also make it very clear that the data can be used. To make this clear, it may be helpful to show what data that belong together.

The law of proximity

A principle that strongly supports this is "The law of proximity". The law of proximity, is a principle stemming from Gestalt Psychology that explains how humans organizes information. It states that: People tend to perceive as a unit those things that are close together in space (Ormrod, 2012). When elements are close together in a space, we perceive them as something that may work together. If a button is close to a lamp, we expect that button to turn on or off the close lamp. The same is true for data. As seen in 3.1 Ex.1, if data is presented together close in a line, we perceive them as a unit, and that they are relevant to each other. If data have equal proximity or are spread out as in Ex.2 and Ex.3, they are perceived as less likely to be relevant.

Figure 3.1:Examples of relevance by proximity

3.3.1 Human memory

According to (Ormrod, 2012), working memory appears to have a limited capacity. A grown person’s capacity to remember units of information is reported to lie somewhere between 5 and 9. However, she reports this is an oversimplification of the capacity of working memory. The capacity of working memory can be increased by using different techniques to increase the information in each unit. E.g. the string of 12 units "5 1 8 9 3 4 2 7 6 4 2 1" can be more easily remembered by chunking them together to form the 4 units "5 1 8" - "9 3 4" - "2 7 6" - "4 2 1". But, even though there exist techniques to increase the number of units stored in working memory, it’s obvious that reducing the need is beneficial. Additionally, it’s suggested that cognitive processing may reduce the working memory capacity (Ormrod, 2012).

Remembering several numbers while doing mathematical equations is way harder than just remembering the numbers. When storing units in working memory, there is also the factor of duration. She reports on experiments

(36)

that have shown that remembering only 3 letters while counting backwards reduced the accuracy by 90% over 18 seconds when told to repeat the letters.

The current app requires several steps to find health issue symptoms.

A health worker need to visit each event page and store at least one data element in working memory. The data elements then need to be combined in memory to come up with a hypothesis. Also, visiting just 3 different events using the app takes at least 10 seconds. If the health worker forgets a data element during this time, she has to revisit an event page, increasing the time to collect data elements in working memory even further. This suggests that finding health issues symptoms with the app is unnecessary hard.

3.3.2 Presentation and accessibility

As we know, when presenting data, it is important to cater the presentation to the users. In areas where education is low, some presentational concepts may be unfamiliar and therefore hard to understand. This studied in a paper by Lippeveld (Theo Lippeveld, 2000). Rural Haitians, accustomed to flat bread had intuitively understood a "pie" chart. To rural Malawians pie charts was hard to grasp. They found it easier grasp different proportions better through measures of beans than flat bread. This suggests that understandings of presentation are highly cultural. Other accessibility considerations from the guide on presentation, suggests providing text alternatives for non-text elements such as charts and images. Low educated individuals, who are not used to line charts may not understand their meaning, and if using line charts, the option to view data as both charts and text should be available.

3.3.3 Different ways of presenting data

There are several forms to present data. Data can be presented as charts, maps or tables, each in various modes.

Charts

Charts represents data as different shapes. Charts are used to visualize the relative sizes of each data element, such as showing the highest value of some element. They should be considered when the data are very dispersed, when you have very few or many elements or when they show little or no variation(Europe, 2009) Charts come in various modes as seen in the following figures.

(37)

Figure 3.2:A bar chart. (Europe, 2009)

Figure 3.3:A line chart, also known as a line graph. (Europe, 2009)

(38)

Figure 3.4:A pie chart. (Europe, 2009)

Maps

Maps deals with geographic information and is therefore only useful when position of the data is important. A common application of maps is when presenting census data.

Figure 3.5:Map presentation. (Europe, 2009)

(39)

Tables

Tables are visualizations that present data in rows and columns. The intersections of the rows and columns are called cells. It is in these cells that the data values are stored. Tables types are usually expressed as either a single (fig:3.6) or multi-dimensional (fig: 3.7) table. The top (and leftmost if a multi-dimensional) cell of each column and row are usually identified by a name.

Figure 3.6:A single-dimensional table.

Figure 3.7:A multi-dimensional table.

3.3.4 Why did I chose tables?

In the application of presenting data for detecting symptoms of health issues, maps make little sense. In this application geographical position of the data elements are not important. Whether the data was collected in one village or another does not affect the symptoms. Charts makes somewhat sense in case of each single instance of data elements, but not in relation to each other. E.g. what element value is higher between weight and

(40)

height doesn’t provide any useful insight. However, if one were to display only the relation of weight values over time, then a line chart would be useful. As all data elements have equal relevance and importance and do not always have any relation to each other, I have chosen the Tables as the main data presentation, but also kept line charts in mind.

Another reason for choosing tables was to mimic the paper tools many health workers are used to.

3.3.5 How to present data using tables

A guide on presenting statistics and data (Europe, 2009) provides several checklists for visual presentations using tables. As this guide mainly focuses on presenting statistics I have extracted the principles that can be used for data presentation in general.

I first present the principles for the "anatomy" of a multi-dimensional table as seen in fig:3.8. Tables should make it easy for actors to understand and find data values. As foot notes and source are only used for statistic presentation, these are omitted.

• The table title should give a clear and accurate description of the data.

• Column headers, at the top of the table, should identify the data presented in each column of the table and provide any relevant metadata such as time period.

• Row stubs, in the first column of the table, should identify the data presented in each row of the table and may also include metadata such as units of measurement.

Figure 3.8:The anatomy a multi-dimensional table. (Europe, 2009)

(41)

With table form and accessibility in mind, the guide provides principles on ensuring that tables are easy to understand.

• Unnecessary text should be avoided.

• Data should be displayed by chronological order for time series.

Analysis will be harder if the user has to build a chronological picture in her head on her own.

• When presenting decimal numbers, you should keep to a minimum of decimal places. The numbers should be aligned on the decimal point (or on the right in the absence of decimal places) so their relative value is clear.

• If numbers of the same data element are aligned in a column, they should not be centered. This can be derived from if you can guarantee that the numbers are of the same magnitude.

• Use thousand separators, such as 1 000 000 rather than 1.000.000.

Using a space instead of a symbol can avoid the problem of having to translate between languages.

• No data cells should be left empty. If a cell is left empty, the user cannot know if the reason was because if was forgotten or if the patient didn’t know. Also, if just marking an empty cell with

"no" the user would not know if the answer to a question is "no"

of if the question just wasn’t answered. If a value is missing, it should rather be identified as something like "not available" or "not applicable". Abbreviations should be avoided as this may have different interpretations. "NA" could refer to any of these.

3.4 How usefulness and usability can be related in software like the Tracker Capture.

As mentioned earlier, there is no consensus on the absolute definitions of usefulness and usability. Many of the definitions may at times overlap in some of their metrics. What this may show, is that they are closely linked to the process of how users use their software and how well the software is performing. This view is supported by a paper that analysed the relationship between usefulness and usability in information retrieval systems (Tsakonas & Papatheodorou, 2006). The paper found significant correlations between usefulness and usability and presented a model between user interaction and information behaviour. As seen in figure 3.9, usefulness is the relationship between user and the content the software provides. Usability shows the relationship between the software itself in how the user interacts with the user interface. The relationship between the software and the content it provides defines the performance in terms of related measures of precision, recall and response time of information retrieval.

(42)

Figure 3.9: How usability and usefulness relates to performance of the software in the context of information retrieval (Tsakonas &

Papatheodorou, 2006).

Do bear in mind, that I did not fully use the framework used in Tsakonas paper. The insights I use from this paper are only the relationships between system, content and user. This model and framework is created with information retrieval systems in mind, and to make it work with the context software like the Tracker Capture, it would need some tweaking. But, I think that it could still be reasonable to say that the same relationships can be applied to data collection software such as the Tracker Capture. If data collection software should be useful in other ways than just collecting data, then additional features created need to draw from the software’s main source of value, namely its data. Just as with information retrieval, how the data is presented, how it’s accessed and the relevance of the data, is what makes the system useful. The more useful data the software provides, the more useful the features that use the data will be. It defines usability in the same way as usual, as in the systems ease of use.

However, the perfomance metric does not fit into the context of software like the Tracker.

For future work, it might however be useful to convert and build upon this model to better fit the need of software such as the Tracker Capture.

(43)

Chapter 4

Research methodology

The aim of the study was to conduct research to explore the design and development of features that will make data useful to health workers. This thesis is part of an HISP Action Research project to find ways to make data useful for the health workers in the software tools they use.

This chapter gives an overview of the methodology and methods used in the research to answers the following research questions.

1. What is the usefulness of the History Table in the context of detecting health symptoms?

2. What is the usability of the History Table in the context of detecting health symptoms?

3. What additional features would the health workers like to have accessible in the History Table?

4.1 Action Research

Action research is a flexible research methodology uniquely suited to researching and supporting change. It integrates social research with exploratory action to promote development(Given, 2008) p.4. One of the goals in Action Research is to first define and identify a problem and then coming up with a viable solution for it. The research is a collaboratory process between researcher and the individuals experiencing the problems. Action research is an iterative process containing multiple phases. The initial phase consists of the finding and defining of the problem. The researcher then devises aplan and follows toact’s out the plan. After data is gathered from theactphase, the data isevaluatedand what has been learned is specified (Given, 2008).

The cycle can then be repeated until the final cycle.

4.2 The phases of the thesis

To answer the research questions listed above, I separated the thesis into three phases that fit into the Design Thinking methodology. Each phase

(44)

will be discussed in more detail during this chapter. Due to the exploratory nature of this thesis I will mainly use qualitative methods from software usability and usefulnens testing. However, I will also use some quantitative methods.

As seen in figure 4.1, the initial phase and phase 1 fits into the plan phase in finding and defining a problem. In the first cycle of action research, this phase involves learning about the domain of health workers situation in Malawi. What they do, how they do it and what may be done to help them. The second phase contains the stages ofact. In this phase I designed and implemented multiple prototypes of the History Table, based on the existing Tracker Capture Android app and using literature on data presentation. Creating use-cases and planning of experiments and interviews was also a part of this phase. In the third phase I travelled back to Malawi toresearch, where I performed experiments and interviews using the developed prototypes. The gathered data was then transcribed and analysed. The lastevaluatephase contained the analysing of findings then coming to conclusions to the research questions.

Figure 4.1:How all steps fit into the action research cycle.

• Initial Phase: Learn about the domain

• Phase 1:

– Define the problem.

– Define a solution.

• Phase 2: Develop the table for use in the experiments.

(45)

– Design of the history table prototype.

– Implementing the history table prototype using the old Tracker app.

– Creating use-cases for use in the experiments.

• Phase 3: Perform experiments and interview using the history table – Running experiments using the Tracker app and the history

table to gather data.

– Performing interviews after the experiments to gather data.

– Write transcrips and analyse data.

• Phase 4: Analyse findings and conclude.

– Analyse the findings.

– Come to conclusions to research questions.

4.3 Initial and Phase 1: Initial field trip to Malawi.

Learning about the Domain and defining problem

My research started by going on a field trip to Chancellor College in Zomba, Malawi. The trip lasted between 21.08.17 and 04.09.17. The agenda of the trip was to gain an understanding on the domain and work practices of CHW’s in Malawi and to get an insight on the health situation in Malawi.

Our contact at the College, Chipo Kanjo, organized a meeting with three CHW’s at a village clinic outside of Ngwerero. Since June the CHW’s had started using a version of Commcare running on android phones. The smartphones were reported on being a bit small for the registration and I was told they would rather prefer to use tablets. In the Commcare app, like the Tracker Capture, health workers had the capability to access relevant data from previous events. There was however no features that allowed for data analysis in any way or any other features that may help the CHWs in the their tasks other than just data collection.

Table 4.1:Timeline of meetings

(46)

On 28.08.17 I had a meeting with the District health officer (District Health Officer (DHO)) in Zomba. The goal of the meeting was to get an update on some of the situation in Malawi and suggestions on what Health Facilities that were best suited for a visit the following days. The district currently has 265 Village clinics with very few having proper infrastructure and buildings. Many are running clinics in other buildings such as old churches, all manned by CHW’s. Since the new health reform of 2017 CHW’s are only to be given a maximum of 15 tasks (12 normal tasks with 3 extra tasks). To avoid CHW’s being overburdened, all new initiatives from programs should go through the Health Facility. The extra tasks can be allowed to switch between CHW’s when needed. However, none of the CHW’s I later visited had heard about this limit and currently had about 17 duties. The DHO suggested a few good catchment areas to visit that are considered “hard to reach” with bad roads, lakes between the mainland, bad or no power grid. Since these areas are hard to reach they are resulting in low timely data delivery. I chose two Health Clinics to visit, that are hard to reach but still have access to the power grid. I was also told that the government have stopped employing new CHW’s as well as 15% of the current CHW’s are not reporting at all.

4.3.1 Defining problem and solution

The need of a feature such as the History Table had been discussed earlier.

Before the Tracker Capture and other software tools, they were using the paper tools. In these tools they were able to view all data elements at a glance on the same paper. When changing to the software tools, no such functionality was present. After coming back, based on what I had learned from the trip and in literature on health information systems, I decided to focus on finding a way to make the frontline health workers see the usefulness of data. As data is collected in the software tools they use such as the Tracker Capture, the data is already accessible and relevant in the same tools according to their detail level. Therefore, to make the health workers see the data as useful, the focus should be on increasing the presentation of this data. I decided to create a prototype that presents all data on one page to use in experiments to explore if it increases the usefulness of the software in the context of the health workers ability to detect symptoms of health issues.

4.4 Phase 2: Designing and Implementing The His- tory Table prototype, and preparing for experi- ments

4.4.1 Prototyping

Prototypes are useful tools when wanting to answer questions on technical feasibilities of ideas and do user testing and evaluation. They are a great aid when wanting to test out different ideas before a fully finished product.

(47)

As prototyping encourages reflection in the design process it is encouraged to be performed before writing any code (Preece, Rogers, & Sharp, 2015).

Prototypes can be separated into low and high-fidelity prototyping. The paper (Preece et al., 2015) cites from Marc Rettig (1994) that: Low fidelity prototypes are quick to build, and lets the users focus on the actual content of the prototype. However low fidelity prototypes are mentioned to have limited usefulness for usability tests. As I wanted to measure both the usefulness and usability in the health workers ability to detect symptoms of health issues, a fully interactive high-fidelity prototype was needed.

Compromises

As the intention of a prototype is to create something quickly, designing prototypes must involve some compromises. Compromises may be having breadth of functionality called horizontal prototyping versus depth of few or one feature called vertical prototyping (Preece et al., 2015). Based on our research question, the only functionality that should be tested is the health workers ability to detect symptoms based on presenting data in a better way. Say the table would contain features that help the user in other aspects of detecting symptoms, such as highlighting high data values.

When analysing the results, it may be hard to distinguish if the feature of presenting all data elements on the same page, or the highlighting feature helped the user the most. Therefore, the prototype should be as simple as possible and helpful features may rather be developed at a later point in time.

4.4.2 Implementation tools

To develop for Android you can either use the Java programming language for native Android, or any other language that has tools that allow you to compile into native Android code. As, the app I implemented was already written for native Android and I would have to change some of the existing code, developing it in native Android was the best choice.

Below are the tools chosen to implement the history table.

• Java: The official language for creating native Android apps.

• Android studio: The official IDE for creating Android apps that includes a device emulator.

• A 10-inch Samsung Tablet for testing the app.

• Git: Version control for software.

4.4.3 Preparations for the experiments Technology Description

In the experiments I used a 10-inch Android Samsung tablet. This tablet was chosen as it was the same tablet I had used in the development phase,

(48)

so by using the same tablet I was sure that the History Table would have the optimal presentation.

The ANC use cases

As part of the experiments, I created use cases using the ANC program as the basis. I designed the use cases to test if the participants ability to detect illnesses would increase when having the history table available.

I created a set of use cases with 3 different outcomes. The first use-case would have a client with high blood pressure. The second use-case would represent a client decreasing weight. The last use-case represented a fully healthy client. The set was then duplicated using different names. All the names used in the use cases are made up names as an ethical consideration.

During the experiments I used two versions of the app. One version of the app would have the new history table included. Another would have the history table omitted. I wanted to make sure that the order of exposition to the two versions would not produce different results. The order of the apps was therefore alternated between every participant. Every second participant would use the version with the history table for the first set of use-cases. The following participant would use the version with the history table for the second set of use-cases.

Table of the use cases

Table 4.2 shows the use-cases that was used in the experiments. The values separated with dashes represent each visit of the ANC program (ANC1- ANC2-ANC3-ANC4). This table only shows the Data Elements that had relevance to the health danger signs the participants were to detect. A full overview of the use cases with all the Data Elements that were used in the experiments can be seen in the appendix.

Table 4.2:Use-cases that was used in the experiments. Format is read as ANC1-ANC2-ANC3-ANC4

(49)

Adding the use cases to the Tracker

The use cases were entered in the system through the DHIS2 Maintenance web application. This makes the program accessible in the Tracker Capture Android App. The Data elements that were used came from the Malawian ANC program, previously collected by a colleague. For the sake of making room for all the data elements in the history table without having to scroll down, a few of the Data Element from the program were omitted.

4.5 Phase 3: Performing experiments and interviews

With the History Table prototype fully developed it was ready for usefulness and usability testing in experiments with health staff in the field.

The second trip to Zomba, Malawi lasted just under a month between 22.10.17 and 18.11.17. During the trip I performed experiments while observing health staff participants going through use-cases I had prepared.

After the experiments, the users were interviewed, and in some cases, there were group discussions and focus groups during these interviews.

When testing the prototype, it is of great value to test it with the users that are supposed to use the finished product. As these users know the context best, they have the biggest possibility to help find unforeseen problems (Dumas & Redish, 1999). When performing both usability and usefulness testing, the observations may sometimes be recorded and then analysed further to create suggestions for later improvement.

Individuals from low income countries may feel uncomfortable when being interviewed by high income countries, using technical devices. To keep the participants as comfortable as possible I refrained from recording the experiments and rather took notes that were later analysed.

Who were the participants?

Table 4.3:Participants table To get hold of health staff participants for

our experiments I had great help from Chipo Kanjo and Tiwonge our Malawi con- tacts from Chanco college in Zomba. Un- fortunately, I was not able to get hold of any health workers who were using the Tracker Capture Android app. But as long as the participants had some experience with software tools before, it would be suf- ficient to get usable results. The experiments all took place in Malawi in or by close range to Zomba.

The Malawian health system have many different groups of health workers who are tending to clients with a range of

different illnesses. CHW’s work mainly with the communities with mostly preventive and informational work, clinicians may do primary care and the

Making data useful to health workers by increasing the usefulness and usability of their tools.

Making data useful to health workers by increasing the usefulness and usability of their

tools

An experiment to increase health workers ability to detect symptoms of

health issues with the District Health Information System (DHIS2) Tracker

Capture Android app

John Melin

Thesis submitted for the degree of

Master in Informatics: Programming and networks 60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

Making data useful to health workers by increasing the

usefulness and usability of their tools

An experiment to increase health workers ability to detect symptoms of

health issues with the DHIS2 Tracker Capture Android app

John Melin

Abstract

Acknowledgement

Contents

Acronyms

List of Figures

List of Tables

Chapter 1

Introduction

1.1 Research context

1.2 Research problem

1.3 Research response

1.4 Research Question

1.5 Structure of Thesis

Chapter 2

Research Context

2.1 Malawi Country Profile

Chapter 3

Background on usability,

usefulness and presentation of data

3.1 Software usability

3.2 Software usefulness

3.3 Presentation to increase data usefulness

3.4 How usefulness and usability can be related in software like the Tracker Capture.

Chapter 4

Research methodology

4.1 Action Research

4.2 The phases of the thesis

4.3 Initial and Phase 1: Initial field trip to Malawi.

Learning about the Domain and defining problem

4.4 Phase 2: Designing and Implementing The His- tory Table prototype, and preparing for experi- ments

4.5 Phase 3: Performing experiments and interviews