AI triage prototype system

Atlas

I built the connected prototype layer for Atlas: first-responder mobile, incident-command iPad, ER intake, and the local server that kept patient state moving across the demo.

ownership
Digital Prototype Engineer - apps and real-time system
timeframe
Capstone, 2026
stack
SwiftUI, TypeScript, WebSocket, Mapbox
proof
Prototype case study
outcome
207 server tests passing
Atlas

decision

Connected FR mobile, incident-command iPad, and ER intake prototypes for a mass-casualty triage demo.

build path

Structured the first monochrome pass -> translated final flows into native app prototypes -> built the local TypeScript/WebSocket server for live patient-state sync.

scope

FR mobile, IC iPad, ER intakeApp surfaces

3 iOS targets, 134 Swift filesNative code proof

7.1k-line TypeScript REST/WebSocket serverServer proof

47-patient mock incident streamSimulation proof

outcome proof

207 server tests passingValidation

Final visual system and hardware were team-ownedRole boundary

This page focuses on my digital prototype/build contribution.

A portfolio page about the working prototype, not the whole design story

My contribution

Atlas was a team capstone. I helped shape the first structural pass and a monochrome interface iteration, then focused on building the digital prototype system: the app surfaces, shared state, mock incident data, and live sync needed to make the concept demonstrable.

The build behind the screens

Prototype proof

3Native app targets

134Swift files

7.1kServer code lines

207Server tests passed

Four pieces made the prototype feel alive

Build scope

Responder-facing updatesFR mobile

A mobile surface for map context, patient lists, injury updates, and quick triage changes from the field.

Command and assignmentIC iPad

An incident-command surface for the operating map, patient assignment, quick-send instructions, and hospital capacity.

Receiving preparationER iPad

A hospital intake surface showing incoming patients, live vitals, injury locations, and status history.

Shared patient stateLocal server

A TypeScript REST/WebSocket server handled mock incident data and broadcast patient updates across the app surfaces.

The three apps I helped turn into a connected demo

Prototype surfaces

First-responder mobile map and patient context
First-responder mobile map and patient context
Incident-command quick-send and map coordination
Incident-command quick-send and map coordination
Emergency receiving intake detail and patient status
Emergency receiving intake detail and patient status

The prototype was built around a single shared incident state

System flow

Seed a live scenario01 / Mock incident

A local data layer could generate a 47-patient incident stream so the demo had enough movement to stress the experience.

Centralize patient, responder, and hospital updates02 / Server state

The TypeScript server kept one source of truth for patient status, locations, assignments, teams, and instructions.

Push changes to every surface03 / WebSocket broadcast

When a patient changed, the server broadcast state events so FR, IC, and ER screens could stay synchronized.

Render role-specific views04 / Native clients

Each SwiftUI target used the same shared models while showing only the slice of the incident that role needed.

The final visual direction came from Team Atlas. My implementation work translated that direction into prototype apps, shared components, and live system behavior.

What this page should claim

Credit boundary

Atlas should be read as a team capstone where my strongest contribution was making the digital prototype work across multiple app surfaces.

I am not claiming ownership of the final visual design or physical prototype. This page focuses on the structure, early monochrome pass, native prototypes, and real-time system I helped build.