Check-In’s with a Purpose: Applications for Disaster Response

This is the second post in my check-in’s-with-a-purpose series. The first post looked at the use of check-in’s to coordinate activist campaigns and street protests. The check-in’s series builds on Ushahidi’s free and open-source check-in service (CI) slated to launch in just a few weeks at SxSW 2011.

So how might organizations and local groups be able to use CI for disaster response? In three ways: (1) preparedness; (2) coordination; and (3) evaluation.

Preparedness

When you walk into a disaster area, say following an earthquake, you don’t want to be swamped with all kinds of information imaginable. You only want information relevant to you and your responsibilities in a given geographic area (demand side versus supply side). CI provides an easy, intuitive interface for this. You check-in when you want additional info about the area you are in.

This is similar to the idea of geo-caching, hence the reference to preparedness. You embed (or pre-populate) a given map with relevant structural and event-data for a given area. By structural data, I mean physical infrastructure such as hospitals, schools, etc. Event-data simply refers to nearby incidents. New data could be regularly embedded into the map (via geo-RSS feeds) to provide the latest event-data available. When you check-in, CI provides you with information and updates relevant to your vicinity and profile. For example, if you’ve added “health” as a tag on your profile, CI could prioritize health-based information when you check-in, including the location of other health-workers and their contact info.

There is another equally important angle to preparedness when it comes to check-in’s. Mapping infrastructure vulnerable to disasters is common practice in disaster risk reduction projects. These can be community-driven and participatory, giving local communities a stake in building their own resilience. In one such project, local communities in neighborhoods around Istanbul mapped infrastructure vulnerable to earthquake damage, e.g., overhanging structures like balconies. They also mapped local shelters, possible escape routes, etc. CI could be used for this type of crowdsourced, participatory mapping. Crowdfeeding would then simply happen by checking-in. The sign “In case of emergency, break glass” would become “In case of emergency, check-in.”

Coordination

What about coordination? Keeping track of who is in a disaster area, and where, is no easy task. A check-in service would go a long way to addressing this coordination challenge. Call it instant mapping. Disaster responders would simply click the check-in app on their smart phones after they land in a disaster area to check-in. Each organization could set up their own check-in service to coordinate their staff with instant maps. Check-in deployments could also be project- or cluster-based.

In addition, an open check-in deployment could be set up for all responders. A separate CI deployment would be especially useful if hundreds of volunteers decide to fly in. They could be tasked more efficiently if they first checked-in. Doing so would provide coordinators with access to individual profiles with listed skill sets and contact info, much like a LinkedIn profile. Disaster responders and volunteers could also check-out once they leave a disaster area.

A check-in service could facilitate a number of other coordination challenges. Finding missing persons after a disaster has always been difficult, for example. One way to let others know you’re ok would be by checking in. Doing so would prompt the CI service to provide you with the latest on the disaster that took place, information on nearby services and who in your own professional or social network is in the vicinity long with their contact info. This could also be a way to coordinate corporate social responsibility projects in the immediate aftermath of a disaster. Large companies with employees wanting to help could simply check-in to their CI service to get information on how to help.

Evaluation

Check-in’s could also be used for evaluation and accountability purposes. Once you’ve accomplished a task, you could quickly check-in with an update, which would leave a digital trace of your accomplishment. Or say you’re on your way to a food distribution site and drive past some newly flooded houses, you could quickly check-in with that information to update everyone else on your network. CI can also be used with badges and points, allowing people to develop a track-record of their work in a disaster area.

Some Challenges

There are of course some challenges in using a CI service for disaster response. Keep it simple. This is perhaps the most important point. One could very easily go all out and add countless features to a CI service. Such is the beauty of open source software. For disaster response, however, the trick will be to keep it simple and not try to turn CI into a solution for everything. If data coverage isn’t possible, then a check-in service should allow for SMS-based check-in’s. This could be done by using SMSsync. Another challenge will be to provide a seamless way to check into multiple CI deployments at the same time and for these to be interoperable. For example, if I’m with WFP, I should be able to check-in on the WFP CI and have my check-in appear simultaneously on the Food Cluster CI, OCHA CI, etc.

If you have ideas about how a check-in service could be used for disaster response, or recommendations on what would make Ushahidi’s CI system more useful, please do add them in the comments section below. My next post in this check-in’s-with-a-purpose series will describe how a CI service combined with gaming can be used to catalyze civic participation and engagement across a range of activities.