Pitfalls

Today’s Radiology PACS – Shiny But Not New

It may seem a little late for commenting on observations from RSNA 2013, but then nothing has changed in the Radiology PACS market since then, so I think observations from three months ago are still valid.  Come to think of it, nothing really significant seems to have changed in Radiology PACS for several years now.  Pesky little things like bug fixes get attention each year, and functions that should have been standard years ago have finally shown up, but there have been very few major changes in system architecture.  Some semblance of Disaster Recovery has always been there, but a true Business Continuity configuration is still a reach for many of the PACS vendors.

Lots of radiology PACS on the market today are old.

havana3Interesting to see some of the PACS vendors developing a clinical display application based on server-side rendering and a zero (or at least near-zero) client. Why is the diagnostic application suite still a beefy client that requires delivery of the full lossless dataset to the remote display platform?  While the EMR user can access and view data on their Windows or Mac laptop, mobile tablet or phone, why is the radiologist still limited to a glorified PC?  Clinical image distribution and display has historically played second fiddle to the diagnostic application suite.  Why this sudden shift in focus from diagnostic to clinical?   Could it be that image enabling the EMR is the “new thing”, or simply the easier and less expensive engineering effort?  In the absence of meaningful change in system architecture and diagnostic display technology, perhaps the thinking is that a shiny new clinical viewer will serve as a differentiator among a handful of radiology PACS solutions that are otherwise old, and effectively the same core systems they were nearly ten years ago.

From my perspective, it seems that today’s Radiology PACS market is a zero sum game.  While some vendors with old technology are clearly losing market share, vendors with even “decent, old PACS” tend to lose as many existing customers as they gain new customers each year.  At 95+% market penetration, it’s a replacement market, where vendors attempt to take market share from each other.  Price pressure takes its toll on system sales revenue, so the real money is in service contracts.  But once again, if there is no net increase in customer base from year to year, that revenue stream is not growing. Only so much R&D funding is available each year, and apparently there is not enough revenue to fund “the next big thing” for Radiology PACS.   When revenues are flat or falling, profits also fall unless costs are reduced.  In addition to cutting R&D, that typically means vendors cut costs by eliminating staff through layoffs, or euphemistically “rightsizing”, “reorganizing”, spinning off or shutting down under-performing parts of their businesses.  When the Radiology PACS market went cold, the size of Radiology PACS companies shrunk.

In addition to standing pat with their existing technology, the Radiology PACS vendors have fallen behind in enhancing their solutions with those features and functions that radiologists and radiology departments need today to provide good patient care and stay competitive in their market. By and large, today’s Radiology PACS solutions do not support advance Breast Imaging packages to cover Full Field  Digital Mammography and Breast Tomosynthesis, as well as the ability to display multi-modality breast imaging presentations.  They do not include advanced diagnostic Nuclear Medicine packages to cover all the variations on mixed modality image fusion.  There is no advanced worklist functionality that can escalate studies on the read list to meet TAT requirements, no ED preliminary findings and discrepancy reporting, no call functionality and follow-up.  3D is basic if available at all, and remote access is typically poor. Today’s Radiology PACS frequently have no business analytics or data mining that would enable the department to discover and monitor the drivers of their business.

All of these highly desirable, if not necessary, features and functions are third party plugs-ins developed by smaller, more nimble and innovative vendors.  In too many cases, however, the interfaces required to plug these tools into the core Radiology PACS are not yet developed for a specific combination of vendor solutions.  It’s as though cooperating with the third party vendors to expand the core PACS through the addition of these plug-ins would be seen as an open admission that the PACS vendor has fallen behind.

Based on last year’s RSNA observations, it’s time for the PACS vendors to admit their system deficiencies, and start working on the solutions.  If keeping up with current requirements through in-house development is not feasible, then the PACS vendor must embrace the concept of third party plug-ins and get on with the development of the interfaces.  They should think of this strategy as a business necessity.  The VNA is steadily pulling image management from the department PACS.  Advanced clinical viewers that address both DICOM and non-DICOM objects will easily outperform those new PACS clinical viewers.  If a PACS vendor can’t keep up with all of the new radiology department application requirements, it will be a struggle to sell any new systems a few years from now, and that is the beginning of the end for the installed base.

Havana2As I departed Chicago last December, one strong image came to mind.  Pick any upscale neighborhood in Havana and you’re likely to see shiny cars parked at the curb.  The interesting thing is, none of these are new cars, they’re shiny old cars.  Some have new wheels, but they’re still old cars.  Today’s Radiology PACS conjured up images of Havana streets…shiny cars that are not really new, with underlying layers of faded paint covered in super-high-gloss wax.

The Real Reason for Deploying a Vendor Neutral Archive

I came across a PowerPoint presentation that I created in July 2006 that referenced a DICOM Migration Server, a term at that time referring to an “open” DICOM Part 10 Storage Solution.  I vaguely remembered the subject, so I opened the file and reviewed the slides.  I felt as though I had traveled back in time to the very earliest days of the paradigm shift that would one day be referred to as the Vendor Neutral Archive.  That’s six years ago last month.  Slide after slide contained bulleted descriptions of the numerous problems facing an organization that had managed to accumulate no fewer than five different department PACS.  Five separate silos of data that could not be exchanged between the PACS. Five different image viewers that the referring physicians had to toggle between.  The last few slides in the deck laid out a rather optimistic (at the time) plan for a strategic solution to the mess.  A grin spread across my face.

I closed the slide deck, assigned a loud red label to the file so I could easily find it again, and fast-forwarded to the present thinking, “You’ve come a long way baby!”

I have been intensely focused on both the concept and the reality of Vendor Neutral Archive for those last six years.  Perhaps that is why it seems so obvious to me why a healthcare organization should make the switch.  They should “take the A out of PACS”, move the data to a VNA, associate a universal viewer to the VNA and use this combo system to manage the distribution of that data to every other system and caregiver throughout the organization.  These are things that even the best of today’s department PACS are simply incapable of effectively doing in a multi-vendor environment.

Based on the questions I continue to see quoted in the print and electronic publications, posted on-line in the focus groups, and raised at the end of many of my webinars, there still appear to be a large percentage of both PACS admins and IT systems analysts that don’t “get it”.  They seem hung up on the technical features of the VNA and all of the potential snags that they fear are bound to occur when two systems, more importantly two vendors, are forced to work together.  The litany of both identified and suspected complications goes on and on.  No doubt the incumbent PACS vendors skillfully placed many of the items on these lists.

OK, it’s time to step back from the techy stuff for a minute.

It’s true.  Many currently installed department PACS are incapable of efficiently inter-operating with a foreign archive without help, simply because they were not designed to work with a foreign archive.  The installed base of VNA solutions would be a pitiful fraction of the real number, if the VNA guys had not developed some very clever workarounds to the inadequacies of many PACS.  Without help, most PACS could not be paired with a VNA. They lack the ability to store images to a foreign archive and then remember where they stored those images.  They are incapable of propagating ADT updates or Merge and Splits to an outside archive.  They have no concept of a deletion policy and therefore have no mechanism for reacting to an externally executed Purge Strategy.  Some PACS have no concept of a relevant prior coming from another PACS, and if the VNA suddenly delivers the study to its doorstep, the PACS thinks it’s a new study and puts it in a reading list.  As I have said, the litany of both identified and suspected complications goes on and on.  The naysayers apparently have not taken the time to read up and learn how all of these problems have been resolved.  As a consequence of those workarounds, the actual installed base of VNA solutions is actually a pretty impressive number.

My advice to those that still don’t get it is don’t get hung up on the technology.  The real argument for deploying the VNA is CONTROL.  It’s time for the organization to take control of its data.  Every day that goes by, another “x” gigabytes is forwarded to the department PACS where it is converted to an effectively proprietary DICOM format that the organization will eventually have to pay in time and money to move to yet another PACS with its proprietary format.  Regardless how soon the organization can afford to replace the incumbent PACS, it’s time to start migrating the data to a VNA…in effect it’s time to mitigate the cost of that future data migration.

What about future VNA migrations, when the first VNA has to be replaced with another VNA?  That’s a really good question.

The answer is actually quite simple.  The real objective in negotiating the contract for the VNA is to gain access outside of any confidentiality stipulation in the contract to the VNA database and all of the tools required to allow the organization to move its data from VNA 1 to VNA 2, at no cost.  Without that arrangement, you’ve missed the point.

Bottom line…initiate a pro-active DICOM migration of the PACS data to a entry-level VNA.  Take control of your data.  As soon as possible, replace the uncooperative PACS with a real PACS, one that fully interoperates with a VNA.

Best-of-Breed VNA Looks Good on Paper, but can it be Built and Supported?

The initial focus of the Vendor-Neutral Archive concept was two-fold [1] to consolidate individual department PACS archives and [2] facilitate data exchange between those PACS.  As the concept evolved, so did the complexity of the configuration.  Today’s VNA configuration will probably include a pre-fetch and routing application, an HL7 interface, one or more methodologies for acquiring non-DICOM image objects, a QA/QC application suite, a universal viewing application…the list goes on.  It is highly likely that a second party is providing one or more of these numerous applications.  Different vendors will most likely provide the hardware infrastructure.  The system solution package will be comprised of multiple professional services components, which may very well be provided by different vendors.

The composition of the ideal VNA and the specific configuration that best meets the initial and long-term requirements of the healthcare organization will likely be an assembly of best-of-breed components and subsystems from multiple vendors. Therein lies a well-known problem.  Multiple vendors means multiple Service Level Agreements and multiple 800 numbers to call for support.  Is it possible for a single vendor to offer technology choices, multiple configurations, then actually build and support that custom solution?  Can a site-specific, best-of-breed VNA succeed?

Sponsored by an unrestricted grant from Dell Healthcare, I recently completed a white paper that addresses this very subject.   The paper was published/released November 27, 2011, on the opening morning of RSNA.  You can download a copy of the paper from this web site, or visit the Dell website through this link to find my paper and other related information from Dell.

The paper explores the complexity of the VNA and presents some of the options available to organizations looking for a best-of-breed VNA implementation.  It also looks at the profile of an ideal partner that has the software, hardware and services expertise to integrate, deploy and support multiple best-of-breed solutions.

A webinar also sponsored by Dell Healthcare and based on this paper was given on Thursday, November 17, 2011.  Follow this link to the Dell web site to retrieve the replay of that webinar.

 

Enterprise Archive is a Solid Concept that Doesn’t Go Far Enough

What’s in a name? Quite a bit actually.  The art of word-smithing is alive and well at some of the largest PACS companies.  Several major PACS vendors have recently announced their “Enterprise Archive” and proclaim them to be “multi-department image repositories” and “platforms for application-neutral image management”.

Sounds a lot like the concept of PACS-Neutral Enterprise Archive, but are these new Enterprise Archives really “PACS-Neutral”?

Over the last few years, most of the major Radiology PACS vendors have acquired Cardiology PACS solutions by acquiring the companies that developed those Cardiology systems.  Unfortunately the acquired technology was frequently different than the company’s existing technology, whether that was different OS, different directory database, different file structure, different programming language.  This is a major reason why so many Radiology and Cardiology PACS today stand separate, each with their separate silos of information.  So a major effort underway at the major PACS companies has been to “integrate” their Radiology and Cardiology PACS into a single platform, at least a single, shared long-term archive.  (A single shared directory database would be an even better solution.)  Now it is apparent some of the major PACS companies have finally succeeded in integrating their Radiology PACS and their Cardiology PACS into this single, ideal data management system, and the result is being promoted as “Enterprise Archive”.

Their concept of an “Enterprise Archive” is a significant improvement, but it doesn’t go far enough.

While the major PACS vendors were busy figuring out how to integrate their own PACS products into their own single, shared archive, a number of smaller more innovative companies were busy figuring out how to bring disparate PACS into a shared long-term data management system.  It seemed to the innovators that developing the technology to interconnect multiple PACS from different vendors would address a much larger problem, a problem that is far more representative of the real market.

There is nothing wrong with developing a technology and a marketing strategy that encourages Health Systems to invest in department PACS from the same vendor.  It’s just that at the end of the day (more realistically the end of five years), all those TeraBytes of data are still in a file format somewhat proprietary to that vendor.  And all the waving of the DICOM and IHE flags isn’t going to eliminate the need to migrate that data to the next archive, should the Health System decide to switch vendors at some future date.

Despite such interesting examples of word-smithing as “application-neutral image management”, the majority of this new breed of “Enterprise Archive” are not what is meant by “PACS-Neutral Enterprise Archive”.  Those archives are not capable of the high degree of interoperability (data exchange) with PACS from other vendors.  They are not capable of fixing the numerous DICOM sins that are firmly entrenched in the installed base, sins that limit our ability to effectively exchange data between departments and between organizations.

While the major PACS vendors were busy integrating their own PACS into their own Enterprise Archive, a market has emerged for the PACS-Neutral Enterprise Archive.  The former is just the latest incarnation of the vendor’s proprietary database, and the later is the multi-vendor and (finally) portable database that today’s market really needs.  And the big guys can’t catch up by simply word-smithing their marketing pieces in an attempt to hijack the better idea.

You don’t need a complicated RFP to drill down past the word-smithing and get to the truth of the matter.  Two simple and reasonably straightforward questions, if answered by the vendor truthfully, will separate what we mean by PACS-Neutral Enterprise Archive from what the major vendors are calling their Enterprise Archive.

Question#1: Is your proposed archiving system capable of Dynamic Tag Morphing?  Minimum functionality of Dynamic Tag Morphing refers to the ability to reference an internal library of PACS-specific Tag addresses (Group, Element) and Attributes (VR, VM), during the Archive’s internal process of modifying a DICOM Header in near-real-time when transmitting DICOM image data acquired on one system but destined for another.

Question #2: Does your Dynamic Tag Morphing application allow for the definition of rules around how Tags should be statically modified, typically based upon Boolean logic.  For example, if data originated at a specific facility using PACS A, is of a specific type, and is destined for another specific facility using PACS B, the archive should be able to dynamically modify any DICOM header values based upon static rules or a data source lookup (for example changing patient ID, Study Description, or Accession Number) to enable full utilization of the data by PACS B.

If you are having difficulty getting past the word-smithing, Gray Consulting has developed a useful and inexpensive Educational Program designed to introduce you and your organization to the subject of PACS-Neutral Archive.  The program consists of a 90 minute Webinar hosted by Michael Gray and based on PowerPoint slides, and a very inclusive 4-page list of Features and Functions that define the PACS-Neutral Archive.  Contact Gray Consulting at graycons@well.com for more information and a quote for the Educational Program.

The latest buzz in the PACS world

The latest buzz in the PACS world, especially in a few Discussion Threads on AuntMinnie.com, is the “web-enabled” PACS. Two of the more significant features of a PACS that would qualify it as web-enabled are communications between client displays and server based on http:// or http(s):// and the image objects are all assigned their own URL. The merits of a web-enabled PACS aside, I have a concern about the assignment of a URL to all of the image objects.

The implication is that all study data objects would be treated as URL objects. This is in fact the way Fuji treats the study objects in Synapse. While I would agree that there are some distinct advantages to “organizing” a database using URL, the problem is when the use of URL supercedes the use of DICOM.

Web tools like http:// and URL are effectively standards, but there is only one universally recognized standard in medical imaging communications and that is DICOM. A lot of effort continues to be poured into defining DICOM objects and DICOM communication SOP Classes. The vendors are being pushed hard to keep up with the advancements in the DICOM standard and nowhere is this more evident than in the area of IHE-inspired DICOM objects and SOP classes like Presentation States and Key Image Notes. To this day there are a number of major PACS systems that still treat key data objects associated with the study as proprietary objects. It’s very difficult to extract and migrate non-DICOM data objects to another DICOM-conformant PACS.

My fear is that the adoption of URL as the primary method of managing study related data will de-emphasize the importance of first making all study-related data DICOM objects. There is no way to predict how many PACS systems will be able to exchange URL data objects five years from now. However there is a very good chance that most PACS systems will be able to exchange DICOM objects five years from now.

There may be a number of good arguments for tagging all study related data objects with a URL, but let’s keep the pressure on the PACS vendors to make all of those data objects DICOM objects first.

Document dilemma

It might be useful to re-open the subject of Document Scanning: [1] Where should the document objects be stored (PACS vs RIS), and [2] What would be the best file format for the scanned document object?

A number of radiology departments with PACS are currently managing scanned document objects in the PACS. Many of these PACS are managing the document objects as a DICOM Secondary Capture objects and storing the objects as a new series in the study file. This makes it easy for the radiologist to access and view the document along with the images. This also assures that documents can be migrated along with the study data, whenever necessary.

One of the problems with this method includes having to accommodate this new study series (document objects) in pre-existing hanging protocols. Another problem is the fact that all of these document objects subsequently travel everywhere the study file travels, ending up on display screens all over the enterprise.

Comments in favor of or against this approach are welcomed.