MEDICAL KNOWLEDGE REPRESENTATION WITHIN
HEARTFAID PLATFORM
Dragan Gamberger, Marin Prcela, Alan Jović, Tomislav Šmuc
Rudjer Boskovic Institute, Bijenicka 54, Zagreb, Croatia
Ganfranco Parati, Mariaconsuelo Valentini
Cardiology II, S.Luca Hospital, Istituto Auxologico Italiano, Milano, Italy
Kalina Kawecka-Jaszcz, Katarzyna Styczkiewicz, Andrzej Kononowicz
I Cardiac Department, Jagiellonian University Medical College, Cracow, Poland
Antonio Candelieri, Domenico Conforti, Rosita Guido
Department of Electronics, Informatics and Systems, University of Calabria, Rende (Cosenza), Italy
Keywords: Heart failure, knowledge representation, ontology, production rules.
Abstract: The paper presents the results of the development of the knowledge base for the HEARTFAID platform.
The means and methods used to collect, systematize and formalize medical knowledge, as well as to test the
developed knowledge representation are described. The descriptive part of the knowledge base is realized as
an ontology which conceptualizes the heart failure medical domain. The procedural part of the knowledge
base is realized through sets of production rules. The procedural knowledge covers the tasks of heart failure
diagnosis, severity assessment, treatment process, medication prescription and dosage, medication
contraindications, prognosis estimation, and acute decompensation detection. Finally, medical plans are
used to present medical actionable knowledge. Currently they are used only to systemize procedural
knowledge development process but they present a challenge for the future work in the field of medical
knowledge representation.
1 INTRODUCTION
Medicine is the field characterized by the enormous
amount of existing expert knowledge and at the
same time there is a need for constant and reliable
decision making. This is an ideal scenario for
building and using automated knowledge based
decision systems. Building an effective knowledge
base is a challenge relevant not only for the
Heartfaid platform, but for all artificial intelligence
applications as well. It is also known as a hard
problem with possibly many different solutions
among which none can be selected as ideal or
optimal for all situations.
The knowledge representation is actually a very
lively research field, especially in medical
application. Heartfaid platform is a good example of
a real medical environment for which automated
intelligent decision making is necessary. In our work
we first tried to test different knowledge
representation options and then to select and use
modern and most appropriate technology for solving
concrete decision making problems.
2 MEDICAL MOTIVATION
Heart failure is increasingly frequent in western
world, carrying a high mortality rate and being
responsible for a consistent increase in healthcare
costs related to the multiple therapeutic interventions
307
Gamberger D., Prcela M., Jovi
´
c A., Šmuc T., Parati G., Valentini M., Styczkiewicz K., Kawecka-Jaszcz K., Kononowicz A., Candelieri A., Conforti D. and
Guido R. (2008).
MEDICAL KNOWLEDGE REPRESENTATION WITHIN HEARTFAID PLATFORM.
In Proceedings of the First International Conference on Health Informatics, pages 307-314
Copyright
c
SciTePress
and the high frequency of hospital admissions
required by these patients. There is therefore an
increasing need for a better care, that might be
provided not only by highly specialized centers, but
also by small hospitals and by field cardiologists, a
need that has to be matched with a policy of cost
containment. Progress in technology may offer an
important support to make this possible, allowing
adequate knowledge to be made available to all
health care providers in this field. It might also offer
new methods for regular and accurate collection of
biological signals in patients living in their home
environment, making use of sensors, either
traditional or wearable, able to provide a continuous
monitoring also through telemedicine facilities.
More recent progress might further offer an
advanced platform of services for the automated
integration between the signals collected both at
home and in the clinic environment on one side, and
the available state-of-the-art knowledge on the other
side, providing an artificial intelligence support to
clinical decision. The proper adoption of these tools
might help improving the daily care of chronic heart
failure patients, through a prompt titration of
treatment in response to early detection of even
minor changes in clinical conditions, as well as
through a reduction of diagnostic and therapeutic
errors, by reinforcing the implementation of the
most advanced recommendations provided by
international clinical guidelines. Such an approach
might also help improving the cost/effectiveness of
heart failure care facilitating the implementation of a
disease management approach, in which therapy,
education and follow-up are tailored for each patient
by a multidisciplinary team constantly supported by
an advanced platform of computerized services
guiding the clinical decision through a continuous
update of patient’s clinical conditions allowed by
advanced wireless telecommunication technology.
The Heartfaid project is aimed at developing such a
tool and at testing its feasibility and usefulness in the
management of chronic heart failure patients,
focussing in particular on those with advancing age.
3 RELATION WITH DECISION
SUPPORT SUBSYSTEM
Decision support subsystem (DSS) is the part of the
platform responsible for its intelligent behaviour and
the knowledge base (KB) is the representation of the
medical knowledge necessary for the DSS
operability. In order that this knowledge can be used
by the DSS, it must be presented in a formally sound
way. The task of building the knowledge base
consists of collecting the relevant medical
knowledge, its systematization, and technical
formalization.
User services are not supposed to directly access
the knowledge available in the KB. They can only
ask for the assistance of the DSS, which can then
decide to use the KB for its decision making
process. It means that during normal platform
operation, the KB, with exception of DSS, is isolated
from other platform parts. In contrast to that, during
the platform development the KB is perhaps the
most relevant integrative part between medical and
technical partners. Building it presents the challenge
of transferring all aspects of relevant medical
knowledge into the platform. The success in this
work significantly determines the overall
performance of the system.
On the other side, DSS completely determines
the requirements set on formal aspects of the
knowledge representation task. The final goal is
effective interplay between the DSS and the KB.
Already in the project definition it has been
determined that the ontological form of knowledge
representation is the most appropriate for the
concrete task. In the DSS development phase the
semantic web OWL ontology form with integrated
rules in the SWRL form have been selected as
optimal solution. The main reason for these
decisions is that only relative simple representation
forms without explicit time component and with
deterministic logic can be effectively handled by
available open source interpreters and reasoning
systems.
In our work we have also experimented with
some other systems, especially those specifically
designed for medical applications and guideline
modelling. We have worked with Arden syntax,
GLIF, Asbru, and PROforma.
Arden syntax (Hripcssak et al, 1993) is a rule-
based system adopted in the year 1992 and it is now
part of HL7 standard. The main idea of the Arden
syntax is to add as much as possible human-readable
information to machine-readable rules. Each rule is
stored in a single file and is called a Medical Logic
Module (MLM). The drawback of Arden syntax is
that it does not refer to any kind of domain
description (ontology). Due to this, the system needs
to interact directly with a clinical database in order
to provide alerts and reminders, which strongly
hiders knowledge sharing. Also, the execution
components are not freely available (mostly because
of Arden’s institution dependency). However, unlike
HEALTHINF 2008 - International Conference on Health Informatics
308
the vast majority of other systems, it has found a
practical usage in real clinical environments.
GLIF (Peleg et al, 2000) provides a framework
for developing medical guidelines that are both
easily understandable by humans (medical experts)
and interpretable by machines. Each GLIF guideline
is modelled in the form of a flowchart (directed
graph). GLIF is suitable for describing logic
sequence of actions. Within the HEARTFAID
platform GLIF may be used to represent the logical
flow of actions, e.g. sequence of tests performed for
diagnosing disease or prescribing therapy but the
problem is that there exists only commercial
execution engine (Glee).
Asbru (Shahar et al, 1998) is a guideline
modelling tool which focuses on representing
medical plans. It is highly aware of the time
dimension in the medical procedures and actions. A
plan in Asbru is a set of actions that are performed
when certain preconditions hold. Each plan is
decomposed into more sub-plans that are performed
sequentially, concurrent (parallel execution) or
cyclical. Within the HEARTFAID platform, Asbru
can be used in situations where actions are taken in a
predefined order, e.g. to describe the procedure at
the baseline evaluation or additional patient visits to
the clinics. However, there are no freely available
execution engines that may be integrated into
HEARTFAID platform.
PROforma (Sutton et al, 2003) is a knowledge
composition language that aims to assist patient care
through active decision support and workflow
management. Similar to the GLIF model, it
represents also guidelines as a directed graph in
which nodes represent instances from the PROforma
task ontology. PROforma contains a number of tools
for developing guidelines. A major focus point is on
guideline safety by defining additional safety-related
operators such as integrity and safety constraints.
Considering the execution engines, Arezzo is a
commercial version of PROforma, while Tallis is a
version available for educational and research
purposes (under license agreement).
4 DESCRIPTIVE HEART
FAILURE KNOWLEDGE
The first step in the development of the knowledge
base for the Heartfaid platform has been
development of the heart failure (HF) ontology. It
presents the formalized description of concepts for
the whole heart failure domain. It includes basic HF
concepts, properties that characterize patients, all
relevant diagnostic examinations and tests, and
treatment procedures. The ontology also includes
other cardiovascular system related concepts as well
as concepts related to other organs when they are
connected with HF. The information presented in the
ontology has been obtained by human interpretation
of guidelines for congestive and acute heart failure
(http://www.escardio.org/knowledge/guidelines/),
Heartfaid reports, as well as from other medical
knowledge sources, including, but not limited to
UMLS (Unified Medical Language System), Mayo
clinic web site and Open Clinical web site.
In its current form the ontology presents the
detailed taxonomic overview of the HF domain with
around 200 classes describing HF related concepts.
Examples are "Cardiac_hypertrophy", "Blood_
pressure_signs" or "Heart_murmurs". These
concepts are interconnected with super-class and
sub-class properties into a hierarchical tree-like
structure. At the basic level there are five relavant
super-classes: "HF_concept", "Patient_characte-
ristic", "Patients", "Testing", and "Treatment".
Figure 1 presents the Protégé tool displaying these
five super-classes with some of their most relevant
sub-classes.
Individuals or instances are members of the
classes and typically present exhaustive list of
concrete concepts relevant for the class. For
example, the "Cardiac_hypertrophy" class has
following six instances: "Cardiomegaly",
"Combined ventricular hypertrophy", "Left_atrial_
hypertrophy", "Left_ventricular-hypertrophy",
"Right_atrial_hypertrophy", and "Right_ventricular_
hypertrophy". The ontology includes more than
2000 individuals. When possible, classes are
specified with their CUI number (Concept Unique
Identifier according to UMLS) and with a list of
synonyms. For example, for the class
"Heart_diseases" its CUI is C0018799 and its
synonyms are "Disorder_of_heart", "Cardiac_
diseases", "Cardiopathy".
Finally, the ontology contains properties that
connect individuals in different classes. These
properties are relevant because they enable
introduction of relations among concepts. For
example, individual "Valvular_heart_disease" from
the class "Heart_valve_diseases" is indicated by the
individual "Dyspnea" from the class of
"Signs_and_symptoms". Or that "Hyperkalemia"
from the class "Potassium_disorder" may be caused
by medications like "Potassium_sparing_diuretics"
or "Spironolactone". The names of these properties
are "Indicated" and "MayBeCausedByMedication".
MEDICAL KNOWLEDGE REPRESENTATION WITHIN HEARTFAID PLATFORM
309
The HF ontology includes definitions of more than
100 properties.
Figure 1: Protégé tool used to display a part of the HF
ontology.
The ontology presents descriptive domain
knowledge. This knowledge is of two types. The
first is defined by the generality relations among
instances and classes, as well as by the generality
relations among sub-classes and super-classes. In
this way for each concept presented by some
instance there is a series of is-a relation. For
example, it means that "Cardiomegaly" is-a
"Cardiac_hypertrophy" while "Cardiac_
hypertrophy" is-a "Heart_disease". The second type
of descriptive knowledge contained in the ontology
comes from properties that define relations between
classes, such as "Indicated" or "MayBe
CausedByMedication", mentioned before.
Descriptive HF ontology is publicly available in
the web form from the project web site at
http://www.heartfaid.org/links.php.
5 PROCEDURAL KNOWLEDGE
The HF ontology presents the detailed taxonomic
overview of complete heart failure domain including
relevant relations among concepts. It represents
descriptive knowledge about the domain. Platform
should also be able to perform some actions,
typically in the form of suggestions for patients and
medical personnel. The knowledge representing
sufficient and necessary conditions that some actions
can be done is the so called procedural knowledge.
Descriptive and procedural knowledge together
present the knowledge base of the HF platform.
5.1 Production Rules
Production rules in a form "IF some condition is true
THEN make some action" are a widely used
approach for the presentation of procedural
knowledge. Their advantages are natural
interpretation by humans and modularity during
construction. It is also relevant that production rules
are also a formal way of presenting knowledge and
in this way a good starting point for practical
realization of the decision support system. For the
integration of descriptive and procedural knowledge
it is important that production rules can use only the
concepts defined in the HF ontology.
At the knowledge presentation level it is very
important that production rules can be easily
understood and corrected by medical experts. In this
way the major advantage of presenting procedural
knowledge in the form of production rules is that
they present formal enough way to present
knowledge that can be used by the platform and that
at the same time medical experts can easily control
the expected performance of the platform. The
correction of rules or adding them should only be
performed by the authorized medical personnel.
The HF procedural knowledge has been divided
into 10 functional subtasks in order to enable easier
human control of the completeness and consistency
conditions. They are:
1. HF diagnosis
2. Alternative or additional diagnosis
3. Heart failure severity assessment – specifying
NYHA class for patient, which is required for
general patient treatment approach
4. HF general treatment process based on severity
assessment
5. HF medications contraindications, adverse
effects & additional treatment rules
6. Prognosis estimation for HF patients
HEALTHINF 2008 - International Conference on Health Informatics
310
7. Non-pharmacological management and
recommendations
8. Specific medication prescription and dosage
9. Acute decompensation of congestive heart
failure
10. Heart failure cause and CAD risk factors
An example for a rule from the diagnosis subtask is:
Diagnosis: Systolic heart failure
IF
Patient has either heart failure signs or heart failure
symptoms
AND
ECG abnormal (left bundle branch block AND
anterior Q waves)
AND
patient has (ischemic heart disease)
AND
Chest X-ray abnormal (cardiothoracic ratio > 0.5)
AND
natriuretic peptides abnormal (BNP > 100 pg/ml))
5.2 Soft Computing
Intelligent medical applications require the ability to
work with imprecise or only partially true data. The
goal is to ensure robustness and efficiency of the
decision making process in a real world
environment. Soft computing techniques including
fuzzy systems and probabilistic reasoning can be
used to solve these problems. These techniques
typically lead to relative complex systems whose
performance and final decisions are rather difficult
to predict. For the platform we have decided to solve
the problem by a) a mixture of deterministic
production rules with fuzzy output values
(consequences) and b) complex but deterministic
computation of some input values that mimic fuzzy
inputs.
5.2.1 Fuzzy Consequences from
Deterministic Rules
The approach means that we have deterministic
rules, deterministic rule inputs, and deterministic
outputs which may have different, but in advance
predefined levels of reliability or probability.
An example of the deterministic rule with fuzzy
consequence is that Heart failure is possible IF
Patient has either heart failure signs or heart failure
symptoms AND cardiothoracic ratio > 0.5. Such
rule has precisely defined conditions but the level of
the reliability of the consequence is rather low.
Higher level of reliability is the rule with the
consequence Heart failure is probable, while the
highest level is that Heart failure diagnosis is
suggested.
The advantage of this approach is that decision
making process is deterministic and consequently
relatively simple. The application of this approach is
possible for the HF platform because decisions are
directed to humans who must decide upon their
acceptability and they are not automatically
executed. Medical doctors are the only ones who can
confirm and follow these suggestions. In this
framework we do not have closed loop decisions.
Suggestions with a predefined level of reliability are
completely acceptable. Moreover, they are easier to
interpret by humans than the numerical values
produced by probabilistic reasoning and completely
fuzzy systems.
In addition to different levels of the diagnosis
reliability in which we have four levels (suggested,
probable, possible, unlikely), we use fuzzy
conclusions for the prognosis (good, worse, very
poor), for medication recommendation (suggested,
consider) etc.
5.2.2 Computation of Complex Patient
Descriptors
Some deterministic rules require inputs that describe
patient status that are difficult to define by absolute
values. Such inputs can be described as fuzzy
because the same value can in different situations
have different meaning. Good examples are all
values that should be interpreted relative to some
other, current or previous, patient characteristics and
measured values.
We avoid using fuzzy values by implementing
complex computation in the process of preparing the
inputs for decision making. This means that in this
computation we must take into account, besides
basic patient characteristic, also all other properties
that significantly determine its previous or current
status relevant for the interpretation of the basic
characteristic. For example, for the input significant
arterial drop we have to look into the complete
patient history, compute mean blood pressure
values, and then based on the current value that is
more than 30 mmHg lower conclude on significant
arterial drop.
The computation of complex descriptors can be
effectively realized inside the factual knowledge
building block. It has access to the complete set of
patient data and this enables that all data necessary
for complex computations can be acquired. If some
data can not be found in the patient record then the
final patient descriptor will have unknown value and
MEDICAL KNOWLEDGE REPRESENTATION WITHIN HEARTFAID PLATFORM
311
this will prevent the respective rule to fire. For the
sake of decision reliability, the rules should have
also simple security cut-off points, like present
systolic blood pressure below 90 mmHg in the
previous example that will fire also if data necessary
for complex computations are not available.
The main disadvantage of this approach is that
rather complex computations relevant for the
decision making process are built into fixed
programmed logic with the consequence that they
can not be changed easily. The advantages are
simplicity of procedural knowledge and the
reliability of the DSS process.
5.3 Ontological Representation of
Procedural Knowledge
Presentation of HF procedural knowledge in the
form of production rules does not mean that their
practical realization for the decision support
purposes must be in the same form. It is true that
these rules may be used to build a rule based expert
system, but these rules can also be used for
representing procedural knowledge in other forms.
For the HF platform, the integration with descriptive
knowledge presented in the HF ontology is relevant.
In this situation, an appropriate form for procedural
knowledge is SWRL (Semantic Web Rule
Language), which is a logical extension of the OWL
(Web Ontology Language).
But there is also another possibility. The unique
property of OWL is the ability to represent logical
operations between classes and between classes and
individuals using the so called concept constructors.
It enables that logical relations contained in
production rules can be presented in the ontological
form. The result is the ontology that contains both
descriptive and procedural knowledge. The
advantage of the approach is a tight connection and
conceptualized representation of complete domain
knowledge which may potentially lead to a more
intuitive representation of medical knowledge. In the
future this can also enable web based distributed
decision support, but this is not relevant for the
current platform realization.
By integrating all of the ten sets of production
rules, we have built the procedural HF ontology. It
is different than the descriptive HF ontology because
it has two root classes: "Patient" and
"Patient_caracteristics". The "Patient_characteris-
tics" class contains descriptive knowledge necessary
for logical relations in production rules. All of its
subclasses and individuals, including the class
hierarchy, are based on and can be thought of as a
subset of the HF ontology. Theoretically the
complete descriptive HF ontology could be
integrated here but this was not done because of
reasoning efficiency. So the "Patient_characteristics"
class contains only descriptive knowledge necessary
for reasoning with current version of procedural
knowledge.
The class "Patient" contains the complete
procedural knowledge. In order to be compatible
with production rules organization it has ten
subclasses, each of them representing one rule set.
They are further divided into many subclasses.
Every class with no subclasses has necessary and
sufficient conditions defined, and this is where
procedural knowledge is stored. Each of the class
definitions can be found as a rule in one of the rule
sets. Fulfilling conditions for being in the class is
perceived as a suggestion for a particular patient,
e.g. class Patient_Severity_assessment has subclass
NYHA_IV. Conditions for this class are: patient has
dyspnoea, fatigue or palpitations at rest and patient
has heart failure. The patient with these
characteristics fulfils the conditions for being in this
class.
Testing is always the significant part of the KB
development process. By presenting production
rules in the ontological form we have enabled that
the problem can be solved by developing a java-
based OWL interpreter with added concept
“negation-as-failure” into the logic semantics of
OWL. The hybrid instance checking process
obtained in that manner aims to combine the OWL
syntax with the closed world assumption semantics.
The developed Protégé plug-in integrates the
interpreter into the Protégé with a simple user
interface. In this way, the interpreter is introduced
directly into the knowledge base building facility,
which eases the process of building and maintaining
the knowledge base.
6 MEDICAL PLANS
Medical plans are textual and visual presentations of
procedures that take place after detection of some
events. Events can be any type of health disorder
including signs, symptoms, and diagnosis. The main
characteristic of medical plans is that they are event
driven and because of that they present actionable
view of the medical knowledge. This actionable
view is a special case of the more general procedural
knowledge.
HEALTHINF 2008 - International Conference on Health Informatics
312
In the Heartfaid platform medical plans are only
a middle step between experts and the guideline
modelling tools which persuade the experts to
clearly state the procedure they would normally
perform when facing a specific problem. At the
same time they enable technicians to understand it
and encode it in a machine readable form (de Clercq
et al, 2004). They are similar to medical pathways
but in contrast to medical pathways which are
designed to be used by medical doctors in order to
systemize and standardize their work, medical plans
are designed for technical people in order to better
understand medical concepts. In the HF domain we
have used medical plans as an auxiliary tool for
systemizing procedural knowledge development and
to enable some verification of the implemented
knowledge base.
The syntax of the medical plans highly
resembles the traditional workflow management.
The difference is that the medical plans will not be
executed by machines; they are written in an almost-
free graph/text form with main purpose to be fully
understandable by humans. Their main characteristic
is that they are event driven and their main
advantage is a clear systematization of the medical
procedures and interconnections among them.
Additionally, their visual presentation facilitates
understandability by medical experts.
For the heart failure platform, medical plans
describe the disorders that can occur as events to the
patient who is treated by the platform. These
disorders have assigned urgency levels which
correspond to the type of response needed from the
medical team. For example, pulmonary edema has
the highest urgency level, requiring immediate
admission to the hospital. An example of a symptom
that has a low urgency level is cough. Cough does
not require for the patient to report to the hospital,
but rather if it is persistent, he should contact his
general practitioner. The urgency levels solve the
problem of entering the appropriate medical plan in
situations when more than one triggering event
occurs. The plans of the lower urgency level can be
interrupted if another event of the higher urgency
level happens.
At the moment, the heart failure system has 38
interconnected plans for signs, symptoms and
diagnosis assessment and treatment and 15 plans for
medications prescription and dosage. Most of them
have been presented in both graphical and textual
form. Figure 2 presents the medical plan for
handling heart failure patients with increased body
temperature.
The usual way of designing medical plans is in
close resemblance to the medical doctor’s way of
thinking when handling a patient. The most common
procedure would be to ask for other symptoms in
relation to the one the patient complains about and to
do the examination and find the appropriate signs.
These other signs and symptoms can either confirm
the initial suspicion, or request that some tests
should be taken, or completely disprove the
existence of the disorder. Usually, the next thing a
medical doctor would do is to order a series of tests.
These tests can also confirm the suspicions or give
rise to a new possible diagnosis. The next course of
action is to prescribe the appropriate treatment or to
give recommendations.
6.1 Further Research Topics
In the HF project the medical plans have been
developed by technical people in the phase of
procedural knowledge development. The goals were
to demonstrate medical domain understanding and to
systemize acquired knowledge. Their significance is
in the fact that they present a middle step between
the experts and their expert knowledge and technical
people that formalize the knowledge.
Development of medical plans opened some
potentially interesting questions that might be very
relevant as further research topics. The first is
weather all types of useful medical procedural
knowledge (or at least its major part) can be
described by medical plans. If the answer is positive,
then it would be interesting to think about the
possibility to make medical plans executable directly
without their transformation to other forms (rules,
ontologies, workflows) or to try to enable their
automatic conversion without human intervention
(de Clercq et al, 2004). Based on the work and
results in the HF project, these options seem
interesting because the approach based on medical
plans as the first and potentially the only creative
part requiring human intervention, could
significantly change the traditional way of designing
procedural knowledge.
7 CONCLUSIONS
The paper presents the main results of the work
related to collection, systematization, and
formalization of the knowledge related to the heart
failure domain. The main results are: descriptive HF
MEDICAL KNOWLEDGE REPRESENTATION WITHIN HEARTFAID PLATFORM
313
Figure 2: Medical plan for heart failure patients with increased body temperature.
ontology, procedural knowledge base, HF medical
plans, and ontological presentation of procedural
knowledge.
Although the constructed knowledge base has
been partially verified and improved by medical
doctors, the current version presents technical
formalization of medical guidelines and starting
point for Heartfaid platform implementation. It can
be expected that tests with prototypes will
demonstrate deficiencies in the form and content of
the knowledge base. By these improvements we
expect to be able to collect and formalize also the
tacit medical knowledge related to HF. Long and
detailed experimental work with the platform is the
necessary condition for the success of this process.
Moreover, even in the operational life of the
platform it can be expected that continuous
improvements in the knowledge base will be
necessary.
ACKNOWLEDGEMENTS
The work was done for EU FP6 project "Heartfaid:
A knowledge based platform of services for
supporting medical-clinical management of the heart
failure within the elderly population". It was
supported by Croatian Ministry of Science,
Education and Sport project "Machine Learning
Algorithms and Applications".
REFERENCES
Hripcsak, G., Clayton, P.D., Pryor, T.A., Haug, P.,
Wigertz, O.B., Van der lei, J., 1993. The arden syntax
for medical logic modules. Forteenth Annual
Symposium on Computer Applications in Medical
Care, 200-204. IEEE Computer Society
Press.
Peleg, M., Boxwala, A., Ogunyemi, O., 2000. GLIF3: The
Evolution of a Guideline Representation Format.
Proceedings of the American Medical Informatics
Association (AMIA) Annual Symposium. (20
Suppl):645-649. Washington DC: AMIA.
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(1-2), 29-51.
Springer, 1998.
de Clercq, A., Blom, J.A., Korsten, H.M., Hasman, A.,
2004. Approaches for creating computer-interpretable
guidelines that facilitate decision support. Artificial
Intelligence in Medicine 31(1), 1-27. Springer, 2004.
Sutton, D.R., Fox, J., 2003. The Syntax and Semantics of
the PROforma guideline modelling language. Journal
of the American Medical Informatics Association:
JAMIA, 2003 Sep-Oct;10(5):433-43. Hanley &
Belfus.
HEALTHINF 2008 - International Conference on Health Informatics
314