Okay, cool. Okay. All right, thanks for coming to my talk. My name is Stephan Noel, and today I'd like to talk to you about burning down data walls in the US fire service and beyond. So just a bit of overview. So first a bit about UL, the company behind the Fire Safety Research Institute. Then what is NERIS and what problems we were trying to solve, and then the fire software landscape, and then some opportunities for atproto. Okay, I'm a senior front-end engineer at the Fire Safety Research Institute. These are just my handles and tech that I'm interested in.
And you can usually find me in South Florida or a bit sometimes in Costa Rica or Portugal. So UL, you usually can you might recognize our logos or maybe not if you squint hard enough on your smoke alarm, your circuit breaker, and if you take out your laptop charger, you'll probably find us on there as well. And the history, so the history of UL coincides with the uh the electrification of the US, and um basically in the ahead of the Chicago World Fair, um there were a lot of fires basically. And um our founder, uh William Henry Merrill noticed that it it was due to a lack of standards, and um above a firehouse in downtown Chicago, UL was founded.
So this is just to give you a sense of the scale of uh fire in the US. There are over 30,000 fire departments, and they have all different ways to do things. And around 19,000 are completely volunteer, and then around 3,000 are completely career, so they get uh salaried, and then the rest are a combination of um yeah, basically salaried and and volunteers. And FGNY is the largest in the US, and uh yeah, the the scale ranges from extremely large to extremely small. Sometimes it's just whoever shows up for the day. And there are 36 around 36 million calls for fire service per year, but 65% of those calls that firefighters respond to are medical in nature.
So I'll just uh run you through the life of a fire incident and the kind of software uh usually involved in that. So step one is the fire occurs, you become aware of it. Then you then you run, then you call 911. Then you uh that that call to 911 is actually communicating with somebody at what's called a public service answering point. Uh a PSAP uh is how they the acronym is. And so this is where the CAD software comes in. This is a computer aided dispatch. And then they're the ones who dispatch uh the fire truck.
Their goal is to arrive there in within six minutes because when it comes to fire, every every second counts. And then the firefighters arrive on scene. And then they fill out the details about what happened on the fire report. So firefighters aren't really excited about filling out the report, but that data is really useful. And we use it in order to inform our research, try to improve response times, and yeah, it's not it's not it's not data for profit, it's for research. So that last step of that's what's called a record management system, an RMS. And before NERIS there was N First.
So what would happen is the the fire software that they would use would basically take whatever they entered in plain text and they would submit it to an FTP server. And then one to two years later, around the time by which which it's no longer useful at all, then they can finally get that data out. And the major problem was that the data standard hadn't updated since 2014. So all of these different software providers would have they would be stuffing data into this one field where they can put in whatever they they wanted and basically there was no data portability because of that.
So then NERIS comes in and we make the schema more flexible to try to prevent that kind of vendor locking. In addition, we also provide this uh a free RMS in order for them to enter their data. And we also provide um the like essential analytics for them out, and all of this is provided uh for free. And in and it's also we provide a REST API, not an FTB server. Um we we will also be providing uh NERES public, which will also provide aggregate data. Um that will be available uh uh you won't need authentication in order to get to that.
So did we solve everything was all we needed to reverse time back to the open API days and just have a separate entity in in charge of that API. Well the fire service software needs go beyond just incident data. It includes pre-planning for how you would um plan your response to a fire, access points, just structure, inspections for fire code violations, permit management, um, personnel management to manage the training of firefighters, uh staffing and scheduling, because firefighters usually they work 48 hours in a row and trade shifts all the time, and you'd have to manage your fire trucks and and fire hoses and yeah uh medication as well.
So there's a lot of software that firefighters need, but the thing is they they want only one invoice um one bill at the end because request for proposal is difficult, especially in the larger fire departments. So what happened is they wanted to they they had one fire software that was really good at one thing, and then these companies, in order to provide what firefighters wanted, became mediocre in a lot of things. They in order to implement these other features, they had to well try to implement it themselves, but usually would aggressively acquire in order to do so to become a kind of everything app for fire.
And those departments who only wanted some of the features would now have to pay for all of them. And what fire departments really wanted was just one bill and software that did a lot of things. And this has led to one tool to rule them all, and that has led to just a few companies ruling them all. And so now about 60% of the market share is owned by four companies. And it's often driven by medical reporting needs, as you saw that 65% um of the calls are medical in nature. So this is kind of related to what what Rudy mentioned before.
Um, but people don't want more and more apps, but also the the billing experience um is is important here as well. And when it comes to fire trucks, the the situation is even even more dire, and the price hikes that resulted is is even worse. And fire isn't just the US problem, it's global, and we want to connect to and work with um international communities. And the EU is actually uh recently started uh FireStat and Canada has uh also expressed interest in something similar of a uh reporting at a national level. And yeah, to understand the fire problem, we would we will need global standards.
And what if we can go beyond incidence and also include all the data from fire all the different fire software that that firefighters uh use. I think atproto has a a lot of potential here. And if if you have ideas on on how to push safety science, fire fire science and safety science forward. So if if you would like to get started on in fire software, one one way would be to integrate with uh NERIS. Um this top link here is is the link that will show you all the steps. You create some geo tickets and we'll set you up with a dedicated department.
And this below the link below is the the link to our API docs. And just some final thoughts. The transition to NERS just happened January of this year. And the moat is lower than ever. We're seeing two-person startups making real headway and word of mouth spreads fast in the fire service. And I would love to see atproto enter this this space as well. You don't need fire knowledge to build um or NERIS. Uh second, uh just the open question again. Um interop gives us a lot more user choice, but can we have um uh a better billing experience as well.
Um and then finally um the the fire space, who who would have thought it's it would be uh uh dominated by by four VC funded companies as well. And you've you've heard it before, uh product drive protocols, and I'd love to see us drive atproto forward with fire software. Thank you. That was great. So you you actually uh you pitched civic tech global standards and then you snuck in um an atproto wallet in the side of things as well. Did I hear that? Yeah, you did. That was amazing. Yeah, thank you very much.