Euros, Assumptions, and Greek Islands

You may notice some degree of stagnation on the blog, as I have not posted in several weeks. I’ll try to remedy that situation.

I am presently in Rome, Italy, following a cruise of a few Greek Islands, Split, Croatia, and Venice. It was actually a meeting cruise, with a number of lectures on CT by Elliot Fishman, M.D. and other radiological celebrities. I wonder if they realize that they were on the ship with the (in)famous Dr. Dalai… The cruise itself was OK, but I do have to give one warning: Unless you are clinically deaf, avoid the Royal Caribbean ship Splendour of the Seas like the plague. It is an older ship with absolutely no insulation between decks. We could rarely sleep due to the constant banging around and dragging of chairs on the deck above us. Not good. However, there was a great deal of CT knowledge imparted to the participants, and I'm going to try to apply at least some of what I learned to my daily practice. Although the meeting wasn't about PACS, I did acquire a few tidbits here and there. Several of the other participants have Agfa Impax 6 and hate it. One fellow replaced an old (2003) Amicas system with Dynamic Imaging and loves it. Dr. Fishman himself uses Emageon at Johns Hopkins, and complained numerous times that it chokes if they try to load a CT series that contains more than 100 images. That's 100, folks, not 1000. Their solution has been to use Siemens WebSpace, a remote client version of InSpace, for multislice CT studies of more than 100 slices, which is about everything they do there at Hopkins.

There is a thread on Aunt Minnie which was prompted by my recent article, Dalai’s Laws of PACS. This discussion has gone from hashing out what clinicians should expect out of PACS (a major point that I left out of the Laws) to a longer chat about vendor-neutral archives and databases. I don't claim to have all the answers on that one, nor do I begin to understand all the underlying DICOM issues involved. However, two experiences from this trip I'm on may provide some useful analogies.

The issue was rather well-stated by David Clunie (of course!) with this post toward the end of the long thread:

We have talked about the "vendor-neutral image archive", which could be the place in which images and other (standard) composite DICOM objects live; would it also be feasible to discuss a "vendor neutral image database" as a separate entity from the archive, which multiple PACS and/or "Image Manager" actors could access ? I say this, because it is useful to have central and accessible database of the images and various additional information that may not be strictly related to or extractable from the DICOM image headers and have no business in there (e.g., read status, legal name changes like getting married, etc.) - this information is needed by multiple production systems (e.g., different PACS, different RIS, web server, EMR, etc) in addition to the image locations, yet is perhaps separate from the "PACS" functionality per se. Also, during PACS migration, such a database might not need to be changed, or could be serialized in a "vendor neutral image database interchange format" that could be "read into" the next database. In the past various folks have proposed extensions to support PACS migration that serialized a snapshot of this information (even suggesting a huge DICOMDIR for this), but I am not sure that there has ever been a serious attempt to factor out a shared, live, standardized, database. In a sense, the VNIA and the VNIDB would to in-house PACS what the IHE XDS repository and XDS registry are to cross-enterprise document sharing; not that I am suggesting that XDS is necessarily the appropriate technical solution for this. Ordinary SQL access might be an option; another might be Grid Service based queries such as are being developed for caBIG imaging, which also have the benefit of a comprehensive security model.

Early on in the discussion, I think I was mentally considering the archive and the database as one, which is not strictly accurate. For me, the bottom line is this: I want the ability to plug different tools, modalities, and especially workstation GUI's into my database. Simple concept, difficult execution, apparently. But here is where the first European example comes into play. You are all familiar with the Euro, the new currency used by the multiple countries of the European Union. Anywhere within the EU, a One Euro Coin looks like this on the back:

But on the front, the different member countries can display their own design. Here are the coins from Greece, Ireland, and Italy:

My point here is that all these coins are worth one Euro. They look slightly different, but they do exactly the same thing. Such would be my vision for a Vendor Neutral system. I want to be able to buy a database from Belgium, as it has the reputation to be the best. I want to plug in a scanner from Germany, and have it talk to my database from Belgium without any add-ons, extra interfaces, or especially extra charges. I want my interface from Greece, my 3D app from Ireland, and so on. Quite roughly, interchange DICOM for Euro, and you see where I'm going with this. DICOM needs to be the unit of currency for PACS. The only problem with this concept is the vendors' insistence on the use of Private Attributes, factors that make their systems different, but don't translate from PACS to PACS. WindowsPACSMaven proposes a possible solution:

To alleviate the above mentioned issue with Private Attributes I decided with a colleague in 1998 that we would design a PACS using "Native DICOM". Native DICOM is DICOM V3.0 with no Private Attributes! To do this we partnered with a major university to be sure that no vendor attributes got into our design...By using Native DICOM we would be guaranteeing viewability anywhere that DICOM V3.0 is present. So if we can get Radiology to start to use Native DICOM through vendor and/or open solutions the problems with storage and retrieval will be minimized going forward from here. Because the Native DICOM concept is so radical I actually lost my job for promoting this concept and am now an independent software developer for healthcare! Because of my job loss I still have to remain anonymous so that I don't affect my future income possibilities since I do consulting for healthcare vendors.

One would assume that the big boys have something to lose with this approach, eh? Therefore, it must be good! OK, OK, there is a lot more to the issue than I've presented, but the idea is clear, and I think it has a lot of merit.

So how did we get in this situation? The second lesson from my trip might explain it. On the island of Corfu, we were enticed by Royal Caribbean's shore excursion brochure to take a "4WD trip into the hills of the island, where you will see villages rarely visited by outsiders." We were intrigued and signed up for the journey. When we got to the staging area, we found 20 little 4WD vehicles. So far so good. But upon closer examination, there was one little problem: the cars all had manual transmissions! This was a problem because I've never driven a stick, and my wife hadn't done so in over 20 years! But she bravely took the wheel, and skillfully drove up and down the hills, through little passes and treacherous switchbacks like this:

It was worth it, however, to see some of the wonderful, isolated little villages. At least that's what we told my wife when we got back! She was too busy driving, and in particular trying to keep from rolling back into the car behind us in the caravan to see the sights! Here are some typical scenes:

The lesson here is that Royal Caribbean assumed that everyone was OK with their way of doing things, that no one would have a problem with manual transmissions. They were so unconcerned with the needs of their passengers in this venue that they didn't even bother to publish the fact that the cars were only of this persuasion in any of their literature. This is they way it is, kids, it would cost us money to change it, and we assume you will like it and be comfortable with it.

I'm sure you see where I'm going with this. Do I even have to say it? Oh, well, I'm not known for my subtlety. Many PACS companies have done things a certain way for quite a while, and they assume you and I will like it. The fact that we may NOT be comfortable with it, and that we may have to waste the brainpower that we should be using to view the road, I mean the image, on driving the stick instead. The DICOM currency standard would be one way to solve this problem. One could, in theory, use an "automatic" front end to a database that otherwise had a "stick shift" GUI.

Let me wrap this up before I get even further lost in weird car analogies. Ultimately, the only "vote" we have is with our dollars, (or Euros) or those that come from our hospitals. I WANT the ability to do what I have described above, and I expect the market to provide it eventually. Royal Caribbean made what could have been a very dangerous assumption (had I tried to drive myself), and the non-insulated Splendour of the Seas deprived me of valuable sleep. My vote will be to never cruise on one of their ships again. I'll be certain to exercise the same sort of thing with other big purchases as well. Hint, hint.....

Ciao!

The Rocky Horror PET Show

A coronal slice from a PET/CT. Scary, ain't it?

OOPS, I Did It Again....Dalai's Laws of PACS Published!

I'm published again! Auntminnie.com has graciously posted a revised and expanded version of Dalai's Laws of PACS, accessible here. I guess it was a slow news-day.





I'm waiting for the, um, comments from my friends in IT.

Teleradiology Spam

You have to love spam, especially when it comes from unexpected sources. Today, I received this little opus from Dr. Ashish Dhawad, trying to convince me of the joys of using his "Telediagnosys" service operating from India:

Hi,

TeleDiagnosys is a premier provider of offsite Teleradiology/Nighthawk Reporting Services from American Board Certified radiologists.

If you are a Imaging Center / Hospital - We can provide you with STAT and Routine reports 24 X 7 leading to cost reduction.

If you are a radiology group - We can take care of any additional / overflow work that you cannot handle, increasing your productivity

Our advantages -

1) Attractive Pricing - USD 8 for X Ray, USD 35 for CT and USD 45 for MR

2) Reporting by American board certified radiologists with State licenses and malpractice insurance

3) 24 X 7 X 365 coverage

4) Turnaround time of 30 mins for STAT and 12 - 24 hours for routine studies

5) Fully transcribed reports in required formats can be emailed/faxed at no extra cost

6) US telephone number for emergency calls

7) No minimum guarantees, No Setup fees

8) No PACS to send images??? We can provide you with a complete solution

More details are available on our website - http://www.telediagnosys.com

In case you need any more information including references or trials please contact me on dhawad@telediagnosys.com or US Toll Free 800-490-0509.

With Best Regards,
Dr Ashish Dhawad
Chief Operating Officer
Telediagnosys Pvt Ltd
US Tel no: 800-490-0509
US Fax no: 703-991-1426
Email: dhawad@telediagnosys.com
URL: http://www.telediagnosys.com/

I went to the website earlier this morning, and it was quite nicely done, with Adobe Flash titles and the like. However, this afternoon, I find the website is down, perhaps due to much traffic or angry complaints spawned by the spam email advertisement. But, the Google-cached version tells us:

TeleDiagnosys Services Pvt. Ltd. is India's pioneering and premier provider of offsite Teleradiology Reporting Services from experienced and eminent doctors with fast turnaround times. We partner with diagnostic centers, individual radiologists, hospitals, medical groups and other entities requiring remote, off-site reading of diagnostic imaging studies. Using a comprehensive approach, we provide the expertise to configure, install and maintain the digital technology necessary to implement remote reading of imaging studies. We also link our clients with well-qualified & well-trained radiologists who are available to provide remote reading and interpretation services. We have the necessary infrastructure and expertise available to provide round the clock, reliable and efficient service to our clients.

I had thought this sort of thing had not caught on in the US, but in looking around the web, there are dozens of companies in India offering similar telerad services. Most claim to use Board Certified U.S. trained radiologists. Perhaps they do. Rather hard to prove from here, isn't it? Does anyone really know who is on the other end of their teleradiology or night-hawk service? Have you actually met any of them?

No matter. What these companies are selling is cheap, available radiology. Whether all of their readers are rads from Haavaard, or if they are all students at the Bangalore High School for Health Sciences, what attracts their US users is mainly the cost savings. I can tell you that Telediagnosys' prices are lower than many out there, and if you look around, you can do even better.

I don't know about you, but to me, this lowest-bidder concept of Radiology is not a particularly comforting thought. Would you base your choice of a surgeon on who will cut on you for the lowest price? Well, as it turns out, lots of folks would do exactly that. There is a new trend of "medical tourism" that inspires those who cannot afford treatment here in the US to go abroad, often to India. This article from the Providence (RI) Journal tells the story:

The first such travelers were looking for cut-rate cosmetic surgery. But today, many include people seeking necessary procedures, including heart bypasses, hip and knee replacements, cancer treatment and dental work. They are finding clean, well-equipped, even luxurious hospitals that meet accreditation standards and often are staffed by American-trained doctors. Catering to an international clientele, they provide procedures at roughly one-tenth to one-quarter of the cost in an American hospital.

Ouch. American medicine has somehow priced itself out of the market. Where did we go wrong? I have to think it is some combination of greed and fear, relinquishing control of what is still (but just barely) the best health-care system in the world to the government, and to third-party payers. The greed factor is obvious, when one looks at self-referral, and I won't bore you with that discussion again. Fear of loss of revenue is certainly a similar emotion that has driven costs up, and led physicians into areas not their own, such as (surprise) imaging, which leads to self-referral. I'm not certain if the government or the insurance company, or the uneasy symbiosis we all share with them has driven the whole system off the edge. What I do know is that costs are exploding, and if we don't fix it, our friends in Washington and Bangalore will do it for us.

Even as a physician, I'm not immune to the ravages of costly medical care. My son just had some diagnostic procedures (EGD, colonoscopy, small-bowel follow-through) for which the hospital bill alone (haven't got the physician's bills yet) was $10,000. Since his doc is in another state, and out of our insurance company's little local network, I might just have to eat that cost. I would not have taken him to India, but for someone who had no good choice, spending, say, $3000, including the trip to India and a little sight-seeing, would have been a very viable alternative.

All of us involved in the U.S. Healthcare field have to do something about this stuff, and quickly. Otherwise, Hillary-Care AND Bangalore General are going to be our future. Namaste!

Is Speech Recognition a Kickback???

Image credit: http://www.jd-associates.com.au/author/garrydisher

I wish I had come up with this myself, but instead, this comes from one of the many brilliant folks that peruse this blog and otherwise correspond with yours truly. My colleague has suffered through a forced implementation of SR, and notes the following:

Do you know if anyone has ever tried to construe the adoption of voice recognition technology as a kickback to the hospital in violation of federal antikickback statutes? It would seem to me that transcription services are traditionally provided for free by the hospital to hospital-based physicians (except of course the cardiologists and administrators don’t have to use it!) and that the cost of transcription is covered by the technical fee collected by the hospital. In essence we are providing free services to the hospital in return for a hospital contract. I wonder what the lawyers would say.

So do I.

The Inmates Are Running The Asylum

I have stolen my title from a book of the same name by one Alan Cooper. Mr. Cooper is Founder and Chairman of the Board of the Cooper company, which is devoted to leading-edge, customer/user oriented product and software design. From the company website:

For over 30 years Alan Cooper has been a pioneer of the modern computing era. His groundbreaking work in software invention, design and construction has influenced a generation of programmers and business people—and helped a generation of users. Alan is the author of two best-selling books, About Face: The Essentials of User Interface Design and The Inmates Are Running the Asylum, and his visionary ideas and outspoken style make him a popular speaker. Whether you know him as the "Father of Visual Basic," the inventor of personas, or the guy who thinks software should be spanked, we know him as the man whose ideas are the foundation of what we do.

Mr. Cooper has a rather radical outlook on software and indeed other high tech offerings. From his "Inmates" book:

No matter how early in the development process specifications are drafted, they cannot substitute for interaction design. And no matter how hard they try, programmers cannot consistently arrive at a successful design. Not only are their methods, training, and aptitude wrong for the job, but they are caught in a strong conflict of interest between serving the user's needs and making their programming job easier. Yet, in company after company, software engineers are allowed to control the development process, often from start to finish. Sometimes, their control is overt, but more typically it is indirect.

Hence, the inmates (the programmers...no offense!) are running the asylum. This is more or less what yours truly has been saying for a while in reference to PACS. The vendors are allowing their engineers and programmers to create technological magnum opuses which allow too many permutations, and ultimately get in the way of my reading my studies. Why is this tolerated? Cooper compares this to a dancing bear: we are all so impressed with the fact that bear is dancing at all, that we fail to observe just how badly it is choreographed.

So few software-based products have exhibited any real dancing ability that most people are honestly unaware that things could be better-a lot better. Most people using spreadsheets and word processors on modern computers imagine that all the problems that a computer can solve have been solved, and solved adequately if not well...Bill Gates once observed, with uncharacteristic cynicism, that the way you made software user friendly was by making a rubber stamp and stamping each box with the legend "USER FRIENDLY." Unintentionally, his method has become the computer industry's real method.

Mr. Cooper's premier design company will help one create a software product (or hardware, for that matter) that does not suffer from these maladies. The company motto is: "Companies are more successful when their products help users achieve their goals." Accomplishing this gargantuan task takes several steps, including Planning, Research, Modeling, Requirements, Framework, Refinement, and Support. Of these, modeling may be the most characteristic of Cooper's contributions.

Are you frustrated by trying to develop a product that serves thousands--or even millions--of different users? Imagine if instead of trying to please everyone, you could design for three distinct people you knew very well. Wouldn't that make your job easier?

This is the power of personas, a technique for modeling users that we invented here at Cooper. As we interview and observe users in their natural habitats, we look for patterns of behavior and goals shared by multiple people. Each distinct behavior pattern becomes the basis for a persona: a description of an archetypal user.

Personas help everyone from programmers to executives understand users in a way no other tool can: at a gut level. Personas help guide design decisions, end those lengthy arguments about what users need, and get everyone to agree on what product you're building.

You don't need an enormous project to enjoy the benefits of personas. For short projects, personas may just be quick sketches based on limited data. For large initiatives with distributed teams, a well-researched and thoroughly documented set of personas can be an essential reference and communication tool.

In an article about Cooper, Allison J. Head further describes this process:

The gist of Cooper's argument is fairly straightforward: There will be far greater success designing an interface that meets the goals of one specific person, instead of trying to design for the various needs of many. At first blush, though, it may seem downright counterintuitive to design for just one person, whether hypothetical or not. How can designing for a single soul possibly ensure an interface that supports the needs of many users? But as an interface becomes more layered and complex and tries to serve an ever-widening audience base, Cooper's argument holds true.

As long as personas are developed with diligence, the planning and development tool has three key benefits for interface design projects of all kinds. First, personas introduce teams to hypothetical users who have names, personal traits, and habits that in a relatively short time become believable constructs for honing design specifications. Second, personas are stand-ins with archetypal characteristics that represent a much larger group of users. Third, personas give design teams a strong sense of what users' goals are and what an interface needs to fulfill them.

She goes on to describe what may happen if programmers and designers don't user personas:

One of the best arguments for using personas comes from some misguided design efforts at Microsoft. When the software giant geared up to redesign its well-known Microsoft Office Suite for a 1997 release, the research team soon discovered that many of the features users wanted already existed. In fact, four out of five of the features users requested for Office 97 came with Office 95. The outcome of Microsoft's design approach is just what Cooper warns against. In trying to support the diverse tasks of many conceivably different software users, Microsoft cobbled together a product that was bloated with capabilities and ended up satisfying few users.

I think most would agree. I am reminded of some PACS systems I have used....

Anyway, how might this approach be used to create a PACS? Can we assemble a "Joe Radiologist" persona that would cover most radiologists? Well, let's see.... What do radiologists do all day with respect to PACS? We sit in front of the darn things and read studies. That pretty much is all we do, except for the interventional types and the barium-slingers. The real question is how Joe Radiologist wants to interface with his PACS. That is indeed the question. If I were taking this approach, I would talk with all of my partners, and ask them what they like and what they don't like about the PACS systems we already use. In fact, I would post the question here on the blog, and open it up to as many rads as possible. I would then synthesize and distill this wide pool of answers down to a usable persona.

The key to this process is, I believe, to drop all preconceived notions, but not to forget lessons learned. If you are going to build a PACS (or a car, or a toilet-paper holder) you would like to make it usable, and comfortable. There should be adequate features to cover at least 95% of situations that will arise (easy with toilet-paper holders, harder with cars, easier than some think with PACS.) Many products out there are obsessed with how to handle something that Joe Radiologist might have to do once a week, or once a month, and pay little attention to the repetitive grind that makes up 95% of our work. And many vendors are stuck in the rut of doing things the same way, version after version. Therefore, it is critical to see how a wide swath of your potential customers would use your product, and it is very important to understand how they work with your competitors' versions of the same thing. When Saab designs a new car, for example, it is probably wise to determine if the 99% of the world that buys cars other than Saab's would appreciate having the ignition key on the center console, which is where Saab (and no one else) puts it. If you are a PACS company, it is probably not terribly wise to gear your Joe Radiologist persona to those who are mostly users of your PACS, and then proceed to come up with the next generation of a PACS with its ignition key on the center console. I should also add that real radiologists need to be reintroduced to the process; don't go with the stereotyped "Joe" for a prolonged period without a reality-check from the flesh-and-blood version. Trust me, if these caveats to the Cooper approach are discarded, the result will not be what "Joe Radiologist" wants at all.

One of my partners told me in all seriousness that I should create my own PACS system. I wish I had the time and the wherewithall to do so. Of course, out of vanity, my persona would be used instead of "Joe's" which would naturally yield the most wonderful system ever. Absolutely. Guaranteed.

40,000 Hits and Repeat Customers

Image Credit: http://www.scifi.com

This is a first, folks! I think Visitor 40,000 happens to have been number 20,000 as well. I'm assuming that there aren't too many folks in Montevideo, Uruguay who peruse this stuff, so I'm thinking this represents another visit from Rafael Sanguinetti of www.charruasoft.com. Thanks for your support!

A Survivor Of Voice/Speech Recognition Speaks Out

(Dalai's note: I was approached by a colleague, and asked if I would post his VR/SR experiences online, but anonymously so he would not have the vendor in question breathing down his neck. I am more than happy to do so, and here it is....)


I will start by telling of our voice recognition (VR) experience.

About one and a half years ago we launched VR to our hospital system. It was an integrated “front end” VR product that resided on our PACS workstations. You may or may not have preconceived ideas about what quality we might have purchased, suffice it to say we purchased what for all intents and purposes, seemed to be the best VR product on the market. No we didn’t buy some outdated piece of garbage.

It was a planned 6-week launch with training provided primarily by the VR company. Initially, we were expecting things to be a little stormy; how wrong we were. First, we had scheduling problems with training, there were rads that were unavailable for training and the amount of time dedicated to each rad was short, only a few hours. In addition, the rads were learning while still having to attend to some clinical duties, which was a BIG MISTAKE.

So after a few weeks, the trainers left, there were still rads that had almost zero actual training. Our IT/IS support staff tried to help out as much as possible. It was just over a month when things in the department finally caved in. We were chronically short staffed, radiologist wise, and work wasn’t being finished. Those of us who took to VR somewhat well were being completely overrun by those who did not, both in having to field multiple near hysterical calls and a markedly increased workload. There were multiple unexplained system crashes (denied initially but fixed somewhat in a later patch) and a greatly degraded workstation performance.

We had numerous direct meeting between the administration, radiologists, and VR company. Here is what we got, repeated requests for the radiologists to document every occurrence of problems (yeah, right, like we weren’t totally swamped as it was what’s one more thing to do), repeated denials of their software being to blame for workstation slowness and crashes (of course later we would learn that yes it was their software causing crashes and system performance issues), repeated promises to fix the problems.

After almost 2 months of this I, being the “radiologist champion” for VR and about 2 seconds from a complete nervous breakdown, told myself “Either I stop using VR or I hand in my 90 day notice and look for a new job”. I turned off the VR product and told my fellow radiologists that I would no longer be fielding their questions about “how to make VR work”. The rest of the group followed suit immediately. It imploded over night. Problems that still existed at this time were:

1) Random crashed requiring a system reboot
2) Unexplained, or rather un-admitted, slowness of the workstation
3) Consistent patterns of errors in VR, it did not appear to be learning no matter how many times corrected
4) Almost no one in the department (IT/IS included) really knew how to use the advanced functions, macro generation was “trial and error”
5) Lack of advanced support, many question to our IS/IT people generated a response “I’ll send and email to VR company and see what they say”
6) Many errors sent for “transcriptionist editing” came back uncorrected, the error rate of “transcritpionist editing” was far greater than the old system. Many report errors escaped the radiologist review as well and went out finalized. Many, many months later I would learn we had some actual “transcriptionist sabotage” going on and this was NEVER disclosed to the radiologists.
7) A horrific loss of productivity in an already short staffed group.
It died for a long time; of course the hospital had a vested interest in making this work.

We recently had a visit to a “model group” for VR and got to see them in action. The model group watched us and decided to purchase the product anyway. They are a large group; they owned the transcription, PACS, and other things and “contracted” these things out to hospitals. This was a business decision by a group that owned the entire infrastructure. They did things very differently and claim a 90+% “sign off” rate. Here is what we observed and were told:

They began by sending their IT folks to the VR company for intensive training. They refused the VR company's offer to do radiologist training; they were going to handle that all in house. Prior to launch their entire IT/IS support staff had been using the product for “months” and were fluent in its use. This was before a radiologist touched it. After launch they had their trainers go back for additional training to learn to “hack” the word lexicon to overcome pattern of repeated errors. This has worked very well for them and is a process discouraged by the VR company. What we learned, to our dismay, was that VR was not just “appearing” to not learn certain repeated phrases or words, it REALLY WASN’T learning them at all, no matter how many times we made corrections manually. The "model group" placed skilled VR support staff available 24/7, to immediately respond and deal with radiologist problems with VR.

They began by doing a “staged” launch of VR, starting with sections and working 1 section at a time. Each radiologists was initially afforded a full half day of one-on-one training with no clinical duties (no phone calls, no tech interruptions, no exams needing to be read, NOTHING); after that they each received 3 full days of one-on-one training while working (they estimated a total of 24-28 training work hours for each rad). By one on one they mean the trainer was physically in the same room or sitting outside the radiologists door. They had section meetings every morning to discuss VR’s use and share tips; they relied on a lot of “peer pressure” to make things go smoothly. The entire launch was slated to take about 1 year.

The made sure their workstation greatly exceeded the VR companies recommendations. They made sure their transcriptionists were folded into other duties as they lost their need for so many of them. I would add here that prior to VR this groups report turn around was poor, over 2 days for routine stuff.

We were also told the group was now considering “financially penalizing” rads that are using too much transcriptionist editing, this was not implemented yet and the penalties they were considering was not shared with us.

We then got to observe some rads in action. It really wasn’t magic. First, they have employed radiology “assistants”. These folks do a lot of the “scut work”, phone calls and so on; they basically make sure the radiologists are not disturbed and the hospital pays for them. One rad was a “macro master” although he appeared to spend much more time looking at the VR than the exam. One rad absolutely hated the VR system, so all is not roses at this model group. The next few rads showed all the problems we have seen all along, lots of little annoying errors. Every rad admitted it slowed them down but they had “made up” for it through intense training, heavy assistant use, awesome IS support staff and excellent equipment. They did feel, well, most of them, that it was “worth it” for various reasons.

They did confirm many things we radiologists already knew. Things like the software’s inability to learn certain works on its own, or rather the pattern of making repeated patterns of errors. The VR company’s gross underestimation of the training needed and IS support staff needs. The performance issues on the VR companies “recommended” systems. Basically this is something the radiologists need to “buy into”. They did admit to the limitations of VR but that it is improving and “As long as the radiologists see continual improvement they will stick with it”. They also, on their own, identified and developed work-arounds for many conflicts the software was having with other office software products.

Where do we go from here? A few in my group had prior experiences with VR, all universally negative. I had a hope, as did the administration, that “This is such a superior product, it will be different this time”. It was very disappointing to see not only every fear confirmed, but also some new ones learned. Any trust between the VR company and the radiologists has been completely destroyed beyond repair. This experience has certainly made us much more cautious in trusting the word of any vendor, especially software vendors as I feel they may not fully grasp that they are selling a medical product and not a video game (i.e. doctors have zero tolerance for “buggy” software and more than they would tolerate a “buggy” CT scanner). So it stands with my group, many of whom now have the well justified attitude of “Hell will freeze over before I turn on VR again”. I am not sure this can ever be turned around. I hope, if nothing else, this review serves as a warning, to radiologists, administrators and most importantly VR vendors that VR is not something to be taken on lightly.

In a similar vein to Dalai Lama here are my 10 commandments for VR:

1) Voice recognition (VR) exists as only one of multiple possible solutions to address the problem of radiology report turn around time. The underlying problem being the near instantaneous distribution of images through PACS unaccompanied by the radiologist report.
2) VR will only see its maximum benefit (i.e. near instantaneous report generation) IF the radiologists self edit and sign off the majority of reports.
3) VR with or without self editing slows radiologists down. It costs productivity as radiologists are now forced to spend additional time either self editing or reviewing the VR generated reports for errors. Do not assume your radiologists are going to quietly eat this productivity loss.
4) The loss of radiologist productivity can be compensated, to some degree, by the use of radiologist assistants to do some tasks formerly done by the radiologist. Also there is a gain by the lessened need to re-review cases that have been dictated but not transcribed. Despite this there may still be a long term net productivity loss. Again, do not assume your radiologists are going to quietly eat this productivity loss.
5) Poor system performance is a guaranteed PACS/VR killer.
6) VR and PACS are by definition “beta” software. There is no such thing as a perfect PACS or VR software; there are only “acceptable” performance parameters that will improve over time. VR may never be perfect.
7) The hospital shall accept it’s responsibility for supporting VR by ensuring it’s IT/IS support staff are well versed in PACS and VR and available as long as the radiologist are working. The IS/IT support staff shall have a full working knowledge of VR and be capable of training radiologists before a radiologist ever touches the software.
8) VR requires far more IT/IS/training support that the VR companies will admit.
9) VR is not a big money saver if properly implemented. Any savings from transcriptionists will be quickly eaten up by the need for hardware upgrades, software upgrades, training and the needs for additional support staff.
10) Before implementing VR, ask yourself “Am I doing this for the right reasons and am I willing to commit additional resources, possible indefinitely, to the proper launching and support of VR?”

PACS Abuse

An observant AuntMinnie poster found this lovely little item from the Cleveland Clinic:

Sub-specialized medical care is the standard of care today. Only an orthopaedic surgeon would perform an anterior cruciate ligament reconstruction, and only a neurosurgeon would remove a brain tumor. It is still common however, for general radiologists with no sub-specialized training to interpret the images that lead to these procedures.

This lack of sub-specialized radiology interpretations previously was necessary because of the need to have a radiologist in close proximity to the imaging center where procedures were performed. Now, through the use of new developments in information technology systems, Cleveland Clinic’s Department of e-Radiology offers sub-specialized radiology interpretations to referring physicians anywhere in the country. Better quality of medicine is possible through the use of interpretations and protocols developed and performed by Cleveland Clinic sub-specialty-trained academic radiologists.

A number of factors made growth in e-Radiology possible, most notably the imaging explosion of the past few years, which is expected to grow at the rate of 8% to 10% per year into the foreseeable future. Two additional factors are the national shortage of radiologists and the rapid developments in information technology that have allowed image interpretation to occur independent of geographical restrictions.
A large portion of the imaging growth is in outpatient imaging, with an estimated half billion outpatient imaging examinations projected to be performed in 2008. In 2002, 84% of magnetic resonance, 64% of computed tomography and 98% of positron emission tomography scans were done on an outpatient basis, and these percentages are expected to continue to increase over the next ten years. Only 67% of imaging is currently done in hospitals, down from 95% in 1980. Outpatient imaging accounted for $14.8 billion in Medicare revenue for hospitals in 2001 and generated $3 billion in profits.

Radiologist shortages have been significantly resolved through the use of teleradiology. Over the past few years, dramatic advances in information technology and the availability of technology in cost-effective pricing, high-speed telecommunication lines have removed almost all geographic restrictions in interpreting images. It is now possible to send digital images securely over the Internet on a virtually real-time basis to radiologists located anywhere such telecommunication lines exist. The radiologist is then able to dictate the images using voice recognition software so that the images and report are available online for the referring physician within minutes via a HIPAA-compliant Web browser.

This is just plain disturbing on several levels. First off, the piece insults general radiologists, who are for the most part quite good at what they do. Will a super-specialized rad be better for the esoterica of his specialization? Probably, but on a day-to-day and head-to-head comparison, I thing we would find that the generalist can hold his own. I am very distressed in this regard by the use of the term "standard of care." This is a legal term, and the Cleveland Clinic is basically saying that the generalists out in the boonies are beneath that standard and are therefore committing malpractice!

Secondly, there is note of the explosion of imaging, but no decrying the self-referral that is inherant in much of the "outpatient" studies that would be included in this designation.

Finally, the anonymous author of this piece is using the advent of my beloved PACS (technically teleradiology, but they have become essentially one in the same these days) to facilitate and even justify their desire to swoop in and snatch exams away from the lowly generalists.

I always advise my gentle readers to "follow the money," and here, this is not a difficult task. Our friend at Cleveland Clinic is telling you that the lowly generalists out in the boonies can't do an adequate job, but in years past, you had to settle for this because they were the only game in town. But wait, we now have PACS, and so we are finally able to help you poor downtrodden masses who have the bad fortune to live somewhere other than Cleveland. Just sign this reading contract, and pay us our fee, and we'll all live happily ever after.

This drivel should be beneath an institution with the stature the Cleveland Clinic. It is an abuse of PACS technology to generate revenue that really belongs elsewhere. AND, it encourages self-referral in a round-about way. I do hope everyone at the Cleveland Clinic will enjoy Hillary-Care which they are helping to bring about with their greedy approach to radiology and medicine.

Stupid Pet, I Mean PACS Tricks

Image credit: http://www.skateboardingbulldog.com

It's amazing that a little glitch can cause a big pain. What's even more amusing is the fact that this particular glitch is shared by Impax 6.x and GE Centricity 2.x.

Here's the scenario...I'm looking at a CT, cine'ing through the slices. I want to change window settings, say from a mediastinal window to a bone window. Shouldn't be a problem, especially if I have the window/level preset to a keyboard shortcut. BUT...sometimes, only the slice that is on the screen will have the parameters changed, with all other slices remaining at the original level. And just why does this happen only sometimes?

Our Agfa PACS-admin actually figured this one out, and it turns out to be the explanation for Centricity's bad behaviour as well. If you did nothing else to the scan other than change with W/L settings, there is no problem, and such changes apply to all slices. However, if you happened to stop and measure something, then all bets are off. In their infinite wisdom, the programmers decided that a measurement should only apply to the slice on the screen. That makes sense, I guess, but their solution was to switch the tool application mode (my term, but it works) from applying a change to all slices to applying it to just one. And, it doesn't return to the "all slice" mode when you go back to the window/level control. This makes me do it, which as a lazy slug, I resent, and I don't even realize that I have to make this change until I'm flipping through the images and see one slice at lung windows and the rest at a different setting altogether.

I have to throw in one more little trick from Impax. At the bottom of the viewer, if you right-click on an UNMARKED point (even my Agfa PACS-Admin didn't know about this tool), you get a little sub-menu with three selections. The first is a limited history, which will bring up a list of the last 20 studies that were marked as Dictated. (This, of course, doesn't help if you lost something that was marked "Dictation started".) The second entry on this secret menu allows one to auto hide the toolbars, which I have never seen anyone use. The final entry, "Show Navigation Toolbar at the top of the screen" does just that. Sadly, there is a significant lag in the activation of any of the items, and the grouping is unintuitive enough that when I go after the history, I accidentally hit the "Show Toolbar at top" as often as not. I don't want the toolbar up there, and worse yet, it often disrupts the position of the other buttons at the top of the viewer, requiring me to log off and back on again to fix it. Really fun trick, guys.

How did we get these stupid PACS tricks? I will guarantee you that the developers didn't demo or test these options in an actual production environment. I'm sure these functions made perfect sense on paper, but they yield yet another hinderance to my workflow, out here in the real world of private practice.

Would you guys at GE and Agfa mind fixing this stuff, please?

The Best Invention Ever

TWO $1000 Mikes Disabled By 3mm Piece of Plastic...A bit of bad design

Our suburban hospital just replaced their antiquated tank with the modern, computer-based Fusion dictation system from Dolbey. This is a digital voice system, but it does NOT include speech recognition, thank Heavens.

I got there today to read out the weekend carnage, and what do I find? The laser barcode scanner on the microphone isn't working right. This microphone is a nice little piece of equipment, a Philips SpeechMike classic with barcode reader, which retails for over $1000. I asked the director of the department if we had another one, and yes, we did, but that one had a malfunctioning barcode reader as well. I peeked inside the little red window, and activated the laser scanner...yes, really bad idea for someone who makes a living with his eyes! I could see the laser, but it appeared to be hitting above the top of the window, and not getting out to scan the barcode. There is a tiny adjustment knob at one side, and this was a little loose, and didn't seem to change anything inside.

The Fusion system depends on barcoding at the moment; when we get this site on PACS later this year, the demographics should download from PACS automatically. Still, that is several months away. So, I could either figure out what was wrong, key in the accession numbers manually (by using the tiny trackball on the mike to select numbers on the on-screen keypad), or I could just do one long dictation, reading off the accession numbers and hoping for the best.

Being a tinkerer at heart, and having total disregard for warranty voidance, I took screwdriver in hand and disassembled the offending mike. Inside the bottom, pictured below, you can see the red window to the left, and a mirror to the right.

The next image is a little blurry (sorry, my phone doesn't have good macro capability!) but it tells the whole story. The black box at the top of the microphone is the laser assembly. The black bar-like thing next to the red crayon is a black diffuser, which is used to direct the beam a bit so you can hold the mike more naturally. It is supposed to sit atop the laser. But the little tiny black C-shaped thing between the two is one of two tiny brackets that holds the diffuser in place and allows the little knob thing to ratchet it and hold it in place. The problem is, this tiny $.001 piece of plastic broke right off of its base (the roughly triangular thing to the left at the top of the laser housing), and rendered the whole assembly useless. Bad design. Really bad design.

Being too lazy to do anything else, I simply left the back off of the mike, and used the microswitch that is at my thumb as seen below to activate the laser. It is a little bright, and must be pointed perpendicular to the barcode, but it works. Of course, normally the microswitch would be keyed by a plastic trigger in the base. Notice the high-tech rubber band that keeps the cord from detaching. Nothing like the feel of bare circuit board in your hands...

So, problem solved temporarily. I do expect a replacement mike, with perhaps several in reserve, until Philips redesigns this really bad implementation. And, don't even think of telling me that opening the case voids the warranty.....

You Knew Dalai Was Strange...But this really takes the cake!

A few years ago, when my son was a Cub Scout, our troop held an annual "Dad and Scout" cake contest. The only rules were that moms were not allowed to help, and that all components must be edible (by normal people). My son and I decided to take a rather medical bent, although some would call it macabre. Thus was born the idea of the Scout Patient Cake. The cake itself is red-velvet, nicely simulating tissue. The brain and heart are composed of....marzipan! Yes, Dalai's brain is made of almond paste... The lips are of the classic wax variety, the eyeballs are strips of white "AirHeads" taffy rolled into balls and adorned with frosting. Large vessels are made of strawberry licorice, and coronaries are drawn in with liquid frosting. Now the hospital blue cover was by far the hardest part of this project. This was made from fondant, a thick frosting-like material that you usually see in cakes more like this one from Krista's Creations:

That darn stuff is very hard to work with, which is probably why the cake above goes for $300. I have a feeling ours would not command that price.

Back to the Cub Scouts... prizes were awarded in various categories. Our cake took second place overall. I think perhaps the judges were afraid to award us anything less.

You'll be glad to know that even though the cake went down the dispose-all years ago, I saved the brain and the heart in the freezer, where they remain to this day. You never know when you might need one, right?

A-Wristing Technology...but do they tell time??

Image credit: http://www.internationalhero.co.uk

We all remember the comic strip "Dick Tracy" wherein the razor-nosed detective wore on his wrist first a walkie-talkie, and in later years a video-phone. I don't know about you, but I really wanted one of these when I was a kid, and nothing much has changed.

Well, actually, something has changed...technology has caught up with fiction, and there are some expensive toys available that do approach this level of sophistication.

First, there is was a watch marketed as a "Dick Tracy" special, made by Fossil:

This little $200 gem uses the MSN Direct network, a subscription wireless service that sends accurate time to the watch, as well as sports scores, stock prices, news, etc. The downside here is that the service is expensive (~$10/month), and there is no uplink back to the Internet. I'm not sure if it's still available.

If you don't want to communicate, but do want the joys of watching videos and hearing MP3's on your watch, then this latest series of watches from China might be up your alley. (My son is considering squandering some of his allowance on one of these, and if he does, I'll let you know how he likes it.) Below is a photo from http://www.chinavision.com of this rather large contraption...it's almost a video iPod with a wrist strap:

These things are only $50-$100 or so, depending on how much memory you purchase with them (they are currently available with up to 4Gb of RAM!)

The Holy Grail of wrist machines is, of course, a real wrist cell-phone, and there is finally one for sale to the masses, although the masses would need to cough up $1000 Australian (about $850 US.) This feature-packed M500 comes from SMS Technology Australia, http://www.mymobilewatch.com:

Look at these specs:

Model M500 Quad Mode, Touchscreen, Java and WAP enabled

Weight: 60g

Color: Silver or Black with Leather Strap

Screen: TFT 1.5 - inch colour touchsreen 120 x 160

Frequency: GSM850/900/1800/1900Mhz (GPRS), SIM

SMS: Full SMS and MMS functionality

MP3: Support AAC/MP3

MP4: Support Video Playing

Touchscreen with Built-in Stylus

Memory: 128MB Built-in Memory

Battery: 400mAh, Talk Time 200 Minutes, Standby Time 80 Hours

USB: For Data Transfer and Recharging

Bluetooth 2.0

This thing should work on any GSM network, including AT&T. The only downside (besides the rather outrageous price) is that one must use a Bluetooth headset, but that isn't much of a limitation these days.

There is nothing like being on the bleeding edge, especially if you can afford it! And yes, if you were wondereing, all of these wrist-marvels do tell time....

PACS Pioneers...and my brush with greatness

Image credit: http://www.legendsofamerica.com

In researching another post, I ran across this article from Imaging Economics about the history of PACS. It is a very brief synopsis of the path to today's filmless world of Radiology. I won't try to summarize the summary, but suffice it to say that PACS (although they didn't call it that until fairly recently) had its start at several centers around the world, with the perseverance of a number of true visionaries. Probably the most important single milestone was the development of the DICOM standard which (at least in theory) allows scanners from Manufacturer A to communicate with viewers from Manufacturer B. Before DICOM, everyone had a proprietary code for everything, and the PACS pioneers actually had to reverse-engineer and decode tapes, which must have been just a load of fun.

My brief contact with the "Great Ones" of PACS occured in 1992, and it was the idea of a local businessman. This gentleman owned the storage facility in which we archived the zillions of films taken over the years. He had heard of the work Bernie Huang, PhD, was doing at UCSF, and decided to see it for himself. He was so impressed that he took a couple of us radiologists, and a hospital administrator out to see Dr. Huang.

In 1992, there was no such thing as the PACS we have today. Dr. Huang's operation consisted of what we might call today a couple of mini-PACS operations, without much standardization. There was a tape jukebox sitting in the middle of the lab, workstations here and there, digitizers, and whatnot everywhere. But Dr. Huang's vision was clear...this was the future, and film was not.

When we returned home from UCSF, our "patron" asked what we thought of the whole thing. I responded, "It's great, it's obviously where we are headed, but.... The hospital isn't going to buy, let alone be able to maintain, a system comprised of loose pieces of technology. Someone has to put it all in one box before it will become practical." I'm not sure if our friend agreed or not, but he never did approach us with any proposal.

A year later, we were in negotiations with Agfa for our first PACS, and we were on our way to becoming one of the first filmless departments in the country.

Empiric's Encompass.NET RIS......The Amicas of RIS's

You may recall from a very early post that I had originally planned no RIS for our Amicas PACS. We were going to use paper and PACSGear scanning software to simulate a RIS, if you will. However, we ultimately decided that this would be rather tedious, and would not allow us to do some of the things we have grown accustomed to doing, such as editing reports. So, we went in search of a RIS. We didn't need a big bad hospital system, but we did need something. Basically, there were two requirements: the RIS had to be very easy to use, and it had to be reasonably priced. We found the the ideal combination for our purposes in Empiric's Encompass.NET product. Functionally, it is straight-forward, and easy to use, and most importantly, it doesn't get in my way. That's why I call it the "Amicas of RIS's". Amicas probably doesn't like that title, because they have their own RIS. We looked at it, and it is a great product, but it was more powerful and more expensive than we really needed for our little operation.

Now, I don't want to leave you with the impression that Encompass is underpowered, because it isn't. It is streamlined, and its interface is rather spartan. (More on that in a moment.) It does, however, have everything we needed. From the Empiric web site:

Primary RIS Functions:
Patient registration and scheduling
Embedded digital dictation
Transcription
Electronic report signatures
Auto faxing (direct or by eFax.com)
Multi-site support
Audit trails
PDA capabilities
Management reporting
Mammography tracking
Document scanning
Inventory tracking
Paper-less consent forms
Radiologist peer review functions
Film library management
Additional staff and equipment management tools

PACS/Imaging Functions:
Web viewer w/auto study retrieval
Image routing & archive management
DICOM worklist
RIS-integrated workstation

Referring Physician Functions:
On-line study requests
On-line report access
On-line image access
Optional integrated EMR

Complete Billing Functions:
Claim generation
Payment posting
Collections management
Credit card co pay capture
On-line eligibility verification

Obviously, there is a lot to this system. We have it integrated nicely to our Amicas PACS, and the two play nicely together. Encompass does have its own viewer available, and it isn't bad, but we are much happier overall with the combination.

The best part of the RIS, as with Amicas PACS, is that it doesn't get in our way. It can provide reports viewable from within PACS, which the clinicians love (and so do we). We are really thrilled with the simplicity of reviewing and signing off of reports. We log in to the system (from anywhere, as this is a .NET web-accessed program), hit the "batch sign" button, and all of our pending reports are displayed. There is the option to edit them if necessary, which is a rare need given our incredible transcriptionists, and then they can all be signed with ONE CLICK! We use Cerner at our Agfa hospital, and Meditech at the other places we cover, and the concept of "ease of use" has obviously never been heard by their developers. But it is the backbone of Encompass.

Now, I mentioned the somewhat spartan nature of the Encompass.NET interface, and indeed, it isn't particularly fancy. But I do have the honor of announcing their next interface, with screenshot below, which will make its official debut at SIIM next month. Empiric hired a "prominent West Coast GUI design firm that specializes in ergonomics" to revamp the front end. Notice the "at a glance" concept that will instantly show the user the status of each patient and exam. It's prettier than the functional design they have today (screenshots of which can be seen at their website.)

If you are in the market for a RIS, and you aren't trying to outfit the entire Mayo Clinic, have a look at Encompass. My partners and I like it, and we're rather hard to please.....

Dalai Gets Trumped!

Unbeknownst to me, there has been a game of sorts going on among some of my partners called "Trump the Dalai", wherein they have to find some piece of technology I haven't already tried. My partner Rick (well, to be honest, it was actually his wife) won the game hands down this week. For his birthday, Rick received a brand new FlipStart super-compact PC. I'll let you read the stats on the FlipStart webpage, but suffice it to say, this is a fully functional Windows XP computer that is about the size of a largish paperback book. Most remarkable for a tiny machine like this is its large screen, a "5.6 inch diagonal high ­resolution display (which) makes computing easy on the eyes, with a full view of Windows® (1024 x 768)."

When Mark, my PACS guru, got hold of this thing, he went absolutely wild with glee, and proceeded to access our Amicas server, which turned out to be just as easy as on any other laptop. You can see the results above. Note the quarter on the screen placed for a size reference. With the size of the image displayed, you might think we were using a scanner like this one:

Rest assured, however, that these are real human images from a regular old MRI. (The little scanner, image courtesy of Craig Woody, BNL, actually is a minature PET detector used for animal research.)

The screen resolution of the FlipStart is adequate for reading digital modalities such as CT, MR, NM, US, etc. I don't think I would try to read CR, but it might be possible in a pinch. Especially for rat radiographs.

Rick's prize for winning Trump the Dalai? An extra night of call! Just kidding.....

New Trix From Impax 6

Image credit: http://www.generalmills.com

Silly Agfa, Trix are for Kids, not for PACS!

In the last few days, I noticed that my profile on Impax 6.2.1.135 had changed in subtle ways. Different worklists than those I had selected were displayed, there were different columns of information within those worklists. Some of my tools and display settings were not as I had left them.





I thought I was crazy, which is probably true anyway, but now, some of my partners are noticing the same thing! Our PACS people are looking into this, but I see only a few possibilities:

1. Someone is getting in there and messing up the settings


2. There is some problem with the communication between our three production servers, and settings are getting tweaked somehow in that process


3. The data tables are becomming corrupted...seems to me things would have deteriorated a lot more if that were the case


4. The damn thing is haunted

Personally, I'm voting for #4. I'll keep you informed.

Speech Recognition...Again

Courtesy of: http://www.engr.uconn.edu/ece/SeniorDesign/projects/ecesd79/

There are a few ways to get noticed on an AuntMinnie.com discussion. Mentioning GE Centricity always draws a lot of attention, but these days, a thread talking about speech recognition will be pounced upon like Howie Mandel after some poor "Deal or No Deal" contestant opens the case containing $0.01.

A recent AuntMinnie front page article reported the results of a study from the U.K. and Germany that discovered

. . . speech recognition technology eliminated "significant delays" in report transcription and typing issues, leading to an improvement in service to both clinicians and patients. Researchers at Hammersmith Hospital and Charing Cross Hospital also concluded that a well-planned organization-wide implementation of speech recognition technology "can have a dramatic impact on radiology service delivery. . ."

In 2004, emergency room and primary care reports took three to five days to complete at Hammersmith Hospital. Finished inpatient and outpatient reports ranged from a low of three days to as many as eight days for inpatient reports in August 2004. With the advent of speech recognition technology, the time from report generation to completion declined to one to two days from January 2005 to February 2006.

This article prompted a number of responses on an accompanying AM.com discussion. A few were positive about SR, but many were doubters, including yours truly. You may remember my earlier post about SR, and I haven't changed my mind. I haven't seen any evidence to suggest that SR has improved. Articles like the above don't do much to help SR's reputation. I mean really, three to five days! That is totally unacceptable under any circumstances. Did our British friends have only one transcriptionist available? Did she have to use the loo for 30 minutes of every hour of her 4 hour daily shift? If you set the bar that low in other venues, I could be the Steeler's next quarterback! I will have to admit that SR might be able to improve the situation if things are that bad.

Fortunately, here in my little corner of the boonies, things are pretty good. Our turnaround time with Human Transcription (HT) is usually from 10-20 minutes, with STAT's coming out within 5 minutes. Of course, if there is reason to do so, we type in a prelim, leave a voice-clip, or (gasp) even pick up the phone to call the clinician. Why would we ever want to switch to SR?

Look, I love technology more than anyone else I know, and I am absolutely fascinated by the concept of the computer listening to me and converting my uttered pearls of wisdom to text, or to commands, etc. Wonderful. But if this is such a wonderful idea, why hasn't it caught on elsewhere, such as among the administrative types that are pushing it on us rads? I think the ultimate reason is this: A machine will never understand the nuances (pun intended for the Powerscribe set) and the outright inherant inconsistancies of human speech. I can dictate this: "The left shoulder, I mean the right shoulder shows no fractures" or some equally flawed speech, and it will come out OK with HT, but not with the machine. Those for whom SR works well have not only trained the machine, but moreover, they have trained themselves to dictate in a completely different way than they learned as youngsters. I personally am not that big a fan of technology that forces me to adapt to it.

I have to wonder if some of the more ardent supporters of SR on the various AM threads work for Agfa or Nuance, or if they are just low-level administrator types taking some heat for spending $300K on something that doesn't work very well.

Has anyone really added up the cost of SR vs. HT (speech recognition vs. human transcription)? I suspect that once you pay the $300K for the initial set up, add in training time and costs, cost of upgrades, cost to replace the darn thing in 3-5 years, etc., there won't be much savings with SR. That does not, of course, take into account the radiologists' time, effort, pain, and potential malpractice suits caused by using SR. But then, the administrative types that usually make this decisions AREN'T PAYING FOR THE RADIOLOGISTS so they don't really care about that. But we rads DO care. If SR is so bloody wonderful, why don't administrators as well as the occupants of the C-suite use it? Apparently, it's good enough to generate reports upon which life-or-death decisions are made, but not good enough to replace the secretaries of any of the above. Think about it, folks....

Here Wii Go!...A new pointing device for PACS?

There has been much discussion of how to point at your CT on the workstation. Most of us still use the venerable old mouse, while some have graduated to trackballs, joysticks, jog-shuttle dials, and even roller-mice.

An Italian college student by the name of Giorgio has come up with something new, that I think has great promise. Some of you have probably succumbed to your kids' pleadings for a new Nintendo Wii, which isn't all that expensive at around $200. The Wii's claim to fame is its entirely different approach to game control: the Wii-mote, consisting of a wand or nunchuck, and a little joystick control on another little pod:

You control the various games by moving the nunchuck in a natural manner. For example, hold it like a golf-club or a tennis racket and swing appropriately. A tiny accelerometer inside the nunchuck translates the motion into control signals for the Wii. Note the included wrist-strap designed to keep the nunchuck in your hand after a vicious slice, thus avoiding injury to yourself, others, and your TV.

Giorgio has hacked the Wii-mote and via a control system called GlovePIE, he has made it operate a CT display. Based on his video, he hasn't yet tried it on 3D renderings, MPR, etc, but that would be the next logical step.

Now can I get a Wii, Mom?

OOPS....We had a little downtime today...

Fortunately, I'm on vacation this week, and I didn't have to deal with the joys brought about by downtime. According to Dalai's First Law of PACS, "PACS IS the Radiology Department," and so when PACS is down, the department is down, and the patients can just cool their jets (or their hemorrhages, or whatever) until it's back. The good news is that the rads can go on a prolonged coffee break if there isn't any way to get back up again.

I don't know all the details at this point, but I do know that our newly-upgraded Impax 6.2.1.135 went down from 8AM until 10AM today. Not the best time for that to happen, if there is a good time. We are assured by our vendor, however, that the same problem will not occur again (any time soon, I assume). I find the whole situation sort of confusing, because we have three parallel production servers, and I don't really understand what took them all down at once. Maybe the Oracle is at it again?

Since the upgrade was fresh, no one thought there would be any problem of this magnitude this soon (about 52 hours after completion), and so the backup plan wasn't fully on-line. Now, we do have a test server, which was used during the upgrade itself, but I guess the scanners weren't still pointing to it. We actually had to use the venerable old (gasp) Web 1000 to get anything read during the dark age of the downtime. Fortunately, the servers where good old Web 1000 live haven't been wiped as yet; I think they are going to be converted to Impax 6 servers eventually.

Well, we survived, and we are stronger for it. Can't wait for the next episode of "As the PACS Turns (Off)".

Impax 6.2.1.135

Never let it be said that whining doesn't get you somewhere. We complained, and Agfa listened (to a significant degree, anyway). As noted in the sign-on screen above, our Agfa site bumped up to version 6.2.1.135 (6.2 for short) from 6.0.x over the weekend. The upgrade went without a hitch. Well, that was my view, because I'm on vacation, and no one bothered me! I'm told there were some problems here and there, causing the install to be completed at about 4AM this morning, instead of the anticipated 8 or 9 PM last night. Something with Oracle, I hear. (IT folks are rather like doctors. If you come in with some weird disease, it somehow is always due to a virus. A problem with Impax somehow always relates to Oracle. Personally, I would prefer the Oracle from the movie "300" but she might not prove quite as operational as what we now have. I digress....) To add insult to injury, something happened to the power at the data center this morning, and shut the darn thing down again, but that was NOT the fault of Oracle, as near as anyone can tell. I find it interesting that someone on the team was checking my blog at 1AM this morning to see if I had said something bad about them yet. Who, me???

Not counting some patches and service upgrades, this is the first major revision we have had in the six months since go-live with Impax 6. I have a list of the 113 things that were changed, but I'll spare you the joys of reading that. Let's just concentrate on what directly affects me, the target audience (at least that's how the folks from Waterloo explained the requirement of affixing a big red bull's-eye on my back...)

The single greatest accomplishment as far as I'm concerned is the reintroduction of the "simple search" for "simple-minded radiologists." Instead of the incredibly powerful but incredibly obtuse "advanced search", the easy version lets me drill down quickly to what I need. The Agfa folks were absolutely flabbergasted that we end up searching by the patient's name about 90% of the time. Well, now I can do that without going through the gawd-awful drop down menu of 100 different criteria. Unless I really want to, that is, because the advanced search is still available. See? An easy solution! Here is how it looks today (compact and expanded versions..you'll have to click them to see everything):

The list of improvements goes on for 112 other items, give or take. I do think there are some duplicates on the list, for what that's worth. Some of the other highlights include:

• Available Series Tray is now embedded based on User configuration. It was previously stuck at the left side.
• Hotkeys should now "stick", and not be erased after logout.
• Various causes of crashes have been eliminated.
• Cursor mode line now upgrades in orthogonal views.
• Should be able to open larger number of studies without slowdown.
• There is now permission to configure one's own station (and take back some RAM!!)
• New/upgraded versions of the client will download automatically when the new version is recognized.
• Column changes in Worklists are immediately saved, and applied to ALL worklists (hopefully that's what we wanted..)
• The automatic brightening and dimming of the Prior list is shut off.

Now, here are some of my pet peeves that are not yet fixed:

• Handling of two rads trying to dictate the same study. There is a temporary fix with a warning message, but an insistent rad can still override the settings.
• No easy way to get back to the last study that was on the screen. Yes, there is a somewhat hidden "history" tool, but it only works on studies that have been clicked off as dictated.
• Spine labelling. There isn't any.
• Voxar button still stays active, leading to repeated activation of Voxar3D when you were just trying to get back to the original study.
• Comparison windows still based on the cloning concept.
• TOGGLING!
• Black screen when images of a series are loading.
• Thumbnails in the Series window can be easily, inadvertantly resized, to the point of being unusable.

I could go on. 6.2.1.x represents a significant improvement, at the very least many glitches have indeed been fixed. The underlying philosophy of the program remains what it was, however, and that is something the potential buyer should be very, very comfortable with before, well, potentially buying Impax 6.

Thirty-Five Thousand Hits!

Courtesy of http://membres.lycos.fr/xenu/rtcfun.html

Visitor 35K came to my site at 1:40PM EDT today, and stayed an impressive 18 minutes, 25 seconds. He or she must have fallen asleep at the keyboard! Anyway, he is from Bekond, Germany, and was searching for the phrase "Oracle buys Agfa". It seems takeover rumours are rampant these days. As near as I can tell, Oracle is not buying Agfa. Agfa isn't even for sale, is it?

Hospital Mentality

The above is an unretouched and unedited video shot in the departmental restroom at one of our hospitals. You will note the obvious dilemma. Ah, hospital mentality...

GE Buys Agfa PACS!!!....Centri-PAX to debut soon

Just when I think there are no more surprises left in this game, something comes at me from left field.

I have it on good authority that GE and Agfa have had high level talks over the past six months, and they have agreed to merge their PACS products. The new flagship offering, Centri-PAX (Centricity is GE's system, IMPAX comes from the Agfa side) should offer the best of both worlds, without carryover of the deficiencies of each. The new hybrid will be web-based, and run on Microsoft's .NET platform. It will eliminate the need for the separate Centricity-Web now required for web access on the GE side. Centricity users will note similar DLP's (hanging protocols). 3D options will include the GE Advance Workstation (AW) platform, long promised to be ported to Centricity, or the Voxar/Barco 3D program. TeraRecon or Vital Images' Vitrea may also be purchased.

Spokespeople for both companies note the unprecedented nature of this cooperation between giants in the PACS field. "This is like Ford and GM working together on a next-generation vehicle," says Robert Pryor, President of Agfa Health Care. GE's David Henriksen, head of GE's PACS and IT division agrees: "For the first time in the history of PACS, the two biggest names in the business will cooperate to provide the best program available."

Competing companies had no comment, except to urge you to note the date of this posting. Have a happy one.