A firefighter arrives at a structure fire. An EMT treats a patient on scene. Within hours — sometimes minutes — they need to document everything: the incident, the scene, the patients, the actions taken, the resources deployed.
Federal reporting standards dictate exactly what data must be collected, in what format, and how it relates to other data points.
Emergent was building an iOS application to make that documentation faster and easier.
The app already existed in a basic form — originally a side project built by developers, now being rebuilt as a full product with a dedicated team.
But two federal compliance standards were about to reshape everything the app needed to collect: the National Emergency Response Information System (NERIS) for fire service reporting and the National Emergency Medical Services Information System (NEMSIS) for EMS and patient data.
As I researched the regulatory requirements for NERIS and NEMSIS, it became clear that the problem wasn't at the field level — it was structural.
The application's navigation and information architecture had no place for much of the data these standards required.
Patient data, for example, was treated as a separate entity — slightly disconnected from the incident it belonged to.
But in reality, every patient encounter happens within an incident. The incident is the envelope. Everything that happens on scene — every patient, every action, every resource — needs to live inside that envelope and stay connected to it.
NEMSIS also introduced HIPAA requirements for patient data.
NERIS had its own set of data structures, packaging formats, and reporting rules.
The two standards overlapped in places and diverged in others. And the current app wasn't built to accommodate either one.
This was a startup. Timelines were compressed, the team was small, and development was already underway on other features.
I couldn't pause everything for a months-long architecture overhaul. And there was no guarantee my recommendations would be implemented before priorities shifted — which, at a startup, priorities can frequently change.
I also had to account for being new to the team — building credibility quickly while making the case for significant structural changes.
After 
Before Rather than waiting until the regulatory data work was complete and then presenting a finished recommendation, I recognized that the structural implications were urgent enough to escalate immediately.
The development team needed to know now that their current architecture couldn't hold what was coming — not after I'd finished cataloging every data field.
I separated the infrastructure problem from the data problem.
I brought the structural concerns to the design team first, then pitched the recommended reorganization to stakeholders.
They asked me to go back with the design team and refine the proposal. We whiteboarded the changes together and I presented the refined recommendations — essentially saying: here are structural changes you can make now that will allow you to simply plug in the regulatory data work the moment it's ready.
That framing mattered. I wasn't asking them to stop what they were doing. I was showing them how to prepare for what was coming so it wouldn't disrupt their existing work when it arrived.
The data requirements for NERIS and NEMSIS are extraordinarily detailed. Each standard specifies required and optional fields, input types, nesting hierarchies, value sets, nullability rules, and packaging constraints.
NERIS uses Swagger UI — confirmed as the authoritative source through direct contact with the Director of Research at Fire Safety Research Institute (FSRI) — served as the primary reference.
But Swagger UI isn't designed for cross-referencing, filtering, or connecting elements to an existing application's data structures.
I built the analysis in Airtable, capturing metadata for each API element — requirement level, input type, nullability, payload constraints, value sets, nesting depth, and source notes.
This allowed me to do what Swagger UI alone couldn't:
Dispatch data, for example, overlapped significantly between NERIS and NEMSIS — but with critical differences in format and packaging that needed resolution before implementation.
The core of my recommendation addressed how the application organized information around an incident.
In public safety, when first responders arrive on scene, the incident is the primary unit of work. Everything flows from it.
For a small call — a single EMT, one patient — the incident details need to be minimal so the responder can focus on the patient.
For a large-scale incident — multiple patients, multiple units — situational data is gathered by different people on scene, and EMTs need to focus solely on their assigned patients without navigating broader scene management.
The app needed to support both scenarios with the same underlying structure. My recommendation reorganized the navigation so that:
I worked with the design team through whiteboarding sessions to refine these changes, ensuring they were feasible within the existing technical architecture while still addressing the regulatory requirements.
I recommended a complete redesign of the application — and others on the team shared that view.
But I also recognized that a full redesign wasn't going to happen on a startup timeline.
Instead, I focused on the structural changes that would enable a future redesign while solving the immediate compliance problem.
The structural reorganization was a stop-gap that served double duty: it met the regulatory needs and laid a better foundation for whatever came next.
From the start, my goal was to ensure the app could meet federal reporting requirements without adding friction for the people using it.
First responders need to capture incident data quickly and get back to helping people — every extra tap, every confusing navigation path, every unnecessary screen is time taken away from someone in an emergency situation.
Compliance had to be built into the structure, not bolted on top of it in ways that would slow the experience down.
I was let go in a 30% reduction in force (RIF) before the recommendations were fully implemented — a reality of startup work where priorities and budgets shift without warning. I don't know how the application evolved after my departure.
What I do know is that the work itself was sound. The regulatory mapping was thorough, the structural diagnosis was accurate, and the reorganization I recommended was designed to be implemented incrementally without disrupting ongoing development.
If I were to do this engagement again, I would have pushed harder to document the structural recommendations in a formal deliverable earlier. At a startup, institutional knowledge walks out the door when people do.
The whiteboarding sessions and presentations were effective for alignment, but a comprehensive written reference would have ensured the thinking survived regardless of team changes.▪️
All work © Jayna Bergerson unless otherwise noted.
