What is Second Due?

Second Due is a piece of software I created for Caroline County Firefighter/EMTs that gives helpful information we can reference en route to a call such as nearest water sources, nearest helicopter landing locations, and routing directions to call. It was created in response to the fact that current solutions such as First Due, Active 911, and Fire Mobile are lacking features that I believe providers would find useful. This program is not affiliated with or endorsed by Caroline County Fire Rescue.

How is Second Due better than First Due?

• Automatically list nearest water sources - Not automatically listing nearest hydrants / draft sites is the biggest drawback of First Due and is why I will never break out First Due over a mapbook on the way to a fire. First Due automatically lists the nearest hydrants and draft sites.
• Accurate hydrant locations - As of today, First Due's hydrant locations are inaccurate. I have cross-referenced the hydrant locations from First Due with 2 sets of mali books am in the process of verifying the location of every hydrant with Google Street View or in person.
• Best routes to hospitals and estimated ETAs - At times I have been caught off gaurd by traffic or blockages on I-95 or 301. By listing the travel times and fastest routes (taking traffic into account) to the nearest hospitals, providers can reference them while en route to a call so the driver will know which route to take without having to manually calculate the times to each hospital with their phone.
• Never miss a call - Due to an issue with address recognition, First Due doesn't list all calls. Since Active911 does not appear to have this problem, Second Due downloads calls from Active911 and First Due (in the unlikely event that Active911 doesn't register a call while First Due does).
• Type messages to other units on the same call - Radio traffic is frequently garbled and hard to understand, making miscommunication possible. By being able to type out messages to all the units responding to a call, communication is clear and easy to reference.
• Time-to-hospital exceeds stroke / STEMI guidelines - First Due will automatically alert while en route and while en scene if the estimated time to get the patient to an appropriate hospital exceeds the recommended time for a stroke or STEMI and if a helicopter should be considered. In addition, First Due will propose different rendevous points that are between the scene and a hospital and have a large enough area for a landing zone.
• Notes for incoming units - Units being able to write notes or directions to other incoming units while en route to a call will helli avoid confusion through garbled radio transmissions and will be easily referenceable.
• Bad dispatch alert - By default, Second Due will sound an alert if a unit is mistakenly dispatched your first due. There is also an option to sound an alert if you are closer to a call as determined by your own GPS. Most of the time these mistakes are caught by one of the units, however, it is nice to have a backuli system.
• Search hospitals by specialties - While all providers know the common specialties our approved hospitals offer, rarer ones are not common knowledge. For instance, did you know that VCU is the only approved hospital that can handle dental injuries?
• List estimated arrival times of incoming units - Second Due lists the estimated arrival times and order of incoming units. This can be useful for the first arriving engine or batallion to know what tasks to assign incoming units.
• List hospital wait times - Second Due lists estimated wait times for Richmond hospitals based on how long Richmond Ambulance Authority's units are waiting at different hospitals

How does Second Due work?

Front End - JavaScript

Second Due performs most of its functions on the frontend through client-side JavaScript and makes heavy use of the Google Maps API. In the past when I'd write JavaScript, I'd use janky workarounds to avoid asynchronous functions because I didn't want to learn how to use them. After writing JavaScript "the right way", lots of asynchonous functions with promises and callbacks and all that, I found that not only is it better code but it's easier to write and read once you understand it.

Front End - Google Maps API

The Google Maps API proved incredibly useful with this project and had every single feature you could think of already built into it. Need to calculate the time, distance, and major roadways reccomended to take for 10 different routes from one location to many and list them in an array? Google Maps API has already gotchu with minimal work required on your end. Need to display custom county lines and lines subdividing a county? Google Maps API has got your back. Need to be able to search for places with an autocomleting search bar. Don't sweat it with Google Maps API.

Back End - NodeJS Server

I run a NodeJS Server that scrapes data for call information and hospital wait times. The NodeJS server uses websockets to connect with the client side JavaScript and send updates when a call comes out or a hospital wait time changes. Like my client-side JavaScript, I was tempted to be lazy and forgo the asynchronous websockets to transfer data between the client-side JavaScript and my NodeJS server and do some hacky thing where the client-side JavaScript fetches a file hosted on my server every minute and my NodeJS updates that file every minute. I decided to do the right thing and learn websockets, which results in less unnecessary traffic (traffic is only sent when my NodeJS server detects a new call or a change in hospital wait times) and is more elegant.

Back End - PHP and MySQL Server

Even though all dispatch information is broadcasted over public radio, which means anybody can listen to it (even people halfway across the world can listen to our traffic because someone is running an online repeater in Caroline County that lets anyone listen to fire rescue radio traffic in Caroline online), I don't want to be responsible for further sharing that information. To ensure only Caroline County employees can access the call data, I created a user login system that only issues accounts to people with a Caroline County government email and who I have confirmed that they themselves made this account. It has all the security features expected of a login system (that are weirdly missing on even some large websites) such as hashing and salting passwords with the latest algorithms, HTTPS, and anti-brute force detection.

Back End - DigitalOcean Hosting

This whole shebang is hosted on a DigitalOcean server. After running websites off of home servers for 4 years, I'm tired of the headache of involved. This headache includes having to set up auto-updating DNS because I can't get a static IP for my house, hardware breaking down, not being able to scale if your server gets a spike of traffic, and having a computer in your house you always have to have turned on. The price of the DigitalOcean server is 100% worth not having to fix problems totally unrelated to the purpose of my website.