Health Imaging & IT - October 2007 - (Page S7) 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, adaption 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 on-site 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 Buyer’s Guide 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! 7 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.