Our place of abode Kerala, located in the southern most tip of India faced unprecedented rainfall which resulted in disastrous floods from Aug 8 — Aug 16th, 2018. Nearly 500 people lost their lives, 1.5 million people were displaced and an estimated damage of US $3 billion was incurred.
All of our team members were involved in the flood relief operations and we were actively observing and discussing the events as they took place. With this background of our observations and experiences, we hacked a product for managing disasters at Call For Code Kerala Hackathon where we tried to distill the lessons we learnt from our efforts in helping in the flood missions.
As a disaster happens, we can see the population divide itself to two: a huge number of victims and a comparatively low number of volunteers enlisting themselves to help the victims. During this intense period it’s a tough challenge to match this asymmetrical demand and supply efficiently. Without knowing the nature of unfolding events, it’s hard to administer decisions effectively and efficiently to the limited pool of volunteers and professionals.
One of our key observations during Kerala Flood was that while a good enough number of volunteers and agencies were willing to enlist themselves and put their time and effort on line, there was much difficulty in coordinating and communication amongst the teams as the state was not prepared to deal with tasks at this scale and intensity.
With the dedication of the officials of the state and relentless efforts and solidarity displayed by the professionals, Kerala was able to pull through the ordeal. This is our humble attempt at cataloguing our ideas which we feel will smoothen such rescue operations from the digital space in case a disaster is to occur anywhere on our planet.
It could be the case that a volunteer would have to take care of 10 or 100 victims during a short span of time. Any solution devised should be able to tailored to reduce the cognitive overload an official has to go through when making decisions.
During the Kerala floods the volunteer teams coordinated with whatever tools they had at their disposal. Rescue teams made effective use of both digital and printed medium tools.
Some of them where:
Word of mouth was relied to communicate local information. This helped spread the word about the status of a community to its inhabitants.
Toll free numbers for reporting rescue locations were set up and calls were routed to them.
Whatsapp and Instagram was used to flash important information and forward timely information to a large number of people. The instant messaging triumphed over other mediums in informing people of the status of the incident.
One curious use of the printed materials was to print out the incoming requests and then use a highlighter pen to cross of the incidents that were successfully completed.
A lot of bespoke websites and apps developed by independent teams and the government itself propped up on the scene. A list of these can be found here.
Google Docs were used as a database of dynamic data like incoming requests, number of relief camps set up etc. Google Person Finder which was useful during the Haiti missions were used as a a decentralized database for retrieving information about missing persons.
While a lot of tech solutions were deployed, the ones that we observed to provide best leverage for rescue operations were Whatsapp chat messages and Instagram DMs and Stories. These tools could afford unstructured data that happened during the flood and diseminate them in an effective manner.
While these tools provided pretty decent leverage to carry out the rescue missions. With great dedication and effort from volunteers end, they were able to do a great job in carrying out the rescue missions. During this intense period, we observed quite a few pain points which if mitigated could take the relief operations in another port of disaster much effectively.
No global sense of whose requests was received and who got rescue help. Multiple calls had to be placed between the parties to establish the ground truths.
Without a consolidated database of information, it’s hard to tell the true from fake and tell apart different instances of the same case such as a name like Sanjivani spelt as Sanjivni/Sanjeevani/Sanjheevni in different variations. This usually happens when same name is being registered by 4 different person.
Without understanding which places are getting hit bad geographically and where the population is concentrated, it’s hard to coordinate a rescue mission and effectively make use of the precious resources in an efficient manner.
Getting a consolidated database acting as a single source of truth will enable matching the demand with the supply effectively between the victims and volunteers.
Our solution was to come up with an end-to-end conversational platform that will empower the officials to keep track of the situation and connect the demand and supply between victims and volunteers instantaneously.
The offical who is coordinating the rescue missions would initially be presented with a dashboard. The dashboard contains “modules”: Units that can be dragged and dropped in order to configure the workspace to cater to the unique needs of a situation. This would be geographically segmented so that a volunteer whose control is in a particular area gets a birds eye view of the events happened in that geographical location.
The dashboard as we designed during the hackathon contains a few modules:
A ticketing area which is a collection of all the open and closed cases in the given geographical location. This would be sorted according to priority from left to right. The official can see which all cases have high priority, are open, as well as an area to reach out for closed issues in case she wants to have a re-check on the transactions done on any particular case.
Under these categories it would have a listing of all the issues that has to be taken care of during the disaster. Each issue here would have a unique ticket id. Thus these issue can be conceptualized as a single point of contact for all intelligence that has been gathered and all the communication that happened under it. This is a valueable model to gather intelligence on all the ongoing events related to a particular issue and also allows for cross team communication in case there's more than one official operating on a single issue.
Another advantage of having a ticketing system like this in place is that once a case is deemed to be complete, she can confidently move on to tackling the next case having brough about a closure. This allieviates the cognitive burden of having to track many open cases simultaneously and getting worried about the progress about their transactions.
Say a pregnant lady was trapped in a building during flood. A neighbour spots the issue and tries to report it on to the platform. This would get logged on the system as a case. This case will now be the place in which all communication relating to this incident will be logged.
Now, it has been a common occurence that these sort of high priority cases get reported multiple times by different agents. The good thing about having a ticketing system in place is that you can combine these requests under the same ticket thereby curbing the proliferation of inbound requests and keep the dashboard populated with unique cases.
Even if there’s a replacement of an official, the newly appointed person can quickly get upto speed after browsing through this event log. This log can act as a single database of all information that has happened relating to the case on a continous stream with timestamps and geotags. This means a person in charge can travel backwards in time and sort of time travel in his head about what has happened. With the help of geotags she would be able to correlate the space coordinates were a certain incident took place.
One of the main things that can aid during a disaster is to get a visualization on the situation. One of the ways we think this can be accomplished is by getting a live picture of the events happening in the area.
As can be seen from the map, different events pertaining to the disaster is color coded and shown on the map. An important thing to note is that the ones that have high priority will be assigned a reddish color and the ones with low priority would be assigned a bluish color. The icons here represent the kinds of tickets that has been registered in the system. Helicopter stands for airlift, the water drop and plate icons stand for water/food requests and capsules represent medicine requests respectively.
By looking at the map above, one can see the Thrippunithura area (on the far right) has quite a few high priority cases, so an official who has identified this pattern can at once devise efficient airlift trajectories.
Once an issue has been identified, the next step is to delegate it to the appropriate professional. Towards this end, the platform would have a live listing of professionals enlisted for the cause. It will have a readily updated listing of professionals to see if they are online and ready to respond.
With such a database, the official is in charge of making an informed decision on who is ready to be assigned to a particular issue segmented by the departments. Once a professional from the respective department is assigned to a case, the system will mark once she has accepted the case. This enables acquiring a picture of the professionals from various departments working on any given issue at a point of time.
As observed in the beginning, the apps that were successful during Kerala Floods where Whatsapp and Instagram. We tried to give a closer look at these and one thing that we could find out was that a key factor that made these tools successful where their capability to capture and disseminate unstructured information. These tools could adapt themselves to spread the news about new kinds of phenomena that occured during the flood like poisonous reptils creeping into house as a result of water from highland areas seeping in to houses in the valleys.
This idea, we think has a far reach, during a disaster, its hard to predetermine the shape of the emergencies that will occur and hence any pre-solution to communicate the situation should be able to adapt to the rapidly changing nature of the events.
In our thinking, the best solution we found is a chat interface, where people can write down their thoughts. This is a solution, we think would scale when it’s another disaster say, a forest fire, that has drastically different kind of requirements when compared to a flood.
This sort of interface would be a good fit not just for cross victim communication, but also to coordinate the operation between volunteers, victims, and officials. Officials can mediate the communication between victim and volunteer using a chat interface.
Not just humans actors, but machines in the form of chatbots, drones, and semi-automated robots etc. could also play an active role in this mission by updating the officials, volunteers, and victims of the progress in the rescue operations.
Some of the use cases where chatbots could be deployed would be in notifying the officials when the professionals such as when a doctor or a helicopter operator requests anything from their side or makes progress on the victim’s case.
Another case where this could be of use would be to push a notification to victims in an area where a red alert has been issued. So a chatbot could be programmed to push notifications to concerned people in the geographical area simultaneously.
During a disaster, the psyche of the victim would be going through an emotional turmoil. During this time period, its not realistic to expect that he would have the time to learn a novel UI and explore its possibilities. With this in the back of our mind, the UI we devised was a conversational one which the victim would be familiar with in his common life in the form of sending SMSes, or Whatsapp chat messages.
This leads to reduced cognitive load of having to understand the possibilities and enable getting up to speed quickly. In case, the user has a distinct requirement, a virtual volunteer can take over and provide assistance. We also tried to take this one step further, by minimizing the need to provide textual input by providing common patterns as actionable buttons.
Chatbots can be leveraged to play an active role in helping the user remain calm. One feature that we think will greatly aid in keeping the user at peace is to provide continuous feedback on the progress of his request. Say a marooned user on top of a building during a flood registers a request, a chatbot in the system will regularly update him of the status of his case. This could include details like providing the name of the official assigned to his case and a phone number of the official in case of emergency to contact, estimated time for arrival of the official to his scene etc.
One other area where a chatbot can be deployed is to acquire closures on the ticketing system. Say, a victim was successfully saved, the chatbot can prompt her to check if she was successfully saved. If it was conducted successfully, this sort of intelligence gained can then be propagated to the stake holders in the system. We think the peace of mind her friends, relatives, and the rescue mission official will get once they get to know that her case has been successfully completed would contribute highly towards improving the state of their mind.
One other area where a chatbot can be deployed is to get a closure on the ticketing system. Say, a victim was successfully saved, the chatbot can prompt her to see if she is safe. This sort of intelligence gained can then be propagated to her friends, relatives, and the rescue mission official to know that her case has been successfully completed. This sort of pleasant news can be push notified to the many stakeholders involved in the situation and thus consoling them and improving their state of mind.
Conversational UI can also afford multilingual text messages. This is key as people speaking a different language commonly find themselves at loss when they get hit by the disaster. They will have a hard time communicating with the local members. A conversational UI that can accept a different language can quickly tag the case and rerouted it to a volunteer proficient in that language who can help with the situation. Other media that can be facilitated using a conversational UI includes voice messages, images, videos etc. all of which could be made use in order to communicate the situation of hte victim with the volunteers.
A note that has to be made about implementing this system is that the database powering the system should act conceptually as a single source of truth. Above and over of the benefit of having a ticketing system that curbs fake and redundant data, the thinking behind adopting this model is that once this database is made open source it will foster innovation by small groups that would be willing to contribute to the platform. During Kerala Floods of 2018, a lot of small units came forward to build their own apps which served a single purpose well. This sort of collaboration could open up the space for new innovations which will enrich the platform in ways not yet imagined.
During a disaster, it’s often the case that the population who have no connectivity find themselves in dire times. So the disaster management system we have designed here should take care of this aspect of the problem. A lot of unique innovations are being made for this segment like the Mesh technology, Physical push buttons, Drones combined with CV etc. which can mitigate the damage done to this section of the population.
For people who at least have a feature phone, a toll-free number to call and SMS could be provided where in the same conversational format can be employed to get their unique requirements. The data coming through this channel might have to be accomodated in to the system using volunteer input.
Also, Whatsapp centers could be established for each county/district to send their messages to, which could be parsed and automatically added to the ticketing system as an issue segregated by number. These aspect of acquiring data from different channels have to be take into account if we are to build a robust system to prevent the largest possible amount of casualties and damages in a disaster.
Our ideal goal is to turn this system into a holistic solution that can not only take care of the rescue aspect of a disaster, but the whole spectrum of rescue — relief — rehabilitation — rebuild. We have an inkling that this system can easily be adapted to pre and post disaster scenarios. A lot of characteristics involved in high intensity rescue operations stay the same during relief camp inventory and refurbishing and provisioning during rehabilitation and even for forecast of high risk areas during a disaster.
As outlined above the architecture has to be made modular to allow for flexibility to cater to unique situations. Each module could either be an artefact that has visual presence in the dashboard or could be a functional unit such as a chatbot logger for medical casualities.
The advantage of having a modular architecture is that the efforts made by independent teams acting as third party can be integrated to enrich the ecosystem.
The data and functionality that is accumulated in this system over a long period of time could be an invaluable tool in another port where the same disaster hits. We had difficulty assimilating lessons from past disasters on the web when our own state got hit by floods. We envision this system with its single source of truth could be queried and visualized by public or officials in various ways to acquire insights and intelligence about common patterns that will emerge during disasters.
If you have any comments / feeback on this article, please forward it to our email