PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY
Towards a User-driven Ontology Engineering Methodology
Femke Ongenae
1
, Lizzy Bleumers
2
, Nicky Sulmon
3
, Mathijs Verstraete
3
, Mieke Van Gils
3
,
An Jacobs
2
, Saar De Zutter
4
, Piet Verhoeve
4
, Ann Ackaert
1
and Filip De Turck
1
1
Information Technology Department (INTEC), Ghent University - IBBT, Gaston Crommenlaan 8, 9050 Ghent, Belgium
2
Research Centre for Studies on Media, Information and Telecommunication (SMIT), Brussels University (VUB) - IBBT
Pleinlaan 2, 1050 Brussels, Belgium
3
Centre for User Experience Research (CUO), K.U. Leuven - IBBT, Parkstraat 45, bus 3605, 3000 Leuven, Belgium
4
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 finds 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
configure 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 sufficient
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
81
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
Copyright
c
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 classification 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 first 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 profile 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 difficult 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
1
or the Gene Ontology
2
. 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-
fication 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
1
http://www.opengalen.org/index.html
2
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
first 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 five widely accepted stages for building an
ontology (Pinto and Martins, 2004):
Specification: 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 reflect 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
82
2.1 Specification: Observations and
Scenario Description
To achieve a grounded, user-centered design process,
the specification stage starts with creating a represen-
tative stakeholder group. Two major institutionalized
continuous care settings were identified, 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 first
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
3
. 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.
3
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 identified, namely information
integration & data provisioning at the point of care
and an intelligent & dynamic nurse call system. The
first 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 filtered 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 find the most appropriate staff member to
handle a request of care from a patient/resident and at
the same time optimize the current workflow 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 workflow was constructed. It outlines all
documents (analog or digital) and formats of commu-
nication used during the care for patients/residents.
The document workflow also describes the proper-
ties of the documents, such as the content, the specific
aim, the author(s), the target audience, the storage lo-
cation and the relationships to other documents.
As a final step in the specification stage, a sunny-
PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering
Methodology
83
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 specifica-
tion stage consists of:
Composing a representative stakeholder group.
Creating better knowledge of each other’s field 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.
Defining 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-
cific 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 specific 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
4
. 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 simplified, first 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 specific 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., difficult 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-
4
http://www.prof-projects.com/en/index.html
KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development
84
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
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
TV
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 first version of the high-level
ontology, which is illustrated in Figure 3. As can be
seen, 6 major sub-domains were identified, namely
information pertaining to tasks & processes, to per-
son profiles, 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 identified (69
concepts in total). This allowed the ontology engi-
neers to integrate the information obtained during the
specification stage in this ontology, based on the mind
maps and document workflow.
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
5
and the SWRLTemporalOntology
6
.
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 specific to these settings.
5
http://www.w3.org/Submission/OWL-S/
6
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 workflows and mind maps and
extracting concepts such as roles, competences, tasks
(care acts) and profiles. 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 define 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 defined through ax-
ioms that restrict the possible interpretations for the
meaning of those concepts, e.g., defining which com-
petences a certain role has, which competences are
PARTICIPATORY DESIGN OF A CONTINUOUS CARE ONTOLOGY - Towards a User-driven Ontology Engineering
Methodology
85
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 filled by organizing decision-tree
workshops. The goal of these workshops was to cap-
ture the decision process that the caregivers propose
or find 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 find 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 first 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
No
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”
No
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”
No
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
No
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?
No
...
...
...
Legend:
Bold text: concepts from ontology
: choice/decision
Italic text : refer to other decision-tree
: perform task/algorithm
: terminate
…?
...
...
Figure 5: Decision tree that finds 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
86
mon decision tree that finds 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 first 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 classifica-
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 specific goal to fill a
specific 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
´
eg
´
e editor
7
was used to develop the con-
tinuous care ontology in the Ontology Web Language
(OWL)
8
. The Pellet Reasoner
9
was used to check the
consistency and the classification of the ontology. The
SWRL rule language
10
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
7
http://protege.stanford.edu/
8
http://www.w3.org/TR/owl-features/
9
http://pellet.owldl.com/
10
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 finds 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
first 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 prefix 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
87
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
Of
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
11
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 specific 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 workflows. The most impor-
tant concepts are shown in Figure 7. The classes pre-
ceded by the owls prefix are imported from the OWL-
S Process ontology
5
. 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
11
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.
Profile Ontology. This ontology models the pro-
file 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 profile. The ba-
sic profile 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 file. The risk profile is defined by clas-
sification axioms and rules. This allows a reasoner to
automatically obtain the risk profile of the patient by
reasoning on the information in the basic profile. Fi-
nally, the Profile ontology also contains concepts and
rules to model the trust relationship between two peo-
KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development
88
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, defines each role that can oc-
cur in a continuous care setting by its competences
through classification axioms, e.g., the Doctor Role
is defined as a role which has all the medical com-
petences. This allows writing algorithms that find
the most appropriate staff members to fulfill 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
fulfilling 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 defined through rules.
Medical Ontology. To model the medical knowl-
edge, the Galen Common Reference Model
1
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 Profile 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
6
was imported.
This ontology defines a temporal model that can be
used to model complex interval-based temporal infor-
mation. It also defines 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
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
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
xsd:int
hasYCoord
hasXCoord
Department
Bed
belongsTo
Room
isOn
Department
xsd:int
hasNr
xsd:int
hasNr
Device
PDA
Bedside
PC
Portable
Phone
TV
Troop
Towel
Item
Furniture
Closet
has
Location
belongsTo
belongsTo
...
...
...
...
wsn:System
wsn:Sensor
Actuator
belongsTo
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
hasFunction
Sanitary
...
Light
Control
Nurse
Call
...
Busy
...
has
Location
containsSystem
Figure 8: The most important concepts of the Profile, Con-
text and Role & Competence Ontology.
rules infer new knowledge based on the data available
in the ontology. Efficient and fast notifications 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
10
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 specification 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
89
short to get to the bottom of the issue at hand. How-
ever, it was difficult 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
briefly 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 difficult 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 workflows, 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 reflect
on sometimes higly complex issues. It was found that
participants much appreciated this approach of action
and reflection. It allowed them to reflect 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
4
. 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 specifications. 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
90