Future Internet of Things Platform for Ubiquitous

Integration of Clinical Environments at Patient’s House Antonio J. Jara, Miguel A. Zamora-Izquierdo, and Antonio F. Gómez-Skarmeta

1Abstract —This work presents a next generation clinical

architecture based on the Future Internet of Things for

extending a patient’s environment to integrated clinical

environments. It 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 RFID. Movital additionally supports

communication capabilities to allow a secure, scalable and

global integration of the sensors deployed at the patient’s

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

Integration 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 AIRE project.

Index 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 “Fundación Séneca” (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 Atención 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 patient’s 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 Integration 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 patient’s

environments, such as the patient’s 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 patient’s sensors.

Ubiquitous Integration 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 patient’s 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 patient’s 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 patient’s

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 patient’s 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 “Clínica del Vallés” 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 patient’s

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 patient’s 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 patient’s 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 patient’s 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 patient’s 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

patient’s 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 patient’s 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

manufacturer’s 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 patient’s 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

“Clínica del Vallés” (Barcelona). The deployment was

composed of 14 rooms, where the platform was integrated in

the headboard of the bed and continues being used

nowadaysb. 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 patient’s 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 patient’s 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:

smAs-s)mA-0mAs

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.

smA+0,061smA) =67,8mAM=1,13mAs s for each minute = 0,022s for each second (3) Total consumption=-00,0221,13 0,022mAs

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=2s=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 patient’s

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 patient’s 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.; López P.; Fernández 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.