Sunday, August 21, 2016

Deconstructed PACS: What is it, Implementation, Do’s and Don’ts (Part 1 of 4)

This is the first part of the deconstructed PACS (Picture Archiving and Communication System) series; for a full featured presentation you can look at the video. This part covers the “what” of this phenomena.

The term “deconstructed PACS” has only recently been coined and is basically referring to providing
a best-of-breed solution for the different PACS components as opposed to a single-vendor PACS. As will become clear in the discussion below, there have always been variations of deconstructed PACS systems implemented, but over the past few years, the degree to which the PACS systems have been split up and the range of components being sourced from different vendors has been increasing.

As of today, it is estimated that less than 5 percent of the installations are truly deconstructed, and there is still a lot to be learned about the support, return on investment, and what scenarios result in a good solution. Therefore, the deconstructed PACS is still relatively early in this evolution of PACS technology, and is no longer considered “hype” based on the amount of discussion and interest it gets at tradeshows and in user group discussions.

To explain what a deconstructed PACS system is, let’s start with a typical PACS system core architecture. The core has an application that manages the incoming images and related information, checks them for integrity, and sometimes, depending on the vendor, requires a technologist to “verify” them before they are added to the PACS database and archive and become available for physicians to interpret. The core also has a database/archive to allow for querying and retrieving the stored information and typically some type of Information Lifecycle Management (ILM), which implements retention rules. A radiologist can access the images to perform a diagnosis through a workflow manager, which provides a customized worklist to the radiologist, depending on the specialty, and synchronizes this list with other users who access the images. Referring physicians and specialists typically access the images for review using a web-based or some type of thin client or zero-footprint viewing interface.

One of the relatively common applications of a deconstructed PACS covers the use case whereby a radiologist needs to read for multiple institutions that have PACS systems from different vendors. Instead of having to log into different PACS systems using their proprietary workflow manager interface and dealing with multiple worklists, one can use a third party universal worklist provider that will provide a unified worklist.

A second example of a deconstructed PACS is where the database/archive is provided by a different vendor than the PACS system through a Vendor Neutral Archive (VNA). In its pure role, a VNA is a replacement for the PACS image manager/archive, which allows for a new PACS system to be deployed relatively easily as it reduces data migration issues. Note however, that it will shift the migration issue to when the VNA needs to be migrated, so this advantage could be overrated. The main benefit of a VNA is that it shifts the data ownership to the end user as several PACS vendors would store the data into a proprietary format and not even provide the database scheme to the end users.

Typically, one keeps the PACS database/image manager in place, which stores the data for 6-18 months for ready access by the radiologists. Synchronizing changes, deletions and updates of the images between the PACS and VNA is still an issue, it is addressed by implementing one of the standard IHE profiles called IOCM, but support is still lacking. An issue with VNA implementation is to decide the dataflow, i.e. are images sent first to the VNA and then to the PACS or vice versa. The same applies for physician access, should it be from the VNA or PACS? Also note that the VNA has become much more than just a simple PACS archive/image manager extension as it is also often used as an enterprise archiving solution which can potentially manage non-DICOM objects, deal with multiple Accession Numbers and patient ID’s, and perform sophisticated data clean-up using tag morphing.

A fully deconstructed PACS therefore typically has a workflow manager and image manager/archive from different vendors in addition to the diagnostic workstation and even the physician viewers. One could even argue that there is no need for a traditional PACS vendor anymore, assuming that the VNA is taking the role of the PACS image manager/archive.

Now let’s backup and look at the different PACS core and ancillary components as listed below and see how they can be deconstructed:

PACS core features to be considered for deconstructing:
  • ·         Prefetching and routing: most PACS systems provide routing capability, however, not always to the level of sophistication needed.
  • ·         Image QC: one could purchase QC workstations that provide auto merge/splitting of studies, allow for reprocessing CR/DR images and fix information in the header using a modality worklist feed.
  • ·         Reading worklist: this is the universal worklist for the radiologists that can talk to multiple PACS systems
  • ·         Diagnostic display: this is the main reader for generic radiology reading (CT, MR, CR/DR, US), but for some specialties such as digital mammography supporting breast tomosynthesis, nuclear medicine, including image fusion, and cardiology showing non-image data there might be a need for a workstation from different vendors.
  • ·         Physician display: web-server solutions from third party vendors have been available for some time; especially when looking for tablet access and zero-footprint solutions there are quite a few other options.
  • ·         3-D and other plug-ins: there has been a steady market for sophisticated 3-D applications and orthopedic templating from other vendors
  • ·         Archiving and image manager: here is where the VNA plays a role
  • ·         Audit trails and Security/privacy: this is typically done by each vendor in a proprietary manner, i.e. they provide authorization and access controls and log all accesses. Some vendors have a totally promiscuous interface, i.e. they allow anyone to access the PACS core, something that can be prevented by programming the network routers. Audit trail recording can be done using an external ATNA repository which can be shared by multiple ATNA sources.
  • ·         System administration: this addresses fixing broken or unverified studies, merging or splitting them to match orders, body parts or specialties and running database reports about storage usage, performance and availability. There are a few third party vendors that can provide some of these features, most of them are tied to the specific vendor.
  • ·         Load balancing: this is typically done by adding multiple servers that can split the load for the incoming and outgoing data
  • ·         Disaster recovery, high availability and business continuity: Many institutions have solved this by using a cloud storage solution.
  • PACS ancillary features that can be considered for deconstructing:
  • ·         Order processing: Many PACS vendors offer an integrated RIS/PACS or have the PACS worklist created by their RIS. In the majority of the cases, the RIS and PACS have been reconstructed. As a matter of fact, most of the order entry and processing is shifting to the EMR.
  • ·         Modality Worklist Provider: Most initial PACS systems were using an external modality worklist provider aka connectivity manager or broker. This takes in the HL7 orders, which are kept in a small appointment database and provide a reply to the modality worklist queries. There seems to be a trend to take this out of the PACS system as there are often limitations in the sophistication and amount of worklist filtering that can be provided.
  • ·         Dictation: even although many PACS systems are tightly connected with only one or at most two voice recognition systems, some radiologists prefer to work with a different manufacturer.
  • ·         Report storage and distribution: some vendors store reports in the PACS, some in the RIS, and some in a broker, but it appears that the trend is to store them in the EMR.
  • ·         Inter and intra image sharing: there are many solutions for this including portals, but many institutions opt to outsource the inter-facility image sharing to external companies to provide physician access.
  • ·         Critical results and discrepancy reporting: this is often built in but can also be added on.
  • ·         Clinical trials management: this can be added on by having a gateway that takes care of anonymization and adding the clinical trial identifiers.
  • ·         Teaching files: many users opt for an external solution, especially as it can be kept even after a PACS vendor has been replaced.
  • ·         Peer review: there are third party solutions for selecting random studies on a predetermined date and assigning them to a list of qualified radiologists.
  • ·         Dose and contrast management: radiation dose registration systems and in the future contrast management systems can be added on.
  • ·         Decision support: this is a new area, vendors are starting to offer data mining to provide decision support for physicians.
  • ·         Interface engine: some vendors integrate a HL7 interface engine with their product, but most of them provide an external vendor for this.

In conclusion, deconstructed PACS systems, aka “best-of-breed” have been around since PACS started, although maybe not to the degree as currently being implemented. The definition of a deconstructed PACS is vague and subject to interpretation by the vendor defining it; it can include one or many core or ancillary components. Remember that it is still a PACS, the basic functionality does not really change, both a deconstructed or reconstructed PACS does the same job. It is recommended that you look at your PACS system in case you need to have additional functionality, such as peer reviews, decision support or dose registration and consider third party vendors. If you are looking for a PACS replacement, you might even consider purchasing one of the core components from a different vendor. However, be careful, and look at the do’s and don’ts section of this series.

The author, Herman Oosterwijk is a long-time PACS trainer and consultant, published several textbooks and study guides on this subject and provides both face-to-face and on-line training on PACS, DICOM, HL7 and IHE. He can be reached at www.otechimg.com

3 comments:

  1. An excellent start by Herman O. in identifying the key aspects of deconstructing a PACS.

    As we move to the Internet of Things (IoT) concept so that integration becomes more uniform, the result will be more powerful solutions for all users.

    As more silos become "vendor independent", the move to IoT will accelerate in the years to come.

    ReplyDelete
  2. I think this is interesting articles and Business ethics for new information's, and i like that kind of information.So the i like that post,because all of given information was very excellent

    Best Informatica Training Institute in Chennai

    ReplyDelete

  3. Thanks of sharing this post…Informatica is the fastest growing technology that helps to get your dream job in a best way, so if you wants to become a expertise in Informatica get some training on that Technology.
    Regards,

    ETL Training in Chennai | Informatica Training Institutes in Chennai

    ReplyDelete