Resetting Your FireApp Password

Users may use the Change Password button from the login screen to reset your FireApp password.

  • Input your FDID in the Officer ID field.
  • Click the Change Password button.

FireApp Change Password Button









You will then receive a temporary PIN (sent to the e-mail address on file with FireApp). Input the code along with your new password (and confirmation second entry of that password).

FireApp Change Password Screen












Click the Submit New Password button and you’re ready to log into FireApp.

Hiding and Showing the Left Pane in FireApp on the MDC

With the implementation of FireApp on MDCs, there is one minor change to the look and feel of the program (and it only shows up on the MDC version).

When you launch FireApp on the MDC, note the left pane:

FireApp Logon Screen MDC


The left-pointing double arrow, located above the Exit button in the left-side panel, will enable you to minimize the left pane and give you more room to work in FireApp (so you don’t have to scroll to the right side of the screen).

To see the full buttons again in the left pane and restore the full panel, just click the right-pointing double arrow.

FireApp Arrow Right


Until you get used to knowing which buttons are Validate and Lock without seeing the full buttons, you may want to use the new arrows.


Reporting for a Unit that Fails to Repond

Is a Fire App Unit Report completed for a unit that fails to respond? And if so, how is that report competed? In short, it depends.

  • If ECC marked the unit as FFR and the unit did not respond (i.e., no enroute time), then FireApp will not create a unit report for it and therefore there is no need to complete a FireApp report.
  • If ECC marked the unit as FFR and the unit did respond (i.e., with enroute time) after being marked as FFR, FireApp will create a unit report for it and the unit officer will have to complete that report.
  • If the unit was in fact FFR, but ECC failed to mark it as FFR, then FireApp will not treat it as FFR unit and went ahead to create a unit report for it. In this case, the commander can notify FRS IT and we will check with ECC. Once ECC confirms it is FFR, FRS IT will remove the unit report from FireApp and adjust FFR statistics for Ops Chief office accordingly.

Determining Who Does the FireApp Reports (Part II)

INCIDENT REPORT vs. UNIT REPORT – Who is in charge?

Incident reports are for reporting what happened on the INCIDENT.  It is written by the Officer in Charge (Incident Commander) and, yes, every incident has an Incident Commander (even a single EMS unit response). The report may include information such as:

  • Description of the scene
  • Explanation of the situation
  • Incident priorities
  • Strategic objectives
  • Incident Action Plan
  • Key incident command assignments or the Command structure
  • Significant events that occurred
  • Other agencies involved in the response
  • Incident outcome


Unit reports are for reporting the details as they relate to a specific UNIT.  It is written by the Unit Officer and may include information such as:

  • Apparatus positioning
  • Observations made by unit personnel
  • Information provided to Command by the unit
  • Assignments, tasks, or orders received from Command
  • Actions taken by the unit
  • Results of actions taken
  • Explanation or justifications for actions
  • Unique circumstances encountered
  • Disposition of personnel, apparatus, and/or equipment

Also, it is important to point out that when you get on the scene of any incident, and you place the responding unit(s) in service, you automatically become the Incident Commander, even if you were not originally dispatched on the call.  For example, while driving to the PSTA on a training detail, you come across a PIC that other units have been dispatched to, but you determine that it is a PDC and you clear all of the responding units.  You just became the Incident Commander.  If you make the decision to clear the assignment, you are now the only one who knows the situation that was found on the call, and why the decision was made to place the other units in service, so you are now responsible for documenting that information on the Incident Report.

Finding NFIRS Reference

Searching for the right entry for a field in your FireApp report? Not sure what the difference is between two codes? Here are links that may help:

Because they’re PDFs, you can search for a specific word or phrase. Just press Ctrl-F (Find) on your keyboard for a search box when you load up the PDF.

Avoiding A Common Mistake in FireApp for Units Cancelled Enroute

Scenario: E702 and A702 have been dispatched on a call and E702 is cancelled enroute but A702 works the call. A702 takes the person to the hospital. The E702 officer returns to the station to work on his/her FireApp reports and marks both the unit and incident report as cancelled.

Might this sound familiar? Since A702 personnel still had a patient and a transport, FireApp is confused.

The MCFRS database administrator spends a lot of time clearing up such issues before he may send date to NFIRS.

If your unit was cancelled enroute, you absolutely want to identify that in the unit report. Please do not mark the entire incident as cancelled, though.


Using Good Data in a Misunderstood FireApp Field

Scenario: You are on the EMS crew of a box alarm. You go to the fire and set up shop but no patients ever need to come your way. Should you list BLS care (and/or ALS care) since those were the capabilities of the personnel on board?

The answer is no. As the field name implies, we’re talking about what level actions were taken. If you never saw a patient, you’re not going to list that you performed BLS care (and/or ALS care if a medic unit was involved).

So, what to use? Not that I’m a big fan of the Other (Misc) option, but it’s still an option. If you’re ever going to use something that ends in Other, please make sure you have carefully looked to see that no other options apply (such as Standby). We need to report good data, after all.