Technology Posts

After some problems in the way messages where received before from Digicel, they have now re-routed the incoming messages (MO) through SMPP, the standard protocol for SMS messaging. Messages from both carriers are now being handled by Nuntium, an InSTEDD open source and free service for messaging.

Too much debriefing and blogging needs to be done, and this is not an attempt to do so. I just wanted to share a diagram with the current situation of connections between systems and telcos at Haiti. It's probably very technical, but good as reference:

‘Information is a vital form of aid in itself […] Disaster-affected people need information as much as water, food, medicine or shelter. Information can save lives, livelihoods and resources.’ (World Disasters Report 2005)

During 2009 we have been working with Thomson Reuters Foundation on a free and open source information management system designed to be deployed in emergencies caused by sudden onset natural disasters.

The first and basic rationale for the system is that people caught up in disasters are not helpless victims and that life saving, actionable information is as important as blankets and tarpaulin. As first responders, they need reliable information to make decisions and minimize the impact.

The aim of the system is to streamline the communication flow and collaboration between the affected population with media, aid workers and government agencies, to help citizens get verified, accurate and actionable information that will enable them to make decisions and recover from the disaster.

The EIS system also provides means for affected population and field workers to channel vital data back up into aid response.

The combination of crowd-sourcing features with collaborative analytics and machine learning tools, in the hands of a team with a vast experience on humanitarian news opens up unprecedented opportunities in the area.

This tool is part of a free information service run by Thomson Reuters Foundation to help survivors of natural disasters called EIS.

Design objectives

There is an article from Bruno Giussani that provides a very interesting insight into the future role of journalism and which I believe describes perfectly what we have been trying to do:

The new power of editors and journalists will depend on their ability to take on new tasks: to animate a group of people; to develop ways to organize how information is gathered and used, with the participation of what used to be called "the audience;" and to help people navigate an information landscape that's increasingly crowded and constantly shifting.

In line with this idea, our objectives were:

1. Collect reports originated from the very first layer of affected population - survivors; combine that with information received from the field including aid agencies, local media and government.


2. Provide fast and reliable means to filter, search and detect important information in the pool of reports.


3. Streamline the flow of information inside a distributed editorial team including local translators.


4. Reach out to affected population with useful and actionable information in a timely manner.

1-Subscription and Collection

Citizens can report their location by sending an SMS to the system with the name of the village they are. That simple action registers them in the system to receive alerts targeted to that village.

Every citizen, either registered or not, can report information to the system through SMS.

The system allows submission of raw reports through several channels:

• SMS: through mobile aggregators (like Clickatell) or plugged-in phones. People can send information to a specific number, which then stores the message in the system.

• Twitter: both streams from particular users or certain hashtags can be imported.
  


• Email: any number of email addresses can be checked by the system and directed to specific collection baskets or inboxes


• RSS: feeds can be checked periodically and new articles will appear in the system.


• Web: any user with permissions can post information using the web interface.

Bounded and Unbounded Crowd-sourcing

Through the use of a feature we called "Working groups" and in combination with the "Baskets", both bounded and unbounded crowd-sourcing processes can coexist in the stream.

Identified users can be assigned to "Working Groups" and the reports coming from those groups, can be configured to go to specific baskets. Therefore, some baskets can be monitored more often or by different people, depending on the working groups (bounded crowd) putting reports there. An unbounded basket could be even configured to be self-filtered by the same unbounded crowd and items with 10 or more people marking them as "alert" or a specific tag could then be pulled by another basket which is monitored by some agency.

The possibilities are endless and it is yet to be discovered which patterns work better depending on each situation. There is probably no silver-bullet and it'll be up to the expertise of teams deploying this to find-out, share and adjust for cultural, social and political contexts.

2-Selection and Filtering

Through a number of different tools, users monitoring the pool of raw reports can filter important information. The goal in this stage is to try to deal with as many situation awareness “demons” as possible, being data overload and context stress the most salient ones in these kinds of scenarios. These tools include search, tagging and automatic extraction of the location the text refers to. Other features that can be added to customize the experience and workflow include flagging documents, hiding them, commenting and relating them. The objective of these features is to aid in the process of collaboratively selecting useful information to initiate the editing workflow.

The platform is completely modular, allowing the customization of each collaboration space, based on the balance of features vs. simplicity.

3-Workflow

The system allows for a flexible and tailored workflow by the use of a simple but powerful metaphor:

A module called “Baskets” allows the configuration of a custom workflow tailored to the specific team and situation. The module works based on the concept of baskets. Each basket is a collection of pieces of information (items), that acts both as inbox and outbox. Each user in the system is given permissions to read, write, move in or move out items from one or more baskets.

Typically, a user would monitor one or more baskets based on his role. As new items appear, he will decide what to do, act on the item, flag it as urgent, write a comment, create a new alert or translate it to another language. He would then put the new item or the edited one in another basket for someone else to do his part of the job. The administrator is allowed to configure "baskets" and determine who can put, view, edit and remove items from those baskets. Users can then perform given tasks on the articles and move them to the next step.

The flow improves when people have not only direct access to information, but the benefit also of credible intermediaries to help discover, gather, compare, contextualize, and share information. (Knight Commision)

Different flows can be created and tuned during a deployment, ranging from a completely crowd-sourced citizen journalism to a standard editorial workflow involving translation, editing, approval, etc.

4-Informing

Once an alert is ready to be sent out to relevant recipients, the system allows the user to target affected population by location through a map with references of clusters of citizens. The user sees a map with the different groups of citizens and the number of citizens in each group.

The objective of targeting by location is not only to keep the information relevant to everyone, but also to avoid that people in a desperate situation end up traveling to a distant location just because they received a message saying there is food or blankets there.

The alert can be sent through SMS and Email, and can also be addressed to specific working groups, like aid workers, local media or government agencies.

Technology

The EIS system was built on top of RIFF (http://instedd.org/evolve), an InSTEDD platform tool developed as a general collaboration environment for content creation, social metadata annotation, and automated analysis with potential applicability in a wide range of areas.

Results

A recent pilot of the system in Tomohon, North Sulawesi Indonesia, in partnership with the Local Red Cross and the Search and Rescue Team, has proved the validity of our assumptions. Even if the incoming stream of reports from the field contained (by design) a low signal/noise ratio, the editorial team managed to process the information, select relevant topics and going through a quick but reliable loop with local translators could provide alerts with verified data.

A short summary of the pilot can be seen here

Conclusion

We have built a tool that can handle information collection, flow and reach out in a wide range of deployment scenarios in disaster situations, providing the support for channeling information up and down as needed among a heterogeneous ecosystem of stakeholders. The system will serve as the basis for further learning, development and work on the subject.

We have been in PP (Phnom Penh) for about a week now to start up our Mekong Collaboration Program. Cambodia is going to be the first site for our field tests, and we are working closely with the Ministry of Health and NGOs to identify the requirements and scope of our work. Our primary objective is to support the Cambodian Center for Disease Control in their ability to detect and respond rapidly to priority diseases (including cholera, dengue, and others). Our secondary objective is to develop a set of tools that can be sustained because there is a market for these tools within and beyond the health sector (and even in the commercial sector).

One of our top priorities on this trip has been to get a deeper understanding of the technology infrastructure and staffing. Our technology team, including Ed, our Director of Engineering, believe strongly the tools need to engage and draw on Cambodian talent to be useful and to enable a Cambodian team to provide support after we leave. We welcome ideas on how to build technology sustainably or connections in Cambodia you might recommend.

One of our favorite NGOs is the Khmer Software Initiative, whose vision is "a country where Cambodians can learn and use computers in their own language, a country that does not have to change to a new language in order to use computers!" We are also concerned with this question because many software applications here are only in English, including mobile phone text messaging. There are some Khmer cell phones, but their reach is still limited. A serious question we are exploring is: how will widespread access to Khmer text messaging be possible?

I just returned from India, a personal trip to attend a friend's wedding that also included many opportunities to explore how InSTEDD could serve the communities here. Disaster and public health are both top priorities here. India was in the midst of a major polio vaccination push, with banners displayed around Dehli encouraging families to get their children immunized on a mass immunization day - January 6th. In the eastern region, they are responding to the the once every 48 year bamboo bloom that brings with it thousands of rats and mass exoduses.

The most interesting discovery was during a conversation with my friend, Chhaya Kunmar, who works for an NGO in the Himalayan mountain regions south of Nepal. The founders of Himalayan Action Research Centre realized the greatest way they could empower people of the rural areas was to provide information. The center of HARC's platform is to share information and provide training to these rural villagers, and information alone, without direct financial aid, has had a tremendous effect. They showed villagers how worthwhile organizing into farmer groups could be, and they also introduced these farmers to large buyers who could give them better prices. These two efforts resulted in orange farmers earning from 1 cent a kilo to 5 cents a kilo. It turns out these rural villagers simply did not have easy access to information and resources that would help them improve their lives. But what is most significant is HARC's approach. They do not arrange the buying or tell farmers what to grow; they simply introduce them to better opportunities and allow the farmers to decide.

This model is relevant to InSTEDD's efforts to use technology to gather and share information more effectively in remote regions of the world.

Technology had penetrated these hill stations (though I would call them mountains they were so enormous) but to a lesser extent than one would think of India. In the village of Naugaun in the state of Uttranchal, some farmers have cell phones, and anyone with a job outside the subsistence sector has a cell phone. There was no internet cafe in the village, and computers were definitely limited to the NGO, and were further limited by the regular power outages in the village.

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)

Recommended reading

• HMN’s framework
• Taha’s blog (Taha is quietly helping in some continent-wide health system integration efforts, and has a lot of experience in this area)
• Christopher Alexander and The Timeless Way of Building introduced patterns and pattern languages to describe what would otherwise be a complex, multidimensional knowledge base of architectural approaches to building homes.
• One of Chris Seebregts’s latest presentations on SlideShare.
• Sketching User Experiences about the role of design and how it relates to successes in technology .

Last week, I presented Evolve; InSTEDD's Global Early Warning and Response System, at the 2009, American Medical Informatics Association (AMIA) Spring Congress. The conference took place at the Walt Disney World Swan, May 28th–30th, in Orlando, Florida, USA. Here is the presentation:

Data source: A(H1N1) Evolve Collaborative Workspace

Note: Tag cloud was created on Many Eyes © IBM (click here for a live version)

Note: Tag cloud was created on Many Eyes © IBM (click here for a live version)

Note: Map was created on Many Eyes © IBM (click here for a live version)

Related Links:

• Tracking A(H1N1) using Evolve
  
• Low volume Evolve announcements on Twitter
• Extremely Affordable Health Innovations
  
• MBDS ICT and Technology Forum
  
• Best Poster Award for Improving Public Health Investigation and Response at the Seventh Annual International Society for Disease Surveillance Conference
• Collaborative Analytics and Environment for Linking Early Event Detection to an Effective Response

On October 13-15, 2008, over 65 people gathered from around Cambodia to participate in a Cambodian CDC-led Avian Influenza (AI) pandemic training and simulation exercise in the Stung Treng province, Cambodia. Cambodia CDC provided the public health training and InSTEDD introduced and tested GeoChat for the first time demonstrating the utility of mobile phones to help with cross-disciplinary and cross-regional pandemic preparedness and response.



Here my After Action Trip Report (a summary is also provided on the InSTEDD site).
Related Links:

• What is GeoChat
  
• GeoChat Tool
  
• Your wishes for GeoChat
• Ed on GeoChat
• Taha on GeoChat
  

Earlier this month, I presented our vision for an Integrated Global Early Warning and Response System at the Seventh Annual International Society for Disease Surveillance Conference, December 3-5, 2008 at the Raliegh Conference Civic Center. We received the most votes in the "Best Poster" award category for the "Improving Public Health Investigation and Response" track. You can also download the article abstract from here.