CT-MRI

Buyer’s Guide

Decision Making for 3D Vendor Selection

Planning for advanced visualisation and workflow has become a critical element of any imaging practice involving modern MDCT and MR modalities. So, what are the right questions to ask, and what are the pitfalls? Here are some pointers that can help you to avoid purchasing a glorious 3D Technicolor paperweight!

What’s wrong with the 3D that comes with the scanner, anyway?

Generally speaking, nothing is wrong with it, as far as it goes. Most CT scanners come bundled with a 3D workstation offered as part of the package, and these workstations often have good software for providing 3D interpretation support. The problem is that there is usually only one supplied per CT, and purchasing an additional one is very expensive.

The CT technologist usually needs access to the workstation for various management tasks, and so there is competition for this valuable resource that can only be often have to interpret from 2D stations looking at static images created by technologists, precluding the possibility of pursuing a diagnostic decision tree that requires multiple consecutive questions to be addressed in 3D.

The key problem that has arisen with the introduction of MDCT is how to provide volumetric interpretation support to interpreting and referring physicians, and this is where the ‘bundled’ workstation falls down. Failing to plan for a broader 3D solution is planning to fail.

What’s a thin client and why do we need it?

Making advanced visualisation available to a broad enterprise poses some technological challenges. This is not like browsing the web where the processing power required is small and the data volume transferred is manageable. Modern MDCT datasets can run to gigabytes and the processing power needed to render them in real time 3D pushes the very limits of modern computing technology. As a result, there is tremendous value in being able to avoid moving the large CT datasets around to multiple computers across the enterprise, and in being able to avoid reliance on the processing power of whatever computer may be available out there to do the 3D rendering itself.

This is where the client-server architecture comes in and this is where it brings such an advantage. All the data can be centralised into one server, which can easily be located close to the modalities or PACS, such that the transfer is fast. This server, if equipped with a huge amount of processing power, can then provide rendering services to many computers across the enterprise which can run a simple application to control the server and receive a real time stream of images for display. This effectively turns every computer in the enterprise into a 3D workstation and if the power and feature set of the server is adequate, this becomes a really elegant, viable and cost-effective solution for delivering advanced image processing to everyone who needs it.

This ‘thin client’ approach, when implemented properly, is also excellent for PACS integration because, since it makes no significant demands on the client-side hardware, it can easily run alongside the PACS software without impairing its performance and still be available for instant access in 3D. Key questions to ask: What kind of rendering technology is used on the server side? Is it CPU/GPU based which has performance limitations, especially when serving many users at once, or is a dedicated medical volume rendering hardware solution used which can power many concurrent clients accessing large datasets? What is the clinical functionality? What features are missing on the thin client software compared to the conventional stand-alone workstation? Can you live without them?

What is the workflow for sharing work between the workstations and clients? Can a technologist prepare a dataset for interpretation and then deliver it in a form that can be interacted with and further manipulated on the client side?

What kind of administration and IT capability does the system have. This is now an enterprise server and it needs to be professionally equipped to meet enterprise IT needs like security and account management. How much bandwidth is used when a user is interacting with data? How quickly can a large dataset be opened on the client side?

Beware of solutions based on CPU or GPU technology on the server side, since these technologies face serious limitations when trying to provide advanced 3D services to many users at once. Beware a great demo of a single client. Ask to see multiple clients in operation at once to really understand if the system can serve a department or enterprise. Don’t only rely on the images the vendor brought to the demo – load some of your own and carefully evaluate the time before the data is available to be manipulated.

Beware solutions that actually download a compressed copy of the data to the client side and then use some client-side rendering power. These solutions have a higher client requirement and on slower networks, it can be really slow to load a dataset.

For that matter, what’s a thick client and when is it useful?

In the world of medical imaging, a 3D ‘thick client’ is a solution for 3D image processing which requires that the local computer performs all the image processing and that a complete copy of the dataset must be present on that computer before any processing can begin.

This architecture is particularly bad for an enterprise deployment, when you do not know in advance where a study will be needed for a certain type of interpretation. For example, if there are five stations where radiologists may work, and any of them may need to access a 3D interpretation tool, each of those stations will have to be made powerful enough to handle 3D processing, and potentially huge datasets will have to be duplicated across all stations, just in case a physician needs access.

Usually, the performance of the PACS station in question is impaired when doubling as thick client 3D solution as it can consume so much of the system’s memory and resources. When the thick client 3D solution relies on the CPU or GPU for 3D rendering, extensive use of CPU, disk and memory is required in the background simply to organize data as it is received. This can result in the active PACS application suffering a slowdown.

If the data is instead pulled ‘on demand’ when a physician decides that 3D interpretation is needed, then the time to transfer the data and any necessary time to prepare it for rendering in the CPU/GPU case has to be factored in, and for large studies, it can take minutes to open a case.

Even a sagittal reformat requires a little piece of every slice in a CT examination, so the entire dataset has to be transferred before even a single image can be generated.

This is why 3D is so totally different from 2D and for these reasons, deployment of a thick client solution into the enterprise is challenging at best in a controlled PACS environment, and entirely impractical to the broader imaging enterprise.

However, the advantage of a thick client is that it can have the most focused and powerful tools, and so it serves a valuable and effective role as a dedicated station for a technologist to edit and prepare cases for subsequent review or interpretation, or for a power-user physician who is interpreting a large number of volumetric scans every day, and for whom the complete feature set of the advanced workstation justifies the investment.

Key questions to ask: What features are only available on the thick client offering? What kind of rendering engine is used? Is it CPU/GPU based requiring time-consuming preparation of data? Evaluate the clinical functionality carefully with an appropriate expert.

Pitfalls: Beware careful preparation of data by the vendor on the demo system. The demo system will always have ‘champion data’ that shows off the system to its best effect. To really test a system bring a couple of datasets on a CD (make sure one has 2-3000 images at least) and ask them to work these up. This will really show several key important factors –How long does it take to get a case ready for review? After the files have been read from the CD, is there a further delay for preprocessing? CPU/GPU-based systems often have such a delay which is used to prepare the data for rendering, consuming CPU power, memory, and hard drive space for the working volumes.

How well do the tools work on these cases presented “cold”. No workstation is perfect, but they all seem to demo so well, but the important thing is not how well it does on a great case. How does it deal with really challenging cases?

Is there a limit to the number of slices a system can What’s the difference between the technologies out there? load at one time?

Make sure that the key features are demonstrated on full-size datasets with diagnostic-quality resolution to fully understand real-world performance.

Vendors sometime talk about remote control of a workstation.

Check to see if that locks out the workstation for anyone else to use it on a different case concurrently. It usually does.

What’s automatic preprocessing and how does it work?

Automatic preprocessing should take care of most of the routine tasks related to 3D image management, such as removing bones, calculating color maps to encode time-dependence, filtering for spherical objects (e.g. SPN), or removing the CT table from an examination.

When these tasks are automated and performed off-line, results are delivered to a technologist or physician without them having to initiate the process and then wait for it to complete, and hence, valuable time is saved. In order for this to work well, ideally preprocessing tasks should be centralized to a dedicated preprocessing server, because if they are performed on a workstation or rendering server that is also serving active users, the interactive performance of that system will be impacted while the preprocessing is being performed.

Preprocessing should never interfere with active interpretation sessions.

Key questions to ask: Is automatic preprocessing available? Is the task separated to a dedicated system serving the enterprise?

What features are supported (e.g., bone removal, sphericity filters, parametric mapping, CT table removal, centerline extraction)?

Pitfalls: Beware the claim that preprocessing is supported when actually all that is being done is preparation of data for 3D rendering. Vendors that rely on commodity graphics cards or off-the-shelf computers for 3D rendering often have to perform extensive preparation of the image data before it can be rendered in 3D, which uses additional disk space, consumes CPU power and adds minutes of delay before even basic 3D rendering can begin. This is entirely different from the “added value” of advanced preprocessing as described above.

What’s the difference between the technologies out there?

The key differences between the 3D technologies in the market relate to the technology used for 3D rendering, and the general architecture of the system. When the CPU of a computer is used for 3D rendering, a generalpurpose processor designed for Microsoft applications performs a specialized medical imaging task, often with poor efficiency and performance, even when compromises are made in image quality.

The same is true for GPU rendering, as “video cards” in most computers are mainly designed for computer games. These cards deal primarily with “polygon” graphics and typically do a poor job on anatomical data, with compromises in terms of performance and image quality.

As a result, such systems usually have to calculate additional information about every dataset that is received, just to prepare it for 3D rendering, which takes time, memory and CPU power, and the results must then be stored on the hard drive, consuming additional space.

The alternative is to use a dedicated hardware processor specifically designed to perform medical visualization where the slice data can simply be downloaded to the board’s memory without any delay or additional processing, with real time 3D following. Such a system can have the power and scalability to manage a true client-server deployment powerful enough for an imaging enterprise.

This fundamental technology question leads to the architecture differences between the vendors. Most of the 3D solutions developed by scanner manufacturers were conceived as extensions of the CT scanner and hence, they are fundamentally stand-alone solutions not well suited to an enterprise deployment. However, in order to meet the growing demand for an enterprise solution, adoption of this technology is sometimes offered to make it more accessible elsewhere, but the fundamental design as a stand-alone station impairs the effectiveness of this approach, especially when coupled with a CPU or GPU rendering engine that lack sufficient power for multiple concurrent users working on large datasets.

Third-party 3D vendors generally have some architecture to address the enterprise solution, which has an emphasis either on client-server or on “thick clients”, depending on their rendering technology platform. By asking the right questions you can usually detect the vendor’s preference – do they really believe in their thin client solution or do they rather try to promote the thick client option, and downplay the thin client as “only for referring physicians”? This should give a clue to the strengths of their system.

A truly capable enterprise solution should be based on a client-server solution powerful enough for true diagnostic interpretation by many users at the same time, on realistically-sized MDCT datasets. This will require a very powerful rendering engine in the server.

The demo – seeing through the smoke and mirrors!

Seeing is believing! With sophisticated 3D tools, an onsite demonstration is always a wise investment of time and effort. Vendors will bring their solutions and set them up for you to investigate, and you should ensure that each clinical specialty is well represented to get as many objective opinions as possible, at one time. This will save repeat demos and expedite the whole process.

Vendors inevitably like to control the demo situation, showing their best demo data and never missing a beat. However, the true test of the 3D system is how it responds in your hands, on your data. Bring a CD, grab the mouse and, at least for one case, the vendor should be able to show you how the system performs in your world.

In a real-world setting, a system will have to deal with multiple incoming cases throughout the day, and they will have to become available for review quickly. A demonstration system brought in by the vendor typically has all the demo cases pre-loaded and ready for review. To fully understand how the system will perform in the real world, test the vendor’s technology by giving them a big dataset – for example, 10 cardiac phases of 300 slices each, or a 2000 slice run-off examination, and ask them to load it.

Apart from the time it takes to get the images from the CD into the computer, how long does it take to make the dataset available for interpretation? Some technologies may require 5, 10, or even 30 minutes to get a large case ready to be reviewed, and this means some of that system’s power is always being used in the background for this task. This is a workflow delay you will have to budget for in your practice, so it’s worth knowing about it in advance!

A vendor with a truly powerful rendering architecture should be able to load a large study from a CD and go directly to 3D rendering.

Playing nice – thinking ahead for integration

Integration of advanced visualization tools with PACS is not essential, but it does help smooth the workflow and it can save a few additional seconds of locating the patient for a second time when you want to work in 3D.

If you have a PACS, check if the 3D vendor can integrate and if so, how easy is that to realize? Is there a cost on the PACS vendor side? If you have not yet purchased your PACS, ask the vendor about how to phrase the requirement for the PACS company to ensure that a smooth integration with 3D is part of the PACS package. They will be so much more co-operative before you place your purchase order!

Contact: Nehal Shah
nehal@terarecon.com
Mobile: 9920592475