David Hirschorn, MD

For the past 15 years, most PACS have performed the basic tasks of taking in images, archiving them, sending them to workstations for display, and hopefully not losing them. In the early days of PACS, in the late 1990s, that was considered plenty, given that the predecessor was film. Every system had the ability to zoom and pan and window and level. They could even flip and rotate images, which any picture managing software can do today. Measurement tools were also a given.

Over time, as CT scanners were able to slice thinner and thinner sections of the body, isometric data sets became available and the voxel (volume element) entered the vocabulary of medical imaging. It soon became apparent that new possibilities in manipulating the data to produce multiplanar reformations (MPRs) and maximum intensity projections (MIPs), as well as volume and surface renderings, could be realized.

These images have proven highly useful to the radiologist and referring clinician for both diagnosis and preoperative planning. But the software to perform these 3D renderings was often complex to use and typically found on only one or two separate computers in the department. To manipulate a set of images, they would have to be transferred to one of these workstations, and then someone, either a radiologist or a technician, would have to spend a fair amount of time adjusting the software to obtain a useful view of the data. Afterward, only a small set of key views would be captured and sent back to the PACS for archiving and review and the rest of the 3D model would be thrown away.

There was good reason for this. Radiologists used to look at about 30 slices of the head, about 60 slices of the chest, and about 80 slices of the abdomen and pelvis. This has not changed, even with the advent of multislice CT scanners. In fact, what most of these scanners do is acquire images in razor-thin slices, 0.5 or 0.6 mm, and average them together to make the typical 2.5-mm, 5-mm, or 10-mm–thick slices radiologists are used to seeing. So what was the point of making devices able to acquire the thin slices?

The answer is 3D. And that is why every CT vendor tries to package a 3D workstation with its scanner. It's not just because they want to sell you more; it's because it takes good 3D processing to bring out many of the benefits of the new scanners over older or less advanced ones. But as beautiful as the images are that the vendor may be able to produce on that workstation, it is still physically fixed in one location, typically. And more important, is not integrated with the PACS. Even if the workstation is accessible remotely, it is often disruptive to a radiologist to have to put PACS aside, push an exam to the 3D system, manipulate it there, and then push back to PACS only a few sample 2D captures of the 3D model.

There was a time in the mid-1990s when PACS vendors looked askance at enterprise distribution, the ability to serve out images as web pages to computers at nursing stations and doctors' homes and offices. Some of the bigger vendors thought that it was not important enough to modify a system they had designed to do the work of a radiology department. This led to the growth of several smaller companies that specialized in the enterprise distribution market.

At larger institutions these supplemented the PACS and at some smaller institutions they actually became the PACS. Some of those companies had the foresight to realize that if they didn't become full-blown PACS companies, they would not survive because the established PACS vendors would eventually absorb this niche product into their own. Indeed this has happened. What PACS vendor has no web distribution offering today? And how many companies are there today that offer just enterprise image distribution without PACS?

The same thing is happening with what is called 3D, or advanced visualization, technology. Yesterday's advanced visualization will be considered just visualization tomorrow. It is a natural evolution, and it has already happened in some PACS. More and more, PACS have incorporated not only the basic 3D manipulations of MPR and MIP, but also vessel tracing for angiographic studies, virtual endoscopic views for flying through hollow viscera like the trachea or intestines, and surface rendering for complex fractures such as those of the tibial plateau, including the ability to remove unwanted bones that obscure the view, like the femoral condyles.

Such features were considered the sole domain of 3D companies such as TeraRecon, Vital Images, and the former Voxar. These companies tended to offer simpler to use and sometimes more powerful advanced visualization tools than the CT vendors, but were still disconnected from the PACS. So PACS vendors began incorporating these advanced functions into their systems, and the degree of integration of this functionality is one of the key differentiators in the PACS market today. To that end, the market for stand-alone 3D systems will likely shrink as it, like enterprise distribution, gets assimilated into PACS.

One 3D vendor who has already seen this trend is Visage, which has worked to turn its strong server-based advanced visualization system into a PACS. Having the computer programming expertise to manipulate 3D models of hearts, brains, and everything else, it was fairly straightforward for them to add the other essential workflow elements of work lists and hanging protocols. And like any good 3D PACS vendor, standard 3D renderings are just another part of the hanging protocol, along with the pre- and postcontrast axial images. And like any good 3D vendor, their tools are simplified through the use of tool cards with big buttons that allow the radiologist to rapidly select which type of 3D rendering he wants to see, the same way he might pick a window and a level setting.

Since all of the 3D rendering is done on the server side instead of at the PACS workstation, the speed of the system does not depend on the processing power of the workstation. It will remain fast so long as not too many people are actively using it at the same time (the capacity is planned for ahead of time) and the network connectivity isn't too slow, at least about 2 MBps, which is within range of what most home cable and DSL users have.

Conversely, there is one longtime PACS vendor, Carestream, that has made serious leaps into the 3D space, and there is one 3D functionality it offers that no other PACS vendor has incorporated yet. It is called automatic image registration and it is a big deal. It is an underlying technology in the system that opens the door to comparisons in PACS that radiologists could only guesstimate before.

Whenever a patient is scanned in a CT scanner, the head, for example, is never in the same position. One time the nose may be pointed up and to the left, the next time pointed down and to the right. One of the primary tasks of a radiologist is to compare the current exam to the prior and judge if the bleed or the tumor has changed. But since the head is sliced differently each time it's scanned, we can only estimate the change in our mind's eye, so to speak, trying to account for the difference in patient positioning from exam to exam.

This a perfect place to use the thin slices of the CT scan, the ones that are too thin to be viewed individually, to reslice that data so the two scans line up with each other in 3D space: the nose in one scan points in exactly the same direction as in the other. For the first time, we can really compare two different scans matched up exactly, slice by slice, even though their orientations in 3D space were different at the time of acquisition.

With this foundation, new kinds of comparisons can be made that were previously impossible. Not only can the matched slices be compared side by side, they can even be overlaid on each other with different color maps. And a slider bar can be used to transition the opacity/transparency of one scan or the other, back and forth, to truly see if a brain tumor or lung nodule or kidney mass has changed in size.

Such overlays just never made sense before because the slices of two scans never really matched up with each other. This kind of image registration can be performed not only between two scans from the same modality, but with any other volumetrically acquired modality as well, such as PET or MRI. So a preoperative CT scan, for example, can be directly overlaid on a postoperative MRI.

Automatic image registration used to be found in research packages and even in some clinical 3D workstations. But for the first time it is now built directly into a PACS, and can be made a normal part of a hanging protocol involving relevant priors. This represents a paradigm shift for PACS from 2D image manager to 3D data set visualizer. Without tools such as these built into PACS, much of the potential of modern day multislice CT scanners goes unutilized, and cross-modality comparisons are less refined than they could be.

This evolution of PACS is leading to stratification in the PACS market between the 2D PACS that don't do much more than take in your images, move them around, and hopefully not lose them and the 3D PACS that unlock the full potential of multislice CT, MRI, and PET. (It may even extend to volumetric ultrasound if the technique gains momentum.)

Many vendors are building in other features, such as critical test result management, teaching file functions, and electronic medical record integration. While these are important, they are relatively simple to incorporate, and can be supplemented in other ways outside the PACS. Advanced visualization functionality is therefore one of the main frontiers remaining in PACS. There are many 2D PACS on the market that will likely never evolve into much more than what they are now; their vendors try to sell them on the basis of a cheaper price or a good company name. But for not necessarily much more money, a good 3D PACS can be purchased with technology that will avoid obsolescence a lot longer, and bring visualization of volumetric modalities to the next level.

The days of 2D PACS are numbered. 3D PACS are the way to go for now and into the future.

Articles

For the past 15 years, most PACS have performed the basic tasks of taking in images, archiving them, sending them to workstations for display, and hopefully not losing them.

2D PACS has had its day in the sun, now 3D PACS is moving in

As display technology evolves, radiology departments are presented with a growing variety of PACS displays with increased brightness, sharper contrast, and improved calibration capability. Two developments on their way to the consumer market are likely to offer significant potential benefits for radiologic image visualization.

The first is the DisplayPort digital display interface standard, already available on some new displays. The second is light-emitting diode (LED) backlighting of liquid crystal displays, which can be found today in a select variety of both laptop  computers and desktop displays. 

The DisplayPort standard specifies a digital video and audio interconnect that can be used to connect a computer to a display, including newer television sets. It is poised to replace older connectors such as VGA, DVI, and HDMI cables, as well as component video and S-video cables. As is usual with technological advances, DisplayPort is smaller and faster than its digital predecessor DVI, and the new standard offers much more. 

First, it carries a digital audio signal in addition to the video, eliminating the need for a separate audio connection. Second, it incorporates an auxiliary channel to carry non-video-related data, such as that from universal serial bus devices and flash media cards. Until now, if you wanted to plug the USB cable of your keyboard or mouse into your monitor, you had to complete the chain to the computer by connecting a USB cable between your monitor and your computer. DisplayPort carries non-video-related data without the need for a separate USB cable to the computer. 

As for resolution, DisplayPort can support the same number of pixels as the fastest type of DVI connection (dual-link DVI): 2560 x 1600, which is 4 megapixels. 

The biggest potential benefit to radiologists is in the color depth that DisplayPort supports. It is the first nonproprietary digital standard that allows greater than 8 bits per component. Most displays use a video signal with red, green, and blue components. Color displays, which predominate in radiologic imaging today, typically mix these colors in equal proportions to produce 256 shades of gray. The DICOM Part 14 Grayscale Display Function defines exactly what brightness level these shades of gray should optimally achieve, based on the darkest black and brightest white of the display.

In order to "tune" the display closely to these desired values, it is best to have lots of values to choose from. This approach is analogous to having two digital FM radio tuners, one that allows you to move the dial in increments of 0.2 MHz and one with increments of 0.01 MHz. The second one allows you to pick dial settings much closer to your favorite radio stations than the first. If, over time, some drift of the tuner's internal components occurs such that the original dial settings no longer work well, the second tuner can be finely adjusted to compensate for the drift by rotating the dial one or two more increments in either direction, whereas the first dial can not be finely adjusted. Granted that most of the increments of the second tuner will not be used, because most of them are in between radio stations as opposed to the few that are right on the mark, but the increased number of increments gives the leeway needed for fine tuning.

So, too, with digital video signals. Although PACS software generally tries to display only 256 shades of gray at a time, having more than 256 shades to choose from allows for a much finer tuning of those shades. The DVI ceiling of 8 bits per component limits the available shades of gray to 256. DisplayPort supports up to 16 bits per component, yielding up to 65,000 shades of gray! DisplayPort thus has the potential to give a much tighter calibration of a color display to the DICOM curve.

It should be pointed out, however, that the interconnect between the computer and the display is only one of three components in the display chain, which also includes the graphics adapter (video card) and the display itself. All three of these need to support increased (i.e., greater than 8) bits per component in order to deliver on this promise, so DisplayPort is necessary but not sufficient by itself. Nonetheless, it is an important step in the right direction.

Color LCDs are illuminated by a backlight of white light that shines forward from the back of the display toward the user's face and is filtered and attenuated along the way to produce changes in color and brightness. For years, the predominant source of such backlights has been the cold cathode fluorescent lamp (CCFL), a variation on the common fluorescent lamp ubiquitous in office ceilings. While such lamps produce a lot of light from less energy and with less heat production than their incandescent counterparts, they do have some drawbacks. 

Since the colors of an LCD are produced by filtering the backlight, an LCD can output only colors that were contained in the backlight to begin with. It turns out that the "white" light of CCFLs does not contain as broad a spectrum of colors as the white light of LEDs. Unlike CCFLs, individual LEDs actually produce light of different colors: red, green, and blue. These colors are then mixed to produce white light, offering much greater control over the color spectrum emitted by LED backlit displays. Less of the light produced goes to waste. 

Another limitation of CCFLs is that they operate only together as a unit-the backlight lamps are either all on or all off. This makes it difficult to make the darker areas of the image, such as the air inside the lungs on a chest radiograph, really dark. LEDs, on the other hand, can slice the backlighting into 1-cm squares and selectively illuminate only the areas of the display where light is needed, thereby leaving the darker areas much darker. This produces contrast ratios simply not achievable with CCFL backlights. 

The results can be stunning. I saw at RSNA 2006 a demonstration of such a display, which presented a shining star on a dark sky. The contrast between the star and the sky was so huge that it had almost a 3D effect. This capability may have a large impact on mammography in particular, where significant boosts in contrast can make all the difference in detecting cancer. It may also help in the detection of subtle findings on  radiographs of conditions such as pneumothorax, pneumoperitoneum, subcutaneous gas collections, and vascular and parenchymal calcifications.

So far, several laptop manufacturers have used LED backlights in their products, but the technology has yet to penetrate the mainstream display market. Some obstacles remain in keeping the light output of an array of LEDs uniform over time. Theoret¬ically, LEDs should consume less power than CCFLs, but this has not always been the case in actual products. They should also last longer than fluorescent lamps, but the cost of production of these displays still remains significantly higher. Perhaps as production ramps up, this will change. 

Yet another benefit of this technology is the fact that it is more environmentally friendly. In February 2003, the 

European Union launched its Restriction of Hazardous Substances (RoHS) directive to try to eliminate the use of mercury, lead, and other hazardous wastes from electronic devices. LEDs fare better in such measurements because they are mercury-free, unlike fluorescent lamps.

Both DisplayPort and LED backlighting bode well for radiology. DisplayPort should set the stage for improved monitor calibration and simplified connections. LED backlighting should provide unprecedented degrees of contrast for mammography and general radiography, where it is needed most. It should also ultimately result in displays that have better color capabilities, last longer, consume less power, and are less harmful to the environment. One might say that radiology has a bright future, indeed!

Dr. Hirschorn is a research fellow in radiology informatics at Massachusetts General Hospital/ Harvard Medical School and director of radiology informatics at Staten Island University Hospital. He can be reached at hirschorn.david@mgh.harvard.edu. Mr. Conway is director of radiology informatics at Massachusetts General Hospital.

Display technology advances hold promise for radiology

When PACS were first introduced, the vendor supplied the whole system, from the back-end servers to the front-end diagnostic workstations. Over time, the buyers of these systems realized that none of these PACS vendors actually manufactured the computers and monitors; they just resold them, often at huge markups.

Many hospitals and imaging centers today choose to buy PACS computers themselves and are comfortable integrating them into their networks. But when it comes to monitors, that's a different story, because it's primarily the monitors that distinguish the hardware of a PACS workstation from that of an ordinary computer. They usually make up the bulk of the cost as well.

Fortunately, like the computers and storage components of PACS, monitors have become commoditized. This means that they are cheaper and easier to obtain. Radiology departments can buy them directly from distributors-and in some cases manufacturers-instead of from the PACS vendor. Along with this new opportunity, however, comes the burden of deciding what to buy and of maintaining it.

The first step in deciding what to buy involves choosing between monitors made especially for the medical imaging market and those made for the general consumer market.

During the first decade of commercial PACS availability, no such choice existed. Although generic computers, storage, and networks generally sufficed for medical imaging, the consumer displays of that time did not. The color cathode ray tubes (CRTs) of the last decade had many limitations that made them unsuitable for radiologic image display. One of the biggest was that they simply weren't bright enough to display enough shades of gray for diagnostic interpretation of a chest x-ray. This gave rise to a whole new industry of medical-grade monitors, designed specifically for medical imaging display.

It began with the 1-megapixel gray-scale CRT and ultimately progressed to the 3-MP gray-scale liquid crystal display of today. These displays were made gray scale not because of any inherent problem with color but to enable increased brightness of display. In other words, they simply couldn't make a color display with the same brightness as a gray-scale display. Since 2005 this is no longer the case.

But the psychology of buying monitors specifically designed for medical image display is deeply ingrained, and these monitors still do offer some distinct advantages over general consumer displays, albeit at a much steeper price. Furthermore, only a few models of consumer displays are suitable for medical imaging, and their setup and management is a new experience for most radiology departments.

Typical 3-MP gray-scale displays have features not currently found in their consumer counterparts. First, they have a brightness stability control, which is analogous to a thermostat. This means that if they are set to output 500 cd/m2 (candelas per square meter), they will adjust the voltage and send enough power to the backlight of the display, based on the readings of a built-in light sensor, to produce that brightness. This compensation acts both in the short term, during the warm-up period of the fluorescent lamps when the monitor is first turned on at the beginning of the day, and in the long term, as the lamp output naturally decays over the years.

Second, these displays allow a tight calibration to the DICOM Part 14 Grayscale Display Function. Like a musical instrument, they can be very finely tuned. The displays are usually calibrated at the factory, and, provided they can keep their light output constant, they can often maintain their calibration for long periods of time.

But a pair of these displays typically costs about $12,000, and they cannot display color.

In 2005, the consumer display market debuted a new offering, a 2.3-MP color display with a light output of about 450 cd/m2. It lacks brightness stability control, and its backlight does decay significantly over time, such that it remains suitable for radiography for only about 18 months rather than the five years typical for medical gray-scale displays. However, at roughly one-tenth the price, they are much cheaper to use and provide color capability, which is important for viewing color Doppler ultrasound, nuclear medicine images, functional MRI, 3D, and CAD. What's more, when they reach the end of their useful life for radiography, there are options. They can be relegated to use as viewers for such nonradiographic images as CT, MR, and ultrasound, none of which requires the same high brightness as radiography. Or they can be repurposed as nonimaging monitors for work list, dictation, or even just plain non-PACS desktop displays, where they will remain useful for many more years.

To use these monitors for imaging, however, they must be calibrated, and this requires considerably more effort than is needed for their medically marketed counterparts. And their calibration cannot be as fine, though many would argue that doesn't matter, and to most radiologists the difference is barely noticeable.

Displays designed for medical imaging usually come with a controller board that fits into a slot of the computer. The slot standard for older computers is PCI; for newer computers it's PCI express. But most newer computers come with both types of slot. After physically installing the controller card into the computer, digital visual interface (DVI) cables are typically used to connect the monitors to the controller card.

Next comes the software. Drivers are loaded onto the operating system of the computer to allow it to properly utilize the features of the controller and the displays. At this point, the displays are set to their proper resolution and orientation. The computer desktop is arranged to reflect the physical location of the displays so that the cursor transitions from one monitor to the next smoothly as it moves across the screens.

Then the calibration software is loaded and run. It should allow the computer to check the light output and calibration conformance (the fine tuning) of each display and should record those results in a log. Such checks should be run periodically-quarterly or biannually. If the check fails or if it cannot be run, then technical support should be contacted. The monitor may have to be replaced.

What too many radiology departments do not realize is that these checks will not run on their own; they must be set to do so. And even then the results need to be looked at on a regular basis to recognize and address any problems the calibration conformance checks detect. Too often, both the radiology department and the PACS vendor assume that these expensive displays take care of themselves when in fact they do not. They, too, need care and maintenance, albeit far less than consumer displays.

The setup process is very similar to that of medically marketed displays, with a few key differences. While the display literature may give a list of compatible graphics controllers (aka video cards), none comes with the display. It's up to the buyer to buy one separately. For the 1920 x 1200-pixel displays, the controller that we prefer is the nVidia NVS 440 because it can drive up to four monitors, which is how many we typically have on a PACS workstation. We also buy the DVI Y-splitter cables for the card to send each monitor a DVI signal instead of an analog video graphics array (VGA) signal. VGA signals are subject to electromagnetic interference, which is frequently encountered in hospitals and near imaging equipment.

We then usually attach two simple 19-inch flat-panel displays, for work list and dictation functionality, and two 24-inch 1920 x 1200-pixel displays rotated to portrait orientation. For maximum light output, the displays must be set to maximum resolution, maximum brightness, and the "user preset" color setting. Consumer displays have no built-in photometer, so we then calibrate the displays using VeriLUM from Image Smiths, which requires holding a photometer (which looks like a hockey puck) over each screen for about four minutes. The white level is checked to make sure it is within an acceptable range (400 to 500 cd/m2), and the calibration conformance is checked as well, to make sure it is within an acceptable range ( < 0.075 JND RMSE [just noticeable difference root mean square error]).

Calibration checks as described need to be run quarterly or biannually. A major difference between consumer and medically marketed displays is that the luminance will drop over time with consumer displays. This may have an effect on the calibration conformance, which requires recalibration and, eventually, monitor replacement.

Using these high-brightness consumer displays for PACS is also, to some degree, uncharted territory for the manufacturers. They are not used to customers complaining that they measured the luminance of a display with a photometer and found it to be too low too quickly. Their warranties do not directly address the issue. Though the vendors we have dealt with have been accommodating thus far, we know that they cannot keep exchanging monitors for us endlessly as their backlights decay. Nonetheless, we know that even if a display becomes too dim for radiography and is not eligible for warranty exchange, it can still be repurposed as described above and retain a significant percentage of its value that way.

There is no question that medically marketed displays are optimized for display of radiography and many of the other modalities. While their care and maintenance is considerably simpler than that of consumer displays, there is a burden to maintaining them that is too often ignored by radiology departments and vendors alike, usually due to lack of knowledge. These displays, too, need to be checked periodically.

The use of consumer displays for PACS requires more knowledge when selecting and setting up monitors and video cards, and it takes more work to calibrate and to check that calibration periodically. It will also require more frequent monitor replacement. It is up to the hospital or imaging facility to decide if those trade-offs are worth the color benefits and the drastically lower price.

Dr. Hirschorn is a research fellow in radiology informatics at Massachusetts General Hospital and Harvard Medical School, and director of radiology informatics at Staten Island University Hospital.

Direct monitor purchases save money but require more care

Since the beginning of PACS, one of the main rate-limiting components of the image viewing workstation has been the central processing unit. Other parts of the computer are easy to scale up. Computer memory is cheap and plentiful. It's a simple matter to load a computer up with 4 gigabytes-typical PACS software rarely uses more than a quarter of that. Graphics rendering speeds and the speed of the computer bus (the highway system that connects the parts of the computer) are much faster than most PACS software clients need. But it is the CPU that dictates how fast a radiologist can scroll through a stack of images or manipulate a 3D rendering of the heart.

For at least a decade, it has been possible to put two or more processors into a single computer. Early on, however, many who bought these high-priced systems were disappointed to experience no significant increase in the speed of their applications. The reason? Unless an application was specifically designed to use multiple processors, it did not take advantage of them. To some extent this is still true. What's more, operating systems did not excel at balancing the load of multiple applications on multiple processors. Instead, they tended to overload the first one and underutilize the second one.

Several recent advances in processor technology have pushed processing power to a new level, which can seriously affect the radiologist's daily workload. First, raw processing speed has climbed over the 3-gigahertz (GHz) mark, a threefold increase since five years ago. Second, processors are now built with two and even four cores, allowing them to execute multiple instructions simultaneously and function as multiple virtual processors. Third, operating systems are now sophisticated enough to carefully distribute the load of multiple applications and their processes over the available physical and virtual processors so that no one processor gets overloaded. Fourth, and perhaps most important, the price of such processing power has fallen to the $2500 range, which is easily justifiable for a PACS workstation computer.

To take advantage of the multiple processor environment, an application should be multithreaded. This is a programming technique that allows the computer to begin a new task before the old one is completed. Newer PACS software is written in languages that make effective use of this environment. Older PACS software cannot do the same. However, even with older PACS viewing software, today's processors and operating systems still manage to distribute their load somewhat.

The other CPU-hungry radiologist application is speech recognition software. In order to deliver real-time speech recognition, which means that a radiologist can see her words within a few seconds of speaking them, the speech engine needs to move fast. It needs to quickly sift through the thousands of words in its lexicon to find the ones with the highest probability of matching what was said. Even by today's standards, this is computationally intense. This high demand on the processor has been the biggest barrier to combining speech recognition and PACS viewing software on one computer. That barrier has finally fallen.

Even if neither the PACS software nor the speech recognition software is written in a multithreaded fashion, today's multiprocessor computers can distribute their load appropriately. What does this mean to the radiologist? It means that a single computer, with a single mouse or other pointing device and a single keyboard, can run both PACS and speech recognition software, plus whatever else a radiologist might need such as e-mail, Web browsing, or a work list tool. It means no more confusion over which keyboard goes with which computer or which mouse controls which screen. It also cuts in half the number of computers that the radiology department needs to maintain. Remote installations for teleradiology are no longer forced to use a router to share an Internet connection. All of the radiologist's applications can reside on one machine, which can serve as a single cockpit to get the work done.

At Staten Island University Hospital (SIUH), we combined our PACS and speech recognition software on one of these new fast computers. The new computer was a Dell Precision 690 with two physical 3-GHz processors, each with dual core and with hyperthreading activated (Figure 1). The Windows XP operating system saw this configuration as eight virtual processors in all.

First, we opened a 100-slice abdominal-pelvic CT scan using the GE Centricity PACS 2.0 RA 1000 viewing software, which was configured to occupy only the two right monitors. The images were magnified to full screen and then scrolled through one at a time as a stack at full speed by whipping the mouse up and down rapidly. Such an operation is one of the most taxing on the CPU.

The response time of the system was well within reason and noticeably better than on our other computers, which are older and have a single CPU with one core. This result was not surprising. Nor was it surprising that the system performed perfectly well at achieving real-time speech recognition using MedQuist's SpeechQ for Radiology. Words appeared on the screen within one to two seconds after being spoken.

During the PACS scrolling test, one of the eight CPU graphs peaked at about 90% utilization with marginal activity on one of the other CPU graphs. During the speech recognition test, another of the CPU graphs peaked at only about 50% utilization, with yet another peaking at 20% activity. The key test, however, was using PACS and speech recognition at the same time. To our surprise and delight, neither function slowed in performance at all. We could scroll and dictate, dictate and scroll, and the images kept on moving as fast as before and the words appeared in the dictation window as quickly as before.

During this full-throttle testing, the system managed to keep the CPU utilization reasonably well distributed over the eight processor graphs, with no one processor exceeding 90%. This test was repeated many times with the same result. We have decided to use this hardware platform for all new workstations. Likewise, the Massachusetts General Hospital radiology department plans to deploy all of its new Agfa IMPAX PACS workstations on this platform. It also plans to run Commissure's RadWhere on this standardized platform for speech recognition, work lists, and advanced communication functions.

For balance, we tried conducting the same test at SIUH on a Dell Dimension 9100, which has a single 2.7-GHz processor, dual core, and no hyperthreading (Figure 2). The operating system saw this as only two virtual processors. In this case, performance under the full-throttle test was adequate, but applications showed the strain. Scrolling in PACS slowed down by about 30%, and speech recognition also slowed noticeably, although without any change in accuracy. However, under normal dictation conditions of intermittent scrolling and intermittent dictating, which only sometimes overlapped, performance was more than adequate. The speech engine was able to catch up during the normal pauses in dictation, and dictation only occasionally slowed down scrolling.

To round out the picture, we also tried the test on a Hewlett-Packard Evo D7100 with a single 1.8-GHz processor with a single core running Windows 2000. The computer slowed after a few seconds and then completely froze and rebooted itself during the test-an unsuccessful test by any measure.

This trend in processing power can have an untoward effect on PACS software that can not multithread. In an effort to reduce power consumption and heat production, companies such as Intel and AMD are producing processors that have more and more cores but run at lower clock speeds. The goal is to reduce the electrical overhead while preserving processing speed by adding more cores. That's fine if the software applications can make effective use of the multiple cores, and most modern software can. But legacy systems may actually run slower on these newer processors because they can use only one of the cores on one of the physical processors. Imagine paying a premium for the latest processor only to find your PACS software runs slower!

Curious to hear their reaction, I contacted both MedQuist and Commissure representatives to let them know how well their software runs on the same machine as PACS.

"In the past, when speech recognition and PACS have operated on a single workstation, there was always uncertainty and instabilities around shared system resources between the two resource-intensive applications," said Michael Mardini, CEO of Commissure. "With the latest developments in CPU design, we have overcome a significant hurdle to reliably deliver integrated workflow solutions in a single box environment."

Frank Lavell, CEO of MedQuist, also responded.

"With SpeechQ for Radiology, MedQuist has focused on enhancing the radiologist's workflow. Integrating speech recognition with PACS has been vital to improving that workflow and patient care," he said. "Our engineers are working to make this process as seamless as possible to the end user. We are excited at the results from the Staten Island tests."

Although strong processing power is necessary to run these multiple applications, it is not sufficient. You can't navigate the dictation application, the work list, and the image visualization all on one monitor, no matter how large. Fortunately, attaching multiple monitors to a computer has become much simpler over the past few years. A four-head video card such as the NVidia NVS 440 can run four monitors, each up to 2.3 megapixels (1200 x 1920).

Alternatively, a variety of inexpensive dual-head video cards are available that can run two monitors. Most higher-end computers can handle up to four or five expansion cards of any type, including video cards. Thus, whether using consumer displays for image viewing or displays that are specifically marketed for radiology, it is not too hard to add another display or two for speech recognition and work list functionality. Screen real estate is now cheaper than ever. A 19-inch color flat panel can be had for about $200.

The ability to combine PACS visualization software and speech recognition on one computer represents a breakthrough in terms of simplifying the work environment for radiologists. As these applications begin to share physical resources such as the CPU and memory, they are also beginning to demonstrate higher levels of integration, such as the ability to share patient context-no more having to type in the accession number to synchronize applications. Such trends could reduce medical errors and should result in greater efficiency and satisfaction in the radiologic interpretation process.

Since the beginning of PACS, one of the main rate-limiting components of the image viewing workstation has been the central processing unit. Other parts of the computer are easy to scale up. Computer memory is cheap and plentiful.

Tech advances permit PACS, speech tools on one computer

 Extending access to radiology images and reports has always been a challenge. When PACS was first introduced in the early 1990s, it required costly dedicated workstations for viewing images and reports. Even radiology information systems, in use since the '70s, required a "dumb" terminal or terminal emulation software on a PC to view reports. These limitations prevented most clinicians outside the radiology department from reaping the benefits of digital imaging and reporting.

When the Web became popularized in 1995, a few companies saw the future and introduced systems that could take DICOM images, convert them to the common JPEG format, and distribute them along with the report text (when available) via the Web. This provided a huge boost to referring clinician access. Now everyone in the hospital could see that CT scan within seconds of its completion without having to trudge to a PACS workstation in radiology.

By the end of the '90s, even the "big iron" PACS vendors realized that having a Web interface to PACS was quickly becoming a necessity. Some Web distribution companies continued to develop a symbiotic relationship with the bigger PACS vendors, providing Web access to the archive when the PACS vendor could not. Because their client applications were lighter and could be installed on regular PCs, many RIS vendors did not see as great a need to "Webify" their applications. To this day, most RIS user interfaces are not Web-based.

Despite these advances, access ended at the limits of the hospital network in most cases. If your office was on the hospital's network, then you could see images and reports; if not, then you could not. You could forget about access from home or a remote office or another hospital. Further, hospitals realized that their networks had to be protected from hackers and viruses. They set up firewalls between their networks and the public Internet that prevented all access from the outside world, legitimate or not.

Of course, the problem of remote access was not unique to radiology or even healthcare, and virtual private networks were created to address this issue. In most cases, a firewall only allows users within the hospital to request information from or initiate communication with the outside world, but not vice versa. This setup is like a pay phone that you can use to call anywhere but does not allow incoming calls.

The VPN appliance called a concentrator is the device that mediates traffic initiated from the outside world toward the hospital. Like any good sentry, it first requires that the user be authenticated via any combination of password, electronic certificate, USB key, and SecurID card (a small handheld device that displays a number that changes every minute). Once authenticated, the outside user's computer becomes connected to the hospital's internal network through a secure encrypted tunneling protocol, usually IP Security Protocol (IPSec). Once you're in, you're in. Your home computer now functions as if it were within the walls of the hospital, with all the benefits and restrictions of that network.

While plenty of systems within a hospital contain information that might be useful to a physician at home or in a remote office, historically the radiology department has driven the desire for remote access. A physician who wanted to know the latest potassium level for a patient, for example, could just call the laboratory to find out. This solution did not work with radiologic images.

Dr. Eliot Siegel of the Baltimore VA Medical Center jokes about this PACS downtime scenario: When the referring clinician calls to ask what the liver lesion looks like, the radiologist replies, "Picture a sunny day, with the sun just over the horizon, and the birds swooping down from the heavens . . ."

You get the idea-there's no substitute for seeing the images yourself. Furthermore, the radiologist shortage, which is easing but still present, and the increasing availability of teleradiology services contribute to the need for remote access to meet growing demand for radiology services. Remote access also increases opportunities for radiologists to confer with one another about difficult cases.

VPNs are powerful all-purpose tools, but they come with a price in terms of implementation and support. For most end users in a hospital environment, they are too powerful. Partners HealthCare in Boston manages information technology for Massachusetts General Hospital, Brigham and Women's Hospital, and eight other healthcare facilities/systems. Partners needs several full-time equivalent employees to maintain the VPN hardware and software, validate applications functioning through it, and deal with the constant influx of new users throughout the year. Installing VPN client software is never easy. Conflicts with other applications, antivirus software, personal firewalls, and home routers are common.

Some brands of VPN clients can't even coexist with others on the same computer. Any attempt to install a second VPN client can prevent your computer from starting Windows at all. To put it simply, VPNs often don't play well with each other or with other software on your computer. A physician who works at more than one hospital and seeks remote access to both from the same home computer may be out of luck.

Most VPNs are configured to give the user access to everything on the network, including network printers that are nowhere near you, and servers to which you can only cause harm. Such unnecessary access is a security risk, especially should access to a VPN account fall into the wrong hands.

Some hospital systems, such as Partners, implemented VPNs anyway because it was the only way to provide the needed access securely. Some decided to deploy applications such as the PACS Web server on the Internet, relying upon the authentication and encryption of the application itself for security. Others saw this approach as too risky but just didn't have the resources to handle a VPN, and they decided that remote access would have to wait until something better came along. Now, finally, that day has arrived.

The Secure Sockets Layer protocol has been around for over 10 years. People around the world use SSL for secure communication over the Web for credit card purchases and bank transactions. Rather than giving you full access to the bank's internal network, it allows you to access only your own account, and that access terminates when you close your Web browser or the session times out. It makes you prove who you are with a password and encrypts the information passing back and forth between you and the bank, but it requires no special software installation. The necessary components are already there in the Web browser, and they work for every bank and every merchant without conflicts.

Theoretically, SSL technology can be applied to every information server in the hospital, including the PACS Web viewer, the RIS Web viewer, the voice recognition Web interface, the HIS Web interface, the laboratory Web interface, and so on. But this requires each of these individual applications to employ SSL, and each of these servers must be put on the Internet for access, where they will basically serve as fresh meat for hackers and viruses (Figure 1). Hospitals, and indeed most large facilities, minimize the number of points of physical entry and exit for visitors and employees for security reasons. Likewise, it is better to maintain one point on the network for remote access and then deploy all of those applications through that point. Such a solution, called an SSL VPN, has recently become available (Figure 2) (http:/www.net-security.org/article.php?id=595).

A hospital using an SSL VPN can get secure authenticated access with no special software to deploy. In effect, the hospital can create a secure Web portal, a single point of access on the Web to reach the protected internal resources of the hospital. What a user initially sees may look something like Figure 3. At the discretion of the hospital's IS department, the user provides a combination of password and any of the other authentication methods described above. This process should require a relatively high level of security-more complex passwords and perhaps one of the other methods-because it is the main barrier standing between unwanted visitors and your hospital's internal information sources.

The user is then presented with a list of available applications and other resources such as network drives. In order to access the PACS, for example, the user will still have to provide a password for that application, but the process will be no different from that of a user sitting at a computer in the hospital.

One advantage of this approach is that the user has access to only those applications that are part of that individual's profile, and these can be set on a per user or per group basis. In a typical traditional VPN environment, all access is permitted except that which is explicitly denied. In an SSL VPN environment, all access is denied except that which is explicitly permitted. Traditional VPNs provide access at the network level, whereas SSL VPNs provide access at the application level, where it is much easier to manage. Unlike traditional VPNs, which either grant or deny access and then ignore the ensuing activity over the connection, SSL VPNs actually mediate the entire session.

To the PACS application, for example, the SSL VPN is just another user on the system; the PACS is unaware that the SSL VPN is actually serving as a proxy for a remote user. Thus, the PACS application needs no special modification to support this type of access. More important, it allows the SSL VPN to actively monitor and record every detail of every transaction.

There are three A's of network security. The first two, authentication and authorization, were discussed above. The mediation process provides the third one: audit. If a security breach is suspected, the SSL VPN has an audit trail that can trace the suspicious activity to help identify its source.

PACS, HIS, RIS, and electronic medical record user interfaces range in complexity from simple Web-based designs to heavy CD-based installations that can be hard to configure and have poor tolerance for the comparatively low bandwidth of the Internet. Those that are purely Web-based can be easily deployed via an SSL VPN with "zero footprint." That is, not only does the connection itself not require the installation and configuration of a VPN client from a CD, but there's not even the smallest bit of special code to download or a cookie to store on your hard drive.

In effect, doctors can use a computer with the tightest security settings, which will not allow them to make the slightest modification to the system, and still be able to use the SSL VPN. Many Windows-based applications can be deployed in much the same way via a presentation server on the hospital side and a Web browser plug-in on the user side. Citrix Metaframe is one popular example of this technology. As with all SSL connections, your session ends when you close the browser. If you close down your Web browser after checking your bank account and then try to go back in, you'll find you have to log in again because your first session has ended. This is also the case with simple SSL VPN connections.

For applications that do not have a Web-based user interface and need to communicate over non-Web protocols, such as some 3D rendering packages, surgical planning software, and streaming videoconferencing, there is an extension of the SSL VPN idea. SSL tunneling allows these bulkier applications to conduct their non-Web protocol communications through a small software-based session manager that is downloaded the first time the user accesses the hospital's system.

Download of this applet does require some level of user permissions on the remote computer, but it's a small price to pay for the access it provides. The session manager keeps you connected even after you close your Web browser until you log out or your session expires. (An icon typically resides in the system tray in the right end of the taskbar to indicate your connection status.) Moreover, it acts as an adjunct to, rather than a substitute for, your regular connection to the Internet. If you start an application that needs to connect to one of the hospital's internal resources-the PACS archive, for example-the session manager takes notice and handles the connection. But if you are simply trying to browse a public Web site, it ignores your request and allows your regular Internet connection to handle it.

This is fundamentally different from the way traditional VPNs operate. Almost every user of a traditional VPN has at one time tried to print to a local networked printer and failed, forgetting that a user connected to a remote location via VPN is no longer on the local network. With a traditional VPN you are either "there" (on the hospital's network) when connected, or "here" (on your local home or office network) when not connected, but never both at the same time. With managed SSL tunneling sessions, in effect you can be both there and here at the same time.

SSL tunneling ultimately encapsulates all network traffic, regardless of the original protocol, into a Web protocol. This adds to security because network administrators need to monitor only one protocol: the Web protocol that everyone uses for most everything else. This function is similar to the single point of entry, except in this case it's a single type of entry.

Partners HealthCare began providing widespread VPN access in 1999, and it has dealt with the expansion of the system to include hundreds of users. This has been a huge support burden, and the group began test deployment of an SSL VPN last year. It has met with measured success thus far, and the plan is to gradually convert most VPN users to this service over the next few years. The zero

footprint model will be deployed as much as possible. For situations in which thick client access over non-Web protocols is necessary, the managed session approach will be used. Traditional IPSec VPN access will remain, but only when direct access to the network is absolutely necessary, as for vendors who need direct access to the machines they support.

Staten Island University Hospital in New York City is taking a similar approach. The hospital has an IPSec VPN, but it is used only by vendors and technical support personnel. SIUH has already tested and validated its SSL VPN solution with the Web interface of its PACS and new RIS, which is inherently Web-based.

For hospitals that have been holding back on remote access because traditional VPNs seemed too difficult to manage, now is a great time to jump in with SSL VPNs.

The authors wish to acknowledge Christopher Gervais, senior research analyst/technologist at Partners HealthCare, and Bill Rears, director of PC LAN services at Staten Island University Hospital, for their valuable input to this article.