wiki:BluePrintCERT

Version 25 (modified by Fran Boon, 11 years ago) ( diff )

--

CERT: Community Emergency Response Teams

In the US, CERT Teams are local emergency response teams based on volunteers that take 20 hour initial training, and much continuing education, to be certified community response helpers in an emergency. They get mobilized to force-multiply the first responders, when all government-owned response teams are maxed out and overwhelmed. Famous ones are e.g. the LA CERT, the Arlington County CERT here in the area, and others.

CERTs have limited recourses and no standard equipment, so providing tools for them to register and organize their users beyond list-servs, assign responsibilities, keep track of skill-sets, general community management etc.

Project started at RHoK December 2010:

Demo site:

Current Code:

Workflow

Workflow is based on ICS.

Current Workflow:

Proposed Workflow:

Detailed Workflow:

Use Cases

  1. Each volunteer who completes the CERT basic training program will be entered into the database.
  1. Web-accessible user interface allows volunteers to update selected information on their account.
  1. Primary & secondary admins from any CERT group can create an "Event", which can be a disaster, drill, exercise, training, etc.
  • [Event = Project in current Eden terminology. Ideally want a simple deployment setting to convert between the 2 terms]
  1. After creating an event, the admin may search for volunteers to respond to that event by specifying specific skills, location and interests.
  • the majority of deployments are 3-8 hours, but I can imagine one lasting longer. However, we could create separate events for each day
  • They will be assigned tasks by the IC when they get to the deployment location. I don't think that would be part of this system.
  • [We can use Sahana Eden 'Tasks' to manage deployments]
  1. A request for volunteers is sent by email, SMS and Google Talk to the search result set.
  1. Volunteers can respond by email, SMS or Google Talk to be deployed, and will then receive a second communication with deployment details
  • Q: Why not send them the complete details initially, to help them decide if they want to volunteer?
  • The second message is still important for confirmation though. - michael.howden
  • [lauralanford] We want to avoid spontaneous participants - if deployment details are only sent to confirmed responders, there is less likelihood of unplanned volunteers showing up on site.
  1. Once the requested number of volunteers has been met, a second communication will be sent to those who have not yet responded that the request has been filled.
  1. A list will be generated with the names and skillsets of the volunteers to be deployed and sent to the event incident commander.
  1. When a volunteer arrives at the event scene, he / she can text or email a confirmation of arrival to the system.
  1. When a volunteer leaves the event scene, confirmation of exit.
  1. If a volunteer has not confirmed exit by the closure of the event, a notice is generated and sent to the IC and the admin who created the event.
  1. Send Situation Reports to the system for the IC's attention

Workplan

Proposed schema changes:

Issues

These should be logged as tickets with the 'CERT' Version:

  • Remove the volunteer flag from pr_person & instead use:
    • response.s3.filter = (db.pr_person.id == db.vol_volunteer.person_id) & (db.vol_volunteer.status == 1)
    • There are issues with this filter anyway - need a nice way of making persons into volunteers from the vol module: a new registration controller?
  • When 'open' a person from the Team Members view it should open the Person record not the Membership record
  • Need UI to access the 'Show Offices within x radius of an Event ('Project') Map:
  • Add a Volunteers layer to the main map which shows all Volunteers with random colours assigned per-team

BluePrints

Attachments (4)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.