How We Built Vlepis: A Smart Patient Monitoring System (And What It Taught Us About Hardware)

We’re DigitalMonk, a hardware development agency. Most of our days are spent wrestling with PCB layouts in KiCad or debugging BLE connections on an nRF52. But recently, we took on a project that felt a little different.

A healthcare startup came to us with a problem. They had a great idea for a patient monitoring app, but they were stuck in the "idea" phase. They had a Figma mockup and a lot of ambition, but no firmware, no hardware, and no idea how to bridge the gap between a mobile app and a physical device.

They needed a prototype. Fast.

Here’s how we took Vlepis from a concept to a working system that monitors patient vitals in real time, and why we ended up relying heavily on Raspberry Pi developers to make it happen.

The Problem: Too Much Data, Not Enough Context

The client’s vision was clear: build a system that tracks a patient’s heart rate, oxygen saturation (SpO2), and body temperature, then pushes that data to a dashboard for nurses and doctors.

The catch? Hospitals are noisy environments—both physically and digitally. You can’t just slap a sensor on a patient and hope the data is accurate. You need to filter out motion artifacts, handle intermittent connectivity, and ensure the data pipeline doesn’t break when the Wi-Fi drops.

The client initially thought they just needed a mobile app. We quickly explained that the app is the easy part. The hard part is the hardware.

Our Approach: Modular Hardware, Smart Firmware

We didn’t want to build a custom PCB from scratch on day one. That’s expensive and slow. Instead, we took a modular approach.

For the sensor suite, we used off-the-shelf medical-grade breakout boards (Maxim MAX30102 for heart rate/SpO2 and a simple thermistor for temperature). This let us validate the concept without waiting for a custom board to arrive from a fab.

For the brain, we had a choice: go with a low-power MCU like the ESP32, or use a single-board computer.

We chose the ESP32 for the wearable sensor node. It’s cheap, has built-in Wi-Fi/Bluetooth, and runs Zephyr RTOS beautifully. The firmware handles the sensor polling, filtering, and local buffering of data. If the Wi-Fi goes down, the device stores 10 minutes of data locally and syncs when it reconnects. No data loss.

But here’s where the Raspberry Pi developers on our team became the unsung heroes.

The Gateway: Why We Needed a Raspberry Pi

A patient’s phone isn’t always on, and hospitals don’t want to rely on a patient’s personal device for critical data. We needed a dedicated gateway device in the room that could receive data from the ESP32 via BLE, process it, and push it to the cloud via MQTT.

Enter the Raspberry Pi.

We used a Raspberry Pi 4 as the room-side gateway. It’s powerful enough to run a local MQTT broker (Mosquitto) and handle TLS encryption without breaking a sweat. Our Raspberry Pi developers wrote a Python script that subscribes to the BLE data from the ESP32, validates the checksums, and publishes the cleaned data to AWS IoT Core.

Why not just use another ESP32 as the gateway? We could have, but the Pi gave us flexibility. We could SSH into it, run diagnostics, and even host a local web server for on-site testing. It’s a developer-friendly platform that let us iterate quickly.

The Software Stack: Keeping It Simple

We didn’t over-engineer the backend. The Vlepis stack looks like this:

Firmware: Zephyr RTOS on the ESP32 (C language).
Gateway: Raspberry Pi 4 running Raspberry Pi OS Lite.
Backend: AWS IoT Core (MQTT) -> Lambda -> DynamoDB.
Frontend: A React dashboard for nurses.

The key decision was using MQTT instead of HTTP. It’s lightweight, persistent, and perfect for low-bandwidth medical data. The latency is under 100ms, which is more than acceptable for this use case.

The Build: 3D Printing and Prototyping

We didn’t stop at the electronics. The client needed something to show investors. So, our mechanical engineer designed a custom enclosure using Fusion 360 and printed it on our Prusa MK4.

The housing holds the ESP32, the sensor board, and a 1000mAh LiPo battery. It’s compact—about the size of a matchbox—and clips onto a patient’s wrist strap. We shipped three fully functional prototypes to the client within six weeks of the kickoff call.

The Hardest Part: Data Integrity

Let’s be honest: reading a heart rate from a wrist sensor is messy. The MAX30102 is sensitive to movement. If a patient shifts in bed, the readings spike.

We spent two weeks just tuning the firmware filters. We implemented a moving average algorithm and a simple anomaly detection system in the gateway code. If the heart rate jumps from 75 to 150 BPM in one second, the system flags it as an artifact and requests a re-read.

This is where the Raspberry Pi developers shined. They were able to run simulations on the Pi—feeding it noisy data and tweaking the Python filtering logic in real-time—without having to reflash the ESP32 every time. It saved us days of development time.

What We Learned

Building Vlepis taught us a few things about hardware startups:

Don’t build custom PCBs until you have to. Use dev boards and breakouts for the first prototype. It’s faster and cheaper.
The gateway is critical. A Raspberry Pi is perfect for this role. It’s not a production device, but for a pilot program, it’s unbeatable.
Cloud connectivity is a feature, not the product. The value is in the data reliability and the user experience.

The Result

We delivered the Vlepis prototype on time. The client is now running a pilot with a local clinic, and we’re currently designing a custom PCB (using an nRF52840 for lower power consumption) for the production run.

If you’re building a connected health device and need help with the hardware, don’t hesitate to reach out. Whether you need firmware engineers or Raspberry Pi developers to handle your gateway logic, we’ve got you covered.

This post was originally written for the DigitalMonk blog. We build hardware prototypes from scratch—PCB design, firmware, and full assembly—and ship them worldwide.