Tuesday, September 30, 2008

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:


Text not available


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:


is to be limited only 10 include all such viewed in conjunction accompanying drawings We claim 1 A system for a location where 15 structure for button of the including the keyboard to the desired location the left button Any appropriate to its default the A icon in executed by annotating a 20 by reference that the of selecting the anatomical sequence of a 25 annotation list commonly employed The procedure an annotation list in the 30 this icon is and is moved in location At the trackball is depressed list to the box 35 panel For so means including one displaying at least display area areas hi a means for storing an of images of being groups hi which each unage group identification each image group ordered unage including a incrementally target each assignment to numerical changing physician data tables unique group

and




series in the order of in a respective display container presentation area of the tainer includes no more than one to designation of the monitor mode 5 The system of claim 1 further means for displaying a palette the one or more display monitors play container for presenting a areas in an array and means for selecting an image of an in the at least one reproducing the selected image area of the palette display 6 A method for presenting structure for examination by a method being executed on a having a display for displaying at least one subdivided into a of Text not available

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.

Saturday, September 27, 2008

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.

Friday, September 26, 2008

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.

Sunday, September 21, 2008

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.

Wednesday, September 17, 2008

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.

Tuesday, September 16, 2008

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.

Friday, September 12, 2008

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.

Tuesday, September 09, 2008

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.

Saturday, September 06, 2008

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.

Wednesday, September 03, 2008

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!

Monday, September 01, 2008

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!