NucNet: A single-vendor clinical picture archiving and communication system—description and reflections

NucNet: A Single-Vendor Clinical Picture Archiving and Communication SystemmDescription and Reflections Jack E. Juni In 1 9 8 4 t o 1985, w o r k commenced at the University

of Michigan to develop, in cooperation with commercial vendors, a picture archiving and communication system capable of handling all clinical imaging in the division of nuclear medicine. The guiding features o f NucNet are the optimization of the system for perceived, rather than actual speed, and the use of technology appropriate to the majority of clinical activity rather t h a n t o the entirety. This has resulted in a cost-effective system that has been easy to use

N 1985 a group headed by the author from the

I Division of Nuclear Medicine at the University of Michigan Medical Center was assigned the task of designing, purchasing, and implementing a picture archiving and communication system (PACS). This system was to allow acquisition, viewing, and archiving of all image data acquired by the Clinical Nuclear Medicine service. The positron emission tomography (PET) research facility at that time was located in a separate building with its own custom-designed VAX (Digital Equipment Corp, Maynard, MA)based system. Because there was no computer programmer or a systems analyst working in the Clinical service, the architecture, design, and implementation of what later came to be called NucNet to a great extent were the result of a close collaboration between well-informed amateurs and commercial vendors. Although fulltime computer programmers were later brought on board, the goals and initial architecture of the system reflected the strong clinical orientation of the initial planners. REASONS FOR INSTALLING PACS

Digital Display of Images By displaying all images in digital rather than sheet film format, the interpreting physician would have the ability to window and contrast enhance all images. By viewing multiple studies of one patient side-by-side on a computer display, we hoped to improve on the previously intermittent availability of old films for interpretation. Interactive viewing of single-photon emission computed tomography (SPECT) studies and cinematic display of gated blood pool and gastrointestinal (GI) motility studies previously had Seminars in Nuclear Medicine, Vol XX, No 3 (July), 1990: pp 193-204

and well accepted for routine clinical work. A new image management system currently being developed at William Beaumont Hospital is based on these principles but uses the latest generation of powerful microcomputers to perform most of the actions currently performed by l a r g e r computers on NucNet. It is anticipated that, using current technology, the key functionality of NucNet can be obtained for a fraction of its original cost. 9 1990 by W.B. Saunders Company.

required physicians to walk from computer to computer. Each machine was generally unable to perform image acquisition or processing while these "computer rounds" were in session. Centralized digital scan viewing would reduce physician workload and increase the availability of imaging computers for additional patient throughput.

Digital Image Archiving By storing all nuclear medicine images in digital form, it was hoped that NucNet would provide more rapid access to studies than traditional sheet film library methods. 13 It was expected that computerization would reduce the number of lost or misplaced films and, due to image storage in a computerized data base, allow rapid location of any particular scan.

Remote Acquisition and Viewing Nuclear medicine at the University of Michigan was divided into several physical locations-a pediatric subunit in the adjacent Mott Children's Hospital, a cardiac imaging subunit located adjacent to the Cardiac Intensive Care Unit, and the PET research facility located in the medical research building complex. By electronically connecting these remote sites, we hoped to allow any image acquired at any of these sites to be processed and/or viewed at any site. In addition, we planned to make electronic scan viewing

From the Department of Nuclear Medicine, William Beaumont Hospital, Royal Oak, MI. Address reprint requests to Jack E. Juni, MD, Nuclear Medicine Department, William Beaumont Hospital, 3601 W 13 Mile Rd, Royal Oak, M148072. 9 1990 by W.B. Saunders Company. 0001-2998/90/2003-0001505.00/0 193

194

JACK E. JUNI

available to the cardiac catheterization laboratory and to the orthopedic services, with potential availability of films for review in other units as requested. 3,4

2.

Electronic Dissemination of Scan Reports Before NucNet, formally dictated scan reports were typed on microcomputer-based word processors and the printed reports were distributed by hand and pneumatic tube system to the inpatient wards and outpatient clinics. By coordinating computerized storage of scan reports into PACS, remote electronic access to patient reports would become feasible. By connecting to the already existing hospital broadband laboratory data network, we were able to make scan reports accessible to hospital staff using the computer system already in existance for clinical pathology reports.

3.

Cost Savings We hoped to see a net cost savings with the implementation of PACS due to several factors. 5'6 By reducing the need for physical filing and sorting of films, we hoped to reduce labor and clerical costs as well as to reduce the size of the film storage area. When digital viewing was firmly established, the possibility of doing away in large part or completely with x-ray film would eventually result in a substantial savings. Most importantly, we hoped to increase the ability of physicians and technologists in the division to accomplish more productive work per unit of professional time.

4.

GUIDING PRINCIPLES OF CLINICAL PACS

1. The system must be perceived by its users as better than the existing system of sheet film and alternator panels. No matter how modern or state of the art it may be to computerize a clinical unit, if the computer system is not a noticable improvement for the great majority of its users, implementation into daily practice will be an uphill battle. The system must be sufficiently "user-friendly" to enable operation by all technologists and all physicians, including rotating residents with a minimum of instruction and a minimal need for refresher courses when rotating personnel return to the unit. A clinical unit in which a com-

5.

puter expert(s) must be on hand to help will have trouble operating at high efficiency. The system must be faster than a filmbased system. The issue of actual and perceived speed of a PACS may be the single most important determinent of success or failure in the clinical setting. A loaded film alternator requires only about 3 seconds to bring up a new study. No matter what the cost savings, a system in which the speed of physician access to needed images is in any degree less than that of a sheetfilm filing system is unlikely to be accepted. The issue of system speed is addressed later. The psychology and scan-handling habits of the physician and technologist should dictate all system functions. The pattern of interaction between patient, technologist, and nuclear medicine physician is a complex and relatively unstructured mix of question-and-answer, image inspection, evaluation, and special requests. The technologist and physician interact many times throughout the day. If a computer is interposed between the clinical staff, the normal interplay that contributes to a sense of job satisfaction is damaged. No one wants to spend their day interacting with a computer rather than a human being. System users should not have to understand the computer operating system. Requiring physicians to learn Unix (9 AT&T, New York, NY), VMS (9 Digital Equipment Corp, Maynard, MA), or other computer operating systems is in the best of circumstances a chore, and in the worst of circumstances a threat, particularly to those of us who began practice before the prevalence of computers. A few simple and intuitive commands or motions should be sufficient for the average user to do their job. All system functions should result in the transfer of work to the lowest paid person capable of doing the job. A system that requires the physician to request each scan and bring it up for viewing is not likely to be viewed with favor by a physican used to having this chore done by a file clerk. Considering the wide pay scale range of the typical nuclear medicine department, trans-

NUCNET: DESCRIPTION AND REFLECTIONS

fering even simple tasks up the chain of command may not be cost-effective. 6. A P A C S must be less expensive than a film-based system or it must pay for itself in greatly added functionality. 7. The system must have as much redundancy as possible, ie, the failure of any single component of the system must not be catastrophic. Referring physicians do not view "the computer is down" as an acceptable excuse for a lack of results. Loss of even a small amount of patient data due to system failure is unacceptable. For this reason, the system was designed to have as much hardware and software redundancy as possible. Hardware modules were to be as interchangeable as possible. Software for most pieces of equipment was to be identical, thus allowing rapid replacement of an ailing unit with a spare without performing major system surgery. 8. Most importantly, the system must be capable o f automatic function. That is, performance of the entire range of data acquisition, data migration (transfer of data from acquisition units to viewing and archiving stations), and archiving itself should not require a system manager. All data archiving was to be completely automatic, requiring at most the relatively simple task of mounting a new reel of magnetic tape or a fresh optical disk platter by the technologist staff. 7 In 1986, the clinical imaging core of the Division of Nuclear Medicine was relocated to a new hospital building. Significant funds were thus available for new equipment purchases, but there was no immediate funding for computer personnel. This resulted in the following additional rules for the design of NucNet: 1. The system was to be oriented for clinical rather than research use. Although the clinical and research aspects of nuclear medicine at the University of Michigan overlap extensively, the primary thrust of N u c N e t was to be support of the clinical operation. Although the system was later expanded to include clinical research, extensive off-line processing capabilities and sophisticated on-line research-orientated data bases were viewed to be of secondary impor-

195

tance. Nonetheless, provisions had to be made in design of the system to permit expansion of its research functionality once the clinical requirements were met. 2. All hardware must be commercially available. Most of the digital imaging systems in use during the design phase of NucNet were based heavily on custom-designed or extensively modified commercial equipment. Because the personnel required to make and support such equipment were not available to us early on, it was essential that all hardware be not only commercially available but completely supportable by outside services. 3. All major system software must be commercially available. The software needed for management of a digital PACS is typically large and complex. Software maintenance (debugging, optimizing, and revising) of most systems requires in-house computer programmers. The funding situation that left us with substantial money for equipment but negligible money for personnel, again required that we look to a commercial vendor for system software. 4. For the previously mentioned reasons, it was decided that the entire system must require less than one quarter full-time employee (FTE) to manage and maintain. NuCNET AT THE UNIVERSITY OF MICHIGAN: INITIAL CONFIGURATION

The planning and negotiations that lead to N u c N e t began in the summer of 1984. It was decided early on to purchase the entire computer system from a single vendor. Although this significantly restricted the options available, the primarily factor was our need to have a system that could be assembled and, for the most part, maintained by commercial vendors. Past experience at many sites has shown that even the simple connection of a gamma camera from one vendor to a computer from another frequently results in maintenance and startup problems. The vendor of each piece of equipment will be tempted to blame problems on other vendors' component(s). The user, in the uncomfortable position of forcing field service representatives from two (competing) companies to work together, is facing a challenging task to say the least. Because clinical

196

needs dictated that a variety of gamma cameras be used, we felt it necessary to standardize on one computer system for interconnecting them, particularly since the various components of the computer system were required to exchange information as a primary function of the PACS. It was necessary that not only hardware support but software support as well be coordinated from a single source. In making such a large purchase--22 computers serving 10 cameras--it was also important that the system use as little proprietary hardware as possible. Several vendors offered systems that met most of our needs, but were heavily dependent on custom-built communications interfaces, disk drives, etc. Our concern was that should these companies change the direction of their product line or suffer unforseen financial reversals, we might be left with an unsupported and potentially unsupportable system. If the basic components were constructed from units available from third-party sources, ie, general purpose computers and network buses, we would at least have the potential of maintaining and upgrading the hardware components of the system from other sources. Likewise, if intercomputer communications used a widely available and welldocumented format, we would be less susceptible to the vagaries of the nuclear medicine marketplace. In 1985 to 1986, we eventually settled on a system based on the M i c r o D E L T A / M a x D E L T A systems developed by Computer Design and Applications (CD&A) of Waltham, MA. We had concern about purchasing this system from a small company with relatively little experience or investment in the nuclear medicine arena. We elected to purchase this equipment through Siemens Gammasonics Inc (Hoffman Estates, IL) via an arrangement in which Siemens warrantied the performance of the system and guaranteed support and maintenance for it. Negotiations between CD &A and Siemens were already underway at that time for Siemens to acquire the M i c r o D E L T A / M a x D E L T A product line from CD&A. This acquisition occurred at about the same time as our placement of the purchase order. Thus, at the time of delivery, our entire system was part of the Siemens product line, supported by Siemens with additional support contracted by Siemens from CD&A.

JACK E. JUNI

The M i c r o D E L T A / M a x D E L T A system consists of multiple MicroDELTA computers connected by a proprietary communications link ( H C O M M ) to a VAX 11/750 superminicomputer (Digital Equipment Corp, Maynard, MA). The MicroDELTA contained a nuclear acquisition board, a 512 • 512-pixel color display, a 60 to 80 megabyte internal hard disk, an internal bit-slice processor (a hardware board capable of rapid performance of certain predefined operations such as image smoothing), and a 51/4 inch floppy disk drive. The MicroDELTA also had its own internal microprocessor capable of performing a full range of nuclear acquisition and processing routines. The H C O M M line connecting the MicroDELTA to the VAX consisted of a fairly standard RS-232 serial line for text communications and a separate high-speed coaxial cable data path for the transmission of image data. When connected to a VAX or Microvax (Digital Equipment Corp, Maynard, MA) computer via the H C O M M line, the MicroDELTA could operate in "slave" mode. In slave mode, all data acquisition and camera control was performed on the MicroDELTA while image data were transmitted to the VAX or Microvax computer. Most additional processing was then performed on the VAX or Microvax central processing unit (CPU), which in turn was capable of using the MicroDELTA's bit-slice processor for computationally intensive tasks such as tomographic reconstruction. In slave mode, operation of the MicroDELTA was significantly faster than in standalone mode; however, from the operator's point of view, the software was identical. Thus, the system had an attractive element of redundancy. While the optimal performance was obtained by using the MicroDELTA in slave mode connected with a VAX or Microvax computer, in the event of malfunction of the VAX-type system or in the H C O M M communication hardware, the MicroDELTA could perform all routine acquisition and processing tasks, albeit at a slightly slower rate. Data could then be transferred via floppy disk from one MicroDELTA to another to bypass any single failure in the H C O M M communications link. The standard commercially available MaxD E L T A configuration at that time consisted of a single VAX 11/750 computer with one to four MicroDELTA computers slaved to it. In order to

NuCNET: DESCRIPTION AND REFLECTIONS

197

permit simultaneous operation of over a dozen acquisition and processing stations, we would need to connect multiple VAX CPUs together, a configuration not readily available at that time. We were able to take advantage of a close working relationship with Siemens and CD&A in which the companies' personnel developed communication software to meet our design specifications. Although this meant that initially we would be the sole users of this software product (a situation we had hoped to avoid), Siemens later marketed this system widely leaving us with a well-supported hardware and software foundation. We initially purchased a total of 16 MicroDELTA units, 12 for acquisition and processing, two for off-line processing, and two for image review and interpretation. Rather than purchase a number of VAX 11/750s, we purchased four Microvax II (Digital Equipment Corp, Maynard, MA) computers, a unit that had just entered the market place. The Microvax II computer provided virtually the same processing capability as the VAX 11/750 at substantially less cost and with substantially lower space requirements. Three of the Microvax IIs were connected to MicroDELTAs whereas one was reserved for the DELTAVISION (9 Seimens

Gammasonics, Inc, Hoffman Estates, IL) display system described below. The VAX-type CPUs were interconnected using a bus configuration Ethernet (9 Xerox, Stamford, CT) system running under the DECNET (9 Digital Equipment Corp, Maynard, MA) software protocol. This communications package was available off-theshelf from Digital Equipment Corporation and transmitted data with a maximum rate of 10 megabits per second, thus meeting both the third-party availability and speed requirements previously defined. A diagram of the hardware configuration of the system is shown in Fig 1. Each Microvax II computer was fed via HCOMM line by 3 to 4 MicroDELTA acquisition and processing units. Each of the three Microvax II computers was equipped with a total of 135 megabytes of magnetic hard disk storage. The VAX 11/750 served as a backup acquisition node but, more importantly, as a central archiving node. The VAX 11/750 drove two 400 megabyte fixed multiplatter hard disks and a single 200 megabyte removable platter for a total of 1 gigabyte of on-line magnetic storage. This storage formed the short-term archive, to be described subsequently. In addition, the VAX 11/750 was connected to a 1 gigabyte optical disk storage unit forming the long-term archive.

MicroDelAcqui ta sidUnits on

I MicroVax II I

I MicroVax II~

$1

$1 EtherNet Bus $1

;l I Vax11/750IN I ~ Fig 1. Original hardware architecture of NucNet. Note that all V A X - t y p e central processing units (CPUs) function as peers. In the event of hardware failure, any of the V A X - t y p a CPUs could take over the functions of another.

I MicroVax II1

-lineprocessing

iI II I ~'~--'~ DeltaVision ~ Physician processing~ ScanReadingRoom

:

198

This unit was of the write once, read many times variety permitting no erasure of recorded data. This was felt to be a desirable feature for archiving of medical images. The optical disk was initially controlled by software that was custom-developed by CD&A. Difficulties with this software led us to switch to a commercially available optical disk controller software package marketed by Perceptics (Knoxville, TN), reaffirming the desirability of purchasing off-theshelf products manufactured by outside vendors whenever possible. The Perceptics software enabled the optical disk to be controlled by any VAX-type computer in a manner identical to that of a standard erasable magnetic disk. Because of this, no special modifications of the existing software were needed to use optical disk storage. Two MicroDELTA stations were attached via H C O M M to the VAX 11/750. These units were placed in the scan reading room and were available for physician review of scans and physician processing of clinical data. The great bulk of clinical image display and interpretation was performed on a unit then known as DELTAVISION. This unit contained 8 megabytes of high-speed random access memory (RAM) with a dedicated processing unit driving a 1024 • 1024 high resolution 16-bit color display monitor. The unit requires a VAX-type CPU to drive it and we elected to use our fourth Microvax II for this purpose. We could have used this Microvax II for other purposes simultaneously if needed. The DELTAVISION was controlled by a keyboard and a mouse and had a number of useful capabilities. The large amount (for its day) of image random access memory (RAM) allowed the display to be preloaded with a large number of images waiting to be displayed. The images were displayed side-by-side in miniature form on the screen with superimposed patient names. By pointing at any image with the mouse, that image could be expanded or zoomed up to full display size for group viewing. Cinematic sequences were represented on the screen by their first frame. A single mouse click set the entire (zoomed) sequence into motion. Using the mouse to point at a menu of options at the right side of the screen, images could be smoothed, windowed, and moved about on the screen. Color translation tables could also be changed with a few mouse clicks. If

JACK E. JUNI

images were transferred to the DELTAVISION in advance of a reading session, most of the images to be interpreted were already in memory and on the screen. Zooming a given memoryresident image set to viewing size was virtually instantaneous. Mouse-selectable menu items also allowed retrieval of images from the short-term and long-term archives by either date, patient name, or patient number. NETWORK TRANSMISSION SPEED

The original NucNet was implemented using a commercial communications link ( H C O M M ) that transmitted data from the acquisition units to the VAX and Microvax II backbone of the communication system at approximately 1 megabit per second. Transfer of information along the VAX backbone was performed using coaxial cable Ethernet using Digital Equipment Corporation's DecNet software protocols at approximately 10 megabits per second. In actual practice, of course, network t h r o u g h p u t s are considerably less than the data rate specified by any manufacturer. ~'3 Ethernet is now the most commonly available high-speed data transfer method and is relatively inexpensive. However, when multiple computers try to use the network simultaneously, their messages "collide," dictating that the computers stop transmitting and retry later. Thus, while the network may have a very high-rate of data transfer when only small volumes of data are being moved, the actual data throughput may be only a small fraction of the rated throughput when multiple images are being moved between multiple different computers. The actual time required for data transfer in a well designed PACS is irrelevant. A physician sitting at a display station to review the day's accummulation of images need have no knowledge or concern for the amount of time it took data to be moved from one computer to the other. The most important criterion, perceived system response time, can be defined as time spent by the end user waiting for a request to be filled. More specifically, for a physician, the perceived response time of the system is determined by the time spent not interpreting images or performing other intelligent activity while waiting for a response from the system. While actual time is not directly related to perceived time, the throughput rating system shown in Table 1 seems to

199

NucNEx: DESCRIPTION AND REFLECTIONS

Table 1. Subjective Perception of System Response Time Versus Actual Time ActualTime (s)

PerceivedTime

< 1 2-4 4-10

Rapid

Instant

> 10

Forever

Slow

apply. Images must be ready when the user is ready to see them. The natural conclusion is to use the fastest available technology to move images from point to point. At the present time, actual data transmission rates an order of magnitude higher than those of N u c N e t are achievable with commercially available hardware. Although the overall price/performance ratio of digital data transmission lines keeps improving, 1 our experience would seem to indicate that such high-end hardware solutions may not be necessary for a nuclear medicine network. Physical data transmission rate contributes to perceived system response time only when the user is waiting for an image to be transferred across the network. If a system is designed such that all data can be retrieved from any of a multiple of viewing stations, a large number of data paths are required. If it is assumed that the user may wish to view any image residing in the system archives at any time, an extremely high data-transfer rate is required. Our own observations, and those of Templeton et al, 6 indicate that this is not applicable in a dedicated clinical nuclear medicine network. In observations of film library room activity, we have found that - 8 5 % of all data retrieval needs can be anticipated at least 24 hours in advance and better than 98% at least 4 hours in advance. Images must be ready when the user is ready. However, most physician users are only ready to review scans at certain prescheduled times of the day. For example, it may be reasonably assumed that a gated cardiac blood pool scan scheduled for performance in the morning will need to be viewed and interpreted at the routine 3:00 PM scan reading session. Likewise, in most mediumor large-sized units, scan reading is performed almost exclusively in one physical location, ie, reading room. Assume the processed data are physically located on a magnetic disk at some central computer. To view this study during the afternoon reading session, the reading room phy-

sician must enter a request to see a study and wait for it to be transferred across the network. However, at the time the scan was scheduled it could reasonably be anticipated that the physician would want to see the images at this time and location. The images could be automatically transferred from the central computer to one or more viewing terminals in the reading station before the images are requested. If these images are then stored in R A M or on a high-speed magnetic disk at the image display station, the response time perceived by the physician is determined only by the speed of the image display terminal itself. 7'8 In this manner, direct access of information across the network in which the user is spending nonproductive time waiting for an image to be transferred may in most cases be eliminated. It is relatively rare that an image is interpreted within the first few minutes after it is acquired. Thus, although always desirable, high datatransmission rates are not essential to the perceived response time of a system. Rather, when a study is scheduled, the system can be notified in advance of any requests as to where to send a copy of the data. So long as the data are transmitted, however slowly, before they are actually requested, the perceived response is virtually instantaneous. It has been our experience that if the system response for the overwhelming majority of data is rapid, users can easily tolerate somewhat slower response time for the rare unanticipated data request. DATA MIGRATION

Automatic flow of data to the correct places was necessary to the hands-off operation of the system desired, both in terms of moving images from one computer to another and in terms of incorporating studies into the patient database and optical disk archive. The software architecture shown in Fig 2 was implemented. Note that each unit in the diagram may or may not represent a different hardware unit. In fact, the system was designed to be flexible so that various pieces of hardware could serve many different roles in the data transfer process. In addition to allowing for expansion of the system, this also gave us greater resistance to hardware failures. If, for example, the machine containing the short-term archive were disabled, a new short-

200

JACK E. JUNI

Qt Gammacamera I

MicroDelta

1

24 hours

I.

MicroVaxII

1

0-10 rains

= 3 weeks

= 3 weeksper disk- (Optical\ Disks archived term archive could be started on an alternate computer very simply without altering the overall system setup. Gamma camera data were acquired directly into the MicroDELTA acquisition units. These data were then either processed (calculation of ejection fraction, smoothing, etc) on the acquisition unit or were sent for processing off-line on another unit or to the short-term archive. When the technologist who acquired the data had completed the work on a given data set, a single menu option added to the clinical software package provided by Siemens initiated an automatic transfer of the patient's data through the H C O M M line to one of the Microvax IIs. These data were not deleted from the initial acquisition machine but remained on that machine for 24 hours. The Microvax IIs each came equipped with approximately 135 megabytes of hard disk storage, which served as intermediate staging areas at which data could be buffered and stored awaiting transfer to other locations along the Ethernet bus. Because the initial acquisition Units were not capable of multitasking (eg, performing a data transfer while simultaneously acquiring or processing another study), the Microvax IIs served an important function by rapidly accepting the data transferred by the technol-

24 hours

Display RAM

24 hours

Fig 2. Data migration path. Bold arrows indicate data transfer performed automatically by demons. A d e m o n on the DELTAVISlON server could request needed studies from the short-term and long-term archives, the magnetic and optical disk units, respectively. A demon to automatically transfer data from DELTAVISlON to display RAM is under development.

ogist. If the Ethernet bus was operating near maximum capacity, an infrequent occurrence in our experience, the Microvax IIs could hold the data until they could be transferred further. The multitasking capability of the Microvax IIs enabled them to continue acquiring data from other acquisition units while holding data for further transfer.

Servers, Demons, and Other Operatives In order for images to be appropriately transferred through a networked computer system to short-term and long-term storage areas, display devices, and mass storage devices, some routing decisions must be made. One way to do this is to have a human computer operator examine each file on the system and copy or transfer it to other locations as needed. Following the precept that human labor is the most expensive part of a computer system, we elected to automate this process using special software servers, colloquially known as "demons." A software demon is a computer program capable of functioning without human interaction. In NucNet, such programs exist on all computers other than the MicroDELTA acquisition units. The software demon is capable of activating itself automatically at predetermined time intervals, perform-

NUCNET: DESCRIPTION AND REFLECTIONS

ing the task(s) assigned to it and then inactivating itself (hibernating) until the next designated reappearance time. In our system, the Microvax IIs connected to MicroDELTAs had a demon that awakened approximately every 60 seconds. This demon examined the hard disk on the Microvax II looking for the presence of one or more files that had been transferred over from the acquisition units. If no such files existed, the demon-server would turn itself off and reawaken 60 seconds later to check again. If a file or files were found, the demon-server would transfer a copy of the files(s) to the short-term archive and to a special staging area where scans awaited further transfer to the D E L T A V I S I O N reading room display system. In the original N u c N e t configuration, this staging area was a partition of a large magnetic disk attached to the VAX 11/750. Another demon-server in the VAX 11/ 750 would awaken every 5 minutes and look for image files in the staging area. If any were present, it would transfer them to the local hard disk on the Microvax II dedicated to the D E L T A V I S I O N display system. An additional demon-server was under development to automatically transfer as many studies as possible from the hard disk in the D E L T A V I S I O N ' s Microvax II to the RAM in the D E L T A V I S I O N . This would have the effect of electronically "loading an alternator" by keeping the RAM of the display system full. Any images in the RAM appear almost instantly upon request. Therefore, it appears to the physician requesting an image that the system's response time is very rapid, even though it may have taken 10 or 15 minutes for the image to get from the camera to the viewing station. ARCHIVING

A common justification for installation of PACS is the ability to rapidly access prior imaging studies on a given patient for comparison to new studies. ~'3'7 Many system designs employ complicated high-bandwidth cable or fiber optic data-transfer systems to enable ondemand transfer of large, multifile data sets. In order to get these older studies into the network, a means of rapidly accessing old optical disk platters is needed. The most common solution is the optical juke box, a device that stores a number of optical disk platters and can insert a given one upon request much as with juke boxes

201

designed for audio records. While such a system is attractive at first glance, it is often not practical for the nuclear medicine setting. If a nuclear department generates 1 gigabyte every 3 weeks (the amount of data archived at the University of Michigan), then a total of 17 optical platters would be used in a year. The typical optical juke box available at the time of writing this article costs between $150,000 and $250,000 and holds about 50 disks. Thus, an additional optical juke box would have to be added every 3 years. To put this in perspective, the cost of one optical juke box will pay the salary of a filing clerk for 8 to 10 years. Therefore, rather than invest in an optical juke box to provide rapid access to past data, it seemed far more cost-effective to use existing file room staff to mount and dismount optical disks upon request. This is a simple job requiring less than 15 minutes of training and requires no other knowledge of computers. As an example, most patients having routine bone scans for follow-up of metastatic disease are scheduled at least 24 hours in advance. It may reasonably be assumed that the physician interpreting scans would like to have all past scans on that patient available at the time of reading. Therefore, it is possible to mount the appropriate optical disk platter containing the old data and transfer those data to the network the night before or the morning of the scan. Again, because the data will have been automatically transferred to the viewing station before they are requested by the reading physician, the perceived access time is quite rapid. Our patient population can be divided into basically two groups: those patients having a single scan for an isolated problem and those patients returning on a regular basis for followup scans of chronic illnesses such as metastatic disease, coronary disease, diabetes, etc. If each study on this second set of patients were to be archived on a separate optical disk at the time the study was performed, in a few years, such a patient might have files scattered across five or six optical platters. This would require that multiple disks be mounted in order to retrieve all past studies for viewing. Because human labor is the most expensive component of a system, such shuffling of disk platters would present difficulties, especially when many such patients were scheduled f o r a day. For this reason, when any patient comes for a scan, all previous studies on

202

JACK E. JUNI

the same patient are retrieved from optical disk and placed in a single batch file in the short-term archive. This entire set of studies is then rearchived on the optical disk currently in use. Although this means that a patient having 10 scans might have 10 copies of the first scan in the optical disk data set, only the most recently archived file set needs to be pulled. Thus, a maximum of only one optical platter per repeat patient would need to be mounted. Kent Gardner at the University of Michigan has written a simple program that, when given a list of patients to be retrieved, checks the database and prints a list of which optical disks need to be mounted. If two or three patients' files reside on one older optical disk, a single mounting of that disk would allow all such patients to be retrieved. Therefore, pre-pulling of studies for a full day's reading session rarely takes more than 5 or 10 minutes and can be done by a relatively unskilled worker. Even if the optical disk library were to expand to several hundred disks, the cost of purchasing and maintaining a series of optical juke boxes would be an order of magnitude higher than the cost of employing an hourly worker to perform the same task. Because the disks rarely need to be accessed in a rapid (<10 minutes) manner, replacement of a file clerk with an optical juke box seems impractical for a well-planned clinical system. The cost of maintaining multiple copies of a patient's file is typically less than 25 cents per patient at current prices. These prices can be expected to decrease in the future. IMAGES IN MULTIPLE LOCATIONS

N u c N e t was designed so that all images could be transferred across the network and viewed at any image processing or display computer on the network. Doing this would require a relatively high network throughput capability if this feature were to be used often. In practice, we found it was extremely uncommon for patient data to be requested of the network at any other than two locations--the physician scan reading room and the separate computer area designated for offline processing of scans by technologists. Since in actual practice scans were almost never requested from the network by the individual acquisition stations, substantial cost might have been saved by omitting this capability. The system of demons-servers that automatically transfer scan data to the physician reading room

also could be used to transfer all data to the computer area for off-line processing. It is cheaper to make multiple copies of an image and send them to wherever they might be needed than to transfer one copy rapidly back and forth between multiple locations. In many systems, the existance of multiple copies of a patient's data on the network is considered something to be avoided. In NucNet, a system somewhat analogous to the publishing of a daily newspaper was implemented. The official copy exists at only one place: the longterm archive (optical disk). As many other copies as needed are created and sent to all places where they might possibly be desired. In this manner, just as with the newspaper, all information is available when one sits down to read. The fact that the newspaper may contain information that is not required by one particular reader is irrelevant. The systematic copying of all information and sending it in bulk to all possible readers is far less expensive than customizing a paper for the needs of an individual reader. Because our system was designed for reading and interpretation of scans rather than for the primary purpose of processing scans at multiple locations, the existence of multiple copies presented no problems other than use of memory space. If a physician or technologist doing off-line processing wished to have the newly processed data become part of the official record, they must send a letter to the editor, ie, explicitly order the system to incorporate their changes into the long-term archive. In actual practice, we found that physicians performed very little processing of routine clinical images and most of this processing could be performed in advance. In keeping with the philosophy that all work should be transferred to the lowest-paid person capable of doing the job, all predictable imaging process operations were performed by technologists off-line if any significant possibility existed that this processing would be requested. With the speed of modern nuclear medicine computers, it is less expensive to do special processing on every case than to have a physician do the processing for individual cases. In fact, after several months, one of the processing units placed in the scan reading room was removed due to the lack of use. In research or other settings a processing terminal may be desired in the physician viewing area, although for such cases the access time of individual cases

NUCNE'r: DESCRIPTION AND REFLECTIONS

need not be up to the standard expected for regular scan interpretation. A problem with the system of making multiple copies of data is that on-line system storage capacities may soon be exceeded. For this reason, a system of "sundown dates" for data outside of the long-term archive was implemented. All files were automatically deleted when their sundown date was reached. Each CPU on the system had a demon-server that activated itself every 24 hours to remove unneeded files. The rules for deletion of files were determined by the location of the given file, the date of origin of the file, a n d / o r a sundown date automatically assigned to a file by the data acquisition units when the file was submitted to the system: (1) All data stored on the MicroDELTA acquisition units ( MicroDELTAs) were deleted after 24 hours; (2) all data in staging areas such as the intermediate Microvax IIs were deleted as soon as it was verified that an accurate copy of the data existed further downstream in an area designated for more permanent storage; (3) all data were deleted from the local memory of the D E L T A V I S I O N reading if space was needed for new studies; and (4) data were deleted from the short-term archive if the following criteria were met: a copy already existed on the long-term archive, and either the sundown date for the given file had passed or insufficient storage remained in the short-term archive to hold the anticipated amount of data for the next operating day. Sundown dates were arbitrarily set at several weeks after file creation in the current implementation of NucNet. In the future, however, interaction with the scheduling desk will allow sundown dates to be assigned on the following premises: (1) images on all patients studied within the last week should be available on magnetic media storage, ie, the viewing station itself or the central short-term archive hard disk; (2) images on all inpatients should be available on the short-term archive until the patient is diskharged; and (3) copies of all images obtained within the previous 24 to 48 hours remain in local storage of the image display unit. APPROPRIATE TECHNOLOGY

A long-term goal of many PACS is to create a system capable of displaying images from all modalities--nuclear medicine, computed tomog-

203

raphy (CT), magnetic resonance imaging (MRI), angiography, etc. Nuclear medicine and perhaps ultrasound are unique in the relatively small amounts of digital data involved. Although the temptation is great to construct a system allowing simultaneous digital viewing of a chest x-ray and a lung scan, the added cost required to increase system storage capacities, bandwith, and display quality to permit reasonable transfer of a digitized chest x-ray is enormous. Saddling a nuclear medicine PACS with the requirement that it be capable of handling the massive amounts of data generated by CT or MRI would result in a very high hardware expense that does little to benefit the system in terms of transfer of nuclear medicine images. In a setting where such intercomparison of images is absolutely mandatory, one might consider the order of magnitude increase in price worthwhile. However, if such side-by-side comparisons are performed only a few times a day, it may be just as practical and clinically acceptable to view the nuclear images on a digital screen and the MRI images on a conveniently placed film view box. Good system design would dictate that a system should be built to handle the great majority of its tasks efficiently. Designing a system to allow it to efficiently handle the most complex of possible tasks, even if those involve only a small percentage of system usage, may result in a very expensive case of over-engineering. Along with the desire to create multimodality PACSs, implementation of report generation, image annotation, and teleradiology are often desired. While generation of electronic reports of scans was added to N u c N e t after it had been on-line for several months, an insistence that all of these features be provided at the outset would have substantially delayed system start-up and the subsequent resorting of priorities that ensued. We found that incremental implementation of system capabilities was both easier to justify on a financial basis and allowed us to make more intelligent decisions about what was actually needed. WHAT ABOUT ACR-NEMA?

The desirability of maintaining all files in the same digital format is obvious. This becomes particularly important when different modalities are linked and especially when units of different manufacturers are used. The design of NucNet

204

JACK E. JUNI

was simplified greatly by the fact that virtually all acquisition units came from one vendor and used compatible digital file formats. Other institutions, particularly those adding a PACS to an existing stock of computers from a variety of manufacturers, must face several problems. One question is whether all files should be stored in an identical format. This m a y be accomplished by use of file format translation software available from a limited number of vendors. At the present time, such systems are diskouraged by the major vendors of nuclear medicine equipment and often require purchase of separate hardware to permit their function. The American College of Radiology-National Electronic Manufacturers Association (ACRN E M A ) specification 3'4 provides a standard format definition for all medical imaging. At the time of this writing, virtually no nuclear medicine equipment available in the United States will produce A C R - N E M A standard output. The decision made for N u c N e t and for the new system under development at William Beaumont Hospital is to store files internally in the format in which they were acquired. When other imaging modalities come on-line, a translation device a n d / o r program will be acquired to allow twoway transmission of data. At the present time, it appears to be economically and practically unfeasible to use the A C R - N E M A specification internally in a nuclear medicine network. Hopefully, this will change in the future as vendors adapt to this standard. In any case, because N u c N e t is optimized for nuclear medicine, it is unlikely to handle large CT or M R I images gracefully. In view of the difficulties in implementing multimodality digital image transfer and the simplicity of using a light box along side a nuclear viewing

console, it seems that the vendors of light boxes have a long and profitable future ahead of them. LESSONS LEARNED FROM NUCNET

1. Ninety-eight percent of all data retrieval needs can be anticipated at least 4 hours in advance. 2. Rapid image transfer is only rarely needed as long as copies of images are placed where needed before they are requested. 3. All data do not need to be accessible everywhere. 4. All machines do not need to talk to all other machines. 5. Two-way data travel is rarely needed. 6. Replacing a file clerk with a computer programmer does not represent a cost savings. 7. Replacing a file clerk with a nuclear medicine physician is especially not cost-effective. 8. A system that has a perceived operating rate that is faster than a mechanical alternator will be readily accepted. 9. Completely replacing the fluorescent light at the view box by a computer screen is a pointless exercise. Appropriate technology should be used for each task at hand. ACKNOWLEDGMENT

The creation and implementationof a systemas complexas NueNet reflects the creativity and diversity of a number of peoplewithin the Universityof Michigan; Robert Ackerman, CNMT, David Feldt, Gregory Brown, Richard Hichwa, PhD, and Kent Gardner stand out among many others. Siemens Gammasonics and CD&A provided key expertise, knowledge, and hard work without which this system could not have been created. We eagerly look forward to the future creations of all these fine people. I would like to thank Maureen Rotarius for preparation of this manuscript.

REFERENCES

1. Huang HK, MankovickN J, Taira RK, et al: Picture archiving and communicationssystems (PACS) for radiological images: State of the art. CRC Crit Rev Diagn Imaging 28:383-427, 1988 2. Jost RG, Mankovich N J: Digital archiving requirements and technology. Invest Radiol 23:803-809, 1988 3. Cox GG, Dwyer SJ III, Templeton AW: Computer networks for image management in radiology: An overview. CRC Crit Rev Diagn Imaging 25:333-371, 1986 4. Cannavo MJ: Communicationsstill weak link in implementation of PACS. Diagn Imaging 155-157, 1989

5. Bakker AR, Stut WJJ Jr, DeValk JPJ, et al: PACS costs: Modelling and simulation. Med Inf 13:307-313, 1988 6. TempletonAW, Cox GG, Dwyer SJ III: Digital image management networks: Current status. Radiology 169:193199, 1988 7. Taira RK, Mankovich N J, Boechat MI, et al: Design and implementationof a picture archiving and communication system for pediactric radiology. AJR 150:1117-112t, 1988 8. Taaffe J: Digital image archive: Using statisticalcoaching techniques. Appl Radiol xx:39-43, 1988