| | 69 | |
| | 70 | === Alameda CERT === |
| | 71 | 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. |
| | 72 | |
| | 73 | Some of the other administrative Preparedness questions I have recently answered from the data base include: |
| | 74 | |
| | 75 | - Whose Disaster Service Worker (DSW) badge has expired, so we can get them sworn in again and a new badge issued. |
| | 76 | - Which of our recruits volunteered to staff a CERT booth at public events, and send them an invitation to participate. |
| | 77 | - 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. |
| | 78 | - Where do the newly qualified Basic CERTs live. This information is passed to the team leaders of the neighborhood teams. |
| | 79 | - Give the radio club a listing of new Basic CERTs who said they were also interested in becoming a ham. |
| | 80 | |
| | 81 | 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. |
| | 82 | |
| | 83 | 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. |
| | 84 | |
| | 85 | Tom Schweich KJ6BIT |
| | 86 | |
| | 87 | === Sacramento CERT === |
| | 88 | Person Table (demographics): Should be able to tell us who they are, where they live and how to contact them. |
| | 89 | * Name (first, last) |
| | 90 | * Address (address, city, state, zip) |
| | 91 | * Phones (home, cell, work, contact preference) |
| | 92 | * EMail (home, work, other, preference) |
| | 93 | * Team/Battalion (determines what team for larger CERT groups) |
| | 94 | Training Table (qualifications): Should be able to tell us what they know and if they are current |
| | 95 | * Class type (Basic, Level II, Level III, specialty, etc.) |
| | 96 | * Title |
| | 97 | * Prereq (Level II would require Basic, Level III requires Level II, etc.) |
| | 98 | * Rating (is this a class that grants the graduate a specific rating like an Amateur Radio License, etc.) |
| | 99 | * Expires (rating expires on X date) |
| | 100 | Event: Should be able to track volunteer hours for grants, etc. |
| | 101 | * Date |
| | 102 | * In (time in) |
| | 103 | * Out (time out) |
| | 104 | * Title |
| | 105 | * Location |
| | 106 | * Description |
| | 107 | |
| | 108 | 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). |
| | 109 | |
| | 110 | Robert Ross, CFR, DTT |
| | 111 | CERT/Teen CERT Instructor |
| | 112 | Sacramento CERT Battalion 6, Level III |
| | 113 | K1RLR |
