Deconstructed PACS part 2 of 4: Implementation within the VA

This is part 2 of 4 of the Deconstructed PACS series, the full video and corresponding slides of the webcast can be viewed here. 

The VA Midwest Health Care Network, otherwise known as VISN 23 (Veterans Integrated Service Network) implemented a deconstructed PACS between September, 2014 and August, 2015.  Our legacy PACS hardware, originally purchased as part of a Brit Systems installation was at end of life.  The leadership team in VISN 23 made the decision to proceed with a deconstructed PACS solution to replace our traditional PACS.

VISN 23 encompasses all of Minnesota, Iowa, North Dakota, South Dakota and Nebraska and small parts of additional surrounding states.  The largest facility is Minneapolis with 130,000 studies per year.  All told, the 11 facilities register 460,000 studies per year.

Prior to making the decision to proceed with a deconstructed PACS, the VISN 23 PACS and Imaging Service lines achieved successful implementations of various PACS “sub-components”.  These consisted of Corepoint Healthcare’s HL7 integration engine, PowerScribe 360®, Laurel Bridge Compass® DICOM Router, Pacsgear PACS Connect®, TeraRecon Intuition® Advanced Visualization as well as various CD burning and importing solutions across the enterprise.  Having the experience of researching, evaluating and procuring these various components encouraged the teams to move forward with a fully deconstructed PACS.

The primary three components of the deconstructed PACS in VISN 23 are Visage Imaging as the viewing solution, Lexmark Acuo as the VNA and Medicalis as the radiologists’ worklist. Due to concerns about bandwidth across the enterprise, VISN 23 chose to install a Visage server at 8 of the 11 campuses along with an Acuo local server which Acuo labels a “temporal”.  Acuo data centers are installed at both Minneapolis and Omaha with DICOM replication between these two.  The Medicalis servers are installed in Omaha.  Also installed in Omaha are the HL7, modality worklist and PowerScribe servers for the enterprise.

Prior to deconstructing the PACS, VISN 23 made extensive use of DICOM routers to ingest studies from the modality layer.  Also a third party modality worklist solution purchased from Pacsgear was implemented well ahead of the deconstructed PACS.  This allowed the biomed teams to fully configure the modalities to interact with these two systems before during and after implementing a deconstructed PACS.  This freed up time and resources during the actual implementation of the primary three components of the deconstructed PACS.

The VISN 23 team faced several challenges during implementation. First, we discovered that new internal policies prevented installation of the Visage viewer on enterprise desktops for clinical use.  Second, since the legacy PACS hardware was at end of life, implementation was begun before the legacy studies had been migrated.  Therefore, at the first site, we initiated a “just in time” or “Ad Hoc” migration meaning priors were retrieved from legacy systems for current studies as they were performed.  However, since we had to maintain the legacy PACS for the enterprise desktop viewer, we had to be cautious to avoid overburdening the legacy PACS with prior retrievals.  We managed this, but it was a delicate balancing act that went on for nearly six months.

Another challenge VISN 23 faced (and will continue to face regardless of PACS type) is that the VA’s HIS/RIS, known as VistA, will only generate an HL7 message at the time of patient registration.  This means that, essentially, there is no pre-fetch but rather a “post-fetch” or “just-in-time fetch”.  As we worked through the issues, there were times when priors were not fully available for the radiologists.  In response to this, we had a few users who innocently fetched entire jackets on multiple patients to get priors.  This caused serious system performance issues. This was easily remedied with education.

VISN 23 teams also discovered during the process of migration and priors retrieval that there were inconsistencies in some DICOM tags on these legacy studies.  We addressed this by using the evaluative tag morphing and writing capabilities of the DICOM routers mentioned earlier.

Lastly, at the request of the radiologists, support teams went back to the study description source in VistA’s RIS and improved the efficiency of the descriptions.  For example, if a CT Chest and a CT Abdomen/Pelvis were acquired together, all of the images were usually stored under the CT Chest description.  We modified the description for these studies to read “CT (CAP) Chest”.

Successes achieved during our implementation were several. The viewer and VNA were able to achieve a very tight integration for study and patient splits, edits, merges, and so on.  We found it much easier to view images from other facilities. Clinical staff easily adapted to the Visage viewer on the enterprise desktop.  The tag morphing and writing will lead to a much cleaner database.  The server side rendering of the Visage viewer allowed near instant viewing of even volumetric CT studies using minimal bandwidth. 

In summary, our vendors worked remarkably well together. VISN 23’s experience proved that a deconstructed PACS is a feasible alternative even in a challenging security environment such as the VA.

The author, Michael Ryan played a leading role in the implementation of the deconstructed PACS in the VA Midwest Health Care Network (VISN 23).  Michael has since retired from the VA and is now providing consulting services as MCR Consulting, LLC.  You can reach Mike at MCR Consulting, LLC, [email protected]

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