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:

• ​Problem Definition
• ​Final RHoK Status Presentation
• ​Photos

Demo site:

• ​http://cert.sahanafoundation.org
• This site needs moving from Healthscapes to Zen

Current Code:

• ​http://bazaar.launchpad.net/~rhok-vol/sahana-eden/trunk

Workflow

Workflow is based on ICS.

Current Workflow:

Proposed Workflow:

Detailed Workflow:

• ​Source on Google Docs

Use Cases

1. Each volunteer who completes the CERT basic training program will be entered into the database.

2. Web-accessible user interface allows volunteers to update selected information on their account.

3. 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]

4. 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]

5. A request for volunteers is sent by email, SMS and Google Talk to the search result set.

6. 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.

7. 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.

8. A list will be generated with the names and skillsets of the volunteers to be deployed and sent to the event incident commander.

9. When a volunteer arrives at the event scene, he / she can text or email a confirmation of arrival to the system.

10. When a volunteer leaves the event scene, confirmation of exit.

11. 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.

12. 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

• ​https://docs.google.com/document/d/1ekhiNz7cmryynt1FeeXi6IXNx9b-3ANfZxX-F9hyqmk/edit?hl=en_GB#

Proposed schema changes:

• ​https://spreadsheets0.google.com/ccc?key=tZcjtk6NVhWC2VkriozZBZA&authkey=CI2E35AH&hl=en&authkey=CI2E35AH#gid=0

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:
  • A dropdown for the Event
  • A slider for the Radius (textbox fine to start with)
  • jQuery to read these values when the 'Show Map' button is clicked with a URL like:
    • ​http://127.0.0.1:8000/rhok/vol/view_offices_map?project_id=1&radius=1000
  • (Longer-term would be good to have the filter adjust the Map dynamically)
• Add a Volunteers layer to the main map which shows all Volunteers with random colours assigned per-team

Related

• BluePrintVolunteer
• ​Roster, Training and Activities Tool Specification
• ​http://groundcrew.us - Commercial Tool which is similar (but relies on EOC having Internet as it's only cloud-based)

---

BluePrints