How do you architect your VNA?

 

 

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.

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

 

 

How Big is a Mammography Study??

 

How big is a mammo study?

It depends. I was recently asked what is the average size of a mammography study. I asked for clarification, what do you mean? I received a somewhat strange look and the response mammography, you know breast imaging….

Bottom line up front, somewhere between 20 MB and 1GB per exam

The problem is that there is no easy answer to that question because well, it depends. For starters there is as we all know a huge difference between tomography and plain film mammo. So averaging the two would vary greatly depending on the ratio of tomo to mammo. If you look in your VNA they will often share the modality code MG so how do you tell the difference? Number of images? You could assume that anything over 10 images is tomo. Ok so the next way to tell would be to get into your database and do a query for the SOP Class Breast Tomosysnthesis Image Storage (1.2.840.10008.5.1.4.1.1.13.1.3) however, you will find that within a study you will have a few tomo images and plan mammo images stored. Then again, you may be working with a popular vendor who stores the tomo images in a proprietary and much small format using the secondary capture SOP class (1.2.840.10008.5.1.4.1.1.7) easy right? All you need to do is isolate out the 2D exams from the exams containing a 3D image, then find out if you are using the BTO SOP class or the secondary capture SOP, THEN you can average your exams and get the average study size, right? Well sort of..

NOW we need to determine if they are compressed or not. To figure that out you need to look at the transfer syntax. Many modalities will default to Implicit VR Endian, which is transfer syntax (1.2.840.10008.1.2) this is uncompressed. Many PACS will take the syntax that the modality sent and refuse to change it for fear of impacting image quality. Therefore, the study is stored on disk and in the long-term archive or VNA in the same format. Unless you get into inbound and outbound compression which is a whole different topic. There are of course many different transfer syntaxes with varying compression, but we will take the other common one, JPG 2000 lossless (1.2.840.10008.1.2.4.90). Either compression can be applied to any of the SOP classes described above.

So, the question stands, what type of mammo do you mean? Standard format or proprietary (but very common) and compressed or uncompressed. How you ask the question will skew the answer dramatically.  Given the trend in the market tomo is growing so the average in Dec 2017 is very different than the average in Dec 2016.

If you have read all the way through this, the breast tomo format lossless compressed averaged out to be 711 MB, while the secondary capture format also lossless compressed averaged in at 194 MB.

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org