Wednesday, October 20, 2010

Paranoid IT-diocy

One of my many friends in the PACS arena, working in an academic setting, sent me this message the other day:

This morning, I was working with an orthopedic surgeon at the big ortho clinic.  He was using his personal digital camera to take a picture of films that were up on a light box.  He said it was the only way he could get images to put in a presentation. How sad is that?

The new PACS system does have the functionality to do it but IT workstations are so locked down, no one can put in a thumb drive, or even save to a shared drive on the network. They will someday be installing a product that will enable them to import/export images, but have not seen fit to deploy it yet.
Now, if that isn't foolish enough, try this one, coming to one of my hospitals.  It seems that remote verification is problematic, and so something like this is to be employed:
RSA® Adaptive Authentication is a comprehensive authentication platform providing costeffective protection for an entire user base. Adaptive Authentication is powered by Risk-Based Authentication, a risk assessment and authentication technology that operates transparently and classifies all users by measuring a series of risk indicators. This transparent authentication for the majority of users provides for a convenient online experience as users are only challenged when suspicious activities are identified and/or an organizational policy i violated. The strong authentication functionality of RSA Adaptive Authentication is offered to Citrix XenApp® environments through the RSA Adaptive Authentication Adapter, which enables integration of RSA’s risk-based authentication technology with Citrix XenApp’s user name and password verification system.
Here it is graphically:

It seems that our hospital is going to implement a system whereby we are to be telephoned for a confirmation (requiring us to answer and press the # key) before we can sign on to the system from a location outside the hospital.  I kid you not.
What we see in these two situations is a trend of what I can only call paranoia, and maybe even tyranny.  IT is so consumed in its own importance and the obsession with even the remotest possibility of a breach or infection, that they will implement such foolish and draconian measures as I have outline above. 
Clearly, they don't get it.  Perhaps a reading of Dalai's Laws by IT would be in order.  Several times per hour for the next month.
Attention IT!!!!  These computers and networks exist for PATIENT CARE, and they are not your own personal virtual castles.  You may not hole yourselves up in your little electronic fortresses and force the rest of us to play these little games to feed your paranoia.  This crap has to stop. 
Yes, I understand the importance of maintaining security, and I'm certainly willing to work with IT on reasonable measures to keep the network safe.  But IT had better start understanding that we have to use their damnable equipment for PATIENT CARE, which trumps everything else.  And I do mean EVERYTHING else.  Work with us, and we'll work with you.  But being an obstructionist in a patient-care enviromnent only hurts the patients.  Is that what you really want?  I hope not.
Don't call me, I'll call you.  And your bloody computer system better not call me, either. 

Monday, October 18, 2010

Zünder Down Under

I had hoped to return from Perth able to report considerable progress in the repair of the Western Australia PACS system. Unfortunately, those I spoke with tell me there is perhaps some very minor improvement, with crashes and prolonged downtimes still the norm.  One radiologist I spoke with said he had basically just given up and accepted this as the way things will be.

I still find this situation rather horrific, and even more so given the relative lack of progress over the five months since I first brought it to your attention.  What's going on here?

Clearly, something is very, very wrong with this large installation.   Normally, the vendor would be held accountable for a glitch of this magnitude.  Thus, I'm asking Agfa to comment, and any responses will be published here verbatim.  Please tell us what has happened in WA.  Let us know why this installation cannot be brought into complete functionality.  Is it a hardware problem?  Have key pieces been replaced?  Is it a software problem with Version 6.4?  (We have 6.3.x, which has had a much better run.)  Is it something with the local infrastructure?  Network?  Some problem with the Aussie version of English?

I'm convinced this problem can be fixed, but apparently not until adequate resources are thrown at it, which hasn't yet occurred.

Please let us know.  Your customers, present and future, are quite interested.

Sunday, October 17, 2010


From the Wikipedia:

In geography, the antipodes (from Greek ἀντίποδες,[1] from anti- "opposed" and pous "foot"; pronounced /ænˈtɪpədiːz/) of any place on Earth is the point on the Earth's surface which is diametrically opposite to it. Two points that are antipodal (/ænˈtɪpədəl/) to one another are connected by a straight line running through the centre of the Earth.

WolframAlpha calculates that the antipode for Columbia, SC, lies at coordinates 34° 1' 2"S, 98° 59' 21"E:

This is a few hundred miles west of Perth, Australia, which I left early this morning (yesterday, local time) and I'm now on my final flight home.  Thus, I have just returned today from being as far away as I can get and remain on this planet.  What a concept.  Of course, my bag is still in Sydney.

In the world of PACS, I think there are some antipodes as well, practices and ideas that are as far removed from each other as it gets.

There are companies that listen to their users, companies that don't, and companies that are beginning to learn that this might be something important to do.

There are companies that buy new technology with at least the intention of implementing it, and those that buy things and suppress them to prop up the market for sales and service of the existing dinosaur.

There are organizations that buy products their end-users want and need, and those that buy to keep IT or Administration happy, or to appease someone who would be embarrassed to shift to another line after a long stint with a favorite vendor.

There are companies that do whatever it takes to keep their customers online at all costs, and those that don't.

There are systems that are a joy to use and don't get in the reader's way, and those for which the best part of the experience is logging off.

And so forth.

We're landing now, so my WiFi is about to be cut off.  Let me just say that my talk in Perth was very warmly received and I hope I've made some new friends (and no new enemies!)  More to come.

Friday, October 15, 2010

Dalai's Laws of PACS, Revised...The RANZCR Address

Note:  Video of the presentation from Perth is now available online at:


When I spoke on behalf of healthinc in Brisbane a year ago, I never thought I would be asked to return for a repeat performance. But here I am and I'm really thrilled to speak with you today, even though I've been looking over my shoulder since I arrived in Australia. And by the way, thanks for having me over when your dollar reached parity with ours! Anyway, I hope you will consider these few moments time well spent, an amusing break from your real educational activities. And remember, if you don't take any notes, you'll have plausible deniability of ever having heard me!

You may have seen my blog, If so, you might ask how this average private-practice radiologist from Columbia, South Carolina, a small city in the Deep South of the United States, become the Dalai Lama of PACS? Here's the story in brief: In 1992, when I was just a few years out of residency, one of my senior partners introduced me to this thing called PACS, (although we really didn’t use the term so much back then.) We slowly implemented a piece here, and a piece there, and by the mid 1990's our main hospital was one of the first to be totally (almost) filmless, and ultimately paperless. My partner aimed for the idea of “Sit here, read there”. Among us, anyway, he was a visionary, although he always had some problems getting his home computer to work properly. Sadly, he’s since gone on to a better place (no, he's not dead, he's in Florida!), but I’ve been able to oversee the implementation of his idea. My group now covers five hospitals, two outpatient centers, and numerous doctors’ offices, all interconnected either with the hospitals' PACS or a system we own. Just about every examination can be accessed from anywhere, the dream fulfilled. Or is it a nightmare? That depends on the day.

I won’t exaggerate my role in this achieving this dream, but as a former Electrical Engineer, it did seem natural that I would get involved in the process. In large part, I’ve had to be the spokesman, and occasionally the champion for my group of radiologists, since many of my colleagues had little idea of how this PACS thing worked, or even how it should work, and by and large didn't care much as long as it did work. I began to post on, initially asking what to do about a system that failed constantly (but that my senior partner loved.) To hide from him, and from the little company involved (ScImage), I adopted a nickname I thought no one would connect to me. Totally out of the blue, I came up with “Dalai Lama”. It didn’t fool anyone, but an Internet presence was born. My immodest assumption that some of my AuntMinnie posts were worthy of a wider audience led to the creation of Dalai's PACS blog, and the rest is history. Obviously, the blog postings, as well as my thoughts today, are my own personal experiences, opinions and observations and I just want everyone to take them for what they are worth. No divine knowledge or inspiration is implied. Certainly no offense is intended toward His Holiness, the XIVth Dalai Lama.

In fact, His Holiness is speaking at Emory University next week if you should happen to be in Atlanta.

The sense that medical imaging products were not all they could be, and the willingness to make honest statements online about my observations, has made me what I am today, the premier radiologist PACS blogger. Actually, I’m still the ONLY radiologist PACS blogger, but that provides job security, I guess. In a sense, I have appointed myself the spokesman for radiologists concerning PACS functionality as a whole. That rather lofty opinion of my role comes more from the vendors than from my inflated ego. As one of the loudest and least-civilized voices on such things, I seem to have reached the threshold of attention of at least some of the PACS vendors. Indeed, I have it on good authority that one of the main targets of my bilious postings thinks I've been "unfair" to the industry, meaning that particular company. I'll let you be the judge of that as we progress.

Whether in the Deep South of the US, or the Southern Hemisphere, we radiologists are all experiencing many of the same problems with PACS and the associated infrastructure, and dare I say it, the politics surrounding both. I’m one of a very few speaking publicly about these observations, probably because the audience is pretty small, we perceive no one cares, most of us aren’t crass enough to lay things out as blatantly as I do, and many are hesitant to take on the vendors, and others who don't get it. But after a day slogging against a malfunctioning system, I think most of us do care, and want some changes.

When I left residency in 1990, film was ubiquitous, and there was no such thing as PACS out in the field, at least not in a place like ours. My group had purchased a teleradiology system the year before I joined, however, consisting of video capture of the digital modalities, and a video camera on a stick suspended over a view-box for transmission of plain radiographs.

This conncected via analog telephone line to the Image Data Corporation Multiview Photophone, which we affectionately called the "humpback". Now those were the days. A 9 inch grayscale screen with a Touch-Tone numerical keypad serving as the only control. Things have of course become somewhat more complicated since then.

What has happened to the PACS market over the years is a story of Biblical intricacy, substituting corporate mergers and acquisitions for the "begats." This very Photophone device is a good example. You see, Image Data Corporation was purchased by eMed, which was bought by ACCESS, which then changed its name back to eMed, which in turn was purchased by Merge. In the meantime, AMICAS, my favorite PACS, was purchased by Vital Works, which changed its name back to AMICAS, then purchaed Emageon, and just this year, the whole package was purchased by none other than Merge. Thus, at least my PACS world has come full-circle within 20 years and Merge triumphs. Literally hundreds of PACS vendors have come and gone since I first started dabbling in this venue. There are well over 100 companies out there today in PACS, although how many are truly viable is up for debate.

Of the dozens, and even hundreds of PACS products, there is one positive comment to be made about each and every one: they all do show the images. Sort of. Some don’t do much more than that, and may in fact make it quite difficult to see the images, which is the whole point of their existence! A very few are obviously written with the radiologist in mind, with input from a number of rads. Others are clearly authored by computer geeks who had little idea how to spell PACS, let alone how to handle X-rays and CTs and their associated workflow. The common thread with most of these is the utter lack of understanding of what we do and how we do it. Approaches range from the ridiculous to the sublime.

One interface was even made to look like a spaceship control panel (I'm not exaggerating).

Fortunately, I was prepared for that one.

If you can't beat them, you might find yourself assimilated into the collective...

One small company even sold us one of the earliest implementations of an online real-time MPR viewer, wrapped in one of the worst GUI's I have ever seen.

Getting the images into the thing was an exercise in agony. It just didn't occur to this vendor that there was more to the software than the core viewer.

Another larger and more familiar vendor still insists upon pursuing the concept of toggling tools on and off with no obvious rhyme or reason. This company, among others thinks that the more buttons there are, the better the deal. (Which is something that some of their IT-based customers also believe.) Clearly, no practicing radiologist actually touched these programs before their release.

In addition to the joys of the disparate, sometimes poorly written software, I’ve had to deal with our IT departments and their lack of understanding of our workflow, our needs, or often anything at all about what we do.

Sometimes it really does seem like a horror movie.

Overall, it has always seemed to me that in a life and death business like ours, things could be done better.

Over the years, certain trends and patterns in PACS and our relations with PACS vendors as well as Information Technology became clear. I’ve distilled these into the LAWS of PACS. I have revised this list over the years, as the landscape keeps changing. Here they are, without further ado. . . try to picture me as Moses coming down off Mount Sinai:

I. PACS IS the radiology department.

This one is as obvious as it gets, but many still can't grasp the concept. Once PACS is in place, film is essentially gone forever, and in a very real sense, the mass of wires and computers is the entire department. Yes, there are still modalities, CR cassettes, barium, and so on, but for all intents and purposes, PACS is the department's face to the world. It should go without saying that the system actually has to work. Every single time it's used. You see, patients' very lives depend on this technology. Let me repeat that. PATIENTS' LIVES DEPEND ON PACS. IT HAS TO WORK.

I believe there has been some local experience with PACS malfunctions, and not long ago, I personally endured a 3.5 hour outage of a central PACS system that covered three hospitals, including a Level I Trauma Center. You can very well imagine the impact this had on our hospital and on our patients.

II. PACS exists to improve patient care. Its users are the radiologists and radiologic technologists. The entire goal of the PACS team is to optimize PACS function for its users.

This should be a no-brainer. In theory at least, everything and everyone in a hospital or clinic exists to improve patient care, from the guy who mops the floor to the neurosurgeon, to the Chief Executive Officer (yes, the CEO thinks he is above the surgeons, and we'll let him hold onto his fantasy). In essence, we all work for the patients, not the CIO, not the CEO (and certainly not the vendors).

I admit to some degree of bias, but I have to believe that PACS exists for us, the radiologists, to use for patient care. Quite often, though, IT doesn't accept this very important reality. The IT version of this law might read, "We provide PACS because it is made up of computers, which we own throughout the enterprise. We know far better than you do how our computers work, and what software will be easiest for us to maintain. We would be much happier if you would refrain from actually touching the mouse or the keyboard." Fine, let them push the barium too!

III. PACS should be the shared responsibility of the radiology and IT departments.

Notice the word "should." PACS is one of those little projects that requires the help and expertise of a lot of folks. As in Dalai's Second Law, PACS is indeed at its core a collection of computers and wires, an IT project if there ever was one, right? But as per Dalai's First Law, PACS is the radiology department, governing everything from its workflow to its profit margin -- things understood best by radiology, and it is a critical component of PATIENT CARE!

Therefore, I make the bold statement that management of this very important system should be shared between IT and Radiology. It only makes sense to let the various departmental expertise apply to where it can do the most good, again for Patient Care.

Sadly, PACS, being a rather high priced item, sometimes becomes a hostage, yanked back and forth to the department that wields the greatest power. Thus, territorial squabbling comes into play. Sometimes, the participants, whether from IT, or the government, or a vendor (this wouldn't happen to Radiology) tend to lose their orientation, which should of course be directed toward...THE PATIENT!

IV. PACS should not get in your way.

A corollary of Dalai's Second Law: PACS exists to let me, the radiologist, look at my patients' images. Anything that gets between me and that image is a distraction, and gets in my way. Obviously, some of this will be necessary, but if I have to click excessively, or take 39 trips to the menu bar before I'm done with the exam, something is wrong. Let me illustrate with an automotive analogy:

The newer BMW’s have something called iDrive, which is a big mouse that controls 700 functions. Most people end up accessing about 20 of these. Disgust with the vast excess is called “feature fatigue." The multiplicity of stuff available distracts one from the road, creating a potential hazard. Lexus vehicles on the other hand have simple, intuitive controls that make you feel more a part of the road. (Sadly, Lexus now has a new model with its own version of iDrive. Apparently my influence is limited.)

V. Workflow is inversely proportional to the number of buttons on the PACS desktop.

This is a corollary of the Fourth Law. I cannot, for love, money, or excessive ranting on my blog, get some of the big PACS companies to understand this. I was told by the head of a major PACS project from a major PACS company that its solution to providing a feature when you ask for A and I ask for B is to add a button that does both A and B. Here is what happens when the buttons are allowed to multiply like rabbits:

Many modern systems have in this way become hyperconfigurable and suffer from something I call the Lego-PACS syndrome -- that is, one can organize the buttons on the interface in so many ways that the permutations would take a century to exhaust. I assume the building toy Lego is as popular here as it is back home, and it was indeed my favorite growing up. But the sad fact is, I don't want to be spending my time searching through a sea of buttons and menu items; I want to read my studies. There is a minimum feature set necessary to accomplish this simple goal, and beyond that, every extra function has the potential to slow me down. That’s not to say that I don’t like advanced functionality. I do love power! But there are ways to simplify and organize these controls so they are unobtrusive, but available.

VI. PACS is not film.

In the early days of PACS, displays were designed to mimic a film view box. This seems rather foolish to us today. The versatility of a soft-copy display is so much greater than that of a piece of film it just isn't funny. Can you window and level a piece of film? Can you cine through images on a filmed CT? Well, I suppose you could stack them up like a deck of playing cards and riffle through them, but come on! Take away film and your workflow improves 10-fold.

VII. The degree of understanding of Radiologist workflow is inversely proportional to the size of the PACS company.

While not a hard and fast rule, it does seem that smaller companies can be more innovative and responsive, at least to a point. With some of the huge monolithic companies, having things "my way" is simply not in the cards. The products of the larger companies seem to reflect the mentality of largess, and even "bloatware". With this comes the anathema of the Lego PACS and obstructive designs I have bemoaned above. Sometimes, a large company (in this case large is spelled l-a-r-Capital G-Capital E) tries to emulate the flexibility of a smaller company by simply purchasing said smaller companies. Perhaps they are trying in this manner to become all things to all rads, or maybe they are just trying to find something that actually works. So far, their latest assimilation into the collective hasn’t worked very well.

VIII. Vendors work for us, not the other way around.

I suppose it's easier for the manufacturers to attempt to adapt the user to the program rather than vice versa, and our first mistake is allowing this to happen. I was shown a demo recently of the latest version of our PACS, one which I haven't been terribly pleased with to this point. After five years of whining (on my part), they had finally added on a simple function of spine labelling. The new toy was well-executed, but far more complex than what we had requested. Something simple could have made it out the door as a service release. Some other features that we had despised stayed on. When I protested, I was told, "But that's what makes us different!" I refrained from responding, "that's what makes you inferior!"

IX. A true PACS guru is worth his/her weight in gold.

There is absolutely no way in the known universe to successfully implement PACS without a guru. What is a guru? Someone who knows the PACS in and out, knows the radiologists and technologists better than his or her own family, and can make the system work for the end users, as per Dalai's Second Law.

The vendors are usually present for the initial installation, although we all know they may not follow through quite as well as we might like. Ultimately, there must be someone there on the ground to keep everything running smoothly.

X. All software errors, including those within PACS code, can be repaired if the vendor is sufficiently motivated to do so.

I've had some of the larger PACS companies tell me they just can't fix some bug, even one that crashes a system. What they really mean is, they won't fix the problem, or at least they feel the resources required would be more profitably deployed somewhere else, say on the next version of vaporware. As Windows users, we are all participating in the world's largest and longest beta test. At least Microsoft eventually fixes most of the things we discover. Why should we expect any less from our PACS vendors?

XI. If IT doesn’t like something, it will be termed a security risk.

I recently found a way to thwart IT, or so I thought, by using a macro program to automatically refresh a RIS window that would otherwise close every 30 minutes. Signing in to a Citrix window gets boring after the tenth time that day, you know. The macro worked, but IT removed it from all computers, saying that someone could create a macro that would bypass password entry. Sure they could. They could also use a wax pencil to inscribe their password on the monitor, as many of my colleagues have over the years. I’m not certain if we should ascribe IT's behavior to paranoia, concern, laziness or simple meanness. Probably all four. IT actually did decide to let me use my macro in the end, after I made my case to the head of IT security. In the meantime, however, they've taken away the right-click from our computers because I was nasty enough to use it to change the vendor's logo background on the desktop. All I did was shuffle the letters A, G, F, and A around a little bit...

XII. The PACS needs to be operable by the least technically-savvy radiologist on staff.

This is inspired by one of my partners, one of the best interventional radiologists I have ever met. Ironically, he has great difficulties handling anything run by computer. I often tell the story about the time he called me from an airplane about to take off to ask how to turn up the volume on his laptop so his children could watch a DVD. While the PACS has to work for me, it has to work for my less-computer-savvy partner as well, or it might as well not work at all.

XIII. Drive before you buy.

It is impossible to get the feel for a PACS graphical user interface (GUI) in a 10-minute demonstration, no matter how well it is presented. In fact, the better the presentation, the more chance that you are being deceived.

Ask, nay, demand, direct access to the program under consideration, something you can pound on without the salesman in attendance. The joys and pitfalls of various systems do not become apparent until you have actually tried to use them in a production environment. You wouldn't buy a Mercedes after watching the salesman drive it around the lot, and PACS tends to be significantly more expensive than a car. Keep in mind as well that the system that works wel for your mate down the road might not fit your particular workflow.

And as Moses (or was it Pharoh?) said, "So let it be written, so let it be done!"

These lessons have been painfully learned. Ultimately, my experiences and observations have been punctuated by fights, I mean discussions, with our IT folks, administrators, and of course, our vendors. On many issues, I have had to use my blog to garner attention to significant problems with PACS systems, when there was no other way to get anyone to listen. In fact, that is probably why a vendor we all know well labels my blog "unfair". This is such a relatively small niche market that problems might well go unnoticed and thus sales not be affected, were it not for a loudmouth such as myself. Since I'm the only Radiologist blogging about PACS, my "unfair" observations do seem to reach their intended audience. Have I impacted a sale or two? That's not my intention, but were problems dealt with properly, I would have no influence at all. If complaints were addressed, and patient care not impacted, I wouldn't be making any "unfair" observations whatsoever. Sadly, whistle-blowers are generally not appreciated, especially by those who were tattled upon.

I've taken a number of approaches in reporting the joys of our various systems on my blog, from direct opinion-pieces to little cartoons (I'm the one with the stethescope and the nice tan):

I’ve even parodied some famous songs. My favorite example of the latter is my Belgian Rhapsody, which begins (and I'll do you all the favor of reading it and not singing it):

Is PACS online today-

Is that just fantasy?

Still caught in downtime

With no functionality-

Open your files

Look up from the dials and see

I’m just a poor rad, trying to get through the day

‘Cause PACS is easy come easy go

Why it glitches, I don’t know

Any way the circuits blow doesn’t really matter to me

To me…..


Mama, just read a scan

Had a CT of the head

Clicked it off, now PACS is dead

Mama, it had just come up

But now I’ve gone and crashed it all again

Mama, Oooo, ooo ee ooo

Didn’t mean to make it die

If it’s not online again this time tomorrow

Back to film, Back to film, as if PACS doesn’t matter..

Apologies to Freddie Mercury, wherever he is…

 Dalai's Laws cover the importance of PACS and how it should work. We in this room understand that criticality quite well, but our IT and other politically-minded colleagues often do not. Once the infrastructure is in place to view our patients' images with electronic, soft-copy reading, there is no turning back. If PACS doesn't work, the hospital might as well shut down. I believe you call this situation a "Code Yellow," an internal emergency disaster.

My main trauma hospital, and its two sister hospitals which are all connected via the same PACS, (one you know well) recently endured a complete PACS shutdown lasting 3.5 hours. To this day, no one knows what happened, or at least they aren't telling me. We were dead in the water with NO PACS functionality. All we could do was to look at a few of the studies on the modality consoles. It seems our downtime plan involved printing film, but wouldn't you know it, someone disposed of the printers! IT's response?

Firstly, I would like to apologize for the unexpected downtime that occurred this past weekend. Impax is a very important system in our enterprise, and it definitely prohibits optimal workflow and efficiency when any high priority system goes down.

I have met with the parties involved in responding to the downtime, and the procedure for reporting issues to AGFA was followed appropriately. That being said, the field engineer who responded from AGFA should have escalated the outage to a senior product specialist who is intimately knowledgeable of our system, and he did not. This has been brought up to the service manager for follow-up and resolution.

As far as a failover system, Impax is configured to run in its test environment (on a test server). Since this affects how the modalities send the studies, the time frame for decision-making to initiate this process is 4 hours. This allows the vendor to respond, make assessments, and hopefully resolve any problems. During this time, studies do have to be viewed at the modalities.

I appreciate your feedback and your dedication to (our hospital) Radiology.

Excuse me? FOUR HOURS is acceptable? Not to me, it isn't.

Clearly, those upon whom we all depend for support may not understand the situation. Of course, this is the very same PACS team that when called upon to fix a malfunctioning PACS computer during a tumor conference declared, "Sorry, I'm still in bed. I'll be there in an hour and a half." This truly happened to us a few months ago.

Those vendors who land in my crosshairs got there by a similar combination of deafness, ignorance, arrogance, and hubris, and a significant amount of bad luck. Again and again and again, we are delivered products that the engineers (keep in mind, I am an engineer by training) think we should like, but never asked us if we actually do. Waiting five years for something simple like spine labeling because the vendor didn't want to listen to me when I told them to make it simple is ridiculous. Hearing that some poorly-conceived core functionality will be kept as it is because "that's what makes us special" is enough to drive me to drink. More than I already do, that is.

With bad designs, bad installations, and bad service, the vendors have great potential to wreak havoc upon us, and some do this quite well. Honestly, I don't think the vendors deliberately set out to create problems, but somehow they manage to do so anyway. A fellow in Canada responded to one of my rants against a certain PACS as follows:

Frankly, I have given up on reporting bugs. After one week Level 1 Support says you are doing something wrong...after 1 month Level 2 Support says they will look into it, and have never seen this problem before...after several months Level 3 support says 'Oh yes, that is a known issue, but it has not been given priority'. Is this the reputation any vendor would really want?

No, it's not. And if I were a vendor, I would really hate to bear the liability of a malfunctioning PACS.

What is the answer? Simply put, we need better communication, and that is a two-way street. Somehow, there needs to be dialogue between the end-users of these things and the folks that create them. I've attempted to open the discussion with my blog, but that's just the first step, and a fairly feeble and occasionally misunderstood one at that. But there is one other factor to consider. As long as we keep buying the suboptimal products they are selling, there won't be much incentive for improvement. The disconnect is inherent in the mechanism of that very purchase. We, the end-users, very rarely get much of a say in the selection of the PACS. Rather, it may be driven by some political motives, sometimes even by IT's desire to select a vendor that will do a bit of their work for them. We have an old saying in the States: "No one ever got fired by choosing GE." Clearly, those people don't work for me!

We have to make known our needs, and the manufacturers, the software writers, the vendors, IT, and all levels of governance over us need to listen. And of course we need to hear and understand their restrictions and limitations as well. But if we say nothing, if we are content with suboptimal products, suboptimal service, and indifferent, condescending oversight, well then, we deserve what we get. But our patients deserve better than that, don’t they?

In the end, that's what Dalai's Laws are all about. PACS is a tool for improving patient care, and patients' lives depend on it.

It is very encouraging to realize that all of us in this field face and surmount similar challenges. We must keep fighting the good fight on behalf of our patients, in spite of what some larGE companies might, well, imagine.

My second trip to Australia confirms what I learned on the first: Your country is absolutely beautiful, and your people incredibly friendly. Perhaps you'll make me an honorary Australian after all this, assuming I'm allowed to leave the country, that is.

In closing, I would like to once again thank the convenors of RANZCR for granting me the opportunity of speaking to you this morning. Now, back to the more educational part of the meeting. Thank you for your attention.

Perth PACS Poll

Did you know that Perth is considered the most remote major city in the world?  It is antipodal relative to my home in South Carolina, and it is exactly 12 hours ahead.  Thus, I'm more or less as far from home as I can get and remain on Earth.  But you wouldn't know it by walking around.  Perth is a really nice place, very cosmopolitan. 

After doing a bit of shopping in a wonderful European-style promanade, I've been wandering the exhibit floor at RANZCR. The iPad is the temptation of choice around here, with many vendors offering one up as a prize if you are so kind as to fill out the contact information.  Not a problem, although I doubt I'll be contacted, being rather far from the local market.  I'll let you know if I actually win an iPad.

One such drawing is run by Contrast Imaging Solutions, and I stopped to have a very interesting chat with the guys there.  It seems they have GE to thank for their existence:  someone here using iPACS was abandonded when GE bought the company (RealTimeImage) and assimilated the product.  The CI folks got together and built a new RIS/PACS from scratch.  I gave it a very cursory look and it does seem to have promise.  There are no plans, though, to export it to the 'States as its billing module is geared toward the Australian payers. 

As part of their iPad drawing entry, I had to write down the RIS and PACS I'm using, and its best and worst features.  For my Empiric RIS and AMICAS PACS, I gave credit for usability.  For the downside, I noted the fact that Fuji now owns Empiric.  (I'm hoping that Merge's ownership of AMICAS turns out to be a positive.) 

CI's unofficial talley of the poll so far notes mostly negative sentiments.  There was apparently a pleurality of responses like, "the best part of our system is logging off," and "too many crashes."  I'm not sure there were even any positive answers beyond mine.

Vendors, listen to your customers.  No, not the IT folks, or whatever.  Listen to the radiologists who actually use your stuff.  They don't like a lot of what you are doing.  It's not too much for us to ask for a system that works, and works well, especially at the prices these things command. 

There are companies that understand that.  From my brief chat, Contrast Imaging is one of them.  And I'm sure there are many more.  Wouldn't you rather be known as a vendor that "GETS IT" than otherwise?  Seriously?

Wednesday, October 13, 2010

Reefer Gladness

I'm here in Melbourne, waiting on my friend to finish up business so we can go to dinner.  My enjoyment of Melbourne has been a bit dampened by a cold rain, but I did get to see much of the downtown in spite of the inclement weather.  This is a rather pleasant place, a large city with a nice gentle demeanor (I was accosted by only one homeless person) which reminds me a lot of a smaller version of Boston, or maybe even Chicago.

I did have a bit of a fright when I stumbled across this building:

I had an excellent visit to Port Douglas and the Great Barrier Reef on Monday.  I had, as you know, arrived in Brisbane on Sunday minus my luggage.  Delta relayed the message to Qantas that the bag would show up late on Monday, while I was to be out on a boat cavorting with the fish.  Qantas sent me on to Cairns with $100AU and a little toiletry kit, and their sincerest apologies.  Naturally, the bag arrived that day anyway, but not until I had spent the money on replacements I didn't need.  Oh well.  Attached to the bag was a tag again apologising for its "mishandling."  Delta needs to take lessons from Qantas on customer service.   

The Thala Beach Lodge (lobby pictured below) is about a thirty minute shuttle ride from Port Douglas, the stepping-off point for most of the Reef trips. 

It's probably not a place for kids, as there isn't a lot to do on the property besides eat, drink, and walk the beach.  Still it was very pleasant and relaxing, a perfect spot for those headed to the reef, but who want a smaller, quieter, and more private property.

There are dozens of boats that ply the waters of the Reef National Park.  I chose the Wavelength based mainly on recommendations, and I'm glad I did.  The Wavelength is a small 30 passenger ship which is geared entirely toward snorkeling; no SCUBA, and no glass bottom.  It was perfect.

The ride out to the Outer Reef is very rough, so much so that the crew fed us motion-sickness pills (some local variant of Dramamine, I think) which worked well.

Here I am with Rich, another guest.  And here I am in the awfully warm Neoprene wetsuit, which does make the cool water a bit more tolerable: 

I'm sure there are lots of folks who would appreciate the shot of Dalai face-down in the water more without the snorkel. 

I can't begin to tell you about all the fish we saw, mainly because I can't remember the names of most of them.  We did not see any clownfish; sadly, they have been severely poached after the cartoon Finding Nemo made them popular.  Did you know they can change sex from female to male?  Nemo's mom apparently didn't know that either. 

We did see lots of other fish, though, and more coral than I thought possible in one place.  I've snorkeled all over, and I've never seen a reef that just goes on and on and on...  These are some photos taken by the marine-biologist on our particular trip.

Our marine-biologist was very knowledgable, and quite personable.  He tried really, really hard not to preach about globalwarmingclimatechange, but he let a little slip out.  Suffice it to say he believes the reef's growth has slowed, and this is attributed to higher surface temperatures and a higher atmospheric content of CO2.  I would have liked to have the discussion of causality with him, but we never got around to that.  He did point out an area of plate-like coral that had been demolished by a cyclone ten years ago and had regrown quite nicely.  Does this disprove the theory?  Probably not to those who BELIEVE, but that's a topic for another day. 

Tomorrow, I head to Perth and the RANZCR meeting.  Back to business!  But these few days have let me acclimate to functioning 12-14 hours into the future, and were well worth it.  More to come!

Sunday, October 10, 2010


I made it to Port Douglas, Queensland, Australia, in one piece. Unfortunately, Delta couldn't seem to figure out how to transfer my suitcase over to Qantas, so I'm here quite literally with the clothes on my back. Qantas did give me some cash to buy a few things, which helps some. I was able to run to town and pick up a bathing suit so I can go snorkeling on the Reef tomorrow.

The Thala Beach Lodge is quite pleasant, a bit rustic and out of the way but nice nonetheless. It's sort of a cross between Las Brisas and Camp Nebagamon.

Yes, I'm back, although with a somewhat inauspicious start. For whatever reason, I'm not feeling disoriented this time. On my first visit, just under one year ago, I had some brief mental images of being upside down. Not a problem this time, however. I've simply decided that the rest of you, at least those in the Northern Hemisphere, are the inverted ones. Think about that, you North American/European chauvinists.

More later, assuming I don't get stung or eaten or something.