Multi-Site Wheelchair
Tracking System
Real-time visibility and chain-of-custody for 800+ wheelchairs and clinical assets across four hospital sites — built on QR scan workflows and a shared state model.
- Role
- Systems design & build
- Sites
- 4 hospitals
- Scale
- 800+ assets
- Status
- In production
01 · The problem
An empty wheelchair was an open question.
Thousands of patient moves a week relied on equipment no system could locate. Four sites, four ways of knowing — and none of them shared.
Before · fragmented coordination
No connecting line — because there wasn't one. The dotted gaps are radio calls, sticky notes, and best guesses.
No shared visibility
Each site tracked its own equipment its own way — nothing read across the network.
Manual coordination
Finding a chair meant a radio call and a walk through the floor.
Inconsistent state
Cleaned? Inspected? Overdue? The log was paper — and often stale.
Slow, low accountability
Turnaround dragged, and there was no record of who had what, when.
Pre-system state · representative.
02 · Solution architecture
One scan. One source of truth.
Pick the gesture first. A scan resolves to a transition, the registry records it, and every other surface reads downstream from that one event.
The spine
QR Scan
one input
Workflow Orchestration
resolve transition
State Machine
what’s allowed
Operational Registry
source of truth
Equipment isn’t inventory — it’s a lifecycle
States are how a system gets memory — and how it knows what’s overdue.
QR scan layer
Every asset carries a code. One scan is the only input the system needs.
Workflow orchestration
The scan resolves to a state transition; rules decide what’s valid from here.
Operational registry
One record per asset — current state, location, and full custody history.
Multi-site coordination
One shared registry, role-shaped surfaces per site and for operations.
03 · Operational workflow
Watch a scan move the whole system.
One gesture, four effects. Step through it — or let it run.
The gesture
WC-2207
Site B · floor 3
Registry record
WC-2207
In Use13:40 · in use · transport, floor 3
Reads downstream
1. Scan QR — A coordinator scans the chair on return — the only input the system needs.
Interactive prototype · representative state model.
04 · Operational impact
Less hunting. More moving.
The point was never a dashboard. It was equipment in the right place, a clean record of every move, and a coordinator who can stop guessing.
800+
assets under one registry
4 sites
one shared state model
Every move
logged — full chain of custody
Before → after
Locate a chair
radio call, walk the floor
scan-to-locate, any site
Asset state
paper logs, often stale
live, per-asset, with history
Maintenance
sticky notes, easy to miss
auto-flagged on state thresholds
Accountability
who had it? unclear
chain-of-custody on every scan
Utilization visibility · per site · last 6 weeks
representativeUtilization was invisible before — now it's a line on a chart, per site and per shift.
Operational figures are representative; the system runs in production across sites.
05 · Where this goes
The registry becomes the training set.
Every scan is already a labelled event. Over time that’s a clean operational dataset — and a foundation for intelligence that stays grounded in what the system actually records.
Predictive maintenance
Usage and state history flag the assets most likely to need service — before they fail mid-transport.
Utilization forecasting
Anticipate demand spikes by site and shift, and pre-position equipment instead of chasing it.
Operational copilot
Ask the registry in plain language — “where are Site C’s idle chairs?” — grounded in real records.
AI-assisted logistics
Suggest transfers between sites before a shortage becomes a delayed discharge.
Roadmap — no model where a rule will do.
Want the architecture walkthrough?
Happy to talk through the state model, the multi-site sync, and what phase two looks like.