← Back to Proof of Work
Healthcare & MedTech

Remote Patient Vitals Patch

US-based digital-health / remote-patient-monitoring startup

A 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.

~33%Estimated AI-first engineering effort reduction
24/7Continuous vitals visibility vs. intermittent manual checks
5Engineering layers spanned
Layers we built
HardwareFirmwareCloudApplicationAI / Algorithms
The Ryvasys Split

Where AI accelerated vs. where our engineers led.

Every project follows the same Ryvasys 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
Engineering detail

Technical deep-dive

Additional detail on architecture, stack and implementation specifics for this engagement.

STACK

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
DATA

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
CHALLENGE

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
RATIONALE

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

Building something in this space? Let's scope it together.