wiki:BluePrintCERT

Version 33 (modified by Laura Lanford, 13 years ago) ( diff )

added desired functionality list for gsoc

CERT: Community Emergency Response Teams

Table of Contents

  1. Workflow
  2. Use Cases
    1. Alameda CERT
    2. Sacramento CERT
  3. Workplan
    1. Issues
    2. Related

​Community Emergency Response Teams (CERTs) are disaster trained volunteer groups that provide trained support when an emergency overwhelms a community's resources. CERTs are organized locally and provide both emergency response and preparedness outreach in their own communities.

There are more than 1800 CERTs in the U.S, most of whom serve small communities with limited professional emergency response capability. When used correctly these teams are a valuable resource, but too often they are underutilized due to lack of coordination. There are commercial platforms available to coordinate volunteers, but most have two serious issues: complexity and cost.

Sahana-Eden offered a promising open source solution for coordination both within and between CERTs. Since Chicago CERT and Sahana-Eden first collaborated in late 2010, we have talked to dozens of CERTs teams to design a solution specific to CERTs and their unique needs and workflows.

Our goal is to make the Sahana-CERT branch intuitive and flexible, to allow it to be used easily by non-technical CERT coordinators but still allow access to Sahana's powerful functionality. Our focus at Random Hacks of Kindness 2011 was to create a comfortable, user-friendly interface that would allow any CERT coordinator to jump right into using Sahana-Eden. The RHoK team did an amazing job, which can be seen at the ​demo site, and won first place at ​RHoK Austin for their work.

We are already getting requests from CERTs all over the United States who are desperate for a coordination solution. CERTs receive relatively little funding, most of which goes to training and equipment for their volunteers. Most coordinators have neither the time to implement a custom solution nor the money to purchase a commercial solution.

The opportunity to have a world class system like Sahana-Eden, customized for CERTs, just for the cost of maintaining the instance is a wonderful thing. After evaluation of our beta implementation with City of Chicago, the Sahana-CERT branch will be available for use by every CERT in the country. This could improve the emergency response outcomes of hundreds of communities struck by local and large scale disasters.

Our next big push of new functionality, which we hope to complete over this years Summer Of Code, includes the following:

  • Inbound SMS parsing for deployment responses
  • Generate a list of responding volunteers
  • Installer for CERT coordinators to deploy an instance with minimal technical knowledge
  • Update UI for all pages to be as streamlined and intuitive as the front screen.
  • Secure web-based volunteer information updates by the volunteer.
  • (potential) Mobile checkin / checkout of volunteers onsite

Sahana supports Rapid Application Development and has a worldwide network of generous, knowledgeable developers. This event is an excellent introduction to developing for the Sahana platform. If you know Python, JavaScript or CSS design, please consider joining the collaboration!

You are welcome to connect with the Sahana-Eden team on IRC #sahana-eden.

Members working on the CERT branch include:

Fran Boon (IRC: flavour, skype: franboon) physically in Oxford, UK Dominic Konig (IRC: nursix, skype: nursix) physically in [56.941681N,15.912713E], Sweden Pat Tressel (IRC: ptressel) physically in Portland, OR Laura Lanford (IRC: llanford) physically in Chicago, IL Benjamin Rapoport (IRC: BenjaminCCC) physically in Culver City, CA

The Sahana/CERT collaboration was started at RHoK December 2010:

Work continued at RHoK 2011:

Demo site:

Code from RHoK 2010:

Code from RHoK 2011:

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

Alameda CERT

Our needs are more administrative and during Preparedness phase. We need to know who needs Disaster Medical 2 in order to complete their Basic CERT.

Some of the other administrative Preparedness questions I have recently answered from the data base include:

  • Whose Disaster Service Worker (DSW) badge has expired, so we can get them sworn in again and a new badge issued.
  • Which of our recruits volunteered to staff a CERT booth at public events, and send them an invitation to participate.
  • Who is assigned to the various neighborhood teams, and which members of that team have completed Basic CERT, which are DSWs, and who are licensed Amateur Radio operators.
  • Where do the newly qualified Basic CERTs live. This information is passed to the team leaders of the neighborhood teams.
  • Give the radio club a listing of new Basic CERTs who said they were also interested in becoming a ham.

If I understand what your software focuses on, it's more of matching skills to needs during Response phase. In contrast, we plan for CERTs to stay in their neighborhood as long as needed there, and then report to an Emergency Volunteer Center (EVC) for assignment. We have a kit from our county for operating an EVC. We have exercised that kit once in conjunction with a Shelter Ops exercise. It's a manual EVC, and maybe your software could help there.

The ham radio operators that are ARES registered and trained are pre-assigned, and then would use an on-air resource net to refine those plans during the Response phase of an Incident.

Tom Schweich KJ6BIT

Sacramento CERT

Person Table (demographics): Should be able to tell us who they are, where they live and how to contact them.

  • Name (first, last)
  • Address (address, city, state, zip)
  • Phones (home, cell, work, contact preference)
  • EMail (home, work, other, preference)
  • Team/Battalion (determines what team for larger CERT groups)

Training Table (qualifications): Should be able to tell us what they know and if they are current

  • Class type (Basic, Level II, Level III, specialty, etc.)
  • Title
  • Prereq (Level II would require Basic, Level III requires Level II, etc.)
  • Rating (is this a class that grants the graduate a specific rating like an Amateur Radio License, etc.)
  • Expires (rating expires on X date)

Event: Should be able to track volunteer hours for grants, etc.

  • Date
  • In (time in)
  • Out (time out)
  • Title
  • Location
  • Description

On and on, tracking other variables. I would imagine the Training table would have a child table that would handle classes that come in modules (basic class would have the 7 basic modules, ARC ratings would have the 3 basic classes, etc.). The Person table might have fields to indicate if the user is 'affiliated' (wants to be an active deployale member used on any/all events) vs. 'unaffiliated' (wants to only be called upon for actual disasters).

Robert Ross, CFR, DTT CERT/Teen CERT Instructor Sacramento CERT Battalion 6, Level III K1RLR

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.