INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL)

Standardization of Sensor-data based on ISO/IEEE 11073

Philipp Nieke, Sten Hanke, Christopher Mayer, Andreas Hochgatterer

AIT Austrian Institut of Technology GmbH, Biomedical Systems, Viktor Kaplan Strasse 2, A-2700 Wiener Neustadt, Austria

Stefan Sauermann

University of Applied Sciences Technikum Vienna, Biomedical Engineering, H

ochst

adtplatz 5, A-1200 Vienna, Austria

Keywords:

Ambient Assisted Living, AAL, ISO/IEEE 11073, Interoperability, Standardization.

Abstract:

In the process of developing projects in Ambient Assisted Living (AAL), it is very important to avoid isolated

and proprietary applications in the Information Technology (IT) infrastructure. Therefore standardization com-

mittees try to close the gap between these applications in developing appropriate standards for communication

and software-architectures. The ISO/IEEE 11073 standard family and especially the standard specialization

”ISO/IEEE 11073-10471, Independent Living Activity Hub” is the key for establishing interoperability in

AAL. The scope is to establish a common software-architecture and communication between agents (any form

of medical devices, e.g. Independent Living Activity Hub which represents a sensor network) and managers

(software-tool for receiving data; e.g. sensor-data). Consequently the integration of different sensor-networks

(agents) from different manufacturers to an ISO/IEEE 11073 manager could be achieved by plug & play inter-

operability if the agents are built up according to the standard guidelines. However, this study showed that it

is possible to apply the standard to existing sensor-networks by designing the agent with appropriate mapping

methods between manufacturer- and ISO/IEEE 11073 nomenclature. The ﬂexible bodywork of the designed

agent allows its application and use for speciﬁc sensor networks from different manufacturers without great

effort, whereas the ”once-implemented manager” can be applied for any ISO/IEEE 11073-10471 Independent

Living Activity Hub.

1 INTRODUCTION

According to a study (Bundesministerium f

ur Bildung

und Forschung, 2009) about demographic change,

Germany will have one of the oldest populations in

the world by the year 2035. To prevent a sharp in-

crease of social costs, products and new technologies

have to be developed now. One approach is the pos-

sibility of enabling older people to have an indepen-

dent life in their homes as long as possible. Ambient

Assisted Living Technologies try to follow this ob-

jective in integrating intelligent assistance-systems in

peoples’ houses and ﬂats. Modern sensor-techniques

and IT-based evaluation of data, allowing the genera-

tion of behaviour pattern recognition, should support

the safety of the inhabitants. In other words, current

sensor-events are compared with predeﬁned patterns

and if the situation differs from normality an alarm

will be triggered by the AAL-system.

In order to avoid isolated applications in this

potential sector, international standards in IT-

infrastructure and communication procedures should

be used right from the beginning. So far mostly pro-

prietary sensor systems are on the market, which are

tailored to respective environments, user groups and

use cases. The ISO/IEEE 11073 standard family for

medical device communication aim at supporting the

development of interoperable systems in the ﬁeld of

AAL. This study shows the relevance and beneﬁts of

the ISO/IEE 11073 for AAL-projects and in general.

Moreover it shows how the standard can be imple-

mented for existing sensor networks from different

vendors that do not follow the standard guidelines on

the part of the manufacturer.

406

Nieke P., Hanke S., Mayer C., Hochgatterer A. and Sauermann S. (2010).

INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL) - Standardization of Sensor-data based on ISO/IEEE 11073.

In Proceedings of the Third International Conference on Health Informatics, pages 406-413

DOI: 10.5220/0002700204060413

 SciTePress

2 ISO/IEEE 11073 STANDARD

FAMILY

The ISO/IEEE 11073 standard represents a standard

for health informatics in the ﬁeld of personal health

device communication with the focus on establishing

interoperability.

It has no special system requirements and there-

fore is not associated with nor limited to special hard-

ware or software technologies or other protocols (Mc-

Cabe, 2007).

The scope is to establish a common software-

architecture and communication between agents (any

form of medical devices or sensor systems) and man-

agers (for instance personal computers) without fo-

cusing on the transport layer. Agents are collect-

ing medical or behaviour-speciﬁc data about a per-

son or the environment and transfer the informa-

tion to the manager for data collection, displaying or

further analysis. The information is available from

a range of domains including disease management,

health and ﬁtness or ageing independently applica-

tions (IEEE Engineering in Medicine and Biology So-

ciety, 2008b).

The ISO/IEEE 11073 standards deﬁne both the

bodywork of the agents and the communication-

procedure between agent and manager. The individ-

ual agents are represented in speciﬁc device special-

izations (ISO/IEEE 11073-104xx, i.e. Independent

Living Activity Hub, Weighing scale, Thermometer,

Cardiovascular ﬁtness and activity monitor), whereas

the ISO/IEEE 11073-20601 presents the basic frame-

work and communication for all agents. Generally

the standard is applied on layer 7 of the ISO/OSI ref-

erence model and can be utilised independently of the

medium of transmission.

The ISO/IEEE 11073-20601 ”Application Proﬁle

- Optimized Exchange Protocol” deﬁnes a common

framework for an optimized exchange protocol as ba-

sis for all ISO/IEEE 11073 standards. It describes an

abstract model for the bodywork of agents and con-

stitutes a common communication procedure between

agents and managers. So the purpose of the optimized

exchange protocol is to provide the basis for support-

ing any type of agent.

The ISO/IEEE 11073-10471 ”Independent Living

Activity Hub” represents the relevant device special-

isation for the integration of smart home sensors in

AAL-projects. Based on the Optimized Exchange

Protocol this standard establishes a normative deﬁ-

nition of the bodywork and communication between

independent living activity hubs and managers in a

manner that enables plug-and-play interoperability.

In this context, independent living activity hubs are

deﬁned as devices that communicate with simple situ-

ation monitors (binary sensors), standardise informa-

tion received from the sensors and provide these data

to a manager (IEEE Engineering in Medicine and Bi-

ology Society, 2008a). Until now, this device special-

ization support the terminology of 10 sensor-types,

which are shortly described in table 1.

Table 1: Supported sensors by ISO/IEEE 11073-10471

(IEEE Engineering in Medicine and Biology Society,

2008a).

Sensor-type Remark

Fall sensor Detects a person’s fall

PERS (Personal Emer-

gency Response Sys-

tem) sensor

Detects when a ”panic

button” is activated

Environmental sensors

(e.g. smoke-, CO-

sensors)

Detects any environ-

mental aspect and

generates a sensor

event, if measurement

is beyond a certain

threshold

Motion sensor Generates a sensor

event, whenever it has

sensed movement

Property exit sensor Generates a sensor

event, whenever it

has sensed the exit of

an occupant from the

familiar environment

(e.g. used for cognitive

issues)

Enuresis sensor Generates a sensor

event when involuntary

urination or bed-wetting

is recognized

Usage sensor Generates a sensor

event at the start of use

as well as at the end of

use

Switch sensor Generates a sensor

event when recog-

nizing a ”ON”- or a

”OFF”-state

Simple medication

dispenser

Generates a sensor

event when a dosage

of medication has been

taken or not within a

certain time-period

Temperature sensor Generates a sensor

event when temperature

has risen above or

dropped below a certain

level

INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL) - Standardization of Sensor-data based on ISO/IEEE

11073

407

3 MOTIVATION AND BENEFITS

OF USING A STANDARD IN

AAL

The main-objective of applying a standard in IT-

infrastructure with special regard to medical devices

is interoperability. According to IEEE (IEEE-USA,

2005), interoperability in healthcare does not only

mean that healthcare systems must be able to com-

municate with one another, but also that they must

employ shared terminology and deﬁnitions. Imple-

mented systems should communicate in a way that

systems ”understand” each other and thus prevent the

loss of information and allow the correct interpre-

tation and evaluation of transmitted data. Standard

Committees, like the International Standards Orga-

nization (ISO), provide standards to avoid isolated

applications with their own communication structure

and terminology.

The ISO/IEEE 11073 standards deﬁne a common

core of communication functionality for medical and

personal health devices and specify the use of term

codes, formats and behaviours in a telehealth environ-

ment to favour plug & play interoperability (McCabe,

2007).

By establishing plug & play interoperability in

AAL, new sensor-network solutions can be added to

an existing manager without great effort. A standard-

ised architecture and communication structure of both

the manager and the sensor-network solution, which

represents the agent, are prerequisites. As the com-

munication ﬂow always follows the same procedure

and transmitted data have the same bodywork, one

manager can be applied to more standard-conform

agents. So the manager always receives data in

the same format. As in AAL-technologies different

sensor-types (see table 1) are useful, which are of-

ten not provided by one manufacturer, different data-

formats have to be handled by the receiving system,

if the sensors’ communication protocols are not stan-

dard conform. Therefore the application of a common

standard would close this gap and would enable plug

& play interoperability of different sensor networks

or single sensors.

Furthermore a standardised format would be a

great advantage in AAL technologies for the im-

plementation of behaviour pattern recognition algo-

rithms and sensor data fusion.

Different Associations make an effort to spread

and reﬁne the standards. In case of the ISO/IEEE

11073 standards the Continua Health Alliance is lead-

ing. It is a group of technology, healthcare and ﬁtness

companies dedicated to establishing a system of inter-

operable telehealth solutions. These solutions should

foster the independence of people to better man-

age their health (Continua Health Alliance, 2009).

ISO/IEEE 11073 standardised sensor-networks can

be certiﬁed by the Continua Health Alliance.

4 APPLICATION OF ISO/IEEE

11073 TO AAL

Generally, the ISO/IEEE 11073-20601 architecture

consists of three models (parts), which interact with

each another:

• the Domain Information Model,

• the Communication Model and

• the Service Model.

The ISO/IEEE 11073 family is based on an object-

oriented systems management paradigm. Thus, data

(measurement, state, etc.) are modelled in the form

of information objects that are accessed using object

access services (IEEE Engineering in Medicine and

Biology Society, 2008b).

4.1 Domain Information Model

The Domain Information Model (DIM) deﬁnes the

bodywork of an agent as a set of objects. Their at-

tributes describe measurement data as well as ele-

ments that control the behaviour of agents. The DIM

describes a hierarchical structure that represents all

data an agent-device can communicate to a manager.

For the application of the Independent Living

Activity Hub following classes of the ISO/IEEE

11073-20601 have to be implemented:

Medical Device System (MDS). Each Agent is

represented by exactly one MDS-object. Its attributes

deﬁne product-speciﬁc information, as well as the

conﬁguration of the agent and is primarily necessary

for the identiﬁcation of the agent at the manager.

Moreover the MDS-class deﬁnes methods (services,

events) for the data-access.

Metric Class. The metric class is the base class for

numeric-, realtime-sa (sample array) and enumera-

tion class, which represent the measurement-objects

(Numeric, RealTime-SA and Enumeration).

Enumeration Class. An instance of the enumeration

class represents status information (e.g. from a sen-

sor), which is reported within an event report service.

According to the speciﬁcation all measurement-

objects (sensor-event-objects) are instances of the

HEALTHINF 2010 - International Conference on Health Informatics

408

enumeration class.

Considering this bodywork the class-architecture

with its speciﬁc attributes has to be implemented.

Each attribute of these classes has its own nomencla-

ture and a speciﬁc data-type, represented in Abstract

Syntax Notation 1 (ASN.1), which is described in de-

tail in section 5. The nomenclature-deﬁnitions and

nomenclature-codes (32-bit identiﬁer) can be found

either in ISO/IEEE 11073-20601, - 10101 or in the

relevant device specialization. In table 2 one can see

the attribute name to the ASN.1 notation mapping of

the MDS class. For better understanding of the class-

structure the example in table 3 shows an instanced

object of the MDS-class. The tables for the Metric

and the Enumeration class are similar.

4.2 Communication Model

The communication model describes the

communication-procedure between agent and

manager through state-machines. The communi-

cation is realised with certain services (association

services, object access services) that are supported by

both the agent and the manager. These services are

speciﬁed in the service model of the ISO/IEEE 11073

standard.

4.3 Service Model

The service model describes in which way data are

exchanged between agent and manager.

Association services control associations between

agent and manager and are applied at the beginning

and at the end of each communication-procedure.

Therefore the following subtypes of association ser-

vices are deﬁned in the standard:

• Association request

• Association response

• Association release request

• Association release response

Object access services are used to retrieve in-

formation of the instanced objects, deﬁned in the

Domain Information Model. These services are

necessary for both the conﬁguration (registration) of

new sensor networks (agents) at the manager and for

the transmission of sensor-events from the agent to

the manager. Therefore a conﬁguration event report

and an agent initiated measurement transmission

event report are deﬁned for the Independent Living

Activity Hub.

Conﬁguration Event Report. The Conﬁguration

event report is used by the agent, when the device

is in a communication-state with the manager for

the ﬁrst time. The conﬁguration of the agent is

represented by a unique ID (Dev-Conﬁguration ID)

within the association request. If the manager does

not know the conﬁguration ID and therefore the

device, a conﬁguration event report is generated. In

that service the agent transfers its conﬁguration with

all supported attributes to the manager. Static values

of the object-attributes are also reported in the conﬁg-

uration event report, as they remain unchanged. After

this procedure the manager knows about the device

specialisation and no conﬁguration event is necessary

any more unless for instance a new sensor is added.

In this case, the agent has to send a new conﬁguration

event report to the manager for the registration of the

new sensor. Therefore, agents can have more than

one conﬁguration ID. Dynamic values, such as mea-

surements are sent in later measurement event reports.

Agent- and Manager Initiated Measurement

Transmission Event Report. An agent-initiated

measurement transmission is sent by the agent, when

the device has registered a sensor-event or has taken

a measurement. Only dynamic values are reported in

this service as static values are already known by the

manager from the conﬁguration event report.

5 THE COMMUNICATION FLOW

AS A SET OF BYTE-STREAMS

In the ISO/IEEE 11073 standard family the Abstract

Syntax Notation 1 (ASN.1) is used in the Domain In-

formation Model (attribute data-types) and in the ser-

vice model (format of the messages).

The Abstract Syntax Notation is a formal nota-

tion for deﬁning data structures and messages. The

great advantage of this notation is that it can be used

platform-, provider- and application-independently

for the transfer of protocol-messages. Especially

today, when software developers face the problem

of interaction among a multitude of heterogeneous

computer-systems, a common language as well as cer-

tain rules for messaging is necessary (Hoss and Wey-

land, 2007).

ASN.1 describes data structures at a very high

level of abstraction and thus separates the speciﬁca-

tion of data and how these data will be implemented

in a particular language, like Java or C. So the de-

sign principle of abstraction is an important key of

software development and the focus of using ASN.1

(Kaliska, 1993).

INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL) - Standardization of Sensor-data based on ISO/IEEE

11073

409

Table 2: MDS-class of Independent Living Activity Hub -Agent (IEEE Engineering in Medicine and Biology Society, 2008a).

Attribute name Attribute type (deﬁned in Abstract

Syntax Notation -ASN.1)

Remark

Handle Handle Object identiﬁer

System Model SystemModel Number of manufacturer and model

System ID OCTETSTRING Organizationally Unique Identiﬁer (OUI; registration

from IEEE) + manufacturer-deﬁned ID

Dev-Conﬁguration ID ConﬁgId See 4.3.2 Object Access Services

Date and Time AbsoluteTime

Attribute-Value-Map AttrValMap Deﬁnes the attributes reported in the measurement

transmission event report; dynamic values

System-Type-Spec-

List

TypeVerList Deﬁnes the type of the agent according to the device

specialization

Standard committees like the International Stan-

dards Organization (ISO) and the International

Telecommunication Union Telecommunication Stan-

dardization Sector (ITU-T) use ASN.1 for their stan-

dard speciﬁcations (Hoss and Weyland, 2007).

For the messaging there are several coding rules,

for instance Basic Encoding Rules (BER), Medical

Device Encoding Rules (MDER), or Packed Encod-

ing Rules (PER), which support encoding of ASN.1

syntax to a byte-stream and the vice-versa process

of decoding. For each simple as well as structured

ASN.1 data type there is a deﬁned coding rule. This

aspect is very relevant as far as the prevention of

loss of information and the right interpretation of data

by the receiver is concerned (IEEE Engineering in

Medicine and Biology Society, 2008b).

The availability of different ASN.1 compilers sup-

ports the transfer of ASN.1 deﬁnitions into the spe-

ciﬁc programming language, considering the partic-

ular coding rules. For the implementation of the

ISO/IEEE 11073 standard in this study, an open

source ASN.1 to Java compiler has been used. With

the help of that compiler predeﬁned ASN.1 data-types

of the standard can be transformed into classes of

object-oriented programming language. Additionally

each class has been provided with encoding- and de-

coding methods for transforming the instanced ob-

jects into a byte-stream.

6 IMPLEMENTATION

The chosen language for the implementation is Java

due to its object-oriented approach. The ﬁrst step

for standard-conform implementation is to design

an ISO-Agent, according to the Domain Informa-

tion Model (DIM) of the Independent Living Activity

Hub (see 4.1). The ISO-Agent is a prerequisite for

the implementation of the ISO/IEEE 11073-conform

communication-ﬂow with the manager.

For the application of the standard, nomencla-

ture deﬁnitions with their speciﬁc nomenclature codes

according to ISO/IEEE 11073-20601, -10471 and

-10101 and ASN.1 data-type deﬁnitions have to

be used. Therefore a separate class with all re-

quired IEEE-nomenclature deﬁnitions has been im-

plemented. These codes and deﬁnitions are necessary

to set attributes correctly in the particular instanced

objects. Furthermore all required ASN.1 data-type

deﬁnitions (a total of 73) have to be translated with

the help of the ASN.1/Java compiler into Java-classes.

Whenever one of these deﬁnitions is applied, a new

object of the relevant ASN.1 class has to be instanced.

Thus the classes contain constructors as well as meth-

ods for encoding and decoding, required for standard-

conform implementation of the messages.

The general bodywork of the agent has been

implemented according to the ISO/IEEE 11073-

20601 Optimized Exchange Protocol and to the de-

vice specialization ISO/IEEE 11073-10471 Indepen-

dent Living Activity Hub. Therefore the classes

MDS, Metric and Enumeration are required. Ad-

ditionally, required mapping-methods between spe-

ciﬁc manufacturer-nomenclature of the sensor net-

work and ISO/IEEE 11073-nomenclature are inte-

grated in the Enumeration-class.

In order to have a clearly arranged and compre-

hensible bodywork, all static and predeﬁned data are

integrated within a conﬁguration class. This class

includes agent-speciﬁc deﬁnitions for the Domain

Information Model (MDS-, Metric-, Enumeration-

class) and for the messages. Another important ele-

ment of this conﬁguration class is the storage of the

conﬁguration IDs. Each sensor-object is assigned a

unique conﬁguration ID. These IDs are represented

within a hash table. On the basis of the object identi-

ﬁer (Handle attribute) of each sensor-object, the keys

of the hash table are established. In other words, each

value of the Handle attribute (representing a sensor)

is assigned a conﬁguration ID. The conﬁguration ID

is necessary to set up communication with the man-

HEALTHINF 2010 - International Conference on Health Informatics

410

Table 3: Example of instanced objects of MDS class.

MDS-Object

Attribute name Attribute value Remark

Handle 0 Each Agent has exactly one MDS-Object; therefore

the Handle-value should be 0.

System Model Number of

• manufacturer: xxxx;

• model: xxxx These numbers are

speciﬁc values from the manufac-

turer;

These numbers are speciﬁc values from the manufac-

turer

System ID

• OUI: xxxxx;

• Manufacturer-deﬁned ID:

xxxxxxxxx;

The OUI is the registration ID from IEEE. The

manufacturer-deﬁned ID represents the System-ID of

the manufacturer.

Dev-Conﬁguration ID 16384 According to ASN.1 deﬁnition of ConﬁgId, the value

16384 represents the ﬁrst value provided for ”ex-

tended conﬁguration”

Date and Time 21-2009-3-11 13:22:26:885 According to ASN.1 deﬁnition of AbsoluteTime, date

and time are presented in this format

Attribute-Value-Map

• OID: 2448, length: 4;

• OID: 2881, length: 4;

According to ASN.1 deﬁnitions of AttrValMap, this

attribute deﬁnes the attributes that are later reported

in the measurement transmission event report. The

values are represented with the nomenclature-codes of

the standard and their length of bytes.

• OID: 2448 represents Absolute-Time-Stamp;

• OID: 2881 represents Enum-Observed-Value-

Simple-Bit-Str;

System-Type-Spec-

List

OID: 4167 The value 4167 represents the nomenclature-code for

the Independent Living Activity Hub

ager. With the help of public-deﬁned ”get-methods”,

static information can be obtained in other classes.

Attributes, containing dynamic data, always have to

be instanced in the particular class.

The ISO-Agent Listener class can be seen as the

core element of the generated software. Whenever

the ISO Agent Listener recognises a data-packet from

the sensor network, it has to generate an ISO/IEEE

11073 conform data-packet. These packets are rep-

resented as instances of the Enumeration class. Fig-

ure 1 shows a simpliﬁed use case of the ISO Agent

Listener. For each supported sensor network system

from speciﬁc vendors an own listener has to be im-

plemented. The ISO Agent Listener is the lynchpin

for the communication procedure. Each capture of

a sensor data-packet and creation of an enumeration-

object has to be followed by an association request.

The association request is always the ﬁrst message in

the communication-ﬂow between agent and manager.

Figure 2 summarises the duties of the ISO Agent Lis-

tener.

The manager is also realised with a conﬁguration

class where static information is stored. Like the ISO



Sensor-event

Vendor X

data-packet

Sensor network system vendor X

Sensor-event

Vendor Y data-

packet

Sensor network system vendor Y

ISO AGENT

Creating an object of the

Enumeration class with correct

syntax and data-types

ISO Agent Listener X

Setting up the

communication with the ISO

Manager according

Communication Model

ISO Agent Listener Y

Figure 1: Use case of the ISO Agent.

Agent conﬁguration class, the manager conﬁguration

has a hash table where familiar conﬁgurations IDs of

the agent are stored (Note: the agent can have more

than one conﬁguration ID). Whenever the agent starts

the communication with the manager, an association

request is sent. Within this message the conﬁgura-

tion ID of the particular sensor-object is transmitted.

When the manager receives the association request,

the information has to be decoded and a distinction of

INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL) - Standardization of Sensor-data based on ISO/IEEE

11073

411

receivedatapacketfrom

sensor

receive messages from

createnewenumeration

object

receive



messages



from



manager

ISO Agent Listener

object

send association request

ISO



Agent



Listener

send



association



request

sendconfigurationeventreport

sendmeasurement

d l

sen

associationre

ease

request

Figure 2: Duties of the ISO Agent Listener.

cases, whether the conﬁguration ID is already familiar

or not, is necessary. If the manager knows the conﬁg-

uration ID, the agent can continue with the measure-

ment transmission event report; otherwise, the agent

has to send a conﬁguration event report.

Generally an objective has been to design an ar-

chitecture that is as ﬂexible as possible. Thus, new

sensors and their appropriate mapping methods can

be integrated without great effort. The implemented

ISO-Agent represents its own sensor-network. Spe-

ciﬁc data of the system have been implemented in a

particular conﬁguration class. This approach is the

basis for further integration of other sensor-network

solutions and underline the ﬂexible expandability.

Therefore the implementation of a new conﬁgura-

tion class and modiﬁcation of the mapping methods

should be the only job of a software engineer for in-

tegrating new sensor networks that are not designed

according to ISO/IEEE 11073 guidelines right from

the beginning (from the manufacturer). The manager

and communication methods, however, can also be

applied for other sensor-network solutions from other

manufacturers without changing its bodywork. This

point represents exactly the objective of using this

standard, namely interoperability. The possibility of

communicating with more than one agent is the key

for interoperability and an approach to avoid hetero-

geneous IT-infrastructure.

7 CONCLUSIONS

The paper shows that it is possible to apply the stan-

dard to a sensor network that is not designed accord-

ing to any standard guidelines at all. It shows how

to integrate the ISO/IEEE 11073-10471 standard in a

smart home setup with different smart home sensors

from different vendors. The usage of interoperabil-

ity standards in the AAL context is more and more

essential as it is necessary for open and ﬂexible plat-

forms which are the basis to bring AAL applications

to a larger market. Interoperable middelware compo-

nents in AAL would also save money concerning the

application implementation effort as it is reusable, not

proprietary and not constraint to modules and sensors

from a special technology provider or a certain appli-

cation setup.

The integration of interoperability standards in

AAL is a highly new ﬁeld concerning the eHealth

environment respectively the medical bed side treat-

ment, whereas the usage of standards is a more im-

proved effort.

During our work we have tried to implement the

ISO/IEEE 11073-10471 in applications in different

projects with different sensors and already see the

beneﬁt by developing modules which make the appli-

cation independent from different kind of sensors and

sensor data protocols. Anyway we have experienced

some missing data ﬁelds and descriptions because of

the different protocols of certain sensors from differ-

ent manufacturers.

It will be a progress to bring the experiences into

the development of the standards and the standard

documents to work on a widespread usage of stan-

dards of interoperability.

ACKNOWLEDGEMENTS

This research was accomplished within the context

of the project ”Know-how und Kompetenz-Aufbau

im Bereich Smart Homes f

ur sicheres und energieef-

ﬁzientes Wohnen” intitiated by the AIT Austrian In-

stitute of Technology GmbH - Biomedical Systems.

This research was partly funded by the AIT Austrian

Institute of Technology GmbH and the Federal Re-

public of Lower Austria and coﬁnanced by the EC

(EFRE).

REFERENCES

Bundesministerium f

ur Bildung und Forschung (2009). In

AAL - Ambient Assisted Living in Deutschland. Bun-

desministerium f

ur Bildung und Forschung, Avail-

able from: http://www.aal-deutschland.de/aal-1 [Ac-

cessed: march 6th 2009].

Continua Health Alliance (2009). About the Alliance.

Available from: http://www.continuaalliance.org [Ac-

cessed: February 28th, 2009].

Hoss, C. and Weyland, M. (2007). openASN.1: Entwicklung

und Evaluation eines ASN.1-Compilers und PER-

Codes unter Java. diploma thesis, TU Darmstadt. [on-

HEALTHINF 2010 - International Conference on Health Informatics

412

line] Available from: http://www.openasn1.de/ [Ac-

cessed: February 28th, 2009].

IEEE Engineering in Medicine and Biology Society

(2008a). Health informatics - Personal health de-

vice communication, Part 10471: Device special-

ization - Independent living activity hub. diploma

thesis, TU Darmstadt. [online] Available from:

http://www.openasn1.de/ [Accessed: February 28th,

2009].

IEEE Engineering in Medicine and Biology Society

(2008b). Health informatics - Personal health

device communication, Part 20601: Application

proﬁle - Optimized Exchange Protocol. diploma

thesis, TU Darmstadt. [online] Available from:

http://www.openasn1.de/ [Accessed: February 28th,

2009].

IEEE-USA (2005). Interoperability for the national health

information network. Available from: http://www.aal-

deutschland.de/aal-1 [Accessed: march 6th 2009].

Kaliska, B. S. (1993). A Laymans Guide to a Sub-

set of ASN.1, BER and DER. Available from:

http://luca.ntop.org/Teaching/Appunti/asn1.html [Ac-

cessed: February 28th, 2009].

McCabe, K. (2007). IEEE begins work on 10 communica-

tion standards for personal telehealth devices. Avail-

able from: http://standards.ieee.org/announcements/

pr telehealth.html [Accessed: March 9th 2009].

INTEROPERABILITY IN AMBIENT ASSISTED LIVING (AAL) - Standardization of Sensor-data based on ISO/IEEE

11073

413