Disaster responders cannot be everywhere at the same time, but the crowd is always there. The same is true for health care professionals such as critical care paramedics who work with an ambulance service. Paramedics cannot be posted everywhere. Can crowdsourcing help? This was the question posed to me by my colleague Mark who overseas the ambulance personnel for a major city.
Take Sudden Cardiac Arrest (SCA), for example. SCA’s account for an estimated 325,000 deaths each year in the US—one person every two minutes. Survival rates nationally are less than 8%. But Cardio-Pulmonary Resuscitation, or CPR, can sustain life until paramedics arrive by maintaining blood flow to the heart and brain. “Without oxygen-rich blood, permanent brain damage or death can occur in less than 8 minutes. After 10 minutes there is little chance of successful resuscitation. Even in modern urban settings the response times for professional rescuers commonly approach these time frames” (1). This explains why “effective bystander CPR, provided immediately after sudden cardiac arrest, can double or triple a person’s chance of survival” (2). In fact, close to 60% of adults in the US say they have taken CPR training (often due to school requirements) and 11% say they have used CPR in an actual emergency (3).
So why not develop a dedicated smartphone app to alert bystanders when someone nearby is suffering from a Sudden Cardiac Arrest? This is what Mark was getting at when we started this conversation back in April. Well it just so happens that such an app does exist. The PulsePoint mobile app “alerts CPR-trained bystanders to someone nearby having a sudden cardiac arrest that may require CPR. The app is activated by the local public safety communications center simultaneous with the dispatch of local fire and EMS resources” (4).
In sum, the purpose of the app is to increase survival rates by:
Reducing collapse-to-CPR times by increasing citizen awareness of cardiac events beyond a traditional “witnessed” area.
Reducing collapse-to-defibrillation times by increasing awareness of public access defibrillator (AED) locations through real-time mapping of nearby devices.
The PulsePoint approach is instructive to those of us applying technology to improve international humanitarian response. First, the app works within, not outside, existing institutions. When someone calls 911 to report a cardiac arrest, paramedics are still dispatched to the scene. At the same time, emergency operators use PulsePoint to alert registered bystanders in the area. Second, volunteers who receive an alert are provided with a map of nearby AEDs, i.e., additional “meta-data” important for rapid response. Third, training is key. Without CPR training, the “crowd” is not empowered to help. So Community Emergency Response Teams (CERTs) are important. Of course, not all needs require special expertise to be fulfilled, but preparedness still goes a long way.
My colleague Samia Kallidis is launching a brilliant self-help app to facilitate community-based disaster recovery efforts. Samia is an MFA Candidate at the School of Visual Arts in New York. While her work on this peer-to-peer app began as part of her thesis, she has since been accepted to the NEA Studio Incubator Program to make her app a reality. NEA provides venture capital to help innovative entrepreneurs build transformational initiatives around the world. So huge congrats to Samia on this outstanding accomplishment. I was already hooked back in February when she presented her project at NYU and am even more excited now. Indeed, there are exciting synergies with the MatchApp project I’m working on with QCRI and MIT-CSAIL , which is why we’re happily exploring ways to collaborate & complement our respective initiatives.
Samia’s app is aptly called Jointly and carries the tag line: “More Recovery, Less Red Tape.” In her February presentation, Samia made many very compelling arguments for a self-help approach to disaster response based on her field research and interviews she conducted following Hurricane Sandy. She rightly noted that many needs that arise during the days, weeks and months following a disaster do not require the attention of expert disaster response professionals—in fact these responders may not have the necessary skills to match the needs that frequently arise after a disaster (assuming said responders even stay the course). Samia also remarked that solving little challenges and addressing the little needs that surface post-disaster can make the biggest differences. Hence Jointly. In her own words:
“Jointly is a decentralized mobile application that helps communities self-organize disaster relief without relying on bureaucratic organizations. By directly connecting disaster victims with volunteers, Jointly allows individuals to request help through services and donations, and to find skilled volunteers who are available to fulfill those needs. This minimizes waste of resources, reduces duplication of services, and significantly shortens recovery time for individuals and communities.”
Samia kindly shared the above video and screenshots of Jointly below.
I’m thrilled to see Jointly move forward and am excited to be collaborating with Samia on the Jointly and MatchApp connection. We certainly share the same goal: to help people help themselves. Indeed, increasing this capacity for self-organization builds resilience. These connection technologies and apps provide for more rapid and efficient self-help actions in times of need. This doesn’t mean that professional disaster response organizations are obsolete—quite on the contrary, in fact. Organizations like the American Red Cross can feed relevant service delivery data to the apps so that affected communities also know where, when and how to access these. In Jointly, official resources will be geo-tagged and updated live in the “Resources” part of the app.
You can contact Samia directly at: hello@jointly.us should you be interested in learning more or collaborating with her.
A colleague of mine at Google recently shared a new and very interesting Web App that tracks breaking news events by monitoring Wikipedia edits in real-time. The App, Wikipedia Live Monitor, alerts users to breaking news based on the frequency of edits to certain articles. Almost every significant news event has a Wikipedia page that gets updated in near real-time and thus acts as a single, powerful cluster for tacking an evolving crisis.
Social media, in contrast, is far more distributed, which makes it more difficult to track. In addition, social media is highly prone to false positives. These, however, are almost immediately corrected on Wikipedia thanks to dedicated editors. Wikipedia Live Monitor currently works across several dozen languages and also “cross-checks edits with social media updates on Twitter, Google Plus and Facebook to help users get a better sense of what is trending” (1).
I’m really excited to explore the use of this Live Monitor for crisis response and possible integration with some of the humanitarian technology platforms that my colleagues and I at QCRI are developing. For example, the Monitor could be used to supplement crisis information collected via social media using the Artificial Intelligence for Disaster Response (AIDR) platform. In addition, the Wikipedia Monitor could also be used to triangulate reports posted to our Verily platform, which leverages time-critical crowdsourcing techniques to verify user-generated content posted on social media during disasters.
GDACS, the Global Disaster Alert and Coordination System, sparked my interest in technology and disaster response when it was first launched back in 2004, which is why I’ve referred to GDACS in multiple blog posts since. This near real-time, multi-hazard monitoring platform is a joint initiative between the UN’s Office for the Coordination of Humanitarian Affairs (OCHA) and the European Commission (EC). GDACS serves to consolidate and improve the dissemination of crisis-related information including rapid mathematical analyses of expected disaster impact. The resulting risk information is distributed via Web and auto-mated email, fax and SMS alerts.
I recently had the pleasure of connecting with two new colleagues, Daniel Link and Adam Widera, who are researchers at the University of Muenster’s European Research Center for Information Systems (ERCIS). Daniel and Adam have been working on GDACSmobile, a smartphone app that was initially developed to extend the reach of the GDACS portal. This project originates from a student project supervised by Daniel, Adam along with the Chair of the Center Bernd Hellingrath in cooperation with both Tom de Groeve from the Joint Research Center (JRC) and Minu Kumar Limbu, who is now with UNICEF Kenya.
GDACSmobile is intended for use by disaster responders and the general public, allowing for a combined crowdsourcing and “bounded crowdsourcing” approach to data collection and curation. This bounded approach was a deliberate design feature for GDACSmobile from the outset. I coined the term “bounded crowd-sourcing” four years ago (see this blog post from 2009). The “bounded crowd-sourcing” approach uses “snowball sampling” to grow a crowd of trusted reporters for the collection of crisis information. For example, one invites 5 (or more) trusted local reports to collect relevant information and subsequently ask each of these to invite 5 additional reporters who they fully trust; And so on, and so forth. I’m thrilled to see this term applied in practical applications such GDACSmobile. For more on this approach, please see these blog posts.
GDACSmobile, which operates on all major mobile smartphones, uses a delibera-tely minimalist approach to situation reporting and can be used to collect info-rmation (via text & image) while offline. The collected data is then automatically transmitted when a connection becomes available. Users can also view & filter data via map view and in list form. Daniel and Adam are considering the addition of an icon-based data-entry interface instead of text-based data-entry since the latter is more cumbersome & time-consuming.
Meanwhile, the server side of GDACSmobile facilitates administrative tasks such as the curation of data submitted by app users and shared on Twitter. Other social media platforms may be added in the future, such as Flickr, to retrieve relevant pictures from disaster-affected areas (similar to GeoFeedia). The server-side moderation feature is used to ensure high data quality standards. But the ERCIS researchers are also open to computational solutions, which is one reason GDACSmobile is not a ‘data island’ and why other systems for computational analysis, microtasking etc., can be used to process the same dataset. The server also “offers a variety of JSON services to allow ‘foreign’ systems to access the data. […] SQL queries can also be used with admin access to the server, and it would be very possible to export tables to spreadsheets […].”
I very much look forward to following GDACSmobile’s progress. Since Daniel and Adam have designed their app to be open and are also themselves open to con-sidering computational solutions, I have already begun to discuss with them our AIDR project (Artificial Intelligence for Disaster Response) project at the Qatar Computing Research Institute (QCRI). I believe that making the ADIR-GDACS interoperable would make a whole lot of sense. Until then, if you’re going to this year’s International Conference on Information Systems for Crisis Response and Management (ISCRAM 2013) in May, then be sure to participate in the workshop (PDF) that Daniel and Adam are running there. The side-event will present the state of the art and future trends of rapid assessment tools to stimulate a conver-sation on current solutions and developments in mobile tech-nologies for post-disaster data analytics and situational awareness. My colleague Dr. Imran Muhammad from QCRI will also be there to present findings from our crisis computing research, so I highly recommend connecting with him.
Disaster response apps have multiplied in recent years. I’ve been reviewing the most promising ones and have found that many cater to professional responders and organizations. While empowering paid professionals is a must, there has been little focus on empowering the real first responders, i.e., the disaster-affected communities themselves. To this end, there is always a dramatic mismatch in demand for responder services versus supply, which is why crises are brutal audits for humanitarian organizations. Take this Red Cross survey, which found that 74% of people who post a need on social media during a disaster expect a response within an hour. But paid responders cannot be everywhere at the same time during a disaster. The response needs to be decentralized and crowdsourced.
In contrast to paid responders, the crowd is always there. And most survivals following a disaster are thanks to local volunteers and resources, not external aid or relief. This explains why FEMA Administrator Craig Fugate has called on the public to become a member of the team. Decentralization is probably the only way for emergency response organizations to improve their disaster audits. As many seasoned humanitarian colleagues of mine have noted over the years, the majority of needs that materialize during (and after) a disaster do not require the attention of paid disaster responders with an advanced degree in humanitarian relief and 10 years of experience in Haiti. We are not all affected in the same way when disaster strikes, and those less affected are often very motivated and capable at responding to the basic needs of those around them. After all, the real first responders are—and have always been—the local communities themselves, not the Search and Rescue Teams that parachutes in 36 hours later.
In other words, local self-organized action is a natural response to disasters. Facilitated by social capital, self-organized action can accelerate both response & recovery. A resilient community is therefore one with ample capacity for self-organization. To be sure, if a neighborhood can rapidly identify local needs and quickly match these with available resources, they’ll rebound more quickly than those areas with less capacity for self-organized action. The process is a bit like building a large jigsaw puzzle, with some pieces standing for needs and others for resources. Unlike an actual jigsaw puzzle, however, there can be hundreds of thousands of pieces and very limited time to put them together correctly.
This explains why I’ve long been calling for a check-in & match.com smartphone app for local collective disaster response. The talk I gave (above) at Where 2.0 in 2011 highlights this further as do the blog posts below.
This “MatchApp” could rapidly match hyper local needs with resources (material & informational) available locally or regionally. Check-in’s (think Foursquare) can provide an invaluable function during disasters. We’re all familiar with the command “In case of emergency break glass,” but what if: “In case of emergency, then check-in”? Checking-in is space- and time-dependent. By checking in, I announce that I am at a given location at a specific time with a certain need (red button). This means that information relevant to my location, time, user-profile (and even vital statistics) can be customized and automatically pushed to my MatchApp in real-time. After tapping on red, MatchApp prompts the user to select what specific need s/he has. (Yes, the icons I’m using are from the MDGs and just placeholders). Note that the App we’re building is for Androids, not iPhones, so the below is for demonstration purposes only.
But MatchApp will also enable users who are less (or not) affected by a disaster to check-in and offer help (by tapping the green button). This is where the match-making algorithm comes to play. There are various (compatible options) in this respect. The first, and simplest, is to use a greedy algorithm. This algorithm select the very first match available (which may not be the most optimal one in terms of location). A more sophisticated approach is to optimize for the best possible match (which is a non-trivial challenge in advanced computing). As I’m a big fan of Means of Exchange, which I have blogged about here, MatchApp would also enable the exchange of goods via bartering–a mobile eBay for mutual-help during disasters.
Once a match is made, the two individuals in question receive an automated alert notifying them about the match. By default, both users’ identities and exact locations are kept confidential while they initiate contact via the app’s instant messaging (IM) feature. Each user can decide to reveal their identity/location at any time. The IM feature thus enables users to confirm that the match is indeed correct and/or still current. It is then up to the user requesting help to share her or his location if they feel comfortable doing so. Once the match has been responded to, the user who received help is invited to rate the individual who offered help (and vice versa, just like the Uber app, depicted on the left below).
As a next generation disaster response app, MatchApp would include a number of additional data entry features. For example, users could upload geo-tagged pictures and video footage (often useful for damage assessments). In terms of data consumption and user-interface design, MatchApp would be modeled along the lines of the Waze crowdsourcing app (depicted on the right above) and thus designed to work mostly “hands-free” thanks to a voice-based interface. (It would also automatically sync up with Google Glasses).
In terms of verifying check-in’s and content submitted via MatchApp, I’m a big fan of InformaCam and would thus integrate the latter’s meta-data verification features into MatchApp: “the user’s current GPS coordinates, altitude, compass bearing, light meter readings, the signatures of neighboring devices, cell towers, and wifi networks; and serves to shed light on the exact circumstances and contexts under which the digital image was taken.” I’ve also long been interested in peer-to-peer meshed mobile communication solutions and would thus want to see an integration with the Splinternet app, perhaps. This would do away with the need for using cell phone towers should these be damaged following a disaster. Finally, MatchApp would include an agile dispatch-and-coordination feature to allow “Super Users” to connect and coordinate multiple volunteers at one time in response to one or more needs.
In conclusion, privacy and security are a central issue for all smartphone apps that share the features described above. This explains why reviewing the security solutions implemented by multiple dating websites (especially those dating services with a strong mobile component like the actual Match.com app) is paramount. In addition, reviewing security measures taken by Couchsurfing, AirBnB and online classified adds such as Craig’s List is a must. There is also an important role for policy to play here: users who submit false misinformation to MatchApp could be held accountable and prosecuted. Finally, MatchApp would be free and open source, with a hyper-customizable, drag-and-drop front- and back-end.
I recently met up with some Facebook colleagues to discuss the role that they and their platform might play in disaster response. So I thought I’d share some thoughts that come up during the conversation seeing as I’ve been thinking about this topic with a number of other colleagues for a while. I’m also very interested to hear any ideas and suggestions that iRevolution readers may have on this.
There’s no doubt that Facebook can—and already does—play an important role in disaster response. In Haiti, a colleague used Facebook to recruit hundreds of Creole speaking volunteers to translate tens of thousands of text messages into English as part of our Ushahidi-Haiti crisis mapping efforts. When an earth-quake struck New Zealand earlier this year, thousands of students organized their response via a Facebook group and also used the platform’s check-in’s feature to alert others in their social network that they were alright.
But how else might Facebook be used? The Haiti example demonstrates that the ability to rapidly recruit large numbers of volunteers is really key. So Facebook could create a dedicated landing page when a crisis unfolds, much like Google does. This landing page could then be used to recruit thousands of new volunteers for live crisis mapping operations in support of humanitarian organizations (for example). The landing page could spotlight a number of major projects that new volunteers could join, such as the Standby Volunteer Task Force (SBTF) or perhaps highlight the deployment of an Ushahidi platform for a particular crisis.
The use of Facebook to recruit volunteers presents several advantages, the most important ones being identity and scale. When we recruited hundreds of new volunteers for the Libya Crisis Map in support of the UN’s humanitarian response, we had to vet and verify each and every single one of them twice to ensure they were who they really said they were. This took hours, which wouldn’t be the case using Facebook. If we could set up a way for Facebook users to sign into an Ushahidi platform directly from their Facebook account, this too would save many hours of tedious work—a nice idea that my colleague Jaroslav Valuch suggested. See Facebook Connect, for example.
Facebook also operates at a scale of more than half-a-billion people, which has major “Cognitive Surplus” potential. We could leverage Facebook’s ad services as well—a good point made one Facebook colleague (and also Jon Gosier in an earlier conversation). That way, Facebook users would receive targeted adds on how they could volunteer based on their existing profiles.
So there’s huge potential, but like much else in the ICT-for-you-name-it space, you first have to focus on people, then process and then the technology. In other words, what we need to do first is establish a relationship with Facebook and decide on the messaging and the process by which volunteers on Facebook would join a volunteer network like the Standby Volunteer Task Force and help out on an Ushahidi map, for example.
Absorbing several hundred or thousands of new volunteers is no easy task but as long as we have a simple and efficient micro-tasking system via Facebook, we should be able to absorb this surge. Perhaps our colleagues at Facebook could take the lead on that, i.e, create a a simple interface allowing groups like the Task Force to farm out all kinds of micro-tasks, much like Crowdflower, which already embeds micro-tasks in Facebook. Indeed, we worked with Crowdflower during the floods in Pakistan to create this micro-tasking app for volunteers.
As my colleague Jaroslav also noted, this Mechanical Turk approach would allow these organizations to evaluate the performance of their volunteers on particular tasks. I would add to this some gaming dynamics to provide incentives and rewards for volunteering, as I blogged about here. Having a public score board based on the number of tasks completed by each volunteer would be just one idea. One could add badges, stickers, banners, etc., to your Facebook profile page as you complete tasks. And yes, the next question would be: how do we create the Farmville of disaster response?
On the Ushahidi end, it would also be good to create a Facebook app for Ushahidi so that users could simply map from their own Facebook page rather than open up another browser to map critical information. As one Facebook colleague also noted, friends could then easily invite others to help map a crisis via Facebook. Indeed, this social effect could be most powerful reason to develop an Ushahidi Facebook app. As you submit a report on a map, this could be shared as a status update, for example, inviting your friends to join the cause. This could help crisis mapping go viral across your own social network—an effect that was particularly important in launching the Ushahidi-Haiti project.
As a side note, there is an Ushahidi plugin for Facebook that allows content posted on a wall to be directly pushed to the Ushahidi backend for mapping. But perhaps our colleagues at Facebook could help us add more features to this existing plugin to make it even more useful, such add integrating Facebook Connect, as noted earlier.
In sum, there are some low hanging fruits and quick wins that a few weeks of collaboration with Facebook could yield. These quick wins could make a really significant impact even if they sound (and are) rather simple. For me, the most exciting of these is the development of a Facebook app for Ushahidi.
I thrive when working across disciplines, building diverse cross-cutting coalitions to create, translate and apply innovative strategies driven by shared values. This has enabled the 20+ organizations I’ve worked with, and those I’ve led, to accelerate meaningful and inclusive social impact.
Which is why I've been called a social entrepreneur and a translational leader by successful innovators. President Clinton once called me a digital pioneer, while recent colleagues describe me as kind, dedicated, values-driven, authentic, creative, ethical, and impactful.
iRevolutions 