== Disaster Response: Remote == '''Definition:'''[[BR]] Group of virtual volunteers, physically remote from an incident but collaborating to reduce suffering and provide situational awareness to any interested parties.[[BR]] Volunteers may be members of existing organizations (SBTF, GIS Corps, HOT OSM) or interested individuals who have become alerted to an opportunity.[[BR]] '''Types of Assistance:''' * collect social media messages (Twitter, Facebook, Baidu) * collect email and SMS messages * collect news, RSS and transcribed radio or voice communications * translate messages * categorize messages * determine geographic coordinates of a need or event * provide cumulative effort impossible or inconvenient for single agencies * generate image digitization for shared maps (perhaps integrate with OSM task manager?) * provide analytical assessment * store communications * supplement existing information networks === Interface === === Technology === Standards Compliant database containing: * event identification * reporter details * the Report * available means of communication * history of interactions regarding that report * location coordinates * multiple location names associated with that coordinate * related reports * time value (to track an events evolution) * supporting or responding agencies (who has viewed it, who is responding) * severity of event * category (icon driven menu) * media (photo, video, audio) * URL groups (supporting organizations, coordinating documents, related web resources) * URL description * relevant feed generation (API or RSS etc.) * tracking of message view or response '''Workflows:'''[[BR]] Each report is an entity with a living human on the other side. Whether the message is regarding a life or death threat, or more mundane matters, it is important to the sender and ought to be afforded attention. In systems without feedback, individuals provide messages in the blind and aid workers must filter through and make critical decisions that increase tension. With feedback and mutual communication, individuals are empowered to assess their own needs in the priority structure. This will reduce the mundane reports and uncover potential for unanticipated solution finding. Remote disaster response should be working towards a goal of enabling input from every affected person in an event. The current fact that it is difficult to impossible doesn't indicate that the goal is any less important. Methods and technologies are already in production to handle significant volumes of information. Data analytics and crowd processing are also more effective than ever before. Report processing will often follow a series of interventions, but the object is to process the messages quickly, rather than to ensure that every message is put through the same procedure. Some actions are not always necessary. SMS from a known and trusted entity can be assumed to be valid until the content proves otherwise. Messages containing lat lon coordinates do not need to wait in a cue every time. This is particularly important for critical messages. These will be verified further upon the action-taking phase, so the priority is to get critical messages identified and into an appropriate workflow. Part of the group effort is categorization. The work is also important to do before the message arrives. Publicity efforts should be supported by all stages of message process that encourages self categorization. Providing two channels for interaction is one example, or choosing delivery technique (e.g. SMS for critical communications, Twitter for others)