XBeats: A Real-Time Electrocardiogram Monitoring and Analysis System

Abstract

This work presents XBeats, a novel platform for real-time electrocardiogram monitoring and analysis that uses edge computing and machine learning for early anomaly detection. The platform encompasses a data acquisition ECG patch with 12 leads to collect heart signals, perform on-chip processing, and transmit the data to healthcare providers in real-time for further analysis. The ECG patch provides a dynamically configurable selection of the active ECG leads that could be transmitted to the backend monitoring system. The selection ranges from a single ECG lead to a complete 12-lead ECG testing configuration. XBeats implements a lightweight binary classifier for early anomaly detection to reduce the time to action should abnormal heart conditions occur. This initial detection phase is performed on the edge (i.e., the device paired with the patch) and alerts can be configured to notify designated healthcare providers. Further deep analysis can be performed on the full fidelity 12-lead data sent to the backend. A fully functional prototype of the XBeats has been implemented to demonstrate the feasibly and usability of the proposed system. Performance evaluation shows that XBeats can achieve up to 95.30% detection accuracy for abnormal conditions, while maintaining a high data acquisition rate of up to 441 samples per second. Moreover, the analytical results of the energy consumption profile show that the ECG patch provides up to 37 h of continuous 12-lead ECG streaming.

1. Introduction

The World Health Organization (WHO) in 2019 identified that cardiovascular diseases (CVDs) are the number one cause of death [1]. Electrocardiogram (ECG or EKG) is the oldest and most used test by cardiologists for understanding heartbeat “rhythms”. Cardiologists build their diagnoses on heart conditions by analyzing the heart’s electrical activity displayed in waveform format. Diagnosing heart diseases is commonly a manual process [2]. Holter monitors are widely known devices used by practicing specialists and cardiologists to perform ECG testing. There are multiple configurations of ECG tests using Holter monitors, like the number of leads or data acquisition period. The selection between the common two to three leads or the standard 12 leads is left to the cardiologist’s discretion or as the patient’s heart condition develops [3]. The 2- to 3-lead Holter monitors are used for detecting heart rate and its rhythm. Conversely, a standard 12-lead ECG would be needed to screen patients for possible cardiac ischemia and help healthcare providers quickly identify patients who have ST-elevation myocardial infarction (i.e., heart attack) and perform the appropriate medical intervention in time [4]. A standard 12-lead ECG requires a Holter monitor that can be installed at hospitals or carried by the patients. Usually, Holter monitors installed at hospitals come with diagnostic tools to analyze heartbeats in real-time. However, previous ECG charts are not available for comparison with ECG current signals to observe any potential correlation between previous ECG charts and current ECG charts. Furthermore, heart conditions could be misdiagnosed (or an anomaly entirely missed) due to intermittent heart irregularity (aka arrhythmia) [4].

Notably, similar devices provide similar functionality to Holter monitors, also called event monitors [5]. Event monitors are portable devices that a person can carry around day and night until symptoms occur. The main difference is that Holter monitors record ECG signals regardless of the heart conditions during the recording period. In contrast, event monitors are designed to be automatically activated when symptoms are experienced and then record current heartbeats. Alternatively, the patient can manually activate them if an abnormal heart rhythm is felt. Accordingly, recent event monitors can now be configured to be worn continuously, and others are applied to the skin and are activated automatically when any symptoms are experienced [5]. Event monitors overcome Holter monitors’ shortcomings as they can provide heart monitoring for extended periods that can last for weeks. However, event monitors are not designed to trigger an emergency response for life-threatening arrhythmia due to a processing lag at the order of several minutes. Given the requirements mentioned above, the patient is recommended to stay in bed and be hospitalized for the test period. Consequently, in response to the rapid digital revolution and the COVID-19 pandemic, the healthcare landscape has seen a rapid shift from physical to virtual care and telemedicine. The provision of remote patient monitoring has changed the traditional healthcare abilities to monitor and manage patients [6]. Despite the significant research efforts brought by MedTech companies and the research community, continuous remote ECG monitoring still lacks comprehensiveness and completeness compared to the services offered in hospitals and clinics [6,7].

This paper proposes XBeats, a new platform for continuous remote ECG monitoring using a lightweight standard 12-lead ECG smart patch that integrates intelligent signal analysis and offers two heartbeat classification phases. The platform encompasses hardware components that are responsible for the data acquisition represented in our proposed smart patch for ECG monitoring. The ECG patch gathers the ECG data and transmits it to the backend system. The connection between the ECG patch and the backend system is enabled by integrating the latest Internet of Things (IoT) communication protocols (i.e., Bluetooth Low Energy (BLE) and MQTT (Message Queueing Telemetry Transport)). Moreover, the ECG patch introduces interactive modes of operations that are dynamically configured based on the patients’ health conditions or the healthcare provider’s recommendations.

The remainder of the paper is organized as follows: Section 2 reviews related work in this area. The proposed platform architecture is described in Section 3, and we demonstrate the end-to-end solution for real-time ECG monitoring. Section 4 describes the developed prototype of the ECG patch for evaluating the proposed platform. Section 5 contains performance evaluation, and experimental results are given in Section 5. Lastly, Section 6 provides concluding remarks and draws future directions.

2. Background and Related Work

The prevalence of chronic illnesses is increasing. Currently, developments in wearable sensors and communication protocols contribute to the system’s enrichment in ways that will soon transform healthcare services. The first of these improvements is remote patient monitoring (RPM). RPM systems collect vital signs from patients by non-invasive procedures and their real-time transmission to healthcare providers. The information collected by RPM devices may assist clinicians in making the best choice possible at the appropriate moment. Therefore, many efforts have been conducted to advance remote ECG monitoring systems to match or exceed the performance of the ECG testing administered at hospitals and healthcare facilities [8]. This section intends to identify research gaps in defining the lifecycle required to perform a standard ECG monitoring system and highlight the solutions introduced in the literature. The section is divided into three topics categorized by the number of ECG leads provided in each work and an additional section evaluating the work introduced in the industry from a commercial perspective.

2.1. Single Lead ECG

Single Lead ECG devices are very common today. A single ECG lead covers limited heart regions, making it suitable for heart activity monitoring. One-lead ECG can help improve arrhythmia diagnosis but discriminating P-waves may be challenging and insufficient for correct diagnosis of sinus rhythm [9]. Accordingly, these devices are generally used to record long recordings up to 14 days or a recording of merely a few seconds (e.g., Apple Watch Series 7). The authors in [10] fused the machinal pattern of the heart using seismocardiography (SCG) signal with ECG data. The fusion method is based on the Naïve Bayes probabilistic model to extract the PQRST annotations from the raw ECG signal. Then, they calculate the duration between different subsets of the PQRST data vector, which can indicate the presence of abnormalities in the ECG signals. The ECG processing is performed on a host desktop, where the data is transmitted through a synchronous data logger. This process is decoupled from the data acquisition process as it runs using a data logger which is not designed for real-time operations.

Several research works have proposed transmitting ECG signals in real-time to a backend server for processing. The authors in [11] proposed integrating wireless communications (e.g., BLE and WIFI) for transmitting the acquired data. The actual design and hardware prototype didn’t include wireless communication modules. Therefore, the device is connected to high-performance data acquisition hardware. Then, the data are transferred to the host computer for storage, processing, analysis, and visualization. Klum et al. [12] present a fusion algorithm between multiple sensors, including a single-lead ECG sensor to measure lead I or II and a stethoscope to obtain an acoustic insight of the heartbeats. Similarly, [13] introduced a remote single-lead ECG powered by a coin battery. ECG signals are transferred to a mobile device in real-time and then to a backend system for further analysis. Although the device provides offline ECG data logging, it doesn’t analyze the collected data for abnormal heart conditions to notify the patients or the healthcare provider to take necessary actions.

A different line of research develops porotypes that use fog computing to enable remote ECG monitoring. The authors in [14] introduced a single lead ECG monitoring system to provide a telemedical solution for rural areas with the help of fog computing. The system utilizes the ESP-32 module as the main microcontroller (MCU) for processing the collected ECG data, then sends the collected data in one-minute intervals, not on a real-time basis. This limitation is due to the bandwidth restriction of the LoRa communication link (i.e., 0.3–50 Kb/s). Moreover, the authors didn’t consider discontinuity scenarios where no wireless connectivity is in range since the device doesn’t offer offline data logging. Accordingly, this solution is not optimized for long-term ECG monitoring. Similarly, Ahsanuzzaman et al. [15] developed a single-lead ECG acquisition hardware using Arduino Uno for acquiring ECG signals and sending them to a Raspberry PI (RPI) for further analysis and classification. However, the system has an overhead in the design since the Analog to Digital Converter (ADC) is interfaced to an Arduino Uno via Serial Peripheral Interface (SPI). The Arduino Uno device is connected serially to the RPI for signal analysis. This design overlap could have been avoided by directly connecting the ADC module to the RPI. Moreover, the RPI has an embedded BLE module that can communicate with a mobile phone instead of using the extra HC-05 Bluetooth hardware.

The integration of the four modes of operations: (1) serial cable transmission, (2) offline data logging to a local flash drive, (3) transmission to a mobile phone via Bluetooth, and (4) transmission to a desktop via Bluetooth provides better integration and operability. The authors in [16] proposed a single-lead ECG signal acquisition prototype using one of the four given modes of operation. Using the first two operation modes, the system can detect the QRS feature points from a complete cardiac cycle. However, this function is only available through the first operation mode. Besides, the device doesn’t provide an automated handover between operation modes when, for example, a discontinuity event occurs, the device doesn’t switch to the offline operation mode.

2.2. Two ECG Leads or More

Multiple Leads ECG provides a better view of the heart condition for long-term cardiac diagnoses. Further, additional ECG leads are required to diagnose sinus rhythm or arrhythmias. In [17], the authors developed a 3-lead ECG wearable device that transfers the acquired ECG data to a mobile device through BLE communications, then relays the data to a backend system through mobile connectivity. Their hardware is based on the RPI development board as the main MCU, and a breakout Printed Circuit Board (PCB) was designed with an analog frontend for acquiring the ECG signals. The system featured a backend component to store collected ECG data. Despite the RPI’s compact size, multiple communication protocols, and computation capabilities, it is not optimized for wearable technologies since it is not designed for low-power computing. Yuan et al. [18] developed a 3-lead ECG acquisition device to acquire ECG signals during different pregnancy stages. The signals are transmitted to an Android application using BLE. Then, the application performs real-time filtering to remove baseline drift and high-frequency interference. The sample entropy algorithm is then used for fetal ECG extraction performed offline. To that extent, Wang et al. [19] designed an intelligent vest using non-adhesive electrodes to collect 3-lead ECG signals transmitting data to a mobile device to display the received signals. The system acts as a Holter monitor, where no data analytics or classification is done on the collected ECG data. This component is needed in critical heart conditions.

Physicians recommend that increasing the number of active ECG leads helps understand heart conditions. To that extent, Abtahi et al. [20] developed a 5-lead ECG acquisition hardware using ADAS1000 chip as an Analog Frontend (AFE) on a custom-designed PCB interfaced to an RPI module using the serial SPI. The system featured a backend component to store the collected ECG data. However, the hardware is not optimized for wearable technologies since the RPI is not designed for low-power computing. Moreover, the device doesn’t offer offline ECG data recording in disconnected scenarios when Bluetooth connectivity is unavailable. Lastly, the authors [21] introduced an early detection module to notify patients about abnormal heart conditions. However, the module relies on getting the classification results (e.g., Mild and Severe over a certain period) using a script running on a host desktop.

2.3. Standard 12-Lead ECG

Standard 12-Lead ECG provides a complete and comprehensive analysis of the heart and enables a better thorough diagnosis that cannot be obtained otherwise. The authors in [22] presented a 12-lead module to capture ECG vital signals and transmit them to a backend server for analysis via a mobile phone connected to the ECG device through Bluetooth. However, the Bluetooth link used the classical Bluetooth protocols to communicate with a mobile device. It didn’t optimize the BLE protocol stack for sending the data, which increases the packet size and overhead of the transferred data rather than using BLE standard services and characteristics. Besides, the device depends on the results coming from the backend regarding the heart condition of the patient because it only works if the device is connected to a mobile phone with internet connectivity. Moreover, the Bluetooth module used is not optimized for low power consumption, reducing the device’s operation time and compromising the patient experience. Accordingly, their system mainly focuses on the data acquisition part of the ECG test. In contrast, the authors in [23] use a similar monitoring architecture but add active electrodes attached to the patient’s body without adhesive materials. However, the device only supports offline ECG monitoring. The data is stored on a flash drive and then transferred to a PC for further processing and analysis of the collected ECG data.

While in [24], the authors developed a prototype for EEG/ECG data acquisition, the hardware utilizes the TI ADS1298/9 Analog Frontend chip for digitizing analog EEG/ECG signals. The authors incorporated multiple components to make it suitable for remote EEG/ECG monitoring like Bluetooth, WIFI, and local storage (i.e., SD) modules. However, the platform for operating these modules to perform ECG/EEG monitoring is not mentioned. Besides, the authors were interested in validating the integrability and operability of the hardware modules in terms of the available bandwidth between the different components to perform a successful EEG/ECG test.

Lastly, the authors in [7,8] conclude that with the massive diversity of work proposed in ECG monitoring systems, these systems still lack completeness and comprehensives. Despite the significant overlapping in the literature about the number of recorded ECG leads, accuracy, usability, and mobility, these systems cannot provide real-time data streaming and heart condition diagnosis.

2.4. Commercial ECG Devices

ECG devices must be approved by respective health authorities in countries to be used on patients or spread commercially. Currently, there are many devices available in the market that perform remote ECG monitoring. However, most of them have not been approved for medical use by respective authorities in targeted countries, like the Medical Device Bureau in Canada or the Food and Drug Administration (FDA) in America. AliveCor is one of the commercial devices that the FDA has cleared as a clinical-grade consumer product. The device offers real-time diagnoses of heart conditions. It is used to detect recurrent atrial fibrillation only and provides real-time readings for a short time. Also, patients have to stand still and limit their movement during the data acquisition period. The SEEQ^TM sensor by Medtronic Inc. [25], the ZIO^XT Patch by iRhythm Technologies Inc. [26], and the wearable biosensor by Philips [27] all share the same features of continuous ECG data collection from 7 up to 14 days of recorded data. However, the collected data is only for one ECG lead that can only detect limited heart diseases. Additionally, the SEEQ^TM and the ZIO^XT are “single-use” devices. While Savvy ECG [28] addresses the shortcomings of the previously mentioned devices like reusability (rechargeable battery) and real-time streaming to a mobile device, the solution does not offer diagnostic information about the heart conditions of the patient. Moreover, the device cannot determine various heart diseases since it only supports single-lead ECG acquisition. Similarly, BioTelemetry [29] introduced the MCOT wireless ECG that provides two channels of ECG data acquisition with up to 30 days of data storage. The device allows for wireless data transmission on demand. Besides, the device can’t be used multiple times. Once the battery is exhausted, it can’t be used again. Moreover, the battery life lasts for one year, and once the expiration date has expired, the device is no longer usable and needs to be replaced with a new device. On the other hand, [30] delivers continuous wireless ECG monitoring. However, the device captures only one single ECG channel. Moreover, the device is not designed for long-term cardiac diagnoses since the device working time lasts for up to a day, then the device would need to be recharged.

3. XBeats System Architecture

The design of XBeats addresses the limitations of existing solutions by providing a BLE-connected, real-time, and comprehensive ECG monitoring system. The architecture comprises a wearable and unobtrusive real-time ECG device which can be configured with three operation modes: (a) continuous mode, (b) triggered mode, and (c) offline mode.

3.1. Hardware Specifications

The building blocks of the proposed platform are shown in Figure 1. The operation modes that govern the delivered functionalities and behavior of the proposed ECG patch are:

• The continuous mode provides an unbounded real-time high-resolution data stream of the 12-lead ECG data transmitted directly to a backend system. Physicians sometimes require this mode of operation if abnormal heart conditions are detected or the patient’s case requires 24/7 monitoring. However, this mode has a significant power consumption profile that affects the device’s battery lifetime due to the continuous transmission of the collected ECG data wirelessly to the backend system via a communication gateway;
• The offline mode records the 12-lead ECG data on the Multimedia Card (MMC) storage when no paired BLE device is nearby to connect to the ECG patch. This mode is enabled for the entire data acquisition period until a paired BLE device connects to the patch and synchronizes the data transfer to the backend system; and
• The triggered mode is optimized for power saving. The device sends keep-alive signals in normal heart conditions and only transmits ECG signals when a potential heart abnormality is detected. The ECG patch chooses from three data acquisition settings where the number of leads is configurable. The default setting for this operation mode is three ECG leads (e.g., Lead I, II, and V1), which can be changed dynamically in real-time. The patient and healthcare provider can reconfigure the number of enabled ECG leads through a paired BLE-enabled device or the backend system.

The design of the ECG patch implements a modular architecture that focuses on the specifications and functionalities of the hardware components needed for the device operation. Therefore, our ECG patch is not limited to a specific hardware component or vendor, where the proposed hardware components can replace other components with similar capabilities.

3.1.1. Data Acquisition

The data acquisition module is set to acquire the following leads purely in the analog format: two of the limb leads and the six chest leads (i.e., Leads I, II, V1, V2, V3, V4, V5, and V6), while the augmented leads (i.e., aVR, aVL, and aVF) and Lead III are computed digitally. Most importantly, to capture at least one complete heartbeat signal, a sliding window of 2 s interval is used based on the fact that the minimum and maximum heart rates are recorded between 30 and 240 beats per minute (bpm) [31].

The device runs on the default operation mode until a new instruction is received from a connected paired BLE device as shown in Figure 2. Once the connection is established, the instructions are received through the connected BLE device. Then, the ECG patch starts a service routine that listens for new instructions to update the current operation mode. The service routine expects one of three instructions to be received at a time. One of the expected instructions is to activate the continuous mode to perform a 12-lead ECG test. This instruction comes directly from the user through the mobile application or as instructed by the healthcare provider through the backend system. The second instruction involves handling the results of the classification module. The classification module analyzes the ECG data continuously on an edge device upon receiving it from the ECG patch. The classification results are transmitted to the mobile application, and then the mobile application sends instructions to the ECG patch with the classification results. The ECG patch will continue in the triggered operation mode with three leads (i.e., Leads I, II, and V1) when the heart activity is normal. On the other hand, in case of abnormal heart conditions, the classification module will return the number of leads to be activated and start the triggered mode.

3.1.2. Data Transmission and Protocols

Data transmission constitutes the second step of the data pipeline in the XBeats framework as the ECG patch continuously exchanges data with the backend system. Furthermore, the patients and their healthcare providers can display related vital information about the heart from the recorded ECG signals. The data transmission hardware comprises a multi-standard wireless MCU with an RF core that fully supports Bluetooth Low Energy 5.2 (BLE). The MCU enables seamless data transmission in real-time to the backend system. The BLE 5.2 upgrades the data transfer rate two times the rate of the previous Bluetooth 4.2 from 1 Mbps to 2 Mbps. The communication between BLE-based sensors and smart devices is governed by Generic Access Profile (GAP) and Generic Attribute (GATT) protocols [32].

GATT defines how two BLE devices exchange data, while GAP constitutes a standard way for BLE devices to communicate with the outside world. A complete GATT transaction constitutes three high-level, nested objects called Profiles, Services, and Characteristics. For instance, the Heart Rate Profile (HRP) is used in devices measuring heart rate [33]. The HRP profile has two mandatory services: heart rate and device information services. Complementary services can also be added, for instance, Battery Service (BAS) to indicate the battery’s current level. BLE provides a versatile set of full-stack solutions to meet the needs for low-power wireless connectivity. However, a Profile [32] must be defined to exchange data between BLE-enabled peripherals. According to Bluetooth SIG [34], a profile with its related services can be selected from the Bluetooth SIG’s predefined profiles and services if they match the application’s specifications or develop custom services to match the application’s specifications. There is no standard BLE profile to deliver the standard 12-lead ECG services [35]. Therefore, we create a customized BLE profile to enable XBeats to provide the designed services in our platform (i.e., operation modes and ECG data streaming).

To that extent, our proposed ECG BLE “Profile” describes the number of GATT “Services” and GATT “Characteristics” that should be used to achieve the addressed functionalities of the proposed ECG patch. The BLE profile describes how services deliver the application’s intended functionalities [33]. Figure 3 shows the designed “ECG Profile” with three services that correspond to operation modes defined on the ECG patch and the edge classification service. The first service in the ECG profile is the triggered mode containing three characteristics. The first characteristic holds information about the active number of leads. In contrast, the second characteristic is a flag that refers to the status of real-time streaming, whether it’s currently enabled or disabled. The second “Service” is for the continuous operation mode where ECG leads are fixed to the standard 12-lead configuration, and the stream flag characteristic is enabled by default. Lastly, we implement the “ECG Classification” service for our novel dynamic modes of operation. The “ECG Classification” service contains two characteristics. The first characteristic holds the current heart condition results from the classification implemented on the edge device. The other “Characteristic” carries the recommended ECG leads to be activated based on the results from the classification function on the edge device.

3.1.3. Data Logging

The ECG patch integrates a high-performance and reliable MMC for continuous data logging. The data logging process is encapsulated in an independent task running simultaneously with the data acquisition task. A data retention service routine is also integrated within the system for more extended periods, as recommended by cardiologists. Consequently, the device monitors all incoming ECG signals for critical heart conditions detection. After this grace period, newly received data is not recorded until previously saved data is downloaded. This is another system design decision with an alternative option that could be overwriting older data with recent ECG signals. Cardiologists recommend our design choice [36]. The system will alert patients and healthcare providers to reconnect the smart ECG patch or offload the data logger to record ECG signals.

3.1.4. Edge Classification

XBeats integrates a binary classifier implemented on the edge to perform preliminary analysis on the collected raw ECG signal for anomaly detection. The classifier can be either integrated into a mobile application or an edge device with enough resources. The objective of the proposed edge classification is to optimize data transmission to the backend system compared to the continuous mode of operation. The classification module also aims to optimize the device’s battery life by regulating the power consumption profile of the communication module by actively adjusting the number of enabled leads for ECG data acquisition. Before the classification task, data preprocessing is applied to the collected ECG data. The preprocessing phase extracts the PQRST features from the ECG waveform using the Pan Tompkins algorithm [37]. The PQRST feature points constitute one single heartbeat. The correlation between two consecutive PQRST vectors facilitates interpreting the patient’s heart condition and discovering abnormalities if they exist. The preprocessing step includes detecting multiple R points (R-R interval), which helps measure the heart rate. Also, the PR interval, QRS duration, or QT interval contributes to revealing significant heart condition information. That, in return, adds more confidence to the binary classification detection task. The binary classification module (i.e., integrated into the mobile application) classifies the signals into just two categories; normal, which includes one type of signal, and abnormal, representing all other types of signals.

The binary classification of ECG signals utilizes the online dataset PTB-XL Arrhythmia Database [38] to train the model on larger populations. The implemented model uses lead II and resamples the ECG data to 300 Hz to match the minimum sampling rate of the signals extracted from our ECG patch. Model training and verification are performed according to the proposed approach in [39]. The preprocessing phase includes an algorithm to extract 85 features from the ECG waveforms mentioned in [39]. Accordingly, we propose a feature selection technique called mutual information (MI) ranking criterion to select the 10 most informative features from Lead II to obtain high accuracy. Furthermore, we filter the top 10 features into 5 features that are used as an input for the classification algorithm. This approach suits our system needs due to the power and time limitation. We only need to extract significant information about the heart condition, which adds more confidence in the binary classification task. The 5 features are a collection of R–R-intervals, HBF (Hermite basis functions), and time–domain morphology features explained in [39]. We test several algorithms to evaluate which yields better results, including Random Forest, Support Vector Machine (SVM), Decision Tree, k-nearest neighbors (Knn), Logistics Regression, and Extra Trees.

4. Prototype Implementation

This section lays out the tools and hardware used in building our proposed ECG patch. The hardware prototype consists of four major components: A microcontroller with a wireless core for BLE communications, an analog frontend interface (AFE) for acquiring analog ECG signals using a high-performance analog to digital converter and a micro-SD card module for data logging, as shown in Figure 4.

4.1. Data Acquisition and Logging

The prototype of the proposed ECG patch is powered by the SimpleLink 32-bit Arm MCU (CC2652R), which runs as the central processor. The CC2652R chip is capable of handling real-time operations needed for critical safety systems. The MCU features an ultra-low power sensor controller powered by an Arm Cortex-M0 processor that offloads simple tasks like sensors readings of the main MCU. These features make the selected MCU well-suited for high data acquisition applications. Moreover, the ECG patch utilizes a specialized medical AFE to take electrical signals from the heart and digitize them. The ADS1298 chip is integrated into the patch to digitize the acquired ECG signals, and it comes with a 24-bit status word that reflects the status of the electrodes (i.e., probably attached, whether connected or not). Moreover, it offers two sampling modes, namely, high-resolution mode and low power mode. Furthermore, we use the Wilson Center Terminal (WCT) to determine the central terminal needed to perform a standard 12-lead ECG test [2,3]. The ADS1298 chip internally generates the WCT voltage through three integrated low-noise amplifiers that route the signals from the Right Arm (RA), Left Arm (LA), and Left Leg (LL) leads to calculate the WCT voltage. The equivalent voltage for the WCT is calculated using the following equation: (RA + LA + LL)/3. Similarly, the Right Leg (RL) electrode is driven internally by the RL Driver (RLD) on the ADS1298 chip. In XBeats, the RLD is derived as the average of RA, LA, and LL, which has the same level as the WCT voltage. To that extent, the RLD common-mode voltage is set to (AVDD + AVSS)/2, where AVDD is the analog voltage supply, and the AVSS is the analog ground supply. Therefore, the WCT is buffered internally and routed to the RLD. On the other hand, the RLD improves the common-mode rejection (CMR) and reverses the common-mode interference in the ECG circuit due to the power lines interface and other sources. Lastly, we use a digital notch filter of 50 Hz or 60Hz to compensate for the common-mode rejection.

We use the proprietary Texas Instruments Real-Time Operating System (TI-RTOS) in our proposed platform to operate the ECG patch. TI-RTOS provides tools for managing and scheduling tasks using application layer functions. The combination of TI-RTOS and ultra-low-power MCU supports longer battery life and makes applications more adaptable for real-time monitoring systems and wearable devices. The ECG hardware firmware encapsulates the operations conducted by the MCU into tasks using the scheduling APIs of the onboard RTOS. Data acquisition, logging, and transmission are encapsulated in separate tasks. Each task is ranked based on a pre-configured priority. The data acquisition task is set to receive the highest priority in the firmware operating on the hardware. While the data logging task has the second-highest priority after the data acquisition task, then the data transmission task.

The data acquisition task in the XBeats platform runs at a sampling rate ranging between 250 to 500 SPS. In the case of the 250 SPS, the acquisition task captures one sample every four milliseconds (250 samples/1000 ms = 4 ms). The data acquisition task itself requires 1ms to capture each sample. Therefore, the remaining time available for other tasks (e.g., compression, logging, and transmission) to operate after each sample acquisition equals 3 ms (4 ms − 1 ms). This period is down to 1 ms at 500 SPS. However, in the proposed platform we process samples in batches every 1 s, in which we execute logging and transmission tasks. This means we have a total of 750 ms available for these two tasks when the sampling rate is 250. In comparison, at the 500 rates, a total of 500 ms is available for running these tasks. This setup is a stringent time constraint in our system, and the data logging and transmission tasks will have to be completed during this time interval. Otherwise, it will be interrupted by the data acquisition task since it has the highest priority according to our setup to ensure we don’t miss any data. Then our novel classification service comes in handy as it enables the ECG to dynamically configure the number of active ECG lead in the acquisition service.

4.2. Data Transmission

Data transmission represents the main bottleneck of the proposed ECG patch, which is defined as the BLE communication link. The ECG patch uses the low power mode of the BLE stack instead of the classical BLE mode. Therefore, we designed our custom BLE profile to maximize communications and data handling between the ECG patch and smart devices (i.e., Smartphone or Smart Home devices).

Table 1. The Proposed BLE Profile for the ECG Patch Application: 12-Lead ECG service Attributes.

Handle	Type	Type	Hex/Text Value (Default)	GATT Server Permissions	Notes
0x10	0x2800	GATT_PRIMARY_ SERVICE_UUID	0 xBA55 (ECG_SERV_UUID)	GATT_PERMIT_READ	Start of ECG Profile Service
0x11	0x2803	ECG_PROFILE_ CHARACTER1_UUID	12 00 (handle: 0x0012)	GATT_ PERMIT_READ	Characteristic1 declaration
			AD 2B (UUID: 0x2BAD)
0x12	0x2BAD	FULL_ECG_12LEAD_UUID	00:00:00:00:00:00:00:00:00:00:00:00 (224 bytes)	GATT_PERMIT_READ|GATT_PERMIT_ NOTIFY	ECG data value
0x13	0x2902	GATT_CLIENT_CHAR_CFG_UUID	00:00 (2 bytes)	GATT_PERMIT_READ | GATT_ PERMIT_WRITE	BLE characteristic notifications enable/disable
0x14	0x2901	GATT_CHAR_USER_ DESC_UUID	“ECG Data Stream” (15 bytes)	GATT_PERMIT_READ	Characteristic1 user description
0x15	0x2803	ECG_PROFILE_ CHARACTER2_UUID	16 00 (handle: 0x0016)	GATT_ PERMIT_READ	Characteristic2 declaration
			AD 3B (UUID: 0x3BAD)
0x16	0x3BAD	ECG_NUM_CHANS	0x08 (1 byte)	GATT_PERMIT_READ	Number of ECG Channels
0x17	0x2901	GATT_CHAR_USER_ DESC_UUID	“Number of ECG Channels” (22 bytes)	GATT_PERMIT_READ	Characteristic2 user description
0x18	0x2803	ECG_PROFILE_ CHARACTER3_UUID	19 00 (handle: 0x0019)	GATT_ PERMIT_READ	Characteristic3 declaration
			CD 2B (UUID: 0x2BCD)
0x19	0x2BCD	ECG_STREAM_FLAG_ COMMAND	0x00 (1 byte)	GATT_PERMIT_READ|GATT_ PERMIT_WRITE	“01:00” to enable/”00:00” to disable
0x1A	0x2901	GATT_CHAR_USER_ DESC_UUID	“Stream Flag Status” (18 bytes)	GATT_PERMIT_READ	Characteristic3 user description

shows the attributes table of one of the ECG services available on the ECG patch; this service constitutes the continuous operation mode with 12-lead enabled. Services are shown in black; characteristics are bold, and characteristic values and descriptors are shown in grey.

The other two services, “triggered mode service” and “ECG classification service”, are designed similarly to the attributes in Table 1. Consequently, the combination of the three services allows our ECG patch to deliver a dynamic way of configuring the settings of the device in real-time as heart conditions develop. We leverage the new features introduced in BLE v5.2 over earlier versions of BLE (e.g., BLE v4.1). The first feature is the improved transmission rate (i.e., LE 2M PHY), allowing BLE 5.2 enabled devices to transfer data at a symbol rate of 2 Mbps. This means we can transmit each bit in half the time compared to earlier BLE PHY, which allows for a symbol rate of 1 Mbps. Moreover, the Data Length Extensions (DLE) [40] enable the packet to carry a significantly larger payload (Up to 251 bytes vs. 27 when disabled), introduced in BLE v4.2. The integration of DLE has increased the size of data sent in a single packet and reduced the number of the mandatory Interframe Space (IFS) delays (i.e., 150 μs) between each packet sent. Accordingly, the ECG patch can transmit more data in significantly less time.

5. Experimental Results and Discussions

This section presents the evaluation techniques and tests to verify and validate all the components in the XBeats platform. These include measurements about the operation modes, useful sampling rates, and energy consumption analysis concerning the hardware constraints. The hardware constraints in each of the following experiments are mainly related to the data acquisition time constraints, the quality and correctness of the acquired ECG signals, the accuracy of the classification algorithm, and the overall battery lifetime. The experiments are organized in the same order we presented the XBeats platform in terms of the functional components. Therefore, the first experiment evaluates the ECG data acquisition under different operation modes while running the data logging subroutine, followed by data transmission using BLE. Then, we assess the ECG data classification module, and, lastly, we determine the analytical energy consumption of the ECG patch over time. But, first, we explain the data sources used to conduct our experiments. The experimental setup consists of the following steps:

• Collect ECG data in real-time using the prototype hardware of the ECG patch. The experiment includes acquiring ECG data at different modes of operation: standard 12-Lead ECG data under the “continuous” mode of operation; one and three ECG leads under the triggered mode of operation; standard 12-lead ECG data under the offline mode of operation;
• Evaluate the effective ECG data sampling rate compared to the theoretical data acquisition values provided by the analog to digital converter. The evaluation is performed on each of the operation modes above;
• Evaluate the proposed ECG classification service implemented on an edge node. The evaluation steps include comparing the accuracy and processing time of six different techniques, which is concluded by the selected classification techniques for our edge classification service; and
• Calculate the power consumption footprint and the energy-saving of applying the triggered operation mode while activating the edge classification service.

5.1. Data Sources Description

We connect our ECG patch to the TechPatient CARDIO V4 heart simulator to collect ECG data to generate ECG datasets. This way, we avoid connecting the prototyped hardware to an actual patient. The simulator can generate real-time ECG waveforms for different cardiac conditions and support two modes of operation: ECG mode and Rhythmic mode. The ECG mode provides realistic 12-lead ECG waveforms. The rhythmic mode simulates 45 predefined arrhythmias or heart diseases, such as ventricular tachycardia and ventricular fibrillation. The device can be configured in 1 beat per minute (BPM) increments from 20 to 240 BPM and 2 BPM increments from 240 to 300 BPM in the ECG mode. Therefore, we created two datasets using the ECG Simulator: normal and abnormal ECG signals to test the XBeats platform.

On the other hand, we use a larger dataset (i.e., PTB-XL) for training and validating the developed classification algorithms and a dataset we created from the TechPatient CARDIO V4 heart simulator [41] as an external source of data for additional validation. The purpose of using the PTB-XL is to extend the developed classification model to cover a broader range of heart diseases and provide better accuracy. The PTB-XL dataset [38] provides a freely accessible ECG dataset of unprecedented size hosted by PhysioNet. The dataset comprises 21,837 clinical 12-lead ECG measured simultaneously, representing the conventional 12-lead ECG records. The length of each record is 10 s. The tests were performed on 18,885 subjects (52% were male, and 48% were female). The digitized signals are available at two sampling frequencies, 500 and 100 samples per second. Each record in the dataset has an attached header file describing each subject’s demographic information, health conditions, doctor’s comments, age, gender, diagnoses, number of records, number of samples, and the sampling rate. The records are categorized into five superclasses (NORM: normal ECG, CD: conduction disturbance, MI: myocardial infarction, HYP: hypertrophy, and STTC: ST/T changes) from which a 24-subclasses are derived, forming a multitude of diverse ECG data as a resource for ECG analysis algorithms. Accordingly, we aggregate all the abnormal signals (24 different abnormal heartbeat classes) into one category to make up a binary data set for normal and abnormal conditions. The size of the PTB-XL dataset makes it a valuable asset in machine learning and deep learning applications.

5.2. Data Acquisition and Data Transmission

In this section, we perform a sequence of experiments to validate the resultant sampling rate and the correctness of the digitized ECG data. Consequently, we connect the TechPatient CARDIO V4 heart simulator to the ADS1298 evaluation hardware. This step aims to create a benchmark for our ECG patch when evaluating the ECG patch while acquiring ECG data in real-time. We use the ADS1298 ECG frontend evaluation software built on top of LabVIEW libraries. The initial setup includes generating square signals using a square generator. Following that step, we start to capture the signals using the evaluation software using the ADS1298 development kit. Then use the ECG patch to collect the same signals and compare them to the benchmark signals collected by the evaluation software. In the second step, we use the evaluation software to collect ECG data through the ADS1298 development kit simulated directly from the TechPatient CARDIO V4 heart simulator, as shown in Figure 4. Then we compare collected ECG data by the evaluation software to the ECG data collected by the proposed ECG patch. The signals displayed in Figure 5 represent a full set of 12-lead for a standard ECG test, where Figure 5a shows the ECG limb leads, and Figure 5b shows the ECG chest leads. The data retrieval process was accomplished by selecting from two methods: Read Data Continuous (RDATAC) and Read Data (RDATA). The RDATAC method sets the device to continuously read data without sending any subsequent commands or further configuration. In contrast, the RDATA reads data output from the output register once triggered by the data-ready flag. After a successful data cycle, 216 bits of data are available to read from the output register. The 216 bits (27 bytes) are formatted as follows: 24 status bits + 24 bits of data per channel × 8 channels = 216 bits. The low power mode starts at 250 SPS, generating 6750 bytes every second, while the high-resolution mode starts at 500 SPS which generates 13.5 Kbytes every second.

Table 2. Collected ECG Data Size over Different Periods.

Sampling Rate Time Interval	250 SPS (Low-Power)	500 SPS (High-Resolution)
1 s	6.75 Kilobyte (KB)	13.5 KB
1 min	405 KB	810 KB
1 h	24.3 Megabyte (MB)	48.6 MB
24 h	583.2 MB	1.1664 Gigabyte (GB)

shows the size of the ECG data acquired and saved on the internal storage attached to the ECG patch. The digitized ECG signals are derived using the formulas illustrated in

Table 3. ECG 12-Lead Derivations.

Analog Input	Derived Lead	Polarity	Digitally Generated Leads
Channel 1	V6 = V6 − WCT	Unipolar	Lead III = Lead II − Lead I
Channel 2	Lead I = LA (1) – RA (2)	Bipolar	aVF = (Lead II + Lead III)/2
Channel 3	Lead II = LL (3) − RA	Bipolar	-aVR = (Lead I + Lead II)/2
Channel 4	V2 = V2 − WCT (*)	Unipolar	aVL = (Lead I − Lead III)/2
Channel 5	V3 = V3 − WCT (*)	Unipolar
Channel 6	V4 = V4 − WCT (*)	Unipolar
Channel 7	V5 = V5 − WCT (*)	Unipolar
Channel 8	V1 = V1 − WCT (*)	Unipolar

⁽*⁾ WCT = (LA + RA + LL)/3, WCT: Wilson Center Terminal. ⁽¹⁾ LA: Left Arm Electrode. ⁽²⁾ RA: Right Arm Electrode. ⁽³⁾ Left Leg Electrode.

.

Following the benchmark setup, we evaluate the ECG patch prototype by applying the same configurations used in the benchmark experiment. The ADS1298 chip on the ECG prototype applies the RDATAC methods to collect ECG data continuously at a default sampling rate of 500 SPS. This setup is fixed during the whole experiment. We run the experiment four times under different operation modes, as shown in

Table 4. The useful sampling rate of the XBeats prototype over various operation modes.

Operation Mode	Number of Channels	Number of ECG Leads	# Samples/ BLE Packet	Payload/ BLE Packet	Acquisition Rate
Offline	8	12	N/A	N/A	480 SPS
Disconnected Mode	8	12	N/A	N/A	370 SPS
Continuous Mode	8	12	7	8 (CH) × 4 (Bytes) × 7 (Samples) = 224 Bytes	343 SPS
Triggered Mode-1	1	1 (i.e., Lead II)	56	1 × 4 × 56 = 224 Bytes	441 SPS
Triggered Mode-2	2	3 (i.e., Leads I, II, and aVF)	28	3 × 4 × 28 = 224 Bytes	441 SPS

. The evaluation criterion is based on the resultant data rate of our ECG prototype, which varies according to the selected operation mode. The first operation mode evaluated is the “offline mode”, in this operation mode, the wireless communication module (i.e., BLE) is switched off completely. The ECG patch is programmed to enable the 12-lead ECG acquisition in the “offline mode” or the “disconnected mode”. We allow this feature to guarantee that the ECG patch doesn’t miss any vital information about the heart conditions during disconnectivity. The resultant ECG data acquisition rate in the “offline mode” is 480 SPS. In contrast, the” Disconnected mode” provided a resulting sampling rate of 370 SPS. The observations from this experiment noted that the communication module on the ECG patch enters the advertising mode [42]. A BLE device uses advertisements to broadcast packets to BLE-enabled devices around it. Then the receiving devices can act on this information or connect to receive more information. When the BLE module on the ECG patch is in advertising mode, advertising packets are sent periodically on each advertising channel to update the presence of the ECG patch to the surrounding devices until it matches with a paired BLE device and establishes a new connection. This operation adds an overhead to the data acquisition task and, thus, the reduced sampling rate.

The second patch of tests includes the operation modes that rely on the BLE wireless connectivity to transfer the acquired ECG data to the paired BLE-enabled mobile device. This experiment requires a BLE-enabled mobile device to run our customized mobile application. We use the Google Pixel 3 smartphone to install our ECG patch mobile application. The smartphone supports the latest BLE v5.2 that allows our application to utilize the Data Length Extensions, and the LE 2M PHY features provided by BLE v5.2. Our mobile application automatically sets the physical layer to the 2 MB/s physical configurations and updates the maximum payload to 251 bytes. The payload of one successful BLE packet at the “continuous mode” contains seven samples, where each sample carries values from the digitized channels. We encapsulate the 24 bits received for each channel into an unsigned integer object. The total payload size inside on BLE packet applies the following formula: $Number of Channels\times Object Size\times Number of samples$. Consequently, we evaluate the “continuous mode” on the ECG patch prototype and display the streamed ECG in real-time, as shown in Figure 6a,b. The displayed ECG leads are computed similarly using the leads derivation in Table 3. The useful acquisition rate at the “continuous mode” is 343 SPS. Likewise, we apply the same setup on the “triggered mode” with one and three lead configurations. The observed useful data acquisition rate at both operation modes configurations was the same (i.e., 441 SPS).

We noticed some noise and outliers in the ECG singles acquired by our ECG patch prototype, as shown in Figure 6b,c, while operating in the “continuous mode” and “triggered mode”. We found that the primary source of noise and outliers is a result of sudden movements and motion artifacts on the wires connecting the electrodes to the ECG patch prototype.

5.3. Signal Detection and Classification

The signal detection and classification represent one of the novel integrations of this work as it enables the dynamic configurations of operation modes in real-time. Moreover, it provides an additional safeguard to the ECG monitoring platform as we bring the classification closer to the patient. This feature is considered the first step of a two-phase ECG data classification of the ECG monitoring platform. The binary classification module provides a faster response by classifying the ECG data to normal heartbeat or irregular heartbeats. The second phase includes deep analytics functions deployed at the backend level, where we perform and build a correlation between real-time and historical data for better analysis and predictions. To that extent, we use the real-time ECG dataset acquired from the simulator using the proposed ECG patch to evaluate the performance of our classification algorithm. In contrast, we use the PTB-XL datasets for training the proposed classification module. The dataset is split into training and testing sets at an 80% to 20% ratio. To select the best classifier for our application, we compare six different algorithms, namely, random forest (RF), support vector machine (SVM), K-nearest neighbors (KNN), Decision tree (DT), logistic regression (LR), and Extra Trees Classifier, which is the ensemble learning method of the decision trees method as recommended by [39].

The main objective of our model is to achieve the best accuracy with the minimum processing time to fit the constraints of our hardware system. We calculate the F1-score (F1), Precision, Recall, overall accuracy, and the processing time to fit the trained model of each classification technique. The training set performance is calculated using a K-fold cross-validation splitting strategy with 10 folds. The results are collected using only 5 features from the top 5 to minimize our processing time, as shown in

Table 5. The top 5 informative features used to classify the ECG signals.

Rank	Feature	Definition
1	RR0/avgRR	The current R-R interval divided by the average of the last 32 beats
2	RR+1/RR0	The next R-R interval divided by the current R-R interval
3	RR-1/RR0	The previous R-R interval divided by the current R-R interval
4	RR+1/avgRR	The next R-R interval divided by the average of the last 32 beats
5	hbf_3	The coefficients of fitting Hermite basis functions with polynomials degree = 3

. We used Python and Scikit-learn for implementation. The results in

Table 6. The six classification techniques accuracy and processing time.

	RF	SVM	KNN	LR	DT	Extra Trees
Accuracy	95.20%	94.19%	94.05%	93.60%	91.56%	95.30%
Processing Time	44.54 s	89.13 s	1.84 s	0.857 s	3.98 s	5.78 s

compare the 6 algorithms from the accuracy and time perspectives. We observe that the Extra Trees Classifier achieves the best combination of accuracy and time with the highest accuracy of 95.3% and only 5.78 s to classify the ECG signal. Logistic regression performs the best processing time with 0.857 s but with an accuracy of 93.6%, which is considered the lowest accuracy out of all classifiers. Worth noting, the processing time in Table 6 represents the overall processing time of the corresponding algorithm over the selected dataset. The following experiment evaluates the actual time when implementing the best algorithm in real-time on an edge device.

Table 7. Performance report obtained from the six classification techniques for normal and abnormal ECG signals.

		RF	SVM	KNN	LR	DT	Extra Trees
N	Precision	96.11%	95.26%	96.64%	94.73%	95.75%	96.17%
	Recall	98.27%	98.38%	96.68%	98.27%	94.73%	98.63%
	Fl-score	97.19%	96.79%	96.66%	96.47%	95.23%	97.38%
ABN	Precision	83.33%	82.06%	72.98%	79.87%	60.61%	85.96%
	Recall	70.31%	60.30%	72.73%	55.60%	65.85%	68.13%
	Fl-score	76.27%	69.51%	72.86%	65.56%	63.12%	77.03%

shows the performance details obtained from the test dataset for the normal signals (N) and abnormal signals (ABN). We observe that almost all the best values result from the Extra Trees classifier, which concludes that it’s the best model to adopt in our system. Furthermore, we investigate the accuracy of the Extra Trees classifier with the number of features, as shown in Figure 7a. It can be observed that the highest performance is accomplished with only 5 features (accuracy = 95.30%), and after that, the accuracy decreases with the growth of the number of features.

We deploy the classification module on a Raspberry Pi 3 B+ board acting as an edge device. MQTT is the underlying communication protocol between our mobile application and the edge device. The mobile application is designed to publish the ECG data in patches every second. This is another system design decision that can be changed to alternative options with 5 or 10 s intervals. Therefore, the integration of the MQTT protocol provided a pipeline for our mobile application to publish the ECG signals collected by the ECG patch in 0.12 s. The edge device continuously receives ECG data until an abnormal heartbeat is detected; the system simultaneously sends the signal to different services to alert caregivers and/or healthcare providers. Figure 7b shows a screenshot of an SMS message sent to alert the healthcare provider of irregular heartbeats as part of the notification service provided by the proposed platform. The average processing time for the ECG signal detection is 0.29 s. If an abnormal heart condition is detected, a message is sent out immediately to caregivers in a range of 0.57 to 0.77 s, which is quick enough for healthcare providers to take necessary actions.

5.4. Energy Consumption

The current hardware design used in the prototype includes some development boards and is not yet optimized for compact design and final commercial production. Therefore, we use the Energy Trace tool to determine the analytical energy consumption of the ECG patch over time. We use the Energy trace tool in the free-run mode, where the sampling frequency is approximately 4.2 kHz. We performed analytical tests on the ECG prototype, where the device is assumed to be in the “continuous” operation mode. The test includes acquiring the full 12-lead ECG data and transmitting the data over BLE in real-time to a smartphone. This means the MCU is always in an active mode, and no power-saving protocols are applied other than the default settings on the MCU. Consequently, the analytical results show that the ECG patch can deliver a continuous real-time 12-lead ECG for 37 h approximately using a rechargeable lithium-ion battery with a capacity of 2000 mAh; details are shown in

Table 8. Analytical power consumption of the ECG patch hardware prototype.

Power Consumption Results	Value
Mean, Min, and Max	157.73 mW, 91.69 mW, and 364.133 mW
Average voltage	3.3 V
Battery Capacity	2000 mAh
Total Operation time	1 Day, 13 h approximately

.

6. Conclusions

Although the ECG test is a 100-year-old technology, it remains scientifically challenging and attractive to research to unleash the full potential of information technology and IoT in this domain. We demonstrate the need for a compact wearable ECG monitoring system from the literature. We introduce XBeats a novel platform for continuous real-time monitoring. The ECG patch prototype proposed XBeats supports dynamic modes of operations that are actively configured when the heart conditions of the patient change. The device carries out all primary operations: data acquisition, logging, and transmission at an acquisition rate of up to 441 samples per second with significantly low latency. The proposed platform integrates an on-chip binary ECG signal classification implemented on edge devices. The classification algorithm achieved a maximum detection accuracy of 95.30% based on the Extra Trees machine learning classifier. This accuracy is accepted in our proposed platform as an initial phase of classification to support in-time notifications to the patient/healthcare providers. Our system demonstrates exemplary performance and can send immediate messages to patients or healthcare providers when irregular heartbeats are detected. It can also support long-term medical diagnosis for ECG signals in real-time. The results achieved in the prototype development allow us to conclude that high-quality real-time remote 12-lead ECG monitoring is achievable through our robust platform design and selected hardware components. As a future direction, we plan to integrate high-performance streaming engines at the backend like Kafka or NATS. Additional future work includes extending the binary classification module to further analyze the abnormal class severity. We also consider modifying the classification technique to work with aggregated ECG data in real-time as they arrive with predefined windows for the aggregation process. The platform shall avoid false positives regarding the patient’s heart conditions when classifying the heartbeats individually. Moreover, the system can be configured to call emergency response in extreme cases when the patient is at imminent risk or irresponsive.