Web-based Access to an Online Atlas of Anatomy:The Digital Anatomist Common Gateway Interface

S.W. Bradley, C. Rosse, J.F. BrinkleyDigital Anatomist Program, Dept. Biological Structure and

Integrated Academic Information Management Systems (IAIMS) ProgramUniversity of Washington, Seattle, WA 98195

ABSTRACTA World Wide Web Common Gateway Inter-

face package is described for accessing existing on-line interactive atlases of anatomy. The Web in-terface accesses the same 2-D and 3-D images ofhuman neuroanatomy, knee anatomy and thoracicviscera that are currently accessed by a custom in-teractive atlas in distance learning courses. Al-though the Web interface is too slow to replace theexisting atlas, it provides a parallel access path thathas much broader potential for development of adistributed distance learning network in anatomy.By maintaining both access methods to the sameinformation sources we continue to satisfy the fastinteractivity needs for our local courses, while atthe same time providing a migration path to theWeb as the capabilities of Web browsers evolve.

INTRODUCTIONThe recent explosion in use of the World WideWeb [1] has led to several applications for dis-tance learning in medicine, including radiol-ogy, blood morphology, and many others. TheUniversity of Washington HealthLinks Web site(http://www.hslib. washington. edu) has point-ers to some of these applications. However,for highly interactive applications current Webbrowsers are very slow because the connection tothe server must be re-established for each interac-tion, and because all processing must be done atthe server.

In a separate presentation we describe a non-Web based client-server framework for the Digi-tal Anatomist interactive atlas of anatomy [2]. Inthis system the client-server connection is main-tained throughout the session, and all informationrelated to a single image is downloaded in a singlechunk, after which the client performs the compu-tations necessary for interaction with the image.

This mechanism has proven to be a viable ap-proach to distance learning in our medical school,and is used extensively in several neuroanatomyand gross anatomy classes, both at the Universityof Washington and at remote sites on the Internet.The success of our online anatomy atlas has led

us to consider ways to make it more widely us-able as a building block for University of Wash-ington IAIMS (Integrated Academic InformationManagement Systems) [3] educational tools. How-ever, the custom framework is a one-of-a-kind sys-tem that runs only on the Macintosh computer.In addition, it is not directly compatible with thenewer Web based learning programs, nor is the in-formation easily distributed among many sites asit is on the Web. Thus, there is a tradeoff betweenthe increased interactivity of the custom approachversus the wider applicability of the Web-basedapproach, and we have begun a series of experi-ments to evaluate these tradeoffs.

In this paper, we describe one such experiment,a Web-based interface to the same images that areaccessed by the custom client. Although the Webclient is slower than the custom client, it is inher-ently portable across multiple platforms, and hasthe potential to link distributed sources of infor-mation. By providing both a Web-based and acustom interface to the same data we ensure thatthe atlas remains fast enough for use in our localcourses, while providing a pathway for much wideravailability as Web-based browsers evolve.

Web-Based Extensions to theDigital Anatomist Framework

The Digital Anatomist Interactive atlas is animage-based drill and practice program. Imagesdepicting 2-D or 3-D views of anatomic objects aredownloaded to a local client from a server. Oncethe image is available the student clicks the mouse

0195-4210/95/$5.00 C 1995 AMIA, Inc. 512

on various regions and the atlas displays the nameof the structure, along with other attributes suchas definition. The structure name is also linkedto available Quicktime movies. The interactiveatlas is one component of the Digital Anatomistdistributed framework [4], a portion of which isshown in figure 1. The components above the net-work line are clients, whereas the components be-low the line are servers and information resources.The original custom client is the Macintosh Inter-active Atlas; the original custom servers are thestructural database server, the structural knowl-edge base server, the log server and the dispatchserver.The interactive atlas client accesses images,

stored as files in the database, by means of thestructural database server, which acts somewhatlike an ftp server. The Mac client can also accessanatomic terminology and relationships stored inour knowledge base, via the structural knowledgeserver.Each database request from the client retrieves

two files: a PICT file showing the anatomic regionof interest, and an associatedframe file. The framefile contains the name of the PICT file, as wellas a list of polygonal regions denoting structuresof interest on the image. When the user clickson the image the client determines which polygonhas been indicated, and displays the name of theassociated structure. The name also acts as anindex for retrieving associated information fromthe knowledge base. A second kind of frame fileassociates commands with the polygonal regions;the primary command is "OPEN-FRAME", forretrieving a new frame file.The bottom-left side of figure 1 shows the

World Wide Web extensions to the existing Digi-tal Anatomist servers: a standard Web Server (i.e.:NCSA httpd 1.3), and the Digital Anatomist CGI(Common Gateway Interface) Package. Anatomyatlas images are retrieved from the database bymeans of the CGI package, which is in turn ac-cessed by the Web server. The images are dis-played on a standard Web browser such as Mosaicor Netscape. Unlike the custom framework, theWeb-based interface to the databases is structuredsuch that almost all of the processing is done in-side the server's CGI package, and only minimalamount of data is sent to the client at any onetime.

Figure 2 shows a typical page of the DigitalAnatomist Interactive Atlas on the World WideWeb. Once the image has been retrieved the stu-

I N .- I-IDiep LO..SI Senrzr I Senrer

Figure 1: Web extensions to the Digital Anatomistframework

dent clicks on a region of the image, causing thename of the structure, in this case descending tho-racic aorta, to appear at the top of the image. Ifthe "Show Outlines" button is selected the screenshows the same image with all structures outlined,(figure 3).

The Digital Anatomist CommonGateway Interface

The heart of the Web extension is the CGI pack-age, which consists of four main CGI programsand a server cache directory for saving convertedimages. The CGI programs access files in thedatabase and knowledge base directly, bypassingthe custom servers.

Figure 4 is an expansion of the CGI box in fig-ure 1, and shows how these programs work to-gether. All communication between these pro-grams and the client is facilitated through the Webserver. The arrows denote information flow fromprogram to program. The following sections de-scribe these programs in more detail.

The Controller: ImageformEvery atlas page on the client is actually an HTMLform [11, sent by the Web server. There areseveral specific items each form contains. Everyuser interface control, such as the "Show All Out-lines" checkbox, is one of these items. The actualanatomical image shown on the page is also a formitem. In addition, there may be one or more in-visible text fields for use by the server. Each formitem has a name and a value. For instance, the

513

I II --

kmW&Sr

Figure 2: A typical Atlas page on the World WideWeb.

Figure 3: A typical Atlas page with the structuraloutlines turned on.

wb

Figure 4: Architecture of the Digital AnatomistCommon Gateway Interface

checkbox named "outlines" may have a value of"on" or "off." One of the invisible fields, "ffpath",has it's value set to a string denoting the pathto the frame file containing the named structureinformation.The image acts as two form items, "image.x"

and "image.y", which record the value of the Xand Y coordinates of the mouse click, respectively.All forms must have an action that causes themto be sent to the server. Many forms have a "Sub-mit" button. The Digital Anatomist forms use theclick inside of the image as a "Submit" button.When the user clicks inside the image, the "im-age.x" and "image.y" items are assigned their ap-propriate values, and all of the form items, namesand values, are sent to the server for interpreta-tion.Imageform is the program responsible for read-

ing the form data from the Web client. It does notprocess the value of the form's user interface con-trols, but passes them on to the other programsthat do. Imageform uses the path stored in the"ffpath" invisible field to read the structural out-line coordinates and perform a point-in-polygoncomparison with the mouse-click coordinates.Once Imageform determines which region the

click was in, it looks at the name of the regionto determine whether it is a control button thatlinks to another frame with a different image, or ananatomical structure that needs to be identified. Ifit is an anatomical structure, imageform transferscontrol to PageMaster, passing it the values of allthe form items (one of which is the path to thecurrent frame file) and the name of the anatomicalstructure.

514

I;"; .. ....... ... .... .. .. .* .. :..!::. :P. nn ...1.,.---.

If the region is determined to be a control but-ton, imageform reads the path name of the newframe to be linked to. It then substitutes the newframe file's path name for the form item that wasspecifying the current frame file. Imageform thencalls PageMaster with no structure name parame-ter, and all of the form items.

If the mouse-click is not found to intersect any ofthe named regions, Imageform transfers to Page-Master, passing the structure name "unlabeledarea" and all of the current form items, withoutchanging frames.

Screen Design: PageMasterPageMaster is the program responsible for pro-cessing most of the form data, and designing thenext form page that the client will see. First,it names the client window after the frame file.Then, at the top of the page, it displays the nameof the last structure clicked, as passed from Image-form. From the directive in the frame file, Page-Master finds out the relative path to the image file.It then determines, from a form item, whether theoutlines should be shown. PageMaster then looksinto the server's cache of GIF files, to see if thenecessary image file exists in GIF format. If theGIF was found, PageMaster outputs a pointer di-rectly to that file, for the Web browser to display,probably from it's own local memory cache. Oth-erwise, PageMaster outputs an IMG SRC path toanother CGI program: Getpict. This URL directsthe Web client to retrieve the GIF image that get-pict redirects it to. Once the IMG SRC path hasbeen resolved PageMaster outputs the "Show AllOutlines" button, with it's previous state remem-bered, just below the image. The last thing Page-Master outputs is the invisible form item contain-ing the path of the frame file for this image, as itwas passed from Imageform.

Image File Handler: GetpictSince all of the image files are stored as MacintoshPICT files, and the standard image file format forthe World Wide Web is GIF, image file conver-sion must be done. To keep everything compatiblewith the original Macintosh version of the DigitalAnatomist, our current approach is to not touchthe original PICT files, but to convert them to GIFas they are needed at run time. This conversionprocess can take an unacceptable length of time,especially if the process is run on a slow computer.This is the reason for the server-side GIF cache.

This cache is a directory, with the hierarchy dupli-cated from the original PICT directory. When aPICT file is converted to GIF format, it is saved inthe cache directory, exactly where it would appearin the PICT directory. Having a separate cache di-rectory gives us the ability to monitor the cachesize, and remove the least-recently-used image fileif the cache gets too big.

This image conversion is the main function ofGetpict. As input, Getpict takes the relative pathto a PICT file and a flag denoting whether out-lines should be on or not. If no outlines are needed,the appropriate path prefix is prepended, then thePICT file is converted to GIF with Unix netpbmutilities, and saved in the cache directory. Get-pict then exits, outputting redirection commandsto the Web client to get the new GIF file. If out-lines are needed Getpict transfers control to Out-liner, passing the full paths to both the PICT fileand the frame file, and then echo's Outliner's out-put back to the Web client via PageMaster.

OutlinerFigure 3 shows an atlas page containing an imagethat is the result of Outliner. Outliner is the pro-gram that takes care of drawing the structural out-lines on top of the image file. It is passed the pathto a PICT file and the path to it's associated framefile. First, Outliner converts the PICT file to astandard format called ppm. Once this has beendone, Outliner can easily read information aboutthe image, like height, width, and number of col-ors. After this information has been read, Outlinerreads the coordinates from the frame file, storingthem in order in memory. It must also computethe coordinates of the pixels that compose the linesegment connecting two adjacent region boundarycoordinates. Then Outliner modifies the ppm fileby replacing all of the pixels that correspond to theregion boundaries, with a pixel of the color speci-fied by the frame file. This is all done in memory.After this process has been completed, the contentof memory is converted to GIF format, and savedin the cache directory under a name similar to theoriginal that denotes that it has outlines. Outlinerthen outputs commands to redirect the Web clientto retrieve the new GIF file.

RESULTS AND DISCUSSIONThe Digital Anatomist CGI Package provides

access to the same image data that is available tothe custom client, currently 423 image frames, of

515

which 290 are neuroanatomy and 133 are thoracicviscera [2]. As the anatomists update the databasethe changes are immediately visible on the Webvia the CGI package. Each image obtained via theWeb is associated with the same structural regionsas in the custom version, so all structures that areoutlined can be seen in a Web image.

Qualitative comparison between the Web basedatlas and the custom atlas suggests that, althoughthe Web atlas is slower to return a structure namethan the custom atlas, it is not unacceptably slow,especially when run on fast clients and servers.However, since all mouse clicks must be processedon the server, we expect that as network distanceincreases the Web based atlas will be unacceptablyslow when compared to the custom atlas. Thisexpectation, along with the lack of overlays delin-eating outlined structures, is the main reason wewill continue to support the custom atlas.

In addition to the slower speed and lack of over-lays there are other features of the custom atlasthat are not yet supported in the Web version, in-cluding quiz mode, animations, and access to theknowledge base. These features should be rela-tively easy to incorporate into the CGI packagegiven the availability of the forms interface andour Lisp-based knowledge server organization [4].We have already demonstrated a text entry Webinterface to the knowledge base. All that needsto be done now is to replace the manual text en-try with a structure name returned from Image-form. With the help of the anatomic extensionsto the UMLS (Unified Medical Language System)[5] currently under development, this will be verypowerful for looking up synonyms and root wordsof structure names that have been retrieved.The current experiment has shown us the fea-

sibility of constructing a Web based interface toan interactive atlas of anatomy. Although the in-terface is too slow to replace our current atlas, itprovides many exciting opportunities for expan-sion that could not be easily accomplished withthe custom atlas. Among these are automaticplatform independence, easy creation of user in-terface devices, dynamic generation of atlas con-tents by back-end knowledge bases and graphicsserver programs (which are already available inour framework and elsewhere[4]), and sharing ofcontent among multiple sites.The latter idea has great appeal as the basis

for a collaborative network for distance learningin structural biology, of the kind envisioned in ourIAIMS project [3]. For instance, one school may

have a premier neuroanatomy program while theother may have more strength in its musculoskele-tal program. With the use of this type of frame-work, any group of institutions or departmentsmay collaborate to create a distributed anatomydistance learning system. As some of the currentWeb limitations are resolved this approach to med-ical education will become a very useful and pow-erful learning tool.AcknowledgmentsThis work was funded by National Library ofMedicine Grants LM05620 and LM04925, and Hu-man Brain Project Grant DC/LM02310. The au-thors would like to acknowledge the support ofthe following members of the IAIMS EducationalGroup at the University of Washington: Jim Bar-rett, Cliff Solomon, John Bolles, Debbie Ketchell,and Sherrilynne Fuller. The Digital Anatomiston the World Wide Web can be found atthe URL: http://wwwl.biostr.washington.edu/-DigitalAnatomist.html.

References[1] R.J. Vetter, C. Spell, and Ward. C. Mosaic and

the World-Wide Web. Computer, 27(10):49-57, 1994.

[2] J.F. Brinkley, K.R. Eno, J.W. Sundsten, D.M.Conley, and C. Rosse. A distributed frameworkfor distance learning in anatomy: The DigitalAnatomist Interactive Atlas. 19th Symposiumon Computer Applications in Medical Care. InPress, 1995.

[3] S. Fuller. Creating the integrated informationinfrastructure for the 21st century at the Uni-versity of Washington Warren G. MagnusonHealth Sciences Center. In Proceedings, 17thAnnual Symposium on Computer Applicationsin Medical Care, pages 529-533, Washington,D.C., 1993.

[4] J.F. Brinkley, K. Eno, and J.W. Sund-sten. Knowledge-based client-server approachto structural information retrieval: the DigitalAnatomist Browser. Computer Methods andPrograms in Biomedicine, 40:131-145, 1993.

[5] C. Rosse, M. Ben Said, K.R. Eno, andJ.F. Brinkley. Enhancements of anatomi-cal information in UMLS knowledge sources.19th Symposium on Computer Applications inMedical Care. In Press, 1995.

516