OR WAIT null SECS
PACS workstation software has evolved considerably over the past 10 years. The marketplace tends to focus on image manipulation tools, but many other factors that are not as apparent should be considered. What are the hardware and operating system
PACS workstation software has evolved considerably over the past 10 years. The marketplace tends to focus on image manipulation tools, but many other factors that are not as apparent should be considered. What are the hardware and operating system requirements of the software? Will it blend in with a hospital's existing computer infrastructure or remain an island unto itself, requiring proprietary parts and maintenance with minimal interaction with other hospital systems? What are the software licensing options: Are they per seat or per concurrent user, or have they been eliminated altogether? The answers to these questions can strongly affect the initial and ongoing costs of a PACS, as well as its degree of flexibility.
PACS workstation software, like most computer software, is usually designed to run on a particular operating system such as Windows, MacOS, Unix, or Linux. Early PACS workstation software was built around Unix, a powerful and stable operating system that has been around for decades. But Unix is most suited to use by experienced computer programmers and software analysts to run "back office" servers.
Although improved user interfaces for Unix have been developed, they have never achieved the user-friendliness and widespread acceptance of Windows, and the average user in a hospital does not know how to navigate a Unix workstation. Because of its narrower market, hardware designed to run Unix applications is more expensive than that designed for Windows.
The allure of Linux is that it is based on Unix but runs on the cheaper commodity PC hardware, and it is free. Its user interface does not have the ease of use and widespread acceptance that Windows does, however.
MacOS is the operating system of Macintosh computers, and it has a very friendly user interface, strong Unix underpinnings, and a substantial consumer following. Nonetheless, it is not as widely accepted as Windows, and the hardware is somewhat more expensive.
Most newer PACS workstations, therefore, run on the PC platform. Some vendors still sell workstations based on Unix, but this is becoming less common. PCs are cheap and flexible, and unlike Unix-based hardware, they can easily be redeployed for other uses if they are no longer needed as a PACS workstation.
Companies that offer their PACS workstation software on multiple platforms may not be able to keep pace with new features. It is time-consuming and expensive for vendors to keep multiple versions of their software up to date, and customers may find that these companies do not move as quickly to offer new features and functionality as vendors that focus on a single platform.
PACS workstation software should be easily deployed over the network. The client and server software is typically updated on a six to 12-month cycle for bug fixes and for new features and functionality. Deploying the upgrades can be tedious and expensive if a technician has to visit each machine personally to load the new version. Programs like pcAnywhere make it possible to update all computers from a single location but still require a technician to manage the process for each one.
In contrast, network-deployed updates require virtually no extra effort. The new version of the software is installed once on the server, and when users next log onto the system, the updates are automatically loaded onto the client computers. This is the most efficient and cost-effective way to keep software up to date.
Five to 10 years ago, hospitals would buy the workstation hardware and software from the PACS vendor for a typical price of $40,000 to $100,000 per workstation. The cost was the same regardless of how often the workstation was used, and when an institution needed to add another workstation, it cost another $40,000 to $100,000. The switch to PC-based workstations has changed pricing dramatically.
Because high-end PC workstations are inexpensive, and off-the-shelf consumer-grade monitors are adequate for many types of radiologic images, it's often possible to deploy the hardware of a PACS workstation for under $3000. All that remains is the cost of the software.
Vendors at first responded to this situation by offering software licenses for each workstation at a cost of $10,000 to $15,000. But it became apparent that paying for a license based on the number of users rather than the number of workstations is more logical. Nor does it make sense that a department with 20 half-time radiologists would pay for twice the number of licenses as a department with 10 full-time radiologists. The licenses came to be based on the number of concurrent users, so the two aforementioned departments would pay the same if they had the same number of radiologists working per day on average.
Many vendors tier their workstation software licenses based on different types of users: full functionality for diagnostic radiologists, reduced functionality for referring clinicians, and still less functionality for technologists and PACS administrators. Each tier is priced accordingly lower. Costs can be controlled somewhat by purchasing only the minimum number of the most expensive licenses for the software required by radiologists and more of the less functional licenses that are adequate for most other users.
All vendors offer some type of Web version of their workstation software, which typically has fewer features but is readily accessible from any PC within the hospital and even outside, depending on security arrangements. While they originally priced the Web version based on the number of concurrent users, many vendors found it easier to simply charge a flat fee for unlimited usage.
The Web version of the software is an add-on for most of the older PACS vendors, while some newer vendors have designed their systems to be Web-based from the start. Those that added it later found that it often replaced the second-tier software designed for referring physicians.
New vendors, without the legacy versions of their software to support and maintain, are developing single, fully functional Web-based versions of their PACS software. In a sense, it's one size fits all. It is easier for a support team to maintain, it simplifies training, and the client application can be customized to some degree, depending on the type of user. A user may specify, for example, that she is a radiologist and would like to see an expanded tool set every time she uses the system, while another user may specify that he is a referring clinician and would prefer a simplified interface. These profiles do not have to be changed on a particular workstation but are obtained from the server whenever and wherever the user logs into the system.
The license fee is usually a one-time payment; there should be no renewal fee for a software license. The cost of upgrades, updates, and revisions, also called obsolescence protection, should be built into the service contract.
Some PACS vendors are beginning to price PACS based on volume. The true costs of operating and servicing a PACS can depend on procedure volume. The greater the number of studies, the greater the amount of support needed from the PACS vendor. Based on the annual procedures volume, a vendor can estimate the number of modalities, the cost of integrating them, the number and types of users, and the cost to support them. The vendor can predict within reason the cost of providing and servicing the system.
This form of pricing eliminates the need to purchase individual software licenses and removes the burden of guessing how many licenses of each type are needed. The total cost of adding a new workstation is reduced to just the price of the hardware, which can range from as little as $1500 for a workstation with a single color monitor to $15,000 for one with dual 3-megapixel gray-scale high-brightness flat panels. Many hospitals will find this type of pricing ideal, as it is far easier to forecast future budgets.
All PACS software can perform the standard functions, although some do it more easily than others. Some vendors' products fall short in the ability to compare two or more studies, whether they are relevant priors of the same modality or complementary images from a different modality. This becomes even more complex when a user tries to compare three MR studies of a patient, each containing 10 or more series.
Ideally, PACS workstation software should allow users to divide up the available monitor real estate however they choose, from one study extending across all screens with one image per screen to each screen containing multiple images from multiple patients. Some systems do not permit display of images from more than one patient at a time; other do permit it, albeit with an onscreen warning that images from more than one patient are about to be displayed. The software should also provide cross-referencing between 2D CT slices to the scout, as well as among sagittal, axial, and coronal CT and MR images.
Workstation software may also fall short in hanging protocols. The user should have the ability to create and save multiple presentation states (first T1s, then proton densities, then T2s, etc.) and to give the system a set of rules for which presentation state to use by default, based on the study type. Creation of hanging protocols can be a tedious process even with good software, but it should not have to be done very often.
Some systems make it difficult to modify protocols, and this can be a source of frustration. While it's helpful if the system can be trained to predict the correct hanging protocol to use by default, it is more important that other protocols can be easily selected via a readily accessible menu during study review.
Workstation software should be highly customizable so that users can work the way they prefer to. When a user is just starting to break in the system, it is convenient to copy hanging protocols and window/level settings from other users or to start off with a small list of system defaults. But each user's list of such settings should be kept restricted to his or her own user profile.
Older systems pooled together everyone's window/level settings, resulting in 10 different entries to choose from just for CT abdomen soft tissue, for example. The list of settings would rapidly become so long as to be cumbersome to use. Individual users should be able to copy another's settings, but their own list of window/level settings should contain only the entries they put there themselves.
Some systems further confuse things by forcing individual lists of window/level settings and hanging protocols to contain many nonremovable systemwide settings, many of which users may never need. Small details such as these can greatly affect the degree of frustration radiologists experience when using the workstation software.
The set of rules that tells the system when to use it by default can be just as complex as arranging the screen layout of a hanging protocol. The rules are generally based on the modality and body part, such as "CT abdomen/pelvis." In certain systems, the rules can be based on secondary descriptors as well, such as "renal stone protocol." The better ones also take into account the presence or absence of a relevant prior exam and can change the hanging protocol to accommodate the prior study if available.
The concept of what constitutes a relevant prior study is a discussion unto itself and is often customizable on an institutional basis. When a hospital's system is installed, the vendor typically asks the administrators a list of questions; for example, whether they consider an esophagram a relevant prior for a chest x-ray or vice versa. This information is generally used to prefetch the relevant priors from the deep archive, which is often on tapes that have slower access times, to the rapidly accessible online cache in preparation for study review (usually the night before a scheduled procedure). But this information is also used by the hanging protocols component to decide whether there is a relevant prior to be displayed alongside the original study. Like the list of window/level settings and hanging protocols, the menu list of all relevant prior studies should be readily accessible during image review.
Other features to look for include the ability to export images to teaching files and create conference lists and 3D capability.
PACS is generally thought of as the system that moves images around within the radiology department in order to get the work of the department done. But two other types of systems that originally developed separately from PACS should now be integrated with it: enterprise image distribution and teleradiology.
Independent enterprise image distribution systems were designed to serve out images from the PACS archive to anywhere within the hospital's network via Web protocols, so any PC in the hospital could view the images. Users with access to the hospital's network from home or clinic via a virtual private network (VPN) connection could see the images there as well. Today, however, all PACS come with a built-in Web server.
Teleradiology, too, was originally thought of as a different product designed to deliver full-fidelity images with a full set of diagnostic viewing tools to a radiologist in a remote location for primary diagnosis. As more radiologists are getting broadband Internet connections, the distinction between "local" and "remote" is becoming slimmer. Nonetheless, broadband Internet connections, especially to distant countries, are considerably slower than local network speeds. Consequently, it is not safe to assume that the same PACS software that functions within the hospital will work when set up on a workstation connected to a remote location via a VPN.
Some vendors offer yet another software package to address those needs, and the degree of integration with the PACS varies. Some can provide the same work list functionality through their teleradiology product; others can't. But a few vendors have pushed the limits of technology by making their PACS workstation software capable of functioning well even over the relatively low bandwidth of an international Internet session. This again simplifies the situation by providing a single uniform platform at both the hospital and the home.
The ideal PACS workstation software would provide a single Web-based product to serve the internal needs of the radiology department, enterprise image distribution, and teleradiology. It should be capable of customization for the user: simplified for the referring clinician or optimized for low bandwidth connections for the teleradiologist. While these requirements sound simple, they are invaluable in today's marketplace, providing considerable improvements to workflow and productivity. Careful inspection and evaluation of PACS offerings today will help differentiate between the systems that offer these tremendous advantages and the lesser PACS solutions of the past.
Workstation software should be designed to present and interact with information from other systems, including the radiology information system, hospital information system, electronic medical record, and dictation system. The first two allow the radiologist to review a patient's medical record without having to reenter the patient's name or medical record number for each system. Integration with the dictation system is key for eliminating the errors and tedium associated with entering the accession number for each dictation. When the PACS workstation and dictation systems are in synch, the radiologist has only to click a button on the screen labeled "Dictate," and the dictation system is automatically queued for the correct accession number for the exam on the screen.
In the days when PACS vendors sold the hardware and software as a bundle, they did not allow installation of other software on their machines. But today the software should be designed to allow installation of other applications on the same machine, including those giving access to electronic medical records, e-mail, teaching files, medical literature, and the paging system. The number of computers required at a reading station can be reduced because the need to set up a separate computer for these other applications is eliminated. The only caveat is current speech recognition software, which may perform better on a separate machine, rather than competing with the PACS software for resources. This may also change, however, as speech recognition software becomes more Web-based and CPU performance continues to improve.
Many aspects of PACS workstation software are not obvious at trade show demonstrations. Any vendor can throw images on a screen and demonstrate simple functions. The factors that separate strong PACS workstation software offerings from weaker ones are usually seen only during actual implementation and use of the system. It is imperative, therefore, to visit sites that have the actual system up and running before making a PACS purchasing decision.
Ask the radiologists who use it how they like it. Have them show you some of the more sophisticated tasks, such as comparing and cross-referencing studies and setting up hanging protocols. Ask them to show you the degree of integration that has been provided with the RIS, HIS, or speech recognition system. Ask how the system differs in functionality in their homes, offices, and other remote locations. Ask the administrators what's involved in setting up a new workstation. Challenge vendors to eliminate the workstation software license fee and include it into the service cost based on procedure volume.
The term "PACS workstation" is becoming an anachronism. Few people would call a computer that runs word processing software a word processing workstation. PACS viewing software is just one of several computer applications that radiologists use to perform image interpretation. It should no longer require a dedicated computer or special hardware, other than a special display system in some circumstances. PACS viewing software is finally evolving to perform well on standard desktop PCs alongside other hospital applications, making it easier to install, use, and maintain.
Dr. Hirschorn is a research fellow at Massachusetts General Hospital/Harvard Medical School and director of radiology informatics at Staten Island University Hospital. Mr. Schultz is senior programming consultant in radiology at MGH and for Partners Healthcare. Dr. Dreyer is vice chair of radiology information services at MGH and an assistant professor of radiology at Harvard Medical School.
WORKSTATIONS: THINGS TO DO BEFORE YOU BUY
?Visit a site that has the workstation in operation; ask the radiologists who use it how they like it.
?Observe how the workstation handles sophisticated tasks such as comparing and cross-referencing studies and setting up hanging protocols.
?Check to see how closely the workstation is integrated with the RIS, HIS, or speech recognition system.
?Ask the administrators what is involved in setting up the new workstation.
?Challenge vendors to eliminate the workstation software license fee and include it in the service cost based on procedure volume.