Wearable Sensors Integrated with Internet of Things for Advancing eHealth Care

Health and sociological indicators alert that life expectancy is increasing, hence so are the years that patients have to live with chronic diseases and co-morbidities. With the advancement in ICT, new tools and paradigms are been explored to provide effective and efficient health care. Telemedicine and health sensors stand as indispensable tools for promoting patient engagement, self-management of diseases and assist doctors to remotely follow up patients. In this paper, we evaluate a rapid prototyping solution for information merging based on five health sensors and two low-cost ubiquitous computing components: Arduino and Raspberry Pi. Our study, which is entirely described with the purpose of reproducibility, aimed to evaluate the extent to which portable technologies are capable of integrating wearable sensors by comparing two deployment scenarios: Raspberry Pi 3 and Personal Computer. The integration is implemented using a choreography engine to transmit data from sensors to a display unit using web services and a simple communication protocol with two modes of data retrieval. Performance of the two set-ups is compared by means of the latency in the wearable data transmission and data loss. PC has a delay of 0.051 ± 0.0035 s (max = 0.2504 s), whereas the Raspberry Pi yields a delay of 0.0175 ± 0.149 s (max = 0.294 s) for N = 300. Our analysis confirms that portable devices (p<<0.01) are suitable to support the transmission and analysis of biometric signals into scalable telemedicine systems.


Introduction
Internet of Things (IoT) is a framework in which sensors, devices and actuators can be managed in an ubiquitous and distributed way [1]. The health sector is not outside of the IoT revolution and there already exist multiple applications and services for improving health care quality [2].
Within this context, telemedicine is an ideal scenario for the expansion and improvement of health IoT technologies [3]. Remote monitoring using accessible and easy-to-use sensors are the avant-garde of the application of these type of technologies [4].
Distributed systems for remote monitoring have been presented elsewhere [5,6] describing two main types of architectures. On the one hand, the first type of system allows storing biometric, behavior and context variables from commercial sensors into devices (mobile phones, tablets and data descriptors which are only useful for high communication layers. Although messages should be controlled by standard quality metrics and procedures, adding unnecessary data to wireless physical interfaces may cause more problems than what they actually tend to solve. Moreover, when moving towards a real user case in which patients and health professionals exchange data, there are needs of deploying a Graphical User Interface (GUI), for instance a webpage running on a specific webserver (or even a mobile application), which adds hurdles to the potential and strengths of the interconnection of distributed systems.
In this paper, we present and evaluate an embedded distributed system with a custom lite protocol for the connection of cheap health devices based on prototyping eHealth solutions (Arduino, Raspberry Pi, and biosignals kit). All components are interconnected using the process choreography paradigm [21,22]. To evaluate the extent to which portable devices can be compared with fix systems, the overall deployment has been configured into two different deployment scenarios: (1) Desktop Computer with Windows 10 Operating System; and (2) Raspberry Pi with Windows 10 Core IoT Operating System. The same functionalities for requesting and retrieving data from health sensors and hosting an HTLM5 webpage were embedded into the two systems to compare a key performance indicator: the time delay between acquiring and displaying the bio-signal. Our experiments confirm the expected hypothesis, that is: portable components have an increased latency in the communications, but this latency is negligible. Portable devices are suitable to support the transmission and analysis of biometric signals into scalable telemedicine systems. Our conclusion is that portable computing fosters new opportunities to expand the use of wearables in health care research. Strengths of the proposed system are the open specification of the protocol, the open-communications method using standard communication structures (based on XML) and choreography, and the direct connection to open-source hardware components. These results make it possible to enhance the system for other domains, such as Ambient Assisted Living (AAL) and smart-home sensors.

Material and Methods
In this section, we describe the materials and methodology we used to test the two deployment scenarios for a remote health management system. We first describe the hardware to sense biometric signals using the eHealth Sensors kit and Arduino. Second, we describe the integration paradigm based on service choreography. Third, we describe the communication protocol. Finally, we describe the experimental setup.

eHealth Sensors Kit
Arduino is an open-specification platform based on an ATmega328P micro-controller with the minimum capacity to execute simple programs (sketches). Arduino provides an easy but effective hardware to connect and use many electronic components with a wide variety of applications [23,24]. The official website of Arduino [25] has a comprehensive collection of information, downloads, tutorials and examples about how to use the platform.
Arduino provides an excellent platform to test and prototype solutions by adding supplemental modules (Bluetooth, WiFi boards, LEDs, and servo-motors) and other hardware. In this research, we have set up the eHealth Biometric Sensor Platform created by Libelium [26]. This kit allows users to acquire a set of physiological signals such as ECG, EMG, breathing rate, surface temperature, GSR, blood glucose and SpO2 (Table 1). eHealth kit has been used in wearable sensors research [27,28].
The Libelium kit is not a certified medical device. We used this platform as a virtual medical device because it implements the same physical interfaces and monitoring circuits as certified and commercial sensors do. Moreover, it prevents us from developing manufacturer protocols to retrieve raw physiological signals to test our principal hypothesis.

Temperature Sensor
Body temperature depends upon the place in the body in which the measurement is made, and the time of day and the level of activity of the subject. Different parts of the body have different temperatures.

Airflow Sensor
Respiratory rate is a broad indicator of major physiological instability. The sensor measures the breathing flow of a person in the up airways (nose). Airflow sensor can also provide an early warning of hypoxemia and apnea.

Continuous data
Galvanic Skin Response Sensor (GSR) It can be used to measure the electrical conductance of the skin, which varies with its moisture level. Skin conductance is used as an indication of psychological or physiological arousal. GSR measures the electrical conductance between 2 points, and is essentially a type of ohmmeter.

Electrocardiography Sensor (ECG)
A diagnostic tool that is routinely used to assess the electrical and muscular functions of the heart. ECG has grown to be one of the most commonly used medical tests in modern medicine. Some diseases have no modifications on ECG waveform.

Electromyogram Sensor (EMG)
It can be used as a diagnostic tool to evaluate and record the electrical activity produced by skeletal muscles by measuring the electrical activity of muscles at rest and during contraction. EMG is used for identifying neuromuscular diseases, assessing low-back pain, kinesiology, and disorders of motor control.

Continuous data
The whole sensing information detection part for biometric information relies on the Arduino eHealth Sensor Kit ( Figure 1). These sensors can be used as diagnostic tools in clinical settings and also used to remotely monitor the state of a patient in real time. Some of the sensors which use the electro-physiological techniques (e.g., ECG, EMG, and GSR) require a time series to make a sense of them. All biometric sensors should be integrated on one Arduino board to collect comprehensive biometric information at the same time.

Choreography Integration
One of the objectives to improve health care services is to provide reliable remote access to the data retrieved by the sensors of the eHealth kit. A Service Oriented Architecture (SOA) involves the use of weakly coupled services to support such processes in a high inter-operable way. In an SOA environment, network resources are available through services which can be accessed through standard methods. Masking such resources with services allows accessing them without the needs of knowing how they were implemented internally.
The software enabling communication between the sensors and the displaying interfaces was implemented using a choreography engine [12], a semantic engine capable of connecting registered services and functions. The Choreographer dispatches messages among the modules using a specific eXtensible Markup Language (XML) message protocol called eXtensible MeSsaGe (XMSG) [21]. XMSG is based on the Foundation for Intelligent Physical Agents (FIPA) recommendations [29] and Simple Object Access Protocol (SOAP) [30] headers to route and characterize messages. The XMSG protocol allows broad-/multi-cast, as well as Peer to Peer (P2P) message calls, using custom symbols in the destination address. XMSG can be serialized and transmitted over any transport protocol such as REST and HTTP.
Services are designed to fit into three categories: serial communication, data translation and web-client. The client part is defined as a web service to deliver an interactive interface in a web browser. Serial communication service establishes the connection with the Arduino hardware to read data from wearable sensors. The translator service verifies data packets and translates information according to a predefined communication protocol. After extracting data from the packets, a new message is generated and sent to the client service to be displayed in web interface. These services also allow controlling the sensors (turn on/off, change sampling frequency, etc.). Figure 2 draws the information flow between the hardware and the interactive interface. Figure 3 shows a schema of the physical connection of the components, enhancing the information flow of Figure 2. In this schema, we show how the wearable sensors are connected to the Arduino + eHealth shield and how this component enables the communication to the Choreographer software (blue cross) in the Raspberry and other applications in the Pebble smart watch. In this paper, we have analyzed the flow of information through the serial communication port to the Choreographer, and then, from the Choreographer to the webpage by using WiFi interface. The webpage is a front-end which can be executed in a browser on any computer/tablet.

Communication Protocol
Once the sensors have been connected to the eHealth shield, the most important issue is to define a communication protocol to ensure correct data transmission. As illustrated in Figure 3, information should be handled between the webpage and the Arduino board through a distributed system (Sensors + Arduino in Location A and the Webpage in Location B). This type of information involves sensor data (type of measurement, value, units, time stamp, etc.) and the control commands that manage the sensors. Besides, error detection mechanism should also be added since the messages may be corrupted during the transmission.
Two operational modes are defined for operating with sensors. This first is the Active mode, through which sensors can automatically collect and send measurements to the software at every time interval according to their individual settings. Thus, data from all sensors can be displayed in real-time. The second is the passive mode, which implies that users can send different commands from the webpage to a specific sensor to request its data or change acquisition parameters. Users should be capable of interacting and operating with sensors: to request the current value of a sensor, to stop data retrieval, to set the time interval, etc. The structure of the commands is described in Tables 2  and 3. Therefore, the protocol should consider the following descriptors: Kit Type: Type of the sensor kit used for extensions to other type of sensing environments such as smart homes. Destination: Name of the sensor which identifies the destination of the command. Command: Different commands which can be used to ask for the sensor data or change some default settings. Parameter: This field corresponds to the Command field for changing some settings (e.g. transmit the parameter of the time interval in active mode). Checksum: The checksum field is the 16 bit sum of all bytes of the command packet. It can be used to detect command error which might be introduced during the transmission. Sensor Type: Name of the sensor which sends data or response. Response To: This field indicates which command the sensor is responding to, so the communication can be asynchronous. Data: This is the data part measured by the sensors or the answer of the command. Unit: This field corresponds to the Data field and it is the unit of the data. The format of the sensor data packet and response packet is shown in Table 3.

Portable Embedded System
Raspberry Pi was introduced in 2012 [31] and has been extensively used in home monitoring environments [32,33]. It integrates a computer board with support for many input and output peripherals through standard interfaces (Serial, Bluetooth and Wi-Fi) and allows the installation of several operative systems. Dimensions of the device are 85.60 mm × 53.98 mm × 17 mm, with a weight of approximately 45 grams. The device is cased and mounted inside a plastic box with a 7 inch touchscreen and powered with a battery. Raspberry Pi 3 is a platform suitable for embedding high level applications which allow the interaction with different devices and users in a wide range of applications. In this study, we used the Raspberry Pi 3 with the operating system from Microsoft Windows 10 IoT Core [34]. Windows 10 IoT Core is an optimized version of Windows 10 for small portable ARM and ×86/×64 devices. One of the aims of this paper is to evaluate the extent to which portable systems are ready to substitute computers in the way they connect and process information coming from several eHealth sensors. To this end, we will evaluate the Raspberry Pi 3 in comparison to a desktop computer.

Design of Experiments
The proposed system must provide a record track of the executed services, their results, time stamp and other audit information. A track component should be in charge of recording the trace of all the activities that take place during the performance of the system. The records must be standardized (or even normalized), understandable and ready to be parsed and mined. Therefore, this component will record all interaction events among the modules and components.
The experiments assessed the communication delay between distributed physical components among service request and service response for all integrated sensors. The main key performance indicator is the latency, which is defined as the difference of time between the start of the transmission of the first message and the end of the correct reception of the last message [18]. The latency wasmeasured and compared in two environments using the same choreography software: Due to the skewed distribution of the latency parameters, a Wilcoxon signed-rank test at 95% C.I. was used to assess the independence of intra and inter schema differences. Significance was assumed for p < 0.05. Statistical and graphical analysis was done using Matlab 2016R version using Academic License.

Results
The choreography engine uses SOA and implements a Windows Presentation Foundation GUI [35] application with several services declared and running in the background. Each service represents a specific functionality and different services interact with each other by passing messages.

Choreographer Functions to Manage eHealth Sensors
The services for accessing eHealth sensors are managed by the choreography engine ( Table 4). As shown in Section 2.2, the Arduino board communicates with the serial communication service, and, analogously, users interacts with the web dashboard to request data from sensors. The translator service performs as a middleware by connecting the web service and serial communication service while data are exchanged between entities. Figures 4 and 5 show the sequence diagram of the three services.   Illustrated by the sequential diagram in Figure 5 and Table 5, the translator service is one of the most crucial parts of the overall architecture since it is the only service which implements the communication protocol. Each sensor has one translator and different methods are used to parse the information coming from the serial communication service or encapsulate various commands received from web service into command packets.

SetActiveMode(onOff)
If the parameter is on, start active mode of the target sensor and request for the continuous data. If the parameter is off, stop active mode.

ChecksumCalculate(command)
Calculate the checksum of the full command and append it at the end of the packet. Each sensor has an individual webpage to control and display biometric signals. Therefore, for passive mode, once a user taps a button on the webpage to request data or set up operational modes, the web service sends a command to the corresponding translator. The translator service identifies the intent of the request and translates it into the predefined format, adding header and checksum to the command, and then sends the restructured new message to serial communication service. When the Arduino board receives the message from serial communication service, it retrieves Destination and Command information to effectively execute the command (e.g., read ECG).

Serial Communication
After executing the command, the Arduino board generates a response packet for answering the request. The serial communication service transmits the packet to all translator services and each translator has to verify and parse it if it is a valid message. Translator service is able to distinguish which request this packet answers by means of Response To field. The Data part and Units part are then extracted and transmitted to the target web service by referring to Sensor Type part of the packet. Finally, data are shown on the webpage using a time series chart.
To illustrate the operation in detail, we can take body temperature data request as an example. When the user clicks the button on the webpage to request body temperature, the Body Temperature Web Service calls getData method in Body Temperature Translator Service and the translator starts to construct a command packet. It sets the Kit Type field as EHEALTH, Destination field as BODYTEMPERATURE, Command field as GETDATA, no Parameter and uses delimiter '|' to concatenate each individual field. After calculating the checksum of the whole command, it is appended as the tail of the packet and the resulting command packet stands as "EHEALTH|BODYTEMPERATURE| GETDATA||2657".
Similarly, when the Arduino board finishes reading the command, it creates a data packet and sends it to the serial communication service. The data packet could look like "EHEALTH|BODYTEMPERATURE|GETDATA |36.5|C|3052". Later, it will be transmitted to Body Temperature Translator Service, where the checksum of this packet will be calculated again and compared with the original one. If there is a match, the packet is validated.
For the active mode, the web service should send a setActiveMode command with parameter on. Once the active mode has been configured, the Arduino board will send the specific sensor data at a predefined rate. This behavior will not stop until another setActiveMode off command is triggered. When it comes to sensors such as the ECG, Airflow and GSR, the active mode can be extremely important. These continuous data are collected and utilized to generate a biometric signal for real-time monitoring.

Track Component
The Choreographer included a service to keep track of all the exchanged messages across components. As the limitations on the time resolution deserved special attention and open a brand new study field, all the interactions on the webpage were recorded in a special format and placed in a basic Comma-Separated Values file (to make easy the access for the information). A file named choreo_track was automatically generated upon first launch of the system (see Figure 6). A main class controlled the interaction events during a session and tracked them in that file. Each interaction event was written in a line with the following format: <Timestamp>, <sender>, <receiver>, <message>

•
Time stamp: dd/mm/yyyy hh:mm:ss.sssss. • Sender: The module who triggered or controlled the action (see Figure 2). • Destination: The module who was receiving the service request. • Method: To indicate whether it was a request or an inform method.

•
Message: The data exchanged, for instance the packets described in previous sections.

Raspberry Pi for Hosting and Serving a Webpage
Web service representation for both scenarios are based on RESTful (Representational State Transfer) service. A service in the Choreographer is in charge of serving a webpage based on JavaScript and HTML5. The implementation is based on the .NET v4.5 framework for webservers and implementation of RESTful services. As Figure 7 shows, in the case of the computer implementation, libraries are directly used from Windows Communication Foundation (WCF), whereas, for the Raspberry, the use of RESTUP libraries was needed [36]. RESTUP maps web service libraries from WCF to be compatible with Windows 10 IoT Core operating system. Other studies have shown good results by implementing this architecture based on Apache Server [37].  Figure 8 illustrates the final system. The picture shows the first term the Arduino Uno mounted with the eHealth shield and the health sensors kit. Different sensors should be connected to the eHealth shield. The EMG sensor and the ECG cannot work simultaneously since a jumper should be switched in the board to use one adaptation circuit or another. The Arduino is connected through a USB interface to the Raspberry Pi or the PC, in which an instance of the Choreographer is installed.

Deployment
The computer screen shows the welcome page of the web application, which shows access to analyze data from the five sensors (the three buttons are for the three variables of the GSR sensor). After clicking on each button, the user can access individual pages for each sensor where different operations can be executed. For sensors such as ECG, EMG, GSR and Airflow sensor, single datum seems meaningless, thus users can start active mode to monitor and graph real-time sensor data. Besides, it is also feasible for users to set a time interval to retrieve past values from the sensors. Once these values are prepared, a chart would be plotted for each different set of data. The chart is real-time updated (see time delays in Figures 9 and 10), and it is refreshed every 250 ms. For body temperature sensor, apart from the above functions, users can access current body temperature data by clicking GETDATA button.
The Raspberry Pi (below the screen) shows the control Graphical User Interface of the Choreographer. The Choreographer was created similar to a tab in our window, containing graphical services which can be used to manage the five sensors in the system. By doing so, users can interact with the sensors without the needs of accessing the webpage.

Experiments
Sensors that support the active mode (ECG, EMG, Airflow and GSR) have a default sampling rate set to 20 Hz (20 Samples per second); this means that the interval between two samples is 50 ms for both PC and Raspberry Pi. Besides, the webpage is set to request data every 250 ms. The experiment shows that the PC deployment generated less latency in the communication segment between the Arduino and the Choreographer (Figure 9). Our measurements correspond to the theoretical sample period, which is 50 ms. Nonetheless, we do not see this behavior in the Raspberry Pi: The mean value of the time delay is around 50 ms, but the standard deviation is greater than the standard deviation of the PC. These points are distributed sparsely but showed the pattern of an arithmetic series. The gap between two corresponding points is approximately 10 ms to 20 ms.
The communication of the active mode between Choreographer and webpage ( Figure 10) shows a similar situation. The PC shows a good result with all the measurements concentrated around 250 ms. We see a different pattern in the Raspberry PI with all the measurements with a fixed interval (mean value is 250 ms and the gap is about 10 ms to 20 ms).
We compared the communication segment between the Arduino and the Choreographer for the two deployments (Raspberry and PC). This segment is composed of the Serial Communication Service and the Translator service. Results show that Raspberry Pi has a statistically significant increased delay (p << 0.01) for all the five sensors, whereas, for the segment between the Choreographer and the web service, all sensors except ECG showed a not statistically significant increased delay (for ECG p << 0.01, and p > 0.5 for the rest ). Figures 9 and 10 show the cumulative scatter plots for the delays tracked with the tracker component ( Figure 6). Even though the results are scattered, it is notorious that the delay experimented for the Raspberry Pi shows a clear pattern (especially for ECG, EMG and GSR in Figure 10). This pattern may be caused by the internal delay of the Arduino for acquiring measurements (10 ms-20 ms), and the reason of not having it on the PC may depend of the communication stack, which is bigger in the PC. In this case, the Choreographer can fill the memory stack with more measurements which will be delivered faster to the web interface. Another finding involves the precision of time intervals. The PC shows a bigger reliability by means of a lower standard deviation and a lower range. As an example, for the EMG communication between the Arduino and the Choreographer (Figure 9), the PC has a delay of 0.051 ± 0.0035 s and a range of 0.2504 s (N = 300), whereas the Raspberry has a delay of 0.0175 ± 0.149 s and a range of 0.294 s (N = 300). Therefore, the Choreographer achieves a higher reliability for acquiring measurements if deployed in a PC.

Discussion
In this paper, we present an integration of two innovative paradigms: Health Sensors and IoT focused on simple deployments. These two streams, which are widely accepted by the scientific community, are seen as the future of how information and communication technologies can make health care system sustainable. Moreover, the connection of these two paradigms with new ubiquitous computing and artificial intelligence models can promote the crucial step-forward for the adoption and spread use of health sensors for the management of chronic conditions.
In this context, forecasts on the increment of the population over 60 years old in developed countries and the pandemic dimension some diseases are reaching deserves special attention. Health care systems are not prepared to sustain these numbers and there is increased demand for better and personalized care services. This is the main reason that pushes us to propose cheap and scalable solutions that allow users to plug and play them without the need of understanding complex standards or programming frameworks.
One of the flagship projects on the evaluation of remote care presented in Section 1 (Whole System Demonstrator Programme) has demonstrated favorable results on the management of patients with chronic conditions, but stating that the technology is not yet ready for scaling-up [11]. The system proposed and evaluated in this study is based on a Service Oriented Architecture with a central component (Choreographer). The Choreographer works as a message dispatcher that allows connecting different modules (health sensors, webpages, etc.). The simplicity of the Choreographer prevents us from using another type of complex integration solutions like Enterprise Serial Bus (ESB), which provides a gain on the performance of its execution and fault tolerance [20].
The Choreographer relies on existing libraries and communication stacks of Microsoft .NET v4.5 framework, a key element for ensuring its reutilization and the compatibility with legacy systems in hospitals and health care infrastructures. The Choreographer implements a protocol based on a custom formatting message exchange language, XMGS. XMSG is based on SOAP and not REST to achieve a minimum level of standardization of information exchange across the system. Nevertheless, as reported in Section 3, REST stands as a proper methodology for describing the interfaces of the system by simply serializing XSMG. The proposed architecture can be adapted to a RESTful architecture with JSON messages, but due to the complexity of the distributed system, the number of sensors and client applications, it is needed to ensure a minimum set of information into the exchanged messages.
The eHealth sensing platform has been built on purpose using the Arduino Libellium kit, a low-cost solution that allows the integration of a wide range of physiological sensors. Even though these sensors are for prototyping, they are useful to work with on the design, development and evaluation of possible solutions to record, store and transmit biometric signals (ECG, EMG, Airflow, etc.). This technology was chosen over other commercial health sensors because of the cost as well as the integration simplicity: Arduino provides serial communication over wired and wireless physical interfaces, whereas the majority of sensors only provide wired communication, and, most of the time, the protocols to retrieve measurements are not available for third parties or are based on complex standards as the ISO/IEEE 11073 [14].
The proposed system is capable of hosting and serving a website as a regular web service. This is an extremely important feature that allows certifying the system as plug-and-play. With the proposed architecture of communications, health sensors may be configured to be subscribed to a specific website to perform a real-time broadcasting of the measurements, at the same time that these measurements may be stored in cloud services or analyzed by complex algorithms.
The deployment of this system is feasible on either a PC or a Raspberry Pi. According to our experiments (Figures 9 and 10), there is a statistically significant increased delay on the Raspberry Pi with respect the PC, which is understandable considering the unbalanced set of computational resources. However, for some specific cases, this delay is not relevant for the medical and monitoring purpose; (in the case of ECG, latency difference is below 0.030 s).
The significantly increased delay of Raspberry Pi may be related to the processor technical features, which has fewer capabilities than the personal Computer processor (ARMv8 @1.2 GHz and 1 GB RAM versus Dual Core @2.6 GHz and 4 GB RAM). Future work should consider experimental verification of the causes of the delay. Our results show that the latency experimented from side-to-side (meaning from sensors to the webpage) has not a big difference (even though significant), and the delay introduced by the Raspberry Pi is assumable. The low costs and requirements of a Raspberry Pi are not comparable with the high costs and requirements of a personal computer. Therefore, our experiments suggest that the new architectures for monitoring bio-signals could rely on the implementation of networks based on the Raspberry Pi without compromising the latency.

Conclusions
In this manuscript, we present and evaluate a scalable system based on five wearable sensors that allow the plug-and-play deployment on different use scenarios (on Raspberry and desktop computer). Raspberry pi yields a significant increased delay with respect to the same implementation in a personal computer. However, the measured delay is negligible and acceptable in real-time remote monitoring. Implementation of health web sensor node as a part of the Internet of Things using a Raspberry Pi has benefits with respect the use of a desktop computer, which paves the way to the implementation of new portable systems for remote management of chronic conditions. Future work will pursue on this line, finding out the percent of missing packets and the throughput in terms of other KPIs, such as the error rate, memory use, power consumption and influence of the network load (4 G/5 G). Moreover, future research should implement large amounts of traffic (several users and longer periods) to reflect the performance differences in commercial environments.