Building the Best RFP: Part 2 -- Display software

Jul 15, 2007

AuntMinnie.com is pleased to present the second installment in the Building the Best RFP series. This new series of articles focuses on the major technology issues in choosing the right PACS, and each edition will include the precise wording you might use in an RFP to a vendor. For part one on directory architecture, click here.

PACS vendors can package PACS display software in numerous ways, the most common of which are separate software packaging and collective software packaging.

Separate software packaging: This approach has multiple, separate display software packages, one for each major class of user: radiologist (diagnostic), technologist (quality control), system administrator, specialist (surgeon), and generalist. Each unique software package is optimized for the specific user class, including or eliminating features or functions based on the needs of the typical user in each class. The graphical user interface (GUI) for each class of display software may differ.
Collective software packaging: This type has only one display software package, which is a collection of all the display features and functions supported by the PACS. Each major class of user is granted access to only those specific display features/functions required to perform its tasks. The GUI is identical across all display classes.

Early generations of PACS featured two distinct display stations: "diagnostic" (used by radiologists) and "clinical" (used by referring physicians). The clinical station was frequently "dumbed-down" and limited to basic display features, to make it easier for the clinicians to use. At that point in time, PACS display stations were custom-built hardware platforms, meaning big and expensive.

When the "Web viewer" was created to make image viewing more affordable throughout the hospital, the nature of its software and PC hardware resulted in a significantly different GUI. Now there were three classes of display: diagnostic, clinical, and Web, each featuring different applications, each sporting a different GUI.

Over time, the Web viewer software became more and more sophisticated, and the PC and network hardware became faster and faster. The old "clinical" display was replaced by the Web viewer. Eventually, even the "diagnostic" display could be based on a high-end PC Web viewer. Now we began to hear the term "Web-based PACS," the implication being that all the displays are merely variations of a Web viewer.

By the time each PACS vendor replaced its older generation of PACS with its new generation, separate software packaging had been replaced with collective software packaging.

The most current generation of PACS has one master superset of display functionality, featuring one common GUI. A display class is created by enabling or disabling specific display functions. Better yet, in some PACS, users can be allowed to access specific tools based on their individual needs, resulting in hundreds of display configurations.

While this degree of customization initially gave the vendors fits with their pricing strategy, they eventually stopped charging per display station and started charging per concurrent type of user (radiologist, clinician, and technologist). Better yet, some vendors now price their PACS software based entirely on the number of studies under management and grant an unlimited number of display users.

Collective software packaging has many obvious advantages:

Individualized display applications
User access to exactly what tools are required
Simplified training and user experience, as all displays look and behave exactly the same
Affordable pricing models
Simplified maintenance and support

Perhaps even more important than packaging is where the display software runs and how it is installed.

Those distinct diagnostic and clinical packages of yesteryear actually ran on the dedicated display station hardware as so called "fat-client" packages. The diagnostic and clinical software was physically installed on each display station, as was each upgrade. Maintaining these displays was a lot of work.

In contrast, a single copy of Web viewer software would run on the Web server, and only a small applet or subset of software would actually be running on the Web viewer (PC). Furthermore, Web viewer software would automatically self-install upon first time log-on to the Web server. This self-installation greatly simplified maintenance and revision control.

Before jumping to the conclusion that a single copy of software running on a central server is the ideal, let's remember how feature-rich our PACS display software has become. It's not unusual to find multiple specialty applications integrated into both diagnostic and specialist display software.

Applications such as multiplanar reformatting (MPR), maximum intensity projection (MIP), volume rendering, surgical planning, and voice recognition require huge processor and memory resources to run efficiently. The fat-client model may be difficult to maintain, but it is typically much faster than its thin-client counterpart. In most computer applications, and medical imaging is certainly no exception, performance is the leading concern.

The best of both worlds

There is a best-of-both-worlds scenario. Many of the current-generation PACS are often described as Web-based, suggesting that all classes of displays are thin-client, when in fact the fully featured classes of display software (diagnostic, specialist) are in fact fat-client.

The single master copy of the collective (display) software package is installed on the main PACS server, but all classes of display software are automatically downloaded to the individual display platforms upon first log-on to the server. The fully featured classes of display software run on the local display platform, but they are "Web-delivered" to the hardware.

The fact that the original copy (and revisions) of the display software are automatically downloaded to the display hardware is referred to as zero administration, because the IT department only has to maintain the master copy on the main server. This approach to display software is the best of both worlds: fat-client performance with zero administration.

In summary, look for the following six main features of the display software in your next PACS:

Collective software packaging: all classes of display are derivatives from one master copy that resides on the main PACS server.
All classes of display look and behave the same ... same GUI.
Individual user display packages are created through assignment of privileges.
The fully featured display packages are fat-client to provide the highest performance.
All classes of display software (and revisions) are automatically Web-delivered to the display platforms.
Each user's display profile (assigned features/functions) "float," meaning they are accessible from any physical display station.

Relevant RFP Q&A

In this section of the article, we look at sample RFP questions, and how to evaluate vendor responses. Notice in the following sample RFP questions how multiple-choice options are offered. This tactic helps to eliminate any chance of the vendor misunderstanding the issue or weasel-wording the response.

Which of the following best describes the structure (packaging) of the diagnostic display software? Describe any discrepancies.
1. Diagnostic display software is manually installed/loaded onto the display platform (PC) and entire software application runs on the display platform.
2. A master copy of the diagnostic software is maintained on the main server. Diagnostic display software is automatically installed/loaded onto the display platform (PC) upon first log-on to main server and entire software application runs on the display platform.
3. Master copy of diagnostic display software is hosted by and runs on the main server. A simple display applet is automatically installed/loaded upon first log-on to main server. Majority of pixel data manipulations and processing is executed on the main server and only the resultant display page is downloaded by the applet and displayed on the local display hardware.
Good response:
The B response is "Web-delivered" and represents zero administration, yet provides best performance.

Bad responses:
The A response will mean good performance, but high maintenance and possibly mean that the software is older-generation, and possibly scheduled for expensive replacement. The C response means thin client, and probably less-than-ideal performance.
The GUI for all classes of display station should be identical. Which of the following descriptions best fits the various classes of display stations you are proposing?
1. There is only one display application (with one GUI) from which all classes of display station are derived. Each class of display is created from this single application by granting or restricting user privileges.
2. There are multiple different display applications (i.e., diagnostic, clinical, Web), but the GUI of the clinical or Web class closely resembles that of the diagnostic class. Some applications or user operations behave slightly differently or some tool bars or icons are different.
3. There are multiple different display applications, each with their own unique and different GUI.
Good response:
A is the ideal response -- easier training, remembering, and maintenance.

Bad responses:
The B response suggests separate display software. "Closely resembles" or "similar" is not the same as identical. The C response probably means an older generation of software. Beware an impending forklift upgrade to next generation.
It is a requirement that the display software support "floating" user software licenses. Verify that any user can log onto any display station (hardware) and access his or her display software (user-specific worklists/folders, hanging protocols, and any other preferences and setups).
Good response:
Yes to all issues. The user profile and not the hardware or physical location should determine the features of the display station. The only exception being that some applications require (and are limited to) specific hardware resources.

Bad response:
Anything less than yes to all issues suggests inflexible software licensing and resource utilization.
Which of the following best describes the proposed Web distribution subsystem:
1. The Web distribution software is a component (subset) of the diagnostic software package that is hosted by the main server. There is no separate "Web server" hardware, Web directory, or Web data database.
2. The Web distribution software is a component of the main and local server, and much of the Web software is hosted by the respective server, but user access and load balancing is hosted by a separate server. The Web software accesses the main or local server directory and data database.
3. The Web distribution software is separate from the PACS application software package, and is hosted by a dedicated freestanding server. This independent Web server has its own directory database and data database and its own locally attached storage solution.
Good response:
The A response indicates a current-generation PACS architecture, with a single consolidated display application, directory and data database. The B response is an acceptable variation, as long as you make sure that any separate Web servers are configured for redundancy.

Bad response:
Response C is definitely old-school, requiring additional resources and maintenance.

By Michael Gray
AuntMinnie.com contributing writer
July 16, 2007

Michael Gray is the principal of Gray Consulting and has been providing consulting services related to PACS since 1991, assisting over 45 healthcare organizations choose their PACS. Mr. Gray's do-it-yourself RFP template, "PACS with a Punch," is available at www.graycons.com.

Part II: Proactive PACS data migration -- A better way to address the inevitable, January 4, 2007

Part I: Proactive PACS data migration -- A better way to address the inevitable, October 26, 2006