Internet of Things 5 (2019) 116–129

Contents lists available at ScienceDirect

Internet of Things
journal homepage: www.elsevier.com/locate/iot

Open Software and Data

A health monitoring system for vital signs using IoT

K. Narendra Swaroop a, Kavitha Chandu b,∗, Ramesh Gorrepotu a, Subimal Deb b
a
Department of Electronics and Physics, GIS, GITAM, Visakhapatnam 530045, India
b
Department of Physics, GIT, GITAM, Visakhapatnam 530045, India

a r t i c l e i n f o a b s t r a c t

Article history: This article presents the design of a real-time health monitoring system which can store a
Received 16 July 2018 patient’s basic health parameters. The data can be made available to a medical practitioner
Revised 9 January 2019
as an alert and for monitoring by multiple means of communication. At present, healthcare
Accepted 11 January 2019
systems exist with single mode communication option – popularly either in GSM or data
Available online 19 January 2019
access on a web application. The proposed health monitoring system enhances healthcare
Keywords: delivery by communicating multiplexed data over three modes – BLE (mobile application),
IoT GSM (messaging services) and Wi-Fi (Internet).
Health monitoring system © 2019 Elsevier B.V. All rights reserved.
Multiplexing
Multimode communication

1. Introduction

Data exchange and automation using Internet of things (IoT) is a rapidly growing technology. It includes sensors, cyber
systems – the things in IoT and cloud computing. To reach humans in real time, cyber systems communicate collaboratively
at each stage over the Internet. The advances in Internet innovation have made possible techniques for the conveyance
of healthcare. Networking infrastructure and common access can encourage sharing of patient data and clinical information
making the Internet a perfect tool for remote patient observing applications [1]. Sinnapolu et al [2] demonstrated integrating
wearable devices with IoT and cloud to monitor health parameters and rendering assistance in case of emergency. It is
an exemplary solution to the problem of communication and reporting system and attempts to address the case of an
incapacitated patient driving an automobile. Similar health monitoring systems can enhance the quality of life, especially
for elderly people.
As adults age over 65 years, they need continuous health monitoring. Their population is increasing since the past two
decades. By 2025 it is expected to reach 1200 million among which 80% will be from developing countries [3,4]. A rapid
adaptation of smart phones [5] and web applications makes them a preferred platform for health monitoring systems. Em-
bedded device platforms have evolved rapidly and are now available with many communication options, preferably wireless.
A comparative evaluation of existing health monitoring systems for wearability, security, ease of use and storage require-
ments was made by Gupta et al to identify desirable features missing in contemporary systems [6]. However, an overuse of
the devices and network bandwidths can interrupt real time monitoring. To the best of our knowledge, health monitoring
systems simultaneously implementing multimode communication have not been designed. We therefore present a system
that uses three modes – GSM, BLE and Wi-Fi, in tandem or together, to ensure continuity in health monitoring.
This paper deals with the design and development of a health monitoring system for vital signs using multiplexed and
multimode communication. Section II reviews earlier works on healthcare using IoT. The next section deals with hardware

∗
Corresponding author.
E-mail address: kavitha.chandu@gitam.edu (K. Chandu).

https://doi.org/10.1016/j.iot.2019.01.004
2542-6605/© 2019 Elsevier B.V. All rights reserved.
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 117

Fig. 1. Functional architecture of AHM system.

and software design of the system. Section IV deals with data formats and protocols used in the system design. The remain-
ing part of the paper discusses data multiplexing and multimode communication followed by analysis of conducted clinical
trials.

2. Review of literature

Present day health care applications of wireless sensor networks (WSN) aim to monitor heart troubles, breathing is-
sues, panic response, and stress levels. Even though numerous studies focus on technical, monetary, and social issues, the
technical sprints need to be resolved to have reliable, secure, flexible and power-efficient WSN. The integration of exist-
ing medical technology with wireless network in specialized areas is expected to be witnessed soon [7]. Small wearable
nonintrusive sensors [8] will facilitate large data to be collected automatically. This will reduce regular visit to clinics and
hence the expenditure. Future works in this field of research will benefit the entire health field [9]. A smart vest [10,11] is
another technology evolving as an essential system that can be worn for physiological monitoring. Different sensors can be
integrated into the wearable and at the same time gather bio-signals in an unobtrusive and non-invasive way.
The emerging technology for communication in healthcare is by mobile monitoring systems. Self-management of di-
abetes mellitus type 1 was possible with a phone call and SMS. This method produced satisfactory changes in dia-
betes self-efficacy, adherence to treatment [12] and behavioural changes [13]. A clinically validated and flexible frame-
work, performing real-time analysis of physiological data to monitor patient health conditions has also been developed
[14]. Data mining techniques are used for analysing the data collected by sensors. Real-time processing was performed,
and alerts triggered in critical situations. In a unique approach [15] to measure the heart rate by a non-contact and
non-invasive device, a CCD camera was employed in a trial of 14 Asian participants. Airstrip Technologies [16] devel-
oped using AppPoint software platform, a new monitoring system that can be as good as smart phones and personal
computers.
According to Topol [17], acceptance of mobile phones in healthcare is possible because of ever-growing use of smart
phones, enhanced bandwidth with third and fourth generation (3G and 4G) mobile data networks and computing power
comparable to that of a personal laptop computer. There is a competitive market of medical technology using informa-
tion technology for healthcare provision [18]. Healthcare systems are advancing for cloud adoption and artificial intelligence
driven analytics for diagnosis [19]. A system for prediction and support for aged individuals suffering from memory impair-
ment [20] was implemented using information from unimpaired cases. IoT research is clearly geared towards engaging cloud
technologies with evolutionary computing tools to deliver urgent or monitored medical assistance.
Integrating different modes of communication for health monitoring would help to overcome drawbacks in communica-
tion. BLE can be exploited for short-range transmission, Wi-Fi over the Internet and SMS when the Internet is inaccessible.

3. Design of the system

3.1. Hardware

The functional architecture (Fig. 1) of an AHM system is phased out in four stages – data origination, acquisition and
processing, communication and access.
118 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Fig. 2. AHM system.

Fig. 3. (a) (left): DS18B20 temperature sensor (b) (right) Sunrom blood pressure/heart rate sensor.

Data origination: Sensor interface to monitor blood pressure, heart rate and temperature.
Data acquisition and processing: This is done by an embedded platform –Raspberry Pi 3 (RPi3) in the present system.
Data communication: RPi3’s on-chip BLE and Wi-Fi modules and USB ports to interface GSM is chosen for multimode
communication.
Data access:

 GSM: Data in short form with limited text is sent to configured mobile number
 BLE: Data in streamline is received at BLE open terminal application in standard format
 Wi-Fi: Data in streamline pushed to web server in cloud and presented on web application.

Fig. 2 depicts the hardware design of the system. RPi3 plays the role of a master in the design. Two sensors – DS18B20
digital thermometer and Sunrom blood pressure /heart rate sensor were interfaced to monitor the vital signs. The DS18B20
digital thermometer (Fig. 3a) is used to record body temperature. It provides 9-bit to 12-bit Celsius temperature measure-
ments and incorporates only one wire (apart from ground) to communicate with microcontroller. The Sunrom blood pressure
/heart rate sensor (Fig. 3b) is interfaced with RPi3 through RS232 port. The complete AHM system is powered by a micro
USB socket 5VDC, 2.5A power adapter.
The system requires active communication channels to transmit health data for monitoring and alerts. The RPi3 has
on-board Wi-Fi, Bluetooth and USB boot capabilities. The USB GSM modem (Fig. 4a) uses a SIM card, operates over a
subscribed mobile operator to send data using SMS. GSM interface and RPi3 use circuit switching to establish communi-
cation path between them. A major upgrade in the RPi3 module is embedded connectivity with on-board Wi-Fi (Fig. 4b)
(BCM43143). MQTT (MQ Telemetry Transport) protocol is implemented to transmit data through Wi-Fi. The Sunrom blood
pressure/pulse-rate sensor and RPi3’s in-built BLE module require a UART port. RPi3 comes with a single UART port and
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 119

Fig. 4. (a) (left): USB GSM module (b) (middle) Inbult Wi Fi (c) (right) CSR 4.0 BLE adaptor.

Fig. 5. Software architecture.

hence an external Bluetooth dongle with standard CSR 4.0 format was used with RPi3 (Fig. 4c). These three modes will
be used to communicate multiplexed data for monitoring a patient’s vital signs – body temperature, heart rate and blood
pressure to a clinician.

3.2. Software

The software architecture of the present system is sequential, distributed and systematic, completing the processes of
data acquisition from sensors to data packet transmission through various channels (Fig. 5). The steps for execution are
sequential. The system initialization is followed by the firmware pools for event triggers to acquire data from distributed
sensor inputs. The acquired data is segregated to construct individual packets for respective mode of communication. The
multiplexing of acquired data and transmission through multimode communication is handled systematically.
The core application was scripted in the Python programming language. The web application was developed with HTML5
and CSS3 for the user interface; PHP for the backend; MYSQL for the database and JSON’s RESTful API for the services. A
developed IBEACON mobile application was deployed with the support of BLE CSR 4.0 protocol. The CSR Mesh protocol was
used for communication between two BLE devices. GSM’s SMS service infrastructure is utilized without additional software
for user interface.
The complete algorithm for the multiplexed multimode communication, starting from booting the RPi3 to its operational
state is shown in Fig. 6.
System initialization: AHM system does not have specific power-on switch on-board to initialize the booting sequence.
With the power adaptor switched on, the booting sequence is initiated. The RPi3 excludes usage of on-board non-volatile
memory. SD/MMC card slot is provided to store the boot loaders, file systems and Linux Kernels. The RPi3’s Broadcom
120 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Fig. 6. (a) Software algorithm (b) System initialization (c) Interfaces initialization and Pool for event trigger. For packet formation and transmission refer
Figs. 11 and 12 respectively.

BCM2835 (SoC) powered with its ARM1176JZF-S (700 MHz processor) is held in reset mode. The Video Core IV GPU executes
the first stage bootloader from ROM.

 The bootcode.bin (second stage bootloader) from file system (FAT32 or FAT16) on the SD Card is loaded by first stage
bootloader.
 The second stage bootloader – bootcode.bin is executed on the VideoCore GPU and loads the third stage bootloader –
The third stage bootloader reads the GPU firmware from start.elf.
 All the actions happen in start.elf (third stage bootloader) where it starts by reading config.txt, a text file containing
configuration parameters for both the VideoCore (Video/HDMI modes, memory, console frame buffers etc.) and loading
of the Linux Kernel (loading addresses, device tree, UART/console baud rates etc).

Sensor interfaces initialization: After the booting sequence is complete, the interface with RS232 peripheral is initial-
ized by configuring the baud rate and frame settings. Subsequently the one-wire protocol interface GPIO is initialized. Each
instance of reading contains of 15 bytes at 9600 baud rate.
Pool for event trigger: The software shall be forever in pooling mode for interrupt trigger to recognize the input data
from RS232 interface where the health parameters blood pressure and pulse rate are received. Data from Sunrom mod-
ule in RS232 interface triggers the sequence of operations for multiplexing sensors data and transmitting in multimode
communication.
Data acquisition, segregation and packet formation: Upon a trigger from RS232 interface, the data from blood pressure
sensor and temperature sensor is read and a raw data frame is created. This raw data frame with health parameters data
and generic data strings mentioned below form the payload data packet for further communication.

• Patient identity – PTID

 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 121

Fig. 7. Timing diagram for one-wire interface.

Fig. 8. Temperature register format.

• Body Temperature string – TMP

• Systolic Blood pressure – SYS
• Diastolic blood pressure – DIA
• Heart Rate – PUL
Packet transmission – GSM, BLE and Wi-Fi: The payload data packet with generic string and health parameters are
common inputs for the three modes of communication. The SMS text using GSM network is limited to 140 octets or 1120
bits in length. User data message is 140 bytes, payload constructed for GSM is 40 bytes. MQTT-SN message contains two
parts, a 2 or 4-octet long header which is always present and contains the same fields and an optional variable part, its
presence and content of the variable part depend on the type of the message considered. BLE CSR 4.0 protocol transmits 20
bytes of data packet which include the payload data. Upon transmission of the organized data packets the software again
gets into pooling mode for the next instance of data trigger event.

4. Data formats and protocols

The system uses different standard data formats and transmission protocols for interfacing sensors and communicating
the data over the three mentioned modes.
Temperature sensor: The 1-Wire bus system uses a single bus master to control slave devices. The DS18B20 is always a
slave. All data and commands are transmitted least significant bit first over the 1-Wire bus. All transactions on the 1-Wire
bus begin with an initialization sequence. The initialization sequence consists of a reset pulse and present pulse transmitted
122 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Fig. 9. MQTT Message structure.

Fig. 10. BLE protocol architecture.

by master and slave respectively. The presence pulse lets the master know that slave device (DS18B20) is on the bus and
ready to operate. Fig. 7 shows the timing diagram for the one-wire interface.
In the temperature register the data is stored as a 16-bit number - sign extended two’s complement number. If the
DS18B20 is configured for 12-bit resolution, all bits in the temperature register will contain valid data (Fig. 8). For 11-bit
resolution, bit 0 is undefined. For 10-bit resolution, bits 1 and 0 are undefined and for 9-bit resolution bits 2, 1, and 0 are
undefined.
Sunrom blood pressure/ heart rate monitor: The blood pressure and heart rate parameters are received in RS232 for-
mat. Its output is three parameters in ASCII serial data format at 9600 baud rate. The information is carried in 3 bytes -
byte 1 corresponds to systolic, byte 2 to diastolic and byte 3 to pulse rate.
MQTT protocol: The present system uses MQTT protocol to transmit data using Wi-Fi. MQTT is a popular lightweight
messaging protocol (Fig. 9) and very modest power is consumed, unlike other heavy protocols. MQTT uses a client-server
architecture. The clients are the devices (in our case the two sensors) connected to the server. It uses a publish/subscribe
model and hence requires a broker. RPi3 sends MQTT packets to cloud using the open source mosquito MQTT broker. The
mosquito provides standard commands for subscribe/publish/password.
BLE: The architecture of BLE (Fig. 10) consists of two parts – controller and host. The controller is typically a SoC (System
on Chip) with a radio. The controller comprises of the physical layer and the link layer. The host comprises of protocols:
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 123

Fig. 11. Packet formation for multiplexing.

Fig. 12. Multimode communication.

Logical Link Control and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Security Manager Protocol (SMP), Profiles
Generic Attribute Profile (GATT), and the Generic Access Profile (GAP). The communication between host and the controller
is through the HCI (Host Controller Interface).
GSM: A GSM is a mobile phone or modem device used along with a SIM card over a subscribed network.
124 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Fig. 13. Data received as SMS on mobile.

Fig. 14. IBeacon mobile application.

These protocols will be used to track a patient’s vital signs in real-time and monitor and administer medication at the
clinician’s discretion. This also boosts the patient’s feeling of the clinician being readily available for administering any
required medication.

5. Data multiplexing and multi-mode communication

Multiplexing is done by the software program. The sensor data is multiplexed and framed into a custom payload packet
(Fig. 11). The payload packet is framed to respective standard data packet for multimode communication on GSM, BLE and
Wi-Fi by the system software (Fig. 12). This multiplexed data is displayed across three modes – messaging, a mobile and a
web application.
The health parameter alerts are received as a message (SMS) through GSM. Fig. 13 is a screenshot of the SMS screen.
Fig. 14 displays the mobile application IBeacon scanner (an open mobile application) where the data from the system is
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 125

Fig. 15. Web Application.

Fig. 16. Clinical trial set up.

received in packets, each packet represent a parameter value. The packet numbering is indicated by “Minor” field and health
parameter value is indicated in “Major” field. Customized BLE application is not developed due to license and customization
overheads. The alerts received through MQTT protocol can be viewed on web application (Fig. 15).

6. Result analysis

Clinical trials were performed, and data is collected to get feedback of the present system. The data was collected under
medical supervision to find out the functional validity of the concept over existing remote monitoring systems. Clinical trials
were conducted in hospitals located in our city. The trials were limited to few hospitals due to the limitation of sharing
126 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Fig. 17. Clinical data output.

patient data for the study. Clinicians were resistive to conduct the trails with their patients for confidentiality and to avoid
ethical issues. It is ensured that communication during data collection happens in all three modes. The clinicians helped
to validate the communicated data by comparison with conventional methods. The clinical setups for data collection are
shown Fig. 16.
Fig. 17 shows the values received on web and mobile interfaces during a clinical trial. The time latency (Fig. 18a) is
analysed to understand the expected delay in transmission of data after taking the readings. From the trials, it is ob-
served that data transmission (Table 1a) to BLE was swift being in the same location and point to point communica-
tion. We note that the communication took place in under 3 s. In receiving data over GSM and web application had a
delay of less than a minute and 5 min respectively due to stages of communication process using the established net-
work. However, owing to lower resolution – up to minutes in the time stamp for SMS and BLE, the delay could not
be determined with accuracy better than a minute. The averages and standard deviations have been calculated in Table
1b and plotted in Fig. 18b. It is clear that the performance of the system is affected by the bottleneck presented by the
networks.
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 127

300

250 Time Stamp SMS

Time stamp Web
Time Stamp BLE
Time latency (sec)

200

150

100

50

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Patient ID

300

250
Latency (sec)

200 SMS
150 WEB

100

50

0
22/02/2018

23/02/2018

24/02/2018

25/02/2018

26/02/2018

Date

Fig. 18. (Top) Time latency of implemented system (Bottom) Daily averages with standard deviations (plotted as error bars).
128 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129

Table 1a
Time latency.

Patient ID Date Reading time Receiving time Latency (sec)

BLE (HH:MM) SMS (HH:MM) Web (HH:MM:SS) BLE SMS Web

1 22-02-2018 16:07 16:07 16:09 16:08:30 0 120 90

2 22-02-2018 16:10 16:10 16:11 16:11:10 0 60 70
3 22-02-2018 16:13 16:13 16:15 16:14:10 0 120 70
4 22-02-2018 16:17 16:17 16:18 16:17:06 0 60 6
5 22-02-2018 16:19 16:19 16:21 16:19:08 0 120 8
6 22-02-2018 16:21 16:21 16:24 16:22:48 0 180 108
7 22-02-2018 17:34 17:34 17:36 17:36:49 0 120 169
8 22-02-2018 17:50 17:50 17:52 17:51:13 0 120 73
9 22-02-2018 17:52 17:52 17:54 17:53:45 0 120 105
10 22-02-2018 17:55 17:55 17:59 17:57:18 0 240 138
11 23-02-2018 18:00 18:00 18:01 18:01:46 0 60 106
12 24-02-2018 13:43 13:43 13:44 13:45:12 0 60 132
13 24-02-2018 13:49 13:49 13:50 13:51:14 0 60 134
14 24-02-2018 14:18 14:18 14:19 14:19:51 0 60 111
15 26-02-2018 13:28 13:28 13:30 13:30:35 0 120 155
16 26-02-2018 13:33 13:33 13:36 13:37:26 0 180 266
17 26-02-2018 13:36 13:36 13:38 13:37:56 0 120 116
18 26-02-2018 18:42 18:42 18:44 18:46:46 0 120 286
19 26-02-2018 18:47 18:47 18:50 18:49:36 0 180 156
20 26-02-2018 18:54 18:54 18:56 18:57:40 0 120 220
Avg. 117 125.95
STD dev 49.53468 71.84081

Table 1b
Day-wise averages and standard deviations.

Count Date Daily average(sec) Std. dev.

SMS WEB SMS WEB

10 22-02-2018 126 83.7 52.535702 51.17084673

3 24-02-2018 60 125.66667 5.538E-12 12.7410099
6 26-02-2018 140 199.83333 30.983867 68.07177584

Table 1 (a) Time latency from the data acquired per patient. (b) Averages and
standard deviations are calculated day-wise. The dependence of the system’s
performance on the network is clearly reflected.

7. Conclusion

The system addresses key issues and challenges related to healthcare vulnerabilities with the high usage of ubiquitous
devices like Smartphone, tablet, laptop or PC. It enhances overall healthcare delivery by facilitating multiple modes of con-
nectivity between patients and clinicians. The primary hardware blocks work using RPi3 Model B. Health monitoring sensors
and wireless communication (BLE, Wi-Fi and GSM) are integrated to overcome the challenges. The accuracy of the acquired
data is limited by the accuracy of the sensors used. The multiple modes of communication help in reducing the risk of
losing track of a patient if one of the three modes of communication fail.
The mobile application software is used with user interface to view data on Mobile / Tablets. Prototype web application
software with cloud database interface was developed to view data on webpage. SMS to a registered mobile of clinician is
received with essential data to interpret the vital health parameters of the patient.
This study is supported by data collection to serve the purpose of measuring the parameters with accuracy and the
other benefits of multiplexed multimode communication. Clinical trials were conducted and clinician feedback overall was
an appreciation for the system. Essential point of observation was that the system links the patient and clinician with no
delay, when the clinician is otherwise inaccessible. Based on the feedback from the clinicians, usage of this system shall
facilitate clinician’s additional urge to provide close monitoring and care of the patients. Patients gain further psychological
advantage that his/her clinician is monitoring the health parameters, from time to time.

References

[1] R.T. Hameed, O.A. Mohamad, N. Ţăpuş, Health monitoring system based on wearable sensors and cloud platform, in: System Theory, Control and
Computing (ICSTCC), 2016 20th International Conference o, IEEE, 2016, pp. 543–548.
[2] G. Sinnapolu, S. Alawneh, Integrating wearables with cloud-based communication for health monitoring and emergency assistance, Internet of Things
1 (2018) 40–54.
[3] S.J. Coons, J.A. Johnson, The United States spends more on health care than any other nation in the world, Soc. Behav. Asp. Pharm. Care (2010) 279.
[4] H. Bray, National population projections, Off. Natl. Stat. (2008).
 K.N. Swaroop, K. Chandu and R. Gorrepotu et al. / Internet of Things 5 (2019) 116–129 129

[5] A. Milenkovic, C. Otto, E. Jovanov, Wireless sensor networks for personal health monitoring: issues and an implementation, Comput. Commun. 29
(2006) 2521–2533, doi:10.1016/j.comcom.2006.02.011.
[6] N. Gupta, H. Saeed, S. Jha, M. Chahande, S. Pandey, IoT based health monitoring systems, in: Innovations in Information, Embedded and Communication
Systems (ICIIECS), 2017 International Conference on, IEEE, 2017, pp. 1–6.
[7] O. Aziz, B. Lo, R. King, A. Darzi, G.-Z. Yang, Pervasive body sensor network: an approach to monitoring the postoperative surgical patient, in: Interna-
tional Workshop on Wearable and implantable Body Sensor Networks (BSN 2006), Cambridge, MA, USA, 2006.
[8] M. Haghi, K. Thurow, R. Stoll, Wearable devices in medical internet of things: scientific research and commercially available devices, Healthc. Inf. Res.
23 (1) (2017) 4–15.
[9] N. Kumar, A. Aggrawal, N. Gupta, J. C.M., Wearable sensors for remote healthcare monitoring system, Int. J. Eng. Trends Technol. 3 (1) (2012) 37–42
2012.
[10] P.S. Pandian, K. Mohanavelu, K.P. Safeer, T.M. Kotresh, D.T. Shakunthala, P. Gopal, V.C. Padaki, Smart Vest: wearable multi-parameter remote physiolog-
ical monitoring system, Med. Eng. Phys. 30 (4) (2008) 466–477.
[11] G. López, V. Custodio, J.I. Moreno, LOBIN: E-textile and wireless sensor-network-based platform for healthcare monitoring in future hospital environ-
ments, IEEE Trans. Inf. Technol. Biomed. 14 (6) (2010) 1446–1458.
[12] V.L. Franklin, A. Greene, A. Waller, S.A. Greene, C. Pagliari, Patients’ engagement with “Sweet Talk”– a text messaging support system for young people
with diabetes, J. Med. Internet Res. 10 (2) (2008).
[13] B.S. Fjeldsoe, A.L. Marshall, Y.D. Miller, Behavior change interventions delivered by mobile telephone short-message service, Am. J. Prev. Med. 36 (2)
(2009) 165–173.
[14] D. Apiletti, E. Baralis, G. Bruno, T. Cerquitelli, Real-time analysis of physiological data to support medical applications, IEEE Trans. Inf. Technol. Biomed.
13 (3) (2009) 313–321 2009.
[15] C. Takano, Y. Ohta, Heart rate measurement based on a time-lapse image, Med. Eng. Phys. 29 (8) (2007) 853–857 2007.
[16] AirStrip Technologies. Airstrip Technologies remote continuous vital sign monitoring via the iPhone (2012).
[17] E.J. Topol, Transforming medicine via digital innovation, Sci. Transl. Med. 2 (16) (2010).
[18] J.J. Oresko, Z. Jin, J. Cheng, S. Huang, Y. Sun, H. Duschl, A.C. Cheng, A wearable smartphone-based platform for real-time cardiovascular disease detec-
tion via electrocardiogram processing, IEEE Trans. Inf. Technol. Biomed. 14 (3) (2010) 734–740.
[19] https://cdn.ihs.com/www/pdf/Technology- White- Paper- The- Connected- Patient.pdf.
[20] G.M. Lunardi, F. Al Machot, V.A. Shekhovtsov, V. Maran, G.M. Machado, A. Machado, J.P.M. de Oliveira, IoT-based human action prediction and support,
Internet Things 3 (2018) 52–68.