|Home | About | Journals | Submit | Contact Us | Français|
A 10 Mbits/second fiber-optic network for the transmission of chest x-ray images has been designed and implemented at our Hospital. Images are acquired with a high-resolution laser scanner. The viewing consoles display images at spatial resolutions of either 512 square or 1024 square. User interfaces have been designed to simplify the digitization and display processes. The applications level networking software and all the image processing software has been developed in-house. The system is now serving a 11-bed critical care facility on a day-to-day basis. This paper will focus on the software design issues. The software will be presented from a systems perspective. The importance of the user in the design process will be stressed and exemplified. The role of intelligent, rule-based software will be demonstrated. Selected clinical results will be discussed.
MEDICAL IMAGE MANAGEMENT SYSTEMS (MIMS) are attempting to replace decades of effort invested in conventional equipment and film-handling schemes. There is an un-coordinated effort by the industry to substitute conventional equipment with ‘MIMS-ready’ replacements. This has resulted in a plethora of MIMS components based around CPUs with widely varying power and complexity. The ACR/NEMA1 standard is a commendable, yet preliminary, step towards standardization.
When one steps back and views the effort in the MIMS industry it is unnerving to notice that the role of the user is taking a secondary place to the role played by new and fancy hardware. The design of software is intimately linked with user-related issues. We must realize that a MIMS display console is competing against a film multiviewer that has been pre-loaded by a film librarian with 200 films. The physician in a critical care area is unimpressed by the fact that the digitized images he is seeing came from a laser-disk via optical fiber that is a couple of thousand feet long. Clearly, the speed of retrieval (either raw speed or intelligent schemes to effect transfers) is a key issue to acceptance.
We believe that while efforts in hardware design will improve the displays and their capabilities, there is a definite need for intelligent software to aid user-interface issues. This paper will address the software design issues of a working, prototype MIMS at our institution. We present a high-level view of our software design and address some of the more interesting issues in more detail. The reactions of physicians to our design will be discussed.
A description of the hardware follows in Table 1.
All the stations are networked together with a fiber-optic token-passing ring from Proteon Corporation (Natick, MA). The hardware signals at 10 Mbits/second.
The acquisition station is a dual processor system with an LSI-11/23 dedicated for image capture. The laser scanner is a prototype from DuPont Laboratories (Wilmington, DE) and is presently operating at a 100 micron resolution. The digitized image is shipped to a second LSI-11/23 for transmission to the archive (Figure 1). Each chest x-ray image is scanned at a resolution of 1684 × 2048 × 12 bits. However, the stored image is sub-sampled to yield a pixel matrix of 1024 × 1024 × 12. Each image occupies 2 MBytes.
The storage on the archive consists of magnetic disk and optical platters. There is a Gigabyte of Winchester for the most recent images and a 2 GByte removable platter system from Perceptics Corporation (Knoxville, TN) for the archival of the older images.
The physician station is centered around a Gould-DeAnza (San Jose, CA) IP-5500. Two image buffers, 512 × 512 × 8 in size, constitute the display memories.
The radiologist station is centered around a Ramtek (Santa Clara, CA) image processor which has three image buffers 1024 × 1024 pixels in size. One buffer is 10 bits deep and the other two are 8 bits deep.
The prototype MIMS described above is being used to clinically evaluate the effectiveness of image transmission to the Medical Intensive Care Unit (MICU). We now discuss the experiment.
The Medical Intensive Care Unit (MICU) is an 11-bed critical care facility located in the patient care of the Hospital, removed from the Radiology Department. Patients are admitted into the MICU because of critical illness requiring close monitoring or intensive support. The average length of stay is six days. As a general practice, each MICU patient receives a daily chest x-ray examination and findings are communicated to the MICU clinicians after the radiologist has studied the x-ray image.
The core experiment consists of comparing blocks of time (eight weeks each) during which images are viewed either on film (‘film period’) or at the digital display console (‘digital period’). Four basic data sets are being collected:
The demographic and diagnostic information data is required to prove our hypothesis that the film and digital periods are equivalent. The administrative data is being collected to perform a cost-effectiveness analysis. The data on the time till an action is taken is the primary data set used in the comparison between the film and digital systems.
The flow of events from the time an examination is ordered to the time an action is taken is indicated in Figure 2. Key information generated during this cycle is being recorded using a set of specially designed questionnaires. The trigger points for the five different questionnaires are indicated in Figure 2. Note the alternate paths during the digital periods.
Figure 2 indicates the complexity of the design of a Medical Image Management System if it must effectively perform all the actions of a film-based system. We have elected to build a prototype that will stress all aspects of MIMS and thereby provide us with feedback to refine our design.
Referring again to Figure 2, we note the existence of the two data intensive communication paths: (1) The acquisition and transmission path, and, (2) The retrieval and display path. These two paths, in fact, depict all the functions required in a MIMS:
We believe that the two most crucial areas of stress in a MIMS are:
(a) transmission/retreival and, (b) the design of an effective image display console. Our definition of the image display console includes the design of the user-interface which is very often neglected. These issues have been dealt with elsewhere.5
We discuss the design issues with an example comprising the archive and physician station interactions. We assume that the image has been captured and transmitted to the archive in some fashion and this part of the operation will not be considered here. Figure 3 (on the following page) is a simplistic view of the programs that execute on stations. We briefly describe their functions in Table 2
Note the existence of three classes of programs:
A simplified description of a typical session would be:
In the more interesting situation where a multiplicity of images are requested we see the evolution of two symbiotic program loops:
The first loop is user-intensive and from the computer’s viewpoint has a large wait or ‘Z’ time. Conversely (and unfortunately !), the second loop is computer-intensive and from the user’s view-point has a large ‘z’ time. It is conceivable that while the physician is manipulating the first image, a scheduler could issue background requests to the archive and stock up the sub_archive.
Clearly, this is an ideal scenario for multi-tasking operations provided the following is true:
There are a number of issues that directly impact the high level design of a MIMS. We now discuss a few of these.
The images that are displayed in the MICU are sorted by two parameters: reverse-chronological order and film view. We will now discuss a hypothetical case to demonstrate our rule-based sequencing.
A particular image (of a specific patient) is fully described by the ordered pair I(tx, py), where:
‘I’ is a particular image taken at time tx with a view py.
Consider a set with the following images:
Examinations 1 and 4 have single views while examinations 2 and 4 have multiple views. Depending on whether the physician begins with a single-view exam or a multiple-view exam, two different sequences arise. These are discussed below:
Note that the sequencing proceeds only backwards in time. Also this scheme is set up for only two monitors, but could be easily generalized for multiple monitors.
Our design involves a local sub_archive which contains subsets of data present in the central archive. The sub_archive, however, can become stale. Currently this can happen with respect to: (1) The list of patients in the MICU and, (2) The availability of ‘wet-readings’ mentioned earlier. Therefore the local and remote archives must periodically be synchronized. This has an impact on the high level design. At present, our control program exits after a period of user inactivity and synchronization occurs when it is reinvoked.
The MICU station’s sub archive can only hold 22 contiguous images. It is advantageous to be able to move newly digitized images that are available on the archive and have a high probability of being viewed here. The rules for choosing the ‘next-image’ presented in an earlier section drives the image-prefetch algorithm. Currently, the image retreival program, irp, has two masters. The first is the MICU control program, mcp, and the other is the image pre-fetch program. A more comprehensive design would regard irp as a server or database manager available to any user at any time.
One issue which arises in retrieving a sequence of images is when to retrieve them. If all images in a given sequence are likely to be viewed, it makes sense to retrieve them one after another. However, if later images in the sequence are less likely to be viewed, then their retrieval should be retarded in order to conserve I/O time and disk space. This parameter is driven by the nature of the specific display station: a review and comparison station such as our MICU station might differ from a reading station in the radiology department. Currently, the prefetch is one (or, in specific situations, two) images ahead of the actual usage.
We record both usage and usage characteriestics on the MICU station. This is essential for evaluating user acceptance and preferences. In due course, we wish to code in more intelligence into the user interface by designing ‘personality modules’ that will cater for different users by providing tailored environments.
The clinical evaluation has now been in progress for 24 of the 64 weeks that are scheduled. This includes two ‘film’ periods and one ‘digital’ period. Apart from the questionnaires mentioned above, the project’s Research Coordinator has been interviewing users for their reactions to the use of the console.
The MICU physicians noted the convenience of having the images available to them earlier in the day, lessening the need to visit the Radiology Department. This advantage was more evident on weekends and evenings. We did note a reluctance to the use of the digital console, however. Some felt that the worst-case retrieval time of 20 seconds was rather slow. Physicians were uncomfortable with any kind of image manipulation, for fear of losing a baseline for comparison. Some felt the need for a substantial amount of manipulation to achieve an acceptable appearance.
We have designed a prototype Medical Image Management System and are clinically evaluating it. Effective software design is crucial for physician acceptance. The MIMS display console is an ideal area for multi-tasking operations. Use of rule-based, intelligent scheduling algorithms can greatly enhance the utility of a digital viewing console. We have noted the reactions of the physicians to our display console and we are working to improve the console.
This supported by grant, #HL 33332 from the NHLBI, USPHS. We wish to acknowledge the technical support of Philips Medical Systems and E.I. DuPont de Nemours.