RHoK 2011

At RHoK 2010, Sahana programmers first worked with the Chicago Community Emergency Response Team to create a volunteer tracking system that can be used for Chicago CERT and, eventually, more of the 1800+ CERTs in the United States.

The notes from RHoK 2010 can be at http://eden.sahanafoundation.org/wiki/BluePrintCERT. The relevant portions for our goals this year are copied into the notes below. It is important to understand that many CERT member and administrators are not strongly technical and are intimidated by the power and complexity of the existing platform.

There are three specific functionalities we hope to accomplish at this year's event:

1. Create a simple, easy-to-follow, intuitive Volunteer and Event database user interface.
2. Create a search functionality that allows administrators to search for volunteers with specific characteristics and choose to send event deployment requests to those volunteers.
3. Automatically process volunteer responses to the deployment information, respond appropriately to the responses, and generate a master list of participating volunteers for the event.

A demo of the current functionality has been set up at:

• ​http://cert.sahanafoundation.org

You are free to register here & play!

1. Create a simple, easy-to-follow, intuitive Volunteer and Event database user interface

The following screenshot is a proposed UI design that should be simple and intuitive enough for non-technical users to be able to follow:

User Story 1: Setup for initial CERT training.

1a. Basic training is 8 classes and a final exam. CERT Administrator Joe creates an event for each class:

1b. Joe also creates a qualification category that requires all classes and the exam. All the classes are internal to CERT and so go under "Training Requirements". No external credentials are required to complete basic training. The Skill Level indicates the maximum level this qualification grants to the volunteer who receives it. If the volunteer already has a higher skill level, they are not downgraded.

1c. Some of the students are already AED / CPR certified, so Joe also creates qualification for that. The students will send Joe a copy of their certification which he will then attach to their profile.

1c. Joe then enters (or import) a list of the students in the class. If they already exist in the volunteer database, the class is added to their existing profile. If they do not exist in the database, a new volunteer record is created.

1d. Determining which volunteers have completed all the requirements for a given qualification will be refreshed on a non-configurable time interval or forced by selecting "Refresh All Qualifications" on the Qualifications page.

1e. When volunteers first complete all the required classes for Basic Training, their status is changed from "Pending" to "Active" and are eligible for additional call-outs and training.

Sample volunteer profile pages

The info page is pretty straightforward. The "text" checkbox indicates that the volunteer can receive SMS messages at that number. The "Contact Lists" indicate what types of communications this volunteer will receive from CERT. I'm signed up for everything, but if I wanted to stop receiving notifications about drills I would be removed from the "Drills" contact list. (TODO: preferred method of communication)

The qualifications and level boxes (from left to right, level 1, 2 and 3) are pulled from the qualifications database. The notes and attachments are part of the volunteer's profile. The paperclips indicate an an attached file with verification of that qualification.

This is just a list of the events in which the volunteer has participated. In the future we'd like to be able to filter by event type.

This is where CERT leadership can make notes that are important or helpful for an incident commander. The information on this page will be added to the volunteer roster that is sent to the incident commander, and instructions on the appropriate types of things to write in this area will be part of our SOP.

This is a read only page that indicates which past deployments the volunteer has responded to at what his / her response was.

2. Create a search functionality that allows administrators to search for volunteers with specific characteristics and choose to send event deployment requests to those volunteers

The deployment page allows the admin to send a request to specific volunteers. (CONSIDER: Can admins send deployment requests without affiliation to an event?)

By default all Active members are shown in the recipient list who are assigned to the appropriate contact list. For instance, if sending a deployment for a Training event, only volunteers who belong to the "Training" contact list will be shown in the recipient list. The list can be further filtered by selecting "Restrict recipients by qualification" and using multi-select to choose.

The deployment notice is a standard template. Joe wants to edit before sending so he selected "Edit Request Before Sending" to bring up the preview pane. He adds a couple of notes and select "Send Deployment"

Here is a flow chart of the whole deployment process:

3. Automatically process volunteer responses to the deployment information, respond appropriately to the responses, and generate a master list of participating volunteers for the event

As seen in the Deployment Workflow above, volunteers are expected to respond to the deployment request in specific way in order to be processed by the system. When the desired number of volunteers have responded affirmatively, the system sends regrets to all subsequent responses, generated a volunteer list and sends it to the incident commander.