PACS Slims Down — How PACS Clients Are Changing | CoActiv Medical
LinkedIn Login

Connect healthcare products, companies and hospitals with your LinkedIn network.

Facebook Login

Interact with your Facebook network around healthcare products, companies and hospitals.

Login With Facebook
MedicExchange Login

Enjoy Premium Access as a MedicExchange Member.

       Enter Your Email Address to Receive a
Copy of MedicExhange Member Demograhpics

Facebook Twitter Linkedin
Facebook: MedicExchange
Twitter: MedicExchange
CoActiv Medical PACS Slims Down — How PACS Clients Are Changing

PACS Slims Down — How PACS Clients Are Changing

Company News - CoActiv Medical
While a major advantage of the thick client is its ability to operate instandalone mode without requiring network connections to process imagingdata, from an IT perspective, thick clients can present islands that impedethe network information flow.

Thin client configuration eliminates many of the problems of updating and installing software uniformly to all clients. Most thin clients are now PCbased but still don’t store either imaging data or imaging applications locally, relying on the server and network connections to access both the programs and the data they process.

Anyone who’s recently purchased, installed, or upgraded to a new PACS has likely encountered at least part of the current debate about “smart” vs. thin or thick network clients. While discussions about client types were once exclusively the stuff of IT, the smart client label has become common enough that it sometimes crops up even outside those circles and has begun to be used specifically to market PACS servers and workstations. The problem is, there’s no consensus about what constitutes a smart client in a PACS network, not even among the vendors who apply the term to their products.

The confusion has reached the point where independent researchers and informatics scholars with no individual axe to grind have attempted to set some clear-cut definitions among client types for PACS networking. Until those kinds of classifications become widely accepted, network designers and PACS administrators will have to continue making their own distinctions among the many choices available. And as PACS spreads to departments outside radiology, they’ll also need to decide just how much PACS workstation “smarts” they want to distribute to any particular network location.

Thick Client Advantages
In the traditional IT debate, thin and thick clients each offer specific advantages, but each also has its own drawbacks. Imaging department staff may be most familiar with the conventional thick client, a dedicated workstation that performs all the functions needed for executing highly sophisticated work with imaging data but little else. Post-processing workstations that enable reconstruction of 3-D and 4-D MRI and CT studies, for example, are individually loaded with all the applications and intelligence required for those tasks and draw on PACS only for accessing the stored DICOM images.

Thick (or rich or fat) clients like these “provide a great user experience,” notes Rik Primo, director of enterprise imaging solutions for Siemens Medical Solutions. Siemens makes the Leonardo automated postprocessing multimodality workstation, Soarian healthcare process management and electronic medical record software, and syngo Imaging and syngo Workflow Web-enabled PACS/RIS system, all featuring the company’s proprietary common user interface. Primo points out that the true thick client supports built-in, high-level functions that run in a consistent applications environment under a particular operating system platform. “It also used to require specific hardware at the site, but with more powerful PCs becoming available, this requirement goes away,” he says.

“Many radiologists love to work on [thick clients], but thick clients can be very costly to deploy and even costlier to maintain,” Primo says. Because such highly specialized, high-functionality devices must be individually loaded and tested each time new applications or software updates are required, it may be necessary to schedule and dispatch personnel and reserve workstation time weeks ahead to keep some nodes working while others are upgraded. And while an advantage of the thick client is its ability to operate in standalone mode without requiring network connections to process imaging data, from an IT perspective, thick clients can present islands that impede the network information flow.

Thick Client Drawbacks
“The thick client can absorb a lot of administrative resources because you can’t just push the code out [over the network to all the workstations] because you may interrupt work in progress,” says Primo. “So, the problem for many users really stems from the dramatic growth in the number and kinds of tasks that users want to perform at the PACS workstation, [such as] 3-D reconstructions and virtual colonoscopies or other advanced image processing applications. At the same time, doctors also want to retrieve patients’ electronic medical records or review nonimaging data in the radiology information system.”

And as PACS applications become more complex, they need to install more code and use more resources. Many applications can’t share software components or do so poorly, which can result in significant response time lags and glitches ranging from momentary image freezing to system crashes. Says Primo, “If you had to install all of these new applications on a conventional PC workstation as thick clients, it would be a nightmare requiring hundreds of gigabytes of separate applications, all of them modifying the registry. That’s the kind of situation that IT people [working with Windows] use the expression ‘DLL hell’ to describe.”

Thin Client Benefits
The thin client may seem to solve all those resource issues. Today, browser-based thin client architectures deploy powerful, high-performance, high-speed servers to provide processing and intelligence on demand. Clients are interconnected through the hospital backbone network, using servers that run dedicated protocols to communicate with multiple workstations operating different applications concurrently. This approach enables facilities to install client software to workstations virtually anywhere, even remotely, and to move imaging directly to more varied types of clients and locations.

Thin client configuration eliminates many problems of uniformly updating and installing software to all clients. Most thin clients are now PC-based but still don’t store imaging data or imaging applications locally, relying on the server and network connections to access both the programs and data they process. Instead of running PACS applications in standalone mode at each separate workstation, a processing server streams imaging data to any client application on the network on command. For sophisticated applications like 3-D reconstructions or 4-D echocardiograms, the server continuously updates the PC screen in real time as all the slices are rendered.

Today’s powerful servers can deliver excellent image quality and high responsiveness, so radiologists and others working with intricate gigabyte imaging files no longer suffer from the once-common effects of multiple users on the network. And typically, a single integrated user interface supports access for both highend clinical applications and less complex conventional PACS functions. But in many cases, imaging applications must be simplified to run as thin clients, which often means reducing or eliminating features end users may want, including help and cut-and-paste functions.

Outsmarting the Thin Client
“Traditionally, thin clients are not designed to move and manipulate large image files, although they are fine for things like RIS applications, for instance,” says Ed Heere, president of PACS maker CoActiv. He adds, however, that the flexibility and security offered by today’s distributed networking means that PACS servers and workstations can be configured to overcome most of the old drawbacks.

CoActiv, for example, does not rely on virtual private networks tunneling across the Internet to deliver data and applications processing, as older networks often do. CoActiv’s EXAM-PACS customized software links multiple widely dispersed sites using client-server technology at each end, thus enabling all sites to operate as an integrated system. Using encrypted 128-bit secure sockets layer communications, CoActiv can automatically transmit executable files (including updates) to local and remote machines almost instantaneously, without worrying about interrupting workflow or tying up local resources. Image data from multiple modalities can be uploaded to the on-site servers or directly to client servers hosted at the company’s data centers. Client servers provide short-term storage, while archiving is done via the company’s secure storage facility. Temporary local and remote archival storage is always active online.

In a CoActiv network, workstations and servers are standard, off-the-shelf, high-performance PCs from highend manufacturers such as Dell, Hewlett-Packard, and IBM. Such devices are easy to obtain, fast to install, uncomplicated to use, and easier to maintain and service—the essence of a thin client but with independent local processing power.

So just what is or isn’t a smart client in today’s market? Primarily, it comes down to how much and what kind of processing can be accomplished at the workstation without network connection, but many details are obscure to those outside IT, as outlined in the accompanying sidebar.

Not So Smart?
“I think this is more a war of words than a war of technologies,” says Heere. “I consider ‘smart client’ a marketing term, and different marketing departments may mean different things when they use it.”

He adds, “We consider that we use thin client communication technology for remote, validated access to an internal network, but our image processing applications are installed to the local machines.” The result is complete transparency among applications, at least as far as end users are concerned. “And smart radiologists want to keep it that way,” says Heere. “They want access to all the data and functions they need, instantaneously, but they don’t necessarily need to know all the details of how that’s accomplished. This way, all the applications can be built into the client. We don’t need to use any third-party software, and we don’t have to worry about DLL or program library [incompatibilities]. Upgrades are automatic, and the system restarts the application, not the PC. And all the [PACS] clients on the network are 100% nonreliant on the operating system DLLs or program libraries.”

Primo also eschews the “smart” label: “We call ours a hybrid model,” he says. Because the Siemens syngo Image Distribution is based on standard Windows technology, it allows integration of PACS functions into any existing infrastructure, such as a local- or wide-area network, using plug-and-play modules for standard workflow operations (lsuch as data management, image distribution, image reading, archiving, and reporting). This architecture not only supports a high degree of configuration flexibility, including remote teleradiology, it also streamlines installation and updating of PACS applications across the network.

“We use thin clients and install the applications most often used by radiologists on the server, and they can be ownloaded to workstations using a kind of floating license,” he says. “So the radiologist can manage 3-D reconstruction, for example, from the workstation with the server doing the reconstruction.

“This way, in case you need to do a lot of processing on a local workstation, you can get the performance of the thick client, and it can be available to multiple concurrent users.” However, Primo notes, “For radiologists who are going to be doing the most demanding applications all the time, we would still install a thick client that can fully operate as a standalone site, disconnected from the local network if it’s needed.”

Integration, Not Isolation
The current thin vs. thick vs. smart debate should probably focus less on the clients and the end-user applications and more on the networking and communications technology. Granted, PACS administrators and end users historically feel that their application processing needs are vastly different from that of other departments. But as direct medical imaging usage spreads throughout the healthcare organization and as radiology begins to share its once isolated image data stores, PACS applications are being seen less as the exception outside the information flow and more as another vital element within the complete network.

Indeed, Heere says his company’s roots in the IT world, rather than in medical imaging per se, is one of its biggest strengths: “We’re an IT company that evolved into a PACS company because we saw the need for our skills and tools. We have several large installations now where we’ve helped radiology departments in enterprise networks solve what we call ‘the big exam problem,’ meaning they need to provide fat clients outside radiology—for example, cardiology. We’ve encountered more traditional PACS vendors telling hospitals that they can’t integrate cardiology and radiology and also make that data usable remotely, but our combined thin-thick client approach can make it all work together. In fact, many of our hospitals, even some doing more than 75,000 exams a year, operate our PACS without a dedicated PACS administrator.

“We’re seeing more and more facilities, and also PACS companies, beginning to move in this same direction,” adds Heere. “Especially as teleradiology gains importance, the real endpoint is how easy, how fast, how transparent can this whole process be made for the end user, regardless of what the particular application may be.” In fact, he says, in many situations, no separate thick clients are required anywhere in the network.

“Doctors don’t care how it’s done, as long as the data they get is delivered quickly and accurately. And referring doctors want the same access as the diagnosticians,” says Heere. “This technology delivers essentially the same functionality everywhere on the network.”

Getting the Best of Both
Primo isn’t sure about the demise of the traditional thick client yet. “For the most demanding applications, there’s really not an alternative to the thick client, and I don’t see that changing in the short term,” he says.
Under any name, he agrees, today’s newest user workstations are more complex than earlier versions. They offer greater functionality and security as well as greater flexibility. Even so, whether thin, smart, or hybrid, these types of clients must operate as part of the larger network configuration and can’t provide the standalone processing power of the traditional dedicated imaging station. And sometimes, he adds, whether a client is smart or not just depends on where it is configured within the network.

“It seems there are always at least two ways to go,” says Primo. “As the Cheshire Cat says in Alice in Wonderland, the right way depends on where we want to go. In IT and PACS, we want to go down the middle of the two extremes: great functionality and easy maintenance. We do want the best of both worlds.”

Spotting Smart Client Attributes
Googling the phrase “smart PACS client” will net you an array of definitions, essays, and opinions, but one of the most comprehensive and least technically obscure guides was written by Microsoft engineer and blogger David Hill. His full entry, “What is a smart client anyway?” can be found at http://blogs.msdn.com/dphill/articles/66300.aspx. In it, Hill details these five key features that indicate a smart network client:
• can use local hardware and software resources, such as memory drives, scanners, phone lines, etc, and anyprograms or interfaces needed to operate those devices;
• capable of operating as part of a larger distributed network, including the Internet;
• can operate offline and intelligently manage network reconnection and database updating;
• enables intelligent (typically automatic) software installations and updates; and
• flexibly supports multiple functions working on a common platform, typically including different devices anddiffering software versions.

Source: Radiology Today