Saving lives with mobile open source

The UN Foundation and the charitable arm of mobile operator Vodafone recently carried out some research into the impact mobile phones are having on developing countries.

The report revealed a lot of anecdotal information about how mobile and wireless technology can improve everything from healthcare to commerce. Specific projects highlighted in the report included a text-messaging service, provided by Oxfam and the Kenyan organisation PeaceNet, to alert NGOs to any violent incidents surrounding recent election-related civil unrest in Kenya.

As well as making use of the connectivity mobile technology offers, in countries where access to PCs is rare the limited computing power of mobile handsets can be put to good use. Set up in 2003 by epidemiologist Joel Selanikio and technologist Rose Donna (formerly of the American Red Cross), the not-for-profit consultancy DataDyne has developed software to enable health workers in developing countries collect data more easily.

DataDyne claims its EpiSurveyor suite, an open-source mobile and PC client that can be used on handheld computers and smartphones, allows health workers to speed up the collection of health data, as they no longer have to rely on paper-based methods. Better data hopefully means an improved chance of tackling health issues more efficiently, potentially saving lives.

EpiSurveyor has now been officially adopted by the World Health Organization (WHO) as a standard for data collection in sub-Saharan Africa and Datadyne is working to make it compatible with an increasing number of more low-end mobile handsets.

ZDNet.co.uk caught up with Selanikio to learn more about the origins of EpiSurveyor and find out his hopes for the long-term potential of the technology to save lives.

Q: It makes a lot of sense to use mobile phones for data collection given the huge numbers of them in circulation, even in developing countries. But how did the idea for EpiSurveyor come about?
A: The genesis of this project goes back about 10 years. I was an epidemiologist working for the US Centers for Disease Control and Prevention and collecting data in the field, including the middle of nowhere like rural Borneo and Haiti. I began thinking about a way to improve the process of collecting information, and [the fact] that there was so much information we needed but didn't have.

At the time I was aware of some data-collection or data-analysis programmes that had been created by public health authorities, all of which I thought were hampered by the fact they were not open source. Although they were created by public entities, their development was essentially monopolised by single organisations for reasons that continue not to be clear to me.

I felt we had some good ideas and those ideas became EpiSurveyor, but it was clear to me then, and it's clear to me now, that we don't have a monopoly when it comes to good ideas for the future of EpiSurveyor. It seems to me the open-source model is really the best way to let people have a vote in the development of the software, and also a way to be able to accept other people's offers of assistance in an easier way than if we were working behind some kind of screen of closed source.

How are you getting the open-source community involved in developing EpiSurveyor?
We are just getting the community involved now, I would say.

My training in college was in sociology with a minor in computer science, so I had a programming background and worked as a programmer and database consultant on Wall Street before I left and decided to go to medical school. I made some tentative steps towards programming Episurveyor myself before I quickly realised that, in the 10 years that I had left programming to pursue my medical training, I was in way over my head. I tried to get some funding from my employer at the time, but I couldn't do it, so the project lay dormant for quite a while.

This was back in 1994/5 and it wasn't really till about 2002 that I began thinking about it again. I applied for a grant from the World Bank...

...and eventually got it, and was able to hire a programmer in the US and, not long after that, I left my job with the government to begin DataDyne in order to pursue projects like EpiSurveyor on a full-time basis.

Right now we have four full-time people, a couple of interns, three contract programmers in Bangalore, and one of our full-time programmers is in Nairobi. We have been getting some help from an organisation in the UK called Aptivate, based in Cambridge, and Cell-Life, which is located in Cape Town, South Africa.

What has the input been like from the wider open-source community?
Well, it is interesting — Cell-Life and Aptivate weren't part of our development team and I didn't know those organisations existed, and then they approached us. In the case of Aptivate, they looked us up and said: "We have been using EpiSurveyor for our HIV programmes in Zambia and we have some programming resources available in case you need some help moving the project along". That was quite exciting for us, as people outside the project were using our software.

And with Cell-Life, they develop open-source software and said: "We think that EpiSurveyor is just the thing for a mobile front end for a project that we are working on, so why don't we work together on some things?" They put in some programming time — particularly towards the development of a Java J2ME version of EpiSurveyor to run on a mobile phone.

So is EpiSurveyor restricted to use on Palm devices at the moment?
Episurveyor is written to run in SuperWaba, which is an open-source super-set of Java that can run on mobile devices. Because we have limited resources, we have spent all our time working on the Palm platform, but it's certainly a frequent request that EpiSurveyor should run on, for example, Windows Mobile.

Since SuperWaba does run on Windows Mobile, from talking to the programming team I understand it's not a big deal to move EpiSurveyor to Windows Mobile — we shouldn't have to re-write the programme at all, apart from the communications aspect: the way in which you transfer a designed form from your desktop to the device and vice versa.

How does EpiSurveyor work? Is there a desktop client and a mobile client?
Yes. On the desktop you have a Java environment running, and that is where you design and create the [health survey] forms. On the Palm platform, you use the Palm synchronisation tool to transfer forms to the device and data from the device.

When it comes to cell phones, that is a whole other interesting topic in terms of methods we will use to transmit forms to the mobile devices and data back from the cell phones. At this point, we are trying to think about how we can create better tools for people who are using EpiSurveyor to manage the survey process.

Imagine if you were in charge of a children's vaccination programme in Thailand, and you had to go out and find out what percentage of children are vaccinated against measles. The only way to do that is to go out and do a vaccination survey. You can imagine, as all the vaccination officers at this point have cell phones, how nice it would be if you could go to a website and see something that looks like the [PC client] local version of EpiSurveyor. You would then be able to create your survey form [online], but then you would have an additional layer within that which would be the user management; you could enter the users, and you could indicate what teams they were on.

You could then distribute that form via SMS or GPRS to the mobile devices of the other people who ought to be out there and participating in the survey. It would just appear, they could accept it and then transmit the data they have collected in exactly the same way. That would be a huge step up from the current process.

That was going to be my next question — how low-end can you go with the actual mobile client? Are you talking about smartphones or any kind of mobile phone?
We are definitely not just talking about smartphones. Even though we are only targeting Palm devices at the moment, it's always been the case that we just don't want to provide software to international organisations with large budgets that can buy $500 (£250) devices. In fact, with the huge rollout we are doing with the WHO in their African regional office, with the assistance of the Vodafone Foundation and The UN Foundation, even that rollout was done based on using the $75 Palm which is the lowest-end unconnected Palm you can get.

There are lot of complications when you start programming for the low-end cell-phone platform, because it is really a stack of different platforms and there is a huge lack of standardisation. I think, over the next five years, we are going to see a tremendous thinning-out of these non-standard platforms, driven by the iPhone platform and a number of others. For the time being...

...we are just creating a basic J2ME implementation; we know it's not going to run on every cell-phone platform, but we are aiming to make sure it runs on some devices that are sub-$100 devices. We will probably come up with a list of 10 devices it's designed to work on, which will include some low-end devices and some high-end.

Have you come up against any handset manufacturers or operators that are not willing to open up their systems or share information for this kind of project?
At the moment we haven't, but it will be interesting to find out in the next year or two if that happens. At the moment, we are aiming to have a field-testable instance of the first J2ME-based version of EpiSurveyor ready for spring. I am not sure what the position of mobile operators and handset manufacturers will be but, if we work with the J2ME standard, there are many phones that are closer to standards than others and will run the J2ME implementation.

So what phase is EpiSurveyor in at the moment — trial phase?
No, it's not in trial phase. It's in its implementation phase and I think the distinction is important. We went through a beta testing phase where the application simply didn't work, but thank heavens for our extremely long-suffering team of beta testers in the Ministry of Health in Kenya, who were able to pore through that software and spot the problems.

Once we had got the major bugs sorted out, we spent a year in Kenya and in Zambia, actually collecting data for public health. During that time we were able to re-work out training materials and hone the software to add the many features that people suggested from actual field use.

We have now moved in our current phase where we are working with WHO, to roll EpiSurveyor out along with mobile devices to regional health officers in sub-Saharan Africa. We have already rolled out to a lot of countries and will do another 10 this year. There are about 40 countries in sub-Saharan Africa and we are not quite to the halfway point.

Is EpiSurveyor the only application of its type out there? There must be proprietary alternatives.
There are other platforms such as Pendragon Forms, and I have used it before, but it is not inexpensive. However, I was using that back in 1997, but almost 10 years later I would still estimate that 95 percent or more of public health data in developing countries is collected on paper. So with EpiSurveyor we were trying to answer the question of why, if these mobile platforms are better than paper and have been around for such a long time, more people aren't using them.

One of the answers is complexity: if you had to program every time you sent an email, how many emails would you send? With public health data collection on these mobile devices, the problem is that commercial platforms are of such a complexity that is above the capability of many public health workers. Pendragon Forms, for example, is not at the level of using Microsoft Word or Excel.

How is EpiSurveyor making a difference right now?
One of the examples I use all the time is Zambia, which is one of our pilot countries for this particular roll-out. In Zambia they have been trying to implement a programme to find out the quality of care being delivered at clinics. They have been trying to do that for years, but again it's very difficult if you collect the data and then it takes six months to enter the data into a computer from your paper forms.

Using a PDA decreases the lag down to a day, from data collection to putting it in the hands of people who can understand it. They have now discovered things such as 40 percent of clinics in Zambia were missing essential malaria treatment medicine.

I think people who have not been involved in field studies don't understand how hard it is to know anything in the developing world: how many kids are attending schools, the HIV prevalence rate; all these different things. Now we have taken a very difficult thing, the actual mechanics of manipulating paper and doing data entry, and made it in an effortless process.

If the team that wants to do data collection doesn't have fuel for the vehicles, then EpiSurveyor is not going to help with that, but it does decrease what I see as the activation energy necessary to go out and collect data. So it's not just improving an old methodology, but they are going out and doing surveys that they simply wouldn't have done before.