Saturday, March 25, 2006

Radiology, PACS, Clinicians, and Rocket-Science

"semila" started an AuntMinnie thread with the following posts:

Has anyone other than me concluded that the PACS market in general has become a big yawn? The conversations on these boards has deteriorated into techie minutia and nothing exceptional has come from any of the major PACS vendors in recent years. Price erosion continues to dampen the market and no new entries have come into the space in the past couple years. PACS has become a "cog in the wheel". Digital Imaging will in most cases now, be sold with larger information systems and will be a module that can be "turned on or off". PACS is not radiologies baby anymore, but one of the many niches that will make up the EMR/EPR. Aunt Minnie would be wise to diversify the content of its site to begin including more foward thinking discussion.


. . . PACS genrerally has one purpose: receive images from modality, compress, store, display and distribute. This isnt rocket science folks, and other industries do this all the time, they just dont have to answer to HIPPA! The foward thinking focus here should be how PACS fits into information systems. The small markets adoption of PACS is irrelevant.
Another note: I for one am a fan of image interperetation being taken away from radiologists and infused into the doctorate programs of the "real" docs, like cardiologists. Doctors that sit in dark rooms or in front of computers providing varying degrees of experience in diagnosis without ever actually seeing a patient is beyond me (teleradiogy - ugh). I am sure I touched a nerve with this one, but c'mon.........really. How bout this Dalai Lama cat.........this guy sounds more like an IT person than a doctor. Scary.

OK, Semila, you did indeed get my attention! I posted a more limited answer on AuntMinnie due to restrictions on the size of individual responses, but here it is a bit more fleshed-out.

Gee, where do I begin.... First off, I'll take the IT comment more as a complement than anything else, although I am no doubt considered a "scary cat" by both IT and physician camps. I'm in progress on my next AuntMinnie article concerning this particular relationship, and it is guaranteed to touch some nerves. As it turns out, I have degree in Electrical Engineering, major in Bioengineering, minor in Computer Science, so I do have the ability to “talk the talk” of IT, and occasionally even to “walk the walk”.

I tend to agree with semila to some degree about the level of "rocket science" or lack thereof in PACS. It has indeed been commoditized and often just comes as an added bonus with a suite of scanners or other computer systems. Rather like a prize in a cereal box. As an engineer, I do keep in mind that PACS at its core is simply the movement of image data from place to place, and this is not “rocket science” in this day and age. Semila points out that HIPAA plays a major part in its function, but as I found in researching my last article, one can use HIPAA as a template, and not hide behind it to avoid doing your job as some IT folks are wont to do.

At this point, I am going to throw in something so obvious, yet so obnoxious, that it will certainly generate some nasty commentary. So be it….. PACS EXISTS for the radiologists. Ha! Try to disprove that. As Pacs_Guru says, we radiologists are now blind without IT, but IT has no reason to exist without us. PACS defines how I do my job, which is to interpret radiographic and related imaging studies. Without PACS, the patient would still get the study and get it read, but this process would utilize film or perhaps reading directly off of the scanner’s monitor. There is a lot of technical jargon involved in the processes of “receiv(ing) images from modality, compress, store, display, and distribute”, even if it is pretty mundane. Those of us who come here are interested in these “boring” things, and they need to be discussed.

No doubt there will be eventual incorporation of PACS into the wider information systems; we are seeing that already to a minor degree. But since PACS is a tool for radiologists, I will push the very biased view that its next evolution/revolution needs to be in radiology workflow. I have only a vague idea, personally, of where that needs to go. When I went into private practice, 16 years ago, the work model was not so very different than it is today. We would pile in at 8AM, grab 20 or 30 jackets off a stack of 100 or so, put the films on the viewer, interpret them by dictating into a tape-recorder, with demographic information, history, etc, from a paper requisition, take the film down, sack it, stack the jacket, and then do the same for the next patient. The workflow today is to some extent an electronic version of the film days. We sign on to the PACS, select the appropriate worklist, queue up the first study, dictate it into the tank (eventually to VR), using demographics gleaned from the HIS/RIS system, and push the button removing this exam from the list and queuing up the next. (The sweat-shop/factory analogy is apt much of the time.)

The real difference between film and PACS is that we can manipulate the images we view, and in the case of multislice CT, we can add a number of tools to the armamentarium, including cine-view and the various flavors of 3D such as MPR, Volume Rendering, Virtual Endoscopy, and so on. At some point, there will be some radically different paradigm for reading, although it would have to go hand-in-hand with advances in imaging technology as a whole. We are already seeing that to some extent with whole-body CT. Instead of an X-Ray here and there, our patients are being scanned from head (almost) to toe. There is a great push in this direction from the ER, which wants us to do all their diagnosis for them. Thus, our trauma center often orders “Man-Scans” including CT’s of the head, neck, chest, abdomen, pelvis, total spine, at least one extremity, CT PA gram, and CT Aortogram. One stop shopping, folks. Much as I resent doing the ER’s docs’ thinking for them, I realize that this is where we are in 2006, and somehow my workflow needs to incorporate this monster. Here is where a good, unobtrusive PACS system can help me. All of the imaging needs to be delivered to me in a way that I can read it as efficiently as possible. How about the exams that benefit from 3D (Aortogram, spine CT’s, etc.) being automatically displayed with the MPR’s or VR’s necessary for rapid interpretation? How about automatically displaying relevant priors, images, lab data, etc? That is just the tip of the iceberg, and there are many folks much smarter than I am out there working on all this.

Semila proposes that radiologist need not be the masters of imaging, that other specialties could do at least as well at it. I’m trying very hard not to take this as an attack on my profession, but that is quite difficult as you might imagine. I am assuming that
semila is not from the US based on his/her diction, and perhaps things are different is his/her native land. I cannot put it better than did James P. Borgstede, M.D., head of the ACR, in his article “Chipping Away at Imaging” in this month’s Journal of the American College of Radiology:

One of the first canons radiology residents learn when they enter training is to look at the entire image. We are taught that this precept separates us from other physicians who view, but do not interpret, images. Image interpretation, as we all know, is difficult. Sometimes we’re given histories, and occasionally, we even have the opportunity to talk with referring physicians to assist us in our interpretations. Both written histories and dialogues usually focus on clinicians’ suspicions from their histories and physical examinations, assuming they have performed them. Clinicians direct our attention to parts of images or to certain organ systems. By adhering to the first tenet of radiology, we avoid missing unsuspected, but significant, findings included in studies. How many times is a computed tomographic scan requested for pulmonary embolus only to find that the patient has a rib fracture or subdiaphragmatic process that accounts for his or her symptoms? Radiologists, looking at the entire image, hopefully detect the significant abnormalities that are commonly missed by our clinical colleagues only looking at the portions of the studies piquing their clinical interest. These nonradiologist “viewers” of images mentally chip away at imaging examinations, excluding the areas they perceive as irrelevant. By viewing examinations with tunnel vision, they miss significant observations. It seems today that chipping away at images, and in fact our entire specialty, is an avocation of many individuals and groups inside and outside of medicine.Clinicians are keen on focusing on the parts of images within their specialties or subspecialties. Computed tomographic scanners have even been created to assist them in carving away unwanted portions of images. Cardiac imaging is one example; scanners have been created that remove everything from images except the heart. Therefore, physicians focused on the cardiac portions of scans do not have responsibility for the distractions created by bones, soft tissues, lungs, and other mediastinal structures. The companies marketing such scanners emphasize to nonradiologists the freedom from liability and responsibility such scanners create: “If you can’t see it, you don’t have any responsibility for it.” The companies in turn market the same products to radiologists under the pretext of protecting radiology for radiologists by excluding the ability of others to view portions of images that, in the companies’ opinion, are the purview of radiologists. What a help these companies are in chipping away at the images! Unfortunately, patients suffer in this scenario because they may require repeat scans to look at the structures excluded from the original examinations.

The point is that radiologists are trained for many years to interpret the entire image. Remember, what we are looking at is ultimately the anatomy and pathology, not just an image of shadows and density distributions, or water mappings, or areas of glucose uptake. The total yield is definitely more than the sum of the parts here. It doesn’t matter if they are reading a film, a digital image, or holding the patient up to the light. That is why the “old” radiologists are just as good at the new modalities.
Could you train a cardiologist to spot a lung cancer on a coronary CTA? Could you train an orthopedic surgeon to see that same lung cancer on a thoracic spine series? Probably. These folks are very smart and dedicated to what they do best. I mean to take nothing away from them. But where does this mentality stop? Why shouldn’t the surgeon look at the cytopath slides from his biopsy? Maybe he should supervise anesthesia as well? I’m sure he could be trained to do so.

Rather like pathologists, radiologists are impartial arbitrators. We have nothing to gain by coming to one conclusion or another. Once the study is ordered, we have only the goal of finding the right answer. We cannot, by definition, self-refer, which is NOT the case with clinicians. I’m not going to rehash that issue on this thread, but it may well be the one single reason NOT to turn over the reins of imaging to the clinicians.

Definitely a fascinating discussion, semilla! Thanks for starting the thread.

Thursday, March 23, 2006



Wow. Who'd have ever thunk it? From an inasupicious beginning to one of the four or five premier PACS blogs on the Internet! Of course, there are only about four or five PACS blogs on the Internet, so perhaps the competition isn't terribly fierce. Still, it's a monumental achievement as far as I'm concerned, and I thank all of you out there who have hit the reload button all those hundreds of times.

Anyway, I know visitor 10K quite well; he comes to us from mid-Florida via Road Runner, and he is one of the Mark's who define PACS for me. He knows who he is. Hey Mark, have you been sitting by the computer waiting for the opportunity? Did you think there might be a prize involved? Well, drop me an email, and you will qualify for an autographed photo, suitable for framing, target practice, or wrapping fish. Congratualations!

The Dalai PACS system is in progress...we have signed papers and promised money, and the equipment should start to arrive. The PACS adventure is just beginning!

Sunday, March 19, 2006

Impax 6.0: Glitch Report

I think Agfa may already know about this, but putting it on the blog guarantees that everyone who matters from Mortsel to Massachusetts will get to see it.

You will perhaps remember the monitor configuration screen:

Well, Windows has its own monitor configuration screen, accessed through the "Display" control panel. One of our stations was set up such that monitor 3 was between 1 and's just the way the cables ran. Windows lets you move the icon representing the monitor to wherever you want it to be, thus matching the physical configuration. Unfortunately, this totally confused Impax 6.0, which tried to place the image panes between monitor 3 and 2. That didn't work very well. After an hour of reinstalling video adapter and monitor drivers (at one point, I rendered the whole station useless and had to LogMeIn into it to get it to work), I just swapped the cables to the offending monitors, and redid the Windows Display setup. Voila! All is well. Maybe Impax 6.5 will take its cues from Windows, rather than attempting to override it. Remember, folks, the market has chosen Windows as the platform of choice; things go more smoothly if we let it do what it wants to do.

Saturday, March 11, 2006

Feature Fatigue and Lego PACS

Images courtesy of PC Magazine.

Even a blind pig occasionally finds an acorn, or even a truffle. So it is with yours truly. I was listening to NPR's "Weekend Edition" this morning (yes, conservative ol' Dalai listens to Radio Dark Side on occasion), and I caught an interview with Dr. Roland Rust from the University of Maryland. Dr. Rust holds the David Bruce Smith Chair in Marketing at the Robert H. Smith School of Business at the University of Maryland, where he is Chair of the Marketing Department and is Executive Director of the Center for Excellence in Service. Good credentials, right? Dr. Rust discussed the theory of "Feature Fatigue", and I was reminded instantly of Lego PACS. It seems I stumbled onto the same basic idea as Dr. Rust and his colleagues. The abstract of his recent paper tells the story:

As technology advances, it becomes more feasible to load products with a large number of features, each of which individually might be perceived as useful. However, too many features can make a product overwhelming for consumers and difficult to use. Three studies examine how consumers balance their desires for capability and usability when they evaluate products and how these desires shift over time. Because consumers give more weight to capability and less weight to usability before use than after use, they tend to choose overly complex products that do not maximize their satisfaction when they use them, resulting in “feature fatigue.” An analytical model based on these results provides additional insights into the feature fatigue effect. This model shows that choosing the number of features that maximizes initial choice results in the inclusion of too many features, potentially decreasing customer lifetime value. As the emphasis on future sales increases, the optimal number of features decreases. The results suggest that firms should consider having a larger number of more specialized products, each with a limited number of features, rather than loading all possible features into one product.

In the interview, Dr. Rust used the example of the latest BMW, which uses a technological innovation called "iDrive". This is sort of like a mouse for the car, and controls about 700 different functions. It looks good on paper, and in the showroom, but it seems that about 95% of those who buy the car actually use maybe 10 or 20 of those 700 options. To me, the way Lexus designs its dashboard is the antithesis to the BMW approach. It is simple and clear, there are far fewer buttons, but those that are there do what they are supposed to do superbly well. The car becomes almost transparent; it's just me and the road. But I digress. The bottom line is that people are attracted to products that have a lot of features, but usually, they end up not using most of the features that caught their eye in the first place. Hence, "feature fatigue", if not outright buyer's remorse.

I think this applies perfectly to my "Lego PACS" concept. Many systems out there are incredible technological tour de forces, or is that tours de force? I have written in my RSNA reviews about some of these. I will certainly give them great credit for innovation and the delivery of power to the end-user. However, do I really need the ability to change the wording of a 3rd-tier sub-menu? Does that help me get through my electronic stack of films any faster and easier? Personally, I think not. When I sit down at my station for a 6-hour uninterupted reading marathon, what I need (besides a bedside commode and a refrigerator) is the ability to interface with the study. I need the most streamlined, but still powerful, set of tools available to examine the image set, process it further if necessary, annotate it if necessary, and then send it away to be replaced by the next victim's, I mean patient's images. As I have put it many times before, the PACS should not get in my way.

I have yet to find an absolutely perfect system, but I still stubbornly insist that Amicas LightBeam comes close. I have the majority of what I need and very little of what I don't need. I do sit on the Amicas Advisory Committee, and I will do my best to keep them steered in that direction.

In the meantime, you'll have to excuse me. My cell-phone/PDA/MP3-Video player is ringing, and I seem to have misplaced my Bluetooth headset with caller ID, so I don't know who in the world is calling. Sometimes, I like feature fatigue....

Friday, March 10, 2006

Agfa Impax 6.0, Online!

Well, it's actually here and running. My friends from Agfa and Mitra have been very active on my blog today, with lots of hits on my older 6.0 postings. Now that I actually have it in my grubby little paws, so to speak, it's time for an update.

Our Impax 6.0 Interim Web Solution is a somewhat limited installation, as an appendage, if you will, to the Impax 5.2 system. One can query the database (but reports are not available), and "live" images must be pushed to the 6.0 server. Still, it is here and it works, and it is significantly better for home use than the venerable old Web1000.

Loading it was pretty straightforward, although on two of our machines, I ran into .NET problems. Impax 6.0 uses .NET 1.1, although Microsoft now offers version 2.0. One of the 1.1 hotfixes wouldn't install on my laptop, and I ended up reloading Windows. Likely the problem was with a virus scan or some such thing, and turning off the virus scan on the other problem machine let the hotfix load properly. Oh, well, my laptop needed housecleaning anyway. Once .NET was in place, the installer had to be restarted to load Impax 6.0, which then proceded nicely. One does need to know the address of the server during the install, a minor difficulty.

When everything is tidily loaded and rebooted, you click the icon to activate the program, and you are then greeted by this sign-on window:

I like the graphics, personally. I guess someone in Waterloo plays "The Sims" a lot, because the image sure does look like a Sims-esqe radiology department. Hey, it's cute!

To digress a little before we get into actual usage, you can customize several factors by hitting the Configuration toggle on the front page. For most, the only item that will change is the screen layout. At home I have two monitors, but most of my partners have one, and you can set up the program to do it your way on each station where you have logged in. You get to choose where the worklist goes, how many and which screens actually get the image data, etc, and it will remember the next time you sign in. Also on this configuration screen can be found just about every other control that used to live in the IMPAX Configuration (or Conflaguration as one of our PACS admins puts it) control panel. The new Configuration screen looks uncannily like the old control panel. Anyway, about the only other control a lowly end-user like me will use will the the RAM allocation. This program wakes up hungry, and will reserve just about all available RAM for itself. Fortunately, you can tone this down, and on my 4 Gb machine at home (ain't the Dell Outlet site wonderful?), using only 2 Gb seems to work OK, and allows Amicas LightBeam to operate simultaneously as well.

Once you're "in", you get this screen full of worklists. As I noted in the last post, the worklists are extremely customizable, down to the day and even the hour if you so choose. Everything I posted about the "Relevance" and the "Refresh" buttons is accurate, so I won't repeat anything.

I had noted previously that you can do Boolean-style searches, and the criteria for such a search are nearly unlimited:

There is a way to make your own worklist and even deploy it on some days but not others:

My ideal schedule would probably be no activity on any given day, but that doesn't pay the bills, does it? Anyway, opening a worklist gets you a list of patients and exams, and clicking one sends you to the actual viewer:

Ah, but wait! If you have only one screen, you toggle back and forth between the viewer and the data screen with the "Text" button. In fact, a lot of Impax 6.0 activity is based on toggling back and forth between screens in this manner. If you have more than one monitor, however, the images go off to the side, and you toggle between data and worklists, a more satisfactory experience. As I have posted earlier, the data or text screen has lots of very useful stuff like lists of priors, reports, and comment fields in which you can type your love notes to the ER. The panes can be easily resized and the program remembers what you did for next time.

I said before that the viewer is VERY similar to that within Impax 5.2 once you get past the slick reskinning, and I stand by that. There is still the necessity to use clone windows instead of dragging a sequence where you want to as many times as you want to. There is no "simple" MPR, and our web-deployed version doesn't have Voxar as yet. (I don't know if we will ever get that at home...) I have yet to dabble with hanging protocols, but the tool looks promising, at least. The button configuration scheme works just about identically to the old one:

This is too much configuration, in my humble, lazy, and somewhat Luddite-based opinion. I still prefer a more simple, streamlined approach. But that's just me.

Now, here's a little determine if you receive images compressed or uncompressed, you go to the upper right hand corner, click the triangle by your name, and check or uncheck "Show Original Images". This doesn't seem like a particularly logical place to put this, but then Saab puts the ignition switch on the center console. To each his own, just so long as I know where to look.

Forgive the necessarily brief overview, but what I am finding is that if you know Impax 4.5/5.2, you won't have much trouble with 6.0. That may be a good thing, but I do wish there had been a deeper overhaul. This product does get the Dalai stamp of usability, but mainly because I have spent a year with the older Impax's. But I do have to complement Agfa on what must have been a very difficult port over to .NET/CRL. This gave them the ability to deploy Impax 6.0 over the web, and that is a great achievement in and of itself.

I'll report more as the journey progresses.

Wednesday, March 01, 2006

9000 Visitors!

Visitor 9000 comes from Pasadena, California, via Verizon Internet. He (or she) was looking for information about using a Shuttlepro jog-dial with PACS. I've tried to do that, as you know, without much luck. For what it's worth, I got a keymap from a kind soul on the Agfa users' group. This will work for Agfa, and should work for other systems with minor modifications:


1 ---F5
2 ---F6
3 ---F7
4 ---F8
5 ---page up
6 ---page down
7 -
8 ---page up
9 ---page down
10 -
11 --Enter
12 --F9
13 --Alt + Tab
14 --home
15 --end
jog left -----page up
jog right ---page down
shuttle in

Left 7 ---page up 60 frames/sec
Left 6 ---page up 45 frames/sec
Left 5 ---page up 30 frames/sec
Left 4 ---page up 15 frames/sec
Left 3 ---page up 10 frames/sec
Left 2 ---page up 5 frames/sec
Left 1 ---page up 2 frames/sec
Centered -
Right 1 --page down 2 frames/sec
Right 2 --page down 5 frames/sec
Right 3 --page down 10 frames/sec
Right 4 --page down 15 frames/sec
Right 5 --page down 30 frames/sec
Right 6 --page down 45 frames/sec
Right 7 --page down 60 frames/sec
Shuttle in transition (all) -

The old joke about 2001: A Space Odyssey, is that "HAL" was wordplay on IBM, one letter off for each, right? Arthur C. Clarke (or was it Stanley Kubrick?) denied this, claiming that it stood for Heuristic ALgorithm. Whatever. Gary Lockwood was one of the stars of the movie, along with Keir Dullea.

It is a little known fact, at least to those who don't dabble in such trivia, that Mr. Lockwood starred in the second Star Trek pilot episode, "Where No Man Has Gone Before", along with Sally Kellerman:

Because of the Star Trek connection, Mr. Lockwood is a frequent convention guest. The photo with my son below was taken at the 2004 Star Trek Convention in Las Vegas. Photos with a straight face are more expensive, I guess, although I did buy a copy of the famous "pod photo" above signed by both Mr. Lockwood and Mr. Dullea.

This all gives me an idea for a new podcast. How about "2006: A PACS Oddity"? All of HAL's memory now fits on a 2 GB thumb-drive, and Dave kills him by pulling it out of its USB socket. I'm sorry, Dalai, I'm afraid I can't do that....