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.