AI triage prototype system
Atlas
A connected digital prototype layer for mass-casualty triage: field response, incident command, hospital intake, and shared patient state.
The command surface shows the proof: patient locations, hospital capacity, quick-send instructions, and live sync in one operating map.
- role
- Digital Prototype Engineer - apps and real-time system
- proof
- Prototype case study
- result
- 207 server tests passing
decision
Connected FR mobile, incident-command iPad, and ER intake prototypes into one live mass-casualty triage demo.
proof
Shaped the first structure and monochrome pass -> translated final team flows into native app prototypes -> built the local TypeScript/WebSocket server for live patient-state sync.
result
207 server tests passing · Final visual system and hardware were team-owned
Atlas at a glance
One incident state across three app surfaces
The full team concept connected responders, command, hospital staff, and patient-worn tags. This page focuses on the digital layer I could prove in software: shared patient status, locations, assignments, and receiving context during a live demo.
Project context
Mass-casualty triage breaks when field, command, and hospital views fall out of sync
Paper tags and radio updates fragment quickly. Atlas proposed a shared system where patient information follows the patient from field response to command to ER intake.
4
Touchpoints in the full team concept
3
Digital app surfaces I helped prototype
Scope boundary
My proof is the connected software layer
Connected prototype behavior
I shaped the early structure, then built SwiftUI surfaces, shared models, mock incident data, and the TypeScript/WebSocket server.
Research, final visual system, and hardware
Stakeholder research, final visual direction, and physical triage-tag exploration were team-owned.
Prototype proof
Evidence that the system actually ran
3
Native app targets
134
Swift files
7.1k
Server code lines
207
Server tests passed
Digital handoff proof
Field update -> command view -> hospital queue
Connected prototype layer
Four pieces made the demo feel live
Responder-facing updates
Map context, patient lists, injury updates, and quick triage changes from the field.
Command and assignment
Operating map, patient assignment, quick-send instructions, and hospital capacity.
Receiving preparation
Incoming patients, live vitals, injury locations, and status history.
Shared patient state
A TypeScript REST/WebSocket server broadcast patient updates across surfaces.
Prototype surfaces
The three app surfaces I helped turn into a connected demo
System flow
Mock incident -> server state -> WebSocket sync -> native views
01
Mock incident
Seed a live scenario
A local data layer could generate a 47-patient incident stream so the demo had enough movement to stress the experience.
02
Server state
Centralize patient, responder, and hospital updates
The TypeScript server kept one source of truth for patient status, locations, assignments, teams, and instructions.
03
WebSocket broadcast
Push changes to every surface
When a patient changed, the server broadcast state events so FR, IC, and ER screens could stay synchronized.
04
Native clients
Render role-specific views
Each SwiftUI target used the same shared models while showing only the slice of the incident that role needed.
This is the strongest claim: I made the software layer move like one emergency-response system, while crediting the broader team-owned product work clearly.
What this page should claim clearly
Atlas should be read as a team capstone where my strongest contribution was making the digital prototype layer work across multiple app surfaces.
The final visual system, stakeholder research narrative, and physical tag prototype were team-owned. This page focuses on the structure, early monochrome pass, native app prototypes, and real-time system behavior I helped build.