IoT Smart Wearable for Remote Patient Vital Monitoring: Web and App

I co-developed an IoT remote patient monitoring system in a two-person Computer Engineering thesis team, combining a custom wearable device, Android application, web dashboard, cloud backend, and AI-assisted reporting to help doctors, patients, and their families monitor vital signs remotely.

This project was much more than a wearable sensor. My co-developer and I built an end-to-end Remote Patient Monitoring system that connects physical hardware to a cloud-based software platform. I worked across the major parts of the project, including the Android application, web and backend development, embedded firmware, hardware integration, and system testing. The wearable device is built around an ESP32-C6 Super Mini microcontroller. It collects four important vital signs: body temperature through an MLX90614 infrared sensor, heart rate and blood oxygen saturation through a MAX30102 sensor, and systolic and diastolic blood pressure through a modified digital wrist blood-pressure monitor. The ESP32 firmware coordinates the sensors, applies calibration values, follows doctor-defined monitoring schedules, manages sensor power to reduce unnecessary battery use, and sends readings over Wi-Fi. On the software side, we developed a backend that receives and manages device data, a cloud PostgreSQL database through Supabase for storing patient readings and history, a web dashboard for monitoring and administration, and an Android application for doctors and patients. The source-code appendix documents a Go backend and a Dart/Flutter Android application. The system uses role-based access so administrators, doctors, and patients are given different functions. Doctors can review current and historical readings, switch between list and graph views, inspect trends, receive abnormal-reading alerts, change the monitoring schedule for a patient's device, and create AI-assisted reports. Patients can monitor their own readings and receive relevant notifications and reports. Gemini was integrated as an assistant for generating structured patient reports from collected vital-sign data. The AI output is treated as an assistive feature rather than an automatic final medical decision: reports can be reviewed and edited by the doctor before they are signed and sent to the patient. The result was a complete IoT prototype where the physical device, firmware, backend, database, web dashboard, Android app, notification system, and AI feature work as parts of one connected system.

Many remote patient monitoring systems can collect and transmit health readings, but the project identified a gap between simply collecting data and making that information useful to the people responsible for a patient's care. A patient outside a hospital may still need regular monitoring of heart rate, temperature, blood oxygen saturation, and blood pressure. Doctors also need a practical way to review those readings remotely, while patients and family members need a simpler way to understand when a reading may require attention. Another challenge is that monitoring requirements are not always the same for every patient. Fixed measurement schedules can collect unnecessary readings, consume more battery power, or fail to match the monitoring schedule requested by a healthcare professional. We designed the system around these problems. Instead of stopping at sensor readings, the project connects a wearable device to web and mobile platforms, stores historical information, allows doctors to configure monitoring intervals, shows trends, creates abnormal-reading notifications, and assists doctors in preparing structured reports. The goal was to create one connected monitoring workflow rather than separate hardware, application, and reporting tools.

A patient is registered in the system and associated with the appropriate doctor and monitoring device. Role-based access controls what administrators, doctors, and patients are allowed to view or manage. The doctor can configure how often the patient's vital signs should be collected. This makes the monitoring schedule adjustable instead of forcing every patient to use the same fixed interval. The wearable keeps track of the monitoring schedule and reminds the patient when a reading is approaching. The device uses a buzzer and LED indicators, while the connected platforms can also provide notifications. Before collecting a scheduled reading, the device checks for signs that it is actually being worn. This helps prevent measurements from being taken when the wearable is not positioned on the patient. The ESP32-C6 firmware activates the sensors required for that measurement. The MLX90614 handles temperature, the MAX30102 handles heart rate and blood oxygen saturation, and the modified wrist monitor handles blood pressure. Power to sensors can be controlled so components do not need to remain active when they are not being used. Raw measurements are processed by the firmware and corrected using calibration values obtained during device testing. These calibration values are stored so the correction can continue to be applied to new measurements after the device restarts. The processed readings are transmitted through Wi-Fi to the backend and stored in the Supabase PostgreSQL database. The backend manages the connection between the physical device, stored patient records, user accounts, notifications, and the web and mobile interfaces. The system evaluates the collected readings against its monitoring criteria. When an abnormal reading is detected, an alert can be created so the relevant users do not need to continuously watch the dashboard to notice a possible problem. Doctors can open the web dashboard to see their assigned patients, recent readings, historical data, notifications, reports, and monitoring settings. Vital history can be viewed as lists or graphs and filtered by different time ranges to make changes and patterns easier to understand. Patients and doctors can also use the Android application to access monitoring information remotely. The application communicates with the same backend, so the wearable, database, web application, and mobile application operate on the same patient data. For deeper review, the doctor can open the trend-analysis tools. These summarize recent measurements, display graphs, show statistics such as minimum, maximum and average readings, and highlight abnormal events found within the selected period. The doctor can also request an AI-assisted report. Patient data is structured and passed to Gemini to produce a report containing summaries, trend information, identified risks, and recommendations. The system includes a fallback path for situations where the AI service is unavailable, and the generated report remains subject to doctor review rather than being treated as an automatic final decision. Once the doctor has reviewed the information, the report can be kept as a draft or finalized for the patient, completing the path from a physical sensor measurement to information that can be remotely reviewed and acted on.

Patient → wearable sensors → ESP32-C6 firmware → calibration and scheduled data collection → Wi-Fi/HTTPS transmission → Go backend → Supabase PostgreSQL database → web and Flutter Android dashboards → abnormal-reading alerts and trend analysis → Gemini-assisted report generation → doctor review → patient. The important part of this architecture is that each component has a clear job. The hardware captures the measurement, the firmware controls when and how it is collected, the backend manages the data and application logic, the database keeps the history, and the web and mobile interfaces turn that data into information that users can actually review.

The project reached the stage of a functional and tested academic prototype rather than remaining only a design concept. Testing covered the hardware components, sensor behavior, calibration, data transmission, monitoring schedules, diagnostic alerts, AI-assisted report generation, battery performance, and user experience. Because the first raw sensor measurements were not consistent enough, we calibrated the sensors using linear regression and compared the resulting measurements with conventional medical devices. The thesis documents testing with 10 participants and repeated trials for each monitored vital sign, with medical practitioners assisting during the validation process. We also tested the complete data path rather than only checking whether the individual sensors produced a value. Across the vital-sign transmission tests, the values recorded by the wearable matched the values received by the database. Device-to-database transmission generally remained within approximately 0.1 to 0.5 seconds, allowing new readings to appear with little noticeable delay. The abnormal-reading and notification logic was tested using different normal and abnormal values to verify that the system categorized readings and generated the expected alerts. The AI-assisted report feature was evaluated across 20 simulated test runs covering normal readings, individual abnormalities, and multiple abnormal readings. All 20 runs produced the required report fields with 100% completeness and no fallback usage during those tests. The study calculated an overall AI feature confidence score of 86.84%. One limitation identified during testing was response time: complex AI reports could take considerably longer to generate than simple cases. User experience was evaluated with 20 respondents across 26 items. The system received an overall mean score of 4.55 out of 5, interpreted in the study as Strongly Agree. The prototype also has important limits. It depends on internet connectivity for real-time synchronization, its sensors required calibration to improve consistency, and the documented battery test estimated roughly 6 to 7 hours of operation under a 15-minute monitoring interval. The study also does not claim full compliance with international healthcare-data privacy standards or position the prototype as a medically certified production device. These were identified as areas for further development.