A priority queue-based telemonitoring system for automatic diagnosis of heart diseases in integrated fog computing environments

Abstract

Various studies have shown the benefits of using distributed fog computing for healthcare systems. The new pattern of fog and edge computing reduces latency for data processing compared to cloud computing. Nevertheless, the proposed fog models still have many limitations in improving system performance and patients’ response time.

This paper, proposes a new performance model by integrating fog computing, priority queues and certainty theory into the Edge computing devices and validating it by analyzing heart disease patients' conditions in clinical decision support systems (CDSS). In this model, a Certainty Factor (CF) value is assigned to each symptom of heart disease. When one or more symptoms show an abnormal value, the patient’s condition will be evaluated using CF values in the fog layer. In the fog layer, requests are categorized in different priority queues before arriving into the system. The results demonstrate that network usage, latency, and response time of patients’ requests are respectively improved by 25.55%, 42.92%, and 34.28% compared to the cloud model. Prioritizing patient requests with respect to CF values in the CDSS provides higher system Quality of Service (QoS) and patients’ response time.

Introduction

Recent developments in Information Technology solutions have led to using them broadly in precise health monitoring and treatment systems. ¹ Remote patient monitoring (RPM) is the use of digital technologies to monitor and collect patient health data. ² RPM systems are used to diagnose medical emergencies, the severity of the patient’s condition, and effective response time to perform medical procedures.^3,4 Internet of things (IoT) has been widely used to join existing medical resources and has provided credible, effective, and intelligent health care services to patients. ⁵

Nevertheless, things in the IoT have limited power, storage, and computing capabilities. In this way, cloud computing promises several benefits to deliver cost‐effective services. It provides scalable management of virtual storage, processing, and network resources on the Internet and enables ubiquitous data access. Despite the many benefits, responding to latency-dependent and urgent health monitoring and surveillance systems requests is challenging. The main reason for such latency-sensitive applications is the need to perform a huge amount of calculations on large volumes of data and transfer them to a centralized database in data centers. ⁶

Introduced by CISCO in 2012, fog computing ⁷ has been widely used in the healthcare industry to provide services to applications with urgent response and minimal service delays. Based on predefined policies in this computing model, part of the data collected by the sensors is processed in endpoint IoT devices and the remaining part is sent to the cloud for processing. Fog computing regulates which information should be sent to the cloud server and processed locally. In other words, fog computing as a virtual platform is embedded at the edge of the network, and data processing, storage, and network-based services are moved near to IoT devices instead of data centers. ⁸ Low latency services and reduced bandwidth traffic are the main benefits of fog computing. Therefore, fog computing can effectively cope with problems such as interruptions, delays, and even network breakdowns that can have unpleasant consequences for patients’ health in remote health care services. In this way, Clinical decision support systems (DSSs) as interactive information systems can effectively scale to the growth and development of IoT services and data explosion. Nowadays, CDSSs are widely used to predict and diagnose acute clinical conditions based on the data collected by sensors and remote health monitoring devices. These architectures allow real-time analysis of data with minimal latency and response time. ⁹ Using fog computing capabilities to implement CDSSs can overcome the lack of awareness, mobility support, and low latency that are existed in the architecture of cloud-based DSS systems. ⁵

Problem statement

In the current fog models, a mass of data is sent to the cloud server and an important portion of this data contains the vital patients’ health information, which must be processed timely. Moreover, there is no difference between emergency requests and non-emergency requests in receiving services from the cloud server in most such models.

Research questions

- Can the use of priority queues in the fog layer lead to improved response time in fog computing compared to cloud computing?

- Can priority queues reduce network usage time in fog computing compared to cloud computing?

- Can priority queues reduce latency in fog computing compared to cloud computing?

The key contributions

In this paper, a real-time RPM is presented to continuously monitor and diagnose patients’ health conditions based on the received data from sensors. To increase the efficiency of the proposed system, an innovative model is proposed to classify requests in CDSS based on their priority for receiving the service. According to this model, requests detected as urgent will attain a higher priority for sending to the cloud server. So far, however, there has been little discussion about prioritizing patients’ requests in real-time RPM.

Related work

Hassan et al. ¹⁰ presented a home hospitalization system based on IoT, fog computing, and cloud computing. The system allows to manage and monitor the patient’s health vital signs. Azimi et al. ¹¹ proposed a hierarchical architecture called HiCH is based on fog computing and machine learning for health monitoring. HiCH used the fog and cloud. HiCH efficacy has been evaluated through a comprehensive performance assessment with focusing on arrhythmia detection for patients with cardiovascular disease (CVDs).

In, ⁶ a framework called HealthFog is proposed to integrate deep learning in Edge computing devices for automated analysis of heart disease. HealthFog was evaluated for power consumption, network bandwidth, latency, jitter, accuracy, and execution time to deploy and test the performance of the proposed model. He et al. ¹² developed an IoT-based healthcare model called FogCepCare to assess patient health. In this model, partitioning and clustering methods and parallel processing techniques have been used to optimize execution time. FogCepCare performance was compared to the cloud environment in terms of execution time as an optimization parameter. Barik et al. ¹³ presented an in-home monitoring system for diagnosing diabetes using k-means clustering methods and deep neural network data on River Ganga Basin geospatial database. Azimi et al. ¹⁴ investigated the possibility of using the convolutional neural network (CNN) classification model as an example of deep learning methods in the fog computing architecture. In this study, a system for monitoring patients’ health using ECG classification is presented. Pham et al. ¹⁵ presented a cloud-based smart home environment, which uses wearable sensors to collect physiological, motor, and acoustic data to periodically monitor patients’ health status. In this study, patients’ daily activities, as well as their behavioral changes, are examined.

Sahoo et al. ¹⁶ proposed a parallel semi-naive bayes (PSNB) based probabilistic method that is used to process large volumes of multi-structured and low-latency patient data in healthcare for future health condition prediction. The optimal data distribution (ODD) algorithm is used to determine the patients’ priorities. Abdelmoneem et al. ¹⁷ introduced a task scheduling and allocation mechanism for cloud-fog based architecture (CFBA) for IoT-based healthcare to monitor the health status of patients. This mechanism performs the task of distributing health care tasks efficiently. Performance evaluation of CBFA was performed based on latency parameters using the iFogSim tool. Gia et al. ¹⁸ developed a health monitoring system that performs continuous remote monitoring of the ECG with automated analysis and notification. ECG sensor nodes collect and transmit respiration rate and body temperature. In addition, the system can analyze the collected data in useful ways to make decisions and, if necessary, send real-time notifications for immediate attention. Gill et al. ¹⁹ proposed an IoT-based cloud computing model for healthcare to effectively manage patients’ heart data. In this model, patients’ status is examined to identify and diagnose heart disease through requests sent by users. The iFogSim toolkit was used to evaluate the proposed model. Mutlag et al. ⁹ have developed an electronic health system based on fog calculations for monitoring the health of the elderly. In this system, a mobile application such as the fog node is responsible for periodically collecting patients' physiological parameters. This system enables to monitor the patient’s health remotely and in real-time.

Muhammed et al. ²⁰ proposed a healthcare framework called UbeHealth. This study leverages edge computing, deep learning, big data, high-performance computing (HPC), and the IoT to address many challenges that hinder networked healthcare domains. In this study, several algorithms have been used in the form of three layers and two components to predict network traffic to optimize data rates, data storage, and routing decisions. Asif-Ur-Rahman et al. ²¹ introduced a heterogeneous cloud-based IoHT communication framework by combining the mist and fog computing in which the routing process for real-time and conventional data is performed separately. The latency criterion has been evaluated to ensure the QoS of the proposed framework. Karakaya et al. ²² proposed a light and safe fog-based IoT model to report results to the technical team and physicians by analyzing health and tactical information on exercise. This study investigates a fog-based intelligent DSS health care system to automatically diagnose heart patients’ health status based on the nature of patients’ requests.

Methodology

Our goal in this study is to introduce an RPM system for heart patients. This system focuses on the early detection of complications that can lead to heart problems in patients. In this study, an end-to-end solution is presented based on a patient health monitoring system. This system aims to help the healthcare team by early detection and continuous monitoring of the patient’s condition and alerting the patient’s suspicious condition. Figure 1 shows the data flow in the proposed model. The model consists of three main parts, including the data layer, fog layer, and cloud layer.

- The data collection layer gathers patients’ data sent from sensors of the body area network (BAN) in real-time and sends it to the fog layer.

- The fog layer stores and evaluates the sensors’ data in a local storage. The data is compared with the normal values ranges (thresholds) predetermined by physicians. If the threshold is violated, the data is sent to the cloud for further evaluation. In the proposed model, requests are prioritized in the fog layer in order to be submitted to the cloud server for CDSS evaluation based on their class (emergency, warning, or normal).

- Requests are evaluated to determine the patient’s condition at this layer. The results of the CDSS evaluation are considered as the patient’s condition and if the patient is in a critical or emergency situation, the physician and treatment team, family, and the patient will be informed.

Figure 1.

Proposed model architecture.

This study uses Raspberry Pi capabilities as a fog node to receive and process sensors data. The Raspberry Pi board is an embedded minicomputer and is very useful in IoT projects. Table 1 represents the specification of the fog node in this study.

Table 1.

Configuration details of fog node.

Device type	CPU, GHz	RAM (GB)	Bluetooth	Wi-Fi
Raspberry PI 3 B+	1.4	1GB LPDDR2 SDRAM	4.2, BLE	2.4 GHz and 5 GHz IEEE 802.11b/g/n/ac wireless LAN

Data preprocessing

Based on the proposed model in Figure 1, the data sent by the sensors is considered as request demands. Each request demand includes various vital signs of the patient that are sent to the fog node. For each symptom different ranges including normal, high, very high, low, and very low are defined by medical professionals. Table 2 shows typical ranges defined by expert physicians according to the importance and level of risks for the patients. This quantification is based on certainty factors (CF) and the effective ratio of each symptom (Table 4) in heart disease. ²³

Table 2.

CF value interpretation.

Uncertain term	CF
Definitely not	−1.0
Almost certainly not	−0.8
Probably not	−0.6
Maybe not	−0.4
Unknown	−2∼2
Maybe	0.4
Probably	0.6
Almost certainly	0.8
Definitely	1.0

Certainty factors is a technique for uncertainty in expert systems and expresses the level of belief in an event, a fact, or a hypothesis using expert assessment. ²⁴ The CF model has become a standard way to manage uncertainty in rule-based systems. CF theory is an alternative to Bayesian reasoning when reliable statistical information is not available or the independence of evidence cannot be assumed. This theory introduces a certainty factors calculus based on human expert heuristics. According to this approach, as shown in Table 2, uncertain statements are mapped to a CF number between 1 and −1, which indicates the degree of belief in a statement. A certainty factor of −1 would represent a complete lack of belief in something while a factor of 1 would represent an absolute belief in a rule or value.

For example, in the sentence “it will probably rain today”, CF (E) = CF (it will probably rain today) = 0.6. This approach replaces the more formal probability P (E) with CF (E).

Since the effective symptoms in the diagnosis of heart disease have been used, the range of [0–1] has been used for mapping to the CF number. According to Table 2 and based on the symptoms of heart disease and the opinion of medical experts, Table 3 is prepared to evaluate the symptoms of heart disease. When one or more symptoms of a request are outside the normal range, the request will be weighted using Table 3 for prioritization. CF values will be awarded to all ranges of each symptom by physicians using Table 3. This CF value indicates the effect of the measured value of each symptom on heart disease. For example, CF value for the very high and very low ranges of the blood pressure symptom is 0.89 and 0.55, respectively. High blood pressure is one of the most important risk factors for CVD and is the leading cause of mortality. ²⁵

Table 3.

CF values of abnormal symptoms. ²⁴

Symptoms range	CF value
Very low	0.4 to 1
Low	$\epsilon$ to 0.4
Normal	0
High	$\epsilon$ to 0.4
Very high	0.4 to 1.0

When a request i is sent to the fog node, all k abnormal symptoms are aggregated according to equation (1).

${\mathrm{w}}_{\mathrm{i}}={\displaystyle \sum }_{\mathrm{k}=0}^{\mathrm{n}}\mathrm{C}\mathrm{F}\left(\mathrm{A}\mathrm{b}\mathrm{n}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}{\hspace{0.17em}\text{Symptom}}_{\mathrm{k}}\right)$

(1)

Equation (2) normalizes the weight of request i, ${\pi }_{\mathrm{i}}$ , into range [0,1].

$\mathrm{w}\mathrm{e}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}\left(\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{s}{\mathrm{t}}_{\mathrm{i}}\right)=\frac{\left({\mathrm{w}}_{\mathrm{i}}-\min \left({\mathrm{A}\mathrm{b}\mathrm{n}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}\hspace{0.17em}\mathrm{S}\mathrm{y}\mathrm{m}\mathrm{p}\mathrm{t}\mathrm{o}\mathrm{m}}_{\mathrm{k}}\right)\right)\times \left(1-\epsilon \right)}{({\mathrm{w}}_{\mathrm{i}}-\min ({\mathrm{A}\mathrm{b}\mathrm{n}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}\hspace{0.17em}\mathrm{S}\mathrm{y}\mathrm{m}\mathrm{p}\mathrm{t}\mathrm{o}\mathrm{m}}_{\mathrm{k}})+\epsilon }$

(2)

Queuing service

According to the proposed model in the fog layer, a request containing one or more abnormal symptoms is detected and is sent to the cloud layer. However, when the number of these requests increases the queue length increases. The queuing service in the proposed model prioritizes the process of requests based on the urgency of the demand. Each request is weighted based on the number of abnormal symptoms and CF values. Various methods are used to manage requests queue. One of the most popular is the M/G/1 queueing model with priority. ²⁶ Inter arrival times of submitted requests to the system are exponentially distributed and the service time distribution can be any arbitrary distribution. In this queueing model, the requests are classified into different static priorities before entering the system. A request is assigned to a waiting queue upon arrival based on its priority class. Priority classes are numbered from one to h. h is the highest priority class and one is assigned to the lowest priority class. In the proposed model, the request weight calculated by equation (2) is assumed as the priority of that request. Higher priority is assigned to patients’ requests with urgent demand. The response time of a request with priority p (p = 1,2,..., h), T_p, is the sum of average request service time of class p requests, E [S], and the average time that an arriving request of class p has to wait, W_p, for the server to complete processing the current request in service, equation (3).

${\mathrm{T}}_{\mathrm{p}}=\mathrm{E}\left[\mathrm{S}\right]+{\mathrm{W}}_{\mathrm{p}}$

(3)

The request waiting time is a calculated as follows.

${\mathrm{W}}_{\mathrm{p}}=\frac{\frac{1}{2}{\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{h}}{\lambda }_{\mathrm{i}}\times \mathrm{E}\left[{\mathrm{S}}_{\mathrm{i}}^2\right]}{\left(1-{\mathrm{U}}_{\mathrm{p}}\right)\times \left(1-{\mathrm{U}}_{\mathrm{p}+1}\right)}$

(4)

where, p, λ_p, $\mathrm{E}\left[{\mathrm{S}}_{\mathrm{p}}^2\right]$ , and U_p denote priority class, arrival rate of requests of priority p, the second moment of class p requests, and is the server utilization due to processing class p requests, respectively. U_p is calculated by equation (5).

${\mathrm{U}}_{\mathrm{p}}={\displaystyle \sum }_{\mathrm{j}=\mathrm{p}}^{\mathrm{h}}{\lambda }_{\mathrm{j}}\times \mathrm{E}\left[{\mathrm{S}}_{\mathrm{j}}\right]$

(5)

The product λ_j×E [S_j] is the fog server utilization U_j due to processing priority j requests.

In this study, patients’ requests are classified to three classes named normal, warning, and emergency classes after registering in the electronic health record (EHR). The emergency requests have the highest priority and the normal requests classes have the lowest priority for processing in the fog layer (Figure 2). The requests with the warning class have the middle priority.

Figure 2.

Classifying requests in priority queues of the fog layer.

Results

Dataset

The coronary artery heart disease patient database in the machine learning repository of the University of California, Irvine ²⁷ is used in experiments. In this dataset, 14 different characteristics are measured. It includes the characteristics of 320 samples of people with coronary artery disease.

Evaluation

A simulator (mobile application) was developed to evaluate the proposed model. This mobile application was developed using Android Studio to send the patient’s vital signs from the data-acquisition layer to the fog layer. It sends dataset records as requests based on the Poisson distribution function with arrival rate λ. Data attributes are stored separately in a CSV file and are uploaded to the broker node using HTTP POST. Requests are sent by this application in real-time to the fog layer to monitor the patient’s health condition.

Main three component of Figure 3 are:

A: An android application that sends dataset records to the Raspberry Pi. This application simulates the role of an IoT device and sends requests to the cloud server for evaluation. Each record contains a number of features.

B: As a fog layer, Raspberry Pi is responsible for classifying the requests sent by the android application. According to Table 4, each request contains 14 features that are considered as symptoms measured by sensors.

C: The cloud layer contains a clinical DSS that is responsible for interpreting the requests sent from the fog layer. Microsoft Azure cloud platform is used in this layer.

Figure 3.

Deployed model and test setup.

Table 4.

Description of heart disease data set.

	Attribute	Domain
1	Age	Age in years
2	Sex	1 = male; 0 = female
3	CP: Chest pain type	1: Typical angina
		2: Atypical angina
		3: Non-anginal pain
		4: Asymptomatic
4	trestbps: Resting blood pressure (in mmHg on admission to the hospital) 11 htn	Number
5	chol: serum cholesterol in mg/dl	Number
6	fbs: (Fasting blood sugar >120 mg/dl)	1 = true; 0 = false
7	restecg: Resting electrocardiographic results	0: Normal
		1: Having ST-T wave abnormality (T wave inversions and/or ST elevation or depression of >0.05 mV)
		2: Showing probable or definite left ventricular hypertrophy by Estes' criteria
8	thalach: Maximum heart rate achieved	Number
9	exang: Exercise induced angina	1 = yes; 0 = no
10	Oldpeak = ST depression induced by exercise relative to rest	Number
11	Slope: The slope of the peak exercise ST segment	1: Upsloping
		2: flat
		3: Downsloping
12	ca: number of major vessels	(0–3) colored by fluoroscopy
13	thal: thallium scan	3 = normal
		6 = fixed defect
		7 = reversible defect
14	Class	0: <50% diameter narrowing
		1: >50% diameter narrowing

The CDSS used in the cloud layer is based on the rule developed in the study. ²⁸ Some samples of the extracted rules are shown as follows:

-R1: if (thal is 3) and (ca is 3) and (sex is 0) and (slope is 1) then the probability of infection is 56%.

-R2: if (thal is 6) and (CP is 4) and (restecg is 1) and (sex is 0) and (chol >200) then the probability of infection is 64%.

-R3: if (thal is 3) and (ca is 3) and (sex is 1) and (slope is 2 or 3) and (thalach ≤ 160) then the probability of infection is 5%.

Figure 4 shows the measured network usage time for different requests arrival rates. As can be seen, the average network usage time in the proposed model is less than in the fog and cloud-based model. In our model, requests detected as normal by the fog node are stored locally, so the warning and emergency requests classes need to be checked in real-time and transmitted through the network first. Normal class requests are sent to the cloud layer to record data in the EHR when the queue of warning and emergency classes is empty. The proposed fog-based model reduced network usage time by an average of 25.55% compared to the cloud compared and 5.8% to the fog computing model.

Figure 4.

Average network usage time versus patients’ request rates.

We present the aggregated results for all the classes in terms of Latency and Response Time in Figures 5 and 6. In this way, we used the following calculations for these metrics

${\mathrm{L}}^{\mathrm{a}\mathrm{g}\mathrm{g}\mathrm{r}}=\frac{{\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{j}}\left({\mathrm{w}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}\_\mathrm{i}}*{\mathrm{L}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}\_\mathrm{i}}\right)}{{\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{j}}{\mathrm{w}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}\_\mathrm{i}}}$

(6)

${\mathrm{R}}^{\mathrm{a}\mathrm{g}\mathrm{g}\mathrm{r}}=\frac{{\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{j}}\left({\mathrm{w}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}}\_\mathrm{i}*{\mathrm{R}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}\_\mathrm{i}}\right)}{{\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{j}}{\mathrm{w}}_{\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{s}\_\mathrm{i}}}$

(7)

where, L^aggr and R^aggr denote the aggregated (weighted) latency and response time of a request in an infrastructure (Cloud, Fog, or Proposed). w_{class_i} represents the weight of the request class i (as shown in Table 5), L_{class_i} represents the latency of class i, and R_{class_i} represents the response time of class i. There are three classes (j = 3) including Normal, Warning, and Emergency.

Figure 5.

Average request latency versus patients’ request rates.

Figure 6.

Average response time versus patients’ request rates.

Table 5.

Requests classification result.

Class	Number of requests	Percentage, %
Normal	100	31
Warning	132	41
Emergency	88	28

Figure 5 depicts a comparison of the average latency in the proposed model and fog computing and cloud computing with different patient requests rates. Compared to cloud and fog computing, the proposed model reduced the latency by an average of 42.92% and 14.5% respectively.

Figure 6 represents a comparison of the average response time in the proposed model with the fog and cloud computing based on equation (3). Compared to cloud and fog computing, the proposed model reduced the response time by an average of 34.28% and 15.6% respectively.

Table 5 shows the classification of dataset records in the fog layer. In this layer, the request classification process was performed by equation (2).

These results demonstrate that the proposed model provides better performance in comparison to the others in lowering the average latency and response time of a request.

Figure 7 shows a comparison of the latency in the proposed model with the cloud and fog model for different patient request classes. According to this figure, the proposed model reduced the requests latency of warning classes 45.53% and 54.5% respectively compared to the fog and cloud model. Also requests latency of emergency classes 19.7%. and 32.02% respectively reduced compared to the fog and cloud model.

Figure 7.

Comparison of latency time in each classes.

Figure 8 represents a comparison of network usage time in the proposed model with the cloud and fog model for three requests classes. As can be seen, warning class requests consumed more network bandwidth than emergency and normal classes because the main portion of requests is warning. The proposed model reduced the network usage time for requests in warning class 26.39% and 14.46% respectively reduced compared to the cloud and fog model. Also emergency class network usage time 15.66% and 8.74% reduced compared to the cloud and fog model.

Figure 8.

Comparison of network usage time in each classes.

Figure 9 shows the comparison of response time in the proposed model. According to this figure, emergency class requests have a better response time than the other two classes. The proposed model improved the response time of warning in fog model 18.15% and cloud model 26.94, also 61.41% and 77.34% respectively reduced for emergency class in fog and cloud model.

Figure 9.

Comparison of patient response time in each classes.

The results in Figures 7 and 9 represent the Latency and Response Time for each class. With respect to Normal class results in these Figs., it is necessary to mention that the DSS in our model detects a request class firstly and processes the request based on its class type. All the requests experience a processing time in the DSS. Therefore, the DSS imposes a negligible time to the Latency and Response time of all requests. This is the main reason that the Normal requests face more Latency and Response time in our model in comparison to the Fog and Cloud.

Figures 7 and 9, show that when the proposed model detects a request as normal, the request would not be processed until all the requests in the higher priority classes processed. It is clear from equations (3)–(5) that the waiting time of a lower class requests (normal) depends on the number of higher priority queues (warning and emergency) and the number of requests in these queues. When the DSS in our model receives a request, it needs a time to detect the request class based on its characteristics. Therefore, the DSS imposes a negligible time to the Latency and Response time of all requests. This is a reason that normal requests face more Latency and Response time in our model in comparison to the Fog and Cloud. Therefore, the normal requests relatively experience high latency and response time in comparison to the fog and cloud environments. When a request is a normal request, there is no sensitivity to send it in a dedicated time in our model. This would not affect the functionality of the proposed model.

Discussion

In this study, by using priority queues in the fog layer and allocating appropriate bandwidth to the requests of patients with acute conditions, a significant improvement in response time (34.28%) was achieved. In recent research, using techniques such as big data, ¹⁹ decision support systems, ²⁹ machine learning, ¹³ etc., in the fog layer, attempts have been made to manage bandwidth. Fog-based remote patient monitoring systems have mainly focused on latency improvement.

Integrating the IoT, fog computing, and cloud computing has provided many benefits, such as remote patients’ treatment plans and urgent medical care for healthcare systems. Recently, the efficiency of cloud computing and its use in the medical industry has been extensively studied, leading to the provision of efficient and accepted cloud-based solutions. However, due to geographically centralized architecture and multi-stage distance from the IoT data sources, the cloud faces limitations in real-time communications. The lack of real-time communication can increase the number of patients’ death in IoT-based healthcare systems.

Table 6 examines recent works in the fog-IoT-based healthcare industry. Previous works has focused mainly on the analysis of cardiac patient data and predictive accuracy, and less attention has been paid to the QoS review of RPMs. The presented model in this study can effectively identify the requests based on the severity of the patient’s request. It determines the priority of requests by identifying the symptoms affecting the condition of heart patients in fog layer. In the proposed model, emergency requests are prioritized for receiving services by combining the weighting technique and priority queues.

Table 6.

The percentage of improvement of the proposed model compared to the other models.

Work	Fog computing	IoT	Prediction system	Priority queue	Performance parameters
					Power consumption	Execution time	Latency	Network usage time	Response time
[10]	✔	✔	91%	—	—	—	—	—	—
[11]	✔	✔	—	—	—	—	—	—	16.45%
[6]	✔	✔	89%	—	—	—	16%	26%	—
[12]	✔	✔	—	—	—	—	—	—	—
[13]	✔	✔	81.89%	—	—	—	—	—	—
[14]	✔	✔	96%	—	—	72.8%	—	—	19.04%
[15]	✔	✔	90%	—	—	—	—	—	—
[16]	✔	✔	87.8%	—	—	—	—	—	—
[17]	✔	✔	—	—	—	—	—	—	—
[18]	✔	✔	—	—	20–50%	—	10–50%	40–80%	—
[19]	✔	✔	—	—	23.56%	—	19.5–29.4%	22–26.7%	—
[22]	✔	✔		✔	—	1%	35.4%	11.16%	—
Proposed model	✔	✔	89.76%	✔	—	—	42.92%	25.55%	34.28%

Recent studies have presented models to reduce latency and make applications more efficient using fog and cloud computing. In this study, the effectiveness of using priority queues to identify emergency patients with minimal delay was investigated. According to Table 6, although the response time criterion is an important factor in the provision of remote patient monitoring services, most of the fog-based RPM models have qualitatively an improvement in response time reported. The proposed model, unlike previous studies, is simultaneously focused on increasing the quality of service and the quality of experience (QoE).

In the evaluation of the present model, the input data is based on a dataset, which as a limitation, vital signals can be directly received from sensors in the real environment.

Conclusion

In this study, a fog-based intelligent DSS health care system was presented for automatic diagnosis of heart patients’ health status. This health care system introduces a queuing modeling in the fog service to effectively evaluate heart patients’ data received from various IoT devices. The system incorporates the queuing modeling into edge devices for real-time heart disease analysis and response. The proposed fog computing model prioritizes the incoming patients’ requests with different medical urgencies to be processed by the DSS. The proposed system was evaluated with the coronary artery heart disease dataset and the results demonstrate that it can significantly improve QoS metrics. Moreover, this system scales well when the request rate increases. In the future, we plan to investigate a method to switch requests class between queues. In other words, the CF-based mechanism is tuned based on the waiting time of requests and move them between classes. In addition, the efficiency of the proposed system can be evaluated for predicting and diagnosing other IoT-based diseases.