#PulseCamp : Building a vital stats monitor for the world

My brain was pretty close to silly putty by the end of last week. It was been snapping back and forth, rubber-band-like, between microscopic, tightly focused, gnarled and tricky use cases up to their connection to the UN Global Pulse project - a global, systems-changing project.

Sketching out the architecture. This might take more post-its.

The Global Pulse, at scale, is... well, the more time I spend on it the less I'm sure I know what it specifically is. In effect, it is a massive data coordination system which helps visualization and tracking of anomalys and trends. The dream is to predict crises and improve prevention. This is easily thought of in detecting disease outbreaks through various data-connected behavior changes (increase in usage of oral rehydration salts as evidenced by stock-outs in health clinics reported in a nationa health information system could indicate a cholera problem). Its most valuable use case seems to be at the national level, but there would also (obviously) be a global level to track larger trends across countries and regions. And country-level offices could peer together with other Pulse installations, bring in global baseline data, and so on. It keeps going deeper and deeper in every direction possible.

Accepting the insanely complicated data and architecture questions, how do you even find the right data (whether it's well-formatted or a pile of paper), and connect it in and pull out solid anomaly tracking and generate useful, predictive guesses on trends. That's the key in the next stage of the Pulse - starting in one country. This PulseLab will be able to grok the local context and know the right data to plug in.

The trick for the data and architecture part has also been faced. Implementation will not be easy, by any means, but the goal of the architecture is to re-use and re-cycle as many existing tools as possible to slurp in data (both chunky databases and firehoses of live streaming data), standardize it, and then create a set of manipulation and visualization tools to help reveal trends and test hypotheses. This will likely take the form of a set of toyboxes of data sources, data transformation tools, apps (input/output to other useful systems like mappers, charting, Ushahidi, etc.), and a recipe box of how others have chained these together for specific data-digging goals. This recipe and the hypothesis testing tool (the "hunch" ) will likely compete to be the core social object of the system, with aid and government officials trading hunches and recipes (and recipes to support hunches, hunches based on recipe results...).

A potential Global Pulse Product-in-a-box for an end user

There is a lot up in the air, and a lot still to congeal as development of this tool and the architecture gets moving. The (amazingly well-facilitated) process which went from thinking through users, their requirements, common underlying system-level requirements and speccing those out was fantastic. It encouraged a lot of different and conflicting views around the product's end form to come to a loose consensus (and a better, more flexible product outline!).

If you're saying it can't be done, you're almost right. The first iterations will be limited and possibly fragile, relying on low-hanging data fruit instead of difficult to "harvest" data exhaust. Privacy issues abound, both on personal levels and at government security levels. Trust me when I say that the room was stock full of mind-bogglingly smart people who have dealt with the real worlds of development and reconstruction work, and these obstacles are being worked through by people who realize that lives and livelihoods are at stake in some of the privacy questions.

Here are summary notes from each day: One (Term of the Day: "Data Exhaust"), Two (TotD: "Data Esperanto"), and Three (TotD: "Contextualized Cartography"), as well as a solid overview of the project, and the call to action leading in to last week's workshop. A great writeup of the event is at by MIT's Nadav Aharony.

mHealth: Tending the garden of 1000 flowers

At #mHS10, we heard funders talking time and time again for letting "1000 flowers bloom" in mHealth pilots, and programs talking about pilots leading to more pilots. This was fine the first few times it came up, but by the last day, the syndromes of the pilot-itis pandemic were clear.

FlowerThis reeks of desperation. The funders are not finding clear winners in their projects, and the various implementers are casting about with local solutions that they either can't or won't scale, trying to find an idea so powerful that it will break through this lock.

We need to focus more energy on innovations which are dealing with core problems in health and in using mobiles for health, and thin out some of these 1000s of flowers. The soil is too fertile for this approach, and the many duplicated, repeated pilots will crowd out new, creative and gamechanging ideas. We need to move past these more basic mhealth applications - reminder messages for drug adherence, pre-natal checkups and so on are great - but simply using a new communications method to address an old problem. Let's replicate and scale those to more sub-sectors and keep them funded, but let's not dwell on them.

On scale -- this is not something that's eay to do. There are many barriers in mobile and in health, from cultural concerns to be dealt with which limit scaling of health projects, to many technical ones inhibiting good mobile projects from being re-implemented in other regions. There are many good meta-solutions to the technical side - open data standards and open source, both praised often at MHS10, are paving the way by creating a variety of tools which can work together.

We need more.

The platforms and networks need to become more open. Projects have been able to thrive where they rely on the lowest common denominators in phones - voice and SMS. Even still, a lack of global short-codes and improved cross-carrier and cross-border functionality hinders scaling. Beyond voice and SMS, it becomes a difficult maze of twisty passages dealing with the various featurephone systems, vendor lock-downs, and even more capable smartphones, which are even more locked down and difficult to get custom applications loaded.

The building blocks are there -- open source tools and open data standards abound; focusing on those is a big first step. Banding projects together, connecting at events like the mHealth summit, and increased best-practice sharing is another. Not being shy about where the real blockers are to scalable solutions is the elephant in the room. Do we need to engage the GSMA and ITU to work on better cross-connection solutions among the many global connectivity providers? Cell phone manufacturers to improve standardized access to their devices? These aren't the low-hanging fruits, but they might be the keys.

From #mHS10 to #mHS11: What we need for next year

Herein, a mix of quotidian tasks and big goals for us to prepare for a 2011 mHealth Summit. mHS10 was a great conference, and represents a seachange in the field compared to last year. It had a selection of amazing speakers, lots of academics and implementers, and overall just the right crowd.

Still, there remain some changes I'd love to see for the conference itself, and I'll follow up with some bigger challenges that the mHealth world needs to deal with, based on the themes from this year's conference.

First, keep the music if you must, but add lasers and a fog machine. If you were there, you know what I mean.

My top take-aways from #mHS10 , the mHealth Summit 2010

As you might have guessed from my tongue-in-cheek #mHS10 drinking game (pilot=1 shot, 1k flowers=2, feature phone=3, "going global with sms phone support" = finish bottle), I got a bit tired of "Pilot-itis," which was finally called out as a problem on stage by Christopher Bailey of the WHO during the Wednesday morning plenary.

This pilot-itis was my biggest overall frustration with the discussions and presentations this year - a seemingly endless march of "new" pilot programs around (1) SMS for outreach/awareness (2) SMS and mobile for low-touch scheduled reminders and interaction or (3) Apps for various forms of monitoring. Perhaps it's my relative unfamiliarity with the health field, but do programs do controlled studies every time they plan to release a new paper, or put a PSA ad at bus stops? There is so much that can be done today, with a few hours of hacking, to advance at least #1 and #2 above, settle on a few solutions, and move on to more impactful territory. Take a page from Nike (who have one of the most successful fitness monitoring apps in the wild) and Just Do It.

OLPCs, Uruguay and Educational Value

My recent blog post on Uruguay's Plan Ceibal generated a buzz of discussion over at OLPCNews on the value of measurement, test scores, and updates from the field on 1:1 laptop projects visibly impacting test scores (http://www.gse.uci.edu/person/warschauer_m/docs/netbooks-aera2010.pdf#n…). Are these soft measures of attendance and laptop usage good enough, or must we demand test score improvements?

UR(uguay) Doing it Right: CEIBAL's numbers, miracles, and measurement

Miguel didn't dive deep into cost calculations during his TEDxBuenosAires talk, but this seems like awfully low numbers. I am curious to see how they are controlling the costs - perhaps Internet access is affordable due to a competitive marketplace (wish we had one of those in the States) or existing subsidies for educational access. Do these costs include Ministry-level overhead and teacher training, or have those been rolled into existing budgets? I wonder not so much as a criticism of their cost calculations - clearly CEIBAL is a shining star in both OLPC distributions and educational technology projects - but rather as a best-practices interest.

Another OLPC TCO study

1:1 Computing costs are a difficult thing to nail down, because there are so many factors that go into it. I worked with GeSCI's Roxanna Bassi to create a worksheet to help guide cost calculations. I took a first stab four years ago, and came out with a $972/laptop cost over a 5 year program. To say that that cost estimate was not popular at the time would be an understatement.

OLE Nepal has put together a great TCO of the laptop program, based on their pilot project. Where I pieced together training budgets from USAID ICT4Edu projects and Internet connectivity estimates from UN/ITU global averages, they have on-the-ground numbers, (and a few ideal estimates on repair costs). The total for a 5 year program in Nepal? We're still looking at $753, if you read carefully:


Innovation and Cell Phones: It's not happening at Apple

Or Google. And certaintly not at any of the carriers. The real innovation and hacking is on the streets of Ghana, India, China, Egypt and more, as Jan Chipchase reveals in Icon Magazine: http://www.iconeye.com/index.php?option=com_content&view=article&catid=443&id...:

"In any cluster of mobile phone shops you find someone who offers repair services. This typically starts out as people fixing displays and speakers, which tend to break first. People then come asking if other things can be fixed, and over time there’s an increased awareness of how to fix different models. Nokia tends to be the dominant player in those markets, so people tend to know how to fix them, right down to soldering bits of the circuit board. It’s from those repair services that a street-hacker culture originates. "

This also sounds curiously similar to early stages of import-replacing industrialization, where with domestic reverse-engineering of imported technologies in support of increasing support, repair, and eventually production and innovation of the technology.

Oh wait, we're already seeing innovation:

"However the demand is there, and we’ve seen street services that offer to take two physical sim cards, and re-engineer the circuitry to fit into one sim card slot – effectively allowing multiple phone numbers on one device. You could argue that the cutting edge of mobile technology and use is happening on the streets of places like Accra, rather than Tokyo or San Francisco. "