Fixing NFIRS by Dr. Matt

Having spent the last year or more digesting NFIRS specifications and tooling and “getting into the headspace of NFIRS” I was intrigued to come upon this article “Now is the Time to Finally Fix NFIRS: Let’s Make ‘Timely Information Sharing’ the Rallying Cry for the Post-COVID Fire Service” by Dr. Matt Hinds-Aldrich - Chief Fire Data Nerd. Not a short article, but fascinating … I learned a lot; some historical background to combine with my fresh perspective, and digested some interesting proposals.

Dr. Matt (if he doesn’t mind me calling him that) ’s fourteen points are these:

1. Move to a Federated or Semantic Architecture
2. Jettison any module where another group or agency has established an industry-recognized data format
3. Operational data matters
4. We need to reduce the burden of data entry upon firefighters
5. Relational databases and traditional data dictionaries limit progress
6. Without an emphasis on training any changes to NFIRS will be wasted
7. Improve the usefulness of narrative remarks
8. Expedite data sharing
9. Automate as much of the data sharing process as possible
10. Develop data sharing APIs
11. Adopt JSON as default data format
12. Fix the fledgling feedback loop
13. Continue to make it easy for small rural fire departments to enter data
14. Improve the economic estimates for fire loss and saves

Now I don’t have standing to comment on many of these, but as a developer (and now an NFIRS developer) I’ll comment on some:

#5 Significant agreement here! Wading through “coding lists” has been the most exhausting part of learning NFIRS. Right now NFIRS coding pushes the job of data normalization out to the reporting firefighters (who know NFIRS the least well, know subtle choices least well.) Data quality isn’t improved this way. A selected coding value expresses 100% confidence in the intent, when (quite frankly) a firefighter might easily have misunderstood the value they picked from the long long list, or simply missed a better alternative value. Trying to cover the many possibilities with long lists of codes leaves a “cannot see the wood for the trees” problem. Less is more, and we can do better than putting this on firefighters.

#11 Adopting JSON would make the data far more accessible. It is good that eNFIRS now allows UTF-8 (not just plain ASCII) but despite the NFIRS file format parser and format writer taking only minutes to develop, the file needs computer processing to read. It would be far more accessible to the average developer if it could be transported as JSON. JSON is self-describing a field name then the field value - both together - not a value and its field based on its position in a pile. Back in the day positional placement saved a lot of bandwidth, but today it is more important for it to be human readable. It is a small difference, but it would make a meaning difference for developers, and lead to better tooling, APIs and solutions.

#7 Narratives might be unstructured and variable quality but they also seem primed for data mining with machine learning techniques. I wonder if the new eNFIRS infrastructure will allow any of that.

#2 NFIRS could use better extensibility, even if just for special studies. COVID-19 impact data just isn’t data it can gather. COVID-19 has had a significant impact on fire departments at every level, and NFIRS could be helping fire departments collaborate to face this challenge. One NFIRS “special study” with 4 choices cannot even begin to cover COVID-19 impacts, risks, exposures, mitigation approaches and successes and so much more that fire departments are dealing with. NFIRS would need to add a COVID-19 transaction or module, and/or (at least) COVID-19 aware coding options for existing elements. (A JSON format and/or semantic architecture might allow this rapid extension, and federation might allow new data dictionaries to mature quickly in a time of significant change, like COVID-19.) Without some of this flexibility it’ll be a difficult challenge for NFIRS to participate in COVID-19 data gathering.

#12 When I first read ‘fix the fledgling feedback loop’ I expected to read about the data quality feedback loop where the reports that departments enter is verified somehow; comparing against similar departments/scenarios, reviewing odd coding choices (in case of error or misunderstanding). Having reporting feedback would be a boon, but having data quality feedback would increase the data quality making those reports more valuable. The currently automated feedback warnings and errors on bulk import are mostly syntactic not semantic, so miss large swathes of feedback/review opportunity.

#4 and #13 Is what Responserack is working to do…

Thanks for the insights …

I have formed my own opinions on NFIRS working with this specification, but seeing Dr Matt’s 14 steps - no doubt shared/discussed with members of the NFIRS community over years - helps me add layers to that understanding. I look forward to following NFIRS ongoing evolution in the years ahead.