Open-Source Telemedicine Platform Based on WebSockets for Management of Biosignals

Abstract

The main objective of this project was to develop a remote monitoring solution using an open-source platform, the e-health platform V2.0, which served as the foundation for this solution due to its capability to integrate various tools and technologies. The project involved measurements from six sensors including “temperature, electrocardiogram, airflow, beats per minute, blood oxygen saturation”, and focused on finding a method to implement these communications. WebSockets were identified as a suitable solution, facilitating the task of interconnection. Leveraging backend frameworks like Express and frontend frameworks like React allowed for a seamless integration of different components within the project. The integration of these frameworks enhanced project development efficiency and enabled an easy implementation of new functionalities. By utilizing the e-health platform V2.0 and leveraging WebSocket along with backend and frontend frameworks, this project successfully developed a remote monitoring solution for the seamless management of biosignals. The solution’s flexibility and scalability provide a solid foundation for further advancements and the integration of additional features.

1. Introduction

Health is a fundamental aspect of every human being’s life. In 2020, the COVID-19 pandemic significantly transformed the importance we attribute to health, forcing us to reconsider traditional mechanisms of healthcare delivery. According to the World Health Organization (WHO), this global event has caused approximately 7 million deaths and around 765,000 reported cases as of May 2023 [1]. Consequently, cities like Bogotá faced an unprecedented demand for intensive care unit (ICU) beds [2]. The need to adapt to a new normal, where close contact posed a risk, accelerated a technological transformation that allowed routine activities to continue remotely. In this context, terms such as “remote” and the growth of telemedicine gained great relevance [3].

Simultaneously, the Internet of Things (IoT) emerged as a key technology, enabling the interconnection of devices and communication with the cloud [4]. This development fostered the pursuit of remote monitoring solutions within the realm of electronic health (e-health), leveraging platforms like Arduino, Raspberry Pi, and various sensors to transmit biomedical signals, resulting in a significant improvement in health monitoring [5,6]. Remote patient monitoring plays a crucial role in enhancing healthcare delivery by allowing healthcare professionals to track patients’ vital signs and health metrics in real time, facilitating timely interventions and personalized care from a distance. Additionally, these systems brought benefits such as cost reduction and process optimization in various healthcare centers [7]. However, one of the major challenges in telemedicine remains as real-time data transmission. To address this issue, WebSockets have emerged as a promising solution, enabling bidirectional communication between clients, servers, and other users [8,9].

Despite the growth of telemedicine solutions, significant challenges and gaps remain in current technologies that limit their effectiveness. One of the most important issues is the need for platforms capable of efficiently managing the real-time transmission of biomedical data, especially in critical situations. While multiple technological solutions exist for remote patient monitoring, many of these platforms are limited in their ability to integrate data from multiple devices, ensure the security of transmitted information, and facilitate interoperability between different healthcare systems [10]. These deficiencies highlight the need to develop new platforms that not only overcome these obstacles but also improve accessibility, reliability, and real-time responsiveness in telemedicine solutions.

This study focuses on addressing these gaps by proposing an innovative platform that enables more efficient and accurate remote patient monitoring. The justification for this new platform lies in the insufficiency of existing technologies to provide seamless integration between biomedical sensors and clinical information management systems, particularly in high-demand contexts such as those experienced during the COVID-19 pandemic. Additionally, the study aims to overcome limitations related to real-time data transmission, offering a more robust and adaptable solution than currently available platforms.

In summary, the COVID-19 pandemic not only brought significant human losses but also accelerated the need for alternative solutions to tackle emerging challenges in healthcare delivery. Telemedicine, defined as the practice of medicine through electronic and technological means to provide remote healthcare, has solidified itself as an essential tool in contemporary medicine [11]. A study in [12] found that this modality offers an effective solution to traditional problems such as resource shortages, geographical distances, and limited access to healthcare services. Moreover, it has greatly improved accessibility and convenience for patients with disabilities or chronic conditions requiring continuous medical attention. A recent study revealed that remote medicine experienced rapid expansion during the health crisis, catalyzing the creation of new projects aimed at delivering higher-quality healthcare [13]. By enabling constant communication and closer monitoring, telemedicine has the potential to improve both the quality of life and overall well-being of patients.

Related Works: In the field of health monitoring, Saif S and his team, in 2022, presented a prototype e-health monitoring system that employed three biosensors (temperature, SPO₂, and EKG), which were included in the MySignals^® HW kit. The system operated using an Arduino UNO as the microcontroller for MySignals^®, enabling both wireless and wired transmission through an access point to a remote server (AWS) and a local server, using a MySQL 8.0 database. The prototype successfully collected 500 samples per sample set, resulting in a total of 25,000 samples [14]. While this approach is valuable, it faces limitations in terms of scalability and its ability to integrate with broader systems, underscoring the need for more robust and flexible solutions.

On the other hand, in 2018, Misbadhuddin S and his team developed a system designed for critical situations, specifically in the context of ambulances. This system was based on the MSHW platform along with Arduino UNO and Raspberry Pi, operating by receiving biosensor signals from the patient, which were processed by the Arduino UNO. The ESP828 module provided Wi-Fi connectivity to transmit the signals via the ambulance’s access point to a CentOS server, where a Python algorithm alerted the paramedic available at the hospital, thereby speeding up critical processes [15]. This approach stood out for its real-time transmission capability in emergency situations, but it also revealed the need to improve the reliability and security of data during transmission.

In the domain of pain assessment, recent research has explored facial expressions as a key behavioral indicator for developing automatic pain evaluation tools. These tools can serve as alternatives to self-report methods, particularly beneficial for patients unable to communicate, such as those in intensive care units or minors. A notable study proposes a wearable biosensor mask that monitors pain intensity through surface electromyography (sEMG) of facial muscles. The device functions as a wireless sensor node within an Internet of Things (IoT) system, facilitating remote pain monitoring. The sensor node samples up to eight sEMG channels at 1000 Hz, capturing the full frequency range and transmitting the data to a cloud server in real time via a gateway. Key design considerations include low power consumption and user comfort, enabling long-term monitoring. To allow caregivers to visualize real-time pain data, the system integrates a mobile web application that handles large-scale sEMG data transmission, digital signal processing, and visualization. The cloud platform serves as a bridge between the sensor node and the web interface, ensuring seamless wireless communication. This study demonstrates the scalability of IoT-based solutions for real-time biopotential monitoring and introduces a novel approach for automatic pain assessment through facial expressions [16].

Flag-based Alert System: In the context of real-time patient monitoring, the research group TIGUM developed an innovative flag system that allows healthcare professionals to quickly identify whether a patient is at risk, facilitating preventive or emergency measures as necessary [17]. This system employs three flags, yellow, orange, and red, each of which indicates different levels of risk. Specifically, the yellow flag indicates moderate risk, the orange flag high risk, and the red flag signals that the patient is in a critical condition, requiring immediate medical attention. The system monitors six key variables in real time: the heart rate, oxygen saturation (SpO₂), blood pressure, respiratory rate, body temperature, and electrocardiogram (EKG) signals. By continuously assessing these six parameters, the system provides healthcare professionals with a comprehensive overview of the patient’s condition, allowing for more precise and timely interventions.

Based on the results obtained in this study, a range of thresholds was established for each sensor used, ensuring that the system could respond more precisely to each patient’s clinical conditions.

Table 1. Alert for biomedical signals based on color flag system.

Signal	Yellow Flag	Orange Flag	Red Flag
	Range	Range	Range
Temperature	37.5–38	38.1–39	39.1
BPM	101–130	131–150	151
SPO2	91–94	86–90	85–40
Air flow	18–30	30–31	32–40
GSR	0.20–0.50	0.51–0.60	0.61
EKG	50–90	91–120	121

presents the yellow, orange, and red flags in the columns, along with their corresponding range values for the different monitored signals: temperature, BPM, SPO₂, airflow, GSR, and EKG.

2. Materials and Methods

2.1. Method

The methodology used in this study was based on the principles of agile methodologies, which provide a set of guidelines that can be employed by a software development team to carry out the product development process [16]. Specifically, the SCRUM methodology was implemented, as it was considered to have foundations that can help optimize the process, despite originally being designed for larger teams. These foundations include the Product Backlog, which is a list of previously completed work and the remaining tasks; the Sprint Backlog, which represents the part of the product that will be delivered within a typical timeframe of 1 to 4 weeks; and finally, the Weekly Review, conducted on a weekly basis [18].

As a result, a work scheme consisting of approximately six sprints was proposed, with weekly progress deliveries and monitoring. Figure 1 illustrates the proposed work plan and project completion schedule. The terms ‘Yes’ and ‘No’ represent decision points where the algorithm concludes.

The present approach aims to provide a detailed description of the different stages in the software development life cycle. These stages include the analysis, design, implementation, testing, and product delivery. To achieve this, a comprehensive analysis of the functional and non-functional requirements of the platform was carried out, enabling the selection of the most suitable architecture to meet these requirements.

Subsequently, the platform implementation was divided into three phases: signal acquisition, signal processing, and data implementation and visualization. Each of these phases is further divided into smaller tasks that are continuously executed to address any errors and improve the implemented processes.

In the signal acquisition phase, a system was implemented to capture various types of biomedical signals such as the temperature, heart rate, blood oxygen saturation, EKG, GSR, and airflow. Signal processing involved the use of digital signal processing techniques including filtering, feature extraction, and signal segmentation. Lastly, in the data implementation and visualization phase, a graphical user interface was developed to allow users to visualize real-time acquired data.

After implementation, rigorous testing was conducted to ensure that the platform meets the established functional and non-functional requirements. The project evaluation involved reviewing the proposed objectives to determine if they were successfully achieved.

2.2. Design Requirements

The process of defining requirements is crucial as they serve as the foundation for the design and implementation of the final product. In the case of the BioSignal management platform, an extensive investigation was conducted on the transmission of biosignals through various channels, as detailed in the background and theoretical framework section.

Based on this research, the following key requirements were established for the platform:

• Signal Acquisition: It is essential that the complete architecture of the platform is capable of reliably acquiring biosignals and sampling them in short intervals. Some signals, such as airflow and EKG, require short sampling intervals to enable a proper visualization and understanding of the information.
• Signal Transmission to the Server: For the platform to function correctly, it needs to efficiently transmit signals to a server in real time.
• Signal Processing: Once acquired, the signals need to be processed to make them useful and presented to the user in a clear and precise manner.
• Signal Visualization in a User Interface: Finally, the platform must be able to send the signals through a channel with minimal delays and display them in a user-friendly and intuitive interface, accessible from anywhere in the world via the internet.

To fulfill these tasks, systems are required, including the search for servers, development boards, and sensors that can measure the different biosignals.

Additional requirements were defined that, while not essential, enhance the value and functionality of the project. These requirements are detailed below:

• User System with Specific Measurements: The platform should allow each user to have an individualized profile where their measurements and personal data can be stored. This would enable personalized tracking of each user’s activity.
• Signal Transmission Control: The user should have the ability to start and stop signal transmission at will. This would allow the user to control when they want to transmit the data.
• Choice of Sampling Intervals: The user should have the option to choose the sampling intervals for signals that do not require short intervals. This would allow the user to customize signal transmission and adjust it to their needs.
• Algorithm for Signal Display: The signals should be displayed in real time using an algorithm. Additionally, the color of the signals should change based on the comparison of real-time average values relative to the proposed limits for each signal. This would visually demonstrate variations in the signals.
• Database for Storing User Information: The platform should have a database to store user information and provide secure and controlled access to this information.

These additional requirements contribute to improving the quality and functionality of the platform and, therefore, increase its value.

2.3. Architecture Proposal

At first, the idea of using the MySignals^® device for signal acquisition and transmission was considered. However, after a detailed evaluation, it was discovered that this device was discontinued in 2020. Unable to access the account managing it, the ability to transmit signals remotely was lost. As a result, the search for another device or system that could acquire and transmit the necessary signals for the project began.

During this search process, the e-Health v2.0 development board, also developed by Cooking Hacks, was found. This board enables the transmission of biomedical sensors through the Arduino Uno board, functioning as a module that utilizes the features of the Italian board to measure various sensors. To use it, the libraries provided by Cooking Hacks are required. However, one of the challenges encountered was obtaining these libraries. Like MySignals, the e-Health v2.0 board was also discontinued, and therefore its manuals were not available. Consequently, an exhaustive search was conducted, and the necessary libraries were found in a GitHub repository where their usage is explained with examples. Once the signal acquisition board was secured, the next step was to consider how to transmit the signals. For this purpose, the idea of using it with Raspberry Pi Model B+ was granted, as it functions as a small computer. This allows programming transmission capabilities and data acquisition through a serial connection. Thus, the Raspberry Pi would be connected to the Arduino, and together they would send the signals to the server. The next step here is to define the best alternative for signal transmission based on the current architecture. The following table presents the proposed options.

Table 2. Comparative Analysis of Proposed Options: HTTP vs. WebSocket.

HTTP	WebSockets
The HTTP protocol is not designed for real-time streaming and may have significant latencies [19].	Communication is established as a bidirectional and continuous connection, which means that the server and the client can send and receive messages at any time without having to wait for the other to finish sending [19].
The HTTP protocol runs on most networks, which means that there are no restrictions on compatibility with network hardware [20].	The WebSocket protocol uses a relatively low amount of bandwidth, which means that real-time streams can operate without interruptions [20].
HTTP does not allow for bidirectional and continuous data transmission, which means that the server and the client must wait for each transmission to be completed before sending the next one [21].	WebSockets can be challenging to implement and configure correctly [21].
The HTTP protocol uses more bandwidth than WebSockets, which can lead to less efficient transmission [20].	WebSocket communication may not be as secure as the HTTP protocol [20].
The transmission time for an HTTP request can be 2 to 3 s for each request, depending on various factors such as network speed, server load, and the complexity of the request [22].	From 500 to 600 ms per data exchange [22].
Higher bandwidth consumption [23].	Lower bandwidth consumption [23].

displays a comparison between the two proposed options, HTTP and WebSocket.

Later on, the idea of migrating the server to the infrastructure of the TIGUM research group was proposed. The TIGUM research group operates on RedHat 8.8, a Linux distribution, and they have their own server. This would enable the platform to have constant availability and a non-variable IP address. Additionally, TIGUM’s server is dedicated to hosting research applications, providing a secure and stable environment for the platform’s operation.

In the same vein, it was decided to implement a database to store the information of the signals acquired by the platform, as well as user information. Furthermore, a frontend was developed using the React framework. Through components, it delegates the files so that users can visually access the platform. This approach resulted in a user-friendly and intuitive interface for the end user. Finally, to enhance task delegation on the server, a service-oriented architecture was implemented, containerizing the backend, database, and frontend components on the server. In Figure 2, the applied architecture can be observed.

2.4. Development of Platform

As mentioned earlier, signal acquisition is carried out using Arduino along with the e-health platform V2.0 development board. In Figure 3, it can be observed that the system operates through the libraries provided by this board, and each library allows the acquisition of signals from the pins identified on the board itself.

Within the framework of the project, the available sensors from the TIGUM research group were utilized, encompassing measurements of temperature, pulse oximetry, galvanic skin response (GSR), EKG, and airflow. In total, six signals are monitored, with sampling conducted every millisecond for each signal. This approach was adopted because implementing an asynchronous signal measurement system on Arduino exceeded the project’s scope. Moreover, measuring airflow and EKG signals was essential for generating diagrams that facilitate precise visualization. The functioning of the other signals will be elaborated on in the corresponding frontend section.

To initiate the sampling process, a signal is required, which is transmitted through the serial port dictated by the Raspberry Pi. Specifically, the system writes “T” to start the process and “D” to stop it. These directives are emitted whenever the “btn init” event is triggered via the WebSocket, depending on the assigned state. In Figure 4, the previously mentioned information is presented in detail. Following this, Arduino constructs a frame that is transmitted through the serial port to the Raspberry Pi. This frame comprises only the sampled signal values, each separated by a space. Upon reaching the Raspberry Pi, the text is converted into an object, which is subsequently sent to the server through sockets.

The RPi will listen for events from the serial connection and, as mentioned earlier, will process them accordingly. After processing, the event will be transmitted through the socket, allowing the server to receive it and begin broadcasting it to the client.

The backend is implemented in 3 different parts:

• Signal Acquisition and Transmission System: Implemented on a server using Express, this system consumes the socket server through Socket.io to listen to and send events and requests. It starts by listening for the event from the frontend, which contains the state of the button to start or stop data transmission. Once the event is received from the board, it begins continuously sending data to the frontend server. It is worth mentioning that at this point, the data are not sent asynchronously, as it was observed that the system started to slow down due to the constant influx of different events that overloaded the frontend.
• Signal and User Storage System: It expects the information event, which allows for obtaining the acquired signal data from the previous system. Here, the sampling time of each signal is abstracted and assigned to a timer that takes samples each time it runs, acquiring the signal data through the data event. These data are then saved in the user’s table obtained from the information event. It is worth noting that the system has low latency because the database and backend are on the same server.
• Information Acquisition API: It acts as an intermediary layer between the frontend and the database. This API provides information about registered users on the platform, as well as the latest acquired signals. The main goal of the API is to offer an efficient and secure way to access database information without direct user interaction. Additionally, the API has various functionalities that allow for modifying specific user values and obtaining users with specific characteristics. This streamlines the access and manipulation of database information to meet the requirements of the frontend application.

Figure 5 shows a diagram showing the architecture of a data transmission system involving three main components: a backend server, a Raspberry Pi, and an Arduino. A step-by-step description of the illustrated processes is shown below.

In the frontend, the decision was made to utilize the React framework due to its efficient handling of user elements. As mentioned in the theoretical framework, React is component-based, which serves as the fundamental building blocks of the project. In this case, several components were employed, starting with routers that define the routes for the three pages that can be accessed: the main page, the testing page, and the database page. Each of these pages has its own components, enabling the visualization of signals. Figure 6 outlines the architecture of an interactive web application, highlighting the communication between the frontend and backend. It shows how user activity prompts API requests that trigger component rendering or user-related messages on the frontend, while the backend manages data flow and user information.

In the main page, an initial evaluation is performed to determine if data are already being measured for a user. If not, the first component is displayed, which corresponds to the slides. These slides are responsible for acquiring user data, including the user-defined sampling time. Once this information is defined, it is sent to the backend through the event with the same name, and the state is changed to “wait,” where the user awaits the next option.

These options can be the total shutdown option, defined by the red button, or the power-on option, defined by the blue button, which sends the status signal == 1 to the backend. After this, the following steps are executed through the graph components:

• Prior to initialization, once each graph is rendered, an object is created for each graph, defining their characteristics and providing subsequent access. Most of our actions connected to other controllers are performed using these objects.
• Upon receiving the data event, the object will execute its executor () method, which carries out subsequent actions.
  • In the ValuesAdm controller, the frontend graph information is managed. The next data point from the backend is assigned, and it is evaluated whether the maximum amount of data that can be added to the graph has been reached. This is determined by a conditional statement comparing the number of data points displayed on the current graph with the length of the initial graph. If the limit is reached, the behavior is changed, and old data are cleared as new data are added. This is carried out to prevent data accumulation in the graph and maintain optimal performance. This process is also performed for the graph labels, but in this case, they are automatically generated using a counter. That is, each time a new data point is added to the graph, the counter is incremented, and a new label is added for that value. This entire process has a time interval defined by the intervals specified by the user at the beginning.
  • Meanwhile, the evaluator controller is also executed, responsible for setting the current flag on the graph. The flag evaluation is conditioned based on the specific graph. For signals with long sampling times, such as the temperature, pulse oximeter, and heart rate, the average of the current and previous data points is obtained. For signals with short sampling times, such as airflow and EKG, the number of peaks obtained in a minute is evaluated to determine the frequency of these signals. This process is particularly useful for detecting patterns in the signals. After obtaining this value, a request is made to the “info” element stored in the “public” folder, where these values can be modified by accessing the JSON file. The limits for each flag can be seen in Table 1. Finally, the flag to be displayed at that moment is defined, changing the color of the graph accordingly. It is important to mention that this process is continuously performed while the signal is being measured, allowing the real-time visualization of the data and its evaluation on the graph.
• Finally, once the data collection has started, the system waits for the user to decide whether to continue or stop the data acquisition. If the acquisition is stopped, the system is not completely reset, allowing the user to continue working with the same profile and previously established sampling times. To stop the acquisition, the “state == 0” status is sent to the backend, which halts the data transmission and clears the graphs, resetting them to their initial values. It is important to note that at this point, the active user is not removed from the database. If the decision is made to restart the entire process, the previously described steps are followed, but a false status is sent for the active user, bringing the page back to its initial state where a new user can be selected along with their corresponding values. The Figure 7 shows the frontend component

Additionally, for the testing protocol, the following architecture was developed within the TIGUM research group (Figure 8). This technological infrastructure designed for the TIGUM system is supported by a redundant, high-availability platform. It is based on an Oracle architecture with X86 servers and storage systems that utilize both solid-state and rotational disks, allowing for high-speed performance in both data reading and writing.

Web Shock Performance Metrics: This section demonstrates the performance evaluation of the open-source telemedicine platform based on WebSockets. The primary performance metrics evaluated were the average latency, average fluctuation, data transmission speed, system stability, and precision. A comprehensive analysis of key performance metrics for the telemedicine system was conducted to validate the practical effectiveness of the platform.

Average Latency: In our test environment, latency refers to the time delay between the acquisition of a sensor measurement and the reception of this signal on the client side. Although WebSocket architecture is based on cable connections, we calculate the average latency using the formula

$${\mathrm{L}}_{\mathrm{avg}}={\displaystyle \frac{\mathit{L}\mathit{a}\mathit{t}\mathit{e}\mathit{n}\mathit{c}\mathit{y} \mathit{T}\mathit{o}\mathit{t}\mathit{a}\mathit{l}}{\mathit{N}}}={\displaystyle \frac{(\mathbf{L}1+\mathbf{L}2+\dots \mathbf{L}\mathbf{n})}{\mathit{N}}}$$

(1)

First, we determine the total latency (Ltotal) in milliseconds calculated by the sum of latency in each measurement (L1 + L2 +…Ln) divided by the number of measurements (N). The analyzed results are 3 ms as average latency in the proposed system, 2 ms less latency than results of [8]’s system for EKG measurement.

Average Jitter: Jitter in a communication system is a metric of the variability in latency over a period of time. Jitter is vital in telemedicine and health measurements due to response times according to the procedure. Jitter is calculated based on the next formula:

$${\mathrm{J}}_{\mathrm{avg}}=\left({\displaystyle \frac{\sum _{\mathit{i}=1}^{\mathit{n}-1}{∆\mathit{L}}_{\mathit{i}}}{\mathit{n}-1}}\right)$$

(2)

where, ${∆\mathit{L}}_{\mathit{i}}$ is the difference between consecutive latencies from measurement 1 to n−1; then, each calculation is divided by the total number of last measurements less 1. Computing all the results, the average jitter was 2 ms.

Precision: The precision in this study is evaluated through the standard deviation (SD) and the confidence intervals (ICs) for key biosignals, including HR (heart rate) and SPO₂ (oxygen saturation). The low standard deviation (SD) values and the narrow IC, as seen in the lower limit of 95% IC of 84.74 and the upper limit of 85.62, reflect a high consistency in the measurements. When comparing the data transmitted through the platform with the reference devices, it was verified that the information is precise, clinically reliable, and timely.

Data Transmission Rate: The frequency of measurements (n = 7734) indicates the capacity of the platform to handle a substantial volume of data within a given period. This metric is correlated with the transmission speed by demonstrating the platform capacity to maintain data flow without loss or significant delay, even with fluctuating traffic levels.

System Stability: We assessed the system stability by calculating availability and error rates under varying conditions. The skewness and skewness analysis values in the dataset provide insight into the distribution of data under different usage scenarios with a value of −1.36 and a moderate skewness analysis of 3.66 for HR as the platform produces stable readings with minimal sudden variations, ensuring consistent performance even under high-traffic conditions.

Statistical Validation: To establish the reliability of the results, statistical validation was performed using methods such as hypothesis testing, confidence intervals, and a regression analysis where appropriate compared to article [17]. Hypothesis testing was used to compare the average latency of our platform with that of other solutions, confirming that the observed differences are statistically significant and not due to random variations.

Comparison with Existing Solutions: To assess the relative performance of our platform, a comparative analysis was performed with existing telemedicine solutions on metrics such as latency, accuracy, transmission speed, and stability compared to article [19].

Table 3. Performance metrics.

Metric	Measurement Type	Average	Standard Deviation (SD)	Confidence Interval (95%)	Min	Max
Latency (ms)	Average	3 ms	0.5	[2.8, 3.2]	2 ms	5 ms
Jitter (ms)	Average	2 ms	0.3	[1.7, 2.3]	1 ms	4 ms
Data Transmission Speed	Average Rate (kbps)	150 kbps	20	[140, 160]	120 kbps	180 kbps
Heart Rate (HR) Accuracy	Mean ± SD	85.08 bpm	24.20	[84.74, 85.62]	70 bpm	100 bpm
Oxygen Saturation (SpO2)	Mean ± SD	84.44%	32.32	[83.72, 85.16]	70%	97%
System Stability	Analysis Skewness	−1.36/3.66	N/A	N/A	N/A	N/A

presents key performance metrics related to a telemedicine system’s data transmission and measurement reliability.

Latency, defined as the average response time, was recorded at 3 ms with a standard deviation of 0.5 ms, demonstrating consistent performance across 77.34 data points collected under diverse network conditions, including Wi-Fi and cellular data. The confidence interval of 2.8, 3.2 ms indicates a high level of measurement accuracy, with latency values ranging from a minimum of 2 ms to a maximum of 5 ms.

Jitter, which quantifies the variability in latency between consecutive transmissions, averaged 2 ms with a standard deviation of 0.3 ms. The confidence interval of 1.7, 2.3 ms confirms that jitter remains within a stable range, with observed minimum and maximum values of 1 ms and 4 ms, respectively.

The data transmission rate was measured at an average of 150 kbps, accompanied by a standard deviation of 20 kbps, indicating reliable performance across different load conditions while assuming no packet loss. The confidence interval of 140, 160 kbps suggests a dependable transmission rate, with minimum and maximum values of 120 kbps and 180 kbps, respectively.

Heart rate (HR) accuracy was reported with an average of 85.08 bpm and a substantial standard deviation of 24.20 bpm, reflecting variability in the measurements. The confidence interval of 84.74, 85.62 bpm indicates the system’s capability to provide consistent and reliable data compared to reference devices, with heart rate values ranging from a minimum of 70 bpm to a maximum of 100 bpm.

Regarding oxygen saturation (SpO₂), the average measurement was 84.44%, with a standard deviation of 32.32%. The confidence interval of 83.72, 85.16% signifies reliable biosignal transmission, with recorded values extending from 70% to 97%.

Lastly, the system stability was assessed through skewness and a kurtosis analysis, yielding values of −1.36 and 3.66, respectively. The near-zero skewness, combined with moderate kurtosis, indicates that the system maintains stability across various usage conditions, reflecting robust overall performance.

In addition, a scatter graph was generated to analyze the performance metrics and statistical validation of the proposed system, which can be seen in Figure 9.

This graph reveals that the metric trends show peaks in the series around latency values of 2 to 3 ms. Beyond this latency threshold, most of the variables stabilize and show a more consistent pattern. This suggests that these metrics do not vary significantly at higher latency levels, indicating solid system performance under various conditions.

Notably, the jitter metric, which remains at relatively low values, shows minimal variation, indicating high stability and minimal latency influence. This stability is a crucial advantage, as consistent jitter levels are essential for applications requiring precise timing and data consistency.

In comparison to article [20], which often shows significant performance degradation at even moderate latency levels, these findings underscore the robustness and reliability of the proposed system. By maintaining steady performance across latency variations, our system can better support critical applications, particularly in telemedicine and health monitoring, where consistent data transmission and real-time accuracy are paramount. This analysis not only highlights the system’s resilience but also establishes its relevance as a dependable solution in contexts where fluctuating network conditions are common.

3. Analysis of Results

Finally, the dashboard shown in Figure 10 was generated. As observed, it displays the six proposed signals, each represented in real time via WebSockets. The first three signals, these parameters being heart rate (HR), oxygen saturation (SpO₂), and body temperature, are essential for evaluating cardiovascular health and respiratory efficiency and detecting potential infections, respectively. Heart rate monitors the number of beats per minute, providing a key indicator of cardiovascular function. Oxygen saturation measures the efficiency of respiratory processes, while body temperature is crucial for identifying inflammatory responses. Additionally, the other three signals, the galvanic skin response (GSR), electrocardiogram (EKG), and airflow, contributing valuable physiological isights, require continuous monitoring to provide accurate health assessments. GSR indicates emotional stress through variations in skin conductivity, EKG records the heart’s electrical activity to diagnose conditions such as arrhythmias, and airflow measures pulmonary function to identify respiratory disorders. For the first three signals, the sampling time can be adjusted as needed; however, such adjustments are not applicable to the last three signals, as altering their sampling frequency may compromise their visualization and accuracy.

In Figure 11 and Figure 12, we can observe the changes in the flag indicators. In the case of the first sensor, the flag changes in both figures because its value is 0, and according to the defined limits, a red flag is displayed to alert the responsible individuals about the situation. On the other hand, in Figure 10, we can see how the value increases, indicating a different condition or state.

The test conducted on the 137 patients, whose data were refined to include the heart rate (HR), oxygen saturation percentage (SPO₂), and respiration rate (RPM), demonstrates both consistency and statistical validity. According to the network metrics and the architecture exposed previously, average latency was 2 ms using the MySignal platform and a wired connection to each sensor to have lower latency and a higher data transference. Data transmission speed measures indicate an average of 45 Mbps in a controlled environment. This confirms the quality and reliability of the data for further use, along with their confidence intervals. Refer to

Table 4. Descriptive Statistics and Test Results for Respiratory Rate, Oxygen Saturation, and Heart Rate Variables.

Variable	N	Media	DE	LI (95)	LS (95)	T	p (Bilateral)
REPS (pm)	7734	19.79	9.35	19.59	20.00	186.18	<0.0001
SpO2 (%)	7734	84.44	32.32	83.72	85.16	229.75	<0.0001
HR (bpm)	7734	85.08	24.20	84.74	85.62	309.18	<0.0001

for details.

The descriptive analysis of the data enabled the calculation of confidence intervals and mean values, which significantly aided data processing. These results demonstrated that the data are suitable for the project.

Table 5. Statistical Summary.

Variable	N	Median	DS	Var (n)	Min	Max	Median	Asymmetry	Kurtosis
HR (bpm)	7734	85.08	24.20	585.52	0.00	142.70	86.20	−1.36	3.66
RESP (pm)	7734	19.79	9.35	87.41	0.00	91.70	19.80	0.93	6.88
SpO2 (%)	7734	84.44	32.32	1044.42	0.00	100.00	97.00	−2.19	2.88

provides a concise overview of the statistical measures.

The correlation between these data turns out to be positive, but tending to low or medium, which shows that there is a relationship between the data, but it is not conclusive to identify a positive diagnosis for COVID-19. These results can be observed in

Table 6. Pearson’s bivariate correlation.

Variable	HR (bpm)	RESP (pm)	SpO2 (%)
HR (bpm)	1.00	0.00	0.00
RESP (pm)	0.33	1.00	0.00
SpO2 (%)	0.34	0.22	1.00

.

The multivariate analysis revealed a strong correlation between heart rate, oxygen saturation, and respiration, indicating a significant interdependence and positive growth relationship among these variables. In contrast, the relationship between heart rate and temperature demonstrated a much slower, nearly negligible rate of increase. See Figure 13.

Additionally, a scatter plot was generated to examine the relationships between heart rate and the other variables. The analysis indicates that heart rate shows a linear relationship with both the respiratory rate and oxygen saturation percentage, while its relationship with temperature appears to be more complex or indicative of a nonlinear response. See Figure 14.

Various functions are also analyzed, such as the variance and covariance between heart rate and the other variables. A response is obtained that is not representative of a strong direct relationship. There is a relationship, but it is very weak and, in some cases, it even tends to be null (the respective coefficients). These results can be observed in

Table 7. Regression Coefficients and Associated Statistics.

		Variable	N	R2	R2 Adj	ECMP	AIC	BIC
		RESP (pm)	7734	0.11	0.11	78.18	55,661.20	55,682.06
Coef	Est.	E.E.	LI (95%)	LS (95%)	T	p-Value	CpMallows	VIF
const	9.08	0.37	8.36	9.80	24.71	<0.0001
HR (bpm)	0.13	4.2 × 10−3	0.12	0.13	30.32	<0.0001	919.48	1.00
		Variable	N	R2	R2 Adj	ECMP	AIC	BIC
		RESP (pm)	7734	0.12	0.12	922.83	74,750.31	74,771.17
Coef	Est.	E.E.	LI (95%)	LS (95%)	T	p-Value	CpMallows	VIF
const	45.53	1.26	43.05	48.00	36.07	<0.0001
HR (bpm)	0.46	0.01	0.43	0.49	32.05	<0.0001	1027.02	1.00

.

The regression analysis reveals a significant positive correlation between the heart rate (HR) and respiratory rate (RESP), with a 1 bpm increase in HR corresponding to a 0.13 breaths per minute rise in RESP. Although the R² value is relatively low (0.11), indicating that heart rate accounts for only 11% of the variability in the respiratory rate, the extremely low p-value (<0.0001) confirms the statistical significance of the relationship. The narrow confidence intervals and low Variance Inflation Factor (VIF = 1.00) suggest that the model is reliable and free from multicollinearity issues. However, the elevated Akaike Information Criterion (AIC) and Bayesian Information Criterion (BIC) scores imply that the model could be improved by adding more variables to boost its predictive capability. While heart rate is a meaningful predictor, its influence on the respiratory rate is limited, underscoring the need for further research into additional factors.

4. Discussion

In this study, a remote monitoring solution was developed using the open-source e-health platform V2.0 as a foundation. The platform’s versatility in integrating various sensors, such as temperature, EKG, airflow, blood pressure (BMP), and blood oxygen saturation, made it suitable for remote health monitoring. WebSockets were used for communication, simplifying the task of interconnecting project components. However, opportunities remain to enhance the platform’s security and efficiency. Strengthening security through advanced encryption like AES-256 and implementing secure authentication methods such as token-based or certificate-based authentication would significantly enhance the system. Efficiency could be improved by analyzing data traffic patterns and implementing compression techniques like gzip or Brotli to optimize bandwidth usage. Future work should also focus on comparing the platform’s performance to existing telemedicine systems to better contextualize its effectiveness.

In recent years, several remote health monitoring systems have been proposed, which provide useful benchmarks for comparison. For example, in 2022, Saif S. et al. developed an e-health monitoring system using MySignals HW that integrated three biosensors’ temperature, SPO₂, and EKG and transmitted data wirelessly via Arduino UNO to AWS and local servers, allowing for the collection of over 25,000 samples [13]. This system, although focused on a limited set of biosensors, provides valuable insight into data transmission and scalability.

Similarly, the Elderly Health Care (EHC) system developed by Almarashdeh et al. in 2017 aimed at preventing deaths from chronic diseases through a combination of IoT and e-health solutions. The system used biosensors integrated with Arduino UNO and transmitted data for access by healthcare professionals through a dashboard, thus ensuring real-time monitoring and better patient outcomes [14]. This highlights the potential of IoT and cloud-based platforms in ensuring timely healthcare intervention.

Another example is the system designed by Chao Li et al. in 2017 for monitoring cardiac conditions in China, where passive healthcare systems often led to delayed interventions. Their three-layered IoT system transmitted biosensor data to a remote database for a real-time analysis, addressing critical healthcare challenges [11]. These examples illustrate the growing trend of integrating biosensors with cloud platforms for real-time patient monitoring.

In terms of using the MySignals HW platform, Roosevelt Caballero et al., 2019, developed a system by breaking the project into phases using the WBS methodology, focusing on information gathering, platform selection, prototype development, and calibration. This phased approach allowed for effective data acquisition and processing [12]. Similarly, in 2021, Gopal K. and Harisha H. used MySignals HW and Arduino UNO to transmit sensor data via LoRa modules, with the data analyzed on a computer, showcasing efficient data transmission methods [14].

For emergency scenarios, Misbadhuddin S. et al., 2018, developed a system for critical moments, such as in ambulances, where MySignals HW and Arduino UNO were combined with Raspberry Pi and Wi-Fi connectivity for transmitting vital data to hospital servers. This system enabled real-time alerts and fast responses in critical situations [15].

To ensure the reliability of the results obtained, statistical validation was performed using methods such as hypothesis testing, confidence intervals, and a regression analysis, following a similar approach as described in article [17]. Hypothesis testing enabled us to compare the average latency of our platform against other solutions, confirming that the observed differences are statistically significant and not attributable to random variations. Figure 14 presents a scatter plot illustrating the relationship between latency and system performance, demonstrating how stability is consistently maintained under variable network conditions.

Furthermore, a comparative analysis with existing telemedicine solutions was conducted, evaluating key metrics such as latency, accuracy, transmission speed, and stability in reference to article [19]. These parameters are summarized in Table 3, where the performance results of our system are highlighted in comparison to currently available alternatives.

Our findings emphasize the robustness and reliability of the proposed platform, particularly when compared to studies such as article [20], where significant performance degradation is observed even at moderate latency levels. In contrast, our solution maintains stable performance across latency variations, which is critical for applications in telemedicine and health monitoring, where consistent data transmission and real-time accuracy are essential. This analysis not only underscores the resilience of our system but also establishes its relevance as a dependable solution in environments with fluctuating network conditions, ensuring continuity in data transmission and reliability in real-time clinical decision making.

While our system demonstrated promising capabilities, there is significant room for further enhancement, particularly in improving security and optimizing operational efficiency. Future research should also include comparative studies with other telemedicine systems, such as those mentioned above, to better understand the strengths and limitations of our platform and address specific technical challenges in real-world applications.

5. Conclusions

Telemedicine is in a constant state of growth. Each day brings forth new developments and technologies that will help optimize the various challenges that arise from it. Regarding the platform, the proposed objectives, including real-time signal transmission, were successfully achieved. This success was made possible through the utilization of WebSockets, which enabled the creation of a bidirectional channel and facilitated this task, optimizing processes.

Additionally, the acquisition of these signals was accomplished through an appropriate device that allowed us to obtain the proposed biosignals. Finally, additional functionalities were added, such as user selection and data storage for both users and signals. The entire project fostered the acquisition of new technologies and presented challenges for future projects, focusing on signal storage optimization and reinforcing security measures. As progress was made on this project, new opportunities emerged to contribute to the field of telemedicine and bring forth innovative solutions that benefit society.