View
212
Download
0
Embed Size (px)
Citation preview
An ontological framework for representing and exploiting
medical knowledge
Francisco Jesus Torralba-Rodrıgueza, Jesualdo Tomas Fernandez-Breisa, RafaelValencia Garcıaa, Juana Marıa Ruız-Sancheza, Rodrigo Martınez-Bejara,*,
Juan Antonio Gomez-Rubıb
aDepartamento de Ingenierıa de la Informacion y las Comunicaciones, Universidad de Murcia, CP30071 Murcia, SpainbServicio de Medicina Intensiva, Hospital Universitario Virgen de la Arrixaca, Carretera Madrid-Cartagena, El Palmar, CP30120 Murcia, Spain
Abstract
Patients on Intensive Care Units (ICUs) need continuous attention and monitoring. The patient may be connected to an alarm system, so
that an alarm is triggered when the state of the patient changes. In this work, we present an ontology-based approach to reduce the influence of
superfluous alarms. Our main goal was to build an intelligent system for ICUs, so that given a set of patient’s event, that system could check
whether the patient meets some diagnostic hypothesis in order to keep track of his/her correct evolution.
q 2003 Elsevier Science Ltd. All rights reserved.
Keywords: Knowledge Management; Intensive Care Unit; Ontology
1. Introduction
Nowadays, the importance of Knowledge Management
(KM) is growing in the Information Society and medical
domains are not an exception. In Yu-N and Abidi (1999),
managing knowledge in the healthcare environment is
considered to be important due to the characteristics of
healthcare environments and the KM properties. The
motivation for the work presented here is an ongoing
multidisciplinary research project taking place between an
AI group and a hospital aimed at modeling clinical events at
Intensive Care Units (ICUs). The ultimate objective is the
implantation of a KM system in that unit. From the ICUs
clinical management perspective, we intend to have the
decision making, the knowledge acquisition and manage-
ment processes in knowledge bases. So, such processes will
be more efficient in resources and time dimensions. On the
other hand, if the clinical management of the ICUs is made
through intelligent systems oriented to clinical manage-
ment, then, different clinical management variables (i.e.
doctors, equipment, nurses, etc.) will directly interact with
pure clinical variables.
An important problem in patient management is the
unfolding of illness over time, so that the representation and
analysis of clinical data cannot be performed without taking
into account its temporal dimension (Shahar, 2000). It can
be said that time is especially important when time-oriented
clinical data take part of decision support applications such
as determining a diagnosis or monitoring the evolution of a
patient (Shahar, 1999). This work deals with monitoring and
diagnosis through the use of intelligent alarms systems.
According to Lawless (1994), the purpose of measuring and
monitoring systems is to identify changes in variables which
previous experience or physiologic knowledge suggests are
likely to impair the viability of the tissues, organs, or
organism. Moreover, there is strong evidence that the use of
monitoring devices, if properly used, would prevent a
significant number of deaths or injuries (Tinker et al., 1989).
Conventional patients’ monitoring systems get physio-
logical signals and process them to extract reliable
information. When a certain parameter reaches a threshold,
an alarm is triggered informing about the existence of an
abnormal condition. Commercial patients’ monitoring
systems have some important problems to overcome such
as the low specificity of the alarms and the triggering of
superfluous ones. Each alarm warns about abnormal values
of a certain condition.
In ICUs, where response time is critical, it would be
desirable to have systems that apply alarm management
0957-4174/03/$ - see front matter q 2003 Elsevier Science Ltd. All rights reserved.
doi:10.1016/S0957-4174(03)00048-4
Expert Systems with Applications 25 (2003) 211–230
www.elsevier.com/locate/eswa
* Corresponding author.
E-mail addresses: [email protected] (R. Martınez-Bejar); fjtr2@alu.
um.es (F.J. Torralba-Rodrıguez); [email protected] (J.T. Fernandez-
Breis); [email protected] (R.V. Garcıa); [email protected] (J.M.
Ruız-Sanchez); [email protected] (J.A. Gomez-Rubı).
techniques, solving (some of) the problems mentioned
before. Nowadays, there is an increasing interest in the
development of patients’ monitoring systems that are able to
produce more significant outputs (smart alarms). One way to
do that is improving the quality of the information supplied
by the alarms by using the historical temporal evolution of
the patient. An alarm can be defined as a warning of an
approaching or existing danger and traditional monitoring
systems generate an alarms when the value of a variable is
higher than a pre-defined threshold.
In Van de Aa (1990), the main problems with traditional
alarm systems are described: (a) it is impractical to set all
the individual thresholds at the beginning, or during an
anaesthetic procedure; (b) alarms are not specific; (c) a
single variable alarm cannot point to possible causes; (d)
artifacts can trigger an alarm indiscriminately (false
alarms). Van de Aa (1990) presents a layered approach to
Intelligent Alarms, which is comprised of seven layers. The
most significant layers are the fourth and fifth ones, namely,
redundancy removal and the smart alarms. The fourth layer
is in charge of detecting and removing superfluous data and,
therefore, next levels only work with necessary data. The
smart alarms layer generates the alarms by looking at
different elements such as feature values, trends, or
combinations of variables. The intelligence of the approach
resides in this layer, which needs as much a priori
information as possible about the patient.
In this work, we move from an abductive diagnosis and
monitoring approach to a consistency-based one. According
to Lucas (1998), an abductive diagnosis is formalised as
reasoning from effects to causes, with causal knowledge
represented as logical implications of the form causes !
effects, where causes are usually abnormalities or faults, but
they may also include normal situations. On the other hand,
consistency-based diagnosis finds faulty device components
that account for a discrepancy between predicted normal
behaviour and actually observed behaviour. This discre-
pancy is formalised as logical inconsistency. In our work,
this discrepancy is measured by the inconsistency between
concepts from the hypothesis and the history of the patient.
We could also state that our system performs hypothetical
reasoning, because of its capability of producing multiple
diagnoses, generating different hypotheses and testing them
in parallel. In Haimowitz, Le, and Kohane (1995), an
approach for detecting trends by matching the data to
patterns is presented. This approach, in addition to the
consistency-based and the abductive diagnosis, could be a
third approach used for diagnosing. In that work, diagnosis
is related to trend detection and the patterns matching is
based on a regression model.
In literature, ontologies are commonly defined as
specifications of domain knowledge conceptualisations
(Van Heijst, Schreiber, & Wielinga, 1997). In Shahar
(1999), a domain knowledge ontology is presented as a
theory of entities (concepts), their properties (attributes),
and their relations in the domain. Our ontological model
covers three types of relationships: taxonomic, mereolo-
gical and temporal. In medical domains (Shahar, Miksch,
& Johnson, 1998), actions and effects are not necessarily
instantaneous, but actions are considered to have
temporal extensions, that is, actions can be expected to
be performed in a time interval or a period of time
(Shahar & Musen, 1996). This characteristic is covered
by the ontological model by measuring temporality in a
fuzzy manner. In this sense, another goal of our
ontological model was to cover the temporal dimension-
ality of actions (alarms in our case). These goals have
been reached through the design and implementation of
an ontology-based system for managing intelligent
alarms. This system is capable of deciding whether a
patient meets a diagnostic hypothesis or not, by doing an
efficient management of the alarms triggering (that is, by
detecting superfluous and false alarms). As pointed out in
Haimowitz and Kohane (1993), false alarm rates are very
high in current alarm systems and they can divert the
attention of doctors away from more important tasks. But
they are not the unique non-ideal alarms; false-negative
alarms and true-positive ones with inappropriate delays
should also be avoided. In Lawless (1994), the author
found that over 94% of alarms soundings in a paediatric
ICU might not be clinically important, the patient
movement being the most common cause of the false
alarms. Therefore, a reliable reduction of redundant and
false positive alarms in ICUs is definitely needed
(Haimowitz et al., 1995). The ontological model
introduced here is used from two different perspectives.
On the one hand, it is used to model the ICU, with its
personnel, equipment, patients and so on, that is, from an
organisational point of view. On the other hand, it is
used to model the clinical evolution of the patients of an
ICU. We have focused this work on a single ICU
although this approach can easily be extended to multiple
ICUs, which could share knowledge about diagnostic
hypotheses. The alarms’ triggering that warns about the
state of a specific patient are registered as events of that
patient and they will take part in the patient’s evolution.
This evolution is specified as an ontology, which is used
to check for the correctness of the patient’s evolution and
diagnosis.
Another objectives of this work was to take into
account the occurrence of cyclical (events or sets of
events that appear more than one time). For it, an
ontology-based framework for managing cycles is
proposed in this paper.
The structure of this paper is as follows. Section 2
provides an overview of the system. In Section 3, the
ontological framework used in this work is introduced.
Section 4 describes OBIAC tool, which implements a
system that meets the requirements. The validation of the
system is validated is Section 5. Finally, some conclusions
are put forward in Section 6.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230212
2. An overview of the framework
In an ICU, different actors can be identified: patients,
medical doctors, nurses, and medical equipment (alarm
systems, beds and so on). The purpose of this article is to
show an approach aimed at building a system able to
help medical doctors to follow the evolution of their
patients, by integrating the knowledge offered by physicians
and the knowledge collected from intelligent alarm systems.
Moreover, the clinical response time is a critical factor, so
that having a system that applies alarm management
techniques is very useful to avoid false and redundant
alarms, which are the main problems of current patients
monitoring systems. It would also be desirable to have
labeled alarms, which describe pathological states of
patients. The framework has been designed to meet all
these requirements.
2.1. Clinical events management
In our environment, four main entities, which are not
totally independent one another, can be distinguished:
patient (diagnostic) hypothesis, medical staff and event.
Both the evolution of the patients and diagnostic hypotheses
are defined through a set of events. An event occurs in a
specific environment, which is determined by the patient
and his/her disease. That implies that the event must
have some type of relationship with the rest of elements
(events) that exist in its environment. The measurement of
such relationships will depend on the type of event. In case
of patient events, such relations are quantified by means of
natural numbers, whereas in case of hypothesis events, the
relations have to be measured in a fuzzy way. The reason for
such difference is that the state of the patient changes at a
particular time point, so that the temporal relation between
two hypothesis events cannot be specified so precisely as for
patients because there can be differences between different
patients. Therefore, a fuzzy measurement is required for
quantifying such relations. In particular, three fuzzy
relationships have been used in this work: (a) approximately
x time units later; between x and y time units later; (c)
exactly x time units later.
There are events whose existence determine a particular
diagnosis or that constrain heavily the possible diagnoses.
There may also be events that cannot occur if the patient
suffers from a particular disease. All these issues can be
summarised in four criteria.
Criterion 1. It follows from the requirement of the
existence of a series of events for a particular disease. It
establishes the minimum set of events that have to be
present in the evolution of a patient so that the correspond-
ing diagnostic hypothesis is acceptable.
Criterion 2. It establishes which events cannot appear
in the evolution of a patient diagnosed with a specific
disease. Let us suppose that the patient P suffers from C
and the diagnostic hypothesis for such disease implies
that the events A and B are incompatible in the context
of this hypothesis. Then, if A and B appear in the
evolution of the patient P then C is not a valid diagnosis
for P.
Criterion 3. It establishes the possibility of admission for
series of events whose existence is not compulsory for the
existence of a particular disease. That is, even though minor
events/criteria specified in the diagnostic hypothesis do not
appear in the evolution of the patient, the diagnosis for the
patient would not become invalid.
Criterion 4. If the hypothesis is defined along some days
(i.e. 10 days) and the patient evolution is less than this
quantity (i.e. 5 days), there should be events in the
hypothesis that cannot appear in patient evolution, because
it is not the moment (these events will be called ‘Future
Events’, because they must appear in the future). So, when
checking a patient evolution with a hypothesis, these events
do not have to be taken into account.
The sets of events defining particular diagnostic
hypotheses are not usually linear throughout the timeline
but they contain cycles, which are ordered sets of events that
may occur more than once to the patient. Therefore, this
special type of cyclical events must be modelled in a
particular way. For this purpose, a diagnostic hypothesis
will be comprised of individual events and cycles. On the
other hand, the evolution of the patient will be comprised of
individual events and the occurrence of instance of the
hypothesis cycles must be detected. To do this the following
general algorithm for checking whether the evolution of the
patient follows the pattern indicated by a specific diagnostic
hypothesis will be followed:
1. If the diagnostic hypothesis contains cycles, then detect
such cycles in the patient’s evolution.
2. If some cycle is found, then replace the individual
events that are part of the cycle by the cycles that
appear in the patient’s evolution.
3. This step is comprised of two actions.
a. Check whether the event-related criteria are met.
b. Check the temporal consistency between the
diagnostic hypothesis and the temporal evolution
of the patient.
4. If both are consistent, then it is acceptable that the
patient evolves according to the diagnostic
hypothesis.
Moreover, the resulting system will assign a value to the
hypothesis. This value will be a measure of the accuracy of
the diagnosis process, in such a way that the closer the
evolution of the patient is to the hypothesis, the higher the
value will be. Therefore, the hypothesis will not be accepted
unless its associated value is greater than a determined
threshold. This threshold will be established manually by
the user, so that the degree of exigency imposed to the
system is variable.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 213
2.2. Other framework’s possibilities
One of the problems with traditional patient monitoring
systems is the existence of false alarms, that is, alarms that
are triggered but that do not have any real influence on the
patient’s evolution. When the correction of a diagnostic
hypothesis is checked, the system labels alarms as either
positive or false, and it will not take into account the false
ones in the process of detecting whether the patient meets a
specific temporal pattern (i.e. a diagnostic hypothesis) or
not. A problem comes up when a false alarm is not false as
such but it has been forgotten by the medical doctors when
they have specified the temporal pattern of the hypothesis.
As a consequence of carrying out the process of checking
whether both ontologies, the one representing a diagnostic
hypothesis and the other one representing the patient
evolution, are consistent, the system will be capable of
discovering events, if any, from the patient ontology that do
not belong to the diagnostic hypothesis. This might happen
due to different reasons, such as a false or a missing alarm.
In this case, medical doctors could have forgotten an event
or the event could be medically unknown when the
hypothesis was constructed. The framework has been
designed so that the system asks experts (medical doctors)
whether the new alarm must be part of the diagnostic
hypothesis. In case their answer is affirmative, temporal
constraints should be added to the event to establish its
relationships with its environment (disease).
The system will help to make the decision about a
patient’s diagnosis when this is not clearly known. It could
be thought that the patient has the diagnosis proposed by a
medical doctor, but diagnosis in ICUs is frequently
uncertain. Then, we could try to test the patient’s evolution
with different hypotheses. The system will allow for this
partial testing process by selecting the patient and the set of
diagnostic hypotheses to check. This request would result in
a set of possible diagnostic hypotheses whose temporal
pattern is met by the temporal evolution of the selected
patient. Each candidate hypothesis would then be given a
value according to the different tests made and the best
candidate. If this value is greater than the threshold
established by the expert, then the hypothesis will be
acceptable for the patient.
3. The ontological framework
3.1. Ontologies in medical domains
Ontologies have been used for representing knowledge in
clinical domains, although they have been used for different
purposes. In this section, some examples are mentioned. In
Schulz and Hahn (2001), an ontology engineering frame-
work for the anatomy domain is proposed. An ontology has
also been used in the NeoGanesh system (Dojat et al., 1997)
and in the Deja Vu system (Dojat, Ramaux, & Fontaine,
1998) to model the world into two types of entities: (1)
atemporal entities, used to model the observed system, and
(2) temporal entities, used for modelling the evolution.
YAQ (Uckun, Dawant, & Lindstrom, 1993) is another
example of ontology applied to model-based reasoning in
physiologic domains. RESUME (Shahar & Musen, 1996) is
another system that uses ontologies in medical domains.
3.2. Ontologies in this work
An ontology is viewed in this work as a specification of a
domain knowledge conceptualisation (Van Heijst et al.,
1997). In addition, ontologies will be represented here by
means of multiple hierarchical restricted domains (MHRD)
in a similar manner to that employed by other authors (see,
for instance, Eschenbach and Heydrich (1995)). In particu-
lar, we term MHRD to a set of concepts holding the
following:
† They are defined through a set of attributes, so that the
presence of axioms between these attributes will not be
considered.
† There can be taxonomic relations among concepts, so
that attribute (multiple) inheritance is permitted.
† There can also be mereological and temporal relation-
ships among the concepts.
In addition to this, the ontology representation schema
adopted here includes ‘structural’ axioms, that is, axioms
drawn from the proper structure of the ontology. It should be
clarified that defining ontologies without non-structural
axioms does not mean that this sort of axioms cannot be
defined as a (part of the) specification of a conceptualisation.
What we do is to split up the classic definition of ontology
(i.e. the one including structural and non-structural axioms)
into two parts so that we term ontology to the whole
specification of a conceptualisation excluding non-struc-
tural axioms.
Taxonomic and partonomic relationships have widely
been used in ontological models and they are considered as
basic relationships to be covered by an ontological model
(Borst, 1997; Schulz, Romacker, Faggioli, & Hahn, 1999;
Shahar & Musen, 1996). Temporal relationships have also
been used in clinical domains and they are considered to be
significant. Moreover, various qualitative and quantitative
temporal relationships can exist between measurements and
interventions. In particular, temporal relationships are
essential in our domain (i.e. in ICUs) to model the temporal
evolution of a patient and the temporal relationships
between the different events of a patient’s clinical history.
Regarding partonomic relationships among concepts, the
(mereological) part-of ontologies defined here will be
supposed to hold irreflexivity, and asymmetry. On the
other hand, although there are other properties that may be
present in partonomic ontologies, we will constrict our-
selves to analyse partonomic organisations by taking into
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230214
account the previous (mereological) properties and some
other (new) attribute-based ones. Concerning temporal
organisations, this type of organisation can be seen as
temporal graphs/networks in a similar sense to that used in
Wainer and de Melo Rezende (1997). In order to represent
possibility, the membership function has been used. This
function has been used, for instance, in Jones, Harrison, and
Lowe (2001) and Lowe, Harrison, and Jones (1999) for
modelling fuzzy trends.
3.3. Some ontological definitions
Some ontological definitions are introduced in this
section. Such definitions will be used in next sections.
These definitions have already been used in Fernandez--
Breis and Martınez-Bejar (2000a,b).
Definition 1. Equivalent concepts. Two concepts A and B
belonging to different ontologies are said to be equivalent if
their respective sets of attributes are equivalent (their
attributes have the same names) and their respective sets of
parent and child concepts are also equivalent (each parent
concept of A has an equivalent concept amongst the parent
concepts of B or one of them has no parents).
Definition 2. Equivalent ontologies. Two ontologies A and
B are equivalent when for every concept c belonging to A
there is a concept c0 in B such as c and c0 are equivalent.
Definition 3. Inconsistent concepts. Two concepts A and B
belonging to different ontologies are inconsistent if they
have the same name, their respective sets of parent and
children concept are equivalent but they have no common
attributes.
Definition 4. Inconsistent ontologies. Two ontologies A and
B are inconsistent if there is a pair of concepts c1 and c2; one
belonging to A and the other one belonging to B, such that
c1 and c2 are inconsistent concepts.
3.4. Ontological representation of cycles
A cycle can be seen as a (sub)ontology whose root
concept is the name of the cycle and each particular event is
a mereological child of that root concept. However, some
assumptions and properties concerning cycles should be
introduced:
† A cycle is a leaf node of the ontology that specifies the
diagnostic hypothesis.
† The events included in a cycle cannot appear in the rest
of the diagnostic hypothesis (i.e. the ontology).
† The events included in a cycle must be independent of
the events that are not members of the same cycle.
A cycle can be more formally defined as follows.
Definition 5. Cycle. A cycle Cy(t) is a set of concepts
(events) {c0ðtÞ; c1ðtÞ;…; cnðtÞ}; holding the following prop-
erties:
1. The events included in the cycle cannot appear in the rest
of the diagnostic hypothesis.
2. There can only be temporal relationships between ciðtÞ
and cjðtÞ i . 0; j . 0; i – j:
3. c0ðtÞ is the root of the cycle and it is the mereological
parent of the other cycle events.
4. The cycle is a leaf node of the ontology that specifies
the diagnostic hypothesis.
Now, provided that a cycle can be seen as an ontology,
functions to check for both the equivalency and the
consistency among two cycles can be defined.
Definition 6. Cycle_equivalency. Let cycle1(t) and cycle2(t)
be two cycles. Then, it is said that they are equivalent
cycles, written cycle_equivalency (cycle1(t), cycle2(t)) if
equivalent_ontologies (cycle1(t), cycle2(t)).
Definition 7. Cycle_consistency. Let cycle1(t) and cycle2(-
t) be two cycles. Then, it is said that they are consistent
cycles, written cycle_consistency (cycle1(t), cycle2(t)) if
not (inconsistent_ontologies (cycle1(t), cycle2(t))).
Therefore, when checking whether two ontologies are
consistent or equivalent and the current concept is a cycle
then the corresponding function for cycles will be applied.
3.5. Ontology-based consistency
Now, the algorithm to check for the consistency between
the temporal evolution of a patient and the diagnostic
hypothesis must be modified since cycles can appear in the
model. The algorithm used is described in the following
lines. First, let us introduce an example that will be useful
for illustrating the process. Let us suppose that the
diagnostic hypothesis is given by Table 1. The hypothesis
is comprised of a set of individual events X0; X1; X2; and X3
and two cycles, Cycle1 and Cycle2. Moreover, the
diagnostic hypothesis is formulated in a way so that
Table 1
The diagnostic hypothesis
Event Time
X0 0 min
X1 Approx. 5 min after X0
X2 Approx. 3 min after X0
X3 Approx. 10 min after X1
Cycle1 Approx. 2 min after X1
Cycle2 Approx. 3 min alter X2
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 215
the members (events) of the set {X1; Cycle1} must appear
compulsorily in the evolution of patients for the disease
under question.
Each cycle is defined in the following way. Cycle1 is
comprised of the events E1 and E2; so that E2 occurs after
E1: Cycle2 is comprised of the events E3 and E4; so that E4
occurs after E3: There is not a quantified delay between the
occurrence of events E1 and E2; nor between E3 and E4: Let
us also suppose that there is a patient connected to our
system through an intelligent alarm system. Thus, the
temporal evolution of that patient could be defined by the
sequence of events shown in Table 2.
Step 1. Checking for the existence of cycles in the
diagnostic hypothesis. In this step, the ontology that
represents the diagnostic hypothesis must be checked in
order to know whether it contains cycles or not. In case
cycles are not included in the diagnostic hypothesis then, go
to the Step 4 of this algorithm. The input of this step is the
ontology representing the diagnostic hypothesis, and the
output is a boolean value that indicates whether the
algorithm must go to Step 2 or 4.
In our example, through this step we check whether the
diagnostic hypothesis contains cycles and it can be observed
in Fig. 1 that the hypothesis contains two cycles, Cycle1 and
Cycle2 so that Step 2 is the following step of the algorithm.
Step 2. Identifying cycles. In this step, the cycles
included in the diagnostic hypothesis must be searched in
the temporal evolution of the patient. For it, the individual
events of each cycle are individually identified in the
patient’s ontology. Once all the individual events of a cycle
have been found, the cycle’s internal temporal consistency
must be checked. In case the cycle is not consistent, both
ontologies are directly labelled inconsistent, so that the
algorithm returns the inconsistency found. The inputs for
this step are the ontologies that represent the patient’s
temporal evolution and the diagnostic hypothesis. The
output is the set of cycles included in the diagnostic
hypothesis identified in the patient’s temporal evolution.
When analysing the example ontology shown in Table 2
that represents the temporal evolution of the patient under
question, the individual events of both cycles are found. In
particular, Cycle1 occurs twice during the period of time
covered by this example, and Cycle2 just once. First, all the
appearances of Cycle1 should be identified. For it, its
individual events must be searched in the ontology. An
appearance of E1 is found at the time point 5 min 50 s and
one of E2 at 7 min 37 s so that the (internal) temporal
constraint associated to Cycle1, namely that E2 occurs after
E1; is met and therefore the cycle is identified. A second
appearance of E1 is found at 15 min 13 s and the second one
of E2 is found at 16 min 7 s as well. On the other hand, the
cycle Cycle2 is also identified in the patient’s evolution. Its
individual events are found at 7 min 25 s ðE3Þ and 8 min
ðE4Þ:
Step 3. Inclusion of the cycles. The alarm system is
not capable of detecting cycles but warning about
individual events, which may or may not belong to a
cycle. The previous step is in charge of detecting the
existence of those cycles in the patient’s evolution. The
individual events identified in the evolution of the patient
as part of the cycles defined in the corresponding
Fig. 1. The ontology after including the cycles.
Table 2
The patient’s evolution
Event Time
X0 0 min
X2 2 min
X1 4 min 20 s
E1 5 min 50 s
E3 7 min 25 s
E2 7 min 37 s
E4 8 min
X3 14 min 45 s
E1 15 min 13 s
E2 16 min 7 s
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230216
diagnostic hypothesis are replaced by their respective
cycles in the patient’s evolution. Each individual event
has an occurrence time assigned to it so that the cycle
that replaces a set of events must also be assigned an
occurrence time. In particular, the occurrence time
assigned to the cycle will be the occurrence time of
the first event included in the cycle. In case the same
cycle is identified more than once in the patient’s
evolution, the cycle will only appear once while the rest
of appearances will be removed from the evolution of the
patient. The inputs for this step are the inputs for Step 2
and the output of Step 2. The output is a new ontology
representing the temporal evolution of the patient but in
which the cycles are included.
Example. In our example, the ontology representing
the evolution of the patient would be transformed into
the one shown in Fig. 1.
Step 4. Checking for the consistency of the patient’s
evolution and the diagnostic hypothesis. For this purpose,
the procedure is the same as the one used in the method
without cycles. For this step, a cycle will be considered as a
simple node, since checking for the consistency only takes
into account the temporal relationships and the occurrence
times for each event/cycle. Then, there will be two
ontologies, representing the evolution of the patient and
the diagnostic hypothesis, respectively. Moreover, the
consistency of these two ontologies will be checked by
means of the function consistent_ontologies.
Example. At this stage, it must be checked the
consistency between the diagnostic hypothesis and the
patient evolution. For it, it can be seen in Tables 3 and 4
the temporal measurement for the events belonging to the
corresponding temporal chains. Both ontologies are
consistent from a temporal point of view since the
occurrence time of each patient event belongs to the time
interval established in the diagnostic hypothesis. Therefore,
the patient can be diagnosed the disease specified by the
hypothesis.
Step 5. Finally, the event-related criteria must be
checked. In this example, the evolution of the patient is
applied the criterion stating that X1 and Cycle1 are events
that have occurred to the patient.
4. OBIAC tool
In this chapter, we will explain how this tool works.
Once the OBIAC tool is launched, the main window is
displayed (Fig. 2). There, the user should be able to see the
list of patients that exist at that particular time within the
system. They will appear in the list labeled ‘PATIENTS’. In
the list labeled ‘HYPOTHESIS’, the list of hypothesis that
exist at that particular time within the system is shown. On
the right hand-side, the information of the selected patient is
shown. Such selection is made by clicking on the name of
the corresponding patient.
By clicking on the button labeled ‘Patient Evolution’ or
by selecting the option ‘Patient ! Evolution’ in the menu,
the description of the patient evolution since its entrance is
displayed in natural language in an independent window
(Fig. 3).
In order to see the expected evolution of a hypothesis, the
user has to use the option ‘Hypothesis ! Expected
Evolution’ (Fig. 4).
The menu bar in the main window permits users to create
and modify the elements of the system.
4.1. Adding patients and hypothesis
The first element to consider is (obviously) the patient.
To create a new patient, we will select ‘Management !
New Patient’, and then, the new patient window should be
opened (Fig. 5). In that window, the following patient data
are input: name, age, diagnosis and entrance date (this field
is automatically set by OBIAC but it may be changed), if he/
she is diabetic and/or hypertensive, and the medicament
allergies that he/she suffers (including comments that were
necessary, i.e. alternative medicament). Moreover, a
registration number should appear. This number is assigned
by the system, and it cannot be modified. It will be useful to
identificate patients (especially if they have the same name).
To introduce a diagnosis for the patient, this may be chosen
by selecting it in the combobox labelled ‘Possible
Diagnosis’, where all the hypothesis kept by the system
appear.
Once the patient data has been introduced, then, by
clicking on the ‘Add’ button, the patient will be inserted into
the system database. Then, the buttons ‘Add Other’ and ‘Add
Event’ will be activated, so that new patients or events for
Table 4
The patient’s evolution
Patient evolution Exact occurrence time
X0 0 min
X2 2 min
X1 4 min 20 s
Cycle1 5 min 50 s
Cycle2 7 min 25 s
X3 13 min 15 s
Table 3
The hypothesis
Hypothesis Fuzzy occurrence time
X0 0 min
X2 Approx. 3 min
X1 Approx. 5 min
Cycle2 Approx. 6 min
Cycle1 Approx. 7 min
X3 Approx. 15 min
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 217
the new patient may be defined. It must be taken into account
that the Add button is disabled once the new patient is added,
because this patient cannot be added again. By clicking on the
‘Done’ button, the new patient window will be closed.
New hypotheses may also be created through the option
‘Management ! New Hypothesis’, and then, the new
hypothesis window is opened (Fig. 6). In that window, the
hypothesis description (i.e. ‘arrythmias’) is introduced. As
for creating patients, once the new hypothesis is added,
events and new hypotheses may be defined.
Patients and hypothesis are composed of events. An event
is a fact that is produced in a patient (or hypothesis) at a
specific moment. Moreover, events may have an associated
magnitude value (i.e. increase of temperature ¼ 0.5 8C).
This value may be numeric (i.e. obtained through a
medition), but sometimes, medicians prefer using literal
values (i.e. corporal temperature is very high). In OBIAC,
both options are permitted.
4.2. Adding events
If we want to add a new patient event, we have to choose
the option ‘Patient ! Add Event’ after selecting the patient
in the main window (or clicking on Add Event when
creating a patient as it was stated before). In that case, the
new event window will be opened (Fig. 7). There, the
description and the value of the event must be introduced.
To introduce the event description, the user may introduce
either a new description or select an existing one.
To introduce the event value, the user may insert a
numeric value and/or select a fuzzy one (a literal value)
from the combobox labelled ‘fuzzy value’. The possible
Fig. 2. Principal OBIAC window.
Fig. 3. Patient Evolution window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230218
diffuse values are: ‘very-high’, ‘high’, ‘middle-high’,
‘middle’, ‘middle-low’, ‘low’, ‘very-low’ (Fig. 8).
After introducing the event data, the event is inserted into
the system database by clicking on the Add button. When
the data base is updated, we can add other event pushing
Add Other button, or start the ‘Edit Event’ window pushing
Edit Event button (we will see this window later).
4.2.1. Hypothesis events
We can add hypothesis events in similar way as for
patient events, by selecting the option ‘Hypothesis ! Add
Event’ after having selected a patient, but there are some
differences (Fig. 9).
Hypothesis events are facts that are expected to appear in
patient evolutions. But not all the patients develop all the
Fig. 4. Hypothesis expected evolution.
Fig. 5. New Patient window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 219
events with the same magnitude (i.e. patients that suffer flu,
their fever will be between 37 and 40 8C. Hence, a flu
hypothesis saying that fever will be exactly 38 8C cannot be
defined. So, when introducing the hypothesis event value in
the field ‘Numeric Value’, two numeric values defining a
range (i.e. for event ‘fever’, such values would be 37 and 40)
are expected.
In addition, there are events, which are incompatible
in the context of a hypothesis. If such events appear in
the same patient evolution, such hypothesis must be
rejected. So, after creating an event, its incompatible
events may be defined by clicking on the button labeled
‘Incompatible’.
On the other hand, not all the patients develop all the
events. There are events, called major events, which are
compulsory for concluding that the patient is developing the
diseases. However, other events, called minor events, are not
compulsory. This quality of the event is input by selecting
‘Major’ or ‘Minor’ in the combobox labelled ‘Type’. The
value ‘kLaterl’ can be chosen for delaying this qualification
(Fig. 10).
Moreover, some ‘minor events’ are more important than
others. For this purpose, a priority value must be selected
from the combobox labelled ‘Priority’. The possible priority
values are: very-high, high, middle-high, middle, middle-
low, low, very-low (Fig. 10).
Fig. 6. New Hypothesis window.
Fig. 7. New Event window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230220
4.3. Editing events
After creating hypothesis or patient events, they can be
edited by selecting a patient (or hypothesis) in the main
window and either selecting ‘Patient (or Hypothesis) !
Edit Event’ or clicking on the Edit Event button once the
event has been added. Then, the Edit Event window is
opened for the selected patient or hypothesis (Figs. 11 and
12). There, the event values (i.e. numeric and/or diffuse) and
its temporal relations can be edited.
Another event of the selected hypothesis (or patient)
without closing the window, by selecting it in the combobox
labelled ‘OBSERVATION’. The type and the priority of
events can also be changed. Finally, incompatible events
may also be checked and modified.
4.3.1. Temporal relations
Once hypothesis events have been introduced, time
relations between hypothesis events must be defined in
the Edit Event window. In the list labelled ‘Temporal
Relations’, all the relations between the edited event and
the rest of selected hypothesis (or patient) events appear.
A temporal relation between patient or hypothesis
events can be added by clicking on the ‘New’ button,
edited by clicking on the ‘Edit’ button in edit event
Fig. 8. Event diffuse value.
Fig. 9. New Hypothesis Event window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 221
window, or removed by selecting it and clicking on the
‘Remove’ button (Figs. 11 and 12).
In this window, a new relation between the current event
and another patient (or hypothesis) event can be defined. To
indicate that the chosen event will occur before, the user will
choose ‘BEFORE’. If the chosen event must occur after,
‘AFTER’ will be the selected option (Fig. 14).
Now, the relation type must be selected. There are three
types of relations, namely (Fig. 14):
† Exactly: Event A will occur exactly x s before/after
Event B.
† Between: Event A will occur between x and y s before/
after Event B.
† Approximately: Event A will occur x s before/after Event
B (^20% error).
Finally, the time delay is specified. This is introduced by
using two sets of comboboxes accounting for temporal
categories (i.e. seconds, minutes, hours and so on). If the
relation type is ‘Exactly’ or ‘Approximately’, the second set
will be ignored (Fig. 14).
A temporal relation is correct if there is not any cycle
between temporal relations (i.e. a before b, b before c, c
Fig. 10. Type and priority values.
Fig. 11. Edit Patient Event window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230222
before a), and there is not any other temporal relation
between the same events. If the temporal relation is not
correct, an error message will appear.
Editing a temporal relation. On the other hand, a
temporal relation can be edited by selecting it and clicking
on the Edit button. The relation would be displayed and the
user may modify it as in the previous case. The functionality
of this window, labelled ‘Editing a link for the event’, is the
same that we have described before (Figs. 13 and 14).
4.4. Creating/editing incompatible events
The window shown in Fig. 15 appears when the user
wants to edit incompatible events. There, all the events,
which are incompatible with the current event, are
shown. The list of the existing system events is also
shown.
The dialog for creating a new incompatible event (see
Fig. 16) is displayed by clicking on Add Event. This
window is similar to ‘New Hypothesis Event’ one, although
in this case the Add Other and Edit Event buttons and the
combobox to select the description do not exist. Moreover,
there is not type nor priority value.
4.5. Creating/editing cycles
In order to describe cycles, the option ‘Hypotheses !
Add Cycle’ must be selected. Then, the ‘New Cycle’
window will be opened (Fig. 17). As for hypothesis events, a
Fig. 12. Edit Hypothesis Event window.
Fig. 13. New/Edit Temporal Relation window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 223
code (generated by OBIAC) will be assigned to it. Its
description, type and priority value must be specified.
Once the cycle is introduced, its events must be defined.
The ‘New Cycle Event’ window will be shown by clicking
on Add Event. This window is exactly the same as the one
for creating hypothesis events (see Fig. 9).
All the events appear in the list labelled as ‘Cycle Events’
followed by its numerical and fuzzy values (i.e. ‘EventD
{from 0.2 to 0.4} {Low}’). If one is selected, the ‘Edit Cycle
Event’ window will be opened with the event data. Event
values and temporal relations between cycle events may be
added, edited, or removed as for hypothesis events.
However, cycle events can only be related to cycle events.
A cycle can be considered a sub-hypothesis into a
hypothesis. On the other hand, the cycle, as an element of
the hypothesis, has type and priority values and it can have
incompatible events.
4.5.1. Editing cycles
Fig. 18 is the corresponding window for editing cycles.
This window is similar to the New Cycle window with small
differences. First, on the top of the window, the hypothesis
Fig. 14. New/Edit Temporal Relation window options.
Fig. 15. Incompatible Events window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230224
cycle description field appears in a combobox where the
cycle to edit is selected. On the other hand, the Add button
has been changed by the ‘Update’ button, which is used to
update cycle data (not cycle events data) in system database.
Finally, there is not an Add Other button.
4.6. The diagnosis process
OBIAC allows for comparing the patient evolution with
a diagnostic hypothesis to confirm a particular diagnosis. To
do that, the option ‘Patient ! Check’ is provided. The user
Fig. 16. Create Incompatible Event window.
Fig. 17. New Cycle window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 225
must select a patients and a set of candidate hypotheses for
performing such checking. There are some aspects that must
be taken into account when checking patient evolutions with
hypotheses.
4.6.1. The accuracy problem in OBIAC
Patients who develop the same disease usually show
different symptoms. If all hypothesis events appear correctly
in the patient evolution, the hypothesis must be accepted,
but it would be wrong to use only event occurrence times for
such measurements. So, OBIAC evaluates how much the
patient evolution approximates the hypothesis description,
taking into account parameters such as the type and priority
values of the hypothesis events.
First, Major events must always appear correctly in the
patient evolution. If a Major event does not appear in such
evolution, the hypothesis is rejected. If all the Major events
appear in patient evolution, the error in Minor events must
be calculated. For this purpose, a hypothesis value (HV) is
calculated by using all hypothesis events (except Future
Events) priority values. This priority value is fuzzy, but
numeric values are required for this computation, so that a
numeric value must be assigned to each fuzzy value, as
follows:
Diffuse value Numerical value
Very-high 7
High 6
Middle-high 5
Middle 4
Middle-low 3
Low 2
Very-low 1
To establish the HV, OBIAC will sum all the non-Future
Events priority value.
Once HV has been calculated, the value for the patient
evolution, and the measurement of the hypothesis compli-
ment (HC) must be obtained. For it, the system will sum the
non-Future Events priority value of those events that appear
in patient evolution correctly (with correct value, and in
expected time). Finally, HV and HC are compared.
Concretely, the percentage of HV that is complimented in
patient (HC) is calculated. This is the compliment value of
the hypothesis (CV).
CV ¼ ðHC £ 100Þ=HV
Now, a threshold value to accept or reject the hypothesis
must be established. It is called the ‘Acceptation Value’.
This can be done by using the option ‘Management !
Acceptation Value’.
Some observations about the acceptation value must
be made. If it is equal 100%, no minor event can fail.
On the other hand, if it is equal to 0%, all minor
events can fail. In this latter case, if all Major events
appear correctly in patient evolution, the acceptance of
rejection of the hypothesis will be independent of Minor
events.
4.6.2. OBIAC diagnosis information
OBIAC compares the patient evolution with the
hypothesis, which represents the expected evolution.
These are the possible outputs for this process:
† Case 1. Patient evolution fulfils exactly the hypothesis.
† Case 2. Patient evolution fulfils every major events but
not every minor events.
Fig. 18. Edit Cycles window.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230226
† Case 3. Patient evolution does not fulfil every major
events.
† Case 4. There are incompatible events.
In the first case, the hypothesis is completely accepted.
For Cases 3 and 4 the hypothesis will be rejected. For Case 2
the response will depend on the priority of the events that
have failed, the HV (priority value of all events) and the
acceptation value established at this moment.
In each case, the application output is shown to the user,
as well as the reasons for the decision made, and, if the
hypothesis is accepted, it will show information about future
events and false alarms. So, the application output is as
follows:
† Case 1 (Fig. 19). It will appear an acceptation window,
followed by a window with Future Events (if there is
almost one). Then, a window with the events (if there is
almost one) that are part of a cycle in the hypothesis, but
do not form one complete or have errors is displayed. It
should be noticed that if the cycle appears once, the event
that represents it is accepted as correct, but it could have
other occurrences with errors. Finally, the false alarms (if
there is almost one) are shown.
† Case 2. It will appear the list of inconsistent events with
the reason of the failure (i.e. ‘INCONSISTENT
VALUES’). Next, the resolution (i.e. acceptance or
rejection) and the percentage of compliment of the
hypothesis are shown.* If the hypothesis is accepted, future events and false
alarms lists (as in Case 1) are shown. The events that
appear in the hypothesis but not appear in patient (if
there is almost one), called expected events, are also
displayed. If there are expected events, it may mean
that those events have not been noticed in the patient
(someone may be forgot to do it), so it is important to
take them into account (Fig. 20).* If the hypothesis is rejected, the list of expected events
(if there is almost one) is shown (Fig. 21).
† Case 3 (Fig. 22). The list of inconsistent events, major
and minor, as well as the failure reason is displayed.
Next, the rejection window (without HC value) appears,
followed by a window with major events that have failed.
Finally, if there is almost one, the expected events are
listed.
† Case 4 (Fig. 23). In this case, the list of incompatibilities
and the rejection window are shown.
5. Validation of the system
The system described in the previous sections has been
validated across ICU domain which is a very a particular
domain. When a patient enter in a ICU, the diagnosis has
been done. Physicians and ICU personal normally control
that the vital constants values of patients are normal. Next,
we briefly describe how OBIAC can be used in this domain.
In most situations, physicians must describe vital constants
as cycles when describing a particular hypothesis. There are
two manners to do it:
† Describing each vital constant to control as a cycle, so,
each cycle contain an event that describes the event range.
† Grouping events (each group is a cycle). For example,
vital constants that are controlled in every ICU patient
(cardiac frequency, arterial pressure, etc.), and those that
are particular for each hypothesis (for example, in craneal-
encefalic traumatism, medicians will control intracraneal
pressure and other specific values).
Fig. 19. Example of Output in Case 1.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 227
On the other hand, the controlled vital constants values of
patients will be introduced in the application. When ICU
staff inputs patient data the patient evolution can checked
against his/her diagnosis. If there are any problem with
the events of a cycle, there will appear the ‘Faults detected
in Cycle events’ window. The ICU personal can see in that
moment the event priority and type, and will know whether
the fault is an emergency.
Fig. 20. Example of Output in Case 2 (hypothesis accepted).
Fig. 21. Example of Output in Case 2 (hypothesis rejected).
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230228
6. Discussion and conclusions
In this work, we have presented to framework for
managing intelligent alarms in order to monitor patients’
state in ICUs. The motivation for the work described eats
from to Spanish Government-funded project whose objec-
tive is to perform KM in ICUs. This aspect has been
considered necessary elsewhere (Yu-N & Abidi, 1999).
There, managing knowledge in the healthcare environment
is considered to be important due to the characteristics of
healthcare environments and the KM properties. For it, the
management of medical terminology and its evolution is
considered to crucial element (Oliver, Shahar, Shortliffe, &
Musen, 1999). The main technology used in this work has
been the ontology. Ontologies have previously been used to
do temporary abstractions. Thus, in Shahar et al. (1998) an
ontology-based approach facilitates acquisition, mainten-
ance, sharing and reuse of the required storm-abstraction
knowledge. As stated in Schulz et al. (1999), for medical
domains it is not adequate to have only taxonomic and
mereological constraints. Physiological events have tem-
porary dimensionality as well. Therefore, we must take this
into account for choosing the kind of ontological model to
uses. Our approach exploits the significant advantage of
ontologies, namely, reuse, since existing ontologies may be
easily reused for constructing new ones which are related to
the previous ones (i.e. similar hypotheses, similar ICUs,
etc.). The use of ontologies we have made in this work
intends to achieve the same goal as the parameter-properties
ontology that appears in Shahar and Musen (1996).
The ontological temporality has been exploited in this
work mainly for modeling the temporal evolution of patients
and diagnostic hypotheses. In Allen (1984), 13 possible
temporal relationships are specified although they can be
seen as seven and their respective inverse, except in the case
of the ‘equal’ relation. In our work, the unique temporal
relation used has been the AFTER relation which has the
BEFORE one as its counterpart. In the aforementioned
work, a general theory of action and time was pursued and
actions have both starting time and duration. On the other
hand, our work only needs to have information about the
instant or time interval at which an alarm is triggered. Since
in this work we do not focus on the event duration itself, but
on the event sequence, the temporal relations that appear in
Fig. 22. Example of Output in Case 3.
Fig. 23. Example of Output in Case 4.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230 229
that work concerning duration of action have not been
considered.
In this work, hypotheses and temporal evolution of
patients are confronted in order to know the correct
diagnosis for a patient, while in Shahar et al. (1998) we
could find equivalent figures for them. The equivalent for
hypotheses are clinical guidelines, obtained during design
time from (medical) experts. During the execution time we
would have the patient’s state, which could be considered as
the equivalent to the temporal evolution of the patient in our
system. Our approach follows a similar philosophy, and our
higher level concepts could be considered to be the
diagnostic hypotheses together with the ontologies that
represent the temporal evolution of patients, although our
system does not try to create temporal abstraction in the way
done in RESUME (Shahar & Musen, 1996). In this sense, it
can be said that our approach is closer to the TrenDx system
(Haimowitz & Kohane, 1993) given that our goal is not to
abstract from the data but checking for the correctness of a
particular diagnosis and suggesting when the diagnosis is
unknown. The approach presented in Haimowitz et al.
(1995) is similar to our approach because both works
implement some kind of pattern matching.
The framework will allow to automatically decide
whether a patient meets a diagnostic hypothesis or not, by
doing an efficient management of the alarms triggering (that
is, by detecting superfluous and false alarms). In Lawless
(1994), a wide classification of alarms is made. There,
alarms can be false, induced and significant. In our work,
induced alarms (provoked by staff manipulation of the
patient) are considered false ones.
Acknowledgements
We thank the Spanish Ministry for Science and
Technology for its support for the development of the
system through projects FIT-150200-2001-320 and FIT-
070000-2001-785, and Seneca Foundation through projects
PL/3/FS/00 and PI-16/0085/FS/01.
References
Allen, J. F. (1984). Towards a general theory of action and time. Artificial
Intelligence in Medicine, 23(2), 23–154.
Borst, W. N (1997). Construction of engineering ontologies for knowledge
sharing and reuse. PhD Thesis, University of Twente, Enschede, The
Netherlands
Dojat, M., Pachet, F., Guessoum, Z., Touchard, D., Harf, A., & Brochard, L.
(1997). NeoGanesh: A working system for the automated control of
assisted ventilation in ICUs. Artificial Intelligence in Medicine, 11,
97–117.
Dojat, M., Ramaux, N., & Fontaine, D. (1998). Scenario recognition for
temporal reasoning in medical domains. Artificial Intelligence in
Medicine, 14, 139–155.
Eschenbach, C., & Heydrich, W. (1995). Classical mereology and restricted
domains. International Journal of Human-Computer Studies, 43,
723–740.
Fernandez-Breis, J. T., & Martınez-Bejar, R. (2000a). A web-based
framework for integrating knowledge. Industrial Knowledge Manage-
ment: A Micro-Level Approach, 123–138.
Fernandez-Breis, J. T., & Martınez-Bejar, R. (2000b). A cooperative tool
for facilitating knowledge management. Expert Systems with Appli-
cations, 18(4), 315–330.
Haimowitz, I. J., & Kohane, I. S. (1993). Automated trend detection with
alternate temporal hypotheses. Proceedings of the 13th International
Joint Conference on Artificial Intelligence, 146–151.
Haimowitz, I. J., Le, P. P., & Kohane, I. S. (1995). Clinical monitoring
using regression-based trend templates. Artificial Intelligence in
Medicine, 7, 473–496.
Jones, R. W., Harrison, M., & Lowe, A. (2001). Computerised anaesthesia
monitoring using fuzzy trend templates. Artificial Intelligence in
Medicine, 21, 247–251.
Lawless, S. T. (1994). Crying wolf: False alarms in a pediatric intensive
care unit. Critical Care Medicine, 22(6), 981–985.
Lowe, A., Harrison, M. J., & Jones, R. W. (1999). Diagnostic monitoring in
anaesthesia using fuzzy trend templates for matching temporal patterns.
Artificial Intelligence in Medicine, 16, 183–199.
Lucas, P. (1998). Analysis of notions of diagnosis. Artificial Intelligence,
105.
Oliver, D. E., Shahar, Y., Shortliffe, E. H., & Musen, M. A. (1999).
Representation of change in controlled medical terminologies. Artificial
Intelligence in Medicine, 15(1), 53–76.
Schulz, S., & Hahn, U. (2001). Parts, locations and holes-formal reasoning
about anatomical structures. Lecture Notes in Artificial Intelligence,
2101, 293–303.
Schulz, S., Romacker, M., Faggioli, G., & Hahn, U. (1999). From
knowledge import to knowledge finishing automatic acquisition and
semi-automatic refinement of medical knowledge. Proceedings of
Knowledge Acquisition Workshop.
Shahar, Y. (1999). Timing is everything: Temporal reasoning and temporal
data maintenance in medicine. Joint European Conference on Artificial
Intelligence in Medicine and Medical Decision Making. AIMDM’99,
Aalborg, Denmark, Berlin: Springer, pp. 30–46.
Shahar, Y. (2000). Dimension of time in illness: An objective view. Annals
of Internal Medicine, 132(1), 45–53.
Shahar, Y., Miksch, S., & Johnson, P. (1998). The Asgaard project: A task-
specific framework for the application and critiquing of time-oriented
clinical guidelines. Artificial Intelligence in Medicine, 14, 29–51.
Shahar, Y., & Musen, M. A. (1996). Knowledge-based temporal abstraction
in clinical domains. Artificial Intelligence in Medicine, 8(3), 267–298.
Tinker, J. H., Dull, D. L., Caplan, R. A., Ward, R. J., Cheney, F. W. (1989).
Role of monitoring devices in prevention of anesthetic mishaps: A
closed claims analysis. Anesthesiology, 71, 541–546.
Uckun, S., Dawant, B. M., & Lindstrom, D. (1993). Model-based diagnosis
in intensive care monitoring: The YAQ approach. Artificial Intelligence
in Medicine, 5, 31–48.
Van de Aa, J. J (1990). Intelligent alarms in anaesthesia. Thesis,
Technische Universiteit Eindhoven, The Nederlands
Van Heijst, G., Schreiber, A. T., & Wielinga, B. J. (1997). Using explicit
ontologies in KBS development. International Journal of Human-
Computer Studies, 45, 183–292.
Wainer, J., & de Melo Rezende, A. (1997). A temporal extension to the
parsimonious covering theory. Artificial Intelligence in Medicine, 10,
235–255.
Yu-N, C., & Abidi, S. S. R. (1999). Evaluating the efficacy of knowledge
management towards healthcare enterprise modelling. Proceedings of
the International Joint Conference on Artificial Inteligence.
F.J. Torralba-Rodrıguez et al. / Expert Systems with Applications 25 (2003) 211–230230