DICOM viewers

DICOM viewers are either web based (where the images live on a central server) and viewed using the local computers generic browser, or specifically designed local applications on the local computer. Blackbird offers both DICOM viewers, so we think we are able to give unbiased advice. We prefer thick clients and hope that the discussion below, at the very least, empowers you to make educated choices.

After the summary of advantages and disadvantages there is a discussion for those interested in understanding the technologies.

Web-based or thin client

Advantages:

• Easy to deploy
• Easy to manage
• "Heavy lifting" can be done on the central server (although it is debatable if there is any advantage to this)

Disadvantages:

• Expensive
• Slower
• Doctors wait time is increased
• Not hi-fidelity
• Bandwidth usage increased)

Thick client

Advantages:

• Less expensive
• Faster
• Doctor's wait time is minimal
• Hi-fidelity
• Less bandwidth
• Elegant degradation if there is hardware or network failure

Disadvantages:

• Harder to deploy
• Harder to manage

Discussion

Thick and thin clients

In a nutshell, thick clients produce a better experience for the doctor while thin clients are easier for the IT administrators to set up and manage. Besides offering a fast, hi-fidelity experience, thick clients are generally cheaper (but you should be mindful to ensure that your service contract is structured so that the ongoing management cost is capped and that cap is less than the license savings compared to the thin client). A good analogy is web based email (such as Gmail or Yahoo) v/s Outlook on your local computer. Outlook responds much faster (because the mail is downloaded in the background) and is richer - more hi-fidelity. This is because Outlook is a local application which also means that it needs to be set up on each computer, Gmail just uses your browser which limits how rich the experience can be, but entails zero set up. Like Outlook email, Blackbird's thick client is very quick for the doctor (the priors are routed to the thick client with front desk registration and the current images are routed as soon as the tech is finished scanning). Like email in Outlook the doctor just sees a quick, rich interface and is shielded from the magic going on in the background. A big downside to Outlook is losing all your email when you lose, or move, computers. Many people, myself included, therefore pop their Gmail account with Outlook. This means they get to work in Outlook, but if something goes wrong, the email is still available on the web. This is precisely the Blackbird thick client model.

Image transmission

One cannot scroll though a stack of images unless all those images have been downloaded to the local machine. This applies to thin as well as thick clients and is an important concept. It explains why "streaming" doesn't really provide any real gain.
Two factors affect image transmission speed:
1) Size of images.
2) Size of the pipe (network bandwidth).
The images to be transferred may be made smaller with compression. One type of compression is “streaming”, which is common in thin client PACS systems. Although streaming gives the impression of being faster this is not in fact true – the initial (non diagnostic) image is “painted” on the screen and then the rest arrives, “filling in the pixels”. Things such as scrolling through the stack or reformatting cannot be done accurately until the whole image has arrived.

Workload-balancing

Many practices are distributed geographically with reporting radiologists (RR) scattered over different sites. If one RR is quiet it is very useful to move the images to that site – this is what workload balancing means. The challenge is to ensure that remote images get to the reporting site as rapidly as possible.

Essentially there are 2 load-balancing models:
1) Thin client
With a Web Based PACS system, a PACS server is installed in a central site and images are routed directly to the main server over the network. If the web PACS goes down, the reporting stops! This extremely important to know - a poorly deployed Web PACS, without redundancy (read additional expense), can bring down an entire practice. Modalities are very simple in their image transmission rules. For example most cannot compress images. Thus, if required to send directly to a remote server, transmission will be slow and bandwidth intensive. Once images are on the Web Server the radiologist “pulls” images to their local workstation (note that they must pull them and wait while this happens). This may mean that the radiologist might be pulling images from a remote server in a distant location, for a CT study that was done in the next room! This is, of course, very inefficient and bandwidth extravagant. While load balancing is important, it is equally important to realize that most images are actually reported from the site at which they were generated. Therefore, sending uncompressed images from the remote site to the central server and then “pulling” most images back from the Web PACS is very inefficient.

To address this, a Web PACS over a WAN should have image caching servers at each site with a master database at the main site. This allows images at each site to be locally cached, therefore making better use of bandwidth and significantly increasing speed. The image cache however, is another server, and adds cost, and one still needs a workstation.
Actually, the local cache server also needs to be duplicated (and have sophisticated software installed) so that, if a cache server dies, your modalities still see the "address" or AET to which they have been configured to sent. I am not aware of any non Blackbird installation where this is being done. If the cache server dies, the modalities do not know what to do and work stops!

2) Thick client
Blackbird’s thick client solution is inherently faster and more bandwidth friendly than a web based solution. Modalities send to a local, inexpensive, Blackbird miniPAC which does several things:

• Allows the modalities to keep sending to the AET even if a computer goes down (the MiniPACS is actually more than 1 computer).
• Keeps current images and recent priors (about 3 months worth) available locally
• If there are older priors they are pulled from the archive on patient registration - i.e. they are available locally long before the radiologist has need of them.
• Current images are compressed and routed to the central archive when bandwidth is available.
• The miniPACS can also stream images to other facilities to facilitate load balancing.

Blackbird's thick client routers allow routing of images depending on rules e.g. RAD X is covering facility Y and all images from 2-6 pm must be available on his laptop (importantly, like Outlook email, this happens in the background - all the RAD sees is instant access to the images!).

It really does appear to be magical :)