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.