Fmfi - User contributions [en]

UWC Telehealth:Project Chapter

2007-11-16T06:40:01Z

Btucker:

{{UWC_Telehealth nav bar}}

'''MUTI telehealth, Canzibe, Eastern Cape Province, South Africa'''

{|
!width="150" align="left"|Researchers:
|William D. Tucker, Xolisa Vuza: University of the Western Cape, South Africa
|-
|width="150" align="left"|
|Andrew Maunder, Marshini Chetty, Gary Marsden and Edwin H. Blake: University of Cape Town, South Africa
|-
|width="150" align="left"|
|Murray Pearson : University of Waikato, New Zealand
|-
|width="150" align="left"|
|Rudi Westerveld: Delft University of Technology, Netherlands
|-
|}

[[Image:image001.jpg|left|thumb|600px|Figure 1: Rural environment in the Eastern Cape of South Africa]]__TOC__
<br clear=all>

==Background to the problem==

For four years we have been iteratively evolving MUTI, a rural telehealth system, for hospitals and clinics in a remote rural part of the Eastern Cape in South Africa, shown in Figure 1 (Chetty, 2005; Chetty et al., 2003, 2004a; Maunder et al., 2006; Vuza, 2006; Vuza & Tucker, 2004). MUTI enables nurses and doctors to use a wireless Internet Protocol-based communication system to conduct patient referrals, request ambulance services, order supplies and generally keep in contact with one another. The primary community-oriented goal was to prevent unnecessary travel by sick patients from the clinic to the hospital, as transportation in these poverty-stricken and geographically dispersed areas is difficult and expensive for the local inhabitants. We hope that the system can enable nurses at the clinic to learn how to treat a wide range of problems locally by consulting with doctors that they normally do not meet or even speak with. We also hope that the system will lessen the workload for doctors at the hospital. As we expected, integrating new technologies into their everyday work lives is not straightforward or easy.

Villages are not centralized, and can spread out for kilometers. Most homes are traditional rondavels, and constructed with a circular mud wall (now mixed with cement) and a thatch roof. Almost no one has electricity or running water. Some homes, do have some solar power. The clinic can be seen in the centre of the picture, behind the rondavels.

We sought and gained the approval of local community leaders and both regional and provincial Department of Health (DoH) managers. However, at the time of project inception, Voice over Internet Protocol (VoIP) was illegal in South Africa. This was overturned by the national regulatory agency, the Independent Communications Authority of South Africa (ICASA) in March 2005. The WiFi network, however, is still legislatively problematic. An umbrella goal of the project is to somehow influence national policy to “open up” these technologies for empowerment of disadvantaged people across the country (Chetty et al., 2006).

The research programme employs a modified Action Research approach (detailed in Section 4) to learn how to develop an appropriate technical system and also to learn how to support the stakeholders to participate in the system’s design and deployment. The technical system copes with the frequent power outages experienced in the remote rural areas and also copes with the fact that the doctors and nurses are so busy they barely have time to use the system. We pay a great deal of attention to the human computer interface with a user-centred development approach (Maunder et al., 2006). For us, the WiFi network is the First Mile, and the human computer interface is the First Inch. We want to learn how to develop a usable and sustainable system that fits into the social context of its usage.

The rest of the chapter is laid out as follows. First we cover related work, from South Africa and internationally, in section 2. Section 3 expresses our research question with a Computer Science-oriented view of Information and Communication Technology for Development (ICT4Dev). We present our Socially Aware Software Engineering approach in section 4, which brings together Action Research and software engineering processes. This section also tells how we employed Outcome Mapping to help with those processes. The iterative cycles of system implementation are presented in section 5, illustrating the parallel path of community engagement and software engineering. Section 6 presents our thoughts on sustainability. Section 7 provides Outcome Mapping-oriented analysis of the project. The final section presents our conclusions in the form of lessons learnt and recommendations for similar ICT4Dev projects.

==Related work==

Telehealth is not new. Nor is the concept of rural telehealth. There are many telehealth systems around the world, both in developed countries, e.g. Hong Kong (Chau & Hu, 2004), and the developing world, e.g. South America (Muñoz et al., 2003) and India (Chandrasekhar & Ghosh, 2001). (Aoki et al., 2003) conducted a study that reviewed the results of 112 telehealth clinical and non-clinical evaluations. They found a majority of the reports used descriptive methods to quantitatively address technical performance, patient satisfaction and diagnostic accuracy. (Aoki et al., 2003) felt that not enough studies focused on clinical effectiveness and cost-effectiveness, and furthermore, that a multi-disciplinary approach is needed to address these issues.

Our interest is more aligned to telehealth systems in developing areas. (Chandrasekhar & Ghosh, 2001) identifies three key areas where these technological systems bring benefits: 1) continuing education for health practitioners, 2) ability to deliver healthcare to remote and poor locations and 3) transparent access to information to “improve the availability and delivery of publicly provided health services”. On the other hand, (Chandrasekhar & Ghosh, 2001) also recognize the difficulties. They characterize the main challenges as: a prevalence of inadequate infrastructure, lack of access to a given telehealth system by most people and the sad case that most of the system users lack the skills to use them appropriately. Thus, we see that the main issues of telehealth systems are both technical and social.

One of the more successful telehealth systems in Africa is the SATELLIFE projects in Uganda (bridges.org, 2003; Sewankambo & Riccio, 2003). This project deployed PDA’s (personal digital assistants, e.g. a Palm pilot) to doctors for mobile use in a) collecting and collating statistics and b) accessing current reference material while on the go. This project illustrates how relatively leading-edge technology can be applied in a digital divide environment, leveraging both technical and social arrangements.

==Research question==

It follows, then, that our research goal is to learn how to balance the technical and social issues in order to provide rural telehealth in our target arena. As Computer Scientists, we have a somewhat natural bias toward deploying and designing only the most advanced technology. In order to prevent that bias from giving birth to yet another “white elephant”, our goal is to learn how to include the social environment of our users, ourselves, and our country in the development process. It is not surprising, then, that we follow the suggestion of(Aoki et al., 2003) and turn to a multi-disciplinary methodology.

==Methodology==

We are deriving an application development method¬ology suited to ICT software development in a developing country environment (Blake & Tucker, 2006a). For the MUTI project, this means targeting underprivileged remote rural areas. Of course there are many technical challenges, but more challenging is understanding and incorporating community needs and social issues. These social implications affect technological choices and development. Throughout this process, we have employed social-oriented data collection methods from Outcome Mapping (Earl et al., 2001).

====Socially Aware Software Engineering====
In order to avoid the technical bias associated with traditional software engineering approaches we are reaching towards a synthesis of several approaches. A bottom-up research approach was chosen to understand and address real community needs. It takes into account the issues related to developing and using software in the community aside from only the technical ones. This process leads to a Socially Aware Software Engineering approach based on a combination of the following:

• User-centred methods taken from the field of Human Computer Interaction (HCI) (Dray et al., 2003)
• Participatory Design methods to ensure that solutions meet user requirements (Davies et al., 2004; Muller et al., 1991)
• Exploratory prototyping methods entail developing a series of prototypes
• Action Research cycles to guide the process of working with actual communities (Avison et al., 1999; Baskerville & Wood-Harper, 1996; Carr & Kemmis, 1991)

Essentially, the socially aware software engineering framework adopted for this project represents a customized version of the Action Research process, with pertinent HCI and participatory design principles included in an iterative prototype development process.

====Outcome Mapping====
Outcome Mapping (Earl et al., 2001) was used as both an evaluation and a data collection methodology. The main steps of Outcome Mapping are Intentional Design, Outcome Performance, followed by Monitoring and Evaluation Planning. These steps were applied cyclically in this project along with the Action Research and software development cycles. The first phase of our Outcome Mapping process was presented in a Masters thesis (Vuza, 2006). We recently revised the Intentional Design and Strategy Maps to fit with the changes encountered in the project. Some illustrative details are presented in section 7.

==Implementation process==

We were introduced to rural telehealth by a fellow FM/FI project in the Eastern Cape (see Meraka telehealth). The CSIR had built a rural WiFi network and installed PCs and VoIP handsets in a hospital, clinic, school and police station (CSIR, 2002). The CSIR’s approach to the technical issues of communication was as follows. First, they used a normal telephone plugged into the IP network for real-time voice communication. Second, a one-way web camera enabled a doctor at the hospital to surf to the webcam at the clinic. Lastly, an email system was deployed for store-and-forward communication. This was abused (because it used a costly GSM connection) and discontinued. Overall, the approach was to use “off the shelf” solutions. Our approach was to build our own solution. We worked with end-users in several long-term iterative cycles, with a particular version of the MUTI system corresponding to each Action Research cycle.

====MUTI v1.0====
We built the first version for the Sulenkama hospital and Tsilitwa clinic in the Qumbu district in 2004 because we observed that the network was frequently down due to power outages, malfunctioning UPS, vandalism, etc. We did not build this network. It was already in situ, built by the CSIR. MUTI v1 provided synchronous voice, and asynchronous text, voice and images. We ran MUTI v1 on laptops (not the PCs installed by the CSIR) chosen to maximise battery life. The user interface was not very user friendly, and made it difficult to train the nurses to use the software. However, even when they did use the software, the doctor hardly ever answered because the laptop (as well as the CSIR PC) was locked up in a room in the hospital. The doctor was alone, and didn’t have the time to answer any calls anyway. That’s why we had hoped they would use the asynchronous (store-and-forward) messaging facility. They used it, but not very often. Near the end of 2004, the CSIR asked us to leave the site so that we could evaluate the two telehealth approaches (theirs and ours) at two different sites, rather than side-by-side at the same site. It was a good suggestion.

[[Image:image003.jpg|right|thumb|Figure 2 Canzibe/Lwandile network diagram]]

This rural wireless network connects Canzibe hospital to Lwandile clinic, roughly 15km apart as the crow flies, but on the road it is more than 30km. The wireless links used enhanced (for longer distances) 802.11b links at 2.4GHz. Because the hilly terrain prevents line-of-sight, we needed to build two intermediate relay stations. All four units use a low voltage WRAP PC routerboard, essentially a “biscuit” PC that runs a Linux operating system There are two more Access Points (APs) connected at each end, creating a hotspot for the mobile laptops and WiFi handsets.

====MUTI v2.0====
Based on the feedback from the Sulenkama/Tsilitwa experience, we continued work on the MUTI system in 2005. First we built our own WiFi network at a new site: Canzibe hospital and Lwandile clinic, in the Libode district (see Figure 2). The network is based on the CRCNet model (http://www.crc.net.nz). The power issues are similar to the first site in that both hospitals have mains power with a backup generator. However, Lwandile clinic is a completely solar site. We also did not experience vandalism to the network relays because we installed them in safe locations. MUTI v2 rounded out the synchronous and asynchronous communication to all three modalities: text, voice and video. The interface was slightly improved, but still was not very easy to learn or use for the nurses (see Figure 3). The doctors, on the other hand, were able to point out numerous deficiencies, but were still able to use the system. Because the clinic has no other form of communication, they used the real-time voice and video functions the most.

[[Image:image005.jpg|right|thumb|Figure 3: MUTI v2 on a laptop with video]]

We chose to deploy the first two versions of MUTI on a laptop, because of long battery life. This picture shows the development team installing and testing out the real-time video component for the first time (hence the camera in the photo!). Later, we learned that the peripherals caused endless hassles, e.g. orienting the webcam to get a good picture, or fumbling with the microphone headset. Users ended up only plugging in the microphone and using the built-in speakers.

====MUTI v3.0====
Based on the feedback from MUTI v2 in 2005 and early 2006, we realized that the nurses were not using the asynchronous functionality purely because of the interface difficulties. The doctors would answer the synchronous calls when they could, but they are also quite busy, and the laptop is just one machine, and lives in one doctor’s office. So we decided to port the store-and-forward portion to a WiFi handset (see Figure 4). This is MUTI v3. The user interface is greatly improved and resembles SMS. The nurses are already familiar with SMS on cell phone handsets, and find the handset much less intimidating than the laptop PC. Power is still a problem, however, in that the handset consumes the battery rapidly when the WiFi is turned on. Our software attempts to manage that by automatically turning it on and off when needed. The handset still functions as a normal GSM phone, and the nurses can either use that, or the MUTI v2 system on the laptop to make a voice call.

The nurses were recently given a GSM cell phone by the DoH. The DoH even convinced the cellular service providers to re-orient a tower so that the clinic gets coverage. Our data shows that the nurses use the MUTI system with VoIP more often than the DoH-provided cell phone. First of all, we can only make this statement because of what the nurses and doctors told us. We do not have access to their cell phone call detail records. Perhaps the nurses are afraid to use the new cell phone because they know that their boss will have access to the call details? Also, so far the only contact the nurses have with the doctors is via MUTI. Thus they are accustomed to contacting the doctors with that system, and not the cell phone.

[[Image:image007.jpg|right|thumb|Figure 4: MUTI v3 on a WiFi-enable GSM cell phone]]

Because of the difficulties with the laptops, we decided to port the MUTI software to a mobile phone handset. Due to technological restrictions (to protect the voice revenues of cellular service providers), we were not able to port the real-time components. However, the store-and-forward functionality was a good fit. Note that all of the peripherals from the laptop (mic, headphone, camera, video and even Bluetooth and WiFi) are all neatly integrated into this leading edge device. Combined with the fact that cell phones are already integrated into everyday rural South African life, the cell phone is an attractive component for the First Inch. The battery life, however, does not compare with the laptop.

==Sustainability \ business models==
We are a research group at a university, and not a commercial enterprise. Our goal is to learn how to make the technologies work in digital divide situations and make the knowledge, and even the software, freely available so that others can take the knowledge and commercialise it. To achieve these ends, we have published widely and have coded the software as “Open Source as possible” . In the best case, we would like to see a local company take up the approach to constructing the networks and deploying the communications software as a business product that can be supplied to the Department of Health, and even to the Department of Education, as hospitals & clinics tend to be co-located with schools.

==User needs application of the OM process==

====Vision and Mission====
The vision can be summarized as follows:
• Enhance rural healthcare provision with ICT
• Develop the system together with healthcare professionals
• Enable a sustainable system

In support of the vision, the programme uses an Socially Aware Software Engineering (see section 4.1) approach to learn how to develop an appropriate technical system and also to learn how to support the stakeholders to participate in the system’s design and deployment. The technical system copes with frequent power outages in remote rural areas and also copes with the severe scheduling demands experienced by the doctors and nurses using the system. Attention to the human computer interface with a user-centred development approach enables us to learn how to develop a usable and sustainable system that fits into the social context of its usage. In addition to targeting doctors and nurses, the programme also targets community leaders and government agencies involved with the target communities.

====Boundary partners and progress markers====
The primary boundary partners are the direct users of the system: doctors and nurses at the hospital, and nurses at the clinic. The progress markers are very similar for all of them. Some examples, according to the Outcome Mapping framework, are listed in Table 1:

{| border="1" cellpadding="7" cellspacing="0"
!align="left" |Boundary Partner
!align="left" |Outcome Challenge
|-
|Doctors and nurses
|To support healthcare professionals to use IP-based communication as a part of their everyday work processes
|}

{| border="1" cellpadding="7" cellspacing="0"
!align="left" |Expect/Like/Love to see
!align="left" |Data collection method
|-
|1. Use MUTI to make real-time calls (laptop)
|MUTI system logs
|-
|2. Make weekly appointment for MUTI meetings
|Check appointment book
|-
|3. Use MUTI to send messages (iMate)
|MUTI system logs
|-
|4. Call TransCape if there are MUTI problems (iMate)
|MUTI system logs
|-
|5. Tell us what they like about MUTI
|Interviews and focus group discussions
|-
|6. Tell us what they do not like about MUTI
|Interviews and focus group discussions
|-
|7. Tell us what we can change to improve MUTI
|Interviews and focus group discussions
|-
|8. Follow up on patients referred to/from the hospital
|OK
|-
|9. Contact doctor for medicine
|MUTI system logs
|-
|10. Contact doctor for lab results
|MUTI system logs
|-
|11. Prefer MUTI rather than cellphone
|MUTI system logs & interviews
|-
|12. Better treatment for patient
|Interviews and focus group discussions
|-
|13. Good relations between nurses and doctors
|Interviews and focus group discussions
|}

Table 1 Progress markers for doctors and nurses

Other boundary partners include:
• clinic managers, based at the District Department of Health offices in Libode. They drive from clinic to clinic (there are 10 around Canzibe hospital, and 3 other hospitals, with about 10 clinics each, in the district).
• Hospital manager, based at Canzibe hospital. She is responsible for the doctors and nurses at the hospital only.
• District level Department of Health, based at Libode. We have met with the CEO, district manager, deputy manager, and the information officer. We also had some brief dealings with the provincial level DoH.
• Support team at Transcape. These were the people on the ground supporting the project while were not in field.
• The research group itself. We want to continually critically reflect on our own behaviour and have our operations externally evaluated, e.g. by bridges.org (Huesler, 2005).
• ICASA, the regulator. We are still not sure how to influence their behaviour with our project (see section 8.9).

====Strategy map====
We chose to prioritize our interaction with the nurses because they were the least familiar with ICT in general. Also, if the nurses did not use the MUTI system, it simply would not be used. The strategy map shown in Table 2 depicts several strategies targeted to the nurses themselves (I-1, I-2 and I-3) and the overall environment (E-1, E-2 and E-3). The strategies are mechanisms to encourage the nurses to use the system more often. We start with trying to get their feedback into the system design process. This is more difficult than it sounds. The nurses are not confident with ICT, and perhaps do not feel that they actually know enough to offer criticism or offer suggestions. In order build confidence, Transcape sends a Xhosa-speaking female to train the nurses on a weekly basis. Her job is to make the technology less intimidating to the nurses. We also try to engage the nurses’ managers about the project but have not been very successful in this regard. Of all of the boundary partners, the clinic managers are the ones we have had the least amount of contact with. We therefore place much of the burden on the doctors to be responsive to the nurses when they do use the system. Then there is a rather large gap in the strategy map as we leap from the users and their managers to the wider environment. The goal is that somehow, the wider environment could exert some influence on the nurses to be more open to participating in the ICT4Dev process. One of those sources would be to have all the technology legalised in the country – a rather tall order.

{| border="1" cellpadding="7" cellspacing="0"
!align="left" |Causal
!align="left" |Persuasive
!align="left" |Supportive
|-
|I-1
|I-2
|I-3
|-
|Paper prototyping exercise to learn how to construct better interfaces
|Train nurses to use software and ICT in general
|Training supplied by local NGO (TransCape) on a weekly basis
|-
|Interviews to get feedback
|SMS the nurses to follow up
|Update management level stakeholders
|-
|E-1
|E-2
|E-3
|-
|Managers make MUTI a part of the job description
|Academic and industry conferences and journals
|Engage Transcape NGO
|-
|ICASA legalizes VoIP and rural WiFi
|Publish information and source code on WWW
|Engage doctors to be responsive
|}

Table 2 Strategy map for the clinic nurses

==Conclusions \ challenges \ next steps==

====System usage====
The MUTI system now offers the capacity to handle a range of communications between the two sites, including text, voice, pictures and video. We find that for the most part, the users prefer to use real-time voice, or VoIP. The second most used function is real-time video. Unfortunately, the nurses rarely use the store-and-forward messaging from MUTI v2. Since we only recently introduced MUTI v3 on the WiFi handhelds, we will have to wait and see what happens with the new First Inch.

====Long term engagement and NGO partnership====
Our approach is to get new research ideas from the participants themselves. We have found that the longer we are involved with the users, the more comfortable they become with the technology, and with us. This enables them to make informed suggestions to us, ones that we can follow up on. An example from MUTI v2 is that the nurses suggested that we provide thumbnails for both voice clips and images in the store-and-forward messages. We picked that up in a paper-prototyping exercise. Other examples include using the system for reporting test results (hospital manager) and improving presence (also from the nurses). As it turns out, however, most of the suggestions come from the local technical support, as they are the ones dealing with the users on a regular basis. This reinforces the need for partnering with an NGO on the ground in the community itself. In our case, Transcape became our surrogate champion because a firm champion did not emerge in the user community. Because the community already trusted Transcape, that trust was extended to us. We would not have built the community’s trust without Transcape or the long-term engagement required to foster that trust.

====Making friends in the community====
Getting to understand the local social environment is very difficult when we are not resident at the site. Nor do most of the research team speak the language. We were very fortunate in 2004-2005 to have a native Xhosa speaker who comes from a similar rural area. The Xhosa-speaking users and boundary partners found it easier to communicate with him. He was also instrumental in pointing out to us the cultural customs, e.g. how to shake hands and grasp your elbow when shaking the hand of a respected elder. We also set aside a significant amount of time to socialise with the foreign doctors, and especially our local support staff. We have become genuine friends. Because of this friendship, we find the information flows very openly.

====Obtaining the support of the next highest power====
We have found the higher power on the chain of boundary partners to be supportive, but distant. We have therefore focussed attention closer to the bottom. We visit with the hospital manager every visit, keeping her posted, and asking her advice. But at the district and provincial levels, we have not been able to get them actively involved. They are, however, receptive to periodic group meetings.

====Continuous assessment and (re)design====
Our methodology is based on iterative cycles. We revise the software on a regular basis, and one can see that embodied through three versions of MUTI thus far. We have revised the OM intentional design recently, and will continue to do so as we learn more about the social and technical aspects of the project. We also chose to have the project externally evaluated by bridges.org (Huesler, 2005).

====Keeping in contact====
We engage with as many boundary partners as possible on every field visit. In addition, we touch base with some boundary partners, especially our support team, the doctors and nurses, with simple SMS and phone calls. Most of them do not have email, although now we are teaching them to use email on the handsets with GPRS.

====Sharing our experiences (good and bad) with the world====
We have also published widely in academic venues: journals (Blake & Tucker, 2006b; Chetty et al., 2006), local conferences (Chetty et al., 2003, 2004b; Maunder et al., 2006; Tucker, 2005; Vuza & Tucker, 2004), international conferences (Chetty et al., 2004a; Tucker, 2004) and Masters theses (Chetty, 2005; Vuza, 2006). We feel it is just as important to publish and share our mistakes as well as our triumphs.

====Experimenting to remain innovative====
As Computer Scientists, we are always trying to push the devices to do more. One example is using state-of-the-art WiFi handsets for MUTI v3. We are striving to do VoIP over WiFi on these handsets. Another example is our use maintenance-free vehicle batteries to power everything. This was an experimental risk that paid off. Our experimentation with the laptops was not successful. The peripheral devices proved to be too complicated for users.

What would it take to complete and stabilise MUTI so that it could be offered as a commercial product? We only recently introduced MUTI v3 into the field. It will take some time and usage to iron out the bugs. Unfortunately, MUTI v3 only handles store-and-forward messaging, not real-time communication. Because of the user interface issues, we would prefer to completely replace MUTI v2 on the laptop. We are currently working on a new underlying engine, and want to completely redesign the interface along the lines of Skype.

====Regulation and policy====
We went through a long process to obtain a test license from ICASA, the South African telecommunications regulator, for our rural WiFi network. The process started in Nov 2004, and was not granted until we were actually en route with the kit in the car in May 2005. It was a temporary license for 3 months, and we were able to extend it another 6 months. We are not able to obtain the long distances with lower power output from the radio cards to comply with ICASA regulations for the 2.4GHz spectrum. When we tried again to get a longer term “research” license, ICASA insisted that we obtain a full private telecommunications network license. We told them we were a research group, had no commercial aspirations, etc. and then just gave up. The people we were dealing with left ICASA, management changed, etc. and it was very difficult to communicate with them. We already had the network in place, and decided it was just too much effort to deal with ICASA’s inconsistencies. We do not have approval for the network now, and that is one of the reasons we are not expanding the network. While we do not feel that ICASA will shut down this network, due to the publicity is would generate. However, the possibility is there at any time.

====Engaging in organizational reflection====
As we are a boundary partner ourselves, we often reflect on how to change our own behaviour. One example is that we now tend to stay longer in the field. This enables us to build stronger bonds with our users and boundary partners. We have also gone through external evaluation to learn how to better incorporate best practise into our research efforts. We are Computer Scientists. We have spent the past several years, using this project as a significant example, learning how to build a methodology that examines ICT within the local South African digital divide context. Just as we revise our software, we also revise our “socially aware” methodology as we gain more experience in the field.

==Acknowledgements==

We are fortunate to have the project funded by several generous donors: the IDRC of Canada, SANPAD of the Netherlands, the Telkom/Cisco/THRIP Centre of Excellence at UWC and the Telkom/Siemens/THRIP Centre of Excellence at UCT. We are also very grateful for the participation of the healthcare professionals at Sulenkama, Tsilitwa, Canzibe, Lwandile and Libode. This work would also not be possible without the help of Transcape, particularly Arjan van der Sar and Thathiswa Masiso.

== References ==

N. Aoki, K. Dunn, K.A. Johnson-Throop and J.P. Turley (2003). Outcomes and Methods in Telemedicine Evaluation. Telemedicine Journal and e-Health, Mary Ann Liebert, Inc., 9(4), 393-401.

D.E. Avison, F. Lau, M.D. Myers and P.A. Nielsen (1999). Action Research. Communications of the ACM, ACM Press, 42(1), 94-97.
R.L. Baskerville and A.T. Wood-Harper (1996). A critical perspective on action research as a method for information systems research. Journal of Information Technology, 11, 235-246.

E.H. Blake and W.D. Tucker (2006a). Socially Aware Software Engineering for the Developing World. Proc. IST-Africa 2006, Pretoria, South Africa.

E.H. Blake and W.D. Tucker (2006b). User Interfaces for Communication Bridges Across the Digital Divide. AI & Society, Springer-Verlag, 20(2), 232-242. bridges.org (2003, February 28). Evaluation of the SATELLIFE PDA Project, 2002: Testing the use of handheld computers for healthcare in Ghana, Uganda, and Kenya. Retrieved Jan 20, 2006

W. Carr and S. Kemmis (1991). Becoming Critical - Education, Knowledge And Action Research. London and Philadelphia: The Falmer Press.
C.P. Chandrasekhar and J. Ghosh (2001). Information and communication technologies and health in low income countries: the potential and the constraints. Bulletin of the World Health Organization, 79, 850-855.

P.Y.K. Chau and P.J.-H. Hu (2004). Technology Implementation for Telemedicine Programs. Communications of the ACM, ACM Press, 47(2), 87-92.
M. Chetty (2005). Developing Locally Relevant Applications for Rural South Africa: A Telemedicine Example (pp. 191). Cape Town, South Africa: University of Cape Town.

M. Chetty, E.H. Blake and E. McPhie (2006). VoIP Deregulation In South Africa: Implications for Underserviced Areas. Telecommunications Policy, Elsevier Ltd., 30(5-6), 332-344.

M. Chetty, W.D. Tucker and E.H. Blake (2003). Using Voice over IP to Bridge the Digital Divide - A Critical Action Research Approach. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2003), George, South Africa, II-291-292.

M. Chetty, W.D. Tucker and E.H. Blake (2004a). Developing Locally Relevant Applications for Rural Areas: A South African Example. Proc. Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists, (SAICSIT 2004), Cape Town, South Africa, 234-239.

M. Chetty, W.D. Tucker and E.H. Blake (2004b). Telemedicine using VoIP combined with a Store and Forward Approach. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2004), Stellenbosch, South Africa, II-53-56.
CSIR (2002). "Tele-Health" application demonstrated over wireless network in Tsilitwa, Eastern Cape. Retrieved Feb 16, 2006, http://www.cda.co.za/Tsilitwa/

R. Davies, S. Marcella, J. McGrenere and B. Purves (2004). The ethnographically informed participatory design of a PD application to support communication. ACM SIGACCESS Accessibility and Computing, ACM Press(77-78), 153-160.

S. Dray, D.A. Siegel and P. Kotze (2003). Indra’s Net: HCI in the developing world. Interactions, ACM Press, 10(2), 28-37.

S. Earl, F. Carden and T. Smutylo (2001). Outcome Mapping: Building Learning and Reflection into Development Programs. Ottawa, Canada: International Development Research Centre.

J. Huesler (2005, Dec 8). An experiment in South Africa to connect computer science research with real community needs and ICT policy-making: Final Report. Evaluation of the Broadband Applications Network Group (BANG) Retrieved Jan 20, 2006, http://www.bridges.org/evaluation/bang/

A. Maunder, G. Marsden and W.D. Tucker (2006). Evaluating the relevance of the ‘Real Access’ criteria as a framework for rural HCI research. Proc. 5th Conference on Human Computer Interaction in Southern Africa, (CHI-SA 2006), Cape Town, South Africa, 75-78.

M.J. Muller, J.L. Blomberg, K.A. Carter, E.A. Dykstra, K.H. Madsen and J. Greenbaum (1991). Participatory Design in Britain and North America: Responses to the Scandinavian Challenge. Proc. ACM SIGCHI Conference on Human Factors in Computing Systems, (CHI ‘91), New Orleans, Louisiana, 389-392.

M.A. Muñoz, M. Rodríguez, J. Favela, A.I. Martinez-Garcia and V.M. González (2003). Context-Aware Mobile Communication in Hospitals. IEEE Computer, 36(9), 38-46.

D.N.K. Sewankambo and R. Riccio (2003). The HealthNet Uganda - SATELLIFE Handheld Computer Project. Proc. ICT Development Forum, Petersberg, Germany.

W.D. Tucker (2004). Connecting Bridges Across the Digital Divide. Proc. 2004 ACM SIGCHI Conference on Human Factors in Computing Systems, (CHI 2004), Vienna, Austria, 1039-1040.

W.D. Tucker (2005). Case study: Internet Protocol-based tele-consultation: A VoIP Project. Proc. VoIP World Africa 2005, Johannesburg, South Africa.
X. Vuza (2006). Social and Technical Issues of IP-Based Multi-Modal Semi-Synchronous Communication: Rural Telehealth Communication in South Africa (pp. 125): University of the Western Cape.

X. Vuza and W.D. Tucker (2004). An IP based Multi-Modal Semi-Synchronous Rural Telehealth Service: Adding Video Messaging and Conferencing to MuTI. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2004), Stellenbosch, South Africa, II-289-290.

2007-07-05T09:02:34Z

2007-07-05T08:16:31Z

Btucker: /* Background */

{{UWC_Telehealth nav bar}}

==Background==
For four years we have been iteratively evolving MUTI, a rural telehealth system, for hospitals and clinics in a remote rural part of the Eastern Cape in South Africa. MUTI enables nurses and doctors to use a wireless Internet Protocol-based communication system to conduct patient referrals, request ambulance services, order supplies and generally keep in contact with one another. The primary community-oriented goal was to prevent unnecessary travel by sick patients from the clinic to the hospital, as transportation in these poverty-stricken and geographically dispersed areas is difficult and expensive for the local inhabitants. We hope that the system can enable nurses at the clinic to learn how to treat a wide range of problems locally by consulting with doctors that they normally do not meet or even speak with. We also hope that the system will lessen the workload for doctors at the hospital. As we expected, integrating new technologies into their everyday work lives is not straightforward or easy.

UWC Telehealth:Project Chapter

2007-07-05T07:59:44Z

Btucker: first load up - not formatted very well, and no pictures either

{{UWC_Telehealth nav bar}}
MUTI chapter

William D. Tucker, Xolisa Vuza, Andrew Maunder, Marshini Chetty, Murray Pearson, Rudi Westerveld and Edwin H. Blake

1.1 Background to the problem
For four years we have been iteratively evolving MUTI, a rural telehealth system, for hospitals and clinics in a remote rural part of the Eastern Cape in South Africa (Chetty, 2005; Chetty et al., 2003, 2004a; Maunder et al., 2006; Vuza, 2006; Vuza & Tucker, 2004). MUTI enables nurses and doctors to use a wireless Internet Protocol-based communication system to conduct patient referrals, request ambulance services, order supplies and generally keep in contact with one another. The primary community-oriented goal was to prevent unnecessary travel by sick patients from the clinic to the hospital, as transportation in these poverty-stricken and geographically dispersed areas is difficult and expensive for the local inhabitants. We hope that the system can enable nurses at the clinic to learn how to treat a wide range of problems locally by consulting with doctors that they normally do not meet or even speak with. We also hope that the system will lessen the workload for doctors at the hospital. As we expected, integrating new technologies into their everyday work lives is not straightforward or easy.

Figure 1 1 Rural environment in the Eastern Cape of South Africa
Villages are not centralized, and can spread out for kilometers. Most homes are traditional rondavels, and constructed with a circular mud wall (now mixed with cement) and a thatch roof. Almost no one has electricity or running water. Some homes, do have some solar power. The clinic can be seen in the centre of the picture, behind the rondavels.

We sought and gained the approval of local community leaders and both regional and provincial Department of Health (DoH) managers. However, at the time of project inception, Voice over Internet Protocol (VoIP) was illegal in South Africa. This was overturned by the national regulatory agency, the Independent Communications Authority of South Africa (ICASA) in March 2005. The WiFi network, however, is still legislatively problematic. An umbrella goal of the project is to somehow influence national policy to “open up” these technologies for empowerment of disadvantaged people across the country (Chetty et al., 2006).

The research programme employs a modified Action Research approach (detailed in Section 1.4) to learn how to develop an appropriate technical system and also to learn how to support the stakeholders to participate in the system’s design and deployment. The technical system copes with the frequent power outages experienced in the remote rural areas and also copes with the fact that the doctors and nurses are so busy they barely have time to use the system. We pay a great deal of attention to the human computer interface with a user-centred development approach (Maunder et al., 2006). For us, the WiFi network is the First Mile, and the human computer interface is the First Inch. We want to learn how to develop a usable and sustainable system that fits into the social context of its usage.

The rest of the chapter is laid out as follows. First we cover related work, from South Africa and internationally, in section 1.2. Section 1.3 expresses our research question with a Computer Science-oriented view of Information and Communication Technology for Development (ICT4Dev). We present our Socially Aware Software Engineering approach in section 1.4, which brings together Action Research and software engineering processes. This section also tells how we employed Outcome Mapping to help with those processes. The iterative cycles of system implementation are presented in section 1.5, illustrating the parallel path of community engagement and software engineering. Section 1.6 presents our thoughts on sustainability. Section 1.7 provides Outcome Mapping-oriented analysis of the project. The final section presents our conclusions in the form of lessons learnt and recommendations for similar ICT4Dev projects.
1.2 Related work
Telehealth is not new. Nor is the concept of rural telehealth. There are many telehealth systems around the world, both in developed countries, e.g. Hong Kong (Chau & Hu, 2004), and the developing world, e.g. South America (Muñoz et al., 2003) and India (Chandrasekhar & Ghosh, 2001). (Aoki et al., 2003) conducted a study that reviewed the results of 112 telehealth clinical and non-clinical evaluations. They found a majority of the reports used descriptive methods to quantitatively address technical performance, patient satisfaction and diagnostic accuracy. (Aoki et al., 2003) felt that not enough studies focused on clinical effectiveness and cost-effectiveness, and furthermore, that a multi-disciplinary approach is needed to address these issues.

Our interest is more aligned to telehealth systems in developing areas. (Chandrasekhar & Ghosh, 2001) identifies three key areas where these technological systems bring benefits: 1) continuing education for health practitioners, 2) ability to deliver healthcare to remote and poor locations and 3) transparent access to information to “improve the availability and delivery of publicly provided health services”. On the other hand, (Chandrasekhar & Ghosh, 2001) also recognize the difficulties. They characterize the main challenges as: a prevalence of inadequate infrastructure, lack of access to a given telehealth system by most people and the sad case that most of the system users lack the skills to use them appropriately. Thus, we see that the main issues of telehealth systems are both technical and social.

One of the more successful telehealth systems in Africa is the SATELLIFE projects in Uganda (bridges.org, 2003; Sewankambo & Riccio, 2003). This project deployed PDA’s (personal digital assistants, e.g. a Palm pilot) to doctors for mobile use in a) collecting and collating statistics and b) accessing current reference material while on the go. This project illustrates how relatively leading-edge technology can be applied in a digital divide environment, leveraging both technical and social arrangements.
1.3 Research question
It follows, then, that our research goal is to learn how to balance the technical and social issues in order to provide rural telehealth in our target arena. As Computer Scientists, we have a somewhat natural bias toward deploying and designing only the most advanced technology. In order to prevent that bias from giving birth to yet another “white elephant”, our goal is to learn how to include the social environment of our users, ourselves, and our country in the development process. It is not surprising, then, that we follow the suggestion of(Aoki et al., 2003) and turn to a multi-disciplinary methodology.
1.4 Methodology
We are deriving an application development method¬ology suited to ICT software development in a developing country environment (Blake & Tucker, 2006a). For the MUTI project, this means targeting underprivileged remote rural areas. Of course there are many technical challenges, but more challenging is understanding and incorporating community needs and social issues. These social implications affect technological choices and development. Throughout this process, we have employed social-oriented data collection methods from Outcome Mapping (Earl et al., 2001).
1.4.1 Socially Aware Software Engineering
In order to avoid the technical bias associated with traditional software engineering approaches we are reaching towards a synthesis of several approaches. A bottom-up research approach was chosen to understand and address real community needs. It takes into account the issues related to developing and using software in the community aside from only the technical ones. This process leads to a Socially Aware Software Engineering approach based on a combination of the following:

• User-centred methods taken from the field of Human Computer Interaction (HCI) (Dray et al., 2003)
• Participatory Design methods to ensure that solutions meet user requirements (Davies et al., 2004; Muller et al., 1991)
• Exploratory prototyping methods entail developing a series of prototypes
• Action Research cycles to guide the process of working with actual communities (Avison et al., 1999; Baskerville & Wood-Harper, 1996; Carr & Kemmis, 1991)

Essentially, the socially aware software engineering framework adopted for this project represents a customized version of the Action Research process, with pertinent HCI and participatory design principles included in an iterative prototype development process.
1.4.2 Outcome Mapping
Outcome Mapping (Earl et al., 2001) was used as both an evaluation and a data collection methodology. The main steps of Outcome Mapping are Intentional Design, Outcome Performance, followed by Monitoring and Evaluation Planning. These steps were applied cyclically in this project along with the Action Research and software development cycles. The first phase of our Outcome Mapping process was presented in a Masters thesis (Vuza, 2006). We recently revised the Intentional Design and Strategy Maps to fit with the changes encountered in the project. Some illustrative details are presented in section 1.7.
1.5 Implementation process
We were introduced to rural telehealth by a fellow FM/FI project in the Eastern Cape (see Chapter ???). The CSIR had built a rural WiFi network and installed PCs and VoIP handsets in a hospital, clinic, school and police station (CSIR, 2002). The CSIR’s approach to the technical issues of communication was as follows. First, they used a normal telephone plugged into the IP network for real-time voice communication. Second, a one-way web camera enabled a doctor at the hospital to surf to the webcam at the clinic. Lastly, an email system was deployed for store-and-forward communication. This was abused (because it used a costly GSM connection) and discontinued. Overall, the approach was to use “off the shelf” solutions. Our approach was to build our own solution. We worked with end-users in several long-term iterative cycles, with a particular version of the MUTI system corresponding to each Action Research cycle.
1.5.1 MUTI v1.0
We built the first version for the Sulenkama hospital and Tsilitwa clinic in the Qumbu district in 2004 because we observed that the network was frequently down due to power outages, malfunctioning UPS, vandalism, etc. We did not build this network. It was already in situ, built by the CSIR. MUTI v1 provided synchronous voice, and asynchronous text, voice and images. We ran MUTI v1 on laptops (not the PCs installed by the CSIR) chosen to maximise battery life. The user interface was not very user friendly, and made it difficult to train the nurses to use the software. However, even when they did use the software, the doctor hardly ever answered because the laptop (as well as the CSIR PC) was locked up in a room in the hospital. The doctor was alone, and didn’t have the time to answer any calls anyway. That’s why we had hoped they would use the asynchronous (store-and-forward) messaging facility. They used it, but not very often. Near the end of 2004, the CSIR asked us to leave the site so that we could evaluate the two telehealth approaches (theirs and ours) at two different sites, rather than side-by-side at the same site. It was a good suggestion.

Figure 1 2 Canzibe/Lwandile network diagram
This rural wireless network connects Canzibe hospital to Lwandile clinic, roughly 15km apart as the crow flies, but on the road it is more than 30km. The wireless links used enhanced (for longer distances) 802.11b links at 2.4GHz. Because the hilly terrain prevents line-of-sight, we needed to build two intermediate relay stations. All four units use a low voltage WRAP PC routerboard, essentially a “biscuit” PC that runs a Linux operating system There are two more Access Points (APs) connected at each end, creating a hotspot for the mobile laptops and WiFi handsets.
1.5.2 MUTI v2.0
Based on the feedback from the Sulenkama/Tsilitwa experience, we continued work on the MUTI system in 2005. First we built our own WiFi network at a new site: Canzibe hospital and Lwandile clinic, in the Libode district (see Figure 1 2). The network is based on the CRCNet model (http://www.crc.net.nz). The power issues are similar to the first site in that both hospitals have mains power with a backup generator. However, Lwandile clinic is a completely solar site. We also did not experience vandalism to the network relays because we installed them in safe locations. MUTI v2 rounded out the synchronous and asynchronous communication to all three modalities: text, voice and video. The interface was slightly improved, but still was not very easy to learn or use for the nurses (see Figure 1 3). The doctors, on the other hand, were able to point out numerous deficiencies, but were still able to use the system. Because the clinic has no other form of communication, they used the real-time voice and video functions the most.

Figure 1 3 MUTI v2 on a laptop with video
We chose to deploy the first two versions of MUTI on a laptop, because of long battery life. This picture shows the development team installing and testing out the real-time video component for the first time (hence the camera in the photo!). Later, we learned that the peripherals caused endless hassles, e.g. orienting the webcam to get a good picture, or fumbling with the microphone headset. Users ended up only plugging in the microphone and using the built-in speakers.
1.5.3 MUTI v3.0
Based on the feedback from MUTI v2 in 2005 and early 2006, we realized that the nurses were not using the asynchronous functionality purely because of the interface difficulties. The doctors would answer the synchronous calls when they could, but they are also quite busy, and the laptop is just one machine, and lives in one doctor’s office. So we decided to port the store-and-forward portion to a WiFi handset (see Figure 1 4). This is MUTI v3. The user interface is greatly improved and resembles SMS. The nurses are already familiar with SMS on cell phone handsets, and find the handset much less intimidating than the laptop PC. Power is still a problem, however, in that the handset consumes the battery rapidly when the WiFi is turned on. Our software attempts to manage that by automatically turning it on and off when needed. The handset still functions as a normal GSM phone, and the nurses can either use that, or the MUTI v2 system on the laptop to make a voice call.

The nurses were recently given a GSM cell phone by the DoH. The DoH even convinced the cellular service providers to re-orient a tower so that the clinic gets coverage. Our data shows that the nurses use the MUTI system with VoIP more often than the DoH-provided cell phone. First of all, we can only make this statement because of what the nurses and doctors told us. We do not have access to their cell phone call detail records. Perhaps the nurses are afraid to use the new cell phone because they know that their boss will have access to the call details? Also, so far the only contact the nurses have with the doctors is via MUTI. Thus they are accustomed to contacting the doctors with that system, and not the cell phone.

Figure 1 4 MUTI v3 on a WiFi-enable GSM cell phone
Because of the difficulties with the laptops, we decided to port the MUTI software to a mobile phone handset. Due to technological restrictions (to protect the voice revenues of cellular service providers), we were not able to port the real-time components. However, the store-and-forward functionality was a good fit. Note that all of the peripherals from the laptop (mic, headphone, camera, video and even Bluetooth and WiFi) are all neatly integrated into this leading edge device. Combined with the fact that cell phones are already integrated into everyday rural South African life, the cell phone is an attractive component for the First Inch. The battery life, however, does not compare with the laptop.
1.6 Sustainability \ business models
We are a research group at a university, and not a commercial enterprise. Our goal is to learn how to make the technologies work in digital divide situations and make the knowledge, and even the software, freely available so that others can take the knowledge and commercialise it. To achieve these ends, we have published widely and have coded the software as “Open Source as possible” . In the best case, we would like to see a local company take up the approach to constructing the networks and deploying the communications software as a business product that can be supplied to the Department of Health, and even to the Department of Education, as hospitals & clinics tend to be co-located with schools.

1.7 User needs – application of the OM process
1.7.1 Vision and Mission
The vision can be summarized as follows:
• Enhance rural healthcare provision with ICT
• Develop the system together with healthcare professionals
• Enable a sustainable system

In support of the vision, the programme uses an Socially Aware Software Engineering (see section 1.4.1) approach to learn how to develop an appropriate technical system and also to learn how to support the stakeholders to participate in the system’s design and deployment. The technical system copes with frequent power outages in remote rural areas and also copes with the severe scheduling demands experienced by the doctors and nurses using the system. Attention to the human computer interface with a user-centred development approach enables us to learn how to develop a usable and sustainable system that fits into the social context of its usage. In addition to targeting doctors and nurses, the programme also targets community leaders and government agencies involved with the target communities.

1.7.2 Boundary partners and progress markers
The primary boundary partners are the direct users of the system: doctors and nurses at the hospital, and nurses at the clinic. The progress markers are very similar for all of them. Some examples, according to the Outcome Mapping framework, are listed in Table 1 1:

Boundary partner Doctors and nurses
Outcome challenge To support healthcare professionals to use IP-based communication as a part of their everyday work processes.
Data collection method
Expect to see:
1. Use MUTI to make real-time calls (laptop) MUTI system logs
2. Make weekly appointment for MUTI meetings Check appointment book
3. Use MUTI to send messages (iMate) MUTI system logs
4. Call TransCape if there are MUTI problems (iMate) MUTI system logs
Like to see:
5. Tell us what they like about MUTI Interviews and focus group discussions
6. Tell us what they do not like about MUTI
7. Tell us what we can change to improve MUTI
8. Follow up on patients referred to/from the hospital OK
9. Contact doctor for medicine MUTI system logs
10. Contact doctor for lab results MUTI system logs
Love to see:
11. Prefer MUTI rather than cellphone MUTI system logs & interviews
12. Better treatment for patient Interviews and focus group discussions
13. Good relations between nurses and doctors
Table 1 1 Progress markers for doctors and nurses

Other boundary partners include:
• clinic managers, based at the District Department of Health offices in Libode. They drive from clinic to clinic (there are 10 around Canzibe hospital, and 3 other hospitals, with about 10 clinics each, in the district).
• Hospital manager, based at Canzibe hospital. She is responsible for the doctors and nurses at the hospital only.
• District level Department of Health, based at Libode. We have met with the CEO, district manager, deputy manager, and the information officer. We also had some brief dealings with the provincial level DoH.
• Support team at Transcape. These were the people on the ground supporting the project while were not in field.
• The research group itself. We want to continually critically reflect on our own behaviour and have our operations externally evaluated, e.g. by bridges.org (Huesler, 2005).
• ICASA, the regulator. We are still not sure how to influence their behaviour with our project (see section 1.8.8).
1.7.3 Strategy map
We chose to prioritize our interaction with the nurses because they were the least familiar with ICT in general. Also, if the nurses did not use the MUTI system, it simply would not be used. The strategy map shown in Table 1 2 depicts several strategies targeted to the nurses themselves (I-1, I-2 and I-3) and the overall environment (E-1, E-2 and E-3). The strategies are mechanisms to encourage the nurses to use the system more often. We start with trying to get their feedback into the system design process. This is more difficult than it sounds. The nurses are not confident with ICT, and perhaps do not feel that they actually know enough to offer criticism or offer suggestions. In order build confidence, Transcape sends a Xhosa-speaking female to train the nurses on a weekly basis. Her job is to make the technology less intimidating to the nurses. We also try to engage the nurses’ managers about the project but have not been very successful in this regard. Of all of the boundary partners, the clinic managers are the ones we have had the least amount of contact with. We therefore place much of the burden on the doctors to be responsive to the nurses when they do use the system. Then there is a rather large gap in the strategy map as we leap from the users and their managers to the wider environment. The goal is that somehow, the wider environment could exert some influence on the nurses to be more open to participating in the ICT4Dev process. One of those sources would be to have all the technology legalised in the country – a rather tall order.

Causal Persuasive Supportive
I-1 I-2 I-3
Paper prototyping exercise to learn how to construct better interfaces Train nurses to use software and ICT in general Training supplied by local NGO (TransCape) on a weekly basis
Interviews to get feedback SMS the nurses to follow up Update management level stakeholders
E-1 E-2 E-3
Managers make MUTI a part of the job description Academic and industry conferences and journals Engage Transcape NGO
ICASA legalizes VoIP and rural WiFi Publish information and source code on WWW Engage doctors to be responsive
Table 1 2 Strategy map for the clinic nurses
1.8 Conclusions \ challenges \ next steps
1.8.1 System usage
The MUTI system now offers the capacity to handle a range of communications between the two sites, including text, voice, pictures and video. We find that for the most part, the users prefer to use real-time voice, or VoIP. The second most used function is real-time video. Unfortunately, the nurses rarely use the store-and-forward messaging from MUTI v2. Since we only recently introduced MUTI v3 on the WiFi handhelds, we will have to wait and see what happens with the new First Inch.
1.8.2 Long term engagement and NGO partnership
Our approach is to get new research ideas from the participants themselves. We have found that the longer we are involved with the users, the more comfortable they become with the technology, and with us. This enables them to make informed suggestions to us, ones that we can follow up on. An example from MUTI v2 is that the nurses suggested that we provide thumbnails for both voice clips and images in the store-and-forward messages. We picked that up in a paper-prototyping exercise. Other examples include using the system for reporting test results (hospital manager) and improving presence (also from the nurses). As it turns out, however, most of the suggestions come from the local technical support, as they are the ones dealing with the users on a regular basis. This reinforces the need for partnering with an NGO on the ground in the community itself. In our case, Transcape became our surrogate champion because a firm champion did not emerge in the user community. Because the community already trusted Transcape, that trust was extended to us. We would not have built the community’s trust without Transcape or the long-term engagement required to foster that trust.
1.8.3 Making friends in the community
Getting to understand the local social environment is very difficult when we are not resident at the site. Nor do most of the research team speak the language. We were very fortunate in 2004-2005 to have a native Xhosa speaker who comes from a similar rural area. The Xhosa-speaking users and boundary partners found it easier to communicate with him. He was also instrumental in pointing out to us the cultural customs, e.g. how to shake hands and grasp your elbow when shaking the hand of a respected elder. We also set aside a significant amount of time to socialise with the foreign doctors, and especially our local support staff. We have become genuine friends. Because of this friendship, we find the information flows very openly.
1.8.4 Obtaining the support of the next highest power
We have found the higher power on the chain of boundary partners to be supportive, but distant. We have therefore focussed attention closer to the bottom. We visit with the hospital manager every visit, keeping her posted, and asking her advice. But at the district and provincial levels, we have not been able to get them actively involved. They are, however, receptive to periodic group meetings.
1.8.5 Continuous assessment and (re)design
Our methodology is based on iterative cycles. We revise the software on a regular basis, and one can see that embodied through three versions of MUTI thus far. We have revised the OM intentional design recently, and will continue to do so as we learn more about the social and technical aspects of the project. We also chose to have the project externally evaluated by bridges.org (Huesler, 2005).
1.8.6 Keeping in contact
We engage with as many boundary partners as possible on every field visit. In addition, we touch base with some boundary partners, especially our support team, the doctors and nurses, with simple SMS and phone calls. Most of them do not have email, although now we are teaching them to use email on the handsets with GPRS.
1.8.7 Sharing our experiences (good and bad) with the world
We have also published widely in academic venues: journals (Blake & Tucker, 2006b; Chetty et al., 2006), local conferences (Chetty et al., 2003, 2004b; Maunder et al., 2006; Tucker, 2005; Vuza & Tucker, 2004), international conferences (Chetty et al., 2004a; Tucker, 2004) and Masters theses (Chetty, 2005; Vuza, 2006). We feel it is just as important to publish and share our mistakes as well as our triumphs.
1.8.8 Experimenting to remain innovative
As Computer Scientists, we are always trying to push the devices to do more. One example is using state-of-the-art WiFi handsets for MUTI v3. We are striving to do VoIP over WiFi on these handsets. Another example is our use maintenance-free vehicle batteries to power everything. This was an experimental risk that paid off. Our experimentation with the laptops was not successful. The peripheral devices proved to be too complicated for users.

What would it take to complete and stabilise MUTI so that it could be offered as a commercial product? We only recently introduced MUTI v3 into the field. It will take some time and usage to iron out the bugs. Unfortunately, MUTI v3 only handles store-and-forward messaging, not real-time communication. Because of the user interface issues, we would prefer to completely replace MUTI v2 on the laptop. We are currently working on a new underlying engine, and want to completely redesign the interface along the lines of Skype.
1.8.9 Regulation and policy
We went through a long process to obtain a test license from ICASA, the South African telecommunications regulator, for our rural WiFi network. The process started in Nov 2004, and was not granted until we were actually en route with the kit in the car in May 2005. It was a temporary license for 3 months, and we were able to extend it another 6 months. We are not able to obtain the long distances with lower power output from the radio cards to comply with ICASA regulations for the 2.4GHz spectrum. When we tried again to get a longer term “research” license, ICASA insisted that we obtain a full private telecommunications network license. We told them we were a research group, had no commercial aspirations, etc. and then just gave up. The people we were dealing with left ICASA, management changed, etc. and it was very difficult to communicate with them. We already had the network in place, and decided it was just too much effort to deal with ICASA’s inconsistencies. We do not have approval for the network now, and that is one of the reasons we are not expanding the network. While we do not feel that ICASA will shut down this network, due to the publicity is would generate. However, the possibility is there at any time.
1.8.10 Engaging in organizational reflection
As we are a boundary partner ourselves, we often reflect on how to change our own behaviour. One example is that we now tend to stay longer in the field. This enables us to build stronger bonds with our users and boundary partners. We have also gone through external evaluation to learn how to better incorporate best practise into our research efforts. We are Computer Scientists. We have spent the past several years, using this project as a significant example, learning how to build a methodology that examines ICT within the local South African digital divide context. Just as we revise our software, we also revise our “socially aware” methodology as we gain more experience in the field.

Acknowledgements
We are fortunate to have the project funded by several generous donors: the IDRC of Canada, SANPAD of the Netherlands, the Telkom/Cisco/THRIP Centre of Excellence at UWC and the Telkom/Siemens/THRIP Centre of Excellence at UCT. We are also very grateful for the participation of the healthcare professionals at Sulenkama, Tsilitwa, Canzibe, Lwandile and Libode. This work would also not be possible without the help of Transcape, particularly Arjan van der Sar and Thathiswa Masiso.

REFERENCES

N. Aoki, K. Dunn, K.A. Johnson-Throop and J.P. Turley (2003). Outcomes and Methods in Telemedicine Evaluation. Telemedicine Journal and e-Health, Mary Ann Liebert, Inc., 9(4), 393-401.
D.E. Avison, F. Lau, M.D. Myers and P.A. Nielsen (1999). Action Research. Communications of the ACM, ACM Press, 42(1), 94-97.
R.L. Baskerville and A.T. Wood-Harper (1996). A critical perspective on action research as a method for information systems research. Journal of Information Technology, 11, 235-246.
E.H. Blake and W.D. Tucker (2006a). Socially Aware Software Engineering for the Developing World. Proc. IST-Africa 2006, Pretoria, South Africa.
E.H. Blake and W.D. Tucker (2006b). User Interfaces for Communication Bridges Across the Digital Divide. AI & Society, Springer-Verlag, 20(2), 232-242.
bridges.org (2003, February 28). Evaluation of the SATELLIFE PDA Project, 2002: Testing the use of handheld computers for healthcare in Ghana, Uganda, and Kenya. Retrieved Jan 20, 2006
W. Carr and S. Kemmis (1991). Becoming Critical - Education, Knowledge And Action Research. London and Philadelphia: The Falmer Press.
C.P. Chandrasekhar and J. Ghosh (2001). Information and communication technologies and health in low income countries: the potential and the constraints. Bulletin of the World Health Organization, 79, 850-855.
P.Y.K. Chau and P.J.-H. Hu (2004). Technology Implementation for Telemedicine Programs. Communications of the ACM, ACM Press, 47(2), 87-92.
M. Chetty (2005). Developing Locally Relevant Applications for Rural South Africa: A Telemedicine Example (pp. 191). Cape Town, South Africa: University of Cape Town.
M. Chetty, E.H. Blake and E. McPhie (2006). VoIP Deregulation In South Africa: Implications for Underserviced Areas. Telecommunications Policy, Elsevier Ltd., 30(5-6), 332-344.
M. Chetty, W.D. Tucker and E.H. Blake (2003). Using Voice over IP to Bridge the Digital Divide - A Critical Action Research Approach. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2003), George, South Africa, II-291-292.
M. Chetty, W.D. Tucker and E.H. Blake (2004a). Developing Locally Relevant Applications for Rural Areas: A South African Example. Proc. Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists, (SAICSIT 2004), Cape Town, South Africa, 234-239.
M. Chetty, W.D. Tucker and E.H. Blake (2004b). Telemedicine using VoIP combined with a Store and Forward Approach. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2004), Stellenbosch, South Africa, II-53-56.
CSIR (2002). "Tele-Health" application demonstrated over wireless network in Tsilitwa, Eastern Cape. Retrieved Feb 16, 2006, http://www.cda.co.za/Tsilitwa/
R. Davies, S. Marcella, J. McGrenere and B. Purves (2004). The ethnographically informed participatory design of a PD application to support communication. ACM SIGACCESS Accessibility and Computing, ACM Press(77-78), 153-160.
S. Dray, D.A. Siegel and P. Kotze (2003). Indra’s Net: HCI in the developing world. Interactions, ACM Press, 10(2), 28-37.
S. Earl, F. Carden and T. Smutylo (2001). Outcome Mapping: Building Learning and Reflection into Development Programs. Ottawa, Canada: International Development Research Centre.
J. Huesler (2005, Dec 8). An experiment in South Africa to connect computer science research with real community needs and ICT policy-making: Final Report. Evaluation of the Broadband Applications Network Group (BANG) Retrieved Jan 20, 2006, http://www.bridges.org/evaluation/bang/
A. Maunder, G. Marsden and W.D. Tucker (2006). Evaluating the relevance of the ‘Real Access’ criteria as a framework for rural HCI research. Proc. 5th Conference on Human Computer Interaction in Southern Africa, (CHI-SA 2006), Cape Town, South Africa, 75-78.
M.J. Muller, J.L. Blomberg, K.A. Carter, E.A. Dykstra, K.H. Madsen and J. Greenbaum (1991). Participatory Design in Britain and North America: Responses to the Scandinavian Challenge. Proc. ACM SIGCHI Conference on Human Factors in Computing Systems, (CHI ‘91), New Orleans, Louisiana, 389-392.
M.A. Muñoz, M. Rodríguez, J. Favela, A.I. Martinez-Garcia and V.M. González (2003). Context-Aware Mobile Communication in Hospitals. IEEE Computer, 36(9), 38-46.
D.N.K. Sewankambo and R. Riccio (2003). The HealthNet Uganda - SATELLIFE Handheld Computer Project. Proc. ICT Development Forum, Petersberg, Germany.
W.D. Tucker (2004). Connecting Bridges Across the Digital Divide. Proc. 2004 ACM SIGCHI Conference on Human Factors in Computing Systems, (CHI 2004), Vienna, Austria, 1039-1040.
W.D. Tucker (2005). Case study: Internet Protocol-based tele-consultation: A VoIP Project. Proc. VoIP World Africa 2005, Johannesburg, South Africa.
X. Vuza (2006). Social and Technical Issues of IP-Based Multi-Modal Semi-Synchronous Communication: Rural Telehealth Communication in South Africa (pp. 125): University of the Western Cape.
X. Vuza and W.D. Tucker (2004). An IP based Multi-Modal Semi-Synchronous Rural Telehealth Service: Adding Video Messaging and Conferencing to MuTI. Proc. South African Telecommunications Networks & Applications Conference, (SATNAC 2004), Stellenbosch, South Africa, II-289-290.