PACS, advanced visualization integration continues to evolve

In today's imaging world, advanced visualization is a necessity. When integrating AV technology into PACS, however, users have to choose from several approaches, each with its own pros and cons, according to a presentation at the recent Society for Imaging Informatics in Medicine (SIIM) annual meeting in Minneapolis.

In a talk at SIIM, Kenneth Wang, MD, PhD, of Johns Hopkins Hospital in Baltimore, shared his research team's concept of the continuum of PACS and advanced visualization integration, ranging from the traditional method of separate PACS and 3D software to a future vision of complete integration with a common user interface and a modular framework for incorporating specific software applications.

Although 3D is increasingly being used in clinical imaging, it still lags behind the widespread adoption of PACS. This is due to several reasons, including the belief by some that 3D isn't necessary for all cases, Wang said.

Also, the 3D lab model, which utilizes specialized hardware and software resources and specially trained staff, has been seen as a successful way to handle advanced visualization tasks. That's another reason why PACS and 3D haven't been tightly coupled, he said.

Wang also noted that while these are valid arguments, attempts to integrate these technologies haven't always been seamless, either. Until just a few years ago, the dominant mode of using 3D involved radiologists switching back and forth between PACS and 3D workstations, Wang said.

"On the other hand, wouldn't it be nice if we had a platform where you could do your routine 2D image review, but you could also say, I like this cardiac CT package from 3D vendor x, and I like this neurovascular package from 3D vendor y, and I really like this CT colonography package from 3D vendor z," he said. "And just start to plug these pieces into a single platform that can serve all of these needs, but lets you decide which of these pieces serves your needs the best."

Technology factors at play in PACS and 3D integration include the "thinness" of the 3D client, where the 3D image data reside, and where the image computation is performed. Another factor is how the different components of an integrated system communicate, Wang said.

Separate clients

The first level of PACS and 3D integration is the traditional model, utilizing separate turnkey client software for both PACS and 3D. In this model, the dedicated 3D system communicates directly with the imaging modalities and can also pull studies from the primary PACS archive.

It also bears responsibility for managing its own local dedicated archive and has its own specialized patient database and worklist functions. This method is easy to implement and offers freedom of choice among the 3D vendors; whatever PACS you have doesn't really affect that decision, Wang said.

However, this method suffers from being disruptive, forcing radiologists to move back and forth from each system. It's also hard to maintain and support and is not scalable. Furthermore, it leads to study routing issues and results in a duplicated archive and patient database.

The second level -- proprietary client-side integration -- involves the concept of context sharing to provide advanced visualization tools on the same system. The primary PACS application shares image data with a thick-client 3D system that can be run on the same client machine.

This has the benefit of using a single machine, with the 3D application triggered by the PACS software. However, this can also be a disadvantage, with multiple sizeable applications competing for system resources, he said.

"And you can start to become very dependent on your vendors," he said. "Traditionally, this type of arrangement has depended on a specific PACS vendor deciding to form a strategic relationship with another specific 3D vendor to develop these special-purpose connections. That really kind of locks you in terms of what your choices are."

This approach also involves using separate user interfaces, and data transfer efficiencies may not be fully realized, Wang said.

A third level of integration, using server-based 3D rendering in combination with a thin 3D client separate from PACS, addresses some of those disadvantages of the context-sharing model. It also doesn't require dedicated image transfers over the network, is scalable, and is easier for the IT staff to maintain and support, Wang said.

However, it still has the disadvantage of requiring its own archive and duplicated patient database, the necessity of performing dedicated DICOM transfers in the data center, and separate user interfaces, he said.

The fourth level of integration utilizes archive and database integration, enabling users to benefit from less hardware redundancy. The need for dedicated DICOM transfers is eliminated and 3D vendors are freed from developing database and worklist functions, Wang said.

However, it still uses separate user interfaces for PACS and 3D, he said.

The final level of the PACS and 3D integration hierarchy would use a client platform in which applications could plug into a common framework. These applications would provide their functions through a unified user interface, Wang said.

This would allow users to assemble a suite of the applications that best suit their needs, according to Wang.

Efforts are under way to develop this type of platform, including work by DICOM Working Group 23 and the National Cancer Institute's Cancer Biomedical Informatics Grid (caBIG) eXtensible Imaging Platform (XIP), Wang said.

By Erik L. Ridley staff writer
June 17, 2010

Related Reading

SIIM opening session highlights advances driving informatics, June 3, 2010

QA program cuts errors in 3D image processing lab, May 21, 2010

CAD, PACS pairing boosts lung nodule detection, saves time, April 30, 2010

How to maximize your chances of 3D lab success, January 14, 2010

3D software boosts diagnostic accuracy for Alzheimer's, December 1, 2009

Copyright © 2010

Page 1 of 775
Next Page