Health Imaging & IT - October 2007 - (Page S5) How quickly can a large dataset be opened on the client side? Pitfalls: Beware 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 5 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. Buyer’s Guide 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 5 w w w. t e r a re c o n . c o m http://www.terarecon.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.