Principles for Health IT - Lessons From Africa on Radically Low Cost Tools

For the last four years I was attending Lewis & Clark in Portland and in my free time, nursing a massive soft spot in my heart for the Archimedes Movement. This last summer I graduated and moved to Malawi, where I work on mHealth (mobile phones & health) projects with FrontlineSMS:Medic. Our focus is to bring radically low cost tools to the poor and cut off settings that stand to benefit the most from being connected. I recently wrote a blog post on the FrontlineSMS:Medic team blog about our position on five key issues in health IT, and Liz thought some of you might be interested. While Malawi is a world away from Oregon, I'd argue that the IT context is similar to much of rural Oregon. What do you think?

1. Who are your target audience?
The Frontline Philosophy: To begin with, we're focused on serving organizations that work to improve human health.  And like Kiwanja.net and the core FrontlineSMS team, we focus on the "long tail." This graph sums up the long tail idea well:

Our team differs from Kiwanja.net's approach to the long tail in one important way. Ken Banks usually talks about where organizations sit on this graph. Instead, we look at where specific use cases or projects sit on the graph. If you're a grassroots NGO with 2-3 people on staff, no tech experience, and a shoestring budget, then all of your projects and capabilities should fall in the green part of this graph. You might also be an international NGO with a multi-million dollar budget and a big IT team, but chances are you have some use cases or projects that your IT experts can't contribute much time to, or where you need to stretch every dollar a very, very long way, or where you work in an impossibly remote and low infrastructure area whose needs are entirely different than other parts of your service area. These are what we'd call long tail use cases. Such organizations might find a rewarding cost/benefit equation for implementing expensive, complicated medical record systems at referral hospitals, perhaps even district hospitals. But for long tail use cases at remote health centers they will need a tool with a frontlines philosophy (whether or not they end up using FrontlineSMS).

2. What is your position on scaling?
Like Kiwanja.net, we focus on horizontal scale, rather than vertical scale. For a generic example of horizontal scale, think of ten independently managed platforms serving 10,000 people each, as opposed to a single centrally managed platform serving 100,000 people. We choose the horizontal, modular approach because we do not want to centralize:

• knowledge transfer, learning, and the empowerment that comes from a job well done.
• use of gathered data
• user ownership and enthusiasm
• decision making authority
• funding requirements (and potential for failure if they aren't met)

We also like it when end users can make their own technology decisions (rather than having to defer to an official who will never actually use the tool directly), and we like it when ambitious groups can charge ahead without having to wait for their entire country/district/the domain of any vertically scaled system to catch up.

We do, however, find it absolutely essential to be able to centralize one thing: data. For a huge number of reasons, from pharmacy and supplies procurement, to fund-raising, to disease outbreak management, to research. Exchanging data, of course, can be achieved by representing data in agreed upon formats and transferring via a variety of channels - from Internet, to SMS, to USB sticks carried by bicycle.

3. How does it replicate and grow?
Kiwanja.net couldn't have said it better: "growth is based on patience, and a “pull” rather than “push” approach, i.e. awareness-raising and then letting NGOs decide if they want to try out the tool or not. Those that do then go and request it from the website. Everything is driven by the end user."
At the request of partner organizations, we do have a core team of experts that manage a small number of implementations. The majority of implementations, however, only rely on us for the free software and a lot of advice and support (mostly via email). As an organization, we have plenty of growing up left to do, and we're still figuring out how to portray to the public that we don't want to (and frankly can't) manage or direct most implementations of FrontlineSMS and associated tools in health care settings.
We recently decided to start using the term reference implementations to describe the small number of programs that our core team of experts oversees directly. Moving forward, reference implementations will be selected because they pioneer a new piece of software, an important new use case or methodology, or in some way contribute substantially to the larger Frontline community. All other projects are community implementations, and we are pleased to support them with free software, direct email with our team, and upcoming public email lists and a wiki-based field guide. Hat tip to the OpenMRS community for the framing of reference and community implementations.

4. What is your position on open sourcing?
In addition to sharing source code, we strive to live up to principles that are common among community developed projects, such as openness and transparency, bias towards collaboration rather than reinventing the wheel, and sharing the fruits of our labors as freely and widely as possible. That said, we prioritize impact for our users, and we are realistic about the substantial resources required to collaborate - to license code and make sure it's commented and documented thoroughly enough to support developer collaboration. We sympathize with the many young and low resourced open source projects that are so busy supporting users that they leave something to be desired for strict open source advocates. We're still in the process of working out licensing of PatientView and setting up our wiki and public mailing lists. We hope you'll give us the benefit of the doubt and (collegially) hold us accountable in this regard.

5. Does access to “the cloud” matter?
Yes, the cloud matters; it is the future, but not the present on the frontlines of global health. I mean this more as an observation than as an opinion - the cloud simply cannot be accessed with any regularity in the vast majority of places where we work. We want everything we do to accelerate movement towards sophisticated use of low cost, easily accessible cloud based apps, but starting with apps that work exclusively in the cloud or even rely on the Internet just isn't the best way to do this. Paper based societies need to get their feet in the door with tools that work NOW, but have been designed to point the way to cloudville. How can an SMS platform built on disconnected laptops point the way to cloudville? Under the "scaling" section we hinted at the importance of data standards and platform interoperability. We're making sure FrontlineSMS plays nice with various cloud based apps. We may even start working in the cloud ourselves someday, but not just yet.

I'd like to close with an idea. Is the Horizontal vs Vertical principle worth applying beyond IT, to health reform generally? What do or would we gain with a national reform agenda that instituted a centralized national health service? We might gain massive efficiencies and economies of scale if we were willing to take advantage of them, but could we end up centralizing some things that we'd rather keep decentralized?

This piece was cross-posted at the FrontlineSMS:Medic team blog.