Explaining Medical Model Exceptions - Computational Intelligence in Healthcare: Advanced Methodologies - page 260

Exceptional cases. The performed Fisher test confirms the hypothesis that patients
doing active fitness achieve better physical conditions than non-active ones. However,
there are exceptions, namely active patients whose health conditions did not improve.
Exceptional cases need to be explained. Explained exceptions build the case base.
According to table 1, the stronger the model, the more exceptions can be observed
and have to be explained. Every exception is associated with at least two problems.
The first one is “Why did the patient's condition get worse?” Of course, “worse” is
meant in terms of the chosen model. Since there may be some factors that are not in-
cluded in the model but have changed positively, the second problem is “What has
improved in the patient's condition?” To solve this problem significant factors where
the values improved have to be searched.
In the following section the set-up of a case base on the strongest model version is
explained.
2.2 Setting up a Case Base
We intend to solve both problems (mentioned above) by means of CBR. So we begin
to set up the case base up sequentially. That means, as soon as an exception is ex-
plained, it is incorporated into the case base and can be used to help explaining further
exceptional cases. Alphabetical order for the exceptional cases was chosen.
Since the case base is rather small, sophisticated retrieval algorithms are not re-
quired. So, the retrieval of already explained cases is performed by keywords. The
main keywords are “problem code”, “diagnosis”, and “therapy”. In the situation of
explaining exceptions for dialysis patients the instantiations of these keywords are
“adverse effects of dialysis” (diagnosis), “fitness” (therapy), and two specific problem
codes. Besides the main keywords, additional problem specific ones are used. Here
the additional keyword is the number of worsened factors. Further keywords are op-
tional. They are just used when the case base becomes bigger and retrieval is no
longer simple.
However, ISOR not only uses the case base as a knowledge source but further
sources are involved, namely the patient's individual base (his medical history) and
observed data (partly gained by dialogue with medical experts). Since in the domain
of kidney disease and dialysis the medical knowledge is very detailed and much in-
vestigated but still incomplete, it is unreasonable to attempt to create an adequate
knowledge base. Therefore, a medical expert, observed data, and just a few rules
serve as medical knowledge sources.
2.2.1 Expert Knowledge and Artificial Cases
In ISOR, an expert's knowledge can be used in many different ways. Firstly, it is used
to acquire rules, and secondly, it can be used to select appropriate items from the list
of retrieved solutions, to propose new solutions, and last but not least, to create artifi-
cial cases.
Initially, an expert creates artificial cases; afterwards they can be used in the same
way as real cases. They are created in the following situation. An expert points out a
factor F as a possible solution for a query patient. Since many data are missing, it may
happen that just for the query patient values of factor F are missing. In such a situation