Remote Patient Vitals Patch
US-based digital-health / remote-patient-monitoring startupA wearable medical patch continuously captures patient vital signs and securely transmits physiological data for remote monitoring, giving care teams a continuous view of patient status rather than relying only on intermittent manual measurements.
Where AI accelerated vs. where our engineers led.
Every project follows the same Rivix Split — AI drafts the mechanical work, a named engineer reviews and owns every decision that touches safety, cost, or a regulatory limit.
Where AI accelerated
- Firmware scaffolding & sensor-driver implementation
- BLE connectivity implementation
- Signal-processing code
- Backend APIs & service boilerplate
- Test-case generation & documentation
Where our engineers led
- Medical/product requirements
- Hardware architecture & sensor selection
- Power architecture
- Safety-critical behavior
- Validation, verification & final code review
Technical deep-dive
Additional detail on architecture, stack and implementation specifics for this engagement.
Architecture & stack
The patch runs on a low-power, Cortex-M-class microcontroller paired with an analog front-end for capturing physiological signals (ECG/PPG-class sensing), with firmware structured around an RTOS to manage sampling, buffering and radio scheduling within a tight power envelope. A BLE radio handles the device-to-phone hop; a companion mobile app relays data over standard REST/HTTPS to a cloud ingestion service.
- Cortex-M-class MCU + analog front-end for ECG/PPG-class sensing
- RTOS-based task scheduler separating sampling, radio and power-state duties
- BLE 5.x link to a companion app; REST/HTTPS device-to-cloud pipeline
Connectivity & data pipeline
Sensor data is sampled continuously, filtered and windowed on-device to reduce the volume that needs to cross the radio link, then streamed over BLE in periodic batches to tolerate connection drops. On the backend, a device-to-cloud pipeline validates, timestamps and persists readings, exposing them through APIs consumed by the care-team-facing application.
- On-device filtering & windowing before any radio transmission
- Periodic batch upload over BLE, sized to tolerate multi-minute connection gaps
- Backend validates, timestamps and persists each reading before it's queryable via API
Key engineering challenges
The core tension was continuous multi-day wear against a small battery budget: every sampling-rate, filtering and radio-duty-cycle decision traded signal fidelity against power draw. Motion artifact rejection and reliable skin-contact sensing under real-world conditions (sweat, movement, adhesive wear) were the other major axis of engineering effort, alongside designing for graceful reconnection when BLE links drop.
- Balancing sampling rate and filter complexity against a multi-day battery budget
- Motion-artifact rejection under sweat, movement and adhesive wear
- Deterministic reconnection/resync logic after BLE link drops
Why this approach
An RTOS-based firmware architecture with aggressive duty-cycling was chosen over a bare-metal loop to make power-state management and sensor scheduling explicit and testable, which mattered given the multi-day continuous-wear requirement and the safety expectations around a medical monitoring device.
- RTOS chosen over bare-metal loop for explicit, testable power-state management
- Duty-cycled radio use over always-on streaming to protect battery life
- On-device pre-processing kept the safety-relevant logic auditable and unit-testable