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.
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
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
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
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
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
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
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
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
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
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
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-
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
Applicat io n
Health Record
Data Store
deploy /
access user
- start discovery
- connect sensor
- configure sensor
- send discovered sensors
- transmit health records
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.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
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
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.
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.
Network manager: transfer of locally measured
and stored (via proxy) bio-data to background
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
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
Finally, the sensor is put into master mode
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
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.
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.
This work is supported by the EU IST FP6 HYDRA
project (IST-2005-034891).
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-, last viewed: June 27
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,, 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