Every architectural decision in CareVision was made to serve one goal: give caregivers fast, trustworthy context when a resident needs attention. Here is why we chose what we chose, and what we intentionally left out.
These six principles guided every decision from technology selection to scope boundaries. When two approaches seemed equally valid, we used these to break the tie.
Video analysis runs on-device. No frames are uploaded. No cloud ML. The phone does the thinking, and only structured events leave the device. Privacy is not a policy; it is how the system is built.
In a care setting, latency is not a performance metric. It is a safety metric. We optimized for time-to-first-frame and event-to-alert latency because seconds matter when a resident is at risk.
The backend orchestrates. It does not think. Intelligence lives on the device (Vision, state machine) and in the caregiver's hands (decision-making with live context). The server is a relay, not a brain.
This is a showcase, and we never pretend otherwise. In-memory storage, demo auth tokens, and simplified detection are all clearly documented. We prove the architecture works without faking production readiness.
Instead of building separate sensor and caregiver apps, we built one binary with a role picker. This makes the demo simpler, the codebase smaller, and the shared models guaranteed to stay in sync.
We started with the riskiest technical problems: real-time video latency, on-device CV accuracy, and SSE delivery speed. Polish and persistence come after the core loop is proven.
Each of these decisions had alternatives. We chose the option that best served the demo goal while staying architecturally honest about what a production system would need.
We need sub-second latency. HLS cannot deliver that.
Privacy and latency both demand local processing.
Alerts flow one direction. Use the simpler protocol.
Camera, Vision, and WebRTC all demand platform-level control.
In a production app, React Native could own the standard product screens (settings, history, profile) while native iOS handles the camera, Vision, and media-critical paths. This showcase demonstrates the native side specifically because that is where the hard engineering problems live.
This is a demo. Durability is a solved problem; we are proving the real-time loop.
A production system would use PostgreSQL (matching Inspiren's actual stack) with WAL-based replication for durability, plus Redis for the pub/sub fanout layer. The store interface is already abstracted behind a class, so swapping in a real database is a mechanical change, not an architectural one.
Every prototype involves trade-offs. We made them explicitly and documented the path to production for each one.
All alerts, timelines, and sessions are lost when the backend restarts. This is fine for a demo that runs for 10 minutes. Production would persist to PostgreSQL and recover state from the database on startup.
Alerts arrive only when the app is open and connected via SSE. A production system would use APNs for background delivery so caregivers are notified even when the app is not in the foreground.
Bearer tokens are issued without real identity verification. Production would use OAuth or SAML, integrate with facility identity providers, and enforce role-based access with proper session management.
The demo supports one room with one sensor and one caregiver. Production needs multi-room orchestration, sensor health monitoring, and alert routing based on assignments and proximity.
The bed-exit detector uses persistence windows (0.6-0.8s) and cooldown windows (8-10s) to reduce noise, but clinical-grade accuracy would require a trained ML model, not just pose heuristics.
The app requires network connectivity to function. In production, critical events would be queued locally with durable storage and synced when connectivity returns, following a local-first architecture.
These features are solvable problems with known solutions. We omitted them because they do not help prove the core thesis: that the real-time detection-to-response loop can work with low latency and good architecture.
Swap the in-memory store for PostgreSQL. The interface is already abstracted.
APNs integration for background alert delivery. Standard iOS capability.
OAuth/SAML with facility identity providers. Well-understood integration.
Clip recording and replay for post-incident review. LiveKit supports this natively.
Room registry, sensor health, caregiver assignment, and alert routing.
Encryption at rest, audit logging, access controls, BAA compliance. Important but orthogonal to the demo.