While the advent of digital breast tomosynthesis (DBT) in the U.S. has added an exciting weapon to the breast imaging armamentarium, these new capabilities have also led to significant image management challenges. DBT adopters need to be aware of and plan for issues such as large file sizes and proprietary file formats.
For many years, mammography was the one film-based modality that strenuously resisted the inexorable trend toward digital imaging. When digital mammography systems were finally deployed, the modality's challenging display characteristics initially kept the images separate from the mainstream PACS, particularly when viewing for primary interpretation.
Dr. David Clunie.Nowadays, with the addition of mammography-specific features to PACS and widespread implementation of the Integrating the Healthcare Enterprise (IHE) Mammography Image integration profile, full-field digital mammography (FFDM) is relatively well integrated. The ordinary storage and distribution infrastructure has been leveraged, largely retiring the need for separate dedicated systems. This is consistent with the trend toward integrated enterprise-wide solutions replacing departmental islands.
Enter breast tomosynthesis.
Unlike conventional four-view digital mammograms, with a large matrix size for each image but a single frame for each view, tomosynthesis reconstructs multiple "slices" through each breast from multiple projection views. Typically, there are between 50 and 100 slices per view, depending on the size of the breast, and each is of a similar matrix size to an FFDM image. This represents a dramatic increase in the size of each study for which tomosynthesis is used in place of or in addition to conventional FFDM.
Uncompressed, a single tomosynthesis image averages about 450 MB in size. There is no evidence yet that it is safe to perform irreversible (lossy) compression on these images; nor do the Mammography Quality Standards Act (MQSA) regulations permit it. Reversible (lossless) compression is relatively effective, achieving roughly a fivefold reduction in size when state-of-the-art compression (e.g., JPEG 2000) is used.
Assuming the recommended practice of four views, the compressed total is roughly 350 MB per study, not including the projection views or an additional set of FFDM or synthesized FFDM images. This is larger than a typical CT chest, abdomen, and pelvis image of modest slice thickness (2.5 mm), similarly compressed.
That is quite a lot of data to transmit and store, particularly when one considers the relatively high throughput of a dedicated screening facility. It is certainly a nontrivial amount of data to include in one's consideration of capacity and cost of the archival and distribution infrastructure.
Storage and display
The information is not in and of itself more challenging than any other bulk data. As long as it is in a standard DICOM format, contemporary PACS and archives should have no trouble storing and regurgitating it. One just needs to plan for the increased utilization.
Like FFDM before it, display of breast tomosynthesis images is challenging. All of the well-accepted mammography viewing requirements, such as correct orientation, hanging of multiple views with priors for comparison, annotation, display with comparable size, true and actual size, measurement tools, and correct grayscale handling are equally applicable to tomosynthesis images.
For tomography, there is an additional need to be able to smoothly scroll at a rapid frame rate, without skipping frames, through all the slices for all the views displayed on the large 5-megapixel displays required for mammography. Ideally, this should be synchronized with same-size contralateral and prior views.
Some users prefer automated cine in addition to manual scrolling. This level of display performance is achievable with contemporary hardware and software, but it does require an extra effort on the part of the developers of workstations and viewers.
The viewer needs to enable the user to compare current and prior FFDM and tomosynthesis images at the same size, whether it be true or actual size or user-selected. The user needs to be able to annotate abnormalities on individual frames, store these in a standard format, and alert subsequent reviewers to the presence of such annotations, since they are easy to miss when scrolling through multiple frames. It is desirable to be able to merge all such annotations from different frames of one tomosynthesis view into a single presentation on a real or synthesized FFDM (maximum intensity projection) view.
These requirements apply not only to the radiology reading station, but also to the viewers available to referring physicians through the PACS, vendor-neutral archive (VNA), cloud image sharing solution, and on CD or DVD. Interactive viewing can achieve acceptable performance from the user's perspective by employing both on-demand and prefetching solutions, assuming that sufficient network bandwidth is available to allow for a high reading throughput, particularly in a screening setting. Real-time telemammography over low-bandwidth connections is challenging.
Viewing interoperability
When FFDM was first introduced, different implementation decisions by different vendors compromised viewing interoperability, despite use of the DICOM standard. Accordingly, the IHE Mammography Image integration profile was developed with significant input from both users and vendors. This led to a significant improvement in the user experience, provided a road map for third-party implementers, and resulted in higher-quality PACS viewers overall.
Even though there is currently only one tomosynthesis modality vendor (Hologic) with an approved product in the U.S., that situation is not likely to prevail indefinitely; there are already other commercially available systems in Europe, and there is also growing activity among third-party viewer developers. Accordingly, there is probably a need for an extension of the IHE profile in the next annual cycle to specifically address additional features required for satisfactory tomosynthesis viewing.
As yet, there is only one tomosynthesis computer-aided detection (CAD) product on the market, Hologic's ImageChecker 3D Calc CAD application for microcalcifications, which has the CE Mark in Europe. As additional products arrive, they will present an additional challenge to the workflow and deployment infrastructure. Questions will arise as to what type of images (e.g., raw or processed projections or reconstructed slices) will need to be sent to the CAD system as opposed to the PACS, in what form the CAD results will be encoded (necessitating extensions to the DICOM Mammography CAD Structured Report object), and how display systems will interpret and render the CAD marks to present to the user, all in an interoperable manner.
Migration issues
For sites that have or are planning to deploy tomosynthesis and integrate it with their existing PACS infrastructure, there are additional challenges. First and foremost is the need to consider the PACS upgrade path, since proper support of tomosynthesis may require DICOM Service-Object-Pair (SOP) Class configuration and viewing software that is not supported by older software platforms.
Be sure to check what is required before committing to supporting tomosynthesis; hopefully, it's a software upgrade and perhaps a new license, rather than a "forklift" upgrade. Consider this factor, also, if planning a total PACS migration in the same time frame.
An additional challenge to consider is the need to avoid (or migrate from) legacy proprietary image file formats. The first vendor in the U.S. market, Hologic, elected to use a proprietary variant of the DICOM Secondary Capture object in its Selenia Dimensions system, which received U.S. Food and Drug Administration (FDA) clearance in February 2011, even though there was already a DICOM standard for breast tomosynthesis slices (Supplement 125, published in August 2008). Even in Europe, where a CE Mark was issued in 2008, initial rollout was slow, and the proprietary format could have been avoided entirely after early clinical (preapproval) studies.
This proprietary format hides the tomography pixel data in private attributes inside a secondary capture DICOM object with a dummy (middle frame only) image. Its use allows storage in most PACS, even obsolete ones, as long as the PACS does not discard the unexpectedly large private data elements. Unfortunately, it makes the user completely dependent on a proprietary workstation for viewing.
The net result is an archive filled with priors that are unusable by third parties without conversion, as well as digital media handed to patients that is unusable by anyone without a Hologic SecurView workstation with tomography capabilities. Upgrading to a contemporary PACS (or PACS version) that supports the standard tomography object for storage and display becomes a significant migration project.
Another approach
An alternative strategy to support legacy PACS and permit adequate, but not optimal, viewing might be to have the modality produce standard breast tomosynthesis objects but then convert them to multiframe secondary capture with standard compressed pixel data for transmission to the PACS, since these are already widely supported; such objects could later be changed back to the standard object just by changing the SOP Class unique identifier (UID), reducing the migration burden and complexity.
Fortunately, the current version of Selenia Dimensions can create standard DICOM Breast Tomosynthesis SOP Class images. At the time of writing, though, even some new deployments are still configured with the proprietary format, such as to support an obsolete PACS version. This leads to proliferation of the migration problem.
On a positive note, Hologic has assisted potential third-party PACS and viewer implementers by providing sample objects in the standard format, has encouraged their adoption, and can convert the proprietary format objects to the standard format on request. There is talk of deploying converters to the field, possibly with a cost, though, and the vendor has steadfastly refused to publish the details of the format.
Further confusion arises when the projection images are taken into account. These, too, are stored in Hologic's proprietary format and can be saved to the PACS but not viewed. DICOM's Mammography Working Group 15 is belatedly developing a new object to encode these as standard multiframe objects as well.
In the interim, the vendor could have chosen to save the projection images as ordinary viewable FFDM objects, but it did not. For now, this means that projection images will be orphans in the PACS, unable to be viewed and needing migration later should they be needed as priors for viewing or for CAD.
In summary, though breast tomosynthesis images are challenging for the informatics infrastructure in terms of size, features, and interoperability issues, the future is relatively bright. A good strategy to mitigate the concerns, coupled with a beefing up of the underlying infrastructure in some cases, and the avoidance of dependence on proprietary technology, should lead to this important new modality being able to participate as a good PACS citizen in fairly short order.
To assist sites and vendors in addressing the challenges, the Society for Imaging Informatics in Medicine (SIIM) is holding a forum -- called Digital Breast Tomosynthesis and the Informatics Infrastructure -- at its upcoming annual meeting in Grapevine, TX. The forum will follow the closing session on Saturday, June 8, and will run from 5:15 p.m. to 7:15 p.m. All are welcome to attend. Please refer to the SIIM2013 website for details.
Dr. David Clunie is a radiologist, medical informaticist, DICOM open-source software author, editor of the DICOM standard, and co-chair of the IHE Radiology Technical Committee. He is currently the part-time chief technology officer of CoreLab Partners (formerly RadPharm) and is also the proprietor of PixelMed Publishing, which publishes educational material about DICOM and related subjects, in addition to developing open-source and custom software and providing consulting and training in the field.
