Happy New Year to all! As we embark on a new year (Negative 13 Degrees Fahrenheit as I sit here), I wanted to relay a conversation that resulted from a renewal of an old acquaintance from the RSNA (Radiological Society of North America) meeting in December, 2013. I ran into Chris Magyar, now CTO at Seven10 Storage Software (http://seven10storage.com/), and formerly with Agfa and Emageon. Chris is someone who has been around VNAs and DICOM storage for a long time and really understands it!
Just before the holidays, Chris and I had a conversation about what he is up to at Seven10. Chris introduced me to a concept that I had not considered when I put together my VNA framework (http://www.healthcare-informatics.com/article/framework-aid-vna-implementation?page=show#.UiYFIN0v9Hg.email) – that of a “Storage VNA” versus a “PACS VNA.” As Chris points out, one of the prime motivators for considering a PACS VNA has been the notion of migrating data due to an obsolete storage infrastructure associated with an existing system.
Obviously, there are many additional reasons to consider a PACS VNA, but there can just as well be situations where the only need is to get data off old, end of life media. In this case, the Storage VNA may be a credible method to accomplish this, by means of an application that migrates the storage infrastructure without impacting the underlying application. A major advantage is that the application can be used for subsequent data migrations should storage technology evolve in the future.
To reference an old adage, “if it isn’t broken, don’t fix it,” if the organization is happy with an existing system, and there are no other compelling factors regarding the need for a full VNA, then migrating an existing system’s data to new storage media makes a lot of sense.
In relationship to the VNA Framework previously published, Figure 1 highlights how a Storage VNA might fit within the VNA Framework. Note that services would emphasize data migration. Most likely, if it is a legacy system, the data would be in DICOM format, but nothing should preclude other data formats. Infrastructure-wise, the Storage VNA most likely relates to local infrastructure, but again, nothing should preclude a cloud-based service from using such an application. Obviously, data migration does not involve image display/accessibility, so there would be no involvement on the accessibility axis. From a total cost of ownership perspective, the Storage VNA would most likely be either a capital or per study cost model.
So, the Storage VNA fits the VNA Framework and represents a viable option should there be a specific intent of migrating storage media. It may be a concept worth considering for those not ready to tackle a full VNA. And in that sense, it can be considered a viable alternative in that one doesn’t have to replace an existing archive application with a VNA just because of media obsolescence. It may be one more option to consider in navigating the VNA forest.
