This is a guest post written by Sean Blaschke, the Child Survival Systems Strengthening Specialist for UNICEF.

It is nearly impossible to discuss mHealth without the topic of “scale” coming up. Although achieving scale is not required or even appropriate for some use cases, governments in the developing world are increasingly frustrated with pilotitis and are requiring mHealth innovators to start planning for national scale interventions. However, there is another problem: scale is often discussed only in very superficial terms. The metrics of achieving “scale” are often associated with either percentage of population covered, or geographic reach. Yet these metrics miss key indicators – including those measuring sustainability – required to accurately guide if an initiative is truly “scaled up”.

In Uganda, the Ministry of Health – with support from UNICEF, WHO and DFID – are “scaling-up” a RapidSMS based, mobile disease surveillance and medicine tracking tool – mTrac – that extends the reach of DHIS2 to the Health Facility level. A year after launching, we currently have over 15,000 staff trained and registered, and 1,500 government health facilities using the system. This covers approximately 70% of the country, and we expect to reach 100% coverage by May 2013. By most standards, this alone should equate to “scale”. But does it?

For many mHealth initiatives, government ownership is crucial to long-term success. Yet working with government is not always quick and easy; donors, development partners and private sector companies sometimes take short-cuts, bringing government along only in a cursory fashion or not at all. mHealth projects are piloted (some at significant scale), achieve all of the projects objectives and are deemed a huge success, project funding comes to a close, and the project implementers prepare to hand over the initiative to the government only to find that they are unable to or unwilling to either scale-up or sustain the initiative. The mHealth project joins the graveyard of other “successful” mHealth projects. What went wrong, and what other key factors are required not only to reach scale but to sustain it?

Enabling Regulatory Environments

For most mHealth initiatives, even those driven by the private sector and which we can assume will start with a sound business model and projected revenue streams required to sustain the project, at some point government must be engaged. This is especially true with the growing number of mHealth applications in developing countries which provide consumer oriented services, including those that register pregnant mothers, and send them general information, tips, reminders for clinic visits, and notifications to pick up test results. Unless these mHealth applications adhere to government laws and policies, such as those that address privacy and security of electronic health records, a well-intentioned project could quickly find itself on the wrong side of the law. What complicates this further is that these laws and policies do not yet exist in many developing countries (although this is quickly changing). mHealth innovators in countries with gaps need to at minimum be aware, and ideally play a role, in advocating for appropriate laws and policies that create an enabling environment – understanding that too much regulation can cause as many problems as too little regulation.

Country Ownership

In the past, most Ministries of Health in developing countries did not have a single entry point, or coordinating unit, for mHealth. If a funder interested in malaria diagnostics wanted to support an electronic system to track consumption of anti-malarial drugs, they would go to their countries department charged with malaria control or medicines. At the same time, another funder would be approaching the epidemiological surveillance department with a similar tool for tracking notifiable diseases, while a third funder would be working with the communications team to send reminders for patient adherence to anti-retroviral medicines.

This is also changing, but many countries still see mHealth not as a cross-cutting enabler that impacts all programmes but as “IT issue”. However, some countries – including both Rwanda and Uganda – are setting up actual Health Information Departments and creating eHealth Coordinator positions that do not just create a token coordination roll but have real power with senior level decision making and budgets.

 “Islands of Data”

Even where there is coordination and government leadership, too often there is a project –rather than systems – focused approach that creates vertical information silos, or “islands of data”.  As these vertical systems overlap, confusion is created amongst end-users and new barriers to interoperability – and sustainability – are created.

Now, many Ministries of Health are taking a different approach: they are looking at the Health Information System as a whole, with interconnection and interoperability a tacit requirement of a properly functioning system. This includes recognizing that there are certain databases or registries, such as those for facilities, providers and clients, which should be centrally managed and shared across applications. Without a common baseline of shared information, a health system, particularly one dependent on IT systems, cannot function.

Private sector partners, donors and mHealth application developers should all take heed. Some government bodies are beginning to consider “accrediting” mHealth applications, and failure to comply with emerging standards around system architecture and accompanying Application Programming Interfaces (APIs) could lead to projects with the potential to scale being shut down.

Sustainable Financing and Human Resources

As part of this approach to developing an enterprise level health architecture, many governments are now also taking a new look at the infrastructure, human resource and financing requirements needed to meet these new needs. It is critical for government to fully understand the total cost of ownership of any initiative before they decide to invest resources, and make an investment case on using these resources to support and maintain them.

If government has not dedicated sufficient human resources to manage the systems, including hardware support to deal with broken devices (including phones) and technical resources (either in house or outsourced) to maintain and upgrade the software applications, and financial resources to pay for them, then these mHealth initiatives – particularly those approaching or operating at scale – are sitting on shaky ground. If donor funding disappears, equipment begins to degrade and breakdown over time, or a myriad of other unplanned issues arise, quick wins could rapidly turn into painful lessons learned.

Conclusion

In Uganda, through initiatives like mTrac, we are grappling with these challenges. The Ministry of Health, along with partners like UNICEF, are now regularly meeting with other Health Development Partners to address duplication of efforts and coordinate support and funding. We have greatly reduced “competition” between partners and provided a forum for dialogue, which has been a key factor in the successes we have achieved so far. However, it is also clear that there are also no easy answers and each win is often hard fought.

Designing a successful mHealth application is only the first part – technology should not be the driver, but serve the people and the systems it is meant to support. It is only when you look beyond the numbers and address the structures required to sustain them that true scale – and sustainability – can be achieved.

Photo: Courtesy of author.