the functional structure of the remote patient monitoring system based on an IoT-cloud architecture. The system has been designed to measure physiological parameters of a human being such as pulse rate and body temperature. The inputs from the sensors are fed to the programming board for further processing and calculation.

A wireless transreciver module is integrated with the pro- gramming board to send the data to a user interface, a cus- tom developed app that displays the health parameters. The received health parameters are processed in the app, and a corresponding brief health analysis report is generated and displayed on the app. If the analysis infers that the person is medically distressed, a text message is sent to all those people that are registered in the app as friends, family, doctors or car- egivers. The data is also sent to a live online database which can be accessed by anyone with whom the database URL has been shared. This database also plots the data on a time graph which can be customized to show data from any of the sensors over a period of time.

The design is practical and can be scaled up further to inte- grate many more sensors in order to measure various other health parameters as shown in Fig. 2.

The various hardware blocks are explained in full details in a later section.

 

1    Details of the sensing system

The current version of the system consists of three sensing units, a temperature sensor, a heart rate detector unit and a fall detector.

 

1.1    Temperature sensor

 

The skin temperature measurement is done using the LM35, a precision IC temperature by Texas Instruments (LM35 1999). The sensor analog voltage output is directly pro- potional to the temperature that can be easily interpreted to obtain a temperature reading in Celsius. This voltage is measured by the Arduino microcontroller using a 10-bit Analog-to-Digital converter (ADC). The temperature sensor, LM35 is first calibrated using standard HICKS IS-3055 (PT- 2) and lukewarm water upto 50 °C and then it is intefaced with the microcontroller. The normal body temperature sample was attained by holding the LM35 under the finger tip however the high temperature was obtained by blowing hot air on the developed prototype using hand held hot air blower. The average accuracy level of the LM35 temperature sensor is ± 1 °C. But the accuracy level decreases for tem- peratures between 2 to 25 °C. Also, relative changes in tem- perature were measured and synchronized with the devel- oped app in order to send the alarm text messages to friends, relatives and doctors. This would help in determining if the subject was under any form of trauma, injury, stroke, heat exhaustion, burns, and heart attack (Azimi et al. 2018).

The output of the ADC has to be converted to the cor-

rect value. The ADC-value is first compared with the refer- ence voltage of 5V and then divided by 1024 as the ADC of Arduino is of 10 bits. The result is divided by 10 as the change in LM35 is 10 mV/ °C.

1.2    Heart rate sensor

The technique used to detect the person’s heartbeat is based on his photoplethysmogram (PPG) signal. A PPG signal is an optically obtained plethysmogram which is a volumetric measurement of a person’s organ. A PPG is often obtained by using a pulse oximeter, which illuminates the skin and meas- ures changes in light absorption (Shelley and Shelley 2001). A PPG shows the changes in blood flow as a waveform as shown in Fig. 3. The waveform has an alternating current (AC) com- ponent and a static or DC component. The AC component 

corresponds to variations in blood volume in synchronization with the heart beat. So, the AC component can be used as a source of heart rate information (Alian and Shelley 2014). The static component is created mostly by absorption of light by surrounding tissues (Alian and Shelley 2014). The basic frequency of the AC component varies with the heart rate and is superimposed on the DC base line. The normal frequency range of PPG signal is 0.5 to 5 Hz (Alian and Shelley 2014). Additionally, the shape of the PPG waveform differs from subject to subject and varies with the location and manner in which the pulse oximeter is attached. Theoretically, any body part can be used to measure heart rate through the sensor of the device, although finger tips and earlobes are commonly considered. The useful AC signal is only a very small portion of the whole signal thus filters are required.

and phototransistor placed side by side that are enclosed inside a leaded package so as to minimize the effect of surrounding visible light (TCRT100 2012). The infrared emitter emits light at a wavelength of 950 nm which passes through the skin and phototransistor receives the reflected wave accordingly. The change in volume caused by the pressure pulse is detected by illuminating the skin with the doide light and then measur- ing the amount of light reflected to a phototransister. The use of 950 nm wavelength ensures that only haemoglobin absorb the light (Malhi et al. 2012). Each cardiac cycle appears as a peak as shown in Fig. 3. Since blood flow to the skin can be modulated by multiple other physiological systems, the PPG can also be used to monitor breathing, hypovolemia, and other circulatory conditions (Reisner et al. 2008).

A fingertip placed over the TCTRT100 will act as a reflec- tor of the incident light. The amount of light reflected back from the finger tip is monitored by the phototransistor. The vol- atge signal obatiend at different nodes of the ciruit is indicated in Fig. 4. The V_in from the TCRT1000 is a periodic physiologi- cal waveform attributed to small variations caused by the pul- satile tissue blood volume inside the finger. The V_in signal also contains the unwanted DC signal and high frequency noise including 50 Hz mains interferences. The stage 1 of the signal conditioning in Fig. 4, suppresses the large DC component and boosts the weak pulsatile AC component, which carries the required information. The V_in is passed through high-pass filter (HPF) to get rid of the DC component. The cut-off frequency of the HPF is set to 0.7 Hz.

HPF Cutoff frequency,

fh = 2лR C .

1.2.1    Analog filter design                                                                ^{1  1}

 

A analog/traditional heart rate detector has been designed to detect the person’s beats per minute (BPM) using dicrete components (Malhi et al. 2012). The useful AC signal is only a very small portion of the whole signal, an effectiveThe signal is then passed though an active Butterworth low- pass filter (LPF) that is made of an Op-Amp (LM324) (LM324 2015). The cut-off frequency of the LPF is set to 2.34 Hz and is expressed as,

amplification and filtering circuit is generally used to extract

fl = 2лR C 

desired information from it 

The sensor used in this system is TCRT1000, which is a reflective optical sensor with both the infrared light emitter

Thus, the combination of the HPF and LPF helps to remove unwanted DC signal.The gain of the active low pass filter 

Gain = A

F ⎢ 1 + j� f  �⎥

where f is the frequency of the signal, f_l is the LPF and

A   = 1 +   R4 .

FR3

The traditional circuit for pulse detection utilizes discrete components and Op-Amps. The discrete components have their own tolerance limits which result into inaccuracy. More- over, it consumes appreciable amount of power in biasing of Op-Amps and also makes the system little voluminous and large which is undesirable for a wearable health monitoring system (Pantelopoulos et al. 2010).

1.2.2    Digital filter design

A digital filter has been designed to remove the discrete com- ponents from the traditional/analog heart rate detector circuit using Infinite Impulse Response (IIR) technique. In IIR tech- nique bilinear transformation method has been opted due to its one to one mapping of poles and zeros for converting analog signal into discrete time domain (Sklar 2009). The analog filter used for filtration and amplification of PPG signal is a com- bination of high pass and active low pass filter. The transfer function of these filter are converted to z-domain using bilinear transformation as,

 

s + a js= 2

z−1 z+1

2 + a T

2 − a T

(4)

 s j

² (z − 1)

H (z) =

j     =    

for high pass filter

j

 b

H (z) =

 

 

 

        b(z + 1)        

       =                               ,

 

s + bjs= 2

 

z−1             2 + b z −  2 − b

 

 

 

⊤   z+1                   T                       T

 

for low pass filter where, a =   ¹ ; b =    ¹   and T is sam-

 

 

Stage 2 is a repetition of stage 1 for further purification

 

pling time.

 

R1 C1

 

R2 C2

 

and strengthening of PPG waveform. The voltage at node

 

The theoretically derived digital filter transfer function

 

V₁ of the traditional circuit of has also been obtained

 

H₁(z) and H₂(z) are compared with digital filter approximation methods available in MATLAB. However the transfer function

 

using Multisim 12.0 and theoretical calculation has also

been performed. The same input signals are applied to the node V_in of the practical circuit and the output volt- age is observed at node V₁. The theoretical voltages are calculated using (3) and a comparision curve is shown in Fig. 5. Equation (3) reveals that as the frequency of the input signal increases the gain of the circuit decreases.

Finally, practical PPG wave form has been obtained on Tektronix TDS 2014C DSO by placing finger tip on TCRT1000 sensor as shown . The pulsating pulse obtained by ‘tustin’ method of MATLAB matches exactly with the theoretically derived transfer function of low pass and high pass filter from Eqs. (4) and (5)

The signal of node V_in is directly fed to the programming board (Arduino 2015) and the filteration, amplifaction of the signal has been carried out inside the Arduino. The signal is passed through a digital bandpass filter consisting of a low- pass filter (6) with a cut-off frequency of f_l (2.34 Hz) and a high-pass filter (7) with a cut-off frequency of f_h (0.7 Hz).

The filterd signal is then amplified accordingly,

 

obtained at node V_in is of low amplitude of 2 mV (peak to

 

y (n + 1) = y (n) ∗ e^−aT + 1 − e^−aT  ∗ x (n),

 

(6)

 

peak) and the SNR is also very low. The output of stage 1          0                       0                                                                                                                                  0

 

is then fed to a continuous set of similar filters for removal of noise to the maximum and to achieve significant amount

 

y1(n + 1) = y1(n) ∗ e^−bT + x1(n + 1) − x1(n).

 

(7)

 

of gain. Output of the stage 2, i.e. V₂ is then shifted up by using an adder circuit. Output obtained at the node V_o is the desired PPG signal. The observed PPG is almost similar to the normal/standard PPG signal.

 

Taking the sampling time of 0.01 s, the digital filter is

programmed in Arduino Uno and responses were captured for different methods available in MATLAB.

 

Table 1 Comparison of digital filter transfer function using different methods at T = 0.01 s

 

 

obtained signal at node V_in and PPG waveform after the digital filteration and amplification is shown in Fig. 7d.

 

Filter types/methods                  High pass filter transfer function

 

Low pass filter transfer function

 

The PPG waveform at node V_in contain noise as shown

in Fig. 7d and hence not suitable for heart rate measuremnt.

 

Analog filter transfer func- tion

Digital filter transfer function

 

    s       s+4.5455

 

1

H (z) = 0.9778(z−1)

 

 21.2766  

s+21.2766

H (z) = 0.0962(z+1)

 

The removal of noise with proposed digital filter is found to be effective as shown by red colour PPG signal in Fig. 7d where PPG waveform contain least amount of noise. The

 

using Eqs. (4) and (5)

Corresponding digital filters obtained using MATLAB

 

z−0.9556         2

 

z−0.8077

 

obtained filtered PPG signal was calibrated according to nor- mal human pulse rate of 60 BPM (Malhi et al. 2012). Then logic was implemented inside the Arduino to count the pulse

 

z−0.9556

‘tustin’ method                        0.9778(z−1)

z−0.9556

‘zoh’ method                            z−1

‘foh’ method                            0.9776(z−1)

 

0.09615(z+1)

z−0.8077

 0.1917  

z−0.8083

0.09922z−0.09243

 

duration of two successive maximum peak of the obtained pulse wave as in Eq. (8) in BPM,

1000 ∗ 60

 

z−0.9556

‘impulse’ method                    −0.04545Z

z 0.9556

−

 

z−0.8083

0.2128z+2.362×10⁻¹⁷

z−0.8083

 

BPM =

 

.

pulase duration between two succesive peaks

 

 

 

Figure 7 depicts the responses of digital filter obtained on implementing various methods available in MATLAB. The unfiltered PPG signal is shown in blue color whereas as fil- tered signal is in red. From the filtered response obtained, it is concluded that filter designed using ‘tustin’ had provided better filter response compared to other methods. Finally the obtained z-domain transfer by ‘tustin’ method has been implemented inside programming board for further process- ing using difference Eqs. (5) and (6).

The PPG waveform was captured at Arduino serial monitor by placing a finger tip on TCRT1000 sensor. The

 

(8)

Then the prototype was tested under different human activities like sleeping walking, sitting, brisk walking, run- ning and sprinting.

The heart-beat values obtained from the traditional PPG circuit are compared with the proposed digital filter after placing the finger tip on TCRT1000 sensor. The obtained curve is approximately a straight line which indicates that the developed digital filter is effective and is also able to calculate the heart beat accurately as compared to the tradi- tional PPG detector as shown in Fig. 8.

However certain factors like motion artifact, contact pressure have adverse effect on generated PPG signal which

 

 

 

 

Fig. 7 Digital filter responses with various methods available in MATLAB plotted in Arduino serial monitor. a Filter response using ‘foh’ method, b filter response using ‘zoh’ method, c filter response using ‘impulse’ method, d filter response using ‘tustin’ method

 

 

 

Fig. 8 Pulse rate comparison with traditional PPG circuit and pro- posed digital circuit

 

needs proper attention but these factors are not considered in this work which may be the possible reason of error (Muk- hopadhyay et al. 2017).

1.3    Impact sensor

 

An ADXL335 accelerometer sensor was used to detect the impact situations. It provides a complete 3-axis acceleration measurement system. The ADXL335 has a measurement range of ± 3 g minimum (ADXL335 2010). The output sig- nals are analog voltages that are proportional to acceleration. It can measure the static acceleration of gravity in tilt-sens- ing applications as well as dynamic acceleration resulting from motion, shock, or vibration. The accelerometer was placed inside the wrist band for prompt detections.

This sensor was mainly used to track the physical move- ments of the patient and monitor whether there were any cases of falling or sudden impacts on the patient’s body. The acceleration value was read in three different axes in an interval of every 2 ms. In the next step, the magnitude of the difference between two consecutive set of readings were measured which was then compared with the threshold value, to detect an impact of significantly large magnitude. Experiments were conducted to set the threshold value of fall. The everyday human movement like walking, sitting, standing, writing and jumping was simulated and data were obtained. It was concluded from the obtained data that at rest accelerometer reading ranges from 9.00 to 10.50 m/s2 and during freefall the acceleration value becomes less than

9.00 m/s2 and when collision occurs, it rises above 11.00 m/

s2.

The response of accelerometer after being attached to wrist-band were also tested for different activities as shown in Fig. 9a, b. The sudden sharp peak was observed when hit during normal activity like walking or writing. Using these data, threshold value for shock or hit to accelerometer was decided to be 15.0 m/s2 for the proposed prototype. The

 

output from the accelerometer was read at the ADC pins A2, A3 and A4 of the Arduino microcontroller. The difference in the sensed values also improved the accuracy of the whole sensing system.

 

2    Interfacing and communication

The microcontroller used in the wrist strap unit is the Arduino Uno. It is programmed to perform the operations like signal conditioning, computing, analyzing and is also responsible for communication. It takes inputs from the sen- sors in the form of analog and digital voltages. Each sensor has a dedicated port, A1 for the temperature sensor and A0 for the heart rate sensor. Each sensor’s signal is sampled at a pre-defined rate using Arduino’s interrupt driven algorithms.

2.1    Communication

 

Communication between the wrist unit and the receiver unit (user interface) is wireless. The data measured by the sensors is received by the Arduino microcontroller. An algorithm runs in the background to convert the sensed values to temperature in Fahrenheit and to calculate the BPM value of the person. A low power Bluetooth module HC-05 (HC-05 2010) is used for communication. In addi- tion, the network-setup of the sensors is easy, fast and scal- able. Hence, an extension of new sensing units is possible without any issues. The Arduino microcontroller is a low- power consumption module, with a built-in UART function for serial transmission of data to HC-05 module for wireless transmission.

2.2    The developed app

 

The developed app runs on an Android platform and is capa- ble of storing the received physiological parameter values on the smart phone itself in a local tiny data-base. These parameters are compared to the set value in the app and in case of a medical distress of the person, an alert message is automatically sent to friends, family members or doctors, whosoever’s phone number is registered in the app for emer- gency. This is achieved by using the normal SMS service of the mobile for communication. The sent alert message also contains the GPS location of the person that makes it simple to track the person. This application has been included in the system mainly for the blind and elderly people. The physi- ological parameters, health analysis and GPS location of the person are sent to the live online database by the devel- oped app automatically. However, the limitation is that the mobile must be internet enabled over WiFi or mobile data for the app to transfer these details to the cloud. The app was developed on the open-source MIT App Inventor 2 platform

 

 

 

Fig. 9 a Variation in acceleration reading when hit during normal daily activity. b Accelerometer’s response for forced hit to surface

 

 

available online (MIT App 2018). The developed App also includes the SMS texting component, GPS, uploading the values online to a database and saving the physiological parameters on a local data base on the Android smart phone as well. The corresponding components and elements are programmed in the Blocks section of MIT App inventor using the various objects. The algorithm flow develpoed for designing the app is shown in Fig. 10.

2.3    Online database

 

The online database was hosted using the Google Fusion Tables. Data is stored in Google’s cloud. All of the data are stored in a public table (or tables) that can be accessed via Google Drive, and allows different users to add information to the tables. Fusion Tables API V2.0 facilitates the storage, sharing, query and visualization of data tables. Application using Fusion Tables requires authentication with Goog- le’s servers. It needs an API Key which the app developer haveto authenticate. So, the end-users must login to access a Fusion Table. With this approach, we create credentials and a special “Service Account Email Address” which allows

 

end-users to edit Fusion Tables without logging in; our ser- vice account authenticates all access (MIT App 2018).

 

3    Prototype and experimental results

The actual prototype comprises of microcontroller devel- opment board Arduino Uno, low power Bluetooth module (HC-05) and sensor hub. The sensor hub contains tempera- ture sensor (LM35), heart rate sensor and 3-axis accelerom- eter (ADXL335) with signal conditioned voltage outputs. The heart rate sensor uses TCRT1000, reflective sensors which include an infrared emitter and phototransistor, for the determination of photoplethysmogram (PPG) signal as discussed in Sect. 3.2. The amount of light detected by the phototransistor varied with the patient’s heart pulse, as the amount of absorbed IR light changed with the flow of blood, which is directly linked to the heart rate. The PPG wave are then filtered and amplified for further processing. The ADXL335 measures the static acceleration of gravity and detects the impact situation.

The processing circuitry only contains programming board and the sensors were placed within the wrist strap and finger band.The prototype was powered from pins of the port of microcontroller.

The processed data is then transmitted to the devel- oped Android device through Bluetooth module HC-05. It has universal asynchronous receiver-transmitter inter- face with programmable baud rate. The RF transmission using HC-05 has been tested to operate effectively upto 40 meters range in the sight of line. TCRT1000 and tempera- ture sensors are mounted on the inner side of the finger band, positioned in such a way that it is in direct contact with the skin to sense the external body temperature. The actual body temperature is then calculated from the exter- nal body temperature. There can be various methods to estimate the actual body temperature from the external body temperature (Lenhardt and Sessler 2006), but with a rough estimation it was found that the body temperature was 4.8   C higher than the skin temperature. The blue- tooth module HC05 is place on one side and impact sen- sor ADXL335 on other side. The developed app displays various physiological parameter as shown in Fig. 13. The app has been designed to be user friendly. One can enter and save a friend’s, relative’s or doctor’s phone number

to which the health report or text message will be sent in case of emergency.

Figure 13a is the screenshot of the upper half of the devel- oped app that shows variouscomponents. The scrolled down screen of the developed app where the body temperature (in Fahrenheit), heartbeat value (in BPM) and the impact status are displayed as shown in Fig. 13b. The analysis is processed by the app based on the body temperature, BPM values and fall status. A local database saved on the smart phone stores the data as shown in Fig. 13c. A test was conducted to estab- lish the efficacy of the developed wearable system by com- paring the heartbeat obatined from the developed prototype with a commercially available activity tracker Xiaomi MI Band 2 (Xiaomi 2018). Several measurements of heart beat were taken during the various human activites like sleep- ing, running, jumping, walking and sprinting. The different activities gave rise and fall of heartbeat with a varied range of readings as shown in Fig. 14.

The x-axis is dedicated to the heart rate measurement obtained by Xiaomi Band whereas the y-axes represent heart rate measured by proposed prototype and its correspond- ing error. The obtained error plot is a zig–zag curve which shows the error at every measurement point together with its maximum possible error. A maximum error of + 2.54% is obtained as

The physiological parameters stored in the local data- base of smart phone were hosted online on Google Fusion Tables as shown in Fig. 15. The various columns created on Fusion table were Date, Temperature, Heart-beat, Analysis and Location. The body temperature was displayed in its raw format in Celsius as sensed by the LM35 sensor.The variation of body temperature and heartbeat over time can be constantly monitored by the caregiver of the patient. The link of the Fusion Table can be shared with a doctor for seeking rofessional help. The fusion table also allows to view the GPS location of the person through Google Maps in the same window itself. The developed wearable health monitoring system detects abnormality in patient status and sends a text message to its caregivers as shown in Fig. 16. Therefore, necessary help can be provided in times of dire need.

The developed app is able to gather data from the sensing unit which may be analyzed and stored for future refrences. Hospitals, caregivers or rehabilitation centers can monitor the patient from any location and respond appropriately, based on the alert received.

ALARM SYSTEM

Physiological data can  be  obtained  by  many  kinds  of  body  sensors  and  monitoring devices and health applications that may require health data. The data may  include  blood pressure, electrocardiography (ECG), heart pulse rate, electromyography (EMG), respiration, electroencephalogram (EEG), glucose monitoring, motion detection, thermometer, cochlear implant, blood oxygen—pulse oximeter (SpO2), artificial retina, weight scaling, sleep monitor and many others [19]. Whilst more sensors and data may be useful to determine an activity, vital signs are discussed. Only three vital signs (Heart rate, Body temperature and Respiration rate) are used for the experiments with body sensors as the fourth, blood pressure, cannot be measured practically during the undertaking of activities.

Vital signs are:

 

• Blood pressure (BP)—it is discussed but not used for experiments;
• Heart rate (HR);
• Body temperature (BT); and
• Respiration rate (RR).

Health data have unique traits as opposed to other sensor network data, and therefore they need to be treated and processed differently.

 

 

• There are inherent lower and upper limits imposed on the data. For instance, the human body temperature naturally falls within 35.5 ◦C (96 ◦F)–38.33 ◦C (101 ◦F) with a normal temperature of 37 ◦C (98.6 ◦F) [20], and critical deviations from these values would result in
• The normal values of sensed data vary depending on a user’s characteristics such as age and
• The same data could be regarded as normal or abnormal depending on the situation. For example, a heart rate of 150 beats/min is regarded as normal during running but is a cause for alarm during
• They are related with one another, e.g., a linear relationship between temperature and pulse rate with an average increase in heart rate of 4.4 beats/min for each 1 ◦C (2.44 beats/min for each 1 ◦F) rise in temperature over the range of temperatures examined (35.5 ◦C to 2 ◦C) [20].
• They are in the form of numeric
  • Activity Determination

Whilst current AR provides the real-time status of an activity, this information can be used for the inference system to determine a situation of the user and to infer whether to raise an alarm or not. By combining various data sources, it is possible to determine a situation or activity as physiological data are related to each other. When a user is running, for instance, the heart rate increases, body temperature goes up [21] and respiration rate also rises, and this information can be read together.

When sensors capture data, the actual value to be used is calculated to produce the health status value. Table 2 shows an example of how it can be calculated and weighed to find critical values by allocating different weightings for each sensor. Attributes can be each of the sensed data such as blood pressure (e.g., 140/90 mmHg) with systolic/diastolic, pulse (e.g., 97 BPM and Body Mass Index (BMI) (e.g., 24 = 170 cm/70 kg). Inferred values can be obtained by applying thresholds such as low, high, normal, abnormal. This can also include data such as male/female, age, related diseases, body weight, exercise tolerance and overall health condition [22]. They are used along with the weighting of the attribute which is the portion of which it affects health status. This is because not all attributes are equally affected by an activity or situation of a human who could be young or old, male or female or any other such variable. The outcome of the inferring process is to calculate a personalized range of normal thresholds for each attribute and to compare it with generic information. For example, comparing the personal blood pressure range (85/55–110/70 mmHg) to the generic range (90/60–120/80 Hg) of the specific group the user belongs to. Table 1 shows another example of how the weighted value can be used to calculate a situation activity when there is an “ambiguity of the situation” based on each application. Thus, the outcome in this case will be a determination of the user being in a “running” activity state. In the case of AR, the weighting is 100 which results in 100R (Running) activity. HR has a weighting of 20, which results in 20W (Walking). Therefore, the result shows 100R + 50R = 150R and 20W + 30W = 50W. Thus, the inference outcome (150 > 50) is one of running based on these weightings. These weightings are given arbitrarily, however, they should be defined by physicians or scientists.

Whilst the AR sensors indicate the status of activity motion, they do not show the level of activity such as the degree of tiredness from the accelerometer. Furthermore, the accuracy of the activity relies on the sensor location which can be unreliable if placed in the wrong location. To enhance the quality of the content, a combination of physiological and AR sensor data can be used to assess the situation.. These data can be used along with physiological data processed by an algorithm [23] in order to determine and verify the activity situation. The objective of situation determination is to infer whether the sensed data is in the range of the alarm threshold. Thus, when the result of sensed data does not fall into the appropriate field of the threshold, an alarm notification process is engaged.

• Algorithm Creation

There are traits in human activity and the reaction of physiological data to the activities. As the outcome of the experiment, some knowledge are obtained as the following:

• When an activity changes from a less active to a more active state, physiological data values of HR, BT and RR tend to increase as shown in Figure 3.
• When an activity or movement suddenly changes, it takes time for the corresponding physiological data to change
• Physiological data cannot represent or reflect instant movement changes, such as stopping for a few seconds during
• AR data alone cannot tell the degree or detailed content of
• The exercise intensity is an indicator of kinetic strength, and the Target HR is calculated by the Karvonen Formula [24] and Heart Rate Karvonen Formula [25] as defined by:

 

HR_T = ((HR_Max − HR_Rest) × %Intensity) + HR_Rest                                                                                                                                                     (1)

where HR_Rest is Resting HR, HR_Max is Maximum HR and HR_T is Target HR. Using Equation (1), the Android app calculates the training heart rate as below for our tester who wants to train for the intensity level of 50% to 70%, for example.

• Max HR: 220 − 16 = 204
• 204 − 67 (resting HR) = 137
• 137 × 50% + 67 = 136 BPM (minimum training HR)
• 137× 70% + 67 = 163 BPM (maximum training HR)

Based on these operations, they are compared to the actual averaged HR measurements in our experiment as in Table 4, Table 5 and Figure 9, which shows the values during walking (138 BPM) and running (155 BPM). This information is used to create an individualized threshold data for situation determination, which can be used together with other data such as Respiration and Body temperature to verify the AR data obtained by accelerometers. There may be a case of tricky results when combining the physiological sensor data after inference of their values. As shown in Table 1, the activity could result in a 50% Walk and 50% Run status after considering the weighting. In this case, the activity of AR data cannot be verified by the physiological data unless the weight has been reallocated to avoid this kind of situation. If this situation occurs, it remains as a dilemma and should be manually reviewed by a physician who can alter the weight or decide which inference to take. However, this is a rare situation and data from before and after that point in time can also be taken into account for determining the likely activity.

When there are multiple sensors and data obtained for the same attribute, e.g., heart rate, the inferred value is used to represent how the attribute locates the overall status of the individual’s health. In this case, it may not give many options to discern due to discrepancies.

As shown in Figure 4, it shows the gaps of two different data, which were taken from 30 min of walking while wearing two devices on the same wrist. This gap could be accounted for by averaging the values from the two data sources. When the number of sensors increases to more than two devices, it becomes more difficult to determine how to handle the data. When sensed data from various sensors are different and some of them are not consistent with the rest of the data, it needs to be an inferred point to decide on whether the specific data should be ignored or used.

• Alarm Notification Utilizing AR and Smart Device Application

In the age of smart devices, there are several possibilities to where user feedback can be sent. The two most pervasive are smart devices and smartwatches, where a user can receive a popup notification, and either ignore it or respond to it. Given the need for user simplicity, the system is designed so that notifications disappear automatically if no response is received, and any required feedback is in the form of single-tap buttons. When the smart device receives the alarm notification from the WBAN, it opens the app screen notifying of the alarm and allows the user to respond by selecting from a menu of options. If there is no response within a certain period of time, e.g., 60 s, this is deemed to be a “time out” and the app sends a confirmation message to the sensor node. If conditions persist to the thresholds of the sensor node, then the sensor node will take further action of raising the alarm to the next level, e.g., asking the user if they require help, and possibly notifying physicians or requesting emergency services as pre-programmed.

The app is capable of receiving any query from any sensor node, with answers received by all sensor nodes. As these are intended to be infrequent events and most often only during an initial training period, their effect on sensor node battery life is presumed to be negligible.

In the second stage of decision-making, a sensor node runs through the following logic:

1. The user feedback is received and averaged with existing user
2. If the user’s data is to be outside tolerance ranges, further action is
3. If user feedback is inappropriate for the current reading levels, further action is

When further action is warranted, a further prompt is sent to the user. From the app screen the user can select one of the options below as an example:

1. ‘No, it should not be an alarm (I am OK)’.
2. ‘Yes, I need help but not urgently (I am not OK)’.
3. ‘Yes, it is urgent and I need help ASAP (I am dying, please save me)’.

For option #1, the smart device notifies the sensor of a “false” alarm, and the sensor discards the alarm and cancels the notification. For option #2, the smart device notifies the sensor of a “true” alarm and the sensor continues with raising the alarm. The smart device app notifies the alarm to pre-defined parties. For option #3, the smart device notifies the sensor of a “true” and “urgent” alarm and the sensor increases the alarm level to maximum urgency. The smart device app notifies the alarm to pre-defined parties whilst emitting siren noises. CT or physicians may actuate the sensor device for further action if necessary.

When the smart device is triggered for alarm by the sensor, it opens the app and requests the user to verify the validity of the alarm situation. If the user cannot confirm to the pop up screen by whatever reasons, the screen remains until the set timer expires. In this case, the app regards the lack of response as being received as an “emergency”, and the smart device triggers the voice confirmation functionality with the pre-defined questions. These voice prompts are configurable by the app to allow each user to customise the questionnaire based on their individual situation. For example, when the user does not respond to the voice prompt, the smart device may ignore the alarm as a default action instead of automatically sending an alarm. Refer to Figure 6 for overall procedures of the information flow, and the following shows an example of the voice prompts which is also displayed on the app screen:

1. Should I call your doctor so that you can speak to him/her? (Yes or No is answered). If Yes, it calls the pre-programmed number. If No, it ignores the alarm. If no answer is received or failed to call, it moves to the next
2. Should I send an emergency to your doctor? (Yes or No is answered). If Yes, it moves to the next If No, it ignores the alarm. If no answer is received, it moves to the next step.
3. Should I transmit your health information to your doctor? If Yes, it transmits the user’s health information along with the alarm message. If No, it just sends the alarm message. If no answer is received, it moves to the next
4. Are you OK and should I ignore the alarm? (Yes or No is answered). If Yes, it ignores the If No or no answer is received, it finally transmits the alarm message.
   • App Design

The smart device app has multiple screens to display the alarm notification and examples are: Screen 1: Notification

1. Alarm is raised at “14:22:00 21 July 2016”
2. Slide to “ignore” (“false alarm” is inputted, and a confirmation message pops up) or “respond” (options screen is displayed with details of the alarm). A timeout event triggers the default

Screen 2: Details of the alarm

 

1. User ID (name/nick name);
2. Date and Time (incidence time stamp, current time);
3. Location (with GPS turned on the location may be displayed);
4. Sensed data which triggered the alarm, g., BPM 170;
5. Sensed activity, g., sitting;
6. Selection of 1 (false), 2 (default alarm), 3 (urgent alarm) or timeout, followed by a confirmation of the selection; and
7. Screenshot options and information flow are shown

When the user responds with details of the activity such as “resting”, “active” or “very active”, the information is sent to the sensor, which will discern the normality of the alarm and take appropriate actions such as to ignore, raise the default alarm or initiate urgent alarming. Figure 5 depicts the process of user actions, and Figure 6 shows an example of an app screen displayed on the smart device for the user to respond and input to.

• Sensor to App Communication

The app receives JavaScript Object Notation (JSON) data from the system or sensor nodes as requested by, e.g., UDP/IP, using WBAN interface and protocols such as Wi-Fi, Bluetooth, BT-LE, ZigBee, etc. [21]. The app looks at the “JSON key:value” pairs and simply displays each line. If a key ends in a question mark, then it is presented as an input, with an array of options provided for the user. The user can ignore these questions. The app will take no action if no user input is received. It will simply refresh the screen with any new sensor information or request when it is next received. Thus, the protocol is simple and lightweight, which is appropriate for its low-power energy requirements in WBAN. Upon reception of the user input, it is sent back to the same source IP address.

• Feedback-Enabled Activity Recognition

User feedback system allows any AR system to benchmark initial parameters unique to each user. Whilst Table 3 shows the resting heart rates (BPM) for men as a general guide [26], an individually prescribed threshold for activity can be prescribed by clinicians for each user as subject-specific training data are also required [27], as shown in Table 2. As an average man will have a different range of resting BPMs when compared to an athlete, as shown in Table 3, this cannot be applied to every male. Therefore, it is essential to create an individualized threshold table. Likewise, an AR system can also have a customized data set from learning and mining activity data using generic information obtained by big data as well as user inputs. A notification message can be individually customized such as the one shown in Figure 7. For example, the slow walking activity of an athlete may be a running activity of a child, and this difference can be accounted for by verifying with the child’s physiological data as a way to confirm their AR determined running state. In other words, the heart rate of 127 BPM is not necessarily considered to be “high” for other users as they may have a different range of thresholds.

The feedback system records a simple table per sensor node including the sensed information, the duration of sensed feedback, time, and user feedback. The application can further provide details of the activity as the heart rate, for example, will fluctuate during the “elevated” or “lowered” time. Therefore, the “start” and “end” times of the “activity” (or anomaly event), and the average during that period can also be included. This may require a separate table of the times and responses of each user feedback, linking to the ID of one “activity” period as there may be multiple responses if the activity lasts for a prolonged duration. This feature however is up to the application requirements.

SECURITY:

The main concern in RPM systems is the secure and efficient transmission of medical data. The inability to delete or change information from blocks makes blockchain technology the best technology for healthcare systems and could prevent these issues [8]. But Blockchain technology in its original form is not a long-term solution. It has limitations that when connected to IoT scenarios become very evident. In this section, we discuss the challenges for applying blockchain to IoT and explain how to solve these problems in our model.

1. System Requirements and Solutions

• Decentralization: To ensure robustness and scalability and to eliminate many-to-one traffic flows we need a decentralized system. Using such decentralized systems information delay problems that are seen on occasion with Blockchain. In our model, we are using an overlay decentralized network [9].
• Authentication and Security of data: User’s computers or cloud services store data that could be modified or lost  while  transmitting  itc˜  The preservation of such incorrect tampered data increases the burden to the system and can also cause issues to the patient using RPM. Therefore to ensure that data is not modified we use a digital signature scheme. On the receiver side, data is verified with the user’s digital signature and if received correctly, it sends a receipt of data to the patient.
• Scalability: Solving “Proof of Work” (PoW) is com- putationally intensive, however, IoT devices are very resource restricted [10]. The IoT network in most cases

contains a large number of nodes and Blockchain Tech- nology scales poorly to large networks as the number of nodes in the network increases. We eliminate the concept of PoW in our overlay network and also divide our overlay network into several clusters instead of a single chain of blocks. Therefore a single blockchain is not responsible for all nodes in the network, instead nodes are split into several clusters.

• Data Storage: Storing IoT big data over Blockchain technology is not practical and therefore we propose the use of cloud servers to store encrypted data blocks. The data can be interpreted as secure over the cloud due to additional cryptographic security present including digital signatures and high standard encryption [11].
• Anonymity of users: Medical data of a patient may contain sensitive information, and therefore data must be anonymized over the network. For anonymity, we are using a Ring structure along with digital Ring signatures allow a signer to sign data anonymously. That is to say, that the signature is mixed with other groups (named ring), and no one (except the actual signer) knows which member signed the message [12].
• Security of data: To save the data from hackers, we are using a double encryption scheme. We encrypt the data using lightweight ARX algorithms and then encrypt the data again using the public key of the receiver [13]. Also, we are using Diffie-Hellman key exchange technique to transfer the public keys and therefore to get the keys is almost impossible for an attacker [14].

1. OUR PROPOSED SYSTEM Our system consists of five parts:

• Overlay network
• Cloud storage
• Healthcare providers
• Smart contracts
• Patient equipped with IoT
• Overlay network: An overlay is a peer to peer network that is based on a distributed architecture. The nodes connected to the network could be a computer, smart- phone, tablet or any other IoT device as To increase network scalability and avoid network delay, we group the nodes in the form of many clusters. Each cluster has one Cluster Head. Each cluster head has a unique public key which is shared with other clusters using the Diffie-Hellman algorithm. The cluster head also contains the information about the public keys of nodes which are allowed to access data from the network. These networks only contain the hash of the blocks (not the original data which is stored in the cloud). Each block also contains the hash of the previous block, and therefore we can treat it similar to the blockchain.
• Cloud Storage: Instead of saving the IoT healthcare data over blockchain directly, we use cloud storage servers to save the patient The cloud storage groups

 

user’s data in identical blocks associated with a unique block number. Cloud storage is connected to overlay networks, once the data stored in a block, the block is encrypted using the shared public key of the user, and cloud server sends the hash of the data blocks to the overlay network.

• Healthcare providers and Patients: Healthcare providers are appointed by insurance companies or by patients to perform medical tests or to provide medical Healthcare services provide treatment to patients once they receive an alert from the network. Patients themselves are the owners of their personal data and responsible for granting, denying or revoking data access from any other parties, such as insurance company or health care providers [15].
• Smart contracts: Smart contracts allow the creation of agreements in any IoT devices which is executed when the given conditions in the contract are met [16]. Con- sider we set the condition for the highest and lowest level of patient blood pressure. Once readings are received from the wearable device that do not follow the indicated range, the smart contract will send an alert message to the authorized person or healthcare provider and also store the abnormal data into the cloud so that healthcare providers can receive the patient blood pressure readings as well when needed in real

 

1. CRYPTOGRAPHIC TECHNIQUES USED IN THE MODEL

Instead of only one type of encryption technique, we use both encryption schemes, Symmetric and Asymmetric for different purposes. Symmetric algorithms (Private key encryption) use the same key for both encryption of plaintext and decryption of ciphertext, whereas asymmetric algorithms (Public key encryption) use different keys for encryption of plaintext and decryption of ciphertext. We use the variable name k_sym for the private key or symmetric key in our algorithms, and the same key will be used for encryption and decryption on both side of the transmission.

An asymmetric encryption sender will have one key pair (sk_priv, sk_pub), and receiver will have another  key  pair (rk_priv, rk_pub). Data can be encrypted using receivers public key rk_pub and can be decrypted using her private key rk_priv. Generally, we use abbreviation plaintext (P ) for the normal data file and ciphertext (C) for the encrypted data file.

 

1. ARX Encryption Algorithm:

In our model, we are using a particular branch of the Symmetric key, called ARX algorithms to encrypt the data for Blockchain. These algorithms are made of the simple op- erations Addition, Rotation and XOR and support lightweight encryption for small devices. One example of the latest good ARX cipher is SPECK [17], [18], designed by National Security Agency (NSA), US in June 2013. SPECK is a family of lightweight block ciphers with the Feistel-like structure in which each block is divided into two branches, and both

branches are modified at every round. Each block size is divided into two parts, left half and right half.

 

1. Digital Signature:

We add a digital signature to the data for authentication purposes. Digital signatures are the public-key primitives of message authentication. Each user has a public-private key pair. Generally, the key pairs used for signing/verifying and the key pairs used for encryption/decryption are different. In our case sender will have one key pair (sk_spriv , sk_spub ), and receiver will have another key pair (rk_spriv , rk_spub ). The senders private key sk_spriv is used to sign the data, and the key is referred to the signature key while senders public key

 

Algorithm 1 Data Encryption                                                  

1: function ENCRYPTION (data  file)

2:          if user confirm data preservation over blockchain then

3:                  Generate a symmetric key k_sym

←

4:                 C       Encrypt_sym  (data  file, k_sym)

←

5:                 C_k       Encrypt_asym  (k_sym, rk_pub)

6:          else

7:                  Do nothing

8:          end if

   9: end function                                            

For    the     digital    signature    senders    can     use    two keys     (sk_s                      , sk_s     )             that is         different     from            the

 

sk_s

 

is used for verification on the receiver side of the

 

pub

 

priv

 

pub

transmission. Signer feeds the data or plaintext into the Hash

Function and generates the hash value hash_p. Hash value hash_p of plaintext and signature key sk_spriv are then fed to the signature algorithm and sent along with the encrypted data. During the verification process, the verifier generates the hash value hash_r of the received data from the same hash function. Using the Verification algorithm and signers public key, he also extracts the original hash value hash_p of plaintext and if the value of hash_p and hash_r are same then data is verified and not changed during the transmission process.

 

1. Ring Signature:

We use Ring signature technology, which allows a signer to sign data in an anonymous way. The signature is mixed with other groups (named ring) and no one (except actual signer) knows which member signed the message. Ring Signature was originally proposed by Rivest in 2001 [19]. A user desiring to mix his transaction sends a request to the Blockchain network.

 

encryption/decryption keys. To add the digital signature, the sender first passes the data file to the Hash Function and creates the hash value hash_p of the data. Then he signs the data using his private key sk_spriv by passing the value of the private key and hash value hash_p to the Signature Algorithm. The signers public key sk_spub can be used to verify data on the receiver side. To apply the Anonymity of the patient or user, we add ring signature in our Algorithm 2.

 

 

Algorithm 2 Ring Signature and Public Key Sharing            

1: function SIGNATURE (data  file)

2:          if user chose anonymity over blockchain then

3:                  Generate a asymmetric public-private key pair

(skspub , skspriv )

←

4:                  hash_p       calculate hash of the data file

5:                  Create the Digital Signature using hash_p and signers private key sk_spriv

:                    Share the public key sk_spub to the receiver using

 

The request comprises of the public key sk_s

 

pub

 

. After receiving

 

Diffie-Hellman key exchange

7:                  Mix the signature with other network group to

 

the request the network sends back a certain amount of public

|

keys   (sk1_spub , sk2_spub , sk3_spub , sk4_spub      which are collected from other  users  (u₁, u₂...u_N )  who  also  applied  for  mixing

 

form a ring

8:          end if

 

service, including sk_s

 

pub

 

. Using ring signatures in our model

 

   9: end function                                                                       

 

we can get two important security properties. They are Signers Anonymity and Signature Correctness.

1. ALGORITHMS

In our encryption Algorithm 1, we encrypt the data file by using the symmetric key k_sym and produce a ciphertext file C. After encryption, we use double encryption technique and encrypt the key k_sym by using the public key cryptography. We use the receivers public key rk_pub to encrypt the symmetric key k_sym and send the encrypted key along with the ciphertext C. We denote the encrypted symmetric key with C_k.

 

The user will ask the network for other accounts who also want to add ring signatures to their transactions. The network will then provide them with a set of users who also wish to apply ring signatures. The sender’s transactions are then mixed with other users transactions and sent over the network. No one will be able to identify the original signer of the ring group. The process is described in the block diagram (Figure 1) of our model.

To decrypt the ciphertext data C (Algorithm 3), we need the symmetric key k_sym. The symmetric key was encrypted using the public key rk_pub of the receiver, and therefore receivers private key rk_priv can only decrypt the symmetric key. We first decrypt the C_k using the private key rk_priv of the receiver and get the original symmetric key k_sym. We apply the key to the ciphertext C and get the original plaintext or data file.

Algorithm 3 Data Decryption                                                  

1: Input: Encrypted file C, Encrypted symmetric key (C_k)

2: Output: Decrypted data  file

3:   function DECRYPTION (C, C_k, rk_priv, k_sym)

←

4:          k_sym       Decrypt_asym  (C_k, rk_priv)

←

5:          data file      Decrypt_sym (C, k_sym)

   6: end function                                                                        

 

During the verification process (Algorithm 4), a Verifier generates the hash value hash_c of received data (ciphertext) using the same hash function. Also, the verifier feeds the digital signature and the verification key into the verification algorithm and extracts the hash value hash_p of original data (plaintext). If both hash values are equal, it means data file is not modified during transfer between sender and receiver.

 

Algorithm 4 Signature Verification                                         

1: Input: Encrypted file C, Signers Public key (skspub )

2:   function VERIFICATION (C, skspub )

←

3:          hashc          calculate hash of the received encrypted data file

C to be verified

 

known devices which are constantly evolving in today’s medi- cal world. The health information is sent to smart devices such as a smartphone or tablet for the formatting and aggregation by the application. Once complete, the formatted information is sent to the relevant smart contract for full analysis along with the threshold value. The threshold value decides whether the health reading is NORMAL as per standard readings or not. If the health reading is abnormal, then the smart contract will create an event and send an alert to the overlay network and to the patient. Also, it stores the abnormal readings to cloud servers and cloud server transfer the hash of the stored data to the overlay network. When health data is transferred to the cloud server, the sender adds a digital signature to the data. Overlay network then sends an alert to the health providers. Here, we are not storing the health readings to the overlay network, but we only store the transaction alert to the overlay network.

Health Alert Events should also be anonymous, and pri- vacy preserved to the overlay network. We treat this alert as a transaction of the specific user and apply all advance cryptographic techniques according to the algorithm explained

 

4:          Using Public key sks

file

 

pub

 

of signer, extract hashp of senders

 

in Section V. Here the entity who is sending the information could be treated as a sender and the entity who is receiving

 

5:          if hashc = hashp then

6:                return C

7:          else

8:                return “Signature incorrect”

9:          end if

10: end function

 

 

1. MODEL IMPLEMENTATION

In our system, the patient is equipped with wearable devices such as a blood pressure monitor, insulin pump, or other

 

the information could be treated as a receiver. Here we only describe the flow of data in our system and do not describe all the encryption/decryption technical details as we already explained cryptographic techniques in above sections by taking a general model of the sender, receiver and network. An overlay network contains the public key information of all connected nodes and hash indexes of the stored data over the cloud. Once the healthcare provider node gets an alert, he/she access the full health reading of patient for which he/she is authorized over the network.