Patently Silly?

My only experience with patents was rather expensive and nonproductive. I invented a device to draw perpendicular lines on a mammogram for needle-localization purposes, which actually was quite elegant. Sadly, after a $500 patent search, I found that I was about the fifth or sixth person to come up with this design. Sigh.

A fan of this blog (thanks to PACSMan and Jennifer) sent me a link to PatentlySilly, a blog about weird patents that really demonstrates just how clueless the US Patent Office can be. Check out this patent for a water-pipe with a little extra stimulus, as a good example. This gets a patent, but my great idea couldn't. There ain't no justice!

There have been several stories lately about DR Systems suing NovaRad, Emageon, and eRad. I first heard about this from an AuntMinnie post, and there has been further elaboration from PACSMan/Ms. PACS and Spidey.

Now, I should state up front that I have met DR Systems President Dr. Murray Reicher, and I continue to correspond with him on non-PACS matters. (I've never even touched a DR product, for better or worse.) In my dealings with him, Dr. Reicher demonstrates the very highest moral and ethical fibre possible, and I don't think his company would pursue patent-infringement lawsuits if he did not feel completely justified in doing so. But I needed to educate myself in the particulars, as this is a very important situation in the PACS world.

The patent in question can be found at the US Patent Office website. The patent, "Automated system and a method for organizing, presenting, and manipulating medical images," was filed by Wesley Hilton, Dr. Reicher, and Dale Seegmiller on December 30, 1992, and approved September 19, 1995. Here is the abstract:

An automated system for organizing, presenting, and manipulating medical images includes a database in which the medical images are structured into groups, each group including one or more image series, each image series including an ordered sequence of images which illustrate incrementally registered aspects of an anatomical target. Image series are presented in their sequential order either in a monitor presentation format which displays each sequence in its entirety in a single monitor display container or which presents two or more image series, image-by-image, in adjacent presentation areas of a series display container. The system includes a plurality of monitors in which all monitors, save one, produce display containers for image series presentation. One monitor is reserved for displaying a working palette to which images of the image series displayed on the other monitors may be moved. The system activates a monitor in a plurality of monitors in response to movement of a cursor between monitors. An active monitor is indicated by presentation of a control panel. The system also provides heads-up presentation of control panel icons at a cursor location outside of the control panel by sequentially changing the shape of the cursor to the icon shapes for user selection.

Got all that? Here's a drawing from the patent that gives you a vague idea of the approach:

Feel free to read the entire patent at your leisure. The Summary continues:

SUMMARY OF THE INVENTION Therefore, it is a primary objective of this invention to provide an automated system for storage, retrieval, and presentation of medical images which is especially adapted for the presentation of medical image sequences and which affords the user with a flexible and responsive set of functions that permit direct manipulation of the modes of image presentation and of the presented images themselves. The invention is embodied in a computer display system which presents images of anatomical structure and the like for examination. The system includes the following combination: a first display container including a first preselected number of substantially rectangular presentation areas in a substantially rectangular array; a second display container including a second preselected number of substantially rectangular presentation areas in a substantially rectangular array; an image database including a plurality of images of anatomical structure, the images being separated into image groups in which: each image group is indexed by a unique group identification; and each image group is partitioned into one or more ordered image series, each ordered image series including a succession of images which illustrate incrementally registered aspects of an anatomical target, each image series being ordered by assignment to each image in the image series of a position in a respective monotonically changing sequence; a mechanism connected to the image database and to the first and second display container and responsive to a group identification for displaying at least two image series of an image group indexed by the patient identification, wherein: each image series is displayed in the order of its respective sequence in a respective display container such that each presentation area of the respective display container includes no more than one image; or, all of the image series are displayed in one display container and each image series is displayed one image at a time in the order of its respective sequence in a respective presentation area of the display container.

This legalese word salad (there is much more) seems to be discussing what we now call hanging protocols, a preset display configuration for various imaging procedures.

The current lawsuit against Emageon, eRad, and NovaRad was filed in California, and some details can be found here. I actually paid a few dollars to download the complaint itself, which is a public document. Of the fifty-five pages (they only charge $0.08 per page, with maximum charge of thirty pages or $2.40 per document!), the majority simply reproduce the patent in question, 5,452,416, a.k.a, the '416 patent, and this is followed by a series of definitions of the various terms in the patent which come from a prior case against Fuji. The real complaint is succinctly worded, and repeated for the three defendents:

Emageon/eRAD/NovaRad has infringed at least claims 1 and 6 of the '416 patent through, among other activities, the manufacture, use, importation, sale and/or offer for sale of automated medical imaging and archival systems. Emageon/eRAD/NovaRad has also infringed at least claims 1 and 6 of the '416 patent by knowingly and actively inducing others to infringe, and by contributing to the infringement by others.

Hmmmm... Sounds like contributing to the delinquency of a minor. So, we need to look at Claim 1 and Claim 6 of the patent. Here they are:

and

Well, I'm not a patent attorney, but my semi-educated read of these claims suggests that DR has a point. Pretty much any and all PACS displays could be lumped under this description with enough of a fudge-factor. There does seem to be some specificity for what we would now call a hanging protocol, although a quick read makes it sound like the patent just covers a run-of-the-mill display. That's trouble for everyone else, and good news for DR Systems.

I suppose the moot point her is whether or not DR really invented all this, or at least perfected it. The patent was filed in 1992, and granted in 1995. Was there PACS in 1995? Of course. Were there hanging protocols? Not on the systems I used at that time. Were they in development at other shops? I don't know about that. Moreover, should this sort of thing have been patented? Today, it seems self-evident that you should look at PACS more or less as everyone does it, although I certainly have my own personal preferences in that regard. Is the image layout on the screen patentable? Or copyrightable, for that matter? I've jokingly said that I need to patent both breathing and the sun coming up in the morning; think of the fees I could charge! How much credit does the Patent Office receive for deciding that something should receive a patent? What is a patent anyway? From the Patent Office itself comes the official definition:

. . .a property right granted by the Government of the United States of America to an inventor “to exclude others from making, using, offering for sale, or selling the invention throughout the United States or importing the invention into the United States” for a limited time in exchange for public disclosure of the invention when the patent is granted.

(An invention is) any art or process (way of doing or making things), machine, manufacture, design, or composition of matter, or any new and useful improvement thereof, or any variety of plant, which is or may be patentable under the patent laws of the United States.

You can see that the parameters are pretty nebulous, and an invention is patentable if the USPTO says it is. I guess "breathing" and "sun coming up in the morning" probably won't fly, however. But from Thompson Reuters Scientific comes this list, which is a little more intuitive:

In general a patent will be granted for an invention so long as it:

• is new or "novel": the invention must never have been made in public in any way, anywhere, before the date on which the application for a patent is filed.
• involves an inventive or "unobvious" step: this step must not be obvious to others with good knowledge and experience of the subject of the invention.
• is capable of industrial/useful application: an invention must be capable of being made or used in some kind of industry.

It's the "new" and "unobvious" questions that I cannot answer with respect to the DR programs. The way patent applications are written, chock full of legalese and mumbo jumbo, nothing is obvious. Is the layout of images on a screen obvious, new, and unique? Is the concept of hanging protocols obvious? Was it new and unique in 1992? I'll have to leave that to folks older and wiser than I. I could barely spell PACS back then. But, we do have the reality of the patent granted to DR at that time.

DR has sued other PACS vendors, and several small companies have settled. Supposedly, some larger companies are considering fighting DR Systems, which to my non-legal mind would require invalidation of the DR '416 patent. I'm not sure that would be easy, and I know it would be incredibly expensive. The lawyers always win, don't they?

Ironically, DR Systems has itself been sued by GE for patent infringement. A suit filed by GE in the US District Court of the Eastern District of New York on 10/16/2006 notes:

DR Systems has been and now is directly infringing and indirectly infringing, by way of inducement and contribution, the '674 Patent in this district and elsewher in the US by making, using, selling, and offering for sale image and information management systems for hospitals and medical imaging centers that practice one or more claims of the '674 Patent. The infringing systems include the Catapult Technologist QC Workstation, Advanced Windows Catapult, The Dominator, Web Dominator, The Instant Reporter, Web Ambassador, CD Ambassador, The Communicator, and/or Guardian Archive.

DR Systems' actions have damaged GE in an amount to be determined at trial and have caused and will continue to cause GE irreparable injury for which GE has no adequate remedy at law.

Sounds kind of familiar, doesn't it? Here we go again...

GE's Patent 6,633,674 was filed November 25, 1999, and issued October 14, 2003. Here is Claim 1:

1. A picture archiving and communication system comprising:
an input device configured to receive uncompressed medical image data files including a descriptive header and image data, and to convert each of the uncompressed image data files to a hybrid compressed data file including uncompressed descriptive header data, compression header, and compressed image data;
a data file server coupled to the input device for storing the hybrid compressed image data files;
a client system coupled to the server, the client system being configured to receive the hybrid compressed data files and to uncompress the image data for output; and
a database accessible by the file server for referencing the hybrid compressed data files.

The rest of the claims have more to do with compression. Here again, a semi-educated read makes it sound like GE has patented PACS, doesn't it? I didn't go through all the court documents (even at $0.08 per page, the cost adds up, you know!) but the suit was eventually dropped "with prejudice."

I think the bottom line here is that the Patent Office granted a lot of patents for PACS and related technologies, almost certainly without completely understanding all the vagarities and implications of what they were approving. I'm sure I don't grasp it all, and I really doubt that anyone does. DR's suits based on Patent '416 seem to me to have some validity, based on the existence of the patent itself. As I noted above, the lawyers win no matter what.

Addendum: Aunt Minnie's Brian Casey has written about this topic as well, and has gone more in depth about the claims of the initial patent.

Hollywood House Recycling?

Being a good husband sometimes means seeing movies you might have otherwise avoided. Today, I took my wife to see the consumate chick-flick weeper, "Nights in Rodanthe." I won't give away the plot, but suffice it to say, it lives up (or down) to its reputation.

The action takes place mostly in Rodanthe, which is on Hatteras Island in the Outer Banks of North Carolina. When the main scene of the inn on the beach appeared, I nudged my wife and said, "That sure looks like the Weasley's house in the Harry Potter movies!" She gave me the "shut up and watch the movie, you unfeeling lump" look in response.

Anyway, I found a photo of the Weasley's house, which was called "The Burrow" in the Harry Potter movies, as well as a shot of the house used for "Nights in Rodanthe". One in the same? Well, the ocean is apparently encroaching further and further upon the Rodanthe house, and maybe it too is only held up by magic these days.

Buttons, Buttons, and More Buttons

Shuttle controls, image courtesy of http://www.nasa.gov

I've done you the favour of reproducing the "Customization" window from one of our larger PACS installations. You may have to click on the image to see the details. Depicted below is the window that allows us to change the tools on the toolbar and on the "context", or the right-click menu.

This particular screen capture shows how we change the settings for the "CRDX" modality. A drop-down gives you access to changing the other modalities. Our list has 29 modalities, although we probably actually access about 10 of these. Now, given that there are 89 tools, which can either be present or absent, each modality can have 2^89, or 6.1897002 × 10^26 available tool arrangements, so with 29 modalities, we therefore have 9.08696418 × 10^776 possibilities. OK, we don't use all the modalities, as I admitted, and if you look closely at the tools, many relate to digital mammography, and some are different facets of tools that are usually combined, such as "Flip Horizontal", "Flip Vertical", and the "Rotate" clusters. Moreover, I won't ever use a significant number of these functions. But that still leaves us with millions and millions of possible configurations.

To add to the joy of this particular product's setup, each modality has its own "Screen Layout" control, with all these options:

The little bar of 5 screens can be preset, but this is all you can access from within the viewer itself. Most other products give full control from a much simpler button or pair of buttons on the viewer:

To add further to our joy, there is a complete palette for digital mammo controls:

Buttons, buttons, buttons.

I've bemoaned this sort of thing for years, as my regular readers know quite well. Give me a streamlined package that lets me do my job without this level of distraction. So how did we get to this mess, and how do we get out of it? I discussed this with my friend and guru, PACS Ferret, whom I stole from the big U down the road, and he set me straight on a few things. There are stark differences in the way things are done in academia and in private practice. I view myself as more or less typical of a private practice PACS user. I need to power through my studies with the greatest accuracy and the least distraction possible. In the academic world, a place I haven't visited for quite a while, much time is taken for teaching, and research. The cases are often pre-read by residents. Some of those obscure tools might have a place.

This explains to some degree where all the tools came from. Some site calls up the vendor and said, "we need a left-handed spanner," and Shazam, there it is on the desktop. This might work well here and there, but if the solution to creating a GUI is to give the suckers what they want, everything any one of them might want, you end up with the astronomical number of control permutations (or is that combinations?) calculated above. There has to be a better way.

The solution to this mess is multi-factoral. First, send me $700 Billion, and then I'll.... Oh, wait, wrong mess. No, first, there needs to be a cleanup of sorts, with consolidation of multiple duplicate or near-duplicate functions, and more intelligent design overall. But beyond this, there may well need to be a whole new approach. PACS Ferret suggests a modular approach. There could be plug-ins or entire modules devoted to certain audiences. Perhaps the mammography module would include all the important tools for this modality. The academic version could include every tool known, including a picture-in-picture window to monitor the residents and see if they are goofing off. The private practice version would be streamlined, of course, but could have modules for high-level visualization as required, be they for cardiac imaging, virtual colongraphy, or whatever. I'm suggesting that these components blend in seamlessly with the PACS GUI, rather than spawn as add-on programs as we often see today.

With the modular approach, one PACS could be made to fit all, much more easily than what we see today. Of course, this doesn't address the functionality of the GUI itself, which is a related but different story.

You can never be too rich or too thin (that one has been disproven, by the way), but you certainly can have too many buttons. There are ways to keep this under control, which some vendors understand and some don't. However, I have to realize that there are those rads out there who probably want some of the things I consider superfluous, so we need to find a way to accommodate them. Throwing in everything but the kitchen sink on every version just won't cut it, but maybe, just maybe, the modular approach could keep your sink out of my playground.

Addendum:

One of my friends from the large PACS company above told me about the "CNTL-Right Click" text menu of tools:

Having used the program for several years now, I had no idea this existed. Maybe I need to do a CNTL-SHIFT-Right-Click and see if that brings out some Easter Egg or maybe wipes the disk.

This "new" approach is slightly helpful to access a tool that I might use once a year. I will have already organized my Right-Click tools to include those I use the majority of the time.

Another Addendum

A representative from a big PACS company had this to say about my post:

There is no doubt that many PACS vendors continue to carry the sins of the past (90's) in which tools were added at a single request, but with maturity of products and the market expectation, I believe that we see far more constraint these days when considering tools. For instance, does the tool meet the needs of more then one user, how can that outcome be achieved within the context of an existing tool etc. . I could discuss with you the analysis done to actually determine tool usage across (hundreds of) installations and you would feel justified in your opinion, given the 10-90 rule (10 % of tools are used 90% of the time) However, from my perspective, the blog was a bit misleading because it failed to set any type of control in the example picture, that complex library of tools shown can be controlled via proviledges, that once set, reduce the 'plethora of tools" the user sees, That window was that the "ALL tools" window for general management versus the tabbed libraries which focus on specific toolsets. The control RMB was put in place to allow users to set minimal icon based menus but still have acess to other tools that are needed on occaision. This will in theory also reduce the need to edit the menu as often? My point...

Respectfully, I agree with your overall assessment, but feel that it doesnt necessarily reflect newer/emerging products that have learnt from the sins of the past. We PACS vendors are trying to get smarter by listening instead of thinking.

And indeed I'm finding this to be the case. The change is slow, but sure.

London's PACS Is Falling Down

It seems that London (Ontario, not that other London) has a little problem. According to the London Free Press,

London and area doctors are being asked to carefully select which patients need X-rays after the $50-million digital system serving eight hospitals was partially crippled during a weekend computer upgrade.
London's hospitals have brought in more staff and reverted to using X-ray film, a technology they left behind five years ago when they switched to the new system.

London's two hospitals share the system with hospitals in Ingersoll, Strathroy, Newbury, St.Thomas, Tillsonburg, Woodstock, Stratford, Goderich, Exeter, St. Marys, Seaforth and Clinton.

Oops. Just in case you were interested, Hewlett Packard supplied the hardware, and.....

HP teamed on the project with GE Healthcare, a major provider of transformational medical technologies, and Cerner Corp., a leading supplier of healthcare information technology. GE Healthcare is providing the picture archiving and communication system (PACS) and Cerner is providing its Cerner Millennium® platform for electronic patient records and radiology.

Sorry. Hope it gets fixed quickly. Many thanks to Miss Pat for the tip.

PACS State-Of-The-Art, Circa 1985

PACS has existed in some form or another for quite a while. Today, we are rather jaded with the multitude of options out there. Do we go with Windows or Linux or Unix for the back end? Do we use 2 MP flat-panel monitors, or 3 MP or even 5 MP's? Gigabit Ethernet to the desktop is a given in most places, so in-house transmission times are almost negligible. And so it goes.

There was a time, however, when this was almost science fiction, and the assemblage of disparate components into what we call a PACS was the goal of a handful of visionaries around the world.

Long before my trip to UCSF to visit Bernie Huang in 1992, as described in a previous post, there were a number of centers developing functioning digital departments. I recently stumbled across an article from the University of Kansas by Arch Templeton, M.D., Samuel Dwyer, Ph.D, et. al., documenting such an effort.

Looking back, the problems of film seem almost funny today:

In most radiology departments, digitally formatted radiographic information is recorded, used, and stored as analog images on multiformat film, manually assembled in individual patient jackets and retained in a central film file. . . Sequential (one at a time) access to film jackets results in limiting the diagnostic information to one user or display site at a time.

And the solution?

The solution is a peripheralized (not centralized) computer based system that can capture, display and archive all digitally formatted image and alphanumeric data generated during a patient's hospital stay. The system must have on-line access, fast communication links, and high utilization capabilities. It must be bidirectionally integrated to an appropriate long term archiving system.

Here is what they envisioned, and ultimately built:

The interesting historical note here is that the system was indeed built as a series of nodes, with relatively independent architecture. Contrast that to today's PACS with a central web-style arrangement. For long-term storage, there were various options, including magnetic tape, or magnetic disks. The old Winchester-type sealed disks were available in 450 MB capacity for about $15,000 per drive, or one could splurge on a 1GB drive for $130,000! Other options included optical disks ($8,000 for the drive, $150 for the 4GB disk). There was such a thing as linear optical tape (drive cost: $80,000-$100,000, 50GB tape reel cost: $2500). The article even discusses laser-sensitive x-ray film which could store 1MB/cm2, or 238 MB on a 14 x 17 sheet!

We've definately come a long way, baby.

Radiology Sales

Sometimes good ideas come in pairs, or even in threes. I've introduced you to PACS-aholic, the new blog from the PACSman and Ms. PACS, designed to give us an inside look at the PACS industry. In today's entry, Mike and Cristen give the PACS sales institution a well-deserved kick in the pants, with some well-justified finger-pointing. This should be required reading for anyone who has even the slightest connection with purchasing a PACS.

I've discovered a new blog that could possibly blow the lid off of radiology sales practices. "Spidey" apparently knows something about this, and his (her?) blog, SPIDEYKNOWS_SALES (http://spideyknows.blogspot.com/), promises to deliver "tales from the streets and rooftops about winning and losing in selling to the Radiology marketplace." "Spidey" is a salesperson, who has been successful at the game, and still likes what he does. Why? "Because I like to win. I like to solve problems and I like to see people have the tools to enable them to do their job better." My kind of sales person; I haven't met too many like him.

"Spidey's" first post is, to put it bluntly, a hatchet-job on the gang-approach to sales, slashing the common practice of bringing everyone from a low-level VP to a low level janitor along for the VISIT to the CLIENT. But Spidey also places some blame on the customer where it is due:

Yet, some clients even demand it...they feel insulted if a "herd" doesn't arrive, because don't numbers indicate how important one is? I wonder how far prices could be reduced and profits increased if vendors and potential clients would focus on learning about solving a problem from the best person capable of solving it? Cut the number of mouths on the Commission food chain and compensate the person or person(s) who go out in the morning and bring supper on the table at night.

And this is what I've been saying in some form for a while. I've been wined and dined over the years, I've been visited by the "herd" and I've been taken on some great junkets. Ten years ago, Elscint took me and a partner to Israel and Germany to look at some new developments in MRI. We flew Business Class, stayed in the finest hotels, and had ample time for touring, at Elscint expense. The irony here is that Elscint's MRI division was purchased the week before we went on this little trip by. . . GE. So, I had a really good time at you-know-who's expense. The bigger irony is that Elscint (and subsequently GE) never even produced more than one or two prototypes of the machines we demoed. Tens of thousands of sales dollars shot to hell. And in many ways, this trip was a little more justified than most, as this was the only way to see what these one-of-a-kind machines could do. But a web-based PACS can be demoed anywhere, anytime, without the entire entourage of suits and accouterments. There needs to be a new paradigm in this industry, with more conscientious investment of time and money directed where it should go, and not toward some administrator, IT-type, or physician's ego. Just show me the machine. Since no one has listened to me on this topic, maybe Mike, Cristen, or Spidey will have better luck.

Questions From ANOTHER Interaction Designer

Another anonymous PACS designer chimes in:

I'm an interaction designer/programmer as well. And I find Cooper & Reimann's book Interaction Design 2.0 to be useful in educating programmers about generic user expectations and behavior. It also introduces some important concepts which we use in our design guidance documents.

As much as I agree about the importance of good interaction design, market forces are such that what people pay for (from among what is offered) is what the market will provide more of. So I have some questions related to that.

1) When purchasing a PACS, how do radiologists evaluate the software interaction? To what extent are they willing to try out unfamiliar(but possibly better) interaction models, and how much time are they willing to give to that process?

2) Does anyone evaluate the ease of use of anything besides the radiologist's workstation? If so, what?

3) How much is usability weighted in the purchase decision? And how much of a premium (in purchase price) is a superior design worth?

Very good questions, all. Here, we really get to the crux of the matter, whether a more usable product is a sales advantage, and worth more than Brand X.


Now, I can answer all of these according to my own, biased, radiologist-centric viewpoint, which might not be accurate for all involved. Based on my experience and research and observation, it is probably rare for the radiologists to actually decide which PACS to buy. As often as not, the choice lies in the hands of bean-counters, and/or the IT folks, who may or may not pay attention to the needs, wants, desires, and whines of the radiologists.


So, how do radiologists evaluate the software interaction from a 10-minute demo? Very poorly. It is impossible to see how a complex piece of software will behave in your hands in that short a time. In most cases, the sales or apps person is "driving" anyway, and we poor rads get no hands-on time at all. From this brief exposure, we are supposed to make a million-dollar decision. I have long advocated prolonged web-based demos, and I still think they represent the best approach.


When I'm looking at new software, I try to use it as if I were actually in a production environment. This isn't easy, especially in a 10-minute demo, but it can and should be done. Now, trying new processes is a problem. I, for one, am willing to do so, but some are not. If the keys to the "new process" are not immediately obvious, if it is not intuitive, it will be bypassed.


Let me go off on a tangent for a moment. I received a disk from St. Elsewhere over the weekend with a client program from a smaller PACS company. The damn thing loaded VERY slowly, and the GUI was esoteric. I was actually in the middle of writing a hatchet-piece about the program in between call cases. However, the more I worked with the viewer in the process of digging up dirt on it, the more I found it useful, or put another way, the less I hated it. Thus, unfamiliarity in this business breeds contempt. Now, this particular program will never reach the level of Dalai-usability, but it wasn't quite as bad as I first thought. There is a balance, a threshold of what works well for all immediately, and what will eventually work better than you think it will initially.


How much time will we give to checking out something new? Probably not enough. Again, we need to see quickly that your new process is better than the old way.

Hopefully, PACS admins and IT types are allowed to look at the back-end of the system as well as the front. The best GUI in the world is useless if its underpinnings don't work well. The support folks need to be checking out the administrative tools, ease of fixing studies, and ten dozen other things that I couldn't even begin to name. Yes, I do indeed acknowledge their importance!

The part usability plays in the purchase goes right back to who is really in charge. If the rads ignore the job of selection, and just depend on the proverbial "someone else" to do the picking, then it probably doesn't matter at all. The same is true if the rads are excluded from the decision altogether. (It happens, trust me.)

And it needs to be stated that usability is in the eyes (and mouse) of the beholder. One of my senior partners proclaimed for the first time yesterday that he vastly prefers Agfa Impax 6 to Amicas LightBeam. Why? Because with Impax, you can access the ruler tool via the right-click menu, and with LightBeam, you have to scoot the mouse up to the tool-bar. The other features (no matter how well or poorly done) don't matter to him one bit, at least they didn't yesterday. Now, my other 27 partners think just the opposite, but you see the dilemma. Whom should the designers target? Why me, of course!

How much is a good design worth? That's somewhat of a trick question. In the PACS business, there is a significant disconnect between price and design. I don't have to go there again, do I? Designing a program that actually works properly in the hands of real users might well cost more that just letting the engineers/designers/programmers run loose. There should be numerous iterations of redesign and retesting with real live radiologists, especially those who do not already use the company's product. That's a hard process to quantify and deciding what it's really worth is even harder.

I've been preaching about GUI design for years and years. It's nice to see the concept finally get some attention, and I really appreciate hearing from the guys on the front lines in this effort. Will their hard work pay off? It should! The better, more usable PACS should sell better than the clunker, but that may not work so well in the real world, where IT may decide to purchase from the company that "no one ever gets fired for chosing," whichever that might be this week. But keep up the good work guys; sooner or later someone WILL be fired for picking an unusable system. Someday. I promise.

Further Down The Green Brick Road

As a Centricity user, I have wondered how the "Centricitgrad" integration is progressing. As I still have friends at GE (well, they used to work for DI, but...), I was able to get the official inside scoop:

It has been 11 months since GE Healthcare acquired Dynamic Imaging, and operationalized their business within GE as “Dynamic Imaging Solutions”. Since the announcement, both Centricity PACS, and Centricity PACS-IW (formerly Dynamic Imaging’s IntegradWeb PACS) have both enjoyed success in the marketplace – gaining healthy shares in the various market segments.

While Dynamic Imaging Solutions continues to operate as a separate business unit within GE Healthcare IT’s Imaging Solutions division, the fruits of the consolidated, global engineering efforts are already showing significant progress.

GE is leveraging and integrating a number of technologies (i.e., PACS-IW Web client technology, RealTimeImaging’s advanced streaming technology, previously acquired by IDX/GE), to provide a powerful, Web accessible, diagnostic capable viewer that communicates directly with the robust Centricity PACS infrastructure. At GE’s user group conference, the GE Healthcare User Summit in Washington , D.C last month, 13 customers experienced a preview of our work-in-progress (WIP) and provided invaluable feedback to our product mangers and engineers. The response was very positive, as the new capabilities and diagnostic workflow will benefit radiologists as well as many major clinical areas.

The formal product reveal, currently a WIP, will require FDA 510K clearance prior to release due to the interpretive capabilities of the viewer. GE is excited about our great progress and customer feedback thus far. Our next steps are the clinical pilots, with culmination of our 2008 activities at RSNA in Chicago .

I always thought IntegradWeb had good streaming capabilities, but perhaps they have been improved. I guess we'll see more come RSNA.

OK, Now Agfa Isn't For Sale

I've been reporting on and off for a while that Agfa was trying to sell off its healthcare division. Today, Agfa said, "Not so fast..."

From Reuters:

BRUSSELS, Sept 9 (Reuters) - Belgian imaging technology group Agfa-Gevaert (AGFB.BR: Quote, Profile, Research, Stock Buzz) said on Tuesday it planned to keep its healthcare unit together and that its board had not launched a process to sell the operation.

The company referred to a number of media articles in recent weeks stating that Agfa was set to start a formal sales process of healthcare.

"In its regular meeting of today, September 9, 2008, the board of directors has taken note of the confusion created by this misleading information and therefore has decided to set the record straight," Agfa said in a statement.

Belgian daily De Standaard for example reported last Friday that Agfa was taking steps to sell the unit by the end of this year, driving Agfa shares up by some 5 percent.

"The board confirms that no decision has been taken to launch a process for the sale of the healthcare business group," Agfa said, adding its priority was to improve operational efficiency.

"The board confirms its commitment to the preservation of the unity of the healthcare business group, to its strategy and to the investments made for extending its leading position in healthcare IT," it continued.

Agfa, which specialises in imaging systems, IT and top-end printers for publishers and newspapers, had planned last year to split into three separately listed companies -- Agfa Graphics, Agfa Health Care and Agfa Materials.

It scrapped the plan after disappointing first-quarter results, saying the move was no longer viable. . .

Analysts believe healthcare is the unit Agfa would most likely spin off or sell, although the company first needs to address problems there.

I stand ready to help address those problems if called upon to do so.

A Note From An Interaction Designer

On occasion, someone actually believes me to be wise in matters pertaining to PACS. It's amazing how far you can get on self-promotion.

Anyway, I've been working with several companies on their PACS designs, taking great care to avoid any cross-talk. Today, I received the email below from one company:

A request for your thoughts. . . You're unique in that you have notoriety in the medical imaging world, and actually have advocated for the need for interaction design. . . .

I am the interaction designer who works on user research and interaction design; as well as working with programmers to actually try to get the designs built. My goal is to make physicians happy and fully engaged in their software, or at least get rid of some of the "grr" :)

The questions I have for you:

1) How much of what you (or the average "Joe" rad persona) cares about in a PACS system is in the interaction design (behavior/workflow) and visual design?

2) Do you think other vendors have picked up on having dedicated interaction designers? I wonder what our best competitors are doing. If they don't call it interaction design, do they have people continually focusing on users and the user interface, planing the workflow of a user through the interface toward his goals rather than on how to architect-build-code-program the user interface?

3) How effective are seeing designs in giving you a sense of the final user experience (and workflow)? The intention of the this early review is always deeper understanding to fix on an initial plan of what to build (a design); that design is then built in software and can be tested out by rads hands-on. Having users try out an iPod is the best way to make alterations to the iPod experience, but you need to design an iPod in the first place, and not a Zune or worse a Sandisk player (I hate the Sandisk, the buttons change meaning on each level of navigation argh! Impossible to use, a pure waste of $45).

Wow. I have notoriety! Is that sort of like credibility? Oh well....

If you have a look at my old post, The Inmates Are Running The Asylum, you will see more or less where I'm coming from. Alan Cooper, of Cooper Designs, promotes the concept of software tailored for the user, and not simply cobbled together by the coders/programmers, the "inmates of the asylum".

Cooper designs interactive products that deliver power and pleasure to the people who use them. Our design methodology is founded on the observation that people will gladly use and recommend products that are designed to advance their goals, while they dislike products that merely satisfy feature checklists or are informed solely by abstract notions of simplicity.

Cooper’s Goal-Directed design methodology places the goals of the user at the center of the design process. Rather than focusing exclusively on underlying technologies or the tasks that users must perform to use their current products, our process identifies what it is that users want to accomplish in the first place and results in designs that satisfy those goals.

Thoroughly understanding the environments in which people use products, and determining the goals they expect to accomplish, yields designs that deliver a satisfying customer experience. Goal-Directed design delivers power to users without intimidating them and guards against the development of products that lack features and affordances essential to the satisfaction of users. Conversely, Goal-Directed design also prevents the addition of features that, however clever, are rarely used or irrelevant to core goals of the product users

There is a major PACS product that was revamped with the help of Cooper Design. Sadly, no one appears to have actually listened to Cooper's advice that must have cost them hundreds of thousands, if not millions to obtain. The result of the interaction was a "prettier" product which was far more esoteric and harder to use than its predecessor.

But let me answer the questions. First, how much of what I care about in a PACS is in the interaction, etc.? Are you kidding me? Is this a trick question? You could say that the images are the most important thing, and of course, that is the purpose of the PACS, to show me those images. Every single PACS out there, from the very worst to the very best, from free open-source software to the most expensive gold-plated diamond-encrusted magnum opus extravaganza will do that. The ONLY differentiating feature IS the interaction design! I guess this is one of those universal truths that is so very fundamental that it is not as obvious as it should be.

What makes one PACS easy to use and another difficult? It is the consideration of the user's needs, the interaction design as Cooper calls it, and perhaps to a bit lesser degree the visual design, the skin if you will. The designer (in general, this should NOT be the same guy that writes the code, although I know a few folks in the business that excel at both) needs to see how the radiologist will use the program, and make that interaction smooth and easy. I have said in numerous posts that the PACS shouldn't get in my way, and that is perhaps the simplest explanation of how to design it. This doesn't just happen; the program has to be written such that the images are easily available, and amenable to whatever manipulation is needed for their interpretation. Like a fine automobile connects you to the road, PACS connects you to the images. When driving, your focus should be on the road, and the car should allow you to make that connection without demanding so much of your attention that you become dangerous. When reading imaging studies, PACS should let you focus on the patient, without superflous controls or buttons, or sliders, or tabs, or whatever. Distracting me from the images can be rather dangerous to the patient, and profitable for the litigators.

In essence, PACS IS the workflow, it IS the interaction. I care about this. A lot.

Have other vendors figured this out? Yes, to varying extents. No one seems to call it interaction design, but then Cooper's influence may not be all that wide-spread. But those systems that have won my admiration definately zero-in on my interface goals. Do they have people that focus on users and interfaces? Yes, they do. Some of them do the coding, some don't, but all of them understand that the damn thing is being written to facilitate radiologists interpreting images. Such a simple concept.

The design reviews referred to above certainly do help. Like my friend's example of the iPod vs. the Sandisk player, having a functioning framework for testing is certainly one of the best ways to see what works and what doesn't. I can't really think of a better way to do this. You have to see how your model performs in the hands of the users doing with it what they do every day. A focus-group or questionnaire won't get you very far in the real world.

It's sort of ironic that my friend hates his Sandisk because the buttons change meaning on each level of navigation. Kind of like screens toggling in a state-dependent manner isn't it? Arrrggghhh is right!

I don't have a handle on what the rest of the radiologists in the world think about the various interface issues, but I know what works for me. I have said a number of times that Amicas has come close to figuring this out, and they have done so by listening to their users, perhaps more than many other companies. Creating a great PACS is simple if you follow this simple recipe. Lots of happiness, little "grrrrrr".

How much of what I care about in a PACS system is in the interaction design (behavior/workflow) and visual design? A heck of a lot. But then I've been saying that for a long time, in my quest for notoriety.

McCain - Palin!!

Whoops....wrong Palin!

Blog Competition!

I've been talking with Mike Cannavo for years about blogging. He kept threating to start his own blog, while I kept urging him to ghost-write for me, or at least contribute outright to my illustrious blog. Well, he has finally gone off the deep end with his very own site, so allow me to introduce you to PACS-aholic, "An intoxicating look at the PACS industry".

Mike is not going it alone, unlike your intrepid Dalai. No, he will be working with "Ms. PACS":

Now for the true identity of Ms. PACS - underneath the smoke and mirrors, Ms. PACS is Cristen C. Bolan, the Editor of Imaging Technology News (ITN) magazine. ITN is read by Radiologists and Radiation Oncologists who want the latest news on technology for the hospital and outpatient space.

Mike, of course, is no slouch himself (posture non-withstanding):

You may already be familiar with the notorious PACS guru - the PACSman. Michael J. Cannavo earned his reputation as the PACSman for his more than 22 years of experience advising healthcare facilities and providers on the essentials of PACS in the healthcare enterprise.

Mike may be best known for his series of "Exploring PACS Secrets" on AuntMinnie.com, and PACS-aholic promises to extend the expose' into new and uncharted territory. The blog takes the point-counterpoint format as seen in the Weekend Update segments of Saturday Night Live, wherein Dan Aykroyd would respond to Jane Curtin by calling her an ignorant . . . well, you know. Fortuately, Mike and Cristen are much more civil.

Being sort of a PACS-aholic myself, I'm looking forward to some great information and entertainment. Good luck, and welcome to the blogosphere, kids!

Desperately Seeking Updates

I hope everyone has had a happy and enjoyable Labor Day weekend. Sadly, it's now time to think about going back to the regular grind, you know, work. There is indeed a reason why work is a four-letter word.

I really don't mind going back after a long weekend, although when I've been off for one week, or more rarely two, it's a bit harder. And part of the joy is my realization that depending upon the site to which I'm assigned on that black Monday, I will have to wrestle with one balky PACS or another to accomplish my tasks for the day.

As I'm not interested in generating trouble for anyone in the form of letters from acronymical government agencies, I will avoid the pleasure of naming names and repetitively repeating lists of problems. But it seems some of the problems we are having with one of our systems are fixed by an update that came out a long time ago. However, on many PACS, adding updates can be a real pain that has the potential to shut down the enterprise. Thus, in the interest of avoiding yet another trip to the servers, we decided to wait for the update that was supposed to be available this January. Ah, but alas, here it is September 1st, and this wonderful update that fixed even more stuff is nowhere to be seen. And why is this? Well, the only word that has filtered down to my peon level is that the company has been adding more features to this update to satisfy various customers.

How should we feel about this turn of events? In my bowel-unrest over this situation, I have to conclude that the update process for many if not most companies is broken. Waiting this period of time for critical fixes is unacceptable, but there doesn't seem to be a way to get anything but an absolutely critical, emergency, life-saving patch out the door in any reasonable amount of time. This might have something to do with the way the code is written or managed. Perhaps there is a more modular approach that would allow the repair of one section without tearing apart another? That's beyond my expertise, but maybe I'm somewhere near the right track?

And, there needs to be a much better method of deployment. Updates should not be major events that are life-threatening to the PACS staff (who are in danger from the radiologists if they can't get the system back up in 5 minutes). Why is it that even horrible bloatware like Windows can automatically update in the background, but PACS server software can't? I know that some companies use a three server configuration, including the main production server, a test server, and a fail-over server. While it is still a pain to update with this system, the whole thing doesn't crumble during the process, we don't have to point to different servers during the update, etc. There has got to be a better way.

Finally, in our particular situation, the blame for the rather long delay in the update is laid at the feet of the customers (might be us, but I don't think it is) who are demanding new and different functionality. I'm assuming these requests are coming from existing customers; if the additions are for potential customers, well, let's just say Hell hath no fury like a Dalai scorned, and someone better be ready to take one for the team.

Lemme give every company out there a big hint: FIX what's wrong with what's out there BEFORE you start adding NEW thing that will break. I don't think that's a radical concept.

So, I'm begging PACS vendors to consider this request: Put some work into your update process. And your updates. And the rest of your software, as needed. It would be most appreciated.

I'll be sure to, ummmm, update everyone when I see some progress. Enjoy the rest of Labor Day!

Saved By Cancer

There is an old Arab saying that goes something like this: "The enemy of my enemy is my friend." Here is a medical illustration of that sentiment.

Below are three slices from an abdominal CT of a patient with known lymphoma. The most recent examination showed much less disease, and a completely normal aorta. Today, however, the periaortic adenopathy has increased markedly. But....look at the aorta!





At this point, I'm not certain if there is a small dissection, a small leak forming a pseudoaneurysm, an ulceration, or even an infectious process involving the aorta. What I do know is that the huge node mass appears to be tamponading, or sealing, the abnormality in the aorta, and quite ironically is keeping the patient from bleeding out.

The patient was to go for surgical consult; I would expect he will undergo endografting rather than any sort of open procedure.

Wonders never cease in this business.

GE PACS Target of FDA Warning Letter

Fair is fair. I reported on the warning letter Siemens received about its PET/CT manufacturing process. Our local GE salesperson did, after all, send out a press release publicising the embarrassing news, and it had already been published on about 100 websites by the time I got around to posting it.

While no other PACS companies have called me to make me aware of the situation, it would appear to be GE's turn on the FDA's carpet, and to be fair and balanced, this gets equal time. I first learned of this courtesy of AuntMinnie.com, with additional coverage on HealthImaging.com. The original text of the FDA's letter can be found here.

So what's the problem? Actually, there are quite a few.

The letter was sent to Mr. Vishal K. Wanchoo, President and CEO of GE Healthcare Integrated IT Solutions in Barrington, Illinois. I believe this is the site of GE's Intergalactic IT and PACS headquarters, which I visited years ago. The main product produced here is software, specifically Centricity PACS and related items. The IT shop was inspected from April 15 through May 13 of this year. Here again, as with Siemens, the "medical devices" created in Barrington were found to be

adulterated within the meaning of Section 501(h) of the Act [21 U.S.C. 351(h)], in that the methods used in, or the facilities or controls used for, their manufacture, packing, storage, or installation are not in conformity with the current Good Manufacturing Practice (cGMP) requirements of the Quality System (QS) regulation found at Title 21, Code of Federal Regulations (CFR), Part 820.

There were 12 points of failure, although the letter rather explicitly states that the list is "not all-inclusive." Most were addressed by GE, with most of the responses deemed "inadequate." The letter contains chapter and verse of the regulations that were not satisfied, with examples thereof. There were significant problems with analysis of processes, records, etc. The procedure for implementing design changes was flawed. An MDR report was not submitted with 30 days of receiving information that a device had malfunctioned and could "cause or contribute to a death or serious injury if the malfunction were to recur." Apparently, this refers to a a misdiagnosis which occurred after an incorrect patient jacket opened on a Centricity PACS workstation.

The letter concludes:

You should take prompt action to correct these deviations and to establish procedures to prevent their recurrence. Failure to promptly correct these deviations may result in FDA initiating regulatory action without further notice, including but not limited to, seizure, injunction, and/or civil money penalties. Also, federal agencies are advised of the issuance of all Warning Letters about devices so that they may take this information into account when considering the award of contracts. Additionally, premarket approval applications for Class III devices to which the Quality System Regulation deviations are reasonably related will not be approved until the violations have been corrected. Requests for Certificates to Foreign Governments will not be granted until the violations related to the subject devices have been corrected.

Please notify this office, in writing, within 15 working days of receipt of this letter of the specific steps you have taken to correct the violations, including:

• An explanation of your plan to prevent these violations from recurring.

• Any documentation of the corrective actions you have taken.

• An explanation of each step being taken to identify and make corrections to any underlying systems problems necessary to assure that similar violations will not recur.

• A timetable for implementation of corrective actions. If they will not be completed within 15 working days, state the reason for the delay and the timetable for completing the corrective actions.

Finally, you should know that this letter is not intended to be an all-inclusive list of the violations at your facility. It is your responsibility to ensure compliance with applicable laws and regulations administered by FDA. The specific violations noted in this letter and in the Inspectional Observations, Form FDA-483, issued at the closeout of the inspection may be symptomatic of serious problems in your firm's manufacturing and quality assurance systems. You should investigate and determine the causes of the violations, and take prompt actions to correct the violations and to bring your products into compliance.

I think they mean business. AuntMinnie reported GE's response:

"GE Healthcare takes the warning letter very seriously, and is actively working on providing the information requested by FDA in the warning letter and on identifying further enhancements to the site's quality systems that may be appropriate," the statement said. "GE Healthcare is committed to providing its customers and their patients with products that are safe and effective for their intended uses, and to following FDA requirements and guidance on how this can be best achieved."

I'm sure they will take care of these little problems.

This whole episode teaches us some important lessons. First off, no one and no company is perfect, even GE. Second, complaints are a critical part of the process, and must be handled rapidly and seriously. The FDA knows this, and I think every manufacturer of a medical device knows it too. There is no way to test every possible permutation of code in the lab, and the end-users will almost certainly find something unforseen. Ultimately, we all have to listen to each other. Medical device manufacturers have an even more specific duty to understand the complaints of their users. A glitch in this realm has the potential to kill, and that is not an exaggeration. Granted, there are some of us users that just like to whine, but others really are trying to help improve the product, and make it safer and and better for everyone. After all, every one of us, IT CEO's, software engineers, and even doctors, will be patients one day.

Sorry about that, Mr. Wanchoo.

So, if there happens to be a list of problems floating around on the Internet somewhere, do have a look. It could perhaps help limit the joys of a Letter of Warning.

Emily--She's Unreal!

From the UK's Times Online comes a fascinating discussion of a new era in computer animation. Have a look at the video below:




This amazing clip shows just how far we have come in this realm. The girl in the movie is the "output" of a computer system at Image Metrics, the folks that animated Grand Theft Auto. What you see in the movie is a completely digital rendering of actress Emily O'Brien. I can't tell the difference between the real thing and her digital doppleganger.

The data is acquired as follows:

One of the attributes that sets Image Metrics apart is their unencumbered video-capture process. Using standard or HD cameras, or a head-mounted camera, an actor's performance is perfectly captured with all of its nuances and subtleties. There are no time-consuming markers or makeup to apply. The director is free to capture the performance he or she needs, while the actor has the freedom to move unhindered about the stage. The result is spectacular performance-driven animation every time.

An actor reads the script and performs the scene as they would on stage.

A director controls the actor's performance as cameras capture it.

The actor can perform freely, without markers or makeup.

The absence of those same markers and makeup allow directors to see the subtleties of an actor's performance.

In addition to taking less time to set up, the director can get the performance he or she wants for their film.

The improvement of Image Metrics' current methods over earlier attempts is the introduction of much finer control, essentially down to the individual pixel level. Beyond this,

"Ninety per cent of the work is convincing people that the eyes are real," Mike Starkenburg, chief operating officer of Image Metrics, said.

"The subtlety of the timing of eye movements is a big one. People also have a natural asymmetry - for instance, in the muscles in the side of their face. Those types of imperfections aren't that significant but they are what makes people look real."

Technology had to catch up for this to be possible:

For many years now, animators have come up against a barrier known as "uncanny valley", which refers to how, as a computer-generated face approaches human likeness, it begins take on a corpse-like appearance similar to that in some horror films.

As a result, computer game animators have purposely simplified their creations so that the players realise immediately that the figures are not real.

"There came a point where animators were trying to create a face and there was a theory of diminishing returns," said Raja Koduri, chief technlology officer in graphics at AMD, the chip-maker.

AMD last week released a new chip with a billion transistors that will be able to show off creations such as Emily by allowing a much greater number of computations per second. "If you're trying to process the graphics in a photo-realistic animation, in real-time, there's a lot of computation involved," said Mr Koduri.

By 2020, the line between photo and photoreality may well be completely blurred. I'll bet it comes sooner than that, based on Emily.

Think of the possibilities. With the proper apparatus, you could have yourself scanned and placed in whatever movie you want....

Brave New World, ain't it?

Virtual Servers and PACS

The thought of multiple operating systems running on one computer is nothing new. My very own Dell Outlet-Site 8Gb RAM extravaganza now can be booted into Windows XP x64, to take full advantage of those 8G's, or into XP Pro, to use the peripherals that x64 doesn't support (pretty much all of them.) One of the things computers do quite well is to run lots of different things simultaneously, although I can't with my present set-up run XP Pro and x64 at the same time.

It turns out that with the proper layer of software, such as the products from VMWare, one can simultaneously run two (or more) virtual machines on one piece of hardware. This lends itself well to servers, but it can work with desktops too.

Why would you do this? From VMWare:

• VMware Server enables users to quickly provision new server capacity by partitioning a physical server into multiple virtual machines. With VMware Server, users can:


• Provision a new server in minutes without investing in new hardware


• Run Windows and Linux operating systems and applications on the same physical server


• Increase the utilization of a physical server


• Move virtual machines from one physical host to another without re-configuration


• Easily migrate virtual machines to VMware Infrastructure


• Access enterprise-class support organization


• Efficiently provision, monitor and manage infrastructure with VirtualCenter add-on


• Capture state of an entire virtual machine and roll back to that state with the click of a button

So what can you do with this?

• Streamline software development and testing by allowing developers to create multiple environments with different operating systems on the same server


• Simplify IT testing of patches, new applications and operating systems by allowing systems administrators to test in secure virtual machines and be able to roll back to a clean state by leveraging snapshots.


• Simplify server provisioning by building a virtual machine once and deploying it multiple times


• Evaluate software in ready-to-run virtual machines without installation and configuration


• Re-host legacy operating systems such as Windows NT Server 4.0 and Windows 2000 Server in a virtual machine running on new hardware and operating system


• Leverage pre-built, ready-to-run virtual appliances that include virtual hardware, operating system and application environments. Virtual appliances for Web, email, proxy and other infrastructure services are available for download from VMTN.

And how does this work?

VMware Server installs and runs as an application on top of a host Windows or Linux operating system. A thin virtualization layer partitions the physical server so multiple virtual machines can run simultaneously on a single server. Computing resources of the physical server are treated as a uniform pool of resources that can be allocated to virtual machines in a controlled manner. VMware Server isolates each virtual machine from its host and other virtual machines, leaving them unaffected if an application in a virtual machine crashes. Data does not leak across virtual machines and applications can only communicate over pre-configured network connections. VMware Server encapsulates a virtual machine environment as a file, which is easy to back-up, move and copy.

The banner at the top of the post suggests that the main impetus for this software might be green, in otherwords running fewer computers, and using less energy. If your energy bills are outrageous, you might consider this rationale. Reuters reported that a hospital in Munich, Germany, achieved a 50% energy savings in this manner. However, reducing the number of hardware servers altogether is probably a better reason. Our PACS implementation uses about 10 servers, with production, test and fail-over devices for PACS and RIS, and others for additional applications. Several of these might not require the full resources of an individual server, and the combination of virtual servers would suffice.

A whitepaper from Stratus Technologies dated June, 2008 further discusses the use of server virtualization:

Server virtualization is getting attention as hospitals and other healthcare delivery organizations increase IT usage while seeking ways to accommodate its cost. Among many other advantages, virtualization allows healthcare delivery organizations to save money by consolidating a number of applications on the same physical server. Server virtualization can be defined as the practice of using a software layer to let one physical computing server run multiple virtual machines that support multiple applications.

Why Virtualize?

Server Consolidation: Many applications in the enterprise require as little as 5-10 percent of a server’s capacity. Business enterprises that have implemented virtualization are opting to consolidate a number of these applications on a single physical server, while planning capacity for growth in the total workload.

Application Lifecycle Management: Compared with typical enterprise applications, healthcare IT applications are distinguished by the need for long lifecycles-possibly a decade or more. After the IT solution is in production, healthcare delivery organizations want to ensure stability and reduce risk by avoiding changes to the software application itself, as well as the operating system and the server hardware.

• Speed and ease of provisioning. Server virtualization allows you to create a standard virtual machine - consisting of software files that include the application and an operating system - that can be copied onto a server in a matter of minutes when additional capacity is required. The virtual machine can be qualified and tested in advance to ensure it will work as expected.


• Hardware and capacity upgrades. When more processing power or storage capacity is needed, virtualization can similarly let you move the virtual machine to newer hardware with no change to the application or operating system. You are not locked into older hardware.


• Failover and disaster recovery (DR). A virtual machine’s image - including configuration state, disk state and so on - residing on one physical server can also be periodically replicated to another physical server for backup or fast restart. Healthcare delivery organizations can use this capability to support DR. Not only is it prudent to provide for recovering electronically stored health data, but also The Health Insurance Portability and Accountability Act (HIPAA) requires a DR plan to do so. Some virtualization software also allows for point-in-time rollbacks. Useful when data corruption has occurred, rollback lets an administrator revert the virtual machine to an earlier known good state.


• Upgrades without downtime. A capability known as live migration allows for planned hardware and operating system upgrades (in cases where the operating system is not visible to the application) with virtually no interruption to the application and little perceived impact by users. Note that the operating system that can be upgraded is at the host OS/hypervisor layer; guest operating systems cannot be upgraded online.

So, it's an interesting idea, but Stratus identifies some potential problems, particularly worrisome in the health-care realm:

While consolidating applications on fewer computer servers has significant benefits, risks exist when the underlying platform (including hardware, virtualization software layer and drivers) is not sufficiently robust. A problem that affects the platform could cause downtime or performance issues for all the applications on that platform. The incident could then be followed by a long recovery time.

Stratus projects that this process will evolve into "True Utility Computing":

People want pools of servers that not only run multiple applications, but also enable dynamic and fluid use of resources. In the future, automated management capabilities - such as application-sensitive monitoring and intelligent policy making - will be necessary to bring this flexibility to the mainstream.

Until we reach this point, we'll have to be satisfied with VMWare, or other (nonfree) options such as Microsoft Virtual Server.

I haven't found many references to the use of virtual servers with PACS. Some posts on the Fuji Synapse message board suggest some hesitation:

I would not dream to install it on anything but a real server running real Windows OS. Some things like your core database you should not compromise on in the CIO / CTO'seffort to save expenses and virtualized the data center. You need a robust cluster to avoid downtimes. This I would insist and draw a line in the sand on if I were you...Same goes with your IIS ( DICOM ) Servers. Unless you can get 100 MB right up to the blade where the blade running Vmware / windows is, your performance in image transfer is going to be poor. I set up a test of this and the Vmware instance of a Fuji DICOM server would only allow users to download image to workstations at ~ 9 IPS versus a real servers speeds of 20+ IPS.

So, virtual servers might not yet be ready for PACS primetime, but certainly some of the less-demanding services, RIS, corporate email, and so on, could work well in this environment. Maybe cutting the purchase of one server won't make that much difference in your enterprise, but then again, it might, and this technique allows that possibility.

Could radiologists ever go virtual? They already have! Well, not really, but you get the idea.

90,000 Hits . . .While Dalai Does Acapulco

A lucky reader from Mount Clemens General Hospital, in Mount Clemens, Michigan, scored the 90,000th hit on DoctorDalai.com. I'm going to have to create a contest or offer a prize for #100,000.

We've had several hundred hits since then. You see, I do need to get away from the world of PACS every now and then, so Mrs. Dalai, my daughter "Dolly", and I spent a few days in Acapulco. You can get some good last minute deals, and in particular, Orbitz.com was able to deliver the hotel and the flights I wanted at a very good price.

Acapulco occupies a lovely bay off of the Pacific coast of Mexico. At night, the lights go on up into the hills, and they create one of the most beautiful vistas in the world.

We returned to a place called Las Brisas, where we had stayed 18 years ago. The motto of this pink and whitewashed hillside resort is that children are "seldom seen, but often made" there. My daughter is 20, but when we told people of our prior visit, we could see the wheels turning. Not quite, folks. (There were actually a bunch of kids staying at the resort this trip, reversing the philosophy.) Each room, or "cassita," has its own pool into which the staff throws hibuscus blossoms (some rooms share a pool), and the effect is very striking:

Las Brisas used to provide Jeeps to the guests for their use about the resort and in town. Sadly, traffic in Acapulco is totally unmanagable for a gringo like me, and apparently there were some incidents with the local police stopping the well-labelled tourists. Today, if you want a car, you have to rent your own. I could have had a SmartCar (not so smart in Acapulco traffic) or a non-pink Jeep, but I'm not good enough or crazy enough to drive there today.

We saw the obligatory sights, including the cliff divers (no doubt there are some out there who would have encouraged me to give it a go...)

I did get conned into trusting my life to this lovely horse for a ride on the beach. I won't be doing that again anytime soon...

The worst part of any vacation, of course, is the return to reality once it's over. I hope you'll forgive my brief hiatus in posting, but Las Brisas is only now acquiring WiFi. So much for paradise...

Amicas V6. . .It's Almost Here

I'm just back from Boston, having spent the past several days holed up with the developers of Amicas' latest and greatest, Version 6, or V6 for short. This was a lot more fun than you might think, as these are not only brilliant folks, but they are also some of the nicest and most down-to-earth people I know. They welcomed me and Mrs. Dalai (who was not amused by her title) to Amicas' world-wide headquarters (which is in the New Balance building by chance) and made us feel right at home.

I had the chance to simulate my workday sitting in front of a V6 workstation. As an added bonus, we were using one of the new Barco 6MP color monitors. I want one, although the $17K price tag will keep it out of my reach for a while.

HQ is a maze of cubbies and computers, much like any of the dot.coms in their heyday. There is no impending sale of the company, thank you, and work proceeds nicely on several fronts.

I cannot post any specifics on V6 at the moment, but your patience will be rewarded before too long. I will go out on a limb and tell you that its code name is "Phoenix", which is a bit of hyperbole based on the fact that this is one of a very few PACS products that has been completely rewritten from the ground up. Since its predecessors are still functioning well, the imagery of "rising from the ashes" is a little overblown. When I first saw the initial stub-laden pre-alpha version, I commented that it should be called "Freedom PACS" as in freedom from the way other big companies do things. That hasn't caught on as yet, but I keep hoping for a change of heart, and a chance at residuals for coining the name.

Since I can't tell you much about V6, I am left with telling you what it doesn't do (obviously stuff that can be found on some competing products):

1. V6 doesn't have an unstable worklist
2. It doesn't allow two people to be dictating the same study at the same time.
3. It won't show the demographics for the last patient you were looking at for 20 seconds or so while displaying the images for the next.
4. It will not show you the wrong report associated with the prior study you are viewing.
5. It will not randomly choose a prior to show you even after you have clicked the one you do want.
6. It doesn't have a hanging protocol setup so badly done that you don't bother using it.
7. V6 doesn't make you wait for everything in the worklist to be cached before it lets you start viewing an image.
8. It will not mistake "relevance" for "relevants"
9. It will not limit me to one viewport for one series, and float the series selectors over the viewing real-estate.
10. It will not utilize "toggling".
11. It will not treat examinations of the same patient from different campuses of the same hospital system as coming from entirely different patients, thus impairing comparison.
12. It will not hide functions in unexpected places.
13. It will not be confused as to how a three-dimensional cursor should operate.
14. It will not assume that changes (like windowing) to one slice of a CT or MR should not propagate to the rest of the series.
15. It will not erase the search-term you last used when you click in the text-window.
16. It does not make you open a study to see if someone else is reading it.
17. It will not display a study that was on your worklist when you first started reading, but has since been dictated.
18. It will not restrict you to six measurements per slice or image.
19. It does not make you buy another client and separate program to run via the web.
20. V6 will not be integrating someone else's software into an older version of itself to form any sort of hybrid product.
21. It will not require additional (extra cost) software to display MPR's or VR's.
22. It will not automatically change the parameters of a search from "all times" to "Last 7 Days".
23. It will not restrict you to placing a series in one and only one viewport.
24. It will not force you to use clone windows.
25. It will not make extensive use of toggling.
26. It will not promise individual functions (pre-cans, worklists, etc.) that somehow become system-wide and not individual at all.
27. It will not randomly change column-widths and sorting parameters and such.
28. It will not carry through old ideas that didn't work for anyone except for a select few members of a very focused focus group.
29. It was not created by letting the inmates run the asylum (thank you Alan Cooper!)

V6 will show the industry how PACS should work. As with Amicas' previous offerings, it will not be perfect, but it is pretty darn good. Trust me on that.

I'll let you know more shortly.