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