The Economist (again!), Fuse, and Chris Blow

admin — Wed, 10 Jun 2009 00:17:29 -0500

Once again the Technology Quarterly section of the Economist has selected a focus on InSTEDD and our work in Asia, this time for sensors, sensitivity, and the use of mobile devices for data collection. The pleasant face you see on the GeoChat screenshot that opens the article is our Vice President for Engineering, Eduardo Jezierski, working within our Innovation Laboratory in Phnom Penh, Cambodia. More on the Lab below.

The article (which you can find here) quotes several informed and articulate sources, including staff at MIT and Path Intelligence, regarding the usefulness of mobile devices in general and our approach to data collection in particular. From my reading it's a fairly nice validation of our design and methods.

We'll soon be talking more about our Mesh4x client, called Fuse, that I'm pretty excited about. Mesh4x, the code library, works beautifully (we find a minor bug every few months and fix it) but it's been a developer's tool. Fuse will change that, and we have layers of plans beyond that simple but elegant client. One of the very talented people looking over the design of the interface is the remarkable Chris Blow, who did such beautiful work for our valued colleagues at Ushahidi and who is now working within our Innovation Laboratory in Cambodia. Chris - a very impressive intelligence - is just visiting, but while he's with us he's helping the Cambodian lab students learn techniques that let them design user interfaces that make sense for their Cambodian customers. This Innovation Lab idea is really fascinating and it seems to be working well. So is Chris, for that matter. Take a look at his blog here.

InSTEDD in a very brief TV interview on Fox

admin — Tue, 09 Jun 2009 23:52:19 -0500

This morning started very early, with a live Fox Business News interview about InSTEDD that you can view here. The interview was done within the fascinating Computer History Museum just off the Google Campus in Mountain View, and really, really early in the morning.

Fox was apparently pleased with the few minutes and the producer of Fox Business, Gary Kaye, came up afterwards to request a little more interview time in the future. He said he was surprised to see such a combination of tech and humanitarian support and wanted to know more. Stay tuned.

(Again, the link is here.)

Eric

Architecture, Mobiles, and Health: 10 pitfalls

admin — Sun, 07 Jun 2009 23:36:13 -0500

The “eHealth” space (which obviously includes the mobile, mHealth aspects), is a bit too chaotic from the perspective of a common developing country. Imagine you are responsible for ICT (Information and Communication Technology) of a ministry of health or hospital wanting to modernize to improve patient outcomes or disease detection. Where do you start? What could work and what won’t, for you? What is reliable? What is the fine print?

Unfortunately, this is not just because of a rapid pace of innovation in technology, or the extreme conditions in which these health solutions have to exist.

Some of the confusion is –unwillingly- created and perpetuated by the same organizations that are trying to help in the space. This includes international organizations, academia, NGOs, funders, open technology groups, private tech vendors, etc. Types of issues I’ve run into first-hand include:

Academic projects that collect data with preference towards information that will help to publish a paper rather than the information that will be the most actionable or help community health the most. The project rarely fits in with other technologies already deployed.
Funders that sponsor the construction of specialized, one-off, disease-specific systems, that are built from scratch even if architecturally they are the same as other specialized, one-off, disease-specific projects.
Technology vendors fostering ‘data sharing’ projects where the data ends up shared but, unfortunately, ‘owned’ by the vendor.
Open technology projects that would rather accrete features or add cool gizmos that attract users into a do-it-all system rather than open up information and let the data flow around to other applications.
Groups that would rather implement anything new, now, regardless of what already works, than to help a developing country figure out what they really need.

Some of organizations are fortunately waking up to these issues and starting initiatives to reduce their occurrence. A key component of these initiatives is to bringing in an architectural approach to the evaluation, planning, implementation and assessment of ICT needs. And fortunately these organizations have people that both know the problem space and have worked as architects in other contexts.

By an ‘architectural approach’ I mean an approach that:

Separates the discussions of capability from implementation. e.g. a medical record system is a capability a hospital needs, OpenMRS or OpenVISTA are two implementation alternatives that could fulfill that need.
Understands the role of standards in supporting interoperable building blocks that can evolve over time, not as an end in of itself.
Helps transition the end goals, requirements and capabilities of the overall health system - the ‘business’ architecture - into ‘technology’, ‘integration’ and ‘infrastructure’ architectures that only exist to support the end goals.
Navigates the tension between the potential benefits of centralized, top-down decision making around ICT versus the potential benefits of decentralized, bottoms-up decision making.

What would it look like from the perspective of an implementer if the eHealth/mHealth community took such an approach? Here are some things you could imagine:

You would get something like a capability map, a set of boxes with labels and lines that describe common elements of an eHealth countrywide health information system (HIS), including capabilities such as medical records, biosurveillance, pharmacy stock management, etc.
You would be able to write on this map which capabilities you have implemented (digitally or not), and for each capability get some performance metrics that can help you rank its effectiveness. For example, a biosurveillance component would assess the timeliness and completeness of reports. Your capability maps would help you do an assessment against this metrics, letting you see your maturity, and your weak spots. This assessment by itself is a huge asset for a country and funders, as it lets you understand the landscape before you aim your efforts.
Using the same taxonomy of capabilities, a technology team should be able to find open source solutions, papers, and case studies that describe if/how the capability can be improved. Ideally, these case studies should roll up to a community-maintained pattern library, that describes the distilled “solutions to a problem in a context” that have been discovered previously.
Any improvements can be measured over time and pilots can be assessed objectively as to how much they contribute to the goals of the country (currently, organizations running pilots set up their own measures and they aren’t always traceable to the measures a host country cares about).
Funders could work together helping implement solutions that work together and not on a per-project, per-disease basis.
Finally, any local innovations could be tracked and published against that map, helping discovery by others wanting to implement it elsewhere, contribute code, etc. Assisting the discovery and amplification of bottom-up ideas is critical as the eHealth space is very much giving its first steps.

So an architectural approach makes it easier to implement, build and fund technology for eHealth. So let’s look at what holds this space back and some potential issues that may crop up by rushing in.

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.

The landscape is improving

Here are some efforts I like because I think they are taking the right steps to creating long-lasting value. If you know of other relevant initiatives please feel free to add comments below

Health Metrics Network (institutional/Wikipedia)

HMN is a multilateral effort supported by funders, WHO and many organizations to define and help implement a framework for health information systems.

OASIS: Chris Seebregts and others have been putting together an effort called OASIS to help contribute to this space. I haven’t seen much official content about OASIS yet, but knowing Chris and his deep experience in the field I know that he is likely to endorse things that really work, and has direct access to the ‘proven practices’ in his work on OpenMRS and other technology efforts in Africa.

(This is not to be confused with the well-known OASIS consortium http://www.oasis-open.org/ which has IBM, Microsoft, Oracle and Sun as founding members)

A little information about InSTEDD

admin — Fri, 29 May 2009 16:30:09 -0500

Wow. Over the past few weeks, interest in InSTEDD and in our tools, Innovation Lab, and advisory role has skyrocketed. We find we're receiving about a four requests a week for some sort of work somewhere in the world. Over the past few days, for example, we've had conversations about opportunities in Israel, Pakistan, Georgia (the one next to Belarus, not the one with peaches), Italy, and Tajikistan.

To get a jump start on some of these conversations, and to wrap some some of what we do into a neater package, we've developed a Fact Sheet. It's brief, just a two-pager, plus a page around a few of our achievements. To keep it brief we've minimized some of the very cool work being done by Taha Kass-Hout in Atlanta, and the separate work being done by Romdoul Kim and the Innovation Lab team in Cambodia, but it's enough to get the flavor of our skills.

Please feel free to download it here, and to contact me, or anyone at InSTEDD, if there is some project you think might be interesting for us to do together. You can reach me, as always, at Rasmussen@InSTEDD.org.

Eric

InSTEDD Team Blogs