confusing and/or new to many, therefore this attempt to shine some
light on this topic.
In the past, there have been other adjectives used for the
PACS system, which came and went. For example, the terms of the integrated
PACS, the RIS (Radiology Information System) driven or PACS driven, and several
others. In the meantime, the RIS is pretty much dead as most hospitals now have
an EMR (Electronic Medical Records) with order entry capability in the form of
a CPOE (Computerized Physician Order Entry) function, so there is no use to
talking about integrated RIS/PACS or RIS driven PACS anymore.
So, what is the deconstructed PACS in my opinion? It is
nothing other than using a best-of-breed approach or commoditization for the
individual PACS components. It is a logical evolution of what has been
happening since PACS started all along.
Going back in PACS history, the initial PACS systems were a
“package deal” containing hardware and software for the archive, viewing
stations, including dedicated expensive video cards, and monitors. This was
true until the hospital IT departments got involved, especially from the large
providers, who had a contract with for example, HP, Dell or IBM to provide all
of their hardware, which could amount to literally thousands (or more) computers
a year. Most of them can buy the hardware much cheaper than the PACS vendors,
and therefore wanted to provide their own hardware for the viewing stations.
The same thing happened with the archives, for example, an
IT shop who had all EMC hardware with its support and maintenance agreement,
would be very hesitant to bring in another vendor just for the PACS. Remember
that the PACS from a hospital perspective is just another piece of their
healthcare IT puzzle together with the other department systems, HIS, billing
etc. To make a point, when I visit a hospital IT room I can appreciate their
perspective, as the PACS servers take up just a few of the many computer cabinets
in one of the several rows of hardware of their computer room.
Some of the first vendors very smartly addressed that
requirement and started to sell PACS software licenses only while specifying
minimum hardware specs such as required CPU, memory and OS version, which did
shake up the industry and pretty much everyone started to follow. We are now at
the point that you can provide your own hardware, including the medical grade
monitors, video boards, computers, servers and storage devices for all PACS
components.
After that, VNA or Vendor Neutral Archives were introduced.
Users were getting tired of having to migrate data every time they changed PACS
vendora, so they wanted to take control over their data and purchase the
archive from a different vendor and use the PACS archive mainly as a cache to
allow for fast access of the most recent studies.
In the meantime, more “ologies” wanted to manage their
images electronically and again, the CIO’s were not allowing a department to
buy yet another archive for let’s say cardiology, dentistry, surgery and other
images. The users also found out that not all images are in a DICOM format, for
example, speech pathology, physical therapy and dermatology were all storing
native JPEGS and MPEGs, and ophthalmology has been creating pdf’s containing
very detailed and specific results. Moreover, the push to share this
information in a standard manner with Health Information Exchanges (HIE’s)
forced these VNAs to become a gateway to the outside world using standard
protocols such as XDS. And if you need to have access to all of the patient
images creating a patient centered view, you might as well access the VNA
instead of all the individual PACS systems while using a zero footprint viewer.
An additional problem with uncoupling the archive i.e. VNA
from the PACS is synchronization. If an image has to be modified or deleted on
the PACS, you don’t want to have to do that twice, voila, the IHE IOCM (Imaging
Object Change Document) profile that provides that functionality. So we arrived
at an archive device (VNA) that supports DICOM, non-DICOM, can talk XDS,
supports the PACS synchronization and has a standard DICOM viewer interface. At
least this is a “true VNA” in my definition.
So far we have deconstructed the PACS hardware and software,
the archive and the viewer, which actually caused some “experts” to announce
that PACS is dead, which is definitely a misstatement. Therefore, myth number
one that the deconstructed PACS is the same as “PACS is dead,” is definitely a
misstatement. We still need PACS systems that manage the department workflow,
providing very fast access to images and efficiently providing very specific
tools and image presentation in the form of hanging protocols to deal with
specialties such as cardiology, mammography, dentistry, nuclear medicine, and
last but not least, general radiography. This is in addition to features such
as peer review capabilities and critical results reporting.
Going down the path of deconstruction, we also need
so-called workflow managers that manage the workstations. These started out as
a solution for radiologists who are serving multiple hospitals, each one might
have a different PACS system. Instead of having to log into different worklists
for each individual PACS, the workflow manager would combine or aggregate these
worklists and create a single one, while synchronizing the reading between
multiple users and PCS systems. The step from different PACS systems to a
single archive (VNA) that has images from different sources is not that hard to
make, hence we have the next step, i.e. a workflow manager from a different
vendor. The step to use a best-of-breed viewer is now easy to make, yet from
another vendor.
So far we reconstructed the archive, workflow manager and
viewer, however, we need additional middleware to make this work. In
particular, we need to clean up the data as it comes from different sources,
such as series and procedure descriptions, especially if the images are created
at different institutions with their own terminology. For this a DICOM cleaner
or “tag morphing” software is needed. In addition, if you don’t have a
universal ID, you need the Master Patient Index or MPI capability. Last but not
least, to get some of the details needed from the orders, you need an interface
engine that consolidates all of the HL7 feeds.
As of now we have five components, the VNA, workflow
manager, viewer, DICOM router, HL7 interface engine and an optional MPI
provider. You can purchase each one of those from a different vendor, which is
the best-of-breed approach.
This brings us to myth number 2, which is that a
deconstructed PACS is less expensive, which is not necessarily true. The reason
is the effort involved with integrating, testing and maintaining such a diverse
system. Assuming that you have a strong IT department, and educated imaging and
biomedical engineering resources, it could definitely be less expensive and
provide best of breed, i.e. a solution that better meets your specific
requirements and workflow. The truth is that for many institutions this is not
an option. They might want to deconstruct the PACS only to the level of the
VNA, and even in that case they might be better off to purchase the VNA from
the same vendor as their PACS provider. However, if you do so, I would strongly
recommend requiring standards support at each level so that you can replace any
of the components for either business reasons or if the vendor simply does not
keep up with new developments. As an example, you would be surprised how many
vendors still don’t support 3-D breast tomosynthesis images, or even the new
enhanced multi-frame CT and MR for their viewer, in which case you might be
better off to look for a different solution.
The last myth is that a deconstructed PACS is something new,
which is incorrect. It is just a logical evolution of what started 15 years ago
by opening up the PACS by using standard interfaces and allowing the
replacement of the several parts by the different vendors. So, the truth is
that there is nothing new under the sun, which might take some of the marketing
hype away from the vendors, but that is OK, they just have to come up with
another term to sell what is basically the same old thing.
In the meantime, as a user, it is important to make sure
that any new PACS purchase allows for the deconstruction by requiring standard
support, and verifying and testing these, and continue to get educated and stay
knowledgeable to provide the more sophisticated support needed for these
systems.
