You are on page 1of 4

Avoiding pitfalls in adding to a PACS

or changing PACS vendors

Making changes to a PACS can be painful.
Thorough planning helps to avoid common pitfalls.

Steven C. Horii, MD

ncreasingly, radiology practices are ties for advanced visualization may drive It is critical to consider how informa-
deciding to add to an existing picture the need to add to or change a PACS. tion will move among several PACS.
archiving and communications sys- Upgrading is difficult because the Should we go back to the old store-and-
tem (PACS) or to change PACS vendors PACS interacts with so many other sys- forward days of routing images to where
entirely. These are among the most chal- tems and devices. There are a tremendous they’re needed? How do we do that with
lenging transitions a radiology practice number of interfaces involved, and that different kinds of PACS? How do we get
will ever face. This article will discuss complexity affects information flow. the information where it’s needed, when
why it may be desirable to upgrade a Network loads may change, for example, it’s needed?
PACS, how to manage the project, and and a larger amount of storage may be At a minimum, interfaces usually
some pitfalls to watch out for. needed. Studies may begin to incorporate require the setting of parameters by both
new images, as advanced imaging tech- vendors involved. The software on both
Adding to a PACS niques enable radiologists to create 3- sides of the interface is expecting certain
The decision to add to a PACS is often dimensional (3D) series from data that behavior and data across that interface,
driven by imaging subspecialties. Exist- was already part of the image acquisition. and is sensitive to very small changes.
ing PACS often fail to meet the needs of Similarly, new imaging equipment When managing interface changes,
radiologists who interpret ultrasound or raises new issues. If cardiology is being keep in mind that vendors generally
nuclear medicine studies, for example. integrated into the PACS, images should accept responsibility only for their hard-
An ultrasound system must be able to flow to the archive directly from the ware and software and for managing
handle not just color imaging but multi- angiography systems. To do that, it is nec- their side of any interface. They will not
ple cine loops, Doppler wave forms, and essary to interface with equipment in the be responsible for what is on the other
other complex tasks that PACS supplied catheterization laboratory. Table 1 sum- side of the interface, unless an agree-
by the major vendors often don’t handle. marizes some tips for adding to a PACS. ment to that effect has been negotiated
Nuclear medicine studies involve similar or the same vendor manufactures both
challenges, particularly in the mathemat- Avoiding pitfalls pieces of equipment.
ical analysis of images. Cardiology is PACS and radiology information The process of installing a new system,
also placing new demands on PACS, as systems (RIS) do not exist as stand- new software release, or new hardware
cardiologists have different requirements alone systems. They interface with a usually results in downtime. Manage-
from radiologists when interpreting number of other systems, including hos- ment of this process is important because
images. At the same time, new capabili- pital information systems, pharmacy it affects all users. Be aware that a system
systems, admission-discharge-transfer that worked perfectly during testing
Dr. Ho ri i is a Professor of Radiology systems, billing systems, and others. can still develop problems during instal-
and the Clinical Director of Medical Software and hardware changes have lation. It is unlikely that any vendor can
Informatics, the Univ ersity of Pennsy l-
vania Medical Center, Philadelphia, PA. the potential to affect the way those exactly reproduce your system configura-
interfaces operate. tion for testing.


policy and sign off on it. Such an agree- The University of Pennsylvania has
Table 1. Tips for ment can avoid the common problem of changed PACS vendors 3 times. The first
adding to a PACS a vendor who performs preventive main- time, the vendor for our ultrasound mini-
tenance on a scanner and, without the PACS left the business. Our main PACS
• Completely understand the pro- explicit consent of the radiologist, also vendor could not handle ultrasound
jected workflow and movement installs some new software. Often it is images in the way we needed, so we had
of information between the new only when the scanner stops sending to make a change to a new ultrasound
PACS and the existing one. images to the PACS that the radiologist mini-PACS. In another case, our health
• Become knowledgeable about becomes aware of the software upgrade. system established an exclusive relation-
the interfaces between systems— Consider having a test system that ship with a single imaging equipment
what those interfaces do, what enables the testing of changes before vendor, and we were required to change
information flows across them, they’re actually implemented in opera- vendors for our departmental PACS. We
and their upstream and down-
tional systems. As mentioned earlier, eventually changed back when the new
stream dependencies.
this will not catch all of the little, irritat- system could not meet our needs.
• When managing interface ing problems that might occur, but it
changes, keep in mind that ven-
will catch the big ones that prevent the Challenges
dors generally accept responsi-
system from operating. There is no question that changing to
bility only for their hardware and
software, and for managing their Understand that knowledge is power. a new PACS is painful. The most intense
side of any interface. A radiologist who is knowledgeable pain does not come from the capital
about the interfaces between systems, costs. Nor does it come from the need to
• Establish a strict policy covering
changes and upgrades. Require what those interfaces do, and what infor- dispose of old equipment or to part ways
that vendors understand the pol- mation flows across them is in a much with the existing vendor.
icy and sign off on it. better position to determine whether a What is really difficult is the migration
new system is likely to impact an exist- of multiple terabytes of data that reside in
• Consider having a test system that
allows changes and upgrades to ing system. It is also important to under- an existing archive. This may seem puz-
be run prior to implementing them stand that interfaces have both upstream zling. We can store and retrieve DICOM
on operational systems. and downstream dependencies. A change images, so why can’t we easily retrieve
• Anticipate and manage system
on one side may affect the way devices DICOM objects? Many PACS store
downtime. operate on the other side. DICOM attributes in proprietary data-
base tables, reassembling the DICOM
Changing to a new PACS objects only when they are requested.
There are many stories of major prob- If adding to an existing PACS is chal- Vendors do this because it optimizes sys-
lems that developed after the addition of lenging, changing to a new PACS vendor tem performance. Remember, DICOM
a new system or a change in software on is daunting. Many radiology departments was designed for the communication of
an existing system. Usually, the systems are doing just that, however. There are images, not as a database format.
themselves work, but the interface fails. several reasons why. A vendor may go Typical database problems include
For example, when we installed a new out of business or be purchased by irregularities in patient names. Is Homer
CT scanner at the University of Pennsyl- another company, for example. In addi- Simpson the same person as Homer J.
vania, the PACS stopped acquiring tion, an existing PACS may no longer Simpson? What about Homer Simson,
images. Both devices were DICOM con- support the department’s current work, or spelled without the p, who has a different
formant, but the network interface had it may not expand to meet new needs. If identification number but the same birth
been set for a particular scanner. When the PACS cannot handle the advanced date and the same address? Are they all
we changed that scanner, we had to visualization needed for cardiac imaging, the same person?
change the parameters on the network a new PACS may be needed. What about a head CT study that actu-
interface to suit the performance of the A corporate decision may drive the ally contains images of the head, chest,
new machine. change to a new PACS. If the hospital is abdomen, and pelvis? What about stud-
To avoid such problems, it is essential purchased by a larger entity, hospital ies that were entered into the database
to completely understand the projected administration may sign an exclusive with incorrect order or request numbers?
work flow and movement of information purchase agreement with a particular And what about studies that were stored
across the interfaces between systems, vendor. One radiology practice may take on read-only memory but whose attrib-
especially between a new PACS and the over an existing one with a very large utes were updated after the initial image
existing one. There must be a strict pol- installed base. A new radiology chairman acquisition? When those studies are read
icy in place covering any changes and may have a preferred system and initiate off the disc, they will come back with the
upgrades. Vendors should understand the the change in the PACS vendor. older values in the DICOM headers.


■ 21

There are numerous other examples,

all with some sort of information mis- Table 2. Tips for changing PACS vendors
match. During the migration progress, • Get a “prenuptial” agreement from your PACS vendor that includes:
each of these will need either manual
• A guarantee of access to the database and data. If a vendor is going out
intervention or processing through addi-
of business, get the database schema and details of all intersystem
tional software. interfaces, including all DICOM and HL7 messages and their content.
As might be expected, interfaces pre-
• The option to continue service contracts on a month-by-month basis,
sent special problems. All interfaces
with cost constraints.
between the new PACS and other infor-
mation systems and imaging equipment • Continuation of 24/7 service on the same terms as during the system
active life.
will, at the least, need to be tested. In
addition, a new round of interface license • Guaranteed engineering support during the transition, including a com-
fees may be imposed by other vendors, mitment to work with the new vendor. Negotiate a schedule of charges
for engineering support in advance.
for example, the RIS vendor.
The phasing out of old equipment can • Make provision for retrieving DICOM objects that contain private groups and
create another problem, particularly if the elements.
new PACS installation runs behind • Consider changing the disaster recovery backup to a DICOM media storage
schedule. In our case, we had been ob- application profile system. Store all information as DICOM files and DICOM
objects, rather than in proprietary formats. Consider a “vendor-independent”
serving archive failures resulting from
storage solution.
mechanical problems in the existing juke
box. We didn’t fix the problems because • Continue maintenance of the old PACS. Be prepared for failures of the old
system before completion of the changeover.
we expected the new system to be in
place before the existing system failed • Establish realistic and firm changeover dates, as well as contingency plans if
completely. Unfortunately, we missed the those dates are missed. Include an agreement about who will pay for service
of the old system if changeover dates are missed.
target date for installation of the new
PACS. Archive failures began to occur • Consider beginning database conversion well in advance of changeover.
with increasing frequency and began to • Plan on running parallel systems for a time. Determine who will pay for the
affect clinical operation. extra network infrastructure and hardware that will be needed.
At that point, it was unclear who • Appoint an “informatics historian” to record dates of all systems and software
would handle problems with the exist- installations, keep track of all software version descriptions, and maintain a
ing system during changeover. The old record of problems, as well as their follow-up and resolution.
system vendor was no longer under ser-
vice contract, and the new system ven- month-to-month basis, with cost con- return them on request. Determine how
dor was not enthusiastic about paying to straints. Service should be on the same these will be migrated to the new system.
repair a system it was going to replace. terms as during the system’s active life. If Make sure the vendor does not simply
It took several months of negotiation service had been available 24 hours a day, discard private DICOM groups.
with both vendors to get the situation 7 days a week, it should continue at this Establish realistic and firm change-
resolved. In the end, we had support of level as long as the system is in clinical use. over dates, as well as contingency plans
both systems. The agreement should also provide in case those dates are missed. This
for guaranteed engineering support dur- should include an agreement about who
Recommendations ing the transition, including a commit- will pay for service of the old system if
Based on our experience, it is wise to ment to work with the new vendor. Such changeover dates are not met.
get a “prenuptial agreement” from the service will not be free of charge, but Consider changing the disaster recov-
PACS vendor (Table 2). This agreement it is wise to negotiate a schedule of ery backup to a DICOM media storage
should provide for guaranteed access to charges in advance. application profile system. Store all infor-
the database and the data. If a vendor is No matter how information migration mation as DICOM files and DICOM
going out of business, it is important to is managed—whether by the existing objects, rather than in proprietary formats.
get the database schema from them vendor, the new vendor, or a third Consider using a vendor-independent
before they shut down. Details of all party—provision should be made for storage solution that supports different
intersystem interfaces are also needed, DICOM objects that contain private vendors’ PACS. There are commercial
including all DICOM and HL7 mes- groups and elements. Private DICOM vendors that provide such products, and
sages and their content. groups are permitted in the DICOM stan- some of the main PACS vendors can do
The agreement should include an op- dard, and many vendors use them. Ide- so as well, upon request (and payment of
tion to continue service contracts on a ally, a storage system will store these and the cost of such options).

Be prepared for failures of the old system before completing
changeover to the new system, and know how to handle those
failures. Do not ignore maintenance of the old system. Continue
to check that backup systems are working.
Don’t count on reusing old PACS hardware. Not only is the
old hardware likely to be obsolete, it will be needed when the
old system is run in parallel with the new system during testing
and startup. In addition, if the original PACS was acquired
through an operating lease, the equipment must be returned to
the original vendor unless a purchase agreement is negotiated.
Consider beginning database conversion well in advance of
changeover. Set a target for the amount of data to be con-
verted prior to the changeover, typically 1 to 2 years’ worth,
with the rest converted on either an ad hoc basis or in a back-
ground process.
Determine who will perform database clean-up and how it
will be paid for. If health system staff will be doing the clean-
up, consider negotiating a charge-back rate to cover labor.
Considering having a database survey done ahead of time to
determine how many problems exist in the database. This will
provide perspective on how difficult the changeover is likely
to be.
It will likely be necessary to run parallel systems for a while.
Determine who will pay for the extra network infrastructure
and hardware that may be needed to support a network that is
twice its usual size.
If the change in PACS is a result of a decision by the health
system or hospital administration, make sure they are aware of
the full costs associated with making the change and are willing
to support those costs.
Finally, appoint an “informatics historian” who will record
the dates of all systems and hardware installations, keep track
of all software version descriptions, and maintain a record of
problems, as well as their follow-up and resolution. Such
records are extremely valuable and have saved some institu-
tions significant expenses on service contracts.

Adding a PACS to an existing enterprise is not a trivial
endeavor. It requires knowledge and planning, chiefly with
regard to interfaces and data flow. It is possible to minimize the
negative impact of a PACS addition, but it is difficult to com-
pletely eliminate it. A change in PACS vendors is, without
question, painful. The most effective way to minimize the pain
is to thoroughly plan for the change and prepare for all that it
will entail.

For a roundtable discussion of this article, visit http://

December 2008