I am David McCann and when I first arrived in Uganda, I used to describe it as “the perfect storm” for aid in general, and M4D in particular. The country overall has the necessary cellular coverage for a successful M4D project.
Kampala is comfortable, with mild weather, good infrastructure (Umeme Electricity Co. notwithstanding), and more than its share of international-style restaurants for all those expatriate aid workers.
And in contrast, the impoverished Northern regions of the country have the necessary need for immediate and long-term intervention from development organizations, from the small NGO to Big Aid.
The government, at first blush, seems to enjoy the arrangement
Discussions of corruption within any large organization or government could fill volumes, but to put it succinctly, big money flows through Uganda, funds many of its public programs, and is certainly strained through the appropriate parliamentarians (and yes, a few high-paid NGO consultants) before arriving where it’s needed.
The result is almost a gold-rush frenzy to get one’s own brand of smart phone and wheel-reinventing Android app out to a handful of Village Health Team workers and change the world. In theory, this sounds like a win for the Ugandan people…
In practice, there are other details to consider
You’ve managed to track drug stock-outs in a sub-county in Moroto using solar chargers and 50 Samsung Galaxies. That’s great, can we share data with a similar project I did using BlackBerries in Gulu? Probably not.
You’ve rolled your own drug-stock-tracking application. And yet when members of Big Aid met with the Ministry of Health, to account for the overlapping features of their mHealth applications and whether API integration is possible, one actually responded along the lines of “well, it’s backed by a relational database, so in theory, yes.”
While true, this misses the intent of the question by a wide margin. It’s worse in the education sector, where the Ministry of Education and Sports has unfortunately contracted a private US company to write a proprietary, never-completed application for tracking district-level attendance.
A year ago I was told it did have an API, “using SOAP.” A year later the company has yet to elaborate on that single sentence worth of documentation.
Ministry of Health is pushing coordination
In contrast, the Resource Center at the Ministry of Health has in their employ a talented young IT professional, whose task has been to migrate literally dozens of historical databases (in MS-Access, shudder) over to their running instance of DHIS2.
When I have the pleasure of speaking with him, he gets excited about software using Django, FOSS in general, and API layers for sharing data. He’s part of an elite few Ugandan IT professionals who are changing their country for the better.
DHIS2 is fulfilling the medical recording needs of not only Uganda, but many other countries in the region including neighboring Rwanda. It is free, open source, and continues to have features added to it by an active community. Its adoption by (and related referendum from) the Ministry of Health in Uganda signals perhaps not a changing of the guard, but at least the entrance of a few people in key positions who pay attention.
These champions are forcing the Big Aid organizations to do M4D in a more coherent way. They’ve cut the tracking of health-based indicators that serve only as metrics of aid success, and they get excited (and sometimes even angry) when they see the messages people send in to an anonymous hotline about drug stock-outs or health provider absenteeism. (For those in Uganda, the hotline is a free SMS short code, 8200, and you can report on any problems in your local health facility).
If you want to do M4D in Uganda, you have to be willing to collaborate.
If you still think the best way to succeed is by handing out an iPad to every village health worker in the parish you’re working in, great. Just make sure first that no one else is handing out Androids there too.
And when your pilot crashes and burns because it can’t scale country-wide, your data should at least be able to feed into a system that tracks the entire small-scale NGO graveyard of projects, because the sum total of the data actually is useful, even if the project itself ultimately wasn’t.
If you’re Big Aid, it means you’re going to have to start re-thinking the budget of that $hundreds-of-thousands grant, because it probably shouldn’t have your own branded software platform as a line item.
Obviously, I see this as a good thing. It’s a powerful indication that at least at the Ministry of Health, Uganda is ready to take ownership for its development. And really, isn’t that sort of the whole point?
This could be great if increased regulation from Kampala improves collaboration. It could be horrible if it disempowers ministry and private groups working at the local and regional levels. Rather than a thumbs up or thumbs down, we should all be promoting a balance here.
Case in point: the central administration of another east african ministry of health recently decided to roll out DHIS, and decided to mandate participation of all provinces before central was really ready to support local ministry offices. One remote district I’ve worked with was forced to stop using a regional information system that they had used very effectively in the past, instead switching to a still-in-progress (i.e. buggy) DHIS implementation that the local staff don’t trust or know how to use well. My organization isn’t behind either of these technologies and I have no vested interest, but it was sad to see the significant progress of a minority region steam rolled by an incompletely implemented plan from central government.
Developing an eHealth strategy and mandating that all ICT projects engage in collaborative fora and make meaningful efforts to support data standards are fantastic ideas. This centralization could prove problematic if the vetting process for new ICT projects proves to be driven by personal connections rather than technical and operational merits, if the burden of central mandates outpaces the support provided to local ministry, or if the new barrier to entry is so high that it regulates smaller innovative groups out of the market and leaves the whole country chained to bureaucratic giants.
Hi David,
An interesting look at the moratorium that came as a shock to myself and my distance learning team at a local Ugandan training organization for health workers.
What does this moratorium really mean for collaboration? Pessimistically, a hindrance. Optimistically, nothing. I’m happy the Ministry of Health is taking stock of programs and evaluating effectiveness, but I think you hit the nail on the head by mentioning the different projects that bring technology in and don’t collaborate. Where we disagree is here:
“If you still think the best way to succeed is by handing out an iPad to every village health worker in the parish you’re working in, great. Just make sure first that no one else is handing out Androids there too.”
Until the development community stops introducing new tools and starts working with the tools already available to health workers, building ICT infrastructure with local partners (including our beloved Umeme) then collaboration is a non-starter. An iPad user in Mbarara will not be able to collaborate with an Android user in Gulu, so let’s stop it all together and think strategically about how to create a real eHealth program that can build ICT skills and infrastructure throughout the country that are translatable and real and will really support moving towards a national eHealth program. What’s the point in collaborating if everyone has their own agenda? It’s going to take a tactical cross governmental program involving the Ministry of Health, Uganda Communications Commission, Ministry of ICT, Ministry of Education, and maybe even the Ministry of Works and Transport, as well as all of the stakeholders on your fantastic map above, to really improve the ICT4D collaboration in Uganda. And I think some of that is underway and the moratorium is a start.
But this isn’t going to be an easy fix because it means changing the way we do and think about ICT4D projects in general.
stunning outcome. But not surprising. the MoH Rwanda instituted this a while ago – all new ehealth/mHealth projects are supposed to be reviewed by a steering group – exactly to avoid this sort of 1000-flowers-blooming + lack of interoperability.
David,
and the MoHSW in Tanzania has also been complaining about the chaos in the m-health sector. Sometimes, the same health center will be implementing 2 separate m-health trials for different programs.
Tanzania does have a coordinator who is more open to ‘1000 flowers blooming’ but insists that they be kept current. We also have an active Technical Working Group where implementing organizations are keeping each other up to date on programs. Partners know that this communication is important and are putting in the effort coordinate.
You issue you did not mention is that development agencies are not funding proprietary software. This is not a philosophy, but a restriction on spending donor funds. We have had a couple of interesting programs that simply hit the wall when they ended their test phase and discovered that one was willing or able to buy the software.
I think it’s great to re-evaluate what systems are in the field. But the result shouldn’t be a dictation of either software or hardware requirements along the lines of “You must use X or Y but never Z.”
The realities of how health is financed in East Africa are that money comes in from many different sources. It is both reasonable and unavoidable that the sources of money will want to exercise some control over the information collected. Each of these donors and implementing partners also comes with resident expertise that makes them prone to one set of technologies or another. They may also have strategic partnerships that make some hardware or software apps most cost effective under project budgets. Finally, users at different levels (community, facility, district, county, state, national, IP, development partner, donor…) have different needs and, therefore, will often push for different user interfaces, types of interactions, and data use.
Behind the discussion above on central “forcing” of DHIS2 to ouster a local software is NEED by the MOH (not desire) to control; control costs, control time to implement, control interoperability of data, control training of its health workforce, control ability to know what’s going on with malaria or HIV in their country. And THIS is the heart of it.
This is not a SYSTEMS INTEROPERABILITY problem. It is a DATA INTEROPERABILITY problem. I think you’re wrong to suggest not to roll out an iPad because an Android is on its way–sometimes you need an 8-inch touchscreen and sometimes you can get away with a 2.1″ screen with small QWERTY keyboard…depends on the user and use case. The real problem is that, on the back end, the data being collected isn’t interoperable across projects. The speck of hope is the person above who’s purging these MS Access databases into DHIS2 (or any central platform, assuming the data fields are actually compatible).
I’d like to see the outcome of the moratorium be a set of data standards for health data in Uganda (e.g. SDMX, DXF, HL7…) and an insistence that all projects in Uganda adhere to those standards during collection. The issue is the data, not the device, and not the application running on the device. A set of uniform data standards bypasses the more-expensive and less-rewarding path of dictating platforms to a wide array of users.
The idea that there is one data collection software and one set of data collection / supportive supervision devices that will effectively meet the needs of all MOH and donors is a pipe dream. Many have tried that path; all have failed.
I think there are probably two crucial issues, one being sovereignty and responsibility, the other being the something more specific to Uganda and its use of DHIS2.
First to responsibility. I’m of the opinion that development and aid have, as their ultimate goal, the empowerment and the sustainable governance of those countries they have a presence in. My sarcastic comments about the realities of the institution aside, I’ve remained a bit of an optimist, I’ll admit. You’re quite right that the MoH in Uganda has a central need for sovereignty of health-related interventions in their country. I’m also of the opinion that they, as the authority of health in their country, are the persons appropriate to do so, they are at least ostensibly the *customers* with the *requirements* for improving health in Uganda.
Second to DHIS2. I’d first like to say that I have NEVER worked on a software project that didn’t have “You must use X or Y but never Z”-style requirements. It’s absurd these days to think of a product that, if it has an API (and shame if you don’t) that speaks at least XML and/or JSON. DHIS2 is not a turnkey product, and in fact is not yet equipped to do the sort of rural data collection that Uganda’s environment demands. Again, forgive my sarcasm, but while I am a little frustrated at the map at the top of this article, I do seriously believe that if one really MUST do that little iPad project, by all means do so. DHIS2 serves as the current standard of DATA STORAGE for the MoH, it’s why they want all our pet donor projects to speak it, as an API requirement (the analogy is DHIS2 is just another data transfer standard, just like XML or JSON). It is NOT intended to be the sole product used to collect the data, and the moratorium is actually quite clear on that. I hope this clarification is good news to you, it means that in fact Uganda is taking steps to insist on standards adherence. I think it’s good that the Ugandan government ultimately has some (at least shared) ownership of mHealth data, and at the end of the day I think they really just want to maintain one database (which happens to be DHIS2) rather than some suite of standards (the proposed SDMX, DXF, HL7, OpenMRS, etc. etc).
For this update, I am a member of the eHealth TWG at the MoH in Uganda. We are sifting through a lot of pilots struggling against “pilotism”. Looking for interventions that fit into our Framework, sustainable and scalable.
Am sharing these comments with the DGHS at MoH for purposes of information sharing.
MoH and UNICEF are hiring an eHealth Consultant to help establish a new eHealth Technical Working Group to provide the positive coordination we all hope will come out of the moratorium.
Upset by the moratorium? Be past of the solution!
May 4th application deadline!
Details:
http://bit.ly/HNj4WB
The post is good, but it does not provide a complete picture of the all the M4D initiatives unfolding in Uganda. No mention of the participation of U MoH and other partners in the OpenMRS work. ( https://openmrs.org/blog/2010/09/20/openmrs-community-wins-best-paper-at-medinfo/ ), and work with other partners such as Partners in Health ( http://www.pih.org/news/entry/medical-students-from-around-the-world-call-for-recommitment-to-global-fund/ ) and so on.
A good point the article makes is about the need to coordinate efforts and ensure interoperability across platforms for a robust national MRS and it is laudable to see the government taking steps to ensure that.
I am probably one of very few native Ugandan Medical Doctors who possess software development skills (excuse the explicit presumption), as well as experience in rural health care delivery against a background of a rural upbringing.
Amidst the various technical angles in the mHealth/eHealth debate, we must all agree that there is one important, desirable and non-negotiable endpoint: Improved Health for Ugandans. In this context, that is the bottom line.
That statement for many “purist” techies may seem redundant. But when you realise that the projected commercial value for eHealth technologies is in the tens of billions of US Dollars per year, you begin to see that turf wars are going to be the norm. The incessant cries for integrability and interoperability are the early symptoms of this phenomenon. Some African Ministries of Health are now hiring, at high cost, Data warehousing experts to collate their varied data types and sources!
While it is exciting that my passions for medicine and technology can intersect, it is sobering to remember that if Ugandans could attain optimal health through the use of good old ink and paper, that would suffice.
Our best software, middleware, hardware and the architecture that holds them count for nothing if Ugandans do not derive a positive health value from them. Managers must watch “the health bottom line” and actively screen out opportunistic enterprise.
The Ugandan situation is evidently not unique. Many interest groups are trying to cash in on the gold mine that mHealth in Africa is. To my mind, it is thrilling that this article uses the Ugandan situation as a metaphor to stir up debate that is relevant right around the world.
Insightful
Hi Jeff
I think you have exactly defined the real problem and real solution. Let’s hope it wins out against the opposing clamour to define application, operating system, device, hardware etc. standards which would only serve to stifle and block innovative solutions and restrict flexibility to embrace emerging technologies and concepts in thre future.
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] a health plan and technical specifications and make certain that a projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] health strategy and technical specifications and make sure that the projects fit. (Here’s a map of pilots in Uganda that eloquently explains […]
[…] them all; South Africa has banned pilots of new electronic medical records systems. Here’s a map of pilots in Uganda that eloquently explains […]