Journal of Biomedical Informatics 45 (2012) 429–446

Contents lists available at SciVerse ScienceDirect

Journal of Biomedical Informatics

journal homepage: www.elsevier.com/locate/yjbin

An ontology-based personalization of health-care knowledge to support

clinical decisions for chronically ill patients
David Riaño a, Francis Real a, Joan Albert López-Vallverdú a,⇑, Fabio Campana b, Sara Ercolani c,
Patrizia Mecocci c, Roberta Annicchiarico d, Carlo Caltagirone d,e
a
Research Group on Artificial Intelligence, Universitat Rovira i Virgili, Tarragona, Spain
b
Centro di Assistenza Domiciliare, ASL RM B, Roma, Italy
c
University of Perugia, Perugia, Italy
d
IRCCS Fondazione S. Lucia, Roma, Italy
e
University Roma Tor Vergata, Roma, Italy

a r t i c l e i n f o a b s t r a c t

Article history: Chronically ill patients are complex health care cases that require the coordinated interaction of multiple
Received 12 January 2011 professionals. A correct intervention of these sort of patients entails the accurate analysis of the condi-
Accepted 25 December 2011 tions of each concrete patient and the adaptation of evidence-based standard intervention plans to these
Available online 18 January 2012
conditions. There are some other clinical circumstances such as wrong diagnoses, unobserved comorbid-
ities, missing information, unobserved related diseases or prevention, whose detection depends on the
Keywords: capacities of deduction of the professionals involved.
Ontologies
In this paper, we introduce an ontology for the care of chronically ill patients and implement two
Medical decision support systems
Health care personalization
personalization processes and a decision support tool. The first personalization process adapts the con-
tents of the ontology to the particularities observed in the health-care record of a given concrete patient,
automatically providing a personalized ontology containing only the clinical information that is relevant
for health-care professionals to manage that patient. The second personalization process uses the person-
alized ontology of a patient to automatically transform intervention plans describing health-care general
treatments into individual intervention plans. For comorbid patients, this process concludes with the
semi-automatic integration of several individual plans into a single personalized plan. Finally, the ontol-
ogy is also used as the knowledge base of a decision support tool that helps health-care professionals to
detect anomalous circumstances such as wrong diagnoses, unobserved comorbidities, missing informa-
tion, unobserved related diseases, or preventive actions.
Seven health-care centers participating in the K4CARE project, together with the group SAGESA and the
Local Health System in the town of Pollenza have served as the validation platform for these two pro-
cesses and tool. Health-care professionals participating in the evaluation agree about the average quality
84% (5.9/7.0) and utility 90% (6.3/7.0) of the tools and also about the correct reasoning of the decision
support tool, according to clinical standards.
Ó 2012 Elsevier Inc. All rights reserved.

1. Introduction
Ontologies are one of the most successful ways of representing
actionable knowledge in biomedicine [1–5]. Two of the reasons for
this success are their ability to capture biomedical knowledge in a
formal but simple, powerful and incremental manner, and their
easy application in the reasoning processes [6] performed by
medical decision support systems.
In health care, the most common, complex and resource-
consuming clinical cases to deal with correspond to chronically
⇑ Corresponding author. Address: Av. Paı¨sos Catalans, 26, 43007 Tarragona, Spain.
Fax: +34 977559710.
E-mail address: joanalbert.lopez@urv.net (J.A. López-Vallverdú).
ill patients [7], who are a kind of patients that deserve long term
and simultaneous assistance provided by several sorts of profes-
sionals, as for example family doctors, specialists, nurses, or social
workers.
In order to deal with this highly variable kind of patients, we
need mechanisms to personalize the knowledge describing both
the condition of these patients (each individual patient is a poten-
tial different case with specific diseases, syndromes, social needs,
signs and symptoms), and the intervention plan for these patients
(the actions to be followed for different patients are eventually
very varied). But we also need mechanisms to assess whether the
decisions and recommendations on these patients are correct or
not in part because the possibilities of over- and under-treat these
kind of patients can be very high.

1532-0464/$ - see front matter Ó 2012 Elsevier Inc. All rights reserved.
doi:10.1016/j.jbi.2011.12.008
430 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
In this context, we developed a health-care ontology to organize
the terms used to describe chronically ill patients. This is called the
case profile ontology and it is used as a knowledge base for
the personalization of patient conditions and intervention plans,
and also as the core of a medical decision support tool that helps
health-care professionals to detect feasible medical and social
inconsistencies in the available data of chronically ill patients
under treatment.
The ontology is described in Section 3.
A wrapper system integrating these two personalizations and
the decision support tool was also implemented (see Fig. 1). With
this system, the ontology can be directly maintained (and ex-
tended) by health-care professionals without any intervention of
information technology specialists. As the ontology grows up with
new medical concepts and properties, the diversity of patients that
our system is able to deal with increases, the possible intervention
plans can be more detailed and accurate, and the decision support
system automatically becomes more powerful. Therefore, the
health-care utility of the system is exclusively dependent on the
incorporation of new knowledge in the case profile ontology.
In this work, a patient condition is considered to be all the past and
current medical and social information about the patient that may
affect the professional immediate and short term management of
that patient. This information is mainly composed of the patient
signs, symptoms and diagnoses, but it also may include family ante-
cedents and social conditions and limitations. A formal intervention
plan is a computer-interpretable structure representing the heath
care procedures to assist patients suffering from one particular
disease, syndrome, or social issue. It contains indications to all the
actors involved in the care process (i.e., health-care professionals,
care givers, etc.) in order to provide the best coordinated action plan
possible. Both the ontology and the formal intervention plans are
mutually related and they define the knowledge base on which
two knowledge personalization procedures and one decision sup-
port tool are implemented.
Given the condition of a chronically ill patient (or a patient
type), the ontology is used to personalize the medical and social
knowledge available for that patient, discarding all the knowledge
that is not related to that patient condition. This personalization
process (see Section 5.1) concludes with a patient-oriented
ontology that contains the medical concepts and the relationships
confirmed by the patient condition (i.e., confirmed knowledge), but
also those other concepts and relationships that are not observed
in the patient condition but that should have been observed or that
are feasible to be observed, according to the knowledge contained
in the case profile ontology (i.e., unconfirmed knowledge).
At the same time, the patient condition, the formal intervention
plans related to the diseases, syndromes, and social issues of that
comorbid patient (or patient type) and the case profile ontology
Fig. 1. The wrapper system.
are used by another personalization procedure to provide a unified
intervention plan for that patient (see Section 5.2).
So, in our system, the information about how to deal with
comorbid patients is not necessarily scattered across several inter-
vention whose application has to be synchronized [8], but de-
scribed with a single unified intervention plan whose application
is much easier, medically intuitive, and controllable.
The third and last application of the case profile ontology is in a
cyclic on-line decision support tool (see Section 5.3) whose main
purpose is to help professionals in health-care processes as
prevention, diagnosis and therapy planning. Starting with a patient
condition which is represented by a subset of the terms in the
ontology, this tool explores the ontology to find possible additional
or alternative diagnoses, feasible signs and symptoms that are not
observed in the patient condition, additional tests to check and to
assess these signs and symptoms, and the available interventions
to deal with the new medical and social problems observed for
the patient. As the user of the decision support tool (e.g., a physi-
cian, nurse or social worker) confirms or performs some of these
recommendations, the information about the patient and the treat-
ment may change and this new information can cause the decision
tool to continue providing new suggestions to the health-care pro-
fessional. This loop stops either when the tool is not able to provide
new suggestions or when the health-care professional considers
that the current condition of the patient is perfectly represented
by the accepted diagnoses, signs and symptoms, assessments,
and interventions. At any point, the decision about what the
patient has and does not have is left to the professional who is
using the tool.
Both the personalized ontology and the unified intervention
plan of a patient may evolve as the patient condition changes
(i.e., when the information about the patient changes in the
health-care record of that patient) or as a result of the application
of the decision support tool to find out new medical knowledge
about the analyzed patient. These evolved ontologies and unified
intervention plans can be successively stored as part of the
health-care record of that patient, in Fig. 1.
Notice that these ontologies are not aimed to contain the clini-
cal information about the patient, but the subset of general clinical
information that is relevant to the patient in a concrete moment.
The information of the patient remains in the health-care record
of the patient.
The two personalization procedures and the decision support
tool are detailed in Section 6. These components, together with
the case profile ontology and the formal intervention plans of 19
of the most common diseases of chronically ill patients, are inte-
grated in a computer application to help general practitioners in
their daily tasks of visiting patients, follow-up, diagnosis, planning
of treatments and foreseeing evolutions. Concretely, it allows users
(1) to provide a detailed and sound description of the medical
and social condition of a single patient or a patient type, (2) to
isolate the health-care knowledge related to a patient condition
from the case profile ontology, (3) to automatically obtain an inter-
vention plan adjusted to the patient health-care requirements, (4)
to help physicians in the processes of disease prevention and
detection, and (5) to facilitate the task of finding the most accurate
intervention in each particular moment.
The integration of these technologies in the system depicted in
Fig. 1 aims at providing health-care professionals dealing with
chronically ill patients with an integrated tool that helps them in
decision and analysis tasks. The decision tasks at the point and
time of care are to determine the condition of new arriving
patients, and to refine predefined standard evidence-based treat-
ments in order to obtain and validate a unified intervention plan
adapted to the health-care and social needs of the patient during
the first and the follow-up visits. The analysis task is to help the
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446 431

physician to study the available information about the patient in suggests a distinction between ontologies about health-care manage-
order to detect anomalous circumstances such as wrong diagnoses, ment (i.e., ontologies about the concepts involved in the organization
unobserved comorbidities, missing information, unobserved re- of health-care activities), and ontologies about biomedical subdo-
lated diseases, or preventive actions. The system works automati- mains (i.e., ontologies about biomedical concepts). Some representa-
cally for the first and the last tasks and semi-automatically for the tive examples of health-care management ontologies are the Actor
second one. The interface allows graphical representation and Profile Ontology [5], an ontology to structure organizational health-
refinement of intervention plans and provides dialogs for the rest care knowledge for home care, and the ontology in [3] which is
of the tasks. In Section 6 we explain several experiences with the conceived to describe adaptive medical workflows. On the contrary,
system. the Gene Ontology [18], the Foundational Model of Anatomy
Ontology [19], and the Ontology for General Medical Science [20]
are examples of biomedical domain ontologies.
2. Background
In this work we have used Protégé to develop an ontology for
the domain of chronically ill patients requiring home care: the Case
The health-care condition of a patient is defined as all the past
Profile Ontology.
and current medical and social information about the patient that
This ontology that after validation was tested in a real health-
may affect the professional immediate and short term manage-
care settings in the K4CARE project8 [53] is not aimed to contain
ment of that patient. In this work, this information corresponds
information about concrete patients (i.e., instances), but the clinical
to all the diseases, syndromes and social issues that are diagnosed
concepts, relationships, and constraints that are relevant to manage
for the patient, the signs and symptoms (including family anteced-
chronically ill patients. For this reason, the uses of this ontology that
ents and anamnesis), the problem assessments performed (i.e.,
are described in this paper are not implemented with an OWL-DL
medical, social, cognitive, and mobility tests), and the current
reasoner but with a functional interface implemented in Jena9 that
interventions, either pharmacological, rehabilitative, nurse care,
allows efficient and sound navigation through the ontology classes
social care, counseling, and special medical services.
and properties.
In order to describe patient conditions, several national and
international encoding systems have been proposed [9] for dis-
eases and procedures: International Classification of Diseases 2.2. Formal intervention plans
(ICD9-CM1, ICD102), and International Classification of Primary Care
(ICPC3); signs and symptoms: parts of ICD9-CM and ICD10, and Formal intervention plan is the name we use to refer to a
pharmacological treatments: Anatomical Therapeutic Chemical computer-interpretable structure representing the heath care
classification system (ATC4). procedures to assist patients suffering from a particular disease,
SNOMED [10] is also a well known health-care terminology syndrome, or social issue. There are several computer-oriented lan-
system that does not only provide a semantic classification of guages and systems to represent and execute these plans, as for
terms, but also the possibility of combining terms to describe or example Asbru [21], Proforma [22], GLIF3 [23], SAGE [24], and
refine new health-care information. In a third group, UMLS [11] SDA [25]. Despite their differences, there are some features that
represents a different approach that unifies several biomedical any language or system to represent formal intervention plans
terminologies to define cross relationships and equivalences should comply with [27,28]. These can be summarized as (1) the
between the terms in these terminologies. capability of representing patient states, (2) the availability of
Terminology and coding systems are cornerstones of any primitives to allow medical procedures to contain sequences,
computer-based medical system and also the basis for semantic concurrencies, alternatives, and loops, (3) the incorporation of
interoperability. In this work we use ICD10-CM and ATC. nesting as a means of describing medical procedures at different
levels of abstraction and granularity, and (4) the integration with
electronic health-care records. All the above languages satisfy
2.1. Health-care ontologies
these features to a large extent.
Clinical practice guidelines are documents gathering all the
An ontology is a knowledge model that represents a set of con-
available medical evidence with regard to a particular disease.
cepts within a domain and the relationships among these concepts.
Some clinical practice guidelines contain clinical algorithms
Ontologies facilitate not only representation but also concept
as a means to provide a simplified schematic model of some
instantiation and instance-based reasoning within a domain.
specific medical and clinical pathways. Clinical algorithms are
OWL is a semantic markup language for publishing and sharing
formal structures starting with a clinical state box that defines
ontologies on the World Wide Web. Among the tree versions of
the problem addressed by the clinical algorithm, and followed
the OWL language, OWL DL [12] reaches the maximal expressive-
by a combination of decision and action boxes [29,30]. Decision
ness as maintaining computational completeness (all the entail-
boxes are branching elements that lead the application of the
ments are guaranteed to be computed) and decidability (all the
clinical algorithms in one direction or another depending on
reasoning processes finish).
the response to a yes–no question (e.g., is the patient diabetic?).
Ontologies have been widely applied in biomedicine [13–16]
Action boxes contain medical orders or recommendations, either
and made available in multiple on line ontology libraries [17] such
diagnostic or therapeutic (e.g., drug prescription or professional
as Bioportal5, Open Biological and Biomedical Ontologies Foundry6,
counsel).
or Protege library7. Several ontology editors as Protégé (protege.
Several of the above mentioned languages and systems to
stanford.edu) have also contributed to the development of
represent formal intervention plans include the possibility of
biomedical ontologies. A review of published biomedical ontologies
defining clinical algorithms. In this work, we use the SDA modeling
language in order to represent the formal intervention plans
1
http://icd9cm.chrisendres.com/
2
corresponding to 19 diseases, two syndromes, and six social issues
http://www.who.int/classifications/icd/en/
3
http://www.kith.no/templates/kithWebPage1062.aspx
that affect chronically ill patients.
4
http://www.whocc.no/atc/
5
http://bioportal.bioontology.org
6 8
http://www.obofoundry.org http://www.k4care.net
7 9
http://protegewiki.stanford.edu http://jena.sourceforge.net
432 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
2.3. Medical decision support systems and decision problems
Since the early 1970s, medical decision support systems have
evolved to support health-care professionals in decision making
[31–37] and it is expected that they will continue evolving in the
future [38].
In the last years, several systematic reviews have arrived to
similar conclusions about the success of medical decision support
systems. Namely, these systems may reach a significant impact
in the performance of health-care professionals [39,40] in impor-
tant tasks such as diagnosis, preventive care, disease management,
and drug dosing and managing. However, the use of these systems
as normal tools in clinical practice and the analysis of the impact of
these systems in the patient outcomes [39,41] remain as open
challenges for the future.
As far as the care of chronically ill patients is concerned,
INTERNIST-I [43] was a pioneer of these systems to diagnose multi-
ple diseases in internal medicine. It contained a knowledge base
of about 500 diseases described in terms of more than 4100
manifestations and each manifestation was associated with a
property list encoding information about interdependencies be-
tween manifestations. All this knowledge was involved in a rea-
soning process that ranked the feasible diseases affecting a
concrete case and provided a final diagnose in a way that was
similar to differential diagnosis. INTERNIST-I (and the later CADUCEUS
[44]) received several critiques as their ad hoc knowledge struc-
ture that made maintenance and validation processes very diffi-
cult, and their lack of therapeutic interest in contrast to other
systems as MYCIN [45] that dealt not only with patient diagnosis
but also with therapeutic actions. While the first critique was
addressed with the possibility of converting the INTERNIST-I knowl-
edge structures into an ontology [46], the problem of making
decision support systems that integrate patient diagnosis and
treatment was also addressed in later systems [34–37].
According to [42], the design and function of medical decision
support systems can be classified with the use of 24 features that
are grouped into five categories: context (i.e., clinical setting,
clinical task, unit of optimization, relation to point of care, and
potential completion barriers), knowledge and data source (i.e.,
clinical knowledge source, data source, data source intermediary,
data coding, degree of customization, and update mechanism),
decision support (i.e., reasoning method, clinical urgency, recom-
mendation explicitness, and logistical complexity), information
delivery (i.e., delivery format, delivery mode, action integration,
and delivery interactivity/explanation availability), and workflow
(i.e., system user, target decision maker, output intermediary,
and workflow integration). Please, see [42] for a complete descrip-
tion of these features.
Here, we introduce a new knowledge-based medical decision
support system whose knowledge structures (i.e., ontology and
formal intervention plans) are maintainable whilst they are used
to support physicians in multiple tasks as diagnosis, therapy
critiquing, therapy planning, and pharmacological treatment. For
diagnosis assistance, our system implements a ranking process
which is similar to the one of INTERNIST-I. Our system is designed
to provide a patient-centered support in a way that the available
knowledge is continuously personalized to the condition of the
chronically ill patient under consideration.
2.4. Personalization
Clinical assistance deals with the professional adaptation of
general health-care practices to the particularities of the assisted
patient. Patient-centered health-care lies on the personalization
of care as local, national and international evidence-based
standards of good medical practice are maintained. In the case
of chronically ill patients [7], health-care personalization is
particularly relevant since the potential variability of the cases is
very high in terms of the patient condition (i.e., what is the
available patient information that is relevant to make decisions?),
interventions (i.e., what is the unified intervention plan defining
the treatment of this patient?), and quality assessment (i.e., is
the set of measures taken for the patient correct and complete?).
These facts define health-care personalization at two levels: (1)
identification of the medical knowledge that is relevant and that
affects the patient (i.e., definition of the patient condition and
the medical semantics of this condition) and (2) description of
the treatment that the patient has to follow (i.e., construction of
a unified intervention plan). The personalization of a treatment
can also be used for the retrospective analysis of past actions in
terms of medical correctness (i.e., are all the already performed
actions justified from both the patient condition and the corre-
sponding intervention plan?) and medical completeness (i.e., are
there some required actions not performed?).
In the last years, health-care personalization has become syno-
nym of both pharmacogenomics, or the use of genetic information
about one patient to design a pharmacological treatment
specific for that patient [47], and personal health systems, or the
individualization of interventions aimed to prevent or treat dis-
eases via technological tools that are made available as part of a
health-care environment [48].
Here, our approach to health-care personalization concerns
with the adaptation of the standard medical knowledge available
(i.e., ontology and formal intervention plans) by omitting all the
parts that are irrelevant for the current patient, and providing as
much detail as possible to those other parts that affect the patient.
Combining all the personalized intervention plans into a single
unified intervention plan (see Section 5.2) is also part of the
personalization offered by our system.
3. The case profile ontology
The Case Profile Ontology [50] is an OWL-DL compliant ontol-
ogy developed in the K4CARE project (http://www.k4care.net) in
order to provide a formal representation of all the health-care con-
cepts related to the care of chronically ill patients at home (i.e.,
syndromes, diseases, social issues, signs and symptoms, problem
assessments, and interventions) and the relationships and
constraints between these concepts.
All the classes, class relationships and constraints, where man-
ually introduced and doubly validated by a team of health-care
professionals from five different countries: Czech Republic,
Hungary, Italy, Romania, and UK.
In order to obtain all the domain knowledge contained in the
ontology, this team selected some of the most representative
diseases, syndromes and social issues related to chronically ill
patients [7]. These were:
 Nineteen diseases: anaemia, arthritis, cerebrovascular disease,
chronic ischaemic heart disease, chronic obstructive pulmonary
disease, decubit ulcer, delirium, six sorts of dementia (vascular,
secondary, mixed, Alzheimer, unspecified, and other degenera-
tive dementia), depression, diabetes, heart failure, hyperten-
sion, iatrogenic cognitive impairment, Parkinson disease and
Parkinsonism (see Fig. 2).
 Two syndromes: immobility and cognitive impairment.
 Five social issues: serious mental illness, bad environment, low
income, lack of family support, and lack of social network.
For each disease, several clinical practice guidelines and scien-
tific papers [49] were considered to identify the corresponding
signs and symptoms, interventions, problem assessments, and also
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446 433

Fig. 2. OWL ontology defined with Protégé.

the related syndromes. For syndromes and social issues only
scientific papers were used [49]. All the information extracted from
these documents together with the professional experience of
the physicians in the work team were manually incorporated
to the ontology as classes, properties, and property constraints.
Protégé was the tool used to construct the case profile ontology
(see Fig. 2).
The main concepts and relationships in the ontology are shown
in Fig. 4. Solid arrows represent subclass relationships (e.g.,
Chronic Heart Failure is a Disease), while dashed arrows represent
properties (and their inverse properties) between medical con-
cepts. For example, diseases are related to signs and symptoms
with property hasSignAndSymptom, and viceversa with the inverse
property isSignOf.
The necessary conditions of all the classes in the ontology were
manually refined in terms of the properties of that class to reflect
the medical knowledge provided by the team of health-care
professionals in the K4CARE project. So, for example, the property
hasSignAndSymptom in the class chronic heart failure was
restricted to contain the possible signs and symptoms of this dis-
ease, and the inverse property isSignOf in a symptom of chronic
heart failure (e.g., asthenia) was restricted to all the diseases in
the ontology with that symptom, including but not necessarily
only chronic heart failure.
Only allValuesFrom and the cardinality restrictions of OWL DL
were used to describe the property constraints in each class. This
captures, for example, the relationship between each disease and
all the possible signs and symptoms of that disease [50]. So,
Fig. 3 shows a constraint of all the signs and symptoms that can
be observed in a patient with chronic heart failure. Not all of them
are required, but as new signs and symptoms in the constraint are
confirmed for a concrete patient, more evidence shall exist that
this patient may have heart failure. In our decision system in
Section 5.3, this evidence will help practitioners either to diagnose
the disease or to seek new evidences.
In this ontology, a disease is a physiological or psychological
dysfunction, a syndrome is a complex health situation in which a
combination of signs and symptoms occurs more frequently than
it would be expected on the basis of chance alone and it generates
a functional decline, and a social issue is a sociological matter that
can become a problem during the treatment of the patient. Social
issues are considered to be factors outside the control of the

Fig. 3. Constraint on the possible signs and symptoms of heart failure.

434 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446

patient and the patient’s immediate social environment, and they
may affect many individuals or a society [50].
Property hasICD10Code was used to contain the ICD10 code of
each disease in the ontology, as Fig. 2 indicates.
Diseases, syndromes and social issues use the property
hasSignAndSymptom to determine their signs and symptoms
among a hierarchy of 293 signs and symptoms (only the first
level of this hierarchy is shown in Fig. 4), and the property
hasIntervention to indicate their health-care interventions in a hier-
archy of 108 different types of interventions (among which 94
are pharmacological). Note that the way that these interventions
are combined to provide a proper treatment is not represented in

Fig. 4. Case profile ontology.

 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
the ontology but in the formal intervention plans of the correspond-
ing disease, syndrome or social issue. In the ontology, interventions
are classified into pharmacological treatments, non-pharmacological
treatments, rehabilitation, nursing care, social care, counseling and
special medical services.
Pharmacological treatments are codified with the Anatomical
Therapeutic Chemical classification system (see hasATCCode prop-
erty in Fig. 4), they have the property hasAdministrationRoute to
determine their route of administration among 24 possible
alternative routes, and they have data properties to describe their
dosage, number of times, periodicity, and preparation.
Finally, property isAssessedBy determines the means of assess-
ing each sign and symptom of the ontology, making a distinction
between comprehensive assessments, consultations, diagnostic
examinations and laboratory analyses (see Fig. 4). In the ontology,
there are 176 different types of problem assessments to evaluate
the condition of the patient during the first encounter and when-
ever a re-evaluation is required.
All the above properties have their corresponding inverse proper-
ties evaluatesSignOrSymptom, isSignOrSymptomOf, isInterventionOf,
canBeCauseOf, and isRouteOfAdministration, respectively. All these
properties appear in Fig. 4.
A complete description of the case profile ontology can be found
in the K4CARE technical report [50].
It is important to notice that, for all the uses of the case profile
ontology in this work (including personalization and decision
support), we did not use an OWL-DL reasoner but a functional
interface for the case profile ontology navigation that was imple-
mented on Jena.
4. Formal intervention plans
Each disease, syndrome and social issue in the ontology is re-
lated to a formal intervention plan that represents the correspond-
ing treatment as a state-decision–action (or SDA) diagram [25].
These diagrams provide a correct health-care combination of all
the interventions in the ontology that are related to that disease,
syndrome or social issue. For example, the SDAs in Figs. 5 and 6
represent the formal intervention plans for patients with heart
failure and Alzheimer’s disease as they were described in the
K4CARE project, respectively.
Similar to clinical algorithms, these sort of diagrams [25]
connect states, decision points, and action blocks represented as
circles, diamonds and rectangles, respectively. SDA notation com-
ply with all the features required for languages to represent formal
intervention plans (see Section 2.2): representation of patient
states with state elements (circles) describing patient conditions;
incorporation of sequences, alternatives and loops with SDA con-
nectors (arrows) and decision points (diamonds); concurrency
with the incorporation of several simultaneous interventions in
the same action block (rectangle); introduction of nested parts
with the incorporation of calls to other SDAs inside the action
blocks (rectangles); and the integration with electronic health-care
records which is accomplished by the system executing the SDAs.
So, the SDA diagram in Fig. 5 describes the general treatment of
heart failure in chronically ill patients who are in one of two
possible states: START and patient monitoring. ‘‘START’’ represents
patients with a pharmacological treatment who start home care
(HC), and ‘‘patient monitoring’’ the regular follow-up of heart fail-
ure patients at home. Note that the SDA is complemented with two
ending states, one to continue with the home care of the patient,
and another one to consider admission of the patient to a hospital.
When a patient arrives in a condition that satisfies the state about
monitoring, the SDA suggests that if an increase of the patient
weight is observed, a dietetic or pharmacological change is
435
required depending on whether there are or not symptoms of
breathless or ankle edema. Consultation with a specialist is also
recommended in some cases.
The SDA in Fig. 6 is more detailed and it includes pharmacolog-
ical treatment of Alzheimer’s disease. It also involves some nested
actions such as clinical assessment that is common to several inter-
vention plans and performed several times in this concrete plan,
and dosage reduction10 as a procedure that requires a different level
of granularity.
Formal intervention plans expressed as SDA diagrams can be as
specific as the terms in the case profile ontology permit. In order to
make an intervention plan consistent with the ontology, the states
and the decision points in the SDA must be expressed with terms in
the ontology (i.e., diseases, syndromes, special issues, interven-
tions, signs and symptoms, and problem assessments), but the ac-
tion blocks in the SDA can only be expressed with the terms of the
sort intervention in the ontology that are related to the disease
whose treatment that plan represents.
SDAs representing intervention plans can also include time con-
straints and restrictions on the sort of actors that are allowed to or-
der and to perform the corresponding interventions in the plan.
The most frequent time constraints are of the sort [min,max]. These
are related to the connectors leaving some action blocks in the SDA
diagram and they represent stops of the treatment between min
and max time. For example, some parts of the treatment in Fig. 6
describe delays of one month (i.e., [1 M, 1 M]) after a follow-up
encounter.
On the other hand, each intervention in an action block can be
related to the sort of actors that are allowed to order that interven-
tion, and also to the sort of actors that are allowed to perform that
intervention (e.g., physician, nurse, care giver, etc.). So, for exam-
ple, we can indicate that some care intervention can be ordered
either by nurses or physicians, but only performed by care givers.
All these constraints together with the information in the elec-
tronic health-care record are used for the personalization of formal
intervention plans into individual intervention plans, as it is
detailed in Section 5.2, before the knowledge in the formal
intervention plan can be applied to a concrete patient. Individual
intervention plans are also represented as SDA diagrams.
5. The knowledge-based system
The case profile ontology and the formal intervention plans
developed during the K4CARE project define the knowledge base
of our system, in Fig. 1. Restricted to 19 diseases, two syndromes,
and five social issues, the ontology conceptualizes the knowledge
related to the care of chronically ill patients at home, whereas
the formal intervention plans describe general evidence-based
treatment plans for these diseases, syndromes and social issues.
The context in which a concrete patient is assisted depends on
the actors participating in the care of this patient (i.e., family doc-
tor, nurses, caregiver, etc.), but also on the information contained
in the health-care record of that patient. Therefore, the knowledge
in the ontology and the knowledge in all the intervention plans
that affect a target patient must be complemented with the
information about the context of this patient; i.e., the actors
involved and the health-care record of the patient. This individual
information transforms the general evidence-based knowledge
of the ontology and the intervention plans related to this
patient into a personalized knowledge that is represented by a
10
In our work, dosage modifications are achieved by replacing one of the
pharmacological treatments contained in the case profile ontology by another
pharmacological treatment in the ontology. This is possible because the last level of
the hierarchy of drugs contains specific products (e.g., Enalapril Merck 20 mg 80 tablets
EFG and Enalapril Merck 5 mg 60 tablets EFG) with concrete dosages [26].
436 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446

Fig. 5. Formal intervention plan for the treatment of chronic heart failure.

patient-oriented ontology and a unified intervention plan. After about the target patient, and the unified intervention plan to
that, the personalized ontology is used by our decision support tool automate the care processes to be performed on the target patient
to help health-care professionals to detect new medical knowledge [51].
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446 437

Fig. 6. Formal intervention plan for the treatment of Alzheimer’s disease.

These two personalization procedures and the decision support
tool are the basic components of our system (see Fig. 1). They are
detailed in the next subsections.
5.1. Personalizing Patient Knowledge
The knowledge about each single patient is personalized after a
process of filtering and restructuring the case profile ontology with
four main purposes: to provide an evidence-based integrated
description of the patient condition, to determine as much as
possible the actors directly involved in the care of the patient, to
incorporate the personalized ontology in the health record of the
patient, and to produce a knowledge structure that could be
incorporated in a decision support tool in order to analyze the
patient condition. In subSection 5.2, the personalization of inter-
vention plans complements these four purposes with a last one
which is to provide an integrated description of the patient
treatment for automating some care aspects as coordination.
438 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
5.1.1. Personalizing the patient condition
The personalized ontology has two main classes: Background
and PatientCase. The Background class will contain all the concepts
in the case profile ontology that can be confirmed in the health re-
cord of the patient, together with the other concepts in the case
profile ontology that should also be observed for the current
patient, but which are not confirmed in the health record (i.e.,
evidence-based knowledge). On the contrary, the PatientCase class
will only contain the ontological concepts that are found in the
record of the patient (i.e., confirmed knowledge).
Background knowledge will be used by the decision support tool
in subSection 5.3 to help physicians to define a more accurate
profile of the patient condition, and therefore to improve the
PatientCase knowledge.
As Fig. 7 shows, the Background class has four subclasses:
Diagnostic, SignAndSymptom, Intervention, and ProblemAssessment.
Diagnostic class is also structured in three subclasses: Disease,
Syndrome, and SocialIssue. This is the basic structure on which
the case profile ontology is personalized to a patient.
The personalization process depends on whether the diagnostic
of the patient is already confirmed in the health-care record of the
patient or not. If it is not, the set of current signs and symptoms in
the record are incorporated as subclasses of both the SignAndSymptom
and the PatientCase classes. The property isSignOf is then used to
determine the feasible diseases, syndromes, and social issues that are
related in the case profile ontology to the observed signs and symp-
toms. All of them are incorporated to the respective subclasses of
Diagnostic in the personalized ontology as diagnostic hypotheses, but
not to the PatientCase class as confirmed diagnoses. Similarly, the
property isAssessedBy provides the problem assessments related to
the patient signs and symptoms. Once obtained, they are incorporated
to the class ProblemAssessment. The property hasIntervention is used to
obtain all the interventions (i.e., single health-care actions) to the dis-
eases, syndromes, and social issues found in the previous steps. They
are incorporated to class Intervention. All these problem assessments
and interventions are also sought in the health-care record of the
patient and incorporated to the PatientCase class if they are found.
Alternatively, if the patient is already diagnosed (i.e., the cur-
rent condition of the patient in the health-care record contains
one or more active diseases, syndromes or social issues), the pro-
cess of constructing the personalized ontology is the following.
Starting with the patient diseases, syndromes and social issues
that are found in the case profile ontology, the properties
hasSignAndSymptom, canBeCauseOf, and hasIntervention are used
to determine feasible signs and symptoms, syndromes, and
interventions. Once found, they are introduced in the respective
Fig. 7. Structure of the personalized ontologies.
subclasses of the Background class in the personalized ontology.
The signs and symptoms are used to determine their related
problem assessments, according to the property isAssessedBy.
These problem assessments are introduced in the subclass
ProblemAssessment of the personalized ontology. All the above
mentioned findings are searched in the health-care record of the
patient, and the ones that are found, incorporated to the class
PatientCase as confirmed information.
The concepts that have to be incorporated to the class Patient-
Case are included as direct subclasses of that class. However, the
concepts to be incorporated in the Background class follow a two
step process that, firstly, removes all the concepts in the case pro-
file ontology except the ones that have to be incorporated in the
personalized ontology, including their subclasses, and the ones
that are ancestor classes of those concepts. Secondly, the resulting
hierarchies of classes are modified in order to have an explicit
representation of only those concepts that are describing the
condition of the current patient.
If one patient condition is described with several concepts
among which there is one that subsumes some other (i.e.,
c1  c2), our system interprets that ’’the patient has c2, which is a
c1, but also some other c1 different to c2 which is not specified.
So, a new concept (c1  c2) representing the cases in c1 that are
not of the sort c2 is introduced in the personalized ontology, as sub-
concept of c1, and with c2 as sibling. This process was extended to
the case that we have multiple concepts subsumed by the same
concept. The purpose of this process is to retain in the personalized
ontology of one patient all the concepts describing this patient
condition and to have these concepts as accurately represented
as possible.
For example, if a patient has chest pain, dyspnea and another
unspecified pulmonary problem that requires a radiography before
it can be determined, the first two signs are in the case profile
ontology and therefore incorporated to the personalized ontology.
However, the last vague symptom pulmonary problem has to be
represented with the general ontology class pulmonary, but since
dyspnea is a kind of pulmonary symptom, a new class representing
all the pulmonary symptoms in the case profile ontology but dysp-
nea is created in the personalized ontology.
This example is depicted in Fig. 8, where part of the SignAnd-
Symptom class hierarchy of the case profile ontology, in Fig. 8a, is
transformed into the SignAndSymptom class hierarchy of the
personalized ontology, in Fig. 8b.
Observe in the personalized ontology in Fig. 8b how the pul-
monary signs and symptoms of the patient are organized in two
subclasses, Dyspnea and Pulmonary-X001, the last one being any
pulmonary sign except dyspnea. ChestPain is the only general sign
and symptom maintained.
This transformation is not conceived to detect or correct the
medical mistakes that could be retrospectively found in the
health-care record of the patient, but just to represent the knowl-
edge about the current patient condition introduced in the record,
as an ontology. This ontology is the knowledge base that the
decision support tool described in Section 5.3 will use to help
health-care professionals to detect medical errors and omissions,
but also to obtain a more precise clinical description of the patient
under study and to provide recommendations.
5.1.2. Personalizing the involved actors
When we combine the knowledge in the personalized ontology
both with the health-care organizational knowledge available in
other ontologies such as the Agent Profile Ontology [5] or the
one in [3], and also with the information available in the health-
care record of a concrete patient, we can determine the people that
are allowed to perform each single intervention and problem
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
Fig. 8. Example of ontology personalization.
assessment, and reflect this knowledge in the personalized
ontology of that patient.
So in the Agent Profile Ontology [5], interventions and problem
assessments belong to the class action, and the property hasSubject
provides the sorts of actors performing the action. In [3], interven-
tions and problem assessments are under the class task and
property isPerformedBy provides the roles of the people who can
perform a given task. Here, we have used the Agent Profile
Ontology to determine which roles are allowed to perform the
different sort of interventions in the case profile ontology. This
was possible after a synchronization of the teams that developed
the two ontologies in the K4CARE project.
Once we have the sort of actors (or roles) that can perform a
concrete intervention or problem assessment in a personalized
ontology, the electronic health-care record of the patient is used
to retrieve the professionals that are the current actors in the
care of that patient. For example, if a patient requires ECG, and
hasSubject informs that ECGs can only be done by family doctors,
cardiologists, or nurses. Then, the record of that patient is searched
to find the current family doctor, cardiologist and nurse of the
patient. If, for example, there is not a cardiologist assigned to the
patient, then the ECG of this patient will be performed either by
the retrieved family doctor or nurse.
This identification of the actors participating in the care of one
patient is stored in the personalized ontology of that patient. We
use property hasSubject of the Intervention and the ProblemAssess-
ment classes in Fig. 7 to store such information. After that, the
personalized ontology can be stored in the electronic health-care
record of the patient as a description of the current condition of
this patient. From that moment on, the ontology can be retrieved
439
to assess the patient and to make decisions. Patient assessment
is directly performed as a navigation process within the classes
of the personalized ontology that describe the patient current con-
dition. However, more complex decisions as determining wrong
diagnoses, detecting comorbidities or preventing the development
of new diseases, require the combined use of both the personalized
ontology of the patient and the case profile ontology described in
Section 3. In order to help health-care professionals in these tasks,
we developed the decision support tool that is described in Section
5.3.
5.2. Personalizing intervention plans
Formal Intervention Plans are designed to describe general
treatments for concrete diseases. They bring a lot of interesting
knowledge, but at the same time their application to a particular
patient has two obstacles: the first one is the isolation of the parts
of the general treatment that are relevant to the current patient
(e.g., which parts of the intervention in Fig. 6 are relevant for a
patient with moderate Alzheimer’s), and the second one is the
management of comorbidities in a single treatment (e.g., what is
the result of combining the two formal intervention plans in Figs.
5 and 6 to treat a patient with both a concrete breathless and a
moderate Alzheimer’s). The way we address these two obstacles
is explained in the next two sections.
5.2.1. Generating individual intervention plans
The knowledge contained in the personalized ontology of a
patient is used to customize each one of the formal intervention
plans corresponding to the diseases of that patient. The process
440 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446

starts with the identification of the patient diseases in PatientCase
class of the personalized ontology. The intervention plans corre-
sponding to these diseases are recovered from the case profile
ontology (property hasFIP), an each one of them adapted according
to the information about the patient which is available in the
PatientCase class of the personalized ontology. An intervention plan
that has been adapted to a concrete patient is called an Individual
Intervention Plan, and it represents the personalized treatment of
one of the diseases, syndromes and social issues of that patient.
The adaptation process of an intervention plan starts with the
identification of the states in the plan that the patient satisfies
(i.e., the terms describing the state are found in the personalized
ontology). For each one of these states, the process recursively
follows the outgoing paths of the intervention plan, trying to solve
all the decisions that are found in the path by removing the
decision branches which are labeled with terms that are not found
in the personalized ontology, until an already visited element of
the plan is reached. For example, if a patient with moderate
Alzheimer’s presents acetyl-cholinesterase-inhibitor (AchEI) con-
traindications, only the fifth branch in the first decision of the
intervention plan in Fig. 6 remains in the individual intervention
plan of this patient, in Fig. 9.
When a state of the plan is reached that is not satisfied by
the knowledge about the patient condition in the personalized
ontology, it is considered a feasible future state of the patient,
and the treatment derived from this state in the plan is maintained
in the individual plan without changes. The same is done if a
branch with a [min, max] time delay is reached because this
indicates that the current treatment stops there, and the next
steps in the formal intervention plan describe feasible future
treatments that do not depend on the current patient condition
but on the future evolution of the patient.

Fig. 9. Example of Alzheimer’s individual intervention plan.

 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
Fig. 10. Tool to integrate several individual intervention plans into a unified intervention plan.
5.2.2. Integrating unified intervention plans
If a patient is diagnosed with several simultaneous diseases, our
system generates an individual intervention plan for each disease.
All these plans represent personalized interventions that coexist in
the treatment of the patient. Coordinating the simultaneous
actions of several plans can be inefficient and difficult because of
several reasons as, for example, redundancy of actions or interac-
tions between treatments. Redundancies occur when the same
action (e.g., blood analysis) is required by several plans of the same
patient, but it should be performed only once [8]. Interactions are
harder to detect, and they occur when the actions of one plan (e.g.,
drug prescription) interferes with the actions of another interven-
tion plan of the same patient.
Our approach to avoid redundancies and interactions is to inte-
grate all the individual intervention plans affecting the treatment
of a patient into a single plan that is called the Unified Intervention
Plan. This integration has been achieved with the incorporation of
the SDA Lab tool11 to the system in Fig. 1. This tool provides a graph-
ical interface to the edition and merging of SDA diagrams that is
based on the terms in the case profile ontology, and it helps
health-care professionals to import and to combine the states,
decisions and action blocks in the individual intervention plans of
11
SDA Lab software and user’s manual: http://banzai-deim.urv.net/repositories/
sdalab1.4.rar
441
a patient, and to integrate them in a single unified intervention plan.
In Fig. 10, the SDA Lab tool is used to define the unified intervention
plan for the treatment of a patient with both moderate Alzheimer’s
with AchEI contraindications and stable chronic heart failure.
Once validated by a physician, the unified intervention plan is
stored in the electronic health-care record of the corresponding
chronically ill patient, and it can be used to automate the coordina-
tion of the actors participating in the treatment of this patient [51].
5.3. Decision Support Tool
The case profile ontology and the personalized ontology that is
stored in the health-care record of a patient can help health-care
professionals to make decisions and also to analyze and detect
lacks of precision in the description of the patient condition. These
imprecisions may reduce the quality of the treatment that the
patient is currently receiving. In order to help minimizing such
imprecisions, our system integrates a decision support tool that
helps physicians to detect wrong diagnoses, unobserved comorbid-
ities, incomplete descriptions of the patient condition, related
diseases and prevention.
The automatic process followed by this tool is summarized in
Fig. 11 as a loop that starts with the information contained in the
personalized ontology about the target patient. If the patient is
already diagnosed, the diseases, syndromes and social issues in
442 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
Fig. 11. Medical decision support tool reasoning loop.
the personalized ontology determine the signs and symptoms this
patient should have, and the interventions this patient should be
receiving. A distinction is made between signs, symptoms and
interventions that are confirmed (they are in the PatientCase class
of the personalized ontology of the patient) and those others that
the properties hasSignAndSymptom and hasIntevention in the case
profile ontology provides as feasible for this patient. As Fig. 12
depicts, all this information is delivered to the physician who is
allowed to confirm some of the facts (i.e., moving elements from
the left to the right hand side columns in Fig. 12) or to cancel the
confirmation of some facts (i.e., moving elements from right to
left). Once the new sets of signs and symptoms and interventions
are confirmed, this new information is used to search in the
case profile ontology other possible diagnoses (property IsSignOf)
and also the expected problem assessments that should have
been made to confirm the new signs and symptoms (property
IsAssessedBy).
As INTERNIST-I [43] does, our decision support tool provides a
ranking of the most feasible diseases, syndromes and social issues
the patient may have. In our system this ranking is conditioned to
Fig. 12. Adjusting a patient condition: signs, symptoms, and interventions.
Fig. 13. Adjusting a patient condition: ranking the diseases.
the medical knowledge available in the case profile ontology. As
Fig. 13 shows, the ranking relates each disease with a percentage
representing the evidence provided by the ontology that the pa-
tient has that disease, according to the current description of the
patient condition. This evidence value is calculated as a weighted
proportion of the signs and symptoms related to the disease in
the case profile ontology that have been observed in the patient.
During differential diagnostic, a sign (or symptom) that discards
few diseases is of less help than another sign that discards many
diseases. Therefore, in order to rank the patient feasible diseases
we calculate the weight of each sign as the proportion of diseases
that are not related to that sign in the case profile ontology (i.e.,
sign s is weighted ((d  ds)/(d  1))2 with d the total number of dis-
eases in the ontology and ds the number of diseases that property
isSignOf relates to s).
We square this value to penalize signs with low weights in front
of signs with high weights [52], and use the values obtained to cal-
culate the percentages in Fig. 13 that rank the diseases.
For each disease d in the case profile ontology, this percentage is
calculated as the addition of the weights of all the signs and
symptoms of d that the patient has, over the addition of the
weights of all the signs and symptoms related to d (i.e.,
P P
ð s2ðS\PatientCaseÞws = s2S ws Þ  100, where S = {s:isSignOf(s, d)}).
This ranking can help the physician to decide modifications of
the diagnosis of the patient in Fig. 11. These modifications, and also
the possible changes about problem assessments, can be confirmed
by the physician by means of a choice screen equivalent to the one
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446 443

Table 1
Classification of the decision support system with the features in [42].

Feature Value Explanation (the system . . .)

Clinical setting Outpatient . . . Is addressed to home care of chronically ill patients
Clinical task Prevention, diagnosis and treatment . . . Provides support in these clinical tasks
Cnit of optimization Patient outcomes . . . Allows a most accurate knowledge about the patient condition
Relation to point of care Synchronous and asynchronous . . . Is prepared to provide on line and off line supports
Clinical knowledge source Clinical practice guideline based . . . Uses evidence-based clinical knowledge
Data source Health-care record and patient . . . Combines data from the electronic health-care record and form the direct
observation observation of the patient
Data source intermediary None . . . Incorporates the data directly from the sources
Data coding ICD10-CM, ATC, others . . . Uses the coding systems of the K4CARE project
Degree of customization Patient condition and requirements . . . Obtains and exploits the personalized ontology and the unified intervention plan of
the patient
Updated mechanism None Not considered in this work
Reasoning method Ontology-based . . . Reasons though ontology navigation (see Fig. 11)
Clinical urgency Non-urgent . . . Is aimed to general practice medicine and geriatrics
Recommendation explicitness Explicit . . . Provides explicit recommendations (see Figs. 12 and 13)
Logical complexity or recommended One-step actions . . . Reasoner iterates steps in the loop depicted in Fig. 11
action
Response requirement Decision maker acknowledged . . . Provides recommendations that are acknowledged by the health-care professional
Delivery format Stand alone software . . . Provides direct access through a user’s interface (see Fig. 1)
Delivery mode Pull . . . Provides recommendations upon requirement
Action integration Intuitive . . . Allows interaction by means of interface menus and buttons
Delivery interactivity/explanation None There is not an explanation module, but the ontology contains explanatory comments
availability (see Fig. 2)
System user Health-care professionals . . . Is designed for professionals in direct contact with patients
Target decision maker Physician . . . Helps physicians to make decisions
Output intermediary None . . . Allows direct interaction of health-care professionals with the system
Degree of workflow integration None . . . Keeps the reasoner and the intervention plans separated (see Fig. 1)

in Fig. 12. The new changes in the patient diagnosis cause a new
loop of the whole process. This reasoning loop continues till the
physician confirms that the current description of the patient con-
dition is correct. Then, the system allows the user to construct the
personalized ontology from the information gathered (see Section
5.1.1), and store this ontology in the electronic health-care record
of the patient as his current condition.
The decision support loop can also be started for undiagnosed
patients. In this case, the signs and symptoms of the target patient
are taken as the starting point of the loop in Fig. 11.
In Table 1, this decision support tool is described in terms of the
features and possible values proposed in [42] to classify medical
decision support systems. A column with brief explanations is also
provided.
6. The K4CARE experience
All the personalization procedures and the decision support tool
described in the previous sections have been tested in the context
of the K4CARE project. K4CARE (http://www.k4care.net) is an
information and communication technology project that was sup-
ported by the European Commission and which counted on the
participation of the Centro di Assistenza Domiciliare ASL RM B
(Italy), IRCCS Fondazione S. Lucia (Italy), the Department of Clinical
and Experimental Medicine at the University of Perugia (Italy), the
Ana Aslan International Foundation (Romania), the Research Insti-
tute for the Care of Elder People (UK), Szent János Kórház (Hungry),
and the General University Hospital in Prague (Czech Republic).
All these health-care centers provided the knowledge to con-
struct the case profile ontology and the formal intervention plans
described in the previous sections, but they also contributed to the
validation of the process of generating unified intervention plans.
Another health-care center, namely SAGESSA (www.grupsagessa.
com), provided data about clinical cases for the diseases chronic
obstructive pulmonary disease, hypertension, diabetes, and chronic
heart failure. A total number of 916 patients, among which 187
suffered of more than one of these diseases, were used to analyze
the personalization of the ontology, and also to evaluate the perfor-
mance of the decision support tool.
6.1. The experience of generating unified intervention plans
After a technological and a medical verification of the processes
and tools to transform formal intervention plans into individual
intervention plans, and these into unified intervention plans, the
town of Pollenza (Italy) was selected to perform a ground test with
local health-care professionals and patients. These professionals
were alien to and therefore independent of the K4CARE project.
There were four general practitioners (GPs), four nurses, one
geriatrician, and one social worker. The GPs selected 23 voluntary
patients out of a population of 400 assisted chronically ill patients
over 65 years in town. All of the patients were home-care patients
with ages above 70, defining a target population of mainly geriatric
users with a high resource consumption, mostly of nursing ser-
vices, and suffering from several of the diseases, syndromes and
social issues contained in the case profile ontology. Mainly, coro-
nary heart disease, cerebrovascular disease, arthritis, diabetes,
hypertension, cognitive impairment, and immobility. Some of
them with low family support and many of them with low income,
as affecting social issues.
After a short training of 2 days, the health-care professionals
were asked to perform their usual care activities on this population
with the system in Fig. 1 and, simultaneously, with their normal
means, in order to promote the comparison between usual proce-
dures and the ones proposed in this paper. The activities lasted for
1 week and these were about the management of the data of
the patients (i.e., health-care record), the construction of unified
intervention plans for the management of these patients, and the
automatic execution of these plans by the system.
For the construction of unified intervention plans, the data in
the health-care record of each patient was used to determine the
respective diagnosis. These diagnoses were used to identify the
formal intervention plans affecting each one of the patients. These
plans were personalized into the respective individual intervention
plans and, finally, integrated with the clinical management of the
444 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
services required by the patient (e.g., admission, follow-up or
re-evaluation actions). These services were also represented with
the SDA notation [25] in the K4CARE project. The integration of
individual intervention plans and services with the SDA Lab tool
concluded with unified intervention plans for all the patients, that
were validated by the physicians before they were run by the sys-
tem in order to automate the coordination of the care activities of
the GPs, specialist, nurses and social worker involved.
All this activity was performed by a real time connection with
the server that hosted the system, accessed by laptops or desktops
operated by participants and located at patients’ homes, GPs’ offi-
ces and District’s office in Pollenza. The dynamism of the activities
is reflected in the 260 registers that were created in the electronic
health-care record of the patients, and the execution of 184 health-
care actions of the different unified intervention plans.
The conclusions of the professionals participating were
captured in several questionnaires that they were asked to fill in
at the end of the experience [53]. All the questions had to be scored
between 1 (low) and 7 (high). The mean values and (in parenthesis)
standard deviations of the answers were:
 Mean overall score of the evaluation: 5.8 (0.5).
 Perceived ease of use: 5.8 (0.5).
 Perceived usefulness: 5.9 (0.7).
 Attitude toward using: 6.0 (0.8).
 Need of such systems in health-care: 6.3 (0.9).
 Awareness of some similar system: 1.9 (0.8).
6.2. Experiences personalizing the case profile ontology
The personalization of the case profile ontology was analyzed for
four diseases: chronic obstructive pulmonary disease, hypertension,
diabetes, and chronic heart failure. Three sorts of evaluations
were performed: personalization of the ontology to a single disease,
personalization of the ontology to comorbid conditions, and
personalization of the ontology to concrete patients.
With the first test we obtained that the personalized ontologies
contain 8.03%, 5.46%, 9.77%, and 10.84% of the case profile ontology
classes when a patient is constrained to have only one of the above
mentioned diseases, respectively. If only the classes related to
signs and symptoms, interventions, and problem assessments are
considered, the percentage of original classes that remain in the
personalized ontology are shown in Table 2.
These proportions and the detail of the personalizations were
analyzed by a senior GP with more than 20 years of experience
assisting patients in the SAGESSA group who agreed with the
results, except in the proportion of interventions related to hyper-
tension in comparison to the rest of diseases. The main reason for
this, is that in spite that all the pharmacological interventions
of all the diseases in the case profile ontology are defined at the
same level of detail of the Anatomical Therapeutic Chemical classi-
fication system hierarchy, the interventions that were related to
hypertension (i.e., antihypertensives, diuretics, peripheral vasodila-
tors, beta blocking agents, calcium channel blockers, agents acting
on the renin-angiotensin system, dietetic prescription, and nursing
Table 2
Proportional sizes of the personalized ontologies.
Disease s&s Intervention Problem
(%) (%) assessment (%)
Chronic obstructive pulmonary 13.52 4.60 17.67
disease
Hypertension 6.92 5.75 12.09
Diabetes 14.47 3.45 26.98
Chronic heart failure 16.35 6.32 27.91
care) were more specific than the interventions related to other
diseases that include concepts at the same level of the Anatomical
Therapeutic Chemical hierarchy but which are less concrete, as for
example cardiac therapy, drugs for obstructive airway diseases, or
drugs used in diabetes. This particularity of the hierarchy will be
studied in future versions of the case profile ontology, though it
does not affect either the personalization algorithms or the
decision support tool introduced in this paper, which are based
on the concepts rather than on how general these concepts are.
The personalization of the ontology to comorbid conditions was
also analyzed for hypertension plus diabetes, and hypertension
plus diabetes plus chronic heart failure conditions. For these
comorbidities, the personalized knowledge generated was ana-
lyzed by SAGESSA health-care experts who arrived to the following
conclusion: ‘‘the personalized knowledge seems to contain all the
information required to diagnose and to treat these comorbid
conditions, however final acceptance depends on how the system
behaves in front of concrete patients’’.
In order to solve this doubt, the electronic health-care record of
916 chronically ill patients in SAGESSA were used to evaluate the
process of personalizing the ontology to concrete real patients.
According to the physicians supervising the results, the personal-
ized ontologies do not only captured the relevant information
about each case (in the class PatientCase) but also it extended the
information about the patient with unobserved but medically
sound elements of information (in the class Background). When
asked about the difference between these two classes in the
personalized ontology, physicians agreed that the concepts in
PatientCase provided a description of the case in terms of the avail-
able information about them, whereas the concepts in Background
provided a view of the patient as a medical case which supplies a
global perspective that is very interesting in follow-up tasks.
6.3. Decision making in K4CARE
In order to analyze the capabilities of the decision support tool,
a senior GP of the SAGESSA group was asked to study the system
behavior in front of five irregular medical situations: wrong diag-
nosis, unobserved comorbidities, missing information about the
patient condition, discovery of unobserved related diseases, and
prevention. For each situation, the GP proceeded with the descrip-
tion of artificial medical cases and studied how useful and fast was
the system to help him to detect these irregularities. For example,
how sensitive was the system to replace a diagnosis from a chronic
obstructive pulmonary disease to a cardiac disease (chronic
ischaemic heart disease, or chronic heart failure) as new signs
and symptoms are confirmed for the patient, or the ability of the
system to detect hypertension in a diabetic patient that presented
headache and dizziness. In this case, the system recommended
some assessment tests which result into new signs and symptoms
like epistaxis and palpitation which reinforced the weight of
hypertension in the ranking of feasible diseases of the patient.
Other singular analysis performed with the tool was the deter-
mination of chronic ischaemic heart disease for a patient for which
very little information was known. Since the disease was sus-
pected, the introduction of this possibility in the decision support
tool made the system to recommend some problem assessments
to detect signs and symptoms that could confirm it. When the phy-
sician confirmed these signs and symptoms, chronic ischaemic
heart disease reached the first position in the ranking of diseases.
One last example of use of the decision support tool was to pre-
vent the patient of developing new diseases with the introduction
of all the current signs and symptoms of the patient. In one of the
cases studied, the ranking of diseases confirmed anaemia in the
patient (53.94%), but also showed that according to the signs and
symptoms observed the patient was close to suffer from chronic
 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
ischaemic heart disease (30.54%) and chronic heart failure
(16.16%). The tool was then used to find out a preventive treatment
that could avoid the development of these diseases. The GP using
the tool concluded that the measures suggested were appropriate
for prevention.
Some of the most relevant clinical studies performed with the
decision support tool are described in [54].
The general conclusions about the decision support tool after
the study can be summarized as: (1) the set of terms managed
by the tool (i.e., ontology classes) is appropriate to support physi-
cians in diagnostic tasks and also to allow the correct description of
patients, (2) the system adapts the recommendations as new infor-
mation is confirmed and this adaptation is similar in the steps and
requirements of information to the decisions taken by regular GPs,
and (3) the ranking of diseases is an excellent means to confirm the
patient diagnosis, but also to guide physicians on considering and
preventing future diseases.
7. Final remarks
The case profile ontology presented in this paper corresponds to
the version 3.6. It is an evolving ontology for the management of
chronically ill patients at home that integrates general medical
knowledge with knowledge that is specific for this kind of patients.
Future versions of the ontology will include restrictions on the
interactions between interventions with the purpose of extending
the decision support tool with mechanisms to compare treatments
[26]. This will permit the decision support tool to help physicians
to change treatments when it was required. As mentioned in a pre-
vious section, a second consideration for future versions of the
ontology is to reconsider the relationships among intervention
classes in the ontology and Anatomical Therapeutic Chemical
codes. Current uses show that these concepts are correctly related,
but the percentage of hypertension in column interventions in
Table 2 deserve a consideration.
It is also expected that the introduction of knowledge about
interactions between intervention classes in the ontology will
affect the construction of unified intervention plans. At the
moment, the integration of several individual intervention plans
in a single unified plan with the SDA Lab tool is a manual process
that depends directly on the health-care professional using the
tool. With this new knowledge, we aim at extending the tool
with a process that supervise the action blocks of the unified
intervention plans and suggests alternative interventions if some
undesired interaction is detected.
Acknowledgments
This paper presents part of the work developed in the K4CARE
project that was partially funded by the European Commission.
The authors would like to acknowledge the health-care profession-
als participating in the project, as well as the ones involved in the
experience in Pollenza, and especially Dr. Collado who obtained the
permissions required to use the electronic health-care records of
the patients in SAGESSA and contributed very much with his
expert analysis and recommendations during the evaluation of
the decision support tool.
We are also thankful to the anonymous reviewers for several
interesting remarks and comments that helped us to improve the
paper.
References
[1] Rosse C, Mejino JLV. A reference ontology for biomedical informatics: the
Foundational Model of Anatomy. J Biomed Inform 2003;36:478–500.
[2] Yu AC. Methods in biomedical ontology. J Biomed Inform 2006;39:252–66.
445
[3] Dang J, Hedayati A, Hampel K, Toklu C. An ontological knowledge framework
for adaptive medical workflow. J Biomed Inform 2008;41:829–36.
[4] Matos EE, Campos F, Braga R, Palazzi D. CelOWS: an ontology based framework
for the provision of semantic web services related to biological models. J
Biomed Inform 2010;43:125–38.
[5] Valls A, Gibert K, Sánchez D, Batet M. Using ontologies for structuring
organizational knowledge in home care assistance. Int J Med Inform
2010;79:370–87.
[6] Harrison’s Principles of Internal Medicine, 17th Ed., McGraw-Hill; 2008.
[7] Ouwens M, Wollersheim H, Hermens R, Hulscher M, Grol R. Integrated care
programmes for chronically ill patients: a review of systematic reviews. Int J
Qual Health-Care 2005;17(2):141–6.
[8] Abidi SR, Abidi SSR. Towards the merging of multiple clinical protocols and
guidelines via ontology-driven modeling. AIME 2009:81–5.
[9] Hammond WE, Cimino JJ. Standards in medical informatics. In: Shortliffe EH,
Perreault LE, Wiederhold G, Fagan LM, editors. Medical Informatics: Computer
Applications in health-care and Biomedicine. New York: Springer; 2000. p.
212–56 [chapter 6].
[10] Rothwell DJ, Cote RA. Managing Information with SNOMED: understanding
the model. In: Proc. AMIA annual fall symp, 1996. p. 80–83.
[11] Lindberg DA, Humphreys BL, McCray AT. The unified medical language system.
Methods Inf Med 1993;32(4):281–91.
[12] Antoniou G, Van Harmelen F. Web ontology language: OWL. In: handbook on
ontologies, Springer Int. Handbooks on Information Systems; 2003. p. 67–92.
[13] Pisanelli DM, editor. Ontologies in medicine. (vol. 102), IOS Press Series in
Technology and Informatics; 2004.
[14] Bodenreider O, Stevens R. Bio-ontologies: current trends and future directions.
Brief Bioinform 2006;7(3):256–74.
[15] Brochhausen M, Spear AD, Cocos C, Weiler G, Martn L, Anguita A, et al. The
ACGT master ontology and its applications – towards an ontology-driven
cancer research and management system. J Biomed Inform 2011;44(1):8–25.
[16] Robinson PN, Mundlos S. The human phenotype ontology. Clin Genet
2010;77(6):525–34.
[17] d’Aquin M, Noy NF. Where to publish and find ontologies? A survey of
ontology libraries. Technical report, Stanford Center for Biomedical
Informatics Research; 2010.
[18] Mungall CJ, Berardini TZ, Deegan J, Ireland A, Harris MA, Hill DP, et al. Cross-
product extensions of the gene ontology. J Biomed Inform 2011;44(1):80–6.
[19] Rosse C, Mejino JLV. A reference ontology for biomedical informatics: the
Foundational Model of Anatomy. J Biomed Inform 2003;36:478–500.
[20] Scheuermann RH, Ceusters W, Smith B. Toward an ontological treatment of
disease and diagnosis. In: Proceedings of the 2009 AMIA summit on
translational bioinformatics, San Francisco (CA); 2009. p. 116–20.
[21] Seyfang A, Miksch S, Marcos M. Combining diagnosis and treatment using
ASBRU. Int J Med Inform 2002;68(1–3):49–57.
[22] Sutton DR, Fox J. The syntax and semantics of the PROforma guideline
modelling language. JAMIA 2003;10(5):433–43.
[23] Boxwala AA, Peleg M, Tu S, et al. GLIF3: a representation format for sharable
computer-interpretable clinical practice guidelines. J Biomed Inform
2004;37(3):147–61.
[24] Tu SW, Mansfield JG, Weida T, Berg D, et al. The SAGE guideline model:
achievements and overview. JAMIA 2007;14(5):589–98.
[25] Riaño D. The SDA⁄ model: a set theory approach. In: 20th IEEE international
symposium on computer-based medical systems, 2007. p. 563–8.
[26] López-Vallverdú JA, Riaño D, Collado A. Detecting dominant alternative
interventions to reduce treatment costs. LNAI 2011;6924:131–44.
[27] Wang D, Peleg M, Tu SW, Boxwala AA, Greenes RA, Patel VL, et al.
Representation primitives, process models and patient data in computer-
interpretable clinical practice guidelines. A literature review of guideline
representation models. Int J Med Inform 2002;68(1–3):59–70.
[28] Peleg M, Tu S, Bury J, Ciccarese P, Fox J, Greenes RA, et al. Comparing
computer-interpretable guideline models: a case-study approach. J Am Med
Inform Assoc 2003;10(1):52–68.
[29] Hadorn DC. Use of algorithms in clinical guideline development in Clinical
Practice Guideline Development: Methodology Perspectives. Agency for
health-care Policy and Research: Rockville, MD; January 1995. p. 93–104
[AHCPR Pub. No. 95-0009].
[30] Society for Medical Decision Making. Committee on standardization of clinical
algorithms. proposal for clinical algorithm standards. Med Decis Making
1992;12:149–54.
[31] Shortliffe EH, Buchanan BG, Feigenbaum EA. Knowledge engineering for
medical decision making: a review of computer-based clinical decision aids.
Proc IEEE 1979;67(9):1207–24.
[32] Miller RA. Medical diagnostic decision support systems – past, present, and
future. JAMIA 1994;1:8–27.
[33] Turban E. Implementing decision support systems: a survey. In: IEEE
international conference on systems, man, and cybernetics, 1996. p. 2540–5.
[34] Kaplan B. Evaluating informatics applications – clinical decisions support
systems literature review. Int J Med Inform 2001;64:15–37.
[35] Ruland CM. A survey about the usefulness of computerized systems to
support illness management in clinical practice. Int J Med Inform
2004;73:797–805.
[36] Peleg M, Tu S. Decision support, knowledge representation and management
in medicine. IMIA Yearb Med Inform 2006:72–80.
[37] Berlin A, Sorani M, Sim I. A taxonomic description of computer-based clinical
decision support systems. J Biomed Informa 2006;39:656–67.
446 D. Riaño et al. / Journal of Biomedical Informatics 45 (2012) 429–446
[38] Sittig DF, Wright A, Osheroff JA, Middleton B, Teich JM, Ash JS, et al. Grand
challenges in clinical decision support. J Biomed Informa 2008;41:387–92.
[39] Amit X, Garg AX, Neill KJ, Adhikari NKJ, McDonald H, Rosas-Arellano MP, et al.
Effects of computerized clinical decision support systems on practitioner
performance and patient outcomes. JAMA 2005;293(10):1223–38.
[40] Kawamoto K, Houlihan CA, Balas EA, Lobach DF. Improving clinical practice
using clinical decision support systems: a systematic review of trials to
identify features critical to success. BMJ 2005;330(7494). doi:10.1136/
bmj.38398.500764.8F.
[41] Jaspers MWM, Smeulers M, Vermeulen H, Peute LW. Effects of clinical
decision-support systems on partitioner performance and patient outcomes:
a synthesis of high-quality systematic review findings. JAMIA
2011;18(3):327–34.
[42] Sim I, Berlin A. A framework for classifying decision support systems. In: AMIA
Annu Symp Proc.; 2003. p. 599–603.
[43] Wolfram DA. An appraisal of INTERNIST-I. Artif Intell Med 1995;7:93–116.
[44] Myers JD, Pople HE, Miller RA. CADUCEUS: A computerized diagnostic
consultation system in internal medicine. In: Proc Annu Symp Comput Appl
Med Care, 1982. p. 44–7.
[45] Shortliffe EH. Computer-based medical consultations. MYCIN. New
York: Elsevier; 1976.
[46] Musen MA, Gennari JH, Wong WW. A rational reconstruction of INTERNIST-I using
PROTéGé-II. In: Proc Annu Symp Comput Appl Med Care, 1995. p. 289–93.
[47] Cascorbi I. The promises of personalized medicine. Eur J Clin Pharmacol
2010;66:749–54.
[48] Maglaveras N, Bonato P, Tamura T. Guest editorial special section on personal
health systems. IEEE Trans Inform Technol Biomed 2010;14(2):360–3.
[49] Campana F, Riaño D. Formal intervention plans III. K4CARE project report D06,
<http://banzai-deim.urv.net/projects/K4CARE/Docs/5-K4CARE-FIPs03.pdf;
2008 (accessed Nov 2011).
[50] Ercolani S, Real F, Annicchiarico R, Campana F, Federici A, Mecocci P, et al. Case
profile ontology. K4CARE project report D05.3, <http://banzai-deim.urv.cat/
projects/K4CARE/Docs/4-K4CARE-CPO.pdf>; 2008 [accessed November 2011].
[51] Isern D, Moreno A, Pedone G, Sánchez D, Varga LZ. Home care personalisation
with individual intervention plans. In: Knowledge management health-care
procedures, LNAI 5626, 2009. p. 134–51.
[52] Romero C, Riaño D, Real F. Ontology-based retrospective and prospective
diagnosis and medical knowledge personalization. In: Knowledge
representation for health-care, LNAI 6512; 2011. p. 1–15.
[53] Tomassini P, Campana F, Quattrociocchi C, Tini N, Dolezal J, Annicchiarico R,
et al. Validation and assessment of platform – II. K4CARE project report D12.2,
<http://banzai-deim.urv.cat/projects/K4CARE/Docs/8-K4CARE-Valid02.pdf>;
2009 [accessed November 2011].
[54] Romero C. Ontology-Based Diagnosis and Personalization of Medical
Knowledge. MsC thesis dissertation, <https://deim.urv.cat/pfc/docs/pfc735/
d1244024300.pdf>; 2009 [accessed November 2011].