Search tips
Search criteria 


Logo of digimagwww.springer.comThis JournalToc AlertsSubmit OnlineOpen Choice
J Digit Imaging. 2003 March; 16(1): 96–102.
Published online 2003 April 30. doi:  10.1007/s10278-002-6026-5
PMCID: PMC3045120

Prototype Medical Image Management System (MIMS) at the University of Pennsylvania: Software Design Considerations


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.


Preliminary work on the prototype began in 1981 and has been refined since.2,3,4 At present, five stations are networked together with a token-passing, star-shaped fiber-optic ring (see Figure 1).

Figure 1
The topology of the prototype MIMS.

A description of the hardware follows in Table 1.

Table 1
Description of the hardware

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:

  1. Demographic data
  2. Radiologist diagnosis data
  3. Administrative data
  4. Time to action data

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
The event flow in the MICU.


4.1 Preliminaries

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:

  1. Acquisition
  2. Transmission
  3. Storage
  4. Retrieval
  5. Display of the image and demographics

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

4.2 An Example

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

Figure 3
The MICU ↔ Archive program structure.

Note the existence of three classes of programs:

  1. Programs with duals that operate across the network [adb/pdb]
  2. Programs that are unique to a node [dsp]
  3. Programs that are similar, but run on different nodes [pel]

4.3 Typical session:

A simplified description of a typical session would be:

At software boot time

  1. Network server is activated
  2. Error logger is activated

For every session

  1. mcp is invoked and spawns irp
  2. User requests images for a patient
  3. Patient information is retrieved by adb/pdb
  4. User requests image
  5. mcp passes message to irp
  6. irp checks (local) sub_archive,
equation image

In the more interesting situation where a multiplicity of images are requested we see the evolution of two symbiotic program loops:

  1. LOOP 1:  user request → display/manipulation → user request
  2. LOOP 2:  archive_request → image_transmission → archive_request

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:

  1. The time to retrieve an image from the local disk is significantly smaller than the time required to retrieve an image, via the network, from the archive.
  2. The host computer is sufficiently powerful that these two tasks can proceed without significant degradation of user-response time.
  3. It is possible to formulate a ‘look-ahead’ algorithm that will determine what the ‘next’ image will be.

4.3 Related Issues

There are a number of issues that directly impact the high level design of a MIMS. We now discuss a few of these.

4.3.1 Display Rules

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.

  1. Times are ordered as follows: t0, t−1, . . . , t−k, . . . t−n
  2. Time t0 is the most recent
  3. Film views are ordered as follows: p1, p2, . . . , pj, . . . , pm
  4. Film view p1 has the highest priority, other views decrease in priority.

Consider a set with the following images:

  1. EXAM 1: I(t0, p1)
  2. EXAM 2: I(t−1, p1), I(t−1, p2), I(t−1, p3), I(t−1, p4)
  3. EXAM 3: I(t−2, p1), I(t−2, p2)
  4. EXAM 4: I(t−3, p1)

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:

Case 1: Begin with a Single-view Exam

Case 2: Begin with a Multiple-view Exam

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.

4.3.2 Synchronization

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.

4.3.3 Image Prefetch

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.

4.3.4 Prefetch Queing

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.

4.3.5 Session Logging

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.


1. National Electrical Manufacturers Association: ACR-NEMA Standards Publication Number 300-1985, Digital Imaging and Communication, NEMA, 1985
2. Arenson RL, London JW, Morton DE: Fiber Optic Communication Systems for Medical Images. Proceedings of the First International Conference and Workshop on PACS for Medical Applications, IEEE Computer Society, cat. no. TH0090-1, pp. 74-79, 1982
3. Arenson RL, London JW, Morton DE: Fiber Optic Network with Image Storage and Display Systems. Proceedings of the Seventh Conference on Computer Applications in Radiology, American College of Radiology, pp. 545-561, April 1982
4. Arenson RL, Morton DE, London JW: Early experience with Fiber Optic Picture Archival and Communication Systems for Medical Images. Proceedings of the SPIE Second International Conference on PACS for Medical Applications. SPIE, pp. 116-121, 1983
5. van der Voorde F, Arenson RL, Kundel HL, et al. Development of a Physician Friendly Digital Display Console. SPIE Medicine XIV/PACS-IV Newport Beach, CA. 1985;626:541–548.

Articles from Journal of Digital Imaging are provided here courtesy of Springer