Lessons from m-Health Projects: The Tech is the Easy Part

Posted by AnneryanHeatwole on Mar 08, 2011

Adherence reminders, patient data transmission via community health workers, HIV/AIDs info services – mobile phones can be used in a variety of health settings. As mobiles have become cheaper and more easily available around the world, mobile health projects have followed, taking advantage of the devices’ data storage capabilities, information transferring potential, and social networking features.

MobileActive has covered the m-health area extensively as NGOs, aid organizations, and governments continue to launch new projects incorporating ICTs into their work. Organizations like the Praekelt Foundation, which runs multiple mobile health projects, Pesinet, a micro-insurance and community health worker data collection tool, Dimagi, which developed CommCare (a project that helps community health workers promote healthy behaviors in patients), and MoTeCH, a Grameen Foundation project that uses mobiles to send medical advice to pregnant women and young parents along with creating a data managing resource for community health workers, are exploring the potential that mobile technology offers for delivering health care.

Looking at some of these organizations’ experiences, we put together a list of key lessons organizations are learning as they develop m-health projects:

Do The Field Work: Where you launch your project can have a big impact on its chances of success. Do you have local leadership and buy-in from the community you work in? How will you identify your target users and beneficiaries? Can the infrastructure support your project (both with mobile coverage and physical needs like transportation and supply management)? Tim Wood, director of the Mobile Health Innovation department for the Grameen Foundation explains, “You have to look very carefully and make sure the system you’re supporting can handle the demand [...] it’s necessary to do a lot of qualitative studies.”

Know what sort of communication abilities your users have – do they use a different language for speaking than for writing and reading? What sort of phones do they use? How? How do people charge phones? What is their ability to access information or receive it - what are the costs, what are the literacy levels, what are preferred and culturally appropriate ways to reach benficiaries?  Who is left out? What are the mobile operators in your target area and which ones will you use? Do you have the requisite relationships with local leaders, local health providers, operators, and local government agencies?  All of these questions need to be answered before you start developing the project so that you don’t waste time and resources developing an unusable or unsustainable system.

Talk With Beneficiaries From The Beginning: Make sure that your project jives with what the community wants and needs.  Never assume that you know best. Marcha Neethling, head of operations of the Praekelt Foundation, says, “I think in many cases, people design something and you think it’s going to work, but you don’t really have sufficient feedback from the audience from the beginning – it always happens later on in the process when people start using the system and then give you feedback. But I think a lesson would have been to do a lot more user interaction and focus group discussions with potential users before actually launching a service.”

Get out, interview, talk to people, observe, use polls, ask customers and users about what they want, how it should work, what features it should have, and what they like and don’t like. Creating buy-in among local users early on is crucial to the success of an m-Health project, so users need to know that they’re an integral part of the process.

Research Similar Projects: It helps to know what’s been done before. Find out if similar projects have been launched elsewhere, and if so, find out how they worked. Ask what went well, what challenges they faced, and how the organizations worked around those challenges. Anne Roos-Weil, co-founder and managing director of Pesinet writes, “I think one of the key success factors is really to first get a clear view on what kind of players are already involved in healthcare issues and technology issues and start talking to them about ideas to get them to co-design the service with you.” Learning from others can help you avoid repeating mistakes or spending time and money developing processes and systems that already exist or that don't work.

Make Sure You’re Providing Something of Actual Value:
Neal Lesh, chief strategy officer of Dimagi explains, “It’s not a good idea to automate a broken system. There’s a real temptation to get excited and say, ‘Oh, we could solve that with technology!’ but technology is really just a tool and if you have something where there are no human resources, or supervision, or all the incentives are wrong then throwing in that tool isn’t going to make a difference. […] Make sure that the system is relatively easy to use, that it clearly provides some value to the job.” Don’t launch an m-health project just because you can, make sure there’s a demand and need for the service you’re offering.

Build In-Country Partnerships:
If you are an outsider and not a local organization, this seems obvious but you'd be surprised how many do-gooders come in - just because they are privileged, well-resourced, or simply because they can.  A successful project depends on local leadership, ownership, and buy-in. From working with community health workers to doing outreach with potential users, from partnering with local mobile operators to finding collaborating hospitals and health outposts, there are many different people and organizations involved in creating a good project. Look for a local champion, someone who’s excited about deploying systems and wants to work with you to help you navigate the best way to build strong relationships. Technology doesn’t replace human interaction, so reach out to people who can help you make your project succeed.

Set Realistic Timelines: When launching a project, it’s tempting to think that your project will instantly change your beneficiaries’ lives for the better - provided there is real value and you have heeded all of the above.  But there are all sorts of delays that can happen – training takes time, leadership and tech development takes time, infrastructure may need to be adapted, there can be bad weather or political turmoil, lost funding, and user adoption may be slower than you think. There are many ways projects can go wrong in the early stages, so give yourself enough time to adapt.

However, open-ended projects aren’t ideal either; there needs to be some accountability and deadlines for projects so that they don’t limp along without resolution. When developing a timeline, consider how needs and technology may change during the course of your project and be ready to adapt for that. 

Don’t Get Attached To Your Original Design/Idea: Be open to a lot of refinement and changes after the initial design phase. Once you are implementing, evolve and stay agile  – move things around and take out what does not make sense to the users. Ensure that your partnerships allow you to adjust and adapt your tools rapidly as the needs evolve on the ground. Writes Roos-Weil, “Test ideas/functionalities on the future users before going to production and get their insight into the design from the start, or you might need to do it all over again soon.” If you do realize that your initial plan is flawed, be willing to change it to meet local needs rather than forcing people into an inadequate situation. Experience shows that people will not abide by that and simply not use what you cleverly thought up.

Set Realistic Goals: Based on the research and analysis, set clear, concise goals that accurately reflect what you think your project can actually do. Says Lesh, “There’s a massive gap between how community health worker systems are designed to operate and how they actually operate – what works in the US isn’t what works on the ground when it’s deployed. […] Things that look good on paper don’t translate to good projects.” If you think that your project will help mothers in one rural area monitor vaccination schedules, then just start with that region. If you have the money and resources, and your deployment area has the infrastructure to support large-scale projects, then aim for larger user numbers. If your project is funded by grants, how will you make it sustainable over time? If the project isn’t self-sustainable, can you ensure regular funding? How can you keep sustained interest?

Get Regular Feedback/Monitor Your Work: In order to make sure that any system works and that it is actually useful and has health impacts, you need a way to get regular feedback on your work. Feedback can be anything from counting unique hits on a mobile platform (Praekelt’s Young Africa Live), monitoring increases in demand for vaccinations at local health centers after an SMS vaccination reminder was sent out (Grameen Foundation), or tracking increases in the number of users over a period of time (Pesinet). Says Lesh, “I think no matter how good a system is, even if it makes things better and everyone agrees that it’s good for you, it’s really hard to get sustained usage just because it’s a good idea. You really need to have some level of feedback or supervision to reward good behavior and highlight any lack of usage.”  Some of the better-developed projects build in monitoring and evaluations that are formal and thought-through from the get-go – something we strongly encourage.

Think Through The Total Cost of Ownership for both the Project and the Users: Although mobile technology offers many financial advantages (such as increased efficiency for community health workers and cheap communication with large numbers of people) it’s important to think through the total cost of both the launch and the maintenance of any mobile health project. Who will develop the platform? Can you afford to fix the issues that come up during the deployment? Will you provide financial incentives for participants (such as topping up airtime or providing phones)? What will your communication costs look like? Set a flexible but realistic set of budgets that account for more than just the initial costs.

Try To Use Open-Source Solutions: While we are not dogmatic about it, we are proponents of the potential of open source solutions. Re-using code and opening your work to potential collaboration can make your work stronger, more transparent, and the end products better. Neethling explains, “We really believe in collaboration, the possibilities that exist out there. If other people use your technology, don’t make it proprietary or don’t make the licenses so strict that no one else can work on it or improve it.”

Invest in Local Capacity: Try to have things "coded in country", and use technology that is accessible and fixable on location with local talent. Think through in your project how you can build that talent - it is there. By developing systems locally, think through how to work with existing technologies, and develop and draw on local resources, you will support innovation, build stronger buy-in, and make your projects more sustainable. Do keep in mind that it may take time to build capacity, and plan accordingly.

Remember That Technology Isn’t A Panacea:
Find out what the root problems are first and investigate if technology will actually help. Anne Roos-Weil explains that a common problem is people viewing technology as a cure-all for existing problems: “Partners might get interested in the "tech aspect" because it looks innovative and not see the innovation in the business model/service design. It is important to remind them that an m-health program is not about technology, that technology is not the end, it is just a means to create better efficiencies in processes.” Wood seconds this, saying, “The technology is the easy part, the real challenge is the on-ground implementation and management.”

Photo via Flickr user Wayan Vota

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd><p><br> <b><i><blockquote>
  • Lines and paragraphs break automatically.

More information about formatting options