Abstract

Introduction

Materials & Methods

Results

Discussion & Conclusion

References

Discussion
Board

In 1995, the Department of Diagnostic Radiology at the Montreal General Hospital implemented a filmless mini picture archive and communications system (PACS) that was developed in-house in its ultrasound division¹. This step demonstrated, within our department, the tremendous potential of PACS to provide faster and wider access to images through the automation of archival and retrieval tasks that previously occupied one full-time clerk who handled films. In addition, by eliminating the films, savings were generated that allowed the initial hardware startup costs to be recovered in under six months.

Concurrently and independently, a group of our radiologists were exploring the practice of soft-copy diagnostic review in CT and MRI. After a relatively short time, a preference for this approach became clear owing to the belief that soft-copy image analysis yields a more thorough means of diagnosis, thus greater potential clinical benefit. This consensus, together with the financial and technical success of the ultrasound mini-PACS, motivated the decision to extend the PACS to include CT and MRI. However, some challenges needed to be faced that were not previously significant in ultrasound. The three most important were:

1. how to satisfy the need for more sophisticated image analysis software.
2. how to ensure that the investment would accommodate potential expansion and integration with associated information systems.
3. how to provide image access to users (primarily Hospital clinicians from outside Radiology) without printing films.

Although there were no means to view ultrasound images from outside of Radiology, this last issue never surfaced as a concern. In CT and MRI, however, we knew that a far greater clinical population of would be affected.

The approach we took to address these three issues was as follows. Since, at that time, our PACS development team comprised only two people, we recognized that developing our own diagnostic image analysis software was unrealistic. Thus we committed to acquiring a commercial solution. This made the second issue even more important. The ultrasound mini-PACS had not been designed for the greater volumes of image data to be managed in CT and MRI, and it employed file-formats and communication protocols that would not easily accommodate other modalities. Thus, it became clear that a newly designed PACS would be required for CT and MRI. These limitations were address by adopting the digital imaging and communications in medicine (DICOM), version 3.0, standard (see: http://www.nema.org/nema/medical/dicom/).

The re-designed PACS employed several similar concepts that had served us well in ultrasound, but was truly a new system. Unlike the ultrasound system which employed only two servers (one for archival, and one for retrieval), the CT and MRI PACS comprised five types servers, each with different functional roles. One of these was a Web Server, and its role was to address the third issue; namely, how to provide users throughout our Hospital (and even outside our institution) with access to images residing on the PACS.

Rationale for Using the WWW

Given the need to deliver digital images to a wide community of users, we weighed the various options against our constraints. Amongst the latter were financial limitations and practical issues that included how to equip and train the hundreds of users that would require image access. From a technical perspective, we also recognized the need to adopt methods that would include users of as many different computer platforms as possible (eg, Macintosh, IBM PC-compatible, and Unix). The alternative of developing specific software for each one was impractical.

A survey of clinicians within our hospital revealed that many were already equipped with computers (most of which were IBM PC-compatible) and had basic computer skills. Furthermore, the vast majority of these computers were connected to the Hospital's network, which meant that the physical infrastructure was in-place.

The commercial image viewing solutions that were available at that time were few in number and designed for only IBM PC-compatibles. In addition to being exceedingly expensive to distribute such a solution to several hundred users, a relatively small percentage of the computers within our hospital satisfied the minimal configuration requirements of these software packages. (The average Hospital PC was based on an Intel 80486 CPU and was equipped with 8MB of RAM.) Due to our financial limitations, we simply could not upgrade or replace a large number of these PCs.

Thus, since we could not afford a commercial solution and wanted to avoid developing (and maintaining) software for each type of computer platform, we pursued a Web-based solution. The attraction here was that we needed to develop only a single interface that would allow users throughout the Hospital to employ their favorite Web-browser to access our images. Furthermore, as the Web became more widely used in general, we knew that our population of users would become familiar and comfortable with the interface, which meant that user-training would be minimal. From the point of view of developing the required software (i.e., Web pages) on our server, the advantages stemmed from the relative ease (and speed) with which this could be done.

Back to the top.