Journal Assignment Week 8

This Provisional PDF corresponds to the article as it appeared upon acceptance. Fully formatted

PDF and full text (HTML) versions will be made available soon.

Ambient-aware continuous care through semantic context dissemination

BMC Medical Informatics and Decision Making 2014, 14 :97 doi:10.1186/1472-6947-14-97

Femke Ongenae ([email protected])

Jeroen Famaey ([email protected])

Stijn Verstichel ([email protected])

Saar De Zutter ([email protected])

Steven Latré ([email protected])

Ann Ackaert ([email protected])

Piet Verhoeve ([email protected])

Filip De Turck ([email protected])

ISSN 1472-6947

Article type Research article

Submission date 18 December 2012

Acceptance date 19 June 2014

Publication date 4 December 2014

Article URL http://www.biomedcentral.com/1472-6947/14/97

Like all articles in BMC journals, this peer-reviewed article can be downloaded, printed and

distributed freely for any purposes (see copyright notice below).

Articles in BMC journals are listed in PubMed and archived at PubMed Central.

For information about publishing your research in BMC journals or any BioMed Central journal, go to

http://www.biomedcentral.com/info/authors/

BMC Medical Informatics and

Decision Making

© 2014 Ongenae et al. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited. Ambient-aware continuous care through semantic

context disseminationFemke Ongenae 1

Corresponding author

Email: [email protected]

Jeroen Famaey 1

Email: [email protected]

Stijn Verstichel 1

Email: [email protected]

Saar De Zutter 2

Email: [email protected]

Steven Latré 3

Email: [email protected]

Ann Ackaert 1

Email: [email protected]

Piet Verhoeve 4

Email: [email protected]

Filip De Turck 1

Email: [email protected]

1 Information Technology Department (INTEC), Ghent University - iMinds , Gaston

Crommenlaan 8, 9050 Ghent, Belgium

2 Televic Healthcare NV, Leo Bekaertlaan 1, 8870 Izegem, Belgium

3 Department Mathematics and Computer Science, University of Antwerp - iMind s,

Middelheimlaan 1, 2020 Antwerp, Belgium

4 iMinds, Gaston Crommenlaan 8, 9050 Ghent, Belgium

Abstract

Background

The ultimate ambient-intelligent care room contains numerous sensors and dev ices to monitor

the patient, sense and adjust the environment and support the staff. This sensor-based approach

results in a large amount of data, which can be processed by current an d future applications, e.g.,

task management and alerting systems. Today, nurses are responsible fo r coordinating all these

applications and supplied information, which reduces the added value and s lows down the adoption

rate. The aim of the presented research is the design of a pervasive and scalable framework that is able to

optimize continuous care processes by intelligently reasoning on the large amo unt of heterogeneous

care data.

Methods

The developed Ontology-based Care Platform (OCarePlatform) consists of modular components

that perform a speci c reasoning task. Consequently, they can easily b e replicated and distributed.

Complex reasoning is achieved by combining the results of different compon ents. To ensure that

the components only receive information, which is of interest to them at that time , they are able

to dynamically generate and register lter rules with a Semantic Communication Bus ( SCB). This

SCB semantically lters all the heterogeneous care data according to the reg istered rules by using

a continuous care ontology. The SCB can be distributed and a cache can b e employed to ensure

scalability.

Results

A prototype implementation is presented consisting of a new-generation nurse call system supported

by a localization and a home automation component. The amount of data that is lter ed and the

performance of the SCB are evaluated by testing the prototype in a living lab. The delay introduced

by processing the lter rules is negligible when 10 or fewer rules are regis tered.

Conclusions

The OCarePlatform allows disseminating relevant care data for the differe nt applications and

additionally supports composing complex applications from a set of smaller inde pendent components.

This way, the platform signi cantly reduces the amount of information that ne eds to be processed

by the nurses. The delay resulting from processing the lter rules is linear in the amount of

rules. Distributed deployment of the SCB and using a cache allows further imp rovement of these

performance results.

Keywords

eHealth, Semantic modelling, Continuous care, Context dissemination, Ontology , Ambient intelligence

Background

Introduction

Since a number of years, the complexity of institutional care settings has been increasing due to societal

factors such as the growth of the care unit size, the more specialized natur e of the care and the reduction

in staf ng levels. This requires a more optimized rostering and use of staff r esources.

Information technology is often introduced [1] to deal with these issues. Th e current institutional care

settings contain numerous devices and applications to support caregiver s in carrying out their everyday

activities, e.g., electronic medical records or patient monitoring equipment. Ho wever, this high amount

of technology further increases the complexity of these daily activities, bec ause the caregivers are

directly faced with often complex technologies [2]. The caregiver has to u se several devices to consult

and insert data even when carrying out a single task. This is very time-con suming. Due to this

inadequate integration of the available technology, as well as the large amount of data being generated by the devices and the heavy workload of staff members, it is not uncommon for important events to be

missed, e.g., early indications of worsening condition of a patient.

Consider for example a patient with a concussion, who needs to be in a dark environment. Today, the

staff members are responsible for switching on the lights at the appropriate le vel each time they enter

the room. Consequently, each staff member has to be aware of all the aspec ts and speci cities of the

patient's condition. If an uninformed person enters the room or a wrong b utton is pressed, this can cause

physical pain for the patient. However, if the lighting control system would b e aware of the patient's

pathology and needs, it can automatically turn on the light to the correct level when it detects that the

nurse enters the room. Moreover, a message can be displayed explaining to the nurse why the lights are

dimmed. Staff members are able to overrule the system and a light sensor could be used to monitor the

light intensity in the room and alert a nurse if a pre-de ned threshold is cro ssed.

Ambient-aware continuous care

The ultimate ambient-intelligent care room of the future uses numerous devices to sense the needs and

preferences of the patients and caregivers and adapt itself accordin gly [3]. This implies an emerging

demand for the integration and processing of the heterogeneous data off ered by the different technologies

present in the room.

The ACCIO [4] (Ambient-aware provisioning of Continuous Care for Intr a-muros Organizations)

project aims to realize this goal by developing a context-aware, ambient-intellig ent, pervasive and

semantic platform. This platform, called the Ontology-based Care Platform (OC arePlatform), enables

technology to blend into the background by using sensors to sense the cur rent context and actuators to

adapt the environment according to the sensed context [5]. The OCare Platform integrates, lters and

processes the large amounts of heterogeneous care data delivered by the various devices, sensors,

applications and clinical databases in order to optimize continuous care proc esses. This frees the

caregiver from the cumbersome task of managing the different sensors , actuators and applications him-

or herself. However, to achieve this goal, the platform must be able to interp ret the meaning and

adequately lter the relevant information out of this huge amount of care da ta. Unorganized raw data

can be voluminous, but has no meaning on itself as it has no relationships or c ontext. Information is

data that has been given meaning by de ning relational connections. For this, the platform uses an

ontology [6], which is a semantic model that formally describes the concepts in a certain domain, their

relationships and attributes. By managing the data about the current contex t in an ontology, intelligent

algorithms can be more easily de ned that take advantage of this information to a utomate, optimize

and personalize the continuous care of patients. Referring back to the pr evious example, this means

that the ontology models the patient's condition and the nurses' locations amongs t other things.

Algorithms can then be expressed, using concepts from the ontology, to au tomatically dim the light to

the correct level based on, e.g., the location of the patient and the nurses , the time of day and the

condition of the patient. Afterward, the nurse can decide to overrule this de cision by adjusting the light

level in the room manually. This allows that unexpected events can be addre ssed by the caregiver.

Objective & paper organization

The main research question addressed in this paper is: How do we build a modu lar platform that is able

to process and intelligently reason on the large amount of heterogeneous c are data in a performant an

scalable manner in order to optimize continuous care processes?

The remainder of this article is structured as follows. The Related workSection highlights the

contributions of this paper in view of the relevant related work. The MethodsSection starts with a

description of the architecture of the OCarePlatform in the Architecture of the OCarePlatform Subsection. TheContinuous care ontology Subsection describes the developed continuous care

ontology. The Use case: optimizing continuous care through an ontology-based nurse call system

Subsection elaborates on the speci cs of the platform using an illustrative e xample, namely realizing a

next-generation nurse call system supported by a Localization and Home A utomation Component. To

demonstrate the advantages and evaluate the performance of the OCarePla tform, the prototype was

evaluated in a living lab environment. The evaluation set-up is detailed in the na l subsection of the

Methods Section. The Results and discussion Section evaluates the amount of data that is ltered by

the OCarePlatform and the performance and scalability of the lter rules. It also discusses the potential

impact of the platform on the delivery of continuous care. The conclusions are highlighted in the

Conclusion Section.

Related work

Context-aware systems

Dey and Abowd [7] refer to context as “any information that can be used to characterize the situation of

entities (i.e., whether a person, place or object) that are considered relev ant to the interaction between a

user and an application, including the user and the application themselves”. A system may be labeled

as “context-aware” if it can acquire, interpret and use context informa tion to adapt its behavior for the

current context in use [8]. A number of generic context platforms have been developed previously

to relieve application developers from the aggregation and abstraction of c ontext information and the

derivation of high-level contexts. A complete overview and classi cation o f the literature can be found

in Hong, et al. [9], while an in-depth discussion and comparison of these p latforms can be found in

Baldauf, et al. [10] and Xue and Pung [11].

One of the rst platforms to be developed was the Context Toolkit [12], a J ava framework allowing the

rapid prototyping of sensor-based context-aware applications. Howev er, the Context Toolkit does not

provide a common context model to enable knowledge sharing and context r easoning. Various

approaches have been proposed for modeling context information, i.e., k ey-value, markup scheme,

graphical, object-oriented, logic-based and ontology-based models. Str ang and Linnhoff-Popien [13]

evaluated these context modeling approaches based on six criteria, namely distributed composition,

partial validation, richness and quality of information, incompleteness and amb iguity, level of formality

and applicability to existing environments. They show that ontologies ful ll most of these requirements

and are the most expressive models as these formal models allow the integratio n and exploitation of

more speci c context knowledge with high-level context information using r easoner components. The

most prominent examples of context-aware systems based on ontologies are the Service-Oriented

Context-Aware Middleware (SOCAM) [14], the Context Broker Architec ture (CoBrA) [15], the

Context Managing Framework (CMF) [16], a service-oriented middlewar e that integrates a Context

Management Service with an Awareness and Noti cation Service (CMSANS ) [17], the

service-oriented architecture for context-aware middleware in a smart ho me described by Kim and

Choi [18] and Gaia [19]. The properties of these systems are summarized in Table 1. Table 1 Comparison of prevalent ontology-based generic and healthcare context-aware systems to

the OCarePlatform

Context-aware systems Context model Contex reasoning Reas oning expressivity

CoBrA Centralized Logic & rule-based RDFS & OWL-Lite

CMF Centralized Machine learning Naive Bayesian classi er

CMSANS Centralized Logic & rule-based RDF

SOA Centralized Logic & rule-based RDF

SOCAM Hybrid Logic & rule-based RDFS, OWL-Lite, Jena Rules, P rolog & hybrid

Gaia Distributed Logic & rule-based DAML + OIL

Fook, et al. Centralized Logic & rule-based OWL-DL

Zhang, et al Centralized Logic & rule-based OWL-DL, Jena Rules, Prolog & hybrid

ERMHAN 2 nodes Logic & rule-based OWL-DL & Jena Rules

OCarePlatform Distributed Logic & rule-based OWL-DL, SWRL & J ena Rules

A distinction can be made between systems that keep the context information centralized or distributed.

In a centralized system, one common knowledge component is used, which inte grates all the context

information and inferences high-level knowledge through reasoning on this shared context model.

Various applications can then access this knowledge or query this shared context model. The central

context server is also able to monitor context changes and send events to th e interested applications.

CMF, CMSANS, CoBrA and the SOA proposed by Kim and Choi all use this a pproach. The

disadvantage of the centralized approach is that the context server for ms a single point of failure and a

performance bottle neck. To avoid the rst problem, CoBrA offers the po ssibility of creating brokered

federations. A federation consists of multiple instances of the central know ledge component, called the

context broker. These brokers then periodically exchange and sync hronize contextual knowledge. An

advantage of this approach is that the access to the shared context model no longer depends on the

availability of one single broker. Another broker from the federation can easily be used to replace the

one that becomes unavailable. However, as each broker contains all the context information,

performance remains an issue.

In the distributed approach, the context information is distributed across multiple components. None

of the components thus has a complete overview of the current context. GAI A supports both pull and

push-based context acquisition. The former is enabled by letting the applica tions specify queries for

speci c context information. For the latter, GAIA uses communication channe ls. Each channel has one

or more context suppliers. The applications, called consumers, can regis ter for context information they

are interested in.

SOCAM employs a hybrid approach. Applications can directly receive con text information from the

different context providers. However, the context providers also s upply their knowledge to a central

knowledge component, called the Context Interpreter. This Context Interpreter maintains a shared

context model and derives high-level knowledge from it. It offers this knowledge to the different

applications. The applications thus receive both low-level as well as high- level context information.

The ontology-based context-aware systems also differ in the used knowle dge representation language.

The most common language for describing ontologies is the Web Ontology Lang uage (OWL) [20].

Three variants of OWL exist, with different levels of expressiveness, namely OWL-Lite, OWL-DL and

OWL-Full (ordered by increasing expressiveness). OWL-Lite allows expressing a classi cation

hierarchy and simple constraints. OWL-DL is founded on Description Logic s(DL) [21]. Description

Logics are decidable fragments of rst-order logic. Consequently, the O WL-DL variant provides the

maximum expressiveness possible while retaining computational completeness, decidability and the

availability of practical reasoning algorithms. As a result, semantic reasoner s, such as Pellet [22] or

Hermit [23], can be used to infer new knowledge, i.e., logical consequen ces, from the information captured in OWL-Lite and OWL-DL ontologies. Rules, e.g., Semantic Web Rule Language

(SWRL) [24] or Jena Rules [25], can be expressed using OWL conce pts. These rule languages support

a wide range of built-in operators which greatly increase expressivene ss of the context model. Table 1

summarizes the reasoning capabilities for the aforementioned context-aware platforms.

Context-awareness in healthcare

Context-aware computing is a research eld, which considers healthcare as a relevant area of

application [26]. Especially pervasive healthcare is highly suitable for us ing context-aware

systems [27]. First, there is a large amount of available information, speci c healthcare situations and

related tasks, which creates a potential for cognitive overload amongst th e caregivers. Second, the

patients, healthcare professionals and some equipment are fairly mobile, wh ich requires accurate

localization and adaptation of the healthcare services to the environment. Thir d, the nancial and

human resources are limited. This implies a need to cut cost while improving the qu ality of care to an

increased number of people. Although context-awareness infrastructu re including more complex

devices and software will add to the total cost, the reduced number of medica l errors and the ability to

more effectively utilize healthcare resources should lead to reduced cos t [27]. Finally, the expectation

to be able to access, process and modify healthcare information anywhere using mobile devices is

another reason to use context-aware approaches.

Context-aware and pervasive technologies have been applied to a numbe r of hospital use cases [26].

The following notable prototypes have been proposed in literature. The “h ospital of the future” [28]

prototype consists of (1) a context-aware Electronic Patient Record (EP R) ltering information

according to the current context, (2) an intelligent pill container for prop er dose administration and (3)

a context-aware hospital bed of which the content of the display changes according to the context and

displays warnings for some potentially incorrect actions. The Context-awa re MobileWard [29] is

designed to support nurses in conducting morning procedures in a hosp ital ward. An intelligent

hospital prototype [30] has been developed, which allows localization of a team member and the ability

to initiate an audio-video conference from the nearest contact point. Similar ly, the Vocera

communication system [31] supports communication amongst hospital workers via mobile devices and

localization techniques. In Muñoz, et al. [32] a context-aware mobile commun ication prototype is

presented, which empowers mobile devices to recognize the context in which hospital workers perform

their tasks in order to provide contextual messaging.

Similarly, the following notable context-aware prototypes have been develop ed for homecare and

residential care. Prototypes have been proposed to assist patients in tak ing their medications at

home [33,34]. Vivago [35] is a social alarm system for elderly based on wearable sensors. It provides

long-term monitoring of a user's activity pro le and automatic alarm noti cation . A context-aware

system has also been developed to assist adults with dementia during hand wa shing [36]. The use of

context-aware systems for telemedicine of chronic diseases [37,38] is also an active research eld. The

LifeMinder prototype [39] can sense pulse waves, user's actions and postures and can capture

contextual photos and continuous voices. This information is then used to de tect that the user is in a

stressful state. Finally, a prototype [40] was presented to detect falls of elderly by using a visual fall

detection system and combining this with context information, e.g., patient's gene ral condition,

location and duration of patient's inactivity.

Examples of context-aware healthcare systems based on ontologies can als o be found in literature.

Fook, et al. [41] present a context-aware system for monitoring and ha ndling agitation behavior in

persons with dementia. Zhang, et al. [42] propose a context-aware infr astructure to support the global

healthcare system in terms of device access, context management and ser vice interoperability. These

two approaches adopt a centralized knowledge management approach w ith an ontology-based knowledge component as central entity. The Emilia Romagna Mobile Health Assistance Network

(ERMHAN) [43] is a multichannel context-aware service platform designe d to enable the development

and delivery of an extensible set of care services which allow patients to b e assisted at home and

support the activity and mutual collaboration of care providers who are in volved in patient care and

assistance. This framework distributes the context knowledge across two nodes. ThePatient Context

Manager is deployed at the patient site and is responsible for pre-processing the d ata retrieved by

biomedical and environmental sensor networks. Rule-based reasoning is employed to detect abnormal

phenomena in this sensor data and to forward these anomalies to the Central Context Manager. This

Central Context Manager is deployed in the care center and combines the alarms received from the

Patient Context Manager with other context information in order to take appropriate actions. The

properties of these systems are also summarized in Table 1.

The healthcare scenario has some speci c implications which differentiate it f rom other scenarios.

Although much research has been done on the subject, the adoption of con text-aware services is

lagging behind what could be expected. Most of the aforementioned proje cts are prototypes. Real

applications are still dif cult to nd. Whereas the healthcare industry is quic k to exploit the latest

medical technology, they are reluctant adopters of modern health informatio n systems [44]. Half of all

computer-based information systems fail due to user resistance and staff in terference [45]. The main

complaint made against mobile, context-aware systems is that users had to sign i cantly alter work ow

patterns to accommodate the system [46]. An often overlooked fact is that th e strength of any

context-aware platform is heavily dependent on the correctness and co mpleteness of the used

knowledge model. This model needs to capture the daily work practices and c ontext of the caregivers

and patients accurately [47]. Constructing this model is a dif cult task. In c ontrast to the healthcare

domain in general, a lot of knowledge used in continuous care, e.g., how to p rioritize and assess nurse

calls or assign caregivers to patients, is implicit and best practices are not rigorously documented.

Another challenge in the healthcare scenario is the fact that wrong decisio ns made by the system can

have severe implications. Context data delivered by sensors is very unr eliable. Decisions made based

on wrong or incomplete sensor data might thus not be correct. Quality of Con text-aware (QoC-aware)

algorithms that take the reliability and correctness of the context data into acco unt should thus be

developed to mediate this issue.

Publish/subscribe systems

Publish/subscribe systems have evolved from static topic-based to dynamic c ontent-based systems. By

augmenting the content with semantics, subscriptions can be created which tak e into account the actual

meaning of the content. Several semantic publish/subscribe systems have be en proposed in

literature [48], which differ in the method proposed to relate subscriptions to messages, namely based

on Resource Description Framework (RDF) [49] graph-matching, ontolog ical inferencing and

attribute-value pair matching. Our approach is most closely related to semantic p ublish/subscribe

systems that use OWL inferencing. These systems represent subscriptio ns as OWL concepts and

messages as concept instances. An inferencing engine is used to determin e if a message instance

satis es the constraints of a subscription class. This approach is more exp ressive than the custom RDF

graph-matching algorithms as it allows new, non-asserted knowledge to be in ferred. Moreover, it does

not limit the formatting of the messages, as is the case in systems based on attribute -value pairs.

Ontologies for representing context in healthcare environments

The de nition and use of ontologies in the medical domain is an active researc h eld, as it has been

recognized that ontology-based systems can be used to improve the manage ment of complex health

systems [50]. However, most of the developed ontologies focus on the bio medical domain and are mainly employed to clearly de ne medical terminology [51], e.g., Galen Common Reference Model [52]

or the Gene Ontology [53].

A very well-known, comprehensive, multilingual clinical healthcare terminolo gy is SNOMED CT [54].

SNOMED CT focuses on de ning clinical terminology, providing terms, syno nyms, codes and

de nitions used in clinical documentation, clinical health records and repor ts. It contains more than

300,000 concepts. However, the focus is more on describing the condition of the patient, his or her

clinical information and the procedures he or he has undergone. As suc h it is tuned a lot towards

healthcare provided in hospital settings (focus on curing the patients) and not so much in residential or

home care settings (focus on caring for patients). Consequently, it does not represent information and

knowledge used to optimize continuous care work processes. It does no t describe, e.g., the different

care tasks such as making the bed, giving a patient toilet assistance or ans wering nurse calls and the

competences that are required for it, the various roles a caregiver can assume and the competences that

are associated with it and the association between measured parameters, the devices that measure them

and the faults and alarming measurements that might occur. Moreover, the fo rmalism in which

SNOMED CT is expressed is much less expressive than OWL. There are s till known de ciencies

regarding the ontological commitment of SNOMED CT [55,56], e.g., the clari ca tion of which kind of

entity is an instance of a given SNOMED CT concept. This means that differe nt agents might interpret

SNOMED CT differently, depending on their point of view. This means that it is dif cult for existing

OWL reasoners to reason over and classify the SNOMED CT ontology in an automated and consistent

way. Moreover, when all the instance data of different patients is added to this large ontology, it

becomes very dif cult to reason over it with existing reasoners in a scalab le and performant manner.

As such, we deem SNOMED CT ideal to integrate and exchange healthcare data in standardized

manner, however, it is not ideal to support reasoning over this data to op timize continuous care.

Different standards have also been proposed to support the continuity of care for patients. Continuity of

care is concerned with the quality of care over time. As patient's healthcare n eeds can rarely be met by

a single professional, continuity of care is achieved by providing a seamles s service to patient through

integration, coordination and the sharing of information between different healthcare providers and

caregivers. The most well-known of these standards is Health Leven Se ven (HL7), which provides

standards for the exchange, integration, sharing, and retrieval of ele ctronic health information.

However, these standards suffer from the same drawbacks as previo usly mentioned for the ontologies,

i.e., they focus on clinical information and procedures and do not contain s tandardization efforts

towards continuous care processes, e.g., making the bed or answering p atients calls.

Unfortunately, it can be concluded that little work has been done on develo ping high-level ontologies,

which can be used to model context information and knowledge utilized across the various continuous

care settings. However, ontologies have been developed for speci c s ubdomains of continuous care,

e.g., ontologies for structuring organizational knowledge in homecare ass istance [50], representing the

context of the activity in which the user is engaged [57] and modeling chron ic disease management

in homecare settings [43]. The used contextual information is often very simp le. Time, location and

pro le information of staff members and patients are the most used contextual parameters [26]. A major

challenge in modeling context-aware healthcare ontologies is that the descrip tion of a situation by using

what (activity), who (identity), where (location) and when (time) may not be enough [27]. More richness

and higher reliability are required. This could include how (process), with whom (sources), and so what

(needed action).

Our contribution

In this research, the OCarePlatform, a distributed, scalable, context-awa re and pervasive platform to

support continuous care processes, is presented. This platform emplo ys a Semantic Communication Bus (SCB) to accomplish a exible and semantic publish/subscribe mechanism tocommunicate

context information between the devices delivering context information and the applications processing

this information. Table 1 compares the OCarePlatform to the prevalent gener ic and healthcare

ontology-based context-aware systems. It can be noted that our appro ach adopts a distributed context

model. The SCB, which uses a set of core ontologies to model the communicated context information,

forwards the gathered context information to the various applications, but does not retain this

information. The applications have their own individual knowledge compone nt, which contains a

domain-speci c extension of (a subset of) the core ontologies. The app lications do retain the context

information they obtain. To communicate to the SCB in which information they are inter ested, the

applications register lter rules with the SCB. They are also able to post infer red knowledge back to the

SCB. The SCB thus loosely couples the context providers and the content consumers, i.e., the

applications. None of the components have a complete overview of the curre nt context as the

knowledge is distributed across the various applications. In contrast to a s hared context model, the

application components only manage the context model and context information pertaining to their

speci c domain. This improves the scalability and performance of these applic ations, as they need to

manage less context information with more concise context models. Conseque ntly, expressive

inferencing, i.e., OWL-DL, SWRL and Jena Rules inferencing, can be ef ciently performed. It can be

derived from Table 1 that the use of a distributed context model has not f ound a lot of uptake in

healthcare context-aware systems. Most systems use a centralized contex t model. ERMHAN only

distributes the context model across two nodes, one at the patient's home an d one in the care center.

This distribution is thus location-based. Our approach distributes the contex t according to application

domain.

Additionally, our approach differs from other OWL inferencing publish/s ubscribe systems as it also

allows the use of Jena rules and SWRL [24] to de ne subscriptions. Thes e rule languages support

a wide range of built-in operators which greatly increases expressiven ess. Jena [25] rule inferencing

exhibits the best scaling behavior in function of the amount of subscription r ules and increasing message

complexity [58,59], but is less expressive than SWRL or OWL inferencing . The choice between these

three reasoning approaches allows balancing expressivity and perfo rmance according to the speci c use

case at hand. The generic context-aware platform with semantic publish/su bscribe mechanism presented

in this paper has already been applied to several autonomic network manage ment scenarios such as the

management of a multimedia access network and the management of a cloud data c enter [59]. This paper

thoroughly evaluates the performance of the proposed platform within the h ealthcare domain. Moreover,

it is shown how a more scalable platform can be achieved by distributing the SC B and employing a

cache.

As mentioned previously, little work has been done on the development of high -level continuous care

ontologies, which can be re-used across the various continuous care d omains, e.g., hospitals, care

residences and homecare. Therefore, seven continuous care core ontologies and a plethora of

domain-speci c ontologies, which import (a subset of) these core ontolog ies, were designed. The

ontology was developed in such a way that it can easily be extended with new knowledge.

As a last contribution, this paper also presents a framework and algorithms a llowing applications to

autonomously generate and register new lter rules based on the current context.

In summary, the main contribution of this paper is the presentation of the design o f the OCarePlatform,

which combines expressive OWL-DL context reasoning, distributed mana gement of the context model

and information, intelligent ltering of context information, and distributed dep loyment of the

publish/subscribe mechanism and inclusion of a cache to increase scalability . The combination of all

these features differentiates this platform from other works in the same are a. This paper also illustrates

the exibility of the OCarePlatform by elaborating on the framework and algor ithms that allow the application components to adapt the lter rules and thus the information they areinterested in. Finally,

this paper also presents the performance evaluation of the SCB in the healthc are domain using the

developed continuous care ontology.

Methods

Architecture of the OCarePlatform

The ambient-intelligent care room consists of various devices, e.g., senso rs and nurse call buttons, and

intelligent applications that process the generated data. A communication subs trate is needed to glue

these components together and orchestrate collaboration. For this, the Semantic Communication Bus

(SCB) [59] was designed, as visualized in Figure 1. The SCB orchestrates the c ommunication of

semantically enriched data. This allows ltering data based on meaning rather th an on string patterns.

The SCB interprets the data by using core ontologieswhich model the information being exchanged for

a continuous care domain. For example, the ontologies represent that the e nvironment contains light

sensors, which make observations about the light intensity at a location. As mentioned previously, little

work has been done on developing ontologies to support the continuous c are of patients. Such an

ontology has to contain information about the pro le of staff members and patie nts, roles and

responsibilities, administrative information, etc. To tackle this issue, a participa tory ontology

engineering methodology was developed in previous research to co-cre ate together with the

stakeholders the continuous care core ontologies. This is further detailed in theContinuous care

ontology Section.

Figure 1 Architecture of the OCarePlatform using a Semantic Commun ication Bus for

interaction, collaboration and orchestration.

As depicted at the bottom of Figure 1, the Context Provider Servicesreceive data from the devices in the

environment and transform it to context information which adheres to conc epts in the core ontologies.

This semantically enriched information is forwarded to the Context Manager, which publishes it on the

SCB. For example, the Location Provider Service is used to publish location information about staff

members or patients on the SCB.

As is the case with classic publish/subscribe mechanisms, the SCB contains a Context Disseminator,

which allows application components to subscribe to context information, which is relevant to them at

that speci c moment. The application components use a Context Manager, which contains (a subset

of) the core ontologies used by the SCB, to specify the context they are inte rested in. This is done by

de ning ltering rules and registering them with the Context Disseminator. For example, a nurse

alerting application component indicates that it is only interested in light intensity ob servations,

crossing a particular threshold and coming from rooms with patients who suff er from a concussion.

These rules are expressed using concepts from the core ontologies. E xamples of such rules can be

found in the Flexible and semantic publish/subscribe mechanism Section. The application components

can also register new lter rules on the y based on the current context, w hich greatly improves the

exibility of the platform. This is further detailed in the Flexible and semantic publish/subscribe

mechanism Section.

When continuous care information is published on the SCB, the Context Disseminatormatches this

published event with the registered lter rules by reasoning on the informatio n in the ontology. If a

match is found, the information is forwarded to the application components that s ubscribed to that lter

rule. As visualized in the top right of Figure 1, the intelligent application components, receiving context

information from the SCB, also use ontologies to model their speci c (sub)do main and perform

sophisticated reasoning. These domain-speci c ontologiesextend concepts from the core ontologies,

such that the context delivered by the SCB is directly understood by the ap plication logic. Static

information about the environment is collected from databases, e.g., names o f patients or locations of

sensors. This also allows integrating information collected from the electronic health record (EHR) of

the patient in the domain ontologies used by the application components. The elec tronic health record

is checked when a new patient is admitted and the relevant information is loaded into the ontology.

During the stay, the electronic record and the ontological knowledge base are also constantly synched.

As such, this information is taken into account when reasoning is performed about the current context

and condition of the patient.

As a result of the reasoning, the application components can adapt the env ironment by controlling

devices, e.g., lights or alerting a caregiver by sending a noti cation to a mobile p hone or beeper. The

application components can also publish their conclusions on the SCB through theContext Manager .

This way, they can be picked up by other application components to perform additional reasoning. For

example, a rst application component computes the locations of people, bas ed on the available raw

sensor information, and publishes these locations on the SCB. A second ap plication component uses

this augmented location information to assign staff members to tasks, while a third ap plication

component uses it to regulate the light level in a room. As the different compo nents on which the

complex reasoning is based can run in parallel, this allows achieving complex r easoning in a very

performant and scalable manner.

Note, that the Semantic Communication Bus (SCB) only reasons about one eve nt at the time. It classi es

the event according to its properties and forwards it to the application compo nents that are interested in

these types of events. This allows that the SCB can easily be replicated and d istributed to increase its

performance and scalability. This is further explained in the Flexible and semantic publish/subscribe

mechanism Section. The application components then reason further on the events they receive from

the SCB. This reasoning possibly involves reasoning on previous events and the data recorded about

the patient and captured in an EHR or other databases. This allows building v ery modular application

components that perform very speci c tasks. Moreover, the use of lte r rules reduces the amount of

care data that is forwarded to these components. This means that they perf orm their speci c tasks,

i.e., reasoning, only on that subset of the generated events that they are interested in. This prevents

these components from being ooded with huge amounts of sometimes irrelevan t data generated by the

sensors and devices in a truly pervasive and ambient-aware patient roo m. It thus allows increasing their

performance.

To ensure that the SCB can process all the events it receives in a timely mann er, the Context Disseminator

uses a cache [60]. When information is published on the SCB, the Context D essiminator rst checks the

cache. If the published event is not found in the cache, a miss occurred and the Context Disseminator

performs semantic reasoning to determine to which lter rules the event matches . If a match is found,

the event is forwarded and the match is added to the cache. The cache thus contains mappings between

published events and the matching lter rules. However, if the published eve nt is found in the cache,

a hit occurred. The lter rules to which this event is mapped are collected an d the event is forwarded

to the application components that subscribed to the lter rule. Consequently, no reasoning needs to

be performed to process the event. Ef cient search algorithms exist to imple ment a cache, which allow

performing a cache look-up in a very performant manner [61]. Continuous care ontology

A continuous care ontology was developed using a participatory ontology engineering methodology.

The methodology is tuned towards less IT-focused domains, such as health care, where the stakeholders

might not be willing or able to construct the ontologies themselves. It involves th e stakeholders, e.g.,

nurses, caregivers and physicians, social scientists and ontology en gineers in each step of the ontology

development cycle by employing several participatory methods and techniqu es to capture the daily and

preferred work practices, e.g., observations, role-playing and discu ssing scenarios in hands-on

workshops. A detailed discussion and evaluation of the methodology can be found in Ongenae, et

al. [62,63].

Knowledge about a certain domain constantly changes such as the discove ry of new drugs and diseases.

An ontology is therefore not a static model, but a dynamic one that should con stantly be able to change

and evolve. This was taken into account by developing the continuous car e ontology in such a way that

the model can easily be extended with new concepts, relations and axioms.

As a rst measure, a distinction was made between general and domain-spe ci c continuous care

knowledge. The rst is of interest to various context-aware healthcare applications and is applicable

across all continuous care domains, e.g., hospitals, home care environmen ts and residential care

settings. This knowledge is modeled in the continuous care core ontologies. A dding too many axioms

to the core ontologies that constrain the possible interpretations of concepts was especially avoided,

unless there was very wide agreement about the constraint amongst the s takeholders involved in the

co-creation process. This facilitates cross-domain applicability of the core ontologies and allows easy

extension without contradicting with the knowledge already contained in these ontologies. The

domain-speci c ontologies, which were also developed using the participato ry ontology engineering

methodology, model knowledge particular to a speci c domain, e.g., the speci c roles and

competences employed within a hospital setting and how they map on each other, the speci c patient

pro les present within a care residence or the particular continuous car e work ows pertaining to nurse

calls or care requests. All concepts in the domain-speci c ontologies are a lways subclasses of concepts

in the core ontologies. New domain-speci c ontologies can thus easily be de ned by extending the

core ontologies.

Second, the continuous care core ontology was developed in a modular wa y instead of as one big

monolithic semantic model. The application of the participatory ontology engineerin g methodology

resulted in seven core ontologies for the continuous care domain, namely the Upper,Sensor &

Observation ,Context ,Pro le ,Role & Competence ,Medical andTask ontologies. These modules are

linked to each other using the OWL import mechanism. This way, the domain-spec i c ontologies can

easily import and extend a speci c core module instead of importing the whole co ntinuous care core

ontology. This facilitates re-use and allows application components to only use a subset of the

continuous care core ontology to perform the domain-speci c reasoning . A smaller, focused ontology

is also easier to interpret and extend with new concepts, relations and de n itions.

As a nal measure, the de ned concepts are grouped as much as possib le into logical categories,

according to the properties they share. This logical category is introduce d as a concept in the ontology

and the grouped concepts are de ned as subclasses of this concept. F or example, consider the process

of modeling the pro le information of a person, e.g., his/her mother tongue, se x and nationality. This

information could be represented by relationships, e.g., hasSexorhasNationality , with as

domain the Personconcept or as separate concepts in the ontology, e.g., SexorNationality . In

the continuous care ontology the latter approach is chosen and these conc epts are introduced as

subclasses of a logical category concept, i.e., Profile. Restrictions, relations and properties can then

be de ned on this logical category. When new pro le information needs to b e added to the ontology, it

can easily be added as a subclass of the logical category concept. The n ew pro le information will automatically inherit all the relations, restrictions and properties de ned on the parentProfile

concept. This makes it easier to manage and extend the ontology. As can be s een at the bottom of

Figure 2, the logical category can even be further divided in several lo gical subcategories, e.g., the

subclassing of the Profileconcept into the Biological,Psychological and

Sociological Profile concepts.

Figure 2 Overview of the most prevalent classes and relations of the s even continuous care core

ontologies. The gure visualizes the most prevalent classes, their relations and prop erties of the

seven continuous care care ontologies, namely the Upper,Sensor ,Context ,Pro le ,Role & Competence ,

Medical andTask ontology . The squares represent the classes. The dashed arrows depict su bclass

relationships. The blue arrows represent relationships between classe s (object properties) and between

classes and ranges (datatype properties). Ovals represent the rang es of the datatype properties.

The continuous care core ontologies are used by the SCB to lter the contex t information for the

appropriate application components. The most important concepts and relatio ns of the core ontologies,

with respect to the use case detailed in the following section, are depicted in Fig ure 2 and discussed in

the following paragraphs. The application components use (a subset of) the core and domain-speci c

ontologies to perform sophisticated reasoning on the data they receive fr om the SCB.

The Upper ontology describes general classes, relations and axioms. Most importantly this onto logy

enables data to be related with a unique ID. The classes preceded by the na mespace pre xtemporal

are imported from the SWRL Temporal Ontology [64] and model complex interval-based temporal

information. All the other core ontologies import this ontology and de ne their c oncepts as

subconcepts of temporal:Entity . This is not shown on Figure 2 to avoid overloading the gure.

The Sensor & Observation ontology is one of the most important ontologies for ltering data. The

concepts preceded by the wsnnamespace pre x are imported from the Wireless Sensor Network

ontology (WSN) [65,66], which was developed by the co-authors and allows givin g meaning to data

values monitored by sensors. It contains a Systemconcept, which models a system and its

components. These components are modeled as subclasses of System, e.g., the Sensoror

Actuator concepts. A Systemcan then be associated with its components through various

properties, e.g., hasSensorPart orhasActuatorPart . The modeledObservation concept

represents a data value monitored by such systems. However, context inf ormation is often unreliable as

it is gathered by sensors which can be imprecise or erroneous, e.g., fall detection sensors are known to

often generate false positives. Moreover, the context information can b e ambiguous as information

gathered by different sensors can be con icting or the context informa tion might even be incomplete if

there is no sensor information available. As it is mostly this context information tha t determines the

behavior and the strategies of the different application components, it is impo rtant to make the quality

of the context data explicit to prevent error propagation. To support th e development of QoC-aware

algorithms, this ontology contains axioms and rules, modeled as Symptomconcepts, which allow

detecting speci c phenomena in the observations published to the SCB. For e xample, the

LightIntensityBelowZeroSymptom detects light intensity observations that are below zero.

Using OWL2 DL mechanisms, axioms are provided that reclassify these sympto m individuals as

individuals of the Faultconcepts, e.g., the previously mentioned symptom is reclassi ed as a

FaultyLightIntensitySensor indicating that the sensor that made the measurement is faulty,

since light intensity can never be below zero. Additionally, a fault can be re classi ed as aSolution,

e.g., the previous fault is reclassi ed as the DoNotUseSensorsolution indicating that measurements

from this sensor should not be used by the algorithms. Consequently, the a pplication components can

take these classi cations into account in their lter rules and algorithms. For e xample, on the one hand,

the application components can register lter rules that indicate that observa tions reclassi ed as

FaultyLightIntensitySensor concepts should not be forwarded to the application component. On the other hand, application components could also choose to receive these annotated

observations and process them differently in their own algorithms, e.g., for Fault Detection and

Diagnosis (FDD). The WSN ontology was extended with subclasses of the System,Sensor ,

Actuator ,Observation ,Fault andSolution concepts. These subclasses represent systems

(e.g., nurse call system), sensors (e.g., RF or light sensor) and actuato rs (e.g., light or magnetic lock)

and their associated observations (e.g., call button pushed or light intensity ), faults (e.g., light intensity

too high) and solutions (e.g., turn down the light) that play an important role in co ntinuous care

settings.

The Context ontology models the contextual environment information. ContextGroupis the most

important concept. It represents a logical grouping of entities that belong together, e.g., a patient with

all his/her devices, room, bed and other equipment. The composition of a con text group dynamically

changes based on the context. This ontology also contains all the information related to localization. A

Location can either be a coordinate or a zone.

The Pro le Ontology models the pro le information about staff members and patients that was indicate d

as being important by the stakeholders in the workshops. Each Personis associated with a Profile,

which consists of a basic and a risk pro le. The latter is de ned by axioms an d rules, which allows

inferencing the risk pro le of the patient by reasoning on the information in th e basic pro le.

The Role & Competence ontology de nes each role by its competences through axioms. This supports

algorithms that nd the most appropriate staff members to ful ll a task based on the required

competences. Each person is then associated with competences and roles th rough ve relationships:

hasFunction ,hasRole ,hasCurrentRole ,hasDiplomaCompetence and

hasExperienceCompetence . ThehasFunction relation models the primary role of a person,

i.e., the role for which this person was primarily hired. The hasRolerelation indicates all the roles a

person can ful ll, while the hasCurrentRolemodels the person's current role. If the latter is not

instantiated, it is assumed that the current role of the person is his/her func tion. The

hasDiplomaCompetence andhasExperienceCompetence indicate extra competences a

person has acquired by either following training courses or through exp erience.

The Galen Common Reference Model [52], of which the concepts are preceded by the galen

namespace pre x, represents clinical terminology. The Medical ontologyadds axioms and constraints

to this imported terminology, which express relations between this medical knowle dge and concepts in

the other ontologies.

Finally, the Task ontology models continuous care process work ows. A work ow represents a

sequence of related continuous care tasks, which are conducted in a pa rticular order. For this, the

OWL-S Process ontology [67] was imported, of which the classes are preceded by the owlsnamespace

pre x. The Processconcept models a process, which can return information and produce a c hange in

the environment based on the context and the information it is given. This is d escribed byhasInput,

hasOutput ,hasPrecondition andhasEffect relations. A process can be composed of

several other processes. The Taskconcept, introduced as subclass of Process, represents the

various continuous care tasks. Consider, for example, the task of assig ning a person to a call. ACall

is modeled as an unplanned task. A Normal Callis then modeled as a Call, which has as

precondition that a patient pushes a call button. This task takes the patient a s input and the assigned

caregivers as output. The effect of the Normal Callis that the assigned caregivers' cellphones ring. Use case: optimizing continuous care through an ontology-based nurse call system

Scenario description

Nurse call systems are a very important fundamental technology in continuo us care as they are used by

caregivers to coordinate work, be alerted of patient's needs, communica te with them through intercoms,

and request help from other staff members. When patients feel unwell the y push a button. The nurses

then receive a message on a beeper with the room number. This brings us to the question: which nurse

goes to the room, the closest one, the one on call, et cetera? The current systems often have a very

static nature as call buttons have xed locations, e.g., on the wall next to the b ed. Moreover, there is an

increased risk when patients become unwell inside a hallway, staircase or outside as they cannot use the

nurse call system. Additionally, the current nurse call algorithms consist o f prede ned links of beeper

numbers to rooms. Consequently, the system presently does not take into ac count the various factors

speci c to a given situation, such as the pathology of a patient (e.g., heart patient or confused) nor the

competences of the staff (e.g., nurse or caregiver).

The increased introduction of electronic devices in continuous care setting s facilitated the development

of the ontology-based Nurse Call System (oNCS), visualized in Figure 3, which allows patients to walk

around freely and use wireless nurse call buttons. Additionally, this platfo rm manages the pro les of

staff members and patients in an ontology. A sophisticated nurse call algorithm was developed by the

authors. It rst determines the priority of the call using probabilistic reaso ning algorithms, which take

into account the origin of the call and the pathology of the patient. Next, the alg orithm nds the most

appropriate staff member to handle the call. It dynamically adapts to the situation a t hand by taking

into account the context, e.g., location of the staff members and patients. A deta iled description of this

platform can be found in Ongenae, et al. [68].

Figure 3 General concept of the oNCS System with probabilistic priorit y assessment and pro le

management.

To better illustrate the bene ts of the OCarePlatform, an extension of the oNCS Application Component

is presented in this paper, which allows nurse calls to be automatically launched based on the data

generated by the electronic equipment and sensors in the environment, e.g., alerting a nurse when the

light intensity is too high in the room of a patient with a concussion. The propos ed extension provides a

solution to potential risky situations being missed because the caregivers ar e overloaded with constantly

monitoring and orchestrating all the devices in the ambient patient room, making it more applicable to

real-time scenarios.

To realize this extension, two other application components were designed, n amely a Localization and

Home Automation Application Component. The rst determines the location of patien ts, staff

members and devices. The latter automatically controls the ambient-intelligent activ ity in the room of

the patient, e.g., switching on the lights at the appropriate level. The oNCS, the H ome Automation and

Localization Application Component each represent an Application Componentwhich uses the SCB to

lter context information that is relevant for it at that moment. The architectur e of these components is

thus very similar to the architecture of the Application Componentat the top right of Figure 1. These

three application components, the SCB, the sensors and the actuators togeth er form a scenario-speci c

implementation of the OCarePlatform.

The OCarePlatform has also been leveraged to develop a social-aware a nd context-aware multi-sensor

fall risk assessment and detection platform and to support the continuous care of elderly by a trusted

care network in an ambient-aware home environment. More information about these use cases can be

found in De Backere, et al. [69] and Van den Abeele, et al. [70] resp ectively. Flexible and semantic publish/subscribe mechanism

The SCB allows application components to subscribe to relevant context information by registering lter

rules with the Context Disseminator. When a context publisher forwards inf ormation to the SCB, the

Context Disseminator reasons on the core ontologies to determine which subs cribers are interested in

this information by computing whether the forwarded data satis es at least on e lter rule de ned by the

subscriber. If it does, the information is forwarded to the application compo nent.

Publishing context. The Context Provider Services are used to semantically annotate data with

concepts from the core ontologies so that it can be interpreted by the SCB. To achieve a exible

system, in which published context and lter rules can easily be matched, an Eventconcept is added

to the Upper Ontology , which has ahasContext relationship totemporal:Entity concepts.

These additions are indicated in green in Figure 2. As all the other core ontolo gies import theUpper

Ontology , thisEvent concept and the hasContextrelationship essentially become a part of all the

other core ontologies too. These core ontologies have de ned all their co ncepts as subconcepts of

temporal:Entity . As such, all their instances can occur as range of the hasContextrelation.

New types of events and lter rules can thus easily be expressed and match ed. No other modi cations

to the ontologies are needed to support the management of these events.

When a device wants to publish context information, the Context Provider Se rvice creates an event,

containing the data it wishes to publish. For example, to publish that the light sen sor with ID L101

measured a light intensity of 100 lumen, the following instances are created (c f. Figure 4A):

Ob owl:instanceOf ObservationandOb hasValue 100 andOb hasUnit `lm'

LsId owl:instanceOf IDand LsId hasID `L101'

Ls owl:instanceOf LightSensorandLs hasId LsId andOb isObservationOf Ls

Ev owl:instanceOf EventandEv hasContext Ob

Similarly, application components can publish the results of their reasoning. Fo r example, the

Localization Component collects all the context information that gives an indic ation of the location of

staff members, such as Radio-Frequency IDenti cation (RFID) tags, an d calculates their current

locations, e.g., room 101. These locations are published on the SCB to be us ed by other application

components, e.g., the oNCS Application Component, as follows (cf. Figure 4B ):

Pid owl:instanceOf IDand Pid hasID `AB452487'

Powl:instanceOf PersonandP hasId Pid

R101 owl:instanceOf RoomandR101 hasNr 101 andR101 isLocationOf P

Ev owl:instanceOf EventandEv hasContext R101

To support the aggregation of context data and allow lter rules to proces s multiple observations

simultaneously, more complex Context Provider Services can be written. For example, instead of

publishing each light intensity observation to the SCB separately as in the rst example, a Context

Provider Service was developed to calculate the average of all the light inte nsity observations in a room

within a minute and only publish this average as an event on the SCB. This even t can be published as a

normal LightIntensity observation or the aggregation process can be made explicit to the SCB by creating a new type of theObservationconcept in theSensor & Observation core ontology , for

example AveragedLightIntensityObservation . Filter rules can then be written to process

this new type of event. Similarly, Context Provider Services can be written to a ggregate the values of

different types of sensors.

Figure 4 Examples of events published on the SCB. This instantiation diagram visualizes two

examples of events that are published on the SCB, namely A)an event indicating that a light sensor

with ID L101 measured a light intensity of 100 lumen and B)an event expressing that a person with ID

AB452487 is located in room 101. The squares represent classes fro m the core ontologies. The dashed

arrows depict subclass relationships. The blue arrows represent re lationships between classes (object

properties). The green text and arrows indicate instances of classes, ranges of datatype properties and

instantiated object properties.

Subscribing to context. Filter rules are expressed by de ning subclasses of the Eventclass. This

way, the Context Disseminator can determine if the published context matches a lter rule by asking

an OWL Reasoner, such as Pellet, if the published event can be classi ed as an instance of theEvent

de ned by the lter rule [59]. The lter rule is de ned by means of necess ary and suf cient conditions,

which the published event must ful ll to belong to this class. Moreover, the C ontext Disseminator can

use the OWL reasoner to check if the lter rule is satis able, i.e., does not co ntradict with the knowledge

already de ned in the core ontologies. If the lter rule is unsatis able, the s ubscription of the lter rule

fails and the class is not added to the ontology. This ensures increased ro bustness.

For example, as the Home Automation Component regulates the ambient-intelligent a ctivity in the room

of a patient, it is interested in location information, as well as light intensity, humidity and temperature

observations. It registers the following lter rule:

Event andhasContext some(LightIntensity

or ExternalTemperatureObservation

or Humidity

or Location)

Note that the two Eventexamples match with this lter rule. The ontology declares that each

Observation , which has a unit of type lumen, is an observation of type LightIntensity, as

follows: LightIntensity == (Observation and (hasUnit value “lm” ˆˆstring)) Consequently, the rst event

matches. Similarly, the second event matches because the ontology states that eachRoom is a subclass

of Location , as follows: Room subclass of Zone

Zone subclass of Location These events will thus be forwarded to the Home Automation Component.

Generating new lter rules. The information in which an application component is interested can

change based on the current context. Instead of ltering all the context that might be needed at some

point in time, the application components are able to generate new lter rules whe n the context

changes. The lter rule generation process is thus made context depend ent. To enable this, the

ontology allows de ning context dependencies between different, but r elated context. A context

dependency (X,c,Y) means that context Y only needs to be ltered if the con dition c holds for context

X. Optionally, a range d can also be speci ed for the values of this context parameter Y. For example,

the domain-speci c ontology used by the oNCS Application Component de ne s the dependency: (Person ,hasDiagnosis some (hasAssociatedPathology some (hasSymp tom

some galen:SensitivityToLight)) ,LightIntensity ). This dependency indicates that

the oNCS Application Component is also interested in LightIntensitymeasurements when a

patient is detected who is sensitive to light. Additionally, the domain-speci c onto logy associates each

light sensitivity symptom with a threshold, e.g., 100 lm. Consequently, the range d of Y is de ned as

being greater than or equal to this threshold. This allows the oNCS Application Component to alert a

caregiver when the light intensity is too high, i.e., greater than or equal to 10 0, at the location of this

patient.

Given the context dependencies, the lter rule generation algorithm work s as follows. The

ContextToQuery concept and thehasContextDependency relationship between

temporal:Entity concepts are introduced in the Upper Ontology, as visualized in orange in

Figure 2. To de ne a context dependency, a subclass of the ContextToQueryconcept is de ned

with the necessary and suf cient condition that the ontological instance mus t have the relationship X

hasContextDependency Y andc true . The ContextToQueryLightSensitivePerson

concept at the bottom of Figure 2 illustrates this for the running light sensitiv ity example. Every time

the context changes, the context dependencies are investigated by exa mining the membership of

instances to the ContextToQuery concept through inferencing on the ontology. Once the

membership is determined, the construction of the lter rules is straightforward . For example, consider

that the oNCS Application Component is alerted that the patient in room 101 is dia gnosed with a

concussion, because his pro le is updated in the EHR database. The doma in-speci c ontology of the

oNCS Application Component contains the knowledge that patients with a concu ssion have light

sensitivity as a possible symptom, as follows: Concussion subclass of (has Symptom some

LightSensitivity) Consequently, the condition c of the context dependency holds and the reasoning

inferences that this person is an instance of the ContextToQueryLightSensitivePerson

concept.

The lter rule is then constructed by de ning an Event, which has as context the range Y of the

hasContextDependency . To determine the device(s) from which this context Y should be ltered,

the ContextGroup associated with the patient is analyzed. As previously explained, the

ContextGroup represents a logical group of entities, e.g., a patient with his/her associated devices.

For the running example, this results in the following lter rule:

Event andhasContext some(LightIntensity

and (hasValue some oat[>=100])

and (isObservationOf some

(hasId somehasID `L101')))

This rule lters light intensity observations from the room of the patient. For th e published context to

match with this lter rule, it must be of type LightIntensity. Moreover, its current value must be

of type oat and higher than or equal to 100. Finally, the observation must originate from a system with

ID `L101'. This is the ID of the light sensor in room 101. As previously ind icated, this kind of static

information is stored in databases, which can be queried by the application co mponents. Note that the

rst example of the Publishing contextSection matches with this lter rule. More information about this

lter rule generation algorithm can be found in [59].

Distributed deployment. As the application components heavily depend on the SCB to receive relevan t

context information, the centralized design of the SCB forms a single point of failure and a performance bottleneck. However, the SCB can easily be distributed as it does not retainthe published context

data, i.e., only one event is processed at a time by the SCB. Different instan ces of the SCB, processing

the various events in parallel, can thus easily be deployed without interferin g with each other. An actual

large-scale deployment of the SCB will thus most likely not correspond to a c entralized physical process,

but will be a virtual substrate distributed across the network. Two approa ches can be used, which are

compared in Figure 5.

Figure 5 Comparison of the two approaches to distribute the SCB. To prevent that the SCB becomes

a single point of failure and to improve the performance, the SCB can be distr ibuted. ApproachA

replicates the SCB, meaning that each context dissemination instance will conta in the same amount of

lter rules and the published events are divided across the different SC Bs and processed in parallel.

Approach Bdistributes the lter rules across different instances of the SCB, proces sing a published

event in parallel.

On the one hand, the SCB can be replicated, meaning that each context diss emination instance will

contain the same amount of lter rules and the published events are divided a cross the different SCBs

and processed in parallel. This improves the scalability. Replication also remov es the single point of

failure as a replicated instance of the SCB can easily replace a faulty one. T his approach can be achieved

by using the persistent team approach described in the Adaptive Agent A rchitecture [71].

On the other hand, the lter rules can be distributed across different insta nces of the SCB, processing a

published event in parallel. In this case, the number of lter rules present in each context dissemination

instance will thus be relatively low, which increases the throughput of eac h SCB signi cantly.

Sophisticated algorithms have been proposed in literature to ef ciently distribu te the lter rules across

the different peers [72]. This approach can be combined with the rst to deal with faulty nodes.

Evaluation set-up

To evaluate the performance and bene ts of the SCB, a prototype of the oN CS Application Component,

extended with the Localization and Home Automation Application Components, was imp lemented and

tested in the Patient Room of the Future (PRoF) [73]. PRoF is a high- delity mo ck-up of a near-

future patient room integrating innovations from soft- and hardware dev elopers as well as furniture.

The aim of PRoF is to make a patient feel more at home by exploring ways to put the patient and his

needs rst. PRoF consists of a typical patient room and hallway found in a hospital setting, as well

as a room mimicking a homecare setting. For the prototype, both rooms were equ ipped with a TMote

Sky [74] sensor board, which contains a light, temperature and humidity sen sor. Also, each patient

and staff member carried an RFID tag to track their location. Finally, each patie nt wore a bracelet that

monitors the patient's body temperature. The developed prototype, consisting of the various context

providers, the SCB, the oNCS, and the localization and Home Automation Applica tion Components,

was installed in PRoF and integrated with the available nurse call and light contr ol system, RF tags and

sensors. Smartphones running the mobile nurse call application, which ena ble the nurses receive and

answer calls, were also provided. Figure 6 visualizes the deployment of th e prototype and accompanying

sensors in PRoF. As PRoF contains only two rooms and the number of users was also limited, only one

instance of the SCB was deployed. Figure 6 Deployment of the prototype in PRoF.To evaluate the performance and bene ts of the SCB,

a prototype of the oNCS Application Component, extended with the Localization a nd Home Automation

Application Component, was deployed in the Patient Room of the Future (PRoF ). PRoF consists of a

typical patient room and hallway found in a hospital setting, as well as a ro om mimicking a homecare

setting. For the prototype, both rooms were equipped with a TMote Sky senso r board, which contains a

light, temperature and humidity sensor. Also, each patient and staff member ca rried an RFID tag to track

his/her location. Finally, each patient wore a bracelet that monitors the patien t's body temperature. The

developed prototype, consisting of the various context providers, the S CB, the oNCS, the localization

and Home Automation Application Components, was installed in PRoF and integrated with the available

nurse call and light control system, RF tags and sensors. Smartphones r unning the mobile nurse call

application, which enable the nurses receive and answer calls, were als o provided.

This prototype allowed users to experience a fully immersed, contextual exp erience of the system in

a lifelike context. As we wanted the participants to have a complete experience o f the system, small

groups were invited, i.e., two or three users per workshop, so that they w ould be occupied at all times

and the researchers could follow them one-on-one. As such, seven w orkshops were organized for 15

participants. During a 2.5 hour role-playing workshop, the participants we re asked to play out seven

scenes. For each scene, a test user received a persona card and a context card, informing the test user

of the role he or she would have to take up and what he or she would have to do. Afterward, the

functionality of the system was elaborately discussed.

However, as PRoF contains only two rooms, it was dif cult to thoroughly ev aluate the performance of

the system based on these user tests. To mediate this, simulations were perfor med based on realistic

data gathered from observations and interviews performed at Ghent Un iversity Hospital [75]. The

simulated department contains 20 rooms, 30 patients and 10 staff members, who answer calls. It was

again assumed that each room is equipped with a TMote Sky, the temperature o f each patient is

monitored with a bracelet and the location of all the staff members and patients is tr acked. The

simulation of the observations of the RF tags was based on realistic data gather ed about the walking

behavior of caregivers and patients in several departments of Ghent U niversity Hospital. The

simulation of the observations of the other sensors was based on stakehold er input. Table 2 gives an

overview of the amount of data generated by each sensor for the simulation s. As the goal of the

simulations was to assess the performance and scalability of the SCB, only one instance was deployed.

Table 2 Sensor data generated in a department with 20 rooms, 30 pa tients and 10 staff members

Nr. of Nr. of observations Total nr. of observations

Sensor sensors per sensor per hour

Light 1/room 1/sec 72,000

Temperature 1/room 1/sec 72,000

Humidity 1/room 1/sec 72,000

RFID tag 1/person 1/sec 144,000

Body temperature 1/patient 1/sec 108,000

The prototype is able to realize the example detailed in the IntroductionSection. This scenario consists

of the following steps.

First, the oNCS, Localization Component and Home Automation Application Compon ents register lter

rules with the SCB, to receive context information they are interested in, inde pendent of the current

context. These lter rules are visualized in green in Figure 7. Figure 7 First step of the implemented scenario: Con guration.This sequence diagram visualizes

the different actions taken during the rst step of the scenario realized b y the implemented prototype.

In this step, the different application components are con gured by regis tering lter rules with the SCB

such that they receive the context information that they are always intere sted in, independent of the

current context. The lter rules are depicted in green. The “par” indica tes that the different application

components can perform their actions in parallel.

During the night, a nurse enters the room of a patient, who is sleeping. As the RFID tag of the nurse is

picked up by the loop installed in the room, an event is generated and publishe d on the SCB. This event

is shown in the rst blue square of Figure 8. The RFIDRegistrationconcept is de ned in the

ontology as an observation made by a Sensorof typeRFIDLoop orRFIDReader , as follows:

RFIDRegistration == (Observation and (isObservationOf some (RFIDLoo p or RFIDReader)))

Consequently, this event matches with the lter rule registered by the Localiza tion Application

Component. This component maps the RFID on the appropriate nurse and up dates the location of this

person. This location information is pushed back to the SCB, as illustrated in the second blue square of

Figure 8. As already explained in the Subscribing to contextSubsection of theFlexible and semantic

publish/subscribe mechanism Section, this location information matches with the lter rule of the

Home Automation Application Component. Similarly, it also matches with the lter rule of th e oNCS

Application Component. The latter only updates the location of the nurse. No fu rther reasoning is

triggered in this component. However, the former detects that a nurse has e ntered the room during the

night shift. The Home Automation Application Component also knows that the light is currently turned

off. To enable the nurse to perform her duties, the component decides to switch on the light to a very

low level, namely 1. Consequently, the light sensor in the room detects the cha nged light intensity in

the room and an event is sent to the SCB, as shown in the third blue square o f Figure 8. As explained in

the Subscribing to context Subsection, this light intensity information is picked up by the Home

Automation Application Component, which concludes that the light level was adju sted to the right

level.

Figure 8 Second step of the implemented scenario: Turn on light when nurse enters the room.

This sequence diagram visualizes the different actions taken during the s econd step of the scenario

realized by the implemented prototype. In this step, a nurse enters the room of the patient. This is

detected by using RFID Tags, which send an Eventto the SCB. The Localization Component is alerted

of this Eventas it matches with the lter rule this application component registered with the SCB. The

location of the nurse is updated and this information is published on the SCB. Th is location information

is forwarded to the oNCS and the Home Automation Application Components as it matc hes with their

lter rules. The rst just updates the location of the nurse in its local domain- speci c ontology. The

second uses this information to adjust the light level in the room of the patient. F inally, the light sensor in

the room notices the change in light intensity and publishes this Eventon the SCB. This Eventmatches

with the lter rule of the Home Automation Component, which receives this Eventand reasons that the

light was adjusted to the appropriate level. The different Events are depic ted in blue. The “par” indicates

that the different application components can perform these actions in par allel.

The next day, the EHR of the patient is updated to indicate that a patient with ID P231 has a concussion,

as illustrated in Figure 9. Consequently, the knowledge bases of the oNCS a nd Home Automation

application components is updated with this information as they are regularly syn ched with the database

containing the EHR data. As explained in the Generating new lter rulesSubsection of theFlexible and

semantic publish/subscribe mechanism Section, the oNCS Application Component registers a new lter

rule with the SCB as it detected that the patient with ID P231 is sensitive to light. Figure 9 Third step of the implemented scenario: Registering a dynamic lter rule.This

sequence diagram visualizes the different actions taken during the third s tep of the scenario realized by

the implemented prototype. In this step, the local domain-speci c ontologies of th e Home Automation

and oNCS Application Components are updated to signal to these components th at a particular patient

has a concussion. The oNCS Application Component uses its local domain-s peci c knowledge to derive

that this patient is sensitive to light. Consequently, the oNCS Application Compon ent registers a lter

rule to receive speci c context information pertaining to the light intensity in this patient's room. The

lter rule is depicted in green. The “par” indicates that the different applic ation components can perform

their actions in parallel.

In the evening, a visitor enters the room of patient with ID P231, who is curr ently resting. This causes

the light to be automatically turned on to a low level. The actions taken to realize this a re similar to

the ones visualized in Figure 8. However, in Figure 8 the Home Automation Applic ation Component

dims the light because it is night. In this case, the light is dimmed because the patien t has a concussion.

However, as visualized in Figure 10, it remains possible for people to over rule the system and brighten

the light in the room. The light sensor again picks up this change in light intensity in the room. An event

similar to the event in the last blue square of Figure 8 is published on the SCB. T his event is picked up by

the Home Automation Application Component. However, this component detects tha t it already tried to

dim the light and that a person has manually adapted the light level. The Home Au tomation Application

Component can thus not intervene. However, because of the newly reg istered lter rule, this event is

also forwarded to the oNCS Application Component. This component reason s on the event and alerts a

nurse that the light level has been turned on too high in the room of a patient with light sensitivity.

Figure 10 Fourth step of the implemented scenario: Visitor overrules the system and a nurse is

alerted. This sequence diagram visualizes the different actions taken during the f ourth step of the

scenario realized by the implemented prototype. In this step, a visitor adjusts the light level in the

room and thus overrules the system. The light sensor in the room notices the change in light intensity

and publishes this Eventon the SCB. This Eventmatches with the lter rule of the Home Automation

Component, which receives this Eventand reasons that the light level cannot be adjusted to the needs of

the patient as the component has been overruled. However, this Eventalso matches with the new lter

rule that the oNCS Application Component registered in step 3 of this scenario . The oNCS Application

Component derives that the light level is above the threshold for patients w ith a concussion and uses

reasoning to nd the most appropriate nurse to alert. The “par” indicates th at the different application

components can perform these actions in parallel.

The evaluations were performed using the continuous care core ontologie s needed to model the scenario

as described in the Continuous care ontology Subsection. The core ontologies consist of 142 classes, 42

object properties, 21 data properties and 556 asserted axioms. The Pro tégé ontology editor [76,77] was

used to develop the ontologies in OWL-DL [20]. The context information pub lished on the SCB and the

lter rules registered by the application components are also expressed in O WL-DL. The prototype was

built in Java, based on the Pellet OWL 2 reasoner [22] and the OWL Applica tion Programming Interface

(OWL-API) [78]. The cache was implemented using a combination of the Leas t-Frequently Used (LFU)

and Least Recently Used (LRU) replacement algorithms, called the Least R ecently/Frequently Used

(LRFU) policy [79]. All the tests were performed under exactly the same co nditions on the same isolated

machine with following speci cations: Advanced Micro Devices (AMD) Athlon 64 X 2 Dual Core

Processor, 3000 megahertz (MHz) Central Processing Unit (CPU) an d 2 Gigabyte (GB) of Random-

Access Memory (RAM). Results and discussion

Semantic reasoning and ontologies were adopted in this research to facilitate the exploitation and

integration of heterogeneous context information delivered by the device s in an ambient-intelligent

patient room. However, it is widely known that special attention needs to be p aid to the number of

instances in the ontology as this adversely affects the reasoning performa nce [80]. Consequently, if all

the data from the ambient-intelligent environment would be delivered directly to the ontology-based

application components, their performance would degrade drastically. By u sing the SCB, which only

process one event at a time, lters can be de ned to ensure that the applic ation components only

receive relevant context information. This way, the different infrastr ucture components are loosely

coupled, effectively separating the devices delivering context informa tion from the application

components that process this information. Moreover, the SCB allows the comp osition of complex

application components from a set of smaller application components, which pe rform speci c

reasoning tasks in parallel and forward their conclusions through the SC B.

Consequently, the effectiveness of the rules can be measured by the re duction in the amount of

information that is processed by the application components as it is important that only the necessary

context information is analyzed. However, the correctness of the rules is another important

performance metric. The correctness is in uenced by the amount of data th at was wrongfully ltered.

It is important not to lter too much information, as a lack of information about the context might

cause application components to take incorrect actions or no action at all. Th e goal is to increase the

effectiveness, while maintaining the correctness. Consequently, we aim to maximize the amount of

data that is not forwarded, while ensuring that all the information that in ue nces the actions of

application components is correctly forwarded.

In the scenario detailed in the Evaluation set-upSubsection of theMethodsSection, the SCB is capable

of ltering a large amount of the simulated data from Table 2. As the Home Automatio n Component is

only interested in sensor observations about the light intensity, the externa l temperature and the

humidity, 54% of the generated sensor data is not forwarded to this compone nt. Similarly, the

Localization Component is only interested in RFID tag data, resulting in a 77% re duction of forwarded

data. By taking advantage of the dynamic lter rule generation, none of the ligh t intensity observations

are forwarded to the oNCS Application Component if none of the patients in the department have light

sensitivity symptoms. When the department does have such a patient, only 8.3% of all the light

intensity observations are forwarded to the oNCS Application Component. In this case we assume that

it takes the nurse on average 5 minutes to respond to the context call, gener ated by the oNCS

Application Component because the light intensity is too high in the room. This time inte rval was

chosen based on observations and stakeholder expertise. This way, th e lter rule generation process

allows dynamically adapting the amount of data that is ltered based on the conte xt. It can be noted

that neither the oNCS nor the Home Automation Application Component ever rece ive RFID tag

observations anymore. They depend on the Localization Application Compon ent, which processes

these raw RFID observations and publishes the resulting augmented location information. However,

these location updates are far less frequent than the RFID tag observatio ns, as only signi cantly

changed locations are published, e.g., staff member is in another room.

The dissemination of new context consists of two steps. First, lter rules are created by the application

components and registered with the Context Disseminator of the SCB. Howeve r, as lter rule

registrations only occur occasionally, the introduced delay is negligible. Se cond, context is published

to the SCB and matched with the lter rules. If a match is found, the context is for warded to the

appropriate application component. The publication of context information ha ppens frequently, as

illustrated by Table 2. As such, it is important that events are matched with lter r ules quickly and

ef ciently. When a cache miss occurs, the Context Disseminator has to reason on the information in the ontology

to match the published event to the registered lter rules. The performance o f ltering, matching and

forwarding an event with the SCB as a function of the number of lter rules in case of a cache miss,

is visualized in Figure 11. The lower and upper limits of the standard deviation a re [2.19, 10.28],

[2.58, 9.76] and [2.65, 10.07] when respectively 0%, 50% and 100% of the lter rules match with the

published event. The graph shows that the processing time is linear in terms of the amount of lter rules

and that the in uence of the percentage of lter rules that match the event is negligible. Note that for the

described scenario, which contains at most 4 lter rules, an event is pro cessed in on average 82.67 ms.

However, the performance quickly decreases. For 50 lter rules, it tak es on average 1 second to process

an event if a cache miss occurs.

Figure 11 Average reasoning time as a function of the number of lte r rules.This graph visualizes

the average reasoning time (y-axis in milliseconds (ms)) needed to publish, lte r and forward one event

as a function of the number of lter rules (x-axis) and the percentage of lter rules that match with this

event, averaged over 30 iterations in case a cache miss occurs. The dar k blue, orange and light blue line

indicate that 0%, 50% and 100% of the lter rules match with the published event respectively.

It can be derived from Table 2, that every second all the sensors willoutput a new observation. In order

to keep up with the publishing rate of the sensors (throughput), it is thus impor tant that the SCB can

process one event of each sensor in less than a second. Figure 12 vis ualizes the number of events that can

be ltered per second by one instance of the SCB as a function of the numbe r of lter rules in case none

of these events are present in the cache. This means that the Context Diss eminator will have to reason

on the ontology to lter, match and forward these events to the correct applic ation components. Note

that the number of events on the y-axis is limited to those events which have been completely processed

within the time limit, i.e., 1 second. Partially processed events are not considered . The graph shows that

for the described scenario, which contains at most 4 lter rules, at most 1 5 events can be processed. If

this result is mapped on the sensors in Table 2, this means that the SCB can pro cess the events of 11

sensors of the simulated department, namely the events of 1 staff member (carr ying an RFID tag) and 2

rooms (each tted with 1 light, 1 temperature and 1 humidity sensor) with 2 patients in each room (each

carrying an RFID tag and a body temperature sensor).

Figure 12 Number of events processed per second as a function of the number of lter rules.This

graph visualizes the number of events that can be ltered per second (y- axis) by one instance of the

SCB as a function of the number of lter rules (x-axis) in case none of thes e events are present in the

ache. This means that the Context Disseminator will have to reason on the onto logy to lter, match and

forward these events to the correct application components. An event is o nly counted when it has been

completely processed and forwarded. The dark blue, orange and light blue line indicate that 0%, 50%

and 100% of the lter rules match with the published events respectively.

To enhance these performance results, three measures can be taken. F irst, the cache can be used. If the

published event is present in the cache, a cache hit occurs and no rea soning needs to be performed to

process the event and forward it to the appropriate application componen ts. As the cache is implemented

using LRFU, looking up whether an event is present in the cache and, in c ase of a cache hit, getting the

lter rules and thus the application components to which the event should be fo rwarded can be performed

with a worst-case performance of O(log n), where n is the number of entrie s in the cache [79]. Moreover,

replacing an entry in the cache with a new entry in case of a cache miss also ha s a worst-case performance

of O(log n). Consequently, looking up an entry in the cache performs much better than the reasoning

that needs to be performed by the SCB when a cache miss occurs. It need s to be noted that the entries

in the cache will become invalid when a new lter rule is added to the SCB as it is po ssible that the

events already present in the cache now also match on this new lter rule. To resolve this issue, all the

entries in the cache are agged. When a cache hit occurs for a agged entry, the Context Disseminator will perform the reasoning step, update the value in the cache and remove the ag. This way the whole

cache will eventually be updated, either by performing reasoning or beca use agged entries are replaced

by new entries. To further speed up the runtime performance of the SCB, th e cache could be lled with

representative events during start-up. For example, the cache could be lled with room temperature

events between 18 and 22

Celsius, as these are the most common room temperature values. However,

this will signi cantly increase the start-up time of the platform and might only be a g ood choice when

the lter rules do not change often.

As a second measure, the framework can be distributed. As explained in the Flexible and semantic

publish/subscribe mechanism Section, two approaches can be used, namely replicating the SCB or

distributing the lter rules across multiple instances of the SCB. A combination of b oth can also be

used to ensure scalability as well as tolerance against faulty SCB instances . The choice of the

distribution approach depends on the speci c use case scenario. For u se cases where the number of

published events is high compared to the number of lter rules, the rst appr oach is more suitable. As

illustrated by Table 2, the use case presented in this paper falls into this catego ry. A lot of events are

published on the SCB, but only 4 lter rules are registered. The rst app roach is thus a good choice. As

mentioned previously, this can be achieved by using the persistent team app roach. The only parameter

of this approach, is the minimum number of times R that the SCB should be replicated . To achieve a

scalable deployment for the use case under scrutiny, R is set equal to the number of rooms, i.e., 20. As

an SCB instance with 4 lter rules is able to process 15 events per second, th e availability of at least 20

SCB instances guarantees that the 3 environment observations measured by the TMote Sky and the 4

patient observations, namely the location and temperature of the two patients, in each room per second

can be ef ciently processed. It also leaves enough processing powe r to process the location

observations of the staff members and to allow the registration of additional co ntext-dependent lter

rules. In contrast, the second approach or the combination of both appro aches is a better choice for use

case scenarios with a lot of lter rules compared to the number of published e vents. Next to the

parameter R, specifying the number of SCB instances that should be create d, this approach also

requires a speci cation of how the lter rules should be distributed across these instances. A simple

algorithm consists of distributing the lter rules so that each instance of the SC B contains

approximately the same amount of lter rules. This ensures that each instanc e of the SCB has a

comparable performance.

Furthermore, it has been shown by the authors [59] that the performance of the SCB depends

signi cantly on the complexity of the used core ontologies. It is therefore impo rtant to nd a good

balance between the desired throughput and the intelligence of the SCB, i.e., the expressiveness of the

core ontologies and accompanying lter rules.

By balancing the expressivity of the core ontologies and the desired throu ghput, employing caches and

distributing the SCB according to the speci cs of the use case, the develope d platform supports the

realization of a plethora of healthcare scenarios in an ef cient and scala ble way.

To ensure the correctness of the lter rules it is important to continuously ev aluate the platform with

the domain experts, both during the development process and after the sys tem has been deployed.

Domain experts were constantly involved during the design and development o f the continuous care

ontologies, OCarePlatform and used application components to make sure the system correctly re ects

the continuous work processes of the caregivers. Observations wer e performed to investigate which

information is taken into account to perform a certain task or make a decision. A participatory

methodology was used to develop the ontology and the accompanying algorithms . Moreover, the

developed system has been thoroughly evaluated with the various stakeho lders by allowing them to

play scenarios in PRoF. If the system gets deployed, techniques can also be used to continuously monitor and improve the correctness. For example, situations can be examinedin which the decision of

the platform was overruled by the users and intermediate feedback can be gathered.

The user tests resulted in a considerable amount of feedback. However , the feedback mostly pertained

to the user interface of the mobile nurse call application and the employed nurs e call algorithm. No

comments were made about missed or unnecessary calls, wrong light levels o r the performance of the

system. The ambient intelligence of the room, e.g., adjusting the lights or the tempera ture, was almost

never overruled. Similarly, the calls that are automatically launched based on the context, were found

interesting most of the time. However, the nurse that is assigned to the call was sometimes changed or

overruled. It is sometimes dif cult to assess whether a nurse is available to a ddress a particular call,

because it is dif cult to assess what their current task is. The nurse ca ll algorithm was then adapted to

deal with this issue, by allowing caregivers to indicate that the call should be redirected. The system then

nds another suitable nurse based on the current context information. T his algorithm is more thoroughly

described in Ongenae, et al. [63].

Note that the described application components of the OCarePlatform only ad just the ambient intelligent

devices, e.g., lights or radiators, or alert the caregiver of abnormal situ ations or measurements. The

EHR of the patient is not adjusted by the components. A lot of user resistanc e was met in the fact that

the system would automatically feed or adapt the EHR of the patient. The careg ivers felt that human

assessment is always needed of the alerts to assess their validity, as it is dif cult for the system to capture

all the small nuances of a situation that the caregivers are sensitive to bec ause of their experience and

everyday interaction with the patients. Therefore, it was chosen to leave th e responsibility in the hands

of the caregivers to assess whether the system made the right conclusion . This feedback about the

correctness of the alert can be inserted by the caregivers on the mobile a pplication. The caregiver can

then choose to add the alerted information to the clinical record of the patient h im- or herself. The latter

could be easily automated by providing the caregiver with a button on the mobile a pplications that allows

inserting the alerted information to the EHR. As we already map the EHR to the ontolo gy, implementing

the fact that information derived by the ontology should be inserted in the EH R is straightforward.

Future work on the continuous care ontology will focus on two things. First, it will be investigated

how the ontology can be aligned with the Semantic Sensor Network Ontology (SS N) [81], which was

constructed by the Semantic Sensor Network W3C Incubator Group [82]. Second, the ontology will

be extended with new parts to support speci c continuous care application domains, e.g., fall detection

or activity recognition. Future work on the OCarePlatform will concentrate on providing tools and

methodologies that allow developers to easily develop new services or adap t the algorithms in already

existing services. Techniques will also be researched to combine the even t-driven OCarePlatform with

more request-driven work ow composition and execution platforms.

Conclusions

In this article, a context-aware and pervasive framework was presente d, capable of disseminating and

ltering important care-related data of the different technologies available in an ambient-aware patient

room towards a multitude of care applications, based on their information requ irements. To realize this

goal, the framework employs continuous care ontologies, which capture the information and

knowledge being exchanged and utilized within healthcare settings. The app lications can register,

adapt and remove semantic lter rules on the y to receive context informatio n that is important to

them at that moment. This way, the amount of data which needs to be processe d by the applications is

signi cantly reduced, which improves their performance and decreases overhead while maintaining an

individualized approach. It was shown that the delay introduced by the context dissemination and ltering component is linear in

the amount of lter rules and is negligible when 10 or less lter rules are regis tered. The performance

of the platform can be signi cantly increased by employing a cache and by d istributing the reasoning on

the lter rules. The latter is achieved by replicating the context dissemination an d ltering component

or by distributing the lter rules across different instances of this compone nt. A combination of both

approaches can also be used. Moreover, the platform supports the co mposition of complex applications

from a set of smaller applications in a loosely coupled manner. The simple applic ations perform speci c

reasoning tasks in parallel and notify their conclusions to other applications , which have expressed an

interest in this kind of information.

Abbreviations

ACCIO: Ambient-aware provisioning of Continuous Care for Intra-muros O rganizations; AMD:

Advanced Micro Devices; CMF: Context Managing Framework; CMSANS : Context Management

Service with an Awareness and Noti cation Service; CoBrA: Context Bro ker Architecture; CPU:

Central Processing Unit; DL: Description Logics; EHR: Electronic Health R ecord; EPR: Electronic

Patient Record; ERMHAN: Emilia Romagna Mobile Health Assistance Network; F DD: Fault

Detection and Diagnosis; GB: Gigabyte; LFU: Least-Frequently Used; LR FU: Least

Recently/Frequently Used; LRU: Least Recently Used; MHz: megahertz; OCarePlatform:

Ontology-based Care Platform; oNCS: ontology-based Nurse Call Syste m; OWL: Ontology Web

Language; OWL-API: Ontology Web Language Application Programming In terface; PRoF: Patient

Room of the Future; QoC-aware: Quality of Context-aware; RAM: Rando m-Access Memory; RDF:

Resource Description Framework; RFID: Radio-Frequency IDenti ca tion; SCB: Semantic

Communication Bus; SOA: Service-Oriented Architecture; SOCAM: Serive -Oriented Context-Aware

Middleware; SWRL: Semantic Web Rule Language; WSN: Wireless Sensor N etwork.

Competing interests

The authors declare that they have no competing interests

Authors' contributions

FO carried out the study, developed the healthcare applications and ontolo gies described in this paper

and drafted the manuscript. JF and SL participated in the development of the S emantic communication

Bus and helped with the evaluation. SD, SV and AA participated in the case stud y and development of

the ontologies. SV was also involved in the evaluation. PV and FDT supervise d the study, participated

in its design and coordination and helped to draft the manuscript. All authors read and approved the

nal manuscript.

Acknowledgements

We would like to acknowledge that part of this research was supported by the iMinds Project ACCIO

co-funded by the IWT, iMinds and the following partners: Televic NV, Boo ne NV, Dominiek Savio

Instituut and In-Ham. Part of this research was performed in the PRoF1.0 demo room, which was

realized in Poperinge, Belgium by the PRoF consortium in 2010. F. Ongena e and J. Famaey would

like to thank the IWT for nancial support through their Ph.D. grant. S. La tré is funded by the Fund

for Scienti c Research Flanders (FWO-Vlaanderen). We thank all the p articipants in ACCIO for their

valuable contribution to the project. References1. Orwat C, Graefe A, Faulwasser T: Towards pervasive computing in health care - A literature

review. BMC Med Inform Decis Mak 2008,8(26):18.

2. Tentori M, Segura D, Favela J: Chapter VIII: monitoring hospital patients using ambient

displays. InMobile Health Solutions for Biomedical Applications ,Volume 1 , 1st edition. Edited

by Olla P, Tan J. Hershey, New York: Medical Information Science Refe rence; 2009:143–158.

3. Burgelman JC, Punie Y: Chapter II: information, society and technology. InTrue Visions: The

Emergence of Ambient Intelligence ,Volume 1 , 1st edition. Edited by Aarts EHL, Encarnacao JL.

Berlin/Heidelberg, Germany: Springer; 2006:17–35.

4. The ACCIO Project 2012. [http://www.ibbt.be/en/projects/overview-projects/p/detail/accio-2]

5. Punie Y: The future of ambient intelligence in Europe: the need for more ever yday life.

Communication and Stratégies 2005,57:141–165.

6. Gruber TR: A translation approach to portable ontologies. Knowl Acquis1993,5(2):199–220.

7. Dey AK, Abowd GD: Towards a better understanding of context and context-aware ness.

In Proceedings of the CHI Workskhop on the What, Who, Where, When and How of Context-

Awareness: 1–6 April 2000; The Hague, The Netherlands. Edited by Morse DR, Dey AK. New

York: ACM Press; 2000.

8. Byun H, Cheverst K: Utilizing context history to provide dynamic adaptations. Appl Artif Intell

2004, 18(6):533–548.

9. Hong J, Suh E, Kim S: Context-aware systems: a literature review and classi cation. Expert

Syst Appl 2009,36(4):8509–8522.

10. Baldauf M, Dustdar S, Rosenberg F: A survey on context-aware systems.Int J Ad Hoc Ubiquitous

Comput 2007,2(4):263–277.

11. Xue W, Pung HK: Chapter 8: context-aware middleware for supporting mobile applica tions

and services. InHandbook of Mobile Systems Applications and Services ,Volume 1 , 1st edition.

Edited by Kamur A, Xie B. Florida: CRC Press; 2012:269–304.

12. Dey AK, Salber D, Abowd GD: A conceptual framework and a toolkit for supporting the rapid

prototyping of context-aware applications. Hum Comput Interact J, Special Issue on Context-

aware Computing 2001,16(2–4):97–166.

13. Strang T, Linnhoff-Popien C: A context modeling survey.InProceedings of the 6th International

Conference on Ubiquitous Computing (UbiComp), Workshop on Advance d Context Modelling,

Reasoning and Management: 7 September 2004; Nottingham, UK. Edited by Indulska J, Roure

DD. New York: ACM; 2004:31–41.

14. Gu T, Pung HK, Zhang DQ: A service-oriented middleware for building context-aware services .

J Netw Comput Appl 2005,28:1–18.

15. Chen H: An intelligent broker architecture for pervasive context-aware systems.PhD thesis ,

University of Maryland, Baltimore County 2004.

16. Korpipää P, Mantyjarvi J, Kela J, Keranen H, Malm EJ: Managing context information in mobile

devices. IEEE Pervasive Comput 2003,2(3):42–51. 17. Santos LOBS, Wijnen RP, Vink P:A service-oriented middleware for context-aware

applications. InProceedings of the 5th International Workshop on Middleware for Perva sive and

Ad hoc Computing: 26–30 November 2007; Newport Beach, Orange C ounty, CA, USA.New York:

ACM Press; 2007:37–42.

18. Kim E, Choi J: A context-awareness middleware based on service-oriented arch itecture.In

Proceedings of the 4th International Conference on Ubiquitous Intelligenc e and Computing: 11–

13 July 2007; Hong Kong, China. Edited by Indulska J, Ma J, Yang LT, Ungerer T, Cao J.

Berlin/Heidelberg: Springer; 2007:953–962.

19. Román M, Hess C, Cerqueira R, Campbell RH, Nahrstedt K: Gaia: a middleware infrastructure

to enable active spaces. IEEE Pervasive Comput2002,1:74–83.

20. McGuinnes DL, Van Harmelen F: OWL Web Ontology Language overview. W3C Recomm2004.

[http://www.w3.org/TR/2004/REC-owl-features-20040210]

21. Baader F, Calvanese D, McGuinness DL, Nardi D, Patel-Schneide r P:The Description Logic

Handbook: Theory, Implementation and Applications. Cambridge: Cambridge University Press;

2003.

22. Sirin E, Parsia B, Grau BC, Kalyanpur A, Katz Y: Pellet: a practical OWL-DL reasoner.J Web

Semant Sci Serv Agents World Wide Web 2007,5(2):51–53.

23. Motik B, Shearer R, Horrocks I: Hypertableau reasoning for description logics. J Artif Intell Res

2009, 36:165–228.

24. Horrocks I, Patel-Schneider PF, Boley H, Tabet S, Grosof B, De an M:SWRL: A Semantic Web

Rule Language combining OWL and RuleML. W3C Member Submission2004. [http://www.w3.

org/Submission/SWRL/]

25. Carroll JJ, Dickinson I, Dollin C, Reynolds D, Seaborne A, Wilkinson K:Jena: implementing the

semantic web recommendations. InProceediungs of the 13th international Conference on World

Wide Web (WWW) - Alternate Track Papers & Posters: May 17–20 2004; N ew York, NY, USA.

Edited by Feldman S, Uretsky M, Najork M, Wills C. New York: ACM; 2004:74– 83.

26. Bricon-Souf N, Newman CR: Context awareness in health care: a review. Int J Med Informat

2007, 76:2–12.

27. Varshney U: Chapter 11: context-awareness in healthcare. InPervasive Healthcare Computing:

EMR/EHR, Wireless and Health Monitoring , 1st edition. New York: Springer Science + Business

Media, LLC; 2009:231–257.

28. Bardram J: Applications of context-aware computing in hospital work - Example s and design

principles. InProceedings of the Annual ACM Symposium on Applied Computing: 14–17 March

2004; Nicosia, Cyprus. New York: ACM Press; 2004:1574–1579.

29. Skov MB, Hoegh RT: Supporting information access in a hospital ward by a context-awa re

mobile electronic patient record. Pers Ubiquitous Comput2006,10(4):205–214.

30. Mitchell S, Spiteri MD, Bates J, Coulouris G: Context-aware multimedia computing in the

intelligent hospital. InProceedings of the 9th Workshop on ACM SIGOPS European Workshop :

Beyond the PC: New Challenges for the Operating System: 17–20 Septembe r 2000; Kolding,

Denmark. New York: ACM; 2000:13–18.

31. Stanford V: Beam me up, doctor McCoy. IEEE Pervasive Comput2003,2(3):13–18. 32. Muñoz MA, Rodríguez M, Favela J, Martinez-Garcia AI, González VM:Context-aware mobile

communication in hospitals. Computer2003,36(9):38–46.

33. Fishkin K, Wang M, Fishkin KP, Wang M: A exible, low-overhead ubiquitous system for

medication monitoring. Tech. rep., Intel Research Seattle, Technical Memo IRS-TR-03-011 2 003.

34. Floerkemeier C, Siegemund F: Improving the effectiveness of medical treatment with pervasi ve

computing technologies. InProceedings of the 2nd International Workshop on Ubiquitous

Computing for Pervasive Healthcare Applications at International Confere nce on Ubiquitous

Intelligence and Computing: 25 October 2003; Seattle, Washington, USA. New York: ACM; 2003.

35. Korhonen I, Paavilainen P, Särelä A: Application of ubiquitous computing technologies for

support of independent living of the elderly in real life settings. InProceedings of the

2nd International Workshop on Ubiquitous Computing for Pervasive Health care Applications at

International Conference on Ubiquitous Intelligence and Computing: 25 Oc tober 2003; Seattle,

Washington, USA. New York: ACM; 2003.

36. Mihailidis A, Carmichael B, Boger J, Fernie G: An intelligent environment to support aging-

in-place, safety, and independence of older adults with dementia. InProceedings of the

2nd International Workshop on Ubiquitous Computing for Pervasive Health care Applications at

International Conference on Ubiquitous Intelligence and Computing: 25 Oc tober 2003; Seattle,

Washington, USA. New York: ACM; 2003.

37. de Toledo P, Jimenez S, del Pozo F, Roca J, Alonso A, Hernandez C :Telemedicine experience for

chronic care in COPD. IEEE Trans Inform Tech Biomed 2006,10(3):567–573.

38. Hu B, Hu B, Wan J, Dennis M, Chen HH, Li L, Zhou Q: Ontology-based ubiquitous monitoring

and treatment against depression. Wireless Comm Mobile Comput2010,10(10):1303–1319.

39. Suzuki T, Doi M: LifeMinder: an evidence-based wearable healthcare assistant. InProceedings

of the ACM Conference on Human Factors in Computing Systems: 31 March - 5 April 2001; Seattle,

Washington, USA. Edited by Beaudouin-Lafon M, Jacob RJK. New York: ACM; 2001:127– 128.

40. Jansen B, Deklerck R: Context aware inactivity recognition for visual fall detection. In

Proceedings of the Pervasive Health Conference and Workshops: Nov ember 29 2006; Innsbruck,

Austria. Piscataway: IEEE; 2006:1–4.

41. Fook VFS, Tay SC, Jayachandran M, Biswas J, Zhang D: An Ontology-based context model in

monitoring and handling agitation behaviour for persons with dement ia.InProceedings of the

4th IEEE International Conference on Pervasive Computing and Commun unications Workshops

(PERCOMW): 13–17 March 2006; Pisa, Italy. Washington: IEEE Computer Society; 2006:560–

564.

42. Zhang D, Yu Z, Chin CY: Context-aware infrastructure for personalized healthcare. Stud Health

Technol Inform 2005,117:154–163.

43. Paganelli F, Giuli D: An Ontology-based system for context-aware and con gurable se rvices to

support home-based continuous care. IEEE Trans Inf Technol Biomed2011,15(2):324–333.

44. Chin T: Technology valued, but implementing it into practice is slow. Am Med News2004.

[http://www.ama-assn.org/amednews/2004/01/19/bisb0119.htm]

45. Anderston J, Aydin C: Evaluating the impact of health care information systems. Int J Technol

Assess Health Care 1997,13(2):380–393. 46. Jahnke JH, Bychkov Y, Dahlem D, Kawasme L:Context-aware information services for health

care. InProceedings of the 27th German Conference on Arti cial Intelligence, Wo rkshop on

Modeling and Retrieval of Context (MRC): 20–21 September 2004; Ulm, Germany.Edited by Roth-

Berghofer T, Schulz S. Aachen: CEUR; 2004:73–84.

47. Ash J, Sittig D, Guappone K, Dykstra R, Richardson J, Wright A, Car penter J, McMullen C, Shapiro

M, Bunce A, Middleton B: Recommended practices for computerized clinical decision support

and knowledge management in community settings: a qualitative stu dy.BMC Med Inform

Decis Mak 2012,12:6.

48. Filali I, Bongiovanni F, Huet F, Baude F: A survey of structured P2P systems for RDF data

storage and retrieval. International Journal Transactions on Large-scale Data and Knowledg e-

Centered Systems III, Special Issue on Data and Knowledge Managem ent in Grid and P2P Systems.

2011, 6790:20–55.

49. Manola F, Miller E, McBride B: RDF primer.W3C Recomm 2004. [http://www.w3.org/TR/2004/

REC-rdf-primer-20040210/]

50. Valls A, Gibert K, Sánchez D, , Bateta M: Using ontologies for structuring organizational

knowledge in Home Care assistance. Int J Med Inform2010,79(5):370–387.

51. Ongenae F, De Backere F, Steurbaut K, Colpaert K, Kerckhove W, Decruyenaere J, De Turck F:

Appendix B: overview of the existing medical and natural language o ntologies which can be

used to support the trans-lation process. BMC Med Inform Decis Mak2011,10(3):4.

52. Rector AL, Rogers JE, Zanstra PE, van der Haring E: OpenGALEN: open source medical

terminology and tools. InProceedings of the annual American Medical Informatics Association

(AMIA) Symposium: 8–12 November 2003; Washington, DC, USA. American Medical Informatics

Association (AMIA); 2003:982. [http://www.opengalen.org/]

53. Blake JA, Harris MA: The Gene Ontology (GO) project: structured vocabularies for molecula r

biology and their application to genome and expression analysis. Curr Protoc Bioinformatics

2008, 23(7.2.1–7.2.9):1472–6947. [http://www.geneontology.org/]

54. Cornet R, de Keizer N: Forty years of SNOMED: a literature review. BMC Med Inform Decis

Mak 2008, 8:S1–S2.

55. Schulz S, Cornet R, Spackman K: Consolidating SNOMED CT's ontological commitment. Appl

Ontol 2011,6:1–11.

56. Wroe C: Is semantic web technology ready for Healthcare? InProceedings of the 3rd European

Semantic Web Conference (ESWC): 11–14 June 2006; Budva, Montene gro.Berlin/Heidelberg:

Springer; 2006.

57. Rodríguez MD, Tentori M, Favela J, Saldaña D, García JP: CARe: an ontology for representing

context of activity-aware healthcare environments. InProceedings of the AAAI Workshop on

Activity Context Representation: Techniques and Languages: 7–8 Augu st 2011; San Francisco,

CA, USA. Menlo Park: AAAI Press; 2011.

58. Famaey J, Latré S, Strassner J, De Turck F: An Ontology-driven semantic bus for autonomic

communication elements. InProceedings of the 5th International Workshop on Modelling

Autonomic Communication Environments (MACE): 28 October 2010; Niaga ra Falls, Canada.

Edited by Brennan R, Fleck J, van der Meer S. Berlin/Heidelberg: Springe r; 2010:37–50.

59. Famaey J, Latré S, Strassner J, De Turck F: Semantic context dissemination and service

matchmaking in future network management. Int J Netw Manag2011,22(4):285–310. 60. Mattson RL, Gecsei J, Slutz DR, Traiger IL:Evaluation techniques for storage hierarchies. IBM

Syst J 1970,9(2):78–117.

61. Cormen TH, Leiserson CE, Rivest RL, Stein C: Introduction to Algorithms.Cambridge: MIT Press;

2009.

62. Ongenae F, Bleumers L, Sulmon N, Verstraete M, Jacobs A, Van Gils M, Ackaert A, De Zutter S,

Verhoeve P, De Turck F: Participatory design of a continuous care Ontology: towards a user -

driven Ontology engineering methodology. InProceedings of the International Conference on

Knowledge Engineering and Ontology Development (KEOD): 26–29 Octo ber 2011; Paris, France.

Edited by Filipe J, Dietz JLG. Portugal: SciTePress Digital Library; 2011:81 –90.

63. Ongenae F, Duysburgh P, Verstraete M, Sulmon N, Bleumers L, Jaco bs A, Ackaert A, De

Zutter S, Verstichel S, De Turck F: User-driven design of a context-aware application: an

ambient-intelligent nurse call system. InProceedings of the User-Centered Design of Pervasive

Healthcare Applications Workshop (U-CDPHA) of the 6th International Co nference on Pervasive

Computing Technologies for Healthcare (PervasiveHealth): 21–24 May 2 012; San Diego, CA, USA.

Piscataway: IEEE; 2012:6.

64. O'Connor MJ, Das AK: A lightweight model for representing and reasoning with temporal

information in biomedical ontologies. InProceedings of the International Conference on Health

Informatics (HEALTHINF): 20–23 January 2010; Valencia, Spain. Edited by Fred ALN, Filipe J,

Gamboa H. Portugal: SciTePress Digital Library; 2010:90–97.

65. Verstichel S, De Poorter E, De Pauw T, Becue P, Volckaert B, De T urck F, Moerman I, Demeester P:

Distributed ontology-based monitoring on the IBBT WiLab.t infrastr ucture.InProceedings of

the 6th International Conference on Testbeds and Research Infrastruc tures for the Development

of Networks and Communities (TridentCom): 18–20 May 2010; Berlin, Ge rmany.Edited by

Magedanz T, Gavras A, Thanh NH, Chase JS. Berlin/Heidelberg, Germa ny: Springer; 2010:509–

525.

66. Verstichel S: The Wireless Sensor Network (WSN) Ontology 2010. [http://users.atlantis.ugent.

be/svrstich/deus/wsn.owl]

67. Martin D, Burstein M, Hobbs J, Lassila O, McDermott D, McIlraith S, Nar ayanan S, Paolucci M,

Parsia B, Payne T, Sirin E, Srinivasan N, Sycara K: OWL-S: semantic markup for web services.

W3C Member Submission 2004. [http://www.w3.org/Submission/OWL-S/]

68. Ongenae F, Myny D, Dhaene T, De oor T, Van Goubergen D, Ver hoeve P, Decruyenaere J, De

Turck F: An ontology-based nurse call management system (oNCS) with pro babilistic priority

assessment. BMC Health Serv Res 2011,11(26):28.

69. De Backere F, Ongenae F, Van den Abeele F, Hoebeke J, Verstich el S, ckaert A, De Turck F:Social-

aware and context-aware multi-sensor fall detection platform. InProceedings of the Workshop

on Semantic Web Applications and Tools for Life Sciences (SWAT4LS-2013) : 9–11 December 2013;

Edinburgh, Scotland. Aachen: CEUR-WS.org; 2013:4.

70. Van den Abeele F, Hoebeke J, De Backere F, Ongenae F, P Bonte S V, Carlier T, Crombez P,

De Gryse K, Danschotter S, Moerman I, De Turck F: OCareClouds: improving home care by

interconnecting elderly, care networks and their living environmen ts.InProceedings of the 8th

International Conference on Pervasive Computing Technologies for Hea lthcare (PervasiveHealth):

20–23 May 2014; Oldenburg, Germany. Piscataway: IEEE; 2014:2.

71. Kumar S, Cohen PR, Levesque HJ: The adaptive agent architecture: Achieving fault-tolerance

using persistent broker teams. InProceedings of the 4th International Conference on Multi-Agent Systems: 10–12 July 2000; Boston, MA, USA.Washington: IEEE Computer Society; 2000:159–

166.

72. Chen C, Tsai CL, Horng SJ: Exploiting attribute popularity distribution skew to enhance the

performance of peer to peer publish/subscribe systems. Int J Innovat Comput Inf Control2011,

7 (7):4047–4066.

73. Consortium TP: PRoF: Patient Room of the Future [http://www.prof-projects.com/]

74. Corporation M: TMote Sky datasheet 2006. [http://www.eecs.harvard.edu/~konrad/projects/

shimmer/references/tmote-sky-datasheet.pdf]

75. Ghent University hospital [http://www.healthcarebelgium.com/index.php?id=uzgent]

76. Knublauch TH, Fergerson RW, Noy NF, Musen MA: The Protégé OWL Plugin: an open

development environment for semantic web applications. InProceedings of the 3rd International

Semantic Web Conference: Nov 7–11 2004; Hiroshima, Japan. Edited by McIlraith SA, Plexousakis

D, van Harmelen F. Berlin/Heidelberg: Springer; 2004:229–243.

77. Stanford Center for Biomedical Informatics Research: The Protégé ontology editor[http://protege.

stanford.edu/]

78. Horridge M, Bechhofer S: The OWL API: a Java API for OWL Ontologies. Semantic Web

Journal, Special Issue on Semantic Web Tools and Systems 2011,2:11–21.

79. Lee D, Choi J, Kim JH, Noh SH, Min SL, Cho Y, Kim CS: LRFU: a spectrum of policies that

subsumes the least recently used and least frequently used policies .IEEE Trans Comput 2001,

50 (12):1352–1361.

80. Ma L, Yang Y, Qiu Z, Xie G, Pan Y, Liu S: Towards a complete OWL Ontology benchmark. In

Proceedings of the 3rd European Semantic Web Conference: 11–14 Ju ne 2006; Budva, Montenegro.

Edited by Sure Y, Domingue J. Berlin/Heidelberg: Springer; 2006:125–13 9.

81. W3C Semantic Sensor Network Incubator Group: Semantic Sensor Network Ontology2011.

[http://www.w3.org/2005/Incubator/ssn/ssnx/ssn]

82. Barnaghi P, Compton M, Corcho O, Castro RG, Graybeal J, Herzo g A, Janowicz K, Neuhaus H,

Nikolov A, Page K: Semantic sensor network XG nal report. W3C Incubator Group Rep2011.

[http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/] Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 BioMed

Centralpublishes undertheCreative Commons Attribution License(CCAL). Under

the

CCAL, authors retaincopyright tothe article butusers areallowed todownload, reprint,

distribute

and/orcopy articles inBioMed Centraljournals, aslong asthe original workis

properly

cited.