It contains improvements for Upcoming where attendance is displayed inline with the activity, and can be used to filter from the user’s perspective: all activities, Mine (ones the user is attending or requested to attend), Attending or Requested. Use this to more easily track down the upcoming activity you are looking for.
Improvements in Recent Activities include filtering by activity type: all activities, just incidents, just exercises or just events. Use this to more easily track down the recent activity you are looking for.
Once you’ve subscribed to the calendar it will fill in the upcoming exercises and events you are attending. (It might take a little time to settle down, after having been added, but once settled it’ll update automatically & regularly.) You can even get automatic calendar reminders / notifications for those activities.
If you are out and about (on the road or otherwise not logged in to D4H on your computer to check) your calendar is what keeps you connected to your organization’s activities. Subscribe to your D4H calendar.
D4H supports a large collection of custom fields. We’ve only needed to create a few, but they have proven quite useful.
Here are the main ones we use:
Custom Fields on a Member
We created a “promotion date” (for when promoted from trainee to active firefighter) and then a “general notes” where the member can store their own FD data. (I record my annual pack test times in that field, for me to compete against me.) We have a private “Personnel Notes” field for additional (not public) information. Here are how we configured the private personnel notes…
Custom Fields on an Activity
We added a timestamp for when the patient care report has been filed, and we configure a note (seen by report approvers) to not approve a medical report until the paperwork has been received. Further, we did elect to rename the incident timestamps to match our department’s terminology (to easy member training.)
Custom fields allow us to keep additional data in the right place in D4H.
We implement Incident Command System (ICS) on all our incidents; basic on small incidents and we grow it for more complex. We have these main three on all incidents:
That said, Firefighter perform various roles on scene – based upon the incident type – and we record many of those roles.
Within our organization we have personnel at various levels of their career, at various levels of experience, and mentoring the membership through new roles is healthy for the organization. Recording these roles is good for helping “spread the wealth”.
New members need a certain number of successful driving experiences with an officer before they can progress to driving by themselves, or emergent. We record those. Senior firefighters need opportunities to be Command or Operations, and we need to spread that wealth. A healthy organization has experience redundancy, and maintaining that is an ongoing challenge.
We look to “Command” for answers to any question from the incident. We look to “Primary Patient Care” for the patient care report paperwork. We have special roles such as “Call credit during Training/Event” for those unable to respond, but due to Fire Department business. Roles help us add per member detail to a report, and build details of our response.
Keeping track of who performs what roles is valuable data for our membership.
We use D4H tags to record various aspects of our incidents and exercises. With tags we can do data analysis (should we ever need, including for grant application purposes) which allow us to pull reports that the same detail in the narrative would not.
Our two main groups are “Response Categories” and “Training Categories” and for incidents we tag the main aspect of the call from the former. We then provide additional details through the other “Response *” groups of tags.
Our district covers three counties (which provides some interesting challenges) and we chose to record which county the incident occurred within.
We do add some “Special Handling” and “Miscellaneous” tags for other aspects (including events) but those are pretty specific to us/our needs.
Note: D4H doesn’t distinguish tags between incident and exercises, so our “Training Categories” tags (another posting) do show up, and so sometime users incorrectly select them. We created reports looking for any training tags incorrectly added to incidents and that allows us to capture those mistakes.
We’ve found that “D4H tags” are a very powerful and important aspect of D4H.
Our department gets dispatched via a Computer Aided Dispatch (CAD) system. That system generates unique identifiers and when we are looking up an incident we use that identifier.
D4H allows the user to utilize the system generated identifier, or (although it is hidden behind a ‘magic’ – and confusing to our membership – click on the system identifier text) enter a user entered identifier.
We enter our CAD number as that identifier, but we’ve learned to work around some aspects…
Our CAD numbers start over each year, they are only unique within a year. January 1st the first CAD of a year would be 000001, again.
Also, D4H search is prefix loaded so we:
We prefix our CAD # with zeros to 6 digits. This way we can search of CAD #11 without CAD #111 and CAD #1111 getting in the way.
We postfix our CAD # with “CAD” and 4 digit year to make it unique.
Here is our design for a unique identifier:
[Zero Padded CAD#]”CAD”[4 Digit Year]
Examples would give:
000001CAD2019, 000002CAD2019, 123456CAD2019
If we ever need to add an “incident credit” or “add on” incident to the CAD we might add a letter, e.g. 000001CAD2019A and so on. If we ever need something added but not through CAD we use the system generated identifier.
This design allows us unique identifiers we can access easily through search.
We are a mountain fire department with both a community and significant wildland potential (with urban interface.) Our firefighters train for structural firefighting and wildland firefighting (and more.) We also have a wildland team for additional firefighters that respond to wildland fires.
We’ve created four D4H groups:
Full Firefighters (FFF)
Wildland Team Firefighter (WLT)
(Incident-only) Active Full Firefighters (AFFF)
(Incident-only) Active Wildland Team Firefighter (AWLT)
For structure fires, medical incidents, hazardous materials, and such only our AFFF respond. For wildland fires, illegal / unattended campfires, smoke reports both AFFF and AWLT respond. We manage their “requested” status in D4H by adding the appropriate group.
This keeps our memberships’ percentages correctly representing their standing. They are invited (requested) to the incidents they can attend and not those they cannot, nor those they are temporarily unavailable for.
(More precisely – when creating an incident report – we add the personnel that attended and mark them as attended, then use “Quick Add” to add the correct “Active” response groups. Note that the newly added members are added and left “selected”. We then use “Bulk Action” to “Set Status” to “Absent”. )
Our membership are operational (our responders) or non-operational (administration, support.) When a firefighter has to take an absence we do NOT change their operational status but we temporarily move them out of their “Active” group. (We do have a “Temporary non-Operational” group, but that is less important.)