PACS preferences: How to push a radiologist's buttons

2005 07 13 14 24 08 706

2005 07 13 14 24 24 706By his own words, Dr. Sam Friedman is just an average radiologist in an average practice in an average town in the southeastern U.S. A regular poster in's Discussion Groups under the tongue-in-cheek alias "Dalai Lama," Friedman says he can claim expertise on only one area: how he uses PACS.

For radiology, PACS has been nothing short of a complete and total revolution; PACS now quite literally defines how I perform my job. As a nuclear radiologist, I spend at least 85% to 90% of my day with the microphone in my left hand and the mouse in my right hand. If I'm not talking into the former whilst manipulating the latter, I'm not generating revenue for my group.

My goal in life is to do my work and go home; my PACS system should facilitate this and not get in my way. So what are the elements of a usable, unobtrusive PACS according to this humble rad?

Let's start with some general observations on PACS GUIs and their functions. First and foremost, every part of the darn thing has to work every single time, and that includes all those little buttons that you might use once a year.

The vendors will quote you "uptime" rates of 99.999%, but for some distributed systems, if just one workstation is up, well, that counts as uptime. Given that great uptime, please spare me hourly (or more) lockups and reboots. Been there, done that: we used an early form of a small PACS network that would fail literally on every other study.

One of my partners (who still likes the product) determined that pressing thus-and-so button, and right-clicking just there, while holding your left hand in the air and howling at the moon would keep the program from crashing. That may be, but most of us just don't have time for a crash-o-matic solution. The system needs to be bulletproof, and the least-technical member of your group should not be able to bring it down, even if he presses all the keys at the same time (I've seen it happen).

The interface must be clear, without distractions. The whole point of the process is to see the images, right? So why do some programs devote tremendous amounts of screen real estate to everything but the image? If I want the old report, or the demographic page, or the Nasdaq stock ticker, let me bring it up somewhere else, not where it invades the current image.

Some PACS systems out there seem to imitate the bridge of the Starship Enterprise up to and including the "gleeps" and "whirrs" from the controls. As a closet Trekker (we prefer that term to Trekkie, by the way), I love that idea, but not while I'm trying to work, please! Cute, but not what I really need.

Graphics on the various buttons can be a little underdone, too; that same crash-o-matic system I mentioned uses some very primitive low-resolution unintuitive icons on its various buttons, and at least one of those symbols seems to have been lifted from another famous non-PACS, but still copyrighted, source.

Make the interface clear and readable, with obvious designations. The same goes for menus. Some of the most sophisticated programs out there suffer from "right-click-orrhea" in which a right-click brings up a huge list of stuff. Now I don't mind if the right-clicker results in a well-organized and helpful submenu, but there are those who pile everything including the kitchen sink into this otherwise hidden area. No thanks.

Some systems make that right-click deluge (and about 1,000 additional settings) customizable, and all that for each modality, no less. Most of us would give up and use the default settings that came with the program. Keep it clean, clear, and simple. That's all I ask.

Oh, and by the way, how about having all the buttons work in a consistent manner? It is a real pain if, say, the magnifier works by left-click activation, then actual manipulation with the mouse wheel, while the window/level control is toggled on and off with a left-click and manipulated with moving the mouse immediately thereafter without clicking anything else, etc., etc. See what I mean?

These expensive toys come with a vast number of tools and gadgets, all intended to help us interpret our examinations. Do they really accomplish this goal? Well, let's see. In no particular order, here are some of my favorites (or not as the case may be):

RIS/PACS integration: The new Holy Grail. I don't think this is quite there yet. Yes, it's nice to get your reports brought up within the PACS window, and all systems do that with the appropriate connection. But does the PACS really need to feel the RIS and be the RIS, or could they just go out for dinner and a movie?

Work list: The unsung hero of PACS. You need to see what you need to read, yes? Well, there's much more to it than that. Tell me what needs reading, what is STAT, what can be put off until after lunch, is someone else reading something so I don't have to, are there prior examinations, and maybe tell me something about the patient like age and what idiot (oops, I mean honored referring clinician) ordered this test.

Hanging protocols: I like to think I'm flexible, but in reality I am set in my ways. I like my studies to come up in the same manner every single time. Hanging protocols are supposed to accomplish this. Properly done, you should simply set up windows and other settings the way you want them for a particular type of exam, click the button, and presto, the next exam comes up in the same way.

There are systems out there that require deep, dark, secret programming methods to set up, and somehow, no one ever quite knows how to do it. Hanging protocols can be totally confounded, however, if your techs are inconsistent in labeling the examinations. The PACS is stupid, after all, and can't just look at the image, decide whether it's the patient's head, tail, or something in between, and place it appropriately. Wine and dine your techs and make them swear to label the same image the same way every time. Tell them your happiness is their reward.

3D: Gotta have it for CT and some MRI exams. Period. Some companies have built-in multiplanar reconstruction (MPR), volume rendering, and such, and some let you connect to 3D software (or actual added-on computers). The absolute minimum acceptable to me would be MPR with the ability to do oblique reconstruction, and the ability to MIP (create maximum intensity projections) from there.

Volume rendering is really nice to have. It is very helpful to be able to push those renderings back to your PACS, which is often not available without the add-on programs. And by the way, make the included stuff intuitive, if you please. If I point to a lesion on one plane, I want the other planes to show me the same lesion. It's called triangulation, and some of the vendors out there must have slept through that class in high school.

3D cursor: Most MRI studies are done in multiple planes, and the DICOM headers tell you lots of spatial information if you actually look there. A 3D cursor uses this information to triangulate (see above), snapping the images in all sequences to the spot you select. Believe me, this is incredibly helpful.

Spine labeling: Done the easy way using that 3D information there for the taking in multiplanar studies (CT, MRI), I can label the individual vertebral bodies and disk spaces in five seconds. Done the hard way (by another company), it would take me 10 minutes if I were willing to slog through things that way, which I'm not.

Magnification: You thought there wasn't anything new here, right? Surprise! Several companies have figured out that image magnification should not go from the center of the image matrix itself, but should be centered where you select. It doesn't sound like much of a philosophical difference, but it saves the panning step after you've magnified the abnormality off of your screen and have to drag it back.

Linking: If you read a CT or MR that by some miracle has a prior study available, you want to link them together slice by slice. Just about every system will do this based on table position, so if one CT was performed with thicker slices than the other, the images will match up better.

A few companies still haven't grasped this simple concept, however. If your potential vendor can't do this, run, don't walk, to the next one. It can be done with one click, especially if you want to display multiple views of the same sequence with different window and level settings, for example.

The more clicks, menus, and buttons it takes to make this (or anything else, for that matter) happen, the less likely you are to actually use it. Some systems get bogged down if you link too many windows. That's too bad, because I like to link multiple windows.

Measurement/markup: I have to keep reminding some of my partners not to write on the screens with the red crayons -- that's what the markup tools are for, guys. I like the latest versions that let you place the actual measurement somewhere other than over the thing you're measuring. And if I want to make a hundred measurements on a single slice, I'm going to do just that; one system will only allow two measurements to appear on the screen at once, and that will never do.

Web client: Being rather set in my ways, I really prefer having the same interface at home as I do at work. The Web-based systems allow this; the older "big-iron" approach is to add on another whole system that taps into the main PACS database (and was usually acquired from some other company anyway).

In my own humble opinion, a PACS needs to let me do my work, and not get in my way. At the same time, it needs to give me a Swiss Army knife (dare I say MacGyver-esque?) set of tools to get the job done. These are not mutually exclusive criteria; rather, a properly deployed interface will make my work of interpretation much easier, and make my day much more enjoyable. Well, except for the BEs....

By Dr. Sam Friedman contributing writer
July 18, 2005

In addition to regular posts in's PACS Digital Community discussion groups, Dr. Friedman also maintains a blog at

Related Reading

3D navigation holds promise for image overload, July 11, 2005

Digital mammography presents PACS challenges, July 8, 2005

CARS opens with call for more PACS research, June 23, 2005

Integrated 2D/3D offers workflow, clinical gains, June 17, 2005

Healthcare IT delivers market advantage, June 9, 2005

Copyright © 2005

Page 1 of 775
Next Page