Submitted Successfully!
To reward your contribution, here is a gift for you: A free trial for our video production service.
Thank you for your contribution! You can also upload a video entry or images related to this topic.
Version Summary Created by Modification Content Size Created at Operation
1 Heart Health Monitoring Service Platform is a concept that allows medical device manufacturers to offer diagnosis support for a range of diseases to healthcare providers. + 2229 word(s) 2229 2020-09-02 07:53:15 |
2 format change + 1 word(s) 2230 2020-09-09 03:57:29 |

Video Upload Options

Do you have a full video?


Are you sure to Delete?
If you have any further questions, please contact Encyclopedia Editorial Office.
Faust, O.; Lei, N.; Chew, E.; Ciaccio, E.J.; Acharya, U.R. Heart Health Monitoring Service Platform. Encyclopedia. Available online: (accessed on 17 June 2024).
Faust O, Lei N, Chew E, Ciaccio EJ, Acharya UR. Heart Health Monitoring Service Platform. Encyclopedia. Available at: Accessed June 17, 2024.
Faust, Oliver, Ningrong Lei, Eng Chew, Edward J. Ciaccio, U Rajendra Acharya. "Heart Health Monitoring Service Platform" Encyclopedia, (accessed June 17, 2024).
Faust, O., Lei, N., Chew, E., Ciaccio, E.J., & Acharya, U.R. (2020, September 07). Heart Health Monitoring Service Platform. In Encyclopedia.
Faust, Oliver, et al. "Heart Health Monitoring Service Platform." Encyclopedia. Web. 07 September, 2020.
Heart Health Monitoring Service Platform

Heart Health Monitoring Service Platform is a concept that allows medical device manufacturers to offer diagnosis support for a range of diseases to healthcare providers. The proposed platform is based on heart rate monitoring and the diagnosis support is achieved with deep learning. 

Platform Heart rate Computer aided diagnosis Deep learning Atrial fibrillation Stroke Cardiovascular disease Diabetes

To address this need, we put forward the idea that the combination of Heart Rate (HR) measurements, Internet of Things (IoT), and advanced Artificial Intelligence (AI), forms a Heart Health Monitoring Service Platform (HHMSP). This service platform can be used for multi-disease monitoring, where a distinct service meets the needs of patients having a specific disease. The service functionality is realized by combining common and distinct modules. This forms the technological basis which facilitates a hybrid diagnosis process where machines and practitioners work cooperatively to improve outcomes for patients.

1. Introduction

Figure 1 shows an overview diagram of the proposed service platform. The cloud server, at the center, incorporates the machine classification functionality. We envision that, for routine disease monitoring tasks, the data interpretation is done by machine classification, and human experts just validate the machine decisions. This hybrid approach, where machines and humans work together cooperatively, improves cost efficiency while maintaining the safety and reliability of the diagnosis. With respect to cost, the HHMSP harvests the economies of scale with common modules that implement an IoT infrastructure. These modules handle the data communication from the point of measurement to a central storage location. Distinct modules facilitate both decision-making processes and the resultant dissemination. The concept of common and distinct modules makes the HHMSP sufficiently agile to cope with future requirements.

Figure 1. Overview diagram of the Heart Health Monitoring Service Platform (HHMSP).

2. System Architecture

The HHMSP allows us to frame the health monitoring problem in a business environment which demands cost-effective solutions. Furthermore, the business centric framing mandates that the healthcare provider becomes a customer who uses a service to improve disease diagnosis or disease monitoring. The healthcare provider registers a patient with a service, which is tailored for an individual disease. For example, a cardiologist registers a patient with the AF monitoring service. That service will provide diagnosis and treatment support.

The HHMSP architecture was designed such that it incorporates HR measurement, IoT for data distribution, cloud servers for storage and advanced Artificial Intelligence (AI) for data interpretation. The block diagram, shown in Figure 2, provides a graphical representation of the proposed HHMSP architecture.

Figure 2. Heart Health Monitoring Service Platform (HHMSP) architecture. The common modules are in orange and the distinct modules are in blue. Abbreviations in the figure: Cardiovascular Disease (CVD), Atrial Fibrillation (AF), and Graphical User Interface (GUI).

Implementing the platform architecture establishes the service functionality, which can be described as follows: The healthcare provider purchases a specific diagnosis support service (The specific service offering will depend on the service provider business model and on regulatory requirements.). At the clinic, a patient is fitted with a HR sensor and registered with the service platform (DB module). The patient wears the sensor which communicates the measurement data to a data acquisition module. That module relays that data to an IoT cloud server. Once on the cloud server, the HR data can be used for diagnosis support. The deep learning module queries the data from the cloud and extracts relevant information with a disease specific model. The alarm module informs the physician if the DL results meet a specific condition, for example a disease is detected. Once alerted, the medical expert can use the physician support module to interact with both the DL result and raw HR data during the diagnostic process. Having two cascaded decision processes, where a DL algorithm provides an initial assessment and a human practitioner reaches a diagnosis, improves the safety when compared to each individual decision system. The feedback module can be used to disseminate rapid response warnings when an immediate health risk was detected, and it can be used for patient compliance, i.e., a request to wear the sensor. A diagnosis should be communicated via the standard channels established by the healthcare provider. The following sections describe both common and distinct modules of the proposed HHMSP. To illustrate the platform functionality, we discuss the details and state performance results from an AF monitoring service.

2.1. DB Module

The DB module incorporates a Database (DB) which holds patient information. Necessary fields are: Patient ID, disease type, assigned physician, cloud server login key, service start date, service end date. For the HHMSP, the disease type can be sleep disorders, CVD, diabetes or AF. Optional fields are: Patient name and detailed feedback. The feedback could be a list of healthcare instructions for the patient. At the start of the service subscription, the caregiver registers the patient with the DB module. In response, the DB module will provide the cloud server login key. That login key is used to set up the data acquisition module, as described in the next section.

2.2. Data Acquisition Module

The measurement setup is straight forward. The patient wears a breast strap with an embedded HR sensor. The sensor picks up the electrical activity which indicates the human heartbeat, known as the R peak. The time between two consecutive R peaks is measured and the resulting value is communicated to the mobile phone as the RR interval. A stream of RR intervals is referred to as HR signal. We tested our system with two commercially available sensors, namely Polar H10 and Polar H7 ( Low power Bluetooth is used to transfer the data from the HR sensor to an Android smartphone or tablet.

The heart health app relays the sensor information to the IoT cloud server. The data exchange with the IoT cloud server is facilitated by an Internet connection. Figure 3 shows a screen shot of the heart health app, which was created by extending the BLEConnect program ( The background shows an averaged HR trace. The dialogue in the foreground requests the user to enter the login data for the IoT server. Each user has a unique cloud server login key. Both the patient and authorized caregivers can access the patient’s data using the same cloud server login key, which is stored in the DB module.

Figure 3. Screen shot of the heart health app which relays the sensor data to the cloud server.

2.3. Cloud Server

We have used ThingSpeak from Mathworks ( as cloud server. To test the HHMSP, two accounts were created with test data from PhysioNet’s AFDB and two accounts were set up with measured data. Each account has two channels. The first channel, which is called RR_interval_data, holds the measurement data. The content is updated when the heart health app relays the HR signals. The second channel, which is called AF_detection_result, holds the machine classification results. The result channel content is updated when the machine classification system produces a new result.

2.4. Deep Learning Module

The deep learning module reads new entries from the RR_interval_data channel and writes the classification outcomes to the AF_detection_result channel. The DL system was used because of its ability to detect the disease based on hidden information present in the HR signals. As such, DL does not require feature engineering. This is a significant improvement compared to conventional machine learning algorithms[1]. The absence of feature engineering makes DL robust when it classifies samples from a larger data set. In a clinical setting, this robustness translates to high-quality diagnostic support for patients using HR signals. Each disease requires a distinct DL model. Based on information from the DB module (disease type), the deep learning module selects the appropriate model for the HR to be analyzed.

The AF module was created by training the DL system using labeled HR data obtained from PhysioNet’s AFDB ( Based on data from 20 subjects, the system achieved an accuracy of 98.51% with 10-fold cross-validation[2]. The blindfold classification performance, with 99.77% accuracy, indicates that the model is able to deliver high quality diagnostic support for patients using HR signals.

2.5. Alert Module

The alert module prompts the physician to use the assigned physician support module. That prompt is triggered when a specific condition is reached, usually when a disease is detected. Sending the alert message can be facilitated with a range of communication channels, such as e-mail, Twitter, and instant messaging.

For the AF monitoring service, the alert module is implemented on ThingSpeak. A monitor program checks every DL result on the AF_detection_result channel. If the estimated AF probability is above 0.5, the monitor program will send an alert message to the assigned physician via Twitter and SMS.

2.6. Physician Support Module

The assigned physician has access to the HR data and DL diagnostic support through the HHMSP. As such, HR signals are complex and their waveform resembles noise. Therefore, disease detection, with the naked eye, is inefficient and error prone. Algorithm support is needed to extract relevant information from the signal. The HHMSP physician support module incorporates algorithm support in the form of DL results and features. The use case scenario for the module unfolds as follows. The assigned physician receives an alert from the alert module with information about the patient condition. Figure 1 shows an example where the physician received an alert message, because the DL system detected an AF episode in the HR signal from one of the patients. By using the physician support module, the assigned physician confirms or rejects the DL assessment and establishes a diagnosis[3]. Then the diagnosis will be communicated to the patient and other stakeholders via the feedback module, as discussed in the next section.

Figure 4 shows a screenshot of the prototype HHMSP physician support module with the AF GUI. This module was developed by extending the Heart Rate Variability Analysis Software (HRVAS) ( The drop-down list allows the assigned physician to select a patient based on the patient ID, as provided by the DB module. The left-hand side of the figure visualizes the automated decision support from the deep learning module. The right-hand side shows the HRV signal features which were designed to help the assigned physician to validate the DL results.

Figure 4. Physician support with the modified Heart Rate Variability Analysis Software (HRVAS) program.

In the example, shown in Figure 4, the patient with ID 08455 was selected, because of an alert message. After pressing ”Fetch Data” the DL results are displayed as estimated AF probability over time, in the upper left corner of the figure. In the timeline, the assigned physician can select a region of interest. Once the region is identified, the support tool fetches the corresponding HR signal segment and calculates a wide range of features from that segment. The feature extraction results are displayed on the right side. Figure 4 shows the selected region of interest as a light red square in the timeline plot. The square area encompasses a spike in estimated AF probability and a step edge. The estimated AF probability is reflected in the color scheme of the HR graph shown in the lower left corner. The color bar maps the estimated AF probability to a specific color, for example a low probability is blue and a high probability is red. The small red region in the HR graph reflects the spike. Similarly, the red region on the right of the HR graph reflects the step edge. The Poincaré plot[4], as well as features SD1 and SD2, for the selected HR signal segment are displayed on the right side of Figure 4.

2.7. Feedback Module

Once the assigned physician has reached a diagnosis, the feedback module is used to communicate with the patient. Social media, e-mail and personal phone calls can be used to provide feedback. One way of providing feedback is with a simple traffic light system: Green—all is well. Yellow—take predetermined precautionary action. Red—see your physician immediately.

2.8. Testing

The HHMSP was tested with the AF monitoring service. By doing that, we tested all common modules for data handling and the specific modules which establish diagnostic support. To verify all aspects of the AF monitoring service, we registered two healthy volunteers with the DB module. Subsequently the volunteers were fitted with HR sensors and their data was communicated and processed by the HHMSP. To be specific, their data was processed with the deep learning module which executed the AF specific DL model. However, the DL results were not verified by a cardiologist. Therefore, no diagnosis was established and the results have only an indicative character.

To validate both deep learning and physician support modules for the AF monitoring service, we streamed benchmark data from PhysioNet’s MIT-BIH Atrial Fibrillation Database[5] to the data acquisition module. Figure 4 shows a screenshot of the physician support module which details both DL and feature extraction results for the benchmark data. Apart from visual inspection, enabled by the physician support module, we also compared the deep learning module results for the benchmark data with the results for the same benchmark data obtained by a previous study on the automated detection of atrial fibrillation using a long short-term memory network with RR interval signals[2]. In that study, we used the same model as in the deep learning module. We established that the DL results were the same. With that, we could validate both data acquisition and deep learning modules. Furthermore, that validation confirmed that the AF monitoring service achieved 99.77% accuracy with benchmark data.


  1. Oliver Faust; Yuki Hagiwara; Tan Jen Hong; Oh Shu Lih; U. Rajendra Acharrya; Deep learning for healthcare applications based on physiological signals: A review. Computer Methods and Programs in Biomedicine 2018, 161, 1-13, 10.1016/j.cmpb.2018.04.005.
  2. Oliver Faust; Alex Shenfield; Murtadha Kareem; Tan Ru San; Hamido Fujita; U. Rajendra Acharrya; Automated detection of atrial fibrillation using long short-term memory network with RR interval signals. Computers in Biology and Medicine 2018, 102, 327-335, 10.1016/j.compbiomed.2018.07.001.
  3. Oliver Faust; Edward J. Ciaccio; Arshad Majid; U. Rajendra Acharya; Improving the safety of atrial fibrillation monitoring systems through human verification. Safety Science 2019, 118, 881-886, 10.1016/j.ssci.2019.05.013.
  4. U. Rajendra Acharrya; Oliver Faust; Vinitha Sree; G. Swapna; Roshan Joy Martis; Nahrizul Adib Kadri; Jasjit S. Suri; Linear and nonlinear analysis of normal and CAD-affected heart rate signals. Computer Methods and Programs in Biomedicine 2014, 113, 55-68, 10.1016/j.cmpb.2013.08.017.
  5. Moody, G.; A new method for detecting atrial fibrillation using RR intervals. Comput. Cardiol. 1983, 10, 227–230.
Contributors MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to : , , , ,
View Times: 602
Revisions: 2 times (View History)
Update Date: 17 Feb 2021
Video Production Service