253 - NERIS - the paradigm shift for the US fire data collection with Craig Weinschenk

Why Fire Data Must Change

Wojciech Wegrzynski 0:00

Hello, everybody. Welcome to the Fire Science Show. We need better data. We need more data. That's a, a common thing we can agree when we discuss multiple, multiple different fire problems or problems, uh, in fire safety engineering in general. It's a common answer that I get in the podcast. But how does one get more data, and, uh, most importantly, how does one get more actionable, robust, uh, reliant, uh, data from fire incidents? The systems that we have in place, they are working, and we're all aware of their limitations and, pretty much what can be done with the data has already been mostly done. We're-- we know where we are at. To get ahead, we, we need a major change. We need new systems. We need a paradigm shift in how the data is collected. And you know what? Today, I'm extremely happy to talk about such a paradigm shift, and it's not one in the making. It's not one in a planning. It is one that already is deployed across the US, and it's working. It, it, it's moving. It's gathering hundreds of thousands of records every week. And, um, I'm so excited to, to bring this up because, it's not very often where we have a true paradigm shift, uh, happening in front of our eyes. And even more happy that, uh, for this discussion, I can bring back my friend, uh, Dr. Craig Weinschenk from ULRI, Fire Safety Research Institute, uh, to the podcast, who for the last several years has been dealing, with this problem, who has been developing, the statistical tool that we will talk about, the National Emergency Response Information System, NERIS in short. And, uh, Craig is an experimentalist. You've heard him on the podcast talk about Flowpath. That was a popular episode. And, uh, he was also one, uh, working on FDS in the past, and now, uh, dropped on pretty much data analysis and statistical analysis, uh, tracking tool. He told me he has not burned anything in, in a very long time, which, uh, for a fire experimentalist is, is kind of disappointing. I hope, uh, UL, uh, sends him to a very engaging and demanding fire experimental set so he recovers from all of this statistical work. But, uh, yeah, let's focus on the NERIS and how much it gives to the US Fire Service and how much it can give to fire safety engineers worldwide, because solutions and fire problem across the g- globe are very similar. We can all learn from this. And yeah, I'm more excited than usual for this episode. I'm excited for all episodes, but this one more than usual, and you should be as well. Let's spin the intro and jump into the episode.

Sponsor Message From OFR

Wojciech Wegrzynski 3:19

The Fire Science Show podcast is brought to you in partnership with OFR Consultants. OFR is the UK's leading independent multi-award winning fire engineering consultancy with a reputation for delivering innovative safety driven solutions. we've been on this journey together for three years so far, and here it begins the fourth year of collaboration between the Fire Science Show and the OFR. So far, we've brought you more than 150 episodes, Which translate into nearly 150 hours of educational content available, free, accessible, all over the planet without any paywalls advertisement or hidden agendas. This makes me very proud and I am super thankful to OFR for this long lasting partnership. I'm extremely happy that we've just started the year four, and I hope there will be many years after that to come So big thanks, OFR for your support to the Fire Science show and the support to the fire safety community at large that we can deliver together. And for you, the listener, if you would like to learn more or perhaps even become a part of OR, they always have opportunities awaiting. Check their website@orconsultants.com And now let's head back to the episode. Hello, everybody.

Meet Craig And Define NERIS

Wojciech Wegrzynski 4:36

I'm joined today by Craig Weinschenk, uh, from ULRI. Hey, Craig. Welcome back to the podcast.

Craig Weinschenk 4:42

Yeah, thanks for having me. Excited to, to see you again. It's been a few years, I think, since the last time we've chatted.

Wojciech Wegrzynski 4:47

Yeah, man. And, and the project we're talking about, I remember you sent me a, a text message. That was like three years ago. "Oh, yeah, we're starting this new project. Uh, it's gonna be announced soon. Uh, maybe one day we'll talk about it." Here we are, uh, three years later talking about it, and I feel it's way too late, but I'm, I'm so happy that, that you're here to share the practicality of, of the Neris. Was it a, a rollercoaster for you before we go into the details?

Craig Weinschenk 5:15

Um, yeah, if, if the rollercoaster's just a straight uphill amount of work, then, then yeah, we're, we're still in the uphill in terms of rollercoasters.

Wojciech Wegrzynski 5:25

You're still, yeah. I mean, uh, the listeners will know in, in one hour, uh, why are we discussing it in this way. So anyway, uh, a big task was dropped on the ULRI shoulders and on your shoulders, which was to revolutionize the way the statistics are gathered from, from the fire incidents. And, it's perhaps one of the most mentioned things when I, when I interview people in, in this podcast. We need better statistics. Like, we need, like, we need to know what's happening. We need real world data. We need to, you know, join our stuff, our safety engineering with what the fire brigades are doing, and we can do it through statistics, uh, countless times in the podcast. So I think the, need for that is omnipresent and obvious. H-how, how was it when you were starting? How, how w- how did the landscape look like? Like, wh- why would ULRI jump into such a massive endeavor as building Neres?

Craig Weinschenk 6:21

Yeah. So, I think the key part is, is, is a little bit about

NFIRS Origins And How Reporting Worked

Craig Weinschenk 6:25

the history of where, where the US was in, uh, incident reporting

Wojciech Wegrzynski 6:29

Okay

Craig Weinschenk 6:30

will help us kinda set the stage on why we made the decisions and why we are where we are. So, know, in the 1970s, 1970, uh, five was the initiation of the National Fire Incident Reporting System in the United States, known as NFIRS. Uh, this came about following the America's Burning Report in 1973, and it also led to the establishment of the United States Fire Administration in 1974. And so for the last 50 years, NFIRS was the system, that all fire incident reporting was sent to at the, the national level and then also through the respective states.

Wojciech Wegrzynski 7:03

Mm-hmm.

Craig Weinschenk 7:04

now in 1970s, this started as carbon copy forms, so little literal paper forms with the white, pink, and yellow copies that you would fill out, and then you'd have triplicates to send around to the, to the respective, um, you know, authorities having jurisdiction. And over the last 50 years, it moved from paper forms to some digital forms, but it, it really was a digital version of those paper forms. So still very numeric code heavy, uh, very rigid in its, its design structure because the database reflected the paper form that existed. And the workflows then were also kind of, very good in the '80s and '90s but started to fall behind the modern tech stack when you get to the late '90s and, and 2000s. And so the workflow was, department would log their incident, and they would log it either in, the paper form and mail it to the state or to the, to the federal government. They would log it in a kind of a digital app that kind of existed at, at the United States Fire Administration level, or they would, use a third-party records management system. So in the United States, a lot of these third-party software stood up to support and help fire departments manage not just incident reporting but their entire stack of, of operations

Wojciech Wegrzynski 8:17

was it like omnipresent? Every fire department had to do that?

Craig Weinschenk 8:20

so it's a, it's a voluntary system in the United States, but there's, least at the federal level. But to be eligible for federal funding and federal grants and things, you need to be able to prove that you've been submitting incident data to the United States Fire Administration. Because the United States Fire Administration has an obligation requirement to report to Congress about the state of the fire problem in the United States. That

Wojciech Wegrzynski 8:42

Okay

Craig Weinschenk 8:42

of that U- United States Fire Control Act in, in the 1970s. And so you, you had this obligation to, to get data to, to the federal government. And then a lot of the state fire marshal's office started to put in and enact state laws that required, incident reporting for fire fatalities, and then eventually expanding to all fires and, and incident reporting. So there's state laws that are maybe a little more restrictive than the federal piece in terms of reporting frequency and occurrence. so it's, it's a pseudo-volunteer system because it depends on the, the respective states and what, what legislation is in place

Wojciech Wegrzynski 9:20

And who would be filling that out? Was it like the commander of the, of the incident? Was it like the, the chief of a station, like someone who would just fill it out a week after an incident, or they would do it in the truck when they're coming back to the base?

Craig Weinschenk 9:34

Uh, that's, uh, an excellent question because it's, it varies widely across the fire service in,

Wojciech Wegrzynski 9:41

Okay

Craig Weinschenk 9:41

So in some departments it's who's ever the low man or low, low person on the fire on the totem pole, Because no one joined the fire service to do paperwork. So the, you know, the rookie got the incident reporting, which sometimes is good because they just came out of training, but sometimes bad because their experience is a little bit limited. and the whole idea was make the red go away, right? Fill out the required fields and submit the record so that the compliance box was checked.

Wojciech Wegrzynski 10:09

Okay

Craig Weinschenk 10:09

Um, now some departments said, "We're, we're gonna make a, an officer fill it out," and a chief officer would have to review it before it, it makes its way to another agency. So as departments grew and matured and data became a, a larger part of their daily workflows, they added more and more, you know, QA QC pieces in their respective departments. So it varies still to this day. Some departments require, you know, a battalion chief to sign off before the record is complete. Uh, some still will say, Hey, you're the person that knows how to use the computer. You're the person filling out the incident report."

Wojciech Wegrzynski 10:47

uh, in terms of data collected, was it like just one rigi-rigid set of data, or there were kind of, you know, twists of that? I don't know, a fire brigade in California had a different one than in New York, uh, they just made them up their own, uh, versions of it?

Craig Weinschenk 11:03

That's, that's another really good question. One of the challenges that we faced w- as we started to roll out, uh, the replacement, is that there's the, there was the NFIRS standard, and the last major update to the standard was in 1999 in NFIRS 5.0, and there was a, a minor release. We got to 5.3 in, in kind of 2014. So the, the standard hadn't really changed, and if, if anyone's listened to any other episode of your podcast, we've talked about how much the fire environment's changed over the

Wojciech Wegrzynski 11:33

Yeah

Craig Weinschenk 11:34

years in all aspects, right? But the,

Wojciech Wegrzynski 11:36

From 75 for sure.

Craig Weinschenk 11:38

Yeah. And so the questions being asked were the same ones being asked in, in, in 1999 as in 2026. And so what ended up happening is some of the states had supplementary questions, or a department might create a plus-one code, an ability to create a custom or question that layered on top of the standard set. And that's good for local analysis, but the challenge was everyone created their plus-one codes to be their plus-one codes. So you'd have 20, 30, 40,000 different plus-one codes that weren't able to be aggregated because slightly vary-- different variations of the question set or the answer set, or

Wojciech Wegrzynski 12:18

Mm-hmm.

Craig Weinschenk 12:19

different terminology from the East Coast to the West Coast. So we, we ended up, uh, fracturing a lot of our data, even though our mission was probably the same and the intent was the same, because it was all being done at the local level and, and, and the vendor space, which is excellent, right? They, they really helped facilitate this for, for local analysis and even some state analysis. the piece was is they, they might have a, a, a number of departments in state A and a number of departments in state B, right? And so they were fractured across the country in terms of their, their client base, and so everything was slightly different. The terminology was slightly different. And so you ended up with this, this really kind of, data set that, that, lost, uh, some of its value because of its uniqueness. Uh, and that's a challenge when you're trying to aggregate and understand statistics, right? Is, is, we take that shotgun approach and all of a sudden we're, we're a little too fractured for, for our own good.

Wojciech Wegrzynski 13:11

Yeah, well, i-i-if the goal is to provide the Congress an update, I assume accumulating data on like a sum of deaths in fire, probably is straightforward, though you would have to define what means, uh, to die in fire, which probably is, is a challenge on its own. But, but let's assume that this one is easy. But if you want to compare, you know, the fire safety or risk or hazard in one state versus another, and you have... You're talking about different approaches in, in the gathering those statistics, that, that's probably not possible with, with the previous data. I, I assume this was a limitation of the pre- previous database at the agglomeration stage. Any other severe limitations of that?

Craig Weinschenk 13:51

Yeah,

NFIRS Limits Plus One Codes Delays

Craig Weinschenk 13:52

I mean, the, the other part too is, is how the data actually moved between the agencies, uh, who collected it and then the agencies either at the state or, federal level who collected it. So you've got the creators, they would create the, the incident report and export, uh, a caret-separated plain text file. Um, they would export them probably once or twice a month, sometimes once or twice a quarter. They would zip them up and then email them around to their state or drop them in an FTP upload for submission to the federal database. It would then process them, and then at some point in time in the future, it would send back a response that said, "Hey, these might be your errors. you know, you need to fix these. These, these records failed to validate." So it became pretty tricky because the workflow from the person who entered the record on, you know, we'll call it, you know, say May 20th, they might not get the response that there's an error from validation into the federal system. the plus 15 days for them to export out of their own system. They send to the state maybe then plus 15 days for, for them to, to aggregate across all of the thousand departments in their state, and then they might send to the federal plus 15 days, right? so by the time it comes back, you're like, "What was I doing?" and then because of the FTP upload part, updating records was very difficult. It was, it was oftentimes, well, as long as it got in, worry about the updates later, even though they might update their record locally. So, so the accuracy and the, the data sets at the local level and the federal level might not have always been one-to-one because of how hard it was to update a record. becomes particularly important for the fatality piece because the initial record might be a non-fatal casualty that became a fatal casualty

Wojciech Wegrzynski 15:36

Yeah, and you have to update. Okay

Craig Weinschenk 15:38

in that workflow and then updating it became, well, records might be right, the state's records might be right, but the federal record might not have gotten that update, or it might not have even left the department if that update happened. It became a real challenge of, of how do we stay in sync with all of these different pieces floating in there?

Wojciech Wegrzynski 15:57

Yeah, I, I, I can only imagine like issues or, you know, technical challenges like that just piling up over 50 years of this being used, which is natural for a system that kind of outgrown the initial idea, you know? Uh, and eventually y- you have to move on and, and here NERIS, which is National Emergency Response Information System, uh, comes on, on the horizon. So, tell me about the first days, like when you approached the project. Like what did you do on the first day?

Craig Weinschenk 16:26

I think the first day was, it was, uh, talking to my, my fiancé and letting her know that things, things are about to change a little bit. Uh, uh, yeah, the hours are about to get a little bit longer. but after that it was, "Okay, how do we get to work to support the fire service," right? That's, that's kind of our mission here at FSRI, and, you know, we are fortunate enough to, you know, be the, the contract performer for the United States Fire Administrator and the United States Fire Administration. The, the partnership there has been just absolutely tremendous, and, you know, truly a partnership. We, we, you know, collaborate with them every day to make sure that the, the system we're building and, and have, have built is, is meeting the needs of, the federal partners, and then also connecting with every local department downstream to make sure that it's meeting their needs. Um, but when we started, it was about a little over three years ago now. You know, the first piece is let's first recognize that... And, and you said it best with, with NFIRS, is that it worked for a really long time and did a lot of good things for understanding the fire problem in the

Wojciech Wegrzynski 17:24

Yeah, for sure.

Craig Weinschenk 17:25

Um, but the demands, the size of the fire de- service, right, all of the, responses that they have to tackle outgrew, um, where we were. So we had to make sure that when, when we started building, that we're building for the next 50 years, not building for the next two years.

Wojciech Wegrzynski 17:41

Yeah

Craig Weinschenk 17:42

because we have one shot to deploy, a system of this scale. We've gotta be thinking about being dynamic, thinking about being elastic in terms of how we're, we're designing our architecture all the way through our data schemas and then to our data visualization

Wojciech Wegrzynski 17:58

Uh, d- day one, was it already,

Building NERIS Cloud API Security

Wojciech Wegrzynski 18:00

"Okay, we have to design a new nationwide system for everything?" Or was it like, "Let's brainstorm how could it l- look like, and if it's good, we're gonna roll out?"

Craig Weinschenk 18:09

Um, so we-- before we were awarded the, the, the contract, um, we went through a, a funding mechanism where there was a pretty rigid peer review assessment. So I had to write a 25-page proposal outlay basically what was our proposed architecture, our view, our, our kind of what does the next five years of development look like, in the event we were the, the awardee. So, you know, day one wasn't coming from scratch. It wasn't like... We had to prove ourselves that we, we had a plan in place for the next five years of development and rollout and how we would do it. the cool part is the-- I looked back not too long ago at some of the schematics I used in that proposal, and while the, the graphics have matured, fundamental approach, uh, is still the same.

Wojciech Wegrzynski 18:55

Mm-hmm

Craig Weinschenk 18:56

so we, we are built in a cloud-based architecture, so we use AWS as our, our cloud hosting infrastructure. and then our back end, actual fundamental tenet is we use a, a service or tool called Kubernetes. So it allows us to horizontally scale resources, based on load. So as, you know, more and more departments use the system, either through our API or through our user interface, um, we're dynamically scaling resources so that their

Wojciech Wegrzynski 19:26

Okay

Craig Weinschenk 19:27

is, is unimpacted

Wojciech Wegrzynski 19:28

so it's, so it's like a distributed system, not just a one server room, uh, at URI that, that, uh, if meteor hits you, the, the fire department is really screwed with

Craig Weinschenk 19:39

right? I mean,

Wojciech Wegrzynski 19:40

okay

Craig Weinschenk 19:41

the-- Which is, which is interesting 'cause, like, the NFIRS system was actually on a, on a server in, in, at a FEMA facility. So, you know,

Wojciech Wegrzynski 19:48

う ん。

Craig Weinschenk 19:48

a cloud-based architecture was, was paramount. And then we have, you know, we have worked so that we can be operational in multiple avail-- uh, availability zones, and if we needed to roll over to an entire different, you know, zone within the AWS architecture, we can spill over from U-US East one or two to US West one or two. All of that's gotta be designed from the ground up so that, you know, we can maintain operational, uh, functionality

Wojciech Wegrzynski 20:13

There's so many sides to a project of this scale, like starting with, uh, how does one do the report-- reporting itself? Like what data you want to report? When do you want it reported? Uh, how do you manage like changes to the data like you've mentioned? Like, uh, some-- unfortunately, someone turns into fatality, you have to update that. But also, you know, how to gather that, how to process it, how to share it back, how to manage version control, you know, uh, how to make sure that you don't run out of the disk space in 10 years, you know. It's, it's unbelievable h-how much things you, you have to go outside of, you know, just the simple question of what data I need to collect. Like, w-when you approach this, w-what was the bigger pain? Figuring out what data you want to collect and what you're interested in as the end product of Nereus or the technicalities of how we make sure that this is seamless, robust, and, and, and safe?

Craig Weinschenk 21:17

Um, they're kind of interconnected. Uh, One, I'll say some of it was easier because I hired some really talented people and then got out of their way. Uh, you know, hire a good data architect and a, and

Wojciech Wegrzynski 21:29

Yeah

Craig Weinschenk 21:30

and a good principal software engineer and you're, you're you know, in good hands in, in some of those pieces. But I think they come with different sets of unique challenges. So, from the architecture perspective, you know, there's some of those solutions are kind of well known. How do we build a scalable cloud-based architecture? We weren't necessarily inventing something new there, but we were building something, you know, that we knew we had to, to design for the fire service. And so

Wojciech Wegrzynski 21:54

Mm-hmm.

Craig Weinschenk 21:54

a, a tricky piece was, well, how, how do we build this system? in- initially thought there's about 23 to 25,000 fire departments in the United States. We have 31,000 in the database right now. So, from the scale of operation, every department needs a page, every department needs their own So there's, you know, authentication into the system and then authorization that says, "You're a member of this department, you can only operate and see data on, on this department." building all of that out is all custom and, and took a lot of work to make sure that the security side is, from, from a, a system perspective. Learned more about data security in the last three years than

Wojciech Wegrzynski 22:34

Yeah

Craig Weinschenk 22:34

I would as an experimentalist. Uh, but that, that piece is pretty tricky. But then at the same time, everything that we do from data transfer is done through our API. So from a data submission side, from a data, you know, retrieval side, data visualization side, the API is that layer that sits between all of the cloud-based infrastructure, all of the architecture, data storage, all of that, the API sits on top, sits inside of a secure, you know, cloud environment, and then the user interface analytics and, and the pieces the fire service kinda interacts with sits on top of that. So i-imagine like a big iceberg, right? All of the architecture and everything's under the waterline. The API is our waterline, and then everything else that, that you can see and touch is, is above that, plane. And so when we talk about the data schemas and why that's complicated, well, it's one thing to ask questions of what people are going to collect, and there's a number of challenges that, are associated with that, and I can, probably fill an entire hour on, on those challenges. but we-- every-everything that we shape, it's, it's, is this a nested field? If it's nested, what are the, the requirements to link the tables? So there's the foreign key constraints to link table A and table B. and then so the more nested we get, there's advantages to some of that for being a dynamic question and answer set. and then that payload has to be shaped to be submitted to our API, then that API has to then be able to say, "Okay, the payload comes through successful," so all the validators to ensure that the data quality is where it needs to be. and some of those tables are really good because they enforce a rigidity to the data. Because if there is a nested table, well, the field can't exist unless you've properly structured it and, and put it in, in this, this connected table. So we, we process all of that and then we write it to the database. If we're gonna make a change, it's okay, well, there's a change to the schema, a change to the API, a change to the database. So there's, there's difficulties in building a system that still allows us to update while also, being able to enforce the current state of the system

Wojciech Wegrzynski 24:42

Okay. I really let this, like, 20th minute, I really want to jump into what you're collecting, but I, I still have more questions. Um, y- y- you said you hired a really good data scientist, you hired a really good programmer. Did you also hire a social scientist that would tell you, like, how to make people fill it out well? How to make sure that the firefighters want to, to fill it out well? Like, do the firefighters feel linked to a greater good they're building up through those statistics? Because, you know,

Getting Firefighters Buy In

Wojciech Wegrzynski 25:10

for a bloke filling up the form, it's like an perhaps annoying. I would feel annoyed if I had to fill out the form when I'm tired after, an event. But at the same time, I'm contributing to a much bigger thing overall, and everyone is doing that. So, so w- w- was this also a part of consideration while building the technical system?

Craig Weinschenk 25:30

we, we don't have a true social scientist by degree on staff, but we do have folks that are-- been in the fire service.

Wojciech Wegrzynski 25:38

Mm-hmm.

Craig Weinschenk 25:39

so we, we hired a, a chief, a former chief from Rogers, Arkansas, who, who is kind of our, our, NERRS's fire chief, so to speak. He doesn't really like that phrase, but you know, it's fun. but fantastic human, fantastic chief. And, um, one of the things that we said at the very early on when we were building this team is, is we have performance goals as, as a team, and w- you know, we need to achieve X, Y, or Z, you know, piece of code at this time. And then we have development goals. It's, it's just part of, you know, FSRI's and URI's structure, right?

Wojciech Wegrzynski 26:12

Yeah.

Craig Weinschenk 26:12

But for everyone on NERRS, their, their development goal is to spend time with the fire service, is that every software developer should be doing ride-alongs, should be at firefighter conferences, should be interacting with the folks that are gonna use the software, 'cause that's the best feedback you're gonna get is from a, from a firefighter. They're, they're the most honest group of folks that, that we get to

Wojciech Wegrzynski 26:31

Yeah.

Craig Weinschenk 26:32

If something's not working, they're gonna tell us.

Wojciech Wegrzynski 26:34

Uh, brutally.

Craig Weinschenk 26:36

and, uh, I think that's the most important piece is, one, we, we hired folks that knew that this was, was part of the job and, and that should excite you, right? This should get you, to, to wanna work on a project of this magnitude. that's been the most rewarding piece is getting, you know, from our front-end developers to our back-end developers, spending time with the fire service. everyone's seen what the current state of things are. when we go to conferences, I bring the developers to our booth, um, so they can interact with our, our end users. Um, they see all of the tickets that come in through our help desk, and the, and the pain points that folks are, experiencing, whether it's through direct application of our system or through a third-party connected system. we need to be where they are. in lieu of a, a social scientist, it was we're, we're gonna bring our team to our stakeholders.

Wojciech Wegrzynski 27:28

And

Craig Weinschenk 27:29

FSRI does most things, right? Is that we work with our stakeholders and, and, you know, this project is no exception

Wojciech Wegrzynski 27:36

and I even had an episode with Steve and you, I believe, that, uh, we're discussing about how to work with the fire department. Not for, not, you know, on behalf of fire department, but with. And I, I assume this is at the very core o- of doing that, and I, I, I'm very sure that you've done this part with the, the highest possible standard on that. Okay, so the data itself, because I think the data is at the core in here. what exactly are you trying to collect? Uh, is there a hierarchy of what you are looking for? And if you could also kind of tie it back to, NFIRS, like i- is there like a leap from the previous kind of collection to the, to the new world? And also how... Okay, that, that's like seven questions. Okay, I'll stop here. Yeah, just, just

Fatalities Updates And Lives Saved

Wojciech Wegrzynski 28:28

go on that.

Craig Weinschenk 28:29

there's, there, there's certain requirements. We still have to fulfill the, the congressional mandate. So we, we need to understand the fire loss problem in the country. And so we still have questions around, um, injuries and, and, and fatalities for both firefighters and,

Wojciech Wegrzynski 28:44

S-s-s-sorry, do you have a strict definition of an injury and fatality for, for this purpose?

Craig Weinschenk 28:51

So, so for us, it, it, for, for fatal, if, if there's a, coroner, uh, designation, right, the death certificate says fire, then it's a fire fatality. now we're, we're... Does everyone who fills out the survey recognize and, and adhere to that? Probably not, right? There's, again, 30,000 fire departments in the United States. However many, you know, hundreds of thousands, if not, you know, millions of folks that interact with the submission side. But that's where we wanna go. and in particular, it's for the update piece, right? The, the on-scene fire fatality is, is the fire service has a pretty good handle of those that are, that they're aware of during operations. It's what happens downstream, right? That, that may be during transport or in the

Wojciech Wegrzynski 29:31

I ask this, I, I ask this purposefully because it's a part of the discussion here at the EU Firestat project, uh, that I've also had Martina and Mohammed on, on the podcast before. Uh, and it's n- like wh- when there's a, a death at the site, it's pretty obvious. But if a person you know, um, dies as a consequence of a fire 30 days later in the hospital, it may not be that obvious link, you know? And, and, and this is one of the statistics that moves the political needle around, you know, because, uh, that's the one that actually gets stuff, uh, that, that triggers, you know, political decisions. A- a- as sad as it would be, like you need But, but th- that, that's the one that, that really moves the imagination of, of the, of the, of the lawmakers, right?

Craig Weinschenk 30:18

And so, so one of the cool parts of, of how we built it is, know, the when, when a record gets submitted to the NERS API, it's immediately available to the state fire marshals for those respective states and to the United States Fire Administration. So you have both these AHJs, operating and seeing the data, seeing the same data at the same time, which is really powerful because is an update to a, a status, whether the, the s-state fire marshal is now pulling, you know, death certificate data in, in their state looking at this, they can now link that back to the, to the call and say, "Hey, Fire Department X, go update your record." And because of our API, very, very easy to update a record. We have, we have modern put and patch methods, so you can go in and update that record.

Wojciech Wegrzynski 31:05

Hmm.

Craig Weinschenk 31:05

incident has a history table, just like if you're using Git or anything else, right? So there's a, there's a history table in every incident. So we'll know the record was updated. We'll know what fields were updated on a, on a per record basis. So then we can look... When we look at statistics at a given year, can say how many were entered as, as fatal, how many were changed into fatal, or how many were possibly incorrectly fatal and moved back to, to a non-fatal, uh, state. So all of that will help us. The fact that the state fire marshals can see that data and their teams, right, can look at this data, 'cause, you know, in the United States we've been, we've been averaging around 3,000 fire fatalities a year. If you were looking at, at death certificate data, we're probably under by about 50%.

Wojciech Wegrzynski 31:49

Hmm

Craig Weinschenk 31:50

And part of it is because it's really hard to update in some of these systems. And so, you know, by, by putting that at the forefront of we need to make it easy to update a record, uh, we need to track the updates, right? That helps us tell the story of any aggregate statistic, not just, you know, the, the fire fatality.

Wojciech Wegrzynski 32:07

Okay, so injuries, fatalities, that, that's one, uh, data point. w-what about other ones?

Craig Weinschenk 32:12

So the, the, the counter to that, right, is lives saved.

Wojciech Wegrzynski 32:16

Mm-hmm.

Craig Weinschenk 32:16

now, we couldn't tell you... I mean, I could tell you there's about 4,000 saves in, in the, in the database in Q1, across all hazards, about, uh, 1,000 fire saves in, in the United States, which is really cool. That-- And that's a powerful thing because lives saved is why we do the work we do. Um, the lives lost is, is w- why we're, we're after more resources and, and doing the research and the fire prevention work and all those other pieces. but the fire service does amazing work 24 hours a day, seven days a week, 365 days a year. This enables them track the wins, right? When you're in a loss-based business, get hard. The critical events, the traumatic events start to stack. How do we then give them the opportunity to handle the saves? And putting that at the forefront of, of our data visualization of, all of the aspects of how we talk about data, that's the carrot. We talked about the social side of this. Um, that's a huge piece. Uh, and there's chiefs now leveraging that data in, in their Q1 reports to their s- to their mayors, to their councils, saying, We, we are now being able to better track lives saved in the fire department." And that's not just from fire. It's from swiftwater, it's from trench rescues, elevator rescues. We had a big ice storm that came through, you know, the United States in, in February, and particularly in the Mid-Atlantic. So a ton of ice rescues that in the old system was just a medical call.

Wojciech Wegrzynski 33:50

Mm-hmm.

Craig Weinschenk 33:51

you're deploying your rescue squad, you're doing rope rescues and steep angles down, down hills to rescue somebody the bottom of, a hill that, you know, for all intents and purposes, that's a rescue because that's a removal from a place of harm to, bring them to a Place of care. that matters, it's a huge piece of what we do

Wojciech Wegrzynski 34:09

this something new for NERIS versus NFI RS or is, was it already in the previous system?

Craig Weinschenk 34:15

there was a loose tracking, uh, in the sense that you could in, very deep in some of the modules, you could assess that there was some, a rescue made, but not the same way that we, we have a true rescue module, uh, in terms of the actions and tactics you're taking. Even from a structure rescue, we're looking from isolation from how you searched, all of the things the fire service does, we're tracking to operationalize what they did on scene. So giving them credit for the work, for the training, for the skills. you know, when we talk about incident types, the other big thing we did, was in, in the legacy system, you chose a single incident type, and you had to choose it to the lowest number. So the lowest number being the hundred series in fire, and then kind of, you know, your, your public service at your seven hundreds and eight hundreds. But, uh, response is complex. You know, if you've got a car fire a crash, uh, maybe, maybe you now need to send or you're going to send a rescue squad to, to do extrication and extraction, or at least a truck that's gonna have those tools. You're gonna send an engine for water and suppression. You're gonna send a medic unit for potentially transport. And if you're fighting for resources and you're, and you're trying to understand the, the emergency response problem in, in this country before that was a fire, it was a car fire. So, in the 100 series, the fact that you had medical and, and your rescue squads on that call kinda got lost. And so when, when apparatuses are the price they are, when equipment's the price it is, and are, are also, you know, the most valuable asset, how do we get more people and then how do we train them, we need to tell the story that they are responding to comp-complex incidents. We need the rescue, apparatus, we need the rescue tools, and we need the trained rescue personnel. We need the medical apparatus, the medical people, and the trained medical personnel. We need the suppression apparatus,

Resources Unit Typing And Timestamps

Craig Weinschenk 36:05

the suppression tools, and the suppression personnel. a per-- an individual is, is all three, but on a scene of this complexity, you need the, the, the additional staffing to make that all go.

Wojciech Wegrzynski 36:17

And if it's all tagged under a car fire, it could be like a super minor thing or, or engagement of multiple, multiple squads, right? w- okay, in terms of resources used, how deeply you're tracking it because, like, you can do it by ladders or engines that are sent. I may be wrong, but I think in UK they were tracking pumps and how many hours the pumps were working, uh, and, or what kind of pumps. In Poland, I also may be wrong, but I think we're counting out how many pairs of firefighters or how many firefighters were engaged. At least that's what you hear in the radio when they tell you, "Oh, there's a fire. There has been like 70 pairs of firefighters battling it." So, so w- how do you track the resources per, per incident?

Craig Weinschenk 37:03

That's, that's, um, it's

Wojciech Wegrzynski 37:06

And, and, and is it automated or someone has to fill it out?

Craig Weinschenk 37:09

Uh, it depends. so the way we built this is, is there's kinda two tiers to NERS. There's what we call our entity spec, and so that's all the demographic information about a department, including geo-coded station locations. each station has its series of units, so all the units are tied to stations. All the units are typed to FEMA unit typing, so we know exactly what a structural engine is versus a brush truck versus, uh, a tower ladder over 70 foot or under 70 foot. you know, uh, whether you have suppression capabilities or not, whether it's a quint, um, all the way down to your aerial apparatus, fixed wing or drones. So the entire stack of, of equipment is all standardized and typed. It's all tied to geo-coded stations. Stations are inside of a jurisdictional boundary, so we have geo-coded jurisdictional boundaries for about 28,000 of the 30,000 departments. we built out from the ground up, let's understand the capacity capability perspective of, of, of the fire departments. Then on an incident, when you log and submit your incident records, and so if you've got a connected CAD to your records management system or a connected CAD into our system or if you're just doing full manual entry in our system, um, you're tagging the units that exist in, in the database. So now we know the capability or the unit type of every unit that's being submitted. And it's not just E23, because E23 could be a structural engine or it could be a brush truck, depending upon how people, uh, name their units across the country. But you've tagged it to a type that's standardized, then we ask the number of personnel on the apparatus on the call.

Wojciech Wegrzynski 38:47

Mm-hmm.

Craig Weinschenk 38:48

get into the individuals yet because of the challenges with PII, PHI, and things like that. We don't want the names of the firefighters. We just wanna know how many firefighters were on, and so now we can look at the staffing per apparatus, apparatus per call. We know where the apparatus would call itself home, so we know now, know, when you get there. And from, from the unit level perspective, it's when were you dispatched, when did you arrive? Uh, we have tactical timestamps from like water on fire time to start of search, search complete. Those tactical timestamps are not as uniformly used because you need a little more sophistication either from your CAD and dispatch or your incident command to-- Someone's gotta write those timestamps down. They're not as well known or automated, so we're still working with the industry to move the whole, whole industry towards better ways to track that from radio traffic and, and command boards and things. But

Wojciech Wegrzynski 39:41

W-w-what's a cat in your dictionary?

Craig Weinschenk 39:44

uh, computer-aided dispatch, so the dispatch center, so the, the

Wojciech Wegrzynski 39:47

So not AutoCAD.

Craig Weinschenk 39:50

that Um, yeah, so all, all of that is we, we've got, you know, we have a, a robust integration partner program, so a lot of this stuff is automated through their local systems. the really cool part is there's about 40 different third-party systems sending data to us, from about 13,000 different departments into our API every single day, um, which is, which is really exciting. They, a department, they have different levels s- of sophistication from the digital and data perspective, um, and we support all of those different variations

Wojciech Wegrzynski 40:20

In terms of those timestamps, how do they get recorded? Like, is it automated? I know the call is transcribed or the radio is transcribed and you know? Or is it like someone after the, the, the, the, the firefight, they're going, "Okay, yeah, we arrived like seven minutes in. We had water 15 minutes in," et cetera. Like, is it human dependent, automated?

Craig Weinschenk 40:43

Uh, both. So at

Wojciech Wegrzynski 40:45

Okay

Craig Weinschenk 40:47

or at least, integrated side, right, maybe not sophisticated, but most integrated from a technological perspective, your apparatus have automation for wheel stop. Uh, you put the parking brake on, we're getting on-scene time. when the pump gets in gear, you're, you're saying, "Okay, that could be a surrogate for, for water

Wojciech Wegrzynski 41:05

Water. Okay

Craig Weinschenk 41:06

out of the apparatus is going. Um, so there's, there's pieces there that are automated already in, in s- some of these, you know, newer apparatus. then there's the piece in their, in their mobile data terminals in their apparatus is when, when they arrive on scene, they're pressing a button that says on scene. so that's automatically getting transcribed from the press of a button in their, in their apparatus into their records management system to then send to us.

Wojciech Wegrzynski 41:32

I, I mean, this changes the quality of the data or robustness of the data, and it also changes the, um, effort of the user, how much they have to input. If, if like stuff gets filled out automatically, it gets input. But, you know, uh, immediate, you know, threat is, you don't want to blame someone. "Oh, you, you got water in 15 minutes and you should have after 10 minutes," or, you know... How did you deal with that aspect? Because y- like for me, w- whatever fire brigade is doing, they're like working under extreme stress and, uh, they're humans. Humans are made to make mistakes. That's, that's a human thing to make mistakes. And, I would never be willing to, you know, blame firefighters or something. Sometimes it goes better, sometimes it goes worse. It's a human thing, you know? But you know, wh- when the statistics are automatically uploaded and the fire marshal sees that, "Oh my God, you guys were super slow with water," you know, uh, that, that's a, that's a challenge. H- How, how did you consider that aspect?

Craig Weinschenk 42:39

Yeah. So, so When we say auto uploaded, right? So even for a records management system or, or, or so, there's still QA QC happening at the department level before they send it. It-- the automation happens when they lock the call. So the fire department fills out their record. They say, "Here's the review of our, our record." They basically say, "Yeah, this is an accurate representation of our, our incident." They close the call. Once it's closed in a third-party system, it then gets sent, to our API and then is, is available to the State Fire Marshal and to 96 Fire Administration.

Wojciech Wegrzynski 43:13

o- one day someone could park at the hydrants and you just cannot access it. And it, it, it's not within like... It, it will take a minute or two to get through that problem. And if it's also in a strong wind, and also there was a traffic jam, and also you have arrived on the wrong side of the building because that's where the dispatcher sent you in, this can add up to a significant delay, you know? And, uh, while it's potentially justified and people were doing their best job, uh, tough luck, right? Uh, uh, uh, yet in the statistic it's gonna look bad

Craig Weinschenk 43:46

Yeah. So, so there's a number of ways we handle that. So one, we track

Impediments Narratives And Data Context

Craig Weinschenk 43:50

your dispatch location as well as your final incident location.

Wojciech Wegrzynski 43:54

Okay

Craig Weinschenk 43:54

uh, we do have that part handled. Your, your dispatch location is often automated out of your CAD, and then when you fill out your incident report, you're saying, "Hey, I was not-- I did not end up where I was supposed to be," or, "I was sent in the wrong place," you can update that. And that-- the really cool part then is now we can start to see how location differs. there specific geospatial areas in your, jurisdiction where this is happening? Uh, if so, then that's an education problem either to the citizens or to the dispatchers to recognize, hey, we've got a problem in this very tight little area where there's some miscommunication. Maybe it's new construction, new road, whatever it might be. So we can handle and control for, for the location piece, and recognizing that those are different is a big deal from a, a data quality perspective and a, a data analytics perspective.

Wojciech Wegrzynski 44:43

Th- this is something that's empowering the fire brigade, you know? This is something that helps you. And I'm like, I'm asking this question because I am also mindful that, they may be actually, you know, reluctant to share some of the data because of, of, of stupid ideas o- of responsibility or other things that actually, uh, perhaps should not apply in, in this regard. But, you know, uh, w- we're not talking about having picnics at, at the river. Every fire is a tragedy for someone, you know? And, and that, uh, that has consequences and that, that, that's a very tough job, you know, to, to answer and, and to do, especially if not everything goes, uh, uh, by, by your, uh, will. Uh, in, in ter- in terms of those incidents reported, like i- i- is it like everything? Like c- car accidents, medical emergencies, cat on a tree, et cetera

Craig Weinschenk 45:34

Yeah. Yeah. So we, we have, we're all hazards. and the, the other piece on the data quality and, and data concerns, there's a couple other things we have in place that I wanna highlight because I think it's important. we also collect what your dispatch code was. So in the United States there's a lot of, um... it's called determinant codes, so there's priority dispatch. And so the dispatcher's actually going to listen to the caller and based on a handful of questions they're asking, they get a five-digit code that corresponds to the number of apparatus and the, the type of emergency you're responding to. Um, so we collect that. So we know what you were sent to, then you fill out in the incident what were you actually arrived at. And that often plays a role of, okay, well, we had-- were expecting X and we, we got, you know, 12, right? So we, we were expecting a letter, we got a number, and the, you know, number's far bigger. So tho-those, those things are, are real and they happen and we track all of that. And then the third part is we actually have in, in the narrative section, so in addition to all the structured data, we have two narratives. We have one that is the final disposition of the call, so what is your summary of the incident? then unique to, to NERRS is what were any impediments that happened on the call? So we actually have an explicit field for you to say, "Hey, there was a, car parked in front of the hydrant. The hydrant was damaged, the hydrant was frozen," um, whatever, whatever those things might be. Or, "There was a new hazard we had no idea how to handle,"

Wojciech Wegrzynski 46:59

Hmm

Craig Weinschenk 47:00

seen this call." That goes in your impediment narrative so that we are giving them the, fields to justify abnormalities. Because in most cases, the, I mean, the fire service on 99% of the call, uh, they're used to it, they're trained for it, they're ready to go. But with 35 million calls

Wojciech Wegrzynski 47:18

Yeah.

Craig Weinschenk 47:19

States, that 1% is

Wojciech Wegrzynski 47:20

1% is a lot, yeah

Craig Weinschenk 47:21

amount of call volume. So we've gotta give them these avenues to, tell their story of, "Hey, this didn't go as planned. Here's why." then we can use that data, right, between the United States Fire Administration, between the state fire marshals and FSRI and the larger fire service community to say, "How do we better support the fire service to handle those calls? What research needs to be done? What community risk reduction needs to be done? Uh, what public education needs to be done so that 1% becomes a half percent, becomes a 0.1% in terms of things that are anomalies?"

Wojciech Wegrzynski 47:59

okay, uh, y-you're gathering all those data, and I'm, I'm pretty sure we have not even covered all, a-all or most of them. But, you've also mentioned, uh, ability to act on the data or access the data. W-what are you giving back to the departments,

Dashboards Maps Mutual Aid Linking

Wojciech Wegrzynski 48:15

to the communities, to the regions, to the federal government at those different levels? Like, what, what kind of access they have to the data, uh, and how can they browse it?

Craig Weinschenk 48:25

Yeah. So we do it in a couple different ways. Uh, first and foremost, we have a, a, a custom dashboard that's designed for, for NERS data available to every fire department in the country. when you log into our user interface, we have both an insights tab, which is providing kind of a real-time summary of every record that's been submitted, so you know if you're expecting 200 records in the database and you see 200 there, everything has been submitted successfully. Then we have an analytics dashboard that is fully interactive, from filtering and geospatial, so every call is, is geocoded and

Wojciech Wegrzynski 48:59

Okay

Craig Weinschenk 49:00

Um, you can see it in your jurisdictional boundary. You'll see what

Wojciech Wegrzynski 49:04

So, it's not just a list that you can filter, but also like a map that you can look at the locations, et cetera

Craig Weinschenk 49:10

Yeah. So we, we have a full geospatial map. We have a heat map, time of day, day of week, so you can see trends relative to time of day, all linked to your incident type, all linked to your casualties, all linked to the location module, and also to emerging hazards. So if there's batteries involved or, uh, medical oxygen involved, everything is cross-referenced, all searchable. and then the really cool part is also all of your aiding departments. So if you're responding with other agencies, those calls are linked. You can view those calls so you know what the rest of the department was doing, you know the total resources on the call, because oftentimes you're-- ask for help, it means you need additional resources. You can see then their side of the record. In the legacy system, you just made it up. You just said, "Hey, I think they got here this time," or you're calling them to try to get their data. Now we can say, "Hey, if you're on the same call and you link each other," like tagging somebody on Facebook, you see the picture on their

Wojciech Wegrzynski 50:06

Did,

Craig Weinschenk 50:07

whatever

Wojciech Wegrzynski 50:08

do you link them? By dispatch number?

Craig Weinschenk 50:11

couple ways. Um, so we, we do it by, uh, one, you have to tag the other agency. So you tag the, the unique identifier of the department. So every department, every i- department in the system has their own NERS ID. Uh, their ID is based on their state and county code, so it's all geospatial. Um, and then you're linked to the other department. So you, you, you tag them, they tag you. then we know call create time, so when did the call happen? And then we know where the call was, so we have the lat, long. So we can use location, time, and department tagging, uh, to show, hey, these are the calls that you were tagged on. Here's when they occurred. These are our most likely linked, uh, calls. So we give a-- We're working on how do we improve the probability score of surfacing that, hey, this is probably, two calls are probably linked, right? It's still work in progress on the probable, but most departments will know when they see that in their list from the other agency, that's, that's this call, right? The human nature part of it does a lot of lift right now, but we're working on improved automation.

Wojciech Wegrzynski 51:13

H-how, how do you handle it when there's like a massive wildfire? Like there's 100,000 acres burning con-concurrently over seven different counties. I, I mean, you cannot tag it all to one code.

Large Wildfires Incident Analysis IRWIN

Wojciech Wegrzynski 51:25

So y- did you give a hashtag, uh, like, or like

Craig Weinschenk 51:29

Yeah, a couple-- yes and yes. So we, you know, most, if, if there's a large wildfire that say on state land, there are state forestry departments, and then all the locals will support the state forestry departments. They can all tag the s-state foresters. That helps us link the call. the other piece is in our core incident, doesn't really get into that, but we do have a secondary module called incident analysis, um, that's kind of like a surrogate for investigation. So that's going live, at the end of this month, and that kind of hangs on the core record. for an outside fire then, in the United States, any large fire gets named. It has an incident start date and an end date and all of these other attributes. So you fill the incident analysis part out, and that allows you to link all the core records with the incident analysis record. So an IA record could have multiple core records, right? That can all start to tell the story of, "Hey, we, were all on the same named fire, though we were here at this little region for this time." Um, and so the other part is that in, in the wildland space, there's another federal system called IRWIN, and we're working to integrate all of the local data sent to them as they handle more of the state and federal data. So we're collecting the necessary elements them to get the rest of the record that they don't often get because the local jurisdictions don't always submit that other system.

Wojciech Wegrzynski 52:56

Man, that, that, that's, that's awesome. Like, it, it's linking so many things into a workable format that you can actually do. I mean, I, I, uh, I've talked with Steve Koelbler a month ago and he said that you just crossed 10 million incidents. That sounds insane. Congratulations on, well, it's 10 million of, of incidents, so perhaps congratulations is a bad word, but, uh, uh, the scale is, is just impressive, you know? how much is the database growing, and how do you see what you can do with the data already on this sample? Because 10 million incidents is a, is a huge sample already.

Craig Weinschenk 53:32

Yeah. So we're, we'll cross 13 million, uh, now in, in, in about a couple days. So we process on weekdays around 88,000 incidents, um, on average. The

Wojciech Wegrzynski 53:43

Absolutely

Craig Weinschenk 53:46

Um, and then on the weekends it'll-- it's a little bit less. There's just less folks that close out records on, on Saturdays and Sundays, typically in the 60 to 70,000 range, um, on, on weekends. it's about 10 days. Every 10 days there's a, a million records, arriving into, uh, into the system. So the cool part is from a technological perspective, right? The 10 million is, that we handled it, the system scaled dynamically. The database is robust. you know, from a uh, sociological perspective, that's a lot of calls for service, right? That's a lot of bad days that have happened, in Q1 of of 2026, right? So there's, both sides of that piece. the exciting part from a fire service transition perspective is that s- just about 62% of those calls have arrived within 24 hours of the 911 call.

Wojciech Wegrzynski 54:37

Hmm.

Craig Weinschenk 54:37

So what was, we might export

Scale Metrics Speed Adoption Challenges

Craig Weinschenk 54:40

15 or 30 days or even once a quarter and send them around to the state and federal government. We've shrunk that timeline down with a modern API, to basically the next shift. Um, so that's really important. Um,

Wojciech Wegrzynski 54:54

S- from those plus 15 days that we were discussing before when the

Craig Weinschenk 54:58

and plus

Wojciech Wegrzynski 54:59

copies were sent.

Craig Weinschenk 55:00

generous, right? That

Wojciech Wegrzynski 55:01

Okay

Craig Weinschenk 55:01

that was the probably the, the most generous time window, and that would only get you to sending that email to your state, right? Now we have this available to USFA and the state fire marshal for all departments submitting, right, to their respective agencies in this, nature of, time lag. And, and, uh, a lot of that 40% that's older is still some of it is backfilling from folks who had some technological challenges onboarding. So I think the true number is even a little bit higher. Um, and I think 50% of all calls are occurring within the same calendar day, uh, which is, which is really impressive. So not just 24 hours, but same day. and, I think the, the other piece that's, that's really exciting, right, is, is we just crossed 60, 60% or we will cross 60% of all departments reporting. a lot of work to go.

Wojciech Wegrzynski 55:54

Mm-hmm

Craig Weinschenk 55:54

we're still working to get the, the next in-increment in terms of, you know, what does it take to get to 70, 80, 90, 100%, right? I don't, I

Wojciech Wegrzynski 56:02

but the rollout is now like, uh, full, like everyone's supposed to be trans- transferring to this system from the NFIIRS, right?

Craig Weinschenk 56:10

Yeah. So, so that the legacy system went offline on December 31st of, of

Wojciech Wegrzynski 56:15

Okay

Craig Weinschenk 56:16

for, for collecting new incidents. Um, so there are a lot of departments that are still collecting locally that are, you know, haven't submitted that are... You know, we have some, some tendency challenges to break, right? That people might only

Wojciech Wegrzynski 56:28

Is the onboarding difficult or?

Craig Weinschenk 56:30

for the most part, reporting's pretty easy. Uh, we, we've cut a lot of the, the extra fields. The hardest part is all those timestamps we talked about. Entering time is just, it's cumbersome. It's, you know, just no matter how good you make your user interface, putting times in, you know, gets to be typing it all out date and time, right? Because we can't pre-populate the, the day stamp because incidents wrap days. They could wrap multiple days. So we've gotta be cognizant of what we pre-populate for folks because you can't assume the incident is a single day. then you've got the time zone challenge of all our time zones. So we store everything in UTC with, with all the UT off- UTC offsets. States are non-uniform in time zones. Then you've got Arizona with daylight savings time and not daylight savings time. So there's all of those things, right? Like, if, if, if I didn't like time zones before, I definitely don't like them now. Uh, that's one of the, the, the trickiest parts is being, you know, so, so standardizing all that behind the scenes in our database, on our API, communicating that to our integration partners, how we store it. you know, that's, that's been, you know, big, big challenge.

Wojciech Wegrzynski 57:40

Uh, o-o-one question I should have asked before, but, uh, I, I really will feel bad if I don't ask it. Do you collect any information about the fire safety engineering of the building in which the fire took place? Like did it have sprinklers? I mean, if you had the layout, that would be awesome, but, firewalls, class of fire resistance, smoke control, stuff like that.

Craig Weinschenk 58:02

now we're, we're mostly focused on

Fire Protection Data Parcel Weather Enrichment

Craig Weinschenk 58:05

smoke alarms type usage, sprinkler systems presence type usage, um, or f- and, and both failures in, in either,

Wojciech Wegrzynski 58:13

ん。

Craig Weinschenk 58:14

general other fire alarms, CO alarms, all of the other pieces, and all the different cooking suppression pieces. aren't getting into the larger fire protection of the building, or any of the, the larger commercial infrastructure. but one of the things we are doing, there's kinda twofold on, on that piece. In the legacy system, you could only enter fire protection information if there was a fire.

Wojciech Wegrzynski 58:37

Mm-hmm

Craig Weinschenk 58:38

So you, you only knew that y- either it activated and, and, or didn't activate and things like that. We also have the human response part of like, okay, did the humans, or did the people evacuate? Did they not evacuate? What w- what was that piece? But now we also surface that for any incident type. So if you're going for a non-emergent medical call or a public service call, you can document that there's sprinkler systems. You can document that there are working smoke alarms or tested smoke alarms. when we start to then we're, we're gradually building this larger database of presence of sprinklers, presence of smoke alarms. The next schema that we're rolling out is our community risk reduction schema. So when you're doing smoke alarm installs, when you're doing all of the, the prevention work, all of that will layer in against the incident data, against the incident analysis piece. Our CRR also includes investigations, so inspections and all of the pieces on the-- where we'll get into more of the traditional fire protection pieces because that's gonna come from a code enforcement person who's gonna know the nuances of all that information. Trying to ask a firefighter post-incident whether there was a smoke exhaust system is much harder than asking the investigator or, or the inspector to do so. So the, the method and the approach has always been put the right questions in front of the right people at the right time because otherwise we're, we're already de- burdening the fire service so much

Wojciech Wegrzynski 1:00:04

I, I fully understand that, but, you know, in the exact same way like you said it's important to highlight the lives saved during the fire operations, I think for us fire safety engineers it's also like a valuable knowledge to know how often our solution actually worked, you know? And, and, uh, i-i-if, if there's like a, a shift in the way we collect data that could actually give us a little bit more insight into how successful are we as fire safety engineering community in, you know, actually delivering what we would like to do. Because I mean, if in the end nothing what we do works, then, uh, man, shit, that's not good. That's not great.

Craig Weinschenk 1:00:43

Yeah, and so the, the other cool part is we, we do have a national parcel database, so every call is getting enriched with parcel information. so we, we have things like assess-- tax assessed value, land assessed value. Uh, we do have construction type designation of, like, usage type and our fire protection in the, in the construction type and building in that parcel database. That's not something we're asking because it's in an existing data set that we're leveraging to enrich the data. So every call that comes in, we ask also how do we get buy-in, too, right? So we, we enrich it with parcel information, we enrich it with weather data. So every single call when it's, when it comes in, we, we grab the lat-long of the call, the call create time, and hit our, uh, weather database API in, in the states and grab temperature, pressure, participation, humidity,

Wojciech Wegrzynski 1:01:32

Wind.

Craig Weinschenk 1:01:33

wind, you name it, all, all included.

Wojciech Wegrzynski 1:01:35

Yeah

Craig Weinschenk 1:01:36

allergens, we get air quality index, we tag it with the census block and track. Um, we're adding things like land ownership, so it's state, federal, local land. if there's a vehicle involved, if you enter the vehicle identification number, we pull back all of the vehicle information from safety information, airbags, uh, make and model. Um, in our invest incident analysis, we have a consumer products module to understand any of the consumer products information. we have a battery module to know like watt hours and voltage and charging status, and was it a, a listed product? you know, all the cell and, and cell construction, so prism or, or, you know, uh, I, you know, I should know all the battery stuff. It's been a while since I've been involved. Uh, Adam will get mad at me if he hears this. but y- you know, all of the, the battery information, whether it was being used indoors, outdoors, was it designed to be an indoor or outdoor battery? Um, so all of those things are being tracked or available to be tracked, quite extensively. And then we ask about suppression. So did it reignite? How did you choose to suppress it? What tools were used? So there's quite an extensive set of information there that goes probably more in depth than most people want, but these are critical incidents that we should capture it on, and it's designed to be within the fire investigator to come in and, and add all of this information that they know now they have a place to tie it to that core record.

Wojciech Wegrzynski 1:03:03

Yeah, I mean, those integrations, you know, if I think about building information modeling that we are forced to do in m- so many projects, actually, this is the, the final destination of building information modeling, because now it allows us to do so much more than we could ever do if we did not have that. And eventually, you know, maybe it's not 2026 when we integrate everything seamlessly, but in 10, 20, 30 years, that, that's highly likely that we will have very good integrations, uh, between those systems. And actually, the, the, the thing that I've just asked you to track whether-- what types of systems would be there would be an obvious, because if you went and address, there's a database that knows what the building at this address actually had, you know? And, and it's just about, you know, linking resources and processing the out- outputs, which, which would be very, very valuable. Um, to, to finish up, what's the number one challenge that you're looking at today? So you've developed the system, you've built it up with a team of amazing people, rolled out to some, you know, brave people who tried to, to test it and went through all of that, rolled out nationally. What's your next, uh, biggest challenge with this?

Craig Weinschenk 1:04:20

I'd say m-maintaining the trust that people gave us on,

Wojciech Wegrzynski 1:04:24

Yeah

Trust Data Sharing And What Comes Next

Craig Weinschenk 1:04:25

on, on day, day one, day zero, that we've gotta continue to provide value back to them. So everyone who's using the system from someone submitting, someone consuming and using and, and from the, AHJ side to the fire protection side to the, you know, fire response side, we've gotta continue and to maintain the trust. We've gotta continue to adapt, so making sure that, know, as we roll out new features, we're not losing sight of the initial intent is, is providing value to the fire service so they understand their risk have resources at the ready to respond. it's a really hard problem, uh, and we've still got 40% of the country to go.

Wojciech Wegrzynski 1:05:08

Hmm.

Craig Weinschenk 1:05:08

so you know, that, that's been the hard part. There's no magic button that says, "I wanna email every fire chief in America." Uh, if there was, we'd, we'd be much further along than we are, but I'll, I'll take 60% at this point in terms of, of participation reporting from a statistical perspective, right? We can start to look at national level data as we're, we're getting closer and closer every day to, to have some, some, some pieces out. And then, and then one other piece too is, is, to set up the sharing so that the fire protection community can learn and benefit. So while we have all of the jurisdictional data released and under the NERRS public, we're working on how do we get the incident data out. So working with, with the United States Fire Administration, of course, to get this data out to, the larger research community, to the public in a way that is respectful of the response, but, but giving enough information to folks to, do research to help the fire service. So to your point earlier about, well, what if the, the water on fire time... There's certain things that just aren't public data. They don't need to be public. Um, but a department has control over their API, so if they wanna have researchers connect to their API, they give the permissions out. Um, if they wanna have third-party analytics tools to connect to their, their API, they can do so. So every department has granular lever- granular level control over all of this, and I think that's the other big piece that, that, that is, you know, the next thrust is making sure the share side of this is done right and is done in a way to help the fire service.

Wojciech Wegrzynski 1:06:40

I mean, th-that's a big responsibility but also opportunity for you because, you know, I, I don't think every, every fire department would have a data scientist on their team. But, if you can work around, you know, general processing ways that just work and, and that just help inform them with some actionable data actually that, that they can benefit of, and you most likely have already worked it out what's like the number one stuff or num- 10 most important statistics people look into. Like, you can then deploy that on all the departments that are out there and, and empower thousands and thousands of firefighters with stuff that they potentially were not even looking at.

Craig Weinschenk 1:07:24

E-exactly. That's part of our, our mandate and, and the really cool part of working with USFA is, we build for one department, and that could be the largest department in the United States in, in either FDNY or CAL FIRE that, that have, FDNY has 220 stations and 17,000 uniformed personnel. They respond to over a million and a half calls every year to the small rural department that is single station respond from home volunteer. The analytics are designed for everybody. their-- every department has their analytics page. We build it, you know, from sound science and say, "Here it is for you." That, that is a directive from, know, the, the project is to make sure folks can, can use their data. but if you wanna go further, there's the API, right? There's all these tools, and we have API clients that we've built and released. Um, so building this open architecture environment has, has also enabled folks to have more access than maybe they, they had in the past, which is exciting 'cause it's their data, right? They're the ones that, that went to that call. They own that record. Um, right. They're choosing to share it, for research and, and grant opportunities and state funding and, and all of those other requirements. So we've gotta make sure that we're, we're giving them return on their, their effort.

Wojciech Wegrzynski 1:08:39

Awesome. Uh, Craig, thank you, thank you so much for, uh, covering all of this. Thank you so much for your hard work on this, on this extremely important project. And, one day when, uh, you work through the first year of RecurZ and found some actionable, uh, you know, advice that we can give to people or maybe some tough lessons for fire safety engineers, I'm also interested in those. We need to catch up once again and, uh, not just see, uh, what data are we collecting, but what, uh, the data told us and, uh, if it was really worth it. I'm sure it was... I'm sure it is worth it, but, uh, I, I would love to see the, you know, actual outcomes of all of that

Craig Weinschenk 1:09:21

Uh, absolutely. Thanks for having me today and, and looking forward to, uh, to joining you once again in the future.

Host Takeaways And Closing

Wojciech Wegrzynski 1:09:27

And that's it. My God, this is so intense. Like we, we've spent an little bit more than an hour talking about this system, and we've barely scratched the surface. And, and Craig also gave me a short, walkthrough or, you know, five-minute demonstration, and, oh, this system is amazing. Like the amount of data they are collecting, the ways that it is processed on the dashboard. When Craig said they, they have a dashboard for fire brigades to look at, it's outstanding what the fire brigade can see. Like I, I can already see that, when you are filling out paper forms and mailing them to your authorities, it was just, you know, an obligation. Today, when you're collecting the data at the level of granularity that we were discussing with Craig, you are building up a database of knowledge for yourself, and it's actionable knowledge. It is actionable data. It, it truly is knowledge. Like it, it gives you a completely different understanding of your own operations and how they tie into the region. On the regional scale, you can track how well the resources are spent, how, how-- which station needs more equipment, which station needs more people. Where's the area where we perhaps should build a new station? And I, I'm really looking-- Well, I'm not looking forward to major fire incidents, but I'm looking forward to having data analysis at this level, at this level of granularity to be performed after a major wildfire or a major, disaster that occurs because that, for the first time, I think we can have, like, this insightful investigation carried out at this scale with this ease. You, you could do that in the past, but it would took you months and months to collect all the resources needed. Here, you can filter them by a hashtag and, and, and you get pretty much everything you needed. And also the integrations, the future integrations. If we had a national BIM model database where every building would be stored in that, which is possible. If you have to support-- If you have to supply BIM model of your building for your building permit design, then there's no reason why this could not be stored and accessible in the cloud. Perhaps a little big, uh, endeavor for 2026, but who knows, in 10, 20 years, will that not be a standard? And if we have that, we have an amazing link between the response, the fire hazard, the fire occurrence, and the buildings themselves. Wow, it-- this is blowing up my mind, and I'm, I'm so happy that this, uh, project happened. And I must say, you know, it's been three years since Craig told me he's, he's moving on to this. Three years is very little time for such a development. Like, this is unbelievable how fast this was built, how fast this was rolled out, and I can only imagine that it's gonna be maintained and updated and upgraded and kept in a great shape for a very long time. Congratulations, ULRI. This is an outstanding piece of job. You can have, uh, you can put the Fire Science Show Badge of Excellence on the website of this project. I approve this project. This is amazing work. Okay, uh, that will be it for today's episode. Next week, I'm gonna bring you, uh, more fire science, and it's gonna be hard to top this one off, but I will do my best. There's a lot of great fire science out there in the world, and, uh, it makes its way to Fire Science Show and makes its way to you. So I hope to see you back here next Wednesday. Cheers. Bye.