I Spent 5 Years in NYC 9-1-1. The Software We Used Was Working Against Us
When I started working in the New York City 9-1-1 system, I expected the hardest part of the job to be the medicine. Cardiac arrests, trauma, pediatric emergencies — the clinical side of EMS is demanding and unforgiving. I trained for it. I was ready for it.
What I was not ready for was how much of my time, energy, and cognitive bandwidth would be consumed by the technology I was forced to use.
Over five years in one of the largest and most demanding EMS systems in the world — thousands of calls per day across five boroughs — I watched software fail the people who depended on it. Not occasionally. Routinely. And the consequences weren’t measured in inconvenience. They were measured in response times, documentation accuracy, patient outcomes, and crew burnout.
This isn’t an article about one bad platform or one specific vendor. It’s about a systemic problem in how technology is built for EMS — and what the field should be demanding instead.
The Dispatch Problem
The first place technology fails EMS providers is dispatch. I have watched crews sit available while calls stacked because the CAD system could not process assignments efficiently during high-volume periods. I have seen dispatch information arrive incomplete, inaccurate, or late — sending units to wrong addresses, missing critical details about scene safety, or failing to update responding crews when conditions changed.
In a system handling the call volume of New York City, even small delays compound. A dispatch lag of 30 to 60 seconds doesn’t sound like much until you multiply it across thousands of daily calls. At the system level, those seconds translate into measurable degradation of response times. At the patient level, they can mean the difference between intervention during a salvageable cardiac arrest and arrival after the window has closed.
The fundamental issue is that most dispatch platforms were designed around the needs of the system administrator, not the needs of the provider in the field. The interface prioritizes data collection and compliance reporting over speed and clarity of communication. When your primary user is a crew responding emergently, every extra click, every unnecessary screen, and every redundant data field is a design failure.
The Documentation Burden
If dispatch is where technology first fails providers, documentation is where it grinds them down.
Electronic patient care reporting was supposed to make documentation faster, more accurate, and more useful for quality improvement. In practice, most ePCR platforms achieve the opposite. They are slow. They are cluttered with fields that are irrelevant to many calls. They crash or lag on the mobile devices crews carry. And they are designed around billing and compliance requirements rather than clinical workflow.
I have watched paramedics spend more time completing an ePCR after a call than they spent on scene treating the patient. I have seen providers leave critical clinical details out of their documentation — not because they didn’t know the information, but because the software made it so tedious to enter that they triaged their own documentation under time pressure. When the next call is already waiting, something has to give. Too often, it’s the completeness of the patient record.
The downstream effects are significant. Incomplete documentation affects hospital handoff quality. It degrades the data available for quality improvement and research. It creates liability exposure for providers. And it contributes directly to the burnout and frustration that is driving experienced providers out of the field.
A well-designed ePCR should take less time to complete than writing a paper report. The fact that most providers would tell you the opposite is an indictment of how these tools are built.
The Records and Data Problem
Beyond individual patient encounters, EMS agencies depend on technology for records management, quality assurance, scheduling, inventory, and operational reporting. In practice, many agencies operate with records systems that don’t communicate with each other. CAD data lives in one system. Patient care records live in another. Hospital outcome data lives in a third. Each platform has its own login and its own data format.
The result is that agency leaders often cannot get a clear picture of their own operations without manually exporting data from multiple systems and reconciling it in spreadsheets. The computing power to integrate these systems exists. The vendors building these tools simply aren’t motivated to make interoperability easy because fragmentation keeps agencies locked into their ecosystem.
EMS leaders should be asking one question every time they evaluate technology: does this system make it easier or harder to see what is happening in our operation? If the answer is harder, the tool isn’t serving the mission.
Why This Keeps Happening
The pattern I observed across every technology platform I used in EMS was the same. The software was built by people who had never done the job. Not just people who were not paramedics or EMTs — people who had never spent time on a unit, never sat in a dispatch center during a surge, never watched a crew try to complete documentation while their radio was already assigning the next call.
This matters because EMS is an operational environment with constraints that are invisible from the outside. Providers use technology in the back of a moving ambulance, in poor lighting, wearing gloves, under time pressure, often while managing a deteriorating patient. They switch between tasks constantly. They are interrupted by radio traffic, patient needs, and scene hazards. They work 12- to 24-hour shifts and need tools that reduce cognitive load, not add to it.
When technology is designed without understanding these constraints, it creates friction at every interaction point. That friction isn’t just annoying. It’s operationally dangerous. Every second a provider spends fighting their software is a second they aren’t spending on patient assessment, scene awareness, or crew communication.
The vendors building EMS technology have a responsibility to understand the operational environment their products will be used in. That means spending time in the field. It means hiring people with EMS experience — not just as consultants, but as core members of product and engineering teams. It means testing products under realistic conditions, not just in a conference room demo.
What EMS Should Be Demanding
The current state of EMS technology isn’t inevitable. It’s the result of low expectations and misaligned incentives. Agencies accept tools that are barely functional because the alternatives seem equally bad. Vendors build to the minimum requirements of RFPs and compliance standards rather than to the actual needs of providers.
Changing this requires EMS leaders to raise the bar on what they demand from technology partners.
First, demand that technology reduce time on task, not increase it. If a new platform requires more clicks, more screens, or more time than the one it replaces, it has failed its primary design objective. Measure this. Hold vendors accountable to it.
Second, demand interoperability. Your CAD system, your ePCR, your records management, your scheduling platform, and your QA tools should communicate with each other without requiring manual data transfers. If a vendor cannot or will not integrate with the other systems you use, that is a disqualifying limitation.
Third, demand field testing. Ask vendors when their product team last rode along on a unit during a busy shift. Ask them whether their development process includes input from active EMS providers — not former providers who left the field a decade ago, but people who are currently doing the job. The answer will tell you everything about how seriously they take the operational environment.
Fourth, demand reliability. The system shouldn’t crash during peak volume. It shouldn’t lag on standard-issue devices. It shouldn’t lose data during transmission. These aren’ aspirational features. They are baseline requirements for any tool used in emergency operations.
Finally, demand that the people building your technology understand what is at stake. EMS software isn’t a productivity tool. It’s operational infrastructure that directly affects patient care, provider safety, and system performance. The people designing it should treat it with the same seriousness that providers bring to every call.
The Opportunity Ahead
The technology to solve these problems already exists. AI-assisted dispatch, intelligent documentation that reduces provider workload, real-time operational dashboards — all of this is technically achievable today. These capabilities are simply not being applied consistently to EMS technology.
It will only happen if the field demands it. If agencies continue to accept tools built by people who don’t understand the job, they will continue to get tools that work against the mission instead of supporting it.
I left the streets, but I did not leave the mission. The problems I watched technology create for providers in the NYC 9-1-1 system are the same problems agencies across the country face every day. Solving them starts with acknowledging that the current state of EMS technology is not good enough — and that the people building these tools owe the field something better.
About the Author
Mendel Rosenblum, NRP, is an active paramedic and firefighter in Cincinnati, Ohio. He spent five years working in the New York City 9-1-1 system.
