Value-Sensitive Design and Health Care in Africa

346 IEEE TRANSACTIONS ON PROFESSIONAL COMMUNICATION, VOL. 52, NO. 4, DECEMBER 2009

Value-Sensitive Design and Health Care in Africa—REBECCA WALTON AND BRIAN DERENZI

Abstract—In this paper, we describe our approach of using value-sensitive design to guide the design, development,and implementation of health information systems for use in rural areas of two developing countries in Africa. Byusing shared conceptual investigation, we are able to create a generalized list of stakeholders and values that spanmultiple projects without losing any of the power of the conceptual investigation. This process can be applied to otherprojects to develop a stronger set of stakeholders and values. We also present a technical investigation of a vaccinedelivery project in Sub-Saharan Africa and plans for an upcoming empirical investigation for a mobile-phone-basedsupport tool for community health workers in East Africa.

Index Terms—Africa, developing world, health information system (HIS), information and communication technologyfor development (ICTD), mobile phones, rural Africa, value-sensitive design (VSD).

Information and communication technology fordevelopment (ICTD) has been widely hyped asproviding useful tools for improving health care indeveloping countries [1], [2]. Broadly defined, ICTDinvolves using information technologies to supportdevelopment projects in under-resourced countrieswith a goal to enable communities and individualswithin these countries to develop a more equitableand prosperous future [3]. As such, ICTD usuallyinvolves stakeholders from multiple cultures atvarious organizational levels, from internationalagencies to local community members. Thus,many of the important issues of ICTD focusmore on people, their needs, the socioculturalenvironment, and relevant constraints than ontechnological capabilities, though technology is acentral component [4].

Under the broad umbrella of ICTD are informationtools designed to support health care in developingcountries. Known as health information systems(HISs), these tools may encompass a variety oftechnologies from handheld digital devices, laptops,and wireless networks to radios, register books,and paper forms. HISs are commonly used forapplications, such as improving monitoring andevaluation, collecting data, facilitating task shifting,compiling patient records, monitoring logistics,and improving diagnostics [5]–[10]. HISs have beenimplemented in countries, including South Africa[10], [11]; Malaysia [12]; Brazil; Mozambique [8];

Manuscript received September 05, 2008; revised January 13,2009. Current version published November 25, 2009.R. Walton is with the Department of Human Centered Designand Engineering, University of Washington, Seattle, WA 98195USA (email: [email protected]).B. DeRenzi is with the Department of Computer Science andEngineering, University of Washington, Seattle, WA 98195 USA(email: [email protected]).

IEEE 10.1109/TPC.2009.2034075

Tanzania [13]; Uganda [7], [9]; Nicaragua [5]; Peru[6]; and many others.

PROBLEMS IN HEALTH INFORMATION SYSTEMS

Despite the prevalence and great expectationsof HISs in developing countries, many projectshave failed to fulfill project goals, failed to becomesustainable in the long term, failed to successfullyscale from pilot projects, or failed to even reach thepilot stage. Examining the lessons learned fromboth successful and unsuccessful projects canyield themes relevant to HIS design, preventingunnecessary repetition of earlier mistakes andincreasing the chances for successful projectoutcomes.

Lessons learned from numerous projects suggestthat one way to increase chances of success is toincrease incentives for direct stakeholders to usethe system. For example, Lucas describes severalcase histories of ICT for health in developingcountries, concluding with a recommendationto consider the multitude of possible effects onstakeholders, including workload, satisfaction, taskshifting, upskilling, and downskilling, as a way toidentify how to encourage use and support of theHIS [14]. Similarly, Piotti, Chilundo, and Sahayshare several lessons learned for successfullyimplementing HISs in developing countries,emphasizing the need for formal incentives andenforcements to encourage system use [8].

Another major theme in HIS problems is a failureto fully understand and collaborate with relevantstakeholders, a failure which often leads tosustainability problems. Collaboration is crucialto identifying differences in perspectives amongstakeholders—a major factor in ICT projectsuccess [4], [10]. In fact, understandings of“development” among stakeholders was one of themajor themes of the 2007 ICTD conference [15].

0361-1434/$26.00 © 2009 IEEE

WALTON AND DERENZI: VALUE-SENSITIVE DESIGN AND HEALTH CARE IN AFRICA 347

These different understandings can lead to majordisconnects among stakeholders and affect projectsustainability, such as whether a donor continuessupport or whether a government body agrees toexpand a pilot project.

For example, Satellife’s pilot project in Ugandawas temporarily suspended when the Ministry ofHealth (MoH) called for cessation of all activitybecause it had not been adequately consultedabout the project design [9]. This cessation wasrequested even though the MoH had participatedin a stakeholders meeting seven months earlier.Despite several measurable successes (such as near100% reporting rates in participating districts),the MoH as a whole was “unwilling to embracethe program” at its conclusion [9, p. 21], and thepilot project became a catalyst for dialog betweennongovernmental organizations (NGOs), such asSatellife and the MoH, instead of leading to anationwide rollout.

A third problem with HISs is their failure to supporttasks and decision making at the district leveland lower. This failure results in, at best, moreaccurate data being collected and shared up theorganizational hierarchies but having little to noeffect on the quality of health care, especially inrural areas [11], [13], [16].

For example, Williamson and Stoops describe thetwo-year rollout of a nationwide, district-level HISin South Africa, following a three-year pilot project.This project achieved some major successes,such as developing a district-level culture thatvalues information and, therefore, records datamore accurately. However, one of the main goalsfor this project was to support decision makingat the district level—a goal that was not met forseveral reasons, including a lack of training and adisconnect between the way the system presentedinformation and the tasks that district managersand health workers perform [11].

All three problems—(1) need for stakeholderincentives, (2) need for full understanding ofstakeholder perspectives, and (3) need to supportdecision making at the lowest level—reveal a themein HIS design that centers on involving stakeholdersand addressing the values and information needsthat are relevant to them. By investigating valueconceptions relevant to stakeholders, designers canmore fully understand stakeholder perspectivesthat are relevant to HIS design. By designinga system that supports stakeholders’ values,designers can create incentives for use and ensure

support of direct stakeholders at the lowest level ofhealth care—at rural homes and clinics.

VALUE-SENSITIVE DESIGN

To address the above problems, we employedthe value-sensitive design (VSD) approach to twoHIS projects. VSD enables system designers tocomprehensively address values throughout thedesign process by employing a combination of threetypes of investigations: (1) conceptual, (2) empirical,and (3) technical [17].

VSD begins with a conceptual investigation, whichincludes identifying all relevant direct and indirectstakeholders and then examining the key valuesthat are implicated for these stakeholders. Directstakeholders include those who use the informationsystem, for example, in the case of a medicalrecords system, data-entry personnel who put theinformation into the system, as well as doctorsand nurses who look up patient records. Indirectstakeholders include people who are affected bythe information system. To continue the exampleabove, patients themselves would be key indirectstakeholders.

Empirical investigations often extend the workof conceptual investigations. While conceptualinvestigations provide a framework and languagefor talking about values in the design of a system,empirical investigations enable designers todirectly investigate the values of stakeholdersand/or evaluate the success of a particulardesign. Methodology for empirical investigations isincredibly flexible:

The entire range of quantitative andqualitative methods used in social scienceresearch is potentially applicable here,including observations, interviews, surveys,experimental manipulations, collection ofrelevant documents, and measurements of userbehavior and human physiology. [17, p. 351]

The unifying theme of these methods is a focus onidentifying implications of values in systems design.

Technical investigations focus on examining thetechnology choices for information systems design.Certain technical features and approaches morereadily support some values while making othersmore difficult. For example, data-entry systemsthat include solely multiple-choice selectionsrather than open-ended answers support valueslike efficiency more readily than values such ascreativity or precision. Similarly, systems that


track and record use by login name supportaccountability more readily than privacy. Therefore,examining the technical aspects of a system canyield important implications for the support ofstakeholder values.

VSD involves iteratively conducting theseinvestigations, enabling investigations withdifferent types of focus (human versus technology)and levels of focus (broadly conceptual versusspecific) to clarify a variety of design issues.The iterative nature of VSD “checks” the resultsof previous investigations. For example, theVSD process most often begins with conceptualinvestigations in which stakeholders and potentialvalues are identified. The empirical investigationsthat follow should investigate the validity of theproposed values, confirming that they are relevantto stakeholders or identifying different values ofprimary importance. When empirical investigationsidentify new values, designers should conduct asecond iteration of the conceptual investigation,researching and defining these new values toensure that values important to stakeholders shapeupcoming technical investigations and that thesesame values are confirmed in the next iteration ofempirical investigations.

This paper describes two projects to design HISs tosupport public health in Africa, with one projectusing VSD from the early conceptual stages ofproject design and the other project applying VSD toevaluate design before system implementation anduser training. We begin by describing the projectsthemselves. Afterward, we detail a joint conceptualinvestigation. The sections that follow includethe technical investigation of the vaccine deliveryproject and planned empirical investigations for themobile-phone-based support tool, CommCare. Weconclude with implications of this work and visionsfor future research to extend transferability.

PROJECT DESCRIPTIONS

This paper concerns two projects to developHISs that provide value to direct and indirectstakeholders at many levels: health workers andpatients at rural homes and clinics, supervisorsin district- and province-level offices of the MoH,decision makers at the national level of theMoH, and international donors and NGOs thatsupport the development and implementationof these information systems. Each author isdeveloping an HIS to support health in ruralAfrica. The first author is developing an HIS tosupport last-mile vaccine delivery to rural clinics

in two provinces of a country in Sub-SaharanAfrica. This project is a redesign of an existingHIS, with a new focus on supporting tasks anddecision making at the rural-clinic level whilecontinuing to provide appropriate information atother levels of the system. The second author isdeveloping a mobile-phone-based support tool,called CommCare, for community health workers(CHWs) to use in East Africa. CommCare will aidCHWs in treating the patients they see, planningtheir day, and organizing all of the data collected.

Sub-Saharan Africa: Vaccine Delivery The firstproject centers on redesigning an informationsystem to support vaccine delivery and healthworker training/supervision for 251 rural healthclinics in two northern provinces of a country inSub-Saharan Africa. These rural health clinicscover a population of 5.2 million people whowalk an average of five miles to reach the nearesthealth clinic [18]. In a country with an averagelife expectancy of 41 years and a per capita totalhealth expenditure of US$47, the need for basichealth services is great. Yet, delivering medicalsupplies—especially vaccines, which require afunctioning cold chain to maintain a temperature of2 C to 8 C—can cost five times as much for ruralhealth clinics as it does for urban medical facilities[18]. Thus, it is often the rural populations whosuffer the most from a lack of basic health care.

In response to this need, the MoH, a local nonprofitorganization, and an international nonprofitorganization have partnered to deliver vaccines anda few related medical supplies (such as syringesand safety boxes) to all rural health clinics offeringvaccination services in two northern provinces.The MoH provides the medical supplies and fieldcoordinators, most of whom are retired MoHemployees and, therefore, well prepared to offersupportive supervision to isolated health workersat the rural health clinics. The local nonprofitorganization provides the operational oversight ofmonthly deliveries, including drivers and vehicles,and the international nonprofit organizationprovides technical assistance, including thedevelopment of the information system. The firstauthor was hired by this organization to design theHIS, oversee its technical development, install thesystem, and train users. References to this project’sHIS designer refer to her.

The information system facilitates informationflow from rural health clinics to a variety ofstakeholders worldwide. Thus, the HIS designincludes mapping the information flow from health


clinics to stakeholders, selecting information torecord and report, designing report formats andcomputer interfaces, coding the applications,building a new database, producing manualsand help materials, physically implementing thesystem, and conducting training.

Broadly, the HIS is designed to work as follows:During the monthly visits to health clinics,supervisors fill out paper forms, recordinginformation, such as existing, ideal, and deliveredstock amounts; number of children and adultsimmunized; and equipment condition. Supervisorsspend an average of 10–15 days per monthmaking these visits. When they return to theirprovince-level office, supervisors enter the datainto a desktop application and export it to a flashdrive. The flash drive is then delivered to an officewith an internet-connected computer, and the filesare uploaded to a web application. During thisinteraction with the web application, a two-waysynchronization feature ensures consistency ofdata and facilitates any updates to the desktopapplication. Stakeholders can run reports from thedesktop or web applications.

The HIS information flow was mapped and basicsystem components were selected before applyingVSD to this project. After the initial mappingand selection, VSD guided interactions betweendesigners, developers, and direct stakeholders toaffect interface design, technical features, andwording. More information about the influenceof VSD on design is described in the TechnicalInvestigation section.

East Africa: CommCare In rural areas, peopleoften delay seeking care until it is too late or simplydo not seek care at all. For these individuals, thereis a high opportunity cost associated with visitingthe health clinic including: travel to the healthclinic, missing work, food costs, housing costs, andso forth. To address this problem, many groupshave used the community health worker modelto provide health education and screening at thehousehold level [19]. In rural regions of low-incomecountries, CHWs are often in the best position topromote preventive care, ensure safe pregnancy,and monitor population health. To provide effectivecare, however, CHWs need to track a great dealof data about each family and provide a broadrange of health services. They often receive limitedtraining, experience high staff turnover, and receivelimited supervision.

To aid CHWs in this task, we are developing a tool,CommCare, to help support their work. CommCarewill provide support for CHWs to manage ahousehold visit, plan their day, and exploreaggregate data to compare their performance withothers in their country. CommCare will guide theCHW to screen household members for illnessessuch as tuberculosis (TB) or malaria, and provideadvice on living conditions (e.g., safe water practicesor family planning), as well as allow them to registerany births or deaths that have occurred since thelast visit.

To help a CHW plan which houses to visit on anygiven day, CommCare will provide reminders forfollow-up visits that have been generated fromprevious visits. For example, if a member of ahousehold is referred to a health facility for TBscreening, CommCare can direct the CHW to followup on that household after one week to ensure thatthe patient did, in fact, go to the health facilityto get tested for TB. Finally, CHWs will be ableto explore trends in their data and compare theiractivity to those of other CHWs in the district,region, and country. The goal is to help relievefeelings of isolation by providing a social networkwith other CHWs in the area.

CONCEPTUAL INVESTIGATION

We performed a joint conceptual investigationfor these projects, listing direct and indirectstakeholders and identifying key values based onthose stakeholders. This conceptual investigationthen formed the foundation for other investigations:a technical investigation of the vaccine deliveryproject and an empirical investigation plan forCommCare. By selecting relevant values andidentifying the people who affect and are affectedby the HIS, the conceptual investigation framesfuture investigations and aids in prioritizing areasof focus.

We began the conceptual analysis by individuallyidentifying the stakeholders for each projectand then comparing stakeholder lists to identifypatterns. The projects differ in information flow,technologies, and type of HIS used by stakeholders.However, the projects involve very similarorganizations and groups of people, allowing astakeholder pattern to readily emerge. Table I liststhe major stakeholder groups for both projects.

The descriptions below detail each stakeholdergroup for the two projects, with benefits andpotential harms described for each.


TABLE ISHARED DIRECT AND INDIRECT STAKEHOLDERS

Stakeholders for the Vaccine Project

Health Workers: Health workers involved in thisproject provide direct health care in the ruralclinics that provide immunization services in twoprovinces. The benefits to these stakeholdersinclude receiving more helpful and appropriatesupervision and training. For example, ifsupervisors see a pattern of refrigerator problems,they may train health workers in performingmaintenance. Another potential benefit is areduction in delays during supervisor visits. If thenew paper forms are quicker for supervisors tofill out, the health worker may not be delayed aslong in providing patient care during supervisorvisits. Potential harms include the possibility thatincreased data accessibility and reporting mayreveal problems that prompt increased training orpossibly reprimands or negative feedback.

Supervisors: Each supervisor makes monthly visitsto 40–55 rural health clinics to provide supportivesupervision to rural health workers, record dataabout vaccine stocks and use, and deliver vaccines,fuel, and syringes. Supervisors are employees ofthe province-level MoH and are collocated with thelocal NGO. The HIS will enable these supervisors torun reports immediately after data entry, accessingclinic-level feedback, as well as district- andprovince-level aggregated data. These reports canenable supervisors to provide more appropriate anduseful supportive supervision to health workers.The HIS may also simplify data entry by providingmultiple-choice selections for questions instead ofrequiring supervisors to write long answers.

However, the HIS does constrain data entry, forexample, by specifying the order of information,requiring that all questions be answered, andprompting supervisors to enter data for allhealth clinics. These constraints could increasedata-entry time if supervisors consistently skippedquestions with the old system, and the increasedaccountability enabled by this HIS could causediscomfort if it highlights mistakes or problems.

Local NGO: Stakeholders at the local NGO willuse the HIS to run reports that support their ownduties. For example, the province-level managerscan use reports to oversee the performance of theprogram and of the supervisors. The national-levelNGO managers could use reports to support theirfundraising efforts to expand programs. Benefitsof the new HIS include allowing these managersto run their own reports directly, as well as theability to customize reports according to certainparameters and access clinic-level feedback. Themanagers can use this information to supportfund raising and reputation building when theinformation is positive and to evaluate the need forchanges when the information is negative.

Drawbacks of the HIS include the necessityof sharing access and control with severalorganizations, which opens the program to morescrutiny because of increased access to the data.Further, if the increased accountability identifiesproblems with the program, it will require effort toaddress these problems. Ignoring problems will nolonger be easy.

International NGO: The international NGO providestechnical assistance for the vaccine deliveryprogram, as well as monitoring the completenessof uploaded data, raising money to expandprograms, and working with the MoH to implementprograms. Benefits of the HIS for stakeholdersat the international NGO include the ability tocustomize reports according to certain parametersand access clinic-level feedback, as well as district-and province-level aggregated data. Another majorbenefit for these stakeholders is that validationwill occur at the field level by the supervisors whogathered the data at the health clinics. The oldsystem (being replaced by the new HIS) requiresvalidation to occur at the international-NGO levelby stakeholders who do not speak the language inwhich data are recorded and who cannot directlyaccess supervisors to request clarification. Thesefactors make validating data with the old system acomplex, frustrating experience.

The drawbacks of the new HIS are the samefor the international NGO as for the local NGO:Stakeholders must share access and control withseveral organizations, which opens the program tomore scrutiny because of increased access to thedata. Increased accountability is likely to highlightproblems and increase pressure to address them.

Ministry of Health: The MoH managers will use theHIS to run reports and oversee the program from


the perspective of how last-mile vaccine deliveryfits into the nation’s overall health services andstrategy. Similar to the NGOs, the MoH benefitsfrom the new system by directly running its ownreports and customizing these reports according tothe information needed to support its own tasks.This stakeholder group can use the information tosupport decision making, supervision, and resourcedistribution—key components to expanding thevaccine delivery project from two provinces to theentire country. The MoH faces little, if any, potentialharm from the new HIS.

Health Clinic Patients: The first indirect stakeholdergroup includes people who use immunizationservices in the public-health clinics in the twoprovinces involved in this project. The benefits topatients include an increased likelihood of receivingeffective vaccines when they visit the local healthclinic (i.e., after walking an average of five miles,these patients can have their babies immunized,rather than being turned away). The HIS couldprovide this benefit if other stakeholders use thedata to affect stock order quantities, improverefrigerator maintenance, and regulate distributionschedules. Potential harms include the possibilityof waiting longer to be seen by the health worker.If supervisors spend more time training healthworkers during the delivery visits, patients will waitlonger for care during these delivery visits.

It is important to note that the vaccine recordscaptured and shared by the HIS do not includepatient names or other identifying information,and, therefore, patient privacy is fully protected.Vaccine information is recorded along with generalpatient demographics, such as age range and sex,but no names, addresses, or other identifyinginformation are included. The purpose of theHIS is to support better planning, budgeting,ordering, and supervising within the public-healthsystem; thus, recording patient identification isnot necessary and would introduce unnecessarycomplexity to ensure privacy protection.

Financial Donors: The second indirect stakeholdergroup is donors; in other words, the foundationsthat fund this project like it, as do the foundationsand individuals who consider funding futureprojects. This stakeholder group would benefitfrom the new HIS by gaining an improvedunderstanding of program impact and havingincreased information to support decision making.The only potential harm for the financial donor isthat if the donor funds a project that fails, therewill be more proof.

Stakeholders for CommCare

Community Health Workers: The CHW will performhousehold visits and use CommCare to trackfollow-ups and referrals as well as access educationmaterials. The software will allow the health workerto manage data and household visits better. It willalso provide decision support to help the CHWprovide a higher level of care at the household level.However, the CHW will have to learn/master a newtechnology and keep the phone charged. CHWs willneed to work with the system while usability issuesare identified and rectified. Finally, the supervisorswill be able to see what they are doing more easily,causing a loss of autonomy.

Supervisors: The health facilitators (HFs) will beresponsible for supervising the CHWs. Each HF willhave a set of CHWs to supervise. CommCare willhelp the HFs by providing timely household-leveldata that will allow them to more easily managethe CHWs and have a better understanding ofwhat is happening in the field. The CHWs will bemore accountable as a result. CommCare will puta burden on the supervisors since they will be thefirst point of contact for the CHWs in case anythingwith the software or mobile phone goes wrong.

International NGO: The local office of the NGO willbe gathering the data collected by the CHWs tocreate reports for their supervisors back in the US.The more accurate and timely the data, the easier itwill be to compile the required reports. Also, havingthe data in a digital form that is easy to aggregatewill allow the NGO workers to create better reports.

Ministry of Health: The MoH will presumably bereceiving higher-quality data in a more timelymanner. If the pilot project is successful, the MoHcan roll out the software to more districts andregions across the country. One potential harmis that the software, and larger intervention, willpotentially be disruptive to how the national HIS isset up since the software will not initially be tiedto the HIS.

Patients: The people who are being visited by theCHWs will now have their medical informationstored on the mobile device as the CHW comesaround. According to our hypothesis, theseindividuals will benefit from a higher standard ofcare in this case. They will be visited by CHWs whohave more resources at their disposal. However,the data will now be stored in an electronic form,making it easier to copy and distribute. Also, thereis a potential harm for the people who are notvisited by the CHWs using CommCare because they


will hypothetically be receiving a lower standardof care.

Financial Donors: The financial donors will supportthe development of the software and the pilot.If the project succeeds, the financial donors willbe able to use this as good public relations andto claim they have made a positive impact in thelives of thousands of people. If the project fails, thereputation of the financial donor could be at risk.

Values for Stakeholders Identifying stakeholdervalues is one of the key components of aconceptual investigation. This step often beginswith brainstorming potentially relevant values,based on the direct and indirect stakeholders lists,the tasks supported by the information system,the environment in which the system functions,the cultures of the organizations and nationalitiesinvolved, the goals of the new information system,and the identified shortcomings of the approachbeing replaced or upgraded.

In light of these factors, we identified numerouspotentially relevant values:• Respect: For such a wide variety of stakeholders

to share a common system, they must respecteach other and the work each stakeholderperforms.

• Accountability: Actions and responsibilitiesmust be able to be traced to their source toenable problems to be addressed and the systemto continue functioning.

• Human welfare: These projects supportpublic-health applications, which, by definition,improve human welfare.

• Sharing: Numerous stakeholders will sharethe information gathered and reported by theinformation system.

• Autonomy: Stakeholder organizations should beable to directly access and apply the informationgathered by these systems without relying ongatekeeper organizations.

• Empowerment: Stakeholders should be able touse the information system to meet challengesassociated with their tasks.

• Access: Stakeholders should be able to accessthe information relevant to their tasks, regardlessof their location or organization of employment.

• Trust: Stakeholders must be able to trust eachother to feel comfortable sharing the informationsystem and the information itself.

For the first iteration of our conceptualinvestigation, we selected two of the valueson which to focus in depth: (1) respect and

Fig. 1. Power relations in our HIS.

(2) accountability. Our reasoning for thisinitial focus is that the values of respect andaccountability involve every stakeholder group andpresent an opportunity to explore not only theindividual effects and importance of values but alsothe value tensions at the core of complex systemsdesign. Further, the values are directly, rather thanindirectly, related to the HIS itself. For example,human welfare is central to health care, but the HISdoes not perform health care; it supports healthcare. Thus, human welfare is relevant but lesscentral to information system design than directlyrelevant values, such as respect and accountability.As described in our Technical Investigation section,these values did prove central to stakeholders inthe vaccine delivery project. As described in ourEmpirical Investigation section, the second authorwill explore the validity of these values for theCommCare project as part of an iterative VSDapproach.

Respect: After exploring relevant literature[20]–[23], we developed the following definitionof respect to guide the technical and empiricalinvestigations: People respect entities (human andnonhuman) that they believe to possess inherentvalue. Respect includes a feeling of esteem andthe moral discipline to actively benefit or preservethe dignity of the respected entity. Respect is akey component of HIS design, especially in lightof power imbalances inherent within the projectcontexts. Fig. 1 shows these power imbalances.

And in addition to one-way, hierarchicalrelationships, stakeholders also have mutuallydependent relationships. In these relationships,each stakeholder relies on the other stakeholders(up, down, and outside the hierarchy) to performhis or her tasks, since each stakeholder can affectthe others, and all stakeholders share the samehigh-level goal of ensuring that children andadults in rural areas receive proper basic healthcare. The interdependence among stakeholdersmakes respect vital to supporting a functioninginformation system. If stakeholders believe eachother to possess inherent value, they will more


likely make the effort to actively benefit or preservethe dignity of all stakeholders. This effort could takea variety of forms, depending on the stakeholdersinvolved and the cultural context of the interaction.

One way of showing respect in the context of theseprojects is to respect organizational hierarchies.For example, system designers for both projectsoften consulted with higher-level managersand supervisors to gain official sanction beforeapproaching field-level users. The purpose of theseconsultations centered far more on showing respectfor the managers and supervisors than on gainingdirect input to the system design. Thus, showingrespect involves not only respecting individualsbut also the cultural appropriateness of respectingrelevant hierarchies and working within theconstraints associated with these hierarchies.

Accountability: The second key value guiding ourinvestigations is accountability, defined as follows:People or institutions are accountable when theiractions or omissions, either good or bad, can belinked to them. Whether or not consequences canbe enforced, accountability enables responsibleparties to be identified [17], [24]–[26].

The organizational and geographical distributionof system stakeholders makes accountabilityabsolutely necessary to support sustainability ofthe information system. Identifying responsibleparties is complex when those parties mightbe working for the MoH, a local NGO, or aninternational NGO. Even more complex is whensome stakeholders work in the US and somein Africa, some with internet access and somewithout, some using certain components of thesystem, such as mobile phones or paper forms,and others using different components, such aswebsites or desktop applications.

In such a varied and distributed environment, itis vital that actions and omissions be traced tothe source. Otherwise, addressing any problemsor even routine maintenance or training wouldbe impeded (or potentially impossible), and theinformation associated with these projects wouldnot be credible even if it were to make it fromsources to stakeholders. For example, in theCommCare project, if questionable informationsuch as a patient record with a highly unusualcombination of symptoms and past illnesses wererecorded and shared throughout the informationsystem, it would be important to be able to tracethe entries to the health worker who recorded thisinformation and follow up to request confirmation

or additional information to explain the unusualrecord. Similarly, in the vaccine delivery informationsystem, if the vaccine records for a particulardistrict tripled in a short time, it would be importantto trace the increase to the particular health clinicsexperiencing the increase and the health workerskeeping records for those health clinics. In thiscase, accountability would enable an explanation,such as the addition of many new health clinics tothe district or the identification of recording errors,and perhaps the need for particular health workersto be trained in record keeping.

TECHNICAL INVESTIGATION

Based on the aforementioned conceptualinvestigation, the first author performed a technicalinvestigation of the vaccine delivery project toensure that respect and accountability weresupported in the HIS design process and inthe product itself. The actual methodology ofthis investigation involved consciously weighingdecisions—both major and minor—throughout thedesign and development according to the effectson respect and accountability as defined in theconceptual investigation.

For example, one minor decision in this processinvolved determining the best way to allow usersto record why a health clinic was stocked out ofvaccines. One way to make this decision would befor the designer to create a set of multiple-choiceanswers based on his or her own experience orlogic. Another way to address this decision is toanalyze past records and select the most commonreasons as multiple-choice options. A third possibleapproach would be to provide a text box and allowsupervisors to type freeform answers. And a fourthwould be to ask supervisors which answer choicesto display. Each possible approach has differentimplications for respect and accountability.

The approach selected in this case was acombination of all of the above. Analyzing pastrecords provided a reasonable starting list ofpossible answers, while using the designer’sexperience and logic slightly modified the list byidentifying an answer no longer applicable due toproject changes. Having supervisors review thislist and modify it further showed respect for theirexpertise as the stakeholders who have the mostdirect contact with health workers and clinics andare, therefore, most familiar with the causes ofstock outs. Further, by telling supervisors how theoriginal list was developed, we provided an exampleof the usefulness of accountability; in other words,


by tracking their past responses through thesystem, we produced a useful starting list.

Finally, we included a text box for supervisors todescribe any unusual reasons not included in theother choices. The combination of multiple-choiceanswers and a text box shows respect for alldirect stakeholders by supporting (rather thanfrustrating) their tasks. It enables supervisorsto record detailed, accurate answers, which isa concern of theirs, since accountability willenable their answers to be traced to them andsince they will use this information to help healthworkers prevent stock outs in the future. Further,this combination approach respects other directstakeholders who work with aggregated data and,therefore, can more readily aggregate and analyzemultiple-choice answers, especially since many ofthese stakeholders speak a different language thanthe one in which data are recorded.

Although this example suggests that basingdesign decisions on VSD can be complicated ortime consuming, the VSD approach does notalways require significantly more time than moretraditional top-down approaches (and certainlyno more time than related approaches suchas participatory design), but instead it involvesa different type of reasoning when weighingdecisions. Further, we believe the extra time to bewell invested when it results in a system designthat is embraced by stakeholders.

Values in the Design Process The HIS designprocess supported the values of respect andaccountability during interactions among thedesigner, stakeholders, and developers. Spaceconstraints prevent describing every facet of theprocess in detail, but a few detailed examples canillustrate the impact of VSD on the design processand provide a clear picture of how the process itselfsupported respect and accountability.

One of the most important aspects of the designprocess was showing respect for the contributionsof all stakeholders by including as many aspossible in the design process. However, respectingstakeholders by deeply involving them in designwas in tension with respecting stakeholdersby supporting the performance of their regulartasks, since spending time on design could takesignificant time from their job tasks. Thus, thebest way of showing respect to stakeholders duringthe design process was to maximize design inputwhile accommodating their regular daily tasks asmuch as possible. This balance involved building

on previous interactions with supervisors andmanagers at the MoH and local NGO, as well asvisiting them in person to review design decisionstogether. During these visits, several methods wereused to gather information relevant to design andallow for triangulation to support decision making.

When supervisors return from their 10- to 15-daydelivery trips to visit clinics, their first priority istransferring information from the paper forms tothe computer. Thus, we postponed interviews anddesign reviews and began research interactionswith participant observation, observing supervisorsenter data from the old forms into the oldinformation system, noting information, such aserrors in data recorded, per-clinic time requiredto enter data, and relevant environmental factors,such as shared equipment and a lack of desktopspace. This schedule enabled supervisors to gettheir most important work done first and providevaluable benchmarking data for the new design.

It also provided a useful springboard to exploringthe importance of accountability during designreviews. For example, participant observationconfirmed that supervisors frequently leave blanksin the paper forms and, therefore, in the electronicforms that are shared with other stakeholders.The old information system does not supportaccountability by identifying who records electronicdata, nor does it provide any feedback whenstakeholders leave blanks. Thus, the lack ofaccountability for incomplete forms implies a lowpriority for complete information within the sharedsystem.

One of the most striking examples of respect andaccountability in the design process came duringreviews of an interface mockup with the designerand supervisors. This onscreen mockup allowedsupervisors to get a sense of the new interface whilereviewing language choices, ways of answeringquestions, answer choices, question order, and newfeatures such as the inability to skip questions orleave them blank. This last feature required thatthe interface always enable supervisors to indicatethat they cannot answer a particular questionso that they are not forced to guess or make upanswers simply to proceed to the next screen.

One series of stock questions included the answeroption “I don’t know” to enable supervisors toproceed when they do not know the stock levelof certain vaccines or medical supplies. Thesupervisors said that they would never choose theanswer “I don’t know” because their managers at


the local NGO and the MoH would ask them, “Whydon’t you know?” They explained that in English “Idon’t know” may be neutral, but in their language(which is the HIS-interface language used bysupervisors and their managers), it was accusatoryand, in this context, suggests that if they weredoing their job, they would know.

When the designer thanked them for the input andrequested an alternative option, the supervisorssuggested “Does not exist.” The designer explainedthat she was reluctant to use this language becauseit was not exactly true; the answer did exist, butbecause of any number of factors, it could not berecorded. She explained that because many peoplein different organizations will use the new HIS,every answer needs to be explicit.

System users in the international NGO, forexample, can only “see” the health clinics from thedata that supervisors enter into the computer, anda blank is confusing to those who cannot see theclinic for themselves. Blanks could mean manydifferent things to these users, and some userscould think that supervisors left a blank becausethey did not look at the vaccine stock, so they donot know. One supervisor said, “Of course I know;it is my job to know.” And the designer replied thatit is her job to know, too, but she can only knowthrough him and the answers he explicitly recordsin the system. Ambiguities, such as blanks, havemeaning for the supervisors but not for other users.

One supervisor then asked what he should recordif a clinic does not have any stock of a particularvaccine. He asked if he recorded a zero, would otherusers know that it meant there was no vaccine. Andthe designer said yes, it is the only way these userswill know that there was no vaccine. Only explicit,unambiguous answers are useful for system userswho lack the supervisors’ hands-on expertise withthe health clinics.

The designer and supervisors learned from eachother during this exchange. The designer discoveredthat blanks had a specific meaning for supervisors.In the stock questions, a blank indicated a stockout. One of the main goals of the vaccine deliveryproject is to prevent clinics from turning awaypatients who walk an average of five miles to receivevaccinations. Thus, tracking stock outs is animportant purpose of the HIS. It is vital to uncovermiscommunications that mask such importantinformation. Further, during the review of earlierquestions, supervisors had explained that theyleft yes/no questions blank in the current system

if the answer was no. Thus, the designer learnedhow interpretation and meaning differ amongsystem stakeholders—a particularly importantfinding in terms of accountability, as accountabilityis compromised by ambiguity. The supervisorsalso learned during this exchange. They gained abroader perspective of the system and discoveredthe importance of explicitness and accountabilityto the other users sharing the system.

Based on these new understandings, the designerand supervisors agreed upon a replacement for“I don’t know.” When supervisors are unableto answer stock questions, they will select “Notrecorded.” This answer option shows respect tosupervisors by preserving their dignity, unlike “Idon’t know,” which suggests that they did notproperly perform their job. Yet, it also supportsaccountability by explicitly indicating that thisquestion cannot be answered, differentiating thisanswer from “zero” or “no.”

Values in the Product Respect and accountabilityalso affected the HIS product itself, guidingdecisions about technical features and components.Table II identifies several technical featuresof the HIS and how they support respect andaccountability. These technical features wereselected because they most directly support thevalues. Other factors—such as budget, timeframe,existing equipment, and the scope and goals of thevaccine delivery project—also affected technicalfeatures. Thus, respect and accountability stronglyaffected some technical decisions (also in Table II),while other factors determined additional technicalfeatures.

As shown in Table II, technical decisions can haveimportant effects on the values of stakeholders,and seemingly value-neutral decisions, such as thelevel of hardware flexibility the system supports orthe level of data aggregation provided in reports,actually affect whether the stakeholders’ dignity ispreserved (respect) or behaviors can be traced totheir source (accountability).

EMPIRICAL INVESTIGATION

The empirical investigation for CommCare iscurrently in progress. The goal of this empiricalinvestigation is to explore how the theoreticalframework developed during the conceptualinvestigation fits with information from the field.The investigation can be broken down into threephases, described in the following subsections.


TABLE IIRESPECT AND ACCOUNTABILITY IN THE PRODUCT

Phase One: Rapport Building The first phaseis investigative. The goal is to get oriented at thesite and to get to know the stakeholders. Already,informal discussions with the CHWs, supervisors,and NGO workers have been used to gain a betterunderstanding of the information workflow. Wehave also followed CHWs on their day-to-dayactivities in order to gather observational data.

We believe that this first phase of rapport buildingis essential in showing respect to the people weare working with and will lead to much betterfeedback and a better final product in the end. Byestablishing a relationship first, the stakeholderswill be more open in their comments. Previous workby Schwartzman and Parikh has suggested this tobe an important part of the design process [27].

Phase Two: Focused Design The secondphase is a bit more structured. It has includedsemistructured interviews and focus groups,with both the supervisors and CHWs. The focusgroups allowed the stakeholders the chance toverbalize and brainstorm about the future potentialof the CommCare application. A primary goal ofthese focus groups has been to confirm our valuehypotheses and elicit information about how eachgroup views the software. At this time, we are stillin the process of analyzing and collecting data fromfocus groups. As we continue our work, we areplanning to conduct similar focus groups and visitswith clients who are being seen by CHWs. We hopeto incorporate their feedback into designing oursoftware and training practices.

Phase Three: Rapid Iterative Design The thirdphase merges with the start of the technicalinvestigation. Even now as we finish phase two,we have begun to deploy software with limitedfunctionality and are working intensely with asubset of the CHWs to develop a system that willbest help support their work. The software is stillbeing designed and developed while we do thisto use what we are learning from the previousphases. Respecting the suggestions of the CHWs byincorporating their feedback has been vital to thecontinuation of this project.

CONCLUSIONS

This research has identified several conclusionswith implications for future work. First, theconceptual investigation offers value not only forthese specific projects, but potentially for otherHIS development projects in developing countries.Performing a shared conceptual investigationproduced a slightly broader stakeholder groupingand treatment of values, without losing any ofthe power of VSD. The observations were equallyapplicable and useful for each project. The easewith which the project-specific stakeholders andvalues correlated suggests that projects that aresimilar enough in scope and purpose may be ableto build off of previous conceptual investigations.Such repurposing would not only save time inthe design process, but also could contribute toa mesolevel of research highly useful in gaugingresearch transferability and contributing to theorydevelopment in this highly practical field.


Another important take-away from this researchis acknowledging the complexities and tensionsinvolved in working with values. For example,during the HIS-design process for the vaccinedelivery project, showing respect was not astraightforward case of getting as much input aspossible from direct stakeholders. Even duringthe design-review visit, these stakeholders wereresponsible for continuing to perform their jobs, soshowing respect actually required balancing theirability to provide input with getting their regularwork done. This balance involved rescheduling theinterviews and design review after data from therecent delivery had been entered into the computer.Observing this data entry proved serendipitous, asit also provided useful data to guide design.

In addition, important values can inherentlyconflict, such as when showing respectmeans avoiding accusations, while supportingaccountability requires explicitly identifyingresponsible parties. As illustrated in the technicalinvestigation, balancing or resolving these tensionsoften requires deep collaborations in whichstakeholders learn from and about each other.These new understandings can enable a balance oftensions that all stakeholders understand and canagree to support.

A final conclusion involves the future effects of theconceptual investigation on system design for theCommCare project. Because of the importance ofthe value of respect, we have modified our approachto increase time to get to know the stakeholdersand local customs that could affect the CommCareproject. This modification illustrates a direct effectof the conceptual investigation on design—reflectingour intent to respect our collaborators as we designa system together.

We believe that applying VSD to these projects willresult in improved system designs that increasesustainability of these health-care projects inparticular and will, more broadly, inform futureprojects to design sustainable information systemsto support health care in developing countries.

ACKNOWLEDGMENTS

The authors would like to thank the Ministry ofHealth and NGOs that contributed to the vaccinedelivery project, as well as the people at theMillennium Villages Project, Ministry of Health inTanzania, D-Tree International, and the OpenROSAconsortium for their support of this work. Theauthors would also like to thank A. Borning, B.Friedman, and T. Parikh for their contribution tothis work.

REFERENCES

[1] infoDev. (2006, Mar./2007, Oct.). Improving health, connecting people: The role of ICT in the health sector indeveloping countries. [Online]. Available: http://www.infodev.org/en/Publication.84.html

[2] World Bank. (1993, Jun.). World development report 1993: Investing in health. [Online]. Available:http://www-wds.worldbank.org/external/default/WDSContentServer/WDSP/IB/1993/06/01/000009265_3970716142319/Rendered/PDF/multi0page.pdf

[3] United Nations Development Programme, Evaluation Office. (2001). Information communications technologyfor development. Essentials: (5). [Online]. Available: http://www.apdip.net/documents/policy/actionplans/Essentials05092001.pdf

[4] C. Maiers, M. Reynolds, and M. Haselkorn, “Challenges to effective information and communication systemsin humanitarian relief organizations,” presented at the IEEE Prof. Commun. Soc. Conf., Limerick, Ireland,Jul., 10–13, 2005.

[5] W. Avilés, O. Ortega, G. Kuan, J. Coloma, and E. Harris. (2007, Oct.). Integration of informationtechnologies in clinical studies in Nicaragua. Public Library of Science Medicine. [Online]. Available:http://medicine.plosjournals.org/perlserv/?request=get-document&doi=10.1371/journal.pmed.0040291&ct=1#journal-pmed-0040291-sd001

[6] W. H. Curioso, B. Karras, P. Campos, C. Buendía, K. Holmes, and A. M. Kimball, Design and implementationof Cell-PREVEN: A real-time surveillance system for adverse events using cell phones in Peru, in Proc. AMIASymp., 2005, pp. 176–180. [Online]. Available: http://faculty.washington.edu/wcurioso/cellpreven.pdf

[7] A. Mandelli and D. Giusti. (2005, Apr.). Using HMIS for monitoring and planning: The experience of UgandaCatholic Medical Bureau. Health Policy Develop. J. [Online]. Available: http://www.bioline.org.br/pdf?hp05010

[8] B. Piotti, B. Chilundo, and S. Sahay, “An institutional perspective on health sector reforms and the process ofreframing health information systems,” J. Appl. Behav. Sci., vol. 42, no. 1, pp. 91–109, 2006.

[9] Satellife and Uganda Chartered HealthNet, “Uganda health information network project: Final technicalreport,” Watertown, MA, 2004.

[10] J. Braa and C. Hedberg, “The struggle for district-based health information systems in South Africa,” Inf.Soc., vol. 18, no. 2, pp. 113–127, 2002.

[11] L. Williamson and L. Stoops, “Using information for health,” South African Health Rev., pp. 101–116, 2001.[12] H. Leng, “Ownership, control, and contention: Challenges for the future of healthcare in Malaysia,” Soc. Sci.

Med., vol. 66, no. 10, pp. 2145–2156, 2008.


[13] M. Smith, S. Madon, A. Anifalaje, M. Lazarro-Malecela, and E. Michael. (2008). Integrated health informationsystems in Tanzania: Experience and challenges. Electron. J. Inf. Syst. Develop. Countries. [Online]. Available:http://www.ejisdc.org/ojs2/index.php/ejisdc/article/viewFile/395/240

[14] H. Lucas, “Information and communications technology for future health systems in developing countries,”Soc. Sci. Med., vol. 66, no. 10, pp. 2122–2132, 2008.

[15] J. Bussel. (2008). Current issues in information and communication technology and development. InformationTechnology in Developing Countries. [Online]. Available: http://www.iimahd.ernet.in/egov/ifip/feb2008/jennifer-bussell.htm

[16] H. Standing, A. Mushtaque, and R. Chowdhury, “Producing effective knowledge agents in a pluralisticenvironment: What future for community health workers?,” Soc. Sci. Med., vol. 66, no. 10, pp. 2096–2107, 2008.

[17] B. Friedman, P. H. Kahn, Jr., and A. Borning, “Value sensitive design and information systems,” inHuman-Computer Interaction in Management Information Systems: Foundations, P. Zhang and D. Galletta,Eds. Armonk, NY: M. E. Sharpe, 2006, pp. 348–372.

[18] Northern Mozambique Project. (2007). VillageReach. Accessed May 2008. [Online]. Available:http://villagereach.net/where-we-work/mozambique

[19] U. Lehmann and D. Sanders. (2007, Jan.). Community health workers: What do we know about them?WHO Report. Evidence and Information for Policy. Dept. Human Resources for Health, Geneva, SZ. [Online].Available: http://www.who.int/hrh/documents/community_health_workers.pdf

[20] P. Bourgois, In Search of Respect: Selling Crack in El Barrio. Cambridge, UK: Cambridge Univ. Press, 1995.[21] H. Frankfurt, Necessity, Volition and Love. New York: Cambridge Univ. Press, 1999.[22] D. Pepper, F. Webster, and G. Revill, Environmentalism: Critical Concepts. London, UK: Routledge, 2003.[23] J. Raz, Value, Respect, and Attachment. Cambridge, UK: Cambridge Univ. Press, 2001.[24] G. Williams. (2006). Responsibility. The Internet Encyclopedia of Philosophy. [Online]. Available:

http://www.iep.utm.edu/r/responsi.htm#H2[25] T. Honderich, Ed., The Oxford Companion to Philosophy. Oxford, UK: Oxford Univ. Press, 1995.[26] Dictionary.com. (2009). Accountable. [Online]. Available: http://dictionary.reference.com/

search?q=accountable[27] Y. Schwartzman and T. S. Parikh, “Establishing relationships for designing rural information systems,” in

CHI’07 Extended Abstracts on Human Factors in Computing Systems, 2007, pp. 1845–1850.

Rebecca Walton is currently pursuing the Ph.D. degree in the Department of Human Centered Design and Engineering at the

University of Washington, Seattle. Her research interests involve information and communication technology for development,

particularly information systems design and project management. She has designed and conducted research in Africa, Central Asia,

South America, and the US. Her research experience involves information and communication technology for development projects

to support public health, microfinance, and emergency logistics.

Brian DeRenzi received the B.S. degree in Computer Engineering from the University of California, Santa Barbara, and the M.S.

degree in Computer Science from the University of Washington, Seattle, where he is currently pursuing the Ph.D. degree in

Computer Science and Engineering. His research focuses on designing and deploying appropriate and sustainable technologies

for health-care workers in low-income countries. He is currently focusing on building mobile-phone applications to support

community health workers in East Africa.

Documents

Value-Sensitive Design and Health Care in Africa