Technology Decisions

You are now ready to scope out the technology specifications of your mHealth solution. If you are a typical health program implementer, this might be uncharted territory. However, you do not have to become a technology expert to describe what you need. Learning a few basics—as outlined in Table 1 below—will help you make key project decisions and articulate your technology needs.

Table 1 includes an exhaustive list of considerations; you are not expected to know all of the answers as you work through each topic. There is no scripted path, and the decisions made depend entirely on the intended functionality of the technology and the environment in which it will operate.

We recommend that you create a document that captures your technology requirements. This document will ultimately guide the technology development process, whether you are building it in-house or with outside expertise. A helpful exercise is to write down everything that you “wish” the technology could do, and then go back and identify which functionalities are “must have” versus “nice to have” and "not needed." The Guide's Technology Decisions Worksheet (PDFWord) will help you complete this task.

Your program's capacity needs and budget for technology costs will serve as important reality checks as to the feasibility of delivering on your proposed technology requirements. These topics warrant additional consideration, the guidance for which is available on these pages: 

We encourage you to connect with the collaborative mHealth community of health program staff and technologists—both in your country and globally—to help you navigate your range of options and to understand the terminology (see the Resources Section for more information on these existing Networks and Communities of Practice). Also consult with your internal information technology (IT) team, if you have one; if not, an outside consultant can provide valuable support.

Additionally, the Planning an Information System: A Toolkit for Public Health Managers, developed by WHO and PATH, is a valuable reference guide to supplement the advice provided in Table 1 below. While the focus of the toolkit is on information systems, much of the guidance is tranferable to mHealth programs.

Table 1. Key topics and considerations for developing a comprehensive scope for your technology needs












TOPICS

KEY CONSIDERATIONS

Core Functionality

 

 

 

 

 

 

 

 

 

 

 

Describe the core functions that the technology needs to perform, focusing on the experience of the end user.

  • Describe the user journey, from beginning to end. What is the user expected to do? What is the technology expected to do? 
  • What communication format will be used (for example, short message service (SMS), multimedia messaging service (MMS), interactive voice response (IVR), video, voice, survey, forms, web, general packet radio service (GPRS)? Confirm that the format aligns with your formative research results, and is practical given the context of the program setting.
  • How will the user access the program? For example, does the user have to opt in to use the service, is it pre-loaded on the mobile device, or does it need to be downloaded? 
  • Will the application involve one-way communication or two-way interaction between the program and the end user?
  • How often does the mHealth program interact with the user, and vice versa (daily, weekly, or monthly)?
  • In which languages will the program be available?
  • If a user wishes to discontinue the program, how will the user disable the application?
  • What will a user do if he or she needs help? Will there be a customer service line or a point person to help with questions?

Data Analytics, Storage, & Availability

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Mobile platforms have the capability to collect and store data, often in real time, which is unprecedented data functionality for the public health field. When designing an mHealth program, one must think through the data needs of the program and further understand if and how a mobile platform could collect that information. Some key considerations include:

  • What are the key performance indicators for the project, and how will the program measure success? How can user data be used to report on the key performance indicators? Refer to the Logic Model and Data Collection, Monitoring & Evaluation pages for more information.
  • What are the standard reports that you want the program to generate?
  • At what interval does data need to be available (real time, weekly, monthly), and to whom? Consider how will the data be transmitted, and whether there needs to be a back-up plan.
  • How will data be stored and accessed? What are the hosting options? Consider whether web-enabled databases are appropriate (for example, with data sets available to researchers via a login).
  • What volume of records will need to be stored? How will data be backed up?
  • In what format will the data be available? Consider a format that facilitates analysis, and consult with researchers if necessary to determine the appropriate format.
  • Will the program need a data dashboard? If so, who is the audience, and what are the specifications?
  • How will data needs change over time, especially if the program is intended to reach significant scale?
  • Who owns the data generated by the mobile application?
  • How will the data be managed? Who will be responsible for managing the data? Refer to Project Management for more information.

Security, Hosting, & Privacy

 

 

 

Data—especially health information about patients—must be handled with care to protect human rights and personal safety. Data security, hosting, and privacy are serious issues to grapple with. Consider how to find and maintain robust and secure hosting. Patient privacy laws vary by country and will likely affect your data collection plans and systems. To understand mHealth privacy and legal issues, get in touch with mHealth experts who can help (see Networks under Resources). For more guidance, refer to the mHealth Alliance’s June 2013 report titled, Patient Privacy in a Mobile World: A Framework to Address Privacy Law Issues in Mobile Health.

Mobile Delivery Platform

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A service delivery platform is a set of components that enable a service to be deployed and integrated with the mobile telecommunications network. Essentially, it is what allows a service to operate. Based on your technology requirements, you will need to identify which platform best suits your technology needs and organizational capacity. Note that there are existing platforms available, such as CommCare, DataDyne, DataWinners, FrontlineSMS, and RapidSMS. Some are open source downloads which may or may not require programming to fit your needs; others are online services with limited customization capabilities. After reviewing available solutions, you might determine that you need a customized platform to be built to meet your specific requirements. Example exploratory questions include: 

  • What existing open source tools can be used, if any? Consider the pros and cons of each option, mapping your technology requirements to the capabilities of the platforms. Also understand the programming needs, the level of ongoing support available for each option, and the costs.
  • Identify how the technology will be enabled in the mobile telecom environment. Will it work across different mobile network operators (MNOs)? What partnerships need to be developed to activate the service (for example, partnerships with aggregators, MNOs, mobile gateway providers)?
  • Consider how the platform will be able to adapt to changes and advances in technology.
  • Based on the platform, will the project need new or additional computers or a server to run the program?
  • Consider issues around interoperability and lisencing. Both topics are addressed in more detail below. 

Table 4.1 of the Planning an Information Systems Project: A Toolkit for Public Health Managers provides a detailed breakdown of the benefits and risks of working with different software models. (Copyright © 2013 World Health Organization (WHO), Program for Appropriate Technology in Health (PATH). All rights reserved.) 


Some of the questions listed here were also addressed in the Landscape Analysis.

Monitoring & Maintenance

 

 

How will the technology be monitored and maintained over time? What kind of capacity will keep technology functioning as expected, and systems updated appropriately? (See Capacity Needs, as well as the Project Management and Partnership Development pages).

User Considerations—Hardware, Equipment, & Power, and Connectivity Needs

 

 

 

 

 

 

 

 

 

 

 

 

In addition to getting an effective platform in place, you will need to think through other elements that affect the user’s ability to use the technology reliably and consistently. These considerations include hardware, connectivity, and power needs. For example:

  • Will the project purchase phones for the end users? How much lead time is needed to order the phones? Where will the phones be stored before they are handed out? Will the phones need to be charged before they are distributed, and if so, how will this happen? If you have bulk inventory, do you need to purchase charging hardware?
  • Do the end users have access to electricity to recharge their phones? If not, will the program provide access to charging stations? If solar chargers are used, will that conflict with the time when they need to be used?
  • Will network service be available consistently in the local environment of the end user? How fast is the network?
  • Will end users need training on the phones? What time and resources will be needed for end user training?
  • What other hardware does the program need to operate? Think about modems, subscriber identity module (SIM) cards, access to Internet, and more.
  • Consider whether a maintenance plan for the mobile devices used for the project is needed. How will broken phones be fixed or replaced?
  • Consider developing a policy for lost or misplaced phones. For example, would the user have to pay for the replacement?


These considerations should be informed by findings from the Landscape Analysis and interviews with the Target Population.

Enabling Environment—Telecom Regulations, National Policies, & Interoperability

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When developing the technology scope, reconsider questions asked during the Landscape Analysis to ensure that you staying current. The technology environment can shift in a matter of weeks or months. Refer to publications by your country’s telecom regulatory authority, and gather insights from industry insiders by researching for new article and publications, and subscribing to and connecting to others on listservs. Also, speak with ministry officials and the members of the mHealth community. Some considerations include:

  • Explore current mobile industry regulations, policies, and upcoming changes. Do any pose a challenge or advantage to the proposed mHealth solution?
  • What are the national policies regarding mHealth, if any, where the solution will be implemented? Are there discussions underway to develop a national mHealth plan, if there is not one?
    • How might existing or developing policies present challenges or advantages to the project?
    • If the government is planning for or has established interoperability of systems, explore their system specifications and considerations for integration.
  • Are there relevant national policies or regulations regarding the collection, use, and storage of patient health data? If so, is this work in compliance?
  • Will the solution need to link to an existing health management information system (HMIS), and what do you need to know to make that happen? How will the mHealth solution work with existing technology and infrastructure in the country of operation? Is it a possibility that it may need to link to these kinds of systems in the future?


Key resources to consult include the mHealth Alliance’s report The State of Standards and Interoperability for mHealth among Low- and Middle-Income Countries and the World Health Organization’s resource National eHealth Strategy Toolkit.

Scalability

 

 

 

 

 

 

Most likely, your mHealth technology will be created or customized to handle a particular volume of users at the outset of your project, with the intention that the technology will be built out further as the user volume increases. The way the technology is originally set up can have major implications for scalability.

  • What volume of users is expected in the short and long term?
  • What is the expected volume of message or information transmission over time?
  • Where may the program be scaled over time?

Ensure that the mobile delivery platform can operate at scale or can be adapted to do so. Refer to Scale-up for more information regarding scale up processes.

Sustainability

 

 

 

 

 

 

Sustainability—how the program will be financed to operate over time—deserves consideration during the design phase. Often mHealth programs stall after a pilot phase because financial resources cannot be secured. Consider:

  • What is the financial plan for sustaining operations of the mHealth solution over time?
  • What donors are funding mHealth deployments? What are their funding levels? What are their application requirements and funding cycles?
  • If you plan to integrate advertising or mobile payments into the solution, what are the technology implications to consider during the design phase?

Visit the Sustainability page of the Guide for more information on this topic.

Licensing

 

 

Software licensing models exist to establish who owns the software, who has the right to modify the software, and the fees associated with using the software (for example, per installation or per license). 

Open source software is a favorable model in the mHealth community. Open source software allows programmers to change and adapt software without needing the permission of the original software developers. Over time, the software evolves and improves as a result of collaborative work among multiple parties. 

 

Consider: 

  • If you develop new software, how will you license your software? 
  • If you are using existing software, what is that software's licensing model? What impacts will this model have on your ability to adapt the code and sustain operations in the future? 

THE EXPERTS SAY...

“Keep it simple. Cut out the bells and whistles and design the system as if you were going to scale up tomorrow.” – Marasi Mwencha, John Snow, Inc.

“[Costing] depends on type of project. In India, texting is more expensive than the Internet. In other places, it might be the other way around—this matters.”– Jeremy Wacksman, Dimagi

“Voice requires a lot of bandwidth and processing power. Relying on thousands of phone calls a minute to reach scale for a voice-based project is a huge technical [software/hardware] challenge. You may need 100 servers rather than 10 – where will you put them and who will monitor and service these?” – James BonTempo, CCP (with Jhpiego at the time of the interview)

___________________________________________________________________________________________________________________________________

Reference

mHealth Implementation Opportunities, Issues and Challenges. Affiliate session at the mHealth Summit. 2012 Dec 5. Washington, D.C.