International Conference on Complex, Intelligent and Software Intensive Systems
Ontology Based and Context-Aware Hospital Nurse Call Optimization
F. Ongenae, M. Strobbe, J. Hollez, G. De Jans,
F. De Turck, T. Dhaene, P. Demeester
Ghent University
Gaston Crommenlaan 8, bus 201
B-9050 Gent, Belgium
Email: Femke.Ongenae@intec.ugent.be
Abstract
In this paper, the focus is on how context information
can be efficiently modeled with an ontology. This ontology
can than be used by reasoning algorithms which are based
on this context information. This is illustrated with a use
case which studies the evolution from a place oriented to a
person oriented nurse call system.
An ontology was designed which holds the necessary
context information. A nurse call algorithm that uses this
information was constructed. The CASP Context frame-
work was extended to implement the use case. This frame-
work is bases on an OSGi framework. Rules are formulated
to implement the algorithm. OWL was applied to integrate
the ontology into the framework. A Web Service interface
was designed which allows to insert new information into
the Knowledge Base or extract information from it. At last
a simulation was set up to show the advantages of the per-
son oriented approach. The results of a performance study
are shown as well.
1. Introduction
1.1. Situation
Context information becomes increasingly important in
a world with more and more wireless devices that have to be
in touch with the environment around them. In this article
it is shown how this context information can be efficiently
modeled and used by employing an ontology. It will also
be shown how this ontology can be used for reasoning with
a Rule-based algorithm to obtain answers which take the
context information into account. The use case that will be
studied in detail is the evolution of a place oriented nurse
call system to a person oriented one.
First, an ontology was designed in an iterative way by
studying relevant situations and extracting the necessary
0-7695-3109-1/08 $25.00 © 2008 IEEE
DOI 10.1109/CISIS.2008.80
P. Verhoeve
Televic R&D
Leo Bekaertlaan 1
8870 Izegem
Belgium
Email: p.verhoeve@televic.com
context information. Next, an algorithm was constructed
that relied on the context information in the ontology. This
way, the algorithm was more sensible to the varying condi-
tions of the environment. The application was implemented
by extending the CASP (Context-Aware Service Platform)
context framework. This consists of a collection of applica-
tions (bundles) for OSGi. At last, a simulation was set up to
show the advantages of this new approach.
1.2. Related work
Context-awareness is a hot research domain, with inter-
esting topics such as context modeling, infrastructure sup-
port for querying and reasoning on contextual information
using an inference engine and so on. In [9] an adaptable
and extensible ontology is proposed for creating context-
aware computing infrastructures, ranging from small em-
bedded devices to high-end service platforms. In [11] an
OSGi-based infrastructure for context-aware applications is
proposed.
1.3. Paper organization
This paper is organised as follows: the second section
explains the use case discussed in this paper namely the evo-
lution from a place oriented to a person oriented nurse call
system. The third section shows how the ontology and the
new nurse call algorithm are designed. The fourth section
sheds some light on the implementation details. In the fifth
section a simulation demonstrates the advantages of the new
approach.
2. Context-aware use case
2.1. Introduction
The current nurse call systems are organized according
to rooms: each room (or bed) has a (fixed) button which
985

Figure 1. Place oriented nurse call system
and algorithm.
can be used by the patients to call a nurse. In such a place
oriented system the called nurse simply goes to the room
where the call came from. Herewith two important assump-
tions are made: the patient must still be in the room and it
must be the patient who lies in the room that made the call.
In the future, there will be an evolution to a (mobile) but-
ton for each patient so that they can walk around freely and
still make calls. The system would become person oriented.
This evolution implies a lot of changes, e.g. the nurse has
to go to the exact location of the patient (not his room), the
patient can make call from anywhere in the hospital and so
on. This huge impact is comparable to the introduction of
the mobile phone. In the past we used to call to a telephone
(a place) and ask for the correct person. Now we call a
mobile phone and we immediately expect to have the right
person on the line. The owner of the mobile phone does not
need to be in his house, but is reachable all over the world.
2.2. Place oriented nurse call system
The current nurse call system can be viewed in Fig. 1.
Each room has at least one button which can be used by
the patient to call a nurse. All the buttons in a room are
connected to a node. This node has the intelligence to know
what must happen inside the room when a call is made e.g.
buzzers start making sounds, lights switch on and so on. All
the nodes (rooms) of a department are connected with each
other and eventually connected to a Controller.
The controllers are the heart of the system. Each con-
troller has the intelligence to know what must happen when
a call is made in one of the rooms that it is responsible
for. It knows for example which nurses must be called.
Once a controller is configured it can work completely au-
tonomous, without help from a person or pc. The controllers
can be connected to each other and with a pc through an IP
network. This pc can be used to change the configuration.
2.3. Place oriented nurse call algorithm
The place oriented nurse call algorithm divides the
nurses in a department into groups. Each group is responsi-
ble for a section of rooms. It is possible that these sections
986
overlap. To make a call the patient pushes one of the but-
tons in his room. All the beepers of the nurses, who are in
the group that is responsible for the section of rooms that
this room belongs to, are activated. Each nurse decides on
his own if he is going to interrupt his current task to answer
the call or not. The nurse who reaches the room first (and
pushes a button that acknowledges his presence) will handle
the call.
3. Context Study
The evolution to a person oriented system demands a
good understanding of the context of a hospital to achieve
a more efficient nurse call algorithm. A patient can for ex-
ample move all over the hospital to make a call. Therefore,
a nurse who works in the department of the patient is not
necessarily near to the patient and may thus not be the best
candidate to answer the call. This was not a problem in the
place oriented system as the rooms were static. So nurses
who worked within a certain department would always be
near the rooms in that department.
It is important to have access to context information such
as the location and risk factors of the patient, the character-
istics of the hospital staff and the infrastructure of the hospi-
tal. This information can be used to determine which nurse
should be called for which patient at a certain moment.
Ontologies can be used to structure and represent knowl-
edge about a certain domain in a formal way. A person
oriented ontology was developed which represents the nec-
essary context information. The ontology and the nurse
call algorithm were developed simultaneously. A couple
of concrete situations were studied. For each situation the
relevant context information was extracted and the ontol-
ogy was augmented with it. A generic optimal solution (in
terms of which nurse should be called) was also devised for
each situation. The combination of the optimal solutions for
these different situations resulted in the algorithm. It took
several iterations and meetings with domain experts to get
the desired ontology.
3.1. Person oriented ontology description
A short, but complete definition of an ontology is given
in [4]. “An ontology is a specification of a conceptualiza-
tion in the context of knowledge description.” An ontology
describes formally the entities within a certain domain, their
properties and their relations. This allows a computer to
reason about this knowledge. Therefore, ontologies are the
ideal way to store context information.
The following situations were studied to gradually ex-
tend the ontology with relevant context information. These
situations were discussed and constructed in collaboration
with the domain experts at Televic NV [12]. First, the dif-
ferent possible kinds of staff members, who were able to
answer calls, were studied. Next, the influence of the loca-
tions of the patients and the staff members was taken into
account. Different kinds of calls were also distinguished.
The possibility for patients to prefer to be treated by cer-
tain kinds of nurses was modeled by allowing patients to
identify characteristics (e.g. language, sex) that the nurse
must have. Nurses can also specify that they do not want to
treat certain patients.
The administrative needs of the overall system were also
considered e.g. knowing the names of the patients/beds.
The current status of the staff member is an important
factor. A staff member can be occupied with completing a
certain task. Each task has a priority ranging from 1 (low) to
10 (high). For each staff member a list of tasks that he must
do can be stored. Devices must also be modeled as they can
also launch calls (e.g. when a heart monitor is unplugged
accidentally, it launches a call).
In the last stage the possibility was added to identify risk
factors for patients (e.g. heart patient, high cholesterol). By
doing so, their calls receive a higher priority.
Finally, the status of a call was added. When a call is
launched, its status is active. It changes to answered when a Figure 2. The person oriented ontology.
staff member is on his way to the patient. If a staff member
is actually treating the patient, the status changes to busy. tient is searched. If he is free and in the vicinity,
When the call is completely handled, the status becomes he is called. If he is occupied and his current task
finished. has a lower priority, he is also called.
An outline of the resulting ontology (showing the most – If the responsible helper cannot be called, all the
important concepts) is shown in Fig. 2. The squares depict helpers are searched who work on the depart-
the different entities (classes) in the domain and the arrows ment from where the call originated. From this
signify subsumption. The ovals determine the properties of group all the helpers who are not free, are not
the entities that they are connected to. The lines depict the willing/qualified to treat the patient or are not in
relations between different entities. The cardinality of each the vicinity are removed. From the remaining
entity within the relation is also given (* means 0 or more). helpers, the one who has the most characteristics
in common with the preferences of the patient is
chosen. If there are no characteristics given, the
3.2. Nurse call algorithm nurse who is the closest to the patient is chosen.
– If the result is empty, the search is broadened
A new algorithm was designed to find the correct staff beyond the helpers of the department. All the
member to handle a certain call. It makes use of the infor- helpers who are qualified to treat the patient are
mation stored in the ontology. An outline of the algorithm, searched. All the helpers who are not free, are
which shows the important features, is given below. It first not willing to treat the patient or are not in the
determines which kind of call has been made: neighborhood are filtered. From the remaining
• Urgency call: The closest (to the origin of the call) group the one who has the most characteristics
member of a urgency team who is not already handling in common with the preferences of the patient is
a urgency call is searched. Then the entire urgency chosen. If there are no characteristics given, the
team to which this person belongs is called. The prior- nurse who is the closest to the patient is chosen.
ity lies here on finding a person who is near instead of – If the result is empty again, this means that there
a person who is free. are no available helpers in the direct vicinity. The
• Normal call: The part of the algorithm to call a helper distance becomes a deciding factor at this mo-
consists of a number of steps: ment. So the group of qualified helpers is se-
lected, but only the ones who are not free or are
– First, the helper who is responsible for this pa- not willing to treat the patient are filtered. From

987
 the remainder the one who is closest to origin of
the call is chosen.
– If this still does not offer a solution, all the
helpers in the hospital are considered and the one
who is closest to the patient is called.
A staff member can sometimes be called while he is al-
ready busy with a task. It is up to him to decide if he is
going to interrupt his current task or not. In contradiction
to the place oriented case, the staff member knows that the
new call has a higher priority than the task that he is cur-
rently working on. Based on these priorities he can make a
more funded decision to interrupt his current task or not.
If he decides to answer the new call, the system auto-
matically interrupts his current task. If the task is a call, an
other staff member is searched (using the above algorithm)
to handle the call. If the task is a normal task (e.g. giving
a medicine to a patient), the task is added again to the list
of task that this staff member must do. So the staff member
does not have to remember himself that he has to return to
a task or that he has to call some other staff member.
The algorithm also has a time-out procedure. If a staff
member has not indicated that he is going to handle the
call within a certain time, the algorithm selects another staff
member to handle the call.
Note that this algorithm differs significantly from the
place oriented one. The place oriented algorithm only looks
at which patients (actually rooms) are allocated to which
nurses. In the new algorithm much more factors are taken
into account. It looks at the characteristics and the status
of the staff members, the risk factors and preferences of the
patients, the priority of the call and so on.
4. Implementation details
In this section the implementation details are discussed.
First, the ontology was digitalized by using the ontology
language OWL and the ontology editor Protégé. Next, the
existing CASP Context framework, which makes use of an
OSGi Framework, was extended. The ontology was inte-
grated into it. The algorithm was implemented by using
Rules. Some web services were written to allow applica-
tions and users to add or extract information from the ontol-
ogy.
4.1. Digitalizing the ontology
There are different ontology languages with different
possibilities. OWL[1], from the World Wide Web Con-
sortium (W3C)[2], was chosen because an OWL file can
be directly integrated into the CASP Context Framework
(see section 4.2). Furthermore, OWL is a standard and it
provides numerous additional possibilities e.g. inverse rela-
tions.
988
Figure 3. The CASP Context Framework
OWL consists of three sublanguages: OWL-Lite, OWL-
DL and OWL-Full. The main difference is their expressiv-
ity. Here OWL-DL is used because it is based on description
logic[7]. Description logic is a decidable part of the first
order logic. This way it is possible to reason about the de-
cidable information in the ontology. This is necessary when
Rules are used for the implementation of the algorithm.
Protégé[6, 3] was used as the ontology editor.
4.2. CASP Context Framework
The OSGi Framework[5] is an open service platform for
the delivery and control of different applications (which are
called bundles in OSGi) and services to a certain type of
networked device in the environment. The CASP context
framework is a collection of bundles which were developed
by the co-authors to handle context information. More in-
formation can be found in [10]. An overview of the frame-
work is shown in Fig. 3. The Context Interpreter represents
the context information e.g. the Context Model (the OWL
file) and the Knowledge Base (the data that conforms to the
ontology). It also holds all the Rules that were used to im-
plement the nurse call algorithm (see section 4.3).
The different Context Providers allow importing exter-
nal information into the Knowledge Base. This new infor-
mation can come from a database (Persistence Layer) or
directly from a device (Device Layer, Context Gathering
Layer). As there was no access to devices, some Web Ser-
vices were developed to allow users to add new information.
The Query Services are used to extract information from
the Knowledge Base. This can be used to visualize the
knowledge or to use the information in another application
(Application Layer). A visualization of the knowledge is
currently not implemented as this was not the main goal of
the research. Instead a Web Service was developed which
allows users to extract information.
4.3. Rules for the nurse call algorithm
The person oriented nurse call algorithm is implemented
by using Rules. These are activated when a certain event
[insert\_nurse\_normalcall:
(?x rdf:type ncs:Normal)
(?x ncs:has\_status ?status)
(?status ncs:Kind ’Active’)
noValue(?x ncs:treated\_by\_nurse)
->findHelper(?x)]
Figure 4. The new normal call Rule.
occurs in the Knowledge Base for example when a new call
is added. When the condition is fulfilled, the Rule calls a
functor. A functor does some calculations with the parame-
ters it receives from the Rule, for example the new call. The
functor can change the information in the Knowledge Base.
Every kind of call that can occur is handled by a different
Rule but in a similar manner. The code fragment in Fig. 4
shows the Rule that reacts to a normal call. This Rule is
activated when a normal call is launched. If the condition
is fulfilled the functor findHelper() is called which follows
the earlier stated algorithm (see section 3.2) to find a correct
staff member to handle the call. It adds the information that
this staff member has to handle this call to Knowledge Base.
When a staff member decides that he is going to answer
a call (and thus changes the status of the call tot answered)
the Rule update answered call gets activated. The functor
UpdateAnsweredCall() is used to interrupt the current task
(if any) of the staff member automatically as explained in
section 3.2. It also changes some other information in the
Knowledge Base to indicate that this staff member is work-
ing on this call. There is also a Rule call treated to handle
the information that must change in the Knowledge Base
when a staff member ends a call e.g. the status of the staff
member must be changed to free.
A last set of Rules (e.g. relaunch normalcall timeout)
is used to handle the time-out of a call. This means that if
the called staff member has not answered the call within a
certain period of time, then the call is launched again.
5. Simulation setup
To test and demonstrate the advantages of the system, a
couple of simulations were set up. Some typical situations
within a hospital were simulated and the results were stud-
ied and compared with the location oriented system. Here,
one of the simulations is described which nicely illustrates
some advantages of the new person oriented system. More
information about the simulations can be found in [8].
5.1. Scenario description
Fig. 5 shows an overview of the situation at the start of
the simulation. It takes place within one department of a
hospital. The different numbered P’s and V’s depict the pa-
tients and nurses. The nurses are responsible for the patients
989
Figure 5. Simulation: plan and initial posi-
tions
who lie in the rooms that have the same color as the nurse.
Nurse V2 is responsible for patient P6 (standing in the hall-
way) and nurse V4 is responsible for patient P2 (standing in
the bathroom). The doctor (illustrated by D1) is responsi-
ble for all the patients in this department. The urgency team
is composed of doctor D1 and nurses V3 and V2. There
is only one patient who has a risk factor namely patient P3
who is a heart patient. No patient has specified any (re-
stricting) characteristics to which his treating nurse should
conform. Nurse V3 is treating patient P5 (so he is busy), all
the other staff members are currently free.
The simulation consists of the following steps:
• Patient P3 (the heart patient) makes a normal call.
• The called notices that P3 is in very bad shape.
• The nurse launches a urgency call.
• The called urgency team starts treating him (but does
not finish the call yet).
• Patient P4 makes a normal call.
• The called nurse completely finishes the call.
• All other calls are also finished at this moment.
It is assumed that a nurse who is called and who is al-
ready busy with a task, will always interrupt his current task
to handle the new call. This leads to a more complicated and
illustrative simulation.
5.2. Results description
The performance of 10 different simulations can be
viewed in figure 6. It shows for each call the average time
(in milliseconds) between the launch of the call and the mo-
ment that nurse receives the call. It also shows the standard
deviation (SD) of each test in milliseconds. Which nurses
were called by the algorithm will now be discussed.
The algorithm notices that nurse V3 is responsible for
this patient. V3 is in the vicinity, but he is not free. The call
of patient P3 has a higher priority than the one of patient
P5 (because P3 is a heart patient). The algorithm thus calls
nurse V3 to handle the call. Nurse V3 receives and answers
this call and starts moving towards P3.
When nurse V3 answered the new call, his current task
(the call of P5) was automatically interrupted and launched

Figure 6. Performance of 10 different simula-
tions.
again to find a new staff member to handle it. The algo-
rithm notices that the responsible nurse (nurse V3) is in
the vicinity, but is handling a call with a higher priority,
so he cannot be called. The algorithm now considers all
the nurses who work in this department. The only differ-
ing factor between these nurses is their availability and the
distance to the patient (there are no characteristics, prefer-
ences or qualifications given). V3 is not selected because
he is not free. From the remaining nurses, the closest one is
chosen namely nurse V4. He receives and answers the call.
He goes to patient P5 and continues his treatment.
Meanwhile nurse V3 has arrived in the room of patient
P3. He launches the urgency call. The system automatically
changes the status of the normal call of P3 to finished. There
is only one urgency team, so they are called. V3 is already
at the location of the patient. Doctor D1 and Nurse V2 hurry
to P3. They start treating the urgency call.
The algorithm notices that V3 is responsible for P4. But
nurse V3 is already busy with a urgency call (which has
the highest priority), so he cannot be called. The only free
nurses are V1 and V5. The only difference between them is
the distance to the patient. So Nurse V5, who is the closest,
is called. Nurse V5 receives and answers the call. He goes
to P4 and completely finished the call. All the other calls
(the one of P5 and the urgency call) are also finished.
5.3. The advantages of a person oriented
system
The following advantages of the person oriented sys-
tem in contrast with the place oriented system could be de-
ducted:
• A staff member knows the exact location of the patient
who made the call.
• A staff member knows which patient made the call.
• The workload is distributed better among the different
staff members.
• Patients do not have to wait so long before their call is
treated.
• The wishes, the characteristics and the risks of the pa-
tient are taken into account.
• It is known for sure that the called nurse is in the vicin-
ity of the patient (or is the nearest possible person who
could be called).
990
• When a task is interrupted, the nurse does not have to
remember himself that he has to return to it. This leads
to lesser forgotten tasks and lesser work pressure on
the staff.
• When a nurse is called while he is already doing a task,
he is sure that the new call has a higher priority.
6. Conclusion
This article showed how context information could be
efficiently modeled by using an ontology. It was also il-
lustrated how this ontology can be used by reasoning al-
gorithms which take this context information into account.
This was illustrated with the development of a person ori-
ented nurse call system. The simulations showed that the
person oriented approach has many advantages over the
place oriented approach because it takes the context infor-
mation into account.
References
[1] S. Bechhofer, F. V. Harmelen, J. Hendler, I. Horrocks,
D. McGuinnes, P. Patel-Schneider, and L. Stein. Owl web
ontology language reference, December 2003.
[2] W. W. W. W. Consortium. http://www.w3.org/.
[3] T. P. O. Editor and K. A. System. http://protege.
stanford.edu/.
[4] T. Gruber. A translation approach to portable ontology spec-
ifications. Journal of Knowledge Acquisition, 5(2):199–220,
April 1993.
[5] S. Haiges. A step by step introduction to osgi programming
based on the open source knopflerfish osgi framework, Oc-
tober 2004.
[6] M. Horridge, H. Knublauch, A. Rector, R. Stevens, and
C. Wroe. A practical guide to building owl ontologies us-
ing the protégé-owl plugin and co-ode tools, August 2004.
The University of Manchester.
[7] D. Nardi, R. J. Brachman, F. Baader, W. Nutt, F. M. Donini,
D. Calvanese, D. McGuinnes, and P. Patel-Schneider. The
Description Logic Handbook: Theory, Implementation and
Applications. The Press Syndicate of the University of Cam-
bridge, Cambridge, UK, 2003.
[8] F. Ongenae. Design and implementation of a person oriented
nurse call system. Master’s thesis, Intec, UGent, Gent, 2007.
[9] D. Preuveneers, J. V. den Bergh, D. Wagelaar, A. Georges,
P. Rigole, T. Clerckx, Y. Berbers, K. Coninx, and V. Jonkers.
Towards an extensible context ontology for ambient intelli-
gence. In in Proc. EUSAI 2004, Eindhoven, pages 148–159,
November 2004.
[10] M. Strobbe, J. Hollez, G. D. Jans, O. V. Laere, J. Nelis, F. D.
Turck, B. Dhoedt, P. Demeester, N. Janssens, and T. Pollet.
Design of casp: an open enabling platform for context aware
office and city services. In in Proc. MUCS 2007, Munich,
pages 123–142, May 2007.
[11] H. K. P. T. Gu and D. Q. Zhang. Toward an osgi-based infras-
tructure for context-aware applications. Journal of Pervasive
Computing, IEEE, 3(4):66–74, October 2004.
[12] a. Televic NV, specialized in nurse call systems and multi-
media communications. http://www.televic.com.