|Version 9 (modified by 10 years ago) ( diff ),|
BluePrint : Resource Tagging for Ticketing System
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.
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.
The users of the solution would be local government, emergency management officials, and first responders. It will help them streamline their work queuing and prevent issues from falling through the cracks through the use of a proactive alert system that re-queues unassigned work. This solution would impact the end users, because it automates re-queuing of unassigned issues. It makes it very difficult for things to fall through the cracks. Given that the stakeholders are typically the same individuals and organizations listed in the resource pool, it would assist them with an automated mechanism for queuing their work based on priority. It would also provide a method of handling the data in such a fashion that it could be easily ported into a mapping system similar to Google Earth. When an issue passes the threshold for reassignment, it would then dump the item back into the queue and alert other authoritative resources.
This project would require a web server (Apache), a PHP handler (phpMyAdmin), and a functional SQL database similar to those used in MySQL Community Server.
The primary issue created by handling data this way would that the data is initially put in by users. Although data checking can be done for correct format, it would be very difficult to verify that an address is correct. Also, the person reporting the issue may not be physically on site. This would also create problems with pulling GPS information from a cell phone. The constraint would be that location information would need to be accurate for the system to be effective with geo-tagging.
Sahana Eden Ticketing System.jpg
) - added by 10 years ago.
Resource Tagging System Blueprint
) - added by 10 years ago.
Work Flow Document
- questionaire.PNG (19.1 KB ) - added by 10 years ago.
- gantt.jpg (121.7 KB ) - added by 10 years ago.
- tasks.jpg (85.3 KB ) - added by 10 years ago.
Download all attachments as: .zip