| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
infoRAD |
1 From the Department of Radiology (S.K.L., S.K.H.) and the Computer and Communication Center (C.H.P., C.H.W., W.Z.J.), Taichung Veterans General Hospital, 160 (section 3) Taichung Kang Rd, Taichung 40705, Taiwan; and the Department of Diagnostic Radiology, National Defense Medical Center, Taipei, Taiwan (S.K.L.). Presented as an infoRAD exhibit at the 1997 RSNA scientific assembly. Received May 29, 1998; revision requested September 10 and received October 23; accepted December 18. Supported by grant VGHTH 86-030-3 in memory of Chi-shuen Tsou, MD, from the Medical Research Advancement Foundation to the joint research program of Taichung Veterans General Hospital and National Tsing-Hua University. Address reprint requests to S.K.L.
 |
Abstract |
|---|
 Top Abstract INTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
Index Terms: Computers • Images, transmission • Teleradiology
|
INTRODUCTION |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
In recent years, the Internet has become a popular and convenient means of exchanging information. Images can be easily managed with global networking and software (3). Many researchers have designed successful teaching file systems on the Internet (4,5). A teleradiology system has been developed on the World Wide Web to allow remote consultation with expert radiologists (6). Our hospital developed a PACS in 1993 (7) and has extended it to a hospital-wide PACS (8). To facilitate better service outside the hospital, we have developed a practical, useful, and economical teleradiology conferencing system that uses Java (9) on the platform-independent and hospital-independent Internet.
|
METHODS |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
Use of Java dramatically reduces the cost of software distribution and maintenance. A Java program can be executed on any platform by using a local program or a program downloaded from an Internet server. This feature allows us to maintain an up-to-date version of our application system in the server instead of each client storing and updating the application system independently. In addition, the multimedia, animation, and interaction capabilities of Java facilitate display and processing of medical images for clients. Therefore, we chose to use Java to design our teleradiology system.
System Design
There are several important aspects of designing a teleradiology system. In the most general sense, teleradiology refers to the transmission of radiologic images from one place to another (1). Teleradiology may be supported by video conferencing (telemedicine) so that the medical personnel at each end of the link can converse with each other and make annotations on the images being reviewed. Thus, a sophisticated teleradiology system should include the following features: (a) synchronous consultation from both ends, (b) connection with the PACS for accessing images, (c) basic functions for image processing, and (d) teleconferencing for interactive conversation (10,11).
We designed our system to be an alternative to the teleradiology system within our hospital. In particular, we designed the system to be useful for urgent radiologic reporting and consulting for an acute condition when a physician is at home and for assisting a remote affiliated hospital with an immediate diagnosis. The system provides remote consultation in such a way that both physicians can review the same images and discuss them in a dialog window or by telephone. The screens displayed at each end coincide with each other. If the image at one end is changed, whether by user manipulation or by performing some processing functions, the image at the other end is changed simultaneously. So that each user can see what the other is referring to, a synchronized indicator was designed to concurrently point to the image area of interest at both ends (Fig 1). In addition, a user may add annotations, such as text, line segments, rectangles, or polygons, to image areas of interest; these annotations are simultaneously displayed on both monitors (Fig 1). Finally, we designed a dialog window for on-line conversation as an alternative to the telephone (Fig 2).
|
|
|
The database server subsystem provides the location of a required image to the client. Whenever the server is activated, it passively waits for a request from the client. When the database handler receives a request, it queries the patient database for related demographic data and the image location and replies to the client. The client then requests an image transfer from the related image server by entering the image location.
The client subsystem is composed of a viewer program, a local image file, and a stream listener. The viewer program requests the database server subsystem and the image server subsystem to retrieve images and provides a graphical user interface (GUI) for processing the images. The local image file is used to store the images. Because the two users communicate via the Internet or an intranet, the stream listener provides on-line two-way communication with the other client for synchronization. When the user at one end changes the screen in any way, the stream listener simultaneously changes the other screen in the same way to maintain a consistent view at both ends.
System Operation
A user operates the system by means of a client subsystem. When a client subsystem is activated, its stream listener is triggered at the same time to wait for a connection from other remote clients. Alternatively, the client subsystem may actively connect to a remote client if the user specifies an Internet protocol address (Fig 1). After the connection is completed, a synchronous channel is created between the two clients so that they can send messages to each other. Any user may request a patient's information from the database server, retrieve related images from the image server, and select one of the images for manipulation. The other client is instantaneously notified about these operations by commands passed through the synchronous channel. The remote client immediately executes the received commands to perform the same operations.
The system is used not only for image consultation but also for image reporting. We designed the system to be an alternative to a remote PACS. If a radiologist wants to perform image reporting at home, the process may be initiated without specifying an Internet protocol address because the radiologist does not have to communicate with any other user. The system allows a user to retrieve a single image or a file of images that may belong to many patients. These images are returned from the image server by means of file transfer protocol and stored in the local image file. In this way, a radiologist may prefetch all required images before performing image reporting.
System Implementation
Two connected client subsystems become symmetric. The symmetry is achieved by means of identical implementation of all clients. There is no master-slave relationship between connected clients. Any client may actively connect to or passively be connected by another client. Every operation of one client will instantaneously be replayed by the other by passing the same command through the communication channel between them. The symmetric property of our client design simplifies user operations and the complexity of implementations.
To maintain identical screen contents at both ends, the system is implemented to provide a synchronized display during consultation. There are two synchronization methods for screen display: the screen-sharing strategy and the command-passing strategy. The former, which is used by Intel ProShare and is commonly applied in teleconferencing, transmits the whole updated screen to the other side even though there are only a few changes. Because any change at one end causes a "screen dump" at the other end, network transmission is heavy. For example, if we want to enhance the displayed image by adjusting its window level, the screen-sharing strategy will send almost a whole screen of data to the other side. As a result, roughly a million bytes of data will be sent on the network. However, in our system, we use the command-passing method, which transmits only a command code and the parameters of the operation to the synchronized client. Only a few bytes are needed to represent the command code and parameters. After the remote computer receives the command code, it executes the command and produces the same screen display immediately. The command-passing strategy tremendously reduces the volume of transmitted messages and the response time for synchronizing displays. All operations, including image manipulation, annotation, and dialog, are implemented with this strategy in our system.
However, synchronized display has some drawbacks, such as operation conflict and insignificant moving of the cursor. Operation conflict occurs when two users activate some operations simultaneously; the result is an inconsistent screen display. We solve this conflict by means of a token-passing strategy. With this strategy, the user who needs to activate a command presses an icon first to get the control token to execute the operation.
Moving a mouse cursor results in a string of insignificant events. Such movement increases the volume of message transmission during synchronized display and dramatically slows the performance of the system. This problem can be solved by introducing a synchronized indicator (Fig 1). Because users move the indicator to the area of interest by using the command-passing strategy, we thus avoid transmission of all moving events of the mouse cursor.
Our system was implemented with Java Development Kit (JDK) 1.1.4 and can be executed with Java Run-Time Environment (JRE) 1.1.4 or later versions. The Java applets for Web browsers such as Internet Explorer or Netscape Navigator were not used in our system because our program has to access local files and download images into local disks and doing so would violate the security constraints of Java applets. The computers of our users are all Pentium based with Windows 95, platforms that are popular in our country.
|
RESULTS |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
In mid-1997, our first experimental system was established for radiologists, who were consulted at home on emergency cases. Using a telephone modem, a physician could access the images from the PACS at our hospital and communicate with the consulting clinicians. Although this teleradiology system was convenient, the bandwidth of the transmission line became a bottleneck because the storage requirements of medical images are very large. For example, it took approximately 18 minutes to send a compressed 4-Mbyte radiograph via the telephone line. To reduce the transmission time, a cable modem technique was introduced; the transmission speed increased to more than 128 kbits/sec, and the transmission rate tripled.
In mid-1998, we installed the system at an affiliated rural veterans hospital 70 km from our hospital. This hospital is a rest-home hospital without a full-time radiologist. It already had a mini-PACS with DICOM-compliant CT capability and a plain radiography digitizer. When a radiology reporting service or teleconsultation is requested, our radiologists can communicate with the remote clinicians by using this system. The affiliated hospital is connected with a 64-kbit leased line; therefore, it takes approximately 10 minutes to retrieve a compressed 4-Mbyte radiograph.
The response times of the various image manipulation functions of a local computer are within 1 second. However, it takes a few seconds for the remote computer to redo the same operation by means of the command-passing method.
|
DISCUSSION |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
For on-line consultation, the necessary equipment for the system is the network interface or modem for making an on-line connection. However, a microphone and a sound card may be used for audio conversation in place of telephone dialog. Because not all computers are equipped with an audio device, the dialog window is used as an alternative to let the remote user see what the local user is typing or drawing (Fig 2). Furthermore, there should be a video camera for teleconferencing. The video conversation must be in a unified, nonproprietary, platform-neutral format. At present, there is no natural way to implement a video conversation environment in Java. However, a new feature of the Java platform, the Java Media Framework (JMF), will be integrated into our system in the near future. This feature will be a great support to the media capture and conferencing functions of the system.
The greatest advantage of our system is that it provides a platform-independent telemedicine service via the Internet. A consultation can be accomplished easily and cost-effectively. However, the drawback of Internet bandwidth still exists. To obtain images faster, we are looking for a faster Internet networking technique. An alternative solution to this problem is to use the prefetch function of the system to get images in advance so that the consultation time itself can be reduced.
|
CONCLUSIONS |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
|
Footnotes |
|---|
|
References |
|---|
|
TopAbstractINTRODUCTIONMETHODSRESULTSDISCUSSIONCONCLUSIONSReferences |
|---|
This article has been cited by other articles:
|
|
 |
|
  B. F. Tomandl, P. Hastreiter, C. Rezk-Salama, K. Engel, T. Ertl, W. J. Huk, R. Naraghi, O. Ganslandt, C. Nimsky, and K. E. W. Eberhardt Local and Remote Visualization Techniques for Interactive Direct Volume Rendering in Neuroradiology RadioGraphics, November 1, 2001; 21(6): 1561 - 1572. [Abstract] [Full Text] [PDF]
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
| RADIOGRAPHICS | RADIOLOGY | RSNA JOURNALS ONLINE |
