Roles / Responsibilities

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:

  • Command
  • Operations
  • Safety

That said, Firefighter perform various roles on scene – based upon the incident type – and we record many of those roles.

A list of recorded roles.
Just some of the recorded 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.

Designing your incident identifier

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.

System Generated Identifier
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.

Inviting Groups in D4H…

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.

Group-Invitations

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

Working with “Add Another Date” for Event & Exercise Shifts/Slots

We do shifts for staffing community slash days, sign-up slots for annual mask fit testing and arduous pack tests, and more. (We use D4H events for this, rather than try to teach our membership yet another tool.) When creating events (or exercises) in D4H one can create the activity, but “clone it” to multiple dates / times. The title, location, pre-plan and attendance requests are all copied to the multiple activities created.

Note: Once created you can not longer edit them as one, so ensure your activity is correct before you press “finished” and save/copy it.

Once created the event or exercises typically have incrementing sequence numbers, and you can share them (say in an email) with your members by listing the links. We tend to do this in chronological order, allowing them to connect to D4H and sign-up.

Typically we have a limit on the number who can attending. Sometimes it is one member, sometimes it is based upon the number of a resource (e.g. available pack test weight vests.) We list the number that can sign up in the pre-plan, however we do have to manually monitor this since D4H does not support such a limit.

Longstanding bug/workaround…

D4H creates activity records, and multiple “attendance” records for the activity. (One or more per user.) Unfortunately when creating entries across multiple days the activity start & end date/time are correctly calculated, however the attendance start & end date/time are NOT. Somehow (seemingly a code bug) they inherit the *time* of the original activity.

If you create entries for 0900, 1000, 1100 you’ll get activities at those times, but attendance records at 0900, 0900, 0900. This is confusing to membership ‘cos it is presented incorrectly in calendar and the “Are you attending” prompts.

The way we’ve fixed this (since multiple reports over the years to D4H have not gotten this resolved, yet) is to:

  • Use a date range in the events view to gather a list of all these events.
  • Open each event in a separate browser tab (creating a “work list”)
  • Press “Update details” on an event.
  • Go to “Attendance” tab, select all attendees using top/left checkbox, use “Bulk Action” to “Set Period” (set to the correct activity dates) to correct the attendance records, then “Finished” to save.
  • Close the tab once the event view is restored as corrected, taking one off the “work list”.

This bug/workaround does diminish the time saving benefit (for the administrator) of “Add Another Date”, but it still saves creating repetitive activities by hand.

Combining/processing D4H reports

D4H comes with a powerful reporting capability to analyse your team data. Much of the data your organization has gathered in D4H is available via reports. That said, we have custom logic that we need to apply for our firefighter’s annual requirements.  We gather the firefighter’s fire training hours, their medical training hours, their station training hours and more. Each of these come from a separate D4H report. Eight of them. We combine the outputs from a number of D4H reports into one combined report – with our logic and our presentation – for ease of use by our firefighters. That takes a bit of processing…

We use the “Download to Spreadsheet” option on the report page (see below) which creates and downloads a CSV (comma separated variable) text file that can be easily processed by Excel (and other spreadsheet programs) or by scripting languages:

Exporting-CSV

We download the output and rename the file as (say) fire.csv (with one named for each of the others.) We then process these files using a ruby script…

require 'csv';
# Fire
puts "---------------------------------------------------------------------- Fire"
CSV.foreach("fire.csv", :encoding => 'bom|utf-8') do |row|
    if $. > 1
        # Skipped header line...
        raw_name = row[1]     # Name in column 1
        name = raw_name.strip # Trimmed spaces from name
        fire_hours = ( row[5].to_f / 60 ) # Fire hours...
        ...

In order to speed the process of generating the report data … by removing the manual steps of selecting the report, selecting the date range (and not making a mistake), remembering to press ‘GO’ to re-run it with the date range, then downloading … we created a local HTML file called edit-to-download-reports.html with links to each report.

To download we (1) login to D4H in a browser (2) open the HTML file with links (anchor tags) for each of these, where you would replace:

  1. The subdomain to your D4H subdomain
  2. The report identifier (get it from the URL of the report)
  3. The start and end dates. We typically have the start of year and the end of the month we are reporting to.

Extract the report ID from the end of the report web address:

https://{YOUR SUBDOMAIN}.d4h.org/team/reports/custom/view/{REPORT_ID}

Remember to edit the “endDate” if you are running these for (say) a new month:

https://{YOUR SUBDOMAIN}.d4h.org/team/oldexport/?category=reports_custom&format=csv&param%5Breport_id%5D={REPORT_ID}&param%5BstartDate%5D=2018-01-01&param%5BendDate%5D=2018-12-31

We’ve found that by using D4H reporting and then exporting to CSV file format we can extend the functionality to our custom needs.

Response Utilities for D4H on iOS. Version 1.0.3 released…

A release of Response Utilities 1.0.3. is rolling out. It releases a number of large and small improvements, and a few additions.

What’s New:
– Improved interface for upcoming and recent activities, and improved workflow for marking attendance. Activities are color coded to match the D4H activity colors. Color coding allows for and easier visual scan.

– “Off Duty” interface now includes an options for “Team” as well as for this “Member”, so overhead can more easily view team status (and team members can set their availability) when on the go.

– Integration into iOS Spotlight Search. In the iOS search bar you can find for members by name (or reference, or position) to quickly launch the application and provide a view of that member. Think of this as integrating D4H data into the phone or device’s contacts.

– “Whiteboard” support allows you to view (and add to) entries on the whiteboard. Share messages with others in the agency, from the field. (Perhaps implement a quiz on your whiteboard.)

Activities can now be shared with other responders via a link into D4H. Allowing communication around an incident or exercise, as needed, without taking data out of D4H.

– More details have been added to the member view. Viewing a member now shows:

  • The member’s upcoming “off duty” status, if any set.
  • The member’s recent activities; incidents, exercises, events.
  • The member’s groups.
  • Now: Links to their profile on D4H and qualification card on D4H.

This extended member view allows a member to check themselves quickly, but also allows overhead and/or administration to check on a member.

– This release adds a number of links into D4H website, to ease navigation on the mobile website.

Learn more about Response Utilities for D4H.

D4H Whiteboard

The D4H whiteboard is a great way to get information out to the members of your organization. Some might not check email, and maybe you don’t wish to “spam” by sending to all, but adding a whiteboard message gets to people who log in to D4H on a regular basis. (We used it recently to remind about our annual SCBA mask fit testing.)

Adding a message (marked important or not) is a great way to get to the top of the D4H dashboard:

When we don’t have more pressing postings to make, we’ve chosen to offer quiz questions on our whiteboard as a fun way to keep content fresh in mind, and keep our membership engaged. We (with we being Coal Creek Canyon Fire Rescue) provide response for structure fire, wildland fire, rescue (including automobile), medical (as a BLS agency), hazardous materials, and (as we learned in 2013) other incidents, such as floods. We also assist with search and rescue (having mountainous state parks in our district.) We have a lot to remember, and quizzes are a good way to keep things top of mind.

We used a spreadsheet to gather questions and a simple ruby script (run automatically daily against the D4H APIs) to post the questions and answers. The script takes the day of the year and combines that with the number of quiz questions to pick today’s quiz question and yesterday’s answer, and posts both.

 #
 #  A snippet of the script, to add a whiteboard entry...
 #
 wuri = URI('https://api.d4h.org/v2/team/whiteboard')
 areq = Net::HTTP::Post.new(wuri)
 areq['Authorization'] = 'Bearer ___________'
 
 areq.set_form_data({'text' => formatted_question, 'enddate' => question_days_ahead_formatted}, '&')
        
 ares = Net::HTTP.start(wuri.hostname, 
                   wuri.port, 
                   :use_ssl => true) {|http|
   http.request(areq)
 }

You can view the Whiteboard in D4H’s MyD4H mobile application. Additionally, here is how the Whiteboard looks in Response Utilities for D4H

Working with D4H groups

Some response teams use mailing lists to communicate with their members, and some create mailing lists per “group” (e.g. officers, leadership, etc.) within their organization, including for qualification groups; divers, drone pilots, EMTs, etc. etc.

Using groups within D4H allows you to reference members by name (their profile) and only have to manage the email address once within D4H, not once per mailing list. You can view members in a group and/or the groups a member is within. As things change (and things continually change; members retire, members get qualified and/or promoted) you can easily maintain D4H groups accordingly.

In D4H you can create as few or as many groups as you like, naming them as suits your purpose. You can create a Dive Team group, an Officers group, a per Station group, as required. You can set requirements on groups (ensuring you have a given number of such members on duty) and you can collaborate with groups. D4H allows you to message a group, sending to only those within that group.

Using groups make D4H more valuable for your organization.

Response Utilities, our mobile application for D4H allows you to quickly/easily view members within groups, and also send email and/or messages (if all members of the group have a mobile phone number registered with D4H) to all members of a group from anywhere you need. (See communications for how.)

Reviewing activities…

Response Utilities allows access to your agency’s incident and exercise information. Look at past incidents and their details, look at past training exercises (or events) and view attendance.

Were you active on the incident but your participation failed to get recorded? Did the report writer mishear details over the radio and hence misreport apparatus or important details of the response? Did you not get JPR (job performance review) credit from an exercise?

The more personnel that review past incidents – and soon after they occur – the more accurate the reports will be. That helps you, and the whole organization.

Use Response Utilities to check the time of the incident or exercise, as well as the duration. Check participation, including a quick scan of participants faces. (The current user is shown first, otherwise those with identified roles – e.g. command or instructor – come first.) check if the activity is still draft (shown as blank below) or has been published.