
When replacing a PACS system, it is highly recommended that
you consider revisiting the fundamental image and information system
architecture and workflow, as this is a prime opportunity to redesign it. In
particular, one should consider the following:
1.
Use a Vendor Neutral Archive (VNA) - To avoid
multiple data migrations in the future, it is strongly recommended that you disconnect
the PACS database or image manager from its archive and use a different vendor
for the archive from the PACS vendor. It is possible to purchase a VNA from the
same vendor as the PACS; however, it is very hard if not impossible to prove
that they are not very tightly coupled. For example, some vendors do not
physically delete images from the archive but, rather only set a deletion flag
in the database, which is not acceptable. The reason is that if one ever is
going to migrate the archived images to a different vendor, the
deletion-flagged images will almost certainly re-appear. One could argue that
deletion of images is not a common scenario, however, it is necessary if the
age of the images is past the retention rules, or if they are simply
incorrectly labeled or have no diagnostic value. Regardless, just for the sake
of being able to go with other vendors in the future without massive, lengthy
and costly data migrations, a VNA from a different vendor makes every sense in
the world.
2.
Consider an enterprise PACS solution - Another
major advantage of using a VNA is that it allows a relatively easy transition
to connect multiple PACS systems from several departments. The first one on the
list is cardiology, however, this is probably also the most complicated as
cardiology requires storage of not only images but waveforms and
electrophysiological data as well. Other specialties ranging from
gastroenterology to dermatology or dentistry have a need to archive MPEG files
in addition to JPEG static images. A “true” VNA should be able to take care of
these additional image format storage requirements.
3.
Determine what information should be migrated - Many
PACS systems store so-called key image information and annotations in the
database instead of encoding this as a DICOM object that can be migrated. It is
possible to decode this vendor-proprietary information and create new DICOM
objects, however, this goes beyond a “simple” migration and can become quite
involved and costly. Therefore, one should decide what information is
clinically important and critical, which depends on how the previous PACS system
was used. For example, the chance that a five-year-old study is going to be
retrieved is small to start with, and if a measurement resulting in an
annotation has to be redone, that might not be a big deal. However, if
technologists were using annotations to correct left and right positioning
indications, this has to be recovered and recreated. In addition, migrating is
a good time to revisit retention rules to avoid migrating information that
exceeds the retention requirement. Lastly, some PACS systems store diagnostic
reports, some don’t. If the new PACS doesn’t and if the old PACS does, these
have to be either migrated from the old PACS to a RIS or EMR.
4.
Revisit document management - Many institutional
systems have been scanning documents such as requisitions, release forms, and
anything that was part of an order, as a DICOM object which is stored with the
images. This made a lot of sense when the only access to electronic information
for a radiologist was the PACS workstation. However, as most institutions can
be expected to either have an EMR, or be in the process of installing one this
year, it does not make sense to continue this practice, as it can be kept in
the EMR. In addition, some of these documents, such as the requisition, should
be available as an electronic order in the EMR, which includes the reason for the
study and clinical history in electronic format, eliminating the need to scan requisitions.
5.
Phase out CD import and export - Burning CDs and
importing images from them has become a logistical issue in addition to the
fact that some CD’s are still created with image resolutions that simply have
no diagnostic value such as simple JPEG’s, or are stored in a proprietary
format. There are other options for importing and exporting images using file
sharing or cloud services, some of those provided by the PACS vendor, some of
them provided by a third party. Eventually, images will be exchanged through
Health Information Exchanges (HIE’s), therefore, using a file-sharing service
may serve as a logical step into that direction.
6.
Apply rules learned from IHE scheduled workflow
- I am convinced that the majority of PACS systems don’t fully use the IHE
scheduled workflow features, and thus do not take advantage of the efficiency
and workflow benefits of those features. In particular, implementing a Modality
Performed Procedure Step (MPPS) allows modalities to exchange exam status, the
image count, and procedure changes with PACS and RIS, but MPPS has been
sparsely implemented. Changing a PACS system is a good opportunity to review
the bidirectional RIS/PACS interfaces and activate DICOM MPPS as well as
Storage Commitment at all of the modalities. Storage Commitment (handing off
archive responsibility) should be implemented between the PACS and VNA anyway
to prevent information loss.
7.
Look beyond RIS/PACS to EMR/PACS - RIS systems
might become obsolete as sophisticated Computerized Physician Order Entry
(CPOE) systems are becoming available as part of an EMR. A radiology department
would still need software to manage its resources, finance, supplies, and other
typical department management items, however, the traditional RIS features that
include ordering, scheduling and report management and distribution can be
centralized in an EMR. An integration of a PACS with an EMR on the front-end
might make more sense than integrating it with a RIS. If nothing else, a plan
to phase out the RIS should be part of the PACS replacement objectives.
8.
Revisit the enterprise imaging solution - Images
from the PACS have been made available throughout the enterprise by using web-servers
that were part of the PACS system. However, when all images are going to be
available at a VNA or enterprise archive, it makes more sense to have a viewer
connected to the VNA instead of to the PACS. Most VNA’s support a web version
of DICOM called WADO (Web Access to DICOM Objects) and there is actually a newly
defined IHE profile that specifies how plug-ins would work with EMR’s (see www.ihe.net for more information). A temporary
solution is for the EMR to have a PACS “plug-in,” which allows the EMR access
to the primary PACS archive, however, one should design the system architecture
to eventually get the images from the VNA.
9.
Make sure there is support for all recent DICOM
enhancements - There is a new generation of DICOM objects, which I refer to as
DICOM 4.0, which are based on multi-dimensional object definitions with DICOM
headers that are much richer, better defined and encoded. This family of so-called
DICOM SOP Classes includes the enhanced MR and CT, and the new digital
mammography, tomosynthesis. There are even new versions for cardiology, angio
and RF. Instead of having to use dedicated modality workstations to view these
new DICOM SOP Classes, one should make sure that there is support for them in
the new PACS system. Other groups of SOP Classes are the Structured Reports
that encode ultrasound measurements and CAD results, which should be supported
and interpreted as well as displayed correctly. Lastly, there is an increasing
demand to record dose information in the form of DICOM Structured Reports,
which have to be managed in a PACS, i.e. recorded and exchanged.
10.
Consider the cloud - Outsourcing storage might
make sense for some institutions, depending on available in-house IT resources.
Concern about privacy, security and availability, and whether or not the
information is considered to be of such an important strategic asset may be
reasons that an institution would want to keep it in-house. If for no other
reason, one should consider maintaining a copy of the data in the cloud to
provide disaster recovery. If there are concerns with security, organizations could
consider creating their own clouds, which is rather common for either large
geographical areas (e.g. in Canadian provinces), or for large provider groups.
For a small institution that does not have any affiliations, a commercially
available cloud service might make sense.
In conclusion, replacing a PACS with the same or different
vendor without redesigning the architecture of the system would be a major lost
opportunity. It is strongly recommended that you review the current
architecture, workflow and standards support, i.e. how open the system is and
how it can be improved, to make sure the new system can serve the next generation of hardware and software.