interoperability in ambient assisted living (aal ... · and software-architectures. the iso/ieee...

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

Philipp Nieke, Sten Hanke, Christopher Mayer, Andreas HochgattererAIT Austrian Institut of Technology GmbH, Biomedical Systems, Viktor Kaplan Strasse 2, A-2700 Wiener Neustadt, Austria

Stefan SauermannUniversity of Applied Sciences Technikum Vienna, Biomedical Engineering, Hochstadtplatz 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 isolatedand 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 communicationand 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 inAAL. The scope is to establish a common software-architecture and communication between agents (any formof 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 itis possible to apply the standard to existing sensor-networks by designing the agent with appropriate mappingmethods between manufacturer- and ISO/IEEE 11073 nomenclature. The flexible bodywork of the designedagent allows its application and use for specific sensor networks from different manufacturers without greateffort, whereas the ”once-implemented manager” can be applied for any ISO/IEEE 11073-10471 IndependentLiving Activity Hub.

1 INTRODUCTION

According to a study (Bundesministerium fur Bildungund Forschung, 2009) about demographic change,Germany will have one of the oldest populations inthe world by the year 2035. To prevent a sharp in-crease of social costs, products and new technologieshave 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. AmbientAssisted Living Technologies try to follow this ob-jective in integrating intelligent assistance-systems inpeoples’ houses and flats. Modern sensor-techniquesand IT-based evaluation of data, allowing the genera-tion of behaviour pattern recognition, should supportthe safety of the inhabitants. In other words, currentsensor-events are compared with predefined patternsand 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 shouldbe used right from the beginning. So far mostly pro-prietary sensor systems are on the market, which aretailored to respective environments, user groups anduse cases. The ISO/IEEE 11073 standard family formedical device communication aim at supporting thedevelopment of interoperable systems in the field ofAAL. This study shows the relevance and benefits ofthe ISO/IEE 11073 for AAL-projects and in general.Moreover it shows how the standard can be imple-mented for existing sensor networks from differentvendors that do not follow the standard guidelines onthe part of the manufacturer.

406Nieke 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-413DOI: 10.5220/0002700204060413Copyright c© SciTePress

2 ISO/IEEE 11073 STANDARDFAMILY

The ISO/IEEE 11073 standard represents a standardfor health informatics in the field of personal healthdevice communication with the focus on establishinginteroperability.

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 (anyform 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-specific data about a per-son or the environment and transfer the informa-tion to the manager for data collection, displaying orfurther analysis. The information is available froma range of domains including disease management,health and fitness or ageing independently applica-tions (IEEE Engineering in Medicine and Biology So-ciety, 2008b).

The ISO/IEEE 11073 standards define both thebodywork of the agents and the communication-procedure between agent and manager. The individ-ual agents are represented in specific device special-izations (ISO/IEEE 11073-104xx, i.e. IndependentLiving Activity Hub, Weighing scale, Thermometer,Cardiovascular fitness and activity monitor), whereasthe ISO/IEEE 11073-20601 presents the basic frame-work and communication for all agents. Generallythe standard is applied on layer 7 of the ISO/OSI ref-erence model and can be utilised independently of themedium of transmission.

The ISO/IEEE 11073-20601 ”Application Profile- Optimized Exchange Protocol” defines a commonframework for an optimized exchange protocol as ba-sis for all ISO/IEEE 11073 standards. It describes anabstract model for the bodywork of agents and con-stitutes a common communication procedure betweenagents and managers. So the purpose of the optimizedexchange protocol is to provide the basis for support-ing any type of agent.

The ISO/IEEE 11073-10471 ”Independent LivingActivity Hub” represents the relevant device special-isation for the integration of smart home sensors inAAL-projects. Based on the Optimized ExchangeProtocol this standard establishes a normative defi-nition of the bodywork and communication betweenindependent living activity hubs and managers in amanner that enables plug-and-play interoperability.In this context, independent living activity hubs are

defined as devices that communicate with simple situ-ation monitors (binary sensors), standardise informa-tion received from the sensors and provide these datato 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 RemarkFall sensor Detects a person’s fallPERS (Personal Emer-gency Response Sys-tem) sensor

Detects when a ”panicbutton” is activated

Environmental sensors(e.g. smoke-, CO-sensors)

Detects any environ-mental aspect andgenerates a sensorevent, if measurementis beyond a certainthreshold

Motion sensor Generates a sensorevent, whenever it hassensed movement

Property exit sensor Generates a sensorevent, whenever ithas sensed the exit ofan occupant from thefamiliar environment(e.g. used for cognitiveissues)

Enuresis sensor Generates a sensorevent when involuntaryurination or bed-wettingis recognized

Usage sensor Generates a sensorevent at the start of useas well as at the end ofuse

Switch sensor Generates a sensorevent when recog-nizing a ”ON”- or a”OFF”-state

Simple medicationdispenser

Generates a sensorevent when a dosageof medication has beentaken or not within acertain time-period

Temperature sensor Generates a sensorevent when temperaturehas risen above ordropped below a certainlevel

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

407

3 MOTIVATION AND BENEFITSOF USING A STANDARD INAAL

The main-objective of applying a standard in IT-infrastructure with special regard to medical devicesis interoperability. According to IEEE (IEEE-USA,2005), interoperability in healthcare does not onlymean that healthcare systems must be able to com-municate with one another, but also that they mustemploy shared terminology and definitions. Imple-mented systems should communicate in a way thatsystems ”understand” each other and thus prevent theloss of information and allow the correct interpre-tation and evaluation of transmitted data. StandardCommittees, like the International Standards Orga-nization (ISO), provide standards to avoid isolatedapplications with their own communication structureand terminology.

The ISO/IEEE 11073 standards define a commoncore of communication functionality for medical andpersonal health devices and specify the use of termcodes, formats and behaviours in a telehealth environ-ment to favour plug & play interoperability (McCabe,2007).

By establishing plug & play interoperability inAAL, new sensor-network solutions can be added toan existing manager without great effort. A standard-ised architecture and communication structure of boththe manager and the sensor-network solution, whichrepresents the agent, are prerequisites. As the com-munication flow always follows the same procedureand transmitted data have the same bodywork, onemanager can be applied to more standard-conformagents. So the manager always receives data inthe same format. As in AAL-technologies differentsensor-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 commonstandard would close this gap and would enable plug& play interoperability of different sensor networksor single sensors.

Furthermore a standardised format would be agreat advantage in AAL technologies for the im-plementation of behaviour pattern recognition algo-rithms and sensor data fusion.

Different Associations make an effort to spreadand refine the standards. In case of the ISO/IEEE11073 standards the Continua Health Alliance is lead-ing. It is a group of technology, healthcare and fitnesscompanies 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 canbe certified by the Continua Health Alliance.

4 APPLICATION OF ISO/IEEE11073 TO AAL

Generally, the ISO/IEEE 11073-20601 architectureconsists of three models (parts), which interact witheach 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 formof information objects that are accessed using objectaccess services (IEEE Engineering in Medicine andBiology Society, 2008b).

4.1 Domain Information Model

The Domain Information Model (DIM) defines thebodywork 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 DIMdescribes a hierarchical structure that represents alldata an agent-device can communicate to a manager.

For the application of the Independent LivingActivity Hub following classes of the ISO/IEEE11073-20601 have to be implemented:

Medical Device System (MDS). Each Agent isrepresented by exactly one MDS-object. Its attributesdefine product-specific information, as well as theconfiguration of the agent and is primarily necessaryfor the identification of the agent at the manager.Moreover the MDS-class defines methods (services,events) for the data-access.

Metric Class. The metric class is the base class fornumeric-, realtime-sa (sample array) and enumera-tion class, which represent the measurement-objects(Numeric, RealTime-SA and Enumeration).

Enumeration Class. An instance of the enumerationclass represents status information (e.g. from a sen-sor), which is reported within an event report service.According to the specification 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-architecturewith its specific attributes has to be implemented.Each attribute of these classes has its own nomencla-ture and a specific data-type, represented in AbstractSyntax Notation 1 (ASN.1), which is described in de-tail in section 5. The nomenclature-definitions andnomenclature-codes (32-bit identifier) can be foundeither in ISO/IEEE 11073-20601, - 10101 or in therelevant device specialization. In table 2 one can seethe attribute name to the ASN.1 notation mapping ofthe MDS class. For better understanding of the class-structure the example in table 3 shows an instancedobject of the MDS-class. The tables for the Metricand the Enumeration class are similar.

4.2 Communication Model

The communication model describes thecommunication-procedure between agent andmanager through state-machines. The communi-cation is realised with certain services (associationservices, object access services) that are supported byboth the agent and the manager. These services arespecified in the service model of the ISO/IEEE 11073standard.

4.3 Service Model

The service model describes in which way data areexchanged between agent and manager.

Association services control associations betweenagent and manager and are applied at the beginningand at the end of each communication-procedure.Therefore the following subtypes of association ser-vices are defined 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, defined in theDomain Information Model. These services arenecessary for both the configuration (registration) ofnew sensor networks (agents) at the manager and forthe transmission of sensor-events from the agent tothe manager. Therefore a configuration event reportand an agent initiated measurement transmissionevent report are defined for the Independent LivingActivity Hub.

Configuration Event Report. The Configurationevent report is used by the agent, when the deviceis in a communication-state with the manager forthe first time. The configuration of the agent isrepresented by a unique ID (Dev-Configuration ID)within the association request. If the manager doesnot know the configuration ID and therefore thedevice, a configuration event report is generated. Inthat service the agent transfers its configuration withall supported attributes to the manager. Static valuesof the object-attributes are also reported in the config-uration event report, as they remain unchanged. Afterthis procedure the manager knows about the devicespecialisation and no configuration event is necessaryany more unless for instance a new sensor is added.In this case, the agent has to send a new configurationevent report to the manager for the registration of thenew sensor. Therefore, agents can have more thanone configuration ID. Dynamic values, such as mea-surements are sent in later measurement event reports.

Agent- and Manager Initiated MeasurementTransmission Event Report. An agent-initiatedmeasurement transmission is sent by the agent, whenthe device has registered a sensor-event or has takena measurement. Only dynamic values are reported inthis service as static values are already known by themanager from the configuration event report.

5 THE COMMUNICATION FLOWAS A SET OF BYTE-STREAMS

In the ISO/IEEE 11073 standard family the AbstractSyntax 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 defining data structures and messages. Thegreat advantage of this notation is that it can be usedplatform-, provider- and application-independentlyfor the transfer of protocol-messages. Especiallytoday, when software developers face the problemof interaction among a multitude of heterogeneouscomputer-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 highlevel of abstraction and thus separates the specifica-tion of data and how these data will be implementedin a particular language, like Java or C. So the de-sign principle of abstraction is an important key ofsoftware development and the focus of using ASN.1(Kaliska, 1993).


409

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

Attribute name Attribute type (defined in AbstractSyntax Notation -ASN.1)

Remark

Handle Handle Object identifierSystem Model SystemModel Number of manufacturer and modelSystem ID OCTETSTRING Organizationally Unique Identifier (OUI; registration

from IEEE) + manufacturer-defined IDDev-Configuration ID ConfigId See 4.3.2 Object Access ServicesDate and Time AbsoluteTimeAttribute-Value-Map AttrValMap Defines the attributes reported in the measurement

transmission event report; dynamic valuesSystem-Type-Spec-List

TypeVerList Defines the type of the agent according to the devicespecialization

Standard committees like the International Stan-dards Organization (ISO) and the InternationalTelecommunication Union Telecommunication Stan-dardization Sector (ITU-T) use ASN.1 for their stan-dard specifications (Hoss and Weyland, 2007).

For the messaging there are several coding rules,for instance Basic Encoding Rules (BER), MedicalDevice Encoding Rules (MDER), or Packed Encod-ing Rules (PER), which support encoding of ASN.1syntax to a byte-stream and the vice-versa processof decoding. For each simple as well as structuredASN.1 data type there is a defined coding rule. Thisaspect is very relevant as far as the prevention ofloss of information and the right interpretation of databy the receiver is concerned (IEEE Engineering inMedicine and Biology Society, 2008b).

The availability of different ASN.1 compilers sup-ports the transfer of ASN.1 definitions into the spe-cific programming language, considering the partic-ular coding rules. For the implementation of theISO/IEEE 11073 standard in this study, an opensource ASN.1 to Java compiler has been used. Withthe help of that compiler predefined ASN.1 data-typesof the standard can be transformed into classes ofobject-oriented programming language. Additionallyeach 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 Javadue to its object-oriented approach. The first stepfor standard-conform implementation is to designan ISO-Agent, according to the Domain Informa-tion Model (DIM) of the Independent Living ActivityHub (see 4.1). The ISO-Agent is a prerequisite forthe implementation of the ISO/IEEE 11073-conformcommunication-flow with the manager.

For the application of the standard, nomencla-ture definitions with their specific nomenclature codesaccording to ISO/IEEE 11073-20601, -10471 and-10101 and ASN.1 data-type definitions have tobe used. Therefore a separate class with all re-quired IEEE-nomenclature definitions has been im-plemented. These codes and definitions are necessaryto set attributes correctly in the particular instancedobjects. Furthermore all required ASN.1 data-typedefinitions (a total of 73) have to be translated withthe help of the ASN.1/Java compiler into Java-classes.Whenever one of these definitions is applied, a newobject 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 beenimplemented 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 classesMDS, Metric and Enumeration are required. Ad-ditionally, required mapping-methods between spe-cific 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 predefined data areintegrated within a configuration class. This classincludes agent-specific definitions for the DomainInformation Model (MDS-, Metric-, Enumeration-class) and for the messages. Another important ele-ment of this configuration class is the storage of theconfiguration IDs. Each sensor-object is assigned aunique configuration ID. These IDs are representedwithin a hash table. On the basis of the object identi-fier (Handle attribute) of each sensor-object, the keysof the hash table are established. In other words, eachvalue of the Handle attribute (representing a sensor)is assigned a configuration ID. The configuration IDis necessary to set up communication with the man-


410

Table 3: Example of instanced objects of MDS class.

MDS-ObjectAttribute name Attribute value RemarkHandle 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

specific values from the manufac-turer;

These numbers are specific values from the manufac-turer

System ID• OUI: xxxxx;• Manufacturer-defined ID:

xxxxxxxxx;

The OUI is the registration ID from IEEE. Themanufacturer-defined ID represents the System-ID ofthe manufacturer.

Dev-Configuration ID 16384 According to ASN.1 definition of ConfigId, the value16384 represents the first value provided for ”ex-tended configuration”

Date and Time 21-2009-3-11 13:22:26:885 According to ASN.1 definition of AbsoluteTime, dateand time are presented in this format

Attribute-Value-Map• OID: 2448, length: 4;• OID: 2881, length: 4;

According to ASN.1 definitions of AttrValMap, thisattribute defines the attributes that are later reportedin the measurement transmission event report. Thevalues are represented with the nomenclature-codes ofthe 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 forthe Independent Living Activity Hub

ager. With the help of public-defined ”get-methods”,static information can be obtained in other classes.Attributes, containing dynamic data, always have tobe instanced in the particular class.

The ISO-Agent Listener class can be seen as thecore element of the generated software. Wheneverthe ISO Agent Listener recognises a data-packet fromthe sensor network, it has to generate an ISO/IEEE11073 conform data-packet. These packets are rep-resented as instances of the Enumeration class. Fig-ure 1 shows a simplified use case of the ISO AgentListener. For each supported sensor network systemfrom specific vendors an own listener has to be im-plemented. The ISO Agent Listener is the lynchpinfor the communication procedure. Each capture ofa sensor data-packet and creation of an enumeration-object has to be followed by an association request.The association request is always the first message inthe communication-flow between agent and manager.Figure 2 summarises the duties of the ISO Agent Lis-tener.

The manager is also realised with a configurationclass 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 configuration class, the manager configurationhas a hash table where familiar configurations IDs ofthe agent are stored (Note: the agent can have morethan one configuration ID). Whenever the agent startsthe communication with the manager, an associationrequest is sent. Within this message the configura-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


411

receive data packet from sensor

receive messages from

create new enumeration object

receive messages from manager

ISO Agent Listener

object

send association requestISO Agent Listener send association request

send configuration event report

send measurement

d lsend association release request

Figure 2: Duties of the ISO Agent Listener.

cases, whether the configuration ID is already familiaror not, is necessary. If the manager knows the config-uration ID, the agent can continue with the measure-ment transmission event report; otherwise, the agenthas to send a configuration event report.

Generally an objective has been to design an ar-chitecture that is as flexible as possible. Thus, newsensors and their appropriate mapping methods canbe integrated without great effort. The implementedISO-Agent represents its own sensor-network. Spe-cific data of the system have been implemented in aparticular configuration class. This approach is thebasis for further integration of other sensor-networksolutions and underline the flexible expandability.Therefore the implementation of a new configura-tion class and modification of the mapping methodsshould be the only job of a software engineer for in-tegrating new sensor networks that are not designedaccording to ISO/IEEE 11073 guidelines right fromthe beginning (from the manufacturer). The managerand communication methods, however, can also beapplied for other sensor-network solutions from othermanufacturers without changing its bodywork. Thispoint represents exactly the objective of using thisstandard, namely interoperability. The possibility ofcommunicating with more than one agent is the keyfor 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 howto integrate the ISO/IEEE 11073-10471 standard in asmart home setup with different smart home sensorsfrom different vendors. The usage of interoperabil-ity standards in the AAL context is more and more

essential as it is necessary for open and flexible plat-forms which are the basis to bring AAL applicationsto a larger market. Interoperable middelware compo-nents in AAL would also save money concerning theapplication implementation effort as it is reusable, notproprietary and not constraint to modules and sensorsfrom a special technology provider or a certain appli-cation setup.

The integration of interoperability standards inAAL is a highly new field concerning the eHealthenvironment 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 theISO/IEEE 11073-10471 in applications in differentprojects with different sensors and already see thebenefit by developing modules which make the appli-cation independent from different kind of sensors andsensor data protocols. Anyway we have experiencedsome missing data fields and descriptions because ofthe different protocols of certain sensors from differ-ent manufacturers.

It will be a progress to bring the experiences intothe development of the standards and the standarddocuments to work on a widespread usage of stan-dards of interoperability.

ACKNOWLEDGEMENTS

This research was accomplished within the contextof the project ”Know-how und Kompetenz-Aufbauim Bereich Smart Homes fur sicheres und energieef-fizientes Wohnen” intitiated by the AIT Austrian In-stitute of Technology GmbH - Biomedical Systems.This research was partly funded by the AIT AustrianInstitute of Technology GmbH and the Federal Re-public of Lower Austria and cofinanced by the EC(EFRE).

REFERENCES

Bundesministerium fur Bildung und Forschung (2009). InAAL - Ambient Assisted Living in Deutschland. Bun-desministerium fur 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: Entwicklungund Evaluation eines ASN.1-Compilers und PER-Codes unter Java. diploma thesis, TU Darmstadt. [on-


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. diplomathesis, TU Darmstadt. [online] Available from:http://www.openasn1.de/ [Accessed: February 28th,2009].

IEEE Engineering in Medicine and Biology Society(2008b). Health informatics - Personal healthdevice communication, Part 20601: Applicationprofile - Optimized Exchange Protocol. diplomathesis, TU Darmstadt. [online] Available from:http://www.openasn1.de/ [Accessed: February 28th,2009].

IEEE-USA (2005). Interoperability for the national healthinformation 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].


413

interoperability in ambient assisted living (aal ... · and software-architectures. the iso/ieee...

Documents