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.
Reliability & constraints · how the system behaves when things go wrong
production guaranteesIntermittent connectivity
Scans queue locally on the device when Wi-Fi or cellular drops; the registry reconciles the queued events in arrival order once the link is restored.
Scan validation
Every scan is checked against the current state machine. Invalid transitions (e.g. Cleaning → In Use without an Available step) are rejected at the edge and logged.
State reconciliation
When two scans collide — a delayed offline event arriving after a newer one — the registry applies a deterministic last-writer-wins-by-timestamp rule and surfaces the conflict for review.
Audit logging
Every state transition writes an append-only audit row with actor, site, timestamp, and prior state. The audit log is never edited — corrections are written as new compensating events.
Duplicate-scan prevention
Repeated scans of the same asset within a short debounce window resolve to a single transition; duplicates are recorded but do not double-count or re-fire downstream flags.
Operational fallback workflow
When the registry is unreachable, ward staff fall back to a paper handoff sheet keyed by asset ID; coordinators reconcile entries on the next available shift without losing chain-of-custody.
These behaviours are not edge cases — they are the daily reality of running an asset registry across four sites with mixed network conditions and shift-based staff turnover.
03 · Roles & responsibilities
Six roles, one shared record.
Each role uses the system through a surface shaped to the work they do — and writes back to the same registry. Coordination is a side-effect of doing the job, not a separate task.
Transport Aide
Patient transport across units and between sites
- Scans
- DispatchArrivalReturn
- Surface
- Mobile scan view — one tap per leg of the trip
- Decision it enables
- Knows which chair to take next and where the closest available one is staged.
Unit Clerk
Coordinates equipment requests and unit-level availability
- Scans
- RequestReceiveRelease
- Surface
- Unit board — current par, inbound transfers, pending requests
- Decision it enables
- Stops chasing equipment by phone — sees what is on the way and what is overdue.
Ward Nurse
Patient-side equipment use during care
- Scans
- Assign to patientRelease at discharge
- Surface
- Bedside scan — single action tied to the patient encounter
- Decision it enables
- Hands off equipment cleanly at end of shift with no paper handoff sheet.
Equipment Coordinator
Per-site cleaning, inspection, and lifecycle flow
- Scans
- ReturnedCleaningInspectionAvailable
- Surface
- Site board — queue by state, age-in-state, threshold flags
- Decision it enables
- Works the queue in priority order rather than rediscovering it each shift.
Operations Lead
Network-wide utilization and inter-site coordination
- Scans
- Audit only — no manual scans
- Surface
- Operations cockpit — site availability, par variance, transfer suggestions
- Decision it enables
- Approves cross-site transfers before a shortage becomes a delayed discharge.
Biomedical Engineering
Preventive maintenance and asset retirement
- Scans
- Maintenance inMaintenance outRetired
- Surface
- Service queue — assets flagged by threshold or anomaly, with full custody history
- Decision it enables
- Plans the day from a flagged queue, not a clipboard walkthrough.
Why surfaces, not screens
Every role sees a different view of the same registry. A Transport Aide on a mobile scan view and an Operations Lead in the cockpit are reading the same row of data, shaped to the decision they need to make. That is the difference between a tracking app and a tracking system: the data model is shared, the surfaces are not.
04 · 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.
05 · Operational surfaces
What operations actually sees.
Three of the working surfaces that read from the registry. Designed for shift speed and alert response — not for screenshots — so they are dense, status-led, and quiet about anything that is fine.
Site availability board · operations cockpit
| Site | Unit | Par | Avail. | In use | Cleaning | Maint. | Status |
|---|---|---|---|---|---|---|---|
| Site A | ER | 32 | 11 | 14 | 4 | 3 | Within par |
| Site A | Imaging | 18 | 7 | 9 | 2 | 0 | Within par |
| Site B | ER | 28 | 4 | 18 | 5 | 1 | −7 below par · 14 min |
| Site B | Med-Surg | 36 | 12 | 19 | 4 | 1 | Within par |
| Site C | ER | 24 | 8 | 12 | 3 | 1 | Within par |
| Site C | Discharge | 14 | 2 | 9 | 2 | 1 | −4 below par · 22 min |
| Site D | ER | 30 | 14 | 12 | 3 | 1 | Within par |
| Site D | Med-Surg | 34 | 18 | 13 | 2 | 1 | Within par |
Asset detail · WC-2207 · full custody history
Wheelchair · Adult standard
WC-2207
Site B · ER · floor 3 · bay 04
- Acquired
- 14 Mar 2023
- Cycles since clean
- 0
- Cycles this week
- 23
- Last inspection
- Tue 12 May · passed
- Next inspection due
- Wed 12 Aug · 91d
- Open service tickets
- None
- Custody (current)
- EQC · Site B
Cleaning threshold approaching
Will auto-flag at cycle 10 (current: 8). Coordinator can pull early or wait for the next return.
Custody history · scan-sourced · append-only
7 events shown · full log in audit- 14:02Scan · Returned·EQC · Site BIn UseReturned
Returned from ER · floor 3
- 13:40Scan · In Use·TPT · 04127AvailableIn Use
Dispatch · ER → Imaging
- 13:18Cycle complete·EQC · Site BCleaningAvailable
Cycle 8 / 10 to inspection
- 12:55Scan · Cleaning·EQC · Site BReturnedCleaning
- 12:34Scan · Returned·TPT · 04088In UseReturned
Returned from Med-Surg
- 11:02Tue 12 MayInspection passed·BME · Site BInspectionAvailable
Annual safety check
- 09:45Tue 12 MayMaintenance out·BME · Site BMaintenanceInspection
Brake pad replaced · ticket #BME-3128
Service queue · open tickets & transfer suggestions
Cycle 10 · cleaning flag
Site A · EQC
Cycle 11 · cleaning flag
Site A · EQC
Inspection due in 3d
Site B · BME
Brake anomaly · 2 sensor events
Site C · BME
Returned · awaiting cycle
Site D · EQC
Surfaces shown are representative renderings of the production console. Asset IDs, ticket numbers, and timestamps are illustrative.
06 · 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
Representative operational outcomes
informed by deployment observationsTypical equipment search time reduced from several minutes to under 30 seconds.
Operational visibility improved through scan-sourced state tracking — every asset has a current state, a location, and a known custodian.
Cross-site transfer recommendations surfaced through par-level monitoring, reducing reliance on phone-tree coordination during shortages.
Full audit trail created for every scan-triggered state transition, supporting incident review, lifecycle audits, and accreditation evidence.
Cleaning and inspection cycles caught by threshold flags rather than by ad-hoc inspection, reducing missed-cycle incidents reported by ward staff.
Per-site utilization became measurable for the first time, giving operations a baseline for par-level tuning and shift planning.
Outcomes are described qualitatively. Specific numerical figures are not published in this case study — they vary by site and shift, and accurate ranges depend on internal operational data we treat as confidential.
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.
07 · Phased rollout
What we shipped, what broke, and what changed.
Real deployments are not big bangs — they are small bets, observed honestly, and corrected. The phases below are the actual shape of how this system grew across the network, including the parts that did not work the first time.
Phase 00 — Site A · prove the gesture
Pilot · single site
One site, one workflow (return → cleaning → available), one primary role (Equipment Coordinator) on a mobile scan view. Goal: prove that one scan can replace the radio call.
Shipped
- Core scan-to-state model and append-only registry.
- Mobile scan surface for the Equipment Coordinator role.
- Single-site availability dashboard for the EQC supervisor.
What broke
- Paper handoff sheets persisted in parallel for several weeks — staff did not yet trust the new record.
- Basement and ambulance-bay Wi-Fi was intermittent; scans completed on-screen but never reached the registry.
What changed
- Added an on-device offline queue with deterministic retry once connectivity returned.
- Ran a two-week "shadow" period where paper and registry ran in parallel before formally retiring paper.
Phase 01 — Sites B & C · separate the namespaces
Multi-site · two sites added
Two more hospitals onto the same registry, two more roles (Transport Aide, Ward Nurse) with their own surfaces. Goal: prove the data model holds when more than one site writes to it.
Shipped
- Site-scoped surfaces for Transport Aide and Ward Nurse.
- Site-prefixed asset identifiers across the registry.
- Inter-site transfer logging (manual approval only at this stage).
What broke
- Two sites had assets numbered identically before the rollout — scans resolved to the wrong record until prefixes propagated.
- During shift handover, the same asset was sometimes scanned twice within seconds, creating phantom state churn in the audit log.
What changed
- Migrated all asset IDs to site-prefixed format and reissued QR labels before activating writes at Site C.
- Added a short debounce window on scan events; duplicate scans inside the window resolve to a single transition with a marker in the audit row.
Phase 02 — Site D · par-level monitoring goes live
Network complete · all four sites
All four sites writing to one registry, with par-level monitoring and transfer suggestions surfaced to operations. Goal: move from passive tracking to active rebalancing.
Shipped
- Par-level monitoring per unit, with site-level rollups.
- Automated transfer suggestions when units sustained below-par availability.
- Audit-trail completeness rules — every state change must be scan-sourced or a written compensating event.
What broke
- Par-level alerts fired on every short demand swing; operations staff began muting the channel.
- Some transfer suggestions made operational sense on paper but ignored shuttle-schedule reality, so they sat unactioned.
What changed
- Tuned variance thresholds per unit and time-of-day; alerts only fire after a sustained dip rather than a single sample.
- Added shuttle-schedule context to transfer suggestions so the suggested ETA reflects the next physical movement, not a theoretical best case.
Phase 03 — Network-wide visibility & biomedical surface
Operations cockpit
Centralized operations cockpit for the Operations Lead and a dedicated service queue for Biomedical Engineering. Goal: every alert has a clear owner and a clear action.
Shipped
- Operations cockpit with site availability, par variance, and transfer approval workflow.
- Biomedical Engineering surface — service queue with custody history and threshold-driven inspection scheduling.
- Per-alert ownership and acknowledgement model.
What broke
- The first cockpit shipped as a "wall of information" — alerts were visible but the next action was not obvious, so items sat unactioned.
- Service tickets opened automatically by threshold sometimes duplicated tickets created manually by BME staff.
What changed
- Every alert in the cockpit now carries a one-tap action (approve / dismiss / escalate) and a named owner role.
- Service-ticket creation is idempotent against an open ticket for the same asset and reason; existing tickets gain a new note instead of a new row.
Operating principle
The system shipped in pieces because trust is built in pieces. Each phase added one site or one role, the team watched what actually happened, and the next phase changed something concrete in response. There is no version of this rollout that succeeds without the “what broke” column being honest.
Phasing is presented at a level appropriate for public discussion. Internal incident reports and operational metrics are not included.
08 · 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.