Design Considerations for Wide Area Distribution of Digital X-ray Images

R Long
LE Berman
GR Thoma
PACS Design and Evaluation
Proc. SPIE v 1899, Medical Imaging, 1993
pp. 383-394.

ABSTRACT

The increasing backbone speeds of Wide Area Networks, along with the growing numbers of users of these networks, have created an opportunity for the development of remotely accessible and highly data-intensive digital libraries. The National Library of Medicine is building a prototype system for the storage of several thousand digital x-ray images, while providing remote access to these images across the Internet. This paper discusses the design factors analyzed for this system, and presents performance statistics collected. The design factors considered include: network protocol selection, endpoint tuning of protocol, image compression, and application data handling. Research toward application data handling includes plans to stage groups of images from an optical archive to memory for the efficient transmission of large numbers of images. To maximize image data transmission speed, experimental protocols are being studied as alternatives to TCP/IP. TCP overhead processing is being researched, and approaches to tuning TCP performance for transmission of large image files are being analyzed. To minimize the storage capacity required and to decrease transmission time, lossy compression techniques are being considered. Research is proceeding toward the selection of a compression technique and optimum compression ratio consistent with the image quality required to produce standardized readings.

1. OVERVIEW

A prototype system for Internet distribution of an archive of digital radiographs is being developed at the National Library of Medicine (NLM). Major goals of the system are to digitize and archive a collection of about 27,000 film radiographs, to make these radiographs available across the Internet to a small number of radiologists who will read the images in a standardized fashion, and to store the readings in a database at NLM. Both the readings and the associated images will eventually be made accessible over the Internet.

The project, named DXPNET for Digital Xray Prototype workstations linked via InterNET, is a collaboration among NLM, the National Institute of Arthritis and Musculoskeletal and Skin Diseases (NIAMS), and the National Center for Health Statistics (NCHS). The radiograph data originate with the National Health and Nutrition Examination Surveys (NHANES) which are conducted periodically by NCHS to assess the nation's health by field collections of biomedical and demographic data of interest to epidemiological researchers. The third in this series of surveys, NHANES III, is currently ongoing. Typical data for an NHANES subject includes body weight, blood pressure, serum cholesterol, age, sex, and, in some cases, film radiographs. To guarantee anonymity, specific identifiers for NHANES subjects are excised from the data. The radiographs to be archived include 5,100 cervical spine images and 11,900 lumbar spine images collected during NHANES II, and 5,000 hand/wrist images and 5,000 knee images to be collected during NHANES III.

Past teleradiology implementations have been traced [1] to as early as 1959 and have included the use of coaxial cable, telephone line, UHF radio, laser and microwave as carriers of the data. The microwave transmissions have included both line-of-sight and satellite propagation paths. Systems described in the current literature include a teleradiology system to serve the U.S. armed forces in Korea [2]; this system uses high speed communication lines which include T1 (1.544 Mbps) transmission capability; and a teleradiology system [3] planned for the Los Angeles metropolitan area which will provide T1 transmission rates by exploiting multiple 56 kbps digital voice channels. Future teleradiology experiments may include the use of NASA's Advanced Communications Technology Satellite (ACTS), to be deployed in 1993, which will provide T1 communications links across widely-separated locations. The same satellite is expected to provide 300 Mbps communications in 1994. A description of ACTS is given in [4]. The creation of the National Research and Education Network (NREN) [5], with its proposed gigabit/second transmission rates, will mark a major advance in teleradiology. An important step in the creation of NREN was achieved in Fall 1992 with the switchover of NSFNET backbone speeds from T1 to T3 transmission rates.

DXPNET system goals include not only developing techniques to use the present Internet to its maximum capability, but also addressing the issues and putting in place the designs and techniques which will allow for a natural transition to the expected higher-speed NREN Wide Area Network (WAN).

Among the important issues which confront the designer of a system for the distribution of digitial radiographs are "time-to-delivery", preservation of all essential medical information in the data (especially if lossy compression is used), visual quality of the display, ease of use, security, and cost. In the WAN environment, the "time-to-delivery" issue continues to play a prominent role, since even with recent increases in backbone Internet transmission speeds, the large size of uncompressed digital radiograph files translate to a transmission time of several minutes. By "time-to-delivery", we refer specifically to the time delay between a remote user making a request for an image or images from a central archive, and the time an image appears on his or her display. Contributing to time-to-delivery are:

• time to move the requested image file from the archive to memory or magnetic disk of the computer which hosts the archive;
• time to transfer the file across the Internet to the magnetic disk at the remote workstation of the radiologist; and
• time to transfer the file from the magnetic disk to the display memory at the remote workstation.

Figure 1.

Figure 1 provides a simple model of the required processes. Shown without a quantitative scale, the model is meant to be conceptual rather than a precise representation of the relationships between the three factors. The important points which Figure 1 illustrates are:

• transmission time is the dominant process (as expected) for a large region of file sizes;
• as file sizes decrease, there is a crossover point at which the time required to retrieve a file from the archive becomes dominant (the file sizes for which retrieval time dominates will be seen to be small compared to the size of uncompressed radiographs, but within the range of file sizes which might be achievable with lossy compression);
• the retrieval time curve is very flat; this will be seen to be due to the large amount of time required to retrieve an optical platter from "near-line" storage and to load in into a disk drive (this time is independent of file size);
• the display time is small, relative to the other factors.

In this paper we will present data based on direct measurements and on published device specifications to approximately quantify the parameters of the curves of Figure 1, for a specific point-to-point Internet transmission, as well as to describe approaches to reducing the time delays.

2. HOW DXPNET IS DISTINCT FROM PACS

In light of certain similarities with conventional Picture Archiving and Communications Systems (PACS), it is instructive to note the differences between DXPNET and PACS that determine design goals unique to DXPNET. Design goals for DXPNET are different from those of conventional PACS for several reasons:

1. An objective of DXPNET is to produce statistical data for epidemological studies, rather than to facilitate clinical interpretations for immediate patient care.
2. For a particular NHANES study, the collection size is predictable and fixed, rather than continually growing.
3. Only digital display technology will be used to view and read the images; the film will not be available as an option.
4. The radiologists will typically produce readings by sequentially reading each image in a predetermined group. Hence, the next image to be viewed is predictable, rather than being one selected at random from the archive.
5. Only x-ray images are included, not other modalities such as CT, MR, PET, or ultrasound images.

Some of these considerations suggest design goals different from those for PACS systems. For example, because of the predictablity of the next image to be viewed, this next image may be pre-fetched from the archive to reduce the radiologist's perceived wait time. Also, because the images are not for clinical use, the use of lossy compression may not be a barrier.

3.0 SYSTEM DESCRIPTION

The system functions for DXPNET may be listed as follows:

1. Digitization of the film images.
2. Quality control checks on the digitized images.
3. Archiving of the digitized images.
4. Request for and transmittal of image or readings data.
5. Displaying image and recording readings data.
6. Database capability to store, retrieve, and analyze the readings data.

From the point of view of the radiologist reading the images, the system is a high-performance workstation client coupled across the Internet to a remote server which provides image data from the archive. This logical client/server relationship is being implemented by creating a Unix-based server to handle requests for images from an optical disk jukebox archive, and a Unix software client operating on a remote workstation. The software communications link is a "sockets" interface operating with TCP/IP network protocols.

Digitization of the images is in progress, with over 6,000 films completed at this time; each of these digitized images has been viewed by trained technicians to check for quality. Archiving of the images to the optical disk jukebox is now beginning. Concurrently with the digitization and quality control work, client/server software for data transmittal has been developed, as well as man-machine interface software to display the images and accept readings, and software to store the readings in a database system with the necessary functionality. DXPNET will meet the needs of NCHS to preserve the NHANES radiographs, extract information from them, and provide remote access to the radiographs for researchers [6].

3.1 Digitization of the film images

The film radiographs are being scanned at UCLA with a Lumisys DIS-1000 laser scanner, which scans at 146 dpi and produces 12-bit gray level output. The data for each pixel is stored in a two-byte field. The dimensions of the digital images of the cervical spine and the hand/wrist radiographs are 1463 x 1755 pixels, and the dimensions of the lumbar spine and the knee radiograph images are 2048 x 2487 pixels. These dimensions correspond to file sizes of approximately 5 and 10 megabytes, respectively. The digital image files produced at UCLA are written to 5.25" WORM disks with a two-sided capacity of 600 MB and (currently) mailed to NCHS for quality control.

3.2 Quality control checks

Considering the need for a Quality Control (QC) technician to check for acceptability of contrast, removal of subject identification, and overall acceptability of the digital data, a QC workstation was developed using a 20 MHz 386 PC with a 1280x1024 8-bit grayscale monitor, a 300 MB hard disk, and an optical disk drive attached with a SCSI interface. The optical disk drive is used to read the WORM platters containing the digitized images. This selection of hardware was made to quickly assemble an affordable, but adequate, workstation for QC.

The QC process consists of (1) machine-processing a batch of images (typically 30-40) to reduce the image data to 1024x1024 8-bit images, and (2) viewing the reduced images on the workstation monitor to check for defects introduced in the scanning process (blurred image, misaligned image, etc.) and to ensure that all subject-identifying information has been removed from the image. (The reduction of the 12-bit data to 8 bits is strictly for compatibility with the QC display system; it is accomplished by dividing the 12-bit values by a constant (9 or 10) derived from observing the dynamic range of the 12-bit data.)

3.3 Archiving

An optical disk jukebox has been procured for the image archive and is currently being integrated into the system for storing the images in their full 12-bit form. Optical storage technology has been used in PACS systems since as early as 1986 (see, for example [7]); unlike PACS, where storage requirements may quickly grow to terabytes, the total required capacity for the DXPNET uncompressed image storage is approximately 224 gigabytes (GB). Considering the possiblity that 2-3:1 lossless compression, or even lossy compression might be used in the system, it was determined that a jukebox with capacity of 70-80 GB would be acceptable.

In addition to capacity, other archive issues considered in the jukebox acquisition included:

1. Multiple internal drives -- The acquired system has four, allowing the jukebox robotics to move platters to one or more drives while data is being simultanously read or written on another drive. This also permits redundancy in the event of drive failure. Automatic detection of a failed drive and switchover to a working drive is a requirement of the system.
2. A standalone optical disk drive -- To allow for the system data to be made available to users in the event of catastrophic jukebox failure, a single-disk standalone optical disk drive is part of the system.
3. Transportability of the media -- To allow for maximum transportability of the files on the media, it is required that each platter side contain its own complete Unix file system; this allows the platters to be read on any manufacturer's optical drive capable of reading standard Unix files, without any requirement that the drive be supported by vendor-specific optical disk management software. This gives the system the flexibility for a platter to be physically removed and transported to the desired destination, should that requirement arise.

The jukebox acquired contains 144 optical platters. Each platter is formatted at 512 bytes/sector and provides for 283 MB of storage per platter side, for a total jukebox capacity of 144 x 2 x 283 = approximately 81.5 GB of storage. Cost per platter was $130, implying a unit storage cost of about 23 cents/megabyte.

The optical archive system cost, including jukebox, standalone drive, 144 rewriteable platters, jukebox management software, and supplementary software for disk caching, was about $108,000, excluding the host computer.

Data within the jukebox may be considered to be "online" if the data is on a platter currently loaded into a drive, or "near-line" if it is not loaded into a drive, but resides on one of the platter shelves internal to the jukebox. Since there are 144 platters and only four drives, most of the platters will be near-line at any given time. Even though there are multiple internal drives, there is only one data path in and out of the jukebox; hence reading data from multiple drives is necessarily sequential.

Accessing data files from the jukebox involves several steps:

1. If the drive to be used already contains a platter, that platter must be "spun down" to zero velocity.
2. That platter must be unloaded from the drive.
3. That platter must be returned to its shelf.
4. The new platter must be retrieved from its shelf.
5. It must be loaded into a drive.
6. It must be "spun up" to the angular velocity required by the drive.
7. The read/write heads of the drive mechanism must be moved to the track containing the data.
8. The data must be read.

Nominal times for these operations, based on the vendor's technical specifications [8], are given in Table 1. Steps 2-5 are combined into the operation "change time".

Thus, to read a 5 MB file from the jukebox to memory may take approximately 25 seconds, when the file's platter is not in a drive, and a platter must be removed to make a drive available. Some of the jukebox operations involve only the robotics, while others involve only the disk drive mechanism. In principle, these operations may be done in parallel, but the particular implementation of the vendor's jukebox management software may restrict this potential parallelism. In the system discussed here, for example, I/O (reads/writes) may be done in parallel with robotics movement, or in parallel with spin up or spin down; this is currently the only parallelism available. Figure 2 shows how parallel operations may be used in a multiple drive system to gain some efficiency in data retrieval.

In Figure 2, the assumption is that two drives have been loaded with platters and are ready for reading at the beginning of the timeline. The intervals labelled ABCD (for drive 1) and abcd (for drive 2) correspond to operations which repeat periodically. The operations which occur in those intervals are as follows:

drive 1 -- use robotics and spin platter (18 seconds during AB); read 5 MB file (7.4 seconds during BC); wait for robotics (10.6 seconds during CD);

drive 2 -- read 5 MB file (7.4 seconds during ab); wait for robotics (10.6 seconds during bc); use robotics and spin platter (18 seconds during cd).

"Use robotics and spin platter" means to execute a sequence of commands to spin down and unload the old platter, store the old platter, retrieve the new platter, load, and spin up the new platter. Note that both drives experience periodic 10.6-second "dead time" intervals waiting for the robotics or spin control. The efficiency gained in using two drives as opposed to one is useful, but less than might be expected, because of the dead time. In the periodic drive use pattern, drive 1 carries out a use-robotics-read-dead-time sequence, while drive 2 carries out read-dead-time-use-robotics. The time spent for each drive is 36 seconds. In this 36 second interval, 10 MB are read by using the two drives; to read 10 MB using only one drive would take (2 x 25.4) 50.8 seconds.

Figure 2.

The above analysis is the best available characterization of the expected jukebox performance when a single file is to be retrieved, and disk change operations are required. Because of the high cost (18 seconds) of disk change/load/unload/spin up/spin down operations, the designer should seek to minimize these operations by (1) placing the required set of image files on as few platters as possible or, if that is not feasible, to (2) carry out the most time-consuming operations "off-line" to the user, so that the perceived retrieval time is reduced, even though the actual retrieval time is unchanged. In this second option, the images are "staged" to a large dynamic memory or magnetic disk cache prior to the time that the user expects delivery. Both of these options require the capability to predict in advance the set of images that the user will request. The initial phase of DXPNET may use this second option. If implemented, the radiologist will request a batch of images to be read on the following work day.

Overnight, the DXPNET system will move requested images to cache, then proceed to transmit them to the remote workstation of the radiologist.

3.4 Transmittal of image or readings data

The overriding issue in wide-area network transmission of digital radiographs is transmission time. Until recently, Internet backbone speeds have been limited by T1 rates (1.544 bps); at this time, even though the current backbone rate is T3 (45Mbps), most users are limited in transmission rate by lower speed links, ranging from T1 down to telephone line speeds. If it were possible to utilize the full network bandwidth, assuming T1 links to the backbone, the NHANES II images could be moved point to point in 26s and 52s for the 5 MB and 10 MB images, respectively. However, due to heavy load, host computer architecture differences, and packet retransmissions, we have realized a median transfer time of 318s and 636s for the cervical and lumbar images. This median transfer time corresponds to a transfer rate of about 16 kilobytes/second. Measured transfer rates achieveable are shown for one month in Figure 3, and example rates measured for one day are shown in Figure 4. These slow transmission rates have forced us to investigate alternative methods for transmitting the images.

Figure 3.

Figure 4.

3.4.1 Alternative Network Transport Protocols

The most common protocol for reliable data transfer on the Internet is TCP/IP. One avenue for possible faster data transmission is the use of an alternative protocol designed for transfer of large blocks of data. The NETBLT protocol represents an attempt in this direction. NETBLT attempts to avoid unnecessary packet retransmissions and waits for acknowledgements by a redesign of the flow control and error recovery processes used by TCP. Like TCP, NETBLT is a reliable transport protocol. Efficiencies of greater than 90 per cent of the available WAN bandwidth have been reported in NETBLT experiments [9]. However, the designer desiring to implement an unconventional protocol, such as NETBLT, faces the likelihood of heavy programming demands at the operating system and network level. While this remains an area of interest, DXPNET is proceeding with the conventional TCP/IP protocol.

3.4.2 Batch Transmission

Another option to combat the slow transfer rates would be to provide a mechanism for batch transfers of the images, as discussed in Section 3.3. Batch transmission would allow the user to start a downloading process and than return to process these images once they have been received. However, this presents several operational problems. For example, limited disk space on the receiving end would minimize the usefulness of batch downloading. Secondly, it would be advantageous to have the transfers take place during low Internet load periods. This typically occurs during the late evening and very early morning, but can be unpredictable at times.

3.4.3 Image Compression

As an alternative, image compression can be used to reduce the amount of data transmitted across the Internet. If lossless data compression is used, than the images are fully recoverable. Lossless algorithms typically yield compression ratios of 2:1; such a low rate of compression would not make a significant impact on the system since there would still be such a long wait for image transfers. Lossy compression techniques providing variable compression ratios could be incoporated into the system, but they also have limitations, since they are not reversible. That is, after decompression, the resulting image is a reproduction of the original, not an exact duplicate. The loss incurred could result in artifacts being introduced, blurring of important features, or even removal of features. Carefully designed studies must occur before lossy technique can be employed.

In a preliminary study to determine if lossy compression is a viable alternative, we showed that the least significant five bits do not appear to carry any information relevant to cervical vertebra. We applied these results to the Joint Photographic Exploitation Group (JPEG) standard and found that it might be possible to use lossy data compression at rates of 30-40:1 [10]. At rates this high, the transfer times will decrease to 10-20s of image transfer times. This results in a total delivery time (assuming 25.4 seconds for data retrieval) of 35.4 or 45.4 seconds. However, more analysis on a statistically valid data set must be done before we can draw any conclusions.

3.4.4 Modifications to Current Transfer Mechanisms

Finally, modifications to the transfer mechanisms can also help improve system performance. In order to preserve maximum software control, our application uses a custom-built UNIX BSD sockets interface to the Internet, rather than an "off-the-shelf" TCP implemntation such as the File Transfer Protocol (FTP) program. Both FTP and our sockets interface use the TCP/IP network protocol. Other researchers have studied overhead in TCP processing [11], and improvements in TCP implementation on a particular system may be possible. This mechanism allows a process to make a reliable connection with a remote user with TCP. The client, at the remote location, communicates with the server, at NLM, over particular ports on each machine. Standard read and write operations can be used and the lower levels of the network break up the data stream and send it out to the appropriate location. The performance can be improved by altering system parameters or by multiplexing the transfer through multiple time-sliced processes. These alternatives may result in speedups sufficient to meet a user's real-time requirements.

All of these options have a signficant impact on the design of the Standardized Readings Workstations (SRW) being designed for use by the radiologist. Combinations of these alternatives will lead to much higher throughput, but must be used prudently. Lossy compression poses the greatest risk, but leads to the greatest potential gain in performance. On the other end of the spectrum, it might be possible to use lossless compression in coordination with improvements to the sockets interface to provide real-time throughput. The second alternative is advantageous because it eliminates any possibility of data error. However, it might not be an achievable alternative.

3.5 Man-machine interface to display image and record readings data

The SRW has a man-machine interface (MMI) or graphical user interface (GUI), with the following functionality:

1. allow the user to download images from the NLM archive
2. apply some basic image processing algorithms to the images
3. record the user's standardized reading
4. save the user's standardized readings in the NLM archive

The SRW currently runs on a SUN 4/260 under SUN OS 4.0.3. The GUI portion has been developed with the Xview development package under Openwindows 3.0. Attached to the SUN 4/260 is a high resolution Megascan monitor, used for viewing the NHANES II images. This monitor has a resolution of 2048x2560 pixels and can display 256 gray levels. The standardized readings are maintained in a database at NLM. This database has been implemented with Postgres, a relational database developed by the University of California, Berkeley. The database is responsible for maintaining a list of valid users, parcelling out images to users, and updating the database with completed standardized readings. The server software on the NLM side is actually the Postgres database manager talking to clients through a UNIX socket port. It responds to all queries composed by the user at the SRW GUI.

Upon starting up the SRW the user is presented with a pop-up login window. The user types in an account name and password that is registered with the NLM database. After account verification is performed at the NLM, the SRW goes into a full operating mode. The user can read images that are available in local storage and/or download images in the background. With simple point-and-click options, the user selects an image to view and waits for the software to display it on the Megascan monitor. Next the user has several utilities available for enhancing or analyzing the image. For example, histogram equalization and manual dynamic thresholding can be used to increase the contrast or remove noise. After the image has been evaluated, the user steps through a pre-defined set of fields, typing in information about the image. There is also a field for general comments. Once this is completed the response is forwarded to NLM for inclusion in an online database.

The expected time to display one of the 5 MB image files on the Megascan monitor is about 4 seconds, assuming that the file is on local magnetic disk. This display time can be improved if the user is willing to invest in dedicated disk array technology. (Such a device, described in [12], could display the 5 MB image file in 1.3 seconds.)

3.6 Database capability to store, retrieve, and analyze the image data

The database requirements for the initial phase of the radiograph project are modest: the radiologist must be able to store his readings, and to retrieve his readings for review or modification. To preserve independence of readings, one radiologist may not access the readings of another radiologist. The database should support queries embedded in software to allow flexibility in development of the user interface. The system should provide security mechanisms and should either directly support a remote client/server interface, or be amenable to operation in such an environment.

Several data base products were examined. All are of the relational model and all except one, Postgres, are commercial products. Table 2 shows a comparison of the characteristics of three of these products. Two of the systems shown in Table 2 are major commercial products (Products A and B) and have the corresponding level of reliability and support. To the best of our knowledge, Postgres reliability has not undergone long-term testing on largescale applications; Postgres originates in the academic world, and is supported by a small academic group; an Internet conference exists for exchange of information between users. All three products support embedded query language, that is, the capability to make queries to the database from within custom-written software. Online archiving is the process of database archiving while the database is in use; the commercial products can do this, while Postgres cannot. Similarly, products A and B offer aids in disaster recovery, while Postgres does not ("mirroring" refers to writing a disk copy of the database updates currently in dynamic memory; "roll-forward" and "roll-back" are the capabilities to step back and forth betweeen database updates to arrive at the desired recovery point). All three products support a direct interface between a database server and a remote clien, all support stored procedures or rules (the capability for the database to invoke custom-written software functions), and all support "triggers" (the capability to trap system events and take appropriate action). None of them have any significant support for optical storage. We judged Postgres the easiest to learn; the commericial products are relatively expensive, while Postgres is public domain.

We performed direct experimentation with the Postgres system by building a small database of standardized readings data and accessing this database with the client/server interface provided by Postgres. This experimental system has an integrated GUI which lets a client display a radiograph on a Sun workstation display, allows the entry of a reading of that radiograph, and allows the storage of that reading in a remote database; similarly, previous readings may be retrieved from the remote database. In all the trials, the Postgres system has performed well. Although we have concerns over the lack of Postgres software support relative to the commercial products, our experience gives us confidence of its usefulness on our application.

3.7 System Overview

The complete system overview in given in Figure 5, which shows an SRW client communicating with the Electronic X-ray Archive (EXA) server at NLM. The SRW system consists of an SRW Client module and a Communications Module; the EXA system consists of a Login Server module, a Postgres Server module, and a Communications Module. The normal event sequence is as follows: when a radiologist requests to log in to the DXPNET system, the radiologist login i.d. and password is passed from the SRW Client to the Login Server; the Login Server calls Postgres, which checks the database to see if the i.d. and password correspond to an authorized DXPNET user; if so, Postgres returns a database account number to the Login Server, which in turn returns the database account number to the SRW client. (This account number is a Postgres mechanism and is required to access Postgres.) With this account number, the SRW Client may directly access the Postgres server. Thus, when the radiologist queries the database, the SRW Client will send the query, along with the database account number, to the Postgres Server. The Postgres Server will recognize that a query is being made from a valid Postgres user and will respond with the results of the query. The query responses are made using the client/server interface internal to Postgres. If a request is made for image data, the Postgres Server responds by invoking a custom-written program to transfer the data over the sockets interface described earlier. This design takes advantage of the full query capabilities of Postgres, while maintaining control over the most critical part of the client/server interface in custom-written code.

Figure 5.

4. SUMMARY AND CONCLUSION

Using the transmission data collected, and assuming linearity of transmission rates over a range of file sizes from 64K to 5 MB, a performance curve for point-to-point Internet transmission can be extrapolated. This curve is shown in Figure 6, along with a curve for data retrieval time from the jukebox. Because of the large span of the horizontal and vertical scales, a log-log graph is given. The third element in time-to-delivery, display time, is not graphed, but for DXPNET may be assumed to be approximately four seconds. The transmission rates shown are actually based on statistical data for transmissions between NLM and the University of Arizona. The rates obtained at any particular time on this link, or for other point-to-point links, may vary. The data retrieval times likewise have a statistical component which depends on whether an optical disk change is necessary to retrieve the data, and how far the required platter is located from the drive.

Figure 6.

The graph illustrates that for image files of size in the 200-300 KB range, the dominant factor in time-to-delivery may be time to retrieve the image from the archive, rather than the transmission time. For DXPNET, this means that lossy 20:1 compression might cause the retrieval time to be the dominant factor.

Time-to-delivery remains a prime issue for WAN teleradiology. For teleradiology over the Internet, time-to-delivery may be minimized by minimizing retrieval time, transmission time, and display time. Possibilities for reducing retrieval time include exploiting multiple drives in an optical disk jukebox and carrying out time-consuming data retrieval "off-line" to the user (which minimizes perceived, but not actual, retrieval time). Transmission time may potentially be reduced by using new transport protocols, such as NETBLT, in place of TCP; however, the results to date are sketchy and the implementation tools are scarce. The designer may attempt to reduce transmission time while staying in the TCP/IP environment by batch transmission in user "off-line" hours (to reduce perceived, but not actual, transmission time), by using lossy compression, if the project end-goals allow it, or by attempting improvements on the system implementation or application approach to the use of TCP. The easiest route to reducing actual transmission time at present appears to be use of lossy compression, if such use is consistent with project goals. If this is inconsistent with project goals, the designer may be faced with the need to reduce perceived, rather than actual, transmission time, by doing the transmissions in batch mode "off-line" to the user. Finally, although display time is a minor factor in time-to-delivery, that time can also be decreased if the designer is willing to invest in dedicated hardware, such as parallel transfer disk technology.

5. ACKNOWLEDGEMENTS

The authors would like to thank Leif Neve for his support and contributions to this work.

6. REFERENCES

1. Lewis S. Carey. "Teleradiology: Part of a Comprehensive Telehealth System," Radiologic Clinics of North America, pp. 357-362, Vol. 23, No. 2, June 1985.

2. Seong K. Mun. "Command-Wide Teleradiology for U.S. Armed Forces in Korea," PACS Design and Evaluation, Proc. SPIE v. 1654, Medical Imaging VI, pp. 81-88, 1992.

3. Brent K. Stewart, Samuel J. Dwyer III, H. K. Huang, and H. Kangarloo. "Design of a High-Speed, High-Resolution Teleradiology System," PACS Design and Evaluation, Proc. SPIE v. 1654, Medical Imaging VI, pp. 66-80, 1992.

4. S. Joseph Campanella. "An Onboard Processing Beam Hopping Satellite," Comsat Laboratories, Clarksburg, Md.

5. Vinton G. Cerf. "NREN," Internet RFC 1167, July 1990.

6. George R. Thoma, L. Rodney Long, and Lewis E. Berman. "Access to a Digital Xray Archive over Internet," presented at OE/FIBERS '92, Boston, Massachusetts, September 8-11 1992.

7. Nicholas J. Mankovich, Ricky K. Taira, Paul S. Cho, and H.K.Huang. "Operational Radiolgic Image Archive on Digital Optical Disks," Radiology, pp. 139-142, April 1988.

8. "Optical Disk Library Systems," Hewlett-Packard technical publication no. 5091-1757E, May 1991.

9. David D. Clark, Mark L. Lambert, and Lixia Zhang. "NETBLT: A High Throughput Transport Protocol,"Frontiers in Computer Communications Technology, SIGCOMM '87 Workshop, pp. 353-359.

10. L. E. Berman, R. Long, S. R. Pillemer, "Effects of Quantization Table Manipulation on JPEG Compression of Cervical Radiographs," submitted to Society for Information Display International Symposium,Seminar, and Exhibition, May 1993.

11. David D. Clark, Van Jacobson, John Romkey, and Howard Salwen. "An Analysis of TCP Processing Overhead," IEEE Communications Magazine, pp. 23-29, June 1989.

12. Albert W.K. Wong, Mansur Loloyan, S.L. Lou, and H.K. Huang. "On-line Performance Characteristics of a Radiology PACS," PACS Design and Evaluation, Proc. SPIE v. 1654, Medical Imaging VI, pp. 14-23, 1992.

CEB Home | CEB Projects | Related Work | Publications | Repositories | NHANES | Site Index

U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894
National Institutes of Health | U.S. Dept. of Health and Human Services
Copyright information | Privacy policy | NLM Accessibility
USA.gov | Need a plug-in? | RSS

URL: http://archive.nlm.nih.gov/pubs/design-consid/design-consid.php
Last updated February 13, 2002

Send questions or comments about this site to