PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY

Towards a User-driven Ontology Engineering Methodology

Femke Ongenae

, Lizzy Bleumers

, Nicky Sulmon

, Mathijs Verstraete

, Mieke Van Gils

An Jacobs

, Saar De Zutter

, Piet Verhoeve

, Ann Ackaert

and Filip De Turck

Information Technology Department (INTEC), Ghent University - IBBT, Gaston Crommenlaan 8, 9050 Ghent, Belgium

Research Centre for Studies on Media, Information and Telecommunication (SMIT), Brussels University (VUB) - IBBT

Pleinlaan 2, 1050 Brussels, Belgium

Centre for User Experience Research (CUO), K.U. Leuven - IBBT, Parkstraat 45, bus 3605, 3000 Leuven, Belgium

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

Keywords:

Ontology engineering, Participatory, User-driven, Continuous care, eHealth.

Abstract:

The patient room of the future would be able to sense the needs and preferences of the patients and nurses

and adapt itself accordingly by combining all the heterogeneous data offered by the different technologies.

This goal can be achieved by developing a context-aware framework, which exploits and integrates the hetero-

geneous data by utilizing a continuous care ontology. The existing ontology engineering methodologies are

rather extreme in their choices to include domain experts. On the one hand, there are methodologies that only

discuss the scope, use and requirements of the ontology with the domain experts. On the other hand, there

are approaches in which the ontology is completely constructed by the domain experts by providing them

with user-friendly and collaborative tools. In this paper, a participatory ontology engineering methodology

is presented that ﬁnds a middle ground between these two extremes. The methodology actively involves so-

cial scientists, ontology engineers and stakeholders. The stakeholders participate in each step of the ontology

life cycle without having to construct the ontology themselves or attribute a large amount of their time. The

applicability of the methodology is illustrated by presenting the co-created continuous care ontology.

1 INTRODUCTION

1.1 Background

The ambient intelligent care room of the future will

contain numerous devices that work together to sup-

port caregivers and residents in carrying out their ev-

eryday activities and tasks. The room will be able

to sense the needs and preferences of the occupants

and adapt itself accordingly by combining all the het-

erogeneous data offered by all the technology in the

room such as sensors, wireless devices and input from

caregivers given through multimodal interfaces, e.g.,

graphical user interfaces (GUIs) or speech recogni-

tion. However, nowadays the caregiver is responsible

for the coordination, management and consultation of

all these devices. The caregiver has to use several

sources and devices to consult data and to keep it up

to date even when carrying out a single task (Tentori

et al., 2009). This is a very time consuming job.

Consider, for example, a patient, who suffers from

a concussion, needs to be in a quiet and dark envi-

ronment to heal. Today, it is the nurse who needs to

conﬁgure the room to dim the lights each time he/she

enters. Moreover, the nurse is responsible for alerting

all the staff members and visitors that the room needs

to be quiet and dark. If the nurse presses the wrong

button or an uninformed person enters the room, this

can cause physical pain for the patient. However, if

the system would be aware of the patient’s and nurse’s

needs, namely darkness for the patient and sufﬁcient

light for the nurse to work, the system can automati-

cally turn on the light to the correct level when it de-

tects that the nurse enters the room. Moreover, the

system can display a message in the room or at the

entrance of the room, reminding visitors and staff to

keep the room dark and quiet.

The IBBT project ACCIO (Ambient aware pro-

visioning of Continuous Care for Intra-muros Orga-

nizations) (Ongenae and et al., 2010) aims to tackle

Ongenae F., Bleumers L., Sulmon N., Verstraete M., Van Gils M., Jacobs A., De Zutter S., Verhoeve P., Ackaert A. and De Turck F..

PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering Methodology.

DOI: 10.5220/0003654700810090

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (KEOD-2011), pages 81-90

ISBN: 978-989-8425-80-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

this problem by developing an intelligent, context-

aware framework, which exploits and integrates the

available heterogeneous data by utilizing an ontology

(Gruber, 1993). An ontology formally describes the

concepts in a domain, their attributes and their re-

lationships. It can also contain classiﬁcation rules,

which are used to express the business logic of an ap-

plication. This commonly agreed upon data-format

can then be used to exchange the data and its attached

domain model. In this way an ontology encourages

re-use, communication, collaboration and integration.

Thus, the ﬁrst step within the ACCIO project is

the development of an ontology to support the contin-

uous care of patients. This model has to contain infor-

mation about the proﬁle of the staff members and pa-

tients, which staff members are responsible for which

tasks, administrative information, etc.

However, the incorporation of ontology engi-

neering tasks in knowledge-empowered organizations

such as hospitals can prove to be very difﬁcult if not

done in a way that is seamless to the day-to-day activ-

ities of the organization members (Kotis and Vouros,

2006). To resolve this issue, a participatory onto-

logy engineering methodology is developed within

the ACCIO project, which co-creates the ontology to-

gether with the stakeholders, i.e., nurses, caregivers,

patients, doctors and professionals working for the

healthcare industry. The methodology thus includes

the stakeholders in every step of the design and devel-

opment process.

1.2 Related Work

Although ontologies are widely accepted within the

eHealth domain, most of these models focus on

biomedical research, e.g., Galen Common Reference

Model

or the Gene Ontology

. Little work has been

done on the development of ontologies to support the

continuous care of patients.

Well-known methodologies exist to construct an

ontology such as Tove, Enterprise and Methontology

(Pinto and Martins, 2004). However, these methodo-

logies emphasize the role of the knowledge engineer.

Domain experts are only involved during the speci-

ﬁcation phase. Moreover, no tools or methods are

discussed to empower the domain experts to actively

participate in the ontology life-cycle.

Recently, a human-centered approach (HCOME)

(Kotis and Vouros, 2006) has been proposed where

the active participation of domain experts is accentu-

ated. This approach offers user-friendly and collabo-

rative tools that allow the domain experts to construct

http://www.opengalen.org/index.html

http://www.geneontology.org/

and discuss their own ontologies. The knowledge en-

gineer only delivers (technical) support.

It can be noted that the current methodologies are

rather extreme in their choice to involve domain ex-

perts in the ontology life-cycle. Within the ACCIO

project, a methodology is developed that holds a mid-

dle ground between these two extremes. It promotes

user participation while taking into account that time

is a valuable resource within the eHealth domain. The

methodology actively involves social scientists, onto-

logy engineers and stakeholders, i.e., nurses, care-

givers, patients, doctors and professionals working

for the healthcare industry, in the ontology engineer-

ing process. Moreover, the methodology acknowl-

edges that domain experts are no ontology engineers

as such, or vice versa. The stakeholders participate in

each step of the life cycle of the ontology without hav-

ing to construct the ontology themselves or attribute a

large amount of their time.

1.3 Objective & Paper Organization

The goal of this paper is twofold. On one hand, the

ﬁrst steps towards a participatory ontology engineer-

ing methodology are described. On the other hand,

the continuous care ontology, which resulted from ap-

plying the methodology, is presented.

The remainder of this paper is organized as fol-

lows. Section 2 describes the various user-driven me-

thodologies and techniques used and evaluated for

building an ontology. In Section 3, the developed

continuous care ontology is discussed. Section 4 de-

scribes the lessons learned during the development of

the methodology. Finally, the most important conclu-

sions and future work are described in Section 5.

2 ONTOLOGY CO-CREATION

METHODOLOGY

There are ﬁve widely accepted stages for building an

ontology (Pinto and Martins, 2004):

• Speciﬁcation: identify the scope and requirements

• Conceptualization: construct a conceptual model

• Formalization: translate the conceptual model

into a formal model

• Implementation: implement the formal model in a

knowledge representation language

• Maintenance: continuously evaluate and update

the ontology to reﬂect changes in the domain

The following subsections describe the user-driven

and participatory methodologies that were used and

evaluated (Bleumers and et al., 2011) within the

ACCIO project to achieve the goals of these stages.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

2.1 Speciﬁcation: Observations and

Scenario Description

To achieve a grounded, user-centered design process,

the speciﬁcation stage starts with creating a represen-

tative stakeholder group. Two major institutionalized

continuous care settings were identiﬁed, namely res-

idential (focus on care) and hospital care (focus on

cure). A representative Flemish institution from each

category closely collaborated in the project, namely

Dominiek Savio Institute, which provides residential

care to people suffering from cognitive and phys-

ical impairments, and OLV Hospital Aalst. Staff

from other institutions and professionals working for

the healthcare industry, e.g., Boone NV, a furnishing

company, and Televic Healthcare NV, a nurse call sys-

tem company, were also included in the stakeholder

group.

Next, a hands-on workshop was organized in

which the members of the project (i.e., the stakehol-

ders most closely involved in the co-creation of the

ontology), learned what ontology means and what

ontology engineering entails, both from a social and

a computer science perspective. A simple ontology

was constructed through a series of exercises. More-

over, the workshop also aimed to generate discussion

amongst the stakeholders on how a participatory onto-

logy engineering methodology could be achieved.

This is an essential step in interdisciplinary research

and co-creation processes as the group diversity and

the background knowledge is very different. A ﬁrst

essential step is learning to understand each other, so

a better integration of concepts and views can be ini-

tiated in the subsequent development steps.

To get a clear picture of the scenarios in which an

ontology-based, context-aware platform can optimize

the provision of continuous care, observations were

performed in the two collaborating institutions. The

current daily practices were observed, e.g., helping a

resident go to the toilet, giving medicine to a patient

and communicating the status of a patient/resident

with other staff members. Additionally, selected staff

members, patients and residents were interviewed and

logging data from the available systems, e.g., nurse

call systems, were analyzed.

The observations were performed by the social

scientists together with ontology engineers. All these

observations were systematically represented in mind

maps

. An example is shown in Figure 1. These mind

maps were also evaluated and validated with different

stakeholders from the institutions, who were not nec-

essarily involved in the observations.

http://www.xmind.net/

Figure 1: Example mind map, summarizing the observa-

tions at Dominiek Savio Institute.

By iterating these mind maps, a clear view of the

current continuous care practices and two major areas

for improvement were identiﬁed, namely information

integration & data provisioning at the point of care

and an intelligent & dynamic nurse call system. The

ﬁrst area can be summarized as providing the right in-

formation at the right time, at the right place for the

right person. This requires an increased need for mo-

bile services to support data input, e.g.; care registra-

tion, and requested, e.g., medical data about patients,

at the point of care. Moreover, information should

be integrated, prioritized and ﬁltered based on con-

textual information. Examples of this include only

monitoring values that violate a threshold or only dis-

playing recent information that pertains to the patient

a staff member is currently caring for.

An intelligent nurse call system should use the in-

tegrated information about the staff and patients/res-

idents to ﬁnd the most appropriate staff member to

handle a request of care from a patient/resident and at

the same time optimize the current workﬂow in a dy-

namic way. The current nurse call systems are mainly

lacking the ability to adapt, to give feedback to the

patient/resident and to give an overview of the current

situation, e.g., localization of patients and staff.

To get a clearer view of all the information be-

ing exchanged during the continuous care practices,

a document workﬂow was constructed. It outlines all

documents (analog or digital) and formats of commu-

nication used during the care for patients/residents.

The document workﬂow also describes the proper-

ties of the documents, such as the content, the speciﬁc

aim, the author(s), the target audience, the storage lo-

cation and the relationships to other documents.

As a ﬁnal step in the speciﬁcation stage, a sunny-

PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering

Methodology

day scenario was constructed. A scenario is a short

story that describes the hypothetical use of a system

to help develop a detailed and shared understanding

of the context and activities of the users. In this case,

the scenario describes the story of a resident of a resi-

dential care setting who becomes unwell and is trans-

ported to a hospital for treatment. Both the care for

the resident in the residential care setting and the hos-

pital are supported by the ontology-based, context-

aware, continuous care system under development.

The scenario is sunny-day because it is an ideal sce-

nario in which the technology, e.g., the context-aware

system, the sensors and actuators, optimally supports

the needs of the users and the context, unconstrained

by the current technological possibilities.

The scenario starts with the description of the var-

ious personas (Pruitt and Adlin, 2006). Personas are

used to represent a particular user archetype of the

software and include a name, a picture and demo-

graphic information. Personas communicate common

attitudes, desires, behaviors and frustrations for a par-

ticular user group. Their main advantage is that they

allow feeling real empathy for the user group, as they

put a human face to a list of requirements. The sce-

nario and accompanying personas, allowed the onto-

logy engineers to keep in mind the various user groups

whose information, requirements, activities and con-

text should be represented in the ontology.

To summarize, the proposed user-driven speciﬁca-

tion stage consists of:

• Composing a representative stakeholder group.

• Creating better knowledge of each other’s ﬁeld of

expertise through a hands-on workshop compris-

ing of a basic and comprehensive exercise.

• Performing observations.

• Analyzing and iterating the observations with the

stakeholders, identifying areas where ICT can

support and improve the current work processes.

• Deﬁning the scope and requirements of the onto-

logy by creating a sunny-day scenario.

• Iterating the sunny-day scenario with the stake-

holders.

2.2 Conceptualization: Role-play

Co-design Workshop

The two observed continuous care settings, namely

Dominiek Savio Institute and OLV Hospital Aalst, are

rather different, but the aim is to construct an onto-

logy that can be used to build a context-aware plat-

form, which supports and optimizes the continuous

care practices in both settings. Moreover, the onto-

logy should not only be applicable to the two spe-

ciﬁc settings studied during the observations. On one

Figure 2: Role-play workshop at the PRoF1.0 room.

hand, the ontology should be abstract enough to be

applied to all continuous care settings, while on the

other hand it should remain speciﬁc enough to build

practical applications on it. Therefore, it is important

to identify the high-level concepts that are used with

the same meaning within the continuous care domain

and model them in a high-level ontology.

To achieve this goal a role-play co-design work-

shop was organized in the Patient Room of the Fu-

ture (PRoF) 1.0 demo room

. Members from all

stakeholder groups, e.g., caregivers and profession-

als working for the healthcare industry, participated

in the workshop. The users were represented by both

management and caregivers from different healthcare

settings. A simpliﬁed, ﬁrst version of the sunny-day

scenario was visualized in a storyboard and used as

central discussion point throughout the workshop, as

can be seen in the top left corner of Figure 2. Par-

ticipants took turns to play out the scenario in the

PRoF1.0 room. Each participant received a persona

card describing the character of the person they would

be playing, e.g., an experienced nurse or an anxious

patient. They also received a card describing the sit-

uational context of this speciﬁc scenario, e.g., patient

has fallen out of bed during the night. The stakehol-

ders not participating in the role-play, watched the

scenario being played out on a TV outside the room

and wrote down observations and comments, as visu-

alized in the top left of Figure 2. After each role-play,

a discussion was held amongst all the stakeholders.

The discussion points were visualized on the story-

board by adding post-its and drawings of perceived

problems, e.g., difﬁcult for patient to alert a nurse, and

opportunities, e.g., automatic fall detection, as visual-

ized on the right of Figure 2.

Simultaneously, two ontology engineers followed

the role-playing and discussions from the back-

http://www.prof-projects.com/en/index.html

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

Sensor Ontology

Upper Ontology

LightSensor

Medical Ontology

Actuator

Light

Process/Task Ontology

Process

PlannedProcess UnplannedProcess Call

SanitaryCall NormalCall

Task

Person, Role, Competence Ontology

Door

System

Event

Person

Competence

Role

Entity

ownsDevice

Temporal Ontology

Granularity

ValidTime

ValidInstant ValidPeriod

hasValidTime

executedBy

currentTask

hasPathology

Pathology

Priority

hasPriority

Status

Active BusyFinished Present

hasStatus

Parameter

BodyTemperature

hasParameter

hasCompetence

consistsOf

hasFirstTask

nextTask

Precondition

Postcondition

hasPrecondition

hasPostcondition

Sensor

SpeechRecognition

Call

Button

DoorSensor

FallDetection

xsd:string

hasUnit

xsd:double

hasValue

xsd:string

hasUnit

xsd:double

hasValue

IndicationLight

triggers

usedIn

uses

controls

Caretaker

Nurse

Doctor

Patient

GiveMedication

AnswerNormalCall

executedOn

TodoTasks

xsd:string

hasName

xsd:string

hasSex

hasCurrentRole?

hasRole?

hasCompetence

xsd:date

Has

BirthDate

BloodPressure

xsd:string

hasUnit

hasValue

xsd:double

Diabetes

Examination

Treatment

equivalent

Message

Characteristic

Wish RiskProfile

VegetarianImpatientAgressive MedicalRiskBehavioralRisk

Nationality

Faith

Language

hasNationality

hasFaith

hasLanguage

hasCharacteristic

hasWish

hasRiskProfile

hasProxy

isValidIn

IsValidIn

Device

PDA

Bedside PC

GSM

Portable

Phone

Location

hasLocation

hasLocationhasLocation

ZoneCoordinate

Note: Everything has a timestamp

(by using the concept ValidInstant) or

a period wherein it is valid (by using

the concept ValidPeriod)

needsCompetence

Figure 3: The high-level ontology resulting from the role-play co-design workshop at the PRoF1.0 demo room.

ground, translating it to concepts and relations drawn

as a graph on paper, as visualized in the bottom

left corner of Figure 2. Intermittently, this high-level

ontology was shown to the stakeholders for feedback.

The workshop resulted in a new iteration of the

sunny-day scenario taking into account the feedback

of the stakeholders and a ﬁrst version of the high-level

ontology, which is illustrated in Figure 3. As can be

seen, 6 major sub-domains were identiﬁed, namely

information pertaining to tasks & processes, to per-

son proﬁles, roles & competences, to medical context,

to sensor observations, to temporal information and

to general upper concepts. The most important con-

cepts within these sub-domains were identiﬁed (69

concepts in total). This allowed the ontology engi-

neers to integrate the information obtained during the

speciﬁcation stage in this ontology, based on the mind

maps and document workﬂow.

Based on this ontology, an investigation of ex-

isting ontologies was performed to evaluate if these

could be re-used. The existing ontologies, which

were found suitable, were imported. These included

the Wireless Sensor Network (WSN) ontology (Ver-

stichel and et al., 2010), the OWL-S Process onto-

logy

and the SWRLTemporalOntology

As mentioned previously, the two settings under

scrutiny during the observations are quite different.

The major difference between the two is that resi-

dential care settings focus more on care, while hos-

pitals focus more on curing the patients. Therefore, it

was decided to conceptualize two low-level ontolo-

gies, containing concepts speciﬁc to these settings.

http://www.w3.org/Submission/OWL-S/

http://protege.cim3.net/cgi-bin/wiki.pl?

SWRLTemporalOntology

These low-level concepts are always subconcepts of

concepts in the high-level ontology.

The low-level ontologies were constructed by an-

alyzing the document workﬂows and mind maps and

extracting concepts such as roles, competences, tasks

(care acts) and proﬁles. The two resulting low-level

ontologies were compared to identify common con-

cepts used within both settings with the same mean-

ing. These concepts were moved to the high-level

ontology. The resulting ontologies are discussed in

Section 3.

To summarize, the proposed user-driven concep-

tualization stage consists of:

• Performing one or more role-playing workshops

based on the sunny-day scenario to deﬁne the

high-level concepts for the ontology, making sure

all stakeholders are represented in the workshop

• Mapping the high-level ontology on existing, re-

usable ontologies.

• Extracting low-level concepts by studying the re-

sults from the observations, propagating concepts

used in all settings to the high-level ontology.

• Updating the sunny-day scenario with the feed-

back of the stakeholders obtained during the role-

playing workshops.

2.3 Formalization: Decision-tree

Co-design Workshop

In this stage, the conceptual description developed in

the previous stage is transformed into a formal model.

This means that the concepts are deﬁned through ax-

ioms that restrict the possible interpretations for the

meaning of those concepts, e.g., deﬁning which com-

petences a certain role has, which competences are

PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering

Methodology

Figure 4: Decision-tree workshop: scenario is visualized on

a layout and high-level concepts, derived from the requested

information, are summarized in a decision tree.

needed to perform a task or which sensor observa-

tions are valid. A lot of these restrictions were derived

from the data extracted during the observations or

the sunny-day scenario discussions. However, there

were still some gaps in the ontology pertaining to the

way care requests or nurse calls are prioritized and

assigned to caregivers.

These gaps were ﬁlled by organizing decision-tree

workshops. The goal of these workshops was to cap-

ture the decision process that the caregivers propose

or ﬁnd ideal to prioritize and assign care requests or

nurse calls in a decision tree. This decision tree can

then be translated to axioms in the ontology. To make

sure the context-dependent factors are captured, the

workshop was organized twice: once with stakehol-

ders from the residential care domain and once with

stakeholders from the hospital.

At the start of the workshop, the participants de-

scribed a complex situation involving care requests or

nurse calls. Next, the participants were asked to sup-

pose they were an intelligent system that had a com-

plete overview of the care setting and the current sit-

uation. The task of this system is to ﬁnd the most ap-

propriate staff member to handle a care request from

a patient/resident. A few of the complex situations

described by the participants were selected to fur-

ther discuss how this intelligent system should ideally

handle them, i.e., prioritize and assign them. The sit-

uations were illustrated on a layout of the institution.

The participants, playing the role of the system, could

collect additional information about the situation by

asking questions, e.g., How many staff members are

present in the department? What are their roles? Who

made the request? Instead of immediately giving an

answer, a discussion was ﬁrst held about the impor-

tance of the requested information, e.g., Why do you

feel the answer to this question is pertinent? Does

everyone agree? Can you give examples of answers

to this question? Finally, the question was answered

precondition: a call or care request is detected/made by a patient or resident

Goal: find 1 or more caregivers to handle this task

Reason

call/care request

known?

YesNo

Determine whether request/call is for:

- care

- medical reasons

- hotel task

GO TO Decision-tree

“Assign reason call/care request”

Classify reason as:

- care

- medical reasons

- hotel task

GO TO Decision-tree

“Assign reason call/care request”

Urgency call?No Yes

Classify call as

Normal call

More than

1 staff member with

the required

competences?

Yes

Patient/

resident making

call/request

known?

Assign the

task to this

filtered staff

member

Yes

Are there

filtered staff members who

are close and status

== free?

YesNo

Assign the task/

call to the close &

free filtered staff

members

Assign free or busy status to

filtered staff members based on

their current task

GO TO Decision-tree

“Determine status staff member”

Location

of the call/care

request

known?

Yes

Determine whether filtered staff

members are in proximity (close

enough) to the location of the call

GO TO Decision-tree

“Determine neighborhood of call”

Determine the degree of the trust

relationship between the filtered

staff members and the patient/resident

GO TO Decision-tree

“Determine trust relationship”

Yes

Are there

filtered staff members

for whom the degree of the trust

relationship > trust

threshold

For the rest of the

decision-tree consider as filtered

staff members only the staff

members with the required

competences AND for whom the

degree of the trust relationship

with the patient/resident > trust

threshold

Yes

GO TO Decision-tree

“Emergency procedure”

Assign priority call/care

request based on context

& patient profile

GO TO Decision-tree

“Priority assignment”

Filter staff members with the required

competences for a call with this reason

depending on their current role, function,

experience, and so on

GO TO Decision-tree

“Mapping competences/roles on tasks”

Priority ==

Normal?

...

Legend:

Bold text: concepts from ontology

: choice/decision

Italic text : refer to other decision-tree

: perform task/algorithm

: terminate

…?

...

Figure 5: Decision tree that ﬁnds the appropriate staff mem-

ber to handle a call or care request.

and the answer was visualized on the layout, as can

be seen in Figure 4.

The asked questions gave the ontology engineers

insights into which information is important to make a

decision. Moreover, the order in which the questions

are asked gave insight into the importance of this in-

formation for making the decision. During the work-

shop, this information is visualized on paper in the

form of a decision tree, as shown in the bottom right

corner of Figure 4. This decision tree thus contains

the high-level concepts to which the questions of the

participants pertained, e.g., location or task priority.

After the workshop, these results were trans-

formed to more formal decision trees for each setting.

After all the workshops, the decision trees were com-

pared to extract common parts. The common parts de-

liver input for the high-level ontology, while the other

branches are encoded in the low-level ontologies. Fi-

nally, the decision trees are translated to axioms and

rules in the implementation stage (see Section 2.4).

As an example, Figure 5 shows a part of the com-

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

mon decision tree that ﬁnds the most appropriate staff

members to handle a call or care request based on the

data in the ontology. Words indicated in bold refer

to concepts from the high-level ontology. The algo-

rithm ﬁrst determines whether the call is an urgency

call. Each care setting has its own procedure for han-

dling these highest priority calls. These procedures

are encoded in separate, context-dependent decision

trees to which this decision tree refers. If the call is

normal, the decision tree determines whether the rea-

son for the call is medical, care or a “hotel” task, e.g.,

a request for a glass of water. Based on this classiﬁca-

tion, staff members are sought with the required com-

petences for carrying out such tasks. If there are mul-

tiple staff members available with the required com-

petences, the decision tree assigns the most appropri-

ate staff members to the call based on their current

task, location, trust relationship with the patient and

the priority of the call.

To summarize, the proposed user-driven formal-

ization stage consists of:

• Extracting axioms and rules from the observations

• Performing one or more decision-tree workshops

with a carefully selected group of stakeholders,

each workshop has a very speciﬁc goal to ﬁll a

speciﬁc formal gap in the ontology

• Updating the sunny-day scenario with the feed-

back obtained during the decision-tree workshops

2.4 Implementation & Maintenance

In the implementation stage, the conceptual graphs

and decision trees are translated into an ontology lan-

guage. As the goal is not to overburden the stakehol-

ders, they are not actively involved in this stage. How-

ever, to prevent losing sight of the user requirements

when making implementation decisions, the ontology

engineers constantly validate the ontology under de-

velopment with the sunny-day scenario.

The Prot

e editor

was used to develop the con-

tinuous care ontology in the Ontology Web Language

(OWL)

. The Pellet Reasoner

was used to check the

consistency and the classiﬁcation of the ontology. The

SWRL rule language

was used to express rules us-

ing concepts from the ontology. The resulting contin-

uous care ontology is discussed in Section 3.

The maintenance stage consists of continuously

evaluating, updating and correcting the ontology.

This work is ongoing within the ACCIO project. The

developed ontology is currently being evaluated with

http://protege.stanford.edu/

http://www.w3.org/TR/owl-features/

http://pellet.owldl.com/

http://www.w3.org/Submission/SWRL/

the stakeholders by organizing additional role-play

workshops in the PRoF1.0 demo room. These work-

shops also include stakeholders who were not in-

volved in the other stages to make sure the ontology is

widely applicable across the continuous care domain.

Meanwhile, the intelligent, context-aware frame-

work is being developed and installed in the PRoF1.0

room. The aim is to show how intelligent applica-

tions can be built on top of this ontology. As a proof

of concept an intelligent nurse call system (Ongenae

and et al., 2011) is being built which ﬁnds the most

appropriate staff member to handle a call made by a

patient/resident by using all the information collected

in the ontology. This nurse call system makes use

of all the sensor data which can be collected in the

PRoF1.0 demo room, e.g., light sensors and intelli-

gent bed able to sense the vital parameters of a pa-

tient/resident. The nurse call system is also able to

adjust the status of the devices in the room based on

the context captured in the ontology, e.g., turn on the

light at a certain level when a staff member enters the

room or adjust the temperature based on the presence

of people in the room and their preferences.

Once this intelligent nurse call system is installed,

stakeholders will be invited to the PRoF1.0 demo

room to play with the system, criticize, discuss and

evaluate it. This evaluation will give input about the

correctness and applicability of the ontology.

3 THE CONTINUOUS CARE

ONTOLOGY

As mentioned previously, the main difference be-

tween residential care settings and hospitals is that the

ﬁrst focus more on care, while the latter focus more

on curing the patients. Consequently, the ontology

was split into a high-level ontology, modelling the

concepts that are used with the same meaning within

the continuous care domain, and two low-level on-

tologies, one focusing on care and the other on cure.

These low-level ontologies contain concepts that are

used with a different meaning in both settings or that

are used within residential care, but never within hos-

pitals and vice versa. The following paragraphs give

a concise overview of the high-level ontology.

Sensor Ontology. This ontology models the infor-

mation delivered by the numerous sensors and ac-

tuators present in the ambient intelligent care room

of the future. The most important concepts are vi-

sualized in Figure 6. The concepts preceded with

the wsn preﬁx are imported from the Wireless Sen-

sor Network (WSN) ontology, which was developed

PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering

Methodology

wsn:Sensor

Board

wsn:System

wsn:Sensor

wsn:Action

wsn:Fault

wsn:Observation

wsn:

Solution

wsn:Symptom

wsn:Detected

Fault

Incipient

Fault

wsn:PossibleFaulty

TemperatureSensor

wsn:Faulty

TemperatureSensor

wsn:

TMoteSky

wsn:Light

Sensor

wsn:

Temperature

Sensor

wsn:

Humidity

Sensor

wsn:External

Temperature

Observation

wsn:Humidity

wsn:Average

DataValue

wsn:Do

NotUse

DataValue

wsn:ZeroValue

Symptom

wsn:Threshold

Symptom

wsn:Temperature

SensorValue10

DeviationSymptom

wsn:Humidity

ZeroSymptom

isSensorPartOf

hasFault

Has

Observation

hasSolution

hasSymptom

hasNext

Observation

hasPrevious

Observation

isActionOf

isFaultOf

isObservation

isSolution

ForFault

isSymptomOf

Requires

Action

xsd:string

description

xsd:string

command

xsd:float

hasValue

xsd:string

forOS

Actuator

Light

Door

Blood

Pressure

Sensor

CallButton

DoorSensor

FallDetection

xsd:string

hasUnit

Buzzer

CallButton

Pressed

CallButtonPressed

DeviationLess

Than3seconds

...

Blood

Pressure

...

wsn:Humidity

TooLow

Systolic

BloodPressure

Above160

Hypertension

CallButtonPressed

TooFastInARow

Make

SensorCall

IgnoreCall

hasSensorPart

xsd:float

hasValue

xsd:string

hasUnit

Figure 6: The most important concepts of the imported

WSN and the Accio Sensor ontology.

within the IBBT project DEUS

and allows attach-

ing meaning to the data values monitored by sensors.

The System concept models a system and its com-

ponents, e.g., sensors. An Observation represents

a data value monitored by a system. Rules added

to the ontology allow detecting speciﬁc phenomena,

modeled as Symptom concepts, in these observations,

e.g., temperature observation deviates more than 10

degrees from the last. Axioms reclassify these symp-

toms as Fault concepts, e.g., the temperature sensor

is possibly faulty, and even as a Solution, e.g., do not

use that temperature value. This WSN ontology was

extended with systems, sensors and actuators, e.g.,

nurse call buttons or fall detection systems, and their

associated observations, faults and solutions that play

an important role in continuous care settings. Some

examples are shown in Figure 6.

Task & Process Ontology. This ontology models

continuous care process workﬂows. The most impor-

tant concepts are shown in Figure 7. The classes pre-

ceded by the owls preﬁx are imported from the OWL-

S Process ontology

. The Process concept models

a process that can return some new information and

produces a change in the environment based on the in-

formation it is given and the context. This is described

by the hasInput, hasOutput, hasPrecondition

and hasEffect relations. A process can be com-

posed of several other processes through the Compos-

iteProcess and ControlConstruct concepts. The Accio

http://www.ibbt.be/en/projects/overview-

projects/p/detail/deus

PlannedTask UnplannedTask

Call

AssistanceCall

NormalCall

Task

Priority

hasPriority

owls:Process

owls:Composite

Process

owls:Simple

Process

owls:Atomic

Process

owls:As

Process

owls:Control

Construct

owls:If-

Then-Else

owls:

Iterate

owls:Split-

Join

owls:Expression

owls:Condition

owls:List

collapsesTo

expandsTo

composedOf

computedEffect

computedInput

computedOutput

computedPrecondition

else

owls:Result

hasEffect

hasPrecondition

hasResult

owls:

ProcessVar

owls:Parameter

owls:ResultVar

owls:Input owls:Output

hasResultVar

hasVar

hasParameter

hasInput

hasOutput

ifCondition

inCondition

realizedBy

realizes

then

first

rest

components

name

xsd:boolean

invocable

Normal

Priority

Urgent

Priority

VeryUrgent

Priority

TaskStatus

hasStatus

TaskList

Assigned

Finished

Active

Temporarily

Accepted

Busy

xsd:int

NrOfTimesCalled

Reason

Medical

Reason

Care

Reason

Hotel

Reason

hasReason

...

controls

usedIn

wsn:

Sensor

Actuator

xsd:boolean

hasReceived

Feedback

Medical

Call

Care

Call

Hotel

Call

UrgencyCall

DoctorNeedeReason

GiveMedication

...

ContextCall

InConversation

DoctorNeededCall

xsd:int

NrOfTimes

Redirected

xsd:int

NrOfTimes

Relaunched

Medical

Assistance

Call

...

Care

ContextCall

...

wsn:System

makesCall

Figure 7: The most important concepts of the imported

OWL-S Process and the Accio Task ontology.

Task ontology extends this ontology by introducing

the Task concept, which is a subclass of Process and

is further divided into planned and unplanned tasks.

Some examples of each are shown at the bottom of

Figure 7. Each task has an associated Status, e.g.,

Assigned or Finished, and Priority. From the ob-

servations and workshops it was clear that the stake-

holders preferred three levels of priority, namely very

urgent, urgent and normal. This Task concept is used

to model the continuous care tasks. Consider, for ex-

ample, the task of assigning a person to a call, for

which the decision tree is shown in Figure 5. A Call

is modeled as an unplanned task. The various possible

types of calls, e.g., urgency or normal, and the possi-

ble reasons for the call, i.e., medical, care and hotel,

are also modeled. For each type of call, its precon-

ditions, e.g., a patient pushes a button, its input, e.g.,

the patient, its output, i.e., the assigned staff mem-

bers, and its effects, e.g., the staff members’ portable

phones ring, are modeled by using concepts from the

OWL-S Process ontology.

Proﬁle Ontology. This ontology models the pro-

ﬁle information about staff members and patients/res-

idents that was indicated by the stakeholders in the

different co-design workshops as important. The most

important concepts are visualized at the bottom of

Figure 8. Each Person is associated with a Profile,

which consists of a basic and a risk proﬁle. The ba-

sic proﬁle models the biological, psychological and

sociological information. Some examples are shown

in Figure 8. This information needs to be inputted

into the system or extracted from documents, e.g., pa-

tient’s medical ﬁle. The risk proﬁle is deﬁned by clas-

siﬁcation axioms and rules. This allows a reasoner to

automatically obtain the risk proﬁle of the patient by

reasoning on the information in the basic proﬁle. Fi-

nally, the Proﬁle ontology also contains concepts and

rules to model the trust relationship between two peo-

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

ple, e.g., it models that each doctor has a therapeutic

relationship of high degree with his/her patients.

Role & Competence Ontology. This ontology, of

which the most important concepts are shown in the

top part of Figure 8, deﬁnes each role that can oc-

cur in a continuous care setting by its competences

through classiﬁcation axioms, e.g., the Doctor Role

is deﬁned as a role which has all the medical com-

petences. This allows writing algorithms that ﬁnd

the most appropriate staff members to fulﬁll a task

based on the required competences. Each person is

associated with competences and roles through ﬁve

relationships. hasFunction indicates the primary

role of a person, i.e., the role for which this person

was primarily hired. hasRole models all the roles

a person can have, e.g., the head of the department

who is also a nurse. The role a person is currently

fulﬁlling within the care setting is represented by

hasCurrentRole. Finally, hasDiplomaCompetence

and hasExperienceCompetence model extra com-

petences a person has acquired by following courses,

e.g., a caregiver who is trained to perform some med-

ical tasks, or through experience.

Context Ontology. This model represents the con-

textual environment information. The most prevalent

concepts are shown in the middle of Figure 8. The

most important concept is the Troop, which is a log-

ical grouping of entities that belong together, e.g.,

a patient with all his/her devices, sensors, actuators,

room, bed and equipment. The composition of a troop

dynamically changes based on the context, e.g., the

location or status of the people, devices and equip-

ment. This is deﬁned through rules.

Medical Ontology. To model the medical knowl-

edge, the Galen Common Reference Model

was im-

ported and connected with the concepts from the

Accio ontology as illustrated in Figure 8. For ex-

ample, the Pathology concept is connected with the

Person concept from the Accio Proﬁle ontology.

Temporal Ontology. It also important to model

time in the ontology, e.g., tasks that need to be per-

formed before a certain point in time or work pro-

cesses that are adjusted according to the time of day.

For this the SWRLTemporalOntology

was imported.

This ontology deﬁnes a temporal model that can be

used to model complex interval-based temporal infor-

mation. It also deﬁnes a library of SWRL built-ins

to perform temporal reasoning. The Accio Temporal

ontology extends this ontology to model the current

temporal context, e.g., the current season or shift.

SWRL Rules. On top of this ontology rule-based

algorithms are developed that contain the algorithms

to optimize and automate continuous care. These

Context Ontology Accio

Role & Competence Ontology ACCIO

Profile Ontology ACCIO

Person

owns

Device

Has

Pathology

Parameter

hasParameter

hasExperience

Competence

hasSex

hasFunction

xsd:string

hasUnit

hasValue

xsd:double

Impatient

Agressive

Nationality Language

hasNationality

hasLanguage

hasRiskProfile

hasProxy

has

Location

Competence

Role

hasCompetence

Medical

Competence

Administer

Medication

Competence

Care

Competence

AnswerCall

Competence

Answer

MedicalCall

Competence

belongsTo

StaffMember

MedicalRole

CaringRole

Family Patient Resident

Gender

Profile

BasicProfile

hasProfile

hasDiploma

Competence

hasCurrentRole

BloodPressure

worksOn

liesOn

livesOn

responsibleFor

hasBed

hasTelephone

Number

xsd:string

TrustRelationship

PersonalRelationship FamilyRelationship TherapeuticRelationship

hasTrustRelationship

belongsTo

xsd:int

hasDegree

RiskProfle

Medical

RiskProfile

Behavioral

RiskProfile

...

Answer

CareCall

Competence

...

GiveBathroom

AssistanceTo

PersonCompetence

...

Call

Task

TaskList

makesCall

hasCurrentTask

hasTODOTasks

executedOn

executedBy

belongsTo

Biological

Profile

Sociological

Profile

Psychological

Profile

hasBasicProfile

hasSociologicalProfile

hasBiological

Profile

hasPsychological

Profile

...

needsCompetence

hasLocation

Location Zone

Coordinate

xsd:int

hasYCoord

hasXCoord

Department

Bed

belongsTo

Room

isOn

Department

xsd:int

hasNr

xsd:int

hasNr

Device

PDA

Bedside

Portable

Phone

Troop

Towel

Item

Furniture

Closet

has

Location

belongsTo

...

wsn:System

wsn:Sensor

Actuator

belongsTo

...

assignedTo

hasRole

Person

Status

hasStatus

Man

Woman

DeviceStatus

hasStatus

hasCentre

Coordinate

containsRoom

Floor

isOnFloor

contains

Room

Hallway

contains

Hallway

contains

Hallway

Function

RoomFunctionDeviceFunction

hasFunction

Sanitary

...

Light

Control

Nurse

Call

...

Busy

...

has

Location

containsSystem

Figure 8: The most important concepts of the Proﬁle, Con-

text and Role & Competence Ontology.

rules infer new knowledge based on the data available

in the ontology. Efﬁcient and fast notiﬁcations made

by these algorithms allow appropriate actions to be

taken by the staff. An example of a work process that

can be optimized this way is the assignment of care-

givers to calls or care requests for which the decision

tree is shown in Figure 5. For example, the grey path

in Figure 5 is encoded as a SWRL Rule

as follows:

hasRe a s o n ( ? c a l l , ? r ) ∧ MedicalReason ( ? r ) ∧

h a s C u r r e n t R o l e ( ? p , ? r o ) ∧

hasComp e t enc e ( ? ro , ? c ) ∧ Me d i c al C o m p e te n c e ( ? c )

⇒ a s si g n e dT o ( ? c a l l , ? p )

4 LESSONS LEARNED

In this section, the most important lessons learned

during the co-creation of the ontology with the par-

ticipatory methodology are discussed. More informa-

tion can be found in Bleumers, et al. (2011).

Timing. One of the goals was to achieve user par-

ticipation beyond collecting the requirements of the

ontology in the speciﬁcation phase, but without actu-

ally pushing them in the role of ontology engineers

and thus overburdening them. The stakeholders are

mainly involved through the workshops and obser-

vations. The observations comprised of 1 week in

each continuous care setting, during which staff mem-

bers were followed and interviewed. The workshops

lasted 2 to 3 hours on average. The workshops were

distributed amongst the available participants, while

maintaining the group of each workshop representa-

tive of the different stakeholders in the domain. Par-

ticipants often remarked that the sessions seemed too

PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering

Methodology

short to get to the bottom of the issue at hand. How-

ever, it was difﬁcult to lengthen the workshops as par-

ticipants often could not make themselves available

that long. In line with a suggestion of one of the par-

ticipants, a follow-up session was coupled with each

workshop. This allows presenting the output of the

workshop and the achieved results. This permits to

brieﬂy discuss pressing issues not handled during the

workshop, to evaluate the output and to illustrate to

the stakeholders that their input was taken into ac-

count and that is was time well spent. It was also

concluded that while the described methodology lim-

its the time that has to be invested by the stakeholders,

it does require a large amount of time and effort from

the social scientists and ontology engineers.

Elicitate Out-of-the-Box Thinking. During the

workshops, it was noted that it was difﬁcult for stake-

holders to look beyond their current situation and

work practices. This issue was resolved by explicitly

triggering participants to think out-of-the-box, e.g.,

by taking them out of their usual role and practices

with the persona and situation cards in the role-play

workshops.

Connecting Ontology Engineers and Stakeholders.

One of the challenges during the workshops was the

facilitation of the communication between the onto-

logy engineers and stakeholders. It became apparent

that bridges needed to be build between them. This

was done in various ways. First, the ontology engi-

neers took part in the observations to get an idea of the

current work practices of the stakeholders. Second,

bridges were also used during the workshops, e.g., the

storyboard in the role-play workshop or the decision-

tree. Finally, the resulting ontology and axioms were

communicated with the stakeholders in an easily un-

derstandable format, e.g., document workﬂows, mind

maps, graphs and decision-trees.

Learning by doing. A hands-on approach was used

during the workshops, e.g., exercises in the ontology

workshop, role-playing in the role-play workshop

and question-and-answer process in the decision-tree

workshop. Participants were also stimulated to reﬂect

on sometimes higly complex issues. It was found that

participants much appreciated this approach of action

and reﬂection. It allowed them to reﬂect on their cur-

rent practices, enhanced their understanding of the

topic and elicitated discussion.

5 CONCLUSIONS

In this paper a participatory ontology engineering

methodology is proposed which promotes user parti-

cipation while taking into account that time is a valu-

able resource. The methodology actively involves

ontology engineers, social scientists and stakeholders,

i.e., nurses, caregivers, patients, doctors and profes-

sionals working for the healthcare industry, in the

ontology engineering process. The user-driven me-

thodologies and techniques to achieve this partici-

patory ontology engineering methodology were pre-

sented in detail and validated by building a continuous

care ontology. Future work will focus on developing

and validating user-driven techniques to support the

maintenance stage of the ontology life-cycle.

ACKNOWLEDGEMENTS

Part of this research was supported by the IBBT

Project ACCIO. F. Ongenae would like to thank the

IWT for her Ph.D. grant. The role-play workshop was

organized in the PRoF1.0 demo room in Poperinge,

Belgium

. We thank all the participants in ACCIO

for their valuable contribution to the project.

REFERENCES

Bleumers, L. and et al. (2011). Towards ontology co-

creation in institutionalized care settings. In Proc. of

Pervasive Health 2011. IEEE.

Gruber, T. (1993). A translation approach to portable onto-

logy speciﬁcations. Knowledge Acquisition, 5:199–

220.

Kotis, K. and Vouros, G. (2006). Human-centered ontology

engineering: the hcome methodology. Knowledge and

Information Systems, 10(1):109–131.

Ongenae, F. and et al. (2010). User-driven design of an

ontology-based ambient-aware continuous care plat-

form. In Proc. of Pervasive Health 2010, Munich,

Germany. IEEE.

Ongenae, F. and et al. (2011). An ontology-based nurse call

management system (oncs) with probabilistic priority

assessment. BMC Health Services Research, 11(26).

Pinto, H. and Martins, J. (2004). Ontologies: how can

they be built? Knowledge and Information Systems,

6(4):441–464.

Pruitt, J. and Adlin, T. (2006). The persona lifecycle: keep-

ing people in mind throughout product design. Mor-

gan Kaufmann, San Mateo, USA.

Tentori, M., Segura, D., and Favela, J. (2009). Mobile

Health Solutions for Biomedical Applications, chapter

VIII: Monitoring hospital patients using ambient dis-

plays. Medical Information Science Reference, USA.

Verstichel, S. and et al. (2010). Distributed ontology-based

monitoring on the ibbt wilab.t infrastructure. In Proc.

of TridentCom 2010, Berlin, Germany. Springer.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development