Unified Modeling Language and Design of a case-based retrieval system inmedical imaging

Christel LeBozec, M.D., Marie-Christine Jaulent PhD., Eric Zapletal and Patrice DegouletM.D., Ph.D.

Medical Informatics Department, Broussais Hospital, 75014 Paris, Francelebozec @hbroussais.fr

One goal of artificial intelligence research into case-based reasoning (CBR) systems is to developapproaches for designing useful and practicalinteractive case-based environments. Explaining eachstep of the design of the case-base and of the retrievalprocess is critical for the application of case-basedsystems to the real world. We describe herein ourapproach to the design of IDEM - Images andDiagnosis from Examples in Medicine - a medicalimage case-based retrieval system for pathologists.Our approach is based on the expressiveness of anobject-oriented modeling language standard: theUnified Modeling Language (UML). We created a setof diagrams in UML notation illustrating the steps ofthe CBR methodology we used. The key aspect of thisapproach was selecting the relevant objects of thesystem according to user requirements and makingvisualization of cases and of the components of thecase retrieval process.Further evaluation of the expressiveness of the designdocument is required but UML seems to be apromising formalism, improving the communicationbetween the developers and users.

INTRODUCTION

Developing sound knowledge based systems inradiology and pathology is difficult because thesedomains can hardly be modeled by logicalformalization. Case-Based Reasoning (CBR) can beused in such weak-theory domains. CBR makes itpossible to reuse prototype images and diagnosis ofpreviously resolved cases to explain new situations[1]. CBR systems have been validated for intelligentreference image selection in MACRAD [2],IMAGECREEK [3], DIAGMED [4] and for retrievalof radiology reports in ISIS [5].The status of methodology employed for designingreal-world CBR systems is not achieved. There havebeen several attempts to define appropriate CBRsystems development methodologies, mostlyassociated with specific projects [6], but sometimesalso more formally [ 1,7].A rapid prototyping strategy is currently considered tobe the most effective way to design useful andpractical interactive case-based environments [8,9]. Amajor drawback with this incremental development isthat the user is only involved in the validation ofprototypes. It is difficult to validate the deepcomponents of the system based purely on theperformance of a prototype. It is also vital that the

system developers have a good understanding of themedical knowledge involved in the cases and in theretrieval process.An alternative approach to CBR system developmentis to involve both users and developers in the designof the first prototype by producing a comprehensivedocument. The Unified Modeling Language (UML), aunified notation based on various Object-Oriented(00) analysis and design methodologies, provides arepresentation of the components of a system thatbalances the expressiveness of the formalism and itscomputational tractability [10].The aim of this work was to use UML, as a suitableformalism to improve the understanding by both usersand developers of each step of the case-base andretrieval process design.We have used UML to illustrate the design of IDEM"Images and Diagnosis from Examples in Medicine",a CBR application for "intelligent" content-basedimage retrieval in pathology. Based on the descriptionof a new case, IDEM provides the images anddiagnosis for the most similar cases in the database[1 1].We first present the main CBR system developmentmethodologies and the concepts of UML notation.Then, some examples of UML diagrams used tospecify the relevant objects of the system are given asresults. Our results show that the legibility of UMLaffords participants to visualize and evaluate themodel before the implementation of the firstprototype. Furthermore, the modular nature of the 00approach makes it possible to edit and modify selectedimplemented objects of the case-base or retrievalprocess during the development.

METHODS

A methodology provides guidelines for the successfuldevelopment of a software system. It is usuallypresented as a series of steps, associated with specifictechniques and notations. As the complexity of CBRsystems increases in scope and scale, it becomeschallenging to use such methodology to design theglobal architecture of the system as well as eachspecific component.Bergman et al., as part of the APPLICUS project,designed a sample project plan for the development ofCBR applications [8]. They use MILOS, a softwareprocess modeling system in which the model isdefined in terms of processes, methods, products,goals and resources. Several types of processes can beidentified (technical, managerial and organizational

1091-8280/98/$5.00 C 1998 AMIA, Inc. 887

processes). The processes involved in this CBRapplication include for example: defining the scope ofthe CBR project, background knowledge modeling,case acquisition. For each process, input, output,resource consumption and methods are specified. Aset of product types (e.g. descriptive models, case-

bases, CBR prototypes, technical environment,documentation...) is provided. The methodology usedin the APPLICUS project provides a global model forthe development and deployment of a CBR system.Other studies [1,12] have produced similar genericmethodologies for developing CBR systems. Thegeneric subprocesses and products flow involved inthe design of a CBR system are depicted in Figure 1.

Figure 1- CBR system development processes

We used the concepts of 00 software developmentwithin this framework. This approach involvesmodeling objects from the real world and then usingthe model to build a system application based on thoseobjects. 00 modeling and design lead to a betterunderstanding of requirements, simpler designs, andmore maintainable systems.UML is a language for specifying, constructing,visualizing, and documenting the objects of a softwaresystem readable by humans and machines. It combinesthe concepts of the main available 00 methodologies[13-15]. The authors of UML didn't produce a

standard process but they did promote a developmentprocess that is use-case driven, architecture centric,iterative and incremental. 00 methodologyformalized by UML can be used to define the objectsinvolved in the various processes using a series ofdiagrams specified by user requirements. Userrequirements are initially expressed in terms of use

cases. Specification of a use case defines the possiblesequences of interactions between participants and thesystem.A specific pattern of interactions is shown on

interaction diagrams. There is at least one

interaction diagram for each significantly differentkind of use case instance. A summary table is thenproposed from all the interaction diagrams thatproduce the effects of the use cases.

888

There are two types of interaction diagram: sequence

diagrams and collaboration diagrams.A sequence diagram shows the explicit chronologicalsequence of messages between participants and thesystem. Sequence diagrams are suitable for real timespecification and for complex scenarios.A collaboration diagram highlights the set of objectsthat implement the use case. It also specifies the way

they are linked together by the sequence of message

flows. Collaboration diagrams are more useful thansequence diagrams for understanding all the effects on

a given object and for procedural design. Eachcollaboration diagram provides a preliminary classmodel. The objects emerging from the variouscollaboration diagrams of the use cases are compiledinto class diagrams for the object model.

RESULTS

This method was applied to our specific case-basedretrieval system project to produce an analysis anddesign document. In IDEM, the medical imageretrieval process is based on a comparison betweenmeaningful image features. The main use case is"Case comparison" and is involved in several otheruse cases occurring in daily practice as

"Standardization", "Quality assurance", "Diagnosissupport", "Education"... In this section, we illustratethe expressiveness of the UML formalism by a seriesof diagrams used to specify the relevant objects. Theset of objects has been implemented in an objectdatabase (02 system)[16].

Object selection by UML diagrams.The participants involved in the use case diagrams ofIDEM are users (students, pathologists and experts)and people involved in the realization andmaintenance of the system (experts and developers)(Figure 2).

C(Idz Case n

Figure 2 - Use cases diagram of the image retrievalsystem

A set of scenarios is attached to each use case (Table1). Using the summary table the scenarios areproposed by the experts and validated by the otherparticipants.

Table 1. The main use cases and thecorresponding scenarios

ScenariosDefinition/Modification of areadescriptorsDefinition/Modification ofdescriptor valuesDefinition/Modification of casedescriptionDefinition/Modification of caseindexingDescription of a new caseRetrieval of similar casesSimilarity justificationComparison of descriptions for asingle caseComparison/Standardization ofthe descriptions for a single caseComparison/Standardization ofthe descriptions of cases from thesame diagnostic classComparison/Standardization ofthe indexing of the cases of asingle diagnostic classComparison/Standardization ofthe descriptions for a single caseRetrieval of similar cases

Comparison/Standardization ofthe descriptions for a single case

Scenarios corresponding to the two main processeshave been identified (Figure 1): constitution of thecase base and retrieval process determination.The key object that implements the case baseconstitution is "case". A case is a set of empiricaldata, gathered by an experienced pathologist whilesolving a situation. A case is a collection ofmacroscopic areas, each associated with a collectionof histologic areas. A histologic area may containseveral other histologic areas as well as cytologicaldescriptions (class "cell "). Each type of area isdefined by a set of about ten specific features. Forinstance, (nuclear-size: large) is one of the features ofhistologic areas of the proliferation type.On the legible object model of the- domain (Figure 3)the user can visually identify a missing class orattribute. The main classes can be edited thanks to the02 interface so that the user adds or modifiescomponents of the cases.

889

CaseN0: numautoTopography : stringSide: stringSize : stringClinicalcontext: stringAge : stringRace : stringSex : stringDiagnosis: Diagnosis

AreaSize: stringTopography : stringOutline : stringLimits : stringShape: stringNumber: stringImportance : stringRelief: string

Macroscopicarea HistologicqareaColor: string Architecture: stringConsistency : string

CellCytoplasmic-staining: stringNuclearsize: stringNuclear-shape: stringNucleole: stringNuclearstaining: stringMitoticactivity: stringChromatin : string

Figure 3 - The object model of a pathological case

Figure 4 illustrates an aspect of the definition of thesecond component of our CBR system: the retrievalcomponent. Retrieval capacity depends on thedefinition of similarity between cases. Overallsimilarity is computed as the aggregation of localsimilarities between morphological features. Asimilarity table is defined for each feature such that allthe possible values of the feature can be compared.For instance, the possible values for the feature"nuclear size" are "small", "medium", "large",veryjlarge". "Defining/Modifying local similarity ofan attribute" is one of the sequence diagrams thatexplicitly emphasizes a particular aspect of the usecase "Configuring the system".

expertBase : Expert system: System1: Display the General Model

2: Select the Class "Nuclear Size"3: Display the Selected Class

4: Display the SimilarityTable

5: Display the List of Symbols6: Select a couple of symbols7: Edit the local similarity

8:Modify the local similarity

Figure 4 - The sequence diagram of"Defining/Modifying the local similarity of an

attribute"

.---

-

Figure 5 shows the corresponding collaborationdiagram. The objects describing the use case, such as

Similarity Table, Symbol... are emerging. Someobjects do not belong to the domain, but to thehuman-computer-interaction. In Figure 5, "L-Objects"(for List-Objects) corresponds to a set of instances ofthe class "Object".

"W-objects" (for (Window-Objects)) correspond tothe interface objects that are successively displayed on

the screen (WConfiguration) for a particular scenario(Figures 6 and 7). The visualization of the"W-objects" gives an idea of the fonctionalities of thefuture prototype.On Figure 7, the parameters of "WSimilarity_table",once edited, can be changed by the expert.

DISCUSSION AND CONCLUSION

Developing CBR systems is more than just deliveringprototypes for the retrieval of cases, based on case

comparison. It is important to make sure that all thecomponents of the system and the steps in the process

are convenient and comprehensible to experts, users

and developers alike.Before its recent adoption as a standard by the ObjectManagement Group (OMG), UML was already a defacto standard embraced by many organizations andvendors due to its expressiveness, conciseness andmodular nature. However, these advantages have notbeen exploited in developing CBR systems. We foundthat UML could be useful to display objectsimplementing the use cases of a daily practice and toextend the object model to the level of a programminglanguage.In this paper we have presented a selection ofdiagrams illustrating the expressiveness of the designdocument.Representing the design with UML has considerableadvantages. First, it is possible for experts to validateand modify the case model and to act on the varioussteps of the retrieval process during the development.Second, the knowledge included in the system isevaluated at the level of the interface objects. Theperformances of the first resulting prototype are notadversely affected by the use of a great deal ofpreliminary and simplified information to evaluate thevalidity of the system.At last, the legibility of UML affords the developersto appreciate the complexity of the futureimplementation of the system.CBR systems in similar application domains such as

radiology or pathology necessarily have use cases andscenarios in common. Unifying the design languagemay be useful for experts and system designers ofvarious application domains to combine their

890

1: Display2: eect

Figure 5 - The collaboration diagram"Defining/Modifying the local similarity of an

attribute "

respective experience and to solve their problems inbuilding medical image retrieval systems.We are currently studying human computerinteractions. Before people can decide whether to relyon a CBR system's advice, they must understand thecriteria by which the system identifies a particularcase as being the most relevant to a given problem[17]. We think it would be valuable to allow users totune the retrieval process. The users could select theirown criteria for relevant cases by changing apredefined set of degrees of similarity.

References

1. Kolodner JL. Case-basedreasoning. MorganKaufmann, 1993.

2. Macura RT, Macura KJ. MacRad: Radiologyimage resource with a case-based retrieval system.In: First International Conference on Case-BasedReasoning: Research and Development, VelosoM, Aamodt A (eds), Berlin: Springer Verlag,1995; 43-54.

3. Grimnes M, Aamodt A. A two layer case-basedreasoning architecture for medical imageunderstanding, In: Case-Based Reasoning- ThirdEuropean Workshop, Smith I, Faltings B (eds),Berlin: Springer Verlag, 1996; 164-178.

4. Maulmy 0. Un systeme d'aide a l'interpretationd'images medicales, Memoire de diplomed'ingenieur CNAM, 1997.

5. Kahn CE, Anderson GM, Case-based reasoningand imaging procedure selection. InvestigativeRadiology, 1994; 29: 643-7.

6. Althoff KD, Wess S., Weis KH, Auriol E,Bergman R, Holtz H et al. An evaluation of thefinal integrated system. Technical report. EspritProject INRECA Deliverable D6, 1995.

7. Bergmann R, Wilke W, Schumacher J. Usingsoftware process modeling for building a case-based reasoning methodology: Basic approachand case study. In: International Conference onCase-Based Reasoning, Springer Verlag, 1997;509-519.

8. Bartsch-Sprol B. How to make CBR systemswork in practice. In: 4h German Workshop onCase-Based Reasoning: System development andevaluation; Burkhard H.D, Lenz M. (eds), Berlin,1996; 36-42.

9. Boehm BW. A spiral Model of SoftwareDevelopment and Enhancement, Computer, 1988;21(5): 61-72.

10. The Rational Rose documentation home page:http:llwww.rational.com/uml/documentation.html

11. Jaulent MC, Le Bozec C, Zapletal E, Degoulet P.Case-based diagnosis in histopathology of breasttumours. Accepted to MEDINFO 1998.

12. Goel AK, Murdock JW. Meta-Cases: ExplainingCase-Based Reasoning. In: Case-BasedReasoning- Third European Workshop, Smith I,Faltings B (eds), Berlin: Springer Verlag, 1996;150-163.

13. Booch G. Object-oriented analysis and designwith applications, 2nd edition, Addison-Wesley,1994.

14. Jacobson I, Ericson M, Jacobson A. The Objectadvantage. Business Process reengineering withObject technology, Addison-Wesley, 1994.

15. Rumbaugh J, Blaha M, Premerlani W, LorensenW. Object-oriented modeling and design. PrenticeHall, 1991.

16. The 02 technology home page.http:Hlwww.O2tech.fr/index.html.

17. Ashley KD, Aleven V. A logical representationfor relevance criteria. In: Case-Based Reasoning-First European Workshop, Wess S, Althoff KD,Richter MM (eds), Berlin: Springer Verlag, 1993;338-52.

891