Technology Posts

A new version of Nuntium, is out and I wanted to share some of the great new features it contains.

Nuntium is an open source and free messaging service, built with Ruby on Rails. It has a simple but powerful API that you can use to integrate your application. You can use Nuntium from InSTEDD's server or deploy it in your own machine. Join our list to get help or discuss your needs.

To put it in a simple way, Nuntium acts as your one-stop for all the messaging needs of your applications, including -but not limited to- SMS, Mail, Twitter and XMPP. It allows you to focus on your functionality without having to deal with all the crazy quirks of telephone companies infrastructure, SMS aggregators or communication protocols.

It also supports the QST protocol defined by the OpenMobile Consortium.

Every single feature built in Nuntium, is the result of a concrete need that we had during our work with messaging systems, mainly in South-East Asia -where Nuntium delivers the daily communications and disease reporting of a few thousands users- and Haiti where it served as the keystone layer for receiving and sending hundreds of thousands of messages from the 4636 shortcode. So, instead of going through the features I'll present some examples.

Share your number among many applications

Once you have created your account in Nuntium, you can add as many applications as you need. Let's imagine that after lots of negotiations you got a 1234 shortcode in Kenya and you need to use it with four applications. We'll call them "Maternal Health", "Road accidents", "Disease Reporting" and "Team chat".


For the Maternal Health application, you decided you are going to ask your users to prefix their messages with "MH". In the case of "Road accidents", your users are 5 specific individuals and you know their phone numbers. For "Disease Reporting" you are using a mobile application that sends SMS reports in a machine-readable format. And with your "Team chat" app you don't want people to have to prefix their messages.

By using Rules in Nuntium you could configure that scenario, and support 4 different applications, coded in different languages, with a single number for all of them. All that, while keeping the routing logic out of your apps, and making it transparent to each one.

Rules can change properties in the message, like removing a keyword prefix or decide to which application the message should be routed. You can do simple things like matching the start of the body, or use regex expression to target very specific formats or syntaxes.

Supporting complex, emerging, dynamic ecosystems

In many situations you might face a constantly changing environment, in which you need to switch routing rules, deliver messages through different channels according to the carrier of the recipient, or you might have to create an infrastructure by combining plugged-in phones, direct network connections to telephone companies and international aggregators. All that while keeping track of what is going on with each single message.


Nuntium is packed with lots of tools to do so. You can:

• Configure any number of SMPP connections to telephone companies
• Specify an individual throttle number for each connection
• Create rules to route messages based on their carrier, prefix, country code, or any custom attribute that you want to create
• Track each single message with a detailed log
• Define delivery strategies like broadcasting through different channels or choosing the most appropriate channel based on priorities
• Configure restrictions to the use of channels, based on country, carrier or custom attributes
• Re-route messages that failed through a specific channel, through another one
• Track credit consumed by channels.

Tracking your messages

Nuntium gives you detailed logs of what happened to each message:

• How and when it was received
• Which channels were available to send it
• Which was chosen and based on what strategy or priority
• Errors or warnings in the communication with the telco server
• Sucessful deliveries

Using Clickatell

Clickatell is the de-facto service for a quick, reliable, international messaging setup. They provide you with one or more numbers that you can use in several countries and carriers.

Nuntium supports the creation of a channel for Clickatell. All you need to configure are your credentials, decide if you want to use it as incoming, outgoing or bi-directional channel and the network that you got your number in. That network determines in which countries and carriers your phone number will work. Nuntium already imports periodically all the coverage tables from Clickatell, so you don't need to worry about that.

After doing the setup, you can either pull the messages using an RSS feed, or you can configure an endpoint in your app, an Nuntium will do a post to that URL for each incoming message. That way you don't even need to code a scheduled recurrent task to check for new messages.

Using a plugged-in phone or a gsm modem

A very common scenario in a mobile app deployment is that the use of international numbers for SMSing is either cost-prohibitive or just doesn't work. Getting a local telephone company to provide you with a cheap number and a machine-friendly interface to read and receive messages can take some time in many countries.

The default choice in this cases is to buy a local simcard, get a cheap phone and just interface through a computer.

You can also do that with Nuntium by configuring another type of channel and downloading our mobile gateway application. It's a java app, so you can run it under Windows, Linux or OSX.

The nice thing is that whenever you need to scale up and you have your short-code or long-code ready with a carrier or aggregator, you just add another channel and without changing a single line in your application, you are ready to go from a few messages per minute, to hundreds or thousands.

Allowing your apps to interact with users through Twitter, Email and Chat

Nuntium does more than sending SMS. You can use it for any other messaging channel you can think of. Mail is supported through POP3 and SMTP, so you can just create a gmail account and start sending and receiving mails from your app. Or create a twitter account and set it up. If you want your users to be able to chat with your application or receive notifications in their GTalk, Adium, or any other XMPP (ex-Jabber) client, you can also do it.

And all of this through only ONE interface. Your application doesn't have to worry if it's an SMS, email, twitter or instant message what it want to send. Just adding a prefix like "xmpp://" or "sms://" to the recipient address will tell Nuntium everything it needs to know to dispatch the message. You will also get all the incoming messages in exactly the same way.

Summary

If you need to SMS-enable your apps, or if you want to switch to something that will allow you to scale both horizontally and vertically, get in touch, we would love to help you out build a world-class app with world-class messaging powers.

During August 2009, we went on a number of field trips to health centers in remote areas of Thailand and Cambodia. The idea was to conduct a few usability tests on Geochat syntax alternatives that we were exploring. Our goal was to simplify the interaction between health workers and the system to ultimately allow them to report disease cases in a semi-structured way.

The case information always originates at the local health center level - this is where the patient comes and gets diagnosed. Most of the case reports are made through phone calls to the district level (the higher administrative level). Case details get lost when the district level summarizes the information by disease and reports the quantity of each to the provincial level.

During our visits to provincial offices, we received useful feedback which ultimately led to the design of the current syntax. However, in health centers we found a few issues that needed to be solved before any syntax at all could be used:

• Most people do not know how to send SMS.


• Some of them do not know how to read an incoming SMS.


• Support for Khmer and Thai characters is not common in the handsets and carriers most people use.


• Even if there is support for the characters, writing SMS using them is much more difficult than writing in English due to the amount of letters in the alphabet.

These posed a huge barrier to solve even before the reports could be collected. It was not about simplifying a syntax.

Reinventing the Wheel

On our way back from the visits, feeling discouraged over the challenges ahead, an idea arose. What if we decouple the process of structuring the report from the channel through it was sent? If you ask someone to send a telegraph, he does not need to know Morse code. In the same way, we could allow health workers to create the report outside the constraints of the tool being used to transmit it.

The reporting wheel has 3 concentric circles. The material can be paper, card-stock or plastic. The circles turn independently, so you can combine any set of values of each ring. On the left side is the value to be selected, on the right side a code that represents that value.

The cover of the wheel allows you to see the values you are selecting and the number you need to report. Once the user has selected the day of the month, the disease and the number of cases he wants to report, a 9 digits number is formed on the right side which represents the 3 values selected.

The user can then make a call to a reporting hotline and enter the number or send it through an SMS (it's usually much easier to train people to text numbers than letters).

Additional instructions can be written on the cover to make the tool "self-documented."

This tool is very easy to build and can be done locally; it's cheap without being fragile; can be shared and does not requires batteries. Best of all, it can be created for any language while still being language independent, that is, different wheels in different languages can contain the same codes and thus be used to report the same values. Some initial usability tests indicate that it's intuitive and easy to learn. In one particular case, a health worker was explaining how to use it to a colleague after just 5 minutes of training.

Codification

There are two issues in the codification process:

1. Mistakes in the typing of the numbers: a typo could cause a Malaria report to be mistaken for Dengue.


2. If multiple groups want to use the same reporting hotline for different kinds of reports such as veterinary diseases or crop yields, the recipient of the reports needs to know which kind of wheel it came from.

The solution for both problems happens to lie in the same trick. The codes for each reported value are selected in a way that not only allows the detection of errors in the typing, but also enables the detection of the kind of wheel used to report. With the method we developed, a total of more than 600k different wheels can be created and each can be uniquely identified with no additional information - only the 9-digit number reported is required. That means the same reporting hotline can be used to receive reports from a wide variety of sources.

At the moment we are conducting pilots in Thailand and Cambodia. We will soon have more to report on this.

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