(This is the talk I gave to healthinc customers and friends Wednesday, October 21, 2009 in Brisbane, Queensland, Australia.)
A quick disclaimer: I'm not the REAL Dalai Lama, but he is coming to Sydney in December.
I’m guessing most of you have had a look at my blog, and maybe some of you have even peeked at my profile.
Hopefully, you won’t find me too disappointing in person! I’m just an average radiologist from an average small town in the Deep South of the US. Nothing special, I promise. So what am I, a nice Jewish boy from Nebraska doing here in Brisbane speaking to you as the Dalai Lama of PACS?
It's been an interesting journey. I’ve always loved anything to do with electronics or computers, as well as things medical. So it seemed logical to obtain an Electrical Engineering degree, and go on to medical school. At first, I wanted to be a Cardiologist, but I was able to resist the dark side, and I soon became enamoured with radiology. In those days, before CT was quite so wide spread, and when NMR was found only in chemistry labs, Nuclear Medicine was more computer-oriented than diagnostic radiology itself, and so a fellowship followed.
I’m now a private-practice radiologist in Columbia, South Carolina, a job I found by answering an ad posted in our reading room. (I had no idea where Columbia was when I called in, but it sounded like a nice place.)
In 1992, a few years into private practice, one of my senior partners introduced me to this thing called PACS, (although we really didn’t use the term so much in the early 90’s.) 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 eventually formed (or stole, I’m not sure) the idea of “Sit here, read there”. He was a visionary as far as such ideas go, although he always had some problems getting his home computer running smoothly. Sadly, he’s since gone on to a better place (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 with modalities ranging from Computed Radiography to CT, PET/CT and MRI. With few exceptions, we can access any study from anywhere, the dream fulfilled.
I won’t exaggerate my role in this achieving this dream, although I did have some influence here and there. 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 AuntMinnie.com, initially asking my contemporaries 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, I am posting my own personal opinions and observations and I just wanted everyone to take them for what they are worth. No divine knowledge or inspiration is implied. But, 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.
I cannot tell you how amazed I am to be speaking with you here today, half a world away from my own territory. But I have to believe that I’m experiencing the same trials and tribulations as every other radiologist. For some reason, I’m one of a very few of us 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 General Electric. But after a day slogging against a malfunctioning system, I think most of us do care, and want some changes.
I have had the joy of working with quite a number of systems beginning with our first, relatively primitive Agfa system, complete with UNIX based computers, back in 1993. Since then, well... The short list of my conquests includes Agfa, ScImage, Image Technology Laboratories, General Electric, Aspyra, and of course Amicas. And, let us not forget the innumerable CD-ROMs with rather poor excuses for viewing software included. I can make a positive comment about each and every one of these: they all do show the images. Sort of. Some don’t do much more than that, and in fact make it quite difficult to see the images, which is the whole point of the exercise! 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 CT’s. The common thread with most of these is the utter lack of understanding of how I do things. Suffice it to say that most of these (not Amicas, fortunately, and some others out there such as Intelerad and a few more) haven't a clue about what we do and how we do it. Approaches range from an attempt to look like a spaceship control panel (I'm not exaggerating) to the concept of toggling tools on and off with no obvious rhyme or reason. 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. It didn't occur to them that there was more to the software than the core viewer. Getting the images into the viewer was an exercise in agony. Most of the systems don't grasp the concept of an updated worklist, and most think 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.
Overall, it has always seemed to me that in a life and death business like ours, things could be done better.
In addition to the joys of the disparate, sometimes poorly written systems themselves, 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.
Over the years, certain trends and patterns in PACS and our relations with PACS vendors as well as Information Technology (or Information Services, or whatever we happen to call them) became clear. I’ve distilled these into the LAWS of PACS (autographed copies available for $10US in the back!). 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 see the forest for the trees. Once PACS is in place, the film is gone, 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.
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.
Again, this is so big and clear that many have trouble seeing it, or at least no one wants to admit it. Especially IT. There does seem to be some debate as to who should be considered the real users of PACS. Yes, in theory, 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 CEO (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 me, the radiologist, to use for patient care. Quite often, IT doesn't quite get 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. A big discussion at SiiM in Charlotte this past June came to a similar conclusion. And 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, a rather high priced item, sometimes becomes a political hostage, yanked back and forth to the department that wields the greatest power and can draw the largest budget. Thus, territorial squabbling comes into play, and some who participate tend to lose their orientation, which should of course be directed toward...THE PATIENT!
IV. Once PACS, never back.
A little PACS downtime provides a wonderful reality check. It becomes very clear in the first 10 minutes or so that we cannot ever live without our system again. Film? What's that? Is there a good downtime plan? Is there any downtime plan?
V. Workflow is inversely proportional to the number of buttons on the PACS desktop.
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.
Many modern systems have in this way become hyperconfigurable and suffer from the Lego-PACS syndrome -- that is, one can build the buttons on the interface in so many ways that the permutations would take a century to exhaust. I assume Lego is as popular here as it is back home, and it was indeed my favorite toy 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 should not get in your way.
A corollary of Dalai's Fifth 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. I love car analogies to illustrate this. The latest BMW’s have something called iDrive, which is a big mouse that controls 700 functions. Most people end up accessing about 20 of these. This is called “feature fatigue” and the multiplicity of stuff available distracts one from the road. 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.)
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 "Big Iron" companies, unlike Burger King (which I understand is called Hungry Jacks around here) having things "my way" is simply not in the cards. The products of the larger companies seem to reflect the mentality of largess, and the phrase "bloatware" comes to mind. With this comes the anathema of the Lego PACS and obstructive designs I have bemoaned above. A large (spelled l-a-r-G-E) company who likes to claim that their imagination is always at work keeps buying out smaller companies, trying 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. An average PACS consultant will take six months to tell you what you already know.
There are some very good consultants out there, especially my very good friend Mike Cannavo, the One and Only PACSMan. Perhaps you have read his series of excellent articles on Aunt Minnie. If you really need someone, call Mike. He'll help you negotiate the tortuous road to acquiring PACS. But then, he is well above average.
In many cases, consultants are brought on board not so much for their expertise in PACS, but to provide someone to blame in case the PACS purchase doesn't please everyone involved. A great deal of information is available on the Internet, both from the vendors themselves and from happy (and unhappy) users posting on sites like AuntMinnie.com. After perusing the available information, going through various demos and site visits, and communicating with other users, I think one can amass a fair amount of knowledge about the various systems out there.
Where the above-average consultant shines is actual negotiation of the deal, with the understanding of the subtleties and nuances of contracts and such. Yes, they have their place, but if you hire a consultant with the thought of picking your PACS for you, I would respectfully submit that you are simply avoiding doing your homework. Remember, no one knows your business like you do.
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 can be relied upon to varying degrees, at least for the initial installation, but ultimately, there must be someone there on the ground to keep everything running smoothly. As of a year or so ago, I would have said that there were about 100 PACS gurus in the country. By now, there are probably nearly a thousand or so, but they are still the most valuable folks in the hospital. Trust me on that.
I have been extremely fortunate to know several gurus over the years. My group's guru worked his way up to PACS from being chief trauma radiographer; therefore he understands Radiology workflow better than any IT wonk. This is a critical trait in a guru. The first guru I ever met was originally one of my Nuclear Medicine tech students. He had extensive computer and electronics training in his first career in the US Army, and so was well equipped to do the job. I'll never forget sitting with him in PACS committee meetings, run by IT. On some particular issue, IT was going on and on: "We can't do that, it won't work, we'll need to schedule a meeting in six months to decide if we should talk further about it." To which my old guru turned to me and whispered, "I've already done it and it works just fine!"
X. Remember that you are the PACS customer.
No offense to present company, but vendors have sneaky ways of disarming complaints: "You don't really need that function," "No one else does it that way," and "We're working on that, but we don't know when it will be available."
Don't let them get away with this bait-and-switch game. You wouldn't expect this sort of treatment at the Mercedes dealership, and most PACS are a lot more expensive than any car!
XI. All software errors, including those within a PACS, 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?
Urging our friends to see things our way isn't easy. Sometimes, one has to resort to bad publicity, as might be found on a certain radiologist's PACS blog....
Now, believe it or not, I don't jump for joy or cackle with glee when I post a bug report. Actually, I cringe, well, at least a little, knowing that I'm inviting trouble upon the company involved, as well as myself and my group. But when patient care is involved, you do what you have to do, and be prepared to take the consequences.
XII. 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 this behaviour to paranoia, concern, laziness or simple meanness. Probably all four.
XIII. The PACS needs to be operable by the least technically savvy radiologist on staff.
This is inspired by one of my partners who is 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 (to embarrass him) about the time he called me from a plane 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.
XIV. Drive before you buy.
I've been preaching this one for years now, and people still don't believe me. 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 some smoke and mirrors are involved.
Ask, nay, demand, a demo of your own that you (not the salespeople) can pound on at will. Technically, this should not be a problem for any Web-based product, as there should be a demo server for just this purpose. The joys and pitfalls of various systems do not become apparent until you have actually tried to use them in a production environment.
XV. Speech recognition will be acceptable to me when the CEO, CFO, and CIO use it for their correspondence.
This topic probably deserves an entire article of its own, as it always inspires controversy. As I see it, speech recognition (it is not voice recognition, by the way) is a technology that has yet to be perfected. Comments on AuntMinnie.com and elsewhere indicate that the level of satisfaction is pretty low. But hospital administrators still try to push it on us. Why? Because they pay transcriptionists, and they don't pay us.
Therefore, if they can shift even some of the transcriptionists' editing duties onto the radiologists, they save money and look good come budget time. If it takes us an extra hour a day to do our job and do all the editing expected from a human transcriptionist, well, that's OK, right? Wrong!
So, here's my counter offer: When the members of the C-suite (the CEO, CIO, CFO, etc.) find speech recognition adequate for their correspondence, I will deem it worthy of review for use in the reports I issue as my stock-in-trade, the reports that clinicians rely on to make life-and-death decisions about their patients. Fair enough?
XVI. PACS is not film.
In the early days of PACS, displays were designed to mimic a film view box. This seems sort of 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.
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, and our vendors. On many issues, I have had to use my blog to garner attention to significant problems we have had with PACS systems, when there was no other way to get anyone to listen. Here is a great example plucked from my blog of how our IT department and a large vendor teamed up to make my life miserable with something called "G.I.D.I." As you will see, rather than make us giddy, it becomes more of an abbreviation, as in, "this G.D. thing is driving me crazy!"
"What is a GIDI?" Well, the official title of this software extravaganza is "Generic IMPAX DTMF Integration," and it was designed to help us communicate reports to the outside world. It was a good idea, with all the right intentions, but we all know what the road to Hell is paved with, don't we?
Here's the problem the GIDI was designed to solve: We have Agfa Impax PACS, and we also had an older Dictaphone analogue voice dictation system. As we dictate happily along, there must be a way to enter the patient into the system for the transcriptionist to know whose report she is typing. We could just read the patient ID, or the accession number, or something like that into the mike as the beginning of the dictation. But that wasn't good enough. The GIDI was supposed to solve the problem by automatically entering the touch-tones into the Dictaphone, via a SoundBlaster audio board that interfaces between the workstation and the analogue dictation line.
This should be a labor-saving device for all involved. Except for one little problem. It is a true pain in the backside to use. It was over engineered and under tested. In actual use, the tones are transmitted VERY SLOWLY. Yes, an extra 6 or 10 seconds per study is no big deal, unless you are reading 200 studies a day as we do some weekends. That would be 1200 seconds, or 20 minutes. Let's see...even an extra 10 minutes per day, working, say, 200 days per year, adds up to 2000 minutes or 33 hours. That would be just under four 9-hour working days per year. You get the idea. All that time wasted because of a program that is supposed to be helping me.
Even worse, the thing has a bad habit of hanging up the Dictaphone, crashing IMPAX, or decoupling itself with the dictation system, requiring restarting of the GIDI, redialing into Dictaphone, and sometimes rebooting the computer altogether. So, add another 10-20 minutes to the daily toil. The system only allows dictating one exam at a time, so we have to re-GIDI every study on a multiple trauma patient. (And I'm talking about a CT of the head, C-spine, T-Spine, L-spine, chest, abdomen, pelvis, and at least one extremity, as well as CR's of all of the above, so there could be 10-20 different clicks for one patient.)
Worst of all, occasionally, when the GIDI blows up, the study that was on the screen disappears, and if you weren't paying very close attention in those first few seconds, it is rather difficult to know who just left your screen. Thus, a number of studies are accidentally lost from the worklist, only to be rediscovered hours or days later.
This blog post caused a minor war between us, well, me, and IT. There were shrieks (literally) of anger, and requests to pull the plug on Dear Doctor Dalai. But I was right, and ultimately the GIDI was turned off.
This is the same IT team, by the way, that made a decision about PACS vendors with absolutely zero input from the radiologists.
It should surprise no one that Agfa delivered us a similar bout of foolishness quite recently involving our beloved IMPAX:
When I try to look at a study, say a CT, which has more data coming in from the modality, say a sagittal reformat, the client crashes. The crash occurs AFTER I have clicked the study into "Dictation Started" status, and the study in question subsequently disappears off the list. When the client comes back to life, I have to remember the name of the victim, or the study runs the risk of being lost to me, only to turn up later in the "you didn't read this on time!" pile. Dare I even hint at the possibility of an impact upon patient care?
Here's the problem as I understand it: We don't want people reading studies before all the data is in. Thus a study has a built-in delay that should keep it off the worklist until it's ready. But sometimes there is an even longer delay between the acquisition of the various parts of the study, and it appears on the list anyway. But if we access the study whilst more data is coming in, the system gets confused, since we shouldn't be reading it, and it crashes. Hence, my image of the monkey chasing the weasel. POP goes the Impax!
There ought to be a solution for this. If there is, please let us deploy it. If there isn't, please create one. Very quickly, please.
POP goes the Dalai!
As of this point, right now, today, Agfa’s response has been twofold: 1. We’re talking about it. 2. You should change your workflow to work around this error. Someone from Canada left me this comment on the blog post bemoaning this garbage:
I hope Agfa PACS is not implying that it is acceptable in any way to get this type of error message; you are offering a work around, not a solution. . . As an Impax user (and someone with a degree in Computer Science) I find it totally unacceptable that a live clinical product has this type of bug. Furthermore, Agfa makes little or no active effort to correct or prevent these types of bugs. Frankly, I have given up on reporting bugs.
The usual response from Agfa support is...after 1 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?
Sadly, we keep getting solutions designed without regard to the actual workflow of the actual human beings that actually use them. Again and again and again, we are delivered products that the engineers (keep in mind, I am an engineer by training as well) think we should like, but never asked us if we actually do. Maybe it all boils down to communication. Somehow there needs to be dialogue between the end-users of these things and the folks that create them. Don't go looking for something you can patent, guys, but try to come up with something that will truly help me do my job. And please listen to me when I tell you how I do my job, don't just show me newer and shinier gadgets that you think will enhance my workflow. Most of the time, they just get in my way. Like the GIDI. Which we got removed as quickly as we could. But the latest glitch tells me we still have a long, long way to go.
There is light at the end of the tunnel, as there are some companies that actually listen to us. I stumbled upon the Amicas booth at the SCAR (now SIIM) meeting in 2003 in Boston. There was an unoccupied workstation and I sat down and started pounding on it. I liked what I saw. Here was the Real-time worklist, looking much like it does today, which told me at a glance who was reading what, and what needed to be read. What a concept! The viewer was clean and functional. It worked, and it didn’t get in my way. That software, by the way, was LightBeam version 3.6 or 3.7. What you will be working with now is version 6, known simply as Amicas PACS, with Halo Viewer. (Where Halo came from, I don’t really know, but it sounds good. Perhaps there was an X-box player amongst the programmers!) I’m very proud to say that I had a hand in the development of Version 6. The parts you like are the ones I suggested. Those few parts you don't like I had nothing to do with! Seriously, though, Amicas decided to start from scratch, to completely rewrite the software, and I happened on the scene just as some of the ideas were beginning to gel. I’ve been up to Amicas HQ several times, and the Medical Advisory Committee has met several times over the past few years, trying to help create this next-generation product. As a final shake-down, I spent two solid days working with the guys in Boston, attempting to simulate my daily reading grind. That helped provide the final touches for Halo, or so I’m told. The final product was borne of Amica’s desire to listen to us, the radiologists, and help us do our job in the easiest manner possible. Of course, they listened to me and folks like me. However, as per Dalai’s Lucky Thirteenth Law, PACS has to work for the least-technically-savvy member of the group, and I tried to keep that in mind at all junctures.
My battles with IT wax and wane as well. Like Amicas, there are some IT folks that do understand my workflow and my needs. By and large, they, like my guru, rose up from the radiology ranks. They speak my language as well as that of the machines. They understand the ultimate goal, serving the patient, better than those who didn’t come from the health-care background.
The key here is communication, which is a two-way street. We have to make known our needs, and the manufacturers, the software writers, the vendors, and IT, all 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 IT management, well then, we deserve what we get. But our patients deserve better than that, don’t they?
Healthcare in the US is at the cusp of major change, although as yet we have no idea how that will actually manifest. We do expect, sadly, that imaging revenue will be hit hard. We have in many ways been the victims of our own success. Imaging works, and works very well, to help our patients. We do such a good job of it that emergency medicine docs order CT scans of trauma patients before actually casting eyes on them. They think we can do a better job of diagnosis than they can, and probably they are correct! Thus we are incredibly busy, sometimes with more business than we can handle comfortably. For us, imaging has thus become a 24/7/365 proposition. I don’t know if you have to deal with this to the same degree as we do, but if a patient presents at 3AM with a headache that he’s had for the past week, he gets a head CT then and there. Americans, at least, have come to expect this level of attention.
As scanner technology improves, business increases, and hardware prices fall. Thus, it is now possible for not only radiologists, but clinical doctors as well to own their own machines. Some of the latter buy state-of-the-art battleships with all the bells and whistles some opt for the surplus East German versions powered by rats on a treadmill. Because our insurers don’t know the difference, studies from either one receive the same reimbursement. Thus, imaging self-referral by clinical doctors who own their own scanners has skyrocketed. Now, my clinical friends claim that this practice provides convenience for their patients, and I’m sure that’s true. But how do we explain the fact that those who have their own scanners order significantly more scans? Either they are overutilizing the technology, or their less-fortunate clinical brethren are underutilizing it. I’m not smart enough to tell you which is true. Our government may or may not ever get around to solving this. They actually think this is a turf battle, which needs no regulation on their part. What will happen to health care as a whole, I haven't a clue.
The only way to stay alive in the anticipated environment of change is to be as efficient as possible. A good PACS makes this happen; a bad PACS will hurt you.
Now, I understand that you have your own version of Medicare here, a mixture of public and private approaches. I would really like to learn more about it from your perspective. Apparently, you suffer with taxes being levied to support healthcare too- but luckily you don't have to deal with Messrs Obama and Biden. Last time I checked, you do have Kevin Rudd, and Nicola Roxon (Minister of Health and Aging), but at least you have the Queen.
The near-term looks grim to me, given the impending changes. Sales of equipment in the US are way down, as we don’t have a clue even yet what is coming at us. Still, I do envision some good things happening. There is a huge governmental drive in the US toward the Electronic Health Record. This is a good thing, although the government probably wants it more for tracking purposes than patient care. Most vendors, including Amicas, are developing vendor-neutral archives, which will simplify storage across the enterprise. There is also a huge push toward unified PACS, which gives one a single portal to a disparate enterprise, as well as universal identifiers to collect the data on your patient who was at Hospital A yesterday, Hospital B today, and will be seen at Clinic C next week. This is perhaps the most welcome invention of all, given the multitude of sites we cover, and the tendency of patients to visit them all at one point or another. In fact, the "portable patient" has been the bane of my existence for many many years, and I keep hoping to see this problem solved. On another front, advanced visualization will become a part of every PACS; you will find, by the way, that the on-board tool-set in Version 6 already has tremendous power for 3D processing.
But no matter how far we progress, Dalai’s Laws still apply. PACS exists for the good of the patients, and this we must never forget. We are all bound to find the system that suits us, that lets us do our job of caring for our patients in the best manner possible. I think we in this room have found one that’s pretty darn good.
This little journey through PACS is obviously far from over, and it has been quite interesting to say the least. As long as we keep in mind that the ultimate goal is the improvement of patient care, we will certainly all be traveling in the same direction.
I'm still more than a little bit stunned that anyone even looks at my blog, let alone my apparent world-wide readership. It's quite humbling to know that you have read my feeble attempts at prose, but it is very encouraging to realize that all of us in this field face and surmount similar challenges. We'll keep fighting the good fight on behalf of our patients, in spite of what some large companies might, well, imagine.
Your country is absolutely beautiful, and your people incredibly friendly. That being said, listen to this quote from the 1987 American Express Guidebook to Australia:
"Behind the wheel of a car, many Australians change from being normally very tolerant creatures into something far less attractive. In addition to fast and aggressive driving, they sometimes show a marked reluctance to obey traffic laws and lane discipline, which can be disconcerting for visitors accustomed to highway driving in Europe or the USA."
Obviously, the authors had never been in a cab in Boston or Washington, D.C. The book goes on:
"But it should be said that Australians are an extremely generous people. They possess a wry sense of humour and a laconic turn of phrase. They have a healthy disregard for authority and a great distaste for exaggeration, showing off, and other expressions applied to those who have an inflated sense of their importance. . . and there is nothing an Australian likes better than deflating such people."
It seems I've been an Australian all my life and I didn't even know it!
I would like to thank
healthinc for giving me this incredible opportunity to speak with you tonight. I am particularly grateful to Natasha Noble, who spent hours on the phone with me at the very fringes of the day around here making countless arrangements for this all to be possible. This trip has given me the chance to visit with some old friends, Mark and Sonya, who live here in Brisbane, and whom I haven’t seen in many years. I hope you didn’t find this all too boring!
Most of all, I thank you for your time tonight and your readership of my blog. For what it's worth, I think you have made an excellent choice in vendors. That is my own, honest, humble opinion. So, as we say in the Deep South, Y’all Take Care! Thank you so much for coming tonight.
