Before you can design your VNA you need to identify what exactly it is that you want to build. Implying that requirements are simply to be the long-term archive for images is about the same as saying I want a building to live in, or build me an office building downtown. While there are many, many requirements and concepts, I would like to focus on two for now. The first is the concept of location, where are the images, where are the consumers and where will the images be stored. The second is how to organize data within your VNA.
It seems somewhat anachronistic to be talking about physical location in a virtual world, but location matters because it effects latency which relates to how fast you can move the data. In a perfect world there are gigabit pipes everywhere with no latency and data moves almost instantaneously. However, in my world there are some pretty slow and saturated networks. So, where are the consumers of imaging data? This is typically the radiologists and referring physicians. These users are likely in relatively close physical proximity to the origin of the images; at least in a metropolitan area, Nighthawk and teleradiology is a different subject altogether. To provide the fastest access to data there should be some amount of images near the consumers. This is typically a local cache or short-term storage (STS) often provided by the primary PACS system. However, in many circumstances VNA is now supplying the EMR image viewer directly in which case there should be some subset of images in close proximity to the EMR servers. Depending on the configuration you may need to setup a component of the VNA to act as that short-term storage locally. This is critical in a VNA first workflow which is part of the “deconstructed PACS” concept. Also important is the location of the data center which may be in the building, across town or across the country. The size of the cache varies based on workflows and user needs primary diagnostics may require a cache of up to 2 years’ worth of data on site, or none at all. When I say 2 years’ worth I simply mean enough storage to hold all data that was acquired in the last two years.
The second and more interesting idea is how to organize data within your VNA. Each vendor has their own terminology, so I will refer to them as “buckets”. How you put data IN to your VNA greatly effects how you get data OUT of your VNA. As we all know business cycles are cyclical, so there will likely be a period of acquisitions and growth, followed by a period of divestitures. The smart VNA team will plan for both. The simplest way to organize the data is in one big bucket, hey that’s a VNA right? With all data stored in one bucket, something like the accession number or more likely the study Unique Identifier (UID) which is by definition and standard unique throughout the world, would be how data is separated. To find data in your bucket you need to query for a number of fields, like patient name, DOB study type, or in a perfect world the UID. This is simple to setup, easy to get data in but hard to get data out. The other extreme of the spectrum is to create a bucket for everything. Data can be split into endless buckets, I have herd of some facilities that have one bucket per modality, per hospital, per year. Meaning they have hospital A x-ray 2017, ct 2017, MR 2017, then Hospital B x-ray, ct etc….. This is difficult to get data in, but very easy to find data and get it out.
Why would one separate data? It makes reporting much easier as many VNA’s (and PACS) don’t do the best job of analytics. It is also logical when looking at the facility level. The trick is to expand the view up to an enterprise of say 20-40 hospitals and related imaging centers and the problem becomes more complex and too many buckets becomes unsustainable. Having worked with many enterprises through the years I have settled into the “sweet spot”. Basically, I plan for an eventual divestiture. This is typically not done at the modality level, but at a facility level. No one has ever asked me to separate out and deliver only one modality, but often times an imaging center is bought or sold as is a hospital. This level allows for adequate reporting and tracking but also facilitates the smooth transition during a divesture.
In practical terms I have found that 4 walls define a facility, as does a business relationship. Hospital A may have a woman’s care center in house, an imaging department and an off campus urgent care center (UCC). I would create a VNA bucket for each, as well as each source system. PACS, CPACS, ophiology, surgery and eventually pathology are unique entities that should have separate data, as they will likely be replaced and upgraded on separate schedules. Therefore, they each get their own bucket. That does of course bring up the question of mammography. When there is a separate departmental system for mammography it is often connected into PACS. If there is a workflow reason to store these images into PACS then I would not create a separate VNA bucket. If there is no reason to then have the mammo system archive to VNA directly.
One last point, is that there is effort and complexity that goes into breaking up imaging streams into separate buckets. This setup cost must be weighed against the benefit of reporting and long term possible divesture. I can confidently say that when you go through the offloading and divesture process you will be very glad you have the data broken out because it makes the process significantly easier. In that environment the facility has already been sold and therefore it is difficult to justify resources to the process. You will want to be able to point the new owner to the data and let them retrieve it having confidence that the data is separated in your VNA such that they can’t see or accidently get to other data.
Please let me know what topics you would like to discuss