Month: November 2009

Mobile meets health on the margins

32 Comments

The timing of this article could not have been better, given the discussions last week on the merits of mobile-based “cloud computing” and the clarification of our position a couple of days later. Despite advances in mobile devices and data connectivity, the need for mobile tools to also be able to work in less than optimal conditions is still as strong and as relevant as ever, as this use of FrontlineSMS by Telecoms Sans Frontiers in Nicaragua shows us all too well.

“TSF – No Bugs In This Software That Fights Disease”
(re-printed with the kind permission of SatNews.com)
November 5th, 2009

“Since the beginning of October, Nicaragua is facing a huge rise of dengue cases, which has become a major public health concern in the country. The Health Ministry of the Central American nation (Minsa) has a crisis unit (SILAIS) which currently focuses its activities in response to both the dengue and H1N1 plagues. An Internet monitoring system has previously been set up to control the health situation in the country; nevertheless access to computer is often difficult in some regions where only few health centers are equipped.

TSF and FrontlineSMS TrainingDue to this serious situation, and the necessity to improve the collection of information, TSF, in collaboration with PATH (an international non-profit organisation that aims at enabling communities worldwide to break longstanding cycle of poor health) is reinforcing SILAIS’ capacities in Information and Communications Technologies.

In order to monitor the spread of the dengue in Managua and to conduct mobile health actions, TSF has been implementing for the first time a very innovative system based on a widespread, cheap and solid technology, GSM.

To set up the program, TSF uses FrontlineSMS software. Developed by a TSF partner NGO, FrontlineSMS is free, open source software that turns a laptop and a mobile phone into a central communications hub. Once installed, the program enables users to send and receive text messages with large groups of people through mobile phones. Thus, GSM technology is used to reach as many geographical zones as possible to control health issues in those areas. The server in SILAIS is connected with the 32 health units in Managua.

Each health unit has been delivered a mobile phone by TSF, so that they can send different kinds of information through SMS to the server. Hospital and health centers fill in predefined forms from their mobile phones and send them by SMS to SILAIS. Designed by PATH and the SILAIS, those forms provide data about the classic and hemorrhagic dengue cases, about the H1N1 2009 ones and the need for medicines when the stock nearly runs out. Once the forms received, the server stores information and puts them in databases in order to facilitate statistical analysis, on Excel format for example.

TSF provides two-way communication to health units enabling SILAIS to receive a daily report and gather messages from the health units and will have an updated situation in each center. At the meanwhile, SILAIS will also be able to communicate important information to them through SMS (such as an alert or a warning about coming meetings for example) or give them automatic answers to predefined questions sent by the health units.

Image courtesy Telecoms Sans Frontiers

By providing communication links between health structures and the SILAIS, TSF will allow the Health Ministry to have more accurate information about the diseases spread within Managua and quickly survey and assess the needs in affected areas. TSF helps health professionals use advanced methodologies such as smart phones and open-source software. Mobile devices are great tools to track and transmit crucial data in order to detect an epidemic threat at an appropriate time. Through this program, TSF participates in strengthening health systems in Nicaragua.

Following the installation of the system, on October 24th, TSF organized training for all the beneficiaries of the project. The health units and SILAIS staff were trained on the application’s functionalities and available services”.

For a related article on FrontlineForms, the FrontlineSMS data collection tool used by TSF for the project, go here.

Our “social mobile” line in the sand

40 Comments

The depth and range of discussion generated by my last post on “the cloud” and “appropriate technology” may have come as something of a surprise, but one thing is clear. There’s a great deal of misunderstanding around the topic, particularly with people who are either developing or promoting tools based on the very technology I was challenging. The only way to avoid this kind of confusion is to spell out our positions clearly, and I made this point in that very same post. So how do we move on from here?

Well, we need to set out our positions clearly as a marker in the sand for future discussion. So, let me go first. To clear up any present and future confusion, here’s the official FrontlineSMS / kiwanja.net position on what I consider five key “mobile tools for development” areas – location in the “long tail”, scaling, replication and growth, open sourcing and access to “the cloud”.

1. Who are your target audience?

Some time ago I butchered Chris Anderson’s “long tail” concept and adapted it for mobile. It seemed like the best way of categorising the different focus areas for mobile tools – high-end for larger organisations down to low-end for small grassroots ones. Here’s what I came up with.

Social Mobile Long Tail, kiwanja.net

The basic rationale behind the diagram is this. Tools in the red area are technically and financially out-of-reach of many grassroots NGOs, many of whom sit in the green space. Tools at the higher end of the graph are generally more complex, server-based systems which require a high degree of technical competence, and often the Internet, to set up and use. Tools in the lower end are simple, low-cost, need few technical skills, work on easily available hardware, don’t require the Internet, and are easy to install and run. Tools in the green space can be quickly adopted and replicated – within hours – whereas tools at the other end need much more planning, i.e. more people and more lead time, and most likely a degree of training.

Note: There is no right or wrong or good or bad place on the tail. There are just different places

From its early beginnings in South Africa in 2004, FrontlineSMS has been totally focused on grassroots NGOs in the green space, an area which I believed back then was heavily underserved (and to a large degree still is). We’re not particularly interested in big users such as international NGOs or government departments. So if our tool isn’t considered right for the kinds of big projects they’re likely to be running, then that’s fine with us.

I wonder where the other social mobile tools would place themselves on the tail?

2. What is your position on scaling?

Believe it or not, not everyone wants to build tools that can grow into large centralised solutions, which is how many people seem to define scale. No one is ever going to run a nationwide election monitoring campaign running into millions of text messages using a single laptop, cable and mobile phone. FrontlineSMS is based on “horizontal scaling”, gained by an increase in the numbers of individual users with their own systems. In other words, a hundred systems in a hundred clinics serving 10,000 people each, rather than one system adapted and “scaled up” to serve a million. We’re happy and comfortable with this approach, as are our target audience of grassroots NGOs.

3. How does it replicate and grow?

Growth is based on patience, and a “pull” rather than “push” approach, i.e. awareness-raising and then letting NGOs decide if they want to try out the tool or not. Those that do then go and request it from the website. Everything is driven by the end user, who needs to be independently motivated to download and use the tool. There is no need for us to be involved at any stage, so no-one flies anywhere and no-one does any training – note that the approaches of FrontlineSMS:Medic and FrontlineSMS:Credit may be different – and no-one tries to “sell” FrontlineSMS to anyone. The solution is designed to allow users to do everything themselves. No core FrontlineSMS implementations are driven by us, and none are our projects. Use is replicated by users sharing experiences, talking about their use of the tool to others, and growing numbers of champions who are either building their own solutions around FrontlineSMS, or bloggers and researchers who write about its use and impact.

4. What is your position on open sourcing?

Again, from the very beginning we have been unashamedly focused on our end user – NGOs in developing countries seeking easy-to-deploy mobile tools. Our end users are not programmers, coders or technical developers, and few if any of our FrontlineSMS user base would have any idea what to do with source code. We decided that we would focus on the open source community once we believed we had something worth working with, and that time is about now. In between working on everything else, we plan to launch a developer community soon. That all said, there are already a number of developers bolting on new functionality to the core FrontlineSMS platform, and 90% of the code is already available online and accessible through SourceForge.

5. Does access to “the cloud” matter?

Cloud image courtesy versacevistas.wordpress.com

FrontlineSMS only came about four years ago because of a critical lack of tools that allowed for group messaging without the need for the Internet. Building a tool which is able to operate in Internet-free zones has therefore been central to our thinking since the very beginning, and continues to this day. Beyond basic messaging, FrontlineSMS can make use of an Internet connection when and where available – messages can be forwarded via email, or posted to websites, for example (that’s the functionality Ushahidi takes advantage of) – but no Internet is not a show stopper for us. And as time moves on and connectivity does improve, we’ll be ready. We’re adding picture messaging in the next couple of months (for example), and other web-based features are in the pipeline. We are not anti-Internet, but realistic when it comes to its availability and reliability.

So, that’s our line in the sand. If anyone else has a mobile tool – or is working on a mobile tool – I’d encourage them to clear up any possible confusion and write a post outlining their thinking in these five areas. The alternative is more confusion, and more false arguments and comparisons.

I know I’d love to know the thinking behind more social mobile tools, and going by the reaction earlier this week, it looks like I’m not the only one. Now is a good-a-time as any to join the conversation.

Read responses and “lines in the sand” from:

FrontlineSMS:Credit
FrontlineSMS:Medic

(As of 20th December, no other mobile tools providers have responded, which is a shame. May the confusion and misrepresentation continue…)

“Inappropriate” appropriate technology?

63 Comments

For some time things have been hotting up in the mobile for development space, and new tools are emerging all the time. But while these solutions extend all the way across the technological spectrum, almost all claim to be “appropriate” in one way or another. Clearly something isn’t right.

An appropriate use of Twitter?

For a while it was “scale”, and then “enabling environments”, and now it seems to be all about “appropriate technology”. I remember studying sustainable development at university, and coming to the conclusion that the term was so widely misunderstood and overused, it had almost become meaningless. I think we’re in danger of having the same thing happen with many of the terms we wildly band around in mobile. Part of the problem is that people are rarely asked to justify their positions or claims, so we never really quite know what anyone means.

In a recent PC World article I wrote, entitled “Appropriate Technology and the Humble Mobile Phone” funnily enough, I broadly defined appropriate technology as “anything that is suited to the environment in which it is used”. There are many factors that need to be considered in deciding how suitable something is – how complex it is to use, whether it can be used largely unaided, whether it can be fixed or maintained locally, how easily it can be localised, whether it can stand the field conditions, and so on.

You could also add to that whether or not the underlying infrastructure is in place for the technology to actually work. Makes sense, no? If we take anything that uses “the cloud“, for example, then I’d argue that it’s largely “inappropriate” unless you’re working in predominantly urban areas or in predominantly ‘developed’ countries. Many of the projects I see are aimed largely at the opposite – developing country and rural. On top of that, many of the areas where I’ve worked have little or no Internet access of any description, and very few people have devices that could access it, even if it was there.

In a recent must-read post – “The sun is shining in Africa” – Miquel provides some compelling arguments as to why “the cloud” is not an appropriate technology for much of the developing world:

The other big point missed in all this Cloud business is how it’s screwing the rest of the world outside of well, the US, and maybe Europe. This is the problem in how when people who proselytize a new technology don’t know understand the underpinnings of it, they often miss big gaping holes in the actual implementation of it

Maybe it’s no coincidence that there’s been a rise in use of “the cloud” and “appropriate technology” terminology at the same time. Let’s just get one thing straight, though. Technologies that use “the cloud” are not bad technologies, just as technologies which base themselves on simple SMS aren’t either. People that build and promote mobile technologies for developing regions just need to be clearer where their target audience are, and base their technology choice on what works – and what’s available – in the places where those people live and work.