AMBIENT HEALTHCARE SYSTEMS

Using the Hydra Embedded Middleware for Implementing an

Ambient Disease Management System

Heinz-Josef Eikerling, Gernot Gräfe, Florian Röhr

Siemens AG SIS C-LAB, Fürstenallee 11, D-33102 Paderborn, Germany

Walter Schneider

Paderborn University C-LAB, Fürstenallee 11, D-33102 Paderborn, Germany

Keywords: Disease management, Embedded systems, Middleware, AmI, Ambient intelligence.

Abstract: Healthcare is an important aspect of ambient life. As the life expectation increases and thus diseases

statistically become more frequent, the high-quality and cost-effective management of such diseases

becomes a societal task. Within this paper we examine issues and requirements stemming from the

implementation of disease management systems. Such systems critically depend on acceptance, cost-

efficiency and other criteria that – through those requirements – are addressed by the Hydra multi-domain

middleware. Hydra aims at the seamless integration of embedded systems such as bio-medical sensors and

other domain-specific and generic equipment. We motivate and demonstrate the use of the middleware in

the healthcare sector by means of a disease management system relying on the easy integration and proper

configurability of applications running on the included measuring and controlling devices.

1 INTRODUCTION

From an economic perspective, healthcare is an

evolving market. It constitutes a complex system

with a plethora of requirements specific to each

stakeholder, e.g. patients and their families, health

care professionals, health care providers (public and

private), governmental agencies and insurance

companies.

This paper describes the application of technical

means provided by the Hydra project addressing

some of the emerging needs in the health care

domain. The designed health care system

particularly takes into account that people suffering

from temporary, as well as chronic diseases, will

make increased use of technologies that support

continuous health monitoring, as well as care in

terms of medication and advice, in order to mitigate

disabilities and maintain, or even improve, their

health status. Health care services will therefore

have to be offered in an ambient way, e.g., while

being in the domestic environment (Goubran, 2007),

while being at work, on the move etc. Consequently,

for medical devices to become a part of an ambient

environment should automatically integrate

themselves into the varying ambience of the user –

nursing home, hospitals, work place or at home – so

that biomedical data triggering appropriate activities

can be seamlessly transmitted to background

systems. Such activity could consist of alerting the

doctor or nurse if a patient’s bio-parameter (blood

pressure, weight, glucose level etc.) changes

critically.

Before describing the benefits of the Hydra

middleware, background information on disease

management systems in terms of the developments,

requirements and solutions steering our efforts will

be provided. Subsequently, the application of the

Hydra middleware to a concrete application scenario

that addresses the use of Hydra for dynamically

connecting and configuring medical sensors, e.g. a

blood pressure measuring device or glucose

metering device, plus the software running on top of

it will be described. Finally, some extensions and the

key open issues that must be addressed in the future

will be discussed.

Eikerling H., Gräfe G., Röhr F. and Schneider W. (2009).

AMBIENT HEALTHCARE SYSTEMS - Using the Hydra Embedded Middleware for Implementing an Ambient Disease Management System.

In Proceedings of the International Conference on Health Informatics, pages 82-89

DOI: 10.5220/0001553000820089

 SciTePress

2 DISEASE MANAGEMENT

2.1 Major Trends

Currently the healthcare domain faces a significant

change caused by the following tendencies:

 Demographic change and aging population:

Developed countries have to deal with an aging

society and growing life expectations.

According to a report published by the UN’s

Department of Economic and Social Affairs

(see UN report, 1998), 22% of the world’s

population will be 60 years or older in 2050.

Especially Europe will be affected as 35% of

Europe’s citizens will be 60 years or older.

Senior citizens in particular will need medical

assistance.

 Environmental changes:

 Urbanization: More and more people are

moving from rural areas into the cities

because of comparably better job

opportunities and a potential higher

standard of living. Negative environmental

influences in cities caused by local excess

of population like air pollution will result in

rising numbers of patients suffering from

respiratory and other fatal diseases.

 Industrialization and climate change:

Since starting weather and climate

recordings, experts have recognized a

dramatic change of the climate and an

increasing number of natural disasters due

to increasing temperature on earth caused

by CO2 emissions and industrial pollutions.

On a long term perspective respiratory and

cardiovascular diseases will potentially

increase.

 Cost pressure: Due to the demographic change

in the developed countries some social

healthcare systems are seriously struggling, as

decreasing or stable tax incomes cannot bear the

increasing costs for healthcare caused by an

aging society. In developing countries there is

an increasing growth in population and

therefore an increase in healthcare demand in

total. Thus the demand and total costs for

medical treatments and assistance have already

started to dramatically increase.

 New medical treatment and surgery methods

and processes: New medical treatments are

emerging which result in patient-centric care at

the cost of additional health care expenses.

2.2 Actors and Stakeholders

Besides these global trends and challenges, four

groups of stakeholders have been identified in the

healthcare domain. Each group represents different

trends and challenges with respect to their objectives

and tasks.

 Patients who require medical treatment are

interested in participating in medical decisions

and have an increased demand of preventive

examinations like check-ups for cancer. A large

share of patients is willing to pay more for

health and also wellness.

 Providers, e.g. doctors, nurses, hospitals and

nursing homes, which provide medical

assistance and treatments, are facing exploding

costs and capacity shortness. Therefore they

have to optimize their resource allocation to

achieve an increase in efficiency by applying

new ways of medical assistance and care.

 Governmental agencies are struggling to

ensure the quality of the national health systems

albeit ever increasing costs.

 Cost bearers e.g. insurance companies, which

compensate the medical treatment costs, are

facing exploding health expenses and therefore

looking for new ways to reduce medical

treatment costs.

Nevertheless the demographic change and the

enormous cost pressure harbour the chance for

companies acting in the healthcare sector as service

providers to introduce new concepts, like integrated

supply, prevention in terms of medical wellness as

well as assisted living. Especially health insurance

companies and hospitals are looking for innovative

concepts and IT solutions that help to keep costs as

well as the rising number of patients manageable.

Therefore disease management solutions that

support assisted living, improve medical treatments,

provide monitoring of patients and increase the

efficiency within the health systems seem to be one

of the most promising ways to reduce costs and to

keep the growing number of patients manageable at

an at least stable quality level of medical service.

2.3 Opportunities

Supporting ambient health care through technical

means may definitely constitute a countermeasure to

abate the increasing costs resulting from the above

AMBIENT HEALTHCARE SYSTEMS - Using the Hydra Embedded Middleware for Implementing an Ambient Disease

Management System

trends. The figures below illustrate the economic

potential of disease management applications for

monitoring patients’ sensitive bio-data (see reference

list).

 33% of the elderly are interested in assisted

living services, but less than 30% are willing to

pay for such services. According to an US

survey, 92% of people aged 65 to 74 and 95%

of people older than 74 years want to stay at

home instead of living in a nursing home.

Nevertheless more than half of all 85 year olds

need daily assistance (see BMBF 2008).

 According to the US Department of Health and

Human Services chronic illnesses cause more

than 75% of the medical care costs in the United

States. In Germany for example the costs for

diabetes and cardiovascular diseases amount up

to 31.4 and 35.4 Billion € per year.

 The medical care of an Alzheimer patient costs

64.000 US $ a year in an US home for elderly

people whereas a home monitoring would cost

20.000 US $. Daily costs for home monitoring

would lie between 3 and 5 US $. The costs for a

video based monitoring amounts to around 35

US $. In Germany 2 million people are in need

of daily assistance. This causes yearly costs of

more than 17 Billion €. Nursing home

occupancy costs almost 4.000 € a month.

2.4 Key Functional Requirements

Especially elderly people and people with limited

abilities who need daily assistance would benefit

from ambient assisted living featured into the

domestic environment. Such forms of assisted living

at home require special IT systems which support

functionalities to remotely control vital functions

and bio data and enable health professionals like

doctors and nurses to monitor and steer care

processes. In order to do so, the systems consisting

of devices, services and applications must

A. support to seamlessly interconnect devices like

wireless sensors, medical / user devices and

applications on top of them,

B. enable the exchange of information in various

communication modes depending on a

dynamically changing networking environment,

C. offer convenience such as detecting and

handling a patient’s context including critical

conditions,

D. implement safety and security in the ambient

environment though this is a rather broad topic

particularly in the health domain.

When dealing with specific applications for

specific purposes in healthcare, ideally such

requirements would be covered (at least to a certain

extend) by an underlying system platform.

2.5 Challenges

The above requirements are slightly more general

than those mentioned in Stankovic et al. 2005. They

result in several challenges for the system platform

which will have to be addressed when compared to

the state of the art.

Concerning A., a platform will have to deal with

enormous device diversity. A huge amount of

medical devices exist today. Some are equipped with

wireless (I/R or Bluetooth, future devices may also

support emerging standards like Wireless USB) or

wired interfaces (USB, serial interface). For

seamless integration, particularly bio-sensors will

have to be modelled in order to be readily used.

Also, it should be taken into account that multiple

sensors will have to be handled simultaneously in

case of multi-disease management. With respect to

B., today it is still quite challenging to deal with the

plethora of low-footprint (in terms of computing

resources and energy consumption) protocols

implemented on typical bio-sensors. Beyond multi-

protocol support robust communication mechanisms

in the platform will have to deliver advanced

synchronisation mechanisms taking into account

temporary off-line situations. Features for context-

awareness (C.) will have to support federated or at

least decentralized decision making which will have

to be backed by central supervision. Especially for

D., there are also reliability aspects which will have

to be addressed by the platform for the sake of

ensuring timely reaction in case of emergency and

for monitoring the service level for billing and other

purposes.

2.6 Sample Scenario

Our sample healthcare scenario addresses the

proliferation of self-management schemes for long

term diseases. Clinicians and developer users work

together to bring about a wealth of smart devices and

low power sensors in wireless, self configuring body

networks which semantically interface to legacy

health care systems. The systems are reliable and

safe and doctors increasingly rely on access to

remote information, not only to perform diagnosis

but also in order to make long term risk assessments.

HEALTHINF 2009 - International Conference on Health Informatics

The statements above are reflected in a typical

disease management scheme which is partitioned

into the following elements:

1. Device configuration: before doing any

measurements, the sensors and the other

devices, including the applications, need to be

configured in a convenient and preferably

automatic way.

2. Application configuration: building on the

configuration of the physical setup of the

measuring environment, various parameters of

the application such as conditions for triggering

alerts will have to be defined. Such conditions

may constitute a context which requires specific

actions when reached.

3. Monitoring: in this part of the scenario, bio-

data once sensed is automatically (i.e., with

minimum user interaction) transferred to some

background system recording the data and

providing secured access to privileged users,

e.g. the health professionals (physician).

Completely different communication channels

can be used for transferring the data, such as

ordinary stationary Internet or asynchronous

transfer via cellular networks through SMS for

example.

4. Data management and analysis: in order to

prepare for temporary off-line situations, data

will have to be locally cached, thus transferred

in bulk mode to be synchronized with the

background system. Analysis of the collected

data will be offered not only to the health

professional but also to the adequately educated

patient.

We will now describe how, by using Hydra, the

scenario for the monitoring of the patient’s blood

pressure as sensitive bio-data can be implemented

taking into account the requirements mentioned in

2.4. Adaptations to other types of bio-data (glucose

level metering, weight measuring etc.) are straight-

forward.

3 HYDRA MIDDLEWARE

3.1 Overview

Hydra constitutes a middleware for pervasive

embedded and networked systems based on the

service-oriented architecture paradigm. As one

incarnation of this paradigm, web services promise a

composable, interoperable, reusable and Internet-

enabled wrapping of functions as services

(Weerawarana 2005). Increasingly, this approach is

currently extended to resource-constrained

embedded devices like sensors in health care, which

through implementing functions as web services

become pervasive devices. Hydra faces some

challenges in regards to implementing web services

on devices which is prerequisite for achieving this

interoperability. First, the web services should be

adequately efficient in order to realise usable

services on small devices, despite the fact that

embedded devices are constrained in memory,

processor and energy resources. Second,

development of embedded web services must handle

the variability of hardware and software, and

possible dependencies between them. Especially, it

has to be taken into account that the development

effort may involve different implementation

languages and communication protocols. Finally,

there is the question of how to develop pervasive

web service applications efficiently.

Figure 1: Hydra middleware Layered architecture.

In Hydra, the overall functional architecture is

divided into two parts, namely:

 Application Elements (AEs)

 Device Elements (DEs).

AEs are meant to be deployed and run on

comparably powerful machines, and DEs describe

components that are usually deployed inside Hydra-

enabled devices where small devices may be

involved. The Layered architecture of the Hydra

middleware is shown in Figure 1. From a

deployment point of view the differentiation

between the following physical entities is crucial:

 Non-Hydra-enabled devices, which do not host

the Hydra middleware

 Hydra-enabled devices, which do host the

Hydra middleware

 Gateways, special Hydra-enabled devices that

incorporate non-Hydra-enabled devices in the

Hydra network.

AMBIENT HEALTHCARE SYSTEMS - Using the Hydra Embedded Middleware for Implementing an Ambient Disease

Management System

Device

Applicat io n

Bluetooth

Link

Network

Medical

Sensor

Proxy

Controlling

Device

Web

Application

Server

Health Record

Data Store

USER_ID

APP_SERV_URL

deploy /

install

User

Application

Bluetooth

Link

access user

application

- start discovery

- connect sensor

- configure sensor

- send discovered sensors

- transmit health records

Device

Configurations

transmit health records

Figure 2: Architecture Disease Management System.

3.2 HYDRA Managers

According to Figure 1, the middleware comprises a

set of managers, each of which is reflected in the

AEs as well as in the DEs. The following managers

make up the core middleware:

 Network Manager which handles the lower

networking issues as part of the network layer

 Service Manager and the Context Manager on

the semantic layer

 Event Manager which provides publish /

subscribe functionalities on the service layer,

 Device Manager which constitutes a service

discovery back end based on UPnP which offers

the possibility of finding devices that support

different communication protocols,

 Ontology Manager which permits one to

describe devices (like medical devices and other

equipment) on a semantic level,

 Diagnostics Manager which is used to monitor

the system’s conditions and states in order to

fulfil error detection and logging device events.

Hydra also features a so-called Virtual Devices

which is an abstract level on top of the above

definitions of Hydra-enabled devices, Non-Hydra-

enabled devices, Proxies or Gateways. Each of these

devices can have at least one Virtual Device. Such

devices are mainly foreseen to ensure non-

linkability, i.e. to ensure privacy and security a

malicious user cannot link to a device directly and

thereby gain advantage via access to some or all of

the communication running through the device.

Virtual Devices are deployed on a different Gateway

than the owning entity, thus changing the IP address.

Another purpose of virtual devices lies in the

extension or limitation of devices’ or services’

original existing functionalities. A developer user or

an end-user can decide to grant limited access to his

device by offering only a minimised interface via the

virtual device.

4 USING HYDRA

4.1 Featured Devices

Before explaining the deployment of the Hydra

middleware to the various nodes in the Disease

Management System, we introduce the actual

devices featured in the sample scenario as shown in

Fig. 2:

 Measuring device: We use the Corscience /

Omron 705IT BT which measures the blood

pressure on the upper arm. It is equipped with a

Bluetooth interface for wireless data

HEALTHINF 2009 - International Conference on Health Informatics

transmission. The measured value is

automatically transmitted via a Bluetooth-

capable cell phone or an approved Bluetooth

modem to a central archive. A transmitted data

record consists of the serial number, systolic

and diastolic blood pressure values, pulse, time

and date of measurement. Non-transmitted data

is stored in the device. The transmission of

stored data blocks is done at the time of the next

measurement.

 Gateway: standard PC running Windows XP

(laptop) with Bluetooth interface which acts as a

proxy for the measuring device.

 Mobile phone: used as 2nd relay (alternative) to

forward data to the background system. This

relay is used in case the user is in a mobile

context.

 Mobile terminal: laptop, PDA or Ultra-light

computer used for configuring environment

(either initially but also at runtime for

configuring events etc.).

 Application server: hosting the application for

controlling the environment and constituting a

link to back-end services (e.g., storing medical

health records).

4.2 Use of Managers

Figure 2 shows the devices and their interactions.

The whole process of setting up the measuring

environment is triggered by the controlling device

which runs a web application (user application)

hosted by a web application server. The web

application server maintains data bases for storing

the measured data and for managing meta-data

(information concerning device configurations) with

respect to the featured sensor and proxy devices.

Moreover, the application server via some network

is connected to the proxy device in both directions.

I.e. once initiated by the user through the web

application, it asynchronously starts the discovery of

sensing devices on the proxy and takes care of

connecting the selected sensor with the proxy, while

also configuring both the sensor and the proxy. This

requires that the device application that runs on the

proxy has been previously installed. We assume that

the device application is implemented as a service

(proxy service), which has been personalized prior to

deploying it to the proxy such that it knows about

the user (via a unique USER_ID) and the URL of

the application on the application server. The

USER_ID has to match the code that is entered at

the web application client on the controlling device.

Thus there is a one-to-one relationship between

proxy service and user.

According to the above scenario elements, the

following HYDRA managers will be featured:

Device configuration:

 Discovery manager: during the configuration of

the measuring environment, compatible devices

matching the offered protocol (i.e., Bluetooth)

will have to be identified.

 Device Device / Device Service manager:

similar to other medical measuring equipment,

the bpm (blood pressure meter) will provide the

bio-data in a push / master mode which means

that the device is activated and monitored bio-

data is immediately transferred to a configurable

data sink. Thus, the device will have to be

proxified in order to offer push / master as well

as pull / slave style interactions.

SMS

Application

Server

Cellular

Bridge

Network

Manager

Health Record

Data Store

1. On the move: sen ding

health record via SMS.

2. At home: sending

via gate way.

Figure 3: Use of Hydra Network Manager in Disease

Management System.

Through the above managers, various parameters

for the bpm can be configured, some will be

changed automatically or through interactive user

dialogs whereas others will be simply displayed and

stored in a configuration database:

a. Current date & time (automatic)

b. Time zone (automatic)

c. Switch on / off buzzer (interactive)

d. Specification of Bluetooth pin (interactive)

e. MAC address (only displayed)

f. Identification (only displayed)

g. Serial number (automatic)

h. Firmware version (only displayed)

i. Use cellular phone as gateway (interactive)

j. Cellular bridge phone number (interactive)

AMBIENT HEALTHCARE SYSTEMS - Using the Hydra Embedded Middleware for Implementing an Ambient Disease

Management System

Application configuration:

 Context manager: for the definition of

conditions triggering an alert.

 Event manager: for creating events based on

measured data.

Monitoring:

 Network manager: transfer of locally measured

and stored (via proxy) bio-data to background

system.

 Context manager: the monitoring process can

make use of the dynamic networking and

discovery / semantic resolution mechanisms of

the HYDRA middleware. Through the context

manager we can take into account varying user

contexts (like ‘on the move’, ‘at work’ or ‘at

home’) which require to dynamically connect

the measuring equipment with other devices.

Data management and analysis:

 Network manager: used to exchange bio-

medical data between application server and

proxy (e.g., uploading analysis results).

On the other hand, the proxy calls the application

server for registering itself with the application and

upon finishing the device discovery. This is done

during the configuration phase of the measuring

environment. During the configuration phase the

sensor (e.g. blood pressure measuring device) can

also be switched to use a mobile phone in its

proximity as a gateway for transferring the medical

records. In the normal (sensing) mode the

application offers a service for storing measured

values.

5 SYSTEM USAGE

5.1 Application Pre-configuration

In order to simplify the configuration on the end-

user site as much as possible, prior to configuring

and using the environment some administrative tasks

have to be carried out:

 A user has to be created comprising a unique

User ID. In practical deployment of the scenario

this would be done and administrated by a

health care operator.

 The device application for measuring the blood

pressure is adapted to the user by embedding the

User ID into the device application. Since the

device application is unique, an association

between device application and user (through

User ID) can be maintained. The personalized

device application can be shipped either as CD,

memory stick or offered as a downloadable

software package via a portal.

5.2 Device Configuration

For the initial setup of the measuring environment,

the patient uses a controlling (mobile) device that

runs the user application provided by the web

application server. The following steps are executed:

 Through the GUI of the blood pressure

measuring application running on the

controlling device, the user is advised to unwrap

the delivery containing the bpm.

 The user is asked to ensure that the device

application is properly installed and running on

the proxy device. Moreover, the Bluetooth

interface should be activated.

 The blood pressure measuring application asks

the user to provide an activation code that

comes with the package. A user might have to

deal with several sensors and thus device

applications. This unique code identifies the

actual measuring process and is thus linked with

the User ID and the application running on the

proxy device.

Depending on the provided code, some basic

information on the bpm device is provided like

for instance maintenance information or how to

use the device or to what types of devices it can

be connected (e.g., cell phone type)

 In this configuration mode, the user is advised

to switch on the bpm.

 Based on the provided activation code, a session

is opened. The user is informed that a Hydra

Wireless Device Discovery is started on the

proxy device. The discovery results are passed

from the proxy device application back to the

web application server. During the discovery

process the user application is suspended for

some time.

 The discovery results are presented in the user

application. As the ordinary outcome of the

discovery it will be shown that the bpm has

been found. The user is asked to confirm the

discovery result and permit the configuration of

the device (‘pushing the O/I button for longer

then 5 seconds’). Because the bpm is usually in

master mode, it advises the user to put it into

HEALTHINF 2009 - International Conference on Health Informatics

slave mode so that it can be properly

configured.

Finally, the sensor is put into master mode

again.

 After editing the according forms and storing

the list of attributes on the portal, the

configuration data is uploaded to the bpm via

the Bluetooth link. The configuration settings

are translated into a proprietary binary protocol

offered by the bpm.

5.3 Measuring Process and Data

Provisioning

On demand, the patient attaches the bpm to his

upper arm and activates the device. The bpm, while

being in master mode, measures the patient’s

systolic and diastolic blood pressure (including the

pulse) values and transfers them together with the

meta-data (timestamp, sensor ID, etc.) to the

application server via the gateway. By analysing the

user context (i.e., being ‘on the move’ or ‘at home),

the gateway is automatically determined. This can

be done implicitly, because if the stationary home

gateway is not available the mobile phone is used.

The application server offers a service for storing

health records together with a user ID.

When transmitting via the PC-based gateway,

the Network Manager is used to send the patient

records to the application server. When using the

mobile phone, the bpm triggers the mobile phone via

AT commands over the Bluetooth interface. The

mobile phone then sends an SMS to a cellular

network interface attached to the application server

where the message is unpacked, and the service

storing the health record is supplied with the

according information.

6 CONCLUSIONS

Triggered by the shift from reactive and

interventional healthcare towards prevention,

systems supporting ambulatory monitoring and

treatment of people suffering from long term

diseases are gaining increased interest. Wireless

sensors in clothing, shoes etc. yielding bio data will

leverage possibilities for mashing up entertainment

and supervised self-care. This will eventually

become part of everyday life (Lin 2006). We have

discussed some issues arising from the functional

(e.g. interoperability) and non-functional (e.g. cost-

efficiency) demands for such systems. Through

Hydra we can devise solutions that thanks to the

modular approach help to address these demands. In

fact, Hydra permits to develop cost-efficient web-

service enabled pervasive devices, such as bio-

sensors by automating the process of generating

lower level software constituents dealing e.g. with

device discovery, communication management

through the use of the built-in Hydra managers. The

three layer approach in the middleware ensures

structured application design and future extensions

(through additional managers).

Future iterations concerning the use of Hydra in

the health care domain, as well in other domains

(building automation and agriculture), will yield

indicators on the effectiveness of the approach. It

will turn out if Hydra can be established as a

platform for Health Care ecosystems integrating

foundation as well as third party services.

ACKNOWLEDGEMENTS

This work is supported by the EU IST FP6 HYDRA

project (IST-2005-034891).

REFERENCES

A. Arcelus, R. Goubran, M. H. Jones, F. Knoefel,

“Integration of Smart Home Technologies in a Health

Monitoring System for the Elderly”, in 21st

International Conference on Advanced Information

Networking and Applications Workshop, IEEE, 2007.

C. R. Baker et al, “Wireless Sensor Networks for Home

Health Care”, 21st International Conference on

Advanced Information Networking and Applications

Workshops (AINAW'07), IEEE 2007.

United Nations (UN) Secretariat, Long Range World

Population Projections, the Department of Economic

and SocialAffairs, 1998.

German Federal Ministry of Education and Research

(BMBF), Information: AAL- Ambient Assisted Living

(German), web site: http://www.aal-

deutschland.de/marktpotenziale, last viewed: June 27

2008.

J. J. Lin, L. Mamykina, S. Lindtner, G. Delajoux, H. B.

Strub, “Fish'n'Steps: Encouraging Physical Activity

with an Interactive Computer Game”, Lecture Notes

in Computer Science, No. 4206, pages 261-278, 2006.

J. A. Stankovic, Q. Cao, T. Doan, L. Fang, Z. He, R.

Kiran, S. Lin, S. Son, R. Stoleru, A. Wood, "Wireless

Sensor Networks for In-Home Healthcare: Potential

and Challenges", In Proceedings of Workshop on High

Confidence Medical Devices Software and Systems

(HCMDSS), 2005.

uPNP, http://www.upnp.org, last viewed July 13 2008

S. Weerawarana, F. Curbera; F. Leymann: Web Services

Platform Architecture. Prentice Hall PTR, Upper

Saddle River/NJ 2005.

AMBIENT HEALTHCARE SYSTEMS - Using the Hydra Embedded Middleware for Implementing an Ambient Disease

Management System