When it comes to enterprise imaging, a smart solution should include connectivity intelligence, sophisticated storage management, and a flexible, cost-effective package.
As medical imaging and PACS technologies move into the limelight of enterprise imaging, new challenges start to reveal themselves. What should our enterprise imaging strategy be? Should radiology own the solution, or hospital IT? Should all imaging data reside in one system, or should we take a federalized approach? What departments should be able to store their data in the enterprise system? Are the enterprise systems able to handle all of those data types? How will departmental workflows be affected?
In addition to these clinical considerations, sites looking to move into a comprehensive enterprise imaging paradigm must weigh the costs of achieving those goals. With new technologies such as whole slide imaging in pathology, the storage infrastructure capacity required to support a comprehensive solution can increase by at least one order of magnitude. Although the price of storage is always decreasing, the cost of a truly enterprise class storage management solution of that magnitude can be significant.
Beyond Radiology
Since the release of the initial DICOM 3.0 standard in 1991, PACS have been primarily focused on dealing with radiology images. Yet, other departments generate significant volumes of images, as well. Despite the many advancements in DICOM working groups and the release of many supplements for nonradiology disciplines, the fact remains that in today’s hospital environments, data is not always in DICOM format. Furthermore, even when data outside radiology is in DICOM format, it requires more than a radiology-centric database to manage.
Radiation oncology is a great example of a clinical specialty that makes very heavy use of digital imaging, and has arguably the most complex use of digital images. For cancer cases treated by radiation therapy, imaging is used throughout the care cycle, in screening, diagnosis, staging, treatment planning, treatment delivery, response assessment, and follow-up care. And these images are not generated in a single department—they are often acquired in oncology, radiology, pathology, surgery, and others. Images and other DICOM objects generated in radiation oncology involve highly complex relationships that tie together CTs used in treatment planning, anatomic structures drawn on those CTs, frames of reference, DICOM RT doses calculated based on the CTs and structures, and many others. Parsing these relationships is required in order to contextualize the patient case for clinicians and make the data available for further manipulations.
Another example of specialty-specific imaging needs is in digital pathology. While the DICOM Supplement 145 for Digital Pathology was officially finalized in 2010, whole slide image (WSI) scanner vendors are still in the process of implementing it into their solutions. And even if the manufacturers could start selling DICOM-conformant pathology solutions today, there is still roughly 10 years of legacy proprietary WSI files out in the world. An ideal enterprise imaging solution should account for this, and still provide access to the data.
What’s in a VNA?
It can be tempting to assume that a Vendor Neutral Archive (VNA) will be the panacea for all enterprise imaging connectivity and storage needs. The key question to ask VNA vendors is “What is your definition of a VNA?” Some vendors consider a solution that simply communicates with multiple DICOM PACS to be a VNA. However, the “V” in “VNA” should refer to more than just DICOM system vendors. To achieve true enterprise imaging, non-DICOM data types also must be supported. And for the DICOM side of the VNA, the intelligence layers for multiple specialties, such as radiation oncology as discussed above, should be supported. A VNA will be of limited value to a radiation oncologist if the only thing the oncologist sees when querying the system is a reverse-chronological listing of “studies,” as presented in most radiology PACS. The oncologist needs to know what images are associated with which treatment plan, which structure sets were drawn on those CTs, which doses were calculated based on those objects, and which doses can be registered with the CTs and structure sets.
Storage scalability also should be an important part of the VNA assessment process. One of the most-cited reasons for purchasing a VNA is to achieve vendor independence. If the VNA is to provide long-term access to the majority of imaging in the enterprise, then consideration for digital pathology and its requisite scalability needs should be taken into account in order to preclude a VNA migration in the future.
Accessibility Across Departments
Sharing data across departments requires a thoughtful approach to managing the data. Two general use case scenarios arise in this area.
In the first scenario, users in one department want to see images from another department as they go through their daily routine in providing patient care. For example, in orthopedics, surgeons planning their surgical case want to see x-ray or MRI data captured in radiology. Surgeons use these images to help decide the type and size of joint components to use for the operation. One might presume that the radiology PACS provides the necessary access to image viewing. However, the surgeon planning the case requires other tools not typically found in a radiology PACS. For example, surgeons need the ability to pull up joint templates to overlay on the x-rays. The surgeon would then mark fiducial points on the anatomy and want the templates to be anchored to the fiducials. There are several other specialized tools needed in orthopedics, as well. Due to the highly specialized nature of these specialty tool sets, it is advisable to take a best-of-breed approach, giving each department maximum flexibility in choosing the tools they need to provide the best care possible.
Given that the applications used in Department A require the use of images coming from Department B, we now have a connectivity issue to resolve. This can be accomplished via two different methods—push or pull. It would not be practical for radiology systems to divine which images will be needed in the various departments, so the push model is not ideal. A more efficient approach is the pull method, which allows the departments to use their own scheduling and workflow intelligence to decide which images are needed from radiology, and then pull those as needed. The oncology imaging server that XStor developed, for example, has the intelligence to know which cancer patients are currently active. The server can then query the radiology PACS on a schedule and/or ad hoc basis to discover what imaging studies exist in the PACS. Those studies can be either indexed or cached in the oncology server to be presented to oncologists or physicists seamlessly, as they are needed.
In the second scenario regarding access across departments, imaging is required in an environment in which clinicians from different specialties come together to look at information on the same screen, such as in tumor boards. In this collaborative setting, there are often oncologists, radiologists, surgeons, and others sitting in the same room to go through cancer cases, patient by patient. It is very desirable to have all of the imaging and related data available in a single system. Notwithstanding the best-of-breed comments above, the collaboration scenario differs from the first scenario in that the clinicians are not typically trying to use their specialized tools during tumor boards. In this case, a single system that brings together all of the information and provides a more basic level of visualization will suffice. In the XStor solution, images from various departments are presented in one system. There is, notably, one big issue that underlies this ability to store and manage all of these data types.
Massive Storage Required
Anyone who has been working in radiology but has yet to be introduced to digital pathology will be in for quite a surprise when they look at the storage requirements. In the time that XStor has been working in pathology, we have heard a similar story time and again: “We [pathology] talked to the hospital IT group and told them our storage requirements, and all we heard was jaws hitting the floor.”
WSI files are large due to the resolution at which slides must be scanned. A single, typical pathology slide (H&E stained and scanned at 40X objective, if you’re into that) is over 300 MB. A typical case may involve five to six slides, for a total of approximately 1.5 GB per case. A hospital pathology department planning to scan 50,000 slides per year should plan for annual storage consumption of 20 TB. Some large institutions generate 500,000 to 1 million slides per year, or 200-400 TB. These larger institutions need storage solutions in the petabyte (PB) range.
When you start to look at the systems that can handle these massive storage requirements, you quickly realize that you are in the market for a sophisticated storage solution. This is where the notion of storage management comes into play. An ideal enterprise imaging solution will include an advanced storage management system in addition to the connectivity and clinical domain intelligence features discussed above.
If you have priced out enterprise storage management solutions, then you know that there is significant disparity with the cost per terabyte at Fry’s. There is, however, a very good reason for the disparity: the two solutions are not equivalent. Enterprise storage management is a complete solution comprising both software and hardware components. Some of the advanced features you may find in an enterprise storage management solution include: RAID 6 or similar redundancy (disk failures are covered), scalability (the system can grow with your needs), online expansion (the system does not need to go offline to expand), replication (the data can be mirrored in a separate on-site or off-site location), integrity checking and self-healing (data do not get corrupted), thin provisioning (storage sizes are allocated up front without all of the hardware being in place), de-duplication (data are efficiently stored), and snapshots (the system can go back in time, if needed).
All of these very technical terms amount to two key points: the systems are extremely robust, and they are worth paying for in a medical setting.
Cost Considerations
Given the range of choices when purchasing storage, a hospital must consider several issues. The following costs should be analyzed when sourcing storage management:
- Up-front cost of system
- IT resources to install, configure, and manage system
- Future expansion cost
- Cost of downtime
- Cost of inefficiencies due to dealing with multiple vendors or multiple layers of a vendor’s organization
As an alternative to capital purchases, hospitals now have a myriad of options to purchase storage in a Software/Storage as a Service (SaaS) model. These options are designed to allow the customer to pay for storage without a large capital outlay. Evaluating these solutions requires diligence to understand all of the ongoing costs associated with the system.
Beyond storage management, hospitals also must look at the current costs of doing business the way they do it today. A large number of small inefficiencies can net gross inefficiency in aggregate. As budgets grow ever tighter, the tolerance for inefficiency drops. The effective implementation of technology can help to resolve this situation.
Strategies for Success
Managing imaging in the enterprise is more complex than it was 10 years ago. Thoughtful consideration of the issues outlined in this article can help in devising a strategy that meets current needs and positions an enterprise for success in the future.
In order to adapt with varying data flow requirements between departments, the image connectivity layer should be flexible enough to handle automated flows in a push or pull model, ad hoc requests, and contextualized information. The system should be able to store any of the image data from various departments, including non-DICOM images, but also able to only store indexes to data that need to reside in other systems.
Storage management should be extremely robust, scalable, and affordable. Patient care depends on the availability and integrity of information, so an enterprise-class storage management system is warranted.
We believe that an ideal scenario that aligns the needs of the CMO, CIO, and CFO is to have one vendor provide all three of the key needs detailed in this article: connectivity intelligence, enterprise-class storage management, and a flexible, cost-effective package.
Syed Z. Hamdani is founder, president, and CEO and Jim Weldy is VP of Customer Experience at XStor Systems Inc, based in Mountain View, Calif.
