Fire Department Incident Reporting Software: Why a Month of Runs Goes Missing Before Anyone Notices

The report that never closed

It is 10:40pm on the back half of a 48. A captain sits at the watch desk with a run from three days ago still open: room and contents fire in a two family, engine and truck from his station, a mutual aid engine that arrived, worked, and never got documented anywhere except the tape. He knows what happened on the fireground. What he does not know is which property use code the state expects for a two family with a converted basement unit, because the last time he guessed, the record came back weeks later flagged with an error he could not reproduce. So he saves it incomplete. There are eleven more behind it, and the crew just got toned out again.

Multiply that by every company officer in the department and you get the pattern every records management officer recognises. Reports are written days late from memory, coding is inconsistent between stations because each shift learned it from a different training officer, and nobody discovers a gap until the annual export runs and a month of runs simply is not in the national dataset. By then the officers who ran those calls are on different shifts and half of them cannot remember whether the smoke alarm was present and operating.

The cost of a gap is not the report, it is what the report feeds

Incident data is the only quantitative account your department gives of itself. Assistance to Firefighters and SAFER grant narratives are written from run volume, response time and incident type distribution. Insurance Services Office evaluations look at your response and deployment record. The annual report to the city council that justifies the fourth engine company is built from the same numbers. When a month is missing or when structure fires are coded inconsistently across stations, you are not producing bad paperwork, you are producing a weaker case for staffing and equipment than the department actually earned on the street.

There is a second cost that shows up quietly. When a fatal fire becomes a lawsuit or a state investigation, the incident record is the department's version of events. A narrative typed four days later, missing the mutual aid unit and the arrival times that the CAD already recorded, is a document that hurts you. Officers do not write bad reports because they are careless. They write bad reports because the tool asks them to reconstruct from memory what the dispatch system already knew in real time.

Officers retype what CAD and the ePCR already captured

Every unit that responded, the times it was dispatched, en route, on scene and available, the address as verified by dispatch, the initial call type, the units that were cancelled: all of it exists in your CAD before the officer opens the reporting screen. On the EMS side, the ePCR already holds patient count, disposition and transport destination in a structured format. In most departments the officer types some or all of it a second time, and the two records then disagree about arrival time by ninety seconds, which is exactly the kind of discrepancy an attorney enjoys.

Prefill is not a convenience feature. It is the single change that most reliably moves report completion from days to the same shift, because it converts the officer's job from data entry to review and narrative. That is a job an officer will actually do at the kitchen table before end of shift. Any build that does not start with the CAD and ePCR feed is building a nicer typewriter.

The national schema is moving under you

The US Fire Administration is replacing the long standing National Fire Incident Reporting System with the National Emergency Response Information System, and the two do not model an incident the same way. Confirm your own state's timeline with your state fire marshal's office rather than with a vendor sales engineer, because the state sits between you and the federal dataset and sets its own submission window and its own additional required elements. Many states already collect fields the national schema never asked for.

What this means for a build is specific: your data model cannot be the national schema. It has to be your incident, with the national and state schemas as export mappings that are versioned and swappable. Departments that hard coded the old schema into their forms are now paying to rebuild forms. Departments that stored the underlying facts and generated the submission from a mapping table are changing a mapping.

What ESO, ImageTrend, Emergency Reporting and First Due actually leave on the table

These are real products with real fire service knowledge behind them, and for a department that fits their model they work. Be clear about where they stop.

• Suite gravity. The prefill you want between dispatch, ePCR and the incident report generally works cleanly when all three are the same vendor. If your CAD is from one vendor and your ePCR from another, you are back to an interface project, and it is usually a paid one on the vendor's schedule rather than yours.
• Local fields on the vendor's calendar. When your state adds a required element or your chief wants a mandatory tactical field on working fires, you file a request and wait. Departments routinely handle the gap with a free text note field that no one can report on.
• Validation that runs too late. Products vary on this, but the failure mode is consistent: coding errors surface at export or at the state, weeks after the officer who was on the call has forgotten it. Validation belongs in front of the officer at submit time, tied to what the CAD says happened.
• Your data behind a report writer. Getting a full, queryable copy of your own incident history out for a grant analysis or a deployment study is often a support ticket rather than a query. That is fine until the week you need it.

What a custom build has to include

The scope that earns its money is narrower than most chiefs expect. Start with a report object that holds the facts of the incident, populated automatically from CAD at the moment the last unit clears and from the ePCR when the patient record is signed. Layer a validation engine on top of it that runs the state's rules plus your own department rules while the officer is still in the form, with plain language messages, not error codes. Add an approval chain that mirrors your actual policy, company officer to battalion chief to records, with the reasons for every kickback stored so the training officer can see which codes the department gets wrong.

Then build the export as a mapping layer, one mapping per target, so a schema change is configuration rather than a rewrite. Give the records officer a completion dashboard that shows open incidents by station and by officer with an age on each, because the single most effective control in this whole system is a battalion chief seeing that his station has nine reports older than four days. Finally, give yourself a real query surface over your own history, since the grant narrative and the council presentation are the reason this data exists.

What it costs and how long it takes

In our delivery experience across this category, a first release covering CAD and ePCR prefill, the report form, inline validation, the approval chain and state export runs $75,000 to $160,000 and ships in 12 to 20 weeks. The department is submitting real records at the end of it, not piloting. A full records platform adding training and certification tracking, apparatus and SCBA checks, hydrant and preplan data, occupancy links and exposure reporting runs $200,000 to $500,000 phased over 9 to 18 months.

What moves the number up: the number of separate systems you want to read from, since a CAD interface and a NEMSIS compatible ePCR interface are two different projects and each vendor charges for their side. Criminal justice information handling if your incident data touches law enforcement records, because access control, auditing and authentication requirements are engineering work, not a checkbox. Multi agency scope, if a county wants one system across departments with different chiefs and different coding habits. Historical conversion, which is almost always underestimated: ten years of prior incidents with dirty codes take real time to map, and you should decide honestly whether you need all of it or the last three years plus an archive.

What keeps the number down: one department, one CAD, one ePCR, and a decision to leave training records and apparatus checks in whatever they live in now until phase two.

When buying beats building

If you run fewer than roughly 1,500 calls a year with a mostly volunteer roster, buy. A hosted product plus a records officer who chases completion weekly will outperform a custom system nobody has budget to maintain. If your CAD, ePCR and reporting are already one vendor's suite and the prefill genuinely works, and your state has not added fields the vendor refuses to support, buy and spend the money on turnout gear.

Build when two or more of these are true. Your CAD and your ePCR come from different vendors and the interface never got funded. Your state requires elements your vendor will not add, so your officers key them into a spreadsheet or a note field. You have been surprised at year end by missing or rejected records more than once. You are a regional or county fire authority where several departments have to report as one and their coding does not match. Or your department is building a real data program, meaning someone is expected to answer deployment and staffing questions from this data, and the vendor's report writer cannot answer them.

How to choose a developer

Ask them to describe the difference between what your officer knows and what the schema wants, before they show you a screen. A developer who has done fire records will talk about incident, exposure, unit response and the fact that a single incident can carry multiple exposures with their own codes. A developer who shows you a form builder has not read the specification.

Ask specifically how they will validate. If the answer is that the state will tell you what is wrong, walk. Validation has to run in the officer's hands before submit and it has to be rules you can edit when your state changes them, without a release.

Ask what CAD they have actually pulled from and how. Names matter here. A vendor supported interface, a database replica and a nightly file drop are three different projects with three different failure modes, and the answer determines whether prefill happens in seconds or the next morning.

Ask who owns the code and the data and get it in writing before kickoff. You should own the repository, the hosting accounts and an unrestricted right to hire someone else. At Digital Heroes it is yours from the first commit. The fastest way to test any other vendor is to ask for a full export of your incident history in an open format and see how quickly they say yes. Start there, before you sign anything.