Building the Best RFP: Part 1 -- Directory architecture

AuntMinnie.com is pleased to present the first installment in the Building the Best RFP series. This new series of articles will focus 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.

Choosing the right PACS is still a challenge. PACS is not a commodity -- the most popular systems may look the same, but each vendor's offering has key features that make it different from competing systems.

PACS consultant Michael Gray.

At the same time, PACS has become increasingly complicated. PACS software is comprised of hundreds of features, supported by hundreds of specifications. Many a user's expectations are met, and many are unmet. The consequences of choosing the wrong PACS go beyond unmet expectations.

Choosing the right PACS is a much easier and less risky process if you understand the underlying technologies. Information from vendors can be of dubious value, while browsing Internet PACS forums can create an incomplete picture. Site visits are helpful, but even a full day on a site visit investigating the PACS deployed by an organization "exactly like yours" will not reveal all the issues that you will have to address if you want to make sure that you are choosing the "right" PACS for your organization.

We hope to address this informational void with Building the Best RFP, a new series of articles that will focus on the major technology issues that you will need to understand in order to choose the right PACS. Each article in the Building the Best RFP series will introduce a key technology issue, an explanation of the relevance of that issue to various real-world situations, and the implication of the issue on cost of ownership, flexibility, performance, and other factors.

Every installment will also include the precise wording you might use in an RFP or a simple quote request to convey your requirements to a vendor. Based on the many vendor responses to RFPs for PACS that I have read over the years, it is apparently quite easy for those who write the responses to the RFPs to misread or misunderstand many of the questions. It is also not uncommon for those who write the responses to provide either the barest of information or a deluge of paragraphs completely off-subject. Therefore, each article will also provide some examples of both good and bad responses to RFP-style questions.

Directory architecture

The subject of our inaugural "Building the Best RFP" article is directory architecture. A PACS server subsystem can be figured in numerous ways. Here are a few examples:

1. Combine all the individual software applications into a single package, and run that combined package on a single server.
2. Dedicate an individual server to each of the individual core software applications.
3. Combine all the individual server software applications into a single package, and install a copy on each of two servers that are running in tandem.
4. Combine all the individual server software into one or two packages, and install those packages on at least two separate server platforms that are configured as a cluster.

More important than the choice of server architecture itself is the directory server architecture of the PACS configuration. The key to this issue is understanding that the user's access to study information is dependent on access to the directory database and directory server.

The patient and study information presented in user worklists is provided by the directory (Oracle, Sybase, DB2, SQL, etc.). If the directory database is unavailable, either through a directory software or directory server failure, the entire system is effectively down. New studies cannot be acquired, and new and relevant prior studies cannot be viewed. A failure of the network connecting a user display station with the directory server will also prevent access to images.

A single directory server can meet the performance and reliability requirements of a single imaging facility, provided the server hardware itself is configured with sufficient processor power and redundant components. The network reliability can also be addressed with redundant network runs and network switches.

Enterprises that have multiple imaging facilities separated by wide area network (WAN) connections need to think about the dependency on a single directory server for functionality. Scheduled or unscheduled downtime of the directory server will affect all facilities. Failure of a WAN connection will affect the connected facility.

One way to prevent an interruption of service would be to configure a fail-proof server and double up on the WAN connections. An alternative to this approach is configuring the PACS with multiple directory servers, placing a local directory server in each facility.

In a multidirectory configuration, each facility directory server handles a particular facility, and all the facility directories forward their contents to a main directory server that manages the master directory for the enterprise. Each individual facility directory is automatically synchronized with the master.

A user worklist can be configured to focus on studies performed at a specific facility and managed by that facility's local directory server. If a user requests a new study or a relevant prior study that is not in that local directory, the system will automatically search the master directory for the study. Worklists can be filtered to represent specific facilities, or can be constructed to represent the enterprise-wide view of the operation.

If a facility loses its local directory server (but the network connecting to the main directory remains intact), image acquisition and image display at that facility can continue through support of the master directory server. The master directory sever itself can be backed up by a business continuity server. The multiple directory architecture is more expensive than a single directory architecture, and considerably more expensive than doubling up the WAN connections, but possibly the more reliable solution for a multifacility enterprise.

A final word of caution: To be truly useful, a multiple directory architecture must support the exchange of all study data among all the servers in the configuration. This would include the images as well as all associated "work products" that might have been created by the technologists and radiologists in the course of preparing and interpreting the study.

Work products include presentation states (window/level settings, annotations, overlays), key image flags and any key image notes, digital voice clips, scanned documents, and both preliminary and final radiology reports. You want to ensure that the images and all work products can be accessed by any user, regardless of where the study was performed and where it was interpreted.

It is also very important that the various local directory databases be automatically synchronized with each other. In most multiple directory architectures, the main or master directory server, which maintains the master directory of all the patients and studies across the enterprise, is located in the main hospital or its data center. Each smaller facility has its own local directory server, which manages the directory of that facility. The local directories should constantly be in synch with the master directory.

Furthermore, the user should not have to make changes to multiple directories. One change to patient or study information in any directory should be automatically propagated throughout the system.

Relevant Q&A

1. Which of the following best describes your proposed system configuration? Please describe any discrepancies.

   1. There is only one main directory database running on one designated main server. This single directory manages all patient and study information for the enterprise. All local servers require access to this main directory to acquire new studies and access image data.

   2. Both the main server and the local servers have their own directory database. Each local directory manages all patient and study information for that facility. The main directory manages all patient and study information for the enterprise. Each facility can function autonomously with its own local server.

   Good response:
   A good answer is a clear statement of either A or B. The best choice for your situation depends on your situation.

   Bad responses:

   • Any response that fails to clearly state either A or B, or that includes qualifications or variations may represent an attempt to make one configuration look like the other.
   • Any response that is clearly off subject.