A friend of mine was interviewed this morning by the BBC to debate the employment of the OLPC in Africa, following these comments in a recent interview:

"If I had the money, I would not spend it on laptops," Hollow told SciDev.Net. "It will cost about US$3 billion dollars to give every [Ethiopian] child a laptop. And as a proportion of the national budget for education, that's just ridiculous."
The approach "doesn't actually empower people in the way that we'd like. It just undermines the teacher ... It's impossible to integrate it".

While Dave says only his least favorable statements about the laptop were used in the article, he does agree that the laptops are an inappropriate use of funds for a country as poor as Ethiopia, especially for primary school students. While the debate has not yet been placed on the BBC website, this piece also talks about the laptops, and more generally, how children are using technology too much.

While to some extent my interest in OLPC has waned, Iam starting to think about other things I would like to learn more about, particularly as I think about my possible master's in Education, Health Promotion, and International Development at the IOE starting this fall. What possibilities are there for leveraging technology for Public Health in International Development? Though I swear I was thinking of it first, the latest issue of the Economist, was clearly a step ahead of me in their technology quarterly. One of the innovative ideas was following up on patients to make sure they take their TB drugs:

"TAKING your medicine even for a week is a drag. Taking it every day for six months is a real nuisance. Yet that is what is asked of those being treated for tuberculosis (TB). They need to pop their pills for half a year if they are to eliminate the bacteria that cause the infection and combat the emergence of antibiotic-resistant strains. But the actual symptoms of infection tend to go away after just two months of taking the medicine, so the incentive to carry on is negligible. Worse, the drugs themselves produce unpleasant symptoms, including nausea, diarrhoea, headaches and insomnia. Indeed, one common anti-TB drug, rifampicin, also has the unnerving side effect of turning people’s tears, sweat and urine a shade of reddish orange.
Every cloud, however, has a silver lining, for it was this strange (if harmless) side effect that gave a team of researchers at the Massachusetts Institute of Technology (MIT) their crucial idea: stamp-sized patches, much like litmus paper, that change colour when exposed to the urine of people with traces of medicine in their systems. The crucial trick of XoutTB, as the system built around these patches is known, is that the change in colour reveals a code that a patient can send by text-message to a number which rewards him with free airtime minutes on his mobile phone. Patients thus have a daily incentive to take their terrible pills."

...somehow the idea of incentivizing health like that doesn't seem entirely sustainable - shouldn't good health practices be enough of a reward in and of themselves? In fact I think these sort of ideas can be leveraged within a business model, and not just for free, not to mention paying patients to do what is good for them. The article mentions later that this idea could be extended further to other illnesses:

"If XoutTB does work, the team has ambitions to extend it. Other drugs can also be a nuisance to remember. The anti-retrovirals used to combat AIDS, for example, have to be taken for the rest of a patient’s life. And taking medicines for non-infectious conditions such as diabetes and high blood pressure is also a chore. Find the right “litmus test”, though, and what is now being done with TB drugs could succeed with any of these as well. Taking your medicine could, at last, become a truly rewarding experience. "

Another article was about using the location element in phones to track the spread of public health issues:

The sender’s location is determined for each of the messages, which pop up as conversation threads on an interactive map that can be called up on the web. Clicking on this map allows text messages to be sent back to users in the field from the control centre. InSTEDD says this service, called GeoChat, enables “geospatial ground-truthing, as your mobile team works to confirm, refute, or update data”.
Automating the reporting of titbits from remote clinics has already had a profound impact, says Eric Rasmussen, InSTEDD’s chief executive. Instead of recording information on scraps of paper, which would sometimes take days to reach higher-ups and trigger an alarm, the cycle-time has been reduced to days or even hours. GeoChat has been officially adopted by the six countries which share a border in the Mekong Basin, including Myanmar and Yunnan province in China, establishing a flow of real-time disease data from villages in the region to each country’s health ministry. Authorities can then choose to share this information with international bodies such as America’s Centres for Disease Control and Prevention (CDC) or the World Health Organisation. The aim is to enable a quick response to any outbreak of avian flu, cholera, malaria or dengue fever. InSTEDD is helping aid organisations and government agencies deploy its free tools in other countries, including Bangladesh, Peru and Tanzania.

InSTEDD mentions on their blog 10 pitfalls in public health development with Mobiles:

Pitfalls of an architectural approach
These pitfalls are not inherent to any and all architecture efforts, rather, they are risks that can be managed and mitigated. I am sharing them because I’ve seen these sap energy out of what otherwise could have been a great contribution:

1. One Size Fits All / Blueprints with no context: I’ve seen architecture efforts fail because they create blueprints that don’t consider the target context. Think about why a city apartment is different from a beach house, even if they have a lot in common. mHealth solutions will vary country to country due to factors such as different mobile penetration, language and literacy, cultural factors, population distributions. A good architectural approach would consider context as a first-class citizen. A great investment would be to evolve pattern languages for the eHealth/mHealth space, because they inherently bring in context to the equation. This is tough, however, because understanding context requires experience and on-the-ground presence which is expensive, and requires time, and takes away the illusory charm of cookie cutter answers.

2. “Best practices” advertised while the paint is still wet: There is a huge hunger for best practices. In a new field as mHealth, things that work once get a lot of press. I always recommend focusing on proven practices rather than best practices, and evaluating on impact metrics (e.g. birth complications averted) rather than proxy measures such as adoption or usage metrics (“30 users”) or satisfaction (“so-and-so is thrilled”). The latter is especially tough because impact metrics may take months or years to budge, and while subjective evaluation is critical, many organizations work heavily with per diems that distort the value proposition of an effort (For those of you not familiar with the term, a per-diem boils down to compensation as in “If you come and [work with my project] for a day we’ll pay your staff $5 each”. Everyone would agree it’s hard to design compensation for ‘customers’ that doesn’t create conflicts of interest). A good catalog of solutions would be transparent about the impact metrics and evaluation timeframes (it ran for a week, it ran for a year) of implementations or pilots (unfortunately there are a lot of systemic disincentives on all parties involved to publish this information raw).

3. Star charts for the high priests it is common to see an architecture effort devolve into a debate about frameworks, representation and notation, a debate with language and artifacts that only ‘a chosen few’ can understand. Be wary if you see UML diagrams with OCL expressions, or diagrams that claim code generation as a goal. Notations are only useful if they help comprehension. And don’t be fooled – UML and any specialized notation has been used many times to hide bad thinking behind a veneer of formality. A good architecture effort would communicate in a language and notation that is simple even if not formal. Even better, it would provide a reference architecture and reference implementations as a starting point for common scenarios (“Show me”. Heck, you could even have virtual machines with things deployed and running). In my experience a good set of documents outlining tradeoffs and decision points go a long ways helping implementation, more than a complete Zachman or TOGAF analysis or detailed BPEL workflow.

4. Shipping technology versus building capacity a good effort would specify the relevant skills and communities needed to implement technologies, and pointers on how to get those skills, not just to consulting organizations who can drop-ship products that do the job. For an effort to be sustainable, your users have to understand the goals that the technology supports, and your IT staff needs to understand the technology better than superficially. National or regional labs like InSTEDD innovation labs would be a great asset to the ecosystem of eHealth initiatives.

5. Architecture antipatterns. "an anti-pattern is something that looks like a good idea, but which backfires badly when applied." (Jim Coplien). Sounds obvious one should avoid them but some antipatterns are like flypaper, one keeps getting stuck on them, and they aren’t well documented. Architecture efforts that rely on heavy top-down prescription are very prone to recommending antipatterns as they don’t have immediate feedback loops. To discover these troublemakers early and nip them in the bud, watch out for designs that make sense to engineers but don’t make as much sense to user; or ‘grafting’ that work in other contexts. e.g. A common antipattern is recommending single-master centralized data repositories for information that spans many sectors or agencies. Another one is assuming a process or technology that works for 2 weeks for 20 people can scale to a national rollout. Good architecture guidance would have appropriate risks associated with each capability, validated by real case studies.

6. The Master Data Model (capitalization required). This is a common antipattern, but it deserves its own bullet. The pitfall is assuming you can model the data of a domain a priori, share it across organizations and applications, and then implement software following that model. (e.g. A patient has a first name, a last name, date of birth…) It is possible but very inefficient to do things this way. Creating master data models is a huge temptation amongst folks who have reductionist/mechanist perspectives (and not much enterprise-scale software deployment experience). History has shown that small, flexible standards that can be used together tend to survive longer than larger, holistic standards that cover too much. Think microformats, on standard protocols. Model the interoperability that emerges on the internet, not in large companies. Empower your users to evolve their data models and workflows without having to call coders (if that is too hard, at least make sure local, in-country developers can change and deploy the software)

7. Filtering innovation out The desire to rationalize efforts to save resources can lead to de-duplication initiatives. Reducing duplication can save waste but can also stifle innovation by reducing the chances of discovering new ways of doing things. Many great innovations are recombinations and integrations of things that existed before. A good architecture effort should celebrate multiplicity of approaches and implementations– a better gene pool is more likely to succeed. People shouldn’t be as worried about duplication of effort as they should be about lack of interoperability between projects. That said, the amount of tech efforts in the field that I’ve seen that are funded to be duplicative from day one is staggering, but only depressing when you consider how many don’t interoperate with much at all (sometimes even on purpose).

8. The “open clique” Any architecture is a like a small language, and any architecture creates an asymmetry, of those who know about it, understand it and are behind it and those who don’t know about it or aren’t quite up to speed. The health and humanitarian space is small and cliques form much more easily than in the commercial space. An honest architectural approach would be open, and would allow critique, revision and aggregation by parties not involved in creating the original architecture documents. I like the Health Metric Network’s approach to this.

9. Forgetting about your users For a project to be successful you need to understand user priorities and how they experience technology. How many technologies have been inflicted on users because they have the right technical specifications with little regards for the user experience? How many of these technologies that users don’t like have succeeded? With mobile applications, there are many many settings and kinds of users for technology. Making things user-friendly takes more work, especially in the field. User Experience (UX) design plays a critical role in determining how technology can help the users achieve their goals. Yet I have always been amazed how most enterprise architecture frameworks miss user experience and design (or confuse it with usability and requirements gathering). Most arch frameworks are evolutions of mainframe- and client/server- era learnings generalized and repackaged for the slowly changing architectural and organizational styles used in enterprises. Consider that enterprises can afford to inflict badly designed technologies on their users much more than a ministry of health in a developing country, so I think they are a terrible role model for this particular aspect.

10. Forgetting it’s about community health the health space is littered with technologies and standards that evolved from secondary goals of the industry, that happened to be better funded for IT. E.g. standards for medical record exchange that evolved out of billing reports needed for insurance, or auditing systems that track liabilities of health care organizations but not patients or doctors. Keep the end goal in mind! A good architecture effort would make sure the outcomes and impact are correctly placed. Standards would be chosen based on how well they fit a problem, and catalogued as an implementation choice.

I hope this doesn’t sound as complaining. Rather, I am proactively sharing experience for which I have first-hand scars, after having worked in the enterprise architecture space for many years. Actually I’ve been coming back and again the idea of drafting a book on technology patterns for developing countries to share this, but would like to make it a collaborative effort. It is simpler to point out pitfalls than to steer a course that avoids them, but that was not the point of this post. Also, any architecture is a starting point, not an endgame that does the decision-making job for you: it is place from which to begin the conversations. Even with the best architecture efforts, the responsibility of coming up with the right solutions is with the implementers.