Teach Yourself mHealth, Part 1
This post is the first of a three-part series, 'Teach Yourself mHealth.' Here, we focus on what mHealth is and what mHealth projects look like. In Part 2, we'll map out in detail how mHealth can strengthen health information systems. In Part 3, we'll explore some common design challenges that mHealth projects face and review the best online resources for keeping your mHealth knowledge up to speed.
Subscribe by email to get Parts 2 and 3 delivered straight to your Inbox.
Early last year, I became interested in the intersection of mobile phone technology and health information systems, or 'mHealth,' which is short for 'mobile health.' A project I was working on required a high degree of mHealth knowledge in addition to my public health expertise, so I put my time in. I spoke with experts and friends who design and implement mHealth projects in sub-Saharan Africa. I spoke with government ministers who were eager to improve existing health management information systems and NGO coordinators who want to include mHealth in their program scope.
Throughout my discussions, mHealth's mystique as the next big thing gave me the feeling that people want an mHealth project the same way you might want a new hand bag--because it looks good and everyone else has one. To many program people I spoke with, the specifics of what mHealth is--and what it is not--were often unclear.
Without doubt, mHealth and eHealth projects are now a part of the international health landscape. mHealth's ability to strengthen systems is increasingly quantified in peer-reviewed literature and best practices are becoming more standardized by the month.
Despite the ability of technology-based projects to become intimidatingly technical, mHealth knowledge is straightforward and easy to learn. If you work in international health, it's smart to acquaint yourself with the basics, even if you're not interested in including mHealth components in your current project portfolio just yet.
Starting with the Big Picture
Before
we do anything else, it's a good idea to get our terminology
straight and explore what we mean by mHealth in the first place.
eHealth refers to electronic technology that improves or automates a health system. It's the broader category under which mHealth falls.
mHealth refers to health systems that include a mobile component, most often the use of mobile phones. The mobile phone can be the basic indestructible Nokia or a higher-end smart phone. Smart phones and tablets are becoming increasingly available in sub-Saharan Africa, where I work, and so the hardware landscape is constantly changing.
Basic mobile phones send and receive data through SMS text messages, usually sent to a specific number, or shortcode, that the project team arranges with a mobile network provider. Usually, project participants already have mobile phones and there is sufficient mobile network coverage in or near their area to allow them to send and receive text messages on a consistent basis.
It's worth noting that many mHealth project stakeholders--by which I mean the people the project is created to serve--may not be fully literate, may not know how to send and receive SMS, may not be able to charge their phones easily, and may not
have good enough eyesight to read the small screen even if everything else is working (this last lesson from a pilot project in rural Liberia). Using a Human Centered Design approach and some solid common sense can encourage mHealth teams to anticipate these hurdles in the design phase and to keep adjusting and improving during project implementation.
mHealth projects that use smart phones have the distinct advantage of being able to use phone-based applications, or apps, that can gather, send and process mHealth data, behaving like a very small computer. Smart phones that run on open source operating systems, like Android, encourage software developers to create customized mHealth applications that operate from the phone.
Whatever phone is being used ultimately connects to a central server. Some SMS platforms, like EpiSurveyor, have a server online that you access from an Internet browser. Others, like Medic Mobile, run off of a mobile phone connected to a computer. Others are physically installed and need 24-hour electricity and a cool, dry environment. Setting up these servers can be tricky and, depending on the
platform, can require technical expertise. Key mHealth Project Areas
For now, mHealth projects are often communications or information based, used for behavior change communications or to gather health information. Diagnostic applications for mHealth are very cool, like the mobile phone that could scan a blood slide to
test for malaria, but still in pilot phases for the moment and not ready for field use.
Let's look for a moment at these two program focuses of current mHealth projects: communications and information. Obviously, mobile phones are great communication tools and using text messages to send targeted behavior change communications is an obvious application of the technology. Reproductive health messages and other potentially sensitive health messages can be easily adapted to the anonymity of text messages. These projects work especially well when there is two-way communication between the person receiving the message and the system sending it.
Information systems stand to gain a lot from mHealth applications, gathering data for accurate and timely decision-making that can save lives. Community health workers or primary health facilities have huge opportunities, using mHealth technology, to collect information that helps health officials make day-to-day decisions, especially around stock management and disease surveillance. Conversely, mHealth information systems can prompt primary care providers and assist with patient tracking, providing an automated structure for supportive supervision.
Key Players in mHealth Teams
Bringing together a good team, assembled from a diverse range of stakeholders, is key to a mHealth project's long-term success. Including the right people on the project team can help to ensure that the mHealth project meets the needs of its stakeholders and improves, rather than duplicates, existing systems. In addition to a good project coordinator, the following stakeholders are important to include in a mHealth team:
The Ministry of Health is the key stakeholder in mHealth projects, and early buy-in and ongoing Ministry guidance is essential to ensure that the project is owned and operated by Ministry staff in the long-term future.
The mobile network operator, or mobile phone company, is a key player in mHealth projects, especially as they attempt to scale. Demonstrating the value of a private-public partnership to a for-profit company demands both strategy and patience, with a long-term vision of how the mHealth system will go to scale.
Having a good software developer customize and install the SMS platform is obviously crucial, and if at all possible, hiring local developers builds technical capacity in-country and improves sustainability down the road, since you won't need to fly in technical help from someplace else. If you do bring someone in from outside, try to pair them with a local developer who can learn how to maintain the system.
Innovations projects can often feel competitive, and implementing organizations may be reluctant to involve or include sister organizations or NGOs in their design and implementation. I always feel this is a shame, as successful projects require a diverse team, and local NGOs in particular have a lot to offer in terms of specialized local or regional knowledge and of the cultural attitudes that can influence appropriate project design.
When you get right down to it, designing and implementing mHealth projects are no different than designing and implementing good aid projects. The basics, like designing for and with your stakeholders, and planning for long-term sustainability, remain the same no matter what hardware or technological innovations we apply.
In the next post, we'll map
out in detail how mHealth can strengthen communications and information systems. Subscribe by email to get Parts 2 and 3 delivered straight to your Inbox.