=Paper=
{{Paper
|id=None
|storemode=property
|title=Interpreting Patient Data using Medical Background Knowledge
|pdfUrl=https://ceur-ws.org/Vol-897/session2-paper06.pdf
|volume=Vol-897
|dblpUrl=https://dblp.org/rec/conf/icbo/OberkampfZB12
}}
==Interpreting Patient Data using Medical Background Knowledge==
https://ceur-ws.org/Vol-897/session2-paper06.pdf
Interpreting Patient Data using Medical Background Knowledge
Heiner Oberkampf 1∗, Sonja Zillner 1 , Bernhard Bauer 2 and Matthias Hammon 3
1
Corporate Technology Siemens AG, 81739 Munich, Germany
2
Programming Distributed Systems, University of Augsburg, 86135 Augsburg, Germany
3
University Hospital Erlangen, 91054 Erlangen, Germany
ABSTRACT annotations capture only descriptive information of its content, i.e.
Clinical patient data, such as medical images and reports, establish the observations made, the findings discovered, the various sym-
the basis of the diagnostic process. In order to improve the access ptoms identified2 . Though in practice clinicians often want to search
to heterogeneous and distributed clinical data sources recent work for higher level information, e.g. disease information. Consider the
concentrates on extracting semantic annotations with links to conce- diagnostic process: after a CT-scan a clinician looks for findings
pts of medical ontologies, such as RadLex, FMA, SNOMED CT or indicating certain diseases he suspects the patient might have. For
others. However, these annotations are not always on the appropri- instance, the clinician looks for cancer-indicating findings or sym-
ate level of detail for clinical applications as they simply reflect the ptoms in the CT image series. The problem is that even though
descriptive content of the respective patient data. For integrating the existing medical ontologies encompass information about diseases
data into the clinical work-flow, an interpretation of annotations using and symptoms, knowledge about their interrelations is missing.
medical background knowledge is needed. In this paper we present Today methods for capturing and exploiting the information about
a use-case of such an interpretation: we have built an initial onto- semantic relation between symptoms, for instance CT-image anno-
logy containing lymphoma-related diseases and symptoms as well as tations describing findings, and their associated diseases are mis-
their relations. The created ontology is used to infer likely diseases of sing. Thus, the search for cancer-indicating findings is only possible
patients based on annotations. In this way, annotations can be under- through a search for specific finding as e.g. ”enlarged mediastinal
stood in the context of likely diseases and help the clinician to make a lymph nodes” or ”enlarged spleen” assuming that the clinician is
diagnosis. By means of a prototype implementation we evaluate our informed about likely symptoms of a disease. However, clinicians
approach and identify further knowledge requirements for the model. are usually experts in one particular domain, leading to a lack of
prior knowledge about the interrelations of symptoms and diseases
1 INTRODUCTION in case certain diseases are no longer in the scope of their expertise.
Clinical patient data, such as medical images and patient reports, In other words, there is a clear danger that the information about the
provide the basis for the diagnostic process. However, the enormous relevance of identified symptoms remains overlooked or misinter-
volume and complexity of data prevents clinical staff to get the full preted, leading to wrong or not appropriate treatments, etc. Thus, the
use of the content of the data by reviewing it all. Recent work aimed relevance-based highlighting of information about clinical observa-
to make heterogeneous clinical data better accessible (for search or tions in the context of likely diseases supports clinicians to improve
other processes) by means of structured semantic annotation with their treatment decisions.
concepts of well established medical ontologies like RadLex, the Within this paper, we introduce a use case scenario in the domain
FMA, SNOMED CT or others. For instance, the Theseus MEDICO of clinical diagnose that relies on the seamless interpretation of
project1 aims at the automatic extraction of descriptive content of annotations by integrating formalized medical background know-
medical images for better integration into clinical processes as e.g. ledge about interrelations of diseases and symptoms. However, the
decision making. Approaches for semantic annotation range from information about disease and symptom interrelations is not covered
automatic image parsing (Seifert et al., 2009) and information extra- by existing medical ontologies. We fill the missing link by proposing
ction DICOM headers and structured reports (Möller et al., 2009) a Disease-Symptom-Ontology that contains diseases, symptoms,
to (aided) manual approaches (Wennerberg et al., 2008), (Channin their relations and as many links as possible to established medi-
et al., 2010) and (Rubin et al., 2008). In the MEDICO project a cal ontologies. As a disease-symptom ontology can be arbitrarily
dedicated Annotation-Schema, the MEDICO-Annotation-Ontology complex, we need to be very specific about the scope and the goal
(Seifert et al., 2010), was created to store the annotations of clinical of the proposed ontology. The contribution of this paper is to detail
data in a structured way in order to improve precision and recall in the knowledge model as well as the knowledge engineering steps of
information retrieval in comparison to simple key-word tagging as the first version of the ontology model that aims to fulfil the requi-
pointed out in (Opitz et al., 2010). Moreover, in MEDICO, anno- rements of our use case scenario: the aim here is to infer likely
tations were used to classify lymphoma patients according to the diseases based on patient annotation data, helping the clinician in
Ann-Arbor staging system which relies mainly on the location of the diagnosis. After the automatic detection of an initial set of fin-
enlarged lymph nodes (Zillner, 2009). dings and corresponding diseases, this information can be used in
So the good news is that great progress has been made concerning differential diagnosis, where the clinician intends to either exclude
the extraction of annotations. The problem however is that these or strengthen particular diseases. So the first list of symptoms and
likely diseases in turn indicates to check for further symptoms. E.g.
∗ To whom correspondence should be addressed: hei- ”enlarged lymph nodes” indicates to check for B-symptomatic i.e.
ner.oberkampf.ext@siemens.com
1 http://theseus-programm.de/en/920.php 2 We exchangeably use the terms symptom, sign, finding and observation.
1
Oberkampf et al
weight loss, fever and night sweat). Understanding available sym- diseases and even though DOID aims also at ontological treatment
ptom annotations in the context of diseases improves the process of diseases and diagnosis (Scheuermann et al., 2009) relations to
significantly as the clinician will not miss any findings and sym- symptoms, if present, are hidden in a owl:AnnotationProperty cal-
ptoms of diseases that might be out of his (main) expertise. Through led ”def” as text. For lymphoma there are no symptoms specified in
our application that relies on the Diseases-Symptom-Ontology we DOID.
are able to make the likely diseases of the patient explicit, which
again improves and accelerates the diagnostic process. Based on 3 MEDICAL BACKGROUND KNOWLEDGE
a clinical evaluation of the implemented use case, we identified Medical Ontologies provide a comprehensive and well structured
further knowledge requirements for the model. vocabulary, which allows to describe precisely the content of images
In Section 2, we will first sketch the related work of clini- and reports in annotations. When we want to use these descriptive
cal decision support systems and medical ontologies as well as annotations (observations made, findings, symptoms) in clinical
discuss in Section 3 the medical background-knowledge that is decision support systems, we need to interpret them. Existing medi-
required for interpreting clinical annotations with respect to likely cal ontologies however contain most of their information in their
diseases. Section 4 shows how the medical knowledge can be repre- class-hierarchy. They do not have enough relations of symptoms to
sented in a Disease-Symptom-Ontology. By means of a prototype other relevant concepts as e.g. diseases, examinations or medication.
implementation we evaluate our approach and identify further kno- In particular, existing ontologies can’t be used to infer likely disea-
wledge requirements for the model (Section 5). We conclude with ses, plan further treatments or control therapy results and medication
an outlook of the future work. effects based on annotations describing findings.
Similar to the cognitive decision process of clinicians, who rely
2 RELATED WORK on their experience and expertise, we take medical background kno-
2.1 Clinical Diagnostic Support wledge to automatically interpret the findings and symptoms in
order to integrate them in aforementioned clinical processes. In the
Although various clinical diagnostic support systems have been rea-
first use case we aim to make annotations useful in diagnosis. Pre-
lized (for a comprehensive overview we refer to the open-clinical
dominantly we need the relations between symptoms and diseases.
website3 ), they are either tailored to a particular type or range of
This background knowledge is used to make likely diseases expli-
diseases, e.g. cardiac diseases (K and Singaraju, 2011) or aim to effi-
cit (see figure 1). Knowing likely diseases makes it easier to plan
ciently access and integrate to (only) external medical knowledge
next examinations. Further, the clinician gets an overview of what
resources, such as the access to evidence-based best-practices4 or
symptoms of certain disease are present without going through all
the access to relevant international studies and publications5 . More-
images and reports. Especially this helps the clinician not to miss
over, various standalone decision support systems for clinical dia-
symptoms in the diagnostic process.
gnosis, such as MYCIN (Shortliffe, 1976), CASNET (Kulikowski
and Weiss, 1982), DXplain6 or other expert systems for diagno-
sis have been developed that require manual input of symptom and
finding information to infer a set of likely diseases.
2.2 Medical Ontologies
We also analysed existing medical ontologies like SNOMED CT,
FMA, RadLex and DOID with respect to disease-symptom relati-
ons. The Human Disease Ontology (DOID) consists of about 8000
diseases structured in a hierarchy, SNOMED CT provides a huge
vocabulary of clinical terms, the Foundational Model of Anatomy
(FMA) – a detailed description of the anatomy, RadLex – a stru-
ctured terminology for the radiological domain . . . However none
of them contains diseases and symptoms and the relation betw-
een them, such that we could use the information to analyse our
annotations with respect to diseases. E.g. SNOMED CT contains
”Hodgkin-Lymphoma” and ”lymphadenopathy” but no relation in- Fig. 1. From annotated patient data to diagnosis support: taking medical
between. The only relation we have is that the ”lymph node stru- background knowledge to interpret annotations.
cture” is FindingSiteOf ”Hodgkin-Lymphoma” as well as ”lymph
node structure” is FindingSiteOf several types of ”lymphadenopa- Knowledge about the disease-symptom-relations can be found
thy”. The Human Disease Ontology gives us a good hierarchy of in common clinical knowledge resources as for example ”Innere
Medizin” (G. Herold und Mitarbeiter), where about 300 diseases
3 http://www.openclinical.org/dss.html are listed and described. Besides definition of the disease with cor-
4 ZynxAmbulatory: http://www.zynxhealth.com/Solutions/ responding symptoms, epidemiological information, classification,
ZynxAmbulatory.aspx risk-factors, clinical best practices for further treatment and therapy,
5 LeitsymptomNavigator: http://www.albis.de/home/news/ the typical age and other useful information can be found in ”Innere
nachricht-anzeigen/browse/3/datum////-1e3591bb94/?tx ttnews% Medizin”. Sometimes there is valuable extra-information as pro-
5BbackPid%5D=255&cHash=f625030d5cc0c3ad26d76d1a406e1945 babilities for occurrence of symptoms (e.g. ”Hodgkin-Lymphoma”
6 http://lcs.mgh.harvard.edu/projects/dxplain.html has the symptom ”enlarged lymph nodes” with probability 85%) or
2
Interpretation of Patient Data
hints for differential diagnosis (e.g. symptom ”enlarged mediastinal
lymph node” indicates differential diagnosis ”Hilus-Tbc”, ”Non-
Hodgkin-Lymphoma”, ”Bronchial carcinoma” and others). Some of
the symptoms are precisely specified (e.g. ”weight loss” more than
10% within the last 6 month).
4 THE DISEASE-SYMPTOM-ONTOLOGY
Our goal is to establish a knowledge model able to represent infor-
mation contained in Herold’s ”Innere Medizin” necessary for clini-
cal diagnosis. First of all this is the relationship between symptoms
and diseases. As we want to use this Disease-Symptom-Model for
the interpretation of annotations as shown in figure 1 we also cho-
ose to model the relations in an ontology with links to the medical
ontologies which are used for annotations. Figure 2 shows how the
Disease-Symptom-Ontology relates to other ontologies.
Fig. 3. A CT-image showing a lymphoma-indicating finding.
like DiSy:hasDOID, DiSy:hasRadLex ID, DiSy:hasFMA ID and
DiSy:hasSNOMED ID. This way of referencing works well if
there exist corresponding concepts. However, finding correspon-
ding concepts is generally difficult, so we take several approaches
of linking concepts. We always try to link to single corresponding
concepts but additionally we may link to two concepts, the one defi-
ning the location or parameter and the other – the modification:
examples are ”lymph node” and ”enlarged” or ”carcinoembryonic
Fig. 2. Ontology architecture: the Disease-Symptom-Ontology has to be antigen” and ”raised”. If we do not find one single corresponding
linked to all medical ontologies used for annotation of clinical patient data. concept for a symptom, this is the only way of linking:
DiSy:Enlarged_mediastinal_lymph_node
DiSy:hasSNOMED_ID SNOMEDCT:52324001;
The cornerstones of the Disease-Symptom-Ontology are the clas- DiSy:hasAnatomicalRegion_RadLex RID28891;
ses DiSy:Disease and DiSy:Symptom with subclasses for specific DiSy:hasModifier_RadLex RID5791.
diseases and symptoms. Additionally to the classes we have indivi- Here SNOMED CT has a corresponding concept SNOME-
duals for all diseases and symptoms to be able to relate symptoms DCT:52324001 (”mediastinal lymphadenopathy”), whereas Rad-
and diseases with the owl:ObjectProperty DiSy:hasSymptom and a Lex has no single one, so we need to take the two conce-
sub-property DiSy:hasLeadingSymptom. This approach is similar pts RID28891 (”mediastinal lymph node”) and RID5791 (”enlar-
to the one in RadLex, the FMA or other medical ontologies which ged”) with respective relations. Using two links is similar to the
contain both classes and individuals. The relations should not be annotation-techniques in the MEDICO project. Indeed, many dif-
understood in the way ”d always has symptom s” as this is not true ferent links to the ontologies allow us to recognize better the
in the medical domain. At this point we avoid getting into techni- symptoms described in the MEDICO-annotations. The recognition
cal questions like how to represent formally that a disease ”may” be is done through querying the annotation data in the following way:
caused by something or that a disease ”may” show up by some sym- in the Disease-Symptom-Ontology we have a class DiSy:Patient and
ptom. For a good description of that problem we refer to (Rector an owl:ObjectProperty :showsSymptom for relating patients with
et al., 2008). Even though existing medical ontologies provide a symptoms. Our query component searches for annotations, repre-
detailed description of the medical domain this link is still missing senting symptoms as shown in figure 3. If such annotation data is
as described in the related work section. found, let’s say for a symptom S, then a triple ”patient :showsSym-
4.1 Establish Alignments ptom S” is added to our ontology. As we do not need direct matches
of annotations and symptoms (as illustrated in figure 3) one can see
Linking the Disease-Symptom-Ontology to other medical ontolo-
that through the referenced ontologies we fan out our symptoms
gies has two reasons: firstly, this is necessary as we aim to interpret
to all subclasses of the linked concepts: even though DiSy does
annotations which are taken from them. Our second purpose is to
not contain a symptom, which directly references ”enlarged” and
benefit from their structure (see structure import below). Figure 3
”facial lymph node”, these image annotations will be captured at
exemplary illustrates how symptoms of DiSy are linked to Rad-
least as the symptom ”enlarged lymph node”, since ”lymph node”
Lex such that annotations can be interpreted in a disease-context: a
is a superclass of ”facial lymph node”.
CT-image annotated with RadLex-concepts ”enlarged” and ”facial
lymph node”: we infer that the image shows a lymphoma-indicating 4.2 Importing Structure
finding but not a colorectal-cancer-indicating.
As mentioned above we try to reuse knowledge from other medical
Links to other ontologies: Basically we hold the identifiers of ontologies. In this section we describe how the subclass-structure
the referenced concepts with owl:AnnotationProperty relations of DiSy is automatically created. All diseases are initially entered
3
Oberkampf et al
as simple sub-classes of DiSy:Disease, i.e. without any hierarchi- • Open symptoms: symptoms without any corresponding anno-
cal information. Likewise for symptoms. The only information we tation data. These symptoms haven’t been examined yet and
need to enter is the link to external ontologies. The big advantage need to be targeted next.
of importing the hierarchy is that we reuse existing knowledge. If
two referenced concepts in an external ontology (for diseases e.g. This information forms the basis for inferring a ranked list of
to DOID) stand in a sub-class relation, then we will enter a sub- likely diseases, but there are more factors with influence on the
class relation between the referencing concepts of DiSy. This can be ranking: e.g. information about leading-symptoms, the intensity or
achieved by a simple SPARQL CONSTRUCT statement. E.g. we novelty of symptoms, the age- and sex-specific incidence propor-
have two diseases ”Lymphoma” and ”Hodgkin-Lymphoma”, initi- tion7 of a disease and risk-factors due to other diseases or life-style
ally direct sub-classes of DiSy:Disease and with corresponding links (e.g smoking). Most of this knowledge is also contained in Herold’s
to DOID. Due to DOID ”Hodgkin-Lymphoma” is a sub-class of ”Innere Medizin” and we included such knowledge with the help of
”Lymphoma”, so this relation is added to our ontology. The subclass owl:DatatypeProperties.
relation in the external ontology does not have to be direct, but it The weighting of the different factors is still a topic of the
could also be a sub-class path. Symptoms are structured similarly ongoing discussions with our clinical partners, but the basic idea
(see figure 4): ”Enlarged lymph node” and ”enlarged mediastinal is to measure how well the patient’s symptom information matches
lymph node” - in RadLex we have a subclass path ”mediastinal the typical symptomatology of some given disease in terms of pre-
lymph node”, ”deep lymph node of thorax”, ”lymph node of tho- cision and recall. Additionally, we provide the clinician with a
rax”, ”lymph node of trunk”, ”lymph node”. As rdfs:subClassOf is ”good graphical overview” about likely diseases with drill-down
a transitive relation after RDFS-reasoning within RadLex ”mediasti- possibilities.
nal lymph node” becomes a subclass of ”lymph node” so we make 5.2 Scope and Features of the Prototype
”enlarged mediastinal lymph node” a subclass of ”enlarged lymph
node”. This is done again by SPARQL CONSTRUCT statements. In the first implementation we focused on five diseases, for which
we already have annotated patient data from the MEDICO pro-
ject: Hodgkin lymphoma, non-Hodgkin lymphoma, reactive lym-
phadenitis, colorectal carcinoma and diverticulitis. In interviews
with clinicians we identified about 40 symptoms with relations to
these diseases. Additionally, the clinicians listed so called leading
symptoms (cardinal symptoms) for each disease.
As mentioned above the absolute and relative amount of present
and absent symptoms is most important for creating a ranked list
of likely diseases, where leading symptoms are weighted stronger.
In this demonstrator we used a stacked bar diagram to show the
absolute and relative amount of present and absent symptoms as
well as leading symptoms (see figure 5). Information about risk-
age and adapted incidence proportion is given additionally. Through
hovering over the chart the clinician can see lists of the present,
Fig. 4. Getting the subclass-hierarchy from established ontologies.
open and absent symptoms. Another tab gives a ranked list of open
symptoms helping the clinician to plan next examinations.
The structure import is done only once so that its computational 5.3 Clinical Evaluation
effort can be accepted. In interviews with clinicians we got a positive feedback: infer-
ring likely diseases shows the usefulness of annotations for clinical
decision support. The graphical visualization and especially the pos-
5 PROTOTYPICAL IMPLEMENTATION
sibility to get an overview of open symptoms helps to plan further
5.1 Inference of likely Diseases examinations. Based on the prototype implementation the clinicians
Given a patient with an initial set of symptoms (explicitly represen- could explain what questions should be addressed next. Due to their
ted within the patient’s annotations), we are aiming to infer a ranked feedback it would be of high relevance to include information about
list of likely diseases. From the Disease-Symptom-Ontology and the time-sequences of symptoms in order to detect their development,
initial set of symptoms we can derive a list of likely diseases and in see differences between examinations and avoid inclusion of too old
a second step for each disease a set of related symptoms. After ali- patient-data. Further, they see a need in representing the intensity
gning the annotation data with the set of related symptoms the set of of present symptoms and e.g. the amount of enlarged lymph nodes
related symptoms can be split into three categories for each disease: (1, 2, many). Additionally, the clinicians pointed out it would be
extremely helpful to create a connection between medication and
• Present symptoms: symptoms for which corresponding anno- symptoms. Relying on the subclass hierarchy of medical ontologies
tations were found. is problematic: on the one hand there still exist simple errors like
• Absent symptoms: symptoms which were under inspection
but did not show up (e.g. ”no enlarged lymph nodes in neck- 7 The incidence proportion is the number of new cases within a specified
area”). Absent symptoms are of high importance as they allow time period divided by the size of the population initially at risk (Source:
a clinician to exclude certain diseases. Wikipedia)
4
Interpretation of Patient Data
6 CONCLUSION
Our approach of building a initial ontology referencing to the
relevant medical ontologies is well suited to understand annota-
tions with respect to symptoms and diseases. The description of
symptoms with the help of links makes our ontology flexible for fur-
ther applications. However through evaluation we identified several
necessary enhancements, concerning the coverage and expressivity
of the model. In future work we will address the listed require-
ments. Our long term aim is to build a generic context model for
a more flexible and context-dependent interpretation of annotations
under consideration of different medical background knowledge as
illustrated in figure 1.
ACKNOWLEDGEMENTS
This research has been supported in part by the THESEUS Pro-
Fig. 5. Prototype implementation with graphical overview of present, open gram in the MEDICO Project, which is funded by the German
and absent symptoms and leading symptoms. Federal Ministry of Economics and Technology under grant num-
ber 01MQ07016. The responsibility for this publication lies with
the authors.
underlined in (Rector et al., 2011), on the other hand – subclas-
ses do not always represent their superclass in a symptom-relevant REFERENCES
sense. E.g. in SNOMED CT ”intended weight-loss” is a subclass Channin, D. S., Mongkolwat, P., Kleper, V., Sepukar, K., and Rubin, D. L. (2010).
of ”weight-loss” (a symptom for lymphoma). Patient data annotated The caBIGTM Annotation and Image Markup Project. J. Digital Imaging, 23(2),
217–225.
with the concept ”intended weight-loss” will create a triple ”:patient
K, V. and Singaraju, J. (2011). Article: Decision Support System for Congenital Heart
:showsSymptom :weight-loss”. We cannot avoid that in a general Disease Diagnosis based on Signs and Symptoms using Neural Networks. Interna-
way as we will not analyse all subclasses of referenced symptoms. tional Journal of Computer Applications, 19(6), 6–12. Published by Foundation of
Computer Science.
Kulikowski, C. A. and Weiss, S. M. (1982). Representation of expert knowledge for
5.4 Revised Knowledge Requirements consultation: The CASNET and EXPERT projects. In P. Szolovits, editor, Artificial
We learned from the evaluation that we have to adjust our querying Intelligence in Medicine, pages 21–55. Westview Press.
component in order to keep track of the time-sequence of the sym- Möller, M., Regel, S., and Sintek, M. (2009). RadSem: Semantic Annotation and
Retrieval for Medical Images. In Proceedings of the 6th Annual European Semantic
ptoms. This can be done easily as this information is contained in Web Conference. o.A.
the MEDCIO-annotations, which are structured after studies with Opitz, J., Parsia, B., and Sattler, U. (2010). Evaluating Modelling Approaches for
time-stamps. Basically we have to replace the relation ”patient sho- Medical Image Annotations. CoRR.
wsSymptom S” by a blank node construction holding also a date, Rector, A., Brandt, S., and Schneider, T. (2011). Getting the foot out of the
pelvis: Modeling problems affecting use of SNOMED CT hierarchies in practical
the finding id, intensity etc. found in the annotations. Especially the
applications. JAMIA. 2011;18: 432-440.
finding id could be used to address the subclass-problem mentioned Rector, A. L., Stevens, R., and Drummond, N. (2008). What Causes Pneumonia? The
above, because this helps to track how we have come to specific pre- Case for a Standard Semantics for ”may” in OWL. In OWLED.
sent symptoms. In summary we set the following requirements for Rubin, D. L., Mongkolwat, P., Kleper, V., Supekar, K., and Channin, D. S. (2008).
an enhanced Disease-Symptom-Ontology and application making Medical Imaging on the Semantic Web : Annotation and Image Markup. AAAI
Spring Symposium Series Semantic Scientific Knowledge Integration.
use of it for clinical decision support: Scheuermann, R. H., Ceusters, W., and Smith, B. (2009). Toward an ontological
treatment of disease and diagnosis. Summit on Translat Bioinforma, 2009, 116–120.
• Temporal information is highly important in clinical diagno- Seifert, S., Barbu, A., Zhou, S. K., Liu, D., Feulner, J., Huber, M., Suehling, M., Caval-
laro, A., and Comaniciu, D. (2009). Hierarchical parsing and semantic navigation
sis. The model has to represent the temporal relevance of
of full body CT data. Proceedings of SPIE, pages 725902–725902–8.
symptoms, when and how long a symptom was present. This Seifert, S., Kelm, M., Möller, M., Mukherjee, S., Cavallaro, A., Huber, M., and Coma-
should allow to track the development of symptoms. niciu, D. (2010). Semantic Annotation of Medical Images. In Proceedings of SPIE
Medical Imaging, February 13-18, San Diego, CA, United States. o.A.
• Inconsistency handling: situations where annotations are con-
Shortliffe, E. H. (1976). Computer-Based Medical Consultations: MYCIN, volume 85.
tradicting each other (report: ”no enlarged lymph nodes”, American Elsevier.
image: ”enlarged mediastinal lymph node”) have to be pre- Wennerberg, P., Zillner, S., Möller, M., Buitelaar, P., and Sintek, M. (2008). KEMM:
sented to the clinician in an adequate way. Inconsistent sets of A Knowledge Engineering Methodology in the Medical Domain. In C. Eschenbach
present and absent symptoms are hints for a deeper inspection. and M. Gruninger, editors, 5th International Conference on Formal Ontology in
Information Systems. Formal Ontology in Information Systems (FOIS-08), October
• Represent a more fine-grade significance values of symptoms 31 - November 3, Saarbrücken, Germany, volume 183 of Frontiers in Artificial
in addition to ”leading symptoms” and the intensity of sym- Intelligence and Applications. IOS Press, Amsterdam.
ptoms (1, 2, many enlarged lymph nodes). Zillner, S. (2009). Towards the Ontology-based Classification of Lymphoma Pati-
ents using Semantic Image Annotations. In Proceedings of SWAT4LS Semantic
• Extend the coverage of the model to examinations and medi- Web Applications and Tools for Life Sciences (SWAT4LS), Amsterdam, Netherland,
cation. November, 2009.
5