An IoT-Enabled Cross-Platform Mobile Health Framework for Real-Time Cardiac Monitoring, Data Visualization, and Intelligent Alerting

The design of mobile health applications for IoT-based vital-sign monitoring has been addressed from multiple angles in the recent literature. Galavi et al. [7] conducted an umbrella review of usability evaluation criteria for mHealth applications and identified that the most frequently overlooked criteria are related to interface simplicity, navigation depth, and timely feedback, findings directly relevant to the navigation-architecture decisions in CardioSense. Ashraf et al. [8] presented an open-source IoT health-monitoring system with cloud integration, while Bhagat et al. [9] evaluated Flutter as a cross-platform mobile development framework, reporting that its widget library and hot-reload cycle substantially reduce development iteration time relative to native approaches. Saraf et al. [10] reviewed Firebase as a mobile back-end service, identifying its real-time database listener model as a key architectural advantage for data-driven applications that require low-latency screen updates. Lovrić et al. [11] validated Flutter's suitability for health-domain interfaces in an independent evaluation using a psycho-oncological counselling application, reporting adequate tooling maturity for health-sector use despite the framework's comparatively young age. Bhimanapati et al. [4] proposed UI/UX design principles specifically for mobile health applications, emphasizing the importance of minimizing cognitive load through flat navigation hierarchies and color-coded status indicators. These principles informed the four-module tab structure and the traffic-light alert escalation scheme implemented in this work.

On the underlying IoT messaging layer, Wytrębowicz et al. [12] compared messaging protocols for IoT systems and reported latency and overhead advantages for publish-subscribe alternatives over simple request-response messaging at larger deployment scales. Kim et al. [13] proposed a design and evaluation framework specifically for mHealth applications, emphasizing minimal navigation depth and immediate status visibility upon login, principles reflected in the CardioSense interface. Regarding the companion sensing hardware, Barral Vales et al. [14] documented fine time-synchronization techniques for ESP32-based IoT devices. Mujeeb Rahman et al. [15] presented an ESP32-based wireless patient monitor validated under live patient-data conditions, a real-time field-testing protocol comparable to the one followed for the device underlying this application. Filgueiras et al. [16] evaluated the accuracy of low-cost wearable sensors against medical-grade equipment, while Saha et al. [17] reviewed machine-learning deployment workflows for microcontroller-class hardware relevant to the companion device's on-device classifier. Finally, Georgieva-Tsaneva et al. [18] reported an IoT-based cardio-monitoring system for underserved contexts, and Uddin and Koo [19] reviewed multi-hop IoT patient-monitoring architectures aimed at extending remote-monitoring reach.

Regarding the companion sensing hardware specifically, several ESP32/MAX30102-based prototypes have been reported without an equivalent dedicated mobile-application layer. Dobbertin-Sanchez and Chinchay-Espino [20] presented a low-cost IoT oximeter built on a NodeMCU and MAX30102 sensor, targeting Peru's non-specialized population, but limited to a local web server without cloud alerting. Contardi et al. [21] coupled an ESP32 to a MAX30102 sensor for continuous point-of-care oxygen-saturation and heart-rate monitoring through a similar local-web-server architecture. Ya'acob et al. [22] reported a real-time ESP32-based wireless health-monitoring system with stable IoT communication but no local display or mobile client. At a higher level of analytical sophistication, Alnajjar [5] described a wearable IoT platform integrating multi-parameter cardiovascular risk prediction, achieving greater diagnostic depth at substantially higher hardware cost and design complexity. Relative to these antecedents, the present work contributes a functionally validated, end-to-end implementation that integrates all components, namely Flutter-based UI, Firebase back-end, multi-channel alerting, and IoT sensor coupling, into a single verified system. The interactive mobile-technology stack itself, rather than the underlying sensor, is the primary documented contribution here.

To make the positioning of this work relative to the studies discussed above more explicit, Table 1 consolidates the application purpose, sensing platform, mobile-side component, evaluation method, and reported limitations of each closely related system. As the table shows, most of the directly comparable ESP32/MAX30102-based prototypes either omit a dedicated mobile client entirely or do not report its evaluation method; this is the specific gap this work addresses. Broader mHealth literature not restricted to this hardware pairing does include mobile dashboards and alerting, so this table should be read as a comparison within the narrower ESP32/MAX30102 hardware family, not as a claim about the mHealth field as a whole.

Table 1. Structured comparison of related mobile-enabled Internet of Things (IoT) vital-sign monitoring systems

4.1 Authentication and onboarding flow

New users created an account by supplying an email address and password through a dedicated registration screen; successful registration triggered a confirmation message and redirected the user to the login screen. Figure 7 shows the login screen with the CardioSense logo, email and password fields, and a sign-in button. Returning users authenticated through the same credentials, after which the application transitioned to the main status screen shown in Figure 8, which displays a Normal classification with 95.0% confidence and a live heart-rate reading of 75.0 bpm synchronized in real time from the companion IoT sensing device, an onboarding pattern consistent with low-cost IoT oximeter and vital-sign monitoring proposals that similarly prioritize a minimal-friction first-use experience [20, 24]. A password-recovery option is available from the login screen for users who forget their credentials.

tu_pian_3.jpg

Figure 7. CardioSense login screen

tu_pian_24.jpg

Figure 8. CardioSense status screen (Normal state)

4.2 Functional evaluation procedure

Because CardioSense is the interface layer of a broader IoT vital-sign real-time monitoring system, its evaluation in this stage focused on functional correctness rather than a structured usability-metric study (such as the System Usability Scale). The application was exercised during live demonstration sessions in which adult student volunteers registered new accounts, signed in, and interacted with the companion sensing device while observing the corresponding screen transitions and data updates in real time. This functional, scenario-based evaluation approach is consistent with early-stage validation practice reported for wearable IoT cardiovascular monitoring prototypes prior to formal usability or clinical trials [5], and aligns with practitioner-reported expectations for remote patient-monitoring tools regarding ease of adoption and integration into daily workflows [25]. Figure 9 shows the application immediately after a successful authentication event, displaying the confirmation banner 'Inicio de sesión exitoso' and the four-module tab bar (Status, History, Alerts, Profile) that anchors the application's user interface design, confirming correct onboarding behavior and navigation-structure rendering across test sessions.

tu_pian_4.jpg

Figure 9. CardioSense post-login screen confirming successful authentication and navigation bar

4.3 Observed functional behavior

Table 3 summarizes the functional checks performed and their observed outcomes across the core application modules.

Table 3. Functional verification checklist and observed outcomes

4.4 Alerting behavior under critical readings

Figure 10 summarizes the evaluation results graphically: all six verified functions received a Pass result, confirming that the complete interaction loop from registration through alerting and historical review operates correctly end-to-end.

tu_pian_26.png

Figure 10. Functional evaluation results by module (all six functions: Pass)

tu_pian_27.jpg

Figure 11. CardioSense alert screen (Arrhythmia state)

Figure 11 shows the application's status screen during a session in which the companion device, built on a MAX30102-over-ESP32 acquisition pipeline similar to designs reported for continuous point-of-care oxygen-saturation monitoring [21] and other ESP32-based IoT device implementations [26], reported an arrhythmia-pattern classification. The interface immediately replaced the normal green status indicator with a high-visibility amber alert card displaying the classification label, a confidence percentage, and the underlying heart-rate value (168.7 bpm), together with a precise timestamp of the last update. This visual escalation design, color, iconography, and information density all shifting in response to severity, was motivated by randomized evaluations of push-based mobile health notifications in an unrelated clinical domain. Those studies report that timely, salient alerts measurably increase user engagement and responsiveness, but this design was not directly tested against that evidence. No equivalent user study was conducted for CardioSense, so the actual effect of this design on user responsiveness remains to be measured [27] and is consistent with the design considerations recommended for sensing platforms targeting chronic-disease populations who depend on rapid, unambiguous status cues [28].

4.5 Historical tracking and alerts modules

The History module aggregated seven days of measurements into summary statistics (mean heart rate, mean SpO₂, and minimum/maximum bounds) and rendered them alongside a trend line, allowing the user to visually identify drift over time without manually inspecting individual records, a pattern of real-time field validation similar to that reported for ESP32-based wireless health-monitoring systems tested under live patient-data conditions [22]. Figure 12 shows the History screen displaying a 7-day bpm trend, mean SpO₂ of 93.1%, and 28 measurements logged in the evaluation period.

tu_pian_28.jpg

Figure 12. CardioSense history screen showing 7-day bpm trend

tu_pian_29.png

Figure 13. Heart-rate range (minimum, mean, maximum) over the 7-day evaluation window

Figure 13 summarizes the same heart-rate range numerically: a minimum of 75 bpm, a mean of 114.8 bpm, and a maximum of 155 bpm over the n = 28 readings logged during the seven-day window, computed by the application using the running mean and incremental extrema described in Section 5.1.

Table 4 consolidates the two classification states explicitly verified during the evaluation, contrasting the reported confidence percentage, heart rate, and severity tier for each, and providing a single reference point for the case-specific figures discussed throughout Section 4.

Table 4. Observed classification states during the functional evaluation

Table 5. Representative alert events logged by triggering parameter

tu_pian_30.jpg

Figure 14. CardioSense Alerts module listing logged events by severity

tu_pian_5.png

Figure 15. Distribution of logged alerts by severity (n = 100)

tu_pian_6.jpg

Figure 16. CardioSense push notification on the Android lock screen

The Alerts module listed all generated events in reverse-chronological order, each tagged with a severity label (such as critical or high) and a human-readable description of the triggering condition (such as low SpO₂, elevated heart rate, or low temperature), confirming that alert metadata generated on the device side was correctly received, parsed, and rendered by the mobile client, consistent with the end-to-end reliability goals emphasized in broader IoT healthcare-monitoring reviews [29]. Figure 14 shows the Alerts module listing 100 logged events for the test account, including a low-SpO₂ reading (89.7%, tagged critical), an elevated heart rate (131.8 bpm, tagged critical), and a low-temperature reading, each with its corresponding elapsed-time stamp.

Table 5 consolidates the specific event types visible in this alert log, contrasting the triggering parameter, the recorded value, and the resulting severity tier for the three representative cases discussed above. Although the full 100-event log spans a broader range of recorded values, these three cases illustrate that the system correctly differentiates between distinct physiological triggers (oxygen saturation, heart rate, and temperature) rather than applying a single undifferentiated alert rule.

Of the 100 logged alerts shown in this session, 42 were tagged as critical and 58 as non-critical, as summarized graphically in Figure 15, indicating that the alert-classification logic distributed severity labels across a realistic mix of conditions rather than flagging every out-of-range reading as critical.

It is important to state precisely what this session-log analysis does and does not demonstrate. The severity label attached to each alert is generated on the companion sensing device according to the thresholding rule described in Section 5.2. The mobile application only receives, parses, and renders this pre-computed label. No independent verification of true-positive or false-positive rates against a clinical ground truth was performed at either the device or application level. Likewise, the elapsed time from event generation to on-screen and push-notification delivery was not systematically measured during this evaluation, so no detection-latency or notification-delivery-time figures are reported. The 42/58 critical/non-critical distribution should therefore be read as evidence that the application correctly displays a heterogeneous mix of severities generated upstream, not as a measured detection-accuracy or latency result. Quantifying alert-generation accuracy and end-to-end notification latency against a reference standard is identified as necessary future work in Section 7.

Beyond the in-app alert list, Figure 16 shows the corresponding push notification rendered on the Android lock screen ('CardioSense Alerta: ... Confianza: 100.0%'), confirming that the alerting pipeline correctly reaches the operating-system notification layer in addition to the in-app Alerts module.

4.6 Profile and informational screens

Registration and login flows completed without errors across repeated trials, including the expected handling of duplicate-account and invalid-credential conditions. Figure 17 shows the Profile module displaying the authenticated user's name with shortcuts to the status and history views, alongside account-management and informational sections (data-privacy policy and open-source license disclosures).

Figure 18 shows the corresponding 'About CardioSense' informational screen, confirming that the application's static informational content, namely app description, version, open-source license disclosures, and privacy-policy access, was integrated consistently with its dynamic, data-driven screens, an integration pattern also reported for portable IoT-based health-monitoring frameworks targeting home-based patient care [30].

tu_pian_7.jpg

Figure 17. CardioSense profile screen

tu_pian_8.jpg

Figure 18. CardioSense informational screen ('About CardioSense')

6.1 Interpretation of the functional evaluation

The functional checks summarized in Table 3 indicate that the core interaction loop of CardioSense, namely authentication, real-time status synchronization, alert escalation, and historical review, operates as designed when paired with the companion IoT sensing device. The visually distinct alert state observed in Section 4.3 suggests that the chosen escalation pattern is likely to support rapid interpretation by non-specialist users; however, this expectation was not yet confirmed through a structured usability instrument, and should be treated as a design hypothesis pending formal testing. Table 6 contrasts the non-functional requirements defined in Section 3.2 with the corresponding evaluation outcome.

The comparison criteria in Table 7 are intentionally limited to hardware stack, connectivity, mobile-client presence, and alerting, because factors such as response latency, usability outcomes, security posture, scalability, battery consumption, and measurement accuracy are not consistently reported in the cited source publications and cannot be responsibly estimated for systems this work did not implement or test. Extending this comparison along those additional dimensions would require either re-implementing the compared systems under a common test protocol or contacting their original authors for unpublished data, neither of which was undertaken here; the present table should therefore be read as a structural and architectural comparison rather than a comprehensive performance benchmark.

Beyond hardware positioning, the decision to build CardioSense in Flutter aligns with the broader trend toward cross-platform frameworks in health-oriented mobile development, where a single codebase reduces the engineering burden of maintaining parity between Android and iOS releases [8]. Similarly, the choice of a real-time, listener-based Firebase back-end over a heavier request-response API mirrors architectural recommendations distilled from messaging-protocol comparisons reported for IoT systems more broadly [12], and is consistent with the time-synchronization and connectivity design constraints documented for ESP32-class IoT companion devices operating over Wi-Fi [14]. The resulting interface design also reflects mHealth usability evaluation guidance on minimizing navigation depth and surfacing status information immediately upon login [13].

Table 6. Non-functional requirements versus evaluation outcomes

Table 7. Comparative positioning of CardioSense against related ESP32/MAX30102-based monitoring systems

6.3 Limitations of the study

Several limitations qualify the present findings. The evaluation reported here is functional and scenario-based; it does not include a structured, validated usability instrument (such as the System Usability Scale) or a statistically powered sample of end users. Long-term reliability of push and email notifications under intermittent network connectivity was not systematically stress-tested. Accessibility considerations, such as screen-reader compatibility and color-contrast compliance for users with visual impairments, were not formally assessed in this stage of development. Finally, the historical-trend visualization was evaluated only over short observation windows, so longer-term data-retention and chart-scalability behavior remain to be characterized.

The functional-evaluation participants are described only as adult student volunteers affiliated with the developing institution; the exact number of participants, their age range, technical background, and recruitment procedure were not formally recorded during this stage and cannot be reported here. This is treated as a limitation of the evaluation’s reporting completeness rather than omitted by choice, and a fully documented recruitment and demographic protocol is planned for the structured usability study identified as future work in Section 7.

Similarly, the physiological values and classification outputs discussed throughout the Results section (Section 4) were received from the companion IoT sensing device rather than computed, calibrated, or independently verified by the mobile application itself. This application-level evaluation should therefore not be read as validating the accuracy, calibration procedure, or measurement environment of the underlying sensor. That sensor is documented and evaluated separately in the companion hardware publication. What this work verifies is that the application correctly receives, displays, and reacts to values generated upstream, not the correctness of those values themselves.

6.4 Implications for interactive mobile health technologies

Beyond its specific role as the companion interface to a vital-sign sensing device, CardioSense illustrates a broader pattern relevant to the interactive mobile technologies field: the pairing of a cross-platform UI framework, cloud synchronization, and lightweight alert systems is reported in the literature to lower the engineering effort required to deliver a responsive, alert-capable mobile health experience relative to maintaining separate native codebases. This specific work did not measure development time or maintenance cost directly; it instead relies on the functional outcome of a working, verified implementation as supporting evidence. The underlying design pattern is also reflected in wireless ESP32-based patient-monitor designs that pursue similarly low development overhead [15]. This is particularly attractive for academic and early-stage prototyping contexts where development resources are limited, paralleling the resource-aware design philosophy behind low-cost wearable sensor evaluations [16] and microcontroller-class machine-learning deployment workflows aimed at minimizing infrastructure requirements [17]. These same resource constraints motivate continued attention to accessible IoT-based cardio-monitoring system designs [18] and to cloud-connected, multi-hop patient-monitoring architectures aimed at extending reach into underserved settings [19].

All functional evaluation sessions described in this work were conducted with adult student volunteers who registered test accounts using non-identifying credentials and were verbally informed of the purpose of the demonstration prior to participation; informed verbal consent was obtained from all participants. No real patient data, clinical records, or personally identifying health information were processed or retained; all physiological values displayed and logged during testing originated from the companion sensing device operated on consenting volunteers for demonstration purposes only. A formal institutional ethics-committee review was not required for this functional-evaluation stage, as no clinical intervention or vulnerable population was involved; a structured usability study with appropriate ethical review is planned as part of future work, as noted in Section 7.