FogMed: A Fog-Based Framework for Disease Prognosis Based Medical Sensor Data Streams

: Recently, an increasing number of works start investigating the combi-nation of fog computing and electronic health (ehealth) applications. However, there are still numerous unresolved issues worth to be explored. For instance, there is a lack of investigation on the disease prediction in fog environment and only limited studies show, how the Quality of Service (QoS) levels of fog services and the data stream mining techniques in ﬂ uence each other to improve the disease prediction performance (e.g., accuracy and time ef ﬁ ciency). To address these issues, we propose a fog-based framework for disease prediction based on Medical sensor data streams, named FogMed. This framework aims to improve the disease prediction accuracy by achieving two objectives: QoS guarantee of fog services and anomaly prediction of Medical data streams. We build a virtual FogMed environment and conduct comprehensive experiments on the pub-lic ECG dataset to validate the performance of FogMed. The experiment results show that it performs better than the cloud computing model for processing tasks with different complexities in terms of time ef ﬁ ciency.


Introduction
Both remote and in-hospital healthcare mechanisms use body sensors and patient monitoring devices to collect and display the continuous signals of multiple physiological parameters, which are usually presented in the form of data streams. These data streams will be referenced by doctors or intelligent medical decision systems to detect or predict diseases, and to give accurate prognosis decisions in time [1]. The elders or patients having chronic diseases usually need to be monitored consistently. For example, it is of great value to predict abnormal heartbeats as early as possible and send a response to user terminals as soon as possible. Care workers can take effective measures in advance, so that the survival chance of patients with heart diseases can be increased. This work aims to develop an ehealth system based on IoTs to provide robust healthcare support for those people.
Some researches [2,3] apply cloud computing techniques to ehealth industry. Cloud computing enables on-demand utilization of software and hardware resources [4]. The centralization of cloud resources and their flexible provision facilitates the analyzing of a large volume of Medical data streams. For example, it is possible to easily perform deep learning algorithms for big data processing and mining. In addition, cloud computing reduces the costs of building high performance servers and databases for individual service users. An obvious disadvantage of just applying cloud computing to solve ehealth problems is that cloud resources are usually far away from end users. This may result in slow answers for a diagnosis event, which can cause terrible consequences in a real-time Medical event.
Fog computing is the current optimal solution for ehealth services [5]. The design of fog computing is especially adaptive to the applications requiring fast answers. Fog computing is a combination of edge computing and cloud computing. The tasks demanding low latency and few resources will be distributed to edge devices. The tasks requiring a large amount of resources will be delivered to the cloud computing center (CCC). In an ehealth system, data streams consistently collected from body sensors can be monitored, displayed and processed by edge devices. A large volume of historical data can be stored in cloud databases for further analysis. Existing fog-based data analyzing [6,7] and QoS controlling [8] techniques have dramatically improved the machine-based health monitoring and anomaly detection. However, there are still a number of unresolved issues worth to be explored. For example, there lacks an investigation on anomaly (e.g., heart disease) prediction based on Medical data streams in fog computing; and limited studies show how the Quality of Service (QoS) optimization of fog services and the anomaly prediction of Medical data streams influence each other to improve the prognosis accuracy.
In this paper, we propose an environment-friendly Medical data stream management system based on fog computing, called FogMed. It can collect and store patients' physical information, analyze and predict anomalies based on the information, and optimize QoSs of fog services. The purpose of monitoring patients is to detect or predict their anomalies as early as possible, so that the accurate treatments can be taken in advance to maintain patient health. Therefore, we focus on two problems: anomaly detection and prediction of Medical data streams, and QoS optimization of fog services. To demonstrate the efficiency of FogMed, we illustrate an example of Atrial Fibrillation (AF) prediction from Electrocardiogram (ECG) data streams. A two-layer stacked long short term memory (LSTM) model is proposed for AF prediction (abbreviated as SLAP). Based on the AF prediction results, we evaluate the response time of fog nodes for processing simple Medical tasks and that of CCC for processing complex Medical tasks. At last, we build a virtual FogMed environment and conduct comprehensive experiments. Experiment results show that FogMed performs better than the cloud computing model for processing both complex and simple Medical tasks. Overall, this work has the following contributions: We introduce a fog-based disease prediction framework to explore the correlation between QoS optimization of fog computing and the performance of disease prediction. We illustrate an example of heartbeat anomaly prediction based on FogMed and introduce a deep learning model for anomaly prediction. We conduct comprehensive experiments to validate the efficiency of FogMed for processing both complex and simple Medical tasks.
The structure of this paper is: Section 2 describes the architecture, functions and characteristics of FogMed, and illustrates an example of abnormal heartbeat prediction based on FogMed; Section 3 demonstrates the efficiency of FogMed based on experiments. Section 4 reviews state-of-the-art; and Section 5 concludes this paper.

A Fog-Based Framework for Disease Prognosis Based on Medical Data Streams
This section introduces the key physiological parameters that need to be monitored and analyzed in ehealth. We propose a system of analyzing, mining and managing Medical sensor data streams based on fog computing techniques, namely FogMed, and introduce the structure of a fog device in FogMed. We summarize the main notations used in this paper in Tab. 1.

Types and Collections of Medical Data Streams
Advanced handheld or wearable monitors can help collect different types of physiological signals of patients or elders. For example, a handhold multi-parameter patient monitor [9] is capable of consistently monitoring pulse rate, information of blood constituents (e.g., arterial carbon monoxide saturation and arterial oxygen saturation), plethysmograph data, and perfusion quality. This information is normally presented in the form of data streams. A number of medical devices [10] have been developed to store and analyze these data streams.

Requirements on Computing Model for Processing Medical Data Streams
Real-time generated healthcare data streams have features of variety, large volume, and high velocity [11]. Some researches propose cloud-based methods to process this type of data. However, the centralization of cloud resources and the inflexibility of cloud network structures make the cloud incapable of handling healthcare data streams rapidly. Low velocity may result in serious consequences in healthcare contexts [11]. The computing model capable of handling such healthcare data streams must satisfy the following requirements [12,13]: (1) Easy to achieve very low latency. Fast responses can save treatment costs and patient lives, which requires not only the speed of data transmission and analysis, but also the right places to make decisions. Places close to the data generation mobile devices are more appropriate for fast decision making than remote clouds. (2) Reduce the waste of network resources. Not all the data need to be sent to the cloud. (3) Guarantee data security. Healthcare data are the privacy of  [12]. However, different mobile devices may use different communication protocols.

Overview of the Architecture of FogMed
The architecture of FogMed is shown in Fig. 1. The sensor layer is the edge of the architecture, where different types of sensors consistently sense the physiological signals of patients. We use the wearable health monitoring sensors [14] to monitor a patient's physical status. A wearable hub [14] is used to communicate these data streams with mist devices, such as mobile devices (e.g., laptops or mobile phones), microcomputers or microcontrollers that have data processing and storage capabilities. These mist devices are at the bottom of the fog layer. They can analyze a small amount of data and make fast decisions. Tasks requiring more computing resources are forwarded to the second fog layer. Cloud resources are far away from sensors, which can process non-urgent tasks requiring a large amount of resources. Both fog and cloud layers have capabilities of analyzing and summarizing data, making diagnostic decisions, and determining service scheduling strategies.
We use the round-robin database (RRDB) in fog layer to store small and temporal data streams; and use both the RRDB and the journal database (JDB) in cloud layer to store large and long-term historical data [1]. For example, an RRDB stores physical data streams from sensors of a patient, and a JDB stores the information of important medical events, e.g., an illness breaking or a device failure.

Geographical Partition and Function Components of Fog Devices
FogMed works in a constrained geographic area. It further partitions devices of a wide area into a number of subareas and manages each subarea through some controlling devices. Fig. 3 shows geographical partitions of fog devices. There is at least one controlling fog device in a subarea, which has the following functions: Resource management: Manages both practical and virtual resources to guarantee successful executions of multiple Medical tasks, by simultaneously optimizing QoS levels [15]. Power management: Power management is critical in an ehealth system. Both cloud and fog devices have power constraints [16], so it is necessary to develop an appropriate energy saving strategy by considering the power drain and battery lifetime of fog nodes [17] to guarantee the success of realtime Medical tasks. Monitoring devices: Monitor both resource utilization and energy consumption. The monitoring data can be used for real-time resource and energy management. It can be stored in a cloud JDB for subsequent system analyses. Medical data stream management: Pre-process, store, and analyze Medical data streams. Especially, by cooperating with the resource management, energy management and status monitoring components, a fog node should be capable of determining which data streams and tasks should be sent to cloud and which should be processed by fog devices.
Basically, non-controlling fog devices in a subarea have functions of Medical data stream management, status monitoring and power management. They execute instructions from controlling devices and send information to places designated by controlling devices (e.g., databases, other fog devices, user terminals or cloud devices). Fig. 2 shows the structure of a controlling fog device of FogMed, which references the fog node architecture defined by [18]. This structure takes into account resource management (including hardware and software resources), QoS optimization, data processing and analyzing, database management, interfaces to the Web, connections to the other fog nodes and the cloud layer, data organization, network communication and data security [19] for designing both hardware and software.

Architecture of a Fog Device in FogMed
The structure of a non-controlling fog device is similar to that of a controlling fog device, but based on its specific functions, it might be configured by different software or hardware. The application scenario of FogMed is to monitor physiological conditions of patients by using sensors and monitors inside or outside a hospital. The workflow of Fogmed is as follows: By using monitor components (see Fig. 2), a fog device directly connects to one or more sensors on the body of a patient. The fog device is managed by an operating system and deployed by a number of software services. The monitors, coupled with the protocols/services of the network communication and device interaction, collect data streams generated by sensors in certain generating rates. The data streams collected in a time interval are pre-processed (e.g., removing noises), formatted, compressed, and stored in the random access memory (RAM) or the RRDB. In this step, we need to develop advanced techniques to organize (i.e., format, compress, federate and store) different types of data streams collected from sensors or patients. A fog device is deployed by a system of Medical data stream management, which includes the services of real-time processing and analyzing consistently generated data streams. Based on specific requirements, the fog device calls corresponding services to analyze data streams. If this analyzing task requires a short-term history information, the fog device accesses the RRDB. However, if a long-term history information is required and the fog device cannot provide such information, this analyzing task is sent to CCC. In this step, we need to develop innovative techniques to predict or detect anomalies in data streams to diagnose diseases as early as possible. As soon as an anomaly is detected, the system calls services of analyzing anomalies and making treatment decisions. It then sends alarms or corrective treatments to end-devices of the patient based on some pre-determined confidence thresholds. If the system cannot automatically make right decisions based on the confidence thresholds, the anomaly will be sent to end-devices, and  Figure 3: Geographical partition and controlling of fog devices then artificial decisions will be made and sent to patients. In this step, we need to develop techniques of anomaly prediction and treatment decision making.

Resource Management, QoS Optimization and Energy Saving
The other two objectives of this work are QoS optimization and energy saving. FogMed guarantees that the requested tasks are completed, and the best trade-off among multiple quality measuring parameters (e.g., response time, latency, and availability) of services (e.g., cloud, fog and network resources) is achieved. The satisfaction degrees of a service user (e.g., a patient, a doctor, or a service using the measured services) are then optimized. Simultaneously, FogMed aims to minimize the energy (e.g., power) consumption on the premise of QoS optimization and accurate decision making.
To achieve QoS optimization, we explore techniques of resource management, including both software and hardware resources. Software resources refer to virtual resources, e.g., virtual machines on a fog or cloud platform, virtual fog nodes by separating an actual fog node or a geographically constrained area, and virtual local area networks. Hardware resources include the actual fog and cloud processors, memories, and networks. FogMed must be able to dynamically determine how many and which fog and cloud processors to be used, how many fog and cloud databases to be built, and how to distribute tasks and balance loads on fog and cloud devices. We will show the efficiency of FogMed for performing Medical tasks by comparing it with a CCC in Section IV.

Components and Functions of Cloud Layer in FogMed
A cloud computing device in cloud layer processes complex services and a large amount of data that cannot be processed in fog devices. In our medical context, the data stream mining services that do not require fast responses but require high computing power or depend on certain historical information are most probably processed by cloud computing devices. In addition, cloud layer is deployed with both JDB and RRDB, which store long-term information and time-critical information respectively. Components of cloud layer are shown in Fig. 4, which include controlling devices (represented by the oval shape) and non-controlling devices (represented by the round shape). A controlling device accepts services coming from the fog layer and allows services to non-controlling devices based on some service allocation strategies. Its functions are similar to the functions of controlling fog devices. Non-controlling cloud device has the same functions as controlling fog devices. Controlling and non-controlling cloud devices communicate with each other, and also communicate with cloud storage devices (i.e., cloud RRDBs and JDBs). We describe an example of building a deep learning model to predict AFs based on ECGs in the cloud layer of FogMed.

A Deep Learning Model for Predicting Atrial Fibrillation in Cloud Layer
In cloud layer, we store a large amount of history ECG data streams in JDBs, and train a deep learning model, a stacked LSTM, to predict AFs based on ECG data streams. We call this model a stacked long short term memory architecture for AF prediction (abbreviated as SLAP). The structure of SLAP is shown in Fig. 5, which contains two sub-layers of LSTM. Each edge connecting two cells has a weight value. Fig. 6 shows details of SLAP, where a hidden layer of LSTM overlays the other hidden layer, and the upper layer outputs information to the lower layer. A cell represents a time unit. The input layer inputs a multivariate time series to each cell and the output layer outputs a time series with N (N > 0) time units.
Eq. (1) shows the data transformation between cells [20], where i lower is the input to the bottom hidden layer; f is an activation function; W lower n is the weight of the edge connecting the upper-layer cell and the bottom-layer cell; N is the output number of the upper layer; o n is the output of a cell; and b lower is a bias value.
SLAP takes advantage of the multiplicative structure of LSTM, in which each cell is capable of controlling the information flow. Based on the output of a time unit and the new ECG signals, SLAP predicts signal trends in next time unit with variable time lengths.

Modelling Errors of the Predicted Samples for Classifying Normal and Abnormal Samples
After training a SLAP model, we determine whether the predicted samples are normal or abnormal. To achieve this, we assume that the errors of the predicted samples from the true samples fit the multivariate where l is an n × 1 vector and Ä is an n × n matrix, which are defined by Eqs. (3) and (4) respectively.
If p e i ð Þ < e, we say x i is a normal sample, or else, x i is an abnormal sample, where e is an error threshold and will be introduced in detail in the next section.

Steps of Model Learning and AF Prediction
Steps of building SLAP are as follows: (1) Data processing. At first, we divide a set of multivariate ECG samples into four subsets, S 1 , S 2 , S 3 and S 4 , to train the SLAP parameters, the multivariate Gaussian distribution of sample errors, and an error threshold E for distinguishing normal and abnormal samples, and to test the trained SLAP model respectively. (2) Learn SLAP parameters and the multivariate Gaussian distribution. We use sample set S 1 to learn the SLAP model and use S 2 to validate the model and simultaneously fit the multivariate Gaussian distribution. (3) Determine E. After fitting the multivariate Gaussian distribution, we determine the value of E based on S 3 . The final E should maximize the f-score in Eq. (5) [21].
where A p and A r are defined by Eqs. (6) and (7) respectively; and b is a trade-off parameter between A p and A r .
3 Experiment Our experiment contains two main parts: Experiment-I: evaluate the deep learning model SLAP for AF prediction; and Experiment-II: Evaluate the response time of fog layer and cloud layer for processing AFs. We describe the results of these two parts separately.

Experiment-I
Experiment-I is based on two public ECG databases: the long-term AF database (LTAF) and the AF terminal challenge database (AFTC) [22]. LTAF includes the long-term ECG recordings of 84 subjects who have the sustained or paroxysmal AFs [23], and the duration of LTAF records are in the range of 24 to 25 hours. A record in AFTC contains two ECG signals, where the sample frequency of each signal is 128 samples/second; and a record only sustains one minute. We separate the two datasets into four subsets: S 1 , S 2 , S 3 and S 4 .
The settings for training an SLAP are defined as follows: divide a long term ECG into short segments (1~2 minutes), where each segment has the length of 100 unit time (1 unit time = 1 second); and input the segments into the input layer of SLAP consistently. SLAP has two hidden layers. Each layer has 55 cells. Let the learning rate to be 0.01, the termination error to be 0.00001, and b to be 0.1. We then train the SLAP based on S 1 . The trained SLAP can predict the trend of the ECG signals in future 10 time units. The experiment runs on a computer with a GPU of NVIDIA GeForce 1050 1 .
Based on the above settings, we train an SLAP model and use this model to test the performance of AF prediction and then to determine E. We take about 45 seconds to fix the optimal F b = 0.92 and E = 0.015. And then we validate the anomaly prediction results based on S 4 . We compare the AF prediction performance of SLAP, single-layer LSTM and RNN in Tab. 2. The accuracy recall and f-score of SLAP are higher than those of RNN and LSTM, because the stacked LSTM layers in SLAP can extract high-level features that can result in a richer output than RNN and LSTM [21].
Tab. 3 shows the performance of SLAP with different number of layers. SLAP with two layers achieves the highest performance. SLAP with one layer does not have enough weight variables to support the feature diversity. SLAP with more than two layers can cause under-fitting. Experiment results demonstrate that a stacked structure can enhance feature extraction accuracy, and support the modeling of ECGs by using various weight variables and biases.

Experiment-II
We build a virtual FogMed environment, whose topology is shown in Fig. 7. This network topology has one cloud data center and 16 fog areas (WAN1, …, WAN16). Each fog area contains 32 fog nodes that are connected with each other. Each fog area contains 16 hospitals, and each hospital contains 500 edge nodes, where an edge node represents a patient that being monitored and sends data streams to its connected fog node. The configurations of the virtual FogMed environment are shown in Tab. 4, where the computing core numbers of the cloud data center (cdcCoreNum) and a fog node (fogCoreNum) is 64 and 4 respectively; the average sizes of a task packet or a query packet from a fog node to cloud (aveTaskSizeF2C) and to an RRDB (aveQuerySizeF2DB) are both 1 KB; the average sizes of a response  In the virtual FogMed, patients are monitored to detect the abnormal heartbeats. By using ECG detection sensors, a patient generates heartbeat data streams consistently. These data streams are sent to and analyzed by a mist device connected with the sensors. If an abnormal heartbeat happens, a warning signal is sent to a connected fog node f o . In a certain time period (e.g., 1 ms), f o integrates the warning signals from the 500 edge nodes and establishes tasks to process these abnormal signals based on the abnormal complexities. We divide the abnormal complexity into 20 grades: g 1 $ g 20 where g 1 represents the simplest task. After determining g i i 2 1; . . .   enough capacity, it will start this task, or else, it will send this task to the controlling fog device Ctrf o in this fog area. Based on the task complexity, Ctrf o makes decisions to allocate other fog devices to g i . or send this task to CCC.
We test AFs in this experiment, and define the number (n) of AFs happened in 1 ms as a variable of the abnormal complexity: g ¼ g 1 if n 2 1; 25 ½ ; g ¼ g 2 if n 2 26; 50 ½ ;…; and g ¼ g 20 if n 2 426; 500 ½ . And we use a simple scenario in this experiment for testing the performance of FogMed: We set two complexity thresholds: t 1 ¼ 60% and t 2 ¼ 90%. The complexity of a task will be determined by a fog device. The complexity of a task being less than t 1 , between t 1 ; t 2 ½ , and more than t 2 means the task is simple (task s ), moderately complex (task m ) and very complex (task c ) respectively.
Test-I: a fog node sends all arrived tasks (including task s , task m and task c ) to CCC. The action loop time (i.e., a time period from the point of sending a task to the point of getting a response) of CCC for tasks with different complexities is shown in Fig. 8. We can see that whatever the complexity of a task is, the average response time of CCC for the task is around 250 ms, which means the task complexity does not influence much on the processing time of CCC. And since we have defined that the packet size and the transmission rate of distributing a task on the Internet is fixed, and they cannot be influenced by task complexities, so sending a simple task from fog to cloud takes similar time to send a complex task.
Test-II: a simple task (task s ) is processed by the fog device holding the task or fog devices close to the holding device; a moderate task (task m ) needs to query ancillary data from a hospital RRDB and then is processed by the fog device holding the task or fog devices closing to the holding device; and a complex task (task c ) will be sent to cloud by a fog controlling device. We define that the complexities of a task s , a task m and a task c are less than 60, in [60,90], and more than 90 respectively. Fig. 9 shows the action loop time of 12 task s s, 6 task m s and 2 task c s, where the average response time (i.e., average loop time) of task s s, task m s and task c s are around 50 ms, 90 ms and 150 ms respectively. On one hand, locally processing a simple task by a fog device takes little transmission time and transmitting a task from fog to cloud needs much time. On the other hand, though the processing power of CCC is stronger than that of a fog device, CCC needs to process more complex tasks than fog devices.
From Figs. 8 and 9, we can see that CCC takes 250 ms on average to process all types of tasks simultaneously, and 150 ms on average to just process complex tasks. This is because sending more tasks to CCC increases the occurrence possibility of network congestion in one time period, and tasks may need to be queued to wait for the free processing power. From this experiment, we can see that distributing all tasks to cloud has to solve problems of remote transmission, network congestion and task overwhelming. However, FogMed takes advantage of both fog and cloud resources, which solves the problem that the fog layer lacks computation and storage resources, and eases network congestion and task overwhelming for the cloud layer. In addition, for small hospitals or individuals, it is simpler and more practical to build or use cheap fog devices near to them. Overall speaking, fog computing is more appropriate to solve ehealth problems and FogMed is an efficient and practical framework for disease diagnosis and prognosis.

Related Work
This section reviews state-of-the-art about the fog-based ehealth, focusing on discussing disease prognosis, Medical data stream mining, QoS optimization and energy saving. Based on the literature review, we point out some unresolved issues.

QoS Optimization and Energy Saving in Fog-Based ehealth
Many scholars explored the problem of QoS optimization in fog environment. Muhammed et al. [24] proposed a network management framework to solve the QoS optimization of network latency, bandwidth, and reliability in the IoT-based ehealth system. It uses an edge device called cloudlet [25] to implement the fog framework. Different to [24], Rahmani et al. [26] designed a gateway as an intelligent fog device to connect end users and resource centers. The gateway-based healthcare system considers these QoS parameters: End-device mobility, energy saving, service availability and resource scalability. Gu et al. [27] applied the fog computing to Medical intelligent systems, and explored the problems of task allocation, virtual machine distribution, and resource collaborations among root stations. Shukla et al. [28] developed a fuzzy model for latency minimization of the fog network in healthcare IoTs. Petrakis et al. [29] developed an IoT as a Service (iTaaS) to collect and process sensor data. They applied iTaaS to Medical sensor data stream management to speed up the answering of Medical services. Asif-Ur-Rahman et al. [30] designed a five-layer framework based on fog computing to optimize the resource usage and the Medical task distribution. Wei et al. [31] proposed a model-free reinforcement learning method to solve the problem of formulating and balancing the computation offloading in a mobile edge environment.
Sensor-based fog computing faces an important problem: How to balance the limited power of fog devices and the requirements on processing a large amount of data. To solve this problem, Sodhro et al. [32] proposed an adaptive power control algorithm that can save more power, reduce packet loss and Figure 9: Response time of FogMed with respect to different task complexities calculation complexity, and improve link reliability. Qu et al. [33] summarized the main challenges, analyzed corresponding solutions proposed by existing works, helped readers have a deeper understanding on the concepts of different computing models and studied the techniques of QoS optimization and energy saving in these models. In 2017, work [34] proposes two green and sustainable algorithms to improve the battery life in the transmission of the Variable Bit Rate (VBR) video in wireless body sensor networks. Later, an algorithm of processing various postures of subjects [35] and considering power control was proposed. Further, the work [16] designs two advanced algorithms, named Hybrid Adaptive Bandwidth and Power Algorithm and Delay-tolerant Streaming Algorithm. In addition, the work [16] explores the problem of power control in sensor-based smart healthcare, which introduces an adaptive transmission power control algorithm and a battery and power gathering model for body sensors.

Medical Data Stream Analysis in Fog-Based ehealth
Farahani et al. [18] did a survey on the fog-driven ehealth. Based on the review, they introduced an architecture of IoT ecosystem and discussed challenges in building this system. This work discusses applications of the existing resource management and data analysis techniques to the ecosystem, and reviews multiple Medical problems based on different types of Medical data. Borthakur et al. [36] introduced a fog architecture for unsupervised mining of the physical data. Nguyen et al. [37] developed a health management system for heart diseases based on low-cost fog nodes. However, this work neither investigates the data stream analysis and fog computing techniques in detail, nor designs advanced QoS optimization and energy saving strategies. Our work is different to the above works because we focus on making accurate and time-efficient predictive decisions for disease prognosis. We aim to develop new algorithms of anomaly prediction in Medical data streams, and new QoS optimization and energy saving techniques to improve the prediction accuracy and efficiency.

Disease Prognosis Based on Data Stream Mining
Some researchers explored the disease prognosis techniques without considering the network environment and the computing paradigm. For example, Yoon et al. [38] proposed a forecasting system for prognosis decision making, which monitors patients in hospitals and analyzes the disease status based on the monitored data streams of physical parameters. Tashkandi et al. [39] explored similarity calculation techniques among patients having similar diseases, aiming to improve the prognosis results based on the historical information of the other patients. Sow et al. [40] investigated the techniques of fast online predictions in a short period based on the live data of patients in hospitals. One problem of the above work is that they only discuss the disease prognosis in hospitals, but do not consider the cases of remote monitoring of the patient status. Wang et al. [41] discussed big data processing and analysis according to different service requirements and introduced the detailed cloud computing service system based on big data. Yin et al. [42] analyzed the feature and problem of finite state automata and improved nondeterministic finite automata by reducing the conversion edge to reduce the memory usage.

Differences of the Above Works to FogMed
The main objective of FogMed is to support disease prediction based on Medical data streams. The above works are not appropriate for solving the problem considered in FogMed. To achieve the objective, FogMed should have a mechanism to automatically segment a long-term Medical data stream precisely, learn association rules between a preceding segment and a future abnormal segment, and allocate and store the segments and rules properly to support fast information query. Therefore, QoS optimization strategies for making predictive Medical decisions should consider how to transmit, allocate and store the correlated segments and rules in a fog environment, and when to perform predictions and make decisions based on the rules and the current QoS levels of fog services. In addition, few of the existing works investigate how fog computing techniques will affect the design of Medical data stream mining algorithms, and then affect the disease prediction performance. Therefore, it is necessary to design adaptive Medical data stream mining algorithms to fit the dynamic environment variables of fog computing.
In this work, we implemented a deep learning algorithm for anomaly prediction and validated the capability of Fog computing processing anomalies in Medical data streams in terms of the average response time. In the future, we will consider more QoS variables and explore how these QoS variables influence disease prediction tasks.

Conclusion
We proposed FogMed, a fog-based framework for disease prognosis based on Medical sensor data streams. FogMed aims to improve the prognosis accuracy by achieving two objectives: QoS optimization of fog services, and anomaly detection and prediction based on Medical data streams. In addition, we built a virtual FogMed environment and conduct comprehensive experiments on the public ECG dataset. In the future, we will consider power constraints of fog devices and develop advanced power saving techniques in FogMed. Furthermore, we will explore power-aware task allocation algorithms to improve the anomaly prediction performance in power-constrained environment.
Funding Statement: This work is supported by NUIST Students' Platform for Innovation and Entrepreneurship Training Program, the National Natural Science Foundation of China (Grants No 61702274), the Natural Science Foundation of Jiangsu Province (Grants No BK20170958), and PAPD.

Conflicts of Interest:
The authors declare that they have no conflicts of interest to report regarding the present study.