BluePrint : Resource Tagging for Ticketing System

Introduction

During a natural disaster, notification and assignment of key resources is a key component of an effective response. As disaster data and needs are gathered, that information must be disseminated in a fashion that is effective, efficient, and contains protective measures that will prevent issues from being overlooked. The data must be conveyed in a "many to many" format, similar to joins and grouping within a relational database. The goal is to categorize, notify, allocate resources from a pool, and notify those resources whenever a new issue is presented. We believe that this will help expedite a cohesive response to issues which arise in a natural disaster.

Project Description

The project that our team, the Fighting Mongooses, will be working on deals with the issue of resource tagging within the ticketing system that emergency management groups utilize to mount a mitigating response to the problems that arise during and after a natural disaster. This includes tagging the issue with a unique ID number, tagging the resource pool, and how the individual resources are tagged. The module should also allow for multiple teams or resources to be assigned individual tasks for a single incident when a response from more than one team or resource is required. The client application for this module must be able to create, update, and delete/resolve incidents within the database. Although resolved incidents would remain in the database for historical purposes, they would be tagged as inactive and no longer appear in resources' work queues. Once a resource or team is assigned an incident, the resource or team will be notified based on their individually configured notification preferences. Options will include RSS, Twitter, SMS, and e-mail.

Stakeholders

The stakeholders for this project will be local government deploying the software, emergency management officials, first responders, and individuals reporting an issue. Ancillary stakeholders will be the individuals working with the Sahana Foundation, as it is their software that the module would be incorporated into. The module would assist emergency management officials and responders by effectively and efficiently disseminating information on incidents requiring interaction. It would also provide centralized control of the repository of information. Individuals reporting an issue would be assured that their problem would given to an appropriate response team.

User Case

The user case parallels the requirements. Emergency responders must be able to receive notifications about incidents in a timely fashion with fail safes in place. As such, a user can report an issue to a centralized control authority. The incident can be filed within the ticketing system with accurate information. Once the issue is filed and a priority is selected, the incident gets pushed to a work queue for an appropriate response team. An authoritative user then assigns a task for the incident, and a notification is sent to that individual resource. That resource then responds appropriately. In the event that the incident does not have a task assigned to the appropriate resource, it is then placed back in the team queue and other authoritative resources are notified. This streamlines and simplifies work assignment, while providing fail safes so that issues do not get overlooked.

Requirements

The web interface will include fields such as the person reporting, subject, request type, priority, location, and contact information for the person reporting. Once the issue is filed, it will be placed in a queue for a team. An authoritative resource will be notified via one of the aforementioned methods with the expectation that the authority will assign the tasks to individual resources. The system will be able to add assignments for multiple teams if the response required transcend multiple teams. For example, if there was a fire and there were injuries, the incident might have tasks assigned to both EMTs and the fire department. The incident would have to then be individually resolved by each team before falling out of the active queue.

Incident numbers will be assigned in chronological order using a counter in web2py. The incidents will have a status of active or inactive inside of the database. Active will be represented by a 1, and inactive will be represented by a 0. Incidents with an inactive status will not show up in the work queue for teams.

Incidents that are not assigned once they arrive in the work queue pool will be given a predefined time threshold calculated based on a time stamp when the issue is initially filed. Once the time threshold has been exceeded, it is reintroduced and timestamped within the work queues. Other authoritative resources are then notified. This will occur until the issue is acknowledged and reassigned appropriately.

The software must include functionality to pass the address or latitude coordinates to a cell phone or an auxiliary application to provide directions and a map to the incident. For example, the data could be accessed on a computer and passed into Google maps.

This project is to be completed in web2py. web2py provides all of the functionality of an SQL database through a Database Abstraction Layer, so constructing a relational database within the existing system would present no problem. This provides the functionality for a "many to many" relationship between incidents and resources or resource pools.

Example: ​http://www.web2py.com/books/default/chapter/29/06/the-database-abstraction-layer

There are modules that can be integrated to update RSS feeds for resource notification. This is due to the fixture structure of RSS feeds. These include title, link, description, items, etc.

Example: ​http://www.web2py.com/book/default/chapter/10#RSS

Email notification is also possible within web2py. It requires that settings, similar to those you would configure when setting up an email client, be configured within the code. This allows the client application to connect to an SMTP server to send email notifications to users. We recommend the utilization of the SMTPS protocol for secure delivery.

Example: ​http://www.web2py.com/book/default/chapter/08

SMS notification to resource cell phones is possible through web2py. It does require the utilization of an SMSC proxy. The data is encrypted for secure transmission across the Internet with the use of an X.509 certificate.

Example: ​http://web2py.com/books/default/chapter/37/08/emails-e-sms-todo

Twitter notification is also possible for notification within web2py. There is a constraint with Twitter notifications. Although the notifications can be sent across Twitter, the tweets will still be constrained to the 140 character limit. This would require that the subject and incident number only be included within the notification, and the user would have to use an alternative method to acquire the full incident description. As such, this aspect of the notification module could provide notification only. It would require further intervention from the resource receiving the message.

Example: ​http://www.web2py.com/book/default/chapter/14#Twitter-API

System Constraints

The primary constraint will be that the address or latitude and longitude information provided by individuals requesting assistance must be accurate. Without accurate information, passing the information to other software for directions would be useless. The software would also require that authoritative users respond to requests for assignment in a timely fashion. If they do not, then incidents would cycle in an infinite loop without ever being resolved. This would ultimately create system resource issues until the system became non-responsive.

Mind Map

Resource Tagging Graphical Representation

Work Flow Mock Up

Gantt Chart

Tasks

Quality Control

Link to Questionaire: ​http://questionpro.com/t/AKlrOZQdWh

Presentation

{widget url=​http://youtu.be/gEEwXbCc-Ls}

---

BluePrint