INTEROPERABILITY IN SMART HOME MIDDLEWARE

The MPOWER Project

Sten Hanke and Thomas Fuxreiter

Austrian Research Centers GmbH – ARC, Biomedical Engineering, Viktor-Kaplan-Straße 2, Vienna, Austria

Keywords: Smart home, sensor applications, interoperability, middleware, MPOWER, interfaces, standards, service-

oriented architecture, web services.

Abstract: The paper describes the use of interoperability standards and interoperability frameworks in a smart / sensor

home project. During the EU funded project MPOWER an open middleware platform will be developed

which should speed up the task of developing and deploying services for persons with cognitive disabilities

and elderly. The developed middleware has different interfaces where interoperability standards are

required. The paper points out these requirements and presents solutions in the different layers of the

Service-Oriented Architecture approach. In future, standards and defined interfaces are more and more

needed because of the need for a secure and easy data and messaging transfer. The middleware will be

developed non-proprietary and is open for different applications and sensor integration.

1 INTRODUCTION

Interoperability in smart home and sensor systems is

a rarely unvalued field in research and development

so far. There is hardly any activity in using standards

and defined interfaces although this area of research

deals with a lot of different sensors and sensor data

from the medical field as well as from the domestic

domain and data have to be transferred to “outside”

systems.

The operating experience has shown that a

change of thinking is unavoidable for a faster and

more cost efficient development and for a more safe

data transfer.

For an efficient development in the future it will

be important to overcome proprietary systems and

solutions for every single smart home environment.

With the experience from the medical field, where a

lot of initiatives have been working on the

development and promotion of standards and

frameworks for years, an adaptation of the smart

home context is desirable.

The following benefits can be mentioned:

Interoperable and semantic systems are vendor

independent and e.g. different kinds of sensors can

easily be integrated. This opens the market and

speeds up the development and inner data transfer.

Furthermore the interfaces for any legacy system or

nursing system are defined. Thus data can be

retrieved easily by any outer system, which fulfils

the guidelines for the defined data format.

2 THE MPOWER PROJECT

MPOWER is a “Specific Target Research Project”

(Contract number 034707), partially financed by the

INFFSO DG of the European Commission.

The aim of the project is to define and implement

an open platform to simplify and speed up the task

of developing and deploying services for persons

with cognitive disabilities and elderly.

With the start of the project an investigation of

user needs was carried out. The aim was to gain

knowledge about the needs of older people and

people with dementia, in respect to technical IT

solutions, which can support everyday living and to

“aging in place”. Before developing new

technological solutions, an investigation of the user

groups’ needs and requirements was important.

When looking at the European society today,

there are some striking trends: The growth of the

older population, that is people over 65 years of age,

is expected to rise in the decades to come. In general

the health of older people is improving and life

expectancy is rising in many countries.

This changing of the society in the next years

reveals the need for a faster development of novel

176

Hanke S. and Fuxreiter T. (2008).

INTEROPERABILITY IN SMART HOME MIDDLEWARE - The MPOWER Project.

In Proceedings of the First International Conference on Health Informatics, pages 176-181

 SciTePress

and innovative technology solutions which are

providing applications for an ambient assistive

living.

The MPOWER middleware follows the IBM

Service-Oriented Architecture (SOA) approach

using web services. Applications built in the SOA

are based on services. A service is an

implementation of a well-defined business

functionality, and such services can then be

consumed by clients in different applications or

business processes. SOA-based applications are

distributed multi-tier applications that have a

presentation, a business logic, and persistence layers.

Services are the building blocks of SOA

applications. While any functionality can be made

into a service, the challenge is to define a service

interface that is at the right level of abstraction

(Mahmoud, 2005).

Web services are software parts designed to

support machine-to-machine interaction over a

network. This interoperability is gained through a set

of XML-based open standards, such as WSDL,

SOAP, and UDDI. These standards provide a

common approach for defining, publishing, and

using web services (Mahmoud, 2005).

The idea in the MPOWER project is to evaluate

use cases and features for elderly people and people

with dementia, based on user scenarios. The

assigned features are leading to services, which will

be implemented as web services. The application

developer will be able to develop applications based

on these services more efficient. For demonstrating

the middleware there are two demonstration sites

planed. One demonstration site will be based in

Norway. The Norwegian pilot Point-of-Care (PoC)

application will show the connection to a legacy

system, storing information about medical treatment,

social treatment and care planning. The other trial

Point-of-Care application will be implemented in

Poland. This demonstration site will show the

integration of different domestic and medical

sensors.

3 INTEROPERABILITY

An essential aspect of an architecture is the

establishment of technical standards. In general,

standards define common elements, such as user

interfaces; system interfaces, representations of data,

protocols for the exchange of data, and interfaces

accessing data or system functions. Technical

standards provide a number of advantages for the

systems architect.

The partners will promote standardization

through aligning their work with ongoing

development of HL7, security and interoperability

standards. Standards are important because they are

accepted by multiple vendors, thereby increasing the

likelihood that a collection of systems from diverse

sources will be able to interoperate.

Definition of interoperability in ISO/IEC 23282-

0: Information Technology Vocabulary,

Fundamental Terms: “The capability to

communicate, execute programs, or transfer data

among various functional units in a manner that

requires the user to have little or no knowledge of

the unique characteristics of those units”

Interoperability can be achieved through:

 the implementation of standards,

 the usage of predefined sets of business

procedures,

 the usage of accorded file formats and

protocols for data transmissions.

4 INTEROPERABILITY IN

MPOWER

Inside the MPOWER framework different interfaces

for implementing interoperability standards and

guidelines have been identified. Interoperability is

important for every interface where data is

transferred outside the closed system. Concerning

the Service-Oriented Architecture (SOA) approach,

messaging guidelines for data transfer between the

different services are also a need of interoperability.

The following chapters will describe these three

interfaces where interoperability needs in the

MPOWER framework are identified and where and

how standards are used.

4.1 Interoperability in Point of Care

Systems

Homecare and Point-of-Care systems that are

available today, usually provided by one single

vendor, suffer under proprietary data and messaging

transfer and lack very often in respect to data

exchange and interoperability with other systems,

especially third party systems.

A series of “health informatics, Point-of-Care”

standards are being developed in a concerted

approach between ISO, IEEE, IHE, and other major

players in the field. These efforts are targeted

towards implementing interoperable measurement

INTEROPERABILITY IN SMART HOME MIDDLEWARE - The MPOWER Project

177

systems in healthcare, for example laboratory,

intensive care and telemonitoring purposes as well

as home care. The standards provide architectural

components, information models and services

(ISO/IEEE 11073-10201), and also methods for data

exchange, both wire based, and wireless (ISO/IEEE

11073-30300).

Although the IHE started implementing the

framework for health applications, the

communication structure could also be used as well

for homecare applications for elderly and persons

with dementia. This could easily be done since there

are already structures for Point-of-Care devices as

well as for information sharing with legacy systems

or care provider systems. The benefit would be the

accordance to established standards and standard

frameworks. It is clear that there is an advantage

because of already established Point-of-Care

communications from the medical field (blood

pressure, temperature etc.). So the existing standards

have to be extended for the homecare use cases and

devices. Of course the whole IT structure and the

cross-enterprise-document (XDS) sharing defined in

the IHE framework could handle personal health

data and information, which could be, depending on

the use cases, important for medical help.

The ISO 11073 offers plug-and-play and a

functional as well as a semantic interoperability

between sensor systems and aggregation systems. In

this standard all functions and use cases in patient

oriented health care and of course in some aspects of

smart homes for elderly are object orientated

modelled already. That means a so-called domain

information model is constructed where the device,

the functionality, the measured data, settings, alarm

functions, patient information and interfaces are

defined. Furthermore there are codes for all

information elements defined as “nomenclature”

(ISO/IEEE 11073-10101) and “data dictionary”

(ISO/IEEE 11073-10201).

The communication standard POCT-1A is

implemented in the ISO 11073.9 and is specialized

for patient near Point-of-Care. In principle the

functionality of POCT1-A could be realized with

HL7, but the functional range of the HL7 structure is

in some cases (single sensors) too highly

dimensioned. So it could depend on the special

function that should be realized between the sensor

(according sensors often have a restricted hardware)

and the local controller. Because of a clear defined

message communication the unique interpretation of

the standard is guaranteed. POCT1-A is a flaring of

HL7 not a competing standard.

Figure 1: The Service Components Layer and the Physical

Layer in the SOA approach.

Figure 1 shows the Service Components Layer and

the Physical Layer in the SOA approach. The

Service Components Layer contains the POC

framework provided by the IHE with the Device

Observation Filter, the Device Observation Reporter

and the Device Observation Consumer.

The advantage of the CEN/ISO/IEEE 11073 is

that it is the only comprehensive system of Point-of-

Care medical device communication standards. The

modality categories range from real-time-operating

medical equipment to Point-of-Care test devices.

Wired as well as wireless IR and RF network

technologies are supported. If healthcare providers

and management organizations want Point-of-Care

to record transparency of information, then they

must demand medical device interoperability. In

addition to the core development bodies, the activity

coordinates regularly with other health information

activities (HL7, NCCLS, IHE and DICOM).

4.2 Interoperability to Legacy Systems

One of the key problems in healthcare and Point-of-

Care is the lack of interoperability among different

healthcare systems (service interfaces) at the one

side and among diverse device examples and

aggregation / computation systems (device

interfaces) on the other side. Interoperability

standards and frameworks would also advance the

exchange of data and information between two

system-interfaces respectively services as well.

HEALTHINF 2008 - International Conference on Health Informatics

178

Figure 2: IT Infrastructure Technical Framework provided

by the IHE.

Figure 2 shows the IHE Framework for Legacy

Systems. The Document Source is connected to the

middleware. The Documents Source could be any

kind of health record as for example the Clinical

Document Architecture, a XML schema developed

by the HL7 group for store the HL7 messaging

context in a document format. The Document

consumer will be stakeholder who is interested in

viewing the data or viewing parts of the patient

related data, e.g. a doctor or a nurse. The

identification is provided by the Patient Identity

source; i.e. a registration as it could be managed by

the eCard (www.chipkarte.at, 2007) in Austria for

example.

4.3 Interoperability between Services

Between the services all medical data will be

transferred in the well defined HL7 messaging. All

contexts concerning non medical data e.g. the

domestic sensor data will be transferred in a

common XML schema with SOAP actions.

5 RESULTS

5.1 The Operational System Layer /

Physical Layer

Based on the service oriented architecture model

from IBM (Arsanjani, 2004) the interfaces for the

interoperability have been integrated. For the

development concerning the MPOWER middleware

platform the layers of services and service or

enterprise components are of interest.

The physical layer or operational layer consists

of sensors as well as sensor systems, which provide

a collected set of information. Through the

operational layer there is of course also the

possibility to have an access on existing custom built

applications and legacy systems as well as for

instance other object-oriented implementation like

older legacy which are providing miscellaneous data

on the physical layer from bottom up.

The physical layer in the SOA approach

represents the whole sensor layer, which provides

the information of the smart house. This will be

medical data like blood pressure as well as non-

medical data like status sensors (door open, door

closed, etc.).

5.2 The Enterprise Components Layer /

Service Components Layer

The enterprise components or service components

layer uses typically container-based technologies

such as application servers to implement the

components, workload management, high

availability, and load balancing.

For future applications it must be guaranteed that

different sensors or different sensor systems from

different vendors could be connected to the system.

In this layer device components will also be

implemented. Based on the IHE framework the

device components are defining the communication

interface to the different services, which need

detailed information of one or more sensors or

sensor systems. The important interoperability

interface for connecting different sensors and sensor

systems to the system will be the data server in the

service component layer. The data server will only

accept data and information from registered sensors,

which means that a sensor has to connect to the

system. According to the ISO 11073 standards the

sensor or the sensor system has to communicate its

domain information model. The domain information

model contains the following information: the

device or sensor name, the functionality, the

measured data the sensor will provide, settings,

alarm functions and if possibly patient information

(for instance when thinking of patient monitors or

other complex measurement systems where such

data are provided).

If a single sensor with a restricted possibility of

processing power and memory capacity should be

connected to the system the POCT-1A protocol

standard is the recommended interface technology.

The POCT-1A standard is optimized for the

communication between sensors / devices and an

observation reviewer or local controller. The

protocol is XML, so it has the advantage for an easy

interpretation to HL7. As mentioned before there are

ambitions to integrate the POCT-1A into the HL7

v3.0 standard. The POCT-1A will be an add-on to

the HL7 for e.g. memory restricted devices.

INTEROPERABILITY IN SMART HOME MIDDLEWARE - The MPOWER Project

179

5.3 The Service Layer

In the service layer the different services for

interoperability are present. The services could be

used for the different business processes and interact

with each other. The work of the interoperability

group in the MPOWER project will be to provide

services, which are the interface to the “outside” of

the smart house. There will be services for document

translation or extraction to provide medical relevant

data for more comprehensive document sources like

patient reports or health records. The export of the

medical relevant data to a health record will be

provided with ebXML and SOAP protocols and

stored in a HL7 CDA adaptive format.

Figure 3: The Application Layer, the Business Processes

Layer and the Service Layer in the SOA approach.

Figure 3 shows the Application Layer, the Business

Processes Layer and the Service Layer and the

connection to “outside” server proxies.

To have the option for providing information and

data or a part of the smart house data to a healthcare

delivery organization belonging to a clinical affinity

domain (e.g. community of care) the cross-enterprise

document sharing (XDS) defined by the IHE will be

of interest. Within the XDS a federated document

repository and a document registry create a

longitudinal record of information about a patient

within a clinical affinity domain. This profile is

based upon ebXML registry standards, SOAP,

HTTP and SMTP. By looking at these standards the

MPOWER middleware platform could also provide

interfaces and standards where a data exchange to

such “outside” frameworks will be easily possible.

There will be services for mobile notification

services like SMS and Email. The interfaces for

these needs will be presented by services, which will

make the translation of the different formless

notification and alarming needs. It will be part of the

Proof-of-Concept application, making the

demonstration, to set up the “outside” proxy,

connected to the interface services provided by the

interoperability working group, for the respective

use case. The legacy system / institution is

connected to the service layer of the MPOWER

middleware because in this structure the legacy

system is an external system where an interface for a

possible data exchange should be provided. As

mentioned above it must be clear that if the legacy

system, which could be a hospital information

system as well as any other proprietary system, the

interface is in the operational layer.

5.4 The Business Processes Layer /

Choreography Layer

In the business process composition or choreography

layer different compositions and choreographies of

services exposed in the services layer are defined.

Services are bundled into a flow through

orchestration or choreography, and thus act together

as a single application. These applications support

specific use cases and business processes (Arsanjani,

2004). According to the use cases a business process

could access different services.

5.5 The Application Layer

The application developer will develop graphical

interfaces for end users conjunct with invocations of

service components as well as handling of business

processes. Several use cases will be demonstrated

during the MPOWER Proof-of-Concept

applications.

6 CONCLUSIONS

Interoperability standards in smart home

applications are not widely used and implemented.

Different sensor systems and applications in the

medical field have shown that standards and defined

interfaces are needed for a satisfying message

processing and data transfer. Proprietary systems are

restrictive and there is no sharing of information.

However the trend in Europe points to more non-

central information admittance. More and more

people are medically treated at home and

telemonitoring is a growing IT field. Therefore

novel sensor and medical data sharing applications

have to be open for any data sharing. Integration of

sensors from different vendors and information

sharing to different legacy systems is required.

HEALTHINF 2008 - International Conference on Health Informatics

180

To meet these requirements it is not sufficient to

have one fixed setup of individual components for

the sensor system. Practical systems must be able to

change within given limits, and still be able to fulfil

their purposes. Different elements from the

repository (sensors, processes, documents etc.) must

be changeable by different vendors with similar

properties. This goal can only be achieved through

working together on integrating standards.

ACKNOWLEDGEMENTS

MPOWER is a “Specific Target Research Project”

(Contract number 034707), partially financed by the

INFFSO DG of the European Commission.

The authors would like to thank all persons and

institutions in the four partner countries for

participating in the investigation.

REFERENCES

ISO/IEC JTC1 SC3, 2003. Information Technology for

Learning, Education and Training. Proposed Draft

Technical Report.

Mahmoud, Q. H., 2005. Service-Oriented Architecture

(SOA) and Web Services: The Road the Enterprise

Application Integration (EAI).

Arsanjani, A., 2004. IBM Service-oriented modelling and

architecture.

IHE Patient Care Device Technical Framework; Year 1:

2006-2007; Volume 1 Integration Profiles; Revision

1.1 Trail Implementation Version; Publication Date:

20060815

IHE Patient Care Device Technical Framework; Year 1:

2006-2007; Volume 2 Transactions; Revision 1.1 Trail

Implementation Version; Publication Date: 20060815

IHE IT Infrastructure Technical Framework Volume 2

(ITI TF-1) Integration Profiles; Revision 2.0 – Final

Text; August 15, 2005

IHE IT Infrastructure Technical Framework; Volume 2

(ITI TF-2) Transactions; Revision 2.0 – Final Text;

August 15, 2005

eCard; www.chipkarte.at ; last seen: 06/07;

Sozialversicherungs-Chipkarten Betriebs- und

Errichtungsgesellschaft m.b.H. - SVC

INTEROPERABILITY IN SMART HOME MIDDLEWARE - The MPOWER Project

181