Computing systems use object-oriented software for medical databases
Computing systems use object-oriented software for medical databases
By George Kotelly, Executive Editor,and Andrew Wilson, Editor at Large
Working together, the National Jewish Center for Immunology and Respiratory Medicine (NJC; Denver, CO) and Los Alamos National Laboratory (LANL; Los Alamos, NM) have designed a patient-record system that helps medical professionals nationwide combat the effects of tuberculosis and other lung diseases. Dubbed TeleMed, the system is based on a national radiographic repository located at LANL. Physicians can access the database from their homes or offices via a multimedia interface that allows them to view such data.
By matching a patient`s radiographic information with data in the repository, doctors can review the treatment history and determine the best course of action. Clinicians, diagnosticians, hospital residents, and physicians also can use the system for educational purposes. Furthermore, because TeleMed is based on a distributed computing architecture, medical professionals can view repository data simultaneously and use the data to collaborate and consult over a wide-area network.
Information integration
The design of TeleMed provides a one-to-many connectivity to diverse information sources, including a variety of databases based on relational, object-oriented, or other data models and files (see Fig. 1). The multidatabase system is integrated with an Object Request Broker (ORB) through an Object Database Adaptor (ODA), which provides a mechanism to integrate an object-oriented database system. The data stored in local data sources can be seen through a unified global schema expressed in an object-oriented data model and can be queried and manipulated using a C++ interface, an object-oriented dialect of SQL, and/or an advanced query/browser tool.
Most commercially available database-connectivity products such as EDA/SQL from Information Builders (New York, NY), Sybase OmniSQL Gateway, and IBM DataJoiner can bring together only relational data sources (such as Oracle, IBM DB2, Sybase SQL Servers, Informix, and Ingres) and prerelational sources (such as IMS, VSAM, and ISAM files) and cannot deal with data sources based on an object-oriented data model.
Because of this, LANL adopted UniSQL/M from UniSQL Inc. (Austin, TX), Total ObjectHub from Cincom Systems Inc. (Cincinnati, OH) and Pangaea from Telos Corp (Ashburn,VA). These packages use an object-oriented data model to build a unified database schema from local databases and can combine distributed heterogeneous data sources including object-oriented databases and relational databases and files. Such tools provide user interfaces of C++ and an object-oriented SQL query language, resolve the impedance mismatch between the application objects and relational data, and return results in their object representation so that methods written to reflect medical applications can be performed on these objects in the Common Object Request Broker Architecture (CORBA) distributed- object-computing architecture of TeleMed.
CORBA standard
The CORBA, an industry standard promoted by The Object Management Group (Framingham, MA), allows applications to communicate with one another no matter where they are located or who has designed them. The Object Request Broker is middleware that establishes the client-server relationships between objects. Says David Forslund, director of the advanced computer laboratory and laboratory fellow at LANL, "CORBA lets programmers choose the most appropriate operating system, execution environment, and programming language to use for each component of a system under construction."
CORBA is also platform-independent. Forslund knew that parts of the TeleMed system need to run on a variety of systems. CORBA achieves success in the TeleMed project via the object database. "We used the object model because you can map to objects," adds Forslund. Each object comes with its own data and methods that can be used to retrieve information over the Web. Objects allow users to retrieve as much or as little information as they want.
Since Forslund began working with CORBA, security features such as full encryption, authorization, and authentication have been added. These features are critical to the success of TeleMed. TeleMed designers use a software product called Orbix from Iona Technologies (Cambridge, MA). The Orbix architecture is Iona`s implementation of the CORBA standard.
Gaining momentum
TeleMed uses Sybase`s Gain Momentum as its user interface. Gain provides a facility called user canvas that allows an external application to render into a window under management by the Gain environment. The X window identification (ID) of the user canvas, which is available within Gain, is passed to an external process. The external process then establishes a connection to the X server and renders into the Gain-supplied X window. Events that occur over the user canvas are ignored by Gain so that the external process can handle them in the normal X window manner.
This mechanism is used in TeleMed to provide an integrated volume rendering from within the Gain user interface. After viewing a patient and a computed-tomography (CT) examination, a TeleMed user can then start the volume renderer on that series of CT slices. The Gain interface forks an executable that is linked with the VolPack library and tells it the X-window ID of the window that the volume is to be rendered into. Gain also passes the renderer information about the current patient and examination.
On startup, the renderer loads the requested CT slices from the database, resamples them into a volume, and establishes a socket connection back to Gain. This connection is used to pass information between the Gain interface and the renderer. The renderer sends the Gain interface information in the progress of the rendering that is displayed by Gain. Gain then passes the renderer the results of the user`s interaction with the view manipulators. Rendered images need to be communicated because the renderer is displaying them directly into the Gain user canvas (see Fig. 2).
While the software renderer is fast enough for casual use (for example, a physician shows a patient some renderings that depict the progress of the treatment), it is not fast enough to explore the volume. A radiologist, when presented with a new series of CT scans, must quickly examine the volume to find features of interest. To accomplish this task efficiently, the renderer must run at interactive rates (10 frames per second) and provide powerful user interfaces for volume exploration.
The high-performance renderer (T3D) achieves interactive rates through the use of hardware acceleration. The T3D runs on a Silicon Graphics Onyx computer with Reality Engine 2 (RE2) graphics hardware. It uses 3-D hardware texture mapping to accelerate volume rendering. The resampled volume is loaded directly into hardware texture memory. The 3-D texture is intersected by a number of parallel polygons, and the resultant images are mapped onto them. These polygons are then composited back-to-front, which results in a volumetric rendering.
The T3D can render 128 ¥ 128 ¥ 128 volumes into a 512 ¥ 512 window at interactive rates. Additionally, the RE2 supports hardware texture look-up tables, which enable the development of interfaces that dynamically modify the mapping of density to color and opacity to allow hardware accelerated rendering (see Fig. 3).
Unlike the software-only renderer, the T3D is not fully integrated into the Gain user environment. It connects to Gain via a socket and exchanges information with the interface, but its interface and display are separate from Gain. The reason is that Gain cannot supply a user canvas (X window ID) of the proper X visual. The T3D uses OpenGL, which requires a server with visuals capable of rendering OpenGL commands. While these visuals are obviously available on the machine, Gain is unaware of them internally and can not be started with the proper visual.
New methods for accessing imagery involve content-based retrieval, where searches are performed directly on image data as opposed to searches of associated textual information that has been "attached" to each database image by an interpreter or analyst. Content-based retrieval should greatly improve the value of massive image databases, especially for those applications in which data are collected in such staggering quantities that human experts can only examine a minute quantity of the entire data set. In these applications, content-based retrieval can provide tools for browsing the huge databases for specific images of interest.
A CANDID approach
Researchers at LANL are currently developing the Comparison Algorithm for Navigating Digital Image Databases (CANDID), which facilitates a query-by-example approach to image retrieval. A user poses queries such as "Show me all images in the database that contain textures similar to those in this example image."
The basis of the CANDID approach is that either an entire image or a specific region of interest with a global signature is described. Signatures are then matched with a distance measure to determine image similarity. Every image stored in the database is characterized by a global signature that can represent features such as local textures, shapes, and colors. When a user queries the database to retrieve images similar to a user-provided example, a global signature for that example image is computed, and this signature is compared to the signatures of all images in the database. Global signature comparisons allow the database images to be ranked with respect to their similarity to the query image.
In medical applications, CANDID has been used to compare pulmonary CT imagery in an effort to sort images by disease type and severity. Each image is described with a signature representing the fine-texture structure of the imagery itself. This technique enables image databases to be browsed to find various lung disorders.
The six images in Fig. 4 are from a single CT study of a patient with a lung disease that is characterized by the formation of empty cysts in the lung. When one of these images is used to query the database, it should be expected that the other images from this same study would be retrieved.
In experiments, all images from this same study were retrieved successfully with the exception of Image 2 (the image in the center of the upper row). Image 2 is the only image from this study that is an expiratory image (that is, all the air has been blown out of the lungs before the image was acquired). The other five images are inspiratory images. The resulting difference in image texture causes Image 2 to be categorized as different.
"A longer range goal is to perform advanced decision support on images," Forslund says.
Decision support capability allows a user to take an image of a CT scan, and submit it as a query to a database. Then a user could navigate the database and perform comparisons of medical images, seeing up to 700 3-D images on a screen simultaneously.
FIGURE 1. The structure of the TeleMed client shows its relationship to other TeleMed components. The user interface consists of several applications of which the primary application is the TeleMed database and patient navigator.
FIGURE 2. Because the TeleMed application uses an object-oriented approach, applications such as volume rendering can be performed directly within the user interface.
FIGURE 3. To support a hardware-accelerated rendering, the TeleMed system uses a Silicon Graphics Onyx computer with Reality Engine-2 graphics hardware to visualize volume rendering in the same user interface.
FIGURE 4. By using CANDID software, similar images can be recalled automatically. In this application, images from this same study are retrieved successfully with the exception of Image 2 (top, middle), where all the air has been blown out of the patient`s lungs before the image is acquired. The other five images are inspiratory images. This comparison causes Image 2 to be categorized as different.