The usefulness and ease-of-use of interactive voice, with Freedom Fone, for Sarvodaya Community Emergency Response Team (CERT) members to supply incident information was blogged two weeks back. Now the question is “how is all that information put to use in responding to those incidents?”. In here we tell parts of that story.

CERT members call one of the four telephone numbers to access Freedom Fone; then press the “reporting” menu item number on their phone keypad to record a “field observation report”. That report is received and stored in the Freedom Fone inbox as an audio file (MP3) at Sarvodaya’s Hazard Information Hub (essentially the data center belonging to the Sarvodaya Community Disaster Management Center). Trained HIH Operators (HIHO) listen to those local language spoken incident field observations, then transform them in to English language text to feed in to the Sahana Eden, Emergency Data Exchange Language Situational Reporting (SITREP) application. This process is, essentially, crowd-sourcing, just like any other incident management system like Ushahidi; i.e. we need people to supply information and people to process them.

FF4EDXL research team observed the HIHO human action cycle and complexities of interaction sequence. The process began with the HIHO activating the CERT members with an alert message asking them to assess the situation. Thereafter, the HIHO would receive field observation reports from the CERT members. The figure to the right shows eleven tasks the HIHO had to perform between alerting and situational reporting.

Creating the Common Alerting Protocol message in Sahana Agasti, deciphering the field observation report, and creating the SITREP message in Sahana Eden were the most time consuming activities. The time series shows that the HIHO had some confusion with when they should upload the audio alert file (task no. 4) in Freedom Fone and issue the SMS text alert (task no 7); hence, the multiple instances of this task indicate the user revisiting this task and realizing that a prerequisite had not been completed. Despite the training and illustrating the streamlined processes in a quick reference guide, these mishaps were recurrent.

There are three recommendations that we draw from these exercises:

1) The user should be presented with a “single application” that has all the necessary functionality; where they don’t have to go between Freedom Fone, Sahana, Audacity, and other software to complete the process. Hence, Freedom Fone and a audio recording application would need to be embedded in to Sahana.

2) More automation is required to streamline and increase the efficiencies. Besides the 23 minute waiting time between issuing the alert and receiving the field reports, all tasks should be accomplished under 5 minutes. This requires better software functionality.

3) The HIHO volunteers must be trained and certified. Unlike other crowd sourcing applications that may be self-intuitive to get familiar with right away, this one is domain specific (i.e. for disaster management) and require some aptitude of skills and knowledge to engage. Sarvodaya should advocate such a program to ready their volunteer base to assist the HIH during a disaster.

The intent of FF4EDXL is to realize the design requirements to improve this system to enable Sarvodaya with emergency communication capabilities to better manage future disasters.