In the late 1970s and early 1980s, Colorado Video was nearly the only vendor of technology that could transmit images from point A to point B via standard telephone lines. The company provided analog video-capture capability, capturing images using what was, quite literally, a basic camera-on-a-stick approach. Depending on the site, it might have involved a video camera mounted on a tripod and focused on a light box in the corner of the reading room or a single-film light box, facing upward, with a video camera rigged directly above it and pointing. This configuration was often used in a spare room in order to make better use of what little space was available (and to avoid knocking over the tripod).
These early systems were considered state of the art at the time. So was the amazing speed of image transmission; transmission times of 5 to 10 minutes per film were not uncommon. Neither should it be forgotten that the films involved were either CT images on film (formatted 12 per sheet) or single radiographs.
In 1985, the first digital teleradiology system was introduced. It did not take long for new entrants to join the industry, although teleradiology was a very new concept to both the sales forces and the radiologists at the time. Most radiologists seemed to be more interested in combining the teleradiology with other personal applications instead of addressing the need for teleradiology alone.
Early Days of PACS
The first picture archiving and communications system (PACS) was introduced to the world in November 1984 at the annual Chicago meeting of the Radiological Society of North America (RSNA). Naturally, this drew a fair amount of attention, but there was no consensus. Many radiologists were lukewarm toward the idea of soft-copy reading, and with good reason. The state-of-the-art monitor of the time was a 1,000-line non-interlaced system that was not ready for the primary reading of chest images, but that might be considered for CT and MRI interpretation. Several radiologists said that they were not sure that they would have the volumes needed to justify this technology. The technology has changed considerably since then, but the cost-justification concern is still present.
Many vendors perceived a new opportunity to secure long-term business by locking an institution into a future relationship through PACS. They emphasized long-term support, upgrades, and new relationships in which both parties moved forward as partners.
One vendor went so far as to express severe displeasure at anyone having the capability to query its drives for patient data. Therein lay the fundamental problem encountered in the development of what is now known as the Digital Imaging and Communications in Medicine (DICOM) 3.0 standard. Vendors did not believe a leveling of the playing field was in their best interest. Given the fact that, at the time, one point of radiology equipment market share represented $44 million, some respect must be given to that defensive position. A free market economy is not based on free exchange among competitors of what is perceived as proprietary information.
The Need for Standards
Given the conflict between the proprietary outputs of the equipment of each imaging vendor and the new interest in integrating imaging devices for the good of radiology, it became apparent to the industry that some sort of standard should be developed. In 1983, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) joined hands, under the supervision of the US federal government, to meet collectively and begin such an effort.
This effort involved many of the primary vendors of radiology equipment and several representatives of the ACR, most of whom were staff members of teaching institutions. Face to face and in public, each vendor expressed a desire to see a standard agreed upon and developed. In reality, the politics of such an environment allowed only minor progress during the next several years.
In 1985, what became known as version 1.0 of the ACR/NEMA standard was released. This standard did not even conform to the International Standards Organization model. What it agreed upon was a point-to-point communication protocol implementing the use of a 50-pin plug. The protocol was defined and was documented as well as it could be, given the politics of the negotiating table, but deploying this interface was very costly due to its low volume and high nonrecurring engineering charges. To implement such a standard interface between any two imaging devices required not only the expense of the nonstandard connector, but the cooperation of the vendor of the equipment being integrated.
Keep in mind that, in order to develop the software for such an interface, developers had to obtain the proprietary formats and communications protocols from the equipment vendors. Obtaining this information was akin to securing a top-secret security clearance from the US Department of Defense. The vendors were very reluctant to provide anyone with such privileged information; of course, they could not say so in public. The most that they would say in public was that they would have to check with particular individuals who might have the authority needed to sign a document releasing the needed information. If the petitioner was lucky enough to get the signature, after explaining to at least two people what would be done with the information, it was then necessary to determine who had the information and whether it was well documented.
Version 2.0 of the ACR/NEMA standard did not differ much from version 1.0. The second version was released in 1988. The significant difference between the two versions was the ability of the standard to accommodate the laser cameras that were then new to the market. New definitions allowed such functions as multiple copies and the variable formatting of images on a single piece of film. It was after the release of version 2.0 that the ACR organized an effort encouraging institutions to require conformance to the ACR/NEMA standard. This effort resulted in the initial awareness by hospitals that they could require adherence to standards of their vendors.
The First Shakeout
The early casualties of the PACS market included four highly respected large companies. Each of these four powerhouses spent hundreds of millions of dollars in an effort to capture what was becoming the next wave of imaging technology and a new frontier. With a high-quality marketing effort behind this new concept, who could go wrong? Only now, 13 years later, are organizations finally beginning to understand and justify the deployment of PACS.
One effort combined the imaging expertise of one major vendor with the communications expertise of AT&T. Both entities invested millions in a project that was widely believed to provide the answer to the problem of integrating diverse imaging modalities from multiple vendors. In a separate effort, IBM and another vendor developed a PACS product line that had, as a primary requirement, the stipulation that the PACS would work only with that vendor’s imaging equipment. Both product lines were withdrawn within the first 2 years of being shown at the annual RSNA meeting.
It became obvious to many people that PACS was very expensive and was still not quite ready for broad deployment. Involvement with PACS was, however, a tremendous education for many within the industry. The attempts to launch proprietary systems were unfortunate, but they did create a demand for direct digital interfaces that would work beyond the dominant-vendor-controlled radiology departments. These new products on the market requiring direct digital interfaces — along with the federal government’s Medical Diagnostic Imaging Support (MDIS) project — greatly influenced the development of the DICOM 3.0 standard.
DICOM 3.0
Version 3.0 of the ACR/NEMA standard was introduced as DICOM 3.0 at the 1992 RSNA meeting. It was intended as the answer to all nagging connectivity problems. It has allowed interfacing issues to be addressed more effectively, but has been no panacea. A large number of institutions did not know the basics of DICOM, and many ultimately accepted the inaccurate compliance claims of vendors. Unfortunately, they did not admit such mistakes so that others could learn from them.
Progress has been made, but not as much as could have been made through informed acquisitions. As a whole, health care is no less than 5 years behind other industries in the state of its information systems.
MiniPACS Solutions
New entrants into the industry continued to emerge, bringing very innovative, cost-effective approaches to PACS. Soon, what have since become known as miniPACS solutions appeared, demonstrating how effective a miniPACS for, for instance, ultrasound could be.
While one vendor captured the ultrasound miniPACS market, other new vendors redefined opportunities for networking. The deployment of networks in intensive care units (ICUs) and emergency departments slowly justified the continued interest in PACS (and, ultimately, much larger deployments).
The PACS industry saw failures as well as successes. It took one major vendor, for example, more than one attempt to get it right. The source of the system that it sells today should also be remembered. The world’s first PACS traded hands in 1985 a year after its debut. After that vendor upgraded the system and made it more effective, it was then sold to Loral, which bought it in an effort to bolster its federal MDIS bid. Loral won the bid, deployed the systems required by the MDIS contract, and then sold the system to yet another vendor. Given a couple of upgrades, the same fundamental architecture that was there in 1992 still exists today, complete with Macintosh interfaces.
All vendors describe their architectures as open, but how well do they comply? A primary goal of the DICOM Committee has been to permit interoperability via DICOM interfaces. This industry often states that its goal is to deploy standards-based solutions. How well is it complying with its own goals?
Users should look at the systems being deployed today for PACS networks (and for hospital information system networks, as well). How well will a radiology information system (RIS) from one of the freestanding RIS vendors integrate with the SMS, Meditech, or HBOC systems? If the facility wants to integrate a PACS using a Health Level 7 interface, it is likely to need an interface engine or the new tools available from PACS vendors.
The Impact of the Web
Few developments have affected society as much as has the World Wide Web. It is a method of communication that is here to stay. As recently as a few years ago, health care information officers were afraid to deploy patient information over the Web. Now that fears have been alleviated to some degree through the deployment of firewalls and more advanced security measures, the recent trend seems to favor the use of the Web for image and report distribution.
Nonetheless, facilities considering Web use still need a clear idea of what they want to do with images when they get them. This determines technical requirements, including the hardware and software needed to view any image adequately. For example, in an ICU, most images are viewed in order to verify tube placement or detect bleeding. Radiologists are not performing final interpretations and generating reports in this environment. Therefore, a monitor having a pixel count of 1,000×1,000 (a 1K monitor) will work very well, cutting costs significantly.
In sending images to a Web server, review what will be done with the images. In most cases, these images are being made available to referring physicians. Do these physicians require high-end 2K monitors? Probably not, but it does not cost more to send the full data set so why limit any physician’s ability to review the full fidelity of the data set file?
With new Web-browser technology, there is no limit to anyone’s ability to view images at high resolutions. Images can be reformatted today in such a way that they can be viewed at the original acquisition resolution or at a minimized resolution, depending on the hardware and software installed. In fact, one vendor’s new viewing software automatically detects display capabilities and allows the user to review images at the resolutions of their choice.
For image distribution, many avenues are available. New display stations use Web capabilities, and dedicated display stations are designed for many of the PACS on the market. What is required is a thorough understanding of who needs access to the images.
It is not uncommon, today, to distribute images and reports throughout an entire campus on a local-area network using common desktop computers with varying display capabilities. The same images and reports are then made available to referring physicians via image-distribution (Web) server. This capability greatly enhances an institution’s marketing arm.
CONCLUSION
Radiology’s ability to distribute images has come a long way, but there is still some distance to be traveled and some obstacles to be overcome. Not all of them are technology centered. Moving ahead in the deployment of a PACS or image-distribution system requires considerable thought and careful planning. While cost-justification issues have become easier to address and overcome, executing PACS projects within common political environments often poses one of the greatest challenges to architects of a filmless environment.
