Future Internet of Things Platform for Ubiquitous

Integration of Clinical Environments at Patients House

Antonio J. Jara, Miguel A. Zamora-Izquierdo, and Antonio F. Gmez-Skarmeta
1Abstract This work presents a next generation clinical
architecture based on the Future I nternet of Things for
extending a patients environment to integrated clinical
environments. I t introduces technological innovations and
advanced services which allow patient monitoring and
supervision by remote centers, and personal multimedia
platforms such as smart phones and tablets. From the
hardware point of view, it consists of a platform/gateway
named Monere, and a personal clinical device/sensor
adaptor named Movital, used for the wireless integration
of clinical devices through 6LoWPAN, and patient
identification through RFI D. Movital additionally supports
communication capabilities to allow a secure, scalable and
global integration of the sensors deployed at the patients
environment. This paper presents the architecture, and
how it provides support for mobility and ubiquitous
connectivity, extended devices integration, reliability, and
in definitive offers a bridge between the sensors connected
to the patient and the information systems, in conjunction
with the user interfaces, in order to reach a Ubiquitous
I ntegration of Clinical Environments. This solution is
being deployed and evaluated in a clinic in Barcelona, and
in Assisted Living Environments for patients with
respiratory illnesses under the AI RE project.
I ndex Terms Internet of Things, Sensor and RFID
technologies for e-health, Architecture, Integrated Clinical
Environment, Ambient Assisted Living.
I. INTRODUCTION
The evolution of technologies for, on the one hand, the
identification of objects, with applications such as Radio
Frequency Identification (RFID), and, on the other hand, for
communication and consumer devices, providing solutions
which offer ubiquitous access to information -such as
wireless personal devices, embedded systems and smart
objects-, together with the capabilities presented by the
Future Internet with IPv6 protocol and technologies, such as
IPv6 over Low Power Area Networks (6LoWPAN), which
allow the Internet extension to small and smart devices. This

Manuscript received December 15th, 2011. The authors would like to
thank the Spanish ministry for Industry, Tourism and infrastructure, and the
ministry for education, social politic and sport for sponsoring the research
activities under the grants AIRE Architecture for Insufficiency
Respiratory Evaluation Project (TSI-020302-2010-95), and the FPU
program (AP2009-3981). This work has been carried out by the Intelligent
Systems group of the University of Murcia, awarded as an excellence
researching group by the Fundacin Sneca (04552/GERM/06), and in
the framework of the IoT6 European Project (STREP) from the 7th
Framework Program (Grant 288445).
Finally thanks to PhD. Fred Hosea from Kaiser Permanente, Mr. Miguel
Yasuhiko Tsuchiya and Mr. Javier Sancho from Flowlab, and M.D.
Bienvenido Barreiro and his team from the neuomology service, as such as
the team from Centro de Atencin Primaria i.e. medical centre and
Addom services from Mutua Terrasa.
Antonio J. Jara, Miguel A. Zamora and Antonio F. G Skarmeta are with
the Department of. Information and Communications Engineering (DIIC),
Computer Science Faculty at the University of Murcia, ES-3100, Spain.
(phone: +34-868-88-8771; fax: +34-868-88-4151; e-mail: jara@um.es).
extension is a key element that is making it feasible to
identify, sense, locate, and connect all the people, machines,
devices and things surrounding us among them.
These new capabilities for linking Internet with everyday
sensors and devices, forms of communication among people
and things, and exploitation of data capture, define the so
called Future Internet of things (IoT) [1].
The IoT is considered one of the major communication
advances in recent years, since it offers the basis for the
development of independent cooperative services and
applications. An extensive research on using this concept in
different areas such as building automation, Intelligent
Transport Systems, and healthcare is being carried out. For
example, its potential for mobile health applications has
been recently reported in [2], showing its potential from the
identification capacities for drugs identification [3], and its
communication capabilities to offer ubiquitous therapy by
providing wireless and mobility capabilities for personal
devices and smart objects, in addition to allowing the
collection of data anytime and anywhere [4]. An example of
an application where these capabilities are exploited for
chronic diseases management is presented in the solution for
diabetes, found in [5]. However, even when specific
solutions are located for IoT [2,5] and wireless networks [6],
no study to date presents a platform to address this concept
and offer support for ubiquitous personalized healthcare.
This work goal is to exploit the aforementioned IoT
capabilities in order to build a platform for personalized
healthcare in the patients environment. In this respect, this
platform goal is the extension of those environments
towards a clinical environment. Thereby, it can be reached,
what we have defined as, a Ubiquitous I ntegration of
Clinical Environments.
This denomination is inspired, firstly, in the ubiquitous
feature, because it is not only oriented towards hospitals and
specialized clinical environments, but also towards patients
environments, such as the patients house, senior citizen
residence, or gym, and mobile environments such as an
ambulance, mobile clinics, and travel health services, where
support for mobility is going to be required. Secondly, the
term is inspired in integration, since it is focused on its
integration and interoperability with the current information
infrastructure and e-Health platforms, instead of offering an
additional alternative for the market. This integration factor
is the key element, since as it was mentioned by Dr Najeeb
Al-Shorbaji, director of knowledge management and sharing
at the World Health Organization, It cannot be viewed as a
standalone proposition and must be seen as a subset of e-
health, which in turn is an integral part of a more general,
comprehensive healthcare strategy, encompassing all
security, ethical and standards issues. This integrator spirit
is fundamental for the current Internet and IoT.
Furthermore, and in order to reach a proper integration,
application-level interoperability among clinical devices and
the existing platforms is required, together with security and
privacy support since medical data are highly sensitive.


Therefore, our platform aims to support ubiquitous and
mobile healthcare, as well as integration of the deployed
home platform and clinical devices in the current e-Health
infrastructure, interoperability, security and privacy based
on the integration of IoT technologies for patients sensors.
Ubiquitous I ntegration of Clinical Environments defines
complex design challenges and requirements, which need a
bottom-up approach, from the clinical devices and network
infrastructure to the e-Health platforms.
At the e-Health platforms level, several projects are found
to reach a unified Electronic Health Record among different
hospitals, organizations and countries, as well as a definition
of personalized services, electronic prescription, support
Personal Health Record, and collaborative Decision Support
Systems. However, we do not see the next-generation of
devices, gateways and systems which offer the capabilities
required to provide the bottom support for the pursued
solution as being so developed.
For that purpose, the specifically built platform which is
installed in the patients environment, denominated Monere,
presents multi-technology support. This platform can be
considered as a gateway, which is what the ISO/IEEE
11073-20601 Personal Health Data Exchange Protocol
(HDP) [7] defines as IEEE manager. This links between the
clinical devices located at the patients house and the
external network, and carries out additional administrative
functions such as configuration management, reliability
monitoring, live performance metrics, and support for risk.
The connection of the clinical sensors (sources) to
Monere is through their native technology, e.g. wired
technologies such as serial, USB or wireless such as
Bluetooth and ZigBee.
In addition, Monere is complemented by a clinical device
integrator (adaptor), called Movital, which is like an IEEE
agent following the HDP protocol. Movital extends current
sensors to a mobile and wireless device. This offers the
support for the device lifecycle management and complex
network transactions such as mobility support, in addition to
offering the adapter functionality from native protocol to a
suitable protocol, denominated YOAPY, for the
requirements and constrains from 6LoWPAN technology.
Finally, Movital also offers the integration of a RFID
reader to identify the patient and caregivers, or loads the
patient's profile from the personal health card.
In particular, the new capabilities and functionalities for
the clinical devices and design issues considered for the
proposed network infrastructure have been defined by a
group of experts from clinical technology, hospitals and
assisted living, to satisfies the requirements from patients
monitoring and e-Health platform integration.
All these requirements and considerations are presented
in the next section, which defines the additional
functionalities needed for the clinical devices to reach the
defined Ubiquitous Integrated Clinical Environments.
Section IV presents the architecture showing the integration
of patients environment with the current platforms. This
integration is satisfied with the developed gateway
(Monere), and clinical device integrator (Movital), which
are presented in Sections V and VI, respectively. Finally,
Section VII presents the use case of the proposal for assisted
living of fragile patients with serious breathing problems
from AIRE project with the performance evaluation of the
communications protocols defined for the different clinical
sensors integrated from the mentioned scenario.

Fig. 1. Ubiquitous Integrated Clinical Environments Architecture.
II. DESIGN ISSUES AND REQUIREMENTS FOR UBIQUITOUS
INTEGRATED CLINICAL ENVIRONMENTS
This solution has been designed, evaluated and validated by
a multidisciplinary group of experts from Mutua Terrassa
(Spain) under the frame of the AIRE project, for clinic
environments from Clnica del Valls in Barcelona
(Spain), through the Intelligent Beds project, and clinical
technology considerations from Kaiser Permanente
Innovation Labs (USA), and Flowlab (Europe).
This determines the requirements for the integration of
clinical devices with information systems. Figure 1 presents
the requirements considered for the Ubiquitous Integration
of Clinical Environments platform, by nurses, physician and
caregivers (marked in green), by clinical technology experts,
and by our own experience (marked in violet). Over which
management services are defined for communication and
interoperability. Finally, high level and value-added services
from each specific healthcare provider are built.
The first consideration from the caregivers group is the
need for integration of clinical devices in the patients
environment in order to carry out distant monitoring of
patient status, and personalized/adaptive home therapy.
The second consideration is that the clinical devices to be
integrated should be the current available clinical sensors;
therefore backward compatibility and flexibility in the
platform to integrate existing devices are required.
In addition, the third issue is the support of ubiquitous
and mobility-proof networks to keep patients connected
anytime/anywhere. This factor is highly relevant to link the
different patients environments, which are linked through
the Mobility management service. It is mentioned in case it
cannot be supported, since continuous monitoring is highly
chaotic during the day. A support night-time monitoring
could be also interesting regarding chronic diseases, since
the night situation is considered to be equivalent to the
situation during the day in these cases. Therefore, it shows
the interest in integrating them in the patients bed for
continuous monitoring and logging.
The fourth one is the need to identify the patient and the
caregiver who is attending the patient when a measure is
carried out. This is required for environments with multiple
patients such as senior living residences, and for therapies
requiring regular visits from caregivers. This requirement is


highly interesting IoT capabilities are able to solve it with
RFID integration [8].
The last issue from physicians was the integration of
patient monitors, i.e. compound devices, in addition to
simple ones, since they use this kind of device. It provides
correlated and synchronized values, and higher accuracy.
From the clinical technology experts and our experience,
we defined the mentioned requirements in the Introduction
in order to reach this integration, which corresponds to
interoperability among devices with different systems. For
that purpose, we have been focused on integrating current
devices and supporting devices compliant with standards
such as ISO/IEEE 11073-20601 Personal Health Data
Exchange Protocol (HDP), which is the specialized profile
designed to allow interoperability between medical,
healthcare and fitness devices from different vendors. In
addition, we are considering the new versions for coming
devices based on HL7v3, and Integrated Clinical Devices
(ICD-10), since expandability is another feature considered
to keep up the pace with technological progression and to
support a smooth continual improvement process.
The other requirement that this group presented had to do
with data security and privacy, and with the integration of
the Identity Management platform to carry out the Access
and Consent Management of doctors and other systems to
the patients health information, i.e. carry out the access
policy matrix for privilege management. This is required to
guarantee security, privacy, anonymous consultation and the
patients privacy, integrity of the information and patient
confidentiality.
Finally, issues regarding scalability, for processing of
large amounts of medical data for a growing population;
availability and robustness, since a system failure can put
lives at risk, in medical environments; and economies of
scale, i.e. new services should be based on existing modules
in order to leverage the related platform investment. For this
last purpose the proposal is definition of generic services for
linking with the specific high level services from each
healthcare provider. The last one considers from both sides
that physicians and nurses do not want to use new
applications to access these new services, but they prefer to
integrate them in their existing solutions. Otherwise, they
are not going to use them frequently.
III. RELATED WORKS
The current situation of clinical devices from hospital and
assisted living environments is focused on stand-alone
devices with basic network connectivity, and on manual
configuration and limited interoperability with manufacturer
protocols and proprietary implementations. We require a
new generation of solutions oriented to devices completely
connected with full duplex communication, having Internet
support at device level, as well as extended application level
interoperability, support for remote management,
administrative functions, and auto-configuration is required,
since it will allow reach scalable and ubiquitous healthcare.
We can find the development of platforms and technical
solutions for continuous/intermittent monitoring of vital
signs in home setting location for specific chronic diseases
as those which are defined by the ALADDIN project [9] for
dementia management, the home medical gateway presented
in [10] for Obstructed Sleep Apnea (OSA) patients to
monitor and improve their sleep quality, and finally the
long-term healthcare system for physiological monitoring
presented in [11]. These solutions are distinguished by
integration of a set of specific sensors through their property
protocol, based on Bluetooth or USB/Serial, which is far
from the interoperability, administrative functions, mobility
and security support elements which are required.
With regard to interoperability, we can find some
commercial solutions to integrate devices compliant with
the HDP, such as the Bluegiga AP3201 e-Health Gateway,
Everyware Medical Gateway, and the Vignet pilot, which
provide a Connected Health platform for mobile phones,
PCs and gateways to connect any medical device with
servers or services available over the network. The problem
of these solutions is that, even when interoperability is being
solved, it is limited to HDP devices; it does not satisfy the
requirement of integrating device heterogeneity; and it
extends already existing e-Health platforms, instead of
proposing new ones.
In short, this new generation of interoperable e-Health
platforms and clinical devices requires significant scaling of
clinical technology management and services, in addition to
high integration requirements. In this respect, the state-of-
the-art technology to address these requirements presents
Future Internet as a medium to integrate clinical devices,
offering new administrative functions, and also empowering
deployments with connectivity and scalability capabilities,
not only from Internet, but also Machine to Machine (M2M)
communications, and finally IoT [12].
This network evolution towards a full Internet
connectivity solution for everywhere and in everything
provides capacities to build intelligent environments [13],
and to solve the presented design issues, in order to reach
the Ubiquitous Integrated Clinical Environments.
IV. ARCHITECTURE OVERVIEW
The architecture is presented in Figure 2 shows, on the one
hand, the Environment Integration Platform (EIP),
composed of the Monere platform in the patients house to
provide a global connectivity and management capacity, and
the Movital nodes which have been designed to work with
devices for medical purpose from different vendors. In
addition to transmitting vital signs data, these elements offer
administrative functions for medical error reduction, fault
detection, remote device management and, in short, their
own integration into the system lifecycle.
On the other hand, this architecture presents as it is also
integrated with existing information systems, such as the
Hospital Information System (HIS), and the Service
Providers System (SPS) to develop services from healthcare
providers, as well as with other systems for context
management, and intelligent analysis of patient status.
Finally, it presents as could be integrated with the
Identification Management System (IdM) in order to
provide scalable security and privacy support.
A. Hardware platforms
The descriptions of Monere and Movital are presented in
Sections V and VI, respectively. They are the key elements
to introduce the IoT in clinical environments. Monere is the
gateway and manager to support ubiquitous data collection
and access, whereas Movital is the combination of the IoT-
based communication and identification technologies for
wireless and mobile integration of clinical devices.



Fig. 2. Architecture overview: platform integration with the current Information Technology Infrastructure.

B. Information Systems
The information systems considered range from integration
of inherited systems from current deployments, such as the
Hospital Information System, and the results from previous
works, such as Context Management Framework, to the
definition of new Services Provider System (SPS) so as to
define the personalized services from healthcare providers,
such as Personal Health Record, health status monitoring, e-
booking services etc.
- Hospital Information System (HIS) usually adopts
native integration with that currently deployed in the
hospital. It offers support for the Electronic Health
Record management, but it can also provide
administration and control of human resources, clinical
divisions in hospitals etc. From a research perspective,
the current tendency of the HIS is the standard
CEN/ISO 13606, which is based on OpenEHR, and is
defined to satisfy the European standard requirements
for clinical data interoperability. From a commercial
perspective, it is the extended Clinical Document
Architecture (CDA) from HL7.
- Context Management Framework (CMF) are built for
tracking patients health at home, and any difficulties
encountered in daily activities. It is based on event
processing; identifying patterns over events is always
done by context of time, space and relationship between
events that make up the pattern, such as the time
between two high blood pressure measurements and
two different lab results for the same patient. The
solution from European projects such as SPICE, Sensei,
and Florence, could be examples of CMF.
- Knowledge Base Systems (KBS) will be specified as
managing large data volumes which may be generated
from various sources with heterogeneous formats, and
with semantics, synchronicities, accuracies, trust and
reliability. They will be critical to underpin remote
consultations of large communities of patients. There
are existing low-level data fusion techniques for
automated pre-processing of data to identify and model
important trends and anomalies in data from monitoring
devices. These can refer to some of the KBS developed
in previous projects, such as our previous work for
insulin therapy in diabetic patients [5], and ALADDIN
for dementia [9].
C. Security Management
This architecture integrates, through Movital, a suitable
security stack based on Elliptic Curve which has been
optimized for embedded IoT devices [14] to support and
improve security primitives, and identification management,
for communication with clinical devices. This ensures the
patients privacy, and security of information.
In addition, the Identity Management System can be
integrated to offer security, privacy and Identity
Management (IdM) features for communication with other
systems, ensuring anonymous consultation from external
doctors, patient privacy, integrity of information, etc. [15].
This part is relevant to reach ubiquitous healthcare, since it
offers support for policy regulations, and also implements
interoperability among HIS from different hospitals,
institutions and even nations under the frame of the project
epSOS, where European regulations for Electronic Health
Record interoperability implementation are defined.

V. MONERE: MONITORING, CONNECTING &WATCHING
Monere is a word from ancient Latin that means watching,
adverting and alerting. These are our goals after continuous
monitoring through this multi-protocol card which connects
a set of clinical devices, environmental sensors and systems
through various communication protocols, so as to provide
the capabilities to reach the mentioned goals with the
support for ubiquitous data collection and global access.
This not only offers the functionalities of IEEE manager, but
also facilitates the retrieval of information from the different
clinical sources, as well as the integration of information
with the Information Infrastructure.



Fig. 3. Monere platform with the communication board and the integrated touch screen.

This platform is presented in Figure 2, which is based on
the 32-bit processor ARM9@400Mhz supporting Linux OS,
with 256MB LPDDR RAM memory, and 256MB NAND
memory. This offers Ethernet 10/100Mbps (A), two USB
2.0 ports (B), four Serial RS232 ports (C), Bluetooth 2.1
with HDP profile compliant with BlueGiga (D), GPRS from
WaveCom (E), ZigBee/6LoWPAN from Jennic (F), 24
inputs/outputs among digitals/analogs/relays (G), a compact
flash support for data logging (H), and a touch screen LCD
(I). Finally, there are some other interesting capabilities for
continuous monitoring, such as a real-time watch, five high
precision timers, two analog/digital converters for analog
signal processing, a random number generator for security
seeds, and IPv6 stack support.
Monere offers a new dimension of networked and
scalability capabilities to reach a higher interoperability,
medical error reduction, and remote device management
(monitor and repair). It also connects all kinds of devices
such as sensors, and patient monitors, and collects context
information such as patients activity, including factors such
as environmental status.
Monere platform is a modular hardware, and its drivers
are based on Linux OS, making the upgrading of platform
components feasible without having to reconfigure all the
other ones. This makes it more robust and expandable.
Furthermore, a previous version of Monere has been
deployed already in a building automation solution [16], and
it is being piloted at a hospital, showing its availability and
robustness capabilities. In addition, this architecture
presents a hierarchical deployment, where several Monere
are deployed, e.g. one per clinical bed or room, where a
system is taking care of another one, in order to reduce
points of failure and make it highly available.
This also offers the capacity for continuous monitoring
and logging by using the Information Infrastructure through
Internet and, at a local level, by having the support of the
mentioned compact flash for offline deployments, or in case
of connection disruption.
This system has a very flexible and open connectivity
support for clinical devices, via RS232 and Bluetooth
Health Device Profile (HDP) compliancy, which is
supported by iWRAP firmware by BlueGiga. Bluetooth has
been considered for the integration of sensors into this
gateway, since it is used as a secure and reliable connection
in a variety of medical applications. The implementations
have been typically based on Bluetooth SPP and on the
manufacturers specific proprietary implementations;
however, since the definition of the ISO/IEEE 11073-20601
Personal Health Data Exchange Protocol, and IEEE 11073-
104xx device specializations, the application level
interoperability is being extended among different clinical
and collection devices, such as the ones presented here,
from different manufacturers.
Additionally, under this work clinical devices are adapted
to 6LoWPAN (IPv6 over Low Power Wireless Personal
Area Networks), a protocol defined by the Internet
Engineering Task Force (IETF) which extends Wireless
Sensor Networks to Internet, adding IEEE 802.15.4 a layer
to support IPv6. 6LoWPAN presents advantages as regards
previous solutions based on Bluetooth, because with this
protocol the value is transmitted directly without any user
interaction, i.e. user does not need to set up a mobile phone
or similar. That feature is interesting for elderly patients
who are not accustomed to new technologies, as well as for
the extension of coverage from a range of 10-15 to over 100
meters, allowing monitoring of users during usual activities
at home, i.e. Activities Daily Living (ADL).
Finally, this platform is an integrator of information
provided by sensors through the different protocols, which
parses and translates the application layers received in IPv6
packets or native protocols, into an application level
interoperable framework based on HDP for clinical devices.
Monere is being integrated with CEN/ISO 13606 for the
interoperability with the Information Systems, as an
alternative to the current communications based on HL7.

Fig. 4. Movital device to adapt the devices to the Internet of Things, top
picture is top view and bottom picture is cross view.


VI. MOVITAL: MOBILE VITAL SIGNS MONITORING
This architecture needs to support the integration and
adaptation of clinical devices to IoT technologies, since it is
required to provide ubiquitous connectivity. For that reason,
Monere platform is completed with a mobile and wireless
device in order to integrate clinical devices, Movital (mobile
vital sign monitoring). It is presented in Figure 4.
Movital adapts basic communication technologies such as
USB/RS232/IrDA (A) to 6LoWPAN, to allow interaction of
the collected data with other entities of the architecture. It
also integrates RFID technology to allow the identification
of patients to personalize the services, and identification of
physician for responsibility issues, which is required for
environments with multiple patients, such as senior
residence, to link data to patient and physician identity.
As a result, Movital is the combination of the mentioned
new generation technologies, including SkyeModule M2,
from SkyeTek (B) for contactless identification (RFID and
NFC), and module Jennic JN5139 for 6LoWPAN (C).
The size of Movital has been minimized to a credit card
size for an easier integration. Furthermore, it is powered
with reachable lithium batteries to optimize lifetime. This
leads to a compact module which acts as an efficient
information exchange gateway between clinicians, patients
and information infrastructure.
In order to ensure the Quality of Privacy (QoP) and
Security, Movital offers security capacities through
symmetric-key encryption AES 128 bits, integrity based on
CRC16-ITT, and asymmetric-key encryption based on
Elliptic Curve Cryptography (ECC), in order to adapt public
key algorithms and support low cost, high performance, and
secure authentication [14]. These capacities are required
since privacy is the most relevant issues in healthcare and
IoT, due to openness and ubiquity features.
Movital also offers support for mobility, which has been
solved with a novel mobility protocol. This supports mobile
monitoring in patients environments, as well as in critical
situations e.g. refineries [17]. Mobility is one of the major
advantages from IoT for ubiquitous healthcare solutions.
Movital also presents a flexible use with a unique module
of several sensors; for that reason, we have included a
switch to select the device in a determined moment (D).
Finally, as it has been mentioned, Movital function is
focused on the integration of clinical devices, offering a
solution with backward compatibility, since the clinical
devices defined by clinical partners. Some examples of
integrated sensors are found in Figure 5, where patient
monitors are integrated, something which is not usually
considered for this kind of solution, but it was required.
Specifically, Movital is offering a new generation of
clinical devices with advanced capabilities. The usual
sensors found in the market are denominated simple, i.e. a
clinical device which offers a single function with low
network impact, administration and integration, such as the
3-lead electrocardiogram by Medlab (Figure 5.H), which, in
turn, is extended with Movital in order to reach complex
clinical devices. Complex clinical devices not only
integrate some administrative functions, they also offer high
network capabilities such as Ambulo (Figure 5.D), the blood
pressure sensor by A&D (Fig. 5.E), the ear thermometer by
Clever (Figure 5.G), and the 7-leads ECG by CardioBlue
(Figure 5.I).

Fig. 5. Top: Patient monitor with an adapted version of Movital
integrated, and in the bottom: wearable, portable clinical devices

The next level which is not usually considered for this
solution is the compound, i.e. patient monitors, which
presents a multifunction device evolving medium
technology, with medium integration, management
requirements, and network capabilities. For example, the
VITRO patient monitor by Medlab in top Figure 5. This
monitors multiple vital signs, from non-invasive blood
pressure (NIBP) to pulse-oximeter and heart rate. This also
carries out an algorithm that amplifies real pulses and
suppresses artefacts. These modules also have been
extended with a version of Movital in the communications
box (A), which includes the 6LoWPAN transceiver by
Jennic (B), and a RFID reader to identify patient/nurse (C).
Finally, the compound-complex defines a multiple
function system, with highly evolving technology, high
administrations, networks and integration capabilities, and
even supports clinical decision making. This level is only
reached with the Movital and the Monere platforms, since
they are able to carry out local and remote processing with
intelligent information systems to detect anomalies and
evaluate patients status. An example of this is intelligent
insulin therapy developed by Movital with the glucometer
presented in Figure 5.F [5], which is connected via IrDA to
Movital and a touch-screen for user interaction with the
intelligent system, and the solution for continuous ECG
analysis for the module from Figure 5.H [18].



Fig. 6. Home Respiratory Therapy based on Ubiquitous Integrated Clinical Environments.

VII. EVALUATION: HOME RESPIRATORY THERAPY
A. Scenario
The experience and scenario evaluation started with the
deployment of a previous version of the solution in Hospital
Clnica del Valls (Barcelona). The deployment was
composed of 14 rooms, where the platform was integrated in
the headboard of the bed and continues being used
nowadays
b
. Movital has been evaluated in assisted living
environments for diabetes management [5], and the
evaluation of the new version of the platform based on IoT
is being carried out for home therapy of respiratory
illnesses, such as Chronic Obstructive Pulmonary Diseases
(COPD) under the AIRE project.
This evaluation is focused on the validation of the design
issues and integration aspects from the architecture. Figure
6 shows the architecture of the defined solution, where we
consider clinical devices for different continuous and
discrete vital signals, which are relevant for different
respiratory illnesses. The first one is the wearable pulse
oximeter Wrist OX2 by Nonin (Figure 6.A), which offers
continuous oxygen saturation monitoring. This offers
connectivity based on Bluetooth HDP, and its clinical
purpose is relevant the majority of breathing problems, since
oxygen saturation is directly related to insufficient
respiration. This sensor connects directly to the Monere
platform.
Monere is integrated in the bed in collaboration with
Industrias Pardo under AIRE project, since as it has been
mentioned in Section II, continuous monitoring of patients
during the night is highly relevant.
The second integrated sensor is the patient monitor,
CAP10 by Medlab (Figure 6.B) for continuous monitoring
of CO2 level and breathing (i.e. capnography). This has
been also integrated with Movital, such as VITRO. This also
offers serial interface for connecting directly to the Monere
platform in case of being deployed next to the patients bed.
The third integrated sensor is the Peak Expired Flow
(PEF) PF-100, by Microlife, to monitor lung capacity for
asthma. This transmits discrete values via Moviital.

b
Intelligent Beds project, video and pictures of the deployment:
http://ants.inf.um.es/projects/ibeds/index.php, 2009.

Other portable sensors are also considered, like those
carried out by the caregivers, since they require assistance
from a specialist. The spirometer, used for periodic revision
of the disease evolution, is an example. Portable devices
integrate RFID to identify not only the patient who
corresponds to the test carried out, but also the specialist
who has attended the patient.
Monere also controls the oxygen therapy through one
analog input in order to monitor the oxygen flow. This
integration for monitoring the home respiratory therapy
compliance with a native interface from Monere, presents
the capabilities and flexibility of the developed platform.
In this respect, the IoT offers advantages for this solution,
such as the capability of interconnecting the clinical devices
through Bluetooh and 6LoWPAN, as well as the patients
and caregivers identification through RFID. On the other
hand, it offers the capability to interconnect the system not
only with the neumology platform, for a frequent follow-up
from the specialist, but also with the Hospital Information
System to transmit information about the evolution of the
patient, and finally with an intelligent information system,
for automatic evaluation of patient evolution, and detection
of any relevant anomaly.
Finally, this also allows the interconnection with user
interfaces such as smart phones and tablets. Figure 6.C and
Figure 7, shows a snapshot of the application for consulting
the patients vital signs status and evolution.
In conclusion, Sections V and VI have presented how the
proposed Monere and Movital platforms satisfy the
requirements and design issues mentioned in Section II,
with regard to communication issues such as scalability,
robustness, security, privacy, expandability, availability,
flexibility, and to features of the services, such as mobility
and continuous logging, as well as monitoring. In addition,
they include to specific requirements from the solution such
as interoperability, backward compatibility for integration of
the current clinical devices and patient monitors, as well as
the identification of caregivers to address the responsibility
of medical assistants and caregivers. Finally, this section
presents how the integration of the presented platforms and
clinical devices. The following subsections demonstrate the
new services, capabilities, and advantages reached with the
integration of the Future Internet of Things through
WebServices and IPv6 for multimedia interface integration.


B. Multimedia User Interface
The end user interface is focused mainly to be located at the
new generation of smart devices such as smart phones (see
Figure 6) and tablets (see Figure 7). In addition, it has been
also defined an embedded user interface in the Movital (see
Figure 5.H), and in the Monere (see Figure 3.I). These last
two interfaces are mainly focused for management and
configuration steps. The Android OS-based interfaces for
the Google Nexus S, and the Samsung Galaxy Tab offer an
intuitive and simple interface for the collection of the data
through WebServices and IPv6 through the WiFI connection.
It is not considered 3G, since it is not yet offering IPv6.
The WebServices from the clinical devices point of view
are based on CoAP WebServices [18] over 6LoWPAN,
which are being offered by the Movital devices presented in
the previous section. The integration of IPv6/Glowbal IP
and WebServices in Movital is explained in [19].
In addition, it is being also considered the Near Field
Communication (NFC) technology as a medium to transfer
the data from the Google Nexus S application and the
clinical devices [20]. This offers a user interface very
intuitive, i.e. just approach, which is very interesting for
elderly people.
The interface is focused for the parameters from the
AIRE project. The vital sign monitored are breathe per
minute, etO2, and CAP curve from the capnografy (see
Figure 6.B), Spo2 from the pulse-oximeter (see Figure 6.A),
and finally Peak Expiratory Flow (PEF) from the peak flow
meter (see Figure 6.C). In addition, it is considered an ECG
from the solution [18] to measure the ECG and heart-rate. It
can be seen that it is carried out a pre-diagnosis of the status
of the patient, on the one hand for the ECG, and on the other
hand for the Insufficiency Respiratory Evaluation (AIRe).


Fig. 7. User Interface based on Galaxy Tab and connectivity through
IPv6-based on wireless local area network (WLAN).
C. Technical Evaluation
The technical evaluation of the communication between
Movital and Monere is based on YOAPY pre-processing
module. This module is required, since it was initially
concluded that the native RAW mode transmission from the
clinical sensors presents an intensive quantity of
information. Therefore, this produces a delay for real-time
and continuous monitoring of vital signs. Since, this
generates more information that technologies such as
6LoWPAN and Bluetooth are able to transmit. For that
reason, YOAPY carries out a pre-processing and analyzes
the relevant parts from the vital sign to compress the
gathered RAW data, and make feasible its continuous and
real-time transmission, YOAPY also presents optimizations
regarding power consumption, and this introduces security,
integrity, and privacy capabilities to the communication.

1) YOAPY for a wearable electrocardiogram (ECG)

The pre-process and ECG data compression methods can be
found in current research literature. Some of the most
relevant studies are based on wavelet-based. These
approaches are focused on the QRS complex, which is a
group of waves depicted on an ECG signal. QRS complex is
the most important clinical part of the cardiology system
and determines the normal or abnormal arrhythmia
occurring in the heart (see Figure 8 for QRS complex
identification). The problem is that wavelet-based method is
not suitable for the constrained chips located at the
platforms from the Internet of Things such as Movital.
For that reason, this work proposes a simpler pre-
processed based on representations of the waveform with
the amplitude and times of each one of the significant points
from the curve [21], i.e. P, Q, R, S and T points, since it is
really the relevant information. Figure 8 presents the
significant points from the curves, which are transmitted
when it is considered the use of the YOAPY compression.
The format presented in Table I consumes 10
bytes/sample, which means that 5 samples are transmitted in
a frame. In addition, this pre-process makes the
development of health status monitoring solutions easier.


Fig. 8. Representation of the pre-processed trace. Top corner is the
reference. Points are P:green, Q:yellow, R:pink, S:blue, T:dark blue.
a) Overload and payload size
The overload is reduced by YOAPY where an ECG
trace of 257 bytes is reduced to 10 bytes (see Table I).
Therefore, considering the available payload of 76bytes
[19]; 6 frames are required per sample in the original format.
The new format allows the inclusion of 5 samples in a frame.

Reference
wave trace


TABLE I. FORMAT FOR ECG PRE-PROCESSED SAMPLES
0 1 2 3 4 5 6 7
BPM P Q R S T S_TP S_PQ
68
0x44
132
0x84
121
0x79
185
0xB9
122
0x80
144
0x90
151
0x97
9
0x09
S_QS S_ST S_RS Other samples (until a total of 5
samples, it is a fix number to avoid
counters)
32
0x20
3
0x03
71
0x47

Thereby, this also allows to include security support.
Specifically, it is considered two security levels; ECDSA,
which requires a field of 16bytes for the digital signature,
and AES-CCM-128 Link Layer Security, which requires
21bytes. They offer integrity and confidentiality, and an
additional timestamp is considered to ensure freshness.
Overload is summarized in Table II.

TABLE II. OVERLOAD EVALUATION BY SECURITY LEVELS & YOAPY
Security
Level
Security
Overload
+
Timestamp
Available
Payload
#frames
with RAW
data
#samples in
a frame
with YOAPY
less 1 packet
per sample
AES-CCM
128bits
Layer
Security
23bytes +
2bytes =
25bytes
76bytes
25bytes =
51bytes
257/51
6 packets
for a
sample
(51-1)/10
5 samples
in one
packet
ECDSA
160bits
based on
ECC
16bytes +
2bytes =
18bytes
76bytes -
18bytes =
58bytes
257/58
5 packets
for a
sample
(58-1)/10
5 samples
in one
packet
b) Power consumption
Power consumption of Movital is measured for the different
operations. In normal conditions, Movital enters sleep mode
for the sake of power saving, and the power consumption
from the board is 0,72mA from a mere 0.06uA from the
transceiver. When the sensor module wakes up, due to an
abnormal event or periodical tasks, the Movital module
enters a CPU doze mode, where consumption varies
between 41mA and 48mA. UARTs are used for this mode,
one for debugging and another to connect the clinical sensor.
Finally, receiving and transmitting 6LoWPAN packets
varies between 44m and 56mA. Power consumption is
summarized in Table III.
TABLE III. POWER/RADIO CHARACTERISTICS IN MOVITAL
Power/Radio
Mode
Datasheet (D) and
Application Note (AN)
references [5] for
6LoWPAN transceiver
Empirical
value from
oscilloscope
in Movital
Deep sleep
current
1.6uA from D and
0.06uA from AN
0,72mA for
any sleep
mode, it is
the lowest
consumption.
Sleep current
with wake up
(I/O and Timer)
2.8uA from D and
3,5uA from AN
Active
Processing,
i.e. CPU Mode
2.85 + 0.285 per MHz,
i.e. 7,41mA for 16Mhz
CPU
41mA to
48mA, we are
considering
the maximum
value equal
to 48mA
Active CPU and
transceiver
idle (CPU doze)
27,3mA from AN
Radio transmit
current
37mA from D and 38mA
from AN
44mA to
56mA, we are
considering
the maximum
value equal
to 56mA
Radio receive
current
37mA from D and AN
UART (Sensor
connection)
Additional current of
0.095mA for each
o3wne from AN

Power consumption to transmit a 6LoWPAN packet is
presented in the Figure 9, where this spends 34,2ms. It could
be considered that for a frame of the maximum length i.e.
127bytes should spend a total time of 4,064ms (250kbps
bandwidth). However, this consumes 30ms more because
the time required to turn on the transceiver and the
application of CSMA/CA algorithm to access the radio
medium, i.e. Clear Channel Assessment (CCA), is
performed to determine if the channel is currently in use.
CCA takes 8 symbol periods (0.128 ms) to complete a
assessment. Once the channel is assessed to be free, this
sends the packet. After, it waits around 1.3ms, and then it
switches again to the radio transceiver to receive the
corresponding acknowledgement (ACK message).
In conclusion, the relation between total transfer time
and payload time is highly unbalanced (4ms/34ms).
Therefore, our goal is to reduce the number of total frames.


Fig. 9. Power analysis for the transmision of a 6LoWPAN packet
carried out with the Tektronix DPO 7104C and a shunt resistance of
10 0.5%. It is presented V:yellow, I:blue, and Power:orange.
c) Lifetime and Latency from security
Once the power consumption of a sensor node is measured
for each frame, then the number of frames required for the
ECG wave transmission is estimated, and the lifetime for a
battery can be derived. Assuming an ECG contains 70bpm,
the device requires 0,3125s of CPU for each second to
receive the data from the sensor, i.e. ECG with a sample
frequency of 300Hz and a speed of 9600bps. Hence, the
basic power consumption is:
0,313s48mA+(10,313s-s)0,72mA = (15,5-0,72)mAs (2)
This also requires the consumption during the time , which
is the required to encrypt and transmit the packet. The
encryption time depends on the security level.
The time it takes AES-CCM-128 to encode 51bytes from
payload (64bytes, since 16bytes multiple is required) is
61ms. This is not suitable for the RAW data, since it only
can transfer 16 frames per minute and 420 frames are
required. But, it is suitable with the 14 frames per minute
required after YOAPY module pre-processing.
14(0,034s56mA+0,061s48mA) =67,8mAM=1,13mAs
=1,3328s for each minute = 0,022s for each second (3)
Total consumption=15,5-0,720,022+1,13 0,022=15,51mAs

The battery capacity is measured in milliamps hours
(mAH). This device has 2 x AAA batteries with 800mAH
drive to continuously transmit packets for more than 100
hours (AES-CCM-128 security and YOAPY pre-processing).
Lifetime=28003600/15,51=371373s=4days 7h 10 m (4)
It is concluded the suitability for continuous data
transmission applying symmetric key cryptography based on
AES, and the Elliptic Curve Cryptography, also proposed
under AIRE project in [14], for establishing the session,
since the digital signature with the optimized ECC stack is
765ms. This latency makes ECDSA unsuitable for the
continuous monitoring.


2) YOAPY for the other devices from AIRE

This section presents another two examples of YOAPY for
continuous sensors. Regarding to discrete sensors such as
temperature and peak flow sensor, it is only requiring a byte
for temperature value, and the peak flow sensor only two
bytes for PEF value, since this version is not calculating
FEV, therefore they present a very low requirements.
a) Patient monitor with ECG and Pulse-oximeter
In addition, to the ECG, it has been integrated the patient
monitor PEARL100 from medlab. This offers a different
format, since this offers the ECG wave and SPo2 value. In
this occasion, it is also analyzed the wave processing peaks
from the QRS complex. YOAPY format for PEARL100
clinical sensor is presented in the Table IV.
TABLE IV. FORMAT FOR PEARL100
0 1 2 3 4 5 6 7
BPM P Q R S T S_P S_PQ
S_QRS S_ST S_T SPo2
b) Capnography
The capnography CAP10 from medlab is offering three
relevant values, breath per minute, etCO2, and the etCO2
wave. This last one can be seen in the bottom part from the
Figure 7. The wave for each breath has a size of 300-350
bytes. Therefore, it is already required to compress it. The
relevant points from the etCO2 wave are the beginning of
the inspiration (point left) and the end of this (point right).
For this is required, 2 bytes for the left point, and 3 bytes for
the right point (since it is over 300 the value, therefore this
requires 2 bytes). The format is presented in the Table V.
TABLE V. FORMAT FOR CAP10
0 1 2 3 4 5 6 7
etCo2 Breaths
per
minute
(BPM)
Point
left
X
Point
left
Y
Point
right
X
(LSB)
Point
right
X
(MSB)
Point
right
Y

VIII. CONCLUSIONS
Ubiquitous Integrated Clinical Environment platform based
on the IoT offers support for large scale connectivity with
different medical devices, as well as integration with
information systems, and continuous monitoring of patients
status. It also improves accessibility to clinical services,
compatibility and ubiquity, enhancing citizen mobility, and
guarantees access to medical information, anywhere and
anytime. Proof of this is the extension of e-Health to mobile
Health (m-Health) with multimedia platforms such as the
presented based on smart phones and tablets, which allows
an ubiquitous access to the patients status and evaluation
through Internet.
Monere and Movital hardware resources make this
integration feasible through seamless communication flows
between heterogeneous devices, hiding the complexity of
the end-to-end heterogeneity to communication service, and
supporting security and mobility.
Ongoing work is focused on the economic impact
evaluation of the presented solution for home respiratory
therapy, not only because it is one of the main requirements
for healthcare providers to deploy these solutions, but also
because it demonstrates the suitability and profitability of
the ubiquitous healthcare solutions.
REFERENCES
[1] Atzori, L.; Iera, A.; Morabito. G.; The Internet of Things: A survey.
Computer Networks Vol. 54, No. 15, pp. 2787-2805, 2010.
[2] Istepanian R.S.H.; Jara, A.; Sungoor, A.; Philips, N.: Internet of
Things for M-health Applications (IoMT), AMA IEEE Medical
Technology Conference on Individualized Healthcare, Washington
(USA), 2010.
[3] Dohr, A.; et al.; "The Internet of Things for Ambient Assisted
Living,", ITNG, pp .804-809, Seventh International Conference on
Information Technology, 2010.
[4] Zorzi, M.; Gluhak, A.; Lange, S.; Bassi, A.; "From today's INTRAnet
of things to a future INTERnet of things: a wireless- and mobility-
related view", Wireless Communications, IEEE, Vol. 17, no. 6, pp.44-
51, 2010.
[5] Jara, A. J.; Zamora, M.A.; Skarmeta, A.F.G.; An internet of things
based personal device for diabetes therapy management in ambient
assisted living (AAL), Personal and Ubiquitous Computing, DOI:
10.1007/s00779-010-0353-1, Vol. 15, no. 4, pp. 431-440, 2011.
[6] Chung-Chih Lin; Ming-Jang Chiu; Chun-Chieh Hsiao; Ren-Guey
Lee; Yuh-Show Tsai; "Wireless Health Care Service System for
Elderly With Dementia," Information Technology in Biomedicine,
IEEE Transactions on , vol.10, no.4, pp.696-704, Oct. 2006.
[7] Yao, J.; Warren, S.; Applying the ISO/IEEE 11073 Standards to
Wearable Home Health Monitoring Systems, Journal of Clinical
Monitoring and Computing, Vol. 19, No. 6, pp. 427-436, 2005.
[8] Shuenn-Yuh Lee; Liang-Hung Wang; Qiang Fang; "A Low-Power
RFID Integrated Circuits for Intelligent Healthcare Systems,"
Information Technology in Biomedicine, IEEE Transactions on ,
vol.14, no.6, pp.1387-1396, Nov. 2010.
[9] Perakis, K.; Haritou1, M.; Koutsouris, D.; ALADDIN, technology
platform for the Assisted living of Dementia elderly INdividuals and
their career, International Workshop of Ambient Assisted Living
(IWAAL'09), IWAAN 2009, Part II, LNCS 5518, pp. 878-881, 2009.
[10] Yu, Chun; et al; "Implementation of Smart Medical Home Gateway
System for Chronic Patients", 13th International Conference on
Biomedical Engineering", IFMBE Proceedings, Springer, pp. 1086-
1089, Vol. 23, 10.1007/978-3-540-92841-6_267, 2009.
[11] Chung-Chih Lin et al.; A pervasive health monitoring service system
based on ubiquitous network technology, International Journal of
Medical Informatics, Vol. 77, Issue 7, pp. 461-469 , 2008.
[12] Geng Wu; Talwar, S.; Johnsson, K.; Himayat, N.; Johnson, K.D.;
"M2M: From mobile to embedded internet," Communications
Magazine, IEEE, DOI: 10.1109/MCOM.2011.5741144, Vol.49, no.4,
pp.36-43, April 2011.
[13] Yan Zhang; Rong Yu; Shengli Xie; Wenqing Yao; Yang Xiao;
Guizani, M.; "Home M2M networks: Architectures, standards, and
QoS improvement," Communications Magazine, IEEE , vol.49, no.4,
pp.44-52, April 2011.
[14] Marin, L.; Jara, A.J.; Skarmeta, A.F.G.; Shifting Primes: Extension
of pseudo-Mersenne primes to optimize ECC for MSP430-based
Future Internet of Things devices. Multidisciplinary Research and
Practice for Business, Enterprise and Health Information Systems,
Springer, LNCS, 2011
[15] Lopez, G.; Canovas, O.; Gomez-Skarmeta, A.F.; Girao, J.; A SWIFT
Take on Identity Management", DOI: 10.1109/MC.2009.141,
Computer, Vol.42, no.5, pp.58-65, May 2009
[16] Zamora, M.A.; Santa, J.; Skarmeta, A.F.G.; An integral and
networked Home Automation solution for indoor Ambient
Intelligence, IEEE Pervasive Computing, Vol. 9, pp. 66--77, 2010.
[17] Jara, A.: Silva, R.M.; Sa Silva, J.; Zamora, M.A.; Skarmeta, A.F.G.;
Mobile IP-based Protocol for Wireless Personal Area Networks in
Critical Environments, Wireless Personal Communications, ISSN:
0929-6212, Vol. 61, No. 4, pp. 711-737, 2011.
[18] Guinard, D.; Trifa, V.; Karnouskos, S.; Spiess, P; Savio, D;
"Interacting with the SOA-Based Internet of Things: Discovery,
Query, Selection, and On-Demand Provisioning of Web Services",
Services Computing, IEEE Transactions on, Vol.3, No.3, pp.223-235,
doi: 10.1109/TSC.2010.3, 2010.
[19] Jara, A.J.; Zamora, M.A.; Skarmeta, A.F.G; Glowbal IP: an adaptive
and transparent IPv6 integration in the Internet of Things, Mobile
Information Systems, IOS Press, in press, 2012.
[20] Jara, A.J.; Lpez P.; Fernndez D.; beda, B.; Zamora, M.A.;
Skarmeta, A.F.G; Heart monitoring system based on NFC for
continuous analysis and pre-processing of wireless vital signs,
International Conference on Health Informatics, HEALTHINF, 2012.
[21] Jara, A.J.; Marin, L.; Zamora, M.A.; Skarmeta, A.F.G.; "Evaluation
of 6LoWPAN capabilities for secure integration of sensors for
continuous vital monitoring", V International Symposium on
Ubiquitous Computing and Ambient Intelligence (UCAmI'11), 2011.